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