Tikv节点磁盘耗尽恢复经验

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

1赞

感谢您的分享 :+1:

1赞