DM 实践手册

原创

TiDB社区干货传送门 2023-01-08 00:39:15 ©著作权

文章标签 linux DM mysql 文章分类 Spark 大数据

©著作权归作者所有：来自51CTO博客作者TiDB社区干货传送门的原创作品，请联系作者获取转载授权，否则将追究法律责任

作者： Hacker_小峰

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：

Schema	Tables
sharding001	user_push01
sharding002	user_push01

迁移目标库的结构如下：

Schema	Tables
sharding_merge	user_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 don't 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 don't 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": 13,
         "successful": 12,
         "failed": 0,
         "warning": 1
      }
   }"
}

第 4 步：查看任务状态

查看任务:

tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}

$ tiup dmctl --master-addr 10.1.1.7:8261 query-status shard_merge
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 query-status shard_merge
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "sourceStatus": {
                "source": "mysql-sharding-01",
                "worker": "dm-10.1.1.6-8262",
                "result": null,
                "relayStatus": null
            },
            "subTaskStatus": [
                {
                    "name": "shard_merge",
                    "stage": "Running",
                    "unit": "Load",
                    "result": null,
                    "unresolvedDDLLockID": "",
                    "load": {
                        "finishedBytes": "5826081601",
                        "totalBytes": "27887789287",
                        "progress": "20.89 %",
                        "metaBinlog": "(mysql-bin.000233, 207018196)",
                        "metaBinlogGTID": ""
                    },
                    "validation": null
                }
            ]
        }
    ]
}

第 5 步：校验上下游数据

下载工具

wget https://download.pingcap.org/tidb-enterprise-tools-nightly-linux-amd64.tar.gz

tar zxvf tidb-enterprise-tools-nightly-linux-amd64.tar.gz

编写 sync-diff-inspector 配置文件：

# Diff Configuration.

######################### Global config #########################

# 检查数据的线程数量，上下游数据库的连接数会略大于该值
check-thread-count = 4

# 如果开启，若表存在不一致，则输出用于修复的 SQL 语句
export-fix-sql = true

# 只对比表结构而不对比数据
check-struct-only = false

# dm-master 的地址, 格式为 "http://127.0.0.1:8261"
dm-addr = "http://10.1.1.7:8261"

# 指定 DM 的 `task-name`
dm-task = "shard_merge"
######################### Datasource config #########################
[data-sources]
[data-sources.mysql1] # mysql1 是该数据库实例唯一标识的自定义 id，用于下面 task.source-instances/task.target-instance 中
    host = "10.1.1.2"
    port = 3327
    user = "dm_mysql"
    password = "BMYKGn9OSFJAO6GnjJKkoECFKdSBIOreAuqSr1Zf"



[data-sources.tidb0]
    host = "10.1.1.10"
    port = 4000
    user = "dm_tidb"
    password = "7kTuLQ5o8XaFtInawrSDGEDPNTKiGgD89/UnL7Y="
    #（可选）使用 TiDB 的 snapshot 功能，如果开启的话会使用历史数据进行对比
    # snapshot = "386902609362944000"
######################### Task config #########################
[task]
    output-dir = "/home/tidb/sync_diff_inspector/output"

    # 需要比对的下游数据库的表，每个表需要包含数据库名和表名，两者由 `.` 隔开
    target-check-tables = ["sharding_merge.*"]

运行 sync-diff-inspector，执行如下命令：

./sync_diff_inspector --config=./config.toml

$ /home/tidb/tidb-enterprise-tools-nightly-linux-amd64/bin/sync_diff_inspector --config=/home/tidb/sync_diff_inspector/config.toml
A total of 2 tables need to be compared

Comparing the table structure of ``sharding_merge`.`user_push`` ... failure
Comparing the table structure of ``sharding_merge`.`comments`` ... failure
Comparing the table data of ``sharding_merge`.`user_push`` ...
Comparing the table data of ``sharding_merge`.`comments`` ...
_____________________________________________________________________________
Progress [>------------------------------------------------------------] 0% 0/1062
......

