线上是 v6.5 的集群，最近做历史数据清理，按主键分批 delete 了大概五千万行。GC life time 用的默认 10 分钟，用 tikv-ctl 查过 GC safe point 早就推进到删除时间之后了，但观察一周，TiKV 磁盘占用基本没怎么降。手动对相关表所在的 region 跑过 compact cluster，释放了一点但不多，看 stores 的 region 分布也比较均衡。现在纠结要不要上 unsafe destroy range，又怕影响线上业务。想请教下大家遇到这种场景一般是怎么处理的？是只能等底层 compaction 慢慢做，还是有参数可以催一下？
这种情况挺常见的，delete 只是标记删除，真正释放要等 RocksDB compaction 把 tombstone 合并掉。先确认下 gc safe point 是否真的推进了，用 SELECT * FROM mysql.gc_delete_range 看下 delete range 任务有没有卡住，有时候 region 上有慢查询会导致任务堆积。
1 个赞
safe point、compact、region 分布都查过了，排查挺细的。这种场景我碰到过，多半不是 GC 没跑，而是删除留下的 tombstone 沉在 write CF 底层 SST 里——tikv-ctl compact 默认 bottommost 是 skip，最底层根本不会重写，所以你只看到掉了一点。建议低峰期对 write、default CF 加 --bottommost force 再压一遍，空间基本能回来，注意下 IO 压力就行。unsafe destroy range 是给 drop/truncate 场景用的，纯 delete 别上，容易误伤。