pingcap · sre-bot · Apr 8, 2020 · Apr 8, 2020 · Apr 8, 2020 · Apr 8, 2020
diff --git a/TOC.md b/TOC.md
@@ -273,6 +273,10 @@
   + System Databases
     - [`mysql`](/reference/system-databases/mysql.md)
     - [`information_schema`](/reference/system-databases/information-schema.md)
+    + `sql-diagnosis`
+      - [`cluster_info`](/reference/system-databases/cluster-info.md)
+      - [`cluster_hardware`](/reference/system-databases/cluster-hardware.md)
+      - [`cluster_config`](/reference/system-databases/cluster-config.md)
   - [Errors Codes](/reference/error-codes.md)
   - [Supported Client Drivers](/reference/supported-clients.md)
   + Garbage Collection (GC)

diff --git a/reference/system-databases/cluster-config.md b/reference/system-databases/cluster-config.md
@@ -0,0 +1,54 @@
+---
+title: CLUSTER_CONFIG
+summary: Learn the `CLUSTER_CONFIG` cluster configuration system table.
+category: reference
+---
+
+# CLUSTER_CONFIG
+
+You can use the `CLUSTER_CONFIG` cluster configuration table to get the current configuration of all TiDB/PD/TiKV nodes in the cluster. For TiDB versions earlier than 4.0, you need to access the HTTP API of each node one by one to collect all component configurations.
+
+{{< copyable "sql" >}}
+
+```sql
+desc cluster_config;
+```
+
+```
++----------+--------------+------+------+---------+-------+
+| Field    | Type         | Null | Key  | Default | Extra |
++----------+--------------+------+------+---------+-------+
+| TYPE     | varchar(64)  | YES  |      | NULL    |       |
+| INSTANCE | varchar(64)  | YES  |      | NULL    |       |
+| KEY      | varchar(256) | YES  |      | NULL    |       |
+| VALUE    | varchar(128) | YES  |      | NULL    |       |
++----------+--------------+------+------+---------+-------+
+```
+
+Field description:
+
+* `TYPE`: The node type. The optional values are `tidb`, `pd`, and `tikv`.
+* `INSTANCE`: The service address of the node.
+* `KEY`: The configuration item name.
+* `VALUE`: The configuration item value.
+
+The following example shows how to query the `coprocessor` configuration on the TiKV node using the `CLUSTER_CONFIG` table:
+
+{{< copyable "sql" >}}
+
+```sql
+select * from cluster_config where type='tikv' and `key` like 'coprocessor%';
+```
+
+```
++------+-----------------+-----------------------------------+----------+
+| TYPE | INSTANCE        | KEY                               | VALUE    |
++------+-----------------+-----------------------------------+----------+
+| tikv | 127.0.0.1:20160 | coprocessor.batch-split-limit     | 10       |
+| tikv | 127.0.0.1:20160 | coprocessor.region-max-keys       | 1.44e+06 |
+| tikv | 127.0.0.1:20160 | coprocessor.region-max-size       | 144MiB   |
+| tikv | 127.0.0.1:20160 | coprocessor.region-split-keys     | 960000   |
+| tikv | 127.0.0.1:20160 | coprocessor.region-split-size     | 96MiB    |
+| tikv | 127.0.0.1:20160 | coprocessor.split-region-on-table | false    |
++------+-----------------+-----------------------------------+----------+
+```
diff --git a/reference/system-databases/cluster-hardware.md b/reference/system-databases/cluster-hardware.md
@@ -0,0 +1,62 @@
+---
+title: CLUSTER_HARDWARE
+summary: Learn the `CLUSTER_HARDWARE` cluster hardware system table.
+category: reference
+---
+
+# CLUSTER_HARDWARE
+
+The `CLUSTER_HARDWARE` hardware system table provides the hardware information of the server where each node of the cluster is located.
+
+{{< copyable "sql" >}}
+
+```sql
+desc cluster_hardware;
+```
+
+```
++-------------+--------------+------+------+---------+-------+
+| Field       | Type         | Null | Key  | Default | Extra |
++-------------+--------------+------+------+---------+-------+
+| TYPE        | varchar(64)  | YES  |      | NULL    |       |
+| INSTANCE    | varchar(64)  | YES  |      | NULL    |       |
+| DEVICE_TYPE | varchar(64)  | YES  |      | NULL    |       |
+| DEVICE_NAME | varchar(64)  | YES  |      | NULL    |       |
+| NAME        | varchar(256) | YES  |      | NULL    |       |
+| VALUE       | varchar(128) | YES  |      | NULL    |       |
++-------------+--------------+------+------+---------+-------+
+```
+
+Field description:
+
+* `TYPE`: Corresponds to the `TYPE` field in the [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) table. The optional values are `tidb`, `pd`, and `tikv`.
+* `INSTANCE`: Corresponds to the `STATUS_ADDRESS` field in the [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) cluster information table.
+* `DEVICE_TYPE`: Hardware type. Currently, you can query the `cpu`, `memory`, `disk`, and `net` types.
+* `DEVICE_NAME`: Hardware name. The value of `DEVICE_NAME` varies with `DEVICE_TYPE`.
+    * `cpu`: The hardware name is cpu.
+    * `memory`: The hardware name is memory.
+    * `disk`: The disk name.
+    * `net`: The network card name.
+* `NAME`: The different information names of the hardware. For example, cpu has two information names: `cpu-logical-cores` and `cpu-physical-cores`, which respectively mean logical core numbers and physical core numbers.
+* `VALUE`: The value of the corresponding hardware information, such as the disk volume and CPU core numbers.
+
+The following example shows how to query the CPU information using the `CLUSTER_HARDWARE` table:
+
+{{< copyable "sql" >}}
+
+```sql
+select * from cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores';
+```
+
+```
++------+-----------------+-------------+-------------+--------------------+-------+
+| TYPE | INSTANCE        | DEVICE_TYPE | DEVICE_NAME | NAME               | VALUE |
++------+-----------------+-------------+-------------+--------------------+-------+
+| tidb | 127.0.0.1:10080 | cpu         | cpu         | cpu-logical-cores  | 8     |
+| tidb | 127.0.0.1:10080 | cpu         | cpu         | cpu-physical-cores | 4     |
+| pd   | 127.0.0.1:2379  | cpu         | cpu         | cpu-logical-cores  | 8     |
+| pd   | 127.0.0.1:2379  | cpu         | cpu         | cpu-physical-cores | 4     |
+| tikv | 127.0.0.1:20160 | cpu         | cpu         | cpu-logical-cores  | 8     |
+| tikv | 127.0.0.1:20160 | cpu         | cpu         | cpu-physical-cores | 4     |
++------+-----------------+-------------+-------------+--------------------+-------+
+```
diff --git a/reference/system-databases/cluster-info.md b/reference/system-databases/cluster-info.md
@@ -0,0 +1,56 @@
+---
+title: CLUSTER_INFO
+summary: Learn the `CLUSTER_INFO` cluster topology information table.
+category: reference
+---
+
+# CLUSTER_INFO
+
+The `CLUSTER_INFO` cluster topology table provides the current topology information of the cluster, the version information of each node, the Git Hash corresponding to the node version, the starting time of each node, and the running time of each node.
+
+{{< copyable "sql" >}}
+
+```sql
+desc cluster_info;
+```
+
+```
++----------------+-------------+------+------+---------+-------+
+| Field          | Type        | Null | Key  | Default | Extra |
++----------------+-------------+------+------+---------+-------+
+| TYPE           | varchar(64) | YES  |      | NULL    |       |
+| INSTANCE       | varchar(64) | YES  |      | NULL    |       |
+| STATUS_ADDRESS | varchar(64) | YES  |      | NULL    |       |
+| VERSION        | varchar(64) | YES  |      | NULL    |       |
+| GIT_HASH       | varchar(64) | YES  |      | NULL    |       |
+| START_TIME     | varchar(32) | YES  |      | NULL    |       |
+| UPTIME         | varchar(32) | YES  |      | NULL    |       |
++----------------+-------------+------+------+---------+-------+
+7 rows in set (0.00 sec)
+```
+
+Field description:
+
+* `TYPE`: The node type. The optional values are `tidb`, `pd`, and `tikv`.
+* `INSTANCE`: The instance address, which is a string in the format of `IP:PORT`.
+* `STATUS_ADDRESS`: The service address of HTTP API. Some commands in tikv-ctl, pd-ctl, or tidb-ctl might use this API and this address. You can also get more cluster information via this address. Refer to [TiDB HTTP API document](https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md) for details.
+* `VERSION`: The semantic version number of the corresponding node. To be compatible with the MySQL version number, the TiDB version is displayed in the format of `${mysql-version}-${tidb-version}`.
+* `GIT_HASH`: The Git Commit Hash when compiling the node version, which is used to identify whether two nodes are of the absolutely consistent version.
+* `START_TIME`: The starting time of the corresponding node.
+* `UPTIME`: The uptime of the corresponding node.
+
+{{< copyable "sql" >}}
+
+```sql
+select * from cluster_info;
+```
+
+```
++------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+
+| TYPE | INSTANCE        | STATUS_ADDRESS  | VERSION                                | GIT_HASH                                 | START_TIME                | UPTIME       |
++------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+
+| tidb | 127.0.0.1:4000  | 127.0.0.1:10080 | 5.7.25-TiDB-v4.0.0-beta-195-gb5ea3232a | b5ea3232afa970f00db7a0fb13ed10857db1912e | 2020-03-02T16:27:28+08:00 | 4m18.845924s |
+| pd   | 127.0.0.1:2379  | 127.0.0.1:2379  | 4.1.0-alpha                            | 4b9bcbc1425c96848042b6d700eb63f84e72b338 | 2020-03-02T16:27:17+08:00 | 4m29.845928s |
+| tikv | 127.0.0.1:20160 | 127.0.0.1:20180 | 4.1.0-alpha                            | 7c4202a1c8faf60eda659dfe0e64e31972488e78 | 2020-03-02T16:27:28+08:00 | 4m18.845929s |
++------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+
+```
diff --git a/reference/system-databases/sql-diagnosis.md b/reference/system-databases/sql-diagnosis.md
@@ -29,9 +29,9 @@ The SQL diagnosis system consists of three major parts:
 
 The cluster information tables bring together the information of all nodes and instances in a cluster. With these tables, you can query all cluster information using only one SQL statement. The following is a list of cluster information tables:
 
