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.

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 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=<rds-endpoint> \
--port=3306 \
--user=<username> \
--password=<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.

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='[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

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.

• 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.