Voici la méthode que j’utilise, en environnement Linux standard (pas de snapshot, de système de fichier intégrant lui-même de la réplication, etc.) pour réparer une réplication MySQL ou MariaDB victime d’une panne suffisamment importante pour nécessiter de refaire complètement la réplication. Attention, on est ici dans le cas d’un serveur où toutes les bases sont répliquées. Il sera nécessaire d’adapter la solution si vous effectuez des réplications partielles de certaines bases seulement.
 
Note : il n’y aura pas besoin de noter les informations master data du serveur maître qui seront contenues directement dans les dumps mysql générés.
 
La première étape consiste à arrêter la réplication. Pour cela, il est nécessaire de vous connecter sur votre serveur ESCLAVE / SLAVE et de faire un :

STOP SLAVE;

On attaque ensuite le travail sur le serveur MAITRE / MASTER. J’effectue également ici un STOP SLAVE; sur le MASTER, car dans mon cas, la réplication a été initialisée dans les deux sens. Cette opération est inutile si la réplication n’est configurée que dans un sens.
 
il sera nécessaire d’ouvrir 2 sessions sur le serveur MASTER, directement via SSH ou au travers d’un outil tel que screen. La première session va nous servir à mettre le serveur en lecture seulement le temps de l’exécution du dump

***ON THE MASTER***

###Premier terminal###

STOP SLAVE;
FLUSH TABLES WITH READ LOCK;

Maintenant que le serveur est en lecture seulement, on peut passer sur notre second terminal pour effectuer le dump de la base ou de l’ensemble des bases 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 ici 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, bzip2, rar, etc. ou l’envoyer directement dans un fichier .sql non compressé si vous avez la place nécessaire (sinon il est toujours possible d’effectuer une sortie over ssh vers un autre serveur).

###Second Terminal###

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

Quelques explications sur la commande :

$dbtodump : Il s’agit du nom de la base de données que vous souhaitez sauvegarder.
 
–opt : cette option inclut plusieurs autres options couramment utilisées pour améliorer les performances de la sauvegarde. Cela inclut –add-drop-table, –add-locks, –create-options, –disable-keys, –extended-insert, –lock-tables, et d’autres options similaires. Utiliser –opt, permet d’éviter de spécifier chacune des options concernées.
 
–single-transaction : cette option effectue la sauvegarde dans une transaction unique, ce qui garantit que la base de données reste cohérente pendant le processus de sauvegarde, même si d’autres opérations sont en cours.
 
–hex-blob : on indique à mysqldump de sauvegarder les données de type BLOB sous forme hexadécimale, ce qui peut éviter certains problèmes / incohérences à la restauration sur certains caractères.
 
–triggers : permet d’inclure les triggers (déclencheurs en français) dans la sauvegarde, ce qui signifie que les instructions SQL pour les déclencheurs seront incluses.
 
-R ou –routines : cette option va permettre de sauvegarder également les procédures stockées et les fonctions de la base de données.
 
-E ou –events : cette option va également sauvegarder les événements de la base de données, qui sont des tâches planifiées exécutées automatiquement par le serveur MySQL.
 
–comments : cette option inclut des commentaires dans le fichier de sauvegarde pour expliquer à quoi correspond chaque section de la sauvegarde.
 
–dump-date : ajoute la date de création de la sauvegarde dans les commentaires.
 
–no-autocommit : cette option désactive l’autocommit pendant le processus de sauvegarde, ce qui peut être utile pour garantir la cohérence des données.
 
–master-data : enfin, cette option va nous permettre d’inclure les informations de position du journal binaire (binlog) dans les commentaires de la sauvegarde. C’est ce qui va nous éviter d’avoir à effectuer cette opération manuellement sur le serveur slave après l’injection.
  
Si j’ai besoin d’effectuer une série de dumps, sûr, plusieurs bases de données 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

J’ignore volontairement la base mysql, car dans mon cas, le master et le slave ont un compte admin avec des mots de passe différents.

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</code>

Une fois le ou les dumps terminés, on peut repasser le serveur MySQL ou MariaDB MAITRE / MASTER en écriture :

***ON THE MASTER***

###Premier terminal###

UNLOCK TABLES;

Voilà, la production peut continuer tandis que nous pouvons aller nous occuper tranquillement du serveur esclave. Attention, je vous conseille d’effectuer ces opérations dans un screen, surtout si le dump à injecter est gros pour éviter qu’une coupure de connexion vienne faire échouer votre restauration.

*** ON THE SLAVE ***

mysql -uroot -p < yourdump(s).sql&#91;/code&#93;

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 : 

&#91;code&#93;vim restoredbs.sh

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

chmod +x restoredbs.sh
cat liste.txt |xargs -l ./restoredbs.sh&#91;/code&#93;

Une fois la restauration terminée, il ne reste plus qu'à <strong>redémarrer la réplication</strong> : 
[code]START SLAVE;[code]
Puis, à vérifier que tout se passe bien : 
[code]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, après que la réplication a été rattrapée, vous noterez le logname et la position :

SHOW MASTER STATUS;

Il suffira alors de lancer la commande suivante sur le serveur MAITRE / MASTER :

*** 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;