AWS同构MySQL RDS间数据镜像同步方案选型咨询

别被官方文档里「同构迁移优先选原生工具」的说法带偏，这个推荐的适用场景是搭建1:1完全同步的灾备、只读副本，你本身就需要做带过滤、带转换的非对称同步，DMS的适配度反而比原生复制高得多，完全覆盖你提的4个核心要求，运维成本远低于自研Kinesis链路。

DMS对应需求的配置方式 #

• 首次全量同步：新建DMS迁移任务时，先选择「全量加载」模式，提前在表映射规则里排除性能环境专属的独立表/独立Schema，避免全量加载覆盖你保留的性能环境专属配置、测试数据，首次全量跑完不需要重置性能库数据。
• 周度增量同步：全量任务跑完后，记录当前生产库的binlog位点，后续每周启动DMS CDC任务时，直接指定从上次记录的binlog位点开始消费，任务跑完自动停止即可，不需要持续运行任务节省成本；CDC模式默认只捕获位点之后的新增、变更数据，不会重复同步历史存量。
• 不覆盖存量数据规则：在DMS任务的写入策略里，直接配置冲突处理规则为主键冲突时跳过写入，对应到DMS的参数就是把TargetTablePrepMode设为DO_NOTHING，异常处理策略里把插入冲突的动作设为IGNORE，全程只会执行插入操作，完全不会更新、删除性能库已有的任何数据，包括你后续补录的性能环境专属数据。
• 数据加工转换：DMS原生支持表级、列级的转换规则，不需要额外开发消费程序，比如邮箱脱敏直接在列转换规则里配置哈希、字符串掩码规则即可，复杂转换逻辑也可以通过DMS内置的表达式函数实现，同步过程中自动完成加工再写入目标库。

为什么不推荐Kinesis自研链路 #

这个方案的投入产出比极低：

• 你需要自行维护binlog抓取组件（比如Debezium、Canal），自行处理binlog位点续传、重复消费、异常重试、表结构变更兼容等一堆边缘问题，还要单独写消费逻辑实现幂等判断、数据脱敏、写入重试，整套链路的开发、后续运维工作量至少是DMS方案的5倍以上，后续每次生产库表结构调整、MySQL版本升级都要适配自研代码，长期维护成本很高。
• 你提到的Lambda消费Kinesis写入RDS的模式，还要单独处理Lambda并发、RDS连接数打满、大批次写入超时等问题，稳定性远不如DMS原生的写入链路。

轻量替代方案（适合数据量中等的场景） #

如果你的单周新增数据量在百万级以内，完全可以用更简单的脚本方案，不需要额外引入云服务：

• 首次全量同步直接用生产RDS快照恢复到性能RDS，恢复后关闭性能库的只读属性，补录性能环境专属数据，记录当前同步时间点。
• 后续每周定时跑一个简单的脚本，用mysqldump指定--insert-ignore --no-create-info --single-transaction参数，加上时间条件只导出上次同步时间点之后新增的数据，导出过程中直接通过流处理完成邮箱等字段的脱敏，再导入性能RDS即可，--insert-ignore参数会自动跳过主键冲突的已有数据，全程不会覆盖存量，整套脚本只有几十行，跑在低配置EC2或者Lambda上就够，成本几乎可以忽略。

注意：不要用RDS原生只读副本做这个场景，原生复制会全量同步生产库的所有更新、删除操作，会直接冲掉你性能库的专属数据，也无法支持字段脱敏、增量跳过冲突的需求。

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