DM 部署

第 1 步：在中控机上安装 TiUP 组件

使用普通用户登录中控机，以 TiDB 用户为例，后续安装 TiUP 及集群管理操作均通过该用户完成：

执行如下命令安装 TiUP 工具：

curl --proto =https --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

安装完成后，~/.bashrc 已将 TiUP 加入到路径中，你需要新开一个终端或重新声明全局变量 source ~/.bashrc 来使用 TiUP。

source /home/tidb/.bash_profile

安装 TiUP DM 组件：

tiup install dm dmctl

第 2 步：编辑初始化配置文件

$ vim dm-test-topology.yaml# Global variables are applied to all deployments and as the default value of # them if the specific deployment value missing. global: user: "tidb" ssh_port: 22 deploy_dir: "/data/dm-deploy" data_dir: "/data/dm-data" server_configs: master: log-level: info # rpc-timeout: "30s" # rpc-rate-limit: 10.0 # rpc-rate-burst: 40 worker: log-level: info master_servers: - host: 10.1.1.6 name: master1 ssh_port: 22 port: 8261 peer_port: 8291 deploy_dir: "/data/dm-deploy/dm-master-8261" data_dir: "/data/dm-data/dm-master-8261" log_dir: "/data/dm-deploy/dm-master-8261/log" # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.master` values. # config: # log-level: info # rpc-timeout: "30s" # rpc-rate-limit: 10.0 # rpc-rate-burst: 40 - host: 10.1.1.6 name: master3 ssh_port: 22 port: 8263 peer_port: 8293 deploy_dir: "/data01/dm-deploy/dm-master-8263" data_dir: "/data01/dm-data/dm-master-8263" log_dir: "/data01/dm-deploy/dm-master-8263/log" # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.master` values. # config: # log-level: info # rpc-timeout: "30s" # rpc-rate-limit: 10.0 # rpc-rate-burst: 40 - host: 10.1.1.7 name: master2 ssh_port: 22 port: 8261 peer_port: 8291 deploy_dir: "/data01/dm-deploy/dm-master-8261" data_dir: "/data01/dm-data/dm-master-8261" log_dir: "/data01/dm-deploy/dm-master-8261/log" # numa_node: "0,1" # # The following configs are used to overwrite the `server_configs.master` values. # config: # log-level: info # rpc-timeout: "30s" # rpc-rate-limit: 10.0 # rpc-rate-burst: 40 worker_servers: - host: 10.1.1.6 # ssh_port: 22 # port: 8262 deploy_dir: "/data02/dm-deploy/dm-worker-8262" log_dir: "/data02/dm-deploy/dm-worker-8262/log" # numa_node: "0,1" # # Config is used to overwrite the `server_configs.dm-worker` values # config: # log-level: info - host: 10.1.1.7 # ssh_port: 22 # port: 8262 deploy_dir: "/data02/dm-deploy/dm-worker-8262" log_dir: "/data02/dm-deploy/dm-worker-8262/log" # numa_node: "0,1" # # Config is used to overwrite the `server_configs.dm-worker` values # config: # log-level: info monitoring_servers: - host: 10.1.1.7 # ssh_port: 22 # port: 9090 # deploy_dir: "/tidb-deploy/prometheus-8249" # data_dir: "/tidb-data/prometheus-8249" # log_dir: "/tidb-deploy/prometheus-8249/log" grafana_servers: - host: 10.1.1.7 # port: 3000 # deploy_dir: /tidb-deploy/grafana-3000 alertmanager_servers: - host: 10.1.1.7 # ssh_port: 22 # web_port: 9093 # cluster_port: 9094 # deploy_dir: "/tidb-deploy/alertmanager-9093" # data_dir: "/tidb-data/alertmanager-9093" # log_dir: "/tidb-deploy/alertmanager-9093/log" # if monitored is set, node_exporter and blackbox_exporter will be # deployed with the port specified, otherwise they are not deployed # on the server to avoid conflict with tidb clusters #monitored: # node_exporter_port: 9100 # blackbox_exporter_port: 9115

第 3 步：执行部署命令

tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

首先，用 tiup list dm-master 来查看 TiUP 支持的最新版本。

$ tiup list dm-master Available versions for dm-master: Version Installed Release Platforms ------- --------- ------- --------- nightly -> v6.5.0-alpha-nightly-20221108 2022-11-08T23:51:38+08:00 linux/amd64,linux/arm64 build-debug-mode 2022-06-10T14:27:38+08:00 linux/amd64,linux/arm64 v2.0.0-rc 2020-08-21T17:49:08+08:00 linux/amd64,linux/arm64 v2.0.0-rc.2 ...... v6.1.2 2022-10-24T15:14:40+08:00 linux/amd64,linux/arm64 v6.2.0 2022-08-23T09:12:26+08:00 linux/amd64,linux/arm64 v6.3.0 2022-09-30T10:57:42+08:00 linux/amd64,linux/arm64 v6.5.0-alpha-nightly-20221108 2022-11-08T23:51:38+08:00 linux/amd64,linux/arm64

安装最新版本 DM：

tiup dm deploy dm-test v6.5.0-alpha-nightly-20221108 /home/tidb/dm/dm-test-topology.yaml --user tidb -p -i /home/tidb/.ssh/id_rsa

第 4 步：查看 TiUP 管理的集群情况

$ tiup dm list tiup is checking updates for component dm ... Starting component `dm`: /home/tidb/.tiup/components/dm/v1.11.0/tiup-dm list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- dm-test tidb v6.5.0-alpha-nightly-20221108 /home/tidb/.tiup/storage/dm/clusters/dm-test /home/tidb/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa

第 5 步：检查部署的 DM 集群情况

例如，执行如下命令检查 dm-test 集群情况：

tiup dm display dm-test

第 6 步：启动集群

$ tiup dm start dm-test ...... Started cluster `dm-test` successfully

第 7 步：验证集群运行状态

$ tiup dm display dm-test tiup is checking updates for component dm ... Starting component `dm`: /home/tidb/.tiup/components/dm/v1.11.0/tiup-dm display dm-test Cluster type: dm Cluster name: dm-test Cluster version: v6.5.0-alpha-nightly-20221108 Deploy user: tidb SSH type: builtin Grafana URL: http://10.1.1.7:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.1.1.7:9093 alertmanager 10.1.1.7 9093/9094 linux/x86_64 Up /data/dm-data/alertmanager-9093 /data/dm-deploy/alertmanager-9093 10.1.1.6:8261 dm-master 10.1.1.6 8261/8291 linux/x86_64 Healthy /data/dm-data/dm-master-8261 /data/dm-deploy/dm-master-8261 10.1.1.6:8263 dm-master 10.1.1.6 8263/8293 linux/x86_64 Healthy /data01/dm-data/dm-master-8263 /data01/dm-deploy/dm-master-8263 10.1.1.7:8261 dm-master 10.1.1.7 8261/8291 linux/x86_64 Healthy|L /data01/dm-data/dm-master-8261 /data01/dm-deploy/dm-master-8261 10.1.1.6:8262 dm-worker 10.1.1.6 8262 linux/x86_64 Free /data/dm-data/dm-worker-8262 /data02/dm-deploy/dm-worker-8262 10.1.1.7:8262 dm-worker 10.1.1.7 8262 linux/x86_64 Free /data/dm-data/dm-worker-8262 /data02/dm-deploy/dm-worker-8262 10.1.1.7:3000 grafana 10.1.1.7 3000 linux/x86_64 Up - /data/dm-deploy/grafana-3000 10.1.1.7:9090 prometheus 10.1.1.7 9090 linux/x86_64 Up /data/dm-data/prometheus-9090 /data/dm-deploy/prometheus-9090 Total nodes: 8

第 8 步：使用 dmctl 管理迁移任务

dmctl 是用来控制集群运行命令的工具，推荐通过 TiUP 获取该工具。

dmctl 支持命令模式与交互模式，具体请见使用 dmctl 运维集群。

DM 迁移 MySQL 数据库到 TiDB

第 1 步：部署 DM 集群

见上一步。

第 2 步：检查集群信息

DM 集群信息

组件 | 主机 | 端口 ---| ---|--- dm-worker1 | 10.1.1.6| 8262 dm-worker2 | 10.1.1.7| 8262 dm-master1 | 10.1.1.7| 8261 dm-master2 | 10.1.1.6| 8263 dm-master3 | 10.1.1.6| 8261

检查上下游数据库实例信息

数据库实例| 主机 | 端口 | 用户名| 加密密码 ---| ---|---|---|---|--- 上游 MySQL-1 |10.1.1.2|3327|dm_mysql |BMYKGn9OSFJAO6GnjJKkoECFKdSBIOreAuqSr1Zf 下游 TiDB |10.1.1.10|4000|dm_tidb |7kTuLQ5o8XaFtInawrSDGEDPNTKiGgD89/UnL7Y=

创建上下游所需权限用户

#上游MySQL数据库需要的权限 CREATE USER dm_mysql@10.% IDENTIFIED BY dm_mysql@!666; GRANT REPLICATION SLAVE,REPLICATION CLIENT,RELOAD,SELECT ON *.* TO dm_mysql@10.%; flush privileges; #下游tidb数据库需要的权限 CREATE USER dm_tidb@10.% IDENTIFIED BY dm_tidb@!666; GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX ON *.* TO dm_tidb@10.%; flush privileges;

上下游账号密码加解密

加密密码：

tiup dmctl -encrypt 明文

解密密码：

tiup dmctl -decrypt 密文

使用 dmctl 组件来加密, 对于同一个原始密码，每次加密后密码不同。

第 3 步: 创建数据源

将上游 MySQL-1 的相关信息写入到 conf/source1.yaml 中：

vim source1.yaml# MySQL1 Configuration. source-id: "mysql-replica-01" # DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是在上游 MySQL 已开启 GTID 模式。 enable-gtid: false from: host: "10.1.1.2" user: "dm_mysql" password: "BMYKGn9OSFJAO6GnjJKkoECFKdSBIOreAuqSr1Zf" port: 3327

使用 tiup dmctl 将 MySQL-1 的数据源配置加载到 DM 集群：

$ tiup dmctl --master-addr 10.1.1.7:8261 operate-source create /home/tidb/dm/conf/source1.yaml{ "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "dm-10.1.1.7-8262" } ] }

【Tips】

每 operate-source create source1.yaml一下，就占用一个 dm-worker,也就是会有一个dm-worker处于 Bound 状态。

除了 create source.yaml 还可以使用 update、stop、show。不过测试无法使用 update 命令，应该和 DM 在 HA 模式有关。

第 4 步：配置任务

假设需要将 MySQL-1 实例的 sbtest 库的 sbtest1 表以全量+增量的模式迁移到下游 TiDB 的 test_db 库的 test_table 表。

编辑任务配置文件 task1-sbtest.yaml：

vim task1-sbtest.yaml# 任务名，多个同时运行的任务不能重名。 name: "sbtest" # 全量+增量 (all) 迁移模式。 task-mode: "all" # 下游 TiDB 配置信息。 target-database: host: "10.1.1.10" port: 4000 user: "dm_tidb" password: "7kTuLQ5o8XaFtInawrSDGEDPNTKiGgD89/UnL7Y=" # 推荐使用经 dmctl encrypt 加密后的密码 # 当前数据迁移任务需要的全部上游 MySQL 实例配置。 mysql-instances: - # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。 source-id: "mysql-replica-01" # 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置。 block-allow-list: "listA" # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。 block-allow-list: # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。 listA: do-tables: # 需要迁移的上游表的白名单。 - db-name: "sbtest" # 需要迁移的表的库名。 tbl-name: "sbtest1" # 需要迁移的表的名称。

第 5 步：启动任务

前置检查

为了提前发现数据迁移任务的一些配置错误，DM 中增加了前置检查功能：

启动数据迁移任务时，DM 自动检查相应的权限和配置。

也可使用 check-task 命令手动前置检查上游的 MySQL 实例配置是否符合 DM 的配置要求。

配置好后，可以先使用check-task检查下配置项：

tiup dmctl --master-addr 10.1.1.7:8261 check-task task1-sbtest.yaml

返回pre-check is passed.说明检查通过。

启动任务

使用 tiup dmctl 执行以下命令启动数据迁移任务。其中，task1-sbtest.yaml 是之前编辑的配置文件。

tiup dmctl --master-addr 10.1.1.7:8261 start-task /home/tidb/dm/conf/task1-sbtest.yaml

如果执行该命令后返回的结果如下，则表明任务已成功启动。

{ "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "dm-10.1.1.7-8262" } ], "checkResult": "pre-check is passed. " }

如果任务启动失败，可根据返回结果的提示进行配置变更后执行 start-task task.yaml 命令重新启动任务。

第 6 步：查询任务

tiup dmctl --master-addr 10.1.1.7:8261 query-status{ "result": true, "msg": "", "tasks": [ { "taskName": "sbtest", "taskStatus": "Running", "sources": [ "mysql-replica-01" ] } ] }

第 7 步：查看任务状态

tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}$ tiup dmctl --master-addr 10.1.1.7:8261 query-status sbtest tiup is checking updates for component dmctl ... Starting component `dmctl`: /home/tidb/.tiup/components/dmctl/v6.3.0/dmctl/dmctl --master-addr 10.1.1.7:8261 query-status sbtest { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-01", "worker": "dm-10.1.1.7-8262", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "sbtest", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "totalEvents": "19", "totalTps": "0", "recentTps": "0", "masterBinlog": "(mysql-bin.000204, 635)", "masterBinlogGtid": "", "syncerBinlog": "(mysql-bin.000204, 635)", "syncerBinlogGtid": "", "blockingDDLs": [ ], "unresolvedGroups": [ ], "synced": true, "binlogType": "remote", "secondsBehindMaster": "0", "blockDDLOwner": "", "conflictMsg": "" }, "validation": null } ] } ] }

第 8 步：查看 DM 集群及监控

查看 DM 集群状态：

$ tiup dm display dm-test tiup is checking updates for component dm ... Starting component `dm`: /home/tidb/.tiup/components/dm/v1.11.0/tiup-dm display dm-test Cluster type: dm Cluster name: dm-test Cluster version: v6.5.0-alpha-nightly-20221108 Deploy user: tidb SSH type: builtin Grafana URL: http://10.1.1.7:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.1.1.7:9093 alertmanager 10.1.1.7 9093/9094 linux/x86_64 Up /data/dm-data/alertmanager-9093 /data/dm-deploy/alertmanager-9093 10.1.1.6:8261 dm-master 10.1.1.6 8261/8291 linux/x86_64 Healthy /data/dm-data/dm-master-8261 /data/dm-deploy/dm-master-8261 10.1.1.6:8263 dm-master 10.1.1.6 8263/8293 linux/x86_64 Healthy /data01/dm-data/dm-master-8263 /data01/dm-deploy/dm-master-8263 10.1.1.7:8261 dm-master 10.1.1.7 8261/8291 linux/x86_64 Healthy|L /data01/dm-data/dm-master-8261 /data01/dm-deploy/dm-master-8261 10.1.1.6:8262 dm-worker 10.1.1.6 8262 linux/x86_64 Free /data/dm-data/dm-worker-8262 /data02/dm-deploy/dm-worker-8262 10.1.1.7:8262 dm-worker 10.1.1.7 8262 linux/x86_64 Bound /data/dm-data/dm-worker-8262 /data02/dm-deploy/dm-worker-8262 10.1.1.7:3000 grafana 10.1.1.7 3000 linux/x86_64 Up - /data/dm-deploy/grafana-3000 10.1.1.7:9090 prometheus 10.1.1.7 9090 linux/x86_64 Up /data/dm-data/prometheus-9090 /data/dm-deploy/prometheus-9090 Total nodes: 8

可以看到一个 dm-worker 显示被占用，处于 Bound 状态；

还有一个dm-worker 处于空闲的 Free 状态;

可在浏览器中打开 http://10.1.1.7:9093 进入 Alertmanager 查看 DM 告警信息；

可在浏览器中打开 http://10.1.1.7:3000 进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。

DM 迁移 MySQL 分库分表到下游 TiDB

迁移目标

上游 MySQL：

SchemaTablessharding001user_push01sharding002user_push01

迁移目标库的结构如下：

SchemaTablessharding_mergeuser_push

迁移目标：

将sharding[001-002] 的 user_push01 表合并才下游 tidb 的 sharding_merge 库 user_push 表。

分表数据冲突检查

第 1 步： 创建数据源

新建 source2.yaml 文件：

vim source2.yaml# 唯一命名，不可重复。 source-id: "mysql-sharding-01" # DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是上游 MySQL 已开启 GTID 模式。若上游存在主从自动切换，则必须使用 GTID 模式。 #enable-gtid: true from: host: "10.1.1.2" # 例如：172.16.10.81 user: "dm_mysql" password: "BMYKGn9OSFJAO6GnjJKkoECFKdSBIOreAuqSr1Zf" # 支持但不推荐使用明文密码，建议使用 dmctl encrypt 对明文密码进行加密后使用 port: 3327

创建数据源：

tiup dmctl --master-addr 10.1.1.7:8261 operate-source create source2.yaml

第 2 步：创建迁移任务

新建task2-shard-merge.yaml文件, 写入以下内容：

name: "shard_merge" # 任务模式，可设为 # full：只进行全量数据迁移 # incremental： binlog 实时同步 # all： 全量 + binlog 迁移 task-mode: all # 分库分表合并任务则需要配置 shard-mode。默认使用悲观协调模式 "pessimistic"，在深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic" # 详细信息可参考：https://docs.pingcap.com/zh/tidb/dev/feature-shard-merge/ shard-mode: "pessimistic" meta-schema: "dm_meta" # 将在下游数据库创建 schema 用于存放元数据 #ignore-checking-items: ["schema_of_shard_tables"] #任务过程中存在表一致性的报错，加上即可忽略 ignore-checking-items: ["auto_increment_ID"] # 本示例中上游存在自增主键，因此需要忽略掉该检查项 target-database: host: "10.1.1.10" # 例如：192.168.0.1 port: 4000 user: "dm_tidb" password: "7kTuLQ5o8XaFtInawrSDGEDPNTKiGgD89/UnL7Y=" # 支持但不推荐使用明文密码，建议使用 dmctl encrypt 对明文密码进行加密后使用 mysql-instances: - source-id: "mysql-sharding-01" # 数据源 ID，即 source2.yaml 中的 source-id route-rules: ["route-rule"] # 应用于该数据源的 table route 规则 filter-rules: ["store-filter-rule","sale-filter-rule"] # 应用于该数据源的 binlog event filter 规则 block-allow-list: "log-bak-ignored" # 应用于该数据源的 Block & Allow Lists 规则 mydumper-config-name: "global" # mydumpers 配置的名称 loader-config-name: "global" # loaders 配置的名称 syncer-config-name: "global" # syncers 配置的名称 # 分表合并配置 routes: route-rule: schema-pattern: "sharding*" table-pattern: "user_push*" target-schema: "sharding_merge" target-table: "user_push" # 过滤部分 DDL 事件 filters: sale-filter-rule: schema-pattern: "sharding*" table-pattern: "user_push*" events: ["truncate table", "drop table", "delete"] action: Ignore store-filter-rule: schema-pattern: "sharding*" events: ["drop database"] action: Ignore # 黑白名单 block-allow-list: log-bak-ignored: do-dbs: ["~^sharding*"] # 非 ~ 字符开头，表示规则是通配符；v1.0.5 及后续版本支持通配符规则。 do-tables: - db-name: "~^sharding*" # 匹配 sharding001,sharding002。 tbl-name: "~^user_push*" # 匹配 user_push01。 mydumpers: # dump 处理单元的运行配置参数 global: # 配置名称 threads: 4 # dump 处理单元从上游数据库实例导出数据的线程数量，默认值为 4 chunk-filesize: 64 # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB # extra-args: "--consistency none" # dump 处理单元的其他参数，不需要在 extra-args 中配置 table-list，DM 会自动生成 loaders: # load 处理单元的运行配置参数 global: # 配置名称 pool-size: 4 # load 处理单元并发执行 dump 处理单元的 SQL 文件的线程数量，默认值为 16，当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值 # dir: "./dumped_data" # dump 处理单元输出 SQL 文件的目录，同时也是 load 处理单元读取文件的目录。该配置项的默认值为 "./dumped_data"。同实例对应的不同任务必须配置不同的目录 syncers: # sync 处理单元的运行配置参数 global: # 配置名称 worker-count: 4 # 应用已传输到本地的 binlog 的并发线程数量，默认值为 16。调整此参数不会影响上游拉取日志的并发，但会对下游产生显著压力。 batch: 100 # sync 迁移到下游数据库的一个事务批次 SQL 语句数，默认值为 100，建议一般不超过 500。 enable-ansi-quotes: true # 若 `session` 中设置 `sql-mode: "ANSI_QUOTES"`，则需开启此项

第 3 步： 启动任务

在你启动数据迁移任务之前，建议使用check-task命令检查配置是否符合 DM 的配置要求，以降低后期报错的概率。

前置检查：

tiup dmctl --master-addr ${advertise-addr} check-task task2.yaml

启动任务：

$ tiup dmctl --master-addr 10.1.1.7:8261 start-task task2.yaml tiup is checking updates for component dmctl ... A new version of dmctl is available: The latest version: v6.4.0 Local installed version: v6.3.0 Update current component: tiup update dmctl Update all components: tiup update --all Starting component `dmctl`: /home/tidb/.tiup/components/dmctl/v6.3.0/dmctl/dmctl --master-addr 10.1.1.7:8261 start-task task2.yaml { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "user-sharding", "worker": "dm-10.1.1.7-8262" } ], "checkResult": "fail to check synchronization configuration with type: no errors but some warnings detail: { "results": [ { "id": 12, "name": "sharding table `sharding_merge`.`user_push` consistency checking", "desc": "check consistency of sharding table structures", "state": "warn", "errors": [ { "severity": "fail", "short_error": "sourceID user-sharding table {sharding001 user_push01} of sharding `sharding_merge`.`user_push` have auto-increment key, please make sure them dont conflict in target table!" }, { "severity": "fail", "short_error": "sourceID user-sharding table {sharding002 user_push01} of sharding `sharding_merge`.`user_push` have auto-increment key, please make sure them dont conflict in target table!" } ], "instruction": "If happen conflict, please handle it by yourself. You can refer to https://docs.pingcap.com/tidb-data-migration/stable/shard-merge-best-practices/#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables", "extra": "auto-increment key checking" } ], "summary": { "passed": true, "total": 1