diff --git a/alert-rules.md b/alert-rules.md index 10f93399cdfbe..adb525827e74f 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -49,7 +49,7 @@ summary: TiDB クラスターのアラートルールについて学習します - 解決： - リーダーのバランスは、[**TiKV-Details**>**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)で確認します。 + リーダーのバランスは、[**TiKV-Details**>**Cluster**ダッシュボード](/grafana-tikv-dashboard.md#cluster)で確認します。 #### `TiDB_domain_load_schema_total` {#tidb_domain_load_schema_total} @@ -411,7 +411,7 @@ summary: TiDB クラスターのアラートルールについて学習します - 解決： - [**TiKV-Details**> **PD**ダッシュボード](/grafana-tikv-dashboard.md#pd)を監視し、ストア低速スコアのメトリックを確認します。メトリック値が80を超えるノードを特定し、低速ノードとして検出します。 - - [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 + - [**TiKV-Details**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - レイテンシーのタイムアウト制限を増やすには、 [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)設定項目を大きな値に設定します。 - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。 @@ -482,8 +482,8 @@ summary: TiDB クラスターのアラートルールについて学習します - 解決： 1. [**TiKV-Details**> **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラートが発生した TiKV ノードのRaftプロポーズが他の TiKV ノードよりも大幅に高いかどうかを確認します。もしそうであれば、この TiKV に 1つ以上のホットスポットがあることを意味します。ホットスポットのスケジューリングが適切に機能するかどうかを確認する必要があります。 - 2. [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - 3. [**TiKV-Details**>**Raftプロセス**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。 + 2. [**TiKV-Details**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 + 3. [**TiKV-Details**>**Raft process**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。 #### `TiKV_write_stall` {#tikv_write_stall} @@ -537,7 +537,7 @@ summary: TiDB クラスターのアラートルールについて学習します - 解決： - 1. [**TiKV-Details**> **Raft提案**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラート対象の TiKV ノードの**サーバーあたりの 99% Propose 待機期間**メトリックが他の TiKV ノードと比べて大幅に高いかどうかを確認します。高い場合、この TiKV ノードにホットスポットが存在することを示し、ホットスポットのスケジューリングが適切に機能しているかどうかを確認する必要があります。 + 1. [**TiKV-Details**> **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラート対象の TiKV ノードの**サーバーあたりの 99% Propose 待機期間**メトリックが他の TiKV ノードと比べて大幅に高いかどうかを確認します。高い場合、この TiKV ノードにホットスポットが存在することを示し、ホットスポットのスケジューリングが適切に機能しているかどうかを確認する必要があります。 2. [**TiKV-Details**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。 @@ -739,7 +739,7 @@ summary: TiDB クラスターのアラートルールについて学習します - 解決： - [**TiKV-Details**>**タスク**ダッシュボード](/grafana-tikv-dashboard.md#task)のうち`Worker pending tasks`メトリックから、どの種類のタスクの値が高いかを確認します。 + [**TiKV-Details**>**Task**ダッシュボード](/grafana-tikv-dashboard.md#task)のうち`Worker pending tasks`メトリックから、どの種類のタスクの値が高いかを確認します。 #### `TiKV_low_space` {#tikv_low_space} diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 287adc4cb603a..d01e0e557a4d1 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -35,9 +35,9 @@ Raftstore のワークフロー図から、各リージョンのメッセージ ### パフォーマンス監視 {#performance-monitoring} -Grafana の**TiKV ダッシュボード**では、次の監視メトリックを確認できます。 +Grafana の**TiKV-Details**ダッシュボードでは、次の監視メトリックを確認できます。 -- **スレッドCPU**パネルの`Raft store CPU` +- **Thread CPU**パネルの`Raft store CPU` 基準値： `raftstore.store-pool-size * 85%`未満。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 0ead645c61372..0286129f04031 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -62,7 +62,7 @@ tikv: 既存のデプロイメントプランではCPUリソースが限られており、実際のリクエスト数も少ないため、監視パネルを監視し、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)の値を下げて使用率を80%未満に保つことができます。 -このテストでは、このパラメータの値は`2`に設定されています。gRPC**ポーリング CPU**パネルを確認すると、使用率が約 80% であることがわかります。 +このテストでは、このパラメータの値は`2`に設定されています。**gRPC poll CPU**パネルを確認すると、使用率が約 80% であることがわかります。 ![gRPC Pool CPU](/media/best-practices/three-nodes-grpc-pool-usage.png) @@ -70,7 +70,7 @@ tikv: TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。スケジューラスレッドプールは、TiKVが複雑なトランザクションリクエストを単純なキー値の読み取りまたは書き込みに変換するために使用されます。ただし、スケジューラスレッドプール自体は書き込み操作を実行しません。 -理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用率が低くなりすぎます。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。 +理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用率が低くなりすぎます。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**Scheduler worker CPU**パネルの対応するメトリックを観察した結果に基づいています。 ![Scheduler Worker CPU](/media/best-practices/three-nodes-scheduler-pool-usage.png) diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index ce8866ac28be9..f9e98c0d5b3b9 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -78,7 +78,7 @@ tikv-ctl --host= modify-tikv-config -n backup.enable-auto-tune -v |^^^^**--| Because the cluster workload gets higher, auto-tune adjusts the size of the thread pool to `2`. After that, the cluster still has 2 idle CPU cores. ``` -**バックアップ CPU 使用率**パネルでは、自動調整によって調整されたスレッドプールのサイズを確認できます。 +**Backup CPU Utilization**パネルでは、自動調整によって調整されたスレッドプールのサイズを確認できます。 ![Grafana dashboard example of backup auto-tune metrics](/media/br/br-auto-throttle.png) diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 7598379fcf5d7..4e85df32810fa 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -9,7 +9,7 @@ summary: このドキュメントでは、ログバックアップの監視、 ## スナップショットのバックアップと復元の監視 {#snapshot-backup-and-restore-monitoring} -スナップショットのバックアップと復元のメトリックを表示するには、Grafana の[**TiKV-Details**>**バックアップとインポート**ダッシュボード](/grafana-tikv-dashboard.md#backup--import)に移動します。 +スナップショットのバックアップと復元のメトリックを表示するには、Grafana の[**TiKV-Details**>**Backup & Import**ダッシュボード](/grafana-tikv-dashboard.md#backup--import)に移動します。 ## ログバックアップ監視 {#log-backup-monitoring} @@ -22,8 +22,8 @@ summary: このドキュメントでは、ログバックアップの監視、 ### Grafanaの設定 {#grafana-configuration} -- TiUPを使用してデプロイされたクラスターの場合、ダッシュボード[Grafana](https://grafana.com/)にポイントインタイムリカバリ (PITR) パネルが表示されます。TiKV-Details ダッシュボードの**バックアップログ**パネルが PITR パネルです。 -- 手動でデプロイされたクラスターの場合は、 [Grafanaダッシュボードをインポートする](/deploy-monitoring-services.md#step-2-import-a-grafana-dashboard)を参照し、 [tikv_詳細](https://github.com/tikv/tikv/blob/release-8.5/metrics/grafana/tikv_details.json) JSON ファイルを Grafana にアップロードしてください。その後、TiKV-Details ダッシュボードの**バックアップログ**パネルを見つけてください。 +- TiUPを使用してデプロイされたクラスターの場合、ダッシュボード[Grafana](https://grafana.com/)にポイントインタイムリカバリ (PITR) パネルが表示されます。TiKV-Details ダッシュボードの**Backup Log**パネルが PITR パネルです。 +- 手動でデプロイされたクラスターの場合は、 [Grafanaダッシュボードをインポートする](/deploy-monitoring-services.md#step-2-import-a-grafana-dashboard)を参照し、 [tikv_details](https://github.com/tikv/tikv/blob/release-8.5/metrics/grafana/tikv_details.json) JSON ファイルを Grafana にアップロードしてください。その後、TiKV-Details ダッシュボードの**Backup Log**パネルを見つけてください。 ### 監視メトリクス {#monitoring-metrics} diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md index b4fc6bc447780..f3fa965d5f290 100644 --- a/dm/dm-webui-guide.md +++ b/dm/dm-webui-guide.md @@ -16,11 +16,11 @@ DM WebUIは、TiDB Data Migration (DM)タスクを管理するためのWebベー DM WebUI には次のページがあります。 -- **移住** +- **Migration** - **Task**: タスク作成のエントリを提供し、各移行タスクの詳細情報を表示します。このページでは、移行タスクの監視、作成、削除、および設定を行うことができます。 - **Source**: 移行タスクのアップストリームデータソースの情報を設定します。このページでは、アップストリーム設定の作成と削除、アップストリーム設定に対応するタスクステータスの監視、アップストリーム設定の変更など、データ移行環境におけるアップストリーム設定を管理できます。 - - **レプリケーション詳細**：移行タスクの詳細なステータス情報を表示します。このページでは、指定したフィルターに基づいて、上流および下流の構成情報やデータベース名、ソーステーブルとターゲットテーブルの関係など、詳細な構成情報とステータス情報を確認できます。 -- **クラスタ** + - **Replication Detail**：移行タスクの詳細なステータス情報を表示します。このページでは、指定したフィルターに基づいて、上流および下流の構成情報やデータベース名、ソーステーブルとターゲットテーブルの関係など、詳細な構成情報とステータス情報を確認できます。 +- **Cluster** - **Members**：DMクラスタ内のすべてのマスターノードとワーカーノードのリスト、およびワーカーノードとソースノード間のバインディング関係を表示します。このページでは、現在のDMクラスタの構成情報と各ワーカーのステータス情報を確認できます。また、基本的な管理機能もこのページで提供されます。 インターフェースは次のとおりです。 diff --git a/follower-read.md b/follower-read.md index 29cdaf668c24f..0f6ca9dd635a9 100644 --- a/follower-read.md +++ b/follower-read.md @@ -101,7 +101,7 @@ set [session | global] tidb_replica_read = ''; ## 基本的な監視 {#basic-monitoring} -[**TiDB** > **KV Request**>**Read Req Traffic**パネル (v8.5.4 の新機能)](/grafana-tidb-dashboard.md#kv-request)をチェックして、 Follower Read を有効にするかどうかを決定し、有効にした後のトラフィック削減効果を確認できます。 +[**TiDB** > **KV Request** > **Read Req Traffic**パネル (v8.5.4 の新機能)](/grafana-tidb-dashboard.md#kv-request)をチェックして、 Follower Read を有効にするかどうかを決定し、有効にした後のトラフィック削減効果を確認できます。 diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index bf0fa88fab80f..5c4de40b3de7c 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -104,7 +104,7 @@ show config where type = 'tikv' and name like '%enable-compaction-filter%'; > **Note:** > -> 圧縮フィルター機構を使用すると、GCの進行が遅れる可能性があり、TiKVスキャンのパフォーマンスに影響する可能性があります。ワークロードに多数のコプロセッサリクエストが含まれており、パネル[**TiKV-Details >コプロセッサー詳細**](/grafana-tikv-dashboard.md#coprocessor-detail)で**Total Ops Details**の呼び出し回数が`next()`または`prev()`で、呼び出し回数が`processed_keys`回の3倍を大幅に超えている場合は、以下の対策を講じることができます。 +> 圧縮フィルター機構を使用すると、GCの進行が遅れる可能性があり、TiKVスキャンのパフォーマンスに影響する可能性があります。ワークロードに多数のコプロセッサリクエストが含まれており、[**TiKV-Details > Coprocessor Detail**](/grafana-tikv-dashboard.md#coprocessor-detail)パネルで**Total Ops Details**の呼び出し回数が`next()`または`prev()`で、呼び出し回数が`processed_keys`回の3倍を大幅に超えている場合は、以下の対策を講じることができます。 > > - v7.1.3 より前の TiDB バージョンでは、GC を高速化するために Compaction Filter を無効にすることをお勧めします。 > - TiDBバージョンv7.1.3からv7.5.6およびv7.6.0からv8.5.3では、TiDBは各リージョン[`region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710)の冗長バージョンの数と冗長バージョン[`region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710)の割合に基づいて自動的にコンパクションをトリガーし、コンパクションフィルタGCのパフォーマンスを向上させます。この場合、コンパクションフィルタを無効にするのではなく、これらの設定項目を調整してください。 diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index f989cc12d05c3..5ccebdaf117e9 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -39,14 +39,14 @@ PD ダッシュボード メトリック項目の説明は次のとおりです ## Operator {#operator} -- **Schedule operator create**: タイプごとに新しく作成されるオペレーターの数 -- **Schedule operator check**: 種類ごとにチェックされるオペレーターの数。主に現在のステップが完了したかどうかをチェックし、完了している場合は次に実行するステップを返します。 -- **Schedule operator finish**: タイプごとに終了したオペレーターの数 -- **Schedule operator timeout**: タイプごとのタイムアウトオペレーターの数 -- **Schedule operator replaced or canceled**: タイプごとに交代またはキャンセルされたオペレーターの数 -- **Schedule operators count by state**: 状態ごとのオペレーター数 -- **Operator finish duration**: 終了したオペレーターの最大時間 -- **Operator step duration**: 完了したオペレーターステップの最大所要時間 +- Schedule operator create: タイプごとに新しく作成されるオペレーターの数 +- Schedule operator check: 種類ごとにチェックされるオペレーターの数。主に現在のステップが完了したかどうかをチェックし、完了している場合は次に実行するステップを返します。 +- Schedule operator finish: タイプごとに終了したオペレーターの数 +- Schedule operator timeout: タイプごとのタイムアウトオペレーターの数 +- Schedule operator replaced or canceled: タイプごとに交代またはキャンセルされたオペレーターの数 +- Schedule operators count by state: 状態ごとのオペレーター数 +- Operator finish duration: 終了したオペレーターの最大時間 +- Operator step duration: 完了したオペレーターステップの最大所要時間 ![PD Dashboard - Operator metrics](/media/pd-dashboard-operator-v4.png) diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index 0bb8beb0b9dd8..e217f04be1330 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -11,11 +11,11 @@ Grafanaダッシュボードは、PD、TiDB、TiKV、Node_exporter、概要、 パフォーマンス概要ダッシュボードは、TiDB、PD、および TiKV のメトリックを調整し、それぞれを次のセクションで表示します。 -- 概要：データベース時間とSQL実行時間の概要。概要で異なる色を確認することで、データベースのワークロードプロファイルとパフォーマンスのボトルネックを素早く特定できます。 +- Overview：データベース時間とSQL実行時間の概要。概要で異なる色を確認することで、データベースのワークロードプロファイルとパフォーマンスのボトルネックを素早く特定できます。 -- 負荷プロファイル: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV リクエスト OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 +- Load profile: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV リクエスト OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 -- トップダウンのレイテンシーの内訳: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV リクエストレイテンシー、TiKV 内の書き込みレイテンシーの内訳。 +- Top-down latency breakdown: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV リクエストレイテンシー、TiKV 内の書き込みレイテンシーの内訳。 パフォーマンス概要ダッシュボードを使用すると、パフォーマンスを効率的に分析し、ユーザー応答時間のボトルネックがデータベースにあるかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要、ワークロードプロファイル、SQLレイテンシーの内訳を表示することで、データベース内のボトルネックを特定できます。詳細は[パフォーマンス分析とチューニング](/performance-tuning-methods.md)ご覧ください。 @@ -126,7 +126,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - Parse Duration: SQL文の解析にかかった時間 - Compile Duration: 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 -- Execution Duration: SQL文の実行計画の実行に要した時間 +- Execute Duration: SQL文の実行計画の実行に要した時間 これら3つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 3a18e13ab8c40..f428beda430ad 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -22,7 +22,7 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en - RRU: リアルタイムで計算される各リソースグループの読み取りリクエストユニット消費情報。`total`は 、すべてのリソースグループによって消費される読み取りリクエストユニットの合計です。 - RRU Per Query: 各SQL文が1秒あたりに消費する平均読み取りリクエストユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - WRU: リアルタイムで計算される各リソースグループの書き込みリクエストユニット消費情報。`total`は 、すべてのリソースグループによって消費される書き込みリクエストユニットの合計です。 -- WRU Per Query: 各SQL文が1秒あたりに消費する書き込みリクエストユニットの平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- WRU Per Query: 各SQL文が1秒あたりに消費する書き込みリクエストユニット（WRU）の平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - Available RU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`の場合、このリソースグループは`RU_PER_SEC`の割合でトークンを消費し、レート制限状態にあるとみなされます。 - Query Max Duration: リソースグループに関する最大クエリ期間。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 68e91770742da..eebace927435d 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -9,8 +9,8 @@ TiUPを使用してTiDBクラスターをデプロイする場合、監視シス Grafanaダッシュボードは、概要、PD、TiDB、TiKV、Node_exporter、ディスクパフォーマンス、パフォーマンス概要を含む一連のサブダッシュボードに分かれています。TiDBダッシュボードは、TiDBパネルとTiDBサマリーパネルで構成されています。2つのパネルの違いは、以下のとおりです。 -- TiDB パネル: クラスターの異常のトラブルシューティングのために可能な限り包括的な情報を提供します。 -- TiDBサマリーパネル：TiDBパネル情報のうち、ユーザーが最も関心のある部分を抽出し、若干の修正を加えています。日々のデータベース運用においてユーザーが特に関心を持つデータ（QPS、TPS、応答遅延など）を提供し、表示またはレポートする監視情報として機能します。 +- TiDB panel: クラスターの異常のトラブルシューティングのために可能な限り包括的な情報を提供します。 +- TiDB Summary Panel：TiDBパネル情報のうち、ユーザーが最も関心のある部分を抽出し、若干の修正を加えています。日々のデータベース運用においてユーザーが特に関心を持つデータ（QPS、TPS、応答遅延など）を提供し、表示またはレポートする監視情報として機能します。 このドキュメントでは、TiDB ダッシュボードに表示されるいくつかの主要な監視メトリックについて説明します。 diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index b7dda974e5bb0..5479f537a66dc 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -15,104 +15,104 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 このセクションでは、**TiKV-Details**ダッシュボード上のこれらの主要指標について詳しく説明します。 -### クラスタ {#cluster} +### Cluster {#cluster} -- ストアサイズ：TiKVインスタンスごとのストレージサイズ -- 利用可能なサイズ：TiKVインスタンスごとの利用可能な容量 -- 容量サイズ：TiKVインスタンスごとの容量サイズ +- Store size：TiKVインスタンスごとのストレージサイズ +- Available size：TiKVインスタンスごとの利用可能な容量 +- Capacity size：TiKVインスタンスごとの容量サイズ - CPU: TiKVインスタンスごとのCPU使用率 -- メモリ：TiKVインスタンスごとのメモリ使用量 -- IO使用率：TiKVインスタンスごとのI/O使用率 +- Memory：TiKVインスタンスごとのメモリ使用量 +- IO utilization：TiKVインスタンスごとのI/O使用率 - MBps: 各TiKVインスタンスにおける読み取りと書き込みの合計バイト数 - QPS: 各TiKVインスタンスにおけるコマンドあたりのQPS - Errps: gRPCメッセージの失敗率 -- リーダー: TiKVインスタンスごとのリーダーの数 -- リージョン：TiKVインスタンスあたりのリージョン数 -- 稼働時間：前回の再起動以降のTiKVの実行時間 +- leader: TiKVインスタンスごとのリーダーの数 +- Region：TiKVインスタンスあたりのリージョン数 +- Uptime：前回の再起動以降のTiKVの実行時間 ![TiKV Dashboard - Cluster metrics](/media/tikv-dashboard-cluster.png) -### エラー {#errors} +### Errors {#errors} -- 重大なエラー: 重大なエラーの数 -- サーバーがビジー状態です: 書き込み停止やチャネル満杯など、TiKV インスタンスが一時的に利用できなくなるイベントが発生したことを示します。通常の場合は`0`となります。 -- サーバー報告の失敗:サーバーによって報告されたエラーメッセージの数。通常は`0`になります。 -- Raftstoreエラー：各TiKVインスタンスにおけるタイプ別のRaftstoreエラー数 -- スケジューラエラー: TiKVインスタンスごとに、タイプ別のスケジューラエラーの数 -- コプロセッサーエラー：各TiKVインスタンスにおけるタイプ別のコプロセッサエラー数 -- gRPCメッセージエラー：各TiKVインスタンスにおけるタイプ別のgRPCメッセージエラー数 -- Leaderのドロップ数：TiKVインスタンスごとのドロップされたリーダーの数 -- Leaderが見つからない: TiKVインスタンスごとのリーダーが見つからない数 -- ログレプリケーション拒否: 各TiKVインスタンスでメモリ不足のために拒否されたログ追加メッセージの数 +- Critical error: 重大なエラーの数 +- Server is busy: 書き込み停止やチャネル満杯など、TiKV インスタンスが一時的に利用できなくなるイベントが発生したことを示します。通常の場合は`0`となります。 +- Server report failures:サーバーによって報告されたエラーメッセージの数。通常は`0`になります。 +- Raftstore error：各TiKVインスタンスにおけるタイプ別のRaftstoreエラー数 +- Scheduler error: TiKVインスタンスごとに、タイプ別のスケジューラエラーの数 +- Coprocessor error：各TiKVインスタンスにおけるタイプ別のコプロセッサエラー数 +- gRPC message error：各TiKVインスタンスにおけるタイプ別のgRPCメッセージエラー数 +- Leader drop：TiKVインスタンスごとのドロップされたリーダーの数 +- Leader missing: TiKVインスタンスごとのリーダーが見つからない数 +- Log Replication Reject: 各TiKVインスタンスでメモリ不足のために拒否されたログ追加メッセージの数 ![TiKV Dashboard - Errors metrics](/media/tikv-dashboard-errors-v610.png) -### サーバ {#server} +### Server {#server} -- CFサイズ：各カラムファミリーのサイズ -- ストアサイズ：TiKVインスタンスごとのストレージサイズ -- チャネル満杯: TiKV インスタンスごとのチャネル満杯エラーの数。通常の場合は`0`になります。 -- アクティブな執筆リーダー: 各 TiKV インスタンスで執筆されているリーダーの数 -- おおよそのリージョンサイズ：おおよそのリージョンサイズ -- おおよそのリージョンサイズヒストグラム：各おおよそのリージョンサイズのヒストグラム -- リージョン平均書き込みキー数：TiKVインスタンスごとにリージョンに書き込まれたキーの平均数 -- リージョン平均書き込みバイト数：TiKVインスタンスごとのリージョンへの平均書き込みバイト数 +- CF size：各カラムファミリーのサイズ +- Store size：TiKVインスタンスごとのストレージサイズ +- Channel full: TiKV インスタンスごとのチャネル満杯エラーの数。通常の場合は`0`になります。 +- Active written leaders: 各 TiKV インスタンスで執筆されているリーダーの数 +- Approximate Region size：おおよそのリージョンサイズ +- Approximate Region size Histogram：各おおよそのリージョンサイズのヒストグラム +- Region average written keys：TiKVインスタンスごとにリージョンに書き込まれたキーの平均数 +- Region average written bytes：TiKVインスタンスごとのリージョンへの平均書き込みバイト数 ![TiKV Dashboard - Server metrics](/media/tikv-dashboard-server.png) ### gRPC {#grpc} -- gRPCメッセージ数：タイプごとのgRPCメッセージの発生率 -- gRPCメッセージの失敗: gRPCメッセージの失敗率 -- 99% gRPCメッセージ期間：メッセージタイプごとのgRPCメッセージ期間（P99） -- gRPCメッセージの平均実行時間：gRPCメッセージの平均実行時間 -- gRPCバッチサイズ：TiDBとTiKV間のgRPCメッセージのバッチサイズ -- Raftメッセージのバッチサイズ：TiKVインスタンス間のRaftメッセージのバッチサイズ -- gRPCリクエストソースのQPS：gRPCリクエストソースのQPS -- gRPCリクエストソースの実行時間：gRPCリクエストソースの実行時間 -- gRPCリソースグループQPS：リソースグループ別のgRPCリクエストソースのQPS - -### スレッドCPU {#thread-cpu} - -- Raftストア CPU: `raftstore`スレッドの CPU 使用率。通常の場合、CPU 使用率は 80% * `raftstore.store-pool-size`未満である必要があります。 -- 非同期適用CPU: `async apply`スレッドのCPU使用率。通常の場合、CPU使用率は90% * `raftstore.apply-pool-size`未満である必要があります。 -- ストアライターCPU: 非同期IOスレッドのCPU使用率。通常の場合`raftstore.store-io-pool-size` CPU使用率は90%未満である必要があります。 +- gRPC message count：タイプごとのgRPCメッセージの発生率 +- gRPC message failed: gRPCメッセージの失敗率 +- 99% gRPC message duration：メッセージタイプごとのgRPCメッセージ期間（P99） +- Average gRPC message duration：gRPCメッセージの平均実行時間 +- gRPC batch size：TiDBとTiKV間のgRPCメッセージのバッチサイズ +- Raft message batch size：TiKVインスタンス間のRaftメッセージのバッチサイズ +- gRPC request sources QPS：gRPCリクエストソースのQPS +- gRPC request sources duration：gRPCリクエストソースの実行時間 +- gRPC resource group QPS：リソースグループ別のgRPCリクエストソースのQPS + +### Thread CPU {#thread-cpu} + +- Raft store CPU: `raftstore`スレッドの CPU 使用率。通常の場合、CPU 使用率は 80% * `raftstore.store-pool-size`未満である必要があります。 +- Async apply CPU: `async apply`スレッドのCPU使用率。通常の場合、CPU使用率は90% * `raftstore.apply-pool-size`未満である必要があります。 +- Store writer CPU: 非同期IOスレッドのCPU使用率。通常の場合`raftstore.store-io-pool-size` CPU使用率は90%未満である必要があります。 - gRPC poll CPU: `gRPC`スレッドの CPU 使用率。通常の場合、CPU 使用率は 80% * `server.grpc-concurrency`未満である必要があります。 -- スケジューラワーカーの CPU: `scheduler worker`スレッドの CPU 使用率。通常の場合、CPU 使用率は 90% * `storage.scheduler-worker-pool-size`未満である必要があります。 +- Scheduler worker CPU: `scheduler worker`スレッドの CPU 使用率。通常の場合、CPU 使用率は 90% * `storage.scheduler-worker-pool-size`未満である必要があります。 - Storage ReadPool CPU: `storage read pool`スレッドの CPU 使用率 -- 統合読み取りプールCPU: `unified read pool`スレッドのCPU使用率 +- Unified read pool CPU: `unified read pool`スレッドのCPU使用率 - RocksDB CPU: RocksDBスレッドのCPU使用率 -- コプロセッサーCPU: `coprocessor`スレッドのCPU使用率 -- GCワーカーCPU: `GC worker`スレッドのCPU使用率 -- バックグラウンドワーカーCPU: `background worker`スレッドのCPU使用率 -- CPU のインポート: `import`スレッドの CPU 使用率 -- バックアップワーカーCPU: `backup`スレッドのCPU使用率 -- CDCワーカーCPU： `CDC worker`スレッドのCPU使用率 -- CDCエンドポイントCPU： `CDC endpoint`スレッドのCPU使用率 -- RaftlogフェッチワーカーのCPU使用率：非同期RaftログフェッチャーワーカーのCPU使用率 -- TSOワーカーCPU： `TSO worker`スレッドのCPU使用率 +- Coprocessor CPU: `coprocessor`スレッドのCPU使用率 +- GC worker CPU: `GC worker`スレッドのCPU使用率 +- BackGround worker CPU: `background worker`スレッドのCPU使用率 +- Import CPU: `import`スレッドの CPU 使用率 +- Backup Worker CPU: `backup`スレッドのCPU使用率 +- CDC Worker CPU： `CDC worker`スレッドのCPU使用率 +- CDC endpoint CPU： `CDC endpoint`スレッドのCPU使用率 +- Raftlog fetch worker CPU：非同期RaftログフェッチャーワーカーのCPU使用率 +- TSO Worker CPU： `TSO worker`スレッドのCPU使用率 ### PD {#pd} -- PDリクエスト：TiKVがPDに送信するレート -- PDリクエスト処理時間（平均）：TiKVがPDに送信するリクエストの処理にかかる平均時間 -- PDハートビート：TiKVからPDへハートビートメッセージが送信される頻度 -- PDによるピアの検証：TiKVからPDへTiKVピアを検証するためにメッセージが送信される頻度 +- PD requests：TiKVがPDに送信するレート +- PD request duration (average)：TiKVがPDに送信するリクエストの処理にかかる平均時間 +- PD heartbeats：TiKVからPDへハートビートメッセージが送信される頻度 +- PD validate peers：TiKVからPDへTiKVピアを検証するためにメッセージが送信される頻度 ### Raft IO {#raft-io} -- ログ適用期間： Raftがログを適用するのにかかる時間 -- サーバーごとのログ適用期間： RaftがTiKVインスタンスごとにログを適用するのにかかる時間 -- ログ追加期間： Raftがログを追加するのにかかる時間 -- サーバーごとのログ追加期間： RaftがTiKVインスタンスごとにログを追加するのにかかる時間 -- コミットログの所要時間： Raftがログをコミットするのに要する時間 -- サーバーごとのコミットログ期間： RaftがTiKVインスタンスごとにログをコミットするのに要する時間 +- Apply log duration： Raftがログを適用するのにかかる時間 +- Apply log duration per server： RaftがTiKVインスタンスごとにログを適用するのにかかる時間 +- Append log duration： Raftがログを追加するのにかかる時間 +- Append log duration per server： RaftがTiKVインスタンスごとにログを追加するのにかかる時間 +- Commit log duration： Raftがログをコミットするのに要する時間 +- Commit log duration per server： RaftがTiKVインスタンスごとにログをコミットするのに要する時間 ![TiKV Dashboard - Raft IO metrics](/media/tikv-dashboard-raftio.png) -### Raftプロセス {#raft-process} +### Raft process {#raft-process} -- 処理済み準備完了: 1秒あたり、タイプごとに処理された準備完了操作の数 +- Ready handled: 1秒あたり、タイプごとに処理された準備完了操作の数 - count: 1秒あたりに処理された準備完了操作の数 - has_ready_region: 1秒あたりに準備完了状態にあるリージョンの数 - pending_region: 準備完了状態かどうかを確認しているリージョンの1秒あたりの操作数。このメトリックはv3.0.0以降非推奨です。 @@ -120,450 +120,450 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - 追加: 準備完了操作が1秒あたりに含むRaftログエントリの数 - commit: 準備完了操作が1秒あたりにコミットするRaftログエントリの数 - スナップショット: 準備完了操作が1秒あたりに保持するスナップショットの数 -- 0.99Raftストアイベントの所要時間：Raftstoreイベントにかかる時間（P99） -- プロセス準備完了までの時間： Raftでプロセスが準備完了になるまでにかかる時間 -- サーバーごとのプロセス準備完了時間：TiKVインスタンスごとに、 Raftでピアプロセスが準備完了になるまでにかかる時間。2秒未満（P99.99）である必要があります。 -- Raftストアイベントの最大継続時間：最も遅いRaftstoreイベントにかかる時間。 -- レプリカ読み取りロックチェック時間：レプリカ読み取り処理時にロックをチェックするのに要する時間。 -- ピアメッセージ長分布：各TiKVインスタンスの各リージョンで同時に処理されるメッセージ数。メッセージ数が多いほど、ピアの処理負荷が高くなります。 +- 0.99 Duration of Raft store events：Raftstoreイベントにかかる時間（P99） +- Process ready duration： Raftでプロセスが準備完了になるまでにかかる時間 +- Process ready duration per server：TiKVインスタンスごとに、 Raftでピアプロセスが準備完了になるまでにかかる時間。2秒未満（P99.99）である必要があります。 +- Max Duration of Raft store events：最も遅いRaftstoreイベントにかかる時間。 +- Replica read lock checking duration：レプリカ読み取り処理時にロックをチェックするのに要する時間。 +- Peer msg length distribution：各TiKVインスタンスの各リージョンで同時に処理されるメッセージ数。メッセージ数が多いほど、ピアの処理負荷が高くなります。 ![TiKV Dashboard - Raft process metrics](/media/tikv-dashboard-raft-process.png) -### Raftメッセージ {#raft-message} +### Raft message {#raft-message} -- サーバーあたりの送信メッセージ数：各TiKVインスタンスが1秒あたりに送信するRaftメッセージの数 -- サーバーごとのフラッシュメッセージ数：各TiKVインスタンスでRaftクライアントが1秒あたりにフラッシュするRaftメッセージの数 -- サーバーごとの受信メッセージ数：各TiKVインスタンスが1秒あたりに受信するRaftメッセージの数 -- メッセージ：1秒あたりに送信されるRaftメッセージの種類ごとの数 -- 投票： Raftで1秒あたりに送信される投票メッセージの数 -- Raftドロップメッセージ数: 1秒あたりの、種類別のドロップされたRaftメッセージ数 +- Sent messages per server：各TiKVインスタンスが1秒あたりに送信するRaftメッセージの数 +- Flush messages per server：各TiKVインスタンスでRaftクライアントが1秒あたりにフラッシュするRaftメッセージの数 +- Receive messages per server：各TiKVインスタンスが1秒あたりに受信するRaftメッセージの数 +- Messages：1秒あたりに送信されるRaftメッセージの種類ごとの数 +- Vote： Raftで1秒あたりに送信される投票メッセージの数 +- Raft dropped messages: 1秒あたりの、種類別のドロップされたRaftメッセージ数 ![TiKV Dashboard - Raft message metrics](/media/tikv-dashboard-raft-message.png) -### Raftの提案 {#raft-propose} +### Raft propose {#raft-propose} -- Raft準備完了ごとの提案適用数: 提案適用中に、各準備完了操作がバッチ内に含める提案数のヒストグラム。 -- Raftの読み書き提案：1秒あたりのタイプ別提案数 -- サーバーごとのRaft読み取り提案数：各TiKVインスタンスが1秒あたりに行う読み取り提案の数 -- サーバーごとのRaft書き込み提案数：各TiKVインスタンスが1秒あたりに行う書き込み提案の数 -- 提案待ち時間：各提案の待ち時間のヒストグラム -- サーバーごとの提案待ち時間：TiKVインスタンスごとの各提案の待ち時間のヒストグラム -- 適用待ち時間：各提案の適用時間のヒストグラム -- サーバーごとの適用待ち時間：TiKVインスタンスごとの各提案の適用時間のヒストグラム -- Raftログ速度：ピアがログを提案する平均レート +- Raft apply proposals per ready: 提案適用中に、各準備完了操作がバッチ内に含める提案数のヒストグラム。 +- Raft read/write proposals：1秒あたりのタイプ別提案数 +- Raft read proposals per server：各TiKVインスタンスが1秒あたりに行う読み取り提案の数 +- Raft write proposals per server：各TiKVインスタンスが1秒あたりに行う書き込み提案の数 +- Propose wait duration：各提案の待ち時間のヒストグラム +- Propose wait duration per server：TiKVインスタンスごとの各提案の待ち時間のヒストグラム +- Apply wait duration：各提案の適用時間のヒストグラム +- Apply wait duration per server：TiKVインスタンスごとの各提案の適用時間のヒストグラム +- Raft log speed：ピアがログを提案する平均レート ![TiKV Dashboard - Raft propose metrics](/media/tikv-dashboard-raft-propose.png) -### Raft管理者 {#raft-admin} +### Raft admin {#raft-admin} -- 管理者提案：1秒あたりの管理者提案数 -- 管理者適用: 1秒あたりに処理される適用コマンドの数 -- チェック分割：1秒あたりのRaftstore分割チェックコマンドの数 -- 99.99% チェック分割時間: 分割チェックコマンドの実行に要した時間 (P99.99) +- Admin proposals：1秒あたりの管理者提案数 +- Admin apply: 1秒あたりに処理される適用コマンドの数 +- Check split：1秒あたりのRaftstore分割チェックコマンドの数 +- 99.99% Check split duration: 分割チェックコマンドの実行に要した時間 (P99.99) ![TiKV Dashboard - Raft admin metrics](/media/tikv-dashboard-raft-admin.png) -### ローカルリーダー {#local-reader} +### Local reader {#local-reader} -- ローカルリーダーリクエスト：ローカル読み取りスレッドからの総リクエスト数と拒否数 +- Local reader requests：ローカル読み取りスレッドからの総リクエスト数と拒否数 ![TiKV Dashboard - Local reader metrics](/media/tikv-dashboard-local-reader.png) -### 統合リードプール {#unified-read-pool} +### Unified Read Pool {#unified-read-pool} -- レベル別使用時間：統合リードプールにおける各レベルで消費された時間。レベル0は小規模クエリを意味します。 -- レベル0の確率：統合リードプールにおけるレベル0タスクの割合 -- 実行中のタスク：統合読み取りプールで同時に実行されているタスクの数 +- Time used by level：統合リードプールにおける各レベルで消費された時間。レベル0は小規模クエリを意味します。 +- Level 0 chance：統合リードプールにおけるレベル0タスクの割合 +- Running tasks：統合読み取りプールで同時に実行されているタスクの数 -### ストレージ {#storage} +### Storage {#storage} -- ストレージコマンド合計：1秒あたりに受信したコマンドの種類別の数 -- ストレージ非同期リクエストエラー：1秒あたりのエンジン非同期リクエストエラーの数 -- ストレージ非同期スナップショット期間: 非同期スナップショットリクエストの処理に要する時間。 `1s`以内の`.99`未満である必要があります。 -- ストレージ非同期書き込み時間: 非同期書き込みリクエストの処理に要する時間。 `1s`以内の`.99`未満である必要があります。 +- Storage command total：1秒あたりに受信したコマンドの種類別の数 +- Storage async request error：1秒あたりのエンジン非同期リクエストエラーの数 +- Storage async snapshot duration: 非同期スナップショットリクエストの処理に要する時間。 `1s`以内の`.99`未満である必要があります。 +- Storage async write duration: 非同期書き込みリクエストの処理に要する時間。 `1s`以内の`.99`未満である必要があります。 ![TiKV Dashboard - Storage metrics](/media/tikv-dashboard-storage.png) -### 流量制御 {#flow-control} +### Flow Control {#flow-control} -- スケジューラフロー：各TiKVインスタンスにおけるスケジューラのトラフィックをリアルタイムで表示します。 -- スケジューラ破棄率：各 TiKV インスタンスにおけるスケジューラリクエストの拒否率。この比率が 0 より大きい場合、フロー制御が存在することを示します。 `Compaction pending bytes`がしきい値を超えると、TiKV は超過分に基づいて`Scheduler discard ratio`を線形に増加させます。クライアントは拒否されたリクエストを自動的に再試行します。 -- スロットル期間：L0ファイルが多すぎるためにフロー制御がトリガーされた場合に、スケジューラリクエストの実行がブロックされる期間。このメトリックに値がある場合、フロー制御が存在していることを示します。 -- スケジューラによるスロットリングCF：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするCF。 -- フローコントローラーのアクション：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするアクション。 -- フラッシュ/L0フロー：各TiKVインスタンス上のRocksDBの異なるCFにおけるフラッシュとL0圧縮のトラフィック。 -- フロー制御要因：RocksDBのスロットリングをトリガーする要因。 -- コンパクション保留バイト数：各TiKVインスタンスでリアルタイムにコンパクション待ち状態にあるRocksDBデータのサイズ。 -- トランザクションコマンドのスロットリング期間：スロットリングによりトランザクションに関連するコマンドがブロックされた期間。通常、このメトリックは0です。 -- 非トランザクションコマンドのスロットリング期間：スロットリングによって他のコマンドがブロックされた期間。通常、このメトリックは0です。 +- Scheduler flow：各TiKVインスタンスにおけるスケジューラのトラフィックをリアルタイムで表示します。 +- Scheduler discard ratio：各 TiKV インスタンスにおけるスケジューラリクエストの拒否率。この比率が 0 より大きい場合、フロー制御が存在することを示します。 `Compaction pending bytes`がしきい値を超えると、TiKV は超過分に基づいて`Scheduler discard ratio`を線形に増加させます。クライアントは拒否されたリクエストを自動的に再試行します。 +- Throttle duration：L0ファイルが多すぎるためにフロー制御がトリガーされた場合に、スケジューラリクエストの実行がブロックされる期間。このメトリックに値がある場合、フロー制御が存在していることを示します。 +- Scheduler throttled CF：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするCF。 +- Flow controller actions：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするアクション。 +- Flush/L0 flow：各TiKVインスタンス上のRocksDBの異なるCFにおけるフラッシュとL0圧縮のトラフィック。 +- Flow control factors：RocksDBのスロットリングをトリガーする要因。 +- Compaction pending bytes：各TiKVインスタンスでリアルタイムにコンパクション待ち状態にあるRocksDBデータのサイズ。 +- Txn command throttled duration：スロットリングによりトランザクションに関連するコマンドがブロックされた期間。通常、このメトリックは0です。 +- Non-txn command throttled duration：スロットリングによって他のコマンドがブロックされた期間。通常、このメトリックは0です。 ![TiKV Dashboard - Flow Control metrics](/media/tikv-dashboard-flow-control.png) -### スケジューラ {#scheduler} +### Scheduler {#scheduler} -- スケジューラステージ合計：各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 -- スケジューラ書き込みバイト数: 各TiKVインスタンスで処理されたコマンドによって書き込まれた合計バイト数 -- スケジューラ優先度コマンド：1秒あたりの異なる優先度コマンドの数 -- スケジューラ保留コマンド：TiKVインスタンスごとに1秒あたりに保留されているコマンドの数 +- Scheduler stage total：各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 +- Scheduler writing bytes: 各TiKVインスタンスで処理されたコマンドによって書き込まれた合計バイト数 +- Scheduler priority commands：1秒あたりの異なる優先度コマンドの数 +- Scheduler pending commands：TiKVインスタンスごとに1秒あたりに保留されているコマンドの数 ![TiKV Dashboard - Scheduler metrics](/media/tikv-dashboard-scheduler.png) -### スケジューラ - コミット {#scheduler---commit} +### Scheduler - commit {#scheduler---commit} -- スケジューラステージ合計：コミットコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 -- スケジューラコマンドの実行時間: コミットコマンドの実行に要する時間。 `1s`未満である必要があります。 -- スケジューラ ラッチ待機時間: コミット コマンドの実行時にラッチによって発生する待機時間。 `1s`より小さくなければなりません。 -- スケジューラキー読み取り数: コミットコマンドによって読み取られたキーの数 -- スケジューラキー書き込み数: コミットコマンドによって書き込まれたキーの数 -- スケジューラのスキャン詳細: commit コマンド実行時に各 CF のキースキャンの詳細を示します。 -- スケジューラスキャン詳細[ロック]: コミットコマンド実行時のロックCFのキースキャン詳細 -- スケジューラスキャン詳細[書き込み]: コミットコマンド実行時の書き込みCFのキースキャン詳細 -- スケジューラスキャン詳細[デフォルト]: コミットコマンド実行時のデフォルトCFのキースキャン詳細 +- Scheduler stage total：コミットコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 +- Scheduler command duration: コミットコマンドの実行に要する時間。 `1s`未満である必要があります。 +- Scheduler latch wait duration: コミット コマンドの実行時にラッチによって発生する待機時間。 `1s`より小さくなければなりません。 +- Scheduler keys read: コミットコマンドによって読み取られたキーの数 +- Scheduler keys written: コミットコマンドによって書き込まれたキーの数 +- Scheduler scan details: commit コマンド実行時に各 CF のキースキャンの詳細を示します。 +- Scheduler scan details [lock]: コミットコマンド実行時のロックCFのキースキャン詳細 +- Scheduler scan details [write]: コミットコマンド実行時の書き込みCFのキースキャン詳細 +- Scheduler scan details [default]: コミットコマンド実行時のデフォルトCFのキースキャン詳細 ![TiKV Dashboard - Scheduler commit metrics](/media/tikv-dashboard-scheduler-commit.png) -### スケジューラ - 悲観的ロールバック {#scheduler---pessimistic_rollback} - -- スケジューラステージ合計： `pessimistic_rollback`コマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 -- スケジューラコマンドの実行時間: `pessimistic_rollback`コマンドの実行に要する時間。 `1s`より短くなければなりません。 -- スケジューラ ラッチ待機時間: `pessimistic_rollback`コマンドの実行時にラッチによって発生する待機時間。 `1s`より短くする必要があります。 -- スケジューラキー読み取り: `pessimistic_rollback`コマンドによって読み取られたキーの数 -- スケジューラキー書き込み数: `pessimistic_rollback`コマンドによって書き込まれたキーの数 -- スケジューラのスキャン詳細: `pessimistic_rollback`コマンドを実行する際の各 CF のキーのスキャン詳細。 -- スケジューラスキャンの詳細[ロック]: `pessimistic_rollback`コマンド実行時のロック CF のキースキャンの詳細 -- スケジューラのスキャン詳細[書き込み]: `pessimistic_rollback`コマンド実行時の書き込み CF のキー スキャン詳細 -- スケジューラのスキャン詳細[デフォルト]: `pessimistic_rollback`コマンド実行時のデフォルト CF のキー スキャン詳細 - -### スケジューラ - 事前書き込み {#scheduler---prewrite} - -- スケジューラステージ合計：プリライトコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 -- スケジューラコマンドの実行時間: プリライトコマンドの実行に要する時間。 `1s`未満である必要があります。 -- スケジューラ ラッチ待機時間: プリライト コマンドの実行時にラッチによって発生する待機時間。 `1s`より小さくなければなりません。 -- スケジューラキー読み取り数：プリライトコマンドによって読み取られたキーの数 -- スケジューラキー書き込み数：プリライトコマンドによって書き込まれたキーの数 -- スケジューラのスキャン詳細：プリライトコマンド実行時の各CFのキースキャン詳細。 -- スケジューラスキャン詳細[ロック]: プリライトコマンド実行時のロックCFのキースキャン詳細 -- スケジューラスキャン詳細[書き込み]: プリライトコマンド実行時の書き込みCFのキースキャン詳細 -- スケジューラスキャン詳細[デフォルト]: プリライトコマンド実行時のデフォルトCFのキースキャン詳細 - -### スケジューラ - ロールバック {#scheduler---rollback} - -- スケジューラステージ合計：ロールバックコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 -- スケジューラコマンドの実行時間: ロールバックコマンドの実行に要する時間。 `1s`未満である必要があります。 -- スケジューラ ラッチ待機時間: ロールバック コマンドの実行時にラッチによって発生する待機時間。 `1s`より小さくなければなりません。 -- スケジューラキー読み取り数：ロールバックコマンドによって読み取られたキーの数 -- スケジューラキー書き込み数: ロールバックコマンドによって書き込まれたキーの数 -- スケジューラのスキャン詳細: ロールバックコマンド実行時に各CFのキースキャンの詳細を示します。 -- スケジューラスキャン詳細[ロック]: ロールバックコマンド実行時のロックCFのキースキャン詳細 -- スケジューラスキャン詳細[書き込み]: ロールバックコマンド実行時の書き込みCFのキースキャン詳細 -- スケジューラスキャンの詳細[デフォルト]: ロールバックコマンド実行時のデフォルトCFのキースキャンの詳細 +### Scheduler - pessimistic_rollback {#scheduler---pessimistic_rollback} + +- Scheduler stage total： `pessimistic_rollback`コマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 +- Scheduler command duration: `pessimistic_rollback`コマンドの実行に要する時間。 `1s`より短くなければなりません。 +- Scheduler latch wait duration: `pessimistic_rollback`コマンドの実行時にラッチによって発生する待機時間。 `1s`より短くする必要があります。 +- Scheduler keys read: `pessimistic_rollback`コマンドによって読み取られたキーの数 +- Scheduler keys written: `pessimistic_rollback`コマンドによって書き込まれたキーの数 +- Scheduler scan details: `pessimistic_rollback`コマンドを実行する際の各 CF のキーのスキャン詳細。 +- Scheduler scan details [lock]: `pessimistic_rollback`コマンド実行時のロック CF のキースキャンの詳細 +- Scheduler scan details [write]: `pessimistic_rollback`コマンド実行時の書き込み CF のキー スキャン詳細 +- Scheduler scan details [default]: `pessimistic_rollback`コマンド実行時のデフォルト CF のキー スキャン詳細 + +### Scheduler - prewrite {#scheduler---prewrite} + +- Scheduler stage total：プリライトコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 +- Scheduler command duration: プリライトコマンドの実行に要する時間。 `1s`未満である必要があります。 +- Scheduler latch wait duration: プリライト コマンドの実行時にラッチによって発生する待機時間。 `1s`より小さくなければなりません。 +- Scheduler keys read：プリライトコマンドによって読み取られたキーの数 +- Scheduler keys written：プリライトコマンドによって書き込まれたキーの数 +- Scheduler scan details：プリライトコマンド実行時の各CFのキースキャン詳細。 +- Scheduler scan details [lock]: プリライトコマンド実行時のロックCFのキースキャン詳細 +- Scheduler scan details [write]: プリライトコマンド実行時の書き込みCFのキースキャン詳細 +- Scheduler scan details [default]: プリライトコマンド実行時のデフォルトCFのキースキャン詳細 + +### Scheduler - rollback {#scheduler---rollback} + +- Scheduler stage total：ロールバックコマンド実行時の、各ステージにおける1秒あたりのコマンド数。短時間で多くのエラーが発生するべきではありません。 +- Scheduler command duration: ロールバックコマンドの実行に要する時間。 `1s`未満である必要があります。 +- Scheduler latch wait duration: ロールバック コマンドの実行時にラッチによって発生する待機時間。 `1s`より小さくなければなりません。 +- Scheduler keys read：ロールバックコマンドによって読み取られたキーの数 +- Scheduler keys written: ロールバックコマンドによって書き込まれたキーの数 +- Scheduler scan details: ロールバックコマンド実行時に各CFのキースキャンの詳細を示します。 +- Scheduler scan details [lock]: ロールバックコマンド実行時のロックCFのキースキャン詳細 +- Scheduler scan details [write]: ロールバックコマンド実行時の書き込みCFのキースキャン詳細 +- Scheduler scan details [default]: ロールバックコマンド実行時のデフォルトCFのキースキャンの詳細 ### GC {#gc} -- GCタスク: gc_workerによって処理されたGCタスクの数 -- GCタスクの実行時間：GCタスクの実行に要する時間 -- TiDB GC秒数：GCの所要時間 -- TiDB GCワーカーアクション：TiDB GCワーカーアクションの回数 -- ResolveLocksの進捗状況：GCの第一段階（Resolve Locks）の進捗状況 -- TiKV自動GCの進捗状況：GCの第2段階の進捗状況 -- GC速度：1秒あたりにGCによって削除されるキーの数 +- GC tasks: gc_workerによって処理されたGCタスクの数 +- GC tasks Duration：GCタスクの実行に要する時間 +- TiDB GC seconds：GCの所要時間 +- TiDB GC worker actions：TiDB GCワーカーアクションの回数 +- ResolveLocks Progress：GCの第一段階（Resolve Locks）の進捗状況 +- TiKV Auto GC Progress：GCの第2段階の進捗状況 +- GC speed：1秒あたりにGCによって削除されるキーの数 - TiKV Auto GC SafePoint: TiKV GCセーフポイントの値。セーフポイントは現在のGCタイムスタンプです。 -- GCの寿命：TiDB GCの寿命 -- GC間隔：TiDB GCの間隔 -- コンパクションフィルタ内のGC: write CFのコンパクションフィルタでフィルタリングされたバージョンの数。 - -### スナップショット {#snapshot} - -- スナップショットメッセージの送信レート： Raftスナップショットメッセージが送信される頻度 -- スナップショット処理時間（99%）：スナップショットの処理にかかる時間（P99） -- スナップショット状態数：状態ごとのスナップショット数 -- スナップショットサイズ: スナップショットサイズ (P99.99) -- 99.99%スナップショットKV数：スナップショット内のKV数（P99.99） - -### タスク {#task} - -- ワーカーが処理したタスク数：ワーカーが1秒あたりに処理したタスク数 -- ワーカーの保留中のタスク: ワーカーが1秒あたりに処理している保留中および実行中のタスクの現在の数。通常は`1000`未満である必要があります。 -- FuturePoolが処理したタスク数：FuturePoolが1秒あたりに処理したタスク数 -- FuturePoolの保留中のタスク：FuturePoolの保留中および実行中のタスクの現在の数（1秒あたり） - -### コプロセッサーの概要 {#coprocessor-overview} - -- リクエスト処理時間：コプロセッサからのリクエストを受信してから、リクエストの処理が完了するまでの合計時間 -- 総リクエスト数：1秒あたりのリクエストの種類別数 -- 処理時間：コプロセッサリクエストを実際に処理した時間（1分あたり）のヒストグラム -- 総リクエストエラー数：コプロセッサーが1秒あたりに発生させたリクエストエラーの数。短時間に多数のエラーが発生するべきではありません。 -- 合計 KV カーソル操作: 1秒あたりのタイプ別の KV カーソル操作の合計数。例`select` 、 `index` 、 `analyze_table` 、 `analyze_index` 、 `checksum_table` 、 `checksum_index` 。 -- KVカーソル操作：1秒あたりのタイプ別KVカーソル操作のヒストグラム -- RocksDBのパフォーマンス統計：RocksDBのパフォーマンスに関する統計情報 -- 応答の合計サイズ：コプロセッサ応答の合計サイズ - -### コプロセッサーの詳細 {#coprocessor-detail} - -- 処理時間：コプロセッサリクエストを実際に処理した時間（1分あたり）のヒストグラム -- ストアごとの処理時間（95%）：TiKVインスタンスごとに、コプロセッサリクエストを処理するのに要する時間（1秒あたり）（P95） -- 待機時間: コプロセッサリクエストが処理されるのを待っている間に消費される時間。 `10s` (P99.99) 未満である必要があります。 -- ストア別待機時間（95%）：コプロセッサリクエストが処理待ち状態にある時間（TiKVインスタンスごと、1秒あたり）（P95） -- 総DAGリクエスト数：1秒あたりのDAGリクエストの総数 -- 総DAG実行者数：1秒あたりのDAG実行者の総数 -- 総操作数（テーブルスキャン）：コプロセッサでselectスキャンを実行する際の、1秒あたりのRocksDB内部操作数 -- 総操作詳細（インデックススキャン）：コプロセッサでインデックススキャンを実行する際の、1秒あたりのRocksDB内部操作の数 -- CFごとの総操作詳細（テーブルスキャン）：コプロセッサで選択スキャンを実行する際の、各CFにおける1秒あたりのRocksDB内部操作の数 -- CFごとの総操作詳細（インデックススキャン）：コプロセッサでインデックススキャンを実行する際の、各CFにおける1秒あたりのRocksDB内部操作の数 - -### スレッド {#threads} - -- スレッドの状態：TiKVスレッドの状態 -- スレッドIO：各TiKVスレッドのI/Oトラフィック -- スレッドの自発的コンテキストスイッチ: TiKVスレッドの自発的コンテキストスイッチの数 -- スレッドの非自発的コンテキストスイッチ: TiKVスレッドの非自発的コンテキストスイッチの数 +- GC lifetime：TiDB GCの寿命 +- GC interval：TiDB GCの間隔 +- GC in Compaction Filter: write CFのコンパクションフィルタでフィルタリングされたバージョンの数。 + +### Snapshot {#snapshot} + +- Rate snapshot message： Raftスナップショットメッセージが送信される頻度 +- 99% Handle snapshot duration：スナップショットの処理にかかる時間（P99） +- Snapshot state count：状態ごとのスナップショット数 +- 99.99% Snapshot size: スナップショットサイズ (P99.99) +- 99.99% Snapshot KV count：スナップショット内のKV数（P99.99） + +### Task {#task} + +- Worker handled tasks：ワーカーが1秒あたりに処理したタスク数 +- Worker pending tasks: ワーカーが1秒あたりに処理している保留中および実行中のタスクの現在の数。通常は`1000`未満である必要があります。 +- FuturePool handled tasks：FuturePoolが1秒あたりに処理したタスク数 +- FuturePool pending tasks：FuturePoolの保留中および実行中のタスクの現在の数（1秒あたり） + +### Coprocessor Overview {#coprocessor-overview} + +- Request duration：コプロセッサからのリクエストを受信してから、リクエストの処理が完了するまでの合計時間 +- Total Requests：1秒あたりのリクエストの種類別数 +- Handle duration：コプロセッサリクエストを実際に処理した時間（1分あたり）のヒストグラム +- Total Request Errors：コプロセッサーが1秒あたりに発生させたリクエストエラーの数。短時間に多数のエラーが発生するべきではありません。 +- Total KV Cursor Operations: 1秒あたりのタイプ別の KV カーソル操作の合計数。例`select` 、 `index` 、 `analyze_table` 、 `analyze_index` 、 `checksum_table` 、 `checksum_index` 。 +- KV Cursor Operations：1秒あたりのタイプ別KVカーソル操作のヒストグラム +- Total RocksDB Perf Statistics：RocksDBのパフォーマンスに関する統計情報 +- Total Response Size：コプロセッサ応答の合計サイズ + +### Coprocessor Detail {#coprocessor-detail} + +- Handle duration：コプロセッサリクエストを実際に処理した時間（1分あたり）のヒストグラム +- 95% Handle duration by store：TiKVインスタンスごとに、コプロセッサリクエストを処理するのに要する時間（1秒あたり）（P95） +- Wait duration: コプロセッサリクエストが処理されるのを待っている間に消費される時間。 `10s` (P99.99) 未満である必要があります。 +- 95% Wait duration by store：コプロセッサリクエストが処理待ち状態にある時間（TiKVインスタンスごと、1秒あたり）（P95） +- Total DAG Requests：1秒あたりのDAGリクエストの総数 +- Total DAG Executors：1秒あたりのDAG実行者の総数 +- Total Ops Details (Table Scan)：コプロセッサでselectスキャンを実行する際の、1秒あたりのRocksDB内部操作数 +- Total Ops Details (Index Scan)：コプロセッサでインデックススキャンを実行する際の、1秒あたりのRocksDB内部操作の数 +- Total Ops Details by CF (Table Scan)：コプロセッサで選択スキャンを実行する際の、各CFにおける1秒あたりのRocksDB内部操作の数 +- Total Ops Details by CF (Index Scan)：コプロセッサでインデックススキャンを実行する際の、各CFにおける1秒あたりのRocksDB内部操作の数 + +### Threads {#threads} + +- Threads state：TiKVスレッドの状態 +- Threads IO：各TiKVスレッドのI/Oトラフィック +- Thread Voluntary Context Switches: TiKVスレッドの自発的コンテキストスイッチの数 +- Thread Nonvoluntary Context Switches: TiKVスレッドの非自発的コンテキストスイッチの数 ### RocksDB - kv/raft {#rocksdb---kvraft} -- 取得操作: 1秒あたりの取得操作の回数 -- 取得時間：取得操作の実行に要した時間 -- シーク操作：1秒あたりのシーク操作回数 -- シーク時間：シーク操作の実行に要する時間 -- 書き込み操作：1秒あたりの書き込み操作回数 -- 書き込み時間：書き込み操作の実行に要する時間 -- WAL同期操作：1秒あたりのWAL同期操作の回数 -- WAL書き込み時間：WALの書き込みに要した時間 -- WAL同期時間：WAL同期操作の実行に要する時間 -- 圧縮作業：1秒あたりの圧縮および洗浄作業の回数 -- 圧縮時間：圧縮および洗浄作業の実行に要する時間 -- SSTファイルの読み込み時間：SSTファイルの読み込みに要する時間 -- 停止時間を書き込む: 停止時間を書き込む。通常の場合は`0`となるはずです。 -- Memtableサイズ：各カラムファミリーのmemtableサイズ -- Memtableヒット：memtableのヒット率 -- ブロックキャッシュサイズ：ブロックキャッシュのサイズ。共有ブロックキャッシュが無効になっている場合は、カラムファミリーごとに内訳が表示されます。 -- ブロックキャッシュヒット：ブロックキャッシュのヒット率 -- ブロックキャッシュフロー：タイプごとのブロックキャッシュ操作のフローレート -- ブロックキャッシュ操作: タイプごとのブロックキャッシュ操作の回数 -- キーフロー：キーの種類ごとの操作フローレート -- 合計キー数：各カラムファミリー内のキーの数 -- 読み取りフロー：タイプごとの読み取り操作のフローレート -- バイト/読み取り：読み取り操作1回あたりのバイト数 -- 書き込みフロー：タイプごとの書き込み操作のフローレート -- バイト/書き込み: 書き込み操作あたりのバイト数 -- 圧縮フロー：タイプ別の圧縮作業のフローレート -- 圧縮保留バイト数：圧縮対象となる保留バイト数 -- 圧縮ジョブのサイズ（ファイル数）：単一の圧縮ジョブに関係するSSTファイルの数 -- リード増幅率: TiKVインスタンスごとのリード増幅率 -- 圧縮率：各レベルの圧縮率 -- スナップショット数：TiKVインスタンスごとのスナップショット数 -- 最古のスナップショットの存続期間：最も古い未公開のスナップショットが存続している期間 -- 各レベルのファイル数：各レベルにおける異なる列ファミリーのSSTファイルの数 -- SSTファイルの取り込み時間（秒）：SSTファイルの取り込みにかかる時間 -- 各CFの失速条件が変更されました：各カラムファミリーの失速条件が変更されました +- Get operations: 1秒あたりの取得操作の回数 +- Get duration：取得操作の実行に要した時間 +- Seek operations：1秒あたりのシーク操作回数 +- Seek duration：シーク操作の実行に要する時間 +- Write operations：1秒あたりの書き込み操作回数 +- Write duration：書き込み操作の実行に要する時間 +- WAL sync operations：1秒あたりのWAL同期操作の回数 +- Write WAL duration：WALの書き込みに要した時間 +- WAL sync duration：WAL同期操作の実行に要する時間 +- Compaction operations：1秒あたりの圧縮および洗浄作業の回数 +- Compaction duration：圧縮および洗浄作業の実行に要する時間 +- SST read duration：SSTファイルの読み込みに要する時間 +- Write stall duration: 停止時間を書き込む。通常の場合は`0`となるはずです。 +- Memtable size：各カラムファミリーのmemtableサイズ +- Memtable hit：memtableのヒット率 +- Block cache size：ブロックキャッシュのサイズ。共有ブロックキャッシュが無効になっている場合は、カラムファミリーごとに内訳が表示されます。 +- Block cache hit：ブロックキャッシュのヒット率 +- Block cache flow：タイプごとのブロックキャッシュ操作のフローレート +- Block cache operations: タイプごとのブロックキャッシュ操作の回数 +- Keys flow：キーの種類ごとの操作フローレート +- Total keys：各カラムファミリー内のキーの数 +- Read flow：タイプごとの読み取り操作のフローレート +- Bytes / Read：読み取り操作1回あたりのバイト数 +- Write flow：タイプごとの書き込み操作のフローレート +- Bytes / Write: 書き込み操作あたりのバイト数 +- Compaction flow：タイプ別の圧縮作業のフローレート +- Compaction pending bytes：圧縮対象となる保留バイト数 +- Compaction Job Size(files)：単一の圧縮ジョブに関係するSSTファイルの数 +- Read amplification: TiKVインスタンスごとのリード増幅率 +- Compression ratio：各レベルの圧縮率 +- Number of snapshots：TiKVインスタンスごとのスナップショット数 +- Oldest snapshots duration：最も古い未公開のスナップショットが存続している期間 +- Number files at each level：各レベルにおける異なる列ファミリーのSSTファイルの数 +- Ingest SST duration seconds：SSTファイルの取り込みにかかる時間 +- Stall conditions changed of each CF：各カラムファミリーの失速条件が変更されました ### Raft Engine {#raft-engine} -- 業務 +- Operations - write: Raft Engineによる1秒あたりの書き込み操作数 - read_entry: Raft Engineによる1秒あたりのRaftログ読み取り操作数 - read_message: Raft Engineによる1秒あたりのRaftメタデータ読み取り操作の数 -- 書き込み時間： Raft Engineによる書き込み操作にかかる時間。この時間は、これらのデータの書き込みに関わるディスクI/Oのレイテンシーの合計値にほぼ相当します。 -- 流れ +- Write duration： Raft Engineによる書き込み操作にかかる時間。この時間は、これらのデータの書き込みに関わるディスクI/Oのレイテンシーの合計値にほぼ相当します。 +- Flow - 書き込み: Raft Engineの書き込みトラフィック - リライト追加: リライト追加ログのトラフィック - リライト リライト: リライトのトラフィック リライトログ -- 書き込み時間の内訳（99％） +- Write Duration Breakdown (99%) - wal: Raft Engine WAL の書き込みレイテンシー - 待機: 書き始める前の待ち時間 - apply:メモリにデータを適用するのにかかる時間 -- バイト/書き込み: Raft Engineが毎回書き込むバイト数 -- WAL 所要時間の内訳 (P99%): Raft Engine WAL 作成の各段階に要した時間 -- ファイル数 +- Bytes/Written: Raft Engineが毎回書き込むバイト数 +- WAL Duration Breakdown (P99%): Raft Engine WAL 作成の各段階に要した時間 +- File Count - append: Raft Engineがデータ追加に使用するファイルの数 - rewrite: Raft Engineによるデータ書き換えに使用されるファイルの数（rewriteはRocksDBの圧縮に類似しています） -- エントリー数 +- Entry Count - rewrite: Raft Engineによって書き換えられたエントリの数 - append: Raft Engineによって追加されたエントリの数 -### Titan - すべて {#titan---all} - -- Blobファイル数：Titan Blobファイルの数 -- Blobファイルサイズ：Titan Blobファイルの合計サイズ -- ライブブロブサイズ：有効なブロブレコードの合計サイズ -- ブロブキャッシュヒット：Titanブロックキャッシュのヒット率 -- イテレータが触れたブロブファイルの数：単一のイテレータに関係するブロブファイルの数 -- Blobファイル破棄率分布：BLOBファイルのBLOBレコード障害率分布 -- ブロブキーのサイズ：Titanブロブキーのサイズ -- Blob値のサイズ：Titan Blob値のサイズ -- Blob取得操作: Titan Blobにおける取得操作の回数 -- Blob取得時間：Titan Blobで取得操作を実行する際に消費される時間 -- Blobイテレーション操作：Titan Blobでイテレーション操作を実行する際に消費される時間 -- ブロブシーク時間：Titanブロブでシーク操作を実行する際に消費される時間 -- Blob 次の実行時間: Titan Blob で次の操作を実行する際に消費される時間 +### Titan - All {#titan---all} + +- Blob file count：Titan Blobファイルの数 +- Blob file size：Titan Blobファイルの合計サイズ +- Live blob size：有効なブロブレコードの合計サイズ +- Blob cache hit：Titanブロックキャッシュのヒット率 +- Iter touched blob file count：単一のイテレータに関係するブロブファイルの数 +- Blob file discardable ratio distribution：BLOBファイルのBLOBレコード障害率分布 +- Blob key size：Titanブロブキーのサイズ +- Blob value size：Titan Blob値のサイズ +- Blob get operations: Titan Blobにおける取得操作の回数 +- Blob get duration：Titan Blobで取得操作を実行する際に消費される時間 +- Blob iter operations：Titan Blobでイテレーション操作を実行する際に消費される時間 +- Blob seek duration：Titanブロブでシーク操作を実行する際に消費される時間 +- Blob next duration: Titan Blob で次の操作を実行する際に消費される時間 - Blob prev duration: Titan blob で prev 操作を実行するのに要した時間 -- ブロブキーフロー：Titanブロブキーに対する操作のフローレート -- Blobバイトフロー：Titan Blobキー上のバイトフローレート -- Blobファイル読み取り時間：Titan Blobファイルの読み取りに要した時間 -- Blobファイル書き込み時間：Titan Blobファイルの書き込みに要した時間 -- ブロブファイル同期操作: ブロブファイル同期操作の回数 -- Blobファイル同期時間：Blobファイルの同期にかかる時間 -- Blob GCアクション：Titan GCアクションの回数 -- Blob GC 期間: Titan GC 期間 -- Blob GCキーフロー：Titan GCによって読み書きされるキーのフローレート -- Blob GC バイトフロー: Titan GC によって読み書きされるバイトのフローレート -- Blob GC入力ファイルサイズ：Titan GC入力ファイルのサイズ -- Blob GC出力ファイルサイズ：Titan GC出力ファイルのサイズ -- Blob GC ファイル数: Titan GC に関与する Blob ファイルの数 - -### インメモリエンジン {#in-memory-engine} +- Blob keys flow：Titanブロブキーに対する操作のフローレート +- Blob bytes flow：Titan Blobキー上のバイトフローレート +- Blob file read duration：Titan Blobファイルの読み取りに要した時間 +- Blob file write duration：Titan Blobファイルの書き込みに要した時間 +- Blob file sync operations: ブロブファイル同期操作の回数 +- Blob file sync duration：Blobファイルの同期にかかる時間 +- Blob GC action：Titan GCアクションの回数 +- Blob GC duration: Titan GC 期間 +- Blob GC keys flow：Titan GCによって読み書きされるキーのフローレート +- Blob GC bytes flow: Titan GC によって読み書きされるバイトのフローレート +- Blob GC input file size：Titan GC入力ファイルのサイズ +- Blob GC output file size：Titan GC出力ファイルのサイズ +- Blob GC file count: Titan GC に関与する Blob ファイルの数 + +### In Memory Engine {#in-memory-engine} 次のメトリクスは、 [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)(IME) に関連しています。 - Ops: 列ファミリーの1秒あたりの操作数 -- 読み取りMBps：RocksDBとインメモリエンジンにおける読み取りトラフィックの総バイト数 -- コプロセッサー処理時間：コプロセッサリクエストの処理に要する時間 -- リージョンキャッシュヒット数：リージョンキャッシュからデータが正常に取得された回数 -- リージョンキャッシュヒット率：リージョンキャッシュのヒット率 -- リージョンキャッシュミス理由：リージョンキャッシュからデータが取得されない理由 -- メモリ使用量：インメモリエンジンのメモリ使用量 -- リージョン数：異なる種類のリージョンの数 -- GCフィルタ：ガベージコレクション（GC）中のフィルタリングプロセスに関する情報 -- リージョンGCの所要時間：リージョンGCに要した時間 -- リージョン読み込み時間：リージョンの読み込みにかかる時間 -- リージョンロード数：1秒あたりにロードされるリージョンの数 -- リージョンエビクション期間：リージョンをエビクションするのにかかる時間 -- リージョンエビクション数：1秒あたりにエビクションされたリージョンの数 -- 書き込み時間：リージョンキャッシュエンジンでの書き込み操作にかかる時間 -- サーバーごとのインメモリエンジン書き込み時間（99%）：インメモリエンジンにおけるTiKVサーバーごとの書き込み時間の99パーセンタイル値 -- 書き込み準備時間：インメモリエンジンで書き込み操作を準備するのに要する時間 -- サーバーごとのインメモリエンジン書き込み準備時間（99%）：インメモリエンジンにおけるTiKVサーバーごとの書き込み操作準備に要した時間の99パーセンタイル値 -- イテレータ操作：イテレータ操作の種類数 -- シーク時間：シーク操作に要する時間 -- 最古の自動GCセーフポイント：メモリ内エンジンにキャッシュされたリージョンの最古の自動GCセーフポイント -- 最新の自動GCセーフポイント：メモリ内エンジンにキャッシュされたリージョン用の最新の自動GCセーフポイント -- 自動GCセーフポイントギャップ：インメモリエンジンにキャッシュされたリージョンについて、最新の自動GCセーフポイントと最も古い自動GCセーフポイントの間の時間差。 -- TiKV を使用した自動 GC セーフポイントのギャップ: インメモリエンジンにキャッシュされたリージョンについて、TiKV の自動 GC セーフポイントと最も古い自動 GC セーフポイントとの間のギャップ。 - -### 悲観的ロック {#pessimistic-locking} - -- ロックマネージャスレッドのCPU使用率：ロックマネージャスレッドのCPU使用率 -- ロックマネージャが処理したタスク数：ロックマネージャが処理したタスクの数 -- 待機時間の持続時間：トランザクションがロックを解除するまでの待機時間 -- 待機テーブル：待機テーブルの状態情報。ロックの数や、ロックを待っているトランザクションの数などが含まれます。 -- デッドロック検出時間：デッドロックを検出するのに要した時間 -- 検出エラー: デッドロック検出時に発生したエラーの数（デッドロックの数を含む） -- デッドロック検出リーダー: デッドロック検出リーダーが配置されているノードの情報 -- 合計悲観的ロックのメモリサイズ：メモリ内の悲観的ロックが占めるメモリサイズ -- インメモリ悲観的ロックの結果:悲観的ロックのみをメモリに保存した結果。 `full`は、メモリ制限を超えたために悲観的ロックがメモリに保存されなかった回数を意味します。 +- Read MBps：RocksDBとインメモリエンジンにおける読み取りトラフィックの総バイト数 +- Coprocessor Handle duration：コプロセッサリクエストの処理に要する時間 +- Region Cache Hit：リージョンキャッシュからデータが正常に取得された回数 +- Region Cache Hit Rate：リージョンキャッシュのヒット率 +- Region Cache Miss Reason：リージョンキャッシュからデータが取得されない理由 +- Memory Usage：インメモリエンジンのメモリ使用量 +- Region Count：異なる種類のリージョンの数 +- GC Filter：ガベージコレクション（GC）中のフィルタリングプロセスに関する情報 +- Region GC Duration：リージョンGCに要した時間 +- Region Load Duration：リージョンの読み込みにかかる時間 +- Region Load Count：1秒あたりにロードされるリージョンの数 +- Region Eviction Duration：リージョンをエビクションするのにかかる時間 +- Region Eviction Count：1秒あたりにエビクションされたリージョンの数 +- Write duration：リージョンキャッシュエンジンでの書き込み操作にかかる時間 +- 99% In-memory engine write duration per server：インメモリエンジンにおけるTiKVサーバーごとの書き込み時間の99パーセンタイル値 +- Prepare for write duration：インメモリエンジンで書き込み操作を準備するのに要する時間 +- 99% In-memory engine prepare for write duration per server：インメモリエンジンにおけるTiKVサーバーごとの書き込み操作準備に要した時間の99パーセンタイル値 +- Iterator operations：イテレータ操作の種類数 +- Seek duration：シーク操作に要する時間 +- Oldest Auto GC SafePoint：メモリ内エンジンにキャッシュされたリージョンの最古の自動GCセーフポイント +- Newest Auto GC SafePoint：メモリ内エンジンにキャッシュされたリージョン用の最新の自動GCセーフポイント +- Auto GC SafePoint Gap：インメモリエンジンにキャッシュされたリージョンについて、最新の自動GCセーフポイントと最も古い自動GCセーフポイントの間の時間差。 +- Auto GC SafePoint Gap With TiKV: インメモリエンジンにキャッシュされたリージョンについて、TiKV の自動 GC セーフポイントと最も古い自動 GC セーフポイントとの間のギャップ。 + +### Pessimistic Locking {#pessimistic-locking} + +- Lock Manager Thread CPU：ロックマネージャスレッドのCPU使用率 +- Lock Manager Handled tasks：ロックマネージャが処理したタスクの数 +- Waiter lifetime duration：トランザクションがロックを解除するまでの待機時間 +- Wait table：待機テーブルの状態情報。ロックの数や、ロックを待っているトランザクションの数などが含まれます。 +- Deadlock detect duration：デッドロックを検出するのに要した時間 +- Detect error: デッドロック検出時に発生したエラーの数（デッドロックの数を含む） +- Deadlock detector leader: デッドロック検出リーダーが配置されているノードの情報 +- Total pessimistic locks memory size：メモリ内の悲観的ロックが占めるメモリサイズ +- In-memory pessimistic locking result:悲観的ロックのみをメモリに保存した結果。 `full`は、メモリ制限を超えたために悲観的ロックがメモリに保存されなかった回数を意味します。 ### Resolved-TS {#resolved-ts} - Resolved-TS worker CPU：resolved-tsワーカースレッドのCPU使用率 -- Advance-TSワーカーCPU：Advance-TSワーカースレッドのCPU使用率 -- スキャンロックワーカーCPU：スキャンロックワーカースレッドのCPU使用率 -- resolved-tsの最大ギャップ：このTiKV内のすべてのアクティブ領域のresolved-tsと現在時刻との間の最大時間差 -- 安全時刻の最大差: この TiKV 内のすべてのアクティブな領域の安全時刻と現在時刻との間の最大時間差 +- Advance-TS worker CPU：Advance-TSワーカースレッドのCPU使用率 +- Scan lock worker CPU：スキャンロックワーカースレッドのCPU使用率 +- Max gap of resolved-ts：このTiKV内のすべてのアクティブ領域のresolved-tsと現在時刻との間の最大時間差 +- Max gap of safe-ts: この TiKV 内のすべてのアクティブな領域の安全時刻と現在時刻との間の最大時間差 - Min Resolved TS Region：resolved-tsが最小であるリージョンのID - Min Safe TS Region：safe-tsが最小であるリージョンのID -- Leader処理時間：リーダーリクエストの処理に費やされた時間の分布。処理時間は、リクエストの送信からリーダーでの応答の受信までの時間です。 -- リージョンリーダーにおけるresolved-tsの最大ギャップ：このTiKV内のすべてのアクティブなリージョンのresolved-tsと現在時刻との間の最大時間差（リージョンリーダーのみ）。 +- Check Leader Duration：リーダーリクエストの処理に費やされた時間の分布。処理時間は、リクエストの送信からリーダーでの応答の受信までの時間です。 +- Max gap of resolved-ts in Region leaders：このTiKV内のすべてのアクティブなリージョンのresolved-tsと現在時刻との間の最大時間差（リージョンリーダーのみ）。 - Min Leader Resolved TS Region：resolved-tsが最小値であるリージョンのID（リージョンリーダーのみ）。 -- ロックヒープサイズ： resolved-tsモジュールでロックを追跡するヒープのサイズ +- Lock heap size： resolved-tsモジュールでロックを追跡するヒープのサイズ -### メモリ {#memory} +### Memory {#memory} -- アロケータ統計:メモリ割り当ての統計情報 +- Allocator Stats:メモリ割り当ての統計情報 -### バックアップ {#backup} +### Backup {#backup} -- バックアップCPU：バックアップスレッドのCPU使用率 -- 範囲サイズ：バックアップ範囲サイズのヒストグラム -- バックアップ時間：バックアップにかかる時間 -- バックアップフロー：バックアップの合計バイト数 -- ディスクスループット：インスタンスあたりのディスクスループット -- バックアップ範囲の所要時間：範囲のバックアップにかかる時間 -- バックアップエラー：バックアップ中に発生したエラーの数 +- Backup CPU：バックアップスレッドのCPU使用率 +- Range Size：バックアップ範囲サイズのヒストグラム +- Backup Duration：バックアップにかかる時間 +- Backup Flow：バックアップの合計バイト数 +- Disk Throughput：インスタンスあたりのディスクスループット +- Backup Range Duration：範囲のバックアップにかかる時間 +- Backup Errors：バックアップ中に発生したエラーの数 -### 暗号化 {#encryption} +### Encryption {#encryption} -- 暗号化データキー：暗号化されたデータキーの総数 -- 暗号化されたファイル：暗号化されたファイルの数 -- 暗号化が初期化されました: 暗号化が有効になっているかどうかを示します。 `1`は有効であることを意味します。 -- 暗号化メタファイルのサイズ：暗号化メタファイルのサイズ -- データの暗号化/復号化ナノ秒：データの暗号化/復号化にかかる時間のヒストグラム -- 暗号化メタファイルの読み書きにかかる時間：暗号化メタファイルの読み書きに要する時間 +- Encryption data keys：暗号化されたデータキーの総数 +- Encrypted files：暗号化されたファイルの数 +- Encryption initialized: 暗号化が有効になっているかどうかを示します。 `1`は有効であることを意味します。 +- Encryption meta files size：暗号化メタファイルのサイズ +- Encrypt/decrypt data nanos：データの暗号化/復号化にかかる時間のヒストグラム +- Read/write encryption meta duration：暗号化メタファイルの読み書きに要する時間 -### ログバックアップ {#log-backup} +### Log Backup {#log-backup} -- イベント処理速度：書き込みイベントの処理速度 -- 初期スキャン生成イベントスループット：新しいリスナーストリームを生成する際の、段階的なスキャン速度 +- Handle Event Rate：書き込みイベントの処理速度 +- Initial Scan Generate Event Throughput：新しいリスナーストリームを生成する際の、段階的なスキャン速度 - Abnormal Checkpoint TS Lag：各タスクの現在のcheckpoint TSと現在時刻とのラグ -- イベントメモリ：増分スキャンによって生成された一時データが占めるメモリの推定量 -- 観測されたリージョン数：現在視聴されているリージョンの数 -- エラー：再試行可能なエラーおよび致命的ではないエラーの数と種類 -- 致命的なエラー：発生した致命的なエラーの数と種類。通常、致命的なエラーが発生すると、タスクは一時停止します。 +- Memory Of Events：増分スキャンによって生成された一時データが占めるメモリの推定量 +- Observed Region Count：現在視聴されているリージョンの数 +- Errors：再試行可能なエラーおよび致命的ではないエラーの数と種類 +- Fatal Errors：発生した致命的なエラーの数と種類。通常、致命的なエラーが発生すると、タスクは一時停止します。 - Checkpoint TS of Tasks：各タスクのCheckpoint TS -- フラッシュ時間：キャッシュされたデータを外部ストレージに移動するのにかかる時間を示すヒートマップ -- 初期スキャン時間：新しいリスニングストリームを作成する際の増分スキャンにかかる時間を示すヒートマップ -- Raftイベント変換時間：リスニングストリームを作成した後、 Raftログエントリをバックアップデータに変換するのにかかる時間を示すヒートマップ -- コマンドバッチサイズ：リスニング中のRaftコマンドのバッチサイズ（単一のRaftグループ内） -- 一時ファイルへの保存時間：バックアップデータのバッチ（複数のタスクにまたがる）を一時ファイル領域に一時的に保存するのにかかる時間を示すヒートマップ -- 一時ファイルへの書き込み時間：特定のタスクからのバックアップデータのバッチを一時ファイル領域に一時的に保存するのにかかる時間を示すヒートマップ -- システム書き込み呼び出し時間：リージョンからバックアップデータのバッチを一時ファイルに書き込むのにかかる時間を示すヒートマップ -- 内部メッセージタイプ：TiKV内でログバックアップを担当するアクターが受信するメッセージの種類 -- 内部メッセージ処理時間（P90|P99）：各タイプのメッセージの消費および処理速度 -- RocksDBの初期スキャンスループット：増分スキャン中にRocksDB内部ログによって生成される読み取りトラフィック -- 初期スキャン RocksDB 操作: 増分スキャン中に RocksDB が内部的にログに記録した個々の操作の数 -- 初期スキャン開始理由：増分スキャンを開始する理由 -- リージョンチェックポイントキーの配置: PDに記録されたチェックポイント操作の数 +- Flush Duration：キャッシュされたデータを外部ストレージに移動するのにかかる時間を示すヒートマップ +- Initial Scanning Duration：新しいリスニングストリームを作成する際の増分スキャンにかかる時間を示すヒートマップ +- Convert Raft Event Duration：リスニングストリームを作成した後、 Raftログエントリをバックアップデータに変換するのにかかる時間を示すヒートマップ +- Command Batch Size：リスニング中のRaftコマンドのバッチサイズ（単一のRaftグループ内） +- Save to Temp File Duration：バックアップデータのバッチ（複数のタスクにまたがる）を一時ファイル領域に一時的に保存するのにかかる時間を示すヒートマップ +- Write to Temp File Duration：特定のタスクからのバックアップデータのバッチを一時ファイル領域に一時的に保存するのにかかる時間を示すヒートマップ +- System Write Call Duration：リージョンからバックアップデータのバッチを一時ファイルに書き込むのにかかる時間を示すヒートマップ +- Internal Message Type：TiKV内でログバックアップを担当するアクターが受信するメッセージの種類 +- Internal Message Handling Duration (P90|P99)：各タイプのメッセージの消費および処理速度 +- Initial Scan RocksDB Throughput：増分スキャン中にRocksDB内部ログによって生成される読み取りトラフィック +- Initial Scan RocksDB Operation: 増分スキャン中に RocksDB が内部的にログに記録した個々の操作の数 +- Initial Scanning Trigger Reason：増分スキャンを開始する理由 +- Region Checkpoint Key Putting: PDに記録されたチェックポイント操作の数 > **Note:** > -> 以下の監視メトリクスはすべてTiDBノードをデータソースとして使用しますが、ログバックアッププロセスに多少の影響を与えます。そのため、参照しやすいように**TiKVの詳細**ダッシュボードに配置されています。TiKVはほとんどの場合、進捗状況を積極的にプッシュしますが、以下の監視メトリクスの一部でサンプリングされたデータが一時的に取得されないのは正常な動作です。 - -- リクエストチェックポイントバッチサイズ：ログバックアップコーディネーターが各TiKVのチェックポイント情報をリクエストする際のリクエストバッチサイズ -- ティック期間 [P99|P90]: コーディネーター内のティックにかかる時間 -- リージョンチェックポイント失敗理由：リージョンチェックポイントがコーディネーター内で進行できない理由 -- リクエスト結果：コーディネーターがリージョンチェックポイントを前進させた際の成功または失敗の記録 -- リージョンオペレーション回数の取得：コーディネーターがPDからリージョン情報をリクエストした回数 -- アドバンストリガー時間：コーディネーターがチェックポイントを進めることを試みるまでにかかる時間 - -### バックアップとインポート {#backup--import} - -- インポート時のCPU使用率：SSTインポーターによって集計されたCPU使用率。 -- インポートスレッド数：SSTインポーターが使用するスレッドの数。 -- インポートエラー：SSTインポート中に発生したエラーの数。 -- インポートRPC実行時間：SSTインポーターにおける様々なRPC呼び出しに費やされた時間。 -- インポートRPC操作：SSTインポーターにおけるRPC呼び出しの総数。 -- インポートRPCカウント：SSTインポーターによって処理されているRPC呼び出しの数。 -- インポート書き込み/ダウンロードRPC時間：SSTインポーターにおける書き込みまたはダウンロード操作のRPC時間。 -- インポート待機時間：ダウンロードタスクの実行待ち時間。 -- SSTファイルのインポート読み込み時間：外部ストレージからSSTファイルを読み込み、TiKVにダウンロードするのに要した時間。 -- インポート書き換えSST時間：書き換えルールに基づいてSSTファイルを書き換えるのに要した時間。 -- インポート取り込みRPC処理時間：TiKV上で取り込みRPCリクエストを処理するのに費やされた時間。 -- SSTファイルのインポート取り込み時間：SSTファイルをRocksDBに取り込むのに要した時間。 -- インポート取り込みSSTバイト数：取り込まれたバイト数。 -- インポートダウンロードSSTスループット：SSTのダウンロードスループット（バイト/秒）。 -- クラウドリクエスト：クラウドプロバイダーへのリクエスト数。 - -### 特定時点復元 {#point-in-time-restore} - -- CPU使用率：ポイントインタイムリカバリ（PITR）によるCPU使用率。 -- P99 RPC期間：RPCリクエスト期間の99パーセンタイル値。 -- インポートRPC操作：SSTインポーターにおけるRPC呼び出しの総数。 -- インポートRPCカウント：SSTインポーターによって処理されているRPC呼び出しの数。 -- キャッシュイベント：SSTインポート中にファイルキャッシュに保存されたイベントの数。 -- RPC全体の実行時間：RPC呼び出しに費やされた時間。 -- ファイルをメモリに読み込む時間: 外部ストレージからファイルをダウンロードしてメモリに読み込むのにかかる時間。 -- キューイング時間：スレッドにスケジュールされるのを待つ時間。 -- リクエスト処理スループット：リクエストを適用する速度（バイト単位）。 -- ダウンロードされたファイルのサイズ：ダウンロードされたファイルのサイズ（バイト単位）。 -- 適用バッチサイズ：1回のバッチでRaftストアに適用するバイト数。 -- 並行処理によるブロック時間：並行処理の制約により実行を待機するのに費やされた時間。 -- リクエスト適用速度： Raftストアへのリクエスト適用速度。 -- メモリにキャッシュされたファイル：SSTインポーターのリクエストによってキャッシュされたファイル。 -- エンジンリクエスト未完了: Raftストアへの保留中のリクエスト数。 -- 適用時間： Raftストアにデータを書き込むのに費やされた時間。 -- Raftストアのメモリ使用量： Raftストアのメモリ使用量。 +> 以下の監視メトリクスはすべてTiDBノードをデータソースとして使用しますが、ログバックアッププロセスに多少の影響を与えます。そのため、参照しやすいように**TiKV Details**ダッシュボードに配置されています。TiKVはほとんどの場合、進捗状況を積極的にプッシュしますが、以下の監視メトリクスの一部でサンプリングされたデータが一時的に取得されないのは正常な動作です。 + +- Request Checkpoint Batch Size：ログバックアップコーディネーターが各TiKVのチェックポイント情報をリクエストする際のリクエストバッチサイズ +- Tick Duration \[P99|P90\]: コーディネーター内のティックにかかる時間 +- Region Checkpoint Failure Reason：リージョンチェックポイントがコーディネーター内で進行できない理由 +- Request Result：コーディネーターがリージョンチェックポイントを前進させた際の成功または失敗の記録 +- Get Region Operation Count：コーディネーターがPDからリージョン情報をリクエストした回数 +- Try Advance Trigger Time：コーディネーターがチェックポイントを進めることを試みるまでにかかる時間 + +### Backup & Import {#backup--import} + +- Import CPU Utilization：SSTインポーターによって集計されたCPU使用率。 +- Import Thread Count：SSTインポーターが使用するスレッドの数。 +- Import Errors：SSTインポート中に発生したエラーの数。 +- Import RPC Duration：SSTインポーターにおける様々なRPC呼び出しに費やされた時間。 +- Import RPC Ops：SSTインポーターにおけるRPC呼び出しの総数。 +- Import RPC Count：SSTインポーターによって処理されているRPC呼び出しの数。 +- Import Write/Download RPC Duration：SSTインポーターにおける書き込みまたはダウンロード操作のRPC時間。 +- Import Wait Duration：ダウンロードタスクの実行待ち時間。 +- Import Read SST Duration：外部ストレージからSSTファイルを読み込み、TiKVにダウンロードするのに要した時間。 +- Import Rewrite SST Duration：書き換えルールに基づいてSSTファイルを書き換えるのに要した時間。 +- Import Ingest RPC Duration：TiKV上で取り込みRPCリクエストを処理するのに費やされた時間。 +- Import Ingest SST Duration：SSTファイルをRocksDBに取り込むのに要した時間。 +- Import Ingest SST Bytes：取り込まれたバイト数。 +- Import Download SST Throughput：SSTのダウンロードスループット（バイト/秒）。 +- cloud request：クラウドプロバイダーへのリクエスト数。 + +### Point In Time Restore {#point-in-time-restore} + +- CPU Usage：ポイントインタイムリカバリ（PITR）によるCPU使用率。 +- P99 RPC Duration：RPCリクエスト期間の99パーセンタイル値。 +- Import RPC Ops：SSTインポーターにおけるRPC呼び出しの総数。 +- Import RPC Count：SSTインポーターによって処理されているRPC呼び出しの数。 +- Cache Events：SSTインポート中にファイルキャッシュに保存されたイベントの数。 +- Overall RPC Duration：RPC呼び出しに費やされた時間。 +- Read File into Memory Duration: 外部ストレージからファイルをダウンロードしてメモリに読み込むのにかかる時間。 +- Queuing Time：スレッドにスケジュールされるのを待つ時間。 +- Apply Request Throughput：リクエストを適用する速度（バイト単位）。 +- Downloaded File Size：ダウンロードされたファイルのサイズ（バイト単位）。 +- Apply Batch Size：1回のバッチでRaftストアに適用するバイト数。 +- Blocked by Concurrency Time：並行処理の制約により実行を待機するのに費やされた時間。 +- Apply Request Speed： Raftストアへのリクエスト適用速度。 +- Cached File in Memory：SSTインポーターのリクエストによってキャッシュされたファイル。 +- Engine Requests Unfinished: Raftストアへの保留中のリクエスト数。 +- Apply Time： Raftストアにデータを書き込むのに費やされた時間。 +- Raft Store Memory Usage： Raftストアのメモリ使用量。 ### 共通パラメータの説明 {#explanation-of-common-parameters} -#### gRPCメッセージタイプ {#grpc-message-type} +#### gRPC Message Type {#grpc-message-type} 1. トランザクションAPI： @@ -601,7 +601,7 @@ TiKVのパフォーマンスに関する問題（QPSジッター、レイテン 書き込み関連のパフォーマンス問題が発生した場合は、まずTiDB関連のダッシュボードを確認してください。ストレージ側に問題がある場合は、 **TiKV-FastTune**ページを開き、すべてのパネルを確認してください。 -**TiKV-FastTuneの**ダッシュボードには、パフォーマンス問題の考えられる原因を示すタイトルが表示されます。提示された原因が正しいかどうかを確認するには、ページ上のグラフを確認してください。 +**TiKV-FastTune**のダッシュボードには、パフォーマンス問題の考えられる原因を示すタイトルが表示されます。提示された原因が正しいかどうかを確認するには、ページ上のグラフを確認してください。 グラフの左側のY軸はストレージ側の書き込みRPC QPSを表し、右側のY軸上のグラフは上下反転して描かれています。左側のグラフの形状が右側のグラフの形状と一致する場合、示唆された原因は正しいと言えます。 diff --git a/releases/release-3.0.8.md b/releases/release-3.0.8.md index 65f3001ffb5a7..03e8333c65e9b 100644 --- a/releases/release-3.0.8.md +++ b/releases/release-3.0.8.md @@ -109,4 +109,4 @@ TiDB Ansible バージョン: 3.0.8 - ローリングアップデートを実行する際にTiDBのバージョンをチェックするロジックを最適化します[#1056](https://github.com/pingcap/tidb-ansible/pull/1056) - TiSparkをv2.1.8にアップグレード[#1061](https://github.com/pingcap/tidb-ansible/pull/1061) - Grafana で PD ロール監視項目が誤って表示される問題を修正 [#1065](https://github.com/pingcap/tidb-ansible/pull/1065) -- Grafana のTiKV-Detailsページで監視項目`Thread Voluntary Context Switches`と`Thread Nonvoluntary Context Switches`最適化 [#1071](https://github.com/pingcap/tidb-ansible/pull/1071) +- Grafana のTiKV-Detailsページで監視項目`Thread Voluntary Context Switches`と`Thread Nonvoluntary Context Switches`を最適化 [#1071](https://github.com/pingcap/tidb-ansible/pull/1071) diff --git a/releases/release-4.0.13.md b/releases/release-4.0.13.md index c131186d6fbf8..77b4056e34eed 100644 --- a/releases/release-4.0.13.md +++ b/releases/release-4.0.13.md @@ -96,7 +96,7 @@ TiDB バージョン: 4.0.13 - 問題を修正: 以前のバージョンのクラスターで、変数`tidb_enable_table_partition` `false`に設定されている場合、パーティションを含むテーブルは非パーティションテーブルとして扱われます。クラスターを新しいバージョンにアップグレードした後、このテーブルに対して`batch point get`クエリを実行すると、接続panicが発生します[#23682](https://github.com/pingcap/tidb/pull/23682) - TiDB が TCP および UNIX ソケットを listen するように構成されている場合、TCP 接続経由のリモートホストが接続に対して正しく検証されない問題を修正しました。 [#23513](https://github.com/pingcap/tidb/pull/23513) - デフォルト以外の照合順序で間違ったクエリ結果が発生するバグを修正[#22923](https://github.com/pingcap/tidb/pull/22923) - - Grafanaの**コプロセッサー Cache**パネルが動作しないバグを修正[#22617](https://github.com/pingcap/tidb/pull/22617) + - Grafanaの**Coprocessor Cache**パネルが動作しないバグを修正[#22617](https://github.com/pingcap/tidb/pull/22617) - オプティマイザが統計キャッシュアクセスする際に発生するエラーを修正 [#22565](https://github.com/pingcap/tidb/pull/22565) - TiKV diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index 2c43abb3a49d4..3ff8912f4b2e5 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -30,7 +30,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - TiCDC - - resolved TSをバッチで処理することにより、リージョンワーカーのパフォーマンスを向上させます。 [#7078](https://github.com/pingcap/tiflow/issues/7078) @[sdojjy](https://github.com/sdojjy) + - Resolved TSをバッチで処理することにより、リージョンワーカーのパフォーマンスを向上させます。 [#7078](https://github.com/pingcap/tiflow/issues/7078) @[sdojjy](https://github.com/sdojjy) ## バグ修正 {#bug-fixes} diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 2e2c4ca785e32..e0a732a0aa70e 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -252,7 +252,7 @@ TiDBバージョン：8.3.0 - PD - `pd-ctl`を介して`evict-leader-scheduler`の`batch`構成を変更してリーダー退去プロセスを加速するサポート [#8265](https://github.com/tikv/pd/issues/8265) @[rleungx](https://github.com/rleungx) - - Grafana の**クラスタ > Label 配信**パネルに`store_id`モニタリングメトリックを追加して、異なるラベルに対応するストア ID を表示します [#8337](https://github.com/tikv/pd/issues/8337) @[HuSharp](https://github.com/HuSharp) + - Grafana の**Cluster > Label distribution**パネルに`store_id`モニタリングメトリックを追加して、異なるラベルに対応するストア ID を表示します [#8337](https://github.com/tikv/pd/issues/8337) @[HuSharp](https://github.com/HuSharp) - 指定されたリソースグループが存在しない場合、デフォルトのリソースグループへのフォールバックをサポートする [#8388](https://github.com/tikv/pd/issues/8388) @[JmPotato](https://github.com/JmPotato) - `pd-ctl`の`region`コマンドが出力するリージョン情報に`approximate_kv_size`フィールドを追加します。 [#8412](https://github.com/tikv/pd/issues/8412) @[zeminzhou](https://github.com/zeminzhou) - PD APIを呼び出してTTL設定を削除したときに返されるメッセージを最適化します [#8450](https://github.com/tikv/pd/issues/8450) @[lhy1024](https://github.com/lhy1024) diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index 15978a40cc61f..4c3cc5951d1b4 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -51,7 +51,7 @@ TiDBバージョン：8.5.4 - パフォーマンス、拡張性、安定性を向上させるための新しいTiCDCアーキテクチャオプションを導入 [#442](https://github.com/pingcap/ticdc/issues/442) @[CharlesCheung96](https://github.com/CharlesCheung96) - この新しいアーキテクチャは[従来のTiCDCアーキテクチャ](/ticdc/ticdc-classic-architecture.md)アーキテクチャの構成、使用法、API との互換性を維持しながら、TiCDC コア コンポーネントを再設計し、そのデータ処理ワークフローを最適化します。 + この新しいアーキテクチャは[TiCDCクラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)の構成、使用法、API との互換性を維持しながら、TiCDC コア コンポーネントを再設計し、そのデータ処理ワークフローを最適化します。 この新しいアーキテクチャを使用するように構成すると、TiCDC はほぼ線形のスケーラビリティを実現し、より低いリソース消費で数百万のテーブルを複製できます。また、変更フィードのレイテンシーを削減し、書き込みワークロードが高いシナリオ、頻繁な DDL 操作、クラスタのスケーリングにおいて、より安定したパフォーマンスを提供します。なお、この新しいアーキテクチャには現在、いくつか[初期の制約](https://docs.pingcap.com/tidb/v8.5/ticdc-architecture#limitations)があります。 @@ -102,7 +102,7 @@ TiDBバージョン：8.5.4 - 一意の値の数が少ない列（NDV）のクエリ推定ロジックを最適化する [#61792](https://github.com/pingcap/tidb/issues/61792) @[terry1purcell](https://github.com/terry1purcell) - `LIMIT OFFSET`を含む Index Join クエリの推定戦略を最適化する [#45077](https://github.com/pingcap/tidb/issues/45077) @[qw4990](https://github.com/qw4990) - 統計情報が時間内に収集されない場合の範囲外推定戦略を最適化する [#58068](https://github.com/pingcap/tidb/issues/58068) @[terry1purcell](https://github.com/terry1purcell) - - Grafana の**パフォーマンス概要**> **SQL 実行時間概要**パネルに`backoff`メトリックを追加してデバッグを容易にします [#61441](https://github.com/pingcap/tidb/issues/61441) @[dbsid](https://github.com/dbsid) + - Grafana の**Performance Overview** > **SQL Execute Time Overview**パネルに`backoff`メトリックを追加してデバッグを容易にします [#61441](https://github.com/pingcap/tidb/issues/61441) @[dbsid](https://github.com/dbsid) - 監査ログ プラグインにステートメント ID 情報を追加 [#63525](https://github.com/pingcap/tidb/issues/63525) @[YangKeao](https://github.com/YangKeao) - TiKV diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 093d72250a90e..13db82be1042c 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -195,7 +195,7 @@ LIMIT 10; > > Golangのメモリ回収メカニズムと一部の非カウントメモリ構造のため、Grafanaに表示されるメモリは実際のヒープメモリ使用量と一致しません。Grafanaに表示されるメモリと実際のヒープメモリ使用量の間には、約±20%の誤差があることがテストで確認されています。 -各 TiDB インスタンスにキャッシュされている実行計画の合計数を表示するには、Grafana の[**プランキャッシュプラン番号**パネル](/grafana-tidb-dashboard.md)を使用できます。 +各 TiDB インスタンスにキャッシュされている実行計画の合計数を表示するには、Grafana の[**Plan Cache Plan Num**パネル](/grafana-tidb-dashboard.md)を使用できます。 以下は、Grafana の**Plan Cache Memory Usage**パネルと**Plan Cache Plan Num**パネルの例です。 diff --git a/system-variables.md b/system-variables.md index 18da1fd08ed6b..86cc7e991690c 100644 --- a/system-variables.md +++ b/system-variables.md @@ -6554,8 +6554,8 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - PDにおけるTSOの割り当ては、まだボトルネックに達していません。 - PDノードとTiDBノードは十分なCPUリソースを備えている。 - TiDBとPD間のネットワークレイテンシーは、PDがTSOを割り当てるのにかかる時間よりもかなり長い（つまり、TSO RPCの実行時間の大部分はネットワークレイテンシーによるものである）。 - - TSO RPCリクエストの所要時間を取得するには、Grafana TiDBダッシュボードのPDクライアントセクションにある**PD TSO RPC所要時間**パネルを確認してください。 - - PD TSO割り当ての期間を確認するには、Grafana PDダッシュボードのTiDBセクションにある**PDサーバーTSOハンドル期間**パネルを確認してください。 + - TSO RPCリクエストの所要時間を取得するには、Grafana TiDBダッシュボードのPDクライアントセクションにある**PD TSO RPC Duration**パネルを確認してください。 + - PD TSO割り当ての期間を確認するには、Grafana PDダッシュボードのTiDBセクションにある**PD server TSO handle duration**パネルを確認してください。 - TiDBとPD間のTSO RPCリクエストの増加（ `PARALLEL`の場合は2倍、 `PARALLEL-FAST`の場合は4倍）によって生じる追加のネットワークトラフィックは許容範囲内です。 > **Note:** diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index 0270ca06bbc55..95fdcf797d242 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -31,11 +31,11 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro TiCDC の新しいアーキテクチャの監視ダッシュボードには、主に次のセクションが含まれます。 -- [**Summary**](#summary) : TiCDCクラスターの概要情報 -- [**Server**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 -- [**Log Puller**](#log-puller) : TiCDC Log Pullerモジュールの詳細情報 -- [**Event Store**](#event-store) : TiCDCイベントストアモジュールの詳細情報 -- [**Sink**](#sink) : TiCDCシンクモジュールの詳細情報 +- [**Summary**](#summary): TiCDCクラスターの概要情報 +- [**Server**](#server): TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**Log Puller**](#log-puller): TiCDC Log Pullerモジュールの詳細情報 +- [**Event Store**](#event-store): TiCDCイベントストアモジュールの詳細情報 +- [**Sink**](#sink): TiCDCシンクモジュールの詳細情報 ### Summary {#summary} @@ -127,14 +127,14 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 ## クラシックアーキテクチャにおける TiCDC のメトリクス {#metrics-for-ticdc-in-the-classic-architecture} -TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同時にデプロイされる TiCDC のサブダッシュボードが Grafana の[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)に表示されます。 +TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同時にデプロイされる TiCDC のサブダッシュボードが Grafana の[クラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)に表示されます。 各パネルの説明は次のとおりです。 -- [**Server**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 -- [**Changefeed**](#changefeed) : TiCDCレプリケーションタスクの詳細情報 -- [**Events**](#events) : TiCDCクラスタ内のデータフローに関する詳細情報 -- [**TiKV**](#tikv) : TiCDCに関連するTiKV情報 +- [**Server**](#server): TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**Changefeed**](#changefeed): TiCDCレプリケーションタスクの詳細情報 +- [**Events**](#events): TiCDCクラスタ内のデータフローに関する詳細情報 +- [**TiKV**](#tikv): TiCDCに関連するTiKV情報 ### Server {#server} @@ -196,9 +196,9 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 - Event size percentile: TiCDCがTiKVから1秒以内に受信するイベントサイズ（P95、P99、P999） - Eventfeed error/m: TiCDCノードのイベントフィードRPCリクエストによって1分あたりに報告されたエラーの数 - KV client receive events/s: TiCDCノードのKVクライアントモジュールがTiKVから1秒あたりに受信するイベント数 -- Puller receive events/s: TiCDCノードのプラーモジュールがKVクライアントから1秒あたりに受信するイベント数 -- Puller output events/s: TiCDCノードのプラーモジュールがソーターモジュールに送信するイベント数/秒 -- Sink flush rows/s: TiCDCノードが1秒あたりにダウンストリームに書き込むイベント数 +- Puller receive events/s: TiCDCノードのPullerモジュールがKVクライアントから1秒あたりに受信するイベント数 +- Puller output events/s: TiCDCノードのPullerモジュールがソーターモジュールに送信するイベント数/秒 +- Sink flush rows/s: TiCDCノードが1秒あたりにダウンストリームに書き込む行数 - Puller buffer size: TiCDCノードがプラーモジュールにキャッシュするイベントの数 - Entry sorter buffer size: TiCDCノードがソーターモジュールにキャッシュするイベントの数 - Processor/Mounter buffer size: TiCDCノードがプロセッサモジュールとマウントモジュールにキャッシュするイベントの数 @@ -209,7 +209,7 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 - Entry sorter merge duration percentile: TiCDCがソートされたイベントを1秒以内にマージするのにかかる時間(P95、P99、P999) - Mounter unmarshal duration: TiCDCノードがイベントをアンマーシャリングするのにかかった時間のヒストグラム - Mounter unmarshal duration percentile: TiCDC アンマーシャリング イベントが 1秒間に要した時間 (P95、P99、および P999) -- KV client dispatch events/s: KVクライアントモジュールがTiCDCノード間でディスパッチするイベント数 +- KV client dispatch events/s: KVクライアントモジュールがTiCDCノード間で1秒あたりにディスパッチするイベント数 - KV client batch resolved size: TiKVがTiCDCに送信する解決済みタイムスタンプメッセージのバッチサイズ ### TiKV {#tikv} diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 11a8190355fb3..1a2f76af646f3 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -7,14 +7,14 @@ summary: TiCDCの新しいアーキテクチャの機能、アーキテクチャ [TiCDC v8.5.4-release.1](https://github.com/pingcap/ticdc/releases/tag/v8.5.4-release.1)以降、TiCDCは、リアルタイムデータレプリケーションのパフォーマンス、拡張性、安定性を向上させつつ、リソースコストを削減する新しいアーキテクチャを導入しました。 -この新しいアーキテクチャは[従来のTiCDCアーキテクチャ](/ticdc/ticdc-classic-architecture.md)アーキテクチャの構成、使用法、API との互換性を維持しながら、TiCDC コア コンポーネントを再設計し、そのデータ処理ワークフローを最適化します。これには次のような利点があります。 +この新しいアーキテクチャは[TiCDCクラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)の構成、使用法、API との互換性を維持しながら、TiCDC コア コンポーネントを再設計し、そのデータ処理ワークフローを最適化します。これには次のような利点があります。 - **シングルノードのパフォーマンス向上**：シングルノードで最大50万個のテーブルを複製でき、テーブル数の多いシナリオではシングルノードで最大190 MiB/sの複製スループットを実現します。 - **拡張性の向上**：クラスタレプリケーション機能はほぼ線形に拡張可能です。単一のクラスタは100ノード以上に拡張でき、10,000を超えるチェンジフィードをサポートし、単一のチェンジフィード内で数百万のテーブルをレプリケートできます。 - **安定性の向上**：トラフィック量が多く、DDL操作が頻繁に発生し、クラスタのスケーリングイベントが発生するシナリオにおいて、変更フィードのレイテンシーが短縮され、パフォーマンスがより安定します。リソースの分離と優先度スケジューリングにより、複数の変更フィードタスク間の干渉が軽減されます。 - **リソースコストの削減**：リソース利用率の向上と冗長性の削減により、一般的なシナリオではCPUとメモリのリソース使用量を最大50%削減できます。 -## 建築設計 {#architectural-design} +## アーキテクチャ設計 {#architectural-design} ![TiCDC New Architecture](/media/ticdc/ticdc-new-arch-1.png) @@ -25,9 +25,9 @@ TiCDCの新しいアーキテクチャは、ログサービスとダウンスト TiCDCの新しいアーキテクチャは、アーキテクチャをステートフルコンポーネントとステートレスコンポーネントに分離することで、システムの拡張性、信頼性、柔軟性を大幅に向上させています。ステートフルコンポーネントであるログサービスは、データの取得、ソート、およびストレージに重点を置いています。これを変更フィード処理ロジックから分離することで、複数の変更フィード間でデータを共有できるようになり、リソース利用率を効果的に向上させ、システムオーバーヘッドを削減できます。ステートレスコンポーネントであるダウンストリームアダプタは、インスタンス間でレプリケーションタスクを迅速に移行できる軽量スケジューリングメカニズムを使用しています。ワークロードの変化に基づいてレプリケーションタスクの分割とマージを動的に調整できるため、さまざまなシナリオで低遅延のレプリケーションが保証されます。 -## 古典的建築と新建築の比較 {#comparison-between-the-classic-and-new-architectures} +## クラシックアーキテクチャと新しいアーキテクチャの比較 {#comparison-between-the-classic-and-new-architectures} -新しいアーキテクチャは、継続的なシステム拡張時に発生するパフォーマンスのボトルネック、安定性の不足、拡張性の制限といった一般的な問題に対処するように設計されています。[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)と比較して、新しいアーキテクチャは以下の主要な側面で大幅な最適化を実現しています。 +新しいアーキテクチャは、継続的なシステム拡張時に発生するパフォーマンスのボトルネック、安定性の不足、拡張性の制限といった一般的な問題に対処するように設計されています。[クラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)と比較して、新しいアーキテクチャは以下の主要な側面で大幅な最適化を実現しています。 | 特徴 | TiCDCクラシックアーキテクチャ | TiCDCの新アーキテクチャ | | ----------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | @@ -43,9 +43,9 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート ![Comparison between the TiCDC classic and new architectures](/media/ticdc/ticdc-new-arch-2.png) -## クラシックな建築様式と新しい建築様式からお選びください。 {#choose-between-the-classic-and-new-architectures} +## クラシックアーキテクチャと新しいアーキテクチャからお選びください。 {#choose-between-the-classic-and-new-architectures} -ワークロードが次のいずれかの条件を満たす場合は、パフォーマンスと安定性を向上させるために、[従来のTiCDCアーキテクチャ](/ticdc/ticdc-classic-architecture.md)から新しいアーキテクチャに切り替えることをお勧めします。 +ワークロードが次のいずれかの条件を満たす場合は、パフォーマンスと安定性を向上させるために、[TiCDCクラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)から新しいアーキテクチャに切り替えることをお勧めします。 - 増分スキャンパフォーマンスのボトルネック: 増分スキャンタスクの完了に過度に時間がかかり、レプリケーションのレイテンシーが継続的に増加します。 - 超高トラフィックシナリオ：変更フィードの総トラフィックが700 MiB/秒を超える場合。 @@ -68,7 +68,7 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート ### テーブルレベルのタスク分割に関する推奨構成 {#recommended-configurations-for-table-level-task-splitting} -新しい TiCDCアーキテクチャに切り替えた後は、従来のアーキテクチャのテーブル分割設定を再利用しないでください。ほとんどの場合、新しいアーキテクチャのデフォルト設定を使用してください。レプリケーションのパフォーマンスにボトルネックが生じたり、スケジューリングの不均衡が発生したりする特別なシナリオでのみ、デフォルト値に基づいて段階的な調整を行ってください。 +新しい TiCDCアーキテクチャに切り替えた後は、クラシックアーキテクチャのテーブル分割設定を再利用しないでください。ほとんどの場合、新しいアーキテクチャのデフォルト設定を使用してください。レプリケーションのパフォーマンスにボトルネックが生じたり、スケジューリングの不均衡が発生したりする特別なシナリオでのみ、デフォルト値に基づいて段階的な調整を行ってください。 テーブル分割モードでは、以下の設定に注意してください。 @@ -78,19 +78,19 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート ## 互換性 {#compatibility} -以下の特別な場合を除き、TiCDC の新しいアーキテクチャは従来のアーキテクチャと完全に互換性があります。 +以下の特別な場合を除き、TiCDC の新しいアーキテクチャはクラシックアーキテクチャと完全に互換性があります。 ### DDL進捗状況追跡テーブル {#ddl-progress-tracking-table} -TiCDC の従来のアーキテクチャでは、DDL レプリケーション操作は厳密にシリアルであるため、レプリケーションの進行状況は変更フィードの`CheckpointTs`を使用してのみ追跡できます。しかし、新しいアーキテクチャでは、DDL レプリケーションの効率を向上させるために、可能な限り異なるテーブルの DDL 変更を並列でレプリケートします。ダウンストリームの MySQL 互換データベースで各テーブルの DDL レプリケーションの進行状況を正確に記録するために、TiCDC の新しいアーキテクチャでは、ダウンストリームデータベースに`tidb_cdc.ddl_ts_v1`という名前のテーブルを作成し、変更フィードの DDL レプリケーションの進行状況情報を格納します。 +TiCDC のクラシックアーキテクチャでは、DDL レプリケーション操作は厳密にシリアルであるため、レプリケーションの進行状況は変更フィードの`CheckpointTs`を使用してのみ追跡できます。しかし、新しいアーキテクチャでは、DDL レプリケーションの効率を向上させるために、可能な限り異なるテーブルの DDL 変更を並列でレプリケートします。ダウンストリームの MySQL 互換データベースで各テーブルの DDL レプリケーションの進行状況を正確に記録するために、TiCDC の新しいアーキテクチャでは、ダウンストリームデータベースに`tidb_cdc.ddl_ts_v1`という名前のテーブルを作成し、変更フィードの DDL レプリケーションの進行状況情報を格納します。 ### DDLレプリケーション動作の変更 {#changes-in-ddl-replication-behavior} -- 従来のTiCDCアーキテクチャでは、テーブル名を入れ替えるDDL（例： `RENAME TABLE a TO c, b TO a, c TO b;` ）はサポートされていません。新しいアーキテクチャでは、このようなDDLがサポートされています。 +- TiCDCクラシックアーキテクチャでは、テーブル名を入れ替えるDDL（例： `RENAME TABLE a TO c, b TO a, c TO b;` ）はサポートされていません。新しいアーキテクチャでは、このようなDDLがサポートされています。 - 新しいアーキテクチャは`RENAME` DDL のフィルタリング ルールを統一し、簡素化します。 - - 従来のアーキテクチャでは、フィルタリングロジックは以下のとおりです。 + - クラシックアーキテクチャでは、フィルタリングロジックは以下のとおりです。 - 単一テーブル名の変更：DDL文は、古いテーブル名がフィルタルールに一致する場合にのみ複製されます。 - 複数テーブルの名前変更：DDL文は、古いテーブル名と新しいテーブル名の両方がフィルタルールに一致する場合にのみ複製されます。 @@ -104,7 +104,7 @@ TiCDC の従来のアーキテクチャでは、DDL レプリケーション操 rules = ['test.t*'] ``` - - 従来のアーキテクチャでは、 `RENAME TABLE test.t1 TO ignore.t1`のような単一テーブルの名前変更の場合、古いテーブル名`test.t1`ルールに一致するため、複製されます。 `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;`のような複数テーブルの名前変更の場合、新しいテーブル名`ignore.t1`がルールに一致しないため、複製されません。 + - クラシックアーキテクチャでは、 `RENAME TABLE test.t1 TO ignore.t1`のような単一テーブルの名前変更の場合、古いテーブル名`test.t1`ルールに一致するため、複製されます。 `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;`のような複数テーブルの名前変更の場合、新しいテーブル名`ignore.t1`がルールに一致しないため、複製されません。 - 新しい TiCDCアーキテクチャでは、 `RENAME TABLE test.t1 TO ignore.t1`と`RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;`の両方の古いテーブル名がルールに一致するため、両方の DDL文が複製されます。 ## 制限事項 {#limitations} @@ -273,7 +273,7 @@ TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテク ## 新しいアーキテクチャを使用する {#use-the-new-architecture} -新しいアーキテクチャでTiCDCノードをデプロイした後も、従来のアーキテクチャと同じコマンドを引き続き使用できます。新しいコマンドを学習したり、従来のアーキテクチャで使用していたコマンドを変更したりする必要はありません。 +新しいアーキテクチャでTiCDCノードをデプロイした後も、クラシックアーキテクチャと同じコマンドを引き続き使用できます。新しいコマンドを学習したり、クラシックアーキテクチャで使用していたコマンドを変更したりする必要はありません。 例えば、新しいアーキテクチャで新しいTiCDCノードのレプリケーションタスクを作成するには、次のコマンドを実行します。 diff --git a/ticdc/ticdc-classic-architecture.md b/ticdc/ticdc-classic-architecture.md index de2bcfb2ecbcc..07b9919b56012 100644 --- a/ticdc/ticdc-classic-architecture.md +++ b/ticdc/ticdc-classic-architecture.md @@ -1,11 +1,11 @@ --- title: TiCDC Classic Architecture -summary: TiCDC の従来のアーキテクチャと動作原理を学びます。 +summary: TiCDC のクラシックアーキテクチャと動作原理を学びます。 --- # TiCDC クラシックアーキテクチャ {#ticdc-classic-architecture} -このドキュメントでは、TiCDC の従来のアーキテクチャと動作原理について説明します。 +このドキュメントでは、TiCDC のクラシックアーキテクチャと動作原理について説明します。 > **Note:** > @@ -90,7 +90,7 @@ TiCDCの上流は、トランザクションをサポートする分散リレー 下流のリレーショナルデータベースでは、TiCDC は単一テーブル内のトランザクションの一貫性と、複数テーブルにおける最終的なトランザクションの一貫性を保証します。さらに、TiCDC は上流の TiDB クラスターで発生したデータ変更が下流に少なくとも 1回は複製されることを保証します。 -### 建築関連の概念 {#architecture-related-concepts} +### アーキテクチャ関連の概念 {#architecture-related-concepts} - キャプチャ：TiCDCノードを実行するプロセス。複数のキャプチャプロセスがTiCDCクラスターを構成します。各キャプチャプロセスは、TiKVへのデータ変更のレプリケーション（データ変更の受信とアクティブプル、ダウンストリームへのデータレプリケーションなど）を担当します。 - キャプチャオーナー：複数のキャプチャプロセスにおけるキャプチャのオーナー。TiCDCクラスタには、一度に1つのオーナーロールのみが存在します。キャプチャオーナーは、クラスタ内のデータのスケジュール設定を担当します。 diff --git a/ticdc/ticdc-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index 90835121716bc..2b4a44ddcafbe 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -50,7 +50,7 @@ TiCDC は、次の種類のアップストリーム データの変更をサポ たとえば、変更フィードがすべての DDL イベントをフィルターするように設定されている場合、アップストリームが`DROP COLUMN`操作を実行しても、その列に関連する`INSERT`文の書き込みを継続すると、テーブルスキーマの不一致により、TiCDC はこれらの DML 変更をダウンストリームに複製できません。 -- TiCDC [古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)の場合、単一の TiCDC クラスターによって複製されるテーブルの数が次の推奨値を超えると、TiCDC が安定して動作しない可能性があります。 +- TiCDC [クラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)の場合、単一の TiCDC クラスターによって複製されるテーブルの数が次の推奨値を超えると、TiCDC が安定して動作しない可能性があります。 | TiCDCバージョン | 複製するテーブルの推奨数 | | --------------- | :----------: | diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 0bf6d2ab23049..8cb1086e88cfa 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -72,7 +72,7 @@ TiCDCのアーキテクチャを次の図に示します。 - TiCDC: TiCDCプロセスが実行されるTiCDCノード。各ノードではTiCDCプロセスが実行されます。各プロセスは、TiKVノード内の1つ以上のテーブルからデータ変更を取得し、シンクコンポーネントを介して下流システムにその変更を複製します。 - PD：TiDBクラスタのスケジューリングモジュール。このモジュールはクラスタデータのスケジューリングを担当し、通常は3つのPDノードで構成されます。PDはetcdクラスタを介して高可用性を提供します。etcdクラスタでは、TiCDCはノードの状態情報や変更フィードの設定などのメタデータを保存します。 -実装では、TiCDC の[新しいアーキテクチャ](/ticdc/ticdc-architecture.md)と[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)両方が、同じ増分データレプリケーション モデルに基づいて構築されます。クラシックアーキテクチャと比較して、新しいアーキテクチャはタスクスケジューリングとレプリケーションメカニズムをリファクタリングして最適化し、リソースコストを削減しながら、リアルタイム データレプリケーションのパフォーマンス、スケーラビリティ、安定性を大幅に向上させます。 +実装では、TiCDC の[新しいアーキテクチャ](/ticdc/ticdc-architecture.md)と[クラシックアーキテクチャ](/ticdc/ticdc-classic-architecture.md)両方が、同じ増分データレプリケーション モデルに基づいて構築されます。クラシックアーキテクチャと比較して、新しいアーキテクチャはタスクスケジューリングとレプリケーションメカニズムをリファクタリングして最適化し、リソースコストを削減しながら、リアルタイム データレプリケーションのパフォーマンス、スケーラビリティ、安定性を大幅に向上させます。 アーキテクチャ図に示すように、TiCDCはTiDB、MySQL、Kafka、およびストレージサービスへのデータ複製をサポートしています。 diff --git a/ticdc/ticdc-summary-monitor.md b/ticdc/ticdc-summary-monitor.md index ee073ccc509c7..bdd855a3b1681 100644 --- a/ticdc/ticdc-summary-monitor.md +++ b/ticdc/ticdc-summary-monitor.md @@ -13,93 +13,93 @@ v7.0.0以降、 TiUPを使用してGrafanaをデプロイすると、TiCDCサマ 各監視パネルの説明は次のとおりです。 -- サーバー: クラスター内の TiCDC ノードの概要。 +- Server: クラスター内の TiCDC ノードの概要。 - Changefeed: TiCDC 変更フィードのレイテンシーとステータス情報。 -- データフロー: TiCDC 内部モジュールによって処理されるデータ変更の統計。 -- トランザクションシンク: ダウンストリーム MySQL または TiDB の書き込みレイテンシー。 -- MQ シンク: ダウンストリーム MQ システムの書き込みレイテンシー。 -- クラウドストレージ シンク: ダウンストリーム クラウドストレージの書き込み速度。 -- やり直し: やり直し機能が有効な場合の書き込みレイテンシー。 +- Dataflow: TiCDC 内部モジュールによって処理されるデータ変更の統計。 +- Transaction Sink: ダウンストリーム MySQL または TiDB の書き込みレイテンシー。 +- MQ Sink: ダウンストリーム MQ システムの書き込みレイテンシー。 +- Cloud Storage Sink: ダウンストリーム クラウドストレージの書き込み速度。 +- Redo: やり直し機能が有効な場合の書き込みレイテンシー。 -## サーバーパネル {#server-panel} +## Server panel {#server-panel} -**サーバー**パネルは次のとおりです。 +**Server**パネルは次のとおりです。 ![TiCDC Summary Dashboard - Server metrics](/media/ticdc/ticdc-summary-monitor-server.png) -- **稼働時間**: TiCDC ノードが実行されている時間。 -- **CPU 使用率**: TiCDC ノードの CPU 使用率。 -- **メモリ使用量**: TiCDC ノードのメモリ使用量。 +- **Uptime**: TiCDC ノードが実行されている時間。 +- **CPU usage**: TiCDC ノードの CPU 使用率。 +- **Memory usage**: TiCDC ノードのメモリ使用量。 -## チェンジフィードパネル {#changefeed-panel} +## Changefeed panel {#changefeed-panel} **Changefeed**パネルは次のとおりです。 ![TiCDC Summary Dashboard - Changefeed metrics](/media/ticdc/ticdc-summary-monitor-changefeed.png) -- **Changefeed チェックポイント遅延**: 上流 TiDB クラスターと下流システム間のデータレプリケーションレイテンシーを時間で測定します。一般的に、この指標はデータレプリケーションタスクの全体的な健全性を反映します。通常、遅延が小さいほど、レプリケーションタスクの状態は良好です。遅延が大きくなる場合、通常、Changefeed のレプリケーション能力または下流システムの消費能力が上流の書き込み速度に追いついていないことを示します。 -- **変更フィード解決遅延**: 上流 TiDB クラスターと TiCDC ノード間のデータレイテンシーを時間で測定します。この指標は、変更フィードが上流からデータ変更をプルする能力を反映しています。遅延が増加すると、変更フィードが上流で生成されたデータ変更を時間内にプルできないことを意味します。 +- **Changefeed checkpoint lag**: 上流 TiDB クラスターと下流システム間のデータレプリケーションレイテンシーを時間で測定します。一般的に、この指標はデータレプリケーションタスクの全体的な健全性を反映します。通常、遅延が小さいほど、レプリケーションタスクの状態は良好です。遅延が大きくなる場合、通常、Changefeed のレプリケーション能力または下流システムの消費能力が上流の書き込み速度に追いついていないことを示します。 +- **Changefeed resolved ts lag**: 上流 TiDB クラスターと TiCDC ノード間のデータレイテンシーを時間で測定します。この指標は、変更フィードが上流からデータ変更をプルする能力を反映しています。遅延が増加すると、変更フィードが上流で生成されたデータ変更を時間内にプルできないことを意味します。 -## データフローパネル {#dataflow-panel} +## Dataflow panel {#dataflow-panel} ![TiCDC Summary Dashboard - Puller metrics](/media/ticdc/ticdc-summary-monitor-dataflow-puller.png) -- **Puller出力イベント数/秒**: TiCDCノードにおいて、PullerモジュールからSorterモジュールへ1秒あたりに出力されるデータ変更の数。この指標は、TiCDCが上流からデータ変更をプルする速度を表します。 -- **Puller 出力イベント**: TiCDC ノードの Puller モジュールから Sorter モジュールに出力されたデータ変更の合計数。 +- **Puller output events/s**: TiCDCノードにおいて、PullerモジュールからSorterモジュールへ1秒あたりに出力されるデータ変更の数。この指標は、TiCDCが上流からデータ変更をプルする速度を表します。 +- **Puller output events**: TiCDC ノードの Puller モジュールから Sorter モジュールに出力されたデータ変更の合計数。 ![TiCDC Summary Dashboard - Sorter metrics](/media/ticdc/ticdc-summary-monitor-dataflow-sorter.png) -- **Sorter出力イベント数/秒**: TiCDCノードのSinkモジュールにSorterモジュールから1秒あたりに出力されるデータ変更の数。Sorterのデータ出力レートはSinkモジュールの影響を受けることに注意してください。したがって、Sorterモジュールの出力レートがPullerモジュールの出力レートよりも低い場合、必ずしもSorterモジュールのソート速度が遅すぎることを意味するわけではありません。まずSinkモジュールに関連するメトリクスを観察し、Sinkモジュールのデータフラッシュに時間がかかり、Sorterモジュールの出力が低下していないかどうかを確認する必要があります。 +- **Sorter output events/s**: TiCDCノードのSinkモジュールにSorterモジュールから1秒あたりに出力されるデータ変更の数。Sorterのデータ出力レートはSinkモジュールの影響を受けることに注意してください。したがって、Sorterモジュールの出力レートがPullerモジュールの出力レートよりも低い場合、必ずしもSorterモジュールのソート速度が遅すぎることを意味するわけではありません。まずSinkモジュールに関連するメトリクスを観察し、Sinkモジュールのデータフラッシュに時間がかかり、Sorterモジュールの出力が低下していないかどうかを確認する必要があります。 -- **ソーター出力イベント**: TiCDC ノードのソーターモジュールからシンク モジュールに出力されたデータ変更の合計数。 +- **Sorter output event**: TiCDC ノードのソーターモジュールからシンク モジュールに出力されたデータ変更の合計数。 ![TiCDC Summary Dashboard - Mounter metrics](/media/ticdc/ticdc-summary-monitor-dataflow-mounter.png) -- **マウンター出力イベント数/秒**: TiCDCノードにおいて、マウンターモジュールによって1秒あたりにデコードされたデータ変更の数。上流のデータ変更に多数のフィールドが含まれる場合、マウンターモジュールのデコード速度に影響が出る可能性があります。 +- **Mounter output events/s**: TiCDCノードにおいて、マウンターモジュールによって1秒あたりにデコードされたデータ変更の数。上流のデータ変更に多数のフィールドが含まれる場合、マウンターモジュールのデコード速度に影響が出る可能性があります。 -- **マウンタ出力イベント**: TiCDC ノードのマウンタ モジュールによってデコードされたデータ変更の合計数。 +- **Mounter output event**: TiCDC ノードのマウンタ モジュールによってデコードされたデータ変更の合計数。 ![TiCDC Summary Dashboard - Sink metrics](/media/ticdc/ticdc-summary-monitor-dataflow-sink.png) -- **シンクフラッシュ行数/秒**: TiCDCノードにおいて、シンクモジュールが下流へ1秒あたりに出力するデータ変更の数。この指標は、データ変更が下流へ複製される速度を表します。**シンクフラッシュ行数/秒**が**プルラー出力イベント数/秒**よりも低い場合、レプリケーションのレイテンシーが増加する可能性があります。 +- **Sink flush rows/s**: TiCDCノードにおいて、シンクモジュールが下流へ1秒あたりに出力するデータ変更の数。この指標は、データ変更が下流へ複製される速度を表します。**Sink flush rows/s**が**Puller output events/s**よりも低い場合、レプリケーションのレイテンシーが増加する可能性があります。 -- **シンク フラッシュ行**: シンク モジュールによって TiCDC ノードの下流に出力されたデータ変更の合計数。 +- **Sink flush rows**: シンク モジュールによって TiCDC ノードの下流に出力されたデータ変更の合計数。 -## トランザクションシンクパネル {#transaction-sink-panel} +## Transaction Sink panel {#transaction-sink-panel} -**トランザクションシンク**パネルには、ダウンストリームが MySQL または TiDB の場合にのみデータが表示されます。 +**Transaction Sink**パネルには、ダウンストリームが MySQL または TiDB の場合にのみデータが表示されます。 ![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-transaction-sink.png) -- **バックエンドフラッシュ実行時間**: TiCDC トランザクション SinkモジュールがダウンストリームでSQL文を実行するのにかかる時間。この指標を観察することで、ダウンストリームのパフォーマンスがレプリケーション速度のボトルネックになっているかどうかを判断できます。通常、p999値は500ミリ秒未満である必要があります。この値がこの制限を超えると、レプリケーション速度に影響が及び、Changefeedチェックポイントの遅延が増加する可能性があります。 +- **Backend Flush Duration**: TiCDC トランザクション SinkモジュールがダウンストリームでSQL文を実行するのにかかる時間。この指標を観察することで、ダウンストリームのパフォーマンスがレプリケーション速度のボトルネックになっているかどうかを判断できます。通常、p999値は500ミリ秒未満である必要があります。この値がこの制限を超えると、レプリケーション速度に影響が及び、Changefeedチェックポイントの遅延が増加する可能性があります。 -- **フルフラッシュ時間**: TiCDCにおける各トランザクションが、ソーターによるソートから下流への送信までに費やした合計時間。この値から**バックエンドフラッシュ時間の**値を差し引くことで、トランザクションが下流で実行されるまでの合計キューイング時間を取得できます。キューイング時間が長すぎる場合は、レプリケーションタスクに割り当てるメモリクォータを増やすことを検討してください。 +- **Full Flush Duration**: TiCDCにおける各トランザクションが、ソーターによるソートから下流への送信までに費やした合計時間。この値から**Backend Flush Duration**の値を差し引くことで、トランザクションが下流で実行されるまでの合計キューイング時間を取得できます。キューイング時間が長すぎる場合は、レプリケーションタスクに割り当てるメモリクォータを増やすことを検討してください。 -## MQシンクパネル {#mq-sink-panel} +## MQ Sink panel {#mq-sink-panel} -**MQ シンク**パネルには、ダウンストリームが Kafka の場合にのみデータが表示されます。 +**MQ Sink**パネルには、ダウンストリームが Kafka の場合にのみデータが表示されます。 ![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-mq-sink.png) -- **ワーカー送信メッセージ期間パーセンタイル**: TiCDC MQ シンク ワーカーがダウンストリームにデータを送信する際のレイテンシー。 -- **Kafka Ongoing Bytes** : TiCDC MQ Sink がダウンストリームにデータを送信する速度。 +- **Worker Send Message Duration Percentile**: TiCDC MQ シンク ワーカーがダウンストリームにデータを送信する際のレイテンシー。 +- **Kafka Ongoing Bytes**: TiCDC MQ Sink がダウンストリームにデータを送信する速度。 -## クラウドストレージシンクパネル {#cloud-storage-sink-panel} +## Cloud Storage Sink panel {#cloud-storage-sink-panel} -**Cloud Storage シンク**パネルには、ダウンストリームが Cloud Storage の場合にのみデータが表示されます。 +**Cloud Storage Sink**パネルには、ダウンストリームが Cloud Storage の場合にのみデータが表示されます。 ![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-cloud-storage.png) -- **書き込みバイト数/秒**: Cloud Storage Sink モジュールがダウンストリームにデータを書き込む速度。 -- **ファイル数**: Cloud Storage Sink モジュールによって書き込まれたファイルの合計数。 +- **Write Bytes/s**: Cloud Storage Sink モジュールがダウンストリームにデータを書き込む速度。 +- **File Count**: Cloud Storage Sink モジュールによって書き込まれたファイルの合計数。 -## やり直しパネル {#redo-panel} +## Redo panel {#redo-panel} -**やり直し**パネルには、やり直しログ機能が有効な場合にのみデータが表示されます。 +**Redo**パネルには、やり直しログ機能が有効な場合にのみデータが表示されます。 ![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-redo.png) -- **Redo 書き込み行数/秒**: Redo モジュールによって1秒あたりに書き込まれる行数。Redo 機能が有効になっている場合、レプリケーションタスクのレイテンシーが増加すると、このメトリックと Puller 出力イベント数/秒の値に大きな差があるかどうかを確認できます。差がある場合、レイテンシーの増加は Redo モジュールの書き込み容量不足が原因である可能性があります。 -- **Redo 書き込みバイト/秒**: Redo モジュールによって 1秒あたりにデータが書き込まれる速度。 -- **Redoフラッシュログ時間**：Redoモジュールがデータを下流にフラッシュするのにかかる時間。このメトリック値が高い場合、この操作はレプリケーション速度に影響を与える可能性があります。 -- **Redo フラッシュオール期間**: データの変更が Redo モジュールに留まる合計時間。 +- **Redo Write rows/s**: Redo モジュールによって1秒あたりに書き込まれる行数。Redo 機能が有効になっている場合、レプリケーションタスクのレイテンシーが増加すると、このメトリックと**Puller output events/s**の値に大きな差があるかどうかを確認できます。差がある場合、レイテンシーの増加は Redo モジュールの書き込み能力不足が原因である可能性があります。 +- **Redo Write byte/s**: Redo モジュールによって 1秒あたりにデータが書き込まれる速度。 +- **Redo flush log duration**：Redoモジュールがデータを下流にフラッシュするのにかかる時間。このメトリック値が高い場合、この操作はレプリケーション速度に影響を与える可能性があります。 +- **Redo flushall duration**: データの変更が Redo モジュールに留まる合計時間。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index 4953b53551f21..1bf7f7d2a4cc1 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -770,10 +770,10 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', [TiDB Cloudコンソール](https://tidbcloud.com/)すべてのサブスクリプションプランにおいてサポート体験を向上させるため、プランに応じたサポートオプションを提供開始しました。これらのアップデートには以下が含まれます。 - - **プランに応じたサポートのリダイレクト**：クラスタ概要ページで、 **[アクション]**列の**[サポートを受ける]**を選択すると、サブスクリプションプランに基づいて最も適切なリソースにリダイレクトされます。Basicプランのユーザーは**サポートプラン**パネルに、有料プランのユーザーは**サポートポータル**に誘導されます。 + - **プランに応じたサポートのリダイレクト**：クラスタ概要ページで、 **[アクション]**列の**[サポートを受ける]**を選択すると、サブスクリプションプランに基づいて最も適切なリソースにリダイレクトされます。Basicプランのユーザーは**Support Plan**パネルに、有料プランのユーザーは**Support Portal**に誘導されます。 - **ヘルプセンターメニューの改善**：ヘルプメニュー項目名を**Support Options**と**Support Tickets**に変更し、利用可能なサービスをより適切に反映させます。また、有料プランでのみテクニカルサポートチケットが利用できることを明確にするツールチップを追加します。 - - **明確なコミュニティ サポート アクセス**:**サポートプラン**オプション内では、Slack と Discord がBasic プラン ユーザーの主要なテクニカルサポート チャネルとして明確に識別されます。次のドキュメントは、サポート チャネル ポリシーとコミュニティ アクセスを明確にするために合理化されています: [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)、[Connected Careの概要](/tidb-cloud/connected-care-overview.md)、および[Connected Careの詳細](/tidb-cloud/connected-care-detail.md)。 - - **アクション指向のサポートプランUI** ：**サポートプラン**ウィンドウを再設計し、一般的なプラン比較ではなく、現在ご利用のプランで利用可能なサポートオプションを優先的に表示するようにしました。この変更により、現在ご利用のプランに基づいてサポートを受ける方法をすばやく特定できます。 + - **明確なコミュニティ サポート アクセス**:**Support Plan**オプション内では、Slack と Discord がBasic プラン ユーザーの主要なテクニカルサポート チャネルとして明確に識別されます。次のドキュメントは、サポート チャネル ポリシーとコミュニティ アクセスを明確にするために合理化されています: [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)、[Connected Careの概要](/tidb-cloud/connected-care-overview.md)、および[Connected Careの詳細](/tidb-cloud/connected-care-detail.md)。 + - **アクション指向のSupport Plan UI** ：**Support Plan**ウィンドウを再設計し、一般的なプラン比較ではなく、現在ご利用のプランで利用可能なサポートオプションを優先的に表示するようにしました。この変更により、現在ご利用のプランに基づいてサポートを受ける方法をすばやく特定できます。 詳細については、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index 8f095e91070c6..94e8d0781a403 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -46,18 +46,18 @@ TiDB Cloud ClinicはGrafanaを使用して、TiDBクラスターの包括的な ダッシュボードとその内容は変更される場合があります。現在、以下のダッシュボードをご利用いただけます。 -- バックアップとインポート -- DMプロフェッショナル -- DM標準 +- Backup & Import +- DM-Professional +- DM-Standard - Lightning -- パフォーマンス概要 -- TiCDC-概要 +- Performance-Overview +- TiCDC-Summary - TiDB -- TiDB リソース制御 -- TiFlash-概要 +- TiDB-Resource-Control +- TiFlash-Summary - TiKV-Details -- TiProxy-概要 -- ユーザーノード情報 +- TiProxy-Summary +- User-Node-Info ## スロークエリ上位を分析する {#analyze-top-slow-queries} diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 31bd6d68ba88e..9449eebee908b 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -367,8 +367,8 @@ SET GLOBAL tidb_low_resolution_tso=ON; - PDにおけるTSOの割り当ては、まだボトルネックに達していません。 - PDノードとTiDBノードは十分なCPUリソースを備えています。 - TiDBとPD間のネットワークレイテンシーは、PDがTSOを割り当てるのにかかる時間よりもかなり長い（つまり、TSO RPCの実行時間の大部分はネットワークレイテンシーによるものである）。 - - TSO RPCリクエストの所要時間を取得するには、Grafana TiDBダッシュボードのPDクライアントセクションにある**PD TSO RPC所要時間**パネルを確認してください。 - - PD TSO割り当ての期間を確認するには、Grafana PDダッシュボードのTiDBセクションにある**PDサーバーTSOハンドル期間**パネルを確認してください。 + - TSO RPCリクエストの所要時間を取得するには、Grafana TiDBダッシュボードのPDクライアントセクションにある**PD TSO RPC Duration**パネルを確認してください。 + - PD TSO割り当ての期間を確認するには、Grafana PDダッシュボードのTiDBセクションにある**PD server TSO handle duration**パネルを確認してください。 - TiDBとPD間のTSO RPCリクエストの増加（ `PARALLEL`の場合は2倍、 `PARALLEL-FAST`の場合は4倍）によって生じる追加のネットワークトラフィックは許容範囲内です。 並列モードを切り替えるには、次のコマンドを実行してください。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 3ee9737861606..c2d8aa4504dcd 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -363,7 +363,7 @@ SELECT * FROM request_unit_by_group LIMIT 5; -TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の**[TiDB]** > **[リソース制御]**ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについては[TiDBの重要な監視指標](/grafana-tidb-dashboard.md)の**リソース制御**セクションで詳しく説明されています。 +TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の**TiDB** > **Resource Control**ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについては[TiDBの重要な監視指標](/grafana-tidb-dashboard.md)の**リソース制御**セクションで詳しく説明されています。 TiKV は、さまざまなリソースグループからのリクエスト QPS も記録します。詳細については、 [TiKVモニタリング指標の詳細](/grafana-tikv-dashboard.md#grpc)を参照してください。 @@ -377,7 +377,7 @@ TiDB Dashboardの現在の[`RESOURCE_GROUPS`](/information-schema/information-sc > > このセクションでは、TiDB Self-Managed でのみ利用可能な Grafana ダッシュボードについて説明します。TiDB Cloud Dedicated では、TiDB Cloud コンソールの [Calibrate Resource](/tidb-cloud/calibrate-resource.md) ページで、**Total RU Consumed** や **RU Consumed by Resource Groups** などのリソース制御メトリクスを表示できます。 -TiDBは、リソース制御に関するランタイム情報を定期的に収集し、Grafanaの**TiDB** >**リソース制御**ダッシュボードでそのメトリクスの視覚的なグラフを提供します。 +TiDBは、リソース制御に関するランタイム情報を定期的に収集し、Grafanaの**TiDB** > **Resource Control**ダッシュボードでそのメトリクスの視覚的なグラフを提供します。 TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソースグループからのリクエストQPSも記録します。 diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index cf9872a7992ec..bce0b1209f6d1 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -274,7 +274,7 @@ TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...` 2. TiFlashの負荷を調整します。 - TiFlashへの負荷が高すぎると、レプリケーションが遅くなる場合があります。Grafanaの**TiFlash -Summary**パネルで、 TiFlashインジケーターの負荷を確認できます。 + TiFlashへの負荷が高すぎると、レプリケーションが遅くなる場合があります。Grafanaの**TiFlash-Summary**パネルで、 TiFlashインジケーターの負荷を確認できます。 - `Applying snapshots Count` ： `TiFlash-summary` > `raft` > `Applying snapshots Count` - `Snapshot Predecode Duration` ： `TiFlash-summary` > `raft` > `Snapshot Predecode Duration` diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index ad3d66f06e97a..864d70dbd86c3 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1563,7 +1563,7 @@ Titanに関連するコンフィグレーション項目。 ### `max-background-gc` {#max-background-gc} -- TitanにおけるGCスレッドの最大数。TiKV**の詳細** > **スレッドCPU** > **RocksDB CPU**パネルで、Titan GCスレッドが長時間フル稼働状態にあることが確認された場合は、Titan GCスレッドプールのサイズを増やすことを検討してください。 +- TitanにおけるGCスレッドの最大数。**TiKV-Details** > **Thread CPU** > **RocksDB CPU**パネルで、Titan GCスレッドが長時間フル稼働状態にあることが確認された場合は、Titan GCスレッドプールのサイズを増やすことを検討してください。 - デフォルト値: `1` 。v8.0.0 より前のバージョンでは、デフォルト値は`4`です。 - 最小値: `1` @@ -2709,7 +2709,8 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 - タイムスタンプリクエストにおけるTSOの最小数。 - TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV はリクエストされる TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュサイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 -- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチサイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカルキャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。- デフォルト値: `100` +- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO batch size**は、アプリケーションのワークロードに応じて動的に調整されるローカルキャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 +- デフォルト値: `100` ### `renew-batch-max-size` v6.4.0で追加 {#renew-batch-max-size-new-in-v640} diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 03cf101457df0..8cdfd5474536d 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -162,4 +162,4 @@ SHOW CONFIG WHERE Type='tikv' AND Name LIKE 'in-memory-engine\.%'; ### TiKV MVCCのインメモリエンジンを監視するにはどうすればよいですか？ {#how-can-i-monitor-the-tikv-mvcc-in-memory-engine} -Grafanaの**TiKV-Details**ダッシュボードのセクション[**インメモリエンジン**](/grafana-tikv-dashboard.md#in-memory-engine)を確認してください。 +Grafanaの**TiKV-Details**ダッシュボードのセクション[**In Memory Engine**](/grafana-tikv-dashboard.md#in-memory-engine)を確認してください。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 9a39504ecc72e..f3e6114017861 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -82,7 +82,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - TiKV は OOM であり、再起動を引き起こします。 - `THP` (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。 -- モニターを確認してください：TiKV RocksDB が書き込みストールに遭遇し、再選出が行われます。モニター**Grafana** -> **TiKV-details** -> **errors**に`server is busy`が表示されているかどうかを確認してください。 +- モニターを確認してください：TiKV RocksDB が書き込みストールに遭遇し、再選出が行われます。モニター**Grafana** -> **TiKV-Details** -> **errors**に`server is busy`が表示されているかどうかを確認してください。 - ネットワーク分離のため再選。 @@ -95,7 +95,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ TiKV にはボトルネックになる可能性のある単一スレッドがいくつかあります。 - TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV-Details**->**スレッドCPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`を有効にするとこの問題を解決できます。 -- v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( **Grafana** -> **TiKV-details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリックが`80%`超える)、TiKV (v2.x) インスタンスをスケールアウトするか、マルチスレッド対応の v3.x にアップグレードできます。 +- v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( **Grafana** -> **TiKV-Details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリックが`80%`超える)、TiKV (v2.x) インスタンスをスケールアウトするか、マルチスレッド対応の v3.x にアップグレードできます。 ### CPU負荷が増加する {#cpu-load-increases} @@ -135,5 +135,5 @@ CPU リソースの使用量がボトルネックになります。 TiDBのトランザクションは、マルチバージョン同時実行制御（MVCC）メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが保存されます。タイムスタンプは異なるバージョンを区別するために使用されます。GCのタスクは、古くなったデータをクリアすることです。 - ロック解決フェーズでは、TiKVに大量のリクエスト`scan_lock`が作成されます。これはgRPC関連のメトリクスで確認できます。これらのリクエスト`scan_lock`は、すべてのリージョンを呼び出します。 -- 範囲の削除のフェーズでは、TiKV に少数の (またはまったくない) `unsafe_destroy_range`が送信されます。これは、gRPC 関連のメトリックと**GC タスク**パネルで確認できます。 -- Do GC フェーズでは、各 TiKV はデフォルトでマシン上のリーダーリージョンをスキャンし、各リーダーに対して GC を実行します。これは、 **GC タスク**パネルで確認できます。 +- 範囲の削除のフェーズでは、TiKV に少数の (またはまったくない) `unsafe_destroy_range`が送信されます。これは、gRPC 関連のメトリックと**GC tasks**パネルで確認できます。 +- Do GC フェーズでは、各 TiKV はデフォルトでマシン上のリーダーリージョンをスキャンし、各リーダーに対して GC を実行します。これは、 **GC tasks**パネルで確認できます。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index a5c3b2ea272fb..ab70bb22a1803 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -65,7 +65,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ - 書き込みホットスポットを判断するには、 **TiKV トラブルシューティング**監視パネルで**Hot Write**を開き、任意の TiKV ノードのRaftstore CPU メトリック値が他のノードの値よりも大幅に高いかどうかを確認します。 -- 読み取りホットスポットを判断するには、 **TiKV 詳細**監視パネルで**Thread_CPU**を開き、いずれかの TiKV ノードのコプロセッサ CPU メトリック値が特に高いかどうかを確認します。 +- 読み取りホットスポットを判断するには、 **TiKV-Details**監視パネルで**Thread_CPU**を開き、いずれかの TiKV ノードのコプロセッサ CPU メトリック値が特に高いかどうかを確認します。 ### TiDB Dashboardを使用してホットスポットテーブルを見つける {#use-tidb-dashboard-to-locate-hotspot-tables} diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 5321c379546eb..2e703183e7617 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -170,9 +170,9 @@ CheckLeader の問題に対処するには、 [**TiKV-Details**>**Resolved-TS ![Example: Stale Read OPS](/media/stale-read/example-ops.png) -まず、次の[**TiKV-Details**>**Resolved-TS**ダッシュボード](/grafana-tikv-dashboard.md#resolved-ts)の**Max Resolved TS gap**と**Min Resolved TS Region**メトリックを確認します。 +まず、次の[**TiKV-Details**>**Resolved-TS**ダッシュボード](/grafana-tikv-dashboard.md#resolved-ts)の**Max gap of resolved-ts**と**Min Resolved TS Region**メトリックを確認します。 -![Example: Max Resolved TS gap](/media/stale-read/example-ts-gap.png) +![Example: Max gap of resolved-ts](/media/stale-read/example-ts-gap.png) 上記のメトリックから、リージョン`3121`と他のいくつかのリージョンが、resolved-ts を時間内に更新していないことがわかります。