一：环境介绍：

因公司t采用dm 1.0版本，故本过程基于DM集群1.0版本，官方建议使用dm 2.0;  tidb集群版本4.0，上游mysql 社区版5.7.28

1）上游mysql：

SIM:root:[(none)]>select version(); +------------+ | version()  | +------------+ | 5.7.28-log | +------------+ 1 row in set (0.01 sec)

2）中间DM集群

[tidb@tidb-monitor-01 conf]$ dmctl  --master-addr 11.28.11.143:8261 Welcome to dmctl Release Version: v1.0.6 Git Commit Hash: eaf2683c05ab44143bfb286bfbbc3ba157c555cc Git Branch: release-1.0 UTC Build Time: 2020-06-17 10:22:01 Go Version: go version go1.13 linux/amd64

3）下游tidb集群 4.0.8

TIDB:root:[(none)]>select  version(); +--------------------+ | version()          | +--------------------+ | 5.7.25-TiDB-v4.0.8 | +--------------------+ 1 row in set (0.01 sec)

测试DM集群结构介绍：

11.28.11.143     dm-master

11.28.11.143     dm-worker

二：DM集群维护注意事项以及自己的一些理解:

1、 DM 1.0  dm-master和dm-worker没有高可用

因为上游MySQL的信息（source-id）是配置到具体dm-worker配置文件里面的，但是dm 2.0 dm-master和dm-worker有高可用，DM 2.0的source-id不是配置到dm-woker中，需要多一个步骤创建source-id（给dm集群添加source-id）具体命令如下：

tiup dmctl --master-addr 172.16.10.71:8261 operate-source create conf/source1.yaml

2、dm集群的dm-master和dm-worker都有相关进程，但是看不到具体任务的进程！想看具体task状态需要使用：

/home/tidb/dm/dm-ansible-v1.0.6/resources/bin/dmctl  --master-addr 11.28.11.143:8261   query-status  liuwenhe     #liuwenhe为任务名字

/home/tidb/dm/dm-ansible-v1.0.6/resources/bin/dmctl  --master-addr 11.28.11.143:8261  query-error liuwenhe

3、部署好新的dm-worker实例后，该dm-worker时候就会添加到/etc/systemd/system/目录，添加到linux服务， 这样就可以 systemctl  status  dm-worker-8266.service 来查看对应dm-woker的运行状态了，如下步骤必须要做，才能在/etc/systemd/system/目录下生产对应的service配置！

如下所示：一定要在deploy.yml文件所在的目录下执行：

[tidb@tidb-monitor-01 dm-ansible-v1.0.6]$ ll deploy.yml

-rw-r--r-- 1 tidb tidb 1086 Jun 17  2020 deploy.yml

[tidb@tidb-monitor-01 dm-ansible-v1.0.6]$ansible-playbook deploy.yml --tags=dm-worker -l  dm-worker-8266

之后在dm-worker-8266这个实例所在的服务器上就可以通过systemctl来启停和查看查看该worker状态：

[root@tidb-monitor-01 ~]# systemctl  status  dm-worker-8266.service ● dm-worker-8266.service - dm-worker-8266 service   Loaded: loaded (/etc/systemd/system/dm-worker-8266.service; disabled; vendor preset: disabled)   Active: active (running) since Sun 2021-10-31 16:22:08 CST; 1h 11min ago Main PID: 26201 (dm-worker)   CGroup: /system.slice/dm-worker-8266.service           └─26201 bin/dm-worker --worker-addr=:8266 -L=info --relay-dir=/data01/dm_worker_... Oct 31 16:22:08 tidb-monitor-01 systemd[1]: Started dm-worker-8266 service

所以启停动dm-worker的方法有三种：

1）通过ansible-playbook

ansible-playbook stop.yml --tags=dm-worker -l dm-worker-3323

ansible-playbook start.yml --tags=dm-worker -l dm-worker-3323

2）通过systemctl

systemctl  stop   dm-worker-8266.service

systemctl  start    dm-worker-8266.service

3)通过具体的dm-worker命令

nohup ./bin/dm-worker -config conf/dm-worker.toml &

4、关于task的具体配置理解

1）routes路由匹配规则：上游和下游的表对应关系，如果上游和下游表同名，可以只配置库的对应关系即可，如果表名字和库名字都一样，那么就可以不配置！需要注意：需要提前在目的端创建上对应表结构，或者配置如下规则中的route-rule-0（红色部分），这样当你开启task后就会在目标tidb端自动创建上对应的库和表！

