dts是唯一能兼顾结构、全量、增量三阶段且支持不停服迁移的方案；因其通过解析binlog实现全量与增量无缝衔接，避免手动方案易导致的数据丢失、主键冲突及同步断点问题。
DTS 是唯一能兼顾结构、全量、增量三阶段且支持不停服迁移的方案。其他方式（如 mysqldump + binlog 手动回放）在业务写入持续的情况下极易丢数据或主键冲突，不推荐用于生产环境。
为什么必须用 DTS 而不是直接 mysqldump？
自建 MySQL 到 RDS MySQL 的迁移不是“导出再导入”这么简单。关键难点在于：如何保证全量导出期间新产生的数据不丢失？如何避免主从延迟导致的 binlog 断点跳过？DTS 内部通过解析源库 binlog 实现无缝衔接——全量同步启动时会记录当前 binlog position，全量结束后立即从该位置开始拉取增量日志，中间无间隙。
手动用 mysqldump --single-transaction 做全量，再靠 mysqlbinlog 抓增量，容易踩以下坑：
- 源库未开启
binlog_format=ROW或binlog_row_image=FULL，DTS 预检查直接失败 - dump 过程中发生 DDL（如加索引），会阻塞
mysqldump获取一致位点，导致后续增量起点错乱 - 未设置
log_slave_updates=ON（双主场景下），DTS 无法捕获所有变更 - 备份文件里含
CREATE DATABASE语句，而 RDS 不允许用户执行该命令，恢复时报错
前置检查必须做的 4 件事
这些检查项一旦漏掉，任务会在预检查阶段卡住或运行中失败：
- 确认源库
binlog已开启：SHOW VARIABLES LIKE 'log_bin';返回ON - 确认
binlog_format为ROW，且binlog_row_image为FULL（RDS MySQL 默认满足，但自建库需手动设） - 确保待迁移表都有主键或唯一索引——无主键表在增量阶段会出现重复写入，目标库报
Duplicate entry - 源库账号需有
REPLICATION SLAVE和REPLICATION CLIENT权限，以及对迁移库的SELECT权限
增量同步期间最常被忽略的兼容性问题
即使结构和数据都同步成功，业务切流后仍可能出问题，根源常在隐式类型转换或函数行为差异：
-
TIMESTAMP字段在自建 MySQL 5.7 和 RDS MySQL 8.0+ 中默认时区处理不同，建议显式指定TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 自建库若用
utf8字符集（实际是utf8mb3），而 RDS 默认utf8mb4，建表时若没声明CHARACTER SET utf8mb4，会导致 emoji 插入失败 -
ENUM或SET类型字段值包含空格或特殊字符时，DTS 解析可能截断，建议提前用SHOW CREATE TABLE核对定义是否一致 - RDS MySQL 对
sql_mode限制更严格（如默认含STRICT_TRANS_TABLES），源库若长期运行在宽松模式下，迁移后 INSERT 会因隐式转换报错
切流前必须验证的两个动作
别只盯着数据行数是否一致。真正决定能否切流的是「变更实时性」和「约束完整性」：
- 在 DTS 控制台查看「延迟时间」指标，确保稳定在
1s以内（非瞬时值），且连续 5 分钟无抖动 - 手动在源库执行一条带主键更新的 SQL，立刻查目标库对应行，确认值已同步；再执行一次
DELETE，确认目标库行消失——这比 COUNT(*) 更能暴露同步链路断裂点
最后注意：DTS 任务不能直接停用，必须先在控制台点击「结束任务」，否则后台可能自动恢复，继续向目标库写入旧数据，引发双写冲突。
