PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Master-Master Replikation nach einem Absturz wieder synchronisieren?



Poison Nuke
29.08.09, 17:06
Hallo,

ich habe heute testweise einen schönen Master-Master Repli Verbund aufgesetzt. Ging an sich soweit gut. Über DNS-Roundrobin werden beide Server angesteuert und sollte einer ausfallen dann leiten die gängigen Browser automatisch auf den anderen um.
Das ganze läuft auf basis von Debian Lenny, Apache2, Php5 und Mysql5.

Die Datenbank läuft derzeit auch schön synchron und die Fileuploads werden über alle 5min laufendes rsync synchron gehalten. Bisher scheint das so problemlos zu funktionieren.

Was ich mich jetzt frage...wenn einer der Server ausfällt, wie bekommt man die erneut synchron? Reicht es da einfach den ausgefallenden Server wieder hochfahren zu lassen und der MySQL synchronisiert sich selbstständig und auf dem nicht ausgefallenen Server muss man dann unter Umständen nur "Stop Slave" und dann "Start Slave" eingeben? Oder wäre, wenn z.B. der zweite Server wegen einem Hardwaredefekt länger offline war, es besser die gesamte Synchro neu zu machen? Also ein neues binary Log erstellen lassen, Datenbank stoppen, Dumpen und halt von vorn?

asi_dkn
30.08.09, 17:47
Wie sich das verhält solltest du umbedingt testen. In der Theorie (auch in der Praxis, zumindest bei mir) ist das folgendermassen. Wenn ich den einen Server herunterfahre und der kurze Zeit später wieder hoch kommt, dauert das einen Moment, dann holt er automatisch das nach was sein Master in der Zwischenzeit so gemacht hat. Auch der andere Server hängt wieder am richtigen Punkt ein und die Replikation läuft einfach weiter.

Aber wie gesagt, du solltest dein Setup und deine Config umbedingt testen und dich auch bei Änderungen vergewissern das alles noch so läuft wie du das erwartest...

Poison Nuke
30.08.09, 20:53
hio thx :)

also mit einem kleinen Testsystem klappte es ohne Probleme...allerdings ist es umständlich da ein produktives System zu simulieren und parallel noch sowas zu machen, daher eher nicht aussagekräftige Ergebnisse.

Ich hab das ganze jetzt einfach auf meinem produktiven Server(n) umgesetzt...wie sagt man so schön, no risk no fun. Trau mich gerade nur noch nicht so recht das zu testen. ...a bissle eigen ist mir das auch schon.


Was ich mich da aber noch frage, bevor ich es versuche:
wie lange versucht der Master der online geblieben ist, eigentlich die Verbindung zum anderen Master wiederherzustellen? Heißt die Einstellung

Connect_Retry: 60

einfach nur das er alle 60sek es erneut probiert, oder das er es nach 60x aufgibt? Nur wie lang wäre dann das Timeout zwischen den Retrys?


Und was ich mich noch frage: wenn der eine eine zeitlang offline war und auf dem anderen Master sagen wir 10MB an binarylog angefallen sind, dann braucht der slave wahrscheinlich ein paar Sekunden eh er die komplette binary log übernommen hat, was passiert dann wenn genau in dem Moment wo er noch nicht auf dem aktuellen Stand ist, er selbst einen UPDATE befehl z.B. bekommt der eine Zelle inkrementiert die noch gar nicht auf dem aktuellsten Stand ist?

ein Szenario das sicherlich schwer zu provozieren ist nur dennoch würde mich interessieren ob da was passieren kann. Gibt es dazu irgendwie eine Seite bei Mysql wo drin steht wie bei solchen Replikationen die Fehler abgesichert werden?

asi_dkn
31.08.09, 18:14
Also das Master-Master Setup bei welchem auf zwei Servern gleichzeitig geschrieben wird ist nicht so einfach zu lösen. Du musst dann um genau solche "Kollisionen" zu vermeiden entweder eine Art Locking Mechanismus haben, oder dann zum Beispiel die id's in Zweierschritten raufzählen lassen. Also Node A beginnt bei 1 und inkrementiert um 2, Node B startet bei 2 und erhöht ebefalls jeweils um 2.

