记一次因 GC bug 导致 TiKV 存储占用不均的问题处理
作者: OnTheRoad 原文来源:https://tidb.net/blog/82d51e46
1. 问题描述
1.1. 环境描述
1.2. 问题现象
1.2.1. Dashboard 日志
Dashboard 存在大量 ERROR 级别的关于 gc worker 的报错日志,内容如下:
1.2.2. TiKV 空间占用不均
Grafana 监控面板(路径:kruidb-PD->Statistics-balance
)显示 3 个 TiKV 节点空间占用相差较大。
2. 问题分析
2.1. 系统视图查看 region 分布
通过系统视图 information_schema.tikv_region_peers
可查看各个 TiKV 节点中 Leader 与 Region 副本的分布情况。由结果可知,各 TiKV 节点中 Leader 与 Region 副本数量分布均匀。
2.2. 监控面板查看 region 分布
通过 Grafana 监控面板(路径:kruidb-Overview->TiKV
),可查看各个 TiKV 节点中 Leader 与 Region 副本的分布情况。面板显示与系统视图 information_schema.tikv_region_peers
结果一致。
2.3. 系统视图 gc_delete_range
mysql.gc_delete_range
执行了drop/truncate
后,需要被 GC worker 定期物理删除的Key-Value
范围段;mysql.gc_delete_range_done
已经被 GC worker 物理删除的Key-Value
范围段。
系统视图显示存在大量需要被物理删除,而由于 GC worker 失败未删除的数据。
2.4. 查看 store 评分
通过 Grafana 监控面板(路径:kruidb-PD->Statistics-balance
),可查看各个 TiKV 节点 Leader 与 Region 评分。PD 调度器会优先将 Leader 与 Region 调度到评分较低的 TiKV 节点中。
面板显示,各个 TiKV 节点的 Leader 评分较均衡。而 store-2 与 store-3 因空间不足,Region 评分较高。
3. 问题处理
通过以上各系统视图与监控面板初步判断,由于 GC Woker 执行失败,导致大量本应物理删除的数据,未被物理删除,从而占用大量存储空间。
通过查询 ASKTUG,断定由于触发 GC bug #11903 ,原文链接:TiDB 节点大量[gc worker] delete range failed 报错信息。
临时解决方案:可通过禁用
gc.enable-compaction-filter
,并重启集群。永久解决方案:升级 TiDB 集群版本,永久解决。
3.1. 禁用 gc.enable-compaction-filter
在线修改 TiKV 配置
修改持久化配置文件
为避免 SET CONFIG
在线修改的配置,被 tiup reload 所覆盖。需要修改持久化配置文件。
3.2. 增加调度
调整 PD 调度参数,以提高调度速度。
3.3. 结果验证
12 小时候,检查 Grafana 各监控面板,多个 TiKV 节点存储空间占用已达到均衡,且空间占用由原来的 3T 下降到 500G。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/47d9e3e9ba8501ab08ba9f32d】。文章转载请联系作者。
评论