Tikv节点磁盘耗尽恢复经验

2020年出现过一个tidb集群多个Tikv节点磁盘被写满导致集群不可用的情况，大致背景如下(时间较久，这里只做简单描述，不准确之处请谅解)：

第一阶段

部分节点出现磁盘使用量超过80%阈值报警(出现在半夜，业务等级不高且为离线数据，未引起足够重视)

第二阶段

磁盘使用量超过90%，用户侧做drop partition操作。从现象上看，等后来集群恢复后，此drop partition操作才执行。

第三阶段

第二天早上，集群多数Tikv阶段Down

第四阶段

集群恢复，具体恢复过程如下：

1.清理tikv日志，上游堆积的写任务很快将磁盘再次耗尽，导致tikv无法正常拉起

2.再次drop-patition(此时尚不知drop-partition已经无法work)

3.磁盘使用量无法降低

4.扩容5*tikv节点，停掉写入

5.将reserve-space调整为0MB拉起TiKV节点，TiKV依旧无法恢复

6.调大store-limit至120, 同时降低磁盘保留空间为2%

7.重新拉起TiKV节点，集群开始调度

8.待故障TiKV节点磁盘空余>15%，重新开启写入

9.集群平衡，回调store-limit、reserve-space、磁盘保留空间。

总结

正确的恢复姿势

1.集群停止写入

2.集群扩容

3.调整调大store limit

tiup  ctl pd store limit all 120  --pd=http://{{pd_addr}}    120是本人实践下来比较优的一个值

3.通过上述以下方式中的任意一种或多种恢复Tikv服务

方法一：

清理数据盘中的日志文件

方法二：

将reserve-space调整为0MB拉起TiKV节点

参考：

方法三：

使用磁盘的保留空间(具有一定风险，慎用)

sudo tune2fs -m 3 /dev/vdb       // 默认保留5%

4.等故障TiKV节点磁盘使用量得到一定程度的缓解，可重新打开写业务，恢复服务

5.恢复过程中酌情降低store-limit值(官方最佳实践值为15)

6.待集群平衡，回调所有参数至故障之前的值

故障反思

生产业务无论业务级别，集群oncall报警都要引起足够重视

可优化点

TiKV配置参数中将磁盘容量配置为除去保留空间之后的值，可减少预留磁盘空间对pd调度的影响

参考: