MySQL 5.6 GTID Schiavo di replica bloccato (blocco del sistema)?

dba.stackexchange https://dba.stackexchange.com/questions/117068

  •  29-09-2020
  •  | 
  •  

Domanda

Ho impostato 5,6 Replica basata su GTID (il 5.6.26) Sembrava funzionare quando l'ho fatto, ha replicato il mio test casuale DB su quello che ho creato accanto ai dati normali. Tuttavia ad un certo punto qualcosa deve essere successo perché tutto quello che vedo è questo: 

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
.

Ora originariamente "slave_sql_running_state" ha detto "Lettura evento dal registro relè" o qualcosa del genere, ora è cambiato anche in serratura del sistema (lo stato IO ha sempre detto questo).

Sembra che il Seconds_Behind_Master stia aumentando costantemente e il registro relè cresce rapidamente nella dimensione del filesystem, mentre Executed_gtid_set sembra cambiare, ma ancora qualcosa sembra sbagliato perché è così tanto dietro ....

Ecco la lista del processo: 

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             |
+------+-------------+-----------+------+---------+-------+---------------------------------------+------------------+
.

Ho provato a fermare lo schiavo e iniziarlo di nuovo ma non ha aiutato.

Qualcuno ha idee cosa potrei provare a rendere di nuovo questo lavoro?Sarebbe molto apprezzato.

Grazie

È stato utile?

Soluzione

Dato che vedo più di 2 voci system user nella lista dei processlist, presumerei che stiate utilizzando la replicazione multi-thread ( slave_parallel_workers > 1).

Sembra un bug

Il 29 ottobre 2014 è stato espresso da David Moss

.

Grazie per il tuo feedback. Questo problema è stato coperto da Bug 17326020 e il seguente è stato aggiunto al mysql 5.6.21 e 5.7.5 Changelogs:

Quando il filo I / O ricollegato a un master utilizzando GTID e schiavi multithreading mentre nel mezzo di una transazione, è fallito per interrompere la transazione, lasciando una transazione parziale nel relè log, quindi recupera di nuovo la stessa transazione. Questo è avvenuto Quando si esegue una rotazione del registro relè. Ora quando si ricollega, Il server controlla prima di ruotare il registro in questi casi e attendere prima per completare la transazione in corso.

Pertanto non sarà aggiunto nulla di nuovo per coprire questo bug e lo sto chiudendo come fisso.

Il 10 dicembre 2014 è stato espresso da Laurynas Biveinis

.

Problema:

con MTS, GTIDS e posizionamento automatico abilitati, quando un lavoratore applica a Transazione parziale lasciata sul relylog di una riconnessione del filo IO, esso Aspetterà l'evento del registro XID per commettere la transazione.

Sfortunatamente, il coordinatore del filo SQL raggiungerà il master Ruota l'evento nel prossimo file del relylog e aspetterà tutti i lavoratori per completare i loro compiti prima di applicare la rotazione.

Analisi:

Come l'intera transazione viene nuovamente recuperata dal thread IO dopo il Riconnessione, lo schiavo deve rollback la transazione parziale una volta Notando questo ruota dal master.

Questo bug segnala lo stesso problema già fissato da bug # 17326020 e il il problema segnalato non è più riproducibile. Quindi, questa patch è solo Aggiunta di un nuovo caso di prova.

suggerimento

Esegui FLUSH BINARY LOGS; sul master

Vedere se il movimento attiva una risposta dai fili SQL.

Se non lo fa, vai avanti e rimuovi slave_parallel_workers da my.cnf e riavviare mysql.

Dato che hai iniziato a mysql up e master e slave e hai ottenuto error 1236, ciò significa che stai cercando di stabilire la replica da una posizione impossibile. Nel contesto del messaggio GTID ed errore che hai ottenuto, i registri binari necessari per identificare completamente un set di query all'interno di un set GTID non esiste più,

guarda indietro al tuo SHOW SLAVE STATUS\G 

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

Da questo, l'ultimo GTID eseguito è 7846a847-62c7-11e5-91a6-e06995de432e:4783274

Ciò significa che il registro binario che ha o ha avuto 7846a847-62c7-11e5-91a6-e06995de432e:4783275 non esiste più.

Posso vedere questo accadendo se hai interrotto la replica sullo slave, la replica sinistra è sufficientemente a sinistra per il master per ruotare i suoi registri binari (tramite Expire_logs_days) lo slave ancora necessario per vedere, quindi attivato la replica.

Nel tuo caso particolare, prova a fare una discarica mysqlbinlog del registro binario mysqld-bin.000141. Se nulla ne deriva, dovrai ricaricare lo slave e la configurazione della replica da zero.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a dba.stackexchange
scroll top