mysql 5.6 gtid esclave de réplication coincé (système de verrouillage)?

Question

J'ai mis en place 5.6 gtid en fonction de réplication (sur 5.6.26) il semblait fonctionner quand je l'ai fait, il répliqué mon test aléatoire db de plus que j'ai créé à côté de la normale des données.Cependant, à un certain moment, quelque chose s'est passé parce que je ne vois ceci:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: System lock
                  Master_Host: xxxxxxxxxxxxxxxxxx
                  Master_User: xxxxxxxxxxxxxxxx
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysqld-bin.000141
          Read_Master_Log_Pos: 169293671
               Relay_Log_File: mysqld-relay-bin.000003
                Relay_Log_Pos: 16861206
        Relay_Master_Log_File: mysqld-bin.000141
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 16860994
              Relay_Log_Space: 169298584
              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: 55203
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: 7846a847-62c7-11e5-91a6-e06995de432e
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
            Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274
                Auto_Position: 1

a l'origine, "Slave_SQL_Running_State", a déclaré "la lecture de l'événement de relais journal" ou quelque chose comme ça, il a maintenant changé de système de verrouillage de (IO état toujours dit que).

Il semble que le Seconds_Behind_Master est en constante augmentation, et le relais du journal se développe rapidement en taille sur le système de fichiers, tandis que Executed_gtid_set ne semble pas changer, mais toujours quelque chose semble faux, car il est tout simplement beaucoup de retard....

Voici la processlist:

mysql> show processlist;
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| Id   | User        | Host      | db   | Command | Time  | State                                 | Info             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
| 1877 | root        | localhost | NULL | Sleep   |  6076 |                                       | NULL             |
| 1878 | root        | localhost | NULL | Query   |     0 | init                                  | show processlist |
| 1886 | system user |           | NULL | Connect |   783 | System lock                           | NULL             |
| 1887 | system user |           | NULL | Connect |     0 | System lock                           | NULL             |
| 1888 | system user |           | NULL | Connect |   783 | Waiting for an event from Coordinator | NULL             |
| 1889 | system user |           | NULL | Connect | 55455 | System lock                           | NULL             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+

J'ai essayé d'arrêter l'esclave et le démarrer à nouveau, mais il na pas aider.

Quelqu'un a une idée de ce que je pouvais essayer de faire fonctionner à nouveau?Serait très apprécié.

Merci

Answer 1

Depuis je ne vois plus que 2 system user les entrées dans le processlist, je suppose que vous êtes en utilisant le Multi-thread (Réplicationslave_parallel_workers > 1).

Qui ressemble à un bug

• Bug #73066 :La réplication de décrochage avec le multi-thread de réplication
• Bug #72794 :Relais journal sans xid_log_event peut cas parallèle de la réplication de l'accrocher

Oct 29, 2014, cela a été exprimé par David Moss

Merci pour vos commentaires.Cette question a été traitée dans le bogue 17326020 et le suivant a été ajouté à la base de 5.6.21 et 5.7.5 changelog:

Lorsque le thread d'e/S reconnecté à un master à l'aide GTIDs et multithread esclaves tandis que dans le milieu d'une transaction, il n'a pas pour annuler la transaction, laissant une transaction partielle dans le relais le journal, puis extraction de la même opération à nouveau.Cela s'est produit lorsque vous effectuez une rotation du relais du journal.Maintenant, lors de la reconnexion, le serveur vérifie avant de rotation du journal dans de tels cas, et attend d'abord pour toute transaction.

Donc rien de nouveau ne sera ajouté pour couvrir ce bug et je suis de clôture comme résolu.

Sur Décembre 10, 2014, cela a été exprimé par Laurynas Biveinis

Problème:

Avec MTS, GTIDs et auto positionnement activé, lorsqu'un travailleur s'applique à un transaction partielle gauche sur relaylog par un IO fil de la reconnexion, il vais attendre pour le XID journal des événements pour valider la transaction.

Malheureusement, le thread SQL coordonnateur de parvenir à la maîtrise de l' Faites TOURNER l'événement sur la prochaine relaylog fichier et attendre pour l'ensemble des travailleurs pour terminer leurs tâches avant d'appliquer la ROTATION.

Analyse:

Comme l'ensemble de la transaction est extraite à nouveau par l'OI fil après l' la reconnexion, l'esclave doit rollback de la transaction partielle une fois remarquant le faire PIVOTER à partir de le maître.

Ce bug rapports le même problème déjà résolu par le BOGUE#17326020, et la question n'est pas reproductible en plus.Donc, ce patch est juste l'ajout d'un nouveau cas de test.

SUGGESTION

Exécuter FLUSH BINARY LOGS; sur le Maître

Voir si le mouvement déclenche une réponse du SQL threads.

Si cela ne fonctionne pas, aller de l'avant et retirez slave_parallel_workers à partir de my.cnf et redémarrer mysql.

Depuis que vous avez commencé MySQL et maître et de l'esclave et a obtenu error 1236, cela signifie que vous essayez d'établir la réplication à partir d'une position impossible.Dans le contexte de GTID et le message d'erreur que vous avez, le binaire journaux nécessaire pour bien identifier un ensemble de requêtes dans un GTID jeu n'existe plus,

Regarder en arrière à votre SHOW SLAVE STATUS\G

Retrieved_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:4757140-5030085
 Executed_Gtid_Set: 7846a847-62c7-11e5-91a6-e06995de432e:1-4783274

De ce fait, la dernière GTID est exécuté 7846a847-62c7-11e5-91a6-e06995de432e:4783274

Cela signifie que le log binaire qui a ou a eu 7846a847-62c7-11e5-91a6-e06995de432e:4783275 n'existe plus.

Je peux voir ce qui se passe si vous avez arrêté de réplication sur l'Esclave, à gauche de la réplication hors suffisamment longtemps pour que le Maître de tourner son binaires journaux (via expire_logs_days) l'esclave encore besoin de le voir, puis se tourna sur la réplication.

Dans votre cas, essayez de faire une mysqlbinlog dump du log binaire mysqld-bin.000141.Si rien n'en sort, vous devrez recharger l'Esclave et la configuration de la réplication à partir de zéro.