MySQL problème de réplication master slave

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 :

 

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)

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

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 :

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

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

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

Vous devriez avoir ceci parmi la réponse :

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.

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer