一、dmctl相关
tiup dmctl --helpUsage: dmctl [global options] command [command options] [arguments...]
Available Commands:
check-task check-task <config-file> # 检查任务的配置文件
get-config get-config <task | master | worker | source> <name> [--file filename] # 获取配置
config 导入/导出配置的命令
decrypt 将密文解密为纯文本
encrypt 将明文加密为密文。
transfer-source 为source指定worker
handle-error handle-error <task-name | task-file> [-s source ...] [-b binlog-pos] <skip/replace/revert> [replace-sql1;replace-sql2;] # `skip`/`replace`/`revert`当前错误事件或特定binlog位置（binlog-pos）事件。
list-member list-member [--leader] [--master] [--worker] [--name master-name/worker-name ...] # 罗列成员信息
offline-member offline-member <--master/--worker> <--name master-name/worker-name>。# 已关闭的离线会员
operate-leader operate-leader <operate-type> # `evict`/`cancel-evict` the leader.（驱逐或不驱逐leader）
operate-schema operate-schema <operate-type> <-s source ...> <task-name | task-file> <-d database> <-t table> [schema-file] # `get` /`set` /`remove`上游表的模式。
operate-source operate-source <operate-type> [config-file ...] [--print-sample-config] `create`/`update`/`stop`/`show` upstream MySQL/MariaDB source
pause-relay pause-relay <-s source ...> # 暂停dm-worker的中继单元
pause-task pause-task [-s source ...] <task-name | task-file> # 暂停指定的运行任务
purge-relay purge-relay <-s source> <-f filename> [--sub-dir directory] # 根据指定的文件名清除DM-worker的中继日志文件
query-status query-status [-s source ...] [task-name | task-file] [--more] # 查看任务状态
resume-relay resume-relay <-s source ...> # 恢复DM-worker's中继单元
resume-task resume-task [-s source ...] <task-name | task-file> # 恢复一个指定的被暂停的任务
show-ddl-locks show-ddl-locks [-s source ...] [task-name | task-file] # 显示未解析的DDL锁。
start-task start-task [-s source ...] [--remove-meta] <config-file> # 启动任务
stop-task stop-task [-s source ...] <task-name | task-file> # 停止任务
unlock-ddl-lock unlock-ddl-lock <lock-ID> # 强制解锁DDL锁定。
Special Commands:
--encrypt Encrypts plaintext to ciphertext.
--decrypt Decrypts ciphertext to plaintext.
Global Options:
--V Prints version and exit.
--config Path to config file.
--master-addr Master API server address.
--rpc-timeout RPC timeout, default is 10m.
--ssl-ca Path of file that contains list of trusted SSL CAs for connection.
--ssl-cert Path of file that contains X509 certificate in PEM format for connection.
--ssl-key Path of file that contains X509 key in PEM format for connection.二、同步任务创建
1.创建数据源
1.1 编辑配置文件
1.1.1 配置文件完整示例（DM1.0）
# Worker Configuration.
# Log configuration.
log-level = "info"
log-file = "dm-worker.log"
# DM-worker listening address.
worker-addr = ":8262"
# Represents a MySQL/MariaDB instance or a replication group.
source-id = "mysql-replica-01"
# Server id of slave for binlog replication.
# Each instance (master and slave) in the replication group should have a different server id.
server-id = 101
# flavor: mysql/mariadb
flavor = "mysql"
# The directory used to store relay log.
relay-dir = "./relay_log"
# Enables gtid in the relay log unit
enable-gtid = false
relay-binlog-name = ""
relay-binlog-gtid = ""
[from]
host = "127.0.0.1"
user = "root"
password = "Up8156jArvIPymkVC+5LxkAT6rek"
port = 3306
# Relay log purge strategy.
[purge]
interval = 3600
expires = 24
remain-space = 15
# Task status checker.
[checker]
check-enable = true
backoff-rollback = "5m"
backoff-max = "5m"1.1.2 配置文件解释
Global 配置
配置项 | 说明 |
| 日志等级，值可以为 “debug”、”info”、”warn”、”error”、”fatal”，默认值为 “info”。一般情况下不需要手动配置，如果需要排查问题，可以将等级设置为 “debug”。 |
| 日志文件，如果不配置日志会输出到标准输出中。 |
| DM-worker 服务的地址，可以省略 IP 信息，例如：”:8262”。 |
| 标识一个 MySQL/MariaDB 实例或者 replication group。 |
| DM-worker 作为上游 MySQL/MariaDB slave 来获取 binlog 的 server id，该值在一个 replication group （包括 master 和 slave）中必须是唯一的。v1.0.2 及以上版本的 DM 会自动生成，不需要手动配置该项。 |
| 上游数据库的类型，目前值可以为 “mysql” 或者 “mariadb”。v1.0.2 及以上版本的 DM 会自动判断上游版本，不需要手动配置该项。 |
| 存储 relay log 的目录，默认值为 “./relay_log”。 |
| 是否使用 GTID 方式从上游拉取 binlog，默认值为 false。一般情况下不需要手动配置，如果上游数据库启用了 GTID 支持，且需要做主从切换，则将该配置项设置为 true。 |
| 拉取上游 binlog 的起始文件名，例如 “mysql-bin.000002”，该配置在 |
| 拉取上游 binlog 的起始 GTID，例如 “e9a1fc22-ec08-11e9-b2ac-0242ac110003:1-7849”，该配置在 |
数据库链接配置（from 配置项）
配置项 | 说明 |
| 上游数据库的 host。 |
| 上游数据库的端口。 |
| 连接数据库使用的用户名。 |
| 连接数据库使用的密码。注意：需要使用 dmctl 加密后的密码。 |
relay log 清理策略配置（purge 配置项）
一般情况下不需要手动配置，如果 relay log 数据量较大，磁盘空间不足，则可以通过该配置项设置，避免 relay log 写满磁盘。
配置项 | 说明 |
| 定期检查 relay log 是否过期的间隔时间，默认值：3600，单位：秒。 |
| relay log 的过期时间，默认值为 0，单位：小时。超过过期时间的 relay log 会被 DM 删除。如果不设置则 DM 不会自动清理过期的 relay log。 |
| 设置最小的可用磁盘空间。当磁盘可用空间小于这个值时，DM-worker 会尝试删除 relay log，默认值：15，单位：GB。 |
注意：
仅在
interval不为 0 且expires和remain-space两个配置项中至少有一个不为 0 的情况下 DM 的自动清理策略才会生效。
任务检查模块配置（checker 配置项）
配置项 | 说明 |
| 是否开启任务状态检查。开启后 DM 会尝试自动恢复因错误而暂停的数据同步任务，默认值：true。 |
| 任务检查模块中，定时调整恢复等待时间的间隔，默认值：”5m0s”。 |
| 任务检查模块中，检查出错误后等待自动恢复的最长时间间隔，默认值：”5m0s”。 |
1.1.3 DM2.0给的数据库配置实例
source-id: "mysql-replica-01"
# 是否开启 GTID
enable-gtid: false
# 是否开启 relay log
enable-relay: false
relay-binlog-name: '' # 拉取上游 binlog 的起始文件名
relay-binlog-gtid: '' # 拉取上游 binlog 的起始 GTID
from:
host: "127.0.0.1"
port: 3306
user: "root"
password: "ZqMLjZ2j5khNelDEfDoUhkD5aV5fIJOe0fiog9w=" # 推荐使用 dmctl 对上游数据库的用户密码加密之后的密码
security: # 上游数据库 TLS 相关配置
ssl-ca: "/path/to/ca.pem"
ssl-cert: "/path/to/cert.pem"
ssl-key: "/path/to/key.pem"
# purge:
# interval: 3600
# expires: 0
# remain-space: 15配置项说明
Global 配置
配置项 | 说明 |
| 标识一个 MySQL 实例。 |
| 是否使用 GTID 方式从上游拉取 binlog，默认值为 false。一般情况下不需要手动配置，如果上游数据库启用了 GTID 支持，且需要做主从切换，则将该配置项设置为 true。 |
| 是否开启 relay log，默认值为 false。 |
| 拉取上游 binlog 的起始文件名，例如 "mysql-bin.000002"，该配置在 |
| 拉取上游 binlog 的起始 GTID，例如 "e9a1fc22-ec08-11e9-b2ac-0242ac110003:1-7849"，该配置在 |
| 上游数据库的 host。 |
| 上游数据库的端口。 |
| 上游数据库使用的用户名。 |
| 上游数据库的用户密码。注意：推荐使用 dmctl 加密后的密码。 |
| 上游数据库 TLS 相关配置。 |
relay log 清理策略配置（purge 配置项）
一般情况下不需要手动配置，如果 relay log 数据量较大，磁盘空间不足，则可以通过设置该配置项来避免 relay log 写满磁盘。
配置项 | 说明 |
| 定期检查 relay log 是否过期的间隔时间，默认值：3600，单位：秒。 |
| relay log 的过期时间，默认值为 0，单位：小时。未由 relay 处理单元进行写入、或已有数据迁移任务当前或未来不需要读取的 relay log 在超过过期时间后会被 DM 删除。如果不设置则 DM 不会自动清理过期的 relay log。 |
| 设置最小的可用磁盘空间。当磁盘可用空间小于这个值时，DM-worker 会尝试删除 relay log，默认值：15，单位：GB。 |
1.1.4 实际编辑的配置文件（DM 2.0官网给出的配置项）
vim tidb/dm/deploy/dm-worker-8262/conf/source.yaml# MySQL1 Configuration.
source-id: "mysql-replica-01" # 数据源的名
# DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是在上游 MySQL 已开启 GTID 模式。
enable-gtid: false
from:
host: "172.11.10.12" # 上游数据源ip等相关信息
user: "root"
password: "VjX8cEeT4h0C80pe/1aU="
port: 33061.2 将数据源加载到DM集群中
tiup dmctl --master-addr master_ip:8261 operate-source create conf/source.yaml1.3 查看原数据库列表
tiup dmctl --master-addr master_ip:8261 operate-source show1.4 查看原数据库配置(get-config 命令仅在 DM v2.0.1 及其以后版本支持)
tiup dmctl --master-addr master_ip:8261 get-config source mysql-replica-012.编辑配置任务
2.1 配置迁移任务文件
2.1.1 DM 1.0的任务配置文件示例
---
# ----------- 全局配置 -----------
## ********* 基本信息配置 *********
name: test # 任务名称，需要全局唯一
task-mode: all # 任务模式，可设为 "full"、"incremental"、"all"
is-sharding: true # 是否为分库分表合并任务
meta-schema: "dm_meta" # 下游储存 `meta` 信息的数据库
remove-meta: false # 是否在任务同步开始前移除该任务名对应的 `meta`（`checkpoint` 和 `onlineddl` 等）。
enable-heartbeat: false # 是否开启 `heartbeat` 功能
online-ddl-scheme: "gh-ost" # 目前仅支持 "gh-ost" 、"pt"
target-database: # 下游数据库实例配置
host: "192.168.0.1"
port: 4000
user: "root"
password: "" # 如果不为空则需经过 dmctl 加密
## ******** 功能配置集 **********
routes: # 上游和下游表之间的路由 table routing 规则集
route-rule-1: # 配置名称
schema-pattern: "test_*" # 库名匹配规则，支持通配符 "*" 和 "?"
table-pattern: "t_*" # 表名匹配规则，支持通配符 "*" 和 "?"
target-schema: "test" # 目标库名称
target-table: "t" # 目标表名称
route-rule-2:
schema-pattern: "test_*"
target-schema: "test"
filters: # 上游数据库实例匹配的表的 binlog event filter 规则集
filter-rule-1: # 配置名称
schema-pattern: "test_*" # 库名匹配规则，支持通配符 "*" 和 "?"
table-pattern: "t_*" # 表名匹配规则，支持通配符 "*" 和 "?"
events: ["truncate table", "drop table"] # 匹配哪些 event 类型
action: Ignore # 对与符合匹配规则的 binlog 同步（Do）还是忽略(Ignore)
filter-rule-2:
schema-pattern: "test_*"
events: ["all dml"]
action: Do
black-white-list: # 上游数据库实例匹配的表的 black & white list 过滤规则集
bw-rule-1: # 配置名称
do-dbs: ["~^test.*", "user"] # 同步哪些库
ignore-dbs: ["mysql", "account"] # 忽略哪些库
do-tables: # 同步哪些表
- db-name: "~^test.*"
tbl-name: "~^t.*"
- db-name: "user"
tbl-name: "information"
ignore-tables: # 忽略哪些表
- db-name: "user"
tbl-name: "log"
mydumpers: # mydumper 处理单元运行配置参数
global: # 配置名称
mydumper-path: "./bin/mydumper" # mydumper binary 文件地址，默认值为 "./bin/mydumper"
threads: 4 # mydumper 从上游数据库实例导出数据的线程数量，默认值为 4
chunk-filesize: 64 # mydumper 生成的数据文件大小，默认值为 64，单位为 MB
skip-tz-utc: true # 忽略对时间类型数据进行时区转化，默认值为 true
extra-args: "--no-locks" # mydumper 的其他参数，在 v1.0.2 版本中 DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置
loaders: # loader 处理单元运行配置参数
global: # 配置名称
pool-size: 16 # loader 并发执行 mydumper 的 SQL 文件的线程数量，默认值为 16
dir: "./dumped_data" # loader 读取 mydumper 输出文件的地址，同实例对应的不同任务必须不同（mydumper 会根据这个地址输出 SQL 文件），默认值为 "./dumped_data"
syncers: # syncer 处理单元运行配置参数
global: # 配置名称
worker-count: 16 # syncer 并发同步 binlog event 的线程数量，默认值为 16
batch: 100 # syncer 同步到下游数据库的一个事务批次 SQL 语句数，默认值为 100
# ----------- 实例配置 -----------
mysql-instances:
-
source-id: "mysql-replica-01" # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id` 配置
meta: # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 同步开始的位置; 如果 checkpoint 存在，则以 `checkpoint` 为准
binlog-name: binlog.000001
binlog-pos: 4
route-rules: ["route-rule-1", "route-rule-2"] # 该上游数据库实例匹配的表到下游数据库的 table routing 规则名称
filter-rules: ["filter-rule-1"] # 该上游数据库实例匹配的表的 binlog event filter 规则名称
black-white-list: "bw-rule-1" # 该上游数据库实例匹配的表的 black & white list 过滤规则名称
mydumper-config-name: "global" # mydumper 配置名称
loader-config-name: "global" # loader 配置名称
syncer-config-name: "global" # Syncer 配置名称
-
source-id: "mysql-replica-02" # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id` 配置
mydumper-thread: 4 # mydumper 用于导出数据的线程数量，等同于 mydumper 处理单元配置中的 `threads`，在 v1.0.2 版本引入
loader-thread: 16 # loader 用于导入数据的线程数量，等同于 loader 处理单元配置中的 `pool-size`, 在 v1.0.2 版本引入
syncer-thread: 16 # syncer 用于同步增量数据的线程数量，等同于 syncer 处理单元配置中的 `worker-count`，在 v1.0.2 版本引入配置顺序
通过上面的配置文件示例，可以看出配置文件总共分为两个部分：全局配置和实例配置，其中全局配置又分为基本信息配置和实例配置，配置顺序如下：
全局配置
任务基本信息配置
配置任务的基本信息，配置项的说明参见以上示例配置文件中的注释。其中 task-mode 需要特殊说明：
task-mode
- 描述：任务模式，可以通过任务模式来指定需要执行的数据迁移工作。
- 值为字符串（
full，incremental或all）。
-
full：只全量备份上游数据库，然后将数据全量导入到下游数据库。 -
incremental：只通过 binlog 把上游数据库的增量修改同步到下游数据库, 可以设置实例配置的meta配置项来指定增量同步开始的位置。 -
all：full+incremental。先全量备份上游数据库，将数据全量导入到下游数据库，然后从全量数据备份时导出的位置信息 (binlog position) 开始通过 binlog 增量同步数据到下游数据库。
功能配置集
全局配置主要包含下列功能配置集：
配置项 | 说明 |
| 上游和下游表之间的路由 table routing 规则集。如果上游与下游的库名、表名一致，则不需要配置该项。使用场景及示例配置参见 Table Routing |
| 上游数据库实例匹配的表的 binlog event filter 规则集。如果不需要对 binlog 进行过滤，则不需要配置该项。使用场景及示例配置参见 Binlog Event Filter |
| 该上游数据库实例匹配的表的 black & white list 过滤规则集。建议通过该项指定需要同步的库和表，否则会同步所有的库和表。使用场景及示例配置参见 Black & White Lists |
| mydumper 处理单元运行配置参数。如果默认配置可以满足需求，则不需要配置该项，也可以只使用 |
| loader 处理单元运行配置参数。如果默认配置可以满足需求，则不需要配置该项，也可以只使用 |
| syncer 处理单元运行配置参数。如果默认配置可以满足需求，则不需要配置该项，也可以只使用 |
各个功能配置集的参数及解释参见完整配置文件示例中的注释说明。新版本迁移配置
实例配置
本小节定义具体的数据同步子任务，DM 支持从单个或者多个上游 MySQL 实例同步数据到同一个下游数据库实例。
在该项配置中设置数据同步子任务中各个功能对应的配置集中的配置名称，关于这些配置项的更多配置细节，参见功能配置集的相关配置项，对应关系如下：
配置项 | 相关配置项 |
|
|
|
|
|
|
|
|
|
|
|
|
2.1.2 DM 2.0 配置文件示例
# ----------- 全局配置 -----------
## ********* 基本信息配置 *********
name: test # 任务名称，需要全局唯一
task-mode: all # 任务模式，可设为 "full" - "只进行全量数据迁移"、"incremental" - "Binlog 实时同步"、"all" - "全量 + Binlog 迁移"
shard-mode: "pessimistic" # 如果为分库分表合并任务则需要配置该项。默认使用悲观协调模式 "pessimistic"，在深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic"
meta-schema: "dm_meta" # 下游储存 `meta` 信息的数据库
timezone: "Asia/Shanghai" # 时区
case-sensitive: false # schema/table 是否大小写敏感
online-ddl-scheme: "gh-ost" # 目前仅支持 "gh-ost" 、"pt"
ignore-checking-items: [] # 不关闭任何检查项。可选的检查项有 "all"、"dump_privilege"、"replication_privilege"、"version"、"binlog_enable"、"binlog_format"、"binlog_row_image"、"table_schema"、"schema_of_shard_tables"、"auto_increment_ID"
clean-dump-file: true # 是否清理 dump 阶段产生的文件，包括 metadata 文件、建库建表 SQL 文件以及数据导入 SQL 文件
target-database: # 下游数据库实例配置
host: "192.168.0.1"
port: 4000
user: "root"
password: "/Q7B9DizNLLTTfiZHv9WoEAKamfpIUs=" # 推荐使用经 dmctl 加密后的密码
max-allowed-packet: 67108864 # 设置 DM 内部连接 TiDB 服务器时，TiDB 客户端的 "max_allowed_packet" 限制（即接受的最大数据包限制），单位为字节，默认 67108864 (64 MB)
# 该配置项从 DM v2.0.0 版本起弃用，DM 会自动获取连接 TiDB 的 "max_allowed_packet"
session: # 设置 TiDB 的 session 变量，在 v1.0.6 版本引入。更多变量及解释参见 `https://docs.pingcap.com/zh/tidb/stable/system-variables`
sql_mode: "ANSI_QUOTES,NO_ZERO_IN_DATE,NO_ZERO_DATE" # 从 DM v2.0.0 版本起，如果配置文件中没有出现该项，DM 会自动从下游 TiDB 中获得适合用于 "sql_mode" 的值。手动配置该项具有更高优先级
tidb_skip_utf8_check: 1 # 从 DM v2.0.0 版本起，如果配置文件中没有出现该项，DM 会自动从下游 TiDB 中获得适合用于 "tidb_skip_utf8_check" 的值。手动配置该项具有更高优先级
tidb_constraint_check_in_place: 0
security: # 下游 TiDB TLS 相关配置
ssl-ca: "/path/to/ca.pem"
ssl-cert: "/path/to/cert.pem"
ssl-key: "/path/to/key.pem"
## ******** 功能配置集 **********
routes: # 上游和下游表之间的路由 table routing 规则集
route-rule-1: # 配置名称
schema-pattern: "test_*" # 库名匹配规则，支持通配符 "*" 和 "?"
table-pattern: "t_*" # 表名匹配规则，支持通配符 "*" 和 "?"
target-schema: "test" # 目标库名称
target-table: "t" # 目标表名称
route-rule-2:
schema-pattern: "test_*"
target-schema: "test"
filters: # 上游数据库实例匹配的表的 binlog event filter 规则集
filter-rule-1: # 配置名称
schema-pattern: "test_*" # 库名匹配规则，支持通配符 "*" 和 "?"
table-pattern: "t_*" # 表名匹配规则，支持通配符 "*" 和 "?"
events: ["truncate table", "drop table"] # 匹配哪些 event 类型
action: Ignore # 对与符合匹配规则的 binlog 迁移（Do）还是忽略(Ignore)
filter-rule-2:
schema-pattern: "test_*"
events: ["all dml"]
action: Do
block-allow-list: # 定义数据源迁移表的过滤规则，可以定义多个规则。如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list
bw-rule-1: # 规则名称
do-dbs: ["~^test.*", "user"] # 迁移哪些库
ignore-dbs: ["mysql", "account"] # 忽略哪些库
do-tables: # 迁移哪些表
- db-name: "~^test.*"
tbl-name: "~^t.*"
- db-name: "user"
tbl-name: "information"
bw-rule-2: # 规则名称
ignore-tables: # 忽略哪些表
- db-name: "user"
tbl-name: "log"
mydumpers: # dump 处理单元的运行配置参数
global: # 配置名称
threads: 4 # dump 处理单元从上游数据库实例导出数据的线程数量，默认值为 4
chunk-filesize: 64 # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB
skip-tz-utc: true # 忽略对时间类型数据进行时区转化，默认值为 true
extra-args: "--consistency none" # dump 处理单元的其他参数，不需要在 extra-args 中配置 table-list，DM 会自动生成
loaders: # load 处理单元的运行配置参数
global: # 配置名称
pool-size: 16 # load 处理单元并发执行 dump 处理单元的 SQL 文件的线程数量，默认值为 16，当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值
dir: "./dumped_data" # dump 处理单元输出 SQL 文件的目录，同时也是 load 处理单元读取文件的目录。该配置项的默认值为 "./dumped_data"。同实例对应的不同任务必须配置不同的目录
syncers: # sync 处理单元的运行配置参数
global: # 配置名称
worker-count: 16 # sync 并发迁移 binlog event 的线程数量，默认值为 16，当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值
batch: 100 # sync 迁移到下游数据库的一个事务批次 SQL 语句数，默认值为 100
enable-ansi-quotes: true # 若 `session` 中设置 `sql-mode: "ANSI_QUOTES"`，则需开启此项
safe-mode: false # 设置为 true，则将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 5 分钟内 TiDB DM 会自动启动 safe mode
它们时 `syncer-thread` 优先级更高。当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值2.1.3 实际编辑的配置文件
vim /tidb/dm/deploy/dm-master-8261/conf/task.yaml# 任务名，多个同时运行的任务不能重名。
name: "test"
# 全量+增量 (all) 迁移模式。
task-mode: "all"
# 下游 TiDB 配置信息。
target-database:
host: "172.10.11.13"
port: 4000
user: "root"
password: ""
# 当前数据迁移任务需要的全部上游 MySQL 实例配置。
mysql-instances:
-
# 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。
source-id: "mysql-replica-01"
# 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置。
block-allow-list: "global" # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
# dump 处理单元的配置项名称，用于引用全局的 dump 处理单元配置。
mydumper-config-name: "global"
-
source-id: "mysql-replica-02"
block-allow-list: "global" # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
mydumper-config-name: "global"
# 黑白名单全局配置，各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
global:
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。
# dump 处理单元全局配置，各实例通过配置项名引用。
mydumpers:
global:
extra-args: "-B test_db -T test_table" # dump 处理单元的其他参数，从 DM 1.0.2 版本开始，DM 会自动生成 table-list 配置，在其之前的版本仍然需要人工配置。2.1.4 增量的配置文件模版
name: test # 任务名称，需要全局唯一
task-mode: incremental # 任务模式，可设为 "full"、"incremental"、"all"
target-database: # 下游数据库实例配置
host: "127.0.0.1"
port: 4000
user: "root"
password: "" # 如果密码不为空，则推荐使用经过 dmctl 加密的密文
## ******** 功能配置集 **********
block-allow-list: # 上游数据库实例匹配的表的 block-allow-list 过滤规则集，如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list
bw-rule-1: # 黑白名单配置项 ID
do-dbs: ["log"] # 迁移哪些库
syncers: # sync 处理单元的运行配置参数
global: # 配置名称
safe-mode: true # 设置为 true，则将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 5 分钟内 TiDB DM 会自动启动 safe mode
# ----------- 实例配置 -----------
mysql-instances:
- source-id: "mysql-01" # 上游实例或者复制组 ID
block-allow-list: "bw-rule-1" # 黑白名单配置名称，如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list
syncer-config-name: "global" # syncers 配置的名称
meta: # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 迁移开始的位置; 如果 `checkpoint` 存在，则以 `checkpoint` 为 准
binlog-name: mysql-bin.000001
binlog-pos: 20223.开启任务
tiup dmctl --master-addr master_ip:8261 start-task ./task.yaml4.查看任务状态
tiup dmctl --master-addr master_ip:8261 query-status test(任务名)4.1 状态信息详解
{
"result": true, # 查询是否成功
"msg": "", # 查询失败原因描述
"sources": [ # 上游 MySQL 列表
{
"result": true,
"msg": "",
"sourceStatus": { # 上游 MySQL 的信息
"source": "mysql-replica-01",
"worker": "worker1",
"result": null,
"relayStatus": null
},
"subTaskStatus": [ # 上游 MySQL 所有子任务的信息
{
"name": "test", # 子任务名称
"stage": "Running", # 子任务运行状态，包括 “New”，“Running”，“Paused”，“Stopped” 以及 “Finished”
"unit": "Sync", # DM 的处理单元，包括 “Check”，“Dump“，“Load” 以及 “Sync”
"result": null, # 子任务失败时显示错误信息
"unresolvedDDLLockID": "test-`test`.`t_target`", # sharding DDL lock ID，可用于异常情况下手动处理 sharding DDL lock
"sync": { # 当前 `Sync` 处理单元的迁移信息
"totalEvents": "12", # 该子任务中迁移的 binlog event 总数
"totalTps": "1", # 该子任务中每秒迁移的 binlog event 数量
"recentTps": "1", # 该子任务中最后一秒迁移的 binlog event 数量
"masterBinlog": "(bin.000001, 3234)", # 上游数据库当前的 binlog position
"masterBinlogGtid": "c0149e17-dff1-11e8-b6a8-0242ac110004:1-14", # 上游数据库当前的 GTID 信息
"syncerBinlog": "(bin.000001, 2525)", # 已被 `Sync` 处理单元迁移的 binlog position
"syncerBinlogGtid": "", # 使用 GTID 迁移的 binlog position
"blockingDDLs": [ # 当前被阻塞的 DDL 列表。该项仅在当前 DM-worker 所有上游表都处于 “synced“ 状态时才有数值，此时该列表包含的是待执行或待跳过的 sharding DDL 语句
"USE `test`; ALTER TABLE `test`.`t_target` DROP COLUMN `age`;"
],
"unresolvedGroups": [ # 没有被解决的 sharding group 信息
{
"target": "`test`.`t_target`", # 待迁移的下游表
"DDLs": [
"USE `test`; ALTER TABLE `test`.`t_target` DROP COLUMN `age`;"
],
"firstPos": "(bin|000001.000001, 3130)", # sharding DDL 语句起始 binlog position
"synced": [ # `Sync` 处理单元已经读到该 sharding DDL 的上游分表
"`test`.`t2`"
"`test`.`t3`"
"`test`.`t1`"
],
"unsynced": [ # `Sync` 处理单元未读到该 sharding DDL 的上游分表。如有上游分表未完成同步，`blockingDDLs` 为空
]
}
],
"synced": false # 增量复制是否已追上上游。由于后台 `Sync` 单元并不会实时刷新保存点，当前值为 “false“ 并不一定代表发生了迁移延迟
}
}
]
},
{
"result": true,
"msg": "",
"sourceStatus": {
"source": "mysql-replica-02",
"worker": "worker2",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "test",
"stage": "Running",
"unit": "Load",
"result": null,
"unresolvedDDLLockID": "",
"load": { # `Load` 处理单元的迁移信息
"finishedBytes": "115", # 已全量导入字节数
"totalBytes": "452", # 总计需要导入的字节数
"progress": "25.44 %" # 全量导入进度
}
}
]
},
{
"result": true,
"sourceStatus": {
"source": "mysql-replica-03",
"worker": "worker3",
"result": null,
"relayStatus": null
},
"subTaskStatus": [
{
"name": "test",
"stage": "Paused",
"unit": "Load",
"result": { # 错误示例
"isCanceled": false,
"errors": [
{
"Type": "ExecSQL",
"msg": "Error 1062: Duplicate entry '1155173304420532225' for key 'PRIMARY'\n/home/jenkins/workspace/build_dm/go/src/github.com/pingcap/tidb-enterprise-tools/loader/db.go:160: \n/home/jenkins/workspace/build_dm/go/src/github.com/pingcap/tidb-enterprise-tools/loader/db.go:105: \n/home/jenkins/workspace/build_dm/go/src/github.com/pingcap/tidb-enterprise-tools/loader/loader.go:138: file test.t1.sql"
}
],
"detail": null
},
"unresolvedDDLLockID": "",
"load": {
"finishedBytes": "0",
"totalBytes": "156",
"progress": "0.00 %"
}
}
]
}
]
}5.停止任务
tiup dmctl --master-addr master_ip:8261 stop-task test(任务名)6.监控任务与查看日志
如果使用 TiUP 部署 DM 集群时，正确部署了 Prometheus、Alertmanager 与 Grafana，且其地址均为 172.16.10.71。可在浏览器中打开 http://172.16.10.71:9093 进入 Alertmanager 查看 DM 告警信息；可在浏览器中打开 http://172.16.10.71:3000 进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。
ps -ef|grep dm-worker # 可以通过此来查看进程，即能查看日志所在位置DM 在运行过程中，DM-worker, DM-master 及 dmctl 都会通过日志输出相关信息。各组件的日志目录如下：
- DM-master 日志目录：通过 DM-master 进程参数
--log-file设置。如果使用 TiUP 部署 DM，则日志目录位于{log_dir}。 - DM-worker 日志目录：通过 DM-worker 进程参数
--log-file设置。如果使用 TiUP 部署 DM，则日志目录位于{log_dir}。