-+ From the cluster topology table `information_schema.cluster_info`, you can get the current topology information of the cluster, the version of each node, the Git Hash corresponding to the version, the starting time of each node, and the running time of each node.
-+ From the cluster configuration table `information_schema.cluster_config`, you can get the configuration of all nodes in the cluster. For versions earlier than 4.0, you need to access the HTTP API of each node one by one to get these configuration information.
-+ On the cluster hardware table `information_schema.cluster_hardware`, you can quickly query the cluster hardware information.
++ From the cluster topology table [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md), you can get the current topology information of the cluster, the version of each node, the Git Hash corresponding to the version, the starting time of each node, and the running time of each node.
++ From the cluster configuration table [`information_schema.cluster_config`](/reference/system-databases/cluster-config.md), you can get the configuration of all nodes in the cluster. For versions earlier than 4.0, you need to access the HTTP API of each node one by one to get these configuration information.
++ On the cluster hardware table [`information_schema.cluster_hardware`](/reference/system-databases/cluster-hardware.md), you can quickly query the cluster hardware information.
 + On the cluster load table `information_schema.cluster_load`, you can query the load information of different nodes and hardware types of the cluster.
 + On the kernel parameter table `information_schema.cluster_systeminfo`, you can query the kernel configuration information of different nodes in the cluster. Currently, TiDB supports querying the sysctl information.
 + On the cluster log table `information_schema.cluster_log`, you can query cluster logs. By pushing down query conditions to each node, the impact of the query on cluster performance is less than that of the `grep` command.