TiDB 数据库里的数据同步利器:DM
在数字化转型浪潮下,如何把原有 MySQL 分库分表的数据平滑迁移到 TiDB,成为很多企业上云和数据库升级的必答题。
今天我们分享一次真实的迁移方案:
使用 TiDB DM(Data Migration)工具,将多实例/多分表 MySQL 数据合并迁移到TiDB 5.1 集群。
为什么选择 TiDB + DM?
传统 MySQL 架构的痛点
- 分库分表后,业务查询复杂度高
- 扩展性不足,数据量再大就得重新拆分
- 跨库事务难,维护成本居高不下
TiDB 的优势
- 水平扩展,存储 & 计算无限扩展
- 兼容 MySQL 协议,业务改造成本低
- 强一致性分布式事务,天然支持大数据量 OLTP + OLAP 混合场景
DM 的角色
DM 是 TiDB 官方的数据迁移工具,支持:
全量迁移(Dump → Load)
增量同步(Binlog → TiDB)
分库分表合并
换句话说,DM 就是MySQL → TiDB 的最优迁移通道。
架构设计
迁移整体架构如下:
说明:
- DM Master:负责任务调度与管理
- DM Worker:连接 MySQL,负责抽取 binlog & 数据迁移
- TiDB Cluster:目标库,承接合并后的业务数据
分表合并策略
假设场景:
- 源端:MySQL 有8 个分表(order_0 ~ order_7),分别位于不同实例
- 目标端:TiDB 需要将其合并为一张表 order
DM 配置示例
name: "order-merge-task"
task-mode: all # 支持全量+增量
target-database:
host: "tidb.example.com"
port: 4000
user: "dm_user"
password: "******"
mysql-instances:
- source-id: "mysql-01"
route-rules: ["order-route-rule"]
block-allow-list: "order-allow"
mydumper-thread: 4
loader-thread: 8
syncer-thread: 16
routes:
order-route-rule:
schema-pattern: "db_order"
table-pattern: "order_*"
target-schema: "tidb_order"
target-table: "order"
block-allow-list:
order-allow:
do-dbs: ["db_order"]
核心点:route-rules 实现分表到单表的合并映射。
迁移步骤
1 部署 DM 集群
- 通过 Ansible/tiup 部署 DM Master、DM Worker
#scale-dm-out
---
global:
user: "tidb"
ssh_port: 22
deploy_dir: "/usr/local/tidb-deploy"
data_dir: "/data1/dm/data"
# arch: "amd64"
master_servers:
- host: 10.10.3.1
worker_servers:
- host: 10.10.3.1
- 执行扩容所容节点命令
# 列出所有 dm 集群
tiup dm list
# 显示集群详细信息
tiup dm display dm-prod
# 扩容(示例)
tiup dm scale-out dm-prod scale-dm-out.yaml
# 带 native ssh
tiup dm scale-out dm-prod scale-dm-out.yaml --native-ssh
# 缩容(示例)
tiup dm scale-in dm-prod -N 10.10.3.6:8262
# 若节点不可 SSH 可用 --force
tiup dm scale-in dm-prod -N 10.10.3.6:8262 --force
# 使用 dmctl 操作数据源 / 任务
tiup dmctl --master-addr=10.10.3.1:8261 operate-source show
tiup dmctl --master-addr=10.10.3.1:8261 query-status
tiup dmctl --master-addr=10.10.3.1:8261 stop-task mytask
2 配置数据源
tiup dmctl --master-addr=master1:8261 operate-source create mysql-source.yaml
3 启动迁移任务
tiup dmctl --master-addr=master1:8261 start-task order-merge-task.yaml
4 监控迁移进度
tiup dmctl --master-addr=master1:8261 query-status order-merge-task
常见问题 & 最佳实践
Q1:分表主键冲突怎么办?
建议在迁移前统一主键生成策略,比如雪花算法 / TiDB 自增 ID。
Q2:增量迁移时延迟大?
调优 syncer-thread 并合理分配 Worker 资源。
Q3:大表迁移很慢?
可先分批迁移历史数据,再进行增量同步切换。
效果与收益
迁移完成后:
- 所有分表合并到一张 TiDB 表,查询逻辑更简洁
- 扩展性大幅提升,支持亿级订单表
- 与下游数仓、报表系统无缝对接
一句话总结:
TiDB + DM = MySQL 分库分表的终极解法!
总结
- MySQL 分库分表复杂度大 → 迁移到 TiDB
- DM 工具 → 支持全量 + 增量 + 分表合并
- 生产落地关键点 → 架构设计 + 主键策略 + 性能调优
未来,TiDB 不仅是数据库,更是企业数字化的核心底座。
如果你也在经历 MySQL 扩展瓶颈,不妨考虑TiDB + DM 的组合拳。