作者：王相
在 DM 发布 GA 版本之后，很多用户尝试使用 DM 来同步 MySQL 的数据到 TiDB。但是用户普遍反馈 DM 的配置太复杂，想成功创建一个数据同步任务都比较困难。为了让大家能更简单地使用 DM，我们在 v1.0.2 版本中重点对 DM 的易用性做了优化（功能并没有缩水），主要包括：
- 简化配置，可以自动生成的配置不再需要让用户手动设置；
- 优化 query-status 输出，方便查看任务状态；
- 对 DM 文档的结构和内容都做了改进。
DM-worker 配置的优化
首先看下 DM-worker 配置优化后的示例配置文件：
# Worker Configuration.
# Log configuration.
log-file = "dm-worker.log"
# DM-worker listen address.
worker-addr = ":8262"
# Represents a MySQL/MariaDB instance or a replication group.
source-id = "mysql-replica-01"
# The directory that used to store relay log.
relay-dir = "./relay_log"
[from]
host = "127.0.0.1"
user = "root"
password = "Up8156jArvIPymkVC+5LxkAT6rek"
port = 3306
只包含了最基础的配置项，是不是比之前要简单了很多？下面具体看下我们简化了哪些配置。
自动生成 server-id 配置
DM-worker 的 relay log 模块会伪装成 MySQL/MariaDB slave service 来获取 Binlog 数据，因此需要为其设置一个在上游 MySQL/MariaDB 复制组中能保持唯一的 server-id，在 v1.0.2 中 DM-worker 会自动生成随机的 server-id，大家可能会担心随机的 server-id 会不会和已有的 server-id 冲突，为了防止这种情况，DM 会去上游查询所有已经使用的 server-id，如果随机产生的 server-id 已经使用则会再次随机生成。
自动生成 flavor 配置
目前 DM 支持同步的数据库类型包括 MySQL 和 MariaDB，它们的 Binlog 协议是不一样的，因此需要区分。在 v1.0.2 中 DM 会自动查询上游的版本信息从而区分数据库类型是 MySQL 还是 MariaDB，不再需要用户手动配置 flavor。
优化 relay-binlog-name 和 relay-binlog-gtid 配置
DM-worker 拉取上游 Binlog 后将数据保存到本地的 relay log 目录下，通过 relay-binlog-name 或者 relay-binlog-gtid 来设置拉取的起始位置。在 v1.0.2 版本前如果没有配置这两项，默认会从最早的 Binlog position 或空的 GTID sets 开始拉取数据。如果上游保存的 Binlog 文件太多了，DM 要消耗较长时间获取这些数据，且会占用很多本地磁盘空间；同时如果是 GTID 模式且上游已经有 Binlog 被清理了，还会由于不能满足 Binlog 拉取需求而报错。实际上在大部分情况下，用户是先部署 DM 然后再创建数据同步任务，因此 DM 默认从最新位置开始获取 Binlog 数据即可。因此我们在 v1.0.2 版本对这个逻辑进行了优化，一般情况下不需要再手动增加这两项配置。
任务配置的优化
DM 提供的功能比较多，因此 DM 的任务配置最复杂，我们在 v1.0.2 中也做了些配置的简化。
自动生成 Mydumper 的导出表列表
DM 的任务配置中使用黑白名单来设置同步（或者不同步）哪些库、表，但是还需要在 Mydumper 配置中的 extra-args 配置项中设置 Mydumper 需要导出哪些库、表的数据，这就等于让大家为同一功能配置了两次。在 v1.0.2 版本中我们也对此做了优化，DM 根据黑白名单配置自动生成 Mydumper 的参数，大多数情况下不再需要对 Mydumper 进行特殊配置。
注意：如果同步的表太多（上万）则生成的 Mydumper 的 tables-list 长度可能会超过 Linux 启动进程时参数的长度限制，在这种情况下还需要大家手动配置 Mydumper 的 extra-args 配置项。
增加配置项 mydumper-thread loader-thread syncer-thread
熟悉 DM 的同学应该知道 DM 会把数据同步任务分为全量数据导出（dump）、全量数据导入（load）、增量数据导出（relay）和增量数据同步（sync）四个子单元。对于 dump、load 和 sync 这几个子单元的关键配置主要为同步的线程数量，默认配置可以满足绝大多数场景下性能的要求，如果对同步速度的要求比较高，则需要对这些配置项做调整。在 v1.0.2 之前如果要修改这几个子单元的线程数量配置，还需要专门增加 mydumpers、loaders、syncers 的配置项，如下：
mysql-instances:
-
source-id: "mysql-replica-01" # 上游实例或者复制组 ID
mydumper-config-name: "global" # mydumper 配置名称
loader-config-name: "global" # loader 配置名称
syncer-config-name: "global" # Syncer 配置名称
mydumpers: # mydumper 处理单元运行配置参数
global: # 配置名称
threads: 4 # mydumper 从上游数据库实例导出数据的线程数量，默认值为 4
loaders: # loader 处理单元运行配置参数
global: # 配置名称
pool-size: 16 # loader 并发执行 mydumper 的 SQL 文件的线程数量，默认值为 16
syncers: # syncer 处理单元运行配置参数
global: # 配置名称
worker-count: 16 # syncer 并发同步 binlog event 的线程数量，默认值为 16
可以从上面的示例中看出来配置比较复杂，因此我们增加了三个配置项 mydumper-thread、loader-thread 和 syncer-thread，用户如果需要调整同步速度，则可以直接在 mysql-instances 的配置项中设置这三项配置，如下所示：
# ----------- 实例配置 -----------
mysql-instances:
-
source-id: "mysql-replica-01" # 上游实例或者复制组 ID
mydumper-thread: 4 # mydumper 用于导出数据的线程数量，等同于 mydumper 处理单元配置中的 `threads`
loader-thread: 16 # loader 用于导入数据的线程数量，等同于 loader 处理单元配置中的 `pool-size`
syncer-thread: 16 # syncer 用于同步增量数据的线程数量，等同于 syncer 处理单元配置中的 `worker-count`
任务状态输出的优化
之前有用户反馈过，在某些场景下使用 dmctl 的query-status 查看任务状态的输出几乎不可用，因为需要从上百行，甚至上千行的刷屏输出结果中提取有用的信息。在 v1.0.2 版本中对 query-status 的输出做了优化，query-status 只输出任务状态的简易列表，如下所示：
{
"result": true,
"msg: "",
"tasks": [
{
"taskName": "task-1",
"taskStatus": "Running",
"workers": ["127.0.0.1:8262"]
},
{
"taskName": "task-2",
"taskStatus": "Error - Some error occurred in subtask",
"workers": ["127.0.0.1:8262", "127.0.0.1:8263"]
}
]
}
可以清晰地看到任务的状态，如果运行中有错误，也能直接看到错误信息。如果希望查看某个任务详细的状态信息，可以执行命令 query-status <task name>。
文档的优化
对于 DM-worker 和任务的配置都划分为了基础配置和完整配置，对于一般场景，用户只需要根据基础配置文档来部署 DM、创建同步任务即可，降低了大家使用 DM 的门槛。链接如下：
另外对于故障诊断的结构也做了优化，大家遇到问题可以看下文档如何诊断问题、有没有解决方案：DM 故障诊断。
欢迎大家使用 DM v1.0.2，使用过程中有问题或者建议欢迎给我们提 issue。此外，我们也开始了下一步的易用性的改进，主要包括：
- dmctl 支持命令行模式
- query-status 详细显示信息优化
- 错误信息展示与 log 优化
- SQL 同步出错 skip/replace 优化
这些优化将在 v1.0.3 版本发布，大家敬请期待。