Page History

...

1. Auf Slave-Server anmelden
   • Anmeldung in MySQL mit Credentials USER und PWD, danach Slave stoppen und MySQL wieder verlassen. Dafür folgende Befehle nutzen:

     • mysql -uUSER -pPWD

     • STOP SLAVE;

     • RESET SLAVE;

     • QUIT;

   • MySQL Server mit service mysqld restart neu starten.

2. Einen MySQL-Dump schreiben. Auf dem Master-Server nun folgenden Schritte durchführen. Dazu ein Backup-Verzeichnis anlegen und in selbiges wechseln. Der MySQL-Dumb wird nun mit dem folgenden Befehl ausgeführt:

   • mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql

     Ab Release 3.12 wird folgender Befehl benötigt:

   • mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql


   Hierzu eine kurze Erklärung:

   • <Name LogFile> und <Position LogFile> werden durch --master-data im Dump gespeichert.
   • nur die JTEL-Datenbanken verwenden '--databases'
   • alle Datenbanken vor Import löschen  '--add-drop-database'
   • alle Tabelle der Datenbanken vor Import löschen '--add-drop-table'
   • alle Routinen und Prozeduren im Dump implementieren '--events --routines'
   • Zusätzlich kann noch der Parameter --default_character_set utf8 verwendet werden
     
     

   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.

   
   

3. MySQL-Dump vom Master Datenbankserver auf den Slave Datenbank Server kopieren.
   Verwende hierfür das Tool deiner Wahl: Kommandozeile (scp), WinSCP, ...
   
   
4. Wir wechseln wieder auf den Slave-Server und importieren nun den mysqldump.

   • mysql -uUSER -pPWD (Nun sind wir in MySQL)

   • SET foreign_key_checks = 0;

   • drop database JTELLog;

   • drop database JTELStats;

   • drop database JTELWeb;

   • drop database JTELStats2;

   • SET foreign_key_checks = 1;

   • source <filename>;
 

5. Wir ermitteln nun die Replikationsparameter, da wir sie gleich benötigen werden:
   • In der mysqldump Datei ganz am Anfang finden wir im Kommentarblock eine Zeile, die folgendermaßen aussieht: CHANGE MASTER TO MASTER_LOG_FILE='binlog.000872', MASTER_LOG_POS=11940974; Die Parameter MASTER_LOG_FILE und MASTER_LOG_POS muss man sich merken.
   • Wir brauchen den Namen oder die IP vom Master DB Server
   • Wir brauchen das Passwort des Benutzers repl auf dem Master DB Server. Dies entspricht eigentlich immer dem Passwort des Benutzers root - man kann es am einfachsten ausprobieren, in dem man sich vom Slave auf dem Master mit diesem Passwort anmeldet: mysql -h <masterIP> -u repl -p<Passwort> - wenn das Funktioniert, weiss man bescheid.
6. Jetzt befindet sich auf dem Slave server schon eine konsistente, einigermaßen neuer Stand der Daten. Es ist nun nur noch erforderlich die Replikation neu zu konfigurieren. Dazu folgende Befehle:

   • mysql -uUSER -pPWD

   • CHANGE MASTER TO MASTER_HOST='<name oder IP des master servers>',MASTER_USER='repl',MASTER_PASSWORD='<passwort>',MASTER_LOG_FILE='<Name LogFile>', MASTER_LOG_POS=<Position LogFile>;
     Hier sind alle Parameter mit denen aus Schritt 5 zu ersetzen.

   • START SLAVE;

   Nun überprüfen wir den Slave Status (ein paar mal) mit dem Befehl:

   • SHOW SLAVE STATUS\G

   und erwarten folgendes Ergebnis:

   • Slave_IO_Running: Yes

   • Slave_SQL_Running: Yes

   Damit läuft die Replikation nun wieder. Der Name des Logfiles und die Position sollten zeitnah ziemlich genau denen des show master status auf der Master-Datenbank entsprechen.
   
   
7. Aufräumen von Datenmüll nicht vergessen! D.h. mysqldumps und Verzeichnisse zumindest auf dem Slave wieder löschen. Auf der Master Datenbank kann ein Backup bleiben, sofern genügend Platz vorhanden ist. 

...