Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions reference/system-databases/cluster-config.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ You can use the `CLUSTER_CONFIG` cluster configuration table to get the current
{{< copyable "sql" >}}

```sql
desc cluster_config;
desc information_schema.cluster_config;
```

```sql
Expand All @@ -37,7 +37,7 @@ The following example shows how to query the `coprocessor` configuration on the
{{< copyable "sql" >}}

```sql
select * from cluster_config where type='tikv' and `key` like 'coprocessor%';
select * from information_schema.cluster_config where type='tikv' and `key` like 'coprocessor%';
```

```sql
Expand Down
8 changes: 4 additions & 4 deletions reference/system-databases/cluster-hardware.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ The `CLUSTER_HARDWARE` hardware system table provides the hardware information o
{{< copyable "sql" >}}

```sql
desc cluster_hardware;
desc information_schema.cluster_hardware;
```

```sql
Expand Down Expand Up @@ -45,15 +45,15 @@ The following example shows how to query the CPU information using the `CLUSTER_
{{< copyable "sql" >}}

```sql
select * from cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores';
select * from information_schema.cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores';
```

```sql
+------+-----------------+-------------+-------------+--------------------+-------+
| 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 |
| tidb | 0.0.0.0:4000 | cpu | cpu | cpu-logical-cores | 8 |
| tidb | 0.0.0.0:4000 | 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 |
Expand Down
18 changes: 9 additions & 9 deletions reference/system-databases/cluster-info.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ The `CLUSTER_INFO` cluster topology table provides the current topology informat
{{< copyable "sql" >}}

```sql
desc cluster_info;
desc information_schema.cluster_info;
```

```sql
Expand Down Expand Up @@ -42,15 +42,15 @@ Field description:
{{< copyable "sql" >}}

```sql
select * from cluster_info;
select * from information_schema.cluster_info;
```

```sql
+------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+
| 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 |
+------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+
+------+-----------------+-----------------+-------------+------------------------------------------+---------------------------+--------------+
| TYPE | INSTANCE | STATUS_ADDRESS | VERSION | GIT_HASH | START_TIME | UPTIME |
+------+-----------------+-----------------+-------------+------------------------------------------+---------------------------+--------------+
| tidb | 0.0.0.0:4000 | 0.0.0.0:10080 | 4.0.0-beta | 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 |
+------+-----------------+-----------------+-------------+------------------------------------------+---------------------------+--------------+
```
30 changes: 15 additions & 15 deletions reference/system-databases/cluster-load.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ The `CLUSTER_LOAD` cluster load table provides the current load information of t
{{< copyable "sql" >}}

```sql
desc cluster_load;
desc information_schema.cluster_load;
```

