検査結果

TiDB には、システム内の障害や隠れた問題を検出するためのいくつかの組み込み診断ルールがあります。

INSPECTION_RESULT診断テーブルは、問題を迅速に発見し、反復的な手動作業を軽減するのに役立ちます。 select * from information_schema.inspection_resultステートメントを使用して内部診断をトリガーできます。

注記：

このテーブルは TiDB セルフホスト型にのみ適用され、 TiDB Cloudでは使用できません。

information_schema.inspection_result診断結果テーブルinformation_schema.inspection_resultの構造は次のとおりです。

USE information_schema;
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    |       |
| STATUS_ADDRESS | varchar(64)  | YES  |      | NULL    |       |
| VALUE          | varchar(64)  | YES  |      | NULL    |       |
| REFERENCE      | varchar(64)  | YES  |      | NULL    |       |
| SEVERITY       | varchar(64)  | YES  |      | NULL    |       |
| DETAILS        | varchar(256) | YES  |      | NULL    |       |
+----------------+--------------+------+------+---------+-------+
9 rows in set (0.00 sec)

フィールドの説明:

• RULE : 診断ルールの名前。現在、次のルールが利用可能です。
  • config : 設定が一貫していて適切であるかどうかをチェックします。同じ構成が異なるインスタンスで一貫性がない場合、 warning診断結果が生成されます。
  • version : バージョンの整合性チェック。同じバージョンが異なるインスタンスで一貫性がない場合、 warning診断結果が生成されます。
  • node-load :サーバーの負荷をチェックします。現在のシステム負荷が高すぎる場合、対応するwarning診断結果が生成されます。
  • critical-error : システムの各モジュールは重大なエラーを定義します。対応する期間内に重大なエラーがしきい値を超えると、警告の診断結果が生成されます。
  • threshold-check : 診断システムは主要なメトリックのしきい値をチェックします。しきい値を超えると、対応する診断情報が生成されます。
• ITEM : 各ルールは異なる項目を診断します。このフィールドは、各ルールに対応する具体的な診断項目を示します。
• TYPE : 診断のインスタンス タイプ。オプションの値はtidb 、 pd 、およびtikvです。
• INSTANCE : 診断されたインスタンスの特定のアドレス。
• STATUS_ADDRESS : インスタンスの HTTP API サービス アドレス。
• VALUE : 特定の診断項目の値。
• REFERENCE : この診断項目の基準値(閾値)です。 VALUEがしきい値を超えると、対応する診断情報が生成されます。
• SEVERITY : 重大度レベル。オプションの値はwarningとcriticalです。
• DETAILS : 診断の詳細。SQL ステートメントや詳細な診断のためのドキュメント リンクも含まれる場合があります。

診断例

クラスター内に現在存在する問題を診断します。

SELECT * FROM information_schema.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 行目は、クラスター内に 2 つの異なる TiDB バージョンが存在することを示しています。
• 3 行目と 4 行目は、TiKV 書き込み遅延が長すぎることを示しています。予想される遅延は 0.1 秒以下ですが、実際の遅延は予想よりもはるかに長くなります。

「2020-03-26 00:03:00」から「2020-03-26 00:08:00」など、指定した範囲内に存在する問題を診断することもできます。時間範囲を指定するには、SQL ヒント/*+ time_range() */を使用します。次のクエリの例を参照してください。

select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from information_schema.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で再起動されることを示します。
• 2 行目は、 172.16.5.40:10089 TiDB インスタンスの最大get-token-duration時間は 0.234 秒ですが、予想される時間は 0.001 秒未満であることを示しています。

条件を指定して、たとえばcriticalレベルの診断結果をクエリすることもできます。

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

critical-errorルールの診断結果のみをクエリします。

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

診断ルール

診断モジュールには一連のルールが含まれています。これらのルールは、既存の監視テーブルおよびクラスター情報テーブルをクエリした後、結果をしきい値と比較します。結果がしきい値を超えた場合、 warningまたはcriticalの診断が生成され、対応する情報がdetails列に表示されます。