官方文档： https://docs.pingcap.com/zh/tidb-data-migration/v1.0/feature-overview#table-routing

routes:

 route-rule-0:

     schema-pattern: "liuwenhe"

     target-schema: "bre_tidb"

route-rule-1:                   # 配置名称

schema-pattern: "liuwenhe"

table-pattern : "bre_event_data_*"

target-schema: "bre_tidb"         # 目标库名称

target-table: "bre_event_data"

2）filters 配置过滤规则，匹配event,  某个库的某些表的具体操作同步或者忽略！

具体细节参看官方文档： https://docs.pingcap.com/zh/tidb-data-migration/v1.0/feature-overview#binlog-event-filter

filters:                                     # 上游数据库实例匹配的表的 binlog event filter规则集  filter-rule-1:                             # 配置名称    schema-pattern: "liuwenhe"                    # 库名匹配规则，支持通配符 "*" 和 "?"    table-pattern: "bre_event_data_*"        # 表名匹配规则，支持通配符 "*" 和 "?"    events: ["truncate table", "drop table"]    # 匹配哪些 event 类型    action: Ignore                              # 对与符合匹配规则的 binlog 复制（Do）还是忽略(Ignore)  filter-rule-2:    schema-pattern: "liuwenhe"    events: ["all dml"]    action: Do

3）block-allow-list白名单配置：同步那些库和那些表，忽略那些库那些表！

官方文档： https://docs.pingcap.com/zh/tidb-data-migration/v1.0/feature-overview#table-routing

black-white-list:                    # 上游数据库实例匹配的表的 block & allow list 过滤规则集，如果 DM 版本 <= v1.0.6 则使用 black-white-list  bw-rule-1:                         # 配置名称    do-dbs: ["liuwenhe"]     # 迁移哪些库    do-tables:                       # 迁移哪些表    - db-name: "liuwenhe"      tbl-name: "bre_event_data_*"    ignore-tables:                   # 忽略哪些表    - db-name: "liuwenhe"      tbl-name: "bre_event_data"    - db-name: "liuwenhe"      tbl-name: "bre_event_data_archive"

4）dm集群中一些目录的设置规则：

默认值为./ 表示当前目录， 基础目录为inventory.ini配置文件中的deploy_dir=/data01/dm_worker_3323

注意1：其中mydumper输出目录为具体task配置文件中的loaders:模块中的dir: "./dumped_data"目录控制，例如设置成：dir: "/data01/data/dumped_data_liu"， 那么当你启动名字为liuwenhe的task后（前提是设置task-mode为full 或者all），就会生成/data01/data/dumped_data_liu.liuwenhe的子目录，dump下来的sql文件就在这里！

注意2：mydumper默认路径在./bin/mydumper，  默认路径会在 deploy_dir=/data01/dm_worker_3323的基础目录下的/bin下去找，需要自己配置成自己的mydumper所在的路径，可以设置绝对路径；如下我设置的是/home/tidb/liuwenhe/mydumper，

mydumpers:                           # dump 处理单元运行配置参数  global:                            # 配置名称    mydumper-path: "/home/tidb/liuwenhe/mydumper"  # dump 处理单元 binary 文件地址，默认值为 "./bin/mydumper"    threads: 4                       # dump 处理单元从上游数据库实例导出数据的线程数量，默认值为 4    chunk-filesize: 64               # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB    skip-tz-utc: true                # 忽略对时间类型数据进行时区转化，默认值为 true    extra-args: "--no-locks"         # dump 处理单元的其他参数，在 v1.0.2 版本中 DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置 loaders:                             # load 处理单元运行配置参数  global:                            # 配置名称    pool-size: 16                    # load 处理单元并发执行 dump 处理单元导出的 SQL 文件的线 程数量，默认值为 16    dir: "/data01/data/dumped_data_liu"             # load 处理单元读取 dump 处理单元输出文件 的地址，同实例对应的不同任务必须不同（dump 处理单元会根据这个地址输出 SQL 文件），默认值为 "./dumped_data"

注意3: 关于relay log的基准目录，dm 1.01是在具体的dm-worker配置文件中配置的，默认也是 deploy_dir=/data01/dm_worker_3323的基础目录下的relay_log

vim /data01/dm_worker_3323/conf/dm-worker.toml # The directory used to store relay log. relay-dir = "./relay_log"

5、关于下游tidb中的dm_meta库

