IntroductionThis page describes the process of rebuilding a Master-Master DB & Replication. Since the MySQL Dump command locks the tables, there is no need to create it when there is no traffic on the machine. It can be done during operational hours. With --master-data the command mysqldump stores the correct position for inserting the replication on the slave server. ProcedureDetermine Good MasterIn a system with Master-Master replication, one of the masters is active and processing queries from the other jtel cluster members. This is the server from which the MySQL Dump is taken, since this master has the latest data and is up to date. Info |
---|
Further down in this page, the good master-database and server will be referred to as the GOOD MASTER GOOD SLAVE Further down in this page, the broken server will be referred to as the BROKEN MASTER BROKEN SLAVE |
Haproxy configurationIf there is a HAPROXY, then remove the servers on the BROKEN MASTER side from the distribution (also the BROKEN SLAVE on this side). STOP SLAVELogin to MySQL on both the GOOD MASTER and the BROKEN MASTER to stop the slave SQL. Leave MySQL again afterwards. Use the following commands for this: Code Block |
---|
mysql -uUSER -pPWD
STOP SLAVE;
QUIT; |
Phase 1 - MySQL DumpA MySQL Dump of the GOOD MASTER is now created. Perform the following steps to create a MySQL Dump and save it to the STORE:
Warning |
---|
| The mysqldump command is different, depending on the jtel portal release, as well as the MySQL software release installed on the databases. All different options and how to find out which one to choose is specified below. |
Warning |
---|
title | Master-Master Replication |
---|
| The mysqldump commands on this page can NOT be used to realign a master-slave replication. Visit the following page for that description Role DATA - Simple Master / Slave |
jtel Portal software releaseLog in to the Load Balancer of the cluster and execute the following commands as the jtel user Code Block |
---|
# Find out which software release is installed
cd /srv/jtel/shared/JTELCarrierPortal
git status
# If /srv/jtel/.. does not exist on the load balancer, attempt this
cd /home/jtel/shared/JTELCarrierPortal
git status
# Expected output
release-stable/3.XX |
Create Backup Directory Info |
---|
The following commands are designed to be executed on the load balancer as jtel user The following cd commands depend on the variable JT_DATE_TIME, which is set at the beginning of the next part. If the variable is not set, commands will fail. |
Code Block |
---|
# Create backup directory SLAVE MySQL Dump
JT_DATE_TIME=$(date +%F)
mkdir /srv/jtel/shared/backup/${JT_DATE_TIME}
# If /srv/jtel/.. does not exist on the load balancer, attempt this
JT_DATE_TIME=$(date +%F)
mkdir /home/jtel/shared/backup/${JT_DATE_TIME} |
Create MySQL Dump Warning |
---|
title | CAUTION - CREDENTIALS+IP-Adresses |
---|
| Credentials and IP-Addresses need to be changed before the following mysqldump commands can be executed |
Info |
---|
The following commands are designed to be executed on the load balancer as jtel user |
MySQL Dump - Until jtel Portal release 3.12 Code Block |
---|
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> |
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 |
---|
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/srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_${JT_DATE_TIME}.sql |
Warning |
---|
| Versionen | und | If someone logs on to the portal while the dump is being pulled, it will go wrong. Enclosed a SQL query. If the time changes after executing the query, 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 slave :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 versions 3.11 und abwärts sowie Version and below and 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 |
---|
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. |