作者： TUG 微尘原文来源：https://tidb.net/blog/b6833f52

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 节点

参考：

https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file#reserve-space

方法三：

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

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

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

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

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

故障反思

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

可优化点

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

参考:

https://docs.pingcap.com/zh/tidb/stable/command-line-flags-for-tikv-configuration#--capacity