TiDB-Lightning 使用及错误解决 -- 中国DBA社区

TiDB-Lightning 使用及错误解决
TiDB-Lightning 是一个将全量数据高速导入到 TiDB 集群的工具，有以下两个主要的使用场景：一是大量新数据的快速导入；二是全量数据的备份恢复。目前，支持 mydumper 输出格式的数据源,
参考官方文档链接：https://pingcap.com/docs-cn/tools/lightning/deployment/

手动部署TiDB-Lightning

第 1步：下载 TiDB-Lightning 安装包

通过以下链接获取 TiDB-Lightning 安装包（需选择与集群相同的版本）：

v2.1.2: https://download.pingcap.org/tidb-lightning-v2.1.2-linux-amd64.tar.gz
v2.0.9: https://download.pingcap.org/tidb-lightning-v2.0.9-linux-amd64.tar.gz
最新 master 版本: https://download.pingcap.org/tidb-lightning-latest-amd64.tar.gz

第 2步：启动 `tikv-importer`

从安装包上传 bin/tikv-importer。
配置 tikv-importer.toml。

# TiKV Importer 配置文件模版

# 日志文件。
log-file = "tikv-importer.log"
# 日志等级：trace、debug、info、warn、error、off。
log-level = "info"

[server]
# tikv-importer 监听的地址，tidb-lightning 需要连到这个地址进行数据写入。
addr = "0.0.0.0:20170"
# gRPC 服务器的线程池大小。
grpc-concurrency = 16

[metric]
# 给 Prometheus 客户端的推送任务名称。
job = "tikv-importer"
# 给 Prometheus 客户端的推送间隔。
interval = "15s"
# Prometheus Pushgateway 地址。
address = ""

[rocksdb]
# 最大的背景任务并发数。
max-background-jobs = 32

[rocksdb.defaultcf]
# 数据在刷新到硬盘前能存于内存的容量上限。
write-buffer-size = "1GB"
# 存于内存的写入缓冲最大数量。
max-write-buffer-number = 8

# 各个压缩层级使用的算法。
# 第 0 层的算法用于压缩 KV 数据。
# 第 6 层的算法用于压缩 SST 文件。
# 第 1 至 5 层的算法目前忽略。
compression-per-level = ["lz4", "no", "no", "no", "no", "no", "zstd"]

[import]
# 存储引擎文档 (engine file) 的文件夹路径。
import-dir = "/data/tidb/deploy_tidb/data.import/"
# 处理 gRPC 请求的线程数量。
num-threads = 16
# 导入任务并发数。
num-import-jobs = 24
# 预处理 Region 最长时间。
#max-prepare-duration = "5m"
# 把要导入的数据切分为这个大小的 Region。
#region-split-size = "96MB"
# 流管道窗口大小，管道满时会阻塞流。
#stream-channel-window = 128
# 引擎文档同时打开的最大数量。
max-open-engines = 8

运行 tikv-importer。

nohup ./tikv-importer -C tikv-importer.toml > nohup.out &

第 3 步：启动 `tidb-lightning`

从安装包上传 bin/tidb-lightning 及 bin/tidb-lightning-ctl。
将 mydumper SQL dump 数据源写入到同样的机器。
配置 tidb-lightning.toml。

# TiKV Importer 配置文件模版

# 日志文件。
log-file = "tikv-importer.log"
# 日志等级：trace、debug、info、warn、error、off。
log-level = "info"

[server]
# tikv-importer 监听的地址，tidb-lightning 需要连到这个地址进行数据写入。
addr = "0.0.0.0:20170"
# gRPC 服务器的线程池大小。
grpc-concurrency = 16

[metric]
# 给 Prometheus 客户端的推送任务名称。
job = "tikv-importer"
# 给 Prometheus 客户端的推送间隔。
interval = "15s"
# Prometheus Pushgateway 地址。
address = ""

[rocksdb]
# 最大的背景任务并发数。
max-background-jobs = 32

