MySQL effektiv vor Stromausfall schützen

[Dormant]

Servus,

ich hatte jetzt in den letzten Wochen zwei mal einen Ausfall. Einmal war der Strom weg - beide Stromkreise - und einmal hats den ESX zerrissen.
Auf der Kiste laufen Maschinen mit MySQL (Debian 7) und MSSQL. Beim Hochfahren sind dann bei MySQL immer die Datenbanken korrupt und ich muss einen myisamcheck drüber laufen lassen. Das kann dann je nach DB mehrere Stunden dauern. Bei MSSQL läuft einfach alles weiter (Transactionlog). Ich bin jetzt nicht der MySQL Guru, mache eher die Schicht drüber, aber gibts da bei MySQL was vergleichbares. Eventuell auch eine andere DB Software die da besser mit umgehen kann?

Merci für jegliche Vorschläge!

[dirk11]

Wie wär's mit 'ner USV!?

[Dormant]

Beim Stromausfall gar ein Stromkreis USV-gestützt. Da war das ganze RZ down, beim HW-Fehler am ESX hätte mir die USV dann auch nicht geholfen.

[nudgegoonies]

MySQL hat auch ein LOG. Das ist in /var/lib/mysql. Nähere Infos musst Du von einem MySQL Guru erfahren. Aber ich denke, dass ist nicht das Problem. Wenn ich ESX höre dann denke ich sofort an die Schreibstrategien für die VM Images. Da kann das Gastbetriebssystem Journaling, Write-Through oder gar o_direct machen, wenn der Host völlig wegcrasht, und dort mit Writethrough gecached wird oder IO Transaktionen nicht passend durchreicht, dann können die VM Festplattenimages, und so auch die Datenbanken, ordentlich Schaden nehmen.

[dirk11]

Beim Stromausfall gar ein Stromkreis USV-gestützt. Da war das ganze RZ down, beim HW-Fehler am ESX hätte mir die USV dann auch nicht geholfen.

Es war auch nicht von einem HW-Fehler die Rede, sondern von einem Stromausfall. Und bei einem Stromausfall schützt eine (funktionierende) USV nunmal am besten, das sollte wohl unstrittig sein. Eine USV ist in so einem Fall auch nur begrenzt dafür da, den Betrieb aufrechtzuerhalten. Primär ist sie dazu gedacht, das Endgerät geordnet und korrekt herunterzufahren, damit eben solche Datenbank-Fehler nicht auftreten.

[4A4B]

Beim Hochfahren sind dann bei MySQL immer die Datenbanken korrupt und ich muss einen myisamcheck drüber laufen lassen.

Also wird als Storage Engine MyISAM verwendet

Das kann dann je nach DB mehrere Stunden dauern. Bei MSSQL läuft einfach alles weiter (Transactionlog). Ich bin jetzt nicht der MySQL Guru, mache eher die Schicht drüber, aber gibts da bei MySQL was vergleichbares. Eventuell auch eine andere DB Software die da besser mit umgehen kann?

Vielleicht reicht eine Umstellung auf die Storage Engine InnoDB - diese unterstützt auch Transaktionen:

In Fällen von Betriebssystemabstürzen oder Stromausfällen können wir davon ausgehen, dass die Festplattendaten von MySQL nach einem Neustart wieder verfügbar sind. Die InnoDB-Datendateien enthalten unter Umständen aufgrund des Absturzes keine konsistenten Daten, aber InnoDB liest seine Logs aus und findet darin die Liste der anhängigen abgeschlossenen und nicht abgeschlossenen Transaktionen, die noch nicht in die Datendateien geschrieben wurden. InnoDB führt für die nicht abgeschlossenen Transaktionen automatisch einen Rollback aus, die abgeschlossenen Transaktionen hingegen werden in die Datendateien geschrieben.

Quelle: http://dev.mysql.com/doc/refman/5.1/de/ ... ample.html

[Simmel]

Servus,

ich hatte jetzt in den letzten Wochen zwei mal einen Ausfall. Einmal war der Strom weg - beide Stromkreise - und einmal hats den ESX zerrissen.
Auf der Kiste laufen Maschinen mit MySQL (Debian 7) und MSSQL. Beim Hochfahren sind dann bei MySQL immer die Datenbanken korrupt und ich muss einen myisamcheck drüber laufen lassen. Das kann dann je nach DB mehrere Stunden dauern. Bei MSSQL läuft einfach alles weiter (Transactionlog). Ich bin jetzt nicht der MySQL Guru, mache eher die Schicht drüber, aber gibts da bei MySQL was vergleichbares. Eventuell auch eine andere DB Software die da besser mit umgehen kann?

Merci für jegliche Vorschläge!

1. USV unbedingt! Das ist das wichtigste wenn dein Housing keine separaten Stromkreise mit Anschluss an einen Diesel haben.
2. Wie erwähnt InnoDB, nutze ich auch. Hat aber ebenfalls Nachteile. Die DB-Optimierung wird zum spannenden Erlebnis (zumindest wenn man das nicht täglich gemacht wird).
3. Master-Master oder Master-Slave aufsetzen, je nachdem wofür die DB's Verwendung finden. Das Setup ist recht einfach, muss aber bewacht werden (falls die Verbindung aufbricht). Das hat auch den Vorteil das man eine konsistene DB-Sicherung machen kann, oder aber wenn der Master down ist auf den Slave umschwenkt. Allerdings ist da ein Master-Master Setup def. besser geeignet. Geht aber nur wenn ein Master gerade und der andere ungerade ID's verwendet. Das kann man also nicht blind auf- und einsetzen.

Dennoch bin ich der Meinung das du deinem Cheffe (wenns denn im Büro steht das Zeug), eine kleine USV aus dem Kreuz leierst. Die bieten so für 10-15 Minuten Strom und sollte dieser wegbleiben, dann stößt er das System an, um es herunterzufahren und zwar fehlerfrei!

[Dormant]

Hallo zusammen und danke für die zahlreichen Antworten!
Also, das RZ hat zwei Stromkreise, einer davon mit Dieselgeneratoren gestützt. Leider kam es da zu einem technischen Defekt und das komplette RZ war weg
Eine USV in jeder Rack macht da wirtschaftlich nicht viel Sinn und es ist auch nicht davon auszugehen das das noch mal passiert - hoffentlich.

InnoDB war auch schon häufiger im Gespräch, da ist das Recovery aber im Problemfall auch nicht wirklich schöner. Das Binlog kommt leider auch nicht infrage da zu viel Schreibzugriffe auf die DB erfolgen und die Auslagerung in Ramdisk dann auch keinen Sinn macht

Bei den Datenbanken auf denen nicht im Sekundentakt geschrieben wird wäre vielleicht ein Replika mit GlusterFS o.ä. vielleicht sinnvoll? Habt ihr da Erfahrungen?
MySQL Replication hatten wir auch mal, ist aber irgendwann am Monitoring gescheitert, vielleicht sollten wir da noch mal schauen ob Nagios was tolles zu bieten hat bzgl. der Statusüberwachung.

Vielen Dank nochmal!