Por que minha tarefa de CDC do AWS DMS falhou com o erro "Error 1236" quando usei o MySQL como a origem?

Breve descrição

Com o AWS DMS, é possível realizar migrações únicas e replicar alterações em curso para manter as origens e os destinos sincronizados. Para ler as alterações em curso do banco de dados de origem, o AWS DMS usa ações de API específicas do mecanismo para ler os logs de transação do mecanismo de origem. Quando você usa o MySQL como a origem, o AWS DMS lê as alterações dos logs binários (binlogs) baseados em linha. Em seguida, o AWS DMS migra essas alterações para o destino.

Se houver problemas com os logs binários, você receberá a mensagem de erro "Error 1236". Certifique-se de configurar corretamente todos os parâmetros de registro em log binário para oferecer suporte à CDC do AWS DMS ao usar um banco de dados compatível com MySQL autogerenciado ou gerenciado pela AWS.

Resolução

Para solucionar o erro "Error 1236", realize as seguintes ações com base na mensagem de erro recebida.

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

Exemplo de erro dos logs de tarefa:

[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

O erro anterior ocorre quando o banco de dados do MySQL de origem removeu o log binário que o AWS DMS usa para replicar alterações de dados no destino. O MySQL pode remover o log binário pelos seguintes motivos:

• O período de retenção do log binário é muito baixo.
• A tarefa do AWS DMS está travada ou interrompida devido a um problema.

Para confirmar se o log binário está disponível, execute o seguinte comando para listar todos os arquivos de log binário:

mysql> SHOW BINARY LOGS;

Em seguida, execute o seguinte comando para listar o arquivo de log binário atual e a posição:

mysql> SHOW MASTER STATUS;

Para obter mais informações sobre os comandos anteriores, consulte SHOW BINARY LOGS statement (Declaração SHOW BINARY LOGS) e a SHOW MASTER STATUS statement (Declaração SHOW MASTER STATUS) no site do MySQL.

Para resolver o erro, verifique o período de retenção do log binário no banco de dados do MySQL de origem. Se necessário, aumente o período de retenção. Reinicie a tarefa do AWS DMS para executar a fase de carga total novamente.

Realize as seguintes ações com base no seu tipo de banco de dados.

Bancos de dados autogerenciados do MySQL

Para descobrir o período de retenção de logs binários on-premises ou no Amazon Elastic Compute Cloud (Amazon EC2), verifique o valor de expire_logs_days. Para obter mais informações, consulte expire logs days (dias de expiração dos logs) no site do MySQL.

Observação: é uma prática recomendada definir o parâmetro global da variável SET como 1 ou maior. Para obter mais informações, consulte SET syntax for variable assignment (Sintaxe SET para atribuição de variáveis) no site do MySQL.

Bancos de dados do MySQL gerenciados pela AWS

Verifique as horas de retenção de log binário definidas em um banco de dados do Amazon Relational Database Service (Amazon RDS) para MySQL ou da edição compatível com MySQL do Amazon Aurora. Execute o seguinte comando:

mysql> call mysql.rds_show_configuration;

Para aumentar a retenção de logs para 24 horas, execute o seguinte comando:

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

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

Exemplo de erro dos logs de tarefa:

[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)

O erro anterior pode ocorrer pelos seguintes motivos:

• Uma linha tem mais dados do que o valor max_allowed_packet na origem. Para obter mais informações, consulte max allowed packet (pacote máximo permitido) no site do MySQL.
• Uma única transação contém grandes quantidades de dados ou há várias atualizações de linha em uma única transação.
• Há corrupção do log binário no banco de dados de origem.

Se você usar colunas de objeto grande binário (binary large object, BLOB) ou strings longas, defina o valor de max_allowed_packet como o maior BLOB usado. Esse parâmetro pode ter um valor de até 1 GB. Para obter mais informações, consulte The BLOB and TEXT types (Tipos BLOB e TEXT) no site do MySQL.

Para verificar o tamanho da sua maior transação, analise seus logs binários. Certifique-se de que o tamanho da transação não exceda o tamanho de max_allowed_packet. Para obter mais informações sobre como dividir uma transação grande, consulte Packet too large (Pacote muito grande) no site do MySQL.

Se o erro persistir, pode haver corrupção nos logs binários de origem.

Para verificar se há problemas nos logs binários, conclua as seguintes etapas:

1. Execute o comando a seguir para verificar se o log binário existe:

   mysql> SHOW BINARY LOGS;

2. Para visualizar os eventos no log binário, execute o seguinte comando:

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

   Observação: substitua binlog file pelo nome do log binário e position pela posição em que o evento ocorre.

3. Para baixar os logs binários, execute o seguinte 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. Verifique se o log binário mencionado na mensagem de erro está corrompido.

5. Se o log binário estiver corrompido, crie um caso no AWS Support.

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

Exemplo de erro dos logs de tarefa:

[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)

O erro anterior pode ocorrer pelos seguintes motivos:

• Há um sync_binlog != 1 no servidor primário. Isso significa que os eventos de log binário podem não ser sincronizados no disco. Para obter mais informações, consulte sync binlog (sincronizar binlog) no site do MySQL.
• Há corrupção do log binário no banco de dados de origem.

Para resolver esse erro, verifique se o valor do parâmetro sync_binlog na origem está definido como 1. Em seguida, reinicie a tarefa.

Se o parâmetro sync_binlog já estiver definido como 1, verifique se o log binário está corrompido. Para obter instruções, consulte a seção anterior "Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master...".

"Client requested master to start replication from impossible position"

Exemplo de erro dos logs de tarefa:

[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)

Esse erro ocorre quando o servidor de banco de dados do MySQL de origem é interrompido inesperadamente. Uma interrupção inesperada pode ocorrer devido a uma falha de hardware, como um erro de disco ou uma perda de energia.

Para resolver esse erro, realize uma das seguintes ações com base no seu tipo de tarefa do AWS DMS:

• Em tarefas de carga total e CDC, reinicie a tarefa do AWS DMS.
• Em tarefas somente CDC, inicie a tarefa do AWS DMS a partir da próxima posição do log binário.

"Client requested master to start replication from position > file size"

Exemplo de erro dos logs de tarefa:

[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

Esse erro pode ocorrer por cause de logs binários criptografados. Se seu banco de dados do MySQL de origem executar o MySQL versão 8.0 e você criptografar os logs binários, o AWS DMS não poderá ler os logs na inicialização da tarefa. Como resultado, o AWS DMS registra esse erro. Ao ativar a criptografia de log binário, não é possível usar a replicação CDC que usa o MySQL 8.0 como origem. Para obter mais informações, consulte Encrypting binary log files and relay log files (Criptografar arquivos de log binário e arquivos de log de retransmissão) no site do MySQL.

Para solucionar esse problema, realize as etapas a seguir:

1. Execute o comando a seguir para verificar sua versão do MySQL:

   mysql> SELECT VERSION();

2. Execute o comando a seguir para verificar se binlog_encryption está ATIVO:

   mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'binlog_encryption';

3. Para desativar binlog_encryption, execute o seguinte comando:

   mysql> SET GLOBAL binlog_encryption = OFF;

   -ou-
   Inicie a tarefa do AWS DMS com binlog_encryption desativado e, em seguida, execute o seguinte comando para ativar binlog_encryption:

   mysql> SET GLOBAL binlog_encryption = ON;

Informações relacionadas

Como soluciono erros de registro em log binário que recebo quando uso o AWS DMS com o Aurora compatível com MySQL como origem?