Réplication MySQL : L’erreur 1236

Le 14 janvier 2013 — par

Cet article n’intéressera que les personnes qui font de la réplication Master-Slave avec MySQL. Je pense qu’il y en a quand même quelques-unes alors je vais continuer.

Si par malheur votre Slave vient à se couper sans prévenir, la procédure d’extinction de MySQL n’a pas pu se faire. Souvent ce n’est pas très grave, sauf dans le cas d’une réplication Master-Slave.

Dans ce cas le fichier binaire n’est pas correctement arrêté et devient corrompu. Vous obtiendrez la fameuse erreur 1236, affichée telle quelle via un SHOW SLAVE STATUS\G :

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.010902' at 31735587, the last event read from '/var/log/mysql/mysql-bin.010902' at 31735587, the last byte read from '/var/log/mysql/mysql-bin.010902' at 31735606.'

Une erreur qui a l’air de faire un peu peur de prime abord, d’autant que le « conseil » prodigué par le Master demande de toucher à la configuration du serveur, ce qui n’est absolument pas nécessaire pour réparer un fichier corrompu.

Malheureusement quand un fichier binaire MySQL est corrompu, il est impossible de le réparer. Il va donc falloir couper la réplication, refaire sa configuration, puis la redémarrer.

Avant toute chose, prenez bien note de deux valeurs dans le statut de la réplication SHOW SLAVE STATUS\G : Relay_Master_Log_File et Exec_Master_Log_Pos. Elles sont essentielles pour la bonne remise en route.

Couper la réplication est assez trivial :

SLAVE STOP;

Pour la configuration, ça se complique un petit peu. Afin de purger les logs binaires corrompus, il suffit de changer les informations du Master. En l’occurrence on va changer le nom du fichier log et la position dans le fichier, en reprenant les deux variables qu’on a sauvegardées précédemment.

Copiez donc cette ligne sans oublier de modifier Relay_Master_Log_File et Exec_Master_Log_Pos par les valeurs correspondantes :

CHANGE MASTER TO MASTER_LOG_FILE = Relay_Master_Log_File , MASTER_LOG_POS = Exec_Master_Log_Pos;

Puis on redémarre la réplication.

SLAVE START;

Votre serveur devrait être en train de récupérer son retard (symbolisé par une valeur plus ou moins importante de Seconds_Behind_Master) et Slave_IO_Running ainsi que Slave_SQL_Running doivent être de nouveau à Yes.

Vous venez de sauver votre réplication.

S'abonner au flux RSS du blog
Recevoir les nouveaux articles par e-mail :