写点什么

体验更简单的 DM —— v1.0.2

  • 2022 年 7 月 11 日
  • 本文字数:3165 字

    阅读完需:约 10 分钟

原文来源:https://tidb.net/blog/2fbf7fb7

作者:王相


在 DM 发布 GA 版本之后,很多用户尝试使用 DM 来同步 MySQL 的数据到 TiDB。但是用户普遍反馈 DM 的配置太复杂,想成功创建一个数据同步任务都比较困难。为了让大家能更简单地使用 DM,我们在 v1.0.2 版本中重点对 DM 的易用性做了优化(功能并没有缩水),主要包括:


  1. 简化配置,可以自动生成的配置不再需要让用户手动设置;

  2. 优化 query-status 输出,方便查看任务状态;

  3. 对 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。此外,我们也开始了下一步的易用性的改进,主要包括:


  1. dmctl 支持命令行模式

  2. query-status 详细显示信息优化

  3. 错误信息展示与 log 优化

  4. SQL 同步出错 skip/replace 优化


这些优化将在 v1.0.3 版本发布,大家敬请期待。


发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
体验更简单的 DM —— v1.0.2_TiDB 社区干货传送门_InfoQ写作社区