tidb-lightning的使用，tidb lightning 多个任务

本文讲了TiDB-lightning的使用，tidb lightning 多个任务。

一、背景

进行某些数据迁移的时候，用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 的 Physical Import Mode 从 v5.3.0 版本开始支持单表或多表数据的并行导入。通过支持同步启动多个实例，并行导入不同的单表或多表的不同数据，使 TiDB Lightning 具备水平扩展的能力，可大大降低导入大量数据所需的时间。

在技术实现上，TiDB Lightning 通过在目标 TiDB 中记录各个实例以及每个导入表导入数据的元信息，协调不同实例的 Row ID 分配范围、全局 Checksum 的记录和 TiKV 及 PD 的配置变更与恢复。

TiDB Lightning 并行导入可以用于以下场景：

并行导入分库分表的数据。在该场景中，来自上游多个数据库实例中的多个表，分别由不同的 TiDB Lightning 实例并行导入到下游 TiDB 数据库中。

并行导入单表的数据。在该场景中，存放在某个目录中或云存储（如 Amazon S3）中的多个单表文件，分别由不同的 TiDB Lightning 实例并行导入到下游 TiDB 数据库中。该功能为 v5.3.0 版本引入的新功能。

注意

并行导入只支持初始化 TiDB 的空表，不支持导入数据到已有业务写入的数据表，否则可能会导致数据不一致的情况。

并行导入一般用于 local-backend 模式。

并行导入一般用于 Physical Import Mode；虽然也能用于 Logical Import Mode，但是一般不会带来明显的性能提升。

使用说明

使用 TiDB Lightning 并行导入无须额外配置。TiDB Lightning 在启动时，会在下游 TiDB 中注册元信息，并自动检测是否有其他实例向目标集群导入数据。如果有，则自动进入并行导入模式。

但是在并行导入时，需要注意以下情况：

解决主键或者唯一索引的冲突

导入性能优化

解决主键或者唯一索引的冲突

在使用 Physical Import Mode 并行导入时，需要确保多个 TiDB Lightning 的数据源之间，以及它们和 TiDB 的目标表中的数据没有主键或者唯一索引的冲突，并且导入的目标表不能有其他应用进行数据写入。否则，TiDB Lightning 将无法保证导入结果的正确性，并且导入完成后相关的数据表将处于数据索引不一致的状态。

导入性能优化

由于 TiDB Lightning 需要将生成的 Key-Value 数据上传到对应 Region 的每一个副本所在的 TiKV 节点，其导入速度受目标集群规模的限制。在通常情况下，建议确保目标 TiDB 集群中的 TiKV 实例数量与 TiDB Lightning 的实例数量大于 n:1 (n 为 Region 的副本数量)。同时，在使用 TiDB Lightning 并行导入模式时，为达到最优性能，建议进行如下限制：

每个 TiDB Lightning 部署在单独的机器上面。TiDB Lightning 默认会消耗所有的 CPU 资源，在单台机器上面部署多个实例并不能提升性能。

每个 TiDB Lightning 实例导入的源文件总大小不超过 5 TiB

TiDB Lightning 实例的总数量不超过 10 个

在使用 TiDB Lightning 并行导入分库分表数据的时候，请根据数据量大小选择使用的 TiDB Lightning 实例数量。

如果 MySQL 数据量小于 2 TiB，可以使用 1 个 TiDB Lightning 实例进行并行导入

如果 MySQL 数据量超过 2 TiB，并且 MySQL 实例总数小于 10 个，建议每个 MySQL 实例对应 1 个 TiDB Lightning 实例，而且并行 TiDB Lightning 实例数量不要超过 10 个

如果 MySQL 数据量超过 2 TiB，并且 MySQL 实例总数超过 10 个，建议这些 MySQL 实例导出的数据平均分配 5 到 10 个 TiDB Lightning 实例进行导入

接下来，本文档将以两个并行导入的示例，详细介绍了不同场景下并行导入的操作步骤：

示例 1：使用 Dumpling + TiDB Lightning 并行导入分库分表数据至 TiDB

示例 2：使用 TiDB Lightning 并行导入单表数据

使用限制

TiDB Lightning 在运行时，需要独占部分资源，因此如果需要在单台机器上面部署多个 TiDB Lightning 实例(不建议生产环境使用)或多台机器共享磁盘存储时，需要注意如下使用限制：