[rocksdb.defaultcf]
# 数据在刷新到硬盘前能存于内存的容量上限。
write-buffer-size = "1GB"
# 存于内存的写入缓冲最大数量。
max-write-buffer-number = 8

# 各个压缩层级使用的算法。
# 第 0 层的算法用于压缩 KV 数据。
# 第 6 层的算法用于压缩 SST 文件。
# 第 1 至 5 层的算法目前忽略。
compression-per-level = ["lz4", "no", "no", "no", "no", "no", "zstd"]

[import]
# 存储引擎文档 (engine file) 的文件夹路径。
import-dir = "/data/tidb/deploy_tidb/data.import/"
# 处理 gRPC 请求的线程数量。
num-threads = 16
# 导入任务并发数。
num-import-jobs = 24
# 预处理 Region 最长时间。
#max-prepare-duration = "5m"
# 把要导入的数据切分为这个大小的 Region。
#region-split-size = "96MB"
# 流管道窗口大小，管道满时会阻塞流。
#stream-channel-window = 128
# 引擎文档同时打开的最大数量。
max-open-engines = 8

[tidb@ip-172-16-30-86 bin]$ 
[tidb@ip-172-16-30-86 bin]$ 
[tidb@ip-172-16-30-86 bin]$ cat tidb-lightning.toml 
# TiDB-Lightning 配置文件模版

[lightning]
# 用于调试和 Prometheus 监控的 HTTP 端口。输入 0 关闭。
pprof-port = 10089

# 开始导入前先检查集群版本是否支持。
#check-requirements = true

# 控制同时处理的表的数量。这个值会影响 tikv-importer 的内存使用量。
# 不能超过 tikv-importer 中 max-open-engines 的值。
table-concurrency = 8

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

# 最大的 I/O 并发数。I/O 并发量太高时，会因硬盘内部缓存频繁被刷新而增加 I/O 等待时间，
# 导致缓存未命中和降低读取速度。因应不同的存储介质，此参数可能需要调整以达到最佳效率。
io-concurrency = 5

# 日志
level = "info"
file = "tidb-lightning.log"
max-size = 128 # MB
max-days = 28
max-backups = 14

[checkpoint]
# 启用断点续传。
# 导入时，Lightning 会记录当前进度。
# 若 Lightning 或其他组件异常退出，在重启时可以避免重复再导入已完成的数据。
enable =true
# 存储断点的数据库名称。
schema = "tidb_lightning_checkpoint"
# 存储断点的方式
#  - file：存放在本地文件系统（要求 v2.1.1 或以上）
#  - mysql：存放在兼容 MySQL 的数据库服务器
driver = "file"
# 断点的存放位置
# 若 driver = "file"，此参数为断点信息存放的文件路径。
# 如果不设置改参数则默认为“/tmp/CHECKPOINT_SCHEMA.pb”。
# 若 driver = "mysql"，此参数为数据库连接参数 (DSN)，格式为“用户:密码@tcp(地址:端口)/”。
# 默认会重用 [tidb] 设置目标数据库来存储断点。
# 为避免加重目标集群的压力，建议另外使用一个兼容 MySQL 的数据库服务器。
dsn = "/tmp/tidb_lightning_checkpoint.pb"
# 导入成功后是否保留断点。默认为删除。
# 保留断点可用于调试，但有可能泄漏数据源的元数据。
# keep-after-success = false

[tikv-importer]
# tikv-importer 的监听地址，需改成 tikv-importer 服务器的实际地址。
addr = "172.16.30.86:20170"

[mydumper]
# 文件读取区块大小。
read-block-size = 65536 # 字节 (默认 = 64 KB)
# mydumper 源数据目录。
data-source-dir = "/data2/wentaojin/backup/bike/"
# 如果 no-schema 设置为 true，tidb-lightning 将直接去 tidb-server 获取表结构信息，
# 而不是根据 data-source-dir 的 schema 文件来创建库/表，
# 适用于手动创建表或者 TiDB 本来就有表结构的情况。
no-schema = false
# 指定包含 CREATE TABLE 语句的表结构文件的字符集。只支持下列选项：
#  - utf8mb4：表结构文件必须使用 UTF-8 编码，否则 Lightning 会报错
#  - gb18030：表结构文件必须使用 GB-18030 编码，否则 Lightning 会报错
#  - auto：（默认）自动判断文件编码是 UTF-8 还是 GB-18030，两者皆非则会报错
#  - binary：不尝试转换编码
# 注意，此参数不影响 Lightning 读取数据文件。
character-set = "auto"

[tidb]
# 目标集群的信息。tidb-server 的监听地址，填一个即可。
host = "172.16.30.86"
port = 5000
user = "root"
password = ""
# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10086
# pd-server 的监听地址，填一个即可。
pd-addr = "172.16.30.88:2479"
# tidb-lightning 引用了 TiDB 库，而它自己会产生一些日志。此设置控制 TiDB 库的日志等级。
log-level = "error"

# 设置 TiDB 会话变量，提升 CHECKSUM 和 ANALYZE 的速度。各参数定义可参阅
# https://pingcap.com/docs-cn/sql/statistics/#%E6%8E%A7%E5%88%B6-analyze-%E5%B9%B6%E5%8F%91%E5%BA%A6
build-stats-concurrency = 20
distsql-scan-concurrency = 100
index-serial-scan-concurrency = 20
checksum-table-concurrency = 16

# 导完数据以后可以自动进行校验和 (CHECKSUM)、压缩 (Compact) 和分析 (ANALYZE) 的操作。
# 生产环境建议都设为 true
# 执行顺序是: CHECKSUM -> ANALYZE。
[post-restore]
# 如果设置为 true，会对每个表逐个做 `ADMIN CHECKSUM TABLE <table>` 操作。
checksum = true
# 如果设置为 true，会对所有数据做一次全量 Compact。
compact = true
# 如果设置为 true，会对每个表逐个做 `ANALYZE TABLE <table>` 操作。
analyze = true

# 设置背景周期性动作。
# 支持的单位：h（时）、m（分）、s（秒）。
[cron]
# Lightning 自动刷新导入模式周期。需要比 TiKV 对应的设定值短。
switch-mode = "5m"
# 每经过这段时间，在日志打印当前进度。
log-progress = "5m"

# 表库过滤设置。详情见《TiDB-Lightning 表库过滤》。
# 参考表库过滤链接：https://pingcap.com/docs-cn/tools/lightning/filter/

#[black-white-list]
# ...

运行 tidb-lightning。如果直接在命令行中用 nohup 启动程序，可能会因为 SIGHUP 信号而退出，建议把 nohup 放到脚本里面，如：

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

问题错误记录解决

报错信息:
tidb-lightning.log

2019/02/22 09:46:37.946  [info] restore table schema for `bike` takes 3.328498ms
2019/02/22 09:46:37.949  [error] run cause error : Checkpoint for `bike`.`bike` has invalid status: 12
2019/02/22 09:46:37.949  [info] the whole procedure takes 11.138984ms
2019/02/22 09:46:37.949  [warning] cannot switch to Import mode: rpc error: code = Canceled desc = grpc: the client connection is closing
2019/02/22 09:46:37.949 main.go:65: [error] tidb lightning encountered error:Checkpoint for `bike`.`bike` has invalid status: 12
github.com/pingcap/tidb-lightning/lightning/restore.(*RestoreController).restoreTables
        /home/jenkins/workspace/build_tidb_lightning_2.1/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:439
github.com/pingcap/tidb-lightning/lightning/restore.(*RestoreController).restoreTables-fm
        /home/jenkins/workspace/build_tidb_lightning_2.1/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:204
