DM 多库合并至 TiDB

作者： gloria_cy 原文来源：https://tidb.net/blog/d2d1eec6

1、前言

一天开发突然找我，有没有办法可以同时查询 4 个库数据，业务提了需求需要一周上线，我们业务驱动型公司业务提的需要想办法满足。跟开发细聊得知多个场景需要同时查询 4 个 MySQL 库数据，该需求并要一周后上线使用。我们开始探讨找可行的方案。

2、方案选型：

业务有跨库的表关联需求，若完全靠代码实现，开发的代码量较大，开发评估不了周期和可靠性，首先考虑使用 cdc 架构把数据合并到同一个库，给开发介绍了如下三个工具：

a.Databus

b.Debezium

c.Canal

2.1、开发评估后说短期内他们无法实现可靠稳定的架构，主要无法保证数据的完整性。

2.2、线上都使用的阿里 RDS MySQL 也放弃了 MySQL 并行复制。

2.3、一直知道 pingcap 官方推出了 TiDB Data Migration (DM) 套件，之前也使用过 DM 工具。线上 MySQL 是 5.7 版本，TiDB 兼容 MySQL5.7 协议，给开发介绍这个方案后他们只想用这个方案了（开发能少些很多代码）。

3、环境检查：

3.1、检查源端 MySQL 库是否有无主键表。

3.2、检查源端 MySQL 库是否有重名表。

3.3、检查源端 MySQL 库表设计是否有 TiDB 不支持条件。

经检查发现只有表名重复现象，重名的只需要同步其中一个表到 TiDB，环境满足需求。

4、环境部署

TiDB 集群版本：4.0.14

DM 版本：2.0.6

Tikv server：500g SSD 磁盘，16c32g，三台 ecs

Tidb server：200g SSD 磁盘，8c32g，三台 ecs

Pd server：与 tidb 节点共用

DM 集群：500g SSD 磁盘，4c8g，四台 ecs

官方建议每个节点抽出单独的机器来部署，考虑到成本 pd 节点跟 tidb 节点先混用，因为有四个源需要四个 dm-work，DM 集群使用四台机器，dm-work 与 dm-master 部署于相同的四台机器。需要注意 dm-work 主机的磁盘大小，空间大小需要满足一次源库的全量备份。

5、整体集群架构

整体架构如上图所示，主要包括 TiDB 集群组件和 DM 集群组件：

TiDB 集群主要包括三个组件：

Tikv server：负责存储数据。

Tidb server：负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。

PD server： TiDB 集群的元信息管理模块。

DM 集群主要包括三个组件：

DM-master：负责管理和调度数据迁移任务的各项操作

DM-worker：负责执行具体的数据迁移任务

dmctl：是用来控制 DM 集群的命令行工具

* 具体的功能可参考官方文档了解每个模块的详细功能

DM 特性:

Table routing 合并迁移

Block & allow table lists 白名单

Binlog event filter binlog 级别过滤

Shard support 合库合表

我这主要用到是合并迁移和过滤，把多个 MySQL 实例表同步到一个 TiDB 集群中。

6、环境配置

6.1、TiDB 集群安装：使用 tiup 安装 TiDB 集群，参照官方配置进行安装不做详细介绍。

6.2、DM 集群安装：

a. dm 使用比较新的版本，工具类的软件新版本应该更加稳定。

b. 四个源配置在一个 task.yaml 使用 tiup 进行安装。

注意：因多库合并需确保重名表只同步一个，后面新建表需要同步到 tidb，配置文件配置黑名单 block-allow-list: 过滤不同步的表。

c. 停止

7、遇到的问题：

7.1、因多库合并使用的黑名单方式，上游新建表需注意不能重名，不然数据同步会停止。

7.2、4.x 版本的 TiDB 不支持表类型变更，上游不能有类型变化的修改。这点很重要，一旦上游修改了数据类型，dm 会发生中断，同步任务只能重做，重做过程 tidb 数据无法使用，这将耗时又误事的操作，切记对开发人员宣贯这个特性，让他们在设计时避开这个问题。

教训

1. 宣贯开发人员对 tidb 的使用规范，（从 tidb 官网找 MySQL 不兼容的统计出来）

8、总结和感慨

公司内已去年开始使用 tidb，对与周边产品一直都有了解，DM 还是头次使用。开始也担心出问题如何解决，但一直感受到了 TiDB 产品本身，以及 TiDB 社区在不断的做大，做强，才决定使用 dm 做同步。从接到需求和最终上线不到一周时间，这么完善的工具，让我们这个项目中起到事半功倍的效果。开发不在考虑数据同步功能，确保功能及时上线。每个产品没有 100% 的完美，有场景正好适合且能让工作变得更加简单，这就是好的产品。