tidb数据库清理数据后空间不减少问题

🪐 TiDB 技术问题
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】测试环境
【TiDB 版本】8.5.1
【集群节点数】2个tidb3个tikv3个pd共六台服务器
【遇到的问题：问题现象及影响】
数据库表大表清理后，占用的空间不减少，通过SELECT * FROM mysql.tidb WHERE variable_name IN (‘tikv_gc_safe_point’, ‘tikv_gc_last_run_time’);查询结果正常，如下图:

image
image797×133 9.01 KB
，而通过tiup ctl:v8.5.1 pd -u http://192.168.181.57:2379 service-gc-safepoint show命令，查询的"gc_safe_point": 450204182675718148停留在2024-06-03 13:31:04.626 +0800 CST，不正常
image
image1294×293 10.3 KB
，但是没找到如何推进gc_safe_point，也没找到问题所在，还请老师能提供下查询方法及解决思路

1 个赞
2

gc变量设置如下：

image
image453×356 13.1 KB

1 个赞
3

删除之后不是立即减少的。

image
image759×471 79.3 KB

3 个赞
4

参考这个看看，类似的问题。楼主自己解决了。

1 个赞
5

清理方式是啥，truncate table语法还是delete from 语法？前者默认10min后释放空间，后者较慢，会等 region compaction之后才释放空间

1 个赞
6

TiDB 清理数据后空间不减少，本质是其延迟回收的存储机制导致的，核心原因可以拆解为 GC（垃圾回收）未正常推进 和 TiKV Compaction（文件合并）未及时回收空间 两大阶段问题

1 个赞
7

你太着急了，tikv清理空间默认情况下都是需要几天的。过3天你再看看吧

1 个赞
8

手动触发 Compaction（低峰期执行，避免 IO 飙升）

1 个赞
9

这个cdc看着是正常推进的，没有卡住呢

1 个赞
10

是的，如果想观察到空间使用率下降，得耐心等几天。

1 个赞
11

我按照这个把cdc删除了， “gc_safe_point”: 450204182675718148，这个时间还是没推进，[tidb@test4 ~]$ curl http://192.168.180.58:2379/pd/api/v1/gc/safepoint
{
“service_gc_safe_points”: [
{
“service_id”: “gc_worker”,
“expired_at”: 9223372036854775807,
“safe_point”: 464002041091194880
}
],
“min_service_gc_safe_point”: 464002041091194880,
“gc_safe_point”: 450204182675718148
},safe_point和 min_service_gc_safe_point是正常的

1 个赞
12

我这个都一个周了

1 个赞
13

是不是TiDB的垃圾回收GC停止了？导致已经删除的数据的物理空间无法释放？

1 个赞
14

– 查看 DDL 任务进度
SELECT job_id, db_name, table_name, job_type, state, create_time, start_time, end_time
FROM INFORMATION_SCHEMA.TIDB_DDL_JOBS
WHERE state = ‘running’
ORDER BY create_time DESC;

1 个赞
15

在哪里设置的?

1 个赞
16

GC程序运行是不是定时执行的,当然也可以手动执行.

17

这个应该怎么分析？查看哪些参数？

image
image992×340 15.1 KB

18

搜一下 tidb 日志里面有没有关键词 “GC will be skipped”、“gc safepoint blocked by a running session”

19

:thinking:不一定是cdc的问题，原文中写的是，他对比发现是cdc的safepoint不一致，所以删除了cdc的safepoint。你这边要对比看看本地是哪个不一致，然后删除对应的试试。