diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index dc43bf22635b8..22fb9d110e7f6 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -212,7 +212,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し 1 row in set (0.01 sec) ``` -ベクトルを明示的に文字列表現にキャストすることもできます。1関数`VEC_AS_TEXT()`例に挙げましょう。 +ベクトルを明示的に文字列表現にキャストすることもできます。`VEC_AS_TEXT()`関数の使用を例に挙げましょう。 ```sql -- The string is first implicitly cast to a vector, and then the vector is explicitly cast to a string, thus returning a string in the normalized format: diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..daa83a8e3c1e6 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -467,7 +467,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. ネットワークがクリアかどうかを確認してください。 2. リモート TiKV がダウンしていないかどうかを確認します。 - 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。1の解決策を参照してください[`TiKV_channel_full_total`](#tikv_channel_full_total) + 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 #### `TiKV_channel_full_total` {#tikv-channel-full-total} diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index 2d39a6a325cdf..74d96b9c1374b 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -59,7 +59,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 ### TiKVはデータ処理が遅い {#tikv-is-slow-in-data-processing} -TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。15 `170ms`差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。 +TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。`170ms`を差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。 ```sql +----------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------+---------------------------------+-----------+------+ diff --git a/auto-increment.md b/auto-increment.md index 16ac74a383500..efe34776c7b10 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -94,7 +94,7 @@ TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装しま CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int); ``` -クラスター内に2つのTiDBインスタンス（ `A`と`B`があるとします。7テーブルに対してそれぞれ`t`と`B` `A` `INSERT`ステートメントを実行すると、次のようになります。 +クラスター内に2つのTiDBインスタンス（ `A`と`B` ）があるとします。`A`と`B`でそれぞれ`t`テーブルに対して`INSERT`ステートメントを実行すると、次のようになります。 ```sql INSERT INTO t (c) VALUES (1) diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index 51a9323935c03..edfdb9cd51c0b 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc ## 監視アーキテクチャ {#monitoring-architecture} -[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。2 [Grafana](https://grafana.com/) 、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 +[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。[Grafana](https://grafana.com/)は、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 ![The monitoring architecture in the TiDB cluster](/media/prometheus-in-tidb.png) diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 341868db839a4..0098a3bfb5b13 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -102,7 +102,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ - [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) - [`merge-schedule-limit`](/pd-configuration-file.md#merge-schedule-limit) -`Region Merge`パラメータのデフォルト設定はかなり保守的です。5 [PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 +`Region Merge`パラメータのデフォルト設定はかなり保守的です。[PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)に記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 ### 方法4: TiKVインスタンスの数を増やす {#method-4-increase-the-number-of-tikv-instances} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 247e9544b4434..6944704f2283e 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -223,8 +223,8 @@ CREATE TABLE t1 ( TiDBオプティマイザは条件を分解した後、各部分の範囲を計算し、それらを結合します。この例では、次のように導出されます。 - - `(a1, b1) > (1, 10)`場合: `a1 > 1`の場合は 3 、 `a1 = 1`および`b1 > 10`の場合は`(1, +inf]` `(1, 10, 1, +inf]`の範囲を作成します。 - - `(a1, b1) < (10, 20)`の場合: `a1 < 10`と`[10, -inf, 10, 20)`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲​​ 7 を作成します。 + - `(a1, b1) > (1, 10)`の場合: `a1 > 1`の場合は範囲`(1, +inf]`を作成し、 `a1 = 1`および`b1 > 10`の場合は`(1, 10, 1, +inf]`を作成します。 + - `(a1, b1) < (10, 20)`の場合: `a1 < 10`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲`[10, -inf, 10, 20)`を作成します。 最終結果では、これらを組み合わせて、洗練された範囲`(1, 10, 1, +inf] UNION (1, 10) UNION [10, -inf, 10, 20)`得られます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index c05ad675ed769..8ae98fd2e1150 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -74,7 +74,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ - ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 - どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 -ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。1と`region-weight` `leader-weight`それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight` 「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight` 「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 +ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 ### ホットリージョンのスケジュール {#hot-regions-scheduling} @@ -293,7 +293,7 @@ TiKV ノードに障害が発生した場合、PD はデフォルトで、対応 実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。 -TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。1 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)加算することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 +TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)指定します（デフォルトでは無効）。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 85f78bc255dce..d4c3f25221f6b 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -123,4 +123,4 @@ tiup ctl:v tikv --host=${ip:port} modify-tikv-config -n gc.max_ このパラメータは、Goプロセス全体で使用できるCPUコアの数を制御するために使用されます。デフォルトでは、この値は現在のマシンまたはcgroupのCPUコア数と同じです。 -Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。1パラメータの値を制限しないと、これらのバックグラウンドタスク`performance.max-procs` CPUを過剰に消費することになります。 +Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。`performance.max-procs`パラメータの値を制限しないと、これらのバックグラウンドタスクがCPUを過剰に消費することになります。 diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index 51b15a307a8f8..b8f5af85477a3 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -96,10 +96,10 @@ DESC mysql.expr_pushdown_blacklist; 上記の各フィールドの説明は次のとおりです。 - `name` : プッシュダウンが無効になっている関数の名前。 -- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。8 `store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 - - `store_type`が`tidb`場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 - - `store_type`が`tikv`場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 - - `store_type`が`tiflash`場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 +- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 + - `store_type`が`tidb`の場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 + - `store_type`が`tikv`の場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 + - `store_type`が`tiflash`の場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 - `reason` : この関数がブロックリストに追加された理由を記録します。 ### 使用法 {#usage} diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 3eed6a0aea860..3ca2ea20ce2a3 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -15,15 +15,15 @@ TiDBクラスタが大規模で、障害発生後に再度リストアを行う ## 実施原則 {#implementation-principles} -チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)参照してください。 +チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)を参照してください。 ### スナップショットの復元 {#snapshot-restore} -スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。3 `br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 +スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。 `br`は、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`はこの範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 -`br`復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`チェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 +`br`は復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`はチェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 -`br`リストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。 +`br`がリストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`は以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。 MVCC (Multi-Version Concurrency Control) メカニズムを使用しているため、指定されたタイムスタンプを持つデータを順序なしで繰り返し書き込むことができます。 @@ -35,27 +35,27 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた スナップショットバックアップファイルとは異なり、ログバックアップファイルの範囲は重複する可能性があります。そのため、キー範囲を復旧進捗メタデータとして直接使用することはできません。また、ログバックアップファイルの数が多すぎる場合もあります。ただし、各ログバックアップファイルは、ログバックアップメタデータ内で固定の位置を持ちます。つまり、ログバックアップメタデータ内の一意の位置を、復旧進捗メタデータとして各ログバックアップファイルに割り当てることができます。 -ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、トリプル`(log backup metadata name, file metadata array offset, log backup file array offset)` `br`してログバックアップファイルを一意に識別できます。 +ログバックアップメタデータには、ファイルメタデータの配列が含まれています。配列内の各ファイルメタデータは、複数のログバックアップファイルで構成されるファイルを表します。ファイルメタデータには、連結されたファイル内のログバックアップファイルのオフセットとサイズが記録されます。したがって、`br`は`(ログバックアップメタデータ名、ファイルメタデータ配列オフセット、ログバックアップファイル配列オフセット)`の3つの要素の組を使用してログバックアップファイルを一意に識別できます。 ## 使用制限 {#usage-limitations} -チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録することはできません。詳細については、以下のセクションで説明します。 +チェックポイント復元はGCメカニズムに依存しており、復元されたすべてのデータを記録できるわけではありません。詳細については、以下のセクションで説明します。 ### GCは一時停止されます {#gc-will-be-paused} -ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`ログの復元中にGCを一時停止します。3 `br`途中で終了した場合、GCは一時停止状態のままになります。 +ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`はログの復元中にGCを一時停止します。`br`が途中で終了した場合、GCは一時停止状態のままになります。 ログの復元が完了すると、GCは手動で起動することなく自動的に再起動されます。ただし、復元を続行しない場合は、以下の手順でGCを手動で有効にすることができます。 -`br` GCを一時停止する原理は、 `SET config tikv gc.ratio-threshold = -1.0`実行して`gc.ratio-threshold`負の値に設定し、GCを一時停止することです。 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold)の値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 `SET config tikv gc.ratio-threshold = 1.1`実行します。 +`br`がGCを一時停止する原理は、 `SET config tikv gc.ratio-threshold = -1.0`を実行して`gc.ratio-threshold`を負の値に設定し、GCを一時停止することです。 [`gc.ratio-threshold`](/tikv-configuration-file.md#ratio-threshold)の値を変更することで、GCを手動で有効にすることができます。例えば、デフォルト値にリセットするには、 `SET config tikv gc.ratio-threshold = 1.1`を実行します。 ### 一部のデータは再度復元する必要があります {#some-data-needs-to-be-restored-again} -`br`復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。 +`br`は復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。 -- 中断の原因がエラーである場合、 `br`終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 +- 中断の原因がエラーである場合、 `br`は終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージに復元されたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージに復元されたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 ### 復元中にクラスタデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore} @@ -63,43 +63,43 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### クロスメジャーバージョンのチェックポイントリカバリは推奨されません {#cross-major-version-checkpoint-recovery-is-not-recommended} -メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`リカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。 +メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`のリカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。 ## 実装の詳細: チェックポイントデータを下流のクラスタに保存する {#implementation-details-store-checkpoint-data-in-the-downstream-cluster} > **Note:** > -> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータのストレージを指定できます。 +> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータのストレージを指定できます。 チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。 ### スナップショットの復元 {#snapshot-restore} -初期復元中に、 `br`ターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。 +初期復元中に、 `br`はターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。 -復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。`br`は`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 -復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`エラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 +復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`はエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 ### PITR復元 {#pitr-restore} -[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。 +[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)はスナップショットの復元フェーズとログの復元フェーズで構成されます。 -初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 +初期リストアでは、 `br`はスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts`を`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 -初期復元中にログ復元フェーズに入ると、 `br`ターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`エラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 +初期復元中にログ復元フェーズに入ると、 `br`はターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 -初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。mysql.tidb_pitr_id_map**からデータを恣意的に削除すると`mysql.tidb_pitr_id_map` PITRリストアデータの不整合が発生する可能性があります。** +初期リストア中のログリストアフェーズに入る前に、 `br`が`restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。 **`mysql.tidb_pitr_id_map`からデータを恣意的に削除すると、PITRリストアデータの不整合が発生する可能性があります。** > **Note:** > -> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 +> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`が存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 ## 実装の詳細: チェックポイントデータを外部ストレージに保存する {#implementation-details-store-checkpoint-data-in-the-external-storage} > **Note:** > -> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータの外部ストレージを指定できます。例： +> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータの外部ストレージを指定できます。例： > > ```shell > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints" @@ -107,9 +107,9 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 外部ストレージでは、チェックポイント データのディレクトリ構造は次のようになります。 -- ルート パス`restore-{downstream-cluster-ID}` 、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 +- ルート パス`restore-{downstream-cluster-ID}`は、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 - パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。 -- パス`restore-{downstream-cluster-ID}/sst` 、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 +- パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 - パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイント データが保存されます。 @@ -141,21 +141,21 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### スナップショットの復元 {#snapshot-restore} -初期復元中に、 `br`指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パス`br`作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。 +初期復元中に、 `br`は指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パスを作成します。このパスには、 `br`がチェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSを記録します。 -復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。`br`は、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 -復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、エラーコード`br`報告されます。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。 +復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`はエラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。 ### PITR復元 {#pitr-restore} -[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。 +[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)はスナップショットの復元フェーズとログの復元フェーズで構成されます。 -初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 +初期リストアでは、 `br`はスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 -初期復元中にログ復元フェーズに入ると、 `br`​​指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 +初期復元中にログ復元フェーズに入ると、 `br`は指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 -初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。pitr_id_maps **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。** +初期リストア中のログリストアフェーズに入る前に、 `br`が`restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。 **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。** > **Note:** > diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 8384351938299..284a6c7fac439 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -94,7 +94,7 @@ BR を使用すると、ログ バックアップ データをバックアップ TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。 -- `--log.crypter.method` : 暗号化アルゴリズム。2、4、6 `aes192-ctr` `aes128-ctr`かになります。デフォルト値は`aes256-ctr` `plaintext` 、データは暗号化されません。 +- `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 - `--log.crypter.key-file` : キーファイル。2 `crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 @@ -111,7 +111,7 @@ tiup br log start \ ただし、セキュリティ要件が高いシナリオでは、固定の暗号化キーをコマンドラインで直接渡すことは望ましくない場合があります。セキュリティをさらに強化するには、マスターキーベースの暗号化システムを使用して暗号化キーを管理できます。このシステムは、ログバックアップファイルごとに異なるデータキーを生成し、マスターキーのローテーションをサポートします。以下のパラメータを使用して設定できます。 -- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。2、4 `aes192-ctr`または`aes256-ctr` `aes128-ctr`かになります。デフォルト値は`plaintext`で、データは暗号化されません。 +- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。 ローカル ディスクに保存されているマスター キーを使用して暗号化します。 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index dbc9bf6040a6a..fa61bccac9e5b 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -60,8 +60,8 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)調整する必要があります。 - `--pitr-concurrency` : ログ復元中の同時タスクの数。 - `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。 -- `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。2、4、6 `lz4`サポートし、デフォルトは`zstd`です（通常は変更する必要`zstd`ありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を`snappy`してください。 -- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。2 `zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 +- `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。`lz4` 、 `snappy` 、 `zstd`をサポートし、デフォルトは`zstd`です（通常は変更する必要はありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を参照してください。 +- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。`zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 ## フルバックアップのコマンド {#commands-of-full-backup} diff --git a/certificate-authentication.md b/certificate-authentication.md index 2405bba23e874..9721af9f02ac1 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -198,7 +198,7 @@ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem ### サーバー証明書を使用するように TiDB を構成する {#configure-tidb-to-use-server-certificate} -TiDB設定ファイルの`[security]`セクションを変更します。この手順では`path/to/server-key.pem` CA証明書、サーバー鍵、サーバー証明書`path/to/ca-cert.pem`保存されるディレクトリを指定します。3、5、7 `path/to/server-cert.pem`任意のディレクトリに置き換えることができます。 +TiDB設定ファイルの`[security]`セクションを変更します。この手順では、CA証明書、サーバー鍵、サーバー証明書が保存されるディレクトリを指定します。`path/to/server-cert.pem` 、 `path/to/server-key.pem` 、 `path/to/ca-cert.pem`は任意のディレクトリに置き換えることができます。 ```toml [security] diff --git a/check-before-deployment.md b/check-before-deployment.md index 3d9b7dd67e5bc..ce9bbee371323 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -656,7 +656,7 @@ sudo systemctl enable ntpd.service > > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネル パラメータです。 > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 - > - 少なくとも`vm.min_free_kbytes` ～ `1048576` KiB（1 GiB）に設定することをお勧めします。5 [NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)の場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 + > - `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`を設定することをお勧めします。 10. ユーザーの`limits.conf`ファイルを構成するには、次のコマンドを実行します。 @@ -756,6 +756,6 @@ sudo yum -y install numactl SELinux を無効にするか、permissive モードに設定する必要があります。現在のステータスを確認するには、 [ゲットエンフォース(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 -SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。7または`enforcing` `permissive` `disabled`への変更は、再起動しないと有効になりません。 +SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。`enforcing`または`permissive`から`disabled`への変更は、再起動しないと有効になりません。 一部のシステム（Ubuntuなど）では、 `/etc/selinux/config`ファイルが存在せず、getenforceユーティリティがインストールされていない場合があります。その場合は、この手順をスキップしてください。 diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index ee00768b3a89d..79823e2f2063f 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -53,7 +53,7 @@ TiKV は、コマンドラインパラメータに対していくつかの読み - このフラグを使用すると、使用可能な構成値が`FORMAT`に従ってリストされ、終了します。 - `FORMAT`の値オプション: `json` 。現在、JSON 形式のみがサポートされています。 -- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。1または`--config` `-C`されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 +- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。`-C`または`--config`が指定されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 ```json { diff --git a/comment-syntax.md b/comment-syntax.md index 44d164965a193..4d356d68369ac 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -109,7 +109,7 @@ MySQLでは、コメントにサーバーのバージョン番号（例： `/*!5 TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント構文) があり、次の 2 種類に分けられます。 - `/*T! Specific code */` : この構文は TiDB によってのみ解析および実行され、他のデータベースでは無視されます。 -- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。10 `AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。/* **`/*T![`文字内にスペースを入れないでください**。 +- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。`AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。**`/*T![`文字内にスペースを入れないでください**。 ## オプティマイザコメント構文 {#optimizer-comment-syntax} diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 916aa933340da..51c165aacdc59 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -127,7 +127,7 @@ TiDBが使用するトランザクションモデルでは、トランザクシ ### フロー制御 {#flow-control} -- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子はデータ読み取りに使用できる最大スレッド数を使用します。1 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)超えると、データ読み取り演算子は1つのスレッドを停止します。 +- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子は[`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)で許可される最大スレッド数を使用してデータを読み取ります。単一のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データ読み取り演算子は1つのスレッドを停止します。 - このフロー制御動作は、システム変数[`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action)によって制御されます。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index e86e0381fcad6..6faa0c1ca53bc 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -326,7 +326,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ2: 3つのデータセンターに5つのレプリカを2:2:1の割合で配置し、Leaderは3番目のデータセンターに配置しない {#scenario-2-place-five-replicas-in-three-data-centers-in-the-proportion-of-2-2-1-and-the-leader-should-not-be-in-the-third-data-center} -3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、レプリカを対応するデータセンター`label_constraints`から 8 に制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 +3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、 `label_constraints`によってレプリカを対応するデータセンターに制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 ```json [ diff --git a/daily-check.md b/daily-check.md index 80be291715c06..c0973713d7083 100644 --- a/daily-check.md +++ b/daily-check.md @@ -18,7 +18,7 @@ TiDB Dashboardは、TiDBデータベースの運用と保守を簡素化しま ![Instance panel](/media/instance-status-panel.png) - **ステータス**：このインジケーターは、ステータスが正常かどうかを確認するために使用されます。オンラインノードの場合は、このインジケーターは無視できます。 -- **稼働時間**：重要な指標です。2の`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 +- **稼働時間**：重要な指標です。`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 - **バージョン**、**デプロイメントディレクトリ**、 **Gitハッシュ**：これらの指標を確認することで、バージョンやデプロイメントディレクトリの不整合や誤りを回避できます。 ### ホストパネル {#host-panel} diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index 8512682b93462..b5aa4f86b5e04 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -15,7 +15,7 @@ summary: TiDB Dashboardの診断レポートは、異なる時間範囲でのシ ![QPS example](/media/dashboard/dashboard-diagnostics-usage1.png) -`go-ycsb` `2020-03-10 13:24:30`テストの結果は上の画像に示されています。3でQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 +`go-ycsb`圧力テストの結果は上の画像に示されています。`2020-03-10 13:24:30`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 @@ -65,7 +65,7 @@ digest | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8 ![QPS results](/media/dashboard/dashboard-diagnostics-usage3.png) -もう`go-ycsb`圧力テストの結果を上の`2020-03-08 01:46:30`に示します。3でQPSが急激に低下し始め、回復していないことがわかります。 +もう1つの`go-ycsb`圧力テストの結果を上の画像に示します。`2020-03-08 01:46:30`にQPSが急激に低下し始め、回復していないことがわかります。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 @@ -96,7 +96,7 @@ MESSAGE | [expensivequery.go:167] [expensive_query] [cost_time=60.085949605s] [ ![QPS results](/media/dashboard/dashboard-diagnostics-usage5.png) -`go-ycsb` `2020-05-22 22:14:00`テストの結果は上の画像に示されています。3でQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 +`go-ycsb`圧力テストの結果は上の画像に示されています。`2020-05-22 22:14:00`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 0e5a09182bcf2..d798497ec9ca5 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -64,7 +64,7 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。 -`tidb_execute` `tidb_cop`番目のメトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`番目の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。10 `cop`のリクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 +`tidb_execute`には`tidb_cop`メトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。`cop`リクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`の実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 > **Note:** > diff --git a/data-type-string.md b/data-type-string.md index 05af978d4623b..8f37e615ba7d4 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -11,7 +11,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ### CHAR型 {#code-char-code-type} -`CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。2とは異なり、 `VARCHAR`列にデータを挿入する場合、末尾のスペース`CHAR`切り捨てられます。 +`CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。`VARCHAR`型とは異なり、 `CHAR`列にデータを挿入する場合、末尾のスペースは切り捨てられます。 ```sql [NATIONAL] CHAR[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index cc1892edc14cc..94361ea419982 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -176,7 +176,7 @@ JDBCでは通常、以下の2つの処理方法が使用されます。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`から`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 -2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。3 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) `ON`設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 +2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)が`ON`に設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 システム変数[`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) `ON`に設定されている場合、TiDB はクライアントがデータを取得するときにのみデータの一部を読み取ろうとします。これによりメモリ使用量が削減されます。詳細および制限事項については、 [`tidb_enable_lazy_cursor_fetch`システム変数の完全な説明](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)を参照してください。 diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index dad031a4c803e..06181bcf4ef6f 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -131,7 +131,7 @@ DELETE FROM t; ### インデックスのベストプラクティスを追加する {#add-index-best-practices} -TiDBはオンラインのインデックス追加操作をサポートしています。1 [インデックスを追加](/sql-statements/sql-statement-add-index.md)または[インデックスの作成](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 +TiDBはオンラインのインデックス追加操作をサポートしています。[インデックスを追加](/sql-statements/sql-statement-add-index.md)または[インデックスの作成](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index bb19a3490b725..0a11265199d5b 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -58,7 +58,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; +---------------------+------------+-----------+---------------+-----------------------------------------+ ``` -実行プランの`TableFullScan_5`からわかるように、TiDBは`books`番目のテーブルに対してフルテーブルスキャンを実行し、各行について`title`条件を満たすかどうかを確認します。9の`estRows` `TableFullScan_5`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 +実行プランの`TableFullScan_5`からわかるように、TiDBは`books`テーブルに対してフルテーブルスキャンを実行し、各行について`title`が条件を満たすかどうかを確認します。`TableFullScan_5`の`estRows`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 `EXPLAIN`の使用方法の詳細については、 [`EXPLAIN`ウォークスルー](/explain-walkthrough.md)参照してください。 diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 2c292c1649b24..2d13f657a6105 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -61,7 +61,7 @@ BEGIN; START TRANSACTION; ``` -TiDBのデフォルトのトランザクションモードは悲観的です。1 [楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)明示的に指定することもできます。 +TiDBのデフォルトのトランザクションモードは悲観的です。[楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)を明示的に指定することもできます。 ```sql BEGIN OPTIMISTIC; diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index 40bfe15ec8bae..343a843aad345 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -48,7 +48,7 @@ ORDER BY 3 rows in set (0.00 sec) ``` -`a` . `class`および`a` . `stuname`フィールドは`GROUP BY`文で指定されており、選択された列は`a` . `class` 、 `a` . `stuname` 、 `b` . `courscore`です。23 `GROUP BY`条件に含まれない唯一の列である`b` . `courscore`も、 `max()`関数を使用して一意の値で指定されています。このSQL文を曖昧さなく満たす結果は***1つだけ***あり、これを`FULL GROUP BY`構文と呼びます。 +`a` . `class`および`a` . `stuname`フィールドは`GROUP BY`文で指定されており、選択された列は`a` . `class` 、 `a` . `stuname` 、 `b` . `courscore`です。`GROUP BY`条件に含まれない唯一の列である`b` . `courscore`も、 `max()`関数を使用して一意の値で指定されています。このSQL文を曖昧さなく満たす結果は***1つだけ***あり、これを`FULL GROUP BY`構文と呼びます。 反例として、構文`NON-FULL GROUP BY`があります。例えば、この2つのテーブルに次のSQLクエリを記述します (delete `a` . `stuname` in `GROUP BY` )。 diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index d998b339c1257..472416ad6d40e 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -249,7 +249,7 @@ hikari: パラメータの説明は以下の通りです。詳細については、 [HikariCPの公式ドキュメント](https://github.com/brettwooldridge/HikariCP/blob/dev/README.md)を参照してください。 -- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、を参照[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)ください。 +- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してくださいください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 - `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 - `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。graceful [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)使用している場合は、この値が待機時間よりも小さいことを確認してください。 diff --git a/dm/dm-block-allow-table-lists.md b/dm/dm-block-allow-table-lists.md index 0f60f1fa9824e..06e27956a6f6b 100644 --- a/dm/dm-block-allow-table-lists.md +++ b/dm/dm-block-allow-table-lists.md @@ -36,7 +36,7 @@ block-allow-list: # Use black-white-list if the DM version is earlie シンプルなシナリオでは、スキーマとテーブルのマッチングにワイルドカードを使用することをお勧めします。ただし、以下のバージョンの違いにご注意ください。 -- `*` `[]`含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1 `?`だけ使用でき、末尾になければなりません。例えば、 `tbl-name: "t*"`の場合、 `"t*"` `t`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)参照してください。 +- `*` 、 `?` 、 `[]`を含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1つだけ使用でき、末尾になければなりません。例えば、 `tbl-name: "t*"`の場合、 `"t*"`は`t`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)を参照してください。 - 正規表現は`~`文字で始まる必要があります。 @@ -44,8 +44,8 @@ block-allow-list: # Use black-white-list if the DM version is earlie - `do-dbs` : MySQL の[`replicate-do-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-db)と同様に、移行するスキーマのリストを許可します。 - `ignore-dbs` : 移行するスキーマのブロック リスト (MySQL の[`replicate-ignore-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-db)に類似)。 -- `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。4と`tbl-name` `db-name`を指定する必要があります。 -- `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。4と`tbl-name` `db-name`を指定する必要があります。 +- `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 +- `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 上記のパラメータの値が`~`文字で始まる場合、その値の以降の文字は[正規表現](https://golang.org/pkg/regexp/syntax/#hdr-syntax)として扱われます。このパラメータは、スキーマ名またはテーブル名を一致させるために使用できます。 diff --git a/dm/dm-command-line-flags.md b/dm/dm-command-line-flags.md index bb1411fc9d53e..96c7bf97959f1 100644 --- a/dm/dm-command-line-flags.md +++ b/dm/dm-command-line-flags.md @@ -13,13 +13,13 @@ summary: DM のコマンドライン フラグについて学習します。 - クライアントのリクエストを受信するために使用されるDMマスターの外部アドレス - デフォルト値は`"{master-addr}"`です -- オプションフラグ。1の形式をとることができます`"domain-name:port"` +- オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--advertise-peer-urls` {#advertise-peer-urls} - DMマスターノード間の通信用の外部アドレス - デフォルト値は`"{peer-urls}"`です -- オプションフラグ。1の形式をとることができます`"http(s)://domain-name:port"` +- オプションフラグ。`"http(s)://domain-name:port"`の形式をとることができます。 ### `--config` {#config} @@ -87,7 +87,7 @@ summary: DM のコマンドライン フラグについて学習します。 - クライアントのリクエストを受信するために使用されるDMワーカーの外部アドレス - デフォルト値は`"{worker-addr}"`です -- オプションフラグ。1の形式をとることができます`"domain-name:port"` +- オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--config` {#config} diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index c130f9f79aa8f..5751a1e2fceb3 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -29,6 +29,6 @@ summary: このドキュメントでは、データ移行構成ファイルの | コンセプト | 説明 | コンフィグレーションファイル | | :---------- | :-------------------------------------------------------------------------- | :--------------------------------------------------------- | -| `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。1の最大長は`source-id`です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | +| `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。`source-id`の最大長は32です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | | DMマスターID | DMマスターを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | | DMワーカーID | DMワーカーを一意に表す（ `dm-worker.toml`の`worker-addr`のパラメータによって） | `worker-addr` / `dm-worker.toml` | diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 131fe19e62965..654bf60163201 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -146,7 +146,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 3. アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。 -4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid` ～ `true`指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 +4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid`を`true`に指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 例: エラーが発生した場合、 `binlog-name = "mysql-bin.004451"`と`binlog-pos = 2453`をそれぞれ`binlog-name = "mysql-bin.004452"`と`binlog-pos = 4`に更新し、 `binlog-gtid`を`f0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058`に更新します。 diff --git a/dm/dm-table-routing.md b/dm/dm-table-routing.md index 47d12abb39273..d7342e80230d0 100644 --- a/dm/dm-table-routing.md +++ b/dm/dm-table-routing.md @@ -40,7 +40,7 @@ routes: データベース名とテーブル名のマッチングには、正規表現とワイルドカードがサポートされています。シンプルなシナリオでは、スキーマとテーブルのマッチングにワイルドカードを使用することをお勧めします。ただし、以下の点にご注意ください。 -- `*` `[]`含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1 `?`だけ使用でき、末尾になければなりません。例えば、 `table-pattern: "t_*"`の場合、 `"t_*"` `t_`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)参照してください。 +- `*` 、 `?` 、 `[]`を含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1つだけ使用でき、末尾になければなりません。例えば、 `table-pattern: "t_*"`の場合、 `"t_*"`は`t_`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)を参照してください。 - `table-regexp` 、 `schema-regexp` 、 `source-regexp`正規表現のみをサポートし、 `~`記号で始まることはできません。 diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index a93fbe0991e4e..dbb752493a3b6 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -51,7 +51,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して 4. `t3`では、インスタンス 2 からのシャーディング DDL イベントが受信されます。 5. `t4`以降、同期ユニットはインスタンス2からの`schema V2`のDMLイベントも受信します。 -シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`schema V1`から`t2`への`t3`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 +シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`t2`から`t3`までの`schema V1`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 ## 原則 {#principles} diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index abafa293ad40f..418904f363661 100644 --- a/dm/handle-failed-ddl-statements.md +++ b/dm/handle-failed-ddl-statements.md @@ -283,7 +283,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DAN ] } -2. `query-status`コマンドを実行すると、MySQL インスタンス 1 の`shard_db_1` `shard_table_2`と MySQL インスタンス 2 `shard_table_2` `shard_db_2`によって報告されたエラーを確認できます。 +2. `query-status`コマンドを実行すると、MySQL インスタンス 1 の`shard_db_1`.`shard_table_2`テーブルと MySQL インスタンス 2 の`shard_db_2`.`shard_table_2`テーブルによって報告されたエラーを確認できます。 { "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_2` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index 7f4696320975f..c6a0d0efc1f62 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -82,7 +82,7 @@ shard-ddl-lock test ### `shard-ddl-lock unlock` {#shard-ddl-lock-unlock} -このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された`DM-master`ロックのロックを解除するように 1 に積極的に要求します。 +このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的に要求します。 > **Note:** > @@ -153,7 +153,7 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` #### 手動ソリューション {#manual-solution} -アップストリームにインスタンス`MySQL-1` （ `mysql-replica-01` ）と`MySQL-2` （ `mysql-replica-02` ）の2つがあり、 `shard_table_1`に`MySQL-1` `shard_db_1`の`shard_table_2`つ、 `shard_db_2` `MySQL-2`テーブル`shard_db_2` `shard_table_1` 2 `shard_table` `shard_table_2` `shard_db`する必要`shard_db_1`あります。 +アップストリームにインスタンス`MySQL-1` （ `mysql-replica-01` ）と`MySQL-2` （ `mysql-replica-02` ）の2つがあり、 `MySQL-1`に`shard_db_1`の`shard_table_1`と`shard_db_1`の`shard_table_2`の2つのテーブル、 `MySQL-2`に`shard_db_2`の`shard_table_1`と`shard_db_2`の`shard_table_2`の2つのテーブルがあるとします。ここで、これら4つのテーブルをマージして、ダウンストリームTiDBの`shard_db`の`shard_table`テーブルに移行する必要があります。 初期のテーブル構造は次のとおりです。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 75d76ad8ea5d9..88ff214778b6e 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -371,7 +371,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー mysql --host 127.0.0.1 --port 4000 -u root --prompt 'tidb> ' ``` -3. 複製されたデータを確認します。1 [ステップ2](#step-2-prepare-a-source-database-optional)サンプルデータを作成した場合、MySQLソースデータベースからターゲットTiDBデータベースに複製されたテーブル`hello_tidb`が表示されます。 +3. 複製されたデータを確認します。[ステップ2](#step-2-prepare-a-source-database-optional)でサンプルデータを作成した場合、MySQLソースデータベースからターゲットTiDBデータベースに複製されたテーブル`hello_tidb`が表示されます。 ```sql SELECT * FROM hello.hello_tidb; diff --git a/dm/relay-log.md b/dm/relay-log.md index 34432aa7c7766..8f8662cbdfe77 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -276,7 +276,7 @@ purge: purge-relay -s mysql-replica-01 --filename mysql-bin.000001 --sub-dir e4e0e8ab-09cc-11e9-9220-82cc35207219.000002 ``` -- dmctlで次の`purge-relay`コマンドを実行すると、**現在の**（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` ）ディレクトリの`mysql-bin.000001`より前のすべてのリレーログファイル（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`と`e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`にあるすべてのリレーログファイル）が削除されます。13 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`ファイルは保持されます。 +- dmctlで次の`purge-relay`コマンドを実行すると、**現在の**（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` ）ディレクトリの`mysql-bin.000001`より前のすべてのリレーログファイル（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`と`e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`にあるすべてのリレーログファイル）が削除されます。`deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`内のファイルは保持されます。 ```bash purge-relay -s mysql-replica-01 --filename mysql-bin.000001 diff --git a/dynamic-config.md b/dynamic-config.md index d254657886f3f..911fc61509146 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -236,7 +236,7 @@ show warnings; | `cdc.incremental-scan-speed-limit` | 履歴データの増分スキャンの速度の上限 | | `cdc.incremental-scan-concurrency` | 履歴データの同時増分スキャンタスクの最大数 | -上記の表で、プレフィックスが`{db-name}`または`{db-name}.{cf-name}`パラメータはRocksDB関連の設定です。5のオプション値は`db-name` `rocksdb` `raftdb`です。 +上記の表で、`{db-name}`または`{db-name}.{cf-name}`プレフィックスを持つパラメータはRocksDB関連の設定です。`db-name`のオプション値は`rocksdb`と`raftdb`です。 - `db-name`が`rocksdb`の場合、 `cf-name`のオプションの値は`defaultcf` 、 `writecf` 、 `lockcf` 、および`raftcf`です。 - `db-name`が`raftdb`とき、 `cf-name`の値は`defaultcf`になります。 @@ -333,7 +333,7 @@ Query OK, 0 rows affected (0.01 sec) ### TiDB構成を動的に変更する {#modify-tidb-configuration-dynamically} -現在、TiDB構成の変更方法は、TiKVおよびPD構成の変更方法とは異なります。1 [システム変数](/system-variables.md)使用してTiDB構成を変更できます。 +現在、TiDB構成の変更方法は、TiKVおよびPD構成の変更方法とは異なります。[システム変数](/system-variables.md)を使用してTiDB構成を変更できます。 次の例は、 `tidb_slow_log_threshold`変数を使用して`slow-threshold`動的に変更する方法を示しています。 @@ -378,7 +378,7 @@ select @@tidb_slow_log_threshold; 現在、システム変数[`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 に設定できます。 +`tidb_max_tiflash_threads`のデフォルト値は`-1`で、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`を使用すると、 `max_threads`を 10 に設定できます。 ```sql set tidb_max_tiflash_threads = 10; diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 3ecfc18555a5f..c3bf6b57b11dc 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -7,7 +7,7 @@ summary: 機密データを保護するために保存時の暗号化を有効 > **Note:** > -> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。1 [AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 +> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。[AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)を参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 保存時の暗号化とは、データが保存時に暗号化されることを意味します。データベースの場合、この機能はTDE（透過的データ暗号化）とも呼ばれます。これは、転送中の暗号化（TLS）や使用中の暗号化（ほとんど使用されません）とは対照的です。保存時の暗号化はSSDドライブ、ファイルシステム、クラウドベンダーなど、さまざまな方法で実行できますが、TiKVが保存前に暗号化を行うことで、攻撃者がデータにアクセスするにはデータベースへの認証が必要となることを確実にします。例えば、攻撃者が物理マシンにアクセスできたとしても、ディスク上のファイルをコピーするだけではデータにアクセスできません。 @@ -47,7 +47,7 @@ BRは、S3へのデータバックアップ時にS3サーバー側暗号化（SS ### ログ記録 {#logging} -TiKV、TiDB、およびPD情報ログには、デバッグ用のユーザーデータが含まれる場合があります。情報ログとその中に含まれるデータは暗号化されません。1 [ログ編集](/log-redaction.md)有効にすることを推奨します。 +TiKV、TiDB、およびPD情報ログには、デバッグ用のユーザーデータが含まれる場合があります。情報ログとその中に含まれるデータは暗号化されません。[ログ編集](/log-redaction.md)を有効にすることを推奨します。 ## 保存時の TiKV 暗号化 {#tikv-encryption-at-rest} @@ -258,7 +258,7 @@ TiKVをGrafanaでデプロイしている場合は、保存時の暗号化を監 - 暗号化メタファイル サイズ: 暗号化メタデータ ファイルのサイズ。 - 読み取り/書き込み暗号化メタ期間: 暗号化のメタデータを操作するための追加のオーバーヘッド。 -デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。3 [TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 +デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。[TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 ### TiKVバージョン間の互換性 {#compatibility-between-tikv-versions} diff --git a/error-codes.md b/error-codes.md index 01f4113a20504..6789e91850694 100644 --- a/error-codes.md +++ b/error-codes.md @@ -481,7 +481,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8249 - リソースグループが存在しません。このエラーは、存在しないリソースグループを変更またはバインドした場合に返されます。1 [リソースグループを作成する](/tidb-resource-control-ru-groups.md#create-a-resource-group)参照してください。 + リソースグループが存在しません。このエラーは、存在しないリソースグループを変更またはバインドした場合に返されます。[リソースグループを作成する](/tidb-resource-control-ru-groups.md#create-a-resource-group)を参照してください。 - エラー番号: 8250 @@ -505,11 +505,11 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8253 - クエリはランナウェイクエリの条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)参照してください。 + クエリはランナウェイクエリの条件を満たしているため停止します。[ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 - エラー番号: 8254 - クエリは、ランナウェイクエリの隔離監視条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)参照してください。 + クエリは、ランナウェイクエリの隔離監視条件を満たしているため停止します。[ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 - エラー番号: 8260 @@ -571,7 +571,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 完全なエラーメッセージ: `ERROR 9006 (HY000): GC life time is shorter than transaction duration` - 間隔`GC Life Time`は短すぎます。長いトランザクションによって読み取られるはずだったデータが削除される可能性があります。3 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)次のコマンドで調整できます。 + 間隔`GC Life Time`は短すぎます。長いトランザクションによって読み取られるはずだったデータが削除される可能性があります。[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)は次のコマンドで調整できます。 ```sql SET GLOBAL tidb_gc_life_time = '30m'; diff --git a/explain-index-merge.md b/explain-index-merge.md index 5d20e97ab8e36..1ffb643b7a65a 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -48,7 +48,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t) */ * FROM t WHERE a > 1 OR b > 1; 上記のクエリでは、オプティマイザはテーブルにアクセスするためにユニオン型のインデックスマージを選択します。インデックスマージにより、オプティマイザはテーブルごとに複数のインデックスを使用し、各インデックスから返された結果をマージして、上記の出力の後者の実行プランを生成することができます。 -出力において、 `IndexMerge_8`演算子の`operator info`の`type: union`情報は、この演算子がユニオン型インデックスマージであることを示しています。この演算子には3つの子ノードがあります。7と`IndexRangeScan_6` `IndexRangeScan_5`範囲に従って条件を満たす`RowID`をスキャンし、その後、 `TableRowIDScan_7`演算子はこれらの`RowID`に基づいて条件を満たすすべてのデータを正確に読み取ります。 +出力において、 `IndexMerge_8`演算子の`operator info`の`type: union`情報は、この演算子がユニオン型インデックスマージであることを示しています。この演算子には3つの子ノードがあります。`IndexRangeScan_5`と`IndexRangeScan_6`は範囲に従って条件を満たす`RowID`をスキャンし、その後、 `TableRowIDScan_7`演算子はこれらの`RowID`に基づいて条件を満たすすべてのデータを正確に読み取ります。 `IndexRangeScan` / `TableRangeScan`ように特定のデータ範囲に対して実行されるスキャン演算の場合、結果の`operator info`列には、 `IndexFullScan` / `TableFullScan`のような他のスキャン演算と比較して、スキャン範囲に関する追加情報が含まれます。上記の例では、 `IndexRangeScan_5`演算子の`range:(1,+inf]` 、演算子が 1 から正の無限大までデータをスキャンすることを示しています。 diff --git a/explain-overview.md b/explain-overview.md index 349b558a121d3..b2ac2bd250a8e 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -141,8 +141,8 @@ TiDBは、TiKV/ TiFlashからスキャンされたデータまたは計算結果 - **TableReader** : TiKV の`TableFullScan`や`TableRangeScan`の基礎となる演算子によって取得されたデータを集計します。 - **IndexReader** : TiKV の`IndexFullScan`や`IndexRangeScan`の基礎となる演算子によって取得されたデータを集計します。 -- **IndexLookUp** : まず、 `Build`側でスキャンされたRowID（TiKV内）を集計します。次に、 `Probe`側でこれらのRowIDに基づいてTiKVからデータを正確に読み取ります。6 `Build`には`IndexFullScan`や`IndexRangeScan`などの演算子があり、 `Probe`側には`TableRowIDScan`演算子があります。 -- **IndexMerge** : `IndexLookUp`と同様です。4 `IndexMerge` `IndexLookupReader`の拡張と見なすことができます。8 `IndexMerge`複数のインデックスの同時読み取りをサポートします。10 は`Build`あり、 `Probe`は1つです。14 の実行プロセスは`IndexMerge` `IndexLookUp`同じです。 +- **IndexLookUp** : まず、 `Build`側でスキャンされたRowID（TiKV内）を集計します。次に、 `Probe`側でこれらのRowIDに基づいてTiKVからデータを正確に読み取ります。`Build`側には`IndexFullScan`や`IndexRangeScan`などの演算子があり、 `Probe`側には`TableRowIDScan`演算子があります。 +- **IndexMerge** : `IndexLookUp`と同様です。4 `IndexMerge` `IndexLookupReader`の拡張と見なすことができます。8 `IndexMerge`複数のインデックスの同時読み取りをサポートします。`Build`は多数あり、 `Probe`は1つです。`IndexMerge`の実行プロセスは`IndexLookUp`と同じです。 構造はツリー構造のように見えますが、クエリの実行において子ノードが親ノードより先に完了している必要は必ずしもありません。TiDBはクエリ内並列処理をサポートしているため、より正確な表現は、子ノードが親ノード*に流れ込む*というものです。親ノード、子ノード、兄弟ノードの演算子によって、クエリの一部が並列実行される可能性*があります*。 diff --git a/explain-partitions.md b/explain-partitions.md index ef2a8f8515ed0..ba65217d73389 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -5,7 +5,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行プ # パーティションを使用したステートメントの説明 {#explain-statements-using-partitions} -`EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。3 [パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 +`EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。[パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 このドキュメントで使用されているサンプル データ: diff --git a/explain-walkthrough.md b/explain-walkthrough.md index a9c5823245829..422c76146baa8 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -39,9 +39,9 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 子演算子`└─TableFullScan_18`から戻ると、その実行プロセスは次のようになります。これは現時点では最適ではありません。 1. コプロセッサ（TiKV）は、 `trips`テーブル全体を`TableFullScan`演算として読み取ります。その後、読み取った行をTiKV内の`Selection_19`の演算子に渡します。 -2. 述語`WHERE start_date BETWEEN ..`演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18` `stats:pseudo`表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。11 `ANALYZE TABLE trips`実行して統計情報を収集すると、統計の精度が向上することが期待されます。 -3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、演算子 3 も TiKV 内にあります ( `cop[tikv]` )。TiKV コプロセッサは、MySQL の組み込み関数を多数実行できます。そのうちの 1 つが`count`です。 -4. `StreamAgg_9`の結果は、TiDBサーバー内にある`TableReader_21`演算子（ `root`のタスク）に送信されます。この演算子の`estRows`列の値は`1`です。これは、演算子がアクセス対象のTiKVリージョンごとに1行ずつ受け取ることを意味します。これらのリクエストの詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)参照してください。 +2. 述語`WHERE start_date BETWEEN ..`は演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18`には`stats:pseudo`と表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。`ANALYZE TABLE trips`を実行して統計情報を収集すると、統計の精度が向上することが期待されます。 +3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、この演算子も TiKV 内にあります ( `cop[tikv]` )。TiKV コプロセッサは、MySQL の組み込み関数を多数実行できます。そのうちの 1 つが`count`です。 +4. `StreamAgg_9`の結果は、TiDBサーバー内にある`TableReader_21`演算子（ `root`のタスク）に送信されます。この演算子の`estRows`列の値は`1`です。これは、演算子がアクセス対象のTiKVリージョンごとに1行ずつ受け取ることを意味します。これらのリクエストの詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を参照してください。 5. 次に、演算子`StreamAgg_20`は演算子`└─TableReader_21`の各行に関数`count`適用します。これは演算子[`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)からもわかるように、約 56 行になります。これはルート演算子であるため、結果をクライアントに返します。 > **Note:** @@ -95,7 +95,7 @@ Query OK, 0 rows affected (10.22 sec) `ANALYZE TABLE`実行すると、演算子`└─TableFullScan_18`推定行数が正確であり、演算子`└─Selection_19`の推定行数も大幅に近づいたことがわかります。上記の 2 つのケースでは、実行プラン（TiDB がこのクエリを実行するために使用する演算子セット）は変更されていませんが、統計情報が古くなっているために、最適ではないプランが頻繁に発生します。 -`ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。5 [`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 +`ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。[`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 ```sql SHOW STATS_HEALTHY; diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md index c4461b0b7c205..fe84274c75c49 100644 --- a/exporting-grafana-snapshots.md +++ b/exporting-grafana-snapshots.md @@ -14,7 +14,7 @@ summary: Grafana ダッシュボードのスナップショットをエクスポ > > 現在、MetricsToolはGrafana v6.xxでのみ使用できます。 -メトリクスデータはトラブルシューティングにおいて重要です。リモートアシスタンスを依頼した場合、サポートスタッフが問題を診断するためにGrafanaダッシュボードを確認する必要がある場合があります。1 [メトリクスツール](https://metricstool.pingcap.net/) 、Grafanaダッシュボードのスナップショットをローカルファイルとしてエクスポートし、可視化するのに役立ちます。これらのスナップショットを外部の担当者と共有することで、Grafanaサーバー上の他の機密情報へのアクセスを外部に漏らすことなく、グラフを正確に読み取ることができます。 +メトリクスデータはトラブルシューティングにおいて重要です。リモートアシスタンスを依頼した場合、サポートスタッフが問題を診断するためにGrafanaダッシュボードを確認する必要がある場合があります。[メトリクスツール](https://metricstool.pingcap.net/)は、Grafanaダッシュボードのスナップショットをローカルファイルとしてエクスポートし、可視化するのに役立ちます。これらのスナップショットを外部の担当者と共有することで、Grafanaサーバー上の他の機密情報へのアクセスを外部に漏らすことなく、グラフを正確に読み取ることができます。 ## 使用法 {#usage} diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 072ff14e2432a..8b4d351db6024 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -269,7 +269,7 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table [テーブルフィルター](/table-filter.md#syntax)設定しても、 **BR は次のシステム テーブルを復元しないこと**に注意してください。 -- 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。3 [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照してください。 +- 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。[統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照してください。 - システム変数テーブル（ `mysql.tidb` `mysql.global_variables` - [その他のシステムテーブル](https://github.com/pingcap/tidb/blob/release-8.5/br/pkg/restore/snap_client/systable_restore.go#L31) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 63482d8ba1d96..f0872a2c7e525 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -35,7 +35,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ## インストールと展開 {#installation-and-deployment} -本番環境では、 [TiUP](/tiup/tiup-overview.md)使用してTiDBクラスタをデプロイすることをお勧めします。3 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +本番環境では、 [TiUP](/tiup/tiup-overview.md)を使用してTiDBクラスタをデプロイすることをお勧めします。[TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 ### TiKV/PD 用に変更されたtoml構成が有効にならないのはなぜですか? {#why-the-modified-code-toml-code-configuration-for-tikv-pd-does-not-take-effect} diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 027d18f160ff0..3658ffc5bb940 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -140,7 +140,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす ### transaction too largeエラーメッセージが表示されます {#the-error-message-code-transaction-too-large-code-is-displayed} -基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。1 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 +基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。[`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 分散トランザクションは2相コミットを必要とし、最下層でRaftレプリケーションを実行します。トランザクションが非常に大きい場合、コミットプロセスは非常に遅くなり、書き込み競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不要なパフォーマンスの低下につながります。これらの問題を回避するため、デフォルトでは、トランザクション内のキーと値のエントリの合計サイズを100MB以下に制限しています。より大きなトランザクションが必要な場合は、TiDB設定ファイルの値`txn-total-size-limit`変更してください。この設定項目の最大値は10GBです。実際の制限は、マシンの物理メモリにも影響されます。 @@ -152,7 +152,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do ### TiDB はデータを削除した後すぐにスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data} -`DELETE` `TRUNCATE`操作`DROP`いずれもデータを即時に解放しません。7と`TRUNCATE` `DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。11 `DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`実行されると、領域は再利用されます。 +`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`が実行されると、領域は再利用されます。 ### データをロードするときに、ターゲット テーブルで DDL 操作を実行できますか? {#can-i-execute-ddl-operations-on-the-target-table-when-loading-data} @@ -170,7 +170,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do 大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`使用をお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`ループ終了条件として使用することで、トランザクションサイズの制限を超えないようにします。ビジネスフィルタリングロジックを満たすことを前提として、強力なフィルターインデックス列を追加するか、 `id >= 5000*n+m and id < 5000*(n+1)+m`のように主キーを直接使用して範囲を選択することをお勧めします。 -一度に削除する必要があるデータの量が非常に多い場合、このループメソッドは削除処理が後方に移動するにつれて速度が低下します。前のデータを削除した後、多くの削除フラグが短期間残り（その後、すべてガベージコレクションによって処理されます）、後続のDelete文に影響を与えます。可能であれば、Where条件を絞り込むことをお勧めします。1 [詳細はTiDBベストプラクティスをご覧ください](https://www.pingcap.com/blog/tidb-best-practice/#write)参照してください。 +一度に削除する必要があるデータの量が非常に多い場合、このループメソッドは削除処理が後方に移動するにつれて速度が低下します。前のデータを削除した後、多くの削除フラグが短期間残り（その後、すべてガベージコレクションによって処理されます）、後続のDelete文に影響を与えます。可能であれば、Where条件を絞り込むことをお勧めします。[詳細はTiDBベストプラクティスをご覧ください](https://www.pingcap.com/blog/tidb-best-practice/#write)を参照してください。 ### TiDB のデータ読み込み速度を向上させるにはどうすればよいでしょうか? {#how-to-improve-the-data-loading-speed-in-tidb} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index 90db954e13360..f2a72cbdc6130 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -180,7 +180,7 @@ Sqoopでは、 `--batch`各バッチで100文をコミットすることを意 ## TiDB はデータを削除した直後にスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data} -`DELETE` `TRUNCATE`操作はいずれもデータ`DROP` `TRUNCATE` `DROP`は、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。11 `DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。 +`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。 ## データを削除するとクエリ速度が遅くなるのはなぜですか? {#why-does-the-query-speed-get-slow-after-data-is-deleted} @@ -413,7 +413,7 @@ SELECT 'café' = 'cafe' COLLATE utf8mb4_0900_ai_ci; -- Returns 1 (TRUE) 推奨事項: -- ハードウェア構成を改善してください。1 [TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)参照してください。 +- ハードウェア構成を改善してください。[TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)を参照してください。 - 同時実行性を向上させます。デフォルト値は10です。50に上げて試してみることもできますが、通常はデフォルト値の2～4倍の改善が見られます。 - 大量のデータの場合は`count`をテストします。 - TiKV設定を最適化します。1と[TiKVメモリパフォーマンスの調整](/tune-tikv-memory-performance.md) [TiKVスレッドのパフォーマンスを調整する](/tune-tikv-thread-performance.md)参照してください。 diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index 250fafed4f2c1..d79460d058afb 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -49,7 +49,7 @@ TiDBクラスタは、TiDBサーバー、PD（Placement Driver）サーバー、 はい。TiDB は、単一の場所に少数のノードがある場合でも、多数の[複数のデータセンターにまたがるノード](/multi-data-centers-in-one-city-deployment.md)がある場合でも、クラスター全体にトランザクションを分散します。 -GoogleのPercolatorに着想を得たTiDBのトランザクションモデルは、主に2フェーズコミットプロトコルをベースに、実用的な最適化が施されています。このモデルは、タイムスタンプアロケータを利用して各トランザクションに単調増加するタイムスタンプを割り当てることで、競合を検出します。1 [PD](/tidb-architecture.md#placement-driver-pd-server) TiDBクラスタ内でタイムスタンプアロケータとして機能します。 +GoogleのPercolatorに着想を得たTiDBのトランザクションモデルは、主に2フェーズコミットプロトコルをベースに、実用的な最適化が施されています。このモデルは、タイムスタンプアロケータを利用して各トランザクションに単調増加するタイムスタンプを割り当てることで、競合を検出します。[PD](/tidb-architecture.md#placement-driver-pd-server)は、TiDBクラスタ内でタイムスタンプアロケータとして機能します。 ### TiDB を操作するためにどのプログラミング言語を使用できますか? {#what-programming-language-can-i-use-to-work-with-tidb} diff --git a/follower-read.md b/follower-read.md index ef8470a19d85b..940374b0262b8 100644 --- a/follower-read.md +++ b/follower-read.md @@ -15,7 +15,7 @@ Follower Read を実行する際、TiDBはトポロジ情報に基づいて適 -Follower Read を実行する際、TiDB はトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDB はラベル`zone`を用いてローカルレプリカを識別します。TiDB ノードのラベル`zone`がターゲット TiKV ノードのラベル 3 と同じ場合、TiDB はそのレプリカをローカルレプリカと見なします。ラベル`zone`はTiDB Cloudで自動的に設定されます。 +Follower Read を実行する際、TiDB はトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDB はラベル`zone`を用いてローカルレプリカを識別します。TiDB ノードのラベル`zone`がターゲット TiKV ノードのラベルと同じ場合、TiDB はそのレプリカをローカルレプリカと見なします。ラベル`zone`はTiDB Cloudで自動的に設定されます。 diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index 5336e0f6624bb..5b04f381bfc68 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -34,7 +34,7 @@ summary: TiDB でサポートされている集計関数について学習しま - `APPROX_PERCENTILE(expr, constant_integer_expr)` - この関数は`expr`のパーセンタイルを返します。引数`constant_integer_expr`は、 5 から`[1,100]`の範囲の定数整数であるパーセンタイル値を示します。パーセンタイル P k （ `k`はパーセンタイルを表します）は、データセット内に P k以下の値が少なくとも`k%`あることを示します。 + この関数は`expr`のパーセンタイルを返します。引数`constant_integer_expr`は、 `[1,100]`の範囲の定数整数であるパーセンタイル値を示します。パーセンタイル P k （ `k`はパーセンタイルを表します）は、データセット内に P k以下の値が少なくとも`k%`あることを示します。 この関数は、 `expr`の戻り値の型として[数値型](/data-type-numeric.md)と[日付と時刻の種類](/data-type-date-and-time.md)をサポートします。その他の戻り値の型については、 `APPROX_PERCENTILE` `NULL`を返します。 diff --git a/functions-and-operators/functions-and-operators-overview.md b/functions-and-operators/functions-and-operators-overview.md index 1185c94a5eec5..1fe0349e6bcd9 100644 --- a/functions-and-operators/functions-and-operators-overview.md +++ b/functions-and-operators/functions-and-operators-overview.md @@ -5,7 +5,7 @@ summary: 関数と演算子の使い方を学びます。 # 関数と演算子のリファレンス {#function-and-operator-reference} -TiDBの関数と演算子の使い方はMySQLと似ています。1 [MySQLの関数と演算子](https://dev.mysql.com/doc/refman/8.0/en/functions.html)参照してください。 +TiDBの関数と演算子の使い方はMySQLと似ています。[MySQLの関数と演算子](https://dev.mysql.com/doc/refman/8.0/en/functions.html)を参照してください。 SQL 文では、 [`SELECT`](/sql-statements/sql-statement-select.md)文の`ORDER BY`と`HAVING`句、 [`SELECT`](/sql-statements/sql-statement-select.md) / [`DELETE`](/sql-statements/sql-statement-delete.md) / [`UPDATE`](/sql-statements/sql-statement-update.md)文の`WHERE`句、 [`SET`](/sql-statements/sql-statement-set-variable.md)文で式を使用できます。 diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 2bfaa2988f863..91e090395cdf6 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -124,7 +124,7 @@ SELECT year, month, SUM(profit) AS profit FROM bank GROUP BY year, month WITH RO 3 rows in set (0.02 sec) ``` -`GROUP BY`の列にネイティブ`NULL`値が含まれている場合、 `WITH ROLLUP`の集計結果がクエリ結果を誤解させる可能性があることに注意してください。この問題に対処するには、 `GROUPING()`関数を使用して、ネイティブ`NULL`値と`WITH ROLLUP`によって生成された`NULL`値を区別できます。この関数はグループ化式をパラメータとして受け取り、現在の結果でグループ化式が集計されているかどうかを示す`0`または`1`返します。19 `1`集計されていることを表し、 `0`集計されていないことを表します。 +`GROUP BY`の列にネイティブ`NULL`値が含まれている場合、 `WITH ROLLUP`の集計結果がクエリ結果を誤解させる可能性があることに注意してください。この問題に対処するには、 `GROUPING()`関数を使用して、ネイティブ`NULL`値と`WITH ROLLUP`によって生成された`NULL`値を区別できます。この関数はグループ化式をパラメータとして受け取り、現在の結果でグループ化式が集計されているかどうかを示す`0`または`1`を返します。`1`は集計されていることを表し、 `0`は集計されていないことを表します。 次の例は、 `GROUPING()`関数の使用方法を示しています。 diff --git a/functions-and-operators/json-functions.md b/functions-and-operators/json-functions.md index cb128a98d9522..191d32079f1b8 100644 --- a/functions-and-operators/json-functions.md +++ b/functions-and-operators/json-functions.md @@ -22,7 +22,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを | [JSON_CONTAINS()](/functions-and-operators/json-functions/json-functions-search.md#json_contains) | 指定された候補JSONドキュメントがターゲットJSONドキュメント内に含まれているかどうかを1または0を返すことで示します。 | | [JSON_CONTAINS_PATH()](/functions-and-operators/json-functions/json-functions-search.md#json_contains_path) | JSONドキュメントに指定されたパスのデータが含まれているかどうかを示す0または1を返します。 | | [JSON_EXTRACT()](/functions-and-operators/json-functions/json-functions-search.md#json_extract) | `path`引数に一致するドキュメントの部分から選択されたJSONドキュメントからデータを返します。 | -| [->](/functions-and-operators/json-functions/json-functions-search.md#-) | 評価パスの後のJSON列から値を返します。1の別名です`JSON_EXTRACT(doc, path_literal)` | +| [->](/functions-and-operators/json-functions/json-functions-search.md#-) | 評価パスの後のJSON列から値を返します。`JSON_EXTRACT(doc, path_literal)`の別名です。 | | [->>](/functions-and-operators/json-functions/json-functions-search.md#--1) | 評価パスの後のJSON列から値を返し、結果を引用符で囲まない`JSON_UNQUOTE(JSON_EXTRACT(doc, path_literal))`の別名。 | | [JSON_KEYS()](/functions-and-operators/json-functions/json-functions-search.md#json_keys) | JSONオブジェクトの最上位レベルの値からキーをJSON配列として返します。パス引数が指定されている場合は、選択したパスから最上位レベルのキーを返します。 | | [JSON_SEARCH()](/functions-and-operators/json-functions/json-functions-search.md#json_search) | JSONドキュメントで文字列の1つまたはすべてに一致するものを検索する | diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index bf33fc04d5a2b..b08fc05b51790 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -537,8 +537,8 @@ SELECT FIND_IN_SET('Go', 'COBOL,BASIC,Rust,Go,Java,Fortran'); 引数: - `X` : 書式設定する数値。数値、数値文字列、または科学的記数法の数値を指定できます。 -- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。8 `X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。 -- `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。 +- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。`X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。 +- `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`の場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。 動作: @@ -2229,7 +2229,7 @@ SELECT UPPER('bigdata') AS result_upper, UPPER(null) AS result_null; WEIGHT_STRING(str [AS {CHAR|BINARY}(N)]) ``` -- `str` : 入力文字列式。2、4、6 `TEXT`の非バイナリ文字列の場合、戻り値`VARCHAR`は文字列の照合順序重みが含まれます。8、10、12 `BLOB`の`BINARY` `VARBINARY`列の場合、戻り値`CHAR`入力値と同じになります。 +- `str` : 入力文字列式。`CHAR` 、 `VARCHAR` 、 `TEXT`などの非バイナリ文字列の場合、戻り値には文字列の照合順序重みが含まれます。`BINARY` 、 `VARBINARY` 、 `BLOB`などのバイナリ文字列の場合、戻り値は入力値と同じになります。 - `AS {CHAR|BINARY}(N)` : 出力のタイプと長さを指定するために使用されるオプションのパラメータ。2 `CHAR`文字データ型を表し、 `BINARY`バイナリ データ型を表します。6 `N`出力長を指定します。これは 1 以上の整数です。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 168be1a46d220..bd62662535361 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -59,7 +59,7 @@ summary: TiDB 固有の関数の使用法について学習します。 ## 現在のリソースグループ {#current-resource-group} -`CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。3 [リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 +`CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。[リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 セッションが確立されると、TiDB はログインユーザーがデフォルトでバインドされているリソースグループにセッションをバインドします。ユーザーがどのリソースグループにもバインドされていない場合、セッションは`default`リソースグループにバインドされます。セッションが確立されると、ユーザーのバインドされているリソースグループが[ユーザーにバインドされたリソースグループを変更する](/sql-statements/sql-statement-alter-user.md#modify-basic-user-information)で変更されても、バインドされているリソースグループはデフォルトで変更されません。現在のセッションのバインドされているリソースグループを変更するには、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)使用します。 @@ -264,7 +264,7 @@ ORDER BY ## TIDB_デコード_プラン {#tidb-decode-plan} -TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。1関数`TIDB_DECODE_PLAN()` 、エンコードされたプランを人間が読める形式にデコードするために使用されます。 +TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。`TIDB_DECODE_PLAN()`関数は、エンコードされたプランを人間が読める形式にデコードするために使用されます。 この関数は、ステートメント実行時にプランが取得されるため便利です。1 `EXPLAIN`ステートメントを再実行すると、データの分布と統計が時間の経過とともに変化するため、異なる結果が生成される可能性があります。 @@ -378,7 +378,7 @@ SELECT TIDB_IS_DDL_OWNER(); ## TIDB_PARSE_TSO {#tidb-parse-tso} -`TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。3 [TSO](/tso.md) Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 +`TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。[TSO](/tso.md)は Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 TSO は次の 2 つの部分で構成される数値です。 diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md index 9e2e1bda5e9b2..1061d1aa9093e 100644 --- a/functions-and-operators/window-functions.md +++ b/functions-and-operators/window-functions.md @@ -65,7 +65,7 @@ FROM ## `DENSE_RANK()` {#dense-rank} -`DENSE_RANK()`関数は現在行の順位を返します。3 [`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 +`DENSE_RANK()`関数は現在行の順位を返します。[`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 ```sql SELECT diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index 5884b0e49ffc7..10d6a974e9939 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -26,7 +26,7 @@ summary: GC 構成パラメータについて学習します。 -TiKVはGC I/O制限をサポートしています。1を設定すると、GCワーカーの`gc.max-write-bytes-per-sec`秒あたりの書き込み回数を制限し、通常のリクエストへの影響を軽減できます。 +TiKVはGC I/O制限をサポートしています。`gc.max-write-bytes-per-sec`を設定すると、GCワーカーの1秒あたりの書き込み量を制限し、通常のリクエストへの影響を軽減できます。 `0`この機能を無効にすることを示します。 diff --git a/global-indexes.md b/global-indexes.md index 587ed3a045ff6..13204ef8d43a4 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -43,7 +43,7 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 - **v7.6.0より前**：TiDBはパーティションテーブル上のローカルインデックスのみをサポートします。つまり、パーティションテーブルの一意キーには、パーティション式内のすべての列を含める必要があります。パーティションキーを使用しないクエリはすべてのパーティションをスキャンする必要があり、クエリパフォーマンスが低下します。 - **v7.6.0** : グローバルインデックスを有効にするシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)が導入されました。ただし、この機能は現時点ではまだ開発中であり、本番での使用は推奨されません。 - **v8.3.0** : グローバルインデックスが実験的機能としてリリースされました。インデックスを定義する際に`GLOBAL`キーワードを使用することで、明示的にグローバルインデックスを作成できます。 -- **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数 4 は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 +- **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 - **v8.5.0** : グローバル インデックスは、パーティション式のすべての列を含めることをサポートします。 ## グローバルインデックスとローカルインデックス {#global-indexes-vs-local-indexes} diff --git a/glossary.md b/glossary.md index 2bf4423b4f092..da92d58ff5b69 100644 --- a/glossary.md +++ b/glossary.md @@ -143,7 +143,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### グローバルトランザクション識別子（GTID） {#global-transaction-identifiers-gtids} -グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。1 [データ移行（DM）](/dm/dm-overview.md) 、これらのIDを使用して一貫性のあるレプリケーションを保証します。 +グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。[データ移行（DM）](/dm/dm-overview.md)は、これらのIDを使用して一貫性のあるレプリケーションを保証します。 ## H {#a-id-h-class-letter-href-h-h-a} @@ -339,7 +339,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ ### セキュリティ強化モード（SEM） {#security-enhanced-mode-sem} -セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。1 [セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 +セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。[セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のようなシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 詳細については、 [システム変数に関するドキュメント - `tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)参照してください。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 0400ea802201e..6769e350edd4a 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -24,7 +24,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - クライアントのネットワーク要求がTiDBに送信されてから、TiDBがそれを実行した後にクライアントに返される`COM_STMT_FETCH`の時間。通常、クライアント要求はSQL文の形式で送信されますが、 `COM_PING` `COM_SEND_LONG_DATA`のコマンドの実行時間も含まれる場合があります`COM_SLEEP` - TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ような複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 - 1秒あたりのコマンド数: コマンド実行結果の成功または失敗に応じて分類される、TiDBによって1秒あたりに処理されるコマンドの数 -- QPS: すべての TiDB インスタンスで`SELECT`秒あたりに実行される SQL ステートメントの数。1、3、5 `UPDATE`およびその他のタイプのステートメントに従ってカウントされます`INSERT` +- QPS: すべての TiDB インスタンスで秒あたりに実行される SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`およびその他のタイプのステートメントに従ってカウントされます - インスタンス別CPS: コマンド実行結果の成功または失敗に応じて分類された各TiDBインスタンスのコマンド統計 - 失敗したクエリOPM：各TiDBインスタンスで1分間にSQL文を実行した際に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 - スロークエリ：スロークエリの処理時間の統計（スロークエリ全体の時間コスト、コプロセッサーの時間コスト、コプロセッサーのスケジューリングの待機時間）。スロークエリは、内部SQL文と一般SQL文に分類されます。 diff --git a/information-schema/information-schema-character-sets.md b/information-schema/information-schema-character-sets.md index bb83d24d15968..6d5797771e7a2 100644 --- a/information-schema/information-schema-character-sets.md +++ b/information-schema/information-schema-character-sets.md @@ -24,7 +24,7 @@ DESC CHARACTER_SETS; +----------------------+-------------+------+------+---------+-------+ 4 rows in set (0.00 sec) -`CHARACTER_SETS`テーブルをビュー: +`CHARACTER_SETS`テーブルを確認します: ```sql SELECT * FROM `CHARACTER_SETS`; diff --git a/information-schema/information-schema-collation-character-set-applicability.md b/information-schema/information-schema-collation-character-set-applicability.md index 701ffd3722a57..5d293cef45fea 100644 --- a/information-schema/information-schema-collation-character-set-applicability.md +++ b/information-schema/information-schema-collation-character-set-applicability.md @@ -24,7 +24,7 @@ DESC COLLATION_CHARACTER_SET_APPLICABILITY; 2 rows in set (0.00 sec) ``` -`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルの`utf8mb4`の文字セットの照合順序マッピングをビュー。 +`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルの`utf8mb4`の文字セットの照合順序マッピングを確認します。 ```sql SELECT * FROM COLLATION_CHARACTER_SET_APPLICABILITY WHERE character_set_name='utf8mb4'; diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index 3bd5a9d159dbc..e70dd7979147b 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -26,7 +26,7 @@ DESC data_lock_waits; `DATA_LOCK_WAITS`テーブル内の各列フィールドの意味は次のとおりです。 - `KEY` : ロックを待機しているキー（16 進形式）。 -- `KEY_INFO` : `KEY`の詳細情報。4 [キー情報](#key_info)セクションを参照してください。 +- `KEY_INFO` : `KEY`の詳細情報。[キー情報](#key_info)セクションを参照してください。 - `TRX_ID` : ロックを待機しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `CURRENT_HOLDING_TRX_ID` : 現在ロックを保持しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `SQL_DIGEST` : ロック待機中のトランザクションで現在ブロックされている SQL ステートメントのダイジェスト。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 5ffe481af7835..66f07556ce805 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -41,7 +41,7 @@ DESC deadlocks; - `CURRENT_SQL_DIGEST` : ロックを取得するトランザクションで現在実行されている SQL ステートメントのダイジェスト。 - `CURRENT_SQL_DIGEST_TEXT` : ロックを取得するトランザクションで現在実行されている SQL ステートメントの正規化された形式。 - `KEY` : トランザクションがロックしようとしたブロックされたキー。このフィールドの値は16進文字列で表示されます。 -- `KEY_INFO` : `KEY`の詳細情報。4 [`KEY_INFO`](#key_info)セクションを参照してください。 +- `KEY_INFO` : `KEY`の詳細情報。[`KEY_INFO`](#key_info)セクションを参照してください。 - `TRX_HOLDING_LOCK` : 現在キーのロックを保持し、ブロックを引き起こしているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 1d1b5a745a506..69f700f87598e 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -179,7 +179,7 @@ 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 の 0 の 105 倍になります。 +- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 上記の結果から、期間t2のコプロセッサーリクエストが期間t1よりもはるかに多いことがわかります。これによりTiKVコプロセッサーが過負荷になり、 `cop task`待機状態になります。期間t2に大規模なクエリが発生し、負荷がさらに増加している可能性があります。 diff --git a/information-schema/information-schema-sequences.md b/information-schema/information-schema-sequences.md index 6f086c197a868..940f535f93dc0 100644 --- a/information-schema/information-schema-sequences.md +++ b/information-schema/information-schema-sequences.md @@ -5,7 +5,7 @@ summary: SEQUENCES` INFORMATION_SCHEMA テーブルについて学習します # シーケンス {#sequences} -`SEQUENCES`のテーブルはシーケンスに関する情報を提供します。3 [シーケンス機能](/sql-statements/sql-statement-create-sequence.md)テーブルは、MariaDB の同様の機能をモデルにしています。 +`SEQUENCES`のテーブルはシーケンスに関する情報を提供します。[シーケンス機能](/sql-statements/sql-statement-create-sequence.md)は、MariaDB の同様の機能をモデルにしています。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-tidb-servers-info.md b/information-schema/information-schema-tidb-servers-info.md index c8f2006440b47..61ee5ffe7da46 100644 --- a/information-schema/information-schema-tidb-servers-info.md +++ b/information-schema/information-schema-tidb-servers-info.md @@ -35,7 +35,7 @@ DESC tidb_servers_info; 9 rows in set (0.00 sec) ``` -`TIDB_SERVERS_INFO`テーブルをビュー。 +`TIDB_SERVERS_INFO`テーブルを確認します。 ```sql SELECT * FROM TIDB_SERVERS_INFO\G diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index f924245610aab..aa254620a05ae 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -52,7 +52,7 @@ DESC TIDB_TRX; - `SESSION_ID` : このトランザクションが属するセッションの ID。 - `USER` : トランザクションを実行するユーザーの名前。 - `DB` : トランザクションが実行されるセッションの現在のデフォルトのデータベース名。 -- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。2 [`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 +- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。[`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 - `RELATED_TABLE_IDS` : トランザクションがアクセスするテーブル、ビュー、およびその他のオブジェクトの ID。 > **Note:** @@ -64,7 +64,7 @@ DESC TIDB_TRX; ## 例 {#example} -`TIDB_TRX`テーブルをビュー: +`TIDB_TRX`テーブルを確認します: ```sql SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX\G diff --git a/latency-breakdown.md b/latency-breakdown.md index ee161256538f2..3b0de8ca41bd1 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -247,7 +247,7 @@ tikv_grpc_msg_duration_seconds{type="coprocessor"} = req_per_copr = rate(tidb_distsql_handle_query_duration_seconds_count) / rate(tidb_distsql_scan_keys_partial_num_count) ``` -TiKVでは、テーブルスキャンタイプは`select` 、インデックススキャンタイプは`index`です。5と`select` `index`タイプの所要時間の詳細は同じです。 +TiKVでは、テーブルスキャンタイプは`select` 、インデックススキャンタイプは`index`です。`select`と`index`タイプの所要時間の詳細は同じです。 ### インデックス検索 {#index-look-up} @@ -757,7 +757,7 @@ async io enabled commit = max( ) ``` -v5.3.0以降、TiKVはAsync IO Raft （StoreWriterスレッドプールによるRaftログの書き込み）をサポートしています。Async IO Raftは、 [`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)正の値に設定されている場合にのみ有効になり、コミットプロセスが変更されます。3と`persist log locally duration` `wait by write worker duration`以下のように計算されます。 +v5.3.0以降、TiKVはAsync IO Raft （StoreWriterスレッドプールによるRaftログの書き込み）をサポートしています。Async IO Raftは、 [`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)が正の値に設定されている場合にのみ有効になり、コミットプロセスが変更されます。`persist log locally duration`と`wait by write worker duration`は以下のように計算されます。 ```text persist log locally duration = @@ -779,7 +779,7 @@ wait by write worker duration = 非同期IOの有無の違いは、ログがローカルに保持される期間です。非同期IOを使用する場合、ログがローカルに保持される期間は、ウォーターフォールメトリックから直接計算できます（バッチ待機時間は考慮されません）。 -レプリケートログ期間は、クォーラムピアに保持されたログの期間を記録します。これには、RPC期間と過半数に保持されたログの期間が含まれます。1は`replicate log duration`のように計算されます。 +レプリケートログ期間は、クォーラムピアに保持されたログの期間を記録します。これには、RPC期間と過半数に保持されたログの期間が含まれます。`replicate log duration`は以下のように計算されます。 ```text replicate log duration = diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index ad834af095bcb..a74f82052d6a9 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -204,7 +204,7 @@ CREATE TABLE `table5` ( 3. 移行タスクを開始した後、以下のいずれかの方法で進捗状況を確認できます。 - `grep`ツールを使用して、ログファイル内でキーワード`progress`を検索してください。デフォルトでは、進行状況を報告するメッセージが5分ごとにログファイルに書き込まれます。 - - 監視ダッシュボードから進捗状況をビュー。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 + - 監視ダッシュボードから進捗状況を確認します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index b19f45cbf1e21..3067cca213aa8 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -94,7 +94,7 @@ LIMIT `${data-path}`には、エクスポートされたすべての上流テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 -2. `metadata`ディレクトリにある`${data-path}`ファイルをビュー。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 +2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 SHOW MASTER STATUS: Log: mysql-bin.000004 diff --git a/migration-overview.md b/migration-overview.md index 37033a2d70b75..03a22c57c5438 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -32,7 +32,7 @@ Auroraから AWS にデプロイされた TiDB クラスターにデータを移 クラウドストレージ(S3) サービスを使用しておらず、ネットワーク接続が良好で、ネットワークレイテンシーが低い場合は、 [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md)の手順に従って、MySQL から TiDB にデータを移行できます。 -移行速度への要求が高い場合、またはデータサイズが大きい場合（例：1TiB以上）、かつ移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してデータを迅速にインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分データ（binlog）を複製できます。1 [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md)参照してください。 +移行速度への要求が高い場合、またはデータサイズが大きい場合（例：1TiB以上）、かつ移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してデータを迅速にインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分データ（binlog）を複製できます。[大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md)を参照してください。 ## MySQL シャードを TiDB に移行してマージする {#migrate-and-merge-mysql-shards-into-tidb} diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 1ed3b48f0fa9b..ff719380591ec 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -161,7 +161,7 @@ tikv_servers: 上記の例では、 `zone`レプリカの分離を制御する論理可用性ゾーンレイヤーです (サンプル クラスターには 3 つのレプリカがあります)。 -将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`スケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 +将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`をスケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 この 3 層のラベル構造をそのまま採用すると、AZ をスケールアウトした後に、新しいラベルを適用し、TiKV 内のデータを再調整する必要がある場合があります。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index a2b0b9eb9fee0..fa0147416016f 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -95,7 +95,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `OFF` - 可能`OFF`値: `ON` -- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`無効にするかどうかを制御します。デフォルト値`OFF` 、演算子`Point Get`と`Batch Point Get`クエリ実行に使用できることを意味します。11 `ON`設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`無効にし、クエリ実行にコプロセッサーを強制的に選択します。 +- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`を無効にするかどうかを制御します。デフォルト値`OFF`は、演算子`Point Get`と`Batch Point Get`をクエリ実行に使用できることを意味します。`ON`に設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`を無効にし、クエリ実行にコプロセッサーを強制的に選択します。 - `Point Get`と`Batch Point Get`列投影をサポートしていません（つまり、列のサブセットのみを返すことはできません）。そのため、シナリオによっては、実行効率がコプロセッサーよりも低くなる可能性があります。この変数を`ON`に設定すると、クエリのパフォーマンスが向上します。この変数を`ON`に設定する推奨シナリオは次のとおりです。 - 多数の列を持つ幅の広いテーブルで、少数の列のみがクエリされます。 diff --git a/partition-pruning.md b/partition-pruning.md index aea8230e7e54a..f486e634f4044 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -226,7 +226,7 @@ explain select * from t where x between 7 and 14; - [`UNIX_TIMESTAMP()`](/functions-and-operators/date-and-time-functions.md) - [`TO_DAYS()`](/functions-and-operators/date-and-time-functions.md) -- [`EXTRACT(<time unit> FROM <DATETIME/DATE/TIME column>)`](/functions-and-operators/date-and-time-functions.md) 。2列および`DATE` `DATETIME`の場合、 `YEAR`および`YEAR_MONTH`時間単位は単調関数とみなされます。10 `TIME`の場合、 `HOUR` 、および`HOUR_SECOND` `HOUR_MICROSECOND`単調関数とみなされます。パーティションプルーニングでは、 `EXTRACT`では`WEEK`時間単位としてサポートされていないこと`HOUR_MINUTE`注意してください。 +- [`EXTRACT(<time unit> FROM <DATETIME/DATE/TIME column>)`](/functions-and-operators/date-and-time-functions.md) 。`DATE`列および`DATETIME`列の場合、 `YEAR`および`YEAR_MONTH`時間単位は単調関数とみなされます。`TIME`列の場合、 `HOUR` 、 `HOUR_MINUTE` 、 `HOUR_SECOND` 、および`HOUR_MICROSECOND`は単調関数とみなされます。パーティションプルーニングでは、 `EXTRACT`で`WEEK`は時間単位としてサポートされていないことに注意してください。 たとえば、パーティション プルーニングは、パーティション式が`fn(col)`形式 ( `fn`は単調関数`to_days`の場合に有効になります。 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index e8a823d8ac2cf..cf65103ea562d 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -379,7 +379,7 @@ pd-server関連のコンフィグレーション項目 ### `affinity-schedule-limit` v8.5.5 の新機能 {#affinity-schedule-limit-new-in-v855} -- 同時に実行できる[親和性](/table-affinity.md)スケジュールタスクの数を制御します。3に設定すると`0`アフィニティスケジュールが無効になります。 +- 同時に実行できる[親和性](/table-affinity.md)スケジュールタスクの数を制御します。`0`に設定すると、アフィニティスケジュールが無効になります。 - デフォルト値: `0` ### `high-space-ratio` {#high-space-ratio} diff --git a/pd-control.md b/pd-control.md index 66fcba40da399..a55de9c54ca6b 100644 --- a/pd-control.md +++ b/pd-control.md @@ -335,7 +335,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `store-limit-mode`はストア速度を制限するモードを制御するために使用されます。オプションのモードは`auto`と`manual`です。6 `auto`では、ストアは負荷に応じて自動的にバランス調整されます（非推奨）。 -- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいて 4 の値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 +- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいてその値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 ```bash config set store-limit-version v2 // using store limit v2 diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 16ac08d68c11a..0ec625747de20 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -537,7 +537,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ - 平均`Commit Log Duration` = 7.92ミリ秒 - 平均`Apply Log Duration` = 172 us -スレッド`Store`の場合、 `Commit Log Duration`明らかに`Apply Log Duration`よりも高い値です。一方、 `Append Log Duration` `Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。13と`Commit Log Duration` `Append Log Duration`削減する方法としては、以下のものが考えられます。 +スレッド`Store`の場合、 `Commit Log Duration`は`Apply Log Duration`よりも明らかに高い値です。一方、 `Append Log Duration`は`Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。`Commit Log Duration`と`Append Log Duration`を削減する方法としては、以下のものが考えられます。 - TiKV CPU リソースが十分な場合は、 `raftstore.store-pool-size`の値を増やして`Store`スレッドを追加することを検討してください。 - TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)有効にすることを検討してください。RaftRaft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index 01185bd4d91c9..0d1c79fa532ba 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -180,9 +180,9 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。 ### 分析の結論 {#analysis-conclusion} -シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` ） `StmtClose`あります。シナリオ2と比較すると、シナリオ3 `StmtExecute`ネットワークのラウンドトリップ遅延が2つ多くなっています。 +シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ）多くあります。シナリオ2と比較すると、シナリオ3はネットワークのラウンドトリップ遅延が2つ多くなっています。 -- QPS の減少に関する分析： **「CPS By Type」**ペインを見ると、シナリオ 2 には「CPS By Type `StmtExecute`コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` ) が存在する`StmtClose` `StmtClose` `StmtPrepare`にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 +- QPS の減少に関する分析： **「CPS By Type」**ペインを見ると、シナリオ 2 には CPS By Type コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ) が存在することがわかります。`StmtPrepare`と`StmtClose`は QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 - 平均クエリ時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプ`StmtPrepare`と`StmtClose`については、TiDB内部処理においてクエリ時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ時間が大幅に短縮されます。 シナリオ3ではPrepared Statementインターフェースを使用していますが、多くのアプリケーションフレームワークはメモリリークを防ぐためにメソッド`StmtExecute`の後にメソッド`StmtClose`を呼び出すため、実行プランのキャッシュは依然としてアクセスされません。v6.0.0以降では、グローバル変数`tidb_ignore_prepared_cache_close_stmt=on;`を設定できます。その後、アプリケーションがメソッド`StmtClose`を呼び出しても、TiDBはキャッシュされた実行プランをクリアしません。そのため、次のSQL実行では既存の実行プランを再利用でき、実行プランの繰り返しコンパイルを回避できます。 diff --git a/predicate-push-down.md b/predicate-push-down.md index b5378a9702f04..1a30d6482f880 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -129,7 +129,7 @@ explain select * from t where a < @a; このクエリでは、テーブル`t`に述語`a < @a`あります。述語の`@a`ユーザー変数です。 -`explain`結果からわかるように、述語はケース 2 とは異なり、ケース`a < 1`に簡略化されて TiKV にプッシュダウンされます。これは、ユーザー変数`@a`の値が計算中に変化する可能性があり、TiKV がその変化を認識しないためです。そのため、TiDB は`@a` `1`に置き換えず、TiKV にプッシュダウンしません。 +`explain`結果からわかるように、述語はケース 2 とは異なり、 `a < 1`に簡略化されて TiKV にプッシュダウンされることはありません。これは、ユーザー変数`@a`の値が計算中に変化する可能性があり、TiKV がその変化を認識しないためです。そのため、TiDB は`@a`を`1`に置き換えず、TiKV にプッシュダウンしません。 理解を助ける例は次のとおりです。 diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 1caca0bfca048..61ec7fd26e14d 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 3.0.0 ## TiDB {#tidb} - 新機能 - - ウィンドウ関数`NTH_VALUE` `RANK` 。1、3、5、7、9、11、13、15、17、19、21 `LEAD`含むMySQL 8.0 `NTILE`すべての`CUME_DIST`関数`ROW_NUMBER` `LAST_VALUE` `FIRST_VALUE` `PERCENT_RANK`あり`DENSE_RANK` `LAG` + - ウィンドウ関数をサポート。`NTILE` 、 `LEAD` 、 `LAG` 、 `PERCENT_RANK` 、 `NTH_VALUE` 、 `CUME_DIST` 、 `FIRST_VALUE` 、 `LAST_VALUE` 、 `RANK` 、 `DENSE_RANK` 、 `ROW_NUMBER`を含む、MySQL 8.0のすべてのウィンドウ関数と互換性があります - ビューのサポート（**Experimental**） - テーブルパーティションの改善 - サポート範囲パーティション @@ -54,7 +54,7 @@ TiDB Ansible バージョン: 3.0.0 - ログ出力を最適化: `EXECUTE`ユーザー変数を出力し、 `COMMIT`トラブルシューティングを容易にするためにスロークエリログを出力します。 - SQLチューニングの使いやすさを向上させる`EXPLAIN ANALYZE`機能をサポート - 次の行のIDを取得するための`admin show next_row_id`コマンドをサポートします - - 6 `NAME_CONST` `JSON_ARRAY_APPEND`組み込み関数`BENCHMARK`追加し`COALESCE` `JSON_MERGE_PRESERVE` `JSON_QUOTE` + - `JSON_QUOTE` 、 `JSON_ARRAY_APPEND` 、 `JSON_MERGE_PRESERVE` 、 `BENCHMARK` 、 `COALESCE` 、 `NAME_CONST`の6つの組み込み関数を追加 - チャンクサイズの制御ロジックを最適化し、クエリコンテキストに基づいて動的に調整することで、SQL実行時間とリソース消費を削減します。 - 3つの演算子（ `TableReader` `IndexLookupReader`でメモリ使用量の追跡と制御をサポートします`IndexReader` - 空の`ON`条件をサポートするように Merge Join 演算子を最適化します。 diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index d3bb7ea323b64..a968bb8976604 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -31,7 +31,7 @@ TiDB Ansible バージョン: 3.0.2 - INDEX JOIN がプレフィックスインデックスを使用すると結果が間違ってしまう可能性がある問題を修正しました [＃11246](https://github.com/pingcap/tidb/pull/11246) - `DATE_ADD`関数がマイクロ秒を含む日付数値の減算を行う際に分数の配置が誤っているために結果が間違っている可能性がある問題を修正しました[＃11288](https://github.com/pingcap/tidb/pull/11288) - `DATE_ADD`関数が`INTERVAL` の負の数を誤って処理することによって発生する誤った結果を修正しました。 [＃11325](https://github.com/pingcap/tidb/pull/11325) - - `Mod(%)` `Mod(%)` 0 を返し、 `Minus(-)`以下の桁数が大きい場合 ( `select 0.000 % 0.11234500000000000000`など)、 `Multiple(*)` `Minus(-)`返す小数点以下の桁数`Multiple(*)` MySQL と異なる問題を修正しました[＃11251](https://github.com/pingcap/tidb/pull/11251) + - `Mod(%)` 、 `Multiple(*)` 、または`Minus(-)`が 0 を返し、小数点以下の桁数が大きい場合 ( `select 0.000 % 0.11234500000000000000`など)、 `Mod(%)` 、 `Multiple(*)` 、または`Minus(-)`が返す小数点以下の桁数が MySQL と異なる問題を修正しました[＃11251](https://github.com/pingcap/tidb/pull/11251) - `CONCAT`と`CONCAT_WS`関数によって返される結果の長さが`max_allowed_packet`超えると、警告付きの`NULL`が誤って返される問題を修正しました[＃11275](https://github.com/pingcap/tidb/pull/11275) - `SUBTIME`と`ADDTIME`関数のパラメータが無効な場合に警告付きの`NULL`が誤って返される問題を修正しました[＃11337](https://github.com/pingcap/tidb/pull/11337) - `CONVERT_TZ`関数のパラメータが無効な場合に`NULL`が誤って返される問題を修正しました[＃11359](https://github.com/pingcap/tidb/pull/11359) diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md index df90ee9292fbf..817b030717aca 100644 --- a/releases/release-4.0.0-beta.md +++ b/releases/release-4.0.0-beta.md @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 4.0.0-beta ## TiDB {#tidb} -- `INSERT` / `REPLACE` / `DELETE` / `UPDATE`の実行中に使用されたメモリが[＃14289](https://github.com/pingcap/tidb/pull/14289) `MemQuotaQuery`項目で指定された制限を超えた場合、ログを出力するか、SQL 実行をキャンセルします。実際の動作は`OOMAction`設定に依存します。13 [＃14179](https://github.com/pingcap/tidb/pull/14179) [＃14299](https://github.com/pingcap/tidb/pull/14299) +- `INSERT` / `REPLACE` / `DELETE` / `UPDATE`の実行中に使用されたメモリが`MemQuotaQuery`設定項目で指定された制限を超えた場合、ログを出力するか、SQL 実行をキャンセルします。実際の動作は`OOMAction`設定に依存します。 [＃14179](https://github.com/pingcap/tidb/pull/14179) [＃14289](https://github.com/pingcap/tidb/pull/14289) [＃14299](https://github.com/pingcap/tidb/pull/14299) - 駆動テーブルと被駆動テーブルの両方の行数を考慮して、 `Index Join`のコスト計算の精度を高めます。 [＃12085](https://github.com/pingcap/tidb/pull/12085) - オプティマイザの動作を制御し、オプティマイザをより安定させるために 15 個の SQL ヒントを追加します。 - [＃11253](https://github.com/pingcap/tidb/pull/11253) [＃11364](https://github.com/pingcap/tidb/pull/11364) [＃11673](https://github.com/pingcap/tidb/pull/11673) [＃11740](https://github.com/pingcap/tidb/pull/11740) [＃11746](https://github.com/pingcap/tidb/pull/11746) diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index fa1cfafab23f0..c5225c147cf0a 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -62,7 +62,7 @@ TiDB バージョン: 4.0.15 - Dumpling - テーブル情報を取得する前にスキップしたデータベースをフィルタリングして、 `SHOW TABLE STATUS` のフィルタリング効率を向上させます。 [＃337](https://github.com/pingcap/dumpling/pull/337) - - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`使用します。3 `SHOW TABLE STATUS`一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) + - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`を使用します。これは、`SHOW TABLE STATUS`が一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) - `START TRANSACTION ... WITH CONSISTENT SNAPSHOT`または`SHOW CREATE TABLE`構文をサポートしていない MySQL 互換データベースのバックアップをサポート[＃309](https://github.com/pingcap/dumpling/issues/309) - Dumpling の警告ログを改良し、ダンプが失敗したという誤解を招く情報を回避する[＃340](https://github.com/pingcap/dumpling/pull/340) diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index ee8a3a0f792f2..589afa2aca317 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -11,7 +11,7 @@ TiDB バージョン: 5.3.2 > **Warning:** > -> v5.3.2 には既知のバグがあるため、使用は推奨されません。詳細はご覧ください。このバグは v5.3.3 で修正されています。3 [バージョン5.3.3](/releases/release-5.3.3.md)使用を推奨します。 [＃12934](https://github.com/tikv/tikv/issues/12934) +> v5.3.2 には既知のバグがあるため、使用は推奨されません。詳細は [＃12934](https://github.com/tikv/tikv/issues/12934) をご覧ください。このバグは v5.3.3 で修正されています。 [バージョン5.3.3](/releases/release-5.3.3.md)の使用を推奨します。 ## 互換性の変更 {#compatibility-changes} diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index dbbac0b13534e..68f2216d5531e 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -33,7 +33,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - `blackbox_exporter-{version}-linux-amd64.tar.gz` - `node_exporter-{version}-linux-amd64.tar.gz` -- オペレーティングシステムとCPUアーキテクチャの組み合わせに応じて、異なる品質基準に対する多層的なサポートを導入します。1 [OSおよびプラットフォームの要件](https://docs-archive.pingcap.com/tidb/v6.1/hardware-and-software-requirements#os-and-platform-requirements)参照してください。 +- オペレーティングシステムとCPUアーキテクチャの組み合わせに応じて、異なる品質基準に対する多層的なサポートを導入します。[OSおよびプラットフォームの要件](https://docs-archive.pingcap.com/tidb/v6.1/hardware-and-software-requirements#os-and-platform-requirements)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index 1b91b76df9114..30429cb521f9e 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -74,7 +74,7 @@ TiDB バージョン: 6.1.6 - 直交積[＃6730](https://github.com/pingcap/tiflash/issues/6730) @ [gengliqi](https://github.com/gengliqi)を計算するときにセミ結合が過剰なメモリを使用する問題を修正しました - TiFlashログ検索が遅すぎる問題を修正[＃6829](https://github.com/pingcap/tiflash/issues/6829) @ [hehechen](https://github.com/hehechen) - 新しい照合順序[＃6807](https://github.com/pingcap/tiflash/issues/6807) @ [xzhangxian1008](https://github.com/xzhangxian1008)を有効にした後に TopN/Sort 演算子が誤った結果を生成する問題を修正しました - - 特定のケースで[＃6994](https://github.com/pingcap/tiflash/issues/6994) @ [windtalker](https://github.com/windtalker) 10 進キャストが誤って切り上げられる問題を修正しました + - 特定のケースで 10 進キャストが誤って切り上げられる問題を修正しました [＃6994](https://github.com/pingcap/tiflash/issues/6994) @ [windtalker](https://github.com/windtalker) - TiFlashが生成された列[＃6801](https://github.com/pingcap/tiflash/issues/6801) @ [guo-shaoge](https://github.com/guo-shaoge)を認識できない問題を修正 - 特定のケースで小数点以下の桁が切り上げられない問題を修正[＃7022](https://github.com/pingcap/tiflash/issues/7022) @ [LittleFall](https://github.com/LittleFall) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 8b3f8a7769dbf..cc4d0f2d1034c 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -149,7 +149,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - [インデックスマージ](/glossary.md#index-merge)は、 `AND` で接続された式をサポートします [＃39333](https://github.com/pingcap/tidb/issues/39333) @ [guo-shaoge](https://github.com/guo-shaoge) @ [time-and-fate](https://github.com/time-and-fate) @ [hailanwhu](https://github.com/hailanwhu) - v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。11 `AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 + v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。`AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 インデックスマージの詳細については、 [v5.4.0 リリースノート](/releases/release-5.4.0.md#performance)と[インデックスのマージについて説明する](/explain-index-merge.md)参照してください。 @@ -179,7 +179,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - オプティマイザーはより正確なコストモデルバージョン2（GA） を導入しました [＃35240](https://github.com/pingcap/tidb/issues/35240) @ [qw4990](https://github.com/qw4990) - TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 + TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 コスト モデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 @@ -312,7 +312,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620) | 変更 | さらにテストを行った後、デフォルト値を`1`から`2`に変更します。つまり、インデックス選択と演算子選択には、デフォルトでコスト モデル バージョン 2 が使用されることになります。 | | [`tidb_enable_gc_aware_memory_track`](/system-variables.md#tidb_enable_gc_aware_memory_track) | 変更 | デフォルト値を`ON`から`OFF`に変更します。GC対応メモリトラックはテストで不正確であることが判明し、追跡されるメモリサイズが大きくなりすぎるため、メモリトラックは無効化されています。また、 Golang 1.19では、GC対応メモリトラックによって追跡されるメモリは、全体のメモリに大きな影響を与えません。 | | [`tidb_enable_metadata_lock`](/system-variables.md#tidb_enable_metadata_lock-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。これは、メタデータ ロック機能がデフォルトで有効になっていることを意味します。 | -| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | `DELETE` 6.5.0以降で有効になります。1、3、5 `INSERT` `UPDATE` SQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | +| [`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 ノードは自動的にリーダーレプリカから読み取ります。 | diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 1623cc73b807e..2304b30e1acb3 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -94,7 +94,7 @@ TiDB バージョン: 6.5.6 - PDリーダーの故障により1分間に`IMPORT INTO`タスクが失敗する問題を修正[＃48307](https://github.com/pingcap/tidb/issues/48307) @ [D3Hunter](https://github.com/D3Hunter) - 日付型フィールドにインデックスを作成することによって発生する`ADMIN CHECK`の失敗の問題を修正しました [＃47426](https://github.com/pingcap/tidb/issues/47426) @ [tangenta](https://github.com/tangenta) - `TABLESAMPLE` によって返されるソートされていない行データの問題を修正しました [＃48253](https://github.com/pingcap/tidb/issues/48253) @ [tangenta](https://github.com/tangenta) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - TiKV diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 3c2b04e9a4ccc..f5478ab68ef7e 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -243,8 +243,8 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | 変数名 | タイプを変更 | 説明 | | --------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 非推奨 | デフォルト値を`OFF`から`ON`に変更します。 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザーは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。 | -| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)指定することで、キャッシュ可能なプランの最大数を制御できます。 | -| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)指定することで、キャッシュ可能なプランの最大数を制御できます。 | +| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | +| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | `tidb_ddl_distribute_reorg` | 削除済み | この変数の名前は[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)に変更されます。 | | [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 2 つの新しい値オプション`authentication_ldap_sasl`と`authentication_ldap_simple`が導入されました。 | | [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) | 変更 | バージョン7.1.0以降で有効となり、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を制御します。追加のテストを経て、デフォルト値を`"0s"`から`"1s"`に変更します。 | diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 38c6b284e1447..1a42849d8319e 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -73,8 +73,8 @@ TiDB バージョン: 7.1.3 - パーティション列タイプが`DATETIME` の場合に`ALTER TABLE ... LAST PARTITION`実行が失敗する問題を修正しました [＃48814](https://github.com/pingcap/tidb/issues/48814) @ [crazycs520](https://github.com/crazycs520) - `IMPORT INTO`実行中に実際のエラーメッセージが他のエラーメッセージによって上書きされる可能性がある問題を修正[＃47992](https://github.com/pingcap/tidb/issues/47992) [＃47781](https://github.com/pingcap/tidb/issues/47781) @ [D3Hunter](https://github.com/D3Hunter) - cgroup v2コンテナにデプロイされたTiDBが検出できない問題を修正[＃48342](https://github.com/pingcap/tidb/issues/48342) @ [D3Hunter](https://github.com/D3Hunter) - - DUALテーブルを最初のサブノードとして`UNION ALL`実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - DUALテーブルを最初のサブノードとして`UNION ALL`を実行するとエラーが発生する可能性がある問題を修正しました。 [＃48755](https://github.com/pingcap/tidb/issues/48755) @ [winoros](https://github.com/winoros) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - `TABLESAMPLE` によって返されるソートされていない行データの問題を修正しました [＃48253](https://github.com/pingcap/tidb/issues/48253) @ [tangenta](https://github.com/tangenta) - `tidb_enable_ordered_result_mode`有効になっているときにpanicが発生する可能性がある問題を修正[＃45044](https://github.com/pingcap/tidb/issues/45044) @ [qw4990](https://github.com/qw4990) - ウィンドウ関数によって導入されたソートを削減するために、オプティマイザが誤って IndexFullScan を選択する問題を修正しました。 [＃46177](https://github.com/pingcap/tidb/issues/46177) @ [qw4990](https://github.com/qw4990) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index c4fba3938468a..b3061b01013ef 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -143,7 +143,7 @@ TiDBバージョン: 7.1.4 - TiFlash - レプリカ移行中に PD とのネットワーク接続が不安定になり、 TiFlash がpanic可能性がある問題を修正しました [＃8323](https://github.com/pingcap/tiflash/issues/8323) @ [JaySon-Huang](https://github.com/JaySon-Huang) - - `ENUM`値が 0 の場合にTiFlash が`ENUM`誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) + - `ENUM`値が 0 の場合にTiFlash が`ENUM`を誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) - 定数文字列パラメータを含む`GREATEST`または`LEAST`関数で発生する可能性のある、ランダムに無効なメモリアクセスの問題を修正しました。 [＃8604](https://github.com/pingcap/tiflash/issues/8604) @ [windtalker](https://github.com/windtalker) - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @ [gengliqi](https://github.com/gengliqi) - 短いクエリが正常に実行され、過剰な情報ログが出力される問題を修正しました。 [＃8592](https://github.com/pingcap/tiflash/issues/8592) @ [windtalker](https://github.com/windtalker) diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 34dc6f1a5a219..94589fbdb71f9 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -257,8 +257,8 @@ TiDB バージョン: 7.4.0 | [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 変更 | さらにテストを行った後、デフォルト値を`ON`から`OFF`に変更します。これは、非プリペアドプランキャッシュが無効であることを意味します。 | | [`default_collation_for_utf8mb4`](/system-variables.md#default_collation_for_utf8mb4-new-in-v740) | 新しく追加された | `utf8mb4`文字セットのデフォルトの照合順序を制御します。デフォルト値は`utf8mb4_bin`です。 | | [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) | 新しく追加された | 有効にするクラウドストレージURI を指定します[グローバルソート](/tidb-global-sort.md) 。 | -| [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。3 に`OFF`すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | -| [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。1 `moderate` TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。3 `determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | +| [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。`OFF`に設定すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | +| [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。`moderate`は、TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。`determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | | [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) | 新しく追加された | 現在のセッションのタスクタイプを明示的に指定します。タスクタイプは[リソース管理](/tidb-resource-control-ru-groups.md)によって識別および制御されます。例: `SET @@tidb_request_source_type = "background"` 。 | | [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740) | 新しく追加された | この変数は、TiDBインスタンスにキャッシュできる履歴スキーマバージョンの数を制限します。デフォルト値は`16`で、これはTiDBがデフォルトで16個の履歴スキーマバージョンをキャッシュすることを意味します。 | | [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) | 新しく追加された | この変数はインスタンスレベルのシステム変数です。これを使用して、 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)配下のTiDBノードのサービススコープを制御できます。TiDBノードの`tidb_service_scope` `background`に設定すると、DXFはそのTiDBノードで[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)や[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)などのDXFタスクを実行するようにスケジュールします。 | diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index b7a8d90122b91..ed3ecdff3be94 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -141,7 +141,7 @@ TiDB バージョン: 7.5.1 - DDL所有者がネットワークから分離されているの後に`ADD INDEX`実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) - `AUTO_ID_CACHE=1` のAUTO_INCREMENT列を使用すると同時競合によりAUTO_INCREMENT ID 割り当てでエラーが報告される問題を修正しました。 [＃50519](https://github.com/pingcap/tidb/issues/50519) @ [tiancaiamao](https://github.com/tiancaiamao) - クエリに Apply 演算子が含まれており、 `fatal error: concurrent map writes`エラーが発生すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50347](https://github.com/pingcap/tidb/issues/50347) @ [SeaRise](https://github.com/SeaRise) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - `STREAM_AGG()` CI を誤って処理したためにクエリ結果が正しくない問題を修正しました [＃49902](https://github.com/pingcap/tidb/issues/49902) @ [wshwsh12](https://github.com/wshwsh12) - 多数のテーブルまたはパーティションを処理するときに TiDB ノードが OOM エラーに遭遇する可能性がある問題を軽減します。 [＃50077](https://github.com/pingcap/tidb/issues/50077) @ [zimulala](https://github.com/zimulala) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [＃50067](https://github.com/pingcap/tidb/issues/50067) @ [hawkingrei](https://github.com/hawkingrei) @@ -191,7 +191,7 @@ TiDB バージョン: 7.5.1 - `DROP TABLE`データ挿入の直後に実行されると、 `FLASHBACK TABLE`または`RECOVER TABLE`一部のTiFlashレプリカのデータを回復できない可能性がある潜在的な問題を修正しました。 [＃8395](https://github.com/pingcap/tiflash/issues/8395) @ [JaySon-Huang](https://github.com/JaySon-Huang) - Grafana の一部のパネルの最大パーセンタイル時間の表示が誤っていた問題を修正 [＃8076](https://github.com/pingcap/tiflash/issues/8076) @ [JaySon-Huang](https://github.com/JaySon-Huang) - リモート読み取り中にTiFlashがクラッシュする可能性がある問題を修正 [＃8685](https://github.com/pingcap/tiflash/issues/8685) @ [guo-shaoge](https://github.com/guo-shaoge) - - `ENUM`値が 0 の場合にTiFlash が`ENUM`誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) + - `ENUM`値が 0 の場合にTiFlash が`ENUM`を誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) - 短いクエリが正常に実行され、過剰な情報ログが出力される問題を修正しました。 [＃8592](https://github.com/pingcap/tiflash/issues/8592) @ [windtalker](https://github.com/windtalker) - クエリの低速化によりメモリ使用量が大幅に増加する問題を修正 [＃8564](https://github.com/pingcap/tiflash/issues/8564) @ [JinheLin](https://github.com/JinheLin) - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @ [gengliqi](https://github.com/gengliqi) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 259703e32ac28..0c4c9ae6fc211 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -273,7 +273,7 @@ v8.4.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 3d2f7a0cc15a0..c3924867f3684 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -144,7 +144,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタをバージョン 8.4.0 以降にアップグレードすると、クラスタが利用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.1.md b/releases/release-8.5.1.md index 8328c541b41b0..e461fb02b969c 100644 --- a/releases/release-8.5.1.md +++ b/releases/release-8.5.1.md @@ -15,9 +15,9 @@ TiDBバージョン：8.5.1 バージョン8.5.1以降、TiDBはCentOS Linux 7のテストを再開し、互換性を確保しています。TiDB v8.5をデプロイする場合、またはクラスタをv8.5にアップグレードする場合は、TiDB v8.5.1以降のバージョンを使用してください。 -- TiDB v8.4.0 DMR および v8.5.0 リリースは[2024年6月30日をもってサポート終了となります](https://www.redhat.com/en/topics/linux/centos-linux-eol) CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 +- CentOS Linux 7 は[2024年6月30日をもってサポート終了となります](https://www.redhat.com/en/topics/linux/centos-linux-eol)。そのため、TiDB v8.4.0 DMR および v8.5.0 リリースでは、CentOS Linux 7 のサポートとテストを終了しました。CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 -- 現在も CentOS Linux 7 を使用しているユーザーを支援するために、TiDB は v8.5.1 から CentOS Linux 7 のテストを再開します。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)およびセキュリティに関するガイダンスを確認し、Rocky Linux 9.1 以降などの本番使用用の[TiDBがサポートするオペレーティングシステム](/hardware-and-software-requirements.md#os-and-platform-requirements)する報酬システムに移行することを強くお勧めします。 +- 現在も CentOS Linux 7 を使用しているユーザーを支援するために、TiDB は v8.5.1 から CentOS Linux 7 のテストを再開します。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)を確認し、Rocky Linux 9.1 以降などの本番使用向けの[TiDBがサポートするオペレーティングシステム](/hardware-and-software-requirements.md#os-and-platform-requirements)に移行することを強くお勧めします。 CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDBリリースではこのディストリビューションのテストは中止されます。 diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index 9665ccae49b27..596724826dbba 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -90,7 +90,7 @@ TiDBバージョン：8.5.4 ### MySQLとの互換性 {#mysql-compatibility} -バージョン 8.5.4 以降、TiDB は`DECIMAL`列にデータを挿入する際の動作を MySQL と同期させました。小数点以下の桁数が列の定義済みスケールを超える場合、TiDB は余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。小数点以下の桁数に関係なく、切り捨てられたデータは挿入されます。以前の TiDB バージョンでは、挿入される`DECIMAL`値の小数点以下の桁数が 72 を超えると、挿入は失敗し、エラーが返されました。詳細については、 [JDBCを使用してTiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-sample-application-java-jdbc#mysql-compatibility) +バージョン 8.5.4 以降、TiDB は`DECIMAL`列にデータを挿入する際の動作を MySQL と同期させました。小数点以下の桁数が列の定義済みスケールを超える場合、TiDB は、超過した小数点以下の桁数に関係なく、余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。以前の TiDB バージョンでは、挿入される`DECIMAL`値の小数点以下の桁数が 72 を超えると、挿入は失敗し、エラーが返されました。詳細については、 [JDBCを使用してTiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-sample-application-java-jdbc#mysql-compatibility)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/versioning.md b/releases/versioning.md index 63a64f612441b..a7a19dcec885e 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -22,9 +22,9 @@ TiDB のメジャー リリースのサポート ポリシーについては、 TiDB のバージョン番号は`X.Y.Z`から始まり、 `X.Y`リリース シリーズを表します。 -- TiDB 1.0以降、毎年`X`増加します。3リリース`X`に新機能と改善が導入されます。 -- `Y`から増加します。 `Y`ごとに新しい機能と改善が導入されます。 -- リリースシリーズの最初のリリースでは、デフォルトで`Z`が 0 に設定されます。パッチリリースの場合は、1 から`Z`増加します。 +- TiDB 1.0以降、`X`は毎年増加します。`X`リリースごとに新しい機能と改善が導入されます。 +- `Y`は 0 から増加します。 `Y`リリースごとに新しい機能と改善が導入されます。 +- リリースシリーズの最初のリリースでは、デフォルトで`Z`が 0 に設定されます。パッチリリースの場合は、 `Z`は 1 から増加します。 TiDB v5.0.0 以前のバージョンのバージョン管理システムについては、 [歴史的なバージョン管理](#historical-versioning-deprecated)を参照してください。 diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 09ff463606d60..e335ffb5aa338 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -21,7 +21,7 @@ TiDBクラスターの高可用性と災害復旧能力を向上させるには TiUPを使用してクラスターをデプロイする場合、 [初期化設定ファイル](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)で TiKV の場所を設定できます。TiUPは、デプロイ中に TiDB、TiKV、PD、およびTiFlashの対応する設定ファイルを生成します。 -以下の例では、2層トポロジ（ `zone/host`が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 +以下の例では、2層トポロジ（ `zone/host` ）が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 - 各ゾーンには、TiDB インスタンスがデプロイされているホストが 2 つあり、各ホストには個別の TiDB インスタンスがデプロイされています。 - 各ゾーンには、TiKVインスタンスがデプロイされたホストが2つあります。z1では、各ホストに2つのTiKVインスタンスがデプロイされています。z2とz3では、各ホストに個別のTiKVインスタンスがデプロイされています。 @@ -244,7 +244,7 @@ host = "" `location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 -上記の手順に従って`location-labels`ゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、 `isolation-level` ～ `zone`次のように設定できます。 +上記の手順に従って`location-labels`をゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、次のように`isolation-level`を`zone`に設定できます。 ```toml [replication] diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 38bc790053180..da382e51502cb 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -249,7 +249,7 @@ TiDB Self-Managed ユーザーの認証方法として`tidb_auth_token`設定し mycli -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p '' ``` - ここで紹介するMySQLクライアントが`mysql_clear_password`プラグインをサポートしていることを確認してください。3 [mycli](https://www.mycli.net/)デフォルトでこのプラグインをサポートし、有効化します。5 [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)使用している場合は、 `--enable-cleartext-plugin`オプションを使用してこのプラグインを有効化する必要があります。 + ここで紹介するMySQLクライアントが`mysql_clear_password`プラグインをサポートしていることを確認してください。[mycli](https://www.mycli.net/)はデフォルトでこのプラグインをサポートし、有効化します。[MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)を使用している場合は、 `--enable-cleartext-plugin`オプションを使用してこのプラグインを有効化する必要があります。 ```Shell mysql -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p'' --enable-cleartext-plugin diff --git a/sql-plan-management.md b/sql-plan-management.md index 1f2d6e2fca969..566ef0143c7d4 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -9,7 +9,7 @@ SQL計画管理は、SQLバインディングを実行してSQL実行計画を ## SQLバインディング {#sql-binding} -SQLバインディングはSPMの基盤です。1 [オプティマイザヒント](/optimizer-hints.md)ドキュメントでは、ヒントを用いて特定の実行プランを選択する方法を紹介しています。しかし、SQL文を変更せずに実行プランの選択を操作したい場合もあります。SQLバインディングを使用すれば、SQL文を変更せずに特定の実行プランを選択できます。 +SQLバインディングはSPMの基盤です。[オプティマイザヒント](/optimizer-hints.md)ドキュメントでは、ヒントを用いて特定の実行プランを選択する方法を紹介しています。しかし、SQL文を変更せずに実行プランの選択を操作したい場合もあります。SQLバインディングを使用すれば、SQL文を変更せずに特定の実行プランを選択できます。 diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index c4aa08b6ebed1..92cbdc502d937 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -12,7 +12,7 @@ category: reference [チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 -[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
`が実行されます。 diff --git a/sql-statements/sql-statement-admin-pause-ddl.md b/sql-statements/sql-statement-admin-pause-ddl.md index e85601f63b2ac..98ff300c0e829 100644 --- a/sql-statements/sql-statement-admin-pause-ddl.md +++ b/sql-statements/sql-statement-admin-pause-ddl.md @@ -35,7 +35,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 -> - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを一時停止できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 @@ -44,7 +44,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 -> - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを一時停止できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md index 2e329c67aed5d..8913fc2b8226f 100644 --- a/sql-statements/sql-statement-admin-resume-ddl.md +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -34,7 +34,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **Note:** > > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 -> - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを再開できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 @@ -44,7 +44,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **Note:** > > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 -> - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを再開できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 742ed21e6f504..9cdecfefeffa0 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -32,7 +32,7 @@ WhereClauseOptional ::= 現在実行中のDDLジョブのステータスを表示するには、 `ADMIN SHOW DDL`使用します。出力には、現在のスキーマバージョン、DDL IDと所有者のアドレス、実行中のDDLジョブとSQL文、現在のTiDBインスタンスのDDL IDが含まれます。返される結果フィールドは以下のとおりです。 - `SCHEMA_VER` : スキーマのバージョンを示す数値。 -- `OWNER_ID` : DDL所有者のUUID。2 [`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)参照してください。 +- `OWNER_ID` : DDL所有者のUUID。[`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)もを参照してください。 - `OWNER_ADDRESS` : DDL 所有者の IP アドレス。 - `RUNNING_JOBS` : 実行中の DDL ジョブの詳細。 - `SELF_ID` : 現在接続しているTiDBノードのUUID。2 `SELF_ID` `OWNER_ID`と同じ場合は、DDL所有者に接続していることを意味します。 @@ -69,7 +69,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `add index` : [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)操作の場合。 - `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 - `none` : 存在しないことを示します。通常、 `DROP`操作の後、または`CREATE`操作が失敗してロールバックした後、 `none`番目の状態になります。 - - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 + - `delete only` 、 `write only` 、 `delete reorganization` 、 `write reorganization` : これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を参照してください。中間状態の変換は高速であるため、これらの状態は通常、演算中は表示されません。`ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 - `SCHEMA_ID` : DDL 操作が実行されるデータベースの ID。 - `TABLE_ID` : DDL 操作が実行されるテーブルの ID。 @@ -109,7 +109,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `JOB_TYPE` : DDL 操作のタイプ。 - `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 - `none` : 存在しないことを示します。通常、 `DROP`操作の後、または`CREATE`操作が失敗してロールバックした後、 `none`番目の状態になります。 - - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](https://docs.pingcap.com/tidb/stable/ddl-introduction#how-the-online-ddl-asynchronous-change-works-in-tidb)参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 + - `delete only` 、 `write only` 、 `delete reorganization` 、 `write reorganization` : これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](https://docs.pingcap.com/tidb/stable/ddl-introduction#how-the-online-ddl-asynchronous-change-works-in-tidb)を参照してください。中間状態の変換は高速であるため、これらの状態は通常、演算中は表示されません。`ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 - `SCHEMA_ID` : DDL 操作が実行されるデータベースの ID。 - `TABLE_ID` : DDL 操作が実行されるテーブルの ID。 diff --git a/sql-statements/sql-statement-create-view.md b/sql-statements/sql-statement-create-view.md index 58a50bf7445df..f151048e793b7 100644 --- a/sql-statements/sql-statement-create-view.md +++ b/sql-statements/sql-statement-create-view.md @@ -89,8 +89,8 @@ ERROR 1105 (HY000): insert into view v1 is not supported now. ## MySQLの互換性 {#mysql-compatibility} -- 現在、TiDB 内のどのビューも挿入または更新できません (つまり、 `INSERT VIEW`と`UPDATE VIEW`サポートされていません)。5 `WITH CHECK OPTION`構文的に互換性があるだけで、有効ではありません。 -- 現在、TiDB のビューは`ALTER VIEW`サポートしていませんが、代わりに`CREATE OR REPLACE`使用できます。 +- 現在、TiDB 内のどのビューも挿入または更新できません (つまり、 `INSERT VIEW`と`UPDATE VIEW`サポートされていません)。`WITH CHECK OPTION`構文的に互換性があるだけで、有効ではありません。 +- 現在、TiDB のビューは`ALTER VIEW`をサポートしていませんが、代わりに`CREATE OR REPLACE`を使用できます。 - 現在、 `ALGORITHM`フィールドは TiDB において構文的に互換性があるものの、効果がありません。TiDB は現在 MERGE アルゴリズムのみをサポートしています。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 70830347fcc0b..be658f6ecaf6f 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -160,7 +160,7 @@ EXPLAIN ANALYZE SELECT * FROM t1; ### IndexHashJoin {#indexhashjoin} -`IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。5演算`IndexHashJoin`も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 +`IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。`IndexHashJoin`演算子も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 1. 外側のワーカーは N 個の外側の行を読み取り、タスクを構築して、それを内側のワーカー チャネルに送信します。 2. 内部ワーカーは内部ワーカーチャネルからタスクを受け取り、各タスクに対して以下の3つの操作を順番に実行します。a. 外部行からハッシュテーブルを構築する。b. 外部行からキー範囲を構築し、内部行を取得する。c. ハッシュテーブルをプローブし、結合結果を結果チャネルに送信する。注：ステップaとステップbは同時に実行されます。 diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..12324a9cea42d 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -487,7 +487,7 @@ LIMIT 3; 1. 重大な過小評価：最初のリーフノード`IndexReader_76`インデックス`index_orders_on_adjustment_id(adjustment_id)`からデータを読み取ります。実際の行数（ `actRows` ）は256,811,189で、推定された1行（ `estRows` ）よりも大幅に多くなっています。 2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`予想よりもはるかに多くのデータを含むハッシュ テーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 -3. クエリの終了： `0` `HashJoin_69`の演算子の値が`actRows`の場合、1は一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 +3. クエリの終了： `HashJoin_69`とその上位の演算子の`actRows`の値が`0`の場合、一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `estRows` `IndexRangeScan_75`に対して大幅に過小評価していることであり、オプティマイザーが誤った結合順序を選択することになります。 これらの問題に対処するには、特に`orders`テーブルと`index_orders_on_adjustment_id`インデックスのテーブル統計が最新であることを確認します。 diff --git a/statistics.md b/statistics.md index 96d89643f2035..3c972e0eb915b 100644 --- a/statistics.md +++ b/statistics.md @@ -85,7 +85,7 @@ TiDBは、テーブルへの変更回数に基づいて、自動的に[`ANALYZE` ### ヒストグラム {#histogram} -ヒストグラム統計は、オプティマイザが区間または範囲述語の選択性を推定するために使用され、また、統計のバージョン 2 で等号/IN 述語を推定するために列内の異なる値の数を決定するためにも使用される場合があります (統計[統計のバージョン](#versions-of-statistics)を参照)。 +ヒストグラム統計は、オプティマイザが区間または範囲述語の選択性を推定するために使用され、また、統計のバージョン 2 で等号/IN 述語を推定するために列内の異なる値の数を決定するためにも使用される場合があります ( [統計のバージョン](#versions-of-statistics)を参照)。 ヒストグラムは、データの分布を近似的に表現したものです。値の全範囲を複数のバケットに分割し、各バケットに含まれる値の数など、単純なデータを用いて各バケットを記述します。TiDBでは、各テーブルの特定の列に対して等深ヒストグラムが作成されます。この等深ヒストグラムは、区間クエリの推定に利用できます。 @@ -105,14 +105,14 @@ Count-Min Sketch はハッシュ構造です。 `a = 1`や`IN`クエリ (例え Count-Min Sketch はハッシュ構造であるため、ハッシュ衝突が発生する可能性があります。EXPLAIN [`EXPLAIN`](/sql-statements/sql-statement-explain.md)において、同等のクエリの推定値が実際の値から大きく乖離する場合、より大きな値とより小さな値がハッシュ化されているとみなすことができます。この場合、ハッシュ衝突を回避するために、以下のいずれかの方法を取ることができます。 -- `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 -- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 +- `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 +- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ### トップN {#top-n} トップN値とは、列またはインデックス内で出現頻度が最も高いN個の値のことです。トップN統計は、頻度統計またはデータスキューと呼ばれることもあります。 -TiDB は上位 N 個の値とその出現回数を記録します。ここでは`N`は`WITH NUM TOPN`パラメータによって制御されます。デフォルト値は 20 で、これは最も頻繁に出現する上位 20 個の値が収集されることを意味します。最大値は 1024 です。パラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 +TiDB は上位 N 個の値とその出現回数を記録します。ここでは`N`は`WITH NUM TOPN`パラメータによって制御されます。デフォルト値は 20 で、これは最も頻繁に出現する上位 20 個の値が収集されることを意味します。最大値は 1024 です。パラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ## 選択的統計収集 {#selective-statistics-collection} diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index b2dbe9ff003ef..93896e9b57b42 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -11,7 +11,7 @@ summary: Titan の設定方法を学びます。 > **Note:** > -> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。1 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 +> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 > - v7.6.0 以降のバージョンにアップグレードされた既存のクラスターは元の構成を保持します。つまり、Titan が明示的に有効になっていない場合は、引き続き RocksDB が使用されます。 > - クラスタをTiDB v7.6.0以降のバージョンにアップグレードする前にTitanを有効にしていた場合、アップグレード後もTitanが有効になり、アップグレード前の設定値[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)も保持されます。アップグレード前に明示的に値を設定しない場合は、アップグレード後のクラスタ構成の安定性を確保するために、旧バージョンのデフォルト値`1KB`が保持されます。 diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 72e9e903b8ca2..1b8fdab78084b 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -27,7 +27,7 @@ Titan は、大量のデータが TiKV フォアグラウンドに書き込ま Titan を有効にするための前提条件は次のとおりです。 -- 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。1 [`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 +- 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 - 範囲クエリは実行されないか、高い範囲クエリのパフォーマンスを必要としません。Titan に格納されるデータは整列されていないため、範囲クエリのパフォーマンスは RocksDB よりも低く、特に広い範囲のクエリではその傾向が顕著です。PingCAP の内部テストによると、Titan の範囲クエリのパフォーマンスは RocksDB よりも 40% から数倍低いことが示されています。 - 十分なディスク容量（同じデータ量でRocksDBのディスク消費量の2倍の容量を確保することを検討してください）。これは、Titanがディスク容量を犠牲にして書き込み増幅を削減するためです。また、Titanは値を1つずつ圧縮するため、圧縮率はRocksDBよりも低くなります。RocksDBはブロックを1つずつ圧縮するため、TitanはRocksDBよりも多くのストレージ容量を消費しますが、これは想定内の正常な動作です。状況によっては、Titanのストレージ消費量がRocksDBの2倍になる場合があります。 diff --git a/system-variables.md b/system-variables.md index 944803d1e43e9..7c1644051d62c 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1269,7 +1269,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` -- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000` UTC の午前 1:00 を指します。 +- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000`は UTC の午前 1:00 を指します。 ### tidb_auto_analyze_partition_batch_size はv6.4.0 で追加されました。 {#tidb-auto-analyze-partition-batch-size-span-class-version-mark-new-in-v6-4-0-span} @@ -1313,7 +1313,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` -- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000` UTC の午前 1:00 を指します。 +- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000`は UTC の午前 1:00 を指します。 ### tidb_auto_build_stats_concurrency v6.5.0で追加 {#tidb-auto-build-stats-concurrency-new-in-v650} @@ -1765,8 +1765,8 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 範囲: `[32, 10240]` - 単位：行 - この変数は、DDL 操作の`re-organize`フェーズ中にバッチ サイズを設定するために使用されます。たとえば、TiDB が`ADD INDEX`操作を実行すると、インデックス データは`tidb_ddl_reorg_worker_cnt` (数) 個の同時実行ワーカーによってバックフィルされる必要があります。各ワーカーは、インデックス データをバッチ単位でバックフィルします。 - - `tidb_ddl_enable_fast_reorg`が`OFF`に設定されている場合、 `ADD INDEX`はトランザクションとして実行されます。 `UPDATE`の実行中に、対象列で`REPLACE`や`ADD INDEX` }} などの更新操作が多数発生する場合、バッチサイズが大きいほどトランザクション競合が発生する可能性が高くなります。この場合、バッチサイズを小さい値に設定することをお勧めします。最小値は 32 です。 - - トランザクションの競合が存在しない場合、または`tidb_ddl_enable_fast_reorg`が`ON`に設定されている場合は、バッチ サイズを大きな値に設定できます。これにより、データのバックフィルが高速になりますが、TiKV への書き込み圧力も増加します。適切なバッチ サイズについては、 `tidb_ddl_reorg_worker_cnt`の値も参照する必要があります。参考として[オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](https://docs.pingcap.com/tidb/dev/online-workloads-and-add-index-operations)参照してください。 + - `tidb_ddl_enable_fast_reorg`が`OFF`に設定されている場合、 `ADD INDEX`はトランザクションとして実行されます。 `ADD INDEX`の実行中に、対象列で`UPDATE`や`REPLACE`などの更新操作が多数発生する場合、バッチサイズが大きいほどトランザクション競合が発生する可能性が高くなります。この場合、バッチサイズを小さい値に設定することをお勧めします。最小値は 32 です。 + - トランザクションの競合が存在しない場合、または`tidb_ddl_enable_fast_reorg`が`ON`に設定されている場合は、バッチ サイズを大きな値に設定できます。これにより、データのバックフィルが高速になりますが、TiKV への書き込み圧力も増加します。適切なバッチ サイズについては、 `tidb_ddl_reorg_worker_cnt`の値も参照する必要があります。参考として[オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](https://docs.pingcap.com/tidb/dev/online-workloads-and-add-index-operations)を参照してください。 - バージョン8.3.0以降、このパラメータはセッションレベルでサポートされています。グローバルレベルでパラメータを変更しても、現在実行中のDDLステートメントには影響しません。変更は、新規セッションで送信されるDDLにのみ適用されます。 - バージョン 8.5.0 以降では、 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;`を実行することで、実行中の DDL ジョブのこのパラメータを変更できます。TiDB バージョン 8.5.5 より前のバージョンでは、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)が有効になっている場合、 `ADD INDEX` DDL に対してこの操作はサポートされていないことに注意してください。詳細については、 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)を参照してください。 @@ -5150,7 +5150,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、オプティマイザが`DISTINCT`を含む集計関数を、 `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` } に書き換えるなど、2 レベルの集計関数に書き換えるかどうかを設定します。集計列に深刻な偏りがあり、 `DISTINCT`列にさまざまな値がある場合、この書き換えによってクエリ実行時のデータ偏りを回避し、クエリのパフォーマンスを向上させることができます。 +- この変数は、オプティマイザが`DISTINCT`を含む集計関数を、 `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`に書き換えるなど、2 レベルの集計関数に書き換えるかどうかを設定します。集計列に深刻な偏りがあり、 `DISTINCT`列にさまざまな値がある場合、この書き換えによってクエリ実行時のデータ偏りを回避し、クエリのパフォーマンスを向上させることができます。 ### tidb_opt_three_stage_distinct_agg v6.3.0で追加 {#tidb-opt-three-stage-distinct-agg-new-in-v630} diff --git a/table-affinity.md b/table-affinity.md index 937d31256d749..68b2d7420d449 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -35,7 +35,7 @@ PDアフィニティスケジューリングはデフォルトで無効になっ pd-ctl config set schedule.affinity-schedule-limit 4 ``` -2. （オプション）必要に応じてPD設定項目[`schedule.max-affinity-merge-region-size`](/pd-configuration-file.md#max-affinity-merge-region-size-new-in-v855)を変更します。デフォルト値は`256`です。これは、同じアフィニティグループ内の隣接する小さなリージョンを自動的にマージするためのサイズしきい値を制御します。5に設定すると`0`アフィニティグループ内の隣接する小さなリージョンの自動マージが無効になります。 +2. （オプション）必要に応じてPD設定項目[`schedule.max-affinity-merge-region-size`](/pd-configuration-file.md#max-affinity-merge-region-size-new-in-v855)を変更します。デフォルト値は`256` MiB です。これは、同じアフィニティグループ内の隣接する小さなリージョンを自動的にマージするためのサイズしきい値を制御します。`0`に設定すると、アフィニティグループ内の隣接する小さなリージョンの自動マージが無効になります。 ## 使用法 {#usage} diff --git a/table-attributes.md b/table-attributes.md index e00ad2fd3d730..24ea569bda507 100644 --- a/table-attributes.md +++ b/table-attributes.md @@ -133,8 +133,8 @@ ALTER TABLE t PARTITION p ATTRIBUTES 'merge_option=allow'; > **Note:** > -> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)実行する必要があります。 -> - `merge_option`属性を使用する場合は、PD設定パラメータ[`split-merge-interval`](/pd-configuration-file.md#split-merge-interval)に注意する必要があります。5 属性`merge_option`設定されていない場合、リージョンが条件を満たしている場合、 `split-merge-interval`で指定された間隔後にリージョンをマージできます`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、指定された間隔後にリージョンをマージするかどうかを決定します。 +> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)を実行する必要があります。 +> - `merge_option`属性を使用する場合は、PD設定パラメータ[`split-merge-interval`](/pd-configuration-file.md#split-merge-interval)に注意する必要があります。`merge_option`属性が設定されていない場合、リージョンが条件を満たしている場合、 `split-merge-interval`で指定された間隔後にリージョンをマージできます`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、指定された間隔後にリージョンをマージするかどうかを決定します。 @@ -142,7 +142,7 @@ ALTER TABLE t PARTITION p ATTRIBUTES 'merge_option=allow'; > **Note:** > -> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)実行する必要があります。 -> - `merge_option`の属性が設定されていない場合、リージョンが条件を満たしていれば、1時間後にリージョンを統合できます。3 `merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、1時間後にリージョンを統合するかどうかを決定します。 +> - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)を実行する必要があります。 +> - `merge_option`の属性が設定されていない場合、リージョンが条件を満たしていれば、1時間後にリージョンを統合できます。`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、1時間後にリージョンを統合するかどうかを決定します。 diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 606d4f9738ac1..3f80ac05b3912 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -103,7 +103,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ - `` - `` - 1 の値を置き換える前に、 [HTML URL エンコーディングリファレンス](https://www.w3schools.com/tags/ref_urlencode.asp)に基づいて``エンコードする必要があることに注意してください。上記のすべてのフィールドを置き換えた後、設定ファイルは次のようになります。 + ``の値を置き換える前に、 [HTML URL エンコーディングリファレンス](https://www.w3schools.com/tags/ref_urlencode.asp)に基づいてエンコードする必要があることに注意してください。上記のすべてのフィールドを置き換えた後、設定ファイルは次のようになります。 ```shell tiup cdc:v cli changefeed create --server="http://127.0.0.1:8300" --sink-uri="kafka://xxx-xxxxx.ap-east-1.aws.confluent.cloud:9092/ticdc-meta?protocol=avro&replication-factor=3&enable-tls=true&auto-create-topic=true&sasl-mechanism=plain&sasl-user=L5WWA4GK4NAT2EQV&sasl-password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" --schema-registry="https://7NBH2CAFM2LMGTH7:xxxxxxxxxxxxxxxxxx@yyy-yyyyy.us-east-2.aws.confluent.cloud" --changefeed-id="confluent-changefeed" --config changefeed.conf @@ -156,8 +156,8 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co ### 前提条件 {#prerequisites} -- Snowflakeクラスターの登録と作成が完了しました[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)参照してください。 -- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。1 [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)参照してください。 +- Snowflakeクラスターの登録と作成が完了しています。[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)を参照してください。 +- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。[キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)を参照してください。 ### 統合手順 {#integration-procedure} diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index cb07ddd01f2b5..c6f4c33915e6a 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -53,7 +53,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 解決： - このアラートはレプリケーションの中断に似ています。1 [TiCDC はレプリケーションの中断を処理します](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-replication-interruptions)参照してください。 + このアラートはレプリケーションの中断に似ています。[TiCDC はレプリケーションの中断を処理します](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-replication-interruptions)を参照してください。 ## 警告アラート {#warning-alerts} @@ -155,7 +155,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 解決： - 考えられる根本原因は多数あります。1 [TiCDC のトラブルシューティング](/ticdc/troubleshoot-ticdc.md)参照してください。 + 考えられる根本原因は多数あります。[TiCDC のトラブルシューティング](/ticdc/troubleshoot-ticdc.md)を参照してください。 ### `ticdc_memory_abnormal` {#ticdc-memory-abnormal} diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index b0be9e83a3e29..e264a156b821b 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -82,7 +82,7 @@ TiCDC は DML イベントを Kafka イベントに変換し、イベントの ## TiDB拡張フィールド {#tidb-extension-fields} -デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。7で`enable-tidb-extension` `true` （デフォルトは`false` ）に設定すると、TiCDC `sink-uri`メッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 +デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。`sink-uri`で`enable-tidb-extension`を`true` （デフォルトは`false` ）に設定すると、TiCDCはメッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 - `_tidb_op` : DML タイプ。「c」は挿入を示し、「u」は更新を示します。 - `_tidb_commit_ts` : トランザクションの一意の識別子。 @@ -158,7 +158,7 @@ dispatchers = [ } - `{{ColumnName}}`列名を示します。 -- `{{TIDB_TYPE}}` TiDB 内の型を示します。これは SQL 型との 1 対 1 のマッピングではありません。 +- `{{TIDB_TYPE}}`は TiDB 内の型を示します。これは SQL 型との 1 対 1 のマッピングではありません。 - `{{AVRO_TYPE}}` [Avro仕様](https://avro.apache.org/docs/++version++/specification)内のタイプを示します。 | SQLの型 | TiDBの型 | AVRO_TYPE | 説明 | @@ -284,7 +284,7 @@ TiCDC Avro プロトコルは[`io.confluent.kafka.serializers.KafkaAvroDeseriali コンシューマー プログラムは、次のルールによって DML イベント タイプを区別できます。 - Key部分のみの場合はDeleteイベントになります。 -- キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。1 [TiDB拡張フィールド](#tidb-extension-fields)有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 +- キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。[TiDB拡張フィールド](#tidb-extension-fields)が有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 ## トピックの分布 {#topic-distribution} diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index e6face4e1601a..d64ae8a9cfc82 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -23,7 +23,7 @@ TiCDCは、指定されたタイムスタンプ以降に発生した増分デー 1. 上流クラスタと下流クラスタの時点を確認します。2つのTiDBクラスタがある場合は、特定の時点において2つのクラスタのデータが整合していることを確認します。例えば、TiDB 1の`ts=1`時点のデータとTiDB 2の`ts=2`のデータは整合しています。 - 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`設定します。 + 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`を対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`を設定します。 4. `--config`パラメータで指定された構成ファイルに、次の構成を追加します。 diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 26179c694c7f4..91c7ece661e68 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -167,8 +167,8 @@ TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERM 上記の例からわかるように、Canal-JSON は統一されたデータ形式を持ち、イベントの種類ごとに異なるフィールドの入力ルールを備えています。コンシューマーは、統一された方法でこの JSON 形式のデータを解析し、フィールド値をチェックすることでイベントの種類を判別できます。 -- `isDdl`が`true`場合、メッセージには DDL イベントが含まれます。 -- `isDdl`が`false`場合、 `type`フィールドをさらに確認する必要があります。7 が`type` `TIDB_WATERMARK`場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。 +- `isDdl`が`true`の場合、メッセージには DDL イベントが含まれます。 +- `isDdl`が`false`の場合、 `type`フィールドをさらに確認する必要があります。`type`が`TIDB_WATERMARK`の場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。 ## フィールドの説明 {#field-descriptions} diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index 634a048a146b0..8baed00adc661 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -35,7 +35,7 @@ summary: チェンジフィードの基本的な概念、状態の定義、お - ⑤ changefeedの自動リトライが30分を超えて失敗し、changefeedは失敗状態になります。このとき、changefeedは`gc-ttl`で指定された期間、上流GCをブロックし続けます。 - ⑥ changefeed は回復不能なエラーに遭遇し、直接 failed 状態に移行します。このとき、changefeed は`gc-ttl`で指定された期間、上流の GC をブロックし続けます。 - ⑦ changefeedのレプリケーション進行状況が`target-ts`で設定した値に到達し、レプリケーションが完了します。 -- 8 チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 +- ⑧ チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 - ⑨ 失敗の原因が解決され、変更フィードが`gc-ttl`で指定された値よりも短い期間中断された場合は、 `changefeed resume`コマンドを実行してレプリケーション タスクを再開します。 ## チェンジフィードを操作する {#operate-changefeeds} diff --git a/ticdc/ticdc-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index 880965812aa45..a8612bb803efc 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -13,7 +13,7 @@ summary: TiCDC のデータ複製機能について学びます。 - TiCDCは`UPDATE` `INSERT` `DELETE`を生成します。詳細については[TiCDCがデータ変更を処理する方法](/ticdc/ticdc-overview.md#implementation-of-processing-data-changes)参照してください。 -- TiCDCはトランザクションの最終的な一貫性を保証します。1 [再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。3 [同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 +- TiCDCはトランザクションの最終的な一貫性を保証します。[再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)を有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)を有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 ## サポートされている下流システム {#supported-downstream-systems} diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 09518aca005d7..23eab8831c6a2 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -174,7 +174,7 @@ cdc cli changefeed resume --server=http://10.0.10.25:8300 --changefeed-id simple > **Note:** > -> - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがchangefeed（ `t1` ）の現在のチェックポイントTSOよりも大きい場合、 `t1`と`t2`間のデータは下流に複製されません。これによりデータ損失が発生します。13 `cdc cli changefeed query`実行すると`t1`取得できます。 +> - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがchangefeed（ `t1` ）の現在のチェックポイントTSOよりも大きい場合、 `t1`と`t2`間のデータは下流に複製されません。これによりデータ損失が発生します。`cdc cli changefeed query`を実行すると`t1`を取得できます。 > - `--overwrite-checkpoint-ts` （ `t2` ）で指定されたTSOがチェンジフィード（ `t1` ）の現在のチェックポイントTSOより小さい場合、TiCDCは古い時点（ `t2` ）からデータをプルします。これにより、データの重複が発生する可能性があります（たとえば、下流がMQシンクの場合）。 ## レプリケーションタスクを削除する {#remove-a-replication-task} diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 8448ed66da974..8049b5a68bfbb 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -246,7 +246,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | パラメータ名 | 説明 | | :------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bdr_mode` | `BOOLEAN`型。2 [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)有効にするかどうかを決定します。デフォルト値は`false`です。（オプション） | +| `bdr_mode` | `BOOLEAN`型。[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)を有効にするかどうかを決定します。デフォルト値は`false`です。（オプション） | | `case_sensitive` | `BOOLEAN`型。テーブル名をフィルタリングする際に大文字と小文字を区別するかどうかを指定します。v6.5.6、v7.1.3、v7.5.0以降では、デフォルト値が`true`から`false`に変更されます。（オプション） | | `check_gc_safe_point` | `BOOLEAN`型。レプリケーションタスクの開始時刻がGC時刻よりも前であるかどうかを確認するかどうかを指定します。デフォルト値は`true`です。（オプション） | | `consistent` | REDOログの設定パラメータ。(オプション) | @@ -306,7 +306,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | :---------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | `column_selectors` | 列セレクターの構成。(オプション) | | `csv` | CSV 構成。(オプション) | -| `date_separator` | `STRING`型。ファイルディレクトリの日付区切り文字の種類を示します。値の選択肢は`none` 、 `year` 、 `month` 、 `day`です。10 `none`デフォルト値で、日付が区切られないことを意味します。(オプション) | +| `date_separator` | `STRING`型。ファイルディレクトリの日付区切り文字の種類を示します。値の選択肢は`none` 、 `year` 、 `month` 、 `day`です。`none`がデフォルト値で、日付が区切られないことを意味します。(オプション) | | `dispatchers` | イベントディスパッチ用の構成配列。(オプション) | | `encoder_concurrency` | `INT`型。MQシンク内のエンコーダスレッドの数。デフォルト値は`16`です。（オプション） | | `protocol` | `STRING`型。MQシンクの場合、メッセージのプロトコル形式を指定できます。現在サポートされているプロトコルは、 `canal-json` 、 `open-protocol` 、 `avro` 、 `debezium` 、 `simple` 。 | @@ -509,7 +509,7 @@ curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/ch | `resolved_ts` | `UINT64`タイプ。レプリケーション タスクは ts を解決しました。 | | `sink_uri` | `STRING`タイプ。レプリケーション タスク シンクの URI。 | | `start_ts` | `UINT64`タイプ。レプリケーションタスクが開始されます。 | -| `state` | `STRING`型。レプリケーションタスクの`failed` 。2、4、6、8、10 `stopped` `normal`か`finished`なります`error` | +| `state` | `STRING`型。レプリケーションタスクのステータス。`normal` 、 `stopped` 、 `error` 、 `failed` 、または`finished`になります。 | | `target_ts` | `UINT64`タイプ。レプリケーションタスクのターゲット ts。 | | `task_status` | レプリケーション タスクのディスパッチの詳細なステータス。 | diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index c778a08f937d0..d006b0c45b86d 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -9,7 +9,7 @@ summary: OpenAPI インターフェースを使用してクラスターのステ > **注記** > -> TiCDC OpenAPI v1は非推奨であり、将来削除される予定です。1 [TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)使用をお勧めします。 +> TiCDC OpenAPI v1は非推奨であり、将来削除される予定です。[TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)の使用をお勧めします。 TiCDC は、TiCDC クラスターを照会および操作するための OpenAPI 機能を提供します。これは、 [`cdc cli`ツール](/ticdc/ticdc-manage-changefeed.md)の機能に似ています。 diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index d66342fc6213a..ccd8029295ec1 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -236,8 +236,8 @@ TiCDC は、DDL イベントを次の JSON 形式でエンコードします。 | `sql` | string | DDL ステートメント。 | | `commitTs` | number | DDL ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | -| `tableSchema` | object | テーブルの現在のスキーマ情報。詳細については、 [TableSchemaの定義](#tableschema-definition)参照してください。 | -| `preTableSchema` | object | DDL文が実行される前のテーブルのスキーマ情報。1 `CREATE`のDDLイベントを除くすべてのDDLイベントにこのフィールドがあります。 | +| `tableSchema` | object | テーブルの現在のスキーマ情報。詳細については、 [TableSchemaの定義](#tableschema-definition)を参照してください。 | +| `preTableSchema` | object | DDL文が実行される前のテーブルのスキーマ情報。`CREATE`のDDLイベントを除くすべてのDDLイベントにこのフィールドがあります。 | ### DML {#dml} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index dda9e120d3ca8..2c77fce8b9ef4 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -277,7 +277,7 @@ Topic 式の形式は`[prefix]{schema}[middle][{table}][suffix]`です。 ### パーティションディスパッチャ {#partition-dispatchers} -`partition = "xxx"` `index-value`ディスパッチャ`columns`指定するために使用できます。3、5、7、9、11 `default` 5つ`ts`ディスパッチャをサポートします。ディスパッチャのルールは以下のとおり`table` 。 +`partition = "xxx"`を使用してパーティションディスパッチャを指定できます。`default` 、 `index-value` 、 `columns` 、 `table` 、 `ts`の5つのディスパッチャをサポートします。ディスパッチャのルールは以下のとおりです。 - `default` : デフォルトで`table`ディスパッチャルールを使用します。スキーマ名とテーブル名に基づいてパーティション番号を計算し、テーブルからのデータが必ず同じパーティションに送信されるようにします。その結果、1つのテーブルからのデータは1つのパーティションにのみ存在し、順序付けが保証されます。ただし、このディスパッチャルールは送信スループットを制限し、コンシューマーを追加しても消費速度を向上させることはできません。 - `index-value` : 主キー、一意インデックス、または`index`で明示的に指定されたインデックスのいずれかを使用してパーティション番号を計算し、テーブルデータを複数のパーティションに分散します。単一のテーブルのデータは複数のパーティションに送信され、各パーティションのデータは順序付けされます。コンシューマーを追加することで、消費速度を向上させることができます。このディスパッチャは、同じ行への更新が同じパーティションに送信されるようにすることで、その行の順序付けされた処理を保証します。 diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index fc04b6a393198..ee7d66a4105a1 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -30,7 +30,7 @@ Info: {"upstream_id":7277814241002263370,"namespace":"default","id":"simple-repl - `--server` : TiCDC クラスター内の TiCDCサーバーのアドレス。 - `--changefeed-id` : レプリケーションタスクのID。形式は正規表現`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`一致する必要があります。IDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 -- `--sink-uri` ：レプリケーションタスクのダウンストリームアドレス。2 [シンクURIを使用してPulsarを構成する](#sink-uri)参照してください。 +- `--sink-uri` ：レプリケーションタスクのダウンストリームアドレス。[シンクURIを使用してPulsarを構成する](#sink-uri)を参照してください。 - `--start-ts` : チェンジフィードの開始TSO。TiCDCクラスターはこのTSOからデータのプルを開始します。デフォルト値は現在時刻です。 - `--target-ts` : チェンジフィードのターゲットTSO。TiCDCクラスターはこのTSOでデータのプルを停止します。デフォルトでは空であり、TiCDCはデータのプルを自動的に停止しません。 - `--config` : changefeed設定ファイル[TiCDC チェンジフィード構成パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 54172d86904a5..517f8aa3d6c90 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -129,7 +129,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | バージョン6.5.2以下 | 全て | ✗ | ✓ | | | v6.5.3 / v6.5.4 | Canal/オープン | ✗ | ✓ | | -| バージョン6.5.3 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。1を参照してください[＃9086](https://github.com/pingcap/tiflow/issues/9658) | +| バージョン6.5.3 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。[＃9086](https://github.com/pingcap/tiflow/issues/9658)を参照してください。 | | バージョン6.5.4 | Canal/オープン | ✗ | ✗ | 複数の変更を含むトランザクションのみを分割して並べ替える | | v6.5.5 ～ v6.5.9 | 全て | ✓ | ✗ | | | = v6.5.10 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | @@ -140,7 +140,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | バージョン7.1.0 | 全て | ✗ | ✓ | | | バージョン7.1.1 | Canal/オープン | ✗ | ✓ | | -| バージョン7.1.1 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。1を参照してください[＃9086](https://github.com/pingcap/tiflow/issues/9658) | +| バージョン7.1.1 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。[＃9086](https://github.com/pingcap/tiflow/issues/9658)を参照してください。 | | v7.1.2 ~ v7.1.5 | 全て | ✓ | ✗ | | | = v7.1.6 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index a05759fc1dc07..672986d1b1ddf 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -56,7 +56,7 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc ## レプリケーション タスクを作成するとき、または MySQL にデータをレプリケートするときに、「 Error 1298: Unknown or incorrect time zone: 'UTC'エラーを処理するにはどうすればよいですか? {#how-do-i-handle-the-code-error-1298-unknown-or-incorrect-time-zone-utc-code-error-when-creating-the-replication-task-or-replicating-data-to-mysql} -このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。1 [`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 +このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)を実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 ```shell mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p @@ -128,7 +128,7 @@ cdc cli changefeed resume -c test-cf --server=http://127.0.0.1:8300 > **Note:** > -> changefeed `start-ts`エラー発生時の`checkpoint-ts`に 1 を加えた値に設定してタスクを再作成すると、DDL 文をスキップできますが、TiCDC が`checkpointTs+1`の時点での DML データ変更を失う可能性があります。したがって、この操作は実本番環境では厳禁です。 +> changefeed の`start-ts`をエラー発生時の`checkpoint-ts`に 1 を加えた値に設定してタスクを再作成すると、DDL 文をスキップできますが、TiCDC が`checkpointTs+1`の時点での DML データ変更を失う可能性があります。したがって、この操作は実本番環境では厳禁です。 ```shell cdc cli changefeed remove --server=http://127.0.0.1:8300 --changefeed-id simple-replication-task diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index e97c2d0baeee3..d7df32a55f268 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -7,7 +7,7 @@ summary: TiDB Cloudコンソールでデータ アプリを作成、表示、変 Data Service（プレビュー版）のデータアプリは、特定のアプリケーションのデータにアクセスするために使用できるエンドポイントのコレクションです。APIキーを使用して認証設定を構成し、データアプリ内のエンドポイントへのアクセスを制限できます。 -このドキュメントでは、 TiDB Cloudコンソールでデータアプリを管理する方法について説明します。1 [**データサービス**](https://tidbcloud.com/project/data-service)目では、すべてのデータアプリ、エンドポイント、API キーを管理できます。 +このドキュメントでは、 TiDB Cloudコンソールでデータアプリを管理する方法について説明します。[**Data Service**](https://tidbcloud.com/project/data-service)ページでは、すべてのデータアプリ、エンドポイント、API キーを管理できます。 ## データアプリを作成する {#create-a-data-app} diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 1daaef714e36a..1b23b3c0c3a9d 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -264,7 +264,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート } ``` -4. 役割を設定します。 [IAMロールの作成（コンソール）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)参照してください。 「アカウント ID」フィールドに、ステップ 1 で書き留めたTiDB Cloudアカウント ID とTiDB Cloud外部 ID を入力します。 +4. 役割を設定します。 [IAMロールの作成（コンソール）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)を参照してください。 「アカウント ID」フィールドに、ステップ 1 で書き留めたTiDB Cloudアカウント ID とTiDB Cloud外部 ID を入力します。 5. ロール ARN を取得します。 [AWSコンソール > IAM > アクセス管理 > ロール](https://console.aws.amazon.com/iamv2/home#/roles)。お住まいの地域に切り替えてください。作成したロールをクリックし、ARN をメモします。これは、データをTiDB Cloudにインポートするときに使用します。 diff --git a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md index 4845364d21f85..85d1a42be729a 100644 --- a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md @@ -32,8 +32,8 @@ TiDB Cloud Starterの管理インフラストラクチャをアップグレー - クラスタ管理 - クラスターを作成する - クラスターを削除する - - スケールクラスター - - クラスターをビュー + - クラスターをスケールする + - クラスターを表示する - クラスターを一時停止または再開する - クラスターのパスワードを変更する - クラスタートラフィックフィルターを変更する diff --git a/tidb-cloud/releases/release-notes-2021.md b/tidb-cloud/releases/release-notes-2021.md index cba773bbd6852..2c2731668e873 100644 --- a/tidb-cloud/releases/release-notes-2021.md +++ b/tidb-cloud/releases/release-notes-2021.md @@ -110,7 +110,7 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま 一般的な -- TiDB Cloudは現在パブリックプレビュー中です。1 [サインアップ](https://tidbcloud.com/signup)クリックして、以下のトライアルオプションのいずれかを選択してください。 +- TiDB Cloudは現在パブリックプレビュー中です。[サインアップ](https://tidbcloud.com/signup)をクリックして、以下のトライアルオプションのいずれかを選択してください。 - 48時間無料トライアル - 2週間のPoC無料トライアル diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 2a69506593285..db3a3dc1c73a6 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -122,7 +122,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま さらに、データ移行では、既存のデータと進行中の変更の両方をデータ ソースからTiDB Cloudに移行するための完全および増分データ移行機能が提供されます。 - 現在、データ移行機能は**ベータ版**です。3 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター、AWSオレゴン（us-west-2）およびAWSシンガポール（ap-southeast-1）リージョンでのみご利用いただけます。組織ごとに1つの移行ジョブを無料で作成できます。組織に複数の移行ジョブを作成するには、 [チケットを提出する](/tidb-cloud/tidb-cloud-support.md)が必要です。 + 現在、データ移行機能は**ベータ版**です。[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター、AWSオレゴン（us-west-2）およびAWSシンガポール（ap-southeast-1）リージョンでのみご利用いただけます。組織ごとに1つの移行ジョブを無料で作成できます。組織に複数の移行ジョブを作成するには、 [チケットを提出する](/tidb-cloud/tidb-cloud-support.md)が必要です。 詳細については[データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 6e4e63d1faeef..4bacc63df3fcc 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -410,7 +410,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - changefeed を使用してデータを Amazon S3 にストリーミングすることをサポートします。 - これにより、 TiDB CloudとAmazon S3のシームレスな統合が可能になります。1 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターからAmazon S3へのリアルタイムのデータキャプチャとレプリケーションが可能になり、下流のアプリケーションと分析機能が最新のデータにアクセスできるようになります。 + これにより、 TiDB CloudとAmazon S3のシームレスな統合が可能になります。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターからAmazon S3へのリアルタイムのデータキャプチャとレプリケーションが可能になり、下流のアプリケーションと分析機能が最新のデータにアクセスできるようになります。 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 16fd0dda4cb0f..f43af9f45eb42 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -178,7 +178,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) AWS上でのロードバランシングに関する課金体系の変更。 - 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、AWS [AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 + 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、[AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)に伴い、パブリック IPv4 アドレスに対する新しい AWS 料金が含まれます。各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 この料金は、お客様の既存の**TiDB Cloud Dedicated - Data Transfer - Load Balancing**サービスの下に表示されます。 [請求明細](/tidb-cloud/tidb-cloud-billing.md#billing-details)。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 728c505030c58..98e673e6c4db7 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -715,7 +715,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスター内のパブリック エンドポイントのファイアウォール ルールをサポートします。 - TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。1 [TiDB Cloudコンソール](https://tidbcloud.com/)許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 + TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。[TiDB Cloudコンソール](https://tidbcloud.com/)で許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 詳細については[パブリックエンドポイント用のTiDB Cloudサーバーレス ファイアウォール ルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)参照してください。 diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index 68a7617ce799e..28bb65107bc98 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -332,7 +332,7 @@ ticloud serverless export create -c --target-type GCS --gcs.uri .blob.core.windows.net///`形式で Azure Blob Storage の URI を入力します。 - - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。2でSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access) [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)してください。 + - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。[Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用してSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 4. **［エクスポート］**をクリックします。 diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index a747ffef6068d..a014e650ac004 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -20,10 +20,10 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを ### 繋がり {#connection} -- [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。5 [VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md) TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 +- [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。[VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md)は TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 - プライベートエンドポイントのサポート[ファイアウォールルール](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md) 。 -- データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)参照してください。 -- TiDB Cloud Starterクラスターでは、最大400の同時接続が可能です。1 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)設定すると、この制限は5,000に増加します。 +- データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)を参照してください。 +- TiDB Cloud Starterクラスターでは、最大400の同時接続が可能です。[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)を設定すると、この制限は5,000に増加します。 > **Note:** > diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md index 6a974fda65a7b..40afebde7f3e9 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -61,7 +61,7 @@ TiDB Cloud がAmazon MSK プロビジョニングクラスターにアクセス export PATH=$PATH:/home/ec2-user/jdk-22.0.2/bin ``` -4. 以下の内容を含む`scram-client.properties`という名前のファイルを作成します。3と`pswd` `username` /SCRAMの認証情報に置き換えてください。 +4. 以下の内容を含む`scram-client.properties`という名前のファイルを作成します。`username`と`pswd`をSASL/SCRAMの認証情報に置き換えてください。 ```properties security.protocol=SASL_SSL diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index 179d1bcd755b3..ff280866fa59c 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md @@ -112,7 +112,7 @@ Kafka VPC を作成するには、次の手順を実行します。 [ECSコンソール](https://ecs.console.alibabacloud.com/home#/)に進みます。vSwitch に 3 つのブローカー ノード (AZ ごとに 1 つ) を作成します。 -- vSwitch 1 のブローカー`broker-ap-southeast-1a` +- vSwitch `broker-ap-southeast-1a`のブローカー 1 - **ネットワークとゾーン**: `Kafka VPC`および`broker-ap-southeast-1a` vSwitch - **インスタンスとイメージ**: `ecs.t5-lc1m2.small`インスタンスタイプと`Alibaba Cloud Linux`イメージ diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index fcfc89e735364..7b6b4b162ccad 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -39,7 +39,7 @@ AWS PrivateLink を利用することで、エンドポイント接続は安全 ## 前提条件 {#prerequisites} -AWS VPC設定でDNSホスト名とDNS解決の[AWS マネジメントコンソール](https://console.aws.amazon.com/)が有効になっていることを確認してください。1でVPCを作成すると、これらはデフォルトで無効になります。 +AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっていることを確認してください。[AWS マネジメントコンソール](https://console.aws.amazon.com/)でVPCを作成すると、これらはデフォルトで無効になります。 ## プライベートエンドポイント接続を設定し、クラスターに接続する {#set-up-a-private-endpoint-connection-and-connect-to-your-cluster} diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index 57db4051f9321..1d53e0ab26c6d 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -188,7 +188,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング aws ec2 modify-vpc-attribute --vpc-id "$app_vpc_id" --enable-dns-support ``` -設定が完了すると、VPCピアリングが作成されます。1 [TiDBクラスタに接続する](#connect-to-the-tidb-cluster)結果を確認できます。 +設定が完了すると、VPCピアリングが作成されます。[TiDBクラスタに接続する](#connect-to-the-tidb-cluster)ことで結果を確認できます。
diff --git a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md index 34e413c0f2102..93680f02353d6 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -16,9 +16,9 @@ summary: このドキュメントでは、Google Cloud でセルフホスト型 Google Cloud でセルフホスト型 Kafka に Private Service Connect を設定するには、次の 2 つの方法があります。 -- Private Service Connect（PSC）ポートマッピングメカニズムを使用します。この方法では、静的なポートブローカーマッピング設定が必要です。EXTERNALリスナーとアドバタイズリスナーのグループを追加するには、既存のKafkaクラスターを再構成する必要があります。1 [PSC ポート マッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定](#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping)参照してください。 +- Private Service Connect（PSC）ポートマッピングメカニズムを使用します。この方法では、静的なポートブローカーマッピング設定が必要です。EXTERNALリスナーとアドバタイズリスナーのグループを追加するには、既存のKafkaクラスターを再構成する必要があります。詳細は[PSC ポート マッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定](#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping)を参照してください。 -- [Kafkaプロキシ](https://github.com/grepplabs/kafka-proxy)使用してください。この方法では、Kafka クライアントと Kafka ブローカー間のプロキシとして、追加の実行プロセスが導入されます。プロキシはポートとブローカーのマッピングを動的に設定し、リクエストを転送します。既存の Kafka クラスターを再設定する必要はありません。3 [Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)参照してください。 +- [Kafkaプロキシ](https://github.com/grepplabs/kafka-proxy)を使用してください。この方法では、Kafka クライアントと Kafka ブローカー間のプロキシとして、追加の実行プロセスが導入されます。プロキシはポートとブローカーのマッピングを動的に設定し、リクエストを転送します。既存の Kafka クラスターを再設定する必要はありません。詳細は[Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)を参照してください。 このドキュメントでは、Google Cloud の 3 つのアベイラビリティゾーン（AZ）にデプロイされた Kafka Private Service Connect サービスへの接続例を示します。同様のポートマッピング原則に基づいて他の構成も可能ですが、このドキュメントでは Kafka Private Service Connect サービスの基本的な設定プロセスについて説明します。本番環境では、運用の保守性と可観測性を強化した、より回復力の高い Kafka Private Service Connect サービスの使用を推奨します。 diff --git a/tidb-cloud/sql-proxy-account.md b/tidb-cloud/sql-proxy-account.md index 3d156a9e0e6f1..da0ca6710a975 100644 --- a/tidb-cloud/sql-proxy-account.md +++ b/tidb-cloud/sql-proxy-account.md @@ -26,7 +26,7 @@ SQL プロキシ アカウントの主な利点は次のとおりです。 SELECT user FROM user WHERE plugin = 'tidb_auth_token'; ``` -2. SQLアカウントの権限を確認してください。1、3、5 `role_admin`のロール`role_readonly`リストさ`role_readwrite`ている場合は、SQLプロキシアカウントです。 +2. SQLアカウントの権限を確認してください。`role_admin` 、 `role_readonly` 、 `role_readwrite`などのロールがリストされている場合は、SQLプロキシアカウントです。 ```sql SHOW GRANTS for 'username'; diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 010b5bbaf1357..29ba54369575f 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -387,7 +387,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_cluster.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_cluster.example_cluster @@ -546,7 +546,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の Apply complete! Resources: 0 added, 1 changed, 0 destroyed. -4. ステータスを確認するには`terraform state show tidbcloud_cluster.${resource-name}`使用します。 +4. ステータスを確認するには`terraform state show tidbcloud_cluster.${resource-name}`を使用します。 $ terraform state show tidbcloud_cluster.example_cluster @@ -592,7 +592,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の 1. [クラスターを作成する](#create-a-cluster-using-the-cluster-resource)際に使用される`cluster.tf`ファイルで、 `components`構成を編集します。 - たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります[クラスタ仕様からこの情報を取得します](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 + たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります。[クラスタ仕様からこの情報を取得](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 components = { tidb = { diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index 99435bb0e6e88..7ec3a0b3798d1 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -244,7 +244,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi 通常、 TiDB Cloud Dedicated クラスターの作成には少なくとも 10 分かかります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_cluster.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_cluster.example_cluster @@ -486,7 +486,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -4. `terraform state show tidbcloud_dedicated_cluster.${resource-name}`使用して状態を確認します。 +4. `terraform state show tidbcloud_dedicated_cluster.${resource-name}`を使用して状態を確認します。 $ terraform state show tidbcloud_dedicated_cluster.example_cluster diff --git a/tidb-cloud/terraform-use-dedicated-network-container-resource.md b/tidb-cloud/terraform-use-dedicated-network-container-resource.md index 2ce47a033315f..eb4683e4df7b3 100644 --- a/tidb-cloud/terraform-use-dedicated-network-container-resource.md +++ b/tidb-cloud/terraform-use-dedicated-network-container-resource.md @@ -114,7 +114,7 @@ summary: tidbcloud_dedicated_network_container` リソースを使用して、 T TiDB Cloud Dedicated ネットワークコンテナのリージョンにTiDB Cloud Dedicated クラスターを作成するまで、リソースのステータスは`INACTIVE`ままです。その後、ステータスは`ACTIVE`に変わります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_network_container.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_network_container.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_network_container.example diff --git a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md index 1d1cb2b4b75ef..fca4f9e4c1dc7 100644 --- a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md +++ b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md @@ -117,7 +117,7 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_private_endpoint_connection.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_private_endpoint_connection.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_private_endpoint_connection.example diff --git a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md index 65e7e2d7b91c1..0f58a5b6a198c 100644 --- a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md +++ b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md @@ -117,7 +117,7 @@ summary: tidbcloud_dedicated_vpc_peering` リソースを使用して、 TiDB Cl クラウドプロバイダーのコンソールでVPCピアリング接続を承認するまで、リソースのステータスは`Creating`ままです。VPCピアリング接続を承認すると、ステータスは[VPC ピアリングの承認と設定](/tidb-cloud/set-up-vpc-peering-connections.md#step-2-approve-and-configure-the-vpc-peering)基準に`Active`に変わります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_vpc_peering.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_vpc_peering.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_vpc_peering.example diff --git a/tidb-cloud/terraform-use-serverless-branch-resource.md b/tidb-cloud/terraform-use-serverless-branch-resource.md index 613b19fb40f39..ea2bb0d8f3439 100644 --- a/tidb-cloud/terraform-use-serverless-branch-resource.md +++ b/tidb-cloud/terraform-use-serverless-branch-resource.md @@ -116,7 +116,7 @@ summary: サーバーレス ブランチ リソースを使用して、 TiDB Clo Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_branch.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_branch.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_branch.example diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md index 6d7a23b15867a..91f8c89068233 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -226,7 +226,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example @@ -357,7 +357,7 @@ tidbcloud_serverless_cluster.example: Modifications complete after 8s Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用してリソースの状態を確認します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用してリソースの状態を確認します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index dfaffd90e0145..76eca77156620 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -224,7 +224,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example @@ -352,7 +352,7 @@ tidbcloud_serverless_cluster.example: Modifications complete after 8s Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`使用してリソースの状態を確認します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +次に、コマンド`terraform show`または`terraform state show tidbcloud_serverless_cluster.${resource-name}`を使用してリソースの状態を確認します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_cluster.example diff --git a/tidb-cloud/terraform-use-serverless-export-resource.md b/tidb-cloud/terraform-use-serverless-export-resource.md index 89e97acf90898..c20288d61da71 100644 --- a/tidb-cloud/terraform-use-serverless-export-resource.md +++ b/tidb-cloud/terraform-use-serverless-export-resource.md @@ -117,7 +117,7 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud このリソースは同期されていません。1 `terraform refresh`使用すると最新の状態を取得できます。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_export.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_export.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_serverless_export.example diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index f882364a431f6..16484c0a80e27 100644 --- a/tidb-cloud/terraform-use-sql-user-resource.md +++ b/tidb-cloud/terraform-use-sql-user-resource.md @@ -107,7 +107,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_sql_user.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_sql_user.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_sql_user.example @@ -178,7 +178,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -4. `terraform state show tidbcloud_sql_user.${resource-name}`使用して状態を確認します。 +4. `terraform state show tidbcloud_sql_user.${resource-name}`を使用して状態を確認します。 $ terraform state show tidbcloud_sql_user.example # tidbcloud_sql_user.example: diff --git a/tidb-cloud/ticloud-import-start.md b/tidb-cloud/ticloud-import-start.md index d799ca121d687..89d9fafd70a09 100644 --- a/tidb-cloud/ticloud-import-start.md +++ b/tidb-cloud/ticloud-import-start.md @@ -76,9 +76,9 @@ ticloud serverless import start --source-type AZURE_BLOB --azblob.uri .blob.core.windows.net//`形式で指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.サービスアカウントキー文字列 | GCS の base64 でエンコードされたサービス アカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.uri 文字列 | GCS URIを`gcs:///`形式で指定します。ソースタイプがGCSの場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | -| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーIDを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけ設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --s3.role-arn 文字列 | Amazon S3のロールARNを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキーを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけ設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーIDを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.role-arn 文字列 | Amazon S3のロールARNを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキーを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --s3.uri 文字列 | S3 URIを`s3:///`形式で指定します。ソースタイプがS3の場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | | --source-type 文字列 | インポートソースの種類を [ `"LOCAL"` `"S3"` `"GCS"` `"AZURE_BLOB"` ] のいずれかで指定します。デフォルト値は`"LOCAL"`です。 | いいえ | 非対話型モードでのみ動作します。 | | | | | -c, --cluster-id 文字列 | クラスター ID を指定します。 | はい | 非対話型モードでのみ動作します。 | | | | diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md index 864bfca8692f0..d4515fb84e253 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md @@ -59,9 +59,9 @@ ticloud serverless audit-log config update -c --enabled=false | --oss.uri 文字列 | `oss:///`形式の Alibaba Cloud OSS URI。 | いいえ | 非対話型モードでのみ動作します。 | | --rotation-interval-minutes int32 | ローテーション間隔（分）。有効な範囲： `[10, 1440]` 。 | いいえ | 非対話型モードでのみ動作します。 | | --rotation-size-mib int32 | 回転サイズ（MiB）。有効な範囲： `[1, 1024]` 。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーID。 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.role-arn 文字列 | Amazon S3 のロール ARN。 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキー。1 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーID。 `--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.role-arn 文字列 | Amazon S3 のロール ARN。 `--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキー。`--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.uri 文字列 | `s3:///`形式の Amazon S3 URI。 | いいえ | 非対話型モードでのみ動作します。 | | --unredacted | データベース監査ログを編集解除または編集します。 | いいえ | 非対話型モードでのみ動作します。 | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index ccdba05c3726b..7124e7a1dd6a2 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -45,7 +45,7 @@ CMEK 対応プロジェクトを作成するには、次の手順に従います
-この手順は、TiDB Cloud APIを使用して[CMEK 対応プロジェクトを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Project/operation/CreateProject)エンドポイント経由で完了できます。3フィールド`aws_cmek_enabled` `true`に設定されていることを確認してください。 +この手順は、TiDB Cloud APIを使用して[CMEK 対応プロジェクトを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Project/operation/CreateProject)エンドポイント経由で完了できます。`aws_cmek_enabled`フィールドが`true`に設定されていることを確認してください。 現在、 TiDB Cloud APIはパブリックプレビューです。詳細については、 [TiDB Cloud API ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)をご覧ください。 diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index 94b5c34b7da95..102ca8e26a13b 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -47,7 +47,7 @@ PoC の目標を特定するには、次の質問を参考にしてください ## ステップ2. ワークロードの特性を特定する {#step-2-identify-characteristics-of-your-workload} -TiDB Cloudは、高可用性と大容量データの強力な整合性が求められる様々なユースケースに適しています。1 [TiDB の紹介](https://docs.pingcap.com/tidb/stable/overview)主要な機能とシナリオをリストアップしました。お客様のビジネスシナリオに当てはまるかどうかご確認ください。 +TiDB Cloudは、高可用性と大容量データの強力な整合性が求められる様々なユースケースに適しています。[TiDB の紹介](https://docs.pingcap.com/tidb/stable/overview)では、主要な機能とシナリオをリストアップしました。お客様のビジネスシナリオに当てはまるかどうかご確認ください。 - 水平方向のスケールアウトまたはスケールイン - 金融グレードの高可用性 @@ -143,10 +143,10 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます ワークロードを開始した後、次の方法を使用してシステムを観察できます。 -- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。1 [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)参照してください。 -- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。5 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 -- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)参照してください。 -- これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。1 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)参照してください。 +- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。詳細は[TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)を参照してください。 +- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。詳細は[ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)を参照してください。 +- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます。詳細は[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)を参照してください。 +- これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。詳細は[サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)を参照してください。 次はテスト結果を評価する時です。 @@ -180,7 +180,7 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます - アップグレード - TiDB CloudはTiDBクラスタを定期的にアップグレードします。また、サポートチケットを送信してクラスタのアップグレードをリクエストすることもできます。1 [TiDBクラスタのアップグレード](/tidb-cloud/upgrade-tidb-cluster.md)ご覧ください。 + TiDB CloudはTiDBクラスタを定期的にアップグレードします。また、サポートチケットを送信してクラスタのアップグレードをリクエストすることもできます。詳細は[TiDBクラスタのアップグレード](/tidb-cloud/upgrade-tidb-cluster.md)をご覧ください。 - バックアップ diff --git a/tidb-cloud/tidb-node-group-management.md b/tidb-cloud/tidb-node-group-management.md index 5525c8afdc04a..3a5853b97a747 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -57,7 +57,7 @@ TiDB ノード グループを作成するには、次の手順を実行しま デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5 つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 -TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。1 [TiDBノードグループに接続する](#connect-to-a-tidb-node-group)参照してください。 +TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。[TiDBノードグループに接続する](#connect-to-a-tidb-node-group)を参照してください。 ## TiDBノードグループに接続する {#connect-to-a-tidb-node-group} diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index ddad2ea0241aa..dbc0eace5e221 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -11,7 +11,7 @@ Chat2Query API には HTTPS 経由でのみアクセスできるため、ネッ > **Note:** > -> Chat2Query APIはAWSでホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみ利用可能です。3 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでChat2Query APIをご利用いただくには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> Chat2Query APIはAWSでホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみ利用可能です。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでChat2Query APIをご利用いただくには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 始める前に {#before-you-begin} @@ -200,7 +200,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request GET 'https:// **Note:** > -> ナレッジベース関連エンドポイントは、AWS でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみご利用いただけます。3 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでナレッジベース関連エンドポイントをご利用になる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> ナレッジベース関連エンドポイントは、AWS でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみご利用いただけます。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでナレッジベース関連エンドポイントをご利用になる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index 02575a6e778e0..8a5a8dfbce427 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -57,7 +57,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 5daacd14614b2..40c6505a9d33e 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -60,7 +60,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index 5ce52edb6c354..c3b5655dba647 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -78,7 +78,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index e9575f4d31436..62b83b1900ce9 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index 0ceced3994d41..9ad6cca04b44d 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -78,7 +78,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 5421626304f9d..e948e3b307694 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index 8980f911cdad8..695e9b2666fa4 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -83,7 +83,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 77d57bccd7e94..adb528fa50d89 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -72,7 +72,7 @@ raft-engine.prefill-for-recycle = true curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index 818a5a8f94f86..d2ffac8173dc1 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -83,7 +83,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 86115ec572924..009af4f8f1a5c 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -72,7 +72,7 @@ raft-engine.prefill-for-recycle = true curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index 6ac47e8d77ae9..3b376197a2e23 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -72,7 +72,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ - **Leader書き込み最適化**: リーダーがコミットされたがまだ永続化されていないRaftログを早期に適用できるようにし、リーダー ピアの書き込みレイテンシーに対する IO ジッターの影響を軽減します。 -- **低速ノード検出の強化**：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラがトリガーされ、パフォーマンスが回復します。2 [遅いノード検出メカニズム](https://docs.pingcap.com/tidb/v8.5/pd-scheduling-best-practices#troubleshoot-tikv-node) [低速ストアの排除スケジューラ](https://docs.pingcap.com/tidb/v8.5/pd-control#scheduler-show--add--remove--pause--resume--config--describe)を使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。 +- **低速ノード検出の強化**：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラがトリガーされ、パフォーマンスが回復します。[遅いノード検出メカニズム](https://docs.pingcap.com/tidb/v8.5/pd-scheduling-best-practices#troubleshoot-tikv-node)は、 [低速ストアの排除スケジューラ](https://docs.pingcap.com/tidb/v8.5/pd-control#scheduler-show--add--remove--pause--resume--config--describe)を使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。 - **統合ヘルスコントローラー**：TiKVに統合ヘルスコントローラーを追加し、KVクライアントにフィードバックメカニズムを追加します。KVクライアントは、TiKVノードのヘルスとパフォーマンスに基づいて、エラー処理とレプリカ選択を最適化します。 diff --git a/tidb-computing.md b/tidb-computing.md index 7e07dd5d674d5..e5191720ea89f 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -109,7 +109,7 @@ TiDB の SQLレイヤーである TiDB サーバーは、SQL ステートメン SQL コンピューティングの最もシンプルなソリューションは、前のセクションで説明した[テーブルデータからキー値へのマッピング](#mapping-of-table-data-to-key-value)です。これは、SQL クエリを KV クエリにマッピングし、KV インターフェイスを介して対応するデータを取得し、さまざまな計算を実行します。 -例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、5であればその行を返します。このプロセスは以下のとおりです。 +例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、そうであればその行を返します。このプロセスは以下のとおりです。 1. キー範囲を構築します。表内のすべての`RowID` `[0, MaxInt64)`範囲に含まれます。行データの`Key`エンコード規則に従って、 `0`と`MaxInt64`を使用すると、左閉じ、右開きの`[StartKey, EndKey)`範囲を構築できます。 2. キー範囲のスキャン: 上記で構築されたキー範囲に従って TiKV 内のデータを読み取ります。 diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 9eb76bbea3586..3932527970c09 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -20,7 +20,7 @@ summary: TiDB グローバル ソートの使用例、制限、使用方法、 ## 概要 {#overview} -TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。1 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 +TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。[TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)の汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 現在、グローバルソート機能は、クラウドストレージとして Amazon S3 の使用をサポートしています。 @@ -46,7 +46,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](/br/backup-and-restore-storages.md)参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。[例](/br/backup-and-restore-storages.md)を参照してください。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' @@ -55,7 +55,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。[例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)を参照してください。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index b09dda71f886f..40568f03f940c 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -68,13 +68,13 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `index-concurrency` {#index-concurrency} -- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。1と`table-concurrency` `index-concurrency`は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 #### `table-concurrency` {#table-concurrency} -- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。1と`table-concurrency` `index-concurrency`は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 7eb8b36abbf14..e1123d218190e 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -11,8 +11,8 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 -- バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。3 または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) `QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 -- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 +- バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)に`QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 +- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index f850e66c3a35a..617acae27905c 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -37,8 +37,8 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。1 `batch`バッチ要求の数です。3 `batch_cop`バッチ要求内のコプロセッサ要求の数です。5 `cop`コプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。7 `cop_dag`すべてのコプロセッサ要求内の DAG 要求の数です。9 `super_batch`スーパー バッチ機能を有効にするための要求の数です。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 +- 要求 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インスタンスのエラー数。1 `meet_lock`読み取りデータがロックされていることを意味します。3 `region_not_found`リージョンが存在しないことを意味します。5 `epoch_not_match`読み取りリージョンエポックがローカル エポックと一致していないことを意味します。7 `kv_client_error` TiKV との通信でエラーが返されたことを意味します`internal_error`はTiFlashの内部システム エラーです。11 `other`その他のタイプのエラーです。 - リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 @@ -62,7 +62,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## DDL {#ddl} - スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 -- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply`の3 `failed apply`の`apply`のカウントが含まれます。13 `diff apply`単一の適用の通常のプロセスです。15 `full apply`失敗した場合、 `diff apply` `failed apply` `1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 +- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 - スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 - スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index 41cadf172686c..28ccd8cad98c6 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -19,7 +19,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - このエラーは、何らかの間違ったロジックによって発生した可能性があります。1 [サポートを受ける](/support.md)またはコミュニティから。 + このエラーは、何らかの間違ったロジックによって発生した可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 ## `TiFlash_schema_apply_duration` {#tiflash-schema-apply-duration} @@ -33,7 +33,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 ## `TiFlash_raft_read_index_duration` {#tiflash-raft-read-index-duration} @@ -65,4 +65,4 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index 5c36a3d6599a8..95c79eac82837 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -52,9 +52,9 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - DTFile の基本的な I/O 速度テストを提供します。 - パラメータ: - - `--version` : DTFileのバージョン[`dttool migrate`における`--version`](#dttool-migrate)参照してください。 - - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。2 [`dttool migrate` `--algorithm`](#dttool-migrate)参照してください。 - - `--frame` : 検証フレームのサイズ[`dttool migrate`における`--frame`](#dttool-migrate)参照してください。 + - `--version` : DTFileのバージョン。[`dttool migrate`における`--version`](#dttool-migrate)を参照してください。 + - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。[`dttool migrate`における`--algorithm`](#dttool-migrate)を参照してください。 + - `--frame` : 検証フレームのサイズ。[`dttool migrate`における`--frame`](#dttool-migrate)を参照してください。 - `--column` : テストするテーブルの列。デフォルト値は`100`です。 - `--size` : テストするテーブルの行。デフォルト値は`1000`です。 - `--field` : テスト対象テーブルのフィールド長制限。デフォルト値は`1024`です。 @@ -76,6 +76,6 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - `--config-file` : `dttool bench`の設定ファイル[`dttool migrate`における`--config-file`](#dttool-migrate)参照してください。 - `--check` : ハッシュ検証を実行します。 - - `--file-id` ：DTFileのID。2 [`dttool migrate`における`--file-id`](#dttool-migrate)参照してください。 - - `--imitative` : データベースコンテキストを模倣します。2 [`dttool migrate`における`--imitative`](#dttool-migrate)参照してください。 - - `--workdir` : データディレクトリ。2 [`dttool migrate`における`--workdir`](#dttool-migrate)参照してください。 + - `--file-id` ：DTFileのID。[`dttool migrate`における`--file-id`](#dttool-migrate)を参照してください。 + - `--imitative` : データベースコンテキストを模倣します。[`dttool migrate`における`--imitative`](#dttool-migrate)を参照してください。 + - `--workdir` : データディレクトリ。[`dttool migrate`における`--workdir`](#dttool-migrate)を参照してください。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 40017e4c12b19..3998178926dc7 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -358,7 +358,7 @@ I/O トラフィック制限設定を構成します。 - 単一のクエリで生成される中間データのメモリ使用量の制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味します。 -- 値が 1 から`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 +- 値が`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値: `0` 、制限がないことを意味します。 @@ -366,7 +366,7 @@ I/O トラフィック制限設定を構成します。 - すべてのクエリで生成される中間データのメモリ使用量制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味し、 `0`制限なしを意味します。 -- v6.6.0以降では、 `[0.0, 1.0)`から10000000000000の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 +- v6.6.0以降では、 `[0.0, 1.0)`の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値： `0.8` （総メモリの80%を意味します）。v6.6.0より前のバージョンでは、デフォルト値は`0` （無制限を意味します）でした。 @@ -554,7 +554,7 @@ I/O トラフィック制限設定を構成します。 ##### `data-encryption-method` {#data-encryption-method} -- データファイルの暗号化方法。1以外の値は暗号化`"plaintext"`有効であることを意味します。その場合はマスターキーを指定する必要があります。 +- データファイルの暗号化方法。`"plaintext"`以外の値は暗号化が有効であることを意味します。その場合はマスターキーを指定する必要があります。 - デフォルト値: `"plaintext"` 。これは、暗号化がデフォルトで無効になっていることを意味します。 - `"aes256-ctr"` `"aes192-ctr"`オプション: `"aes128-ctr"` `"sm4-ctr"` `"plaintext"`で導入`"sm4-ctr"`れました。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 65a41299b59c8..c0246fd34b582 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -11,7 +11,7 @@ TiDBは、 TiFlashレプリカを読み取る3つの方法を提供します。 ## スマートな選択 {#smart-selection} -TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。1または`desc` `explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： +TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。`desc`または`explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： ```sql desc select count(*) from test.t; diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index ea1014de787f4..748ebe90ba6ab 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -17,7 +17,7 @@ summary: TiFlashの MPP モードとその使用方法を学びます。 -TiFlashは、クエリ実行にMPPモードをサポートしています。このモードでは、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。TiDBは、オプティマイザのコスト推定に基づいて、MPPモードを選択するかどうかを自動的に決定します。1と[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50) [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)値を変更することで、選択戦略を変更できます。 +TiFlashは、クエリ実行にMPPモードをサポートしています。このモードでは、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。TiDBは、オプティマイザのコスト推定に基づいて、MPPモードを選択するかどうかを自動的に決定します。[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50)と[`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)の値を変更することで、選択戦略を変更できます。 次の図は、MPP モードの動作を示しています。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 4373ac825acee..d75d43cab3c20 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1287,7 +1287,7 @@ Raftstoreに関連するコンフィグレーション項目。 > **Warning:** > > - `enable-region-bucket`は、TiDB v6.1.0 で導入された実験的機能です。本番環境での使用は推奨されません。 -> - この設定は、 `region-split-size` `region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 +> - この設定は、 `region-split-size`が`region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 > - `region-split-size`をより大きな値に調整すると、パフォーマンスの低下やスケジューリングの遅延のリスクが生じる可能性があります。 ### `region-bucket-size` v6.1.0の新機能 {#region-bucket-size-new-in-v610} diff --git a/time-to-live.md b/time-to-live.md index f50fb06b813b7..bf86eec7c1490 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -30,7 +30,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード ) TTL = `created_at` + INTERVAL 3 MONTH; ``` - 上記の例では、テーブル`t1`を作成し、TTLタイムスタンプ列に`created_at`指定しています。これはデータの作成時刻を示します。また、テーブル内で行が保持できる最長期間を 3 か月から`INTERVAL 3 MONTH`に設定しています。この値を超えて保持されるデータは、後で削除されます。 + 上記の例では、テーブル`t1`を作成し、TTLタイムスタンプ列に`created_at`を指定しています。これはデータの作成時刻を示します。また、テーブル内で行が保持できる最長期間を、 `INTERVAL 3 MONTH`によって 3 か月に設定しています。この値を超えて保持されるデータは、後で削除されます。 - 期限切れのデータをクリーンアップする機能を有効または無効にするには、 `TTL_ENABLE`属性を設定します。 diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index e8a602b4d7226..4b7f748465cb2 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -118,7 +118,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ 2. トポロジ ファイルを編集します。 - 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`行目を追加する必要があります。7パラメータ`systemd_mode` 、 `systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 + 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`の行を追加する必要があります。`systemd_mode`パラメータは、`systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 さらに、no-sudoモードでは、非rootユーザー`tidb`は`/data`ディレクトリを`deploy_dir`または`data_dir`として使用する権限がないため、非rootユーザーがアクセスできるパスを選択する必要があります。以下の例では相対パスを使用しており、実際に使用されるパスは`/home/tidb/data/tidb-deploy`と`/home/tidb/data/tidb-data`です。トポロジファイルの残りの部分は、通常モードと同じです。別の方法として、rootユーザーを使用してディレクトリを作成し、その後`chown`を使用して所有権を`tidb:tidb`に変更することもできます。 diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index 9a88eb7ecb625..308ca02bbf53c 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -5,7 +5,7 @@ summary: TiUPは、環境変数を用いた柔軟でカスタマイズされた # tiup env {#tiup-env} -TiUPは、ユーザーに柔軟でカスタマイズされたインターフェースを提供します。その一部は環境変数を使用して実装されています。1コマンド`tiup env` 、 TiUPがサポートするユーザー定義の環境変数とその値を照会するために使用されます。 +TiUPは、ユーザーに柔軟でカスタマイズされたインターフェースを提供します。その一部は環境変数を使用して実装されています。`tiup env`コマンドは、TiUPがサポートするユーザー定義の環境変数とその値を照会するために使用されます。 ## 構文 {#syntax} diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index 114f18c78a6a5..8b9a6a5f06c58 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -44,7 +44,7 @@ tiup mirror clone [global version] [flags] ### - {コンポーネント} {#component} -- クローンするコンポーネントのバージョンリストを指定します`{component}`にコンポーネント名を入力してください。3 [`tiup list --all`](/tiup/tiup-command-list.md)実行すると、使用可能なコンポーネント名が表示されます。 +- クローンするコンポーネントのバージョンリストを指定します`{component}`にコンポーネント名を入力してください。[`tiup list --all`](/tiup/tiup-command-list.md)を実行すると、使用可能なコンポーネント名が表示されます。 - データ型: 文字列 - デフォルト: Null diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 920d65217354e..f17d7b9c0bd69 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -74,7 +74,7 @@ THP が有効になっているかどうかを確認するには、次のコマ SELinuxを無効にするか、permissiveモードに設定する必要があります。現在のステータスを確認するには、 [ゲットエンフォース(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 -SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。7または`enforcing` `permissive` `disabled`への変更は、再起動しないと有効になりません。 +SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。`enforcing`または`permissive`から`disabled`への変更は、再起動しないと有効になりません。 一部のシステム（Ubuntuなど）では、 `/etc/selinux/config`ファイルが存在せず、getenforceユーティリティがインストールされていない場合があります。その場合は、この手順をスキップしてください。 diff --git a/tiup/tiup-component-cluster-clean.md b/tiup/tiup-component-cluster-clean.md index 30b8831004d8f..2092e0a7c6504 100644 --- a/tiup/tiup-component-cluster-clean.md +++ b/tiup/tiup-component-cluster-clean.md @@ -23,7 +23,7 @@ tiup cluster clean [flags] ### --all {#all} -- データとログを同時に消去します。1と`--data` `--log`同時に指定するのと同じです。 +- データとログを同時に消去します。`--data`と`--log`を同時に指定するのと同じです。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 - 指定されていない場合は、少なくとも次のいずれかのオプションを指定する必要があります。 diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 4388dc81d4405..72ce0bfd20711 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -19,7 +19,7 @@ tiup cluster display [flags] ### --dashboard {#dashboard} -- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。1オプションを指定すると、 `--dashboard`ボード情報のみが表示されます。 +- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。`--dashboard`オプションを指定すると、ダッシュボード情報のみが表示されます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-replay.md b/tiup/tiup-component-cluster-replay.md index 464699eb76c68..a22ed66ed0a97 100644 --- a/tiup/tiup-component-cluster-replay.md +++ b/tiup/tiup-component-cluster-replay.md @@ -13,7 +13,7 @@ summary: tiup cluster replay` コマンドを使用すると、失敗したク tiup cluster replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。6 [`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`番目を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index 6ecd4eca9ace2..982b8d1dd6da4 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -20,8 +20,8 @@ DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプ > - v2.0 にアップグレードする必要があるデータ移行タスクの場合、これらのタスクで`stop-task`実行しないでください。 > - このコマンドは、DM v2.0.0-rc.2 以降のバージョンへのインポートのみをサポートします。 > - `import`コマンドは、DM v1.0 クラスタを新しい DM v2.0 クラスタにインポートするために使用されます。既存の v2.0 クラスタにデータ移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 -> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なる場合`display`あります。1 コマンドで確認できます。 -> - クラスターをインポートする前に、 `tiup update --self && tiup update dm`実行してTiUP DMコンポーネントを最新バージョンにアップグレードします。 +> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なる場合があります。`display`コマンドで確認できます。 +> - クラスターをインポートする前に、 `tiup update --self && tiup update dm`を実行してTiUP DMコンポーネントを最新バージョンにアップグレードします。 > - クラスターをインポートすると、クラスター内のDMマスターノードは1つだけになります。DMマスターノードをスケールアウトするには、 [`scale out`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index 32eb8223bab68..5861f6af6719c 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -145,7 +145,7 @@ tiup dm patch [flags] 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 Total nodes: 5 - 指定されたノードまたは指定されたロールにホットフィックスを適用します。1と`-N` `-R`が指定されている場合は、共通部分が採用されます。 + 指定されたノードまたは指定されたロールにホットフィックスを適用します。`-N`と`-R`の両方が指定されている場合は、共通部分が採用されます。 # Apply hotfix to a specified node. tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8261 diff --git a/tiup/tiup-component-dm-replay.md b/tiup/tiup-component-dm-replay.md index fb75a637c3c2a..e805b5e1004f4 100644 --- a/tiup/tiup-component-dm-replay.md +++ b/tiup/tiup-component-dm-replay.md @@ -13,7 +13,7 @@ summary: tiup dm replay` コマンドを使用すると、失敗したクラス tiup dm replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。6 [`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`番目を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 66a907642412f..df4560b821ec0 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -93,8 +93,8 @@ server_configs: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。6を指定した場合、セクション`config` `config`設定が`server_configs` `master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 +- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 +- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 - `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 @@ -149,8 +149,8 @@ master_servers: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。6を指定した場合、セクション`config` `config`設定が`server_configs` `worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 +- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 +- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 - `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ba4809fba802..8acbf589f9c9a 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -33,8 +33,8 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック この問題を解決するには、 `tiup cluster deploy -i identity_file`実行して秘密鍵を指定したかどうかを確認します。 -- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。3 `-i`使用して秘密鍵のパスを明示的に指定することをお勧めします。 -- フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。3コマンド`ssh -i identity_file user@remote`手動で実行することで確認できます。 +- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。`-i`を使用して秘密鍵のパスを明示的に指定することをお勧めします。 +- フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。`ssh -i identity_file user@remote`コマンドを手動で実行することで確認できます。 - リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 ### TiUPクラスタコンポーネントを使用したクラスタのアップグレード プロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 9eb8c9f1f97b1..bde1d9e6e008b 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -80,7 +80,7 @@ v6.0.0以降、TiDBは、読み取り/書き込み競合が稀なシナリオに 分離レベル`READ-COMMITTED`が使用され、ステートメントが`SELECT`多く、読み取り/書き込みの競合がまれなシナリオでは、この変数を有効にすると、グローバル タイムスタンプを取得する際のレイテンシーとコストを回避できます。 -v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。3 [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)有効になっている場合も、TiDBは同様にデータを読み取ります。 +v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。[`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)が有効になっている場合も、TiDBは同様にデータを読み取ります。 現在、適用可能なポイント書き込みステートメントの種類は`UPDATE` 、 `DELETE` 、 `SELECT ...... FOR UPDATE`です。ポイント書き込みステートメントとは、主キーまたは一意キーをフィルター条件として使用し、最終実行演算子に`POINT-GET`含まれる書き込みステートメントを指します。現在、3種類のポイント書き込みステートメントに共通するのは、まずキー値に基づいてポイントクエリを実行することです。キーが存在する場合は、キーをロックします。キーが存在しない場合は、空のセットを返します。 diff --git a/transaction-overview.md b/transaction-overview.md index 4feb35adc3142..f60ca07e9b141 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -272,7 +272,7 @@ mysql> SELECT * FROM test; TiDBは楽観的トランザクションと悲観的トランザクションの両方をサポートしており、楽観的トランザクションは悲観的トランザクションの基盤となります。楽観的トランザクションはまず変更をプライベートメモリにキャッシュするため、TiDBは単一トランザクションのサイズを制限します。 -デフォルトでは、TiDB は単一トランザクションの合計サイズを 100 MB 以下に設定します。このデフォルト値は、設定ファイルで`txn-total-size-limit`設定することで変更できます。最大値は`txn-total-size-limit`で、1 TB です。個々のトランザクションのサイズ制限は、サーバーで使用可能なメモリの残り容量にも依存します。これは、トランザクションの実行時に、TiDB プロセスのメモリ使用量がトランザクションサイズと比較して、最大でトランザクションサイズの 2 ～ 3 倍以上にまで増加するためです。 +デフォルトでは、TiDB は単一トランザクションの合計サイズを 100 MB 以下に設定します。このデフォルト値は、設定ファイルで`txn-total-size-limit`を設定することで変更できます。 `txn-total-size-limit`の最大値は 1 TB です。個々のトランザクションのサイズ制限は、サーバーで使用可能なメモリの残り容量にも依存します。これは、トランザクションの実行時に、TiDB プロセスのメモリ使用量がトランザクションサイズと比較して、最大でトランザクションサイズの 2 ～ 3 倍以上にまで増加するためです。 TiDBでは以前、1トランザクションあたりのキーと値のペアの総数が300,000個に制限されていました。この制限はTiDB v4.0で削除されました。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index c28665f9290ce..74a3abb33087b 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -50,7 +50,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - サーバーの負荷が高いです。ログには`server is likely overloaded`表示されています。 -- PD がLeaderを選出できません: PD ログには`lease is not expired`表示されます。3 [この号](https://github.com/etcd-io/etcd/issues/10355) v3.0.x および v2.1.19 で修正されました。 +- PD がLeaderを選出できません: PD ログには`lease is not expired`が表示されます。[この号](https://github.com/etcd-io/etcd/issues/10355)は v3.0.x および v2.1.19 で修正されました。 - リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index a4807918253a8..680200bbf0a37 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -55,7 +55,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ - `apply log`は遅いです。TiKV Grafana の`Raft I/O`と`apply log duration`指標は比較的高く、これは通常、 `Raft Propose` / `apply wait duration`指標も比較的高い場合に発生します。考えられる原因は次のとおりです。 - - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`から大きすぎない範囲に設定することをお勧めします。7と`Thread CPU` `apply cpu`比較的高い値です。 + - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`の範囲で、大きすぎないように設定することをお勧めします。`Thread CPU`/`apply cpu`の値も比較的高くなっています。 - マシンの CPU リソースが不足しています。 - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`追加することで確認できます）。 - RocksDBへの書き込み速度が遅く、 `RocksDB kv` / `max write duration`高い値です。1つのRaftログには複数のキーと値のペア（kv）が含まれる場合があります。128 kvが一括でRocksDBに書き込まれるため、 `apply`ログ1つにつきRocksDBへの書き込みが複数回発生する可能性があります。 diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 41d0c8121021a..2a3b834f7f4e0 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -59,10 +59,10 @@ TiDBログを検索するキーワードとして`[kv:9007]Write conflict`を使 上記のログの説明は次のとおりです。 - `[kv:9007]Write conflict` : 書き込み間の競合を示します。 -- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`示します。4ツール`pd-ctl`使用して、 `start_ts`物理時間に変換できます。 -- `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`示します。 -- `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`示します。 -- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。2 `tableID`書き込み競合テーブルのIDを示します。4 `indexID`書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力。8 `indexValues`競合が発生しているインデックスの値を示します。 +- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`を示します。`pd-ctl`ツールを使用して、 `start_ts`を物理時間に変換できます。 +- `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`を示します。 +- `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`を示します。 +- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。`tableID`書き込み競合テーブルのIDを示します。`indexID`書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力。`indexValues`競合が発生しているインデックスの値を示します。 - `primary={tableID=47, indexID=1, indexValues={string, }}` : 現在のトランザクションの主キー情報を示します。 `pd-ctl`ツールを使用して、タイムスタンプを読み取り可能な時間に変換できます。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index d02329a6ae874..3cef0218acbde 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -64,7 +64,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - StoreWriterスレッドプールのサイズが0の場合、すべての書き込みリクエストはRaftstoreスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。RaftstoreRaftstore数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 + - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。Raftstoreスレッド数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッド プールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 - StoreWriterスレッドプールのサイズが0でない場合、すべての書き込みリクエストはStoreWriterスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index aedbcf6f2084a..e7b63373c4cb0 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -142,7 +142,7 @@ tiup update cluster tiup cluster edit-config ``` -2. フォーマットを参照[トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 +2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するには「Y」と入力してください。