L’objectif de cet article est de décrire la procédure de resynchronisation d’un Slave suite à un problème de réplication MySQL lié au Master.
Dernièrement, chez un client, un problème est survenu sur le Master d’une réplication MySQL.
En effet, le filesystem stockant les données MySQL (datadir) a été saturé et un nouveau disque d’une plus grande taille a été mise en place. Les données ont été déplacé sur ce nouveau disque mais la réplication MySQL avec le Slave n’a pas été remise en place.
Nous devons donc restaurer un backup FULL de 2 bases sur le Slave et relancer la réplication sur le Slave.
Voici donc la procédure qui inclus des actions tant sur le Master que sur le Slave donc bien vérifier sur lequel vous êtes !
Master (asterix)
- Vérifier le status du Master
mysql -uroot -p******** show master status \G; show processlist \G;
- Faire un backup FULL compressé sur le Master avec mysqldump comprenant les 2 bases :
time mysqldump -uroot -p****** --single-transaction --master-data=2 --databases panoramix idefix --max-allowed-packet=2G | gzip > /backup2/backup_bases_03pic.dmp.gz
Nous utilisons la commande time pour chronométrer le temps du backup FULL avec les options suivantes :
– single-transaction : sauvegarde se fait au sein d’une seule transaction tout en laissant la base fonctionner normalement
– master-data : la valeur de l’option à 2 écrit l’instruction CHANGE MASTER TO en commentaire. L’option –master-data désactive automatiquement –lock-tables.
– databases : nom des bases à sauvegarder
– max-allowed-packet : longueur de paquet maximale à envoyer ou à recevoir du serveur
- Transférer le backup FULL des 2 bases en scp du Master vers le Slave :
scp /backup2/backup_bases.dmp.gz capdata@obelix:/opt/restore
Slave (obelix)
- Vérifier le status du Slave et l’état du process de réplication
mysql -uroot -p******** show slave status \G; show processlist \G;
- Supprimer les 2 bases sur le slave :
mysql -uroot -p******** show databases; drop database panoramix; drop database idefix;
- Restaurer le dump de la prod sur le slave :
mysql -uroot -p******** < /opt/restore/backup_bases.dmp
- Dans une nouvelle session, vous pouvez voir le process de restauration depuis la liste des processus sur le Slave :
mysql -uroot -p******** show processlist \G;
- Une fois la restauration terminée, arrêter le slave, mettre le fichier de log et position compris au début du dump puis démarrer le Slave :
mysql -uroot -p******** stop slave; CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.052873', MASTER_LOG_POS=42402792; start slave;
- Vérifier le status du Slave et le rattrapage (Seconds_Behind_Master) des bin logs vis-à-vis du Master :
show slave status \G;
show processlist \G;
Master (Asterix)
- Vérifier le status du Master :
mysql -uroot -p******** show master status \G;
show processlist \G;
Voila en espérant que ce petit tips MySQL vous aura servi.
A bientôt pour de nouveaux articles sur MySQL !
Erwan Ollitrault
Continuez votre lecture sur le blog :
- Déplacer le répertoire de données (datadir) MySQL vers un nouvel emplacement sur Debian (Capdata team) [MySQL]
- [ERROR] Error reading packet from server: Lost connection to MySQL server during query (David Baffaleuf) [Codes erreurMySQL]
- Migrer d’un cluster Galera MariaDB 10.3 vers MariaDB 10.5 avec la réplication logique (David Baffaleuf) [ContainerMySQLNon classé]
- La fin de mysql_upgrade à partir de MySQL 8.0.16 (Capdata team) [MySQL]
- Recharger un backup de master en SQL 2014 CU6 (David Baffaleuf) [SQL Server]