从大数据量分库分表 MySQL 合并迁移数据到 TiDB

如果分库分表合并迁移在 1 TiB 以内，请参考从小数据量分库分表 MySQL 合并迁移数据到 TiDB，支持全量和增量且更为简单。

在本文的示例中，假设有两个数据库 my_db1 和 my_db2，使用 Dumpling 分别从 my_db1 中导出 table1 和 table2 两个表，从 my_db2 中导出 table3 和 table4 两个表，然后再用 TiDB Lightning 把导出的 4 个表合并导入到下游 TiDB 中的同一个库 my_db 的同一个表格 table5 中。

本文将以三个步骤演示导入流程：

1. 使用 Dumpling 导出全量数据备份。在本文档示例中，分别从两个源数据库中各导出两个表：
   • 从实例 1 MySQL 的 my_db1 导出 table1、table2
   • 从实例 2 MySQL 的 my_db2 导出 table3、table4
2. 启动 TiDB Lightning 执行导入 TiDB 中的 mydb.table5
3. 使用 DM 进行增量数据迁移（可选）

• 使用 TiUP 安装 DM 集群
• Dumpling 所需上游数据库权限
• TiDB Lightning 下游数据库所需空间

迁移中如果涉及合库合表，来自多张分表的数据可能引发主键或唯一索引的数据冲突。因此在迁移之前，需要检查各分表数据的业务特点。详情请参考，这里做简要描述：

假设 table1~4 具有相同的表结构如下：

其中 列为主键，具有自增属性，多个分表范围重复会引发数据冲突。sid 列为分片键，可以保证全局满足唯一索引。因此可以移除下游 table5 表 id 列的唯一键属性：

