MySQL数据迁移到TiDB的流程及为何放弃MyCat
背景
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/
参数说明：
- -B， --database 需要备份的数据库
- -t，–threads 备份执行的线程数，默认4个线程
- -F，–chunk-filesize 行块分割表的文件大小，单位是MB
- -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"
说明：
- data-source-dir 就是第二步导出时 -o 的参数值；
- host 是 TiDB 集群地址和端口；
- sorted-kv-dir 这个配置不支持，放开后会报错：unknown configuration options: tikv-importer.sorted-kv-dir。
- 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 和表创建涉及到分库分表策略，需要自己设计数据分布规则，当初也只是简单写了一个生成配置的小程序，不敢保证能够数据能够无缝正确迁移。
