AWS DMS全量+增量同步是目前最可靠、停机时间最短的方案，通常几分钟内完成切换；mysqldump因锁表、无法捕获增量、导入慢且不支持binlog重放，不适合大库或低停机场景。
用 AWS DMS 做全量 + 增量同步，是目前最可靠、停机时间最短的方案，通常能压到几分钟内完成切换。
为什么 mysqldump 不适合大库或低停机要求场景
mysqldump 是离线导出，整个过程源库需锁表（或至少禁止写入），否则 dump 出来数据不一致。即使加 --single-transaction，也只对 InnoDB 有效，且无法捕获 dump 过程中产生的新变更。
- 导出 100 GB 数据在千兆网络下可能耗时 20–40 分钟，期间业务必须停写
- 导入 RDS 时受 IOPS 限制（尤其通用型存储），常比导出还慢；
max_allowed_packet、wait_timeout等参数不匹配还会中途失败 - RDS 不支持
LOAD DATA FROM MASTER或直接复制 binlog 文件，无法靠“冷备份+重放”补增量
AWS DMS 同步的关键配置点
DMS 本身不保证一致性起点，必须配合源库 binlog 设置和任务启动时机手动对齐。
- 源 MySQL 必须开启
binlog_format = ROW，且server_id非零；RDS 源库需调用mysql.rds_set_configuration('binlog retention hours', N)确保 DMS 增量拉取时不丢日志 - 全量任务启动前，记下源库当前
SHOW MASTER STATUS的File和Position；DMS 任务里要填进 “Start replication from specific binary log file and position” 选项，否则增量会漏掉全量期间的变更 - 目标 RDS 若启用了
auto_increment_increment（常见于多可用区集群），需提前在 DMS 表映射中禁用Enable homogeneous change data capture，否则 INSERT 可能因自增冲突失败
跨账号或跨 Region 迁移时容易被忽略的坑
权限和网络连通性问题往往卡在最后一步，而不是数据同步本身。
- 源库若在私有子网，DMS 复制实例必须部署在同一 VPC 或通过 VPC Peering / Transit Gateway 连通；安全组要放行源库的 3306 端口，且源库
bind_address不能为127.0.0.1 - 跨账号时，DMS 任务使用的 IAM 角色必须有
sts:AssumeRole权限，并在目标账号显式授权信任策略；RDS 目标实例的 DB 参数组里，require_secure_transport若设为ON，DMS 会连不上——得临时关掉或配 SSL 证书 - 当源库版本为 MySQL 8.0.28+，默认启用
caching_sha2_password认证插件，而旧版 DMS 不兼容；要么降级认证方式，要么升级 DMS 引擎版本至 3.4.7+
真正决定停机窗口的，从来不是数据量大小，而是你能否在切流前确认 DMS 延迟已趋近于 0（Replication lag 指标稳定在 1–2 秒内），以及应用层是否做好了连接串切换、DNS TTL 降级、事务幂等这些配套动作。
