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

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

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

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

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

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

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

集群环境

name	ip	service
tikv-1	192.168.1.200	tikv
tikv-2	192.168.1.201	tikv
tikv-3	192.168.1.202	tikv(有坏region)
pd	192.168.1.203	pd
tidb	192.168.1.204	tidb,monitoring
sn-data-node-1	192.168.1.216	tidb
sn-data-node-2	192.168.1.217	tidb
tikv-4	192.168.1.218	tikv(有坏region)

悲催之始

上午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 服务已可以启动，总结一下

先stop tikv

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

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

再start tikv

Round 5 最终局

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

回到原点。

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

总结

对TiDB不够熟悉，很多流于表面
对TiDB的文档和工具使用不熟练
TiDB的文档不太清晰，比如在故障处理里，没有内链像是pd-ctl,tikv-ctl，甚至都没有提，在pd-ctl和tikv-ctl等工具没有提如何下载，在工具下载里，没有提包含啥工具。很佛系
多亏了群内各位大佬的热心指导
如果是tikv有问题，先stop tikv
如果对于损坏数小于半数的，可以尝试 recover-mvcc
对于超过半数的，可以尝试 unsafe-recover remove-fail-stores ，再将store设置 tombstone
再start tikv
可以结合 tidb损坏tikv节点怎么恢复集群来做。
多试验，尤其是做极限测试，并且尝试处理，会积累很多经验。
虽然没有瑞恩没有全须全尾的拯救回来，但是缺胳膊少腿总好过没命啊。

一点小广告

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

参考资料