AWS DMS全量负载迁移对源MySQL Aurora数据库性能有何影响？

全量迁移阶段对源端的默认性能影响 #

• 读资源占用：DMS全量阶段会扫描所有待迁移表的全量数据生成一致性快照，基于Aurora的共享存储架构，该操作不会触发表锁，但会消耗源实例的CPU、内存和IO吞吐量，若待迁移数据量较大且未做限流，业务侧普通查询可能出现延迟升高的情况。
• Binlog读取开销：为保证后续增量同步可以无缝衔接，DMS任务从启动开始就会持续拉取源端的二进制日志，该操作会产生稳定的小流量网络开销和极低的CPU占用，仅在源端本身binlog写入吞吐量极高的场景下，会额外增加少量存储读取压力。
• 元数据查询负载：任务启动初期会批量拉取源库的表结构、索引、约束等元数据，当库内表数量超过1000张时，会短时间拉高information_schema的查询负载，可能导致业务侧依赖元数据的操作出现短暂变慢。

生产零 downtime、无异常性能下降的优化方案 #

只要做好以下配置，完全可以把迁移对生产的性能影响控制在5%以内，不会触发业务故障：

• 源端指向只读副本：不要直接连接生产主实例执行迁移任务，先为生产Aurora集群临时创建1台同规格只读副本，将DMS源端配置指向该副本，全量阶段所有读请求完全不占用主实例资源，待全量迁移完成、增量同步延迟低于100ms后再做业务切换，迁移完成后可直接删除临时副本无残留影响。
• 配置DMS限流参数：
  • 调低Maximum number of tables to load in parallel（并行加载表数），4C8G以下小规格实例建议设置为2-4，16C以上大规格实例不超过8
  • 开启大字段分片读取，设置合理的LOB chunk size，避免大字段批量读取打爆源端IO
  • 业务高峰时段可手动暂停全量迁移任务，低谷时段再恢复，Aurora的MVCC机制支持任务断点续传，不会出现数据不一致问题
• 避免锁表风险：DMS默认使用READ COMMITTED隔离级别做一致性快照读取，不会给业务表加排他锁，只要迁移过程中不对待迁移表执行DDL操作，完全不会出现业务卡顿或 downtime。

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