13 votes

Redémarrer la réplication mysql après sql_error

J'ai deux serveurs mysql, un maître et un esclave.

Quelqu'un s'est rendu sur l'esclave et a créé une table, puis s'est ensuite rendu sur le maître et a créé la même table. Bien entendu, cette instruction DDL a été répliquée sur l'esclave, ce qui a provoqué une erreur, entraînant l'arrêt de la réplication au point d'erreur.

Comment dois-je redémarrer le processus de réplication après avoir abandonné la table sur l'esclave ou après avoir démarré la réplication après cette déclaration ?

sortie de l'état de l'esclave :

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: xx.xx.xx.xx
                  Master_User: buildbot
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.024536
          Read_Master_Log_Pos: 33489509
               Relay_Log_File: mysqld-relay-bin.049047
                Relay_Log_Pos: 32575097
        Relay_Master_Log_File: mysql-bin.024476
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1050
                   Last_Error: Error 'Table 'checklist' already exists' on query. Default database: 'dbname'. Query: 'CREATE TABLE `checklist` (
  `checklist_id` int(11) NOT NULL AUTO_INCREMENT,
  `description` varchar(768) NOT NULL,
  `url` varchar(512) NOT NULL,
  `active` bit(1) NOT NULL,
  `insert_date` datetime NOT NULL,
  `xcred` int(11) NOT NULL,
  PRIMARY KEY (`checklist_id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1'
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 32574952
              Relay_Log_Space: 6766519525
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 2013
                Last_IO_Error: error reconnecting to master 'user@xx.xx.xx.xx:3306' - retry-time: 60  retries: 86400
               Last_SQL_Errno: 1050
               Last_SQL_Error: Error 'Table 'checklist' already exists' on query. Default database: 'dbname'. Query: 'CREATE TABLE `checklist` (
  `checklist_id` int(11) NOT NULL AUTO_INCREMENT,
  `description` varchar(768) NOT NULL,
  `url` varchar(512) NOT NULL,
  `active` bit(1) NOT NULL,
  `insert_date` datetime NOT NULL,
  `xcred` int(11) NOT NULL,
  PRIMARY KEY (`checklist_id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1'

25voto

Khaled Points 35208

Vous pouvez utiliser les commandes suivantes (à l'invite mysql) :

mysql> STOP SLAVE;
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS;

La valeur 1 représente le nombre de déclarations à sauter. Vous pouvez le faire à plusieurs reprises jusqu'à ce que la réplication soit corrigée. Vous pouvez voir cette page .

4 votes

+1 Je l'ai utilisé de nombreuses fois, mais il est important de comprendre ce que vous faites lorsque vous l'exécutez. Cela peut entraîner des problèmes d'intégrité des données. Dans les cas où un fichier de vidage a été chargé dans la mauvaise boîte (c'est-à-dire esclave et non maître), j'ai sauté des centaines de requêtes (après avoir vérifié au préalable que cela ne faisait pas de mal !) Cela peut éviter le processus de réinstallation de l'ensemble de la réplication.

2 votes

Oui, vous avez raison. Cela doit être fait avec précaution. C'est utile dans le cas où vous avez une requête invalide qui a arrêté la réplication. Vous pouvez simplement l'ignorer. Vous pouvez également vérifier la ou les tables concernées après cette opération pour vous assurer que vous n'avez pas perdu de données entre le maître et l'esclave.

0 votes

Cela peut également être fait sur phpMyAdmin dans l'onglet "réplication". imgur.com/vonwUQU

3voto

Ryan P Points 1716

Tu ne le fais pas. En fait, vous devez configurer la réplication à nouveau à partir de zéro, comme vous l'avez fait la première fois, car si vous sautez des déclarations, vous risquez de perdre l'intégrité. Pour être sûr, vous devez répliquer à partir d'un point de départ sûr connu.

  • Verrouiller le maître
  • Videz les données en utilisant --master-data et en notant les coordonnées binlog (e.g. show master status)
  • Déverrouiller le maître
  • Charger le dump dans l'esclave
  • Commencez l'esclavage en utilisant 'change master' et les coordonnées binlog que vous avez enregistrées plus tôt

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X