```sql
Expand Down Expand Up @@ -45,21 +45,21 @@ The following example shows how to query the current load information of cpu usi
{{< copyable "sql" >}}

```sql
select * from cluster_load where device_type='cpu' and device_name='cpu';
select * from information_schema.cluster_load where device_type='cpu' and device_name='cpu';
```

```sql
+------+-----------------+-------------+-------------+--------+---------------+
| TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE |
+------+-----------------+-------------+-------------+--------+---------------+
| tidb | 127.0.0.1:10080 | cpu | cpu | load1 | 1.94 |
| tidb | 127.0.0.1:10080 | cpu | cpu | load5 | 2.16 |
| tidb | 127.0.0.1:10080 | cpu | cpu | load15 | 2.24 |
| pd | 127.0.0.1:2379 | cpu | cpu | load1 | 1.94 |
| pd | 127.0.0.1:2379 | cpu | cpu | load5 | 2.16 |
| pd | 127.0.0.1:2379 | cpu | cpu | load15 | 2.24 |
| tikv | 127.0.0.1:20160 | cpu | cpu | load1 | 1.94287109375 |
| tikv | 127.0.0.1:20160 | cpu | cpu | load5 | 2.15576171875 |
| tikv | 127.0.0.1:20160 | cpu | cpu | load15 | 2.2421875 |
+------+-----------------+-------------+-------------+--------+---------------+
+------+-----------------+-------------+-------------+--------+-------+
| TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE |
+------+-----------------+-------------+-------------+--------+-------+
| tidb | 0.0.0.0:4000 | cpu | cpu | load1 | 0.39 |
| tidb | 0.0.0.0:4000 | cpu | cpu | load5 | 0.36 |
| tidb | 0.0.0.0:4000 | cpu | cpu | load15 | 0.66 |
| pd | 127.0.0.1:2379 | cpu | cpu | load1 | 0.39 |
| pd | 127.0.0.1:2379 | cpu | cpu | load5 | 0.36 |
| pd | 127.0.0.1:2379 | cpu | cpu | load15 | 0.66 |
| tikv | 127.0.0.1:20160 | cpu | cpu | load1 | 0.39 |
| tikv | 127.0.0.1:20160 | cpu | cpu | load5 | 0.36 |
| tikv | 127.0.0.1:20160 | cpu | cpu | load15 | 0.66 |
+------+-----------------+-------------+-------------+--------+-------+
```
22 changes: 11 additions & 11 deletions reference/system-databases/cluster-log.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,19 +13,19 @@ To get the logs of the TiDB cluster before v4.0, you need to log in to each inst
{{< copyable "sql" >}}

```sql
desc cluster_log;
desc information_schema.cluster_log;
```

```sql
+----------+---------------------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+---------------------------+------+------+---------+-------+
| TIME | varchar(32) | YES | | NULL | |
| TYPE | varchar(64) | YES | | NULL | |
| INSTANCE | varchar(64) | YES | | NULL | |
| LEVEL | varchar(8) | YES | | NULL | |
| MESSAGE | var_string(1024) unsigned | YES | | NULL | |
+----------+---------------------------+------+------+---------+-------+
+----------+------------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+------------------+------+------+---------+-------+
| TIME | varchar(32) | YES | | NULL | |
| TYPE | varchar(64) | YES | | NULL | |
| INSTANCE | varchar(64) | YES | | NULL | |
| LEVEL | varchar(8) | YES | | NULL | |
| MESSAGE | var_string(1024) | YES | | NULL | |
+----------+------------------+------+------+---------+-------+
5 rows in set (0.00 sec)
```

Expand All @@ -48,7 +48,7 @@ The following example shows how to query the execution process of a DDL statemen
{{< copyable "sql" >}}

```sql
select * from `CLUSTER_LOG` where message like '%ddl%' and message like '%job%58%' and type='tidb' and time > '2020-03-27 15:39:00';
select * from information_schema.cluster_log where message like '%ddl%' and message like '%job%58%' and type='tidb' and time > '2020-03-27 15:39:00';
```

```sql
Expand Down
6 changes: 3 additions & 3 deletions reference/system-databases/cluster-systeminfo.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,12 @@ category: reference

# CLUSTER_SYSTEMINFO

You can use the `CLUSTER_SYSTEMINFO` kernel parameter table to query the kernel configuration information of the server where all nodes of the cluster are located. Currently, you can query the information of the `sysctl` system.
You can use the `CLUSTER_SYSTEMINFO` kernel parameter table to query the kernel configuration information of the server where all instances of the cluster are located. Currently, you can query the information of the `sysctl` system.

{{< copyable "sql" >}}

```sql
desc cluster_systeminfo;
desc information_schema.cluster_systeminfo;
```

```sql
Expand Down Expand Up @@ -40,7 +40,7 @@ Field description:
The following example shows how to query the kernel version of all servers in the cluster using the `CLUSTER_SYSTEMINFO` system information table.

```sql
select * from CLUSTER_SYSTEMINFO where name like '%kernel.osrelease%'
select * from information_schema.cluster_systeminfo where name like '%kernel.osrelease%'
```

```sql
Expand Down
48 changes: 26 additions & 22 deletions reference/system-databases/inspection-result.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,36 +15,38 @@ The structure of the `information_schema.inspection_result` diagnosis result tab
{{< copyable "sql" >}}

```sql
desc inspection_result;
desc information_schema.inspection_result;
```

