Plusieurs choses sont amenées à provoquer un problème de réplication de vos bases de données MySQL :

  • Quelqu’un se connecte sur un slave et fait une modification… (des options readonly permettent de s’en prémunir)
  • Mauvaise perte de connexion entre les serveurs
  • Crash du master
  • …

Pour commencer, je ne le répèterai jamais assez, pensez aux backups de vos bases de données MySQL. Je vais traiter le sujet dans un article sur la sauvegarde de grosse base de données MySQL via xtrabackup, mais autobackup est parfait pour de petites base de données. Ce dernier est basé sur mysqldump, mais gère la journalisation des dumps. J’explique la restauration master-slave à partir d’un dump dans un autre article.

Vous avez maintenant votre roue de secours, on peut donc regarder pour solutionner votre problème de réplication MySQL. Dans la suite de cet article, je traite la restauration à partir des binaires ou d’une sauvegarde Xtrabackup.

Type d’erreur

Avec un show slave status, vous avez une erreur du type :

error ' Duplicate entry '2513' for key 1' on query 'INSERT INTO users VALUES('','400', 'user1', '(hidden)', 'Belgium')'

 

Restaurer un slave via une copie binaire ou xtrabackup

La première méthode permet de partir des fichiers binaires :

  • soit via une sauvegarde xtrabackup, donc pas d’arrêt de service. Xtrabackup sauvegarde le logfile et sa position, très utile pour rétablir la synchronisation.
  • soit via une copie rsync des données de /var/lib/mysql du master, mais le rsync doit être fait avec le serveur MySQL éteint! Ou en read-only avec des flush tables pour ne pas trop dégrader…

1. Préparation sur le slave

Arrêtez le service MySQL.

Si vous avez xtrabackup, copiez la dernière sauvegarde et passez l’étape suivante, rien à faire sur le master, direction point 3.

Si vous le faite via rsync, suivez l’étape suivante.

2. Préparation sur le master uniquement via rsync

Ouvrez 2 consoles SSH sur le master.

Dans la première, ouvrir une console mysql pour mettre la base de données en read-only (pour ne pas arrêter le service MySQL carrément)

FLUSH TABLES WITH READ LOCK;

Dans l’autre fenêtre, obtenir la position du log file via une nouvelle console MySQL et notez le :

show master status \G

Fermez la console MySQL pour revenir en shell.

Maintenant, copiez le répertoire /var/lib/mysql avec les options rsync -ahPl du master vers le slave.

Une fois la copie finie, retournez dans la première console MySQL pour faire la commande de libération des tables :

unlock tables;

Vérifiez que les tables sont bien libérées après avoir attendu une minute :

show open tables;

3. Remettre la réplication MySQL en place sur le slave

En premier, démarrez MySQL et vérifiez que vos bases de données sont bien là.

Appliquez les commandes suivantes, en remplaçant les valeurs par celle de votre infrastructure :

  • HOST : votre serveur master
  • USER : l’utilisateur MySQL de réplication si vous en avez défini un sinon le root (je vous conseille un utilisateur dédié avec uniquement les droits nécessaires)
  • PASSWORD : le mot de passe
  • LOG_FILE et LOG_POS : les valeurs de la position du log file récupérée plus haut sur le master
reset slave;
CHANGE MASTER TO
MASTER_HOST='serveur_master.tld',
MASTER_USER='repl',
MASTER_PASSWORD='passwd',
MASTER_LOG_FILE='mysql-bin.002043',
MASTER_LOG_POS=106;
start slave;

Attendez une minute et puis vérifiez le status du slave :

show slave status \G

Vous devriez avoir ceci parmi la réponse :

Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Votre réplication est donc correcte.

Pour vous rassurez la première fois, vous pouvez faire un « create database toto » sur le master, voir si la base de données apparait sur le slave et ensuite faire un « drop database toto » sur le master.

 

Articles relatifs :