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

8

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

Quelqu'un est allé voir l'esclave et a créé une table, puis est ensuite allé voir le maître et a créé la même table. Bien sûr, cette instruction DDL a été répliquée sur l'esclave, provoquant une erreur, provoquant l'arrêt de la réplication au point de l'erreur.

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

affiche la sortie d'é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 '[email protected]: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'
mysql mysql-replication ʞɔıu
la source

Réponses:

15

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 1représente le nombre d'instructions à ignorer. Vous pouvez le faire à plusieurs reprises jusqu'à ce que la réplication soit corrigée. Vous pouvez voir cette page .

Khaled
la source
2
+1 Je l'ai utilisé plusieurs fois, mais il est important de comprendre ce que vous faites lorsque vous exécutez cela. 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 case (c'est-à-dire que l'esclave n'est pas maître), j'ai sauté des centaines de requêtes (après avoir vérifié cela, cela ne fera aucun mal!). Cela peut éviter le processus de réinitialisation de l'ensemble de la réplication.
Coops
Oui, tu as raison. Cela doit être fait avec soin. Il est utile dans le cas où vous avez une requête non valide qui a arrêté la réplication. Vous pouvez simplement le sauter. Vous pouvez également vérifier les tables pertinentes après cela pour vous assurer que vous n'avez pas perdu de données entre le maître et l'esclave.
Khaled
3

Non. En effet, vous devez reconfigurer la réplication à partir de zéro comme vous l'avez fait la première fois, car si vous sautez simplement des instructions, 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.

  • Verrouillez le maître
  • Vider les données en utilisant --master-data et en notant les coordonnées binlog (par exemple afficher l'état du maître)
  • Déverrouillez le maître
  • Charger la décharge dans l'esclave
  • Commencez à asservir en utilisant 'change master' et les coordonnées binlog que vous avez enregistrées plus tôt
dotplus
la source