diff --git a/alert-rules.md b/alert-rules.md index 45584a084397d..10f93399cdfbe 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -711,7 +711,7 @@ summary: TiDB クラスターのアラートルールについて学習します - 説明： - コプロセッサーのキューイング要求。 + コプロセッサーのキューイングリクエスト。 - 解決： diff --git a/auto-increment.md b/auto-increment.md index d75ca55329677..4ac3330ee4cb6 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -284,7 +284,7 @@ mysql> SELECT * FROM t ORDER BY b; 11 rows in set (0.00 sec) ``` -値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーがデプロイされている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。 +値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーがデプロイされている場合、キャッシュリクエストがインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。 ### キャッシュサイズの制御 {#cache-size-control} diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index 84e4cdbfa6617..e3c0ea4c46e4a 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -53,7 +53,7 @@ sdb 1649.00 209030.67 1293.33 304644.00 13.33 5.09 48.37 sdd 1033.00 4132.00 1141.33 31685.33 571.00 0.94 100.00 ``` -デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュ要求完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。 +デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュリクエスト完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。 クラウドプロバイダーによって、IOPSやMBPSなどのパフォーマンス特性が異なる様々なディスクタイプが提供されています。そのため、ワークロードに応じて適切なクラウドプロバイダー、ディスクタイプ、ディスクサイズを選択することが重要です。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 3fdb99762c6f3..a5b96a21865dd 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -105,7 +105,7 @@ DDL実行のユーザーエクスペリエンスを向上させるため、TiDB v6.2.0 より前では、 TiDB SQLレイヤーで非同期スキーマ変更を処理するプロセスは次のとおりです。 -1. MySQL クライアントは TiDBサーバーに DDL 要求を送信します。 +1. MySQL クライアントは TiDBサーバーに DDL リクエストを送信します。 2. リクエストを受信すると、TiDBサーバーはMySQL プロトコルレイヤーでリクエストを解析および最適化し、実行のためにTiDB SQLレイヤーに送信します。 diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 01874d320c36b..1e6c4dfe0c91b 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -18,7 +18,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high- ## 同時書き込みの多いシナリオ {#highly-concurrent-write-intensive-scenario} -高度な同時書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。 +同時実行性の高い書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。 - 膨大な量のデータ - 履歴データを短時間でデータベースにインポートする必要性 @@ -98,7 +98,7 @@ FROM ![QPS3](/media/best-practices/QPS3.png) -[RaftストアCPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのLeader、 `tikv-0`と`tikv-1`フォロワーです。他のノードの負荷はほぼ空です。 +[Raft store CPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのLeader、 `tikv-0`と`tikv-1`がフォロワーです。他のノードの負荷はほぼ空です。 PD の監視メトリックでも、ホットスポットが発生したことが確認されます。 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index 6fcf4706689d9..8b2cb5b655a0c 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -51,7 +51,7 @@ TiDB は、次のツールを導入することでインデックスの最適化 - 未使用のインデックスの検出: クエリによってアクセスされていないインデックスを識別し、安全に削除できるインデックスを判断するのに役立ちます。 - インデックスの効率を分析する: インデックスが使用される頻度と、効率的なクエリ実行に貢献しているかどうかを追跡します。 -- クエリパターンを評価する: インデックスが読み取り操作、データスキャン、キーバリュー (KV) 要求にどのように影響するかを理解します。 +- クエリパターンを評価する: インデックスが読み取り操作、データスキャン、キー値 (KV) リクエストにどのように影響するかを理解します。 [TiDB v8.4.0](/releases/release-8.4.0.md)から始まる`TIDB_INDEX_USAGE`システムテーブルには、クラスター化されたテーブルの主キーも含まれており、インデックスのパフォーマンスをより詳細に把握できます。 @@ -308,7 +308,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; 4. **DML パフォーマンスへの影響に注意してください。** - - 過剰なインデックス作成は避けてください。インデックスを追加するごとに`UPDATE` `INSERT` `DELETE`のオーバーヘッドが増加します。 + - 過剰なインデックス作成は避けてください。インデックスを追加するごとに`INSERT`、`UPDATE`、`DELETE`操作のオーバーヘッドが増加します。 - 書き込みが多いワークロードのメンテナンス コストを最小限に抑えるために、クエリに必要なものだけをインデックスします。 5. **定期的にテストと調整を行ってください。** diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 534b591be767c..3c019f091da91 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -90,7 +90,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ クラスタトポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。 -リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker` `location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`クラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。 +リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker`は`location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`はクラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。 ### スケールインと障害回復 {#scale-in-and-failure-recovery} @@ -215,7 +215,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`を設定して一時的に無効にすることができます。 - - スケジューリングプロセスが遅すぎます。原因を確認するには**Operator step duration**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` 、 `RemovePeer` 、 `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 + - スケジューリングプロセスが遅すぎます。原因を確認するには**Operator step duration**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` 、 `RemovePeer` 、 `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner`と`AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 - PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。 @@ -299,4 +299,4 @@ v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニ > **Note:** > -> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。 +> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリングリクエストを送信し、TiKVが受信したスケジューリングリクエストを順次実行することで実現されます。**低速I/O**などの要因により、低速ノードではリクエストが蓄積され、一部のリーダーは遅延したリクエストが処理されるまで**Leaderの排除**リクエストを処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。 diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md index f7a0dbc242b44..434f5259035cf 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -25,6 +25,6 @@ zone=dc-1 [ステイル読み取り](/stale-read.md)は、TiDBがユーザーに履歴データ読み取りのために提供するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、ストレージノード間のデータ複製によって生じるレイテンシーを削減できます。地理的に分散されたデプロイメントの一部のシナリオでステイル読み取りを使用する場合、TiDBはリアルタイムパフォーマンスを犠牲にして現在のデータセンター内のレプリカにアクセスし、対応するデータを読み取ります。これにより、センター間接続によって生じるネットワークレイテンシーを回避し、クエリプロセス全体のアクセスレイテンシーを削減します。 -TiDB がステイル読み取りクエリを受信すると、その TiDB ノードの`zone`ラベルが設定されていて、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-replicas`に設定されている場合、TiDB は対応するデータ レプリカが存在する同じ`zone`ラベルを持つ TiKV ノードに要求を送信します。 +TiDB がステイル読み取りクエリを受信すると、その TiDB ノードの`zone`ラベルが設定されていて、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-replicas`に設定されている場合、TiDB は対応するデータ レプリカが存在する同じ`zone`ラベルを持つ TiKV ノードにリクエストを送信します。 ステイル読み取り の実行方法については、 [`AS OF TIMESTAMP`句を使用してステイル読み取りを実行する](/as-of-timestamp.md)を参照してください。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 12e42087b9f67..0ead645c61372 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -68,7 +68,7 @@ tikv: #### `storage.scheduler-worker-pool-size` {#storage-scheduler-worker-pool-size} -TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。スケジューラスレッドプールは、TiKVが複雑なトランザクション要求を単純なキーバリューの読み取りまたは書き込みに変換するために使用されます。ただし、スケジューラスレッドプール自体は書き込み操作を実行しません。 +TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。スケジューラスレッドプールは、TiKVが複雑なトランザクションリクエストを単純なキー値の読み取りまたは書き込みに変換するために使用されます。ただし、スケジューラスレッドプール自体は書き込み操作を実行しません。 理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用率が低くなりすぎます。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。 diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index 8f7f431a41fc4..3d1c06d145407 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -7,10 +7,10 @@ summary: TiDBは、タイムリーなデータリカバリやビジネス監査 [TiDB スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md)と[TiDB ログバックアップと PITR ガイド](/br/br-pitr-guide.md) 、TiDBが提供するバックアップとリストアのソリューション、すなわちスナップショット（フル）バックアップとリストア、ログバックアップ、そしてポイントインタイムリカバリ（PITR）について紹介します。このドキュメントは、特定のユースケースにおいてTiDBのバックアップとリストアのソリューションを迅速に導入するのに役立ちます。 -AWS に TiDB本番クラスターをデプロイし、ビジネスチームが次の要件を要求しているとします。 +AWS に TiDB本番クラスターをデプロイし、ビジネスチームが次の要件をリクエストしているとします。 - データの変更はタイムリーにバックアップしてください。データベースに災害が発生した場合でも、最小限のデータ損失（許容できるのは数分間のデータ損失のみ）でアプリケーションを迅速に復旧できます。 -- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、要求に応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。 +- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、リクエストに応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。 PITR を使用すると、前述の要件を満たすことができます。 diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index 9f49854d4fb13..44528605ee306 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -15,7 +15,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを ## 実装の詳細 {#implementation-details} -スナップショットバックアップ中、 `br`テーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードは要求された範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報を`br`に返します。 +スナップショットバックアップ中、 `br`テーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードはリクエストされた範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報を`br`に返します。 `br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイントバックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。 diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index 74238da018ba8..81a3f0c3cad7a 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -72,7 +72,7 @@ sequenceDiagram - **グローバルチェックポイントtsの取得**：PDからグローバルチェックポイントtsを取得します。 - **ローカルメタデータの生成**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、バックアップタスクのローカルメタデータを生成します。 - **ログデータとメタデータのアップロード**：バックアップファイルとローカルメタデータを定期的にターゲットストレージにアップロードします。 - - **GC の設定**: PD に対して、バックアップされていないデータ (ローカル チェックポイント ts より大きいデータ) が[TiDB GCメカニズム](/garbage-collection-overview.md)によって再利用されないように要求します。 + - **GC の設定**: PD に対して、バックアップされていないデータ (ローカル チェックポイント ts より大きいデータ) が[TiDB GCメカニズム](/garbage-collection-overview.md)によって再利用されないようにリクエストします。 4. TiDBコーディネーターは、ログバックアップタスクの進行状況を監視します。 @@ -124,16 +124,16 @@ PITRの全プロセスは以下のとおりです。 - **バックアップデータの読み取り**：ログバックアップデータを読み取り、復元する必要のあるログバックアップデータを計算します。 - **リージョン情報の取得**: PD にアクセスして、すべてのリージョンのディストリビューションを取得します。 - - **TiKVにデータ復元を要求する**：ログ復元要求を作成し、対応するTiKVノードに送信します。ログ復元要求には、復元するログバックアップデータの情報が含まれています。 + - **TiKVにデータ復元をリクエストする**：ログ復元リクエストを作成し、対応するTiKVノードに送信します。ログ復元リクエストには、復元するログバックアップデータの情報が含まれています。 -4. TiKVはBRからの復元要求を受け入れ、ログ復元ワーカーを起動します。 +4. TiKVはBRからの復元リクエストを受け入れ、ログ復元ワーカーを起動します。 - ログ復元ワーカーは、復元する必要のあるログバックアップデータを取得します。 5. TiKVはログバックアップデータを復元します。 - - **KVのダウンロード**：ログ復元ワーカーは、ログ復元要求に従って、バックアップストレージから対応するバックアップデータをローカルディレクトリにダウンロードします。 - - **KVの書き換え**：ログ復元ワーカーは、復元クラスタテーブルのテーブルIDに基づいてバックアップデータのKVデータを書き換えます。つまり、 [キーバリュー](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 + - **KVのダウンロード**：ログ復元ワーカーは、ログ復元リクエストに従って、バックアップストレージから対応するバックアップデータをローカルディレクトリにダウンロードします。 + - **KVの書き換え**：ログ復元ワーカーは、復元クラスタテーブルのテーブルIDに基づいてバックアップデータのKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 - **KVの適用**：ログ復元ワーカーは、処理されたKVデータをRaftインターフェースを介してストア（RocksDB）に書き込みます。 - **レポート復元結果**: ログ復元ワーカーは復元結果をBRに返します。 diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 7ec13940e1a88..54030e16bdcce 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -52,7 +52,7 @@ sequenceDiagram - **TiKV とリージョン情報の取得**: BR はPD にアクセスして、すべての TiKV ノードのアドレスとデータの[リージョン](/tidb-storage.md#region)分布を取得します。 - **TiKVにデータバックアップを依頼する**： BRはバックアップ依頼を作成し、すべてのTiKVノードに送信します。バックアップ依頼には、バックアップのタイミング、バックアップ対象のリージョン、およびストレージパスが含まれます。 -3. TiKVはバックアップ要求を受け入れ、バックアップワーカーを起動します。 +3. TiKVはバックアップリクエストを受け入れ、バックアップワーカーを起動します。 4. TiKVはデータをバックアップします。 @@ -106,12 +106,12 @@ sequenceDiagram 2. BRは復元データのスケジュールを設定します。 - - **リージョンスケジュールの一時停止**： BRは、復元中に自動リージョンスケジューリングを一時停止するようPDに要求します。 + - **リージョンスケジュールの一時停止**： BRは、復元中に自動リージョンスケジューリングを一時停止するようPDにリクエストします。 - **スキーマの復元**： BRはバックアップデータのスキーマ、および復元対象のデータベースとテーブルを取得します。新しく作成されたテーブルのIDは、バックアップデータのIDと異なる場合があることに注意してください。 - - **リージョンの分割と分散**： BRはPDにバックアップデータに基づいてリージョンを分割（Split）するよう要求し、ストレージノードに均等に分散（Scatter）されるようにリージョンをスケジュールします。各リージョンには、指定されたデータ範囲`[start key, end key)`があります。 + - **リージョンの分割と分散**： BRはPDにバックアップデータに基づいてリージョンを分割（Split）するようリクエストし、ストレージノードに均等に分散（Scatter）されるようにリージョンをスケジュールします。各リージョンには、指定されたデータ範囲`[start key, end key)`があります。 - **TiKVにデータ復元を依頼する**： BRは復元依頼を作成し、リージョン分割の結果に応じて対応するTiKVノードに送信します。復元依頼には、復元するデータと書き換えルールが含まれます。 -3. TiKVは復元要求を受け入れ、復元ワーカーを起動します。 +3. TiKVは復元リクエストを受け入れ、復元ワーカーを起動します。 - リストアワーカーは、リストアのために読み込む必要のあるバックアップデータを計算します。 diff --git a/check-before-deployment.md b/check-before-deployment.md index 5de5cf2c00c83..819be424c8356 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -701,7 +701,7 @@ sudo systemctl enable ntpd.service > **Note:** > > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネルパラメータです。 - > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 + > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリリクエスト速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 > - `vm.min_free_kbytes`を少なくとも`1048576` KiB（1 GiB）に設定することをお勧めします。[NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 > - Linux カーネル 4.11 以前を実行しているシステムの場合は、 `net.ipv4.tcp_tw_recycle = 0`を設定することをお勧めします。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index a9af5806ed74d..9dffec60dd405 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -102,7 +102,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - TiDBサービスの監視ポート - デフォルト: `"4000"` -- TiDBサーバーはこのポートからの MySQL クライアント要求を受け入れます。 +- TiDBサーバーはこのポートからの MySQL クライアントリクエストを受け入れます。 ## `--path` {#--path} diff --git a/configure-load-base-split.md b/configure-load-base-split.md index 096f81b8801eb..9b2aad48e06ce 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -13,7 +13,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ ただし、PDスケジューリングの最小単位はリージョンです。クラスター内のホットスポットの数がノード数より少ない場合、または一部のホットスポットの負荷が他のリージョンよりもはるかに大きい場合、PDはホットスポットをあるノードから別のノードに移動することしかできず、クラスター全体で負荷を分散させることはできません。 -このシナリオは、完全なテーブルスキャンや小さなテーブルのインデックス検索、一部のフィールドへの頻繁なアクセスなど、主に読み取り要求であるワークロードで特に一般的です。 +このシナリオは、完全なテーブルスキャンや小さなテーブルのインデックス検索、一部のフィールドへの頻繁なアクセスなど、主に読み取りリクエストであるワークロードで特に一般的です。 以前は、この問題の解決策として、1つ以上のホットスポットリージョンを分割するコマンドを手動で実行していましたが、この方法には 2つの問題がありました。 @@ -36,9 +36,9 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ リージョンが10秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 -- 読み取り要求の合計が`split.qps-threshold`超えます。 -- トラフィックが`split.byte-threshold`超えています。 -- 統合読み取りプール内の CPU 使用率が`split.region-cpu-overload-threshold-ratio`超えています。 +- 読み取りリクエストの合計が`split.qps-threshold`を超えます。 +- トラフィックが`split.byte-threshold`を超えています。 +- 統合読み取りプール内の CPU 使用率が`split.region-cpu-overload-threshold-ratio`を超えています。 ロードベーススプリットはデフォルトで有効になっていますが、パラメータがかなり高い値に設定されています。この機能を無効にするには、 `split.qps-threshold`と`split.byte-threshold`十分に高い値に設定し、同時に`split.region-cpu-overload-threshold-ratio`を`0`に設定してください。 diff --git a/coprocessor-cache.md b/coprocessor-cache.md index 3101ea8dedb29..8cf11338be1da 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -36,15 +36,15 @@ v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシ - プッシュダウン計算リクエストが同じ場合、キャッシュにヒットします。通常、以下のシナリオでは、プッシュダウン計算リクエストは同じか、部分的に同じです。 - SQL文は同じです。例えば、同じSQL文が繰り返し実行されます。 - このシナリオでは、すべてのプッシュダウン計算要求は一貫しており、すべての要求はプッシュダウン計算キャッシュを使用できます。 + このシナリオでは、すべてのプッシュダウン計算リクエストは一貫しており、すべてのリクエストはプッシュダウン計算キャッシュを使用できます。 - SQL文には変更条件が含まれており、その他の部分は一貫しています。変更条件は、テーブルまたはパーティションの主キーです。 - このシナリオでは、プッシュダウン計算要求の一部は以前の要求の一部と同じであり、これらの計算要求はキャッシュされた (以前の) プッシュダウン計算結果を使用できます。 + このシナリオでは、プッシュダウン計算リクエストの一部は以前のリクエストの一部と同じであり、これらの計算リクエストはキャッシュされた (以前の) プッシュダウン計算結果を使用できます。 - SQL文には複数の変更条件が含まれており、その他の部分は一貫しています。変更条件は複合インデックス列と完全に一致します。 - このシナリオでは、プッシュダウン計算要求の一部は以前の要求の一部と同じであり、これらの計算要求はキャッシュされた (以前の) プッシュダウン計算結果を使用できます。 + このシナリオでは、プッシュダウン計算リクエストの一部は以前のリクエストの一部と同じであり、これらの計算リクエストはキャッシュされた (以前の) プッシュダウン計算結果を使用できます。 - この機能はユーザーにとって透過的です。この機能を有効または無効にしても計算結果には影響せず、SQL実行時間のみに影響します。 diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index c59b7f3d5de43..113fd4f5390f0 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -172,19 +172,19 @@ TiDBには自動診断結果が組み込まれています。各フィールド - KVリクエスト時間 - `KV_backoff`時間、これはKVリクエストが失敗した後のバックオフの時間です -上記の部分のうち、KV 要求時間には次の部分が含まれます。 +上記の部分のうち、KV リクエスト時間には次の部分が含まれます。 - ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`差し引くことで、この項目のおおよその見積もりが可能です。 - 消費時間`tikv_grpc_message` 。 上記の部品のうち、 `tikv_grpc_message`回の消費量に含まれる部品は以下のとおりです。 -- コプロセッサー要求の消費時間。これは、COPタイプの要求の処理を指します。この消費時間には、以下の部分が含まれます。 +- コプロセッサーリクエストの消費時間。これは、COPタイプのリクエストの処理を指します。この消費時間には、以下の部分が含まれます。 - `tikv_cop_wait` : リクエスト キューによって消費された時間。 - - `Coprocessor handle` :コプロセッサー要求の処理に費やされた時間。 + - `Coprocessor handle` :コプロセッサーリクエストの処理に費やされた時間。 - `tikv_scheduler_command`時間の消費で、次の部分が含まれます。 - - `tikv_scheduler_processing_read` : 読み取り要求の処理に費やされた時間。 + - `tikv_scheduler_processing_read` : 読み取りリクエストの処理に費やされた時間。 - スナップショットを`tikv_storage_async_request`で取得するのにかかった時間 (スナップショットはこの監視メトリックのラベルです)。 - 書き込みリクエストの処理にかかる時間。この時間消費には以下の部分が含まれます。 - `tikv_scheduler_latch_wait` : ラッチを待機するのにかかる時間。 @@ -365,4 +365,4 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり - `LABEL` : 監視メトリックに対応するラベル。例えば、監視メトリック`TiKV Coprocessor scan`には、TiKVアドレス、リクエストタイプ、操作タイプ、操作カラムファミリーを表す2つのラベル（ `instance` 、 `req` 、 `tag` 、 `sql_type` ）があります。 - `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`を計算した結果の差の値。 -上記の表から、 `t2`時間範囲では`t1`時間範囲よりもコプロセッサー要求がはるかに多く、 `t2`の TiDB の SQL 解析時間が大幅に長くなっていることがわかります。 +上記の表から、 `t2`時間範囲では`t1`時間範囲よりもコプロセッサーリクエストがはるかに多く、 `t2`の TiDB の SQL 解析時間が大幅に長くなっていることがわかります。 diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index ce4c3d708df00..6d9fcdaada4ce 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -33,7 +33,7 @@ T2: `2020-03-10 13:24:30` ～ `2020-03-10 13:27:30` 。この範囲ではQPSが - `tidb_qps` : QPSが0.93倍減少しました。 - `tidb_query_duration` : P999 クエリのレイテンシーが1.54 倍増加しました。 -- `tidb_cop_duration` : P999 コプロセッサ要求の処理レイテンシーが 2.48 倍に増加しました。 +- `tidb_cop_duration` : P999 コプロセッサリクエストの処理レイテンシーが 2.48 倍に増加しました。 - `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。 - `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3つの TiKV インスタンスで大幅に改善されました。 - `pd_operator_step_finish_total_count`では、転属リーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 4fb996799348d..90ac10346cc5f 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -81,9 +81,9 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー しかし、 `tidb_kv_request`の持続時間が`tidb_cop`にどれだけ含まれているかを判断することは困難です。 -- `tidb_kv_request.Get` : TiDB が`Get`種類のキーバリューリクエストを送信する期間。 -- `tidb_kv_request.Cop` : TiDB が`Cop`種類のキーバリューリクエストを送信する期間。 +- `tidb_kv_request.Get` : TiDB が`Get`型のキー値リクエストを送信する期間。 +- `tidb_kv_request.Cop` : TiDB が`Cop`型のキー値リクエストを送信する期間。 `tidb_kv_request`子ノードとして`tidb_kv_request.Get`と`tidb_kv_request.Cop`ノードを含みませんが、後者の2つのノードで構成されます。子ノードの名前プレフィックスは親ノードの名前に`.xxx`を加えたもので、これは子ノードが親ノードのサブクラスであることを意味します。このケースは次のように理解できます。 -TiDB がキーバリューリクエストを送信する合計時間は 14745.07秒で、そのうち、タイプ`Get`と`Cop`キーバリューリクエストにはそれぞれ 9798.02秒と 4946.46秒かかります。 +TiDB がキー値リクエストを送信する合計時間は 14745.07秒で、そのうち、タイプ`Get`と`Cop`キー値リクエストにはそれぞれ 9798.02秒と 4946.46秒かかります。 diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index 14bbfdd34993b..7edafbcc9f22d 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -23,25 +23,25 @@ TiDBクラスターをTiUPを使用してデプロイした場合、Grafanaで - **Overview**：データベース時間とSQL実行時間の概要。概要で異なる色を確認することで、データベースのワークロードプロファイルとパフォーマンスのボトルネックを素早く特定できます。 -- **負荷プロファイル**: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV 要求 OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 +- **負荷プロファイル**: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV リクエスト OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 -- **トップダウンのレイテンシーの内訳**: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV 要求レイテンシー、TiKV 内の書き込みレイテンシーの内訳。 +- **トップダウンのレイテンシーの内訳**: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV リクエストレイテンシー、TiKV 内の書き込みレイテンシーの内訳。 次のセクションでは、パフォーマンス概要ダッシュボードのメトリックについて説明します。 -### SQLタイプ別のデータベース時間 {#database-time-by-sql-type} +### Database Time by SQL Type {#database-time-by-sql-type} - `database time` : 1秒あたりの合計データベース時間 - `sql_type` : 各タイプのSQL文が1秒あたりに消費するデータベース時間 -### SQLフェーズ別のデータベース時間 {#database-time-by-sql-phase} +### Database Time by SQL Phase {#database-time-by-sql-phase} - `database time` : 1秒あたりの合計データベース時間 - `get token/parse/compile/execute` : 4つのSQL処理フェーズで消費されたデータベース時間 SQL実行フェーズは緑色で、その他のフェーズは全体的に赤色で表示されます。緑色以外の領域が大きい場合は、実行フェーズ以外のフェーズでデータベース時間が大量に消費されていることを意味し、さらなる原因分析が必要です。 -### SQL実行時間の概要 {#sql-execute-time-overview} +### SQL Execute Time Overview {#sql-execute-time-overview} - `execute time` : SQL実行中に1秒あたりに消費されたデータベース時間 - `tso_wait` : SQL実行中の1秒あたりの同時TSO待機時間 @@ -56,32 +56,32 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### QPS {#qps} -すべて`UPDATE` TiDB インスタンスで 1秒あたりに実行された SQL 文の数 (タイプ別: `SELECT`など`INSERT` +すべての TiDB インスタンスで 1秒あたりに実行された SQL 文の数（タイプ別に収集: `SELECT`、`INSERT`、`UPDATE`など） -### CPSタイプ別 {#cps-by-type} +### CPS By Type {#cps-by-type} タイプに基づいて、すべての TiDB インスタンスによって 1秒あたりに処理されるコマンドの数 -### プランキャッシュOPSを使用したクエリ {#queries-using-plan-cache-ops} +### Queries Using Plan Cache OPS {#queries-using-plan-cache-ops} すべての TiDB インスタンスにおける 1秒あたりのプランキャッシュを使用するクエリの数 -### KV/TSO リクエスト OPS {#kv-tso-request-ops} +### KV/TSO Request OPS {#kv-tso-request-ops} -- kvリクエスト合計: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 -- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1秒あたりの KV リクエスト数 +- kv request total: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 +- kv request by type: `Get`、`Prewrite`、`Commit`などのタイプに基づいて、すべての TiDB インスタンスでの 1秒あたりの KV リクエスト数 - tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 -- tso - リクエスト: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 +- tso - request: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 -通常、 `tso - request` `tso - cmd`で割った値が、1秒あたりの TSO 要求バッチの平均サイズになります。 +通常、 `tso - request`を`tso - cmd`で割った値が、1秒あたりの TSO リクエストバッチの平均サイズになります。 -### 接続数 {#connection-count} +### Connection Count {#connection-count} - `total` : すべてのTiDBインスタンスへの接続数 - `active connections` : すべてのTiDBインスタンスへのアクティブな接続の数 - 各TiDBインスタンスへの接続数 -### TiDB CPU/メモリ {#tidb-cpu-memory} +### TiDB CPU/Memory {#tidb-cpu-memory} - `CPU-Avg` : すべての TiDB インスタンスの平均 CPU 使用率 - `CPU-Delta` : すべての TiDB インスタンスの最大 CPU 使用率からすべての TiDB インスタンスの最小 CPU 使用率を引いた値 @@ -89,7 +89,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `CPU-Quota` : TiDBが使用できるCPUコアの数 - `Mem-Max` : すべての TiDB インスタンスの最大メモリ使用率 -### TiKV CPU/メモリ {#tikv-cpu-memory} +### TiKV CPU/Memory {#tikv-cpu-memory} - `CPU-Avg` : すべての TiKV インスタンスの平均 CPU 使用率 - `CPU-Delta` : すべての TiKV インスタンスの最大 CPU 使用率からすべての TiKV インスタンスの最小 CPU 使用率を引いた値 @@ -97,18 +97,18 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `CPU-Quota` : TiKVが使用できるCPUコアの数 - `Mem-Max` : すべての TiKV インスタンスの最大メモリ使用率 -### PD CPU/メモリ {#pd-cpu-memory} +### PD CPU/Memory {#pd-cpu-memory} - `CPU-Max` : すべてのPDインスタンスの最大CPU使用率 - `CPU-Quota` : PDが使用できるCPUコアの数 - `Mem-Max` : すべてのPDインスタンスの最大メモリ使用率 -### トラフィックを読む {#read-traffic} +### Read Traffic {#read-traffic} - `TiDB -> Client` : TiDBからクライアントへの送信トラフィック統計 - `Rocksdb -> TiKV` :ストレージレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー -### 書き込みトラフィック {#write-traffic} +### Write Traffic {#write-traffic} - `Client -> TiDB` : クライアントから TiDB への受信トラフィック統計 - `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度 @@ -116,7 +116,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ - `RocksDB Compaction` : RocksDBの圧縮操作によって生成された合計読み取りおよび書き込みI/Oフロー -### 間隔 {#duration} +### Duration {#duration} - `Duration` : 実行時間 @@ -127,9 +127,9 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `99` : すべてのリクエストを実行するためのP99期間 -- `avg by type` : すべての TiDB インスタンス内のすべてのリクエストを実行するのにかかった平均時間 (タイプ別`UPDATE`収集`INSERT` : `SELECT` +- `avg by type` : すべての TiDB インスタンス内のすべてのリクエストを実行するのにかかった平均時間（タイプ別に収集: `SELECT`、`INSERT`、`UPDATE`） -### 接続アイドル時間 {#connection-idle-duration} +### Connection Idle Duration {#connection-idle-duration} 接続アイドル期間は、接続がアイドル状態にある期間を示します。 @@ -138,7 +138,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `99-in-txn` : 接続がトランザクション内にある場合の P99 接続アイドル期間 - `99-not-in-txn` : 接続がトランザクション内にない場合の P99 接続アイドル期間 -### 解析期間、コンパイル期間、実行期間 {#parse-duration-compile-duration-and-execute-duration} +### Parse Duration, Compile Duration, and Execute Duration {#parse-duration-compile-duration-and-execute-duration} - `Parse Duration` : SQL文の解析に要した時間 - `Compile Duration` : 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 @@ -146,22 +146,22 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 これら3つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 -### 平均 TiDB KV リクエスト期間 {#avg-tidb-kv-request-duration} +### Avg TiDB KV Request Duration {#avg-tidb-kv-request-duration} -`Get` 、 `Prewrite` 、 `Commit`を含むタイプに基づいて、すべての TiDB インスタンスでの KV 要求の実行に費やされた平均時間。 +`Get` 、 `Prewrite` 、 `Commit`を含むタイプに基づいて、すべての TiDB インスタンスでの KV リクエストの実行に費やされた平均時間。 -### 平均 TiKV GRPC 期間 {#avg-tikv-grpc-duration} +### Avg TiKV GRPC Duration {#avg-tikv-grpc-duration} `kv_get` 、 `kv_prewrite` 、 `kv_commit`を含むタイプに基づいて、すべての TiKV インスタンスでの gRPC リクエストの実行に費やされた平均時間。 -### PD TSO 待機/RPC 期間 {#pd-tso-wait-rpc-duration} +### PD TSO Wait/RPC Duration {#pd-tso-wait-rpc-duration} - `wait - avg` : すべての TiDB インスタンスで PD が TSO を返すのを待つ平均時間 - `rpc - avg` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでの平均時間 - `wait - 99` : すべての TiDB インスタンスで PD が TSO を返すのを待つ P99時間 - `rpc - 99` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでのP99時間 -### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} +### Storage Async Write Duration, Store Duration, and Apply Duration {#storage-async-write-duration-store-duration-and-apply-duration} - `Storage Async Write Duration` : 非同期書き込みにかかった時間 - `Store Duration` : 非同期書き込み中のストアループで消費された時間 @@ -171,7 +171,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 平均ストレージ非同期書き込み時間 = 平均保存時間 + 平均適用時間 -### 追加ログ期間、コミットログ期間、適用ログ期間 {#append-log-duration-commit-log-duration-and-apply-log-duration} +### Append Log Duration, Commit Log Duration, and Apply Log Duration {#append-log-duration-commit-log-duration-and-apply-log-duration} - `Append Log Duration` : Raftがログを追加するのにかかった時間 - `Commit Log Duration` : Raftがログをコミットするのにかかる時間 diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index b6cce828e086e..c3bc765aa2fa6 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -107,7 +107,7 @@ Dashboard is not started. ## TiDB Dashboardを再度有効にする {#re-enable-tidb-dashboard} -TiUPを使用してデプロイされた実行中のクラスターの場合は、 `tiup ctl:v pd`コマンドを使用して、PD にインスタンスの再ネゴシエートを要求し、TiDB Dashboardを実行します ( `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます)。 +TiUPを使用してデプロイされた実行中のクラスターの場合は、 `tiup ctl:v pd`コマンドを使用して、PD にインスタンスの再ネゴシエーションをリクエストし、TiDB Dashboardを実行します ( `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます)。 ```bash tiup ctl:v pd -u http://127.0.0.1:2379 config set dashboard-address auto diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 4765ec33db707..1aa325afc9a33 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -170,7 +170,7 @@ OLTP（オンライントランザクション処理）シナリオでは、プ #### `StreamingResult`を使用して実行結果を取得します。 {#use-streamingresult-to-get-the-execution-result} -ほとんどのシナリオでは、実行効率を向上させるために、JDBCはデフォルトでクエリ結果を事前に取得し、クライアントのメモリに保存します。しかし、クエリが非常に大きな結果セットを返す場合、クライアントはデータベースサーバーに一度に返されるレコード数を減らし、クライアントのメモリが準備できるまで待機し、次のバッチを要求することがよくあります。 +ほとんどのシナリオでは、実行効率を向上させるために、JDBCはデフォルトでクエリ結果を事前に取得し、クライアントのメモリに保存します。しかし、クエリが非常に大きな結果セットを返す場合、クライアントはデータベースサーバーに一度に返されるレコード数を減らし、クライアントのメモリが準備できるまで待機し、次のバッチをリクエストすることがよくあります。 JDBCでは通常、以下の2つの処理方法が使用されます。 diff --git a/develop/dev-guide-get-data-from-single-table.md b/develop/dev-guide-get-data-from-single-table.md index ff0c1d2105ffa..37ccb73655e04 100644 --- a/develop/dev-guide-get-data-from-single-table.md +++ b/develop/dev-guide-get-data-from-single-table.md @@ -139,7 +139,7 @@ SELECT * FROM authors WHERE birth_year = 1998;
-Javaでは、同じSQLを使用して、動的なパラメータを持つデータクエリ要求を処理できます。 +Javaでは、同じSQLを使用して、動的なパラメータを持つデータクエリリクエストを処理できます。 これは、パラメータを SQL文に連結することで実行できます。ただし、この方法では、アプリケーションのセキュリティに[SQLインジェクション](https://en.wikipedia.org/wiki/SQL_injection)インジェクションの潜在的なリスクが生じます。 diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index f675db5b9e207..5ca24a5486487 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -25,7 +25,7 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク ホットスポットの問題が存在する場合は、 [TiDBホットスポットの問題の処理](/troubleshoot-hot-spot-issues.md)を参照してトラブルシューティングを行うことができます。これにより、アプリケーション レベルでのホットスポットの生成を回避することができます。 -読み取りホットスポットが避けられない場合、または変更コストが非常に高い場合は、Follower Read機能を使用して、フォロワーリージョンへの読み取り要求のバランスをより適切にロードすることができます。 +読み取りホットスポットが避けられない場合、または変更コストが非常に高い場合は、Follower Read機能を使用して、フォロワーリージョンへの読み取りリクエストの負荷をより適切に分散することができます。 ### 地理的に分散したデプロイのレイテンシーを削減 {#reduce-latency-for-geo-distributed-deployments} diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index f4c5c6f42e678..b32633f5a5a39 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -14,7 +14,7 @@ JavaアプリケーションでTiDBデータベースと連携する一般的な - ネットワーク プロトコル: クライアントは、標準の[MySQLプロトコル](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html)を介して TiDBサーバーと対話します。 - JDBC APIとJDBCドライバ： Javaアプリケーションは通常、標準の[JDBC（Javaデータベース接続）](https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/) APIを使用してデータベースにアクセスします。TiDBに接続するには、JDBC APIを介してMySQLプロトコルを実装するJDBCドライバを使用できます。MySQL用の一般的なJDBCドライバには[MySQL Connector/J](https://github.com/mysql/mysql-connector-j)や[MariaDB Connector/J](https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j#about-mariadb-connectorj)などがあります。 -- データベース接続プール：アプリケーションは通常、接続要求のたびに接続を作成するオーバーヘッドを削減するために、接続プールを使用して接続をキャッシュし、再利用します。JDBCData [データソース](https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)接続プールAPIを定義しています。必要に応じて、さまざまなオープンソースの接続プール実装から選択できます。 +- データベース接続プール：アプリケーションは通常、接続リクエストのたびに接続を作成するオーバーヘッドを削減するために、接続プールを使用して接続をキャッシュし、再利用します。JDBCData [データソース](https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)接続プールAPIを定義しています。必要に応じて、さまざまなオープンソースの接続プール実装から選択できます。 - データアクセスフレームワーク: アプリケーションは通常、 [MyBatis](https://mybatis.org/mybatis-3/index.html)や[Hibernate](https://hibernate.org/)などのデータアクセスフレームワークを使用して、データベースアクセス操作をさらに簡素化および管理します。 - アプリケーションの実装: アプリケーションロジックは、いつどのコマンドをデータベースに送信するかを制御します。一部のアプリケーションは[春のトランザクション](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html)アスペクトを使用して、トランザクションの開始およびコミットのロジックを管理します。 @@ -60,7 +60,7 @@ OLTP (オンライントランザクション処理) シナリオの場合、プ #### `StreamingResult`を使用して実行結果を取得します。 {#use-streamingresult-to-get-the-execution-result} -ほとんどのシナリオでは、実行効率を向上させるために、JDBCはデフォルトでクエリ結果を事前に取得し、クライアントのメモリに保存します。しかし、クエリが非常に大きな結果セットを返す場合、クライアントはデータベースサーバーに一度に返されるレコード数を減らし、クライアントのメモリが準備できるまで待機し、次のバッチを要求することがよくあります。 +ほとんどのシナリオでは、実行効率を向上させるために、JDBCはデフォルトでクエリ結果を事前に取得し、クライアントのメモリに保存します。しかし、クエリが非常に大きな結果セットを返す場合、クライアントはデータベースサーバーに一度に返されるレコード数を減らし、クライアントのメモリが準備できるまで待機し、次のバッチをリクエストすることがよくあります。 JDBCでは通常、以下の2つの処理方法が使用されます。 diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 9a2f97685a31c..2fd083238de3a 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -94,8 +94,8 @@ DM の実行中にエラーが発生した場合は、次の手順に従って | エラーコード | エラーの説明 | 取り扱い方法 | | :----------- | :------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `code=10001` | 異常なデータベース操作です。 | エラーメッセージとエラースタックをさらに分析します。 | -| `code=10002` | 基盤データベースからのエラー`bad connection`です。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在要求されているデータがTiDBに送信されていないことを示します。 | DMはこのようなエラーに対して自動リカバリを提供します。長時間リカバリが成功しない場合は、ネットワークまたはTiDBのステータスを確認してください。 | -| `code=10003` | 基盤データベースからのエラー`invalid connection`です。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在要求されているデータの一部がTiDBに送信されていることを示します。 | DMはこのようなエラーに対して自動回復機能を提供します。長時間回復できない場合は、エラーメッセージをさらに確認し、実際の状況に基づいて情報を分析してください。 | +| `code=10002` | 基盤データベースからのエラー`bad connection`です。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在リクエストされているデータがTiDBに送信されていないことを示します。 | DMはこのようなエラーに対して自動リカバリを提供します。長時間リカバリが成功しない場合は、ネットワークまたはTiDBのステータスを確認してください。 | +| `code=10003` | 基盤データベースからのエラー`invalid connection`です。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在リクエストされているデータの一部がTiDBに送信されていることを示します。 | DMはこのようなエラーに対して自動回復機能を提供します。長時間回復できない場合は、エラーメッセージをさらに確認し、実際の状況に基づいて情報を分析してください。 | | `code=10005` | `QUERY`タイプのSQL文の実行時に発生します。 | | | `code=10006` | `EXECUTE`タイプのSQL文（ `INSERT` `UPDATE`または`DELETE`タイプのDDL文およびDML文を含む）の実行時に発生します。詳細なエラー情報については、通常、データベース操作で返されるエラーコードとエラー情報を含むエラーメッセージを確認してください。 | | | | | | @@ -109,7 +109,7 @@ DM の実行中にエラーが発生した場合は、次の手順に従って #### 理由 {#reason-1} -エラー`invalid connection`は、DM と下流の TiDB データベース間の接続に異常 (ネットワーク障害、TiDB の再起動、TiKV のビジー状態など) が発生し、現在の要求のデータの一部が TiDB に送信されたことを示します。 +エラー`invalid connection`は、DM と下流の TiDB データベース間の接続に異常 (ネットワーク障害、TiDB の再起動、TiKV のビジー状態など) が発生し、現在のリクエストのデータの一部が TiDB に送信されたことを示します。 #### ソリューション {#solutions-1} diff --git a/dm/dm-generate-self-signed-certificates.md b/dm/dm-generate-self-signed-certificates.md index 74cfa6785c177..3d358a4a1f477 100644 --- a/dm/dm-generate-self-signed-certificates.md +++ b/dm/dm-generate-self-signed-certificates.md @@ -108,7 +108,7 @@ DM-master インスタンスに証明書を発行するには、次の手順を > > `0.0.0.0`のような特殊な IP を接続や通信に使用する場合は、 `alt_names`にも追加する必要があります。 -4. `openssl.cnf`ファイルを保存し、証明書要求ファイルを生成します。( `Common Name (e.g. server FQDN or YOUR name) []:`に入力する際に、証明書に`dm`などの共通名 (CN) を割り当てます。これは、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントは、デフォルトでは検証を有効にしません。構成ファイルで有効にすることができます。) +4. `openssl.cnf`ファイルを保存し、証明書リクエストファイルを生成します。( `Common Name (e.g. server FQDN or YOUR name) []:`に入力する際に、証明書に`dm`などの共通名 (CN) を割り当てます。これは、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントは、デフォルトでは検証を有効にしません。構成ファイルで有効にすることができます。) ```bash openssl req -new -key master-key.pem -out master-cert.pem -config openssl.cnf @@ -148,7 +148,7 @@ DM-master インスタンスに証明書を発行するには、次の手順を openssl genrsa -out client-key.pem 2048 ``` -2. 証明書要求ファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 +2. 証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 ```bash openssl req -new -key client-key.pem -out client-cert.pem diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index 1a21fb885bc42..ddfd7b610ae44 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -1008,7 +1008,7 @@ curl -X 'GET' \ ## レプリケーションタスクを削除する {#delete-a-replication-task} -このインターフェースは同期インターフェースであり、要求が成功すると返される本体のステータスコードは 204 になります。 +このインターフェースは同期インターフェースであり、リクエストが成功すると返される本体のステータスコードは 204 になります。 ### リクエストURI {#request-uri} diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index 3db2e0d707701..ca82e51cebe7f 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -93,9 +93,9 @@ sequenceDiagram 2. `DM-master`は受信した DDL 情報に基づいてこの DDL文の移行を調整する必要があると判断し、この DDL文のロックを作成し、DDL ロック情報を`DM-worker-1`に送り返し、同時に`DM-worker-1`をこのロックの所有者としてマークします。 3. `DM-worker-2`は、`t3`の MySQL インスタンス 2 から DDL文を受信するまで DML文の移行を継続し、この DDL文のデータ移行を一時停止し、DDL 情報を`DM-master`に送信します。 4. `DM-master`は受信した DDL 情報に基づいて、この DDL文のロックが既に存在すると判断し、ロック情報を`DM-worker-2`に直接送信します。 -5. タスクの開始時の構成情報、アップストリームの MySQL インスタンスのシャーディングされたテーブル情報、およびデプロイメント トポロジ情報に基づいて、 `DM-master`はマージされるすべてのアップストリームのシャーディングされたテーブルのこの DDL文を受信したと判断し、DDL ロックの所有者 ( `DM-worker-1` ) にこの DDL文をダウンストリームに移行するように要求します。 -6. `DM-worker-1`は、ステップ #2 で受信した DDL ロック情報に基づいて DDL文実行要求を検証し、この DDL文をダウンストリームに移行し、結果を`DM-master`に送信します。この操作が成功した場合、 `DM-worker-1`は後続の ( `t2`のbinlogから始まる) DML文の移行を続行します。 -7. `DM-master`はロック所有者から DDL が正常に実行されたという応答を受け取り、DDL ロックを待機している他のすべての DM-worker ( `DM-worker-2` ) に、この DDL文を無視し、後続の ( `t4`のbinlogから始まる) DML文の移行を続行するように要求します。 +5. タスクの開始時の構成情報、アップストリームの MySQL インスタンスのシャーディングされたテーブル情報、およびデプロイメント トポロジ情報に基づいて、 `DM-master`はマージされるすべてのアップストリームのシャーディングされたテーブルのこの DDL文を受信したと判断し、DDL ロックの所有者 ( `DM-worker-1` ) にこの DDL文をダウンストリームに移行するようにリクエストします。 +6. `DM-worker-1`は、ステップ #2 で受信した DDL ロック情報に基づいて DDL文実行リクエストを検証し、この DDL文をダウンストリームに移行し、結果を`DM-master`に送信します。この操作が成功した場合、 `DM-worker-1`は後続の ( `t2`のbinlogから始まる) DML文の移行を続行します。 +7. `DM-master`はロック所有者から DDL が正常に実行されたという応答を受け取り、DDL ロックを待機している他のすべての DM-worker ( `DM-worker-2` ) に、この DDL文を無視し、後続の ( `t4`のbinlogから始まる) DML文の移行を続行するようにリクエストします。 複数のDM-worker間でシャーディングDDL移行を処理するDMの特性は、以下のようにまとめられます。 @@ -144,7 +144,7 @@ DMでは、DM-worker内でDDL文をシャーディングする簡略化された 1. 各DM-workerは、アップストリームのMySQLインスタンス内の複数のシャーディングテーブルで構成される対応するシャーディンググループに対して、DDL文の移行を個別に調整します。 2. DM-workerは、シャーディングされたすべてのテーブルのDDL文を受け取った後、DDL情報を`DM-master`に送信します。 3. `DM-master`は受信した DDL 情報に基づいて、DM-workers で構成されるシャーディンググループの DDL 移行を調整します。 -4. すべての DM-worker から DDL 情報を受信した後、 `DM-master`は DDL ロック所有者 (特定の DM-worker) に DDL文を実行するように要求します。 +4. すべての DM-worker から DDL 情報を受信した後、 `DM-master`は DDL ロック所有者 (特定の DM-worker) に DDL文を実行するようにリクエストします。 5. DDLロックの所有者はDDL文を実行し、結果を`DM-master`に返します。その後、所有者はDDL移行の内部調整中に以前に無視されたDML文の移行を再開します。 6. `DM-master`は、所有者が DDL文を正常に実行したことを確認した後、他のすべての DM-worker に移行を続行するように要求します。 7. 他のすべてのDM-workerは、DDL移行の内部調整中に、以前に無視されたDML文の移行を個別に再開します。 diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index a97f04e83488f..ae8af599dcd4b 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -18,7 +18,7 @@ DMはシャーディングDDLロックを使用して、操作が正しい順序 ### `shard-ddl-lock` {#shard-ddl-lock} -このコマンドを使用すると、DDLロックを表示し、DM-masterに指定されたDDLロックの解放を要求できます。このコマンドはDM v6.0以降でのみサポートされています。それより前のバージョンでは、コマンド`show-ddl-locks`と`unlock-ddl-locks`を使用する必要があります。 +このコマンドを使用すると、DDLロックを表示し、DM-masterに指定されたDDLロックの解放をリクエストできます。このコマンドはDM v6.0以降でのみサポートされています。それより前のバージョンでは、コマンド`show-ddl-locks`と`unlock-ddl-locks`を使用する必要があります。 ```bash shard-ddl-lock -h @@ -44,7 +44,7 @@ Use "dmctl shard-ddl-lock [command] --help" for more information about a command -- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM-masterに要求します。`[command]`は値として`unlock`のみを受け入れます。 +- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM-masterにリクエストします。`[command]`は値として`unlock`のみを受け入れます。 ## 使用例 {#usage-examples} @@ -86,7 +86,7 @@ shard-ddl-lock test ### `shard-ddl-lock unlock` {#shard-ddl-lock-unlock} -このコマンドは、所有者に DDL文を実行するよう要求し、所有者以外の他のすべての DM-workerに DDL文をスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的に要求します。 +このコマンドは、所有者に DDL文を実行するようリクエストし、所有者以外の他のすべての DM-workerに DDL文をスキップするようリクエストし、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的にリクエストします。 > **Note:** > @@ -119,7 +119,7 @@ Global Flags: - `-o, --owner` : - フラグ; 文字列; オプション - - 指定されていない場合、このコマンドはデフォルトの所有者（結果`shard-ddl-lock`の所有者）に DDL文の実行を要求します。指定されている場合、このコマンドは MySQL ソース（デフォルトの所有者の代替）に DDL文の実行を要求します。 + - 指定されていない場合、このコマンドはデフォルトの所有者（結果`shard-ddl-lock`の所有者）に DDL文の実行をリクエストします。指定されている場合、このコマンドは MySQL ソース（デフォルトの所有者の代替）に DDL文の実行をリクエストします。 - 元の所有者がクラスターからすでに削除されていない限り、新しい所有者を指定しないでください。 - `-f, --force-remove` : @@ -230,7 +230,7 @@ MySQLとDMの操作プロセスは次のとおりです。 - 返される結果`unsynced` by `shard-ddl-lock`には常に`mysql-replica-02`の情報が含まれています。 -6. `shard-ddl-lock unlock`を使用して`DM-master`に要求し、DDL ロックをアクティブにロック解除します。 +6. `shard-ddl-lock unlock`を使用して`DM-master`にリクエストし、DDL ロックをアクティブにロック解除します。 - DDL ロックの所有者がオフラインになった場合は、パラメータ`--owner`を使用して、別の DM-workerを新しい所有者として指定し、DDL を実行できます。 - いずれかの MySQL ソースがエラーを報告した場合、 `result`が`false`に設定され、この時点で、各 MySQL ソースのエラーが許容範囲内であり、期待どおりであるかどうかを慎重に確認する必要があります。 @@ -301,13 +301,13 @@ MySQLとDMの操作プロセスは次のとおりです。 現在、上記のロック解除プロセスはアトミックではありません。非オーナーがDDL操作を正常にスキップした場合、非オーナーが配置されているDM-workerが異常停止するか、下流のTiDBでネットワーク異常が発生し、チェックポイントの更新が失敗する可能性があります。 -非所有者に対応するMySQLソースがデータ移行を復元する際、非所有者はDM-masterに対して、例外発生前に調整されていたDDL操作の再調整を要求しようとします。このため、他のMySQLソースから対応するDDL操作を受け取ることはありません。これにより、DDL操作によって対応するロックが自動的に解除される可能性があります。 +非所有者に対応するMySQLソースがデータ移行を復元する際、非所有者はDM-masterに対して、例外発生前に調整されていたDDL操作の再調整をリクエストしようとします。このため、他のMySQLソースから対応するDDL操作を受け取ることはありません。これにより、DDL操作によって対応するロックが自動的に解除される可能性があります。 #### 手動ソリューション {#manual-solution} ここで、上流と下流のテーブル構造が同じであり、テーブルのマージと移行に対する要求も[一部のMySQLソースが削除されました](#scenario-1-some-mysql-sources-are-removed)の手動ソリューションと同じであるとします。 -`DM-master`自動的にロック解除処理を実行すると、オーナー（ `mysql-replica-01` ）はDDLを正常に実行し、移行処理を継続します。しかし、非オーナー（ `mysql-replica-02` ）にDDL操作のスキップを要求する処理において、対応するDM-workerが再起動されたため、DM-workerがDDL操作をスキップした後にチェックポイントの更新に失敗します。 +`DM-master`自動的にロック解除処理を実行すると、オーナー（ `mysql-replica-01` ）はDDLを正常に実行し、移行処理を継続します。しかし、非オーナー（ `mysql-replica-02` ）にDDL操作のスキップをリクエストする処理において、対応するDM-workerが再起動されたため、DM-workerがDDL操作をスキップした後にチェックポイントの更新に失敗します。 `mysql-replica-02`に対応するデータ移行サブタスクが復元された後、DM-masterに新しいロックが作成されますが、他の MySQL ソースは DDL 操作を実行またはスキップし、後続の移行を実行しています。 diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index 1392900e0bdd3..51eaaf1501b3b 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -46,7 +46,7 @@ TiDBは3つの完全なデータレプリカを保存します。そのため、 TiDBの増分データレプリケーションツールとして、TiCDCはPDのetcdを介して高い可用性を実現します。TiCDCは複数のキャプチャプロセスを通じてTiKVノードからデータ変更を取得し、内部でデータ変更をソートおよびマージします。その後、TiCDCは複数のレプリケーションタスクを使用して、データを複数のダウンストリームシステムにレプリケートします。上記のアーキテクチャ図では、次のようになります。 -- TiKVサーバー：アップストリームのデータ変更をTiCDCノードに送信します。TiCDCノードは、変更ログが継続的でないことを検出すると、TiKVサーバーに変更ログの提供を積極的に要求します。 +- TiKVサーバー：アップストリームのデータ変更をTiCDCノードに送信します。TiCDCノードは、変更ログが継続的でないことを検出すると、TiKVサーバーに変更ログの提供を積極的にリクエストします。 - TiCDC：複数のキャプチャプロセスを実行します。各キャプチャプロセスは、KV変更ログの一部を取得し、取得したデータをソートしてから、変更内容をさまざまな下流システムに複製します。 前述のアーキテクチャ図からわかるように、TiCDCのアーキテクチャはトランザクションログレプリケーションシステムに似ていますが、より優れたスケーラビリティと論理データレプリケーションの利点を備えています。したがって、TiCDCは災害復旧シナリオにおいてTiDBを補完する優れたソリューションとなります。 @@ -63,7 +63,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 ![Primary-secondary cluster DR](/media/dr/ticdc-dr.png) -前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、"1:1"の災害復旧ソリューションとも呼ばれます。 +前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込みリクエストを処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、"1:1"の災害復旧ソリューションとも呼ばれます。 このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、秒単位の RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)を参照してください。 @@ -71,7 +71,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 ![Multi-replica cluster DR](/media/dr/multi-replica-dr.png) -前述のアーキテクチャでは、各リージョンに、異なるアベイラブルゾーン（AZ）に配置された2つの完全なデータレプリカがあります。クラスタ全体は3つのリージョンにまたがっています。リージョン1は、読み取りおよび書き込み要求を処理するプライマリリージョンです。リージョン1が災害により完全に利用不能になった場合、リージョン2をDRリージョンとして使用できます。リージョン3は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは"2-2-1"ソリューションとも呼ばれます。 +前述のアーキテクチャでは、各リージョンに、異なるアベイラブルゾーン（AZ）に配置された2つの完全なデータレプリカがあります。クラスタ全体は3つのリージョンにまたがっています。リージョン1は、読み取りおよび書き込みリクエストを処理するプライマリリージョンです。リージョン1が災害により完全に利用不能になった場合、リージョン2をDRリージョンとして使用できます。リージョン3は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは"2-2-1"ソリューションとも呼ばれます。 このソリューションは、領域レベルのエラー耐性、スケーラブルな書き込み機能、ゼロ RPO、分単位以下の RTO を提供します。本番システムでゼロ RPO が必要な場合は、この DR ソリューションを使用することをお勧めします。このソリューションの詳細については、[単一クラスター内の複数のレプリカに基づく災害復旧ソリューション](/dr-multi-replica.md)を参照してください。 diff --git a/dynamic-config.md b/dynamic-config.md index 0eda319777460..27f346c47be2e 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -140,7 +140,7 @@ show warnings; | `raftstore.raft-store-max-leader-lease` | Raftリーダーの最も長い信頼期間 | | `raftstore.merge-check-tick-interval` | マージチェックの時間間隔 | | `raftstore.cleanup-import-sst-interval` | 期限切れのSSTファイルをチェックする時間間隔 | -| `raftstore.local-read-batch-size` | 1バッチで処理される読み取り要求の最大数 | +| `raftstore.local-read-batch-size` | 1バッチで処理される読み取りリクエストの最大数 | | `raftstore.apply-yield-write-size` | 適用スレッドが各ラウンドで1つのFSM（有限状態機械）に書き込むことができる最大バイト数 | | `raftstore.hibernate-timeout` | 起動時に休止状態に入るまでの最短待機時間。この時間内は、TiKV は休止状態になりません（解放されません）。 | | `raftstore.apply-pool-size` | ディスクにデータをフラッシュするプール内のスレッドの数。これは適用スレッドプールのサイズです。 | @@ -149,7 +149,7 @@ show warnings; | `raftstore.store-max-batch-size` | Raftステートマシンは、BatchSystemによってログをディスクにフラッシュするリクエストをバッチ処理します。この設定項目は、1回のバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 | | `raftstore.store-io-pool-size` | Raft I/Oタスクを処理するスレッドの数。これは StoreWriter スレッドプールのサイズでもあります (この値を 0 以外の値から 0 に、または 0 から 0 以外の値に変更**しないでください**) | | `raftstore.periodic-full-compact-start-max-cpu` | 完全圧縮が有効な場合に TiKV が定期的に完全圧縮を実行する CPU 使用率のしきい値 | -| `readpool.unified.max-thread-count` | 読み取り要求を均一に処理するスレッドプール内のスレッドの最大数。これは UnifyReadPool スレッドプールのサイズです。 | +| `readpool.unified.max-thread-count` | 読み取りリクエストを均一に処理するスレッドプール内のスレッドの最大数。これは UnifyReadPool スレッドプールのサイズです。 | | `readpool.unified.max-tasks-per-worker` | 統合読み取りプール内の 1つのスレッドに許可されるタスクの最大数。値を超えると`Server Is Busy`エラーが返されます。 | | `readpool.unified.auto-adjust-pool-size` | UnifyReadPool スレッドプールのサイズを自動的に調整するかどうかを決定します | | `resource-control.priority-ctl-strategy` | 低優先度タスクのフロー制御戦略を構成します。 | @@ -165,14 +165,14 @@ show warnings; | `pessimistic-txn.in-memory` | メモリ内の悲観的ロックを有効にするかどうかを決定します | | `pessimistic-txn.in-memory-peer-size-limit` | リージョン内のメモリ内悲観的ロックのメモリ使用量制限を制御します | | `pessimistic-txn.in-memory-instance-size-limit` | TiKVインスタンス内のメモリ内悲観的ロックのメモリ使用量制限を制御します | -| `quota.foreground-cpu-time` | TiKVフォアグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフト制限 | +| `quota.foreground-cpu-time` | TiKVフォアグラウンドが読み取りおよび書き込みリクエストを処理するために使用するCPUリソースのソフト制限 | | `quota.foreground-write-bandwidth` | フォアグラウンドトランザクションがデータを書き込む帯域幅のソフト制限 | | `quota.foreground-read-bandwidth` | フォアグラウンドトランザクションとコプロセッサーがデータを読み取る帯域幅のソフト制限 | -| `quota.background-cpu-time` | TiKV バックグラウンドで読み取りおよび書き込み要求を処理するために使用する CPU リソースのソフト制限 | +| `quota.background-cpu-time` | TiKV バックグラウンドで読み取りおよび書き込みリクエストを処理するために使用する CPU リソースのソフト制限 | | `quota.background-write-bandwidth` | バックグラウンドトランザクションがデータを書き込む帯域幅のソフト制限 | | `quota.background-read-bandwidth` | バックグラウンドトランザクションとコプロセッサーがデータを読み取る帯域幅のソフト制限 | | `quota.enable-auto-tune` | クォータの自動調整を有効にするかどうか。この設定項目を有効にすると、TiKV インスタンスの負荷に基づいて、バックグラウンドリクエストのクォータが動的に調整されます。 | -| `quota.max-delay-duration` | 単一の読み取りまたは書き込み要求がフォアグラウンドで処理されるまでに強制的に待機される最大時間 | +| `quota.max-delay-duration` | 単一の読み取りまたは書き込みリクエストがフォアグラウンドで処理されるまでに強制的に待機される最大時間 | | `gc.ratio-threshold` | リージョンGCをスキップするしきい値（GCのバージョン数/キーの数） | | `gc.batch-keys` | 1バッチで処理されるキーの数 | | `gc.max-write-bytes-per-sec` | RocksDBに1秒あたり書き込める最大バイト数 | @@ -220,10 +220,10 @@ show warnings; | storage.flow-control.enable | フロー制御メカニズムを有効にするかどうかを決定します | | storage.flow-control.memtables-threshold | フロー制御をトリガーするkvDB memtablesの最大数 | | storage.flow-control.l0-files-threshold | フロー制御をトリガーするkvDB L0ファイルの最大数 | -| storage.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | -| storage.flow-control.hard-pending-compaction-bytes-limit | フロー制御メカニズムがすべての書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | +| storage.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込みリクエストを拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | +| storage.flow-control.hard-pending-compaction-bytes-limit | フロー制御メカニズムがすべての書き込みリクエストを拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | | `storage.scheduler-worker-pool-size` | スケジューラスレッドプール内のスレッド数 | -| `import.num-threads` | 復元またはインポート RPC 要求を処理するスレッドの数 (動的な変更は v8.1.2 以降でサポートされます) | +| `import.num-threads` | 復元またはインポート RPC リクエストを処理するスレッドの数 (動的な変更は v8.1.2 以降でサポートされます) | | `backup.num-threads` | バックアップ スレッドの数 (v4.0.3 以降でサポート) | | `split.qps-threshold` | リージョンで`load-base-split`を実行するためのしきい値。リージョンの読み取りリクエストのQPSが10秒連続で`qps-threshold`を超える場合、このリージョンは分割される必要があります。 | | `split.byte-threshold` | リージョンで`load-base-split`を実行するためのしきい値。リージョンの読み取りリクエストのトラフィックが10秒間連続して`byte-threshold`を超える場合、このリージョンは分割されます。 | @@ -376,7 +376,7 @@ select @@tidb_slow_log_threshold; ### TiFlash構成を動的に変更する {#modify-tiflash-configuration-dynamically} -現在、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)を使用してTiFlash構成`max_threads`を変更できます。この変数は、 TiFlashが要求を実行するための最大同時実行性を指定します。 +現在、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)を使用してTiFlash構成`max_threads`を変更できます。この変数は、 TiFlashがリクエストを実行するための最大同時実行性を指定します。 `tidb_max_tiflash_threads`のデフォルト値は`-1`で、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`を使用すると、 `max_threads`を10に設定できます。 diff --git a/error-codes.md b/error-codes.md index 99d6fcf8b63bf..cd9f1ad0268d2 100644 --- a/error-codes.md +++ b/error-codes.md @@ -531,7 +531,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 完全なエラーメッセージ: `ERROR 9001 (HY000): PD server timeout` - PD 要求がタイムアウトしました。 + PD リクエストがタイムアウトしました。 PDサーバーのステータス、監視データ、ログ、および TiDBサーバーと PDサーバー間のネットワークを確認します。 @@ -539,7 +539,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 完全なエラーメッセージ: `ERROR 9002 (HY000): TiKV server timeout` - TiKV 要求がタイムアウトしました。 + TiKV リクエストがタイムアウトしました。 TiKVサーバーのステータス、監視データ、ログ、および TiDBサーバーと TiKVサーバー間のネットワークを確認します。 @@ -607,7 +607,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 9012 - TiFlash要求がタイムアウトしました。 + TiFlashリクエストがタイムアウトしました。 TiFlashサーバーの状態/モニター/ログ、および TiDBサーバーとTiFlashサーバー間のネットワークを確認します。 diff --git a/explain-partitions.md b/explain-partitions.md index ebabd0edfd927..0daebb66f8c7b 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -75,7 +75,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 WHERE d = '2017-06-01'; - TiDBは、アクセスする必要があるパーティションが1つだけ（ `p2017` ）であることを正常に識別しました。これは`access object`に記載されています。 - パーティション自体は演算子`└─TableFullScan_19`でスキャンされ、その後`└─Selection_20`適用されて、開始日が`2017-06-01 00:00:00.000000`の行がフィルター処理されました。 - `└─Selection_20`一致する行は、 `count`関数をネイティブに理解するコプロセッサでストリーム集約されます。 -- 次に、各コプロセッサ要求は TiDB 内の`└─TableReader_22`に 1 行を送り返し、それが`StreamAgg_21`にストリーム集約されて、1 行がクライアントに返されます。 +- 次に、各コプロセッサリクエストは TiDB 内の`└─TableReader_22`に 1 行を送り返し、それが`StreamAgg_21`にストリーム集約されて、1 行がクライアントに返されます。 次の例では、パーティションプルーニングによってパーティションが削除されません。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 361fc5bb99731..703e1d1fcc0a8 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -65,7 +65,7 @@ TiDB `label`の設定は、クラスタのデプロイメントアーキテク ### ディスク テストの`dd`コマンドが`oflag=direct`オプションを使用するのはなぜですか? {#why-does-the-dd-command-for-the-disk-test-use-the-oflagdirect-option} -ダイレクト モードでは、書き込み要求を I/O コマンドにラップし、このコマンドをディスクに送信してファイルシステム キャッシュをバイパスし、ディスクの実際の I/O 読み取り/書き込みパフォーマンスを直接テストします。 +ダイレクト モードでは、書き込みリクエストを I/O コマンドにラップし、このコマンドをディスクに送信してファイルシステム キャッシュをバイパスし、ディスクの実際の I/O 読み取り/書き込みパフォーマンスを直接テストします。 ### `fio`コマンドを使用して TiKV インスタンスのディスク パフォーマンスをテストするにはどうすればよいですか? {#how-to-use-the-fio-command-to-test-the-disk-performance-of-the-tikv-instance} diff --git a/follower-read.md b/follower-read.md index 651fb505ee922..29cdaf668c24f 100644 --- a/follower-read.md +++ b/follower-read.md @@ -28,7 +28,7 @@ Follower Read を実行する際、TiDB はトポロジ情報に基づいて適 Follower Read は次のシナリオに適しています。 -- 読み取り要求が集中するアプリケーション、または読み取りホットスポットが顕著なアプリケーション。 +- 読み取りリクエストが集中するアプリケーション、または読み取りホットスポットが顕著なアプリケーション。 - ローカルレプリカからの読み取りを優先して、AZ 間の帯域幅使用量を削減するマルチ AZ デプロイ。 - 全体的な読み取りパフォーマンスをさらに向上させたい読み取り/書き込み分離アーキテクチャ。 @@ -79,8 +79,8 @@ set [session | global] tidb_replica_read = ''; - `tidb_replica_read`の値が`closest-adaptive`に設定されている場合: - - 読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の値である場合、TiDB は読み取り操作に同じアベイラビリティゾーン内のレプリカを選択することを優先します。 アベイラビリティゾーン間で読み取りトラフィックの不均衡な分散を回避するために、TiDB はすべてのオンライン TiDB および TiKV ノードのアベイラビリティゾーンの分散を動的に検出します。各アベイラビリティゾーンでは、 `closest-adaptive`構成が有効になる TiDB ノードの数は制限されており、これは常に TiDB ノードが最も少ないアベイラビリティゾーン内の TiDB ノードの数と同じであり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。たとえば、TiDB ノードが 3つのアベイラビリティゾーン (A、B、C) に分散されていて、A と B にそれぞれ 3つの TiDB ノードが含まれ、C には 2つの TiDB ノードのみが含まれる場合、各アベイラビリティゾーンで`closest-adaptive`構成が有効になる TiDB ノードの数は 2 であり、A および B アベイラビリティゾーンのそれぞれのその他の TiDB ノードは読み取り操作にリーダーレプリカを自動的に選択します。 - - 読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)の値未満の場合、TiDB は読み取り操作に対してリーダーレプリカのみを選択できます。 + - 読み取りリクエストの推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の値である場合、TiDB は読み取り操作に同じアベイラビリティゾーン内のレプリカを選択することを優先します。 アベイラビリティゾーン間で読み取りトラフィックの不均衡な分散を回避するために、TiDB はすべてのオンライン TiDB および TiKV ノードのアベイラビリティゾーンの分散を動的に検出します。各アベイラビリティゾーンでは、 `closest-adaptive`構成が有効になる TiDB ノードの数は制限されており、これは常に TiDB ノードが最も少ないアベイラビリティゾーン内の TiDB ノードの数と同じであり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。たとえば、TiDB ノードが 3つのアベイラビリティゾーン (A、B、C) に分散されていて、A と B にそれぞれ 3つの TiDB ノードが含まれ、C には 2つの TiDB ノードのみが含まれる場合、各アベイラビリティゾーンで`closest-adaptive`構成が有効になる TiDB ノードの数は 2 であり、A および B アベイラビリティゾーンのそれぞれのその他の TiDB ノードは読み取り操作にリーダーレプリカを自動的に選択します。 + - 読み取りリクエストの推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)の値未満の場合、TiDB は読み取り操作に対してリーダーレプリカのみを選択できます。 - `tidb_replica_read`を`learner`に設定すると、TiDB はラーナーレプリカからデータを読み取ります。現在のリージョンで利用可能なラーナーレプリカがない場合、TiDB は利用可能なリーダーレプリカまたはフォロワーレプリカからデータを読み取ります。 @@ -101,7 +101,7 @@ set [session | global] tidb_replica_read = ''; ## 基本的な監視 {#basic-monitoring} -[**TiDB** > **KV 要求**>**読み取り要求トラフィック**パネル (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 を有効にするかどうかを決定し、有効にした後のトラフィック削減効果を確認できます。 @@ -113,7 +113,7 @@ Follower Read には、TiKV 読み取りリクエストをリーダーレプリ ### 強力な一貫性のある読み取り {#strongly-consistent-reads} -フォロワーノードが読み取り要求を処理する際、まずRaftプロトコルの`ReadIndex`を使用してリージョンのリーダーとやり取りし、現在のRaftグループの最新のコミットインデックスを取得します。リーダーの最新のコミットインデックスがフォロワーにローカルに適用された後、読み取り要求の処理が開始されます。 +フォロワーノードが読み取りリクエストを処理する際、まずRaftプロトコルの`ReadIndex`を使用してリージョンのリーダーとやり取りし、現在のRaftグループの最新のコミットインデックスを取得します。リーダーの最新のコミットインデックスがフォロワーにローカルに適用された後、読み取りリクエストの処理が開始されます。 ![read-index-flow](/media/follower-read/read-index.png) diff --git a/generate-self-signed-certificates.md b/generate-self-signed-certificates.md index acf0ddd2681a0..8ea714fffa8bf 100644 --- a/generate-self-signed-certificates.md +++ b/generate-self-signed-certificates.md @@ -103,7 +103,7 @@ TiKV インスタンスに証明書を発行するには、次の手順を実行 IP.4 = 172.16.10.16 ``` -4. `openssl.cnf`ファイルを保存し、証明書要求ファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 +4. `openssl.cnf`ファイルを保存し、証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 ```bash openssl req -new -key tikv.key -out tikv.csr -config openssl.cnf @@ -141,7 +141,7 @@ TiKV インスタンスに証明書を発行するには、次の手順を実行 openssl genrsa -out client.key 2048 ``` -2. 証明書要求ファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 +2. 証明書リクエストファイルを生成します (この手順では、証明書に共通名を割り当てることもできます。共通名は、サーバーがクライアントの ID を検証するために使用されます。各コンポーネントはデフォルトで検証を有効にしませんが、構成ファイルで有効にすることができます)。 ```bash openssl req -new -key client.key -out client.csr diff --git a/global-indexes.md b/global-indexes.md index 36f7eabbb3d6b..8c5bf8c01b24d 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -213,7 +213,7 @@ CREATE TABLE `sbtest` ( `k`に関連するクエリ（例えば`SELECT * FROM sbtest WHERE k > 1`を実行すると、ローカルインデックス`idx`は5つの個別の範囲を生成しますが、グローバルインデックス`global_idx`は1つの範囲のみを生成します。TiDBの各範囲は1つ以上のRPCリクエストに対応するため、グローバルインデックスを使用することでRPCリクエストの数を数倍削減でき、インデックスクエリのパフォーマンスが向上します。 -次の図は、 `idx`と`global_idx`という 2つの異なるインデックスを使用して`SELECT * FROM sbtest WHERE k > 1`ステートメントを実行した場合の RPC 要求とデータフローの違いを示しています。 +次の図は、 `idx`と`global_idx`という 2つの異なるインデックスを使用して`SELECT * FROM sbtest WHERE k > 1`ステートメントを実行した場合の RPC リクエストとデータフローの違いを示しています。 ![Mechanism of Global Indexes](/media/global-index-mechanism.png) diff --git a/glossary.md b/glossary.md index 80321211c5e8d..f4dd00b06c62f 100644 --- a/glossary.md +++ b/glossary.md @@ -179,7 +179,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### Leader／Follower／Learner {#leaderfollowerlearner} -Raftグループ（ [仲間](#regionpeerraft-group)構成）では、Leader、Follower、Learnerがそれぞれ役割を担います。リーダーはすべてのクライアント要求を処理し、フォロワーにデータを複製します。グループリーダーが故障した場合、フォロワーの中から1人が新しいリーダーに選出されます。ラーナーは投票権を持たないフォロワーであり、複製データの追加処理のみに関与します。 +Raftグループ（ [ピア](#regionpeerraft-group)構成）では、Leader、Follower、Learnerがそれぞれ役割を担います。リーダーはすべてのクライアントリクエストを処理し、フォロワーにデータを複製します。グループリーダーが故障した場合、フォロワーの中から1人が新しいリーダーに選出されます。ラーナーは投票権を持たないフォロワーであり、複製データの追加処理のみに関与します。 ### 軽量ディレクトリアクセスプロトコル（LDAP） {#lightweight-directory-access-protocol-ldap} @@ -292,7 +292,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ ### クォータリミッター（Quota Limiter） {#quota-limiter} -クォータリミッターは、TiDB v6.0.0 で導入された実験的機能です。TiKV がデプロイされているマシンにリソース制限がある場合（例えば、CPU が 4V、メモリが 16GB しかない場合）、TiKV のフォアグラウンドが読み書き要求を過剰に処理すると、バックグラウンドで使用される CPU リソースがこれらの要求の処理に使用され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するために、クォータリミッターを[クォータ関連の設定項目](/tikv-configuration-file.md#quota)に設定して、フォアグラウンドで使用される CPU リソースを制限できます。 +クォータリミッターは、TiDB v6.0.0 で導入された実験的機能です。TiKV がデプロイされているマシンにリソース制限がある場合（例えば、CPU が 4V、メモリが 16GB しかない場合）、TiKV のフォアグラウンドが読み書きリクエストを過剰に処理すると、バックグラウンドで使用される CPU リソースがこれらのリクエストの処理に使用され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するために、クォータリミッターを[クォータ関連の設定項目](/tikv-configuration-file.md#quota)に設定して、フォアグラウンドで使用される CPU リソースを制限できます。 ## R {#r} @@ -306,7 +306,7 @@ TiKVクラスタ内のリージョンは、最初は分割されておらず、 リージョン分割の仕組みは、まず1つの初期リージョンを使用して鍵空間全体をカバーし、リージョンのサイズまたは鍵の数が閾値に達するたびに、既存のリージョンを分割して新しいリージョンを生成するというものです。 -### リージョン／仲間／Raftグループ {#regionpeerraft-group} +### リージョン／ピア／Raftグループ {#regionpeerraft-group} TiKV におけるデータストレージの最小単位はリージョンであり、それぞれがデータ範囲 (デフォルトでは 256 MiB) を表します。各リージョンには、デフォルトで 3つのレプリカがあります。リージョンのレプリカはピアと呼ばれます。同じリージョンの複数のピアは、 Raftコンセンサスアルゴリズムを使用してデータを複製するため、ピアもRaftインスタンスのメンバーとなります。TiKV は、マルチ Raft を使用してデータを管理します。つまり、各リージョンには、対応する独立したRaftグループが存在します。 diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index a5bd3c9e7202d..f92054a099709 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -24,15 +24,15 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | PD | Normal stores | 正常状態にあるノードの数。 | | | PD | Abnormal stores | 異常状態にあるノードの数。 | 0 | | PD | Number of Regions | 現在のクラスター内のリージョンの合計数。リージョンの数はレプリカの数とは関係ありません。 | | -| PD | 99% completed_cmds_duration_seconds | pd-server 要求を完了するまでの 99 パーセンタイル期間。 | 5ミリ秒未満 | -| PD | Handle\_requests\_duration\_seconds | PD 要求のネットワーク期間。 | | +| PD | 99% completed_cmds_duration_seconds | pd-server リクエストを完了するまでの 99 パーセンタイル期間。 | 5ミリ秒未満 | +| PD | Handle\_requests\_duration\_seconds | PD リクエストのネットワーク期間。 | | | PD | Region health | 各リージョンの状態。 | 通常、保留中のピアの数は 100 未満であり、不足しているピアの数は必ずしも`0`を超えるとは限りません。 | | PD | Hot write Region's leader distribution | 各 TiKV インスタンスの書き込みホットスポットであるリーダーの合計数。 | | | PD | Hot read Region's leader distribution | 各 TiKV インスタンス上の読み取りホットスポットであるリーダーの合計数。 | | | PD | Region heartbeat report | インスタンスごとに PD に報告されたハートビートの数。 | | | PD | 99% Region heartbeat latency | TiKV インスタンスごとのハートビートレイテンシー(P99)。 | | | TiDB | Statement OPS | 1秒あたりに実行される異なるタイプの SQL文の数。`SELECT` 、 `INSERT` 、 `UPDATE`などの文のタイプに応じてカウントされます。 | | -| TiDB | Duration | 実行時間。
1. クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後にクライアントに返されるまでの時間。通常、クライアント要求はSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。
2. TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ように複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 | | +| TiDB | Duration | 実行時間。
1. クライアントのネットワークリクエストがTiDBに送信されてから、TiDBがリクエストを実行した後にクライアントに返されるまでの時間。通常、クライアントリクエストはSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。
2. TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ように複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 | | | TiDB | CPS By Instance | インスタンス別 CPS: コマンド実行結果の成功または失敗に応じて分類された、各 TiDB インスタンスのコマンド統計。 | | | TiDB | Failed Query OPM | 各TiDBインスタンスにおける1秒あたりのSQL文実行時に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 | | | TiDB | Connection Count | 各 TiDB インスタンスの接続数。 | | @@ -41,10 +41,10 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | TiDB | Transaction Duration | トランザクションの実行時間 | | | TiDB | KV Cmd OPS | 実行された KV コマンドの数。 | | | TiDB | KV Cmd Duration 99 | KV コマンドの実行時間。 | | -| TiDB | PD TSO OPS | TiDB が PD に送信する 1秒あたりの gRPC 要求の数 (cmd) と TSO 要求の数 (request)。各 gRPC 要求には、TSO 要求のバッチが含まれます。 | | +| TiDB | PD TSO OPS | TiDB が PD に送信する 1秒あたりの gRPC リクエストの数 (cmd) と TSO リクエストの数 (request)。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 | | | TiDB | PD TSO Wait Duration | TiDB が PD から TSO が返されるのを待機する期間。 | | | TiDB | TiClient Region Error OPS | TiKV によって返されたリージョン関連エラーの数。 | | -| TiDB | Lock Resolve OPS | ロックを解決したTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、TiDBはロックを解決しようとします。 | | +| TiDB | Lock Resolve OPS | ロックを解決したTiDB操作の数。TiDBの読み取りまたは書き込みリクエストがロックに遭遇すると、TiDBはロックを解決しようとします。 | | | TiDB | KV Backoff OPS | TiKV によって返されたエラーの数。 | | | TiKV | leader | 各 TiKV ノード上のリーダーの数。 | | | TiKV | region | 各 TiKV ノード上のリージョンの数。 | | @@ -56,7 +56,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | TiKV | server report failures | 各 TiKV インスタンスによって報告されたエラーメッセージの数。 | 0 | | TiKV | scheduler pending commands | 各 TiKV インスタンス上の保留中のコマンドの数。 | | | TiKV | coprocessor executor count | TiKVが1秒あたりに受信したコプロセッサ操作の数。コプロセッサの種類ごとに個別にカウントされます。 | | -| TiKV | coprocessor request duration | コプロセッサの読み取り要求を処理するのに費やされた時間。 | | +| TiKV | coprocessor request duration | コプロセッサの読み取りリクエストを処理するのに費やされた時間。 | | | TiKV | raft store CPU | raftstoreスレッドのCPU使用率 | デフォルトのスレッド数は2（ `raftstore.store-pool-size`で設定）です。1つのスレッドの値が80%を超える場合、CPU使用率が非常に高いことを示します。 | | TiKV | Coprocessor CPU | コプロセッサ スレッドの CPU 使用率。 | | | System Info | Vcores | CPU コアの数。 | | diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index 338598d471fec..0bb8beb0b9dd8 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -13,34 +13,34 @@ Grafanaダッシュボードは、PD、TiDB、TiKV、Node_exporter、概要、 - 概要：データベース時間とSQL実行時間の概要。概要で異なる色を確認することで、データベースのワークロードプロファイルとパフォーマンスのボトルネックを素早く特定できます。 -- 負荷プロファイル: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV 要求 OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 +- 負荷プロファイル: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV リクエスト OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 -- トップダウンのレイテンシーの内訳: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV 要求レイテンシー、TiKV 内の書き込みレイテンシーの内訳。 +- トップダウンのレイテンシーの内訳: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV リクエストレイテンシー、TiKV 内の書き込みレイテンシーの内訳。 パフォーマンス概要ダッシュボードを使用すると、パフォーマンスを効率的に分析し、ユーザー応答時間のボトルネックがデータベースにあるかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要、ワークロードプロファイル、SQLレイテンシーの内訳を表示することで、データベース内のボトルネックを特定できます。詳細は[パフォーマンス分析とチューニング](/performance-tuning-methods.md)ご覧ください。 次のセクションでは、パフォーマンス概要ダッシュボードのメトリックについて説明します。 -## パフォーマンスの概要 {#performance-overview} +## Performance Overview {#performance-overview} -### SQLタイプ別のデータベース時間 {#database-time-by-sql-type} +### Database Time by SQL Type {#database-time-by-sql-type} -- データベース時間: 1秒あたりの合計データベース時間 +- database time: 1秒あたりの合計データベース時間 - sql_type: 各タイプのSQL文で1秒あたりに消費されたデータベース時間 -### SQLフェーズ別のデータベース時間 {#database-time-by-sql-phase} +### Database Time by SQL Phase {#database-time-by-sql-phase} -- データベース時間: 1秒あたりの合計データベース時間 -- トークンの取得/解析/コンパイル/実行: 4つのSQL処理フェーズで消費されるデータベース時間 +- database time: 1秒あたりの合計データベース時間 +- get token/parse/compile/execute: 4つのSQL処理フェーズで消費されるデータベース時間 SQL実行フェーズは緑色で、その他のフェーズは全体的に赤色で表示されます。緑色以外の領域が大きい場合は、実行フェーズ以外のフェーズでデータベース時間が大量に消費されていることを意味し、さらなる原因分析が必要です。 -### SQL実行時間の概要 {#sql-execute-time-overview} +### SQL Execute Time Overview {#sql-execute-time-overview} -- 実行時間: SQL 実行中に 1秒あたりに消費されるデータベース時間 +- execute time: SQL 実行中に 1秒あたりに消費されるデータベース時間 - tso_wait: SQL実行中の1秒あたりの同時TSO待機時間 -- KVリクエストタイプ: SQL実行中に各KVリクエストタイプを1秒あたりに待機する時間。KVリクエストは同時実行されるため、合計KVリクエスト待機時間はSQL実行時間を超える場合があります。 -- tiflash_mpp: SQL 実行中に 1秒あたりにTiFlash要求を処理する時間。 +- kv request type: SQL実行中に各KVリクエストタイプを1秒あたりに待機する時間。KVリクエストは同時実行されるため、合計KVリクエスト待機時間はSQL実行時間を超える場合があります。 +- tiflash_mpp: SQL 実行中に 1秒あたりにTiFlashリクエストを処理する時間。 緑のメトリクスは一般的なKV書き込みリクエスト（プリライトやコミットなど）、青のメトリクスは一般的な読み取りリクエスト、紫のメトリクスはTiFlash MPPリクエストを表します。その他の色のメトリクスは、注意が必要な予期しない状況を表します。例えば、悲観的ロックKVリクエストは赤で、TSO待機は濃い茶色で表示されます。 @@ -51,62 +51,62 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### QPS {#qps} -すべて`UPDATE` TiDB インスタンスで 1秒あたりに実行された SQL 文の数 (タイプ別: `SELECT`など`INSERT` +すべての TiDB インスタンスで 1秒あたりに実行された SQL 文の数（タイプ別に収集: `SELECT`、`INSERT`、`UPDATE`など） -### CPSタイプ別 {#cps-by-type} +### CPS By Type {#cps-by-type} タイプに基づいて、すべての TiDB インスタンスによって 1秒あたりに処理されるコマンドの数 -### プランキャッシュOPSを使用したクエリ {#queries-using-plan-cache-ops} +### Queries Using Plan Cache OPS {#queries-using-plan-cache-ops} -- 平均ヒット: すべての TiDB インスタンスで 1秒あたりに実行計画 キャッシュを使用するクエリの数 +- avg-hit: すべての TiDB インスタンスで 1秒あたりに実行計画 キャッシュを使用するクエリの数 - avg-miss: すべての TiDB インスタンスにおける、実行計画 キャッシュを使用していないクエリの数 (1秒あたり) `avg-hit + avg-miss`は`StmtExecute`に等しく、これは 1秒あたりに実行されるすべてのクエリの数です。 -### KV/TSO リクエスト OPS {#kv-tso-request-ops} +### KV/TSO Request OPS {#kv-tso-request-ops} -- kvリクエスト合計: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 -- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1秒あたりの KV リクエスト数 +- kv request total: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 +- kv request by type: `Get`、`Prewrite`、`Commit`などのタイプに基づいて、すべての TiDB インスタンスでの 1秒あたりの KV リクエスト数 - tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 -- tso - リクエスト: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 +- tso - request: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 -通常、 `tso - request`を`tso - cmd`で割った値が、1秒あたりの TSO 要求バッチの平均サイズになります。 +通常、 `tso - request`を`tso - cmd`で割った値が、1秒あたりの TSO リクエストバッチの平均サイズになります。 -### ソース別KVリクエスト時間 {#kv-request-time-by-source} +### KV Request Time By Source {#kv-request-time-by-source} -- kv リクエスト合計時間: すべての TiDB インスタンスで 1秒あたりに KV およびTiFlashリクエストを処理する合計時間 +- kv request total time: すべての TiDB インスタンスで 1秒あたりに KV およびTiFlashリクエストを処理する合計時間 - 各 KV リクエストとそれに対応するリクエストソースは積み上げ棒グラフを形成し、 `external`通常のビジネス リクエストを識別し、 `internal`内部アクティビティ リクエスト (DDL やauto analyzeリクエストなど) を識別します。 ### TiDB CPU {#tidb-cpu} - avg: すべての TiDB インスタンスの平均 CPU 使用率 -- デルタ: すべての TiDB インスタンスの最大 CPU 使用率からすべての TiDB インスタンスの最小 CPU 使用率を引いた値 +- delta: すべての TiDB インスタンスの最大 CPU 使用率からすべての TiDB インスタンスの最小 CPU 使用率を引いた値 - max: すべての TiDB インスタンスの最大 CPU 使用率 ### TiKV CPU/IO MBps {#tikv-cpu-io-mbps} - CPU-Avg: すべての TiKV インスタンスの平均 CPU 使用率 -- CPU デルタ: すべての TiKV インスタンスの最大 CPU 使用率からすべての TiKV インスタンスの最小 CPU 使用率を引いた値 +- CPU-Delta: すべての TiKV インスタンスの最大 CPU 使用率からすべての TiKV インスタンスの最小 CPU 使用率を引いた値 - CPU-MAX: すべての TiKV インスタンス間の最大 CPU 使用率 - IO-Avg: すべての TiKV インスタンスの平均 MBps - IO-Delt: すべての TiKV インスタンスの最大 MBps からすべての TiKV インスタンスの最小 MBps を引いた値 - IO-MAX: すべての TiKV インスタンスの最大 MBps -### 間隔 {#duration} +### Duration {#duration} -- 所要時間: 実行時間 +- Duration: 実行時間 - クライアントからのリクエストをTiDBが受信してから、TiDBがそのリクエストを実行し、結果をクライアントに返すまでの時間。通常、クライアントからのリクエストはSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。 - TiDBはマルチクエリをサポートしています。つまり、クライアントは一度に複数のSQL文（例： `select 1; select 1; select 1;`を送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 -- 平均: すべてのリクエストを実行するのにかかった平均時間 +- avg: すべてのリクエストを実行するのにかかった平均時間 - 99: すべてのリクエストを実行するためのP99期間 -- タイプ別の平均: すべての TiDB インスタンス内のすべてのリクエストを実行するのにかかった平均時間 (タイプ`SELECT` `UPDATE`収集`INSERT` +- avg by type: すべての TiDB インスタンス内のすべてのリクエストを実行するのにかかった平均時間（タイプ別に収集: `SELECT`、`INSERT`、`UPDATE`） -### 接続アイドル時間 {#connection-idle-duration} +### Connection Idle Duration {#connection-idle-duration} 接続アイドル期間は、接続がアイドル状態にある期間を示します。 @@ -114,90 +114,90 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - avg-not-in-txn: 接続がトランザクション内にない場合の平均接続アイドル期間 - 99-in-txn: 接続がトランザクション内にある場合の P99 接続アイドル期間 -### 接続数 {#connection-count} +### Connection Count {#connection-count} -- 合計: すべてのTiDBインスタンスへの接続数 -- アクティブな接続: すべての TiDB インスタンスへのアクティブな接続の数 +- total: すべてのTiDBインスタンスへの接続数 +- active connections: すべての TiDB インスタンスへのアクティブな接続の数 - tidb-{node-number}-peer: 各TiDBインスタンスへの接続数 -- 切断/秒: TiDB クラスタ内の切断回数 +- disconnection/s: TiDB クラスタ内の切断回数 - 99-not-in-txn: 接続がトランザクション内にない場合の P99 接続アイドル期間 -### 解析期間、コンパイル期間、実行期間 {#parse-duration-compile-duration-and-execute-duration} +### Parse Duration, Compile Duration, and Execute Duration {#parse-duration-compile-duration-and-execute-duration} -- 解析時間: SQL文の解析にかかった時間 -- コンパイル時間: 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 -- 実行時間: SQL文の実行計画の実行に要した時間 +- Parse Duration: SQL文の解析にかかった時間 +- Compile Duration: 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 +- Execution Duration: SQL文の実行計画の実行に要した時間 これら3つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 -### 平均 TiDB KV リクエスト期間 {#avg-tidb-kv-request-duration} +### Avg TiDB KV Request Duration {#avg-tidb-kv-request-duration} -`Get` 、 `Prewrite` 、 `Commit`を含むタイプに基づいて、すべての TiDB インスタンスでの KV 要求の実行に費やされた平均時間。 +`Get` 、 `Prewrite` 、 `Commit`を含むタイプに基づいて、すべての TiDB インスタンスでの KV リクエストの実行に費やされた平均時間。 -### 平均 TiKV GRPC 期間 {#avg-tikv-grpc-duration} +### Avg TiKV GRPC Duration {#avg-tikv-grpc-duration} `kv_get` 、 `kv_prewrite` 、 `kv_commit`を含むタイプに基づいて、すべての TiKV インスタンスでの gRPC リクエストの実行に費やされた平均時間。 -### PD TSO 待機/RPC 期間 {#pd-tso-wait-rpc-duration} +### PD TSO Wait/RPC Duration {#pd-tso-wait-rpc-duration} - wait - avg: すべての TiDB インスタンスで PD が TSO を返すのを待つ平均時間 -- rpc - 平均: TiDB が TSO を取得するために PD に gRPC リクエストを送信してから、すべての TiDB インスタンスで TiDB が TSO を受信するまでの平均期間 +- rpc - avg: TiDB が TSO を取得するために PD に gRPC リクエストを送信してから、すべての TiDB インスタンスで TiDB が TSO を受信するまでの平均期間 - wait - 99: すべての TiDB インスタンスで PD が TSO を返すのを待つ P99 期間 -- rpc - 99: TiDB が TSO を取得するために PD に gRPC 要求を送信してから、すべての TiDB インスタンスで TiDB が TSO を受信するまでの P99 期間 +- rpc - 99: TiDB が TSO を取得するために PD に gRPC リクエストを送信してから、すべての TiDB インスタンスで TiDB が TSO を受信するまでの P99 期間 -### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} +### Storage Async Write Duration, Store Duration, and Apply Duration {#storage-async-write-duration-store-duration-and-apply-duration} -- ストレージ非同期書き込み時間: 非同期書き込みにかかる時間 -- ストア期間: 非同期書き込み中にストアループで消費される時間 -- 適用期間: 非同期書き込み中の適用ループで消費された時間 +- Storage Async Write Duration: 非同期書き込みにかかる時間 +- Store Duration: 非同期書き込み中にストアループで消費される時間 +- Apply Duration: 非同期書き込み中の適用ループで消費された時間 これら3つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 平均ストレージ非同期書き込み時間 = 平均保存時間 + 平均適用時間 -### 追加ログ期間、コミットログ期間、適用ログ期間 {#append-log-duration-commit-log-duration-and-apply-log-duration} +### Append Log Duration, Commit Log Duration, and Apply Log Duration {#append-log-duration-commit-log-duration-and-apply-log-duration} -- ログ追加時間: Raftがログを追加するのにかかる時間 -- コミットログ期間: Raftがログをコミットするのにかかる時間 -- ログ適用期間: Raftがログを適用するのにかかる時間 +- Append Log Duration: Raftがログを追加するのにかかる時間 +- Commit Log Duration: Raftがログをコミットするのにかかる時間 +- Apply Log Duration: Raftがログを適用するのにかかる時間 これら3つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 -### パフォーマンス概要パネルのインターフェース {#interface-of-the-performance-overview-panels} +### Interface of the Performance Overview panels {#interface-of-the-performance-overview-panels} ![performance overview](/media/performance/grafana_performance_overview.png) ## TiFlash {#tiflash} - CPU: TiFlashインスタンスごとの CPU 使用率。 -- メモリ: TiFlashインスタンスごとのメモリ使用量。 -- IO 使用率: TiFlashインスタンスごとの IO 使用率。 -- MPP クエリ数: TiFlashインスタンスあたりの 1秒あたりのTiFlash MPP クエリ数。 -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。 +- Memory: TiFlashインスタンスごとのメモリ使用量。 +- IO utilization: TiFlashインスタンスごとの IO 使用率。 +- MPP Query count: TiFlashインスタンスあたりの 1秒あたりのTiFlash MPP クエリ数。 +- Request QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサリクエストの数。 - `batch` : バッチリクエストの数。 - - `batch_cop` : バッチ要求内のコプロセッサ要求の数。 - - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - - `cop_dag` : すべてのコプロセッサ要求内の DAG 要求の数。 + - `batch_cop` : バッチリクエスト内のコプロセッサリクエストの数。 + - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサリクエストの数。 + - `cop_dag` : すべてのコプロセッサリクエスト内の DAG リクエストの数。 - `super_batch` : スーパーバッチ機能を有効にするリクエストの数。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブルスキャン Executor です。`selection`は選択 Executor です。 `aggregation`は集約 Executor です`top_n`は`TopN` Executor です`limit`は制限 Executor です。 -- リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエストタイプについて、1秒あたりの合計処理時間の積み上げグラフを提供します。 -- リクエスト期間: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 -- リクエスト処理時間：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 -- Raft待機インデックス期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信してから、リージョンインデックスが`read_index`になるまで待機する時間です。 -- Raftバッチインデックス読み取り時間: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 -- インスタンスごとの書き込みスループット：インスタンスごとの書き込みスループット。RaftRaftコマンドとRaftスナップショットを適用した場合のスループットも含まれます。 -- 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 -- 読み取りフロー: すべてのTiFlashインスタンスによるディスク読み取りのトラフィック。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブルスキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 +- Request Duration Overview: すべてのTiFlashインスタンスのすべてのリクエストタイプについて、1秒あたりの合計処理時間の積み上げグラフを提供します。 +- Request Duration: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 +- Request Handle Duration：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 +- Raft Wait Index Duration: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`リクエストを受信してから、リージョンインデックスが`read_index`になるまで待機する時間です。 +- Raft Batch Read Index Duration: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 +- Write Throughput By Instance：インスタンスごとの書き込みスループット。Raft書き込みコマンドとRaftスナップショットを適用した場合のスループットも含まれます。 +- Write flow: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 +- Read flow: すべてのTiFlashインスタンスによるディスク読み取りのトラフィック。 ## CDC {#cdc} -- CPU 使用率: TiCDC ノードごとの CPU 使用率。 -- メモリ使用量: TiCDC ノードごとのメモリ使用量。 -- ゴルーチン数: TiCDC ノードあたりのゴルーチンの数。 -- Changefeed チェックポイントラグ: アップストリームとダウンストリーム間のデータ複製の進行ラグ (単位は秒)。 -- Changefeed 解決 ts ラグ: アップストリーム ノードと TiCDC ノード間のデータ複製の進行ラグ (単位は秒)。 -- チェンジフィードのステータス: +- CPU usage: TiCDC ノードごとの CPU 使用率。 +- Memory usage: TiCDC ノードごとのメモリ使用量。 +- Goroutine count: TiCDC ノードあたりのゴルーチンの数。 +- Changefeed checkpoint lag: アップストリームとダウンストリーム間のデータ複製の進行ラグ (単位は秒)。 +- Changefeed resolved ts lag: アップストリーム ノードと TiCDC ノード間のデータ複製の進行ラグ (単位は秒)。 +- The status of changefeeds: - 0: 正常 - 1: エラー @@ -205,11 +205,11 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - 3: 停止 - 4: 完了 - -1: 不明 -- Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1秒あたりに送信する行数。 -- ソーター出力イベント/秒: TiCDC ノードのソーターモジュールがマウント モジュールに 1秒あたりに送信する行数。 -- マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1秒あたりに送信する行数。 -- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーターモジュールがシンク モジュールに 1秒あたりに送信する行数。 -- SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1秒あたりに送信する行数。 -- トランザクションシンクの完全フラッシュ期間: TiCDC ノードの MySQL シンクによるダウンストリーム トランザクションの書き込みの平均レイテンシーと p999レイテンシー。 -- MQ ワーカーのメッセージ送信期間パーセンタイル: ダウンストリームが Kafka の場合の MQ ワーカーによるメッセージ送信のレイテンシー。 -- Kafka 送信バイト: MQ ワークロードでのダウンストリーム トランザクションの書き込みトラフィック。 +- Puller output events/s: TiCDC ノードの Puller モジュールが Sorter モジュールに 1秒あたりに送信する行数。 +- Sorter output events/s: TiCDC ノードのソーターモジュールがマウンター モジュールに 1秒あたりに送信する行数。 +- Mounter output events/s: TiCDC ノードのマウンター モジュールがシンク モジュールに 1秒あたりに送信する行数。 +- Table sink output events/s: TiCDC ノードのテーブル ソーターモジュールがシンク モジュールに 1秒あたりに送信する行数。 +- SinkV2 - Sink flush rows/s: TiCDC ノードのシンク モジュールがダウンストリームに 1秒あたりに送信する行数。 +- Transaction Sink Full Flush Duration: TiCDC ノードの MySQL シンクによるダウンストリーム トランザクションの書き込みの平均レイテンシーと p999レイテンシー。 +- MQ Worker Send Message Duration Percentile: ダウンストリームが Kafka の場合の MQ ワーカーによるメッセージ送信のレイテンシー。 +- Kafka Outgoing Bytes: MQ ワークロードでのダウンストリーム トランザクションの書き込みトラフィック。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 5c283651ae465..3a18e13ab8c40 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -15,34 +15,34 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en このドキュメントでは、リソース コントロール ダッシュボードに表示されるいくつかの主要な監視メトリックについて説明します。 -## リクエストユニットに関するメトリクス {#metrics-about-request-unit} +## Metrics about Request Unit {#metrics-about-request-unit} - RU: 各リソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)の消費情報。リアルタイムで計算されます。`total`は、すべてのリソースグループで消費されるリクエストユニットの合計です。各リソースグループのリクエストユニット消費量は、読み取り消費量（読み取りリクエストユニット）と書き込み消費量（書き込みリクエストユニット）の合計と等しくなります。 -- クエリあたりのRU: 各SQL文が1秒あたりに消費するリクエストユニットの平均数。上記のRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- RU Per Query: 各SQL文が1秒あたりに消費するリクエストユニットの平均数。上記のRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - RRU: リアルタイムで計算される各リソースグループの読み取りリクエストユニット消費情報。`total`は 、すべてのリソースグループによって消費される読み取りリクエストユニットの合計です。 -- クエリあたりのRRU: 各SQL文が1秒あたりに消費する平均読み取りリクエストユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- RRU Per Query: 各SQL文が1秒あたりに消費する平均読み取りリクエストユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - WRU: リアルタイムで計算される各リソースグループの書き込みリクエストユニット消費情報。`total`は 、すべてのリソースグループによって消費される書き込みリクエストユニットの合計です。 -- クエリあたりのWRU: 各SQL文が1秒あたりに消費する書き込みリクエストユニット（WRRU）の平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 利用可能なRU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`の場合、このリソースグループは`RU_PER_SEC`の割合でトークンを消費し、レート制限状態にあるとみなされます。 -- クエリの最大期間: リソースグループに関する最大クエリ期間。 - -## リソースに関する指標 {#metrics-about-resources} - -- KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。`total`は 、すべてのリソースグループのKVリクエストの合計です。 -- クエリあたりのKVリクエスト数: 各SQL文による1秒あたりの読み取りおよび書き込みKVリクエストの平均数。上記のKVリクエスト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 読み取りバイト数: 各リソースグループによって読み取られたデータの量 (1秒あたりに計算)。`total`は 、すべてのリソースグループによって読み取られたデータの合計です。 -- クエリあたりの読み取りバイト数: 各SQL文が1秒あたりに読み取るデータの平均量。上記の読み取りバイト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 書き込みバイト数: 各リソースグループによって書き込まれたデータの量。リアルタイムで計算されます。`total`は 、すべてのリソースグループによって書き込まれたデータの合計です。 -- クエリあたりの書き込みバイト数: 各SQL文が1秒あたりに書き込むデータ量の平均。上記の「書き込みバイト数」メトリックを、1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- KV CPU 時間: 各リソースグループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソースグループで消費された KVレイヤーCPU 時間の合計です。 -- SQL CPU 時間: 各リソースグループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソースグループで消費された SQLレイヤーのCPU 時間の合計です。 - -## リソース コントローラー クライアントに関するメトリクス {#metrics-about-resource-controller-client} - -- アクティブ リソースグループ: リアルタイムで計算された、各リソース コントローラー クライアントのリソースグループの数。 -- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 -- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 -- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 -- 成功した KV 要求の待機期間 (99/90): 各リソース コントローラー クライアントの成功した KV 要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソースグループごとに計算されます。 -- トークン要求処理期間 (999/99): 各リソース コントローラー クライアントのサーバー側からのトークン要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソースグループごとに計算されます。 -- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソースグループごとに計算されます。`successful`と`failed`はすべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 +- WRU Per Query: 各SQL文が1秒あたりに消費する書き込みリクエストユニットの平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- Available RU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`の場合、このリソースグループは`RU_PER_SEC`の割合でトークンを消費し、レート制限状態にあるとみなされます。 +- Query Max Duration: リソースグループに関する最大クエリ期間。 + +## Metrics about resources {#metrics-about-resources} + +- KV Request Count: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。`total`は 、すべてのリソースグループのKVリクエストの合計です。 +- KV Request Count Per Query: 各SQL文による1秒あたりの読み取りおよび書き込みKVリクエストの平均数。上記のKVリクエスト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- Bytes Read: 各リソースグループによって読み取られたデータの量 (1秒あたりに計算)。`total`は 、すべてのリソースグループによって読み取られたデータの合計です。 +- Bytes Read Per Query: 各SQL文が1秒あたりに読み取るデータの平均量。上記の読み取りバイト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- Bytes Written: 各リソースグループによって書き込まれたデータの量。リアルタイムで計算されます。`total`は 、すべてのリソースグループによって書き込まれたデータの合計です。 +- Bytes Written Per Query: 各SQL文が1秒あたりに書き込むデータ量の平均。上記の「書き込みバイト数」メトリックを、1秒あたりに実行されるSQL文の数で割ることで算出されます。 +- KV CPU Time: 各リソースグループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソースグループで消費された KVレイヤーCPU 時間の合計です。 +- SQL CPU Time: 各リソースグループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソースグループで消費された SQLレイヤーのCPU 時間の合計です。 + +## Metrics about Resource Controller Client {#metrics-about-resource-controller-client} + +- Active Resource Groups: リアルタイムで計算された、各リソース コントローラー クライアントのリソースグループの数。 +- Total KV Request Count: 各リソース コントローラー クライアントの KV リクエストの数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの KV リクエストの合計です。 +- Failed KV Request Count: 各リソース コントローラー クライアントの失敗した KV リクエストの数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの失敗した KV リクエストの合計です。 +- Successful KV Request Count: 各リソース コントローラー クライアントの成功した KV リクエストの数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの成功した KV リクエストの合計です。 +- Successful KV Request Wait Duration (99/90): 各リソース コントローラー クライアントの成功した KV リクエストの待機時間 (異なるパーセンタイル)。リアルタイムでリソースグループごとに計算されます。 +- Token Request Handle Duration (999/99): 各リソース コントローラー クライアントのサーバー側からのトークンリクエストの待機時間 (異なるパーセンタイル)。リアルタイムでリソースグループごとに計算されます。 +- Token Request Count: 各リソース コントローラー クライアントに対するサーバー側からのトークンリクエストの数。リアルタイムでリソースグループごとに計算されます。`successful`と`failed`はすべてのリソース コントローラー クライアントの成功したトークンリクエストと失敗したトークンリクエストの合計です。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 16bac0692e9bb..68e91770742da 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -21,7 +21,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### Query Summary {#query-summary} - Duration: 実行時間 - - クライアントのネットワーク要求がTiDBに送信されてから、TiDBがそれを実行した後にクライアントに返されるまでの時間。通常、クライアント要求はSQL文の形式で送信されますが、 `COM_PING`、`COM_SLEEP`、`COM_STMT_FETCH`、`COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります + - クライアントのネットワークリクエストがTiDBに送信されてから、TiDBがそれを実行した後にクライアントに返されるまでの時間。通常、クライアントリクエストはSQL文の形式で送信されますが、 `COM_PING`、`COM_SLEEP`、`COM_STMT_FETCH`、`COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります - TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ような複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 - Command Per Second: コマンド実行結果の成功または失敗に応じて分類される、TiDBによって1秒あたりに処理されるコマンドの数 - QPS: すべての TiDB インスタンスで秒あたりに実行される SQL文の数。`SELECT` 、 `INSERT` 、 `UPDATE`およびその他のタイプの文に従ってカウントされます @@ -105,7 +105,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - KV Backoff Duration: KV再試行リクエストの合計継続時間。TiDBはTiKVへのリクエスト送信時にエラーが発生する可能性があります。TiDBはTiKVへのすべてのリクエストに対して再試行メカニズムを備えています。この`KV Backoff Duration`項目は、リクエストの再試行の合計時間を記録します。 - TiClient Region Error OPS: TiKV によって返されたリージョン関連のエラーメッセージの数 - KV Backoff OPS: TiKVによって返されたエラーメッセージの数 -- Lock Resolve OPS: ロックを解決するためのTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、ロックを解決しようとします。 +- Lock Resolve OPS: ロックを解決するためのTiDB操作の数。TiDBの読み取りまたは書き込みリクエストがロックに遭遇すると、ロックを解決しようとします。 - Other Errors OPS: ロックのクリアや`SafePoint`の更新など、その他の種類のエラーの数 ### KV Request {#kv-request} @@ -122,15 +122,15 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - **cross-zone**: リモートゾーンでステイル読み取りを試みる 1秒あたりのリクエスト数 - **local**: ローカルゾーンでステイル読み取りを試みる1秒あたりのリクエスト数 - Stale Read Req Traffic: - - **cross-zone-in**: リモートゾーンでステイル読み取りを試みる要求に対する応答の着信トラフィック - - **cross-zone-out**: リモートゾーンでステイル読み取りを試みる要求に対する応答の送信トラフィック - - **local-in** : ローカルゾーンでステイル読み取りを試みる要求に対する応答の着信トラフィック - - **local-out** : ローカルゾーンでステイル読み取りを試みる要求の送信トラフィック + - **cross-zone-in**: リモートゾーンでステイル読み取りを試みるリクエストに対する応答の着信トラフィック + - **cross-zone-out**: リモートゾーンでステイル読み取りを試みるリクエストに対する応答の送信トラフィック + - **local-in** : ローカルゾーンでステイル読み取りを試みるリクエストに対する応答の着信トラフィック + - **local-out** : ローカルゾーンでステイル読み取りを試みるリクエストの送信トラフィック - Read Req Traffic - - **leader-local** : ローカルゾーンでのLeader読み取り処理の読み取り要求によって生成されたトラフィック - - **leader-cross-zone** : リモートゾーンでのLeader読み取り処理の読み取り要求によって生成されるトラフィック - - **follower-local** : ローカルゾーンでのFollower Read処理による読み取り要求によって生成されるトラフィック - - **follower-cross-zone** : リモートゾーンでのFollower Read処理による読み取り要求によって生成されるトラフィック + - **leader-local** : ローカルゾーンでのLeader読み取り処理の読み取りリクエストによって生成されたトラフィック + - **leader-cross-zone** : リモートゾーンでのLeader読み取り処理の読み取りリクエストによって生成されるトラフィック + - **follower-local** : ローカルゾーンでのFollower Read処理による読み取りリクエストによって生成されるトラフィック + - **follower-cross-zone** : リモートゾーンでのFollower Read処理による読み取りリクエストによって生成されるトラフィック ### PD Client {#pd-client} @@ -139,7 +139,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - PD Client CMD Fail OPS: PD クライアントによって 1秒あたりに実行された失敗したコマンドの統計 - PD TSO OPS: TiDBがPDに送信する1秒あたりのgRPCリクエスト数（cmd）とTSOリクエスト数（request）。各gRPCリクエストには、TSOリクエストのバッチが含まれています。 - PD TSO Wait Duration: TiDB が PD から TSO が返されるまで待機する時間 -- PD TSO RPC duration: TiDB が TSO を取得するために PD に gRPC 要求を送信してから TiDB が PD から gRPC 応答を受信するまでの期間 +- PD TSO RPC duration: TiDB が TSO を取得するために PD に gRPC リクエストを送信してから TiDB が PD から gRPC 応答を受信するまでの期間 - Async TSO Duration: TiDBがTSOを取得する準備をする時間から、TiDBが実際にPDがTSOを返すのを待ち始める時間までの期間 ### Schema Load {#schema-load} diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index 36b827a52ea52..b7dda974e5bb0 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -179,7 +179,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - ストレージコマンド合計：1秒あたりに受信したコマンドの種類別の数 - ストレージ非同期リクエストエラー：1秒あたりのエンジン非同期リクエストエラーの数 -- ストレージ非同期スナップショット期間: 非同期スナップショット要求の処理に要する時間。 `1s`以内の`.99`未満である必要があります。 +- ストレージ非同期スナップショット期間: 非同期スナップショットリクエストの処理に要する時間。 `1s`以内の`.99`未満である必要があります。 - ストレージ非同期書き込み時間: 非同期書き込みリクエストの処理に要する時間。 `1s`以内の`.99`未満である必要があります。 ![TiKV Dashboard - Storage metrics](/media/tikv-dashboard-storage.png) @@ -187,8 +187,8 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 ### 流量制御 {#flow-control} - スケジューラフロー：各TiKVインスタンスにおけるスケジューラのトラフィックをリアルタイムで表示します。 -- スケジューラ破棄率：各 TiKV インスタンスにおけるスケジューラ要求の拒否率。この比率が 0 より大きい場合、フロー制御が存在することを示します。 `Compaction pending bytes`がしきい値を超えると、TiKV は超過分に基づいて`Scheduler discard ratio`を線形に増加させます。クライアントは拒否された要求を自動的に再試行します。 -- スロットル期間：L0ファイルが多すぎるためにフロー制御がトリガーされた場合に、スケジューラ要求の実行がブロックされる期間。このメトリックに値がある場合、フロー制御が存在していることを示します。 +- スケジューラ破棄率：各 TiKV インスタンスにおけるスケジューラリクエストの拒否率。この比率が 0 より大きい場合、フロー制御が存在することを示します。 `Compaction pending bytes`がしきい値を超えると、TiKV は超過分に基づいて`Scheduler discard ratio`を線形に増加させます。クライアントは拒否されたリクエストを自動的に再試行します。 +- スロットル期間：L0ファイルが多すぎるためにフロー制御がトリガーされた場合に、スケジューラリクエストの実行がブロックされる期間。このメトリックに値がある場合、フロー制御が存在していることを示します。 - スケジューラによるスロットリングCF：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするCF。 - フローコントローラーのアクション：フロー制御のしきい値に達したときにRocksDBのスロットリングをトリガーするアクション。 - フラッシュ/L0フロー：各TiKVインスタンス上のRocksDBの異なるCFにおけるフラッシュとL0圧縮のトラフィック。 @@ -291,7 +291,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - リクエスト処理時間：コプロセッサからのリクエストを受信してから、リクエストの処理が完了するまでの合計時間 - 総リクエスト数：1秒あたりのリクエストの種類別数 -- 処理時間：コプロセッサ要求を実際に処理した時間（1分あたり）のヒストグラム +- 処理時間：コプロセッサリクエストを実際に処理した時間（1分あたり）のヒストグラム - 総リクエストエラー数：コプロセッサーが1秒あたりに発生させたリクエストエラーの数。短時間に多数のエラーが発生するべきではありません。 - 合計 KV カーソル操作: 1秒あたりのタイプ別の KV カーソル操作の合計数。例`select` 、 `index` 、 `analyze_table` 、 `analyze_index` 、 `checksum_table` 、 `checksum_index` 。 - KVカーソル操作：1秒あたりのタイプ別KVカーソル操作のヒストグラム @@ -300,10 +300,10 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 ### コプロセッサーの詳細 {#coprocessor-detail} -- 処理時間：コプロセッサ要求を実際に処理した時間（1分あたり）のヒストグラム -- ストアごとの処理時間（95%）：TiKVインスタンスごとに、コプロセッサ要求を処理するのに要する時間（1秒あたり）（P95） -- 待機時間: コプロセッサ要求が処理されるのを待っている間に消費される時間。 `10s` (P99.99) 未満である必要があります。 -- ストア別待機時間（95%）：コプロセッサ要求が処理待ち状態にある時間（TiKVインスタンスごと、1秒あたり）（P95） +- 処理時間：コプロセッサリクエストを実際に処理した時間（1分あたり）のヒストグラム +- ストアごとの処理時間（95%）：TiKVインスタンスごとに、コプロセッサリクエストを処理するのに要する時間（1秒あたり）（P95） +- 待機時間: コプロセッサリクエストが処理されるのを待っている間に消費される時間。 `10s` (P99.99) 未満である必要があります。 +- ストア別待機時間（95%）：コプロセッサリクエストが処理待ち状態にある時間（TiKVインスタンスごと、1秒あたり）（P95） - 総DAGリクエスト数：1秒あたりのDAGリクエストの総数 - 総DAG実行者数：1秒あたりのDAG実行者の総数 - 総操作数（テーブルスキャン）：コプロセッサでselectスキャンを実行する際の、1秒あたりのRocksDB内部操作数 @@ -416,7 +416,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - Ops: 列ファミリーの1秒あたりの操作数 - 読み取りMBps：RocksDBとインメモリエンジンにおける読み取りトラフィックの総バイト数 -- コプロセッサー処理時間：コプロセッサ要求の処理に要する時間 +- コプロセッサー処理時間：コプロセッサリクエストの処理に要する時間 - リージョンキャッシュヒット数：リージョンキャッシュからデータが正常に取得された回数 - リージョンキャッシュヒット率：リージョンキャッシュのヒット率 - リージョンキャッシュミス理由：リージョンキャッシュからデータが取得されない理由 @@ -460,7 +460,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - 安全時刻の最大差: この TiKV 内のすべてのアクティブな領域の安全時刻と現在時刻との間の最大時間差 - Min Resolved TS Region：resolved-tsが最小であるリージョンのID - Min Safe TS Region：safe-tsが最小であるリージョンのID -- Leader処理時間：リーダー要求の処理に費やされた時間の分布。処理時間は、要求の送信からリーダーでの応答の受信までの時間です。 +- Leader処理時間：リーダーリクエストの処理に費やされた時間の分布。処理時間は、リクエストの送信からリーダーでの応答の受信までの時間です。 - リージョンリーダーにおけるresolved-tsの最大ギャップ：このTiKV内のすべてのアクティブなリージョンのresolved-tsと現在時刻との間の最大時間差（リージョンリーダーのみ）。 - Min Leader Resolved TS Region：resolved-tsが最小値であるリージョンのID（リージョンリーダーのみ）。 - ロックヒープサイズ： resolved-tsモジュールでロックを追跡するヒープのサイズ @@ -516,11 +516,11 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 > > 以下の監視メトリクスはすべてTiDBノードをデータソースとして使用しますが、ログバックアッププロセスに多少の影響を与えます。そのため、参照しやすいように**TiKVの詳細**ダッシュボードに配置されています。TiKVはほとんどの場合、進捗状況を積極的にプッシュしますが、以下の監視メトリクスの一部でサンプリングされたデータが一時的に取得されないのは正常な動作です。 -- リクエストチェックポイントバッチサイズ：ログバックアップコーディネーターが各TiKVのチェックポイント情報を要求する際のリクエストバッチサイズ +- リクエストチェックポイントバッチサイズ：ログバックアップコーディネーターが各TiKVのチェックポイント情報をリクエストする際のリクエストバッチサイズ - ティック期間 [P99|P90]: コーディネーター内のティックにかかる時間 - リージョンチェックポイント失敗理由：リージョンチェックポイントがコーディネーター内で進行できない理由 - リクエスト結果：コーディネーターがリージョンチェックポイントを前進させた際の成功または失敗の記録 -- リージョンオペレーション回数の取得：コーディネーターがPDからリージョン情報を要求した回数 +- リージョンオペレーション回数の取得：コーディネーターがPDからリージョン情報をリクエストした回数 - アドバンストリガー時間：コーディネーターがチェックポイントを進めることを試みるまでにかかる時間 ### バックアップとインポート {#backup--import} diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index df0c35f30507d..60a1c947b8818 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -41,11 +41,11 @@ TiDBを使用すると、SQL実行中に高負荷なクエリを特定できる TiKVコプロセッサータスク関連フィールド: -- `wait_time` : TiKV 内のステートメントにおけるすべてのコプロセッサー要求の合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合でも、要求がキューイングされる可能性があります。キュー内の要求の処理に時間がかかる場合、後続の要求の待機時間が増加します。 -- `request_count` : ステートメントが送信するコプロセッサー要求の数。 +- `wait_time` : TiKV 内のステートメントにおけるすべてのコプロセッサーリクエストの合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合でも、リクエストがキューイングされる可能性があります。キュー内のリクエストの処理に時間がかかる場合、後続のリクエストの待機時間が増加します。 +- `request_count` : ステートメントが送信するコプロセッサーリクエストの数。 - `total_keys` :コプロセッサーがスキャンしたキーの数。 - `processed_keys` :コプロセッサーが処理したキーの数。`total_keys`と比較すると、 `processed_keys`には古いバージョンの MVCC は含まれません。`processed_keys`と`total_keys`の差が大きいことから、古いバージョンが多数存在することがわかります。 -- `num_cop_tasks` : ステートメントが送信するコプロセッサー要求の数。 +- `num_cop_tasks` : ステートメントが送信するコプロセッサーリクエストの数。 - `process_avg_time` :コプロセッサータスクの平均実行時間。 - `process_p90_time` :コプロセッサータスクの P90 実行時間。 - `process_max_time` :コプロセッサータスクの最大実行時間。 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index ba995fab66a90..e8d2ebd13b7fd 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -74,7 +74,7 @@ insert into t select * from t; - `Backoff_time` : ステートメントが再試行を必要とするエラーに遭遇した場合の、再試行までの待機時間。このような一般的なエラーには、 `lock occurs` 、 `Region split` 、および`tikv server is busy`などがあります。 - `Plan` : ステートメントの実行計画。 `SELECT tidb_decode_plan('xxx...')`ステートメントを実行して、具体的な実行計画を解析します。 - `Binary_plan` : バイナリエンコードされたステートメントの実行計画。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行します。 `Plan`および`Binary_plan`フィールドには同じ情報が含まれています。ただし、これら2つのフィールドから解析される実行計画の形式は異なります。 -- `Prepared` : このステートメントが`Prepare`または`Execute`の要求であるかどうか。 +- `Prepared` : このステートメントが`Prepare`または`Execute`のリクエストであるかどうか。 - `Plan_from_cache` : このステートメントが実行プランキャッシュにヒットするかどうか。 - `Plan_from_binding` : このステートメントがバインドされた実行計画を使用するかどうか。 - `Has_more_results` : このステートメントには、ユーザーが取得できる結果がさらにあるかどうか。 @@ -120,7 +120,7 @@ insert into t select * from t; TiKVコプロセッサータスクフィールド： -- `Request_count` : ステートメントが送信するコプロセッサー要求の数。 +- `Request_count` : ステートメントが送信するコプロセッサーリクエストの数。 - `Total_keys` :コプロセッサーがスキャンしたキーの数。 - `Process_time` : TiKV における SQL文の合計処理時間。データは TiKV に同時送信されるため、この値は`Query_time`を超える場合があります。 - `Wait_time` : TiKV におけるステートメントの合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合、リクエストがキューに蓄積される可能性があります。キュー内のリクエストの処理に時間がかかると、後続のリクエストの待機時間が増加します。 diff --git a/information-schema/information-schema-cluster-log.md b/information-schema/information-schema-cluster-log.md index b54f1af65524d..87757626e2476 100644 --- a/information-schema/information-schema-cluster-log.md +++ b/information-schema/information-schema-cluster-log.md @@ -67,5 +67,5 @@ SELECT time,instance,left(message,150) FROM cluster_log WHERE message LIKE '%ddl 上記のクエリ結果は、DDL文を実行するプロセスを示しています。 1. DDL JOB ID が`80`のリクエストが`127.0.0.1:4002` TiDB インスタンスに送信されます。 -2. `127.0.0.1:4000` TiDB インスタンスがこの DDL 要求を処理します。これは、 `127.0.0.1:4000`のインスタンスがその時点で DDL 所有者であることを示します。 +2. `127.0.0.1:4000` TiDB インスタンスがこの DDL リクエストを処理します。これは、 `127.0.0.1:4000`のインスタンスがその時点で DDL 所有者であることを示します。 3. DDL JOB ID が`80`のリクエストが処理されました。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index bf54340131278..f2d1df785b0eb 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -264,7 +264,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | TiDB | tso-duration | pd_tso_wait_duration | 50ミリ秒未満 | トランザクションの TSO を取得するまでの待機時間。 | | TiDB | get-token-duration | tidb_get_token_duration | 1ミリ秒未満 | トークンの取得にかかる時間を照会します。関連するTiDB設定項目は[`token-limit`](/command-line-flags-for-tidb-configuration.md#--token-limit)です。 | | TiDB | load-schema-duration | tidb_load_schema_duration | 1秒未満 | TiDB がスキーマ メタデータを更新するのにかかる時間。 | -| TiKV | scheduler-cmd-duration | tikv_scheduler_command_duration | 0.1秒未満 | TiKV が KV `cmd`要求を実行するのにかかる時間。 | +| TiKV | scheduler-cmd-duration | tikv_scheduler_command_duration | 0.1秒未満 | TiKV が KV `cmd`リクエストを実行するのにかかる時間。 | | TiKV | handle-snapshot-duration | tikv_handle_snapshot_duration | 30秒未満 | TiKV がスナップショットを処理するのにかかる時間。 | | TiKV | storage-write-duration | tikv_storage_async_request_duration | 0.1秒未満 | TiKV の書き込みレイテンシー。 | | TiKV | storage-snapshot-duration | tikv_storage_async_request_duration | 50ミリ秒未満 | TiKV がスナップショットを取得するのにかかる時間。 | diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index ddd49ec6e77e7..e4a6b147c1cee 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -177,9 +177,9 @@ ORDER BY ratio DESC LIMIT 10; 上記のクエリ結果から、次の情報を取得できます。 - 期間 t2 の`tib_slow_query_cop_process_total_time` (TiDB のスロークエリでの時間消費量`cop process` ) は、期間 t1 の 5,865 倍になります。 -- 期間t2における`tidb_distsql_partial_scan_key_total_num` （TiDBの`distsql`が要求するスキャンキー数）は、期間t1の3,648倍です。期間t2における`tidb_slow_query_cop_wait_total_time` （コプロセッサーがTiDBのスロークエリのキューイングを要求する際の待機時間）は、期間t1の267倍です。 -- 期間 t2 の`tikv_cop_total_response_size` (TiKVコプロセッサー要求結果のサイズ) は、期間 t1 の 192 倍になります。 -- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 +- 期間t2における`tidb_distsql_partial_scan_key_total_num` （TiDBの`distsql`がリクエストするスキャンキー数）は、期間t1の3,648倍です。期間t2における`tidb_slow_query_cop_wait_total_time` （TiDBのスロークエリにおいてコプロセッサーリクエストがキューイングされる際の待機時間）は、期間t1の267倍です。 +- 期間 t2 の`tikv_cop_total_response_size` (TiKVコプロセッサーリクエスト結果のサイズ) は、期間 t1 の 192 倍になります。 +- 期間 t2 (TiKVコプロセッサーによってリクエストされたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 上記の結果から、期間t2のコプロセッサーリクエストが期間t1よりもはるかに多いことがわかります。これによりTiKVコプロセッサーが過負荷になり、 `cop task`待機状態になります。期間t2に大規模なクエリが発生し、負荷がさらに増加している可能性があります。 diff --git a/information-schema/information-schema-processlist.md b/information-schema/information-schema-processlist.md index 71295e6c3d12b..93dd2cc40d707 100644 --- a/information-schema/information-schema-processlist.md +++ b/information-schema/information-schema-processlist.md @@ -102,7 +102,7 @@ RESOURCE_GROUP: default - `COMMAND` : `PROCESS`が実行しているコマンドの種類。 - `TIME` : `PROCESS`の現在の実行時間 (秒)。 - `STATE` : 現在の接続状態。 -- `INFO` : 処理中の要求されたステートメント。 +- `INFO` : 処理中のリクエストされたステートメント。 - `DIGEST` : SQL文のダイジェスト。 - `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 - `DISK` : ディスク使用量（バイト単位）。 @@ -124,7 +124,7 @@ RESOURCE_GROUP: default - `COMMAND` : `PROCESS`が実行しているコマンドの種類。 - `TIME` : `PROCESS`の現在の実行時間 (秒)。 - `STATE` : 現在の接続状態。 -- `INFO` : 処理中の要求されたステートメント。 +- `INFO` : 処理中のリクエストされたステートメント。 - `DIGEST` : SQL文のダイジェスト。 - `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 - `DISK` : ディスク使用量（バイト単位）。 diff --git a/latency-breakdown.md b/latency-breakdown.md index 928f0431bd486..361dad69a29f1 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -609,10 +609,10 @@ Diagram( ``` - リクエストの送信にかかる全体的な所要時間は`tidb_tikvclient_request_seconds`と測定されます。 -- RPC クライアントは各ストアへの接続プール (ConnArray という名前) を維持し、各プールにはバッチ要求 (送信) チャネルを持つ BatchConn があります。 +- RPC クライアントは各ストアへの接続プール (ConnArray という名前) を維持し、各プールにはバッチリクエスト (送信) チャネルを持つ BatchConn があります。 - ストアが TiKV であり、バッチサイズが正の場合、バッチが有効になります。これはほとんどの場合に当てはまります。 -- バッチ要求チャネルのサイズは[`tikv-client.max-batch-size`](/tidb-configuration-file.md#max-batch-size) (デフォルトは`128` ) で、エンキューの期間は`tidb_tikvclient_batch_wait_duration`として観測されます。 -- ストリーム要求には`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 +- バッチリクエストチャネルのサイズは[`tikv-client.max-batch-size`](/tidb-configuration-file.md#max-batch-size) (デフォルトは`128` ) で、エンキューの期間は`tidb_tikvclient_batch_wait_duration`として観測されます。 +- ストリームリクエストには`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 まだいくらかのレイテンシーが観測されていますが、 `tidb_tikvclient_request_seconds`は次のように概算できます。 diff --git a/metrics-schema.md b/metrics-schema.md index 6e1005b04e92b..01de2df1c67d2 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -112,7 +112,7 @@ SELECT * FROM information_schema.metrics_tables WHERE table_name='tidb_query_dur フィールドの説明: - `TABLE_NAME` : `metrics_schema`のテーブル名に対応します。この例では、テーブル名は`tidb_query_duration`です。 -- `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータを要求し、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 +- `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータをリクエストし、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 - `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type`の 2つのラベルがあります。 - `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 - `COMMENT` : 監視テーブルの説明。`tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index f601f6f18e592..48d1912d10ac2 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -56,7 +56,7 @@ TiDB、TiKV、PD は 3つの AZ に分散されており、これが最も一般 パフォーマンスはネットワークレイテンシーによって影響を受ける可能性があります。 - 書き込みの場合、すべてのデータは少なくとも2つのAZに複製される必要があります。TiDBは書き込みに2フェーズコミットを使用するため、書き込みレイテンシーは2つのAZ間のネットワークレイテンシーの2倍以上になります。 -- リーダーが読み取り要求を送信する TiDB ノードと同じ AZ にない場合、読み取りパフォーマンスはネットワークレイテンシーの影響も受けます。 +- リーダーが読み取りリクエストを送信する TiDB ノードと同じ AZ にない場合、読み取りパフォーマンスはネットワークレイテンシーの影響も受けます。 - 各TiDBトランザクションは、PDリーダーからタイムスタンプオラクル（TSO）を取得する必要があります。そのため、TiDBとPDリーダーが同じAZにない場合、書き込みリクエストを含む各トランザクションはTSOを2回取得する必要があるため、トランザクションのパフォーマンスはネットワークレイテンシーの影響を受けます。 ### 最適化されたアーキテクチャ {#optimized-architecture} diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 48402fc64fc28..2b84cb109e3ab 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -81,7 +81,7 @@ sequenceDiagram TiDBは、書き込まれたデータが制約を満たしているかどうかを確認します（データ型が正しいこと、NOT NULL制約が満たされていることなど）。**有効なデータは、TiDB内のこのトランザクションのプライベートメモリに格納されます**。 -4. クライアントはコミット要求を発行します。 +4. クライアントはコミットリクエストを発行します。 5. TiDBは2PC方式を採用し、トランザクションの原子性を保証すると同時に、データをストア内に永続化します。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 3fa42cde5ef49..90a3b0a072ef6 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -478,7 +478,7 @@ EXPLAIN SELECT /*+ INDEX_LOOKUP_PUSHDOWN(t1, a) */ a, b FROM t1; - [Follower Read](/follower-read.md)はサポートされていません。 - [ステイル読み取り](/stale-read.md)と[`tidb_snapshot`を使用して履歴データを読み取る](/read-historical-data.md)はサポートされていません。 - プッシュダウンされた`LocalIndexLookUp`演算子は`keep order`をサポートしていません。実行計画にインデックス列に基づく`ORDER BY`が含まれている場合、クエリは通常の`IndexLookUp`にフォールバックします。 -- プッシュダウンされた`LocalIndexLookUp`演算子は、ページング モードでのコプロセッサー要求の送信をサポートしていません。 +- プッシュダウンされた`LocalIndexLookUp`演算子は、ページング モードでのコプロセッサーリクエストの送信をサポートしていません。 - プッシュダウンされた`LocalIndexLookUp`演算子は[コプロセッサーキャッシュ](/coprocessor-cache.md)をサポートしません。 ### NO_INDEX_LOOKUP_PUSHDOWN(t1_name)バージョン8.5.5の新機能 {#no_index_lookup_pushdownt1_name-new-in-v855} diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 4a494caed3a08..ca0c0606fff4a 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -566,12 +566,12 @@ pd-server関連のコンフィグレーション項目 #### `read-base-cost` {#read-base-cost} -- 読み取り要求からRUへの変換の基礎係数 +- 読み取りリクエストからRUへの変換の基礎係数 - デフォルト値: 0.125 #### `write-base-cost` {#write-base-cost} -- 書き込み要求からRUへの変換の基礎係数 +- 書き込みリクエストからRUへの変換の基礎係数 - デフォルト値: 1 #### `read-cost-per-byte` {#read-cost-per-byte} diff --git a/pd-control.md b/pd-control.md index 655557529f572..2b79ef68bd417 100644 --- a/pd-control.md +++ b/pd-control.md @@ -442,7 +442,7 @@ config set service-middleware grpc-rate-limit GetRegion qps 0 config set service-middleware grpc-rate-limit GetRegion concurrency 0 ``` -`service-middleware rate-limit`は、次の HTTP API 要求の最大レートと同時実行性を制御します。 +`service-middleware rate-limit`は、次の HTTP API リクエストの最大レートと同時実行性を制御します。 - `GetRegion` : 指定されたリージョンに関する情報を取得する - `GetStore` : 指定されたストアの情報を取得する diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index f3139d3379e5e..28f35b7acc167 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -28,7 +28,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー ### データベース時間 {#database-time} -データベース時間は、データベースが提供するサービス時間の合計を示します。`ΔT`のデータベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。 +データベース時間は、データベースが提供するサービス時間の合計を示します。`ΔT`のデータベース時間は、データベースがすべてのアプリケーションリクエストを同時に処理するのにかかる時間の合計です。 データベースの時間を取得するには、次のいずれかの方法を使用できます。 @@ -38,17 +38,17 @@ summary: このドキュメントでは、ユーザー応答時間、スルー ## ユーザー応答時間とシステムスループットの関係 {#relationship-between-user-response-time-and-system-throughput} -ユーザー応答時間は、サービス時間、キュー時間、およびユーザー要求を完了するための同時待機時間で構成されます。 +ユーザー応答時間は、サービス時間、キュー時間、およびユーザーリクエストを完了するための同時待機時間で構成されます。 ``` ユーザー応答時間 = サービス時間 + キュー時間 + 同時待機時間 ``` - サービス時間: リクエストを処理するときにシステムが特定のリソースに消費する時間。たとえば、データベースが SQL リクエストを完了するために消費する CPU 時間など。 -- キューイング遅延: システムが要求を処理するときに、特定のリソースのサービスをキューで待機する時間。 +- キューイング遅延: システムがリクエストを処理するときに、特定のリソースのサービスをキューで待機する時間。 - 一貫性遅延: システムがリクエストを処理するときに共有リソースにアクセスできるように、他の同時タスクと通信して連携する時間。 -システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、要求されたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。 +システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、リクエストされたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。 例えば、OLTP負荷を実行しているデータベースシステムでは、CPU使用率が65%を超えると、CPUキューイングとスケジューリングのレイテンシーが大幅に増加します。これは、システムの同時リクエストが完全に独立していないため、これらのリクエストが連携して共有リソースを奪い合う可能性があるためです。例えば、異なるユーザーからのリクエストが、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソース使用率が増加すると、キューイングとスケジューリングのレイテンシーも増加し、共有リソースが時間内に解放されず、他のタスクによる共有リソースの待機時間が長くなります。 diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index 02108381b0f96..ce35372e71b22 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -181,8 +181,8 @@ sequenceDiagram 悲観的トランザクションでは、2PC の前に`Acquire Pessimistic Lock`フェーズが追加されます。このフェーズには、以下の手順が含まれます。 1. (楽観的トランザクションモードと同じ) TiDB はクライアントから`begin`リクエストを受信し、現在のタイムスタンプはこのトランザクションの start_ts です。 -2. TiDBサーバーがクライアントから書き込み要求を受信すると、TiDBサーバーはTiKVサーバーに対して悲観的ロック要求を開始し、ロックはTiKVサーバーに永続化されます。 -3. （楽観的トランザクションモードと同様）クライアントがコミット要求を送信すると、TiDB は楽観的トランザクションモードと同様に 2 フェーズコミットを実行します。 +2. TiDBサーバーがクライアントから書き込みリクエストを受信すると、TiDBサーバーはTiKVサーバーに対して悲観的ロックリクエストを開始し、ロックはTiKVサーバーに永続化されます。 +3. （楽観的トランザクションモードと同様）クライアントがコミットリクエストを送信すると、TiDB は楽観的トランザクションモードと同様に 2 フェーズコミットを実行します。 ```mermaid --- diff --git a/privilege-management.md b/privilege-management.md index 53ff33dece770..f4976f2c008dc 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -525,7 +525,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; 1 row in set (0.00 sec) ``` -このレコードでは、 `Host`と`User`は`root`ユーザーから任意のホスト ( `%` ) から送信された接続要求を受け入れることができると判断します。 `Select_priv`と`Insert_priv`は、ユーザーがグローバルな`Select`および`Insert`権限を持っていることを意味します。 `mysql.user`テーブルの有効範囲はグローバルです。 +このレコードでは、 `Host`と`User`は`root`ユーザーから任意のホスト ( `%` ) から送信された接続リクエストを受け入れることができると判断します。 `Select_priv`と`Insert_priv`は、ユーザーがグローバルな`Select`および`Insert`権限を持っていることを意味します。 `mysql.user`テーブルの有効範囲はグローバルです。 `Host`内の`User`と`mysql.db`は、ユーザーがアクセスできるデータベースを決定します。有効な範囲はデータベースです。 @@ -535,7 +535,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; ### 接続確認 {#connection-verification} -クライアントが接続要求を送信すると、TiDBサーバーはログイン操作を検証します。TiDBサーバーは最初に`mysql.user`テーブルをチェックします。 `User`と`Host`のレコードが接続要求と一致する場合、TiDBサーバーは`authentication_string`を検証します。 +クライアントが接続リクエストを送信すると、TiDBサーバーはログイン操作を検証します。TiDBサーバーは最初に`mysql.user`テーブルをチェックします。 `User`と`Host`のレコードが接続リクエストと一致する場合、TiDBサーバーは`authentication_string`を検証します。 ユーザーの識別は、接続を開始するホスト`Host`とユーザー名`User`の2つの情報に基づいています。ユーザー名が空でない場合、指定されたユーザー名と完全に一致する必要があります。 @@ -543,7 +543,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; ### リクエストの確認 {#request-verification} -接続が成功すると、要求検証プロセスによって、その操作に権限があるかどうかがチェックされます。 +接続が成功すると、リクエスト検証プロセスによって、その操作に権限があるかどうかがチェックされます。 データベース関連のリクエスト（ `INSERT` 、 `UPDATE` ）の場合、リクエスト検証プロセスではまず`mysql.user`テーブルでユーザーのグローバル権限を確認します。権限が付与されている場合は、直接アクセスできます。付与されていない場合は、 `mysql.db`テーブルを確認します。 diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index 63bc6b6c2101c..154903d94377e 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -238,7 +238,7 @@ summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、 - RocksDBの停止を回避するためにスナップショット書き込みプロセスを改善しました - - [読み取り要求を処理するための`LocalReader`スレッドを追加し、読み取り要求の遅延を削減します](https://github.com/tikv/rfcs/pull/17) + - [読み取りリクエストを処理するための`LocalReader`スレッドを追加し、読み取りリクエストの遅延を削減します](https://github.com/tikv/rfcs/pull/17) - [大量の書き込みによる大きなリージョンを回避するために、 `BatchSplit`サポートします](https://github.com/tikv/rfcs/pull/6) diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index faa06a6fe5f03..89270b449618b 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -38,7 +38,7 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL - 根本的な問題を回避するために分離レベル`Read Committed`を禁止する [#7211](https://github.com/pingcap/tidb/pull/7211) - いくつかのケースで`LTRIM` / `RTRIM` / `TRIM`の誤った結果を修正[#7291](https://github.com/pingcap/tidb/pull/7291) - `MaxOneRow`演算子が返される結果が 1 行を超えないことを保証できない問題を修正しました[#7375](https://github.com/pingcap/tidb/pull/7375) - - コプロセッサー要求を範囲が多すぎる場合に分割する[#7454](https://github.com/pingcap/tidb/pull/7454) + - コプロセッサーリクエストを範囲が多すぎる場合に分割する[#7454](https://github.com/pingcap/tidb/pull/7454) - 統計 - 統計動的収集のメカニズムの最適化[#6796](https://github.com/pingcap/tidb/pull/6796) - データが頻繁に更新されると`Auto Analyze`が機能しない問題を修正[#7022](https://github.com/pingcap/tidb/pull/7022) diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index 5a1ca63859deb..dab2ae8a52e4a 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -17,7 +17,7 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 - 定数畳み込みの最適化ルールの強化[#7696](https://github.com/pingcap/tidb/pull/7696) - テーブルデュアルへの伝播後にフィルターがnullになるデータソースを最適化します [#7756](https://github.com/pingcap/tidb/pull/7756) - SQL実行エンジン - - トランザクションにおける読み取り要求のパフォーマンスを最適化する [#7717](https://github.com/pingcap/tidb/pull/7717) + - トランザクションにおける読み取りリクエストのパフォーマンスを最適化する [#7717](https://github.com/pingcap/tidb/pull/7717) - 一部のエグゼキュータにおけるChunkメモリの割り当てコストを最適化する[#7540](https://github.com/pingcap/tidb/pull/7540) - ポイントクエリですべての NULL 値が取得される列によって発生する"index out of range"panicを修正[#7790](https://github.com/pingcap/tidb/pull/7790) - サーバ @@ -51,7 +51,7 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 ## TiKV {#tikv} - パフォーマンス - - コプロセッサ要求の同時実行を最適化する[#3515](https://github.com/tikv/tikv/pull/3515) + - コプロセッサリクエストの同時実行を最適化する[#3515](https://github.com/tikv/tikv/pull/3515) - 新機能 - ログ関数のサポートを追加[#3603](https://github.com/tikv/tikv/pull/3603) - `sha1`関数サポートを追加 [#3612](https://github.com/tikv/tikv/pull/3612) diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index b5a7b8ade6f20..0193dca5baf36 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -43,7 +43,7 @@ TiDB Ansible バージョン: 2.1.18 - 明示的にコミットされたトランザクションで`COMMIT`が失敗した場合、 `COMMIT`の前の最後のステートメントをログに記録します。 [#12747](https://github.com/pingcap/tidb/pull/12747) - TiDBサーバーがSQL文を実行する際に、前の文の保存方法を最適化してパフォーマンスを向上します[#12751](https://github.com/pingcap/tidb/pull/12751) - `skip-grant-table=true`構成の`FLUSH PRIVILEGES`文によって引き起こされるpanic問題を修正 [#12816](https://github.com/pingcap/tidb/pull/12816) - - 短時間に多数の書き込み要求があった場合にパフォーマンスのボトルネックを回避するために、AutoID を適用するデフォルトの最小ステップを`1000`から`30000`に増やします[#12891](https://github.com/pingcap/tidb/pull/12891) + - 短時間に多数の書き込みリクエストがあった場合にパフォーマンスのボトルネックを回避するために、AutoID を適用するデフォルトの最小ステップを`1000`から`30000`に増やします[#12891](https://github.com/pingcap/tidb/pull/12891) - TiDBがパニックになったときに失敗した`Prepared`文がエラーログに出力されない問題を修正しました[#12954](https://github.com/pingcap/tidb/pull/12954) - スロークエリログの`COM_STMT_FETCH`時間レコードがMySQLのものと矛盾する問題を修正しました。 [#12953](https://github.com/pingcap/tidb/pull/12953) - 書き込み競合のエラーメッセージにエラーコードを追加して、原因を素早く特定します[#12878](https://github.com/pingcap/tidb/pull/12878) diff --git a/releases/release-2.1.3.md b/releases/release-2.1.3.md index c6760621e7dfa..64bc3f3c21dba 100644 --- a/releases/release-2.1.3.md +++ b/releases/release-2.1.3.md @@ -47,7 +47,7 @@ summary: TiDB 2.1.3 および TiDB Ansible 2.1.3 がリリースされ、シス - HTTPメソッドを使用した監視情報の取得をサポート [#3855](https://github.com/tikv/tikv/pull/3855) - `data_format` のNULL問題を修正 [#4075](https://github.com/tikv/tikv/pull/4075) -- スキャン要求の範囲の検証を追加[#4124](https://github.com/tikv/tikv/pull/4124) +- スキャンリクエストの範囲の検証を追加[#4124](https://github.com/tikv/tikv/pull/4124) ## ツール {#tools} diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index 8ba318706c15a..7ce8ea8559b33 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -102,6 +102,6 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - バッチでのRaftメッセージの受信と送信をサポート [#3931](https://github.com/tikv/tikv/pull/3913) - 新しいストレージエンジン Titan を導入 [#3985](https://github.com/tikv/tikv/pull/3985) - gRPCをv1.17.2にアップグレード[#4023](https://github.com/tikv/tikv/pull/4023) -- バッチでクライアント要求を受信し、応答を送信することをサポートします。 [#4043](https://github.com/tikv/tikv/pull/4043) +- バッチでクライアントリクエストを受信し、応答を送信することをサポートします。 [#4043](https://github.com/tikv/tikv/pull/4043) - マルチスレッド対応適用 [#4044](https://github.com/tikv/tikv/pull/4044) - マルチスレッドRaftstore サポート [#4066](https://github.com/tikv/tikv/pull/4066) diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 48bd183d5f482..a767c370b1f96 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -83,7 +83,7 @@ TiDB Ansible バージョン: 3.0.0 - より多くのシナリオに適応するためにトランザクション処理ロジックを最適化します。 - デフォルト値の`tidb_disable_txn_auto_retry`を`on`に変更します。これは、自動コミットされないトランザクションは再試行されないことを意味します。 - `tidb_batch_commit`システム変数を追加して、トランザクションを複数のトランザクションに分割し、同時に実行します。 - - `tidb_low_resolution_tso`システム変数を追加して、バッチで取得する TSO の数を制御し、トランザクションが TSO を要求する回数を減らし、一貫性の要件が比較的低いシナリオでのパフォーマンスを向上させます。 + - `tidb_low_resolution_tso`システム変数を追加して、バッチで取得する TSO の数を制御し、トランザクションが TSO をリクエストする回数を減らし、一貫性の要件が比較的低いシナリオでのパフォーマンスを向上させます。 - 分離レベルがSERIALIZABLEに設定されている場合にエラーを報告するかどうかを制御する`tidb_skip_isolation_level_check`変数を追加します。 - `tidb_disable_txn_auto_retry`システム変数を変更して、再試行可能なすべてのエラーで機能するようにします。 - 権限管理 @@ -143,7 +143,7 @@ TiDB Ansible バージョン: 3.0.0 - その他 - etcd をアップグレードして、ログ出力形式の不一致、事前投票でのLeader選択の失敗、リースのデッドロックの問題を解決します。 - ツールによる収集と分析を容易にするために、ログシステムを再構築し、統一されたログフォーマット仕様を開発する - - スケジュール パラメータ、クラスター ラベル情報、TSO 要求、ストア ID、アドレス情報を処理するために PD が消費した時間などの監視メトリックを追加します。 + - スケジュール パラメータ、クラスター ラベル情報、TSO リクエスト、ストア ID、アドレス情報を処理するために PD が消費した時間などの監視メトリックを追加します。 ## TiKV {#tikv} diff --git a/releases/release-3.1.0-beta.2.md b/releases/release-3.1.0-beta.2.md index 46eb1ea3ef58b..e48404113639a 100644 --- a/releases/release-3.1.0-beta.2.md +++ b/releases/release-3.1.0-beta.2.md @@ -51,7 +51,7 @@ TiDB Ansible バージョン: 3.1.0-beta.2 - TiKV - Raftstore - - Hibernate Regions からデータが正しく読み込まれないため、読み取り要求を処理できない問題を修正しました。 [#6450](https://github.com/tikv/tikv/pull/6450) + - Hibernate Regions からデータが正しく読み込まれないため、読み取りリクエストを処理できない問題を修正しました。 [#6450](https://github.com/tikv/tikv/pull/6450) - リーダー移行プロセス中の`ReadIndex`リクエストによって引き起こされるpanic問題を修正しました[#6613](https://github.com/tikv/tikv/pull/6613) - 一部の特殊な状況で休止状態領域が正しく起動しない問題を修正[#6730](https://github.com/tikv/tikv/pull/6730) [#6737](https://github.com/tikv/tikv/pull/6737) [#6972](https://github.com/tikv/tikv/pull/6972) - バックアップ diff --git a/releases/release-3.1.0-ga.md b/releases/release-3.1.0-ga.md index 96c1348740504..d57cd063109f4 100644 --- a/releases/release-3.1.0-ga.md +++ b/releases/release-3.1.0-ga.md @@ -72,7 +72,7 @@ TiDB Ansible バージョン: 3.1.0 GA - レプリカ読み取り によって発生するpanic問題を修正 [#7369](https://github.com/tikv/tikv/pull/7369) [#7418](https://github.com/tikv/tikv/pull/7418) - 復元プロセスで空のリージョンが作成される問題を修正しました [#7419](https://github.com/tikv/tikv/pull/7419) - - 繰り返しのロック解決要求が悲観的トランザクションの原子性を損なう可能性がある問題を修正[#7389](https://github.com/tikv/tikv/pull/7389) + - 繰り返しのロック解決リクエストが悲観的トランザクションの原子性を損なう可能性がある問題を修正[#7389](https://github.com/tikv/tikv/pull/7389) - TiFlash diff --git a/releases/release-3.1.0-rc.md b/releases/release-3.1.0-rc.md index 9b382d12c2396..7bf57a98ba58e 100644 --- a/releases/release-3.1.0-rc.md +++ b/releases/release-3.1.0-rc.md @@ -88,7 +88,7 @@ TiDB Ansible バージョン: 3.1.0-rc - 整合性チェックパラメータを無効にしたときに、既存のキーをトランザクションに挿入してすぐに削除すると競合チェックが失敗したり、データインデックスの不整合が発生したりする問題を修正しました。 [#7112](https://github.com/tikv/tikv/pull/7112) - `TopN`が符号なし整数を比較する際の計算エラーを修正[#7199](https://github.com/tikv/tikv/pull/7199) - Raftstoreにフロー制御メカニズムを導入し、フロー制御がないとログの追跡が遅くなり、クラスターが停止する可能性がある問題と、トランザクションサイズが大きいと TiKV サーバー間の再接続が頻繁に発生する可能性がある問題を解決します[#7087](https://github.com/tikv/tikv/pull/7087) [#7078](https://github.com/tikv/tikv/pull/7078) - - レプリカに送信された保留中の読み取り要求が永久にブロックされる可能性がある問題を修正[#6543](https://github.com/tikv/tikv/pull/6543) + - レプリカに送信された保留中の読み取りリクエストが永久にブロックされる可能性がある問題を修正[#6543](https://github.com/tikv/tikv/pull/6543) - スナップショットを適用することでレプリカの読み取りがブロックされる可能性がある問題を修正 [#7249](https://github.com/tikv/tikv/pull/7249) - リーダーの移行により TiKV がpanicを起こす可能性がある問題を修正[#7240](https://github.com/tikv/tikv/pull/7240) - S3 にデータをバックアップするときにすべての SST ファイルがゼロで埋められる問題を修正しました [#6967](https://github.com/tikv/tikv/pull/6967) diff --git a/releases/release-3.1.1.md b/releases/release-3.1.1.md index 830a35a16bb2f..a52440ea42e8f 100644 --- a/releases/release-3.1.1.md +++ b/releases/release-3.1.1.md @@ -20,7 +20,7 @@ TiDB Ansible バージョン: 3.1.1 - TiFlash - - `handle`目と`version`列をキャッシュして、単一の読み取り要求のディスクI/Oを削減します。 + - `handle`列と`version`列をキャッシュして、単一の読み取りリクエストのディスクI/Oを削減します。 - DeltaTreeエンジンの読み取りおよび書き込みワークロードに関連するグラフィックスをGrafanaに追加します - `Chunk`コーデックの 10 進データエンコードを最適化します - TiFlashの負荷が低いときに開いているファイル記述子の数を減らす diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 27c49a207f931..774e9f3708423 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -96,7 +96,7 @@ TiDB バージョン: 4.0.0 - BR を使用してバックアップするときに発生する`DefaultNotFound`エラーを修正します [#7937](https://github.com/tikv/tikv/pull/7937) - 順序が乱れた`ReadIndex`パケットによるシステムパニックを修正 [#7930](https://github.com/tikv/tikv/pull/7930) - - 読み取り要求コールバック関数が呼び出されないために予期しないエラーが返される問題を修正[#7921](https://github.com/tikv/tikv/pull/7921) + - 読み取りリクエストコールバック関数が呼び出されないために予期しないエラーが返される問題を修正[#7921](https://github.com/tikv/tikv/pull/7921) - TiKV の再起動時にスナップショットファイルを誤って削除することで発生するシステムパニックを修正[#7927](https://github.com/tikv/tikv/pull/7927) - ストレージ暗号化処理ロジックが正しくないため、 `master key`が回転できない問題を修正しました [#7898](https://github.com/tikv/tikv/pull/7898) - ストレージ暗号化が有効になっているときに、スナップショットの受信ファイル`lock cf`が暗号化されない問題を修正しました[#7922](https://github.com/tikv/tikv/pull/7922) diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index a4c06c87e9833..7233e17cc8ed3 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0 RC.1 Release Notes -summary: TiDB 4.0 RC.1は2020年4月28日にリリースされました。このリリースには、TiKV、TiDB、 TiFlash、TiCDC、バックアップ＆リストア（BR）、Placement Driver（PD）の互換性変更、重要なバグ修正、新機能、バグ修正が含まれています。バグ修正では、データの不整合、デッドロック、レプリケーションの失敗などの問題が修正されています。新機能には、コプロセッサー要求をTiFlashにバッチ送信する機能のサポートと、負荷ベースのリージョン分割操作の有効化が含まれます。さらに、 TiFlashはfromUnixTime関数とdateFormat関数のプッシュダウンをサポートするようになりました。 +summary: TiDB 4.0 RC.1は2020年4月28日にリリースされました。このリリースには、TiKV、TiDB、 TiFlash、TiCDC、バックアップ＆リストア（BR）、Placement Driver（PD）の互換性変更、重要なバグ修正、新機能、バグ修正が含まれています。バグ修正では、データの不整合、デッドロック、レプリケーションの失敗などの問題が修正されています。新機能には、コプロセッサーリクエストをTiFlashにバッチ送信する機能のサポートと、負荷ベースのリージョン分割操作の有効化が含まれます。さらに、 TiFlashはfromUnixTime関数とdateFormat関数のプッシュダウンをサポートするようになりました。 --- # TiDB 4.0 RC.1 リリースノート {#tidb-4-0-rc-1-release-notes} @@ -29,7 +29,7 @@ TiDB バージョン: 4.0.0-rc.1 - TiKV - - TiDB からのプローブ要求によって発生するデッドロックの問題を修正 [#7540](https://github.com/tikv/tikv/pull/7540) + - TiDB からのプローブリクエストによって発生するデッドロックの問題を修正 [#7540](https://github.com/tikv/tikv/pull/7540) - トランザクションの最小コミットタイムスタンプがオーバーフローし、データの正確性に影響する可能性がある問題を修正しました[#7638](https://github.com/tikv/tikv/pull/7638) - TiFlash @@ -59,7 +59,7 @@ TiDB バージョン: 4.0.0-rc.1 - TiDB - - コプロセッサー要求をTiFlashにバッチで送信する機能をサポート[#16226](https://github.com/pingcap/tidb/pull/16226) + - コプロセッサーリクエストをTiFlashにバッチで送信する機能をサポート[#16226](https://github.com/pingcap/tidb/pull/16226) - コプロセッサーキャッシュ機能をデフォルトで有効にする[#16710](https://github.com/pingcap/tidb/pull/16710) - SQL文の特別なコメントに登録されたセクションのみを解析する [#16157](https://github.com/pingcap/tidb/pull/16157) - PDおよびTiKVインスタンスの構成を表示するための`SHOW CONFIG`構文の使用をサポート [#16475](https://github.com/pingcap/tidb/pull/16475) @@ -79,7 +79,7 @@ TiDB バージョン: 4.0.0-rc.1 - TiFlash - DeltaTreeエンジンの読み取りおよび書き込みワークロードに関連するメトリックレポートを追加します - - `handle`目と`version`列をキャッシュして、単一の読み取りまたは書き込み要求のディスクI/Oを削減します。 + - `handle`列と`version`列をキャッシュして、単一の読み取りまたは書き込みリクエストのディスクI/Oを削減します。 - `fromUnixTime`と`dateFormat`プッシュダウン関数をサポート - 最初のディスクに従ってグローバル状態を評価し、この評価を報告する - DeltaTreeエンジンの読み取りおよび書き込みワークロードに関連するグラフィックスをGrafanaに追加します diff --git a/releases/release-4.0.0-rc.2.md b/releases/release-4.0.0-rc.2.md index a62f2e7140a15..d2254a566fe2c 100644 --- a/releases/release-4.0.0-rc.2.md +++ b/releases/release-4.0.0-rc.2.md @@ -14,7 +14,7 @@ TiDB バージョン: 4.0.0-rc.2 - TiDB - TiDB Binlogが有効な場合、単一トランザクションのサイズ制限（100 MB）が削除されました。現在、トランザクションのサイズ制限は 10 GB です。ただし、TiDB Binlogが有効で、ダウンストリームが Kafka の場合は、Kafka のメッセージサイズ制限である 1 GB に合わせて`txn-total-size-limit`パラメータを設定してください。 [#16941](https://github.com/pingcap/tidb/pull/16941) - - `CLUSTER_LOG`テーブル照会するときに時間範囲が指定されていない場合は、デフォルトの時間範囲を照会するのではなく、エラーを返して指定された時間範囲を要求するように動作を変更します。 [#17003](https://github.com/pingcap/tidb/pull/17003) + - `CLUSTER_LOG`テーブル照会するときに時間範囲が指定されていない場合は、デフォルトの時間範囲を照会するのではなく、エラーを返して時間範囲の指定をリクエストするように動作を変更します。 [#17003](https://github.com/pingcap/tidb/pull/17003) - `CREATE TABLE`文を使用してパーティションテーブルを作成するときに、サポートされていない`sub-partition`または`linear hash`オプションが指定された場合、オプションが無視されたパーティションテーブルではなく、通常のテーブルが作成されます[#17197](https://github.com/pingcap/tidb/pull/17197) - TiKV diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index 2e6f4eea9f401..a736dbd0ac474 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -22,7 +22,7 @@ TiDB バージョン: 4.0.11 - TiFlash - - コプロセッサースレッドプールを追加して、コプロセッサー要求の実行キューに入れます。これにより、場合によってはメモリ不足（OOM）を回避できます。また、 `cop_pool_size`と`batch_cop_pool_size`設定項目をデフォルト値の`NumOfPhysicalCores * 2`で追加します。 + - コプロセッサースレッドプールを追加して、コプロセッサーリクエストの実行キューに入れます。これにより、場合によってはメモリ不足（OOM）を回避できます。また、 `cop_pool_size`と`batch_cop_pool_size`設定項目をデフォルト値の`NumOfPhysicalCores * 2`で追加します。 ## 改善点 {#improvements} diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index bb8b5590e7b11..7022b3c6c6e90 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -55,7 +55,7 @@ TiDB バージョン: 4.0.15 - Backup & Restore (BR) - 領域を同時に分割して分散させることで、復元速度が向上します[#1363](https://github.com/pingcap/br/pull/1363) - - PD 要求エラーまたは TiKV I/O タイムアウトエラーが発生した場合は、 BRタスクを再試行します[#27787](https://github.com/pingcap/tidb/issues/27787) + - PD リクエストエラーまたは TiKV I/O タイムアウトエラーが発生した場合は、 BRタスクを再試行します[#27787](https://github.com/pingcap/tidb/issues/27787) - 多数の小さなテーブルをリストアするときに空のリージョンを減らして、リストア後のクラスタ操作に影響を与えないようにします[#1374](https://github.com/pingcap/br/issues/1374) - テーブルの作成中に`rebase auto id`操作を実行すると、別の`rebase auto id` DDL操作が節約され、 復元が高速化されます。 [#1424](https://github.com/pingcap/br/pull/1424) diff --git a/releases/release-4.0.2.md b/releases/release-4.0.2.md index 8349e243cbb40..6053b7d32beaa 100644 --- a/releases/release-4.0.2.md +++ b/releases/release-4.0.2.md @@ -133,7 +133,7 @@ TiDB バージョン: 4.0.2 - `tidb_replica_read` `follower`に設定され、リーダーとフォロワー/ラーナー間にネットワークパーティションがある場合にフォロワー/ラーナーが再試行を続ける問題を修正しました。 [#17443](https://github.com/pingcap/tidb/pull/17443) - TiDBがPDフォロワーにpingを送信しすぎる場合がある問題を修正[#17947](https://github.com/pingcap/tidb/pull/17947) - TiDB v4.0 で古いバージョンの範囲パーティションテーブルをロードできない問題を修正しました [#17983](https://github.com/pingcap/tidb/pull/17983) - - 各リージョンに異なる`Backoffer`を割り当てることで、複数のリージョン要求が同時に失敗した場合の SQL文のタイムアウト問題を修正しました[#17585](https://github.com/pingcap/tidb/pull/17585) + - 各リージョンに異なる`Backoffer`を割り当てることで、複数のリージョンリクエストが同時に失敗した場合の SQL文のタイムアウト問題を修正しました[#17585](https://github.com/pingcap/tidb/pull/17585) - `DateTime`区切り文字を解析する際の MySQL 非互換の動作を修正 [#17501](https://github.com/pingcap/tidb/pull/17501) - TiKVリクエストがTiFlashサーバーに時々送信される問題を修正 [#18105](https://github.com/pingcap/tidb/pull/18105) - あるトランザクションで書き込まれ、削除された主キーのロックが別のトランザクションによって解決されたために発生したデータの不整合の問題を修正しました[#18250](https://github.com/pingcap/tidb/pull/18250) diff --git a/releases/release-4.0.7.md b/releases/release-4.0.7.md index 5e49f7172d8a6..34ca095a87aad 100644 --- a/releases/release-4.0.7.md +++ b/releases/release-4.0.7.md @@ -65,7 +65,7 @@ TiDB バージョン: 4.0.7 - copタスクストアが異なるタイプであってもプランダイジェストが同じになる問題を修正[#20076](https://github.com/pingcap/tidb/pull/20076) - `!= any()`関数の誤った動作を修正 [#20062](https://github.com/pingcap/tidb/pull/20062) - `slow-log`ファイルが存在しない場合に発生するクエリエラーを修正[#20051](https://github.com/pingcap/tidb/pull/20051) - - コンテキストがキャンセルされたときにリージョン要求が再試行され続ける問題を修正[#20031](https://github.com/pingcap/tidb/pull/20031) + - コンテキストがキャンセルされたときにリージョンリクエストが再試行され続ける問題を修正[#20031](https://github.com/pingcap/tidb/pull/20031) - ストリーミングリクエストで`cluster_slow_query`のテーブルの時間型をクエリするとエラーが発生する可能性がある問題を修正しました[#19943](https://github.com/pingcap/tidb/pull/19943) - `case when`を使用する DML文がスキーマ変更を引き起こす可能性がある問題を修正しました [#20095](https://github.com/pingcap/tidb/pull/20095) - スローログの`prev_stmt`情報が秘匿化されない問題を修正[#20048](https://github.com/pingcap/tidb/pull/20048) diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 9869c77874e4b..9f1e61e504d42 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -176,8 +176,8 @@ SQLパフォーマンスの問題をトラブルシューティングする際 - `EXPLAIN ANALYZE`は、すべてのDML文の分析をサポートし、実際のパフォーマンスプランと各オペレーターの実行情報を表示します[#18056](https://github.com/pingcap/tidb/issues/18056) - ユーザーは`EXPLAIN FOR CONNECTION`を使用して、実行中のSQL文のステータス情報を分析できます。この情報には、各オペレーターの実行時間と処理された行数が含まれます[#18233](https://github.com/pingcap/tidb/issues/18233) -- `EXPLAIN ANALYZE`の出力には、オペレーターによって送信された RPC 要求の数、ロック競合の解決にかかる時間、ネットワークレイテンシー、RocksDB でスキャンされた削除済みデータの量、RocksDB キャッシュのヒット率など、さらに詳しい情報が含まれています[#18663](https://github.com/pingcap/tidb/issues/18663) -- SQL文の詳細な実行情報はスローログに記録されます。これは`EXPLAIN ANALYZE`の出力情報と一致しています。この情報には、各オペレーターの実行時間、処理された行数、送信されたRPC要求の数などが含まれます[#15009](https://github.com/pingcap/tidb/issues/15009) +- `EXPLAIN ANALYZE`の出力には、オペレーターによって送信された RPC リクエストの数、ロック競合の解決にかかる時間、ネットワークレイテンシー、RocksDB でスキャンされた削除済みデータの量、RocksDB キャッシュのヒット率など、さらに詳しい情報が含まれています[#18663](https://github.com/pingcap/tidb/issues/18663) +- SQL文の詳細な実行情報はスローログに記録されます。これは`EXPLAIN ANALYZE`の出力情報と一致しています。この情報には、各オペレーターの実行時間、処理された行数、送信されたRPCリクエストの数などが含まれます[#15009](https://github.com/pingcap/tidb/issues/15009) [ユーザードキュメント](/sql-statements/sql-statement-explain.md) diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index e50d16c763525..c0659df50c66b 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -50,7 +50,7 @@ TiDB バージョン: 5.0.6 - Backup & Restore (BR) - - PD 要求エラーまたは TiKV I/O タイムアウトエラーが発生した場合は、 BRタスクを再試行します[#27787](https://github.com/pingcap/tidb/issues/27787) + - PD リクエストエラーまたは TiKV I/O タイムアウトエラーが発生した場合は、 BRタスクを再試行します[#27787](https://github.com/pingcap/tidb/issues/27787) - 復元の堅牢性を向上させる[#27421](https://github.com/pingcap/tidb/issues/27421) - TiDB Lightning diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 2cbb36cafdf42..7672e0e63b83c 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -167,7 +167,7 @@ TiDB バージョン: 5.1.0 - TiKVバックグラウンドタスク用の書き込みレート制限機能を追加する（TiKV書き込みレート制限機能） - 読み取りおよび書き込み要求の継続時間の安定性を確保するため、TiKV 書き込みレートリミッターは、GC や圧縮などの TiKV バックグラウンドタスクの書き込みトラフィックを平滑化します。TiKV バックグラウンドタスク書き込みレートリミッターのデフォルト値は"0MB"です。この値は、クラウドディスクメーカーが指定する最大 I/O 帯域幅など、ディスクの最適な I/O 帯域幅に設定することをお勧めします。 + 読み取りおよび書き込みリクエストの継続時間の安定性を確保するため、TiKV 書き込みレートリミッターは、GC や圧縮などの TiKV バックグラウンドタスクの書き込みトラフィックを平滑化します。TiKV バックグラウンドタスク書き込みレートリミッターのデフォルト値は"0MB"です。この値は、クラウドディスクメーカーが指定する最大 I/O 帯域幅など、ディスクの最適な I/O 帯域幅に設定することをお勧めします。 [ユーザー向けドキュメント](/tikv-configuration-file.md#storageio-rate-limit)、 [#9156](https://github.com/tikv/tikv/issues/9156) diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index 57d13cf4fb340..4adc5f8c25fd0 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -56,7 +56,7 @@ TiDB バージョン: 5.1.1 - 未確定エラーの可能性を減らすために、事前書き込みリクエストを可能な限りべき等にします[#10586](https://github.com/tikv/tikv/pull/10586) - 多数の期限切れコマンドを処理する際のスタックオーバーフローのリスクを防ぐ[#10502](https://github.com/tikv/tikv/pull/10502) - - `max_ts` を更新するためにステイル読み取り要求の`start_ts`を使用しないことで、コミット要求の過度な再試行を回避します。 [#10451](https://github.com/tikv/tikv/pull/10451) + - `max_ts` を更新するためにステイル読み取りリクエストの`start_ts`を使用しないことで、コミットリクエストの過度な再試行を回避します。 [#10451](https://github.com/tikv/tikv/pull/10451) - 読み取り準備と書き込み準備は別々に処理して読み取りレイテンシーを削減する[#10592](https://github.com/tikv/tikv/pull/10592) - I/Oレート制限が有効になっている場合のデータインポート速度への影響を軽減します[#10390](https://github.com/tikv/tikv/pull/10390) - Raft gRPC接続間の負荷分散を改善する[#10495](https://github.com/tikv/tikv/pull/10495) diff --git a/releases/release-5.1.2.md b/releases/release-5.1.2.md index d501d71f33153..84d96c95b1573 100644 --- a/releases/release-5.1.2.md +++ b/releases/release-5.1.2.md @@ -101,7 +101,7 @@ TiDB バージョン: 5.1.2 - 破損したスナップショットファイルによって引き起こされる潜在的なディスクフル問題を修正[#10813](https://github.com/tikv/tikv/issues/10813) - TiKVコプロセッサのスローログに、リクエスト処理に費やされた時間のみを考慮するようにする [#10841](https://github.com/tikv/tikv/issues/10841) - スロガースレッドが過負荷になりキューがいっぱいになったときに、スレッドをブロックする代わりにログをドロップする[#10841](https://github.com/tikv/tikv/issues/10841) - - コプロセッサー要求の処理がタイムアウトしたときに発生するpanic問題を修正しました[#10852](https://github.com/tikv/tikv/issues/10852) + - コプロセッサーリクエストの処理がタイムアウトしたときに発生するpanic問題を修正しました[#10852](https://github.com/tikv/tikv/issues/10852) - Titan が有効になっている 5.0 より前のバージョンからアップグレードするときに発生する TiKV panic問題を修正しました[#10842](https://github.com/tikv/tikv/pull/10842) - 新しいバージョンのTiKVをv5.0.xにロールバックできない問題を修正しました[#10842](https://github.com/tikv/tikv/pull/10842) - TiKV が RocksDB にデータを取り込む前にファイルを削除する可能性がある問題を修正しました [#10438](https://github.com/tikv/tikv/issues/10438) diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index 0108a7c1c66ea..efe98658a8d06 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -14,7 +14,7 @@ TiDB バージョン: 5.1.4 - TiDB - システム変数[`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510)のデフォルト値を`2`から`1`に変更します[#31748](https://github.com/pingcap/tidb/issues/31748) - - v5.1.4以降、TiKVが`storage.enable-ttl = true`に設定されている場合、TiKVのTTL機能は[RawKVモード](https://tikv.org/docs/5.1/concepts/explore-tikv-features/ttl/) のみをサポートしているため、TiDBからの要求は拒否されます。 [#27303](https://github.com/pingcap/tidb/issues/27303) + - v5.1.4以降、TiKVが`storage.enable-ttl = true`に設定されている場合、TiKVのTTL機能は[RawKVモード](https://tikv.org/docs/5.1/concepts/explore-tikv-features/ttl/) のみをサポートしているため、TiDBからのリクエストは拒否されます。 [#27303](https://github.com/pingcap/tidb/issues/27303) - ツール @@ -91,7 +91,7 @@ TiDB バージョン: 5.1.4 - 新しい選出が終了した後に`Prepare Merge`トリガーされたが、分離されたピアに通知されない場合のメタデータ破損の問題を修正しました[#11526](https://github.com/tikv/tikv/issues/11526) - コルーチンの実行速度が速すぎる場合に時々発生するデッドロックの問題を修正しました[#11549](https://github.com/tikv/tikv/issues/11549) - フレームグラフのプロファイリング時に発生する可能性のあるデッドロックとメモリリークの問題を修正[#11108](https://github.com/tikv/tikv/issues/11108) - - 悲観的トランザクションで事前書き込み要求を再試行するときにまれに発生するデータの不整合の問題を修正[#11187](https://github.com/tikv/tikv/issues/11187) + - 悲観的トランザクションで事前書き込みリクエストを再試行するときにまれに発生するデータの不整合の問題を修正[#11187](https://github.com/tikv/tikv/issues/11187) - 設定`resource-metering.enabled`が動作しないバグを修正[#11235](https://github.com/tikv/tikv/issues/11235) - `resolved_ts` で一部のコルーチンがリークする問題を修正 [#10965](https://github.com/tikv/tikv/issues/10965) - 書き込みフローが低い場合に"GC can not work"という誤った警告が報告される問題を修正[#9910](https://github.com/tikv/tikv/issues/9910) diff --git a/releases/release-5.1.5.md b/releases/release-5.1.5.md index 952600382815e..2ba782d326884 100644 --- a/releases/release-5.1.5.md +++ b/releases/release-5.1.5.md @@ -45,7 +45,7 @@ TiDBバージョン：5.1.5 - TiKVとTiFlashが論理演算を照会した際に異なる結果を返す問題を修正しました [#37258](https://github.com/pingcap/tidb/issues/37258) - `EXECUTE`文が特定のシナリオで予期しないエラーを発生させる可能性がある問題を修正しました [#37187](https://github.com/pingcap/tidb/issues/37187) - `tidb_opt_agg_push_down`と`tidb_enforce_mpp`が有効になっている場合に発生するプランナーの誤った動作を修正します [#34465](https://github.com/pingcap/tidb/issues/34465) - - TiDBが`SHOW COLUMNS`ステートメントを実行する際にコプロセッサ要求を送信する可能性があるバグを修正しました [#36496](https://github.com/pingcap/tidb/issues/36496) + - TiDBが`SHOW COLUMNS`ステートメントを実行する際にコプロセッサリクエストを送信する可能性があるバグを修正しました [#36496](https://github.com/pingcap/tidb/issues/36496) - `lock tables`フラグが有効になっていない場合に、 `unlock tables`と`enable-table-lock`に対する警告を追加する [#28967](https://github.com/pingcap/tidb/issues/28967) - 範囲パーティションで複数の`MAXVALUE`パーティションが許可される問題を修正 [#36329](https://github.com/pingcap/tidb/issues/36329) @@ -72,7 +72,7 @@ TiDBバージョン：5.1.5 - PDリーダーの移籍後に削除されたtombstoneストアが再び表示される問題を修正しました[#4941](https://github.com/tikv/pd/issues/4941) - PDリーダーの転送後すぐにスケジューリングを開始できない問題を修正します [#4769](https://github.com/tikv/pd/issues/4769) - `not leader` の誤ったステータスコードを修正します。 [#4797](https://github.com/tikv/pd/issues/4797) - - PDがダッシュボードプロキシ要求を正しく処理できない問題を修正 [#5321](https://github.com/tikv/pd/issues/5321) + - PDがダッシュボードプロキシリクエストを正しく処理できない問題を修正 [#5321](https://github.com/tikv/pd/issues/5321) - TSOフォールバックの特定の特殊ケースにおけるバグを修正 [#4884](https://github.com/tikv/pd/issues/4884) - 特定のシナリオでTiFlashラーナーレプリカが作成されない可能性がある問題を修正しました [#5401](https://github.com/tikv/pd/issues/5401) - ラベル分布にメトリクスに残余ラベルが含まれる問題を修正 [#4825](https://github.com/tikv/pd/issues/4825) diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index 2f6ec89bfe17a..45d2e22ae4826 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -55,8 +55,8 @@ TiDB バージョン: 5.2.0 | TiKV設定ファイル | [`storage.flow-control.enable`](/tikv-configuration-file.md#enable) | 新しく追加された | フロー制御メカニズムを有効にするかどうかを決定します。デフォルト値は`true`です。 | | TiKV設定ファイル | [`storage.flow-control.memtables-threshold`](/tikv-configuration-file.md#memtables-threshold) | 新しく追加された | kvDB の memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`5`です。 | | TiKV設定ファイル | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | 新しく追加された | kvDB L0 ファイルの数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`9`です。 | -| TiKV設定ファイル | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は"192GB"です。 | -| TiKV設定ファイル | [`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は"1024GB"です。 | +| TiKV設定ファイル | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は"192GB"です。 | +| TiKV設定ファイル | [`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は"1024GB"です。 | ### その他 {#others} diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md index 59b6205182ce3..3bbccf748f22e 100644 --- a/releases/release-5.2.2.md +++ b/releases/release-5.2.2.md @@ -86,7 +86,7 @@ TiDB バージョン: 5.2.2 - `resolved_ts` で一部のコルーチンがリークする問題を修正 [#10965](https://github.com/tikv/tikv/issues/10965) - 応答サイズが4GiBを超えるとコプロセッサに発生するpanic問題を修正[#9012](https://github.com/tikv/tikv/issues/9012) - スナップショットファイルがガベージコレクションできない場合に、スナップショット ガベージコレクション (GC) で GC スナップショットファイルが失われる問題を修正しました[#10813](https://github.com/tikv/tikv/issues/10813) - - コプロセッサー要求の処理中にタイムアウトによって発生するpanic問題を修正[#10852](https://github.com/tikv/tikv/issues/10852) + - コプロセッサーリクエストの処理中にタイムアウトによって発生するpanic問題を修正[#10852](https://github.com/tikv/tikv/issues/10852) - PD diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index f2ff3e5c9ed16..54717e9e85da7 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -110,7 +110,7 @@ TiDBバージョン：5.2.4 - 極端な状況下でリージョンマージ、ConfChange、スナップショットが同時に発生した際に発生するpanic問題を修正します [#11475](https://github.com/tikv/tikv/issues/11475) - tikv-ctlが正しいリージョン関連情報を返せないバグを修正 [#11393](https://github.com/tikv/tikv/issues/11393) - 小数除算の結果がゼロの場合に負の符号が発生する問題を修正 [#29586](https://github.com/pingcap/tidb/issues/29586) - - 悲観的トランザクションモードでプリライト要求を再試行すると、まれにデータ不整合のリスクが発生する可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) + - 悲観的トランザクションモードでプリライトリクエストを再試行すると、まれにデータ不整合のリスクが発生する可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) - 統計スレッドのデータ監視によって引き起こされるメモリリークを修正 [#11195](https://github.com/tikv/tikv/issues/11195) - TiKVメトリクスにおけるインスタンスごとのgRPCリクエストの平均レイテンシーが不正確である問題を修正しました [#11299](https://github.com/tikv/tikv/issues/11299) - ピアの状態が`Applying`のときにスナップショットファイルを削除すると発生するpanic問題を修正します [#11746](https://github.com/tikv/tikv/issues/11746) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index 48a75b853d8d8..4b1f5c010da84 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -35,7 +35,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 | [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40) | 変更 | 一時テーブルが TiDB でサポートされるようになったため、 `CREATE TEMPORARY TABLE`と`DROP TEMPORARY TABLE` `tidb_enable_noop_functions`を有効にする必要がなくなりました。 | | [`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530) | 新しく追加された | テーブルの統計情報が期限切れになった場合のオプティマイザの動作を制御します。デフォルト値は`ON`です。テーブル内の変更された行数が総行数の80%を超える場合（この比率は設定[`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)で調整できます）、オプティマイザは総行数以外の統計情報は信頼できないと判断し、代わりに疑似統計情報を使用します。値を`OFF`に設定すると、統計情報が期限切れになってもオプティマイザは引き続きそれらを使用します。 | | [`tidb_enable_tso_follower_proxy`](/system-variables.md#tidb_enable_tso_follower_proxy-new-in-v530) | 新しく追加された | TSOFollowerプロキシ機能を有効または無効にします。デフォルト値は`OFF`で、これはTSOFollowerプロキシ機能が無効であることを意味します。この場合、TiDBはPDリーダーからのみTSOを取得します。この機能を有効にすると、TiDBはTSOを取得する際にすべてのPDノードに均等にリクエストを送信します。PDフォロワーはTSOリクエストを転送することで、PDリーダーのCPU負荷を軽減します。 | -| [`tidb_tso_client_batch_max_wait_time`](/system-variables.md#tidb_tso_client_batch_max_wait_time-new-in-v530) | 新しく追加された | TiDBがPDにTSOを要求した際に、バッチ保存操作の最大待機時間を設定します。デフォルト値は`0`で、追加の待機時間はありません。 | +| [`tidb_tso_client_batch_max_wait_time`](/system-variables.md#tidb_tso_client_batch_max_wait_time-new-in-v530) | 新しく追加された | TiDBがPDにTSOをリクエストした際に、バッチ保存操作の最大待機時間を設定します。デフォルト値は`0`で、追加の待機時間はありません。 | | [`tidb_tmp_table_max_size`](/system-variables.md#tidb_tmp_table_max_size-new-in-v530) | 新しく追加された | [一時テーブル](/temporary-tables.md)個の最大サイズを制限します。一時テーブルがこのサイズを超えるとエラーが発生します。 | ### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} @@ -144,7 +144,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 - **PDのタイムスタンプ処理フローを最適化** - TiDBは、PDFollowerプロキシを有効にし、PDクライアントがTSOをバッチで要求する際に必要なバッチ待機時間を変更することで、タイムスタンプ処理フローを最適化し、PDのタイムスタンプ処理負荷を軽減します。これにより、システム全体のスケーラビリティが向上します。 + TiDBは、PDFollowerプロキシを有効にし、PDクライアントがTSOをバッチでリクエストする際に必要なバッチ待機時間を変更することで、タイムスタンプ処理フローを最適化し、PDのタイムスタンプ処理負荷を軽減します。これにより、システム全体のスケーラビリティが向上します。 - システム変数[`tidb_enable_tso_follower_proxy`](/system-variables.md#tidb_enable_tso_follower_proxy-new-in-v530)を介して PDFollowerプロキシの有効化/無効化をサポートします。PD の TSO リクエスト負荷が高すぎる場合、PD フォロワープロキシを有効にすると、フォロワーのリクエストサイクル中に収集された TSO リクエストをリーダーノードに一括転送できます。このソリューションにより、クライアントとリーダー間の直接的なインタラクション数を効果的に削減し、リーダーへの負荷を軽減し、TiDB 全体のパフォーマンスを向上させることができます。 @@ -156,7 +156,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 > **Note:** > - > TSO 要求負荷が高くない場合は、この変数値を変更することはお勧めしません。 + > TSO リクエスト負荷が高くない場合は、この変数値を変更することはお勧めしません。 [ユーザードキュメント](/system-variables.md#tidb_tso_client_batch_max_wait_time-new-in-v530) [#3149](https://github.com/tikv/pd/issues/3149) @@ -385,7 +385,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - `resolved_ts` で一部のコルーチンがリークする問題を修正 [#10965](https://github.com/tikv/tikv/issues/10965) - 応答サイズが4 GiBを超えるとコプロセッサに発生するpanic問題を修正[#9012](https://github.com/tikv/tikv/issues/9012) - スナップショットファイルがガベージコレクションできない場合に、スナップショット ガベージコレクション (GC) で GC スナップショットファイルが失われる問題を修正しました[#10813](https://github.com/tikv/tikv/issues/10813) - - コプロセッサー要求の処理中にタイムアウトによって発生するpanic問題を修正[#10852](https://github.com/tikv/tikv/issues/10852) + - コプロセッサーリクエストの処理中にタイムアウトによって発生するpanic問題を修正[#10852](https://github.com/tikv/tikv/issues/10852) - 統計スレッドの監視データによって発生するメモリリークを修正しました [#11195](https://github.com/tikv/tikv/issues/11195) - 一部のプラットフォームから cgroup 情報を取得する際に発生するpanic問題を修正[#10980](https://github.com/tikv/tikv/pull/10980) - MVCC 削除バージョンが圧縮フィルタ GC によって削除されないため、スキャンパフォーマンスが低下する問題を修正しました。 [#11248](https://github.com/tikv/tikv/pull/11248) diff --git a/releases/release-5.3.3.md b/releases/release-5.3.3.md index 6d0e695cdff69..123b9b2839105 100644 --- a/releases/release-5.3.3.md +++ b/releases/release-5.3.3.md @@ -15,7 +15,7 @@ TiDB バージョン: 5.3.3 - PD リーダーが切り替えられた後、または PD が再起動された後にクラスター内で SQL 実行エラーが継続して発生する問題を修正しました。 - - 原因：この問題は、TiKVのバグが原因で発生します。このバグにより、ハートビート要求が失敗した後、TiKVはPDクライアントに再接続するまで、PDクライアントへのハートビート情報の送信を再試行しません。その結果、障害が発生したTiKVノードのリージョン情報が古くなり、TiDBは最新のリージョン情報を取得できず、SQL実行エラーが発生します。 + - 原因：この問題は、TiKVのバグが原因で発生します。このバグにより、ハートビートリクエストが失敗した後、TiKVはPDクライアントに再接続するまで、PDクライアントへのハートビート情報の送信を再試行しません。その結果、障害が発生したTiKVノードのリージョン情報が古くなり、TiDBは最新のリージョン情報を取得できず、SQL実行エラーが発生します。 - 影響を受けるバージョン: v5.3.2 および v5.4.2。この問題は v5.3.3 で修正されています。v5.3.2 をご利用の場合は、クラスターを v5.3.3 にアップグレードできます。 - 回避策: アップグレードに加えて、送信するリージョンハートビートがなくなるまで、リージョンハートビートを PD に送信できない TiKV ノードを再起動することもできます。 diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 346a707268694..908dc5680c2be 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -31,7 +31,7 @@ TiDB バージョン: 5.4.0 ### システム変数 {#system-variables} -
変数名変更の種類説明
tidb_enable_column_tracking新しく追加されたTiDBがPREDICATE COLUMNSを収集することを許可するかどうかを制御します。デフォルト値はOFF.
tidb_enable_paging新しく追加されたIndexLookUpオペレーターでコプロセッサ要求を送信する際にページング方式を使用するかどうかを制御します。デフォルト値はOFFです。
IndexLookupとLimitを使用する読み取りクエリで、 LimitをIndexScanにプッシュダウンできない場合、読み取りクエリのレイテンシーが高くなり、TiKVのunified read poolのCPU使用率が高くなる可能性があります。このような場合、 Limitオペレーターは少量のデータしか必要としないため、 tidb_enable_paging ONに設定すると、TiDBが処理するデータ量が少なくなり、クエリのレイテンシーとリソース消費が削減されます。
tidb_enable_top_sql新しく追加されたTop SQL機能を有効にするかどうかを制御します。デフォルト値はOFFです。
tidb_persist_analyze_options新しく追加されたANALYZE構成の永続化機能を有効にするかどうかを制御します。デフォルト値はONです。
tidb_read_staleness新しく追加された現在のセッションで読み取れる履歴データの範囲を制御します。デフォルト値は0です。
tidb_regard_null_as_point新しく追加されたオプティマイザが、NULL等価性を含むクエリ条件をインデックスアクセスのプレフィックス条件として使用できるかどうかを制御します。
tidb_stats_load_sync_wait新しく追加された同期的に統計情報を読み込む機能を有効にするかどうかを制御します。デフォルト値の0は、この機能が無効になっており、統計情報が非同期的に読み込まれることを意味します。この機能が有効になっている場合、この変数は、SQL 最適化がタイムアウトする前に同期的に統計情報を読み込むのを待機できる最大時間を制御します。
tidb_stats_load_pseudo_timeout新しく追加された同期的に統計情報を読み込む際にタイムアウトが発生した場合、SQLが失敗するか（ OFF ）、擬似統計情報を使用するようにフォールバックするか（ ON ）を制御します。デフォルト値はOFFです。
tidb_backoff_lock_fast変更デフォルト値が100から10に変更されました。
tidb_enable_index_merge変更デフォルト値がOFFからONに変更されます。
  • TiDBクラスタをv4.0.0より前のバージョンからv5.4.0以降にアップグレードする場合、この変数はデフォルトでOFFなります。
  • TiDBクラスタをv4.0.0以降からv5.4.0以降にアップグレードした場合、この変数はアップグレード前と同じままです。
  • バージョン5.4.0以降で新たに作成されたTiDBクラスタでは、この変数はデフォルトでONなっています。
tidb_store_limit変更バージョン5.4.0より前は、この変数はインスタンスレベルとグローバルレベルの両方で設定可能でした。バージョン5.4.0以降は、この変数はグローバル設定のみをサポートします。
+
変数名変更の種類説明
tidb_enable_column_tracking新しく追加されたTiDBがPREDICATE COLUMNSを収集することを許可するかどうかを制御します。デフォルト値はOFF.
tidb_enable_paging新しく追加されたIndexLookUpオペレーターでコプロセッサリクエストを送信する際にページング方式を使用するかどうかを制御します。デフォルト値はOFFです。
IndexLookupとLimitを使用する読み取りクエリで、 LimitをIndexScanにプッシュダウンできない場合、読み取りクエリのレイテンシーが高くなり、TiKVのunified read poolのCPU使用率が高くなる可能性があります。このような場合、 Limitオペレーターは少量のデータしか必要としないため、 tidb_enable_paging ONに設定すると、TiDBが処理するデータ量が少なくなり、クエリのレイテンシーとリソース消費が削減されます。
tidb_enable_top_sql新しく追加されたTop SQL機能を有効にするかどうかを制御します。デフォルト値はOFFです。
tidb_persist_analyze_options新しく追加されたANALYZE構成の永続化機能を有効にするかどうかを制御します。デフォルト値はONです。
tidb_read_staleness新しく追加された現在のセッションで読み取れる履歴データの範囲を制御します。デフォルト値は0です。
tidb_regard_null_as_point新しく追加されたオプティマイザが、NULL等価性を含むクエリ条件をインデックスアクセスのプレフィックス条件として使用できるかどうかを制御します。
tidb_stats_load_sync_wait新しく追加された同期的に統計情報を読み込む機能を有効にするかどうかを制御します。デフォルト値の0は、この機能が無効になっており、統計情報が非同期的に読み込まれることを意味します。この機能が有効になっている場合、この変数は、SQL 最適化がタイムアウトする前に同期的に統計情報を読み込むのを待機できる最大時間を制御します。
tidb_stats_load_pseudo_timeout新しく追加された同期的に統計情報を読み込む際にタイムアウトが発生した場合、SQLが失敗するか（ OFF ）、擬似統計情報を使用するようにフォールバックするか（ ON ）を制御します。デフォルト値はOFFです。
tidb_backoff_lock_fast変更デフォルト値が100から10に変更されました。
tidb_enable_index_merge変更デフォルト値がOFFからONに変更されます。
  • TiDBクラスタをv4.0.0より前のバージョンからv5.4.0以降にアップグレードする場合、この変数はデフォルトでOFFなります。
  • TiDBクラスタをv4.0.0以降からv5.4.0以降にアップグレードした場合、この変数はアップグレード前と同じままです。
  • バージョン5.4.0以降で新たに作成されたTiDBクラスタでは、この変数はデフォルトでONなっています。
tidb_store_limit変更バージョン5.4.0より前は、この変数はインスタンスレベルとグローバルレベルの両方で設定可能でした。バージョン5.4.0以降は、この変数はグローバル設定のみをサポートします。
### コンフィグレーションファイルパラメータ {#configuration-file-parameters} @@ -366,7 +366,7 @@ TiDB バージョン: 5.4.0 - TiKV - MVCC削除レコードがGCによってクリアされない問題を修正しました [#11217](https://github.com/tikv/tikv/issues/11217) - - 悲観的トランザクションモードでプリライト要求を再試行すると、まれにデータ不整合のリスクが発生する可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) + - 悲観的トランザクションモードでプリライトリクエストを再試行すると、まれにデータ不整合のリスクが発生する可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) - GCスキャンによってメモリオーバーフローが発生する問題を修正 [#11410](https://github.com/tikv/tikv/issues/11410) - RocksDBのフラッシュまたは圧縮時にディスク容量がいっぱいになったときにpanicが発生する問題を修正 [#11224](https://github.com/tikv/tikv/issues/11224) diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 38577d38f9f24..1c0312e0bbf96 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -53,7 +53,7 @@ TiDB バージョン: 5.4.3 - TiKV - PDリーダーの切り替え後またはPDの再起動後にクラスタ内でSQL実行エラーが継続する問題を修正[#12934](https://github.com/tikv/tikv/issues/12934) - - 原因：この問題は、TiKVのバグが原因で発生します。このバグにより、ハートビート要求が失敗した後、TiKVはPDクライアントに再接続するまで、PDクライアントへのハートビート情報の送信を再試行しません。その結果、障害が発生したTiKVノードのリージョン情報が古くなり、TiDBは最新のリージョン情報を取得できず、SQL実行エラーが発生します。 + - 原因：この問題は、TiKVのバグが原因で発生します。このバグにより、ハートビートリクエストが失敗した後、TiKVはPDクライアントに再接続するまで、PDクライアントへのハートビート情報の送信を再試行しません。その結果、障害が発生したTiKVノードのリージョン情報が古くなり、TiDBは最新のリージョン情報を取得できず、SQL実行エラーが発生します。 - 影響を受けるバージョン: v5.3.2 および v5.4.2。この問題は v5.3.3 および v5.4.3 で修正されています。v5.4.2 をご利用の場合は、クラスターを v5.4.3 にアップグレードできます。 - 回避策: アップグレードに加えて、送信するリージョンハートビートがなくなるまで、リージョンハートビートを PD に送信できない TiKV ノードを再起動することもできます。 - TiKV が Web ID プロバイダーからエラーを取得し、デフォルトのプロバイダーにフェイルバックしたときに、権限拒否エラーが発生する問題を修正しました[#13122](https://github.com/tikv/tikv/issues/13122) diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 359ed8e33d3c7..4ee42b5667d44 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -351,7 +351,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 多くのキー範囲を持つバッチに対するRaftstoreのサンプリング精度を向上[#12327](https://github.com/tikv/tikv/issues/12327) - `debug/pprof/profile`に正しい"Content-Type"を追加して、プロファイルをより簡単に識別できるようにします[#11521](https://github.com/tikv/tikv/issues/11521) - - Raftstore がハートビートを持っているときや読み取り要求を処理しているときにリーダーのリースの時間を無期限に更新し、レイテンシージッターを削減します[#11579](https://github.com/tikv/tikv/issues/11579) + - Raftstore がハートビートを持っているときや読み取りリクエストを処理しているときにリーダーのリースの時間を無期限に更新し、レイテンシージッターを削減します[#11579](https://github.com/tikv/tikv/issues/11579) - リーダーを切り替える際にコストが最も低いストアを選択すると、パフォーマンスの安定性が向上します[#10602](https://github.com/tikv/tikv/issues/10602) - Raftログを非同期に取得することで、 Raftstore をブロックすることで発生するパフォーマンスジッターを軽減します。 [#11320](https://github.com/tikv/tikv/issues/11320) - ベクトル計算の`QUARTER`関数をサポート [#5751](https://github.com/tikv/tikv/issues/5751) diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index 1746973b89217..75aa9e07919fe 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -73,7 +73,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - `LIMIT` と併用すると`INL_HASH_JOIN`がハングする可能性がある問題を修正しました [#35638](https://github.com/pingcap/tidb/issues/35638) @[guo-shaoge](https://github.com/guo-shaoge) - `UPDATE`文の実行時に TiDB がpanicする可能性がある問題を修正しました [#32311](https://github.com/pingcap/tidb/issues/32311) @[Yisaer](https://github.com/Yisaer) - - `SHOW COLUMNS`文を実行するときに TiDB がコプロセッサ要求を送信する可能性があるバグを修正しました。 [#36496](https://github.com/pingcap/tidb/issues/36496) @[tangenta](https://github.com/tangenta) + - `SHOW COLUMNS`文を実行するときに TiDB がコプロセッサリクエストを送信する可能性があるバグを修正しました。 [#36496](https://github.com/pingcap/tidb/issues/36496) @[tangenta](https://github.com/tangenta) - TiDBが`SHOW WARNINGS`文を実行するときに`invalid memory address or nil pointer dereference`エラーを返す可能性があるバグを修正しました [#31569](https://github.com/pingcap/tidb/issues/31569) @[zyguan](https://github.com/zyguan) - 静的パーティションプルーニングモードで、テーブルが空の場合に集計条件を含むSQL文が間違った結果を返す可能性があるバグを修正[#35295](https://github.com/pingcap/tidb/issues/35295) @[tiancaiamao](https://github.com/tiancaiamao) - Join Reorder 操作がその Outer Join 条件を誤ってプッシュダウンする問題を修正しました [#37238](https://github.com/pingcap/tidb/issues/37238) @[winoros](https://github.com/winoros) diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index 163b4a503883d..2c43abb3a49d4 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -64,7 +64,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - TiFlash - - I/O リミッターがバルク書き込み後のクエリ要求の I/O スループットを誤って抑制し、クエリのパフォーマンスが低下する問題を修正しました[#5801](https://github.com/pingcap/tiflash/issues/5801) @[JinheLin](https://github.com/JinheLin) + - I/O リミッターがバルク書き込み後のクエリリクエストの I/O スループットを誤って抑制し、クエリのパフォーマンスが低下する問題を修正しました[#5801](https://github.com/pingcap/tiflash/issues/5801) @[JinheLin](https://github.com/JinheLin) - クエリがキャンセルされたときにウィンドウ関数によってTiFlashがクラッシュする可能性がある問題を修正[#5814](https://github.com/pingcap/tiflash/issues/5814) @[SeaRise](https://github.com/SeaRise) - `NULL`値を含む列でプライマリインデックスを作成した後に発生するpanicを修正しました。 [#5859](https://github.com/pingcap/tiflash/issues/5859) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -85,7 +85,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - TiCDC - - CDCサーバーが完全に起動する前に HTTP 要求を受信すると、CDCサーバーがpanicする可能性がある問題を修正しました[#6838](https://github.com/pingcap/tiflow/issues/6838) @[asddongmen](https://github.com/asddongmen) + - CDCサーバーが完全に起動する前に HTTP リクエストを受信すると、CDCサーバーがpanicする可能性がある問題を修正しました[#6838](https://github.com/pingcap/tiflow/issues/6838) @[asddongmen](https://github.com/asddongmen) - アップグレード中のログ フラッディング問題を修正 [#7235](https://github.com/pingcap/tiflow/issues/7235) @[Rustin170506](https://github.com/Rustin170506) - changefeed の redo ログファイルが誤って削除される可能性がある問題を修正[#6413](https://github.com/pingcap/tiflow/issues/6413) @[Rustin170506](https://github.com/Rustin170506) - etcdトランザクションでコミットされる操作が多すぎるとTiCDCが利用できなくなる問題を修正[#7131](https://github.com/pingcap/tiflow/issues/7131) @[Rustin170506](https://github.com/Rustin170506) diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index ef05b615622a1..be49c96a76588 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -259,8 +259,8 @@ TiDBバージョン: 6.2.0-DMR | [tidb_generate_binary_plan](/system-variables.md#tidb_generate_binary_plan-new-in-v620) | 新しく追加された | この変数は、スローログとステートメントサマリーにバイナリエンコードされた実行計画を生成するかどうかを制御します。 | | [tidb_opt_skew_distinct_agg](/system-variables.md#tidb_opt_skew_distinct_agg-new-in-v620) | 新しく追加された | この変数は、オプティマイザが`DISTINCT`を含む集計関数を2レベルの集計関数に書き換えるかどうかを設定します。たとえば`SELECT b, COUNT(DISTINCT a) FROM t GROUP BY b`を`SELECT b, COUNT(a) FROM (SELECT b, a FROM t GROUP BY b, a) t GROUP BY b`に書き換えます。 | | [tidb_enable_noop_variables](/system-variables.md#tidb_enable_noop_variables-new-in-v620) | 新しく追加された | この変数は`noop`の結果に`SHOW [GLOBAL] VARIABLES` 変数を表示するかどうかを制御します。 | -| [tidb_min_paging_size](/system-variables.md#tidb_min_paging_size-new-in-v620) | 新しく追加された | この変数は、コプロセッサのページング要求処理中に処理される行の最大数を設定するために使用されます。 | -| [tidb_txn_commit_batch_size](/system-variables.md#tidb_txn_commit_batch_size-new-in-v620) | 新しく追加された | この変数は、TiDBがTiKVに送信するトランザクションコミット要求のバッチサイズを制御するために使用されます。 | +| [tidb_min_paging_size](/system-variables.md#tidb_min_paging_size-new-in-v620) | 新しく追加された | この変数は、コプロセッサのページングリクエスト処理中に処理される行の最大数を設定するために使用されます。 | +| [tidb_txn_commit_batch_size](/system-variables.md#tidb_txn_commit_batch_size-new-in-v620) | 新しく追加された | この変数は、TiDBがTiKVに送信するトランザクションコミットリクエストのバッチサイズを制御するために使用されます。 | | tidb_enable_change_multi_schema | 削除済み | この変数は、v6.2.0 以降では、デフォルトで 1つの`ALTER TABLE`文で複数の列またはインデックスを変更できるため、削除されます。 | | [tidb_enable_outer_join_reorder](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610) | 変更 | この変数は、TiDB の結合したテーブルの再配置アルゴリズムが Outer Join をサポートするかどうかを制御します。v6.1.0 では、デフォルト値は`ON`であり、これは Join Reorder の Outer Join のサポートがデフォルトで有効になっていることを意味します。v6.2.0 以降では、デフォルト値は`OFF`であり、これはサポートがデフォルトで無効になっていることを意味します。 | @@ -271,7 +271,7 @@ TiDBバージョン: 6.2.0-DMR | TiDB | フィードバック確率 | 削除済み | この設定はもはや有効ではなく、推奨されません。 | | TiDB | クエリフィードバック制限 | 削除済み | この設定はもはや有効ではなく、推奨されません。 | | TiKV | [server.simplify-metrics](/tikv-configuration-file.md#simplify-metrics-new-in-v620) | 新しく追加された | この設定では、返される監視メトリクスを簡略化するかどうかを指定します。 | -| TiKV | [quota.background-cpu-time](/tikv-configuration-file.md#background-cpu-time-new-in-v620) | 新しく追加された | この設定では、TiKVのバックグラウンド処理で読み取りおよび書き込み要求を処理するために使用されるCPUリソースのソフトリミットを指定します。 | +| TiKV | [quota.background-cpu-time](/tikv-configuration-file.md#background-cpu-time-new-in-v620) | 新しく追加された | この設定では、TiKVのバックグラウンド処理で読み取りおよび書き込みリクエストを処理するために使用されるCPUリソースのソフトリミットを指定します。 | | TiKV | [quota.background-write-bandwidth](/tikv-configuration-file.md#background-write-bandwidth-new-in-v620) | 新しく追加された | この設定では、バックグラウンド トランザクションがデータを書き込む際の帯域幅のソフト リミットを指定します (現在は有効ではありません)。 | | TiKV | [quota.background-read-bandwidth](/tikv-configuration-file.md#background-read-bandwidth-new-in-v620) | 新しく追加された | この設定では、バックグラウンドトランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミットを指定します（現在は有効ではありません）。 | | TiKV | [quota.enable-auto-tune](/tikv-configuration-file.md#enable-auto-tune-new-in-v620) | 新しく追加された | この設定では、クォータの自動調整を有効にするかどうかを指定します。この設定項目を有効にすると、TiKVはTiKVインスタンスの負荷に基づいて、バックグラウンドリクエストのクォータを動的に調整します。 | @@ -290,7 +290,7 @@ TiDBバージョン: 6.2.0-DMR | PD | replication-mode.dr-auto-sync.wait-async-timeout | 削除済み | この設定は有効にならず、削除されます。 | | PD | replication-mode.dr-auto-sync.wait-sync-timeout | 削除済み | この設定は有効にならず、削除されます。 | | TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 変更 | `format_version`のデフォルト値が`4`に変更されます。これは v6.2.0 以降のバージョンのデフォルト形式であり、書き込み増幅とバックグラウンドタスクのリソース消費を削減します。 | -| TiFlash | [profiles.default.dt_enable_read_thread](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定は、ストレージエンジンからの読み取り要求を処理するためにスレッドプールを使用するかどうかを制御します。デフォルト値は`false`です。 | +| TiFlash | [profiles.default.dt_enable_read_thread](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定は、ストレージエンジンからの読み取りリクエストを処理するためにスレッドプールを使用するかどうかを制御します。デフォルト値は`false`です。 | | TiFlash | [profiles.default.dt_page_gc_threshold](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定では、PageStorageデータファイル内の有効データの最小比率を指定します。 | | TiCDC | [--overwrite-checkpoint-ts](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task) | 新しく追加された | この設定は`cdc cli changefeed resume`サブコマンドに追加されます。 | | TiCDC | [--確認しない](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task) | 新しく追加された | この設定は`cdc cli changefeed resume`サブコマンドに追加されます。 |