前段时间，看到了一篇关于数据库选型的文章（MongoDB/TiDB/CockroachDB），忍不住感慨了一句，TiDB 一看就是大户人家，什么工具都可以有，什么工具都迭代得特别快，没有钱没有人，难以想像如何才能驱动得了。TiDB/TiKV/PD/Mydumper/Loader/Syncer/Data Migration/TiDB Lighting/Pump/Drainer ... 光是弄清楚这些组件是用来做什么的，感觉都可以评个高工了 :-)
随着 DM 1.0 GA 的 release，我们也开始考虑将 syncer 迁移至 DM。主要原因还是 syncer 已经太久没有更新了，否则 syncer 这种简易几乎无须部署的工具还是比较对我个人的胃口的，官方很喜欢把工具集群化（可能听起来厉害一点），DM 也是，那就按着最小目标（syncer）折腾一下吧。
DM 的架构文档可以参考官方，整个集群有三个角色 dmctl/dm-master/dm-worker。
- DM-master 负责管理和调度数据同步任务的各项操作。
- DM-worker 负责执行具体的数据同步任务。
- dmctl 是用来控制 DM 集群的命令行工具。
Data Migration architecture
官方也提供了基于 Ansible 的部署工具，如果你不是特别需要了解实际的部署过程，或者你的环境对 ansible 的亲和度比较好的话，可以参考使用 DM-Ansible 部署 DM 集群。在这篇文章里，我们还是希望对于 DM 的部署有一定的了解，另外我们的小目标是实现类似 syncer 功能，因此，让我们 step by step 人肉部署吧。（好吧，吐槽一下，其实本人是很反感什么都要 ansible 再包一层的，无法直接通过文档了解工作方式，还非得去读 ansible 的相关部署文件）。
准备工作
-
确认工作目录，假定这里为
/home/dm，并确保相关目录已经建立且具备读写权限：mkdir -p /home/dm/log； -
确保机器上已经具备相应的命令行工具，如：tar、wget、rsync 或 cp 等；
-
下载 DM 二进制文件：
wget http://download.pingcap.org/dm-latest-linux-amd64.tar.gz tar -zxvf dm-latest-linux-amd64.tar.gz rsync -avz dm-latest-linux-amd64/bin/ /home/dm/bin/ -
机器列表，这里我们主要熟悉部署过程，且不需要分库分表合并等功能，只实现 syncer 流程，因此 master 和 worker 均只部署在同一台机器：
角色 地址 DM-master 127.0.0.1:8261 DM-worker 127.0.0.1:8262
配置文件
dm-worker
# DM-worker Configuration: worker.toml
# MySQL Server ID, 注意不要和已有的 ID 冲突
server-id = 8262
# 可以理解为 worker 的唯一标识
source-id = "worker-8262"
worker-addr = "127.0.0.1:8262"
# 支持源为 mysql 或 mariadb
flavor = "mysql"
# 是否启用 GTID，开启前需要上游 MySQL 开启 GTID 功能
enable-gtid = true
# MySQL Master/Slave 发生切换时，是否修复 gtid
auto-fix-gtid = true
# 开始同步的位置，我这里使用 GTID，该值为 MySQL Master 上的 Executed_Gtid_Set 值
# relay-binlog-name = "binlog.000140"
relay-binlog-gtid = "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2"
# charset of DSN of source mysql/mariadb instance
charset = ""
# worker 元数据存储目录，需要提前创建好
meta-dir = "/home/dm/meta/worker-8262"
# relay log 的本地存储目录，需要提前创建好
relay-dir = "/home/dm/relay/worker-8262"
# 源数据库，一个 worker 只能对应一个 MySQL 源
[from]
host = "127.0.0.1"
user = "dm"
# 该密码为使用 dmctl -encrypt ${你的原始密码} 加密后的字符串
password = "vUYLfdtQlHLF6Kr4IHg8NkDjiPtVig6p"
port = 3306
# relay log purge strategy
[purge]
interval = 3600
expires = 0
remain-space = 15
配置不算特别复杂，需要留意的地方都在注释里进行说明了。其中 source-id 请记下来，接着配置 dm-master 需要用到。
再次提醒，MySQL 的密码配置需要使用 dmctl 进行加密处理。
dm-master
# dm-master Configuration: master.toml
log-level = "info"
log-file = "/home/dm/log/dm-master.log"
master-addr = "127.0.0.1:8261"
[[deploy]]
source-id = "worker-8262"
dm-worker = "127.0.0.1:8262"
配置文件比较简单，基本上都不需要解释。其中 [[deploy]] 对应一个 worker，可以有多个 [[deploy]] 。目前了解到的，dm-worker 只能通过配置文件并重启 dm-master 进行加载，无法通过 dmctl 进行运行时填加。好在 dm-master 几乎随时都可以重启，所以也不是特别大的问题。
dmctl
# dmctl Configuration: ctl.toml
master-addr = "127.0.0.1:8261"
dmctl 的配置就相当简单了，只需要指定 dm-master 地址。而 dmctl 也是我们与 dm-master 打交道的最直接工作。
集群启动
经过上述的配置（是不是没有想像中复杂），我们已经可以开启集群了：
- 启动 master: bin/dm-master -config master.toml
- 启动 worker: bin/dm-worker -config worker.toml
除了跟踪日志输出，确认进程是否正常启动。我们还可以借助 dmctl 来检查当前集群的情况，使用 bin/dmctl -config ctl.toml 连接集群，并通过 query-status 查询集群状态，返回如下（成功）：
» query-status
{
"result": true,
"msg": "",
"workers": [
{
"result": true,
"worker": "127.0.0.1:8262",
"msg": "no sub task started",
"subTaskStatus": [
],
"relayStatus": {
"masterBinlog": "(binlog.000172, 234)",
"masterBinlogGtid": "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2",
"relaySubDir": "2ea42e60-a157-11e9-8f2d-0ef02be0adee.000001",
"relayBinlog": "(, 4)",
"relayBinlogGtid": "34204ac9-a157-11e9-bc03-c6e9019f8073:1-2,2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558",
"relayCatchUpMaster": true,
"stage": "Running",
"result": null
},
"sourceID": "worker-8262"
}
]
}
»
这个时候，系统还没有配置任何同步任务，所以也可以看到显示的是：no sub task started。接下来，我们开始来配置一个最基础的同步任务。
配置并应用同步任务
创建任务配置文件
PingCAP 在任务配置这一块有比较完善的说明了DM 任务配置文件介绍。这里我们以将源库为 abc 迁到目标库 abc_dm 为例子做简单说明：
---
name: test
task-mode: all
is-sharding: false
meta-schema: "dm_meta"
remove-meta: false
enable-heartbeat: false
target-database:
host: "192.168.143.41"
port: 3306
user: "dm"
password: "vUYLfdtQlHLF6Kr4IHg8NkDjiPtVig6p"
mysql-instances: # 源库及相关的同步规则配置
-
source-id: "worker-8262"
meta:
binlog-name: binlog.000140
binlog-pos: 141868
route-rules: ["user-route-rules-schema"]
black-white-list: "instance"
routes:
user-route-rules-schema:
schema-pattern: "abc"
target-schema: "abc_dm"
black-white-list:
instance:
do-dbs: ["abc"]
上面参数的说明都可以在官方文档找到，这里对几个重要的参数再做补充说明：
| 参数 | 说明 |
|---|---|
| meta-schema | DM 会将该 task 对应的 meta 信息，如断点（checkpoint）存储至目标集存中的该数据库 |
| remove-meta | 通常我们希望在重启 worker/task 时可以从上次断点继续同步，需要设置为 false |
| password | 需要使用 dmctl 加密 |
| source-id | 理解为相应 dm worker 的 source-id |
| routes | 可以在这里配置数据库表的改名规则，具体参考官方文档 |
| filters | 这里没有用到，可以过滤相应的 binlog events，如 drop table 操作，具体参考官方文档
|
应用并启动同步任务
使用 bin/dmctl -config ctl.toml 登录 dm master，并执行 start-task test.yaml 即可，确认 test.yaml 文件在当前目录下，成功的话将收到如下返回：
{
"result": true,
"msg": "",
"workers": [
{
"result": true,
"worker": "127.0.0.1:8262",
"msg": ""
}
]
}
这个时候再执行 query-status 可以看到相应的 dm worker 有了具体的 subTaskStatus 信息：
"subTaskStatus": [
{
"name": "test",
"stage": "Paused",
"unit": "Sync",
"result": {
"isCanceled": false,
"errors": [
],
"detail": null
},
"unresolvedDDLLockID": "",
"sync": {
"totalEvents": "0",
"totalTps": "0",
"recentTps": "0",
"masterBinlog": "(binlog.000176, 234)",
"masterBinlogGtid": "2ea42e60-a157-11e9-8f2d-0ef02be0adee:1-3472558,34204ac9-a157-11e9-bc03-c6e9019f8073:1-2",
"syncerBinlog": "(, 4)",
"syncerBinlogGtid": "",
"blockingDDLs": [
],
"unresolvedGroups": [
],
"synced": false
}
}
],
这个时候我们通过 mysql 登录目标数据库，可以看到多了 dm_meta 和 abc_dm 两个数据库，其中 dm_meta 里面有两张表：
-
test_loader_checkpoint其中 test 是任务的名称，这张表存储的是全量同步的 meta 信息；id: worker-8262 filename: abc.t3.sql cp_schema: abc cp_table: t3 offset: 156 end_pos: 156 create_time: 2019-09-29 12:03:59 update_time: 2019-09-29 12:04:00
-
test_syncer_checkpint其中 test 是任务的名称，这张表存储的是增量同步的 meta 信息；id: worker-8262 cp_schema: abc cp_table: xxy binlog_name: binlog|000001.000176 binlog_pos: 538 is_global: 0 create_time: 2019-09-29 12:11:25 update_time: 2019-09-29 12:11:25
组件升级
dm-master
dm-master 主要负责 dmctl 的通讯，维护任务及 Sharding DDL lock 信息，重启后会与 dm-worker 重启这些信息，所以除了影响 dmctl 短暂的使用，可以随时重启，升级也就比较简单了：下载新版本 -> 覆盖旧 binary -> 重启。
dm-worker
dm-worker 在本地维护了 meta 信息，在下游（目标）数据库维护了断点（checkpoint）信息，升级也是按：下载新版本 -> 覆盖旧 binary -> 重启即可。唯一需要注意的有：
尽量避免在 sharding DDL 同步过程中重启 DM-worker。
当然，本身对数据的敬畏之心，即使没有 sharding，也不推荐在 DDL 的过程中重启 dm-worker。
dmctl
命令行交互工具，直接升级即可：下载新版本 -> 覆盖旧 binary。
问题处理
-
dm-worker 挂了，并且本地的 meta 信息都丢失了怎么办？
通常不需要担心，找回按原来的 worker.toml 再启动 worker 即可。其中配置文件中的
relay-binlog-gtid或relay-binlog-name的位置信息可能在源数据库已经过期，可以从目标集群的 meta 库找回，或者直接从源数据库集群上使用一个相对靠前的位置信息替换即可。确认新的 worker 已经启动后，再次通过 dmctl 执行
start-task test.yaml即可，task 的配置文件不需要修改，断点信息会从目标数据库中的 meta 库直接获取。
总结
官方的组件（概念）特别多，ansible 的包装让用户对相关组件的工作流程了解门槛大大提升。实际部署流程比想像中较为简单。从可靠性来看，还是比较推荐放弃 syncer（较长时间未更新了），并使用 dm 做为替代工具。
网友评论