TiDB 集群drop database之后多久会释放磁盘空间

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.2.2

从5.2.2集群迁移数据到其他新的集群之后，在旧的 5.2.2集群中执行 drop database xxx之后，从日志看到

[2024/11/19 14:05:23.469 +08:00] [INFO] [session.go:2951] ["CRUCIAL OPERATION"] [conn=2131368435] [schemaVersion=9661] [cur_db=information_schema] [sql="drop database xinyu"] [user=kfzdba@192.168.3.108]
[2024/11/19 14:05:23.477 +08:00] [INFO] [ddl_worker.go:318] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:7129, Type:drop schema, State:none, SchemaState:queueing, SchemaID:121, TableID:0, RowCount:0, ArgLen:0, start time: 2024-11-19 14:05:23.434 +0800 CST, Err:<nil>, ErrCount:0, SnapshotVersion:0; "]
[2024/11/19 14:05:23.477 +08:00] [INFO] [ddl.go:546] ["[ddl] start DDL job"] [job="ID:7129, Type:drop schema, State:none, SchemaState:queueing, SchemaID:121, TableID:0, RowCount:0, ArgLen:0, start time: 2024-11-19 14:05:23.434 +0800 CST, Err:<nil>, ErrCount:0, SnapshotVersion:0"] [query="drop database xinyu"]
... ...
... ...
[2024/11/19 14:05:23.757 +08:00] [INFO] [ddl.go:601] ["[ddl] DDL job is finished"] [jobID=7129]
[2024/11/19 14:05:23.757 +08:00] [INFO] [callback.go:106] ["performing DDL change, must reload"]

然后 tidb_gc_life_time参数的时间是10分钟

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| tidb_gc_life_time | 10m0s |
+-------------------+-------+
1 row in set (0.01 sec)

但是实际上并未按照tidb_gc_life_time设定的时间进行数据清理。

从日子中没有看到其他有关的信息，从监控上看到 14:05 删除的数据库，在 17:50才开始清理数据。

image
image1920×979 61.9 KB

有人知道这个释放逻辑吗？

2

tidb_gc_run_interval这个参数值是多少

3

也是10分钟呢

+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| tidb_gc_run_interval | 10m0s |
+----------------------+-------+
1 row in set (0.02 sec)
4

drop完只是先gc吧，gc完了空间还没释放呢，释放得等compact

5

image
image802×404 42.4 KB

6

表示看不懂了，这里

7

之前一直认为是gc完就是把数据都清理完了，看评论是说还要compact，有没有官方链接说明这个s事情的?

8

简单理解就是： 执行DROP TABLE 语句后，磁盘空间的释放并不是立即发生的。数据库有GC和compact机制，只有compact完了之后，存储空间才会真正释放。

9

这个是GC的逻辑，文档也之前看到过，
第二阶段“delete ranges" 是提示会快速的删除， 由于drop table/index等操作产生的整区间的废弃数据。

所以我理解最迟在20分钟之后会删除range数据，不就是清理磁盘么，难道这里不包含 drop database?

所以这个比较疑惑，看后面有人说需要compact，之前没有了解过这个

10

我在官网文档中没有看到具体的逻辑描述， 只找到了所谓的可以手动执行 tikv的 compact操作，请问你描述的逻辑，从哪里可以看到呢，compact在什么情况下自己触发之类的

11

我目前也是这么认为的。所以同求问

12

你的回答很调皮呀

13

触发机制看这里。
专栏 - 带你全面了解compaction 的13个问题 | TiDB 社区?

14

drop 和 truncate 的话基本上 gc 完成后立马清理，它相当于 unsafe remove。

delete、update 等产生的 mvcc 是 gc 打标签，表示可以 compact。
compact 有自己的机制，比如定时抽样 region 是否有过多的 delete mvcc，如果有就会触发一次 compact。

可以简单的这么理解。

2 个赞
15

gc时间过了很快就释放了 不需要走 compact流程

16

但是实际现象不是这样的呢，从监控图上可以看到，实际清理操作发生在17:50但是drop database 操作是在14:05就执行的

17

我也是这么理解的，但是和实际的结果不一致，所以来此求问

18

drop database后要等gc时间，默认最少10分钟以后才开始清理数据，你看看gc实际触发情况
select * from mysql.tidb查看

19

gc 默认 10min 触发一次，drop database 的数据也需要 gc 推进 safepoint 到 14:05 才能清理数据。可能是因为其他原因导致 gc 没有推进 safepoint 超过 14:05 。
可以看看 tikv 监控里 gc safepoint 的推进情况是不是有段时间卡住了。

ps: drop truncate 操作在 tikv 底层是整块删除，接近于直接删除物理文件。不需要 compaction。

1 个赞
20

这个表中存在放是tidb的系统变量值，值的状态都是当前值，历史问题没有办法看吧