dm 5.4.0 迁移任务，有没有具体的操作步骤

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境`】生产

生产环境现在需要将一套老的DM 集群迁移到新的DM集群上。有没有具体的操作步骤？
下面是我整理的，不知道是否正确。3. 任务迁移
由于 DM 集群的元数据存储（如 checkpoint、shard DDL lock 状态及 online DDL 元信息等数据，因此在执行升级操作前需要确保：
所有数据迁移任务不处于 shard DDL 协调过程中。
所有数据迁移任务不处于 online DDL 协调过程中。
1、导出老集群数据源和任务
tiup dmctl --master-addr master_ip:master_port config export -d /home/tidb/dm_configs/

2、创建新集群数据库源
tiup dmctl --master-addr master_ip:master_port operate-source create ./dmsource.ymal

3、查看新集群数据源
tiup dmctl --master-addr master_ip:master_port config source mysql-replica-01

4、停止老集群任务
tiup dmctl:v5.4.0 --master-addr master_ip:master_port stop-task task-name

5、查看任务是否正的停止
tiup dmctl:v5.4.0 --master-addr master_ip:master_port query-status task-name

6、修改新集群任务
只需关注并要修改红色位置
use dm_meta;
select * from task_name;查看修改的binlog文件和binlog-pos

name: test5 # 任务名称，需要全局唯一
task-mode: incremental # 任务模式，可设为 “full”、“incremental”、“all”
target-database: # 下游数据库实例配置
host: “172xxxx”
port: 4000
user: “root”
password: “ifYMVmDME4o7KjiXtuVJPUBZu4qW” # 如果不为空则需经过 dmctl 加密
block-allow-list: # 上游数据库实例匹配的表的 block & allow list 过滤规则集，如果 DM 版本 <= v1.0.6 则使用 black-white-list
bw-rule-1: # 黑白名单配置的名称
do-dbs: [“sbtest”] # 迁移哪些库
mysql-instances:

  • source-id: “mysql-replica-01”
    meta:
    binlog-name: “Copy-v1-bin.000001”
    binlog-pos: 377006918
    block-allow-list: “bw-rule-1” # 黑白名单配置名称，如果 DM 版本 <= v1.0.6 则使用 black-white-list
    mydumper-thread: 1 # dump 处理单元用于导出数据的线程数量，在 v1.0.2 版本引入
    loader-thread: 1 # load 处理单元用于导入数据的线程数量，在 v1.0.2 版本引入
    syncer-thread: 1 # sync 处理单元用于复制增量数据的线程数量，在 v1.0.2 版本引入

7、检查新集群任务
tiup dmctl --master-addr master_ip:master_port check-task task-filename

8、启动新集群任务
tiup dmctl:v5.4.1 --master-addr master_ip:master_port start-task task-filename

9、查看新集群任务
tiup dmctl:v5.4.1 --master-addr master_ip:master_port query-status task-name

10、清理老集群的数据源
tiup dmctl:v5.4.0 --master-addr master_ip:master_port operate-source stop source-name

2

主要注意点在第六步这块，下游 TiDB 中已经存在旧 task 的 checkpoint 信息。

  • 看起来你是要创建新的增量同步任务，需要注意 task name 名字要和之前 task name 不一致。否则同步任务启动后，会以 dm-meta 中 checkpoint 开始复制，（虽然没啥大问题，不过还是谨慎一些好）
  • 注意配置 task-mode: incremental 为增量同步模式，并且标注好增量同步的起始位点。

可以在测试环境测试下流程，翻了下暂时没有相关文档流程，如果顺利跑通，也可以分享给社区的小伙伴~

3

我就是要按照目前的checkpoint点同步，不然数据不就不一致了吗？ 还是说我理解错了？

4

操作本身没问题啊，我记得低 DM 版本处理可能有点问题，所以建议你测试一下你的方式。

我说的方式是新建一个 增量同步任务，和之前任务名字区分开，增量同步的起始位点用之前 task 下游的 checkpoint 信息，这样操作也是可行的。

5

准备用5.4.0 的，换一个任务名字，这样更好是吧？

6

嗯 我比较推荐换一个任务名字的方式，官网对于 DM 1.0 到 2.0 的升级操作，也是更换了任务名。更加保险一些。
https://docs.pingcap.com/zh/tidb-data-migration/v5.3/manually-upgrade-dm-1.0-to-2.0#第-4-步升级数据迁移任务

image
image1686×1304 312 KB

7

好的，我在测试环境模拟，用同样的名字也可以，还是换一个吧。谢谢！

8

嗯嗯，生产环境还是谨慎些，一旦出现问题，相同的 task 任务名会把原来的 checkpoint 覆盖掉了。

1 个赞
9

我看还可以这样操作 改变数据源与 DM-worker 的绑定关系

transfer-source 用于改变数据源与 DM-worker 的绑定关系。

Copy

help transfer-source

Transfers a upstream MySQL/MariaDB source to a free worker.

Usage:
  dmctl transfer-source <source-id> <worker-id> [flags]

Flags:
  -h, --help   help for transfer-source

Global Flags:
  -s, --source strings   MySQL Source ID.
10

transfer source 这个适用于同一套 DM 集群内的操作，你这个场景下不适用的

11

可以用集群的导出导入功能，更简单https://docs.pingcap.com/zh/tidb/stable/dm-export-import-config

12

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。