Il existe plusieurs méthodes plus ou moins proches pour réparer une réplication MySQL / MariaDB. Je vous livre une de mes méthodes que j’utilise assez souvent car elle permet de par exemple le faire sur la seule base de données qui pose problème. De plus il n’y aura pas besoin de noter les informations master data qui seront contenues directement dans le ou les dumps mysql générés.

La première étape consiste à arrêter la réplication. Pour cela, une petite connexion sur votre serveur SLAVE suivie d’un STOP SLAVE; fera le job.

On attaque ensuite le travail sur le serveur MASTER. Notez que dans le cas présent le STOP SLAVE; que vous pouvez me voir effectuer sur le serveur master est uniquement présent car il y a une réplication dans les deux sens, cela sera inutile dans le cas d’une réplication effectuée dans un seul sens.

il sera nécessaire d’ouvrir 2 sessions sur le serveur MASTER. La première session va nous servir à mettre le serveur en lecture seulement le temps du dump.

***ON THE MASTER***

###Premier terminal###

STOP SLAVE;
FLUSH TABLES WITH READ LOCK;

On passe ensuite au second terminal : j’y exécute alors un dump de la base de données ou des bases de données concernées par l’erreur de réplication préalablement diagnostiquée dans les fichiers de log MySQL. J’utilise pigz pour la compression car il est bien plus rapide que les autres, mais vous pouvez utiliser l’outil de votre choix, tel que gzip ou l’envoyer directement dans un fichier .sql si vous avez la place.

###Second Terminal###

mysqldump $dbtodump --opt --single-transaction --hex-blob --triggers -R -E --comments --dump-date --no-autocommit --master-data |pigz > db2dump.sql.gz

Si j’ai besoin d’effectuer une série de dumps, sur, par exemple l’ensemble des bases, je pourrais procéder ainsi :

mysqlshow |cut -d " " -f2 |grep -v + |grep [a-z\|A-Z\|0-9] |grep -v -w mysql |grep -v -w phpmyadmin |grep -v -w information_schema |grep -v -w performance_schema > liste.txt

vim savedbs.sh

#!/bin/bash
mysqldump $1 --opt --single-transaction --hex-blob --triggers -R -E --comments --dump-date --no-autocommit --master-data |pigz > $1.sql.gz

chmod +x savedbs.sh
cat liste.txt |xargs -l ./savedbs.sh

Une fois le ou les dumps terminés, il faut repasser le serveur MySQL MASTER en écriture :

***ON THE MASTER***

###Premier terminal###
UNLOCK TABLES;

Voila, la production peut continuer tandis que nous pouvons aller nous occuper tranquillement du serveur esclave.

*** ON THE SLAVE ***

mysql -uroot -p < yourdump(s).sql

Pour reprendre l'exemple plus haut, si vous aviez plusieurs ou bien toutes les bases de données à restaurer vous pouvez procéder de la manière suivante :

vim restoredbs.sh

#!/bin/bash
zcat $1.sql.gz |mysql --database=$1

chmod +x restoredbs.sh
cat liste.txt |xargs -l ./restoredbs.sh

Une fois la restauration terminée, il ne reste plus qu'à redémarrer la réplication :

START SLAVE;

Puis à vérifier que tout se passe bien :

SHOW SLAVE STATUS\G

Si la réplication est établie dans les deux sens, il ne faudra pas oublier de la rétablir dans l'autre sens. Pour cela sur le serveur esclave vous noterez le logname et la position :

SHOW MASTER STATUS;

Puis il suffira sur le serveur MASTER de lancer la commande suivante :

*** ON THE MASTER ***
CHANGE MASTER TO MASTER_LOG_FILE='$nameofthelogbinlaststep', MASTER_LOG_POS=$posatlaststep;
START SLAVE;

Puis vérifier que tout va bien:

SHOW SLAVE STATUS\G;

Christophe Casalegno
​Vous pouvez me suivre sur : Twitter | Facebook | Linkedin | Telegram | Youtube