Rebuild Slave-DB & Replication
Da der Befehl mysqldump die Tables locked, ist es nicht notwendig, dass auf der Master Datenbank kein Traffic ist. Durch --master-data wird im Befehl mysqldump die richtige Position zum Einsetzen der Replication auf dem Slave Server hinterlegt.
Falls die Festplatte des Slaves voll ist, dann bitte die Anleitung auf dieser Seite weiter unten - "Slave Platte Voll" betrachten.
- Auf Slave-Server anmelden
mysql -uUSER -pPWD
STOP SLAVE;
RESET SLAVE;
QUIT;
Anmeldung in MySQL mit Credentials USER und PWD, danach Slave stoppen und MySQL wieder verlassen. Dafür folgende Befehle nutzen:
MySQL Server mit
service mysqld restart
neu starten.
- 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
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.
- MySQL-Dump vom Master Datenbankserver auf den Slave Datenbank Server kopieren.
Verwende hierfür das Tool deiner Wahl: Kommandozeile (scp), WinSCP, ... - 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>;
- 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 ParameterMASTER_LOG_FILE
undMASTER_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.
- In der mysqldump Datei ganz am Anfang finden wir im Kommentarblock eine Zeile, die folgendermaßen aussieht:
- 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;
SHOW SLAVE STATUS\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
- 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.
Slave Platte Voll
Es gibt diverse Gründe, warum die Slave Platte voll-laufen kann.
tmp Verzeichnis ist voll
Hintergrund
Jedes Mal, wenn eine Query eine tmp Tabelle anlegt, wird dies in das temp Verzeichnis, üblicherweise /tmp geschrieben. Dies geschieht dann, wenn die maximale Größe der maximale "in Memory" Tabellengröße überschritten wird.Dies wird mit den Variablen tmp_table_size
sowie max_heap_table_size
definiert.
Siehe auch https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html für mehr Information.
Die Tabellen in /tmp werden solange gehalten, bis die jeweilige DB-Verbindung geschlossen wird, oder ein DROP TEMPORARY TABLE aufgerufen wird. Falls das /tmp Verzeichnis voll-läuft, ist zu vermuten dass ein DROP TEMPORARY TABLE irgendwo fehlt. Dies kann durchaus auch durch Kunden-Abfragen an die DB geschehen.
Aushilfe auf permanente Weise schafft hier die Installation von tmpwatch
Hinweise:
- Auf CentOS 6 wird das /tmp Verzeichnis dann standardmäßig dann von Dateien auf den kein Zugriff > 10 Tage nicht erfolgt ist befreit
- Unter Umständen reicht dies nicht aus
- Auf CentOS 7 wird das /tmp Verzeichnis dann standardmäßig dann von Dateien auf den kein Zugriff > 1 Tag nicht erfolgt ist befreit
Vorgehensweise
- Es muss erstmal Platz geschaffen werden. Einfach gnadenlos alles aus /tmp löschen.
- Falls dies genügend Platz verschafft, dann erstmal den mysql Dienst neustarten: service mysql restart
- Falls dann genug Platz vorhanden ist (mindestens ca. 20%), dann mit Wiederherstellung der Replikation wie Oben beschrieben fortfahren.
Jede Menge "relay Logs" vorhanden
MySQL schreibt die Relay-Logs vom Master erstmal in eine Datei. Wenn die Replikation erstmal gebrochen ist, aber der Slave Relay Prozess weiter arbeitet, dann wird die Platte durch Relay Logs befüllt.
Dieser Schritt sollte im jeden Fall durchgeführt werden, insbesondere vor dem nächsten (ibdata zu groß), um Platz zu schaffen.
Vorgehensweise
Die Dateien für die Datenbank befinden sich in der Regel in /var/lib/mysql
Falls nicht, dann ist der Speicherort in /etc/my.cnf zu finden. Der Entsprechende Eintrag ist datadir=(pfad)
- Alle Relay Logs löschen:
cd /var/lib/mysql
rm mysqld-relay-bin* - MySQL Dienst neustarten
service mysqld restart - Falls genug Platz vorhanden (mind. 20%) dann mit der Wiederherstellung des Slaves fortfahren wie oben beschrieben.
ibdata Dateien auf den Slave "Riesen-Groß"
Die Dateien für die Datenbank befinden sich in der Regel in /var/lib/mysql
Vorgehensweise
- Falls nicht weniger als 100% Platte durch die Schritte Oben erreicht werden kann:
- Den MySQL Dienst aus der Autostart austragen:
service mysqld disable - Den Rechner neu starten mit:
reboot
- Den MySQL Dienst aus der Autostart austragen:
- Geht nur wenn weniger als 100% Platte erreicht ist (ggf. nach Reboot oben) dann:
- Auf den mysql Server anmelden:
mysql -u root -p - Alle JTEL Datenbanken droppen:
SET FOREIGN_KEY_CHECKS=0;
DROP DATABASE JTELLog;
DROP DATABASE JTELStats;
DROP DATABASE JTELWeb;
SET FOREIGN_KEY_CHECKS=1; - Mit CTRL+C wieder auf die Kommandozeile, und dann:
service mysqld stop
rm /var/lib/mysql/ibdata*
rm /var/lib/mysql/ib_log_* - MySql Server starten, und ggf. wieder enablen
service mysqld start
service mysqld enable - Plattenplatz prüfen, und mit Slave Wiederherstellung wie oben beschrieben fortfahren.
- Auf den mysql Server anmelden:
Trotzdem kein Plattenplatz > 20% Frei
In diesen Fall ist der Slave einfach zu klein. Die Festplatte muss erweitert werden (wie bei Erweiterung der Rolle STORE, nur auf das Logical Volume anwenden auf den die Daten der MySQL Datenbank sich befinden). Dann die Schritte wieder durchführen, bei Platte zu Klein, dann Slave wieder herstellen wie Oben beschrieben.
Oder der Slave wird komplett neu gebaut mit einer größeren Platte.