[MySQL] DB power failure proof maken.

[OverSoft]

Ik ben op het moment bezig met een narrowcasting projectje.
Op verschillende locaties komen machines te staan waar wat flash films op draaien. De playlist en eventuele texten of RSS feeds komen in een lokale MySQL DB te staan.
Nu is dat niet zo'n probleem en dat heb ik al lang voor elkaar.

Het grootste probleem waar ik momenteel tegen aanloop is dat op een hoop plaatsen waar de machines komen te staan, 's nachts de stroom er af gaat via de stoppenkast. Hier kan ik helaas niets aan veranderen.
Nou draai ik op die machines Ubuntu met Mysql 5. Het grootste probleem is niet zozeer harddisk corruption (tijdens het booten draait de automatische fsck en fixed dat allemaal), maar database corruption. Soms is de 'mysql' database zelf niet eens meer leesbaar en kan ik dus met geen mogelijkheid meer inloggen.
Het probleem is dat op den duur er een hele hoop machines gaan staan en die moeten automagisch weer gaan werken na een power-failure. De DB's veranderen over het algemeen een keer per dag via een updatescript (dit kan overigens oplopen, want het update script draait iedere 5 minuten).

Heeft iemand enig idee hoe ik hier iets tegen kan doen? Oplossingen als UPSen e.d. zijn niet aan de orde, het moet puur software matig gebeuren (ik ga helaas niet over het budget).

[DataGhost]

Zo'n 10 minuten voordat de stroom eraf gaat de zaak laten halten?

[CyBeR]

Verandert de data in je db tussen de updates door? Zo nee, zou je na elke update een dump van je db naar disk kunnen maken (wel een klein archief bijhouden en detecteren of je dump niet halverwege ingekort is omdat de stroom er precies toen uitging) en die bij elke boot inlezen nadat je mysql schoon geinitialiseerd hebt (zodat je mysql tabel enzo ook niet corrupt kan zijn).

[OverSoft]

DataGhost schreef op vrijdag 14 september 2007 @ 00:55:
Zo'n 10 minuten voordat de stroom eraf gaat de zaak laten halten?

Dat gaat niet lukken, elke zaak gaat op andere tijden dicht en dat bijhouden is meer werk dan dit goed opzetten.

CyBeR schreef op vrijdag 14 september 2007 @ 01:02:
Verandert de data in je db tussen de updates door? Zo nee, zou je na elke update een dump van je db naar disk kunnen maken (wel een klein archief bijhouden en detecteren of je dump niet halverwege ingekort is omdat de stroom er precies toen uitging) en die bij elke boot inlezen nadat je mysql schoon geinitialiseerd hebt (zodat je mysql tabel enzo ook niet corrupt kan zijn).

Dat is op zich wel een idee. Gewoon een mysqldump doen naar een bestand.
Heb je nog adviezen over hoe ik het best een schone mysql DB terug kan zetten tijden het booten of wordt dan gewoon heel vies een "tar -xpzf mysqldb.tgz -C /var/lib/mysql"? (Daarmee bedoel ik dus de lege database, niet de dump)

[ Voor 57% gewijzigd door OverSoft op 14-09-2007 02:26 ]

[CyBeR]

OverSoft schreef op vrijdag 14 september 2007 @ 02:23:
[...]

Dat is op zich wel een idee. Gewoon een mysqldump doen naar een bestand.
Heb je nog adviezen over hoe ik het best een schone mysql DB terug kan zetten tijden het booten of wordt dan gewoon heel vies een "tar -xpzf mysqldb.tgz -C /var/lib/mysql"? (Daarmee bedoel ik dus de lege database, niet de dump)

Mja je zou ook nog helemaal de init procedure kunnen doorlopen alsof 't een schone install betrof, maar volgens mij is 't veel minder omslachtig om idd gewoon een pre-inited omgeving terug te zetten. De data in de mysql tabellen e.d. veranderen niet in jouw situatie, lijkt me.