遇到问题

告警auto-increment key checking

有告警auto-increment key checking,但是DM 任务已经running起来了。

需要忽略上游存在自增主键，操作如下：

暂停任务：

tiup dmctl --master-addr 10.1.1.7:8261 pause-task task2-shard-merge.yaml

修改任务配置文件 task2-shard-merge.yaml ,新增：

ignore-checking-items: ["auto_increment_ID"]

恢复任务：

$ tiup dmctl --master-addr 10.1.1.7:8261 resume-task task2-shard-merge.yaml

查看任务：

$ tiup dmctl --master-addr 10.1.1.7:8261 query-status shard_merge
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 query-status shard_merge
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "sourceStatus": {
                "source": "mysql-sharding-01",
                "worker": "dm-10.1.1.6-8262",
                "result": null,
                "relayStatus": null
            },
            "subTaskStatus": [
                {
                    "name": "shard_merge",
                    "stage": "Running",
                    "unit": "Load",
                    "result": null,
                    "unresolvedDDLLockID": "",
                    "load": {
                        "finishedBytes": "748136267",
                        "totalBytes": "21404994407",
                        "progress": "3.50 %",
                        "metaBinlog": "(mysql-bin.000233, 207017999)",
                        "metaBinlogGTID": ""
                    },
                    "validation": null
                }
            ]
        }
    ]
}

配置任务过滤条件有误，如何重新配置任务

停止任务：

tiup dmctl --master-addr 10.1.1.7:8261 stop-task shard_merge

此时，观察到 dm-worker 还是 Bound 占用状态：

$ 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  Bound      /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-woker 和数据源关系：

$ tiup dmctl --master-addr 10.1.1.7:8261 operate-source show
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 operate-source show
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "mysql-replica-01",
            "worker": "dm-10.1.1.7-8262"
        },
        {
            "result": true,
            "msg": "",
            "source": "mysql-sharding-01",
            "worker": "dm-10.1.1.6-8262"
        }
    ]
}

移除不需要的source：

tiup dmctl --master-addr 10.1.1.7:8261 operate-source stop mysql-sharding-01

查看到dm-worker 已释放：

$ tiup dm display dm-test

重新编辑任务配置文件 task2.yaml

vim task2-shard-merge.yaml

重新创建数据源

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

重建创建迁移任务

tiup dmctl --master-addr 10.1.1.7:8261 start-task task2-shard-merge.yaml

迁移过程中发现tikv IO高

新扩容tikv节点后IO变化不大，最后调整task2.yaml 中的loader、syncer 的 threads ，从16调整到4后，IO有明显下降。

停止任务：

tiup dmctl --master-addr 10.1.1.7:8261 stop-task shard_merge

修改配置文件中的loader、syncer 的 threads：

vim task2-shard-merge.yaml

......
    mydumper-config-name: "global"          # mydumpers 配置的名称
    loader-config-name: "global"            # loaders 配置的名称
    syncer-config-name: "global"            # syncers 配置的名称

......
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"`，则需开启此项

重新开启任务：

tiup dmctl --master-addr 10.1.1.7:8261 start-task task2-shard-merge.yaml

DM WebUI 迁移任务管理界面

1、怎样使用 DM WebUI

在 DM 集群配置文件中添加

server_configs:
  master:
    openapi: true

2、访问 DM WebUI

在开启 OpenAPI 后，你可以从 DM 集群的任意 master 节点访问 DM WebUI，访问端口与 DM OpenAPI 保持一致，默认为 8261。访问地址示例：http://{master_ip}:{master_port}/dashboard/。

3、添加上游配置

DM 实践手册_mysql

4、添加迁移任务

DM 实践手册_linux_02

DM WebUI ，界面简单，使用起来易用性强。不喜欢或不习惯 dmctl 的小伙伴们可以试用起来。

