Mysql resynchronisation / replication

Une désynchro entre les slaves et le master peut se manifester après des jours ou des semaines de fonctionnement "correct" (normalement, si la synchro a été bien faite, une desynchro ne se produit jamais, mais bon...).

Une désynchro peut être "invisible": aucune alerte Nagios sur la réplication ou sur MySQL ne signale le problème. On s'en aperçoit par exemple quand un client se plaint au SC qu'une adresse email qu'il a créé/supprimé il y a quelques jours n'est toujours pas fonctionnelle/supprimée...

Première méthode

Maintenant que les serveurs MySQL de plate forme Claranet appartiennent tous à la v5, il est possible d'utiliser la commande LOAD DATA sans que le slave se désynchronise quelques heures plus tard.

Pour cela, sur le serveur slave:

- Détruire les bases qui sont répliquées via un DROP DATABASE <BASE>
  (S'assurer que les bases détruites sont bien répliquées en inspectant le champs 
   Replicate_Wild_Do_Table obtenu via la sortie de SHOW SLAVE STATUS \G)
- STOP SLAVE
- Recréer les bases détruites
- LOAD DATA FROM MATER;
- Attendre (2 minutes grand max)
- START SLAVE

Si tout s'est bien passé, nous n'avons pas vu de warnings ou d'erreurs en sortie lors de l'exécution des commandes précédentes.

Maintenant, il est possible que certaines sous-versions appartenant à la 5 sortent un warning lors du LOAD DATA FROM MASTER. Un SHOW WARNINGS montrera que cette commande est obsolète (LOAD DATA) et qu'il est nécessaire d'utiliser la méthode expliquée dans le paragraphe suivant (celle préconisée par MySQL) pour remettre sur pieds la réplication.

Deuxième méthode

Pour faciliter les choses, j'ai créé un script Shell sur le master et sur chaque Slave. Il permet d'effectuer une resynchro globale et complète en quelques minutes, sans trop interrompre le service.

Attention toutefois: les scripts peuvent (surtout sur Nord) locker le MySQL sans avertissements - pas toujours, mais ça peut arriver. Dans ces cas là (le mysql est toujours en marche, mais toutes les requetes sont en "Waiting For Table" (ou similaire) dans le Show Processlist), il faut rédémarrer le mysqld le plus rapidement possible.

Autre problème pouvant survenir: Des fois, après un reboot de Nord, il est possible que le mysql de Nord soit dans un état très instable même s'il semble être OK (requetes SQL fonctionnelles, certains slaves arrivant à se resynchroniser). Les symptomes sont: certains slaves ne peuvent etre stoppés autrement que par kill -9. Dans ce cas, il faut stopper et redémarrer le mysqld de Nord.

Le script Shell est nommé /var/db/Replication/Syncer.sh sur toutes les machines (Nord et les Slaves), mais le script présent Nord n'a pas exactement les memes fonctions que les scripts présents sur les slaves.

Procédure à suivre :

• Sur Nord, executer : /var/db/Replication/Syncer.sh --lock

Pour info, sur Nord le script effectue alors les actions suivantes :

- FLUSH TABLES WITH READ LOCK
- Copie binaires des tables dans un répertoire temporaire
- RESET MASTER
- UNLOCK TABLES
- Démarrage d'un daemon rsync qui va permettre d'exporter les tables binaires vers les slaves. 
  Ce daemon rsync est lancé en avant-plan : il faudra taper Ctrl+C sur Nord pour le stopper, une fois que
  les slaves auront téléchargé les bases au format binaire.

• Sur chaque slave (l'un après l'autre pour ne pas surcharger Nord), executer : /var/db/Replication/Syncer.sh

Pour info, sur les slaves le script effectue alors les actions suivantes :

- Import des bases binaires, dans un répertoire temporaire, depuis le rsync lancé sur Nord
- Arret du serveur MySQL local sur le slave
- Remplacement des bases désynchronisées par les bases binaires importées depuis Nord
- Effacement des infos de synchronisation - équivalent à un RESET SLAVE
- Redémarrage du MySQL local
- Le MySQL se reconnecte au master, et la synchro reprend.

Une fois que tous les slaves sont correctement resynchronisés, arreter le daemon Rsync lancé sur Nord (en tapant Ctrl+C).

• Procédure manuelle sur un slave

mysql> CHANGE MASTER TO
    -> MASTER_HOST='sarthe.fr.clara.net',
    -> MASTER_PORT=3306,
    -> MASTER_USER='clara_replic',
    -> MASTER_PASSWORD='xxxx',
    -> MASTER_LOG_FILE='xxxxxxx',
    -> MASTER_LOG_POS=xx;
Query OK, 0 rows affected (0.00 sec)

Synchro

• Relance de synchro sur les slave en mysql 5 :

stop slave;

show databases;

drop database easy; drop database clarapw;

create database easy; create database clarapw; create database internal; create database postfix;

load data from master;

start slave;

show slave status \G

- Relancer la synchro pour 1 seul slave: sur le master, lancer le script /var/db/Replication/Master_Syncher.sh ---no-lock (le laisser lancé), puis sur le slave lancer le script /var/db/Replication/Syncer.sh

Pour resynchroniser tous les slaves, sur le master : /var/db/Replication/Master_Syncher.sh --lock

Puis :

- Commande de synchro : sur le slave : stop slave / sur le master : SHOW MASTER STATUS; récuperer le nom du fichier et la position / sur le slave : CHANGE MASTER TO MASTER_LOG_POS = 49575998 , MASTER_LOG_FILE = "mysql-bin.000023"; start slave

(CHANGE MASTER TO MASTER_HOST="mysql2.co.fr.clara.net", MASTER_USER="clara_replic", MASTER_PASSWORD="cl3r3r3pl1c", MASTER_LOG_FILE="mysql-bin.000001", MASTER_LOG_POS=2452; slave stop; reset slave;)

INSERT INTO `user` ( `Host` , `User` , `Password` , `Select_priv` , `Insert_priv` , `Update_priv` , `Delete_priv` , `Create_priv` , `Drop_priv` , `Reload_priv` , `Shutdown_priv` , `Process_priv` , `File_priv` , `Grant_priv` , `References_priv` , `Index_priv` , `Alter_priv` ) VALUES ( 'localhost', 'u_cpop_ng', 'xxxxpasswordxx', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N' );