In diesem Schritt werden wir einen häufigen Replikationsfehler simulieren und zeigen, wie er behoben werden kann. Dies hilft Ihnen zu verstehen, wie Sie Replikationsprobleme in einer realen Umgebung beheben können.
-
Simulieren eines Fehlers:
Ein häufiger Replikationsfehler tritt auf, wenn der Slave-Server eine Dateninkonsistenz feststellt. Wir simulieren dies, indem wir manuell eine Zeile in die Tabelle test_replication.test_table auf dem Slave-Server einfügen. Dies führt zu einem Konflikt, wenn der Master versucht, die gleiche Zeile zu replizieren.
Melden Sie sich auf dem Slave-Server als Root-Benutzer am MySQL-Server an:
sudo mysql -u root
Fügen Sie eine Zeile in die Tabelle test_replication.test_table ein:
USE test_replication;
INSERT INTO test_table (data) VALUES ('This is an intentionally conflicting record on the slave');
exit
-
Auslösen der Replikation:
Fügen Sie nun eine weitere Zeile in die Tabelle test_replication.test_table auf dem Master-Server ein:
sudo mysql -u root
USE test_replication;
INSERT INTO test_table (data) VALUES ('This is a new record from master');
exit
Diese Einfügung auf dem Master löst die Replikation auf den Slave aus. Da wir jedoch manuell eine konfliktive Zeile auf dem Slave eingefügt haben, wird der Replikationsprozess wahrscheinlich einen Fehler encounter.
-
Überprüfen des Slave-Status:
Melden Sie sich auf dem Slave-Server als Root-Benutzer am MySQL-Server an:
sudo mysql -u root
Überprüfen Sie den Slave-Status:
SHOW SLAVE STATUS\G
Untersuchen Sie die Ausgabe. Sie sollten sehen, dass Slave_SQL_Running wahrscheinlich auf No gesetzt ist und das Feld Last_SQL_Error eine Fehlermeldung enthält, die auf einen doppelten Schlüssel oder einen ähnlichen Konflikt hinweist.
Beispiel für eine Fehlermeldung:
...
Slave_IO_State: Waiting for master to send event
Master_Host: master_host
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 154
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 311
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1062
Last_Error: Duplicate entry '1' for key 'PRIMARY'
Skip_Counter: 0
Exec_Master_Log_Pos: 154
Relay_Log_Space: 472
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
...
-
Beheben des Replikationsfehlers:
Um diesen Fehler zu beheben, überspringen wir das problematische Ereignis auf dem Slave-Server. Dadurch wird dem Slave mitgeteilt, das Ereignis, das den Fehler verursacht hat, zu ignorieren und die Replikation mit dem nächsten Ereignis fortzusetzen.
Stoppen Sie zunächst den Slave-SQL-Thread:
STOP SLAVE SQL_THREAD;
Überspringen Sie dann das fehlerhafte Ereignis:
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Dieser Befehl teilt dem Slave mit, das nächste Ereignis im Relay-Log zu überspringen.
Starten Sie schließlich den Slave-SQL-Thread:
START SLAVE SQL_THREAD;
-
Überprüfen, ob die Replikation wieder läuft:
Überprüfen Sie erneut den Slave-Status:
SHOW SLAVE STATUS\G
Sie sollten jetzt sehen, dass Slave_SQL_Running auf Yes gesetzt ist und Last_SQL_Error leer ist. Die Replikation sollte wieder normal laufen.
-
Überprüfen der Datenkonsistenz:
Überprüfen Sie auf dem Slave-Server den Inhalt der Tabelle test_replication.test_table:
USE test_replication;
SELECT * FROM test_table;
exit
Sie sollten sowohl den absichtlich konfliktiven Datensatz als auch den neuen Datensatz vom Master sehen. Der konfliktive Datensatz war bereits vorhanden, und der neue Datensatz wurde nach dem Überspringen des Fehlers erfolgreich repliziert.
+----+-----------------------------------------------------+
| id | data |
+----+-----------------------------------------------------+
| 1 | This is a test record from master |
| 2 | This is an intentionally conflicting record on the slave |
| 3 | This is a new record from master |
+----+-----------------------------------------------------+
3 rows in set (0.00 sec)
Sie haben nun erfolgreich einen Replikationsfehler simuliert und ihn durch Überspringen des problematischen Ereignisses behoben. Dies ist eine gängige Technik zur Behebung von Replikationsproblemen, die durch Dateninkonsistenzen verursacht werden. Denken Sie daran, dass das Überspringen von Ereignissen mit Vorsicht erfolgen sollte, da es zu Datenabweichungen führen kann, wenn es nicht richtig behandelt wird. Es ist wichtig, die Ursache des Fehlers zu verstehen, bevor Sie Ereignisse überspringen.
