03.11
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.

Drucken PDF

Switch to our mobile site