reference: add sql diagnosis overview #2172
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TomShawn
added
translation/from-docs-cn
|
LGTM |
lilin90
reviewed
Apr 7, 2020
| @@ -0,0 +1,50 @@ | |||
| --- | |||
| title: SQL Diagnosis | |||
| summary: Understand SQL diagnostics. | |||
There was a problem hiding this comment.
Suggest keeping the wording consistent.
Suggested change
| summary: Understand SQL diagnostics. | |
| summary: Understand SQL diagnosis in TiDB. |
| category: reference | ||
| --- | ||
|
|
||
| # SQL diagnosis |
There was a problem hiding this comment.
Suggested change
| # SQL diagnosis | |
| # SQL Diagnosis |
|
|
||
| # SQL diagnosis | ||
|
|
||
| SQL diagnosis is a feature introduced since TiDB v4.0. You can use this feature to locate problems in TiDB with higher efficiency. Before TiDB v4.0, you need to use different tools to obtain different information. |
There was a problem hiding this comment.
Suggested change
| SQL diagnosis is a feature introduced since TiDB v4.0. You can use this feature to locate problems in TiDB with higher efficiency. Before TiDB v4.0, you need to use different tools to obtain different information. | |
| SQL diagnosis is a feature introduced in TiDB v4.0. You can use this feature to locate problems in TiDB with higher efficiency. Before TiDB v4.0, you need to use different tools to obtain different information. |
|
|
||
| SQL diagnosis is a feature introduced since TiDB v4.0. You can use this feature to locate problems in TiDB with higher efficiency. Before TiDB v4.0, you need to use different tools to obtain different information. | ||
|
|
||
| The SQL diagnosis system integrates information from all components of the system as a whole, provides a consistent interface to the upper layer through system tables, and provides monitoring summaries and automatic diagnosis, which makes it easier for you to query cluster information. |
There was a problem hiding this comment.
One sentence is a bit too long.
Suggested change
| The SQL diagnosis system integrates information from all components of the system as a whole, provides a consistent interface to the upper layer through system tables, and provides monitoring summaries and automatic diagnosis, which makes it easier for you to query cluster information. | |
| The SQL diagnosis system integrates information from all components of the system as a whole, provides a consistent interface to the upper layer through system tables, and provides the monitoring summary and automatic diagnosis. All these make it easier to query cluster information. |
|
|
||
| + **Cluster information table**: The SQL diagnosis system adds cluster information tables that provide a unified way to get the discrete information of each instance and node. This system fully integrates the cluster topology, hardware information, software information, kernel parameters, monitoring, system information, slow queries, statements, and logs of the entire cluster into the table, allowing you to query these information using SQL statements. | ||
|
|
||
| + **Cluster monitoring table**: The SQL diagnosis system adds cluster monitoring tables. All of these tables are in `metrics_schema`, and you can query monitoring information using SQL statements. Compared to the visualized monitoring before v4.0, you can use this SQL-based method to perform correlated queries on all the monitoring information of the entire cluster, and compare the results of different time periods to quickly identify performance bottlenecks. Because the TiDB cluster has many monitoring metrics, the SQL diagnosis system also provides monitoring summary tables, which allows you to more easily find abnormal monitoring items. |
There was a problem hiding this comment.
Suggested change
| + **Cluster monitoring table**: The SQL diagnosis system adds cluster monitoring tables. All of these tables are in `metrics_schema`, and you can query monitoring information using SQL statements. Compared to the visualized monitoring before v4.0, you can use this SQL-based method to perform correlated queries on all the monitoring information of the entire cluster, and compare the results of different time periods to quickly identify performance bottlenecks. Because the TiDB cluster has many monitoring metrics, the SQL diagnosis system also provides monitoring summary tables, which allows you to more easily find abnormal monitoring items. | |
| + **Cluster monitoring table**: The SQL diagnosis system adds cluster monitoring tables. All of these tables are in `metrics_schema`, and you can query monitoring information using SQL statements. Compared to the visualized monitoring before v4.0, you can use this SQL-based method to perform correlated queries on all the monitoring information of the entire cluster, and compare the results of different time periods to quickly identify performance bottlenecks. Because the TiDB cluster has many monitoring metrics, the SQL diagnosis system also provides monitoring summary tables, so you can find abnormal monitoring items more easily. |
| + On the cluster hardware table `information_schema.cluster_hardware`, you can quickly query the cluster hardware information. | ||
| + On the cluster load table `information_schema.cluster_load`, you can query the load information of different nodes and hardware types of the cluster. | ||
| + On the kernel parameter table `information_schema.cluster_systeminfo`, you can query the kernel configuration information of different nodes in the cluster. Currently, TiDB supports querying the sysctl information. | ||
| + On the cluster log table `information_schema.cluster_log`, you can query cluster logs. By pushing the query condition to each node, the impact of the query on cluster performance is less than that of the grep command. |
There was a problem hiding this comment.
Suggested change
| + On the cluster log table `information_schema.cluster_log`, you can query cluster logs. By pushing the query condition to each node, the impact of the query on cluster performance is less than that of the grep command. | |
| + On the cluster log table `information_schema.cluster_log`, you can query cluster logs. By pushing down query conditions to each node, the impact of the query on cluster performance is less than that of the `grep` command. |
| + On the kernel parameter table `information_schema.cluster_systeminfo`, you can query the kernel configuration information of different nodes in the cluster. Currently, TiDB supports querying the sysctl information. | ||
| + On the cluster log table `information_schema.cluster_log`, you can query cluster logs. By pushing the query condition to each node, the impact of the query on cluster performance is less than that of the grep command. | ||
|
|
||
| On the system tables before v4.0, you can only view the current node. TiDB v4.0 adds the corresponding cluster tables and you can have a global view of the entire cluster on a single TiDB node. These tables are currently in `information_schema`, and the query method is the same as other `information_schema` system tables. |
There was a problem hiding this comment.
Suggested change
| On the system tables before v4.0, you can only view the current node. TiDB v4.0 adds the corresponding cluster tables and you can have a global view of the entire cluster on a single TiDB node. These tables are currently in `information_schema`, and the query method is the same as other `information_schema` system tables. | |
| On the system tables earlier than TiDB v4.0, you can only view the current node. TiDB v4.0 adds the corresponding cluster tables and you can have a global view of the entire cluster on a single TiDB node. These tables are currently in `information_schema`, and the query method is the same as other `information_schema` system tables. |
|
|
||
| ## Cluster monitoring tables | ||
|
|
||
| For you to dynamically observe and compare cluster conditions in different time periods, the SQL diagnosis system adds cluster monitoring system tables. All monitoring tables are in `metrics_schema`, and you can query the monitoring information SQL statements. Using this method, you can perform correlated queries on all monitoring information of the entire cluster and compare the results of different time periods to quickly identify performance bottlenecks. |
There was a problem hiding this comment.
Suggested change
| For you to dynamically observe and compare cluster conditions in different time periods, the SQL diagnosis system adds cluster monitoring system tables. All monitoring tables are in `metrics_schema`, and you can query the monitoring information SQL statements. Using this method, you can perform correlated queries on all monitoring information of the entire cluster and compare the results of different time periods to quickly identify performance bottlenecks. | |
| To dynamically observe and compare cluster conditions in different time periods, the SQL diagnosis system introduces cluster monitoring system tables. All monitoring tables are in `metrics_schema`, and you can query the monitoring information SQL statements. Using this method, you can perform correlated queries on all monitoring information of the entire cluster and compare the results of different time periods to quickly identify performance bottlenecks. |
|
|
||
| + `information_schema.metrics_tables`: Because many system tables exist now, you can query meta-information of these monitoring tables on the `information_schema.metrics_tables` table. | ||
|
|
||
| Because the TiDB cluster has many monitoring metrics, TiDB provides the following monitoring summary tables since v4.0: |
There was a problem hiding this comment.
Suggested change
| Because the TiDB cluster has many monitoring metrics, TiDB provides the following monitoring summary tables since v4.0: | |
| Because the TiDB cluster has many monitoring metrics, TiDB provides the following monitoring summary tables in v4.0: |
lilin90
added
the
status/can-merge
|
/run-all-tests |
|
cherry pick to release-4.0 in PR #2183 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is changed, added or deleted? (Required)
Add the SQL diagnosis overview.
Which TiDB version(s) do your changes apply to? (Required)
If you select two or more versions from above, to trigger the bot to cherry-pick this PR to your desired release version branch(es), you must add corresponding labels such as needs-cherry-pick-4.0, needs-cherry-pick-3.1, needs-cherry-pick-3.0, and needs-cherry-pick-2.1.
What is the related PR or file link(s)?