为Aurora MySQL构建跨区域双向复制灾备方案是否可行？

你的需求完全可行，核心是单活+双向同步+DNS快速切换的模式，刚好能避开Aurora Global Database需要提升备库的步骤，满足低成本、易维护（CDK全管控）和短停机的要求。

可行的同步方案 #

1. AWS DMS双向持续同步（匹配你提出的潜在方案） #

• 用CDK分别部署两个独立的可读写Aurora MySQL集群：primary-us-east-1和backup-us-east-2
• 部署两组DMS复制任务：
  • 主集群到备集群的全量初始化+增量实时同步任务（平时保持运行）
  • 备集群到主集群的反向同步任务（平时暂停，仅故障恢复时启用）
• 故障触发流程：通过Lambda做健康检查（比如定期探测主集群端点、监控CloudWatch区域状态告警），一旦检测到us-east-1故障，自动执行：
  1. 暂停主到备的同步任务
  2. 启动备到主的反向同步任务（为后续主区域恢复做准备）
  3. 更新Route 53 DNS记录，把业务流量切到backup-us-east-2的集群端点
• 恢复流程：主区域恢复正常后，先通过反向同步任务把备集群的增量数据同步回主集群，确认数据一致后切换DNS回主集群，最后恢复主到备的同步链路

2. 原生MySQL双向复制（低成本备选） #

• 利用Aurora MySQL兼容MySQL原生复制的特性，配置两个集群的双向主从复制
• 关键配置要点：
  • 给两个集群设置不同的server-id
  • 开启二进制日志（binlog），指定binlog_format=ROW
  • 平时把备集群设为只读（read_only=1），只有主集群可写，彻底避免数据冲突
  • 故障时，把备集群改为可读写（read_only=0），直接切换DNS即可
• 优势：不用额外依赖DMS，成本更低；劣势：复制链路的监控和维护需要自己做，CDK配置相对繁琐，跨区域网络延迟可能影响复制稳定性

CDK维护关键点 #

• 所有资源（Aurora集群、DMS任务、Lambda、Route 53）都能通过CDK定义，全部纳入基础设施即代码管理，完美解决Aurora Global Database后续资源无法用CDK维护的问题
• 可以用CDK的跨区域部署能力，在同一个栈或者跨栈部署两个区域的Aurora集群
• 把Lambda的故障检测和DNS切换逻辑封装成CDK构造，方便后续复用和修改

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