每个 TiDB Lightning 实例的 tikv-importer.sorted-kv-dir 必须设置为不同的路径。多个实例共享相同的路径会导致非预期的行为，可能导致导入失败或数据出错。

每个 TiDB Lightning 的 checkpoint 需要分开存储。checkpoint 的详细配置见 TiDB Lightning 断点续传。

如果设置 checkpoint.driver = "file"（默认值），需要确保每个实例设置的 checkpoint 的路径不同。

如果设置 checkpoint.driver = "mysql", 需要为每个实例设置不同的 schema。

每个 TiDB Lightning 的 log 文件应该设置为不同的路径。共享同一个 log 文件将不利于日志的查询和排查问题。

如果开启 Web 界面 或 Debug API, 需要为每个实例的 lightning.status-addr 设置不同地址，否则，TiDB Lightning 进程会由于端口冲突无法启动。

示例 1：使用 Dumpling + TiDB Lightning 并行导入分库分表数据至 TiDB

在本示例中，假设上游为包含 10 个分表的 MySQL 集群，总共大小为 10 TiB。使用 5 个 TiDB Lightning 实例并行导入，每个实例导入 2 TiB 数据，预计可以将总导入时间（不包含 Dumpling 导出的耗时）由约 40 小时降至约 10 小时。

假设上游的库名为 my_db，每个分表的名字为 my_table_01 ~ my_table_10，需要合并导入至下游的 my_db.my_table 表中。下面介绍具体的操作步骤。

第 1 步：使用 Dumpling 导出数据

在部署 TiDB Lightning 的 5 个节点上面分别导出两个分表的数据：

如果两个分表位于同一个 MySQL 实例中，可以直接使用 Dumpling 的 --filter 参数一次性导出。此时在使用 TiDB Lightning 导入时，指定 data-source-dir 为 Dumpling 数据导出的目录即可；

如果两个分表的数据分布在不同的 MySQL 节点上，则需要使用 Dumpling 分别导出，两次导出数据需要放置在同一父目录下不同子目录里，然后在使用 TiDB Lightning 导入时，data-source-dir 指定为此父级目录。

使用 Dumpling 导出数据的步骤，请参考 Dumpling。

第 2 步：配置 TiDB Lightning 的数据源

创建 tidb-lightning.toml 配置文件，并加入如下内容：

[lightning] status-addr = ":8289" [mydumper] # 设置为 Dumpling 导出数据的路径，如果 Dumpling 执行了多次并分属不同的目录，请将多次导出的数据置放在相同的父目录下并指定此父目录即可。 data-source-dir = "/path/to/source-dir" [tikv-importer] # 是否允许向已存在数据的表导入数据。默认值为 false。 # 当使用并行导入模式时，由于多个 TiDB Lightning 实例同时导入一张表，因此此开关必须设置为 true。 incremental-import = true # "local"：Physical Import Mode，默认使用。适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。 # "tidb"：Logical Import Mode。TB 级以下数据量也可以采用，下游 TiDB 可正常提供服务。 backend = "local" # 设置本地排序数据的路径 sorted-kv-dir = "/path/to/sorted-dir"

如果数据源存放在 Amazon S3 或 GCS 等外部存储中，请参考外部存储。

第 3 步：开启 TiDB Lightning 进行数据导入

在使用 TiDB Lightning 并行导入时，对每个 TiDB Lightning 节点机器配置的需求与非并行导入模式相同，每个 TiDB Lightning 节点需要消耗相同的资源，建议部署在不同的机器上。详细的部署步骤，请参考 TiDB Lightning 部署与执行

依次在每台机器上面运行 TiDB Lightning。如果直接在命令行中用 nohup 启动程序，可能会因为 SIGHUP 信号而退出，建议把 nohup 放到脚本里面，如：

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

在并行导入的场景下，TiDB Lightning 在启动任务之后，会自动进行下列检查：

检查本地盘空间（即 sort-kv-dir 配置）以及 TiKV 集群是否有足够空间导入数据，空间大小的详细说明参考 TiDB Lightning 下游数据库所需空间和 TiDB Lightning 运行时资源要求。检查时会对数据源进行采样，通过采样结果预估索引大小占比。由于估算中考虑了索引，因此可能会出现尽管数据源大小低于本地盘可用空间，但依然无法通过检测的情况。

