# 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](USER_LogAccess.Procedural.Viewing.md).
## 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`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html) 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= \
--port=3306 \
--user= \
--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](USER_LogAccess.MySQL.Binarylog.md).
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='updated4@example.com' /* 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='updated5@example.com' /* 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](mysql-replication-gtid.md).
+ 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.