Saltar al contenido

¿Por qué mi tarea de AWS DMS CDC devolvió el error «Error 1236» cuando usé MySQL como origen?

9 minutos de lectura
0

He utilizado AWS Database Migration Service (AWS DMS) para migrar mis datos de un motor de base de datos MySQL de origen a un motor de destino. Sin embargo, la tarea de captura de datos de cambios (CDC) devolvió el error «Error 1236».

Descripción corta

Con AWS DMS, puedes realizar migraciones únicas y replicar los cambios en curso para mantener sincronizados los orígenes y los destinos. Para leer los cambios en curso de la base de datos de origen, AWS DMS utiliza acciones de API específicas del motor para leer los registros de transacciones del motor de origen. Cuando utilizas MySQL como origen, AWS DMS lee los cambios de los registros binarios basados en filas (binlogs). A continuación, AWS DMS migra esos cambios al destino.

Si hay problemas con los registros binarios, verás el mensaje «Error 1236». Asegúrate de configurar correctamente todos los parámetros de registro binario para que sean compatibles con AWS DMS CDC cuando utilices una base de datos compatible con MySQL autoadministrada o administrada por AWS.

Resolución

Para solucionar el «Error 1236», realiza las siguientes acciones en función del mensaje de error que recibas.

«Could not find first log file name in binary log index file reading binlog»

Ejemplo de error de los registros de tareas:

[SOURCE_CAPTURE  ]I: Setting position in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:886)
[SOURCE_CAPTURE  ]I: Position was set in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]E: Error 1236 (Could not find first log file name in binary log index file) reading binlog [1020493]
[TASK_MANAGER    ]I: Task - ABCDXXXXXXXXXXXXXX is in ERROR state, updating starting status to AR_NOT_APPLICABLE

El error anterior se produce cuando la base de datos MySQL de origen elimina el registro binario que AWS DMS utiliza para replicar los cambios de datos en el destino. MySQL puede eliminar el registro binario por los siguientes motivos:

  • El periodo de retención del registro binario es demasiado bajo.
  • La tarea de AWS DMS está bloqueada o detenida debido a un problema.

Para confirmar si el registro binario está disponible, ejecuta el siguiente comando para enumerar todos los archivos de registro binarios:

mysql> SHOW BINARY LOGS;

A continuación, ejecuta el siguiente comando para mostrar la posición y el archivo de registro binario actual:

mysql> SHOW MASTER STATUS;

Para obtener más información sobre los comandos anteriores, consulta las instrucciones SHOW BINARY LOGS y SHOW MASTER STATUS en el sitio web de MySQL.

Para resolver el error, comprueba el periodo de retención del registro binario en la base de datos MySQL de origen. Si es necesario, aumenta el periodo de retención. Reinicia la tarea de AWS DMS para volver a ejecutar la fase de carga completa.

Realiza las siguientes acciones en función del tipo de base de datos.

Bases de datos MySQL autoadministradas

Para comprobar el periodo de retención de los registros binarios locales o de Amazon Elastic Compute Cloud (Amazon EC2), revisa el valor de expire_logs_days. Para obtener más información, consulta las fechas de vencimiento de los registros en el sitio web de MySQL.

Nota: Se recomienda establecer el parámetro global de la variable SET en 1 o superior. Para obtener más información, consulta SET syntax for variable assignment (Sintaxis SET para la asignación de variables) en el sitio web de MySQL.

Bases de datos MySQL administradas por AWS

Comprueba las horas de retención de registros binarios que están configuradas en una base de datos de Amazon Relational Database Service (Amazon RDS) para MySQL o de la edición de Amazon Aurora compatible con MySQL. Ejecuta el siguiente comando:

mysql> call mysql.rds_show_configuration;

Para aumentar la retención de registros a 24 horas, ejecuta el siguiente comando:

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

"Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master..."

Ejemplo de error de los registros de tareas:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin.056367' at 787323674  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]D:  net_safe_read error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.)  (mysql_endpoint_capture.c:1119)
[SOURCE_CAPTURE  ]I:  Error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.) reading binlog. Try reconnect  (mysql_endpoint_capture.c:1123)

El error anterior se puede producir por los siguientes motivos:

  • Una fila contiene más datos que el valor del max_allowed_packet en el origen. Para obtener más información, consulta max allowed packet en el sitio web de MySQL.
  • Una sola transacción contiene grandes cantidades de datos o hay actualizaciones de varias filas en una sola transacción.
  • Hay daños en el registro binario en la base de datos de origen.

Si utilizas columnas de objetos grandes binarios (BLOB) o cadenas largas, define el valor de max_allowed_packet en el BLOB más grande que utilices. Este parámetro puede tener un valor de hasta 1 GB. Para obtener más información, consulta The BLOB and TEXT types (Tipos BLOB y TEXT) en el sitio web de MySQL.

Para comprobar el tamaño de la transacción más grande, revisa tus registros binarios. Asegúrate de que el tamaño de la transacción no supere el tamaño del max_allowed_packet. Para obtener información sobre cómo dividir una transacción grande, consulta Packet too large (Paquete demasiado grande) en el sitio web de MySQL.

