【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】5.1.4
【复现路径】gc时间清理非常慢
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
gc清理已经卡在了几天前
查看gc清理日志,一直有失败,看着失败都是在 delete range
从当前集群来看 ,并没有太多物理删除需要清理
gc相关监控
【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】5.1.4
【复现路径】gc时间清理非常慢
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
gc清理已经卡在了几天前
查看gc清理日志,一直有失败,看着失败都是在 delete range
从当前集群来看 ,并没有太多物理删除需要清理
gc相关监控
参考下这个
这种场景,重启tikv可以释放空间吗?
试试吧,找个时间滚动重启下
好的好的
可以把小版本升级到5.4
这算是版本BUG吗?
重启应该解决不了问题,我们有重启过
但是我们的是5.1.4版本不确定是不是也有一样的问题
(我是这个issue 楼主的同事)补充一下目前怀疑的点和情况:
mysql.gc_delete_range 这个表里面,从 0908 就开始长期残留几个 ranges 了,对比其他新的 ranges 差异明显,
从近一个月的 delete日志也发现一直 delete 这些 ranges 都是失败的:
修改gc时间呢,多修改几次看看有没有效果
改一下gc事件
5.3.1版本修复了一个bug ,和你这个现象非常像
unsafe_destroy_range
参数)的问题 #11903大概率是bug,按说gc清理是非常快的,我测试修改 tikv_gc_life_time ,改小,瞬间就删掉之前的了
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。