Versions Compared

Old Version 17

changes.mady.by.user jtel Support

Saved on

compared with

New Version 18

changes.mady.by.user jtel Support

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Sv translation
languageen

Guter Server ermittelnDetermine good server

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).

If there is a HAPROXY, then remove the servers on the broken master side from the distribution (also the slave on this side).


On BOTH Auf BEIDE Master Server


Translations Ignore


Code Block
STOP SLAVE;

Auf den KAPUTTEN Master Server eine Sicherung der guten Master DB anfertigen


Make a backup of the good Master DB on the BROKEN Master Server

Previous to 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 As of release 3.12 bitte folgenden Befehl nutzenplease use the following command:

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 Versions 3.12, 3.14 und and 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.

If someone logs on to the portal while the dump is being pulled, it will go wrong. Enclosed an SQL query. If the time changes after the query is executed, a login has taken place.

If this happens, the dump has to be pulled again and in the meantime it has to be permanently checked if a login has taken place. Only if this is not the case, the dump can be replicated error-free to the slaveWenn 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 versions 3.11 und abwärts sowie Version and below and version 3.16 besteht dieses Problem nicht.this problem does not exist.


On the BROKEN master server, reset the slave and restore the backupAuf den KAPUTTEN Master Server, den Slave resetten, und Sicherung einspielen

Translations Ignore


Code Block
RESET SLAVE; 
SOURCE master.sql;




Auf den KAPUTTEN Master Server aus den On the BROKEN master server, determine the master position from the master.sql die Master Position ermitteln, und dann den Slave reinitialisieren, and then reinitialize the slave


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>; 
START SLAVE;




Auf den KAPUTTEN Master Server den Slave PrüfenOn the BROKEN master server Check the slave

Translations Ignore


Code Block
SHOW SLAVE STATUS\G
Erst wenn alles OK, und die Replikation aktuell ist, dann weitermachen.



Only if everything is OK, and the replication is up to date, then continue.
The status can be monitored with the following commandDen 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 notierenOn the BROKEN master server lock all tables and note master position

Translations Ignore


Code Block
FLUSH TABLES WITH READ LOCK; 
SHOW MASTER STATUS;



Die Positionen von The positions of SHOW MASTER STATUS werden im folgenden Kommando benötigt.are required in the following command.

On the GOOD master server, reposition and start the replication. 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>;
START SLAVE;




Auf den KAPUTTEN Master Server die Tabellen Locks aufhebenUnlock the tables on the BROKEN master server

Translations Ignore


Code Block
UNLOCK TABLES;




Master und Check Masters and Slaves Prüfen

On all servers now Auf allen Servern nun 

Translations Ignore


Code Block
SHOW SLAVE STATUS\G
und prüfen dass alles richtig läuft



and check that everything is running smoothly

It is usually not necessary to restore the slaves attached to both masters. If it is, they can be re-initialized with the normal slave recovery procedureEs 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.

Sv translation
languagede

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


Translations Ignore


Code Block
STOP SLAVE;


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

Translations Ignore


Code Block
RESET SLAVE; 
SOURCE master.sql;





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>; 
START SLAVE;




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; 
SHOW MASTER STATUS;



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>;
START SLAVE;




Auf den KAPUTTEN Master Server die Tabellen Locks aufheben

Translations Ignore


Code Block
UNLOCK TABLES;



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.