Analyse

Le problème est indiqué via la commande slave status;. Le message indique le nom du fichier binlog concerné et la position. La requête précédent cette position n'a pas fonctionné, car les données sur le serveur esclave ne sont pas conformes à celle du serveur maître.

Afin d'identifier l'origine du problème, il faut se connecter sur le serveur maître en tant que root et exécuter la commande suivante :

sudo mysqlbinlog --verbose --stop-position=<position> /chemin/mysql-binlog.<numéro> | less

<position> et <numéro> sont les informations fournies dans le message d'erreur. Je n'ai pas trouvé le moyen d'indiquer la position de début de la transaction qui précède l'erreur. On va aller à la fin du résultat (touche G dans less) et consulter les dernières requêtes, afin de comprendre ce qui ne fonctionne pas.

Correction

Il y a deux corrections possibles, soit on arrive à corriger les données sur le serveur esclave, dans ce cas on va pouvoir redémarrer la réplication, soit on passe simplement la transaction. La seconde solution permet de reprendre la réplication, mais il est fort probable que la réplication sera de nouveau bloquée lors de la prochaine mise à jour de la même ligne qui était en erreur.

Pour appliquer la première solution, on va se connecter à la base de données et exécuter une requête permettant de corriger les données en erreur. Une fois la correction apportée, on va relancer la réplication avec les commandes suivantes :

SHOW REPLICA STATUS;
START REPLICA;
SHOW REPLICA STATUS;

La première et dernière commande, permettent d'afficher le statut de réplication. Lors du second appel, le statut doit indiquer qu'il n'y a plus d'erreur et que le serveur esclave est en attente de nouvelles informations à répliquer.