```sql
+-----------+--------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+------+---------+-------+
| RULE | varchar(64) | YES | | NULL | |
| ITEM | varchar(64) | YES | | NULL | |
| TYPE | varchar(64) | YES | | NULL | |
| INSTANCE | varchar(64) | YES | | NULL | |
| VALUE | varchar(64) | YES | | NULL | |
| REFERENCE | varchar(64) | YES | | NULL | |
| SEVERITY | varchar(64) | YES | | NULL | |
| DETAILS | varchar(256) | YES | | NULL | |
+-----------+--------------+------+------+---------+-------+
8 rows in set (0.00 sec)
+----------------+--------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+------+---------+-------+
| RULE | varchar(64) | YES | | NULL | |
| ITEM | varchar(64) | YES | | NULL | |
| TYPE | varchar(64) | YES | | NULL | |
| INSTANCE | varchar(64) | YES | | NULL | |
| STATUS_ADDRESS | varchar(64) | YES | | NULL | |
| VALUE | varchar(64) | YES | | NULL | |
| REFERENCE | varchar(64) | YES | | NULL | |
| SEVERITY | varchar(64) | YES | | NULL | |
| DETAILS | varchar(256) | YES | | NULL | |
+----------------+--------------+------+------+---------+-------+
9 rows in set (0.00 sec)
```

Field description:

* `RULE`: The name of the diagnosis rule. Currently, the following rules are available:
* `config`: The consistency check of configuration. If the same configuration is inconsistent on different instances, a `warning` diagnosis result is generated.
* `version`: The consistency check of version. If the same version is inconsistent on different instances, a `warning` diagnosis result is generated.
* `current-load`: If the current system load is too high, the corresponding `warning` diagnosis result is generated.
* `node-load`: If the current system load is too high, the corresponding `warning` diagnosis result is generated.
* `critical-error`: Each module of the system defines critical errors. If a critical error exceeds the threshold within the corresponding time period, a warning diagnosis result is generated.
* `threshold-check`: The diagnosis system checks the thresholds of a large number of metrics. If a threshold is exceeded, the corresponding diagnosis information is generated.
* `ITEM`: Each rule diagnoses different items. This field indicates the specific diagnosis items corresponding to each rule.
* `TYPE`: The instance type of the diagnosis. The optional values are `tidb`, `pd`, and `tikv`.
* `INSTANCE`: The specific address of the diagnosed instance.
* `STATUS_ADDRESS`: The HTTP API service address of the instance.
* `VALUE`: The value of a specific diagnosis item.
* `REFERENCE`: The reference value (threshold value) for this diagnosis item. If the difference between `VALUE` and the threshold is very large, the corresponding diagnosis information is generated.
* `SEVERITY`: The severity level. The optional values are `warning` and `critical`.
Expand All @@ -57,7 +59,7 @@ Diagnose issues currently existing in the cluster.
{{< copyable "sql" >}}

```sql
select * from inspection_result\G
select * from information_schema.inspection_result\G
```

```sql
Expand Down Expand Up @@ -110,7 +112,7 @@ You can also diagnose issues existing within a specified range, such as from "20
{{< copyable "sql" >}}

```sql
select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from inspection_result\G
select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from information_schema.inspection_result\G
```

```sql
Expand Down Expand Up @@ -144,15 +146,15 @@ You can also specify conditions, for example, to query the `critical` level diag
{{< copyable "sql" >}}

```sql
select * from inspection_result where severity='critical';
select * from information_schema.inspection_result where severity='critical';
```

Query only the diagnosis result of the `critical-error` rule:

{{< copyable "sql" >}}

```sql
select * from inspection_result where rule='critical-error';
select * from information_schema.inspection_result where rule='critical-error';
```

## Diagnosis rules
Expand All @@ -164,7 +166,7 @@ You can query the existing diagnosis rules by querying the `inspection_rules` sy
{{< copyable "sql" >}}

```sql
select * from inspection_rules where type='inspection';
select * from information_schema.inspection_rules where type='inspection';
```

```sql
Expand All @@ -173,7 +175,7 @@ select * from inspection_rules where type='inspection';
+-----------------+------------+---------+
| config | inspection | |
| version | inspection | |
| current-load | inspection | |
| node-load | inspection | |
| critical-error | inspection | |
| threshold-check | inspection | |
+-----------------+------------+---------+
Expand All @@ -195,6 +197,7 @@ In the `config` diagnosis rule, the following two diagnosis rules are executed b
status.status-port
log.file.filename
log.slow-query-file
tmp-storage-path

// The whitelist of the PD configuration consistency check
advertise-client-urls
Expand All @@ -214,6 +217,7 @@ In the `config` diagnosis rule, the following two diagnosis rules are executed b
log-file
raftstore.raftdb-path
storage.data-dir
storage.block-cache.capacity
```