警告
DM WebUI 当前为实验特性，不建议在生产环境中使用。
DM WebUI 中 task 的生命周期有所改变，不建议与 dmctl 同时使用。

DM 常见问题处理

1、下游 tidb 节点变更导致 DM 中断

首先，DM 任务状态正常

$ tiup dmctl --master-addr 10.1.1.7:8261  query-status
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
{
    "result": true,
    "msg": "",
    "tasks": [
        {
            "taskName": "sbtest",
            "taskStatus": "Running",
            "sources": [
                "mysql-replica-01"
            ]
        }
    ]
}

下线下游 DM 迁移使用的 tidb 节点，让迁移任务中断：

tiup cluster scale-in tidb-test --node 10.1.1.10:4000

查看 DM 任务状态，任务中断:

$ tiup dmctl --master-addr 10.1.1.7:8261  query-status
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
{
    "result": true,
    "msg": "",
    "tasks": [
        {
            "taskName": "sbtest",
            "taskStatus": "Error - Some error occurred in subtask. Please run `query-status sbtest` to get more details.",
            "sources": [
                "mysql-replica-01"
            ]
        }
    ]
}

查看详细报错：

tiup dmctl --master-addr 10.1.1.7:8261  query-status sbtest

#截取的部分信息
"subTaskStatus": [
                {
                    "name": "sbtest",
                    "stage": "Paused",
                    "unit": "Sync",
                    "result": {
                        "isCanceled": false,
                        "errors": [
                            {
                                "ErrCode": 10001,
                                "ErrClass": "database",
                                "ErrScope": "downstream",
                                "ErrLevel": "high",
                                "Message": "database driver error",
                                "RawCause": "dial tcp 10.1.1.10:4000: connect: connection refused",
                                "Workaround": "Please check the database connection and the database config in configuration file."
                            }
                        ],
                        "detail": null
                    }

PS :如果上游到下游没有增量需要更新，这样缩容tidb节点，DM是不会报错的，因为上下游的数据还是一致的。只有当缩tidb后，上游到下游有增量同步时，找不到下游tidb server 节点，DM才会报错。

解决

1、暂停任务：

tiup dmctl --master-addr 10.1.1.7:8261 pause-task sbtest

2、停止任务：

tiup dmctl --master-addr 10.1.1.7:8261 stop-task sbtest

3、更新任务配置文件 task1-sbtest.yaml ：

vim task1-sbtest.yaml

# 将下游 TiDB 配置信息 从原来10.1.1.10（该节点已缩容） 更新为可用的 10.1.96.171
target-database:
  host: "10.1.96.171"
  port: 4000

4、重新启动任务：

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

5、查看任务状态，已正常

$ 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": "2",
                        "totalTps": "2",
                        "recentTps": "2",
                        "masterBinlog": "(mysql-bin.000204, 905)",
                        "masterBinlogGtid": "",
                        "syncerBinlog": "(mysql-bin.000204, 635)",
                        "syncerBinlogGtid": "",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": false,
                        "binlogType": "remote",
                        "secondsBehindMaster": "0",
                        "blockDDLOwner": "",
                        "conflictMsg": ""
                    },
                    "validation": null
                }
            ]
        }
    ]
}

2、上游 MySQL 意外宕机导致 DM 中断

详见官网切换 DM-worker 与上游 MySQL 实例的连接。

3、停止任务后 dm-worker 未释放（仍处于 Bound 占用状态）

查看 dm-woker 和数据源关系：

$ tiup dmctl --master-addr ${advertise-addr}  operate-source show

移除不需要的 source：

tiup dmctl ---master-addr ${advertise-addr}  operate-source stop ${task-name}

查看到 dm-worker 已释放(状态从 Bound 更新为 Free)：

tiup dm display dm-test

4、DDL 导致 DM 中断处理

