AWS DMS：MariaDB 10迁移同步至Aurora MySQL 5.7问题咨询

嘿，我来帮你拆解下这些关于MariaDB迁移到Aurora MySQL的问题：

1. 先解决那个无意义的报错 #

你后来更新的解决方案完全正确！这个Last Error Task error notification received from subtask 0, thread 0 [reptask/replicationtask.c:2673] [20014]报错，根源是目标端点的表外键约束导致DMS无法完成删除/截断表操作。只需要在目标端点的配置中添加initstmt=SET FOREIGN_KEY_CHECKS=0，临时关闭外键检查，就能解决这个冲突问题。

2. 迁移完成间隔2天启动同步，能否从迁移结束位置开始？ #

答案是只要源库的二进制日志（binlog）没被清理，就可以：

• DMS在全量迁移结束时，会自动记录源库当时的binlog位置（或GTID，如果你的MariaDB开启了GTID功能）。
• 后续启动增量同步任务时，它会自动从这个记录的位置开始拉取数据变更。
• 但这里有个关键前提：你的MariaDB的expire_logs_days参数设置的binlog保留时间必须超过5天（3天迁移+2天间隔）。如果binlog在这段时间内被自动清理，那间隔的2天里的数据变更就会丢失，无法捕获。

3. 如何确保数据完全同步？ #

如果想要百分百避免数据丢失，推荐这几个稳妥的方法：

• 提前调整源库binlog保留策略：把MariaDB的expire_logs_days参数设置为至少7天（大于你的迁移+间隔总时长），确保关键binlog不会被自动删除。
• 使用全量+增量一体化任务：不要分开执行全量迁移和增量同步，直接创建一个“全量迁移+持续增量同步”的DMS任务。这样任务会在全量完成后自动无缝切换到增量同步，中间没有间隔，完全不用担心数据遗漏。
• 完成同步后做数据校验：用DMS自带的数据校验功能，或者自行编写脚本对比源库和目标库的表行数、关键数据哈希值；也可以用CHECKSUM TABLE命令对核心业务表做一致性校验，确保两边数据完全匹配。

4. 关于DMS底层流程的参考资料 #

AWS官方文档里有详细的DMS工作流说明，重点看这几块：

• 全量迁移与增量CDC（变更数据捕获）的工作原理章节，里面会讲解全量迁移如何记录结束点、增量同步如何基于该点拉取变更的细节。
• MySQL类目标端点的配置说明，里面会深入解释外键检查、初始化语句这类配置项的作用，帮你理解为什么initstmt能解决之前的报错。

内容的提问来源于stack exchange，提问作者hpaknia