<返回更多

MySQL数据迁移到TiDB的流程及为何放弃MyCat

2021-03-05    
加入收藏

背景

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

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

第一步,部署 TiDB Lightning

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

(一)确定 TiDB 版本

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

MySQL数据迁移到TiDB的流程及为何放弃MyCat

 

(二)下载工具包

根据版本号,确定下载连接: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 目录,查看它提供的工具:

MySQL数据迁移到TiDB的流程及为何放弃MyCat

 


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 和表创建涉及到分库分表策略,需要自己设计数据分布规则,当初也只是简单写了一个生成配置的小程序,不敢保证能够数据能够无缝正确迁移。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>