TiDB 组件 GC 原理及常见问题

导读

本文详细介绍了 TiDB 的 Garbage Collection（GC）机制及其在 TiDB 组件中的实现原理和常见问题排查方法。TiDB 底层使用单机存储引擎 RocksDB，并通过 MVCC 机制，基于 RocksDB 实现了分布式存储引擎 TiKV，以支持高可用分布式事务。GC 过程旨在清理旧数据，减少其对性能的影响，主要包括四个步骤：计算 GC safepoint、解析锁（Resolve locks）、连续范围数据删除（Delete ranges）和同步 GC safepoint 至集群其他组件。文章还讲述了如何定位 GC leader、监控 GC 状态、以及处理 GC 过程中遇到的常见问题。

TiDB 底层使用的是单机存储引擎 RocksDB, 为了实现分布式事务接口，TiDB 又采用 MVCC 机制，基于 RocksDB 实现了高可用分布式存储引擎 TiKV。也就是当新写入（增删改）的数据覆盖到旧数据时，旧数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。当这些历史版本堆积越来越多时，就会引出一系列问题，最常见的便是读写变慢。TiDB 为了降低历史版本对性能的影响，会定期发起 Garbage Collection清理不再需要的旧数据。

本文我们将重点介绍 TiDB 组件中 GC 的相关原理及常见排查手段。由于篇幅原因，TiKV 侧的 GC 相关内容我们将在另一篇文章中独立介绍。

GC leader

通过对 TiDB 分布式事务实现的了解，我们知道 TiDB 集群具体的数据存储在 TiKV 上，集群的元数据信息存在 PD 上，TiDB 要做数据旧版本的回收，则需要有个类似 GC worker 的角色从 PD 拿到元数据信息然后对 TiKV 中的数据做垃圾回收工作。这个角色目前我们放在 TiDB 中，一个就够，所以我们借助 PD 维护选举出一个 GC leader 的角色，来统一协调整个集群的 GC 工作。

GC leader 是 TiDB 中负责推动集群 GC 工作的一个协程（goroutinue）, 一个 TiDB 集群中，同一时刻有且只有一个 TiDB 上会有这个 GC leader 角色。

常见排查指导

通常如果怀疑系统 GC 状态可能存在异常，我们可以从 gc leader 所报的日志中查看当前 GC 的详细状态。

• 如何查找 GC leader 在哪个 tidb 上？

mysql> select variable_name,variable_value from mysql.tidb where variable_name = "tikv_gc_leader_desc"\G;
*************************** 1. row ***************************
 variable_name: tikv_gc_leader_desc
variable_value: host:172-16-120-219, pid:3628952, start at 2024-01-17 16:34:58.022047311 +0800 CST m=+9.910349289
1 row in set (0.00 sec)

Copy

• 找到 gc leader 对应的 tidb 实例，在日志中 grep "gc_worker" 关键字即可看到当前 GC 的整体运行状态。关于日志中字段的具体含义，我们可以在后面的章节会详细展开介绍。

  tidb@172-16-120-219:~/shirly/tiup$ ps aux | grep 3628952
  tidb     3592616  0.0  0.0   8160  2456 pts/2    S+   15:12   0:00 grep --color=auto 3628952
  tidb     3628952  8.2  0.2 10914336 1065168 ?    Ssl  Jan17 4158:25 bin/tidb-server -P 4005 --status=10080 --host=0.0.0.0 --advertise-address=127.0.0.1 --store=tikv --initialize-insecure --path=127.0.0.1:2379,127.0.0.1:2381,127.0.0.1:2383 --log-slow-query=/DATA/disk4/shirly/tiup/tidb-deploy/tidb-4005/log/tidb_slow_query.log --config=conf/tidb.toml --log-file=/DATA/disk4/shirly/tiup/tidb-deploy/tidb-4005/log/tidb.log
  tidb@172-16-120-219:~/shirly/tiup$ grep "gc_worker" /DATA/disk4/shirly/tiup/tidb-deploy/tidb-4005/log/tidb.log  | head
  [2024/02/02 19:29:59.062 +08:00] [INFO] [gc_worker.go:1073] ["[gc worker] start resolve locks"] [uuid=6345a3cad480026] [safePoint=0] [try-resolve-locks-ts=447446541678411803] [concurrency=3]
  [2024/02/02 19:29:59.291 +08:00] [INFO] [gc_worker.go:1095] ["[gc worker] finish resolve locks"] [uuid=6345a3cad480026] [safePoint=0] [try-resolve-locks-ts=447446541678411803] [regions=1236]
  [2024/02/02 19:30:59.065 +08:00] [INFO] [gc_worker.go:1073] ["[gc worker] start resolve locks"] [uuid=6345a3cad480026] [safePoint=0] [try-resolve-locks-ts=447446557407051824] [concurrency=3]
  [2024/02/02 19:30:59.283 +08:00] [INFO] [gc_worker.go:1095] ["[gc worker] finish resolve locks"] [uuid=6345a3cad480026] [safePoint=0] [try-resolve-locks-ts=447446557407051824] [regions=1236]
  [2024/02/02 19:31:59.060 +08:00] [INFO] [gc_worker.go:1073] ["[gc worker] start resolve locks"] [uuid=6345a3cad480026] [safePoint=0] [try-resolve-locks-ts=447446573135691804] [concurrency=3]
  [2024/02/02 19:31:59.297 +08:00] [INFO] [gc_worker.go:1095] ["[gc worker] finish resolve locks