web-dev-qa-db-fra.com

Journal de relais MySQL corrompu, comment le réparer? Essayé mais échoué

Un relais MySQL v5.1.61 a été corrompu lorsque la machine s'est soudainement arrêtée. J'ai essayé de le réparer mais cela n'a pas fonctionné.
- Comment je le répare? Est-ce que j'ai fait quelque chose de mal?

D'après ce que j'ai lu, les journaux de relais MySQL corrompus sont facilement corrigés:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

où Relay_Master_Log_File et Exec_Master_Log_Pos sont répertoriés par:
mysql> show slave status;

Mais quand j'ai fait change master status ..., J'ai une erreur de violation de clé primaire. Comment est-ce possible? La procédure ci-dessus n'est-elle pas correcte, ou est par exemple certains +1 manquant?

(Pour l'instant, j'ai simplement réimporté un mysqldump --master-data du maître vers l'esclave, et cela a résolu le problème. Cependant, à l'avenir, cela pourrait ne pas être approprié.)


Voici les détails de mon problème particulier:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-Host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 66395191
              Relay_Log_Space: 36559177
              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
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

Et voici ce que j'ai fait:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_Host='the-master-Host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Et c'est ce qui s'est passé, une erreur PK:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-Host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

Je pense que j'ai suivi la procédure recommandée (voir les liens juste en dessous), il y avait toujours une erreur PK : ? --- (http://bugs.mysql.com/bug.php?id=26489 , rechercher pour "Contournements". http://mhbarr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/https://stackoverflow.com/ a/14438408

mysqlreplicationcorruption
26
KajMagnus

Erreur: Last_SQL_Errno: 1594 Last_SQL_Error: échec de lecture du journal de relais: impossible d'analyser l'entrée d'événement du journal de relais.

Cette erreur signifie que le fichier journal maître est corrompu ou que le fichier journal relais est corrompu.

  • Avant de faire quoi que ce soit, sauvegardez toutes vos bases de données, journaux, serveurs d'images, répétez plusieurs fois et continuez uniquement à vos risques et périls.

Exécutez d'abord "show slave status\G" sur l'esclave et notez:

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

Tout d'abord, nous voulons nous assurer que le fichier journal maître est intact, alors sautez sur le serveur maître et trouvez Relay_Master_Log_File (vérifiez/var/log/mysql) et exécutez la commande suivante:

mysqlbinlog mysql-bin.000026

Le journal sera affiché mais j'espère que vous ne verrez aucun message d'erreur. Si vous voyez des messages d'erreur, les journaux principaux sont corrompus et vous devrez probablement recréer une image.

Exécutez ensuite la même commande sur le journal du relais esclave (souvent dans/var/lib/mysql)

mysqlbinlog mysqld-relay-bin.000056

Vous verrez probablement des erreurs montrant la corruption qui a arrêté la réplication, comme ceci:

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

Si vous voyez des erreurs, le journal est correct sur le maître et seul le journal de relais de l'esclave est corrompu. C'est une bonne nouvelle, nous pouvons réinitialiser l'esclave et lui dire les détails du maître et où continuer. Si vous ne voyez aucune erreur, arrêtez de lire maintenant, vous avez un problème différent.

Si le journal du relais esclave contient des erreurs, exécutez les commandes suivantes pour réinitialiser l'esclave et les journaux corrompus se reconnecter au maître, obtenir les journaux corrects et recommencer l'asservissement. Notez que MASTER_LOG_POS est le Exec_Master_Log_Pos, et MASTER_LOG_FILE est le Relay_Master_Log_File ([[# #]] pas [~ # ~] le premier, qui correspond aux journaux de relais qui ont été récupérés et doivent être jetés) à la fois à partir de la première commande.

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_Host='master.Host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
35
A.Badger

[Correction de la réplication MySQL après la corruption du journal de relais des esclaves]

La réplication MySQL sur l'esclave (version 5.XX) s'est arrêtée. Slave_IO_Running a été marqué comme Oui, mais Slave_SQL_Running comme Non. L'esclave stop/start simple n'a pas aidé, donc une analyse plus approfondie du problème était nécessaire. Il semblait que le journal de relais de l'esclave actuel était corrompu car le test avec "mysqlbinlog" a imprimé une erreur. Par conséquent, la solution était de supprimer les journaux de binaires de relais actuels et de pointer l'esclave vers la dernière position de journal de binaires maître.

Pour corriger l'erreur, les fichiers binlog actuels sur l'esclave doivent être supprimés et définir une nouvelle position. Avant de définir la nouvelle position du journal des événements, il est important de se rappeler Relay_Master_Log_File et Exec_Master_Log_Pos les valeurs du serveur esclave corrompu en utilisant la commande SHOW SLAVE STATUS\G:

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

OK, avec ces valeurs, une nouvelle position binlog peut être définie:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

Juste pour noter que reset slave supprimera master.info, relay-log.info et tous les fichiers journaux de relais, il n'est donc pas nécessaire de nettoyer les restes dans /var/lib/mysql répertoire.

9
Mohamed Ayas

Je sais que cela fait plus d'un an, mais voici ce qui est peut-être arrivé à ce problème particulier.

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_Host='the-master-Host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Cela semble avoir dû le corriger car il a supprimé le journal de relais corrompu.

Ensuite, vous avez une erreur PK 1062. Pourquoi?

Il y a un bug en suspens ( http://bugs.mysql.com/bug.php?id=60847 ) qui est toujours actif dans MySQL 5.5

Bien que le bogue concerne l'utilisation de mysql --single-transaction --flush-logs, une bizarrerie connexe existe.

J'ai vu cette bizarrerie sur certains serveurs EC2 fonctionnant en tant qu'esclaves pour un client la semaine dernière dans MySQL 5.5.15

Sur le maître, il y avait un étrange INSERT étendu à plusieurs lignes où chaque tuple inséré était un SELECT. Ce qui s'est passé, c'est que le LAST_INSERT_ID dans le journal de relais, qui constitue le prochain incrément automatique à affecter, était déjà utilisé sur l'esclave en raison d'insertions sur plusieurs lignes au préalable.

L'INSERT sérialisé dans le journal de relais ressemblait à

INSERT INTO tablname (column,column) VALUES (value,value,...)

La liste des colonnes ne comprenait pas la clé primaire numérique. Lorsque l'erreur 1062 est revenue, j'utiliserais la même requête sur laquelle elle a échoué, exécutez la requête manuellement. Il n'a pas atteint l'erreur 1062. Ensuite, j'ai exécuté les commandes skip slave habituelles:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

Ensuite, la réplication a rattrapé.

Mon conseil serait de sérialiser correctement vos INSERT sur le Master car cette situation de type bug est en fait assez évitable.

3
RolandoMySQLDBA

Vous l'avez fait très bien (comme d'autres l'ont déjà dit).

Le seul problème est avec le fichier master.info (contient des informations sur la position dans mysql-bin.log du maître) car ce fichier n'est pas synchronisé sur le disque après chaque requête traitée.

Vos informations sur les positions dans le journal du maître sont donc obsolètes et vous traitez des requêtes déjà traitées qui doivent être ignorées avec SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;.

Malheureusement, si vous utilisez des requêtes comme UPDATE table SET counter=counter+1 WHERE id = 12345 et en utilisant binlog_format=STATEMENT vos bases de données peuvent se désynchroniser, je pense.

Vous pouvez dire au serveur MySQL de synchroniser master.info après chaque événement en configurant la variable sync_master_info mais cela aura probablement d'énormes conséquences sur les performances.

1
Dragonn