Sollte die mysql-Replikation nicht mehr laufen, gibt es zwei Wege, den Fehler zu beheben:
- den Fehler überspringen
- ein vernünftiger Rebuild
Den Fehler zu überspringen kann in manchen Fällen schon ausreichend sein. Das kann z.B. der Fall sein, wenn zeitgleich auf beiden Servern ein identisches INSERT ausgeführt wird.
Fehler übersrpingen
Login into mysql as root:
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SHOW SLAVE STATUS \G
Damit ist der letzte Fehler übersprungen. Wenn SHOW SLAVE STATUS \G
keine Fehler mehr anzeigt, läuft die Replikation wieder. Falls doch, lässt sich die Replikation auch relativ einfach wieder neu aufsetzen (Rebuild). Ich empfehle aber auch, sich damit etwas genauer zu befassen: MySQL Skip Duplicate Replication Errors.
Rebuild
Alle Zugriffe durch Applikationen dürfen ab jetzt nur noch auf dem funktionieren Master-Server erfolgen.
Auf diesem erstellen wir einen Dump, der dann auf den defekten Server kopiert wird:
$ mysqldump --add-drop-table --master-data -uUSER -p PASSWORD --all-databases > dump.sql
Auf dem anderen Server muss zunächst der slave angehalten werden
STOP SLAVE;
QUIT;
ehe der Dump durch
mysql -uUSER -p PASSWORD > dump.sql
importiert werden kann.
Durch
SHOW SLAVE STATUS\G
wird überprüft, ob der Server wieder läuft. Entscheidend sind
Slave_IO_Running: Yes
.
Slave_SQL_Running: Yes
Ab jetzt läuft wieder alles von “funktionierender Server” -> “anderer Server”. Jetzt muss das ganze noch für die andere Richtung eingerichtet werden.
Wir sind noch immer auf dem ehemals nicht funktionierenden Server:
flush tables with read lock;
show master status;
*************************** 1. row ***************************
File: mysql-bin.000163
Position: 381821321
Binlog_Do_DB:
Binlog_Ignore_DB: mysql
1 row in set (0.05 sec)
Auf dem anderen Server werden für die Replikation neu gesetzt:
STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000163', MASTER_LOG_POS=381821321;
START SLAVE;
Auf dem zweiten Server müssen nur noch die locks aufgehoben werden und alles läuft wieder wie gehabt.
UNLOCK TABLES;
Die Replikation läuft zwar wieder, ein Monitoring des ganzen wäre aber nicht das schlechteste, oder? 😉
Ein kleiner Fehler ist drin: Es muss beim Wiederherstellen des Dumps natürlich “mysql -uUSER -p PASSWORD < dump.sql" heißen, !
Hi,
schöner Eintrag, aber:
“ehe der Dump durch
mysql -uUSER -p PASSWORD > dump.sql
importiert werden kann.”
müsste doch sicher
mysql -uUSER -p PASSWORD < dump.sql
heißen, oder?
LG.
Genau das habe ich gerade auch geschrieben. Sollte hier wirklich geändert werden!
could you please specify which steps are done on master server & which on slave server – thank you
This post describes the restart of a master-master, and not a master-slave setup.
To restart a master-slave-replication see http://blog.schaal-24.de/?p=671&lang=en
Pingback: mysql-Replikation mit Nagios überwachen | florian @it