专栏 - 初识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两个核心组件具有高可用性，可以避免单节点故障。

l 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集群的恢复时间有关。

l 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集群的模板文件，修改模板文件中具体的节点地址及端口信息
tiup dm template > dm.yaml

//部署DM集群，集群名称为dm-test，版本为v7.5.0
tiup dm deploy dm-test v7.5.0 dm.yaml

//启动DM集群tiup dm start dm-test

//查看DM集群的组件及状态tiup dm display dm-test

下图为测试搭建的一个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个步骤：配置数据源以及配置迁移任务。

l 配置数据源

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

source-id: "mysql-01"    # 数据源 ID，在数据迁移任务配置和 dmctl 命令行中引用该 source-id 可以关联到对应的数据源 

from:  
  host: "172.20.xx.xx"  
  port: 3306  
  user: "root"  
  password: "" # 推荐使用 dmctl 对上游数据源的用户密码加密之后的密码

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

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

tiup dmctl --master-addr 172.20.xx.xx:8261 operate-source create ./source1.yaml

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

tiup dmctl --master-addr 172.20.xx.xx:8261 operate-source show

l 配置迁移任务

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

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

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

tiup dmctl --master-addr 172.20.xx.xx:8261 check-task task01.yaml

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

tiup dmctl --master-addr 172.20.xx.xx:8261 start-task task.yaml

tiup dmctl --master-addr 172.20.12.52:8261 query-status

tiup dmctl --master-addr 172.20.12.52:8261 query-status test

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

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

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

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

关键配置信息：

routes:  
  sharding-route-rules-table:  #规则名称    
    schema-pattern: "test_*"  # 匹配数据源的库名，支持通配符 "*" 和 "?"    
    table-pattern: "t*"  # 匹配数据源的表名，支持通配符 "*" 和 "?"    
    target-schema: "db_target"  # 目标 TiDB 库名    
    target-table: "t_target"  # 目标 TiDB 表名  
  sharding-route-rules-schema:    
    schema-pattern: "test_*"    
    target-schema: "db_target"

DM监控界面：