Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: tidb删除空间回收问题
[TiDB Usage Environment] Production Environment / Testing / Poc
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue: Problem Phenomenon and Impact]
[Resource Configuration] Enter TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachments: Screenshots/Logs/Monitoring]
After deleting data with the delete command and manually compacting, the space cannot be released.
Manual compact command: ./tikv-ctl --host xxxxx --data-dir /data/tidb-data/tikv-20160 compact -d kv
The current file system is:
All three nodes are the same, but manual compacting did not release the space, and the disk usage rate is still 60%. Has anyone encountered this issue before?
The image is not visible. Please provide the text you need translated.
I waited a day for the compact, definitely more than 10 minutes.
By default, GC runs every 10 minutes. If GC is confirmed to be successful, it means that the MVCC data has been successfully deleted. Compaction is automatically executed by the underlying RocksDB based on scoring each level. The underlying data has already been merged and duplicate data deleted. If the data itself is relatively continuous, apart from the first level where there might be more duplicate data, manual execution might not have a significant effect.
To manually compact the write default CF, use the following command. You need to compact the last layer together, otherwise, it will have little effect:
tikv-ctl --host tikv_ip:port compact -c write -d kv --bottommost force
Well, can’t I write it like this?
Check out these two posts:
Deleting does not release disk space, don’t wait, I have tested various manual compaction methods, none of them work.
You are only compacting the default column family (default if not specified). You need to specify and compact the write column family as well.
I checked and I have enabled the compaction feature.
Although it is written this way, it has no actual effect.
Deleting should free up space. If it doesn’t, I think it’s a bug. Please report it in the feedback section.
Not really, other common databases like Oracle, MySQL, etc., also do not release hard disk space upon delete. They just mark the data as deleted, and the space is kept for reuse.
That should be space fragmentation, right? TiDB shouldn’t be the issue. My intuitive feeling is that it’s a bug with GC and compact. Why not provide some feedback?
It’s not a bug, specifically like this:
Does TiDB immediately release space after deleting data?
DELETE, TRUNCATE, and DROP do not immediately release space. For TRUNCATE and DROP operations, after reaching TiDB’s GC (garbage collection) time (default is 10 minutes), TiDB’s GC mechanism will delete the data and release the space. For DELETE operations, TiDB’s GC mechanism will delete the data, but it will not release the space. Instead, the space will be reused when subsequent data is written to RocksDB and compaction occurs.
Compaction is always being done, and eventually, it will compact the last level. Space is released through compaction, but if it is not being released continuously, I think there is a problem. I have encountered a similar situation before where there was a bug in compaction that caused this issue. That’s why I mentioned that not releasing space feels problematic.
I have done several tests in version 7.1, such as deleting all data from a table with tens of millions of rows, and the space occupied is still considerable after a few days.
This is how the table looks now.
|
username: TiDBer_zWsmzAL8
|
username: 
|
username: 
|
username: 
|
username: 
TiDB Technical Issues - TiDB Q&A Community (asktug.com)
|
username: 
|
username: