diff --git a/as-of-timestamp.md b/as-of-timestamp.md index 135eb7059d303..0a5c177fe05d5 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -21,9 +21,9 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 - [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) - [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md) -正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 +正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 -時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。 +時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。 `AS OF TIMESTAMP`句の例をいくつか示します。 diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index f1cc155bef27b..66f151af2fa32 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -62,7 +62,7 @@ TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複 ALTER DATABASE tpcc SET tiflash replica 2; -`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。3 句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句`WHERE`削除します。 +`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。`WHERE`句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句を削除します。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; diff --git a/benchmark/online-workloads-and-add-index-operations.md b/benchmark/online-workloads-and-add-index-operations.md index ff17cb1a4a9b7..66f1f1f4ce19d 100644 --- a/benchmark/online-workloads-and-add-index-operations.md +++ b/benchmark/online-workloads-and-add-index-operations.md @@ -82,7 +82,7 @@ sysbench $testname \ ## テストプラン1: ADD INDEX文の対象列への書き込み操作を頻繁に実行する {#test-plan-1-frequently-perform-write-operations-to-the-target-column-of-the-code-add-index-code-statement} 1. `oltp_read_write`テストを開始します。 -2. 手順`alter table sbtest1 add index c_idx(c)`と同時に実行します。1 を使用してインデックスを追加します。 +2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_write`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 @@ -217,7 +217,7 @@ sysbench $testname \ ## テストプラン 2: ADD INDEXステートメントのターゲット列への書き込み操作を実行しない (クエリのみ) {#test-plan-2-do-not-perform-write-operations-to-the-target-column-of-the-code-add-index-code-statement-query-only} 1. `oltp_read_only`テストを開始します。 -2. 手順`alter table sbtest1 add index c_idx(c)`と同時に実行します。1 を使用してインデックスを追加します。 +2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 @@ -279,7 +279,7 @@ sysbench $testname \ ## テストプラン3: ADD INDEX文のターゲット列はオンラインワークロードとは無関係です {#test-plan-3-the-target-column-of-the-code-add-index-code-statement-is-irrelevant-to-online-workloads} 1. `oltp_read_write`テストを開始します。 -2. 手順`alter table test add index pad_idx(pad)`と同時に実行します。1 を使用してインデックスを追加します。 +2. 手順 1 と同時に実行します。`alter table test add index pad_idx(pad)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index c05ad675ed769..9edc0c9a53e08 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -213,7 +213,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。 - - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。1 または`region-schedule-limit` `leader-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 + - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。 - スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 @@ -229,8 +229,8 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー オペレーターは正常に生成されたが、スケジュール プロセスが遅い場合は、次の理由が考えられます。 -- スケジューリング速度はデフォルトで制限されています。1 または`leader-schedule-limit` `replica-schedule-limit`値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 -- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。 +- スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 +- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 - 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。 @@ -240,7 +240,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー ### ノードをオンラインにするのが遅い {#bringing-nodes-online-is-slow} -現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leaders-regions-are-not-evenly-distributed)を参照してください。 +現在、ノードのオンライン化はバランスリージョンメカニズムを通じてスケジュールされています。トラブルシューティングについては[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 ### ホットリージョンが均等に分布していない {#hot-regions-are-not-evenly-distributed} 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/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index dbc9bf6040a6a..c6b04fbf9fd6c 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -22,7 +22,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `backup` : `tiup br`のサブコマンド。 - `full` : `tiup br backup`のサブコマンド。 -- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。4 は`"s3://backup-data/snapshot-202209081330/"` `-s`パラメーターです。 +- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。`"s3://backup-data/snapshot-202209081330/"`は`-s`のパラメーターです。 - `--pd` : PD サービス アドレスを指定するオプション`"${PD_IP}:2379"`は`--pd`のパラメーターです。 ### コマンドとサブコマンド {#commands-and-sub-commands} @@ -65,7 +65,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ ## フルバックアップのコマンド {#commands-of-full-backup} -クラスターデータをバックアップするには、 `tiup br backup`コマンドを実行します。3 または`full` `table`コマンドを追加して、バックアップ操作の範囲（クラスター全体（ `full` ）または単一のテーブル（ `table` ））を指定できます。 +クラスターデータをバックアップするには、 `tiup br backup`コマンドを実行します。`full`または`table`サブコマンドを追加して、バックアップ操作の範囲（クラスター全体（ `full` ）または単一のテーブル（ `table` ））を指定できます。 - [TiDB クラスターのスナップショットをバックアップする](/br/br-snapshot-manual.md#back-up-cluster-snapshots) - [データベースをバックアップする](/br/br-snapshot-manual.md#back-up-a-database) diff --git a/cached-tables.md b/cached-tables.md index 7f28b90f0646d..c565a15ee15ca 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -72,7 +72,7 @@ SHOW CREATE TABLE users; 1 row in set (0.00 sec) ``` -キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。1 文[`TRACE`](/sql-statements/sql-statement-trace.md)使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 +キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。[`TRACE`](/sql-statements/sql-statement-trace.md)文を使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 ```sql TRACE SELECT * FROM users; diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index cc1892edc14cc..e2711e3a90c72 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -230,7 +230,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 #### バッチ関連パラメータ {#batch-related-parameters} -バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。3 または`executeBatch()` `addBatch()`使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: +バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。`addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: ```java pstmt = prepare("INSERT INTO `t` (a) values(?)"); @@ -296,7 +296,7 @@ UPDATE `t` SET `a` = 10 WHERE `id` = 1; UPDATE `t` SET `a` = 11 WHERE `id` = 2; #### タイムアウト関連のパラメータ {#timeout-related-parameters} -TiDB はタイムアウトを制御するために 2 つの MySQL 互換パラメータ ( [`wait_timeout`](/system-variables.md#wait_timeout)と[`max_execution_time`](/system-variables.md#max_execution_time) ) を提供します。これらの 2 つのパラメータはそれぞれ、 Javaアプリケーションとの接続アイドルタイムアウトと接続内の SQL 実行のタイムアウトを制御します。つまり、これらのパラメータは、TiDB とJavaアプリケーション間の接続の最長アイドル時間と最長ビジー時間を制御します。TiDB v5.4 以降、 `wait_timeout`のデフォルト値は`28800`秒で、8 時間です。v5.4 より前の TiDB バージョンでは、デフォルト値は`0`で、タイムアウトは無制限です。11 のデフォルト値は`max_execution_time` `0` 、SQL ステートメントの最大実行時間は無制限であり、 `SELECT`ステートメントすべて ( `SELECT ... FOR UPDATE`を含む) に適用されます。 +TiDB はタイムアウトを制御するために 2 つの MySQL 互換パラメータ ( [`wait_timeout`](/system-variables.md#wait_timeout)と[`max_execution_time`](/system-variables.md#max_execution_time) ) を提供します。これらの 2 つのパラメータはそれぞれ、 Javaアプリケーションとの接続アイドルタイムアウトと接続内の SQL 実行のタイムアウトを制御します。つまり、これらのパラメータは、TiDB とJavaアプリケーション間の接続の最長アイドル時間と最長ビジー時間を制御します。TiDB v5.4 以降、 `wait_timeout`のデフォルト値は`28800`秒で、8 時間です。v5.4 より前の TiDB バージョンでは、デフォルト値は`0`で、タイムアウトは無制限です。`max_execution_time`のデフォルト値は`0`で、SQL ステートメントの最大実行時間は無制限であり、 `SELECT`ステートメントすべて ( `SELECT ... FOR UPDATE`を含む) に適用されます。 デフォルト値の[`wait_timeout`](/system-variables.md#wait_timeout)は比較的大きな値です。トランザクションが開始されてもコミットもロールバックもされないような状況では、ロックの保持時間が長引くのを防ぐために、よりきめ細かな制御と短いタイムアウトが必要になる場合があります。このような場合は、 [`tidb_idle_transaction_timeout`](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760) （TiDB v7.6.0で導入）を使用して、ユーザーセッション内のトランザクションのアイドルタイムアウトを制御できます。 diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 35cb5cf3fa3dc..29ac3c6448192 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -260,7 +260,7 @@ ORDER BY page_num; たとえば、次のようにして`ratings`テーブル内のデータのページング バッチを実装できます。 -以下のステートメントを使用してメタ情報テーブルを作成します。5 種類の`book_id`と`user_id`を連結したキーは、同じ長さに変換できないため、 `bigint`の最大ビット数である`LPAD` `bigint`を使用して`0`をパディングします。 +以下のステートメントを使用してメタ情報テーブルを作成します。`bigint`型の`book_id`と`user_id`を連結したキーは、同じ長さに変換できないため、 `bigint`の最大ビット数である 19 に従って`LPAD`関数を使用して`0`をパディングします。 ```sql SELECT diff --git a/develop/dev-guide-sql-development-specification.md b/develop/dev-guide-sql-development-specification.md index 7bbc85e85417d..c75c27a07c32c 100644 --- a/develop/dev-guide-sql-development-specification.md +++ b/develop/dev-guide-sql-development-specification.md @@ -42,7 +42,7 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl ## その他の仕様 {#other-specifications} - 条件`WHERE`のインデックス列に対して数学演算や関数を実行しないでください。 -- `OR` `IN`または`UNION`に置き換えてください。7 の数は`IN` `300`でなければなりません。 +- `OR`を`IN`または`UNION`に置き換えてください。`IN`の数は`300`未満でなければなりません。 - あいまいプレフィックスクエリには`%`プレフィックスを使用しないでください。 - アプリケーションが**マルチステートメント**を使用して SQL を実行する場合、つまり複数の SQL がセミコロンで結合され、一度にクライアントに送信されて実行される場合、TiDB は最初の SQL 実行の結果のみを返します。 - 式を使用する場合は、その式がストレージレイヤー（TiKVまたはTiFlash ）へのコンピューティングのプッシュダウンをサポートしているかどうかを確認してください。サポートされていない場合は、TiDBレイヤーでメモリ消費量が増加し、OOMが発生する可能性が高くなります。ストレージレイヤーにプッシュダウンできるコンピューティングは以下の通りです。 diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index e7d8f71c82944..9cd5058d38fdc 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -125,7 +125,7 @@ TiDB に`enablePacketDebug`パラメータを設定しないでください。 **説明** -TiDB は`UpdatableResultSet`サポートしていません。5 パラメータ`ResultSet.CONCUR_UPDATABLE`指定**しないでください**。また、 `ResultSet`内のデータを更新**しないでください**。 +TiDB は`UpdatableResultSet`サポートしていません。`ResultSet.CONCUR_UPDATABLE`パラメータを指定**しないでください**。また、 `ResultSet`内のデータを更新**しないでください**。 **回避方法** diff --git a/develop/dev-guide-unique-serial-number-generation.md b/develop/dev-guide-unique-serial-number-generation.md index 8c3c2a9eb6c0d..1815266022887 100644 --- a/develop/dev-guide-unique-serial-number-generation.md +++ b/develop/dev-guide-unique-serial-number-generation.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-unique-serial-number-generation/','/ja/tidb ## AUTO_INCREMENT列 {#auto-increment-column} -`AUTO_INCREMENT`は、MySQL プロトコルと互換性のある多くの RDBMS の列属性です。2 属性を使用すると、データベースはユーザーの介入なしにこの列に自動的に値を割り当てることができます。テーブル内のレコード数が増加すると、この列の値は自動的に増加し、一意であることが保証されます。 `AUTO_INCREMENT`のシナリオでは、 `AUTO_INCREMENT`列は実際には意味を持たない代理主キーとして使用されます。 +`AUTO_INCREMENT`は、MySQL プロトコルと互換性のある多くの RDBMS の列属性です。`AUTO_INCREMENT`属性を使用すると、データベースはユーザーの介入なしにこの列に自動的に値を割り当てることができます。テーブル内のレコード数が増加すると、この列の値は自動的に増加し、一意であることが保証されます。 `AUTO_INCREMENT`のシナリオでは、 `AUTO_INCREMENT`列は実際には意味を持たない代理主キーとして使用されます。 `AUTO_INCREMENT`列の制限は、列が整数型でなければならず、割り当てられる値も整数でなければならないことです。アプリケーションで必要なシリアル番号が文字、数字、その他の文字で区切られている場合、ユーザーは`AUTO_INCREMENT`列を通してシリアル番号に必要なAUTO_INCREMENT番号を取得することが困難になります。 diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 8dc3eca7d1295..3b4837f472ad8 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -255,7 +255,7 @@ func placeHolder(n int) string { } ``` -各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `1000`は { `ten_point`の最大`false` PLACEHOLDER-1-PLACEHOLDER-E}} まで主キー値を選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`time.Sleep(time.Second)`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 +各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`time.Sleep(time.Second)`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 @@ -421,7 +421,7 @@ public class BatchUpdateExample { ``` -各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `1000`は { `ten_point`の最大`false` PLACEHOLDER-1-PLACEHOLDER-E}} まで主キー値を選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`TimeUnit.SECONDS.sleep(1);`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 +各イテレーションでは、 `SELECT`主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`TimeUnit.SECONDS.sleep(1);`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index 695c1b562ff56..50fb0494f9592 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -159,7 +159,7 @@ FROM まず、CTEブロック`books_authored_by_rm`で著者（ID `2299112019` ）が執筆した書籍を調べます。次に、 `books_with_average_ratings`と`books_with_orders`でこれらの書籍の平均評価と順位をそれぞれ求めます。最後に、 `JOIN`ステートメントで結果を集計します。 -`books_authored_by_rm`のクエリは一度だけ実行され、その後 TiDB は結果をキャッシュするための一時領域を作成することに注意してください。3 と`books_with_orders` `books_with_average_ratings`クエリが`books_authored_by_rm`を参照する場合、TiDB はこの一時領域から直接結果を取得します。 +`books_authored_by_rm`のクエリは一度だけ実行され、その後 TiDB は結果をキャッシュするための一時領域を作成することに注意してください。`books_with_average_ratings`と`books_with_orders`のクエリが`books_authored_by_rm`を参照する場合、TiDB はこの一時領域から直接結果を取得します。 > **Tip:** > diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 7689f54b6da30..403b8015bf23e 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -195,7 +195,7 @@ dmctl --master-addr=127.0.0.1:8261 validation start --start-time 2021-10-21T00:0 dmctl は 3 つのエラー処理コマンドを提供します。 -- `clear-error` : エラー行をクリアします。2 コマンド`show-error`実行すると、エラー行は表示されなくなります。 +- `clear-error` : エラー行をクリアします。`show-error`コマンドを実行すると、エラー行は表示されなくなります。 Usage: dmctl validation clear-error [flags] diff --git a/dm/dm-stop-task.md b/dm/dm-stop-task.md index 1c65c2c378b08..3ddfe61948af2 100644 --- a/dm/dm-stop-task.md +++ b/dm/dm-stop-task.md @@ -5,7 +5,7 @@ summary: データ移行タスクを停止する方法を学びます。 # データ移行タスクを停止する {#stop-a-data-migration-task} -`stop-task`コマンドを使用してデータ移行タスクを停止できます。3 と`stop-task` `pause-task`違いについては、 [データ移行タスクを一時停止する](/dm/dm-pause-task.md)を参照してください。 +`stop-task`コマンドを使用してデータ移行タスクを停止できます。`stop-task`と`pause-task`の違いについては、 [データ移行タスクを一時停止する](/dm/dm-pause-task.md)を参照してください。 ```bash help stop-task diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 3ecfc18555a5f..1845a110340d5 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -123,7 +123,7 @@ AWS KMS を使用してマスターキーを指定するには、TiKV 設定フ region = "us-west-2" endpoint = "https://kms.us-west-2.amazonaws.com" -`key-id` KMS CMK のキー ID を指定します。3 `region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)使用する必要がある場合を除き、通常は指定する必要はありません。 +`key-id`は KMS CMK のキー ID を指定します。`region`は KMS CMK の AWS リージョン名です。`endpoint`はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)を使用する必要がある場合を除き、通常は指定する必要はありません。 AWSでも[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)使用できます。この場合、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。 diff --git a/explain-aggregation.md b/explain-aggregation.md index 57a57cab71f15..e7927a26c4f6f 100644 --- a/explain-aggregation.md +++ b/explain-aggregation.md @@ -65,7 +65,7 @@ EXPLAIN SELECT COUNT(*) FROM t1; 4 rows in set (0.00 sec) ``` -これは`EXPLAIN ANALYZE`で最も簡単に確認できます。1 では、 `TableFullScan`使用されており、セカンダリ インデックスがないため、 `actRows` `SHOW TABLE REGIONS`のリージョンの数と一致しています。 +これは`EXPLAIN ANALYZE`で最も簡単に確認できます。`EXPLAIN ANALYZE`では、 `TableFullScan`が使用されており、セカンダリ インデックスがないため、 `actRows`は`SHOW TABLE REGIONS`のリージョンの数と一致しています。 ```sql EXPLAIN ANALYZE SELECT COUNT(*) FROM t1; diff --git a/explain-mpp.md b/explain-mpp.md index 644952d30c1a7..25b608683c532 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -29,7 +29,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 GROUP BY id; ## Exchange 演算子 {#exchange-operators} -`ExchangeReceiver`と`ExchangeSender` 、MPP実行プランに特有の2つの交換演算子です。4 演算子`ExchangeReceiver`下流のクエリフラグメントからデータを読み取り、 `ExchangeSender`演算子は下流のクエリフラグメントから上流のクエリフラグメントにデータを送信します。MPPモードでは、各MPPクエリフラグメントのルート演算子は`ExchangeSender`です。つまり、クエリフラグメントは`ExchangeSender`演算子によって区切られます。 +`ExchangeReceiver`と`ExchangeSender` 、MPP実行プランに特有の2つの交換演算子です。`ExchangeReceiver`演算子は下流のクエリフラグメントからデータを読み取り、 `ExchangeSender`演算子は下流のクエリフラグメントから上流のクエリフラグメントにデータを送信します。MPPモードでは、各MPPクエリフラグメントのルート演算子は`ExchangeSender`です。つまり、クエリフラグメントは`ExchangeSender`演算子によって区切られます。 以下は単純な MPP 実行プランです。 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/functions-and-operators/cast-functions-and-operators.md b/functions-and-operators/cast-functions-and-operators.md index 88476a7c03f5f..6c67d2076cfa6 100644 --- a/functions-and-operators/cast-functions-and-operators.md +++ b/functions-and-operators/cast-functions-and-operators.md @@ -35,7 +35,7 @@ MySQL 8.0.27以降、 [`BINARY`](https://dev.mysql.com/doc/refman/8.0/en/cast-fu | `CHAR(n)` | 文字列 | はい、ただし長さが指定されている場合のみ | | `DATE` | 日付 | はい | | `DATETIME(fsp)` | 日付/時刻（ `fsp`はオプション） | はい | -| `DECIMAL(n, m)` | `n`進数。1 と`m`オプションで、指定しない場合は`10`と`0`になります。 | いいえ | +| `DECIMAL(n, m)` | 10進数。`n`と`m`はオプションで、指定しない場合は`10`と`0`になります。 | いいえ | | `DOUBLE` | 倍精度浮動小数点数 | いいえ | | `FLOAT(n)` | 浮動小数点数`n`オプションで、 `0`から`53`の範囲で指定します。 | いいえ | | `JSON` | JSON | いいえ | diff --git a/functions-and-operators/encryption-and-compression-functions.md b/functions-and-operators/encryption-and-compression-functions.md index 11537a962f906..0807e047b1a29 100644 --- a/functions-and-operators/encryption-and-compression-functions.md +++ b/functions-and-operators/encryption-and-compression-functions.md @@ -185,7 +185,7 @@ SELECT SHA1('abc'); ### `SHA2()` {#sha2} -`SHA2(str, n)`関数は`n` [SHA-2](https://en.wikipedia.org/wiki/SHA-2)ファミリーのアルゴリズムを使用してハッシュを計算します。5 引数はアルゴリズムを選択するために使用されます。7 `SHA2()` 、引数のいずれかが`NULL`の場合、または`n`で選択されたアルゴリズムが不明またはサポートされていない場合、 `NULL`返します。 +`SHA2(str, n)`関数は[SHA-2](https://en.wikipedia.org/wiki/SHA-2)ファミリーのアルゴリズムを使用してハッシュを計算します。`n`引数はアルゴリズムを選択するために使用されます。`SHA2()`は、引数のいずれかが`NULL`の場合、または`n`で選択されたアルゴリズムが不明またはサポートされていない場合、 `NULL`を返します。 サポートされているアルゴリズムは次のとおりです。 diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 2bfaa2988f863..60547bfc638a1 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -32,7 +32,7 @@ SELECT count(1) FROM t GROUP BY a,b,c WITH ROLLUP; ## ユースケース {#use-cases} -複数`WITH ROLLUP`列からのデータの集計と要約は、OLAP（オンライン分析処理）シナリオでよく使用されます。1 修飾子を使用すると、集計結果に他の高レベルディメンションからのスーパーサマリー情報を表示する行を追加できます。これにより、スーパーサマリー情報を高度なデータ分析やレポート作成に活用できます。 +複数の列からのデータの集計と要約は、OLAP（オンライン分析処理）シナリオでよく使用されます。`WITH ROLLUP`修飾子を使用すると、集計結果に他の高レベルディメンションからのスーパーサマリー情報を表示する行を追加できます。これにより、スーパーサマリー情報を高度なデータ分析やレポート作成に活用できます。 ## 前提条件 {#prerequisites} @@ -100,7 +100,7 @@ SELECT year, month, SUM(profit) AS profit from bank GROUP BY year, month WITH RO 6 rows in set (0.025 sec) ``` -上記の結果には、年と月の両方、年ごと、全体という異なるディメンションで集計されたデータが含まれています。結果において、 `NULL`値が存在しない行は、その行の`profit`年と月の両方をグループ化して計算されていることを示します。7 列の値が`NULL`で`month`行は、その行の`profit` 1 年間のすべての月を集計して計算されていることを示し、 `year`列の値が`NULL`である行は、その行の`profit`すべての年を集計して計算されていることを示します。 +上記の結果には、年と月の両方、年ごと、全体という異なるディメンションで集計されたデータが含まれています。結果において、 `NULL`値が存在しない行は、その行の`profit`年と月の両方をグループ化して計算されていることを示します。`month`列の値が`NULL`である行は、その行の`profit`が 1 年間のすべての月を集計して計算されていることを示し、 `year`列の値が`NULL`である行は、その行の`profit`すべての年を集計して計算されていることを示します。 具体的には： diff --git a/functions-and-operators/json-functions/json-functions-search.md b/functions-and-operators/json-functions/json-functions-search.md index 3ca624b0e3a37..7fc8bd6f542c5 100644 --- a/functions-and-operators/json-functions/json-functions-search.md +++ b/functions-and-operators/json-functions/json-functions-search.md @@ -184,7 +184,7 @@ FROM ( ## `JSON_KEYS()` {#json-keys} -`JSON_KEYS(json_doc [,path])`関数は、JSONオブジェクトの最上位キーをJSON配列として返します。3 引数`path`指定された場合は、選択されたパスの最上位キーを返します。 +`JSON_KEYS(json_doc [,path])`関数は、JSONオブジェクトの最上位キーをJSON配列として返します。`path`引数が指定された場合は、選択されたパスの最上位キーを返します。 例: diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index bf33fc04d5a2b..fac7a9f5a56d6 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -928,7 +928,7 @@ SELECT LENGTH(NULL); ### `LIKE` {#like} -`LIKE`演算子は単純な文字列マッチングに使用されます。式`expr LIKE pat [ESCAPE 'escape_char']` `1` ( `TRUE` ) または`0` ( `FALSE` ) を返します。13 または`expr` `pat`いずれかが`NULL`の場合、結果は`NULL`なります。 +`LIKE`演算子は単純な文字列マッチングに使用されます。式`expr LIKE pat [ESCAPE 'escape_char']` `1` ( `TRUE` ) または`0` ( `FALSE` ) を返します。`expr`または`pat`のいずれかが`NULL`の場合、結果は`NULL`になります。 `LIKE`では次の 2 つのワイルドカード パラメータを使用できます。 diff --git a/global-indexes.md b/global-indexes.md index 587ed3a045ff6..1bb1c5c6c0356 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -203,7 +203,7 @@ CREATE TABLE `sbtest` ( ) partition by hash(id) partitions 5; ``` -前述のテーブルスキーマを例に挙げましょう。1 `idx`ローカルインデックス、 `global_idx`はグローバルインデックスです。5 のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など`idx`つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 +前述のテーブルスキーマを例に挙げましょう。1 `idx`ローカルインデックス、 `global_idx`はグローバルインデックスです。`idx`のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など 5 つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 `k`に関連するクエリ（例えば`SELECT * FROM sbtest WHERE k > 1`を実行すると、ローカルインデックス`idx`は5つの個別の範囲を生成しますが、グローバルインデックス`global_idx`は1つの範囲のみを生成します。TiDBの各範囲は1つ以上のRPCリクエストに対応するため、グローバルインデックスを使用することでRPCリクエストの数を数倍削減でき、インデックスクエリのパフォーマンスが向上します。 diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index b2c42ee3a31f6..f44cc1ec9af75 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -31,7 +31,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | PD | ホットリードリージョンのリーダー分布 | 各 TiKV インスタンス上の読み取りホットスポットであるリーダーの合計数。 | | | PD | リージョンのハートビートレポート | インスタンスごとに PD に報告されたハートビートの数。 | | | PD | 99%リージョンハートビートレイテンシー | TiKV インスタンスごとのハートビートレイテンシー(P99)。 | | -| TiDB | ステートメントOPS | 1 秒あたりに実行される異なるタイプの SQL ステートメントの数。1 、 `SELECT` 、 `UPDATE`など`INSERT`ステートメントのタイプに応じてカウントされます。 | | +| TiDB | ステートメントOPS | 1 秒あたりに実行される異なるタイプの SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`などのステートメントのタイプに応じてカウントされます。 | | | TiDB | 間隔 | 実行時間。
1. クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後にクライアントに返されるまでの時間。通常、クライアント要求はSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。
2. TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ように複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 | | | TiDB | インスタンスごとのCPS | インスタンス別 CPS: コマンド実行結果の成功または失敗に応じて分類された、各 TiDB インスタンスのコマンド統計。 | | | TiDB | クエリ OPM の失敗 | 各TiDBインスタンスにおける1秒あたりのSQL文実行時に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 | | diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 058013252f195..53aeb6e49785f 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -134,7 +134,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - PDサーバTSO処理時間とクライアント受信時間: PDがTSO要求を受信してからPDクライアントがTSO応答を受信するまでの時間 - 処理要求数: TiDB 要求の数 -- リクエスト処理時間: TiDBリクエストの処理に要した時間。1 (P99) `100ms`である必要があります。 +- リクエスト処理時間: TiDBリクエストの処理に要した時間。(P99) は`100ms`未満である必要があります。 ![PD Dashboard - TiDB metrics](/media/pd-dashboard-tidb-v4.png) diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index a669748df2459..4e39e66b4308b 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -180,7 +180,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_dag` : すべてのコプロセッサ要求内の DAG 要求の数。 - `super_batch` : スーパーバッチ機能を有効にするリクエストの数。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。`selection`は選択 Executor です。 `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 - リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエスト タイプについて、1 秒あたりの合計処理時間の積み上げグラフを提供します。 - リクエスト期間: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - リクエスト処理時間：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 715650dfe473f..98f305af729c2 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -45,4 +45,4 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en - 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 - 成功した KV 要求の待機期間 (99/90): 各リソース コントローラー クライアントの成功した KV 要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 - トークン要求処理期間 (999/99): 各リソース コントローラー クライアントのサーバー側からのトークン要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 -- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソース グループごとに計算されます。1 と`failed` `successful`すべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 +- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソース グループごとに計算されます。`successful`と`failed`はすべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index 91f0ab0f9ab88..0c5e759bbf59e 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -37,7 +37,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて - TiKVの設定を最適化する - - `readpool`スレッドプールに自己適応するように設定します。3 パラメータ`readpool.unified.max-thread-count`設定することで、 `readpool.storage`と`readpool.coprocessor`統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 + - `readpool`スレッドプールに自己適応するように設定します。`readpool.unified.max-thread-count`パラメータを設定することで、 `readpool.storage`と`readpool.coprocessor`統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 - `readpool.storage`と`readpool.coprocessor`有効にする: diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index 17a85f37bea7e..c1ff0f6a56eca 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -44,7 +44,7 @@ TiKVコプロセッサータスク関連フィールド: - `wait_time` : TiKV 内のステートメントにおけるすべてのコプロセッサー要求の合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合でも、要求がキューイングされる可能性があります。キュー内の要求の処理に時間がかかる場合、後続の要求の待機時間が増加します。 - `request_count` : ステートメントが送信するコプロセッサー要求の数。 - `total_keys` :コプロセッサーがスキャンしたキーの数。 -- `processed_keys` :コプロセッサーが処理したキーの数。2 と比較すると、 `total_keys` `processed_keys`古いバージョンの MVCC は含まれません。6 と`processed_keys` `total_keys`差が大きいことから、古いバージョンが多数存在することがわかります。 +- `processed_keys` :コプロセッサーが処理したキーの数。`total_keys`と比較すると、 `processed_keys`には古いバージョンの MVCC は含まれません。`processed_keys`と`total_keys`の差が大きいことから、古いバージョンが多数存在することがわかります。 - `num_cop_tasks` : ステートメントが送信するコプロセッサー要求の数。 - `process_avg_time` :コプロセッサータスクの平均実行時間。 - `process_p90_time` :コプロセッサータスクの P90 実行時間。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index a679b1825ca7b..a1dba1822040f 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -7,7 +7,7 @@ summary: INSPECTION_RESULT` 診断結果テーブルを確認します。 TiDB には、システム内の障害や隠れた問題を検出するための診断ルールがいくつか組み込まれています。 -`INSPECTION_RESULT`診断テーブルは、問題を迅速に発見し、手作業の繰り返しを削減するのに役立ちます。3 ステートメント`select * from information_schema.inspection_result`使用して、内部診断をトリガーできます。 +`INSPECTION_RESULT`診断テーブルは、問題を迅速に発見し、手作業の繰り返しを削減するのに役立ちます。`select * from information_schema.inspection_result`ステートメントを使用して、内部診断をトリガーできます。 > **Note:** > diff --git a/information-schema/information-schema-inspection-summary.md b/information-schema/information-schema-inspection-summary.md index d2923fb77cf2b..dc7b108cf1d32 100644 --- a/information-schema/information-schema-inspection-summary.md +++ b/information-schema/information-schema-inspection-summary.md @@ -40,7 +40,7 @@ DESC inspection_summary; - `RULE` : 要約ルール。新しいルールは継続的に追加されるため、 `select * from inspection_rules where type='summary'`ステートメントを実行すると最新のルールリストを照会できます。 - `INSTANCE` : 監視対象インスタンス。 - `METRICS_NAME` : 監視メトリック名。 -- `QUANTILE` : `QUANTILE`含む監視テーブルに有効です。述語をプッシュダウンすることで、複数のパーセンタイルを指定できます。例えば、 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)`実行してDDL関連の監視メトリックを要約し、P80/P90/P99/P999の結果を照会できます。6 、 `MIN_VALUE` 、 `MAX_VALUE` `AVG_VALUE` 、集計の平均値、最小値、最大値を示します。 +- `QUANTILE` : `QUANTILE`を含む監視テーブルに有効です。述語をプッシュダウンすることで、複数のパーセンタイルを指定できます。例えば、 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)`を実行してDDL関連の監視メトリックを要約し、P80/P90/P99/P999の結果を照会できます。`AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`は、それぞれ集計の平均値、最小値、最大値を示します。 - `COMMENT` : 対応する監視メトリックに関するコメント。 > **Note:** diff --git a/information-schema/information-schema-table-constraints.md b/information-schema/information-schema-table-constraints.md index e47aa41f33839..cea747feb876b 100644 --- a/information-schema/information-schema-table-constraints.md +++ b/information-schema/information-schema-table-constraints.md @@ -51,4 +51,4 @@ SELECT * FROM table_constraints WHERE constraint_type='UNIQUE'; - `CONSTRAINT_SCHEMA` : 制約が属するデータベースの名前。 - `CONSTRAINT_NAME` : 制約の名前。 - `TABLE_NAME` : テーブルの名前。 -- `CONSTRAINT_TYPE` : 制約の種類。値は`UNIQUE` 、 `PRIMARY KEY` 、または`FOREIGN KEY`いずれかです。8 と`UNIQUE` `PRIMARY KEY`情報は、 `SHOW INDEX`ステートメントの実行結果と同様です。 +- `CONSTRAINT_TYPE` : 制約の種類。値は`UNIQUE` 、 `PRIMARY KEY` 、または`FOREIGN KEY`のいずれかです。`UNIQUE`と`PRIMARY KEY`の情報は、 `SHOW INDEX`ステートメントの実行結果と同様です。 diff --git a/information-schema/information-schema-tables.md b/information-schema/information-schema-tables.md index 6565249014c48..da08c150d5477 100644 --- a/information-schema/information-schema-tables.md +++ b/information-schema/information-schema-tables.md @@ -106,7 +106,7 @@ SHOW TABLES - `ROW_FORMAT` : 行形式。現在の値は`Compact`です。 - `TABLE_ROWS` : 統計におけるテーブル内の行数。 - `AVG_ROW_LENGTH` : 表の平均行の長さ`AVG_ROW_LENGTH` = `DATA_LENGTH` / `TABLE_ROWS` 。 -- `DATA_LENGTH` : データ長。2 = `DATA_LENGTH` * タプル内の列`TABLE_ROWS`storage長の合計。TiKVのレプリカは考慮されません。 +- `DATA_LENGTH` : データ長。`DATA_LENGTH` = `TABLE_ROWS` * タプル内の列のstorage長の合計。TiKVのレプリカは考慮されません。 - `MAX_DATA_LENGTH` : 最大データ長。現在の値は`0` 、データ長に上限がないことを意味します。 - `INDEX_LENGTH` : インデックスの長さ`INDEX_LENGTH` = `TABLE_ROWS` * インデックスタプル内の列の長さの合計。TiKVのレプリカは考慮されません。 - `DATA_FREE` : データフラグメント。現在の値は`0`です。 diff --git a/information-schema/information-schema-tidb-check-constraints.md b/information-schema/information-schema-tidb-check-constraints.md index 2bf5bf8283ea0..375fc8ddb4c81 100644 --- a/information-schema/information-schema-tidb-check-constraints.md +++ b/information-schema/information-schema-tidb-check-constraints.md @@ -5,7 +5,7 @@ summary: TIDB_CHECK_CONSTRAINTS` INFORMATION_SCHEMA テーブルについて学 # TIDB_CHECK_CONSTRAINTS {#tidb-check-constraints} -`TIDB_CHECK_CONSTRAINTS`表は[`CHECK`制約](/constraints.md#check)表に関する情報を提供します。5 の[`CHECK_CONSTRAINTS`](/information-schema/information-schema-check-constraints.md)に加えて、 `TIDB_CHECK_CONSTRAINTS` `CHECK`制約を定義する表の名前と ID を提供します。 +`TIDB_CHECK_CONSTRAINTS`表は[`CHECK`制約](/constraints.md#check)表に関する情報を提供します。[`CHECK_CONSTRAINTS`](/information-schema/information-schema-check-constraints.md)の列に加えて、 `TIDB_CHECK_CONSTRAINTS`は`CHECK`制約を定義する表の名前と ID を提供します。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index f924245610aab..461658d823683 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -125,7 +125,7 @@ all_sql_digests: ["e6f07d43b5c21db0fbb9a31feac2dc599787763393dd5acbfad80e247eb02 ## クラスター_TIDB_TRX {#cluster-tidb-trx} -`TIDB_TRX`テーブルは、単一の TiDB ノードで実行されているトランザクションに関する情報のみを提供します。クラスター全体のすべての TiDB ノードで実行されているトランザクションの情報を表示するには、 `CLUSTER_TIDB_TRX`テーブルをクエリする必要があります。5 テーブルのクエリ結果と比較すると、 `TIDB_TRX`テーブルのクエリ結果には`INSTANCE`フィールドが追加されています`INSTANCE`フィールド`CLUSTER_TIDB_TRX`は、クラスター内の各ノードの IP アドレスとポート番号が表示され、トランザクションが配置されている TiDB ノードを識別するために使用されます。 +`TIDB_TRX`テーブルは、単一の TiDB ノードで実行されているトランザクションに関する情報のみを提供します。クラスター全体のすべての TiDB ノードで実行されているトランザクションの情報を表示するには、 `CLUSTER_TIDB_TRX`テーブルをクエリする必要があります。`TIDB_TRX`テーブルのクエリ結果と比較すると、 `CLUSTER_TIDB_TRX`テーブルのクエリ結果には`INSTANCE`フィールドが追加されています。`INSTANCE`フィールドには、クラスター内の各ノードの IP アドレスとポート番号が表示され、トランザクションが配置されている TiDB ノードを識別するために使用されます。 ```sql USE INFORMATION_SCHEMA; diff --git a/literal-values.md b/literal-values.md index d7c79bc1f0ce3..e2e1dab41b07b 100644 --- a/literal-values.md +++ b/literal-values.md @@ -146,7 +146,7 @@ SELECT TRUE, true, tRuE, FALSE, FaLsE, false; X'1z' (z is not a hexadecimal legal digit) 0X12AC (0X must be written as 0x) -`X'val'`記法で記述された`val`進数リテラルは、偶数桁でなければなりません。3 の長さが奇数（例えば`X'A'`や`X'11A'` ）の場合、構文エラーを回避するには、値の先頭にゼロを付加します。 +`X'val'`記法で記述された`val`進数リテラルは、偶数桁でなければなりません。`val`の長さが奇数（例えば`X'A'`や`X'11A'` ）の場合、構文エラーを回避するには、値の先頭にゼロを付加します。 ```sql mysql> select X'aff'; diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 6dbe380d1313a..da215cdf246b8 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -151,7 +151,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー +---------------+----------+--------------------+---------------------+---------------------+ 1 row in set (2.11 sec) - `BACKUP`コマンドの実行後、TiDB はバックアップデータに関するメタデータを返します。3 はバックアップ前に生成されたデータなので、ご注意ください。このドキュメントでは、 `BackupTS` `BackupTS`**データチェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 + `BACKUP`コマンドの実行後、TiDB はバックアップデータに関するメタデータを返します。`BackupTS`より前に生成されたデータがバックアップされるため、ご注意ください。このドキュメントでは、 `BackupTS`を**データチェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 3. データを復元します。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 26873e4e55325..6b0943e5f4518 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -724,7 +724,7 @@ select /*+ NO_INDEX_MERGE() */ * from t where t.a > 0 or t.b > 0; ### USE_TOJA(ブール値) {#use-toja-boolean-value} -`boolean_value`パラメータは`TRUE`または`FALSE`です。7 ヒント`USE_TOJA(TRUE)` 、オプティマイザが`in`条件（サブクエリを含む）を結合および集計演算に変換できるようにします。一方、 `USE_TOJA(FALSE)`ヒントはこの機能を無効にします。 +`boolean_value`パラメータは`TRUE`または`FALSE`です。`USE_TOJA(TRUE)`ヒントは、オプティマイザが`in`条件（サブクエリを含む）を結合および集計演算に変換できるようにします。一方、 `USE_TOJA(FALSE)`ヒントはこの機能を無効にします。 たとえば、次のクエリは`in (select t2.a from t2) subq`対応する結合および集計操作に変換します。 diff --git a/password-management.md b/password-management.md index 3f00ec01f5468..a618d2f987b29 100644 --- a/password-management.md +++ b/password-management.md @@ -192,7 +192,7 @@ ALTER USER 'test'@'localhost' PASSWORD EXPIRE; データベース管理者によってアカウントのパスワードの有効期限が設定されている場合、TiDBにログインする前にパスワードを変更する必要があります。手動で設定した有効期限は取り消すことはできません。 -`CREATE ROLE`文で作成されたロールはパスワードを必要としないため、パスワードフィールドは空になります。このような場合、TiDB は`password_expired`属性を`'Y'`に設定します。これは、ロールのパスワードが手動で期限切れになっていることを意味します。この設計の目的は、ロールのロックが解除され、空のパスワードで TiDB にログインすることを防ぐことです。7 文でロールのロックが解除されると、パスワードが空であってもこのアカウントでログインできます。そのため、TiDB は`ALTER USER ... ACCOUNT UNLOCK`属性`password_expired`使用してパスワードを手動で期限切れにし、ユーザーがアカウントに有効なパスワードを設定するようにしています。 +`CREATE ROLE`文で作成されたロールはパスワードを必要としないため、パスワードフィールドは空になります。このような場合、TiDB は`password_expired`属性を`'Y'`に設定します。これは、ロールのパスワードが手動で期限切れになっていることを意味します。この設計の目的は、ロールのロックが解除され、空のパスワードで TiDB にログインすることを防ぐことです。`ALTER USER ... ACCOUNT UNLOCK`文でロールのロックが解除されると、パスワードが空であってもこのアカウントでログインできます。そのため、TiDB は`password_expired`属性を使用してパスワードを手動で期限切れにし、ユーザーがアカウントに有効なパスワードを設定するようにしています。 ```sql mysql> CREATE ROLE testrole; diff --git a/pd-control.md b/pd-control.md index 66fcba40da399..69301e1f1b43f 100644 --- a/pd-control.md +++ b/pd-control.md @@ -315,17 +315,17 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `replication-mode`デュアルデータセンターシナリオにおけるリージョンのレプリケーションモードを制御します。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)参照してください。 -- `leader-schedule-policy`はリーダーのスケジューリング戦略を選択するために使用されます。2 または`size`に従ってリーダー`count`スケジュールできます。 +- `leader-schedule-policy`はリーダーのスケジューリング戦略を選択するために使用されます。`size`または`count`に従ってリーダーをスケジュールできます。 - `scheduler-max-waiting-operator`は、各スケジューラ内の待機オペレータの数を制御するために使用されます。 -- `enable-remove-down-replica`は`false`ダウンタイムレプリカの自動削除機能を有効にするために使用されます。2 に設定すると、PDはダウンタイムレプリカを自動的にクリーンアップしません。 +- `enable-remove-down-replica`はダウンタイムレプリカの自動削除機能を有効にするために使用されます。`false`に設定すると、PDはダウンタイムレプリカを自動的にクリーンアップしません。 - `enable-replace-offline-replica`は、OfflineReplica の移行機能を有効にするために使用されます。2 `false`設定すると、PD はオフラインレプリカを移行しません。 - `enable-make-up-replica`はレプリカ作成機能を有効にするために使用されます。 `false`に設定すると、PDはレプリカが不足しているリージョンに対してレプリカを追加しません。 -- `enable-remove-extra-replica` `false`余分なレプリカを削除する機能を有効にするために使用されます。2 に設定すると、PDは冗長レプリカを持つリージョンの余分なレプリカを削除しません。 +- `enable-remove-extra-replica`は余分なレプリカを削除する機能を有効にするために使用されます。`false`に設定すると、PDは冗長レプリカを持つリージョンの余分なレプリカを削除しません。 - `enable-location-replacement`は分離レベルチェックを有効にするために使用されます。 `false`に設定すると、PDはスケジュール設定によってリージョンレプリカの分離レベルを上げません。 @@ -1133,8 +1133,8 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope - `rank-formula-version`ホットリージョンスケジューリングで使用するスケジューラアルゴリズムのバージョンを制御します。値の選択肢は`v1`と`v2`です。デフォルト値は`v2`です。 - `v1`アルゴリズムは、TiDB v6.3.0以前のバージョンで使用されていたスケジューラ戦略です。このアルゴリズムは、主にストア間の負荷差を軽減することに重点を置いており、他のディメンションへの副作用の発生を回避します。 - - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、副作用を少なくしながら、ストアとファクタ間の公平性を向上させることに主眼を置いています。5 が`strict-picking-store` `true`ある`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。13 が`strict-picking-store` `false`ある`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 - - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。11 アルゴリズムは`v2`両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 + - `v2`アルゴリズムは、TiDB v6.3.0 で導入された実験的スケジューラ戦略であり、TiDB v6.4.0 で一般提供（GA）されました。このアルゴリズムは、副作用を少なくしながら、ストアとファクタ間の公平性を向上させることに主眼を置いています。`strict-picking-store`が`true`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 1 次元の優先度均等化により重点を置いています。`strict-picking-store`が`false`である`v1`アルゴリズムと比較すると、 `v2`アルゴリズムは第 2 次元のバランスを考慮しています。 + - `strict-picking-store`を`true`とする`v1`アルゴリズムは保守的であり、両次元に高負荷のストアがある場合にのみスケジューリングが生成されます。特定のシナリオでは、次元の競合によりバランス調整を継続できなくなる可能性があります。第 1 次元でより適切なバランス調整を実現するには、 `strict-picking-store`を`false`に設定する必要があります。`v2`アルゴリズムは両次元でより適切なバランス調整を実現し、無効なスケジューリングを削減します。 ```bash scheduler config balance-hot-region-scheduler set rank-formula-version v2 diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 16ac08d68c11a..9a9997e1a1869 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -492,7 +492,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ `Commit Log Duration` `Apply Log Duration` 、raftstore内の主要な操作のレイテンシー指標です。これらのレイテンシはバッチ操作レベルで計測され、各操作は複数の書き込みリクエストを組み合わせます。したがって、これら`Append Log Duration`レイテンシは前述の`Store Duration`と`Apply Duration`に直接対応するものではありません。 -- `Commit Log Duration`と`Append Log Duration` 、 `Store`スレッドで実行された操作時間を記録します。6 `Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。8 `Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。12 は、通常、 `Append Log Duration`よりも大幅に大きくなります。 `Commit Log Duration` 、前者には、ネットワークを介してRaftログを他の TiKV ノードにコピーする時間が含まれるためです。 +- `Commit Log Duration`と`Append Log Duration` 、 `Store`スレッドで実行された操作時間を記録します。6 `Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。8 `Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。`Commit Log Duration`は、通常、 `Append Log Duration`よりも大幅に大きくなります。これは、前者には、ネットワークを介してRaftログを他の TiKV ノードにコピーする時間が含まれるためです。 - `Apply Log Duration` `Apply`スレッドによる`apply` Raftログのレイテンシーを記録します。 `Commit Log Duration`が長い場合の一般的なシナリオ: diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index 51ca90e2c5042..b31c82567f7be 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -148,7 +148,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and 上記のステートメントの結果: -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。6 フィールドが`AVAILABLE` `1`なると、このステータスは変更されなくなります。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`は利用可能、 `0`は利用不可を意味します。`AVAILABLE`フィールドが`1`になると、このステータスは変更されなくなります。 - `PROGRESS`レプリケーションの進行状況を表します。値は0.0～1.0の範囲です。1はTiFlashレプリカのレプリケーションの進行状況が完了したことを意味します。 ### ステップ5. HTAPを使用してデータをより速く分析する {#step-5-analyze-data-faster-using-htap} diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index 24f8472d80384..72fd1f45b539e 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -65,7 +65,7 @@ TiDBバージョン：5.2.4 - ウィンドウ関数がトランザクションを使用する場合と使用しない場合で異なる結果を返す可能性がある問題を修正しました [#29947](https://github.com/pingcap/tidb/issues/29947) - SQL文に自然結合が含まれている場合に`Column 'col_name' in field list is ambiguous`エラーが予期せず報告される問題を修正しました [#25041](https://github.com/pingcap/tidb/issues/25041) - `Decimal`を`String`にキャストする際に長さ情報が間違っている問題を修正しました [#29417](https://github.com/pingcap/tidb/issues/29417) - - `GREATEST`関数が`tidb_enable_vectorized_expression`の値が異なる場合（{{B-PLACEHOLDER-2- `on`または`off` 。 [#29434](https://github.com/pingcap/tidb/issues/29434) + - `GREATEST`関数が`tidb_enable_vectorized_expression`の値が異なる場合（`on`または`off`に設定）に一貫性のない結果を返す問題を修正しました [#29434](https://github.com/pingcap/tidb/issues/29434) - `left join`を使用して複数のテーブルのデータを削除する際の誤った結果を修正 [#31321](https://github.com/pingcap/tidb/issues/31321) - TiDBがTiFlashに重複したタスクをディスパッチする可能性があるバグを修正しました [#32814](https://github.com/pingcap/tidb/issues/32814) - クエリ実行時に発生するMPPタスクリストの空エラーを修正する [#31636](https://github.com/pingcap/tidb/issues/31636) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 2b09650ce5193..b3c6cba654a37 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -45,7 +45,7 @@ TiDBバージョン: 6.4.0-DMR - `FLASHBACK CLUSTER TO TIMESTAMP`を使用した特定の時点へのクラスターの復元のサポート (実験的) [#37197](https://github.com/pingcap/tidb/issues/37197) [#13303](https://github.com/tikv/tikv/issues/13303) @[Defined2014](https://github.com/Defined2014) @[bb7133](https://github.com/bb7133) @[JmPotato](https://github.com/JmPotato) @[Connor1996](https://github.com/Connor1996) @[HuSharp](https://github.com/HuSharp) @[CalvinNeo](https://github.com/CalvinNeo) - `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、{{B-PLACEHOLDER-2-PLACEHOLDER-E} `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 + `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、 `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 `FLASHBACK CLUSTER TO TIMESTAMP`を実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーション タスクを一時停止し、 `FLASHBACK`が完了した後に再開する必要があります。そうしないと、レプリケーション タスクが失敗する可能性があります。 @@ -340,7 +340,7 @@ TiDBバージョン: 6.4.0-DMR - TiKV - - Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目`apply-yield-write-size` -0-PLACEHOLDER-E}}を追加します。 [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) + - Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目`apply-yield-write-size`を追加します。 [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) - リージョンのリーダーを移行する前にエントリキャッシュをウォームアップして、リーダー転送プロセス中のQPSジッターを回避する [#13060](https://github.com/tikv/tikv/issues/13060) @[cosven](https://github.com/cosven) - `json_constrains`演算子をコプロセッサーにプッシュダウンするサポート [#13592](https://github.com/tikv/tikv/issues/13592) @[lizhenhuan](https://github.com/lizhenhuan) - `CausalTsProvider`に非同期関数を追加して、一部のシナリオでのフラッシュパフォーマンスを改善します [#13428](https://github.com/tikv/tikv/issues/13428) @[zeminzhou](https://github.com/zeminzhou) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index e8630c6467a1d..c945b43befee4 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -320,7 +320,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | [`mpp_version`](/system-variables.md#mpp_version-new-in-v660) | 新しく追加された | この変数は、MPP実行プランのバージョンを指定します。バージョンを指定すると、TiDBは指定されたバージョンのMPP実行プランを選択します。デフォルト値`UNSPECIFIED` 、TiDBが最新バージョン`1`自動的に選択することを意味します。 | | [`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) | 新しく追加された | この変数は、DDL 再編成フェーズの分散実行を有効にしてこのフェーズを高速化するかどうかを制御します。デフォルト値`OFF`は、デフォルトでは DDL 再編成フェーズの分散実行を有効にしないことを意味します。現在、この変数は`ADD INDEX`に対してのみ有効です。 | | [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | 新しく追加された | この変数は`PLAN REPLAYER CAPTURE`で取得される情報に、デフォルトで履歴統計が含まれるかどうかを制御します。デフォルト値の`OFF`は、デフォルトでは履歴統計が含まれないことを意味します。 | -| [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | 新しく追加された | この変数は`COUNT` `Limit` 0-PLACEHOLDER-E}} が含まれる実行プランをプリペアドプランキャッシュがキャッシュするかどうかを制御します。デフォルト値は`ON`で、これはプリペアドプランキャッシュ がそのような実行プランのキャッシュをサポートすることを意味します。ただし、 プリペアドプランキャッシュ は、 10000 を超える数値をカウントする`COUNT`条件を含む実行プランのキャッシュをサポートしていないことに注意してください。 | +| [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | 新しく追加された | この変数は`Limit`の後に`COUNT`が含まれる実行プランをプリペアドプランキャッシュがキャッシュするかどうかを制御します。デフォルト値は`ON`で、これはプリペアドプランキャッシュ がそのような実行プランのキャッシュをサポートすることを意味します。ただし、 プリペアドプランキャッシュ は、 10000 を超える数値をカウントする`COUNT`条件を含む実行プランのキャッシュをサポートしていないことに注意してください。 | | [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値は`OFF`です。この変数を`ON`に設定すると、TiDB クラスタはリソース グループに基づいたアプリケーションのリソース分離をサポートします。 | | [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-new-in-v660) | 新しく追加された | この変数は、過去の統計情報をストレージに保存する期間を制御します。デフォルト値は7日間です。 | | [`tidb_index_join_double_read_penalty_cost_rate`](/system-variables.md#tidb_index_join_double_read_penalty_cost_rate-new-in-v660) | 新しく追加された | この変数は、インデックス結合の選択にペナルティコストを追加するかどうかを制御します。デフォルト値`0`は、この機能がデフォルトで無効になっていることを意味します。 | diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index c25695619571a..35570c1bbcb0c 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -200,8 +200,8 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - デフォルト設定では[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)がサポートされているため、 TiDB Cloud Starterへの接続が容易になります。 - TiDBのバージョンを識別して、外部キーのタブを表示または非表示にする機能をサポートしています。 - `EXPLAIN`結果に SQL 実行プランを視覚化することをサポートします。 - - `PESSIMISTIC` 、 `OPTIMISTIC` 、 `AUTO_RANDOM` 、 `PLACEMENT` 、 {{B-PLACEHOLDER `POLICY` 、 `REORGANIZE` 、 `EXCHANGE` 、 `CACHE` `NONCLUSTERED` } 、 `CLUSTERED`などの TiDB キーワードの強調表示をサポートします。 - - `TIDB_BOUNDED_STALENESS` 、 `TIDB_DECODE_KEY` 、 `TIDB_DECODE_PLAN` 、 `TIDB_IS_DDL_OWNER` 、{{B-PLACEHOLDER `TIDB_PARSE_TSO` 、 `TIDB_VERSION` `TIDB_DECODE_SQL_DIGESTS` }}、 `TIDB_SHARD`などのTiDB関数の強調表示をサポートします。 + - `PESSIMISTIC` 、 `OPTIMISTIC` 、 `AUTO_RANDOM` 、 `PLACEMENT` 、 `POLICY` 、 `REORGANIZE` 、 `EXCHANGE` 、 `CACHE` 、 `NONCLUSTERED` 、 `CLUSTERED`などの TiDB キーワードの強調表示をサポートします。 + - `TIDB_BOUNDED_STALENESS` 、 `TIDB_DECODE_KEY` 、 `TIDB_DECODE_PLAN` 、 `TIDB_IS_DDL_OWNER` 、 `TIDB_PARSE_TSO` 、 `TIDB_VERSION` 、 `TIDB_DECODE_SQL_DIGESTS` 、 `TIDB_SHARD`などのTiDB関数の強調表示をサポートします。 詳細については、 [DBeaverのドキュメント](https://github.com/dbeaver/dbeaver/wiki)を参照してください。 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-8.4.0.md b/releases/release-8.4.0.md index 259703e32ac28..37a6b5fcaae72 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -219,7 +219,7 @@ TiDB バージョン: 8.4.0 | [`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。その値はデフォルト値`ON`に固定され、[リスト分割](/partitioned-table.md#list-partitioning)がデフォルトで有効になります。 | | [`tidb_enable_table_partition`](/system-variables.md#tidb_enable_table_partition) | 非推奨 | v8.4.0 では、この変数は非推奨になりました。その値はデフォルト値`ON`に固定されます。つまり、[テーブルパーティショニング](/partitioned-table.md)はデフォルトで有効になります。 | | [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) | 変更 | 値の範囲を`[1, 18446744073709551615]`から`[1, 128]`に変更します。 | -| [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。v8.4.0 以降、内部テーブルに`Selection` 、{{B-PLACEHOLDER-3-PLACEHOLDER- `Aggregation` `Projection`デフォルトでサポートされます。 | +| [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。v8.4.0 以降、内部テーブルに`Selection` 、 `Aggregation` 、または`Projection`演算子がある場合、Index Join がデフォルトでサポートされます。 | | [`tidb_opt_prefer_range_scan`](/system-variables.md#tidb_opt_prefer_range_scan-new-in-v50) | 変更 | デフォルト値を`OFF`から`ON`に変更します。統計情報がないテーブル (擬似統計情報) または空のテーブル (統計情報がゼロ) の場合、オプティマイザはフルテーブルスキャンよりもインターバルスキャンを優先します。 | | [`tidb_scatter_region`](/system-variables.md#tidb_scatter_region) | 変更 | v8.4.0 より前は、型はブール型で、 `ON`と`OFF`のみをサポートし、新しく作成されたテーブルのリージョンは、有効化後にのみテーブルレベルの分散をサポートします。v8.4.0 以降では、 `SESSION`スコープが追加され、型がブール型から列挙型に変更され、デフォルト値が`OFF`から null に変更され、オプション値`TABLE`と`GLOBAL`が追加されました。さらに、バッチでの高速テーブル作成中にリージョンの不均一な分散によって発生する TiKV OOM の問題を回避するために、クラスタレベルの分散ポリシーがサポートされるようになりました。 | | [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) | 変更 | デフォルト値を`0`から`536870912` (512 MiB) に変更し、この機能がデフォルトで有効になっていることを示します。許可される最小値は`67108864` (64 MiB) に設定されています。 | diff --git a/role-based-access-control.md b/role-based-access-control.md index 5f3ce18bbe024..80b2e1dafd81f 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -151,7 +151,7 @@ SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read'; | GRANT `app_read`@`%` TO `read_user1`@`localhost` | +--------------------------------------------------------+ -現在のユーザーの権限を確認するには、 `SHOW GRANTS`または`SHOW GRANTS FOR CURRENT_USER()`使用します。5 と`SHOW GRANTS FOR CURRENT_USER()` `SHOW GRANTS`の点で異なります。 +現在のユーザーの権限を確認するには、 `SHOW GRANTS`または`SHOW GRANTS FOR CURRENT_USER()`を使用します。`SHOW GRANTS`と`SHOW GRANTS FOR CURRENT_USER()`は次の点で異なります。 - `SHOW GRANTS` 、現在のユーザーに対して有効なロールの権限を示します。 - `SHOW GRANTS FOR CURRENT_USER()`場合、有効なロールの権限は表示されません。 diff --git a/runtime-filter.md b/runtime-filter.md index 80480b274e9be..4c5c5adbdbd10 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -170,7 +170,7 @@ WHERE d_date = '2002-2-01' AND ### ステップ4. パフォーマンスの比較 {#step-4-performance-comparison} -この例では、50 GBのTPC-DSデータを使用しています。ランタイムフィルターを有効にすると、クエリ時間は0.38秒から0.17秒に短縮され、効率は`ANALYZE` %向上します。1 ステートメントを使用すると、ランタイムフィルター有効後の各演算子の実行時間を確認できます。 +この例では、50 GBのTPC-DSデータを使用しています。ランタイムフィルターを有効にすると、クエリ時間は0.38秒から0.17秒に短縮され、効率は 50 %向上します。`ANALYZE`ステートメントを使用すると、ランタイムフィルター有効後の各演算子の実行時間を確認できます。 ランタイム フィルターが有効になっていない場合のクエリの実行情報は次のとおりです。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ee8dce525a4f1..99d5a205f0ebe 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -128,7 +128,7 @@ MySQL [test]> select @@last_plan_from_cache; ### SHOW WARNINGSを使用して診断する {#use-code-show-warnings-code-to-diagnose} -一部のクエリまたはプランはキャッシュできません。1 ステートメント`SHOW WARNINGS`使用して、クエリまたはプランがキャッシュされているかどうかを確認できます。キャッシュされていない場合は、結果で失敗の理由を確認できます。例: +一部のクエリまたはプランはキャッシュできません。`SHOW WARNINGS`ステートメントを使用して、クエリまたはプランがキャッシュされているかどうかを確認できます。キャッシュされていない場合は、結果で失敗の理由を確認できます。例: ```sql mysql> PREPARE st FROM 'SELECT * FROM t WHERE a > (SELECT MAX(a) FROM t)'; -- The query contains a subquery and cannot be cached. diff --git a/sql-statements/sql-statement-admin-cancel-ddl.md b/sql-statements/sql-statement-admin-cancel-ddl.md index d7950d2dfe0fa..e92b7907cb4a5 100644 --- a/sql-statements/sql-statement-admin-cancel-ddl.md +++ b/sql-statements/sql-statement-admin-cancel-ddl.md @@ -33,7 +33,7 @@ ADMIN CANCEL DDL JOBS job_id [, job_id] ...; > **Note:** > > - バージョン6.2.0より前では、この操作のみがDDLジョブをキャンセルでき、他のすべての操作や環境変更（マシンの再起動やクラスタの再起動など）ではこれらのジョブをキャンセルできませんでした。バージョン6.2.0以降では、 [`KILL`](/sql-statements/sql-statement-kill.md)ステートメントを使用して実行中のDDLジョブを強制終了することでキャンセルできるようになりました。 -> - この操作では、複数のDDLジョブを同時にキャンセルできます。1 ステートメントを使用して、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ジョブのIDを取得できます。 +> - この操作では、複数のDDLジョブを同時にキャンセルできます。 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブのIDを取得できます。 > - キャンセルするジョブが完了している場合、キャンセル操作は失敗します。 ## MySQLの互換性 {#mysql-compatibility} 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-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 742ed21e6f504..a39ad5f6b8c58 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -67,7 +67,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `create table` : [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)操作の場合。 - `create view` : [`CREATE VIEW`](/sql-statements/sql-statement-create-view.md)操作の場合。 - `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`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 +- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。 `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`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 @@ -87,7 +87,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `cancelling` : 操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ表示されます。 - `cancelled` : 操作がキャンセルされたことを示します。 - `pausing` : 操作が一時停止されていることを示します。 - - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。4 コマンドを使用して DDL ジョブ[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 - `done` : 操作は TiDB 所有者ノードで正常に実行されたが、他の TiDB ノードではこの DDL ジョブによって実行された変更がまだ同期されていないことを示します。 - `COMMENTS` : 診断目的の追加情報が含まれます。 - `ingest` : [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)で構成された高速化されたインデックス バックフィルの追加のためのタスクを取り込みます。 @@ -95,9 +95,9 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `txn-merge` : バックフィルが完了すると元のインデックスとマージされる一時インデックスを使用したトランザクション バックフィル。 - `DXF` : [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)で構成された Distributed eXecution Framework (DXF) を使用して実行されるタスク。 - `service_scope` : [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)で設定された TiDB ノードのサービス スコープ。 - - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。4 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)指定することで動的な変更が可能です。 - - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。4 `ADMIN ALTER DDL JOBS`指定することで動的な変更が可能です。 - - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。4 による動的な変更`ADMIN ALTER DDL JOBS`サポートされます。 + - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。[`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)を指定することで動的な変更が可能です。 + - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。`ADMIN ALTER DDL JOBS`を指定することで動的な変更が可能です。 + - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。 `ADMIN ALTER DDL JOBS`による動的な変更がサポートされます。 @@ -107,7 +107,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `DB_NAME` : DDL 操作が実行されるデータベースの名前。 - `TABLE_NAME` : DDL 操作が実行されるテーブルの名前。 - `JOB_TYPE` : DDL 操作のタイプ。 -- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 +- `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。 `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`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 @@ -122,7 +122,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `rollback done` : 操作が失敗し、ロールバックが完了したことを示します。 - `rollingback` : 操作が失敗し、ロールバック中であることを示します。 - `cancelling` : 操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ表示されます。 - - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。4 コマンドを使用して DDL ジョブ[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index c7cefa9b3a366..0196971efe6ca 100644 --- a/sql-statements/sql-statement-alter-sequence.md +++ b/sql-statements/sql-statement-alter-sequence.md @@ -52,11 +52,11 @@ ALTER SEQUENCE sequence_name | パラメータ | デフォルト値 | 説明 | | :---------- | :--------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | | `INCREMENT` | `1` | シーケンスの増分を指定します。正または負の値を指定することで、シーケンスの増加方向を制御できます。 | -| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`1`です。7 < `0` `INCREMENT`場合、デフォルト値は`-9223372036854775807`です。 | -| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`9223372036854775806`です。7 < `0` `INCREMENT`場合、デフォルト値は`-1`です。 | -| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`MINVALUE`です。7 < `0` `INCREMENT`場合、デフォルト値は`MAXVALUE`です。 | +| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`1`です。`INCREMENT` < `0`の場合、デフォルト値は`-9223372036854775807`です。 | +| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | +| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | | `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | -| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。1 > `0` `INCREMENT` 、デフォルト値は`MINVALUE`です。7 < `INCREMENT` `0`場合、デフォルト値は`MAXVALUE`です。 | +| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | > **Note:** > diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md index 696f30812bbcc..a4726261bff42 100644 --- a/sql-statements/sql-statement-alter-table-compact.md +++ b/sql-statements/sql-statement-alter-table-compact.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ALTER TABLE ... COMPACT の使用法の概 # ALTER TABLE ... COMPACT {#alter-table-compact} -読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。1 ステートメントを使用すると、 `ALTER TABLE ... COMPACT`グラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 +読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。 `ALTER TABLE ... COMPACT`ステートメントを使用すると、バックグラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 この文を実行しても、既存のSQL文はブロックされず、トランザクション、DDL、GCといったTiDBの機能にも影響はありません。SQL文で選択可能なデータも変更されません。この文の実行は、IOリソースとCPUリソースを消費します。業務への悪影響を避けるため、リソースに余裕があるタイミングなど、適切なタイミングで実行するようご注意ください。 @@ -89,7 +89,7 @@ ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA; ## データ圧縮の進行状況を観察する {#observe-data-compaction-progress} -`INFORMATION_SCHEMA.TIFLASH_TABLES`テーブルの`TOTAL_DELTA_ROWS`列を確認することで、データ圧縮の進行状況を確認したり、テーブルの圧縮を開始するかどうかを判断したりできます`TOTAL_DELTA_ROWS`の値が大きいほど、圧縮できるデータ量が多くなります。7 が`TOTAL_DELTA_ROWS` `0`場合、テーブル内のすべてのデータは最適な状態であり、圧縮する必要はありません。 +`INFORMATION_SCHEMA.TIFLASH_TABLES`テーブルの`TOTAL_DELTA_ROWS`列を確認することで、データ圧縮の進行状況を確認したり、テーブルの圧縮を開始するかどうかを判断したりできます`TOTAL_DELTA_ROWS`の値が大きいほど、圧縮できるデータ量が多くなります。 `TOTAL_DELTA_ROWS`が`0`の場合、テーブル内のすべてのデータは最適な状態であり、圧縮する必要はありません。
例:パーティションテーブルの圧縮状態を確認する diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index f0a128744281c..985e5988a0661 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -55,7 +55,7 @@ TiDB は推定に 2 つの方法を提供します。 - `OLTP_WRITE_ONLY` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`sysbench oltp_write_only`と同様のワークロードモデルに基づいて推定されます。 - `OLTP_READ_WRITE` : データの読み取りと書き込みが均等なワークロードに適用されます。これは`sysbench oltp_read_write`と同様のワークロードモデルに基づいて推定されます。 - `OLTP_READ_ONLY` : 大量のデータ読み取りを伴うワークロードに適用されます。これは`sysbench oltp_read_only`と同様のワークロードモデルに基づいて推定されます。 -- `TPCH_10` : APクエリに適用されます。2 からの`TPCH-10G`のクエリに基づいて推定されます。 +- `TPCH_10` : APクエリに適用されます。 `TPCH-10G`からの22個のクエリに基づいて推定されます。 > **Note:** > diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index bf4d09fac7f7a..6e2cde069340b 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -55,11 +55,11 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name | :---------- | :--------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | | `TEMPORARY` | `false` | TiDB は現在`TEMPORARY`オプションをサポートしておらず、構文の互換性のみを提供しています。 | | `INCREMENT` | `1` | シーケンスの増分を指定します。正または負の値を指定することで、シーケンスの増加方向を制御できます。 | -| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`1`です。7 < `0` `INCREMENT`場合、デフォルト値は`-9223372036854775807`です。 | -| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`9223372036854775806`です。7 < `0` `INCREMENT`場合、デフォルト値は`-1`です。 | -| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。1 > `0` `INCREMENT`場合、デフォルト値は`MINVALUE`です。7 < `0` `INCREMENT`場合、デフォルト値は`MAXVALUE`です。 | +| `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`1`です。`INCREMENT` < `0`の場合、デフォルト値は`-9223372036854775807`です。 | +| `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | +| `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | | `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | -| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。1 > `0` `INCREMENT` 、デフォルト値は`MINVALUE`です。7 < `INCREMENT` `0`場合、デフォルト値は`MAXVALUE`です。 | +| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | ## SEQUENCE関数 {#code-sequence-code-function} diff --git a/sql-statements/sql-statement-drop-index.md b/sql-statements/sql-statement-drop-index.md index 784e8a43dbddf..6ea746e30ee02 100644 --- a/sql-statements/sql-statement-drop-index.md +++ b/sql-statements/sql-statement-drop-index.md @@ -58,7 +58,7 @@ Query OK, 0 rows affected (0.30 sec) ## MySQLの互換性 {#mysql-compatibility} -- `CLUSTERED`型`CLUSTERED`主キーの削除はサポートされていません。3 型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +- `CLUSTERED`型の主キーの削除はサポートされていません。 `CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-flashback-database.md b/sql-statements/sql-statement-flashback-database.md index 13d373803deb8..6bab1c14e6b48 100644 --- a/sql-statements/sql-statement-flashback-database.md +++ b/sql-statements/sql-statement-flashback-database.md @@ -34,7 +34,7 @@ FlashbackToNewName ::= - `tikv_gc_safe_point`回目より前にデータベースが削除された場合、 `FLASHBACK DATABASE`ステートメントを使用してデータを復元することはできません。`FLASHBACK DATABASE`のステートメントは`ERROR 1105 (HY000): Can't find dropped database 'test' in GC safe point 2022-11-06 16:10:10 +0800 CST`と同様のエラーを返します。 -- `FLASHBACK DATABASE`ステートメントを使用して、同じデータベースを複数回リストアすることはできません。3 でリストアされ`FLASHBACK DATABASE`データベースは元のデータベースと同じスキーマ ID を持つため、同じデータベースを複数回リストアするとスキーマ ID が重複します。TiDB では、データベースのスキーマ ID はグローバルに一意である必要があります。 +- `FLASHBACK DATABASE`ステートメントを使用して、同じデータベースを複数回リストアすることはできません。 `FLASHBACK DATABASE`でリストアされたデータベースは元のデータベースと同じスキーマ ID を持つため、同じデータベースを複数回リストアするとスキーマ ID が重複します。TiDB では、データベースのスキーマ ID はグローバルに一意である必要があります。 ## 例 {#example} diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 2165456952383..43932b60e779e 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -283,7 +283,7 @@ IMPORT INTO t(id, name, @1) FROM '/path/to/file.csv' WITH skip_rows=1; #### ワイルドカードを使用して複数のデータファイルをインポートする {#import-multiple-data-files-using-wildcards} -`file-01.csv`ディレクトリに`file-02.csv` 、 `file-03.csv` 、 `/path/to/` -PLACEHOLDER-E}} という名前のファイルが 3 つあるとします。これらの 3 つのファイルを`t`を使用してターゲット テーブル`IMPORT INTO`にインポートするには、次の SQL ステートメントを実行します。 +`/path/to/`ディレクトリに`file-01.csv` 、 `file-02.csv` 、 `file-03.csv`という名前のファイルが 3 つあるとします。これらの 3 つのファイルを`IMPORT INTO`を使用してターゲット テーブル`t`にインポートするには、次の SQL ステートメントを実行します。 ```sql IMPORT INTO t FROM '/path/to/file-*.csv'; diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index b6a65a0b62532..0baab18d21eb3 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -15,7 +15,7 @@ TiDBでは、クライアントセッションがテーブルロックを取得 `UNLOCK TABLES` 、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。2 `LOCK TABLES` 、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 -テーブルロックは、他のセッションによる読み取りや書き込みから保護します。1 ロックを保持しているセッションは、 `WRITE`や`TRUNCATE TABLE` `DROP TABLE`のテーブルレベルの操作を実行できます。 +テーブルロックは、他のセッションによる読み取りや書き込みから保護します。 `WRITE`ロックを保持しているセッションは、 `DROP TABLE`や`TRUNCATE TABLE`などのテーブルレベルの操作を実行できます。 > **Note:** > diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 4e9dc0159d1d3..e333da1823141 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -96,7 +96,7 @@ select * from employee where id in (...) and salary between ? and ?; > **Note:** > -> [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary)有効になっている場合、 `statements_summary_history`テーブルのデータはディスクに永続化されます。この場合、 `tidb_stmt_summary_max_stmt_count` 、 `statements_summary`テーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、{{B-PLACEHOLDER-5-PLACEHOLDER- `tidb_stmt_summary_max_stmt_count` `statements_summary`から最も使用頻度の低い SQL ダイジェストのみを削除します。 +> [`tidb_stmt_summary_enable_persistent`](#persist-statements-summary)有効になっている場合、 `statements_summary_history`テーブルのデータはディスクに永続化されます。この場合、 `tidb_stmt_summary_max_stmt_count`は、 `statements_summary`テーブルがメモリに格納できる SQL ダイジェストの数のみを制限し、TiDB は`tidb_stmt_summary_max_stmt_count`を超えると`statements_summary`テーブルから最も使用頻度の低い SQL ダイジェストのみを削除します。 diff --git a/statistics.md b/statistics.md index 96d89643f2035..f2b1215e3283b 100644 --- a/statistics.md +++ b/statistics.md @@ -314,7 +314,7 @@ TiDB は、最新の`ANALYZE`ステートメントで指定された新しい構 ### 列構成を保持する {#persist-column-configurations} -`ANALYZE`ステートメント ( `COLUMNS ColumnNameList` 、{{B-PLACEHOLDER-2-PLACEHOLDER- `PREDICATE COLUMNS`を含む) の列構成を永続化する場合は、 `tidb_persist_analyze_options` `ALL COLUMNS`変数の値を`ON`に設定して[構成の永続性を分析する](#persist-analyze-configurations)機能を有効にします。 ANALYZE 構成永続化機能を有効にした後: +`ANALYZE`ステートメント ( `COLUMNS ColumnNameList` 、 `PREDICATE COLUMNS` 、 `ALL COLUMNS`を含む) の列構成を永続化する場合は、 `tidb_persist_analyze_options`システム変数の値を`ON`に設定して[構成の永続性を分析する](#persist-analyze-configurations)機能を有効にします。 ANALYZE 構成永続化機能を有効にした後: - TiDB が統計情報を自動的に収集する場合、または列構成を指定せずに`ANALYZE`ステートメントを実行して手動で統計情報を収集する場合、TiDB は統計情報の収集に以前に保持された構成を引き続き使用します。 - 列構成を指定して`ANALYZE`ステートメントを手動で複数回実行すると、TiDB は最新の`ANALYZE`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。 diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index b2dbe9ff003ef..44664ce25423d 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -111,7 +111,7 @@ Titan BLOBファイルとRocksDBブロックファイルの共有キャッシュ ### Titanの構成例 {#titan-configuration-example} -以下は Titan 設定ファイルの例です。1 または[Kubernetes上でTiDBクラスターを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster) [TiUPを使用して設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)かを選択できます。 +以下は Titan 設定ファイルの例です。[TiUPを使用して設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)か[Kubernetes上でTiDBクラスターを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster)かを選択できます。 ```toml [rocksdb] diff --git a/system-variables.md b/system-variables.md index 944803d1e43e9..fb3a3943ead0b 100644 --- a/system-variables.md +++ b/system-variables.md @@ -5716,7 +5716,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントと[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。このシステム変数が`ON`に設定されている場合、これらの 2 つの方法で現在のセッションまたは現在のステートメントのバインドされたリソース グループを変更するには`SUPER` `RESOURCE_GROUP_ADMIN` 、 `RESOURCE_GROUP_USER` PLACEHOLDER-E}} の特権が必要です。 `OFF`に設定されている場合、これらの権限は不要となり、この変数がない以前の TiDB バージョンと同じ動作になります。 +- この変数は[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントと[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。このシステム変数が`ON`に設定されている場合、これらの 2 つの方法で現在のセッションまたは現在のステートメントのバインドされたリソース グループを変更するには`SUPER` 、 `RESOURCE_GROUP_ADMIN` 、または`RESOURCE_GROUP_USER`の特権が必要です。 `OFF`に設定されている場合、これらの権限は不要となり、この変数がない以前の TiDB バージョンと同じ動作になります。 - TiDB クラスターを以前のバージョンから v8.2.0 以降にアップグレードすると、この変数のデフォルト値は`OFF`に設定され、この機能はデフォルトで無効になります。 ### tidb_retry_limit {#tidb-retry-limit} 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/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index e6face4e1601a..e92ae1391be9c 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -159,7 +159,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま > > 他のシナリオではBDRロールを設定しないでください。例えば、BDRロールを`PRIMARY` 、 `SECONDARY` 、そして0つを同時に設定しないでください。BDRロールを誤って設定すると、TiDBはデータレプリケーション中にデータの正確性と一貫性を保証できません。 -- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 +- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)を使用しないでください。`AUTO_INCREMENT`または`AUTO_RANDOM`を使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`を設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 - クラスタAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`設定します - クラスタBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`設定します diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 26179c694c7f4..4873a13bf0d82 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -82,7 +82,7 @@ TiCDC は、DDL イベントを次の Canal-JSON 形式にエンコードしま | mysqlType | object | isDdlが`false`場合、各列のデータ型がMySQLでどのように表現されるかを記録します。 | | データ | object | isDdlが`false`の場合、各列の名前とそのデータ値を記録します。 | | 古い | object | メッセージが更新イベントによって生成された場合のみ、更新前の各列の名前とデータ値を記録します。 | -| _tidb | object | TiDB拡張フィールド。1 を`enable-tidb-extension` `true`設定した場合にのみ存在します。5 `commitTs`値は、行の変更を引き起こしたトランザクションのTSOです。 | +| _tidb | object | TiDB拡張フィールド。`enable-tidb-extension`を`true`に設定した場合にのみ存在します。`commitTs`の値は、行の変更を引き起こしたトランザクションのTSOです。 | ### DMLイベント {#dml-event} @@ -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-csv.md b/ticdc/ticdc-csv.md index 017fcbaef3f5a..c5e6623e199d6 100644 --- a/ticdc/ticdc-csv.md +++ b/ticdc/ticdc-csv.md @@ -33,7 +33,7 @@ output-field-header = false # New in v8.5.6 (only available in the TiCDC new arc ## トランザクション上の制約 {#transactional-constraints} -- 単一のCSVファイルでは、ある行の`commit-ts`は、次の行の{{B-PLACEHOLDER-E}}と同じかそれ以下です。 +- 単一のCSVファイルでは、ある行の`commit-ts`は、次の行の`commit-ts`と同じかそれ以下です。 - 同一テーブルの同じトランザクションは、同じCSVファイルに保存されます。 - 同じトランザクションの複数のテーブルを、異なるCSVファイルに保存することができます。 diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 09518aca005d7..93d11bce316c7 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -51,7 +51,7 @@ cdc cli changefeed list --server=http://10.0.10.25:8300 ## 特定のレプリケーションタスクをクエリする {#query-a-specific-replication-task} -特定のレプリケーションタスク`-s`クエリするには、 `changefeed query`コマンドを実行します。クエリ結果には、タスク情報とタスク状態が含まれます。3 または`--simple`引数を指定すると、クエリ結果を簡略化し、基本的なレプリケーション状態とチェックポイント情報のみを含めることができます。この引数を指定しない場合は、詳細なタスク設定、レプリケーション状態、およびレプリケーションテーブル情報が出力されます。 +特定のレプリケーションタスクをクエリするには、 `changefeed query`コマンドを実行します。クエリ結果には、タスク情報とタスク状態が含まれます。`--simple`または`-s`引数を指定すると、クエリ結果を簡略化し、基本的なレプリケーション状態とチェックポイント情報のみを含めることができます。この引数を指定しない場合は、詳細なタスク設定、レプリケーション状態、およびレプリケーションテーブル情報が出力されます。 ```shell cdc cli changefeed query -s --server=http://10.0.10.25:8300 --changefeed-id=simple-replication-task diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 8448ed66da974..28ae39eea58bf 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -240,7 +240,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `start_ts` | `UINT64`型。変更フィードの開始TSOを指定します。TiCDCクラスターは、このTSOからデータのプルを開始します。デフォルト値は現在時刻です。（オプション） | | `target_ts` | `UINT64`型。変更フィードのターゲットTSOを指定します。TiCDCクラスターは、このTSOに到達するとデータのプルを停止します。デフォルト値は空で、TiCDCは自動的に停止しません。(オプション) | -`changefeed_id` `target_ts`意味と`sink_uri`は、 [`cdc cli`を使用してレプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)ドキュメントに記載されているものと同じです。これら`start_ts`パラメータの詳細については、 `sink_uri`のドキュメントを参照してください。11 で証明書パスを指定する際は、対応する証明書が対応する TiCDCサーバーにアップロードされていることを確認してください。 +`changefeed_id` `target_ts`意味と`sink_uri`は、 [`cdc cli`を使用してレプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)ドキュメントに記載されているものと同じです。これら`start_ts`パラメータの詳細については、 `sink_uri`のドキュメントを参照してください。`sink_uri`で証明書パスを指定する際は、対応する証明書が対応する TiCDCサーバーにアップロードされていることを確認してください。 `replica_config`パラメータの説明は次のとおりです。 @@ -313,7 +313,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `schema_registry` | `STRING`型。スキーマレジストリアドレス。（オプション） | | `terminator` | `STRING`型。ターミネータは、2つのデータ変更イベントを区切るために使用されます。デフォルト値はnullで、 `"\r\n"`ターミネータとして使用されます。（オプション） | | `transaction_atomicity` | `STRING`型。トランザクションのアトミック性レベル。（オプション） | -| `only_output_updated_columns` | `BOOLEAN`型。2 または`canal-json`プロトコル`open-protocol`使用するMQシンクの場合、変更された列のみを出力するかどうかを指定できます。デフォルト値は`false`です。（オプション） | +| `only_output_updated_columns` | `BOOLEAN`型。`canal-json`または`open-protocol`プロトコルを使用するMQシンクの場合、変更された列のみを出力するかどうかを指定できます。デフォルト値は`false`です。（オプション） | | `cloud_storage_config` | ストレージシンクの構成。(オプション) | | `open` | オープンプロトコルの構成。(オプション) | | `debezium` | Debezium プロトコルの設定。(オプション) | @@ -333,7 +333,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `include_commit_ts` | `BOOLEAN`型。CSV行にコミット情報を含めるかどうか。デフォルト値は`false`です。 | | `null` | `STRING`型。CSV列がnullの場合に表示される文字。デフォルト値は`\N`です。 | | `quote` | `STRING`型。CSVファイル内のフィールドを囲むために使用される引用符文字。値が空の場合、引用符は使用されません。デフォルト値は`"`です。 | -| `binary_encoding_method` | `STRING`型。バイナリデータのエンコード方式。2 または`"base64"` `"hex"`指定できます。デフォルト値は`"base64"`です。 | +| `binary_encoding_method` | `STRING`型。バイナリデータのエンコード方式。`"base64"`または`"hex"`を指定できます。デフォルト値は`"base64"`です。 | `sink.dispatchers` : MQタイプのシンクの場合、このパラメータを使用してイベントディスパッチャを設定できます。サポートされているディスパッチャは`default` 、 `ts` 、 `index-value` 、 `table`です。ディスパッチャのルールは以下のとおりです。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index 5164998dd9a4e..27851cda5e61d 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -23,7 +23,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `cert` : TLS 接続用の PEM 形式の証明書ファイルのパスを指定します (オプション)。 - `cert-allowed-cn` : TLS 接続の PEM 形式の共通名のパスを指定します (オプション)。 - `key` : TLS 接続用の PEM 形式の秘密鍵ファイルのパスを指定します (オプション)。 -- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。6 `sink-uri` `time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。12 パラメータと`time-zone`パラメータの`tz`を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。 +- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。`sink-uri`の`time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。`tz`パラメータと`time-zone`パラメータの両方を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。 - `cluster-id` : (オプション) TiCDC クラスターの ID。デフォルト値は`default`です。 `cluster-id`は TiCDC クラスターの一意の識別子です。同じ`cluster-id`を持つ TiCDC ノードは同じクラスターに属します。 `cluster-id`の長さは最大 128 文字です。 `cluster-id` `^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$`のパターンに従う必要があり、 `owner` 、 `capture` 、 `task` 、 `changefeed` 、 `job` 、 `meta`のいずれかにすることはできません。 ## cdc server構成ファイルのパラメータ {#code-cdc-server-code-configuration-file-parameters} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index dda9e120d3ca8..3bc6116929d45 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -408,7 +408,7 @@ large-message-handle-compression = "none" - `large-message-handle-compression`で指定された圧縮アルゴリズムは、単一のKafkaメッセージを圧縮します。圧縮は、メッセージサイズの制限と比較する前に実行されます。 - 同時に、 [`sink-uri`](#configure-sink-uri-for-kafka)の`compression`パラメータを使用して圧縮アルゴリズムを設定することもできます。この圧縮アルゴリズムは、複数のKafkaメッセージを含むデータ送信リクエスト全体に適用されます。 -`large-message-handle-compression`設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。5 に`compression` [`sink-uri`](#configure-sink-uri-for-kafka)設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 +`large-message-handle-compression`設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 前述の 2 つの圧縮方法の圧縮率は次のように計算されます`compression ratio = size before compression / size after compression * 100` 。 diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 2d06a3125f1aa..52ed4901b386e 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -103,7 +103,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access このロールは、APIキーがデータアプリにリンクされたデータソースに対してデータの読み取りまたは書き込みを行えるかどうかを制御するために使用されます。 `ReadOnly`または`ReadAndWrite`ロールを選択できます。 - - `ReadOnly` : API キーで`SELECT` 、 {{B-PLACEHOLDER `SHOW` 、 `USE` `DESC` }} 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 + - `ReadOnly` : API キーで`SELECT` 、 `SHOW` 、 `USE` 、 `DESC` 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 - `ReadAndWrite` : このAPIキーは、データの読み書きを可能にします。このAPIキーを使用して、DMLステートメントやDDLステートメントなど、すべてのSQLステートメントを実行できます。 3. （オプション）APIキーの希望するレート制限を設定します。 diff --git a/tidb-cloud/data-service-app-config-files.md b/tidb-cloud/data-service-app-config-files.md index 33c2855107677..0f2c2f461f19a 100644 --- a/tidb-cloud/data-service-app-config-files.md +++ b/tidb-cloud/data-service-app-config-files.md @@ -163,7 +163,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 | `method` | string | エンドポイントの HTTP メソッド。 `GET`を使用してデータを取得し、 `POST`を使用してデータを作成または挿入し、 `PUT`を使用してデータを更新または変更し、 `DELETE`を使用してデータを削除できます。 | | `endpoint` | string | データ アプリ内のエンドポイントの一意のパス。パスには、文字、数字、アンダースコア ( `_` )、およびスラッシュ ( `/` ) のみを使用できます。パスはスラッシュ ( `/` ) で始まり、文字、数字、またはアンダースコア ( `_` ) で終わる必要があります。例: `/my_endpoint/get_id` 。パスの長さは 64 文字未満である必要があります。 | | `cluster_id` | string | エンドポイントのTiDB Cloud Starterインスタンスの ID です。インスタンスの URL から取得できます。たとえば、インスタンスの URL が`https://tidbcloud.com/tidbs/1234567891234567890/overview?orgId=`の場合、インスタンス ID は`1234567891234567890`です。 | -| `params` | 配列 | エンドポイントで使用されるパラメーター。パラメーターを定義することで、エンドポイントを介してクエリ内のパラメーター値を動的に置き換えることができます。 `params`では、1 つまたは複数のパラメーターを定義できます。各パラメーターについて、 `name` 、 `type` 、 `required` 、および`default`フィールドを定義する必要があります。エンドポイントにパラメーターが必要ない場合は`params` }} のように { `"params": []` PLACEHOLDER-5-PLACEHOLDER-E}} を空のままにすることができます。 | +| `params` | 配列 | エンドポイントで使用されるパラメーター。パラメーターを定義することで、エンドポイントを介してクエリ内のパラメーター値を動的に置き換えることができます。 `params`では、1 つまたは複数のパラメーターを定義できます。各パラメーターについて、 `name` 、 `type` 、 `required` 、および`default`フィールドを定義する必要があります。エンドポイントにパラメーターが必要ない場合は、 `"params": []`のように`params`を空のままにすることができます。 | | `params.name` | string | パラメータ名。名前には文字、数字、アンダースコアのみを使用できます（ `_` ）。また、文字またはアンダースコアで始まる必要があります（ `_` ）。 `page`および`page_size`はリクエスト結果のページネーション用に**予約されて**いるため、パラメータ名として使用しないでください。 | | `params.type` | string | パラメーターのデータ型。サポートされている値は`string` 、 `number` 、 `integer` 、 `boolean` 、および`array` 。 `string`型のパラメーターを使用する場合は、引用符（ `'`または`"` ）を追加する必要はありません。例えば、 `foo` `string`タイプに対して有効であり、 `"foo"`として処理されますが、 `"foo"`は`"\"foo\""`として処理されます。 | | `params.required` | integer | リクエストでパラメータが必須かどうかを指定します。サポートされている値は、 `0` (必須ではない) と`1` (必須) です。デフォルト値は`0`です。 | diff --git a/tidb-cloud/data-service-get-started.md b/tidb-cloud/data-service-get-started.md index f2322409f1685..12c0e96642d3e 100644 --- a/tidb-cloud/data-service-get-started.md +++ b/tidb-cloud/data-service-get-started.md @@ -203,7 +203,7 @@ HTTPSリクエストを送信することでエンドポイントを呼び出す このロールは、APIキーがデータアプリにリンクされたTiDB Cloud Starterインスタンスに対してデータの読み取りまたは書き込みを行えるかどうかを制御するために使用されます。 `ReadOnly`または`ReadAndWrite`ロールを選択できます。 - - `ReadOnly` : API キーで`SELECT` 、 {{B-PLACEHOLDER `SHOW` 、 `USE` `DESC` }} 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 + - `ReadOnly` : API キーで`SELECT` 、 `SHOW` 、 `USE` 、 `DESC` 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 - `ReadAndWrite` : このAPIキーは、データの読み書きを可能にします。このAPIキーを使用して、DMLステートメントやDDLステートメントなど、すべてのSQLステートメントを実行できます。 3. （オプション）APIキーの希望するレート制限を設定します。 diff --git a/tidb-cloud/prometheus-grafana-integration.md b/tidb-cloud/prometheus-grafana-integration.md index 7eec243d6b66d..e0504e6d1ed31 100644 --- a/tidb-cloud/prometheus-grafana-integration.md +++ b/tidb-cloud/prometheus-grafana-integration.md @@ -13,7 +13,7 @@ TiDB Cloudは[Prometheus](https://prometheus.io/)APIエンドポイントを提 - TiDB CloudをPrometheusと統合するには、自己ホスト型またはマネージド型のPrometheusサービスが必要です。 -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、TiDB Cloud で`Organization Owner`または`Instance Manager`アクセス権が必要です。統合ページを表示するには、 TiDB Cloud の組織内の対象の TiDB Cloud TiDB Cloud Essential TiDB Cloud Premium Premium インスタンスにアクセスするための {{B-PLACEHOLDER-2 -`Project Viewer`または`Instance Viewer`ロール以上が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、TiDB Cloud で`Organization Owner`または`Instance Manager`アクセス権が必要です。統合ページを表示するには、 TiDB Cloud の組織内の対象のTiDB Cloud Essential TiDB Cloud Premiumインスタンスにアクセスするための`Project Viewer`または`Instance Viewer`ロール以上が必要です。 ## 制限 {#limitation} 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..787d7b6ae3e9e 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -142,7 +142,7 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 ## ステップ3. クラスターポリシーをアタッチする {#step-3-attach-the-cluster-policy} -[クラスタポリシーをアタッチする](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html) [前提条件](#prerequisites-for-essential)して、 TiDB Cloud がMSK クラスターに接続できるようにします。2 で取得したTiDB Cloud AWS アカウント ID を使用してください。 +[クラスタポリシーをアタッチする](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html)して、 TiDB Cloud がMSK クラスターに接続できるようにします。[前提条件](#prerequisites-for-essential)で取得したTiDB Cloud AWS アカウント ID を使用してください。 ## ステップ4. マルチVPC接続を有効にする {#step-4-turn-on-multi-vpc-connectivity} 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..34829fbb8b9b8 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -657,7 +657,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **IPv4 範囲**: ネットワーク計画に基づいて CIDR を設定します - **承認されたプロジェクト**: [前提条件](#prerequisites)で取得したTiDB Cloudの Google Cloud プロジェクト (例: `tidbcloud-prod-000` )。 -3. **kafka-proxy-psc**の詳細ページに移動します。3 （例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-proxy-psc` ） `Service attachment`メモします。これは、 TiDB Cloudがこの PSC に接続する際に使用されます。 +3. **kafka-proxy-psc**の詳細ページに移動します。 `Service attachment` （例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-proxy-psc` ）をメモします。これは、 TiDB Cloudがこの PSC に接続する際に使用されます。 4. VPC ネットワークの詳細ページに移動し、すべてのブローカーの PSC トラフィックを許可するファイアウォール ルールを追加します。 diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 010b5bbaf1357..e28d9e67fea4c 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -762,7 +762,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の ... } -5. `terraform apply`コマンドを実行し、確認のために`yes`入力します。5 コマンドでステータスを確認すると、 `RESUMING`になっていること`terraform state show tidbcloud_cluster.${resource-name}`わかります。 +5. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 `terraform state show tidbcloud_cluster.${resource-name}`コマンドでステータスを確認すると、 `RESUMING`になっていることがわかります。 # tidbcloud_cluster.example_cluster: resource "tidbcloud_cluster" "example_cluster" { diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index eb23c6f674a23..f206bc83192f4 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -66,7 +66,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク file_name = "your_csv_path" } - ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。1 の詳細は`csv_format` [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)記載されています。 + ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。 `csv_format`の詳細は [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)に記載されています。 3. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 diff --git a/tidb-cloud/ticloud-cluster-create.md b/tidb-cloud/ticloud-cluster-create.md index 5fcd0eb1f74d8..bac9e7ec94dda 100644 --- a/tidb-cloud/ticloud-cluster-create.md +++ b/tidb-cloud/ticloud-cluster-create.md @@ -46,7 +46,7 @@ ticloud serverless create --display-name --region --max- | -n, --display-name 文字列 | 作成するクラスターの名前を指定します。 | はい | 非対話型モードでのみ動作します。 | | --spending-limit-monthly int | 月間最大支出限度額を USD セント単位で指定します。 | いいえ | 非対話型モードでのみ動作します。 | | -p, --project-id 文字列 | クラスターが作成されるプロジェクトのIDを指定します。デフォルト値は`default project`です。 | いいえ | 非対話型モードでのみ動作します。 | -| -r, --region 文字列 | クラウドリージョンの名前を指定します。1 コマンド`ticloud serverless region`使用すると、利用可能なすべてのリージョンを表示できます。 | はい | 非対話型モードでのみ動作します。 | +| -r, --region 文字列 | クラウドリージョンの名前を指定します。 `ticloud serverless region`コマンドを使用すると、利用可能なすべてのリージョンを表示できます。 | はい | 非対話型モードでのみ動作します。 | | --disable-public-endpoint | パブリックエンドポイントを無効にします。クラスターへのパブリックアクセスを禁止する場合は、このオプションを使用します。 | いいえ | 非対話型モードでのみ動作します。 | | --encryption | 二重層データ暗号化を有効にします。TiDB Cloud Essential クラスタではデフォルトで有効、 TiDB Cloud Starter クラスタではデフォルトで無効になっています。 | いいえ | 非対話型モードでのみ動作します。 | | --max-rcu int32 | TiDB Cloud Essential クラスターの最大リクエスト容量単位 (RCU) を 100000 まで設定します。 | いいえ | 非対話型モードでのみ動作します。 | diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index ddad2ea0241aa..88047dd4b637f 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -353,7 +353,7 @@ TiDB Cloudデータ サービスは、次の Chat2Query v1 エンドポイント | -- | --------------- | ------------------------------------------------------------------------ | | 役職 | `/v1/chat2data` | このエンドポイントを使用すると、ターゲット データベース名と指示を指定して、人工知能を使用して SQL ステートメントを生成および実行できます。 | -`/v1/chat2data`エンドポイントを直接呼び出して、SQL文を生成・実行できます。3 と比較すると、 `/v2/chat2data` `/v1/chat2data`レスポンスが速くなりますが、パフォーマンスは低くなります。 +`/v1/chat2data`エンドポイントを直接呼び出して、SQL文を生成・実行できます。 `/v2/chat2data`と比較すると、 `/v1/chat2data`はレスポンスが速くなりますが、パフォーマンスは低くなります。 TiDB Cloudは、エンドポイントの呼び出しを支援するためのコードサンプルを生成します。サンプルコードを入手して実行するには、 [エンドポイントのコード例を取得する](#get-the-code-example-of-an-endpoint)参照してください。 diff --git a/tidb-cloud/use-chat2query-sessions.md b/tidb-cloud/use-chat2query-sessions.md index f10adb8defed1..b3d16df184bc0 100644 --- a/tidb-cloud/use-chat2query-sessions.md +++ b/tidb-cloud/use-chat2query-sessions.md @@ -83,7 +83,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://eu-cen - `question` :*文字列*。必要なクエリを説明する自然言語での質問。 - `feedback_answer_id` ：*文字列*。フィードバック回答ID。このフィールドはオプションであり、フィードバックにのみ使用されます。 - `feedback_task_id` ：*文字列*。フィードバックタスクID。このフィールドはオプションであり、フィードバックにのみ使用されます。 -- `sql_generate_mode` :*文字列*。SQL文を生成するモード。値は`direct`または`auto_breakdown`です。8 `direct`設定すると、APIは指定された`question` SQL文に基づいて直接SQL文を生成します。12 に設定すると、APIは`auto_breakdown` `question` SQL文を複数のタスクに分割し、各タスクごとにSQL文を生成します。 +- `sql_generate_mode` :*文字列*。SQL文を生成するモード。値は`direct`または`auto_breakdown`です。 `direct`に設定すると、APIは指定された`question`に基づいて直接SQL文を生成します。 `auto_breakdown`に設定すると、APIは`question`を複数のタスクに分割し、各タスクごとにSQL文を生成します。 応答の例は次のとおりです。 diff --git a/tidb-control.md b/tidb-control.md index 0ff921d40b43d..4d7edfa721872 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -267,7 +267,7 @@ tidb-ctl base64decode [table_id] [base64_data] 実際には、 KEY が`/tidb/ddl/all_schema_versions/foo`で VALUE が`bar`あるキーと値のペアが etcd に追加されます。 -- `tidb-ctl etcd delkey` etcd 内の KEY を削除します。2 または`/tidb/ddl/fg/owner/` `/tidb/ddl/all_schema_versions/`プレフィックスを持つ KEY のみ削除できます。 +- `tidb-ctl etcd delkey` etcd 内の KEY を削除します。`/tidb/ddl/fg/owner/`または`/tidb/ddl/all_schema_versions/`プレフィックスを持つ KEY のみ削除できます。 ```shell tidb-ctl etcd delkey "/tidb/ddl/fg/owner/foo" diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 70ceb6cb370d4..4e7e4de889dac 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -29,7 +29,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 #### `IMPORT INTO` {#import-into} -`IMPORT INTO`タスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。3 タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、 `IMPORT INTO`タスクにデータインポート専用の[特定のTiDBノード](/system-variables.md#tidb_service_scope-new-in-v740)を指定することができ`IMPORT INTO` 。 +`IMPORT INTO`タスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。`IMPORT INTO`タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、データインポート用に`IMPORT INTO`専用の[特定のTiDBノード](/system-variables.md#tidb_service_scope-new-in-v740)を指定することができます。 [TiDB グローバルソート](/tidb-global-sort.md)使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をstorageとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、ストレージコストを節約できます。 diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index 058d5c0e97aff..4ed7b819769ea 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -11,7 +11,7 @@ summary: TiDB Lightningのモニター構成と監視メトリックについて TiDB Lightning を手動でインストールする場合は、以下の手順に従ってください。 -`tidb-lightning`のメトリクスは、Prometheus が検出済みであれば直接収集できます。3 のメトリクスポートは`tidb-lightning.toml`のように設定できます。 +`tidb-lightning`のメトリクスは、Prometheus が検出済みであれば直接収集できます。`tidb-lightning.toml`のメトリクスポートは次のように設定できます。 ```toml [lightning] diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 097cb6ea851f9..c419f6369184e 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -20,7 +20,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `-d ` | ローカル ディレクトリまたはデータ ファイルの[外部ストレージURI](/external-storage-uri.md) 。 | `mydumper.data-source-dir` | | `-L ` | ログ`info` : `debug` 、または`error` `warn`は`info` `fatal` 。 | `lightning.level` | | `-f ` | [テーブルフィルタルール](/table-filter.md) 。複数回指定できます。 | `mydumper.filter` | -| `--backend ` | インポート モードを選択します。1 は`local` 、 `tidb` [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)指します。 | `tikv-importer.backend` | +| `--backend ` | インポート モードを選択します。`local`は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を、 `tidb`は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を指します。 | `tikv-importer.backend` | | `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。「-」に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | | `--status-addr ` | TiDB Lightning HTTPサーバーのリスニング アドレス | `lightning.status-addr` | | `--pd-urls ` | PDエンドポイントアドレス。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 | `tidb.pd-addr` | diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index e6c86a3f801c3..5113f302654b4 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -179,7 +179,7 @@ trim-last-separator = false #### `header` {#header} - *すべての*CSV ファイルにヘッダー行が含まれているかどうか。 -- `header`が`true`場合、最初の行は*列名*として使用されます。7 が`header` `false`場合、最初の行は通常のデータ行として扱われます。 +- `header`が`true`の場合、最初の行は*列名*として使用されます。`header`が`false`の場合、最初の行は通常のデータ行として扱われます。 #### not-nullとnull {#code-not-null-code-and-code-null-code} diff --git a/tidb-lightning/tidb-lightning-requirements.md b/tidb-lightning/tidb-lightning-requirements.md index d32ffbb6eb69a..c4c9c4111c3d7 100644 --- a/tidb-lightning/tidb-lightning-requirements.md +++ b/tidb-lightning/tidb-lightning-requirements.md @@ -15,7 +15,7 @@ TiDB Lightningを使用する前に、環境が要件を満たしているかど ## 対象データベースのストレージスペース {#storage-space-of-the-target-database} -ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 +ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。[標準的なハードウェア要件](/hardware-and-software-requirements.md)に加え、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 - インデックスは余分なスペースを占める可能性があります。 - RocksDB には空間増幅効果があります。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index a202df09b9256..0bcb8dcf62720 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -163,7 +163,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= TiDB Lightning Local-backend は、v4.0.0 以降のバージョンの TiDB クラスターへのデータインポートのみをサポートしています。Local-backend を使用して v2.x または v3.x クラスターにデータをインポートしようとすると、上記のエラーが報告されます。その場合は、設定を変更して、データのインポートに Importer-backend または TiDB-backend を使用するように設定できます。 -`nightly`バージョンの中には、v4.0.0-beta.2 に類似しているものもあります。これらの`nightly`バージョンのTiDB Lightning は、実際にはローカルバックエンドをサポートしています。5 バージョン`nightly`使用時にこのエラーが発生した場合は、設定`check-requirements = false`設定することでバージョンチェックを省略できます。このパラメータを設定する前に、 TiDB Lightningの設定が対応するバージョンをサポートしていることを確認してください。そうでない場合、インポートが失敗する可能性があります。 +`nightly`バージョンの中には、v4.0.0-beta.2 に類似しているものもあります。これらの`nightly`バージョンのTiDB Lightning は、実際にはローカルバックエンドをサポートしています。`nightly`バージョンの使用時にこのエラーが発生した場合は、設定`check-requirements = false`設定することでバージョンチェックを省略できます。このパラメータを設定する前に、 TiDB Lightningの設定が対応するバージョンをサポートしていることを確認してください。そうでない場合、インポートが失敗する可能性があります。 ### `restore table test.district failed: unknown columns in header [...]` {#restore-table-test-district-failed-unknown-columns-in-header} 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/tidb-scheduling.md b/tidb-scheduling.md index 58e579f323e2b..540ac00881a17 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -67,7 +67,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン - 各 TiKV ピアによって報告される状態情報: - 各 TiKV ピアは定期的に PD にハートビートを送信します。PD はストアが生きているかどうかを確認するだけでなく、ハートビートメッセージで[`StoreState`](https://github.com/pingcap/kvproto/blob/release-8.5/proto/pdpb.proto#L473)も収集します。3 には`StoreState`が含まれます。 + 各 TiKV ピアは定期的に PD にハートビートを送信します。PD はストアが生きているかどうかを確認するだけでなく、ハートビートメッセージで[`StoreState`](https://github.com/pingcap/kvproto/blob/release-8.5/proto/pdpb.proto#L473)も収集します。`StoreState`には次の情報が含まれます。 - ディスク容量合計 - 使用可能なディスク容量 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 1eeedde6684f5..e4c235a474ff0 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -153,7 +153,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ - 3.3.2 実行計画の調査 - - `explain analyze {SQL}` 。実行時間が許容範囲内であれば、 `count`の結果の`explain analyze`と`row`の`execution info` 3-PLACEHOLDER-E}} の数を比較します。 `TableScan/IndexScan`行で大きな差が見つかった場合は、統計情報が間違っている可能性があります。他の行で大きな差が見つかった場合は、統計情報に問題がない可能性があります。 + - `explain analyze {SQL}` 。実行時間が許容範囲内であれば、 `explain analyze`の結果の`count`と`execution info`の`row`の数を比較します。 `TableScan/IndexScan`行で大きな差が見つかった場合は、統計情報が間違っている可能性があります。他の行で大きな差が見つかった場合は、統計情報に問題がない可能性があります。 - `select count(*)` 。実行プランに`join`操作が含まれている場合、 `explain analyze`の実行に時間がかかる場合があります。 `select count(*)`を実行し、 `TableScan/IndexScan`の結果に含まれる`row count`の情報を比較することで、 `explain`情報にあるかどうかを確認できます。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index ef20c468fb5f7..724c3b74fcd33 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -34,7 +34,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_execution` : 現在実行中のコプロセッサ要求の数。 - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。1 はテーブル スキャン演算子、 `table_scan` `selection`選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`データ受信演算子です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。`table_scan`はテーブル スキャン演算子、 `selection`は選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`データ受信演算子です。 ### レイテンシメトリクス {#latency-metrics} diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 3f1804b255e9a..5156d2d79dc45 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -21,7 +21,7 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; > **Note:** > -> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。7 `1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。`1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 同じテーブルに対して複数のDDL文を実行した場合、最後に実行された文のみが確実に有効になります。次の例では、テーブル`tpch50`に対して2つのDDL文が実行されていますが、2番目の文（レプリカを削除する文）のみが確実に有効になります。 diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index f850e66c3a35a..9908754b79d41 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インスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 4373ac825acee..ec309490ec366 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1697,7 +1697,7 @@ Titanに関連するコンフィグレーション項目。 - `lockcf`のデフォルト値: `"128MiB"` - 最小値: `0` - 単位：KiB｜MiB｜GiB -- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、{{B-PLACEHOLDER `max-bytes-for-level-base`の値は`write-buffer-size * 4`にする必要があります。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。 +- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、 `max-bytes-for-level-base`の値は`write-buffer-size * 4`にする必要があります。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。 ### `target-file-size-base` {#target-file-size-base} diff --git a/tikv-control.md b/tikv-control.md index d73cd7fbbc448..d24d07c8a121a 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -15,7 +15,7 @@ TiKV Control ( `tikv-ctl` ) は、クラスターの管理に使用される TiK > > 使用する制御ツールのバージョンは、クラスターのバージョンと一致させることをお勧めします。 -`tikv-ctl`は`tiup`コマンドにも統合されています。4 ツール`tikv-ctl`呼び出すには、以下のコマンドを実行してください。 +`tikv-ctl`は`tiup`コマンドにも統合されています。`tikv-ctl`ツールを呼び出すには、以下のコマンドを実行してください。 ```shell tiup ctl:v tikv @@ -139,7 +139,7 @@ AAFF `region`サブコマンドの場合: -- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。7 と`-r` `--all-regions`同時に使用できないことに注意してください。 +- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。`-r`と`--all-regions`は同時に使用できないことに注意してください。 - 印刷するリージョンの数を制限するには、 `--limit`オプションを使用します (デフォルト: `16` )。 - 特定のキー範囲に含まれるリージョンを照会するには、 `--start`および`--end`オプションを使用します (デフォルト: 範囲制限なし、16 進形式)。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 995fb626e64a0..25406c909c6c4 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -36,7 +36,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。4 フィールドに指定されたユーザーが``マシン上に存在しない場合、このユーザーは自動的に作成されます。 +- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。``フィールドに指定されたユーザーがターゲットマシン上に存在しない場合、このユーザーは自動的に作成されます。 - `group` : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は``番目のフィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 9e45b391b7a2b..819aeb0b9c345 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -515,7 +515,7 @@ tiup cluster import --dir=/path/to/tidb-ansible ## 操作ログを表示する {#view-the-operation-log} -操作ログを表示するには、 `audit`コマンドを使用します。3 コマンドの使用方法は`audit`のとおりです。 +操作ログを表示するには、 `audit`コマンドを使用します。`audit`コマンドの使用方法は次のとおりです。 ```bash Usage: diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index 0c53eaf5aaa9c..2db8f1b401790 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -34,7 +34,7 @@ tiup mirror genkey [flags] ### -p, --public {#p-public} - オプション`-n/--name`で指定された秘密鍵に対応する公開鍵を表示します。 -- `-p/--public`指定された場合、 TiUP は新しい`-n/--name`鍵を作成しません。3 で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 +- `-p/--public`が指定された場合、 TiUP は新しい秘密鍵を作成しません。`-n/--name`で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-edit-config.md b/tiup/tiup-component-cluster-edit-config.md index e5dc8410cfab1..cefb9149e3cd9 100644 --- a/tiup/tiup-component-cluster-edit-config.md +++ b/tiup/tiup-component-cluster-edit-config.md @@ -5,7 +5,7 @@ summary: tiup cluster edit-config` コマンドを使用すると、デプロイ # tiup cluster edit-config {#tiup-cluster-edit-config} -クラスタのデプロイ後にクラスタ設定を変更する必要がある場合は、 `tiup cluster edit-config`コマンドを使用してエディタを起動し、クラスタの[トポロジファイル](/tiup/tiup-cluster-topology-reference.md)編集できます。このエディタは、デフォルトで`$EDITOR`環境変数に指定されています。7 環境変数が存在しない場合は、 `$EDITOR`エディタ`vi`使用されます。 +クラスタのデプロイ後にクラスタ設定を変更する必要がある場合は、 `tiup cluster edit-config`コマンドを使用してエディタを起動し、クラスタの[トポロジファイル](/tiup/tiup-cluster-topology-reference.md)編集できます。このエディタは、デフォルトで`$EDITOR`環境変数に指定されています。`$EDITOR`環境変数が存在しない場合は、 `vi`エディタが使用されます。 > **Note:** > diff --git a/tiup/tiup-component-cluster-list.md b/tiup/tiup-component-cluster-list.md index 5594ed5a27876..5bbebab6b149d 100644 --- a/tiup/tiup-component-cluster-list.md +++ b/tiup/tiup-component-cluster-list.md @@ -5,7 +5,7 @@ summary: tiup-cluster は、同一の制御マシンを用いた複数のクラ # tiup cluster list {#tiup-cluster-list} -tiup-cluster は、同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートします。1 コマンド`tiup cluster list` 、現在ログインしているユーザーがこのコントロールマシンを使用してデプロイしたすべてのクラスターを出力します。 +tiup-cluster は、同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートします。`tiup cluster list`コマンドは、現在ログインしているユーザーがこのコントロールマシンを使用してデプロイしたすべてのクラスターを出力します。 > **Note:** > diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index d2ab7b3153407..b087b49ce15a2 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -5,7 +5,7 @@ summary: tiup dm edit-config`コマンドを使用すると、デプロイメン # tiup dm 編集設定 {#tiup-dm-edit-config} -クラスターのデプロイ後にクラスターサービス設定を変更する必要がある場合は、 `tiup dm edit-config`コマンドを使用してエディターを起動し、指定したクラスターの[トポロジファイル](/tiup/tiup-dm-topology-reference.md) . を変更できます。このエディターは、デフォルトで`$EDITOR`環境変数に指定されています。7 環境変数が存在しない場合は、 `$EDITOR`エディター`vi`使用されます。 +クラスターのデプロイ後にクラスターサービス設定を変更する必要がある場合は、 `tiup dm edit-config`コマンドを使用してエディターを起動し、指定したクラスターの[トポロジファイル](/tiup/tiup-dm-topology-reference.md) . を変更できます。このエディターは、デフォルトで`$EDITOR`環境変数に指定されています。`$EDITOR`環境変数が存在しない場合は、 `vi`エディターが使用されます。 > **Note:** > 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-list.md b/tiup/tiup-component-dm-list.md index 06432d8dd6866..6f88dabf2eaa6 100644 --- a/tiup/tiup-component-dm-list.md +++ b/tiup/tiup-component-dm-list.md @@ -5,7 +5,7 @@ summary: tiup-dm は、同一の制御マシンを用いた複数のクラスタ # tiup dm list {#tiup-dm-list} -`tiup-dm` `tiup dm list`同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートしています。2 コマンドを使用すると、現在ログインしているユーザーがコントロールマシンを使用してデプロイしているクラスターを確認できます。 +`tiup-dm`は、同じコントロールマシンを使用して複数のクラスターをデプロイすることをサポートしています。`tiup dm list`コマンドを使用すると、現在ログインしているユーザーがコントロールマシンを使用してデプロイしているクラスターを確認できます。 > **Note:** > diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 66a907642412f..9270af25018a0 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -63,7 +63,7 @@ global: ### `server_configs` {#server-configs} -`server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。6 `server_configs`は主に以下のフィールドが含まれます。 +`server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`セクションと同様に、 `server_configs`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。`server_configs`には主に以下のフィールドが含まれます。 - `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)参照してください。 - `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)参照してください。 diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index d8ee5335ad5d5..6e401479b2f35 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -125,4 +125,4 @@ tiup --help TiUPコマンドは TiUP の内部コードに実装され、パッケージ管理操作に使用されますが、 TiUPコンポーネントはTiUPコマンドによってインストールされる独立したコンポーネントパッケージです。 -たとえば、 `tiup list`コマンドを実行すると、 TiUP は独自の内部コードを直接実行します。3 コマンドを実行する`tiup playground` 、 TiUP はTiUP「playground」という名前のローカル パッケージがあるかどうかを確認し、ない場合はミラーからパッケージをダウンロードして実行します。 +たとえば、 `tiup list`コマンドを実行すると、 TiUP は独自の内部コードを直接実行します。`tiup playground`コマンドを実行すると、 TiUP は「playground」という名前のローカル パッケージがあるかどうかを確認し、ない場合はミラーからパッケージをダウンロードして実行します。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index fa02286050085..49ae5d4c684ca 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -75,7 +75,7 @@ select `key`, count(*) as `count` from information_schema.data_lock_waits group 頻繁に問題が発生しているキーがわかっている場合は、 `TIDB_TRX`または`CLUSTER_TIDB_TRX`テーブルからキーをロックしようとしたトランザクションの情報を取得してみることができます。 -`TIDB_TRX`と`CLUSTER_TIDB_TRX`テーブルに表示される情報は、クエリ実行時に実行中のトランザクションの情報でもあることに注意してください。これらのテーブルには、完了したトランザクションの情報は表示されません。同時実行トランザクションの数が多い場合、クエリの結果セットも大きくなる可能性があります。5 句または`where`句`limit`使用すると、ロック待機時間が長いトランザクションをフィルタリングできます。Lock ビューで複数のテーブルを結合する場合、異なるテーブルのデータが同時に取得されない可能性があり、異なるテーブルの情報が一致しない可能性があることに注意してください。 +`TIDB_TRX`と`CLUSTER_TIDB_TRX`テーブルに表示される情報は、クエリ実行時に実行中のトランザクションの情報でもあることに注意してください。これらのテーブルには、完了したトランザクションの情報は表示されません。同時実行トランザクションの数が多い場合、クエリの結果セットも大きくなる可能性があります。`limit`句または`where`句を使用すると、ロック待機時間が長いトランザクションをフィルタリングできます。Lock ビューで複数のテーブルを結合する場合、異なるテーブルのデータが同時に取得されない可能性があり、異なるテーブルの情報が一致しない可能性があることに注意してください。 たとえば、 `where`句を使用してロック待機時間が長いトランザクションをフィルタリングするには、次の SQL ステートメントを実行します。 diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index f4ebc1de34924..35583af34f413 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -26,7 +26,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - すべてのプロセスが実行中の場合は、 `tidb-server`ログをチェックして、次のメッセージが表示されているかどうかを確認します。 - - 情報スキーマが古くなっています: `tikv-server`接続できない場合にこのメッセージが表示されます。3 と`pd-server` `tikv-server`状態とログを確認してください。 + - 情報スキーマが古くなっています: `tikv-server`接続できない場合にこのメッセージが表示されます。`pd-server`と`tikv-server`の状態とログを確認してください。 - panic：プログラムに問題が発生した場合、このメッセージが表示されます。詳細なpanicログをご提供いただければ、 [バグを報告する](/support.md) . 3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 diff --git a/tune-tikv-memory-performance.md b/tune-tikv-memory-performance.md index 663a40d6dd49e..cade589a40db5 100644 --- a/tune-tikv-memory-performance.md +++ b/tune-tikv-memory-performance.md @@ -25,7 +25,7 @@ TiKV 3.0以降では、デフォルトですべてのCFが1つのブロックキ TiKV 3.0 より前では、共有ブロックキャッシュはサポートされていないため、各 CF ごとにブロックキャッシュを個別に構成する必要があります。 -各 CF にはそれぞれ`write buffer`あります。3 パラメータ`write-buffer-size`設定することでサイズを設定できます。 +各 CF にはそれぞれ`write buffer`あります。`write-buffer-size`パラメータを設定することでサイズを設定できます。 ## パラメータ仕様 {#parameter-specification}