北屋教程网

专注编程知识分享,从入门到精通的编程学习平台

从 MySQL 到 TiDB5.1:一次优雅的分表合并迁移实践

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 的组合拳




控制面板
您好,欢迎到访网站!
  查看权限
网站分类
最新留言