GC in compaction filter 实现原理

[h5n1]

GC in CompactionFilter的具体实现过程和原理是什么？ 我理解是以前版本时gc-worker线程扫描kv然后对符合GC条件的数据调用rocksdb的delete()设置delete标记之后等待compact来完成物理删除，使用CompactionFilter后就不在有gc-worker线程和前面的GC逻辑，而是在filter内设置逻辑判断是否符合GC时间要求，compact根据filter的结果来执行物理删除操作。但在rocksdb的compaction filter介绍里需要过滤的key还是打个delete标记，这样不还是会残留很多待物理删除数据吗？

[Lucien]

在 TiKV storage 是建立在 raft 层上面，rocksdb 在 raft 层的下面一层。compaction filter 是rocksdb的东西，只能是每个节点独立运行，没办法走raft的。另外即使不开 compaction filter，也是绕过 raft，是因为在 gc worker 里。从原先的使用 raftkv 进行扫描和删除，改成了直接在 rocksdb 上进行扫描和删除，也不再只对 leader 进行扫描，每个region的区间都会扫描，所以现在 safepoint 之前的、经过 gc 操作的数据可能在 raft 副本间不一致，但是只要保证 safepoint 之后的任一 snapshot 看到的数据是一致的就行，这样保证数据的一致性。

[h5n1]

1. tidb的GC in CompactionFilter 是否是利用了rocksdb的CompactionFilter的功能？
2. 按官档描述“由 RocksDB 的 Compaction 过程来进行 GC，而不再使用一个单独的 GC worker 线程” 这里的RocksDB 的 Compaction 过程来进行 GC具体过程是什么样的？是否在开启 ```enable-compaction-filter = true就不在启动gc-worker线程了？

[Lucien]

@h5n1

• tidb的GC in CompactionFilter 是否是利用了rocksdb的CompactionFilter的功能？

是的，TiDB 集群中 GC 比较多，可以加上对应的组建，不过你问的应该是同一个。

@h5n1

按官档描述“由 RocksDB 的 Compaction 过程来进行 GC，而不再使用一个单独的 GC worker 线程” 这里的RocksDB 的 Compaction 过程来进行 GC具体过程是什么样的？是否在开启 ```enable-compaction-filter = true就不在启动gc-worker线程了？

具体过程看一下上面的反馈，其实也是 gc-worker 线程，只不过是多个。