dm配置文件配置项求解

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:V3.0.3
  • 【问题描述】:dm版本 V1.0.3

如下配置文件案例,当mysql-instances中存在多个source-id即多个dm-work任务时

问题1: mydumpers阶段中的 threads 参数,loaders阶段中的 pool-size 参数,syncers阶段中的 worker-count 参数 。 这3个参数是多个source-id共用的全局配置(累积值)吗, 还是每个source-id任务独立各自使用该参数呢?

问题2:当配置中同时存在 routes、black-white-list、filters 三个模块时,这3个模块的匹配&过滤顺序是完全固化的吗 ? 还是在正文下方,先出现先匹配? 又或者是取决于 source-id 配置项后出现的顺序呢 ?

问题3: 上游mysql有20个表,下游tidb只同步4个表。 如果black-white-list模块中使用do-tables配置项就可以把4个表匹配标识出来,那么ignore-dbs配置项还需要配置吗 ?

谢谢 :slight_smile:

mysql-instances:

source-id: "dm-01"
route-rules: ["rule-1", "rule-2"]
black-white-list: "global"
filter-rules: ["filter-supported-rule"]
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"

source-id: "dm-02"
route-rules: ["rule-1", "rule-2"]
black-white-list: "global"
filter-rules: ["filter-supported-rule"]
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"

source-id: "dm-03"
route-rules: ["rule-1", "rule-2"]
black-white-list: "global"
filter-rules: ["filter-supported-rule"]
mydumper-config-name: "global"
loader-config-name: "global"
syncer-config-name: "global"

routes: rule-1: xxx

black-white-list: global: xxx

filters:

filter-supported-rule:

schema-pattern: "pd_user"
events: ["create table", "all dml"]
action: Do

mydumpers:

global:

mydumper-path: "./bin/mydumper"
threads: 12
chunk-filesize: 64
skip-tz-utc: true

loaders:

global:

pool-size: 24
dir: "./dumped_data"

syncers:

global:

worker-count: 64
batch: 100
max-retry: 100

1、每组 mydumper 和 loader 对应一个上游的 mysql source,threads 和 pool-size 是在 dump 和 load 阶段时 mydumper 和 loader 进程的参数,每个 source-id 独立使用;worker-count 是 syncer 增量同步到下游时的 worker 线程数量,可以认为是多个 source-id 共用的配置。

2、在 DDL 和 DML 同步转换时按照程序内部的固定流程执行,与 routes、black-white-list、filters 在任务配置中的出现顺序及 source-id 的出现顺序无关,详细流程参考 PU 视频课程《生态工具原理》相关章节

3、black-white-list 下设置了 do-tables,不需要再配置 ignore-dbs,即当 do-dbs 和 ignore-dbs 都为空,则进入 table 过滤判断 do-tables, 过滤规则顺序参考

1赞

谢谢大佬确认和恢复 。当前场景需求:同步以pd_user_xxx开头的多个分库内的多个分表,只同步create table和dml类型的binlog;其他类型的binlog(不支持的ddl,以及alter table类型的ddl)都要过滤掉,不同步到下游tidb中。

1: 下面这样配置,是准确的吗 ?

2: 由于alter table类型的ddl被dm过滤掉了,当有新的ddl变更时,是先在下游tidb上执行完成后再在上游db执行,是吗?

谢谢

filters:

filter-supported-rule:

schema-pattern: "pd_user_*"
events: ["create table", "all dml"]
action: Do

filter-unsupported-rule:

schema-pattern: "*"
sql-pattern: ["unsupported-sql", "alter table"]
action: Ignore
  1. 同一个表匹配上多个规则,将会顺序应用这些规则,并且黑名单的优先级高于白名单,即如果同时存在规则 IgnoreDo 应用在某个 table 上,那么 Ignore 生效。

  2. dm 可以处理 alter table,机制是等待上有所有分表 表结构一致后 继续同步。

dm处理分库分表的ddl看文档比较复杂,可能会导致dml语句在下游tidb上的回放滞后。

期望是这样的:dm同步只负责dml语句的回放,不同步ddl ;ddl语句由人肉手动先在下游tidb执行,然后在上游db再执行。

这样的方案,行得通吗 ? 可能会出现什么问题吗 ,谢谢

从逻辑上来讲,总是要等待上游 DDL 全部同步后,再进行 dml。

这边可以测试一下。正常情况下,是同步的很快的。

有个核心的业务表有1000多个分表,各个分表数据量也比较大,生产环境暂时还没测试,下游业务对延迟比较敏感。

期望是这样的:dm同步只负责dml语句的回放,不同步ddl ;ddl语句由人肉手动先在下游tidb执行,然后在上游db再执行。这样的方案,行得通吗 ? 可能会出现什么问题呢?

另外syncers模块对于dml的回放阶段,除了配置worker-count和batch参数外,还有其他可配置参数,来加速回放速度吗 ?

谢谢

  1. 不同步的 ddl 的话,在表结构不一致的时候,同步会断开。

  2. dm 侧回放速度主要是这两个参数。 也可以增加 LB 组件,打散到下游多个 tidb 来提速。

用LB打散到下游多个 tidb的话,如果其中一个tidb挂掉了,发到该tidb上的事务执行失败了,那么这个时候dm是否会将失败的事务在其他存活的tidb上进行重试呢? dm这个时候该怎么处理呢? 谢谢

DM 的 ga 版本之后,对于 已经发到 tidb-server ,节点挂掉是没有办法重试的,直接再发一次有问题。对于没有发送到 tidb-server (没有任何数据通过网络发送到 tidb-server)的情况是会进行重试。所以针对提出来的问题,DM 这块是没办法保证的。

如果是这样的话,那LB组件适合用来做读业务的高可用,不适合放到dm里进行写数据的分发。

是的,对于上面列出的情况,DM 不支持。

好的,谢谢确认。 请问dm的高可用方面的功能支持有吗 ? 或者目前有该方面的上线版本排期吗 ?

谢谢

对于上面提出来高可用,暂时还没有版本以及排期。