inspection_rulesシステム テーブルをクエリすることで、既存の診断ルールをクエリできます。

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

+-----------------+------------+---------+
| NAME            | TYPE       | COMMENT |
+-----------------+------------+---------+
| config          | inspection |         |
| version         | inspection |         |
| node-load       | inspection |         |
| critical-error  | inspection |         |
| threshold-check | inspection |         |
+-----------------+------------+---------+

config診断ルール

config診断ルールでは、 CLUSTER_CONFIGシステム テーブルをクエリすることによって、次の 2 つの診断ルールが実行されます。

• 同じコンポーネントの設定値が一致しているかどうかを確認します。すべての構成項目にこの一貫性チェックがあるわけではありません。整合性チェックの許可リストは次のとおりです。

  // The allowlist of the TiDB configuration consistency check
  port
  status.status-port
  host
  path
  advertise-address
  status.status-port
  log.file.filename
  log.slow-query-file
  tmp-storage-path
  
  // The allowlist of the PD configuration consistency check
  advertise-client-urls
  advertise-peer-urls
  client-urls
  data-dir
  log-file
  log.file.filename
  metric.job
  name
  peer-urls
  
  // The allowlist of the TiKV configuration consistency check
  server.addr
  server.advertise-addr
  server.status-addr
  log-file
  raftstore.raftdb-path
  storage.data-dir
  storage.block-cache.capacity
  

• 以下の設定項目の値が期待どおりであるかどうかを確認します。

  成分	コンフィグレーション項目	期待値
  TiDB	log.slow-threshold	0より大きい
  TiKV	raftstore.同期ログ	true

version診断ルール

version診断ルールは、 CLUSTER_INFOシステム テーブルをクエリすることによって、同じコンポーネントのバージョン ハッシュが一貫しているかどうかをチェックします。次の例を参照してください。

SELECT * FROM information_schema.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 つの診断ルールが実行されます。

• メトリクス スキーマ内の関連する監視システム テーブルをクエリすることにより、クラスターに次のエラーがあるかどうかを検出します。

  成分	エラー名	監視テーブル	エラーの説明
  TiDB	パニックカウント	tidb_panic_count_total_count	TiDB でパニックが発生します。
  TiDB	バイナリログエラー	tidb_binlog_error_total_count	TiDB がbinlogを書き込むときにエラーが発生します。
  TiKV	クリティカル・エラー	tikv_critical_error_total_coun	TiKV の重大なエラー。
  TiKV	スケジューラが忙しい	tikv_scheduler_is_busy_total_count	TiKV スケジューラがビジー状態であるため、TiKV が一時的に利用できなくなります。
  TiKV	コプロセッサーがビジー状態です	tikv_coprocessor_is_busy_total_count	TiKVコプロセッサーはビジー状態です。
  TiKV	チャンネルがいっぱいです	tikv_channel_full_total_count	TiKVで「チャンネルフル」エラーが発生します。
  TiKV	tikv_engine_write_stall	tikv_engine_write_stall	TiKVで「ストール」エラーが発生します。

• metrics_schema.up監視テーブルとCLUSTER_LOGシステム テーブルをクエリして、コンポーネントが再起動されているかどうかを確認します。

threshold-check診断ルール

threshold-check診断ルールは、メトリック スキーマ内の関連する監視システム テーブルをクエリすることにより、クラスター内の次のメトリックがしきい値を超えているかどうかを確認します。

さらに、このルールは、TiKV インスタンス内の次のスレッドの CPU 使用率が高すぎるかどうかもチェックします。

• スケジューラ-ワーカー-CPU
• コプロセッサ-通常-CPU
• コプロセッサーハイCPU
• コプロセッサー低 CPU
• grpc-cpu
• raftstore-CPU
• 適用-CPU
• ストレージ-読み取りプール-通常-CPU
• ストレージ-読み取りプール-高-CPU
• ストレージ読み取りプール低 CPU
• 分割チェックCPU

組み込みの診断ルールは常に改善されています。さらに診断ルールがある場合は、PR または問題をtidbリポジトリに作成してください。