Wer eine MySQL-Datenbank spiegelt (Master/Slave), muss die Replikation öfters kontrollieren, denn im laufenden Betrieb können sich Fehler einschleichen und die Replikation wird gestoppt. Wer denn beispielsweise eine Webseite per Load Balancer gespiegelt hat, wird seinen Kunden nicht auf jedem Frontend-Server die gleichen Daten präsentieren. Aus diesem Grund muss die Replikation überwacht werden. Heute möchten wir uns mit der prinzipiellen Überwachung auseinandersetzen. Denn nur wer weiß, was MySQL für Fehler erzeugen kann und wie man diese per Hand bereinigt, kann sich dann Gedanken um eine Automation oder Überwachung machen.
Dass ein Fehler bei der MySQL-Replikation vorliegt, kann beispielsweise über das Syslog („/var/lib/mysql/mysqld.log“) darauf stoßen. Oder die MySQL-Konsole meldet via SLAVE STATUS einen Fehler.
So ist prinzipiell bei einem MySQL-Replikations-Fehler vorzugehen:
- Anmelden an der MySQL-Konsole mittels „mysql -u root –p“ [RETURN], Eingabe des Passwortes.
- Abfrage des Replikation-Status mit „SHOW SLAVE STATUS G”. Das “G” steht für die formatierte Ausgabe.
Wenn der Slave einen Fehler meldet, ist dieser sowie das SQL-Statement, welches den Fehler verursacht hat, in der Statusmeldung ersichtlich. Nun ist zu prüfen, wie verfahren werden soll. Eventuell soll nur der fehlerverursachende Befehl übersprungen werden. Dann ist wie folgt zu verfahren:
- Den Slave stoppen mit: STOP SLAVE;
- Den Befehl überspringen mit SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
- Den Slave wieder zur Replikation anfahren mit : START SLAVE;
- Den Replikationsprozess überwachen mit SHOW SLAVE STATUS G
- Die MySQL-Konsole beenden mit: quit;
Erkennen, dass die MySQL-Replikation fehlerhaft ist
Über die MySQL-Konsolen-Befehl „SHOW SLAVE STATUS G“ erfährt man alles wissenswerte über den Prozess. Neben den Parameter „Last_Error“ und „Last_Errno“ sollte auf die Parameter „Slave_IO_Running“ und „Slave_SQL_Running“ geachtet werden.. Die Parameter „Last_error“ enthalten eine Fehlernummer und gegebenenfalls ein SQL-Kommando, das einen Fehler verursacht. Aus den Parametern „Slave […] Running“ erfährt man, ob die Replikation noch läuft. Wenn einer der beiden Parameter auf „NO“ steht (oft nur Slave_SQL_Running), dann muss man sich um die Fehlerbehebung kümmern.
Gerne gesehene Fehler einer MySQL-Replikation
Wer eine Datenbank repliziert und nicht nur auf dem Master, sondern auch auf dem Slave mit den Tabellen arbeitet, kann sehr schnell zu folgendem INSERT-Problem kommen. Dann nämlich, wenn der Master Datensätze in eine Tabelle einfügt und ein oder die Slaves in diese (replizierte) Tabelle ebenfalls Datensätze hinzufügen. Selbst wenn die laufende IDs über die Tabelle per „AUTO_INCREMENT“ hinzufügt, tappt man sehr schnell in die Falle und erzeugt einen doppelten Schlüssel (Duplicated Key). Denn die INSERT-Befehl auf dem Master, der vielleicht ohne explizite Angabe einer Datensatz-ID ausgeführt wurde („AUTO_INCREMENT“), wird über das Binär-Log auf dem Slave explizit, also genau mit der ID ausgeführt, die auch auf dem Master eingefügt wurde. Fügt jetzt auch noch der Slave in diese Tabelle auf dem Slave Datensätze hinzu, kann die ID bereits vergeben sein und die MySQL-Replikation schlägt fehl. Das Verhalten ist klar, denn wenn die Replikation die Vergabe der ID dem Slave überlassen würde, könnte so der Spiegel auseinanderlaufen.