github.com/pingcap/tidb-lightning/lightning/restore.(*RestoreController).Run
        /home/jenkins/workspace/build_tidb_lightning_2.1/go/src/github.com/pingcap/tidb-lightning/lightning/restore/restore.go:213
github.com/pingcap/tidb-lightning/lightning.(*Lightning).run
        /home/jenkins/workspace/build_tidb_lightning_2.1/go/src/github.com/pingcap/tidb-lightning/lightning/lightning.go:132
github.com/pingcap/tidb-lightning/lightning.(*Lightning).Run.func2
        /home/jenkins/workspace/build_tidb_lightning_2.1/go/src/github.com/pingcap/tidb-lightning/lightning/lightning.go:83
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1333

主要是手动部署TiDB-Lightning下，因为当前官方推荐配置文件tidb-lightning.toml，默认开启断点续传但是断点续传位置dsn又被默认注释，

[checkpoint]
# 启用断点续传。
# 导入时，Lightning 会记录当前进度。
# 若 Lightning 或其他组件异常退出，在重启时可以避免重复再导入已完成的数据。
enable = true
# 存储断点的数据库名称。
schema = "tidb_lightning_checkpoint"
# 存储断点的方式
#  - file：存放在本地文件系统（要求 v2.1.1 或以上）
#  - mysql：存放在兼容 MySQL 的数据库服务器
driver = "file"
# 断点的存放位置
# 若 driver = "file"，此参数为断点信息存放的文件路径。
# 如果不设置改参数则默认为“/tmp/CHECKPOINT_SCHEMA.pb”。
# 若 driver = "mysql"，此参数为数据库连接参数 (DSN)，格式为“用户:密码@tcp(地址:端口)/”。
# 默认会重用 [tidb] 设置目标数据库来存储断点。
# 为避免加重目标集群的压力，建议另外使用一个兼容 MySQL 的数据库服务器。
#dsn = "/tmp/tidb_lightning_checkpoint.pb"
# 导入成功后是否保留断点。默认为删除。
# 保留断点可用于调试，但有可能泄漏数据源的元数据。
# keep-after-success = false

在不仔细查看得情况下直接执行，若中途出现回复报错，再次开启tidb-lightning读取断点位置无法读取，造成无效状态。

解决方法推荐第二种：

1、修改配置文件，不启用断点续传

[checkpoint]
# 启用断点续传。
# 导入时，Lightning 会记录当前进度。
# 若 Lightning 或其他组件异常退出，在重启时可以避免重复再导入已完成的数据。
enable =false

成功导入:
2019/02/22 10:00:15.229  [info] [`bike`.`bike`:0] restore chunk #0 (/data2/wentaojin/backup/bike/bike.bike.000000002.sql:0) takes 22.330870937s (read: 392.825074ms, encode: 21.798905522s, deliver: 1.15648904s)
2019/02/22 10:00:15.232  [info] [`bike`.`bike`:0] restore chunk #2 (/data2/wentaojin/backup/bike/bike.bike.000000004.sql:0) takes 22.336799588s (read: 394.088023ms, encode: 21.805427634s, deliver: 1.123465823s)
2019/02/22 10:00:15.235  [info] [`bike`.`bike`:0] restore chunk #8 (/data2/wentaojin/backup/bike/bike.bike.000000010.sql:0) takes 22.338351668s (read: 391.600553ms, encode: 21.808404794s, deliver: 1.145327223s)
2019/02/22 10:00:15.251  [info] [`bike`.`bike`:0] restore chunk #13 (/data2/wentaojin/backup/bike/bike.bike.000000015.sql:0) takes 22.349300383s (read: 393.129719ms, encode: 21.815387911s, deliver: 1.13406167s)
2019/02/22 10:00:15.254  [info] [`bike`.`bike`:0] restore chunk #6 (/data2/wentaojin/backup/bike/bike.bike.000000008.sql:0) takes 22.356748605s (read: 389.869014ms, encode: 21.828803596s, deliver: 1.142422067s)
2019/02/22 10:00:15.280  [info] [`bike`.`bike`:0] restore chunk #1 (/data2/wentaojin/backup/bike/bike.bike.000000003.sql:0) takes 22.385562126s (read: 387.617156ms, encode: 21.857417181s, deliver: 1.153295672s)
2019/02/22 10:00:15.298  [info] [`bike`.`bike`:0] restore chunk #5 (/data2/wentaojin/backup/bike/bike.bike.000000007.sql:0) takes 22.402268254s (read: 389.270434ms, encode: 21.871621813s, deliver: 1.132437489s)
2019/02/22 10:00:15.334  [info] [`bike`.`bike`:0] restore chunk #15 (/data2/wentaojin/backup/bike/bike.bike.00001.sql:0) takes 22.431887064s (read: 393.794082ms, encode: 21.896185354s, deliver: 1.195354409s)
2019/02/22 10:00:15.334  [info] [`bike`.`bike`:0] encode kv data and write takes 22.468570871s (read 1009631881, written 958615688)
2019/02/22 10:00:15.334  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] engine close
2019/02/22 10:00:22.460  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] engine close takes 7.126134253s
2019/02/22 10:00:22.460  [info] [`bike`.`bike`] flush kv deliver ...
2019/02/22 10:00:22.460  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] import

