初识TiDB Data Migration迁移工具及实践

很多数据库为了方便替换国外数据库或开源数据库产品都提供了迁移工具，如TiDB Data Migration、TDSQL DB-Bridge、OB OMS、KingBase KDTS/KFS等。虽然都叫迁移工具，但不同厂商的迁移工具能力则不尽相同，有些只能支持全量数据迁移，有些全量迁移和增量迁移用两个不同的工具，有些只能支持数据迁移不支持表结构迁移……本文主要介绍TiDB的DM工具能力以及基本的使用技巧。

一． DM能力简介

TiDB Data Migration（DM）是一款数据迁移工具，支持从与MySQL协议兼容的数据库到TiDB的全量和增量数据迁移。注意，DM的源头不仅仅是MySQL，是能兼容MySQL协议的相关数据库，包括MySQL、MariaDB、Aurora MySQL等。

DM的主要能力可以归纳为以下几点：

• MySQL兼容。高度兼容MySQL常用功能及语法。

• 支持DDL&DML同步。能解析和同步binlog中的DDL和DML操作。

• 支持合库合表同步。如上游是MySQL分库分表，可合并到一张TiDB表。

• 高可用架构。DM本身可以部署为集群方式，各组件均具有高可用性，且可以任意扩容。

• 内置多种过滤器。支持多种方式对同步过程进行过滤。

二． DM架构介绍

TiDB的DM是一个支持高可用的架构，DM整体架构中包括三个组件：DM-master、DM-worker和dmctl，如下图所示。

• DM-master。负责管理和调度数据迁移任务。包括保存DM集群拓扑信息、监控DM-worker运行状态、监控迁移任务运行状态、提供迁移任务管理统一入口、协调分库分表场景下各实例分表的DDL迁移。

• DM-worker。负责执行具体的数据迁移任务。包括将binlog持久化到本地、保存迁移子任务的配置信息、编排迁移子任务的运行、监控迁移子任务的运行状态。

• dmctl。控制DM集群的命令行工具。通过dmctl可以创建/更新/删除迁移任务、查看迁移任务状态、处理迁移任务错误、校验迁移任务配置正确性。

三．DM高可用实现原理

DM具有高可用能力，具体来说就是DM-worker和DM-master两个核心组件具有高可用性，可以避免单节点故障。

• DM-master高可用

下图是DM master的内部架构，可以看到DM master内部是一个ETCD集群，默认情况下有一个Master Leader和多个Master Follower。每个Master自下而下包括多个组件：gRPC和HTTP接口（供其他组件调用如dmctl和WebUI）、etcd（内嵌etcd集群，也作为配置或状态的存储介质）、Election模块（周期性调用etcd进行选举）、Scheduler模块（注册及监听DM woker状态）、Pessimist和Optimist模块（对DDL进行悲观协调及乐观协调）。如果一个DM master发生故障，Election模块通过etcd选举出新的Leader节点并启动DM master相关组件接续执行，DM master切换恢复的时间主要跟etcd集群的恢复时间有关。

• DM-worker高可用

每个DM-worker会bound一个上游数据源，超出上游数据源的DM worker节点默认处于空间（Free）状态。当某个DM worker节点下线或异常时，DM master会将此DM worker相关的迁移任务调度到空闲的DM worker上继续运行。

四．DM部署及创建同步任务实践

如果您使用过tiup cluster安装部署TiDB集群的话，对安装部署DM集群一定很容易理解。DM集群的部署与TiDB集群的部署可以说是非常的类似。在配置好tiup镜像源之后，我们便可以使用相关的tiup dm命令来部署并监控DM集群了，主要使用到的命令如下：

下图为测试搭建的一个DM集群展示输出，结果显示所搭建的DM集群包括3个dm-master、3个dm-worker，以及altermanager\grafana\promethues监控组件，3000页面可以帮忙查看dm迁移的延迟情况。细心的同学还能看到，下图3个dm-worker中有一个Bound状态两个Free状态，这说明Bound状态的dm-worker已经绑定了一个数据源节点（后面会介绍..）。

部署完DM集群之后，我们就可以配置DM同步任务了。想使用DM来进行数据迁移同步，主要包括2个步骤：配置数据源以及配置迁移任务。

• 配置数据源

配置数据源就是我们需要让DM集群加载并保存一份数据源的连接信息，包括数据源地址、用户名密码、端口号等。我们将这些信息保存到一份配置文件中（如source1.yaml），然后使用dmctl来创建数据源即可。一个比较简单的数据源配置示例如下：

注意：为了安全性，配置中的password建议使用dmctl encrypt加密，参考 管理 TiDB Data Migration 上游数据源 | PingCAP 文档中心

下面使用dmctl工具将数据源配置加载到DM集群中，命令为：

创建完成后，使用operate-source show查看配置生效的数据源。从输出显示，创建的数据源被绑定到了一个worker上面，这就能解释为什么上述display dm集群的时候有一个dm worker为Bound状态了。

• 配置迁移任务
  

迁移任务的配置文件也需要事先编辑好，如名称为task.yaml，之后便可以使用dmctl来创建、查询、删除任务。任务配置中主要包括4部分信息：任务信息配置、目标TiDB配置、数据源配置、过滤配置（包括表路由、操作事件过滤、黑名单过滤等）

一个比较典型的迁移配置如下（完整的任务配置参考 DM 任务完整配置文件介绍 | PingCAP 文档中心 ）

注意，迁移任务的文件配置要求比较严格，用户需要严格按照其格式使用，修改完配置文件后可以通过check-task来检查配置文件的正确性，当输出显示"result": true表示配置文件正常。

上图中有一个warning，提示数据源的版本过高，不过warning并不影响任务的创建。这时我们可以使用start-task来创建任务并使用query-status来查看创建的任务。

上面图1中说明DM当时有一个正在running的task，task的名称为test，引用的数据源为mysql-01。图2是对于test这个任务的详细信息输出，包括子任务的同步状态等，由于当前环境中未有可以迁移的表及数据，所有源库与TiDB目标库为同步状态"synced": true。

五．测试与监控DM同步实践

基于上述创建的同步任务配置，我们做一个测试，来验证TiDB DM的分库分表合并能力，在此之前我们先准备三个MySQL单机库。

测试目的：利用routes配置，将3个MySQL中的3个表合并到一个TiDB表。

关键配置信息：

DM监控界面：

同步后状态检查：

六．补充：任务配置遇到的问题

配置DM的task.yaml文件是比较严格的，用户需要较为仔细，好在check-task的输出也比较明确。作者在测试中模拟出几类问题场景，这里跟大家分享一下：

错误1：提示br-rule-1这个block allow list不存在

分析：发现原因是" bw-rule-1"多了一个空格，修改为"bw-rule-1"即可。

错误2：提示filter-rule-2未使用

分析：此规则确实未被使用，因此需要从配置文件中删除它。

错误3：提示unmarshal errors

分析：根据提示定位到41行，发现是此行缩进不正确导致。说明配置文件对缩进有严格要求。

错误4：提示mysql-02不存在

分析：任务配置中引用的数据源必须已经提前创建好，否则就不要在任务文件中引用。

错误5：分库分表任务提示目标表不存在

分析：分库分表情况下目标表和源表名称和schema不同，需要提前创建目标对象