[Koffie]

Tja, dit heeft weinig met PNS te maken; het enige PNS antwoord is namelijk ee fatsoenlijke UPS met ditto management software.

Wat je kunt doen is zorgen dat je elke 10 minuten een dump maakt, en je server zo instellen dat hij bij een reboot eerst die dumps restored.
Een andere optie is een master DB server neerzetten waar de client DB's mee synchen.

Move PNS > NOS

[Ooyevaar]

Helemaal mee eens, een eenvoudige ups kost uiteindelijk veel minder dan jouw tijd.
En om de backup-time hoef je het niet te doen, gewoon netjes af kunnen sluiten is genoeg.

Ik heb de afgelopen jaren echt wel geleerd dat je niet moet gaan investeren in knutseloplossingen

[Confusion]

OverSoft schreef op vrijdag 14 september 2007 @ 00:46:
Het grootste probleem waar ik momenteel tegen aanloop is dat op een hoop plaatsen waar de machines komen te staan, 's nachts de stroom er af gaat via de stoppenkast. Hier kan ik helaas niets aan veranderen.

Puur uit nieuwsgerigheid: wat voor plekken zijn dat?

[user109731]

Gebeurt dit ook wanneer je InnoDB als storage engine gebruikt?

[BarthezZ]

Ben ik de enige die het zeer raar vindt dat het als normaal wordt beschouwdt om pc's gewoon van de stroom af te sluiten? Ik denk dat dat zeker de levensduur van je hd's nogal verkort, en verder is het niet alleen voor MySQL software ronduit slecht...

Ik vermoed dat de kosten van een kleine UPS (genoeg stroom om de pc tijd te geven veilig uit te schakelen) kwa kosten minder zal zijn dan wat je nu aan man uren krijgt voor vervanging, en deze houtje toutje oplossing.
Maak er een uiteenzetting van van alle kosten en ik denk dat je dan toch zal schrikken en een UPS opeens een vrij fijn alternatief zal zijn.

[Verwijderd]

Leuk dat MySQL maar voldoet niet meer aan jouw eisen. Een was meer volwassen/proffesionele database "recovered" zich zelf. Kijk eens naar MaxDB, zit nu ook in de MySQL stal. Of anders sybase, oracle . db2....

en anders (ik ken de load niet) laptopjes? Die draaien nog een uurtje of wat door en als de batterij leeg is kan je 'm netjes laten afsluiten.

[DataGhost]

Ja, er zit dan weinig anders in dan een aantal goedkope UPSjes neer te zetten, zodat je in ieder geval weet wanneer de stroom eraf gaat en een paar minuutjes hebt om de zaak uit te laten schakelen. Misschien moet je ook eens kijken wat het nou precies kost om elke keer data te hetstellen, wellicht rechtvaardigt dat de aankoop?

[OverSoft]

De locaties zijn horeca gelegenheden en helaas gaan uitbaters niet zo netjes met de spullen van anderen om. Alles draait vanaf IDE flash kaartjes en dat hebben we al redelijk dicht zitten.
Het is voor de organisatie simpelweg te duur om UPSen te gaan inzetten, het gaat niet om 5 locaties, eind dit jaar zitten we over de 500.
Laptops gaat niet werken, we gebruiken industrial mobotjes van MSI en Core2Duo's omdat de load gewoon hoog is (de Flash filmpjes hebben resoluties tot 1360x768).

Ik zal eens naar MaxDB kijken (ik weet het, softwarematige oplossing voor dit soort "vieze" problemen is niet netjes, maar het zal moeten)

[daft_dutch]

pak een laptop.
bv:
oud of
met kapot scherm

en met suspend2disk als de accu bijna leeg is. en weer aan als de spanning weer up is.

[Verwijderd]

