Comment resynchroniser la base de données Mysql si le maître et l'esclave ont une base de données différente en cas de réplication de Mysql?
Mysql Server1 est exécuté en tant queMASTER.
Mysql Server2 est exécuté en tant queSLAVE.
Maintenant, la réplication de la base de données se passe deMAÎTREàESCLAVE.
Server2 est supprimé du réseau et reconnecté après un jour. Après cela, il y a une incompatibilité dans la base de données maître et esclave.
Comment resynchroniser à nouveau la base de données car, après la restauration de la base de données passée de maître à esclave, le problème n'est pas résolu?
Il s'agit de la procédure complète à suivre pour resynchroniser une réplication maître-esclave à partir de zéro:
Chez le 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 en lecture), exécutez la commande pour obtenir un vidage du maître:
mysqldump -u root -p --all-databases > /a/path/mysqldump.sql
Vous pouvez maintenant libérer le verrou, même si le vidage n'est pas encore terminé. Pour ce faire, exécutez la commande suivante dans le client MySQL:
UNLOCK TABLES;
Copiez maintenant le fichier de vidage sur l’esclave à l’aide de scp ou de votre outil préféré.
Chez l'esclave:
Ouvrez une connexion à mysql et tapez:
STOP SLAVE;
Chargez le dump de données du maître avec cette commande de console:
mysql -uroot -p < mysqldump.sql
Synchroniser les journaux esclave et 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;
tu devrais voir:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
C'est tout!
La documentation à ce sujet sur le site MySQL est lamentablement obsolète et gâchée par des armes à feu (comme interactive_timeout). L'émission de FLUSH TABLES WITH READ LOCK dans le cadre de votre exportation du maître n'a généralement de sens que si elle est coordonnée avec un instantané de stockage/système de fichiers tel que LVM ou zfs.
Si vous allez utiliser mysqldump, vous devriez plutôt vous fier à l'option --master-data pour vous protéger contre les erreurs humaines et libérer les verrous du maître le plus rapidement possible.
Supposons que le maître est 192.168.100.50 et que l'esclave est 192.168.100.51, chaque serveur a un ID de serveur distinct configuré, le maître a une connexion binaire et l'esclave a un en lecture seule = 1 dans my.cnf.
Pour que l'esclave puisse démarrer la réplication juste après l'importation du dump, émettez 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';
Exportez le maître (à l'écran) en utilisant la compression et en capturant automatiquement les coordonnées correctes du journal binaire:
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 dans l'instance de MySQL s'exécutant sur l'esclave:
zcat replication.sql.gz | mysql
Démarrez la réplication en envoyant la commande à l'esclave:
slaveserver> START SLAVE;
Mettez éventuellement le répertoire /root/.my.cnf sur l'esclave pour stocker le même mot de passe racine que le maître.
Si vous êtes sur la version 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 consignés par ligne sont lents pour les tables dépourvues de clé primaire. Cela est généralement préférable à la configuration alternative (et par défaut) de binlog_format = statement (on master), car elle est moins susceptible de générer des données erronées sur l’esclave.
Si vous devez (mais probablement pas) filtrer la réplication, faites-le avec les options esclaves replicate-wild-do-table = nom_bd.% Ou replicate-wild-ignore-table = badDB.% Et utilisez uniquement binlog_format = row
Ce processus gardera un verrou global sur le maître pour la durée de la commande mysqldump mais n'aura pas autrement d'impact sur le maître.
Si vous êtes tenté d’utiliser mysqldump --master-data - toutes-bases de données - single-transaction (car vous n’utilisez que des tables InnoDB), il est peut-être préférable de vous servir de MySQL Enterprise Backup ou de l’implémentation à source ouverte appelée xtrabackup (avec la permission de Percona)
Sauf si vous écrivez directement sur l'esclave (Server2), le seul problème est qu'il manque à Server2 les mises à jour effectuées depuis sa déconnexion. Redémarrage simple de l'esclave avec "START SLAVE;" devrait tout remettre à la vitesse.
Je pense que Maatkit utilise de l'aide pour vous! Vous pouvez utiliser mk-table-sync. S'il vous plaît voir ce lien: http://www.maatkit.org/doc/mk-table-sync.html
Je suis très en retard sur cette question, mais j’ai rencontré ce problème et, après de nombreuses recherches, j’ai trouvé cette information de Bryan Kennedy: http://plusbryan.com/mysql-replication-without-downtime
Sur Master, effectuez une sauvegarde comme celle-ci:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data = 2 -A> ~/dump.sql
Maintenant, examinez l’en-tête du fichier et notez les valeurs pour MASTER_LOG_FILE et MASTER_LOG_POS. Vous en aurez besoin plus tard: head dump.sql -n80 | grep "MASTER_LOG"
Copiez le fichier "dump.sql" dans Slave et restaurez-le: mysql -u mysql-user -p <~/dump.sql
Connectez-vous à l'esclave mysql et exécutez une commande comme celle-ci: CHANGE MASTER TO MASTER_Host = 'maître-serveur-ip', MASTER_USER = 'replication-user', MASTER_PASSWORD = 'esclave-serveur-mot_de_passe', MASTER_LOG_FILE = ' valeur d'en haut ', MASTER_LOG_POS = valeur d'en haut; START SLAVE;
Pour vérifier la progression de Slave: SHOW SLAVE STATUS;
Si tout va bien, Last_Error sera vide et Slave_IO_State signalera «En attente de l'événement maître en attente d'envoi». Recherchez Seconds_Behind_Master qui indique la distance qui le sépare. YMMV. :)
Suite à la réponse de David ...
Utiliser SHOW SLAVE STATUS\G donnera une sortie lisible par l'homme.
Voici ce que je fais généralement lorsqu'un esclave mysql n'est plus synchronisé. J'ai consulté mk-table-sync mais je pensais que la section Risks était effrayante.
Sur le maître:
SHOW MASTER STATUS
Les colonnes sorties (Fichier, Position) nous seront utiles dans un instant.
Sur esclave:
STOP SLAVE
Puis videz la base de données principale et importez-la dans la base de données esclave.
Puis lancez ce qui suit:
CHANGE MASTER TO
MASTER_LOG_FILE='[File]',
MASTER_LOG_POS=[Position];
START SLAVE;
Où [Fichier] et [Position] sont les valeurs générées par "SHOW MASTER STATUS" présenté ci-dessus.
J'espère que cela t'aides!
parfois, il suffit de donner un coup de pied à l'esclave aussi
essayer
arrêter l'esclave;
réinitialiser l'esclave;
démarrer esclave;
montre le statut d'esclave;
assez souvent, esclaves, ils restent coincés les gars :)
Voici une réponse complète qui, espérons-le, aidera les autres ...
Je souhaite configurer la réplication mysql à l'aide de maître et d'esclave, et comme la seule chose que je savais, c'est qu'il utilise un ou plusieurs fichiers journaux pour se synchroniser. Si l'esclave se déconnecte et ne se synchronise pas, il ne devrait en théorie que se reconnecter. continue de lire le fichier journal à partir de là où il s’est arrêté, comme l’a mentionné malonso.
Voici donc le résultat du test après la configuration du maître et de l’esclave comme indiqué par: http://dev.mysql.com/doc/refman/5.0/fr/replication-howto.html ...
Pourvu que vous utilisiez la configuration maître/esclave recommandée et que vous n'écriviez pas sur l'esclave, lui et moi avions raison (dans la mesure où mysql-server 5.x est concerné). Je n'ai même pas eu besoin d'utiliser "START SLAVE;", il a juste rattrapé son maître. Mais il y a une valeur par défaut de 88000 tentatives toutes les 60 secondes, donc je suppose que si vous épuisez, vous devrez peut-être démarrer ou redémarrer l'esclave. Quoi qu'il en soit, pour ceux qui, comme moi, voulaient savoir si le fait d'avoir un esclave en mode hors connexion et de nouveau en sauvegarde nécessitait une intervention manuelle. Non, ce n'est pas le cas.
Peut-être que l’affiche originale était corrompue dans le ou les fichiers journaux? Mais le plus probablement pas seulement un serveur en mode hors connexion pendant une journée.
tiré de /usr/share/doc/mysql-server-5.1/README.Debian.gz qui a probablement du sens pour les serveurs non-debian:
* NOTES COMPLÉMENTAIRES SUR LA RÉPLICATION ===============================. Si le serveur MySQL agit en tant que Pour la réplication esclave, vous ne devriez pas définir --tmpdir pour qu'il pointe vers un répertoire d'un système de fichiers en mémoire ou vers un répertoire qui est effacé lors du redémarrage de l'hôte du serveur. Un esclave de réplication A besoin de certains de ses fichiers temporaires pour survivre au redémarrage de la machine afin de pouvoir répliquer les tables temporaires ou les opérations LOAD DATA INFILE. Si les fichiers Du répertoire de fichiers temporaires sont perdus au redémarrage du serveur, la réplication .__ échoue .
vous pouvez utiliser quelque chose de sql comme: show des variables comme 'tmpdir'; pour le savoir.
Ajout à la réponse populaire pour inclure cette erreur:
"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",
Réplication d'esclave en un coup:
Dans une fenêtre de terminal:
mysql -h <Master_IP_Address> -uroot -p
Après la connexion,
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Le statut apparaît comme suit: Notez que le numéro de position varie!
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | your_DB | |
+------------------+----------+--------------+------------------+
Exportez le dump de la même manière qu’il décrit " en utilisant un autre terminal "!
Quittez et connectez-vous à votre propre base de données (qui est l'esclave):
mysql -u root -p
Le type les commandes ci-dessous:
STOP SLAVE;
Importez le Dump comme indiqué (dans un autre terminal, bien sûr!) Et tapez les commandes ci-dessous:
RESET SLAVE;
CHANGE MASTER TO
MASTER_Host = 'Master_IP_Address',
MASTER_USER = 'your_Master_user', // usually the "root" user
MASTER_PASSWORD = 'Your_MasterDB_Password',
MASTER_PORT = 3306,
MASTER_LOG_FILE = 'mysql-bin.000001',
MASTER_LOG_POS = 98; // In this case
Une fois connecté, définissez le paramètre server_id (généralement, pour les DB nouveaux/non répliqués, il n'est pas défini par défaut),
set global server_id=4000;
Maintenant, démarrez l'esclave.
START SLAVE;
SHOW SLAVE STATUS\G;
Le résultat devrait être le même que celui décrit.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Remarque: une fois répliqués, le maître et l'esclave partagent le même mot de passe!
Reconstruction de l'esclave avec LVM
Voici la méthode que nous utilisons pour reconstruire les esclaves MySQL avec Linux LVM. Cela garantit un instantané cohérent tout en nécessitant un temps d'immobilisation très minime de votre maître.
Définissez le pourcentage de pages sales d'innodb max à zéro sur le serveur MySQL maître. Cela forcera MySQL à écrire toutes les pages sur le disque, ce qui accélérera considérablement le redémarrage.
set global innodb_max_dirty_pages_pct = 0;
Pour contrôler le nombre de pages modifiées, exécutez la commande.
mysqladmin ext -i10 | grep dirty
Une fois que le nombre cesse de diminuer, vous avez atteint le point de continuer. Ensuite, réinitialisez le maître pour effacer les anciens journaux de bac/journaux de relais:
RESET MASTER;
Exécutez lvdisplay pour obtenir le chemin LV
lvdisplay
La sortie ressemblera à ceci
--- Logical volume ---
LV Path /dev/vg_mysql/lv_data
LV Name lv_data
VG Name vg_mysql
Arrêtez la base de données master avec la commande
service mysql stop
Ensuite, mysql_snapshot sera le nouveau nom du volume logique. Si les binlogs sont placés sur le lecteur du système d'exploitation, ceux-ci doivent également être instantanés.
lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data
Relancer le maître avec la commande
service mysql start
Restaurer le paramètre de pages sales à la valeur par défaut
set global innodb_max_dirty_pages_pct = 75;
Exécutez à nouveau lvdisplay pour vous assurer que la photo est visible et visible.
lvdisplay
Sortie:
--- Logical volume ---
LV Path /dev/vg_mysql/mysql_snapshot
LV Name mysql_snapshot
VG Name vg_mysql
Monter l'instantané
mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot
Si vous avez un esclave MySQL en cours d'exécution, vous devez l'arrêter
service mysql stop
Ensuite, vous devez effacer le dossier de données MySQL
cd /var/lib/mysql
rm -fr *
Retour à maîtriser. Maintenant rsyncnez l'instantané sur l'esclave MySQL
rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/
Une fois que rsync est terminé, vous pouvez démonter et supprimer l’instantané.
umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot
Créer un utilisateur de réplication sur le maître si l'ancien utilisateur de réplication n'existe pas ou si le mot de passe est inconnu
GRANT REPLICATION SLAVE on *.* to 'replication'@'[SLAVE IP]' identified by 'YourPass';
Vérifiez que les fichiers de données/var/lib/mysql appartiennent à l'utilisateur mysql. Si vous le pouvez, vous pouvez omettre la commande suivante:
chown -R mysql:mysql /var/lib/mysql
Prochain enregistrement de la position binlog
ls -laF | grep mysql-bin
Vous verrez quelque chose comme
..
-rw-rw---- 1 mysql mysql 1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw---- 1 mysql mysql 1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw---- 1 mysql mysql 963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw---- 1 mysql mysql 65657162 Aug 28 16:44 mysql-bin.000020
Ici, le fichier journal maître est le numéro de fichier le plus élevé de la séquence et la position du journal bin est la taille du fichier. Notez ces valeurs:
master_log_file=mysql-bin.000020
master_log_post=65657162
Ensuite, démarrez l'esclave MySQL
service mysql start
Exécutez la commande change master sur l’esclave en exécutant les opérations suivantes:
CHANGE MASTER TO
master_Host="10.0.0.12",
master_user="replication",
master_password="YourPass",
master_log_file="mysql-bin.000020",
master_log_pos=65657162;
Enfin commencer l'esclave
SLAVE START;
Vérifier le statut de l'esclave:
SHOW SLAVE STATUS;
Assurez-vous que Slave IO est en cours d'exécution et qu'il n'y a pas d'erreur de connexion. Bonne chance!
BR, Juha Vehnia
J'ai récemment écrit ceci sur mon blog qui se trouve ici ... Il y a quelques détails supplémentaires mais l'histoire est la même.
http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html
Nous utilisons la technique de réplication maître-maître de MySQL et si un serveur MySQL dit que 1 est supprimé du réseau, il se reconnecte lui-même une fois la connexion rétablie et tous les enregistrements validés sur le serveur 2 qui était sur le réseau sont transférés. au serveur 1 qui a perdu la connexion après la restauration . Un thread esclave dans MySQL essaie de se connecter à son maître toutes les 60 secondes par défaut. Cette propriété peut être modifiée car MySQL a le drapeau "master_connect_retry = 5" où 5 est en seconde. Cela signifie que nous voulons une nouvelle tentative toutes les 5 secondes.
Mais vous devez vous assurer que le serveur qui a perdu la connexion n’affiche aucune validation dans la base de données car vous obtenez une copie de clé en double. Code d’erreur: 1062
J'ai créé un dépôt GitHub avec un script pour résoudre ce problème rapidement. Il suffit de modifier quelques variables et de les exécuter (d’abord, le script crée une sauvegarde de votre base de données).
J'espère que cela vous aidera (et aux autres également).
Comment réinitialiser (resynchroniser) la réplication maître-esclave MySQL