GC safe_point如何正常推进,导致磁盘空间暴增

TiDB 使用环境】生产环境
【TiDB 版本】V7.1.0
【操作系统】centos7.9
【部署方式】物理机
【集群数据量】41T
【集群节点数】14
【问题复现路径】重启tidb集群
【遇到的问题:问题现象及影响】tidb grafana监控查看GC safe point未正常推进
PD记录的safe point
curl http://<PD_IP>:<PD_PORT>/pd/api/v1/gc/safepoint
“gc_safe_point”: 455470299584135176

TiDB记录的safe point

SELECT * FROM mysql.tidb WHERE variable_name=‘tikv_gc_safe_point’;
| tikv_gc_safe_point | 20250522-21:37:24.208 +0800 | All versions after safe point can be accessed. (DO NOT EDIT)

TiKV各节点状态

tiup ctl:v<CLUSTER_VERSION> tikv --host=<TiKV_IP>:<TiKV_STATUS_PORT> metrics | grep gc_safe_point

HELP tikv_gcworker_autogc_safe_point Safe point used for auto gc

TYPE tikv_gcworker_autogc_safe_point gauge

tikv_gcworker_autogc_safe_point 455470299584135200
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.005”} 706
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.01”} 710
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.025”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.05”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.1”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.25”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“0.5”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“1”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“2.5”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“5”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“10”} 713
tikv_pd_request_duration_seconds_bucket{type=“get_gc_safe_point”,le=“+Inf”} 713
tikv_pd_request_duration_seconds_sum{type=“get_gc_safe_point”} 1.0915107170000005
tikv_pd_request_duration_seconds_count{type=“get_gc_safe_point”} 713

  1. 三方safe point不一致
  • PD记录455470299584135176(2025-01-22左右)
  • TiDB记录20250522-21:37:24.208 +0800(2025-05-22)
  • TiKV记录455470299584135200(与PD接近)
    *通过GRAFANA查看与PD结果也一致,一致未推进

通过tidb日志查看GC是有正常推进的

期间有重启tidb集群和重启tidb server节点都无用

是不是什么冲突导致的,这个锁信息丢了?
可以看看这个场景是什么问题

看看这个,也许有帮助。

根据这个文档查看有unexpected resolve类似错误,



根据表id查询该表还存在,并且有数据在正常写入。查看没有lock

这个学习了

那有可能是bug 了,看看是不是已经修复的,7.1.X ,可以升级试试

ticdc已经很早就任务删除并下线了,查看没有ticdc任务。
当前查到了是哪个key导致的lock,请问下如何将这个给杀掉呢


这个 Region 对应的表,是否还存活?

如果这个表不需要了,可以尝试 Drop table 或者 remove Region 试试

好像没有办法清理 lock 信息,这个是 GC scan 需要去自动处理的

这个对应的表还在,并且有数据插入。remove region如何操作呢


描述的情况,应该不适于用 Region remove

如果不是 leader Region,通过 tikv-cli ,就可以remove 了

https://docs.pingcap.com/zh/tidb/stable/tikv-control/#设置一个-region-副本为-tombstone-状态


建议采用复制表数据,重建的方案,待新建的数据表确定没问题后,在处理原来有问题的数据表

按这个搞,大概率是这个问题