当你新添加了一个名为liuwenhe的task，并且启动后，就会在tidb中创建四个相应以liuwenhe开头的表；

其中liuwenhe_syncer_checkpoint表中记录上游MySQL中的发生过同步数据的相关分库分表的信息！一个表一行数据，注意不是实时记录的，大概有20-30秒的延迟！

如下表示启动task后，上游MySQL中liuwenhe.bre_event_data_2_1 和liuwenhe.bre_event_data_2_2两表触发过同步数据！

TIDB:root:[dm_meta]>select * from  liuwenhe_syncer_checkpoint\G

*************************** 1. row ***************************

id: 13-3323-8266

cp_schema:

cp_table:

binlog_name: binlog|000001.000608

binlog_pos: 73725412

is_global: 1

create_time: 2021-10-30 22:11:55

update_time: 2021-10-30 22:15:56

*************************** 2. row ***************************

id: 13-3323-8266

cp_schema: liuwenhe

cp_table: bre_event_data_2_1

binlog_name: binlog|000001.000608

binlog_pos: 34781987

is_global: 0

create_time: 2021-10-30 22:12:25

update_time: 2021-10-30 22:12:25

*************************** 3. row ***************************

id: 13-3323-8266

cp_schema: liuwenhe

cp_table: bre_event_data_2_2

binlog_name: binlog|000001.000608

binlog_pos: 64819827

is_global: 0

create_time: 2021-10-30 22:15:25

update_time: 2021-10-30 22:15:25

3 rows in set (0.00 sec)

当你手动给上游MySQL的liuwenhe.bre_event_data_2_4 插入一条数据；

SIM:root:[liuwenhe]>insert  into   bre_event_data_2_4 select  * from bre.bre_event_data  where  REQUEST_ID='C011802110030080016';

Query OK, 1 row affected (0.02 sec)

Records: 1  Duplicates: 0  Warnings: 0

过了大概25秒中，再次查看发现多了一条数据，关于 liuwenhe.bre_event_data_2_4 表的数据！

TIDB:root:[dm_meta]>select * from  liuwenhe_syncer_checkpoint\G

*************************** 1. row ***************************

id: 13-3323-8266

cp_schema:

cp_table:

binlog_name: binlog|000001.000608

binlog_pos: 139825784

is_global: 1

create_time: 2021-10-30 22:11:55

update_time: 2021-10-30 22:22:26

*************************** 2. row ***************************

id: 13-3323-8266

cp_schema: liuwenhe

cp_table: bre_event_data_2_1

binlog_name: binlog|000001.000608

binlog_pos: 34781987

is_global: 0

create_time: 2021-10-30 22:12:25

update_time: 2021-10-30 22:12:25

*************************** 3. row ***************************

id: 13-3323-8266

cp_schema: liuwenhe

cp_table: bre_event_data_2_2

binlog_name: binlog|000001.000608

binlog_pos: 64819827

is_global: 0

create_time: 2021-10-30 22:15:25

update_time: 2021-10-30 22:15:25

*************************** 4. row ***************************

        id: 13-3323-8266

 cp_schema: liuwenhe

  cp_table: bre_event_data_2_4

binlog_name: binlog|000001.000608

binlog_pos: 136641037

 is_global: 0

create_time: 2021-10-30 22:22:26

update_time: 2021-10-30 22:22:26

4 rows in set (0.00 sec)

6、上游MySQL必须开启gtid，否则task会报错：

"ErrLevel": 3,

"Message": "TCPReader get relay event with error: ERROR 1236 (HY000): The replication sender thread cannot start in AUTO_POSITION mode: this server has GTID_MODE = OFF instead of ON.",

"RawCause": "ERROR 1236 (HY000): The replication sender thread cannot start in AUTO_POSITION mode: this server has GTID_MODE = OFF instead of ON."

修改MySQL的gtid方式

SIM:root:[liuwenhe]>set  global  gtid_mode=OFF_PERMISSIVE;

SIM:root:[liuwenhe]>set  global  gtid_mode=On_PERMISSIVE;

SIM:root:[liuwenhe]>set  global  gtid_mode=on;

注意上游mysql中的用户，一定要有需要同步的库的权限，否则query-status和 query-error都没有报错，但是mydumper不能dump下数据。只会生成一个metadata文件记录binlog点位！

并且dm只支持binlog为row格式的上游mysql,  所以当分库分表汇总到tidb的场景中，对其中一个表的delete from  table_1 这类的操作，并不会把下游tidb的表清空，只会删除tidb中table_1的相关数据！

