TiKV 组件内 GC 原理及常见问题

导读

本文深入介绍了 TiKV 中的垃圾回收（GC）机制，包括其工作原理、处理流程以及如何通过 GC safepoint 清理旧版本数据。文章比较了传统 GC 和基于 compaction filter 的 GC 两种方式，指出了后者在优化性能方面的优势，讨论了监控 GC 进度、处理 GC 压力等常见问题。此外，文章还提供了针对物理空间回收问题的解决策略和操作建议，旨在帮助用户更好地理解和管理 TiKV 的 GC 过程，确保数据库的稳定与高效运作。

在前两篇文章中，我们介绍了：

1. 为什么需要 GC？TiDB MVCC 版本堆积相关原理及排查手段
2. TiDB 集群 GC 的定义、实现原理及常见问题：TiDB 组件 GC 原理及常见问题

在前面的文章我们知道，TiDB 中的 GC worker 最后是将 GC safepoint 上传到了 pd-server, 所有的 TiKV 实例会定期从 pd 上获取 GC safepoint，如果发生了变更，则会拿着最新的 GC safepoint 开启本地 TiKV 的具体 GC 工作。本文，我们将详细介绍 TiKV 侧 GC 的原理及常见的问题。

GC_key in TiKV

在上一篇文章中，我们知道 TiDB 在 GC 时，会通过 resolve locks 将集群中所有 GC safepoint 之前的 lock 清理掉，也就是到了 TiKV 之后，我们所有 GC safepoint 之前的事务状态都已经明确了，没有 lock 需要从所在分布式事务的 primary key 中获取事务状态了，我们可以放心大胆的删除旧版本数据了。那么，具体怎么删除呢？

我们来看下面的这个例子：

当前 key 一共有四个版本，写入顺序如下：

• 1:00 新写入或更新，数据存在 default cf
• 2:00 更新，数据存在 default cf
• 3:00 删除
• 4:00 新写入，数据存在 default cf

如果 GC safepoint 是 2:30 , 即最多保证到 2:30 这个时刻的快照一致性，那么我们会保留 2:30 这个时刻读到的版本：key_02:00=>（PUT,01:30）， 他之前的版本数据全部删除，这里我们 key_01:00 对应事务的 write-cf 和 default cf 都会被删除掉。

如果 GC safepoint 是 3:30 呢？

同样的，保留 3:30 这一时刻读到的 key_03:00=>DELETE，3:00 以前的旧版本就会被删除掉。

我们看到，3:30 读到的快照里 key_03:00 的事务是在删除这个 key, 那我们是否有必要保留 03:00 这条 MVCC 呢？

当然是不用了，所以正常情况下，如果 gc safepoint = 3:30, 那么这个 key 需要被 GC 的数据为：

以上，就是对于某个明确的 key, GC 所需要具体清理的数据。TiKV 的 GC，则需要把当前 TiKV 实例上，所有的 key 进行扫描并删除符合条件的旧版本。

相关监控

gc_keys 因为需要读取当前 key 的所有版本才能确认是否删除旧版本，所以会对系统产生读压力，相关监控在 tikv-details->GC-> GC scan write/default details：记录了 GC worker 在执行过程中对 rocksdb write/default cf 的压力：

gc_keys 的 duration 可以在 tikv-details->GC-> GC tasks duration 里面看，如果这一块延迟比较高，说明 gc 压力比较大或者系统本身读写压力比较大影响到了 GC。

GC in TiKV

本章，我们来具体介绍每个 TiKV 实例上，GC 的执行原理和相关监控。TiKV 侧主要有两个常驻线程负责驱动和管理 GC：

• GC worker
• GC manager

GC worker

每个 TiKV 侧有一个 GC worker 线程来处理具体的 GC 工作，TiKV 的 GC worker 主要负责处理以下两类请求：

• GC_keys，简言之，就是对于具体的 key, 扫描并删除符合条件的旧版本。详细过程我们已经在第一章描述过。
• GC（range）：就是对于一块连续的范围的数据调用 GC_keys, 对指定范围内中的每个 key 单独进行 GC 处理。
• unsafe-destroy-range：对于连续范围的数据，直接物理清理。对应于上一篇文章提到的 truncate/drop table/partion.

当前我们 GC worker 一共有两个关键配置，且参数不可调：

• 线程数：GC worker 目前具体只有一个线程，当前代码中硬编码 ( https://github.com/tikv/tikv/blob/v6.3.0/src/server/gc_worker/gc_worker.rs#L1201 )，我们没有提供外部可配的配置。
• GC_MAX_PENDING_TASKS ( https://github.com/tikv/tikv/blob/v6.3.0/src/server/gc_worker/gc_worker.rs#L1201 )GC worker 队列中最多可以接收的任务数，为 4096。

相关监控

GC tasks QPS/duration: tikv-details->GC->GC tasks/GC tasks duration，一般发现 GC tasks duration 比较高时，需要结合 QPS 及 GC worker 的 CPU 是否够用。

GC worker CPU 的使用情况：tikv-details-> thread CPU->GC worker。