Ik heb ook een mysql database die elke dag de poeier in gaat, een rsync van een interne server onder Solaris naar de webserver Linux, gaat niet goed -een beetje moeilijk omdit structureel om te lossen , omdat de mysql.4 versies verschillen, ik kan de versies niet gelijk trekken, omdat mysql 4.x sources niet meer beschikbaar zijn op mysql.com, daarnaast is dit bedacht door een externe ontwikkelaar - als workarround, totdat ik de Debian server naar de nieuwste versies breng onder Mysql 5.x, fix ik iedere nacht de database, bij my online via een mysqlcheck met o.a. opties --autorepair en --silent, jij zou bij het opstarten kunnen controleren of de database beschadigd en eventueel repairen, dat zou met de offline versie moeten gebeuren, myisamchk.

Om naar Maxdb te kijken lijkt me zeker niet verkeerd, maar ik zou wel een controle inbouwen bij het opstarten of de database beschadigd en eventueel repairen, scheelt weer een telefoontje, vooral als je zoveel machines hebt, misschien nog een log server opzetten, zodat de logs centraal te zijn te bekijken als die machines een internet verbinding hebben.

[ Voor 6% gewijzigd door Verwijderd op 15-09-2007 08:39 ]

[CyBeR]

Verwijderd schreef op zaterdag 15 september 2007 @ 08:34:
ik kan de versies niet gelijk trekken, omdat mysql 4.x sources niet meer beschikbaar zijn op mysql.com,

Op mysql.org zijn de 4.0 sources idd pleite (4.1 niet) maar op de mirrors zijn ze er nog wel:

ftp://mirror.hostfuss.com/mysql/Downloads/MySQL-3.23
ftp://mirror.hostfuss.com/mysql/Downloads/MySQL-4.0
ftp://mirror.hostfuss.com/mysql/Downloads/MySQL-4.1

[ACM]

JanDM schreef op vrijdag 14 september 2007 @ 08:29:
Gebeurt dit ook wanneer je InnoDB als storage engine gebruikt?

Waarom kijkt iedereen over deze vraag heen?

OverSoft schreef op zaterdag 15 september 2007 @ 03:10:
Ik zal eens naar MaxDB kijken (ik weet het, softwarematige oplossing voor dit soort "vieze" problemen is niet netjes, maar het zal moeten)

MaxDB of andere producten zou ik niet als eerste naar kijken...

Als je software nu al met MySQL 5 werkt zou ik gewoon de boel in InnoDB omzetten en die zo instellen dat ie writes direct wegschrijft (er is wat controle over de fsyncs mogelijk), verder je harddisk instellen dat ie niet stiekem toch writes gaat zitten cachen (kan met hdparm vziw) en dan zou je redelijk veilig de stroom eraf moeten kunnen halen.
Zolang je dat laatste niet doet - speelt vooral bij IDE/SATA disks - is geen enkel databaseproduct veilig te gebruiken, ook oracle, sybase en db2 niet (hoewel ik uit kostenoogpunt naar postgres zou kijken als je toch iets anders wilt gebruiken dan mysql).

Als je in mysql myisam-tabellen gebruikt heb je gewoon nauwelijks beveiliging tegen outages en crashes, met InnoDB wel en dan kan je tenminste je huidige kennis en software naadloos blijven gebruiken.

[deadinspace]

OverSoft schreef op vrijdag 14 september 2007 @ 00:46:
Het grootste probleem waar ik momenteel tegen aanloop is dat op een hoop plaatsen waar de machines komen te staan, 's nachts de stroom er af gaat via de stoppenkast. Hier kan ik helaas niets aan veranderen.

Je wil dit waarschijnlijk niet horen, maar dat zal altijd problemen blijven geven. Als de stroom naar een computer uitvalt, dan loop je altijd het risico dat data corrupt gaat. Theodore Ts'o heeft dit mooi uitgelegd, dus ik herhaal het relevante stuk hier:

