Solução de problemas de replicação devido à falta de registros

Ao usar o Amazon RDS para MySQL ou o MariaDB com replicação de log binário, você pode encontrar falhas de replicação em que o processo é interrompido devido à falta de registros em réplicas de leitura. Esta seção explica como diagnosticar e resolver esses problemas.

Causas comuns

A inconsistência de dados entre a origem e a réplica pode ser causada por um dos seguintes cenários:

• modificação manual de dados na réplica;

• transações ignoradas usando sql_replica_skip_counter (sql_slave_skip_counter, antes do MySQL 8.0.26);

• linhas ausentes na réplica durante a sincronização inicial de dados usando ferramentas de migração.

Identificar o problema

Um indicador comum desse problema é Error 1032, com a mensagem Can't find record. A seguinte mensagem de erro aparece no log de erros da réplica:

2025-11-04T21:24:11.038899Z 566 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': 
Worker 1 failed executing transaction 'ANONYMOUS' at source log 
mysql-bin-changelog.031523, end_log_pos 899; Could not execute Update_rows event on 
table test_replication.users; Can't find record in 'users', Error_code: 1032; handler 
error HA_ERR_KEY_NOT_FOUND; the event's source log mysql-bin-changelog.031523, 
end_log_pos 899, Error_code: MY-001032

nota

O formato do log de erros varia entre os mecanismos do MySQL e do MariaDB. Para ter informações sobre como recuperar os logs, consulte Como visualizar e listar arquivos de log do banco de dados.

Diagnosticar o problema

Para diagnosticar a falha na replicação:

• Analise os logs de erros da réplica para identificar onde a replicação foi interrompida. Você pode usar MY-010584 como palavra-chave de pesquisa.

• Execute SHOW REPLICA STATUS\G (SHOW SLAVE STATUS\G, antes do MySQL 8.0.22) na réplica e analise a coluna Last_Error:

  Last_Error: Coordinator stopped because there were error(s) in the worker(s). 
  The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' 
  at source log mysql-bin-changelog.031523, end_log_pos 899. See error log and/or 
  performance_schema.replication_applier_status_by_worker table for more details 
  about this failure or others, if any.

• Verifique o nome do arquivo de log binário e a posição em que o processo de replicação foi interrompido na instância de réplica. Você pode encontrar essas informações no log de erros da instância de réplica.

Analisar logs binários

Para investigar uma falha de replicação em uma transação específica, você pode usar o utilitário mysqlbinlog para examinar o arquivo de log binário. Por exemplo, se a replicação tiver falhado na posição 899 end_log_pos no arquivo de log binário mysql-bin-changelog.031523, você poderá analisar esse local específico para identificar a causa da falha.

nota

O valor end_log_pos indica a posição final do evento com falha. Na saída do log binário decodificado, procure o evento cuja end_log_pos corresponde a esse valor.

Use o utilitário mysqlbinlog para baixar e examinar o log binário pertinente. Use o endpoint para a instância primária.

$ mysqlbinlog --read-from-remote-server \
--host=<rds-endpoint> \
--port=3306 \
--user=<username> \
--password=<password> \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name

nota

O utilitário mysqlbinlog é uma ferramenta nativa do MySQL que ajuda a ler e interpretar o conteúdo do log binário. Para ter mais informações sobre como acessar logs binário no Amazon RDS, consulte Acessar logs binários do MySQL.

O log binário da instância do gravador mostra que a instância do gravador tentou atualizar um registro com id=1 na tabela test_replication.users:

#251104 21:13:13 server id 680788197  end_log_pos 899 CRC32 0x89b1e255     Update_rows: table id 101 flags: STMT_END_F
### UPDATE `test_replication`.`users`
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='[e-mail]' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='[e-mail]' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
# at 899

Os logs de erros da réplica mostram que a réplica não pôde executar a instrução UPDATE porque o registro de destino não existe:

Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND

Para verificar se a linha está ausente, verifique se a linha específica existe na réplica:

SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)

Essa saída confirma que a operação UPDATE da instância de banco de dados de origem falhou na replicação porque a linha de destino não existe na réplica.

Evitar falhas de replicação

Sugerimos as seguintes práticas recomendadas para evitar inconsistências de replicação:

• Replicação baseada em GTID Para obter mais informações, consulte Usar a replicação baseada em GTID.

• Use binlog_format como ROW na instância primária. Com binlog_format definido como MIXED, existe a possibilidade de a replicação ocultar inconsistências silenciosamente.

• Configure read_only como 1 na instância de réplica para evitar modificações indesejadas na linha.

• Defina innodb_flush_log_at_trx_commit como 1 na instância de réplica.

• Defina sync_binlog como 1 na instância primária.

• Verifique a paridade do esquema da tabela entre a instância primária e de réplica.

• Garanta que as tabelas replicadas tenham chaves primárias.