使用限制
如果业务不能接受下游 TiDB 跳过异常的 DDL 语句，也不接受使用其他 DDL 语句作为替代，不接受插入其他 DDL 语句，则不适合使用此方式进行处理。
比如：DROP PRIMARY KEY，这种情况下，只能在下游重建一个（DDL 执行完后的）新表结构对应的表，并将原表的全部数据重新导入该新表。

处理出错的 DDL 命令总结

使用 dmctl 手动处理出错的 DDL 语句时，主要使用的命令包括 query-status、binlog （之前版本可使用 handle-error 命令）。

query-status

用于查询当前 MySQL 实例内子任务及 relay 单元等的状态和错误信息

tiup dmctl --master-addr  <master-addr>  query-status <task-name>

binlog skip

跳过任务报错：

tiup dmctl --master-addr  <master-addr>  binlog  skip <task-name>

binlog replace

执行其他 DDL 语句来作为替代：

tiup dmctl --master-addr  <master-addr>  binlog replace  <task-name> "<DDL SQL>"

handle-error

跳过任务报错：

tiup dmctl --master-addr  <master-addr>  handle-error <task-name> skip

执行其他 DDL 语句来作为替代：

tiup dmctl --master-addr  <master-addr>  handle-error   <task-name> replace "<DDL SQL>"

binlog 命令管理和查看binlog操作。该命令仅在 DM v6.0 及其以后版本支持, 之前版本可使用 handle-error 命令。

案例1：迁移中断执行 handle-error 跳过报错

#建表语句
CREATE TABLE `sbtest1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000002 DEFAULT CHARSET=utf8

在上游 MySQL 执行一条alter table 包含多个 DDL 操作：

alter table sbtest1 
add w int(11) not null default '0',
add addr varchar(50) not null default '',
add index idx_addr(addr);

观察到 DM 同步任务正常，下游 TiDB 能正常同步以上 DDL 操作。

在上游 MySQL 执行 TiDB 不兼容的DDL：

mysql> alter table sbtest1 modify column id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT'自增主键';

去掉 UNSIGNED 后则是 TiDB 是可以兼容的语法。在生产环境中遇到的这个栗子，一开始以为DDL只是主键从int扩展到bigint,应该是兼容的呀。最后看了好久才发现还加了UNSIGNED 。

查看 DM 任务状态：

$ tiup dmctl --master-addr 10.1.1.7:8261  query-status
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
{
    "result": true,
    "msg": "",
    "tasks": [
        {
            "taskName": "sbtest",
            "taskStatus": "Error - Some error occurred in subtask. Please run `query-status sbtest` to get more details.",
            "sources": [
                "mysql-replica-01"
            ]
        }
    ]
}

$ 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": "Paused",
                    "unit": "Sync",
                    "result": {
                        "isCanceled": false,
                        "errors": [
                            {
                                "ErrCode": 44006,
                                "ErrClass": "schema-tracker",
                                "ErrScope": "internal",
                                "ErrLevel": "high",
                                "Message": "startLocation: [position: (mysql-bin.000204, 1224), gtid-set: 00000000-0000-0000-0000-000000000000:0], endLocation: [position: (mysql-bin.000204, 1400), gtid-set: 00000000-0000-0000-0000-000000000000:0], origin SQL: [alter table sbtest1 modify column id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT'自增主键']: cannot track DDL: ALTER TABLE `sbtest`.`sbtest1` MODIFY COLUMN `id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键'",
                                "RawCause": "[ddl:8200]Unsupported modify column: this column has primary key flag",
                                "Workaround": "You can use handle-error to replace or skip this DDL."
                            }
                        ],
                        "detail": null
                    },
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "4700",
                        "totalTps": "0",
                        "recentTps": "0",
                        "masterBinlog": "(mysql-bin.000204, 1400)",
                        "masterBinlogGtid": "",
                        "syncerBinlog": "(mysql-bin.000204, 1163)",
                        "syncerBinlogGtid": "00000000-0000-0000-0000-000000000000:0",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": false,
                        "binlogType": "remote",
                        "secondsBehindMaster": "0",
                        "blockDDLOwner": "",
                        "conflictMsg": ""
                    },
                    "validation": null
                }
            ]
        }
    ]
}