7、当上游mysql 执行reset master后

当遇到这种情况的时候，建议从新全量同步数据，防止数据不一致！

8、排查问题

1）查看task的状态，可能会有提示

dmctl  --master-addr 11.28.11.143:8261   query-status  liuwenhe

2）查看task的error信息，

dmctl  --master-addr 11.28.11.143:8261   query-error liuwenhe

3)查看dm-worker运行日志

[tidb@tidb-monitor-01 log]$ pwd

/data01/dm_worker_3323/log

[tidb@tidb-monitor-01 log]$ tail  -n 100  dm-worker.log

9.模拟一个主键冲突的场景，然后尝试跳过某个sql

https://docs.pingcap.com/zh/tidb-data-migration/v1.0/skip-or-replace-abnormal-sql-statements

9、关于增量同步的理解：

1）binlog同步点位或者gtid点位信息记录在如下文件中！实时更新！

[tidb@tidb-monitor-01 78ad9491-9efa-11ea-b4dc-005056b3c9fc.000001]$ cat  relay.meta

binlog-name = "binlog.000025"

binlog-pos = 436295724

binlog-gtid = "78ad9491-9efa-11ea-b4dc-005056b3c9fc:1-27897750"

[tidb@tidb-monitor-01 78ad9491-9efa-11ea-b4dc-005056b3c9fc.000001]$ pwd

/data01/dm_worker_3323/relay_log/78ad9491-9efa-11ea-b4dc-005056b3c9fc.000001

[tidb@tidb-monitor-01 78ad9491-9efa-11ea-b4dc-005056b3c9fc.000001]$

2）关于relay_log的相关目录介绍，请参看官方文档：

https://docs.pingcap.com/zh/tidb-data-migration/v1.0/relay-log

注意这个目录和server-uuid.index文件在启动dm-worker的时候会自动创建上！

[root@tidb-monitor-01 relay_log]# ll

total 4

drwxr--r-- 2 tidb tidb 45 Nov  1 22:48 78ad9491-9efa-11ea-b4dc-005056b3c9fc.000001

-rw-r--r-- 1 tidb tidb 44 Nov  1 22:42 server-uuid.index

Relay-log 本地存储的目录结构示例如下：

• subdir：

• DM-worker 把从上游数据库迁移到的 binlog 存储在同一目录下，每个目录都为一个 subdir。
• subdir 的命名格式为 <上游数据库 UUID>.<本地 subdir 序列号>。
• 在上游进行 master 和 slave 实例切换后，DM-worker 会生成一个序号递增的新 subdir 目录。

• 在以上示例中，对于 7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001 这一目录，7e427cc0-091c-11e9-9e45-72b7c59d52d7 是上游数据库的 UUID，000001 是本地 subdir 的序列号。

• server-uuid.index：记录当前可用的 subdir 目录。
• relay.meta：存储每个 subdir 中已迁移的 binlog 信息。例如，

cat c0149e17-dff1-11e8-b6a8-0242ac110004.000001/relay.meta

binlog-name = "mysql-bin.000010"    # 当前迁移的 binlog 名 binlog-pos = 63083620               # 当前迁移的 binlog 位置 binlog-gtid = "c0149e17-dff1-11e8-b6a8-0242ac110004:1-3328" # 当前迁移的 binlog GTID

也可能包含多个 GTID：

cat 92acbd8a-c844-11e7-94a1-1866daf8accc.000001/relay.meta

binlog-name = "mysql-bin.018393" binlog-pos = 277987307 binlog-gtid = "3ccc475b-2343-11e7-be21-6c0b84d59f30:1-14,406a3f61-690d-11e7-87c5-6c92b

3）开启增量复制：remove-meta 设置为false 即可实现增量同步，但是注意不知道为啥，需要设置task-mode: all  # full/incremental/all

具体如下：

task-mode: all  # full/incremental/all

meta-schema: "dm_meta"

remove-meta: false

meta-schema: "dm_meta"          # 下游储存 `meta` 信息的数据库 remove-meta: false              # 是否在开始运行任务前移除该任务名对应的 `meta`（`checkpoint` 和 `onlineddl` 等）。

实验思路：首先设置全量同步+增量同步保持task运行中，然后关闭task, 上游MySQLinsert一条数据，然后尝试启动task, 目的是让他只增量同步新insert的数据，

实验结果：

