| title | category | aliases | |
|---|---|---|---|
GC 配置 |
reference |
|
TiDB 的 GC 相关的配置存储于 mysql.tidb 系统表中，可以通过 SQL 语句对这些参数进行查询和更改：
{{< copyable "sql" >}}
select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb;+--------------------------+----------------------------------------------------------------------------------------------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+--------------------------+----------------------------------------------------------------------------------------------------+
| bootstrapped | True |
| tidb_server_version | 33 |
| system_tz | UTC |
| tikv_gc_leader_uuid | 5afd54a0ea40005 |
| tikv_gc_leader_desc | host:tidb-cluster-tidb-0, pid:215, start at 2019-07-15 11:09:14.029668932 +0000 UTC m=+0.463731223 |
| tikv_gc_leader_lease | 20190715-12:12:14 +0000 |
| tikv_gc_enable | true |
| tikv_gc_run_interval | 10m0s |
| tikv_gc_life_time | 10m0s |
| tikv_gc_last_run_time | 20190715-12:09:14 +0000 |
| tikv_gc_safe_point | 20190715-11:59:14 +0000 |
| tikv_gc_auto_concurrency | true |
| tikv_gc_mode | distributed |
+--------------------------+----------------------------------------------------------------------------------------------------+
13 rows in set (0.00 sec)
例如，如果需要将 GC 调整为保留最近一天以内的数据，只需执行下列语句即可：
{{< copyable "sql" >}}
update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";注意：
mysql.tidb系统表中除了下文将要列出的 GC 的配置以外，还包含一些 TiDB 用于储存部分集群状态（包括 GC 状态）的记录。请勿手动更改这些记录。其中，与 GC 有关的记录如下：
tikv_gc_leader_uuid，tikv_gc_leader_desc和tikv_gc_leader_lease用于记录 GC leader 的状态tikv_gc_last_run_time：上次 GC 运行时间tikv_gc_safe_point：当前 GC 的 safe point
- 控制是否启用 GC。
- 默认值：
true
- 指定 GC 运行时间间隔。Duration 类型，使用 Go 的 Duration 字符串格式，如
"1h30m"，"15m"等。 - 默认值：
"10m0s"
- 每次 GC 时，保留数据的时限。Duration 类型。每次 GC 时将以当前时间减去该配置的值作为 safe point。
- 默认值：
"10m0s"
注意：
tikv_gc_life_time的值必须大于 TiDB 的配置文件中的max-txn-time-use的值至少 10 秒，且不低于 10 分钟。在数据更新频繁的场景下，如果将
tikv_gc_life_time设置得比较大（如数天甚至数月），可能会有一些潜在的问题，如：
- 磁盘空间占用较多。
- 大量的历史版本会在一定程度上影响性能，尤其是范围查询（如
select count(*) from t）。
指定 GC 模式。可选值如下：
-
"distributed"（默认）：分布式 GC 模式。在此模式下，Do GC 阶段由 TiDB 上的 GC leader 向 PD 发送 safe point，每个 TiKV 节点各自获取该 safe point 并对所有当前节点上作为 leader 的 Region 进行 GC。此模式于 TiDB 3.0 引入。 -
"central"：集中 GC 模式。在此模式下，Do GC 阶段由 GC leader 向所有的 Region 发送 GC 请求。TiDB 2.1 及更早版本采用此 GC 模式。
控制是否由 TiDB 自动决定 GC concurrency，即同时进行 GC 的线程数。
当 tikv_gc_mode 设为 "distributed"，GC concurrency 将应用于 Resolve Locks 阶段。当 tikv_gc_mode 设为 "central" 时，GC concurrency 将应用于 Resolve Locks 以及 Do GC 两个阶段。
true（默认）：自动以 TiKV 节点的个数作为 GC concurrencyfalse：使用tikv_gc_concurrency的值作为 GC 并发数
- 手动设置 GC concurrency。要使用该参数，必须将
tikv_gc_auto_concurrency设为false。 - 默认值：2
从 TiDB 3.0 版本起，由于对分布式 GC 模式和并行 Resolve Locks 的支持，部分配置选项的作用发生了变化。可根据下表理解不同版本中这些配置的区别：
| 版本/配置 | Resolve Locks | Do GC |
|---|---|---|
| 2.x | 串行 | 并行 |
3.0 tikv_gc_mode = centered tikv_gc_auto_concurrency = false |
并行 | 并行 |
3.0 tikv_gc_mode = centered tikv_gc_auto_concurrency = true |
自动并行 | 自动并行 |
3.0 tikv_gc_mode = distributed tikv_gc_auto_concurrency = false |
并行 | 分布式 |
3.0 tikv_gc_mode = distributed tikv_gc_auto_concurrency = true （默认配置） |
自动并行 | 分布式 |
表格内容说明：
- 串行：由 TiDB 逐个向 Region 发送请求。
- 并行：使用
tikv_gc_concurrency选项所指定的线程数，并行地向每个 Region 发送请求。 - 自动并行：使用 TiKV 节点的个数作为线程数，并行地向每个 Region 发送请求。
- 分布式：无需 TiDB 通过对 TiKV 发送请求的方式来驱动，而是每台 TiKV 自行工作。
TiKV 在 3.0.6 版本开始支持 GC 流控，可通过配置 gc.max-write-bytes-per-sec 限制 GC worker 每秒数据写入量，降低对正常请求的影响，0 为关闭该功能。该配置可通过 tikv-ctl 动态修改：
{{< copyable "shell-regular" >}}
tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_sec -v 10MB