Es gibt da auch noch andere Möglichkeiten mit MySQL Cluster (nicht mit der einfachen Replikation zu verwechseln). Auf jeden Fall wird das Setup dadurch nochmals um einiges komplexer und bedarf wohl auch einiges an Wartung.

Sofern ein Server die Last verarbeiten kann würde ich dir empfehlen auch nur auf einem Server zu arbeiten, und der andere zieht einfach alles nach. Fällt der Master aus, stellst du auf den anderen Host um, und wenn der vorherige Master wie oben ist wartest du bis der wieder alle Änderungen nachgezogen hat und machst ihn dann wieder zum "richtigen" Master.

Poison Nuke
31.08.09, 20:26
die "elegante" Lösung mit MySQL Cluster und mehreren Knoten und virtuellen IPs usw bertreue ich u.a. hier im Rechenzentrum...der größte Cluster hat allein 60 homogene MySQL Speicherknoten.

Aber hier ist jetzt Zielsetzung, ein kostengünstiges HA Setup zu realisieren mit zwei Servern, und zwar so das es auch im Fehlerfalle von alleine weiterläuft. da man keinen Loadbalancer bei zwei Servern einfach so nutzten kann ist DNS Roundrobin und Master-Master IMHO eigentlich das sinnvollste. Das Problem ist ja, wenn nun bei einer einfachen Master-Slave konfig der Master ausfällt, wie schaltet man um? Das müsste ja eigentlich dann über Hearbeat und eine virtuelle IP laufen. Nur bei dem gewünschten Setup sollen beide Server geographisch voneinander getrennt sein, um auch eine Havarie in einem Rechenzentrum ohne Ausfall zu überstehen.

Daher ist leider Master-Master das einzige was überhaupt die Bedingungen erfüllt, oder?


Zumindest das Problem mit den auto_increment wurde in MySQL 5.1 gelöst, da kann man einstellen, bei welchem Wert der Server starten soll und um welchen Wert inkrementiert werden soll. Da man Master-Master ja eh nur mit 2 Servern machen kann, stellt man die auto_increment auf 2.

Nur das Problem ist und bleibt, wenn der andere Master nicht mehr synchron ist durch einen Fehler/absturz und sich erstmal synchronisieren muss und dabei aber schon Updates geschrieben werden die auf vorhandenen Datenbankeinträgen basieren, dann kommt als Ergebnis beim einen Master andere Werte heraus wie beim anderen.

Im schlimmsten Fall, wen ein "UPDATE tbl SET value=value+x" bei einer großen Tabelle gemacht wird, hat man mit einem Schlag vllt ein paar tausend Einträge, die komplett andere Werte haben wie auf dem anderen Server.



praktisch wäre es, wenn MySQL selbst eine Erkennungsmöglichkeit hätte für so einen Fall, das es selbst erkennt, das es in einem Master-Master verbund läuft und das einfach alle Tables automatisch gelockt werden solange nicht alle Updates vom anderen Master geladen sind. Kann zwar vllt dazu führen das die Datenbank ein paar Sekunden "laggt" aber besser als wenn sie asynchron läuft. Oder gibt es vllt sogar schon so eine Funktion oder macht es MySQL gar schon von selbst? Konnte dementsprechendes noch nicht entdecken in der doch zugegebenermaßen recht umfangreichen Doku über Replikationen.

Poison Nuke
01.09.09, 07:38
ich hab gerade was geniales in der Mailinglist von MySQL gefunden:


http://www.maatkit.org/tools.html


das ist genau die Lösung des Problems, angeblich. Es prüft die Konsistenz der Tabellen und vorallem ob die Slaves wirklich ein korrektes Abbild der Master haben und es kann auch einen Slave neustarten und dafür sorgen das beide Master wieder synchron laufen usw.


muss mich nur erstmal einarbeiten aber wenn das Tool wirklich das kann was die Website verspricht dann ist es genau die Lösung für das Problem um das es hier geht.

asi_dkn
01.09.09, 18:57
Sieht auf jeden Fall interessant aus. Eventuell hat ja wer vom Board Erfahrungen damit gemacht?

Poison Nuke
01.09.09, 22:26
lustig ist, das Tool hat angeblich auch seine Macken:

http://www.maatkit.org/doc/mk-table-sync.html#RISKS