检查 TiKV 集群的 region 分布是否均匀，以及是否存在大量空 region，如果空 region 的数量大于 max(1000, 表的数量 * 3) ，即大于 “1000” 和 “3 倍表数量”二者中的最大者，则无法执行导入。

检查数据源导入数据是否有序，并且根据检查结果自动调整 mydumper.batch-size 的大小。因此 mydumper.batch-size 配置不再对用户开放。

你也可以通过 lightning.check-requirements 配置来关闭检查，执行强制导入。更多详细检查内容，可以查看 Lightning 执行前检查项。

第 4 步：查看进度

开始导入后，可以通过以下任意方式查看进度：

通过 grep 日志关键字 progress 查看进度，默认 5 分钟更新一次。

通过监控面板查看进度。详情请参见 TiDB Lightning 监控。

等待所有的 TiDB Lightning 运行结束，则整个导入完成。

示例 2：使用 TiDB Lightning 并行导入单表数据

TiDB Lightning 也支持并行导入单表的数据。例如，将存放在 Amazon S3 中的多个单表文件，分别由不同的 TiDB Lightning 实例并行导入到下游 TiDB 数据库中。该方法可以加快整体导入速度。关于更多远端存储信息，请参考 TiDB Lightning 支持的远端存储。

注意

在本地环境下，可以使用 Dumpling 的 --filesize 或 --where 参数，预先将单表的数据划分成不同的部分导出至多台机器的本地磁盘，此时依然可以使用并行导入功能，其配置与示例 1 相同。

假设通过 Dumpling 导出的源文件存放在 Amazon S3 云存储中，数据文件为 my_db.my_table.00001.sql ~ my_db.my_table.10000.sql 共计 10000 个 SQL 文件。如果希望使用 2 个 TiDB Lightning 实例加速导入，则需要在配置文件中增加如下设置：

[[mydumper.files]] # db schema 文件 pattern = '(?i)^(?:[^/]*/)*my_db-schema-create\.sql' schema = "my_db" type = "schema-schema" [[mydumper.files]] # table schema 文件 pattern = '(?i)^(?:[^/]*/)*my_db\.my_table-schema\.sql' schema = "my_db" table = "my_table" type = "table-schema" [[mydumper.files]] # 只导入 00001~05000 这些数据文件并忽略其他文件 pattern = '(?i)^(?:[^/]*/)*my_db\.my_table\.(0[0-4][0-9][0-9][0-9]|05000)\.sql' schema = "my_db" table = "my_table" type = "sql"

另外一个实例的配置修改为只导入 05001 ~ 10000 数据文件即可。

其他步骤请参考示例 1 中的相关步骤。

错误处理

部分 TiDB Lightning 节点异常终止

在并行导入过程中，如果一个或多个 TiDB Lightning 节点异常终止，需要首先根据日志中的报错明确异常退出的原因，然后根据错误类型做不同处理：

如果是正常退出(如手动 Kill 等)，或内存溢出被操作系统终止等，可以在适当调整配置后直接重启 TiDB Lightning，无须任何其他操作。

如果是不影响数据正确性的报错，如网络超时，可以在每一个失败的节点上使用 tidb-lightning-ctl 工具清除断点续传源数据中记录的错误，然后重启这些异常的节点，从断点位置继续导入，详见 checkpoint-error-ignore。

如果是影响数据正确性的报错，如 checksum mismatched，表示源文件中有非法的数据，则需要在每一个失败的节点上使用 tidb-lightning-ctl 工具，清除失败的表中已导入的数据及断点续传相关的源数据，详见 checkpoint-error-destroy。此命令会删除下游导入失败表中已导入的数据，因此，应在所有 TiDB Lightning 节点（包括任务正常结束的）重新配置和导入失败的表的数据，可以配置 filters 参数只导入报错失败的表。

导入过程中报错 "Target table is calculating checksum. Please wait until the checksum is finished and try again"

在部分并行导入场景，如果表比较多或者一些表的数据量比较小，可能会出现当一个或多个任务开始处理某个表的时候，此表对应的其他任务已经完成，并开始数据一致性校验。此时，由于数据一致性校验不支持写入其他数据，对应的任务会返回 "Target table is calculating checksum. Please wait until the checksum is finished and try again" 错误。等校验任务完成，重启这些失败的任务，报错会消失，数据的正确性也不会受影响。

上文就是小编为大家整理的tidb-lightning的使用，tidb lightning 多个任务。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。