Comment re-synchroniser la base de données Mysql si le maître et l'esclave ont des bases de données différentes en cas de réplication Mysql ?

Question

Mysql Server1 est en cours d'exécution en tant que MASTER .
Mysql Server2 est en cours d'exécution en tant que ESCLAVE .

Maintenant, la réplication de la base de données se fait à partir de MASTER à ESCLAVE .

Server2 est retiré du réseau et le reconnecter après 1 jour. Après cela, il y a un désaccord dans la base de données du maître et de l'esclave.

Comment re-synchroniser la base de données car la restauration de la base de données du maître vers l'esclave ne résout pas le problème ?

Answer 1

Voici la procédure complète, étape par étape, pour resynchroniser une réplication maître-esclave à partir de zéro :

Au maître :

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Et copier les valeurs du résultat de la dernière commande quelque part.

Sans fermer la connexion au client (car cela libérerait le verrou de lecture), lancez la commande pour obtenir un dump du maître :

mysqldump -u root -p --all-databases > /a/path/mysqldump.sql

Vous pouvez maintenant libérer le verrou, même si la décharge n'est pas encore terminée. Pour ce faire, exécutez la commande suivante dans le client MySQL :

UNLOCK TABLES;

Maintenant, copiez le fichier dump vers l'esclave en utilisant scp ou votre outil préféré.

A l'esclave :

Ouvrez une connexion à mysql et tapez :

STOP SLAVE;

Chargez le vidage de données du maître avec cette commande de console :

mysql -uroot -p < mysqldump.sql

Synchroniser les journaux de l'esclave et du maître :

RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;

Où les valeurs des champs ci-dessus sont celles que vous avez copiées auparavant.

Enfin, tapez :

START SLAVE;

Pour vérifier que tout fonctionne à nouveau, après avoir tapé :

SHOW SLAVE STATUS;

vous devriez voir :

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

C'est ça !

Answer 2

La documentation à ce sujet sur le site MySQL est terriblement obsolète et truffée d'erreurs (comme interactive_timeout). L'émission de FLUSH TABLES WITH READ LOCK dans le cadre de votre exportation du master n'a généralement de sens que lorsqu'elle est coordonnée avec un snapshot du système de stockage/de fichiers tel que LVM ou zfs.

Si vous utilisez mysqldump, vous devriez plutôt compter sur l'option --master-data pour vous prémunir contre les erreurs humaines et libérer les verrous sur le master aussi rapidement que possible.

Supposons que le maître soit 192.168.100.50 et l'esclave 192.168.100.51, que chaque serveur ait un server-id distinct configuré, que le maître ait une connexion binaire et l'esclave une lecture seule = 1 dans my.cnf.

Pour que l'esclave puisse démarrer la réplication juste après avoir importé le dump, lancez une commande CHANGE MASTER mais omettez le nom et la position du fichier journal :

slaveserver> CHANGE MASTER TO MASTER_HOST='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';

Émettez le GRANT sur le maître pour que l'esclave l'utilise :

masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';

Exporter le master (en écran) en utilisant la compression et en capturant automatiquement les coordonnées binaires correctes du journal :

mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz

Copiez le fichier replication.sql.gz sur l'esclave, puis importez-le avec zcat sur l'instance de MySQL exécutée sur l'esclave :

zcat replication.sql.gz | mysql

Démarrez la réplication en envoyant la commande à l'esclave :

slaveserver> START SLAVE;

En option, mettez à jour le fichier /Root/.my.cnf sur l'esclave afin de stocker le même mot de passe Root que le maître.

Si vous êtes sur 5.1+, il est préférable de définir d'abord le binlog_format du maître sur MIXED ou ROW. Attention, les événements enregistrés par rangée sont lents pour les tables qui n'ont pas de clé primaire. Cette configuration est généralement meilleure que la configuration alternative (et par défaut) de binlog_format=statement (sur le maître), car elle est moins susceptible de produire des données erronées sur l'esclave.

Si vous devez (mais ne devriez probablement pas) filtrer la réplication, faites-le avec les options esclaves replicate-wild-do-table=dbname.% ou replicate-wild-ignore-table=badDB.% et utilisez seulement binlog_format=row

Ce processus détiendra un verrou global sur le maître pour la durée de la commande mysqldump mais n'aura pas d'autre impact sur le maître.

Si vous êtes tenté d'utiliser mysqldump --master-data --all-databases --single-transaction (parce que vous n'utilisez que des tables InnoDB), vous avez peut-être intérêt à utiliser MySQL Enterprise Backup ou l'implémentation open source appelée xtrabackup (avec l'aimable autorisation de Percona).

Answer 3

À moins que vous n'écriviez directement sur l'esclave (Server2), le seul problème devrait être que Server2 manque les mises à jour qui ont eu lieu depuis qu'il a été déconnecté. Il suffit de redémarrer l'esclave avec "START SLAVE ;" pour que tout rentre dans l'ordre.

Answer 4

Je pense que les utilitaires Maatkit sont utiles pour vous ! Vous pouvez utiliser mk-table-sync. Veuillez consulter ce lien : http://www.maatkit.org/doc/mk-table-sync.html

Answer 5

Voici ce que je fais généralement lorsqu'un esclave mysql n'est pas synchronisé. J'ai regardé mk-table-sync mais j'ai trouvé que la section Risques était effrayante.

Sur le maître :

SHOW MASTER STATUS

Les colonnes sorties (Fichier, Position) nous seront utiles dans un instant.

Sur Slave :

STOP SLAVE

Ensuite, videz la base de données maître et importez-la dans la base de données esclave.

Ensuite, exécutez ce qui suit :

CHANGE MASTER TO
  MASTER_LOG_FILE='[File]',
  MASTER_LOG_POS=[Position];
START SLAVE;

Où [Fichier] et [Position] sont les valeurs produites par la commande "SHOW MASTER STATUS" ci-dessus.

J'espère que cela vous aidera !