任务中断，报错Unsupported modify column: this column has primary key flag。

确认了报错的原因，和业务能接受上下游结构不一致。

使用 handle-error <task-name> skip 或 binlog skip <task-name> 跳过任务报错,以尽快恢复任务同步.

跳过报错：

tiup dmctl --master-addr 10.1.1.7:8261  handle-error sbtest skip

$ 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": "4701",
                        "totalTps": "0",
                        "recentTps": "0",
                        "masterBinlog": "(mysql-bin.000204, 1400)",
                        "masterBinlogGtid": "",
                        "syncerBinlog": "(mysql-bin.000204, 1400)",
                        "syncerBinlogGtid": "00000000-0000-0000-0000-000000000000:0",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": true,
                        "binlogType": "remote",
                        "secondsBehindMaster": "0",
                        "blockDDLOwner": "",
                        "conflictMsg": ""
                    },
                    "validation": null
                }
            ]
        }
    ]
}

观察syncerBinlog有没有追上masterBinlog，直到追上。

跳过报错后，尽力修复上下游表结构一致

查询了官网：“不支持修改主键列上需要 Reorg-Data 的类型，但是支持修改 Meta-Only 的类型”。也就是说，仅扩展整型从int到bigint,TiDB是支持的。

再次仔细对比上游MySQL和下游TIDB的表结构，发现除id不止从int类型扩展为bigint,还添加 UNSIGNED 。测试了下，去掉 UNSIGNED 后， DDL 操作就可以在tidb操作成功了。

询问业务不需要存储负数，所以其实压根儿用不上UNSIGNED，可以去掉 UNSIGNED。于是在上游MySQL执行如下DDL，统一上下游表结构

mysql> ALTER TABLE sbtest1 MODIFY COLUMN `id` BIGINT(20)  NOT NULL AUTO_INCREMENT COMMENT '自增主键';

案例2：迁移中断执行 replace 替代操作

上游 MySQL 执行 TiDB 不兼容的DDL：

alter table sbtest1 add new_col int unique;

mysql> show create table sbtest1;
+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table   | Create Table                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| sbtest1 | CREATE TABLE `sbtest1` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  `w` int(11) NOT NULL DEFAULT '0',
  `addr` varchar(50) NOT NULL DEFAULT '',
  `new_col` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `new_col` (`new_col`),
  KEY `k_1` (`k`),
  KEY `idx_addr` (`addr`)
) ENGINE=InnoDB AUTO_INCREMENT=1000002 DEFAULT CHARSET=utf8     |
+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

查看 DM 任务状态：

tiup dmctl --master-addr 10.1.1.7:8261  query-status sbtest

