摘要:mysql使用mysqldump和mydumper实现数据的导出,和load data导入数据。
tidb则使用dumpling导出和Lightning导入,实现逻辑导出和导入。
1、下载软件:
安装包:
https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz
下载链接中的 {version} 为 TiDB Lightning 的版本号。例如,v5.3.4 版本的下载链接为 :
wget https://download.pingcap.org/tidb-toolkit-v5.3.4-linux-amd64.tar.gz。
2、导出数据和结构(dumpling导出)
/data/tools/tidb-toolkit-v5.3.3-linux-amd64/bin/dumpling -u root -P 4036 -p '123456_fan' -h 10.21.108.174 --filetype sql -t 4 -o /data/backup_data/test_sch -r 200000 -F 256MiB -B sysbench_test
只导出数据,不导出结构(dumpling导出)
/data/tools/tidb-toolkit-v5.3.3-linux-amd64/bin/dumpling -u root -P 4036 -p '123456_fan' -h 10.21.108.174 --filetype sql -t 4 -o /data/backup_data/test_sch -r 200000 -F 256MiB -B sysbench_test -m
3、逻辑导入(tidb-lightning 导入):
/data/tools/tidb-toolkit-v5.3.3-linux-amd64/bin/tidb-lightning -config tidb-lightning.toml
可以放到后台:nohup ./tidb-lightning -config tidb-lightning.toml > nohup.out &
编辑:tidb-lightning.toml
[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"
[tikv-importer]
# 选择使用的 local 后端
backend = "tidb"
# 设置排序的键值对的临时存放地址,目标路径需要是一个空目录
#sorted-kv-dir = "/mnt/ssd/sorted-kv-dir"
[mydumper]
# 源数据目录。
data-source-dir = "/data/backup_data/test_sch"
# 配置通配符规则,默认规则会过滤 mysql、sys、INFORMATION_SCHEMA、PERFORMANCE_SCHEMA、METRICS_SCHEMA、INSPECTION_SCHEMA 系统数据库下的所有表
# 若不配置该项,导入系统表时会出现“找不到 schema”的异常
filter = ['*.*', '!mysql.*', '!sys.*', '!INFORMATION_SCHEMA.*', '!PERFORMANCE_SCHEMA.*', '!METRICS_SCHEMA.*', '!INSPECTION_SCHEMA.*']
[tidb]
# 目标集群的信息
host = "10.21.108.174"
port = 4036
user = "root"
password = "123456_fan"
# 表架构信息在从 TiDB 的“状态端口”获取。
#status-port = 10080
# 集群 pd 的地址
#pd-addr = "172.16.31.3:2379"
说明:
1 从 TiDB 5.3.0 开始,TiDB Lightning 增加了前置检查功能,可以在执行迁移前检查配置。默认开启。该功能会自动进行一些磁盘空间和执行配置的常规检查,主要目的是确保后续的整个导入过程顺利。
下表介绍了各检查项和详细解释。
检查项 | 支持版本 | 解释 |
---|---|---|
集群版本/状态是否正常 | >= 5.3.0 | 检查配置中集群是否可以连接,当后端模式是 Local 的时候,还会检查 TiKV/PD/TiFlash 版本是否支持 Local 导入模式。 |
是否有权限读取数据 | >= 5.3.0 | 检查当从云存储(Amazon S3)读取数据的时候,是否有对应的权限,确保不会因权限缺失导致导入中断。 |
导入空间是否足够 | >= 5.3.0 | 检查 TiKV 集群是否有足够空间导入数据。检查时会对数据源进行采样,通过采样结果预估索引大小占比。由于估算中考虑了索引,因此可能会出现尽管数据源大小低于本地盘可用空间,但依然无法通过检测的情况。当后端是 Local 的时候,因为需要在本地进行外部排序,所以还会检查本地存储是否足够。 |
Region 分布状态 | >= 5.3.0 | 检查 TiKV 集群的 Region 分布是否均匀,以及是否存在大量空 region,如果空 Region 的数量大于 max(1000, 表的数量 * 3) ,即大于 "1000" 和 "3 倍表数量"二者中的较大者,TiDB Lightning 无法执行导入。 |
数据文件是否有大 CSV 文件 | >= 5.3.0 | 当备份文件中出现大于 10 GiB 的 CSV 文件且无法进行自动切分 (StrictFormat=false) 的时候,会导致导入性能下降。该检查的目的是提醒用户确保数据格式的情况下,开启自动切分 CSV 功能。 |
是否可以从断点恢复 | >= 5.3.0 | 该检查是确保断点恢复过程中,不会出现对源文件和数据库中 schema 进行修改,导致导入错误数据的情况。 |
是否可以导入数据到已存在的数据表中 | >= 5.3.0 | 当导入到已创建好的数据表中时,该检查尽可能的检查此次导入的源文件是否和已存在的数据表匹配。检查列数是否匹配,如果源文件存在列名,则检查列名是否匹配。当源文件存在缺省列,则检查缺省列在数据表中是否存在 Default Value,如果存在,则检查通过。 |
导入的目标表是否为空 | >= 5.3.1 | 如果导入的目标表不为空,则 TiDB Lightning 会自动报错退出;如果开启了并行导入模式 (incremental-import = true),则会跳过此检查项。 |
2、TiDB Lightning 的后端决定 tidb-lightning
组件将如何把将数据导入到目标集群中。目前,TiDB Lightning 支持以下后端:
以上几种后端导入数据的区别如下:
-
Local-backend:
tidb-lightning
先将数据编码成键值对并排序存储在本地临时目录,然后将这些键值对以 SST 文件的形式上传到各个 TiKV 节点,然后由 TiKV 将这些 SST 文件 Ingest 到集群中。和Importer-backend
原理相同,不过不依赖额外的tikv-importer
组件。 -
Importer-backend:
tidb-lightning
先将 SQL 或 CSV 数据编码成键值对,由tikv-importer
对写入的键值对进行排序,然后把这些键值对 Ingest 到 TiKV 节点中。 -
TiDB-backend:
tidb-lightning
先将数据编码成INSERT
语句,然后直接在 TiDB 节点上运行这些 SQL 语句进行数据导入。
后端 | Local-backend | Importer-backend | TiDB-backend |
---|---|---|---|
速度 | 快 (~500 GB/小时) | 快 (~400 GB/小时) | 慢 (~50 GB/小时) |
资源使用率 | 高 | 高 | 低 |
占用网络带宽 | 高 | 中 | 低 |
导入时是否满足 ACID | 否 | 否 | 是 |
目标表 | 必须为空 | 必须为空 | 可以不为空 |
额外组件 | 无 | tikv-importer | 无 |
支持 TiDB 集群版本 | >= v4.0.0 | 全部 | 全部 |
是否影响 TiDB 对外提供服务 | 是 | 是 | 否 |
如何选择后端模式
- 如果导入的目标集群为 v4.0 或以上版本,请优先考虑使用 Local-backend 模式。Local-backend 部署更简单并且性能也较其他两个模式更高
- 如果目标集群为 v3.x 或以下,建议使用 Importer-backend 模式
- 如果需要导入的集群为生产环境线上集群,或需要导入的表中已包含有数据,则最好使用 TiDB-backend 模式
配置说明:
# tidb-lightning 任务配置
[lightning]
# 启动之前检查集群是否满足最低需求
check-requirements = true
# 每张表被切分成一个用于存储索引的“索引引擎”和若干存储行数据的“数据引擎”
# 这两项设置控制两种引擎文件的最大并发数
# 控制同时允许导入的最大表数量,对于 TiDB-backend,默认值为 CPU 数
index-concurrency = 40
# 控制同时允许导入的最大“数据引擎”数,默认值为 CPU 数,本配置应大于或等于 index-concurrency
table-concurrency = 40
# 执行 SQL 语句的并发数。默认与逻辑 CPU 的数量相同
# TiDB-backend 的瓶颈通常不在 CPU, 可以根据下游集群的实际负载调大此配置以优化写入速度
# 在调整此配置时,建议将 index-concurrency 和 table-concurrency 也调整成相同的值
region-concurrency = 40
# 日志相关的配置
# 输出日志级别
level = "info"
# 日志输出的文件。如果为空(默认),则会输出至 /tmp/lightning.log.{timestamp};如果希望输出至系统标准输出,请设置为 "-"
# file = "tidb-lightning.log"
[checkpoint]
# 启用断点续传
# 导入数据时,TiDB Lightning 会记录当前表导入的进度
# 若 TiDB Lightning 或其他组件异常退出,在重启时也可以避免重复再导入已完成的数据
enable = true
# 存储断点的方式
# - file(默认):存放在本地文件系统(要求 v2.1.1 或以上)
# - mysql:存放在兼容 MySQL 的数据库服务器
driver = "file"
# 存储断点的数据库名称
# 仅在 driver = "mysql" 时生效
# schema = "tidb_lightning_checkpoint"
# 断点的存放位置
#
# 若 driver = "file",此参数为断点信息存放的文件路径
# 如果不设置该参数则默认为 `/tmp/CHECKPOINT_SCHEMA.pb`
#
# 若 driver = "mysql",此参数为数据库连接参数 (DSN),格式为“用户:密码@tcp(地址:端口)/”
# 默认会重用 [tidb] 设置目标数据库来存储断点
# 为避免加重目标集群的压力,建议另外使用一个兼容 MySQL 的数据库服务器
# dsn = "/tmp/tidb_lightning_checkpoint.pb"
# 导入成功后是否保留断点。默认为删除
# 保留断点可用于调试,但有可能泄漏数据源的元数据
# keep-after-success = false
[tikv-importer]
# 后端模式,对于 TiDB-backend 请设置为 “tidb”
backend = "tidb"
# 对于插入重复数据时执行的操作:
# - replace:新数据替代已有数据
# - ignore:保留已有数据,忽略新数据
# - error:中止导入并报错
# on-duplicate = "replace"
[mydumper]
# 设置文件读取的区块大小(默认为 64 KiB),确保该值比数据源的最长字符串长。
# read-block-size = "64KiB"
# (源数据文件)单个导入区块大小的最小值(默认为 100 GiB)。
# TiDB Lightning 根据该值将一张大表分割为多个数据引擎文件。
# batch-size = "100GiB"
# 本地源数据目录或外部存储 URL
data-source-dir = "/data/my_database"
# “严格”格式的导入数据可加快处理速度。
# strict-format = true 要求:
# 在 CSV 文件的所有记录中,每条数据记录的值不可包含字符换行符(U+000A 和 U+000D,即 \r 和 \n)
# 甚至被引号包裹的字符换行符都不可包含,即换行符只可用来分隔行。
# 导入数据源为严格格式时,TiDB Lightning 会快速定位大文件的分割位置进行并行处理。
# 但是如果输入数据为非严格格式,可能会将一条完整的数据分割成两部分,导致结果出错。
# 为保证数据安全而非追求处理速度,默认值为 false。
# strict-format = false
# 如果 strict-format = true,TiDB Lightning 会将 CSV 大文件分割为多个文件块进行并行处理。max-region-size 是分割后每个文件块的最大大小。
# max-region-size = "256MiB" # Byte(默认是 256 MiB)
# 只导入与该通配符规则相匹配的表,默认会过滤掉系统表。详情见表库过滤章节。
# filter = ['*.*', '!mysql.*', '!sys.*', '!INFORMATION_SCHEMA.*', '!PERFORMANCE_SCHEMA.*', '!METRICS_SCHEMA.*', '!INSPECTION_SCHEMA.*']
# 配置 CSV 文件的解析方式(如果源文件中不包含 CSV 文件可不设置此项)。
[mydumper.csv]
# 字段分隔符,应为单个 ASCII 字符。
separator = ','
# 引用定界符,可为单个 ASCII 字符或空字符串。
delimiter = '"'
# CSV 文件是否包含表头。
# 如果 header = true,将跳过首行。
header = true
# CSV 文件是否包含 NULL。
# 如果 not-null = true,CSV 所有列都不能解析为 NULL。
not-null = false
# 如果 not-null = false(即 CSV 可以包含 NULL),
# 为以下值的字段将会被解析为 NULL。
null = '\N'
# 是否对字段内“\“进行转义
backslash-escape = true
# 如果有行以分隔符结尾,删除尾部分隔符。
trim-last-separator = false
[tidb]
# 目标集群的信息。tidb-server 的地址,填一个即可。
host = "172.16.31.1"
port = 4000
user = "root"
password = ""
# 解析和执行 SQL 语句的默认 SQL 模式。
# sql-mode = "ONLY_FULL_GROUP_BY,NO_ENGINE_SUBSTITUTION"
# SQL 连接是否使用 TLS。可选值为:
# * "" - 如果填充了 [tidb.security] 部分,则强制使用 TLS(与 "cluster" 情况相同),否则与 "false" 情况相同
# * "false" - 禁用 TLS
# * "cluster" - 强制使用 TLS, 并使用 [tidb.security] 部分中指定的 CA 验证服务器的证书
# * "skip-verify" - 强制使用 TLS, 但不验证服务器的证书(不安全!)
# * "preferred" - 与 "skip-verify" 相同,但是如果服务器不支持 TLS,则会退回到未加密的连接
tls = ""
# 指定证书和密钥用于 TLS 连接 MySQL。
# [tidb.security]
# CA 的公钥证书。设置为空字符串可禁用 SQL 的 TLS。
# ca-path = "/path/to/ca.pem"
# 该服务的公钥证书。默认为 `security.cert-path` 的副本
# cert-path = "/path/to/lightning.pem"
# 此服务的私钥。默认为 `security.key-path` 的副本
# key-path = "/path/to/lightning.key"
# 设置周期性后台操作。
# 支持的单位:h(时)、m(分)、s(秒)。
[cron]
# 在日志中打印导入进度的持续时间。
log-progress = "5m"