作者： 代晓磊 _Mars 原文来源：https://tidb.net/blog/137913c4

记一次 Lightning 导入失败导致的 tidb 集群重启失败事故处理

一、需求以及环境

需求：离线报表 MySQL 分库分表业务迁移 TiDB，因为是离线报表，凌晨写入后数据不发生变化，先脚本 select into outfile 倒出成为多个 csv 文件，利用 lightning 快速导入到已有的低请求业务 TiDB 集群 (已经提供线上服务)。

环境：

tidb： V4.0.9 版本

lightning： V4.0.9、导入模式 Local

二、问题现象

Lightning 导数据，导入了几分钟后，集群不可用，取消导入，集群仍然不可用，想到重启大法好，重启集群发现集群 tidb 和 tikv 无法启动。

tikv 报错日志：

[2021/01/14 19:41:55.832 +08:00] [ERROR] [sst_importer.rs:92] ["ingest failed"] [err_code=KV:SSTImporter:RocksDB] [err="RocksDB read metadata from /data/deploy/data**/import/**3b719d18-7195-4843-bb4e-00444b53faca_434317_7_4204_write.sst: Os { code: 2, kind: NotFound, message: \""**No such file or directory**\"" }"] [meta="uuid: 3B719D1871954843BB4E00444B53FACA range { start: 748000000000002DFFB95F728000000000FF1400E00000000000FA end: 748000000000002DFFB95F728000000003FF3F16980000000000FA } cf_name: \""write\"" **region_id: 434317 **region_epoch { conf_ver: 7 version: 4204 }"]

三、问题排查和解决

通过上面的报错日志可以发现，tikv 重启在找一个 /data/deploy/data/import/3b719d18-7195-4843-bb4e-00444b53faca_434317_7_4204_write.sst，从路径可以看出是 import 目录的一个 sst 文件，该文件丢失是因为我们 lightning 异常停止导致的丢失，并且该 sst 文件对应的 region 是 434317。

我可以接受丢数据，本来 import 的数据就是不完整的，丢就丢了，我可以恢复后重新导入，再加上该集群有非核心业务服务在使用，我想尽快启动集群。

要想恢复集群就是从 tikv 中将 region=434317 给删除了。

尝试解决方案一：

在 /data/deploy/data/import/ 目录 touch 一个空的 3b719d18-7195-4843-bb4e-00444b53faca_434317_7_4204_write.sst 文件，并且赋予 tidb 用户的权限，发现 tikv 还是启动不起来，报错文件内容为空。

尝试解决方案二：

之前遇到过 3 副本都丢失时的删除 region，如下

./tikv-ctl –db /path/to/tikv/db unsafe-recover remove-fail-stores -s 4 -r 434317

thread ‘main’ panicked at ‘called Result::unwrap() on an Err value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, src/libcore/result.rs:1188:5

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.

执行报错，后来仔细看了文档才发现删除 region 的命令用错了，下面是 unsafe-recover remove-fail-stores 的使用含义。

remove-fail-stores 命令可以将故障机器的 region 从指定 Region 的 peer 列表中移除，此命令常用于多个 TiKV store 损坏或被删除的情况下，这些 Region 便可以使用剩下的健康副本继续提供服务。

真正的解决方案：

其实我们的目的就是将 region=434317 给 tombstone 了，以便 Tikv 启动时跳过对该异常 region 的健康检查，从而使得 tikv 能启动成功。在 tikv 节点执行下面的命令：

./tikv-ctl –db /data/deploy/data/db tombstone -r 434317 –force

tombstone 命令: 在 TiKV 实例上将一些 Region 的副本设置为 Tombstone 状态，从而在重启时跳过这些 Region，避免因为这些 Region 的副本的 Raft 状态机损坏而无法启动服务。

事后处理

在导入数据之前，tidb-lightning 会自动将 TiKV 集群切换为“导入模式” (import mode)，优化写入效率并停止自动压缩。若 tidb-lightning 崩溃，集群会留在“导入模式”。若忘记转回“普通模式”，集群会产生大量未压缩的文件，继而消耗 CPU 并导致延迟。此时，需要使用 tidb-lightning-ctl 手动将集群转回“普通模式“，TiDB 集群才能对外提供正常服务：

bin/tidb-lightning-ctl --switch-mode=normal

最后使用 tidb-backend 的方式导入成功。

四、问题复盘和思考

主要还是 Lightning 使用问题

1、下载跟 tidb 版本匹配的 lightning

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

下载链接中的 {version} 为 TiDB Lightning 的版本号

2、采用什么导入的模式？

https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-backends

• Importer-backend：tlightning 先将 SQL 或 CSV 数据编码成键值对，由额外的组件： tikv-importer 对写入的键值对进行排序后导入 TiKV 中。

• Local-backend：tlightning 先将数据编码成键值对并排序存储在本地临时目录 (就是上文中 date 目录中的 import 子目录)，然后将这些键值对以 SST 文件的形式上传到各个 TiKV 节点，然后由 TiKV 将这些 SST 文件 Ingest 到集群中。不依赖额外的 tikv-importer 组件。

• TiDB-backend：tidb-lightning 先将数据编码成 INSERT 语句，然后通过 TiDB 执行这些 Insert SQL 语句来导入数据。

3 种导入方式对比：

• 速度：Local > importer > tidb-backend

• 资源和网络占用：Local > importer > tidb-backend

3、导入到新集群还是已有集群？

建议导入到新集群 (V4.0+)，这样可以采用 local 这种快速的导入方式； 新集群 (V4.0 以下版本)，可以使用 import 模式 ; 如果导入到线上并且正在使用的集群，请使用 tidb-backend 这种后端导入模式，并且调整并发等避免影响正常的业务。

4、导入过程中的监控

建议导入过程中及时查看 grafana 中关于 Lightning 的专用监控