* Check whether the values of the following configuration items are as expected.
Expand All @@ -230,7 +234,7 @@ The `version` diagnosis rule checks whether the version hash of the same compone
{{< copyable "sql" >}}

```sql
select * from inspection_result where rule='version'\G
select * from information_schema.inspection_result where rule='version'\G
```

```sql
Expand Down
35 changes: 19 additions & 16 deletions reference/system-databases/inspection-summary.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,22 +13,24 @@ The structure of the `information_schema.inspection_summary` inspection summary
{{< copyable "sql" >}}

```sql
desc inspection_summary;
desc information_schema.inspection_summary;
```

```sql
+--------------+-----------------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-----------------------+------+------+---------+-------+
| RULE | varchar(64) | YES | | NULL | |
| INSTANCE | varchar(64) | YES | | NULL | |
| METRICS_NAME | varchar(64) | YES | | NULL | |
| LABEL | varchar(64) | YES | | NULL | |
| QUANTILE | double unsigned | YES | | NULL | |
| AVG_VALUE | double(22,6) unsigned | YES | | NULL | |
| MIN_VALUE | double(22,6) unsigned | YES | | NULL | |
| MAX_VALUE | double(22,6) unsigned | YES | | NULL | |
+--------------+-----------------------+------+------+---------+-------+
+--------------+--------------+------+------+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+--------------+------+------+---------+-------+
| RULE | varchar(64) | YES | | NULL | |
| INSTANCE | varchar(64) | YES | | NULL | |
| METRICS_NAME | varchar(64) | YES | | NULL | |
| LABEL | varchar(64) | YES | | NULL | |
| QUANTILE | double | YES | | NULL | |
| AVG_VALUE | double(22,6) | YES | | NULL | |
| MIN_VALUE | double(22,6) | YES | | NULL | |
| MAX_VALUE | double(22,6) | YES | | NULL | |
| COMMENT | varchar(256) | YES | | NULL | |
+--------------+--------------+------+------+---------+-------+
9 rows in set
```

Field description:
Expand All @@ -37,10 +39,11 @@ Field description:
* `INSTANCE`: The monitored instance.
* `METRICS_NAME`: The monitoring metrics name.
* `QUANTILE`: Takes effect on monitoring tables that contain `QUANTILE`. You can specify multiple percentiles by pushing down predicates. For example, you can execute `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` to summarize the DDL-related monitoring metrics and query the P80/P90/P99/P999 results. `AVG_VALUE`, `MIN_VALUE`, and `MAX_VALUE` respectively indicate the average value, minimum value, and maximum value of the aggregation.
* `COMMENT`: The comment about the corresponding monitoring metric.

> **Note:**
>
> Because summarizing all results causes overhead, the rules in `information_summary` are triggered passively. That is, the specified `rule` runs only when it displays in the SQL predicate. For example, executing the `select * from inspection_summary` statement returns an empty result set. Executing `select * from inspection_summary where rule in ('read-link', 'ddl')` summarizes the read link and DDL-related monitoring metrics.
> Because summarizing all results causes overhead, it is recommended to display the specific `rule` in the SQL predicate to reduce overhead. For example, executing `select * from inspection_summary where rule in ('read-link', 'ddl')` summarizes the read link and DDL-related monitoring metrics.

Usage example:

Expand All @@ -59,13 +62,13 @@ FROM
(
SELECT
/*+ time_range("2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933")*/ *
FROM inspection_summary WHERE rule='read-link'
FROM information_schema.inspection_summary WHERE rule='read-link'
) t1
JOIN
(
SELECT
/*+ time_range("2020-01-16 16:10:54.933","2020-01-16 16:20:54.933")*/ *
FROM inspection_summary WHERE rule='read-link'
FROM information_schema.inspection_summary WHERE rule='read-link'
) t2
ON t1.metrics_name = t2.metrics_name
and t1.instance = t2.instance
Expand Down
Loading