背景

TiDB 是一个分布式关系型数据库，可以无缝对接 MySQL。考虑到产品数据量大的情况下，单机 MySQL 可能无法支撑，而无缝切换到 TiDB 集群也比较方便，所以领导让我调研了一天迁移过程。

本文将记录使用 mydumper 工具导出 MySQL 数据库数据，并使用 TiDB Lightning 将数据迁移到 TiDB 集群的流程。对比以前部署测试 MyCat 时的经历，发现 TiDB 迁移时不需要配置分库分表规则，迁移过程更方便，对得起“无缝”二字！

第一步，部署 TiDB Lightning

TiDB Lightning 部署包是一个压缩文件，解压后可直接使用，部署流程非常简单：

（一）确定 TiDB 版本

用 MySQL 客户端连接到 TiDB 集群后，执行 select version() 语句得到版本号：

（二）下载工具包

根据版本号，确定下载连接：https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz 替换为具体的版本号后的地址。

下载文件：

wget  https://download.pingcap.org/tidb-toolkit-v4.0.0-linux-amd64.tar.gz

（三）解压

进入部署包所在目录，解压：

tar -xzf tidb-toolkit-v4.0.0-linux-amd64.tar.gz

进入解压后的 bin 目录，查看它提供的工具：

mydumper 和 tidb-lightning 就是一对导出、导入工具，其中 mydumper 跟 MySQL 的 mysqldump 功能是一样的。

但是据我测试导出 3.9G 的数据耗时来看，mydumper 比 mysqldump 快很多。

建议使用 mydumper，原因是用它导出的数据时，会自动创建 xxx-schema-create.sql 建库文件，而且建表和插入 SQL 文件分开，不用额外操作，配套用 tidb-lightning 执行导入，不容易出错。

如果用 mysqldumper 则需要注意导出建库语句，是否需要添加 use database 之类的语句，用 MySQL 的 source 导入时容易出现的问题，都需要注意。不是配套的工具，这种方式没有测试过。

第二步，导出 MySQL 数据

进入 bin 目录，用 mydumper 工具，连接到目标数据库上导出，命令如下：

./mydumper -h  IP -P 3306 -u root -p 123456 -t 16 -F 128 -B targetDatabase -o /tidb-data/mydumpersql/

参数说明：

1. -B， --database 需要备份的数据库
2. -t，–threads 备份执行的线程数，默认4个线程
3. -F，–chunk-filesize 行块分割表的文件大小，单位是MB
4. -o，–outputdir 备份文件目录

注意，最后一个 outputdir 的值，后面导入的时候需要使用。因为使用多线程，所以就不难理解为何它的效率会比 mysqldumper 高了。

第三步，导入 TiDB 集群

最后一步，利用 tidb-lightning 工具将第二步导出的数据，导入到 TiDB 集群中。

官网的操作流程不是很清楚，而且给出的 tidb-lightning 里面有一项配置对 4.0.0 版本来说会报错，这里提供纠正后的完整配置。

（一）创建配置文件

在 bin 目录下创建一个配置文件 tidb-lightning.toml【文件名称任意】，并打开：

touch tidb-lightning.toml
vi tidb-lightning.toml

写入如下配置信息：

[lightning]

# 转换数据的并发数，默认为逻辑 CPU 数量，不需要配置。
# 混合部署的情况下可以配置为逻辑 CPU 的 75% 大小。
# region-concurrency =

# 日志
level = "info"
file = "tidb-lightning.log"

[tikv-importer]
# backend 设置为 local 模式
backend = "tidb"
# 设置本地临时存储路径
# sorted-kv-dir = "/mnt/ssd/sorted-kv-dir"

[mydumper]
# Mydumper 源数据目录。
data-source-dir = "/tidb-data/mydumpersql"

[tidb]
# 目标集群的信息。tidb-server 的监听地址，填一个即可。
host = "192.168.xxx.xxx"
port = 4000
user = "root"
password = "root"
# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10080
# pd-server 的地址，填一个即可
# pd-addr = "192.168.xxx.xxx:2379"

说明：

1. data-source-dir 就是第二步导出时 -o 的参数值；
2. host 是 TiDB 集群地址和端口；
3. sorted-kv-dir 这个配置不支持，放开后会报错：unknown configuration options: tikv-importer.sorted-kv-dir。
4. pd-addr 这个配置没啥用，去掉也不影响导入

（二）执行导入命令

由于数据库全量导入，操作耗时较长，官方建议将导入命令封装成脚本。

先在 bin 目录下创建一个 loaddata.sh 文件，内容如下：

#!/bin/bash
nohup ./tidb-lightning -config ./tidb-lightning.toml > nohup.out &

执行脚本，然后查看 TiDB 的集群日志 tidb.log ，查看导入进度。

导入完成后，用 MySQL 客户端连接到 TiDB 集群的一个主机，查看数据。

启示录

将 MySQL 数据迁移到 TiDB 的过程，直接参考官方文档进行操作就可以了。但是，涉及到 tidb-lightning 工具的那一章节，内容跟数据迁移章节有一些看不懂，其中涉及到 tikv-importer，它和 tidb-lightning 的关系没有详细说明，还有一些配置项会导致导入报错。

实践证明，只用 tidb-lightning 工具就可以完成数据迁入过程。

去年 8 月份调研过 MyCat 集群，由于它的分片分库规则比较复杂，而目前这个产品涉及的表比较多，而且很多都是动态创建的，所以只做了技术调研，一直没有技术落地。

MyCat 和 TiDB 都不会对应用端代码产生影响，JDBC 连接只需要修改 IP 和端口就好，几乎没有工作量。库表迁移就不一样了，TiDB 可以直接迁移。

MyCat 由于 Schema 和表创建涉及到分库分表策略，需要自己设计数据分布规则，当初也只是简单写了一个生成配置的小程序，不敢保证能够数据能够无缝正确迁移。