跳至内容
使用AWS re:Post即您表示您同意 AWS re:Post 使用条款
AWS re:Postre:Post
关于 re:Post

当我使用 MySQL 作为源时，为什么我的 AWS DMS CDC 任务失败并显示 "Error 1236"？

5 分钟阅读
0

我使用 AWS Database Migration Service (AWS DMS) 将数据从源 MySQL 数据库引擎迁移到目标引擎。然而，更改数据捕获 (CDC) 任务失败，出现 "Error 1236"。

简短描述

借助 AWS DMS，您可以执行一次性迁移，也可以复制正在进行的更改以保持源数据库和目标数据库同步。为了读取源数据库中正在进行的更改，AWS DMS 会使用特定于引擎的 API 操作来读取源引擎的事务日志。当使用 MySQL 作为源数据库时，AWS DMS 会从基于行的二进制日志中读取更改。然后，AWS DMS 将这些更改迁移到目标数据库。

如果二进制日志存在问题，您会收到 "Error 1236" 消息。当您使用自主管理型或 AWS 托管式 MySQL 兼容版数据库时，请确保正确配置所有二进制日志记录参数以支持 AWS DMS CDC。

解决方法

要对 "Error 1236" 进行故障排除，请根据您收到的错误消息执行以下操作。

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

任务日志中的错误示例：

[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

当源 MySQL 数据库移除了 AWS DMS 用于将数据更改复制到目标数据库的二进制日志时，就会发生上述错误。MySQL 可能会由于以下原因移除二进制日志：

  • 二进制日志保留期过短。
  • AWS DMS 任务因出现问题而卡滞或停止。

要确认二进制日志是否可用，请运行以下命令列出所有二进制日志文件：

mysql> SHOW BINARY LOGS;

然后，运行以下命令列出当前的二进制日志文件和位置：

mysql> SHOW MASTER STATUS;

有关上述命令的更多信息，请参阅 MySQL 网站上的 SHOW BINARY LOGS statement（SHOW BINARY LOGS 语句）和 SHOW MASTER STATUS statement（SHOW MASTER STATUS 语句）。

要解决此错误，请检查源 MySQL 数据库上的二进制日志保留期。如有需要，可以延长保留期。重新启动 AWS DMS 任务以再次运行全量加载阶段。

根据您的数据库类型执行以下操作。

自主管理型 MySQL 数据库

要检查本地或 Amazon Elastic Compute Cloud (Amazon EC2) 的二进制日志保留期，请查看 expire_logs_days 的值。有关更多信息，请参阅 MySQL 网站上的 expire logs days。

**注意：**最佳做法是将 SET 变量的全局参数设置为 1 或以上。有关更多信息，请参阅 MySQL 网站上的 SET syntax for variable assignment（变量赋值的 SET 语法）。

AWS 托管式 MySQL 数据库

检查在 Amazon Relational Database Service (Amazon RDS) for MySQL 或 Amazon Aurora MySQL 兼容版数据库上设置的二进制日志保留小时数。运行以下命令：

mysql> call mysql.rds_show_configuration;

要将日志保留时间增加到 24 小时，请运行以下命令：

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

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

任务日志中的错误示例：

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

出现上述错误的原因可能如下：

  • 源数据库上某行的数据多于 max_allowed_packet 的值。有关详细信息，请参阅 MySQL 网站上的 max allowed packet。
  • 单个事务包含大量数据，或单个事务中有多个行更新。
  • 源数据库上的二进制日志发生损坏。

如果您使用二进制大对象 (BLOB) 列或长字符串，请将 max_allowed_packet 的值设置为您使用的最大 BLOB 的大小。此参数的值最高可达 1GB。有关详细信息，请参阅 MySQL 网站上的 The BLOB and TEXT types（BLOB 和 TEXT 类型）。

要查看最大事务的大小，请查看您的二进制日志。确保事务大小不超过 max_allowed_packet 的大小。有关如何拆分大型事务的信息，请参阅 MySQL 网站上的 Packet too large（数据包过大）。

如果您仍然遇到错误，则源二进制日志可能已损坏。

要检查二进制日志是否存在问题，请完成以下步骤：

  1. 运行以下命令检查二进制日志是否存在：

    mysql> SHOW BINARY LOGS;

  2. 要查看二进制日志中的事件，请运行以下命令：

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

    **注意：**请将 binlog file 替换为二进制日志名称，并将 position 替换为事件发生的位置。

  3. 要下载二进制日志，请运行以下命令：

    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. 检查错误消息中提到的二进制日志是否存在损坏。

  5. 如果二进制日志已损坏，则创建 AWS Support 案例。

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

任务日志中的错误示例：

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

出现上述错误的原因可能如下：

  • 主服务器上设置了 sync_binlog != 1。这意味着二进制日志事件可能无法在磁盘上同步。有关详细信息，请参阅 MySQL 网站上的 sync binlog。
  • 源数据库上的二进制日志发生损坏。

要解决此错误，请确保将源数据库上的 sync_binlog 参数值设置为 1。然后，重新启动任务。

如果 sync_binlog 参数已设置为 1，则检查二进制日志是否损坏。有关说明，请参阅上述 "Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master..." 部分。

"Client requested master to start replication from impossible position"

任务日志中的错误示例：

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

当源 MySQL 数据库服务器意外停止时，就会发生此错误。意外停止可能是由于磁盘错误或断电等硬件故障而导致的。

要解决此错误，请根据您的 AWS DMS 任务类型执行以下操作之一：

  • 对于全量加载和 CDC 任务，请重新启动 AWS DMS 任务。
  • 对于仅限 CDC 的任务，请从下一个二进制日志位置启动 AWS DMS 任务。

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

任务日志中的错误示例：

[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

此错误可能是由于二进制日志已加密导致的。如果您的源 MySQL 数据库运行的是 MySQL 8.0 版本，且已为二进制日志加密，则 AWS DMS 无法在任务初始化时读取日志。因此，AWS DMS 会记录此错误。当您启用二进制日志加密时，不能使用以 MySQL 8.0 作为源的 CDC 复制。有关更多信息，请参阅 MySQL 网站上的 Encrypting binary log files and relay log files（加密二进制日志文件和中继日志文件）。

要解决此问题，请完成以下步骤：

  1. 运行以下命令检查您的 MySQL 版本：

    mysql> SELECT VERSION();

  2. 运行以下命令检查 binlog_encryption 是否已开启：

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

  3. 要关闭 binlog_encryption，请运行以下命令：

    mysql> SET GLOBAL binlog_encryption = OFF;

    -or-
    在关闭 binlog_encryption 的情况下启动 AWS DMS 任务，然后运行以下命令开启 binlog_encryption：

    mysql> SET GLOBAL binlog_encryption = ON;

相关信息

如何排查使用 AWS DMS 时将 Aurora MySQL 兼容版用作源时收到的二进制日志记录错误？

没有评论

相关内容