Como posso solucionar o erro "Esperando que o thread SQL secundário libere espaço suficiente no log de retransmissão" no Amazon Aurora MySQL?

Breve descrição

Quando o Aurora MySQL é uma réplica da replicação de log binário, ele executa o thread E/S e o thread SQL da mesma forma que o MySQL. O thread E/S lê os logs binários do primário e os salva como logs de retransmissão na instância de banco de dados de réplica. O thread SQL processa os eventos nos logs de retransmissão e, em seguida, os exclui quando os eventos nos logs de retransmissão são processados.

Se o thread SQL não processar eventos com rapidez suficiente para acompanhar a velocidade com que os logs de retransmissão estão sendo gerados, a quantidade de logs de retransmissão aumentará.

Quando a variável global relay_log_space_limit é definida como maior que 0 e o tamanho total de todos os logs de retransmissão atinge o limite, os novos não são salvos. Até que o espaço de log de retransmissão fique disponível novamente, a saída de SHOW SLAVE STATUS exibe a mensagem "Esperando que o thread SQL secundário libere espaço suficiente no log de retransmissão" no campo Slave_IO_State.

No Aurora MySQL, relay_log_space_limit está definido como 1000000000 (953,6 MiB) e não pode ser modificado. Isso evita que o volume do cluster se torne desnecessariamente grande. Quando o tamanho total de todos os logs de retransmissão atinge 1000000000 bytes (953,6 MiB) o thread de E/S para de salvá-los. Ele espera que o thread SQL processe eventos e exclua os logs existentes. Slave_IO_State então exibe a mensagem "Esperando que o thread SQL secundário libere espaço suficiente no log de retransmissão". Se o thread SQL não for interrompido, os logs de retransmissão eventualmente serão excluídos e o thread E/S continuará salvando novos logs de retransmissão.

Isso também significa que o atraso na replicação existe porque o SQL não é rápido o suficiente para acompanhar a geração de logs de retransmissão pelo thread E/S. Mesmo que relay_log_space_limit seja modificado para um valor maior, os logs de retransmissão ainda se acumulam e o problema não é resolvido até que o thread SQL se atualize.

Você pode visualizar o espaço atual do log de retransmissão, o status do thread E/S e o status do thread SQL na saída do comando SHOW SLAVE STATUS.

Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: mysql-bin-changelog.237029
Read_Master_Log_Pos: 55356151
Relay_Master_Log_File: mysql-bin-changelog.237023
Exec_Master_Log_Pos: 120
Relay_Log_Space: 1000002403

Master_Log_File e Read_Master_Log_Pos exibem o nome do arquivo de log binário e a posição em que o thread E/S concluiu a leitura e salvou. Relay_Master_Log_File e Exec_Master_Log_Pos exibem o nome do arquivo de log binário e a posição em que o thread SQL está sendo processado. Apesar do thread SQL, na verdade, ler os logs de retransmissão, são exibidos o nome do arquivo de log binário correspondente na instância de banco de dados primária e a posição.

Quando Master_Log_File é diferente de Relay_Master_Log_File, o thread SQL não é rápido o suficiente. Se Master_Log_File e Relay_Master_Log_File forem iguais, o thread E/S pode estar contribuindo para o atraso.

Os seguintes fatores podem causar performance insuficiente do thread SQL:

• Consultas de longa duração na instância de banco de dados primária
• Tamanho ou armazenamento insuficientes da classe da instância de banco de dados
• Consultas paralelas realizadas na instância de banco de dados primária
• Logs binários sincronizados com o disco na instância de banco de dados de réplica
• Binlog_format na instância de banco de dados de réplica está definido como ROW

Para obter mais informações sobre como resolver esses problemas, consulte Como posso solucionar muito atraso da réplica com o Amazon RDS para MySQL

Além disso, os seguintes fatores também podem afetar a performance do thread SQL:

• Um comprimento de lista de histórico de transações (HLL) muito grande na instância de banco de dados de réplica
• Operações de E/S menos eficientes na instância de banco de dados de réplica
• Tabelas com muitos índices secundários na instância de banco de dados de réplica

Resolução

Desde que haja gravações acontecendo em sua réplica, você não precisa se preocupar com o espaço de log de retransmissão. Você pode monitorar isso usando a métrica Write Throughput no Monitoramento avançado.

Em vez disso, foque em solucionar o problema da performance da réplica. Para obter mais detalhes, consulte Como posso solucionar muito atraso da réplica com o Amazon RDS para MySQL e Por que minha réplica de leitura do Amazon Aurora ficou para trás e foi reiniciada?

---

Informações relacionadas

Documentação do MySQL para Opções e variáveis do servidor de réplica