能实现零停机迁移，但需确保binlog配置正确（log_bin=on、row格式、full行镜像、唯一server_id）、授权完整（reload/lock/replication等）、预处理对象冲突、严格监控延迟与校验、切流前停写并终止dts任务。

能实现，但“零停机”不等于“零影响”，关键在增量同步是否持续、数据一致性校验是否到位、业务切换点是否可控。

确认源库 binlog 配置是否满足 DTS 增量捕获要求

DTS 增量同步依赖源库的 binlog 日志，配置错误会导致任务卡在“增量同步中”或直接失败。不是所有 MySQL 部署默认开启完整 binlog 支持。

• log_bin 必须为 ON（不能只写 log_bin = /path/mysql-bin 但没生效）
• binlog_format 推荐设为 ROW；MIXED 可用但部分语句仍走 STATEMENT 模式，可能漏同步
• binlog_row_image 必须是 FULL（尤其涉及 UPDATE/DELETE 时，否则目标端无法还原完整行）
• server_id 必须 >1，且全链路唯一（多个 DTS 任务连同一源库时不能重复）
• 若源库是主从架构中的 slave，还需确认 log_slave_updates = 1

验证命令：SHOW GLOBAL VARIABLES LIKE 'log_bin';、SHOW MASTER STATUS;。别只看配置文件，要查运行时值。

授权账号权限必须覆盖结构迁移 + 全量 + 增量三阶段

很多迁移失败卡在“权限不足”，不是因为没给 SELECT，而是漏了 DTS 内部机制依赖的隐式权限。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 结构迁移需要 SHOW CREATE TABLE、SHOW CREATE VIEW、SHOW PROCEDURE STATUS 等，对应显式授权是 SHOW VIEW 和 PROCESS
• 全量迁移需 LOCK TABLES（无主键表会加表锁）、RELOAD（用于 FLUSH TABLES WITH READ LOCK 的替代逻辑）
• 增量同步强依赖 REPLICATION CLIENT 和 REPLICATION SLAVE，缺一不可
• 阿里云 RDS 等托管实例可省略 SHOW DATABASES，但自建库或第三方云（如 AWS RDS、华为云 RDS）必须显式授予

典型授权语句：GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, PROCESS ON *.* TO 'dts_user'@'%';

目标库对象冲突与 DEFINER 转换需提前干预

DTS 会自动把源库视图/存储过程/函数的 DEFINER 改成目标库账号，并设 SQL SECURITY INVOKER，但这不解决权限问题，也不处理同名对象冲突。

• 如果目标库已存在同名库/表/视图，DTS 结构迁移会报错中断，必须手动清理或改名
• DEFINER 被替换后，调用这些对象时，实际执行权限取决于调用者（INVOKER），不是定义者 —— 所以你要提前对业务账号授读写权限，否则上线就报 EXECUTE command denied
• DTS 不迁移 mysql.user 表，也不会创建缺失的用户，所有权限都得你手工补
• 函数和存储过程的 routine_body 不会被修改，但如果含不兼容语法（如 Oracle 风格的 NVL()），DTS 会尝试转换，但转换失败不会报错，只留日志 —— 建议迁移前用 mysqldump --no-data 抽出 routine 定义人工过一遍

监控增量延迟与校验结果比看“任务状态”更重要

DTS 控制台显示“迁移中”只是表面，真正风险藏在延迟堆积和校验失败里。

• 重点关注控制台的 延迟时间（秒） 指标，持续 >30 秒说明源库写入压力大、网络抖动或目标库写入慢（如索引过多、磁盘 IO 饱和）
• 全量完成后必须手动触发 数据一致性校验，别等自动校验 —— 默认只做记录数比对，要进高级选项勾选 逐行比对 或 SHA256 校验
• 校验发现差异时，DTS 提供“修复”按钮，但它只重传差异行，不解决根本原因（比如源库有未提交事务、目标库有触发器干扰）
• 切流前最后一步：暂停源库写入（SET GLOBAL read_only = ON），等延迟归零、校验通过，再切 DNS 或连接池配置

最容易被忽略的是：DTS 自动恢复机制。迁移失败的任务默认会重试，如果你已在目标库上线业务，这个重试可能把旧数据覆盖回来 —— 切流前务必手动结束或释放任务。