dm配置文件配置项求解

[qq悟空 (七七)]

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

• 【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配置项还需要配置吗 ？

谢谢

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

[qizheng]

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，
过滤规则顺序参考
https://pingcap.com/docs-cn/stable/reference/tools/data-migration/features/overview/#过滤规则

[qq悟空 (七七)]

谢谢大佬确认和恢复 。当前场景需求：同步以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

[zzzzzz (Tz)]

1. 同一个表匹配上多个规则，将会顺序应用这些规则，并且黑名单的优先级高于白名单，即如果同时存在规则 Ignore 和 Do 应用在某个 table 上，那么 Ignore 生效。

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

[qq悟空 (七七)]

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

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

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

[zzzzzz (Tz)]

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

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

[qq悟空 (七七)]

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

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

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

谢谢

[zzzzzz (Tz)]

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

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

[qq悟空 (七七)]

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

[不懂就问 (zhouyueyue)]

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

[qq悟空 (七七)]

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

[不懂就问 (zhouyueyue)]

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

[qq悟空 (七七)]

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

谢谢

[不懂就问 (zhouyueyue)]

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