一、背景

进行某些数据迁移的时候，用dumpling做备份，用lighting做恢复，因为时常用到，所以做个记录

二、使用方法

1.下载

wget https://download.pingcap.org/tidb-toolkit-{version}-linux-amd64.tar.gz
# https://download.pingcap.org/tidb-toolkit-v5.1.0-linux-amd64.tar.gz

2.配置文件

2.1 示例配置文件

vim lighting.toml

[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"[tikv-importer]
# 选择使用的 local 后端
backend = "local"
# 设置排序的键值对的临时存放地址，目标路径需要是一个空目录
sorted-kv-dir = "/mnt/ssd/sorted-kv-dir"[mydumper]
# 源数据目录。
data-source-dir = "/data/my_datasource/"# 配置通配符规则，默认规则会过滤 mysql、sys、INFORMATION_SCHEMA、PERFORMANCE_SCHEMA、METRICS_SCHEMA、INSPECTION_SCHEMA 系统数据库下的所有表
# 若不配置该项，导入系统表时会出现“找不到 schema”的异常
filter = ['*.*', '!mysql.*', '!sys.*', '!INFORMATION_SCHEMA.*', '!PERFORMANCE_SCHEMA.*', '!METRICS_SCHEMA.*', '!INSPECTION_SCHEMA.*']
[tidb]
# 目标集群的信息
host = "**********"
port = 4000
user = "root"
password = "rootroot"
# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10080
# 集群 pd 的地址
pd-addr = "172.16.31.3:2379"

2.2 详解

TiDB Lightning 全局配置

### tidb-lightning 全局配置[lightning]
# 用于拉取 web 界面和 Prometheus 监控项的 HTTP 端口。设置为 0 时为禁用状态。
status-addr = ':8289'# 切换为服务器模式并使用 web 界面
# 详情参见“TiDB Lightning web 界面”文档
server-mode = false# 日志
level = "info"
file = "tidb-lightning.log"
max-size = 128 # MB
max-days = 28
max-backups = 14

TiDB Lightning 任务配置

### tidb-lightning 任务配置[lightning]
# 启动之前检查集群是否满足最低需求。
# check-requirements = true# 引擎文件的最大并行数。
# 每张表被切分成一个用于存储索引的“索引引擎”和若干存储行数据的“数据引擎”。
# 这两项设置控制两种引擎文件的最大并发数。
# 这两项设置的值会影响 tikv-importer 的内存和磁盘用量。
# 两项数值之和不能超过 tikv-importer 的 max-open-engines 的设定。
index-concurrency = 2
table-concurrency = 6# 数据的并发数。默认与逻辑 CPU 的数量相同。
# 混合部署的情况下可以将其大小配置为逻辑 CPU 数的 75%，以限制 CPU 的使用。
# region-concurrency =# I/O 最大并发数。I/O 并发量太高时，会因硬盘内部缓存频繁被刷新
# 而增加 I/O 等待时间，导致缓存未命中和读取速度降低。
# 对于不同的存储介质，此参数可能需要调整以达到最佳效率。
io-concurrency = 5[security]
# 指定集群中用于 TLS 连接的证书和密钥。
# CA 的公钥证书。如果留空，则禁用 TLS。
# ca-path = "/path/to/ca.pem"
# 此服务的公钥证书。
# cert-path = "/path/to/lightning.pem"
# 该服务的密钥。
# key-path = "/path/to/lightning.key"[checkpoint]
# 是否启用断点续传。
# 导入数据时，TiDB Lightning 会记录当前表导入的进度。
# 所以即使 TiDB Lightning 或其他组件异常退出，在重启时也可以避免重复再导入已完成的数据。
enable = true
# 存储断点的数据库名称。
schema = "tidb_lightning_checkpoint"
# 存储断点的方式。
#  - file：存放在本地文件系统。
#  - mysql：存放在兼容 MySQL 的数据库服务器。
driver = "file"# dsn 是数据源名称 (data source name)，表示断点的存放位置。
# 若 driver = "file"，则 dsn 为断点信息存放的文件路径。
#若不设置该路径，则默认存储路径为“/tmp/CHECKPOINT_SCHEMA.pb”。
# 若 driver = "mysql"，则 dsn 为“用户:密码@tcp(地址:端口)/”格式的 URL。
# 若不设置该 URL，则默认会使用 [tidb] 部分指定的 TiDB 服务器来存储断点。
# 为减少目标 TiDB 集群的压力，建议指定另一台兼容 MySQL 的数据库服务器来存储断点。
# dsn = "/tmp/tidb_lightning_checkpoint.pb"# 所有数据导入成功后是否保留断点。设置为 false 时为删除断点。
# 保留断点有利于进行调试，但会泄漏关于数据源的元数据。
# keep-after-success = false[tikv-importer]
# 选择后端：“importer” 或 “local” 或 “tidb”
# backend = "importer"
# 当后端是 “importer” 时，tikv-importer 的监听地址（需改为实际地址）。
addr = "172.16.31.10:8287"
# 当后端是 “tidb” 时，插入重复数据时执行的操作。
# - replace：新数据替代已有数据
# - ignore：保留已有数据，忽略新数据
# - error：中止导入并报错
# on-duplicate = "replace"
# 当后端是 “local” 时，控制生成 SST 文件的大小，最好跟 TiKV 里面的 Region 大小保持一致，默认是 96 MB。
# region-split-size = 100_663_296
# 当后端是 “local” 时，一次请求中发送的 KV 数量。
# send-kv-pairs = 32768
# 当后端是 “local” 时，本地进行 KV 排序的路径。如果磁盘性能较低（如使用机械盘），建议设置成与 `data-source-dir` 不同的磁盘，这样可有效提升导入性能。
# sorted-kv-dir = ""
# 当后端是 “local” 时，TiKV 写入 KV 数据的并发度。当 TiDB Lightning 和 TiKV 直接网络传输速度超过万兆的时候，可以适当增加这个值。
# range-concurrency = 16[mydumper]
# 设置文件读取的区块大小，确保该值比数据源的最长字符串长。
read-block-size = 65536 # Byte (默认为 64 KB)# （源数据文件）单个导入区块大小的最小值。
# TiDB Lightning 根据该值将一张大表分割为多个数据引擎文件。
# batch-size = 107_374_182_400 # Byte (默认为 100 GB)# 引擎文件需按顺序导入。由于并行处理，多个数据引擎几乎在同时被导入，
# 这样形成的处理队列会造成资源浪费。因此，为了合理分配资源，TiDB Lightning
# 稍微增大了前几个区块的大小。该参数也决定了比例系数，即在完全并发下
# “导入”和“写入”过程的持续时间比。这个值可以通过计算 1 GB 大小的
# 单张表的（导入时长/写入时长）得到。在日志文件中可以看到精确的时间。
# 如果“导入”更快，区块大小的差异就会更小；比值为 0 时则说明区块大小一致。
# 取值范围为（0 <= batch-import-ratio < 1）。
batch-import-ratio = 0.75# 本地源数据目录或外部存储 URL
data-source-dir = "/data/my_database"
# 如果 no-schema = true，那么 TiDB Lightning 假设目标 TiDB 集群上
# 已有表结构，并且不会执行 `CREATE TABLE` 语句。
no-schema = false
# 指定包含 `CREATE TABLE` 语句的表结构文件的字符集。只支持下列选项：
#  - utf8mb4：表结构文件必须使用 UTF-8 编码，否则会报错。
#  - gb18030：表结构文件必须使用 GB-18030 编码，否则会报错。
#  - auto：自动判断文件编码是 UTF-8 还是 GB-18030，两者皆非则会报错（默认）。
#  - binary：不尝试转换编码。
# 注意：**数据** 文件始终解析为 binary 文件。
character-set = "auto"# “严格”格式的导入数据可加快处理速度。
# 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 = 268_435_456 # Byte（默认是 256 MB）# 只导入与该通配符规则相匹配的表。详情见相应章节。
filter = ['*.*']# 配置 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 = ""
# 表结构信息从 TiDB 的“status-port”获取。
status-port = 10080
# pd-server 的地址，填一个即可。
pd-addr = "172.16.31.4:2379"
# tidb-lightning 引用了 TiDB 库，并生成产生一些日志。
# 设置 TiDB 库的日志等级。
log-level = "error"# 设置 TiDB 会话变量，提升 Checksum 和 Analyze 的速度。
# 各参数定义可参阅”控制 Analyze 并发度“文档
build-stats-concurrency = 20
distsql-scan-concurrency = 100
index-serial-scan-concurrency = 20
checksum-table-concurrency = 16# 解析和执行 SQL 语句的默认 SQL 模式。
sql-mode = "ONLY_FULL_GROUP_BY,NO_ENGINE_SUBSTITUTION"
# `max-allowed-packet` 设置数据库连接允许的最大数据包大小，
# 对应于系统参数中的 `max_allowed_packet`。 如果设置为 0，
# 会使用下游数据库 global 级别的 `max_allowed_packet`。
max-allowed-packet = 67_108_864# SQL 连接是否使用 TLS。可选值为：
#  * ""            - 如果填充了 [tidb.security] 部分，则强制使用 TLS（与 "cluster" 情况相同），否则与 "false" 情况相同
#  * "false"       - 禁用 TLS
#  * "cluster"     - 强制使用 TLS 并使用 [tidb.security] 部分中指定的 CA 验证服务器的证书
#  * "skip-verify" - 强制使用 TLS，但不验证服务器的证书（不安全！）
#  * "preferred"   - 与 "skip-verify" 相同，但是如果服务器不支持 TLS，则会退回到未加密的连接
# tls = ""
# 指定证书和密钥用于 TLS 连接 MySQL。
# 默认为 [security] 部分的副本。
# [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"# 数据导入完成后，tidb-lightning 可以自动执行 Checksum、Compact 和 Analyze 操作。
# 在生产环境中，建议这将些参数都设为 true。
# 执行的顺序为：Checksum -> Compact -> Analyze。
[post-restore]
# 如果设置为 true，会对所有表逐个执行 `ADMIN CHECKSUM TABLE <table>` 操作
# 来验证数据的完整性。
checksum = true
# 如果设置为 true，会在导入每张表后执行一次 level-1 Compact。
# 默认值为 false。
level-1-compact = false
# 如果设置为 true，会在导入过程结束时对整个 TiKV 集群执行一次 full Compact。
# 默认值为 false。
compact = false
# 如果设置为 true，会对所有表逐个执行 `ANALYZE TABLE <table>` 操作。
analyze = true# 设置周期性后台操作。
# 支持的单位：h（时）、m（分）、s（秒）。
[cron]
# TiDB Lightning 自动刷新导入模式状态的持续时间，该值应小于 TiKV 对应的设定值。
switch-mode = "5m"
# 在日志中打印导入进度的持续时间。
log-progress = "5m"

TiKV Importer 配置参数

# TiKV Importer 配置文件模版# 日志文件
log-file = "tikv-importer.log"
# 日志等级：trace, debug, info, warn, error 和 off
log-level = "info"# 状态服务器的监听地址。
# Prometheus 可以从这个地址抓取监控指标。
status-server-address = "0.0.0.0:8286"[server]
# tikv-importer 的监听地址，tidb-lightning 需要连到这个地址进行数据写入。
addr = "0.0.0.0:8287"
# gRPC 服务器的线程池大小。
grpc-concurrency = 16[metric]
# 当使用 Prometheus Pushgateway 时会涉及相关设置。通常可以通过 Prometheus 从 状态服务器地址中抓取指标。
# 给 Prometheus 客户端推送的 job 名称。
job = "tikv-importer"
# 给 Prometheus 客户端推送的间隔。
interval = "15s"
# Prometheus Pushgateway 的地址。
address = ""[rocksdb]
# background job 的最大并发数。
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", "lz4"][rocksdb.writecf]
# 同上
compression-per-level = ["lz4", "no", "no", "no", "no", "no", "lz4"][security]
# TLS 证书的路径。空字符串表示禁用安全连接。
# ca-path = ""
# cert-path = ""
# key-path = ""[import]
# 存储引擎文件的文件夹路径
import-dir = "/mnt/ssd/data.import/"
# 处理 RPC 请求的线程数
num-threads = 16
# 导入 job 的并发数。
num-import-jobs = 24
# 预处理 Region 最长时间。
# max-prepare-duration = "5m"
# 把要导入的数据切分为这个大小的 Region。
#region-split-size = "512MB"
# 设置 stream-channel-window 的大小。
# channel 满了之后 stream 会处于阻塞状态。
# stream-channel-window = 128
# 同时打开引擎文档的最大数量。
max-open-engines = 8
# Importer 上传至 TiKV 的最大速度（字节/秒）。
# upload-speed-limit = "512MB"
# 目标存储可用空间比率（store_available_space/store_capacity）的最小值。
# 如果目标存储空间的可用比率低于该值，Importer 将会暂停上传 SST
# 来为 PD 提供足够时间进行 Regions 负载均衡。
min-available-ratio = 0.05

三、问题及实际应用场景

1.对于utf8mb4_general_ci的处理

所用配置文件： 示例配置文件即可
问题详情： 因为用dumpling导出的数据，有时候建表语句只有DEFAULT CHARSET=utf8mb4，这样会使原本的utf8mb4_general_ci字符集变成默认的utf8mb4_bin字符集，另外，原来的建表语句也会存在一些tidb不支持的字符集
处理方式： 进入到dumpling导出数据的目录，执行如下命令

sed -i "s/DEFAULT CHARSET=utf8mb4//g" *schema.sql
sed -i "s/DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci//g" *schema.sql
sed -i "s/COLLATE utf8_unicode_ci//g" *schema.sql

2.导入数据时因意外中断

所用配置文件： 示例配置文件即可
问题详情： 导入数据时因为意外中断，重启时断点不可恢复，导入数据出现时自动退出
处理方式：
2.1 将导入模式变为普通模式

bin/tidb-lightning-ctl -config ./lighting.toml --switch-mode=normal

2.2 清除目标库的表数据，清除断点信息

tidb-lightning-ctl -config ./lighting.toml --checkpoint-error-destroy='`schema`.`table`'
# 可以指定库表，=all则全部清除

到此基本就可以解决，可以重新导入数据了

2.3 附加的几条额外命令

# 清除出错状态，尽量不要使用
--checkpoint-error-ignore
# 清除表的断点
--checkpoint-remove
# 将所有断点备份到传入的文件夹，主要用于技术支持。此选项仅于 driver = "mysql" 时有效
--checkpoint-dump
校验导入数据是否正确
ADMIN CHECKSUM TABLE `schema`.`table`;

3.有选择的恢复表

3.1 命令行

./tidb-lightning -f 'foo*.*' -f 'bar*.*'

3.2 配置文件

[mydumper]
filter = ['foo*.*', 'bar*.*']

4.后端模式

Importer-backend： tidb-lightning 先将 SQL 或 CSV 数据编码成键值对，由 tikv-importer 对写入的键值对进行排序，然后把这些键值对 Ingest 到 TiKV 节点中。
配置：

[tikv-importer]
backend = "tidb"
on-duplicate = "replace" # 或者 “error”、“ignore”

Local-backend： tidb-lightning 先将数据编码成键值对并排序存储在本地临时目录，然后将这些键值对以 SST 文件的形式上传到各个 TiKV 节点，然后由 TiKV 将这些 SST 文件 Ingest 到集群中。和 Importer-backend 原理相同，不过不依赖额外的 tikv-importer 组件。
配置：

[tikv-importer]
backend = "tidb"
on-duplicate = "replace" # 或者 “error”、“ignore”

TiDB-backend： tidb-lightning 先将数据编码成 INSERT 语句，然后直接在 TiDB 节点上运行这些 SQL 语句进行数据导入。
配置：

[tikv-importer]
backend = "tidb"
on-duplicate = "replace" # 或者 “error”、“ignore”

5.csv文件导入

文件名： db_name.table_name.csv
如果一个表分布于多个 CSV 文件，这些 CSV 文件命名需加上文件编号的后缀，如 db_name.table_name.003.csv。数字部分不需要连续但必须递增，并用零填充。文件扩展名必须为 *.csv，即使文件的内容并非逗号分隔。

表结构：
CSV 文件是没有表结构的。要导入 TiDB，就必须为其提供表结构。可以通过以下任一方法实现：
1.创建包含 DDL 语句 CREATE TABLE 的文件 db_name.table_name-schema.sql 以及包含 CREATE DATABASE DDL 语句的文件 db_name-schema-create.sql。

2.首先在 TiDB 中直接创建空表，然后在 tidb-lightning.toml 中设置 [mydumper] no-schema = true。（个人喜欢这种方式，比较方便）

6.启动数据导入

./tidb-lightning -config lighting.toml

官网地址： https://docs.pingcap.com/zh/tidb/v4.0/tidb-lightning-overview

tidb-lightning的使用相关推荐

探索TiDB Lightning源码来解决发现的bug
背景上一篇<记一次简单的Oracle离线数据迁移至TiDB过程>说到在使用Lightning导入csv文件到TiDB的时候发现了一个bug,是这样一个过程. Oracle源库中表名都是大 ...
TiDB Lightning 故障处理
本文档总结了使用 TiDB Lightning 过程中常见的运行故障及解决方案. TiDB Lightning 导入速度太慢 TiDB Lightning 的正常速度为每条线程每 2 分钟导入一个 2 ...
TiDB Lightning 常见问题
本文列出了一些使用 TiDB Lightning 时可能会遇到的问题与答案. TiDB Lightning 对 TiDB/TiKV/PD 的最低版本要求是多少? TiDB Lightning 的版本应 ...
部署 TiDB Lightning
本文主要介绍 TiDB Lightning 进行数据导入的硬件需求,以及手动部署 TiDB Lightning 的方式.Lightning 不同的导入模式,其硬件要求有所不同,请先阅读: Physic ...
TiDB Lightning 数据源
TiDB Lightning 支持从多种类型的文件导入数据到 TiDB 集群.通过以下配置为 TiDB Lightning 指定数据文件所在位置. [mydumper] # 本地源数据目录或 S3 等 ...
TiDB Lightning 简介
TiDB Lightning 是用于从静态文件导入 TB 级数据到 TiDB 集群的工具,常用于 TiDB 集群的初始化数据导入. 要快速了解 Lightning 的基本原理和使用方法,建议先观看下面 ...
TiDB Lightning 快速上手
本教程假设使用的是若干新的.纯净版 CentOS 7 实例,你可以(使用 VMware.VirtualBox 及其他工具)在本地虚拟化或在供应商提供的平台上部署一台小型的云虚拟主机.因为 TiDB L ...
TiDB Lightning 断点续传
大量的数据导入一般耗时数小时至数天,长时间运行的进程会有一定机率发生非正常中断.如果每次重启都从头开始,就会浪费掉之前已成功导入的数据.为此,TiDB Lightning 提供了"断点续传& ...
TiDB 在知乎万亿量级业务数据下的实践和挑战
作者 | 朱小厮的博客来源 | https://mp.weixin.qq.com/s/fpWjcDGatuqUUq36K8-3Jw 一.业务场景知乎从问答起步,在过去的 8 年中逐步成长为一个大规 ...
从（知乎大量的数据上保持毫秒级的查询响应时间）上看什么是 TiDB?
我们的痛点系统架构要求勘探 MySQL Sharding 和 MHA 的缺点什么是 TiDB? 我们如何使用 TiDB 我们架构中的 TiDB TiDB 的性能指标我们学到了什么更快地导入数 ...

tidb-lightning的使用