Merge remote-tracking branch 'upstream/master' into tiup-docs-5

alert-rules.md

@@ -425,15 +425,11 @@ This section gives the alert rules for the TiKV component.
 
 * Alert rule:
 
-    `sum(increase(tidb_tikvclient_gc_action_result{type="success"}[6h])) < 1`
-
-    > **Note:**
-    >
-    > In TiDB 3.* versions, the `tidb_tikvclient_gc_action_result` metric exists but does not have a value. It's because distributed garbage collection (GC) is introduced in the TiDB 3.0 version but will not be performed in TiDB.
+    `sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d])) < 1 and sum(increase(tikv_gc_compaction_filter_perform[1d])) < 1`
 
 * Description:
 
-    GC is not performed successfully in a Region within 6 hours, which indicates that GC is not working properly. If GC does not run in a short term, it will not cause much trouble; but if GC keeps down, more and more versions are retained, which slows down the query.
+    GC is not performed successfully on a TiKV instance within 24 hours, which indicates that GC is not working properly. If GC does not run in a short term, it will not cause much trouble; but if GC keeps down, more and more versions are retained, which slows down the query.
 
 * Solution:
 

dumpling-overview.md

@@ -237,7 +237,7 @@ Examples:
 The exported file is stored in the `./export-<current local time>` directory by default. Commonly used options are as follows:
 
 - `-o` is used to select the directory where the exported files are stored.
-- `-F` option is used to specify the maximum size of a single file (the unit here is `MiB`; inputs like `5GiB` or `8KB` are also acceptable).
+- `-F` option is used to specify the maximum size of a single file (the unit here is `MiB`; inputs like `5GiB` or `8KB` are also acceptable). It is recommended to keep its value to 256 MiB or less if you plan to use TiDB Lightning to load this file into a TiDB instance.
 - `-r` option is used to specify the maximum number of records (or the number of rows in the database) for a single file. When it is enabled, Dumpling enables concurrency in the table to improve the speed of exporting large tables.
 
 With the above options specified, Dumpling can have a higher degree of parallelism.

error-codes.md

@@ -98,7 +98,7 @@ TiDB is compatible with the error codes in MySQL, and in most cases returns the
 
 * Error Number: 8027
 
-    The table schema version is outdated. TiDB uses the F1 online schema change algorithm to execute DDL statements. When the table schema version of the TiDB server is earlier than that of the entire system, this error is returned if you execute a SQL statement.
+    The table schema version is outdated. TiDB applies schema changes online. When the table schema version of the TiDB server is earlier than that of the entire system, this error is returned if you execute a SQL statement.
 
     When this error occurs, check the network between the TiDB server and the PD Leader.
 

grafana-tikv-dashboard.md

@@ -223,20 +223,17 @@ This document provides a detailed description of these key metrics on the **TiKV
 
 ## GC
 
-- MVCC versions: The number of versions for each key
-- MVCC delete versions: The number of versions deleted by GC for each key
 - GC tasks: The count of GC tasks processed by gc_worker
 - GC tasks Duration: The time consumed when executing GC tasks
-- GC keys (write CF): The count of keys in write CF affected during GC
-- TiDB GC worker actions: The count of TiDB GC worker actions
 - TiDB GC seconds: The GC duration
-- GC speed: The number of keys deleted by GC per second
-- TiKV AutoGC Working: The status of Auto GC
+- TiDB GC worker actions: The count of TiDB GC worker actions
 - ResolveLocks Progress: The progress of the first phase of GC (Resolve Locks)
 - TiKV Auto GC Progress: The progress of the second phase of GC
+- GC speed: The number of keys deleted by GC per second
 - TiKV Auto GC SafePoint: The value of TiKV GC safe point. The safe point is the current GC timestamp
 - GC lifetime: The lifetime of TiDB GC
 - GC interval: The interval of TiDB GC
+- GC in Compaction Filter: The count of filtered versions in the compaction filter of write CF.
 
 ## Snapshot
 

sql-statements/sql-statement-admin.md

@@ -194,7 +194,7 @@ admin show ddl jobs 5 where state!='synced' and db_name='test';
 * `JOB_TYPE`: the type of the DDL operations.
 * `SCHEMA_STATE`: the current state of the schema. If the `JOB_TYPE` is `add index`, it is the state of the index; if the `JOB_TYPE` is `add column`, it is the state of the column; if the `JOB_TYPE` is `create table`, it is the state of the table. The common states include:
     * `none`: it indicates not existing. When the `drop` or `create` operation fails and rolls back, it usually becomes the `none` state.
-    * `delete only`, `write only`, `delete reorganization`, `write reorganization`: these four states are intermediate states. For details, see the paper [Online, Asynchronous Schema Change in F1](https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf). These states are not visible in common operations, because the conversion from the intermediate states is so quick. You can see the `write reorganization` state only in `add index` operations, which means that the index data is being added.
+    * `delete only`, `write only`, `delete reorganization`, `write reorganization`: these four states are intermediate states. These states are not visible in common operations, because the conversion from the intermediate states is so quick. You can see the `write reorganization` state only in `add index` operations, which means that the index data is being added.
     * `public`: it indicates existing and usable. When operations like `create table` and `add index/column` are finished, it usually becomes the `public` state, which means that the created table/column/index can be normally read and written now.
 * `SCHEMA_ID`: the ID of the database on which the DDL operations are performed.
 * `TABLE_ID`: the ID of the table on which the DDL operations are performed.