ich weiß gerade nicht was besser ist. Das Risiko, das die Tabellen vielleicht nicht 100% synchron sind oder das irgendeiner der dort beschriebenen Bugs auftritt und vllt noch schlimmere Probleme erzeugt (gerade die Bugs im Zusammenhang mit DELETE Argumenten finde ich doch etwas erschreckend)



Was mich gerade eher interessieren könnte:

wo finde ich Erfahrungen und Berichte, welche Fehler bei der Replikation auftreten können? Es gibt soviele Seiten zu Replikation aber nirgendwo konnte ich Erfahrungen finden wie stabil eine Replikation (auch bei einfachen Master-Slave konstrukten) läuft und welche Ursachen Abbrüche hatten).
Vllt würde es reichen derartige Fehlerursachen auszuklammern und dafür sorge tragen das bei unterbrochener Synch nur ein Master weiterläuft und zur Not einfach die Repli komplett neu anstoßen statt sich dann auf eine dritte Tabellensynchronisation zu verlassen die auch wieder ihre Probleme haben könnte (am Ende weiß man ja gar nicht mehr was gerade wohin mit wem synchronisiert)

marce
02.09.09, 07:21
wir nutzen Repliokation nur mit ded. MySQL-Servern oder in "eindeutigen" Master-Slave-Kombinanatioen - also immer so, daß es einen ded. Master gibt, auf den geschrieben wird. Erst wenn der stirbt wird komplett auf den Slave umgeschalten - konfiguriert ist aber immer Master/Master.

Tests mit parallelem Schreiben auf beide Master haben wir gefahren - aber gerade die etwas uneindeutige Art, wie es bei konkurierenden Zugriffen gehandled wird war uns dann doch zu unsicher - und von der Leistung her benötigen wir es noch nicht.

Probleme hatten wir auch mal in dem Fall - es wurden auf beiden Servern quasi-gleichzeitig in einer größeren Aktion Datensätze angelegt, so daß es dann zu gleichen unique-IDs in einem Tabellenfeld kam - wie genau konnten wir hinterher nicht mehr reproduzieren, war wohl eher "Pech" und Zufall... Ergebnis war, daß die Replikation dank eines SQL-Fehlers abgebrochen ist (ja, kann man in der Konfig abstellen, aber konsistent sieht mMn. anders aus) - da der Datensatz aber auch in beiden DBs drin stand konnte die Replikation auch nicht "einfach so" wieder angeworfen werden, wir mussten uns im Endeffekt für ein System/Stand entscheiden und dann die Replikation neu aufsetzen...

nalye
02.09.09, 09:35
Wir haben so etwas Ähnliches mal mit 2 BGP-Borderroutern getestet, ging prima mit ucarp und STONITH

Poison Nuke
02.09.09, 09:53
wir nutzen Repliokation nur mit ded. MySQL-Servern oder in "eindeutigen" Master-Slave-Kombinanatioen - also immer so, daß es einen ded. Master gibt, auf den geschrieben wird. Erst wenn der stirbt wird komplett auf den Slave umgeschalten -

da ist aber das Problem, das du mit virtuellen IPs und Heartbeat arbeiten musst, oder? Kenne zumindest keine andere Lösung für so ein Szenario. Und dabei ist dann eine geographische Redundanz über mehrere Rechenzentren nicht möglich.


Aber irgendwie frag ich mich, wie es überhaupt möglich sein kann, das unterschiedliche UniqueID entstehen? der eine Master erstellt nur ungerade IDs und der andere nur gerade, so dürfte es theoretisch zumindest unmöglich sein das jemals gleiche IDs auf beiden Servern entstehen?




Ergebnis war, daß die Replikation dank eines SQL-Fehlers abgebrochen ist (ja, kann man in der Konfig abstellen, aber konsistent sieht mMn. anders aus

welche Optionen gibt es da genau und gibt es dazu genauere Dokus? Will jetzt nicht das alles einstellen sondern einen Überblick und Verständnis über die bekannten Fehlerursachen bekommen, um das ganze dann vllt sogar schon PHP/system seitig abzufangen.

marce
02.09.09, 10:04
da ist aber das Problem, das du mit virtuellen IPs und Heartbeat arbeiten musst, oder?
Läuft bei uns über einen HW-Loadbalancer, damit ist das erschlagen :-)


