038- 拯救大兵瑞恩之 TiDB 如何在 TiKV 损坏的情况下恢复

作者： anjia 原文来源：https://tidb.net/blog/4b5451bb

这是坚持技术写作计划（含翻译）的第 38 篇，定个小目标 999，每周最少 2 篇。

很喜欢 TiDB 的设计哲学，比如，数据库就活该要么 OLAP，要么 OLTP 么，为嘛就不能兼顾一下？数据量大了后，就一定要反人类的分库分表么？你当分库分表好玩么？分库一时爽，维护火葬场！

尤其在一些中小型团队里，为了数据分析搞一套 Hadoop，约等于为了喝牛奶，从牛崽开始养一头奶牛。一路上明坑暗坑不断。

考虑到学习成本，迁移成本 (高度兼容 MySQL- 但不是 100%)，运维成本 (支持 Ansible- 团队有 Ansible 运维经验)，使用成本 (相比 Hadoop)，硬件成本 (相比 Hadoop)，收益 (不用分开分表，支持 OLAP 和 OLTP，支持分布式事务, 支持 TiSpark, 支持 TiKV，自带同步工具) 等。

好了，疑似广告的一段话说完了，回归正题，介绍是如何悲催的遇上整栋大厦停电，并且恰好 TiKV 文件损坏，以及如何在 TiDB 各位大佬的远程文字指导下，一步步把心态从删库跑路，转变成说不定还有救，以及，我擦，真救回来的坎坷心路旅程。

因为 TiDB 之前是别的同事负责，刚接过来不久，对 TiDB 整个的掌握还很初级。真·面向故障学习！

全文主要是对本次事故的回溯，琐碎细节较多，介意的可以直接看最后。

集群环境

[]()

悲催之始

上午 coding 正嗨，突发性停电

来电后 ssh 到 TiDB 的 Ansible 主控机 ansible-playbook start.yml

事情有点不妙，但是扔不死心的， stop and start 一通后，仍是这个结果。事情有点大条。

好在之前偷偷潜伏到 TiDB 的官方群里，没事就听各位大佬吹水打屁，多少受了点熏陶。撸起袖子，开搞。

[]()

定位问题

[]()

Round 1 懵逼树上懵逼果

先看官方文档

好吧，跟没看区别不大。

