7.5 TiKV 磁盘空间占用与回收常见问题

TiDB 文档和配置中提到的 GC 是什么意思?

TiDB 采用 MVCC 事务模型，并且支持了 Snapshot Isolation 级别的事务隔离，因此为了保证正在进行中的事务能够读取到一致的数据，所有的 DELETE 以及 UPDATE 操作在 TiDB 中都不会立刻将原来的数据在物理上删除或者更改，而是为其新增一个版本，这样就保证了旧的版本仍然能被尚未结束的事务读取到。每隔一段时间 TiDB 会确认某个时间点之前的事务已经全部结束了，那么所有的数据在该时间点之前的版本都可以只保留最新的那一个，于是 TiDB 会将这个时间点通知给 TiKV，TiKV 则会发起清理旧版本数据以回收物理空间的操作，这个操作被称作 GC。
为什么我执行了 UPDATE SQL 之后，集群占用的空间在不停地增长？ UPDATE 的数据会占用额外的空间吗？
建议检测 TiKV 监控中的 GC 一栏中，GC speed 的指标是否与 TiKV 写入性能下降的周期波动重合。TiKV 的 GC 由 raft leader 发起，然后将需要删除的旧版本通过一致性协议发送给 follower 删除，因此会抢占正常的业务写入的资源。可以通过 TiKV 的配置 gc.max-write-bytes-per-sec 来限制 GC 的速度，根据机器配置建议该值设置为 128KB ~ 512KB，默认值为，即不进行任何限速。

TiDB 旧版本数据过期时间是可配置的吗？应该如何调整这个配置的大小？
GC 删除数据所占据的物理空间能在 RocksDB 中被立刻回收吗？

GC 删除的数据会很快被 compact 到下一层。在 TiKV 的 CPU 资源充足，RocksDB compact 足够及时的情况下，由于相同层内不会有重复数据，因此最多存在 12% 应该被删除的重复无效数据，这是由于 rocksdb 的写放大带来的数据。