2019/02/22 10:00:26.191  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] import takes 3.730784142s
2019/02/22 10:00:26.191  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] cleanup 
2019/02/22 10:00:26.247  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] cleanup takes 56.354443ms
2019/02/22 10:00:26.247  [info] [`bike`.`bike`] kv deliver all flushed, takes 3.787301559s
2019/02/22 10:00:26.247  [info] [`bike`.`bike`] import whole table takes 33.382197161s
2019/02/22 10:00:26.247  [info] compact level 1
2019/02/22 10:00:26.248  [info] [bike.bike] ALTER TABLE `bike`.`bike` AUTO_INCREMENT=84135986
2019/02/22 10:00:26.341  [info] [`bike`.`bike`] alter table set auto_id takes 92.982463ms
2019/02/22 10:00:26.348  [info] [`bike`.`bike`] doing remote checksum
2019/02/22 10:00:27.172  [info] compact level 1 takes 924.654605ms
2019/02/22 10:00:43.184  [info] [`bike`.`bike`] do checksum takes 16.84252726s
2019/02/22 10:00:43.191  [info] [`bike`.`bike`] checksum pass, {bytes:958615688 kvs:7091773 checksum:1073236364365082331} takes 16.84928962s
2019/02/22 10:00:43.191  [info] [`bike`.`bike`] analyze
2019/02/22 10:00:51.447  [info] [`bike`.`bike`] analyze takes 8.256530875s
2019/02/22 10:00:51.447  [info] restore all tables data takes 58.690695451s
2019/02/22 10:00:51.447 restore.go:751: [info] Wait for existing level 1 compaction to finish
2019/02/22 10:00:51.447  [info] Wait for existing level 1 compaction to finish takes 199ns
2019/02/22 10:00:51.447  [info] compact level -1
2019/02/22 10:00:51.447 restore.go:373: [info] Everything imported, stopping periodic actions
2019/02/22 10:01:01.124  [info] compact level -1 takes 9.676654663s
2019/02/22 10:01:01.142  [info] switch to tikv Normal mode takes 17.917028ms
2019/02/22 10:01:01.142 restore.go:897: [info] Skip clean checkpoints.
2019/02/22 10:01:01.142  [info] the whole procedure takes 1m8.394477982s
2019/02/22 10:01:01.142 main.go:69: [info] tidb lightning exit.
mysql> use bike;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select count(*) from bike;
+----------+
| count(*) |
+----------+
|  7091773 |
+----------+
1 row in set (0.99 sec)

2、启动配置文件断点续传位置（位置自定义)，并清除所有断点

启用断点位置
dsn = "/tmp/tidb_lightning_checkpoint.pb"
清除所有断点
$./tidb-lightning-ctl --checkpoint-remove=all