既然是 TiDB 起不来，就先看 TiDB 的日志 (实际上应该看 http://prometheus:9090/targets ，因为不太熟悉，所以走了弯路，为嘛不看 Grafana, 是因为 TiDB 那卡到后，Ansible 就自动退出了，没有起 Grafana)

暴露的是连接两个 TiKV 报错，这是前期比较关键的线索，起码有初步排查方向了。

另外从日志看到，疑似报空间不足，实际上没意义，在两台 tikv 执行 df -i df -h 来看，都很充足。

群内 @张曾钧 @PingCAP 大佬开始介入，并且开始了将近 8 个小时的细心和耐心的指导，讲真，PingCAP 团队是我见过最热心耐心的团队，素未蒙面，但乐于助人[呲牙]

此时，通过看官方文档，尝试性，试了下 Prometheus 可以打开，

能看出有两个 TiKV down 掉，正好是上面两个。PS , 我是事后才发现的，当时我一直认为 TiKV 是起来的[捂脸]

插播一下，TiDB 整体架构 ，不多解释。建议看看，可以了解一下 TiDB 的架构原理，比如，TiDB,TiKV,PD 等的职责。

小结： Round 1 以找出两个 TiKV down 结束，效率低到羞愧。

[]()

Round 2 懵逼树前排排坐

注意，下面如无特殊说明，一律是 TiKV 关掉状态下，执行命令。

使用 @唐刘 @PingCAP 的方法 grep -B 50 Welcome , 开始接触事发原因了。

更多的 grep 的方法 (-A -B -C)，参考 man grep 或者 GREP(1) ，因为 tikv 启动会打印 Welcome，所以有理由认为，每次的 Welcome 之前的，肯定是上次退出的原因。

至此，出现了第一个坏掉的 region。

当时执行了 ./pd-ctl store -d -u http://127.0.0.1:2379

找到挂掉的两个 TiKV 的 store id，跟上图的

68935 能对起来。

此时救苦救难的 大佬 提供了 TiKV Control 使用说明 # 恢复损坏的 -mvcc- 数据

实际上执行后，没啥效果，后来发现是因为此 region 超过一半副本出问题了，recover-mvcc 没法恢复。

Round 2 结束，找到了救命稻草，TiKV Control 和 PD Control, 但是，事情远没这么简单。

[]()

Round 3 渐入佳境

中间出了个差点搞死自己的小插曲

/home/tidb/tidb-ansible/resources/bin/pd-ctl -u "http://172.16.10.1:2379" -d store delete 10 自作聪明的以为，TiKV 已经没救了，执行了 store delete 操作。

但是实际上还有救，所以又变成了，如何把已经 delete 掉的 store，再度挂上去。

根据 大佬的 curl -X POST http://${pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Up 成功挂上，当然还是 down 的状态。

根据

tikv-ctl --db /path/to/tikv/db bad-regions 两台坏的，分别如下

发现坏掉的 region 是 31101（实际上因为用的是 2.1.4，每次只显示一个，处理完后，才会显示下一个，效率很低，后来在 [@戚铮]() 大佬的指导下，换用 tikv-ctl 3.x ，每次可以显示全部的坏的 region ）

在好的节点上执行，也不是文中的 all regions are healthy ，实际上是因为，数据文件被占用，没法获取句柄，停掉就行 ansible-playbook stop.yml -l tikv_servers 停掉全部 tikv 节点

此时 @张曾钧 @PingCAP 提示用 tikv-ctl --db /path/to/tikv/db tombstone -p 127.0.0.1:2379 -r 把坏的 region 设置为 tombstone ，但是报错

通过执行 pd-ctl region 31101 发现

这个 region 有两个副本是在坏节点上，超过一半损坏（剧透一下，实际上最后发现，出问题的都是损坏超过 1 半的，1/3 的都自己恢复了）

尝试执行 operator add remove-peer 发现删不掉。

此时 戚铮 大佬出场。

经过一番测试，发现 region31101 很坚挺，使用 recover-mvcc 恢复不了，前面说了是因为损失超过一半副本的原因，使用 operator add remove-peer 删不了，估计也是。

[]()

Round 4 貌似解决

不能因为一颗老鼠屎，坏了一锅汤，部分 region 坏掉了，先尝试强制恢复试试，保证别的正常吧。

注意此命令是在好的 store 上执行

此时启动 TiKV 集群，执行 region 31101，坏掉的已经删掉了，但是服务还是起不来。

此时执行

此时在 [@戚铮]() 老大的指导下，升级 tikv-ctl ,

结果 202 这台，一共三个 region 坏了，处理了俩，感觉遥遥无期，下了 tikv-ctl 3.x 后发现，就还有一个坏的。胜利在望。

重复上述操作后，此节点终于 up 了

218 这个有 6 个坏的

unsafe-recover remove-fail-stores 一通后，终于起来服务了。

Round 4 服务已可以启动，总结一下

1. 先 stop TiKV

2. 如果坏的 region 少于一半，可以尝试 recover-mvcc

3. 如果超过一半，就玄乎了，是在不行就 unsafe-recover remove-fail-stores, 然后再 tikv-ctl –db /path/to/tikv/db tombstone -p 127.0.0.1:2379 -r 31101,xx,xx,xx

4. 再 start TiKV

[]()

Round 5 最终局

你以为万事大吉了？命运就是爱捉弄人。

回到原点。

最后还是损失了部分，但是量不大。

[]()

总结

1. 对 TiDB 不够熟悉，很多流于表面

2. 对 TiDB 的文档和工具使用不熟练

3. TiDB 的文档不太清晰，比如在故障处理里，没有内链像是 pd-ctl,tikv-ctl，甚至都没有提，在 pd-ctl 和 tikv-ctl 等工具没有提如何下载，在工具下载里，没有提包含啥工具。很佛系

4. 多亏了群内各位大佬的热心指导

5. 如果是 TiKV 有问题，先 stop TiKV

6. 如果对于损坏数小于半数的，可以尝试 recover-mvcc

7. 对于超过半数的，可以尝试 unsafe-recover remove-fail-stores ，再 将 store 设置 tombstone

8. 再 start TiKV

9. 可以结合 tidb 损坏 tikv 节点怎么恢复集群 来做。

10. 多试验，尤其是做极限测试，并且尝试处理，会积累很多经验。

11. 虽然没有瑞恩没有全须全尾的拯救回来，但是缺胳膊少腿总好过没命啊。

[]()

一点小广告

其实如果不考虑 OLTP 的场景，还可以尝试使用 clickhouse。这是之前整理的 clickhouse 的一些文章。

• 031- 数据可视化之 redash(支持 43 种数据源)
  

• 033- 史上最全 -mysql 迁移到 clickhouse 的 5 种办法
  

• 035- 解决 streamsets jdbc 全量模式数据重复问题
  

[]()

参考资料

• 我的博客
  

• 我的掘金
  

• failed to write to engine #10596
  

• 使用 TiDB-Ansible 扩容缩容 TiDB 集群
  

• TiDB 集群故障诊断
  

• PD Control 使用说明
  

• TiKV Control 使用说明
  

• TiDB 工具下载
  

• TiDB 损坏 TiKV 节点怎么恢复集群
  

• TiDB 用户案例