Vous avez mis en place deux beaux serveurs MySQL avec un système de réplication master-slave qui vous offre des temps de réponse impressionnants et vous permet de dormir sur vos deux oreilles depuis quelques semaines. Mais voilà qu’un beau jour (de préférence un lundi matin tôt) vous vous rendez compte que vos deux serveurs ne présentent plus les mêmes données (de préférence depuis le vendredi précédent, environ 10 minutes après votre départ).

Pour une fois, ne faites pas confiance à ce bon docteur House, non ça n’est pas un lupus et personne ne va mourir (enfin je crois, en fait ça dépend aussi de votre boss). Il y a de grandes chances pour que vos serveurs soient tout simplement désynchronisés et même si les symptômes semblent catastrophiques, le mal est simple à traiter. Direction les urgences pour administrer un remède de cheval à vos serveurs (en français dans le texte, resynchroniser les bases de données) !

Confirmer la désynchronisation des bases de données

Le seul moyen de vous assurer que vos malades souffrent bien de désynchronisation de la réplication est de comparer leurs index de log binaire grâce aux commandes

SHOW master status;

sur le serveur primaire qui a le rôle de maître et

SHOW slave status;

sur le serveur secondaire. Si vos serveurs sont effectivement désynchronisés, les colonnes “Position” du maître et “Read_Master_Log_Pos” de l’esclave vont être différentes.

 Resynchroniser les bases de données

Il va falloir dans un premier temps remettre les données du maître manquantes sur l’esclave. Pour cela, commencez par purger, verrouiller et noter l’index de log binaire (il a pu changer entre votre diagnostic et le verrouillage) de votre serveur.

RESET master;
FLUSH tables WITH read lock;
SHOW master status;

L’index de log binaire est le nombre indiqué dans la colonne “Position” du tableau qui s’affiche.

Ne fermez pas la connexion à la console SQL car cela supprimerait le verrou et exportez vos données, avec votre utilitaire favori (MySQL Workbench, phpMyAdmin…) ou tout simplement avec mysqldump, transférez le fichier sur le serveur esclave et ouvrez-y  une console. Vous pouvez vous enlever le verrou avant de vous déconnecter du master:

UNLOCK tables;

Sur le slave, commencer par arrêter la réplication :

STOP slave;

Puis importez les données que vous avez transférées.

Enfin, réinitialisez les paramètres de réplication et redémarrez la. Le fichier MASTER_LOG_FILE est le fichier journal de la réplication, vous devez lui donner un nouveau nom pour ne pas détruire l’ancien journal (ça peut toujours servir) :

CHANGE master TO
  MASTER_LOG_POS=index_de_replication_du_maitre,
  MASTER_LOG_FILE=nom_du_fichier;
START slave;

Il ne vous reste plus qu’à vérifier l’état de votre slave grâce à la commande

SHOW slave status;

Il ne vous reste plus qu’à écrire une donnée sur le master et à vérifier qu’elle est bien recopiée sur les slave, si c’est le cas vous avez réussi à resynchroniser les bases de données de vos serveurs MySQL.

La perte de synchronisation n’a généralement pas de lourdes conséquences sur un site éditorial, mais peut s’avérer problématique sur une boutique en ligne par exemple : imaginez qu’un produit épuisé sur le master (qui gère le processus de commandes) reste disponible sur un slave (qui affiche les pages produit), le client ne comprendra pas pourquoi il ne peut pas passer commande. C’est pourquoi il faut resynchroniser les bases de données au plus vite, quitte à prévoir une resynchronisation périodique même si aucun incident ne se produit, vous pouvez par exemple profiter d’une sauvegarde pour réinitialiser les indexes.

Je n’ai pas abordé ici le cas d’une synchronisation master-master. En théorie il n’y a pas beaucoup de différences : on coupe un master et le slave correspondant pour revenir en configuration master-slave, on réinitialise le master actif, on s’assure que les données sont bien les mêmes sur les deux serveurs et on réinitialise le slave avant de relancer les master et slave désactivés. Mais dans la pratique, cela peut être beaucoup plus complexe que cela. Si nous reprenons le cas d’un e-commerce, chaque serveur gère les pages produits et les commandes puisque tout est censé être répliqué. Mais si la réplication cesse, chacun enregistre ses commandes de son côté et il devient impossible de faire un simple dump d’un serveur vers l’autre, sous peine d’effacer des commandes… peut-être que cette mésaventure vous est déjà arrivée ? Comment l’avez-vous traitée ? Avez-vous un système qui vérifie que la réplication fonctionne bien ? N’hésitez pas à nous faire par de vos astuces !

Sources