重新跑tidb-lightning回复即可
, deliver: 1.140056653s)
2019/02/22 10:09:53.984  [info] [`bike`.`bike`:0] encode kv data and write takes 22.655380069s (read 1009631881, written 958615688)
2019/02/22 10:09:53.984  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] engine close
2019/02/22 10:10:00.908  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] engine close takes 6.923744006s
2019/02/22 10:10:00.908  [info] [`bike`.`bike`] flush kv deliver ...
2019/02/22 10:10:00.908  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] import
2019/02/22 10:10:04.434  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] import takes 3.526694642s
2019/02/22 10:10:04.434  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] cleanup 
2019/02/22 10:10:04.486  [info] [`bike`.`bike`:0] [ee90d451-63c0-5f29-ae9f-8c36edf37980] cleanup takes 51.919546ms
2019/02/22 10:10:04.486  [info] [`bike`.`bike`] kv deliver all flushed, takes 3.578760729s
2019/02/22 10:10:04.486  [info] [`bike`.`bike`] import whole table takes 33.158151648s
2019/02/22 10:10:04.486  [info] compact level 1
2019/02/22 10:10:04.487  [info] [bike.bike] ALTER TABLE `bike`.`bike` AUTO_INCREMENT=84135986
2019/02/22 10:10:04.570  [info] [`bike`.`bike`] alter table set auto_id takes 82.899463ms
2019/02/22 10:10:04.578  [info] [`bike`.`bike`] doing remote checksum
2019/02/22 10:10:04.824  [info] compact level 1 takes 337.671399ms
2019/02/22 10:10:21.655  [info] [`bike`.`bike`] do checksum takes 17.084264154s
2019/02/22 10:10:21.661  [info] [`bike`.`bike`] checksum pass, {bytes:958615688 kvs:7091773 checksum:9170025477633009657} takes 17.090882838s
2019/02/22 10:10:21.661  [info] [`bike`.`bike`] analyze
2019/02/22 10:10:31.934  [info] [`bike`.`bike`] analyze takes 10.272878735s
2019/02/22 10:10:31.934  [info] restore all tables data takes 1m0.724062296s
2019/02/22 10:10:31.934 restore.go:751: [info] Wait for existing level 1 compaction to finish
2019/02/22 10:10:31.934  [info] Wait for existing level 1 compaction to finish takes 131ns
2019/02/22 10:10:31.934  [info] compact level -1
2019/02/22 10:10:31.934 restore.go:373: [info] Everything imported, stopping periodic actions
2019/02/22 10:10:33.380  [info] compact level -1 takes 1.445835173s
2019/02/22 10:10:33.397  [info] switch to tikv Normal mode takes 16.280657ms
2019/02/22 10:10:33.397  [info] clean checkpoints takes 73.531µs
2019/02/22 10:10:33.397  [info] the whole procedure takes 1m2.195467259s
2019/02/22 10:10:33.397 main.go:69: [info] tidb lightning exit.


mysql> use bike;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select count(*) from bike;
+----------+
| count(*) |
+----------+
|  7091773 |
+----------+
1 row in set (0.99 sec)

签到成功

CNDBA社区

TiDB-Lightning 使用及错误解决

手动部署TiDB-Lightning

第 1步：下载 TiDB-Lightning 安装包

第 2步：启动 `tikv-importer`

第 3 步：启动 `tidb-lightning`

问题错误记录解决

Marvinn

QQ交流群

注册联系QQ

签到成功

CNDBA社区

TiDB-Lightning 使用及错误解决

手动部署TiDB-Lightning

第 1步：下载 TiDB-Lightning 安装包

第 2步：启动 tikv-importer

第 3 步：启动 tidb-lightning

问题错误记录解决

Marvinn

QQ交流群

注册联系QQ

第 2步：启动 `tikv-importer`

第 3 步：启动 `tidb-lightning`