# Solución de problemas de replicación debido a la falta de registros
Al utilizar Amazon RDS para MySQL o MariaDB con replicación de registros binarios, es posible que se produzcan errores de replicación en los que el proceso se detenga debido a la falta de registros en las réplicas de lectura. En esta sección se explica cómo diagnosticar y resuelve estos problemas.
## Causas habituales
Una falta de coherencia en los datos entre el origen y la réplica podría deberse a uno de los siguientes escenarios:
+ Modificación manual de los datos en la réplica
+ Transacciones omitidas al usar `sql_replica_skip_counter` (`sql_slave_skip_counter` antes de MySQL 8.0.26)
+ Faltan filas en la réplica durante la sincronización inicial de datos mediante las herramientas de migración
## Identificación del problema
Un indicador común de este problema es `Error 1032` con el mensaje `Can't find record`. El siguiente mensaje de error aparece en el registro de errores de la 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**
El formato del registro de errores varía entre los motores de MySQL y MariaDB. Para obtener más información sobre cómo recuperar los registros, consulte [Visualización y descripción de archivos de registro de base de datos](USER_LogAccess.Procedural.Viewing.md).
## Diagnóstico del problema
Para diagnosticar el error de replicación:
+ Revise los registros de errores de la réplica para identificar dónde se ha detenido la replicación. Puede utilizar `MY-010584` como palabra clave de búsqueda.
+ Ejecute `SHOW REPLICA STATUS\G` (`SHOW SLAVE STATUS\G` antes de MySQL 8.0.22) en la réplica y revise la columna `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.
```
+ Compruebe el nombre del archivo de registro binario y la posición en la que se ha detenido el proceso de replicación en la instancia de réplica. Puede encontrar esta información en el registro de errores de la instancia de replicación.
## Análisis de registros binarios
Para investigar un error de replicación en una determinada transacción, puede utilizar la utilidad [`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html) para examinar el archivo de registro binario. Por ejemplo, si se ha producido un error en la replicación en `end_log_pos` en la posición `899` del archivo de registro binario `mysql-bin-changelog.031523`, puede analizar esta ubicación específica para identificar la causa del error.
**nota**
El valor `end_log_pos` indica la posición final del evento erróneo. En el resultado del registro binario decodificado, busque el evento en el que `end_log_pos` coincida con este valor.
Utilice la utilidad `mysqlbinlog` para descargar y examinar el registro binario correspondiente. Utilice el punto de conexión de la instancia principal.
```
$ mysqlbinlog --read-from-remote-server \
--host= \
--port=3306 \
--user= \
--password= \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name
```
**nota**
La utilidad `mysqlbinlog` es una herramienta nativa de MySQL que le ayuda a leer e interpretar el contenido de los registros binarios. Para obtener más información sobre el acceso de los registros binarios en Amazon RDS, consulte [Acceso a los registros binarios de MySQL](USER_LogAccess.MySQL.Binarylog.md).
El registro binario de la instancia de escritura muestra que la instancia de escritura ha intentando actualizar un registro con `id=1` en la tabla `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
```
Los registros de errores de la réplica muestran que la réplica no ha podido ejecutar la instrucción de `UPDATE`, ya que el registro de destino no existe:
```
Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND
```
Para verificar si falta la fila, compruebe si la fila específica existe en la réplica:
```
SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)
```
Este resultado confirma que la operación `UPDATE` de la instancia de base de datos de origen no se ha podido replicar, ya que la fila de destino no existe en la réplica.
## Cómo evitar errores en la replicación
Recomendamos las siguientes prácticas recomendadas para ayudarlo a evitar incoherencias en la replicación:
+ Utilice la replicación basada en GTID. Para obtener más información, consulte [Uso de la replicación basada en GTID](mysql-replication-gtid.md).
+ Utilice `binlog_format` como `ROW` en la instancia principal. Con `binlog_format` como `MIXED`, existe la posibilidad de que la replicación oculte las incoherencias de forma discreta.
+ Establezca `read_only` en `1` en la instancia de réplica para evitar modificaciones involuntarias en las filas.
+ Establezca `innodb_flush_log_at_trx_commit` en `1` en la instancia de réplica.
+ Establezca `sync_binlog` en `1` en la instancia principal.
+ Compruebe la paridad del esquema de la tabla entre la instancia principal y de réplica.
+ Asegúrese de que las tablas replicadas tengan claves principales.