在数据库分布式架构升级的场景里，把业务数据从 MySQL 迁移到 TiDB 是常见需求。手工导出导入不仅需要长时间的停机窗口，迁移期间的增量数据也无法自动追平。NineData 的「数据复制」能力提供结构复制、全量复制、增量复制一体化链路，可以在不停机的情况下完成 MySQL 到 TiDB 的整体迁移同步。
本文基于一次真实的操作录屏整理，逐步演示从创建任务、选择复制对象、配置映射、预检查到启动与监控的完整过程，每一步都配有高清界面截图，照着做即可复现整条链路。
一、方案能力概览
• 结构复制：自动在目标端 TiDB 建库建表，两端对象名称保持一致。
• 全量复制：把源端存量数据一次性迁移写入 TiDB。
• 增量复制：基于 Binlog 实时同步 DML 与 DDL 变更，演示中复制延迟稳定为 0 秒。
• 预检查：迁移前自动校验两端连通性、账号权限、版本兼容与 Binlog 配置。
• 全程可视化：结构、全量、增量三个阶段均有独立页签，提供进度、操作计数与延迟监控。
二、前置条件
1. 数据源接入
• 源端 MySQL 与目标端 TiDB 均已在 NineData「数据源管理」中接入并测试通过。
• 目标端 TiDB 中不存在与源端同名的库表，避免冲突。
2. 账号权限
• 源端 MySQL：具备 SELECT、REPLICATION SLAVE、REPLICATION CLIENT 等复制权限。
• 目标端 TiDB：具备写入与 DDL 权限（CREATE、INSERT、UPDATE、DELETE、ALTER 等）。
3. 源端 Binlog 配置
• 源端已开启 Binlog，且 binlog_format = ROW。
• 待复制的表包含主键或唯一键（无主键表会在预检查中提示）。
三、创建复制任务：选择数据源与目标
登录 NineData 控制台，进入「数据复制」模块，单击新建复制任务。在第 1 步「数据源与目标」页面完成以下配置：
• 任务名称：填写任务名称，例如 mysql-tidb-dq2。
• 源数据源：选择已接入的 MySQL 实例。
• 目标数据源：选择已接入的 TiDB 数据源。
• 目标对象命名规则：选择「保持与源端一致」，目标端库名表名自动沿用源端命名。
• 复制类型：同时勾选「结构复制、全量复制、增量复制」三种类型。
• 冲突策略：存量数据清空后重新写入，增量变更直接更新目标数据，确认无误后单击「下一步」。
四、选择复制对象
第 2 步支持「全部实例」与「自定义对象」两种方式。本演示选择自定义对象，复制源端业务库中的全部数据表；勾选后目标端对象会自动按同名映射显示在右侧。
需要排除某些库或表时，可以在下方配置黑名单；右上角的「导入配置」还支持批量创建相同复制对象的链路，适合多实例批量上线的场景。确认无误后单击「下一步」。
五、配置映射
第 3 步「配置映射」中，源表与目标表默认一一对应，库名表名与源端保持一致。需要批量调整目标库名或表名时，可以使用「批量配置」功能统一改写；该页面还支持字段级映射与行级数据过滤条件。本演示保持默认映射，确认后单击「保存并预检查」。
六、预检查
预检查会自动校验两端连通性、账号权限、版本兼容性，以及 Binlog 相关配置（是否开启、格式是否为 ROW、row_image 是否为 FULL 等）。
本次检查中「源库无主键表存在性校验」未通过。无主键表会影响全量复制效率与增量变更定位，生产环境建议补齐主键或唯一键后再迁移；本演示为测试库，选择「跳过」继续。
其余检查项全部通过后，单击「立即启动」。
七、启动任务并监控三个阶段
任务启动成功后进入详情页，状态由「启动中」自动变为「运行中」，顶部依次展示结构复制、全量复制、增量复制三个阶段的进度。
1. 结构复制
在「结构复制」页签，可以看到源端业务表已全部完成结构同步，每张表均可单击「查看 DDL」查看在目标端执行的建表语句，两端对象名称保持一致。
2. 全量复制
「全量复制」页签展示存量数据的迁移进度，全部表显示「已完成」即代表存量数据已全部写入 TiDB。
3. 增量复制
「增量复制」页签提供读取延迟、复制延迟曲线以及 INSERT、UPDATE、DELETE、DDL 的操作计数。源端暂无变更时各项计数为 0。
源端产生变更后，操作计数实时���新。演示中依次执行了 INSERT、UPDATE 和一条加列 DDL，页签即时显示 INSERT 1、UPDATE 1、DDL 1，复制延迟保持 0 秒。单击「查看 DDL」可以确认：源端执行的加列语句已在目标端 TiDB 按相同语义完成，两端结构保持一致。
八、结语
至此，MySQL 到 TiDB 的结构、全量、增量同步链路已全部搭建完成并稳定运行。后续源端的任何变更都会持续实时同步到目标端，待增量延迟稳定为 0 秒后，业务即可择机完成流量切换，实现不停机迁移。
关于产品与更多迁移链路（如 MySQL 同步到 PostgreSQL、各云厂商数据库之间互迁等），可访问 NineData 官网 www.ninedata.cloud 了解详情。
常见问题 FAQ
Q1：MySQL 迁移到 TiDB 需要停机吗？
不需要。NineData 采用「全量 + 增量」方式：全量复制迁移存量数据，增量复制通过 Binlog 持续追平变更，当复制延迟稳定为 0 秒后即可择机切换业务流量，实现平滑不停机迁移。
Q2：目标端 TiDB 已有同名库表怎么办？
任务配置中提供「目标库同名对象处理策略」：预检查报错并停止任务、跳过并继续任务、删除对象并重建三种。最稳妥的做法是迁移前清理目标端同名对象，保留默认的「预检查报错并停止任务」。
Q3：源库存在无主键表会有什么影响？
预检查会给出「无主键表存在性」失败项。无主键表在大数据量场景下会拖慢全量复制速度，增量 UPDATE/DELETE 也难以精确定位。建议为业务表补充主键或唯一键；少量测试表可选择跳过后继续。
Q4：源端 MySQL 的 Binlog 有什么要求？
必须开启 Binlog 且 binlog_format 为 ROW，binlog_row_image 建议为 FULL，同时保存时长要足够，避免增量拉取中断。这些配置预检查都会自动校验。
Q5：如何确认迁移完成、可以切换业务？
在任务详情页观察：结构复制与全量复制全部「已完成」；增量复制页签操作计数实时更新且复制延迟稳定为 0 秒。此时源端变更已全部追平，可短暂停写确认后切换流量。
Q6：MySQL 和 TiDB 支持哪些版本？
源端支持 MySQL 5.x、8.x 等主流版本，目标端支持 TiDB 主流版本；具体以 NineData 官方文档的兼容性说明为准，预检查中的「版本检查」项也会自动校验两端兼容性。