Si el error persiste, es posible que los registros binarios de origen estén dañados.

Para comprobar si hay problemas en los registros binarios, sigue estos pasos:

  1. Ejecuta el siguiente comando para comprobar si existe el registro binario:

    mysql> SHOW BINARY LOGS;
  2. Para ver los eventos del registro binario, ejecuta el siguiente comando:

    mysql> SHOW BINLOG EVENTS IN 'binlog file' FROM position;

    Nota: Sustituye binlog file por el nombre del registro binario y position por la posición en la que se produce el evento.

  3. Para descargar los registros binarios, ejecuta el siguiente comando:

    shell> mysqlbinlog \
        --read-from-remote-server \
        --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
        --port=3306  \
        --user ReplUser \
        --password \
        --raw \
        --verbose \
        --result-file=/tmp/ \
        binlog.00098
  4. Comprueba si está dañado el registro binario que menciona el mensaje de error.

  5. Si el registro binario está dañado, crea un caso de AWS Support.

«Binlog truncated in the middle of event; consider out of disk space on master...»

Ejemplo de error de los registros de tareas:

[SOURCE_CAPTURE ]I: Read next binary log event failed; net_safe_read error 1236 (binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin-changelog.017672' at 486, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 125, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 4756.) (mysql_endpoint_capture.c:1069)
[SORTER ]I: Transaction consistency reached (sorter_transaction.c:347)
[TASK_MANAGER ]I: Starting replication now (replicationtask.c:2774)
[TASK_MANAGER ]I: Task - MGLVRIRUJH6FE2GP6F7SW46BPBW6YKF2JUJPSVY is in RUNNING state, updating starting status to AR_RUNNING (repository.c:5110)

El error anterior se puede producir por los siguientes motivos:

  • Hay sync_binlog != 1 en el servidor principal. Esto significa que es posible que los eventos de registro binario no se sincronicen en el disco. Para obtener más información, consulta sync binlog (Sincronización de los registros binarios) en el sitio web de MySQL.
  • Hay daños en el registro binario en la base de datos de origen.

Para resolver este error, asegúrate de que el valor del parámetro sync_binlog en el origen esté establecido en 1. A continuación, reinicia la tarea.

Si el parámetro sync_binlog ya está establecido en 1, revisa el registro binario para ver si está dañado. Para obtener instrucciones, consulta la sección anterior "Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master...".

«Client requested master to start replication from impossible position»

Ejemplo de error de los registros de tareas:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin-changelog.007989' at 1631  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.)  (mysql_endpoint_capture.c:1053)
[SOURCE_CAPTURE  ]D:  Error reading binary log. [1020493]  (mysql_endpoint_capture.c:3995)
[SOURCE_CAPTURE  ]E:  Error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.) reading binlog events [1020493]  (mysql_endpoint_capture.c:1074)

Este error se produce cuando el servidor de base de datos MySQL de origen se detiene inesperadamente. Es posible que se produzca una parada inesperada debido a un fallo de hardware, como un error de disco o un corte de energía.

Para resolver este error, realiza una de las siguientes acciones en función del tipo de tarea de AWS DMS:

  • Para tareas de carga completa y de CDC, reinicia la tarea de AWS DMS.
  • Para las tareas exclusivas de los CDC, inicie la tarea de AWS DMS desde la siguiente posición del registro binario.

«Client requested master to start replication from position > file size»

Ejemplo de error de los registros de tareas:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'binlog.000012' at 2179  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from position > file size)  (mysql_endpoint_capture.c:1052

Este error puede producirse debido a registros binarios cifrados. Si la base de datos MySQL de origen ejecuta la versión 8.0 de MySQL y cifra los registros binarios, AWS DMS no podrá leer los registros al inicializar la tarea. Como resultado, AWS DMS registra este error. Al activar el cifrado de registros binarios, no puedes usar la replicación de los CDC que usa MySQL 8.0 como origen. Para obtener más información, consulta Encrypting binary log files and relay log files (Cifrado de archivos de registro binarios y archivos de registro de retransmisión) en el sitio web de MySQL.

Para resolver este problema, sigue estos pasos:

  1. Ejecuta el siguiente comando para comprobar tu versión de MySQL:

    mysql> SELECT VERSION();
  2. Ejecuta el siguiente comando para comprobar si binlog_encryption está ACTIVADO:

    mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'binlog_encryption';
  3. Para desactivar binlog_encryption, ejecuta el siguiente comando:

    mysql> SET GLOBAL binlog_encryption = OFF;

    Alternativa:
    Inicia la tarea de AWS DMS con binlog_encryption desactivado y, a continuación, ejecuta el siguiente comando para activar binlog_encryption:

    mysql> SET GLOBAL binlog_encryption = ON;

Información relacionada

¿Cómo soluciono los errores de registro binario que se muestran cuando uso AWS DMS con Aurora compatible con MySQL como origen?