AWS DMS从RDS MySQL同步时CDC运行一段时间后失败求助

核心结论 #

是的，你需要从头重启复制任务，但重启前先排查并解决导致binlog截断的根本问题，否则重启后可能再次失败。

错误原因分析 #

你遇到的net_safe_read error 1236错误，本质是DMS的CDC进程尝试读取的RDS binlog文件mysql-bin-changelog.017941已经被截断或清理：

• RDS会自动清理超过保留时长的binlog（你设置的是168小时），如果全量加载完成后，CDC进程未能及时追上binlog进度，旧的binlog文件会被RDS删除。
• 错误日志显示“binlog truncated in the middle of event”，也可能是RDS磁盘空间不足时，binlog被强制截断损坏。

升级复制实例规格和存储无法解决这个问题，因为问题根源是源端RDS的binlog已经丢失，DMS任务的checkpoint指向的位置已经无效，恢复任务时仍会尝试读取不存在的binlog片段。

重启任务的关键注意事项 #

1. 优先排查源端RDS问题 #

• 登录RDS MySQL执行SHOW BINARY LOGS;，确认mysql-bin-changelog.017941是否还存在。如果已不存在，说明binlog被自动清理，必须重启任务。
• 检查RDS磁盘使用率，确保磁盘空间充足，避免binlog被强制截断。
• 临时延长binlog保留时长（比如改为336小时/14天），给CDC进程足够的时间追上进度，避免后续再次出现类似问题。

2. 重启任务的两种选择 #

选项一：从头启动全量+CDC（推荐）

因为你已经完成全量同步到Elasticsearch，但目标是Kinesis数据流，重启全量会再次发送全量数据到Kinesis，需要确保ES端能处理重复数据（比如通过文档ID自动去重）。

• 删除当前失败的任务，创建新任务时：
  • 保持全量加载+持续同步模式。
  • 修改FullLoadSettings里的TargetTablePrepMode为DO_NOTHING（原配置是DROP_AND_CREATE），避免Kinesis重复接收全量数据后，ES端重复创建索引或覆盖数据。

选项二：仅启动CDC（有数据丢失风险）

如果能确认全量结束后到当前时间的变更可以接受丢失，或者能手动补全这部分数据，可以尝试：

• 登录RDS MySQL执行SHOW MASTER STATUS;，获取当前最新的binlog文件名和位置。
• 创建新任务时选择仅持续同步模式，在CDC设置里手动指定上述获取的binlog起始位置。
• 这种方式跳过全量，但如果全量结束后到指定位置之间有业务变更，这部分数据会丢失，仅适合对数据一致性要求不高的场景。

后续预防措施 #

• 根据业务变更量和全量加载时长，调整RDS binlog保留时长，确保DMS CDC进程能在binlog被清理前完成读取。
• 监控DMS任务的CDC Latency指标（CloudWatch），如果延迟持续升高，及时调整复制实例规格或优化任务配置。
• 确保RDS磁盘空间预留足够余量，避免因磁盘满导致binlog截断。

内容的提问来源于stack exchange，提问作者chocho.boss