如何摆脱对AWS DMS任务重启/重建的依赖？

一、减少DMS故障后的重建/重启需求 #

• 开启DMS自动恢复机制：在任务配置里打开「自动重启任务」，设置合适的重试间隔和次数，临时故障（RI中断、网络波动）会自动重试，无需手动干预。
• MySQL大版本升级前做预检查：用DMS的任务评估工具提前扫描源端兼容性，修复不兼容的语法和数据类型。升级前暂停CDC任务，升级完成后先做增量校验再恢复，避免直接全量重建。
• DMS复制实例采用多AZ部署：多AZ模式下单个AZ故障会自动切换到备用节点，降低任务中断概率。
• 延长MySQL binlog保留时长：确保binlog保留时间覆盖可能的故障窗口，重启任务时能从断点续传，无需全量加载。同时开启DMS任务日志，方便快速定位故障点。

二、解决高频表长SELECT死锁（无需克隆表） #

• DMS源端启用快照隔离：在Aurora MySQL源端点配置里开启快照隔离，让DMS的查询使用快照级别，避免锁表引发死锁，完全不影响业务正常更新。
• 拆分长查询为分批小查询：把全表查询按主键分块执行，比如按ID范围每次查询1万条数据，缩短锁持有时间，降低死锁风险。
• 调整事务隔离级别：业务允许的情况下，将高频更新表的事务隔离级别改为READ COMMITTED，锁粒度更细，死锁概率更低，先做业务测试再正式上线。
• 用Aurora只读副本做初始加载：DMS初始加载指向Aurora只读副本，CDC仍连接主实例，查询操作都在副本上执行，完全不干扰主库业务，从根源杜绝死锁。

三、简化同步状态校验，无需脚本等待 #

• CloudWatch监控DMS状态：监控TaskStatus、CDCApplyLatency等核心指标，设置告警规则，任务异常时直接触发通知（邮件/短信），无需脚本轮询检查。
• 使用DMS内置数据校验：开启DMS的数据校验功能，任务恢复后自动对比源端和目标端数据一致性，结果可在控制台或CloudWatch查看，脚本只需监听校验完成信号即可。
• 目标端增量时间校验：在Redshift中查询高频表的max(updated_at)，和源端的对应值对比，差值在合理范围内即可判定同步完成，无需全量数据比对。

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