"errors": [
                            {
                                "ErrCode": 10006,
                                "ErrClass": "database",
                                "ErrScope": "downstream",
                                "ErrLevel": "high",
                                "Message": "startLocation: [position: (mysql-bin.000204, 1461), gtid-set: 00000000-0000-0000-0000-000000000000:0], endLocation: [position: (mysql-bin.000204, 1577), gtid-set: 00000000-0000-0000-0000-000000000000:0], origin SQL: [alter table sbtest1 add new_col int unique]: execute statement failed: ALTER TABLE `sbtest`.`sbtest1` ADD COLUMN `new_col` INT UNIQUE KEY",
                                "RawCause": "Error 8200: unsupported add column 'new_col' constraint UNIQUE KEY when altering 'sbtest.sbtest1'",
                                "Workaround": ""
                            }

DM 任务中断并报错，因为不支持该语法。

执行 handle-error replace <taskname> 或 binlog replace <taskname>替代操作，将该 DDL 替换成两条等价的 DDL。操作步骤如下：

tiup dmctl --master-addr 10.1.1.7:8261  binlog replace  sbtest "ALTER TABLE sbtest.sbtest1 ADD COLUMN new_col INT;ALTER TABLE sbtest.sbtest1 ADD UNIQUE(new_col)";

或

tiup dmctl --master-addr 10.1.1.7:8261  handle-error sbtest  replace "ALTER TABLE sbtest.sbtest1 ADD COLUMN new_col2 INT;ALTER TABLE sbtest.sbtest1 ADD UNIQUE(new_col2)";

使用 query-status <task-name> 查看任务状态

tiup dmctl --master-addr 10.1.1.7:8261  query-status sbtest

{
                    "name": "sbtest",
                    "stage": "Running",
                    "unit": "Sync",
                    "result": null,
                    "unresolvedDDLLockID": "",
                    "sync": {
                        "totalEvents": "6107",
                        "totalTps": "86",
                        "recentTps": "0",
                        "masterBinlog": "(mysql-bin.000204, 1577)",
                        "masterBinlogGtid": "",
                        "syncerBinlog": "(mysql-bin.000204, 1577)",
                        "syncerBinlogGtid": "00000000-0000-0000-0000-000000000000:0",
                        "blockingDDLs": [
                        ],
                        "unresolvedGroups": [
                        ],
                        "synced": true,
                        "binlogType": "remote",
                        "secondsBehindMaster": "0",
                        "blockDDLOwner": "",
                        "conflictMsg": ""
                    },

可以看到任务运行正常，错误的 DDL 已被替换且执行成功。

5、使用 gh-ost/pt-osc 工具变更上游对下游影响

上游 MySQL 通过 gh-ost 新增字段：

gh-ost --host=xx.xx.xx.xx --port=33xx --user='username' --password='xxxx' --allow-on-master --allow-master-master --database=sbtest --table=sbtest1  \
--alter="add  create_time datetime not null COMMENT '开始时间'"   --chunk-size=5000 --max-load=Threads_connected=2000,Threads_running=80  --ok-to-drop-table=True \
--approve-renamed-columns --max-lag-millis=5000 --switch-to-rbr --nice-ratio=1     --verbose -execute

上游 MySQL 通过 pt-osc 新增字段及修改字段：

pt-online-schema-change -h 10.xx.xx.xx -P33xx -D sbtest -u username -p passwd t=sbtest1 --alter="add  update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录更新时间',modify create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '记录创建时间'" \
--recursion-method=processlist --check-interval=2 --max-lag=2 --max-load="Threads_running=20"  --critical-load="Threads_running=80" --charset=utf8   --print  --execute

查看 DM 任务状态:

$ tiup dmctl --master-addr 10.1.1.7:8261  query-status
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 query-status
{
    "result": true,
    "msg": "",
    "tasks": [
        {
            "taskName": "sbtest",
            "taskStatus": "Running",
            "sources": [
                "mysql-replica-01"
            ]
        }
    ]
}

看到任务状态正常。

实践小结

我用的 DM 版本是 v6.5.0，实践显示，在上游使用 gh-ost/pt-osc 工具，对下游无影响。虽然任务配置文件 task1.yaml 中没有显式写明 online-ddl: true ,但看起来这个参数在这版本中默认为 TRUE 啦。所以，DM 自动支持上游使用 pt-osc/gh-ost 在线 schema 变更工具，无需特别的配置。另，部署 DM 建议最好用近期比较新的版本。

【查看 tiup 支持的 DM 最新版本】：

tiup list dm-master

6、DM 告警

DM 监控指标

使用 TiUP 部署 DM 集群的时候，会默认部署一套监控系统。可在浏览器中打开 http://10.1.1.7:9093 进入 Alertmanager 查看 DM 告警信息；可在浏览器中打开 http://10.1.1.7:3000 进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。

DM 告警处理

DM 的告警规则及其对应的处理方法可参考告警处理。

详情请参考官网 DM 告警信息。

DM 任务状态转换

暂停任务：

tiup dmctl --master-addr 172.16.10.71:8261 pause-task wr-dm-task1

恢复任务：

tiup dmctl --master-addr 172.16.10.71:8261 resume-task wr-dm-task1

停止任务：

tiup dmctl --master-addr 172.16.10.71:8261 stop-task wr-dm-task1

pause-task 与 stop-task 的区别

【Tips】
有关 pause-task 与 stop-task 的区别如下：
使用 pause-task 仅暂停迁移任务的执行，但仍然会在内存中保留任务的状态信息等，且可通过 query-status 进行查询；
使用 stop-task 会停止迁移任务的执行，并移除内存中与该任务相关的信息，且不可再通过 query-status 进行查询，但不会移除已经写入到下游数据库中的数据以及其中的 checkpoint 等 dm_meta 信息。
使用 pause-task 暂停迁移任务期间，由于任务本身仍然存在，因此不能再启动同名的新任务，且会阻止对该任务所需 relay log 的清理；
使用 stop-task 停止任务后，由于任务不再存在，因此可以再启动同名的新任务，且不会阻止对 relay log 的清理。
pause-task 一般用于临时暂停迁移任务以排查问题等；
stop-task 一般用于永久删除迁移任务或通过与 start-task 配合以更新配置信息。

状态转换图

error occurs
                            New --------------------------------|
                             |                                  |
                             |           resume-task            |
                             |  |----------------------------|  |
                             |  |                            |  |
                             |  |                            |  |
                             v  v        error occurs        |  v
  Finished <-------------- Running -----------------------> Paused
                             ^  |        or pause-task       |
                             |  |                            |
                  start task |  | stop task                  |
                             |  |                            |
                             |  v        stop task           |
                           Stopped <-------------------------|

详见官网 DM 任务状态。

参考文档

DM 常见故障及处理方法

处理出错的 DDL 语句

DM 任务完整配置文件介绍

DM 告警信息

使用 TiUP 部署 TiDB 集群

上一篇：百TB级TiDB集群在线更换NVME磁盘优化实践

下一篇：依据TIdb执行计划的sql调优案例分享

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯

DM 实践手册

DM 实践手册

DM 部署

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

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

第 3 步：执行部署命令

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

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

第 6 步：启动集群

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

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

DM 迁移 MySQL 数据库到 TiDB

第 1 步：部署 DM 集群

第 2 步：检查集群信息

第 3 步: 创建数据源

第 4 步：配置任务

第 5 步：启动任务

第 6 步：查询任务

第 7 步：查看任务状态

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

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

迁移目标

分表数据冲突检查

第 1 步： 创建数据源

第 2 步：创建迁移任务

第 3 步： 启动任务

第 4 步： 查看任务状态

第 5 步： 校验上下游数据

遇到问题

告警auto-increment key checking

配置任务过滤条件有误，如何重新配置任务

迁移过程中发现tikv IO高

DM WebUI 迁移任务管理界面

DM 常见问题处理

1、下游 tidb 节点变更导致 DM 中断

解决

2、上游 MySQL 意外宕机导致 DM 中断

3、停止任务后 dm-worker 未释放（仍处于 Bound 占用状态）

4、DDL 导致 DM 中断处理

使用限制

处理出错的 DDL 命令总结

query-status

binlog skip

binlog replace

handle-error

案例1：迁移中断执行 handle-error 跳过报错

案例2：迁移中断执行 replace 替代操作

5、使用 gh-ost/pt-osc 工具变更上游对下游影响

实践小结

6、DM 告警

DM 监控指标

DM 告警处理

DM 任务状态转换

pause-task 与 stop-task 的区别

状态转换图

参考文档

51CTO博客

第 1 步：创建数据源

第 3 步：启动任务

第 4 步：查看任务状态

第 5 步：校验上下游数据