Guter Server ermitteln Zuerst muss entschieden werden, welcher der "guter" Server ist. Wenn HAPROXY im Betrieb ist, dann ist der guter Master der auf den die Daten derzeit geschrieben werden.
HAPROXY umstellen Falls es ein HAPROXY gibt, dann die Server auf der Kaputten Master Seite aus der Verteilung herausnehmen (auch den Slave auf dieser Seite).
Auf BEIDE Master Server
Auf den KAPUTTEN Master Server eine Sicherung der guten Master DB anfertigen Vor Release 3.12: | Translations Ignore |
|---|
| Code Block |
|---|
mysqldump -h<GOOD_MASTER> -uroot -p<PASSWORD> --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > master.sql |
|
Ab Release 3.12 bitte folgenden Befehl nutzen: | Translations Ignore |
|---|
| Code Block |
|---|
mysqldump -h<GOOD_MASTER> -uroot -p<PASSWORD> --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > master.sql |
|
| Warning |
|---|
In Versionen 3.12, 3.14 und 3.15: Wenn sich jemand am Portal Anmeldet, während der Dump gezogen wird, geht das schief. Anbei eine SQL abfrage. Wenn die Zeit sich nach dem ausführen der Abfrage ändert, hat ein Login stattgefunden. Wenn das passiert, muss der Dump erneut gezogen werden und währenddessen dauerhaft geprüft werden, ob ein Login stattgefunden hat. Nur wenn dem nicht so ist, kann man den Dump Fehlerfrei auf den Slave replizieren. SELECT Max(dtAcdLoggedIn) FROM Users; In Versionen 3.11 und abwärts sowie Version 3.16 besteht dieses Problem nicht. |
Auf den KAPUTTEN Master Server, den Slave resetten, und Sicherung einspielen
Auf den KAPUTTEN Master Server aus den master.sql die Master Position ermitteln, und dann den Slave reinitialisieren
| Translations Ignore |
|---|
| Code Block |
|---|
CHANGE MASTER TO MASTER_HOST = '<GOOD_MASTER>', MASTER_USER = 'repl', MASTER_PASSWORD = '<PASSWORD>', MASTER_LOG_FILE='<NAME_LOGFILE>', MASTER_LOG_POS=<POSITION_LOGFILE>; |
|
Auf den KAPUTTEN Master Server den Slave Prüfen | Translations Ignore |
|---|
| Code Block |
|---|
SHOW SLAVE STATUS\G |
|
Erst wenn alles OK, und die Replikation aktuell ist, dann weitermachen. Den Status kann man mit folgenden Befehl beobachten:
| Translations Ignore |
|---|
| Code Block |
|---|
watch 'mysql -u root -p<PASSWORD> -e "SHOW SLAVE STATUS\G" 2>/dev/null' |
|
Auf den KAPUTTEN Master Server alle Tabellen locken und Master Position notieren | Translations Ignore |
|---|
| Code Block |
|---|
FLUSH TABLES WITH READ LOCK; |
|
Die Positionen von SHOW MASTER STATUS werden im folgenden Kommando benötigt. Auf den GUTEN Master Server die Replikation neu positionieren und starten | Translations Ignore |
|---|
| Code Block |
|---|
CHANGE MASTER TO MASTER_HOST = '<SECOND_MASTER>', MASTER_USER = 'repl', MASTER_PASSWORD = '<PASSWORD>', MASTER_LOG_FILE='<NAME_LOGFILE>', MASTER_LOG_POS=<POSITION_LOGFILE>; |
|
Auf den KAPUTTEN Master Server die Tabellen Locks aufheben
Master und Slaves Prüfen Auf allen Servern nun | Translations Ignore |
|---|
| Code Block |
|---|
SHOW SLAVE STATUS\G |
|
und prüfen dass alles richtig läuft Es ist normalerweise nicht nötig, die Slaves die an beide Master hängen ebenfalls zu wiederherstellen. Wenn doch, können diese mit der normalen Prozedur für das Wiederherstellen des Slaves neu initialisiert werden. | 