实验1 成功实现增量同步！ 如下组合可以成功实验只同步新增加的一条数据，并且没有从新dump上游MySQL数据！

task-mode: all

remove-meta: false

实验2 如下task配置组合报错：

task-mode: incremental  # full/incremental/all

remove-meta: false

报错如下

[tidb@tidb-monitor-01 resources]$ dmctl  --master-addr 11.28.11.143:8261  stop-task  liuwenhe{    "op": "Stop",    "result": false,    "msg": "task liuwenhe has no workers or not exist, can try `refresh-worker-tasks` cmd first",    "workers": [    ] } [tidb@tidb-monitor-01 resources]$ dmctl  --master-addr 11.28.11.143:8261   start-task  /home/tidb/dm-ansible-v1.0.6/resources/conf/task_3323.yaml {    "result": false,    "msg": "[code=20022:class=dm-master:scope=internal:level=medium] mysql-instance(0) must set meta for task-mode incremental\ngithub.com/pingcap/dm/pkg/terror.(*Error).Generate\n\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/pkg/terror/terror.go:236\ngithub.com/pingcap/dm/dm/config.(*TaskConfig).adjust\n\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/dm/config/task.go:378\ngithub.com/pingcap/dm/dm/config.(*TaskConfig).Decode\n\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/dm/config/task.go:330\ngithub.com/pingcap/dm/dm/master.(*Server).generateSubTask\n\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/dm/master/server.go:1851\ngithub.com/pingcap/dm/dm/master.(*Server).StartTask\n\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/dm/master/server.go:230\ngithub.com/pingcap/dm/dm/pb._Master_StartTask_Handler\n\t/home/jenkins/agent/workspace/build_dm_master/go/src/github.com/pingcap/dm/dm/pb/dmmaster.pb.go:2355\ngoogle.golang.org/grpc.(*Server).processUnaryRPC\n\t/go/pkg/mod/google.golang.org/grpc@v1.25.1/server.go:1007\ngoogle.golang.org/grpc.(*Server).handleStream\n\t/go/pkg/mod/google.golang.org/grpc@v1.25.1/server.go:1287\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.1\n\t/go/pkg/mod/google.golang.org/grpc@v1.25.1/server.go:722\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1357",    "workers": [    ] }

实验3 尝试手动删除下游tidb的dm_meta库的liuwenhe_syncer_checkpoint和liuwenhe_loader_checkpoint， 注意一定要同时删除如下两表才能实现全量同步！因为remove-meta: false就是删除如下这俩表的内容！

TIDB:root:[dm_meta]>truncate table liuwenhe_syncer_checkpoint;

Query OK, 0 rows affected (0.10 sec)

TIDB:root:[dm_meta]>truncate table  liuwenhe_loader_checkpoint;

Query OK, 0 rows affected (0.10 sec)

task 配置如下，这样就触发了全量同步，从新导出上游MySQL的数据库表！

task-mode: all

remove-meta: false

10 当同一个task涉及到多个上游MySQL的时候，binlog-pos会怎么显示呢？

这个问题多虑了，因为sql-skip的时候你写上了--worker信息，那么就特指这个worker的binlog-pos信息！

» sql-skip --worker=11.28.11.147:8266  --binlog-pos="binlog|000001.000025:166513224"  liuwenhe

不指定--worker信息就报错，其实想想也能想明白，因为dm 1.0是一个worker里面配置了一个上游MySQL的源，当某个task涉及到多个上游的MySQL源的时候，一定是需要却分的，那就以--worker区分！

» sql-skip --binlog-pos="binlog|000001.000053:486098469"  liuwenhe

should only specify one worker, but got []

11、非常关 键的一个参数在task的配置文件中设置：safe-mode: false，

safe-mode: false  # 设置为 true，则将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。 在启动或恢复增量复制任务的前 5 分钟内 TiDB DM 会自动启动 safe mode,这是这个原因所以当你启动某个task_mode 为all的任务的时候，当全量同步完成后，切换到增量的前5分钟内是safe-mode:true，这样就不会有主键冲突的问题!

12 、关于dm-worker的relay log的删除策略，需要注意的是remain-space的优先级大于expire，如果如下所示，同时设置expires和remain-space,那么当expires到了之后不会触发删除操作！只有当磁盘小于15g的时候才会触发！

#relay log purge strategy

[purge]

interval = 3600     #单位秒，默认3600秒 也就是一个小时检查一次！

expires = 24      # relay log 的过期时间，单位小时

