From a55b1586dfb6ce9138b2bf2e871a17685251d9bd Mon Sep 17 00:00:00 2001 From: guoni Date: Mon, 16 Mar 2020 10:49:31 +0800 Subject: [PATCH 01/43] add sql-dignosis --- reference/system-databases/sql-dignosis.md | 668 +++++++++++++++++++++ 1 file changed, 668 insertions(+) create mode 100644 reference/system-databases/sql-dignosis.md diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md new file mode 100644 index 000000000000..c69d7b8f8935 --- /dev/null +++ b/reference/system-databases/sql-dignosis.md @@ -0,0 +1,668 @@ +--- +title: Sql Dignosis Schema +category: reference +--- + +# SQL DIAGNOSIS +SQL 诊断功能是由 TiDB 4.0 引入的新特性，主要用于提升 TiDB 问题定位效率，相较于 4.0 版本之前，不同的信息需要使用不同工具获取的异构方式， +新的 SQL 诊断对这些离散的信息进行了整体设计，它通过将系统的各种维度信息通过系统表的方式向上层提供了一致的接口方式以及监控汇总与自动诊断，方便了用户对于集群信息的查询。 + +SQL 诊断共分三大块： +* **集群信息表**：TiDB 4.0 诊断功能为原先离散的各节点实例信息提供了一致的获取方式，它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、Statements、日志完全打通，让使用者能够统一使用 SQL 查询。 +* **集群监控与汇总**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 +且由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，从而让用户能以一种更加便捷的方式从众多监控中找出异常的监控项。 +* **诊断结果表**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 + + +## 集群信息表 +集群信息表包括集群拓扑、集群配置、集群硬件、内核参数、系统负载、日志、集群监控等，这些集群表将一个集群中的所有节点实例的信息都汇聚到了一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 +新增的集群信息表如下： + +* 集群拓扑表 `information_schema.cluster_info` 主要是用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 +* 集群配置表 `information_schema.cluster_config` 用于获取集群当前所有节点的配置，TiDB 4.0 之前的版本必须逐个访问各个节点的 HTTP API。 +* 集群硬件表 `information_schema.cluster_hardware` 主要用于快速查询集群硬件信息。 +* 集群负载表 `information_schema.cluster_load` 主要用于查询集群不同节点的不同硬件类型的负载信息。 +* 内核参数表 `information_schema.cluster_systeminfo` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 +* 集群日志表 `information_schema.cluster_log` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，性能影响小于等 grep 命令。 + +TiDB 4.0 之前的以下系统表，只能查看当前节点，TiDB 4.0 实现了对应的集群表，可以在单个 TiDB 节点上拥有整个集群的全局视图。 +这些表目前都位于 information_schema 中，查询形式上与其他 information_schema 系统表一致。 + +## CLUSTER_INFO 表 + +集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 + +``` +mysql> 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) +``` + +字段解释： + +* TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 +* INSTANCE：实例地址，始终为 IP:PORT 格式的字符串 +* STATUS_ADDRESS：HTTP API 服务地址，部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API，会使用这个地址，用户也可以通过这个地址获取一些额外的集群信息，具体 HTTP API 参考官方文档 +* VERSION：对应节点的语义版本号，TiDB 版本为了兼容 MySQL 的版本号，以 ${mysql-version}-${tidb-version} 方式展示 +* GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 +* START_TIME：对应节点的启动时间 +* UPTIME：对应节点已经运行的时间 + +```sql +mysql> 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 | ++------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ +3 rows in set (0.01 sec) +``` + + +## CLUSTER_CONFIG 表 + +集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 + +``` +mysql> 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 | | ++----------+--------------+------+------+---------+-------+ +4 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 +* KEY：配置项名 +* VALUE：配置项值 + +具体示例，查询 TiKV 节点的 `coprocessor` 相关配置： + +```sql +mysql> 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 | ++------+-----------------+-----------------------------------+----------+ +6 rows in set (1.04 sec) +``` + +## CLUSTER_HARDWARE +集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 + +```field +mysql> 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 | | ++-------------+--------------+------+------+---------+-------+ +6 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 +* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net +* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同 + * cpu：硬件名为 cpu + * memory：硬件名为 memory + * disk：磁盘名 + * net：NIC 名 +* NAME：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores`/`cpu-physical-cores`，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME +* VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 + +具体示例，查询集群的 CPU 信息： + +```sql +mysql> 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 | ++------+-----------------+-------------+-------------+--------------------+-------+ +6 rows in set (0.26 sec) +``` + +## CLUSTER_LOAD +集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 + +```field +mysql> desc cluster_load; ++-------------+--------------+------+------+---------+-------+ +| 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 | | ++-------------+--------------+------+------+---------+-------+ +6 rows in set (0.00 sec) +``` + +字段解释： +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net。 +* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同。 + * cpu：硬件名为 cpu。 + * disk：磁盘名。 + * net：NIC 名。 + * memory：硬件名为 memory。 +* NAME：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 CPU 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 +* VALUE：对应硬件负载的值，比如 CPU 的 1min/5min/15min 平均负载。 + + +具体示例，查询集群的 CPU 负载信息： + +```sql +mysql> select * from cluster_load where device_type='cpu' and device_name='cpu'; ++------+-----------------+-------------+-------------+--------+---------------+ +| 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 | ++------+-----------------+-------------+-------------+--------+---------------+ +9 rows in set (0.52 sec) +``` + +## CLUSTER_SYSTEMINFO +集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 + +```field +mysql> desc cluster_systeminfo; ++-------------+--------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++-------------+--------------+------+------+---------+-------+ +| TYPE | varchar(64) | YES | | NULL | | +| INSTANCE | varchar(64) | YES | | NULL | | +| SYSTEM_TYPE | varchar(64) | YES | | NULL | | +| SYSTEM_NAME | varchar(64) | YES | | NULL | | +| NAME | varchar(256) | YES | | NULL | | +| VALUE | varchar(128) | YES | | NULL | | ++-------------+--------------+------+------+---------+-------+ +6 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* SYSTEM_TYPE：系统类型，目前可以查询的系统类型有 system。 +* SYSTEM_NAME：目前可以查询的 SYSTEM_NAME 为 sysctl。 +* NAME：sysctl 对应的配置名。 +* VALUE：sysctl 对应配置项的值。 + +```sql +mysql> select * from cluster_systeminfo where name like '%fd%'; ++------+-----------------+-------------+-------------+-------------------------------+-------+ +| TYPE | INSTANCE | SYSTEM_TYPE | SYSTEM_NAME | NAME | VALUE | ++------+-----------------+-------------+-------------+-------------------------------+-------+ +| tidb | 127.0.0.1:10080 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | +| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.client_fd_count | 98 | +| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.observer_fd_count | 0 | +| pd | 127.0.0.1:2379 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | +| pd | 127.0.0.1:2379 | system | sysctl | net.necp.client_fd_count | 98 | +| pd | 127.0.0.1:2379 | system | sysctl | net.necp.observer_fd_count | 0 | ++------+-----------------+-------------+-------------+-------------------------------+-------+ +6 rows in set (0.04 sec) +``` + +## CLUSTER_LOG +集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 + +```field +mysql> desc cluster_log; ++----------+---------------------------+------+------+---------+-------+ +| 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 | | ++----------+---------------------------+------+------+---------+-------+ +5 rows in set (0.00 sec) +``` + +字段解释： +* TIME：日志打印时间。 +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 INSTANCE 字段。 +* LEVEL：日志级别。 +* MESSAGE：日志内容。 + +> **注意事项：** +>日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，比如 select * from cluter_log where instance='tikv-1' 只会在 tikv-1 执行日志搜索。 +>message 字段支持 like 和 regexp 正则表达式，对应的 pattern 会编译为 regexp，同时指定多个 message 条件，相当于 grep 命令的 pipeline 形式，例如：select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' 相当于在集群所有节点执行 grep 'coprocessor' xxx.log | grep -E '.*slow.*'。 + +在TiDB 4.0 之前要获取集群的日志需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，可以更高效地提供一个全局时间有序的日志搜索结果，对于全链路事件跟踪提供便利的手段，比如按照某一个 region id 搜索日志，可以查询该 region 生命周期的所有日志，类似的通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 + +## 集群监控表 + +TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， +并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，本文不对各个表进行逐个解释。用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 + +```field +mysql> desc metrics_tables; ++------------+-----------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++------------+-----------------+------+------+---------+-------+ +| TABLE_NAME | varchar(64) | YES | | NULL | | +| PROMQL | varchar(64) | YES | | NULL | | +| LABELS | varchar(64) | YES | | NULL | | +| QUANTILE | double unsigned | YES | | NULL | | +| COMMENT | varchar(256) | YES | | NULL | | ++------------+-----------------+------+------+---------+-------+ +5 rows in set (0.00 sec) +``` + +表 `metrics_tables` 的字段解释： +* TABLE_NAME：对应于 metrics_schema 中的表名。 +* PROMQL：监控表的主要原理是将 SQL 映射成 PromQL，并将 Promethues 结果转换成 SQL 查询结果。这个字段是 PromQL 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* LABELS：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 PromQL 也会改变。 +* QUANTILE：百分位，对于直方图类型的监控数据，指定一个默认百分位，如果值为 0，表示该监控表对应的监控不是直方图。 +* COMMENT：是对这个监控表的解释。 + +监控表示例: + +`tidb_query_duration` 的表结构如下，从表的 COMMENT 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 + +```sql +metrics_schema> show create table tidb_query_duration; ++---------------------+--------------------------------------------------------------------------------------------------------------------+ +| Table | Create Table | ++---------------------+--------------------------------------------------------------------------------------------------------------------+ +| tidb_query_duration | CREATE TABLE `tidb_query_duration` ( | +| | `time` datetime unsigned DEFAULT NULL, | +| | `instance` varchar(512) DEFAULT NULL, | +| | `sql_type` varchar(512) DEFAULT NULL, | +| | `quantile` double unsigned DEFAULT NULL, | +| | `value` double unsigned DEFAULT NULL | +| | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='The quantile of TiDB query durations(second)' | ++---------------------+--------------------------------------------------------------------------------------------------------------------+ +``` + +比如 tikv_admin_apply 有三个 label，对应的表也会有三个额外的列 +```sql +mysql> desc metrics_schema.tikv_admin_apply; ++----------+-------------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++----------+-------------------+------+------+---------+-------+ +| time | datetime unsigned | YES | | NULL | | +| instance | varchar(512) | YES | | NULL | | +| type | varchar(512) | YES | | NULL | | +| status | varchar(512) | YES | | NULL | | +| value | double unsigned | YES | | NULL | | ++----------+-------------------+------+------+---------+-------+ +5 rows in set (0.00 sec) +``` + +下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，internal 类型的 P90 耗时是 0.00327。instance 字段是 TiDB 示例的地址。 +``` +metrics_schema> select * from tidb_query_duration where value is not null and time=now() and quantile=0.90; ++---------------------+-------------------+----------+----------+------------------+ +| time | instance | sql_type | quantile | value | ++---------------------+-------------------+----------+----------+------------------+ +| 2020-03-08 13:34:40 | 172.16.5.40:10089 | Select | 0.9 | 0.0384 | +| 2020-03-08 13:34:40 | 172.16.5.40:10089 | internal | 0.9 | 0.00327692307692 | ++---------------------+-------------------+----------+----------+------------------+ +``` + +监控表 session 变量： + +* tidb_metric_query_step：查询的分辨率步长。从 Promethues 的 query_range 数据时需要指定 start，end，step，其中 step 会使用该变量的值 +* tidb_metric_query_range_duration：查询监控时，会将 PROMQL 中的 $RANGE_DURATION 替换成该变量的值，默认值是 60 秒 + +## 监控汇总表 + +由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： + +* information_schema.metrics_summary +* information_schema.metrics_summary_by_label + +这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 +两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 + +```field +mysql> desc metrics_summary; ++--------------+-----------------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++--------------+-----------------------+------+------+---------+-------+ +| METRICS_NAME | varchar(64) | YES | | NULL | | +| QUANTILE | double unsigned | YES | | NULL | | +| SUM_VALUE | double(22,6) 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 | | +| COMMENT | varchar(256) | YES | | NULL | | ++--------------+-----------------------+------+------+---------+-------+ +7 rows in set (0.00 sec) +``` + +字段解释： + +* METRICS_NAME：监控表名 +* QUANTILE：百分位，可以通过 SQL 语句指定 QUANTILE，例如 + * select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据 + * select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999) 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据 +* SUM_VALUE / AVG_VALUE / MIN_VALUE / MAX_VALUE +* COMMENT：对应监控的解释 + +具体查询示例： +以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 information_schema.metrics_summary 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL： + +``` +mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * + from information_schema.`METRICS_SUMMARY` + where metrics_name like 'tidb%duration' + and avg_value > 0 + and quantile = 0.99 + order by avg_value desc + limit 3\G +***************************[ 1. row ]*************************** +METRICS_NAME | tidb_get_token_duration +QUANTILE | 0.99 +SUM_VALUE | 8.972509 +AVG_VALUE | 0.996945 +MIN_VALUE | 0.996515 +MAX_VALUE | 0.997458 +COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second) +***************************[ 2. row ]*************************** +METRICS_NAME | tidb_query_duration +QUANTILE | 0.99 +SUM_VALUE | 0.269079 +AVG_VALUE | 0.007272 +MIN_VALUE | 0.000667 +MAX_VALUE | 0.01554 +COMMENT | The quantile of TiDB query durations(second) +***************************[ 3. row ]*************************** +METRICS_NAME | tidb_kv_request_duration +QUANTILE | 0.99 +SUM_VALUE | 0.170232 +AVG_VALUE | 0.004601 +MIN_VALUE | 0.000975 +MAX_VALUE | 0.013 +COMMENT | The quantile of kv requests durations by store +``` + +类似的，查询 metrics_summary_by_label 监控汇总表结果如下： + +``` +mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * + from information_schema.`METRICS_SUMMARY_BY_LABEL` + where metrics_name like 'tidb%duration' + and avg_value > 0 + and quantile = 0.99 + order by avg_value desc + limit 10\G +***************************[ 1. row ]*************************** +INSTANCE | 172.16.5.40:10089 +METRICS_NAME | tidb_get_token_duration +LABEL | +QUANTILE | 0.99 +SUM_VALUE | 8.972509 +AVG_VALUE | 0.996945 +MIN_VALUE | 0.996515 +MAX_VALUE | 0.997458 +COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second) +***************************[ 2. row ]*************************** +INSTANCE | 172.16.5.40:10089 +METRICS_NAME | tidb_query_duration +LABEL | Select +QUANTILE | 0.99 +SUM_VALUE | 0.072083 +AVG_VALUE | 0.008009 +MIN_VALUE | 0.007905 +MAX_VALUE | 0.008241 +COMMENT | The quantile of TiDB query durations(second) +***************************[ 3. row ]*************************** +INSTANCE | 172.16.5.40:10089 +METRICS_NAME | tidb_query_duration +LABEL | Rollback +QUANTILE | 0.99 +SUM_VALUE | 0.072083 +AVG_VALUE | 0.008009 +MIN_VALUE | 0.007905 +MAX_VALUE | 0.008241 +COMMENT | The quantile of TiDB query durations(second) +``` + +前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 LABEL, 以上面查询结果的第 2, 3 行为例：分别表示 `tidb_query_duration` 的 Select/Rollback 类型的语句平均耗时非常高。 + +除以上示例之外，监控汇总表可以通过两个时间段的全链路监控对比，迅速找出监控数据变化最大的模块，快速定位瓶颈，以下对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： + +* 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00") +* 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") +对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 TIME_RANGE 是用于指定查询时间的 Hint。 + +从上述查询结果可以看出： +* t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍 +* t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍 +* t1 时间段内的 tidb_kv_write_size （tidb 每个事务写入的 kv 大小） 比 t2 时间段高了 1.96 倍 + +通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 + +反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项: +``` +mysql> SELECT + t2.avg_value / t1.avg_value AS ratio, + t1.metrics_name, + t1.avg_value, + t2.avg_value, + t2.comment + FROM + ( + SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ + * + FROM information_schema.metrics_summary + ) t1 + JOIN + ( + SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ + * + FROM information_schema.metrics_summary + ) t2 + ON t1.metrics_name = t2.metrics_name + ORDER BY + ratio DESC limit 10; ++----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +| ratio | metrics_name | avg_value | avg_value | comment | ++----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +| 5865.59537065 | tidb_slow_query_cop_process_total_time | 0.016333 | 95.804724 | The total time of TiDB slow query statistics with slow query total cop process time(second) | +| 3648.74109023 | tidb_distsql_partial_scan_key_total_num | 10865.666667 | 39646004.4394 | The total num of distsql partial scan key numbers | +| 267.002351165 | tidb_slow_query_cop_wait_total_time | 0.003333 | 0.890008 | The total time of TiDB slow query statistics with slow query total cop wait time(second) | +| 192.43267836 | tikv_cop_total_response_total_size | 2515333.66667 | 484032394.445 | | +| 192.43267836 | tikv_cop_total_response_size | 41922.227778 | 8067206.57408 | | +| 152.780296296 | tidb_distsql_scan_key_total_num | 5304.333333 | 810397.618317 | The total num of distsql scan numbers | +| 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) | +| 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | | +| 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | | +| 101.635495394 | tikv_cop_total_kv_cursor_operations | 1070.875 | 108838.91113 | | ++----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +``` + +上面查询结果表示： + +* t2 时间段内的 tidb_slow_query_cop_process_total_time （tidb 慢查询中的 cop process 耗时 ） 比 t1 时间段高了 5865 倍 +* t2 时间段内的 tidb_distsql_partial_scan_key_total_num（tidb 的 distsql 请求扫描key 的数量） 比 t1 时间段高了 3648 倍 +* t2 时间段内的 tikv_cop_total_response_size（tikv 的 cop 请求结果的大小 ） 比 t1 时间段高了 192 倍 +* t2 时间段内的 tikv_cop_scan_details（tikv 的 cop 请求的 scan ） 比 t1 时间段高了 105 倍 + +通过上面两个时间段对比查询可以大致了解集群在这 2 个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 cop task 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 + +实际上，在 t1 ~ t2 整个时间段内都在跑 go-ycsb 的压测，然后在 t2 时间段跑了 20 个 tpch 的查询，所以是因为 tpch 大查询导致了很多的 cop 请求。 + +## 诊断结果表 + +前面介绍了集群信息表和集群监控表，并通过 SQL 演示了如何通过查询这些表来发现集群问题，比如通过 information_schema.cluster_config 发现集群不同节点配置不一致，通过 information_schema.cluster_info 发现是否存在组件版本不一样。 +不过手动执行固定模式的 SQL 排查集群问题是低效的，为了进一步优化用户体验，方便用户使用，于是我们利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断： + +* information_schema.inspection_result +* information_schema.inspection_summary + +该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 SQL select * from information_schema.inspection_result 来触发内部的诊断。 + +## INSPECTION_RESULT + +TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 + +诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL select * from inspection_result 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 + +诊断结果表 `information_schema.inspection_result` 的表结构如下： +``` +mysql> desc inspection_result; ++-----------+--------------+------+------+---------+-------+ +| 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) +``` + +字段解释： +* RULE：诊断规则，目前实现了 + * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 + * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 + * current-load：如果当前系统负载太高，会生成对应的 warning 诊断结果 + * critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果 + * threshold-check：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息 +* ITEM：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 +* TYPE：诊断的实例类型，可能是 tidb/tikv/pd +* INSTANCE：诊断的具体实例 +* VALUE：针对这个诊断项得到的值 +* REFERENCE：针对这个诊断项的参考值（阈值），如果 VALUE 和阈值差距比较大，就会产生对应的结果 +* SEVERITY：严重程度，warning/critical +* DETAILS：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接 + +诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比，如果结果超过阈值或低于阈值将生成 warning / critical 的结果，并在 details 列中提供进一步信息。 + +查询已有的诊断规则: + +``` +mysql> select * from inspection_rules where type='inspection'; ++-----------------+------------+---------+ +| NAME | TYPE | COMMENT | ++-----------------+------------+---------+ +| config | inspection | | +| version | inspection | | +| current-load | inspection | | +| critical-error | inspection | | +| threshold-check | inspection | | ++-----------------+------------+---------+ +5 rows in set (0.00 sec) +``` + +以上的监控汇总表是按照集群所有的监控进行汇总，但是在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8， +如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 + +诊断汇总表 `information_schema.inspection_summary` 的表结构如下： + +``` +mysql> desc inspection_summary; ++--------------+-----------------------+------+------+---------+-------+ +| 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 | | ++--------------+-----------------------+------+------+---------+-------+ +8 rows in set (0.00 sec) +``` + +字段解释： + +* RULE：汇总规则，由于规则在持续添加，以下列表可能已经过时，最新的规则列表可以通过 select * from inspection_rules where type='summary' 查询 +* INSTANCE：监控的具体实例 +* METRIC_NAME：监控表 +* QUANTILE：对于包含 QUANTILE 的监控表有效，可以通过谓词下推指定多个百分位，比如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 ddl 相关监控，查询百分位为 80/90/99/999 的结果。 AVG_VALUE/MIN_VALUE/MAX_VALUE 分别表示聚合的平均、最小、最大值。 + +> **注意事项：** +> +>由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即通过 SQL 的谓词中显示指定的 rule 才会运行。比如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 + +使用示例: + +诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */ * from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： +``` +诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: + +mysql> SELECT + t1.avg_value / t2.avg_value AS ratio, + t1.*, + t2.* + 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' + ) 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' + ) t2 + ON t1.metrics_name = t2.metrics_name + and t1.instance = t2.instance + and t1.label = t2.label + ORDER BY + ratio DESC; +``` From 0ceb83a1b6735d3e1eb137f047f3870ec53750ca Mon Sep 17 00:00:00 2001 From: guoni Date: Mon, 16 Mar 2020 11:10:03 +0800 Subject: [PATCH 02/43] fmt --- reference/system-databases/sql-dignosis.md | 46 ++++++++++++++++++++-- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index c69d7b8f8935..08c0b4a180e2 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -285,7 +285,7 @@ mysql> desc cluster_log; ## 集群监控表 -TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， +集群信息表固然给力，但光有集群信息表还不够，为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， 并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，本文不对各个表进行逐个解释。用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 ```field @@ -481,7 +481,46 @@ COMMENT | The quantile of TiDB query durations(second) * 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") 对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 TIME_RANGE 是用于指定查询时间的 Hint。 -从上述查询结果可以看出： +查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项: +``` +mysql> SELECT + t1.avg_value / t2.avg_value AS ratio, + t1.metrics_name, + t1.avg_value, + t2.avg_value, + t2.comment + FROM + ( + SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ + * + FROM information_schema.metrics_summary + ) t1 + JOIN + ( + SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ + * + FROM information_schema.metrics_summary + ) t2 + ON t1.metrics_name = t2.metrics_name + ORDER BY + ratio DESC limit 10; ++----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ +| ratio | metrics_name | avg_value | avg_value | comment | ++----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ +| 17.6439787379 | tikv_region_average_written_bytes | 30816827.0953 | 1746591.71568 | The average rate of writing bytes to Regions per TiKV instance | +| 8.88407551364 | tikv_region_average_written_keys | 108557.034612 | 12219.283193 | The average rate of written keys to Regions per TiKV instance | +| 6.4105335594 | tidb_kv_write_num | 4493.293654 | 700.923505 | The quantile of kv write times per transaction execution | +| 2.99993333333 | tidb_gc_total_count | 1.0 | 0.333341 | The total count of kv storage garbage collection time durations | +| 2.66412165823 | tikv_engine_avg_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | +| 2.66412165823 | tikv_engine_max_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | +| 2.49994444321 | tikv_region_change | -0.277778 | -0.111114 | The count of region change per TiKV instance | +| 2.16063829787 | etcd_wal_fsync_duration | 0.002539 | 0.001175 | The quantile time consumed of writing WAL into the persistent storage | +| 2.06089264604 | node_memory_free | 4541448192.0 | 2203631616.0 | | +| 1.96749064186 | tidb_kv_write_size | 514489.28 | 261495.159902 | The quantile of kv write size per transaction execution | ++----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ +``` + +查询结果表示： * t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍 * t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍 * t1 时间段内的 tidb_kv_write_size （tidb 每个事务写入的 kv 大小） 比 t2 时间段高了 1.96 倍 @@ -540,7 +579,7 @@ mysql> SELECT ## 诊断结果表 -前面介绍了集群信息表和集群监控表，并通过 SQL 演示了如何通过查询这些表来发现集群问题，比如通过 information_schema.cluster_config 发现集群不同节点配置不一致，通过 information_schema.cluster_info 发现是否存在组件版本不一样。 +前面介绍了集群信息表和集群监控表，并通过 SQL 演示了如何通过查询这些表来发现集群问题，比如通过 information_schema.cluster_config 发现集群不同节点配置不一致，通过 information_schema.metrics_summary 发现指定时间范围内 TiDB 集群中平均耗时最高的监控项。 不过手动执行固定模式的 SQL 排查集群问题是低效的，为了进一步优化用户体验，方便用户使用，于是我们利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断： * information_schema.inspection_result @@ -605,6 +644,7 @@ mysql> select * from inspection_rules where type='inspection'; 5 rows in set (0.00 sec) ``` +## INSPECTION_SUMMARY 以上的监控汇总表是按照集群所有的监控进行汇总，但是在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8， 如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 From 5e0f48a51b0e1203231fd0e2454f7fda5e683d62 Mon Sep 17 00:00:00 2001 From: guoni Date: Mon, 16 Mar 2020 11:17:47 +0800 Subject: [PATCH 03/43] fix lint --- reference/system-databases/sql-dignosis.md | 105 ++++++++++++--------- 1 file changed, 58 insertions(+), 47 deletions(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 08c0b4a180e2..47688b98c298 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -1,20 +1,17 @@ ---- -title: Sql Dignosis Schema -category: reference ---- - # SQL DIAGNOSIS + SQL 诊断功能是由 TiDB 4.0 引入的新特性，主要用于提升 TiDB 问题定位效率，相较于 4.0 版本之前，不同的信息需要使用不同工具获取的异构方式， 新的 SQL 诊断对这些离散的信息进行了整体设计，它通过将系统的各种维度信息通过系统表的方式向上层提供了一致的接口方式以及监控汇总与自动诊断，方便了用户对于集群信息的查询。 SQL 诊断共分三大块： + * **集群信息表**：TiDB 4.0 诊断功能为原先离散的各节点实例信息提供了一致的获取方式，它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、Statements、日志完全打通，让使用者能够统一使用 SQL 查询。 * **集群监控与汇总**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 且由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，从而让用户能以一种更加便捷的方式从众多监控中找出异常的监控项。 * **诊断结果表**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 - ## 集群信息表 + 集群信息表包括集群拓扑、集群配置、集群硬件、内核参数、系统负载、日志、集群监控等，这些集群表将一个集群中的所有节点实例的信息都汇聚到了一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 新增的集群信息表如下： @@ -32,7 +29,7 @@ TiDB 4.0 之前的以下系统表，只能查看当前节点，TiDB 4.0 实现 集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 -``` +```sql mysql> desc cluster_info; +----------------+-------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | @@ -70,12 +67,11 @@ mysql> select * from cluster_info; 3 rows in set (0.01 sec) ``` - ## CLUSTER_CONFIG 表 集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 -``` +```sql mysql> desc cluster_config; +----------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | @@ -113,6 +109,7 @@ mysql> select * from cluster_config where type='tikv' and `key` like 'coprocesso ``` ## CLUSTER_HARDWARE + 集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 ```field @@ -161,6 +158,7 @@ mysql> select * from cluster_hardware where device_type='cpu' and device_name='c ``` ## CLUSTER_LOAD + 集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 ```field @@ -179,6 +177,7 @@ mysql> desc cluster_load; ``` 字段解释： + * TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 * INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 * DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net。 @@ -190,7 +189,6 @@ mysql> desc cluster_load; * NAME：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 CPU 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 * VALUE：对应硬件负载的值，比如 CPU 的 1min/5min/15min 平均负载。 - 具体示例，查询集群的 CPU 负载信息： ```sql @@ -212,6 +210,7 @@ mysql> select * from cluster_load where device_type='cpu' and device_name='cpu'; ``` ## CLUSTER_SYSTEMINFO + 集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 ```field @@ -254,6 +253,7 @@ mysql> select * from cluster_systeminfo where name like '%fd%'; ``` ## CLUSTER_LOG + 集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 ```field @@ -271,6 +271,7 @@ mysql> desc cluster_log; ``` 字段解释： + * TIME：日志打印时间。 * TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 * INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 INSTANCE 字段。 @@ -303,6 +304,7 @@ mysql> desc metrics_tables; ``` 表 `metrics_tables` 的字段解释： + * TABLE_NAME：对应于 metrics_schema 中的表名。 * PROMQL：监控表的主要原理是将 SQL 映射成 PromQL，并将 Promethues 结果转换成 SQL 查询结果。这个字段是 PromQL 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 * LABELS：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 PromQL 也会改变。 @@ -329,6 +331,7 @@ metrics_schema> show create table tidb_query_duration; ``` 比如 tikv_admin_apply 有三个 label，对应的表也会有三个额外的列 + ```sql mysql> desc metrics_schema.tikv_admin_apply; +----------+-------------------+------+------+---------+-------+ @@ -344,7 +347,8 @@ mysql> desc metrics_schema.tikv_admin_apply; ``` 下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，internal 类型的 P90 耗时是 0.00327。instance 字段是 TiDB 示例的地址。 -``` + +```sql metrics_schema> select * from tidb_query_duration where value is not null and time=now() and quantile=0.90; +---------------------+-------------------+----------+----------+------------------+ | time | instance | sql_type | quantile | value | @@ -397,7 +401,7 @@ mysql> desc metrics_summary; 具体查询示例： 以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 information_schema.metrics_summary 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL： -``` +```sql mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * from information_schema.`METRICS_SUMMARY` where metrics_name like 'tidb%duration' @@ -433,7 +437,7 @@ COMMENT | The quantile of kv requests durations by store 类似的，查询 metrics_summary_by_label 监控汇总表结果如下： -``` +```sql mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * from information_schema.`METRICS_SUMMARY_BY_LABEL` where metrics_name like 'tidb%duration' @@ -482,27 +486,28 @@ COMMENT | The quantile of TiDB query durations(second) 对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 TIME_RANGE 是用于指定查询时间的 Hint。 查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项: -``` -mysql> SELECT + +```sql +mysql> SELECT t1.avg_value / t2.avg_value AS ratio, t1.metrics_name, t1.avg_value, t2.avg_value, t2.comment - FROM + FROM ( SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * + * FROM information_schema.metrics_summary - ) t1 + ) t1 JOIN ( SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * + * FROM information_schema.metrics_summary ) t2 - ON t1.metrics_name = t2.metrics_name - ORDER BY + ON t1.metrics_name = t2.metrics_name + ORDER BY ratio DESC limit 10; +----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ | ratio | metrics_name | avg_value | avg_value | comment | @@ -521,6 +526,7 @@ mysql> SELECT ``` 查询结果表示： + * t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍 * t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍 * t1 时间段内的 tidb_kv_write_size （tidb 每个事务写入的 kv 大小） 比 t2 时间段高了 1.96 倍 @@ -528,27 +534,28 @@ mysql> SELECT 通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项: -``` -mysql> SELECT + +```sql +mysql> SELECT t2.avg_value / t1.avg_value AS ratio, t1.metrics_name, t1.avg_value, t2.avg_value, t2.comment - FROM + FROM ( SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * + * FROM information_schema.metrics_summary - ) t1 + ) t1 JOIN ( SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * + * FROM information_schema.metrics_summary ) t2 - ON t1.metrics_name = t2.metrics_name - ORDER BY + ON t1.metrics_name = t2.metrics_name + ORDER BY ratio DESC limit 10; +----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ | ratio | metrics_name | avg_value | avg_value | comment | @@ -594,7 +601,8 @@ TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL select * from inspection_result 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 诊断结果表 `information_schema.inspection_result` 的表结构如下： -``` + +```sql mysql> desc inspection_result; +-----------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | @@ -612,6 +620,7 @@ mysql> desc inspection_result; ``` 字段解释： + * RULE：诊断规则，目前实现了 * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 @@ -630,7 +639,7 @@ mysql> desc inspection_result; 查询已有的诊断规则: -``` +```sql mysql> select * from inspection_rules where type='inspection'; +-----------------+------------+---------+ | NAME | TYPE | COMMENT | @@ -645,12 +654,13 @@ mysql> select * from inspection_rules where type='inspection'; ``` ## INSPECTION_SUMMARY + 以上的监控汇总表是按照集群所有的监控进行汇总，但是在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8， 如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 诊断汇总表 `information_schema.inspection_summary` 的表结构如下： -``` +```sql mysql> desc inspection_summary; +--------------+-----------------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | @@ -680,29 +690,30 @@ mysql> desc inspection_summary; 使用示例: -诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */ * from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： -``` +诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： + +```sql 诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: -mysql> SELECT - t1.avg_value / t2.avg_value AS ratio, - t1.*, - t2.* - FROM +mysql> SELECT + t1.avg_value / t2.avg_value AS ratio, + t1.*, + t2.* + FROM ( - SELECT - /*+ time_range("2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933")*/ * + SELECT + /*+ time_range("2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933")*/ * FROM inspection_summary WHERE rule='read-link' - ) t1 + ) t1 JOIN ( - SELECT + SELECT /*+ time_range("2020-01-16 16:10:54.933","2020-01-16 16:20:54.933")*/ * FROM inspection_summary WHERE rule='read-link' ) t2 - ON t1.metrics_name = t2.metrics_name - and t1.instance = t2.instance - and t1.label = t2.label - ORDER BY + ON t1.metrics_name = t2.metrics_name + and t1.instance = t2.instance + and t1.label = t2.label + ORDER BY ratio DESC; ``` From 8d703b738779b10b5bc9c623b683960e1852b084 Mon Sep 17 00:00:00 2001 From: guoni Date: Mon, 16 Mar 2020 16:46:48 +0800 Subject: [PATCH 04/43] fix lint --- reference/system-databases/sql-dignosis.md | 30 +++++++++++----------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 47688b98c298..8fd9a25d0483 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -133,10 +133,10 @@ mysql> desc cluster_hardware; * INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 * DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net * DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同 - * cpu：硬件名为 cpu - * memory：硬件名为 memory - * disk：磁盘名 - * net：NIC 名 + * cpu：硬件名为 cpu + * memory：硬件名为 memory + * disk：磁盘名 + * net：NIC 名 * NAME：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores`/`cpu-physical-cores`，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME * VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 @@ -182,10 +182,10 @@ mysql> desc cluster_load; * INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 * DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net。 * DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同。 - * cpu：硬件名为 cpu。 - * disk：磁盘名。 - * net：NIC 名。 - * memory：硬件名为 memory。 + * cpu：硬件名为 cpu。 + * disk：磁盘名。 + * net：NIC 名。 + * memory：硬件名为 memory。 * NAME：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 CPU 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 * VALUE：对应硬件负载的值，比如 CPU 的 1min/5min/15min 平均负载。 @@ -393,8 +393,8 @@ mysql> desc metrics_summary; * METRICS_NAME：监控表名 * QUANTILE：百分位，可以通过 SQL 语句指定 QUANTILE，例如 - * select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据 - * select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999) 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据 + * select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据 + * select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999) 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据 * SUM_VALUE / AVG_VALUE / MIN_VALUE / MAX_VALUE * COMMENT：对应监控的解释 @@ -622,11 +622,11 @@ mysql> desc inspection_result; 字段解释： * RULE：诊断规则，目前实现了 - * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 - * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 - * current-load：如果当前系统负载太高，会生成对应的 warning 诊断结果 - * critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果 - * threshold-check：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息 + * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 + * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 + * current-load：如果当前系统负载太高，会生成对应的 warning 诊断结果 + * critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果 + * threshold-check：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息 * ITEM：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 * TYPE：诊断的实例类型，可能是 tidb/tikv/pd * INSTANCE：诊断的具体实例 From 879ba0ad3302cfb21e311cf048317903e4ad3437 Mon Sep 17 00:00:00 2001 From: guoni Date: Thu, 19 Mar 2020 14:32:26 +0800 Subject: [PATCH 05/43] split the sql-dignosis doc --- reference/system-databases/cluster_config.md | 40 + .../system-databases/cluster_hardware.md | 48 ++ reference/system-databases/cluster_info.md | 41 ++ reference/system-databases/cluster_load.md | 51 ++ reference/system-databases/cluster_log.md | 31 + .../system-databases/cluster_systeminfo.md | 42 ++ .../system-databases/inspection_result.md | 58 ++ .../system-databases/inspection_summary.md | 64 ++ reference/system-databases/metrics-schema.md | 59 ++ reference/system-databases/metrics_summary.md | 220 ++++++ reference/system-databases/metrics_tables.md | 25 + reference/system-databases/sql-dignosis.md | 686 +----------------- 12 files changed, 690 insertions(+), 675 deletions(-) create mode 100644 reference/system-databases/cluster_config.md create mode 100644 reference/system-databases/cluster_hardware.md create mode 100644 reference/system-databases/cluster_info.md create mode 100644 reference/system-databases/cluster_load.md create mode 100644 reference/system-databases/cluster_log.md create mode 100644 reference/system-databases/cluster_systeminfo.md create mode 100644 reference/system-databases/inspection_result.md create mode 100644 reference/system-databases/inspection_summary.md create mode 100644 reference/system-databases/metrics-schema.md create mode 100644 reference/system-databases/metrics_summary.md create mode 100644 reference/system-databases/metrics_tables.md diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md new file mode 100644 index 000000000000..2e7face5487f --- /dev/null +++ b/reference/system-databases/cluster_config.md @@ -0,0 +1,40 @@ +# CLUSTER_CONFIG 表 + +集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 + +```sql +mysql> 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 | | ++----------+--------------+------+------+---------+-------+ +4 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 +* KEY：配置项名 +* VALUE：配置项值 + +具体示例，查询 TiKV 节点的 `coprocessor` 相关配置： + +```sql +mysql> 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 | ++------+-----------------+-----------------------------------+----------+ +6 rows in set (1.04 sec) +``` \ No newline at end of file diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md new file mode 100644 index 000000000000..074b240ba0f4 --- /dev/null +++ b/reference/system-databases/cluster_hardware.md @@ -0,0 +1,48 @@ +# CLUSTER_HARDWARE + +集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 + +```field +mysql> 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 | | ++-------------+--------------+------+------+---------+-------+ +6 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 +* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net +* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同 + * cpu：硬件名为 cpu + * memory：硬件名为 memory + * disk：磁盘名 + * net：NIC 名 +* NAME：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores`/`cpu-physical-cores`，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME +* VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 + +具体示例，查询集群的 CPU 信息： + +```sql +mysql> 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 | ++------+-----------------+-------------+-------------+--------------------+-------+ +6 rows in set (0.26 sec) +``` \ No newline at end of file diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md new file mode 100644 index 000000000000..5c90d12d9803 --- /dev/null +++ b/reference/system-databases/cluster_info.md @@ -0,0 +1,41 @@ +# CLUSTER_INFO 表 + +集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 + +```sql +mysql> 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) +``` + +字段解释： + +* TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 +* INSTANCE：实例地址，始终为 IP:PORT 格式的字符串 +* STATUS_ADDRESS：HTTP API 服务地址，部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API，会使用这个地址，用户也可以通过这个地址获取一些额外的集群信息，具体 HTTP API 参考官方文档 +* VERSION：对应节点的语义版本号，TiDB 版本为了兼容 MySQL 的版本号，以 ${mysql-version}-${tidb-version} 方式展示 +* GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 +* START_TIME：对应节点的启动时间 +* UPTIME：对应节点已经运行的时间 + +```sql +mysql> 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 | ++------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ +3 rows in set (0.01 sec) +``` \ No newline at end of file diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md new file mode 100644 index 000000000000..ae1bd97fbf4c --- /dev/null +++ b/reference/system-databases/cluster_load.md @@ -0,0 +1,51 @@ +# CLUSTER_LOAD + +集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 + +```field +mysql> desc cluster_load; ++-------------+--------------+------+------+---------+-------+ +| 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 | | ++-------------+--------------+------+------+---------+-------+ +6 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net。 +* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同。 + * cpu：硬件名为 cpu。 + * disk：磁盘名。 + * net：NIC 名。 + * memory：硬件名为 memory。 +* NAME：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 CPU 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 +* VALUE：对应硬件负载的值，比如 CPU 的 1min/5min/15min 平均负载。 + +具体示例，查询集群的 CPU 负载信息： + +```sql +mysql> select * from cluster_load where device_type='cpu' and device_name='cpu'; ++------+-----------------+-------------+-------------+--------+---------------+ +| 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 | ++------+-----------------+-------------+-------------+--------+---------------+ +9 rows in set (0.52 sec) +``` \ No newline at end of file diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md new file mode 100644 index 000000000000..ad76703b7f73 --- /dev/null +++ b/reference/system-databases/cluster_log.md @@ -0,0 +1,31 @@ +# CLUSTER_LOG + +集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 + +```field +mysql> desc cluster_log; ++----------+---------------------------+------+------+---------+-------+ +| 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 | | ++----------+---------------------------+------+------+---------+-------+ +5 rows in set (0.00 sec) +``` + +字段解释： + +* TIME：日志打印时间。 +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 INSTANCE 字段。 +* LEVEL：日志级别。 +* MESSAGE：日志内容。 + +> **注意事项：** +>日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，比如 select * from cluter_log where instance='tikv-1' 只会在 tikv-1 执行日志搜索。 +>message 字段支持 like 和 regexp 正则表达式，对应的 pattern 会编译为 regexp，同时指定多个 message 条件，相当于 grep 命令的 pipeline 形式，例如：select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' 相当于在集群所有节点执行 grep 'coprocessor' xxx.log | grep -E '.*slow.*'。 + +在TiDB 4.0 之前要获取集群的日志需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，可以更高效地提供一个全局时间有序的日志搜索结果，对于全链路事件跟踪提供便利的手段，比如按照某一个 region id 搜索日志，可以查询该 region 生命周期的所有日志，类似的通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 \ No newline at end of file diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster_systeminfo.md new file mode 100644 index 000000000000..ac873c408aa9 --- /dev/null +++ b/reference/system-databases/cluster_systeminfo.md @@ -0,0 +1,42 @@ +# CLUSTER_SYSTEMINFO + +集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 + +```field +mysql> desc cluster_systeminfo; ++-------------+--------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++-------------+--------------+------+------+---------+-------+ +| TYPE | varchar(64) | YES | | NULL | | +| INSTANCE | varchar(64) | YES | | NULL | | +| SYSTEM_TYPE | varchar(64) | YES | | NULL | | +| SYSTEM_NAME | varchar(64) | YES | | NULL | | +| NAME | varchar(256) | YES | | NULL | | +| VALUE | varchar(128) | YES | | NULL | | ++-------------+--------------+------+------+---------+-------+ +6 rows in set (0.00 sec) +``` + +字段解释： + +* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* SYSTEM_TYPE：系统类型，目前可以查询的系统类型有 system。 +* SYSTEM_NAME：目前可以查询的 SYSTEM_NAME 为 sysctl。 +* NAME：sysctl 对应的配置名。 +* VALUE：sysctl 对应配置项的值。 + +```sql +mysql> select * from cluster_systeminfo where name like '%fd%'; ++------+-----------------+-------------+-------------+-------------------------------+-------+ +| TYPE | INSTANCE | SYSTEM_TYPE | SYSTEM_NAME | NAME | VALUE | ++------+-----------------+-------------+-------------+-------------------------------+-------+ +| tidb | 127.0.0.1:10080 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | +| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.client_fd_count | 98 | +| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.observer_fd_count | 0 | +| pd | 127.0.0.1:2379 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | +| pd | 127.0.0.1:2379 | system | sysctl | net.necp.client_fd_count | 98 | +| pd | 127.0.0.1:2379 | system | sysctl | net.necp.observer_fd_count | 0 | ++------+-----------------+-------------+-------------+-------------------------------+-------+ +6 rows in set (0.04 sec) +``` \ No newline at end of file diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md new file mode 100644 index 000000000000..64fd5e34519e --- /dev/null +++ b/reference/system-databases/inspection_result.md @@ -0,0 +1,58 @@ +## INSPECTION_RESULT + +TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 + +该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 SQL select * from information_schema.inspection_result 来触发内部的诊断。 + +诊断结果表 `information_schema.inspection_result` 的表结构如下： + +```sql +mysql> desc inspection_result; ++-----------+--------------+------+------+---------+-------+ +| 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) +``` + +字段解释： + +* RULE：诊断规则，目前实现了 + * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 + * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 + * current-load：如果当前系统负载太高，会生成对应的 warning 诊断结果 + * critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果 + * threshold-check：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息 +* ITEM：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 +* TYPE：诊断的实例类型，可能是 tidb/tikv/pd +* INSTANCE：诊断的具体实例 +* VALUE：针对这个诊断项得到的值 +* REFERENCE：针对这个诊断项的参考值（阈值），如果 VALUE 和阈值差距比较大，就会产生对应的结果 +* SEVERITY：严重程度，warning/critical +* DETAILS：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接 + +诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比，如果结果超过阈值或低于阈值将生成 warning / critical 的结果，并在 details 列中提供进一步信息。 + +查询已有的诊断规则: + +```sql +mysql> select * from inspection_rules where type='inspection'; ++-----------------+------------+---------+ +| NAME | TYPE | COMMENT | ++-----------------+------------+---------+ +| config | inspection | | +| version | inspection | | +| current-load | inspection | | +| critical-error | inspection | | +| threshold-check | inspection | | ++-----------------+------------+---------+ +5 rows in set (0.00 sec) +``` \ No newline at end of file diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md new file mode 100644 index 000000000000..7203abe40dcd --- /dev/null +++ b/reference/system-databases/inspection_summary.md @@ -0,0 +1,64 @@ +# INSPECTION_SUMMARY + +在部分场景下我们只想要关注特定链路或模块的监控汇总， +比如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 + +诊断汇总表 `information_schema.inspection_summary` 的表结构如下： + +```sql +mysql> desc inspection_summary; ++--------------+-----------------------+------+------+---------+-------+ +| 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 | | ++--------------+-----------------------+------+------+---------+-------+ +8 rows in set (0.00 sec) +``` + +字段解释： + +* RULE：汇总规则，由于规则在持续添加，以下列表可能已经过时，最新的规则列表可以通过 select * from inspection_rules where type='summary' 查询 +* INSTANCE：监控的具体实例 +* METRIC_NAME：监控表 +* QUANTILE：对于包含 QUANTILE 的监控表有效，可以通过谓词下推指定多个百分位，比如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 ddl 相关监控，查询百分位为 80/90/99/999 的结果。 AVG_VALUE/MIN_VALUE/MAX_VALUE 分别表示聚合的平均、最小、最大值。 + +> **注意事项：** +> +>由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即通过 SQL 的谓词中显示指定的 rule 才会运行。比如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 + +使用示例: + +诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： + +```sql +诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: + +mysql> SELECT + t1.avg_value / t2.avg_value AS ratio, + t1.*, + t2.* + 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' + ) 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' + ) t2 + ON t1.metrics_name = t2.metrics_name + and t1.instance = t2.instance + and t1.label = t2.label + ORDER BY + ratio DESC; +``` diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md new file mode 100644 index 000000000000..96870538598b --- /dev/null +++ b/reference/system-databases/metrics-schema.md @@ -0,0 +1,59 @@ +# Metrics Schema + +为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， +并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 + +## tidb_query_duration 表 + +系统表数量较多，这里挑出比较典型的 `tidb_query_duration` 表来作为示例讲解： + +`tidb_query_duration` 的表结构如下，从表的 COMMENT 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 + +```sql +metrics_schema> show create table tidb_query_duration; ++---------------------+--------------------------------------------------------------------------------------------------------------------+ +| Table | Create Table | ++---------------------+--------------------------------------------------------------------------------------------------------------------+ +| tidb_query_duration | CREATE TABLE `tidb_query_duration` ( | +| | `time` datetime unsigned DEFAULT NULL, | +| | `instance` varchar(512) DEFAULT NULL, | +| | `sql_type` varchar(512) DEFAULT NULL, | +| | `quantile` double unsigned DEFAULT NULL, | +| | `value` double unsigned DEFAULT NULL | +| | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='The quantile of TiDB query durations(second)' | ++---------------------+--------------------------------------------------------------------------------------------------------------------+ +``` + +比如 tikv_admin_apply 有三个 label，对应的表也会有三个额外的列。 + +```sql +mysql> desc metrics_schema.tikv_admin_apply; ++----------+-------------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++----------+-------------------+------+------+---------+-------+ +| time | datetime unsigned | YES | | NULL | | +| instance | varchar(512) | YES | | NULL | | +| type | varchar(512) | YES | | NULL | | +| status | varchar(512) | YES | | NULL | | +| value | double unsigned | YES | | NULL | | ++----------+-------------------+------+------+---------+-------+ +5 rows in set (0.00 sec) +``` + +下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，internal 类型的 P90 耗时是 0.00327。instance 字段是 TiDB 示例的地址。 + +```sql +metrics_schema> select * from tidb_query_duration where value is not null and time=now() and quantile=0.90; ++---------------------+-------------------+----------+----------+------------------+ +| time | instance | sql_type | quantile | value | ++---------------------+-------------------+----------+----------+------------------+ +| 2020-03-08 13:34:40 | 172.16.5.40:10089 | Select | 0.9 | 0.0384 | +| 2020-03-08 13:34:40 | 172.16.5.40:10089 | internal | 0.9 | 0.00327692307692 | ++---------------------+-------------------+----------+----------+------------------+ +``` + +监控表 session 变量： + +* tidb_metric_query_step：查询的分辨率步长。从 Promethues 的 query_range 数据时需要指定 start，end，step，其中 step 会使用该变量的值 +* tidb_metric_query_range_duration：查询监控时，会将 PROMQL 中的 $RANGE_DURATION 替换成该变量的值，默认值是 60 秒 + diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md new file mode 100644 index 000000000000..dd6c0e207563 --- /dev/null +++ b/reference/system-databases/metrics_summary.md @@ -0,0 +1,220 @@ +## 监控汇总表 + +由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： + +* information_schema.metrics_summary +* information_schema.metrics_summary_by_label + +这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 +两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 + +```field +mysql> desc metrics_summary; ++--------------+-----------------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++--------------+-----------------------+------+------+---------+-------+ +| METRICS_NAME | varchar(64) | YES | | NULL | | +| QUANTILE | double unsigned | YES | | NULL | | +| SUM_VALUE | double(22,6) 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 | | +| COMMENT | varchar(256) | YES | | NULL | | ++--------------+-----------------------+------+------+---------+-------+ +7 rows in set (0.00 sec) +``` + +字段解释： + +* METRICS_NAME：监控表名 +* QUANTILE：百分位，可以通过 SQL 语句指定 QUANTILE，例如 + * select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据 + * select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999) 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据 +* SUM_VALUE / AVG_VALUE / MIN_VALUE / MAX_VALUE +* COMMENT：对应监控的解释 + +具体查询示例： +以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 information_schema.metrics_summary 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL： + +```sql +mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * + from information_schema.`METRICS_SUMMARY` + where metrics_name like 'tidb%duration' + and avg_value > 0 + and quantile = 0.99 + order by avg_value desc + limit 3\G +***************************[ 1. row ]*************************** +METRICS_NAME | tidb_get_token_duration +QUANTILE | 0.99 +SUM_VALUE | 8.972509 +AVG_VALUE | 0.996945 +MIN_VALUE | 0.996515 +MAX_VALUE | 0.997458 +COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second) +***************************[ 2. row ]*************************** +METRICS_NAME | tidb_query_duration +QUANTILE | 0.99 +SUM_VALUE | 0.269079 +AVG_VALUE | 0.007272 +MIN_VALUE | 0.000667 +MAX_VALUE | 0.01554 +COMMENT | The quantile of TiDB query durations(second) +***************************[ 3. row ]*************************** +METRICS_NAME | tidb_kv_request_duration +QUANTILE | 0.99 +SUM_VALUE | 0.170232 +AVG_VALUE | 0.004601 +MIN_VALUE | 0.000975 +MAX_VALUE | 0.013 +COMMENT | The quantile of kv requests durations by store +``` + +类似的，查询 metrics_summary_by_label 监控汇总表结果如下： + +```sql +mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * + from information_schema.`METRICS_SUMMARY_BY_LABEL` + where metrics_name like 'tidb%duration' + and avg_value > 0 + and quantile = 0.99 + order by avg_value desc + limit 10\G +***************************[ 1. row ]*************************** +INSTANCE | 172.16.5.40:10089 +METRICS_NAME | tidb_get_token_duration +LABEL | +QUANTILE | 0.99 +SUM_VALUE | 8.972509 +AVG_VALUE | 0.996945 +MIN_VALUE | 0.996515 +MAX_VALUE | 0.997458 +COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second) +***************************[ 2. row ]*************************** +INSTANCE | 172.16.5.40:10089 +METRICS_NAME | tidb_query_duration +LABEL | Select +QUANTILE | 0.99 +SUM_VALUE | 0.072083 +AVG_VALUE | 0.008009 +MIN_VALUE | 0.007905 +MAX_VALUE | 0.008241 +COMMENT | The quantile of TiDB query durations(second) +***************************[ 3. row ]*************************** +INSTANCE | 172.16.5.40:10089 +METRICS_NAME | tidb_query_duration +LABEL | Rollback +QUANTILE | 0.99 +SUM_VALUE | 0.072083 +AVG_VALUE | 0.008009 +MIN_VALUE | 0.007905 +MAX_VALUE | 0.008241 +COMMENT | The quantile of TiDB query durations(second) +``` + +前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 LABEL, 以上面查询结果的第 2, 3 行为例：分别表示 `tidb_query_duration` 的 Select/Rollback 类型的语句平均耗时非常高。 + +除以上示例之外，监控汇总表可以通过两个时间段的全链路监控对比，迅速找出监控数据变化最大的模块，快速定位瓶颈，以下对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： + +* 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00") +* 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") +对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 TIME_RANGE 是用于指定查询时间的 Hint。 + +查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项: + +```sql +mysql> SELECT + t1.avg_value / t2.avg_value AS ratio, + t1.metrics_name, + t1.avg_value, + t2.avg_value, + t2.comment + FROM + ( + SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ + * + FROM information_schema.metrics_summary + ) t1 + JOIN + ( + SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ + * + FROM information_schema.metrics_summary + ) t2 + ON t1.metrics_name = t2.metrics_name + ORDER BY + ratio DESC limit 10; ++----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ +| ratio | metrics_name | avg_value | avg_value | comment | ++----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ +| 17.6439787379 | tikv_region_average_written_bytes | 30816827.0953 | 1746591.71568 | The average rate of writing bytes to Regions per TiKV instance | +| 8.88407551364 | tikv_region_average_written_keys | 108557.034612 | 12219.283193 | The average rate of written keys to Regions per TiKV instance | +| 6.4105335594 | tidb_kv_write_num | 4493.293654 | 700.923505 | The quantile of kv write times per transaction execution | +| 2.99993333333 | tidb_gc_total_count | 1.0 | 0.333341 | The total count of kv storage garbage collection time durations | +| 2.66412165823 | tikv_engine_avg_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | +| 2.66412165823 | tikv_engine_max_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | +| 2.49994444321 | tikv_region_change | -0.277778 | -0.111114 | The count of region change per TiKV instance | +| 2.16063829787 | etcd_wal_fsync_duration | 0.002539 | 0.001175 | The quantile time consumed of writing WAL into the persistent storage | +| 2.06089264604 | node_memory_free | 4541448192.0 | 2203631616.0 | | +| 1.96749064186 | tidb_kv_write_size | 514489.28 | 261495.159902 | The quantile of kv write size per transaction execution | ++----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ +``` + +查询结果表示： + +* t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍 +* t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍 +* t1 时间段内的 tidb_kv_write_size （tidb 每个事务写入的 kv 大小） 比 t2 时间段高了 1.96 倍 + +通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 + +反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项: + +```sql +mysql> SELECT + t2.avg_value / t1.avg_value AS ratio, + t1.metrics_name, + t1.avg_value, + t2.avg_value, + t2.comment + FROM + ( + SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ + * + FROM information_schema.metrics_summary + ) t1 + JOIN + ( + SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ + * + FROM information_schema.metrics_summary + ) t2 + ON t1.metrics_name = t2.metrics_name + ORDER BY + ratio DESC limit 10; ++----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +| ratio | metrics_name | avg_value | avg_value | comment | ++----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +| 5865.59537065 | tidb_slow_query_cop_process_total_time | 0.016333 | 95.804724 | The total time of TiDB slow query statistics with slow query total cop process time(second) | +| 3648.74109023 | tidb_distsql_partial_scan_key_total_num | 10865.666667 | 39646004.4394 | The total num of distsql partial scan key numbers | +| 267.002351165 | tidb_slow_query_cop_wait_total_time | 0.003333 | 0.890008 | The total time of TiDB slow query statistics with slow query total cop wait time(second) | +| 192.43267836 | tikv_cop_total_response_total_size | 2515333.66667 | 484032394.445 | | +| 192.43267836 | tikv_cop_total_response_size | 41922.227778 | 8067206.57408 | | +| 152.780296296 | tidb_distsql_scan_key_total_num | 5304.333333 | 810397.618317 | The total num of distsql scan numbers | +| 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) | +| 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | | +| 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | | +| 101.635495394 | tikv_cop_total_kv_cursor_operations | 1070.875 | 108838.91113 | | ++----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +``` + +上面查询结果表示： + +* t2 时间段内的 tidb_slow_query_cop_process_total_time （tidb 慢查询中的 cop process 耗时 ） 比 t1 时间段高了 5865 倍 +* t2 时间段内的 tidb_distsql_partial_scan_key_total_num（tidb 的 distsql 请求扫描key 的数量） 比 t1 时间段高了 3648 倍 +* t2 时间段内的 tikv_cop_total_response_size（tikv 的 cop 请求结果的大小 ） 比 t1 时间段高了 192 倍 +* t2 时间段内的 tikv_cop_scan_details（tikv 的 cop 请求的 scan ） 比 t1 时间段高了 105 倍 + +通过上面两个时间段对比查询可以大致了解集群在这 2 个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 cop task 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 + +实际上，在 t1 ~ t2 整个时间段内都在跑 go-ycsb 的压测，然后在 t2 时间段跑了 20 个 tpch 的查询，所以是因为 tpch 大查询导致了很多的 cop 请求。 diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics_tables.md new file mode 100644 index 000000000000..7190ad0a7176 --- /dev/null +++ b/reference/system-databases/metrics_tables.md @@ -0,0 +1,25 @@ +# METRICS_TABLES 表 + +`METRICS_TABLES` 表提供了 `metrics_schema` 中所有监控表的相关信息。 + +```field +mysql> desc metrics_tables; ++------------+-----------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++------------+-----------------+------+------+---------+-------+ +| TABLE_NAME | varchar(64) | YES | | NULL | | +| PROMQL | varchar(64) | YES | | NULL | | +| LABELS | varchar(64) | YES | | NULL | | +| QUANTILE | double unsigned | YES | | NULL | | +| COMMENT | varchar(256) | YES | | NULL | | ++------------+-----------------+------+------+---------+-------+ +5 rows in set (0.00 sec) +``` + +表 `metrics_tables` 的字段解释： + +* TABLE_NAME：对应于 metrics_schema 中的表名。 +* PROMQL：监控表的主要原理是将 SQL 映射成 PromQL，并将 Promethues 结果转换成 SQL 查询结果。这个字段是 PromQL 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* LABELS：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 PromQL 也会改变。 +* QUANTILE：百分位，对于直方图类型的监控数据，指定一个默认百分位，如果值为 0，表示该监控表对应的监控不是直方图。 +* COMMENT：是对这个监控表的解释。 \ No newline at end of file diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 8fd9a25d0483..68993beee208 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -6,9 +6,9 @@ SQL 诊断功能是由 TiDB 4.0 引入的新特性，主要用于提升 TiDB 问 SQL 诊断共分三大块： * **集群信息表**：TiDB 4.0 诊断功能为原先离散的各节点实例信息提供了一致的获取方式，它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、Statements、日志完全打通，让使用者能够统一使用 SQL 查询。 -* **集群监控与汇总**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 +* **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 且由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，从而让用户能以一种更加便捷的方式从众多监控中找出异常的监控项。 -* **诊断结果表**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 +* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 ## 集群信息表 @@ -25,695 +25,31 @@ SQL 诊断共分三大块： TiDB 4.0 之前的以下系统表，只能查看当前节点，TiDB 4.0 实现了对应的集群表，可以在单个 TiDB 节点上拥有整个集群的全局视图。 这些表目前都位于 information_schema 中，查询形式上与其他 information_schema 系统表一致。 -## CLUSTER_INFO 表 - -集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 - -```sql -mysql> 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) -``` - -字段解释： - -* TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 -* INSTANCE：实例地址，始终为 IP:PORT 格式的字符串 -* STATUS_ADDRESS：HTTP API 服务地址，部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API，会使用这个地址，用户也可以通过这个地址获取一些额外的集群信息，具体 HTTP API 参考官方文档 -* VERSION：对应节点的语义版本号，TiDB 版本为了兼容 MySQL 的版本号，以 ${mysql-version}-${tidb-version} 方式展示 -* GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 -* START_TIME：对应节点的启动时间 -* UPTIME：对应节点已经运行的时间 - -```sql -mysql> 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 | -+------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ -3 rows in set (0.01 sec) -``` - -## CLUSTER_CONFIG 表 - -集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 - -```sql -mysql> 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 | | -+----------+--------------+------+------+---------+-------+ -4 rows in set (0.00 sec) -``` - -字段解释： - -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 -* KEY：配置项名 -* VALUE：配置项值 - -具体示例，查询 TiKV 节点的 `coprocessor` 相关配置： - -```sql -mysql> 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 | -+------+-----------------+-----------------------------------+----------+ -6 rows in set (1.04 sec) -``` - -## CLUSTER_HARDWARE - -集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 - -```field -mysql> 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 | | -+-------------+--------------+------+------+---------+-------+ -6 rows in set (0.00 sec) -``` - -字段解释： - -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 -* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net -* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同 - * cpu：硬件名为 cpu - * memory：硬件名为 memory - * disk：磁盘名 - * net：NIC 名 -* NAME：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores`/`cpu-physical-cores`，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME -* VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 - -具体示例，查询集群的 CPU 信息： - -```sql -mysql> 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 | -+------+-----------------+-------------+-------------+--------------------+-------+ -6 rows in set (0.26 sec) -``` - -## CLUSTER_LOAD - -集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 - -```field -mysql> desc cluster_load; -+-------------+--------------+------+------+---------+-------+ -| 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 | | -+-------------+--------------+------+------+---------+-------+ -6 rows in set (0.00 sec) -``` - -字段解释： - -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 -* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net。 -* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同。 - * cpu：硬件名为 cpu。 - * disk：磁盘名。 - * net：NIC 名。 - * memory：硬件名为 memory。 -* NAME：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 CPU 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 -* VALUE：对应硬件负载的值，比如 CPU 的 1min/5min/15min 平均负载。 - -具体示例，查询集群的 CPU 负载信息： - -```sql -mysql> select * from cluster_load where device_type='cpu' and device_name='cpu'; -+------+-----------------+-------------+-------------+--------+---------------+ -| 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 | -+------+-----------------+-------------+-------------+--------+---------------+ -9 rows in set (0.52 sec) -``` - -## CLUSTER_SYSTEMINFO - -集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 - -```field -mysql> desc cluster_systeminfo; -+-------------+--------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+-------------+--------------+------+------+---------+-------+ -| TYPE | varchar(64) | YES | | NULL | | -| INSTANCE | varchar(64) | YES | | NULL | | -| SYSTEM_TYPE | varchar(64) | YES | | NULL | | -| SYSTEM_NAME | varchar(64) | YES | | NULL | | -| NAME | varchar(256) | YES | | NULL | | -| VALUE | varchar(128) | YES | | NULL | | -+-------------+--------------+------+------+---------+-------+ -6 rows in set (0.00 sec) -``` - -字段解释： - -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 -* SYSTEM_TYPE：系统类型，目前可以查询的系统类型有 system。 -* SYSTEM_NAME：目前可以查询的 SYSTEM_NAME 为 sysctl。 -* NAME：sysctl 对应的配置名。 -* VALUE：sysctl 对应配置项的值。 - -```sql -mysql> select * from cluster_systeminfo where name like '%fd%'; -+------+-----------------+-------------+-------------+-------------------------------+-------+ -| TYPE | INSTANCE | SYSTEM_TYPE | SYSTEM_NAME | NAME | VALUE | -+------+-----------------+-------------+-------------+-------------------------------+-------+ -| tidb | 127.0.0.1:10080 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | -| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.client_fd_count | 98 | -| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.observer_fd_count | 0 | -| pd | 127.0.0.1:2379 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | -| pd | 127.0.0.1:2379 | system | sysctl | net.necp.client_fd_count | 98 | -| pd | 127.0.0.1:2379 | system | sysctl | net.necp.observer_fd_count | 0 | -+------+-----------------+-------------+-------------+-------------------------------+-------+ -6 rows in set (0.04 sec) -``` - -## CLUSTER_LOG - -集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 - -```field -mysql> desc cluster_log; -+----------+---------------------------+------+------+---------+-------+ -| 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 | | -+----------+---------------------------+------+------+---------+-------+ -5 rows in set (0.00 sec) -``` - -字段解释： - -* TIME：日志打印时间。 -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 INSTANCE 字段。 -* LEVEL：日志级别。 -* MESSAGE：日志内容。 - -> **注意事项：** ->日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，比如 select * from cluter_log where instance='tikv-1' 只会在 tikv-1 执行日志搜索。 ->message 字段支持 like 和 regexp 正则表达式，对应的 pattern 会编译为 regexp，同时指定多个 message 条件，相当于 grep 命令的 pipeline 形式，例如：select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' 相当于在集群所有节点执行 grep 'coprocessor' xxx.log | grep -E '.*slow.*'。 - -在TiDB 4.0 之前要获取集群的日志需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，可以更高效地提供一个全局时间有序的日志搜索结果，对于全链路事件跟踪提供便利的手段，比如按照某一个 region id 搜索日志，可以查询该 region 生命周期的所有日志，类似的通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 - ## 集群监控表 -集群信息表固然给力，但光有集群信息表还不够，为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， -并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，本文不对各个表进行逐个解释。用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 - -```field -mysql> desc metrics_tables; -+------------+-----------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+------------+-----------------+------+------+---------+-------+ -| TABLE_NAME | varchar(64) | YES | | NULL | | -| PROMQL | varchar(64) | YES | | NULL | | -| LABELS | varchar(64) | YES | | NULL | | -| QUANTILE | double unsigned | YES | | NULL | | -| COMMENT | varchar(256) | YES | | NULL | | -+------------+-----------------+------+------+---------+-------+ -5 rows in set (0.00 sec) -``` - -表 `metrics_tables` 的字段解释： - -* TABLE_NAME：对应于 metrics_schema 中的表名。 -* PROMQL：监控表的主要原理是将 SQL 映射成 PromQL，并将 Promethues 结果转换成 SQL 查询结果。这个字段是 PromQL 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 -* LABELS：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 PromQL 也会改变。 -* QUANTILE：百分位，对于直方图类型的监控数据，指定一个默认百分位，如果值为 0，表示该监控表对应的监控不是直方图。 -* COMMENT：是对这个监控表的解释。 +为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 -监控表示例: +* `information_schema.metrics_tables`：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 -`tidb_query_duration` 的表结构如下，从表的 COMMENT 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 +由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供了监控汇总表： -```sql -metrics_schema> show create table tidb_query_duration; -+---------------------+--------------------------------------------------------------------------------------------------------------------+ -| Table | Create Table | -+---------------------+--------------------------------------------------------------------------------------------------------------------+ -| tidb_query_duration | CREATE TABLE `tidb_query_duration` ( | -| | `time` datetime unsigned DEFAULT NULL, | -| | `instance` varchar(512) DEFAULT NULL, | -| | `sql_type` varchar(512) DEFAULT NULL, | -| | `quantile` double unsigned DEFAULT NULL, | -| | `value` double unsigned DEFAULT NULL | -| | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='The quantile of TiDB query durations(second)' | -+---------------------+--------------------------------------------------------------------------------------------------------------------+ -``` +* 监控汇总表 `information_schema.metrics_summary` 用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 +* 监控汇总表 `information_schema.metrics_summary_by_label` 同样用于汇总所有监控数据，不过它会对不同的 label 使用区分统计。 -比如 tikv_admin_apply 有三个 label，对应的表也会有三个额外的列 +## 自动诊断 -```sql -mysql> desc metrics_schema.tikv_admin_apply; -+----------+-------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+----------+-------------------+------+------+---------+-------+ -| time | datetime unsigned | YES | | NULL | | -| instance | varchar(512) | YES | | NULL | | -| type | varchar(512) | YES | | NULL | | -| status | varchar(512) | YES | | NULL | | -| value | double unsigned | YES | | NULL | | -+----------+-------------------+------+------+---------+-------+ -5 rows in set (0.00 sec) -``` - -下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，internal 类型的 P90 耗时是 0.00327。instance 字段是 TiDB 示例的地址。 - -```sql -metrics_schema> select * from tidb_query_duration where value is not null and time=now() and quantile=0.90; -+---------------------+-------------------+----------+----------+------------------+ -| time | instance | sql_type | quantile | value | -+---------------------+-------------------+----------+----------+------------------+ -| 2020-03-08 13:34:40 | 172.16.5.40:10089 | Select | 0.9 | 0.0384 | -| 2020-03-08 13:34:40 | 172.16.5.40:10089 | internal | 0.9 | 0.00327692307692 | -+---------------------+-------------------+----------+----------+------------------+ -``` - -监控表 session 变量： - -* tidb_metric_query_step：查询的分辨率步长。从 Promethues 的 query_range 数据时需要指定 start，end，step，其中 step 会使用该变量的值 -* tidb_metric_query_range_duration：查询监控时，会将 PROMQL 中的 $RANGE_DURATION 替换成该变量的值，默认值是 60 秒 - -## 监控汇总表 - -由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： - -* information_schema.metrics_summary -* information_schema.metrics_summary_by_label - -这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 -两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 - -```field -mysql> desc metrics_summary; -+--------------+-----------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+--------------+-----------------------+------+------+---------+-------+ -| METRICS_NAME | varchar(64) | YES | | NULL | | -| QUANTILE | double unsigned | YES | | NULL | | -| SUM_VALUE | double(22,6) 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 | | -| COMMENT | varchar(256) | YES | | NULL | | -+--------------+-----------------------+------+------+---------+-------+ -7 rows in set (0.00 sec) -``` - -字段解释： - -* METRICS_NAME：监控表名 -* QUANTILE：百分位，可以通过 SQL 语句指定 QUANTILE，例如 - * select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据 - * select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999) 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据 -* SUM_VALUE / AVG_VALUE / MIN_VALUE / MAX_VALUE -* COMMENT：对应监控的解释 - -具体查询示例： -以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 information_schema.metrics_summary 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL： - -```sql -mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * - from information_schema.`METRICS_SUMMARY` - where metrics_name like 'tidb%duration' - and avg_value > 0 - and quantile = 0.99 - order by avg_value desc - limit 3\G -***************************[ 1. row ]*************************** -METRICS_NAME | tidb_get_token_duration -QUANTILE | 0.99 -SUM_VALUE | 8.972509 -AVG_VALUE | 0.996945 -MIN_VALUE | 0.996515 -MAX_VALUE | 0.997458 -COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second) -***************************[ 2. row ]*************************** -METRICS_NAME | tidb_query_duration -QUANTILE | 0.99 -SUM_VALUE | 0.269079 -AVG_VALUE | 0.007272 -MIN_VALUE | 0.000667 -MAX_VALUE | 0.01554 -COMMENT | The quantile of TiDB query durations(second) -***************************[ 3. row ]*************************** -METRICS_NAME | tidb_kv_request_duration -QUANTILE | 0.99 -SUM_VALUE | 0.170232 -AVG_VALUE | 0.004601 -MIN_VALUE | 0.000975 -MAX_VALUE | 0.013 -COMMENT | The quantile of kv requests durations by store -``` - -类似的，查询 metrics_summary_by_label 监控汇总表结果如下： - -```sql -mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * - from information_schema.`METRICS_SUMMARY_BY_LABEL` - where metrics_name like 'tidb%duration' - and avg_value > 0 - and quantile = 0.99 - order by avg_value desc - limit 10\G -***************************[ 1. row ]*************************** -INSTANCE | 172.16.5.40:10089 -METRICS_NAME | tidb_get_token_duration -LABEL | -QUANTILE | 0.99 -SUM_VALUE | 8.972509 -AVG_VALUE | 0.996945 -MIN_VALUE | 0.996515 -MAX_VALUE | 0.997458 -COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second) -***************************[ 2. row ]*************************** -INSTANCE | 172.16.5.40:10089 -METRICS_NAME | tidb_query_duration -LABEL | Select -QUANTILE | 0.99 -SUM_VALUE | 0.072083 -AVG_VALUE | 0.008009 -MIN_VALUE | 0.007905 -MAX_VALUE | 0.008241 -COMMENT | The quantile of TiDB query durations(second) -***************************[ 3. row ]*************************** -INSTANCE | 172.16.5.40:10089 -METRICS_NAME | tidb_query_duration -LABEL | Rollback -QUANTILE | 0.99 -SUM_VALUE | 0.072083 -AVG_VALUE | 0.008009 -MIN_VALUE | 0.007905 -MAX_VALUE | 0.008241 -COMMENT | The quantile of TiDB query durations(second) -``` - -前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 LABEL, 以上面查询结果的第 2, 3 行为例：分别表示 `tidb_query_duration` 的 Select/Rollback 类型的语句平均耗时非常高。 - -除以上示例之外，监控汇总表可以通过两个时间段的全链路监控对比，迅速找出监控数据变化最大的模块，快速定位瓶颈，以下对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： - -* 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00") -* 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") -对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 TIME_RANGE 是用于指定查询时间的 Hint。 - -查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项: - -```sql -mysql> SELECT - t1.avg_value / t2.avg_value AS ratio, - t1.metrics_name, - t1.avg_value, - t2.avg_value, - t2.comment - FROM - ( - SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * - FROM information_schema.metrics_summary - ) t1 - JOIN - ( - SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * - FROM information_schema.metrics_summary - ) t2 - ON t1.metrics_name = t2.metrics_name - ORDER BY - ratio DESC limit 10; -+----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ -| ratio | metrics_name | avg_value | avg_value | comment | -+----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ -| 17.6439787379 | tikv_region_average_written_bytes | 30816827.0953 | 1746591.71568 | The average rate of writing bytes to Regions per TiKV instance | -| 8.88407551364 | tikv_region_average_written_keys | 108557.034612 | 12219.283193 | The average rate of written keys to Regions per TiKV instance | -| 6.4105335594 | tidb_kv_write_num | 4493.293654 | 700.923505 | The quantile of kv write times per transaction execution | -| 2.99993333333 | tidb_gc_total_count | 1.0 | 0.333341 | The total count of kv storage garbage collection time durations | -| 2.66412165823 | tikv_engine_avg_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | -| 2.66412165823 | tikv_engine_max_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | -| 2.49994444321 | tikv_region_change | -0.277778 | -0.111114 | The count of region change per TiKV instance | -| 2.16063829787 | etcd_wal_fsync_duration | 0.002539 | 0.001175 | The quantile time consumed of writing WAL into the persistent storage | -| 2.06089264604 | node_memory_free | 4541448192.0 | 2203631616.0 | | -| 1.96749064186 | tidb_kv_write_size | 514489.28 | 261495.159902 | The quantile of kv write size per transaction execution | -+----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ -``` - -查询结果表示： - -* t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍 -* t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍 -* t1 时间段内的 tidb_kv_write_size （tidb 每个事务写入的 kv 大小） 比 t2 时间段高了 1.96 倍 - -通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 - -反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项: - -```sql -mysql> SELECT - t2.avg_value / t1.avg_value AS ratio, - t1.metrics_name, - t1.avg_value, - t2.avg_value, - t2.comment - FROM - ( - SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * - FROM information_schema.metrics_summary - ) t1 - JOIN - ( - SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * - FROM information_schema.metrics_summary - ) t2 - ON t1.metrics_name = t2.metrics_name - ORDER BY - ratio DESC limit 10; -+----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ -| ratio | metrics_name | avg_value | avg_value | comment | -+----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ -| 5865.59537065 | tidb_slow_query_cop_process_total_time | 0.016333 | 95.804724 | The total time of TiDB slow query statistics with slow query total cop process time(second) | -| 3648.74109023 | tidb_distsql_partial_scan_key_total_num | 10865.666667 | 39646004.4394 | The total num of distsql partial scan key numbers | -| 267.002351165 | tidb_slow_query_cop_wait_total_time | 0.003333 | 0.890008 | The total time of TiDB slow query statistics with slow query total cop wait time(second) | -| 192.43267836 | tikv_cop_total_response_total_size | 2515333.66667 | 484032394.445 | | -| 192.43267836 | tikv_cop_total_response_size | 41922.227778 | 8067206.57408 | | -| 152.780296296 | tidb_distsql_scan_key_total_num | 5304.333333 | 810397.618317 | The total num of distsql scan numbers | -| 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) | -| 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | | -| 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | | -| 101.635495394 | tikv_cop_total_kv_cursor_operations | 1070.875 | 108838.91113 | | -+----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ -``` - -上面查询结果表示： - -* t2 时间段内的 tidb_slow_query_cop_process_total_time （tidb 慢查询中的 cop process 耗时 ） 比 t1 时间段高了 5865 倍 -* t2 时间段内的 tidb_distsql_partial_scan_key_total_num（tidb 的 distsql 请求扫描key 的数量） 比 t1 时间段高了 3648 倍 -* t2 时间段内的 tikv_cop_total_response_size（tikv 的 cop 请求结果的大小 ） 比 t1 时间段高了 192 倍 -* t2 时间段内的 tikv_cop_scan_details（tikv 的 cop 请求的 scan ） 比 t1 时间段高了 105 倍 - -通过上面两个时间段对比查询可以大致了解集群在这 2 个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 cop task 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 - -实际上，在 t1 ~ t2 整个时间段内都在跑 go-ycsb 的压测，然后在 t2 时间段跑了 20 个 tpch 的查询，所以是因为 tpch 大查询导致了很多的 cop 请求。 - -## 诊断结果表 - -前面介绍了集群信息表和集群监控表，并通过 SQL 演示了如何通过查询这些表来发现集群问题，比如通过 information_schema.cluster_config 发现集群不同节点配置不一致，通过 information_schema.metrics_summary 发现指定时间范围内 TiDB 集群中平均耗时最高的监控项。 +前面介绍了集群信息表和集群监控表，并通过 SQL 演示了如何通过查询这些表来发现集群问题，比如通过 information_schema.cluster_config 发现集群不同节点配置不一致，通过 `information_schema.metrics_summary` 发现指定时间范围内 TiDB 集群中平均耗时最高的监控项。 不过手动执行固定模式的 SQL 排查集群问题是低效的，为了进一步优化用户体验，方便用户使用，于是我们利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断： -* information_schema.inspection_result -* information_schema.inspection_summary - -该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 SQL select * from information_schema.inspection_result 来触发内部的诊断。 - -## INSPECTION_RESULT - -TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 - -诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL select * from inspection_result 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 - -诊断结果表 `information_schema.inspection_result` 的表结构如下： - -```sql -mysql> desc inspection_result; -+-----------+--------------+------+------+---------+-------+ -| 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) -``` - -字段解释： - -* RULE：诊断规则，目前实现了 - * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 - * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 - * current-load：如果当前系统负载太高，会生成对应的 warning 诊断结果 - * critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果 - * threshold-check：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息 -* ITEM：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 -* TYPE：诊断的实例类型，可能是 tidb/tikv/pd -* INSTANCE：诊断的具体实例 -* VALUE：针对这个诊断项得到的值 -* REFERENCE：针对这个诊断项的参考值（阈值），如果 VALUE 和阈值差距比较大，就会产生对应的结果 -* SEVERITY：严重程度，warning/critical -* DETAILS：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接 - -诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比，如果结果超过阈值或低于阈值将生成 warning / critical 的结果，并在 details 列中提供进一步信息。 - -查询已有的诊断规则: - -```sql -mysql> select * from inspection_rules where type='inspection'; -+-----------------+------------+---------+ -| NAME | TYPE | COMMENT | -+-----------------+------------+---------+ -| config | inspection | | -| version | inspection | | -| current-load | inspection | | -| critical-error | inspection | | -| threshold-check | inspection | | -+-----------------+------------+---------+ -5 rows in set (0.00 sec) -``` - -## INSPECTION_SUMMARY +* 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL `select * from inspection_result` 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 +* 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 -以上的监控汇总表是按照集群所有的监控进行汇总，但是在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8， -如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 -诊断汇总表 `information_schema.inspection_summary` 的表结构如下： -```sql -mysql> desc inspection_summary; -+--------------+-----------------------+------+------+---------+-------+ -| 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 | | -+--------------+-----------------------+------+------+---------+-------+ -8 rows in set (0.00 sec) -``` -字段解释： -* RULE：汇总规则，由于规则在持续添加，以下列表可能已经过时，最新的规则列表可以通过 select * from inspection_rules where type='summary' 查询 -* INSTANCE：监控的具体实例 -* METRIC_NAME：监控表 -* QUANTILE：对于包含 QUANTILE 的监控表有效，可以通过谓词下推指定多个百分位，比如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 ddl 相关监控，查询百分位为 80/90/99/999 的结果。 AVG_VALUE/MIN_VALUE/MAX_VALUE 分别表示聚合的平均、最小、最大值。 -> **注意事项：** -> ->由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即通过 SQL 的谓词中显示指定的 rule 才会运行。比如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 -使用示例: -诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： -```sql -诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: -mysql> SELECT - t1.avg_value / t2.avg_value AS ratio, - t1.*, - t2.* - 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' - ) 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' - ) t2 - ON t1.metrics_name = t2.metrics_name - and t1.instance = t2.instance - and t1.label = t2.label - ORDER BY - ratio DESC; -``` From 2934e47594b66b3de853bce8a68f103a784a7ef4 Mon Sep 17 00:00:00 2001 From: guoni Date: Thu, 19 Mar 2020 14:33:55 +0800 Subject: [PATCH 06/43] refine doc --- reference/system-databases/inspection_result.md | 2 +- reference/system-databases/inspection_summary.md | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index 64fd5e34519e..6161c266e0e6 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -2,7 +2,7 @@ TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 -该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 SQL select * from information_schema.inspection_result 来触发内部的诊断。 +该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 SQL `select * from information_schema.inspection_result` 来触发内部的诊断。 诊断结果表 `information_schema.inspection_result` 的表结构如下： diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 7203abe40dcd..25582b1d11fa 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -1,7 +1,6 @@ # INSPECTION_SUMMARY -在部分场景下我们只想要关注特定链路或模块的监控汇总， -比如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 +在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 诊断汇总表 `information_schema.inspection_summary` 的表结构如下： From a3b172cf80011e5f744f5e2e1b90640098d9afb5 Mon Sep 17 00:00:00 2001 From: guoni Date: Thu, 19 Mar 2020 14:39:34 +0800 Subject: [PATCH 07/43] fix lint --- reference/system-databases/inspection_result.md | 2 +- reference/system-databases/metrics-schema.md | 3 +-- reference/system-databases/metrics_summary.md | 2 +- reference/system-databases/sql-dignosis.md | 12 +----------- 4 files changed, 4 insertions(+), 15 deletions(-) diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index 6161c266e0e6..aecb93c0937b 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -1,4 +1,4 @@ -## INSPECTION_RESULT +# INSPECTION_RESULT TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index 96870538598b..9045b879a1d4 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -55,5 +55,4 @@ metrics_schema> select * from tidb_query_duration where value is not null and ti 监控表 session 变量： * tidb_metric_query_step：查询的分辨率步长。从 Promethues 的 query_range 数据时需要指定 start，end，step，其中 step 会使用该变量的值 -* tidb_metric_query_range_duration：查询监控时，会将 PROMQL 中的 $RANGE_DURATION 替换成该变量的值，默认值是 60 秒 - +* tidb_metric_query_range_duration：查询监控时，会将 PROMQL 中的 $RANGE_DURATION 替换成该变量的值，默认值是 60 秒 \ No newline at end of file diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index dd6c0e207563..fd3c860492ed 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -1,4 +1,4 @@ -## 监控汇总表 +# METRICS_SUMMARY 由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 68993beee208..d3db72e6fb68 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -42,14 +42,4 @@ TiDB 4.0 之前的以下系统表，只能查看当前节点，TiDB 4.0 实现 不过手动执行固定模式的 SQL 排查集群问题是低效的，为了进一步优化用户体验，方便用户使用，于是我们利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断： * 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL `select * from inspection_result` 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 -* 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 - - - - - - - - - - +* 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 \ No newline at end of file From 2545f7a6305401f7458aad7baacf836dfcf0d4b1 Mon Sep 17 00:00:00 2001 From: guoni Date: Fri, 20 Mar 2020 15:14:52 +0800 Subject: [PATCH 08/43] add meta info --- reference/system-databases/cluster_config.md | 7 ++++++- reference/system-databases/cluster_hardware.md | 5 +++++ reference/system-databases/cluster_info.md | 7 ++++++- reference/system-databases/cluster_load.md | 5 +++++ reference/system-databases/cluster_log.md | 5 +++++ reference/system-databases/cluster_systeminfo.md | 5 +++++ reference/system-databases/inspection_result.md | 5 +++++ reference/system-databases/inspection_summary.md | 5 +++++ reference/system-databases/metrics-schema.md | 5 +++++ reference/system-databases/metrics_summary.md | 5 +++++ reference/system-databases/metrics_tables.md | 7 ++++++- reference/system-databases/sql-dignosis.md | 5 +++++ 12 files changed, 63 insertions(+), 3 deletions(-) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md index 2e7face5487f..aefe47a15722 100644 --- a/reference/system-databases/cluster_config.md +++ b/reference/system-databases/cluster_config.md @@ -1,4 +1,9 @@ -# CLUSTER_CONFIG 表 +--- +title: CLUSTER_CONFIG +category: reference +--- + +# CLUSTER_CONFIG 集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 074b240ba0f4..4858790f7686 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -1,3 +1,8 @@ +--- +title: CLUSTER_HARDWARE +category: reference +--- + # CLUSTER_HARDWARE 集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index 5c90d12d9803..30499cec082e 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -1,4 +1,9 @@ -# CLUSTER_INFO 表 +--- +title: CLUSTER_INFO +category: reference +--- + +# CLUSTER_INFO 集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md index ae1bd97fbf4c..447c4d4b11ec 100644 --- a/reference/system-databases/cluster_load.md +++ b/reference/system-databases/cluster_load.md @@ -1,3 +1,8 @@ +--- +title: CLUSTER_LOAD +category: reference +--- + # CLUSTER_LOAD 集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index ad76703b7f73..74bebc7bb6e9 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -1,3 +1,8 @@ +--- +title: CLUSTER_LOG +category: reference +--- + # CLUSTER_LOG 集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster_systeminfo.md index ac873c408aa9..d97a03114ad5 100644 --- a/reference/system-databases/cluster_systeminfo.md +++ b/reference/system-databases/cluster_systeminfo.md @@ -1,3 +1,8 @@ +--- +title: CLUSTER_SYSTEMINFO +category: reference +--- + # CLUSTER_SYSTEMINFO 集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index aecb93c0937b..96e8e106e7ef 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -1,3 +1,8 @@ +--- +title: INSPECTION_RESULT +category: reference +--- + # INSPECTION_RESULT TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 25582b1d11fa..6972d563c15a 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -1,3 +1,8 @@ +--- +title: INSPECTION_SUMMARY +category: reference +--- + # INSPECTION_SUMMARY 在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index 9045b879a1d4..5914c7e437ea 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -1,3 +1,8 @@ +--- +title: Metrics Schema +category: reference +--- + # Metrics Schema 为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index fd3c860492ed..996a1871d169 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -1,3 +1,8 @@ +--- +title: METRICS_SUMMARY +category: reference +--- + # METRICS_SUMMARY 由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics_tables.md index 7190ad0a7176..c1266bacb394 100644 --- a/reference/system-databases/metrics_tables.md +++ b/reference/system-databases/metrics_tables.md @@ -1,4 +1,9 @@ -# METRICS_TABLES 表 +--- +title: METRICS_TABLES +category: reference +--- + +# METRICS_TABLES `METRICS_TABLES` 表提供了 `metrics_schema` 中所有监控表的相关信息。 diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index d3db72e6fb68..d357ed2f751a 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -1,3 +1,8 @@ +--- +title: SQL DIAGNOSIS +category: reference +--- + # SQL DIAGNOSIS SQL 诊断功能是由 TiDB 4.0 引入的新特性，主要用于提升 TiDB 问题定位效率，相较于 4.0 版本之前，不同的信息需要使用不同工具获取的异构方式， From fab9543447f625beec29e70a16ecc9188e148ea6 Mon Sep 17 00:00:00 2001 From: guoni Date: Fri, 20 Mar 2020 15:35:02 +0800 Subject: [PATCH 09/43] =?UTF-8?q?add=20=C3=A6=C2=8Bsql=20copy?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- reference/system-databases/cluster_config.md | 14 +- .../system-databases/cluster_hardware.md | 16 +- reference/system-databases/cluster_info.md | 14 +- reference/system-databases/cluster_load.md | 16 +- reference/system-databases/cluster_log.md | 9 +- .../system-databases/cluster_systeminfo.md | 14 +- .../system-databases/inspection_result.md | 10 ++ .../system-databases/inspection_summary.md | 9 +- reference/system-databases/metrics-schema.md | 19 ++- reference/system-databases/metrics_summary.md | 139 +++++++++++------- reference/system-databases/metrics_tables.md | 9 +- 11 files changed, 192 insertions(+), 77 deletions(-) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md index aefe47a15722..22198b278ace 100644 --- a/reference/system-databases/cluster_config.md +++ b/reference/system-databases/cluster_config.md @@ -7,8 +7,13 @@ category: reference 集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 +{{< copyable "sql" >}} + ```sql -mysql> desc cluster_config; +desc cluster_config; +``` + +``` +----------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+------+---------+-------+ @@ -29,8 +34,13 @@ mysql> desc cluster_config; 具体示例，查询 TiKV 节点的 `coprocessor` 相关配置： +{{< copyable "sql" >}} + ```sql -mysql> select * from cluster_config where type='tikv' and `key` like 'coprocessor%'; +select * from cluster_config where type='tikv' and `key` like 'coprocessor%'; +``` + +``` +------+-----------------+-----------------------------------+----------+ | TYPE | INSTANCE | KEY | VALUE | +------+-----------------+-----------------------------------+----------+ diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 4858790f7686..8d2fd7a56ef6 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -7,8 +7,13 @@ category: reference 集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 -```field -mysql> desc cluster_hardware; +{{< copyable "sql" >}} + +```sql +desc cluster_hardware; +``` + +``` +-------------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+--------------+------+------+---------+-------+ @@ -37,8 +42,13 @@ mysql> desc cluster_hardware; 具体示例，查询集群的 CPU 信息： +{{< copyable "sql" >}} + ```sql -mysql> select * from cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores'; +select * from cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores'; +``` + +``` +------+-----------------+-------------+-------------+--------------------+-------+ | TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE | +------+-----------------+-------------+-------------+--------------------+-------+ diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index 30499cec082e..791e43e1b9bd 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -7,8 +7,13 @@ category: reference 集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 +{{< copyable "sql" >}} + ```sql -mysql> desc cluster_info; +desc cluster_info; +``` + +``` +----------------+-------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------------+-------------+------+------+---------+-------+ @@ -33,8 +38,13 @@ mysql> desc cluster_info; * START_TIME：对应节点的启动时间 * UPTIME：对应节点已经运行的时间 +{{< copyable "sql" >}} + ```sql -mysql> select * from cluster_info; +select * from cluster_info; +``` + +``` +------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ | TYPE | INSTANCE | STATUS_ADDRESS | VERSION | GIT_HASH | START_TIME | UPTIME | +------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md index 447c4d4b11ec..79d06a83d1f9 100644 --- a/reference/system-databases/cluster_load.md +++ b/reference/system-databases/cluster_load.md @@ -7,8 +7,13 @@ category: reference 集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 -```field -mysql> desc cluster_load; +{{< copyable "sql" >}} + +```sql +desc cluster_load; +``` + +``` +-------------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+--------------+------+------+---------+-------+ @@ -37,8 +42,13 @@ mysql> desc cluster_load; 具体示例，查询集群的 CPU 负载信息： +{{< copyable "sql" >}} + ```sql -mysql> select * from cluster_load where device_type='cpu' and device_name='cpu'; +select * from cluster_load where device_type='cpu' and device_name='cpu'; +``` + +``` +------+-----------------+-------------+-------------+--------+---------------+ | TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE | +------+-----------------+-------------+-------------+--------+---------------+ diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index 74bebc7bb6e9..e0eb584a5f0b 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -7,8 +7,13 @@ category: reference 集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 -```field -mysql> desc cluster_log; +{{< copyable "sql" >}} + +```sql +desc cluster_log; +``` + +``` +----------+---------------------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+---------------------------+------+------+---------+-------+ diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster_systeminfo.md index d97a03114ad5..a844358055eb 100644 --- a/reference/system-databases/cluster_systeminfo.md +++ b/reference/system-databases/cluster_systeminfo.md @@ -7,8 +7,13 @@ category: reference 集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 -```field -mysql> desc cluster_systeminfo; +{{< copyable "sql" >}} + +```sql +desc cluster_systeminfo; +``` + +``` +-------------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------------+--------------+------+------+---------+-------+ @@ -32,7 +37,10 @@ mysql> desc cluster_systeminfo; * VALUE：sysctl 对应配置项的值。 ```sql -mysql> select * from cluster_systeminfo where name like '%fd%'; +select * from cluster_systeminfo where name like '%fd%'; +``` + +``` +------+-----------------+-------------+-------------+-------------------------------+-------+ | TYPE | INSTANCE | SYSTEM_TYPE | SYSTEM_NAME | NAME | VALUE | +------+-----------------+-------------+-------------+-------------------------------+-------+ diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index 96e8e106e7ef..142555e43b49 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -11,8 +11,13 @@ TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 诊断结果表 `information_schema.inspection_result` 的表结构如下： +{{< copyable "sql" >}} + ```sql mysql> desc inspection_result; +``` + +``` +-----------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+--------------+------+------+---------+-------+ @@ -48,8 +53,13 @@ mysql> desc inspection_result; 查询已有的诊断规则: +{{< copyable "sql" >}} + ```sql mysql> select * from inspection_rules where type='inspection'; +``` + +``` +-----------------+------------+---------+ | NAME | TYPE | COMMENT | +-----------------+------------+---------+ diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 6972d563c15a..533b91d16faa 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -9,8 +9,13 @@ category: reference 诊断汇总表 `information_schema.inspection_summary` 的表结构如下： +{{< copyable "sql" >}} + ```sql mysql> desc inspection_summary; +``` + +``` +--------------+-----------------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+-----------------------+------+------+---------+-------+ @@ -41,9 +46,11 @@ mysql> desc inspection_summary; 诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： -```sql 诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: +{{< copyable "sql" >}} + +```sql mysql> SELECT t1.avg_value / t2.avg_value AS ratio, t1.*, diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index 5914c7e437ea..054708c4a443 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -14,8 +14,13 @@ category: reference `tidb_query_duration` 的表结构如下，从表的 COMMENT 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 +{{< copyable "sql" >}} + ```sql -metrics_schema> show create table tidb_query_duration; +show create table tidb_query_duration; +``` + +``` +---------------------+--------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +---------------------+--------------------------------------------------------------------------------------------------------------------+ @@ -31,8 +36,13 @@ metrics_schema> show create table tidb_query_duration; 比如 tikv_admin_apply 有三个 label，对应的表也会有三个额外的列。 +{{< copyable "sql" >}} + ```sql -mysql> desc metrics_schema.tikv_admin_apply; +desc metrics_schema.tikv_admin_apply; +``` + +``` +----------+-------------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+-------------------+------+------+---------+-------+ @@ -47,8 +57,13 @@ mysql> desc metrics_schema.tikv_admin_apply; 下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，internal 类型的 P90 耗时是 0.00327。instance 字段是 TiDB 示例的地址。 +{{< copyable "sql" >}} + ```sql metrics_schema> select * from tidb_query_duration where value is not null and time=now() and quantile=0.90; +``` + +``` +---------------------+-------------------+----------+----------+------------------+ | time | instance | sql_type | quantile | value | +---------------------+-------------------+----------+----------+------------------+ diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index 996a1871d169..c46bbc6b4506 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -13,8 +13,13 @@ category: reference 这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 -```field +{{< copyable "sql" >}} + +```sql mysql> desc metrics_summary; +``` + +``` +--------------+-----------------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+-----------------------+------+------+---------+-------+ @@ -41,14 +46,19 @@ mysql> desc metrics_summary; 具体查询示例： 以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 information_schema.metrics_summary 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL： +{{< copyable "sql" >}} + ```sql -mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * - from information_schema.`METRICS_SUMMARY` - where metrics_name like 'tidb%duration' - and avg_value > 0 - and quantile = 0.99 - order by avg_value desc - limit 3\G +select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * +from information_schema.`METRICS_SUMMARY` +where metrics_name like 'tidb%duration' + and avg_value > 0 + and quantile = 0.99 +order by avg_value desc +limit 3\G +``` + +``` ***************************[ 1. row ]*************************** METRICS_NAME | tidb_get_token_duration QUANTILE | 0.99 @@ -77,14 +87,19 @@ COMMENT | The quantile of kv requests durations by store 类似的，查询 metrics_summary_by_label 监控汇总表结果如下： +{{< copyable "sql" >}} + ```sql -mysql> select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * - from information_schema.`METRICS_SUMMARY_BY_LABEL` - where metrics_name like 'tidb%duration' - and avg_value > 0 - and quantile = 0.99 - order by avg_value desc - limit 10\G +select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * +from information_schema.`METRICS_SUMMARY_BY_LABEL` +where metrics_name like 'tidb%duration' + and avg_value > 0 + and quantile = 0.99 +order by avg_value desc +limit 10\G +``` + +``` ***************************[ 1. row ]*************************** INSTANCE | 172.16.5.40:10089 METRICS_NAME | tidb_get_token_duration @@ -127,28 +142,33 @@ COMMENT | The quantile of TiDB query durations(second) 查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项: +{{< copyable "sql" >}} + ```sql -mysql> SELECT - t1.avg_value / t2.avg_value AS ratio, - t1.metrics_name, - t1.avg_value, - t2.avg_value, - t2.comment - FROM - ( - SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * - FROM information_schema.metrics_summary - ) t1 - JOIN - ( - SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * - FROM information_schema.metrics_summary - ) t2 - ON t1.metrics_name = t2.metrics_name - ORDER BY - ratio DESC limit 10; +SELECT + t1.avg_value / t2.avg_value AS ratio, + t1.metrics_name, + t1.avg_value, + t2.avg_value, + t2.comment +FROM + ( + SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ + * + FROM information_schema.metrics_summary + ) t1 + JOIN + ( + SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ + * + FROM information_schema.metrics_summary + ) t2 + ON t1.metrics_name = t2.metrics_name +ORDER BY + ratio DESC limit 10; +``` + +``` +----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ | ratio | metrics_name | avg_value | avg_value | comment | +----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ @@ -175,28 +195,33 @@ mysql> SELECT 反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项: +{{< copyable "sql" >}} + ```sql -mysql> SELECT - t2.avg_value / t1.avg_value AS ratio, - t1.metrics_name, - t1.avg_value, - t2.avg_value, - t2.comment - FROM - ( - SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * - FROM information_schema.metrics_summary - ) t1 - JOIN - ( - SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * - FROM information_schema.metrics_summary - ) t2 - ON t1.metrics_name = t2.metrics_name - ORDER BY - ratio DESC limit 10; +SELECT + t2.avg_value / t1.avg_value AS ratio, + t1.metrics_name, + t1.avg_value, + t2.avg_value, + t2.comment +FROM + ( + SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ + * + FROM information_schema.metrics_summary + ) t1 + JOIN + ( + SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ + * + FROM information_schema.metrics_summary + ) t2 + ON t1.metrics_name = t2.metrics_name +ORDER BY + ratio DESC limit 10; +``` + +``` +----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ | ratio | metrics_name | avg_value | avg_value | comment | +----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics_tables.md index c1266bacb394..8dd275593e45 100644 --- a/reference/system-databases/metrics_tables.md +++ b/reference/system-databases/metrics_tables.md @@ -7,8 +7,13 @@ category: reference `METRICS_TABLES` 表提供了 `metrics_schema` 中所有监控表的相关信息。 -```field -mysql> desc metrics_tables; +{{< copyable "sql" >}} + +```sql +desc metrics_tables; +``` + +``` +------------+-----------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+-----------------+------+------+---------+-------+ From edc30e53948d4cdcc2bc33a6142c06c3dda0306d Mon Sep 17 00:00:00 2001 From: guoni Date: Fri, 20 Mar 2020 16:44:36 +0800 Subject: [PATCH 10/43] refine doc --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index d357ed2f751a..c1f67df5be12 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -17,7 +17,7 @@ SQL 诊断共分三大块： ## 集群信息表 -集群信息表包括集群拓扑、集群配置、集群硬件、内核参数、系统负载、日志、集群监控等，这些集群表将一个集群中的所有节点实例的信息都汇聚到了一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 +集群信息表将一个集群中的所有节点实例的信息都汇聚到了一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 新增的集群信息表如下： * 集群拓扑表 `information_schema.cluster_info` 主要是用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 From 91e2f47ff0dc80287d4ea4f68fbd37d8df494dc0 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:45:44 +0800 Subject: [PATCH 11/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index c1f67df5be12..e8bee432eb81 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -5,7 +5,7 @@ category: reference # SQL DIAGNOSIS -SQL 诊断功能是由 TiDB 4.0 引入的新特性，主要用于提升 TiDB 问题定位效率，相较于 4.0 版本之前，不同的信息需要使用不同工具获取的异构方式， +SQL 诊断功能是在 TiDB 4.0 版本中引入的特性，用于提升 TiDB 问题定位的效率。TiDB 4.0 版本以前，用户需要使用不同工具获取以异构的方式获取不同信息。 新的 SQL 诊断对这些离散的信息进行了整体设计，它通过将系统的各种维度信息通过系统表的方式向上层提供了一致的接口方式以及监控汇总与自动诊断，方便了用户对于集群信息的查询。 SQL 诊断共分三大块： @@ -47,4 +47,4 @@ TiDB 4.0 之前的以下系统表，只能查看当前节点，TiDB 4.0 实现 不过手动执行固定模式的 SQL 排查集群问题是低效的，为了进一步优化用户体验，方便用户使用，于是我们利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断： * 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL `select * from inspection_result` 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 -* 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 \ No newline at end of file +* 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 From 236de52a754e969a7711c25daa29936a8ffd168e Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:45:57 +0800 Subject: [PATCH 12/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index e8bee432eb81..767229d0cd3f 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -6,7 +6,7 @@ category: reference # SQL DIAGNOSIS SQL 诊断功能是在 TiDB 4.0 版本中引入的特性，用于提升 TiDB 问题定位的效率。TiDB 4.0 版本以前，用户需要使用不同工具获取以异构的方式获取不同信息。 -新的 SQL 诊断对这些离散的信息进行了整体设计，它通过将系统的各种维度信息通过系统表的方式向上层提供了一致的接口方式以及监控汇总与自动诊断，方便了用户对于集群信息的查询。 +新的 SQL 诊断系统对这些离散的信息进行了整体设计，它整合系统各个维度的信息，通过系统表的方式向上层提供一致的接口，提供监控汇总与自动诊断，方便用户查询集群信息。 SQL 诊断共分三大块： From 7cbbe98262886931cc0fd7924b262822ff0c4d12 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:46:47 +0800 Subject: [PATCH 13/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 767229d0cd3f..dc85182de709 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -10,7 +10,7 @@ SQL 诊断功能是在 TiDB 4.0 版本中引入的特性，用于提升 TiDB 问 SQL 诊断共分三大块： -* **集群信息表**：TiDB 4.0 诊断功能为原先离散的各节点实例信息提供了一致的获取方式，它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、Statements、日志完全打通，让使用者能够统一使用 SQL 查询。 +* **集群信息表**：TiDB 4.0 诊断系统添加了集群信息表，为原先离散的各节点实例信息提供了统一的获取方式。它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、语句、日志完全整合在表中，让用户能够统一使用 SQL 进行查询。 * **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 且由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，从而让用户能以一种更加便捷的方式从众多监控中找出异常的监控项。 * **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 From aaf04b6da23f071199d6a07e94e57d66da075e64 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:47:12 +0800 Subject: [PATCH 14/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index dc85182de709..15b5ed20ec0c 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -12,7 +12,7 @@ SQL 诊断共分三大块： * **集群信息表**：TiDB 4.0 诊断系统添加了集群信息表，为原先离散的各节点实例信息提供了统一的获取方式。它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、语句、日志完全整合在表中，让用户能够统一使用 SQL 进行查询。 * **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 -且由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，从而让用户能以一种更加便捷的方式从众多监控中找出异常的监控项。 +由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，让用户更便捷地从众多监控中找出异常的监控项。 * **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 ## 集群信息表 From 76df3eeebf662179d12a02feda29a993dab8c793 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:47:28 +0800 Subject: [PATCH 15/43] Update reference/system-databases/cluster_hardware.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_hardware.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 8d2fd7a56ef6..0225c8bba99f 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -36,7 +36,7 @@ desc cluster_hardware; * cpu：硬件名为 cpu * memory：硬件名为 memory * disk：磁盘名 - * net：NIC 名 + * `net`：NIC 名。 * NAME：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores`/`cpu-physical-cores`，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME * VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 @@ -60,4 +60,4 @@ select * from cluster_hardware where device_type='cpu' and device_name='cpu' and | tikv | 127.0.0.1:20160 | cpu | cpu | cpu-physical-cores | 4 | +------+-----------------+-------------+-------------+--------------------+-------+ 6 rows in set (0.26 sec) -``` \ No newline at end of file +``` From 76a72739b744eb8cbe7fb7aa823777420cd37b39 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:47:41 +0800 Subject: [PATCH 16/43] Update reference/system-databases/cluster_hardware.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_hardware.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 0225c8bba99f..390d105619fe 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -37,7 +37,7 @@ desc cluster_hardware; * memory：硬件名为 memory * disk：磁盘名 * `net`：NIC 名。 -* NAME：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores`/`cpu-physical-cores`，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME +* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 或 `cpu-physical-cores` 两个信息名。可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 * VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 具体示例，查询集群的 CPU 信息： From de9d5dd1e082e4a23577264b5a78eb4725d45bbc Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:48:31 +0800 Subject: [PATCH 17/43] Update reference/system-databases/cluster_hardware.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_hardware.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 390d105619fe..bd8fc8420829 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -40,7 +40,7 @@ desc cluster_hardware; * `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 或 `cpu-physical-cores` 两个信息名。可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 * VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 -具体示例，查询集群的 CPU 信息： +查询集群 CPU 信息的示例如下： {{< copyable "sql" >}} From c440c78115173b1d8ac98165e22bbea6d1d6cf92 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:48:44 +0800 Subject: [PATCH 18/43] Update reference/system-databases/cluster_info.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_info.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index 791e43e1b9bd..1ca9c2501ba3 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_INFO -集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 +集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、各节点的启动时间、各节点的运行时间。 {{< copyable "sql" >}} @@ -53,4 +53,4 @@ select * from cluster_info; | 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 | +------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ 3 rows in set (0.01 sec) -``` \ No newline at end of file +``` From 276f099b3a921fcd79473cb8ed9fa0548fb54be0 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 25 Mar 2020 15:48:53 +0800 Subject: [PATCH 19/43] Update reference/system-databases/cluster_info.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index 1ca9c2501ba3..ebcb3f7ae68b 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -32,7 +32,7 @@ desc cluster_info; * TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 * INSTANCE：实例地址，始终为 IP:PORT 格式的字符串 -* STATUS_ADDRESS：HTTP API 服务地址，部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API，会使用这个地址，用户也可以通过这个地址获取一些额外的集群信息，具体 HTTP API 参考官方文档 +* `STATUS_ADDRESS`：HTTP API 的服务地址。部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 * VERSION：对应节点的语义版本号，TiDB 版本为了兼容 MySQL 的版本号，以 ${mysql-version}-${tidb-version} 方式展示 * GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 * START_TIME：对应节点的启动时间 From 4a1607d8f91f2a6417ac1a78078dd8066e17fddf Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 15:57:31 +0800 Subject: [PATCH 20/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 15b5ed20ec0c..d07ea20db991 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -11,7 +11,7 @@ SQL 诊断功能是在 TiDB 4.0 版本中引入的特性，用于提升 TiDB 问 SQL 诊断共分三大块： * **集群信息表**：TiDB 4.0 诊断系统添加了集群信息表，为原先离散的各节点实例信息提供了统一的获取方式。它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、语句、日志完全整合在表中，让用户能够统一使用 SQL 进行查询。 -* **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 metrics_schema 中，可以通过 SQL 的方式查询监控，相对于原先的可视化监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 +* **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 语句来查询监控信息。比起原先的可视化监控，SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，让用户更便捷地从众多监控中找出异常的监控项。 * **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 From 742c3522e7d58a0edaf1ad497419cf8235bf26c5 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 15:58:17 +0800 Subject: [PATCH 21/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index d07ea20db991..109955ede0f6 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -17,7 +17,7 @@ SQL 诊断共分三大块： ## 集群信息表 -集群信息表将一个集群中的所有节点实例的信息都汇聚到了一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 +集群信息表将一个集群中的所有节点实例的信息都汇聚在一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 新增的集群信息表如下： * 集群拓扑表 `information_schema.cluster_info` 主要是用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 From bba068d172164672cb36d44605bbabe8f2f984b3 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 15:58:35 +0800 Subject: [PATCH 22/43] Update reference/system-databases/cluster_info.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index ebcb3f7ae68b..67f254f034a5 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -31,7 +31,7 @@ desc cluster_info; 字段解释： * TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 -* INSTANCE：实例地址，始终为 IP:PORT 格式的字符串 +* INSTANCE：实例地址，为 `IP:PORT` 格式的字符串。 * `STATUS_ADDRESS`：HTTP API 的服务地址。部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 * VERSION：对应节点的语义版本号，TiDB 版本为了兼容 MySQL 的版本号，以 ${mysql-version}-${tidb-version} 方式展示 * GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 From ee5ca59339ff30beba90c1c040d15c933dce6940 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 15:59:10 +0800 Subject: [PATCH 23/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 109955ede0f6..4199aefba9d9 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -18,7 +18,7 @@ SQL 诊断共分三大块： ## 集群信息表 集群信息表将一个集群中的所有节点实例的信息都汇聚在一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 -新增的集群信息表如下： +集群信息表列表如下： * 集群拓扑表 `information_schema.cluster_info` 主要是用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 * 集群配置表 `information_schema.cluster_config` 用于获取集群当前所有节点的配置，TiDB 4.0 之前的版本必须逐个访问各个节点的 HTTP API。 From 8711f0e40fb8ecc82d375b82136b9251ff12cee3 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 15:59:31 +0800 Subject: [PATCH 24/43] Update reference/system-databases/cluster_info.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_info.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index 67f254f034a5..ba81b19c0868 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -33,7 +33,7 @@ desc cluster_info; * TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 * INSTANCE：实例地址，为 `IP:PORT` 格式的字符串。 * `STATUS_ADDRESS`：HTTP API 的服务地址。部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 -* VERSION：对应节点的语义版本号，TiDB 版本为了兼容 MySQL 的版本号，以 ${mysql-version}-${tidb-version} 方式展示 +* `VERSION`：对应节点的语义版本号。TiDB 版本为了兼容 MySQL 的版本号，以 `${mysql-version}-${tidb-version}` 方式展示版本号。 * GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 * START_TIME：对应节点的启动时间 * UPTIME：对应节点已经运行的时间 From b49a46016bd37d9f06dc69b0d3573b116aef1f87 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 16:00:40 +0800 Subject: [PATCH 25/43] Update reference/system-databases/cluster_log.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_log.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index e0eb584a5f0b..13bed092694e 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -29,7 +29,7 @@ desc cluster_log; 字段解释： * TIME：日志打印时间。 -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 +* TYPE：对应节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 `tidb`，`pd` 或 `tikv`。 * INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 INSTANCE 字段。 * LEVEL：日志级别。 * MESSAGE：日志内容。 @@ -38,4 +38,4 @@ desc cluster_log; >日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，比如 select * from cluter_log where instance='tikv-1' 只会在 tikv-1 执行日志搜索。 >message 字段支持 like 和 regexp 正则表达式，对应的 pattern 会编译为 regexp，同时指定多个 message 条件，相当于 grep 命令的 pipeline 形式，例如：select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' 相当于在集群所有节点执行 grep 'coprocessor' xxx.log | grep -E '.*slow.*'。 -在TiDB 4.0 之前要获取集群的日志需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，可以更高效地提供一个全局时间有序的日志搜索结果，对于全链路事件跟踪提供便利的手段，比如按照某一个 region id 搜索日志，可以查询该 region 生命周期的所有日志，类似的通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 \ No newline at end of file +在TiDB 4.0 之前要获取集群的日志需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，可以更高效地提供一个全局时间有序的日志搜索结果，对于全链路事件跟踪提供便利的手段，比如按照某一个 region id 搜索日志，可以查询该 region 生命周期的所有日志，类似的通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 From a6c75f916c557b0cb83327705a739061ac3986d8 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Wed, 25 Mar 2020 16:01:02 +0800 Subject: [PATCH 26/43] Update reference/system-databases/cluster_hardware.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/cluster_hardware.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index bd8fc8420829..f4e0828c1bf4 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -38,7 +38,7 @@ desc cluster_hardware; * disk：磁盘名 * `net`：NIC 名。 * `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 或 `cpu-physical-cores` 两个信息名。可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 -* VALUE：对应硬件信息的值，比如磁盘容量，CPU 核数 +* `VALUE`：对应硬件信息的值。例如磁盘容量和 CPU 核数。 查询集群 CPU 信息的示例如下： From 0514530a83b26f7c829d688df4013dd96131e645 Mon Sep 17 00:00:00 2001 From: guoni Date: Thu, 26 Mar 2020 10:57:09 +0800 Subject: [PATCH 27/43] address comment --- reference/system-databases/cluster_config.md | 10 ++-- .../system-databases/cluster_hardware.md | 16 +++--- reference/system-databases/cluster_info.md | 14 +++--- reference/system-databases/cluster_load.md | 24 ++++----- reference/system-databases/cluster_log.md | 20 ++++---- .../system-databases/cluster_systeminfo.md | 14 +++--- .../system-databases/inspection_result.md | 28 +++++------ .../system-databases/inspection_summary.md | 12 ++--- reference/system-databases/metrics-schema.md | 10 ++-- reference/system-databases/metrics_summary.md | 49 +++++++++---------- reference/system-databases/metrics_tables.md | 10 ++-- reference/system-databases/sql-dignosis.md | 34 ++++++------- 12 files changed, 119 insertions(+), 122 deletions(-) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md index 22198b278ace..bb3b82039af9 100644 --- a/reference/system-databases/cluster_config.md +++ b/reference/system-databases/cluster_config.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_CONFIG -集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置，而 TiDB 4.0 之前的版本必须通过逐个访问各个节点的 HTTP API 的形式才能收集到所有节点配置。 +集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置。对于 TiDB 4.0 以前的版本，用户必须逐个访问各个节点的 HTTP API 才能收集到所有节点配置。 {{< copyable "sql" >}} @@ -27,10 +27,10 @@ desc cluster_config; 字段解释： -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 -* KEY：配置项名 -* VALUE：配置项值 +* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段。可取值为 `tidb`、`pd` 和 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。 +* `KEY`：配置项名。 +* `VALUE`：配置项值。 具体示例，查询 TiKV 节点的 `coprocessor` 相关配置： diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index f4e0828c1bf4..457466897707 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -29,15 +29,15 @@ desc cluster_hardware; 字段解释： -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段 -* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net -* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同 - * cpu：硬件名为 cpu - * memory：硬件名为 memory - * disk：磁盘名 +* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`、`pd` 和 `tikv`。 +* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* `DEVICE_TYPE`：硬件类型。目前可以查询的硬件类型有 `cpu`、`memory`、`disk` 和 `net`。 +* `DEVICE_NAME`：硬件名。对于不同的 `DEVICE_TYPE`，`DEVICE_NAME` 的取值不同。 + * `cpu`：硬件名为 cpu。 + * `memory`：硬件名为 memory。 + * `disk`：磁盘名。 * `net`：NIC 名。 -* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 或 `cpu-physical-cores` 两个信息名。可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 +* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 或 `cpu-physical-cores` 两个信息名，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 * `VALUE`：对应硬件信息的值。例如磁盘容量和 CPU 核数。 查询集群 CPU 信息的示例如下： diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index ba81b19c0868..ffa7338fcb27 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_INFO -集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、各节点的启动时间、各节点的运行时间。 +集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 `Git Hash`、各节点的启动时间、各节点的运行时间。 {{< copyable "sql" >}} @@ -30,13 +30,13 @@ desc cluster_info; 字段解释： -* TYPE：节点类型，目前节点的类型为 pd/tikv/tidb，节点类型始终为小写 -* INSTANCE：实例地址，为 `IP:PORT` 格式的字符串。 -* `STATUS_ADDRESS`：HTTP API 的服务地址。部分 tikv-ctl / pd-ctl / tidb-ctl 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 +* `TYPE`：节点类型，目前节点的类型为 pd/tikv/tidb +* `INSTANCE`：实例地址，为 `IP:PORT` 格式的字符串。 +* `STATUS_ADDRESS`：HTTP API 的服务地址。部分 `tikv-ctl`、`pd-ctl` 或 `tidb-ctl` 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 * `VERSION`：对应节点的语义版本号。TiDB 版本为了兼容 MySQL 的版本号，以 `${mysql-version}-${tidb-version}` 方式展示版本号。 -* GIT_HASH：对应节点版本编译时的 git commit hash，主要用于识别两个节点是否是绝对一致的版本 -* START_TIME：对应节点的启动时间 -* UPTIME：对应节点已经运行的时间 +* `GIT_HASH`：编译节点版本时的 `Git Commit Hash`，用于识别两个节点是否是绝对一致的版本。 +* `START_TIME`：对应节点的启动时间。 +* `UPTIME`：对应节点已经运行的时间。 {{< copyable "sql" >}} diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md index 79d06a83d1f9..1170615e3b6a 100644 --- a/reference/system-databases/cluster_load.md +++ b/reference/system-databases/cluster_load.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_LOAD -集群负载表 `CLUSTER_LOAD` 提供了集群不同节点的不同硬件类型的当前负载信息。 +集群负载表 `CLUSTER_LOAD` 提供集群不同节点、不同硬件的当前负载信息。 {{< copyable "sql" >}} @@ -29,18 +29,18 @@ desc cluster_load; 字段解释： -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 -* DEVICE_TYPE：硬件类型，目前可以查询的硬件类型有 cpu/memory/disk/net。 -* DEVICE_NAME：硬件名，对于不同的 DEVICE_TYPE，取值不同。 - * cpu：硬件名为 cpu。 - * disk：磁盘名。 - * net：NIC 名。 - * memory：硬件名为 memory。 -* NAME：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 CPU 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 -* VALUE：对应硬件负载的值，比如 CPU 的 1min/5min/15min 平均负载。 +* `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 `tidb`、`pd` 和 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* `DEVICE_TYPE`：硬件类型，目前可以查询的硬件类型有 `cpu`、`memory`、`disk` 和 `net`。 +* `DEVICE_NAME`：硬件名，对于不同的 `DEVICE_TYPE`，取值不同。 + * `cpu`：硬件名为 `cpu`。 + * `disk`：磁盘名。 + * `net`：`NIC` 名。 + * `memory`：硬件名为 `memory`。 +* `NAME`：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 cpu 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 +* `VALUE`：硬件负载的值，例如 cpu 在 `1min/5min/15min` 内的平均负载。 -具体示例，查询集群的 CPU 负载信息： +查询集群的 CPU 负载信息示例如下： {{< copyable "sql" >}} diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index 13bed092694e..60fbf7e9e53f 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_LOG -集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，**性能影响小于 grep 命令**。 +集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询。它通过将查询条件下推到各个节点，降低了日志查询对集群的影响。**性能优于 grep 命令**。 {{< copyable "sql" >}} @@ -28,14 +28,14 @@ desc cluster_log; 字段解释： -* TIME：日志打印时间。 -* TYPE：对应节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 `tidb`，`pd` 或 `tikv`。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 INSTANCE 字段。 -* LEVEL：日志级别。 -* MESSAGE：日志内容。 +* `TIME`：日志打印时间。 +* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。 +* `LEVEL`：日志级别。 +* `MESSAGE`：日志内容。 -> **注意事项：** ->日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，比如 select * from cluter_log where instance='tikv-1' 只会在 tikv-1 执行日志搜索。 ->message 字段支持 like 和 regexp 正则表达式，对应的 pattern 会编译为 regexp，同时指定多个 message 条件，相当于 grep 命令的 pipeline 形式，例如：select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' 相当于在集群所有节点执行 grep 'coprocessor' xxx.log | grep -E '.*slow.*'。 +> **注意：** +> 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，例如 `select * from cluter_log where instance='tikv-1'` 只会在 `tikv-1` 执行日志搜索。 +> `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 -在TiDB 4.0 之前要获取集群的日志需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，可以更高效地提供一个全局时间有序的日志搜索结果，对于全链路事件跟踪提供便利的手段，比如按照某一个 region id 搜索日志，可以查询该 region 生命周期的所有日志，类似的通过慢日志的 txn id 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 +TiDB 4.0 版本之前，要获取集群的日志用户需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，提供了一个全局时间有序的日志搜索结果，为全链路事件跟踪提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 `Region` 生命周期的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster_systeminfo.md index a844358055eb..46e98708f8c3 100644 --- a/reference/system-databases/cluster_systeminfo.md +++ b/reference/system-databases/cluster_systeminfo.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_SYSTEMINFO -集群负载表 `CLUSTER_SYSTEMINFO` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 +集群负载表 `CLUSTER_SYSTEMINFO` 用于查询集群不同节点的内核配置信息。目前支持查询 `sysctl` 的信息。 {{< copyable "sql" >}} @@ -29,12 +29,12 @@ desc cluster_systeminfo; 字段解释： -* TYPE：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 tidb/pd/tikv，且均为小写。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 -* SYSTEM_TYPE：系统类型，目前可以查询的系统类型有 system。 -* SYSTEM_NAME：目前可以查询的 SYSTEM_NAME 为 sysctl。 -* NAME：sysctl 对应的配置名。 -* VALUE：sysctl 对应配置项的值。 +* `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。 +* `SYSTEM_TYPE`：系统类型，目前可以查询的系统类型有 `system`。 +* `SYSTEM_NAME`：目前可以查询的 `SYSTEM_NAME` 为 `sysctl`。 +* `NAME`：`sysctl` 对应的配置名。 +* `VALUE`：`sysctl` 对应配置项的值。 ```sql select * from cluster_systeminfo where name like '%fd%'; diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index 142555e43b49..73bee59ffb2e 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -35,21 +35,21 @@ mysql> desc inspection_result; 字段解释： -* RULE：诊断规则，目前实现了 - * config：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果 - * version：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果 - * current-load：如果当前系统负载太高，会生成对应的 warning 诊断结果 - * critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果 - * threshold-check：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息 -* ITEM：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 -* TYPE：诊断的实例类型，可能是 tidb/tikv/pd -* INSTANCE：诊断的具体实例 -* VALUE：针对这个诊断项得到的值 -* REFERENCE：针对这个诊断项的参考值（阈值），如果 VALUE 和阈值差距比较大，就会产生对应的结果 -* SEVERITY：严重程度，warning/critical -* DETAILS：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接 +* `RULE`：诊断规则，目前实现了以下规则： + * `config`：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果。 + * `version`：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果。 + * `current-load`：如果当前系统负载太高，会生成对应的 warning 诊断结果。 + * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果。 + * `threshold-check`：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 +* `ITEM`：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 +* `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：诊断的具体实例。 +* `VALUE`：针对这个诊断项得到的值。 +* `REFERENCE`：针对这个诊断项的参考值（阈值），如果 VALUE 和阈值差距比较大，就会产生对应的结果。 +* `SEVERITY`：严重程度，`warning` 或 `critical`。 +* `DETAILS`：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接。 -诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比，如果结果超过阈值或低于阈值将生成 warning / critical 的结果，并在 details 列中提供进一步信息。 +诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比，如果结果超过阈值或低于阈值将生成 `warning` 或 `critical` 的结果，并在 `details` 列中提供相应信息。 查询已有的诊断规则: diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 533b91d16faa..7fa3cbf41598 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -33,18 +33,18 @@ mysql> desc inspection_summary; 字段解释： -* RULE：汇总规则，由于规则在持续添加，以下列表可能已经过时，最新的规则列表可以通过 select * from inspection_rules where type='summary' 查询 -* INSTANCE：监控的具体实例 -* METRIC_NAME：监控表 -* QUANTILE：对于包含 QUANTILE 的监控表有效，可以通过谓词下推指定多个百分位，比如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 ddl 相关监控，查询百分位为 80/90/99/999 的结果。 AVG_VALUE/MIN_VALUE/MAX_VALUE 分别表示聚合的平均、最小、最大值。 +* `RULE`：汇总规则。由于规则在持续添加，最新的规则列表可以通过 `select * from inspection_rules where type='summary'` 查询。 +* `INSTANCE`：监控的具体实例。 +* `METRIC_NAME`：监控表。 +* `QUANTILE`：对于包含 `QUANTILE` 的监控表有效，可以通过谓词下推指定多个百分位，比如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 ddl 相关监控，查询百分位为 80/90/99/999 的结果。`AVG_VALUE`、`MIN_VALUE`、`MAX_VALUE` 分别表示聚合的平均、最小、最大值。 > **注意事项：** > ->由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即通过 SQL 的谓词中显示指定的 rule 才会运行。比如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 +> 由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即通过 SQL 的谓词中显示指定的 `rule` 才会运行。比如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 使用示例: -诊断结果表和诊断监控汇总表都可以通过 hint 的方式指定诊断的时间范围，比如 select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary 对2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： +诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，比如 `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： 诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index 054708c4a443..607b5ba95db1 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -12,7 +12,7 @@ category: reference 系统表数量较多，这里挑出比较典型的 `tidb_query_duration` 表来作为示例讲解： -`tidb_query_duration` 的表结构如下，从表的 COMMENT 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 +`tidb_query_duration` 的表结构如下，从表的 `COMMENT` 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 {{< copyable "sql" >}} @@ -34,7 +34,7 @@ show create table tidb_query_duration; +---------------------+--------------------------------------------------------------------------------------------------------------------+ ``` -比如 tikv_admin_apply 有三个 label，对应的表也会有三个额外的列。 +比如 `tikv_admin_apply` 有三个 label，对应的表也会有三个额外的列。 {{< copyable "sql" >}} @@ -55,7 +55,7 @@ desc metrics_schema.tikv_admin_apply; 5 rows in set (0.00 sec) ``` -下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，internal 类型的 P90 耗时是 0.00327。instance 字段是 TiDB 示例的地址。 +下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，`internal` 类型的 P90 耗时是 0.00327。`instance` 字段是 TiDB 示例的地址。 {{< copyable "sql" >}} @@ -74,5 +74,5 @@ metrics_schema> select * from tidb_query_duration where value is not null and ti 监控表 session 变量： -* tidb_metric_query_step：查询的分辨率步长。从 Promethues 的 query_range 数据时需要指定 start，end，step，其中 step 会使用该变量的值 -* tidb_metric_query_range_duration：查询监控时，会将 PROMQL 中的 $RANGE_DURATION 替换成该变量的值，默认值是 60 秒 \ No newline at end of file +* `tidb_metric_query_step`：查询的分辨率步长。从 `Promethues` 的 `query_range` 数据时需要指定 `start`，`end`，`step`，其中 `step` 会使用该变量的值。 +* `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。 \ No newline at end of file diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index c46bbc6b4506..be1203e2279e 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -7,11 +7,10 @@ category: reference 由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： -* information_schema.metrics_summary -* information_schema.metrics_summary_by_label +* `information_schema.metrics_summary`。 +* `information_schema.metrics_summary_by_label`。 -这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 -两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 +这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 {{< copyable "sql" >}} @@ -36,15 +35,15 @@ mysql> desc metrics_summary; 字段解释： -* METRICS_NAME：监控表名 -* QUANTILE：百分位，可以通过 SQL 语句指定 QUANTILE，例如 - * select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据 - * select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999) 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据 -* SUM_VALUE / AVG_VALUE / MIN_VALUE / MAX_VALUE -* COMMENT：对应监控的解释 +* `METRICS_NAME`：监控表名 +* `QUANTILE`：百分位，可以通过 SQL 语句指定 `QUANTILE`，例如 + * `select * from metrics_summary where quantile=0.99` 指定查看百分位为 0.99 的数据。 + * `select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999)` 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据。 +* `SUM_VALUE、AVG_VALUE、MIN_VALUE、MAX_VALUE`：分别表示总和，平均值，最小值，最大值。 +* `COMMENT`：对应监控的解释。 具体查询示例： -以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 information_schema.metrics_summary 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL： +以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00'] 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 `information_schema.metrics_summary` 表，并通过 `/*+ time_range() */` 这个 hint 来指定时间范围来构造以下 SQL： {{< copyable "sql" >}} @@ -85,7 +84,7 @@ MAX_VALUE | 0.013 COMMENT | The quantile of kv requests durations by store ``` -类似的，查询 metrics_summary_by_label 监控汇总表结果如下： +类似的，查询 `metrics_summary_by_label` 监控汇总表结果如下： {{< copyable "sql" >}} @@ -132,15 +131,15 @@ MAX_VALUE | 0.008241 COMMENT | The quantile of TiDB query durations(second) ``` -前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 LABEL, 以上面查询结果的第 2, 3 行为例：分别表示 `tidb_query_duration` 的 Select/Rollback 类型的语句平均耗时非常高。 +前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 LABEL, 以上面查询结果的第 2, 3 行为例：分别表示 `tidb_query_duration` 的 Select 和 Rollback 类型的语句平均耗时非常高。 除以上示例之外，监控汇总表可以通过两个时间段的全链路监控对比，迅速找出监控数据变化最大的模块，快速定位瓶颈，以下对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： * 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00") * 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") -对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 TIME_RANGE 是用于指定查询时间的 Hint。 +对两个时间段的监控按照 `METRICS_NAME` 进行 join，并按照差值排序。其中 `TIME_RANGE` 是用于指定查询时间的 Hint。 -查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项: +查询 `t1.avg_value` 与 `t2.avg_value` 差异最大的 10 个监控项: {{< copyable "sql" >}} @@ -187,9 +186,9 @@ ORDER BY 查询结果表示： -* t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍 -* t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍 -* t1 时间段内的 tidb_kv_write_size （tidb 每个事务写入的 kv 大小） 比 t2 时间段高了 1.96 倍 +* t1 时间段内的 `tikv_region_average_written_bytes` region 的平均写入字节数）比 t2 时间段高了 17.6 倍。 +* t1 时间段内的 `tikv_region_average_written_keys`（region 的平均写入 keys 数）比 t2 时间段高了 8.8 倍。 +* t1 时间段内的 `tidb_kv_write_size`（tidb 每个事务写入的 kv 大小）比 t2 时间段高了 1.96 倍。 通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 @@ -234,17 +233,17 @@ ORDER BY | 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) | | 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | | | 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | | -| 101.635495394 | tikv_cop_total_kv_cursor_operations | 1070.875 | 108838.91113 | | +| 10``1.635495394 | tikv_cop_total_kv_cursor_operations | 1070.875 | 108838.91113 | | +----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ ``` 上面查询结果表示： -* t2 时间段内的 tidb_slow_query_cop_process_total_time （tidb 慢查询中的 cop process 耗时 ） 比 t1 时间段高了 5865 倍 -* t2 时间段内的 tidb_distsql_partial_scan_key_total_num（tidb 的 distsql 请求扫描key 的数量） 比 t1 时间段高了 3648 倍 -* t2 时间段内的 tikv_cop_total_response_size（tikv 的 cop 请求结果的大小 ） 比 t1 时间段高了 192 倍 -* t2 时间段内的 tikv_cop_scan_details（tikv 的 cop 请求的 scan ） 比 t1 时间段高了 105 倍 +* t2 时间段内的 `tidb_slow_query_cop_process_total_time`（tidb 慢查询中的 `cop process` 耗时 ）比 t1 时间段高了 5865 倍。 +* t2 时间段内的 `tidb_distsql_partial_scan_key_total_num`（tidb 的 `distsql` 请求扫描key 的数量）比 t1 时间段高了 3648 倍。 +* t2 时间段内的 `tikv_cop_total_response_size`（tikv 的 cop 请求结果的大小 ）比 t1 时间段高了 192 倍。 +* t2 时间段内的 `tikv_cop_scan_details`（tikv 的 cop 请求的 scan ）比 t1 时间段高了 105 倍。 -通过上面两个时间段对比查询可以大致了解集群在这 2 个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 cop task 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 +对比上面两个时间段的查询，可以大致了解集群在这两个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 `Copprocessor` 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 -实际上，在 t1 ~ t2 整个时间段内都在跑 go-ycsb 的压测，然后在 t2 时间段跑了 20 个 tpch 的查询，所以是因为 tpch 大查询导致了很多的 cop 请求。 +实际上，在 t1 ~ t2 整个时间段内都在跑 `go-ycsb` 的压测，然后在 t2 时间段跑了 20 个 `tpch` 的查询，所以是因为 `tpch` 大查询导致了很多的 cop 请求。 diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics_tables.md index 8dd275593e45..d16871d95062 100644 --- a/reference/system-databases/metrics_tables.md +++ b/reference/system-databases/metrics_tables.md @@ -28,8 +28,8 @@ desc metrics_tables; 表 `metrics_tables` 的字段解释： -* TABLE_NAME：对应于 metrics_schema 中的表名。 -* PROMQL：监控表的主要原理是将 SQL 映射成 PromQL，并将 Promethues 结果转换成 SQL 查询结果。这个字段是 PromQL 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 -* LABELS：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 PromQL 也会改变。 -* QUANTILE：百分位，对于直方图类型的监控数据，指定一个默认百分位，如果值为 0，表示该监控表对应的监控不是直方图。 -* COMMENT：是对这个监控表的解释。 \ No newline at end of file +* `TABLE_NAME`：对应于 `metrics_schema` 中的表名。 +* `PROMQL`：监控表的主要原理是将 SQL 映射成 `PromQL`，并将 `Prometheus` 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `LABELS`：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 `PromQL` 也会改变。 +* `QUANTILE`：百分位，对于直方图类型的监控数据，指定一个默认百分位，如果值为 0，表示该监控表对应的监控不是直方图。 +* `COMMENT`：对这个监控表的解释。 \ No newline at end of file diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index 4199aefba9d9..f56e9a21fc95 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -11,40 +11,38 @@ SQL 诊断功能是在 TiDB 4.0 版本中引入的特性，用于提升 TiDB 问 SQL 诊断共分三大块： * **集群信息表**：TiDB 4.0 诊断系统添加了集群信息表，为原先离散的各节点实例信息提供了统一的获取方式。它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、语句、日志完全整合在表中，让用户能够统一使用 SQL 进行查询。 -* **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 语句来查询监控信息。比起原先的可视化监控，SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 -由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，让用户更便捷地从众多监控中找出异常的监控项。 -* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表和集群监控表与汇总表来发现集群问题，但自动挡总是更香的，所以 SQL 诊断利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断。 +* **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 语句来查询监控信息。比起原先的可视化监控，SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，让用户能够更便捷地从众多监控中找出异常的监控项。 +* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表、集群监控表与汇总表，但自动诊断更加方便。所以 SQL 诊断基于已有的集群信息表和监控表，提供了与之相关的诊断结果表与诊断汇总表来执行自动诊断。 ## 集群信息表 集群信息表将一个集群中的所有节点实例的信息都汇聚在一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 集群信息表列表如下： -* 集群拓扑表 `information_schema.cluster_info` 主要是用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、启动时间、运行时间信息。 -* 集群配置表 `information_schema.cluster_config` 用于获取集群当前所有节点的配置，TiDB 4.0 之前的版本必须逐个访问各个节点的 HTTP API。 -* 集群硬件表 `information_schema.cluster_hardware` 主要用于快速查询集群硬件信息。 -* 集群负载表 `information_schema.cluster_load` 主要用于查询集群不同节点的不同硬件类型的负载信息。 -* 内核参数表 `information_schema.cluster_systeminfo` 主要用于查询集群不同节点的内核配置信息，目前支持查询 sysctl 的信息。 -* 集群日志表 `information_schema.cluster_log` 表主要用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，性能影响小于等 grep 命令。 +* 集群拓扑表 `information_schema.cluster_info` 用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、各节点的启动时间、各节点的运行时间。 +* 集群配置表 `information_schema.cluster_config` 用于获取集群当前所有节点的配置。对于 TiDB 4.0 之前的版本，用户必须逐个访问各个节点的 HTTP API 才能获取这些配置信息。 +* 集群硬件表 `information_schema.cluster_hardware` 用于快速查询集群硬件信息。 +* 集群负载表 `information_schema.cluster_load` 用于查询集群不同节点以及不同硬件类型的负载信息。 +* 内核参数表 `information_schema.cluster_systeminfo` 用于查询集群不同节点的内核配置信息。目前支持查询 sysctl 的信息。 +* 集群日志表 `information_schema.cluster_log` 用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，性能影响小于等 grep 命令。 -TiDB 4.0 之前的以下系统表，只能查看当前节点，TiDB 4.0 实现了对应的集群表，可以在单个 TiDB 节点上拥有整个集群的全局视图。 -这些表目前都位于 information_schema 中，查询形式上与其他 information_schema 系统表一致。 +TiDB 4.0 之前的系统表，只能查看当前节点，TiDB 4.0 实现了对应的集群表，可以在单个 TiDB 节点上拥有整个集群的全局视图。 +这些表目前都位于 `information_schema` 中，查询方式与其他 `information_schema` 系统表一致。 ## 集群监控表 -为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 +为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有监控表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控信息。SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 * `information_schema.metrics_tables`：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 -由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供了监控汇总表： +由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供以下监控汇总表： -* 监控汇总表 `information_schema.metrics_summary` 用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。 -* 监控汇总表 `information_schema.metrics_summary_by_label` 同样用于汇总所有监控数据，不过它会对不同的 label 使用区分统计。 +* 监控汇总表 `information_schema.metrics_summary` 用于汇总所有监控数据，以提升用户排查各监控指标的效率。 +* 监控汇总表 `information_schema.metrics_summary_by_label` 同样用于汇总所有监控数据，不过该表会对不同的 label 进行区分统计。 ## 自动诊断 -前面介绍了集群信息表和集群监控表，并通过 SQL 演示了如何通过查询这些表来发现集群问题，比如通过 information_schema.cluster_config 发现集群不同节点配置不一致，通过 `information_schema.metrics_summary` 发现指定时间范围内 TiDB 集群中平均耗时最高的监控项。 -不过手动执行固定模式的 SQL 排查集群问题是低效的，为了进一步优化用户体验，方便用户使用，于是我们利用已有的基础信息表提供了诊断相关的系统表来自动执行诊断： +以上集群信息表和集群监控表均需要用户手动执行固定模式的 SQL 语句来排查集群问题。为了进一步优化用户体验，TiDB 根据已有的基础信息表，提供诊断相关的系统表，使诊断自动执行。自动诊断相关的系统表如下： -* 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果，诊断是惰性触发，使用 SQL `select * from inspection_result` 会触发所有的诊断规则对系统进行诊断，并会在结果集中展示系统中的故障或风险。 +* 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果。诊断是惰性触发，使用 `select * from inspection_result` 会触发所有诊断规则对系统进行诊断，并在结果中展示系统中的故障或风险。 * 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 From 04df9fab44767be760ab4beac7bc42b52be01b51 Mon Sep 17 00:00:00 2001 From: guoni Date: Thu, 26 Mar 2020 11:13:46 +0800 Subject: [PATCH 28/43] refine doc --- reference/system-databases/cluster_config.md | 2 +- reference/system-databases/cluster_info.md | 2 +- reference/system-databases/cluster_load.md | 2 +- reference/system-databases/cluster_log.md | 2 +- reference/system-databases/inspection_result.md | 8 ++++---- reference/system-databases/inspection_summary.md | 2 +- reference/system-databases/metrics_summary.md | 6 +++--- 7 files changed, 12 insertions(+), 12 deletions(-) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md index bb3b82039af9..d2ea4578bfb2 100644 --- a/reference/system-databases/cluster_config.md +++ b/reference/system-databases/cluster_config.md @@ -32,7 +32,7 @@ desc cluster_config; * `KEY`：配置项名。 * `VALUE`：配置项值。 -具体示例，查询 TiKV 节点的 `coprocessor` 相关配置： +以下示例查询 TiKV 节点的 `coprocessor` 相关配置： {{< copyable "sql" >}} diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index ffa7338fcb27..e40274ea41a4 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -30,7 +30,7 @@ desc cluster_info; 字段解释： -* `TYPE`：节点类型，目前节点的类型为 pd/tikv/tidb +* `TYPE`：节点类型，目前节点的可取值为 `tidb`、`pd` 和 `tikv`。 * `INSTANCE`：实例地址，为 `IP:PORT` 格式的字符串。 * `STATUS_ADDRESS`：HTTP API 的服务地址。部分 `tikv-ctl`、`pd-ctl` 或 `tidb-ctl` 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 * `VERSION`：对应节点的语义版本号。TiDB 版本为了兼容 MySQL 的版本号，以 `${mysql-version}-${tidb-version}` 方式展示版本号。 diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md index 1170615e3b6a..54df302aac64 100644 --- a/reference/system-databases/cluster_load.md +++ b/reference/system-databases/cluster_load.md @@ -37,7 +37,7 @@ desc cluster_load; * `disk`：磁盘名。 * `net`：`NIC` 名。 * `memory`：硬件名为 `memory`。 -* `NAME`：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 cpu 在 1min/5min/15min 中的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 +* `NAME`：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 cpu 在 `1min/5min/15min` 内的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 * `VALUE`：硬件负载的值，例如 cpu 在 `1min/5min/15min` 内的平均负载。 查询集群的 CPU 负载信息示例如下： diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index 60fbf7e9e53f..f1a39c5ef1b9 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -38,4 +38,4 @@ desc cluster_log; > 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，例如 `select * from cluter_log where instance='tikv-1'` 只会在 `tikv-1` 执行日志搜索。 > `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 -TiDB 4.0 版本之前，要获取集群的日志用户需要逐个登录各个节点汇总日志。TiDB 4.0 有了集群日志表后，提供了一个全局时间有序的日志搜索结果，为全链路事件跟踪提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 `Region` 生命周期的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 +TiDB 4.0 版本之前，要获取集群的日志用户需要逐个登录各个节点汇总日志。TiDB 4.0 的集群日志表 提供了一个全局时间有序的日志搜索结果，为全链路事件跟踪提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 `Region` 生命周期的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index 73bee59ffb2e..ed24a1db5449 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -36,10 +36,10 @@ mysql> desc inspection_result; 字段解释： * `RULE`：诊断规则，目前实现了以下规则： - * `config`：配置一致性检测，如果同一个配置在不同节点不同，会生成 warning 级别的诊断结果。 - * `version`：版本一致性检测，如果同一类型的节点版本不同，会生成 critical 级别的诊断结果。 - * `current-load`：如果当前系统负载太高，会生成对应的 warning 诊断结果。 - * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果。 + * `config`：配置一致性检测，如果同一个配置在不同节点不同，会生成 `warning` 级别的诊断结果。 + * `version`：版本一致性检测，如果同一类型的节点版本不同，会生成 `critical` 级别的诊断结果。 + * `current-load`：如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 + * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 `warning` 诊断结果。 * `threshold-check`：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 * `ITEM`：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 * `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 或 `tikv`。 diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 7fa3cbf41598..01bee13d9cf3 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -5,7 +5,7 @@ category: reference # INSPECTION_SUMMARY -在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 +在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 `Coprocessor` 配置的线程池为 8，如果 `Coprocessor` 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 诊断汇总表 `information_schema.inspection_summary` 的表结构如下： diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index be1203e2279e..65da40f04ece 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -135,11 +135,11 @@ COMMENT | The quantile of TiDB query durations(second) 除以上示例之外，监控汇总表可以通过两个时间段的全链路监控对比，迅速找出监控数据变化最大的模块，快速定位瓶颈，以下对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： -* 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00") -* 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") +* 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00")。 +* 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") 。 对两个时间段的监控按照 `METRICS_NAME` 进行 join，并按照差值排序。其中 `TIME_RANGE` 是用于指定查询时间的 Hint。 -查询 `t1.avg_value` 与 `t2.avg_value` 差异最大的 10 个监控项: +查询 `t1.avg_value` / `t2.avg_value` 差异最大的 10 个监控项: {{< copyable "sql" >}} From 943a9f24a73e348af3cc6cd1dd2a4dd0d2298e01 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Thu, 26 Mar 2020 17:07:14 +0800 Subject: [PATCH 29/43] refine punctuations and wording --- reference/system-databases/cluster_config.md | 4 +- .../system-databases/cluster_hardware.md | 6 +-- reference/system-databases/cluster_info.md | 8 ++-- reference/system-databases/cluster_load.md | 16 +++---- reference/system-databases/cluster_log.md | 8 ++-- .../system-databases/cluster_systeminfo.md | 2 +- .../system-databases/inspection_result.md | 12 ++--- .../system-databases/inspection_summary.md | 18 +++---- reference/system-databases/metrics-schema.md | 13 +++-- reference/system-databases/metrics_summary.md | 48 ++++++++++--------- reference/system-databases/metrics_tables.md | 8 ++-- 11 files changed, 73 insertions(+), 70 deletions(-) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md index d2ea4578bfb2..7b891b09e26e 100644 --- a/reference/system-databases/cluster_config.md +++ b/reference/system-databases/cluster_config.md @@ -27,8 +27,8 @@ desc cluster_config; 字段解释： -* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段。可取值为 `tidb`、`pd` 和 `tikv`。 -* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。 +* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段。可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。 * `KEY`：配置项名。 * `VALUE`：配置项值。 diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 457466897707..9158298faed2 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_HARDWARE -集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点实例的硬件信息。 +集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点和实例的硬件信息。 {{< copyable "sql" >}} @@ -29,8 +29,8 @@ desc cluster_hardware; 字段解释： -* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`、`pd` 和 `tikv`。 -* INSTANCE：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。 * `DEVICE_TYPE`：硬件类型。目前可以查询的硬件类型有 `cpu`、`memory`、`disk` 和 `net`。 * `DEVICE_NAME`：硬件名。对于不同的 `DEVICE_TYPE`，`DEVICE_NAME` 的取值不同。 * `cpu`：硬件名为 cpu。 diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index e40274ea41a4..7928266618f4 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_INFO -集群拓扑表 `CLUSTER_INFO` 提供了集群当前的拓扑信息，以及各个节点的版本、版本对应的 `Git Hash`、各节点的启动时间、各节点的运行时间。 +集群拓扑表 `CLUSTER_INFO` 提供集群当前的拓扑信息，以及各个节点的版本信息、版本对应的 Git Hash、各节点的启动时间、各节点的运行时间。 {{< copyable "sql" >}} @@ -30,11 +30,11 @@ desc cluster_info; 字段解释： -* `TYPE`：节点类型，目前节点的可取值为 `tidb`、`pd` 和 `tikv`。 +* `TYPE`：节点类型，目前节点的可取值为 `tidb`，`pd` 或 `tikv`。 * `INSTANCE`：实例地址，为 `IP:PORT` 格式的字符串。 * `STATUS_ADDRESS`：HTTP API 的服务地址。部分 `tikv-ctl`、`pd-ctl` 或 `tidb-ctl` 命令会使用到 HTTP API 和该地址。用户也可以通过该地址获取一些额外的集群信息，详情可参考 HTTP API 官方文档。 -* `VERSION`：对应节点的语义版本号。TiDB 版本为了兼容 MySQL 的版本号，以 `${mysql-version}-${tidb-version}` 方式展示版本号。 -* `GIT_HASH`：编译节点版本时的 `Git Commit Hash`，用于识别两个节点是否是绝对一致的版本。 +* `VERSION`：对应节点的语义版本号。TiDB 版本为了兼容 MySQL 的版本号，以 `${mysql-version}-${tidb-version}` 的格式展示版本号。 +* `GIT_HASH`：编译节点版本时的 Git Commit Hash，用于识别两个节点是否是绝对一致的版本。 * `START_TIME`：对应节点的启动时间。 * `UPTIME`：对应节点已经运行的时间。 diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md index 54df302aac64..3e64ff5f56e8 100644 --- a/reference/system-databases/cluster_load.md +++ b/reference/system-databases/cluster_load.md @@ -29,16 +29,16 @@ desc cluster_load; 字段解释： -* `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 TYPE 字段，可取值为 `tidb`、`pd` 和 `tikv`。 -* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 STATUS_ADDRESS 字段。 +* `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。 * `DEVICE_TYPE`：硬件类型，目前可以查询的硬件类型有 `cpu`、`memory`、`disk` 和 `net`。 -* `DEVICE_NAME`：硬件名，对于不同的 `DEVICE_TYPE`，取值不同。 - * `cpu`：硬件名为 `cpu`。 +* `DEVICE_NAME`：硬件名。对于不同的 `DEVICE_TYPE`，`DEVICE_NAME` 取值不同。 + * `cpu`：硬件名为 cpu。 * `disk`：磁盘名。 - * `net`：`NIC` 名。 - * `memory`：硬件名为 `memory`。 -* `NAME`：不同负载类型，比如 cpu 有 `load1/load5/load15` 分别表示 cpu 在 `1min/5min/15min` 内的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 NAME。 -* `VALUE`：硬件负载的值，例如 cpu 在 `1min/5min/15min` 内的平均负载。 + * `net`：NIC 名。 + * `memory`：硬件名为 memory。 +* `NAME`：不同的负载类型。例如 cpu 有 `load1`/`load5`/`load15` 三个负载类型，分别表示 cpu 在 `1min`/`5min`/`15min` 内的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 +* `VALUE`：硬件负载的值，例如 cpu 在 `1min`/`5min`/`15min` 内的平均负载。 查询集群的 CPU 负载信息示例如下： diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index f1a39c5ef1b9..a24981f14c1b 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_LOG -集群日志表 `CLUSTER_LOG` 表主要用于集群日志查询。它通过将查询条件下推到各个节点，降低了日志查询对集群的影响。**性能优于 grep 命令**。 +集群日志表 `CLUSTER_LOG` 表用于查询集群日志。它通过将查询条件下推到各个节点，降低了日志查询对集群的影响。该表的查询性能优于 grep 命令。 {{< copyable "sql" >}} @@ -35,7 +35,9 @@ desc cluster_log; * `MESSAGE`：日志内容。 > **注意：** -> 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件，例如 `select * from cluter_log where instance='tikv-1'` 只会在 `tikv-1` 执行日志搜索。 +> +> + 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件。例如 `select * from cluter_log where instance='tikv-1'` 只会在 `tikv-1` 上执行日志搜索。 +> > `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 -TiDB 4.0 版本之前，要获取集群的日志用户需要逐个登录各个节点汇总日志。TiDB 4.0 的集群日志表 提供了一个全局时间有序的日志搜索结果，为全链路事件跟踪提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 `Region` 生命周期的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 +TiDB 4.0 版本之前，要获取集群的日志，用户需要逐个登录各个节点汇总日志。TiDB 4.0 的集群日志表提供了一个全局且时间有序的日志搜索结果，为跟踪全链路事件提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 Region 生命周期内的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster_systeminfo.md index 46e98708f8c3..c1c0043c551e 100644 --- a/reference/system-databases/cluster_systeminfo.md +++ b/reference/system-databases/cluster_systeminfo.md @@ -30,7 +30,7 @@ desc cluster_systeminfo; 字段解释： * `TYPE`：对应于节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。 -* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。 +* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。 * `SYSTEM_TYPE`：系统类型，目前可以查询的系统类型有 `system`。 * `SYSTEM_NAME`：目前可以查询的 `SYSTEM_NAME` 为 `sysctl`。 * `NAME`：`sysctl` 对应的配置名。 diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index ed24a1db5449..5b0d29ee4e33 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -7,7 +7,7 @@ category: reference TiDB 内置了一些诊断规则，用于检测系统中的故障以及隐患。 -该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 SQL `select * from information_schema.inspection_result` 来触发内部的诊断。 +该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 `select * from information_schema.inspection_result` 语句来触发内部诊断。 诊断结果表 `information_schema.inspection_result` 的表结构如下： @@ -36,20 +36,20 @@ mysql> desc inspection_result; 字段解释： * `RULE`：诊断规则，目前实现了以下规则： - * `config`：配置一致性检测，如果同一个配置在不同节点不同，会生成 `warning` 级别的诊断结果。 - * `version`：版本一致性检测，如果同一类型的节点版本不同，会生成 `critical` 级别的诊断结果。 + * `config`：配置一致性检测。如果同一个配置在不同节点不一致，会生成 `warning` 诊断结果。 + * `version`：版本一致性检测。如果同一类型的节点版本不同，会生成 `critical` 诊断结果。 * `current-load`：如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 `warning` 诊断结果。 * `threshold-check`：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 -* `ITEM`：每一个规则会对不同的项进行诊断，这个用来表示对应规则下面的具体诊断项。 +* `ITEM`：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。 * `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 或 `tikv`。 * `INSTANCE`：诊断的具体实例。 * `VALUE`：针对这个诊断项得到的值。 -* `REFERENCE`：针对这个诊断项的参考值（阈值），如果 VALUE 和阈值差距比较大，就会产生对应的结果。 +* `REFERENCE`：针对这个诊断项的参考值（阈值）。如果 `VALUE` 和阈值相差较大，就会产生对应的结果。 * `SEVERITY`：严重程度，`warning` 或 `critical`。 * `DETAILS`：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接。 -诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比，如果结果超过阈值或低于阈值将生成 `warning` 或 `critical` 的结果，并在 `details` 列中提供相应信息。 +诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比。如果结果超过阈值或低于阈值将生成 `warning` 或 `critical` 的结果，并在 `details` 列中提供相应信息。 查询已有的诊断规则: diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 01bee13d9cf3..9d1539603b69 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -5,12 +5,12 @@ category: reference # INSPECTION_SUMMARY -在部分场景下我们只想要关注特定链路或模块的监控汇总，比如当前 `Coprocessor` 配置的线程池为 8，如果 `Coprocessor` 的 CPU 使用率达到了 750%，可以确定这里有风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。这部分场景问题排查也非常重要，所以新建了 `inspection_summary` 来进行链路汇总。 +在部分场景下，用户只关注特定链路或模块的监控汇总。例如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定存在风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。排查这部分场景的问题也非常重要，所以TiDB 提供了 `inspection_summary` 来进行链路汇总。 诊断汇总表 `information_schema.inspection_summary` 的表结构如下： - -{{< copyable "sql" >}} - + +{{< copyable "sql" >}} + ```sql mysql> desc inspection_summary; ``` @@ -36,17 +36,17 @@ mysql> desc inspection_summary; * `RULE`：汇总规则。由于规则在持续添加，最新的规则列表可以通过 `select * from inspection_rules where type='summary'` 查询。 * `INSTANCE`：监控的具体实例。 * `METRIC_NAME`：监控表。 -* `QUANTILE`：对于包含 `QUANTILE` 的监控表有效，可以通过谓词下推指定多个百分位，比如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 ddl 相关监控，查询百分位为 80/90/99/999 的结果。`AVG_VALUE`、`MIN_VALUE`、`MAX_VALUE` 分别表示聚合的平均、最小、最大值。 +* `QUANTILE`：对于包含 `QUANTILE` 的监控表有效，可以通过谓词下推指定多个百分位，例如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 DDL 相关监控，查询百分位为 80/90/99/999 的结果。`AVG_VALUE`、`MIN_VALUE`、`MAX_VALUE` 分别表示聚合的平均值、最小值、最大值。 -> **注意事项：** +> **注意：** > -> 由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即通过 SQL 的谓词中显示指定的 `rule` 才会运行。比如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 +> 由于汇总所有结果有一定开销，所以 `information_summary` 中的规则是惰性触发的，即在 SQL 的谓词中显示指定的 `rule` 才会运行。例如 `select * from inspection_summary` 语句会得到一个空的结果集。`select * from inspection_summary where rule in ('read-link', 'ddl')` 会汇总读链路和 DDL 相关的监控。 使用示例: -诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，比如 `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，通过两个不同时间段的数据进行对比，快速发现差异较大的监控项。以下为一个例子： +诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，例如 `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 是对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，诊断结果表通过对比两个不同时间段的数据，快速发现差异较大的监控项。以下为一个例子： -诊断集群在时间段 "2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933" 的故障: +诊断集群在时间段 `"2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933"` 的故障: {{< copyable "sql" >}} diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index 607b5ba95db1..af91b0efc66d 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -5,14 +5,13 @@ category: reference # Metrics Schema -为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控，SQL 查询监控的好处在于可以对整个集群的所有监控进行关联查询， -并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 +为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控。SQL 查询监控的优点在于用户可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 -## tidb_query_duration 表 +## `tidb_query_duration` 表 -系统表数量较多，这里挑出比较典型的 `tidb_query_duration` 表来作为示例讲解： +系统表数量较多，这里挑出比较典型的 `tidb_query_duration` 表来作为示例。 -`tidb_query_duration` 的表结构如下，从表的 `COMMENT` 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999，P99，P90 的查询耗时，单位是秒。 +`tidb_query_duration` 的表结构如下。从表的 `COMMENT` 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。 {{< copyable "sql" >}} @@ -55,7 +54,7 @@ desc metrics_schema.tikv_admin_apply; 5 rows in set (0.00 sec) ``` -下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，Select 类似的 Query 的 P90 耗时是 0.0384 秒，`internal` 类型的 P90 耗时是 0.00327。`instance` 字段是 TiDB 示例的地址。 +下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，`Select` Query 类型的 P90 耗时是 0.0384 秒，`internal` 类型的 P90 耗时是 0.00327。`instance` 字段是 TiDB 示例的地址。 {{< copyable "sql" >}} @@ -74,5 +73,5 @@ metrics_schema> select * from tidb_query_duration where value is not null and ti 监控表 session 变量： -* `tidb_metric_query_step`：查询的分辨率步长。从 `Promethues` 的 `query_range` 数据时需要指定 `start`，`end`，`step`，其中 `step` 会使用该变量的值。 +* `tidb_metric_query_step`：查询的分辨率步长。从 Prometheus 的 `query_range` 数据时需要指定 `start`，`end` 和 `step`，其中 `step` 会使用该变量的值。 * `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。 \ No newline at end of file diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index 65da40f04ece..21ce9765805c 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -5,12 +5,12 @@ category: reference # METRICS_SUMMARY -由于 TiDB 集群的监控指标数量较大，因此为了方便用户能更加便捷地从众多监控中找出异常的监控项，TiDB 4.0 提供了监控汇总表： +由于 TiDB 集群的监控指标数量较多，为了方便用户从众多监控中找出异常的监控项，TiDB 4.0 提供了以下监控汇总表： -* `information_schema.metrics_summary`。 -* `information_schema.metrics_summary_by_label`。 +* `information_schema.metrics_summary` +* `information_schema.metrics_summary_by_label` -这两张表用于汇总所有监控数据，以提升用户对各个监控指标进行排查的效率。两者不同在于 information_schema.metrics_summary_by_label 会对不同的 label 使用区分统计。 +这两张表用于汇总所有监控数据，用户排查各个监控指标会更有效率。其中 `information_schema.metrics_summary_by_label` 会对不同的 label 进行区分统计。 {{< copyable "sql" >}} @@ -35,15 +35,16 @@ mysql> desc metrics_summary; 字段解释： -* `METRICS_NAME`：监控表名 -* `QUANTILE`：百分位，可以通过 SQL 语句指定 `QUANTILE`，例如 +* `METRICS_NAME`：监控表名。 +* `QUANTILE`：百分位。可以通过 SQL 语句指定 `QUANTILE`，例如： * `select * from metrics_summary where quantile=0.99` 指定查看百分位为 0.99 的数据。 * `select * from metrics_summary where quantile in (0.80, 0.99, 0.99, 0.999)` 同时查看百分位为 0.80, 0.99, 0.99, 0.999 的数据。 -* `SUM_VALUE、AVG_VALUE、MIN_VALUE、MAX_VALUE`：分别表示总和，平均值，最小值，最大值。 +* `SUM_VALUE、AVG_VALUE、MIN_VALUE、MAX_VALUE` 分别表示总和、平均值、最小值、最大值。 * `COMMENT`：对应监控的解释。 具体查询示例： -以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00'] 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 `information_schema.metrics_summary` 表，并通过 `/*+ time_range() */` 这个 hint 来指定时间范围来构造以下 SQL： + +查询 `'2020-03-08 13:23:00', '2020-03-08 13:33:00'` 时间范围内 TiDB 集群中平均耗时最高的三组监控项。可直接查询 `information_schema.metrics_summary` 表，并通过 `/*+ time_range() */` 这个 hint 来指定时间范围，构造的 SQL 语句如下： {{< copyable "sql" >}} @@ -84,7 +85,7 @@ MAX_VALUE | 0.013 COMMENT | The quantile of kv requests durations by store ``` -类似的，查询 `metrics_summary_by_label` 监控汇总表结果如下： +类似的，查询 `metrics_summary_by_label` 监控汇总表示例如下： {{< copyable "sql" >}} @@ -131,13 +132,14 @@ MAX_VALUE | 0.008241 COMMENT | The quantile of TiDB query durations(second) ``` -前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 LABEL, 以上面查询结果的第 2, 3 行为例：分别表示 `tidb_query_duration` 的 Select 和 Rollback 类型的语句平均耗时非常高。 +前文提到 `metrics_summary_by_label` 表结构相对于 `metrics_summary` 多了一列 `LABEL`。以上面查询结果的第 2、3 行分别表示 `tidb_query_duration` 的 `Select` 和 `Rollback` 类型的语句平均耗时非常高。 + +除以上示例之外，监控汇总表可以通过对比两个时间段的全链路监控，迅速找出监控数据中变化最大的模块，快速定位瓶颈。以下示例对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： -除以上示例之外，监控汇总表可以通过两个时间段的全链路监控对比，迅速找出监控数据变化最大的模块，快速定位瓶颈，以下对比两个时间段的所有监控（其中 t1 为 baseline），并按照差别最大的监控排序： +* 时间段 t1：`("2020-03-03 17:08:00", "2020-03-03 17:11:00")` +* 时间段 t2：`("2020-03-03 17:18:00", "2020-03-03 17:21:00")` -* 时间段 t1 : ("2020-03-03 17:08:00", "2020-03-03 17:11:00")。 -* 时间段 t2 : ("2020-03-03 17:18:00", "2020-03-03 17:21:00") 。 -对两个时间段的监控按照 `METRICS_NAME` 进行 join，并按照差值排序。其中 `TIME_RANGE` 是用于指定查询时间的 Hint。 +对两个时间段的监控按照 `METRICS_NAME` 进行 join，并按照差值排序。其中 `TIME_RANGE` 是用于指定查询时间的 hint。 查询 `t1.avg_value` / `t2.avg_value` 差异最大的 10 个监控项: @@ -186,13 +188,13 @@ ORDER BY 查询结果表示： -* t1 时间段内的 `tikv_region_average_written_bytes` region 的平均写入字节数）比 t2 时间段高了 17.6 倍。 -* t1 时间段内的 `tikv_region_average_written_keys`（region 的平均写入 keys 数）比 t2 时间段高了 8.8 倍。 +* t1 时间段内的 `tikv_region_average_written_bytes` Region 的平均写入字节数，比 t2 时间段高了 17.6 倍。 +* t1 时间段内的 `tikv_region_average_written_keys` Region 的平均写入 key 数，比 t2 时间段高了 8.8 倍。 * t1 时间段内的 `tidb_kv_write_size`（tidb 每个事务写入的 kv 大小）比 t2 时间段高了 1.96 倍。 通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 -反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项: +反过来，查询 `t2.avg_value` 和 `t1.avg_value` 差异最大的十个监控项： {{< copyable "sql" >}} @@ -239,11 +241,11 @@ ORDER BY 上面查询结果表示： -* t2 时间段内的 `tidb_slow_query_cop_process_total_time`（tidb 慢查询中的 `cop process` 耗时 ）比 t1 时间段高了 5865 倍。 -* t2 时间段内的 `tidb_distsql_partial_scan_key_total_num`（tidb 的 `distsql` 请求扫描key 的数量）比 t1 时间段高了 3648 倍。 -* t2 时间段内的 `tikv_cop_total_response_size`（tikv 的 cop 请求结果的大小 ）比 t1 时间段高了 192 倍。 -* t2 时间段内的 `tikv_cop_scan_details`（tikv 的 cop 请求的 scan ）比 t1 时间段高了 105 倍。 +* t2 时间段内的 `tidb_slow_query_cop_process_total_time`（TiDB 慢查询中的 `cop process` 耗时）比 t1 时间段高了 5865 倍。 +* t2 时间段内的 `tidb_distsql_partial_scan_key_total_num`（TiDB 的 `distsql` 请求扫描key 的数量）比 t1 时间段高了 3648 倍。 +* t2 时间段内的 `tikv_cop_total_response_size`（TiKV 的 cop 请求结果的大小 ）比 t1 时间段高了 192 倍。 +* t2 时间段内的 `tikv_cop_scan_details`（TiKV 的 cop 请求的 scan ）比 t1 时间段高了 105 倍。 -对比上面两个时间段的查询，可以大致了解集群在这两个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 `Copprocessor` 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 +对比上面两个时间段的查询，可以大致了解集群在这两个时间段的负载情况。t2 时间段的 cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 -实际上，在 t1 ~ t2 整个时间段内都在跑 `go-ycsb` 的压测，然后在 t2 时间段跑了 20 个 `tpch` 的查询，所以是因为 `tpch` 大查询导致了很多的 cop 请求。 +实际上，在 t1 ~ t2 整个时间段内都在跑 `go-ycsb` 的压测，然后在 t2 时间段跑了 20 个 `tpch` 的查询，所以是因为 `tpch` 大查询导致了出现很多的 cop 请求。 diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics_tables.md index d16871d95062..eddf2c279614 100644 --- a/reference/system-databases/metrics_tables.md +++ b/reference/system-databases/metrics_tables.md @@ -29,7 +29,7 @@ desc metrics_tables; 表 `metrics_tables` 的字段解释： * `TABLE_NAME`：对应于 `metrics_schema` 中的表名。 -* `PROMQL`：监控表的主要原理是将 SQL 映射成 `PromQL`，并将 `Prometheus` 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 -* `LABELS`：监控定义的 label，每一个 label 会对应监控表中的一列，SQL 中如果包含对应列的过滤，对应的 `PromQL` 也会改变。 -* `QUANTILE`：百分位，对于直方图类型的监控数据，指定一个默认百分位，如果值为 0，表示该监控表对应的监控不是直方图。 -* `COMMENT`：对这个监控表的解释。 \ No newline at end of file +* `PROMQL`：监控表的主要原理是将 SQL 映射成 `PromQL`，并将 Prometheus 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `LABELS`：监控定义的 label，每一个 label 对应监控表中的一列。SQL 中如果包含对应列的过滤，对应的 `PromQL` 也会改变。 +* `QUANTILE`：百分位。对于直方图类型的监控数据，指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。 +* `COMMENT`：对这个监控表的解释。 From bc211ce0ddcfc47cd3b88eccad5d80694f27c60a Mon Sep 17 00:00:00 2001 From: crazycs520 Date: Fri, 27 Mar 2020 21:09:33 +0800 Subject: [PATCH 30/43] add more docs Signed-off-by: crazycs520 --- reference/system-databases/cluster_config.md | 8 +- .../system-databases/cluster_hardware.md | 8 +- reference/system-databases/cluster_info.md | 1 - reference/system-databases/cluster_load.md | 10 +- reference/system-databases/cluster_log.md | 39 ++- .../system-databases/cluster_systeminfo.md | 24 +- .../system-databases/information-schema.md | 1 - .../system-databases/inspection_result.md | 250 +++++++++++++++++- .../system-databases/inspection_summary.md | 1 - reference/system-databases/metrics-schema.md | 1 - reference/system-databases/metrics_summary.md | 1 - reference/system-databases/metrics_tables.md | 1 - 12 files changed, 297 insertions(+), 48 deletions(-) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster_config.md index 7b891b09e26e..21593ce5b84b 100644 --- a/reference/system-databases/cluster_config.md +++ b/reference/system-databases/cluster_config.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_CONFIG -集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有节点的配置。对于 TiDB 4.0 以前的版本，用户必须逐个访问各个节点的 HTTP API 才能收集到所有节点配置。 +集群配置表 `CLUSTER_CONFIG` 用于获取集群当前所有 TiDB/PD/TiKV 节点的配置。对于 TiDB 4.0 以前的版本，用户需要逐个访问各个节点的 HTTP API 才能收集到所有组件配置。 {{< copyable "sql" >}} @@ -22,13 +22,12 @@ desc cluster_config; | KEY | varchar(256) | YES | | NULL | | | VALUE | varchar(128) | YES | | NULL | | +----------+--------------+------+------+---------+-------+ -4 rows in set (0.00 sec) ``` 字段解释： -* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段。可取值为 `tidb`，`pd` 或 `tikv`。 -* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `STATUS_ADDRESS` 字段。 +* `TYPE`：节点的类型，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：节点的服务地址。 * `KEY`：配置项名。 * `VALUE`：配置项值。 @@ -51,5 +50,4 @@ select * from cluster_config where type='tikv' and `key` like 'coprocessor%'; | tikv | 127.0.0.1:20160 | coprocessor.region-split-size | 96MiB | | tikv | 127.0.0.1:20160 | coprocessor.split-region-on-table | false | +------+-----------------+-----------------------------------+----------+ -6 rows in set (1.04 sec) ``` \ No newline at end of file diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster_hardware.md index 9158298faed2..3950bfbb9f7f 100644 --- a/reference/system-databases/cluster_hardware.md +++ b/reference/system-databases/cluster_hardware.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_HARDWARE -集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点和实例的硬件信息。 +集群硬件表 `CLUSTER_HARDWARE` 提供了集群各节点所在服务器的硬件信息。 {{< copyable "sql" >}} @@ -24,7 +24,6 @@ desc cluster_hardware; | NAME | varchar(256) | YES | | NULL | | | VALUE | varchar(128) | YES | | NULL | | +-------------+--------------+------+------+---------+-------+ -6 rows in set (0.00 sec) ``` 字段解释： @@ -36,8 +35,8 @@ desc cluster_hardware; * `cpu`：硬件名为 cpu。 * `memory`：硬件名为 memory。 * `disk`：磁盘名。 - * `net`：NIC 名。 -* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` 或 `cpu-physical-cores` 两个信息名，可以通过 `select name from cluster_hardware where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 + * `net`：网卡名。 +* `NAME`：硬件不同的信息名，比如 cpu 有 `cpu-logical-cores` ， `cpu-physical-cores` 两个信息名，表示逻辑核心数量和物理核心数量。 * `VALUE`：对应硬件信息的值。例如磁盘容量和 CPU 核数。 查询集群 CPU 信息的示例如下： @@ -59,5 +58,4 @@ select * from cluster_hardware where device_type='cpu' and device_name='cpu' and | tikv | 127.0.0.1:20160 | cpu | cpu | cpu-logical-cores | 8 | | tikv | 127.0.0.1:20160 | cpu | cpu | cpu-physical-cores | 4 | +------+-----------------+-------------+-------------+--------------------+-------+ -6 rows in set (0.26 sec) ``` diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster_info.md index 7928266618f4..634d9d22cc75 100644 --- a/reference/system-databases/cluster_info.md +++ b/reference/system-databases/cluster_info.md @@ -52,5 +52,4 @@ select * from cluster_info; | 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 | +------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ -3 rows in set (0.01 sec) ``` diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster_load.md index 3e64ff5f56e8..9fd24a51ab9c 100644 --- a/reference/system-databases/cluster_load.md +++ b/reference/system-databases/cluster_load.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_LOAD -集群负载表 `CLUSTER_LOAD` 提供集群不同节点、不同硬件的当前负载信息。 +集群负载表 `CLUSTER_LOAD` 提供集群各个节点所在服务器的的当前负载信息。 {{< copyable "sql" >}} @@ -24,7 +24,6 @@ desc cluster_load; | NAME | varchar(256) | YES | | NULL | | | VALUE | varchar(128) | YES | | NULL | | +-------------+--------------+------+------+---------+-------+ -6 rows in set (0.00 sec) ``` 字段解释： @@ -35,12 +34,12 @@ desc cluster_load; * `DEVICE_NAME`：硬件名。对于不同的 `DEVICE_TYPE`，`DEVICE_NAME` 取值不同。 * `cpu`：硬件名为 cpu。 * `disk`：磁盘名。 - * `net`：NIC 名。 + * `net`：网卡名。 * `memory`：硬件名为 memory。 -* `NAME`：不同的负载类型。例如 cpu 有 `load1`/`load5`/`load15` 三个负载类型，分别表示 cpu 在 `1min`/`5min`/`15min` 内的平均负载，可以通过 `select name from cluster_load where device_type='cpu' group by name` 来查询不同硬件类型支持的 `NAME`。 +* `NAME`：不同的负载类型。例如 cpu 有 `load1`/`load5`/`load15` 三个负载类型，分别表示 cpu 在 `1min`/`5min`/`15min` 内的平均负载。 * `VALUE`：硬件负载的值，例如 cpu 在 `1min`/`5min`/`15min` 内的平均负载。 -查询集群的 CPU 负载信息示例如下： +查询集群当前的 CPU 负载信息示例如下： {{< copyable "sql" >}} @@ -62,5 +61,4 @@ select * from cluster_load where device_type='cpu' and device_name='cpu'; | tikv | 127.0.0.1:20160 | cpu | cpu | load5 | 2.15576171875 | | tikv | 127.0.0.1:20160 | cpu | cpu | load15 | 2.2421875 | +------+-----------------+-------------+-------------+--------+---------------+ -9 rows in set (0.52 sec) ``` \ No newline at end of file diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster_log.md index a24981f14c1b..0e45664617da 100644 --- a/reference/system-databases/cluster_log.md +++ b/reference/system-databases/cluster_log.md @@ -5,7 +5,9 @@ category: reference # CLUSTER_LOG -集群日志表 `CLUSTER_LOG` 表用于查询集群日志。它通过将查询条件下推到各个节点，降低了日志查询对集群的影响。该表的查询性能优于 grep 命令。 +集群日志表 `CLUSTER_LOG` 表用于查询集群当前所有 TiDB/PD/TiKV 节点日志。它通过将查询条件下推到各个节点，降低了日志查询对集群的影响。该表的查询性能优于 grep 命令。 + +TiDB 4.0 版本之前，要获取集群的日志，用户需要逐个登录各个节点汇总日志。TiDB 4.0 的集群日志表提供了一个全局且时间有序的日志搜索结果，为跟踪全链路事件提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 Region 生命周期内的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 {{< copyable "sql" >}} @@ -29,8 +31,8 @@ desc cluster_log; 字段解释： * `TIME`：日志打印时间。 -* `TYPE`：对应节点信息表 `information_schema.cluster_info` 中的 `TYPE` 字段，可取值为 `tidb`，`pd` 或 `tikv`。 -* `INSTANCE`：对应于节点信息表 `information_schema.cluster_info` 中的 `INSTANCE` 字段。 +* `TYPE`：节点的类型，可取值为 `tidb`，`pd` 或 `tikv`。 +* `INSTANCE`：节点的服务地址。 * `LEVEL`：日志级别。 * `MESSAGE`：日志内容。 @@ -38,6 +40,33 @@ desc cluster_log; > > + 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件。例如 `select * from cluter_log where instance='tikv-1'` 只会在 `tikv-1` 上执行日志搜索。 > -> `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 +> + `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 -TiDB 4.0 版本之前，要获取集群的日志，用户需要逐个登录各个节点汇总日志。TiDB 4.0 的集群日志表提供了一个全局且时间有序的日志搜索结果，为跟踪全链路事件提供了便利的手段。例如按照某一个 `region id` 搜索日志，可以查询该 Region 生命周期内的所有日志；类似地，通过慢日志的 `txn id` 搜索全链路日志，可以查询该事务在各个节点扫描的 key 数量以及流量等信息。 +查询某个 DDL 的执行过程示例如下： + +{{< 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'; +``` + +``` ++-------------------------+------+------------------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| TIME | TYPE | INSTANCE | LEVEL | MESSAGE | ++-------------------------+------+------------------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4008 | INFO | [ddl_worker.go:253] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0; "] | +| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4008 | INFO | [ddl.go:457] ["[ddl] start DDL job"] [job="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] [query="create table t3 (a int, b int,c int)"] | +| 2020/03/27 15:39:36.879 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:554] ["[ddl] run DDL job"] [worker="worker 1, tp general"] [job="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:0, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] | +| 2020/03/27 15:39:36.936 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:739] ["[ddl] wait latest schema version changed"] [worker="worker 1, tp general"] [ver=35] ["take time"=52.165811ms] [job="ID:58, Type:create table, State:done, SchemaState:public, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] | +| 2020/03/27 15:39:36.938 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:359] ["[ddl] finish DDL job"] [worker="worker 1, tp general"] [job="ID:58, Type:create table, State:synced, SchemaState:public, SchemaID:1, TableID:57, RowCount:0, ArgLen:0, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] | +| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:253] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0; "] | +| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4009 | INFO | [ddl.go:457] ["[ddl] start DDL job"] [job="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] [query="create table t3 (a int, b int,c int)"] | +| 2020/03/27 15:39:37.141 | tidb | 172.16.5.40:4008 | INFO | [ddl.go:489] ["[ddl] DDL job is finished"] [jobID=58] | ++-------------------------+------+------------------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +``` + +上面查询结果表示： + +1. 用户将 DDL JOB ID 为 58 的请求发给 `172.16.5.40:4008` TiDB 节点。 +2. `172.16.5.40:4009` TiDB 节点处理这个 DDL 请求，说明此时 `172.16.5.40:4009` 节点是 DDL owner。 +3. DDL JOB ID 为 58 的请求处理完成。 \ No newline at end of file diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster_systeminfo.md index c1c0043c551e..574d361a73f4 100644 --- a/reference/system-databases/cluster_systeminfo.md +++ b/reference/system-databases/cluster_systeminfo.md @@ -5,7 +5,7 @@ category: reference # CLUSTER_SYSTEMINFO -集群负载表 `CLUSTER_SYSTEMINFO` 用于查询集群不同节点的内核配置信息。目前支持查询 `sysctl` 的信息。 +集群负载表 `CLUSTER_SYSTEMINFO` 用于查询集群所有节点所在服务器的内核配置信息。目前支持查询 `sysctl` 的信息。 {{< copyable "sql" >}} @@ -36,20 +36,18 @@ desc cluster_systeminfo; * `NAME`：`sysctl` 对应的配置名。 * `VALUE`：`sysctl` 对应配置项的值。 +查询集群所有服务器的内核版本示例如下： + ```sql -select * from cluster_systeminfo where name like '%fd%'; +select * from CLUSTER_SYSTEMINFO where name like '%kernel.osrelease%' ``` ``` -+------+-----------------+-------------+-------------+-------------------------------+-------+ -| TYPE | INSTANCE | SYSTEM_TYPE | SYSTEM_NAME | NAME | VALUE | -+------+-----------------+-------------+-------------+-------------------------------+-------+ -| tidb | 127.0.0.1:10080 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | -| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.client_fd_count | 98 | -| tidb | 127.0.0.1:10080 | system | sysctl | net.necp.observer_fd_count | 0 | -| pd | 127.0.0.1:2379 | system | sysctl | net.inet6.ip6.maxifdefrouters | 16 | -| pd | 127.0.0.1:2379 | system | sysctl | net.necp.client_fd_count | 98 | -| pd | 127.0.0.1:2379 | system | sysctl | net.necp.observer_fd_count | 0 | -+------+-----------------+-------------+-------------+-------------------------------+-------+ -6 rows in set (0.04 sec) ++------+-------------------+-------------+-------------+------------------+----------------------------+ +| TYPE | INSTANCE | SYSTEM_TYPE | SYSTEM_NAME | NAME | VALUE | ++------+-------------------+-------------+-------------+------------------+----------------------------+ +| tidb | 172.16.5.40:4008 | system | sysctl | kernel.osrelease | 3.10.0-862.14.4.el7.x86_64 | +| pd | 172.16.5.40:20379 | system | sysctl | kernel.osrelease | 3.10.0-862.14.4.el7.x86_64 | +| tikv | 172.16.5.40:21150 | system | sysctl | kernel.osrelease | 3.10.0-862.14.4.el7.x86_64 | ++------+-------------------+-------------+-------------+------------------+----------------------------+ ``` \ No newline at end of file diff --git a/reference/system-databases/information-schema.md b/reference/system-databases/information-schema.md index 2b8b875774c3..8ca73ccc2e97 100644 --- a/reference/system-databases/information-schema.md +++ b/reference/system-databases/information-schema.md @@ -541,7 +541,6 @@ CONSTRAINT_CATALOG: def TABLE_SCHEMA: mysql TABLE_NAME: gc_delete_range_done CONSTRAINT_TYPE: UNIQUE -6 rows in set (0.00 sec) ``` 其中： diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection_result.md index 5b0d29ee4e33..99dc041d7a82 100644 --- a/reference/system-databases/inspection_result.md +++ b/reference/system-databases/inspection_result.md @@ -35,7 +35,7 @@ mysql> desc inspection_result; 字段解释： -* `RULE`：诊断规则，目前实现了以下规则： +* `RULE`：诊断规则名称，目前实现了以下规则： * `config`：配置一致性检测。如果同一个配置在不同节点不一致，会生成 `warning` 诊断结果。 * `version`：版本一致性检测。如果同一类型的节点版本不同，会生成 `critical` 诊断结果。 * `current-load`：如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 @@ -43,20 +43,127 @@ mysql> desc inspection_result; * `threshold-check`：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 * `ITEM`：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。 * `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 或 `tikv`。 -* `INSTANCE`：诊断的具体实例。 +* `INSTANCE`：诊断的具体实例地址。 * `VALUE`：针对这个诊断项得到的值。 -* `REFERENCE`：针对这个诊断项的参考值（阈值）。如果 `VALUE` 和阈值相差较大，就会产生对应的结果。 -* `SEVERITY`：严重程度，`warning` 或 `critical`。 +* `REFERENCE`：针对这个诊断项的参考值（阈值）。如果 `VALUE` 和阈值相差较大，就会产生对应的诊断信息。 +* `SEVERITY`：严重程度，取值为 `warning` 或 `critical`。 * `DETAILS`：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接。 +## 诊断示例 + +诊断集群当前时间的问题。 + +{{< copyable "sql" >}} + +```sql +select * from inspection_result\G +``` + +``` +***************************[ 1. row ]*************************** +RULE | config +ITEM | log.slow-threshold +TYPE | tidb +INSTANCE | 172.16.5.40:4000 +VALUE | 0 +REFERENCE | not 0 +SEVERITY | warning +DETAILS | slow-threshold = 0 will record every query to slow log, it may affect performance +***************************[ 2. row ]*************************** +RULE | version +ITEM | git_hash +TYPE | tidb +INSTANCE | +VALUE | inconsistent +REFERENCE | consistent +SEVERITY | critical +DETAILS | the cluster has 2 different tidb version, execute the sql to see more detail: select * from information_schema.cluster_info where type='tidb' +***************************[ 3. row ]*************************** +RULE | threshold-check +ITEM | storage-write-duration +TYPE | tikv +INSTANCE | 172.16.5.40:23151 +VALUE | 130.417 +REFERENCE | < 0.100 +SEVERITY | warning +DETAILS | max duration of 172.16.5.40:23151 tikv storage-write-duration was too slow +***************************[ 4. row ]*************************** +RULE | threshold-check +ITEM | rocksdb-write-duration +TYPE | tikv +INSTANCE | 172.16.5.40:20151 +VALUE | 108.105 +REFERENCE | < 0.100 +SEVERITY | warning +DETAILS | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was too slow +``` + +上述诊断结果发现了以下几个问题： + +* 第一行表示 TiDB 的 log.slow-threshold 配置值为 0 ， 可能会影响性能。 +* 第二行表示集群中有 2 个不同的 TiDB 版本 +* 第三、四行表示 TiKV 的写入延迟太大，期望时间是不超过 0.1s, 但实际值远超预期。 + +诊断集群在时间段 "2020-03-26 00:03:00", "2020-03-26 00:08:00" 的问题。指定时间范围需要使用 `/*+ time_range() */` 的 SQL Hint，参考下面的查询示例： + +{{< copyable "sql" >}} + +```sql +select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from inspection_result\G +``` + +``` +***************************[ 1. row ]*************************** +RULE | critical-error +ITEM | server-down +TYPE | tidb +INSTANCE | 172.16.5.40:4009 +VALUE | +REFERENCE | +SEVERITY | critical +DETAILS | tidb 172.16.5.40:4009 restarted at time '2020/03/26 00:05:45.670' +***************************[ 2. row ]*************************** +RULE | threshold-check +ITEM | get-token-duration +TYPE | tidb +INSTANCE | 172.16.5.40:10089 +VALUE | 0.234 +REFERENCE | < 0.001 +SEVERITY | warning +DETAILS | max duration of 172.16.5.40:10089 tidb get-token-duration is too slow +``` + +上面的诊断结果发现了以下问题： + +* 第一行表示 172.16.5.40:4009 TiDB 节点在 `2020/03/26 00:05:45.670` 发生了重启。 +* 第二行表示 172.16.5.40:10089 TiDB 节点的最大的 get-token-duration 时间为 0.234s, 期望时间是小于 0.001s。 + +也可以指定条件，比如只查询 `critical` 严重级别的诊断结果： + +{{< copyable "sql" >}} + +```sql +select * from inspection_result where severity='critical'; +``` + +只查询 `critical-error` 规则的诊断结果: + +{{< copyable "sql" >}} + +```sql +select * from inspection_result where rule='critical-error'; +``` + +## 诊断规则介绍 + 诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比。如果结果超过阈值或低于阈值将生成 `warning` 或 `critical` 的结果，并在 `details` 列中提供相应信息。 -查询已有的诊断规则: +可以通过查询 `inspection_rules` 系统表查询已有的诊断规则: {{< copyable "sql" >}} ```sql -mysql> select * from inspection_rules where type='inspection'; +select * from inspection_rules where type='inspection'; ``` ``` @@ -69,5 +176,132 @@ mysql> select * from inspection_rules where type='inspection'; | critical-error | inspection | | | threshold-check | inspection | | +-----------------+------------+---------+ -5 rows in set (0.00 sec) -``` \ No newline at end of file +``` + +### config 诊断规则 + +config 诊断规则通过查询 `CLUSTER_CONFIG` 系统表，执行以下 2 个诊断规则： + +* 检测相同组件的配置值是否一致，并非所有配置项都会有一致性检查，下面是一致性检查的白名单： + + ```go + // TiDB 配置一致性检查白名单 + port + status.status-port + host + path + advertise-address + status.status-port + log.file.filename + log.slow-query-file + + // PD 配置一致性检查白名单 + advertise-client-urls + advertise-peer-urls + client-urls + data-dir + log-file + log.file.filename + metric.job + name + peer-urls + + // TiKV 配置一致性检查白名单 + server.addr + server.advertise-addr + server.status-addr + log-file + raftstore.raftdb-path + storage.data-dir + ``` + +* 检测以下配置项的值是否符合预期。 + +| 组件 | 配置项 | 预期值 | +| ---- | ---- | ---- | +| TiDB | log.slow-threshold | 大于 0 | +| TiKV | raftstore.sync-log | true | + +### version 诊断规则 + +version 诊断规则通过查询 `CLUSTER_INFO` 系统表，检测相同组件的版本 hash 是否一致。示例如下： + +{{< copyable "sql" >}} + +```sql +select * from inspection_result where rule='version'\G +``` + +``` +***************************[ 1. row ]*************************** +RULE | version +ITEM | git_hash +TYPE | tidb +INSTANCE | +VALUE | inconsistent +REFERENCE | consistent +SEVERITY | critical +DETAILS | the cluster has 2 different tidb versions, execute the sql to see more detail: select * from information_schema.cluster_info where type='tidb' +``` + +### critical-error 诊断规则 + +critical-error 诊断规则执行以下 2 个诊断规则： + +* 通过查询 metrics_schema 数据库中相关的监控系统表，检测集群是否有出现以下比较严重的错误： + +| 组件 | 错误名字 | 相关监控表 | 错误说明 | +| ---- | ---- | ---- | ---- | +| TiDB | panic-count | tidb_panic_count_total_count | TiDB 出现 panic 错误 | +| TiDB | binlog-error | tidb_binlog_error_total_count | TiDB 写 binlog 时出现的错误 | +| TiKV | critical-error | tikv_critical_error_total_coun | TiKV 的 critical error | +| TiKV | scheduler-is-busy | tikv_scheduler_is_busy_total_count | TiKV 的 scheduler 太忙，该使 TiKV 临时不可用 | +| TiKV | coprocessor-is-busy | tikv_coprocessor_is_busy_total_count | TiKV 的 coprocessor 太忙 | +| TiKV | channel-is-full | tikv_channel_full_total_count | TiKV 出现 channel full 的错误 | +| TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV 出现写入 stall 的错误 | + +* 通过查询 metrics_schema.up 监控表和 `CLUSTER_LOG` 系统表，检查是否有组件发生重启。 + +### threshold-check 诊断规则 + +threshold-check 诊断规则通过查询 metrics_schema 数据库中相关的监控系统表，检测集群中以下指标是否超出阈值： + +| 组件 | 监控指标 | 相关监控表 | 预期值 | 说明 | +| ---- | ---- | ---- | ---- | ---- | +| TiDB | tso-duration | pd_tso_wait_duration | 小于 50 ms | 获取事务 TSO 时间戳的耗时 | +| TiDB | get-token-duration | tidb_get_token_duration | 小于 1 ms | 查询获取 token 的耗时, 相关的 TiDB 配置参数是 token-limit | +| TiDB | load-schema-duration | tidb_load_schema_duration | 小于 1 s | TiDB 更新获取表元信息的耗时 | +| TiKV | scheduler-cmd-duration | tikv_scheduler_command_duration | 小于 0.1 s | TiKV 执行 KV cmd 请求的耗时 | +| TiKV | handle-snapshot-duration | tikv_handle_snapshot_duration | 小于 30 s | TiKV 处理 snapshot 的耗时 | +| TiKV | storage-write-duration | tikv_storage_async_request_duration | 小于 0.1 s | TiKV 写入的延迟 | +| TiKV | storage-snapshot-duration | tikv_storage_async_request_duration | 小于 50 ms | TiKV 获取 snapshot 的耗时 | +| TiKV | rocksdb-write-duration | tikv_engine_write_duration | 小于 100 ms | TiKV RocksDB 的写入延迟 | +| TiKV | rocksdb-get-duration | tikv_engine_max_get_duration | 小于 50 ms | TiKV RocksDB 的读取延迟 | +| TiKV | rocksdb-seek-duration | tikv_engine_max_seek_duration | 小于 50 ms | TiKV RocksDB 执行 seek 的延迟 | +| TiKV | scheduler-pending-cmd-coun | tikv_scheduler_pending_commands | 小于 1000 | TiKV 中被阻塞的命令数量 | +| TiKV | index-block-cache-hit | tikv_block_index_cache_hit | 大于 0.95 | TiKV 中 index block 缓存的命中率 | +| TiKV | filter-block-cache-hit | tikv_block_filter_cache_hit | 大于 0.95 | TiKV 中 filter block 缓存的命中率 | +| TiKV | data-block-cache-hit | tikv_block_data_cache_hit | 大于 0.80 | TiKV 中 data block 缓存的命中率 | +| TiKV | leader-score-balance | pd_scheduler_store_status | 小于 0.05 | 检测各个 TiKV 节点的 leader score 是否均衡，期望节点间的差异小于 5% | +| TiKV | region-score-balance | pd_scheduler_store_status | 小于 0.05 | 检测各个 TiKV 节点的 region score 是否均衡，期望节点间的差异小于 5% | +| TiKV | store-available-balance | pd_scheduler_store_status | 小于 0.2 | 检测各个 TiKV 节点的存储可用空间大小是否均衡，期望节点间的差异小于 20% | +| TiKV | region-count | pd_scheduler_store_status | 小于 20000 | 检测各个 TiKV 节点的 region 数量，期望单个节点的 region 数量小于 20000 | +| PD | region-health | pd_region_health | 小于 100 | 检测集群中处于调度中间状态的 region 数量，期望总数小于 100 | + +另外还会检测 TiKV 节点的以下 thread cpu usage 是否过高: + +* scheduler-worker-cpu +* coprocessor-normal-cpu +* coprocessor-high-cpu +* coprocessor-low-cpu +* grpc-cpu +* raftstore-cpu +* apply-cpu +* storage-readpool-normal-cpu +* storage-readpool-high-cpu +* storage-readpool-low-cpu +* split-check-cpu + +## 最后 + +TiDB 内置的诊断规则还在不断的完善改进中，如果你也想到了一些诊断规则，非常欢迎给 TiDB 提 PR 或 ISSUE。 \ No newline at end of file diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection_summary.md index 9d1539603b69..46a6a930dcd7 100644 --- a/reference/system-databases/inspection_summary.md +++ b/reference/system-databases/inspection_summary.md @@ -28,7 +28,6 @@ mysql> desc inspection_summary; | MIN_VALUE | double(22,6) unsigned | YES | | NULL | | | MAX_VALUE | double(22,6) unsigned | YES | | NULL | | +--------------+-----------------------+------+------+---------+-------+ -8 rows in set (0.00 sec) ``` 字段解释： diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index af91b0efc66d..abee03613907 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -51,7 +51,6 @@ desc metrics_schema.tikv_admin_apply; | status | varchar(512) | YES | | NULL | | | value | double unsigned | YES | | NULL | | +----------+-------------------+------+------+---------+-------+ -5 rows in set (0.00 sec) ``` 下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，`Select` Query 类型的 P90 耗时是 0.0384 秒，`internal` 类型的 P90 耗时是 0.00327。`instance` 字段是 TiDB 示例的地址。 diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index 21ce9765805c..fd93baa62edf 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -30,7 +30,6 @@ mysql> desc metrics_summary; | MAX_VALUE | double(22,6) unsigned | YES | | NULL | | | COMMENT | varchar(256) | YES | | NULL | | +--------------+-----------------------+------+------+---------+-------+ -7 rows in set (0.00 sec) ``` 字段解释： diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics_tables.md index eddf2c279614..66613e1039a5 100644 --- a/reference/system-databases/metrics_tables.md +++ b/reference/system-databases/metrics_tables.md @@ -23,7 +23,6 @@ desc metrics_tables; | QUANTILE | double unsigned | YES | | NULL | | | COMMENT | varchar(256) | YES | | NULL | | +------------+-----------------+------+------+---------+-------+ -5 rows in set (0.00 sec) ``` 表 `metrics_tables` 的字段解释： From a9224d89dc8a09d92c14dcf0a495ef3139fec224 Mon Sep 17 00:00:00 2001 From: crazycs Date: Fri, 27 Mar 2020 21:13:59 +0800 Subject: [PATCH 31/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: Lilian Lee --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index f56e9a21fc95..ea888f5979a5 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -3,7 +3,7 @@ title: SQL DIAGNOSIS category: reference --- -# SQL DIAGNOSIS +# SQL 诊断 SQL 诊断功能是在 TiDB 4.0 版本中引入的特性，用于提升 TiDB 问题定位的效率。TiDB 4.0 版本以前，用户需要使用不同工具获取以异构的方式获取不同信息。 新的 SQL 诊断系统对这些离散的信息进行了整体设计，它整合系统各个维度的信息，通过系统表的方式向上层提供一致的接口，提供监控汇总与自动诊断，方便用户查询集群信息。 From 2130a4e41596bb172860ffc6365745fb8c32b4cc Mon Sep 17 00:00:00 2001 From: crazycs Date: Fri, 27 Mar 2020 21:14:10 +0800 Subject: [PATCH 32/43] Update reference/system-databases/sql-dignosis.md Co-Authored-By: Lilian Lee --- reference/system-databases/sql-dignosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index ea888f5979a5..0c40d72aa214 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -1,5 +1,5 @@ --- -title: SQL DIAGNOSIS +title: SQL 诊断 category: reference --- From 452ef158eb015aa66fac2b38305600d29e9cf308 Mon Sep 17 00:00:00 2001 From: guoni Date: Tue, 31 Mar 2020 10:52:15 +0800 Subject: [PATCH 33/43] add sys tables to TOC --- TOC.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/TOC.md b/TOC.md index 5a5dc5e36362..88f55daf558f 100644 --- a/TOC.md +++ b/TOC.md @@ -248,6 +248,18 @@ + 系统数据库 - [`mysql`](/reference/system-databases/mysql.md) - [`information_schema`](/reference/system-databases/information-schema.md) + + [`sql-diagnosis`](/reference/system-databases/sql-diagnosis.md) + -[`cluster_info`](/reference/system-databases/cluster_info.md) + -[`cluster_hardware`](/reference/system-databases/cluster_hardware.md) + -[`cluster_config`](/reference/system-databases/cluster_config.md) + -[`cluster_load`](/reference/system-databases/cluster_load.md) + -[`cluster_systeminfo`](/reference/system-databases/cluster_systeminfo.md) + -[`cluster_log`](/reference/system-databases/cluster_log.md) + -[`metrics_schema`](/reference/system-databases/metrics_schema.md) + -[`metrics_tables`](/reference/system-databases/metrics_tables.md) + -[`metrics_summary`](/reference/system-databases/metrics_summary.md) + -[`inspection_result`](/reference/system-databases/inspection_result.md) + -[`inspection_summary`](/reference/system-databases/inspection_summary.md) - [错误码](/reference/error-codes.md) - [支持的连接器和 API](/reference/supported-clients.md) + 垃圾回收 (GC) From b0862bee814e76f8237a2e1651c05eb3ce8b2f26 Mon Sep 17 00:00:00 2001 From: guoni Date: Tue, 31 Mar 2020 12:04:54 +0800 Subject: [PATCH 34/43] fix lint --- TOC.md | 2 +- .../system-databases/{sql-dignosis.md => sql-diagnosis.md} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename reference/system-databases/{sql-dignosis.md => sql-diagnosis.md} (100%) diff --git a/TOC.md b/TOC.md index 88f55daf558f..56f0a7b2b84e 100644 --- a/TOC.md +++ b/TOC.md @@ -255,7 +255,7 @@ -[`cluster_load`](/reference/system-databases/cluster_load.md) -[`cluster_systeminfo`](/reference/system-databases/cluster_systeminfo.md) -[`cluster_log`](/reference/system-databases/cluster_log.md) - -[`metrics_schema`](/reference/system-databases/metrics_schema.md) + -[`metrics_schema`](/reference/system-databases/metrics-schema.md) -[`metrics_tables`](/reference/system-databases/metrics_tables.md) -[`metrics_summary`](/reference/system-databases/metrics_summary.md) -[`inspection_result`](/reference/system-databases/inspection_result.md) diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-diagnosis.md similarity index 100% rename from reference/system-databases/sql-dignosis.md rename to reference/system-databases/sql-diagnosis.md From bef374e1cafb81586c159946d314ea81815ca293 Mon Sep 17 00:00:00 2001 From: crazycs Date: Wed, 1 Apr 2020 12:11:57 +0800 Subject: [PATCH 35/43] Update reference/system-databases/sql-diagnosis.md Co-Authored-By: TomShawn <41534398+TomShawn@users.noreply.github.com> --- reference/system-databases/sql-diagnosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reference/system-databases/sql-diagnosis.md b/reference/system-databases/sql-diagnosis.md index 0c40d72aa214..06e98f1e59b8 100644 --- a/reference/system-databases/sql-diagnosis.md +++ b/reference/system-databases/sql-diagnosis.md @@ -33,7 +33,7 @@ TiDB 4.0 之前的系统表，只能查看当前节点，TiDB 4.0 实现了对 为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有监控表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控信息。SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 -* `information_schema.metrics_tables`：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 +* [`information_schema.metrics_tables`](/reference/system-databases/metrics_tables.md)：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供以下监控汇总表： From 45b1d8e8eb6ab0a9980835722cd4c3bb179a67fe Mon Sep 17 00:00:00 2001 From: crazycs520 Date: Wed, 1 Apr 2020 13:27:58 +0800 Subject: [PATCH 36/43] update metrics_schema docs Signed-off-by: crazycs520 --- .../SELECT GREATEST(t1.avg_value,.sql | 15 ++ reference/system-databases/metrics-schema.md | 156 ++++++++++++++---- reference/system-databases/metrics_summary.md | 123 ++++---------- 3 files changed, 174 insertions(+), 120 deletions(-) create mode 100644 reference/system-databases/SELECT GREATEST(t1.avg_value,.sql diff --git a/reference/system-databases/SELECT GREATEST(t1.avg_value,.sql b/reference/system-databases/SELECT GREATEST(t1.avg_value,.sql new file mode 100644 index 000000000000..afd30b52e3e4 --- /dev/null +++ b/reference/system-databases/SELECT GREATEST(t1.avg_value,.sql @@ -0,0 +1,15 @@ +SELECT GREATEST(t1.avg_value, + t2.avg_value)/LEAST(t1.avg_value, + t2.avg_value) AS ratio, + t1.metrics_name, + t1.avg_value as t1_avg_value, + t2.avg_value as t2_avg_value, + t2.comment +FROM + (SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ * + FROM information_schema.metrics_summary ) t1 +JOIN + (SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ * + FROM information_schema.metrics_summary ) t2 + ON t1.metrics_name = t2.metrics_name +ORDER BY ratio DESC limit 10; \ No newline at end of file diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index abee03613907..a28ec0ca0e06 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -5,18 +5,41 @@ category: reference # Metrics Schema -为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控。SQL 查询监控的优点在于用户可以对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。由于目前添加的系统表数量较多，用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 +为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控。实际上，SQL 诊断，以及 `metrics_summary`，`metrics_summary_by_label`，`inspection_result` 这三个监控相关的汇总表数据都是通过查询 `metrics_schema` 库中的各种监控表来获取信息的。 +。目前添加的系统表数量较多，用户可以通过 `information_schema.metrics_tables` 查询这些表的相关信息。 -## `tidb_query_duration` 表 +## 概览 -系统表数量较多，这里挑出比较典型的 `tidb_query_duration` 表来作为示例。 +下面以 `tidb_query_duration` 表来作为示例介绍监控表相关的使用和原理，其他的监控表原理都是类似的。 -`tidb_query_duration` 的表结构如下。从表的 `COMMENT` 中可以看出，这个表的是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。 +先查询 `information_schema.metrics_tables` 中关于 `tidb_query_duration` 表相关的信息： {{< copyable "sql" >}} ```sql -show create table tidb_query_duration; +select * from information_schema.metrics_tables where table_name='tidb_query_duration'; +``` + +``` ++---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+----------+----------------------------------------------+ +| TABLE_NAME | PROMQL | LABELS | QUANTILE | COMMENT | ++---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+----------+----------------------------------------------+ +| tidb_query_duration | histogram_quantile($QUANTILE, sum(rate(tidb_server_handle_query_duration_seconds_bucket{$LABEL_CONDITIONS}[$RANGE_DURATION])) by (le,sql_type,instance)) | instance,sql_type | 0.9 | The quantile of TiDB query durations(second) | ++---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+----------+----------------------------------------------+ +``` + +* `TABLE_NAME`：对应于 `metrics_schema` 中的表名，这里表名是 `tidb_query_duration`。 +* `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL`，并将 Prometheus 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `LABELS`：监控定义的 label，`tidb_query_duration` 有 2 个 label，分别是 `instance` 和 `sql_type`。 +* `QUANTILE`：百分位。对于直方图类型的监控数据，指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。`tidb_query_duration` 默认查询 0.9 ，也就是 P90 的监控值。 +* `COMMENT`：对这个监控表的解释。可以看出 `tidb_query_duration` 表的是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。 + +再来看 `tidb_query_duration` 的表结构： + +{{< copyable "sql" >}} + +```sql +show create table metrics_schema.tidb_query_duration; ``` ``` @@ -24,53 +47,130 @@ show create table tidb_query_duration; | Table | Create Table | +---------------------+--------------------------------------------------------------------------------------------------------------------+ | tidb_query_duration | CREATE TABLE `tidb_query_duration` ( | -| | `time` datetime unsigned DEFAULT NULL, | +| | `time` datetime unsigned DEFAULT CURRENT_TIMESTAMP, | | | `instance` varchar(512) DEFAULT NULL, | | | `sql_type` varchar(512) DEFAULT NULL, | -| | `quantile` double unsigned DEFAULT NULL, | +| | `quantile` double unsigned DEFAULT '0.9', | | | `value` double unsigned DEFAULT NULL | | | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='The quantile of TiDB query durations(second)' | +---------------------+--------------------------------------------------------------------------------------------------------------------+ ``` -比如 `tikv_admin_apply` 有三个 label，对应的表也会有三个额外的列。 +* `time`：监控项的时间。 +* `instance` 和 `sql_type`：是 `tidb_query_duration` 这个监控项的 label。`instance` 表示监控的地址，`sql_type` 表示执行 SQL 的类似。 +* `quantile`，百分位，直方图类型的监控都会有该列，表示查询的百分位时间，如 `quantile=0.9` 就是查询 P90 的时间。 +* `value`：监控项的值。 + +下面是查询时间 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 范围内的 P99 的 TiDB Query 耗时： {{< copyable "sql" >}} ```sql -desc metrics_schema.tikv_admin_apply; +select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; ``` ``` -+----------+-------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+----------+-------------------+------+------+---------+-------+ -| time | datetime unsigned | YES | | NULL | | -| instance | varchar(512) | YES | | NULL | | -| type | varchar(512) | YES | | NULL | | -| status | varchar(512) | YES | | NULL | | -| value | double unsigned | YES | | NULL | | -+----------+-------------------+------+------+---------+-------+ ++---------------------+-------------------+----------+----------+----------------+ +| time | instance | sql_type | quantile | value | ++---------------------+-------------------+----------+----------+----------------+ +| 2020-03-25 23:40:00 | 172.16.5.40:10089 | Insert | 0.99 | 0.509929485256 | +| 2020-03-25 23:41:00 | 172.16.5.40:10089 | Insert | 0.99 | 0.494690793986 | +| 2020-03-25 23:42:00 | 172.16.5.40:10089 | Insert | 0.99 | 0.493460506934 | +| 2020-03-25 23:40:00 | 172.16.5.40:10089 | Select | 0.99 | 0.152058493415 | +| 2020-03-25 23:41:00 | 172.16.5.40:10089 | Select | 0.99 | 0.152193879678 | +| 2020-03-25 23:42:00 | 172.16.5.40:10089 | Select | 0.99 | 0.140498483232 | +| 2020-03-25 23:40:00 | 172.16.5.40:10089 | internal | 0.99 | 0.47104 | +| 2020-03-25 23:41:00 | 172.16.5.40:10089 | internal | 0.99 | 0.11776 | +| 2020-03-25 23:42:00 | 172.16.5.40:10089 | internal | 0.99 | 0.11776 | ++---------------------+-------------------+----------+----------+----------------+ ``` -下面是查询当前时间的 P90 的 TiDB Query 耗时，可以看出，`Select` Query 类型的 P90 耗时是 0.0384 秒，`internal` 类型的 P90 耗时是 0.00327。`instance` 字段是 TiDB 示例的地址。 +以上查询结果的第一行意思是，在 2020-03-25 23:40:00 时，在TiDB 实例 172.16.5.40:10089 上，`Insert` 类型的语句的 P99 执行时间是 0.509929485256 秒。其他各行的含义类似，`sql_type` 列的其他值含义如下： + +* `Select`：表示执行的 `select` 类型的语句。 +* `internal`：表示 TiDB 的内部 SQL 语句，一般是统计信息更新，获取全局变量相关的内部语句。 + +进一步再查看上面语句的执行计划如下： {{< copyable "sql" >}} ```sql -metrics_schema> select * from tidb_query_duration where value is not null and time=now() and quantile=0.90; +desc select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; ``` ``` -+---------------------+-------------------+----------+----------+------------------+ -| time | instance | sql_type | quantile | value | -+---------------------+-------------------+----------+----------+------------------+ -| 2020-03-08 13:34:40 | 172.16.5.40:10089 | Select | 0.9 | 0.0384 | -| 2020-03-08 13:34:40 | 172.16.5.40:10089 | internal | 0.9 | 0.00327692307692 | -+---------------------+-------------------+----------+----------+------------------+ ++------------------+----------+------+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| id | estRows | task | access object | operator info | ++------------------+----------+------+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Selection_5 | 8000.00 | root | | not(isnull(Column#5)) | +| └─MemTableScan_6 | 10000.00 | root | table:tidb_query_duration | PromQL:histogram_quantile(0.99, sum(rate(tidb_server_handle_query_duration_seconds_bucket{}[60s])) by (le,sql_type,instance)), start_time:2020-03-25 23:40:00, end_time:2020-03-25 23:42:00, step:1m0s | ++------------------+----------+------+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` -监控表 session 变量： +可以发现执行计划中有一个 `PromQL`, 以及查询监控的 `start_time` 和 `end_time`，还有 `step` 值，在实际执行时，TiDB 会调用 Prometheus 的 `query_range` HTTP API 接口来查询监控数据。 + +细心的读者可能已经发现，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有 3 个时间的值，执行计划中的 `step` 值为 1 分钟，这实际上是由下面 2 个 session 变量决定的： * `tidb_metric_query_step`：查询的分辨率步长。从 Prometheus 的 `query_range` 数据时需要指定 `start`，`end` 和 `step`，其中 `step` 会使用该变量的值。 -* `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。 \ No newline at end of file +* `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。 + +如果想要查看不同时间粒度的监控项的值，用户可以修改上面2个 session 变量后查询监控表，示例如下： + +首先修改 2 个 session 变量的值，将时间粒度设置为 30 秒。 + +> 注意 +> Prometheus 支持查询的最小粒度就是 30 秒。 + +{{< copyable "sql" >}} + +```sql +set @@tidb_metric_query_step=30; +set @@tidb_metric_query_range_duration=30; +``` + +再查询 `tidb_query_duration` 监控如下，可以发现在 3 分钟时间范围内，每个 label 有 6 个时间的值，每个值时间间隔是 30 秒。 + +{{< copyable "sql" >}} + +```sql +select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; +``` + +``` ++---------------------+-------------------+----------+----------+-----------------+ +| time | instance | sql_type | quantile | value | ++---------------------+-------------------+----------+----------+-----------------+ +| 2020-03-25 23:40:00 | 172.16.5.40:10089 | Insert | 0.99 | 0.483285651924 | +| 2020-03-25 23:40:30 | 172.16.5.40:10089 | Insert | 0.99 | 0.484151462113 | +| 2020-03-25 23:41:00 | 172.16.5.40:10089 | Insert | 0.99 | 0.504576 | +| 2020-03-25 23:41:30 | 172.16.5.40:10089 | Insert | 0.99 | 0.493577384561 | +| 2020-03-25 23:42:00 | 172.16.5.40:10089 | Insert | 0.99 | 0.49482474311 | +| 2020-03-25 23:40:00 | 172.16.5.40:10089 | Select | 0.99 | 0.189253402185 | +| 2020-03-25 23:40:30 | 172.16.5.40:10089 | Select | 0.99 | 0.184224951851 | +| 2020-03-25 23:41:00 | 172.16.5.40:10089 | Select | 0.99 | 0.151673410553 | +| 2020-03-25 23:41:30 | 172.16.5.40:10089 | Select | 0.99 | 0.127953838989 | +| 2020-03-25 23:42:00 | 172.16.5.40:10089 | Select | 0.99 | 0.127455434547 | +| 2020-03-25 23:40:00 | 172.16.5.40:10089 | internal | 0.99 | 0.0624 | +| 2020-03-25 23:40:30 | 172.16.5.40:10089 | internal | 0.99 | 0.12416 | +| 2020-03-25 23:41:00 | 172.16.5.40:10089 | internal | 0.99 | 0.0304 | +| 2020-03-25 23:41:30 | 172.16.5.40:10089 | internal | 0.99 | 0.06272 | +| 2020-03-25 23:42:00 | 172.16.5.40:10089 | internal | 0.99 | 0.0629333333333 | ++---------------------+-------------------+----------+----------+-----------------+ +``` + +最后查看执行计划，也会发现执行计划中的 `PromQL` 以及 `step` 的值都已经变成了 `30` 秒。 + +{{< copyable "sql" >}} + +```sql +desc select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; +``` + +``` ++------------------+----------+------+---------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| id | estRows | task | access object | operator info | ++------------------+----------+------+---------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| Selection_5 | 8000.00 | root | | not(isnull(Column#5)) | +| └─MemTableScan_6 | 10000.00 | root | table:tidb_query_duration | PromQL:histogram_quantile(0.99, sum(rate(tidb_server_handle_query_duration_seconds_bucket{}[30s])) by (le,sql_type,instance)), start_time:2020-03-25 23:40:00, end_time:2020-03-25 23:42:00, step:30s | ++------------------+----------+------+---------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +``` diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics_summary.md index fd93baa62edf..8c78a762fcbd 100644 --- a/reference/system-databases/metrics_summary.md +++ b/reference/system-databases/metrics_summary.md @@ -138,113 +138,52 @@ COMMENT | The quantile of TiDB query durations(second) * 时间段 t1：`("2020-03-03 17:08:00", "2020-03-03 17:11:00")` * 时间段 t2：`("2020-03-03 17:18:00", "2020-03-03 17:21:00")` -对两个时间段的监控按照 `METRICS_NAME` 进行 join，并按照差值排序。其中 `TIME_RANGE` 是用于指定查询时间的 hint。 - -查询 `t1.avg_value` / `t2.avg_value` 差异最大的 10 个监控项: - -{{< copyable "sql" >}} - -```sql -SELECT - t1.avg_value / t2.avg_value AS ratio, - t1.metrics_name, - t1.avg_value, - t2.avg_value, - t2.comment -FROM - ( - SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * - FROM information_schema.metrics_summary - ) t1 - JOIN - ( - SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * - FROM information_schema.metrics_summary - ) t2 - ON t1.metrics_name = t2.metrics_name -ORDER BY - ratio DESC limit 10; -``` - -``` -+----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ -| ratio | metrics_name | avg_value | avg_value | comment | -+----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ -| 17.6439787379 | tikv_region_average_written_bytes | 30816827.0953 | 1746591.71568 | The average rate of writing bytes to Regions per TiKV instance | -| 8.88407551364 | tikv_region_average_written_keys | 108557.034612 | 12219.283193 | The average rate of written keys to Regions per TiKV instance | -| 6.4105335594 | tidb_kv_write_num | 4493.293654 | 700.923505 | The quantile of kv write times per transaction execution | -| 2.99993333333 | tidb_gc_total_count | 1.0 | 0.333341 | The total count of kv storage garbage collection time durations | -| 2.66412165823 | tikv_engine_avg_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | -| 2.66412165823 | tikv_engine_max_seek_duration | 6569.879007 | 2466.05818 | The time consumed when executing seek operation, the unit is microsecond | -| 2.49994444321 | tikv_region_change | -0.277778 | -0.111114 | The count of region change per TiKV instance | -| 2.16063829787 | etcd_wal_fsync_duration | 0.002539 | 0.001175 | The quantile time consumed of writing WAL into the persistent storage | -| 2.06089264604 | node_memory_free | 4541448192.0 | 2203631616.0 | | -| 1.96749064186 | tidb_kv_write_size | 514489.28 | 261495.159902 | The quantile of kv write size per transaction execution | -+----------------+-----------------------------------+-------------------+-------------------+--------------------------------------------------------------------------+ -``` - -查询结果表示： - -* t1 时间段内的 `tikv_region_average_written_bytes` Region 的平均写入字节数，比 t2 时间段高了 17.6 倍。 -* t1 时间段内的 `tikv_region_average_written_keys` Region 的平均写入 key 数，比 t2 时间段高了 8.8 倍。 -* t1 时间段内的 `tidb_kv_write_size`（tidb 每个事务写入的 kv 大小）比 t2 时间段高了 1.96 倍。 - -通过以上结果可以轻易看出 t1 时间段的写入要比 t2 时间段高。 - -反过来，查询 `t2.avg_value` 和 `t1.avg_value` 差异最大的十个监控项： +对两个时间段的监控按照 `METRICS_NAME` 进行 join，并按照差异值大小排序。其中 `TIME_RANGE` 是用于指定查询时间的 hint。 {{< copyable "sql" >}} ```sql -SELECT - t2.avg_value / t1.avg_value AS ratio, - t1.metrics_name, - t1.avg_value, - t2.avg_value, - t2.comment -FROM - ( - SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ - * - FROM information_schema.metrics_summary - ) t1 - JOIN - ( - SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ - * - FROM information_schema.metrics_summary - ) t2 - ON t1.metrics_name = t2.metrics_name -ORDER BY - ratio DESC limit 10; +SELECT GREATEST(t1.avg_value,t2.avg_value)/LEAST(t1.avg_value, + t2.avg_value) AS ratio, + t1.metrics_name, + t1.avg_value as t1_avg_value, + t2.avg_value as t2_avg_value, + t2.comment +FROM + (SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ * + FROM information_schema.metrics_summary ) t1 +JOIN + (SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ * + FROM information_schema.metrics_summary ) t2 + ON t1.metrics_name = t2.metrics_name +ORDER BY ratio DESC limit 10; ``` ``` -+----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ -| ratio | metrics_name | avg_value | avg_value | comment | -+----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ -| 5865.59537065 | tidb_slow_query_cop_process_total_time | 0.016333 | 95.804724 | The total time of TiDB slow query statistics with slow query total cop process time(second) | -| 3648.74109023 | tidb_distsql_partial_scan_key_total_num | 10865.666667 | 39646004.4394 | The total num of distsql partial scan key numbers | -| 267.002351165 | tidb_slow_query_cop_wait_total_time | 0.003333 | 0.890008 | The total time of TiDB slow query statistics with slow query total cop wait time(second) | -| 192.43267836 | tikv_cop_total_response_total_size | 2515333.66667 | 484032394.445 | | -| 192.43267836 | tikv_cop_total_response_size | 41922.227778 | 8067206.57408 | | -| 152.780296296 | tidb_distsql_scan_key_total_num | 5304.333333 | 810397.618317 | The total num of distsql scan numbers | -| 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) | -| 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | | -| 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | | -| 10``1.635495394 | tikv_cop_total_kv_cursor_operations | 1070.875 | 108838.91113 | | -+----------------+-----------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ ++----------------+------------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +| ratio | metrics_name | t1_avg_value | t2_avg_value | comment | ++----------------+------------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ +| 5865.59537065 | tidb_slow_query_cop_process_total_time | 0.016333 | 95.804724 | The total time of TiDB slow query statistics with slow query total cop process time(second) | +| 3648.74109023 | tidb_distsql_partial_scan_key_total_num | 10865.666667 | 39646004.4394 | The total num of distsql partial scan key numbers | +| 267.002351165 | tidb_slow_query_cop_wait_total_time | 0.003333 | 0.890008 | The total time of TiDB slow query statistics with slow query total cop wait time(second) | +| 192.43267836 | tikv_cop_total_response_total_size | 2515333.66667 | 484032394.445 | | +| 192.43267836 | tikv_cop_total_response_size_per_seconds | 41922.227778 | 8067206.57408 | | +| 152.780296296 | tidb_distsql_scan_key_total_num | 5304.333333 | 810397.618317 | The total num of distsql scan numbers | +| 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) | +| 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | | +| 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | | +| 101.635495394 | tikv_cop_scan_keys_num | 1070.875 | 108838.91113 | | ++----------------+------------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+ ``` 上面查询结果表示： * t2 时间段内的 `tidb_slow_query_cop_process_total_time`（TiDB 慢查询中的 `cop process` 耗时）比 t1 时间段高了 5865 倍。 * t2 时间段内的 `tidb_distsql_partial_scan_key_total_num`（TiDB 的 `distsql` 请求扫描key 的数量）比 t1 时间段高了 3648 倍。 +t2 时间段内，`tidb_slow_query_cop_wait_total_time` (TiDB 慢查询中的 cop 请求排队等待的耗时) 比 t1 时间段高了 267 倍。 * t2 时间段内的 `tikv_cop_total_response_size`（TiKV 的 cop 请求结果的大小 ）比 t1 时间段高了 192 倍。 * t2 时间段内的 `tikv_cop_scan_details`（TiKV 的 cop 请求的 scan ）比 t1 时间段高了 105 倍。 -对比上面两个时间段的查询，可以大致了解集群在这两个时间段的负载情况。t2 时间段的 cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 +综上，我们可以马上知道 t2 时间段的 cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 `cop task` 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。 实际上，在 t1 ~ t2 整个时间段内都在跑 `go-ycsb` 的压测，然后在 t2 时间段跑了 20 个 `tpch` 的查询，所以是因为 `tpch` 大查询导致了出现很多的 cop 请求。 From e8179852c466606e4669f3bf1958ea3ae2fd72c4 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Wed, 1 Apr 2020 16:01:14 +0800 Subject: [PATCH 37/43] add reference links and change file names --- .../{cluster_config.md => cluster-config.md} | 0 ...luster_hardware.md => cluster-hardware.md} | 0 .../{cluster_info.md => cluster-info.md} | 0 .../{cluster_load.md => cluster-load.md} | 0 .../{cluster_log.md => cluster-log.md} | 0 ...er_systeminfo.md => cluster-systeminfo.md} | 0 .../system-databases/information-schema.md | 14 +++++++++++ ...pection_result.md => inspection-result.md} | 0 ...ction_summary.md => inspection-summary.md} | 0 ...{metrics_summary.md => metrics-summary.md} | 0 .../{metrics_tables.md => metrics-tables.md} | 0 reference/system-databases/sql-dignosis.md | 25 +++++++++---------- 12 files changed, 26 insertions(+), 13 deletions(-) rename reference/system-databases/{cluster_config.md => cluster-config.md} (100%) rename reference/system-databases/{cluster_hardware.md => cluster-hardware.md} (100%) rename reference/system-databases/{cluster_info.md => cluster-info.md} (100%) rename reference/system-databases/{cluster_load.md => cluster-load.md} (100%) rename reference/system-databases/{cluster_log.md => cluster-log.md} (100%) rename reference/system-databases/{cluster_systeminfo.md => cluster-systeminfo.md} (100%) rename reference/system-databases/{inspection_result.md => inspection-result.md} (100%) rename reference/system-databases/{inspection_summary.md => inspection-summary.md} (100%) rename reference/system-databases/{metrics_summary.md => metrics-summary.md} (100%) rename reference/system-databases/{metrics_tables.md => metrics-tables.md} (100%) diff --git a/reference/system-databases/cluster_config.md b/reference/system-databases/cluster-config.md similarity index 100% rename from reference/system-databases/cluster_config.md rename to reference/system-databases/cluster-config.md diff --git a/reference/system-databases/cluster_hardware.md b/reference/system-databases/cluster-hardware.md similarity index 100% rename from reference/system-databases/cluster_hardware.md rename to reference/system-databases/cluster-hardware.md diff --git a/reference/system-databases/cluster_info.md b/reference/system-databases/cluster-info.md similarity index 100% rename from reference/system-databases/cluster_info.md rename to reference/system-databases/cluster-info.md diff --git a/reference/system-databases/cluster_load.md b/reference/system-databases/cluster-load.md similarity index 100% rename from reference/system-databases/cluster_load.md rename to reference/system-databases/cluster-load.md diff --git a/reference/system-databases/cluster_log.md b/reference/system-databases/cluster-log.md similarity index 100% rename from reference/system-databases/cluster_log.md rename to reference/system-databases/cluster-log.md diff --git a/reference/system-databases/cluster_systeminfo.md b/reference/system-databases/cluster-systeminfo.md similarity index 100% rename from reference/system-databases/cluster_systeminfo.md rename to reference/system-databases/cluster-systeminfo.md diff --git a/reference/system-databases/information-schema.md b/reference/system-databases/information-schema.md index 2b8b875774c3..43b7a21bc203 100644 --- a/reference/system-databases/information-schema.md +++ b/reference/system-databases/information-schema.md @@ -744,6 +744,20 @@ COLLATION_CONNECTION: utf8_general_ci 1 row in set (0.00 sec) ``` +## SQL 诊断相关的表 + +* [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) +* [`information_schema.cluster_config`](/reference/system-databases/cluster-config.md) +* [`information_schema.cluster_hardware`](/reference/system-databases/cluster-hardware.md) +* [`information_schema.cluster_load`](/reference/system-databases/cluster-load.md) +* [`information_schema.cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md) +* [`information_schema.cluster_log`](/reference/system-databases/cluster-log.md) +* [`information_schema.metrics_tables`](/reference/system-databases/metrics-tables.md) +* [`information_schema.metrics_summary`](/reference/system-databases/metrics-summary.md) +* [`information_schema.metrics_summary_by_label`](/reference/system-databases/metrics-summary.md) +* [`information_schema.inspection_result`](/reference/system-databases/inspection-result.md) +* [`information_schema.inspection_summary`](/reference/system-databases/inspection-summary.md) + ## 不支持的 Information Schema 表 TiDB 包含以下 `INFORMATION_SCHEMA` 表，但仅会返回空行： diff --git a/reference/system-databases/inspection_result.md b/reference/system-databases/inspection-result.md similarity index 100% rename from reference/system-databases/inspection_result.md rename to reference/system-databases/inspection-result.md diff --git a/reference/system-databases/inspection_summary.md b/reference/system-databases/inspection-summary.md similarity index 100% rename from reference/system-databases/inspection_summary.md rename to reference/system-databases/inspection-summary.md diff --git a/reference/system-databases/metrics_summary.md b/reference/system-databases/metrics-summary.md similarity index 100% rename from reference/system-databases/metrics_summary.md rename to reference/system-databases/metrics-summary.md diff --git a/reference/system-databases/metrics_tables.md b/reference/system-databases/metrics-tables.md similarity index 100% rename from reference/system-databases/metrics_tables.md rename to reference/system-databases/metrics-tables.md diff --git a/reference/system-databases/sql-dignosis.md b/reference/system-databases/sql-dignosis.md index f56e9a21fc95..149618a9107f 100644 --- a/reference/system-databases/sql-dignosis.md +++ b/reference/system-databases/sql-dignosis.md @@ -19,30 +19,29 @@ SQL 诊断共分三大块： 集群信息表将一个集群中的所有节点实例的信息都汇聚在一起，让用户仅通过一条 SQL 就能查询整个集群相关信息。 集群信息表列表如下： -* 集群拓扑表 `information_schema.cluster_info` 用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、各节点的启动时间、各节点的运行时间。 -* 集群配置表 `information_schema.cluster_config` 用于获取集群当前所有节点的配置。对于 TiDB 4.0 之前的版本，用户必须逐个访问各个节点的 HTTP API 才能获取这些配置信息。 -* 集群硬件表 `information_schema.cluster_hardware` 用于快速查询集群硬件信息。 -* 集群负载表 `information_schema.cluster_load` 用于查询集群不同节点以及不同硬件类型的负载信息。 -* 内核参数表 `information_schema.cluster_systeminfo` 用于查询集群不同节点的内核配置信息。目前支持查询 sysctl 的信息。 -* 集群日志表 `information_schema.cluster_log` 用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，性能影响小于等 grep 命令。 +* 集群拓扑表 [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md) 用于获取集群当前的拓扑信息，以及各个节点的版本、版本对应的 Git Hash、各节点的启动时间、各节点的运行时间。 +* 集群配置表 [`information_schema.cluster_config`](/reference/system-databases/cluster-config.md) 用于获取集群当前所有节点的配置。对于 TiDB 4.0 之前的版本，用户必须逐个访问各个节点的 HTTP API 才能获取这些配置信息。 +* 集群硬件表 [`information_schema.cluster_hardware`](/reference/system-databases/cluster-hardware.md) 用于快速查询集群硬件信息。 +* 集群负载表 [`information_schema.cluster_load`](/reference/system-databases/cluster-load.md) 用于查询集群不同节点以及不同硬件类型的负载信息。 +* 内核参数表 [`information_schema.cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md) 用于查询集群不同节点的内核配置信息。目前支持查询 sysctl 的信息。 +* 集群日志表 [`information_schema.cluster_log`](/reference/system-databases/cluster-log.md) 用于集群日志查询，通过将查询条件下推到各个节点，降低日志查询对集群的影响，性能影响小于等 grep 命令。 -TiDB 4.0 之前的系统表，只能查看当前节点，TiDB 4.0 实现了对应的集群表，可以在单个 TiDB 节点上拥有整个集群的全局视图。 -这些表目前都位于 `information_schema` 中，查询方式与其他 `information_schema` 系统表一致。 +TiDB 4.0 之前的系统表，只能查看当前节点，TiDB 4.0 实现了对应的集群表，可以在单个 TiDB 节点上拥有整个集群的全局视图。这些表目前都位于 [`information_schema`](/reference/system-databases/information-schema.md) 中，查询方式与其他 `information_schema` 系统表一致。 ## 集群监控表 为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有监控表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控信息。SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 -* `information_schema.metrics_tables`：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 +* [`information_schema.metrics_tables`](/reference/system-databases/metrics-tables.md)：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供以下监控汇总表： -* 监控汇总表 `information_schema.metrics_summary` 用于汇总所有监控数据，以提升用户排查各监控指标的效率。 -* 监控汇总表 `information_schema.metrics_summary_by_label` 同样用于汇总所有监控数据，不过该表会对不同的 label 进行区分统计。 +* 监控汇总表 [`information_schema.metrics_summary`](/reference/system-databases/metrics-summary.md) 用于汇总所有监控数据，以提升用户排查各监控指标的效率。 +* 监控汇总表 [`information_schema.metrics_summary_by_label`](/reference/system-databases/metrics-summary.md) 同样用于汇总所有监控数据，不过该表会对不同的 label 进行区分统计。 ## 自动诊断 以上集群信息表和集群监控表均需要用户手动执行固定模式的 SQL 语句来排查集群问题。为了进一步优化用户体验，TiDB 根据已有的基础信息表，提供诊断相关的系统表，使诊断自动执行。自动诊断相关的系统表如下： -* 诊断结果表 `information_schema.inspection_result` 用于展示对系统的诊断结果。诊断是惰性触发，使用 `select * from inspection_result` 会触发所有诊断规则对系统进行诊断，并在结果中展示系统中的故障或风险。 -* 诊断汇总表 `information_schema.inspection_summary` 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 +* 诊断结果表 [`information_schema.inspection_result`](/reference/system-databases/inspection-result.md) 用于展示对系统的诊断结果。诊断是惰性触发，使用 `select * from inspection_result` 会触发所有诊断规则对系统进行诊断，并在结果中展示系统中的故障或风险。 +* 诊断汇总表 [`information_schema.inspection_summary`](/reference/system-databases/inspection-summary.md) 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 From f46db3281f0ae57c2864bf13728526ecffd09d03 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Wed, 1 Apr 2020 17:01:02 +0800 Subject: [PATCH 38/43] fix dead links --- TOC.md | 20 ++++++++++---------- reference/system-databases/sql-diagnosis.md | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/TOC.md b/TOC.md index 56f0a7b2b84e..ead3c1eefa96 100644 --- a/TOC.md +++ b/TOC.md @@ -249,17 +249,17 @@ - [`mysql`](/reference/system-databases/mysql.md) - [`information_schema`](/reference/system-databases/information-schema.md) + [`sql-diagnosis`](/reference/system-databases/sql-diagnosis.md) - -[`cluster_info`](/reference/system-databases/cluster_info.md) - -[`cluster_hardware`](/reference/system-databases/cluster_hardware.md) - -[`cluster_config`](/reference/system-databases/cluster_config.md) - -[`cluster_load`](/reference/system-databases/cluster_load.md) - -[`cluster_systeminfo`](/reference/system-databases/cluster_systeminfo.md) - -[`cluster_log`](/reference/system-databases/cluster_log.md) + -[`cluster_info`](/reference/system-databases/cluster-info.md) + -[`cluster_hardware`](/reference/system-databases/cluster-hardware.md) + -[`cluster_config`](/reference/system-databases/cluster-config.md) + -[`cluster_load`](/reference/system-databases/cluster-load.md) + -[`cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md) + -[`cluster_log`](/reference/system-databases/cluster-log.md) -[`metrics_schema`](/reference/system-databases/metrics-schema.md) - -[`metrics_tables`](/reference/system-databases/metrics_tables.md) - -[`metrics_summary`](/reference/system-databases/metrics_summary.md) - -[`inspection_result`](/reference/system-databases/inspection_result.md) - -[`inspection_summary`](/reference/system-databases/inspection_summary.md) + -[`metrics_tables`](/reference/system-databases/metrics-tables.md) + -[`metrics_summary`](/reference/system-databases/metrics-summary.md) + -[`inspection_result`](/reference/system-databases/inspection-result.md) + -[`inspection_summary`](/reference/system-databases/inspection-summary.md) - [错误码](/reference/error-codes.md) - [支持的连接器和 API](/reference/supported-clients.md) + 垃圾回收 (GC) diff --git a/reference/system-databases/sql-diagnosis.md b/reference/system-databases/sql-diagnosis.md index ec9b14e9cbb4..a7e176dabb4d 100644 --- a/reference/system-databases/sql-diagnosis.md +++ b/reference/system-databases/sql-diagnosis.md @@ -32,7 +32,7 @@ TiDB 4.0 之前的系统表，只能查看当前节点，TiDB 4.0 实现了对 为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有监控表都在 `metrics_schema` 中，可以通过 SQL 的方式查询监控信息。SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。 -* [`information_schema.metrics_tables`](/reference/system-databases/metrics_tables.md)：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 +* [`information_schema.metrics_tables`](/reference/system-databases/metrics-tables.md)：由于目前添加的系统表数量较多，因此用户可以通过该表查询这些监控表的相关元信息。 由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供以下监控汇总表： From 5f30f5259382c1cb76a4ea2ae8e54a70e0f8e563 Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Fri, 3 Apr 2020 11:34:53 +0800 Subject: [PATCH 39/43] Update reference/system-databases/cluster-config.md Co-Authored-By: Lilian Lee --- reference/system-databases/cluster-config.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/reference/system-databases/cluster-config.md b/reference/system-databases/cluster-config.md index 21593ce5b84b..286645d068b5 100644 --- a/reference/system-databases/cluster-config.md +++ b/reference/system-databases/cluster-config.md @@ -1,6 +1,7 @@ --- title: CLUSTER_CONFIG category: reference +summary: 了解 TiDB 集群配置表 `CLUSTER_CONFIG`。 --- # CLUSTER_CONFIG @@ -50,4 +51,4 @@ select * from cluster_config where type='tikv' and `key` like 'coprocessor%'; | tikv | 127.0.0.1:20160 | coprocessor.region-split-size | 96MiB | | tikv | 127.0.0.1:20160 | coprocessor.split-region-on-table | false | +------+-----------------+-----------------------------------+----------+ -``` \ No newline at end of file +``` From ccb0a64defdcbbe96fc054b389fab4bd452af37a Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Fri, 3 Apr 2020 11:35:12 +0800 Subject: [PATCH 40/43] Update TOC.md Co-Authored-By: Lilian Lee --- TOC.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/TOC.md b/TOC.md index ead3c1eefa96..206f9dce69c3 100644 --- a/TOC.md +++ b/TOC.md @@ -249,17 +249,17 @@ - [`mysql`](/reference/system-databases/mysql.md) - [`information_schema`](/reference/system-databases/information-schema.md) + [`sql-diagnosis`](/reference/system-databases/sql-diagnosis.md) - -[`cluster_info`](/reference/system-databases/cluster-info.md) - -[`cluster_hardware`](/reference/system-databases/cluster-hardware.md) - -[`cluster_config`](/reference/system-databases/cluster-config.md) - -[`cluster_load`](/reference/system-databases/cluster-load.md) - -[`cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md) - -[`cluster_log`](/reference/system-databases/cluster-log.md) - -[`metrics_schema`](/reference/system-databases/metrics-schema.md) - -[`metrics_tables`](/reference/system-databases/metrics-tables.md) - -[`metrics_summary`](/reference/system-databases/metrics-summary.md) - -[`inspection_result`](/reference/system-databases/inspection-result.md) - -[`inspection_summary`](/reference/system-databases/inspection-summary.md) + - [`cluster_info`](/reference/system-databases/cluster-info.md) + - [`cluster_hardware`](/reference/system-databases/cluster-hardware.md) + - [`cluster_config`](/reference/system-databases/cluster-config.md) + - [`cluster_load`](/reference/system-databases/cluster-load.md) + - [`cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md) + - [`cluster_log`](/reference/system-databases/cluster-log.md) + - [`metrics_schema`](/reference/system-databases/metrics-schema.md) + - [`metrics_tables`](/reference/system-databases/metrics-tables.md) + - [`metrics_summary`](/reference/system-databases/metrics-summary.md) + - [`inspection_result`](/reference/system-databases/inspection-result.md) + - [`inspection_summary`](/reference/system-databases/inspection-summary.md) - [错误码](/reference/error-codes.md) - [支持的连接器和 API](/reference/supported-clients.md) + 垃圾回收 (GC) From 2f0a3c91843ae40b9c225b25179f8383e93cc96b Mon Sep 17 00:00:00 2001 From: reafans <30926443+reafans@users.noreply.github.com> Date: Fri, 3 Apr 2020 11:36:05 +0800 Subject: [PATCH 41/43] Delete SELECT GREATEST(t1.avg_value,.sql --- .../SELECT GREATEST(t1.avg_value,.sql | 15 --------------- 1 file changed, 15 deletions(-) delete mode 100644 reference/system-databases/SELECT GREATEST(t1.avg_value,.sql diff --git a/reference/system-databases/SELECT GREATEST(t1.avg_value,.sql b/reference/system-databases/SELECT GREATEST(t1.avg_value,.sql deleted file mode 100644 index afd30b52e3e4..000000000000 --- a/reference/system-databases/SELECT GREATEST(t1.avg_value,.sql +++ /dev/null @@ -1,15 +0,0 @@ -SELECT GREATEST(t1.avg_value, - t2.avg_value)/LEAST(t1.avg_value, - t2.avg_value) AS ratio, - t1.metrics_name, - t1.avg_value as t1_avg_value, - t2.avg_value as t2_avg_value, - t2.comment -FROM - (SELECT /*+ time_range("2020-03-03 17:08:00", "2020-03-03 17:11:00")*/ * - FROM information_schema.metrics_summary ) t1 -JOIN - (SELECT /*+ time_range("2020-03-03 17:18:00", "2020-03-03 17:21:00")*/ * - FROM information_schema.metrics_summary ) t2 - ON t1.metrics_name = t2.metrics_name -ORDER BY ratio DESC limit 10; \ No newline at end of file From 0ac939b8c2236cc5a2823cb06602993fc96d933d Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Fri, 3 Apr 2020 11:45:35 +0800 Subject: [PATCH 42/43] reference: add summaries for newly added docs --- reference/system-databases/cluster-hardware.md | 1 + reference/system-databases/cluster-info.md | 1 + reference/system-databases/cluster-load.md | 1 + reference/system-databases/cluster-log.md | 1 + reference/system-databases/cluster-systeminfo.md | 1 + reference/system-databases/inspection-result.md | 1 + reference/system-databases/inspection-summary.md | 1 + reference/system-databases/metrics-schema.md | 1 + reference/system-databases/metrics-summary.md | 1 + reference/system-databases/metrics-tables.md | 1 + reference/system-databases/sql-diagnosis.md | 1 + 11 files changed, 11 insertions(+) diff --git a/reference/system-databases/cluster-hardware.md b/reference/system-databases/cluster-hardware.md index 3950bfbb9f7f..aefe09b6200b 100644 --- a/reference/system-databases/cluster-hardware.md +++ b/reference/system-databases/cluster-hardware.md @@ -1,5 +1,6 @@ --- title: CLUSTER_HARDWARE +summary: 了解 TiDB 集群配置表 `CLUSTER_HARDWARE`。 category: reference --- diff --git a/reference/system-databases/cluster-info.md b/reference/system-databases/cluster-info.md index 634d9d22cc75..ba74408f07bd 100644 --- a/reference/system-databases/cluster-info.md +++ b/reference/system-databases/cluster-info.md @@ -1,5 +1,6 @@ --- title: CLUSTER_INFO +summary: 了解 TiDB 集群配置表 `CLUSTER_INFO`。 category: reference --- diff --git a/reference/system-databases/cluster-load.md b/reference/system-databases/cluster-load.md index 9fd24a51ab9c..57c2e0e2fc1d 100644 --- a/reference/system-databases/cluster-load.md +++ b/reference/system-databases/cluster-load.md @@ -1,5 +1,6 @@ --- title: CLUSTER_LOAD +summary: 了解 TiDB 集群配置表 `CLUSTER_LOAD`。 category: reference --- diff --git a/reference/system-databases/cluster-log.md b/reference/system-databases/cluster-log.md index 0e45664617da..8adbad647bd4 100644 --- a/reference/system-databases/cluster-log.md +++ b/reference/system-databases/cluster-log.md @@ -1,5 +1,6 @@ --- title: CLUSTER_LOG +summary: 了解 TiDB 集群配置表 `CLUSTER_LOG`。 category: reference --- diff --git a/reference/system-databases/cluster-systeminfo.md b/reference/system-databases/cluster-systeminfo.md index 574d361a73f4..ef6c6faeea27 100644 --- a/reference/system-databases/cluster-systeminfo.md +++ b/reference/system-databases/cluster-systeminfo.md @@ -1,5 +1,6 @@ --- title: CLUSTER_SYSTEMINFO +summary: 了解 TiDB 集群配置表 `CLUSTER_SYSTEMINFO`。 category: reference --- diff --git a/reference/system-databases/inspection-result.md b/reference/system-databases/inspection-result.md index 99dc041d7a82..90ac3f5aec2c 100644 --- a/reference/system-databases/inspection-result.md +++ b/reference/system-databases/inspection-result.md @@ -1,5 +1,6 @@ --- title: INSPECTION_RESULT +summary: 了解 TiDB 集群配置表 `INSPECTION_RESULT`。 category: reference --- diff --git a/reference/system-databases/inspection-summary.md b/reference/system-databases/inspection-summary.md index 46a6a930dcd7..be0df9a86016 100644 --- a/reference/system-databases/inspection-summary.md +++ b/reference/system-databases/inspection-summary.md @@ -1,5 +1,6 @@ --- title: INSPECTION_SUMMARY +summary: 了解 TiDB 集群配置表 `INSPECTION_SUMMARY`。 category: reference --- diff --git a/reference/system-databases/metrics-schema.md b/reference/system-databases/metrics-schema.md index a28ec0ca0e06..8adad90a67d0 100644 --- a/reference/system-databases/metrics-schema.md +++ b/reference/system-databases/metrics-schema.md @@ -1,5 +1,6 @@ --- title: Metrics Schema +summary: 了解 TiDB 集群配置表 `METRICS_SCHEMA`。 category: reference --- diff --git a/reference/system-databases/metrics-summary.md b/reference/system-databases/metrics-summary.md index 8c78a762fcbd..f7bd3c35ab33 100644 --- a/reference/system-databases/metrics-summary.md +++ b/reference/system-databases/metrics-summary.md @@ -1,5 +1,6 @@ --- title: METRICS_SUMMARY +summary: 了解 TiDB 集群配置表 `METRICS_SUMMARY`。 category: reference --- diff --git a/reference/system-databases/metrics-tables.md b/reference/system-databases/metrics-tables.md index 66613e1039a5..b157be3ccf9c 100644 --- a/reference/system-databases/metrics-tables.md +++ b/reference/system-databases/metrics-tables.md @@ -1,5 +1,6 @@ --- title: METRICS_TABLES +summary: 了解 TiDB 集群配置表 `METRICS_TABLES`。 category: reference --- diff --git a/reference/system-databases/sql-diagnosis.md b/reference/system-databases/sql-diagnosis.md index a7e176dabb4d..bcfdc6e8f2a1 100644 --- a/reference/system-databases/sql-diagnosis.md +++ b/reference/system-databases/sql-diagnosis.md @@ -1,5 +1,6 @@ --- title: SQL 诊断 +summary: 了解 SQL 诊断功能。 category: reference --- From eac789519826df81db14b25431278081eca22a2a Mon Sep 17 00:00:00 2001 From: lilin90 Date: Fri, 3 Apr 2020 16:38:07 +0800 Subject: [PATCH 43/43] toc: fix a link placement issue --- TOC.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/TOC.md b/TOC.md index 5863936aab67..c1aa740b5aa3 100644 --- a/TOC.md +++ b/TOC.md @@ -220,6 +220,7 @@ - [分区表](/reference/sql/partitioning.md) - [字符集](/reference/sql/character-set.md) - [SQL 模式](/reference/sql/sql-mode.md) + - [SQL 诊断](/reference/system-databases/sql-diagnosis.md) - [视图](/reference/sql/view.md) + 配置 + tidb-server @@ -247,7 +248,7 @@ + 系统数据库 - [`mysql`](/reference/system-databases/mysql.md) - [`information_schema`](/reference/system-databases/information-schema.md) - + [`sql-diagnosis`](/reference/system-databases/sql-diagnosis.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)