CREATE TABLE `table5` (
  `id` bigint(20) NOT NULL,
  `sid` bigint(20) NOT NULL,
  `pid` bigint(20) NOT NULL,
  `comment` varchar(255) DEFAULT NULL,
  INDEX (`id`),
  UNIQUE KEY `sid` (`sid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

如果需要导出的多个分表属于同一个上游 MySQL 实例，建议直接使用 Dumpling 的 -f 参数一次导出多个分表的结果。如果多个分表分布在不同的 MySQL 实例，可以使用 Dumpling 分两次导出，并将两次导出的结果放置在相同的父目录下即可。下面的例子中同时用到了上述两种方式，然后将导出的数据存放在同一父目录下。

首先使用 Dumpling 从 my_db1 中导出表 table1 和 table2，如下：

tiup dumpling -h ${ip} -P 3306 -u root -t 16 -r 200000 -F 256MB -B my_db1 -f 'my_db1.table[12]' -o ${data-path}/my_db1

以上命令行中用到的参数描述如下。要了解更多 Dumpling 参数，请参考 。

然后使用同样的方式从 my_db2 中导出表 table3 和 table4。注意路径在相同 ${data-path} 下的不同子目录 my_db2。

tiup dumpling -h ${ip} -P 3306 -u root -t 16 -r 200000 -F 256MB -B my_db2 -f 'my_db2.table[34]' -o ${data-path}/my_db2

这样所需的全量备份数据就全部导出到了 ${data-path} 目录中。将所有源数据表格存储在一个目录中，是为了后续方便用 TiDB Lightning 导入。

第 3 步增量同步的时候所需的起始位点信息，在 ${data-path} 目录下，my_db1 和 my_db2 的 metadata 文件中，这是 Dumpling 自动生成的元信息文件，请记录其中的 binlog 位置信息。

在启动 TiDB Lightning 进行迁移之前，建议先了解如何处理检查点，然后根据需要选择合适的方式进行迁移。

断点续传

大量数据导入一般耗时数小时甚至数天，长时间运行的进程会有一定机率发生非正常中断。如果每次重启都从头开始，之前已成功导入的数据就会前功尽弃。为此，TiDB Lightning 提供了断点续传的功能，即使 TiDB Lightning 崩溃，在重启时仍然从断点开始继续工作。

• --checkpoint-error-destroy：出现错误后，让失败的表从头开始整个导入过程。
• --checkpoint-error-ignore：如果导入表曾经出错，该命令会清除出错状态，如同错误没有发生过一样。
• --checkpoint-remove：无论是否有出错，把表的断点清除。

关于断点续传的更多信息，请参考 TiDB Lightning 断点续传。

在下游创建 mydb.table5。

执行导入操作

启动 tidb-lightning 的步骤如下：

1. 编写配置文件 tidb-lightning.toml。

   [lightning]
   # 日志
   level = "info"
   file = "tidb-lightning.log"
   [mydumper]
   data-source-dir = ${data-path}
   [tikv-importer]
   # "local"：默认使用该模式，适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。
   # "tidb"：TB 级以下数据量也可以采用`tidb`后端模式，下游 TiDB 可正常提供服务。关于后端模式更多信息请参阅：https://docs.pingcap.com/tidb/stable/tidb-lightning-backends
   backend = "local"
   # 设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空间须大于待导入数据集的大小。建议设为与 `data-source-dir` 不同的磁盘目录，独占 IO 会获得更好的导入性能
   sorted-kv-dir = "${sorted-kv-dir}"
   [[mydumper.files]]
   schema = "my_db"
   table = "table5"
   type = "sql"
   [[mydumper.files]]
   pattern = '(^|/)my_db2\.table[3-4]\..*\.sql$'
   schema = "my_db"
   table = "table5"
   type = "sql"
   # 目标集群的信息，示例仅供参考。请把 IP 地址等信息替换成真实的信息。
   [tidb]
   # 目标集群的信息
   host = ${host}              # 例如：172.16.32.1
   port = ${port}              # 例如：4000
   user = "${user_name}"       # 例如："root"
   password = "${password}"    # 例如："rootroot"
   status-port = ${status-port} # 导入过程 Lightning 需要在从 TiDB 的“状态端口”获取表结构信息，例如：10080
   # PD 集群的地址，Lightning 通过 PD 获取部分信息。
   pd-addr = "${ip}:${port}"   # 例如 172.16.31.3:2379。当 backend = "local" 时 status-port 和 pd-addr 必须正确填写，否则导入将出现异常。

2. 运行 tidb-lightning。如果直接在命令行中启动程序，可能会因为 SIGHUP 信号而退出，建议配合 nohup 或 screen 等工具，如：

   若从 Amazon S3 导入，则需将有权限访问该 S3 后端存储的账号的 SecretKey 和 AccessKey 作为环境变量传入 TiDB Lightning 节点。同时还支持从 ~/.aws/credentials 读取凭证文件。

   export AWS_ACCESS_KEY_ID=${access_key}
   export AWS_SECRET_ACCESS_KEY=${secret_key}
   nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 &

3. 导入开始后，可以采用以下任意方式查看进度：

   • 通过 grep 日志关键字 progress 查看进度，默认 5 分钟更新一次。
   • 通过监控面板查看进度，请参考 。
   • 通过 Web 页面查看进度，请参考 Web 界面。
4. 导入完毕后，TiDB Lightning 会自动退出。查看 tidb-lightning.log 日志末尾是否有 the whole procedure completed 信息，如果有，表示导入成功。如果没有，则表示导入遇到了问题，可根据日志中的 error 提示解决遇到的问题。

注意

无论导入成功与否，最后一行都会显示 tidb lightning exit。它只是表示 TiDB Lightning 正常退出，不代表任务完成。

如果导入过程中遇到问题，请参见 。

基于 binlog 从指定位置同步数据库到 TiDB，可以使用 DM 来执行增量复制

新建 source1.yaml 文件，写入以下内容：

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

在终端中执行下面的命令，使用 tiup dmctl 将数据源配置加载到 DM 集群中:

重复以上步骤直至所有 MySQL 实例被加入 DM。

添加同步任务

编辑 task.yaml，配置增量同步模式，以及每个数据源的同步起点：

name: task-test               # 任务名称，需要全局唯一。
task-mode: incremental        # 任务模式，设为 "incremental" 即只进行增量数据迁移。
# 分库分表合并任务则需要配置 shard-mode。默认使用悲观协调模式 "pessimistic"，在深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic"
# 详细信息可参考：https://docs.pingcap.com/zh/tidb/dev/feature-shard-merge/
shard-mode: "pessimistic"
target-database:              # 下游数据库实例配置。
  host: "${host}"             # 例如：127.0.0.1
  port: 4000
  user: "root"
  password: "${password}"     # 推荐使用经过 dmctl 加密的密文。
##  使用黑白名单配置需要同步的表
  bw-rule-1:                  # 黑白名单配置项 ID。
    do-dbs: ["my_db1"]        # 迁移哪些库。这里将实例 1 的 my_db1 和实例 2 的 my_db2 分别配置为两条 rule，以示例如何避免实例 1 的 my_db2 被同步。
  bw-rule-2:
    do-dbs: ["my_db2"]
routes:                               # 上游和下游表之间的路由 table routing 规则集
  route-rule-1:                       # 配置名称。将 my_db1 中的 table1 和 table2 合并导入下游 my_db.table5
    schema-pattern: "my_db1"          # 库名匹配规则，支持通配符 "*" 和 "?"
    table-pattern: "table[1-2]"       # 表名匹配规则，支持通配符 "*" 和 "?"
    target-schema: "my_db"            # 目标库名称
    target-table: "table5"            # 目标表名称
  route-rule-2:                       # 配置名称。将 my_db2 中的 table3 和 table4 合并导入下游 my_db.table5
    schema-pattern: "my_db2"
    table-pattern: "table[3-4]"
    target-schema: "my_db"
    target-table: "table5"
## 配置数据源，以两个数据源为例
mysql-instances:
  - source-id: "mysql-01"             # 数据源 ID，即 source1.yaml 中的 source-id
    block-allow-list: "bw-rule-1"     # 引入上面黑白名单配置。同步实例1的 my_db1
    route-rules: ["route-rule-1"]     # 引入上面表合并配置。
#       syncer-config-name: "global"  # 引用后面的 syncers 增量数据配置。
    meta:                             # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 `checkpoint` 为准。如果 `meta` 项和下游数据库的 `checkpoint` 都不存在，则从上游当前最新的 binlog 位置开始迁移。
      binlog-name: "${binlog-name}"   # 第 1 步中 ${data-path}/my_db1/metadata 记录的日志位置，当上游存在主从切换时，必须使用 gtid。
      binlog-pos: ${binlog-position}
      # binlog-gtid:                  " 例如：09bec856-ba95-11ea-850a-58f2b4af5188:1-9"
  - source-id: "mysql-02"             # 数据源 ID，即 source1.yaml 中的 source-id
    block-allow-list: "bw-rule-2"     # 引入上面黑白名单配置。实例2的 my_db2
    route-rules: ["route-rule-2"]     # 引入上面表合并配置。
#       syncer-config-name: "global"  # 引用后面的 syncers 增量数据配置。
    meta:                             # task-mode 为 incremental 且下游数据库的 checkpoint 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 checkpoint 为准。
      # binlog-name: "${binlog-name}"   # 第 1 步中 ${data-path}/my_db2/metadata 记录的日志位置，当上游存在主从切换时，必须使用 gtid。
      # binlog-pos: ${binlog-position}
      binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9"
## 【可选配置】 如果增量数据迁移需要重复迁移已经在全量数据迁移中完成迁移的数据，则需要开启 safe mode 避免增量数据迁移报错。
##  该场景多见于以下情况：全量迁移的数据不属于数据源的一个一致性快照，随后从一个早于全量迁移数据之前的位置开始同步增量数据。
# syncers:            # sync 处理单元的运行配置参数。
#  global:           # 配置名称。
#    safe-mode: true # 设置为 true，会将来自数据源的 INSERT 改写为 REPLACE，将 UPDATE 改写为 DELETE 与 REPLACE，从而保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 1 分钟内 TiDB DM 会自动启动 safe mode。

关于任务的更多配置项，可以参考 。

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

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

使用 tiup dmctl 执行以下命令启动数据迁移任务。

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

该命令中的参数描述如下：

如果任务启动失败，可根据返回结果的提示进行配置变更后执行 start-task task.yaml 命令重新启动任务。遇到问题请参考故障及处理方法以及。

如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息，可使用 tiup dmctl 执行 query-status 命令进行查询：

关于查询结果的详细解读，请参考。

监控任务与查看日志

你可以通过 Grafana 或者日志查看迁移任务的历史状态以及各种内部运行指标。

• 通过 Grafana 查看

  如果使用 TiUP 部署 DM 集群时，正确部署了 Prometheus、Alertmanager 与 Grafana，则使用部署时填写的 IP 及端口进入 Grafana，选择 DM 的 dashboard 查看 DM 相关监控项。

• 通过日志查看

  DM 在运行过程中，DM-worker、DM-master 及 dmctl 都会通过日志输出相关信息，其中包含迁移任务的相关信息。各组件的日志目录如下：

  • DM-master 日志目录：通过 DM-master 进程参数 --log-file 设置。如果使用 TiUP 部署 DM，则日志目录默认位于 /dm-deploy/dm-master-8261/log/。
  • DM-worker 日志目录：通过 DM-worker 进程参数 设置。如果使用 TiUP 部署 DM，则日志目录默认位于 /dm-deploy/dm-worker-8262/log/。

• 关于 Dumpling
• 分库分表合并中的悲观/乐观模式
• 恢复数据迁移任务
• 导出和导入集群的数据源和任务配置