remain-space = 15  #剩余15g触发删除，设置为0表示无磁盘剩余条件限制！

relay log 清理策略配置（purge 配置项）

一般情况下不需要手动配置，如果 relay log 数据量较大，磁盘空间不足，则可以通过该配置项设置，避免 relay log 写满磁盘。

配置项	说明
interval	定期检查 relay log 是否过期的间隔时间，默认值：3600，单位：秒。
expires	relay log 的过期时间，默认值为 0，单位：小时。未由 relay 处理单元进行写入、或已有数据迁移任务当前或未来不需要读取的 relay log 在超过过期时间后会被 DM 删除。如果不设置则 DM 不会自动清理过期的 relay log。
remain-space	设置最小的可用磁盘空间。当磁盘可用空间小于这个值时，DM-worker 会尝试删除 relay log，默认值：15，单位：GB。

注意：

仅在 interval 不为 0 且 expires 和 remain-space 两个配置项中至少有一个不为 0 的情况下 DM 的自动清理策略才会生效。

13 当dm-master死掉后，dm-worker可以正常运转，并且dm-worker上的task也正常，除非遇到分库分表修改表结构的情况

1）关闭dm-master

[tidb@tidb-monitor-01 dm-ansible-v1.0.6]$ ansible-playbook stop.yml --tags=dm-master

2)上游mysql insert一条数据

SIM:root:[liuwenhe]>insert into   bre_event_data_2_2     select  * from  bre.bre_event_datawhere  REQUEST_ID='C011802110030080036';

Query OK, 1 row affected (0.00 sec)

Records: 1  Duplicates: 0  Warnings: 0

3）下游tidb中查看

上游insert前确认没有C011802110030080036的数据！

TIDB:root:[dm_meta]>select REQUEST_ID  from  bre_tidb.bre_event_data;

+---------------------+

| REQUEST_ID          |

+---------------------+

| C011802110030080001 |

| C011802110030080003 |

| C011802110030080004 |

| C011802110030080010 |

| C011802110030080035 |

+---------------------+

5 rows in set (0.01 sec)

上游insert后，发现有C011802110030080036的数据了

TIDB:root:[dm_meta]>select REQUEST_ID  from  bre_tidb.bre_event_data;

+---------------------+

| REQUEST_ID          |

+---------------------+

| C011802110030080001 |

| C011802110030080003 |

| C011802110030080004 |

| C011802110030080010 |

| C011802110030080035 |

| C011802110030080036 |

+---------------------+

6 rows in set (0.00 sec)

4）但是因为dm-master死掉了，所以不能使用dmctl了

[tidb@tidb-monitor-01 dm-ansible-v1.0.6]$ dmctl  --master-addr 11.28.11.143:8261  query-status   liuwenhe

can not query liuwenhe task's status(in workers []):

rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connectionerror: connection error: desc = "transport: Error while dialing dial tcp 11.28.11.143:8261: connect: connection refused"

但是可以如下查看dm-worker的状态

[tidb@tidb-monitor-01 dm-ansible-v1.0.6]$ systemctl  status  dm-worker-8266.service

● dm-worker-8266.service - dm-worker-8266 service

Loaded: loaded (/etc/systemd/system/dm-worker-8266.service; disabled; vendor preset: disabled)

Active: active (running) since Mon 2021-11-01 22:42:35 CST; 14min ago

Main PID: 27810 (dm-worker)

CGroup: /system.slice/dm-worker-8266.service

└─27810 bin/dm-worker --worker-addr=:8266 -L=info --relay-dir=/data01/dm_worker...

参考官方文档，了解dm-master和dm-worker的作用！

https://docs.pingcap.com/zh/tidb-data-migration/v1.0/overview

DM-master 负责管理和调度数据迁移任务的各项操作。

• 保存 DM 集群的拓扑信息
• 监控 DM-worker 进程的运行状态
• 监控数据迁移任务的运行状态
• 提供数据迁移任务管理的统一入口
• 协调分库分表场景下各个实例分表的 DDL 迁移

DM-worker 负责执行具体的数据迁移任务。

• 将 binlog 数据持久化保存在本地
• 保存数据迁移子任务的配置信息
• 编排数据迁移子任务的运行
• 监控数据迁移子任务的运行状态

所以dm-master死掉后，就不能添加task任务了，但是如果上游MySQL 分库分表的情况下，没有修改表结构，那么已经存在的task理论上是可以正常运行的！