初识 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 集群展示输出，结果显示所搭建的 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 来创建数据源即可。一个比较简单的数据源配置示例如下：
注意：为了安全性，配置中的 password 建议使用 dmctl encrypt 加密，参考 管理 TiDB Data Migration 上游数据源 | PingCAP 文档中心
下面使用 dmctl 工具将数据源配置加载到 DM 集群中，命令为：
创建完成后，使用 operate-source show 查看配置生效的数据源。从输出显示，创建的数据源被绑定到了一个 worker 上面，这就能解释为什么上述 display dm 集群的时候有一个 dm worker 为 Bound 状态了。
l 配置迁移任务
迁移任务的配置文件也需要事先编辑好，如名称为 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 不同，需要提前创建目标对象。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/8aa4dde4fbee12d2f2c4d78f4】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论