> Simple as pie. Set up a machine running XFS. Start some disk activity
> (maybe a test mail server). When the FS is getting solid activity, yank
> the power out. When I saw this happen I had to mkfs and start over.

What probably hit you here is caused by the very simple fact that PC-class hardware is crap.

You see, when you yank the power cord out of the wall, not all parts of the computer stop functioning at the same time. As the voltage starts dropping on the +5 and +12 volt rails, certain parts of the system may last longer than other parts. For example, the DMA controller, hard drive controller, and hard drive unit may continue functioning for several hundred of milliseconds, long after the DIMMs, which are very voltage sensitive, have gone crazy, and are returning total random garbage. If this happens while the filesystem is writing critical sections of the filesystem metadata, well, you get to visit the fun Web pages at http://You.Lose.Hard/ .

I was actually told about this by an XFS engineer, who discovered this about the hardware. Their solution was to add a power-fail interrupt and bigger capacitors in the power supplies in SGI hardware; and, in Irix, when the power-fail interrupt triggers, the first thing the OS does is to run around frantically aborting I/O transfers to the disk. Unfortunately, PC-class hardware doesn't have power-fail interrupts. Remember, PC-class hardware is cr*p.

Nou gaat die tekst vooral over het veroorzaken van filesystem corruption (en waarom ext3 daar minder vatbaar voor is dan XFS en ReiserFS), maar de reden waarom er garbage geschreven wordt gaat natuurlijk ook up voor de inhoud van files. Zoals bijvoorbeeld een Database file.

Je kan proberen om aggressiever te syncen (filesystem met sync optie mounten, handmatig syncen, whatever), en misschien dat je daar wat succes mee oogst, maar het risico blijft hoogstwaarschijnlijk.

[OverSoft]

Is het misschien een optie om de database tijdens het booten naar het een tmpfs te kopieeren?
Daarna als er een significante database update komt deze wegschrijven naar de schijf op 2 aparte mappen (afwisselend db1 en db2). Pas aan het eind van het wegschrijven schrijf ik (m.b.h. van een scriptje) naar een bestandje 1 of 2.
Tijdens het booten pakt het scriptje dir1 of dir2 om deze weer naar de tmpfs te laden.

Helaas weet ik dat dit altijd problemen gaat geven. Op het moment gebruik ik voor een hoop al tmpfs spul (zoals de flashfiles e.d.). Ram is tegenwoordig niet duur meer en een mooie oplossing voor dit soort spul (een gig geheugen in de players is genoeg. 512mb voor flashfiles, 128mb voor lokale webserver en update scripts en evt. db dus).

