Escravo de replicação gtid do mysql 5.6 travado (bloqueio do sistema)?

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

  •  29-09-2020
  •  | 
  •  

Pergunta

Eu configurei a replicação baseada em 5.6 gtid (em 5.6.26) e pareceu funcionar quando fiz isso, ele replicou meu banco de dados de teste aleatório sobre o que criei além dos dados normais.Porém em algum momento algo deve ter acontecido porque tudo que vejo é isto:

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

agora originalmente "Slave_SQL_Running_State" dizia "lendo evento do log de retransmissão" ou algo parecido, agora também mudou para bloqueio do sistema (o estado IO sempre dizia isso).

Parece que Seconds_Behind_Master está aumentando constantemente e o tamanho do log de retransmissão cresce rapidamente no sistema de arquivos, enquanto Executed_gtid_set parece mudar, mas ainda assim algo parece errado porque está muito atrás...

Aqui está a lista de processos:

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

Tentei parar o escravo e reiniciá-lo, mas não adiantou.

Alguém tem alguma idéia do que eu poderia tentar fazer isso funcionar novamente?Seria muito apreciado.

Obrigado

Foi útil?

Solução

Já que vejo mais de 2 system user entradas na lista de processos, presumo que você esteja usando replicação multithread (escravo_paralelo_trabalhadores > 1).

Isso parece um bug

Em 29 de outubro de 2014, isso foi expresso por David Moss

Obrigado pelo seu feedback.Este problema foi abordado no bug 17326020 e o seguinte foi adicionado aos changelogs do MySQL 5.6.21 e 5.7.5:

Quando o thread de E/S se reconectou a um mestre usando GTIDs e escravos multithreaded enquanto no meio de uma transação, ele falhou para abortar a transação, deixando uma transação parcial no relé e, em seguida, recuperando a mesma transação novamente.Isso ocorreu ao executar uma rotação do log de relé.Agora, ao se reconectar, o servidor verifica antes de girar o log nesses casos e aguarda primeiro para que qualquer transação em andamento seja concluída.

Portanto, nada de novo será adicionado para cobrir esse bug e estou encerrando-o como corrigido.

Em 10 de dezembro de 2014, isso foi expresso por Laurynas Biveinis

Problema:

Com MTS, GTIDs e posicionamento automático ativados, quando um trabalhador aplica um transação parcial deixada no relaylog por uma reconexão de thread de E/S, ele aguardará o evento de log XID para confirmar a transação.

Infelizmente, o coordenador de thread SQL chegará ao mestre ROTATE no próximo arquivo relaylog e aguardará por todos os trabalhadores para concluir suas tarefas antes de aplicar o ROTATE.

Análise:

Como toda a transação é recuperada novamente pelo thread de E/S após o reconexão, o escravo deve reverter a transação parcial uma vez percebendo este GIRAR do mestre.

Este bug relata o mesmo problema já corrigido pelo BUG#17326020, e o O problema relatado não é mais reproduzível.Então, este patch é apenas adicionando um novo caso de teste.

SUGESTÃO

Correr FLUSH BINARY LOGS; no Mestre

Veja se o movimento desencadeia uma resposta dos threads SQL.

Se isso não acontecer, vá em frente e remova escravo_paralelo_trabalhadores de my.cnf e reinicie o mysql.

Desde que você iniciou o MySQL como mestre e escravo e obteve error 1236, isso significa que você está tentando estabelecer a replicação de uma posição impossível.No contexto do GTID e da mensagem de erro que você recebeu, os logs binários necessários para identificar completamente um conjunto de consultas dentro de um conjunto GTID não existem mais,

Olhe para trás, para o seu SHOW SLAVE STATUS\G

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

A partir disso, o último GTID executado é 7846a847-62c7-11e5-91a6-e06995de432e:4783274

Isso significa que o log binário que possui ou teve 7846a847-62c7-11e5-91a6-e06995de432e:4783275 não existe mais.

Posso ver isso acontecendo se você interrompeu a replicação no Slave, deixou a replicação desativada por tempo suficiente para o Master girar seus logs binários (via expire_logs_days) que o escravo ainda precisava ver e, em seguida, ativou a replicação.

No seu caso particular, tente fazer um dump mysqlbinlog do log binário mysqld-bin.000141.Se nada acontecer, você terá que recarregar o Slave e configurar a replicação do zero.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a dba.stackexchange
scroll top