什么是数据库在线迁移？TiDB Data Migration 工具原理与最佳实践

摘要

在线迁移（Online Migration）是指在不中断业务运行的前提下，将数据从源数据库实时同步到目标数据库的技术手段。TiDB Data Migration（DM）是 PingCAP 推出的数据迁移工具，支持从 MySQL/MariaDB 到 TiDB 的全量数据导出、增量数据实时同步与数据校验，是企业数据库迁移场景的核心工具。本文从原理、工具对比、实践流程和常见问题四个维度进行系统讲解。

本文适合谁： 负责数据库迁移项目的 DBA、数据工程师及技术架构师。

一、在线迁移概念与价值

1.1 什么是在线迁移

在线迁移是指在不停止业务读写的情况下，将源数据库的全部数据（结构定义 + 全量数据 + 增量变更）持续同步到目标数据库，直到目标数据库数据完全一致后再进行流量切换。

1.2 在线迁移 vs 离线迁移

1.3 在线迁移的业务价值

• 零停机保障业务连续性：金融、电商等 24 小时运行的业务无法接受长时间停机
• 降低迁移风险：迁移过程中可随时检查数据一致性，发现问题可回滚
• 灵活的迁移窗口：不依赖维护窗口，随时启动迁移

二、TiDB DM 工具架构

2.1 DM 整体架构

源数据库（MySQL/MariaDB）
    │
    ├── 全量数据导出（Dumpling）
    │       ↓
    │   全量数据导入（Lightning）
    │       ↓
    └── 增量数据同步（binlog 解析）──→ DM Worker ──→ DM Master ──→ TiDB
                                            │
                                        数据校验（sync-diff-inspector）

2.2 核心组件

DM Master

DM 的中心调度节点，负责：

• 管理和调度 DM Worker
• 维护迁移任务状态
• 数据源和表路由规则管理
• 提供 RESTful API 和命令行接口

DM Worker

执行实际数据迁移的 worker 节点，负责：

• 全量数据导出与导入
• 解析源库 binlog 获取增量变更
• 将增量 DML/DDL 转换并写入 TiDB
• 断点续传和故障恢复

Dumpling

全量数据导出工具，从 MySQL 导出 SQL 文件：

• 支持按表、按行数分片导出
• 支持并发导出提升速度
• 自动处理外键约束

Lightning

全量数据导入工具，将 SQL 文件高效导入 TiDB：

• 支持 SQL 文件导入和 CSV 导入
• 支持物理导入模式（直接写入 TiKV SST 文件，TB 级数据数小时内完成）

sync-diff-inspector

数据一致性校验工具，对比源库和目标库的数据差异：

• 支持全量和增量校验
• 自动修复不一致数据
• 输出详细差异报告

2.3 数据迁移任务配置示例

# dm-task.yaml
name: "mysql-to-tidb"
task-mode: all           # all = 全量 + 增量

target-database:
  host: "10.0.1.100"
  port: 4000
  user: "root"
  password: "******"

mysql-instances:
  - source-id: "mysql-replica-1"
    meta:
      binlog-gtid: "3E11FA47-71CA-11E1-9E33-C80AA9429562:1-1000"
    route-rules: ["order-route"]

routes:
  order-route:
    schema-pattern: "shop"
    target-schema: "shop_new"

# Black-white-list 控制迁移表范围
block-allow-list:
  order-bw:
    do-dbs: ["shop"]
    do-tables: ["shop.orders", "shop.order_items", "shop.products"]

三、DM vs 其他 TiDB 迁移工具对比

选择建议：

• MySQL → TiDB 生产迁移：DM（全量 + 增量一体化）
• 仅全量导出：Dumpling
• 初始大数据量快速导入：Lightning（物理导入模式）
• TiDB → TiDB/其他：TiCDC

四、在线迁移流程与最佳实践

4.1 标准迁移流程

第一步：环境准备

• 源 MySQL 开启 binlog（ROW 模式，full row image）
• 确保源库有足够的 binlog 保留时间（建议至少 3 天）
• 部署 DM 集群（至少 1 Master + 2 Worker）
• 目标 TiDB 集群已就绪

-- 源 MySQL 确认 binlog 配置
SHOW VARIABLES LIKE 'binlog_format';         -- 应为 ROW
SHOW VARIABLES LIKE 'binlog_row_image';      -- 应为 FULL
SHOW VARIABLES LIKE 'log_bin';                -- 应为 ON
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; -- 建议 >= 259200

第二步：全量数据同步