Ik zal eerst eens gaan experimenteren met innodb, omdat dit het snelst is toe te passen.
Evt. de Mysqlconfig een beetje tweaken zodat writes direct doorgevoerd worden.
(Overigens, de drives die we gebruiken zijn Transcend IDE flash modules, die direct op de 44pins IDE connector geduwd kunnen worden en geen andere aansluitingen meer nodig hebben (ook geen powerplug, dat gaat vanaf de 5volt van de IDE connector (de extra 4pins)).

[vanaalten]

Op zich heb ik weinig verstand van dit soort dingen, maar wat ik er wel van zie:
Zorg dat de gekozen oplossing gegarandeerd betrouwbaar is. En dus niet op basis van een aantal experimenten waarin het goed lijkt te gaan concluderen dat het een betrouwbare oplossing is.

Reden:
Stel, eens in de 700 keer gaat het mis en is er iets corrupt waardoor het systeem niet meer goed op wil starten. Dat lijkt misschien acceptabel, maar als je volgend jaar op 700 locaties (ik extrapoleer even) zit waar de boel dagelijks hard wordt afgesloten, dan heb je dus elke dag een storingsmelding. En tegen die tijd is het systeem al zo groot uitgerold dat het niet echt doenlijk en verkoopbaar is om dan nog over te gaan op een degelijke hardware-oplossing.

Ik zeg niet dat het niet softwarematig kan (immers, ik heb er geen verstand van) maar zorg dat je heel zeker van je zaak bent, dat het gegarandeerd niet fout kan gaan.

[Rukapul]

OverSoft schreef op vrijdag 14 september 2007 @ 00:46:
Het grootste probleem waar ik momenteel tegen aanloop is dat op een hoop plaatsen waar de machines komen te staan, 's nachts de stroom er af gaat via de stoppenkast.

database corruption. Soms is de 'mysql' database zelf niet eens meer leesbaar en kan ik dus met geen mogelijkheid meer inloggen.

De DB's veranderen over het algemeen een keer per dag via een updatescript (dit kan overigens oplopen, want het update script draait iedere 5 minuten).

Je hebt een database die 1x per dag wijzigt en 's nachts gaat de stroom eraf. Dan heb je dus een enorm tijdslot waarin je die ene dagelijkse database update kunt uitvoeren (en gedurende de andere momenten zorg je ervoor dat MySQL geen diskschrijfoperaties uitvoert). Het is of dat, of je geeft niet een volledig beeld van de situatie.

Met zo'n updatestrategie en verder readonly database zijn genoeg degelijke oplossingen te bedenken.

[Bud_s]

OverSoft schreef op vrijdag 14 september 2007 @ 00:46:
Het grootste probleem waar ik momenteel tegen aanloop is dat op een hoop plaatsen waar de machines komen te staan, 's nachts de stroom er af gaat via de stoppenkast. Hier kan ik helaas niets aan veranderen.

Ik herken het verhaal "uitschakelen in de stoppenkast" echter schakelden wij nooit alle groepen uit.

Ik kan me zo voorstellen dat er altijd wel minimaal 1 groep aan blijft. In de horeca hebben ze altijd wel een koeling, vriezer, cv-ketel, noodverlichting of misschien wel een alarm installatie.

Ik zou als ik jou was toch daar eens naar kijken

[ Voor 21% gewijzigd door Bud_s op 16-09-2007 12:32 ]

[OverSoft]

De machines komen in sigarettenautomaten en schakelen dus via de groep waar de sigarettenautomaat op hangt. Helaas blijkt die groep bijna altijd geschakeld te zitten.
Daarnaast kan de database altijd wijzigen, alleen gebeurd het over het algemeen (95 van de 100 keer) een maal per dag. De kroeg eigenaar kan zelf ook text op het scherm zetten, en dat kan dus ook 's nachts gebeuren.

edit:
Kan een DB of HD ook corrupt raken als er alleen van gelezen wordt?
(Let wel, de HD is flash in dit geval)

[ Voor 13% gewijzigd door OverSoft op 16-09-2007 14:50 ]

[Verwijderd]

OverSoft schreef op zondag 16 september 2007 @ 14:47:
De machines komen in sigarettenautomaten en schakelen dus via de groep waar de sigarettenautomaat op hangt. Helaas blijkt die groep bijna altijd geschakeld te zitten.
Daarnaast kan de database altijd wijzigen, alleen gebeurd het over het algemeen (95 van de 100 keer) een maal per dag. De kroeg eigenaar kan zelf ook text op het scherm zetten, en dat kan dus ook 's nachts gebeuren.

edit:
Kan een DB of HD ook corrupt raken als er alleen van gelezen wordt?
(Let wel, de HD is flash in dit geval)

Zou eigelijk niet mogen, behalve als die writes worden gecacht.

Maar wat gebeurd er nog meer op die schijf, is die partitie corrupt, moet je die met fsck fixen ? Wat gebruik je als filesystem ext3 ?

[Koffie]

BarthezZ schreef op vrijdag 14 september 2007 @ 10:53:
Ben ik de enige die het zeer raar vindt dat het als normaal wordt beschouwdt om pc's gewoon van de stroom af te sluiten? Ik denk dat dat zeker de levensduur van je hd's nogal verkort, en verder is het niet alleen voor MySQL software ronduit slecht...

Even los van software corruptie maakt het niets uit.
Ik gok dat dit geen SCSI schijven zijn, dus de vraag is of het relatief vaak aan en uit gaan meer/minder slijtage oplevertd dan 24/7 draaien.
Door in 1 keer de stekker eruit te trekken heeft een HDD iig geen last van - park.exe is al jaren niet meer nodig

[Hmzaniac]

Je hebt het over 500 locaties, is het zowel budget- als managementwise dan niet veel beter om 1 of 2 servers te colocaten en vervolgens je machines op locatie via VPN/SSH met een centrale MySQL server te laten verbinden?

Het bespaart je de rotzooi met kapotte databases, je kan 1 centrale backup doen ipv alle machines langs te gaan en mocht er iets doorbranden is het een kwestie van de hardware vervangen, herinstalleren en klaar.

[ Voor 13% gewijzigd door Hmzaniac op 17-09-2007 13:08 ]

[OverSoft]

Hmzaniac schreef op maandag 17 september 2007 @ 13:07:
Je hebt het over 500 locaties, is het zowel budget- als managementwise dan niet veel beter om 1 of 2 servers te colocaten en vervolgens je machines op locatie via VPN/SSH met een centrale MySQL server te laten verbinden?

Het bespaart je de rotzooi met kapotte databases, je kan 1 centrale backup doen ipv alle machines langs te gaan en mocht er iets doorbranden is het een kwestie van de hardware vervangen, herinstalleren en klaar.

De locaties hangen via UMTS aan de servers (die al colocated zijn uiteraard). Het grootste probleem met UMTS is de prijs. Dataverkeer kost geld en dit moet tot een minimum beperkt worden. (Er wordt op z'n minst iedere 20 seconde contact gezocht met de database).
Installatie en vervanging is allemaal al geregeld (met harddisk cloners).

[BarthezZ]

Koffie schreef op maandag 17 september 2007 @ 11:04:
[...]

Even los van software corruptie maakt het niets uit.
Ik gok dat dit geen SCSI schijven zijn, dus de vraag is of het relatief vaak aan en uit gaan meer/minder slijtage oplevertd dan 24/7 draaien.
Door in 1 keer de stekker eruit te trekken heeft een HDD iig geen last van - park.exe is al jaren niet meer nodig

Nog verder offtopic gaand:
Die dingen zijn toch gemaakt om 24/7 te draaien?
En ter bijvoorbeeld, bij de laatste power failure binnen redbus is toch ook behoorlijk wat hardware gesneuveld bij verscheindene partijen, dus het lijkt me dat dat niet zo heel rpettig is vor die servers

[axis]

BarthezZ schreef op maandag 17 september 2007 @ 14:56:
[...]


Nog verder offtopic gaand:
Die dingen zijn toch gemaakt om 24/7 te draaien?
En ter bijvoorbeeld, bij de laatste power failure binnen redbus is toch ook behoorlijk wat hardware gesneuveld bij verscheindene partijen, dus het lijkt me dat dat niet zo heel rpettig is vor die servers

Topic is een maandje oud, maar ik reageer toch. Al nagedacht over een transactional filesystem als ZFS? Zul je waarschijnlijk wel Solaris willen draaien of FreeBSD 7 (nu nog in pre-release), en dan gooi je alles behalve /boot op ZFS. Volgens het ZFS dev team is ZFS transactional (ext3 en ntfs zijn journaling), waardoor elke write in zijn geheel wordt weggeschreven, of helemaal niet. Zou dus als het goed is op filesystem-niveau niet voor corruptie moeten kunnen zorgen, maar goed, misschien dat je applicaties wel eens op hun bek zouden kunnen gaan.

Zoekt, en gij zult vinden. APC zegt trouwens ook simpele UPSsen te hebben voor rond de 60 piek, lijkt me sterk dat je die nergens in je automaat kwijt kunt