The GC (Garbage Collection) configuration and operational status are recorded in the
mysql.tidb system table. This documents lists these parameters with their descriptions. You can use SQL statements to query or modify them. For example, the following statement adjusts the GC interval to 30 minutes:
update mysql.tidb set VARIABLE_VALUE="30m" where VARIABLE_NAME="tikv_gc_run_interval";
In addition to the following GC configuration parameters, the
mysql.tidbsystem table also contains records that store the status of the storage components in a TiDB cluster, among which GC related ones are included, as listed below:
tikv_gc_leader_lease: Records the information of the GC leader
tikv_gc_last_run_time: The duration of the previous GC
tikv_gc_safe_point: The safe point for the current GC
- The value of
tikv_gc_life_timemust be greater than that of
max-txn-time-usein the TiDB configuration file by at least 10 seconds, and must than or equal to 10 minutes.
- In scenarios of frequent updates, a large value (days or even months) for
tikv_gc_life_timemay cause potential issues, such as:
- Larger storage use
- A large amount of history data may affect performance to a certain degree, especially for range queries such as
select count(*) from t
Specifies the GC mode. Possible values are:
"distributed" (default): Distributed GC mode. In the Do GC step, the GC leader on the TiDB side uploads the safe point to PD. Each TiKV node obtains the safe point respectively and performs GC on all leader Regions on the current node. This mode is is supported from TiDB 3.0.
"central": Central GC mode. In the Do GC step, the GC leader sends GC requests to all Regions. This mode is adopted by TiDB 2.1 or earlier versions.
Controls whether to let TiDB automatically specify the GC concurrency, or the maximum number of GC threads allowed concurrently.
true(default): Automatically use the number of TiKV nodes in the cluster as the GC concurrency
false: Use the value of
tikv_gc_concurrencyas the GC concurrency