新旧系统均有活跃用户时，DynamoDB迁移至PostgreSQL的方案咨询

你已经完成离线全量迁移，接下来在线迁移的核心是同步增量数据+低风险业务割接，以下是主流可行方案：

方案1：Glue + DynamoDB Streams 增量同步 #

• 操作流程：
  1. 开启目标DynamoDB表的Streams，选择NEW_AND_OLD_IMAGES视图类型，确保捕获所有增删改操作。
  2. 创建Glue流式作业，消费DynamoDB Streams数据，转换为PostgreSQL兼容格式（处理嵌套结构、数据类型映射等）。
  3. 加入幂等逻辑：用Stream记录的recordID作为唯一标识，PostgreSQL侧通过ON CONFLICT (record_id) DO UPDATE避免重复写入。
  4. 定期运行Glue批处理作业，对比两边表的记录数、关键字段哈希值，确保数据一致。
  5. 割接阶段：当增量同步延迟降到可接受范围（如<5秒），暂停业务写入DynamoDB，同步最后一批增量，验证一致性后切换业务到PostgreSQL。
• 适用场景：已基于AWS Glue构建离线迁移流程，业务写量中等，能接受分钟级业务暂停，有开发资源自定义同步逻辑。

方案2：AWS DMS 托管式迁移 #

• 操作流程：
  1. 配置DMS迁移任务：源选DynamoDB（需提前开启Streams），目标选PostgreSQL。
  2. 先执行全量迁移（可复用之前Glue的全量结果，减少重复劳动），完成后自动开启CDC模式实时同步增量。
  3. 监控CDC滞后时间，当滞后接近0时，停止业务写入DynamoDB，等待最后一批变更同步完成，用DMS自带校验工具验证一致性，切换业务流量。
• 适用场景：希望减少自定义代码，依赖托管服务降低运维成本，业务写量较高，对数据一致性要求严格，能接受分钟级切换窗口。

方案3：双写+渐进式流量切换 #

• 操作流程：
  1. 修改业务代码，实现同时向DynamoDB和PostgreSQL写入（通过事务或异步校验保证双写正确性）。
  2. 逐步将读流量从DynamoDB迁移到PostgreSQL：先切10%流量，观察稳定性和一致性，没问题后逐步提升比例至100%。
  3. 停止DynamoDB写入，下线旧存储。
• 适用场景：业务代码可修改，要求零停机切换，核心交易类业务，愿意投入开发成本改造业务逻辑。

关键注意事项 #

• 数据一致性：定期校验两边数据，避免丢失或不一致。
• 幂等处理：增量同步必须处理重复操作，防止PostgreSQL出现脏数据。
• 演练：在测试环境完整模拟迁移和割接流程，验证稳定性。
• 回滚：提前准备回滚方案，若切换出问题可快速切回DynamoDB。

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