2009
Wie man eine MySQL Replikation repariert
Bei einer MySQL Replikation (Master-> Slave) kann es Manchmal ungültigen MySQL Abfragen geben, die dafür sorgen, dass die Replikation nicht mehr funktioniert.
Wie dieser Fehler behoben werden kann möchte ich nun zeigen:
Ausgangssituation:
OS: OpenSuSE
Mysql: Version 5.0.26
Cluster:
MysqlDB Master -> Slave oder auch Master1 -> Slave2 -> Master2 -> Slave1
Fehler:
Der Fehler kann in der Logdatei gefunden werden,
/var/lib/mysql/mysqld.log
oder über dir mysql konsole:
Anmeldung an der MySQLDB mit globalen Rechten:
mysql -uroot -p********
Führe dieses Kommando in der MySQL Kommandozeile aus:
mysql> show slave status\G;
Ausgabe:
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.20
Master_User: rep-slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 49829205
Relay_Log_File: mysqlcluster2-relay-bin.000016
Relay_Log_Pos: 3680509
Relay_Master_Log_File: mysql-bin.000003
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: Error 'Duplicate entry '9959-0-_transient_timeout_rss_5d9ad1c55ec39
ea3dba324257d3a091f' for key 1' on query. Default database: 'dbsms29200024'. Query: 'INSERT INTO
`wp_options` (`option_name`,`option_value`,`autoload`) VALUES ('_transient_timeout_rss_5d9ad1c5
5ec39ea3dba324257d3a091f','1257232955','no')'
Skip_Counter: 0
Exec_Master_Log_Pos: 48652901
Relay_Log_Space: 4856813
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
1 row in set (0.00 sec)
ERROR:
No query specified
Achtung: Wenn Slave_IO_Running oder Slave_SQL_Running auf No gesetzt ist, dann ist die Replikation kaput.
In aller Regel steht aber nur Slave_SQL_Running auf NO.
Die Replikation reparieren
Wir halten den Slave (192.168.0.20) mit dem Kommando stop slave an!
mysql> stop slave; Query OK, 0 rows affected (0.00 sec)
Jetzt beheben wir das Problembehebung, in dem wir MYSQL (Slave) den Befehl zum überspringen der ungültige SQL Abfrage geben.
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; Query OK, 0 rows affected (0.00 sec)
Jetzt wird der Slave wieder gestartet.
mysql> start slave; Query OK, 0 rows affected (0.00 sec)
Nun den Status prüfen mit dem Befehl show slave status\G, das "\G" steht nur für die Formatierung.
mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.20 Master_User: rep-slave Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 49930095 Relay_Log_File: mysqlcluster2-relay-bin.000017 Relay_Log_Pos: 235 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 49930095 Relay_Log_Space: 235 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: 0 1 row in set (0.00 sec) ERROR: No query specified
Der Fehler ist behoben, wenn Slave_SQL_Running auf Yes steht. Bei einem Cluster der Form Master1 -> Slave2 -> Master2 -> Slave1
ist es nicht ungewöhnlich dass der zweite Slave sich auch noch mal meldet.
Ich möcht nicht vergessen darauf hinzuweisen, dass ich keine Garantie für die Richtigkeit übernehmen kann.

