Update garbage collection docs

alert-rules.md

@@ -445,7 +445,7 @@ Emergency-level alerts are often caused by a service or node failure. Manual int
 
 * Solution:
 
-    1. Perform `select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME = "tikv_gc_leader_desc"` to locate the `tidb-server` corresponding to the GC leader;
+    1. Perform `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"` to locate the `tidb-server` corresponding to the GC leader;
     2. View the log of the `tidb-server`, and grep gc_worker tidb.log;
     3. If you find that the GC worker has been resolving locks (the last log is "start resolve locks") or deleting ranges (the last log is “start delete {number} ranges”) during this time, it means the GC process is running normally. Otherwise, contact [support@pingcap.com](mailto:support@pingcap.com) to resolve this issue.
 
@@ -633,7 +633,7 @@ For the critical-level alerts, a close watch on the abnormal metrics is required
 * Solution:
 
     1. It is normally because the GC concurrency is set too high. You can moderately lower the GC concurrency degree, and you need to first confirm that the failed GC is caused by the busy server.
-    2. You can moderately lower the concurrency degree by running `update set VARIABLE_VALUE="{number}” where VARIABLE_NAME=”tikv_gc_concurrency”`.
+    2. You can moderately lower the concurrency degree by adjusting [`tikv_db_concurrency`](/system-variables.md#tidb_gc_concurrency).
 
 ### Warning-level alerts
 

backup-and-restore-using-dumpling-lightning.md

@@ -61,30 +61,30 @@ The steps to manually modify the GC time are as follows:
     {{< copyable "sql" >}}
 
     ```sql
-    SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time';
+    SHOW GLOBAL VARIABLES LIKE 'tidb_gc_life_time';
     ```
 
     ```sql
-    +-----------------------+------------------------------------------------------------------------------------------------+
-    | VARIABLE_NAME         | VARIABLE_VALUE                                                                                 |
-    +-----------------------+------------------------------------------------------------------------------------------------+
-    | tikv_gc_life_time     | 10m0s                                                                                          |
-    +-----------------------+------------------------------------------------------------------------------------------------+
-    1 rows in set (0.02 sec)
+    +-------------------+-------+
+    | Variable_name     | Value |
+    +-------------------+-------+
+    | tidb_gc_life_time | 10m0s |
+    +-------------------+-------+
+    1 row in set (0.03 sec)
     ```
 
     {{< copyable "sql" >}}
 
     ```sql
-    UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
+    SET GLOBAL tidb_gc_life_time = '720h';
     ```
 
 2. After executing the `dumpling` command, restore the GC value of the TiDB cluster to the initial value in step 1:
 
     {{< copyable "sql" >}}
 
     ```sql
-    UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
+    SET GLOBAL tidb_gc_life_time = '10m';
     ```
 
 ## Restore data into TiDB

br/backup-and-restore-tool.md

@@ -195,18 +195,17 @@ Each of the above three sub-commands might still include the following three sub
 
 To back up the cluster data, use the `br backup` command. You can add the `full` or `table` sub-command to specify the scope of your backup operation: the whole cluster or a single table.
 
-If the BR version is earlier than v4.0.3, and the backup duration might exceed the [`tikv_gc_life_time`](/garbage-collection-configuration.md#tikv_gc_life_time) configuration which is `10m0s` by default (`10m0s` means 10 minutes), increase the value of this configuration item.
+If the BR version is earlier than v4.0.3, and the backup duration might exceed the [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time) configuration which is `10m0s` by default (`10m0s` means 10 minutes), increase the value of this configuration item.
 
-For example, set `tikv_gc_life_time` to `720h`:
+For example, set `tidb_gc_life_time` to `720h`:
 
 {{< copyable "sql" >}}
 
 ```sql
-mysql -h${TiDBIP} -P4000 -u${TIDB_USER} ${password_str} -Nse \
-    "update mysql.tidb set variable_value='720h' where variable_name='tikv_gc_life_time'";
+SET GLOBAL tidb_gc_life_time = '720h';
 ```
 
-Since v4.0.3, BR automatically adapts to GC and you do not need to manually adjust the `tikv_gc_life_time` value.
+Since v4.0.3, BR automatically adapts to GC and you do not need to manually adjust the [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time) value.
 
 ### Back up all the cluster data
 
@@ -667,7 +666,7 @@ Suppose that 4 TiKV nodes is used, each with the following configuration:
 
 Before the backup operation, check the following two items:
 
-- You have set `tikv_gc_life_time` set to a larger value so that the backup operation will not be interrupted because of data loss.
+- You have set [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time) set to a larger value so that the backup operation will not be interrupted because of data loss.
 - No DDL statement is being executed on the TiDB cluster.
 
 Then execute the following command to back up all the cluster data:

br/backup-and-restore-use-cases.md

@@ -74,21 +74,21 @@ It is recommended that you use a network disk to back up and restore data. This
 
 For the detailed usage of the `br backup` command, refer to [BR command-line description](/br/backup-and-restore-tool.md#command-line-description).
 
-1. Before executing the `br backup` command, check the value of the [`tikv_gc_life_time`](/garbage-collection-configuration.md#tikv_gc_life_time) configuration item, and adjust the value appropriately in the MySQL client to make sure that [Garbage Collection](/garbage-collection-overview.md) (GC) does not run during the backup operation.
+1. Before executing the `br backup` command, check the value of the [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time) configuration item, and adjust the value appropriately in the MySQL client to make sure that [Garbage Collection](/garbage-collection-overview.md) (GC) does not run during the backup operation:
 
     {{< copyable "sql" >}}
 
     ```sql
-    SELECT * FROM mysql.tidb WHERE VARIABLE_NAME = 'tikv_gc_life_time';
-    UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
+    SHOW GLOBAL VARIABLES LIKE 'tidb_gc_life_time';
+    SET GLOBAL tidb_gc_life_time = '720h';
     ```
 
 2. After the backup operation, set the parameter back to the original value.
 
     {{< copyable "sql" >}}
 
     ```sql
-    UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
+    SET GLOBAL tidb_gc_life_time = '10m';
     ```
 
 > **Note:**

dumpling-overview.md

@@ -307,15 +307,15 @@ In other scenarios, if the data size is very large, to avoid export failure due
 {{< copyable "sql" >}}
 
 ```sql
-update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';
+SET GLOBAL tidb_gc_life_time = '720h';
 ```
 
 After your operation is completed, set the GC time back (the default value is `10m`):
 
 {{< copyable "sql" >}}
 
 ```sql
-update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time';
+SET GLOBAL tidb_gc_life_time = '10m';
 ```
 
 Finally, all the exported data can be imported back to TiDB using [Lightning](/tidb-lightning/tidb-lightning-backends.md).

error-codes.md

@@ -151,7 +151,7 @@ In addition, TiDB has the following unique error codes:
 
     An unsupported database isolation level is set. 
 
-    If you cannot modify the codes because you are using a third-party tool or framework, consider using `tidb_skip_isolation_level_check` to bypass this check.
+    If you cannot modify the codes because you are using a third-party tool or framework, consider using [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check) to bypass this check.
 
     {{< copyable "sql" >}}
 
@@ -179,16 +179,10 @@ In addition, TiDB has the following unique error codes:
 
 * Error Number: 8055
 
-    The current snapshot is too old. The data may have been garbage collected. You can increase the value of `tikv_gc_life_time` to avoid this problem. The new version of TiDB automatically reserves data for long-running transactions. Usually this error does not occur. 
+    The current snapshot is too old. The data may have been garbage collected. You can increase the value of [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time) to avoid this problem. The new version of TiDB automatically reserves data for long-running transactions. Usually this error does not occur. 
 
     See [garbage collection overview](/garbage-collection-overview.md) and [garbage collection configuration](/garbage-collection-configuration.md).
 
-    {{< copyable "sql" >}}
-
-    ```sql
-    update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";
-    ```
-
 * Error Number: 8059
 
     The auto-random ID is exhausted and cannot be allocated. There is no way to recover from such errors currently. It is recommended to use bigint when using the auto random feature to obtain the maximum number of assignment. And try to avoid manually assigning values to the auto random column.

faq/migration-tidb-faq.md

@@ -19,7 +19,7 @@ Restart the TiDB service, add the `-skip-grant-table=true` parameter in the conf
 
 ### How to export the data in TiDB?
 
-Currently, TiDB does not support `select into outfile`. You can use the following methods to export the data in TiDB:
+You can use the following methods to export the data in TiDB:
 
 - See [MySQL uses mysqldump to export part of the table data](https://blog.csdn.net/xin_yu_xin/article/details/7574662) in Chinese and export data using mysqldump and the `WHERE` clause.
 - Use the MySQL client to export the results of `select` to a file.
@@ -124,5 +124,5 @@ You can configure concurrent GC to increase the speed of reclaiming storage spac
 {{< copyable "sql" >}}
 
 ```sql
-update mysql.tidb set VARIABLE_VALUE="3" where VARIABLE_NAME="tikv_gc_concurrency";
-```
+SET GLOBAL tidb_gc_concurrency = 3;
+```

faq/sql-faq.md

@@ -139,7 +139,7 @@ You can configure concurrent GC to increase the speed of reclaiming storage spac
 {{< copyable "sql" >}}
 
 ```sql
-update mysql.tidb set VARIABLE_VALUE="3" where VARIABLE_NAME="tikv_gc_concurrency";
+SET GLOBAL tidb_gc_concurrency = 3;
 ```
 
 ## Does `SHOW PROCESSLIST` display the system process ID?

faq/tidb-faq.md

@@ -124,12 +124,12 @@ The accessed Region is not available. A Raft Group is not available, with possib
 
 #### ERROR 9006 (HY000): GC life time is shorter than transaction duration
 
-The interval of `GC Life Time` is too short. The data that should have been read by long transactions might be deleted. You can add `GC Life Time` using the following command:
+The interval of `GC Life Time` is too short. The data that should have been read by long transactions might be deleted. You can adjust [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time) using the following command:
 
 {{< copyable "sql" >}}
 
 ```sql
-update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time';
+SET GLOBAL tidb_gc_life_time = '30m';
 ```
 
 > **Note:**