diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index 74fad545ecf99..8d73016a99ca0 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -212,7 +212,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し 1 row in set (0.01 sec) ``` -ベクトルを明示的に文字列表現にキャストすることもできます。1関数`VEC_AS_TEXT()`例に挙げましょう。 +ベクトルを明示的に文字列表現にキャストすることもできます。`VEC_AS_TEXT()`関数の使用を例に挙げましょう。 ```sql -- The string is first implicitly cast to a vector, and then the vector is explicitly cast to a string, thus returning a string in the normalized format: diff --git a/alert-rules.md b/alert-rules.md index 9327cc77e065b..d813f8a443bf5 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -395,7 +395,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - - 店内に十分なスペースがあるかどうかを確認します。 + - ストア内に十分なスペースがあるかどうかを確認します。 - ラベル構成が設定されている場合は、それに従って追加のレプリカ用のストアがあるかどうかを確認します。 #### `PD_cluster_slow_tikv_nums` {#pd-cluster-slow-tikv-nums} @@ -406,7 +406,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - 低速TiKVノードがあります。`raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)を参照してください。 + 低速TiKVノードがあります。`raftstore.inspect-interval`はTiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)を参照してください。 - 解決： @@ -467,7 +467,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. ネットワークがクリアかどうかを確認してください。 2. リモート TiKV がダウンしていないかどうかを確認します。 - 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。1の解決策を参照してください[`TiKV_channel_full_total`](#tikv_channel_full_total) + 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 #### `TiKV_channel_full_total` {#tikv-channel-full-total} diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index 682e8667a8c0b..02748e99cde07 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -59,7 +59,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 ### TiKVはデータ処理が遅い {#tikv-is-slow-in-data-processing} -TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。15 `170ms`差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。 +TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。`170ms`を差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。 ```sql +----------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------+---------------------------------+-----------+------+ diff --git a/as-of-timestamp.md b/as-of-timestamp.md index 5f0480094ef10..c1727a7a3a965 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -21,7 +21,7 @@ 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)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。 diff --git a/auto-increment.md b/auto-increment.md index 0175bde0b214e..1af3bc263a1cb 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -94,7 +94,7 @@ TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装しま CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int); ``` -クラスター内に2つのTiDBインスタンス（ `A`と`B`があるとします。7テーブルに対してそれぞれ`t`と`B` `A` `INSERT`ステートメントを実行すると、次のようになります。 +クラスター内に2つのTiDBインスタンス（ `A`と`B` ）があるとします。`A`と`B`でそれぞれ`t`テーブルに対して`INSERT`ステートメントを実行すると、次のようになります。 ```sql INSERT INTO t (c) VALUES (1) diff --git a/auto-random.md b/auto-random.md index 48f608910cf3c..a201e54b7feaa 100644 --- a/auto-random.md +++ b/auto-random.md @@ -21,7 +21,7 @@ TiDB で同時書き込みの多いワークロードを処理する方法の詳 `AUTO_RANDOM`は、 `BIGINT`列に値を自動的に割り当てるために使用される列属性です。自動的に割り当てられる値は**ランダム**かつ**一意**です。 -`AUTO_RANDOM`列のテーブルを作成するには、以下のステートメントを使用します。3列目`AUTO_RANDOM`主キーに含まれている必要があり、 `AUTO_RANDOM`列は主キーの最初の列です。 +`AUTO_RANDOM`列のテーブルを作成するには、以下のステートメントを使用します。`AUTO_RANDOM`列は主キーに含まれている必要があり、 `AUTO_RANDOM`列は主キーの最初の列です。 ```sql CREATE TABLE t (a BIGINT AUTO_RANDOM, b VARCHAR(255), PRIMARY KEY (a)); diff --git a/basic-features.md b/basic-features.md index 294859373f052..b5d38ea35f6e0 100644 --- a/basic-features.md +++ b/basic-features.md @@ -197,7 +197,7 @@ summary: TiDBの機能概要について学びましょう。 | [動的剪定](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E | | [範囲列パーティショニング](/partitioned-table.md#range-columns-partitioning) | Y | Y | Y | Y | Y | N | N | | [範囲 INTERVAL 分割](/partitioned-table.md#range-interval-partitioning) | Y | Y | Y | Y | E | N | N | -| [パーティションテーブルをパーティションテーブルに変換する](/partitioned-table.md#convert-a-partitioned-table-to-a-non-partitioned-table) | Y | Y | Y | N | N | N | N | +| [パーティションテーブルを非パーティションテーブルに変換する](/partitioned-table.md#convert-a-partitioned-table-to-a-non-partitioned-table) | Y | Y | Y | N | N | N | N | | [既存のテーブルをパーティション分割する](/partitioned-table.md#partition-an-existing-table) | Y | Y | Y | N | N | N | N | | [グローバルインデックス](/global-indexes.md) | Y | N | N | N | N | N | N | @@ -319,10 +319,10 @@ summary: TiDBの機能概要について学びましょう。 [^2]: バージョン6.5.0以降、 [`tidb_allow_function_for_expression_index`](/system-variables.md#tidb_allow_function_for_expression_index-new-in-v520)システム変数にリストされている関数に対して作成された式インデックスはテスト済みであり、本番環境で使用できます。今後のリリースでは、さらに多くの関数がサポートされる予定です。この変数にリストされていない関数については、対応する式インデックスは本番環境での使用は推奨されません。詳細については、 [式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 -[^3]: サポートされている SQL ステートメントの完全なリストについては[ステートメント参照](/sql-statements/sql-statement-select.md)てください。 +[^3]: サポートされている SQL ステートメントの完全なリストについては[ステートメント参照](/sql-statements/sql-statement-select.md)を参照してください。 [^4]: [v6.4.0](/releases/release-6.4.0.md)以降、TiDB は[高性能かつグローバルに単調な`AUTO_INCREMENT`列](/auto-increment.md#mysql-compatibility-mode)をサポートします -[^5]: [TiDB v7.0.0](/releases/release-7.0.0.md)以降、新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的機能です[v7.6.0](/releases/release-7.6.0.md)以降、TiDB は`LOAD DATA`トランザクションで MySQL と同じように処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB トランザクション モード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 +[^5]: [TiDB v7.0.0](/releases/release-7.0.0.md)以降、新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的機能です。[v7.6.0](/releases/release-7.6.0.md)以降、TiDB は`LOAD DATA`トランザクションで MySQL と同じように処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB トランザクション モード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 [^6]: バージョン 7.5.0 以降、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)レプリケーションは非推奨となりました。バージョン 8.3.0 以降、TiDB Binlogは完全に非推奨となりました。バージョン 8.4.0 以降、TiDB Binlogは削除されました。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスタをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 diff --git a/batch-processing.md b/batch-processing.md index 0b50bf2fdf8d6..85cbd51d333fb 100644 --- a/batch-processing.md +++ b/batch-processing.md @@ -63,7 +63,7 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` #### 制限事項 {#limitations} -- [自動コミット](/transaction-overview.md#autocommit) `INSERT` `DELETE`のみ`UPDATE`サポートします`REPLACE` +- [自動コミット](/transaction-overview.md#autocommit) `INSERT`、`REPLACE`、`UPDATE`、`DELETE`ステートメントのみをサポートします #### ユースケース {#use-cases} 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-for-security-configuration.md b/best-practices-for-security-configuration.md index 8827b2af9b40c..8a109c7233f5a 100644 --- a/best-practices-for-security-configuration.md +++ b/best-practices-for-security-configuration.md @@ -66,7 +66,7 @@ TiDB Dashboardは、デフォルトでは信頼できるユーザー向けに設 TiDBのインストールには、デフォルトでコンポーネント間通信用の特権インターフェースがいくつか含まれています。これらのポートは主に内部通信用であるため、通常、ユーザーがアクセスできるようにする必要はありません。これらのポートをパブリックネットワークに公開すると、攻撃対象領域が拡大し、最小権限の原則に違反し、セキュリティ脆弱性のリスクが高まります。次の表は、TiDBクラスタのデフォルトのリスニングポートを示しています。 -| 成分 | デフォルトポート | プロトコル | +| コンポーネント | デフォルトポート | プロトコル | | --------------- | -------- | ---------- | | TiDB | 4000 | MySQL | | TiDB | 10080 | HTTP | diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index 51a9323935c03..edfdb9cd51c0b 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc ## 監視アーキテクチャ {#monitoring-architecture} -[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。2 [Grafana](https://grafana.com/) 、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 +[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。[Grafana](https://grafana.com/)は、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 ![The monitoring architecture in the TiDB cluster](/media/prometheus-in-tidb.png) diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 09fd4353ca6bb..9aedea093ca95 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -102,7 +102,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ - [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) - [`merge-schedule-limit`](/pd-configuration-file.md#merge-schedule-limit) -`Region Merge`パラメータのデフォルト設定はかなり保守的です。5 [PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 +`Region Merge`パラメータのデフォルト設定はかなり保守的です。[PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)に記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 ### 方法4: TiKVインスタンスの数を増やす {#method-4-increase-the-number-of-tikv-instances} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 3ba879f5e51b3..af5330f80a3f2 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -223,8 +223,8 @@ CREATE TABLE t1 ( TiDBオプティマイザは条件を分解した後、各部分の範囲を計算し、それらを結合します。この例では、次のように導出されます。 - - `(a1, b1) > (1, 10)`場合: `a1 > 1`の場合は 3 、 `a1 = 1`および`b1 > 10`の場合は`(1, +inf]` `(1, 10, 1, +inf]`の範囲を作成します。 - - `(a1, b1) < (10, 20)`の場合: `a1 < 10`と`[10, -inf, 10, 20)`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲​​ 7 を作成します。 + - `(a1, b1) > (1, 10)`の場合: `a1 > 1`の場合は範囲`(1, +inf]`を作成し、 `a1 = 1`および`b1 > 10`の場合は`(1, 10, 1, +inf]`を作成します。 + - `(a1, b1) < (10, 20)`の場合: `a1 < 10`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲`[10, -inf, 10, 20)`を作成します。 最終結果では、これらを組み合わせて、洗練された範囲`(1, 10, 1, +inf] UNION (1, 10) UNION [10, -inf, 10, 20)`得られます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 78bc5b47b483f..a27e00bfc910a 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -74,7 +74,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ - ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 - どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 -ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。1と`region-weight` `leader-weight`それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight` 「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight` 「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 +ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 ### ホットリージョンのスケジュール {#hot-regions-scheduling} @@ -165,7 +165,7 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー pd-ctl を使用すると、以下の3つの側面からスケジューリング戦略を調整できます。詳細は[PD Control](/pd-control.md)を参照してください。 -### スケジューラを手動で追加/削除する {#add-delete-scheduler-manually} +### スケジューラを手動で追加/削除する {#adddelete-scheduler-manually} PDはpd-ctlを介してスケジューラを動的に追加および削除することをサポートしています。例： @@ -173,7 +173,7 @@ PDはpd-ctlを介してスケジューラを動的に追加および削除する - `scheduler remove balance-leader-scheduler` : バランスリーダースケジューラを削除（無効化）する - `scheduler add evict-leader-scheduler 1` : ストア 1 のすべてのリーダーを削除するスケジューラを追加します。 -### オペレータを手動で追加/削除する {#add-delete-operators-manually} +### オペレータを手動で追加/削除する {#adddelete-operators-manually} PDはpd-ctlを介してオペレータを直接追加または削除することもできます。例えば： @@ -196,7 +196,7 @@ pd-ctl の`config show`コマンドを使用してスケジュール設定を確 このセクションでは、いくつかの一般的なシナリオを通じて PD スケジューリング戦略のベスト プラクティスについて説明します。 -### リーダー/リージョンが均等に分布していない {#leaders-regions-are-not-evenly-distributed} +### リーダー/リージョンが均等に分布していない {#leadersregions-are-not-evenly-distributed} PDの評価メカニズムでは、異なるストアのリーダー数とリージョン数だけでは負荷分散状況を完全に反映できないと判断されます。そのため、TiKVの実際の負荷やストレージ使用量から、負荷の不均衡が発生しているかどうかを確認する必要があります。 @@ -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} @@ -293,7 +293,7 @@ TiKV ノードに障害が発生した場合、PD はデフォルトで、対応 実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。 -TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。1 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)加算することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 +TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)を指定します（デフォルトでは無効）。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 46aed8212f1d5..40838b50a5c11 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -123,4 +123,4 @@ tiup ctl:v tikv --host=${ip:port} modify-tikv-config -n gc.max_ このパラメータは、Goプロセス全体で使用できるCPUコアの数を制御するために使用されます。デフォルトでは、この値は現在のマシンまたはcgroupのCPUコア数と同じです。 -Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。1パラメータの値を制限しないと、これらのバックグラウンドタスク`performance.max-procs` CPUを過剰に消費することになります。 +Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。`performance.max-procs`パラメータの値を制限しないと、これらのバックグラウンドタスクがCPUを過剰に消費することになります。 diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index dfa0b9ce22d1a..5fde99097fec7 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -94,7 +94,7 @@ BR を使用すると、ログ バックアップ データをバックアップ TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。 -- `--log.crypter.method` : 暗号化アルゴリズム。2、4、6 `aes192-ctr` `aes128-ctr`かになります。デフォルト値は`aes256-ctr` `plaintext` 、データは暗号化されません。 +- `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 - `--log.crypter.key-file` : キーファイル。`crypter.key`を渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 @@ -111,7 +111,7 @@ tiup br log start \ ただし、セキュリティ要件が高いシナリオでは、固定の暗号化キーをコマンドラインで直接渡すことは望ましくない場合があります。セキュリティをさらに強化するには、マスターキーベースの暗号化システムを使用して暗号化キーを管理できます。このシステムは、ログバックアップファイルごとに異なるデータキーを生成し、マスターキーのローテーションをサポートします。以下のパラメータを使用して設定できます。 -- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。2、4 `aes192-ctr`または`aes256-ctr` `aes128-ctr`かになります。デフォルト値は`plaintext`で、データは暗号化されません。 +- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。 ローカル ディスクに保存されているマスター キーを使用して暗号化します。 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index fa61bccac9e5b..49e14520207fe 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 baff23e8a32c6..7b508e2b9e287 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -53,7 +53,7 @@ Query OK, 0 rows affected (0.01 sec) ### キャッシュされたテーブルを検証する {#verify-a-cached-table} -キャッシュされたテーブルを検証するには、 `SHOW CREATE TABLE`ステートメントを使用します。テーブルがキャッシュされている場合、返される結果には`CACHED ON`番目の属性が含まれます。 +キャッシュされたテーブルを検証するには、 `SHOW CREATE TABLE`ステートメントを使用します。テーブルがキャッシュされている場合、返される結果には`CACHED ON`属性が含まれます。 ```sql SHOW CREATE TABLE users; @@ -115,7 +115,7 @@ TRACE SELECT * FROM users; 7 rows in set (0.00 sec) ``` -`UnionScan`演算子はキャッシュされたテーブルを読み取るために使用されるため、キャッシュされたテーブルの実行プランの`UnionScan`から`explain`までを確認できることに注意してください。 +`UnionScan`演算子はキャッシュされたテーブルを読み取るために使用されるため、`explain`を通じてキャッシュされたテーブルの実行プランで`UnionScan`を確認できることに注意してください。 ```sql +-------------------------+---------+-----------+---------------+--------------------------------+ @@ -155,7 +155,7 @@ SELECT * FROM users; > **Note:** > -> キャッシュされたテーブルにデータを挿入すると、第2レベルの書き込みレイテンシーが発生する可能性があります。このレイテンシーはグローバル環境変数[`tidb_table_cache_lease`](/system-variables.md#tidb_table_cache_lease-new-in-v600)によって制御されます。アプリケーションに応じてレイテンシーが許容できるかどうかを確認することで、キャッシュされたテーブル機能を使用するかどうかを決定できます。例えば、読み取り専用のシナリオでは、この値を`tidb_table_cache_lease`に増やすことができます。 +> キャッシュされたテーブルにデータを挿入すると、第2レベルの書き込みレイテンシーが発生する可能性があります。このレイテンシーはグローバル環境変数[`tidb_table_cache_lease`](/system-variables.md#tidb_table_cache_lease-new-in-v600)によって制御されます。アプリケーションに応じてレイテンシーが許容できるかどうかを確認することで、キャッシュされたテーブル機能を使用するかどうかを決定できます。例えば、読み取り専用のシナリオでは、`tidb_table_cache_lease`の値を増やすことができます。 > > ```sql > set @@global.tidb_table_cache_lease = 10; diff --git a/certificate-authentication.md b/certificate-authentication.md index 2405bba23e874..9721af9f02ac1 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -198,7 +198,7 @@ openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem ### サーバー証明書を使用するように TiDB を構成する {#configure-tidb-to-use-server-certificate} -TiDB設定ファイルの`[security]`セクションを変更します。この手順では`path/to/server-key.pem` CA証明書、サーバー鍵、サーバー証明書`path/to/ca-cert.pem`保存されるディレクトリを指定します。3、5、7 `path/to/server-cert.pem`任意のディレクトリに置き換えることができます。 +TiDB設定ファイルの`[security]`セクションを変更します。この手順では、CA証明書、サーバー鍵、サーバー証明書が保存されるディレクトリを指定します。`path/to/server-cert.pem` 、 `path/to/server-key.pem` 、 `path/to/ca-cert.pem`は任意のディレクトリに置き換えることができます。 ```toml [security] diff --git a/check-before-deployment.md b/check-before-deployment.md index 2c9f0e7898327..8a83fc282130a 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -656,7 +656,7 @@ sudo systemctl enable ntpd.service > > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネル パラメータです。 > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 - > - 少なくとも`vm.min_free_kbytes` ～ `1048576` KiB（1 GiB）に設定することをお勧めします。5 [NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)の場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 + > - `vm.min_free_kbytes`を少なくとも`1048576` KiB（1 GiB）に設定することをお勧めします。[NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 > - Linux カーネル 4.11 以前を実行しているシステムの場合は、 `net.ipv4.tcp_tw_recycle = 0`を設定することをお勧めします。 10. ユーザーの`limits.conf`ファイルを構成するには、次のコマンドを実行します。 @@ -754,8 +754,8 @@ sudo yum -y install numactl ## SELinuxを無効にする {#disable-selinux} -SELinux を無効にするか、permissive モードに設定する必要があります。現在のステータスを確認するには、 [ゲットエンフォース(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 +SELinux を無効にするか、permissive モードに設定する必要があります。現在のステータスを確認するには、 [getenforce(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 -SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。7または`enforcing` `permissive` `disabled`への変更は、再起動しないと有効になりません。 +SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。`enforcing`または`permissive`から`disabled`への変更は、再起動しないと有効になりません。 一部のシステム（Ubuntuなど）では、 `/etc/selinux/config`ファイルが存在せず、getenforceユーティリティがインストールされていない場合があります。その場合は、この手順をスキップしてください。 diff --git a/clustered-indexes.md b/clustered-indexes.md index a995be6de94c3..cd7d5607615bf 100644 --- a/clustered-indexes.md +++ b/clustered-indexes.md @@ -7,7 +7,7 @@ summary: クラスター化インデックスの概念、ユーザーシナリ TiDBはバージョン5.0以降、クラスター化インデックス機能をサポートしています。この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理することができます。 -この文脈における*「クラスター化」*という用語は*、データの格納方法の構成を*指し、*連携して動作するデータベースサーバーのグループを*指すものではありません。一部のデータベース管理システムでは、クラスター化されたインデックステーブルを*インデックス構成テーブル*（IOT）と呼んでいます。 +この文脈における*「クラスター化」*という用語は、*データの格納方法の構成*を指し、*連携して動作するデータベースサーバーのグループを*指すものではありません。一部のデータベース管理システムでは、クラスター化されたインデックステーブルを*インデックス構成テーブル*（IOT）と呼んでいます。 現在、TiDBの主キーを含むテーブルは、以下の2つのカテゴリに分類されます。 @@ -19,7 +19,7 @@ TiDBはバージョン5.0以降、クラスター化インデックス機能を > **Note:** > -> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスター化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスター化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスター化インデックスはデータの格納方法の物理的な実装を表します。 +> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスター化インデックスが有効になっている場合、 *`PRIMARY KEY`*と*クラスター化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスター化インデックスはデータの格納方法の物理的な実装を表します。 ## ユーザーシナリオ {#user-scenarios} @@ -39,7 +39,7 @@ TiDBはバージョン5.0以降、クラスター化インデックス機能を ### クラスター化インデックスを持つテーブルを作成する {#create-a-table-with-clustered-indexes} -TiDB v5.0以降では、 `CLUSTERED`の`NONCLUSTERED`の後に、予約語ではないキーワード`PRIMARY KEY`または`CREATE TABLE`を追加することで、テーブルの主キーがクラスター化インデックスであるかどうかを指定できます。例： +TiDB v5.0以降では、 `CREATE TABLE`文の`PRIMARY KEY`の後に、予約語ではないキーワード`CLUSTERED`または`NONCLUSTERED`を追加することで、テーブルの主キーがクラスター化インデックスであるかどうかを指定できます。例： ```sql CREATE TABLE t (a BIGINT PRIMARY KEY CLUSTERED, b VARCHAR(255)); @@ -96,7 +96,7 @@ ALTER TABLE t DROP INDEX `PRIMARY`; - コマンド`SHOW CREATE TABLE`を実行します。 - コマンド`SHOW INDEX FROM`を実行します。 -- システムテーブル`TIDB_PK_TYPE`の`information_schema.tables`列をクエリします。 +- システムテーブル`information_schema.tables`の`TIDB_PK_TYPE`列をクエリします。 コマンド`SHOW CREATE TABLE`を実行すると、 `PRIMARY KEY`の属性が`CLUSTERED`か`NONCLUSTERED`かを確認できます。例: @@ -126,7 +126,7 @@ mysql> SHOW INDEX FROM t; 1 row in set (0.01 sec) ``` -システムテーブル`TIDB_PK_TYPE`の列`information_schema.tables`をクエリして、結果が`CLUSTERED`か`NONCLUSTERED`かを確認することもできます。例: +システムテーブル`information_schema.tables`の`TIDB_PK_TYPE`列をクエリして、結果が`CLUSTERED`か`NONCLUSTERED`かを確認することもできます。例: ```sql mysql> SELECT TIDB_PK_TYPE FROM information_schema.tables WHERE table_schema = 'test' AND table_name = 't'; diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 9f310e2c77ade..8958e87ac92a4 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -167,7 +167,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - TiDBサーバーのステータスレポートポート - デフォルト: `"10080"` -- このポートはサーバー内部データを取得するために使用されます。データには[Prometheusメトリクス](https://prometheus.io/)と[専門家](https://golang.org/pkg/net/http/pprof/)含まれます。 +- このポートはサーバー内部データを取得するために使用されます。データには[Prometheusメトリクス](https://prometheus.io/)と[pprof](https://golang.org/pkg/net/http/pprof/)が含まれます。 - Prometheus メトリックには`"http://host:status_port/metrics"`でアクセスできます。 - pprof データには`"http://host:status_port/debug/pprof"`でアクセスできます。 diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index d90321ec732aa..83e33102a3c10 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -53,7 +53,7 @@ TiKV は、コマンドラインパラメータに対していくつかの読み - このフラグを使用すると、使用可能な構成値が`FORMAT`に従ってリストされ、終了します。 - `FORMAT`の値オプション: `json` 。現在、JSON 形式のみがサポートされています。 -- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。1または`--config` `-C`されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 +- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。`-C`または`--config`が指定されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 ```json { diff --git a/comment-syntax.md b/comment-syntax.md index 272b579ae27ac..1d66766d20461 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -109,7 +109,7 @@ MySQLでは、コメントにサーバーのバージョン番号（例： `/*!5 TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント構文) があり、次の 2 種類に分けられます。 - `/*T! Specific code */` : この構文は TiDB によってのみ解析および実行され、他のデータベースでは無視されます。 -- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。10 `AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。/* **`/*T![`文字内にスペースを入れないでください**。 +- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。`AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。**`/*T![`文字内にスペースを入れないでください**。 ## オプティマイザコメント構文 {#optimizer-comment-syntax} diff --git a/configure-memory-usage.md b/configure-memory-usage.md index dd668d971ad37..a82682b5f43b6 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -50,7 +50,7 @@ SET GLOBAL tidb_server_memory_limit = "32GB"; > > - TiDBは起動プロセス中に[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)制限が確実に適用されるとは保証しません。オペレーティングシステムの空きメモリが不足している場合、TiDBは依然としてOOMが発生する可能性があります。TiDBインスタンスに十分な空きメモリがあることを確認する必要があります。 > - メモリ制御の過程で、TiDB の合計メモリ使用量が`tidb_server_memory_limit`で設定された制限をわずかに超える場合があります。 -> - バージョン6.5.0以降、設定項目`server-memory-quota`非推奨となりました。互換性を確保するため、クラスターをバージョン6.5.0以降にアップグレードすると、 `tidb_server_memory_limit` `server-memory-quota`の値を継承します。アップグレード前に`server-memory-quota`を設定していない場合は、デフォルト値`tidb_server_memory_limit` （ `80%`が使用されます。 +> - バージョン6.5.0以降、設定項目`server-memory-quota`は非推奨となりました。互換性を確保するため、クラスターをバージョン6.5.0以降にアップグレードすると、 `tidb_server_memory_limit`は`server-memory-quota`の値を継承します。アップグレード前に`server-memory-quota`を設定していない場合は、`tidb_server_memory_limit`のデフォルト値（`80%`）が使用されます。 tidb-server インスタンスのメモリ使用量が総メモリの一定割合（割合はシステム変数[`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)によって制御されます）に達すると、tidb-server はメモリ負荷を軽減するためにGolang GC をトリガーしようとします。インスタンスメモリがしきい値付近で変動することで頻繁な GC が発生し、パフォーマンスに問題が生じるのを防ぐため、この GC 方式では GC は最大で 1 分に 1 回しかトリガーされません。 @@ -94,7 +94,7 @@ tidb-server インスタンスのメモリ使用量がメモリしきい値 (デ 次の例では、アラームをトリガーするメモリを大量に消費する SQL ステートメントを構築します。 -1. セット`tidb_memory_usage_alarm_ratio` ～ `0.85` : +1. `tidb_memory_usage_alarm_ratio`を`0.85`に設定します : ```sql SET GLOBAL tidb_memory_usage_alarm_ratio = 0.85; @@ -127,7 +127,7 @@ TiDBが使用するトランザクションモデルでは、トランザクシ ### フロー制御 {#flow-control} -- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子はデータ読み取りに使用できる最大スレッド数を使用します。1 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)超えると、データ読み取り演算子は1つのスレッドを停止します。 +- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子は[`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)で許可される最大スレッド数を使用してデータを読み取ります。単一のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データ読み取り演算子は1つのスレッドを停止します。 - このフロー制御動作は、システム変数[`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action)によって制御されます。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index 0432d64720893..780367e6e6fed 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -100,8 +100,8 @@ PD は、 `max-replicas` 、 `location-labels` 、および`isolation-level`構 > **Note:** > -> - 配置ルールが有効で複数のルールが存在する場合、以前に設定されたルール`max-replicas` 、 `location-labels` 、および`isolation-level`適用されなくなります。レプリカポリシーを調整するには、配置ルールに関連するインターフェースを使用してください。 -> - 配置ルールが有効になっていて、デフォルト ルールが 1 つだけ存在する場合、 `max-replicas` 、または`isolation-level` `location-labels`が変更されると、TiDB はこのデフォルト ルールを自動的に更新します。 +> - 配置ルールが有効で複数のルールが存在する場合、以前に設定されたルール`max-replicas` 、 `location-labels` 、および`isolation-level`は適用されなくなります。レプリカポリシーを調整するには、配置ルールに関連するインターフェースを使用してください。 +> - 配置ルールが有効になっていて、デフォルト ルールが 1 つだけ存在する場合、 `max-replicas` 、 `location-labels` 、または`isolation-level`が変更されると、TiDB はこのデフォルト ルールを自動的に更新します。 ### 配置ルールを無効にする {#disable-placement-rules} @@ -279,7 +279,7 @@ pd-ctl config placement-rules rule-bundle save --in="rules.json" ### tidb-ctlを使用してテーブル関連のキー範囲を照会する {#use-tidb-ctl-to-query-the-table-related-key-range} -メタデータまたは特定のテーブルに特別な設定が必要な場合は、「 [`keyrange`コマンド](https://github.com/pingcap/tidb-ctl/blob/master/doc/tidb-ctl_keyrange.md) in [tidb-ctl](https://github.com/pingcap/tidb-ctl)を実行して関連キーをクエリできます。コマンドの末尾に`--encode`を追加することを忘れないでください。 +メタデータまたは特定のテーブルに特別な設定が必要な場合は、[tidb-ctl](https://github.com/pingcap/tidb-ctl)の[`keyrange`コマンド](https://github.com/pingcap/tidb-ctl/blob/master/doc/tidb-ctl_keyrange.md)を実行して関連キーをクエリできます。コマンドの末尾に`--encode`を追加することを忘れないでください。 ```bash tidb-ctl keyrange --database test --table ttt --encode @@ -308,7 +308,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ 1: 通常のテーブルに 3 つのレプリカを使用し、メタデータに 5 つのレプリカを使用してクラスタの耐障害性を向上させる {#scenario-1-use-three-replicas-for-normal-tables-and-five-replicas-for-the-metadata-to-improve-cluster-disaster-tolerance} -キーの範囲をメタデータの範囲に制限するルールを追加し、値を`count`から`5`に設定するだけです。このルールの例を以下に示します。 +キーの範囲をメタデータの範囲に制限するルールを追加し、`count`の値を`5`に設定するだけです。このルールの例を以下に示します。 ```json { @@ -326,7 +326,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ2: 3つのデータセンターに5つのレプリカを2:2:1の割合で配置し、Leaderは3番目のデータセンターに配置しない {#scenario-2-place-five-replicas-in-three-data-centers-in-the-proportion-of-2-2-1-and-the-leader-should-not-be-in-the-third-data-center} -3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、レプリカを対応するデータセンター`label_constraints`から 8 に制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 +3つのルールを作成します。レプリカ数をそれぞれ`2` 、 `2` 、 `1`に設定します。各ルールで、 `label_constraints`によってレプリカを対応するデータセンターに制限します。さらに、Leaderを必要としないデータセンターについては、 `role`を`follower`に変更します。 ```json [ @@ -371,7 +371,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ3: テーブルに2つのTiFlashレプリカを追加する {#scenario-3-add-two-tiflash-replicas-for-a-table} -テーブルの行キーに別のルールを追加し、 `count`から`2`の範囲で制限します。 `label_constraints`を使用することで、レプリカが`engine = tiflash`のノードに生成されるようにします。ここで別途`group_id`を使用するのは、このルールがシステム内の他のソースのルールと重複したり衝突したりしないようにするためです。 +テーブルの行キーに別のルールを追加し、 `count`を`2`に制限します。 `label_constraints`を使用することで、レプリカが`engine = tiflash`のノードに生成されるようにします。ここで別途`group_id`を使用するのは、このルールがシステム内の他のソースのルールと重複したり衝突したりしないようにするためです。 ```json { @@ -410,7 +410,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) ### シナリオ5: SSDディスクを搭載したノードにテーブルを移行する {#scenario-5-migrate-a-table-to-the-nodes-with-ssd-disks} -シナリオ3とは異なり、このシナリオは既存の設定に基づいて新しいレプリカを追加するのではなく、データ範囲の他の設定を強制的に上書きします。そのため、ルールグループ設定で、十分な大きさの`index`値を指定し、既存のルールを上書きするには`override` ～ `true`を設定する必要があります。 +シナリオ3とは異なり、このシナリオは既存の設定に基づいて新しいレプリカを追加するのではなく、データ範囲の他の設定を強制的に上書きします。そのため、ルールグループ設定で、十分な大きさの`index`値を指定し、既存のルールを上書きするには`override`を`true`に設定する必要があります。 ルール: diff --git a/configure-time-zone.md b/configure-time-zone.md index d31e29c7620f3..e0345bb40c2cc 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -1,11 +1,11 @@ --- title: Time Zone Support -summary: TiDBのタイムゾーン設定は、time_zone`システム変数によって制御されます。この変数はセッションレベルまたはグローバルレベルで設定できます。`TIMESTAMP`データ型の表示値はタイムゾーン設定の影響を受けますが、`DATETIME`、`DATE`、`TIME`データ型は影響を受けません。データ移行を行う際は、プライマリデータベースとセカンダリデータベースのタイムゾーン設定が一致しているかどうかを特に注意する必要があります。 +summary: TiDBのタイムゾーン設定は、`time_zone`システム変数によって制御されます。この変数はセッションレベルまたはグローバルレベルで設定できます。`TIMESTAMP`データ型の表示値はタイムゾーン設定の影響を受けますが、`DATETIME`、`DATE`、`TIME`データ型は影響を受けません。データ移行を行う際は、プライマリデータベースとセカンダリデータベースのタイムゾーン設定が一致しているかどうかを特に注意する必要があります。 --- # タイムゾーンのサポート {#time-zone-support} -TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables.md#time_zone)によって決定されます。セッションレベルまたはグローバルレベルで設定できます。デフォルト値は`time_zone`で、 `SYSTEM`です`SYSTEM`に対応する実際のタイムゾーンは、TiDBクラスタのブートストラップが初期化される際に設定されます。詳細なロジックは次のとおりです。 +TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables.md#time_zone)によって決定されます。セッションレベルまたはグローバルレベルで設定できます。`time_zone`のデフォルト値は`SYSTEM`です。`SYSTEM`に対応する実際のタイムゾーンは、TiDBクラスタのブートストラップが初期化される際に設定されます。詳細なロジックは次のとおりです。 1. TiDB は`TZ`環境変数の使用を優先します。 2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイム ゾーンを読み取ります。 @@ -24,7 +24,7 @@ SELECT @@global.time_zone, @@session.time_zone, @@global.system_time_zone; TiDB では、 `time_zone`システム変数の値は次のいずれかの形式で設定できます。 - `SYSTEM` (デフォルト値) は、タイム ゾーンがシステムのタイム ゾーンと同じであることを示します。 -- UTC オフセット`'+10:00'`または`'-6:00'`など)。 +- UTC オフセット（`'+10:00'`または`'-6:00'`など）。 - `'Europe/Helsinki'` 、 `'US/Eastern'` 、 `'MET'`などの名前付きタイムゾーン。 ニーズに応じて、次のように TiDB のタイムゾーンをグローバル レベルまたはセッション レベルで設定できます。 diff --git a/constraints.md b/constraints.md index 140d7b004c47a..7909bca5e2b57 100644 --- a/constraints.md +++ b/constraints.md @@ -315,7 +315,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); ERROR 8147 (23000): transaction aborted because lazy uniqueness check is enabled and an error occurred: [kv:1062]Duplicate entry 'bill' for key 'users.username' -- この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`番目のエラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。 +- この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`エラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。 ## 主キー {#primary-key} diff --git a/coprocessor-cache.md b/coprocessor-cache.md index 6f337fd979f87..acbf45ce56c0e 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -68,7 +68,7 @@ EXPLAIN ANALYZE SELECT * FROM t USE INDEX(a); 3 rows in set (0.62 sec) ``` -実行結果の列`execution info`は、コプロセッサーキャッシュのヒット率を示す「 `copr_cache_hit_ratio`という情報が表示されます。上記の例の「 `0.75`は、ヒット率が約75%であることを意味します。 +実行結果の列`execution info`は、コプロセッサーキャッシュのヒット率を示す`copr_cache_hit_ratio`という情報が表示されます。上記の例の`0.75`は、ヒット率が約75%であることを意味します。 diff --git a/daily-check.md b/daily-check.md index 80be291715c06..c0973713d7083 100644 --- a/daily-check.md +++ b/daily-check.md @@ -18,7 +18,7 @@ TiDB Dashboardは、TiDBデータベースの運用と保守を簡素化しま ![Instance panel](/media/instance-status-panel.png) - **ステータス**：このインジケーターは、ステータスが正常かどうかを確認するために使用されます。オンラインノードの場合は、このインジケーターは無視できます。 -- **稼働時間**：重要な指標です。2の`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 +- **稼働時間**：重要な指標です。`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 - **バージョン**、**デプロイメントディレクトリ**、 **Gitハッシュ**：これらの指標を確認することで、バージョンやデプロイメントディレクトリの不整合や誤りを回避できます。 ### ホストパネル {#host-panel} diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index 8512682b93462..b5aa4f86b5e04 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -15,7 +15,7 @@ summary: TiDB Dashboardの診断レポートは、異なる時間範囲でのシ ![QPS example](/media/dashboard/dashboard-diagnostics-usage1.png) -`go-ycsb` `2020-03-10 13:24:30`テストの結果は上の画像に示されています。3でQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 +`go-ycsb`圧力テストの結果は上の画像に示されています。`2020-03-10 13:24:30`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 @@ -65,7 +65,7 @@ digest | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8 ![QPS results](/media/dashboard/dashboard-diagnostics-usage3.png) -もう`go-ycsb`圧力テストの結果を上の`2020-03-08 01:46:30`に示します。3でQPSが急激に低下し始め、回復していないことがわかります。 +もう1つの`go-ycsb`圧力テストの結果を上の画像に示します。`2020-03-08 01:46:30`にQPSが急激に低下し始め、回復していないことがわかります。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 @@ -96,7 +96,7 @@ MESSAGE | [expensivequery.go:167] [expensive_query] [cost_time=60.085949605s] [ ![QPS results](/media/dashboard/dashboard-diagnostics-usage5.png) -`go-ycsb` `2020-05-22 22:14:00`テストの結果は上の画像に示されています。3でQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 +`go-ycsb`圧力テストの結果は上の画像に示されています。`2020-05-22 22:14:00`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 次の 2 つの時間範囲でシステムを比較するレポートを生成します。 diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 630f21fce608d..cc97c894f2653 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -64,7 +64,7 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。 -`tidb_execute` `tidb_cop`番目のメトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`番目の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。10 `cop`のリクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 +`tidb_execute`には`tidb_cop`メトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。`cop`リクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`の実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 > **Note:** > diff --git a/data-type-json.md b/data-type-json.md index 036e640ef4daf..1ef74d05ca1ec 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -5,7 +5,7 @@ summary: TiDB の JSON データ型について学習します。 # JSONデータ型 {#json-data-type} -TiDBは、半構造化データの保存に便利な`JSON` （JavaScript Object Notation）データ型をサポートしています`JSON`データ型は、文字列列に`JSON`形式の文字列を保存する場合と比べて、以下の利点があります。 +TiDBは、半構造化データの保存に便利な`JSON` （JavaScript Object Notation）データ型をサポートしています。`JSON`データ型は、文字列列に`JSON`形式の文字列を保存する場合と比べて、以下の利点があります。 - シリアル化にはバイナリ形式を使用します。内部形式により、 `JSON`ドキュメント要素への高速な読み取りアクセスが可能になります。 - `JSON`列に保存されたJSONドキュメントを自動検証します。有効なドキュメントのみを保存できます。 @@ -70,7 +70,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` 1 row in set (0.01 sec) ``` - 詳細については、第[＃37443](https://github.com/pingcap/tidb/issues/37443)を参照してください。 + 詳細については、issue [#37443](https://github.com/pingcap/tidb/issues/37443)を参照してください。 - データ型を`ENUM`または`SET`から`JSON`に変換する際、TiDB はデータ形式の正確性をチェックします。例えば、TiDB で以下の SQL 文を実行するとエラーが返されます。 @@ -81,7 +81,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` ERROR 3140 (22032): Invalid JSON text: The document root must not be followed by other values. ``` - 詳細については、第[＃9999](https://github.com/pingcap/tidb/issues/9999)を参照してください。 + 詳細については、issue [#9999](https://github.com/pingcap/tidb/issues/9999)を参照してください。 - TiDB では、 `ORDER BY`を使用して JSON 配列または JSON オブジェクトをソートできます。 @@ -111,7 +111,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` 2 rows in set (0.00 sec) ``` - 詳細については、第[＃37506](https://github.com/pingcap/tidb/issues/37506)を参照してください。 + 詳細については、issue [#37506](https://github.com/pingcap/tidb/issues/37506)を参照してください。 - JSON 列にデータを挿入すると、TiDB は暗黙的にデータの値を`JSON`型に変換します。 diff --git a/data-type-string.md b/data-type-string.md index d5570cc7ccd80..70a2043bd5524 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -11,7 +11,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ### CHAR型 {#code-char-code-type} -`CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。2とは異なり、 `VARCHAR`列にデータを挿入する場合、末尾のスペース`CHAR`切り捨てられます。 +`CHAR`は固定長文字列です。Mは列の長さを文字数（バイト数ではありません）で表します。Mの範囲は0から255です。`VARCHAR`型とは異なり、 `CHAR`列にデータを挿入する場合、末尾のスペースは切り捨てられます。 ```sql [NATIONAL] CHAR[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] @@ -192,7 +192,7 @@ SET('1', '2') NOT NULL '2' '1,2' -TiDBでは、 `SET`型の値は内部的に`Int64`に変換されます。各要素の存在は、0または1の2進数で表されます`SET('a','b','c','d')`と指定された列の場合、各要素は以下の10進数と2進数の値を持ちます。 +TiDBでは、 `SET`型の値は内部的に`Int64`に変換されます。各要素の存在は、0または1の2進数で表されます。`SET('a','b','c','d')`と指定された列の場合、各要素は以下の10進数と2進数の値を持ちます。 | メンバー | 小数値 | バイナリ値 | | ----------- | --- | ----- | diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index ec5ba8df7dbdb..2f68edcc824c7 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -176,7 +176,7 @@ JDBCでは通常、以下の2つの処理方法が使用されます。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`から`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 -2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。3 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) `ON`設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 +2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)が`ON`に設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 システム変数[`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) `ON`に設定されている場合、TiDB はクライアントがデータを取得するときにのみデータの一部を読み取ろうとします。これによりメモリ使用量が削減されます。詳細および制限事項については、 [`tidb_enable_lazy_cursor_fetch`システム変数の完全な説明](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)を参照してください。 @@ -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-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index 12b561cbc6bb5..6ff35cb430c23 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -131,7 +131,7 @@ DELETE FROM t; ### インデックスのベストプラクティスを追加する {#add-index-best-practices} -TiDBはオンラインのインデックス追加操作をサポートしています。1 [インデックスを追加](/sql-statements/sql-statement-add-index.md)または[インデックスの作成](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 +TiDBはオンラインのインデックス追加操作をサポートしています。[インデックスを追加](/sql-statements/sql-statement-add-index.md)または[インデックスの作成](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index a11cda23fd261..322c617feb909 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -58,7 +58,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; +---------------------+------------+-----------+---------------+-----------------------------------------+ ``` -実行プランの`TableFullScan_5`からわかるように、TiDBは`books`番目のテーブルに対してフルテーブルスキャンを実行し、各行について`title`条件を満たすかどうかを確認します。9の`estRows` `TableFullScan_5`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 +実行プランの`TableFullScan_5`からわかるように、TiDBは`books`テーブルに対してフルテーブルスキャンを実行し、各行について`title`が条件を満たすかどうかを確認します。`TableFullScan_5`の`estRows`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 `EXPLAIN`の使用方法の詳細については、 [`EXPLAIN`ウォークスルー](/explain-walkthrough.md)を参照してください。 diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 7465c71ea4044..48b96b7569ed7 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 de135a6850c87..808ee6eddfc6e 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 c6cf0c9bc128f..898b01e45fec9 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-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 36a7e9ba41dc4..6478eaaf5a76f 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -61,7 +61,7 @@ BEGIN; START TRANSACTION; ``` -TiDBのデフォルトのトランザクションモードは悲観的です。1 [楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)明示的に指定することもできます。 +TiDBのデフォルトのトランザクションモードは悲観的です。[楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)を明示的に指定することもできます。 ```sql BEGIN OPTIMISTIC; diff --git a/develop/dev-guide-unique-serial-number-generation.md b/develop/dev-guide-unique-serial-number-generation.md index ce4828bf50b32..857e07d4a156c 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-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index 40bfe15ec8bae..343a843aad345 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -48,7 +48,7 @@ ORDER BY 3 rows in set (0.00 sec) ``` -`a` . `class`および`a` . `stuname`フィールドは`GROUP BY`文で指定されており、選択された列は`a` . `class` 、 `a` . `stuname` 、 `b` . `courscore`です。23 `GROUP BY`条件に含まれない唯一の列である`b` . `courscore`も、 `max()`関数を使用して一意の値で指定されています。このSQL文を曖昧さなく満たす結果は***1つだけ***あり、これを`FULL GROUP BY`構文と呼びます。 +`a` . `class`および`a` . `stuname`フィールドは`GROUP BY`文で指定されており、選択された列は`a` . `class` 、 `a` . `stuname` 、 `b` . `courscore`です。`GROUP BY`条件に含まれない唯一の列である`b` . `courscore`も、 `max()`関数を使用して一意の値で指定されています。このSQL文を曖昧さなく満たす結果は***1つだけ***あり、これを`FULL GROUP BY`構文と呼びます。 反例として、構文`NON-FULL GROUP BY`があります。例えば、この2つのテーブルに次のSQLクエリを記述します (delete `a` . `stuname` in `GROUP BY` )。 diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 1c2c467f26b87..39173c348a192 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 5103239deffe8..09a658228ca8f 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/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index 24a3dfc09f48b..4bd83e0d3f2ea 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -249,7 +249,7 @@ hikari: パラメータの説明は以下の通りです。詳細については、 [HikariCPの公式ドキュメント](https://github.com/brettwooldridge/HikariCP/blob/dev/README.md)を参照してください。 -- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、を参照[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)ください。 +- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 - `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 - `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 diff --git a/dm/dm-block-allow-table-lists.md b/dm/dm-block-allow-table-lists.md index 0f60f1fa9824e..06e27956a6f6b 100644 --- a/dm/dm-block-allow-table-lists.md +++ b/dm/dm-block-allow-table-lists.md @@ -36,7 +36,7 @@ block-allow-list: # Use black-white-list if the DM version is earlie シンプルなシナリオでは、スキーマとテーブルのマッチングにワイルドカードを使用することをお勧めします。ただし、以下のバージョンの違いにご注意ください。 -- `*` `[]`含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1 `?`だけ使用でき、末尾になければなりません。例えば、 `tbl-name: "t*"`の場合、 `"t*"` `t`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)参照してください。 +- `*` 、 `?` 、 `[]`を含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1つだけ使用でき、末尾になければなりません。例えば、 `tbl-name: "t*"`の場合、 `"t*"`は`t`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)を参照してください。 - 正規表現は`~`文字で始まる必要があります。 @@ -44,8 +44,8 @@ block-allow-list: # Use black-white-list if the DM version is earlie - `do-dbs` : MySQL の[`replicate-do-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-db)と同様に、移行するスキーマのリストを許可します。 - `ignore-dbs` : 移行するスキーマのブロック リスト (MySQL の[`replicate-ignore-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-db)に類似)。 -- `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。4と`tbl-name` `db-name`を指定する必要があります。 -- `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。4と`tbl-name` `db-name`を指定する必要があります。 +- `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 +- `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 上記のパラメータの値が`~`文字で始まる場合、その値の以降の文字は[正規表現](https://golang.org/pkg/regexp/syntax/#hdr-syntax)として扱われます。このパラメータは、スキーマ名またはテーブル名を一致させるために使用できます。 diff --git a/dm/dm-command-line-flags.md b/dm/dm-command-line-flags.md index bb1411fc9d53e..96c7bf97959f1 100644 --- a/dm/dm-command-line-flags.md +++ b/dm/dm-command-line-flags.md @@ -13,13 +13,13 @@ summary: DM のコマンドライン フラグについて学習します。 - クライアントのリクエストを受信するために使用されるDMマスターの外部アドレス - デフォルト値は`"{master-addr}"`です -- オプションフラグ。1の形式をとることができます`"domain-name:port"` +- オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--advertise-peer-urls` {#advertise-peer-urls} - DMマスターノード間の通信用の外部アドレス - デフォルト値は`"{peer-urls}"`です -- オプションフラグ。1の形式をとることができます`"http(s)://domain-name:port"` +- オプションフラグ。`"http(s)://domain-name:port"`の形式をとることができます。 ### `--config` {#config} @@ -87,7 +87,7 @@ summary: DM のコマンドライン フラグについて学習します。 - クライアントのリクエストを受信するために使用されるDMワーカーの外部アドレス - デフォルト値は`"{worker-addr}"`です -- オプションフラグ。1の形式をとることができます`"domain-name:port"` +- オプションフラグ。`"domain-name:port"`の形式をとることができます。 ### `--config` {#config} diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index c130f9f79aa8f..5751a1e2fceb3 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -29,6 +29,6 @@ summary: このドキュメントでは、データ移行構成ファイルの | コンセプト | 説明 | コンフィグレーションファイル | | :---------- | :-------------------------------------------------------------------------- | :--------------------------------------------------------- | -| `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。1の最大長は`source-id`です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | +| `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。`source-id`の最大長は32です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | | DMマスターID | DMマスターを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | | DMワーカーID | DMワーカーを一意に表す（ `dm-worker.toml`の`worker-addr`のパラメータによって） | `worker-addr` / `dm-worker.toml` | diff --git a/dm/dm-faq.md b/dm/dm-faq.md index cfc64b813959a..322ccc26847ca 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -18,7 +18,7 @@ Alibaba Cloud RDS の主キーのないアップストリーム テーブルの - **Alibaba Cloud RDS**では、主キーのないアップストリーム テーブルの場合、そのbinlog には非表示の主キー列がまだ含まれており、元のテーブル構造と一致していません。 - **HUAWEI Cloud RDS**では、 binlogファイルの直接読み取りはサポートされていません。詳細については、 [HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?](https://support.huaweicloud.com/en-us/rds_faq/rds_faq_0210.html)を参照してください。 -## タスク構成のブロックおよび許可リストの正規表現は、 non-capturing (?!) ? {#does-the-regular-expression-of-the-block-and-allow-list-in-the-task-configuration-support-code-non-capturing-code} +## タスク構成のブロックおよび許可リストの正規表現は、 non-capturing (?!) ? {#does-the-regular-expression-of-the-block-and-allow-list-in-the-task-configuration-support-non-capturing-} 現在、DMはこれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。Golangでサポートされている正規表現については、 [re2構文](https://github.com/google/re2/wiki/Syntax)を参照してください。 @@ -51,7 +51,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを - タスク設定ファイルで新しいタスク名を指定します。次に、 `start-task {task-config-file}`を実行します。 - `start-task --remove-meta {task-config-file}`を実行します。 -## online-ddl: trueを設定した後、gh-ost テーブルに関連する DDL 操作によって返されたエラーをどのように処理しますか? {#how-to-handle-the-error-returned-by-the-ddl-operation-related-to-the-gh-ost-table-after-code-online-ddl-true-code-is-set} +## online-ddl: trueを設定した後、gh-ost テーブルに関連する DDL 操作によって返されたエラーをどのように処理しますか? {#how-to-handle-the-error-returned-by-the-ddl-operation-related-to-the-gh-ost-table-after-online-ddl-true-is-set} [unit=Sync] ["error information"="{\"msg\":\"[code=36046:class=sync-unit:scope=internal:level=high] online ddls on ghost table `xxx`.`_xxxx_gho`\\ngithub.com/pingcap/tiflow/pkg/terror.(*Error).Generate ...... @@ -84,17 +84,17 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを > > 既存のデータ移行タスクにテーブルを追加するのは複雑なため、必要な場合にのみこの操作を実行することをお勧めします。 -### Dump段階 {#in-the-code-dump-code-stage} +### Dump段階 {#in-the-dump-stage} MySQLはエクスポート時にスナップショットを指定できないため、エクスポート中にデータ移行タスクを更新し、その後再起動してチェックポイントからエクスポートを再開することができません。そのため、第`Dump`ステージで移行が必要なテーブルを動的に追加することはできません。 移行のためにテーブルを追加する必要がある場合は、新しい構成ファイルを使用してタスクを直接再起動することをお勧めします。 -### Loadステージ {#in-the-code-load-code-stage} +### Loadステージ {#in-the-load-stage} エクスポート中、複数のデータ移行タスクは通常、異なるbinlogの位置を持ちます。第`Load`ステージでタスクをマージすると、binlogの位置について合意が得られない可能性があります。そのため、第`Load`ステージでデータ移行タスクにテーブルを追加することは推奨されません。 -### Sync段階では {#in-the-code-sync-code-stage} +### Sync段階では {#in-the-sync-stage} データ移行タスクが第`Sync`ステージにあるときに、設定ファイルにテーブルを追加してタスクを再開すると、DMは新しく追加されたテーブルに対して完全なエクスポートとインポートを再実行しません。代わりに、DMは前回のチェックポイントから増分レプリケーションを継続します。 @@ -118,24 +118,24 @@ MySQLはエクスポート時にスナップショットを指定できないた 5. `query-status`までタスクの状態を観察します。`syncerBinlog`が `checkpoint-T`と`checkpoint-S`のうち大きい方の値を超えた場合、 `safe-mode`を元の値に戻し、タスクを再開します。この例では`(mysql-bin.000100, 1234)`です。 -## packet for query is too large. Try adjusting the 'max_allowed_packet' variable ？ {#how-to-handle-the-error-code-packet-for-query-is-too-large-try-adjusting-the-max-allowed-packet-variable-code-that-occurs-during-the-full-import} +## packet for query is too large. Try adjusting the 'max_allowed_packet' variable ？ {#how-to-handle-the-error-packet-for-query-is-too-large-try-adjusting-the-max_allowed_packet-variable-that-occurs-during-the-full-import} 以下のパラメータをデフォルトの 67108864 (64M) より大きい値に設定します。 - TiDBサーバーのグローバル変数: `max_allowed_packet` 。 - タスク設定ファイル内の設定項目： `target-database.max-allowed-packet` 。詳細は[DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 -## DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラーError 1054: Unknown column 'binlog_gtid' in 'field list'を処理する方法を教えてください。 {#how-to-handle-the-error-code-error-1054-unknown-column-binlog-gtid-in-field-list-code-that-occurs-when-existing-dm-migration-tasks-of-an-dm-1-0-cluster-are-running-on-a-dm-2-0-or-newer-cluster} +## DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラーError 1054: Unknown column 'binlog_gtid' in 'field list'を処理する方法を教えてください。 {#how-to-handle-the-error-error-1054-unknown-column-binlog_gtid-in-field-list-that-occurs-when-existing-dm-migration-tasks-of-an-dm-10-cluster-are-running-on-a-dm-20-or-newer-cluster} DM v2.0 以降、増分データレプリケーションを続行するために DM 1.0 クラスターのタスク構成ファイルで`start-task`コマンドを直接実行すると、エラー`Error 1054: Unknown column 'binlog_gtid' in 'field list'`が発生します。 このエラーは[DM 1.0 クラスターの DM 移行タスクを DM 2.0 クラスターに手動でインポートする](/dm/manually-upgrade-dm-1.0-to-2.0.md)で処理できます。 -## TiUP がDM の一部のバージョン (たとえば、v2.0.0-hotfix) の展開に失敗するのはなぜですか? {#why-does-tiup-fail-to-deploy-some-versions-of-dm-for-example-v2-0-0-hotfix} +## TiUP がDM の一部のバージョン (たとえば、v2.0.0-hotfix) の展開に失敗するのはなぜですか? {#why-does-tiup-fail-to-deploy-some-versions-of-dm-for-example-v200-hotfix} `tiup list dm-master`コマンドを使用すると、 TiUP がデプロイをサポートしている DM バージョンを表示できます。このコマンドで表示されない DM バージョンはTiUP管理されません。 -## DM がデータを複製しているときに発生するエラーparse mydumper metadata error: EOFを処理するにはどうすればよいですか? {#how-to-handle-the-error-code-parse-mydumper-metadata-error-eof-code-that-occurs-when-dm-is-replicating-data} +## DM がデータを複製しているときに発生するエラーparse mydumper metadata error: EOFを処理するにはどうすればよいですか? {#how-to-handle-the-error-parse-mydumper-metadata-error-eof-that-occurs-when-dm-is-replicating-data} このエラーをさらに分析するには、エラーメッセージとログファイルを確認してください。原因としては、権限不足のためにダンプユニットが正しいメタデータファイルを生成していないことが考えられます。 @@ -146,15 +146,15 @@ DM v2.0 以降、増分データレプリケーションを続行するために - `block-allow-list`の下にある上流のデータベースとテーブルの名前を設定する必要があります。`do-tables`の前に「~」を追加すると、正規表現を使用して名前を一致させることができます。 - `table-route` 、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_parttern_[0-63]` `table_parttern_0`から`table_pattern_6`までの 7 つのテーブルのみに一致します。 -## DM がアップストリームからレプリケートしていないのに、 replicate lagモニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-code-replicate-lag-code-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} +## DM がアップストリームからレプリケートしていないのに、 replicate lagモニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-replicate-lag-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} DM 1.0では、監視データを生成するには`enable-heartbeat`有効にする必要があります。DM 2.0以降のバージョンでは、この機能はサポートされていないため、監視メトリック`replicate lag`にはデータが存在しないことが想定されます。 -## DM がタスクを開始しているときに、 context deadline exceededを示すエラー メッセージのRawCauseでfail to initial unit Sync of subtaskエラーを処理する方法を教えてください。 {#how-to-handle-the-error-code-fail-to-initial-unit-sync-of-subtask-code-when-dm-is-starting-a-task-with-the-code-rawcause-code-in-the-error-message-showing-code-context-deadline-exceeded-code} +## DM がタスクを開始しているときに、 context deadline exceededを示すエラー メッセージのRawCauseでfail to initial unit Sync of subtaskエラーを処理する方法を教えてください。 {#how-to-handle-the-error-fail-to-initial-unit-sync-of-subtask-when-dm-is-starting-a-task-with-the-rawcause-in-the-error-message-showing-context-deadline-exceeded} これはDM 2.0.0バージョンの既知の問題であり、DM 2.0.1バージョンで修正される予定です。レプリケーションタスクで処理するテーブル数が多い場合に発生する可能性があります。TiUPを使用してDMをデプロイしている場合は、DMをナイトリーバージョンにアップグレードすることでこの問題を修正できます。または、GitHubの[DMのリリースページ](https://github.com/pingcap/tiflow/releases)から2.0.0-hotfixバージョンをダウンロードし、実行ファイルを手動で置き換えることもできます。 -## DM がデータを複製しているときにduplicate entryエラーを処理するにはどうすればよいでしょうか? {#how-to-handle-the-error-code-duplicate-entry-code-when-dm-is-replicating-data} +## DM がデータを複製しているときにduplicate entryエラーを処理するにはどうすればよいでしょうか? {#how-to-handle-the-error-duplicate-entry-when-dm-is-replicating-data} まず、以下の点を確認して確認する必要があります。 @@ -173,11 +173,11 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings `duplicate entry`エラーが発生した場合は、競合データを含むレコードのログ ファイルを確認する必要があります。 -## 一部の監視パネルにNo data pointと表示されるのはなぜですか? {#why-do-some-monitoring-panels-show-code-no-data-point-code} +## 一部の監視パネルにNo data pointと表示されるのはなぜですか? {#why-do-some-monitoring-panels-show-no-data-point} 一部のパネルにデータが表示されないのは正常です。例えば、エラーが報告されていない場合、DDLロックがない場合、またはリレーログ機能が有効になっていない場合、対応するパネルには`No data point`が表示されます。各パネルの詳細については、 [DM モニタリング メトリック](/dm/monitor-a-dm-cluster.md)を参照してください。 -## DM v1.0 では、タスクにエラーがある場合にコマンドsql-skip一部のステートメントをスキップできないのはなぜですか? {#in-dm-v1-0-why-does-the-command-code-sql-skip-code-fail-to-skip-some-statements-when-the-task-is-in-error} +## DM v1.0 では、タスクにエラーがある場合にコマンドsql-skip一部のステートメントをスキップできないのはなぜですか? {#in-dm-v10-why-does-the-command-sql-skip-fail-to-skip-some-statements-when-the-task-is-in-error} まず、 `sql-skip`を実行した後もbinlogの位置が進んでいるかどうかを確認する必要があります。進んでいる場合は、 `sql-skip`が有効になっていることを意味します。このエラーが繰り返し発生する理由は、アップストリームがサポートされていない複数の DDL 文を送信しているためです。`sql-skip -s `を使用して、これらの文に一致するパターンを設定できます。 @@ -189,13 +189,13 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings DM v6.0以降、 `sql-skip`と`handle-error`が`binlog`に置き換えられました。この問題を回避するには、代わりに`binlog`コマンドを使用してください。 -## DM がレプリケートされているときに、ダウンストリームにREPLACEステートメントが表示され続けるのはなぜですか? {#why-do-code-replace-code-statements-keep-appearing-in-the-downstream-when-dm-is-replicating} +## DM がレプリケートされているときに、ダウンストリームにREPLACEステートメントが表示され続けるのはなぜですか? {#why-do-replace-statements-keep-appearing-in-the-downstream-when-dm-is-replicating} タスクに対して[セーフモード](/dm/dm-glossary.md#safe-mode)が自動的に有効になっているかどうかを確認する必要があります。エラー発生後にタスクが自動的に再開される場合、または高可用性スケジュールが設定されている場合は、タスクの開始または再開から1分以内であるため、セーフモードが有効になっています。 DM-worker のログファイルを確認し、 `change count`含む行を探してください。その行の`new count` 0 でない場合、セーフモードが有効になっています。セーフモードが有効になっている理由を確認するには、セーフモードがいつ発生するか、またそれ以前にエラーが報告されているかどうかを確認してください。 -## DM v2.0 では、タスク中に DM が再起動すると、完全インポート タスクが失敗するのはなぜですか? {#in-dm-v2-0-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} +## DM v2.0 では、タスク中に DM が再起動すると、完全インポート タスクが失敗するのはなぜですか? {#in-dm-v20-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} DM v2.0.1 以前のバージョンでは、完全インポートが完了する前に DM が再起動すると、上流のデータソースと DM ワーカーノード間のバインディングが変更される可能性があります。例えば、ダンプユニットの中間データが DM ワーカーノード A にあるにもかかわらず、ロードユニットが DM ワーカーノード B で実行されている場合、操作が失敗する可能性があります。 @@ -218,7 +218,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する - `task-mode`を`incremental`に変更します。 - ダンプユニットが出力するメタデータファイルに記録されている位置に値`mysql-instance.meta.pos`を設定します。 -## 増分タスク中に再起動すると、DM がエラーERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.はなぜですか? {#why-does-dm-report-the-error-code-error-1236-hy000-the-slave-is-connecting-using-change-master-to-master-auto-position-1-but-the-master-has-purged-binary-logs-containing-gtids-that-the-slave-requires-code-if-it-restarts-during-an-incremental-task} +## 増分タスク中に再起動すると、DM がエラーERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.はなぜですか? {#why-does-dm-report-the-error-error-1236-hy000-the-slave-is-connecting-using-change-master-to-master_auto_position--1-but-the-master-has-purged-binary-logs-containing-gtids-that-the-slave-requires-if-it-restarts-during-an-incremental-task} このエラーは、ダンプ ユニットによって出力されたメタデータ ファイルに記録されたアップストリームbinlogの位置が、完全な移行中に消去されたことを示します。 @@ -229,7 +229,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 1. 移行タスクが完了する前に必要なbinlogファイルが誤って削除されるのを防ぐため、上流のMySQLデータベースの値を`expire_logs_days`に増やしてください。データ量が多い場合は、タスクを高速化するために、DumplingとTiDB Lightningを同時に使用することをお勧めします。 2. このタスクのリレー ログ機能を有効にすると、binlogの位置が消去されていても DM がリレー ログからデータを読み取ることができます。 -## クラスターがTiUP v1.3.0 または v1.3.1 を使用してデプロイされている場合、DM クラスターの Grafana ダッシュボードに「 failed to fetch dashboard表示されるのはなぜですか? {#why-does-the-grafana-dashboard-of-a-dm-cluster-display-code-failed-to-fetch-dashboard-code-if-the-cluster-is-deployed-using-tiup-v1-3-0-or-v1-3-1} +## クラスターがTiUP v1.3.0 または v1.3.1 を使用してデプロイされている場合、DM クラスターの Grafana ダッシュボードに「 failed to fetch dashboard表示されるのはなぜですか? {#why-does-the-grafana-dashboard-of-a-dm-cluster-display-failed-to-fetch-dashboard-if-the-cluster-is-deployed-using-tiup-v130-or-v131} これはTiUPの既知のバグで、 TiUP v1.3.2 で修正されています。この問題に対する解決策は以下の2つです。 @@ -243,7 +243,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 4. フォルダー`deploy/grafana-$port/bin/public` `grafana-v4.0.3-**.tar.gz`のフォルダー`public`に置き換えます。 5. `tiup dm restart $cluster_name -R grafana`を実行して Grafana サービスを再起動します。 -## DM v2.0 では、タスクでenable-relayとenable-gtid同時に有効になっている場合、コマンドquery-statusのクエリ結果に、Syncer チェックポイント GTID が連続していないと表示されるのはなぜですか? {#in-dm-v2-0-why-does-the-query-result-of-the-command-code-query-status-code-show-that-the-syncer-checkpoint-gtids-are-inconsecutive-if-the-task-has-code-enable-relay-code-and-code-enable-gtid-code-enabled-at-the-same-time} +## DM v2.0 では、タスクでenable-relayとenable-gtid同時に有効になっている場合、コマンドquery-statusのクエリ結果に、Syncer チェックポイント GTID が連続していないと表示されるのはなぜですか? {#in-dm-v20-why-does-the-query-result-of-the-command-query-status-show-that-the-syncer-checkpoint-gtids-are-inconsecutive-if-the-task-has-enable-relay-and-enable-gtid-enabled-at-the-same-time} これはDMの既知のバグで、DM v2.0.2で修正されています。このバグは、以下の2つの条件が同時に満たされた場合に発生します。 @@ -346,7 +346,7 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する 上記の 1 番目と 2 番目のソリューションで正常にレプリケートできるデータ ソース (上記の例の`mysql2`など) の場合は、増分タスクを設定するときに、 `subTaskStatus.sync`の`syncerBinlog`と`syncerBinlogGtid`情報を使用して関連する`mysql-instances.meta`構成します。 -## DM v2.0 では、 heartbeat機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v2-0-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-code-heartbeat-code-feature-enabled} +## DM v2.0 では、 heartbeat機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v20-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-heartbeat-feature-enabled} DM v2.0以降のバージョンでは、 `heartbeat`機能はデフォルトで無効になっています。タスク設定ファイルでこの機能を有効にすると、高可用性機能に支障をきたします。この問題を解決するには、タスク設定ファイルで`enable-heartbeat`を`false`に設定して`heartbeat`機能を無効にし、その後タスク設定ファイルをリロードしてください。DMは、以降のリリースで`heartbeat`機能を強制的に無効にします。 @@ -368,7 +368,7 @@ dmctl execute コマンドを使用すると、DM マスターへの接続に失 > > `proxy`に関連する環境変数には`http_proxy` 、 `https_proxy` 、 `no_proxy`があります。上記の手順を実行しても接続エラーが解決しない場合は、 `http_proxy`と`no_proxy`の設定パラメータが正しいかどうかを確認してください。 -## DM バージョン 2.0.2 から 2.0.6 で start-relay コマンドを実行したときに返されるエラーを処理するにはどうすればよいですか? {#how-to-handle-the-returned-error-when-executing-start-relay-command-for-dm-versions-from-2-0-2-to-2-0-6} +## DM バージョン 2.0.2 から 2.0.6 で start-relay コマンドを実行したときに返されるエラーを処理するにはどうすればよいですか? {#how-to-handle-the-returned-error-when-executing-start-relay-command-for-dm-versions-from-202-to-206} flush local meta, Rawcause: open relay-dir/xxx.000001/relay.metayyyy: no such file or directory @@ -386,6 +386,6 @@ dmctl execute コマンドを使用すると、DM マスターへの接続に失 - DM を v2.0.7 以降のバージョンにアップグレードします。 -## ロード ユニットがUnknown character setエラーを報告するのはなぜですか? {#why-does-the-load-unit-report-the-code-unknown-character-set-code-error} +## ロード ユニットがUnknown character setエラーを報告するのはなぜですか? {#why-does-the-load-unit-report-the-unknown-character-set-error} -TiDBはMySQLのすべての文字セットをサポートしていません。そのため、フルインポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、DMはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。 +TiDBはMySQLのすべての文字セットをサポートしているわけではありません。そのため、フルインポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、DMはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。 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/dm/dm-table-routing.md b/dm/dm-table-routing.md index 47d12abb39273..d7342e80230d0 100644 --- a/dm/dm-table-routing.md +++ b/dm/dm-table-routing.md @@ -40,7 +40,7 @@ routes: データベース名とテーブル名のマッチングには、正規表現とワイルドカードがサポートされています。シンプルなシナリオでは、スキーマとテーブルのマッチングにワイルドカードを使用することをお勧めします。ただし、以下の点にご注意ください。 -- `*` `[]`含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1 `?`だけ使用でき、末尾になければなりません。例えば、 `table-pattern: "t_*"`の場合、 `"t_*"` `t_`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)参照してください。 +- `*` 、 `?` 、 `[]`を含むワイルドカードがサポートされています。ワイルドカードマッチでは`*`記号は1つだけ使用でき、末尾になければなりません。例えば、 `table-pattern: "t_*"`の場合、 `"t_*"`は`t_`で始まるすべてのテーブルを表します。詳細は[ワイルドカードマッチング](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)を参照してください。 - `table-regexp` 、 `schema-regexp` 、 `source-regexp`正規表現のみをサポートし、 `~`記号で始まることはできません。 diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index a93fbe0991e4e..dbb752493a3b6 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -51,7 +51,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して 4. `t3`では、インスタンス 2 からのシャーディング DDL イベントが受信されます。 5. `t4`以降、同期ユニットはインスタンス2からの`schema V2`のDMLイベントも受信します。 -シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`schema V1`から`t2`への`t3`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 +シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`t2`から`t3`までの`schema V1`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 ## 原則 {#principles} diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index a8bcaab31b021..e2711cad645c7 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -82,7 +82,7 @@ shard-ddl-lock test ### `shard-ddl-lock unlock` {#shard-ddl-lock-unlock} -このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された`DM-master`ロックのロックを解除するように 1 に積極的に要求します。 +このコマンドは、所有者に DDL ステートメントを実行するよう要求し、所有者以外の他のすべての DM ワーカーに DDL ステートメントをスキップするよう要求し、 `DM-master`のロック情報を削除するなど、指定された DDL ロックを解除するように`DM-master`に積極的に要求します。 > **Note:** > @@ -153,7 +153,7 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` #### 手動ソリューション {#manual-solution} -アップストリームにインスタンス`MySQL-1` （ `mysql-replica-01` ）と`MySQL-2` （ `mysql-replica-02` ）の2つがあり、 `shard_table_1`に`MySQL-1` `shard_db_1`の`shard_table_2`つ、 `shard_db_2` `MySQL-2`テーブル`shard_db_2` `shard_table_1` 2 `shard_table` `shard_table_2` `shard_db`する必要`shard_db_1`あります。 +アップストリームにインスタンス`MySQL-1` （ `mysql-replica-01` ）と`MySQL-2` （ `mysql-replica-02` ）の2つがあり、 `MySQL-1`に`shard_db_1`の`shard_table_1`と`shard_db_1`の`shard_table_2`の2つのテーブル、 `MySQL-2`に`shard_db_2`の`shard_table_1`と`shard_db_2`の`shard_table_2`の2つのテーブルがあるとします。ここで、これら4つのテーブルをマージして、ダウンストリームTiDBの`shard_db`の`shard_table`テーブルに移行する必要があります。 初期のテーブル構造は次のとおりです。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 5ae683b5fa4e7..c9e2ac8f3ea66 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -371,7 +371,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー mysql --host 127.0.0.1 --port 4000 -u root --prompt 'tidb> ' ``` -3. 複製されたデータを確認します。1 [ステップ2](#step-2-prepare-a-source-database-optional)サンプルデータを作成した場合、MySQLソースデータベースからターゲットTiDBデータベースに複製されたテーブル`hello_tidb`が表示されます。 +3. 複製されたデータを確認します。[ステップ2](#step-2-prepare-a-source-database-optional)でサンプルデータを作成した場合、MySQLソースデータベースからターゲットTiDBデータベースに複製されたテーブル`hello_tidb`が表示されます。 ```sql SELECT * FROM hello.hello_tidb; diff --git a/dm/relay-log.md b/dm/relay-log.md index a7d9e094fff1f..84cbe32fb90a3 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -276,7 +276,7 @@ purge: purge-relay -s mysql-replica-01 --filename mysql-bin.000001 --sub-dir e4e0e8ab-09cc-11e9-9220-82cc35207219.000002 ``` -- dmctlで次の`purge-relay`コマンドを実行すると、**現在の**（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` ）ディレクトリの`mysql-bin.000001`より前のすべてのリレーログファイル（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`と`e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`にあるすべてのリレーログファイル）が削除されます。13 `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`ファイルは保持されます。 +- dmctlで次の`purge-relay`コマンドを実行すると、**現在の**（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000003` ）ディレクトリの`mysql-bin.000001`より前のすべてのリレーログファイル（ `deb76a2b-09cc-11e9-9129-5242cf3bb246.000001`と`e4e0e8ab-09cc-11e9-9220-82cc35207219.000002`にあるすべてのリレーログファイル）が削除されます。`deb76a2b-09cc-11e9-9129-5242cf3bb246.000003`内のファイルは保持されます。 ```bash purge-relay -s mysql-replica-01 --filename mysql-bin.000001 diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index 4efe66f483a7c..56aa6813e4ef0 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -7,7 +7,7 @@ summary: TiDBが提供するディザスタリカバリソリューションに このドキュメントでは、TiDBが提供するディザスタリカバリ（DR）ソリューションについて説明します。このドキュメントの構成は以下のとおりです。 -- DR（遠隔医療）の基本概念について説明します。 +- DR（災害復旧）の基本概念について説明します。 - TiDB、TiCDC、およびバックアップ＆リストア（ BR ）のアーキテクチャを紹介します。 - TiDBが提供する災害復旧ソリューションについて説明します。 - これらの災害復旧ソリューションを比較します。 @@ -93,7 +93,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 このアーキテクチャでは、TiDBクラスタ1がリージョン1にデプロイされます。BRはクラスタ1のデータを定期的にリージョン2にバックアップし、さらにこのクラスタのデータ変更ログも継続的にリージョン2にバックアップします。リージョン1で災害が発生し、クラスタ1が復旧できない場合、バックアップデータとデータ変更ログを使用して、リージョン2に新しいクラスタ（クラスタ2）を復元し、サービスを提供できます。 -BRに基づく DR ソリューションは、5 分未満の RPO と、復元するデータのサイズに応じて変化する RTO を提供します。 BR v6.5.0 の場合、復元速度については[スナップショット復元のパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)パフォーマンス[PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)を参照してください。通常、リージョン間のバックアップ機能はデータ セキュリティの最後の手段とみなされ、ほとんどのシステムにとって必須のソリューションでもあります。このソリューションの詳細については、 [BRに基づくDRソリューション](/dr-backup-restore.md)を参照してください。 +BRに基づく DR ソリューションは、5 分未満の RPO と、復元するデータのサイズに応じて変化する RTO を提供します。 BR v6.5.0 の場合、復元速度については[スナップショット復元のパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)と[PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)を参照してください。通常、リージョン間のバックアップ機能はデータ セキュリティの最後の手段とみなされ、ほとんどのシステムにとって必須のソリューションでもあります。このソリューションの詳細については、 [BRに基づくDRソリューション](/dr-backup-restore.md)を参照してください。 一方、 BR はv6.5.0 以降、 [EBSボリュームのスナップショットからTiDBクラスタを復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-from-ebs-snapshot-across-multiple-kubernetes)をサポートします。クラスターが Kubernetes 上で実行されており、クラスターに影響を与えずにできるだけ早くクラスターを復元したい場合は、この機能を使用してシステムの RTO を短縮できます。 diff --git a/dumpling-overview.md b/dumpling-overview.md index 7c570616769ca..c0ffd10f9b39c 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -268,7 +268,7 @@ Dumpling、 `-B`オプションを使用して特定のデータベースをエ - `-B employees` `employees`データベースをエクスポートします。 - `-T employees.WorkOrder` `employees.WorkOrder`テーブルをエクスポートします。 -### 同時実行による輸出効率の向上 {#improve-export-efficiency-through-concurrency} +### 同時実行によるエクスポート効率の向上 {#improve-export-efficiency-through-concurrency} エクスポートされたファイルは、デフォルトでは`./export-`ディレクトリに保存されます。よく使用されるオプションは以下のとおりです。 @@ -364,8 +364,8 @@ SET GLOBAL tidb_gc_life_time = '10m'; | `-t`または`--threads` | 同時バックアップスレッド数 | 4 | | `-r`または`--rows` | テーブル内同時実行を有効にすると、エクスポートが高速化されます。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソース データベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソース データベースが MySQL で、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 | | | `-L`または`--logfile` | ログ出力アドレス。空欄の場合は、ログはコンソールに出力されます。 | 「」 | -| `--loglevel` | ログレベル {debug,info,warn,error,dpanic, panic,fatal} | "情報" | -| `--logfmt` | ログ出力形式：{text,json} | "文章" | +| `--loglevel` | ログレベル {debug,info,warn,error,dpanic, panic,fatal} | "info" | +| `--logfmt` | ログ出力形式：{text,json} | "text" | | `-d`または`--no-data` | データのエクスポートを行わない（スキーマのみをエクスポートする場合に適しています） | | | `--no-header` | ヘッダーを生成せずにテーブルのCSVファイルをエクスポートする | | | `-W`または`--no-views` | ビューをエクスポートしないでください | true | @@ -380,7 +380,7 @@ SET GLOBAL tidb_gc_life_time = '10m'; | `--where` | `where`条件を使用して、テーブルバックアップの範囲を指定します。 | | | `-p`または`--password` | 接続先のデータベースホストのパスワード | | | `-P`または`--port` | 接続されたデータベースホストのポート | 4000 | -| `-u`または`--user` | 接続されたデータベースホストのユーザー名 | "根" | +| `-u`または`--user` | 接続されたデータベースホストのユーザー名 | "root" | | `--dump-empty-database` | 空のデータベースの`CREATE DATABASE`ステートメントをエクスポートします。 | true | | `--ca` | TLS接続用の認証局ファイルのアドレス | | | `--cert` | TLS接続用のクライアント証明書ファイルのアドレス | | diff --git a/dynamic-config.md b/dynamic-config.md index 21537945b4559..04f18eda95465 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -173,7 +173,7 @@ show warnings; | `quota.background-read-bandwidth` | バックグラウンドトランザクションとコプロセッサーがデータを読み取る帯域幅のソフト制限 | | `quota.enable-auto-tune` | クォータの自動調整を有効にするかどうか。この設定項目を有効にすると、TiKV インスタンスの負荷に基づいて、バックグラウンドリクエストのクォータが動的に調整されます。 | | `quota.max-delay-duration` | 単一の読み取りまたは書き込み要求がフォアグラウンドで処理されるまでに強制的に待機される最大時間 | -| `gc.ratio-threshold` | リージョンGCをスキップするしきい値（GCの数versions/theキーの数） | +| `gc.ratio-threshold` | リージョンGCをスキップするしきい値（GCのバージョン数/キーの数） | | `gc.batch-keys` | 1バッチで処理されるキーの数 | | `gc.max-write-bytes-per-sec` | RocksDBに1秒あたり書き込める最大バイト数 | | `gc.enable-compaction-filter` | 圧縮フィルタを有効にするかどうか | @@ -217,11 +217,11 @@ show warnings; | `server.raft-msg-max-batch-size` | 1つのgRPCメッセージに含まれるRaftメッセージの最大数を設定します。 | | `server.simplify-metrics` | サンプリング監視メトリックを簡素化するかどうかを制御します | | `storage.block-cache.capacity` | 共有ブロックキャッシュのサイズ（v4.0.3以降でサポート） | -| storage.フロー制御.有効 | フロー制御メカニズムを有効にするかどうかを決定します | -| storage.フロー制御.memtables-threshold | フロー制御をトリガーするkvDB memtablesの最大数 | +| storage.flow-control.enable | フロー制御メカニズムを有効にするかどうかを決定します | +| storage.flow-control.memtables-threshold | フロー制御をトリガーするkvDB memtablesの最大数 | | storage.flow-control.l0-files-threshold | フロー制御をトリガーするkvDB L0ファイルの最大数 | | storage.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | -| storage.フロー制御.ハード保留圧縮バイト制限 | フロー制御メカニズムがすべての書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | +| storage.flow-control.hard-pending-compaction-bytes-limit | フロー制御メカニズムがすべての書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | | `storage.scheduler-worker-pool-size` | スケジューラスレッドプール内のスレッド数 | | `import.num-threads` | 復元またはインポート RPC 要求を処理するスレッドの数 (動的な変更は v8.1.2 以降でサポートされます) | | `backup.num-threads` | バックアップ スレッドの数 (v4.0.3 以降でサポート) | @@ -236,7 +236,7 @@ show warnings; | `cdc.incremental-scan-speed-limit` | 履歴データの増分スキャンの速度の上限 | | `cdc.incremental-scan-concurrency` | 履歴データの同時増分スキャンタスクの最大数 | -上記の表で、プレフィックスが`{db-name}`または`{db-name}.{cf-name}`パラメータはRocksDB関連の設定です。5のオプション値は`db-name` `rocksdb` `raftdb`です。 +上記の表で、`{db-name}`または`{db-name}.{cf-name}`プレフィックスを持つパラメータはRocksDB関連の設定です。`db-name`のオプション値は`rocksdb`と`raftdb`です。 - `db-name`が`rocksdb`の場合、 `cf-name`のオプションの値は`defaultcf` 、 `writecf` 、 `lockcf` 、および`raftcf`です。 - `db-name`が`raftdb`とき、 `cf-name`の値は`defaultcf`になります。 diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md index de295f615e298..2303555f1b56d 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -83,7 +83,7 @@ Dumplingの基本は次のとおりです。 TiDB Lightning は次のモードをサポートしています。 - `Physical Import Mode` : TiDB Lightningはデータを順序付けられたキーと値のペアに解析し、TiKVに直接インポートします。このモードは通常、テラバイト単位の大容量データを新しいクラスターにインポートするために使用されます。インポート中、クラスターはサービスを提供できません。 -- `Logical Import Mode` : このモードでは、バックエンドとしてTiDB/MySQLを使用します。2よりも速度`Physical Import Mode`遅いですが、オンラインで実行できます。また、MySQLへのデータインポートもサポートしています。 +- `Logical Import Mode` : このモードでは、バックエンドとしてTiDB/MySQLを使用します。`Physical Import Mode`よりも速度が遅いですが、オンラインで実行できます。また、MySQLへのデータインポートもサポートしています。 TiDB Lightningの基本は次のとおりです。 @@ -123,9 +123,9 @@ TiCDC の基本は次のとおりです。 - 対象: TiDB クラスター、MySQL、Kafka、Confluent - サポートされている TiDB バージョン: v4.0.6 以降 -### 同期差分インスペクター {#sync-diff-inspector} +### sync-diff-inspector {#sync-diff-inspector} -[同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md) 、MySQLまたはTiDBデータベースに保存されているデータを比較するツールです。さらに、少量のデータに不整合がある場合、sync-diff-inspectorを使用してデータを修復することもできます。 +[sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)は、MySQLまたはTiDBデータベースに保存されているデータを比較するツールです。さらに、少量のデータに不整合がある場合、sync-diff-inspectorを使用してデータを修復することもできます。 sync-diff-inspector の基本は次のとおりです。 diff --git a/enable-tls-between-clients-and-servers.md b/enable-tls-between-clients-and-servers.md index f6d70407ff05b..9de90ad3de61c 100644 --- a/enable-tls-between-clients-and-servers.md +++ b/enable-tls-between-clients-and-servers.md @@ -7,7 +7,7 @@ summary: データセキュリティを確保するため、安全な接続を TiDBはデフォルトでは、サーバーとクライアント間の安全でない接続を許可します。これにより、チャネルトラフィックを監視する第三者は、クエリの内容や結果を含む、サーバーとクライアント間で送受信されるデータを把握し、場合によっては改ざんすることが可能になります。チャネルが信頼できない場合（例えば、クライアントがパブリックネットワーク経由でTiDBサーバーに接続されている場合）、安全でない接続は情報漏洩のリスクが高まります。このような場合は、セキュリティ上の理由から、TLSで保護された接続を必須とすることをお勧めします。 -TiDBサーバーは、TLS（Transport Layer Security）プロトコルに基づくセキュアな接続をサポートしています。このプロトコルはMySQLのセキュアな接続と互換性があり、MySQLクライアント、MySQLシェル、MySQLドライバなどの既存のMySQLクライアントで直接サポートされています。TLSはSSL（セキュリティ [既知のセキュリティ脆弱性](https://en.wikipedia.org/wiki/Transport_Layer_Security)Layer）と呼ばれることもあります。SSLプロトコルには があるため、TiDBはSSLをサポートしていません。TiDBはTLSv1.2とTLSv1.3をサポートしています。 +TiDBサーバーは、TLS（Transport Layer Security）プロトコルに基づくセキュアな接続をサポートしています。このプロトコルはMySQLのセキュアな接続と互換性があり、MySQLクライアント、MySQLシェル、MySQLドライバなどの既存のMySQLクライアントで直接サポートされています。TLSはSSL（Secure Sockets Layer）と呼ばれることもあります。SSLプロトコルには[既知のセキュリティ脆弱性](https://en.wikipedia.org/wiki/Transport_Layer_Security)があるため、TiDBはSSLをサポートしていません。TiDBはTLSv1.2とTLSv1.3をサポートしています。 TLSで保護された接続を使用する場合、その接続には以下のセキュリティ特性があります。 @@ -78,7 +78,7 @@ TiDBサーバーまたはMySQLクライアントで`ssl-ca`パラメータが指 - MySQLクライアントからTiDBサーバーを認証するには： 1. TiDBサーバーで`ssl-cert`および`ssl-key`パラメータを指定します。 2. MySQLクライアントで`--ssl-ca`パラメータを指定します。 - 3. MySQLクライアントで、 `--ssl-mode`から`VERIFY_CA`までを指定してください。 + 3. MySQLクライアントで、 `--ssl-mode`を少なくとも`VERIFY_CA`に指定してください。 4. TiDBサーバーに設定されている証明書（ `ssl-cert` ）が、クライアントの`--ssl-ca`パラメータで指定されたCAによって署名されていることを確認してください。そうでない場合、認証は失敗します。 - TiDBサーバーからMySQLクライアントを認証するには： @@ -90,7 +90,7 @@ TiDBサーバーまたはMySQLクライアントで`ssl-ca`パラメータが指 - 相互認証を行うには、上記の2つの要件を満たす必要があります。 -デフォルトでは、サーバーとクライアント間の認証はオプションです。TLS ハンドシェイク中にクライアントが識別証明書を提示しなくても、TLS 接続は確立できます。ユーザーを作成するとき`REQUIRE x509` 、または既存のユーザーを変更するとき ( `CREATE USER` ) に`ALTER USER` } を指定することで、クライアントの認証を必須にすることもできます。以下は、ユーザーを作成する例です。 +デフォルトでは、サーバーとクライアント間の認証はオプションです。TLS ハンドシェイク中にクライアントが識別証明書を提示しなくても、TLS 接続は確立できます。ユーザーを作成するとき（ `CREATE USER` ）、または既存のユーザーを変更するとき（ `ALTER USER` ）に`REQUIRE x509`を指定することで、クライアントの認証を必須にすることもできます。以下は、ユーザーを作成する例です。 ```sql CREATE USER 'u1'@'%' REQUIRE X509; diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 9e0e9181f5f03..7e20cfb887b5d 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -19,13 +19,13 @@ TiDBクラスターをデプロイすると、ユーザーデータの大部分 ### TiKV {#tikv} -TiKVは保存時の暗号化をサポートしています。この機能により、TiKVは[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) in 5モードまたは[SM4](https://en.wikipedia.org/wiki/SM4_(cipher)) in [CTR](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)モードを使用してデータファイルを透過的に暗号化できます。保存時の暗号化を有効にするには、ユーザーが暗号化キーを提供する必要があります。このキーはマスターキーと呼ばれます。TiKVは、実際のデータファイルの暗号化に使用したデータキーを自動的にローテーションします。マスターキーは手動で随時ローテーションできます。保存時の暗号化は、保存中のデータ（つまりディスク上）のみを暗号化し、ネットワーク経由で転送中のデータは暗号化しないことに注意してください。保存時の暗号化とTLSを併用することをお勧めします。 +TiKVは保存時の暗号化をサポートしています。この機能により、TiKVは[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)または[SM4](https://en.wikipedia.org/wiki/SM4_(cipher)) in [CTR](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)モードを使用してデータファイルを透過的に暗号化できます。保存時の暗号化を有効にするには、ユーザーが暗号化キーを提供する必要があります。このキーはマスターキーと呼ばれます。TiKVは、実際のデータファイルの暗号化に使用したデータキーを自動的にローテーションします。マスターキーは手動で随時ローテーションできます。保存時の暗号化は、保存中のデータ（つまりディスク上）のみを暗号化し、ネットワーク経由で転送中のデータは暗号化しないことに注意してください。保存時の暗号化とTLSを併用することをお勧めします。 クラウド展開とセルフホスト展開の両方でキー管理サービス (KMS) を使用することも、プレーンテキストのマスター キーをファイルで提供することもできます。 TiKVは現在、コアダンプから暗号鍵とユーザーデータを除外していません。保存時の暗号化を使用する場合は、TiKVプロセスのコアダンプを無効にすることをお勧めします。これは現在、TiKV自体では処理されていません。 -TiKVは、暗号化されたデータファイルをファイルの絶対パスを使用して追跡します。そのため、TiKVノードで暗号化が有効になった後は、ユーザーは`storage.data-dir`などのデータファイルパス設定を変更`rocksdb.wal-dir` `raftdb.wal-dir`で`raftstore.raftdb-path` 。 +TiKVは、暗号化されたデータファイルをファイルの絶対パスを使用して追跡します。そのため、TiKVノードで暗号化が有効になった後は、ユーザーは`storage.data-dir`、`raftstore.raftdb-path`、`rocksdb.wal-dir`、`raftdb.wal-dir`などのデータファイルパス設定を変更しないでください。 SM4暗号化はTiKVバージョン6.3.0以降でのみサポートされます。TiKVバージョン6.3.0より前のバージョンではAES暗号化のみがサポートされます。SM4暗号化はパフォーマンスに影響を与えます。最悪の場合、スループットが50%～80%低下する可能性があります。ただし、 [`storage.block-cache`](/tikv-configuration-file.md#storageblock-cache)を十分に大きな値に設定することで、この影響を大幅に軽減し、スループットの低下を約10%に抑えることができます。 @@ -47,7 +47,7 @@ BRは、S3へのデータバックアップ時にS3サーバー側暗号化（SS ### ログ記録 {#logging} -TiKV、TiDB、およびPD情報ログには、デバッグ用のユーザーデータが含まれる場合があります。情報ログとその中に含まれるデータは暗号化されません。1 [ログ編集](/log-redaction.md)有効にすることを推奨します。 +TiKV、TiDB、およびPD情報ログには、デバッグ用のユーザーデータが含まれる場合があります。情報ログとその中に含まれるデータは暗号化されません。[ログ編集](/log-redaction.md)を有効にすることを推奨します。 ## 保存時の TiKV 暗号化 {#tikv-encryption-at-rest} @@ -258,7 +258,7 @@ TiKVをGrafanaでデプロイしている場合は、保存時の暗号化を監 - 暗号化メタファイル サイズ: 暗号化メタデータ ファイルのサイズ。 - 読み取り/書き込み暗号化メタ期間: 暗号化のメタデータを操作するための追加のオーバーヘッド。 -デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。3 [TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 +デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。[TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 ### TiKVバージョン間の互換性 {#compatibility-between-tikv-versions} @@ -382,7 +382,7 @@ BRを使用して S3 にバックアップする際に S3 サーバー側の暗 tiup br backup full --pd --storage "s3:///" --s3.sse aws:kms -独自に作成し所有するカスタム AWS KMS CMK を使用するには、 `--s3.sse-kms-key-id`追加で渡します。この場合、 BRプロセスとクラスター内のすべての TiKV ノードの両方が KMS CMK にアクセスする必要があり（例：AWS IAM経由）、KMS CMK はバックアップの保存に使用する S3 バケットと同じ AWS リージョンに存在する必要があります。BR プロセスと TiKV ノードにBR IAM経由で KMS CMK へのアクセスを許可することをお勧めします[IAMは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)の使用方法については、AWS ドキュメントを参照してください。例： +独自に作成し所有するカスタム AWS KMS CMK を使用するには、 `--s3.sse-kms-key-id`追加で渡します。この場合、 BRプロセスとクラスター内のすべての TiKV ノードの両方が KMS CMK にアクセスする必要があり（例：AWS IAM経由）、KMS CMK はバックアップの保存に使用する S3 バケットと同じ AWS リージョンに存在する必要があります。BR プロセスと TiKV ノードに AWS IAM経由で KMS CMK へのアクセスを許可することをお勧めします。[IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)の使用方法については、AWS ドキュメントを参照してください。例： tiup br backup full --pd --storage "s3:///" --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321 diff --git a/error-codes.md b/error-codes.md index a79a396239210..b6dc4a5bbef9d 100644 --- a/error-codes.md +++ b/error-codes.md @@ -571,7 +571,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 完全なエラーメッセージ: `ERROR 9006 (HY000): GC life time is shorter than transaction duration` - 間隔`GC Life Time`は短すぎます。長いトランザクションによって読み取られるはずだったデータが削除される可能性があります。3 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)次のコマンドで調整できます。 + `GC Life Time`の間隔は短すぎます。長いトランザクションによって読み取られるはずだったデータが削除される可能性があります。[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)は次のコマンドで調整できます。 ```sql SET GLOBAL tidb_gc_life_time = '30m'; diff --git a/explain-aggregation.md b/explain-aggregation.md index a6ef5c4d55bbc..747ec8dd89b7a 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-index-merge.md b/explain-index-merge.md index 5e24ec5230bd6..1bb66c03cbf2f 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -7,7 +7,7 @@ summary: TiDB の EXPLAIN` ステートメントによって返される実行 インデックスマージは、TiDB v4.0で導入されたテーブルアクセス手法です。この手法により、TiDBオプティマイザはテーブルごとに複数のインデックスを使用し、各インデックスから返される結果をマージすることができます。場合によっては、この手法によってテーブル全体のスキャンが回避され、クエリの効率が向上します。 -TiDBのインデックスマージには、交差型と結合型の2種類があります。前者は`AND`式に適用され、後者は`OR`番目の式に適用されます。結合型のインデックスマージは、TiDB v4.0で実験的機能として導入され、v5.4.0でGAとなりました。交差型はTiDB v6.5.0で導入され、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントが指定された場合にのみ使用できます。 +TiDBのインデックスマージには、交差型と結合型の2種類があります。前者は`AND`式に適用され、後者は`OR`式に適用されます。結合型のインデックスマージは、TiDB v4.0で実験的機能として導入され、v5.4.0でGAとなりました。交差型はTiDB v6.5.0で導入され、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントが指定された場合にのみ使用できます。 ## インデックスのマージを有効にする {#enable-index-merge} @@ -48,7 +48,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t) */ * FROM t WHERE a > 1 OR b > 1; 上記のクエリでは、オプティマイザはテーブルにアクセスするためにユニオン型のインデックスマージを選択します。インデックスマージにより、オプティマイザはテーブルごとに複数のインデックスを使用し、各インデックスから返された結果をマージして、上記の出力の後者の実行プランを生成することができます。 -出力において、 `IndexMerge_8`演算子の`operator info`の`type: union`情報は、この演算子がユニオン型インデックスマージであることを示しています。この演算子には3つの子ノードがあります。7と`IndexRangeScan_6` `IndexRangeScan_5`範囲に従って条件を満たす`RowID`をスキャンし、その後、 `TableRowIDScan_7`演算子はこれらの`RowID`に基づいて条件を満たすすべてのデータを正確に読み取ります。 +出力において、 `IndexMerge_8`演算子の`operator info`の`type: union`情報は、この演算子がユニオン型インデックスマージであることを示しています。この演算子には3つの子ノードがあります。`IndexRangeScan_5`と`IndexRangeScan_6`は範囲に従って条件を満たす`RowID`をスキャンし、その後、 `TableRowIDScan_7`演算子はこれらの`RowID`に基づいて条件を満たすすべてのデータを正確に読み取ります。 `IndexRangeScan` / `TableRangeScan`ように特定のデータ範囲に対して実行されるスキャン演算の場合、結果の`operator info`列には、 `IndexFullScan` / `TableFullScan`のような他のスキャン演算と比較して、スキャン範囲に関する追加情報が含まれます。上記の例では、 `IndexRangeScan_5`演算子の`range:(1,+inf]` 、演算子が 1 から正の無限大までデータをスキャンすることを示しています。 diff --git a/explain-indexes.md b/explain-indexes.md index 1e53bb1ef7571..b0283fca677c8 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -161,7 +161,7 @@ EXPLAIN SELECT id FROM t1 WHERE intkey = 123; `id`内部的には`RowID`でもあるため、インデックス`intkey`に格納されます。インデックス`intkey`を`└─IndexRangeScan_5`の一部として使用することで、インデックス`RowID`の値を直接返すことができます。 -## Point_Get と Batch_Point_Get {#point-get-and-batch-point-get} +## Point_Get と Batch_Point_Get {#point_get-and-batch_point_get} TiDBは、主キーまたは一意キーから直接データを取得する際に、 `Point_Get`または`Batch_Point_Get`演算子を使用します。これらの演算子は`IndexLookup`よりも効率的です。例えば、 diff --git a/explain-mpp.md b/explain-mpp.md index 1e63623661e6d..4bd8242aca3bd 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-partitions.md b/explain-partitions.md index ef2a8f8515ed0..ba65217d73389 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -5,7 +5,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行プ # パーティションを使用したステートメントの説明 {#explain-statements-using-partitions} -`EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。3 [パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 +`EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。[パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 このドキュメントで使用されているサンプル データ: diff --git a/explain-walkthrough.md b/explain-walkthrough.md index c9703885c9cab..4a30c165b912a 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -95,7 +95,7 @@ Query OK, 0 rows affected (10.22 sec) `ANALYZE TABLE`を実行すると、演算子`└─TableFullScan_18`推定行数が正確であり、演算子`└─Selection_19`の推定行数も大幅に近づいたことがわかります。上記の 2 つのケースでは、実行プラン（TiDB がこのクエリを実行するために使用する演算子セット）は変更されていませんが、統計情報が古くなっているために、最適ではないプランが頻繁に発生します。 -`ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。5 [`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 +`ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。[`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 ```sql SHOW STATS_HEALTHY; diff --git a/explore-htap.md b/explore-htap.md index 584ee9004d4b1..424aa6a367553 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -72,7 +72,7 @@ TiDB HTAPの機能を検討する前に、TiDBとそのカラム型ストレー ## データ準備 {#data-preparation} -TiFlashがデプロイされた後、TiKVは自動的にTiFlashにデータを複製しません。TiFlashにTiFlashする必要のあるテーブルを手動で指定する必要があります。その後、TiDBが対応するTiFlashレプリカを作成します。 +TiFlashがデプロイされた後、TiKVは自動的にTiFlashにデータを複製しません。TiFlashに複製する必要のあるテーブルを手動で指定する必要があります。その後、TiDBが対応するTiFlashレプリカを作成します。 - TiDBクラスタにデータがない場合は、まずデータを TiDB に移行します。詳細については、[データ移行](/migration-overview.md)を参照してください。 - TiDBクラスタに既にアップストリームからレプリケートされたデータが存在する場合、 TiFlashのデプロイ後、データレプリケーションは自動的に開始されません。TiFlashにレプリケートするテーブルを手動で指定する必要があります。詳細については、 TiFlash[TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash)を参照してください。 。 diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md index c4461b0b7c205..fe84274c75c49 100644 --- a/exporting-grafana-snapshots.md +++ b/exporting-grafana-snapshots.md @@ -14,7 +14,7 @@ summary: Grafana ダッシュボードのスナップショットをエクスポ > > 現在、MetricsToolはGrafana v6.xxでのみ使用できます。 -メトリクスデータはトラブルシューティングにおいて重要です。リモートアシスタンスを依頼した場合、サポートスタッフが問題を診断するためにGrafanaダッシュボードを確認する必要がある場合があります。1 [メトリクスツール](https://metricstool.pingcap.net/) 、Grafanaダッシュボードのスナップショットをローカルファイルとしてエクスポートし、可視化するのに役立ちます。これらのスナップショットを外部の担当者と共有することで、Grafanaサーバー上の他の機密情報へのアクセスを外部に漏らすことなく、グラフを正確に読み取ることができます。 +メトリクスデータはトラブルシューティングにおいて重要です。リモートアシスタンスを依頼した場合、サポートスタッフが問題を診断するためにGrafanaダッシュボードを確認する必要がある場合があります。[メトリクスツール](https://metricstool.pingcap.net/)は、Grafanaダッシュボードのスナップショットをローカルファイルとしてエクスポートし、可視化するのに役立ちます。これらのスナップショットを外部の担当者と共有することで、Grafanaサーバー上の他の機密情報へのアクセスを外部に漏らすことなく、グラフを正確に読み取ることができます。 ## 使用法 {#usage} diff --git a/extended-statistics.md b/extended-statistics.md index 0117d0b4ce3f7..f91344f53a997 100644 --- a/extended-statistics.md +++ b/extended-statistics.md @@ -85,7 +85,7 @@ ALTER TABLE table_name DROP STATS_EXTENDED stats_name;
仕組み -ステートメントを実行すると、TiDB はオブジェクトを直接削除するのではなく、 `mysql.stats_extended`の列`status` ～ `2`に該当するオブジェクトの値をマークします。 +ステートメントを実行すると、TiDB はオブジェクトを直接削除するのではなく、 `mysql.stats_extended`の該当するオブジェクトの`status`列の値を`2`にマークします。 他のTiDBノードはこの変更を読み取り、メモリキャッシュ内のオブジェクトを削除します。最終的にはバックグラウンドガベージコレクションによってオブジェクトが削除されます。 diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 3f9df8ec14416..d0ff9a9e27534 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -140,7 +140,7 @@ Sqoopでは、 `--batch`各バッチで100個の`statement`文をコミットす ### transaction too largeエラーメッセージが表示されます {#the-error-message-code-transaction-too-large-code-is-displayed} -基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。1 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 +基盤となるストレージエンジンの制限により、TiDB の各キーと値のエントリ（1行）は 6MB 以下にする必要があります。[`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)設定値は最大 120MB まで調整できます。 分散トランザクションは2相コミットを必要とし、最下層でRaftレプリケーションを実行します。トランザクションが非常に大きい場合、コミットプロセスは非常に遅くなり、書き込み競合が発生する可能性が高くなります。さらに、失敗したトランザクションのロールバックは、不要なパフォーマンスの低下につながります。これらの問題を回避するため、デフォルトでは、トランザクション内のキーと値のエントリの合計サイズを100MB以下に制限しています。より大きなトランザクションが必要な場合は、TiDB設定ファイルの値`txn-total-size-limit`変更してください。この設定項目の最大値は10GBです。実際の制限は、マシンの物理メモリにも影響されます。 @@ -152,7 +152,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do ### TiDB はデータを削除した後すぐにスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data} -`DELETE` `TRUNCATE`操作`DROP`いずれもデータを即時に解放しません。7と`TRUNCATE` `DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。11 `DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`実行されると、領域は再利用されます。 +`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`が実行されると、領域は再利用されます。 ### データをロードするときに、ターゲット テーブルで DDL 操作を実行できますか? {#can-i-execute-ddl-operations-on-the-target-table-when-loading-data} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index cd101a1f910db..efc32ed6fd6ac 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -180,7 +180,7 @@ Sqoopでは、 `--batch`各バッチで100文をコミットすることを意 ## TiDB はデータを削除した直後にスペースを解放しますか? {#does-tidb-release-space-immediately-after-deleting-data} -`DELETE` `TRUNCATE`操作はいずれもデータ`DROP` `TRUNCATE` `DROP`は、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。11 `DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。 +`DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、圧縮が実行されるまで領域は即時に解放されません。 ## データを削除するとクエリ速度が遅くなるのはなぜですか? {#why-does-the-query-speed-get-slow-after-data-is-deleted} diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index d43ad3740b644..c14ba86e0d14a 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -49,7 +49,7 @@ TiDBクラスタは、TiDBサーバー、PD（Placement Driver）サーバー、 はい。TiDB は、単一の場所に少数のノードがある場合でも、多数の[複数のデータセンターにまたがるノード](/multi-data-centers-in-one-city-deployment.md)がある場合でも、クラスター全体にトランザクションを分散します。 -GoogleのPercolatorに着想を得たTiDBのトランザクションモデルは、主に2フェーズコミットプロトコルをベースに、実用的な最適化が施されています。このモデルは、タイムスタンプアロケータを利用して各トランザクションに単調増加するタイムスタンプを割り当てることで、競合を検出します。1 [PD](/tidb-architecture.md#placement-driver-pd-server) TiDBクラスタ内でタイムスタンプアロケータとして機能します。 +GoogleのPercolatorに着想を得たTiDBのトランザクションモデルは、主に2フェーズコミットプロトコルをベースに、実用的な最適化が施されています。このモデルは、タイムスタンプアロケータを利用して各トランザクションに単調増加するタイムスタンプを割り当てることで、競合を検出します。[PD](/tidb-architecture.md#placement-driver-pd-server)は、TiDBクラスタ内でタイムスタンプアロケータとして機能します。 ### TiDB を操作するためにどのプログラミング言語を使用できますか? {#what-programming-language-can-i-use-to-work-with-tidb} diff --git a/filter-dml-event.md b/filter-dml-event.md index 1dc3cb41b889c..477bbf588bb5e 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -73,7 +73,7 @@ SQL式は1つの列でも複数の列でも使用できます。また、TiDBで `TIMESTAMP`のデフォルトタイムゾーンは、タスク設定ファイルで指定されたタイムゾーンです。デフォルト値はダウンストリームのタイムゾーンです。`c_timestamp = '2021-01-01 12:34:56.5678+08:00'`ように明示的にタイムゾーンを指定することもできます。 -`expression-filter`設定項目で複数のフィルタリングルールを設定できます。上流データソースは、 `expression-filters`の必要なルールを参照してルールを有効にします。複数のルールを使用する場合、**いずれ**かのルールに一致すると、行の変更全体がフィルタリングされます。 +`expression-filter`設定項目で複数のフィルタリングルールを設定できます。上流データソースは、 `expression-filters`の必要なルールを参照してルールを有効にします。複数のルールを使用する場合、**いずれか**のルールに一致すると、行の変更全体がフィルタリングされます。 > **Note:** > diff --git a/follower-read.md b/follower-read.md index cb3965c867d48..eca007f12f237 100644 --- a/follower-read.md +++ b/follower-read.md @@ -15,7 +15,7 @@ Follower Read を実行する際、TiDBはトポロジ情報に基づいて適 -Follower Read を実行する際、TiDB はトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDB はラベル`zone`を用いてローカルレプリカを識別します。TiDB ノードのラベル`zone`がターゲット TiKV ノードのラベル 3 と同じ場合、TiDB はそのレプリカをローカルレプリカと見なします。ラベル`zone`はTiDB Cloudで自動的に設定されます。 +Follower Read を実行する際、TiDB はトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDB はラベル`zone`を用いてローカルレプリカを識別します。TiDB ノードのラベル`zone`がターゲット TiKV ノードのラベルと同じ場合、TiDB はそのレプリカをローカルレプリカと見なします。ラベル`zone`はTiDB Cloudで自動的に設定されます。 diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index d2a83b1013511..811010d5f0acc 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -34,7 +34,7 @@ summary: TiDB でサポートされている集計関数について学習しま - `APPROX_PERCENTILE(expr, constant_integer_expr)` - この関数は`expr`のパーセンタイルを返します。引数`constant_integer_expr`は、 5 から`[1,100]`の範囲の定数整数であるパーセンタイル値を示します。パーセンタイル P k （ `k`はパーセンタイルを表します）は、データセット内に P k以下の値が少なくとも`k%`あることを示します。 + この関数は`expr`のパーセンタイルを返します。引数`constant_integer_expr`は、 `[1,100]`の範囲の定数整数であるパーセンタイル値を示します。パーセンタイル P k （ `k`はパーセンタイルを表します）は、データセット内に P k以下の値が少なくとも`k%`あることを示します。 この関数は、 `expr`の戻り値の型として[数値型](/data-type-numeric.md)と[日付と時刻の種類](/data-type-date-and-time.md)をサポートします。その他の戻り値の型については、 `APPROX_PERCENTILE` `NULL`を返します。 diff --git a/functions-and-operators/cast-functions-and-operators.md b/functions-and-operators/cast-functions-and-operators.md index 28bf3348e113b..af13832ac7792 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/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 3d10d62149ffc..9d377bb01f4df 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`すべての年を集計して計算されていることを示します。 具体的には： @@ -124,7 +124,7 @@ SELECT year, month, SUM(profit) AS profit FROM bank GROUP BY year, month WITH RO 3 rows in set (0.02 sec) ``` -`GROUP BY`の列にネイティブ`NULL`値が含まれている場合、 `WITH ROLLUP`の集計結果がクエリ結果を誤解させる可能性があることに注意してください。この問題に対処するには、 `GROUPING()`関数を使用して、ネイティブ`NULL`値と`WITH ROLLUP`によって生成された`NULL`値を区別できます。この関数はグループ化式をパラメータとして受け取り、現在の結果でグループ化式が集計されているかどうかを示す`0`または`1`返します。19 `1`集計されていることを表し、 `0`集計されていないことを表します。 +`GROUP BY`の列にネイティブ`NULL`値が含まれている場合、 `WITH ROLLUP`の集計結果がクエリ結果を誤解させる可能性があることに注意してください。この問題に対処するには、 `GROUPING()`関数を使用して、ネイティブ`NULL`値と`WITH ROLLUP`によって生成された`NULL`値を区別できます。この関数はグループ化式をパラメータとして受け取り、現在の結果でグループ化式が集計されているかどうかを示す`0`または`1`を返します。`1`は集計されていることを表し、 `0`は集計されていないことを表します。 次の例は、 `GROUPING()`関数の使用方法を示しています。 diff --git a/functions-and-operators/json-functions.md b/functions-and-operators/json-functions.md index 2cca9c5c4876d..2be0b6613e8af 100644 --- a/functions-and-operators/json-functions.md +++ b/functions-and-operators/json-functions.md @@ -22,7 +22,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを | [JSON_CONTAINS()](/functions-and-operators/json-functions/json-functions-search.md#json_contains) | 指定された候補JSONドキュメントがターゲットJSONドキュメント内に含まれているかどうかを1または0を返すことで示します。 | | [JSON_CONTAINS_PATH()](/functions-and-operators/json-functions/json-functions-search.md#json_contains_path) | JSONドキュメントに指定されたパスのデータが含まれているかどうかを示す0または1を返します。 | | [JSON_EXTRACT()](/functions-and-operators/json-functions/json-functions-search.md#json_extract) | `path`引数に一致するドキュメントの部分から選択されたJSONドキュメントからデータを返します。 | -| [->](/functions-and-operators/json-functions/json-functions-search.md#-) | 評価パスの後のJSON列から値を返します。1の別名です`JSON_EXTRACT(doc, path_literal)` | +| [->](/functions-and-operators/json-functions/json-functions-search.md#-) | 評価パスの後のJSON列から値を返します。`JSON_EXTRACT(doc, path_literal)`の別名です。 | | [->>](/functions-and-operators/json-functions/json-functions-search.md#--1) | 評価パスの後のJSON列から値を返し、結果を引用符で囲まない`JSON_UNQUOTE(JSON_EXTRACT(doc, path_literal))`の別名。 | | [JSON_KEYS()](/functions-and-operators/json-functions/json-functions-search.md#json_keys) | JSONオブジェクトの最上位レベルの値からキーをJSON配列として返します。パス引数が指定されている場合は、選択したパスから最上位レベルのキーを返します。 | | [JSON_SEARCH()](/functions-and-operators/json-functions/json-functions-search.md#json_search) | JSONドキュメントで文字列の1つまたはすべてに一致するものを検索する | diff --git a/functions-and-operators/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/tidb-functions.md b/functions-and-operators/tidb-functions.md index 7031f49936b71..11d617743cafb 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -59,7 +59,7 @@ summary: TiDB 固有の関数の使用法について学習します。 ## 現在のリソースグループ {#current-resource-group} -`CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。3 [リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 +`CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。[リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 セッションが確立されると、TiDB はログインユーザーがデフォルトでバインドされているリソースグループにセッションをバインドします。ユーザーがどのリソースグループにもバインドされていない場合、セッションは`default`リソースグループにバインドされます。セッションが確立されると、ユーザーのバインドされているリソースグループが[ユーザーにバインドされたリソースグループを変更する](/sql-statements/sql-statement-alter-user.md#modify-basic-user-information)で変更されても、バインドされているリソースグループはデフォルトで変更されません。現在のセッションのバインドされているリソースグループを変更するには、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)を使用します。 @@ -264,7 +264,7 @@ ORDER BY ## TIDB_デコード_プラン {#tidb-decode-plan} -TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。1関数`TIDB_DECODE_PLAN()` 、エンコードされたプランを人間が読める形式にデコードするために使用されます。 +TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。`TIDB_DECODE_PLAN()`関数は、エンコードされたプランを人間が読める形式にデコードするために使用されます。 この関数は、ステートメント実行時にプランが取得されるため便利です。`EXPLAIN`ステートメントを再実行すると、データの分布と統計が時間の経過とともに変化するため、異なる結果が生成される可能性があります。 @@ -378,7 +378,7 @@ SELECT TIDB_IS_DDL_OWNER(); ## TIDB_PARSE_TSO {#tidb-parse-tso} -`TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。3 [TSO](/tso.md) Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 +`TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。[TSO](/tso.md)は Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 TSO は次の 2 つの部分で構成される数値です。 diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md index bd9f8dd7386fb..c8330c1027203 100644 --- a/functions-and-operators/window-functions.md +++ b/functions-and-operators/window-functions.md @@ -65,7 +65,7 @@ FROM ## `DENSE_RANK()` {#dense-rank} -`DENSE_RANK()`関数は現在行の順位を返します。3 [`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 +`DENSE_RANK()`関数は現在行の順位を返します。[`RANK()`](#rank)と似ていますが、同順位（同じ値と順序条件を共有する行）の場合に空白を残しません。 ```sql SELECT diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index d43c2b71d53b4..391b1b663884e 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -10,7 +10,7 @@ summary: GC 構成パラメータについて学習します。 - [`tidb_gc_enable`](/system-variables.md#tidb_gc_enable-new-in-v50) : TiKV のガベージコレクションを有効にするかどうかを制御します。 - [`tidb_gc_run_interval`](/system-variables.md#tidb_gc_run_interval-new-in-v50) : GC 間隔を指定します。 - [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) : 各 GC でデータが保持される時間制限を指定します。 -- [`tidb_gc_concurrency`](/system-variables.md#tidb_gc_concurrency-new-in-v50) : GC の[ロックを解決する](/garbage-collection-overview.md#resolve-locks)番目のステップのスレッド数を指定します。 +- [`tidb_gc_concurrency`](/system-variables.md#tidb_gc_concurrency-new-in-v50) : GC の[ロックを解決する](/garbage-collection-overview.md#resolve-locks)のステップのスレッド数を指定します。 - [`tidb_gc_scan_lock_mode`](/system-variables.md#tidb_gc_scan_lock_mode-new-in-v50) : GC のロック解決ステップでロックをスキャンする方法を指定します。 - [`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) : アクティブなトランザクションが GC セーフ ポイントをブロックする最大時間を指定します。 @@ -26,7 +26,7 @@ summary: GC 構成パラメータについて学習します。 -TiKVはGC I/O制限をサポートしています。1を設定すると、GCワーカーの`gc.max-write-bytes-per-sec`秒あたりの書き込み回数を制限し、通常のリクエストへの影響を軽減できます。 +TiKVはGC I/O制限をサポートしています。`gc.max-write-bytes-per-sec`を設定すると、GCワーカーの1秒あたりの書き込み量を制限し、通常のリクエストへの影響を軽減できます。 `0`この機能を無効にすることを示します。 @@ -38,11 +38,11 @@ tikv-ctl --host=ip:port modify-tikv-config -n gc.max-write-bytes-per-sec -v 10MB ## TiDB 5.0 の変更点 {#changes-in-tidb-5-0} -TiDBの以前のリリースでは、ガベージコレクションは`mysql.tidb`システムテーブルを介して設定されていました。このテーブルへの変更は引き続きサポートされますが、提供されているシステム変数を使用することをお勧めします。これにより、設定の変更が確実に検証され、予期しない動作を防ぐことができます( [＃20655](https://github.com/pingcap/tidb/issues/20655) )。 +TiDBの以前のリリースでは、ガベージコレクションは`mysql.tidb`システムテーブルを介して設定されていました。このテーブルへの変更は引き続きサポートされますが、提供されているシステム変数を使用することをお勧めします。これにより、設定の変更が確実に検証され、予期しない動作を防ぐことができます( [#20655](https://github.com/pingcap/tidb/issues/20655) )。 `CENTRAL` GCモードはサポートされなくなりました。代わりに、TiDB 3.0以降のデフォルトである`DISTRIBUTED` GCモードが自動的に使用されます。このモードは、TiDBがガベージコレクションを開始するために各TiKVリージョンにリクエストを送信する必要がなくなるため、より効率的です。 -以前のリリースの変更点については、左側のメニューにある*TIDB バージョン セレクターを*使用して、このドキュメントの以前のバージョンを参照してください。 +以前のリリースの変更点については、左側のメニューにある*TIDB バージョン セレクター*を使用して、このドキュメントの以前のバージョンを参照してください。 ## TiDB 6.1.0 の変更点 {#changes-in-tidb-6-1-0} diff --git a/generate-self-signed-certificates.md b/generate-self-signed-certificates.md index dce80574afb2e..d32be6c7d048a 100644 --- a/generate-self-signed-certificates.md +++ b/generate-self-signed-certificates.md @@ -69,7 +69,7 @@ summary: openssl` を使用して自己署名証明書を生成します。 - tidb-server 証明書: TiDB が他のコンポーネントやクライアントに対して TiDB を認証するために使用されます。 - tikv-server 証明書: TiKV が他のコンポーネントやクライアントに対して TiKV を認証するために使用されます - pd-server 証明書: PD が他のコンポーネントやクライアントに対して PD を認証するために使用されます。 -- クライアント証明書: PD、TiKV、TiDBからのクライアントの認証に使用されます（例: `pd-ctl` `tikv-ctl` +- クライアント証明書: PD、TiKV、TiDBからのクライアントの認証に使用されます（例: `pd-ctl`、`tikv-ctl`） ### TiKVインスタンスに証明書を発行する {#issue-certificates-to-tikv-instances} diff --git a/generated-columns.md b/generated-columns.md index 8cb2165d769cd..cf8529fbfe5b1 100644 --- a/generated-columns.md +++ b/generated-columns.md @@ -46,7 +46,7 @@ CREATE TABLE person ( ); ``` -このテーブルでは、 `city`番目の列は**仮想生成列**であり、インデックスが設定されています。次のクエリでは、このインデックスを使用することで実行速度を向上させることができます。 +このテーブルでは、 `city`列は**仮想生成列**であり、インデックスが設定されています。次のクエリでは、このインデックスを使用することで実行速度を向上させることができます。 ```sql SELECT name, id FROM person WHERE city = 'Beijing'; diff --git a/geo-distributed-deployment-topology.md b/geo-distributed-deployment-topology.md index 621f643340b5e..d7200f99edf36 100644 --- a/geo-distributed-deployment-topology.md +++ b/geo-distributed-deployment-topology.md @@ -9,7 +9,7 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 ## トポロジ情報 {#topology-information} -| インスタンス | 数 | 物理マシン構成 | BJ IP | 船 | 設定 | +| インスタンス | 数 | 物理マシン構成 | BJ IP | SH IP | 設定 | | :------------- | :--- | :------------------------------- | :----------------------------------------------------- | :-------- | :------------------------- | | TiDB | 5 | 16 VCore 32GB * 1 | 10.0.1.1
10.0.1.2
10.0.1.3
10.0.1.4 | 10.0.1.5 | デフォルトポート
グローバルディレクトリ構成 | | PD | 5 | 4 VCore 8GB * 1 | 10.0.1.6
10.0.1.7
10.0.1.8
10.0.1.9 | 10.0.1.10 | デフォルトポート
グローバルディレクトリ構成 | diff --git a/global-indexes.md b/global-indexes.md index 2ac47c9fd01b6..7ad2398eb4d72 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -43,7 +43,7 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 - **v7.6.0より前**：TiDBはパーティションテーブル上のローカルインデックスのみをサポートします。つまり、パーティションテーブルの一意キーには、パーティション式内のすべての列を含める必要があります。パーティションキーを使用しないクエリはすべてのパーティションをスキャンする必要があり、クエリパフォーマンスが低下します。 - **v7.6.0** : グローバルインデックスを有効にするシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)が導入されました。ただし、この機能は現時点ではまだ開発中であり、本番での使用は推奨されません。 - **v8.3.0** : グローバルインデックスが実験的機能としてリリースされました。インデックスを定義する際に`GLOBAL`キーワードを使用することで、明示的にグローバルインデックスを作成できます。 -- **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数 4 は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 +- **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 - **v8.5.0** : グローバル インデックスは、パーティション式のすべての列を含めることをサポートします。 ## グローバルインデックスとローカルインデックス {#global-indexes-vs-local-indexes} diff --git a/glossary.md b/glossary.md index 4bad41ce7eb9e..1bf20ca3318b1 100644 --- a/glossary.md +++ b/glossary.md @@ -143,7 +143,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### グローバルトランザクション識別子（GTID） {#global-transaction-identifiers-gtids} -グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。1 [データ移行（DM）](/dm/dm-overview.md) 、これらのIDを使用して一貫性のあるレプリケーションを保証します。 +グローバルトランザクション識別子（GTID）は、MySQLバイナリログで使用される一意のトランザクションIDで、どのトランザクションが複製されたかを追跡するために使用されます。[データ移行（DM）](/dm/dm-overview.md)は、これらのIDを使用して一貫性のあるレプリケーションを保証します。 ## H {#a-id-h-class-letter-href-h-h-a} @@ -339,7 +339,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ ### セキュリティ強化モード（SEM） {#security-enhanced-mode-sem} -セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。1 [セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 +セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。[セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のようなシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 詳細については、 [システム変数に関するドキュメント - `tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)を参照してください。 diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index 7e169d1d1633a..28c09fc750a1d 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文実行時に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 | | @@ -62,7 +62,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | システム情報 | Vコア | CPU コアの数。 | | | システム情報 | メモリ | 合計メモリ。 | | | システム情報 | CPU使用率 | CPU使用率、最大100%。 | | -| システム情報 | 荷重 [1m] | 1分以内に過負荷になります。 | | +| システム情報 | 荷重 [1m] | 1分間の負荷。 | | | システム情報 | 使用可能なメモリ | 使用可能なメモリのサイズ。 | | | システム情報 | ネットワークトラフィック | ネットワーク トラフィックの統計。 | | | システム情報 | TCP再送信 | TOC 再送信の頻度。 | | diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 6aa3bd7a5ebac..ab745687c5291 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -44,7 +44,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - スケジュールオペレータ終了: タイプごとに終了したオペレータの数 - スケジュールオペレータのタイムアウト: タイプごとのタイムアウトオペレータの数 - スケジュールオペレータの交代またはキャンセル: タイプごとに交代またはキャンセルされたオペレータの数 -- 州別の運行管理者数: 州ごとの運行管理者数 +- 状態別のオペレーター数: 状態ごとのオペレーター数 - オペレータ終了時間: 終了したオペレータの最大時間 - オペレータステップの所要時間: 完了したオペレータステップの最大所要時間 @@ -58,7 +58,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - サイズ増幅: TiKVインスタンスあたりのサイズ増幅率。これは、(ストアリージョンサイズ)/(ストア使用容量サイズ)に等しい。 - 利用可能なサイズ比率: TiKVインスタンスあたりの利用可能なサイズ比率。これは、(ストアの利用可能な容量サイズ)/(ストアの容量サイズ)に等しくなります。 - ストアリーダースコア: TiKVインスタンスごとのリーダースコア -- ストアリージョンスコア: TiKVインスタンスごとのリージョンリージョン +- ストアリージョンスコア: TiKVインスタンスごとのリージョンスコア - ストアリーダーサイズ: TiKVインスタンスあたりのリーダーサイズの合計 - ストアリージョンサイズ: TiKVインスタンスあたりのリージョンサイズの合計 - ストアリーダー数: TiKVインスタンスあたりのリーダー数 @@ -117,14 +117,14 @@ PD ダッシュボード メトリック項目の説明は次のとおりです ![PD Dashboard - gRPC metrics](/media/pd-dashboard-grpc-v2.png) -## など {#etcd} +## etcd {#etcd} - 処理トランザクション数: etcdがトランザクションを処理する速度 - 99% トランザクション処理時間: トランザクション処理率 (P99) -- 99% WAL fsync 実行時間: WAL を永続ストレージに書き込むのにかかる時間`1s` (P99) 未満です。 +- 99% WAL fsync 実行時間: WAL を永続ストレージに書き込むのにかかる時間。`1s` (P99) 未満です。 - 99% ピアラウンドトリップタイム（秒）: etcd のネットワークレイテンシー（P99）| 値は`1s`未満です - etcd ディスク WAL fsync レート: 永続ストレージへの WAL の書き込みレート -- Raftの用語: Raftの現在の用語 +- Raft term: Raftの現在のterm - Raftコミットインデックス: Raftの最後にコミットされたインデックス - Raft適用インデックス: Raftの最後に適用されたインデックス @@ -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) @@ -143,7 +143,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - ハートビートリージョンイベントQPS: キャッシュの更新やデータの永続化を含むハートビートメッセージの処理のQPS - リージョンハートビートレポート: インスタンスごとにPDに報告されたハートビートの数 - リージョンハートビートレポートエラー: ステータスが`error`のハートビートの数 -- リージョンハートビートレポートがアクティブ: ステータスが`ok`ハートビートの数 +- リージョンハートビートレポートがアクティブ: ステータスが`ok`のハートビートの数 - リージョンスケジュールプッシュ: TiKVインスタンスごとにPDから送信された対応するスケジュールコマンドの数 - 99%リージョンハートビートレイテンシー: TiKVインスタンスあたりのハートビートレイテンシー(P99) diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index a67d693967d30..6c239255a33ec 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -21,10 +21,10 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### クエリの概要 {#query-summary} - 所要時間: 実行時間 - - クライアントのネットワーク要求がTiDBに送信されてから、TiDBがそれを実行した後にクライアントに返される`COM_STMT_FETCH`の時間。通常、クライアント要求はSQL文の形式で送信されますが、 `COM_PING` `COM_SEND_LONG_DATA`のコマンドの実行時間も含まれる場合があります`COM_SLEEP` + - クライアントのネットワーク要求がTiDBに送信されてから、TiDBがそれを実行した後にクライアントに返される`COM_STMT_FETCH`の時間。通常、クライアント要求はSQL文の形式で送信されますが、 `COM_PING`、`COM_SLEEP`、`COM_STMT_FETCH`、`COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります - TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ような複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 - 1秒あたりのコマンド数: コマンド実行結果の成功または失敗に応じて分類される、TiDBによって1秒あたりに処理されるコマンドの数 -- QPS: すべての TiDB インスタンスで`SELECT`秒あたりに実行される SQL ステートメントの数。1、3、5 `UPDATE`およびその他のタイプのステートメントに従ってカウントされます`INSERT` +- QPS: すべての TiDB インスタンスで秒あたりに実行される SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`およびその他のタイプのステートメントに従ってカウントされます - インスタンス別CPS: コマンド実行結果の成功または失敗に応じて分類された各TiDBインスタンスのコマンド統計 - 失敗したクエリOPM：各TiDBインスタンスで1分間にSQL文を実行した際に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 - スロークエリ：スロークエリの処理時間の統計（スロークエリ全体の時間コスト、コプロセッサーの時間コスト、コプロセッサーのスケジューリングの待機時間）。スロークエリは、内部SQL文と一般SQL文に分類されます。 @@ -85,7 +85,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - 解析時間: SQL文の解析時間の統計 - コンパイル時間: 解析されたSQL ASTを実行プランにコンパイルする時間の統計 - 実行時間: SQL文の実行時間の統計 -- `Stream Agg`なエグゼキュータOPS: `Hash Join`秒あたりに多くのシステムリソース`Hash Agg`消費するオペレータの統計`Index Look Up Join` `Merge Join` `TopN` `Sort` +- 高負荷エグゼキュータOPS: 1秒あたりに多くのシステムリソースを消費するオペレータの統計`Merge Join` `Hash Join` `Index Look Up Join` `Hash Agg` `Stream Agg` `Sort` `TopN` - プランキャッシュOPSを使用したクエリ: プランキャッシュを使用したクエリの1秒あたりの統計 - プラン キャッシュ ミス OPS: 1 秒あたりにプラン キャッシュがミスされた回数の統計 - プランキャッシュメモリ使用量: 各 TiDB インスタンスにキャッシュされた実行プランによって消費されるメモリの合計 @@ -106,7 +106,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - TiClientリージョンエラー OPS: TiKV によって返されたリージョン関連のエラー メッセージの数 - KVバックオフOPS: TiKVによって返されたエラーメッセージの数 - ロック解決OPS: ロックを解決するためのTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、ロックを解決しようとする。 -- その他のエラー OPS: ロックのクリアや更新など、その他の種類のエラーの数`SafePoint` +- その他のエラー OPS: ロックのクリアや`SafePoint`の更新など、その他の種類のエラーの数 ### KVリクエスト {#kv-request} @@ -187,7 +187,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### GC {#gc} -- 作業`delete_range`アクションOPM: `run_job` `resolve_lock`含むGC関連操作の数 +- ワーカーアクションOPM: `run_job`、`resolve_lock`、`delete_range`を含むGC関連操作の数 - 期間 99: GC 関連操作に費やされた時間 - 設定: GCデータの有効期間とGC実行間隔の設定 - GC失敗OPM: 失敗したGC関連操作の数 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index 5ab661dcf0508..ac2d677ac4838 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/identify-slow-queries.md b/identify-slow-queries.md index 34e61ef6bb2b8..17b229304127b 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -129,11 +129,11 @@ TiKVコプロセッサータスクフィールド： - `Cop_proc_avg` : RocksDB のミューテックスなど、カウントできない待機時間を含む、cop-tasks の平均実行時間。 - `Cop_proc_p90` : cop-tasks の P90 実行時間。 - `Cop_proc_max` : cop-tasks の最大実行時間。 -- `Cop_proc_addr` : 実行時間が最も長いコップタスクのアドレス。 +- `Cop_proc_addr` : 実行時間が最も長い cop-task のアドレス。 - `Cop_wait_avg` : リクエストのキューイングとスナップショットの取得時間を含む、cop-tasks の平均待機時間。 -- `Cop_wait_p90` : 警官タスクの P90 待機時間。 -- `Cop_wait_max` : 警官タスクの最大待機時間。 -- `Cop_wait_addr` : 待ち時間が最も長い警官タスクのアドレス。 +- `Cop_wait_p90` : cop-tasks の P90 待機時間。 +- `Cop_wait_max` : cop-tasks の最大待機時間。 +- `Cop_wait_addr` : 待ち時間が最も長い cop-task のアドレス。 - `Rocksdb_delete_skipped_count` : RocksDB がデータをスキャンする際に検出する削除済み (tombstone) キーの数。 - `Rocksdb_key_skipped_count` : RocksDB がデータをスキャンする際に遭遇するすべてのキーの数。 - `Rocksdb_block_cache_hit_count` : RocksDB がブロックキャッシュからデータを読み取る回数。 @@ -143,7 +143,7 @@ TiKVコプロセッサータスクフィールド： - `Cop_backoff_{backoff-type}_total_times` : エラーによって発生したバックオフの合計回数。 - `Cop_backoff_{backoff-type}_total_time` : エラーによって発生したバックオフの合計時間。 - `Cop_backoff_{backoff-type}_max_time` : エラーによって発生したバックオフの最長時間。 -- `Cop_backoff_{backoff-type}_max_addr` : エラーによって最も長いバックオフ時間が発生したコップタスクのアドレス。 +- `Cop_backoff_{backoff-type}_max_addr` : エラーによって最も長いバックオフ時間が発生した cop-task のアドレス。 - `Cop_backoff_{backoff-type}_avg_time` : エラーによって発生するバックオフの平均時間。 - `Cop_backoff_{backoff-type}_p90_time` : エラーによって発生した P90 パーセンタイルバックオフ時間。 @@ -207,7 +207,7 @@ TiKVコプロセッサータスクフィールド： フィールドの詳細な説明、診断の意味、背景情報については、 [`identify-slow-queries`のフィールド説明](/identify-slow-queries.md#fields-description)を参照してください。 -特に断りのない限り、次の表のフィールドは [統一されたルール構文と型制約](#unified-rule-syntax-and-type-constraints)型安定」で説明されている一般的な一致および型ルールに従います。この表には、現在サポートされているフィールド名、タイプ、単位、およびルール固有のいくつかの注意事項のみがリストされています。各フィールドの意味論的な意味を繰り返すことはありません。 +特に断りのない限り、次の表のフィールドは [統一されたルール構文と型制約](#unified-rule-syntax-and-type-constraints)で説明されている一般的な一致および型ルールに従います。この表には、現在サポートされているフィールド名、タイプ、単位、およびルール固有のいくつかの注意事項のみがリストされています。各フィールドの意味論的な意味を繰り返すことはありません。 | フィールド名 | タイプ | ユニット | 注記 | | -------------------------------------------- | -------- | ---- | ---------------------------------- | @@ -215,23 +215,23 @@ TiKVコプロセッサータスクフィールド： | `Session_alias` | `string` | なし | - | | `DB` | `string` | なし | マッチング時に大文字小文字を区別しない | | `Exec_retry_count` | `uint` | カウント | - | -| `Query_time` | `float` | 2番 | - | -| `Parse_time` | `float` | 2番 | - | -| `Compile_time` | `float` | 2番 | - | -| `Rewrite_time` | `float` | 2番 | - | -| `Optimize_time` | `float` | 2番 | - | -| `Wait_TS` | `float` | 2番 | - | +| `Query_time` | `float` | 秒 | - | +| `Parse_time` | `float` | 秒 | - | +| `Compile_time` | `float` | 秒 | - | +| `Rewrite_time` | `float` | 秒 | - | +| `Optimize_time` | `float` | 秒 | - | +| `Wait_TS` | `float` | 秒 | - | | `Is_internal` | `bool` | なし | - | | `Digest` | `string` | なし | - | | `Plan_digest` | `string` | なし | - | | `Num_cop_tasks` | `int` | カウント | - | | `Mem_max` | `int` | バイト | - | | `Disk_max` | `int` | バイト | - | -| `Write_sql_response_total` | `float` | 2番 | - | +| `Write_sql_response_total` | `float` | 秒 | - | | `Succ` | `bool` | なし | - | | `Resource_group` | `string` | なし | マッチング時に大文字小文字を区別しない | -| `KV_total` | `float` | 2番 | - | -| `PD_total` | `float` | 2番 | - | +| `KV_total` | `float` | 秒 | - | +| `PD_total` | `float` | 秒 | - | | `Unpacked_bytes_sent_tikv_total` | `int` | バイト | - | | `Unpacked_bytes_received_tikv_total` | `int` | バイト | - | | `Unpacked_bytes_sent_tikv_cross_zone` | `int` | バイト | - | @@ -240,13 +240,13 @@ TiKVコプロセッサータスクフィールド： | `Unpacked_bytes_received_tiflash_total` | `int` | バイト | - | | `Unpacked_bytes_sent_tiflash_cross_zone` | `int` | バイト | - | | `Unpacked_bytes_received_tiflash_cross_zone` | `int` | バイト | - | -| `Process_time` | `float` | 2番 | - | -| `Backoff_time` | `float` | 2番 | - | +| `Process_time` | `float` | 秒 | - | +| `Backoff_time` | `float` | 秒 | - | | `Total_keys` | `uint` | カウント | - | | `Process_keys` | `uint` | カウント | - | | `cop_mvcc_read_amplification` | `float` | 比率 | 比率値（ `Total_keys / Process_keys` ） | -| `Prewrite_time` | `float` | 2番 | - | -| `Commit_time` | `float` | 2番 | - | +| `Prewrite_time` | `float` | 秒 | - | +| `Commit_time` | `float` | 秒 | - | | `Write_keys` | `uint` | カウント | - | | `Write_size` | `uint` | バイト | - | | `Prewrite_region` | `uint` | カウント | - | @@ -255,7 +255,7 @@ TiKVコプロセッサータスクフィールド： - ルール更新動作: `SET [SESSION|GLOBAL] tidb_slow_log_rules = '...'`の実行ごとに、既存のルールに追加するのではなく、そのスコープ内の既存のルールを上書きします。 - ルールクリア動作: `SET [SESSION|GLOBAL] tidb_slow_log_rules = ''`対応するスコープ内のルールをクリアします。 -- 現在のセッションに、 `tidb_slow_log_rules`ルール、現在の`SESSION`に対する`GLOBAL`ルール、または`Conn_ID`を含まない一般的なグローバルルールなど、適用可能な`Conn_ID`がある場合、スロークエリログの出力はルールのマッチング結果によって決定され、 `tidb_slow_log_threshold`は使用されなくなります。 +- 現在のセッションに、`SESSION`ルール、現在の`Conn_ID`に対する`GLOBAL`ルール、または`Conn_ID`を含まない一般的なグローバルルールなど、適用可能な`tidb_slow_log_rules`がある場合、スロークエリログの出力はルールのマッチング結果によって決定され、 `tidb_slow_log_threshold`は使用されなくなります。 - 現在のセッションに適用可能なルールがない場合、たとえば`SESSION`と`GLOBAL`両方のルールが空の場合、または現在の`GLOBAL`に一致しない`Conn_ID`ルールのみが構成されている場合、スロークエリのログ記録は`tidb_slow_log_threshold`に依存します。単位はミリ秒であることに注意してください。 - スローログを書き込む条件としてSQL実行時間を使用したい場合は、ルール内で`Query_time`を使用し、単位が秒であることに注意してください。 - ルールマッチングロジック： @@ -385,7 +385,7 @@ TiDB 4.0 では、 `SLOW_QUERY`は、ローテーションされたスローロ > > 指定された期間のスローログファイルが削除された場合、またはスロークエリが存在しない場合、クエリはNULLを返します。 -TiDB 4.0 では、すべての TiDB ノードのスロー クエリ情報を照会するための[`CLUSTER_SLOW_QUERY`](/information-schema/information-schema-slow-query.md#cluster_slow_query-table)システム テーブルが追加されました。 `CLUSTER_SLOW_QUERY`テーブルのテーブル スキーマは`SLOW_QUERY`に`INSTANCE`列が追加されている点で`CLUSTER_SLOW_QUERY`テーブルのスキーマとは異なります。 `INSTANCE`列は、スロー クエリの行情報の TiDB ノード アドレスを表します。 `CLUSTER_SLOW_QUERY` 、 [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md)と同様に使用できます。 +TiDB 4.0 では、すべての TiDB ノードのスロー クエリ情報を照会するための[`CLUSTER_SLOW_QUERY`](/information-schema/information-schema-slow-query.md#cluster_slow_query-table)システム テーブルが追加されました。 `CLUSTER_SLOW_QUERY`テーブルのテーブル スキーマは`CLUSTER_SLOW_QUERY`に`INSTANCE`列が追加されている点で`SLOW_QUERY`テーブルのスキーマとは異なります。 `INSTANCE`列は、スロー クエリの行情報の TiDB ノード アドレスを表します。 `CLUSTER_SLOW_QUERY` 、 [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md)と同様に使用できます。 `CLUSTER_SLOW_QUERY`テーブルに対してクエリを実行すると、TiDB は他のノードからすべてのスロークエリ情報を取得して 1 つの TiDB ノードで操作を実行するのではなく、計算と判断を他のノードにプッシュします。 @@ -613,7 +613,7 @@ ORDER BY t1.sum_query_time DESC limit 10\G ### 他のTiDBスローログファイルを解析する {#parse-other-tidb-slow-log-files} -TiDB は`tidb_slow_query_file` `INFORMATION_SCHEMA.SLOW_QUERY`を使用します。セッション変数の値を変更することで、他のスロークエリログファイルの内容をクエリできます。 +TiDB は`INFORMATION_SCHEMA.SLOW_QUERY`をクエリする際に読み取り・解析するファイルを制御するためにセッション変数`tidb_slow_query_file`を使用します。セッション変数の値を変更することで、他のスロークエリログファイルの内容をクエリできます。 ```sql set tidb_slow_query_file = "/path-to-log/tidb-slow.log" diff --git a/information-schema/information-schema-character-sets.md b/information-schema/information-schema-character-sets.md index bb83d24d15968..6d5797771e7a2 100644 --- a/information-schema/information-schema-character-sets.md +++ b/information-schema/information-schema-character-sets.md @@ -24,7 +24,7 @@ DESC CHARACTER_SETS; +----------------------+-------------+------+------+---------+-------+ 4 rows in set (0.00 sec) -`CHARACTER_SETS`テーブルをビュー: +`CHARACTER_SETS`テーブルを確認します: ```sql SELECT * FROM `CHARACTER_SETS`; diff --git a/information-schema/information-schema-collation-character-set-applicability.md b/information-schema/information-schema-collation-character-set-applicability.md index 10630ad5d9bbb..86e9e2ab7ba61 100644 --- a/information-schema/information-schema-collation-character-set-applicability.md +++ b/information-schema/information-schema-collation-character-set-applicability.md @@ -24,7 +24,7 @@ DESC COLLATION_CHARACTER_SET_APPLICABILITY; 2 rows in set (0.00 sec) ``` -`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルの`utf8mb4`の文字セットの照合順序マッピングをビュー。 +`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルの`utf8mb4`の文字セットの照合順序マッピングを確認します。 ```sql SELECT * FROM COLLATION_CHARACTER_SET_APPLICABILITY WHERE character_set_name='utf8mb4'; diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index d9096fe415df6..4e63bde1be6a3 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -26,7 +26,7 @@ DESC data_lock_waits; `DATA_LOCK_WAITS`テーブル内の各列フィールドの意味は次のとおりです。 - `KEY` : ロックを待機しているキー（16 進形式）。 -- `KEY_INFO` : `KEY`の詳細情報。4 [キー情報](#key_info)セクションを参照してください。 +- `KEY_INFO` : `KEY`の詳細情報。[キー情報](#key_info)セクションを参照してください。 - `TRX_ID` : ロックを待機しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `CURRENT_HOLDING_TRX_ID` : 現在ロックを保持しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `SQL_DIGEST` : ロック待機中のトランザクションで現在ブロックされている SQL ステートメントのダイジェスト。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index e0e94bf33d6fd..222f7cfb354dd 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -41,7 +41,7 @@ DESC deadlocks; - `CURRENT_SQL_DIGEST` : ロックを取得するトランザクションで現在実行されている SQL ステートメントのダイジェスト。 - `CURRENT_SQL_DIGEST_TEXT` : ロックを取得するトランザクションで現在実行されている SQL ステートメントの正規化された形式。 - `KEY` : トランザクションがロックしようとしたブロックされたキー。このフィールドの値は16進文字列で表示されます。 -- `KEY_INFO` : `KEY`の詳細情報。4 [`KEY_INFO`](#key_info)セクションを参照してください。 +- `KEY_INFO` : `KEY`の詳細情報。[`KEY_INFO`](#key_info)セクションを参照してください。 - `TRX_HOLDING_LOCK` : 現在キーのロックを保持し、ブロックを引き起こしているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index fe5bd8b96d4fa..e7eeb1898bb11 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -179,7 +179,7 @@ ORDER BY ratio DESC LIMIT 10; - 期間 t2 の`tib_slow_query_cop_process_total_time` (TiDB のスロークエリでの時間消費量`cop process` ) は、期間 t1 の 5,865 倍になります。 - 期間t2における`tidb_distsql_partial_scan_key_total_num` （TiDBの`distsql`が要求するスキャンキー数）は、期間t1の3,648倍です。期間t2における`tidb_slow_query_cop_wait_total_time` （コプロセッサーがTiDBのスロークエリのキューイングを要求する際の待機時間）は、期間t1の267倍です。 - 期間 t2 の`tikv_cop_total_response_size` (TiKVコプロセッサー要求結果のサイズ) は、期間 t1 の 192 倍になります。 -- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details` 、期間 t1 の 0 の 105 倍になります。 +- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 上記の結果から、期間t2のコプロセッサーリクエストが期間t1よりもはるかに多いことがわかります。これによりTiKVコプロセッサーが過負荷になり、 `cop task`待機状態になります。期間t2に大規模なクエリが発生し、負荷がさらに増加している可能性があります。 diff --git a/information-schema/information-schema-sequences.md b/information-schema/information-schema-sequences.md index 6f086c197a868..940f535f93dc0 100644 --- a/information-schema/information-schema-sequences.md +++ b/information-schema/information-schema-sequences.md @@ -5,7 +5,7 @@ summary: SEQUENCES` INFORMATION_SCHEMA テーブルについて学習します # シーケンス {#sequences} -`SEQUENCES`のテーブルはシーケンスに関する情報を提供します。3 [シーケンス機能](/sql-statements/sql-statement-create-sequence.md)テーブルは、MariaDB の同様の機能をモデルにしています。 +`SEQUENCES`のテーブルはシーケンスに関する情報を提供します。[シーケンス機能](/sql-statements/sql-statement-create-sequence.md)は、MariaDB の同様の機能をモデルにしています。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-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..960a5531bf7ed 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` * タプル内の列のストレージ長の合計。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-servers-info.md b/information-schema/information-schema-tidb-servers-info.md index c8f2006440b47..61ee5ffe7da46 100644 --- a/information-schema/information-schema-tidb-servers-info.md +++ b/information-schema/information-schema-tidb-servers-info.md @@ -35,7 +35,7 @@ DESC tidb_servers_info; 9 rows in set (0.00 sec) ``` -`TIDB_SERVERS_INFO`テーブルをビュー。 +`TIDB_SERVERS_INFO`テーブルを確認します。 ```sql SELECT * FROM TIDB_SERVERS_INFO\G diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index ca8fb447f46b6..892883766c071 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -52,7 +52,7 @@ DESC TIDB_TRX; - `SESSION_ID` : このトランザクションが属するセッションの ID。 - `USER` : トランザクションを実行するユーザーの名前。 - `DB` : トランザクションが実行されるセッションの現在のデフォルトのデータベース名。 -- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。2 [`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 +- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。[`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 - `RELATED_TABLE_IDS` : トランザクションがアクセスするテーブル、ビュー、およびその他のオブジェクトの ID。 > **Note:** @@ -64,7 +64,7 @@ DESC TIDB_TRX; ## 例 {#example} -`TIDB_TRX`テーブルをビュー: +`TIDB_TRX`テーブルを確認します: ```sql SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX\G @@ -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/latency-breakdown.md b/latency-breakdown.md index 2ddb2f94b7f4e..e6525c59cadef 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -14,7 +14,7 @@ summary: TiDB のレイテンシーと、実際の使用例でレイテンシー - [TiKVスナップショット](#tikv-snapshot) - [非同期書き込み](#async-write) -これらの分析により、 TiDB SQLクエリの実行時間コストに関する詳細な情報が得られます。これは、TiDBのクリティカルパス診断のガイドです。さらに、第[診断のユースケース](#diagnosis-use-cases)セクションでは、実際のユースケースにおけるレイテンシーの分析方法を紹介します。 +これらの分析により、 TiDB SQLクエリの実行時間コストに関する詳細な情報が得られます。これは、TiDBのクリティカルパス診断のガイドです。さらに、[診断のユースケース](#diagnosis-use-cases)セクションでは、実際のユースケースにおけるレイテンシーの分析方法を紹介します。 このドキュメントを読む前に、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md)をお読みください。レイテンシーをメトリクスに分解する際、特定のスロークエリではなく、実行時間またはレイテンシーの平均値を計算することに注意してください。多くのメトリクスは、実行時間またはレイテンシーの分布を示すヒストグラムとして表示されます。平均レイテンシーを計算するには、以下の合計とカウントのカウンタを使用する必要があります。 @@ -117,7 +117,7 @@ read handle duration = read value duration = tidb_tikvclient_rpc_net_latency_seconds{store="?"} ``` -`tidb_tikvclient_request_seconds{type="Get"}` 、バッチ処理された gRPC ラッパーを介して TiKV に直接送信される GET リクエストの継続時間を記録します`tidb_tikvclient_batch_wait_duration` 、 `tidb_tikvclient_batch_send_latency` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}`などの先行するバッチクライアントの継続時間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 +`tidb_tikvclient_request_seconds{type="Get"}`は、バッチ処理された gRPC ラッパーを介して TiKV に直接送信される GET リクエストの継続時間を記録します。`tidb_tikvclient_batch_wait_duration` 、 `tidb_tikvclient_batch_send_latency` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}`などの先行するバッチクライアントの継続時間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 `tikv_grpc_msg_duration_seconds{type="kv_get"}`期間は次のように計算されます。 @@ -247,7 +247,7 @@ tikv_grpc_msg_duration_seconds{type="coprocessor"} = req_per_copr = rate(tidb_distsql_handle_query_duration_seconds_count) / rate(tidb_distsql_scan_keys_partial_num_count) ``` -TiKVでは、テーブルスキャンタイプは`select` 、インデックススキャンタイプは`index`です。5と`select` `index`タイプの所要時間の詳細は同じです。 +TiKVでは、テーブルスキャンタイプは`select` 、インデックススキャンタイプは`index`です。`select`と`index`タイプの所要時間の詳細は同じです。 ### インデックス検索 {#index-look-up} @@ -655,7 +655,7 @@ tikv_storage_engine_async_request_duration_seconds{type="snapshot"} = get snapshot from rocksdb duration ``` -リーダー リースの有効期限が切れると、TiKV は RocksDB からスナップショットを取得する前に読み取りインデックス コマンドを提案します`tikv_raftstore_request_wait_time_duration_secs`と`tikv_raftstore_commit_log_duration_seconds`読み取りインデックス コマンドをコミットする期間です。 +リーダー リースの有効期限が切れると、TiKV は RocksDB からスナップショットを取得する前に読み取りインデックス コマンドを提案します。`tikv_raftstore_request_wait_time_duration_secs`と`tikv_raftstore_commit_log_duration_seconds`は読み取りインデックス コマンドをコミットする期間です。 RocksDB からスナップショットを取得する操作は通常は高速なので、 `get snapshot from rocksdb duration`無視されます。 @@ -757,7 +757,7 @@ async io enabled commit = max( ) ``` -v5.3.0以降、TiKVはAsync IO Raft （StoreWriterスレッドプールによるRaftログの書き込み）をサポートしています。Async IO Raftは、 [`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)正の値に設定されている場合にのみ有効になり、コミットプロセスが変更されます。3と`persist log locally duration` `wait by write worker duration`以下のように計算されます。 +v5.3.0以降、TiKVはAsync IO Raft （StoreWriterスレッドプールによるRaftログの書き込み）をサポートしています。Async IO Raftは、 [`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)が正の値に設定されている場合にのみ有効になり、コミットプロセスが変更されます。`persist log locally duration`と`wait by write worker duration`は以下のように計算されます。 ```text persist log locally duration = @@ -779,7 +779,7 @@ wait by write worker duration = 非同期IOの有無の違いは、ログがローカルに保持される期間です。非同期IOを使用する場合、ログがローカルに保持される期間は、ウォーターフォールメトリックから直接計算できます（バッチ待機時間は考慮されません）。 -レプリケートログ期間は、クォーラムピアに保持されたログの期間を記録します。これには、RPC期間と過半数に保持されたログの期間が含まれます。1は`replicate log duration`のように計算されます。 +レプリケートログ期間は、クォーラムピアに保持されたログの期間を記録します。これには、RPC期間と過半数に保持されたログの期間が含まれます。`replicate log duration`は以下のように計算されます。 ```text replicate log duration = @@ -863,7 +863,7 @@ tikv_raftstore_apply_log_duration_seconds = `SELECT`ステートメントがデータベース時間の大部分を占める場合、TiDB の読み取りクエリが遅いと想定できます。 -スロークエリの実行プランは、TiDB Dashboardの[Top SQL文](/dashboard/dashboard-overview.md#top-sql-statements)パネルに表示されます。遅い読み取りクエリの時間コストを調査するには、前述の説明に従って[PointGet](#point-get) 、および[シンプルなコプロセッサクエリ](#table-scan--index-scan) [Batch PointGet](#batch-point-get)できます。 +スロークエリの実行プランは、TiDB Dashboardの[Top SQL文](/dashboard/dashboard-overview.md#top-sql-statements)パネルに表示されます。遅い読み取りクエリの時間コストを調査するには、前述の説明に従って、[PointGet](#point-get)、[Batch PointGet](#batch-point-get)、およびいくつかの[シンプルなコプロセッサクエリ](#table-scan--index-scan)を分析できます。 ### 書き込みクエリが遅い {#slow-write-queries} @@ -872,4 +872,4 @@ tikv_raftstore_apply_log_duration_seconds = - 特定の TiKV インスタンスでこのメトリックが高い場合、ホットなリージョンで競合が発生している可能性があります。 - このメトリックがすべてのインスタンスにわたって高い場合、アプリケーションに競合が発生している可能性があります。 -アプリケーションからの競合の原因を確認した後、 [ロック](#lock)と[コミット](#commit)期間を分析することで、書き込みがスロークエリを調査できます。 +アプリケーションからの競合の原因を確認した後、 [ロック](#lock)と[コミット](#commit)期間を分析することで、遅い書き込みクエリを調査できます。 diff --git a/literal-values.md b/literal-values.md index 8ec5a4468b502..c84e0646789ef 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/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index 0d2fe0689c804..636420fc5b045 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -53,7 +53,7 @@ tiup cluster start ${cluster-name} ## クラスターのステータスを表示する {#view-the-cluster-status} -クラスターを起動したら、各コンポーネントのステータスを確認し、正常に動作していることを確認してくださいTiUPには`display`コマンドが用意されているため、コンポーネントのステータスを確認するためにすべてのマシンにログインする必要はありません。 +クラスターを起動したら、各コンポーネントのステータスを確認し、正常に動作していることを確認してください。TiUPには`display`コマンドが用意されているため、コンポーネントのステータスを確認するためにすべてのマシンにログインする必要はありません。 ```bash tiup cluster display ${cluster-name} @@ -87,7 +87,7 @@ tiup cluster display ${cluster-name} パラメータの形式については[TiUPパラメータテンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)を参照してください。 - **構成項目の階層を表すには、 . を使用します`.`** + **構成項目の階層を表すには、 `.` を使用します** コンポーネントの構成パラメータの詳細については、 [TiDB `config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example) 、 [TiKV `config.toml.example`](https://github.com/tikv/tikv/blob/release-8.5/etc/config-template.toml) 、および[PD `config.toml.example`](https://github.com/tikv/pd/blob/release-8.5/conf/config.toml)を参照してください。 diff --git a/migrate-from-mariadb.md b/migrate-from-mariadb.md index 1d2f62dfd24b5..45c456e9d58e3 100644 --- a/migrate-from-mariadb.md +++ b/migrate-from-mariadb.md @@ -150,11 +150,11 @@ GROUP BY ### 構文 {#syntax} -MariaDB は`RETURNING` 、 `DELETE` 、および`INSERT`ステートメントに対して`REPLACE`キーワードをサポートしています。TiDB はこれらをサポートしていません。移行に影響があるかどうかを確認するために、アプリケーションとクエリのログを確認することをお勧めします。 +MariaDB は`DELETE` 、 `INSERT` 、および`REPLACE`ステートメントに対して`RETURNING`キーワードをサポートしています。TiDB はこれらをサポートしていません。移行に影響があるかどうかを確認するために、アプリケーションとクエリのログを確認することをお勧めします。 ### データ型 {#data-types} -MariaDB は、 `UUID` 、 `INET4` 、 `INET6` 。 +MariaDB は、TiDB がサポートしていない `UUID` 、 `INET4` 、 `INET6` などのデータ型をサポートしています。 これらのデータ型を確認するには、次のステートメントを実行します。 @@ -186,7 +186,7 @@ WHERE TiDB は、MariaDB でよく使用される`latin1_swedish_ci`照合順序をサポートしていません。 -TiDB は、MariaDB 11.6 以降のバージョンの照合順序の照合順序である`utf8mb4_uca1400_ai_ci`サポートしていません。代わりに`utf8mb4_0900_ai_ci`を使用してください。これら 2 つの照合順序は[Unicode照合アルゴリズム（UCA）](http://www.unicode.org/reports/tr10/) : `utf8mb4_0900_ai_ci`は UCA 9.0.0 を使用し、 `utf8mb4_uca1400_ai_ci`は UCA 14.0.0 を使用します。 +TiDB は、MariaDB 11.6 以降のバージョンのデフォルトの照合順序である`utf8mb4_uca1400_ai_ci`をサポートしていません。代わりに`utf8mb4_0900_ai_ci`を使用してください。これら 2 つの照合順序は[Unicode照合アルゴリズム（UCA）](http://www.unicode.org/reports/tr10/) : `utf8mb4_0900_ai_ci`は UCA 9.0.0 を使用し、 `utf8mb4_uca1400_ai_ci`は UCA 14.0.0 を使用します。 TiDBがサポートする照合順序を確認するには、TiDBで次のステートメントを実行してください。 @@ -279,7 +279,7 @@ ORDER BY ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci 1 row in set (0.001 sec) -MariaDBには、最大キー長を超える一意インデックスに対する特別な処理機能もあります。例えば、次の例では、MariaDBは`USING HASH`列に`TEXT`一意インデックスを作成します。TiDBにはこの機能はありません。 +MariaDBには、最大キー長を超える一意インデックスに対する特別な処理機能もあります。例えば、次の例では、MariaDBは`TEXT`列に`USING HASH`一意インデックスを作成します。TiDBにはこの機能はありません。 MariaDB> CREATE TABLE t2 (id SERIAL PRIMARY KEY, c1 TEXT NOT NULL); Query OK, 0 rows affected (0.015 sec) @@ -346,7 +346,7 @@ MariaDBからTiDBへデータを移行するには、以下の手順を実行し 3. `tiup tidb-lightning`コマンドを使用してデータを復元します。 TiDB Lightning の構成方法と実行方法の詳細については、 [TiDB Lightningを使い始めよう](/get-started-with-tidb-lightning.md)を参照してください。 -4. ユーザーアカウントと権限を移行します。ユーザーと権限を移行する方法の詳細については、[輸出ユーザーと助成金](#export-users-and-grants)を参照してください。 +4. ユーザーアカウントと権限を移行します。ユーザーと権限を移行する方法の詳細については、[ユーザーと権限のエクスポート](#export-users-and-grants)を参照してください。 5. アプリケーションを再構成してください。TiDBサーバーに接続できるように、アプリケーションの設定を変更する必要があります。 @@ -384,7 +384,7 @@ MariaDBからMariaDBへのレプリケーションのように、最初に初期 ### ステップ3．ユーザーアカウントと権限を移行する {#step-3-migrate-user-accounts-and-permissions} -ユーザーと権限を移行する方法については[輸出ユーザーと助成金](#export-users-and-grants)を参照してください。 +ユーザーと権限を移行する方法については[ユーザーと権限のエクスポート](#export-users-and-grants)を参照してください。 ### ステップ4．データをテストする {#step-4-test-your-data} @@ -404,7 +404,7 @@ TiDBに切り替えるには、以下の手順を実行する必要がありま 移行が成功したことを確認したら、MariaDB のデータの最終バックアップを作成し、サーバーを停止できます。これにより、DM クラスターを停止して削除することもできます。 -## 輸出ユーザーと助成金 {#export-users-and-grants} +## ユーザーと権限のエクスポート {#export-users-and-grants} [`pt-show-grants`](https://docs.percona.com/percona-toolkit/pt-show-grants.html)を使用できます。これは Percona Toolkit の一部で、MariaDB からユーザーと権限をエクスポートし、TiDB にロードするために使用されます。 diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index ca1bc3ca5343c..a01ecefdca653 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/migrate-from-vitess.md b/migrate-from-vitess.md index 0d208f76c9b81..2e4ad2d2af018 100644 --- a/migrate-from-vitess.md +++ b/migrate-from-vitess.md @@ -7,9 +7,9 @@ summary: Vitess から TiDB にデータを移行するためのツールにつ このドキュメントでは、 [Vitess](https://vitess.io/)から TiDB にデータを移行するために使用できるツールについて説明します。 -VitessのバックエンドはMySQLベースであるため、VitessからTiDBにデータを移行する際には、MySQLに適用できるものと同じ移行ツール[TiDB Data Migration (DM)](/dm/dm-overview.md) [Dumpling](/dumpling-overview.md)など[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用できます。これらのツールは、データ移行のためにVitess内の各シャードに対して設定する必要があることに注意してください。 +VitessのバックエンドはMySQLベースであるため、VitessからTiDBにデータを移行する際には、MySQLに適用できるものと[Dumpling](/dumpling-overview.md)、[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)、[TiDB Data Migration (DM)](/dm/dm-overview.md)などの同じ移行ツールを使用できます。これらのツールは、データ移行のためにVitess内の各シャードに対して設定する必要があることに注意してください。 -通常、データ移行前にDMタスクを`task-mode` ～ `all` ～ `physical`に設定することを推奨します。詳細については、 [タスク構成ファイルテンプレート（上級）](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) `import-mode`してください。 +通常、データ移行前にDMタスクの`task-mode`を`all`に、`import-mode`を`physical`に設定することを推奨します。詳細については、 [タスク構成ファイルテンプレート（上級）](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)を参照してください。 データ サイズが 10 TiB を超える場合は、2 つの手順でインポートを実行することをお勧めします。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index d366feffd5f09..f2ad72ed41c22 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -204,7 +204,7 @@ CREATE TABLE `table5` ( 3. 移行タスクを開始した後、以下のいずれかの方法で進捗状況を確認できます。 - `grep`ツールを使用して、ログファイル内でキーワード`progress`を検索してください。デフォルトでは、進行状況を報告するメッセージが5分ごとにログファイルに書き込まれます。 - - 監視ダッシュボードから進捗状況をビュー。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 + - 監視ダッシュボードから進捗状況を確認します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index b19f45cbf1e21..3067cca213aa8 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -94,7 +94,7 @@ LIMIT `${data-path}`には、エクスポートされたすべての上流テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 -2. `metadata`ディレクトリにある`${data-path}`ファイルをビュー。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 +2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 SHOW MASTER STATUS: Log: mysql-bin.000004 diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 1ba28267ff3e1..3042179c9804c 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -15,14 +15,14 @@ summary: シャードの小さなデータセットを MySQL から TiDB に移 | スキーマ | テーブル | | :----- | :------------ | -| ストア_01 | セール_01、セール_02 | -| ストア_02 | セール_01、セール_02 | +| store_01 | sale_01, sale_02 | +| store_02 | sale_01, sale_02 | ターゲット スキーマとテーブル: | スキーマ | テーブル | | :--- | :--- | -| 店 | 販売 | +| store | sale | ## 前提条件 {#prerequisites} diff --git a/migration-tools.md b/migration-tools.md index 09b9663ce54c7..7fabd4c68ead0 100644 --- a/migration-tools.md +++ b/migration-tools.md @@ -35,7 +35,7 @@ TiDB は、完全なデータ移行、増分データ移行、バックアップ - **下流**：TiDB - **利点**： - 大量のデータを迅速にインポートし、TiDB クラスタ内の特定のテーブルを迅速に初期化することをサポートします。 - - インポートの進行状況を保存するチェックポイントをサポートし、再起動後に中断したところからインポートを続行します`tidb-lightning` + - インポートの進行状況を保存するチェックポイントをサポートし、再起動後、`tidb-lightning`は中断したところからインポートを続行します - データフィルタリングをサポート - **制限事項**： - データのインポートに[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md)を使用すると、インポート プロセス中に TiDB クラスターはサービスを提供できません。 diff --git a/minimal-deployment-topology.md b/minimal-deployment-topology.md index 79ddbf414f1dc..21c17f0be7499 100644 --- a/minimal-deployment-topology.md +++ b/minimal-deployment-topology.md @@ -23,11 +23,11 @@ summary: TiDB クラスターの最小限のデプロイメント トポロジ ### トポロジテンプレート {#topology-templates} - [最小トポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml) -- [最小位相の複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) +- [最小トポロジーの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) 上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUP クラスターコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 > - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 5fc1a9df10c1e..e7fb069e189f5 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -21,8 +21,8 @@ summary: 1 つのリージョン内の複数の可用性ゾーンへのデプロ Raftは分散コンセンサスアルゴリズムです。このアルゴリズムを使用することで、TiDBクラスタのコンポーネント間でPDとTiKVの両方がデータの災害復旧を実現します。これは以下のメカニズムを通じて実現されます。 -- Raftメンバーの本質的な役割は、ログの複製を実行し、状態マシンとして機能することです。Raftメンバー間では、ログを複製することでデータの複製が実現されます。RaftRaftは、さまざまな状況に応じて自身の状態を変化させ、サービスを提供するリーダーを選出します。 -- RaftはRaftプロトコルに従う投票システムです。Raftグループでは、メンバーが過半数の票を獲得すると、そのメンバーはリーダーに昇格します。つまり、 Raftグループに過半数のノードが残っている場合、サービスを提供するリーダーが選出されます。 +- Raftメンバーの本質的な役割は、ログの複製を実行し、状態マシンとして機能することです。Raftメンバー間では、ログを複製することでデータの複製が実現されます。Raftは、さまざまな状況に応じて自身の状態を変化させ、サービスを提供するリーダーを選出します。 +- Raftは多数決プロトコルに従う投票システムです。Raftグループでは、メンバーが過半数の票を獲得すると、そのメンバーはリーダーに昇格します。つまり、 Raftグループに過半数のノードが残っている場合、サービスを提供するリーダーが選出されます。 Raft の信頼性を活用するには、実際の展開シナリオで次の条件を満たす必要があります。 @@ -161,7 +161,7 @@ tikv_servers: 上記の例では、 `zone`レプリカの分離を制御する論理可用性ゾーンレイヤーです (サンプル クラスターには 3 つのレプリカがあります)。 -将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`スケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 +将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`をスケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 この 3 層のラベル構造をそのまま採用すると、AZ をスケールアウトした後に、新しいラベルを適用し、TiKV 内のデータを再調整する必要がある場合があります。 diff --git a/non-transactional-dml.md b/non-transactional-dml.md index 5c129dfd6301b..c9d4812fd89b3 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -9,7 +9,7 @@ summary: TiDBの非トランザクションDMLステートメントについて 非トランザクションDML文とは、複数のSQL文（つまり複数のバッチ）に分割され、順番に実行されるDML文です。トランザクションの原子性と独立性を犠牲にして、バッチデータ処理のパフォーマンスと使いやすさを向上させます。 -通常、メモリを大量に消費するトランザクションは、トランザクションサイズ制限を回避するために複数のSQL文に分割する必要があります。非トランザクションDML文は、このプロセスをTiDBカーネルに統合することで、同じ効果を実現します。SQL文を分割することで、非トランザクションDML文の効果を理解するのに役立ちます`DRY RUN`構文を使用すると、分割された文をプレビューできます。 +通常、メモリを大量に消費するトランザクションは、トランザクションサイズ制限を回避するために複数のSQL文に分割する必要があります。非トランザクションDML文は、このプロセスをTiDBカーネルに統合することで、同じ効果を実現します。SQL文を分割することで、非トランザクションDML文の効果を理解するのに役立ちます。`DRY RUN`構文を使用すると、分割された文をプレビューできます。 非トランザクション DML ステートメントには次のものがあります。 @@ -34,7 +34,7 @@ summary: TiDBの非トランザクションDMLステートメントについて 非トランザクションDMLステートメントは、特定のシナリオにおいて、大規模トランザクションのサイズ制限を回避するために使用されます。手動でトランザクションを分割する必要があるタスクを1つのステートメントで完了することで、実行効率が向上し、リソース消費が削減されます。 -たとえば、期限切れのデータを削除する場合、期限切れのデータにアクセスするアプリケーションがないことを確認すると、非トランザクション DML ステートメントを使用して`DELETE`を向上させることができます。 +たとえば、期限切れのデータを削除する場合、期限切れのデータにアクセスするアプリケーションがないことを確認すると、非トランザクション DML ステートメントを使用して`DELETE`のパフォーマンスを向上させることができます。 ## 前提条件 {#prerequisites} @@ -232,7 +232,7 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 非トランザクション DML ステートメントを使用するには、次の手順をお勧めします。 -1. 適切な[破片の列](#parameter-description)を選択します。整数型または文字列型が推奨されます。 +1. 適切な[シャード列](#parameter-description)を選択します。整数型または文字列型が推奨されます。 2. 非トランザクション DML 文に`DRY RUN QUERY`追加し、クエリを手動で実行して、DML 文の影響を受けるデータ範囲がおおよそ正しいかどうかを確認します。 @@ -313,7 +313,7 @@ batch-dml は、DML ステートメントの実行中にトランザクション 非トランザクションDML文は、まだすべてのバッチDML使用シナリオの代替となるわけではありません。主な違いは次のとおりです。 -- パフォーマンス: [破片の列](#how-to-select-a-shard-column)が効率的な場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLのパフォーマンスに近づきます。シャード列の効率が低い場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLよりも大幅に低下します。 +- パフォーマンス: [シャード列](#how-to-select-a-shard-column)が効率的な場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLのパフォーマンスに近づきます。シャード列の効率が低い場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLよりも大幅に低下します。 - 安定性：batch-dmlは、不適切な使用によりデータインデックスの不整合が発生しやすい傾向があります。非トランザクションDML文はデータインデックスの不整合を引き起こしません。ただし、不適切に使用された場合、非トランザクションDML文は元の文と同等ではなくなり、アプリケーションで予期しない動作が発生する可能性があります。詳細は[よくある問題のセクション](#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete)を参照してください。 @@ -321,7 +321,7 @@ batch-dml は、DML ステートメントの実行中にトランザクション ### 複数のテーブル結合ステートメントを実行するとUnknown column xxx in 'where clause'エラーが発生します。 {#executing-a-multiple-table-joins-statement-results-in-the-code-unknown-column-xxx-in-where-clause-code-error} -このエラーは、クエリ内で連結された`WHERE`句が、 [破片の列](#parameter-description)が定義されているテーブル以外のテーブルに関係する場合に発生します。例えば、次のSQL文では、シャード列は`t2.id`で、テーブル`t2`に定義されていますが、 `WHERE`句はテーブル`t2`と`t3`に関係しています。 +このエラーは、クエリ内で連結された`WHERE`句が、 [シャード列](#parameter-description)が定義されているテーブル以外のテーブルに関係する場合に発生します。例えば、次のSQL文では、シャード列は`t2.id`で、テーブル`t2`に定義されていますが、 `WHERE`句はテーブル`t2`と`t3`に関係しています。 ```sql BATCH ON test.t2.id LIMIT 1 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index a2b0b9eb9fee0..fa0147416016f 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -95,7 +95,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `OFF` - 可能`OFF`値: `ON` -- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`無効にするかどうかを制御します。デフォルト値`OFF` 、演算子`Point Get`と`Batch Point Get`クエリ実行に使用できることを意味します。11 `ON`設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`無効にし、クエリ実行にコプロセッサーを強制的に選択します。 +- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`を無効にするかどうかを制御します。デフォルト値`OFF`は、演算子`Point Get`と`Batch Point Get`をクエリ実行に使用できることを意味します。`ON`に設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`を無効にし、クエリ実行にコプロセッサーを強制的に選択します。 - `Point Get`と`Batch Point Get`列投影をサポートしていません（つまり、列のサブセットのみを返すことはできません）。そのため、シナリオによっては、実行効率がコプロセッサーよりも低くなる可能性があります。この変数を`ON`に設定すると、クエリのパフォーマンスが向上します。この変数を`ON`に設定する推奨シナリオは次のとおりです。 - 多数の列を持つ幅の広いテーブルで、少数の列のみがクエリされます。 diff --git a/optimizer-hints.md b/optimizer-hints.md index ed292879f62f8..41d72ed84390a 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -27,7 +27,7 @@ SELECT /*+ USE_INDEX(t1, idx1), HASH_AGG(), HASH_JOIN(t1) */ count(*) FROM t t1, > > 指定されたキーワードの後にコメントが続かない場合、一般的なMySQLコメントとして扱われます。コメントは有効にならず、警告も表示されません。 -現在、TiDBは2つのカテゴリのヒントをサポートしており、それぞれスコープが異なります。最初のカテゴリのヒントはクエリブロックのスコープ（例： [`/*+ HASH_AGG() */`](#hash_agg) ）で有効になり、2番目のカテゴリのヒントはクエリ全体（例： [`/*+ MEMORY_QUOTA(1024 MB)*/`](#memory_quotan)で有効になります。 +現在、TiDBは2つのカテゴリのヒントをサポートしており、それぞれスコープが異なります。最初のカテゴリのヒントはクエリブロックのスコープ（例： [`/*+ HASH_AGG() */`](#hash_agg) ）で有効になり、2番目のカテゴリのヒントはクエリ全体（例： [`/*+ MEMORY_QUOTA(1024 MB)*/`](#memory_quotan) ）で有効になります。 ステートメント内の各クエリまたはサブクエリは異なるクエリブロックに対応し、各クエリブロックには独自の名前が付けられます。例: @@ -35,7 +35,7 @@ SELECT /*+ USE_INDEX(t1, idx1), HASH_AGG(), HASH_JOIN(t1) */ count(*) FROM t t1, SELECT * FROM (SELECT * FROM t) t1, (SELECT * FROM t) t2; ``` -上記のクエリ文には3つのクエリブロックがあります。最も外側の`SELECT`最初のクエリブロック（名前は`sel_1`に対応します。2つの`SELECT`サブクエリは2番目と3番目のクエリブロック（名前はそれぞれ`sel_2`と`sel_3`に対応します。番号の順序は、左から右への`SELECT`の出現に基づいています。最初の`SELECT` `DELETE`または`UPDATE`に置き換えると、対応するクエリブロック名は`del_1`または`upd_1`になります。 +上記のクエリ文には3つのクエリブロックがあります。最も外側の`SELECT`は最初のクエリブロック（名前は`sel_1`）に対応します。2つの`SELECT`サブクエリは2番目と3番目のクエリブロック（名前はそれぞれ`sel_2`と`sel_3`）に対応します。番号の順序は、左から右への`SELECT`の出現に基づいています。最初の`SELECT`を`DELETE`または`UPDATE`に置き換えると、対応するクエリブロック名は`del_1`または`upd_1`になります。 ## クエリブロックで有効になるヒント {#hints-that-take-effect-in-query-blocks} @@ -72,7 +72,7 @@ SELECT /*+ QB_NAME(QB1) */ * FROM (SELECT * FROM t) t1, (SELECT * FROM t) t2; > **Note:** > -> 上記の例では、ヒントが`QB_NAME`から`sel_2`を指定し、元の 2 番目のクエリ ブロック`SELECT`に新しい`QB_NAME`を指定していない場合、2 番目のクエリ ブロック`SELECT`に対して`sel_2`が無効な名前になります。 +> 上記の例では、ヒントが`QB_NAME`を`sel_2`に指定し、元の 2 番目のクエリ ブロック`SELECT`に新しい`QB_NAME`を指定していない場合、2 番目のクエリ ブロック`SELECT`に対して`sel_2`は無効な名前になります。 ### MERGE_JOIN(t1_name [, tl_name ...]) {#merge-join-t1-name-tl-name} @@ -100,7 +100,7 @@ SELECT /*+ NO_MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > > 場合によっては、 `INL_JOIN`ヒントが効かないことがあります。詳しくは[`INL_JOIN`ヒントは有効になりません](#inl_join-hint-does-not-take-effect)を参照してください。 -ヒント`INL_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックス・ネストループ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムは、状況によってはシステムリソースの消費量が少なく、処理時間も短縮される可能性がありますが、状況によっては逆の結果になることもあります。外部テーブルがヒント`WHERE`でフィルタリングされた後、結果セットが10,000行未満の場合、このヒントを使用することをお勧めします。例： +ヒント`INL_JOIN(t1_name [, tl_name ...])`は、指定されたテーブルに対してインデックス・ネストループ結合アルゴリズムを使用するようオプティマイザに指示します。このアルゴリズムは、状況によってはシステムリソースの消費量が少なく、処理時間も短縮される可能性がありますが、状況によっては逆の結果になることもあります。外部テーブルが`WHERE`条件でフィルタリングされた後、結果セットが10,000行未満の場合、このヒントを使用することをお勧めします。例： ```sql SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id; @@ -254,7 +254,7 @@ SELECT /*+ BROADCAST_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; このヒントがクエリ ブロック内で使用される場合、オプティマイザーはサブクエリとその外側のクエリ ブロック間の相関列の非相関化を試行せず、常に Apply 演算子を使用してクエリを実行します。 -デフォルトでは、TiDBは相関サブクエリに対して[相関除去を実行する](/correlated-subquery-optimization.md)適用することで実行効率を高めようとします。しかし、 [いくつかのシナリオ](/correlated-subquery-optimization.md#restrictions)では、相関除去によって実行効率が低下する可能性があります。このような場合は、このヒントを使用してオプティマイザに相関除去を行わないよう手動で指示することができます。例えば、次のようになります。 +デフォルトでは、TiDBは相関サブクエリに対して[相関除去を実行する](/correlated-subquery-optimization.md)ことで実行効率を高めようとします。しかし、 [いくつかのシナリオ](/correlated-subquery-optimization.md#restrictions)では、相関除去によって実行効率が低下する可能性があります。このような場合は、このヒントを使用してオプティマイザに相関除去を行わないよう手動で指示することができます。例えば、次のようになります。 ```sql create table t1(a int, b int); @@ -350,7 +350,7 @@ SELECT /*+ MPP_2PHASE_AGG() */ COUNT(*) FROM t1, t2 WHERE t1.a > 10 GROUP BY t1. ### USE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#use-index-t1-name-idx1-name-idx2-name} -`USE_INDEX(t1_name, idx1_name [, idx2_name ...])`のヒントは、指定された`t1_name`番目のテーブルに対して、指定されたインデックスのみを使用するようにオプティマイザに指示します。例えば、次のヒントを適用すると、 `select * from t t1 use index(idx1, idx2);`番目の文を実行するのと同じ効果が得られます。 +`USE_INDEX(t1_name, idx1_name [, idx2_name ...])`のヒントは、指定された`t1_name`テーブルに対して、指定されたインデックスのみを使用するようにオプティマイザに指示します。例えば、次のヒントを適用すると、 `select * from t t1 use index(idx1, idx2);`文を実行するのと同じ効果が得られます。 ```sql SELECT /*+ USE_INDEX(t1, idx1, idx2) */ * FROM t1; @@ -377,7 +377,7 @@ SELECT * FROM t force index(idx1); ### IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#ignore-index-t1-name-idx1-name-idx2-name} -`IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...])`ヒントは、指定された`t1_name`番目のテーブルの指定されたインデックスを無視するようにオプティマイザに指示します。例えば、次のヒントを適用すると、 `select * from t t1 ignore index(idx1, idx2);`番目の文を実行するのと同じ効果が得られます。 +`IGNORE_INDEX(t1_name, idx1_name [, idx2_name ...])`ヒントは、指定された`t1_name`テーブルの指定されたインデックスを無視するようにオプティマイザに指示します。例えば、次のヒントを適用すると、 `select * from t t1 ignore index(idx1, idx2);`文を実行するのと同じ効果が得られます。 ```sql select /*+ IGNORE_INDEX(t1, idx1, idx2) */ * from t t1; @@ -409,7 +409,7 @@ EXPLAIN SELECT /*+ ORDER_INDEX(t, a) */ a FROM t ORDER BY a LIMIT 10; +----------------------------+---------+-----------+---------------------+-------------------------------+ ``` -オプティマイザはこのクエリに対して2種類のプラン（ `Limit + IndexScan(keep order: true)`と`TopN + IndexScan(keep order: false)` ）を生成します。5ヒント`ORDER_INDEX`使用される場合、オプティマイザはインデックスを順番に読み取る最初のプランを選択します。 +オプティマイザはこのクエリに対して2種類のプラン（ `Limit + IndexScan(keep order: true)`と`TopN + IndexScan(keep order: false)` ）を生成します。`ORDER_INDEX`ヒントが使用される場合、オプティマイザはインデックスを順番に読み取る最初のプランを選択します。 > **Note:** > @@ -577,7 +577,7 @@ SHOW WARNINGS; > > クエリ文に外部結合が含まれている場合、ヒントには結合順序を入れ替え可能なテーブルのみを指定できます。ヒントに結合順序を入れ替えられないテーブルが含まれている場合、ヒントは無効になります。例えば、 `SELECT * FROM t1 LEFT JOIN (t2 JOIN t3 JOIN t4) ON t1.a = t2.a;`で`t2` `t3` `t4`テーブルの結合順序を制御したい場合、 `LEADING`のヒントに`t1`を指定することはできません。 -### マージ（） {#merge} +### MERGE() {#merge} 共通テーブル式（CTE）を含むクエリでヒント`MERGE()`を使用すると、サブクエリのマテリアライゼーションを無効にし、サブクエリをCTEにインライン展開できます。このヒントは非再帰CTEにのみ適用されます。シナリオによっては、 `MERGE()`を使用すると、一時領域を割り当てるデフォルトの動作よりも実行効率が向上します。例えば、クエリ条件のプッシュダウンやCTEクエリのネストなどです。 @@ -598,7 +598,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > > CTE 参照の数が多すぎると、クエリのパフォーマンスがデフォルトのマテリアライゼーション動作よりも低下する可能性があります。 -## 世界中で効果を発揮するヒント {#hints-that-take-effect-globally} +## グローバルに効果を発揮するヒント {#hints-that-take-effect-globally} グローバルヒントは[ビュー](/views.md)で機能します。グローバルヒントとして指定すると、クエリで定義されたヒントがビュー内で有効になります。グローバルヒントを指定するには、まず`QB_NAME`ヒントを使用してクエリブロック名を定義し、次に`ViewName@QueryBlockName`の形式で対象のヒントを追加します。 @@ -655,7 +655,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > **Note:** > -> - ビューでグローバルヒントを使用するには、対応するヒントをビューに`QB_NAME`定義する必要があります。そうしないと、グローバルヒントは有効になりません。 +> - ビューでグローバルヒントを使用するには、対応する`QB_NAME`ヒントをビューに定義する必要があります。そうしないと、グローバルヒントは有効になりません。 > > - ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリ ブロック内にあることを確認する必要があります。 > @@ -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`対応する結合および集計操作に変換します。 @@ -813,7 +813,7 @@ SELECT @@MAX_EXECUTION_TIME; ### ストレート結合() {#straight-join} -`STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`番目の句のテーブル名の順序でテーブルを結合するようにオプティマイザーに通知します。 +`STRAIGHT_JOIN()`ヒントは、結合プランを生成するときに、 `FROM`句のテーブル名の順序でテーブルを結合するようにオプティマイザーに通知します。 ```sql SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; @@ -844,7 +844,7 @@ SELECT /*+ NTH_PLAN(3) */ count(*) from t where a > 5; ### RESOURCE_GROUP(リソースグループ名) {#resource-group-resource-group-name} -`RESOURCE_GROUP(resource_group_name)`は[リソース管理](/tidb-resource-control-ru-groups.md)代わりにリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。 +`RESOURCE_GROUP(resource_group_name)`は、[リソース管理](/tidb-resource-control-ru-groups.md)でリソースを分離するために使用されます。このヒントは、指定されたリソースグループを使用して現在のステートメントを一時的に実行します。指定されたリソースグループが存在しない場合、このヒントは無視されます。 例： @@ -930,7 +930,7 @@ SHOW WARNINGS; 1 row in set (0.01 sec) ``` -この場合、ヒントは`SELECT`キーワードの直後に配置する必要があります。詳細については、 [構文](#syntax)番目のセクションをご覧ください。 +この場合、ヒントは`SELECT`キーワードの直後に配置する必要があります。詳細については、 [構文](#syntax)セクションをご覧ください。 ### INL_JOINヒントは有効になりません {#code-inl-join-code-hint-does-not-take-effect} diff --git a/oracle-functions-to-tidb.md b/oracle-functions-to-tidb.md index 410015b22c7ef..654a3006d8a30 100644 --- a/oracle-functions-to-tidb.md +++ b/oracle-functions-to-tidb.md @@ -17,7 +17,7 @@ summary: Oracle と TiDB の関数と構文の比較を学習します。 | 関数 | Oracle構文 | TiDB構文 | 注記 | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 値を特定の型にキャストする |
  • `TO_NUMBER(key)`
  • `TO_CHAR(key)`
    • | `CONVERT(key,dataType)` | TiDB は、値を`BINARY` 、 `CHAR` 、 `DATE` 、 `DATETIME` 、 `TIME` 、 11 、 `SIGNED INTEGER` `UNSIGNED INTEGER` `DECIMAL`のいずれかの型にキャストすることをサポートしています。 | +| 値を特定の型にキャストする |
  • `TO_NUMBER(key)`
  • `TO_CHAR(key)`
    • | `CONVERT(key,dataType)` | TiDB は、値を`BINARY` 、 `CHAR` 、 `DATE` 、 `DATETIME` 、 `TIME` 、 `SIGNED INTEGER` `UNSIGNED INTEGER` `DECIMAL`のいずれかの型にキャストすることをサポートしています。 | | 日付を文字列に変換する |
  • `TO_CHAR(SYSDATE,'yyyy-MM-dd hh24:mi:ss')`
  • `TO_CHAR(SYSDATE,'yyyy-MM-dd')`
    • |
  • `DATE_FORMAT(NOW(),'%Y-%m-%d %H:%i:%s')`
  • `DATE_FORMAT(NOW(),'%Y-%m-%d')`
    • | TiDB のフォーマット文字列では大文字と小文字が区別されます。 | | 文字列を日付に変換する |
  • `TO_DATE('2021-05-28 17:31:37','yyyy-MM-dd hh24:mi:ss')`
  • `TO_DATE('2021-05-28','yyyy-MM-dd hh24:mi:ss')`
    • |
  • `STR_TO_DATE('2021-05-28 17:31:37','%Y-%m-%d %H:%i:%s')`
  • `STR_TO_DATE('2021-05-28','%Y-%m-%d%T')`
    • | TiDB のフォーマット文字列では大文字と小文字が区別されます。 | | 現在のシステム時間を秒精度で取得する | `SYSDATE` | `NOW()` | | diff --git a/partition-pruning.md b/partition-pruning.md index 4be477dbb3ce4..c854fda638308 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -226,7 +226,7 @@ explain select * from t where x between 7 and 14; - [`UNIX_TIMESTAMP()`](/functions-and-operators/date-and-time-functions.md) - [`TO_DAYS()`](/functions-and-operators/date-and-time-functions.md) -- [`EXTRACT(<time unit> FROM <DATETIME/DATE/TIME column>)`](/functions-and-operators/date-and-time-functions.md) 。2列および`DATE` `DATETIME`の場合、 `YEAR`および`YEAR_MONTH`時間単位は単調関数とみなされます。10 `TIME`の場合、 `HOUR` 、および`HOUR_SECOND` `HOUR_MICROSECOND`単調関数とみなされます。パーティションプルーニングでは、 `EXTRACT`では`WEEK`時間単位としてサポートされていないこと`HOUR_MINUTE`注意してください。 +- [`EXTRACT(<time unit> FROM <DATETIME/DATE/TIME column>)`](/functions-and-operators/date-and-time-functions.md) 。`DATE`列および`DATETIME`列の場合、 `YEAR`および`YEAR_MONTH`時間単位は単調関数とみなされます。`TIME`列の場合、 `HOUR` 、 `HOUR_MINUTE` 、 `HOUR_SECOND` 、および`HOUR_MICROSECOND`は単調関数とみなされます。パーティションプルーニングでは、 `EXTRACT`で`WEEK`は時間単位としてサポートされていないことに注意してください。 たとえば、パーティション プルーニングは、パーティション式が`fn(col)`形式 ( `fn`は単調関数`to_days`の場合に有効になります。 diff --git a/password-management.md b/password-management.md index b671404d8e1ed..09f695a1f8eba 100644 --- a/password-management.md +++ b/password-management.md @@ -218,7 +218,7 @@ mysql> SELECT user,password_expired,Account_locked FROM mysql.user WHERE user = TiDB は、グローバル レベルとアカウント レベルでの自動パスワード有効期限をサポートします。 -- 世界レベル +- グローバルレベル システム変数[`default_password_lifetime`](/system-variables.md#default_password_lifetime-new-in-v650)を設定することで、パスワードの有効期間を制御できます。デフォルト値`0` 、パスワードが無期限であることを示します。このシステム変数を正の整数`N`に設定すると、パスワードの有効期間は`N`日間となり、 `N`日ごとにパスワードを変更する必要があります。 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index e09ce09ef1b24..0ce07f5d24547 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -379,7 +379,7 @@ pd-server関連のコンフィグレーション項目 ### `affinity-schedule-limit` v8.5.5 の新機能 {#affinity-schedule-limit-new-in-v855} -- 同時に実行できる[親和性](/table-affinity.md)スケジュールタスクの数を制御します。3に設定すると`0`アフィニティスケジュールが無効になります。 +- 同時に実行できる[親和性](/table-affinity.md)スケジュールタスクの数を制御します。`0`に設定すると、アフィニティスケジュールが無効になります。 - デフォルト値: `0` ### `high-space-ratio` {#high-space-ratio} @@ -550,7 +550,7 @@ pd-server関連のコンフィグレーション項目 ## controller {#controller} -このセクションでは、 PD for [リソース管理](/tidb-resource-control-ru-groups.md)に組み込まれている構成項目について説明します。 +このセクションでは、 [リソース管理](/tidb-resource-control-ru-groups.md)のためにPDに組み込まれている構成項目について説明します。 ### `degraded-mode-wait-duration` {#degraded-mode-wait-duration} diff --git a/pd-control.md b/pd-control.md index 476d33d11030e..7fd87518b87a8 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 の移行機能を有効にするために使用されます。`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はスケジュール設定によってリージョンレプリカの分離レベルを上げません。 @@ -335,7 +335,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `store-limit-mode`はストア速度を制限するモードを制御するために使用されます。オプションのモードは`auto`と`manual`です。`auto`では、ストアは負荷に応じて自動的にバランス調整されます（非推奨）。 -- `store-limit-version`ストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいて 4 の値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 +- `store-limit-version`はストア制限の計算式のバージョンを制御します。v1 モードでは、 `store limit`を手動で変更することで、単一の TiKV のスケジュール速度を制限できます。v2 モードでは、PD が TiKV スナップショットの機能に基づいてその値を動的に調整するため、 `store limit`値を手動で設定する必要はありません。詳細については、 [ストア制限の原則 v2](/configure-store-limit.md#principles-of-store-limit-v2)を参照してください。 ```bash config set store-limit-version v2 // using store limit v2 @@ -760,7 +760,7 @@ time: 43.12698ms このコマンドを使用して、指定された範囲`[startkey, endkey)`内のすべてのリージョンを照会します。 `endKey`のない範囲もサポートされています。 -パラメータ`limit`はキーの数を制限します。デフォルト値は`limit`で`16` 、値`-1`はキーの数を無制限にすることを意味します。 +パラメータ`limit`はキーの数を制限します。`limit`のデフォルト値は`16`で、値`-1`はキーの数を無制限にすることを意味します。 使用法： @@ -881,9 +881,9 @@ time: 43.12698ms 各種タイプの説明: -- ミスピア: 十分なレプリカがないリージョン +- miss-peer: 十分なレプリカがないリージョン - extra-peer: 追加のレプリカを持つリージョン -- ダウンピア: 一部のレプリカがダウンしているリージョン +- down-peer: 一部のレプリカがダウンしているリージョン - pending-peer: レプリカが保留中のリージョン 使用法： @@ -981,7 +981,7 @@ v6.2.0以降、TiKVはPDにストアハートビートスコア`SlowScore`を報 #### 低速ネットワークノード {#slow-network-nodes} -v8.5.5以降、TiKVはストア内の`NetworkSlowScore`ビートをPDに報告する機能をサポートします。これはネットワーク検出結果に基づいて計算され、ネットワークジッターが発生している低速ノードを特定するのに役立ちます。スコアの範囲は1～100で、値が高いほどネットワーク異常の可能性が高くなります。 +v8.5.5以降、TiKVはストアハートビートで`NetworkSlowScore`をPDに報告する機能をサポートします。これはネットワーク検出結果に基づいて計算され、ネットワークジッターが発生している低速ノードを特定するのに役立ちます。スコアの範囲は1～100で、値が高いほどネットワーク異常の可能性が高くなります。 - TiKVはデフォルトで低速ネットワークノードの検出を有効にし、デフォルトのプロービング間隔は`100ms`です。プロービング頻度を変更するには、TiKV設定項目[`raftstore.inspect-network-interval`](/tikv-configuration-file.md#inspect-network-interval-new-in-v855)を適切な値に設定します。値を小さくするとプロービング頻度が増加し、ネットワークジッターの検出速度が向上しますが、ネットワークリソースとCPUリソースの消費量も増加します。 @@ -1009,7 +1009,7 @@ v8.5.5以降、TiKVはストア内の`NetworkSlowScore`ビートをPDに報告 このコマンドを使用して、 `balance-leader-scheduler`ポリシーを表示および制御します。 -TiDB v6.0.0以降、PDはバランスリーダーがタスクを処理する速度を制御するためのパラメータ`Batch` （ `balance-leader-scheduler`を導入しました。このパラメータを使用するには、pd-ctlを使用して設定項目`balance-leader batch`を変更します。 +TiDB v6.0.0以降、PDはバランスリーダーがタスクを処理する速度を制御するための`balance-leader-scheduler`のパラメータ`Batch`を導入しました。このパラメータを使用するには、pd-ctlを使用して設定項目`balance-leader batch`を変更します。 v6.0.0より前のPDにはこの設定項目がないため、 `balance-leader batch=1`なります。v6.0.0以降のバージョンでは、 `balance-leader batch`のデフォルト値は`4`です。この設定項目を`4`より大きい値に設定するには、同時に[`scheduler-max-waiting-operator`](#config-show--set-option-value--placement-rules) （デフォルト値は`5` ）にもより大きな値を設定する必要があります。両方の設定項目を変更することで、期待される高速化効果が得られます。 @@ -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 @@ -1268,7 +1268,7 @@ store remove-tombstone > **Note:** > -> - ストアのラベルはマージ戦略によって更新されます。TiKVプロセスが再起動されると、その設定ファイル内のストアラベルはPDに保存されているストアラベルとマージされ、マージされた結果が保持されます。マージプロセス中に、PD側とTiKV設定ファイルの間で重複するストアラベルが存在する場合、TiKVストアラベル設定によってPDラベルが上書きされます。例えば、ストア1のストアラベルが`"zone=cn"` ～ `store label 1 zone=cn`に設定されているのに、TiKV設定ファイルに`zone = "us"`設定されている場合、TiKVの再起動後に`"zone"`が`"us"`に更新されます。 +> - ストアのラベルはマージ戦略によって更新されます。TiKVプロセスが再起動されると、その設定ファイル内のストアラベルはPDに保存されているストアラベルとマージされ、マージされた結果が保持されます。マージプロセス中に、PD側とTiKV設定ファイルの間で重複するストアラベルが存在する場合、TiKVストアラベル設定によってPDラベルが上書きされます。例えば、ストア1のストアラベルが`store label 1 zone=cn`によって`"zone=cn"`に設定されているのに、TiKV設定ファイルに`zone = "us"`と設定されている場合、TiKVの再起動後に`"zone"`が`"us"`に更新されます。 > - TiUPを使用してストアのラベルを管理するには、クラスターを再起動する前に、 `store label --force`コマンドを実行して PD に保存されているラベルを空にします。 #### ストアのウェイトを設定する {#configure-store-weight} diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index a5c6460411824..f223b970e1412 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -537,7 +537,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ - 平均`Commit Log Duration` = 7.92ミリ秒 - 平均`Apply Log Duration` = 172 us -スレッド`Store`の場合、 `Commit Log Duration`明らかに`Apply Log Duration`よりも高い値です。一方、 `Append Log Duration` `Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。13と`Commit Log Duration` `Append Log Duration`削減する方法としては、以下のものが考えられます。 +スレッド`Store`の場合、 `Commit Log Duration`は`Apply Log Duration`よりも明らかに高い値です。一方、 `Append Log Duration`は`Apply Log Duration`よりも大幅に高い値であり、スレッド`Store`はCPUとI/Oの両方でボトルネックが発生している可能性があることを示しています。`Commit Log Duration`と`Append Log Duration`を削減する方法としては、以下のものが考えられます。 - TiKV CPU リソースが十分な場合は、 `raftstore.store-pool-size`の値を増やして`Store`スレッドを追加することを検討してください。 - TiDBがv5.4.0以降の場合は、 `raft-engine.enable: true`設定して[`Raft Engine`](/tikv-configuration-file.md#raft-engine)有効にすることを検討してください。RaftRaft Engineは軽量な実行パスを備えています。これにより、I/O書き込みの削減と、一部のシナリオにおける書き込みのロングテールレイテンシーの削減に役立ちます。 diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index f748e95dabe8d..8d59cf3c4aec8 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -180,9 +180,9 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。 ### 分析の結論 {#analysis-conclusion} -シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` ） `StmtClose`あります。シナリオ2と比較すると、シナリオ3 `StmtExecute`ネットワークのラウンドトリップ遅延が2つ多くなっています。 +シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ）多くあります。シナリオ2と比較すると、シナリオ3はネットワークのラウンドトリップ遅延が2つ多くなっています。 -- QPS の減少に関する分析： **「CPS By Type」**ペインを見ると、シナリオ 2 には「CPS By Type `StmtExecute`コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` ) が存在する`StmtClose` `StmtClose` `StmtPrepare`にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 +- QPS の減少に関する分析： **「CPS By Type」**ペインを見ると、シナリオ 2 には CPS By Type コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ) が存在することがわかります。`StmtPrepare`と`StmtClose`は QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 - 平均クエリ時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプ`StmtPrepare`と`StmtClose`については、TiDB内部処理においてクエリ時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ時間が大幅に短縮されます。 シナリオ3ではPrepared Statementインターフェースを使用していますが、多くのアプリケーションフレームワークはメモリリークを防ぐためにメソッド`StmtExecute`の後にメソッド`StmtClose`を呼び出すため、実行プランのキャッシュは依然としてアクセスされません。v6.0.0以降では、グローバル変数`tidb_ignore_prepared_cache_close_stmt=on;`を設定できます。その後、アプリケーションがメソッド`StmtClose`を呼び出しても、TiDBはキャッシュされた実行プランをクリアしません。そのため、次のSQL実行では既存の実行プランを再利用でき、実行プランの繰り返しコンパイルを回避できます。 diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index 60969dcf248de..93abf5bc1ed0d 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -44,13 +44,13 @@ TiDB の悲観的なトランザクションは、MySQL のトランザクショ | セッション1 | セッション2 | セッション3 | | :-------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------ | :----------------------------------------------------------- | - | テーブル t (a INT) を作成します。 | | | + | CREATE TABLE t (a INT); | | | | INSERT INTO T VALUES(1); | | | - | 悲観的な見通しから始める。 | | | + | BEGIN PESSIMISTIC; | | | | UPDATE t SET a = a + 1; | | | - | | 悲観的な見通しから始める。 | | + | | BEGIN PESSIMISTIC; | | | | SELECT * FROM t; -- スナップショット読み取りを使用して、現在のトランザクションが開始される前にコミットされたバージョンを読み取ります。結果は a=1 を返します。 | | - | | | 悲観的な見通しから始める。 | + | | | BEGIN PESSIMISTIC; | | | | SELECT * FROM t FOR UPDATE; -- 現在の読み取りを使用します。ロックが完了するまで待ちます。 | | COMMIT; -- ロックを解放します。セッション 3 の SELECT FOR UPDATE 操作がロックを取得し、TiDB は現在の読み取りを使用して最新のコミット済みバージョンを読み取ります。結果として a=2 が返されます。 | | | | | SELECT * FROM t; -- スナップショット読み取りを使用して、現在のトランザクションが開始される前にコミットされたバージョンを読み取ります。結果は a=1 を返します。 | | diff --git a/pipelined-dml.md b/pipelined-dml.md index f7677d947afd9..492d0915844f9 100644 --- a/pipelined-dml.md +++ b/pipelined-dml.md @@ -41,7 +41,7 @@ summary: パイプラインDMLのユースケース、メソッド、制限事 - パイプライン DML 操作中に[メタデータロック](/metadata-lock.md)が有効になっていることを確認します。 - パイプラインDMLを有効にしてDML文を実行する際、TiDBは以下の条件をチェックします。いずれかの条件が満たされない場合、TiDBは標準のDML実行にフォールバックし、警告を生成します。 - サポートされるステートメントは[自動コミット](/transaction-overview.md#autocommit)だけです。 - - `INSERT` 、 `REPLACE` `DELETE` `UPDATE`のみがサポートされます。 + - `INSERT` 、 `UPDATE` 、 `REPLACE` 、 `DELETE`のみがサポートされます。 - ターゲット テーブルには[一時テーブル](/temporary-tables.md)または[キャッシュされたテーブル](/cached-tables.md)含めることはできません。 - [外部キー制約](/foreign-key.md)有効になっている場合（ `foreign_key_checks = ON` ）、ターゲットテーブルに外部キー関係を含めることはできません。 - `INSERT IGNORE ... ON DUPLICATE KEY UPDATE`ステートメントを実行すると、競合する更新によって`Duplicate entry`エラーが発生する可能性があります。 diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md index b8e986814d20e..d694dcd645c37 100644 --- a/placement-rules-in-sql.md +++ b/placement-rules-in-sql.md @@ -19,7 +19,7 @@ SQLの配置ルールは、SQL文を使用してTiKVクラスタ内のデータ ## 概要 {#overview} -SQL の配置ルール機能を使用すると、配置ポリシー[配置ポリシーを作成する](#create-and-attach-placement-policies)、次のように粗いものから細かいものまで、さまざまなレベルでデータに必要な配置ポリシーを構成できます。 +SQL の配置ルール機能を使用すると、[配置ポリシーを作成し](#create-and-attach-placement-policies)、次のように粗いものから細かいものまで、さまざまなレベルでデータに必要な配置ポリシーを構成できます。 | レベル | 説明 | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -97,7 +97,7 @@ SHOW PLACEMENT LABELS; このステートメントでは、 - `PRIMARY_REGION="us-east-1"`オプションは、 `region`ラベルのノードに`us-east-1`としてRaftリーダーを配置することを意味します。 - - `REGIONS="us-east-1,us-west-1"`オプションは、 `region` - `us-east-1`として、 `region`ラベルのノードに`us-west-1`として Raft Followers を配置することを意味します。 + - `REGIONS="us-east-1,us-west-1"`オプションは、 `region`ラベルが`us-east-1`のノードと`region`ラベルが`us-west-1`のノードに Raft Followers を配置することを意味します。 構成可能な配置オプションとその意味の詳細については、「[配置オプション](#placement-option-reference)参照してください。 @@ -155,13 +155,13 @@ SHOW PLACEMENT LABELS; 1 row in set ``` -- クラスタ内の配置ポリシーに関連付けられているすべてのテーブルを表示するには、 `tidb_placement_policy_name`システムテーブルの`information_schema.tables`列をクエリします。 +- クラスタ内の配置ポリシーに関連付けられているすべてのテーブルを表示するには、 `information_schema.tables`システムテーブルの`tidb_placement_policy_name`列をクエリします。 ```sql SELECT * FROM information_schema.tables WHERE tidb_placement_policy_name IS NOT NULL; ``` -- クラスタ内の配置ポリシーが関連付けられているすべてのパーティションを表示するには、 `tidb_placement_policy_name`システムテーブルの`information_schema.partitions`列をクエリします。 +- クラスタ内の配置ポリシーが関連付けられているすべてのパーティションを表示するには、 `information_schema.partitions`システムテーブルの`tidb_placement_policy_name`列をクエリします。 ```sql SELECT * FROM information_schema.partitions WHERE tidb_placement_policy_name IS NOT NULL; @@ -248,7 +248,7 @@ CREATE PLACEMENT POLICY five_replicas FOLLOWERS=4; ALTER RANGE global PLACEMENT POLICY five_replicas; ``` -TiDB ではリーダーの数がデフォルトで`1`に設定されているため、 `five replicas`は`4`フォロワーと`1`のLeader。 +TiDB ではリーダーの数がデフォルトで`1`に設定されているため、 `five replicas`は`4`つのフォロワーと`1`つのLeaderを意味します。 ### データベースのデフォルトの配置ポリシーを指定します。 {#specify-a-default-placement-policy-for-a-database} @@ -314,8 +314,8 @@ PARTITION BY RANGE( YEAR(purchased) ) ( - `p0`パーティションには`storageforhistorydata`ポリシーが適用されます。 - `p4`パーティションには`storagefornewdata`ポリシーが適用されます。 -- `p1` 、 `p2` 、および`p3`パーティションは、テーブル`companystandardpolicy`から継承された`t1`ポリシーを適用します。 -- グローバルインデックス`idx`は、テーブル`companystandardpolicy`と同じ`t1`配置ポリシーを適用します。 +- `p1` 、 `p2` 、および`p3`パーティションは、テーブル`t1`から継承された`companystandardpolicy`ポリシーを適用します。 +- グローバルインデックス`idx`は、テーブル`t1`と同じ`companystandardpolicy`配置ポリシーを適用します。 - テーブル`t1`に対して配置ポリシーが指定されていない場合、 `p1` 、 `p2` 、 `p3`パーティションとグローバルインデックス`idx`データベースのデフォルトポリシーまたはグローバルのデフォルトポリシーを継承します。 これらのパーティションに配置ポリシーを適用した後、次の例のように、特定のパーティションの配置ポリシーを変更できます。 @@ -410,7 +410,7 @@ SHOW PLACEMENT; CREATE PLACEMENT POLICY deploy221_primary_east1 LEADER_CONSTRAINTS="[+region=us-east-1]" FOLLOWER_CONSTRAINTS='{"+region=us-east-1": 1, "+region=us-east-2": 2, "+region=us-west-1": 1}'; ``` -この配置ポリシーが作成され、目的のデータに適用されると、データのRaftLeaderレプリカは`us-east-1`オプションで指定された`LEADER_CONSTRAINTS`リージョンに配置され、その他のデータのレプリカは`FOLLOWER_CONSTRAINTS`オプションで指定されたリージョンに配置されます。クラスターが障害を起こした場合（たとえば、 `us-east-1`リージョンでノードが停止した場合など）、これらのリージョン`FOLLOWER_CONSTRAINTS`で指定されていても、他のリージョンから新しいLeaderが選出されることに注意してください。つまり、サービスの可用性を確保することが最優先事項となります。 +この配置ポリシーが作成され、目的のデータに適用されると、データのRaftLeaderレプリカは`LEADER_CONSTRAINTS`オプションで指定された`us-east-1`リージョンに配置され、その他のデータのレプリカは`FOLLOWER_CONSTRAINTS`オプションで指定されたリージョンに配置されます。クラスターが障害を起こした場合（たとえば、 `us-east-1`リージョンでノードが停止した場合など）、これらのリージョン`FOLLOWER_CONSTRAINTS`で指定されていても、他のリージョンから新しいLeaderが選出されることに注意してください。つまり、サービスの可用性を確保することが最優先事項となります。 `us-east-1`領域で障害が発生した場合、 `us-west-1`に新しいリーダーを配置したくない場合は、特別な`evict-leader`属性を設定して、その領域で新たに選出されたリーダーを排除することができます。 diff --git a/predicate-push-down.md b/predicate-push-down.md index b5378a9702f04..1a30d6482f880 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -129,7 +129,7 @@ explain select * from t where a < @a; このクエリでは、テーブル`t`に述語`a < @a`あります。述語の`@a`ユーザー変数です。 -`explain`結果からわかるように、述語はケース 2 とは異なり、ケース`a < 1`に簡略化されて TiKV にプッシュダウンされます。これは、ユーザー変数`@a`の値が計算中に変化する可能性があり、TiKV がその変化を認識しないためです。そのため、TiDB は`@a` `1`に置き換えず、TiKV にプッシュダウンしません。 +`explain`結果からわかるように、述語はケース 2 とは異なり、 `a < 1`に簡略化されて TiKV にプッシュダウンされることはありません。これは、ユーザー変数`@a`の値が計算中に変化する可能性があり、TiKV がその変化を認識しないためです。そのため、TiDB は`@a`を`1`に置き換えず、TiKV にプッシュダウンしません。 理解を助ける例は次のとおりです。 diff --git a/read-historical-data.md b/read-historical-data.md index cb47fa81947ed..e6ebe8a62e514 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -106,7 +106,7 @@ TiDBでは、ガベージコレクション（GC）が定期的に実行され 3 rows in set (0.00 sec) ``` -6. スコープがセッションである変数を`tidb_snapshot`設定します。この変数は、値の直前のバージョンを読み取れるように設定されます。 +6. スコープがセッションである`tidb_snapshot`変数を設定します。この変数は、値の直前のバージョンを読み取れるように設定されます。 > **Note:** > diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 95e0e9e099173..cd92bb610af51 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 3.0.0 ## TiDB {#tidb} - 新機能 - - ウィンドウ関数`NTH_VALUE` `RANK` 。1、3、5、7、9、11、13、15、17、19、21 `LEAD`含むMySQL 8.0 `NTILE`すべての`CUME_DIST`関数`ROW_NUMBER` `LAST_VALUE` `FIRST_VALUE` `PERCENT_RANK`あり`DENSE_RANK` `LAG` + - ウィンドウ関数をサポート。`NTILE` 、 `LEAD` 、 `LAG` 、 `PERCENT_RANK` 、 `NTH_VALUE` 、 `CUME_DIST` 、 `FIRST_VALUE` 、 `LAST_VALUE` 、 `RANK` 、 `DENSE_RANK` 、 `ROW_NUMBER`を含む、MySQL 8.0のすべてのウィンドウ関数と互換性があります - ビューのサポート（**Experimental**） - テーブルパーティションの改善 - サポート範囲パーティション @@ -54,7 +54,7 @@ TiDB Ansible バージョン: 3.0.0 - ログ出力を最適化: `EXECUTE`ユーザー変数を出力し、 `COMMIT`トラブルシューティングを容易にするためにスロークエリログを出力します。 - SQLチューニングの使いやすさを向上させる`EXPLAIN ANALYZE`機能をサポート - 次の行のIDを取得するための`admin show next_row_id`コマンドをサポートします - - 6 `NAME_CONST` `JSON_ARRAY_APPEND`組み込み関数`BENCHMARK`追加し`COALESCE` `JSON_MERGE_PRESERVE` `JSON_QUOTE` + - `JSON_QUOTE` 、 `JSON_ARRAY_APPEND` 、 `JSON_MERGE_PRESERVE` 、 `BENCHMARK` 、 `COALESCE` 、 `NAME_CONST`の6つの組み込み関数を追加 - チャンクサイズの制御ロジックを最適化し、クエリコンテキストに基づいて動的に調整することで、SQL実行時間とリソース消費を削減します。 - 3つの演算子（ `TableReader` `IndexLookupReader`でメモリ使用量の追跡と制御をサポートします`IndexReader` - 空の`ON`条件をサポートするように Merge Join 演算子を最適化します。 diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index fdd9ae2c980eb..d2b59bcc819cf 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -31,7 +31,7 @@ TiDB Ansible バージョン: 3.0.2 - INDEX JOIN がプレフィックスインデックスを使用すると結果が間違ってしまう可能性がある問題を修正しました [＃11246](https://github.com/pingcap/tidb/pull/11246) - `DATE_ADD`関数がマイクロ秒を含む日付数値の減算を行う際に分数の配置が誤っているために結果が間違っている可能性がある問題を修正しました[＃11288](https://github.com/pingcap/tidb/pull/11288) - `DATE_ADD`関数が`INTERVAL` の負の数を誤って処理することによって発生する誤った結果を修正しました。 [＃11325](https://github.com/pingcap/tidb/pull/11325) - - `Mod(%)` `Mod(%)` 0 を返し、 `Minus(-)`以下の桁数が大きい場合 ( `select 0.000 % 0.11234500000000000000`など)、 `Multiple(*)` `Minus(-)`返す小数点以下の桁数`Multiple(*)` MySQL と異なる問題を修正しました[＃11251](https://github.com/pingcap/tidb/pull/11251) + - `Mod(%)` 、 `Multiple(*)` 、または`Minus(-)`が 0 を返し、小数点以下の桁数が大きい場合 ( `select 0.000 % 0.11234500000000000000`など)、 `Mod(%)` 、 `Multiple(*)` 、または`Minus(-)`が返す小数点以下の桁数が MySQL と異なる問題を修正しました[＃11251](https://github.com/pingcap/tidb/pull/11251) - `CONCAT`と`CONCAT_WS`関数によって返される結果の長さが`max_allowed_packet`超えると、警告付きの`NULL`が誤って返される問題を修正しました[＃11275](https://github.com/pingcap/tidb/pull/11275) - `SUBTIME`と`ADDTIME`関数のパラメータが無効な場合に警告付きの`NULL`が誤って返される問題を修正しました[＃11337](https://github.com/pingcap/tidb/pull/11337) - `CONVERT_TZ`関数のパラメータが無効な場合に`NULL`が誤って返される問題を修正しました[＃11359](https://github.com/pingcap/tidb/pull/11359) diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md index d59f639caff48..611728fe91204 100644 --- a/releases/release-4.0.0-beta.md +++ b/releases/release-4.0.0-beta.md @@ -13,7 +13,7 @@ TiDB Ansible バージョン: 4.0.0-beta ## TiDB {#tidb} -- `INSERT` / `REPLACE` / `DELETE` / `UPDATE`の実行中に使用されたメモリが[＃14289](https://github.com/pingcap/tidb/pull/14289) `MemQuotaQuery`項目で指定された制限を超えた場合、ログを出力するか、SQL 実行をキャンセルします。実際の動作は`OOMAction`設定に依存します。13 [＃14179](https://github.com/pingcap/tidb/pull/14179) [＃14299](https://github.com/pingcap/tidb/pull/14299) +- `INSERT` / `REPLACE` / `DELETE` / `UPDATE`の実行中に使用されたメモリが`MemQuotaQuery`設定項目で指定された制限を超えた場合、ログを出力するか、SQL 実行をキャンセルします。実際の動作は`OOMAction`設定に依存します。 [＃14179](https://github.com/pingcap/tidb/pull/14179) [＃14289](https://github.com/pingcap/tidb/pull/14289) [＃14299](https://github.com/pingcap/tidb/pull/14299) - 駆動テーブルと被駆動テーブルの両方の行数を考慮して、 `Index Join`のコスト計算の精度を高めます。 [＃12085](https://github.com/pingcap/tidb/pull/12085) - オプティマイザの動作を制御し、オプティマイザをより安定させるために 15 個の SQL ヒントを追加します。 - [＃11253](https://github.com/pingcap/tidb/pull/11253) [＃11364](https://github.com/pingcap/tidb/pull/11364) [＃11673](https://github.com/pingcap/tidb/pull/11673) [＃11740](https://github.com/pingcap/tidb/pull/11740) [＃11746](https://github.com/pingcap/tidb/pull/11746) diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index 0e4acc833a237..dea0ed10bc3c1 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-5.3.2.md b/releases/release-5.3.2.md index db2630e9aef38..82df899b1ff67 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -11,7 +11,7 @@ TiDB バージョン: 5.3.2 > **Warning:** > -> v5.3.2 には既知のバグがあるため、使用は推奨されません。詳細はご覧ください。このバグは v5.3.3 で修正されています。3 [バージョン5.3.3](/releases/release-5.3.3.md)使用を推奨します。 [＃12934](https://github.com/tikv/tikv/issues/12934) +> v5.3.2 には既知のバグがあるため、使用は推奨されません。詳細は [＃12934](https://github.com/tikv/tikv/issues/12934) をご覧ください。このバグは v5.3.3 で修正されています。 [バージョン5.3.3](/releases/release-5.3.3.md)の使用を推奨します。 ## 互換性の変更 {#compatibility-changes} diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index 63712fc1cd1d7..d90326cf5c52f 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -74,7 +74,7 @@ TiDB バージョン: 6.1.6 - 直交積[＃6730](https://github.com/pingcap/tiflash/issues/6730) @ [gengliqi](https://github.com/gengliqi)を計算するときにセミ結合が過剰なメモリを使用する問題を修正しました - TiFlashログ検索が遅すぎる問題を修正[＃6829](https://github.com/pingcap/tiflash/issues/6829) @ [hehechen](https://github.com/hehechen) - 新しい照合順序[＃6807](https://github.com/pingcap/tiflash/issues/6807) @ [xzhangxian1008](https://github.com/xzhangxian1008)を有効にした後に TopN/Sort 演算子が誤った結果を生成する問題を修正しました - - 特定のケースで[＃6994](https://github.com/pingcap/tiflash/issues/6994) @ [windtalker](https://github.com/windtalker) 10 進キャストが誤って切り上げられる問題を修正しました + - 特定のケースで 10 進キャストが誤って切り上げられる問題を修正しました [＃6994](https://github.com/pingcap/tiflash/issues/6994) @ [windtalker](https://github.com/windtalker) - TiFlashが生成された列[＃6801](https://github.com/pingcap/tiflash/issues/6801) @ [guo-shaoge](https://github.com/guo-shaoge)を認識できない問題を修正 - 特定のケースで小数点以下の桁が切り上げられない問題を修正[＃7022](https://github.com/pingcap/tiflash/issues/7022) @ [LittleFall](https://github.com/LittleFall) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 357887e34269b..5895b24cb353d 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.5.0.md b/releases/release-6.5.0.md index f73030e8377e6..b4055e93f4bc9 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -149,7 +149,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - [インデックスマージ](/glossary.md#index-merge)は、 `AND` で接続された式をサポートします [＃39333](https://github.com/pingcap/tidb/issues/39333) @ [guo-shaoge](https://github.com/guo-shaoge) @ [time-and-fate](https://github.com/time-and-fate) @ [hailanwhu](https://github.com/hailanwhu) - v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。11 `AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 + v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。`AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 インデックスマージの詳細については、 [v5.4.0 リリースノート](/releases/release-5.4.0.md#performance)と[インデックスのマージについて説明する](/explain-index-merge.md)を参照してください。 @@ -179,7 +179,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - オプティマイザーはより正確なコストモデルバージョン2（GA） を導入しました [＃35240](https://github.com/pingcap/tidb/issues/35240) @ [qw4990](https://github.com/qw4990) - TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 + TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 コスト モデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 @@ -312,7 +312,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620) | 変更 | さらにテストを行った後、デフォルト値を`1`から`2`に変更します。つまり、インデックス選択と演算子選択には、デフォルトでコスト モデル バージョン 2 が使用されることになります。 | | [`tidb_enable_gc_aware_memory_track`](/system-variables.md#tidb_enable_gc_aware_memory_track) | 変更 | デフォルト値を`ON`から`OFF`に変更します。GC対応メモリトラックはテストで不正確であることが判明し、追跡されるメモリサイズが大きくなりすぎるため、メモリトラックは無効化されています。また、 Golang 1.19では、GC対応メモリトラックによって追跡されるメモリは、全体のメモリに大きな影響を与えません。 | | [`tidb_enable_metadata_lock`](/system-variables.md#tidb_enable_metadata_lock-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。これは、メタデータ ロック機能がデフォルトで有効になっていることを意味します。 | -| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | `DELETE` 6.5.0以降で有効になります。1、3、5 `INSERT` `UPDATE` SQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | +| [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | 6.5.0以降で有効になります。`INSERT` 、 `DELETE` 、 `UPDATE`を含むSQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 `ADD INDEX`と`CREATE INDEX`の加速はデフォルトで有効になります。 | | [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) | 変更 | TiDB v6.5.0より前のバージョンでは、この変数はクエリのメモリクォータのしきい値を設定するために使用されます。TiDB v6.5.0以降のバージョンでは、DMLステートメントのメモリをより正確に制御するために、この変数はセッションのメモリクォータのしきい値を設定するために使用されます。 | | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティーゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティーゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 | diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 990c1c2c6b5cc..8376040537fd6 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -94,7 +94,7 @@ TiDB バージョン: 6.5.6 - PDリーダーの故障により1分間に`IMPORT INTO`タスクが失敗する問題を修正[＃48307](https://github.com/pingcap/tidb/issues/48307) @ [D3Hunter](https://github.com/D3Hunter) - 日付型フィールドにインデックスを作成することによって発生する`ADMIN CHECK`の失敗の問題を修正しました [＃47426](https://github.com/pingcap/tidb/issues/47426) @ [tangenta](https://github.com/tangenta) - `TABLESAMPLE` によって返されるソートされていない行データの問題を修正しました [＃48253](https://github.com/pingcap/tidb/issues/48253) @ [tangenta](https://github.com/tangenta) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - TiKV diff --git a/releases/release-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 418e761caa00a..2ab4d654c990a 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.5.1.md b/releases/release-7.5.1.md index b13885a44ea96..192bbcb1ad2be 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -141,7 +141,7 @@ TiDB バージョン: 7.5.1 - DDL所有者がネットワークから分離された後に`ADD INDEX`を実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [＃49773](https://github.com/pingcap/tidb/issues/49773) @ [tangenta](https://github.com/tangenta) - `AUTO_ID_CACHE=1` のAUTO_INCREMENT列を使用すると同時競合によりAUTO_INCREMENT ID 割り当てでエラーが報告される問題を修正しました。 [＃50519](https://github.com/pingcap/tidb/issues/50519) @ [tiancaiamao](https://github.com/tiancaiamao) - クエリに Apply 演算子が含まれており、 `fatal error: concurrent map writes`エラーが発生すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50347](https://github.com/pingcap/tidb/issues/50347) @ [SeaRise](https://github.com/SeaRise) - - DDL `jobID` 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) + - DDL `jobID`が 0 に復元されたときに発生する TiDB ノードpanicの問題を修正しました [＃46296](https://github.com/pingcap/tidb/issues/46296) @ [jiyfhust](https://github.com/jiyfhust) - `STREAM_AGG()` CI を誤って処理したためにクエリ結果が正しくない問題を修正しました [＃49902](https://github.com/pingcap/tidb/issues/49902) @ [wshwsh12](https://github.com/wshwsh12) - 多数のテーブルまたはパーティションを処理するときに TiDB ノードが OOM エラーに遭遇する可能性がある問題を軽減します。 [＃50077](https://github.com/pingcap/tidb/issues/50077) @ [zimulala](https://github.com/zimulala) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [＃50067](https://github.com/pingcap/tidb/issues/50067) @ [hawkingrei](https://github.com/hawkingrei) @@ -191,7 +191,7 @@ TiDB バージョン: 7.5.1 - `DROP TABLE`データ挿入の直後に実行されると、 `FLASHBACK TABLE`または`RECOVER TABLE`一部のTiFlashレプリカのデータを回復できない可能性がある潜在的な問題を修正しました。 [＃8395](https://github.com/pingcap/tiflash/issues/8395) @ [JaySon-Huang](https://github.com/JaySon-Huang) - Grafana の一部のパネルの最大パーセンタイル時間の表示が誤っていた問題を修正 [＃8076](https://github.com/pingcap/tiflash/issues/8076) @ [JaySon-Huang](https://github.com/JaySon-Huang) - リモート読み取り中にTiFlashがクラッシュする可能性がある問題を修正 [＃8685](https://github.com/pingcap/tiflash/issues/8685) @ [guo-shaoge](https://github.com/guo-shaoge) - - `ENUM`値が 0 の場合にTiFlash が`ENUM`誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) + - `ENUM`値が 0 の場合にTiFlash が`ENUM`を誤って処理する問題を修正しました [＃8311](https://github.com/pingcap/tiflash/issues/8311) @ [solotzg](https://github.com/solotzg) - 短いクエリが正常に実行され、過剰な情報ログが出力される問題を修正しました。 [＃8592](https://github.com/pingcap/tiflash/issues/8592) @ [windtalker](https://github.com/windtalker) - クエリの低速化によりメモリ使用量が大幅に増加する問題を修正 [＃8564](https://github.com/pingcap/tiflash/issues/8564) @ [JinheLin](https://github.com/JinheLin) - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @ [gengliqi](https://github.com/gengliqi) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index a3b80167f2bb9..61c9de5973aa4 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) に設定されています。 | @@ -273,7 +273,7 @@ v8.4.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index a94d7b93d3e5d..454f32f240f0a 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -144,7 +144,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタをバージョン 8.4.0 以降にアップグレードすると、クラスタが利用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.1.md b/releases/release-8.5.1.md index 55d2a38859674..3d1555875d4fb 100644 --- a/releases/release-8.5.1.md +++ b/releases/release-8.5.1.md @@ -15,9 +15,9 @@ TiDBバージョン：8.5.1 バージョン8.5.1以降、TiDBはCentOS Linux 7のテストを再開し、互換性を確保しています。TiDB v8.5をデプロイする場合、またはクラスタをv8.5にアップグレードする場合は、TiDB v8.5.1以降のバージョンを使用してください。 -- TiDB v8.4.0 DMR および v8.5.0 リリースは[2024年6月30日をもってサポート終了となります](https://www.redhat.com/en/topics/linux/centos-linux-eol) CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 +- CentOS Linux 7 は[2024年6月30日をもってサポート終了となります](https://www.redhat.com/en/topics/linux/centos-linux-eol)。そのため、TiDB v8.4.0 DMR および v8.5.0 リリースでは、CentOS Linux 7 のサポートとテストを終了しました。CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 -- 現在も CentOS Linux 7 を使用しているユーザーを支援するために、TiDB は v8.5.1 から CentOS Linux 7 のテストを再開します。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)およびセキュリティに関するガイダンスを確認し、Rocky Linux 9.1 以降などの本番使用用の[TiDBがサポートするオペレーティングシステム](/hardware-and-software-requirements.md#os-and-platform-requirements)する報酬システムに移行することを強くお勧めします。 +- 現在も CentOS Linux 7 を使用しているユーザーを支援するために、TiDB は v8.5.1 から CentOS Linux 7 のテストを再開します。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)を確認し、Rocky Linux 9.1 以降などの本番使用向けの[TiDBがサポートするオペレーティングシステム](/hardware-and-software-requirements.md#os-and-platform-requirements)に移行することを強くお勧めします。 CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDBリリースではこのディストリビューションのテストは中止されます。 diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index 844c997aff9c1..d5dd7c78e7fff 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -90,7 +90,7 @@ TiDBバージョン：8.5.4 ### MySQLとの互換性 {#mysql-compatibility} -バージョン 8.5.4 以降、TiDB は`DECIMAL`列にデータを挿入する際の動作を MySQL と同期させました。小数点以下の桁数が列の定義済みスケールを超える場合、TiDB は余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。小数点以下の桁数に関係なく、切り捨てられたデータは挿入されます。以前の TiDB バージョンでは、挿入される`DECIMAL`値の小数点以下の桁数が 72 を超えると、挿入は失敗し、エラーが返されました。詳細については、 [JDBCを使用してTiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-sample-application-java-jdbc#mysql-compatibility) +バージョン 8.5.4 以降、TiDB は`DECIMAL`列にデータを挿入する際の動作を MySQL と同期させました。小数点以下の桁数が列の定義済みスケールを超える場合、TiDB は、超過した小数点以下の桁数に関係なく、余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。以前の TiDB バージョンでは、挿入される`DECIMAL`値の小数点以下の桁数が 72 を超えると、挿入は失敗し、エラーが返されました。詳細については、 [JDBCを使用してTiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-sample-application-java-jdbc#mysql-compatibility)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/versioning.md b/releases/versioning.md index 58bcee20c84e0..d14fc0622454d 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -22,9 +22,9 @@ TiDB のメジャー リリースのサポート ポリシーについては、 TiDB のバージョン番号は`X.Y.Z`から始まり、 `X.Y`リリース シリーズを表します。 -- TiDB 1.0以降、毎年`X`増加します。3リリース`X`に新機能と改善が導入されます。 -- `Y`から増加します。 `Y`ごとに新しい機能と改善が導入されます。 -- リリースシリーズの最初のリリースでは、デフォルトで`Z`が 0 に設定されます。パッチリリースの場合は、1 から`Z`増加します。 +- TiDB 1.0以降、`X`は毎年増加します。`X`リリースごとに新しい機能と改善が導入されます。 +- `Y`は 0 から増加します。 `Y`リリースごとに新しい機能と改善が導入されます。 +- リリースシリーズの最初のリリースでは、デフォルトで`Z`が 0 に設定されます。パッチリリースの場合は、 `Z`は 1 から増加します。 TiDB v5.0.0 以前のバージョンのバージョン管理システムについては、 [歴史的なバージョン管理](#historical-versioning-deprecated)を参照してください。 diff --git a/replicate-data-to-kafka.md b/replicate-data-to-kafka.md index 63ef8b024048f..f0b5659749ad6 100644 --- a/replicate-data-to-kafka.md +++ b/replicate-data-to-kafka.md @@ -99,7 +99,7 @@ summary: TiCDC を使用して TiDB データを Apache Kafka および Apache F 2. Kafka トピック内のデータを消費します。 - チェンジフィードが正常に動作すると、Kafkaトピックにデータが書き込まれます。実行`kafka-console-consumer.sh`では、データがKafkaトピックに正常に書き込まれていることを確認できます。 + チェンジフィードが正常に動作すると、Kafkaトピックにデータが書き込まれます。`kafka-console-consumer.sh`を実行すると、データがKafkaトピックに正常に書き込まれていることを確認できます。 ```shell ./bin/kafka-console-consumer.sh --bootstrap-server 127.0.0.1:9092 --from-beginning --topic `${topic-name}` diff --git a/role-based-access-control.md b/role-based-access-control.md index cd953810791b1..25928aba0931c 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -168,7 +168,7 @@ SET DEFAULT ROLE TO user [, user ] ``` -たとえば、次のステートメントを使用して、 `rw_user1@localhost` ～ `app_read`および`app_write`のデフォルト ロールを設定できます。 +たとえば、次のステートメントを使用して、 `rw_user1@localhost`のデフォルトロールを`app_read`および`app_write`に設定できます。 ```sql SET DEFAULT ROLE app_read, app_write TO 'rw_user1'@'localhost'; @@ -248,7 +248,7 @@ SET ROLE ALL EXCEPT 'app_read' SET DEFAULT ROLE ALL TO 'rw_user1'@'localhost'; ``` -`rw_user1@localhost`後、次のステートメントを実行できます。 +`rw_user1@localhost`のログイン後、次のステートメントを実行できます。 ```sql SELECT CURRENT_ROLE(); diff --git a/runtime-filter.md b/runtime-filter.md index 7a7a10cbefd3d..794fa0d240ca6 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`ステートメントを使用すると、ランタイムフィルター有効後の各演算子の実行時間を確認できます。 ランタイム フィルターが有効になっていない場合のクエリの実行情報は次のとおりです。 @@ -231,7 +231,7 @@ TPC-DS におけるテーブル`Sales`とテーブル`date_dim`の結合操作 ### ランタイムフィルターモード {#runtime-filter-mode} -ランタイムフィルタのモードは、**フィルタ送信オペレータ**と**フィルタ受信オペレータ**`GLOBAL`関係です。モードは`OFF` `LOCAL` 3つがあります。バージョン7.3.0では、モード`OFF`と`LOCAL`のみがサポートされています。ランタイムフィルタのモードは、システム変数[`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)によって制御されます。 +ランタイムフィルタのモードは、**フィルタ送信オペレータ**と**フィルタ受信オペレータ**の関係です。モードは`OFF`、`LOCAL`、`GLOBAL`の3つがあります。バージョン7.3.0では、モード`OFF`と`LOCAL`のみがサポートされています。ランタイムフィルタのモードは、システム変数[`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)によって制御されます。 - `OFF` : ランタイムフィルターは無効です。無効にした後のクエリの動作は以前のバージョンと同じです。 - `LOCAL` : ランタイムフィルタはローカルモードで有効です。ローカルモードでは、**フィルタセンダーオペレータ**と**フィルタレシーバオペレータは**同じMPPタスク内にあります。つまり、ランタイムフィルタは、HashJoinオペレータとTableScanオペレータが同じタスク内に存在するシナリオに適用できます。現在、ランタイムフィルタはローカルモードのみをサポートしています。このモードを有効にするには、 `LOCAL`に設定してください。 diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index c18efd9d23f6e..b4c8e5efc84bc 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -228,7 +228,7 @@ PD マイクロサービスが有効になっていないクラスターの場 tiup cluster edit-config ``` - `pd_mode: ms`に`global`加算します: + `global`に`pd_mode: ms`を追加します: ```ini global: diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 811a132cdc075..434ec0c2862d1 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -21,7 +21,7 @@ TiDBクラスターの高可用性と災害復旧能力を向上させるには TiUPを使用してクラスターをデプロイする場合、 [初期化設定ファイル](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)で TiKV の場所を設定できます。TiUPは、デプロイ中に TiDB、TiKV、PD、およびTiFlashの対応する設定ファイルを生成します。 -以下の例では、2層トポロジ（ `zone/host`が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 +以下の例では、2層トポロジ（ `zone/host` ）が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 - 各ゾーンには、TiDB インスタンスがデプロイされているホストが 2 つあり、各ホストには個別の TiDB インスタンスがデプロイされています。 - 各ゾーンには、TiKVインスタンスがデプロイされたホストが2つあります。z1では、各ホストに2つのTiKVインスタンスがデプロイされています。z2とz3では、各ホストに個別のTiKVインスタンスがデプロイされています。 @@ -244,7 +244,7 @@ host = "" `location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 -上記の手順に従って`location-labels`ゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、 `isolation-level` ～ `zone`次のように設定できます。 +上記の手順に従って`location-labels`をゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、次のように`isolation-level`を`zone`に設定できます。 ```toml [replication] diff --git a/schema-object-names.md b/schema-object-names.md index 59675f64dff31..37b8591d80e85 100644 --- a/schema-object-names.md +++ b/schema-object-names.md @@ -66,9 +66,9 @@ SELECT 1 AS `identifier`, 2 AS 'string'; 詳細については[MySQLスキーマオブジェクト名](https://dev.mysql.com/doc/refman/8.0/en/identifiers.html)を参照してください。 -## 識別子修飾子 {#identifier-qualifiers} +## 識別子の修飾子 {#identifier-qualifiers} -オブジェクト名は修飾名でも修飾名でも構いません。例えば、次の文は修飾名のないテーブルを作成します。 +オブジェクト名は非修飾名でも修飾名でも構いません。例えば、次の文は修飾名のないテーブルを作成します。 ```sql CREATE TABLE t (i int); diff --git a/sql-plan-management.md b/sql-plan-management.md index 07d92fe280437..fb16c751d5c30 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -9,7 +9,7 @@ SQL計画管理は、SQLバインディングを実行してSQL実行計画を ## SQLバインディング {#sql-binding} -SQLバインディングはSPMの基盤です。1 [オプティマイザヒント](/optimizer-hints.md)ドキュメントでは、ヒントを用いて特定の実行プランを選択する方法を紹介しています。しかし、SQL文を変更せずに実行プランの選択を操作したい場合もあります。SQLバインディングを使用すれば、SQL文を変更せずに特定の実行プランを選択できます。 +SQLバインディングはSPMの基盤です。[オプティマイザヒント](/optimizer-hints.md)ドキュメントでは、ヒントを用いて特定の実行プランを選択する方法を紹介しています。しかし、SQL文を変更せずに実行プランの選択を操作したい場合もあります。SQLバインディングを使用すれば、SQL文を変更せずに特定の実行プランを選択できます。 @@ -37,7 +37,7 @@ SQL ステートメントまたは履歴実行プランに従って、SQL ステ CREATE [GLOBAL | SESSION] BINDING [FOR BindableStmt] USING BindableStmt; ``` -この文は`UPDATE` SQL実行プランをGLOBALまたはSESSIONレベルでバインドします。現在、TiDBでサポートされているバインド可能なSQL文（BindableStmt）には`DELETE` `SELECT` `INSERT` `REPLACE`あり、それぞれ`SELECT`サブクエリが含まれています。以下に例を示します。 +この文はSQL実行プランをGLOBALまたはSESSIONレベルでバインドします。現在、TiDBでサポートされているバインド可能なSQL文（BindableStmt）には`SELECT` 、 `DELETE` 、 `UPDATE` 、および`SELECT`サブクエリを含む`INSERT` / `REPLACE`があります。以下に例を示します。 ```sql CREATE GLOBAL BINDING USING SELECT /*+ use_index(orders, orders_book_id_idx) */ * FROM orders; @@ -82,7 +82,7 @@ USING > **Note:** > -> `REPLACE` `SELECT` `INSERT`実行プランバインディングを作成する場合、バインドするオプティマイザヒントを`INSERT`キーワードの後ではなく、 `SELECT` `REPLACE`に指定する必要があります。そうしないと、オプティマイザヒントは意図したとおりに機能しません。 +> `SELECT`サブクエリを持つ`INSERT` / `REPLACE`文の実行プランバインディングを作成する場合、バインドするオプティマイザヒントを`INSERT` / `REPLACE`キーワードの後ではなく、`SELECT`サブクエリに指定する必要があります。そうしないと、オプティマイザヒントは意図したとおりに機能しません。 ここに 2 つの例を示します。 @@ -376,7 +376,7 @@ SHOW [GLOBAL | SESSION] BINDINGS [ShowLikeOrWhere] | バインドSQL | ヒント付きのバインドされたSQL文 | | デフォルトデータベース | デフォルトのデータベース | | 状態 | ステータスには`enabled` (v6.0 の`using`ステータスを置き換えます)、 `disabled` 、 `deleted` 、 `invalid` 、 `rejected` 、および`pending verify`が含まれます | -| 作成時間 | 時間を創る | +| 作成時間 | 作成時間 | | 更新時間 | 更新時間 | | 文字セット | 文字セット | | 照合順序 | 順序付けルール | @@ -461,7 +461,7 @@ SHOW binding_cache status; ## ステートメントサマリーテーブルを利用して、バインドする必要があるクエリを取得します。 {#utilize-the-statement-summary-table-to-obtain-queries-that-need-to-be-bound} -[ステートメントの要約](/statement-summary-tables.md) 、レイテンシー、実行時間、対応するクエリプランなど、最近のSQL実行情報を記録します。ステートメントサマリーテーブルにクエリを実行すると、条件付き`plan_digest` 、そして[これらの履歴実行計画に従ってバインディングを作成する](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)取得できます。 +[ステートメントの要約](/statement-summary-tables.md)は、レイテンシー、実行時間、対応するクエリプランなど、最近のSQL実行情報を記録します。ステートメントサマリーテーブルにクエリを実行して条件を満たす`plan_digest`を取得し、[これらの履歴実行計画に従ってバインディングを作成する](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)ことができます。 以下の例では、過去2週間に10回以上実行され、SQLバインディングのない複数の実行プランを持つ`SELECT`ステートメントをクエリします。クエリを実行時間でソートし、上位100件のクエリを最も高速なプランにバインドします。 @@ -505,7 +505,7 @@ ORDER BY SUM(exec_count) DESC LIMIT 100; -- Top 100 high-f ## データベース間のバインディング {#cross-database-binding} -バージョン7.6.0以降、TiDBでは、バインディング作成構文でワイルドカード`*`を使用してデータベース名を表すことで、データベース間バインディングを作成できます。データベース間バインディングを作成する前に、まずシステム変数「 [`tidb_opt_enable_fuzzy_binding`](/system-variables.md#tidb_opt_enable_fuzzy_binding-new-in-v760)を有効にする必要があります。 +バージョン7.6.0以降、TiDBでは、バインディング作成構文でワイルドカード`*`を使用してデータベース名を表すことで、データベース間バインディングを作成できます。データベース間バインディングを作成する前に、まずシステム変数 [`tidb_opt_enable_fuzzy_binding`](/system-variables.md#tidb_opt_enable_fuzzy_binding-new-in-v760)を有効にする必要があります。 クロスデータベースバインディングを使用すると、データが異なるデータベースに分類・保存され、各データベースで同一のオブジェクト定義が維持され、類似のアプリケーションロジックが実行されるシナリオにおいて、実行プランの修正プロセスを簡素化できます。以下に、一般的なユースケースをいくつか示します。 diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index f43064d168cc3..6e9459a67b0c3 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -9,7 +9,7 @@ TiDB クラスタの問題を特定してトラブルシューティングする `PLAN REPLAYER`の特徴は以下のとおりです。 -- オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートしてstorage。 +- オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートして保存します。 - 別のTiDBクラスタからエクスポートされたZIP形式のファイルをクラスタにインポートします。このファイルには、オンサイトトラブルシューティング時の後者のTiDBクラスタの情報が含まれています。 ## PLAN REPLAYERを使用してクラスター情報をエクスポートします {#use-code-plan-replayer-code-to-export-cluster-information} @@ -33,7 +33,7 @@ TiDB は、 `sql-statement`に基づいて、次のオンサイト情報を整 履歴統計が[有効](/system-variables.md#tidb_enable_historical_stats)場合、 `PLAN REPLAYER`文で時刻を指定することで、対応する時刻の履歴統計を取得できます。時刻と日付を直接指定することも、タイムスタンプを指定することもできます。TiDB は指定された時刻より前の履歴統計を検索し、その中から最新のものをエクスポートします。 -指定された時刻より前の履歴統計がない場合、TiDBは最新の統計をエクスポートします。これは、時刻が指定されていない場合の動作と一致しています。さらに、TiDBはエクスポートされた`ZIP`ファイル内に、 `errors.txt`ファイル内のエラーメッセージを出力。 +指定された時刻より前の履歴統計がない場合、TiDBは最新の統計をエクスポートします。これは、時刻が指定されていない場合の動作と一致しています。さらに、TiDBはエクスポートされた`ZIP`ファイル内に、 `errors.txt`ファイル内のエラーメッセージを出力します。 > **Note:** > diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index dc7c56eb584d2..bb537e408dd2c 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -41,7 +41,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - `Execute`が実行されるデータベースの名前 - `Prepare`のステートメントの識別子、つまり`PREPARE`のキーワードの後の名前 - 現在のスキーマバージョン。DDL文が正常に実行されるたびに更新されます。 -- 実行時のSQLモード`Execute` +- `Execute`実行時のSQLモード - 現在のタイムゾーン（システム変数`time_zone`の値） - `sql_select_limit`システム変数の値 diff --git a/sql-statements/sql-statement-admin-cancel-ddl.md b/sql-statements/sql-statement-admin-cancel-ddl.md index 9faf0c4cdfcb6..1ca952be90f3b 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-pause-ddl.md b/sql-statements/sql-statement-admin-pause-ddl.md index 48b9a20aa789c..b512448114c6e 100644 --- a/sql-statements/sql-statement-admin-pause-ddl.md +++ b/sql-statements/sql-statement-admin-pause-ddl.md @@ -35,7 +35,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 -> - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを一時停止できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 @@ -44,7 +44,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 -> - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを一時停止できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md index 8a19f576f0e6d..b3df804631be0 100644 --- a/sql-statements/sql-statement-admin-resume-ddl.md +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -34,7 +34,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **Note:** > > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 -> - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを再開できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 @@ -44,7 +44,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **Note:** > > - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 -> - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 +> - このステートメントは複数のDDLジョブを再開できます。[`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`を取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index 369cc4fb41089..3cc0624f438ca 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..0470d698bbdf2 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 78fdcac2fb93c..fc5221c539d29 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 2ca4499c2fa4f..8d65006b3c5f7 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-do.md b/sql-statements/sql-statement-do.md index 41b13d405befe..f2e0f3d918287 100644 --- a/sql-statements/sql-statement-do.md +++ b/sql-statements/sql-statement-do.md @@ -53,7 +53,7 @@ Query OK, 0 rows affected (2.50 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DO`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DO`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} 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-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 3d6dad8070ad8..f3009412f21f9 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -160,7 +160,7 @@ EXPLAIN ANALYZE SELECT * FROM t1; ### IndexHashJoin {#indexhashjoin} -`IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。5演算`IndexHashJoin`も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 +`IndexHashJoin`演算子の実行プロセスは`IndexJoin`演算子と同様です。`IndexHashJoin`演算子も1つの外部ワーカーとN個の内部ワーカーで並列実行されますが、出力順序は外部テーブルと一致するとは限りません。詳細な実行プロセスは以下のとおりです。 1. 外側のワーカーは N 個の外側の行を読み取り、タスクを構築して、それを内側のワーカー チャネルに送信します。 2. 内部ワーカーは内部ワーカーチャネルからタスクを受け取り、各タスクに対して以下の3つの操作を順番に実行します。a. 外部行からハッシュテーブルを構築する。b. 外部行からキー範囲を構築し、内部行を取得する。c. ハッシュテーブルをプローブし、結合結果を結果チャネルに送信する。注：ステップaとステップbは同時に実行されます。 diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index 23bc512c23568..917a5b9d11e67 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -176,8 +176,8 @@ EXPLAIN DELETE FROM t1 WHERE c1=3; | 形式 | 説明 | | ------------ | ------------------------------------------------------------------------------------------------------------------------- | -| 指定されていない | 形式が指定されていない場合は、デフォルトの形式`EXPLAIN` `row`使用されます。 | -| `brief` | `EXPLAIN`ステートメントの出力の演算子 ID は、 `FORMAT`指定されていない場合に比べて簡素化されます。 | +| 指定されていない | 形式が指定されていない場合、 `EXPLAIN`はデフォルトの形式`row`を使用します。 | +| `brief` | `EXPLAIN`ステートメントの出力の演算子 ID は、 `FORMAT`が指定されていない場合に比べて簡素化されます。 | | `dot` | `EXPLAIN`ステートメントは DOT 実行プランを出力します。これを使用して、 `dot`プログラム ( `graphviz`パッケージ内) を通じて PNG ファイルを生成することができます。 | | `row` | `EXPLAIN`文は結果を表形式で出力します。詳細については[クエリ実行プランを理解する](/explain-overview.md)を参照してください。 | | `tidb_json` | `EXPLAIN`ステートメントは実行プランを JSON 形式で出力し、演算子情報を JSON 配列に格納します。 | diff --git a/sql-statements/sql-statement-flashback-database.md b/sql-statements/sql-statement-flashback-database.md index eb8c1a3025aff..a0ef5aac7961a 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 e22df2322ae69..c67808e7da756 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 6c191e9d77095..a4d425a54275b 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`は、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。`LOCK TABLES`は、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 -テーブルロックは、他のセッションによる読み取りや書き込みから保護します。1 ロックを保持しているセッションは、 `WRITE`や`TRUNCATE TABLE` `DROP TABLE`のテーブルレベルの操作を実行できます。 +テーブルロックは、他のセッションによる読み取りや書き込みから保護します。 `WRITE`ロックを保持しているセッションは、 `DROP TABLE`や`TRUNCATE TABLE`などのテーブルレベルの操作を実行できます。 > **Note:** > diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 96293fc5491c2..a76cdd20df368 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -243,7 +243,7 @@ SHOW VARIABLES LIKE 'tidb\_auto\_analyze%'; | tidb_auto_analyze_end_time | 23:59 +0000 | +-----------------------------------------+-------------+ -自動収集ではニーズを満たせない場合があります。デフォルトでは`00:00` ～ `23:59`回収集されるため、分析ジョブはいつでも実行できます。オンラインビジネスへのパフォーマンスへの影響を最小限に抑えるため、統計収集の開始時間と終了時間を指定することもできます。 +自動収集ではニーズを満たせない場合があります。デフォルトでは`00:00` ～ `23:59`の間に収集されるため、分析ジョブはいつでも実行できます。オンラインビジネスへのパフォーマンスへの影響を最小限に抑えるため、統計収集の開始時間と終了時間を指定することもできます。 `ANALYZE TABLE table_name`ステートメントを使用して手動で統計情報を収集できます。これにより、サンプルレート、上位N値の数などの設定を調整したり、特定の列のみの統計を収集したりできます。 @@ -416,7 +416,7 @@ EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 +--------------------------+-------------+--------------+-------------------+----------------------------------------------------------------------------------------------------+ 5 rows in set (0.00 sec) -次の例では、プランツリーの最初のリーフノードである`IndexRangeScan_47`調べることから始めます。オプティマイザは、 `stars`テーブルから`name`と`id`列のみを選択します。これらの列は`name(name)`インデックスから取得できます。その結果、 `stars`のルートリーダーは`IndexReader_48`ではなく`TableReader`なります。 +次の例では、プランツリーの最初のリーフノードである`IndexRangeScan_47`を調べることから始めます。オプティマイザは、 `stars`テーブルから`name`と`id`列のみを選択します。これらの列は`name(name)`インデックスから取得できます。その結果、 `stars`のルートリーダーは`IndexReader_48`であり、`TableReader`ではありません。 `stars`と`planets`の結合はハッシュ結合です（ `HashJoin_44` ）。`planets`テーブルはフルテーブルスキャン（ `TableFullScan_45` ）を使用してアクセスされます。結合後、 `TopN_26`と`TopN_19`がそれぞれ`ORDER BY`と`LIMIT`句を適用します。最後の演算子`Projection_16`は、最後の列`t5.name`を選択します。 @@ -486,9 +486,9 @@ LIMIT 3; 以下の実行プランでは、クエリは5分51秒間実行された後、キャンセルされます。主な問題点は次のとおりです。 1. 重大な過小評価：最初のリーフノード`IndexReader_76`インデックス`index_orders_on_adjustment_id(adjustment_id)`からデータを読み取ります。実際の行数（ `actRows` ）は256,811,189で、推定された1行（ `estRows` ）よりも大幅に多くなっています。 -2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`予想よりもはるかに多くのデータを含むハッシュ テーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 -3. クエリの終了： `0` `HashJoin_69`の演算子の値が`actRows`の場合、1は一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 -4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `estRows` `IndexRangeScan_75`に対して大幅に過小評価していることであり、オプティマイザーが誤った結合順序を選択することになります。 +2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`が予想よりもはるかに多くのデータを含むハッシュ テーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 +3. クエリの終了： `HashJoin_69`とその上位の演算子の`actRows`の値が`0`の場合、一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 +4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `IndexRangeScan_75`に対する`estRows`を大幅に過小評価していることであり、オプティマイザーが誤った結合順序を選択することになります。 これらの問題に対処するには、特に`orders`テーブルと`index_orders_on_adjustment_id`インデックスのテーブル統計が最新であることを確認します。 @@ -542,7 +542,7 @@ LIMIT 3; ### TiDBのインデックス戦略 {#index-strategy-in-tidb} -TiDBは、SQLレイヤー（TiDBサーバー）とストレージレイヤー（TiKV）を分離した分散SQLデータベースです。従来のデータベースとは異なり、TiDBは計算ノードにデータをキャッシュするためにバッファプールを使用しません。そのため、SQLクエリのパフォーマンスとクラスタ全体のパフォーマンスは、処理が必要なキーバリュー（KV）RPCリクエストの数に依存します。一般的なKV RPCリクエストには、 `Point_Get` 、およびコプロセッサー`Batch_Point_Get`あります。 +TiDBは、SQLレイヤー（TiDBサーバー）とストレージレイヤー（TiKV）を分離した分散SQLデータベースです。従来のデータベースとは異なり、TiDBは計算ノードにデータをキャッシュするためにバッファプールを使用しません。そのため、SQLクエリのパフォーマンスとクラスタ全体のパフォーマンスは、処理が必要なキーバリュー（KV）RPCリクエストの数に依存します。一般的なKV RPCリクエストには、 `Point_Get`、`Batch_Point_Get`、およびコプロセッサーがあります。 TiDBのパフォーマンスを最適化するには、インデックスを効果的に使用することが不可欠です。インデックスはKV RPCリクエストの数を大幅に削減できるためです。KV RPCリクエストが減ることで、クエリのパフォーマンスとシステム効率が向上します。以下に、インデックスの最適化に役立つ主要な戦略をいくつか示します。 @@ -560,8 +560,8 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 1. 直接アクセスするには、インデックス プレフィックス列から始めます。 - 同等の条件を持つ列 - - 条件が`IS NULL`ある列 - - `IN`条件に1つの値（例： `IN (1)`が含まれる列 + - 条件が`IS NULL`である列 + - `IN`条件に1つの値（例： `IN (1)`）が含まれる列 2. 次に並べ替え用の列を追加します。 - インデックスでソート操作を処理できるようにする @@ -569,9 +569,9 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 - ソート順を維持する 3. 行の検索を減らすために追加のフィルタリング列を含めます。 - - 複数の値を持つ条件は`IN` + - 複数の値を持つ`IN`条件 - 日付時刻列の時間範囲条件 - - `!=` `<>`の他の非`IS NOT NULL`の`NOT IN` + - `!=`、`<>`、`NOT IN`、`IS NOT NULL`などのその他の非等価条件 4. カバリングインデックスを最大限に活用するには、 `SELECT`リストから列を追加するか、集計に使用します。 @@ -588,7 +588,7 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 - 書き込み時のパフォーマンスへの影響: - 非クラスター化インデックスを使用すると、シングルフェーズコミットの最適化の可能性が低くなります。 - - 追加のインデックスごと`DELETE`書き込み操作が遅くなります ( `INSERT`など) `UPDATE` + - 追加のインデックスごとに書き込み操作（`INSERT`、`UPDATE`、`DELETE`など）が遅くなります - データが変更された場合は、影響を受けるすべてのインデックスを更新する必要があります。 - テーブルに含まれるインデックスの数が増えるほど、書き込みパフォーマンスへの影響が大きくなります。 @@ -597,7 +597,7 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 - 頻繁にアクセスされるインデックスをキャッシュするには、より多くのメモリが必要です。 - バックアップおよびリカバリ操作に時間がかかります。 -- ホットスポットリスクを記述します: +- 書き込みホットスポットのリスク: - セカンダリインデックスは書き込みホットスポットを引き起こす可能性があります。例えば、単調に増加する日付時刻インデックスは、テーブルへの書き込み時にホットスポットを引き起こします。 - ホットスポットはパフォーマンスの大幅な低下につながる可能性があります。 @@ -688,7 +688,7 @@ LIMIT 実行プランには170ミリ秒の期間が表示されています。TiDBは`test_index`を使用して、フィルター`snapshot_id = 459840`で`IndexRangeScan_20`を実行します。次に、テーブルからすべての列を取得し、 `IndexLookUp_23`の後に5,715行をTiDBに返します。TiDBはこれらの行をソートし、1,000行を返します。 -列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`順序を保証しません。これは、列`test_idx`はインデックスプレフィックス列`snapshot_id`後に 2 つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。 +列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`は順序を保証しません。これは、`test_idx`はインデックスプレフィックス列`snapshot_id`後に 2 つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。 当初の計画は次のとおりです。 @@ -818,7 +818,7 @@ TiFlash を戦略的に使用することで、クエリパフォーマンスが TPC-Hクエリ14は、テーブル`order_line`とテーブル`item`結合を伴います。このクエリはTiKVでは**21.1秒**かかりますが、 TiFlash MPPモードではわずか**1.41秒**で実行され、15倍の速度向上が見込まれます。 - TiKVプラン：TiDBはテーブル`lineitem`から3,864,397行、テーブル`part`から1000万行を取得します。ハッシュ結合演算（ `HashJoin_21` ）と、それに続く射影演算（ `Projection_38` ）および集計演算（ `HashAgg_9` ）はTiDB内で実行されます。 -- TiFlashプラン：オプティマイザーは、テーブル数`order_line`と`item`両方でTiFlashレプリカを検出します。TiDBはコスト見積もりに基づいて自動的にMPPモードを選択し、クエリ全体をTiFlash列指向ストレージエンジン内で実行します。これにはテーブルスキャン、ハッシュ結合、列プロジェクション、集計が含まれ、TiKVプランと比較してパフォーマンスが大幅に向上します。 +- TiFlashプラン：オプティマイザーは、`order_line`と`item`の両方のテーブルでTiFlashレプリカを検出します。TiDBはコスト見積もりに基づいて自動的にMPPモードを選択し、クエリ全体をTiFlash列指向ストレージエンジン内で実行します。これにはテーブルスキャン、ハッシュ結合、列プロジェクション、集計が含まれ、TiKVプランと比較してパフォーマンスが大幅に向上します。 クエリは次のとおりです。 diff --git a/stale-read.md b/stale-read.md index be0f5023e4eec..daa0aabaf3ad4 100644 --- a/stale-read.md +++ b/stale-read.md @@ -5,7 +5,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 # ステイル読み取りの使用シナリオ {#usage-scenarios-of-stale-read} -このドキュメントでは、 ステイル読み取りの使用シナリオについて説明します。Stale ステイル読み取り は、TiDB が TiDB に保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、ストレージノード間のデータレプリケーションによって生じるレイテンシーを削減できます。 +このドキュメントでは、 ステイル読み取りの使用シナリオについて説明します。ステイル読み取りは、TiDB が TiDB に保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、ストレージノード間のデータレプリケーションによって生じるレイテンシーを削減できます。 ステイル読み取り を使用する場合、TiDBはデータ読み取りのためにレプリカをランダムに選択します。つまり、すべてのレプリカがデータ読み取りに利用可能になります。アプリケーションが非リアルタイムデータの読み取りを許容できない場合は、 ステイル読み取り を使用しないでください。そうしないと、レプリカから読み取られたデータがTiDBに書き込まれた最新のデータではない可能性があります。 @@ -39,7 +39,7 @@ TiDB は、次のようにステートメント レベル、セッション レ ### ステイル読み取りのレイテンシーを削減 {#reduce-stale-read-latency} -ステイル読み取り機能は、TiDBクラスタのResolved TSタイムスタンプを定期的に進め、TiDBがトランザクションの一貫性を満たすデータを読み取ることを保証します。Stale ステイル読み取りで使用されるタイムスタンプ（例： `AS OF TIMESTAMP '2016-10-08 16:45:26'` ）がResolved TSよりも大きい場合、 ステイル読み取りはTiDBにまずResolved TSを進めさせ、その完了を待ってからデータを読み取るようにトリガーします。これにより、レイテンシーが増加します。 +ステイル読み取り機能は、TiDBクラスタのResolved TSタイムスタンプを定期的に進め、TiDBがトランザクションの一貫性を満たすデータを読み取ることを保証します。ステイル読み取りで使用されるタイムスタンプ（例： `AS OF TIMESTAMP '2016-10-08 16:45:26'` ）がResolved TSよりも大きい場合、 ステイル読み取りはTiDBにまずResolved TSを進めさせ、その完了を待ってからデータを読み取るようにトリガーします。これにより、レイテンシーが増加します。 ステイル読み取りのレイテンシーを短縮するには、次の TiKV 構成項目を変更して、TiDB が解決された TS タイムスタンプをより頻繁に進めるようにします。 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 2d1bfdbdfed53..830eb57d6ce30 100644 --- a/statistics.md +++ b/statistics.md @@ -85,7 +85,7 @@ TiDBは、テーブルへの変更回数に基づいて、自動的に[`ANALYZE` ### ヒストグラム {#histogram} -ヒストグラム統計は、オプティマイザが区間または範囲述語の選択性を推定するために使用され、また、統計のバージョン 2 で等号/IN 述語を推定するために列内の異なる値の数を決定するためにも使用される場合があります (統計[統計のバージョン](#versions-of-statistics)を参照)。 +ヒストグラム統計は、オプティマイザが区間または範囲述語の選択性を推定するために使用され、また、統計のバージョン 2 で等号/IN 述語を推定するために列内の異なる値の数を決定するためにも使用される場合があります ( [統計のバージョン](#versions-of-statistics)を参照)。 ヒストグラムは、データの分布を近似的に表現したものです。値の全範囲を複数のバケットに分割し、各バケットに含まれる値の数など、単純なデータを用いて各バケットを記述します。TiDBでは、各テーブルの特定の列に対して等深ヒストグラムが作成されます。この等深ヒストグラムは、区間クエリの推定に利用できます。 @@ -103,16 +103,16 @@ TiDBは、テーブルへの変更回数に基づいて、自動的に[`ANALYZE` Count-Min Sketch はハッシュ構造です。 `a = 1`や`IN`クエリ (例えば`a IN (1, 2, 3)` ) のような等価性クエリを処理する際、TiDB はこのデータ構造を使用して推定を行います。 -Count-Min Sketch はハッシュ構造であるため、ハッシュ衝突が発生する可能性があります。EXPLAIN [`EXPLAIN`](/sql-statements/sql-statement-explain.md)において、同等のクエリの推定値が実際の値から大きく乖離する場合、より大きな値とより小さな値がハッシュ化されているとみなすことができます。この場合、ハッシュ衝突を回避するために、以下のいずれかの方法を取ることができます。 +Count-Min Sketch はハッシュ構造であるため、ハッシュ衝突が発生する可能性があります。[`EXPLAIN`](/sql-statements/sql-statement-explain.md)ステートメントにおいて、同等のクエリの推定値が実際の値から大きく乖離する場合、より大きな値とより小さな値がハッシュ化されているとみなすことができます。この場合、ハッシュ衝突を回避するために、以下のいずれかの方法を取ることができます。 -- `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 -- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 +- `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 +- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ### トップN {#top-n} トップN値とは、列またはインデックス内で出現頻度が最も高いN個の値のことです。トップN統計は、頻度統計またはデータスキューと呼ばれることもあります。 -TiDB は上位 N 個の値とその出現回数を記録します。ここでは`N`は`WITH NUM TOPN`パラメータによって制御されます。デフォルト値は 20 で、これは最も頻繁に出現する上位 20 個の値が収集されることを意味します。最大値は 1024 です。パラメータの詳細については、 を参照[手動収集](#manual-collection)てください。 +TiDB は上位 N 個の値とその出現回数を記録します。ここでは`N`は`WITH NUM TOPN`パラメータによって制御されます。デフォルト値は 20 で、これは最も頻繁に出現する上位 20 個の値が収集されることを意味します。最大値は 1024 です。パラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ## 選択的統計収集 {#selective-statistics-collection} @@ -218,7 +218,7 @@ TiDB は、パーティション分割されたテーブルに、パーティシ - 一部のパーティションで、すべての列または一部の列の統計情報が欠落している場合、TiDB はグローバル統計情報の生成時にこれらの欠落したパーティション統計情報をスキップするため、グローバル統計情報の生成には影響しません。 -動的プルーニングモードでは、パーティションとテーブルの`ANALYZE`構成は同じである必要があります。したがって、 `COLUMNS`ステートメントの後に`ANALYZE TABLE TableName PARTITION PartitionNameList` }構成を指定した場合、または`OPTIONS`の後に`WITH` }構成を指定した場合、TiDBはそれらを無視して警告を返します。 +動的プルーニングモードでは、パーティションとテーブルの`ANALYZE`構成は同じである必要があります。したがって、`ANALYZE TABLE TableName PARTITION PartitionNameList`ステートメントの後に`COLUMNS`構成を指定した場合、または`WITH`の後に`OPTIONS`構成を指定した場合、TiDBはそれらを無視して警告を返します。 ## 収集パフォーマンスを向上させる {#improve-collection-performance} @@ -300,7 +300,7 @@ auto analyze操作に使用される特定のテーブルに保持されてい SELECT sample_num, sample_rate, buckets, topn, column_choice, column_ids FROM mysql.analyze_options opt JOIN information_schema.tables tbl ON opt.table_id = tbl.tidb_table_id WHERE tbl.table_schema = '{db_name}' AND tbl.table_name = '{table_name}'; ``` -TiDB は、最新の`ANALYZE`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。たとえば、 `ANALYZE TABLE t WITH 200 TOPN;`を実行すると、 `ANALYZE`ステートメントの上位 200 個の値が設定されます。その後、 `ANALYZE TABLE t WITH 0.1 SAMPLERATE;`を実行すると、 `ANALYZE`と同様に、自動`ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;` 。 +TiDB は、最新の`ANALYZE`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。たとえば、 `ANALYZE TABLE t WITH 200 TOPN;`を実行すると、 `ANALYZE`ステートメントの上位 200 個の値が設定されます。その後、 `ANALYZE TABLE t WITH 0.1 SAMPLERATE;`を実行すると、 自動`ANALYZE`ステートメントに上位200個の値とサンプリングレート0.1の両方を設定します。これは`ANALYZE TABLE t WITH 200 TOPN, 0.1 SAMPLERATE;`と同様です。 ### ANALYZE構成の永続化を無効にする {#disable-analyze-configuration-persistence} @@ -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`ステートメントで指定された新しい構成を使用して、以前に記録された永続構成を上書きします。 @@ -413,7 +413,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; `ANALYZE`の状態と統計情報は、以下のステートメントを使用して表示できます。 -### 状態ANALYZE {#code-analyze-code-state} +### ANALYZE状態 {#code-analyze-code-state} `ANALYZE`ステートメントを実行すると、 [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md)を使用して`ANALYZE`の現在の状態を表示できます。 @@ -498,7 +498,7 @@ TiDBの起動時、初期統計情報が完全にロードされる前に実行 -## 輸出入統計 {#export-and-import-statistics} +## 統計情報のエクスポートとインポート {#export-and-import-statistics} このセクションでは、統計情報のエクスポートとインポートの方法について説明します。 @@ -510,11 +510,11 @@ TiDBの起動時、初期統計情報が完全にロードされる前に実行 -### 輸出統計 {#export-statistics} +### 統計情報のエクスポート {#export-statistics} 統計情報をエクスポートするためのインターフェースは以下のとおりです。 -- `${table_name}`データベース内の`${db_name}`テーブルの JSON 形式の統計情報を取得するには： +- `${db_name}`データベース内の`${table_name}`テーブルの JSON 形式の統計情報を取得するには： http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name} @@ -524,7 +524,7 @@ TiDBの起動時、初期統計情報が完全にロードされる前に実行 curl -s http://127.0.0.1:10080/stats/dump/test/t1 -o /tmp/t1.json ``` -- `${table_name}` `${db_name}`テーブルの特定の時刻における JSON 形式の統計情報を取得するには： +- `${db_name}`データベース内の`${table_name}`テーブルの特定の時刻における JSON 形式の統計情報を取得するには： http://${tidb-server-ip}:${tidb-server-status-port}/stats/dump/${db_name}/${table_name}/${yyyyMMddHHmmss} @@ -599,7 +599,7 @@ mysql> SHOW WARNINGS; 2 rows in set (0.00 sec) ``` -テーブル`t`と`ANALYZE`の統計情報をロック解除して、再度実行できます。 +テーブル`t`の統計情報をロック解除すると、`ANALYZE`を再度正常に実行できます。 ```sql mysql> UNLOCK STATS t; @@ -673,7 +673,7 @@ mysql> SHOW WARNINGS; 2 rows in set (0.00 sec) ``` -パーティション`p1`と`ANALYZE`の統計情報のロック解除を再度正常に実行できます。 +パーティション`p1`の統計情報のロックを解除すると、`ANALYZE`を再度正常に実行できます。 ```sql mysql> UNLOCK STATS t PARTITION p1; @@ -718,20 +718,20 @@ TiDB v6.0以降、TiDBは`KILL`ステートメントを使用して、バック SHOW ANALYZE STATUS ``` - 結果の`instance`列と`process_id`列を確認することで、TiDB インスタンス アドレスと、バックグラウンド`ID`タスクのタスク`ANALYZE`を取得できます。 + 結果の`instance`列と`process_id`列を確認することで、TiDB インスタンス アドレスと、バックグラウンド`ANALYZE`タスクのタスク`ID`を取得できます。 2. バックグラウンドで実行されている`ANALYZE`タスクを終了します。 - - [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610)が`true` (デフォルトでは`true` ) の場合、 `KILL TIDB ${id};`ステートメントを直接実行できます。ここで、 `${id}`は、前の手順で取得したバックグラウンド`ID`タスクの`ANALYZE`です。 + - [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610)が`true` (デフォルトでは`true` ) の場合、 `KILL TIDB ${id};`ステートメントを直接実行できます。ここで、 `${id}`は、前の手順で取得したバックグラウンド`ANALYZE`タスクの`ID`です。 - `enable-global-kill`が`false`の場合、クライアントを使用してバックエンドの`ANALYZE`タスクを実行している TiDB インスタンスに接続し、 `KILL TIDB ${id};`ステートメントを実行する必要があります。クライアントを使用して別の TiDB インスタンスに接続する場合、またはクライアントと TiDB クラスタの間にプロキシがある場合、 `KILL`ステートメントではバックグラウンド`ANALYZE`タスクを終了できません。 - `ANALYZE`タスクを終了するには、 `KILL TIDB ${id};`ステートメントを実行します。ここで、 `${id}`は、前の手順で取得したバックグラウンド`ID`タスクの`ANALYZE`です。 + `ANALYZE`タスクを終了するには、 `KILL TIDB ${id};`ステートメントを実行します。ここで、 `${id}`は、前の手順で取得したバックグラウンド`ANALYZE`タスクの`ID`です。 diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index 572a43fdd399a..5c2159a9c2318 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -11,7 +11,7 @@ summary: Titan の設定方法を学びます。 > **Note:** > -> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。1 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 +> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 > - v7.6.0 以降のバージョンにアップグレードされた既存のクラスターは元の構成を保持します。つまり、Titan が明示的に有効になっていない場合は、引き続き RocksDB が使用されます。 > - クラスタをTiDB v7.6.0以降のバージョンにアップグレードする前にTitanを有効にしていた場合、アップグレード後もTitanが有効になり、アップグレード前の設定値[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)も保持されます。アップグレード前に明示的に値を設定しない場合は、アップグレード後のクラスタ構成の安定性を確保するために、旧バージョンのデフォルト値`1KB`が保持されます。 @@ -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/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 4017686826b56..50d17a551530c 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -27,7 +27,7 @@ Titan は、大量のデータが TiKV フォアグラウンドに書き込ま Titan を有効にするための前提条件は次のとおりです。 -- 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。1 [`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 +- 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 - 範囲クエリは実行されないか、高い範囲クエリのパフォーマンスを必要としません。Titan に格納されるデータは整列されていないため、範囲クエリのパフォーマンスは RocksDB よりも低く、特に広い範囲のクエリではその傾向が顕著です。PingCAP の内部テストによると、Titan の範囲クエリのパフォーマンスは RocksDB よりも 40% から数倍低いことが示されています。 - 十分なディスク容量（同じデータ量でRocksDBのディスク消費量の2倍の容量を確保することを検討してください）。これは、Titanがディスク容量を犠牲にして書き込み増幅を削減するためです。また、Titanは値を1つずつ圧縮するため、圧縮率はRocksDBよりも低くなります。RocksDBはブロックを1つずつ圧縮するため、TitanはRocksDBよりも多くのストレージ容量を消費しますが、これは想定内の正常な動作です。状況によっては、Titanのストレージ消費量がRocksDBの2倍になる場合があります。 diff --git a/subquery-optimization.md b/subquery-optimization.md index 81ec71af804a7..8144f78aa48b0 100644 --- a/subquery-optimization.md +++ b/subquery-optimization.md @@ -62,7 +62,7 @@ explain select * from t1 where t1.a in (select t2.a from t2); +------------------------------+---------+-----------+------------------------+----------------------------------------------------------------------------+ ``` -この書き換えは、 `IN`サブクエリが比較的小さく、外部クエリが比較的大きい場合にパフォーマンスが向上します。これは、書き換えを行わないと、t2を駆動テーブルとして`index join`のサブクエリを使用することが不可能になるためです。ただし、書き換え中に集計を自動的に削除できず、 `t2`番目のテーブルが比較的大きい場合、この書き換えがクエリのパフォーマンスに影響を与えるという欠点があります。現在、この最適化を制御するために変数[tidb_opt_insubq_to_join_and_agg](/system-variables.md#tidb_opt_insubq_to_join_and_agg)が使用されています。この最適化が適切でない場合は、手動で無効にすることができます。 +この書き換えは、 `IN`サブクエリが比較的小さく、外部クエリが比較的大きい場合にパフォーマンスが向上します。これは、書き換えを行わないと、t2を駆動テーブルとして`index join`のサブクエリを使用することが不可能になるためです。ただし、書き換え中に集計を自動的に削除できず、 `t2`テーブルが比較的大きい場合、この書き換えがクエリのパフォーマンスに影響を与えるという欠点があります。現在、この最適化を制御するために変数[tidb_opt_insubq_to_join_and_agg](/system-variables.md#tidb_opt_insubq_to_join_and_agg)が使用されています。この最適化が適切でない場合は、手動で無効にすることができます。 ## EXISTSサブクエリと... >/>=/</<=/=/!= (SELECT ... FROM ...) {#code-exists-code-subquery-and-code-x3c-x3c-select-from-code} diff --git a/system-variables.md b/system-variables.md index 777a99d061302..49da5c83d2a1f 100644 --- a/system-variables.md +++ b/system-variables.md @@ -58,7 +58,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- `AUTO_RANDOM`ステートメントで、 `INSERT` -E}} 属性を持つ列の値を明示的に指定することを許可するかどうかを決定します。 +- `INSERT`ステートメントで、 `AUTO_RANDOM`属性を持つ列の値を明示的に指定することを許可するかどうかを決定します。 ### authentication_ldap_sasl_auth_method_name New in v7.1.0 @@ -622,7 +622,7 @@ mysql> SELECT * FROM t1; - 範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean -- この変数は、前のステートメントで使用された実行計画が[計画の製図](/sql-plan-management.md)の影響を受けたかどうかを示すために使用されます。 +- この変数は、前のステートメントで使用された実行計画が[プランバインディング](/sql-plan-management.md)の影響を受けたかどうかを示すために使用されます。 ### last_plan_from_cache New in v4.0 @@ -957,7 +957,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; -- この変数を有効にし、TiDB Data Migration (DM) を使用してデータを移行している場合は、 [DMタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)ファイルの`sql_require_ primary_key`部分に`session`を追加し、それを`OFF`に設定することをお勧めします。そうしないと、DM がタスクを作成できなくなります。 +- この変数を有効にし、TiDB Data Migration (DM) を使用してデータを移行している場合は、 [DMタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)ファイルの`session`部分に`sql_require_ primary_key`を追加し、それを`OFF`に設定することをお勧めします。そうしないと、DM がタスクを作成できなくなります。 @@ -1037,7 +1037,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 適用範囲：なし - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値：（システム依存） -- この変数は、TiDBが最初にブートストラップされた時点のシステムタイムゾーンを示します[`time_zone`](#time_zone)も参照してください。 +- この変数は、TiDBが最初にブートストラップされた時点のシステムタイムゾーンを示します。[`time_zone`](#time_zone)も参照してください。 ### tidb_adaptive_closest_read_threshold New in v6.3.0 @@ -1098,7 +1098,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - 適用範囲：なし - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `json_array, json_array_append, json_array_insert, json_contains, json_contains_path, json_depth, json_extract, json_insert, json_keys, json_length, json_merge_patch, json_merge_preserve, json_object, json_pretty, json_quote, json_remove, json_replace, json_schema_valid, json_search, json_set, json_storage_size, json_type, json_unquote, json_valid, lower, md5, reverse, tidb_shard, upper, vitess_hash` -- この読み取り専用変数は、 [発現指数](/sql-statements/sql-statement-create-index.md#expression-index)を作成するために使用できる関数を表示するために使用されます。 +- この読み取り専用変数は、 [式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を作成するために使用できる関数を表示するために使用されます。 ### tidb_allow_mpp New in v5.0 @@ -1111,7 +1111,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - `0`または`OFF`に設定すると、MPP モードは使用されません。v7.3.0 以降のバージョンでは、この変数の値を`0`または`OFF`に設定する場合は、 [`tidb_allow_tiflash_cop`](/system-variables.md#tidb_allow_tiflash_cop-new-in-v730)変数も有効にする必要があります。そうしないと、クエリでエラーが発生する可能性があります。 - `1`または`ON`は、オプティマイザがコスト見積もりに基づいて MPP モードを使用するかどうかを決定することを意味します (デフォルト)。 -MPP は、 TiFlashエンジンによって提供される分散コンピューティング フレームワークであり、ノード間のデータ交換を可能にし、高性能、高スループットの SQL アルゴリズムを提供します。 MPPモードの選択の詳細については、 [MPPモードを選択するかどうかを制御する](/tiflash/use-tiflash-mpp-mode.md#control-whether-to-select-the-mpp-mode)。 +MPP は、 TiFlashエンジンによって提供される分散コンピューティング フレームワークであり、ノード間のデータ交換を可能にし、高性能、高スループットの SQL アルゴリズムを提供します。 MPPモードの選択の詳細については、 [MPPモードを選択するかどうかを制御する](/tiflash/use-tiflash-mpp-mode.md#control-whether-to-select-the-mpp-mode)を参照してください。 ### tidb_allow_remove_auto_inc New in v2.1.18 and v3.0.4 @@ -1144,7 +1144,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Enumeration - デフォルト値: `ALL` - 値のオプション: `ALL` 、 `PREDICATE` -- この変数は`ANALYZE TABLE`ステートメントの動作を制御します。 `PREDICATE`に設定すると、列挙[述語列](/statistics.md#collect-statistics-on-some-columns)の統計情報のみが収集されます。 `ALL`に設定すると、すべての列の統計情報が収集されます。OLAP クエリを使用するシナリオでは、 `ALL`に設定することをお勧めします。そうしないと、統計情報の収集によってクエリのパフォーマンスが著しく低下する可能性があります。 +- この変数は`ANALYZE TABLE`ステートメントの動作を制御します。 `PREDICATE`に設定すると、[述語列](/statistics.md#collect-statistics-on-some-columns)の統計情報のみが収集されます。 `ALL`に設定すると、すべての列の統計情報が収集されます。OLAP クエリを使用するシナリオでは、 `ALL`に設定することをお勧めします。そうしないと、統計情報の収集によってクエリのパフォーマンスが著しく低下する可能性があります。 ### tidb_analyze_distsql_scan_concurrency New in v7.6.0 @@ -1273,7 +1273,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` -- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000` UTC の午前 1:00 を指します。 +- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000`は UTC の午前 1:00 を指します。 ### tidb_auto_analyze_partition_batch_size New in v6.4.0 @@ -1282,7 +1282,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `8192` 。v7.6.0 より前のバージョンでは、デフォルト値は`1`です。v7.6.0 から v8.1.x までのバージョンでは、デフォルト値は`128`です。v8.2.0 以降では、デフォルト値は`8192`に変更されます。 - 範囲: `[1, 8192]` 。v8.2.0 より前は、値の範囲は`[1, 1024]`です。 -- この変数は、パーティションテーブルを分析するときに TiDB が[自動的に分析します](/statistics.md#automatic-update)パーティションの数を指定します (つまり、パーティションテーブルに関する統計を自動的に収集します)。 +- この変数は、パーティションテーブルを分析するときに TiDB が[自動的に分析する](/statistics.md#automatic-update)パーティションの数を指定します (つまり、パーティションテーブルに関する統計を自動的に収集します)。 - この変数の値がパーティション数より小さい場合、TiDB はパーティションテーブルのすべてのパーティションを複数回に分けて自動的に分析します。この変数の値がパーティション数以上の場合、TiDB はパーティションテーブルのすべてのパーティションを同時に分析します。 - パーティションテーブルのパーティション数がこの変数の値よりもはるかに多く、自動分析に時間がかかる場合は、この変数の値を増やすことで処理時間を短縮できます。 @@ -1317,7 +1317,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - `tidb_auto_analyze_start_time='01:00 +0000'` - `tidb_auto_analyze_end_time='03:00 +0000'` -- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000` UTC の午前 1:00 を指します。 +- パラメータ内の時刻にタイムゾーン情報が含まれている場合、そのタイムゾーンが解析に使用されます。そうでない場合は、現在のセッションの`time_zone`で指定されたタイムゾーンが使用されます。たとえば、 `01:00 +0000`は UTC の午前 1:00 を指します。 ### tidb_auto_build_stats_concurrency New in v6.5.0 @@ -1568,7 +1568,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー -- デフォルト値: デフォルトでは、 [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)設定項目は`true`なので、この変数のデフォルト値は`ON`です。pessimistic [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)が`false`に設定されている場合、この変数のデフォルト値は`OFF`です。 +- デフォルト値: デフォルトでは、 [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)設定項目は`true`なので、この変数のデフォルト値は`ON`です。[`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)が`false`に設定されている場合、この変数のデフォルト値は`OFF`です。 @@ -1624,7 +1624,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: 整数 - デフォルト値: `2` -- お得なオプション： +- 値のオプション： - `1` : TiDB v6.4.0 以前のバージョンでデフォルトで使用されているコストモデルバージョン 1 を有効にします。 - `2` :[コストモデル バージョン2](/cost-model.md#cost-model-version-2)を有効にします。これは TiDB v6.5.0 で一般提供されており、内部テストではバージョン 1 よりも正確です。 - コスト モデルのバージョンは、オプティマイザーの計画決定に影響します。詳細については、[コストモデル](/cost-model.md)を参照してください。 @@ -1668,7 +1668,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `ON` - この変数は`ADD INDEX`と`CREATE INDEX`の高速化を有効にして、インデックス作成時のバックフィル速度を向上させるかどうかを制御します。この変数の値を`ON`に設定すると、大量のデータを含むテーブルのインデックス作成のパフォーマンスが向上します。 - バージョン7.1.0以降、インデックス高速化処理はチェックポイントをサポートしています。障害によりTiDBオーナーノードが再起動または変更された場合でも、TiDBは定期的に自動更新されるチェックポイントから処理の進行状況を回復できます。 -- 完了した`ADD INDEX`操作が高速化されているかどうかを確認するには、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-jobs)ステートメントを実行して、 `ingest`列に`JOB_TYPE`が表示されるかどうかを確認します。 +- 完了した`ADD INDEX`操作が高速化されているかどうかを確認するには、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-jobs)ステートメントを実行して、 `JOB_TYPE`列に`ingest`が表示されるかどうかを確認します。 @@ -1785,7 +1785,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Enumeration - デフォルト値: `PRIORITY_LOW` - 値のオプション: `PRIORITY_LOW` 、 `PRIORITY_NORMAL` 、 `PRIORITY_HIGH` -- この変数は`ADD INDEX`フェーズで`re-organize` } 操作を実行する優先順位を設定するために使用されます。 +- この変数は`re-organize`フェーズで`ADD INDEX`操作を実行する優先順位を設定するために使用されます。 - この変数の値を`PRIORITY_LOW` 、 `PRIORITY_NORMAL`または`PRIORITY_HIGH`に設定できます。 ### tidb_ddl_reorg_max_write_speed New in v6.5.12, v7.5.5, and v8.5.0 @@ -1851,8 +1851,8 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Float - デフォルト値: `0.8` - 範囲: `[0, 1]` -- この変数は、行数を推定する際のフィルタ条件における`like` 、 `rlike` 、および`regexp`関数のデフォルトの選択性を設定するために関数。また、この変数は、これらの関数の推定を支援するために TopN を有効にするかどうかも制御します。 -- TiDB は統計情報を使用してフィルタ条件`like`を推定しようとします。しかし、 `like`複雑な文字列に一致する場合、または`rlike`や`regexp`を使用する場合、TiDB は統計情報を十分に使用できないことが多く、代わりにデフォルト値`0.8`が選択率として設定され、推定が不正確になります。 +- この変数は、行数を推定する際のフィルタ条件における`like` 、 `rlike` 、および`regexp`関数のデフォルトの選択性を設定するために使用されます。また、この変数は、これらの関数の推定を支援するために TopN を有効にするかどうかも制御します。 +- TiDB は統計情報を使用してフィルタ条件`like`を推定しようとします。しかし、 `like`が複雑な文字列に一致する場合、または`rlike`や`regexp`を使用する場合、TiDB は統計情報を十分に使用できないことが多く、代わりにデフォルト値`0.8`が選択率として設定され、推定が不正確になります。 - この変数は、前述の動作を変更するために使用されます。変数が`0`以外の値に設定されている場合、選択率は`0.8`ではなく、指定された変数の値になります。 - 変数が`0`に設定されている場合、TiDB は統計情報で TopN を使用して評価し、精度を向上させ、前述の 3 つの関数を推定する際に統計情報で NULL の数を考慮します。前提条件として、 [`tidb_analyze_version`](#tidb_analyze_version-new-in-v510)が`2`に設定されているときに統計情報が収集されます。このような評価は、パフォーマンスに若干影響を与える可能性があります。 - 変数が`0.8`以外の値に設定されている場合、TiDB は`not like` 、 `not rlike` 、および`not regexp`の推定値をそれに応じて調整します。 @@ -1902,7 +1902,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - OLAPシナリオの場合、最大値はすべてのTiKVノードのCPUコア数を超えてはなりません。 - テーブルにパーティションが多数ある場合、変数値を適切に減らすことで（スキャンするデータのサイズとスキャンの頻度によって決まります）、TiKVがメモリ不足（OOM）になるのを防ぐことができます。 - `LIMIT`句のみを含む単純なクエリの場合、 `LIMIT`の値が100000未満であれば、TiKVにプッシュダウンされるスキャン操作では、実行効率を高めるためにこの変数の値を`1`として扱います。 -- `SELECT MAX/MIN(col) FROM ...`クエリの場合、 `col`列に`MAX(col)`または`MIN(col)`関数で要求されるのと同じ順序でソートされたインデックスがある場合、TiDB はクエリを`SELECT col FROM ... LIMIT 1`に書き換えて処理し、この変数の値も`1`として処理されます。例えば、 `SELECT MIN(col) FROM ...`の場合、 `col`列に昇順インデックスがある場合、TiDB はクエリを`MIN(col)`に書き換えてインデックスの最初の行を直接読み取ることで、 `SELECT col FROM ... LIMIT 1`の値をすばやく取得できます。 +- `SELECT MAX/MIN(col) FROM ...`クエリの場合、 `col`列に`MAX(col)`または`MIN(col)`関数で要求されるのと同じ順序でソートされたインデックスがある場合、TiDB はクエリを`SELECT col FROM ... LIMIT 1`に書き換えて処理し、この変数の値も`1`として処理されます。例えば、 `SELECT MIN(col) FROM ...`の場合、 `col`列に昇順インデックスがある場合、TiDB はクエリを`SELECT col FROM ... LIMIT 1`に書き換えてインデックスの最初の行を直接読み取ることで、 `MIN(col)`の値をすばやく取得できます。 - [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md)テーブルに対するクエリの場合、この変数はスローログファイルの解析における同時実行数を制御します。 ### tidb_dml_batch_size @@ -2094,7 +2094,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Enumeration - デフォルト値: `ON` - 指定可能な値: `OFF` 、 `ON` 、 `INT_ONLY` -- この変数は、主キー[クラスター化インデックス](/clustered-indexes.md)化 として作成するかどうかを制御するために使用されます。ここで「デフォルト」とは、ステートメントがキーワード`CLUSTERED` / `NONCLUSTERED`を明示的に指定しないことを意味します。サポートされている値は`OFF` 、 `ON` 、および`INT_ONLY`です。 +- この変数は、主キー[クラスター化インデックス](/clustered-indexes.md)として作成するかどうかを制御するために使用されます。ここで「デフォルト」とは、ステートメントがキーワード`CLUSTERED` / `NONCLUSTERED`を明示的に指定しないことを意味します。サポートされている値は`OFF` 、 `ON` 、および`INT_ONLY`です。 - `OFF`は、主キーがデフォルトで非クラスター化インデックスとして作成されることを示します。 - `ON`は、主キーがデフォルトでクラスター化インデックスとして作成されることを示します。 - `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、すべての主キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成される主キーのみがクラスター化インデックスとして作成されます。 @@ -2262,7 +2262,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)インデックスの作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`を指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 +- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)の作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`を指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 - この変数は v8.4.0 以降非推奨になりました。その値はデフォルト値`ON`に固定されています。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 ### tidb_enable_lazy_cursor_fetch New in v8.3.0 @@ -2285,7 +2285,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - この変数によって制御される機能には、以下の制限があります。 - 明示的なトランザクション内のステートメントはサポートしていません。 - 実行プランは、 `TableReader` 、 `IndexReader` 、`IndexLookUp`、 `Projection` `IndexLookUp` 、および`Selection`演算子のみを含む実行プランのみをサポートします。 - - Lazy Cursor Fetch を使用するステートメントの場合、実行情報は[ステートメントの概要](/statement-summary-tables.md)と[スロークエリログ](/identify-slow-queries.md)ログに表示されません。 + - Lazy Cursor Fetch を使用するステートメントの場合、実行情報は[ステートメントの概要](/statement-summary-tables.md)と[スロークエリログ](/identify-slow-queries.md)に表示されません。 - サポートされていないシナリオの場合、この変数を`OFF`に設定した場合と同じ動作になります。 @@ -2304,7 +2304,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - この変数によって制御される機能には、以下の制限があります。 - 明示的なトランザクション内のステートメントはサポートしていません。 - 実行プランは、 `TableReader` 、 `IndexReader` 、`IndexLookUp`、 `Projection` `IndexLookUp` 、および`Selection`演算子のみを含む実行プランのみをサポートします。 - - Lazy Cursor Fetch を使用するステートメントの場合、実行情報は[ステートメントの概要](/statement-summary-tables.md)と[スロークエリログ](https://docs.pingcap.com/tidb/stable/identify-slow-queries)ログに表示されません。 + - Lazy Cursor Fetch を使用するステートメントの場合、実行情報は[ステートメントの概要](/statement-summary-tables.md)と[スロークエリログ](https://docs.pingcap.com/tidb/stable/identify-slow-queries)に表示されません。 - サポートされていないシナリオの場合、この変数を`OFF`に設定した場合と同じ動作になります。 @@ -2330,7 +2330,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` 。 -- この変数は、DML ステートメントの[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)キャッシュ機能を有効にするかどうかを制御します。 +- この変数は、DML ステートメントの[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)機能を有効にするかどうかを制御します。 ### tidb_enable_cache_prepare_stmt New in v8.5.7 > **Warning:** @@ -2678,7 +2678,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は[`PLAN REPLAYER CONTINUOUS CAPTURE`機能）](/sql-plan-replayer.md#use-plan-replayer-continuous-capture)を有効にするかどうかを制御します。デフォルト値の`OFF`は、この機能を無効にすることを意味します。 +- この変数は[`PLAN REPLAYER CONTINUOUS CAPTURE`機能](/sql-plan-replayer.md#use-plan-replayer-continuous-capture)を有効にするかどうかを制御します。デフォルト値の`OFF`は、この機能を無効にすることを意味します。 @@ -2875,7 +2875,7 @@ Query OK, 0 rows affected (0.09 sec) > **Note:** > -> この設定は`DOUBLE`型に対して精度指定がMySQLで許可されているため、 `FLOAT`型にのみ適用されます。この動作はMySQL 8.0.17以降非推奨となり、 `FLOAT`型または`DOUBLE`型に対して精度指定を行うことは推奨されません。 +> この設定は、MySQLが`FLOAT`型に対して精度指定を許可しているため、`DOUBLE`型にのみ適用されます。この動作はMySQL 8.0.17以降非推奨となり、 `FLOAT`型または`DOUBLE`型に対して精度指定を行うことは推奨されません。 ### tidb_enable_table_partition @@ -2924,7 +2924,7 @@ Query OK, 0 rows affected (0.09 sec) - `SELECT`ステートメント内の`INSERT INTO SELECT`クエリ (一般的な使用シナリオ:[TiFlashクエリ結果の具体化](/tiflash/tiflash-results-materialization.md)) - `WHERE`および`UPDATE`ステートメントにおける`DELETE`条件フィルタリング -- バージョン7.1.0以降、この変数は非推奨となりました。tidb_allow_mpp [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに判断します。 TiDB では`INSERT` 、 `DELETE` 、および`UPDATE` (例えば`INSERT INTO SELECT` ) を含む SQL ステートメントの読み取り操作をTiFlashにプッシュダウンできるのは、現在のセッションの[SQLモード](/sql-mode.md)厳密でない場合のみであることに注意してください。つまり、 `sql_mode`の値には`STRICT_TRANS_TABLES`および`STRICT_ALL_TABLES`は含まれません。 +- バージョン7.1.0以降、この変数は非推奨となりました。[`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに判断します。 TiDB では`INSERT` 、 `DELETE` 、および`UPDATE` (例えば`INSERT INTO SELECT` ) を含む SQL ステートメントの読み取り操作をTiFlashにプッシュダウンできるのは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合のみであることに注意してください。つまり、 `sql_mode`の値には`STRICT_TRANS_TABLES`および`STRICT_ALL_TABLES`は含まれません。 ### tidb_enable_top_sql New in v5.4.0 @@ -3037,7 +3037,7 @@ Query OK, 0 rows affected (0.09 sec) - `0`または`OFF`は、MPP モードが強制的に使用されないことを意味します (デフォルトでは)。 - `1`または`ON`の場合、コスト見積もりは無視され、MPP モードが強制的に使用されます。この設定は`tidb_allow_mpp=true`の場合にのみ有効になることに注意してください。 -MPP は、 TiFlashエンジンによって提供される分散コンピューティング フレームワークであり、ノード間のデータ交換を可能にし、高性能、高スループットの SQL アルゴリズムを提供します。 MPPモードの選択の詳細については、 [MPPモードを選択するかどうかを制御する](/tiflash/use-tiflash-mpp-mode.md#control-whether-to-select-the-mpp-mode)。 +MPP は、 TiFlashエンジンによって提供される分散コンピューティング フレームワークであり、ノード間のデータ交換を可能にし、高性能、高スループットの SQL アルゴリズムを提供します。 MPPモードの選択の詳細については、 [MPPモードを選択するかどうかを制御する](/tiflash/use-tiflash-mpp-mode.md#control-whether-to-select-the-mpp-mode)を参照してください。 ### tidb_evolve_plan_baselines New in v4.0 @@ -3082,7 +3082,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Time - デフォルト値: `00:00 +0000` -- この変数は、1日におけるベースライン変化の開始時刻を設定するために使用されます。 +- この変数は、1日におけるベースライン進化の開始時刻を設定するために使用されます。 ### tidb_executor_concurrency New in v5.0 @@ -3171,7 +3171,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **Note:** > -> バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。 を使用して[リソース制御](/tidb-resource-control-ru-groups.md)異なるSQLステートメントのリソース使用量を管理することをお勧めします。 +> バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)をサポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。[リソース制御](/tidb-resource-control-ru-groups.md)を使用して異なるSQLステートメントのリソース使用量を管理することをお勧めします。 ### tidb_foreign_key_check_in_shared_lock New in v8.5.6 @@ -3674,7 +3674,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Float - デフォルト値: `0.1` - 範囲: `[0, 1]` -- この変数は、メモリ削除後に[インスタンスプランキャッシュ](#tidb_enable_instance_plan_cache-new-in-v840)プラン キャッシュ用に予約されるアイドルメモリの割合を制御します。インスタンス プラン キャッシュで使用されるメモリが[`tidb_instance_plan_cache_max_size`](#tidb_instance_plan_cache_max_size-new-in-v840)で設定された制限に達すると、TiDB はアイドル メモリの割合が[`tidb_instance_plan_cache_reserved_percentage`](#tidb_instance_plan_cache_reserved_percentage-new-in-v840)で設定された値を超えるまで、Least Recently Used (LRU) アルゴリズムを使用してメモリからメモリプランを削除し始めます。 +- この変数は、メモリ削除後に[インスタンスプランキャッシュ](#tidb_enable_instance_plan_cache-new-in-v840)用に予約されるアイドルメモリの割合を制御します。インスタンス プラン キャッシュで使用されるメモリが[`tidb_instance_plan_cache_max_size`](#tidb_instance_plan_cache_max_size-new-in-v840)で設定された制限に達すると、TiDB はアイドル メモリの割合が[`tidb_instance_plan_cache_reserved_percentage`](#tidb_instance_plan_cache_reserved_percentage-new-in-v840)で設定された値を超えるまで、Least Recently Used (LRU) アルゴリズムを使用してメモリからメモリプランを削除し始めます。 ### tidb_instance_plan_cache_max_size New in v8.4.0 @@ -4045,7 +4045,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 範囲: `[0, 9223372036854775807]` - 単位：バイト - この変数は`Apply`演算子のローカル キャッシュのメモリ使用量しきい値を設定するために使用されます。 -- `Apply`演算子のローカルキャッシュは`Apply`演算子の計算を高速化するために使用されます。 `0`変数を設定すると、 `Apply`キャッシュ機能を無効にできます。 +- `Apply`演算子のローカルキャッシュは`Apply`演算子の計算を高速化するために使用されます。 変数を`0`に設定すると、 `Apply`キャッシュ機能を無効にできます。 ### tidb_mem_quota_binding_cache New in v6.0.0 @@ -4384,7 +4384,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、オプティマイザが`distinct` （例えば`select count(distinct a) from t` ）を持つ集約関数をコプロセッサーために使用されます。 +- この変数は、オプティマイザが`distinct` （例えば`select count(distinct a) from t` ）を持つ集約関数をコプロセッサーにプッシュダウンする最適化操作を実行するかどうかを設定するために使用されます。 - クエリで`distinct`操作を含む集計関数が遅い場合は、変数の値を`1`に設定できます。 次の例では、 `tidb_opt_distinct_agg_push_down`が有効になる前に、TiDB は TiKV からすべてのデータを読み取り、TiDB 側で`distinct`を実行する必要があります。 `tidb_opt_distinct_agg_push_down`が有効になると、 `distinct a`がコプロセッサーにプッシュダウンされ、 `group by`列`test.t.a`が`HashAgg_5`に追加されます。 @@ -4441,7 +4441,7 @@ mysql> desc select count(distinct a) from test.t; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は`EXPLAIN`ステートメントが最適化段階で展開可能な定数サブクエリの実行を無効にするかどうかを制御するために使用されます。この変数が`OFF`に設定されている場合、 `EXPLAIN`ステートメントは最適化段階でサブクエリを事前に展開します。この変数が`ON`に設定されている場合、 `EXPLAIN`ステートメントは最適化段階で[サブクエリ展開を無効にする](/explain-walkthrough.md#disable-the-early-execution-of-subqueries)を展開しません。詳細については、 を参照してください。 +- この変数は`EXPLAIN`ステートメントが最適化段階で展開可能な定数サブクエリの実行を無効にするかどうかを制御するために使用されます。この変数が`OFF`に設定されている場合、 `EXPLAIN`ステートメントは最適化段階でサブクエリを事前に展開します。この変数が`ON`に設定されている場合、 `EXPLAIN`ステートメントは最適化段階でサブクエリを展開しません。詳細については、[サブクエリ展開を無効にする](/explain-walkthrough.md#disable-the-early-execution-of-subqueries)を参照してください。 ### tidb_opt_enable_late_materialization New in v7.0.0 @@ -4451,7 +4451,7 @@ mysql> desc select count(distinct a) from test.t; - 型: Boolean - デフォルト値: `ON` - この変数は、 [TiFlashの遅延マテリアライゼーション](/tiflash/tiflash-late-materialization.md)機能を有効にするかどうかを制御するために使用されます。 TiFlash の遅延マテリアライゼーションは[高速スキャンモード](/tiflash/use-fastscan.md)では有効にならないことに注意してください。 -- この変数を`OFF`に設定してTiFlash の遅延マテリアライゼーション機能を無効にした場合、フィルタ条件 ( { `SELECT`句) を含む`WHERE`ステートメントを処理するために、 TiFlash はフィルタリングの前に必要な列のすべてのデータをスキャンします。この変数を`ON`に設定してTiFlash の遅延マテリアライゼーション機能を有効にすると、 TiFlash は、TableScan オペレータにプッシュダウンされたフィルタ条件に関連する列データを最初にスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列のデータをスキャンしてさらに計算を行うことができ、これにより、データ処理の IO スキャンと計算を削減できます。 +- この変数を`OFF`に設定してTiFlash の遅延マテリアライゼーション機能を無効にした場合、フィルタ条件（`WHERE`句）を含む`SELECT`ステートメントを処理するために、 TiFlash はフィルタリングの前に必要な列のすべてのデータをスキャンします。この変数を`ON`に設定してTiFlash の遅延マテリアライゼーション機能を有効にすると、 TiFlash は、TableScan オペレータにプッシュダウンされたフィルタ条件に関連する列データを最初にスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列のデータをスキャンしてさらに計算を行うことができ、これにより、データ処理の IO スキャンと計算を削減できます。 ### tidb_opt_enable_mpp_shared_cte_execution New in v7.2.0 @@ -4490,7 +4490,7 @@ mysql> desc select count(distinct a) from test.t; - ヒント [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value) への適用: Yes - 型: Boolean - デフォルト値: `OFF` -- この変数は、[相関サブクエリのデコリレーション](/correlated-subquery-optimization.md) のシナリオにおいて、オプティマイザがデコリレーションを行わない論理 Candidate プランも追加で構築するかどうかを制御します。 +- この変数は、[相関サブクエリのデコリレーション](/correlated-subquery-optimization.md) のシナリオにおいて、オプティマイザがデコリレーションを行わない論理候補プランも追加で構築するかどうかを制御します。 - デフォルトでは、TiDB は相関サブクエリに対してデコリレーション書き換えを優先的に試みます。 - この変数を有効にすると、デコリレーション後の Candidate プランが、元の相関サブクエリと同じアクセス方向を持つ等価な `IndexJoin` Candidate プランの生成に失敗した場合、オプティマイザはデコリレーションしない Candidate プランも追加で保持し、デコリレーションあり・なしの両方の Candidate プランを評価したうえで、より低コストな[実行計画](/explain-subqueries.md)を選択します。 @@ -4573,7 +4573,7 @@ mysql> desc select count(distinct a) from test.t; select t.* from t, (select aa from t1 group by aa) tmp_t where t.a = tmp_t.aa; ``` - `t1`列で`unique`と`not null` `aa`限定されている場合、集計なしで次のステートメントを使用できます。 + `aa`列で`t1`が`unique`と`not null`に限定されている場合、集計なしで次のステートメントを使用できます。 ```sql select t.* from t, t1 where t.a=t1.aa; @@ -4597,9 +4597,9 @@ mysql> desc select count(distinct a) from test.t; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、特定の複数テーブル結合クエリの結合したテーブルの再配置最適化を改善します。この変数を`ON`に設定すると、安全条件が満たされている場合、オプティマイザは、連続する複数の結合間のフィルタ条件 ( `Selection` ) を結合したテーブルの再配置最適化の候補範囲に含めます。結合ツリーを再構築する際、オプティマイザはこれらの条件をより適切な位置にプッシュダウン、より多くのテーブルが結合したテーブルの再配置最適化に参加できるようにします。 +- この変数は、特定の複数テーブル結合クエリの結合したテーブルの再配置最適化を改善します。この変数を`ON`に設定すると、安全条件が満たされている場合、オプティマイザは、連続する複数の結合間のフィルタ条件 ( `Selection` ) を結合したテーブルの再配置最適化の候補範囲に含めます。結合ツリーを再構築する際、オプティマイザはこれらの条件をより適切な位置にプッシュダウンし、より多くのテーブルが結合したテーブルの再配置最適化に参加できるようにします。 - この変数を有効にした後にパフォーマンスの低下や不安定な実行プランが見られる場合は、この変数を`OFF`に設定して、この機能を無効にしてください。 -- 式の評価意味論が変更されないようにするため、フィルタ条件に非決定的な関数や関数のある関数 ( `RAND()`など) が含まれている場合、この変数が有効になっていてもオプティマイザは条件プッシュダウンを実行しません。 +- 式の評価意味論が変更されないようにするため、フィルタ条件に非決定的な関数や副作用のある関数 ( `RAND()`など) が含まれている場合、この変数が有効になっていてもオプティマイザは条件プッシュダウンを実行しません。 ### tidb_opt_limit_push_down_threshold @@ -4667,7 +4667,7 @@ mysql> desc select count(distinct a) from test.t; - 範囲: `[-1, 1]` -- この変数は、SQL ステートメントに`ORDER BY`および`ORDER BY` -E}} 句がある場合に、SQL ステートメント`LIMIT`に一致するインデックスの推定行数を制御しますが、一部のフィルタ条件はカバーしません。 +- この変数は、SQL ステートメントに`ORDER BY`および`LIMIT`句がある場合に、SQL ステートメント`ORDER BY`に一致するインデックスの推定行数を制御しますが、一部のフィルタ条件はカバーしません。 - これは、システム変数[tidb_opt_ordering_index_selectivity_threshold](#tidb_opt_ordering_index_selectivity_threshold-new-in-v700)と同じクエリパターンに対応します。 @@ -4827,7 +4827,7 @@ mysql> desc select count(distinct a) from test.t; > **Note:** > - > 現在、オプティマイザはコストモデルに基づいて部分順序 TopN 最適化を適用するかどうかを動的に決定することをサポートしていません。 `COST`または`USE INDEX` } を指定せずにこの変数を`FORCE INDEX`のみに設定した場合、オプティマイザはこの最適化を適用しない可能性があります。最適化が確実に適用されるようにするには、 `USE INDEX`または`FORCE INDEX`と組み合わせて使用​​してください。 + > 現在、オプティマイザはコストモデルに基づいて部分順序 TopN 最適化を適用するかどうかを動的に決定することをサポートしていません。 `USE INDEX`または`FORCE INDEX`を指定せずにこの変数を`COST`のみに設定した場合、オプティマイザはこの最適化を適用しない可能性があります。最適化が確実に適用されるようにするには、 `USE INDEX`または`FORCE INDEX`と組み合わせて使用​​してください。
    部分順序TopN最適化の例を表示する @@ -5153,7 +5153,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、オプティマイザが`DISTINCT`を含む集計関数を、 `SELECT b, COUNT(DISTINCT a) FROM t GROUP BY b`を`SELECT b, COUNT(a) FROM (SELECT b, a FROM t GROUP BY b, a) t GROUP BY b` } に書き換えるなど、2 レベルの集計関数に書き換えるかどうかを設定します。集計列に深刻な偏りがあり、 `DISTINCT`列にさまざまな値がある場合、この書き換えによってクエリ実行時のデータ偏りを回避し、クエリのパフォーマンスを向上させることができます。 +- この変数は、オプティマイザが`DISTINCT`を含む集計関数を、 `SELECT b, COUNT(DISTINCT a) FROM t GROUP BY b`を`SELECT b, COUNT(a) FROM (SELECT b, a FROM t GROUP BY b, a) t GROUP BY b`に書き換えるなど、2 レベルの集計関数に書き換えるかどうかを設定します。集計列に深刻な偏りがあり、 `DISTINCT`列にさまざまな値がある場合、この書き換えによってクエリ実行時のデータ偏りを回避し、クエリのパフォーマンスを向上させることができます。 ### tidb_opt_three_stage_distinct_agg New in v6.3.0 @@ -5689,12 +5689,12 @@ SHOW WARNINGS; - デフォルト値: `OFF` - `tidb_restricted_read_only`と[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は同様の動作をします。ほとんどの場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを使用してください。 - `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限を持つユーザーは、この変数を変更できます。ただし、 [セキュリティ強化モード](#tidb_enable_enhanced_security)が有効になっている場合は、この変数を読み取りまたは変更するために、追加の`RESTRICTED_VARIABLES_ADMIN`権限が必要です。 -- `tidb_restricted_read_only`以下のケースで[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)影響を与えます。 +- `tidb_restricted_read_only`は以下のケースで[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)に影響を与えます。 - `tidb_restricted_read_only`を`ON`に設定すると、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `ON`に更新されます。 - `tidb_restricted_read_only`を`OFF`に設定しても、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は変更されません。 - `tidb_restricted_read_only`が`ON`の場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `OFF`に設定することはできません。 - TiDB の DBaaS プロバイダーの場合、TiDB クラスタが別のデータベースのダウンストリーム データベースである場合、TiDB クラスタを読み取り専用にするには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にした上で`tidb_restricted_read_only`を使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を使用してクラスタを書き込み可能にすることができなくなります。これを実現するには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`を制御し、データベース ユーザーには、 `SUPER`権限を持つルート ユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。 -- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` -E}} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 +- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 - この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 - TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。 - この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。 @@ -5710,7 +5710,7 @@ SHOW WARNINGS; - 型: String - デフォルト値: `""` - 指定可能な値: `"ddl"` 、 `"stats"` 、 `"br"` 、 `"lightning"` 、 `"background"` -- この変数は、現在のセッションのタスクタイプ[リソース制御](/tidb-resource-control-ru-groups.md)明示的に指定するために使用され、それは によって識別および制御されます。例: `SET @@tidb_request_source_type = "background"` 。 +- この変数は、現在のセッションのタスクタイプを明示的に指定するために使用され、[リソース制御](/tidb-resource-control-ru-groups.md)によって識別および制御されます。例: `SET @@tidb_request_source_type = "background"` 。 ### tidb_resource_control_strict_mode New in v8.2.0 @@ -5719,7 +5719,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 @@ -6000,7 +6000,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > **Tip:** > > - 本番環境で`tidb_slow_log_rules`を有効にする場合は、スロークエリログの出力が過度に頻繁に発生しないように、 [`tidb_slow_log_max_per_sec`](#tidb_slow_log_max_per_sec-new-in-v856)も設定することをお勧めします。 -> - 最初はより厳しい条件から始め、トラブルシューティングの必要性に応じて徐々に緩和していくことをお勧めします。パフォーマンスへの影響に関する詳細については、 を [推奨事項](/identify-slow-queries.md#recommendations)してください。 +> - 最初はより厳しい条件から始め、トラブルシューティングの必要性に応じて徐々に緩和していくことをお勧めします。パフォーマンスへの影響に関する詳細については、[推奨事項](/identify-slow-queries.md#recommendations)を参照してください。 ### tidb_slow_log_threshold @@ -6310,7 +6310,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > **Note:** > -> [`tidb_stmt_summary_enable_persistent`](/statement-summary-tables.md#persist-statements-summary)有効になっている場合、 `tidb_stmt_summary_max_stmt_count` [`statements_summary`](/statement-summary-tables.md#statements_summary)テーブルがメモリに格納できる SQL ダイジェストの数を制限するだけです。 +> [`tidb_stmt_summary_enable_persistent`](/statement-summary-tables.md#persist-statements-summary)が有効になっている場合、 `tidb_stmt_summary_max_stmt_count`は[`statements_summary`](/statement-summary-tables.md#statements_summary)テーブルがメモリに格納できる SQL ダイジェストの数を制限するだけです。 @@ -6368,7 +6368,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `OFF` - `tidb_super_read_only` MySQL 変数`super_read_only`の代替として実装されることを目的としています。ただし、TiDB は分散データベースであるため、 `tidb_super_read_only`実行直後にデータベースを読み取り専用にするのではなく、最終的に読み取り専用にします。 - `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限を持つユーザーは、この変数を変更できます。 -- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` }} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 +- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 - この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 - TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。 - この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。 @@ -6549,7 +6549,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > **Note:** > -> - `PARALLEL`モードと`PARALLEL-FAST`モードは、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)および[`tidb_enable_tso_follower_proxy`](#tidb_enable_tso_follower_proxy-new-in-v530)と互換性がありません。tidb_tso_client_batch_max_wait_time [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)ゼロ以外の値に設定されている場合、または[`tidb_enable_tso_follower_proxy`](#tidb_enable_tso_follower_proxy-new-in-v530)が有効になっている場合、 `tidb_tso_client_rpc_mode`設定は有効にならず、TiDB は常に`DEFAULT`モードで動作します。 +> - `PARALLEL`モードと`PARALLEL-FAST`モードは、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)および[`tidb_enable_tso_follower_proxy`](#tidb_enable_tso_follower_proxy-new-in-v530)と互換性がありません。[`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)がゼロ以外の値に設定されている場合、または[`tidb_enable_tso_follower_proxy`](#tidb_enable_tso_follower_proxy-new-in-v530)が有効になっている場合、 `tidb_tso_client_rpc_mode`設定は有効にならず、TiDB は常に`DEFAULT`モードで動作します。 > - `PARALLEL`モードと`PARALLEL-FAST`モードは、TiDB で TS を取得する平均時間を短縮するように設計されています。ただし、レイテンシーの変動が大きい場合（例えば、レイテンシーが長時間にわたって変動したり、レイテンシーに変動したりする場合）は、これらのモードではパフォーマンスが著しく向上しない可能性があります。 ### tidb_cb_pd_metadata_error_rate_threshold_ratio New in v8.5.5 @@ -6772,7 +6772,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、実行プランのバインディング機能を有効にするかどうかを制御するために使用されます。デフォルトでは有効になっており、 `OFF`値を割り当てることで無効にできます。実行プランのバインディングの使用方法については、「実行プラン[実行計画の拘束](/sql-plan-management.md#create-a-binding)を参照してください。 +- この変数は、実行プランのバインディング機能を有効にするかどうかを制御するために使用されます。デフォルトでは有効になっており、 `OFF`値を割り当てることで無効にできます。実行プランのバインディングの使用方法については、[実行計画の拘束](/sql-plan-management.md#create-a-binding)を参照してください。 ### tidb_wait_split_region_finish @@ -6847,7 +6847,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ウィンドウ関数が実行のためにTiFlashにプッシュダウンされる際、この変数を使用してウィンドウ関数の実行の並行レベルを制御できます。指定可能な値は以下のとおりです。 - -1: 細粒度シャッフル機能が無効になります。TiFlashにプッシュダウンされたウィンドウ関数は、シングルスレッドで実行されます。 - - 0: 細粒度シャッフル機能が有効になります。tidb_max_tiflash_threads [`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)有効な値 (0 より大きい値) に設定されている場合、 `tiflash_fine_grained_shuffle_stream_count`は[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)の値に設定されます。それ以外の場合は、 TiFlash計算ノードの CPU リソースに基づいて自動的に推定されます。TiFlashのウィンドウ関数の実際の同時実行レベルは、min( `tiflash_fine_grained_shuffle_stream_count` 、 TiFlashノード上の物理スレッド数) です。 + - 0: 細粒度シャッフル機能が有効になります。[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)が有効な値 (0 より大きい値) に設定されている場合、 `tiflash_fine_grained_shuffle_stream_count`は[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)の値に設定されます。それ以外の場合は、 TiFlash計算ノードの CPU リソースに基づいて自動的に推定されます。TiFlashのウィンドウ関数の実際の同時実行レベルは、min( `tiflash_fine_grained_shuffle_stream_count` 、 TiFlashノード上の物理スレッド数) です。 - 0より大きい整数: 細粒度シャッフル機能が有効になります。TiFlashにプッシュダウンされたウィンドウ関数は、複数のスレッドで実行されます。同時実行レベルは、min( `tiflash_fine_grained_shuffle_stream_count` 、 TiFlashノード上の物理スレッド数)です。 - 理論的には、ウィンドウ関数のパフォーマンスはこの値に比例して向上します。しかし、この値が実際の物理スレッド数を超えると、逆にパフォーマンスが低下します。 @@ -6869,7 +6869,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: Float - デフォルト値: `0.7` - 範囲: `[0, 0.85]` -- この変数はTiFlashのしきい値を制御します。 [クエリレベルのスピル](/tiflash/tiflash-spill-disk.md#query-level-spilling)。 `0` 、クエリレベルの自動スピルを無効にすることを意味します。この変数が`0`より大きく、クエリのメモリ使用量が[`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740) * `tiflash_query_spill_ratio`を超えると、 TiFlash はクエリレベルのスピルをトリガーし、必要に応じてクエリ内のサポートされている演算子のデータをスピルします。 +- この変数はTiFlash [クエリレベルのスピル](/tiflash/tiflash-spill-disk.md#query-level-spilling)のしきい値を制御します。 `0`は、クエリレベルの自動スピルを無効にすることを意味します。この変数が`0`より大きく、クエリのメモリ使用量が[`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740) * `tiflash_query_spill_ratio`を超えると、 TiFlash はクエリレベルのスピルをトリガーし、必要に応じてクエリ内のサポートされている演算子のデータをスピルします。 > **Note:** > @@ -7071,7 +7071,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: Enumeration - デフォルト値: `1` - 値オプション: TiDB Self-Managed および TiDB Cloud Dedicated の場合は`0` 、 `1` `2` }、 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated) [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合は`1`および`2` -- この変数は、パスワードの複雑性チェックのポリシーを制御します。この変数は、 [`validate_password.enable`](#password_reuse_interval-new-in-v650)が有効になっている場合にのみ有効になります。この変数の値によって、 `validate-password`を除く他の`validate_password.check_user_name`変数がパスワードの複雑性チェックで有効になるかどうかが決まります。 +- この変数は、パスワードの複雑性チェックのポリシーを制御します。この変数は、 [`validate_password.enable`](#password_reuse_interval-new-in-v650)が有効になっている場合にのみ有効になります。この変数の値によって、 `validate_password.check_user_name`を除く他の`validate-password`変数がパスワードの複雑性チェックで有効になるかどうかが決まります。 - この変数の値は`0` 、 `1` 、または`2` （それぞれLOW、MEDIUM、STRONGに対応）のいずれかになります。ポリシーレベルによってチェック項目が異なります。 - 0またはLOW：パスワードの長さ。 - 1 または MEDIUM: パスワードの長さ、大文字と小文字、数字、および特殊文字。 diff --git a/table-affinity.md b/table-affinity.md index 8f4c3428dc8aa..35a195638cfc9 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -35,7 +35,7 @@ PDアフィニティスケジューリングはデフォルトで無効になっ pd-ctl config set schedule.affinity-schedule-limit 4 ``` -2. （オプション）必要に応じてPD設定項目[`schedule.max-affinity-merge-region-size`](/pd-configuration-file.md#max-affinity-merge-region-size-new-in-v855)を変更します。デフォルト値は`256`です。これは、同じアフィニティグループ内の隣接する小さなリージョンを自動的にマージするためのサイズしきい値を制御します。5に設定すると`0`アフィニティグループ内の隣接する小さなリージョンの自動マージが無効になります。 +2. （オプション）必要に応じてPD設定項目[`schedule.max-affinity-merge-region-size`](/pd-configuration-file.md#max-affinity-merge-region-size-new-in-v855)を変更します。デフォルト値は`256` MiB です。これは、同じアフィニティグループ内の隣接する小さなリージョンを自動的にマージするためのサイズしきい値を制御します。`0`に設定すると、アフィニティグループ内の隣接する小さなリージョンの自動マージが無効になります。 ## 使用法 {#usage} diff --git a/table-filter.md b/table-filter.md index 3aa52cb1a3486..b802d96f0ad5a 100644 --- a/table-filter.md +++ b/table-filter.md @@ -94,7 +94,7 @@ TOMLファイル内のテーブルフィルターは[文字列の配列](https:/ プレーン名は、次のように有効な[識別子文字](/schema-object-names.md)のみで構成する必要があります。 - 数字（ `0` ～ `9` ） -- 文字（ `a` ～ `z` ～ `A` `Z` +- 文字（ `a` ～ `z` 、 `A` ～ `Z` ） - `$` - `_` - 非ASCII文字（U+0080からU+10FFFF） diff --git a/temporary-tables.md b/temporary-tables.md index 0730c0df2a912..0572553a665cc 100644 --- a/temporary-tables.md +++ b/temporary-tables.md @@ -272,5 +272,5 @@ TiDB のローカル一時テーブルは次の機能をサポートしてい** ## 参照 {#see-also} - [テーブルの作成](/sql-statements/sql-statement-create-table.md) -- [次のようなテーブルを作成する](/sql-statements/sql-statement-create-table-like.md) +- [CREATE TABLE LIKE](/sql-statements/sql-statement-create-table-like.md) - [テーブルを削除](/sql-statements/sql-statement-drop-table.md) diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 262b60678b7fe..35b8680705bf1 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -126,7 +126,7 @@ alertmanager_servers: ### ラベルデザイン {#labels-design} -2つのリージョンに3つのAZを展開する場合、ラベル設計では可用性と災害復旧を考慮する必要があります。展開の物理構造に基づいて、4つ`host`レベル（ `az` ）を`rack`することをお勧めします`replication zone` +2つのリージョンに3つのAZを展開する場合、ラベル設計では可用性と災害復旧を考慮する必要があります。展開の物理構造に基づいて、4つのレベル（`az`、`replication zone`、`rack`、`host`）を定義することをお勧めします。 ![Label logical definition](/media/three-data-centers-in-two-cities-deployment-03.png) diff --git a/ticdc-deployment-topology.md b/ticdc-deployment-topology.md index 06b26f69f6d0e..9c80b7c89bc83 100644 --- a/ticdc-deployment-topology.md +++ b/ticdc-deployment-topology.md @@ -36,5 +36,5 @@ TiCDCは、TiDB 4.0で導入されたTiDBの増分データを複製するため > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPクラスタコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 > - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 42f14652709de..d7599b74afae0 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -103,7 +103,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ - `` - `` - 1 の値を置き換える前に、 [HTML URL エンコーディングリファレンス](https://www.w3schools.com/tags/ref_urlencode.asp)に基づいて``エンコードする必要があることに注意してください。上記のすべてのフィールドを置き換えた後、設定ファイルは次のようになります。 + ``の値を置き換える前に、 [HTML URL エンコーディングリファレンス](https://www.w3schools.com/tags/ref_urlencode.asp)に基づいてエンコードする必要があることに注意してください。上記のすべてのフィールドを置き換えた後、設定ファイルは次のようになります。 ```shell tiup cdc:v cli changefeed create --server="http://127.0.0.1:8300" --sink-uri="kafka://xxx-xxxxx.ap-east-1.aws.confluent.cloud:9092/ticdc-meta?protocol=avro&replication-factor=3&enable-tls=true&auto-create-topic=true&sasl-mechanism=plain&sasl-user=L5WWA4GK4NAT2EQV&sasl-password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" --schema-registry="https://7NBH2CAFM2LMGTH7:xxxxxxxxxxxxxxxxxx@yyy-yyyyy.us-east-2.aws.confluent.cloud" --changefeed-id="confluent-changefeed" --config changefeed.conf diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 19a3ee7818eaa..814aa887509e5 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -82,7 +82,7 @@ TiCDC は DML イベントを Kafka イベントに変換し、イベントの ## TiDB拡張フィールド {#tidb-extension-fields} -デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。7で`enable-tidb-extension` `true` （デフォルトは`false` ）に設定すると、TiCDC `sink-uri`メッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 +デフォルトでは、AvroはDMLイベント内の変更された行のデータのみを収集し、データ変更の種類やTiDB固有のCommitTS（トランザクションの一意の識別子）は収集しません。この問題に対処するため、TiCDCはAvroプロトコルメッセージに以下の3つのTiDB拡張フィールドを導入しています。`sink-uri`で`enable-tidb-extension`を`true` （デフォルトは`false` ）に設定すると、TiCDCはメッセージ生成時にこれらの3つのフィールドをAvroメッセージに追加します。 - `_tidb_op` : DML タイプ。「c」は挿入を示し、「u」は更新を示します。 - `_tidb_commit_ts` : トランザクションの一意の識別子。 @@ -158,7 +158,7 @@ dispatchers = [ } - `{{ColumnName}}`列名を示します。 -- `{{TIDB_TYPE}}` TiDB 内の型を示します。これは SQL 型との 1 対 1 のマッピングではありません。 +- `{{TIDB_TYPE}}`は TiDB 内の型を示します。これは SQL 型との 1 対 1 のマッピングではありません。 - `{{AVRO_TYPE}}` [Avro仕様](https://avro.apache.org/docs/++version++/specification)内のタイプを示します。 | SQLの型 | TiDBの型 | AVRO_TYPE | 説明 | @@ -284,7 +284,7 @@ TiCDC Avro プロトコルは[`io.confluent.kafka.serializers.KafkaAvroDeseriali コンシューマー プログラムは、次のルールによって DML イベント タイプを区別できます。 - Key部分のみの場合はDeleteイベントになります。 -- キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。1 [TiDB拡張フィールド](#tidb-extension-fields)有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 +- キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。[TiDB拡張フィールド](#tidb-extension-fields)が有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 ## トピックの分布 {#topic-distribution} diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index f1ce48769ff13..081f03a0d8337 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -23,7 +23,7 @@ TiCDCは、指定されたタイムスタンプ以降に発生した増分デー 1. 上流クラスタと下流クラスタの時点を確認します。2つのTiDBクラスタがある場合は、特定の時点において2つのクラスタのデータが整合していることを確認します。例えば、TiDB 1の`ts=1`時点のデータとTiDB 2の`ts=2`のデータは整合しています。 - 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`設定します。 + 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`を対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`を設定します。 4. `--config`パラメータで指定された構成ファイルに、次の構成を追加します。 diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index ba5d4a0a68420..7d627dadb96bb 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -167,8 +167,8 @@ TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERM 上記の例からわかるように、Canal-JSON は統一されたデータ形式を持ち、イベントの種類ごとに異なるフィールドの入力ルールを備えています。コンシューマーは、統一された方法でこの JSON 形式のデータを解析し、フィールド値をチェックすることでイベントの種類を判別できます。 -- `isDdl`が`true`場合、メッセージには DDL イベントが含まれます。 -- `isDdl`が`false`場合、 `type`フィールドをさらに確認する必要があります。7 が`type` `TIDB_WATERMARK`場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。 +- `isDdl`が`true`の場合、メッセージには DDL イベントが含まれます。 +- `isDdl`が`false`の場合、 `type`フィールドをさらに確認する必要があります。`type`が`TIDB_WATERMARK`の場合、それは WATERMARK イベントです。それ以外の場合は、DML イベントです。 ## フィールドの説明 {#field-descriptions} diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index d5074a9a5f7f8..0df6096739df7 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -35,7 +35,7 @@ summary: チェンジフィードの基本的な概念、状態の定義、お - ⑤ changefeedの自動リトライが30分を超えて失敗し、changefeedは失敗状態になります。このとき、changefeedは`gc-ttl`で指定された期間、上流GCをブロックし続けます。 - ⑥ changefeed は回復不能なエラーに遭遇し、直接 failed 状態に移行します。このとき、changefeed は`gc-ttl`で指定された期間、上流の GC をブロックし続けます。 - ⑦ changefeedのレプリケーション進行状況が`target-ts`で設定した値に到達し、レプリケーションが完了します。 -- 8 チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 +- ⑧ チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 - ⑨ 失敗の原因が解決され、変更フィードが`gc-ttl`で指定された値よりも短い期間中断された場合は、 `changefeed resume`コマンドを実行してレプリケーション タスクを再開します。 ## チェンジフィードを操作する {#operate-changefeeds} diff --git a/ticdc/ticdc-csv.md b/ticdc/ticdc-csv.md index 2f1dc97fcd901..65a01a1258ed5 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-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index f7a9db94882a0..6eb7343432ebe 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -13,7 +13,7 @@ summary: TiCDC のデータ複製機能について学びます。 - TiCDCは`UPDATE` `INSERT` `DELETE`を生成します。詳細については[TiCDCがデータ変更を処理する方法](/ticdc/ticdc-overview.md#implementation-of-processing-data-changes)を参照してください。 -- TiCDCはトランザクションの最終的な一貫性を保証します。1 [再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。3 [同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 +- TiCDCはトランザクションの最終的な一貫性を保証します。[再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)を有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)を有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 ## サポートされている下流システム {#supported-downstream-systems} diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 92e64a64adce4..3f707ae6f266a 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 99a6e90974eb2..1d01f611af26c 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -240,13 +240,13 @@ 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`パラメータの説明は次のとおりです。 | パラメータ名 | 説明 | | :------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `bdr_mode` | `BOOLEAN`型。2 [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)有効にするかどうかを決定します。デフォルト値は`false`です。（オプション） | +| `bdr_mode` | `BOOLEAN`型。[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)を有効にするかどうかを決定します。デフォルト値は`false`です。（オプション） | | `case_sensitive` | `BOOLEAN`型。テーブル名をフィルタリングする際に大文字と小文字を区別するかどうかを指定します。v6.5.6、v7.1.3、v7.5.0以降では、デフォルト値が`true`から`false`に変更されます。（オプション） | | `check_gc_safe_point` | `BOOLEAN`型。レプリケーションタスクの開始時刻がGC時刻よりも前であるかどうかを確認するかどうかを指定します。デフォルト値は`true`です。（オプション） | | `consistent` | REDOログの設定パラメータ。(オプション) | @@ -306,7 +306,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | :---------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | `column_selectors` | 列セレクターの構成。(オプション) | | `csv` | CSV 構成。(オプション) | -| `date_separator` | `STRING`型。ファイルディレクトリの日付区切り文字の種類を示します。値の選択肢は`none` 、 `year` 、 `month` 、 `day`です。10 `none`デフォルト値で、日付が区切られないことを意味します。(オプション) | +| `date_separator` | `STRING`型。ファイルディレクトリの日付区切り文字の種類を示します。値の選択肢は`none` 、 `year` 、 `month` 、 `day`です。`none`がデフォルト値で、日付が区切られないことを意味します。(オプション) | | `dispatchers` | イベントディスパッチ用の構成配列。(オプション) | | `encoder_concurrency` | `INT`型。MQシンク内のエンコーダスレッドの数。デフォルト値は`16`です。（オプション） | | `protocol` | `STRING`型。MQシンクの場合、メッセージのプロトコル形式を指定できます。現在サポートされているプロトコルは、 `canal-json` 、 `open-protocol` 、 `avro` 、 `debezium` 、 `simple` 。 | @@ -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`です。ディスパッチャのルールは以下のとおりです。 @@ -509,7 +509,7 @@ curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/ch | `resolved_ts` | `UINT64`タイプ。レプリケーション タスクは ts を解決しました。 | | `sink_uri` | `STRING`タイプ。レプリケーション タスク シンクの URI。 | | `start_ts` | `UINT64`タイプ。レプリケーションタスクが開始されます。 | -| `state` | `STRING`型。レプリケーションタスクの`failed` 。2、4、6、8、10 `stopped` `normal`か`finished`なります`error` | +| `state` | `STRING`型。レプリケーションタスクのステータス。`normal` 、 `stopped` 、 `error` 、 `failed` 、または`finished`になります。 | | `target_ts` | `UINT64`タイプ。レプリケーションタスクのターゲット ts。 | | `task_status` | レプリケーション タスクのディスパッチの詳細なステータス。 | diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index 161c10a616017..e7617ca2ad68d 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -9,7 +9,7 @@ summary: OpenAPI インターフェースを使用してクラスターのステ > **注記** > -> TiCDC OpenAPI v1は非推奨であり、将来削除される予定です。1 [TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)使用をお勧めします。 +> TiCDC OpenAPI v1は非推奨であり、将来削除される予定です。[TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)の使用をお勧めします。 TiCDC は、TiCDC クラスターを照会および操作するための OpenAPI 機能を提供します。これは、 [`cdc cli`ツール](/ticdc/ticdc-manage-changefeed.md)の機能に似ています。 diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index 64849e5323884..c5480db1d94ab 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/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index e58e7cfde22b3..0164cb98ee682 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -30,7 +30,7 @@ Info: {"upstream_id":7277814241002263370,"namespace":"default","id":"simple-repl - `--server` : TiCDC クラスター内の TiCDCサーバーのアドレス。 - `--changefeed-id` : レプリケーションタスクのID。形式は正規表現`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`一致する必要があります。IDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 -- `--sink-uri` ：レプリケーションタスクのダウンストリームアドレス。2 [シンクURIを使用してPulsarを構成する](#sink-uri)参照してください。 +- `--sink-uri` ：レプリケーションタスクのダウンストリームアドレス。[シンクURIを使用してPulsarを構成する](#sink-uri)を参照してください。 - `--start-ts` : チェンジフィードの開始TSO。TiCDCクラスターはこのTSOからデータのプルを開始します。デフォルト値は現在時刻です。 - `--target-ts` : チェンジフィードのターゲットTSO。TiCDCクラスターはこのTSOでデータのプルを停止します。デフォルトでは空であり、TiCDCはデータのプルを自動的に停止しません。 - `--config` : changefeed設定ファイル[TiCDC チェンジフィード構成パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index 0716aa8bb0f14..c58462dd47c39 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -129,7 +129,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | バージョン6.5.2以下 | 全て | ✗ | ✓ | | | v6.5.3 / v6.5.4 | Canal/オープン | ✗ | ✓ | | -| バージョン6.5.3 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。1を参照してください[＃9086](https://github.com/pingcap/tiflow/issues/9658) | +| バージョン6.5.3 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。[＃9086](https://github.com/pingcap/tiflow/issues/9658)を参照してください。 | | バージョン6.5.4 | Canal/オープン | ✗ | ✗ | 複数の変更を含むトランザクションのみを分割して並べ替える | | v6.5.5 ～ v6.5.9 | 全て | ✓ | ✗ | | | = v6.5.10 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | @@ -140,7 +140,7 @@ v6.5.10、v7.1.6、v7.5.3、v8.1.1以降、MySQL以外のシンクを使用す | --------------- | ------- | ---------------------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------- | | バージョン7.1.0 | 全て | ✗ | ✓ | | | バージョン7.1.1 | Canal/オープン | ✗ | ✓ | | -| バージョン7.1.1 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。1を参照してください[＃9086](https://github.com/pingcap/tiflow/issues/9658) | +| バージョン7.1.1 | CSV/Avro | ✗ | ✗ | 分割しますが、並べ替えは行いません。[＃9086](https://github.com/pingcap/tiflow/issues/9658)を参照してください。 | | v7.1.2 ~ v7.1.5 | 全て | ✓ | ✗ | | | = v7.1.6 | 全て | ✓ (デフォルト値: `output-raw-change-event = false` ) | ✓ （オプション： `output-raw-change-event = true` ） | | diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 92796010b79ac..48e27abbf0d3e 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -128,7 +128,7 @@ cdc cli changefeed resume -c test-cf --server=http://127.0.0.1:8300 > **Note:** > -> changefeed `start-ts`エラー発生時の`checkpoint-ts`に 1 を加えた値に設定してタスクを再作成すると、DDL 文をスキップできますが、TiCDC が`checkpointTs+1`の時点での DML データ変更を失う可能性があります。したがって、この操作は実本番環境では厳禁です。 +> changefeed の`start-ts`をエラー発生時の`checkpoint-ts`に 1 を加えた値に設定してタスクを再作成すると、DDL 文をスキップできますが、TiCDC が`checkpointTs+1`の時点での DML データ変更を失う可能性があります。したがって、この操作は実本番環境では厳禁です。 ```shell cdc cli changefeed remove --server=http://127.0.0.1:8300 --changefeed-id simple-replication-task diff --git a/tidb-cloud/data-service-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 f84a90a7e993d..9b8782b6afa28 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/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index da1af55fae9f5..85f96495567c5 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -7,7 +7,7 @@ summary: TiDB Cloudコンソールでデータ アプリを作成、表示、変 Data Service（プレビュー版）のデータアプリは、特定のアプリケーションのデータにアクセスするために使用できるエンドポイントのコレクションです。APIキーを使用して認証設定を構成し、データアプリ内のエンドポイントへのアクセスを制限できます。 -このドキュメントでは、 TiDB Cloudコンソールでデータアプリを管理する方法について説明します。1 [**データサービス**](https://tidbcloud.com/project/data-service)目では、すべてのデータアプリ、エンドポイント、API キーを管理できます。 +このドキュメントでは、 TiDB Cloudコンソールでデータアプリを管理する方法について説明します。[**Data Service**](https://tidbcloud.com/project/data-service)ページでは、すべてのデータアプリ、エンドポイント、API キーを管理できます。 ## データアプリを作成する {#create-a-data-app} diff --git a/tidb-cloud/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/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 040c437512e0d..36f6e5b2274a7 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -178,7 +178,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) AWS上でのロードバランシングに関する課金体系の変更。 - 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、AWS [AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 + 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、[AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)に伴い、パブリック IPv4 アドレスに対する新しい AWS 料金が含まれます。各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 この料金は、お客様の既存の**TiDB Cloud Dedicated - Data Transfer - Load Balancing**サービスの下に表示されます。 [請求明細](/tidb-cloud/tidb-cloud-billing.md#billing-details)。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index c3a2f8b3bf0d8..5d13a8bab696d 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -715,7 +715,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスター内のパブリック エンドポイントのファイアウォール ルールをサポートします。 - TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。1 [TiDB Cloudコンソール](https://tidbcloud.com/)許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 + TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。[TiDB Cloudコンソール](https://tidbcloud.com/)で許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 詳細については[パブリックエンドポイント用のTiDB Cloudサーバーレス ファイアウォール ルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)を参照してください。 diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index 8dc89533b0e4d..d69ad82142bcf 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -332,7 +332,7 @@ ticloud serverless export create -c --target-type GCS --gcs.uri .blob.core.windows.net///`形式で Azure Blob Storage の URI を入力します。 - - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。2でSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access) [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)してください。 + - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。[Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用してSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 4. **［エクスポート］**をクリックします。 diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index 93c5247eaf192..eafffbd1ccb2a 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -20,7 +20,7 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを ### 繋がり {#connection} -- [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。5 [VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md) TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 +- [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。[VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md)は TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 - プライベートエンドポイントのサポート[ファイアウォールルール](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md) 。 - データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)を参照してください。 - TiDB Cloud Starterクラスターでは、最大400の同時接続が可能です。[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)を設定すると、この制限は5,000に増加します。 diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index ca62bee71c0a0..3caac8ec5b7e1 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md @@ -112,7 +112,7 @@ Kafka VPC を作成するには、次の手順を実行します。 [ECSコンソール](https://ecs.console.alibabacloud.com/home#/)に進みます。vSwitch に 3 つのブローカー ノード (AZ ごとに 1 つ) を作成します。 -- vSwitch 1 のブローカー`broker-ap-southeast-1a` +- vSwitch `broker-ap-southeast-1a`のブローカー 1 - **ネットワークとゾーン**: `Kafka VPC`および`broker-ap-southeast-1a` vSwitch - **インスタンスとイメージ**: `ecs.t5-lc1m2.small`インスタンスタイプと`Alibaba Cloud Linux`イメージ diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index b2c71dd7399b6..a59e81daab192 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -39,7 +39,7 @@ AWS PrivateLink を利用することで、エンドポイント接続は安全 ## 前提条件 {#prerequisites} -AWS VPC設定でDNSホスト名とDNS解決の[AWS マネジメントコンソール](https://console.aws.amazon.com/)が有効になっていることを確認してください。1でVPCを作成すると、これらはデフォルトで無効になります。 +AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっていることを確認してください。[AWS マネジメントコンソール](https://console.aws.amazon.com/)でVPCを作成すると、これらはデフォルトで無効になります。 ## プライベートエンドポイント接続を設定し、クラスターに接続する {#set-up-a-private-endpoint-connection-and-connect-to-your-cluster} diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index a4601ab649811..f7d50fb2139ad 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -188,7 +188,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング aws ec2 modify-vpc-attribute --vpc-id "$app_vpc_id" --enable-dns-support ``` -設定が完了すると、VPCピアリングが作成されます。1 [TiDBクラスタに接続する](#connect-to-the-tidb-cluster)結果を確認できます。 +設定が完了すると、VPCピアリングが作成されます。[TiDBクラスタに接続する](#connect-to-the-tidb-cluster)ことで結果を確認できます。
    diff --git a/tidb-cloud/sql-proxy-account.md b/tidb-cloud/sql-proxy-account.md index 3f3d6bc3ff5dc..a2eadf475ac5a 100644 --- a/tidb-cloud/sql-proxy-account.md +++ b/tidb-cloud/sql-proxy-account.md @@ -26,7 +26,7 @@ SQL プロキシ アカウントの主な利点は次のとおりです。 SELECT user FROM user WHERE plugin = 'tidb_auth_token'; ``` -2. SQLアカウントの権限を確認してください。1、3、5 `role_admin`のロール`role_readonly`リストさ`role_readwrite`ている場合は、SQLプロキシアカウントです。 +2. SQLアカウントの権限を確認してください。`role_admin` 、 `role_readonly` 、 `role_readwrite`などのロールがリストされている場合は、SQLプロキシアカウントです。 ```sql SHOW GRANTS for 'username'; diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 779f179a8927d..0275d80365413 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -387,7 +387,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを ``` -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_cluster.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_cluster.example_cluster @@ -592,7 +592,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の 1. [クラスターを作成する](#create-a-cluster-using-the-cluster-resource)際に使用される`cluster.tf`ファイルで、 `components`構成を編集します。 - たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります[クラスタ仕様からこの情報を取得します](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 + たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります。[クラスタ仕様からこの情報を取得](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 components = { tidb = { @@ -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-dedicated-vpc-peering-resource.md b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md index a7c7379fd994a..07e80e50b6da7 100644 --- a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md +++ b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md @@ -117,7 +117,7 @@ summary: tidbcloud_dedicated_vpc_peering` リソースを使用して、 TiDB Cl クラウドプロバイダーのコンソールでVPCピアリング接続を承認するまで、リソースのステータスは`Creating`ままです。VPCピアリング接続を承認すると、ステータスは[VPC ピアリングの承認と設定](/tidb-cloud/set-up-vpc-peering-connections.md#step-2-approve-and-configure-the-vpc-peering)基準に`Active`に変わります。 -5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_vpc_peering.${resource-name}`を使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 +5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_vpc_peering.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 ```shell $ terraform state show tidbcloud_dedicated_vpc_peering.example diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index f067952c649bc..fbdb4c56bef32 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-import-start.md b/tidb-cloud/ticloud-import-start.md index 23dad98c64d2b..8c66941bba7b1 100644 --- a/tidb-cloud/ticloud-import-start.md +++ b/tidb-cloud/ticloud-import-start.md @@ -76,9 +76,9 @@ ticloud serverless import start --source-type AZURE_BLOB --azblob.uri .blob.core.windows.net//`形式で指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.サービスアカウントキー文字列 | GCS の base64 でエンコードされたサービス アカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.uri 文字列 | GCS URIを`gcs:///`形式で指定します。ソースタイプがGCSの場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | -| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーIDを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけ設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --s3.role-arn 文字列 | Amazon S3のロールARNを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキーを指定します。1と[ `s3.access-key-id` ] `s3.secret-access-key` `s3.role-arn`か1つだけ設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.アクセスキーID文字列 | Amazon S3のアクセスキーIDを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.role-arn 文字列 | Amazon S3のロールARNを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキーを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --s3.uri 文字列 | S3 URIを`s3:///`形式で指定します。ソースタイプがS3の場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | | --source-type 文字列 | インポートソースの種類を [ `"LOCAL"` `"S3"` `"GCS"` `"AZURE_BLOB"` ] のいずれかで指定します。デフォルト値は`"LOCAL"`です。 | いいえ | 非対話型モードでのみ動作します。 | | | | | -c, --cluster-id 文字列 | クラスター ID を指定します。 | はい | 非対話型モードでのみ動作します。 | | | | diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index ccdba05c3726b..7124e7a1dd6a2 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -45,7 +45,7 @@ CMEK 対応プロジェクトを作成するには、次の手順に従います
    -この手順は、TiDB Cloud APIを使用して[CMEK 対応プロジェクトを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Project/operation/CreateProject)エンドポイント経由で完了できます。3フィールド`aws_cmek_enabled` `true`に設定されていることを確認してください。 +この手順は、TiDB Cloud APIを使用して[CMEK 対応プロジェクトを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Project/operation/CreateProject)エンドポイント経由で完了できます。`aws_cmek_enabled`フィールドが`true`に設定されていることを確認してください。 現在、 TiDB Cloud APIはパブリックプレビューです。詳細については、 [TiDB Cloud API ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)をご覧ください。 diff --git a/tidb-cloud/tidb-node-group-management.md b/tidb-cloud/tidb-node-group-management.md index 985188fd4a759..481c16fe77bc0 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -57,7 +57,7 @@ TiDB ノード グループを作成するには、次の手順を実行しま デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5 つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 -TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。1 [TiDBノードグループに接続する](#connect-to-a-tidb-node-group)参照してください。 +TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。[TiDBノードグループに接続する](#connect-to-a-tidb-node-group)を参照してください。 ## TiDBノードグループに接続する {#connect-to-a-tidb-node-group} diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index d9c2f1b51ed98..d750dc793086f 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -148,7 +148,7 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し このサンプル ポリシーでは、次の点に注意してください。 -- `"arn:aws:s3:::tidb-cloud-source-data/mydata/*"`の`"arn:aws:s3:::tidb-cloud-source-data"`はサンプルの S3 バケット ARN で、 `/mydata/*`データストレージ用に S3 バケットのルートレベルでカスタマイズできるディレクトリです。ディレクトリの末尾は`/*` （例： `"//*"` ）でなければなりません。 `/*`追加されていない場合、 `AccessDenied`エラーが発生します。 +- `"arn:aws:s3:::tidb-cloud-source-data/mydata/*"`の`"arn:aws:s3:::tidb-cloud-source-data"`はサンプルの S3 バケット ARN で、 `/mydata/*`はデータストレージ用に S3 バケットのルートレベルでカスタマイズできるディレクトリです。ディレクトリの末尾は`/*` （例： `"//*"` ）でなければなりません。 `/*`が追加されていない場合、 `AccessDenied`エラーが発生します。 - カスタマー管理のキー暗号化で AWS Key Management Service キー (SSE-KMS) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。`"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"`はバケットのサンプル KMS キーです。 diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index d9e879981133d..399caf74c3263 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -11,7 +11,7 @@ Chat2Query API には HTTPS 経由でのみアクセスできるため、ネッ > **Note:** > -> Chat2Query APIはAWSでホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみ利用可能です。3 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでChat2Query APIをご利用いただくには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> Chat2Query APIはAWSでホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみ利用可能です。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでChat2Query APIをご利用いただくには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 始める前に {#before-you-begin} @@ -200,7 +200,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request GET 'https:// **Note:** > -> ナレッジベース関連エンドポイントは、AWS でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみご利用いただけます。3 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでナレッジベース関連エンドポイントをご利用になる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> ナレッジベース関連エンドポイントは、AWS でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでのみご利用いただけます。[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでナレッジベース関連エンドポイントをご利用になる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index cd306584bc9e8..f5af859da8888 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -57,7 +57,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ @@ -71,7 +71,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ prepare --tables=32 --table-size=10000000 ``` -4. 以下のコマンド`sysbench run`を実行すると、Sysbenchのパフォーマンステスト`oltp_update_non_index`異なるワークロードで実行でき`200` 。このドキュメントでは、 `oltp_point_select` `oltp_read_write` 5つのワークロードでテスト`400`実施します。各ワークロードについて、 `${THREAD}`値が`100`である3つのテスト`oltp_update_index`実施します。各同時実行数で、テスト`oltp_insert`は20分かかります。 +4. 以下のコマンド`sysbench run`を実行して、さまざまなワークロードでSysbenchパフォーマンステストを実施します。このドキュメントでは、 `oltp_point_select` 、 `oltp_read_write` 、 `oltp_update_non_index` 、 `oltp_update_index` 、 `oltp_insert`の5つのワークロードでテストを実施します。各ワークロードについて、 `${THREAD}`値が`100` 、 `200` 、 `400`である3つのテストを実施します。各同時実行数で、テストは20分かかります。 ```shell sysbench ${WORKLOAD} run \ diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 9f29c48f5155f..0b25491fb447b 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -60,7 +60,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index 1805185919db9..3569731ee1271 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -42,7 +42,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = false ``` -- `oltp_insert` 、および`oltp_update_non_index` `oltp_update_index`ロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータ`oltp_read_write`有効にします。 +- `oltp_insert` 、 `oltp_read_write` 、 `oltp_update_index` 、および`oltp_update_non_index`ワークロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータを有効にします。 ```yaml raft-engine.prefill-for-recycle = true @@ -78,7 +78,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ @@ -92,7 +92,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ prepare --tables=32 --table-size=10000000 ``` -4. 以下のコマンド`sysbench run`を実行すると、Sysbenchのパフォーマンステスト`oltp_update_non_index`異なるワークロードで実行でき`200` 。このドキュメントでは、 `oltp_point_select` `oltp_read_write` 5つのワークロードでテスト`400`実施します。各ワークロードについて、 `${THREAD}`値が`100`である3つのテスト`oltp_update_index`実施します。各同時実行数で、テスト`oltp_insert`は20分かかります。 +4. 以下のコマンド`sysbench run`を実行して、さまざまなワークロードでSysbenchパフォーマンステストを実施します。このドキュメントでは、 `oltp_point_select` 、 `oltp_read_write` 、 `oltp_update_non_index` 、 `oltp_update_index` 、 `oltp_insert`の5つのワークロードでテストを実施します。各ワークロードについて、 `${THREAD}`値が`100` 、 `200` 、 `400`である3つのテストを実施します。各同時実行数で、テストは20分かかります。 ```shell sysbench ${WORKLOAD} run \ diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index 1898f7eaf0c08..bfbfdfc8b902f 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index c22e0928ce3e2..3fa934f62119e 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -42,7 +42,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = false ``` -- `oltp_insert` 、および`oltp_update_non_index` `oltp_update_index`ロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータ`oltp_read_write`有効にします。 +- `oltp_insert` 、 `oltp_read_write` 、 `oltp_update_index` 、および`oltp_update_non_index`ワークロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータを有効にします。 ```yaml raft-engine.prefill-for-recycle = true @@ -78,7 +78,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ @@ -92,7 +92,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ prepare --tables=32 --table-size=10000000 ``` -4. 以下のコマンド`sysbench run`を実行すると、Sysbenchのパフォーマンステスト`oltp_update_non_index`異なるワークロードで実行でき`200` 。このドキュメントでは、 `oltp_point_select` `oltp_read_write` 5つのワークロードでテスト`400`実施します。各ワークロードについて、 `${THREAD}`値が`100`である3つのテスト`oltp_update_index`実施します。各同時実行数で、テスト`oltp_insert`は20分かかります。 +4. 以下のコマンド`sysbench run`を実行して、さまざまなワークロードでSysbenchパフォーマンステストを実施します。このドキュメントでは、 `oltp_point_select` 、 `oltp_read_write` 、 `oltp_update_non_index` 、 `oltp_update_index` 、 `oltp_insert`の5つのワークロードでテストを実施します。各ワークロードについて、 `${THREAD}`値が`100` 、 `200` 、 `400`である3つのテストを実施します。各同時実行数で、テストは20分かかります。 ```shell sysbench ${WORKLOAD} run \ diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index ae2377f5b4948..7e13f581dbb5c 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index 9e6561af3bebd..e6144c49707e8 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -47,7 +47,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = false ``` -- `oltp_insert` 、および`oltp_update_non_index` `oltp_update_index`ロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータ`oltp_read_write`有効にします。 +- `oltp_insert` 、 `oltp_read_write` 、 `oltp_update_index` 、および`oltp_update_non_index`ワークロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータを有効にします。 ```yaml raft-engine.prefill-for-recycle = true @@ -83,7 +83,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index ea3074fa56546..a97910e4c9f4c 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -72,7 +72,7 @@ raft-engine.prefill-for-recycle = true curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index c5e282c91edac..b35c39cff64e1 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -47,7 +47,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ raft-engine.prefill-for-recycle = false ``` -- `oltp_insert` 、および`oltp_update_non_index` `oltp_update_index`ロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータ`oltp_read_write`有効にします。 +- `oltp_insert` 、 `oltp_read_write` 、 `oltp_update_index` 、および`oltp_update_non_index`ワークロードの場合は、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータを有効にします。 ```yaml raft-engine.prefill-for-recycle = true @@ -83,7 +83,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 - 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 + 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest`データベースにインポートします。`${HOST}` 、 `${PORT}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。 ```shell sysbench oltp_common \ diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 931199dde218e..7183d797838b7 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -72,7 +72,7 @@ raft-engine.prefill-for-recycle = true curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/pingcap/go-tpc/master/install.sh | sh ``` - 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫`${PASSWORD}` `tpcc`データベースにインポートします。5、7、9 `${HOST}`実際の値に置き換えてください。このドキュメントでは`${THREAD}` `${THREAD}`値が`50` `200`場合の3つのテストを実施しています`100` + 2. 以下のコマンド`go-tpc tpcc`を実行して、1,000個の倉庫を`tpcc`データベースにインポートします。`${HOST}` 、 `${THREAD}` 、 `${PASSWORD}`を実際の値に置き換えてください。このドキュメントでは`${THREAD}`の値が`50` 、 `100` 、 `200`の場合の3つのテストを実施しています。 ```shell go-tpc tpcc --host ${HOST} --warehouses 1000 prepare -P 4000 -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index 6ac47e8d77ae9..3b376197a2e23 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -72,7 +72,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ - **Leader書き込み最適化**: リーダーがコミットされたがまだ永続化されていないRaftログを早期に適用できるようにし、リーダー ピアの書き込みレイテンシーに対する IO ジッターの影響を軽減します。 -- **低速ノード検出の強化**：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラがトリガーされ、パフォーマンスが回復します。2 [遅いノード検出メカニズム](https://docs.pingcap.com/tidb/v8.5/pd-scheduling-best-practices#troubleshoot-tikv-node) [低速ストアの排除スケジューラ](https://docs.pingcap.com/tidb/v8.5/pd-control#scheduler-show--add--remove--pause--resume--config--describe)を使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。 +- **低速ノード検出の強化**：低速ノード検出アルゴリズムを改良し、デフォルトで低速スコア検出を有効にしました。これにより、低速ノードが特定されると、エビクトリーダースケジューラがトリガーされ、パフォーマンスが回復します。[遅いノード検出メカニズム](https://docs.pingcap.com/tidb/v8.5/pd-scheduling-best-practices#troubleshoot-tikv-node)は、 [低速ストアの排除スケジューラ](https://docs.pingcap.com/tidb/v8.5/pd-control#scheduler-show--add--remove--pause--resume--config--describe)を使用して低速ノードを検出・管理し、クラウドディスクジッターの影響を軽減します。 - **統合ヘルスコントローラー**：TiKVに統合ヘルスコントローラーを追加し、KVクライアントにフィードバックメカニズムを追加します。KVクライアントは、TiKVノードのヘルスとパフォーマンスに基づいて、エラー処理とレプリカ選択を最適化します。 diff --git a/tidb-computing.md b/tidb-computing.md index fc5ec63aed2ac..67f48402c2850 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -109,7 +109,7 @@ TiDB の SQLレイヤーである TiDB サーバーは、SQL ステートメン SQL コンピューティングの最もシンプルなソリューションは、前のセクションで説明した[テーブルデータからキー値へのマッピング](#mapping-of-table-data-to-key-value)です。これは、SQL クエリを KV クエリにマッピングし、KV インターフェイスを介して対応するデータを取得し、さまざまな計算を実行します。 -例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、5であればその行を返します。このプロセスは以下のとおりです。 +例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、そうであればその行を返します。このプロセスは以下のとおりです。 1. キー範囲を構築します。表内のすべての`RowID` `[0, MaxInt64)`範囲に含まれます。行データの`Key`エンコード規則に従って、 `0`と`MaxInt64`を使用すると、左閉じ、右開きの`[StartKey, EndKey)`範囲を構築できます。 2. キー範囲のスキャン: 上記で構築されたキー範囲に従って TiKV 内のデータを読み取ります。 @@ -130,7 +130,7 @@ SQL コンピューティングの最もシンプルなソリューションは 上記の問題を解決するには、RPC呼び出しの大量発生を回避するため、計算処理をストレージノードにできるだけ近づける必要があります。まず、SQL述語条件`name = "TiDB"`計算処理のためにストレージノードにプッシュダウンし、有効な行のみが返されるようにすることで、無駄なネットワーク転送を回避します。次に、集計関数`Count(*)`も事前集計のためにストレージノードにプッシュダウンし、各ノードは`Count(*)`の結果のみを返せば済みます。SQLレイヤーは、各ノードから返された`Count(*)`結果を合計します。 -次の画像は、データがレイヤーレイヤーに返される様子を示しています。 +次の画像は、データがレイヤーごとに返される様子を示しています。 ![dist sql flow](/media/tidb-computing-dist-sql-flow.png) diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 3900b93585f66..09e5ec5490806 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -87,8 +87,8 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - `KILL`ステートメントを MySQL 互換に設定するかどうかを決定します。 - デフォルト値: `false` -- `compatible-kill-query` 、 [`enable-global-kill`](#enable-global-kill-new-in-v610) `false`に設定されている場合にのみ有効になります。 -- [`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`の場合、 `compatible-kill-query`クエリを強制終了する際に`TIDB`キーワードを追加する必要があるかどうかを制御します。 +- `compatible-kill-query`は、[`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`に設定されている場合にのみ有効になります。 +- [`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`の場合、 `compatible-kill-query`は、クエリを強制終了する際に`TIDB`キーワードを追加する必要があるかどうかを制御します。 - `compatible-kill-query`が`false`の場合、TiDB での`KILL xxx`の動作は MySQL とは異なります。TiDB でクエリを強制終了するには、 `TIDB`のように`KILL TIDB xxx`キーワードを追加する必要があります。 - `compatible-kill-query`が`true`の場合、TiDB でクエリを強制終了するには、 `TIDB`キーワードを追加する必要はありません。クライアントが**常に同じ TiDB インスタンスに接続されることが確実でない限り**、構成ファイルで`compatible-kill-query`を`true`に設定することは強くお勧めしません。これは、デフォルトの MySQL クライアントでControl + Cを押すと`KILL`が実行される新しい接続が開かれるためです。クライアントと TiDB クラスタの間にプロキシがある場合、新しい接続は別の TiDB インスタンスにルーティングされる可能性があり、誤って別のセッションが強制終了される可能性があります。 - [`enable-global-kill`](#enable-global-kill-new-in-v610)が`true`の場合、 `KILL xxx`と`KILL TIDB xxx`は同じ効果を持ちます。 @@ -260,7 +260,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - テーブルロック機能を有効にするかどうかを制御します。 - デフォルト値: `false` -- テーブルロックは、複数のセッション間で同じテーブルへの同時アクセスを調整するために使用されます。現在、 `READ` 、 `WRITE` 、および`WRITE LOCAL`ロックタイプがサポートされています。構成項目が`false`に設定されている場合、 `LOCK TABLES`または`UNLOCK TABLES`ステートメントを実行しても効果がなく、「LOCK/UNLOCK TABLES はサポートされていません」という警告が表示されます。詳細については、「 [`LOCK TABLES`と`UNLOCK TABLES`](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md)を参照してください。 +- テーブルロックは、複数のセッション間で同じテーブルへの同時アクセスを調整するために使用されます。現在、 `READ` 、 `WRITE` 、および`WRITE LOCAL`ロックタイプがサポートされています。構成項目が`false`に設定されている場合、 `LOCK TABLES`または`UNLOCK TABLES`ステートメントを実行しても効果がなく、「LOCK/UNLOCK TABLES はサポートされていません」という警告が表示されます。詳細については、[`LOCK TABLES`と`UNLOCK TABLES`](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md)を参照してください。 ### `labels` {#labels} @@ -270,7 +270,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > **Note:** > > - TiDBでは、 `zone`ラベルは、サーバーが配置されているゾーンを指定するために特別に使用されます。 `zone`がnull以外の値に設定されている場合、対応する値は[`txn-score`](/system-variables.md#txn_scope)や[`Follower read`](/follower-read.md)などの機能によって自動的に使用されます。 -> - `group`ラベルは、TiDB Operatorにおいて特別な用途があります。TiDB [TiDB Operator](/tidb-operator-overview.md)を使用してデプロイされたクラスタでは、 `group`ラベルを手動で指定することは推奨さ**れません**。 +> - `group`ラベルは、TiDB Operatorにおいて特別な用途があります。[TiDB Operator](/tidb-operator-overview.md)を使用してデプロイされたクラスタでは、 `group`ラベルを手動で指定することは推奨さ**れません**。 ## log {#log} @@ -429,7 +429,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `cluster-ssl-key` {#cluster-ssl-key} -- TiKVまたはPDをTLSに接続するために使用されるSSL秘密鍵ファイルのパス。 +- TiKVまたはPDをTLSで接続するために使用されるSSL秘密鍵ファイルのパス。 - デフォルト値: "" ### `cluster-verify-cn` {#cluster-verify-cn} @@ -584,12 +584,12 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - すべてのステートメントの優先順位を設定します。 - デフォルト値: `NO_PRIORITY` -- 値のオプション: デフォルト値`NO_PRIORITY` 、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY` 、 `DELAYED` 、 `HIGH_PRIORITY` 。 -- バージョン6.1.0以降、すべてのステートメントの優先順位は、TiDB構成アイテム[`instance.tidb_force_priority`](/tidb-configuration-file.md#tidb_force_priority)またはシステム変数[`tidb_force_priority`](/system-variables.md#tidb_force_priority)によって決定されます。 `force-priority`引き続き有効です。ただし、 `force-priority`と`instance.tidb_force_priority`が同時に設定されている場合、後者が有効になります。 +- 値のオプション: デフォルト値`NO_PRIORITY` 、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY`、`DELAYED`、`HIGH_PRIORITY`です。 +- バージョン6.1.0以降、すべてのステートメントの優先順位は、TiDB構成アイテム[`instance.tidb_force_priority`](/tidb-configuration-file.md#tidb_force_priority)またはシステム変数[`tidb_force_priority`](/system-variables.md#tidb_force_priority)によって決定されます。 `force-priority`は引き続き有効です。ただし、 `force-priority`と`instance.tidb_force_priority`が同時に設定されている場合、後者が有効になります。 > **Note:** > -> バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。 を使用して[リソース制御](/tidb-resource-control-ru-groups.md)異なるSQLステートメントのリソース使用量を管理することをお勧めします。 +> バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。 [リソース制御](/tidb-resource-control-ru-groups.md)を使用して、異なるSQLステートメントのリソース使用量を管理することをお勧めします。 ### `distinct-agg-push-down` {#distinct-agg-push-down} @@ -713,7 +713,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 #### `local-agent-host-port` {#local-agent-host-port} -- 記者がメールを送る宛先は、イェーガーエージェントに繋がっている。 +- レポーターがスパンを jaeger-agent に送信する宛先アドレス。 - デフォルト値: `""` ## pd-client {#pd-client} @@ -763,9 +763,9 @@ opentracing.reporter に関連するコンフィグレーション項目。 ### `batch-policy` v8.3.0の新機能 {#batch-policy-new-in-v830} -- TiDB から TiKV へのリクエストのバッチ処理戦略を制御します。TiDB は、TiKV にリクエストを送信する際、常に現在の待機キュー内のリクエストを`BatchCommandsRequest`にカプセル化し、パケットとして TiKV に送信します。これが基本的なバッチ処理戦略です。TiKV の負荷スループットが高い場合、TiDB は`batch-policy`の値に基づいて、基本的なバッチ処理の後にさらに待機するかどうかを決定します。この追加のバッチ処理により、より多くのリクエストを単一の`BatchCommandsRequest`にカプセル化されたできます。 +- TiDB から TiKV へのリクエストのバッチ処理戦略を制御します。TiDB は、TiKV にリクエストを送信する際、常に現在の待機キュー内のリクエストを`BatchCommandsRequest`にカプセル化し、パケットとして TiKV に送信します。これが基本的なバッチ処理戦略です。TiKV の負荷スループットが高い場合、TiDB は`batch-policy`の値に基づいて、基本的なバッチ処理の後にさらに待機するかどうかを決定します。この追加のバッチ処理により、より多くのリクエストを単一の`BatchCommandsRequest`にカプセル化できます。 - デフォルト値: `"standard"` -- お得なオプション： +- 値のオプション: - `"basic"` : この動作は、v8.3.0 より前のバージョンと一致しており、TiDB は[`tikv-client.max-batch-wait-time`](#max-batch-wait-time)が 0 より大きく、TiKV の負荷が[`tikv-client.overload-threshold`](#overload-threshold)の値を超えた場合にのみ追加のバッチ処理を実行します。 - `"standard"` : TiDB は、最近のリクエストの到着時間間隔に基づいてリクエストを動的にバッチ処理します。これは、高スループットのシナリオに適しています。 - `"positive"` : TiDB は常に追加のバッチ処理を実行します。これは、最適なパフォーマンスを実現するために、高スループットのテストシナリオに適しています。ただし、低負荷のシナリオでは、この戦略により不要なバッチ処理の待機時間が発生し、パフォーマンスが低下する可能性があります。 @@ -814,7 +814,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 ### tikv-client.copr-cache v4.0.0 の新機能 {#tikv-client-copr-cache-new-in-v400} -[コプロセッサーキャッシュ](/coprocessor-cache.md)キャッシュ機能に関する設定項目を紹介します。 +[コプロセッサーキャッシュ](/coprocessor-cache.md)機能に関する設定項目を紹介します。 #### `capacity-mb` {#capacity-mb} @@ -880,7 +880,7 @@ TiDBサービスの状態に関するコンフィグレーション。 ### pessimistic-auto-commit はv6.0.0 で追加されました。 {#pessimistic-auto-commit-new-in-v600} -- 悲観的トランザクション モードがグローバルに有効になっている場合 ( `tidb_txn_mode='pessimistic'` ) に、自動コミット トランザクションが使用するトランザクション モードを決定します。デフォルトでは、悲観的トランザクション モードがグローバルに有効になっていても、自動コミット トランザクションは楽観的トランザクション モードを使用します。 `pessimistic-auto-commit`を有効にすると ( `true` } に設定)、自動コミット トランザクションも悲観的モードを使用するようになり、明示的にコミットされた他の悲観的トランザクションと一貫性が保たれます。 +- 悲観的トランザクション モードがグローバルに有効になっている場合 ( `tidb_txn_mode='pessimistic'` ) に、自動コミット トランザクションが使用するトランザクション モードを決定します。デフォルトでは、悲観的トランザクション モードがグローバルに有効になっていても、自動コミット トランザクションは楽観的トランザクション モードを使用します。 `pessimistic-auto-commit`を有効にすると ( `true` に設定)、自動コミット トランザクションも悲観的モードを使用するようになり、明示的にコミットされた他の悲観的トランザクションと一貫性が保たれます。 - 競合が発生するシナリオでは、この設定を有効にすると、TiDB は自動コミットトランザクションをグローバルロック待機管理に組み込み、デッドロックを回避し、デッドロックを引き起こす競合によって発生するレイテンシーの急増を軽減します。 - 競合のないシナリオで、自動コミット トランザクションが多数ある場合 (具体的な数は実際のシナリオによって決まります。たとえば、自動コミット トランザクションの数がアプリケーションの総数の半分以上を占める場合)、単一のトランザクションが大量のデータを操作すると、この構成を有効にするとパフォーマンスが低下します。たとえば、自動コミット`INSERT INTO SELECT`ステートメントです。 - セッションレベルのシステム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)が`"bulk"`に設定されている場合、セッションにおけるこの設定の効果は、それを`false`に設定することと同じです。 @@ -957,12 +957,12 @@ TiDBサービスの状態に関するコンフィグレーション。 - この設定は、TiDBサーバー上で実行されるステートメントのデフォルトの優先度を変更するために使用されます。 - デフォルト値: `NO_PRIORITY` -- デフォルト値`NO_PRIORITY`は、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY` 、 `DELAYED` 、 `HIGH_PRIORITY` 。 +- デフォルト値`NO_PRIORITY`は、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY`、`DELAYED`、`HIGH_PRIORITY`です。 - v6.1.0より前は、この設定は`force-priority`によって設定されます。 > **Note:** > -> バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。 を使用して[リソース制御](/tidb-resource-control-ru-groups.md)異なるSQLステートメントのリソース使用量を管理することをお勧めします。 +> バージョン6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度は適用されなくなります。 [リソース制御](/tidb-resource-control-ru-groups.md)を使用して、異なるSQLステートメントのリソース使用量を管理することをお勧めします。 ### `max_connections` {#max-connections} diff --git a/tidb-control.md b/tidb-control.md index c6cdcebc51277..4182daf583186 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -142,7 +142,7 @@ tidb-ctl schema in `tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。`in`コマンドを使用して特定のスキーマのすべてのテーブルIDを取得し、 `tid`サブコマンドを使用して詳細なテーブル情報を取得できます。 -例えば、テーブルID `mysql.stat_meta`は`21`です。テーブルID `tidb-ctl schema tid -i 21`を使用すると、テーブルID `mysql.stat_meta`の詳細を取得できます。 +例えば、テーブルID `mysql.stat_meta`は`21`です。`tidb-ctl schema tid -i 21`を使用すると、 `mysql.stat_meta`の詳細を取得できます。 ```json { @@ -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-global-sort.md b/tidb-global-sort.md index 69568a2e59588..2c994e82bb45d 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -20,7 +20,7 @@ summary: TiDB グローバル ソートの使用例、制限、使用方法、 ## 概要 {#overview} -TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。1 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 +TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。[TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)の汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 現在、グローバルソート機能は、クラウドストレージとして Amazon S3 の使用をサポートしています。 diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 88daec18e7a4d..0be13bd810731 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -51,7 +51,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。 - `send-kv-pairs` : 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 - `disk-quota` : 物理インポート モードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスク クォータ。 - - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています[`GOMEMLIMIT`適切に設定します](#change-configuration-parameters) + - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。[`GOMEMLIMIT`を適切に設定します](#change-configuration-parameters) - データ検証 diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index c63dd4e5022e9..da42b07d9ff61 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 147809ea448ba..c279e01b6ebfd 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -18,9 +18,9 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `--config ` | ファイルからグローバル設定を読み取ります。このパラメータが指定されていない場合、 TiDB Lightningはデフォルト設定を使用します。 | | | `-V` | プログラムのバージョンを印刷します。 | | | `-d ` | ローカル ディレクトリまたはデータ ファイルの[外部ストレージURI](/external-storage-uri.md) 。 | `mydumper.data-source-dir` | -| `-L ` | ログ`info` : `debug` 、または`error` `warn`は`info` `fatal` 。 | `lightning.level` | +| `-L ` | ログレベル：`debug` 、 `info` 、 `warn` 、 `error` 、または`fatal` 。デフォルトは`info` 。 | `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` | @@ -56,4 +56,4 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `--checkpoint-error-ignore ` | 指定されたテーブルに関連するチェックポイントに記録されたエラーを無視します。 | | `--checkpoint-remove ` | テーブルのチェックポイントを無条件に削除します。 | -`` 、形式`` `db`.`tbl` `` (バッククォートを含む) の修飾されたテーブル名、またはキーワード`all`いずれかである必要があります。 +`` 、形式`` `db`.`tbl` `` (バッククォートを含む) の修飾されたテーブル名、またはキーワード`all`のいずれかである必要があります。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 8e44478797539..53cf7c310e459 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -68,13 +68,13 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `index-concurrency` {#index-concurrency} -- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。1と`table-concurrency` `index-concurrency`は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 #### `table-concurrency` {#table-concurrency} -- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。1と`table-concurrency` `index-concurrency`は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 @@ -229,7 +229,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 複数のTiDB Lightningインスタンス（物理インポートモード）が1つ以上のターゲットテーブル[並行して](/tidb-lightning/tidb-lightning-distributed-import.md)にデータをインポートできるようにするかどうかを制御します。このパラメータは、ターゲットテーブルが空の場合にのみ使用されることに注意してください。 - デフォルト値: `false` -- 値`false`オプション: `true` +- 値のオプション: `true` 、 `false` - 並列インポート モードを使用する場合は、パラメータを`true`に設定する必要がありますが、ターゲット テーブルにデータが存在しないことが前提となります。つまり、すべてのデータはTiDB Lightningによってのみインポートできます。 #### `duplicate-resolution` {#duplicate-resolution} @@ -264,7 +264,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 物理インポート モードで KV ペアを TiKV に送信するときに圧縮を有効にするかどうかを制御します。 - 現在、Gzip圧縮アルゴリズムのみがサポートされています。このアルゴリズムを使用するには、このパラメータに`"gzip"`または`"gz"`を入力してください。 - デフォルト値: `""` 。圧縮が有効になっていないことを意味します。 -- `"gz"` `"gzip"`オプション: `""` +- 値のオプション: `""` 、 `"gzip"` 、 `"gz"` #### `sorted-kv-dir` {#sorted-kv-dir} @@ -411,7 +411,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 処理速度を上げるには、入力データを[厳格な形式](/tidb-lightning/tidb-lightning-data-source.md#strict-format)で指定します。デフォルト値は、速度ではなく安全性を優先した`false`です。 - デフォルト値: `false` -- 値`false`オプション: `true` +- 値のオプション: `true` 、 `false` - `strict-format = true`次のことが求められます: - CSV では、引用符で囲まれている場合でも、すべての値にリテラルの改行 ( `U+000A`と`U+000D` 、または`\r`と`\n` ) を含めることはできません。つまり、改行は行を区切るために厳密に使用されます。 - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが「厳密」でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 @@ -459,7 +459,7 @@ CSV ファイルの解析方法を構成します。 - デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲット テーブルの列名と一致していることが確認されたことを意味します。そのため、2 つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 - CSVテーブルヘッダーとターゲットテーブルの列名が一致しない（例えば、CSVテーブルヘッダーの一部の列名がターゲットテーブルに見つからない）ものの、列の順序が同じ場合は、この設定を`false`に設定してください。この場合、 TiDB Lightningはエラーを回避するためにCSVヘッダーを無視し、ターゲットテーブルの列の順序でデータを直接インポートします。したがって、列の順序が同じでない場合は、インポート前にCSVファイル内の列の順序をターゲットテーブルの順序と一致するように手動で調整する必要があります。そうしないと、データの不一致が発生する可能性があります。 - デフォルト値: `true` -- 値`false`オプション: `true` +- 値のオプション: `true` 、 `false` > **Note:** > @@ -658,7 +658,7 @@ CSV ファイルの解析方法を構成します。 - チェックサムが完了した後に各テーブルに対して`ANALYZE TABLE `を実行するかどうかを指定します。 - デフォルト値: `"optional"` -- `"off"` `"optional"`オプション: `"required"` +- 値のオプション: `"required"` 、 `"optional"` 、 `"off"` ### クローン {#cron} diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 05b2d32956f39..beebdf58899a5 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} @@ -355,14 +355,14 @@ TiDB Lightningは現在、Amazon Aurora、Apache Hive、Snowflakeによって生 ## 圧縮ファイル {#compressed-files} -TiDB Lightningは現在、 Dumplingでエクスポートされた圧縮ファイル、または命名規則に従った圧縮ファイルをサポートしています。現在、 TiDB Lightningは`gzip` `snappy`圧縮アルゴリズムをサポートしています。ファイル名が命名規則に従っている場合、 TiDB Lightningは`zstd`に圧縮アルゴリズムを識別し、追加の設定なしでストリーミング解凍後にファイルをインポートします。 +TiDB Lightningは現在、 Dumplingでエクスポートされた圧縮ファイル、または命名規則に従った圧縮ファイルをサポートしています。現在、 TiDB Lightningは`gzip` 、`snappy` 、`zstd`圧縮アルゴリズムをサポートしています。ファイル名が命名規則に従っている場合、 TiDB Lightningは自動的に圧縮アルゴリズムを識別し、追加の設定なしでストリーミング解凍後にファイルをインポートします。 > **Note:** > > - TiDB Lightningは単一の大きな圧縮ファイルを同時に解凍できないため、圧縮ファイルのサイズはインポート速度に影響します。解凍後のソースファイルは256MiB以下にすることをお勧めします。 > - TiDB Lightning は個別に圧縮されたデータ ファイルのみをインポートし、複数のデータ ファイルが含まれる単一の圧縮ファイルのインポートはサポートしていません。 -> - TiDB Lightningは、 `db.table.parquet.snappy`などの他の圧縮ツールで圧縮された`parquet`ファイル`parquet` `parquet`ライターの圧縮形式を設定できます。 -> - TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類のファイルはエラーの原因となります。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスク`zstd`エラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。 +> - TiDB Lightningは、 `db.table.parquet.snappy`などの他の圧縮ツールで圧縮された`parquet`ファイルをサポートしていません。`parquet`ファイルを圧縮する場合は、`parquet`ライターの圧縮形式を設定できます。 +> - TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` 、 `snappy` 、 `zstd` 圧縮データファイルのみがサポートされています。その他の種類のファイルはエラーの原因となります。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクはエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。 > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)である必要があります。その他の Snappy 圧縮形式はサポートされていません。 ## カスタマイズされたファイルを一致させる {#match-customized-files} @@ -375,7 +375,7 @@ S3にエクスポートされたAuroraスナップショットを例に挙げま 通常、 `some-database`データベースをインポートするには、 `data-source-dir` `S3://some-bucket/some-subdir/some-database/`に設定します。 -上記のParquetファイルパスに基づいて、 `(?i)^(?:[^/]*/)*([a-z0-9\-_]+).([a-z0-9\-_]+)/(?:[^/]*/)*(?:[a-z0-9\-_.]+\.(parquet))$`ような正規表現を記述することでファイルに一致させることができます。一致グループでは、 `index=1`は`some-database` `index=2` `some-table`は`index=3` `parquet`なります。 +上記のParquetファイルパスに基づいて、 `(?i)^(?:[^/]*/)*([a-z0-9\-_]+).([a-z0-9\-_]+)/(?:[^/]*/)*(?:[a-z0-9\-_.]+\.(parquet))$`ような正規表現を記述することでファイルに一致させることができます。一致グループでは、 `index=1`は`some-database`、`index=2`は`some-table`、`index=3`は`parquet`になります。 デフォルトの命名規則に従わないデータファイルをTiDB Lightningが認識できるように、正規表現と対応するインデックスに従って設定ファイルを記述することができます。例： @@ -394,7 +394,7 @@ type = '$3' - **table** : 対象テーブルの名前。値は次のいずれかです。 - 正規表現を使用して取得されたグループ インデックス (例: `$2` )。 - インポートするテーブルの名前（例： `table1` ）。一致したすべてのファイルは`table1`にインポートされます。 -- **type** : ファイルの種類`sql` `parquet`サポートします。値は`csv`のとおりです。 +- **type** : ファイルの種類。`sql` 、`parquet` 、`csv`をサポートします。値は次のとおりです。 - 正規表現を使用して取得されたグループ インデックス (例: `$3` )。 - **key** : ファイル番号 (例: `${db_name}.${table_name}.001.csv`の場合は`001` 。 - 正規表現を使用して取得されたグループ インデックス (例: `$4` )。 diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 471c4183e6226..0479c114194ad 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -51,7 +51,7 @@ TiDB Lightningでは、テーブルのチェックサムは、そのテーブル - すべてのKVペアの合計長さ、および - 各ペアの[CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check)値のビット単位の XOR です。 -TiDB Lightning [インポートされたデータを検証する](/tidb-lightning/tidb-lightning-faq.md#how-to-ensure-the-integrity-of-the-imported-data) 、各テーブルの[地元](/tidb-lightning/tidb-lightning-glossary.md#local-checksum)と[リモートチェックサム](/tidb-lightning/tidb-lightning-glossary.md#remote-checksum)比較することで、このチェックを実行します。いずれのペアも一致しない場合、プログラムは停止します。このチェックは、 `post-restore.checksum`設定を`false`に設定することでスキップできます。 +TiDB Lightning [インポートされたデータを検証する](/tidb-lightning/tidb-lightning-faq.md#how-to-ensure-the-integrity-of-the-imported-data) 、各テーブルの[ローカル](/tidb-lightning/tidb-lightning-glossary.md#local-checksum)と[リモートチェックサム](/tidb-lightning/tidb-lightning-glossary.md#remote-checksum)を比較することで、このチェックを実行します。いずれのペアも一致しない場合、プログラムは停止します。このチェックは、 `post-restore.checksum`設定を`false`に設定することでスキップできます。 チェックサムの不一致を適切に処理する方法については、 [よくある質問](/tidb-lightning/troubleshoot-tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)も参照してください。 @@ -167,7 +167,7 @@ KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によ ### 後処理 {#post-processing} -データソース全体が解析され、TiKV Importer に送信された後の期間。TiDB Lightning はTiKV Importer のアップロードを待機し、 [SST ファイル](/tidb-lightning/tidb-lightning-glossary.md#sst-file)の[摂取する](/tidb-lightning/tidb-lightning-glossary.md#ingest) 。 +データソース全体が解析され、TiKV Importer に送信された後の期間。TiDB Lightning はTiKV Importer のアップロードを待機し、 [SST ファイル](/tidb-lightning/tidb-lightning-glossary.md#sst-file)を[取り込み](/tidb-lightning/tidb-lightning-glossary.md#ingest) 。 @@ -193,4 +193,4 @@ KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によ SSTは「sorted string table（ソートされた文字列テーブル）」の略です。SSTファイルは、RocksDB（およびTiKV）のKVペアのコレクションのネイティブストレージ形式です。 -TiKVインポーターは、閉じた[エンジン](/tidb-lightning/tidb-lightning-glossary.md#engine)からSSTファイルを生成します。これらのSSTファイルはアップロードされ、その後TiKVストアに[摂取した](/tidb-lightning/tidb-lightning-glossary.md#ingest)されます。 +TiKVインポーターは、閉じた[エンジン](/tidb-lightning/tidb-lightning-glossary.md#engine)からSSTファイルを生成します。これらのSSTファイルはアップロードされ、その後TiKVストアに[取り込まれ](/tidb-lightning/tidb-lightning-glossary.md#ingest)ます。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index 9dbde2334af44..f8cbf60bb0bbd 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -41,7 +41,7 @@ backend = "local" 6. すべてのエンジンファイルがインポートされた後、 TiDB Lightningはローカルデータソースと下流クラスターのチェックサムを比較し、インポートされたデータが破損していないことを確認します。その後、 TiDB Lightningはステップ2で削除したセカンダリインデックスを追加するか、TiDBに新しいデータを分析させて（ `ANALYZE` ）、将来の操作を最適化します。一方、 `tidb-lightning`将来の競合を防ぐために`AUTO_INCREMENT`値を調整します。 - AUTO_INCREMENT IDは行数の**上限**に基づいて推定され、テーブルデータファイルの合計サイズに比例します。そのため、AUTO_INCREMENT IDは通常、実際の行数よりも大きくなります。これは、AUTO_INCREMENT IDが[必ずしも連続しているわけではない](/mysql-compatibility.md#auto-increment-id)あるため、正常な動作です。 + AUTO_INCREMENT IDは行数の**上限**に基づいて推定され、テーブルデータファイルの合計サイズに比例します。そのため、AUTO_INCREMENT IDは通常、実際の行数よりも大きくなります。これは、AUTO_INCREMENT IDが[必ずしも連続しているわけではない](/mysql-compatibility.md#auto-increment-id)ため、正常な動作です。 7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 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 1c52884bbd3d4..64520cd3f1841 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-performance-tuning-config.md b/tidb-performance-tuning-config.md index 783d036881e75..8241dc4686308 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -185,7 +185,7 @@ snap-io-max-bytes-per-sec = "300MiB" | 平均レイテンシー（ミリ秒） | 35.87 | 31.92 | -11.01% | | P95レイテンシー（ms） | 58.92 | 51.02 | -13.41% | | プランキャッシュヒット率（％） | 56.89% | 87.51% | +53.82% | -| キャッシュメモリ使用量（MiB）を計画する | 95.3 | 70.2 | -26.34% | +| プランキャッシュメモリ使用量（MiB） | 95.3 | 70.2 | -26.34% | #### 主なメリット {#key-benefits} @@ -272,7 +272,7 @@ sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user #### パフォーマンス分析 {#performance-analysis} -バージョン7.6.0以降、Titanはデフォルトで有効になっています。TiDB v8.4.0では、Titanのデフォルト値は`min-blob-size`ですが、現在は`32KiB`なっています。ベースライン構成では、レコードサイズを`31KiB`に設定することで、データがRocksDBに保存されるようにしています。一方、キー設定構成では、 `min-blob-size` ～ `1KiB`に設定すると、データがTitanに保存されます。 +バージョン7.6.0以降、Titanはデフォルトで有効になっています。TiDB v8.4.0では、Titanの`min-blob-size`のデフォルト値は`32KiB`です。ベースライン構成では、レコードサイズを`31KiB`に設定することで、データがRocksDBに保存されるようにしています。一方、キー設定構成では、 `min-blob-size` ～ `1KiB`に設定すると、データがTitanに保存されます。 主要設定で確認されたパフォーマンスの向上は、主にTitanがRocksDBの圧縮を削減する能力によるものです。以下の図に示すように、 @@ -285,7 +285,7 @@ sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user #### テストワークロード {#test-workload} -以下のコマンド`go-ycsb load`データが読み込まれます。 +以下の`go-ycsb load`コマンドでデータが読み込まれます。 ```bash go-ycsb load mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p threadcount=100 -p recordcount=5000000 -p operationcount=5000000 -p workload=core -p requestdistribution=uniform -pfieldcount=31 -p fieldlength=1024 @@ -313,7 +313,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p 以下に、よくある例外的なケースをいくつか挙げます。 -- 高頻度の小さなクエリに対して、TSOは高い待機時間を設ける。 +- 高頻度の小さなクエリでのTSO待機時間が長い - さまざまなワークロードに適した最大チャンクサイズを選択してください。 - 読み込み負荷の高いワークロード向けにコプロセッサキャッシュを調整する - ワークロード特性に合わせてチャンクサイズを最適化 @@ -329,7 +329,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p > > これらの最適化は、使用状況やデータパターンによって効果が異なる可能性があるため、慎重に適用し、徹底的にテストしてください。 -### 高頻度の小さなクエリに対して、TSOは高い待機時間を設ける。 {#high-tso-wait-for-high-frequency-small-queries} +### 高頻度の小さなクエリでのTSO待機時間が長い {#high-tso-wait-for-high-frequency-small-queries} #### トラブルシューティング {#troubleshooting} diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 48efce201478a..01d7d5548bc1b 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -12,9 +12,9 @@ aliases: ['/ja/tidb/v8.5/tidb-resource-control/','/ja/tidb/stable/tidb-resource- クラスタ管理者として、リソース制御機能を使用して、リソースグループの作成、リソースグループの割り当て量の設定、およびユーザーをそれらのグループにバインドすることができます。 -TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)については を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 +TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 -- TiDBフロー制御：TiDBフロー制御は を使用します。バケットに十分なトークンがなく、リソースグループ [トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 +- TiDBフロー制御：TiDBフロー制御は[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します。バケットに十分なトークンがなく、リソースグループが`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 - TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの`RU_PER_SEC`の値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 @@ -22,14 +22,14 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と -- TiFlashフロー制御: [TiFlashパイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)ライン実行モデルを使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 +- TiFlashフロー制御: [TiFlashパイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 - TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 -- TiFlashフロー制御: [TiFlashパイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)ライン実行モデルを使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 +- TiFlashフロー制御: [TiFlashパイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 - TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 @@ -164,7 +164,7 @@ TiDB Cloudの場合、 [`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stab CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 600; ``` -3. 絶対優先度を`rg3` `HIGH`を作成します。現在の絶対優先度は`LOW|MEDIUM|HIGH`をサポートしています。デフォルト値は`MEDIUM`です。 +3. 絶対優先度を`HIGH`に設定してリソースグループ`rg3`を作成します。現在の絶対優先度は`LOW|MEDIUM|HIGH`をサポートしています。デフォルト値は`MEDIUM`です。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 100 PRIORITY = HIGH; @@ -180,13 +180,13 @@ TiDBは、以下の3つのレベルのリソースグループ設定をサポー #### ユーザーをリソースグループにバインドする {#bind-users-to-a-resource-group} -次の例では、ユーザー`usr1`を作成し、そのユーザーをリソース グループ`rg1`にバインドします。 `rg1`は[リソースグループを作成する](#create-a-resource-group)するの例で作成されたリソース グループです。 +次の例では、ユーザー`usr1`を作成し、そのユーザーをリソース グループ`rg1`にバインドします。 `rg1`は[リソースグループを作成する](#create-a-resource-group)の例で作成されたリソース グループです。 ```sql CREATE USER 'usr1'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg1; ``` -次の例では`ALTER USER`を使用して、ユーザー`usr2`をリソース グループ`rg2`にバインドします。 `rg2`は[リソースグループを作成する](#create-a-resource-group)するの例で作成されたリソース グループです。 +次の例では`ALTER USER`を使用して、ユーザー`usr2`をリソース グループ`rg2`にバインドします。 `rg2`は[リソースグループを作成する](#create-a-resource-group)の例で作成されたリソース グループです。 ```sql ALTER USER usr2 RESOURCE GROUP rg2; @@ -326,7 +326,7 @@ TiDBはシステム変数[`tidb_last_query_info`](/system-variables.md#tidb_last #### RUの統計情報をstatements_summary別に表示する {#view-ru-statistics-by-code-statements-summary-code} -TiDB のシステム テーブル[`INFORMATION_SCHEMA.statements_summary`](/statement-summary-tables.md#statements_summary)には、SQL ステートメントの正規化および集計された統計情報が格納されます。このシステム テーブルを使用すると、SQL ステートメントの実行パフォーマンスを表示および分析できます。また、リソース グループ名、RU 消費量、利用可能な RU の待機時間など、リソース制御に関する統計情報も含まれています。詳細については、 [`statements_summary`フィールドの説明](/statement-summary-tables.md#statements_summary-fields-description)を参照してください。 説明 +TiDB のシステム テーブル[`INFORMATION_SCHEMA.statements_summary`](/statement-summary-tables.md#statements_summary)には、SQL ステートメントの正規化および集計された統計情報が格納されます。このシステム テーブルを使用すると、SQL ステートメントの実行パフォーマンスを表示および分析できます。また、リソース グループ名、RU 消費量、利用可能な RU の待機時間など、リソース制御に関する統計情報も含まれています。詳細については、 [`statements_summary`フィールドの説明](/statement-summary-tables.md#statements_summary-fields-description)を参照してください。 ### リソースグループのRU消費量を表示する {#view-the-ru-consumption-of-resource-groups} @@ -357,7 +357,7 @@ SELECT * FROM request_unit_by_group LIMIT 5; -TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の**[TiDB]** > **[リソース制御]**ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについては[TiDBの重要な監視指標](/grafana-tidb-dashboard.md)の**「リソース制御**」セクションで詳しく説明されています。 +TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の**[TiDB]** > **[リソース制御]**ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについては[TiDBの重要な監視指標](/grafana-tidb-dashboard.md)の**リソース制御**セクションで詳しく説明されています。 TiKV は、さまざまなリソース グループからのリクエスト QPS も記録します。詳細については、 [TiKVモニタリング指標の詳細](/grafana-tikv-dashboard.md#grpc)を参照してください。 @@ -379,7 +379,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー ## ツールの互換性 {#tool-compatibility} -リソース制御機能は、データのインポート、エクスポート、およびその他のレプリケーションツールの通常の使用には影響しませんBR、 TiDB Lightning、およびTiCDCは現在、リソース制御に関連するDDL操作の処理をサポートしておらず、リソース消費はリソース制御によって制限されません。 +リソース制御機能は、データのインポート、エクスポート、およびその他のレプリケーションツールの通常の使用には影響しません。BR、TiDB Lightning、およびTiCDCは現在、リソース制御に関連するDDL操作の処理をサポートしておらず、リソース消費はリソース制御によって制限されません。 ## FAQ {#faq} diff --git a/tidb-rowid.md b/tidb-rowid.md index 7e9852f298fe1..8375704a49b04 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -147,7 +147,7 @@ CREATE TABLE t ( - [`SHOW TABLE NEXT_ROW_ID`](/sql-statements/sql-statement-show-table-next-rowid.md) ：TiDBが次に割り当てる行IDを示します - [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md) ：ホットスポットを減らすために暗黙の行IDをシャーディングする -- [`Clustered Indexes`](/clustered-indexes.md) : テーブルが主キーを使用する理由を説明します`_tidb_rowid` +- [`Clustered Indexes`](/clustered-indexes.md) : テーブルが`_tidb_rowid`の代わりに主キーを使用する場合を説明します - [`tidb_opt_write_row_id`](/system-variables.md#tidb_opt_write_row_id) ： `_tidb_rowid`への書き込みを許可するかどうかを制御します ## 関連項目 {#see-also} 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 b466d769de0bb..851acccb9e310 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`情報にあるかどうかを確認できます。 @@ -362,7 +362,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - PD はLeaderを選出できません: PD ログには`lease is not expired`が表示されます。 [この問題は](https://github.com/etcd-io/etcd/issues/10355)v3.0.x および v2.1.19 で修正されました。中国語の[ケース875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)を参照してください。 - - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `region storage`を`use-region-storage`に設定することで`true`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 + - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 - 5.2.3 TiDBがSQLステートメントを実行する際にPDがタイムアウトしました。 diff --git a/tiflash-deployment-topology.md b/tiflash-deployment-topology.md index a9dafa40ef7ae..c0a757b766512 100644 --- a/tiflash-deployment-topology.md +++ b/tiflash-deployment-topology.md @@ -38,5 +38,5 @@ TiFlashは列指向型ストレージエンジンであり、徐々に標準的 > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPクラスタコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 > - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 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/monitor-tiflash.md b/tiflash/monitor-tiflash.md index 71f585bef0466..814faa99789b3 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -11,13 +11,13 @@ TiUPを使用してTiDBクラスターをデプロイする場合、監視シス Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporterを含む一連のサブダッシュボードに分かれています。診断に役立つ多くのメトリクスが用意されています。 -TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlash-Proxy-Details の**3つのダッシュボードパネルがあります。これらのパネルに表示されるメトリックは、 TiFlashの現在の状態を示します。 **TiFlash-Proxy-Summary**パネルと**TiFlash-Proxy-Details**パネルは、主にRaftレイヤーの情報を表示します。メトリックの詳細は[TiKVの主要な監視指標](/grafana-tikv-dashboard.md)を参照してください。 +TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlash-Proxy-Details**の3つのダッシュボードパネルがあります。これらのパネルに表示されるメトリックは、 TiFlashの現在の状態を示します。 **TiFlash-Proxy-Summary**パネルと**TiFlash-Proxy-Details**パネルは、主にRaftレイヤーの情報を表示します。メトリックの詳細は[TiKVの主要な監視指標](/grafana-tikv-dashboard.md)を参照してください。 > **Note:** > > TiFlashのモニターを改善するには、 TiDB v4.0.5 以降のバージョンを使用することをお勧めします。 -次のセクションでは**、 TiFlash-Summary**のデフォルトの監視情報を紹介します。 +次のセクションでは、**TiFlash-Summary**のデフォルトの監視情報を紹介します。 ## サーバ {#server} @@ -62,7 +62,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## DDL {#ddl} - スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 -- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply`の3 `failed apply`の`apply`のカウントが含まれます。13 `diff apply`単一の適用の通常のプロセスです。15 `full apply`失敗した場合、 `diff apply` `failed apply` `1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 +- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 - スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 - スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index 41cadf172686c..28ccd8cad98c6 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -19,7 +19,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - このエラーは、何らかの間違ったロジックによって発生した可能性があります。1 [サポートを受ける](/support.md)またはコミュニティから。 + このエラーは、何らかの間違ったロジックによって発生した可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 ## `TiFlash_schema_apply_duration` {#tiflash-schema-apply-duration} @@ -33,7 +33,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 ## `TiFlash_raft_read_index_duration` {#tiflash-raft-read-index-duration} @@ -65,4 +65,4 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。PingCAP またはコミュニティから[サポートを受ける](/support.md)。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index e8fb2db6d065a..fca487175c401 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -52,9 +52,9 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - DTFile の基本的な I/O 速度テストを提供します。 - パラメータ: - - `--version` : DTFileのバージョン[`dttool migrate`における`--version`](#dttool-migrate)参照してください。 - - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。2 [`dttool migrate` `--algorithm`](#dttool-migrate)参照してください。 - - `--frame` : 検証フレームのサイズ[`dttool migrate`における`--frame`](#dttool-migrate)参照してください。 + - `--version` : DTFileのバージョン。[`dttool migrate`における`--version`](#dttool-migrate)を参照してください。 + - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。[`dttool migrate`における`--algorithm`](#dttool-migrate)を参照してください。 + - `--frame` : 検証フレームのサイズ。[`dttool migrate`における`--frame`](#dttool-migrate)を参照してください。 - `--column` : テストするテーブルの列。デフォルト値は`100`です。 - `--size` : テストするテーブルの行。デフォルト値は`1000`です。 - `--field` : テスト対象テーブルのフィールド長制限。デフォルト値は`1024`です。 @@ -76,6 +76,6 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - `--config-file` : `dttool bench`の設定ファイル[`dttool migrate`における`--config-file`](#dttool-migrate)参照してください。 - `--check` : ハッシュ検証を実行します。 - - `--file-id` ：DTFileのID。2 [`dttool migrate`における`--file-id`](#dttool-migrate)参照してください。 - - `--imitative` : データベースコンテキストを模倣します。2 [`dttool migrate`における`--imitative`](#dttool-migrate)参照してください。 - - `--workdir` : データディレクトリ。2 [`dttool migrate`における`--workdir`](#dttool-migrate)参照してください。 + - `--file-id` ：DTFileのID。[`dttool migrate`における`--file-id`](#dttool-migrate)を参照してください。 + - `--imitative` : データベースコンテキストを模倣します。[`dttool migrate`における`--imitative`](#dttool-migrate)を参照してください。 + - `--workdir` : データディレクトリ。[`dttool migrate`における`--workdir`](#dttool-migrate)を参照してください。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index b436726f9962c..2144fd7449539 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -358,7 +358,7 @@ I/O トラフィック制限設定を構成します。 - 単一のクエリで生成される中間データのメモリ使用量の制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味します。 -- 値が 1 から`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 +- 値が`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値: `0` 、制限がないことを意味します。 @@ -366,7 +366,7 @@ I/O トラフィック制限設定を構成します。 - すべてのクエリで生成される中間データのメモリ使用量制限。 - 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味し、 `0`制限なしを意味します。 -- v6.6.0以降では、 `[0.0, 1.0)`から10000000000000の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 +- v6.6.0以降では、 `[0.0, 1.0)`の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 - クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 - デフォルト値： `0.8` （総メモリの80%を意味します）。v6.6.0より前のバージョンでは、デフォルト値は`0` （無制限を意味します）でした。 @@ -554,7 +554,7 @@ I/O トラフィック制限設定を構成します。 ##### `data-encryption-method` {#data-encryption-method} -- データファイルの暗号化方法。1以外の値は暗号化`"plaintext"`有効であることを意味します。その場合はマスターキーを指定する必要があります。 +- データファイルの暗号化方法。`"plaintext"`以外の値は暗号化が有効であることを意味します。その場合はマスターキーを指定する必要があります。 - デフォルト値: `"plaintext"` 。これは、暗号化がデフォルトで無効になっていることを意味します。 - `"aes256-ctr"` `"aes192-ctr"`オプション: `"aes128-ctr"` `"sm4-ctr"` `"plaintext"`で導入`"sm4-ctr"`れました。 diff --git a/tiflash/tiflash-data-validation.md b/tiflash/tiflash-data-validation.md index ab50f5b3df1ca..7d1e75294c5d7 100644 --- a/tiflash/tiflash-data-validation.md +++ b/tiflash/tiflash-data-validation.md @@ -17,7 +17,7 @@ summary: TiFlashのデータ検証メカニズムとツールについて学習 検証メカニズムはDeltaTreeファイル（DTFile）を基盤としています。DTFileはTiFlashデータを保存するstorageファイルです。DTFileには以下の3つの形式があります。 -| バージョン | 州 | 検証メカニズム | 注記 | +| バージョン | 状態 | 検証メカニズム | 注記 | | :---- | :------------------------ | :-------------------------------------------------------- | :---------------------------- | | V1 | 非推奨 | ハッシュはデータ ファイルに埋め込まれます。 | | | V2 | バージョン6.0.0未満のデフォルト | ハッシュはデータ ファイルに埋め込まれます。 | V1 と比較して、V2 では列データの統計が追加されます。 | diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index 14608f3bd86fc..257d88c96be4c 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -11,7 +11,7 @@ TiFlashでは、列指向レプリカはRaft Learnerコンセンサスアルゴ -TiDB Cloud を使用すると、HTAP ワークロードに応じて 1 つ以上のTiFlashノードを指定するだけで、HTAP クラスターを簡単に作成できます。クラスター作成時にTiFlashノード数を指定していない場合、またはTiFlashノードを追加したい場合は、ノード数を[クラスターのスケーリング](/tidb-cloud/scale-tidb-cluster.md)ずつ変更できます。 +TiDB Cloud を使用すると、HTAP ワークロードに応じて 1 つ以上のTiFlashノードを指定するだけで、HTAP クラスターを簡単に作成できます。クラスター作成時にTiFlashノード数を指定していない場合、またはTiFlashノードを追加したい場合は、ノード数を[クラスターのスケーリング](/tidb-cloud/scale-tidb-cluster.md)することで変更できます。 diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index d906fad8fd994..723dcc420903d 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -56,6 +56,6 @@ TiFlashのオリジナルのストリームモデルは、スレッドスケジ タスク内のI/O負荷の高い計算ロジックを実行します。例えば、中間結果をディスクに書き込むなどです。 - - 原子炉を待つ + - Wait reactor タスク内の待機ロジックを実行します。たとえば、ネットワークレイヤーがデータパケットを計算レイヤーに転送するのを待機します。 diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index df91cdbdbe671..cb4e0f5b3ce89 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -39,7 +39,7 @@ TiFlash は様々な理由により正常に起動しない場合があります TiFlashのワークロードが大きすぎてTiFlashデータのレプリケーションが遅れる場合、一部のクエリでエラー`Region Unavailable`が返されることがあります。 -この場合、ワークロードを[TiFlashノードの追加](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)ずつバランスさせることができます。 +この場合、ワークロードを[TiFlashノードの追加](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)することでバランスさせることができます。 ## データファイルの破損 {#data-file-corruption} @@ -253,7 +253,7 @@ TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...` 5. PD が適切にスケジュールされているかどうかを確認します。 - `pd.log`ファイルで`table--r`というキーワードを検索し、 `add operator`ようなスケジューリングログを見つけてください。または、Grafana の PD ダッシュボードの**Operator/Schedule オペレータ作成で**`add-rule-peer`オペレータが存在するかどうかを確認してください。また、Grafana の PD ダッシュボードで**Scheduler/Patrol リージョン時間の**値を確認することもできます。Patrol **リージョン時間は、PD がすべてのリージョンをスキャンしてスケジューリング操作を生成するまでの所要時間です。値が大きいと、**スケジューリングに遅延が発生する可能性があります。 + `pd.log`ファイルで`table--r`というキーワードを検索し、 `add operator`ようなスケジューリングログを見つけてください。または、Grafana の PD ダッシュボードの**Operator/Schedule オペレータ作成で**`add-rule-peer`オペレータが存在するかどうかを確認してください。また、Grafana の PD ダッシュボードで**Scheduler/Patrol リージョン時間の**値を確認することもできます。**Patrol リージョン時間**は、PD がすべてのリージョンをスキャンしてスケジューリング操作を生成するまでの所要時間です。値が大きいと、スケジューリングに遅延が発生する可能性があります。 - `pd.log`キーワード`table--r`と`add operator`スケジュール ログが含まれている場合、または**Scheduler/Patrol リージョン時間**パネルの期間値が正常に表示される場合は、PD スケジュールが適切に機能していることを示します。 - `add-rule-peer`スケジュールログが見つからない場合、または**パトロールリージョンの時間**が30分を超える場合、PD はスケジュールを正しく実行していないか、スケジュールの実行に時間がかかっています。TiDB、PD、およびTiFlash のログファイルを[サポートを受ける](/support.md)に収集してください。 diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 92253ae63b7a2..f935628124ceb 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -93,7 +93,7 @@ mysql> explain analyze select o_orderpriority, count(*) as order_count from orde 18 rows in set (6.00 sec) ``` -### 集計関数をJoinまたはUnion前の位置へプッシュダウンします {#push-down-aggregate-functions-to-a-position-before-code-join-code-or-code-union-code} +### 集計関数をJoinまたはUnion前の位置へプッシュダウンします {#push-down-aggregate-functions-to-a-position-before-join-or-union} 集計演算を`Join`または`Union`前の位置までプッシュダウンすることで、 `Join`または`Union`演算で処理されるデータを削減でき、パフォーマンスが向上します。 @@ -165,7 +165,7 @@ mysql> explain analyze select count(*) from t1 join t2 where t1.a = t2.b group b 18 rows in set (0.46 sec) ``` -### Distinct最適化を有効にする {#enable-code-distinct-code-optimization} +### Distinct最適化を有効にする {#enable-distinct-optimization} TiFlashは、 `Sum`列など、 `Distinct`列を受け入れる一部の集計関数をサポートしていません。デフォルトでは、集計関数全体がTiDBで計算されます。 `Distinct`最適化を有効にすると、一部の操作をTiFlashにプッシュダウンできるため、クエリパフォーマンスが向上します。 @@ -215,7 +215,7 @@ mysql> explain analyze select count(distinct a) from test.t; 5 rows in set, 2 warnings (0.24 sec) ``` -### ALTER TABLE ... COMPACTステートメントを使用してデータを圧縮する {#compact-data-using-the-code-alter-table-compact-code-statement} +### ALTER TABLE ... COMPACTステートメントを使用してデータを圧縮する {#compact-data-using-the-alter-table--compact-statement} [`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)文を実行すると、 TiFlashノード上の特定のテーブルまたはパーティションのコンパクションが開始されます。コンパクション中は、ノード上の物理データが書き換えられ、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。これにより、アクセスパフォーマンスが向上し、ディスク使用量が削減されます。以下に例を示します。 @@ -267,7 +267,7 @@ mysql> explain analyze select max(l_shipdate), max(l_commitdate), max(l_receiptd 11 rows in set (3.83 sec) ``` -セット`tidb_broadcast_join_threshold_size` ～ `10000000` : +`tidb_broadcast_join_threshold_size`を`10000000`に設定 : ```sql mysql> set @@tidb_broadcast_join_threshold_size = 10000000; @@ -326,7 +326,7 @@ mysql> explain analyze select a, count(*) from t group by a; 9 rows in set (0.67 sec) ``` -セット`tidb_max_tiflash_threads` ～ `20` : +`tidb_max_tiflash_threads`を`20`に設定 : ```sql mysql> set @@tidb_max_tiflash_threads = 20; @@ -353,9 +353,9 @@ mysql> explain analyze select a, count(*) from t group by a; 9 rows in set (0.37 sec) ``` -### tiflash_fine_grained_shuffle_stream_countを設定する {#configure-code-tiflash-fine-grained-shuffle-stream-count-code} +### tiflash_fine_grained_shuffle_stream_countを設定する {#configure-tiflash_fine_grained_shuffle_stream_count} -Fine Grained Shuffle 機能を[`tiflash_fine_grained_shuffle_stream_count`](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620)設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。 +Fine Grained Shuffle 機能の[`tiflash_fine_grained_shuffle_stream_count`](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620)を設定することで、ウィンドウ関数の実行における同時実行性を高めることができます。これにより、ウィンドウ関数の実行により多くのシステムリソースが使用されるようになり、クエリのパフォーマンスが向上します。 ウィンドウ関数がTiFlashにプッシュダウンされて実行される際、この変数を使用してウィンドウ関数実行の同時実行レベルを制御できます。単位はスレッドです。 @@ -363,7 +363,7 @@ Fine Grained Shuffle 機能を[`tiflash_fine_grained_shuffle_stream_count`](/sys set @@tiflash_fine_grained_shuffle_stream_count = 20; ``` -次の例は、変数`tiflash_fine_grained_shuffle_stream_count`が再構成される前後のクエリ結果を示しています。再構成前は、 `[ExchangeSender_11, ExchangeReceiver_12, Sort_13, Window_22]`のうち`stream_count` 8 です。再構成後は、 `stream_count` 20 になります。 +次の例は、変数`tiflash_fine_grained_shuffle_stream_count`が再構成される前後のクエリ結果を示しています。再構成前は、 `[ExchangeSender_11, ExchangeReceiver_12, Sort_13, Window_22]`のうち`stream_count`は 8 です。再構成後は、 `stream_count`は 20 になります。 `tiflash_fine_grained_shuffle_stream_count`が再構成される前: @@ -383,7 +383,7 @@ mysql> explain analyze select *, row_number() over (partition by a) from t; 7 rows in set (4 min 30.59 sec) ``` -セット`tiflash_fine_grained_shuffle_stream_count` ～ `20` : +`tiflash_fine_grained_shuffle_stream_count`を`20`に設定 : ```sql mysql> set @@tiflash_fine_grained_shuffle_stream_count = 20; diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 4e2858af110f6..7c6f3b02d8b31 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -11,7 +11,7 @@ TiDBは、 TiFlashレプリカを読み取る3つの方法を提供します。 ## スマートな選択 {#smart-selection} -TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。1または`desc` `explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： +TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。`desc`または`explain analyze`ステートメントを使用して、 TiFlashレプリカが選択されているかどうかを確認できます。例： ```sql desc select count(*) from test.t; @@ -38,7 +38,7 @@ explain analyze select count(*) from test.t; | └─TableFullScan_16 | 1.00 | 1 | cop[tiflash] | table:t | tiflash_task:{time:43ms, loops:1, threads:1}, tiflash_scan:{...} | keep order:false, stats:pseudo | N/A | N/A | +--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+ -`cop[tiflash]` 、タスクが処理のためにTiFlashに送信されることを意味します。TiFlash レプリカを選択してTiFlashない場合は、 `analyze table`ステートメントを使用して統計情報を更新し、 `explain analyze`ステートメントを使用して結果を確認できます。 +`cop[tiflash]`は、タスクが処理のためにTiFlashに送信されることを意味します。TiFlash レプリカを選択していない場合は、 `analyze table`ステートメントを使用して統計情報を更新し、 `explain analyze`ステートメントを使用して結果を確認できます。 テーブルにTiFlashレプリカが1つしか存在せず、関連ノードがサービスを提供できない場合、CBOモードのクエリは繰り返し再試行されることに注意してください。このような状況では、エンジンを指定するか、手動ヒントを使用してTiKVレプリカからデータを読み取る必要があります。 diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index 6b05997aeb79d..86d502066c1e6 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -17,7 +17,7 @@ summary: TiFlashの MPP モードとその使用方法を学びます。 -TiFlashは、クエリ実行にMPPモードをサポートしています。このモードでは、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。TiDBは、オプティマイザのコスト推定に基づいて、MPPモードを選択するかどうかを自動的に決定します。1と[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50) [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)値を変更することで、選択戦略を変更できます。 +TiFlashは、クエリ実行にMPPモードをサポートしています。このモードでは、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。TiDBは、オプティマイザのコスト推定に基づいて、MPPモードを選択するかどうかを自動的に決定します。[`tidb_allow_mpp`](/system-variables.md#tidb_allow_mpp-new-in-v50)と[`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)の値を変更することで、選択戦略を変更できます。 次の図は、MPP モードの動作を示しています。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 0bf3abf5bba27..07f829477e46d 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -115,7 +115,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `advertise-addr` {#advertise-addr} -- 顧客とのコミュニケーションのためのリスニングアドレスを宣伝する +- クライアント通信のためのリスニングアドレスを宣伝する - この設定項目が設定されていない場合、 `addr`の値が使用されます。 - デフォルト値: `""` @@ -343,7 +343,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - デフォルト値: `2000` - 最小値: `2` -### `auto-adjust-pool-size` v6.3.0で追加） {#auto-adjust-pool-size-new-in-v630} +### `auto-adjust-pool-size` v6.3.0で追加 {#auto-adjust-pool-size-new-in-v630} - スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在の CPU 使用率に基づいて UnifyReadPool スレッドプールのサイズを自動的に調整することで、TiKV の読み取りパフォーマンスが最適化されます。スレッドプールの可能な範囲は`[max-thread-count, MAX(4, CPU)]`です。最大値は[`max-thread-count`](#max-thread-count)と同じです。 - デフォルト値: `false` @@ -488,7 +488,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - エンジンタイプを指定します。この設定は、新しいクラスターを作成する際にのみ指定でき、一度指定すると変更できません。 - デフォルト値: `"raft-kv"` -- お得なオプション： +- 値のオプション： - `"raft-kv"` : TiDB v6.6.0 より前のバージョンにおけるデフォルトのエンジンタイプ。 - `"partitioned-raft-kv"` : TiDB v6.6.0 で導入された新しいストレージエンジン タイプ。 @@ -550,7 +550,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `api-version` v6.1.0で追加 {#api-version-new-in-v610} - TiKVがRawKVストアとして機能する際にTiKVが使用するストレージフォーマットとインターフェースバージョン。 -- お得なオプション： +- 値のオプション： - `1` : API V1 を使用し、クライアントから渡されたデータをエンコードせず、そのまま保存します。バージョン 6.1.0 より前の TiKV では、デフォルトで API V1 が使用されます。 - `2` : API V2 を使用します: - データは[マルチバージョン同時実行制御 (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc)形式で保存され、タイムスタンプは tikv-server によって PD (TSO) から取得されます。 @@ -558,12 +558,12 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - API V2 を使用する場合は、 `storage.enable-ttl = true`も同時に設定する必要があります。API V2 は TTL 機能をサポートしているため、 [`enable-ttl`](#enable-ttl)を明示的に有効にする必要があります。そうしないと、 `storage.enable-ttl`が`false`にデフォルト設定されるため、競合が発生します。 - API V2を有効にする場合、不要になったデータを再利用するために、少なくとも1つのtidb-serverインスタンスをデプロイする必要があります。このtidb-serverインスタンスは、読み取りサービスと書き込みサービスを同時に提供できます。高可用性を確保するため、複数のtidb-serverインスタンスをデプロイすることも可能です。 - API V2ではクライアント側のサポートが必要です。詳細は、API V2に対応したクライアントの取扱説明書を参照してください。 - - バージョン6.2.0以降、RawKVの変更データキャプチャ（CDC）がサポートされています。RawKV [RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc)を参照してください。 + - バージョン6.2.0以降、RawKVの変更データキャプチャ（CDC）がサポートされています。[RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc)を参照してください。 - デフォルト値: `1` > **Warning:** -> - API V1 と API V2 はストレージ形式が異なります。 TiKV に TiDB データのみが含まれている場合に**のみ**、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 [RawKVのバックアップと復元](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)復元を使用してデータを移行する必要があります。 +> - API V1 と API V2 はストレージ形式が異なります。 TiKV に TiDB データのみが含まれている場合に**のみ**、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 [RawKVのバックアップと復元](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)を使用してデータを移行する必要があります。 > - API V2を有効にした後は、TiKVクラスターをv6.1.0より前のバージョンにダウングレードする**ことはできません**。ダウングレードすると、データ破損が発生する可能性があります。 ## `txn-status-cache-capacity` （v7.6.0で追加） {#txn-status-cache-capacity-new-in-v760} @@ -721,7 +721,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `raftdb-path` {#raftdb-path} -- Raftライブラリへのパス（デフォルトでは`storage.data-dir/raft` +- Raftライブラリへのパス（デフォルトでは`storage.data-dir/raft`） - デフォルト値: `""` ### `raft-base-tick-interval` {#raft-base-tick-interval} @@ -740,7 +740,7 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目はSQL文による照会はできませんが、設定ファイル内で設定できます。 -- ハートビートが送信されるまでの経過ティック数。これは、 `raft-base-tick-interval` * `raft-heartbeat-ticks` の時間間隔でハートビートが送信`raft-heartbeat-ticks` 。 +- ハートビートが送信されるまでの経過ティック数。これは、 `raft-base-tick-interval` * `raft-heartbeat-ticks` の時間間隔でハートビートが送信されます。 - デフォルト値: `2` - 最小値: `0`より大きい @@ -791,7 +791,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `raft-entry-max-size` {#raft-entry-max-size} -- 丸太1本の最大サイズに対する厳格な制限 +- 単一ログの最大サイズに対する厳格な制限 - デフォルト値: `"8MiB"` - 最小値: `0` - 単位：MiB｜GiB @@ -810,13 +810,13 @@ Raftstoreに関連するコンフィグレーション項目。 ### `raft-log-gc-threshold` {#raft-log-gc-threshold} -- 残存するRaftの最大許容数に関するソフトリミット +- 残存するRaftログの最大許容数に関するソフトリミット - デフォルト値: `50` - 最小値: `1` ### `raft-log-gc-count-limit` {#raft-log-gc-count-limit} -- 残存するRaftの許容数の上限 +- 残存するRaftログの許容数の上限 - デフォルト値：各ログが1 KiBであると仮定して計算された、リージョンサイズの4分の3に収まるログの数 - 最小値: `0` @@ -834,7 +834,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `raft-engine-purge-interval` {#raft-engine-purge-interval} -- ディスク容量をできるだけ早く再利用するために、古いTiKVログファイルをパージする間隔。RaftRaftは交換可能なコンポーネントであるため、一部の実装ではパージ処理が必要です。 +- ディスク容量をできるだけ早く再利用するために、古いTiKVログファイルをパージする間隔。Raftエンジンは交換可能なコンポーネントであるため、一部の実装ではパージ処理が必要です。 - デフォルト値: `"10s"` ### `raft-entry-cache-life-time` {#raft-entry-cache-life-time} @@ -856,7 +856,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `hibernate-regions` {#hibernate-regions} -- リージョンの休止リージョンを有効または無効にします。このオプションを有効にすると、長時間アイドル状態が続くリージョンは自動的に休止状態になります。これにより、アイドル状態のリージョンについて、 Raftリーダーとフォロワー間のハートビートメッセージによって発生する余分なオーバーヘッドが軽減されます。休止状態のリージョンのリーダーとフォロワー間のハートビート間隔は`peer-stale-state-check-interval`を使用して変更できます。 +- 休止リージョンを有効または無効にします。このオプションを有効にすると、長時間アイドル状態が続くリージョンは自動的に休止状態になります。これにより、アイドル状態のリージョンについて、 Raftリーダーとフォロワー間のハートビートメッセージによって発生する余分なオーバーヘッドが軽減されます。休止状態のリージョンのリーダーとフォロワー間のハートビート間隔は`peer-stale-state-check-interval`を使用して変更できます。 - デフォルト値: v5.0.2 以降のバージョンでは`true` 、v5.0.2 より前のバージョンでは`false` ### `split-region-check-tick-interval` {#split-region-check-tick-interval} @@ -1287,7 +1287,7 @@ Raftstoreに関連するコンフィグレーション項目。 > **Warning:** > > - `enable-region-bucket`は、TiDB v6.1.0 で導入された実験的機能です。本番環境での使用は推奨されません。 -> - この設定は、 `region-split-size` `region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 +> - この設定は、 `region-split-size`が`region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 > - `region-split-size`をより大きな値に調整すると、パフォーマンスの低下やスケジューリングの遅延のリスクが生じる可能性があります。 ### `region-bucket-size` v6.1.0の新機能 {#region-bucket-size-new-in-v610} @@ -1376,7 +1376,7 @@ RocksDBに関連するコンフィグレーション項目 ### `max-total-wal-size` {#max-total-wal-size} -- RocksDB WAL の最大サイズは合計で、 `*.log`内の`data-dir`ファイルのサイズです。 +- RocksDB WAL の最大サイズは合計で、 `data-dir`内の`*.log`ファイルのサイズです。 - デフォルト値: - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 @@ -1503,7 +1503,7 @@ RocksDBに関連するコンフィグレーション項目 - 現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 - デフォルト値: `false` -- お得なオプション： +- 値のオプション： - `false` : データ量が最も大きい`memtable`が SST ファイルに書き込まれます。 - `true` : 最も早い`memtable`が SST ファイルに書き込まれます。この戦略により`memtable`からコールドデータを消去できるため、コールドデータとホットデータが明確に存在するシナリオに適しています。 @@ -1527,7 +1527,7 @@ RocksDBに関連するコンフィグレーション項目 - RocksDB MANIFEST ファイルに先行書き込みログ (WAL) ファイルに関する情報を記録するかどうか、および起動時に WAL ファイルの整合性を検証するかどうかを制御します。詳細については、RocksDB [マニフェストでWALを追跡する](https://github.com/facebook/rocksdb/wiki/Track-WAL-in-MANIFEST)を参照してください。 - デフォルト値: `true` -- お得なオプション： +- 値のオプション： - `true` : WAL ファイルに関する情報を MANIFEST ファイルに記録し、起動時に WAL ファイルの整合性を検証します。 - `false` : WAL ファイルに関する情報を MANIFEST ファイルに記録せず、起動時に WAL ファイルの整合性を検証しません。 @@ -1618,7 +1618,7 @@ Titanに関連するコンフィグレーション項目。 - `defaultcf`のデフォルト値: `true` - `writecf`および`lockcf`のデフォルト値: `false` -### `optimize-filters-for-memory` v7.2.0の新機能） {#optimize-filters-for-memory-new-in-v720} +### `optimize-filters-for-memory` v7.2.0の新機能 {#optimize-filters-for-memory-new-in-v720} - メモリ内部の断片化を最小限に抑えるブルーム/リボンフィルタを生成するかどうかを決定します。 - この設定項目は、 [`format-version`](#format-version-new-in-v620) 5以上の場合にのみ有効になることに注意してください。 @@ -1697,11 +1697,11 @@ 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} -- ベースレベルでのターゲットファイルのサイズ。 `compaction-guard-max-output-file-size`の値が`enable-compaction-guard` } の場合、この値は`true`によって上書きされます。 +- ベースレベルでのターゲットファイルのサイズ。 この値は、 `enable-compaction-guard`の値が`true`の場合、 `compaction-guard-max-output-file-size`によって上書きされます。 - デフォルト値: None。これは、デフォルトでは`"8MiB"`を意味します。 - 最小値: `0` - 単位：KiB｜MiB｜GiB @@ -1715,7 +1715,7 @@ Titanに関連するコンフィグレーション項目。 ### `level0-slowdown-writes-trigger` {#level0-slowdown-writes-trigger} -- L0 レジスタで書き込み停止を引き起こすファイルの最大数。 +- L0 で書き込み停止を引き起こすファイルの最大数。 - v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は[`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって直接上書きされます。 - バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ、 [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 - デフォルト値: `20` @@ -2195,7 +2195,7 @@ Raft Engineに関連するコンフィグレーション項目。 > 3. `enable`を`true`に設定してRaft Engineを有効にし、TiKV を再起動して設定を有効にしてください。 - Raft Engineのログ ファイルのバージョンを指定します。 -- お得なオプション： +- 値のオプション： - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 - デフォルト値: @@ -2750,7 +2750,7 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ 優先度の低いタスクに対するフロー制御戦略を指定します。TiKVは、優先度の低いタスクにフロー制御を適用することで、優先度の高いタスクの実行を優先します。 -- お得なオプション： +- 値のオプション： - `aggressive` : このポリシーは優先度の高いタスクのパフォーマンスを優先し、優先度の高いタスクのスループットとレイテンシーにはほとんど影響を与えないようにしますが、優先度の低いタスクの実行速度は低下します。 - `moderate` : このポリシーは、優先度の低いタスクに対してバランスの取れたフロー制御を課し、優先度の高いタスクへの影響を少なくします。 - `conservative` : このポリシーは、システム リソースが最大限に活用されることを優先し、優先度の低いタスクが必要に応じてシステムで利用可能なリソースを最大限に活用できるようにするため、優先度の高いタスクのパフォーマンスに大きな影響を与えます。 @@ -2867,7 +2867,7 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ TiKV MVCC インメモリエンジン (IME) のストレージレイヤーに関連する構成項目。 -### v8.5.0で`enable` {#enable-new-in-v850} +### `enable` v8.5.0で追加 {#enable-new-in-v850} > **Note:** > diff --git a/tikv-control.md b/tikv-control.md index b652d692719d5..dd08b0228bcf8 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 @@ -89,7 +89,7 @@ tiup ctl:v tikv - リモートモード: `--host`オプションを使用して、TiKVのサービスアドレスを引数として受け入れます - このモードでは、TiKVでSSLが有効になっている場合、関連する証明書ファイルも指定する必要があり`tikv-ctl` 。例： + このモードでは、TiKVでSSLが有効になっている場合、`tikv-ctl`は関連する証明書ファイルも指定する必要があります。例： ```shell tikv-ctl --ca-path ca.pem --cert-path client.pem --key-path client-key.pem --host 127.0.0.1:20160 @@ -139,7 +139,7 @@ AAFF `region`サブコマンドの場合: -- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。7 と`-r` `--all-regions`同時に使用できないことに注意してください。 +- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。`-r`と`--all-regions`は同時に使用できないことに注意してください。 - 印刷するリージョンの数を制限するには、 `--limit`オプションを使用します (デフォルト: `16` )。 - 特定のキー範囲に含まれるリージョンを照会するには、 `--start`および`--end`オプションを使用します (デフォルト: 範囲制限なし、16 進形式)。 @@ -239,7 +239,7 @@ tikv-ctl --data-dir /path/to/tikv mvcc -k "zmDB:29\000\000\377\000\374\000\000\0 `raw-scan`コマンドはRocksDBから直接スキャンします。データキーをスキャンするには、キーの先頭に`'z'`追加する必要があることに注意してください。 -`--from`と`--to`オプションを使用して`write`スキャンする範囲を指定します（デフォルトでは無制限） `--limit`を使用すると、出力するキーの最大数を制限します（デフォルトでは30） `--cf`を使用すると、スキャンする cf を指定します（ `default` 、または`lock` ）。 +`--from`と`--to`オプションを使用して`write`スキャンする範囲を指定します（デフォルトでは無制限） `--limit`を使用すると、出力するキーの最大数を制限します（デフォルトでは30） `--cf`を使用すると、スキャンする cf を指定します（ `default` 、 `write` 、または`lock` ）。 ```shell tikv-ctl --data-dir /var/lib/tikv raw-scan --from 'zt' --limit 2 --cf default @@ -256,7 +256,7 @@ tikv-ctl --data-dir /var/lib/tikv raw-scan --from 'zt' --limit 2 --cf default ### リージョンに関するいくつかのプロパティを印刷する {#print-some-properties-about-region} -リージョンの状態の詳細を記録するために、TiKVはリージョンのSSTファイルにいくつかの統計情報を書き込みます。これらのプロパティを表示するには、サブコマンド`tikv-ctl`とサブコマンド`region-properties`を実行します。 +リージョンの状態の詳細を記録するために、TiKVはリージョンのSSTファイルにいくつかの統計情報を書き込みます。これらのプロパティを表示するには、`region-properties`サブコマンドを指定して`tikv-ctl`を実行します。 ```shell tikv-ctl --host localhost:20160 region-properties -r 2 @@ -348,7 +348,7 @@ tikv-ctl --data-dir /path/to/tikv tombstone -p 127.0.0.1:2379 -r ,consistency-checkリクエストを送信する {#send-a-code-consistency-check-code-request-to-tikv} -`consistency-check`コマンドを使用して、特定のリージョンの対応するRaft内のレプリカ間の整合性チェックを実行します。チェックが失敗した場合、TiKV 自体がパニック状態になります`--host`で指定された TiKV インスタンスがリージョンリーダーでない場合は、エラーが報告されます。 +`consistency-check`コマンドを使用して、特定のリージョンの対応するRaft内のレプリカ間の整合性チェックを実行します。チェックが失敗した場合、TiKV 自体がパニック状態になります。`--host`で指定された TiKV インスタンスがリージョンリーダーでない場合は、エラーが報告されます。 ```shell tikv-ctl --host 127.0.0.1:20160 consistency-check -r 2 @@ -377,7 +377,7 @@ tikv-ctl --data-dir /path/to/tikv bad-regions all regions are healthy -コマンドが正常に実行された場合、上記の情報が出力。コマンドが失敗した場合、不良リージョンのリストが出力。現在検出可能なエラーには、 `last index` `commit index`不一致と、 Raftログの消失が含まれます。スナップショットファイルの破損など、その他`apply index`条件については、さらなるサポートが必要です。 +コマンドが正常に実行された場合、上記の情報が出力されます。コマンドが失敗した場合、不良リージョンのリストが出力されます。現在検出可能なエラーには、 `last index` `commit index`不一致と、 Raftログの消失が含まれます。スナップショットファイルの破損など、その他`apply index`条件については、さらなるサポートが必要です。 ### リージョンのプロパティを表示する {#view-region-properties} diff --git a/tikv-overview.md b/tikv-overview.md index 4b420c9a314bb..250261c76ebe7 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -15,7 +15,7 @@ TiKV は、Google Spanner の設計に基づいて、マルチ raft グループ ### リージョンとRocksDB {#region-and-rocksdb} -各ストアにはRocksDBデータベースがあり、データはローカルディスクに保存されます。リージョンデータはすべて、各ストア内の同じRocksDBインスタンスに保存されます。Raftコンセンサスアルゴリズムに使用されるログはすべて、各ストア内の別のRocksDBインスタンスに保存されます。これは、シーケンシャルI/Oの方がランダムI/ Raftよりもパフォーマンスが優れているためです。Raftログとリージョンデータを異なるRocksDBインスタンスに保存することで、TiKVはRaftログとTiKVリージョンへのすべての書き込み操作を1つのI/O操作に統合し、パフォーマンスを向上させます。 +各ストアにはRocksDBデータベースがあり、データはローカルディスクに保存されます。リージョンデータはすべて、各ストア内の同じRocksDBインスタンスに保存されます。Raftコンセンサスアルゴリズムに使用されるログはすべて、各ストア内の別のRocksDBインスタンスに保存されます。これは、シーケンシャルI/Oの方がランダムI/Oよりもパフォーマンスが優れているためです。Raftログとリージョンデータを異なるRocksDBインスタンスに保存することで、TiKVはRaftログとTiKVリージョンへのすべての書き込み操作を1つのI/O操作に統合し、パフォーマンスを向上させます。 ### リージョンとRaftコンセンサスアルゴリズム {#region-and-raft-consensus-algorithm} diff --git a/time-to-live.md b/time-to-live.md index 6c26b27602087..bda4cf521e528 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -136,7 +136,7 @@ ALTER TABLE orders TTL_JOB_INTERVAL = '24h'; デフォルトでは`TTL_JOB_INTERVAL`は`1h`に設定されています。 -TTLジョブを実行する際、TiDBはテーブルを最大64個のタスクに分割します。リージョンの最小単位はリージョンです。これらのタスクは分散して実行されます。システム変数[`tidb_ttl_running_tasks`](/system-variables.md#tidb_ttl_running_tasks-new-in-v700)を設定することで、クラスター全体で同時実行可能なTTLタスクの数を制限できます。ただし、すべての種類のテーブルのすべてのTTLジョブをタスクに分割できるわけではありません。どの種類のテーブルのTTLジョブをタスクに分割できないかの詳細については、セクション[制限事項](#limitations)を参照してください。 +TTLジョブを実行する際、TiDBはテーブルを最大64個のタスクに分割します。リージョンを最小単位とします。これらのタスクは分散して実行されます。システム変数[`tidb_ttl_running_tasks`](/system-variables.md#tidb_ttl_running_tasks-new-in-v700)を設定することで、クラスター全体で同時実行可能なTTLタスクの数を制限できます。ただし、すべての種類のテーブルのすべてのTTLジョブをタスクに分割できるわけではありません。どの種類のテーブルのTTLジョブをタスクに分割できないかの詳細については、セクション[制限事項](#limitations)を参照してください。 TTL ジョブの実行を無効にするには、 `TTL_ENABLE='OFF'`テーブル オプションを設定することに加えて、 [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650)グローバル変数を設定してクラスター全体で TTL ジョブの実行を無効にすることもできます。 diff --git a/tiup/tiup-bench.md b/tiup/tiup-bench.md index 677aa96c4bd4d..f4fda3db7b3ee 100644 --- a/tiup/tiup-bench.md +++ b/tiup/tiup-bench.md @@ -138,7 +138,7 @@ Flags: 2. 統計を収集します。 - OLAPシナリオでは、TiDBオプティマイザーが最適な実行プランを生成できるように、以下のSQL文を実行して事前に統計情報を収集してください。tidb_analyze_column_options **`tidb_analyze_column_options` `ALL`に設定してください。そうしないと、統計情報を収集するとクエリのパフォーマンスが大幅に低下する可能性があります。** + OLAPシナリオでは、TiDBオプティマイザーが最適な実行プランを生成できるように、以下のSQL文を実行して事前に統計情報を収集してください。**`tidb_analyze_column_options` `ALL`に設定してください。そうしないと、統計情報を収集するとクエリのパフォーマンスが大幅に低下する可能性があります。** ```sql set global tidb_analyze_column_options='ALL'; diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index 074f0463a787e..60969f3ecee1b 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -118,7 +118,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ 2. トポロジ ファイルを編集します。 - 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`行目を追加する必要があります。7パラメータ`systemd_mode` 、 `systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 + 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`の行を追加する必要があります。`systemd_mode`パラメータは、`systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 さらに、no-sudoモードでは、非rootユーザー`tidb`は`/data`ディレクトリを`deploy_dir`または`data_dir`として使用する権限がないため、非rootユーザーがアクセスできるパスを選択する必要があります。以下の例では相対パスを使用しており、実際に使用されるパスは`/home/tidb/data/tidb-deploy`と`/home/tidb/data/tidb-data`です。トポロジファイルの残りの部分は、通常モードと同じです。別の方法として、rootユーザーを使用してディレクトリを作成し、その後`chown`を使用して所有権を`tidb:tidb`に変更することもできます。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index a936fe22d885d..86a9ccdc1c872 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -9,7 +9,7 @@ TiUPを使用して TiDB をデプロイまたは拡張するには、クラス 同様に、クラスタートポロジを変更するには、トポロジファイルに変更を加える必要があります。違いは、クラスターのデプロイ後は、トポロジファイル内のフィールドの一部しか変更できないことです。このドキュメントでは、トポロジファイルの各セクションと各セクション内の各フィールドについて説明します。 -TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、Grafana、Alertmanager などの監視サーバーTiUPデプロイされます。また、このクラスターをスケールアウトすると、 TiUP は新しいノードを監視スコープに追加します。上記の監視サーバーの設定をカスタマイズするには、 [監視サーバーの構成をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md)の手順に従ってください。 +TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、Grafana、Alertmanager などの監視サーバーもTiUPによってデプロイされます。また、このクラスターをスケールアウトすると、 TiUP は新しいノードを監視スコープに追加します。上記の監視サーバーの設定をカスタマイズするには、 [監視サーバーの構成をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md)の手順に従ってください。 ## ファイル構造 {#file-structure} @@ -36,7 +36,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。4 フィールドに指定されたユーザーが``マシン上に存在しない場合、このユーザーは自動的に作成されます。 +- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。``フィールドに指定されたユーザーがターゲットマシン上に存在しない場合、このユーザーは自動的に作成されます。 - `group` : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は``フィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。 @@ -78,7 +78,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 -- `pd_mode` : PD動作モード。このフィールドは、 [PDマイクロサービス](/pd-microservices.md)マイクロサービスを有効にするかどうかを制御します。サポートされる値は「ms」です。このフィールドを指定すると、PDマイクロサービスが有効になります。 +- `pd_mode` : PD動作モード。このフィールドは、 [PDマイクロサービス](/pd-microservices.md)を有効にするかどうかを制御します。サポートされる値は「ms」です。このフィールドを指定すると、PDマイクロサービスが有効になります。 - `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 @@ -232,7 +232,7 @@ component_versions: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 @@ -286,7 +286,7 @@ pd_servers: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 @@ -338,7 +338,7 @@ tidb_servers: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 @@ -372,7 +372,7 @@ tikv_servers: - `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `tcp_port` : 内部テスト用のTiFlash TCPサービスのポート。デフォルト値は`9000`です。TiUP TiUP以降、この設定項目はv7.1.0以降のクラスターでは有効になりません。 +- `tcp_port` : 内部テスト用のTiFlash TCPサービスのポート。デフォルト値は`9000`です。TiUP v1.12.5以降、この設定項目はv7.1.0以降のクラスターでは有効になりません。 - `flash_service_port` : TiFlashがサービスを提供するポート。TiDBはこのポートを介してTiFlashからデータを読み取ります。デフォルト値は`3930`です。 @@ -400,7 +400,7 @@ tikv_servers: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 デプロイメント後、上記のフィールドではディレクトリを`data_dir`にのみ追加できます。以下のフィールドでは、これらのフィールドを変更することはできません。 @@ -500,7 +500,7 @@ tiproxy_servers: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 @@ -548,7 +548,7 @@ kvcdc_servers: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 - `ticdc_cluster_id` : サービスに対応するTiCDCクラスタIDを指定します。このフィールドが指定されていない場合、サービスはデフォルトのTiCDCクラスタに参加します。このフィールドはTiDB v6.3.0以降のバージョンでのみ有効です。 @@ -641,7 +641,7 @@ scheduling_servers: - `host` : 監視サービスがデプロイされているマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ng_port` : NgMonitoringがリッスンするポートを指定します。TiUP TiUPで導入されたこのフィールドは、 [継続的なプロファイリング](/dashboard/dashboard-profiling.md)と[Top SQL](/dashboard/top-sql.md)をサポートします。デフォルト値は`12020`です。 +- `ng_port` : NgMonitoringがリッスンするポートを指定します。TiUP v1.7.0で導入されたこのフィールドは、 [継続的なプロファイリング](/dashboard/dashboard-profiling.md)と[Top SQL](/dashboard/top-sql.md)をサポートします。デフォルト値は`12020`です。 - `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 @@ -663,13 +663,13 @@ scheduling_servers: - `remote_write` : Prometheus ドキュメント[`<remote_write>`](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 - `remote_read` : Prometheus ドキュメント[`<remote_read>`](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_read)を参照してください。 -- `external_alertmanagers` : `external_alertmanagers`番目のフィールドが設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、 `host`と`web_port`番目のフィールドで構成されます。 +- `external_alertmanagers` : `external_alertmanagers`フィールドが設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、 `host`と`web_port`フィールドで構成されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 - `additional_args` : TiUP v1.15.0で導入されたこのフィールドは、Prometheusの実行に必要な追加パラメータを設定します。このフィールドは配列であり、配列の各要素はPrometheusの実行パラメータです。例えば、Prometheusのホットリロード機能を有効にするには、このフィールドを`--web.enable-lifecycle`に設定します。 @@ -737,7 +737,7 @@ monitoring_servers: - `dashboard_dir` : `dashboard(*.json)`ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、クラスター構成の初期化フェーズ中に、Grafanaのダッシュボードとしてターゲットマシンに転送されます。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 - `config` : このフィールドは、Grafanaにカスタム設定を追加するために使用されます。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`config`フィールドの内容をGrafana設定ファイル`grafana.ini`に追加します。詳細については、 [その他のGrafana設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-other-grafana-configurations)を参照してください。 @@ -790,7 +790,7 @@ grafana_servers: - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 - `listen_host` : Alertmanager にプロキシ経由でアクセスできるように、リスニングアドレスを指定します。 `0.0.0.0`に設定することをお勧めします。詳細については、 [Alertmanager 設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-alertmanager-configurations)を参照してください。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 9b3b75fc7ba9e..f269c995b3b27 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -291,9 +291,9 @@ PD がノード上のデータを他の TiKV ノードにスケジュールす > > このセクションでは、スケールアウトコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 [TiUPを使用して TiDBクラスタをスケールする](/scale-tidb-using-tiup.md)を参照してください。 -スケールアウト操作にはデプロイメントと同様の内部ロジックがあります。TiUPTiUPコンポーネントは、まずノードの SSH 接続を確認し、ターゲット ノードに必要なディレクトリを作成してから、デプロイメント操作を実行し、ノード サービスを開始します。 +スケールアウト操作にはデプロイメントと同様の内部ロジックがあります。TiUPクラスタコンポーネントは、まずノードの SSH 接続を確認し、ターゲット ノードに必要なディレクトリを作成してから、デプロイメント操作を実行し、ノード サービスを開始します。 -PDをスケールアウトすると、ノードがクラスターに`join`つ追加され、PDに関連付けられたサービスの設定が更新されます。他のサービスをスケールアウトすると、サービスが直接起動され、クラスターに追加されます。 +PDをスケールアウトすると、ノードが`join`によってクラスターに追加され、PDに関連付けられたサービスの設定が更新されます。他のサービスをスケールアウトすると、サービスが直接起動され、クラスターに追加されます。 すべてのサービスは、スケールアウト時に正確性の検証を実施します。検証結果から、スケールアウトが成功したかどうかがわかります。 @@ -515,7 +515,7 @@ tiup cluster import --dir=/path/to/tidb-ansible ## 操作ログを表示する {#view-the-operation-log} -操作ログを表示するには、 `audit`コマンドを使用します。3 コマンドの使用方法は`audit`のとおりです。 +操作ログを表示するには、 `audit`コマンドを使用します。`audit`コマンドの使用方法は次のとおりです。 ```bash Usage: @@ -574,7 +574,7 @@ tiup cluster exec test-cluster --command='ls /tmp' ## クラスタコントローラー {#cluster-controllers} -TiUPがリリースされる前は、 `tidb-ctl` `pd-ctl`のツールを使用してクラスターを制御できました。これら`tikv-ctl`ツールをより簡単にダウンロードして使用できるように、 TiUPはそれらをオールインワンコンポーネント`ctl`に統合しています。 +TiUPがリリースされる前は、 `tidb-ctl`、`tikv-ctl`、`pd-ctl`などのツールを使用してクラスターを制御できました。これら`tikv-ctl`ツールをより簡単にダウンロードして使用できるように、 TiUPはそれらをオールインワンコンポーネント`ctl`に統合しています。 ```bash Usage: @@ -601,7 +601,7 @@ tiup ctl:v pd -u http://127.0.0.1:2379 store ## 対象マシンの環境チェック {#environment-checks-for-target-machines} -`check`コマンドを使用すると、ターゲットマシンの環境に対して一連のチェックを実行し、チェック結果を出力できます`check`コマンドを実行すると、よくある不適切な構成やサポートされていない状況を特定できます。コマンドフラグリストは次のとおりです。 +`check`コマンドを使用すると、ターゲットマシンの環境に対して一連のチェックを実行し、チェック結果を出力できます。`check`コマンドを実行すると、よくある不適切な構成やサポートされていない状況を特定できます。コマンドフラグリストは次のとおりです。 ```bash Usage: diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index 2874884bf92e9..c0b4c594731d9 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -5,7 +5,7 @@ summary: TiUPは、環境変数を用いた柔軟でカスタマイズされた # tiup env {#tiup-env} -TiUPは、ユーザーに柔軟でカスタマイズされたインターフェースを提供します。その一部は環境変数を使用して実装されています。1コマンド`tiup env` 、 TiUPがサポートするユーザー定義の環境変数とその値を照会するために使用されます。 +TiUPは、ユーザーに柔軟でカスタマイズされたインターフェースを提供します。その一部は環境変数を使用して実装されています。`tiup env`コマンドは、TiUPがサポートするユーザー定義の環境変数とその値を照会するために使用されます。 ## 構文 {#syntax} diff --git a/tiup/tiup-command-list.md b/tiup/tiup-command-list.md index 12e39f8463e07..2fcefda9985e6 100644 --- a/tiup/tiup-command-list.md +++ b/tiup/tiup-command-list.md @@ -23,13 +23,13 @@ tiup list [component] [flags] - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -### --インストール済み {#installed} +### --installed {#installed} - インストールされているコンポーネントとバージョンのみを表示します。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -### --詳細 {#verbose} +### --verbose {#verbose} - コンポーネント リストにインストールされているコンポーネントのバージョンを表示します。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index 5765a93f63eb5..9758cee5091d5 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -36,13 +36,13 @@ tiup mirror clone [global version] [flags] - データ型: `STRING` - デフォルト: "linux,darwin" -### --プレフィックス {#prefix} +### --prefix {#prefix} -- バージョンのプレフィックスのみを一致させるかどうか。デフォルトでは、 TiUP はTiUPに一致するコンポーネントバージョンをダウンロードします。このオプションを設定すると、プレフィックスが一致するコンポーネントバージョンもダウンロードされます。 +- バージョンのプレフィックスのみを一致させるかどうか。デフォルトでは、 TiUP は厳密に一致するコンポーネントバージョンをダウンロードします。このオプションを設定すると、プレフィックスが一致するコンポーネントバージョンもダウンロードされます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -### - {コンポーネント} {#component} +### --{component} {#component} - クローンするコンポーネントのバージョンリストを指定します。`{component}`にコンポーネント名を入力してください。[`tiup list --all`](/tiup/tiup-command-list.md)を実行すると、使用可能なコンポーネント名が表示されます。 - データ型: 文字列 diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index 08ad8cc61c4bc..21f6993f40778 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -5,7 +5,7 @@ summary: TiUP mirror genkey は、 TiUP用の秘密鍵を生成するための # tiup mirror genkey {#tiup-mirror-genkey} -TiUP [鏡](/tiup/tiup-mirror-reference.md)定義によれば、ユーザーには 3 つの役割があります。 +TiUP [ミラー](/tiup/tiup-mirror-reference.md)の定義によれば、ユーザーには 3 つの役割があります。 - ミラー管理者: `root.json` 、 `index.json` 、 `snapshot.json` 、 `timestamp.json`を変更する権限があります。 - コンポーネント所有者: 対応するコンポーネントを変更する権限を持ちます。 @@ -29,16 +29,16 @@ tiup mirror genkey [flags] - キーの名前を指定します。この名前は、最終的に生成されるファイルの名前も決定します。生成される秘密鍵ファイルのパスは`${TIUP_HOME}/keys/{name}.json`です。 `TIUP_HOME` TiUPのホームディレクトリ（デフォルトでは`$HOME/.tiup`を指します。 `name` `-n/--name`指定される秘密鍵の名前を指します。 - データ型: `STRING` -- デフォルト:「プライベート」 +- デフォルト:「private」 ### -p, --public {#p-public} - オプション`-n/--name`で指定された秘密鍵に対応する公開鍵を表示します。 -- `-p/--public`指定された場合、 TiUP は新しい`-n/--name`鍵を作成しません。3 で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 +- `-p/--public`が指定された場合、 TiUP は新しい秘密鍵を作成しません。`-n/--name`で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -### - 保存 {#save} +### --save {#save} - 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。`hash-prefix`は鍵IDの最初の16ビットです。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-command-mirror-modify.md b/tiup/tiup-command-mirror-modify.md index b95022db84b5b..343354c64f9a6 100644 --- a/tiup/tiup-command-mirror-modify.md +++ b/tiup/tiup-command-mirror-modify.md @@ -26,7 +26,7 @@ tiup mirror modify [:version] [flags] - データ型: `STRING` - コマンドでこのオプションが指定されていない場合、コンポーネント情報の署名にはデフォルトで`"${TIUP_HOME}/keys/private.json"`使用されます。 -### - ヤンク {#yank} +### --yank {#yank} 指定されたコンポーネントまたはバージョンを使用不可としてマークします。 @@ -35,7 +35,7 @@ tiup mirror modify [:version] [flags] - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -### - 隠れる {#hide} +### --hide {#hide} - コンポーネントを非表示にするかどうかを指定します。コンポーネントが非表示の場合、 `tiup list`の結果リストには表示されません。非表示のコンポーネントを表示するには、 `tiup list --all`を使用します。 - データ型: `BOOLEAN` @@ -45,7 +45,7 @@ tiup mirror modify [:version] [flags] > > このオプションはコンポーネントにのみ適用でき、コンポーネントバージョンには適用できません。 -### --スタンドアロン {#standalone} +### --standalone {#standalone} - コンポーネントをスタンドアロンで実行できるかどうかを制御します。このオプションは現在**利用できません**。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-command-mirror-rotate.md b/tiup/tiup-command-mirror-rotate.md index 0256c7ad24ae1..5844cff05965b 100644 --- a/tiup/tiup-command-mirror-rotate.md +++ b/tiup/tiup-command-mirror-rotate.md @@ -9,11 +9,11 @@ summary: TiUPミラーローテートは、 TiUPミラー内のroot.jsonファ - ミラー管理者の署名。公式ミラーの場合、署名は5つあります。初期化されたミラーの場合、デフォルトで署名は3つあります。 - 次のファイルを検証するために使用される公開鍵: - - ルート.json - - インデックス.json - - スナップショット.json - - タイムスタンプ.json -- 有効期限は`root.json` 。公式ミラーの場合、有効期限は作成日`root.json`の 1 年後となります。 + - root.json + - index.json + - snapshot.json + - timestamp.json +- `root.json`の有効期限。公式ミラーの場合、有効期限は作成日`root.json`の 1 年後となります。 TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup/tiup-mirror-reference.md)を参照してください。 @@ -44,7 +44,7 @@ TiUP はコマンド`tiup mirror rotate`を使用して上記のプロセスを tiup mirror rotate [flags] ``` -このコマンドを実行すると、 TiUPはエディタを起動し、ユーザーがファイルの内容を目的の値に変更できるようにします。例えば、フィールド`expires`の値を将来の日付に変更します。次に、フィールドTiUP `version`値を`N`から`N+1`に変更し、ファイルを保存します。ファイルの保存後、 TiUPは一時的なHTTPサーバーを起動し、すべてのミラー管理者がファイルに署名するのを待ちます。 +このコマンドを実行すると、 TiUPはエディタを起動し、ユーザーがファイルの内容を目的の値に変更できるようにします。例えば、フィールド`expires`の値を将来の日付に変更します。次に、TiUPは`version`フィールドの値を`N`から`N+1`に変更し、ファイルを保存します。ファイルの保存後、 TiUPは一時的なHTTPサーバーを起動し、すべてのミラー管理者がファイルに署名するのを待ちます。 ミラー管理者がファイルに署名する方法については、 [`sign`コマンド](/tiup/tiup-command-mirror-sign.md)を参照してください。 diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 01d2662af6c4e..8d18f178ef33f 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -13,7 +13,7 @@ summary: TiUP クラスタは、ハードウェアとソフトウェア環境が デプロイされたマシンのオペレーティングシステムのディストリビューションとバージョンを確認してください。サポートされているバージョンのリストについては、 [OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を参照してください。 -### CPU EPOLLEX限定 {#cpu-epollexclusive} +### CPU EPOLLEXCLUSIVE {#cpu-epollexclusive} 対象マシンのCPUがEPOLLEXCLUSIVEをサポートしているかどうかを確認します。 @@ -72,9 +72,9 @@ THP が有効になっているかどうかを確認するには、次のコマ ### SELinux {#selinux} -SELinuxを無効にするか、permissiveモードに設定する必要があります。現在のステータスを確認するには、 [ゲットエンフォース(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 +SELinuxを無効にするか、permissiveモードに設定する必要があります。現在のステータスを確認するには、 [getenforce(8)](https://linux.die.net/man/8/getenforce)ユーティリティを使用してください。 -SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。7または`enforcing` `permissive` `disabled`への変更は、再起動しないと有効になりません。 +SELinuxが無効になっていない場合は、 `/etc/selinux/config`ファイルを開き、 `SELINUX=`で始まる行を`SELINUX=disabled`に変更します。この変更を行った後、システムを再起動する必要があります。`enforcing`または`permissive`から`disabled`への変更は、再起動しないと有効になりません。 一部のシステム（Ubuntuなど）では、 `/etc/selinux/config`ファイルが存在せず、getenforceユーティリティがインストールされていない場合があります。その場合は、この手順をスキップしてください。 diff --git a/tiup/tiup-component-cluster-clean.md b/tiup/tiup-component-cluster-clean.md index 30b8831004d8f..2092e0a7c6504 100644 --- a/tiup/tiup-component-cluster-clean.md +++ b/tiup/tiup-component-cluster-clean.md @@ -23,7 +23,7 @@ tiup cluster clean [flags] ### --all {#all} -- データとログを同時に消去します。1と`--data` `--log`同時に指定するのと同じです。 +- データとログを同時に消去します。`--data`と`--log`を同時に指定するのと同じです。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 - 指定されていない場合は、少なくとも次のいずれかのオプションを指定する必要があります。 diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index a0c4932dfefd7..e2d62574f54d2 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -31,7 +31,7 @@ tiup cluster deploy [flags] - データ型: `STRING` - コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 -### -p, --パスワード {#p-password} +### -p, --password {#p-password} - ターゲットマシンへの接続に使用するパスワードを指定します。このオプションは`-i/--identity_file`と同時に使用しないでください。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 35434ca2991a8..fff3d76f1f842 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -19,7 +19,7 @@ tiup cluster display [flags] ### --dashboard {#dashboard} -- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。1オプションを指定すると、 `--dashboard`ボード情報のみが表示されます。 +- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。`--dashboard`オプションを指定すると、ダッシュボード情報のみが表示されます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-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-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index b81d1e3a506c0..4dcd9bacac98e 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -31,7 +31,7 @@ tiup cluster patch [flags] - `${component}` : 置換するコンポーネントの名前 ( `tidb` 、 `tikv` 、 `pd`など)。 - `${version}` :コンポーネントのバージョン ( `v8.5.3`や`v7.5.4`など)。 - `${os}` :オペレーティングシステム（ `linux` ）。 - - `${arch}` :コンポーネント`arm64`実行されるプラットフォーム( `amd64` )。 + - `${arch}` :コンポーネントが実行されるプラットフォーム ( `amd64` 、 `arm64` )。 2. 次のコマンドを使用して、現在のコンポーネントパッケージをダウンロードします。 diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 5e346f2a1afd6..30c43b093c74c 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -17,13 +17,13 @@ tiup cluster reload [flags] ## オプション {#options} -### --force {#force} +### --force {#--force} - 再ロード プロセス中のエラーを無視し、強制的に再ロードします。 - データ型: `BOOLEAN` - デフォルト: false -### --transfer-timeout {#transfer-timeout} +### --transfer-timeout {#--transfer-timeout} - PDまたはTiKVを再起動する際、再起動されたノードのリーダーノードが最初に他のノードに移行されるため、移行プロセスには時間がかかります。最大待機時間（秒単位）を`-transfer-timeout`に設定できます。タイムアウト後、サービスは待機せずに直接再起動できます。 - データ型: `UINT` @@ -33,13 +33,13 @@ tiup cluster reload [flags] > > 待機をスキップして直接再起動する場合、サービスのパフォーマンスが不安定になる可能性があります。 -### --ignore-config-check {#ignore-config-check} +### --ignore-config-check {#--ignore-config-check} - コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 - データ型: `BOOLEAN` - デフォルト: false -### -N, --node {#n-node} +### -N, --node {#-n---node} - 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 - データ型: `STRINGS` @@ -50,7 +50,7 @@ tiup cluster reload [flags] > - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 > - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 -### -R, --role {#r-role} +### -R, --role {#-r---role} - 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ロールは、表[クラスターステータス](/tiup/tiup-component-cluster-display.md)の2番目の列です。 - データ型: `STRINGS` @@ -61,7 +61,7 @@ tiup cluster reload [flags] > 1. `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 > 2. オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 -### --skip-restart {#skip-restart} +### --skip-restart {#--skip-restart} `tiup cluster reload`コマンドは 2 つの操作を実行します。 @@ -73,13 +73,13 @@ tiup cluster reload [flags] - データ型: `BOOLEAN` - デフォルト: false -### -h, --help {#h-help} +### -h, --help {#-h---help} - ヘルプ情報を出力します。 - データ型: `BOOLEAN` - デフォルト: false -### --pre-restart-script {#pre-restart-script} +### --pre-restart-script {#--pre-restart-script} > **Warning:** > @@ -89,7 +89,7 @@ tiup cluster reload [flags] - データ型: `STRINGS` - このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。`--skip-restart`を`true`に設定した場合は無効になります。 -### --post-restart-script {#post-restart-script} +### --post-restart-script {#--post-restart-script} > **Warning:** > diff --git a/tiup/tiup-component-cluster-replay.md b/tiup/tiup-component-cluster-replay.md index 464699eb76c68..a22ed66ed0a97 100644 --- a/tiup/tiup-component-cluster-replay.md +++ b/tiup/tiup-component-cluster-replay.md @@ -13,7 +13,7 @@ summary: tiup cluster replay` コマンドを使用すると、失敗したク tiup cluster replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。6 [`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`番目を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index 6907175870b98..4e4580962b4ca 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -18,7 +18,7 @@ tiup cluster upgrade [flags] ## オプション {#options} -### --force {#force} +### --force {#--force} - クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`を使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 - データ型: `BOOLEAN` @@ -28,7 +28,7 @@ tiup cluster upgrade [flags] > > サービスを提供しているクラスターを強制的にアップグレードすると、サービスが利用できなくなる可能性があります。アップグレードが成功すると、起動していないクラスターは自動的に起動されます。 -### --transfer-timeout {#transfer-timeout} +### --transfer-timeout {#--transfer-timeout} - PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。`-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 - データ型: `uint` @@ -38,98 +38,98 @@ tiup cluster upgrade [flags] > > 待機をスキップしてサービスを直接アップグレードすると、サービスのパフォーマンスが不安定になる可能性があります。 -### --ignore-config-check {#ignore-config-check} +### --ignore-config-check {#--ignore-config-check} - バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``は、新しくデプロイされたバイナリへのパスであり、 ``は、ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 - データ型: `BOOLEAN` - デフォルト: false -### --ignore-version-check {#ignore-version-check} +### --ignore-version-check {#--ignore-version-check} - アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`を使用します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### --offline {#offline} +### --offline {#--offline} - 現在のクラスターが実行中でないことを宣言します。このオプションが指定されると、 TiUP はサービスリーダーを別のノードに移動させたり、サービスを再起動したりせず、クラスターコンポーネントのバイナリファイルのみを置き換えます。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### --pdバージョン {#pd-version} +### --pdバージョン {#--pd-version} - PDのバージョンを指定します。このオプションを設定すると、PDのバージョンとクラスターのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、PD のバージョンはクラスターのバージョンと一致し続けます。 -### --tikv バージョン {#tikv-version} +### --tikv バージョン {#--tikv-version} - TiKVのバージョンを指定します。このオプションを設定すると、TiKVのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiKV のバージョンはクラスターのバージョンと一致し続けます。 -### --tikv-cdc-バージョン {#tikv-cdc-version} +### --tikv-cdc-バージョン {#--tikv-cdc-version} - TiKV CDCのバージョンを指定します。このオプションを設定すると、TiKV CDCのバージョンはクラスタのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiKV CDC のバージョンはクラスターのバージョンと一致し続けます。 -### --tiflash-version {#tiflash-version} +### --tiflash-version {#--tiflash-version} - TiFlashのバージョンを指定します。このオプションを設定すると、 TiFlashのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、 TiFlashのバージョンはクラスターのバージョンと一致したままになります。 -### --cdc バージョン {#cdc-version} +### --cdc バージョン {#--cdc-version} - TiCDCのバージョンを指定します。このオプションを設定すると、TiCDCのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiCDC のバージョンはクラスターのバージョンと一致し続けます。 -### --tiproxy バージョン {#tiproxy-version} +### --tiproxy バージョン {#--tiproxy-version} - TiProxyのバージョンを指定します。このオプションを設定すると、TiProxyのバージョンはクラスタのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiProxy のバージョンはクラスターのバージョンと一致したままになります。 -### --tidb-ダッシュボードバージョン {#tidb-dashboard-version} +### --tidb-ダッシュボードバージョン {#--tidb-dashboard-version} - TiDB Dashboardのバージョンを指定します。このオプションを設定すると、TiDB Dashboardのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiDB Dashboardのバージョンはクラスターのバージョンと一致したままになります。 -### --alertmanager-バージョン {#alertmanager-version} +### --alertmanager-バージョン {#--alertmanager-version} - Alertmanagerのバージョンを指定します。このオプションを設定すると、Alertmanagerのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、アラート マネージャーのバージョンはクラスターのバージョンと一致したままになります。 -### --blackbox-exporter-version {#blackbox-exporter-version} +### --blackbox-exporter-version {#--blackbox-exporter-version} - Blackbox Exporterのバージョンを指定します。このオプションを設定すると、Blackbox Exporterのバージョンとクラスタのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、Blackbox Exporter のバージョンはクラスターのバージョンと一致したままになります。 -### --node-exporter-version {#node-exporter-version} +### --node-exporter-version {#--node-exporter-version} - Node Exporterのバージョンを指定します。このオプションを設定すると、Node Exporterのバージョンとクラスターのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、Node Exporter のバージョンはクラスターのバージョンと一致したままになります。 -### --再起動タイムアウト {#restart-timeout} +### --再起動タイムアウト {#--restart-timeout} - ローリング アップグレード中にコンポーネントをアップグレードした後の待機時間を指定します。 - データ型: `STRINGS` [`golang time.ParseDuration`](https://pkg.go.dev/time#ParseDuration)で解析できるすべての型がサポートされます。 - デフォルト: `0` - このオプションを指定しないと、コンポーネントのアップグレード後に待機時間は発生しません。 -### -h, --help {#h-help} +### -h, --help {#-h---help} - ヘルプ情報を出力します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -### ---アップグレード前スクリプト {#pre-upgrade-script} +### ---アップグレード前スクリプト {#---pre-upgrade-script} > **Warning:** > @@ -139,7 +139,7 @@ tiup cluster upgrade [flags] - データ型: `STRINGS` - このオプションは、アップグレードするノードで実行されるスクリプトのパスを指定します。 -### ---アップグレード後のスクリプト {#post-upgrade-script} +### ---アップグレード後のスクリプト {#---post-upgrade-script} > **Warning:** > diff --git a/tiup/tiup-component-dm-disable.md b/tiup/tiup-component-dm-disable.md index ae279d74910d2..9c6073ed60eae 100644 --- a/tiup/tiup-component-dm-disable.md +++ b/tiup/tiup-component-dm-disable.md @@ -3,7 +3,7 @@ title: tiup dm disable summary: tiup dm disable`コマンドは、マシンの再起動後にクラスタサービスの自動有効化を無効にするために使用されます。`-N, --node`オプションを使用してノードを指定し、`-R, --role`オプションを使用して自動有効化を無効にするロールを指定できます。出力はtiup-dmコマンドの実行ログです。 --- -# tiup dm 無効 {#tiup-dm-disable} +# tiup dm disable {#tiup-dm-disable} クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup dm disable`を使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index 7395639559c89..28f008d92f347 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -3,9 +3,9 @@ title: tiup dm edit-config summary: tiup dm edit-config`コマンドを使用すると、デプロイメント後にクラスタサービスの設定を変更できます。エディタを使用して、指定したクラスタのトポロジファイルを変更できます。設定変更時にマシンの追加や削除はできないことに注意してください。コマンド実行後、設定はコントロールマシン上でのみ変更されるため、`tiup dm reloadコマンドを実行して設定を再読み込みする必要があります。 --- -# tiup dm 編集設定 {#tiup-dm-edit-config} +# tiup dm edit-config {#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-enable.md b/tiup/tiup-component-dm-enable.md index 0114f9764c69d..6e1be2dfed43b 100644 --- a/tiup/tiup-component-dm-enable.md +++ b/tiup/tiup-component-dm-enable.md @@ -3,7 +3,7 @@ title: tiup dm enable summary: tiup dm enable`コマンドは、マシンの再起動後にクラスタサービスの自動有効化を有効にするために使用されます。このコマンドは、指定されたノードで`systemctl enable `を実行します。オプションには、自動有効化するノードまたはロールの指定が含まれます。出力はtiup-dmの実行ログです。 --- -# tiup dm 有効 {#tiup-dm-enable} +# tiup dm enable {#tiup-dm-enable} `tiup dm enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `を実行することで、サービスの自動有効化を有効にします。 diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index ad9eb00c05219..48fef311c9d5a 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -11,7 +11,7 @@ summary: TiUP DMの「import」コマンドは、DMクラスタをv1.0からv2.0 -DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプロイされます。TiUP TiUP DMは、 v1.0クラスターをインポートし、DM v2.0に再デプロイするためのコマンド`import`を提供します。 +DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプロイされます。TiUP DMは、 v1.0クラスターをインポートし、DM v2.0に再デプロイするためのコマンド`import`を提供します。 > **Note:** > 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-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index 2bdd1a3e8296a..f10c023fee0d1 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -145,7 +145,7 @@ tiup dm patch [flags] 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 Total nodes: 5 - 指定されたノードまたは指定されたロールにホットフィックスを適用します。1と`-N` `-R`が指定されている場合は、共通部分が採用されます。 + 指定されたノードまたは指定されたロールにホットフィックスを適用します。`-N`と`-R`の両方が指定されている場合は、共通部分が採用されます。 # Apply hotfix to a specified node. tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8261 diff --git a/tiup/tiup-component-dm-replay.md b/tiup/tiup-component-dm-replay.md index fb75a637c3c2a..e805b5e1004f4 100644 --- a/tiup/tiup-component-dm-replay.md +++ b/tiup/tiup-component-dm-replay.md @@ -13,7 +13,7 @@ summary: tiup dm replay` コマンドを使用すると、失敗したクラス tiup dm replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。6 [`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`番目を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 02d7f1eef58c3..6602c8b81954d 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -83,7 +83,7 @@ server_configs: ## `master_servers` {#master-servers} -`master_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます`master_servers`配列です。各配列要素には以下のフィールドが含まれます。 +`master_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます。`master_servers`は配列です。各配列要素には以下のフィールドが含まれます。 - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`使用されます。 @@ -140,7 +140,7 @@ master_servers: ## `worker_servers` {#worker-servers} -`worker_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます`worker_servers`配列です。各配列要素には以下のフィールドが含まれます。 +`worker_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます。`worker_servers`は配列です。各配列要素には以下のフィールドが含まれます。 - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`使用されます。 @@ -184,7 +184,7 @@ worker_servers: ### `monitoring_servers` {#monitoring-servers} -`monitoring_servers` 、Prometheus サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます`monitoring_servers`配列です。各配列要素には以下のフィールドが含まれます。 +`monitoring_servers` 、Prometheus サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます。`monitoring_servers`は配列です。各配列要素には以下のフィールドが含まれます。 - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`使用されます。 @@ -242,7 +242,7 @@ monitoring_servers: ### `grafana_servers` {#grafana-servers} -`grafana_servers` 、Grafana サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます`grafana_servers`配列です。各配列要素には以下のフィールドが含まれます。 +`grafana_servers` 、Grafana サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます。`grafana_servers`は配列です。各配列要素には以下のフィールドが含まれます。 - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`使用されます。 @@ -280,7 +280,7 @@ grafana_servers: ### `alertmanager_servers` {#alertmanager-servers} -`alertmanager_servers` 、Alertmanagerサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます`alertmanager_servers`は配列です。各配列要素には以下のフィールドが含まれます。 +`alertmanager_servers` 、Alertmanagerサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます。`alertmanager_servers`は配列です。各配列要素には以下のフィールドが含まれます。 - `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`使用されます。 diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 9469a71219a83..379f8c7a0bd34 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -5,7 +5,7 @@ summary: TiUPミラーの一般情報を学びます。 # TiUPミラーリファレンスガイド {#tiup-mirror-reference-guide} -TiUPミラーは、コンポーネントとそのメタデータを保存するTiUPのコンポーネントウェアハウスです。TiUPTiUPには、次の2つの形式があります。 +TiUPミラーは、コンポーネントとそのメタデータを保存するTiUPのコンポーネントウェアハウスです。TiUPミラーには、次の2つの形式があります。 - ローカル ディスク上のディレクトリ: このドキュメントではローカル ミラーと呼ばれるローカルTiUPクライアントを提供します。 - リモート ディスク ディレクトリに基づいて開始された HTTP ミラー: このドキュメントではリモート ミラーと呼ばれるリモートTiUPクライアントにサービスを提供します。 diff --git a/tiup/tiup-mirror.md b/tiup/tiup-mirror.md index 164398a7fb40b..af59dafe6426b 100644 --- a/tiup/tiup-mirror.md +++ b/tiup/tiup-mirror.md @@ -90,7 +90,7 @@ tiup mirror clone [global-version] [flags] ### プライベートリポジトリを管理する {#manage-the-private-repository} -1でクローンしたリポジトリは、SCP、NFS経由でファイルを共有するか、HTTPまたはHTTPSプロトコル経由でリポジトリを公開することで、 `tiup mirror clone`のホスト間で共有できます`tiup mirror set `でリポジトリの場所を指定します。 +`tiup mirror clone`でクローンしたリポジトリは、SCP、NFS経由でファイルを共有するか、HTTPまたはHTTPSプロトコル経由でリポジトリを公開することで、 `tiup mirror clone`のホスト間で共有できます。`tiup mirror set `でリポジトリの場所を指定します。 ```bash tiup mirror set /shared_data/tiup diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 62ec5eab2ec15..9e92377ecb951 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/tiup/tiup-playground.md b/tiup/tiup-playground.md index 280aa6c72cbf1..8903b8059309f 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -7,7 +7,7 @@ summary: TiUPのPlaygroundコンポーネントを使用して、ローカルTiD TiDBクラスタは、複数のコンポーネントで構成される分散システムです。一般的なTiDBクラスタは、少なくとも3つのPDノード、3つのTiKVノード、および2つのTiDBノードで構成されます。TiDBをすぐに試してみたい場合、これほど多くのコンポーネントを手動でデプロイするのは時間と手間がかかるかもしれません。このドキュメントでは、 TiUPのPlaygroundコンポーネントと、それを使用してローカルのTiDBテスト環境を迅速に構築する方法について説明します。 -## TiUP遊具施設の概要 {#tiup-playground-overview} +## TiUP Playgroundの概要 {#tiup-playground-overview} Playgroundコンポーネントの基本的な使用方法を以下に示します。 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index a2c9c3d612983..225dd4b44bc97 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -21,7 +21,7 @@ tiup [flags] [args...] # Runs a component ## オプション {#options} -### - バイナリ {#binary} +### --binary {#binary} - このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 @@ -45,16 +45,16 @@ tiup [flags] [args...] # Runs a component - 実行するコンポーネントのパスを指定します。コンポーネントの実行時にTiUPミラー内のバイナリファイルを使用しない場合は、このオプションを追加することで、カスタムパス内のバイナリファイルを使用するように指定できます。 - データ型: `STRING` -### -T, --タグ {#t-tag} +### -T, --tag {#t-tag} - 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクストレージを使用する必要があり、 TiUP はこの実行のために一時的なストレージディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`を指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 - データ型: `STRING` -### -v, --バージョン {#v-version} +### -v, --version {#v-version} TiUPバージョンを出力します。 -### - ヘルプ {#help} +### --help {#help} ヘルプ情報を出力します。 @@ -68,7 +68,7 @@ TiUPには複数のコマンドがあり、これらのコマンドには複数 - [アップデート](/tiup/tiup-command-update.md) : インストールされているコンポーネントを更新します。 - [状態](/tiup/tiup-command-status.md) :コンポーネントの実行ステータスを表示します。 - [クリーン](/tiup/tiup-command-clean.md) :コンポーネントのデータディレクトリをクリーンアップします。 -- [鏡](/tiup/tiup-command-mirror.md) : ミラーを管理します。 +- [mirror](/tiup/tiup-command-mirror.md) : ミラーを管理します。 - [テレメトリー](/tiup/tiup-command-telemetry.md) : テレメトリを有効または無効にします。 - [完了](/tiup/tiup-command-completion.md) : TiUPコマンドを完了します。 - [環境](/tiup/tiup-command-env.md) : TiUP関連の環境変数を表示します。 diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 5190896684e30..04d0083be42bc 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -80,7 +80,7 @@ v6.0.0以降、TiDBは、読み取り/書き込み競合が稀なシナリオに 分離レベル`READ-COMMITTED`が使用され、ステートメントが`SELECT`多く、読み取り/書き込みの競合がまれなシナリオでは、この変数を有効にすると、グローバル タイムスタンプを取得する際のレイテンシーとコストを回避できます。 -v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。3 [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)有効になっている場合も、TiDBは同様にデータを読み取ります。 +v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオにおいて、システム変数[`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630)有効にすることでタイムスタンプ取得の最適化をサポートします。この変数を有効にすると、ポイント書き込みステートメントの実行中に、TiDBは現在のトランザクションの有効なタイムスタンプを使用してデータの読み取りとロックを試みます。[`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)が有効になっている場合も、TiDBは同様にデータを読み取ります。 現在、適用可能なポイント書き込みステートメントの種類は`UPDATE` 、 `DELETE` 、 `SELECT ...... FOR UPDATE`です。ポイント書き込みステートメントとは、主キーまたは一意キーをフィルター条件として使用し、最終実行演算子に`POINT-GET`含まれる書き込みステートメントを指します。現在、3種類のポイント書き込みステートメントに共通するのは、まずキー値に基づいてポイントクエリを実行することです。キーが存在する場合は、キーをロックします。キーが存在しない場合は、空のセットを返します。 diff --git a/transaction-overview.md b/transaction-overview.md index acac6e3e70918..415d0bfacc957 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -272,7 +272,7 @@ mysql> SELECT * FROM test; TiDBは楽観的トランザクションと悲観的トランザクションの両方をサポートしており、楽観的トランザクションは悲観的トランザクションの基盤となります。楽観的トランザクションはまず変更をプライベートメモリにキャッシュするため、TiDBは単一トランザクションのサイズを制限します。 -デフォルトでは、TiDB は単一トランザクションの合計サイズを 100 MB 以下に設定します。このデフォルト値は、設定ファイルで`txn-total-size-limit`設定することで変更できます。最大値は`txn-total-size-limit`で、1 TB です。個々のトランザクションのサイズ制限は、サーバーで使用可能なメモリの残り容量にも依存します。これは、トランザクションの実行時に、TiDB プロセスのメモリ使用量がトランザクションサイズと比較して、最大でトランザクションサイズの 2 ～ 3 倍以上にまで増加するためです。 +デフォルトでは、TiDB は単一トランザクションの合計サイズを 100 MB 以下に設定します。このデフォルト値は、設定ファイルで`txn-total-size-limit`を設定することで変更できます。 `txn-total-size-limit`の最大値は 1 TB です。個々のトランザクションのサイズ制限は、サーバーで使用可能なメモリの残り容量にも依存します。これは、トランザクションの実行時に、TiDB プロセスのメモリ使用量がトランザクションサイズと比較して、最大でトランザクションサイズの 2 ～ 3 倍以上にまで増加するためです。 TiDBでは以前、1トランザクションあたりのキーと値のペアの総数が300,000個に制限されていました。この制限はTiDB v4.0で削除されました。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index f13d524f17391..181fd66e8898d 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -33,7 +33,7 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる - `set global tidb_auto_analyze_end_time='06:00 +0800';` - 実行プランをバインドする - アプリケーションの SQL ステートメントを変更し、 `use index`を実行して、列のインデックスを一貫して使用します。 - - 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありません`create global binding`を使用して、 `force index`のバインディングSQL文を作成します。 + - 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありません。`create global binding`を使用して、 `force index`のバインディングSQL文を作成します。 - 4.0 バージョンでは[SQLプラン管理](/sql-plan-management.md)サポートされており、不安定な実行プランによるパフォーマンスの低下を回避します。 ### PD異常 {#pd-anomalies} @@ -44,17 +44,17 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ #### 考えられる理由 {#possible-reasons} -- ディスクの問題です。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされていないか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（**ディスクパフォーマンス**、**レイテンシー**/**負荷**）を確認することで原因を確認できます。必要に応じて、FIOツールを使用してディスクのチェック**を**実行することもできます。 +- ディスクの問題です。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされていないか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（**ディスクパフォーマンス**、**レイテンシー**/**負荷**）を確認することで原因を確認できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。 - PDピア間のネットワークに問題が発生しています。PDログには`lost the TCP streaming connection`が表示されています。Grafana -> **PD** -> **etcd**モニターの`round trip`を確認して、PDノード間のネットワークに問題が発生し**て**いないか確認し、原因を検証する必要があります。 - サーバーの負荷が高いです。ログには`server is likely overloaded`表示されています。 -- PD がLeaderを選出できません: PD ログには`lease is not expired`表示されます。3 [この号](https://github.com/etcd-io/etcd/issues/10355) v3.0.x および v2.1.19 で修正されました。 +- PD がLeaderを選出できません: PD ログには`lease is not expired`が表示されます。[この号](https://github.com/etcd-io/etcd/issues/10355)は v3.0.x および v2.1.19 で修正されました。 - リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 -- TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー****モニター**にアクセスして、TiDBからPD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 +- TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、TiDBからPD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 - PDは`FATAL`エラーを報告しますが、ログには`range failed to find revision pair`表示されます。この問題はv3.0.8（ [＃2040](https://github.com/pingcap/pd/pull/2040) ）で修正されました。 @@ -62,7 +62,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - ローリングアップグレード中にPD OOMが発生しました。gRPCメッセージのサイズに制限がなく、モニターでは`TCP InSegs`が比較的大きいと表示されます。この問題はv3.0.6（ [＃1952](https://github.com/pingcap/pd/pull/1952) ）で修正されました。 -- PDはパニックになる[バグを報告する](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md) 。 +- PDがパニックになります。[バグを報告する](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md) 。 - その他の原因。`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行してgoroutineを取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 @@ -128,7 +128,7 @@ CPU リソースの使用量がボトルネックになります。 一般的なケースでは、まずデフォルト値（ `4`と`256` ）をそのままにして、クラスターのリソース使用量と応答速度を観察し、その後、同時実行性を高めるために値を`tidb_ddl_reorg_worker_cnt`に増やします。モニターで明らかなジッターが見られない場合は、値を`tidb_ddl_reorg_batch_size`に増やします。インデックス作成に関係する列が頻繁に更新される場合、結果として生じる多くの競合により、インデックス作成が失敗し、再試行されることになります。 -さらに、インデックス作成を優先して処理を高速化するために、値を`tidb_ddl_reorg_priority` ～ `PRIORITY_HIGH`設定することもできます。ただし、一般的なOLTPシステムでは、デフォルト値のままにしておくことをお勧めします。 +さらに、インデックス作成を優先して処理を高速化するために、`tidb_ddl_reorg_priority`の値を`PRIORITY_HIGH`に設定することもできます。ただし、一般的なOLTPシステムでは、デフォルト値のままにしておくことをお勧めします。 ### 高いGC圧力 {#high-gc-pressure} diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index 4bf9304007e3e..c0a8be8642f31 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -55,7 +55,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ - `apply log`は遅いです。TiKV Grafana の`Raft I/O`と`apply log duration`指標は比較的高く、これは通常、 `Raft Propose` / `apply wait duration`指標も比較的高い場合に発生します。考えられる原因は次のとおりです。 - - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`から大きすぎない範囲に設定することをお勧めします。7と`Thread CPU` `apply cpu`比較的高い値です。 + - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`の範囲で、大きすぎないように設定することをお勧めします。`Thread CPU`/`apply cpu`の値も比較的高くなっています。 - マシンの CPU リソースが不足しています。 - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`追加することで確認できます）。 - RocksDBへの書き込み速度が遅く、 `RocksDB kv` / `max write duration`高い値です。1つのRaftログには複数のキーと値のペア（kv）が含まれる場合があります。128 kvが一括でRocksDBに書き込まれるため、 `apply`ログ1つにつきRocksDBへの書き込みが複数回発生する可能性があります。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 03192a5330812..1ce9604c42287 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -57,7 +57,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ パフォーマンスの問題は必ずしもホットスポットが原因であるとは限らず、複数の要因が絡み合っている可能性があります。問題のトラブルシューティングを行う前に、ホットスポットに関連しているかどうかを確認してください。 -- 書き込みホットスポットを判断するには、 **TiKV トラブルシューティング**監視パネルで**Hot Write を**開き、任意の TiKV ノードのRaftstore CPU メトリック値が他のノードの値よりも大幅に高いかどうかを確認します。 +- 書き込みホットスポットを判断するには、 **TiKV トラブルシューティング**監視パネルで**Hot Write**を開き、任意の TiKV ノードのRaftstore CPU メトリック値が他のノードの値よりも大幅に高いかどうかを確認します。 - 読み取りホットスポットを判断するには、 **TiKV 詳細**監視パネルで**Thread_CPU**を開き、いずれかの TiKV ノードのコプロセッサ CPU メトリック値が特に高いかどうかを確認します。 @@ -106,7 +106,7 @@ ALTER TABLE: ALTER TABLE t SHARD_ROW_ID_BITS = 4; ![Dashboard Example 6](/media/troubleshoot-hot-spot-issues-6.png) -上記の負荷図に示すように、設定`SHARD_ROW_ID_BITS`より前では、負荷のホットスポットが単一のリージョンに集中していました。設定`SHARD_ROW_ID_BITS`より後では、負荷のホットスポットが分散するようになります。 +上記の負荷図に示すように、`SHARD_ROW_ID_BITS`を設定する前では、負荷のホットスポットが単一のリージョンに集中していました。`SHARD_ROW_ID_BITS`を設定した後では、負荷のホットスポットが分散するようになります。 ## AUTO_RANDOMを使用してAUTO_INCREMENT主キー ホットスポット テーブルを処理する {#handle-auto-increment-primary-key-hotspot-tables-using-code-auto-random-code} diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index 328a577f65bf6..ff1ce8ec8f90e 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -9,7 +9,7 @@ TiDBは完全な分散トランザクションをサポートしています。v ## ロックビューを使用してロックの問題をトラブルシューティングする {#use-lock-view-to-troubleshoot-lock-issues} -TiDBはバージョン5.1以降、ロックビュー機能をサポートしています。この機能には、ロック競合やロック待機に関する詳細情報を提供する複数のシステムテーブルがバージョン`information_schema`に組み込まれています。 +TiDBはバージョン5.1以降、ロックビュー機能をサポートしています。この機能には、ロック競合やロック待機に関する詳細情報を提供する複数のシステムテーブルが`information_schema`に組み込まれています。 > **Note:** > @@ -227,7 +227,7 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で Grafana の TiDB モニタリングで「KeyIsLocked」エラーがあるかどうかを確認できます。 -TiDBダッシュボードの`KV Errors`パネルには、トランザクションによって発生した書き込み競合を確認するための2つの監視メトリック`Lock Resolve OPS`と`KV Backoff OPS`あります。`Lock Resolve OPS`の`resolve`番目の項目と`KV Backoff OPS`の`txnLock`番目の項目に明らかな上昇傾向が見られる場合、「KeyIsLocked」エラーが発生します。`resolve`はロックを解除しようとする操作を指し、`txnLock`は書き込み競合を表します。 +TiDBダッシュボードの`KV Errors`パネルには、トランザクションによって発生した書き込み競合を確認するための2つの監視メトリック`Lock Resolve OPS`と`KV Backoff OPS`あります。`Lock Resolve OPS`の`resolve`項目と`KV Backoff OPS`の`txnLock`項目に明らかな上昇傾向が見られる場合、「KeyIsLocked」エラーが発生します。`resolve`はロックを解除しようとする操作を指し、`txnLock`は書き込み競合を表します。 ![KV-backoff-txnLockFast-optimistic-01](/media/troubleshooting-lock-pic-07.png) ![KV-Errors-resolve-optimistic-01](/media/troubleshooting-lock-pic-08.png) diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 26ee3805c8546..0830de0281408 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -9,9 +9,9 @@ summary: TiKV のステイル読み取りと safe-ts の原則を紹介し、 ## ステイル読み取りとsafe-tsの概要 {#overview-of-stale-read-and-safe-ts} -[ステイル読み取り](/stale-read.md) 、TiDB が TiDB に保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。TiKV では、 ステイル読み取り は[セーフティーズ](/#what-is-safe-ts)に依存します。リージョンピアへの読み取りリクエストのタイムスタンプ (ts) がそのリージョンの safe-ts 以下であれば、TiDB はピアからデータを安全に読み取ることができます。TiKV は、safe-ts が常に[resolved-ts](#what-is-resolved-ts)以下であることを保証することで、この安全性保証を実装しています。 +[ステイル読み取り](/stale-read.md) 、TiDB が TiDB に保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。TiKV では、 ステイル読み取り は[safe-ts](/#what-is-safe-ts)に依存します。リージョンピアへの読み取りリクエストのタイムスタンプ (ts) がそのリージョンの safe-ts 以下であれば、TiDB はピアからデータを安全に読み取ることができます。TiKV は、safe-ts が常に[resolved-ts](#what-is-resolved-ts)以下であることを保証することで、この安全性保証を実装しています。 -## 安全なtとresolved-tsを理解する {#understand-safe-ts-and-resolved-ts} +## safe-tsとresolved-tsを理解する {#understand-safe-ts-and-resolved-ts} このセクションでは、 safe-ts とresolved-tsの概念とメンテナンスについて説明します。 @@ -21,13 +21,13 @@ safe-ts は、リージョン内の各ピアが保持するタイムスタンプ ### resolved-tsとは何ですか？ {#what-is-resolved-ts} -resolved-ts）は、この値より小さいタイムスタンプを持つすべてのトランザクションがリーダーによって適用済みであることを保証するタイムスタンプです。ピア概念であるセーフトランザクション（safe-ts）とは異なり、resolved-ts ）はリージョンリーダーによってのみ管理されます。フォロワーの適用インデックスはリーダーよりも小さい場合があるため、解決済みトランザクション（resolved-ts）をフォロワー内で直接セーフトランザクション（safe-ts）として扱うことはできません。 +resolved-ts は、この値より小さいタイムスタンプを持つすべてのトランザクションがリーダーによって適用済みであることを保証するタイムスタンプです。ピア概念であるsafe-tsとは異なり、resolved-ts はリージョンリーダーによってのみ管理されます。フォロワーの適用インデックスはリーダーよりも小さい場合があるため、resolved-tsをフォロワー内で直接safe-tsとして扱うことはできません。 -### セーフティーの維持 {#the-maintenance-of-safe-ts} +### safe-tsの維持 {#the-maintenance-of-safe-ts} `RegionReadProgress`モジュールは safe-ts を管理します。リージョンリーダーはresolved-tsを管理し、定期的に、 resolved-ts、このresolved-tsを検証するための最低限必要な適用インデックス、そしてリージョン自体を、CheckLeader RPC を介して全レプリカの`RegionReadProgerss`モジュールに送信します。 -ピアがデータを適用すると、適用インデックスが更新され、保留中のresolved-ts が新しい safe-t になるかどうかがチェックされます。 +ピアがデータを適用すると、適用インデックスが更新され、保留中のresolved-ts が新しい safe-ts になるかどうかがチェックされます。 ### resolved-tsの維持 {#the-maintenance-of-resolved-ts} @@ -105,10 +105,10 @@ Resolver: TiKV は 10 秒ごとに次のメトリックをチェックします。 - resolved-tsが最小であるリージョンリーダー -- 安全度が最小のリージョンフォロワー +- safe-tsが最小のリージョンフォロワー - resolved-tsが最小であるリージョンフォロワー -これらのタイムスタンプのいずれかが異常に小さい場合、TiKV はログを出力。 +これらのタイムスタンプのいずれかが異常に小さい場合、TiKV はログを出力します。 これらのログは、現在は存在しない過去の問題を診断する場合に特に役立ちます。 @@ -214,7 +214,7 @@ Resolver: [2023/07/17 21:16:44.257 +08:00] [INFO] [resolver.rs:213] ["locks with the minimum start_ts in resolver"] [keys="[74800000000000006A5F7280000000000405F6, ... , 74800000000000006A5F72800000000000EFF6, 74800000000000006A5F7280000000000721D9, 74800000000000006A5F72800000000002F691]"] [start_ts=442918429687808001] [region_id=3121] ``` -TiKVログから、トランザクションのstart_ts `442918429687808001` ）を取得できます。ステートメントとトランザクションに関する詳細情報を取得するには、TiDBログでこのタイムスタンプをgrepしてください。出力は以下のとおりです。 +TiKVログから、トランザクションのstart_ts（`442918429687808001`）を取得できます。ステートメントとトランザクションに関する詳細情報を取得するには、TiDBログでこのタイムスタンプをgrepしてください。出力は以下のとおりです。 ```log [2023/07/17 21:16:18.287 +08:00] [INFO] [2pc.go:685] ["[BIG_TXN]"] [session=2826881778407440457] ["key sample"=74800000000000006a5f728000000000000000] [size=319967171] [keys=10000000] [puts=10000000] [dels=0] [locks=0] [checks=0] [txnStartTS=442918429687808001] diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index 27f2aa14aaea9..9374d198aed68 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -9,7 +9,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - 正確なエラーメッセージとエラー発生時の操作 - すべてのコンポーネントの状態 -- エラー`panic`報告するコンポーネントのログの`error` `fatal`情報 +- エラーを報告するコンポーネントのログ内の`error` / `fatal` / `panic`情報 - 構成と展開トポロジ - `dmesg`のTiDBコンポーネント関連の問題 @@ -17,7 +17,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 ## データベースに接続できません {#cannot-connect-to-the-database} -1. `tidb-server` `pd-server`含むすべてのサービスが開始されていることを確認します`tikv-server` +1. `tidb-server` 、 `pd-server` 、 `tikv-server`を含むすべてのサービスが開始されていることを確認します 2. `ps`コマンドを使用して、すべてのプロセスが実行中かどうかを確認します。 @@ -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/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 885864dc74c6d..60af94a0f28bd 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -14,9 +14,9 @@ summary: TiDB OOM (メモリ不足) の問題を診断して解決する方法 - クライアント側で次のエラーが報告されます: `SQL error, errno = 2013, state = 'HY000': Lost connection to MySQL server during query` 。 - Grafana ダッシュボードには次の内容が表示されます。 - - **TiDB** >**サーバー**>**メモリ使用量で**は、 `process/heapInUse`メトリックが上昇し続け、しきい値に達した後、突然 0 に低下することが示されています。 - - **TiDB** >**サーバー**>**稼働時間が**突然ゼロに低下します。 - - **TiDB-Runtime** >**メモリ使用量で**は、 `estimate-inuse`メトリックが上昇し続けていることがわかります。 + - **TiDB** >**サーバー**>**メモリ使用量**では、 `process/heapInUse`メトリックが上昇し続け、しきい値に達した後、突然 0 に低下することが示されています。 + - **TiDB** >**サーバー**>**稼働時間**が突然ゼロに低下します。 + - **TiDB-Runtime** >**メモリ使用量**では、 `estimate-inuse`メトリックが上昇し続けていることがわかります。 - `tidb.log`を確認すると、次のログ エントリが見つかります。 - OOMに関するアラーム: `[WARN] [memory_usage_alarm.go:139] ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"]` 。詳細については、 [`memory-usage-alarm-ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)を参照してください。 @@ -121,7 +121,7 @@ TiDBノードは起動後、統計情報をメモリに読み込む必要があ #### プリペアドステートメントの過剰使用 {#prepared-statements-are-overused} -クライアント側はプリペアドステートメントを作成し続けますが、実行しません[`deallocate prepare stmt`](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement) 。これによりメモリ消費量が増加し続け、最終的にはTiDB OOMが発生します。これは、プリペアドステートメントによって占有されたメモリがセッションが終了するまで解放されないためです。これは、長時間接続セッションにおいて特に重要です。 +クライアント側はプリペアドステートメントを作成し続けますが、[`deallocate prepare stmt`](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement)を実行しません。これによりメモリ消費量が増加し続け、最終的にはTiDB OOMが発生します。これは、プリペアドステートメントによって占有されたメモリがセッションが終了するまで解放されないためです。これは、長時間接続セッションにおいて特に重要です。 この問題を解決するには、次の対策を検討してください。 diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index eeb5cf94a0937..2cafd6d71174c 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -11,7 +11,7 @@ TiDB v3.0.8より前のバージョンでは、TiDBはデフォルトで楽観 ## 書き込み競合の原因 {#the-reason-of-write-conflicts} -TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf)トランザクションモデルを用いてトランザクションを実装します。`percolator`一般的に2PCの実装です。2PCの詳細なプロセスについては[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 +TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf)トランザクションモデルを用いてトランザクションを実装します。`percolator`は一般的に2PCの実装です。2PCの詳細なプロセスについては[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 クライアントが TiDB に`COMMIT`リクエストを送信すると、TiDB は 2PC プロセスを開始します。 @@ -19,7 +19,7 @@ TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/ 2. TiDBは、このコミットに関係するすべてのTiKVリージョンに`prewrite`リクエストを送信します。TiKVは、すべてのキーが正常にプレビューできるかどうかを判断します。 3. TiDB は、 `prewrite`リクエストがすべて成功したという結果を受け取ります。 4. TiDB は PD から`commit_ts`を取得します。 -5. TiDBは、トランザクションの主キーを含むTiKVリージョンに`commit`リクエストを送信します。TiKVは`commit`リクエストを受信すると、データの有効性を確認し、 `prewrite`番目のステージに残っているロックを解除します。 +5. TiDBは、トランザクションの主キーを含むTiKVリージョンに`commit`リクエストを送信します。TiKVは`commit`リクエストを受信すると、データの有効性を確認し、 `prewrite`ステージに残っているロックを解除します。 6. `commit`リクエストが正常に返されると、TiDB はクライアントに成功を返します。 書き込み競合はステージ`prewrite`で発生します。トランザクションが、別のトランザクションが現在のキー（ `data.commit_ts` > `txn.start_ts` ）に書き込みを行っていることを検出すると、書き込み競合が発生します。 diff --git a/tune-operating-system.md b/tune-operating-system.md index 85a48b9c6eb0d..7a2317780cfe8 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -75,7 +75,7 @@ grubby --update-kernel="$KERNEL" --args='transparent_hugepage=never' ### メモリ - 仮想メモリパラメータ {#memory-virtual-memory-parameters} - `dirty_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムは`pdflush`オペレーションを使用してダーティページキャッシュをディスクに書き込みます。デフォルト値の`dirty_ratio`は 20% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、この値を下げるとメモリ回収の効率が向上します。 -- `dirty_background_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムはバックグラウンドでダーティページキャッシュをディスクに書き込み始めます。デフォルト値は`dirty_background_ratio`で、10% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、値を低く設定するとメモリ回収の効率が向上します。 +- `dirty_background_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムはバックグラウンドでダーティページキャッシュをディスクに書き込み始めます。デフォルト値の`dirty_background_ratio`は 10% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、値を低く設定するとメモリ回収の効率が向上します。 ### ストレージとファイルシステム {#storage-and-file-system} @@ -115,7 +115,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler - ソフトウェア割り込み： `/proc/net/softnet_stat`の監視を監視します。3列目以外の列の値が増加している場合は、 `softirq`の`net.core.netdev_budget`または`net.core.dev_weight`の値を適切に調整して、CPU 時間を増やします。さらに、CPU 使用率も確認し、どのタスクが頻繁に CPU を使用しているか、そしてそれらを最適化できるかどうかを特定する必要があります。 -- アプリケーションソケットの受信キュー： `ss -nmp`目のうち`Resv-q`列を監視します。キューがいっぱいの場合は、アプリケーションソケットのキャッシュサイズを増やすか、自動キャッシュ調整機能の使用を検討してください。さらに、アプリケーションレイヤーのアーキテクチャを最適化し、ソケットの読み取り間隔を短縮できるかどうかも検討してください。 +- アプリケーションソケットの受信キュー： `ss -nmp`の`Resv-q`列を監視します。キューがいっぱいの場合は、アプリケーションソケットのキャッシュサイズを増やすか、自動キャッシュ調整機能の使用を検討してください。さらに、アプリケーションレイヤーのアーキテクチャを最適化し、ソケットの読み取り間隔を短縮できるかどうかも検討してください。 - イーサネット フロー制御: NIC とスイッチがフロー制御機能をサポートしている場合は、この機能を使用して、カーネルが NIC キュー内のデータを処理するための時間を確保し、NIC バッファ オーバーフローの問題を回避できます。 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} diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index 6b0ab60c283d6..7a85faaec379c 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -36,7 +36,7 @@ TiKV の読み取り要求は次の種類に分類されます。 - ストレージ読み取りプールで実行される、特定の行または複数の行を指定する単純なクエリ。 - コプロセッサー読み取りプールで実行される複雑な集計計算と範囲クエリ。 -TiKV v5.0以降、すべての読み取りリクエストはデフォルトでクエリ用の統合スレッドプールを使用します。TiKVクラスターをTiKV v4.0からアップグレードし、アップグレード前に`use-unified-pool`設定が`readpool.storage`から`false`に設定されていた場合、アップグレード後もすべての読み取りリクエストは引き続き異なるスレッドプールを使用します。このシナリオでは、すべての読み取りリクエストがクエリ用の統合スレッドプールを使用するようにするには、 `readpool.storage.use-unified-pool`を`true`に設定します。 +TiKV v5.0以降、すべての読み取りリクエストはデフォルトでクエリ用の統合スレッドプールを使用します。TiKVクラスターをTiKV v4.0からアップグレードし、アップグレード前に`readpool.storage`の`use-unified-pool`設定が`false`に設定されていた場合、アップグレード後もすべての読み取りリクエストは引き続き異なるスレッドプールを使用します。このシナリオでは、すべての読み取りリクエストがクエリ用の統合スレッドプールを使用するようにするには、 `readpool.storage.use-unified-pool`を`true`に設定します。 ## TiKV スレッドプールのパフォーマンスチューニング {#performance-tuning-for-tikv-thread-pools} @@ -64,14 +64,14 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - StoreWriterスレッドプールのサイズが0の場合、すべての書き込みリクエストはRaftstoreスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。RaftstoreRaftstore数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 + - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。Raftstoreスレッド数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッド プールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 - StoreWriterスレッドプールのサイズが0でない場合、すべての書き込みリクエストはStoreWriterスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - StoreWriterスレッドプールは、CPUリソース全体が十分である場合にのみ有効にしてください。StoreWriterスレッドプールを有効にする際は、StoreWriterスレッドとRaftstoreスレッドのCPU使用率を80%未満に抑えてください。 - 書き込み要求がRaftstoreスレッドで処理される場合と比較して、理論上は、書き込み要求が StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O 要求をRaftstoreスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 + 書き込み要求がRaftstoreスレッドで処理される場合と比較して、理論上は、書き込み要求が StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O 要求をStoreWriterスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 - ほとんどの場合、StoreWriter スレッドプールのサイズは 1 または 2 に設定してください。これは、StoreWriter スレッドプールのサイズがRaftログの数に影響するため、スレッドプールのサイズを大きくしすぎないようにするためです。CPU 使用率が 80% を超える場合は、スレッドプールのサイズを増やすことを検討してください。 @@ -81,7 +81,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで UnifyReadPool はすべての読み取りリクエストの処理を担当します。デフォルトのサイズ（ `readpool.unified.max-thread-count`に設定）は、マシンの CPU コア数の 80% です。例えば、マシンの CPU コア数が 16 の場合、デフォルトのスレッドプールサイズは 12 です。アプリケーションのワークロードに応じて CPU 使用率を調整し、スレッドプールサイズの 60% から 90% の範囲に維持することをお勧めします。 - Grafanaの`TiKV-Details.Thread CPU.Unified read pool CPU`のピーク値が800%を超えない場合は、 `readpool.unified.max-thread-count` ～ `10`に設定することをお勧めします。スレッド数が多すぎると、スレッドの切り替えが頻繁に発生し、他のスレッドプールのリソースを消費する可能性があります。 + Grafanaの`TiKV-Details.Thread CPU.Unified read pool CPU`のピーク値が800%を超えない場合は、 `readpool.unified.max-thread-count`を`10`に設定することをお勧めします。スレッド数が多すぎると、スレッドの切り替えが頻繁に発生し、他のスレッドプールのリソースを消費する可能性があります。 v6.3.0以降、TiKVは現在のCPU使用率に基づいてUnifyReadPoolスレッドプールサイズを自動調整する機能をサポートしています。この機能を有効にするには、 [`readpool.unified.auto-adjust-pool-size = true`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)を設定します。再読み取りが行われ、最大CPU使用率が80%を超えるクラスターについては、スレッドプールサイズを自動調整することをお勧めします。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index c7bbe82b8c09c..899f83e0ffb45 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -10,7 +10,7 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > **Warning:** > > 1. TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 CentOS Linux 7 で実行されているクラスターを v8.5 にアップグレードする場合は、クラスターが使用できなくなるリスクを避けるために、必ず TiDB v8.5.1 以降のバージョンを使用してください。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 -> 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスタをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 。 +> 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスタをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 > 3. アップグレード処理中はDDLステートメントを実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 > 4. TiDB クラスターで DDL ステートメントが実行されている間は、クラスターをアップグレード**しないでください**(通常、 `ADD INDEX`や列型の変更など、時間のかかる DDL ステートメントの場合)。アップグレードの前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスターで DDL ジョブが実行中かどうかを確認することをお勧めします。クラスターで DDL ジョブが実行されている場合は、クラスターをアップグレードする前に、DDL の実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 > 5. アップグレード前の TiDB バージョンが 7.1.0 以降の場合は、前述の警告 3 と 4 を無視してかまいません。詳細については、 [TiDB スムーズアップグレードの使用に関する制限](/smooth-upgrade-tidb.md#limitations)を参照してください。 @@ -142,7 +142,7 @@ tiup update cluster tiup cluster edit-config ``` -2. フォーマットを参照[トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 +2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するには「Y」と入力してください。 @@ -152,7 +152,7 @@ tiup update cluster - クラスタDDL: - - [スムーズなアップグレード](/smooth-upgrade-tidb.md)アップグレードを使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレード プロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 + - [スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレード プロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 - な を使用しない場合は、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)[スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して、実行中の DDL ジョブが存在するかどうかを確認することをお勧めします。実行中の DDL ジョブが存在する場合は、アップグレードを実行する前に、ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)ステートメントを使用してキャンセルしてください。 - クラスタのバックアップ：クラスタ内でバックアップまたはリストアタスクが実行中かどうかを確認するには[`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md)コマンドを実行することをお勧めします。実行中の場合は、アップグレードを実行する前にタスクが完了するまでお待ちください。