Kenne zumindest keine andere Lösung für so ein Szenario. Und dabei ist dann eine geographische Redundanz über mehrere Rechenzentren nicht möglich.
hm, da müsste ich ein wenig forschen und überlegen.

Eine Option, die mir spontan einfällt wäre da was über DNS zu regeln und jeweils eine lokale Datenbank zu haben - wenn dann ein System stirbt die Anfragen einfach auf das andere umleiten per DNS.

HA ist natürlich anders...

Kommt halt auch immer drauf an, was man möchte und braucht...



Aber irgendwie frag ich mich, wie es überhaupt möglich sein kann, das unterschiedliche UniqueID entstehen? der eine Master erstellt nur ungerade IDs und der andere nur gerade, so dürfte es theoretisch zumindest unmöglich sein das jemals gleiche IDs auf beiden Servern entstehen?
im Falle des Falles werden und wurden die IDs durch die Applikation erstellt - und da können wir leider nicht eingreifen.


welche Optionen gibt es da genau und gibt es dazu genauere Dokus? Will jetzt nicht das alles einstellen sondern einen Überblick und Verständnis über die bekannten Fehlerursachen bekommen, um das ganze dann vllt sogar schon PHP/system seitig abzufangen.
http://dev.mysql.com/doc/refman/5.0/en/replication-options-slave.html#sysvar_slave_skip_errors

Poison Nuke
02.09.09, 22:43
danke :)

ich denke ich werde das so handhaben, das ich das einfach laufen lasse und mir noch eine zuverlässige Methode ausdenke, wie ich bei einem Fehlerfall automatisch heraufinden lasse, was los ist (Error in replication, anderer server down, netzwerkfehler ...) und abhängig davon wird dann einer der Server beendet um die Asynchronität so klein wie möglich zu halten und dann muss ich halt manuell ran.

Angeblich soll die Replikation ja doch recht robust sein. Na hoffen wir es mal. Ich hab irgendwie Angst das das Binary Log selbst irgendwie nicht Fehlerabgesichert ist und durch irgendeinen Übertragungsfehler dort was falsches übermittelt wird oder so.

Am besten ich installiere einfach mal das maatkit bei Gelegenheit und schaue ob man diesen "dry mode" so durchlaufe lassen kann, das er eben nur prüft ob die Tabellen synchron sind und mehr nicht und wenn es nicht der Fall ist, soll eine Email mir zugestellt werden.

Poison Nuke
19.09.09, 10:25
hier mal eine kleiner Zwischenbericht:

letzte Woche gab es das Problem, das aus einem unerfindlichen Grund beide Slaves aufeinmal einen "Duplicate Entry" Fehler meldeten. Die INSERT Aktion die dabei angegeben war, war aber def. fehlerfrei. D.h. das PHP Script hat vor dem Einfügen geprüft ob der Eintrag vorhanden ist und erst wenn er nicht vorhanden ist wird er erzeugt. Und selbst wenn der Eintrag vorhanden ist, MySQL gibt den Fehler direkt zurück ohne was auszuführen. D.h. es ist eindeutig so gewesen, das es zu einem Bug kam und das ist auch so bestätigt im Internet, das selbst Version 5 noch bei der Replikation Probleme mit Duplicate Entrys hat.

der einzige Workaround ist,


my.cnf

[mysqld]
slave-skip-errors=1062

der Code steht für Duplicate Entry Error.




weiterhin war dann durch ein sterbendes Netzteil die Sicherrung von dem Rack geflogen wo beide Server stehen...toll.
Nur sie haben es beide nicht geschafft wieder zu replizieren. Es kam einfach zu einem Verbindungsfehler. (ERRNO 2013 - Lost connection) Konnte aber auch mit Hilfe von Dr. Google nix weiterführendes finden wie man die verbindung neu herstellt. Hab dann einfach beide Server gestoppt. Von einem einen neuen Dump erstellt und dann die Replikation komplett von vorn gestartet.



Hat einer von euch error 2013 erfolgreich "bekämpft"? Weil wäre ja schon praktisch wenn nach einem Systemabsturz ich nicht jedesmal vor Ort sein muss um die Replikation neu zu starten, das kann ja auch nicht Sinn und Zweck einer Master-Master Repli sein.