検査結果

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 : 診断のインスタンス タイプ。オプションの値はtidbpd 、およびtikvです。
  • INSTANCE : 診断されたインスタンスの特定のアドレス。
  • STATUS_ADDRESS : インスタンスの HTTP API サービス アドレス。
  • VALUE : 特定の診断項目の値。
  • REFERENCE : この診断項目の基準値(閾値)です。 VALUEがしきい値を超えると、対応する診断情報が生成されます。
  • SEVERITY : 重大度レベル。オプションの値はwarningcriticalです。
  • 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
  • 以下の設定項目の値が期待どおりであるかどうかを確認します。

    成分コンフィグレーション項目期待値
    TiDBlog.slow-threshold0より大きい
    TiKVraftstore.同期ログ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_countTiDB でパニックが発生します。
    TiDBバイナリログエラーtidb_binlog_error_total_countTiDB がbinlogを書き込むときにエラーが発生します。
    TiKVクリティカル・エラーtikv_critical_error_total_counTiKV の重大なエラー。
    TiKVスケジューラが忙しいtikv_scheduler_is_busy_total_countTiKV スケジューラがビジー状態であるため、TiKV が一時的に利用できなくなります。
    TiKVコプロセッサーがビジー状態ですtikv_coprocessor_is_busy_total_countTiKVコプロセッサーはビジー状態です。
    TiKVチャンネルがいっぱいですtikv_channel_full_total_countTiKVで「チャンネルフル」エラーが発生します。
    TiKVtikv_engine_write_stalltikv_engine_write_stallTiKVで「ストール」エラーが発生します。
  • metrics_schema.up監視テーブルとCLUSTER_LOGシステム テーブルをクエリして、コンポーネントが再起動されているかどうかを確認します。

threshold-check診断ルール

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

成分モニタリング指標監視テーブル期待値説明
TiDBtso-durationpd_tso_wait_duration< 50msトランザクションの TSO を取得するまでの待機時間。
TiDBトークンの取得期間tidb_get_token_duration< 1msトークンの取得にかかる時間を問い合わせます。関連する TiDB 構成項目はtoken-limitです。
TiDBロードスキーマ期間tidb_load_schema_duration1秒未満TiDB がスキーマ メタデータを更新するのにかかる時間。
TiKVスケジューラ-cmd-期間tikv_scheduler_command_duration< 0.1秒TiKV が KV cmdリクエストを実行するのにかかる時間。
TiKVハンドル スナップショット期間tikv_handle_snapshot_duration30代未満TiKV がスナップショットを処理するのにかかる時間。
TiKVストレージ書き込み期間tikv_storage_async_request_duration< 0.1秒TiKV の書き込みレイテンシー。
TiKVストレージスナップショット期間tikv_storage_async_request_duration< 50msTiKV がスナップショットを取得するのにかかる時間。
TiKVrocksdb-書き込み期間tikv_engine_write_duration< 100msTiKV RocksDB の書き込みレイテンシー。
TiKVロックスデータベース取得-期間tikv_engine_max_get_duration< 50msTiKV RocksDB の読み取りレイテンシー。
TiKVロックスデータベースシーク期間tikv_engine_max_seek_duration< 50msTiKV RocksDB の実行レイテンシーseek
TiKVスケジューラー保留中のコマンド数tikv_scheduler_pending_commands< 1000TiKV で停止したコマンドの数。
TiKVインデックスブロックキャッシュヒットtikv_block_index_cache_hit0.95TiKV のインデックスブロックキャッシュのヒット率。
TiKVフィルターブロックキャッシュヒットtikv_block_filter_cache_hit0.95TiKV のフィルターブロックキャッシュのヒット率。
TiKVデータブロックキャッシュヒットtikv_block_data_cache_hit0.80TiKV のデータブロックキャッシュのヒット率。
TiKVリーダースコアバランスpd_scheduler_store_status< 0.05各 TiKV インスタンスのリーダー スコアのバランスが取れているかどうかを確認します。インスタンス間の予想される差異は 5% 未満です。
TiKVリージョンスコアバランスpd_scheduler_store_status< 0.05各 TiKV インスタンスのリージョンスコアのバランスが取れているかどうかを確認します。インスタンス間の予想される差異は 5% 未満です。
TiKV店舗利用可能な残高pd_scheduler_store_status< 0.2各 TiKV インスタンスの利用可能なstorageのバランスが取れているかどうかを確認します。インスタンス間の予想される差異は 20% 未満です。
TiKV領域数pd_scheduler_store_status< 20000各 TiKV インスタンスのリージョンの数を確認します。単一インスタンス内の予想されるリージョン数は 20,000 未満です。
PD地域の健康pd_region_health< 100クラスター内でスケジュール処理中のリージョンの数を検出します。予想される数は合計 100 未満です。

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

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

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

このページは役に立ちましたか?

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.