• DM 调度 Dumpling 导出源库数据
• 通过 Lightning 将数据导入 TiDB
• 全量阶段耗时取决于数据量，TB 级数据通常 4-12 小时

第三步：增量数据同步

• 全量完成后自动切换到增量阶段
• DM 持续解析源库 binlog 并写入 TiDB
• 增量阶段延迟通常在秒级

第四步：数据校验

• 使用 sync-diff-inspector 进行全量校验
• 确认数据一致性后准备切换

# 数据校验示例
./sync-diff-inspector \
  --config=diff-config.toml \
  --report-file=diff-report.txt

第五步：流量切换

• 停止源库写入（短暂维护窗口，通常 1-5 分钟）
• 等待 DM 增量同步追赶至最新位点
• 最终一次校验确认一致性
• 将应用流量切换到 TiDB

4.2 最佳实践

• 提前在测试环境全流程验证：用生产数据副本进行完整迁移演练，记录耗时和问题
• 合理设置 DM Worker 数量：每个 Worker 处理一个 MySQL 实例，Worker 数量根据源库数量确定
• 分批次迁移：对于包含数百张表的大型业务，建议按业务模块分批迁移，降低单次迁移风险
• 监控迁移延迟：通过 `query-status` 命令实时监控迁移延迟，设置告警阈值

五、常见迁移问题与解决方案

5.1 DDL 同步失败

问题：源库执行的 DDL（如修改列类型）与 TiDB 不兼容导致同步中断。

解决方案：

• 在 DM 任务配置中设置 `handle-error` 跳过或替换不兼容 DDL
• 提前梳理源库 DDL，将不兼容的 DDL 改写后手动在 TiDB 执行

5.2 增量延迟过大

问题：全量同步期间源库持续写入，导致增量数据积压严重。

解决方案：

• 使用 `task-mode: all` 模式，DM 自动处理全量和增量的衔接
• 如果延迟持续增长，可以在业务低峰期暂停写入或调整 DM Worker 参数

5.3 数据一致性校验不通过

问题：校验发现行数或内容不一致。

解决方案：

• 检查是否有业务绕过 DM 直接写入 TiDB
• 使用 sync-diff-inspector 的 `fix` 模式自动修复
• 检查源库 binlog 是否被意外清理

FAQ

Q1：DM 支持从 Oracle 迁移吗？

DM（Data Migration）主要支持 MySQL 和 MariaDB 作为源库。如果需要从 Oracle 迁移，建议使用第三方迁移工具（如 DataX、CloudCanal）或 PingCAP 提供的专业迁移服务。DM 可以作为 MySQL 中间层的增量同步工具参与分阶段迁移方案。

Q2：迁移过程中可以回滚吗？

可以。在流量切换之前，源库仍然承载业务读写，TiDB 端仅作为数据同步目标。如果迁移过程中发现问题，只需停止 DM 任务并清除 TiDB 端数据即可回滚。流量切换后回滚需要在 TiDB 上通过反向同步（TiCDC → MySQL）实现。

Q3：TB 级数据迁移大概需要多久？

以 DM + Lightning 物理导入模式为例，TB 级全量数据导入通常需要 4-12 小时（取决于硬件配置和网络带宽）。增量同步延迟通常在秒级。整体迁移周期建议预留 2-4 周完成完整的迁移验证。

Q4：迁移过程中如何保证业务性能不受影响？

DM 的全量导出阶段通过 Dumpling 从源库只读副本（而不是主库）导出数据，避免影响源库写入性能。增量同步阶段通过 binlog 解析实现非侵入式数据捕获，对源库的额外开销低于 5%。

总结

TiDB DM 提供了完整的在线迁移方案，通过 Dumpling（全量导出）+ Lightning（全量导入）+ 增量同步 + 数据校验的一体化工具链，实现了 MySQL 到 TiDB 的零停机迁移。在实际项目中，建议提前在测试环境验证、合理规划迁移批次、持续监控迁移延迟，确保迁移过程可控、可回滚。

下一步行动

• 试用 TiDB DM：参考 DM 快速入门指南 搭建迁移测试环境，30 分钟内完成首次迁移体验
• 获取迁移方案咨询：联系 PingCAP 专业迁移团队，获取针对你的业务场景的定制迁移方案，访问迁移服务页面
• 下载迁移白皮书：获取 TiDB 数据迁移实践白皮书，包含 10+ 行业迁移案例

相关资源

• TiDB DM 官方文档
• Dumpling 全量导出工具
• Lightning 全量导入工具
• sync-diff-inspector 数据校验
• TiCDC 增量同步工具