diff --git a/alert-rules.md b/alert-rules.md index 255ff23d3c3aa..4e3ffef4bf97a 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 45452bb1f7172..f4f977606b574 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 5f70e224afcba..fd66f31fd7788 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} -高度な同時書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。 +同時実行性の高い書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。 - 膨大な量のデータ - 履歴データを短時間でデータベースにインポートする必要性 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index 6520b132f5e68..7101dad1f2ff1 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`システムテーブルには、クラスター化されたテーブルの主キーも含まれており、インデックスのパフォーマンスをより詳細に把握できます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 534b591be767c..bdee3b459edb2 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -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 1b1b2b5a5fe39..e1e1215a97b4b 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 0cfb28a870951..775608d396321 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,15 +124,15 @@ PITRの全プロセスは以下のとおりです。 - **バックアップデータの読み取り**：ログバックアップデータを読み取り、復元する必要のあるログバックアップデータを計算します。 - **リージョン情報の取得**: PD にアクセスして、すべてのリージョンのディストリビューションを取得します。 - - **TiKVにデータ復元を要求する**：ログ復元要求を作成し、対応するTiKVノードに送信します。ログ復元要求には、復元するログバックアップデータの情報が含まれています。 + - **TiKVにデータ復元をリクエストする**：ログ復元リクエストを作成し、対応するTiKVノードに送信します。ログ復元リクエストには、復元するログバックアップデータの情報が含まれています。 -4. TiKVはBRからの復元要求を受け入れ、ログ復元ワーカーを起動します。 +4. TiKVはBRからの復元リクエストを受け入れ、ログ復元ワーカーを起動します。 - ログ復元ワーカーは、復元する必要のあるログバックアップデータを取得します。 5. TiKVはログバックアップデータを復元します。 - - **KVのダウンロード**：ログ復元ワーカーは、ログ復元要求に従って、バックアップストレージから対応するバックアップデータをローカルディレクトリにダウンロードします。 + - **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 dfc48be5d7dfa..9c2088404e6d2 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 8ef7579cb7485..d47ab15d1b27e 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..c9b6cb72cfc62 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -13,7 +13,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ ただし、PDスケジューリングの最小単位はリージョンです。クラスター内のホットスポットの数がノード数より少ない場合、または一部のホットスポットの負荷が他のリージョンよりもはるかに大きい場合、PDはホットスポットをあるノードから別のノードに移動することしかできず、クラスター全体で負荷を分散させることはできません。 -このシナリオは、完全なテーブルスキャンや小さなテーブルのインデックス検索、一部のフィールドへの頻繁なアクセスなど、主に読み取り要求であるワークロードで特に一般的です。 +このシナリオは、完全なテーブルスキャンや小さなテーブルのインデックス検索、一部のフィールドへの頻繁なアクセスなど、主に読み取りリクエストであるワークロードで特に一般的です。 以前は、この問題の解決策として、1つ以上のホットスポットリージョンを分割するコマンドを手動で実行していましたが、この方法には 2つの問題がありました。 @@ -36,7 +36,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ リージョンが10秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 -- 読み取り要求の合計が`split.qps-threshold`超えます。 +- 読み取りリクエストの合計が`split.qps-threshold`超えます。 - トラフィックが`split.byte-threshold`超えています。 - 統合読み取りプール内の CPU 使用率が`split.region-cpu-overload-threshold-ratio`超えています。 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 9cacfca02814f..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..f3cf2a0e68670 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -23,9 +23,9 @@ 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 内の書き込みレイテンシーの内訳。 次のセクションでは、パフォーマンス概要ダッシュボードのメトリックについて説明します。 @@ -73,7 +73,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 - tso - リクエスト: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 -通常、 `tso - request` `tso - cmd`で割った値が、1秒あたりの TSO 要求バッチの平均サイズになります。 +通常、 `tso - request` `tso - cmd`で割った値が、1秒あたりの TSO リクエストバッチの平均サイズになります。 ### 接続数 {#connection-count} @@ -148,7 +148,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### 平均 TiDB KV リクエスト期間 {#avg-tidb-kv-request-duration} -`Get` 、 `Prewrite` 、 `Commit`を含むタイプに基づいて、すべての TiDB インスタンスでの KV 要求の実行に費やされた平均時間。 +`Get` 、 `Prewrite` 、 `Commit`を含むタイプに基づいて、すべての TiDB インスタンスでの KV リクエストの実行に費やされた平均時間。 ### 平均 TiKV GRPC 期間 {#avg-tikv-grpc-duration} diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index b6cce828e086e..3fc48b90c5cce 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..b31c9c0ae99f9 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 4e1a81e7b0402..405bac513e712 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 ca42f0a7d2ab4..594615fe9675b 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 9434da69f8388..952e27de68ed1 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 dc08033492149..7dbe6873ef110 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..acff39a8ba438 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..ecb58267e7b25 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秒あたりに消費する書き込みリクエストユニット（WRRU）の平均数。上記の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 18f83750afd88..2ab6320c09d7d 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 内のすべてのアクティブな領域の安全時刻と現在時刻との間の最大時間差 - 最小解決TSリージョン：resolved-tsが最小であるリージョンのID - 最小安全TSリージョン：安全TSが最小であるリージョンのID -- Leader処理時間：リーダー要求の処理に費やされた時間の分布。処理時間は、要求の送信からリーダーでの応答の受信までの時間です。 +- Leader処理時間：リーダーリクエストの処理に費やされた時間の分布。処理時間は、リクエストの送信からリーダーでの応答の受信までの時間です。 - リージョンリーダーにおけるresolved-tsの最大ギャップ：このTiKV内のすべてのアクティブなリージョンのresolved-tsと現在時刻との間の最大時間差（リージョンリーダーのみ）。 - Min Leader Resolved TS リージョン :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..fbc0c4b4bd8c7 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 cab26b4c8eb7f..f2bd01e96977d 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-methods.md b/performance-tuning-methods.md index 7586233fbd092..b6e44889620f1 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -50,13 +50,13 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 パフォーマンス概要ダッシュボードは、TiDB、PD、および TiKV のメトリックを調整し、それぞれを次のセクションで表示します。 -- データベース時間と SQL 実行時間の概要: 色分けされた SQL タイプ、SQL 実行フェーズ別のデータベース時間、およびさまざまな要求のデータベース時間により、データベースのワークロード特性とパフォーマンスのボトルネックを迅速に特定できます。 -- 主要なメトリックとリソース使用率: データベース QPS、接続情報、アプリケーションとデータベース間の要求コマンド タイプ、データベース内部 TSO および KV 要求 OPS、および TiDB/TiKV リソースの使用率が含まれます。 -- トップダウンのレイテンシーの内訳: クエリレイテンシーと接続アイドル時間の比較、クエリレイテンシーの内訳、SQL 実行における TSO 要求と KV 要求のレイテンシー、および TiKV 内部書き込みレイテンシーの内訳が含まれます。 +- データベース時間と SQL 実行時間の概要: 色分けされた SQL タイプ、SQL 実行フェーズ別のデータベース時間、およびさまざまなリクエストのデータベース時間により、データベースのワークロード特性とパフォーマンスのボトルネックを迅速に特定できます。 +- 主要なメトリックとリソース使用率: データベース QPS、接続情報、アプリケーションとデータベース間のリクエストコマンド タイプ、データベース内部 TSO および KV リクエスト OPS、および TiDB/TiKV リソースの使用率が含まれます。 +- トップダウンのレイテンシーの内訳: クエリレイテンシーと接続アイドル時間の比較、クエリレイテンシーの内訳、SQL 実行における TSO リクエストと KV リクエストのレイテンシー、および TiKV 内部書き込みレイテンシーの内訳が含まれます。 ### データベース時間とSQL実行時間の概要 {#database-time-and-sql-execution-time-overview} -データベース時間メトリックは、TiDB が 1秒あたりに SQL を処理するレイテンシーの合計であり、これは TiDB が 1秒あたりにアプリケーションの SQL 要求を同時に処理する合計時間でもあります (アクティブな接続の数に等しい)。 +データベース時間メトリックは、TiDB が 1秒あたりに SQL を処理するレイテンシーの合計であり、これは TiDB が 1秒あたりにアプリケーションの SQL リクエストを同時に処理する合計時間でもあります (アクティブな接続の数に等しい)。 パフォーマンス概要ダッシュボードには、以下の3つの積み上げ面グラフが表示されます。これらのグラフは、データベースのワークロードプロファイルを把握し、SQL実行中のステートメント、SQLフェーズ、TiKVまたはPDリクエストタイプの観点からボトルネックの原因を迅速に特定するのに役立ちます。 @@ -87,13 +87,13 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 - SQL タイプ別のデータベース時間: 最も時間のかかるステートメントは、 `commit` 、 `update` 、 `select` 、および`insert`文です。 - SQL フェーズ別のデータベース時間: 最も時間のかかるフェーズは緑色で表示される SQL 実行です。 -- SQL 実行時間の概要: SQL 実行で最も時間のかかる KV 要求は、緑色の`Prewrite`と`Commit`です。 +- SQL 実行時間の概要: SQL 実行で最も時間のかかる KV リクエストは、緑色の`Prewrite`と`Commit`です。 > **Note:** > > KVリクエストの合計時間が実行時間よりも長くなるのは正常です。これは、TiDBエグゼキューターが複数のTiKVに同時にKVリクエストを送信する可能性があるためです。その結果、KVリクエストの合計待機時間が実行時間よりも長くなります。前述のTPC-Cワークロードでは、トランザクションがコミットされる際に、TiDBは`Prewrite`つと`Commit`リクエストを複数のTiKVに同時に送信します。したがって、この例では、 `Prewrite` 、 `Commit` 、 `PessimisticLock`リクエストの合計時間は明らかに実行時間よりも長くなります。 > - > - `execute`実行時間は、KVリクエストの合計時間と`tso_wait`目の実行時間の合計よりも大幅に長くなる可能性があります。これは、SQL実行時間のほとんどがTiDBエグゼキュータ内で費やされていることを意味します。以下に、よくある2つの例を示します。 + > - `execute`実行時間は、KVリクエストの合計時間と`tso_wait`の実行時間の合計よりも大幅に長くなる可能性があります。これは、SQL実行時間のほとんどがTiDBエグゼキュータ内で費やされていることを意味します。以下に、よくある2つの例を示します。 > > ``` > - Example 1: After TiDB executor reads a large amount of data from TiKV, it needs to do complex join and aggregation inside TiDB, which consumes a lot of time. @@ -114,7 +114,7 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 - SQL タイプ別のデータベース時間: 主に`SELECT`文です。 - SQLフェーズ別データベース時間：時間のかかる主なフェーズは、オレンジ色のフェーズ`compile`と緑色のフェーズ`execute`です。フェーズ`compile`のレイテンシが最も高く、TiDBが実行計画の生成に時間がかかりすぎていることを示しています。その後のパフォーマンスデータに基づいて根本原因をさらに特定する必要があります。 -- SQL 実行時間の概要: 青色の KV BatchGet 要求は、SQL 実行中に最も多くの時間を消費します。 +- SQL 実行時間の概要: 青色の KV BatchGet リクエストは、SQL 実行中に最も多くの時間を消費します。 > **Note:** > @@ -194,11 +194,11 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 - CPS By Type パネルでは、1秒あたり`StmtPrepare`コマンドの数が 1秒あたり`StmtClose`コマンドの数よりはるかに多く、プリペアドステートメントのアプリケーションでオブジェクト リークが発生していることを示しています。 - Queries Using Plan Cache OPS パネルでは、 `avg-miss`がタイプ別 CPS パネルの`StmtExecute`とほぼ等しく、ほとんどすべての SQL 実行で実行計画 キャッシュが失われていることを示しています。 -#### KV/TSO 要求 OPS とソース別の KV 要求時間 {#kv-tso-request-ops-and-kv-request-time-by-source} +#### KV/TSO リクエスト OPS とソース別の KV リクエスト時間 {#kv-tso-request-ops-and-kv-request-time-by-source} - KV/TSOリクエストOPSパネルでは、1秒あたりのKVおよびTSOリクエストの統計情報を確認できます。統計情報のうち、 `kv request total` TiDBからTiKVへのすべてのリクエストの合計を表します。TiDBからPDおよびTiKVへのリクエストの種類を観察することで、クラスター内のワークロードプロファイルを把握できます。 - KV リクエスト時間 (ソース別) パネルでは、各 KV リクエストタイプとすべてのリクエストソースの時間比率を表示できます。 - - kv 要求合計時間: 1秒あたりの KV およびTiFlash要求の処理時間の合計。 + - kv リクエスト合計時間: 1秒あたりの KV およびTiFlashリクエストの処理時間の合計。 - 各 KV リクエストと対応するリクエストソースは積み上げ棒グラフを形成し、 `external`通常のビジネスリクエストを識別し、 `internal`内部アクティビティリクエスト (DDL やauto analyzeリクエストなど) を識別します。 **例1: 忙しい作業負荷** @@ -208,7 +208,7 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 この TPC-C ワークロードでは、 - 1秒あたりのKVリクエストの総数は79,700です。リクエスト数の多い順に、リクエストタイプ`BatchGet` `Prewrite` `Commit` `PessimisticLock` -- KV 処理時間のほとんどは`Commit-external_Commit`と`Prewrite-external_Commit`に費やされており、最も時間のかかる KV 要求は外部コミット ステートメントからの`Commit`と`Prewrite`あることがわかります。 +- KV 処理時間のほとんどは`Commit-external_Commit`と`Prewrite-external_Commit`に費やされており、最も時間のかかる KV リクエストは外部コミット ステートメントからの`Commit`と`Prewrite`あることがわかります。 **例2: ワークロードを分析する** @@ -217,7 +217,7 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 このワークロードでは、クラスター内で実行されているステートメントは`ANALYZE`だけです。 - 1 秒あたりの KV リクエストの合計数は 35.5 で、1秒あたりの Cop リクエストの数は 9.3 です。 -- KV 処理時間のほとんどは`Cop-internal_stats`に費やされており、最も時間のかかる KV 要求は内部`ANALYZE`操作のうちの`Cop`であることを示しています。 +- KV 処理時間のほとんどは`Cop-internal_stats`に費やされており、最も時間のかかる KV リクエストは内部`ANALYZE`操作のうちの`Cop`であることを示しています。 #### CPUとメモリの使用量 {#cpu-and-memory-usage} @@ -397,15 +397,15 @@ avg Query Duration = avg Get Token + avg Parse Duration + avg Compile Duration + #### KVおよびTSOリクエスト期間 {#kv-and-tso-request-duration} -TiDB はフェーズ`execute`で PD および TiKV と連携します。次の図に示すように、SQL 要求を処理する際、TiDB はフェーズ`parse`および`compile`入る前に TSO を要求します。PD クライアントは呼び出し元をブロックせず、 `TSFuture`を返し、バックグラウンドで非同期的に TSO 要求を送受信します。PD クライアントは TSO 要求の処理を完了すると、 `TSFuture`を返します。 `TSFuture`の所有者は、最後の TSO を取得するために Wait メソッドを呼び出す必要があります。TiDB はフェーズ`parse`および`compile`を完了するとフェーズ`execute`に入り、このフェーズでは次の2つの状況が発生する可能性があります。 +TiDB はフェーズ`execute`で PD および TiKV と連携します。次の図に示すように、SQL リクエストを処理する際、TiDB はフェーズ`parse`および`compile`入る前に TSO をリクエストします。PD クライアントは呼び出し元をブロックせず、 `TSFuture`を返し、バックグラウンドで非同期的に TSO リクエストを送受信します。PD クライアントは TSO リクエストの処理を完了すると、 `TSFuture`を返します。 `TSFuture`の所有者は、最後の TSO を取得するために Wait メソッドを呼び出す必要があります。TiDB はフェーズ`parse`および`compile`を完了するとフェーズ`execute`に入り、このフェーズでは次の2つの状況が発生する可能性があります。 -- TSO要求が完了した場合、Waitメソッドは利用可能なTSOまたはエラーを直ちに返します。 -- TSO 要求がまだ完了していない場合、TSO が利用可能になるかエラーが表示されるまで (gRPC 要求は送信されたが結果が返されず、ネットワークレイテンシーが高くなる)、Wait メソッドはブロックされます。 +- TSOリクエストが完了した場合、Waitメソッドは利用可能なTSOまたはエラーを直ちに返します。 +- TSO リクエストがまだ完了していない場合、TSO が利用可能になるかエラーが表示されるまで (gRPC リクエストは送信されたが結果が返されず、ネットワークレイテンシーが高くなる)、Wait メソッドはブロックされます。 -TSO待機時間は`TSO WAIT`と記録され、TSO要求のネットワーク時間は`TSO RPC`と記録されます。TSO待機が完了すると、TiDBエグゼキューターは通常、TiKVに読み取りまたは書き込み要求を送信します。 +TSO待機時間は`TSO WAIT`と記録され、TSOリクエストのネットワーク時間は`TSO RPC`と記録されます。TSO待機が完了すると、TiDBエグゼキューターは通常、TiKVに読み取りまたは書き込みリクエストを送信します。 -- 一般的な KV 読み取り要求: `Get` `BatchGet`および`Cop` -- 一般的な KV 書き込み要求: 2フェーズコミットの`PessimisticLock` `Prewrite`および`Commit` +- 一般的な KV 読み取りリクエスト: `Get` `BatchGet`および`Cop` +- 一般的な KV 書き込みリクエスト: 2フェーズコミットの`PessimisticLock` `Prewrite`および`Commit` ![Execute](/media/performance/execute_phase.png) @@ -413,7 +413,7 @@ TSO待機時間は`TSO WAIT`と記録され、TSO要求のネットワーク時 - 平均 TiDB KV リクエスト期間: TiDB によって測定された KV リクエストの平均レイテンシー - 平均 TiKV GRPC 期間: TiKV での gPRC メッセージの処理にかかる平均レイテンシー -- PD TSO 待機/RPC 期間: TiDB エグゼキュータの TSO 待機時間と TSO 要求 (RPC) のネットワークレイテンシー +- PD TSO 待機/RPC 期間: TiDB エグゼキュータの TSO 待機時間と TSO リクエスト (RPC) のネットワークレイテンシー `Avg TiDB KV Request Duration`と`Avg TiKV GRPC Duration`の関係は以下のとおりです。 @@ -446,15 +446,15 @@ Avg TiDB KV Request Duration = Avg TiKV GRPC Duration + Network latency between #### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} -TiKV は次の手順で書き込み要求を処理します。 +TiKV は次の手順で書き込みリクエストを処理します。 -- `scheduler worker`書き込み要求を処理し、トランザクションの一貫性チェックを実行し、書き込み要求を`raftstore`モジュールに送信するキーと値のペアに変換します。 +- `scheduler worker`書き込みリクエストを処理し、トランザクションの一貫性チェックを実行し、書き込みリクエストを`raftstore`モジュールに送信するキーと値のペアに変換します。 - TiKV コンセンサス モジュール`raftstore` 、 Raftコンセンサス アルゴリズムを適用して、ストレージレイヤー(複数の TiKV で構成) をフォールト トレラントにします。 Raftstore は`Store`スレッドと`Apply`スレッドで構成されています。 - `Store`スレッドはRaftメッセージと新しい`proposals`を処理します。新しい`proposals`を受信すると、リーダーノードの`Store`スレッドはローカルRaft DBに書き込み、メッセージを複数のフォロワーノードにコピーします。ほとんどの場合、この`proposals`正常に永続化されると、 `proposals`が正常にコミットされます。 - - `Apply`スレッドはコミットされた`proposals`データをKV DBに書き込みます。データがKV DBに正常に書き込まれると、 `Apply`スレッドは書き込み要求が完了したことを外部に通知します。 + - `Apply`スレッドはコミットされた`proposals`データをKV DBに書き込みます。データがKV DBに正常に書き込まれると、 `Apply`スレッドは書き込みリクエストが完了したことを外部に通知します。 ![TiKV Write](/media/performance/store_apply.png) @@ -489,7 +489,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ **例2: 保存期間がボトルネック** -上記の式を適用します：10.1 ms ~= 9.81 ms + 0.304 ms。この結果は、書き込み要求のレイテンシーのボトルネックが`Store Duration`にあることを示しています。 +上記の式を適用します：10.1 ms ~= 9.81 ms + 0.304 ms。この結果は、書き込みリクエストのレイテンシーのボトルネックが`Store Duration`にあることを示しています。 ![Store](/media/performance/cloud_store_apply.png) 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/performance-tuning-practices.md b/performance-tuning-practices.md index 53daab9725a0b..c883e1546baff 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -304,9 +304,9 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 - SQLフェーズ別データベース時間では、 `execute`最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 -- 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 +- 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOをリクエストする必要があるためです。 -TiDB v6.0 は`rc read`を提供します。これは`tso cmd`を削減することで`read committed`分離レベルを最適化します。この機能はグローバル変数`set global tidb_rc_read_check_ts=on;`によって制御されます。この変数を有効にすると、TiDB のデフォルトの動作は`repeatable-read`分離レベルと同じように動作し、PD から取得する必要があるのは`start-ts`と`commit-ts`です。トランザクション内のステートメントは、最初に`start-ts`を使用して TiKV からデータを読み取ります。TiKV から読み取られたデータが`start-ts`より前の場合、データは直接返されます。TiKV から読み取られたデータが`start-ts`より後の場合、データは破棄されます。TiDB は PD から TSO を要求し、読み取りを再試行します。後続のステートメントの`for update ts`では、最新の PD TSO が使用されます。 +TiDB v6.0 は`rc read`を提供します。これは`tso cmd`を削減することで`read committed`分離レベルを最適化します。この機能はグローバル変数`set global tidb_rc_read_check_ts=on;`によって制御されます。この変数を有効にすると、TiDB のデフォルトの動作は`repeatable-read`分離レベルと同じように動作し、PD から取得する必要があるのは`start-ts`と`commit-ts`です。トランザクション内のステートメントは、最初に`start-ts`を使用して TiKV からデータを読み取ります。TiKV から読み取られたデータが`start-ts`より前の場合、データは直接返されます。TiKV から読み取られたデータが`start-ts`より後の場合、データは破棄されます。TiDB は PD から TSO をリクエストし、読み取りを再試行します。後続のステートメントの`for update ts`では、最新の PD TSO が使用されます。 ## シナリオ6: `tidb_rc_read_check_ts`変数を有効にしてTSOリクエストを削減する {#scenario-6-enable-the-tidb-rc-read-check-ts-variable-to-reduce-tso-requests} 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 635de56f5e239..5df412270fe39 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..b7b000bae2ae6 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 8d293818fcc6a..c22cfbcd63461 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 3a5c35573af47..1ae35e6eb7e11 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 b52e6299c5716..2f1e470e626ad 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 930481264e442..480e348ce279b 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 4d7e8d52fb838..1494792d39407 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 9ee9e2d466d9d..44359cbb46c27 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 97bd48db22eee..b5be6befbf67f 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 1f96c2cefe040..a8bf207fb29cb 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`サブコマンドに追加されます。 | diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 26c1a5ce67e8a..d877d6c049fa4 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -213,7 +213,7 @@ TiDBバージョン: 6.3.0-DMR | --------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 新しいオプション`tidb_sm3_password`を追加します。この変数を`tidb_sm3_password`に設定すると、暗号化アルゴリズムとして SM3 が使用されます。 | | [`sql_require_primary_key`](/system-variables.md#sql_require_primary_key-new-in-v630) | 新しく追加された | テーブルに主キーが必要であるという要件を強制するかどうかを制御します。この変数を有効にすると、主キーのないテーブルを作成または変更しようとするとエラーが発生します。 | -| [`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630) | 新しく追加された | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じリージョンのレプリカに送信することを優先するしきい値を制御します。 | +| [`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630) | 新しく追加された | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取りリクエストを TiDBサーバーと同じリージョンのレプリカに送信することを優先するしきい値を制御します。 | | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 新しく追加された | TiDB が悲観的トランザクションで[固有の制約](/constraints.md#pessimistic-transactions)いつチェックするかを制御します。 | | [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) | 新しく追加された | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)が有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理中にローカルストレージを使用する際の制限を設定します。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 新しく追加された | インデックス作成時のバックフィル速度を向上させるために、 `ADD INDEX`および`CREATE INDEX` DDL 操作の高速化を有効にするかどうかを制御します。 | @@ -225,11 +225,11 @@ TiDBバージョン: 6.3.0-DMR | [`tidb_enable_null_aware_anti_join`](/system-variables.md#tidb_enable_null_aware_anti_join-new-in-v630) | 新しく追加された | 特殊な集合演算子`NOT IN`および`!= ALL`を制御します。 | | [`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530) | 変更 | 統計情報が古くなっている場合に、オプティマイザがテーブルの統計情報を使用する動作を制御します。デフォルト値は`ON`から`OFF`に変更されます。これは、テーブルの統計情報が古くなっている場合でも、オプティマイザが引き続きテーブルの統計情報を使用することを意味します。 | | [`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action) | 変更 | データを読み取るオペレーターの動的メモリ制御機能を有効にするかどうかを制御します。この変数が`ON`に設定されている場合、メモリ使用量は[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)の制御下にない可能性があります。そのため、デフォルト値は`ON`から`OFF`に変更されます。 | -| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 新しく追加された | SQL書き込みステートメント内の読み取り要求をTiFlashにプッシュダウンするかどうかを制御します。この変数で制御される機能は、TiDB v6.3.0では完全には動作しません。デフォルト値は変更しないでください。 | +| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 新しく追加された | SQL書き込みステートメント内の読み取りリクエストをTiFlashにプッシュダウンするかどうかを制御します。この変数で制御される機能は、TiDB v6.3.0では完全には動作しません。デフォルト値は変更しないでください。 | | [`tidb_enable_unsafe_substitute`](/system-variables.md#tidb_enable_unsafe_substitute-new-in-v630) | 新しく追加された | 式を生成列に安全でない方法で置き換えるかどうかを制御します。 | | `tidb_general_plan_cache_size` | 新しく追加された | 一般プランキャッシュでキャッシュできる実行計画の最大数を制御します。この変数で制御される機能は、TiDB v6.3.0 では完全には動作しません。デフォルト値を変更しないでください。 | | [`tidb_last_plan_replayer_token`](/system-variables.md#tidb_enable_unsafe_substitute-new-in-v630) | 新しく追加された | 読み取り専用であり、現在のセッションでの最後の`PLAN REPLAYER DUMP`実行の結果を取得するために使用されます。 | -| [tidb_max_paging_size](/system-variables.md#tidb_max_paging_size-new-in-v630) | 新しく追加された | この変数は、コプロセッサのページング要求処理中に最小行数を設定するために使用されます。 | +| [tidb_max_paging_size](/system-variables.md#tidb_max_paging_size-new-in-v630) | 新しく追加された | この変数は、コプロセッサのページングリクエスト処理中に最小行数を設定するために使用されます。 | | [`tidb_opt_force_inline_cte`](/system-variables.md#tidb_opt_force_inline_cte-new-in-v630) | 新しく追加された | セッション全体の共通テーブル式 (CTE) をインライン化するかどうかを制御します。デフォルト値は`OFF`で、これはデフォルトでは CTE のインライン化が強制されないことを意味します。 | | [`tidb_opt_three_stage_distinct_agg`](/system-variables.md#tidb_opt_three_stage_distinct_agg-new-in-v630) | 新しく追加された | `COUNT(DISTINCT)`集計を MPP モードで 3 段階集計に書き換えるかどうかを指定します。デフォルト値は`ON`です。 | | [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 変更 | 動的剪定を有効にするかどうかを指定します。v6.3.0 以降、デフォルト値は`dynamic`に変更されます。 | @@ -249,7 +249,7 @@ TiDBバージョン: 6.3.0-DMR | TiKV | [`log-backup.enable`](/tikv-configuration-file.md#enable-new-in-v620) | 変更 | バージョン6.3.0以降、デフォルト値が`false`から`true`に変更されました。 | | TiKV | [`log-backup.max-flush-interval`](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 変更 | バージョン6.3.0以降、デフォルト値が`5min`から`3min`に変更されました。 | | PD | [診断を有効にする](/pd-configuration-file.md#enable-diagnostic-new-in-v630) | 新しく追加された | 診断機能を有効にするかどうかを制御します。デフォルト値は`false`です。 | -| TiFlash | [`dt_enable_read_thread`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 非推奨 | バージョン6.3.0以降、この設定項目は非推奨となりました。デフォルトでは、スレッドプールがストレージエンジンからの読み取り要求を処理するために使用され、無効にすることはできません。 | +| TiFlash | [`dt_enable_read_thread`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 非推奨 | バージョン6.3.0以降、この設定項目は非推奨となりました。デフォルトでは、スレッドプールがストレージエンジンからの読み取りリクエストを処理するために使用され、無効にすることはできません。 | | DM | [`safe-mode-duration`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | 自動セーフモードの継続時間を指定します。 | | TiCDC | [`enable-sync-point`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | Syncpoint機能を有効にするかどうかを指定します。 | | TiCDC | [`sync-point-interval`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | Syncpointがアップストリームとダウンストリームのスナップショットを同期させる間隔を指定します。 | diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 1aed2954a9705..269b85ab161cf 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -95,7 +95,7 @@ TiDBバージョン: 6.4.0-DMR - TiDBチャンク再利用メカニズムの強化 [#38606](https://github.com/pingcap/tidb/issues/38606) @[keeplearning20221](https://github.com/keeplearning20221) - 以前のバージョンでは、TiDB は`writechunk`関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁に要求する必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数[`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。 + 以前のバージョンでは、TiDB は`writechunk`関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁にリクエストする必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数[`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。 詳細については、 [ユーザー向けドキュメント](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を参照してください。 @@ -139,7 +139,7 @@ TiDBバージョン: 6.4.0-DMR - バッチ書き込みリクエストが軽量トランザクション書き込みの応答時間に与える影響を軽減する [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) - 一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライントランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッドワークロード シナリオでの読み取り要求のスケジューリングを最適化するため、 [`readpool.unified.auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)設定項目を有効にすると、TiKV がすべての読み取り要求に対して UnifyReadPool スレッドプールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込み要求も動的に識別して優先順位を付け、1回のポーリングで Apply スレッドが 1つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響を軽減できます。 + 一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライントランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッドワークロード シナリオでの読み取りリクエストのスケジューリングを最適化するため、 [`readpool.unified.auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)設定項目を有効にすると、TiKV がすべての読み取りリクエストに対して UnifyReadPool スレッドプールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込みリクエストも動的に識別して優先順位を付け、1回のポーリングで Apply スレッドが 1つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込みリクエストがトランザクション書き込みの応答時間に与える影響を軽減できます。 ### 使いやすさ {#ease-of-use} @@ -282,7 +282,7 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 変更 | グローバルスコープを削除し、 [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)設定項目を使用してデフォルト値を変更できるようにします。この変数は、TiDB が悲観的トランザクション内の一意制約をチェックするタイミングを制御します。 | | [`tidb_ddl_flashback_concurrency`](/system-variables.md#tidb_ddl_flashback_concurrency-new-in-v630) | 変更 | バージョン6.4.0以降で有効になり、 [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)の同時実行を制御します。デフォルト値は`64`です。 | | [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50) | 変更 | デフォルト値を`INT_ONLY`から`ON`に変更します。これは、主キーがデフォルトでクラスター化インデックスとして作成されることを意味します。 | -| [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-new-in-v540) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、コプロセッサ要求を送信するためのページング方式がデフォルトで使用されることを意味します。 | +| [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-new-in-v540) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、コプロセッサリクエストを送信するためのページング方式がデフォルトで使用されることを意味します。 | | [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) | 変更 | SESSION スコープを追加します。この変数は[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を有効にするかどうかを制御します。 | | [`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio) | 変更 | デフォルト値を`0.8`から`0.7`に変更します。この変数は、tidb-server のメモリアラームをトリガーするメモリ使用率を制御します。 | | [`tidb_opt_agg_push_down`](/system-variables.md#tidb_opt_agg_push_down) | 変更 | グローバルスコープを追加します。この変数は、オプティマイザが集計関数をJoin、Projection、およびUnionAllの前にプッシュダウンする最適化操作を実行するかどうかを制御します。 | @@ -293,7 +293,7 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_auto_analyze_partition_batch_size`](/system-variables.md#tidb_auto_analyze_partition_batch_size-new-in-v640) | 新しく追加された | パーティションテーブルを分析するときに TiDB が一度に[自動的に分析します](/statistics.md#automatic-update)できるパーティションの数を指定します (つまり、パーティションテーブルに関する統計を自動的に収集します)。デフォルト値は`1`です。 | | [`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) | 新しく追加された | TiDB が[`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640)で指定されたタイムスタンプを持つデータを読み取るかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_enable_gogc_tuner`](/system-variables.md#tidb_enable_gogc_tuner-new-in-v640) | 新しく追加された | GOGC Tuner を有効にするかどうかを制御します。デフォルト値は`ON`です。 | -| [`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640) | 新しく追加された | TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。デフォルト値は`ON`で、これは TiDB がキャッシュされたチャンク オブジェクトの使用を優先し、要求されたオブジェクトがキャッシュにない場合にのみシステムに要求することを意味します。値が`OFF`の場合、TiDB はシステムから直接チャンク オブジェクトを要求します。 | +| [`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640) | 新しく追加された | TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。デフォルト値は`ON`で、これは TiDB がキャッシュされたチャンク オブジェクトの使用を優先し、リクエストされたオブジェクトがキャッシュにない場合にのみシステムにリクエストすることを意味します。値が`OFF`の場合、TiDB はシステムから直接チャンク オブジェクトをリクエストします。 | | [`tidb_enable_prepared_plan_cache_memory_monitor`](/system-variables.md#tidb_enable_prepared_plan_cache_memory_monitor-new-in-v640) | 新しく追加された | プリペアドプランキャッシュにキャッシュされた実行計画によって消費されたメモリをカウントするかどうかを制御します。デフォルト値は`ON`です。 | | [`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640) | 新しく追加された | デフォルト値は`0`です。tidb_enable_external_ts_read [`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) `ON`に設定されている場合、TiDB はこの変数で指定されたタイムスタンプを持つデータを読み取ります。 | | [`tidb_gogc_tuner_threshold`](/system-variables.md#tidb_gogc_tuner_threshold-new-in-v640) | 新しく追加された | GOGC のチューニングにおける最大メモリしきい値を指定します。メモリがこのしきい値を超えると、GOGC Tuner は動作を停止します。デフォルト値は`0.6`です。 | @@ -315,7 +315,7 @@ TiDBバージョン: 6.4.0-DMR | TiDB | [`tidb-max-reuse-column`](/tidb-configuration-file.md#tidb-max-reuse-column-new-in-v640) | 新しく追加された | チャンク割り当てのキャッシュされた列オブジェクトの最大数を制御します。デフォルト値は`256`です。 | | TiKV | [`cdc.raw-min-ts-outlier-threshold`](https://docs-archive.pingcap.com/tidb/v6.2/tikv-configuration-file#raw-min-ts-outlier-threshold-new-in-v620) | 非推奨 | この設定項目は無効になりました。 | | TiKV | [`causal-ts.alloc-ahead-buffer`](/tikv-configuration-file.md#alloc-ahead-buffer-new-in-v640) | 新しく追加された | 事前割り当て済みのTSOキャッシュサイズ（期間）。デフォルト値は`3s`です。 | -| TiKV | [`causal-ts.renew-batch-max-size`](/tikv-configuration-file.md#renew-batch-max-size-new-in-v640) | 新しく追加された | タイムスタンプ要求におけるTSOの最大数を制御します。デフォルト値は`8192`です。 | +| TiKV | [`causal-ts.renew-batch-max-size`](/tikv-configuration-file.md#renew-batch-max-size-new-in-v640) | 新しく追加された | タイムスタンプリクエストにおけるTSOの最大数を制御します。デフォルト値は`8192`です。 | | TiKV | [`raftstore.apply-yield-write-size`](/tikv-configuration-file.md#apply-yield-write-size-new-in-v640) | 新しく追加された | Applyスレッドが1回のポーリングで1つのFSM（有限状態機械）に対して書き込める最大バイト数を制御します。デフォルト値は`32KiB`です。これはソフトリミットです。 | | PD | [`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval) | 新しく追加された | バージョン6.4.0以降で有効になり、PDがTSOの物理時刻を更新する間隔を制御します。デフォルト値は`50ms`です。 | | TiFlash | [`data-encryption-method`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 変更 | 新しい値オプション`sm4-ctr`が導入されました。この設定項目が`sm4-ctr`に設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 | diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 03116d494de85..47d69aabc8077 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -315,7 +315,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | 6.5.0以降で有効になります。`INSERT` 、 `DELETE` 、 `UPDATE`を含むSQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 `ADD INDEX`と`CREATE INDEX`の加速はデフォルトで有効になります。 | | [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) | 変更 | TiDB v6.5.0より前のバージョンでは、この変数はクエリのメモリクォータのしきい値を設定するために使用されます。TiDB v6.5.0以降のバージョンでは、DML文のメモリをより正確に制御するために、この変数はセッションのメモリクォータのしきい値を設定するために使用されます。 | -| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 | +| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取りリクエストの推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 | | [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640) | 変更 | デフォルト値を`0`から`80%`に変更します。TiDB グローバルメモリ制御が GA になったため、このデフォルト値の変更により、メモリ制御がデフォルトで有効になり、TiDB インスタンスのメモリ制限がデフォルトで合計メモリの 80% に設定されます。 | | [`default_password_lifetime`](/system-variables.md#default_password_lifetime-new-in-v650) | 新しく追加された | パスワードの自動有効期限に関するグローバルポリシーを設定し、ユーザーに定期的なパスワード変更を義務付けます。デフォルト値`0` 、パスワードの有効期限が切れないことを示します。 | | [`disconnect_on_expired_password`](/system-variables.md#disconnect_on_expired_password-new-in-v650) | 新しく追加された | パスワードの有効期限が切れたときにTiDBがクライアント接続を切断するかどうかを示します。この変数は読み取り専用です。 | @@ -384,7 +384,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - ディスク容量の枯渇を避けるため、十分なスペースがない場合はRaft Engineへの書き込みを停止します[#13642](https://github.com/tikv/tikv/issues/13642) @[jiayang-zheng](https://github.com/jiayang-zheng) - `json_valid`関数のTiKVへのプッシュダウンをサポート [#13571](https://github.com/tikv/tikv/issues/13571) @[lizhenhuan](https://github.com/lizhenhuan) - - 1回のバックアップ要求で複数の範囲のデータのバックアップをサポート[#13701](https://github.com/tikv/tikv/issues/13701) @[Leavrth](https://github.com/Leavrth) + - 1回のバックアップリクエストで複数の範囲のデータのバックアップをサポート[#13701](https://github.com/tikv/tikv/issues/13701) @[Leavrth](https://github.com/Leavrth) - rusotoライブラリを更新してAWSのアジア太平洋地域（ap-southeast-3）へのデータバックアップをサポート [#13751](https://github.com/tikv/tikv/issues/13751) @[3pointer](https://github.com/3pointer) - 悲観的トランザクション競合を減らす[#13298](https://github.com/tikv/tikv/issues/13298) @[MyonKeminta](https://github.com/MyonKeminta) - 外部ストレージオブジェクトをキャッシュすることでリカバリパフォーマンスを向上 [#13798](https://github.com/tikv/tikv/issues/13798) @[YuJuncen](https://github.com/YuJuncen) @@ -393,7 +393,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - クロスビームチャネルに更新することで、送信側での回転の問題を回避します。 [#13815](https://github.com/tikv/tikv/issues/13815) @[sticnarf](https://github.com/sticnarf) - TiKV でのバッチココプロセッサータスク処理をサポート [#13849](https://github.com/tikv/tikv/issues/13849) @[cfzjywxk](https://github.com/cfzjywxk) - TiKVにリージョンを起動するように通知することで、障害回復の待ち時間を短縮します。 [#13648](https://github.com/tikv/tikv/issues/13648) @[LykxSassinator](https://github.com/LykxSassinator) - - コード最適化によりメモリ使用量の要求サイズを削減 [#13827](https://github.com/tikv/tikv/issues/13827) @[BusyJay](https://github.com/BusyJay) + - コード最適化によりメモリ使用量のリクエストサイズを削減 [#13827](https://github.com/tikv/tikv/issues/13827) @[BusyJay](https://github.com/BusyJay) - コードの拡張性を向上させるためにRaft拡張機能を導入する[#13827](https://github.com/tikv/tikv/issues/13827) @[BusyJay](https://github.com/BusyJay) - tikv-ctl を使用して、特定のキー範囲に含まれるリージョンを照会することをサポートします。 [#13760](https://github.com/tikv/tikv/issues/13760) @[HuSharp](https://github.com/HuSharp) - 更新されないが継続的にロックされている行の読み取りと書き込みのパフォーマンスを向上[#13694](https://github.com/tikv/tikv/issues/13694) @[sticnarf](https://github.com/sticnarf) diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 186a8a4614658..0d8454b382198 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -76,7 +76,7 @@ TiDB バージョン: 6.5.10 - `LEADING`ヒントがブロックエイリアスのクエリをサポートしない問題を修正しました [#44645](https://github.com/pingcap/tidb/issues/44645) @[qw4990](https://github.com/qw4990) - 相関サブクエリにおける TopN オペレーターの誤った結果を修正 [#52777](https://github.com/pingcap/tidb/issues/52777) @[yibin87](https://github.com/yibin87) - 列の不安定な一意のIDにより、 `UPDATE`文がエラーを返す可能性がある問題を修正しました。 [#53236](https://github.com/pingcap/tidb/issues/53236) @[winoros](https://github.com/winoros) - - TiDBがオフラインになっているTiFlashノードにプローブ要求を送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) + - TiDBがオフラインになっているTiFlashノードにプローブリクエストを送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が発生する問題を修正[#50235](https://github.com/pingcap/tidb/issues/50235) @[qw4990](https://github.com/qw4990) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` の場合にAUTO_INCREMENT列の値が減少する可能性がある問題を修正しました。 [#52600](https://github.com/pingcap/tidb/issues/52600) @[tiancaiamao](https://github.com/tiancaiamao) - BIGINT 以外の符号なし整数が文字列/小数点と比較されたときに誤った結果を生成する可能性がある問題を修正しました [#41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) diff --git a/releases/release-6.5.11.md b/releases/release-6.5.11.md index acc26ba9aefb3..f6d963968b6c5 100644 --- a/releases/release-6.5.11.md +++ b/releases/release-6.5.11.md @@ -96,7 +96,7 @@ TiDBバージョン: 6.5.11 - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[#8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - データベースが作成直後に削除されるとTiFlash がpanicする可能性がある問題を修正[#9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 外部結合を含むクエリの実行中にエラーが発生した場合にTiFlashがクラッシュする可能性がある問題を修正しました。 [#9190](https://github.com/pingcap/tiflash/issues/9190) @[windtalker](https://github.com/windtalker) - データ型を`DECIMAL`に変換すると、一部のコーナーケースで誤ったクエリ結果が発生する可能性がある問題を修正しました[#53892](https://github.com/pingcap/tidb/issues/53892) @[guo-shaoge](https://github.com/guo-shaoge) - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブルメタデータのレプリケーションが遅くなり、クエリパフォーマンスが低下する可能性がある問題を修正しました[#9227](https://github.com/pingcap/tiflash/issues/9227) @[JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-6.5.5.md b/releases/release-6.5.5.md index 1788b57f159cb..31a1ff2ac1ddb 100644 --- a/releases/release-6.5.5.md +++ b/releases/release-6.5.5.md @@ -16,7 +16,7 @@ TiDB バージョン: 6.5.5 - TiDB - [`NO_MERGE_JOIN()`](/optimizer-hints.md#no_merge_joint1_name--tl_name-)、[`NO_INDEX_JOIN()`](/optimizer-hints.md#no_index_joint1_name--tl_name-)、[`NO_INDEX_MERGE_JOIN()`](/optimizer-hints.md#no_index_merge_joint1_name--tl_name-)、[`NO_HASH_JOIN()`](/optimizer-hints.md#no_hash_joint1_name--tl_name-)、[`NO_INDEX_HASH_JOIN()`](/optimizer-hints.md#no_index_hash_joint1_name--tl_name-)を含む新しいオプティマイザヒントを追加 [#45520](https://github.com/pingcap/tidb/issues/45520) @[qw4990](https://github.com/qw4990) - - コプロセッサに関連する要求元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) + - コプロセッサに関連するリクエスト元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) - TiKV diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index b4e3fa79314bd..3d246197e8e08 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -100,7 +100,7 @@ TiDB バージョン: 6.5.6 - ピアを移動するとFollower Readのパフォーマンスが低下する可能性がある問題を修正[#15468](https://github.com/tikv/tikv/issues/15468) @[YuJuncen](https://github.com/YuJuncen) - raftstore-applys が継続的に増加するデータエラーを修正しました [#15371](https://github.com/tikv/tikv/issues/15371) @[Connor1996](https://github.com/Connor1996) - - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサの要求がタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) + - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサのリクエストがタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) - `lz4-sys`のバージョンを 1.9.4 にアップグレードしてセキュリティ問題を修正しました [#15621](https://github.com/tikv/tikv/issues/15621) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - バージョン`tokio`を 6.5 にアップグレードしてセキュリティ問題を修正しました [#15621](https://github.com/tikv/tikv/issues/15621) @[LykxSassinator](https://github.com/LykxSassinator) - `flatbuffer` を削除してセキュリティ問題を修正 [#15621](https://github.com/tikv/tikv/issues/15621) @[tonyxuqqi](https://github.com/tonyxuqqi) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index f339ba71efa58..91876a680c87a 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -17,7 +17,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone バージョン6.6.0-DMRの主な新機能と改善点は以下のとおりです。 -
カテゴリ特徴説明
拡張性とパフォーマンス
TiKVはパーティション化されたRaft KVストレージエンジンをサポートしています（実験的）。 TiKVはパーティション化されたRaft KVストレージエンジンを導入しており、各リージョンは独立したRocksDBインスタンスを使用するため、クラスターのストレージ容量をテラバイトからペタバイトまで容易に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
TiKVはデータ要求のバッチ集計をサポートしていますこの機能強化により、TiKVのバッチ取得操作におけるRPCの総数が大幅に削減されます。データが高度に分散しており、gRPCスレッドプールのリソースが不足している状況では、コプロセッサ要求をバッチ処理することで、パフォーマンスを50%以上向上させることができます。
TiFlashは、 ステイル読み取りと圧縮交換をサポートしています。 TiFlashは、リアルタイム要件に制約がないシナリオにおいてクエリ性能を向上させることができる、古いデータの読み取り機能をサポートしています。また、 TiFlashはデータ圧縮をサポートしており、並列データ交換の効率を向上させ、TPC-H全体のパフォーマンスを10%向上させ、ネットワーク使用量を50%以上削減できます。
信頼性と可用性
リソース制御（実験的）リソースグループに基づいたリソース管理をサポートします。これにより、データベースユーザーを対応するリソースグループにマッピングし、実際のニーズに基づいて各リソースグループの割り当て量を設定します。
履歴SQLバインディングTiDB Dashboard上で、過去の実行計画のバインドと、実行計画の迅速なバインドをサポートします。
SQLの機能
外部キー（実験的）データの一貫性を維持し、データ品質を向上させるために、MySQL互換の外部キー制約をサポートします。
多値インデックス（実験的） MySQL互換の多値インデックスを導入し、JSON型を拡張することで、TiDBのMySQL 8.0との互換性を向上させます。
DB操作と可観測性
DMは物理的なインポートをサポートします（実験的） TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードを統合することで、フルデータ移行のパフォーマンスを向上させ、最大10倍高速化します。
+
カテゴリ特徴説明
拡張性とパフォーマンス
TiKVはパーティション化されたRaft KVストレージエンジンをサポートしています（実験的）。 TiKVはパーティション化されたRaft KVストレージエンジンを導入しており、各リージョンは独立したRocksDBインスタンスを使用するため、クラスターのストレージ容量をテラバイトからペタバイトまで容易に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
TiKVはデータリクエストのバッチ集計をサポートしていますこの機能強化により、TiKVのバッチ取得操作におけるRPCの総数が大幅に削減されます。データが高度に分散しており、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することで、パフォーマンスを50%以上向上させることができます。
TiFlashは、 ステイル読み取りと圧縮交換をサポートしています。 TiFlashは、リアルタイム要件に制約がないシナリオにおいてクエリ性能を向上させることができる、古いデータの読み取り機能をサポートしています。また、 TiFlashはデータ圧縮をサポートしており、並列データ交換の効率を向上させ、TPC-H全体のパフォーマンスを10%向上させ、ネットワーク使用量を50%以上削減できます。
信頼性と可用性
リソース制御（実験的）リソースグループに基づいたリソース管理をサポートします。これにより、データベースユーザーを対応するリソースグループにマッピングし、実際のニーズに基づいて各リソースグループの割り当て量を設定します。
履歴SQLバインディングTiDB Dashboard上で、過去の実行計画のバインドと、実行計画の迅速なバインドをサポートします。
SQLの機能
外部キー（実験的）データの一貫性を維持し、データ品質を向上させるために、MySQL互換の外部キー制約をサポートします。
多値インデックス（実験的） MySQL互換の多値インデックスを導入し、JSON型を拡張することで、TiDBのMySQL 8.0との互換性を向上させます。
DB操作と可観測性
DMは物理的なインポートをサポートします（実験的） TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードを統合することで、フルデータ移行のパフォーマンスを向上させ、最大10倍高速化します。
## 機能の詳細 {#feature-details} @@ -45,9 +45,9 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone 詳細については、 [ドキュメント](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660)を参照してください。 -- バッチ集計データ要求 [#39361](https://github.com/pingcap/tidb/issues/39361) @[cfzjywxk](https://github.com/cfzjywxk) @[you06](https://github.com/you06) +- バッチ集計データリクエスト [#39361](https://github.com/pingcap/tidb/issues/39361) @[cfzjywxk](https://github.com/cfzjywxk) @[you06](https://github.com/you06) - TiDB が TiKV にデータ要求を送信すると、TiDB はデータが存在するリージョンに応じて要求を複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンの要求のみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC 要求が発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータ要求を部分的にマージする機能をサポートしており、サブタスクの数と RPC 要求のオーバーヘッドを削減します。データの分散度が高く、gRPC スレッドプールのリソースが不足している場合、要求をバッチ処理することでパフォーマンスを 50% 以上向上させることができます。 + TiDB が TiKV にデータリクエストを送信すると、TiDB はデータが存在するリージョンに応じてリクエストを複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンのリクエストのみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC リクエストが発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータリクエストを部分的にマージする機能をサポートしており、サブタスクの数と RPC リクエストのオーバーヘッドを削減します。データの分散度が高く、gRPC スレッドプールのリソースが不足している場合、リクエストをバッチ処理することでパフォーマンスを 50% 以上向上させることができます。 この機能はデフォルトで有効になっています。システム変数[`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size)を使用して、リクエストのバッチサイズを設定できます。 @@ -352,7 +352,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | TiDB | [`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | ステートメントサマリーデータの永続化が有効になっている場合、この設定では永続データファイルを保持する最大日数を指定します。 | | TiDB | [`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | ステートメントサマリーの永続化が有効になっている場合、この設定では永続データファイルの最大サイズ（MiB単位）を指定します。 | | TiDB | [`tidb_stmt_summary_filename`](/tidb-configuration-file.md#tidb_stmt_summary_filename-new-in-v660) | 新しく追加された | ステートメントサマリーデータの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 | -| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソースグループのリクエストユニット (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソースグループの RU に基づくスケジューリングを無効にすることを意味します。 | +| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソースグループのリクエストユニット (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソースグループの RU に基づくスケジューリングを無効にすることを意味します。 | | TiKV | [`storage.engine`](/tikv-configuration-file.md#engine-new-in-v660) | 新しく追加された | この設定項目は、ストレージエンジンのタイプを指定します。値のオプションは`"raft-kv"`と`"partitioned-raft-kv"`です。この設定項目は、クラスタ作成時にのみ指定でき、一度指定すると変更できません。 | | TiKV | [`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660) | 新しく追加された | この設定項目は、現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 | | TiKV | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 新しく追加された | この設定項目は、単一の TiKV 内のすべての RocksDB インスタンス`memtable`が使用する合計メモリの制限を指定します。デフォルト値は、マシン全体のメモリの 25% です。 | diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index c6dc459000ac0..a873a73027c24 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -307,10 +307,10 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone | TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 変更 | デフォルト値が`false`から`true`に変更されます。 | | TiKV | [`raft-engine.prefill-for-recycle`](/tikv-configuration-file.md#prefill-for-recycle-new-in-v700) | 新しく追加された | Raft Engineのログリサイクル用に空のログファイルを生成するかどうかを制御します。デフォルト値は`false`です。 | | PD | [`degraded-mode-wait-duration`](/pd-configuration-file.md#degraded-mode-wait-duration) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。劣化モードをトリガーするまでの待機時間を制御します。デフォルト値は`0s`です。 | -| PD | [`read-base-cost`](/pd-configuration-file.md#read-base-cost) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取り要求から RU への変換の基準係数を制御します。デフォルト値は`0.25`です。 | +| PD | [`read-base-cost`](/pd-configuration-file.md#read-base-cost) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取りリクエストから RU への変換の基準係数を制御します。デフォルト値は`0.25`です。 | | PD | [`read-cost-per-byte`](/pd-configuration-file.md#read-cost-per-byte) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取りフローからRUへの変換の基準係数を制御します。デフォルト値は`1/ (64 * 1024)`です。 | | PD | [`read-cpu-ms-cost`](/pd-configuration-file.md#read-cpu-ms-cost) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。CPUからRUへの変換の基準係数を制御します。デフォルト値は`1/3`です。 | -| PD | [`write-base-cost`](/pd-configuration-file.md#write-base-cost) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連の設定項目です。書き込み要求からRUへの変換の基準係数を制御します。デフォルト値は`1`です。 | +| PD | [`write-base-cost`](/pd-configuration-file.md#write-base-cost) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連の設定項目です。書き込みリクエストからRUへの変換の基準係数を制御します。デフォルト値は`1`です。 | | PD | [`write-cost-per-byte`](/pd-configuration-file.md#write-cost-per-byte) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連の設定項目です。書き込みフローからRUへの変換の基準係数を制御します。デフォルト値は`1/1024`です。 | | TiFlash | [`mark_cache_size`](/tiflash/tiflash-configuration.md) | 変更 | TiFlashのデータブロックのメタデータのデフォルトのキャッシュ制限を`5368709120`から`1073741824`に変更して、不要なメモリ使用量を削減します。 | | TiFlash | [`minmax_index_cache_size`](/tiflash/tiflash-configuration.md) | 変更 | TiFlashのデータブロックの最小-最大インデックスのデフォルトのキャッシュ制限を`5368709120`から`1073741824`に変更して、不要なメモリ使用量を削減します。 | @@ -387,7 +387,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - TiDBをv6.5.1からそれ以降のバージョンにアップグレードする際にアップデートが欠落する問題を修正 [#41502](https://github.com/pingcap/tidb/issues/41502) @[chrysan](https://github.com/chrysan) - アップグレード後に一部のシステム変数のデフォルト値が変更されない問題を修正 [#41423](https://github.com/pingcap/tidb/issues/41423) @[crazycs520](https://github.com/crazycs520) - - インデックス追加に関連するコプロセッサー要求タイプが不明として表示される問題を修正 [#41400](https://github.com/pingcap/tidb/issues/41400) @[tangenta](https://github.com/tangenta) + - インデックス追加に関連するコプロセッサーリクエストタイプが不明として表示される問題を修正 [#41400](https://github.com/pingcap/tidb/issues/41400) @[tangenta](https://github.com/tangenta) - インデックスを追加する際に「PessimisticLockNotFound」が返される問題を修正 [#41515](https://github.com/pingcap/tidb/issues/41515) @[tangenta](https://github.com/tangenta) - 一意インデックスを追加する際に誤って`found duplicate key`を返す問題を修正 [#41630](https://github.com/pingcap/tidb/issues/41630) @[tangenta](https://github.com/tangenta) - インデックス追加時のpanic問題を修正 [#41880](https://github.com/pingcap/tidb/issues/41880) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index d8654c14b5288..b1710110271d1 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -15,7 +15,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 以前の LTS 6.5.0 と比較して、7.1.0 には、 [6.6.0-DMR](/releases/release-6.6.0.md) 、 [7.0.0-DMR](/releases/release-7.0.0.md)でリリースされた新機能、改善、バグ修正が含まれているだけでなく、次の主要な機能と改善も導入されています。 -
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データ要求をサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取り要求をそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパー​​ティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーションクラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成列（GA）生成列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（Enterprise Editionのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
+
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データリクエストをサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取りリクエストをそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパー​​ティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーションクラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成列（GA）生成列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（Enterprise Editionのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
## 機能の詳細 {#feature-details} @@ -49,7 +49,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - 読み取りホットスポットを軽減するために負荷ベースのレプリカ読み取りをサポートする[#14151](https://github.com/tikv/tikv/issues/14151) @[sticnarf](https://github.com/sticnarf) @[you06](https://github.com/you06) - 読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 + 読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取りリクエストを時間内に処理できず、読み取りリクエストがキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取りリクエストのキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)を参照してください。 diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index 2dbc9e699540f..61e5ed5d22af8 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -29,7 +29,7 @@ TiDB バージョン: 7.1.2 - TiDB - [`NO_MERGE_JOIN()`](/optimizer-hints.md#no_merge_joint1_name--tl_name-)、[`NO_INDEX_JOIN()`](/optimizer-hints.md#no_index_joint1_name--tl_name-)、[`NO_INDEX_MERGE_JOIN()`](/optimizer-hints.md#no_index_merge_joint1_name--tl_name-)、[`NO_HASH_JOIN()`](/optimizer-hints.md#no_hash_joint1_name--tl_name-)、[`NO_INDEX_HASH_JOIN()`](/optimizer-hints.md#no_index_hash_joint1_name--tl_name-)を含む新しいオプティマイザヒントを追加 [#45520](https://github.com/pingcap/tidb/issues/45520) @[qw4990](https://github.com/qw4990) - - コプロセッサに関連する要求元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) + - コプロセッサに関連するリクエスト元情報を追加します [#46514](https://github.com/pingcap/tidb/issues/46514) @[you06](https://github.com/you06) - TiDBノードのアップグレードステータスの開始と終了をマークするために`/upgrade/start`と`upgrade/finish` APIを追加します。 [#47172](https://github.com/pingcap/tidb/issues/47172) @[zimulala](https://github.com/zimulala) - TiKV @@ -44,7 +44,7 @@ TiDB バージョン: 7.1.2 - PD - - PD 呼び出し元のバックオフ メカニズムを最適化して、呼び出しが失敗したときの RPC 要求の頻度を減らします[#6556](https://github.com/tikv/pd/issues/6556) @[nolouch](https://github.com/nolouch) @[rleungx](https://github.com/rleungx) @[HuSharp](https://github.com/HuSharp) + - PD 呼び出し元のバックオフ メカニズムを最適化して、呼び出しが失敗したときの RPC リクエストの頻度を減らします[#6556](https://github.com/tikv/pd/issues/6556) @[nolouch](https://github.com/nolouch) @[rleungx](https://github.com/rleungx) @[HuSharp](https://github.com/HuSharp) - 発信者が切断されたときにCPUとメモリを時間内に解放するために、 `GetRegions`インターフェースにキャンセルメカニズムを導入する[#6835](https://github.com/tikv/pd/issues/6835) @[lhy1024](https://github.com/lhy1024) - TiFlash @@ -132,7 +132,7 @@ TiDB バージョン: 7.1.2 - オンラインアンセーフリカバリがタイムアウトで中止されない問題を修正 [#15346](https://github.com/tikv/tikv/issues/15346) @[Connor1996](https://github.com/Connor1996) - 暗号化により部分書き込み中にデータ破損が発生する可能性がある問題を修正 [#15080](https://github.com/tikv/tikv/issues/15080) @[tabokie](https://github.com/tabokie) - リージョンのメタデータが正しくないことによって引き起こされるTiKV panic問題を修正しました [#13311](https://github.com/tikv/tikv/issues/13311) @[cfzjywxk](https://github.com/cfzjywxk) - - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサの要求がタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) + - オンラインワークロードがある場合にTiDB Lightningチェックサムコプロセッサのリクエストがタイムアウトする問題を修正しました [#15565](https://github.com/tikv/tikv/issues/15565) @[lance6716](https://github.com/lance6716) - ピアを移動するとFollower Readのパフォーマンスが低下する可能性がある問題を修正[#15468](https://github.com/tikv/tikv/issues/15468) @[YuJuncen](https://github.com/YuJuncen) - PD diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index 26b55fedc8fa3..039685027d45f 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -60,7 +60,7 @@ TiDB バージョン: 7.1.5 - `TIDB_HOT_REGIONS`テーブルをクエリすると、誤って`INFORMATION_SCHEMA`テーブルが返される可能性がある問題を修正しました。 [#50810](https://github.com/pingcap/tidb/issues/50810) @[Defined2014](https://github.com/Defined2014) - `IFNULL`関数によって返される型が MySQL と一致しない問題を修正しました [#51765](https://github.com/pingcap/tidb/issues/51765) @[YangKeao](https://github.com/YangKeao) - TTL 機能により、データ範囲の分割が不正確になり、場合によってはでデータ ホットスポットが発生する問題を修正しました。 [#51527](https://github.com/pingcap/tidb/issues/51527) @[lcwangchao](https://github.com/lcwangchao) - - TiDBがオフラインになっているTiFlashノードにプローブ要求を送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) + - TiDBがオフラインになっているTiFlashノードにプローブリクエストを送信し続ける問題を修正[#46602](https://github.com/pingcap/tidb/issues/46602) @[zyguan](https://github.com/zyguan) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` の場合にAUTO_INCREMENT列の値が減少する可能性がある問題を修正しました。 [#52600](https://github.com/pingcap/tidb/issues/52600) @[tiancaiamao](https://github.com/tiancaiamao) - `INSERT IGNORE`を実行すると、一意インデックスとデータの間に不整合が発生する可能性がある問題を修正しました。 [#51784](https://github.com/pingcap/tidb/issues/51784) @[wjhuang2016](https://github.com/wjhuang2016) - 一意インデックスを追加するとTiDBがpanicする可能性がある問題を修正[#52312](https://github.com/pingcap/tidb/issues/52312) @[wjhuang2016](https://github.com/wjhuang2016) diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index efa646115bab4..8c26d01cea4c1 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -14,7 +14,7 @@ TiDB バージョン: 7.1.6 ## 互換性の変更 {#compatibility-changes} - [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.1/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を2048に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [#55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`件目のイベントを`DELETE`目と`INSERT`件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`と`INSERT`イベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`がTiCDCの`thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`イベントを`DELETE`と`INSERT`イベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`イベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`イベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks)を参照してください。@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) - TiDB Lightning `strict-format`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - TiKV設定項目[`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type)のスコープを変更します。 @@ -42,7 +42,7 @@ TiDB バージョン: 7.1.6 - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - 同時実行性の高いデータ読み取り操作におけるロック競合を減らし、短いクエリのパフォーマンスを最適化します[#9125](https://github.com/pingcap/tiflash/issues/9125) @[JinheLin](https://github.com/JinheLin) - クラスター化インデックスを持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 [#9529](https://github.com/pingcap/tiflash/issues/9529) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -195,7 +195,7 @@ TiDB バージョン: 7.1.6 - `DECIMAL`型の小数点部分がの場合に正しくない問題を修正しました [#16913](https://github.com/tikv/tikv/issues/16913) @[gengliqi](https://github.com/gengliqi) - クエリ内の`CONV()`関数が数値システム変換中にオーバーフローし、TiKV panicが発生する問題を修正しました。 [#16969](https://github.com/tikv/tikv/issues/16969) @[gengliqi](https://github.com/gengliqi) - 古いレプリカがRaftスナップショットを処理するときに、遅い分割操作と新しいレプリカの即時削除によってトリガーされ、TiKV がpanicになる可能性がある問題を修正しました。 [#17469](https://github.com/tikv/tikv/issues/17469) @[hbisheng](https://github.com/hbisheng) - - 同時実行性の高いコプロセッサー要求により TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) + - 同時実行性の高いコプロセッサーリクエストにより TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - マスターキーがキー管理サービス (KMS) に保存されているときにマスターキーのローテーションを妨げる問題を修正しました [#17410](https://github.com/tikv/tikv/issues/17410) @[hhwyt](https://github.com/hhwyt) - tikv-ctlの`raft region`コマンドの出力にリージョンステータス情報が含まれていない問題を修正しました [#17037](https://github.com/tikv/tikv/issues/17037) @[glorv](https://github.com/glorv) - Grafana の TiKV パネルの**ストレージ非同期書き込み期間の**監視メトリックが不正確であるという問題を修正しました[#17579](https://github.com/tikv/tikv/issues/17579) @[overvenus](https://github.com/overvenus) @@ -233,7 +233,7 @@ TiDB バージョン: 7.1.6 - 遅延マテリアライゼーションが有効になっている場合に一部のクエリでエラーが報告される可能性がある問題を修正[#9472](https://github.com/pingcap/tiflash/issues/9472) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlashでサポートされていない一部の JSON関数がTiFlash にプッシュダウンされる問題を修正しました [#9444](https://github.com/pingcap/tiflash/issues/9444) @[windtalker](https://github.com/windtalker) - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - BRまたはTiDB Lightning 経由でデータをインポートした後、FastScanモードで多数の重複行が読み取られる可能性がある問題を修正しました。 [#9118](https://github.com/pingcap/tiflash/issues/9118) @[JinheLin](https://github.com/JinheLin) - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [#9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 遅延マテリアライゼーションが有効になった後、仮想生成列を含むクエリが誤った結果を返す可能性がある問題を修正[#9188](https://github.com/pingcap/tiflash/issues/9188) @[JinheLin](https://github.com/JinheLin) diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 3dcc5fcca9df9..d6af60338bc85 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -26,7 +26,7 @@ TiDB バージョン: 7.2.0 - TiFlashはパイプライン実行モデルをサポートします（実験的） [#6518](https://github.com/pingcap/tiflash/issues/6518) @[SeaRise](https://github.com/SeaRise) - バージョン7.2.0より前は、 TiFlashエンジン内の各タスクは実行時に個別にスレッドリソースを要求する必要がありました。TiFlashはタスク数を制御することでスレッドリソースの使用量を制限し、過剰使用を防いでいましたが、この問題を完全に解消することはできませんでした。この問題に対処するため、バージョン7.2.0以降、 TiFlashはパイプライン実行モデルを導入しました。このモデルでは、すべてのスレッドリソースを一元的に管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッドリソースの利用率を最大化します。パイプライン実行モデルを有効または無効にするには、システム変数[`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables/#tidb_enable_tiflash_pipeline_model-new-in-v720)を変更してください。 + バージョン7.2.0より前は、 TiFlashエンジン内の各タスクは実行時に個別にスレッドリソースをリクエストする必要がありました。TiFlashはタスク数を制御することでスレッドリソースの使用量を制限し、過剰使用を防いでいましたが、この問題を完全に解消することはできませんでした。この問題に対処するため、バージョン7.2.0以降、 TiFlashはパイプライン実行モデルを導入しました。このモデルでは、すべてのスレッドリソースを一元的に管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッドリソースの利用率を最大化します。パイプライン実行モデルを有効または無効にするには、システム変数[`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables/#tidb_enable_tiflash_pipeline_model-new-in-v720)を変更してください。 詳細については、[ドキュメント](/tiflash/tiflash-pipeline-model.md)を参照してください。 @@ -191,7 +191,7 @@ TiDB バージョン: 7.2.0 - TiKV - - `pd.retry-interval`を使用した接続要求失敗などのシナリオで PD 接続の再試行間隔を設定することをサポートします [#14964](https://github.com/tikv/tikv/issues/14964) @[rleungx](https://github.com/rleungx) + - `pd.retry-interval`を使用した接続リクエスト失敗などのシナリオで PD 接続の再試行間隔を設定することをサポートします [#14964](https://github.com/tikv/tikv/issues/14964) @[rleungx](https://github.com/rleungx) - グローバルなリソース使用状況を組み込むことで、リソース制御スケジューリングアルゴリズムを最適化する [#14604](https://github.com/tikv/tikv/issues/14604) @[Connor1996](https://github.com/Connor1996) - `check_leader`リクエストに gzip 圧縮を使用してトラフィックを削減します [#14553](https://github.com/tikv/tikv/issues/14553) @[you06](https://github.com/you06) - `check_leader`リクエストに関連するメトリクスを追加 [#14658](https://github.com/tikv/tikv/issues/14658) @[you06](https://github.com/you06) diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index aeb0a1d2042a3..f14b593b28805 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.4.0 通常、TiKVはリクエストを数ミリ秒という非常に高速に処理します。しかし、TiKVノードがディスクI/Oジッターやネットワークレイテンシーに遭遇すると、リクエスト処理時間が大幅に増加する可能性があります。v7.4.0より前のバージョンでは、TiKVリクエストのタイムアウト制限は固定されており、調整できません。そのため、TiKVノードで問題が発生すると、TiDBは一定時間のタイムアウト応答を待機する必要があり、ジッター発生時のアプリケーションクエリパフォーマンスに顕著な影響が生じます。 - TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやストレージ環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 + TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取りリクエストのタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信されたリクエストが遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードにリクエストを再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用して、TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやストレージ環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 詳細については[ドキュメント](/system-variables.md#tikv_client_read_timeout-new-in-v740)を参照してください。 diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index f45b6e6f120a7..9feabb34e10bf 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -121,7 +121,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 | コンフィグレーションファイル | コンフィグレーションパラメータ | 変更の種類 | 説明 | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- | -| TiDB | [`tikv-client.copr-req-timeout`](/tidb-configuration-file.md#copr-req-timeout-new-in-v750) | 新しく追加された | 単一のコプロセッサー要求のタイムアウトを設定します。 | +| TiDB | [`tikv-client.copr-req-timeout`](/tidb-configuration-file.md#copr-req-timeout-new-in-v750) | 新しく追加された | 単一のコプロセッサーリクエストのタイムアウトを設定します。 | | TiKV | [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval) | 変更 | 低速ノード検出の感度を向上させるためにアルゴリズムを最適化した後、デフォルト値を`500ms`から`100ms`に変更します。 | | TiKV | [`raftstore.region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710) | 変更 | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の数を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`ストレージエンジンに対して有効になります。 | | TiKV | [`raftstore.region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710) | 変更 | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の割合を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`ストレージエンジンに対して有効になります。 | @@ -206,7 +206,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - TiKV - - 悲観的トランザクションモードでのプリライト要求の再試行が、まれにデータ不整合のリスクを引き起こす可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) @[MyonKeminta](https://github.com/MyonKeminta) + - 悲観的トランザクションモードでのプリライトリクエストの再試行が、まれにデータ不整合のリスクを引き起こす可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) @[MyonKeminta](https://github.com/MyonKeminta) - PD diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index bd0ba3ef8f6b5..c7b6155e22df3 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -16,7 +16,7 @@ TiDB バージョン: 7.5.2 - RocksDB の TiKV 設定項目[`track-and-verify-wals-in-manifest`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#track-and-verify-wals-in-manifest-new-in-v659-v715-and-v752)を追加します。これは、Write Ahead Log (WAL) の破損の可能性を調査するのに役立ちます。 [#16549](https://github.com/tikv/tikv/issues/16549) @[v01dstar](https://github.com/v01dstar) - TiDB Lightning `strict-format`または`SPLIT_FILE`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - TiCDCオープンプロトコルの`sink.open.output-old-value`設定項目を追加して、更新前の値を下流に出力するかどうかを制御します。 [#10916](https://github.com/pingcap/tiflow/issues/10916) @[sdojjy](https://github.com/sdojjy) -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.5.2以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`目のイベントを`DELETE` `INSERT`と13件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`と`INSERT`イベントに分割していました。v7.5.2以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`がTiCDCの`thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`イベントを`DELETE`と`INSERT`イベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`イベントの順序が誤っている可能性があり、分割された`DELETE`と`INSERT`イベントの順序が誤っている可能性があるため、ダウンストリームデータの不整合が発生する問題に対処しています。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.5/ticdc-split-update-behavior#split-update-events-for-mysql-sinks)を参照してください。@[lidezhu](https://github.com/lidezhu) [#10918](https://github.com/pingcap/tiflow/issues/10918) ## 改善点 {#improvements} diff --git a/releases/release-7.5.3.md b/releases/release-7.5.3.md index 52c999e3cb6dd..c890f91a06daa 100644 --- a/releases/release-7.5.3.md +++ b/releases/release-7.5.3.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.5.3 - TiKV - gRPC メッセージ圧縮方式を`grpc-compression-type`で設定しても、TiKV から TiDB に送信されるメッセージには反映されない問題を修正しました。 [#17176](https://github.com/tikv/tikv/issues/17176) @[ekexium](https://github.com/ekexium) - - 同時実行性の高いコプロセッサー要求により TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) + - 同時実行性の高いコプロセッサーリクエストにより TiKV OOM が発生する可能性がある問題を修正しました [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - CDC とログバックアップが`advance-ts-interval`構成を使用して`check_leader`のタイムアウトを制限しないため、TiKV が正常に再起動したときに`resolved_ts`遅延が大きくなる場合がある問題を修正しました[#17107](https://github.com/tikv/tikv/issues/17107) @[MyonKeminta](https://github.com/MyonKeminta) - 破損したRaftデータスナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [#15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index 1a8837062436c..d8e67e08ebe2e 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -33,7 +33,7 @@ TiDB バージョン: 7.5.4 - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - ツール @@ -93,7 +93,7 @@ TiDB バージョン: 7.5.4 - TiFlash - 分散ストレージおよびコンピューティングアーキテクチャでTiFlash書き込みノードが再起動に失敗する可能性がある問題を修正しました [#9282](https://github.com/pingcap/tiflash/issues/9282) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[#8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 [#9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [#9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 5cea735db8ef4..9f78c64de3f35 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -114,7 +114,7 @@ TiDB バージョン: 7.5.7 - CPUプロファイリング中にデッドロックが発生する可能性がある問題を修正 [#18474](https://github.com/tikv/tikv/issues/18474) @[YangKeao](https://github.com/YangKeao) - 特定のTiFlashレプリカによってオンライン アンセーフ リカバリがブロックされ、コミット インデックスが進まなくなる問題を修正しました。 [#18197](https://github.com/tikv/tikv/issues/18197) @[v01dstar](https://github.com/v01dstar) - TiKVがクライアントがデコードできない圧縮アルゴリズムを使用する可能性がある問題を修正しました [#18079](https://github.com/tikv/tikv/issues/18079) @[ekexium](https://github.com/ekexium) - - TiKV が高同時実行で過剰な SST 取り込み要求を許可する問題を修正 [#18452](https://github.com/tikv/tikv/issues/18452) @[hbisheng](https://github.com/hbisheng) + - TiKV が高同時実行で過剰な SST 取り込みリクエストを許可する問題を修正 [#18452](https://github.com/tikv/tikv/issues/18452) @[hbisheng](https://github.com/hbisheng) - Grafana の TiKV ダッシュボードで`Ingestion picked level`と`Compaction Job Size(files)`が誤って表示される問題を修正しました [#15990](https://github.com/tikv/tikv/issues/15990) @[Connor1996](https://github.com/Connor1996) - TiKV が再起動した後に予期しない`Server is busy`エラーが発生する問題を修正しました [#18233](https://github.com/tikv/tikv/issues/18233) @[LykxSassinator](https://github.com/LykxSassinator) - TiKVがブラジルとエジプトのタイムゾーンを誤って変換する問題を修正[#16220](https://github.com/tikv/tikv/issues/16220) @[overvenus](https://github.com/overvenus) diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index bb699f65f3f16..68da0dfc83b82 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -23,7 +23,7 @@ TiDB バージョン: 7.6.0 リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 - 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 + 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報リクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 詳細については、 [ドキュメント](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)を参照してください。 @@ -239,7 +239,7 @@ TiDB バージョン: 7.6.0 | [`tidb_ignore_inlist_plan_digest`](/system-variables.md#tidb_ignore_inlist_plan_digest-new-in-v760) | 新しく追加された | プランダイジェストを生成する際に、TiDB が異なるクエリ間で`IN`リスト内の要素の差異を無視するかどうかを制御します。デフォルト値`OFF`は、差異を無視しないことを意味します。 | | [`tidb_opt_enable_fuzzy_binding`](/system-variables.md#tidb_opt_enable_fuzzy_binding-new-in-v760) | 新しく追加された | クロスデータベースバインディング機能を有効にするかどうかを制御します。デフォルト値`OFF`は、クロスデータベースバインディングが無効であることを意味します。 | | [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760) | 新しく追加された | TiDB 設定項目[`performance.txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)を動的に変更します。これは、TiDB 内の単一行のデータのサイズを制限します。この変数のデフォルト値は`0`です。これは、TiDB がデフォルトで設定項目`txn-entry-size-limit`の値を使用することを意味します。この変数がゼロ以外の値に設定されている場合、 `txn-entry-size-limit`も同じ値に設定されます。 | -| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | 新しく追加された | 有効にするかどうかを制御します[アクティブなPDFollower](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)機能 (実験的)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報の要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるため、PD リーダーの CPU 負荷が軽減されます。 | +| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | 新しく追加された | 有効にするかどうかを制御します[アクティブなPDFollower](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)機能 (実験的)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報のリクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるため、PD リーダーの CPU 負荷が軽減されます。 | ### コンフィグレーションファイルパラメータ {#configuration-file-parameters} diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 14e1e804edc26..a1669950892a9 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -303,7 +303,7 @@ TiDB バージョン: 8.0.0 | TiKV | [`rocksdb.defaultcf.titan.shared-blob-cache`](/tikv-configuration-file.md#shared-blob-cache-new-in-v800) | 新しく追加された | Titan blob ファイルと RocksDB ブロックファイルの共有キャッシュを有効にするかどうかを制御します。デフォルト値は`true`です。 | | TiKV | [`security.encryption.master-key.gcp.credential-file-path`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 新しく追加された | `security.encryption.master-key.vendor`が`gcp`の場合に、Google Cloud 認証情報ファイルへのパスを指定します。 | | PD | [`schedule.enable-heartbeat-breakdown-metrics`](/pd-configuration-file.md#enable-heartbeat-breakdown-metrics-new-in-v800) | 新しく追加された | リージョンハートビートの内訳メトリクスを有効にするかどうかを制御します。これらのメトリクスは、リージョンハートビート処理の各段階で消費された時間を測定し、監視による分析を容易にします。デフォルト値は`true`です。 | -| PD | [`schedule.enable-heartbeat-concurrent-runner`](/pd-configuration-file.md#enable-heartbeat-concurrent-runner-new-in-v800) | 新しく追加された | リージョンハートビートの非同期同時処理を有効にするかどうかを制御します。有効にすると、独立したエグゼキュータがリージョンハートビート要求を非同期かつ同時に処理し、ハートビート処理のスループットを向上させ、レイテンシーを削減できます。デフォルト値は`true`です。 | +| PD | [`schedule.enable-heartbeat-concurrent-runner`](/pd-configuration-file.md#enable-heartbeat-concurrent-runner-new-in-v800) | 新しく追加された | リージョンハートビートの非同期同時処理を有効にするかどうかを制御します。有効にすると、独立したエグゼキュータがリージョンハートビートリクエストを非同期かつ同時に処理し、ハートビート処理のスループットを向上させ、レイテンシーを削減できます。デフォルト値は`true`です。 | | TiDB Lightning | [`tikv-importer.duplicate-resolution`](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800) | 非推奨 | 物理インポートモードで一意キーの競合を検出して解決するかどうかを制御します。v8.0.0以降は[`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)に置き換えられています。 | | TiDB Lightning | [`conflict.precheck-conflict-before-import`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | TiDB にデータをインポートする前にデータの競合をチェックする、インポート前の競合検出を有効にするかどうかを制御します。このパラメータのデフォルト値は`false`で、これはTiDB Lightning がデータのインポート後にのみ競合をチェックすることを意味します。このパラメータは、物理インポートモード ( `tikv-importer.backend = "local"` ) でのみ使用できます。 | | TiDB Lightning | [`logical-import-batch-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | 論理インポートモードでトランザクションごとに挿入される行の最大数を制御します。デフォルト値は`65536`行です。 | diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 2c85ed2068084..ca3cb690986aa 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -119,7 +119,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 | TiDB Lightning | [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 変更 | デフォルト値を`9223372036854775807`から`10000`に変更することで、異常なタスクを迅速に中断し、対応する調整を迅速に行うことができます。これにより、異常なデータソースやテーブルスキーマ定義の誤りが原因で、インポート後に大量の競合データが発見されるというシナリオを回避し、時間と計算リソースを節約できます。 | | TiKV | [`raft-engine.batch-compression-threshold`](/tikv-configuration-file.md#batch-compression-threshold) | 変更 | デフォルト値を`"8KiB"`から`"4KiB"`に変更して、 Raftログの書き込みの IOPS オーバーヘッドを削減し、圧縮率を向上させます。 | | TiKV | [`memory.enable-thread-exclusive-arena`](/tikv-configuration-file.md#enable-thread-exclusive-arena-new-in-v810) | 新しく追加された | 各TiKVスレッドのメモリ使用量を追跡するために、TiKVスレッドレベルでメモリ割り当てステータスを表示するかどうかを制御します。デフォルト値は`true`です。 | -| TiCDC | [`security.client-allowed-user`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証に許可されるユーザー名をリストします。このリストに含まれていないユーザー名による認証要求は拒否されます。デフォルト値はnullです。 | +| TiCDC | [`security.client-allowed-user`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証に許可されるユーザー名をリストします。このリストに含まれていないユーザー名による認証リクエストは拒否されます。デフォルト値はnullです。 | | TiCDC | [`security.client-user-required`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | クライアント認証にユーザー名とパスワードを使用するかどうかを制御します。デフォルト値は`false`です。 | | TiCDC | [`security.mtls`](/ticdc/ticdc-server-config.md#cdc-server-configuration-file-parameters) | 新しく追加された | TLSクライアント認証を有効にするかどうかを制御します。デフォルト値は`false`です。 | | TiCDC | [`sink.debezium.output-old-value`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | 行データが変更される前の値を出力するかどうかを制御します。デフォルト値は`true`です。無効にすると、 `UPDATE`イベントは"before"フィールドを出力しません。 | diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 205c1683cd024..5387a20ed2232 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -159,7 +159,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiFlash - - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取りリクエストタイムアウトエラーが発生する可能性がある問題を修正しました。 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `SUBSTRING_INDEX()`関数が一部のコーナーケースでTiFlash のクラッシュを引き起こす可能性がある問題を修正[#9116](https://github.com/pingcap/tiflash/issues/9116) @[wshwsh12](https://github.com/wshwsh12) - BRまたはTiDB Lightning 経由でデータをインポートした後、FastScanモードで多数の重複行が読み取られる可能性がある問題を修正しました。 [#9118](https://github.com/pingcap/tiflash/issues/9118) @[JinheLin](https://github.com/JinheLin) - データベースが作成直後に削除されるとTiFlash がpanicする可能性がある問題を修正[#9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index 3cfbad851b191..8ac4f4488269f 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -36,8 +36,8 @@ TiDB バージョン: 8.1.2 - クラスター化インデックスを持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 [#9529](https://github.com/pingcap/tiflash/issues/9529) @[JaySon-Huang](https://github.com/JaySon-Huang) - TLS を有効にした後に証明書を更新することでTiFlash がpanicする可能性がある問題を軽減します[#8535](https://github.com/pingcap/tiflash/issues/8535) @[windtalker](https://github.com/windtalker) - - 分散ストレージとコンピューティング要求を処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのような要求を処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) - - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - 分散ストレージとコンピューティングリクエストを処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのようなリクエストを処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) + - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセルリクエストにタイムリーに応答できるようにします[#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - `LENGTH()`と`ASCII()`関数の実行効率を最適化 [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - 分散ストレージおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 からファイルをダウンロードする際の例外を処理します。 [#9695](https://github.com/pingcap/tiflash/issues/9695) @[JinheLin](https://github.com/JinheLin) diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index 77ced7c6a3234..d37a6d1b8359f 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -304,7 +304,7 @@ TiDB バージョン: 8.2.0 - `JSON_ARRAY_APPEND()`関数を TiKV にプッシュダウンすると TiKV がpanicを起こす問題を修正しました [#16930](https://github.com/tikv/tikv/issues/16930) @[dbsid](https://github.com/dbsid) - リーダーが失敗したスナップショットファイルを時間内にクリーンアップしない問題を修正 [#16976](https://github.com/tikv/tikv/issues/16976) @[hbisheng](https://github.com/hbisheng) - - 高度な同時コプロセッサー要求が TiKV OOM を引き起こす可能性がある問題を修正 [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) + - 同時実行性の高いコプロセッサーリクエストが TiKV OOM を引き起こす可能性がある問題を修正 [#16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - `raftstore.periodic-full-compact-start-times`設定項目をオンラインで変更すると TiKV がpanicを引き起こす可能性がある問題を修正 [#17066](https://github.com/tikv/tikv/issues/17066) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - `make docker`と`make docker_test`の不具合を修正 [#17075](https://github.com/tikv/tikv/issues/17075) @[shunki-fujita](https://github.com/shunki-fujita) - 監視ダッシュボードで**gRPC リクエストソースの期間**メトリクスが正しく表示されない問題を修正 [#17133](https://github.com/tikv/tikv/issues/17133) @[King-Dylan](https://github.com/King-Dylan) diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 1560567dea0b3..2e2c4ca785e32 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -333,7 +333,7 @@ TiDBバージョン：8.3.0 - PD - リソースグループにロールをバインドする際にエラーが報告されない問題を修正 [#54417](https://github.com/pingcap/tidb/issues/54417) @[JmPotato](https://github.com/JmPotato) - - リソースグループが500ミリ秒以上トークンを要求するとクォータ制限に遭遇する問題を修正 [#8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) + - リソースグループが500ミリ秒以上トークンをリクエストするとクォータ制限に遭遇する問題を修正 [#8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) - `INFORMATION_SCHEMA.RUNAWAY_WATCHES`テーブル内の時間データ型が正しくない問題を修正 [#54770](https://github.com/pingcap/tidb/issues/54770) @[HuSharp](https://github.com/HuSharp) - リソースグループが高同時実行時にリソース使用量を効果的に制限できない問題を修正 [#8435](https://github.com/tikv/pd/issues/8435) @[nolouch](https://github.com/nolouch) - テーブル属性を取得する際に誤ったPD APIが呼び出される問題を修正 [#55188](https://github.com/pingcap/tidb/issues/55188) @[JmPotato](https://github.com/JmPotato) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 7373449218817..236f3ae9c28a3 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -21,7 +21,7 @@ TiDB バージョン: 8.4.0 - TSOリクエストに並列バッチモードを導入し、TSO取得のレイテンシーを削減する[#54960](https://github.com/pingcap/tidb/issues/54960) [#8432](https://github.com/tikv/pd/issues/8432) @[MyonKeminta](https://github.com/MyonKeminta) - バージョン8.4.0より前では、TiDBはPDから[TSO](/tso.md)要求する際に、特定の期間に複数のTSO要求を収集し、それらをバッチ処理で順次処理することで、リモートプロシージャコール（RPC）要求の数を減らし、PDのワークロードを軽減していました。しかし、レイテンシに敏感なシナリオでは、この逐次バッチ処理モードのパフォーマンスは理想的ではありませんでした。 + バージョン8.4.0より前では、TiDBはPDから[TSO](/tso.md)リクエストする際に、特定の期間に複数のTSOリクエストを収集し、それらをバッチ処理で順次処理することで、リモートプロシージャコール（RPC）リクエストの数を減らし、PDのワークロードを軽減していました。しかし、レイテンシに敏感なシナリオでは、この逐次バッチ処理モードのパフォーマンスは理想的ではありませんでした。 TiDB v8.4.0では、異なる同時実行能力を持つTSOリクエスト用の並列バッチモードが導入されました。並列モードはTSO取得のレイテンシーを短縮しますが、PDのワークロードが増加する可能性があります。TSO取得に並列RPCモードを設定するには、 [`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840)システム変数を構成してください。 @@ -339,9 +339,9 @@ TiDB をアップグレードする前に、オペレーティングシステム - TiFlash - `LENGTH()`および`ASCII()`関数の実行効率を最適化する [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - - TiFlashが分散ストレージとコンピューティング要求を処理する際に作成する必要のあるスレッド数を減らし、そのような要求を多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます [#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) + - TiFlashが分散ストレージとコンピューティングリクエストを処理する際に作成する必要のあるスレッド数を減らし、そのようなリクエストを多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます [#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) - パイプライン実行モデルにおけるタスク待機メカニズムの強化 [#8869](https://github.com/pingcap/tiflash/issues/8869) @[SeaRise](https://github.com/SeaRise) - - JOIN オペレーターがキャンセル要求にタイムリーに応答できるように、JOIN オペレーターのキャンセル メカニズムを改善 [#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) + - JOIN オペレーターがキャンセルリクエストにタイムリーに応答できるように、JOIN オペレーターのキャンセル メカニズムを改善 [#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) - ツール @@ -374,7 +374,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - TopN オペレーターに続くオペレーターがメモリ制限を超えた場合にフォールバックアクションをトリガーできない問題を修正しました [#56185](https://github.com/pingcap/tidb/issues/56185) @[xzhangxian1008](https://github.com/xzhangxian1008) - ソートオペレーターの`ORDER BY`列に定数が含まれている場合に、列が固定されてしまう問題を修正しました。 [#55344](https://github.com/pingcap/tidb/issues/55344) @[xzhangxian1008](https://github.com/xzhangxian1008) - インデックスを追加する際に、PDリーダーを終了させた後に`8223 (HY000)`エラーが発生し、テーブル内のデータが不整合になる問題を修正しました [#55488](https://github.com/pingcap/tidb/issues/55488) @[tangenta](https://github.com/tangenta) - - DDL履歴ジョブが多すぎると、履歴DDLジョブに関する情報を要求するとOOMが発生する問題を修正 [#55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) + - DDL履歴ジョブが多すぎると、履歴DDLジョブに関する情報をリクエストするとOOMが発生する問題を修正 [#55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) - グローバルソートが有効で、リージョンサイズが96 MiBを超える場合に`IMPORT INTO`の実行が停止する問題を修正しました。 [#55374](https://github.com/pingcap/tidb/issues/55374) @[lance6716](https://github.com/lance6716) - 一時テーブルで`IMPORT INTO`を実行すると TiDB がクラッシュする問題を修正しました [#55970](https://github.com/pingcap/tidb/issues/55970) @[D3Hunter](https://github.com/D3Hunter) - 一意インデックスを追加すると`duplicate entry`エラーが発生する問題を修正 [#56161](https://github.com/pingcap/tidb/issues/56161) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 1f0a4aaf609f4..79f0a7ccf65cf 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -35,7 +35,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 - 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定します。この機能が有効になると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 + 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定します。この機能が有効になると、TiDB はリージョン情報リクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 詳細については、 [ドキュメント](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)を参照してください。 diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index c63c46b9b8af0..d6505892f67b0 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -42,7 +42,7 @@ TiDBバージョン：8.5.4 - TiFlashの正常なシャットダウンをサポート [#10266](https://github.com/pingcap/tiflash/issues/10266) @[gengliqi](https://github.com/gengliqi) - TiFlashサーバーをシャットダウンする際、 TiFlashは現在実行中のMPPタスクを構成可能なタイムアウト時間だけ継続させ、新しいMPPタスク要求を拒否するようになりました。デフォルトのタイムアウト時間は600秒で、 [`flash.graceful_wait_shutdown_timeout`](https://docs.pingcap.com/tidb/v8.5/tiflash-configuration#graceful_wait_shutdown_timeout-new-in-v854)設定項目を使用して調整できます。 + TiFlashサーバーをシャットダウンする際、 TiFlashは現在実行中のMPPタスクを構成可能なタイムアウト時間だけ継続させ、新しいMPPタスクリクエストを拒否するようになりました。デフォルトのタイムアウト時間は600秒で、 [`flash.graceful_wait_shutdown_timeout`](https://docs.pingcap.com/tidb/v8.5/tiflash-configuration#graceful_wait_shutdown_timeout-new-in-v854)設定項目を使用して調整できます。 - 実行中のすべてのMPPタスクがタイムアウト期間内に終了した場合、 TiFlashは直ちにシャットダウンします。 - タイムアウト期間が経過しても未完了のMPPタスクが残っている場合、 TiFlashは強制的にシャットダウンします。 diff --git a/releases/release-8.5.6.md b/releases/release-8.5.6.md index 287172ceb0e74..73b003953b62e 100644 --- a/releases/release-8.5.6.md +++ b/releases/release-8.5.6.md @@ -107,7 +107,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------- | | TiKV | [`gc.auto-compaction.mvcc-read-aware-enabled`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-aware-enabled-new-in-v856) | 新しく追加された | MVCC読み取り対応の圧縮を有効にするかどうかを制御します。デフォルト値は`false`です。 | | TiKV | [`gc.auto-compaction.mvcc-read-weight`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-weight-new-in-v856) | 新しく追加された | リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。デフォルト値は`3.0`です。 | -| TiKV | [`gc.auto-compaction.mvcc-scan-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-scan-threshold-new-in-v856) | 新しく追加された | リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。デフォルト値は`1000`です。 | +| TiKV | [`gc.auto-compaction.mvcc-scan-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-scan-threshold-new-in-v856) | 新しく追加された | リージョンを圧縮候補としてマークするために、読み取りリクエストごとにスキャンされる MVCC バージョンの最小数。デフォルト値は`1000`です。 | | TiCDC | [`sink.csv.output-field-header`](https://docs.pingcap.com/tidb/v8.5/ticdc-csv#use-csv) | 新しく追加された | CSVファイルにヘッダー行を出力するかどうかを制御します。デフォルト値は`false`です。このパラメータはTiCDCの新しいアーキテクチャにのみ適用されます。 | ### システムテーブルの変更 {#system-table-changes} @@ -163,10 +163,10 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - クロスビームスキップリストのメモリリーク問題を修正 [#19285](https://github.com/tikv/tikv/issues/19285) @[ekexium](https://github.com/ekexium) - パーティションテーブルの一意でない列のグローバルインデックスが、場合によっては不整合になり、誤った結果を返す可能性がある問題を修正しました [#19262](https://github.com/tikv/tikv/issues/19262) @[mjonss](https://github.com/mjonss) - コプロセッサのスナップショット取得が停止すると、リクエストの期限が切れるまで統合リードプールワーカーが占有され、他のリードリクエストが遅延する問題を修正しました [#18491](https://github.com/tikv/tikv/issues/18491) @[AndreMouche](https://github.com/AndreMouche) - - ディスクがいっぱいの TiKV ノードでフォロワーの読み取りがブロックされたままになる可能性がある問題を修正するため、ディスクがいっぱいのフォロワーで読み取りインデックス要求を拒否します [#19201](https://github.com/tikv/tikv/issues/19201) @[glorv](https://github.com/glorv) + - ディスクがいっぱいの TiKV ノードでフォロワーの読み取りがブロックされたままになる可能性がある問題を修正するため、ディスクがいっぱいのフォロワーで読み取りインデックスリクエストを拒否します [#19201](https://github.com/tikv/tikv/issues/19201) @[glorv](https://github.com/glorv) - resolved-tsワーカーがビジー状態のときに、 resolved-tsタスクのバックログによって OOM が発生する可能性がある問題を修正 [#18359](https://github.com/tikv/tikv/issues/18359) @[overvenus](https://github.com/overvenus) - - リーダー転送中にロングテールフォロワーの読み取りレイテンシーが発生する可能性がある問題を修正するため、読み取りインデックス要求をより早く再試行し、専用の再試行間隔設定を追加しました [#18417](https://github.com/tikv/tikv/issues/18417) @[gengliqi](https://github.com/gengliqi) - - 悲観的トランザクションでプリライト要求を再試行する際に発生するまれなデータ不整合の問題を修正 [#11187](https://github.com/tikv/tikv/issues/11187) @[wk989898](https://github.com/wk989898) + - リーダー転送中にロングテールフォロワーの読み取りレイテンシーが発生する可能性がある問題を修正するため、読み取りインデックスリクエストをより早く再試行し、専用の再試行間隔設定を追加しました [#18417](https://github.com/tikv/tikv/issues/18417) @[gengliqi](https://github.com/gengliqi) + - 悲観的トランザクションでプリライトリクエストを再試行する際に発生するまれなデータ不整合の問題を修正 [#11187](https://github.com/tikv/tikv/issues/11187) @[wk989898](https://github.com/wk989898) - PD diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index f0c1aa0376bbb..e1b29d3ad8bc5 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -59,14 +59,14 @@ v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つ You can take the following steps to upgrade TiDB manually or by using a script: -1. クラスター内の任意の TiDB ノードに HTTP アップグレード開始要求を送信します`curl -X POST http://{TiDBIP}:10080/upgrade/start` . +1. クラスター内の任意の TiDB ノードに HTTP アップグレード開始リクエストを送信します`curl -X POST http://{TiDBIP}:10080/upgrade/start` . - The TiDB cluster enters the **Upgrading** state. - The DDL operations to be performed are paused. 2. Replace the TiDB binary and perform a rolling upgrade. This process is the same as the original upgrade process. - システム DDL 操作はアップグレードプロセス中に実行されます。 -3. クラスター内のすべての TiDB ノードが正常にアップグレードされたら、任意の TiDB ノードに HTTP アップグレード完了要求を送信します`curl -X POST http://{TiDBIP}:10080/upgrade/finish` . +3. クラスター内のすべての TiDB ノードが正常にアップグレードされたら、任意の TiDB ノードに HTTP アップグレード完了リクエストを送信します`curl -X POST http://{TiDBIP}:10080/upgrade/finish` . - ユーザーの一時停止された DDL 操作が再開されます。 ## Limitations {#limitations} diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 1c50bb6e735af..125c422f4f15a 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -90,21 +90,21 @@ EXPLAIN ANALYZE SELECT * FROM t1; ## オペレーターの実行情報 {#execution-information-of-operators} -基本的な`time`と`loop`実行情報に加えて、 `execution info`はオペレーター固有の実行情報も含まれます。これには主に、オペレーターが RPC 要求を送信するのにかかった時間やその他のステップの実行時間が含まれます。 +基本的な`time`と`loop`実行情報に加えて、 `execution info`はオペレーター固有の実行情報も含まれます。これには主に、オペレーターが RPC リクエストを送信するのにかかった時間やその他のステップの実行時間が含まれます。 ### PointGet {#point-get} `Point_Get`オペレーターからの実行情報には通常、次の情報が含まれます。 -- `Get:{num_rpc:1, total_time:697.051µs}` ：TiKVに送信された`Get` RPC要求の数（ `num_rpc` ）とすべてのRPC要求の合計期間（ `total_time` ）。 +- `Get:{num_rpc:1, total_time:697.051µs}` ：TiKVに送信された`Get` RPCリクエストの数（ `num_rpc` ）とすべてのRPCリクエストの合計期間（ `total_time` ）。 - `ResolveLock:{num_rpc:1, total_time:12.117495ms}` ：TiDBはデータの読み取り時にロックに遭遇した場合、まずロックを解決する必要があります。これは通常、読み取り/書き込み競合のシナリオで発生します。この情報は、ロック解決にかかる時間を示します。 - `regionMiss_backoff:{num:11, total_time:2010 ms},tikvRPC_backoff:{num:11, total_time:10691 ms}` : RPCリクエストが失敗した場合、TiDBはリクエストを再試行する前にバックオフ時間だけ待機します。バックオフ統計には、バックオフの種類（ `regionMiss` `tikvRPC` ）、合計待機時間（ `total_time` ）、バックオフの合計回数（ `num` ）が含まれます。 ### Batch PointGet {#batch-point-get} -`Batch_Point_Get`オペレーターの実行情報は`Point_Get`オペレーターと似ていますが、 `Batch_Point_Get`通常、データを読み取りするために`BatchGet` RPC 要求を TiKV に送信します。 +`Batch_Point_Get`オペレーターの実行情報は`Point_Get`オペレーターと似ていますが、 `Batch_Point_Get`は通常、データを読み取るために`BatchGet` RPC リクエストを TiKV に送信します。 -`BatchGet:{num_rpc:2, total_time:83.13µs}` : TiKVに送信された`BatchGet`タイプのRPC要求の数( `num_rpc` )とすべてのRPC要求に費やされた合計時間( `total_time` )。 +`BatchGet:{num_rpc:2, total_time:83.13µs}` : TiKVに送信された`BatchGet`タイプのRPCリクエストの数( `num_rpc` )とすべてのRPCリクエストに費やされた合計時間( `total_time` )。 ### TableReader {#tablereader} @@ -118,8 +118,8 @@ cop_task: {num: 6, max: 1.07587ms, min: 844.312µs, avg: 919.601µs, p95: 1.0758 - `num` : cop タスクの数。 - `max` `p95` cop タスク`min`実行に費やされた実行時間の最大値、最小値、平均値、および P95 `avg` 。 - `max_proc_keys`と`p95_proc_keys` ：TiKVがすべてのcopタスクでスキャンしたキー値の最大値とP95値。最大値とP95値の差が大きい場合、データ分布が不均衡になる可能性があります。 - - `copr_cache_hit_ratio` : `cop`タスク要求に対するコプロセッサーキャッシュのヒット率。 -- `rpc_info` : 要求タイプ別に集計された、TiKV に送信された RPC 要求の合計数と合計時間。 + - `copr_cache_hit_ratio` : `cop`タスクリクエストに対するコプロセッサーキャッシュのヒット率。 +- `rpc_info` : リクエストタイプ別に集計された、TiKV に送信された RPC リクエストの合計数と合計時間。 - `backoff` : さまざまなタイプのバックオフとバックオフの合計待機時間が含まれます。 ### Insert {#insert} @@ -135,9 +135,9 @@ prepare:109.616µs, check_insert:{total_time:1.431678ms, mem_insert_time:667.878 - `total_time` : ステップ`check_insert`に費やされた合計時間。 - `mem_insert_time` : TiDB トランザクション キャッシュにデータを書き込むのにかかる時間。 - `prefetch` : TiKVから競合チェックが必要なデータを取得する時間。このステップでは、データを取得するために`Batch_Get` RPCリクエストをTiKVに送信します。 - - `rpc` : TiKV への RPC 要求の送信に費やされた合計時間。これには通常、 `BatchGet`と`Get` 2種類の RPC 時間が含まれます。 - - `prefetch`ステップで`BatchGet` RPC 要求が送信されます。 - - `insert on duplicate`ステートメントが実行されると、 `Get` `duplicate update` RPC 要求が送信されます。 + - `rpc` : TiKV への RPC リクエストの送信に費やされた合計時間。これには通常、 `BatchGet`と`Get` 2種類の RPC 時間が含まれます。 + - `prefetch`ステップで`BatchGet` RPC リクエストが送信されます。 + - `insert on duplicate`ステートメントが実行されると、 `Get` `duplicate update` RPC リクエストが送信されます。 - `backoff` : さまざまなタイプのバックオフとバックオフの合計待機時間が含まれます。 ### IndexJoin {#indexjoin} @@ -253,7 +253,7 @@ lock_keys: {time:94.096168ms, region:6, keys:8, lock_rpc:274.503214ms, rpc_count - `region` : `lock_keys`操作の実行に関係する領域の数。 - `keys` : `Lock`必要な`Key`の数。 - `lock_rpc` ：タイプ`Lock`のRPCリクエストをTiKVに送信するのに費やされた合計時間。複数のRPCリクエストが並行して送信される可能性があるため、RPCの合計消費時間はタイプ`lock_keys`操作の合計消費時間よりも長くなる可能性があります。 -- `rpc_count` : TiKV に送信された`Lock`タイプの RPC 要求の合計数。 +- `rpc_count` : TiKV に送信された`Lock`タイプの RPC リクエストの合計数。 ### commit_txn実行情報 {#commit-txn-execution-information} diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index ba27bf0290c74..9a53725fe328f 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -102,7 +102,7 @@ ERROR 1066 (42000): Not unique table/alias: 't' ### テーブルロックの取得 {#table-lock-acquisition} -- TiDBでは、セッションAが既にテーブルロックを保持している場合、セッションBがそのテーブルに書き込みを試みるとエラーが返されます。MySQLでは、セッションBの書き込み要求はセッションAがテーブルロックを解放するまでブロックされ、他のセッションからのテーブルロック要求は現在のセッションが`WRITE`ロックを解放するまでブロックされます。 +- TiDBでは、セッションAが既にテーブルロックを保持している場合、セッションBがそのテーブルに書き込みを試みるとエラーが返されます。MySQLでは、セッションBの書き込みリクエストはセッションAがテーブルロックを解放するまでブロックされ、他のセッションからのテーブルロックリクエストは現在のセッションが`WRITE`ロックを解放するまでブロックされます。 - TiDBでは、 `LOCK TABLES`文に必要なロックが別のセッションによって保持されている場合、 `LOCK TABLES`の文は待機する必要があり、この文の実行時にエラーが返されます。MySQLでは、この文はロックが取得されるまでブロックされます。 - TiDBでは、 `LOCK TABLES`文はクラスタ全体で有効です。MySQLでは、この文は現在のMySQLサーバーでのみ有効であり、NDBクラスタとは互換性がありません。 diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 15172d73297ee..a9f978ccc4927 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -7,7 +7,7 @@ summary: TiDBデータベースにおけるスプリットリージョンの使 TiDBで新しいテーブルを作成するたびに、デフォルトで1つの[リージョン](/tidb-storage.md#region)が分割され、そのテーブルのデータが格納されます。このデフォルトの動作は、TiDB構成ファイルの`split-table`によって制御されます。このリージョン内のデータがデフォルトのリージョンサイズ制限を超えると、リージョンは2つに分割され始めます。 -上記の場合、初期状態ではリージョンが1つしかないため、すべての書き込み要求はリージョンが配置されているTiKV上で発生します。新しく作成されたテーブルへの書き込みが大量に発生すると、ホットスポットが発生します。 +上記の場合、初期状態ではリージョンが1つしかないため、すべての書き込みリクエストはリージョンが配置されているTiKV上で発生します。新しく作成されたテーブルへの書き込みが大量に発生すると、ホットスポットが発生します。 上記シナリオにおけるホットスポット問題を解決するために、TiDBは事前分割機能を導入しました。この機能は、指定されたパラメータに従って特定のテーブルに対して複数のリージョンを事前に分割し、それらを各TiKVノードに分散させることができます。 diff --git a/stale-read.md b/stale-read.md index b90130d7e9909..c1d1a7fee4b1e 100644 --- a/stale-read.md +++ b/stale-read.md @@ -13,15 +13,15 @@ summary: ステイル読み取りとその使用シナリオについて学習 -- シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 +- シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリリクエストを任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 -- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`を要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 +- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`をリクエストします。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 -トランザクションが読み取り操作のみで、ある程度のデータの古さを許容する場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、全体的なクエリ スループットが向上し、クエリのパフォーマンスが大幅に向上します。 +トランザクションが読み取り操作のみで、ある程度のデータの古さを許容する場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリリクエストを任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、全体的なクエリ スループットが向上し、クエリのパフォーマンスが大幅に向上します。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 883f2a5b1cd6c..d67c8361abab0 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -391,7 +391,7 @@ TiDBサーバーに関連するフィールド： TiKVコプロセッサータスクに関連するフィールド： -- `SUM_COP_TASK_NUM` : 送信されたコプロセッサー要求の総数。 +- `SUM_COP_TASK_NUM` : 送信されたコプロセッサーリクエストの総数。 - `MAX_COP_PROCESS_TIME` :コプロセッサータスクの最大実行時間。 - `MAX_COP_PROCESS_ADDRESS` : 実行時間が最大となるコプロセッサータスクのアドレス。 - `MAX_COP_WAIT_TIME` :コプロセッサータスクの最大待機時間。 diff --git a/system-variables.md b/system-variables.md index f8db2d9946100..926fe005ab80f 100644 --- a/system-variables.md +++ b/system-variables.md @@ -801,10 +801,10 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、アクティブ PDFollower機能を有効にするかどうかを制御します (現在はリージョン情報の要求にのみ適用されます)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報の要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるため、PD リーダーの CPU 負荷が軽減されます。 +- この変数は、アクティブ PDFollower機能を有効にするかどうかを制御します (現在はリージョン情報のリクエストにのみ適用されます)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報のリクエストをすべての PD サーバーに均等に分散し、PD フォロワーもリージョンリクエストを処理できるため、PD リーダーの CPU 負荷が軽減されます。 - アクティブPDFollowerを有効にするシナリオ： - リージョン数が多いクラスターでは、ハートビートの処理やタスクのスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなります。 - - TiDBインスタンスが多数存在するTiDBクラスタでは、リージョン情報に対する要求の同時発生率が高いため、PDリーダーに高いCPU負荷がかかります。 + - TiDBインスタンスが多数存在するTiDBクラスタでは、リージョン情報に対するリクエストの同時発生率が高いため、PDリーダーに高いCPU負荷がかかります。 ### performance_schema_session_connect_attrs_size New in v8.5.7 @@ -1050,7 +1050,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - デフォルト値: `4096` - 範囲: `[0, 9223372036854775807]` - 単位：バイト -- この変数は、 [`tidb_replica_read`](#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じアベイラビリティゾーン内のレプリカに送信することを優先するしきい値を制御するために使用されます。推定結果がこのしきい値以上の場合、TiDB は読み取り要求を同じアベイラビリティゾーン内のレプリカに送信することを優先します。それ以外の場合は、TiDB はリーダーレプリカに読み取り要求を送信します。 +- この変数は、 [`tidb_replica_read`](#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取りリクエストを TiDBサーバーと同じアベイラビリティゾーン内のレプリカに送信することを優先するしきい値を制御するために使用されます。推定結果がこのしきい値以上の場合、TiDB は読み取りリクエストを同じアベイラビリティゾーン内のレプリカに送信することを優先します。それ以外の場合は、TiDB はリーダーレプリカに読み取りリクエストを送信します。 ### tidb_advancer_check_point_lag_limit New in v8.5.5 @@ -1081,11 +1081,11 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 型: 整数 - デフォルト値: `1` - 範囲: `[0, 2]` -- この変数は、TiDBがTiFlashにコプロセッサ要求を送信する方法を制御するために使用されます。この変数には以下の値があります。 +- この変数は、TiDBがTiFlashにコプロセッサリクエストを送信する方法を制御するために使用されます。この変数には以下の値があります。 - `0` : リクエストをバッチで送信しません - `1` :集計および結合リクエストはバッチで送信されます - - `2` : すべてのコプロセッサ要求はバッチで送信されます + - `2` : すべてのコプロセッサリクエストはバッチで送信されます ### tidb_allow_fallback_to_tikv New in v5.0 @@ -1340,7 +1340,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 型: 整数 - デフォルト値: `10` - 範囲: `[1, 2147483647]` -- この変数は、読み取り要求がロックに遭遇したときの`backoff`時間を設定するために使用されます。 +- この変数は、読み取りリクエストがロックに遭遇したときの`backoff`時間を設定するために使用されます。 ### tidb_backoff_weight @@ -1350,7 +1350,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 型: 整数 - デフォルト値: `2` - 範囲: `[0, 2147483647]` -- この変数は、TiDB `backoff`の最大再試行待機時間の重みを増やすために使用されます。つまり、内部ネットワークまたは他のコンポーネント(TiKV、PD) の障害が発生した場合に再試行要求を送信する際の最大再試行待機時間です。この変数を使用して最大再試行待機時間を調整でき、最小値は`1`です。 +- この変数は、TiDB `backoff`の最大再試行待機時間の重みを増やすために使用されます。つまり、内部ネットワークまたは他のコンポーネント(TiKV、PD) の障害が発生した場合に再試行リクエストを送信する際の最大再試行待機時間です。この変数を使用して最大再試行待機時間を調整でき、最小値は`1`です。 例えば、TiDB が TiKV から KV を取得する際の基本再試行待機時間は 15 秒です。 `tidb_backoff_weight = 2`の場合、KV を取得する際の最大再試行待機時間は、*基本時間 * 2 = 30 秒*です。 @@ -2588,7 +2588,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `ON` -- この変数は、ページング方式を使用してコプロセッサ要求を送信するかどうかを制御します。TiDB バージョン (v5.4.0、v6.2.0) では、この変数は`IndexLookup`オペレーターにのみ有効です。v6.2.0 以降では、この変数はグローバルに有効です。v6.4.0 以降、この変数のデフォルト値は`OFF`から`ON`に変更されました。 +- この変数は、ページング方式を使用してコプロセッサリクエストを送信するかどうかを制御します。TiDB バージョン (v5.4.0、v6.2.0) では、この変数は`IndexLookup`オペレーターにのみ有効です。v6.2.0 以降では、この変数はグローバルに有効です。v6.4.0 以降、この変数のデフォルト値は`OFF`から`ON`に変更されました。 - ユーザーシナリオ： - すべてのOLTPシナリオにおいて、ページング方式を使用することが推奨されます。 @@ -2784,7 +2784,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 値のオプション: `OFF` 、 `ON` -- この変数は、TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。値が`ON` `OFF`の場合、TiDB はシステムから直接チャンク オブジェクトを要求します。 +- この変数は、TiDB がチャンク オブジェクトのキャッシュを有効にするかどうかを制御します。値が`ON` `OFF`の場合、TiDB はシステムから直接チャンク オブジェクトをリクエストします。 ### tidb_enable_shared_lock_promotion New in v8.3.0 @@ -2972,7 +2972,7 @@ Query OK, 0 rows affected (0.09 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、TSOFollowerプロキシ機能を有効にするかどうかを制御します。値が`OFF`の場合、TiDBはPDリーダーからのみTSOを取得します。値が`ON`の場合、TiDBはTSO要求をすべてのPDサーバーに均等に分散し、PDフォロワーもTSO要求を処理できるため、PDリーダーのCPU負荷が軽減されます。 +- この変数は、TSOFollowerプロキシ機能を有効にするかどうかを制御します。値が`OFF`の場合、TiDBはPDリーダーからのみTSOを取得します。値が`ON`の場合、TiDBはTSOリクエストをすべてのPDサーバーに均等に分散し、PDフォロワーもTSOリクエストを処理できるため、PDリーダーのCPU負荷が軽減されます。 - TSOFollowerプロキシを有効にするシナリオ： - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大します。 - TiDBクラスタには多数のTiDBインスタンスが存在するため、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)の値を増やしても、TSO RPCリクエストの高レイテンシーの問題は解消されません。 @@ -3430,7 +3430,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、非同期コミットにおけるコミットTSの計算方法を制御します。デフォルトでは（ `ON`値の場合）、2フェーズコミットはPDサーバーから新しいTSを要求し、そのTSを使用して最終的なコミットTSを計算します。この場合、すべての同時実行トランザクションに対して線形化可能性が保証されます。 +- この変数は、非同期コミットにおけるコミットTSの計算方法を制御します。デフォルトでは（ `ON`値の場合）、2フェーズコミットはPDサーバーから新しいTSをリクエストし、そのTSを使用して最終的なコミットTSを計算します。この場合、すべての同時実行トランザクションに対して線形化可能性が保証されます。 - この変数を`OFF`に設定すると、PDサーバーから TS を取得するプロセスがスキップされますが、その代償として、因果関係の一貫性のみが保証されますが、線形化可能性は保証されません。詳細については、ブログ投稿[TiDB 5.0 のトランザクションコミットを加速する非同期コミット](https://www.pingcap.com/blog/async-commit-the-accelerator-for-transaction-commit-in-tidb-5-0/)を参照してください。 - 因果関係の一貫性のみが必要なシナリオでは、この変数を`OFF`に設定することでパフォーマンスを向上させることができます。 @@ -3576,7 +3576,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `0` - 範囲: `[0, 18446744073709551615]` - この変数は、インデックス結合の選択にペナルティコストを適用するかどうかを決定します。ペナルティコストを適用すると、オプティマイザがインデックス結合を選択する可能性が低くなり、ハッシュ結合やTiFlash結合などの代替結合方法を選択する可能性が高くなります。 -- インデックス結合を選択すると、多数のテーブル検索要求が発生し、リソースを過剰に消費します。この変数を使用することで、オプティマイザがインデックス結合を選択する可能性を低減できます。 +- インデックス結合を選択すると、多数のテーブル検索リクエストが発生し、リソースを過剰に消費します。この変数を使用することで、オプティマイザがインデックス結合を選択する可能性を低減できます。 - この変数は、 [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数が`2`に設定されている場合にのみ有効になります。 ### tidb_index_lookup_concurrency @@ -3990,7 +3990,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `50000` - 範囲: `[1, 9223372036854775807]` - 単位：行 -- この変数は、コプロセッサのページング要求処理中に処理する最大行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC回数が増加します。一方、値を大きく設定しすぎると、データのロードやフルテーブルスキャンなど、場合によってはメモリ使用量が過剰になります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 +- この変数は、コプロセッサのページングリクエスト処理中に処理する最大行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC回数が増加します。一方、値を大きく設定しすぎると、データのロードやフルテーブルスキャンなど、場合によってはメモリ使用量が過剰になります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 ### tidb_max_tiflash_threads New in v6.1.0 @@ -4230,7 +4230,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `128` - 範囲: `[1, 9223372036854775807]` - 単位：行 -- この変数は、コプロセッサのページング要求処理中に最小行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC要求数が増加します。一方、値を大きく設定しすぎると、Limitを使用したIndexLookupクエリの実行時にパフォーマンスが低下する可能性があります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 +- この変数は、コプロセッサのページングリクエスト処理中に最小行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPCリクエスト数が増加します。一方、値を大きく設定しすぎると、Limitを使用したIndexLookupクエリの実行時にパフォーマンスが低下する可能性があります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 ![Paging size impact on TPCH](/media/paging-size-impact-on-tpch.png) @@ -5152,7 +5152,7 @@ SHOW WARNINGS; - 型: Float - 範囲: `[0, 2147483647]` - デフォルト値: `20` -- TiDBがTiKVからデータを要求する際の起動コストを示します。この変数は[コストモデル](/cost-model.md)によって内部的に使用されるため、値を変更することは推奨され**ません**。 +- TiDBがTiKVからデータをリクエストする際の起動コストを示します。この変数は[コストモデル](/cost-model.md)によって内部的に使用されるため、値を変更することは推奨され**ません**。 ### tidb_opt_skew_distinct_agg New in v6.2.0 @@ -6515,7 +6515,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `0` - 範囲: `[0, 10]` - 単位：ミリ秒 -- この変数は、TiDBがPDからTSOを要求する際のバッチ操作の最大待機時間を設定するために使用されます。デフォルト値は`0`で、これは追加の待機時間がないことを意味します。 +- この変数は、TiDBがPDからTSOをリクエストする際のバッチ操作の最大待機時間を設定するために使用されます。デフォルト値は`0`で、これは追加の待機時間がないことを意味します。 - TiDBで使用されるPDクライアントは、PDからTSOリクエストを取得する際、同時に受信したTSOリクエストを可能な限り多く収集します。そして、収集したリクエストをバッチ処理で1つのRPCリクエストに統合し、PDに送信します。これにより、PDへの負荷を軽減できます。 - この変数を`0`より大きい値に設定した後、TiDBは各バッチマージの終了前に、この値の最大期間待機します。これは、より多くのTSOリクエストを収集し、バッチ操作の効果を向上させるためです。 - この変数の値を増加させるシナリオ： @@ -6724,7 +6724,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) -- この変数は、TiDB が TiKV に送信するトランザクションコミット要求のバッチサイズを制御するために使用されます。アプリケーションワークロード内のトランザクションの大部分に多数の書き込み操作が含まれている場合、この変数の値を大きくすることでバッチ処理のパフォーマンスを向上させることができます。ただし、この変数を大きすぎる値に設定して TiKV の[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)の制限を超えると、コミットが失敗する可能性があります。 +- この変数は、TiDB が TiKV に送信するトランザクションコミットリクエストのバッチサイズを制御するために使用されます。アプリケーションワークロード内のトランザクションの大部分に多数の書き込み操作が含まれている場合、この変数の値を大きくすることでバッチ処理のパフォーマンスを向上させることができます。ただし、この変数を大きすぎる値に設定して TiKV の[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)の制限を超えると、コミットが失敗する可能性があります。 diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index 952d41fb69b1e..0270ca06bbc55 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -31,45 +31,45 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro TiCDC の新しいアーキテクチャの監視ダッシュボードには、主に次のセクションが含まれます。 -- [**まとめ**](#summary) : TiCDCクラスターの概要情報 -- [**サーバ**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**Summary**](#summary) : TiCDCクラスターの概要情報 +- [**Server**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 - [**Log Puller**](#log-puller) : TiCDC Log Pullerモジュールの詳細情報 -- [**イベントストア**](#event-store) : TiCDCイベントストアモジュールの詳細情報 -- [**シンク**](#sink) : TiCDCシンクモジュールの詳細情報 +- [**Event Store**](#event-store) : TiCDCイベントストアモジュールの詳細情報 +- [**Sink**](#sink) : TiCDCシンクモジュールの詳細情報 -### まとめ {#summary} +### Summary {#summary} -以下は**概要**パネルの例です。 +以下は**Summary**パネルの例です。 ![Summary](/media/ticdc/ticdc-new-arch-metric-summary.png) -**概要**パネルの各メトリックの説明は次のとおりです。 +**Summary**パネルの各メトリックの説明は次のとおりです。 -- チェンジフィードチェックポイントラグ: 下流と上流の間のレプリケーションタスクのラグ +- Changefeed Checkpoint Lag: 下流と上流の間のレプリケーションタスクのラグ - Changefeed ResolvedTs Lag: TiCDCノードの内部処理の進行と上流データベース間の遅延 -- アップストリーム書き込みバイト/秒:アップストリームデータベースの書き込みスループット -- TiCDC入力バイト/秒: TiCDCがアップストリームから1秒あたりに受信するデータ量 -- シンクイベント行数/秒: TiCDCが1秒あたりにダウンストリームに書き込む行数 -- シンク書き込みバイト/秒: TiCDCが1秒あたりにダウンストリームに書き込むデータの量 -- チェンジフィードのステータス: 各チェンジフィードのステータス -- テーブルディスパッチャ数: 各チェンジフィードに対応するディスパッチャの数 -- メモリクォータ: イベントコレクタのメモリクォータと使用量。使用量が多すぎるとスロットリングが発生する可能性があります。 +- Upstream Write Bytes/s:アップストリームデータベースの書き込みスループット +- TiCDC Input Bytes/s: TiCDCがアップストリームから1秒あたりに受信するデータ量 +- Sink Event Row Count/s: TiCDCが1秒あたりにダウンストリームに書き込む行数 +- Sink Write Bytes/s: TiCDCが1秒あたりにダウンストリームに書き込むデータの量 +- The Status of Changefeeds: 各チェンジフィードのステータス +- Table Dispatcher Count: 各チェンジフィードに対応するディスパッチャの数 +- Memory Quota: イベントコレクタのメモリクォータと使用量。使用量が多すぎるとスロットリングが発生する可能性があります。 -### サーバ {#server} +### Server {#server} -以下は**サーバー**パネルの例です。 +以下は**Server**パネルの例です。 ![Server](/media/ticdc/ticdc-new-arch-metric-server.png) -**サーバー**パネルの各メトリックの説明は次のとおりです。 +**Server**パネルの各メトリックの説明は次のとおりです。 -- 稼働時間: TiKVノードとTiCDCノードが稼働している時間 -- Goroutine 数: TiCDC ノード上の Goroutine の数 -- オープンFD数: TiCDCノードによって開かれたファイルハンドルの数 -- CPU使用率: TiCDCノードのCPU使用率 -- メモリ使用量: TiCDCノードのメモリ使用量 -- 所有権履歴: TiCDC クラスター内の所有者ノードの履歴記録 -- PD Leader履歴:上流TiDBクラスタ内のPD Leaderノードの履歴記録 +- Uptime: TiKVノードとTiCDCノードが稼働している時間 +- Goroutine Count: TiCDC ノード上の Goroutine の数 +- Open FD Count: TiCDCノードによって開かれたファイルハンドルの数 +- CPU Usage: TiCDCノードのCPU使用率 +- Memory Usage: TiCDCノードのメモリ使用量 +- Ownership History: TiCDC クラスター内の所有者ノードの履歴記録 +- PD Leader History:上流TiDBクラスタ内のPD Leaderノードの履歴記録 ### Log Puller {#log-puller} @@ -79,51 +79,51 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 **Log Puller**パネルの各メトリックの説明は次のとおりです。 -- 入力イベント数/秒: TiCDCが1秒あたりに受信するイベント数 -- 未解決のリージョン要求数: TiCDC が送信したがまだ完了していないリージョン増分スキャン要求の数 -- リージョン要求終了スキャン所要時間:リージョン増分スキャンにかかる時間 -- 登録済みリージョン数: 登録済みリージョンの総数 -- メモリクォータ: Log Puller のメモリクォータと使用量。過剰な使用はスロットリングを引き起こす可能性があります。 -- 解決済みTsバッチサイズ（リージョン）: 1つの解決済みTsイベントに含まれるリージョンの数 +- Input Events/s: TiCDCが1秒あたりに受信するイベント数 +- Unresolved Region Request Count: TiCDC が送信したがまだ完了していないリージョン増分スキャンリクエストの数 +- Region Request Finish Scan Duration:リージョン増分スキャンにかかる時間 +- Subscribed Region Count: 登録済みリージョンの総数 +- Memory Quota: Log Puller のメモリクォータと使用量。過剰な使用はスロットリングを引き起こす可能性があります。 +- Resolved Ts Batch Size (Regions): 1つの解決済みTsイベントに含まれるリージョンの数 -### イベントストア {#event-store} +### Event Store {#event-store} -以下は、**イベントストア**パネルの例です。 +以下は、**Event Store**パネルの例です。 ![Event Store](/media/ticdc/ticdc-new-arch-metric-event-store.png) -**イベントストア**パネルの各メトリックの説明は次のとおりです。 - -- 解決されたTsラグ: イベントストアの処理の進行と上流データベース間のラグ -- レジスタディスパッチャStartTsラグ:ディスパッチャ登録StartTsと現在の時刻のラグ -- サブスクリプション解決Tsラグ: サブスクリプション処理の進行と上流データベース間のラグ -- サブスクリプションデータGCラグ: サブスクリプションデータGCの進行状況と現在の時刻の間のラグ -- 入力イベント数/秒: イベントストアが1秒あたりに処理するイベントの数 -- 入力バイト/秒: イベントストアが1秒あたりに処理するデータ量 -- 書き込みリクエスト数/秒: イベントストアが1秒あたりに実行する書き込みリクエストの数 -- 書き込みワーカービジー率: イベントストア書き込みスレッドの合計実行時間に対するI/O時間の比率 -- 圧縮行数/秒: イベントストアで 1秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) -- 書き込み時間: イベントストアの書き込み操作にかかる時間 -- 書き込みバッチサイズ: 1回の書き込み操作のバッチサイズ -- 書き込みバッチイベント数: 1回の書き込みバッチに含まれる行変更イベントの数 -- ディスク上のデータサイズ: イベントストアがディスク上で占める合計データサイズ -- メモリ内のデータサイズ: イベントストアがメモリ内で占める合計データサイズ -- スキャン要求数/秒: イベントストアが1秒あたりに実行するスキャン要求の数 -- スキャンバイト数/秒: イベントストアが1秒あたりにスキャンするデータの量 - -### シンク {#sink} - -以下は**シンク**パネルの例です。 +**Event Store**パネルの各メトリックの説明は次のとおりです。 + +- Resolved Ts Lag: イベントストアの処理の進行と上流データベース間のラグ +- Register Dispatcher StartTs Lag:ディスパッチャ登録StartTsと現在の時刻のラグ +- Subscriptions Resolved Ts Lag: サブスクリプション処理の進行と上流データベース間のラグ +- Subscriptions Data GC Lag: サブスクリプションデータGCの進行状況と現在の時刻の間のラグ +- Input Event Count/s: イベントストアが1秒あたりに処理するイベントの数 +- Input Bytes/s: イベントストアが1秒あたりに処理するデータ量 +- Write Requests/s: イベントストアが1秒あたりに実行する書き込みリクエストの数 +- Write Worker Busy Ratio: イベントストア書き込みスレッドの合計実行時間に対するI/O時間の比率 +- Compressed Rows/s: イベントストアで 1秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) +- Write Duration: イベントストアの書き込み操作にかかる時間 +- Write Batch Size: 1回の書き込み操作のバッチサイズ +- Write Batch Event Count: 1回の書き込みバッチに含まれる行変更イベントの数 +- Data Size On Disk: イベントストアがディスク上で占める合計データサイズ +- Data Size In Memory: イベントストアがメモリ内で占める合計データサイズ +- Scan Requests/s: イベントストアが1秒あたりに実行するスキャンリクエストの数 +- Scan Bytes/s: イベントストアが1秒あたりにスキャンするデータの量 + +### Sink {#sink} + +以下は**Sink**パネルの例です。 ![Sink](/media/ticdc/ticdc-new-arch-metric-sink.png) -**シンク**パネルの各メトリックの説明は次のとおりです。 +**Sink**パネルの各メトリックの説明は次のとおりです。 -- 出力行バッチ数: シンクモジュールによって書き込まれたDMLバッチあたりの平均行数 -- 出力行数（1秒あたり）: 1秒あたりに下流に書き込まれるDML行数 -- 出力DDL実行時間: 現在のノードの変更フィードのDDLイベントの実行に費やされた時間 -- シンクエラー数 / 分: シンクモジュールによって1分あたりに報告されたエラーの数 -- 出力DDL数/分: 現在のノードの変更フィードに対して1分あたりに実行されたDDLの数 +- Output Row Batch Count: シンクモジュールによって書き込まれたDMLバッチあたりの平均行数 +- Output Row Count (per second): 1秒あたりに下流に書き込まれるDML行数 +- Output DDL Executing Duration: 現在のノードの変更フィードのDDLイベントの実行に費やされた時間 +- Sink Error Count / m: シンクモジュールによって1分あたりに報告されたエラーの数 +- Output DDL Count / Minutes: 現在のノードの変更フィードに対して1分あたりに実行されたDDLの数 ## クラシックアーキテクチャにおける TiCDC のメトリクス {#metrics-for-ticdc-in-the-classic-architecture} @@ -131,86 +131,86 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 各パネルの説明は次のとおりです。 -- [**サーバ**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 -- [**チェンジフィード**](#changefeed) : TiCDCレプリケーションタスクの詳細情報 -- [**イベント**](#events) : TiCDCクラスタ内のデータフローに関する詳細情報 +- [**Server**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**Changefeed**](#changefeed) : TiCDCレプリケーションタスクの詳細情報 +- [**Events**](#events) : TiCDCクラスタ内のデータフローに関する詳細情報 - [**TiKV**](#tikv) : TiCDCに関連するTiKV情報 -### サーバ {#server} +### Server {#server} -以下は**サーバー**パネルの例です。 +以下は**Server**パネルの例です。 ![TiCDC Dashboard - Server metrics](/media/ticdc/ticdc-dashboard-server.png) -**サーバー**パネルの各メトリックの説明は次のとおりです。 +**Server**パネルの各メトリックの説明は次のとおりです。 -- 稼働時間: TiKVノードとTiCDCノードが稼働している時間 -- ゴルーチン数: TiCDCノードのゴルーチンの数 -- オープンFD数: TiCDCノードによって開かれたファイルハンドルの数 -- 所有権: TiCDC クラスター内のノードの現在のステータス -- 所有権の履歴: TiCDCクラスターの所有権の履歴 -- CPU使用率: TiCDCノードのCPU使用率 -- メモリ使用量: TiCDCノードのメモリ使用量 +- Uptime: TiKVノードとTiCDCノードが稼働している時間 +- Goroutine count: TiCDCノードのゴルーチンの数 +- Open FD count: TiCDCノードによって開かれたファイルハンドルの数 +- Ownership: TiCDC クラスター内のノードの現在のステータス +- Ownership history: TiCDCクラスターの所有権の履歴 +- CPU usage: TiCDCノードのCPU使用率 +- Memory usage: TiCDCノードのメモリ使用量 -### チェンジフィード {#changefeed} +### Changefeed {#changefeed} 以下は**Changefeed**パネルの例です。 ![TiCDC Dashboard - Changefeed metrics 1](/media/ticdc/ticdc-dashboard-changefeed-1.png) -- チェンジフィードテーブル数: 各 TiCDC ノードがレプリケーションタスクで複製する必要があるテーブルの数 -- プロセッサ解決ts: TiCDCクラスタで解決されたタイムスタンプ -- テーブル解決ts: レプリケーションタスク内の各テーブルのレプリケーションの進行状況 -- チェンジフィードチェックポイント：下流へのデータ複製の進行状況。通常、緑色のバーは黄色の線とつながっています。 -- PD etcdリクエスト数/秒: TiCDCノードがPDに送信するリクエスト数（1秒あたり） -- 終了エラー数/分: 1分あたりにレプリケーションタスクを中断するエラーの数 -- チェンジフィードチェックポイントラグ:上流と下流間のデータ複製の進行ラグ(単位は秒) -- プロセッサ解決tsラグ:上流ノードとTiCDCノード間のデータ複製の進行ラグ（単位は秒） +- Changefeed table count: 各 TiCDC ノードがレプリケーションタスクで複製する必要があるテーブルの数 +- Processor resolved ts: TiCDCクラスタで解決されたタイムスタンプ +- Table resolved ts: レプリケーションタスク内の各テーブルのレプリケーションの進行状況 +- Changefeed checkpoint：下流へのデータ複製の進行状況。通常、緑色のバーは黄色の線とつながっています。 +- PD etcd requests/s: TiCDCノードがPDに送信するリクエスト数（1秒あたり） +- Exit error count/m: 1分あたりにレプリケーションタスクを中断するエラーの数 +- Changefeed checkpoint lag:上流と下流間のデータ複製の進行ラグ(単位は秒) +- Processor resolved ts lag:上流ノードとTiCDCノード間のデータ複製の進行ラグ（単位は秒） ![TiCDC Dashboard - Changefeed metrics 2](/media/ticdc/ticdc-dashboard-changefeed-2.png) -- シンク書き込み時間: TiCDCがトランザクションの変更をダウンストリームに書き込むのに費やした時間のヒストグラム -- シンク書き込み期間パーセンタイル: TiCDC が 1秒以内にトランザクションの変更をダウンストリームに書き込むのに費やした時間 (P95、P99、および P999) -- フラッシュシンク期間: TiCDC が非同期的にデータを下流にフラッシュするのにかかった時間のヒストグラム -- フラッシュシンク期間パーセンタイル: TiCDC が 1秒以内にデータを非同期にダウンストリームにフラッシュするのにかかる時間 (P95、P99、および P999) +- Sink write duration: TiCDCがトランザクションの変更をダウンストリームに書き込むのに費やした時間のヒストグラム +- Sink write duration percentile: TiCDC が 1秒以内にトランザクションの変更をダウンストリームに書き込むのに費やした時間 (P95、P99、および P999) +- Flush sink duration: TiCDC が非同期的にデータを下流にフラッシュするのにかかった時間のヒストグラム +- Flush sink duration percentile: TiCDC が 1秒以内にデータを非同期にダウンストリームにフラッシュするのにかかる時間 (P95、P99、および P999) ![TiCDC Dashboard - Changefeed metrics 3](/media/ticdc/ticdc-dashboard-changefeed-3.png) -- MySQLシンク競合検出期間: MySQLシンク競合の検出に費やされた時間のヒストグラム -- MySQLシンク競合検出期間パーセンタイル: 1秒以内にMySQLシンク競合を検出するのに費やされた時間(P95、P99、P999) -- MySQLシンクワーカーの負荷: TiCDCノードのMySQLシンクワーカーのワークロード +- MySQL sink conflict detect duration: MySQLシンク競合の検出に費やされた時間のヒストグラム +- MySQL sink conflict detect duration percentile: 1秒以内にMySQLシンク競合を検出するのに費やされた時間(P95、P99、P999) +- MySQL sink worker load: TiCDCノードのMySQLシンクワーカーのワークロード ![TiCDC Dashboard - Changefeed metrics 4](/media/ticdc/ticdc-dashboard-changefeed-4.png) -- Changefeed キャッチアップ ETA: レプリケーションタスクが上流のクラスタデータに追いつくのに必要な推定時間です。上流の書き込み速度が TiCDC のレプリケーション速度よりも速い場合、この指標は非常に大きくなる可能性があります。TiCDC のレプリケーション速度は多くの要因に左右されるため、この指標は参考値であり、実際のレプリケーション時間とは異なる可能性があります。 +- Changefeed catch-up ETA: レプリケーションタスクが上流のクラスタデータに追いつくのに必要な推定時間です。上流の書き込み速度が TiCDC のレプリケーション速度よりも速い場合、この指標は非常に大きくなる可能性があります。TiCDC のレプリケーション速度は多くの要因に左右されるため、この指標は参考値であり、実際のレプリケーション時間とは異なる可能性があります。 -### イベント {#events} +### Events {#events} -以下は**イベント**パネルの例です。 +以下は**Events**パネルの例です。 ![TiCDC Dashboard - Events metrics 2](/media/ticdc/ticdc-dashboard-events-1.png) ![TiCDC Dashboard - Events metrics 2](/media/ticdc/ticdc-dashboard-events-2.png) ![TiCDC Dashboard - Events metrics 2](/media/ticdc/ticdc-dashboard-events-3.png) -**イベント**パネルの各メトリックの説明は次のとおりです。 - -- イベントフィード数: TiCDCノードのイベントフィードRPCリクエストの数 -- イベントサイズのパーセンタイル: TiCDCがTiKVから1秒以内に受信するイベントサイズ（P95、P99、P999） -- イベントフィードエラー/分: TiCDCノードのイベントフィードRPCリクエストによって1分あたりに報告されたエラーの数 -- KVクライアント受信イベント数/秒: TiCDCノードのKVクライアントモジュールがTiKVから1秒あたりに受信するイベント数 -- プラー受信イベント数/秒: TiCDCノードのプラーモジュールがKVクライアントから1秒あたりに受信するイベント数 -- プラー出力イベント数/秒: TiCDCノードのプラーモジュールがソーターモジュールに送信するイベント数/秒 -- シンクフラッシュ行数/秒: TiCDCノードが1秒あたりにダウンストリームに書き込むイベント数 -- プラーバッファサイズ: TiCDCノードがプラーモジュールにキャッシュするイベントの数 -- エントリソーターバッファサイズ: TiCDCノードがソーターモジュールにキャッシュするイベントの数 -- プロセッサ/マウントバッファサイズ: TiCDCノードがプロセッサモジュールとマウントモジュールにキャッシュするイベントの数 -- シンク行バッファサイズ: TiCDCノードがシンクモジュールにキャッシュするイベントの数 -- エントリソーターのソート期間: TiCDCノードがイベントをソートするのにかかった時間のヒストグラム -- エントリーソーターのソート所要時間パーセンタイル: TiCDCのソートイベントが1秒間に要した時間(P95、P99、P999) -- エントリソーターのマージ期間: TiCDCノードがソートされたイベントをマージするのにかかった時間のヒストグラム -- エントリソーターのマージ所要時間パーセンタイル: TiCDCがソートされたイベントを1秒以内にマージするのにかかる時間(P95、P99、P999) -- マウンターのアンマーシャリング期間: TiCDCノードがイベントをアンマーシャリングするのにかかった時間のヒストグラム -- マウンターのアンマーシャリング期間のパーセンタイル: TiCDC アンマーシャリング イベントが 1秒間に要した時間 (P95、P99、および P999) -- KVクライアントディスパッチイベント数/秒: KVクライアントモジュールがTiCDCノード間でディスパッチするイベント数 -- KVクライアントのバッチ解決サイズ: TiKVがTiCDCに送信する解決済みタイムスタンプメッセージのバッチサイズ +**Events**パネルの各メトリックの説明は次のとおりです。 + +- Eventfeed count: TiCDCノードのイベントフィードRPCリクエストの数 +- Event size percentile: TiCDCがTiKVから1秒以内に受信するイベントサイズ（P95、P99、P999） +- Eventfeed error/m: TiCDCノードのイベントフィードRPCリクエストによって1分あたりに報告されたエラーの数 +- KV client receive events/s: TiCDCノードのKVクライアントモジュールがTiKVから1秒あたりに受信するイベント数 +- Puller receive events/s: TiCDCノードのプラーモジュールがKVクライアントから1秒あたりに受信するイベント数 +- Puller output events/s: TiCDCノードのプラーモジュールがソーターモジュールに送信するイベント数/秒 +- Sink flush rows/s: TiCDCノードが1秒あたりにダウンストリームに書き込むイベント数 +- Puller buffer size: TiCDCノードがプラーモジュールにキャッシュするイベントの数 +- Entry sorter buffer size: TiCDCノードがソーターモジュールにキャッシュするイベントの数 +- Processor/Mounter buffer size: TiCDCノードがプロセッサモジュールとマウントモジュールにキャッシュするイベントの数 +- Sink row buffer size: TiCDCノードがシンクモジュールにキャッシュするイベントの数 +- Entry sorter sort duration: TiCDCノードがイベントをソートするのにかかった時間のヒストグラム +- Entry sorter sort duration percentile: TiCDCのソートイベントが1秒間に要した時間(P95、P99、P999) +- Entry sorter merge duration: TiCDCノードがソートされたイベントをマージするのにかかった時間のヒストグラム +- Entry sorter merge duration percentile: TiCDCがソートされたイベントを1秒以内にマージするのにかかる時間(P95、P99、P999) +- Mounter unmarshal duration: TiCDCノードがイベントをアンマーシャリングするのにかかった時間のヒストグラム +- Mounter unmarshal duration percentile: TiCDC アンマーシャリング イベントが 1秒間に要した時間 (P95、P99、および P999) +- KV client dispatch events/s: KVクライアントモジュールがTiCDCノード間でディスパッチするイベント数 +- KV client batch resolved size: TiKVがTiCDCに送信する解決済みタイムスタンプメッセージのバッチサイズ ### TiKV {#tikv} @@ -220,13 +220,13 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 **TiKV**パネルの各メトリックの説明は次のとおりです。 -- CDCエンドポイントCPU: TiKVノード上のCDCエンドポイントスレッドのCPU使用率 -- CDCワーカーCPU: TiKVノード上のCDCワーカースレッドのCPU使用率 -- 最小解決タイムスタンプ: TiKVノード上の最小解決タイムスタンプ -- 最小解決リージョン: TiKVノード上の最小解決タイムスタンプのリージョンID -- 解決されたTSラグ期間パーセンタイル: TiKVノード上の最小解決タイムスタンプと現在の時刻の間のラグ -- 初期スキャン期間: TiKVノードがTiCDCノードに接続する際の増分スキャンに費やされた時間のヒストグラム -- 初期スキャン所要時間パーセンタイル: 1秒以内にTiKVノードの増分スキャンに費やされた時間(P95、P99、P999) -- ブロックキャッシュなしのメモリ: RocksDBブロックキャッシュを除いたTiKVノードのメモリ使用量 -- メモリ内のCDC保留バイト数: TiKVノード上のCDCモジュールのメモリ使用量 -- キャプチャされたリージョンの数: TiKVノード上のイベントキャプチャリージョンの数 +- CDC endpoint CPU: TiKVノード上のCDCエンドポイントスレッドのCPU使用率 +- CDC worker CPU: TiKVノード上のCDCワーカースレッドのCPU使用率 +- Min resolved ts: TiKVノード上の最小解決タイムスタンプ +- Min resolved region: TiKVノード上の最小解決タイムスタンプのリージョンID +- Resolved ts lag duration percentile: TiKVノード上の最小解決タイムスタンプと現在の時刻の間のラグ +- Initial scan duration: TiKVノードがTiCDCノードに接続する際の増分スキャンに費やされた時間のヒストグラム +- Initial scan duration percentile: 1秒以内にTiKVノードの増分スキャンに費やされた時間(P95、P99、P999) +- Memory without block cache: RocksDBブロックキャッシュを除いたTiKVノードのメモリ使用量 +- CDC pending bytes in memory: TiKVノード上のCDCモジュールのメモリ使用量 +- Captured region count: TiKVノード上のイベントキャプチャリージョンの数 diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 050ae90c0cc4e..06026ceeb58c0 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -20,7 +20,7 @@ summary: TiCDCの新しいアーキテクチャの機能、アーキテクチャ TiCDCの新しいアーキテクチャは、ログサービスとダウンストリームアダプタという2つの主要コンポーネントで構成されています。 -- ログサービス：コアデータサービスレイヤーとして、ログサービスはアップストリームのTiDBクラスタから行の変更やDDLイベントなどの情報を取得し、変更データをローカルディスクに一時的に保存します。また、ダウンストリームアダプタからのデータ要求にも応答し、DMLデータとDDLデータを定期的にマージおよびソートして、ソート済みのデータをダウンストリームアダプタに送信します。 +- ログサービス：コアデータサービスレイヤーとして、ログサービスはアップストリームのTiDBクラスタから行の変更やDDLイベントなどの情報を取得し、変更データをローカルディスクに一時的に保存します。また、ダウンストリームアダプタからのデータリクエストにも応答し、DMLデータとDDLデータを定期的にマージおよびソートして、ソート済みのデータをダウンストリームアダプタに送信します。 - ダウンストリームアダプタ：ダウンストリームデータレプリケーション適応レイヤーとして、ダウンストリームアダプタはユーザーが開始する変更フィード操作を処理します。関連するレプリケーションタスクをスケジュールおよび生成し、ログサービスからデータを取得し、取得したデータをダウンストリームシステムにレプリケートします。 TiCDCの新しいアーキテクチャは、アーキテクチャをステートフルコンポーネントとステートレスコンポーネントに分離することで、システムの拡張性、信頼性、柔軟性を大幅に向上させています。ステートフルコンポーネントであるログサービスは、データの取得、ソート、およびストレージに重点を置いています。これを変更フィード処理ロジックから分離することで、複数の変更フィード間でデータを共有できるようになり、リソース利用率を効果的に向上させ、システムオーバーヘッドを削減できます。ステートレスコンポーネントであるダウンストリームアダプタは、インスタンス間でレプリケーションタスクを迅速に移行できる軽量スケジューリングメカニズムを使用しています。ワークロードの変化に基づいてレプリケーションタスクの分割とマージを動的に調整できるため、さまざまなシナリオで低遅延のレプリケーションが保証されます。 diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index e41ce43a7776d..bcc8e41950fe0 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -13,7 +13,7 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい ## TiCDC でタスクを作成するときに`start-ts`を選択するにはどうすればよいですか? {#how-do-i-choose-start-ts-when-creating-a-task-in-ticdc} -レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 +レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータをリクエストします。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 - `start-ts`という値は、現在の TiDB クラスターの`tikv_gc_safe_point`という値よりも大きいです。それ以外の場合、タスクの作成時にエラーが発生します。 - タスクを開始する前に、ダウンストリームにすべてのデータが`start-ts`あることを確認してください。メッセージキューにデータを複製するなどのシナリオでは、アップストリームとダウンストリーム間のデータの整合性が要求されない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 84f74cc8a6a9d..0bf6d2ab23049 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -68,7 +68,7 @@ TiCDCのアーキテクチャを次の図に示します。 アーキテクチャ図における各構成要素は、以下のように説明されます。 -- TiKVサーバー：TiDBクラスタ内のTiKVノード。データに変更が発生すると、TiKVノードは変更ログ（KV変更ログ）として変更内容をTiCDCノードに送信します。TiCDCノードは、変更ログが連続していないことを検出した場合、TiKVノードに変更ログの提供を積極的に要求します。 +- TiKVサーバー：TiDBクラスタ内のTiKVノード。データに変更が発生すると、TiKVノードは変更ログ（KV変更ログ）として変更内容をTiCDCノードに送信します。TiCDCノードは、変更ログが連続していないことを検出した場合、TiKVノードに変更ログの提供を積極的にリクエストします。 - TiCDC: TiCDCプロセスが実行されるTiCDCノード。各ノードではTiCDCプロセスが実行されます。各プロセスは、TiKVノード内の1つ以上のテーブルからデータ変更を取得し、シンクコンポーネントを介して下流システムにその変更を複製します。 - PD：TiDBクラスタのスケジューリングモジュール。このモジュールはクラスタデータのスケジューリングを担当し、通常は3つのPDノードで構成されます。PDはetcdクラスタを介して高可用性を提供します。etcdクラスタでは、TiCDCはノードの状態情報や変更フィードの設定などのメタデータを保存します。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index 330ff6256688c..07823e40ef4b1 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -102,7 +102,7 @@ summary: TiCDC で使用される CLI と設定パラメータについて学習 #### `client-allowed-user` {#client-allowed-user} -- クライアント認証に許可されるユーザー名をリストします。このリストにないユーザー名による認証要求は拒否されます。 +- クライアント認証に許可されるユーザー名をリストします。このリストにないユーザー名による認証リクエストは拒否されます。 - デフォルト値: `null` diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index d4e6dda709589..22fca46fad0a5 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -414,7 +414,7 @@ large-message-handle-compression = "none" - `large-message-handle-compression`で指定された圧縮アルゴリズムは、単一のKafkaメッセージを圧縮します。圧縮は、メッセージサイズの制限と比較する前に実行されます。 - 同時に、 [`sink-uri`](#configure-sink-uri-for-kafka)の`compression`パラメータを使用して圧縮アルゴリズムを設定することもできます。この圧縮アルゴリズムは、複数のKafkaメッセージを含むデータ送信リクエスト全体に適用されます。 -`large-message-handle-compression`を設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 +`large-message-handle-compression`を設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データリクエスト全体をシンクレベルで再度圧縮します。 前述の2つの圧縮方法の圧縮率は次のように計算されます`compression ratio = size before compression / size after compression * 100` 。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 36e6c7fcf2e2d..9f7360563b39e 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -7,7 +7,7 @@ summary: TiCDC が UPDATE` イベントを分割するかどうかに関する ## MySQLシンクの`UPDATE`イベントを分割する {#split-update-events-for-mysql-sinks} -v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`を取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 +v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーションリクエストを受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`を取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 - 1 つまたは複数の`UPDATE`変更を含むトランザクションの場合、トランザクション`commitTS` `thresholdTS`未満であれば、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割してから、それらを Sorter モジュールに書き込みます。 - トランザクション`commitTS`が`thresholdTS`以上である`UPDATE`イベントの場合、TiCDC はそれらを分割しません。詳細については、GitHub の問題[#10918](https://github.com/pingcap/tiflow/issues/10918)を参照してください。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index e83f715054662..b510949a02668 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -171,7 +171,7 @@ TiDB Cloud APIは、RESTベースのインターフェースであり、 TiDB Cl [TiDBノード](/tidb-computing.md)MySQL互換エンドポイントを使用してアプリケーションに接続するステートレスなSQLレイヤーです。SQLクエリの解析、最適化、分散実行計画の作成などのタスクを処理します。 -TiDBノードを複数デプロイすることで、水平方向に拡張し、より高いワークロードに対応できます。これらのノードは、TiProxyやHAProxyなどのロードバランサーと連携して、シームレスなインターフェースを提供します。TiDBノード自体はデータを保存せず、データ要求を行ベースストレージの場合はTiKVノードに、列指向ストレージの場合はTiFlashノードに転送します。 +TiDBノードを複数デプロイすることで、水平方向に拡張し、より高いワークロードに対応できます。これらのノードは、TiProxyやHAProxyなどのロードバランサーと連携して、シームレスなインターフェースを提供します。TiDBノード自体はデータを保存せず、データリクエストを行ベースストレージの場合はTiKVノードに、列指向ストレージの場合はTiFlashノードに転送します。 ### TiKVノード {#tikv-node} diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index 2c58e708ad514..ab7873b7742a0 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -217,8 +217,8 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 7. Kafkaで**TLS Encryption**オプションを有効にしてください。 8. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 9. TiDB Cloudは**Private Service Connect**用のエンドポイントを作成しますが、これには数分かかる場合があります。 -10. エンドポイントが作成されたら、クラウドプロバイダーのコンソールにログインし、接続要求を承認してください。 -11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続要求を承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 +10. エンドポイントが作成されたら、クラウドプロバイダーのコンソールにログインし、接続リクエストを承認してください。 +11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。
@@ -238,8 +238,8 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 7. Kafkaで**TLS Encryption**オプションを有効にしてください。 8. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 9. TiDB Cloudは**Private Link**のエンドポイントを作成しますが、これには数分かかる場合があります。 -10. エンドポイントが作成されたら、 [Azureポータル](https://portal.azure.com/)にログインして接続要求を承認してください。 -11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続要求を承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 +10. エンドポイントが作成されたら、 [Azureポータル](https://portal.azure.com/)にログインして接続リクエストを承認してください。 +11. [TiDB Cloudコンソール](https://tidbcloud.com)に戻る 接続リクエストを承認したことを確認してください。TiDB Cloudは接続テストを実行し、テストが成功した場合は次のページに進みます。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 775853a147fd5..32434b82826c6 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -97,7 +97,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 - **Connectivity Method**：Pulsarエンドポイントへの接続方法に応じて、 **VPC Peering**または**Public**を選択してください。 - **Pulsar Broker** : Pulsar Broker のエンドポイントを入力します。ポートとドメインまたは IP アドレスはコロンで区切ります。例`example.org:6650` 。 -3. **Authentication**セクションで、Pulsarの認証設定に応じて**Auth Type**オプションを選択します。選択したオプションに基づいて、要求された認証情報を入力します。 +3. **Authentication**セクションで、Pulsarの認証設定に応じて**Auth Type**オプションを選択します。選択したオプションに基づいて、リクエストされた認証情報を入力します。 4. オプション：**Advanced Settings**セクションで、追加設定を構成します。 diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 0c8baf8d571f6..6ca861128567a 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -8,7 +8,7 @@ summary: データアプリのAPIキーの作成、編集、削除方法を学 TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)と[ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)の両方をサポートしています。 - [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - 'Basic'HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 -- [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、および要求された URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 +- [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、およびリクエストされた URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 > **Note:** > diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 267caa1ca18f4..2d2fc4627ecee 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -238,13 +238,13 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に 4. **Next**をクリックしてください。 - 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイントリクエストを承認する必要があります。 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続リクエストを見つけて、 **Approve**をクリックします。 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index dc057fc9cf4fe..589e7e0bf5693 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -239,13 +239,13 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 4. **Next**をクリックしてください。 - 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイントリクエストを承認する必要があります。 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続リクエストを見つけて、 **Approve**をクリックします。 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index f5124b5b6b28c..f4210283d6b40 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -108,13 +108,13 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー 4. **Next**をクリックしてください。 - 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイントリクエストを承認する必要があります。 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続リクエストを見つけて、 **Approve**をクリックします。 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 0a8ad07a35530..5a2ae1135fe74 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -432,7 +432,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続リクエストを承認する必要があります。 @@ -458,7 +458,7 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ 4. [Azureポータル](https://portal.azure.com/)の で、MySQL Flexible Server インスタンスの概要ページ (プライベートエンドポイント オブジェクトではありません) に戻り、 **[Essentials]**セクションで**[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/`形式です。このリソース ID (プライベートエンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。 -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続リクエストを承認する必要があります。 @@ -517,7 +517,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続リクエストを承認する必要があります。 @@ -768,9 +768,9 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 接続方法として**Public IP**または**VPC Peering**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - 接続方法として**Private Link**を使用する場合、エンドポイント要求を承認するよう求められます。 + - 接続方法として**Private Link**を使用する場合、エンドポイントリクエストを承認するよう求められます。 - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 - - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーションペインで**Setting** > **Networking**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 + - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーションペインで**Setting** > **Networking**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続リクエストを承認します。 @@ -781,7 +781,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続リクエストを承認してください。 diff --git a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md index 8e0954e4a45f1..e3d09cb5ed556 100644 --- a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md @@ -211,7 +211,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - パブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - AWS Private Link を使用している場合、エンドポイント要求を承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイント要求を承認してください。 + - AWS Private Link を使用している場合、エンドポイントリクエストを承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイントリクエストを承認してください。 @@ -223,7 +223,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続リクエストを承認してください。 diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index b2c11aec30be4..53e06fedeb74c 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -114,7 +114,7 @@ Datadogは、TiDBクラスタに関して以下のメトリクスを追跡しま | :----------------------------------------- | :------- | :---------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tidb_cloud.db_database_time | ゲージ | sql_type: Select|Insert|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | TiDBで実行されているすべてのSQL文が1秒あたりに消費する合計時間。これには、すべてのプロセスのCPU時間と、アイドル状態ではない待機時間が含まれます。 | | tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | すべての TiDB ノードで 1秒あたりに実行される SQL文の数。文の種類 ( `SELECT` 、 `INSERT` 、または`UPDATE` ) ごとにカウントされます。 | -| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後、クライアントに要求が返されるまでの時間。 | +| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | クライアントのネットワークリクエストがTiDBに送信されてから、TiDBがリクエストを実行した後、クライアントにリクエストが返されるまでの時間。 | | tidb_cloud.db_failed_queries | ゲージ | タイプ: 実行者:xxxx|パーサー:xxxx|...
クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | 各TiDBノードで1秒あたりに発生するSQL実行エラーに基づいた、エラーの種類（構文エラーや主キーの競合など）の統計情報。 | | tidb_cloud.db_total_connection | ゲージ | クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | TiDBサーバーにおける現在の接続数。 | | tidb_cloud.db_active_connections | ゲージ | クラスター名: ``
インスタンス: tidb-0|tidb-1…
コンポーネント: `tidb` | アクティブな接続数。 | diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index ef416ba4a0012..935eedb55a306 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -148,7 +148,7 @@ New Relicは、TiDBクラスタに関して以下のメトリクスを追跡し | :----------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tidb_cloud.db_database_time | ゲージ | sql_type: Select|Insert|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | TiDBで実行されるすべてのSQL文が1秒あたりに消費する合計時間。これには、すべてのプロセスのCPU時間と、アイドル状態ではない待機時間が含まれます。 | | tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | すべての TiDB ノードで 1秒あたりに実行される SQL文の数。これは`SELECT` 、 `INSERT` 、 `UPDATE` 、およびその他のタイプの文に従ってカウントされます。 | -| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後、クライアントに要求が返されるまでの時間。 | +| tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | クライアントのネットワークリクエストがTiDBに送信されてから、TiDBがリクエストを実行した後、クライアントにリクエストが返されるまでの時間。 | | tidb_cloud.db_failed_queries | ゲージ | タイプ: 実行者:xxxx|パーサー:xxxx|...

クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | 各TiDBノードで1秒あたりに発生するSQL実行エラーに基づいた、エラーの種類（構文エラーや主キーの競合など）の統計情報。 | | tidb_cloud.db_total_connection | ゲージ | クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | TiDBサーバーにおける現在の接続数。 | | tidb_cloud.db_active_connections | ゲージ | クラスター名: ``

インスタンス: tidb-0|tidb-1…

コンポーネント: `tidb` | アクティブな接続数。 | diff --git a/tidb-cloud/optimize-resource-allocation.md b/tidb-cloud/optimize-resource-allocation.md index c6e80a1f9e9a8..2e41dcbbca5ff 100644 --- a/tidb-cloud/optimize-resource-allocation.md +++ b/tidb-cloud/optimize-resource-allocation.md @@ -32,7 +32,7 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups | 比較項目 | リソース管理 | TiDBノードグループ | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | 分離レベル | TiKVまたはTiFlash論理レイヤー | TiDBノード物理レイヤー | -| フロー制御 | リソースグループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込み要求のフローを制御します。 | サポートされていません。 | +| フロー制御 | リソースグループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込みリクエストのフローを制御します。 | サポートされていません。 | | コンフィグレーション方法 | SQL文を使用して構成 | TiDB Cloudコンソールから設定 | | ワークロードの区別 | 次のレベルでのバインディング リソースをサポートします。
  • ユーザーレベル。
  • セッションレベル (セッションごとにリソースグループを設定します)。
  • ステートメントレベル (ステートメントごとにリソースグループを設定します)。
| さまざまなワークロードに異なる接続エンドポイントを提供します。 | | 料金 | 追加料金なし | TiDB ノードの追加に関連するコストは発生しますが、TiDB ノードグループの作成には追加コストは発生しません。 | diff --git a/tidb-cloud/plan-replayer.md b/tidb-cloud/plan-replayer.md index 4d4e471bb16e2..8b6f0e1315d28 100644 --- a/tidb-cloud/plan-replayer.md +++ b/tidb-cloud/plan-replayer.md @@ -48,7 +48,7 @@ SELECT * FROM orders WHERE customer_id = 1001; ### 履歴統計情報を使用する {#use-historical-statistics} -履歴統計情報が有効になっており、パフォーマンスの問題が特定の時刻に発生した場合は、`WITH STATS AS OF TIMESTAMP` を使用して、その時点で利用可能だった統計情報を要求します。TiDB は、指定したタイムスタンプより前に利用可能な最新の履歴統計情報を使用します。 +履歴統計情報が有効になっており、パフォーマンスの問題が特定の時刻に発生した場合は、`WITH STATS AS OF TIMESTAMP` を使用して、その時点で利用可能だった統計情報をリクエストします。TiDB は、指定したタイムスタンプより前に利用可能な最新の履歴統計情報を使用します。 ```sql PLAN REPLAYER DUMP WITH STATS AS OF TIMESTAMP diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 2c1168ba31e39..01c0443a56ed2 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -228,7 +228,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 -- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)は指定された有効期間 (TTL) にわたって`GET`要求のエンドポイント応答のキャッシュをサポートします。 +- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)は指定された有効期間 (TTL) にわたって`GET`リクエストのエンドポイント応答のキャッシュをサポートします。 この機能により、データベースの負荷が軽減され、エンドポイントのレイテンシーが最適化されます。 @@ -954,7 +954,7 @@ summary: 2023年のTiDB Cloudのリリースノートについて説明します **コンソールの変更** -- 特定のクラスターに対するサポートを要求するプロセスを簡素化するために、各クラスターに**[サポートを受ける]**オプションを追加します。 +- 特定のクラスターに対するサポートをリクエストするプロセスを簡素化するために、各クラスターに**[サポートを受ける]**オプションを追加します。 クラスターのサポートは、次のいずれかの方法でリクエストできます。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index b1f148b2b092e..0d6604fab23f5 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -740,7 +740,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - [スロークエリ](/tidb-cloud/tune-performance.md#slow-query)ビュー、[DB監査ログ](/tidb-cloud/essential-database-audit-logging.md)、および[`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md)テーブル (ベータ版) に実際のクライアント IP アドレスを表示 - TiDB CloudはクライアントIPパススルーをサポートするようになり、スロークエリビュー、DB監査ログ、および`INFORMATION_SCHEMA.PROCESSLIST`テーブルで、ロードバランサー（LB）のIPアドレスではなく、実際のクライアントIPアドレスを表示できるようになりました。この機能により、データベース要求の真の発生源を正確に特定し、トラブルシューティングと分析を改善できます。 + TiDB CloudはクライアントIPパススルーをサポートするようになり、スロークエリビュー、DB監査ログ、および`INFORMATION_SCHEMA.PROCESSLIST`テーブルで、ロードバランサー（LB）のIPアドレスではなく、実際のクライアントIPアドレスを表示できるようになりました。この機能により、データベースリクエストの真の発生源を正確に特定し、トラブルシューティングと分析を改善できます。 現在、この機能はベータ版であり、AWSリージョン`Frankfurt (eu-central-1)`でのみ利用可能です。 diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index faa99c7eabd99..0ffdb311112f2 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -14,7 +14,7 @@ TiDB Cloudは、デフォルトで高い可用性とデータの耐久性を維 ## 概要 {#overview} -TiDBは、 Raftコンセンサスアルゴリズムを用いて高い可用性とデータの耐久性を確保します。このアルゴリズムは、複数のノード間でデータの変更を一貫して複製するため、ノード障害やネットワーク分断が発生した場合でも、TiDBは読み取りおよび書き込み要求を処理できます。このアプローチにより、高いデータの耐久性と耐障害性の両方が実現されます。 +TiDBは、 Raftコンセンサスアルゴリズムを用いて高い可用性とデータの耐久性を確保します。このアルゴリズムは、複数のノード間でデータの変更を一貫して複製するため、ノード障害やネットワーク分断が発生した場合でも、TiDBは読み取りおよび書き込みリクエストを処理できます。このアプローチにより、高いデータの耐久性と耐障害性の両方が実現されます。 TiDB Cloudは、ゾーン別高可用性とリージョン別高可用性によってこれらの機能を拡張し、さまざまな運用要件に対応します。 diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index 9a7592af36dfa..afd0b1bcbd2a6 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -71,7 +71,7 @@ ticloud serverless private-link-connection zones --cluster-id 5. **Create**をクリックします。 -6. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。 +6. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを承認します。 @@ -85,7 +85,7 @@ TiDB Cloud CLI を使用してプライベートリンク接続を作成する ticloud serverless private-link-connection create -c --display-name --type AWS_ENDPOINT_SERVICE --aws.endpoint-service-name ``` -2. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。 +2. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを承認します。 @@ -161,7 +161,7 @@ ticloud serverless private-link-connection zones --cluster-id 5. **Create**をクリックします。 -6. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。 +6. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを許可します。 @@ -175,7 +175,7 @@ TiDB Cloud CLI を使用してプライベートリンク接続を作成する ticloud serverless private-link-connection create -c --display-name --type ALICLOUD_ENDPOINT_SERVICE --alicloud.endpoint-service-name ``` -2. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。 +2. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続リクエストを許可します。 diff --git a/tidb-cloud/set-up-sink-private-endpoint.md b/tidb-cloud/set-up-sink-private-endpoint.md index 5e891fd43d7f7..cdc44868f268b 100644 --- a/tidb-cloud/set-up-sink-private-endpoint.md +++ b/tidb-cloud/set-up-sink-private-endpoint.md @@ -110,7 +110,7 @@ changefeed ダウンストリーム サービスが Azure でホストされて 2. **Create Private Endpoint for External Services**ダイアログで、プライベートエンドポイントの名前を入力します。 -3. リマインダーに従って、 TiDB Cloudの[Google Cloud プロジェクト](https://cloud.google.com/resource-manager/docs/creating-managing-projects)にエンドポイントの作成を事前承認するよう許可するか、エンドポイント接続要求を受け取ったら手動で承認します。 +3. リマインダーに従って、 TiDB Cloudの[Google Cloud プロジェクト](https://cloud.google.com/resource-manager/docs/creating-managing-projects)にエンドポイントの作成を事前承認するよう許可するか、エンドポイント接続リクエストを受け取ったら手動で承認します。 4. セクション[ネットワーク](#network)で収集した**Service Attachment**を入力します。 diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index d2cdc26f5ea81..c10fe6a8daaf2 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -201,7 +201,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング AWS ダッシュボードを使用して VPC ピアリング接続を構成することもできます。 -1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)でピア接続要求を受け入れることを確認します。 +1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)でピア接続リクエストを受け入れることを確認します。 1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)にサインインし、上部のメニューバーで**Services**をクリックします。検索ボックスに`VPC`と入力して、VPC サービスページに移動します。 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index 2ee09af8b33b4..d79dfb4a3446e 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -304,7 +304,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 > **Note:** > -> 監査ログファイルをTiDB Cloudに保存することを要求して選択した場合は、**Database Audit Logging**ページの**Audit Log Access**セクションからダウンロードできます。 +> 監査ログファイルをTiDB Cloudに保存することをリクエストして選択した場合は、**Database Audit Logging**ページの**Audit Log Access**セクションからダウンロードできます。 TiDB Cloud監査ログは、クラスター ID、ノード ID、およびログ作成日が完全修飾ファイルパスに組み込まれた読み取り可能なテキストファイルです。 diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 7f743e30c3b07..ad52798d64c9a 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -178,7 +178,7 @@ TiDB Cloud Starter、 Essential、およびPremiumプランでは、リクエス - TiDB Cloud Starter は、消費された RU の合計数に基づいて請求されます。詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 - TiDB Cloud Essentialは、プロビジョニングされた[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)の数に基づいて請求されます。 1つの RCU は、1秒あたり特定の数の RU を処理できる固定量のコンピューティングリソースを提供します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 - TiDB Cloud Premium は、ワークロードによって消費された実際のリクエストキャパシティユニット (RCU) に基づいて請求されます。 TiDB Cloudは1秒あたりの平均 RU を毎分計算し、その平均値を[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)として請求に使用します。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)を参照してください。 -TiDB Cloud Dedicatedおよび TiDB Self-Managedの場合、リクエストユニット (RU) はシステムリソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベース要求によって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 +TiDB Cloud Dedicatedおよび TiDB Self-Managedの場合、リクエストユニット (RU) はシステムリソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベースリクエストによって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 ## S {#s} diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index 03ad290ee3f5c..a4f327fb2b9f6 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -26,17 +26,17 @@ summary: TiDB Cloudで SQL パフォーマンスを分析および調整する ## ユーザー応答時間とシステムスループットの関係 {#relationship-between-user-response-time-and-system-throughput} -ユーザー応答時間は、サービス時間、キュー時間、およびユーザー要求を完了するための同時待機時間で構成されます。 +ユーザー応答時間は、サービス時間、キュー時間、およびユーザーリクエストを完了するための同時待機時間で構成されます。 ``` User Response time = Service time + Queuing delay + Coherency delay ``` - サービス時間: リクエストを処理するときにシステムが特定のリソースに消費する時間。たとえば、データベースが SQL リクエストを完了するために消費する CPU 時間など。 -- キューイング遅延: システムが要求を処理するときに、特定のリソースのサービスをキューで待機する時間。 +- キューイング遅延: システムがリクエストを処理するときに、特定のリソースのサービスをキューで待機する時間。 - 一貫性遅延: システムがリクエストを処理するときに共有リソースにアクセスできるように、他の同時タスクと通信して連携する時間。 -システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、要求されたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。 +システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、リクエストされたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。 例えば、OLTP負荷を実行しているデータベースシステムでは、CPU使用率が65%を超えると、CPUキューイングとスケジューリングのレイテンシーが大幅に増加します。これは、システムの同時リクエストが完全に独立していないため、これらのリクエストが連携して共有リソースを奪い合う可能性があるためです。例えば、異なるユーザーからのリクエストが、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソース使用率が増加すると、キューイングとスケジューリングのレイテンシーも増加し、共有リソースが時間内に解放されず、他のタスクによる共有リソースの待機時間が長くなります。 diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index a33ddb0a76956..40490365eaac7 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -31,7 +31,7 @@ summary: TiDB バージョン v8.5.0 では、 TiDB Cloud Dedicated クラスタ - 頻繁なバージョン更新: 一部のワークロードでは、データが非常に頻繁に更新され、読み取られます。 - 履歴バージョンの長期保存：特定の時点へのフラッシュバックのサポートといったビジネス要件を満たすために、ユーザーはGC（ガベージコレクション）時間を過度に長く（例えば24時間など）設定することがあります。その結果、多版型同時実行制御（MVCC）バージョンが過剰に蓄積され、クエリの効率が大幅に低下します。 -MVCC バージョンが蓄積されると、要求されたデータと処理されたデータの間に大きなギャップが生じ、読み取りパフォーマンスが低下します。 +MVCC バージョンが蓄積されると、リクエストされたデータと処理されたデータの間に大きなギャップが生じ、読み取りパフォーマンスが低下します。 ### 解決 {#solution} diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 546ff3db9d2ea..1cee787e881ae 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -349,7 +349,7 @@ TiDB 構成ファイルは、コマンドラインパラメーターよりも多 - TiDBにおけるログ書き込み操作のタイムアウトを設定します。ディスク障害によりログの書き込みができない場合、この設定項目によってTiDBプロセスがハングアップするのではなく、panicになることがあります。 - デフォルト値： `0` 。これはタイムアウトが設定されていないことを示します。 - 単位：秒 -- 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどの要求にも応答しません。この設定項目は、このような状況に対処するために設計されています。 +- 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどのリクエストにも応答しません。この設定項目は、このような状況に対処するために設計されています。 ### log.file {#logfile} @@ -799,7 +799,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 > > この設定パラメータは将来のバージョンで非推奨になる可能性があります。値を変更**しないでください**。 -- 単一のコプロセッサー要求のタイムアウト時間。 +- 単一のコプロセッサーリクエストのタイムアウト時間。 - デフォルト値: `60` - 単位：秒 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index e6468c23f37b8..5a4de5c2416fc 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -250,7 +250,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 > > バージョン7.2.0以降、このパラメータは非推奨となり、設定後は無効になります。1回のリクエストでTiKVに送信されるデータ量を調整したい場合は、代わりに[`send-kv-size`](#send-kv-size-new-in-v720)パラメータを使用してください。 -- 物理インポートモードで TiKV にデータを送信するときに、1つの要求内の KV ペアの最大数を指定します。 +- 物理インポートモードで TiKV にデータを送信するときに、1つのリクエスト内の KV ペアの最大数を指定します。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 4eed7ea317b47..31bd6d68ba88e 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -69,7 +69,7 @@ SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855: | [`tidb_opt_enable_mpp_shared_cte_execution`](/system-variables.md#tidb_opt_enable_mpp_shared_cte_execution-new-in-v720) | TiFlashへの非再帰的な[共通テーブル式（CTE）](/sql-statements/sql-statement-with.md)プッシュダウンを有効にします。 | これは実験的機能です。 | | [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600) | Read Committed分離レベルの場合、この変数を有効にすると、グローバルタイムスタンプを取得する際のレイテンシーとコストが回避され、トランザクションレベルの読み取りレイテンシーが最適化されます。 | この機能は、Repeatable Read分離レベルとは互換性がありません。 | | [`tidb_guarantee_linearizability`](/system-variables.md#tidb_guarantee_linearizability-new-in-v50) | PDサーバーからのコミットタイムスタンプの取得をスキップすることでパフォーマンスを向上させます。 | これは、線形化可能性を犠牲にしてパフォーマンスを優先するものです。因果的一貫性のみが保証されます。厳密な線形化可能性が求められるシナリオには適していません。 | -| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | PDFollower機能を有効にすると、PDフォロワーがリージョン要求を処理できるようになります。これにより、すべてのPDサーバーに負荷が均等に分散され、PDリーダーのCPU負荷が軽減されます。 | 該当なし | +| [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | PDFollower機能を有効にすると、PDフォロワーがリージョンリクエストを処理できるようになります。これにより、すべてのPDサーバーに負荷が均等に分散され、PDリーダーのCPU負荷が軽減されます。 | 該当なし | | [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) | 高度なクエリ最適化戦略を有効にすることで、追加の最適化ルールとヒューリスティックを通じてパフォーマンスを向上させることができます。 | ワークロードによってパフォーマンスの向上度合いが異なるため、ご使用の環境で十分にテストを行ってください。 | 以下では、追加の最適化を可能にするオプティマイザ制御構成について説明します。 @@ -121,7 +121,7 @@ soft-pending-compaction-bytes-limit = "192GiB" | [`concurrent-send-snap-limit`](/tikv-configuration-file.md#concurrent-send-snap-limit) [`concurrent-recv-snap-limit`](/tikv-configuration-file.md#concurrent-recv-snap-limit) [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVのスケーリング操作中に、同時スナップショット転送量とI/O帯域幅の制限を設定します。制限値を高く設定すると、データ移行が高速化され、スケーリング時間が短縮されます。 | これらの制限を調整すると、スケーリング速度とオンライントランザクションパフォーマンスのトレードオフに影響します。 | | [`rocksdb.max-manifest-file-size`](/tikv-configuration-file.md#max-manifest-file-size) | RocksDB マニフェストファイルの最大サイズを設定します。このファイルには、SST ファイルとデータベースの状態変更に関するメタデータが記録されます。このサイズを大きくすると、マニフェストファイルの書き換え頻度が減り、フォアグラウンド書き込みパフォーマンスへの影響を最小限に抑えることができます。 | デフォルト値は`128MiB`です。SSTファイルが多数存在する環境（例えば、数十万個）では、マニフェストファイルの書き換えが頻繁に行われると、書き込みパフォーマンスが低下する可能性があります。このパラメータを`256MiB`以上の値に調整することで、最適なパフォーマンスを維持できます。 | | [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。
  • 主キー範囲スキャンにおけるパフォーマンスへの影響の可能性。
  • 空間増幅率の向上（最悪の場合、最大2倍）。
  • ブロブキャッシュのための追加メモリ使用量。
| -| [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込み要求に対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | +| [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込みリクエストに対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 | | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 | | [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じ圧縮効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)を参照してください。 | @@ -145,7 +145,7 @@ soft-pending-compaction-bytes-limit = "192GiB" > **Note:** > -> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込み要求を拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびストレージ設定の適切な構成が不可欠です。 +> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込みリクエストを拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびストレージ設定の適切な構成が不可欠です。 ### TiFlash -ラーナー向け設定 {#tiflash-learner-configurations} @@ -333,10 +333,10 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p #### トラブルシューティング {#troubleshooting} -ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁に要求するクエリが含まれる場合、 [TSO（タイムスタンプオラクル）](/glossary.md#timestamp-oracle-tso)がパフォーマンスのボトルネックになる可能性があります。TSO の待機時間がシステムに影響を与えているかどうかを確認するには、 [**パフォーマンス概要 > SQL実行時間概要**](/grafana-performance-overview-dashboard.md#sql-execute-time-overview)パネルを確認してください。TSO の待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。 +ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁にリクエストするクエリが含まれる場合、 [TSO（タイムスタンプオラクル）](/glossary.md#timestamp-oracle-tso)がパフォーマンスのボトルネックになる可能性があります。TSO の待機時間がシステムに影響を与えているかどうかを確認するには、 [**パフォーマンス概要 > SQL実行時間概要**](/grafana-performance-overview-dashboard.md#sql-execute-time-overview)パネルを確認してください。TSO の待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。 - 厳密な一貫性を必要としない読み取り操作には、低精度TSO（ [`tidb_low_resolution_tso`](/system-variables.md#tidb_low_resolution_tso)を有効にする）を使用します。詳細については、 [解決策1：低精度TSOを使用する](#solution-1-low-precision-tso)を参照してください。 -- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSO要求の並列モード](#solution-2-parallel-mode-for-tso-requests)を参照してください。 +- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSOリクエストの並列モード](#solution-2-parallel-mode-for-tso-requests)を参照してください。 #### 解決策1：低精度TSO {#solution-1-low-precision-tso} @@ -350,7 +350,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p メリットとデメリット： -- キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプを要求する必要性をなくします。 +- キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプをリクエストする必要性をなくします。 - パフォーマンスとデータの一貫性のバランスを取る：この機能は、古い読み取りデータが許容されるシナリオにのみ適しています。厳密なデータの一貫性が求められる場合には、使用を推奨しません。 この最適化を有効にするには： @@ -359,7 +359,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p SET GLOBAL tidb_low_resolution_tso=ON; ``` -#### 解決策2：TSO要求の並列モード {#solution-2-parallel-mode-for-tso-requests} +#### 解決策2：TSOリクエストの並列モード {#solution-2-parallel-mode-for-tso-requests} システム変数[`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840)は、TiDBがPDにTSO RPCリクエストを送信するモードを切り替えます。デフォルト値は`DEFAULT`です。以下の条件を満たす場合、パフォーマンス向上の可能性を考慮して、この変数を`PARALLEL`または`PARALLEL-FAST`に切り替えることを検討してください。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index b7e2a6a17eaf0..3ee9737861606 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -12,11 +12,11 @@ aliases: ['/ja/tidb/v8.5/tidb-resource-control/','/ja/tidb/stable/tidb-resource- クラスタ管理者として、リソース制御機能を使用して、リソースグループの作成、リソースグループの割り当て量の設定、およびユーザーをそれらのグループにバインドすることができます。 -TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 +TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込みリクエストのフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいてリクエストをスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 - TiDBフロー制御：TiDBフロー制御は[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します。バケットに十分なトークンがなく、リソースグループが`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 -- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソースグループの`RU_PER_SEC`の値を使用して、各リソースグループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 +- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソースグループの`RU_PER_SEC`の値を使用して、各リソースグループの読み取りおよび書き込みリクエストの優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用してリクエストをスケジュールおよび処理します。 バージョン7.4.0以降、リソース制御機能はTiFlashリソースの制御をサポートしています。その原理は、TiDBフロー制御およびTiKVスケジューリングと同様です。 @@ -399,7 +399,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー 3. すべてのリソースグループの合計リソース割り当て（ `RU_PER_SEC` ）がシステム容量を超えた場合、どうなりますか？ - TiDB は、リソースグループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えると、TiDB は優先度の高いリソースグループからの要求を満たすことを優先します。同じ優先度の要求すべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 + TiDB は、リソースグループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えると、TiDB は優先度の高いリソースグループからのリクエストを満たすことを優先します。同じ優先度のリクエストすべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 ## 参照 {#see-also} diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index af316dff6e5aa..e164be044326b 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -239,13 +239,13 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.3.1 TiKV RocksDB は`write stall`を検出します。 - TiKV インスタンスには 2つの RocksDB インスタンスがあり、1つは`data/raft`にありRaftログを格納し、もう 1つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 + TiKV インスタンスには 2つの RocksDB インスタンスがあり、1つは`data/raft`にありRaftログを格納し、もう 1つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込みリクエストをブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込みリクエストを動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。 - - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 + - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 - - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 + - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 - ディスクのI/O容量が長時間にわたって書き込み速度に追いつかない場合は、ディスクの容量を増やすことをお勧めします。ディスクのスループットが上限に達し、書き込みが停止する場合（例えば、SATA SSDはNVMe SSDよりも大幅に低い）、CPUリソースが十分であれば、より高い圧縮率の圧縮アルゴリズムを適用することができます。こうすることで、CPUリソースをディスクリソースに振り向け、ディスクへの負荷を軽減できます。 @@ -501,7 +501,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 7.1.2 `coprocessor.go`は`request outdated`を報告します。 - このエラーは、TiKVに送信されたコプロセッサ要求がTiKVのキューで60秒以上待機した場合に返されます。 + このエラーは、TiKVに送信されたコプロセッサリクエストがTiKVのキューで60秒以上待機した場合に返されます。 TiKVコプロセッサが長いキューに入っている理由を調査する必要があります。 @@ -528,7 +528,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 7.2.1 `key is locked` 。 - 読み取りと書き込みが競合しています。読み取り要求は、コミットされていないデータに遭遇したため、データがコミットされるまで待機する必要があります。 + 読み取りと書き込みが競合しています。読み取りリクエストは、コミットされていないデータに遭遇したため、データがコミットされるまで待機する必要があります。 このエラーの発生件数が少ない場合は業務に影響はありませんが、発生件数が多い場合は、業務において読み書きの競合が深刻であることを示しています。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 54b7fa9a4c8a3..90fa3d9b8b687 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -28,11 +28,11 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次のメトリックを使用して、 TiFlashのスループットを取得できます。 - MPP クエリ数: 各TiFlashインスタンスの MPP クエリ数の瞬間値。TiFlashで処理する必要がある現在の MPP クエリ数 (処理中のクエリとスケジュール待ちのクエリを含む) を反映します。 -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。 - - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP 要求です。 +- リクエスト QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサリクエストの数。 + - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP リクエストです。 - `batch` : バッチリクエストの数。 - - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - - `cop_execution` : 現在実行中のコプロセッサ要求の数。 + - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサリクエストの数。 + - `cop_execution` : 現在実行中のコプロセッサリクエストの数。 - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 - Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG オペレーターの数。`table_scan`はテーブルスキャンオペレーター、 `selection`は選択オペレーター、 `aggregation`は集約オペレーター、 `top_n`は TopN オペレーター、 `limit`は制限オペレーター、 `join`は結合オペレーター、 `exchange_sender`はデータ送信オペレーター、 `exchange_receiver`はデータ受信オペレーターです。 @@ -48,13 +48,13 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - SQL文によってクエリされるデータの量が大きい場合、オプティマイザはコストモデルに従って、 TiFlash のフルテーブルスキャンの方がコスト効率が高いと見積もる場合があります。 - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 -- 要求期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサ要求タイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 +- リクエスト期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサリクエストタイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 - リクエスト処理時間: `cop`と`batch cop`リクエストの実行開始から完了までの時間（待機時間を除く）。この指標は、平均レイテンシとP99レイテンシーを含む、 `cop`と`batch cop`リクエストにのみ適用されます。 例1: TiFlash MPPリクエストの処理時間の概要 -次の図のワークロードでは、 `run_mpp_task`と`mpp_establish_conn`要求が合計処理時間の大部分を占めており、要求のほとんどが実行のためにTiFlashに完全にプッシュダウンされる MPP タスクであることがわかります。 +次の図のワークロードでは、 `run_mpp_task`と`mpp_establish_conn`リクエストが合計処理時間の大部分を占めており、リクエストのほとんどが実行のためにTiFlashに完全にプッシュダウンされる MPP タスクであることがわかります。 `cop`リクエストの処理時間は比較的短いため、リクエストの一部はデータアクセスとコプロセッサを介したフィルタリングのためにTiFlashにプッシュダウンされていることがわかります。 diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index 69eb7a21de1b5..b85f1cb577a17 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -32,10 +32,10 @@ TiFlash のバージョンを確認するには、次の2つの方法があり | ログ情報 | ログの説明 | | ------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------- | | `[INFO] [] ["KVStore: Start to persist [region 47, applied: term 6 index 10]"] [thread_id=23]` | データの複製が開始されます（ログの先頭の角括弧内の数字はスレッドIDを表します） | -| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handling DAG request"] [thread_id=30]` | DAG要求の処理、つまりTiFlashがコプロセッサー要求の処理を開始する | -| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handle DAG request done"] [thread_id=30]` | DAG要求の処理が完了しました。つまり、 TiFlashがコプロセッサー要求の処理を完了しました。 | +| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handling DAG request"] [thread_id=30]` | DAGリクエストの処理、つまりTiFlashがコプロセッサーリクエストの処理を開始する | +| `[DEBUG] [] ["CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): Handle DAG request done"] [thread_id=30]` | DAGリクエストの処理が完了しました。つまり、 TiFlashがコプロセッサーリクエストの処理を完了しました。 | -コプロセッサー要求の開始または終了を見つけ、ログの先頭に印刷されているスレッド ID を通じてコプロセッサー要求の関連ログを見つけることができます。 +コプロセッサーリクエストの開始または終了を見つけ、ログの先頭に印刷されているスレッド ID を通じてコプロセッサーリクエストの関連ログを見つけることができます。 ## TiFlashシステムテーブル {#tiflash-system-table} diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index a94df401c7538..e7fe47f225323 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -37,14 +37,14 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`はバッチ要求の数です。`batch_cop`はバッチ要求内のコプロセッサ要求の数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`はすべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`はスーパー バッチ機能を有効にするための要求の数です。 +- リクエスト QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサリクエストの数。`batch`はバッチリクエストの数です。`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インスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 -- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 +- エラー QPS: コプロセッサリクエストを処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 - リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 - 応答バイト/秒: すべてのTiFlashインスタンスからの応答の合計バイト数。 -- Cop タスクのメモリ使用量: コプロセッサ要求を処理するすべてのTiFlashインスタンスの合計メモリ使用量。 -- 処理要求数: コプロセッサ要求を処理しているすべてのTiFlashインスタンスの総数。要求の分類は、要求QPSと同じです。 +- Cop タスクのメモリ使用量: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計メモリ使用量。 +- 処理リクエスト数: コプロセッサリクエストを処理しているすべてのTiFlashインスタンスの総数。リクエストの分類は、リクエストQPSと同じです。 - RPC スレッド: 各TiFlashインスタンスで使用される RPC スレッドのリアルタイム数。 - RPC の最大スレッド数: 各TiFlashインスタンスで最近使用された RPC スレッドの最大数。 - スレッド: 各TiFlashインスタンスで使用されるスレッドのリアルタイム数。 @@ -68,7 +68,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## ストレージ {#storage} -- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1秒あたりに受信される書き込み要求の数。 +- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1秒あたりに受信される書き込みリクエストの数。 - 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`はこの開始以降の書き込み増幅で、 `5min`は過去 5分間の書き込み増幅です。 - 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1秒あたりの読み取りタスクの数。 - 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 @@ -103,4 +103,4 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas - 読み取りインデックス OPS: 各TiFlashインスタンスが`read_index`回のリクエストをトリガーする回数。これはトリガーされたリージョンの数に等しくなります。 - インデックス読み取り時間: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 -- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信した後、ローカルインデックス >= read_index になるまで待機する時間です。 +- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`リクエストを受信した後、ローカルインデックス >= read_index になるまで待機する時間です。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 7228f8bb2a0ad..e50f330ec3eef 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -140,29 +140,29 @@ I/O トラフィック制限設定を構成します。 -- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`はフォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`はフォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_write_weight` {#background_write_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `foreground_read_weight` {#foreground_read_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_read_weight` {#background_read_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら4種類の要求に帯域幅を割り当てます。 +- TiFlashは内部的にI/Oリクエストを4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら4種類のリクエストに帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 @@ -382,7 +382,7 @@ I/O トラフィック制限設定を構成します。 ##### `cop_pool_max_queued_seconds`バージョン5.0の新機能 {#cop_pool_max_queued_seconds-new-in-v50} -- cop要求がTiFlashにキューイングできる最大時間を指定します。cop要求がこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 +- copリクエストがTiFlashにキューイングできる最大時間を指定します。copリクエストがこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 - `0`以下の値は制限がないことを示します。 - デフォルト値: `15` @@ -393,7 +393,7 @@ I/O トラフィック制限設定を構成します。 ##### `manual_compact_pool_size`バージョン6.1の新機能 {#manual_compact_pool_size-new-in-v61} -- TiFlash がTiDB から`ALTER TABLE ... COMPACT`を受信したときに同時に処理できる要求の数を指定します。 +- TiFlash がTiDB から`ALTER TABLE ... COMPACT`を受信したときに同時に処理できるリクエストの数を指定します。 - 値が`0`に設定されている場合、デフォルト値`1`が優先されます。 - デフォルト値: `1` diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index 01710ad73c9f0..d49e49fddbb62 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -11,13 +11,13 @@ TiFlash MinTSOスケジューラは、 TiFlash内の[MPP](/glossary.md#massively MPPクエリを処理する際、TiDBはクエリを1つ以上のMPPタスクに分割し、これらのMPPタスクを対応するTiFlashノードに送信してコンパイルおよび実行します。TiFlashが[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用する前に、各MPPタスクを実行するために複数のスレッドを使用する必要があります。具体的なスレッド数は、MPPタスクの複雑さとTiFlashに設定された同時実行パラメータによって異なります。 -同時実行性の高いシナリオでは、 TiFlashノードは複数のMPPタスクを同時に受信します。MPPタスクの実行が制御されていない場合、 TiFlashがシステムに要求する必要があるスレッド数は、MPPタスク数の増加に伴って直線的に増加します。スレッド数が多すぎるとTiFlashの実行効率に影響を与える可能性があります。また、オペレーティングシステム自体がサポートするスレッド数には制限があるため、オペレーティングシステムが提供できる以上のスレッドをTiFlashが要求するとエラーが発生します。 +同時実行性の高いシナリオでは、 TiFlashノードは複数のMPPタスクを同時に受信します。MPPタスクの実行が制御されていない場合、 TiFlashがシステムにリクエストする必要があるスレッド数は、MPPタスク数の増加に伴って直線的に増加します。スレッド数が多すぎるとTiFlashの実行効率に影響を与える可能性があります。また、オペレーティングシステム自体がサポートするスレッド数には制限があるため、オペレーティングシステムが提供できる以上のスレッドをTiFlashがリクエストするとエラーが発生します。 高い同時実行性が必要なシナリオで TiFlash の処理能力を向上させるには、 TiFlashに MPP タスク スケジューラを導入する必要があります。 ## 実装原理 {#implementation-principles} -[背景](#background)で述べたように、 TiFlashタスクスケジューラを導入する当初の目的は、MPP クエリ実行中に使用されるスレッド数を制御することです。シンプルなスケジューリング戦略は、 TiFlash が要求できる最大スレッド数を指定することです。スケジューラは、各 MPP タスクについて、システムで現在使用されているスレッド数と、MPP タスクが使用すると予想されるスレッド数に基づいて、その MPP タスクをスケジュールできるかどうかを判断します。 +[背景](#background)で述べたように、 TiFlashタスクスケジューラを導入する当初の目的は、MPP クエリ実行中に使用されるスレッド数を制御することです。シンプルなスケジューリング戦略は、 TiFlash がリクエストできる最大スレッド数を指定することです。スケジューラは、各 MPP タスクについて、システムで現在使用されているスレッド数と、MPP タスクが使用すると予想されるスレッド数に基づいて、その MPP タスクをスケジュールできるかどうかを判断します。 ![TiFlash MinTSO Scheduler v1](/media/tiflash/tiflash_mintso_v1.png) diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index c3a561ab2a83e..9ee9c6ffb9e75 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -63,7 +63,7 @@ TiFlash内のレプリカは、特別なロールであるRaft Learnerとして TiFlashはTiKVと同じスナップショット分離レベルの一貫性を提供し、最新のデータが読み取られることを保証します。つまり、TiKVに以前書き込まれたデータを読み取ることができます。このような一貫性は、データレプリケーションの進行状況を検証することで実現されます。 -TiFlash が読み取り要求を受信するたびに、リージョンレプリカはLeaderレプリカに進行状況検証要求（軽量 RPC 要求）を送信します。TiFlashは、読み取り要求のタイムスタンプに含まれるデータが現在のレプリケーション進行状況に含まれた場合にのみ、読み取り操作を実行します。 +TiFlash が読み取りリクエストを受信するたびに、リージョンレプリカはLeaderレプリカに進行状況検証リクエスト（軽量 RPC リクエスト）を送信します。TiFlashは、読み取りリクエストのタイムスタンプに含まれるデータが現在のレプリケーション進行状況に含まれた場合にのみ、読み取り操作を実行します。 ### 賢い選択 {#intelligent-choice} diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index 49eaf65860189..d4f067d70fcad 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -36,7 +36,7 @@ TiFlashのオリジナルのストリームモデルは、スレッドスケジ - パイプラインクエリ実行ツール - パイプラインクエリ実行エンジンは、TiDBノードから送信されたクエリ要求をパイプライン有向非巡回グラフ（DAG）に変換します。 + パイプラインクエリ実行エンジンは、TiDBノードから送信されたクエリリクエストをパイプライン有向非巡回グラフ（DAG）に変換します。 クエリ内のパイプラインブレーカーオペレーターを検出し、それらのオペレーターに基づいてクエリを複数のパイプラインに分割します。次に、パイプライン間の依存関係に基づいて、それらのパイプラインをDAG（有向非巡回グラフ）に組み立てます。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index b6161e142bdad..a954a3a6fb16f 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -43,7 +43,7 @@ SELECT app_name, country FROM t1; - 効率的なBIソリューション - 多くの BI アプリケーションでは、分析クエリ要求が非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリ要求を処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 + 多くの BI アプリケーションでは、分析クエリリクエストが非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリリクエストを処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 - TiFlashによるオンラインアプリケーションの提供 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index f3f534df4afc8..5359b9bc41358 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -237,7 +237,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `end-point-request-max-handle-duration` {#end-point-request-max-handle-duration} -- TiDBからTiKVへの処理タスクのプッシュダウン要求に許容される最長期間 +- TiDBからTiKVへの処理タスクのプッシュダウンリクエストに許容される最長期間 - デフォルト値: `"60s"` - 最小値: `"1s"` @@ -283,7 +283,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `end-point-slow-log-threshold` {#end-point-slow-log-threshold} -- TiDBのプッシュダウン要求がスローログを出力するまでの時間しきい値。処理時間がこのしきい値を超えると、スローログが出力されます。 +- TiDBのプッシュダウンリクエストがスローログを出力するまでの時間しきい値。処理時間がこのしきい値を超えると、スローログが出力されます。 - デフォルト値: `"1s"` - 最小値: `0` @@ -311,7 +311,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ## readpool.unified {#readpoolunified} -読み取り要求を処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。 +読み取りリクエストを処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。 ### `min-thread-count` {#min-thread-count} @@ -369,7 +369,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `use-unified-pool` {#use-unified-pool-1} -- ストレージ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 +- ストレージリクエストに統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 - デフォルト値: このセクション ( `readpool.storage` ) に他の設定がない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のために、デフォルト値は`false`です。このオプションを有効にする前に、必要に応じて[`readpool.unified`](#readpoolunified)の設定を変更してください。 ### `high-concurrency` {#high-concurrency-1} @@ -423,24 +423,24 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `use-unified-pool` {#use-unified-pool} -- コプロセッサ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメータの値が`false`の場合、このセクションの残りのパラメータ（ `readpool.coprocessor` ）で構成された別のスレッドプールが使用されます。 +- コプロセッサリクエストに統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメータの値が`false`の場合、このセクションの残りのパラメータ（ `readpool.coprocessor` ）で構成された別のスレッドプールが使用されます。 - デフォルト値: このセクションのパラメータ ( `readpool.coprocessor` ) がいずれも設定されていない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のためにデフォルト値は`false`になります。このパラメータを有効にする前に、 [`readpool.unified`](#readpoolunified)の設定項目を調整してください。 ### `high-concurrency` {#high-concurrency} -- チェックポイントなどの優先度の高いコプロセッサー要求を処理する同時実行スレッドの許容数 +- チェックポイントなどの優先度の高いコプロセッサーリクエストを処理する同時実行スレッドの許容数 - デフォルト値: `CPU * 0.8` - 最小値: `1` ### `normal-concurrency` {#normal-concurrency} -- 通常優先度のコプロセッサー要求を処理する同時実行スレッドの許容数 +- 通常優先度のコプロセッサーリクエストを処理する同時実行スレッドの許容数 - デフォルト値: `CPU * 0.8` - 最小値: `1` ### `low-concurrency` {#low-concurrency} -- テーブルスキャンなどの低優先度コプロセッサー要求を処理する同時実行スレッドの許容数 +- テーブルスキャンなどの低優先度コプロセッサーリクエストを処理する同時実行スレッドの許容数 - デフォルト値: `CPU * 0.8` - 最小値: `1` @@ -513,7 +513,7 @@ TiKV の設定ファイルは、コマンドラインパラメータよりも多 ### `enable-async-apply-prewrite` {#enable-async-apply-prewrite} -- 非同期コミットトランザクションが、プリライト要求を適用する前にTiKVクライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用時間が長い場合はレイテンシーを容易に短縮でき、適用時間が不安定な場合は遅延ジッターを低減できます。 +- 非同期コミットトランザクションが、プリライトリクエストを適用する前にTiKVクライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用時間が長い場合はレイテンシーを容易に短縮でき、適用時間が不安定な場合は遅延ジッターを低減できます。 - デフォルト値: `false` ### `reserve-space` {#reserve-space} @@ -617,7 +617,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ ### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit-1} -- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始め、 `ServerIsBusy`エラーを報告します。 +- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込みリクエストを拒否し始め、 `ServerIsBusy`エラーを報告します。 > **Note:** > @@ -627,7 +627,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ ### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit-1} -- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この設定項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 +- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込みリクエストを拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この設定項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 - デフォルト値: `"1024GiB"` ## storage.io-rate-limit {#storageio-rate-limit} @@ -1114,7 +1114,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `apply-max-batch-size` {#apply-max-batch-size} -- Raftステートマシンは、BatchSystemによってデータ書き込み要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 +- Raftステートマシンは、BatchSystemによってデータ書き込みリクエストをバッチ処理します。この設定項目は、1つのバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 - デフォルト値: `256` - 最小値: `0`より大きい - 最大値: `10240` @@ -1127,7 +1127,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `store-max-batch-size` {#store-max-batch-size} -- Raftステートマシンは、BatchSystemによってログをディスクに書き込む要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 +- Raftステートマシンは、BatchSystemによってログをディスクに書き込むリクエストをバッチ処理します。この設定項目は、1つのバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 - `hibernate-regions`が有効になっている場合、デフォルト値は`256`です。 `hibernate-regions`が無効になっている場合、デフォルト値は`1024`です。 - 最小値: `0`より大きい - 最大値: `10240` @@ -2388,12 +2388,12 @@ TiKVの自動圧縮の動作を設定します。 ### `mvcc-read-aware-enabled` v8.5.6の新機能 {#mvcc-read-aware-enabled-new-in-v856} -- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取り要求中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。 +- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取りリクエスト中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。 - デフォルト値: `false` ### `mvcc-scan-threshold` v8.5.6で追加 {#mvcc-scan-threshold-new-in-v856} -- リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 +- リージョンを圧縮候補としてマークするために、読み取りリクエストごとにスキャンされる MVCC バージョンの最小数。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 - デフォルト値: `1000` - 最小値: `0` @@ -2627,11 +2627,11 @@ TiCDCに関連するコンフィグレーション項目。 フォアグラウンドのクォータリミッターに関連するコンフィグレーション項目。 -TiKV がデプロイされているマシンにリソースが限られている場合、たとえば、CPU が 4V、メモリが16GB しかないとします。このような状況では、TiKV のフォアグラウンドが読み書き要求を過剰に処理し、バックグラウンドで使用される CPU リソースがこれらの要求の処理に占有され、TiKV のパフォーマンスの安定性に影響する可能性があります。この状況を回避するには、フォアグラウンドのクォータ関連の設定項目を使用して、フォアグラウンドで使用される CPU リソースを制限できます。要求がクォータ リミッターをトリガーすると、要求は TiKV が CPU リソースを解放するまでしばらく待機させられます。正確な待機時間は要求の数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 +TiKV がデプロイされているマシンにリソースが限られている場合、たとえば、CPU が 4V、メモリが16GB しかないとします。このような状況では、TiKV のフォアグラウンドが読み書きリクエストを過剰に処理し、バックグラウンドで使用される CPU リソースがこれらのリクエストの処理に占有され、TiKV のパフォーマンスの安定性に影響する可能性があります。この状況を回避するには、フォアグラウンドのクォータ関連の設定項目を使用して、フォアグラウンドで使用される CPU リソースを制限できます。リクエストがクォータ リミッターをトリガーすると、リクエストは TiKV が CPU リソースを解放するまでしばらく待機させられます。正確な待機時間はリクエストの数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 #### `foreground-cpu-time` v6.0.0の新機能 {#foreground-cpu-time-new-in-v600} -- TiKVフォアグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 +- TiKVフォアグラウンドが読み取りおよび書き込みリクエストを処理するために使用するCPUリソースのソフトリミット。 - デフォルト値： `0` （制限なしを意味します） - 単位：ミリCPU（例： `1500`は、フォアグラウンドリクエストが1.5VのCPUを消費することを意味します） - 推奨設定: 4 コアを超えるインスタンスの場合は、デフォルト値`0`を使用してください。4 コアのインスタンスの場合は、値を`1000`と`1500`の範囲に設定するとバランスが取れます。2 コアのインスタンスの場合は、値を`1200`より小さくしてください。 @@ -2652,7 +2652,7 @@ TiKV がデプロイされているマシンにリソースが限られている バックグラウンドクォータリミッターに関連するコンフィグレーション項目。 -TiKV がデプロイされているマシンにリソースが限られている場合、たとえば CPU が 4V、メモリが16GB しかない場合を考えてみましょう。このような状況では、TiKV のバックグラウンドで計算や読み書き要求が多すぎると、フォアグラウンドで使用される CPU リソースがこれらの要求の処理に占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンドのクォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限できます。要求がクォータ リミッターをトリガーすると、TiKV が CPU リソースを解放するまで、要求はしばらく待機させられます。正確な待機時間は要求の数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 +TiKV がデプロイされているマシンにリソースが限られている場合、たとえば CPU が 4V、メモリが16GB しかない場合を考えてみましょう。このような状況では、TiKV のバックグラウンドで計算や読み書きリクエストが多すぎると、フォアグラウンドで使用される CPU リソースがこれらのリクエストの処理に占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンドのクォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限できます。リクエストがクォータ リミッターをトリガーすると、TiKV が CPU リソースを解放するまで、リクエストはしばらく待機させられます。正確な待機時間はリクエストの数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 > **Warning:** > @@ -2661,7 +2661,7 @@ TiKV がデプロイされているマシンにリソースが限られている #### `background-cpu-time` v6.2.0の新機能 {#background-cpu-time-new-in-v620} -- TiKVバックグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 +- TiKVバックグラウンドが読み取りおよび書き込みリクエストを処理するために使用するCPUリソースのソフトリミット。 - デフォルト値： `0` （制限なしを意味します） - 単位：ミリCPU（例： `1500`は、バックグラウンドリクエストが1.5VのCPUを消費することを意味します） @@ -2689,7 +2689,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### `alloc-ahead-buffer` v6.4.0で追加 {#alloc-ahead-buffer-new-in-v640} - 事前割り当て済みのTSOキャッシュサイズ（期間）。 -- TiKV は、この設定項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`を満たす TSO をローカルに要求してキャッシュします。 +- TiKV は、この設定項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`を満たす TSO をローカルにリクエストしてキャッシュします。 - この設定項目は、TiKV API V2 が有効になっている場合の PD 障害の許容度を高めるためによく使用されます ( `storage.api-version = 2` )。 - この設定項目の値を大きくすると、TSOの消費量とTiKVのメモリオーバーヘッドが増加する可能性があります。十分なTSOを確保するには、PDの設定項目[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を下げることをお勧めします。 - テストによると、 `alloc-ahead-buffer`がデフォルト値の場合、PDリーダーが故障して別のノードに切り替わると、書き込みリクエストのレイテンシーが一時的に増加し、QPSが約15%減少します。 @@ -2707,14 +2707,14 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### `renew-batch-min-size` {#renew-batch-min-size} -- タイムスタンプ要求におけるTSOの最小数。 -- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュサイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 +- タイムスタンプリクエストにおけるTSOの最小数。 +- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV はリクエストされる TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュサイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 - Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチサイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカルキャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。- デフォルト値: `100` ### `renew-batch-max-size` v6.4.0で追加 {#renew-batch-max-size-new-in-v640} -- タイムスタンプ要求におけるTSOの最大数。 -- デフォルトのTSO物理時間更新間隔（ `50ms` ）では、PDは最大262144個のTSOを提供します。要求されたTSOがこの数を超えると、PDはそれ以上TSOを提供しません。この設定項目は、TSOの枯渇と、TSO枯渇が他の業務に及ぼす逆効果を回避するために使用されます。高可用性を向上させるためにこの設定項目の値を増やす場合は、十分なTSOを確保するために、同時に[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を減らす必要があります。 +- タイムスタンプリクエストにおけるTSOの最大数。 +- デフォルトのTSO物理時間更新間隔（ `50ms` ）では、PDは最大262144個のTSOを提供します。リクエストされたTSOがこの数を超えると、PDはそれ以上TSOを提供しません。この設定項目は、TSOの枯渇と、TSO枯渇が他の業務に及ぼす逆効果を回避するために使用されます。高可用性を向上させるためにこの設定項目の値を増やす場合は、十分なTSOを確保するために、同時に[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を減らす必要があります。 - デフォルト値: `8192` ## resource-metering {#resource-metering} diff --git a/tikv-control.md b/tikv-control.md index 5fd13007a2e5c..72c71ef88e0e6 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -383,7 +383,7 @@ DebugClient::check_region_consistency: RpcFailure(RpcStatus { status: Unknown, d > > - `consistency-check`コマンドは TiDB のガベージコレクションと互換性がなく、誤ってエラーを報告する可能性があるため、使用はお勧めし**ません**。 > - このコマンドはリモートモードのみをサポートします。 -> - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックを要求するプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 +> - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックをリクエストするプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 ### スナップショットのメタをダンプ {#dump-snapshot-meta} diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index ddcfdae63af0b..03cf101457df0 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -24,10 +24,10 @@ TiKV MVCCインメモリエンジンは、最新の書き込み済みMVCCバー - 左側（インメモリエンジンが無効になっている場合）：テーブルレコードは、主キーに基づいて昇順でRocksDBに格納され、同じ行のすべてのMVCCバージョンが隣接して配置されます。 - 右側（インメモリエンジン有効）：RocksDB内のデータは左側のデータと同じですが、インメモリエンジンは2つの行それぞれについて最新の2つのMVCCバージョンをキャッシュします。 -- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャン要求を処理する場合： +- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャンリクエストを処理する場合： - インメモリエンジン（左図）がない場合、11個のMVCCバージョンを処理する必要があります。 - インメモリエンジン（右図）では、処理するMVCCバージョンは4つだけなので、リクエストのレイテンシーとCPU消費量が削減されます。 -- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャン要求を処理する場合： +- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャンリクエストを処理する場合： - メモリ内エンジン（右図）に必要な履歴バージョンが欠落しているため、キャッシュが無効になり、TiKVはRocksDBからデータを読み込むようにフォールバックします。 ## 使用法 {#usage} @@ -79,14 +79,14 @@ mvcc-amplification-threshold = 10 - [BR](/br/br-use-overview.md) ：インメモリエンジンはBRと併用できます。ただし、 BRリストア中は、リストア処理に関係するリージョンはインメモリエンジンから削除されます。BRが完了した後、対応するリージョンがホットスポットとして残っている場合は、インメモリエンジンによって自動的にロードされます。 - [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) ：インメモリエンジンはTiDB Lightningと併用できます。ただし、 TiDB Lightningが物理インポートモードで動作する場合、復元プロセスに関係するリージョンはインメモリエンジンから削除されます。物理インポートが完了すると、対応するリージョンがホットスポットとして残っている場合、それらはインメモリエンジンによって自動的にロードされます。 -- [Follower Read](/develop/dev-guide-use-follower-read.md)と[ステイル読み取り](/develop/dev-guide-use-stale-read.md) ：インメモリエンジンは、これら2つの機能と併用できます。ただし、インメモリエンジンはLeader上のコプロセッサ要求のみを高速化でき、Follower Readとステイル読み取り操作を高速化することはできません。 +- [Follower Read](/develop/dev-guide-use-follower-read.md)と[ステイル読み取り](/develop/dev-guide-use-stale-read.md) ：インメモリエンジンは、これら2つの機能と併用できます。ただし、インメモリエンジンはLeader上のコプロセッサリクエストのみを高速化でき、Follower Readとステイル読み取り操作を高速化することはできません。 - [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) ：インメモリエンジンはFlashbackと併用できます。ただし、Flashbackはインメモリエンジンのキャッシュを無効化します。Flashback処理が完了すると、インメモリエンジンはホットスポット領域を自動的にロードします。 ## FAQ {#faq} ### インメモリエンジンは書き込みレイテンシーを低減し、書き込みスループットを向上させることができるか？ {#can-the-in-memory-engine-reduce-write-latency-and-increase-write-throughput} -いいえ。インメモリエンジンは、多数のMVCCバージョンをスキャンする読み取り要求のみを高速化できます。 +いいえ。インメモリエンジンは、多数のMVCCバージョンをスキャンする読み取りリクエストのみを高速化できます。 ### インメモリエンジンが私のシナリオを改善できるかどうかを判断するにはどうすればよいでしょうか？ {#how-to-determine-if-the-in-memory-engine-can-improve-my-scenario} diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 1e059f08f0794..09c81d3009969 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -118,7 +118,7 @@ TiProxy の負荷分散ポリシーの構成。 - デフォルト値: `""` - ホットリロードのサポート: はい -- [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)に使用するラベル名を指定します。TiProxy は、このラベル名に基づいて TiDB サーバーのラベル値を照合し、自分と同じラベル値を持つ TiDB サーバーへのルーティング要求を優先します。 +- [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)に使用するラベル名を指定します。TiProxy は、このラベル名に基づいて TiDB サーバーのラベル値を照合し、自分と同じラベル値を持つ TiDB サーバーへのルーティングリクエストを優先します。 - デフォルト値の`label-name`は空文字列で、ラベルベースの負荷分散が使用されないことを示します。この負荷分散ポリシーを有効にするには、この設定項目を空でない文字列に設定し、TiProxy で[`labels`](#labels) 、TiDB で[`labels`](/tidb-configuration-file.md#labels)の両方を設定する必要があります。詳細については、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を参照してください。 #### `policy` {#policy} diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 22b5fbe2c8279..92cd9ca1711a2 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -10,11 +10,11 @@ TiProxy v1.0.0 は、TiDB サーバーに対してステータスベースおよ デフォルトでは、TiProxy は次の優先順位でこれらのポリシーを適用します。 1. ステータスベースの負荷分散: TiDBサーバーがシャットダウンすると、TiProxy はその TiDBサーバーからオンラインの TiDBサーバーに接続を移行します。 -2. ラベルベースの負荷分散: TiProxy は、TiProxy インスタンスと同じラベルを共有する TiDB サーバーへのルーティング要求を優先し、コンピューティングレイヤーでのリソースの分離を可能にします。 +2. ラベルベースの負荷分散: TiProxy は、TiProxy インスタンスと同じラベルを共有する TiDB サーバーへのルーティングリクエストを優先し、コンピューティングレイヤーでのリソースの分離を可能にします。 3. ヘルスベースの負荷分散: TiDBサーバーのヘルスが異常な場合、TiProxy はその TiDBサーバーから正常な TiDBサーバーに接続を移行します。 4. メモリベースの負荷分散: TiDBサーバーがメモリ不足 (OOM) になる危険がある場合、TiProxy はその TiDBサーバーからメモリ使用量の少ない TiDBサーバーに接続を移行します。 5. CPU ベースの負荷分散: TiDBサーバーの CPU 使用率が他の TiDB サーバーよりもはるかに高い場合、TiProxy はその TiDBサーバーから CPU 使用率の低い TiDBサーバーに接続を移行します。 -6. ロケーションベースの負荷分散: TiProxy は、TiProxy に地理的に最も近い TiDBサーバーへのルーティング要求を優先します。 +6. ロケーションベースの負荷分散: TiProxy は、TiProxy に地理的に最も近い TiDBサーバーへのルーティングリクエストを優先します。 7. 接続数ベースの負荷分散: TiDBサーバーの接続数が他の TiDB サーバーよりも大幅に多い場合、TiProxy はその TiDBサーバーから接続数の少ない TiDBサーバーに接続を移行します。 負荷分散ポリシーの優先順位を調整するには、 [負荷分散ポリシーを構成する](#configure-load-balancing-policies)を参照してください。 @@ -137,8 +137,8 @@ TiProxy は、TiProxy サーバーと TiDB サーバーの場所に基づいて このポリシーは、次のシナリオに適しています。 -- TiDB クラスターがクラウド内のアベイラビリティゾーン全体にデプロイされている場合、TiProxy と TiDB サーバー間のアベイラビリティゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティゾーン内の TiDB サーバーへのルーティング要求を優先します。 -- TiDB クラスターがデータセンター全体にデプロイされている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータセンター内の TiDB サーバーへのルーティング要求を優先します。 +- TiDB クラスターがクラウド内のアベイラビリティゾーン全体にデプロイされている場合、TiProxy と TiDB サーバー間のアベイラビリティゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティゾーン内の TiDB サーバーへのルーティングリクエストを優先します。 +- TiDB クラスターがデータセンター全体にデプロイされている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータセンター内の TiDB サーバーへのルーティングリクエストを優先します。 デフォルトでは、このポリシーの優先度は、ヘルスベース、メモリベース、CPUベースの負荷分散ポリシーよりも低くなっています。優先度を[`policy`](/tiproxy/tiproxy-configuration.md#policy)から`location`に設定することで、優先度を上げることができます。可用性とパフォーマンスを維持するには、少なくとも3台のTiDBサーバーを同じ場所に配置することを推奨します。 @@ -185,7 +185,7 @@ pd_servers: - host: pd-host-3 ``` -上記の構成では、 `tiproxy-host-1`の`zone`設定が`tidb-host-1`と同じであるため、 `tiproxy-host-1`の TiProxy インスタンスは`tidb-host-1` TiDBサーバーへのルーティング要求を優先します。同様に、 `tiproxy-host-2`の TiProxy インスタンスは`tidb-host-2`の TiDBサーバーへのルーティング要求を優先します。 +上記の構成では、 `tiproxy-host-1`の`zone`設定が`tidb-host-1`と同じであるため、 `tiproxy-host-1`の TiProxy インスタンスは`tidb-host-1` TiDBサーバーへのルーティングリクエストを優先します。同様に、 `tiproxy-host-2`の TiProxy インスタンスは`tidb-host-2`の TiDBサーバーへのルーティングリクエストを優先します。 ## 接続数ベースの負荷分散 {#connection-count-based-load-balancing} diff --git a/tiup/tiup-component-cluster-tls.md b/tiup/tiup-component-cluster-tls.md index 4a9a86dda2543..c48f871d6d1db 100644 --- a/tiup/tiup-component-cluster-tls.md +++ b/tiup/tiup-component-cluster-tls.md @@ -33,7 +33,7 @@ tiup cluster tls [flags] - クラスターの現在のTLSステータスに関係なく、TLSを強制的に有効または無効にします。 - データタイプ: `BOOLEAN` - デフォルト: `false` -- このオプションを指定しない場合、クラスターが既に要求された状態にある場合は、操作はスキップされます。 +- このオプションを指定しない場合、クラスターが既にリクエストされた状態にある場合は、操作はスキップされます。 ### --reload-certificate {#reload-certificate} diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 227c5b3a9aeec..979a560d9fb71 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -303,9 +303,9 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの - クライアントがインストールされると、バイナリに`root.json`ファイルが含まれます。 - 実行中のクライアントは、既存の`root.json`に基づいて次のタスクを実行します。 1. `root.json`からバージョンを取得し、 `N`としてマークします。 - 2. ミラーに`{N+1}.root.json`を要求します。要求が成功した場合、 `root.json`で記録した公開鍵を使用して、ファイルが有効かどうかを検証します。 - 3. ミラーから`timestamp.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルが有効かどうかを確認します。 - 4. `timestamp.json`に記録された`snapshot.json`のチェックサムがローカルの`snapshot.json`のチェックサムと一致するかどうかを確認します。一致しない場合は、ミラーから最新の`snapshot.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルの有効性を検証します。 - 5. `snapshot.json`からファイル`index.json`のバージョン番号`N`を取得し、ミラーに`{N}.index.json`を要求します。次に、 `root.json`に記録されている公開鍵を使用して、ファイルが有効かどうかを検証します。 - 6. `tidb.json`や`tikv.json`などのコンポーネントについては、クライアントは`snapshot.json`からコンポーネントのバージョン番号`N`を取得し、ミラーに`{N}.{component}.json`を要求します。次に、クライアントは`index.json`に記録されている公開鍵を使用して、ファイルの有効性を検証します。 - 7. コンポーネントのtarファイルの場合、クライアントは`{component}.json`からファイルのURLとチェックサムを取得し、tarパッケージのURLを要求します。そして、クライアントはチェックサムが正しいかどうかを検証します。 + 2. ミラーに`{N+1}.root.json`をリクエストします。リクエストが成功した場合、 `root.json`で記録した公開鍵を使用して、ファイルが有効かどうかを検証します。 + 3. ミラーから`timestamp.json`をリクエストし、 `root.json`に記録された公開鍵を使用してファイルが有効かどうかを確認します。 + 4. `timestamp.json`に記録された`snapshot.json`のチェックサムがローカルの`snapshot.json`のチェックサムと一致するかどうかを確認します。一致しない場合は、ミラーから最新の`snapshot.json`をリクエストし、 `root.json`に記録された公開鍵を使用してファイルの有効性を検証します。 + 5. `snapshot.json`からファイル`index.json`のバージョン番号`N`を取得し、ミラーに`{N}.index.json`をリクエストします。次に、 `root.json`に記録されている公開鍵を使用して、ファイルが有効かどうかを検証します。 + 6. `tidb.json`や`tikv.json`などのコンポーネントについては、クライアントは`snapshot.json`からコンポーネントのバージョン番号`N`を取得し、ミラーに`{N}.{component}.json`をリクエストします。次に、クライアントは`index.json`に記録されている公開鍵を使用して、ファイルの有効性を検証します。 + 7. コンポーネントのtarファイルの場合、クライアントは`{component}.json`からファイルのURLとチェックサムを取得し、tarパッケージのURLをリクエストします。そして、クライアントはチェックサムが正しいかどうかを検証します。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index cb832c0a6d420..a5c3b2ea272fb 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -177,7 +177,7 @@ TiDBのコプロセッサーキャッシュ機能は、計算結果のキャッ ## 散在する読み取りホットスポット {#scatter-read-hotspots} -読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 +読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取りリクエストを時間内に処理できず、読み取りリクエストがキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取りリクエストのキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 ### 読み取りホットスポット向けの CPU-aware hot Region scheduling {#cpu-aware-hot-region-scheduling-for-read-hotspots} diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index b81d3439c45e2..dc8cb6b01b7a8 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -163,11 +163,11 @@ CURRENT_SQL_DIGEST_TEXT: update `t` set `v` = `v` + ? where `id` = ? ; ### 読み書き競合 {#read-write-conflicts} -TiDBサーバーはクライアントからの読み取り要求を受信すると、物理時刻におけるグローバルに一意で増加するタイムスタンプを現在のトランザクションのstart_tsとして取得します。トランザクションはstart_tsより前の最新のデータ、つまりstart_tsより小さい最新のcommit_tsのターゲットキーを読み取る必要があります。トランザクションがターゲットキーが別のトランザクションによってロックされていることに気づき、そのトランザクションがどのフェーズにあるかを把握できない場合、読み取り/書き込み競合が発生します。図を以下に示します。 +TiDBサーバーはクライアントからの読み取りリクエストを受信すると、物理時刻におけるグローバルに一意で増加するタイムスタンプを現在のトランザクションのstart_tsとして取得します。トランザクションはstart_tsより前の最新のデータ、つまりstart_tsより小さい最新のcommit_tsのターゲットキーを読み取る必要があります。トランザクションがターゲットキーが別のトランザクションによってロックされていることに気づき、そのトランザクションがどのフェーズにあるかを把握できない場合、読み取り/書き込み競合が発生します。図を以下に示します。 ![read-write conflict](/media/troubleshooting-lock-pic-04.png) -Txn0はPrewriteフェーズを完了し、Commitフェーズに入ります。この時、Txn1は同じターゲットキーの読み取りを要求します。Txn1は、自身のstart_tsよりも小さい最新のcommit_tsのターゲットキーを読み取る必要があります。Txn1のstart_tsはTxn0のlock_tsよりも大きいため、Txn1はターゲットキーのロックが解除されるまで待機する必要がありますが、まだ解除されていません。その結果、Txn1はTxn0がコミットされたかどうかを確認できません。こうして、Txn1とTxn0の間で読み取り/書き込み競合が発生します。 +Txn0はPrewriteフェーズを完了し、Commitフェーズに入ります。この時、Txn1は同じターゲットキーの読み取りをリクエストします。Txn1は、自身のstart_tsよりも小さい最新のcommit_tsのターゲットキーを読み取る必要があります。Txn1のstart_tsはTxn0のlock_tsよりも大きいため、Txn1はターゲットキーのロックが解除されるまで待機する必要がありますが、まだ解除されていません。その結果、Txn1はTxn0がコミットされたかどうかを確認できません。こうして、Txn1とTxn0の間で読み取り/書き込み競合が発生します。 TiDB クラスター内の読み取り/書き込み競合は、次の方法で検出できます。 @@ -187,10 +187,10 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で [INFO] [coprocessor.go:743] ["[TIME_COP_PROCESS] resp_time:406.038899ms txnStartTS:416643508703592451 region_id:8297 store_addr:10.8.1.208:20160 backoff_ms:255 backoff_types:[txnLockFast,txnLockFast] kv_process_ms:333 scan_total_write:0 scan_processed_write:0 scan_total_data:0 scan_processed_data:0 scan_total_lock:0 scan_processed_lock:0"] ``` - - txnStartTS: 読み取り要求を送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 - - backoff_types: 読み取り/書き込み競合が発生し、読み取り要求がバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 + - txnStartTS: 読み取りリクエストを送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 + - backoff_types: 読み取り/書き込み競合が発生し、読み取りリクエストがバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 - backoff_ms: 読み取りリクエストがバックオフとリトライに要した時間。単位はミリ秒です。上記のログでは、読み取りリクエストはバックオフとリトライに255ミリ秒を費やしています。 - - region_id: 読み取り要求のターゲット キーに対応するリージョンID。 + - region_id: 読み取りリクエストのターゲット キーに対応するリージョンID。 2. TiKVサーバーのログ @@ -200,7 +200,7 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で [ERROR] [endpoint.rs:454] [error-response] [err=""locked primary_lock:7480000000000004D35F6980000000000000010380000000004C788E0380000000004C0748 lock_version: 411402933858205712 key: 7480000000000004D35F7280000000004C0748 lock_ttl: 3008 txn_size: 1""] ``` - このメッセージは、TiDBで読み取り/書き込み競合が発生したことを示しています。読み取り要求のターゲットキーは別のトランザクションによってロックされています。ロックは、コミットされていない楽観的トランザクションと、プリライトフェーズ後のコミットされていない悲観的トランザクションによって発生しています。 + このメッセージは、TiDBで読み取り/書き込み競合が発生したことを示しています。読み取りリクエストのターゲットキーは別のトランザクションによってロックされています。ロックは、コミットされていない楽観的トランザクションと、プリライトフェーズ後のコミットされていない悲観的トランザクションによって発生しています。 - primary_lock: ターゲット キーがプライマリ ロックによってロックされていることを示します。 - lock_version: ロックを所有するトランザクションの start_ts。 @@ -308,7 +308,7 @@ err="pessimistic lock retry limit reached" ### ロック待機タイムアウトを超えました {#lock-wait-timeout-exceeded} -悲観的トランザクションモードでは、トランザクションは互いのロックを待機します。ロック待機のタイムアウトは、TiDBのパラメータ[innodb_lock_wait_timeout](/pessimistic-transaction.md#behaviors)によって定義されます。これは、SQL文レベルでの最大ロック待機時間であり、SQL文がロックを要求したがロックが取得されなかった場合に想定される時間です。この時間が経過すると、TiDBは再びロックを試行せず、対応するエラーメッセージをクライアントに返します。 +悲観的トランザクションモードでは、トランザクションは互いのロックを待機します。ロック待機のタイムアウトは、TiDBのパラメータ[innodb_lock_wait_timeout](/pessimistic-transaction.md#behaviors)によって定義されます。これは、SQL文レベルでの最大ロック待機時間であり、SQL文がロックをリクエストしたがロックが取得されなかった場合に想定される時間です。この時間が経過すると、TiDBは再びロックを試行せず、対応するエラーメッセージをクライアントに返します。 待機ロックのタイムアウトが発生すると、次のエラーメッセージがクライアントに返されます。 @@ -337,7 +337,7 @@ TTL manager has timed out, pessimistic locks may expire, please commit or rollba ### ロックを取得しようとしたときにデッドロックが見つかりました {#deadlock-found-when-trying-to-get-lock} -2つ以上のトランザクション間でリソースの競合が発生すると、デッドロックが発生します。手動で対処しないと、互いにブロックし合うトランザクションは正常に実行されず、永遠に待機状態になります。デッドロックを解決するには、いずれかのトランザクションを手動で終了し、他のトランザクション要求を再開する必要があります。 +2つ以上のトランザクション間でリソースの競合が発生すると、デッドロックが発生します。手動で対処しないと、互いにブロックし合うトランザクションは正常に実行されず、永遠に待機状態になります。デッドロックを解決するには、いずれかのトランザクションを手動で終了し、他のトランザクションリクエストを再開する必要があります。 悲観的トランザクションでデッドロックが発生した場合、デッドロックを解除するには、いずれかのトランザクションを終了させる必要があります。クライアントはMySQLと同じ`Error 1213`エラーを返します。例： diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 9abd50d2b198b..92c98745b5b34 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -42,7 +42,7 @@ TiDB Grafana パネルで、 **KV エラー**の下にある次の監視メト - `wait_expired` 、トランザクションがロックの有効期限が切れるまで待機する必要があることを示します。 - `expired`ロックのTTLが期限切れであることを示します。その後、競合トランザクションはこのロックを解決できます。 -- **KV 再試行期間は、** KV 要求を再送信する期間を示します。 +- **KV 再試行期間は、** KV リクエストを再送信する期間を示します。 ![kv-retry-duration](/media/troubleshooting-write-conflict-kv-retry-duration.png) diff --git a/tune-region-performance.md b/tune-region-performance.md index 57f3065d94887..3f12f757c8c9e 100644 --- a/tune-region-performance.md +++ b/tune-region-performance.md @@ -45,9 +45,9 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b 多数のリージョンを持つTiDBクラスターでは、ハートビート処理とタスクのスケジューリングによるオーバーヘッドの増加により、PDリーダーのCPU負荷が高くなる可能性があります。クラスターに多数のTiDBインスタンスがあり、リージョン情報へのリクエストが同時に発生すると、PDリーダーのCPU負荷がさらに高まり、PDサービスが利用できなくなる可能性があります。 -高可用性を確保するため、PDリーダーはリージョン情報をフォロワーとリアルタイムで同期します。PDフォロワーはリージョン情報をメモリに保持・保存し、リージョン情報要求を処理できるようにします。システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定することで、アクティブPDFollower機能を有効にすることができます。この機能を有効にすると、TiDBはリージョン情報要求をすべてのPDサーバーに均等に分散し、PDフォロワーもリージョン要求を直接処理できるようになるため、PDリーダーのCPU負荷が軽減されます。 +高可用性を確保するため、PDリーダーはリージョン情報をフォロワーとリアルタイムで同期します。PDフォロワーはリージョン情報をメモリに保持・保存し、リージョン情報リクエストを処理できるようにします。システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定することで、アクティブPDFollower機能を有効にすることができます。この機能を有効にすると、TiDBはリージョン情報リクエストをすべてのPDサーバーに均等に分散し、PDフォロワーもリージョンリクエストを直接処理できるようになるため、PDリーダーのCPU負荷が軽減されます。 PD は、リージョン同期ストリームのステータスを維持し、TiKV client-go のフォールバック メカニズムを使用することで、TiDB 内のリージョン情報が常に最新であることを保証します。 -- PDリーダーとフォロワー間のネットワークが不安定な場合、またはフォロワーが利用できない場合、リージョン同期ストリームは切断され、PDフォロワーはリージョン情報要求を拒否します。この場合、TiDBはPDリーダーへの要求を自動的に再試行し、フォロワーを一時的に利用不可としてマークします。 -- ネットワークが安定している場合でも、リーダーとフォロワー間の同期に遅延が生じる可能性があり、フォロワーから取得したリージョン情報の一部が古くなっている可能性があります。この場合、当該リージョンに対応するKV要求が失敗すると、TiDBはPDリーダーに最新のリージョン情報を自動的に再要求し、TiKVに再度KV要求を送信します。 +- PDリーダーとフォロワー間のネットワークが不安定な場合、またはフォロワーが利用できない場合、リージョン同期ストリームは切断され、PDフォロワーはリージョン情報リクエストを拒否します。この場合、TiDBはPDリーダーへのリクエストを自動的に再試行し、フォロワーを一時的に利用不可としてマークします。 +- ネットワークが安定している場合でも、リーダーとフォロワー間の同期に遅延が生じる可能性があり、フォロワーから取得したリージョン情報の一部が古くなっている可能性があります。この場合、当該リージョンに対応するKVリクエストが失敗すると、TiDBはPDリーダーに最新のリージョン情報を自動的に再リクエストし、TiKVに再度KVリクエストを送信します。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index ee56195cc825b..b20e6161b69eb 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -13,7 +13,7 @@ TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftsto - gRPC スレッドプール: すべてのネットワークリクエストを処理し、さまざまなタスクタイプのリクエストをさまざまなスレッドプールに転送します。 -- スケジューラスレッドプール: 書き込みトランザクションの競合を検出し、2 フェーズコミット、悲観的ロック、トランザクション ロールバックなどの要求をキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 +- スケジューラスレッドプール: 書き込みトランザクションの競合を検出し、2 フェーズコミット、悲観的ロック、トランザクション ロールバックなどのリクエストをキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 - Raftstoreスレッドプール: @@ -23,15 +23,15 @@ TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftsto - StoreWriter スレッドプール: すべてのRaftログをディスクに書き込み、結果をRaftstoreスレッドに返します。 -- Apply スレッドプール: Raftstoreスレッドプールから送信された送信ログを受信し、それをキー値要求として解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッドプールに書き込み要求が完了したことを通知し、結果をクライアントに返します。 +- Apply スレッドプール: Raftstoreスレッドプールから送信された送信ログを受信し、それをキー値リクエストとして解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッドプールに書き込みリクエストが完了したことを通知し、結果をクライアントに返します。 - RocksDBスレッドプール：RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。 -- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取り要求はこのスレッドプールで実行されます。 +- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取りリクエストはこのスレッドプールで実行されます。 ## TiKV読み取り専用リクエスト {#tikv-read-only-requests} -TiKV の読み取り要求は次の種類に分類されます。 +TiKV の読み取りリクエストは次の種類に分類されます。 - ストレージ読み取りプールで実行される、特定の行または複数の行を指定する単純なクエリ。 - コプロセッサー読み取りプールで実行される複雑な集計計算と範囲クエリ。 @@ -45,7 +45,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで v8.5.4以降、gRPCスレッドプールのデフォルトサイズ（ `server.grpc-concurrency`で設定）が固定値の`5`から、CPUコア数に基づいて計算される適応値に変更されました。詳細な計算式については、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)を参照してください。このスレッドプールはコンピューティングオーバーヘッドがほとんどなく、主にネットワークI/Oとデシリアライズリクエストを処理するため、通常はデフォルト設定を調整する必要はありません。 - TiKV でデプロイされたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`設定項目を`2`に設定することを検討してください。 - - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッドプールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 + - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込みリクエストを処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッドプールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 - スケジューラスレッドプール。 @@ -54,7 +54,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで このスレッドプールは主に、複雑なトランザクションリクエストを単純なキー値の読み取り/書き込みリクエストに変換するために使用されます。ただし、**スケジューラスレッドプール自体は書き込み操作を実行しません**。 - トランザクションの競合が検出されると、このスレッドプールは競合の結果を事前にクライアントに返します。 - - 競合が検出されない場合、このスレッドプールは書き込み操作を実行するキー値要求をRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 + - 競合が検出されない場合、このスレッドプールは書き込み操作を実行するキー値リクエストをRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 一般的に、過度のスレッド切り替えを避けるには、スケジューラのスレッドプールの使用率を50%～75%に保つことが最善です。スレッドプールのサイズが`8`の場合、Grafanaでは400%～600%の範囲で`TiKV-Details.Thread CPU.scheduler worker CPU`を維持することをお勧めします。 @@ -71,7 +71,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - StoreWriterスレッドプールは、CPUリソース全体が十分である場合にのみ有効にしてください。StoreWriterスレッドプールを有効にする際は、StoreWriterスレッドとRaftstoreスレッドのCPU使用率を80%未満に抑えてください。 - 書き込み要求がRaftstoreスレッドで処理される場合と比較して、理論上は、書き込み要求が StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O 要求をStoreWriterスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 + 書き込みリクエストがRaftstoreスレッドで処理される場合と比較して、理論上は、書き込みリクエストが StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O リクエストをStoreWriterスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 - ほとんどの場合、StoreWriter スレッドプールのサイズは 1 または 2 に設定してください。これは、StoreWriter スレッドプールのサイズがRaftログの数に影響するため、スレッドプールのサイズを大きくしすぎないようにするためです。CPU 使用率が 80% を超える場合は、スレッドプールのサイズを増やすことを検討してください。