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%的完美，有场景正好适合且能让工作变得更加简单，这就是好的产品。