Escravo de replicação gtid do mysql 5.6 travado (bloqueio do sistema)?
-
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
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
- Erro #73066:Paralisação de replicação com replicação multithread
- Erro #72794:Log de retransmissão sem xid_log_event pode travar a replicação paralela
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.