diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 67596986cef42..db23c5ef7d3ec 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -121,7 +121,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ ### ステップ8: プルリクエストを作成する {#step-8-create-a-pull-request} 1. [https://github.com/$user/docs](https://github.com/$user/docs)でフォークにアクセスします ( `$user` GitHub ID に置き換えます) -2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。5 [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)参照してください。 +2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。詳細は[プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。 これで、PR が正常に送信されました。この PR がマージされると、自動的に TiDB ドキュメントの貢献者になります。 diff --git a/agg-distinct-optimization.md b/agg-distinct-optimization.md index 5380aec6c3752..1a66387a25401 100644 --- a/agg-distinct-optimization.md +++ b/agg-distinct-optimization.md @@ -39,7 +39,7 @@ TiDB の[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distin -この最適化の例として、以下のクエリを見てみましょう。1 `tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。 +この最適化の例として、以下のクエリを見てみましょう。`tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。 ```sql mysql> desc select count(distinct a) from test.t; diff --git a/ai/guides/image-search.md b/ai/guides/image-search.md index a9fefceff7299..4731d1afbf9e0 100644 --- a/ai/guides/image-search.md +++ b/ai/guides/image-search.md @@ -36,7 +36,7 @@ image_embed = EmbeddingFunction( ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-vector-field} -`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。3 `source_field`画像のURLを格納するフィールドを指定するためのパラメータです。 +`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。`source_field`画像のURLを格納するフィールドを指定するためのパラメータです。 ```python from pytidb.schema import TableModel, Field diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index ee4a29cad19c7..72f408b1250e3 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -323,7 +323,7 @@ results = ( > **注記：** > -> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。3 `.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。 +> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。`.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。 > `num_candidate`値を大きくすると、一般的に再現率は向上しますが、クエリのパフォーマンスが低下する可能性があります。データセットと精度要件に応じてこの値を調整してください。 diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index e5288a27d59b2..700d6befc31e0 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -130,7 +130,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; +---------------+------------+----------+-------------+---------------+-----------+----------+------------+---------------------+-------------------------+--------------------+------------------------+---------------+------------------+ ``` -- インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。5 `ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。 +- インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。`ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。 参考までに、768次元の500MiBベクトルデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。 @@ -148,7 +148,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used} -クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。9 `TableFullScan`キュータの`operator info`列に`annIndex:`表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。 +クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。`TableFullScan`キュータの`operator info`列に`annIndex:`表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。 **例: ベクトルインデックスが使用される** diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..961759fa7ceba 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -406,7 +406,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - 低速TiKVノードがあります。1 `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)参照してください。 - 解決： @@ -555,7 +555,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。 2. ホットスポットがあるかどうかを確認します。 - 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。7 `over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 + 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 #### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv-raftstore-thread-cpu-seconds-total} @@ -567,7 +567,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま このルールは、 Raftstoreによる CPU 使用率を監視します。値が高い場合、 Raftstoreスレッドへの負荷が高いことを示します。 - アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。3 `raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。 + アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。`raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。 - 解決： diff --git a/auto-increment.md b/auto-increment.md index 32ddb3b37a250..4e5a8c260ad18 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -27,7 +27,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。 ## コンセプト {#concept} -`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。 +`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。`INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。 パフォーマンス上の理由から、各TiDBサーバーには、 `AUTO_INCREMENT`個の数値が一括で割り当てられます（デフォルトでは3万個）。つまり、 `AUTO_INCREMENT`数値は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調なものになります。 diff --git a/auto-random.md b/auto-random.md index 61cc19bf30eb4..e169abc07feac 100644 --- a/auto-random.md +++ b/auto-random.md @@ -177,7 +177,7 @@ TiDBインスタンスが1つの場合、ノードは明示的な挿入を処理 ALTER TABLE t AUTO_RANDOM_BASE=0; ``` -このステートメントは適切な基数を自動的に決定します。1 `Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。 +このステートメントは適切な基数を自動的に決定します。`Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。 > **注記：** > diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index f1cc155bef27b..e0b9539d43eb0 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -58,7 +58,7 @@ tiup bench ch -H 172.16.5.140 -P 4000 -D tpcc prepare ## TiFlashレプリカを作成する {#create-tiflash-replicas} -TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。1 `tpcc`のTiFlashレプリカを作成するには、次の SQL 文を実行する必要があります。指定されたTiFlashレプリカが作成されると、TiKV は最新のデータをリアルタイムでTiFlashに自動的に複製します。次の例では、クラスターに 2 つのTiFlashノードをデプロイし、レプリカ数を 2 に設定しています。 +TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。`tpcc`のTiFlashレプリカを作成するには、次の SQL 文を実行する必要があります。指定されたTiFlashレプリカが作成されると、TiKV は最新のデータをリアルタイムでTiFlashに自動的に複製します。次の例では、クラスターに 2 つのTiFlashノードをデプロイし、レプリカ数を 2 に設定しています。 ALTER DATABASE tpcc SET tiflash replica 2; @@ -70,8 +70,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; 上記のステートメントの結果は次のようになります。 -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 -- `PROGRESS`レプリケーションの進行状況を示します。値は`0`から`1`までです。6 `1` TiFlashレプリカのレプリケーションが完了したことを意味します。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 +- `PROGRESS`レプリケーションの進行状況を示します。値は`0`から`1`までです。`1` TiFlashレプリカのレプリケーションが完了したことを意味します。 ## 統計を収集する {#collect-statistics} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 8ef9aca7cbb11..dc29217d253f3 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -75,7 +75,7 @@ report-interval=10 db-driver=mysql ``` -上記のパラメータは、実際のニーズに合わせて調整できます。1 `TIDB_HOST` TiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`テストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 +上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST` TiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`テストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。 サンプル**設定**ファイルとして以下を参照してください。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 2cb133a138aa4..18eb34cb48849 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -161,7 +161,7 @@ TiDB v6.2.0以降、単一の`ALTER`文でテーブル内の複数のスキー ### 読み取りと書き込みのパフォーマンスを確認する {#check-the-read-and-write-performance} -TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。1 `ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。 +TiDBがインデックスを追加する際、データのバックフィルフェーズによってクラスターの読み取りと書き込みに負荷がかかります。`ADD INDEX`のコマンドが送信され、 `write reorg`番目のフェーズが開始されたら、GrafanaダッシュボードでTiDBとTiKVの読み取りと書き込みのパフォーマンスメトリックとアプリケーションの応答時間を確認し、 `ADD INDEX`操作がクラスターに影響を与えているかどうかを確認することをお勧めします。 ## DDL関連コマンド {#ddl-related-commands} diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 3f0cfff798c58..3bc22563f238e 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -60,7 +60,7 @@ CREATE TABLE IF NOT EXISTS TEST_HOTSPOT( ) ``` -このテーブルは構造が単純です。主キーの`id`以外に、セカンダリインデックスは存在しません。このテーブルにデータを書き込むには、次のステートメントを実行してください。3 `id`乱数として離散的に生成されます。 +このテーブルは構造が単純です。主キーの`id`以外に、セカンダリインデックスは存在しません。このテーブルにデータを書き込むには、次のステートメントを実行してください。`id`乱数として離散的に生成されます。 ```sql SET SESSION cte_max_recursion_depth = 1000000; @@ -92,7 +92,7 @@ FROM ![QPS1](/media/best-practices/QPS1.png) -クライアントは短時間で「集中的な」書き込みリクエストを開始し、TiDBは3K QPSの書き込みを受信しました。理論上、負荷は6つのTiKVノードに均等に分散されるはずです。しかし、各TiKVノードのCPU使用率から判断すると、負荷分散は不均一です。1 `tikv-3`ノードが書き込みのホットスポットとなっています。 +クライアントは短時間で「集中的な」書き込みリクエストを開始し、TiDBは3K QPSの書き込みを受信しました。理論上、負荷は6つのTiKVノードに均等に分散されるはずです。しかし、各TiKVノードのCPU使用率から判断すると、負荷分散は不均一です。`tikv-3`ノードが書き込みのホットスポットとなっています。 ![QPS2](/media/best-practices/QPS2.png) @@ -156,9 +156,9 @@ TiDBは汎用的な用途向けのデータベースであり、データ分布 SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128; ``` -事前分割操作の後、 `SHOW TABLE test_hotspot REGIONS;`のステートメントを実行して、 リージョン scattering の状態を確認します。3 `SCATTERING`の列の値がすべて`0`であれば、スケジューリングは成功です。 +事前分割操作の後、 `SHOW TABLE test_hotspot REGIONS;`のステートメントを実行して、 リージョン scattering の状態を確認します。`SCATTERING`の列の値がすべて`0`であれば、スケジューリングは成功です。 -次のSQL文を使用して、リージョンリーダーの分布を確認することもできます。1 `table_name`実際のテーブル名に置き換えてください。 +次のSQL文を使用して、リージョンリーダーの分布を確認することもできます。`table_name`実際のテーブル名に置き換えてください。 ```sql SELECT @@ -196,7 +196,7 @@ ORDER BY このような状況でホットスポット問題を回避するには、テーブル作成時に`SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`使用します。 `PRE_SPLIT_REGIONS`の詳細については、 [分割前のリージョン](/sql-statements/sql-statement-split-region.md#pre_split_regions)を参照してください。 -`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。4 `PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。 +`SHARD_ROW_ID_BITS` 、 `_tidb_rowid`列に生成された行 ID をランダムに散布するために使用されます。`PRE_SPLIT_REGIONS` 、テーブルの作成後にリージョンを事前に分割するために使用されます。 > **注記：** > diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index b52410574ac9d..40b4313e826a3 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -302,7 +302,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - フィルタリングの効率を向上させるために列を追加します。 - インデックス構造の変更 (プレフィックス インデックス、複合インデックスなど)。 - - インデックスの選択性を分析します。3 `TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 + - インデックスの選択性を分析します。`TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 4. **DML パフォーマンスへの影響に注意してください。** diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 009e4ecb603d3..ce5a1df8b8614 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -88,7 +88,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ > > TiDB v3.0 以降では`Region Merge`がデフォルトで有効になっています。 -`Region Merge`有効にすることで、Regionの数を減らすこともできます。3 `Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。 +`Region Merge`有効にすることで、Regionの数を減らすこともできます。`Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。 次のパラメータを設定して`Region Merge`有効にします。 @@ -122,7 +122,7 @@ I/O リソースと CPU リソースが十分な場合は、単一のマシン raft-election-timeout = raft-base-tick-interval * raft-election-timeout-ticks raft-heartbeat-interval = raft-base-tick-interval * raft-heartbeat-ticks -リージョンフォロワーが`raft-election-timeout`間隔以内にリーダーからのハートビートを受信しなかった場合、これらのフォロワーはリーダーが故障したと判断し、新たな選出を開始します。3 `raft-heartbeat-interval` 、リーダーがフォロワーにハートビートを送信する間隔です。したがって、この値を`raft-base-tick-interval`に増やすと、 Raftステートマシンから送信されるネットワークメッセージの数は減りますが、 Raftステートマシンがリーダーの故障を検出するまでの時間が長くなります。 +リージョンフォロワーが`raft-election-timeout`間隔以内にリーダーからのハートビートを受信しなかった場合、これらのフォロワーはリーダーが故障したと判断し、新たな選出を開始します。`raft-heartbeat-interval` 、リーダーがフォロワーにハートビートを送信する間隔です。したがって、この値を`raft-base-tick-interval`に増やすと、 Raftステートマシンから送信されるネットワークメッセージの数は減りますが、 Raftステートマシンがリーダーの故障を検出するまでの時間が長くなります。 ### 方法6:リージョンのサイズを調整する {#method-6-adjust-region-size} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 247e9544b4434..85280198a21d9 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -56,7 +56,7 @@ EXPLAIN FORMAT = "brief" SELECT * FROM listings WHERE price < 2000; CREATE INDEX idx_city_bedrooms_price ON listings (city, bedrooms, price); ``` -SQLの複数列インデックスは辞書式順序で並べられます。1 `(city, bedrooms, price)`インデックスの場合、データはまず`city`でソートされ、次に各都市内で`bedrooms`でソートされ、最後に各`(city, bedrooms)`組み合わせ内で`price`でソートされます。この順序付けにより、TiDBは各条件に基づいて効率的に行にアクセスできます。 +SQLの複数列インデックスは辞書式順序で並べられます。`(city, bedrooms, price)`インデックスの場合、データはまず`city`でソートされ、次に各都市内で`bedrooms`でソートされ、最後に各`(city, bedrooms)`組み合わせ内で`price`でソートされます。この順序付けにより、TiDBは各条件に基づいて効率的に行にアクセスできます。 1. プライマリフィルターである`city`でフィルターします。 2. オプションで、その都市内で`bedrooms`でフィルタリングします。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 4ceb0ff28f373..4c40b1d51dc5e 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -68,7 +68,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 1. リソースの可用性に応じてストアを評価します。 2. `balance-leader`または`balance-region` 、高スコアのストアから低スコアのストアへ、リーダーまたはピアを継続的に異動させます。 -しかし、評価方法は異なります。1 `balance-leader`ストア内のリーダーに対応するすべてのリージョンサイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 +しかし、評価方法は異なります。`balance-leader`ストア内のリーダーに対応するすべてのリージョンサイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 - 十分なストレージがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 - ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 @@ -96,7 +96,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ スケールインとは、コマンドを使用してストアをオフラインにし、「オフライン」としてマークするプロセスを指します。PDは、オフラインノード上のリージョンをスケジュールに従って他のノードに複製します。障害復旧は、ストアに障害が発生し、復旧できない場合に適用されます。この場合、対応するストアに分散されたピアを持つリージョンのレプリカが失われる可能性があり、PDは他のノードでレプリカを補充する必要があります。 -スケールインと障害回復のプロセスは基本的に同じです。1 `replicaChecker`異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換える演算子を生成します。 +スケールインと障害回復のプロセスは基本的に同じです。`replicaChecker`異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換える演算子を生成します。 ### リージョンの統合 {#region-merge} diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index 16e2a684bdb43..0ea04992e4923 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -78,7 +78,7 @@ SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに - より多くの同時リクエストをサポートするには、TiDB 構成項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。 - TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。 -- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。3 `DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`含む 400,000 の実行プランで約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 +- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`含む 400,000 の実行プランで約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 ## 古いものを使用するには、慎重に読んでください {#use-stale-read-carefully} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 612711f0681cb..f97c8f2a23802 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -61,4 +61,4 @@ Key Visualizer の詳細については、次のドキュメントを参照し ## MySQLの互換性 {#mysql-compatibility} -UUIDはMySQLでも使用できます。1と`UUID_TO_BIN()` `BIN_TO_UUID()`はMySQL 8.0で導入されました。5 `UUID()`関数はそれ以前のMySQLバージョンでも使用できます。 +UUIDはMySQLでも使用できます。1と`UUID_TO_BIN()` `BIN_TO_UUID()`はMySQL 8.0で導入されました。`UUID()`関数はそれ以前のMySQLバージョンでも使用できます。 diff --git a/binary-package.md b/binary-package.md index be5127de093e8..21a281965f100 100644 --- a/binary-package.md +++ b/binary-package.md @@ -70,7 +70,7 @@ TiDBバイナリパッケージは、amd64およびarm64アーキテクチャで > **注記：** > -> `{version}`インストールするツールのバージョンによって異なります。2 `{arch}`システムのアーキテクチャによって異なり、 `amd64`または`arm64`になります。 +> `{version}`インストールするツールのバージョンによって異なります。`{arch}`システムのアーキテクチャによって異なり、 `amd64`または`arm64`になります。 ## 参照 {#see-also} diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index 1d50372e08c2d..a885c9b9ddcd7 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -96,7 +96,7 @@ DESC mysql.expr_pushdown_blacklist; 上記の各フィールドの説明は次のとおりです。 - `name` : プッシュダウンが無効になっている関数の名前。 -- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。8 `store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 +- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 - `store_type`が`tidb`場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 - `store_type`が`tikv`場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 - `store_type`が`tiflash`場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 1651751b09c7f..cd5c092aeb622 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -69,7 +69,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v - 自動調整により、 `backup.auto-tune-refresh-interval`分ごとに統計が更新され、バックアップ タスクで使用できる CPU コアの最大数が再計算されます。 - デフォルト値: `1m` -以下は、自動チューニングの動作例です。1 `*`バックアップ タスクで使用される CPU コアを示します。3 `^`他のタスクで使用される CPU コアを示します。5 `-` 、アイドル状態の CPU コアを示します。 +以下は、自動チューニングの動作例です。`*`バックアップ タスクで使用される CPU コアを示します。`^`他のタスクで使用される CPU コアを示します。`-` 、アイドル状態の CPU コアを示します。 |--------| The server has 8 logical CPU cores. |****----| By default, `backup.num-threads` is `4`. Note that auto-tune makes sure that the thread pool size is never larger than `backup.num-threads`. diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index 57675fa561034..bbff07cfdde7a 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -22,7 +22,7 @@ summary: TiDB v6.0.0では、データ復元時のテーブル作成プロセス ## バッチテーブル作成を使用する {#use-batch-create-table} -BRはデフォルトでバッチテーブル作成機能を有効にします。v6.0.0以降では、復元プロセスを高速化するために、デフォルト設定は`--ddl-batch-size=128` 。そのため、このパラメータを設定する必要はありません。3 `--ddl-batch-size=128` 、バッチでテーブルを作成し、各バッチで128個のテーブルを作成することを意味します。 +BRはデフォルトでバッチテーブル作成機能を有効にします。v6.0.0以降では、復元プロセスを高速化するために、デフォルト設定は`--ddl-batch-size=128` 。そのため、このパラメータを設定する必要はありません。`--ddl-batch-size=128` 、バッチでテーブルを作成し、各バッチで128個のテーブルを作成することを意味します。 この機能を無効にするには、 `--ddl-batch-size`を`1`に設定します。以下のコマンド例をご覧ください。 diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index f23a3919299b2..9610321f41fdf 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -27,7 +27,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを ### バックアップの再試行はGCの前に行う必要があります {#backup-retry-must-be-prior-to-gc} -バックアップ中、 `br` PD内のバックアップスナップショット`gc-safepoint`を定期的に更新し、データのガベージコレクションを回避します。5 `br`終了すると、 `gc-safepoint`時間内に更新されません。その結果、次のバックアップ再試行までに、データがガベージコレクションされている可能性があります。 +バックアップ中、 `br` PD内のバックアップスナップショット`gc-safepoint`を定期的に更新し、データのガベージコレクションを回避します。`br`終了すると、 `gc-safepoint`時間内に更新されません。その結果、次のバックアップ再試行までに、データがガベージコレクションされている可能性があります。 このような状況を回避するため、 `gcttl`指定されていない場合、 `br`デフォルトで`gc-safepoint`約1時間保持します。必要に応じて、 `gcttl`パラメータを設定することで保持期間を延長できます。 @@ -49,4 +49,4 @@ tiup br backup full \ - 中断の原因がエラーである場合、 `br`終了前にバックアップされたデータのメタ情報を保持します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージにバックアップされたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージにバックアップされたデータのメタ情報を永続化できません。`br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index c8f4f607fe7c4..2d8a221d6d848 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -19,7 +19,7 @@ TiDBクラスタが大規模で、障害発生後に再度リストアを行う ### スナップショットの復元 {#snapshot-restore} -スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。3 `br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 +スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。`br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 `br`復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`チェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 @@ -43,7 +43,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### GCは一時停止されます {#gc-will-be-paused} -ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`ログの復元中にGCを一時停止します。3 `br`途中で終了した場合、GCは一時停止状態のままになります。 +ログの復元中、復元されたデータの順序は不規則です。つまり、キーの削除レコードが書き込みレコードよりも先に復元される可能性があります。この時にGCがトリガーされると、キーのすべてのデータが削除され、GCはキーの後続の書き込みレコードを処理できなくなります。このような状況を回避するため、 `br`ログの復元中にGCを一時停止します。`br`途中で終了した場合、GCは一時停止状態のままになります。 ログの復元が完了すると、GCは手動で起動することなく自動的に再起動されます。ただし、復元を続行しない場合は、以下の手順でGCを手動で有効にすることができます。 @@ -55,7 +55,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた - 中断の原因がエラーである場合、 `br`終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージに復元されたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージに復元されたデータのメタ情報を永続化できません。`br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 ### 復元中にクラスタデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore} @@ -77,7 +77,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 初期復元中に、 `br`ターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。 -復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。`br` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`エラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 @@ -143,7 +143,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 初期復元中に、 `br`指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パス`br`作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。 -復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。`br` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、エラーコード`br`報告されます。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。 diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index bdb278c25e7f3..80db2ae6d7ac3 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -25,7 +25,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ ## 増分データをバックアップする {#back-up-incremental-data} -増分データをバックアップするには、 `tiup br backup`コマンドを、**最終バックアップのタイムスタンプ**`--lastbackupts`を指定して実行します。これにより、br コマンドラインツールは`lastbackupts`から現在時刻の間に生成された増分データを自動的にバックアップします。9 `--lastbackupts`取得するには、 `validate`コマンドを実行します。以下は例です。 +増分データをバックアップするには、 `tiup br backup`コマンドを、**最終バックアップのタイムスタンプ**`--lastbackupts`を指定して実行します。これにより、br コマンドラインツールは`lastbackupts`から現在時刻の間に生成された増分データを自動的にバックアップします。`--lastbackupts`取得するには、 `validate`コマンドを実行します。以下は例です。 ```shell LAST_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 5c5e93107cf28..db50b8f02f666 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -49,7 +49,7 @@ summary: このドキュメントでは、ログバックアップの監視、 | **tikv_log_backup_initial_scan_operations** | カウンタ | 初期スキャン中の RocksDB 関連操作の統計。
`cf :: {"default", "write", "lock"}, op :: RocksDBOP` | | **tikv_log_backup_enabled** | カウンタ | ログバックアップを有効にするかどうか。値が`0`より大きい場合、ログバックアップは有効になります。 | | **tikv_log_backup_observed_region** | ゲージ | リッスンされているリージョンの数。 | -| **tikv_log_backup_task_status** | ゲージ | ログ バックアップ タスクのステータス。1 `0`実行中、 `1`一時停止中、 `2`エラーを意味します。
`task :: string` | +| **tikv_log_backup_task_status** | ゲージ | ログ バックアップ タスクのステータス。`0`実行中、 `1`一時停止中、 `2`エラーを意味します。
`task :: string` | | **tikv_log_backup_pending_initial_scan** | ゲージ | 保留中の初期スキャンの統計。
`stage :: {"queuing", "executing"}` | ### ログバックアップアラート {#log-backup-alerts} diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index f4f31a53d7978..c09e41438f3e0 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -70,7 +70,7 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379" ### 定期的に完全バックアップを実行する {#run-full-backup-regularly} -スナップショットバックアップは、フルバックアップの方法として使用できます。1 `tiup br backup full`実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 +スナップショットバックアップは、フルバックアップの方法として使用できます。`tiup br backup full`実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 ```shell tiup br backup full --pd "${PD_IP}:2379" \ diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 8a37e941c407b..05813ae182c7e 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -96,7 +96,7 @@ TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラ - `--log.crypter.method` : 暗号化アルゴリズム。2、4、6 `aes192-ctr` `aes128-ctr`かになります。デフォルト値は`aes256-ctr` `plaintext` 、データは暗号化されません。 - `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 -- `--log.crypter.key-file` : キーファイル。2 `crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 +- `--log.crypter.key-file` : キーファイル。`crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 次に例を示します。 diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 581210cb32cd6..5ee37a9c24596 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -133,7 +133,7 @@ tiup br restore full \ バックアップと復元機能は、データをバックアップする際に、統計情報をJSON形式で`backupmeta`ファイルに保存します。データを復元する際には、JSON形式の統計情報をクラスターに読み込みます。詳細については、 [負荷統計](/sql-statements/sql-statement-load-stats.md)参照してください。 -v8.5.5以降、 BRは`--fast-load-sys-tables`パラメータを導入し、デフォルトで有効になっています。3 `br`ラインツールを使用して新しいクラスターにデータを復元する場合、上流クラスターと下流クラスター間のテーブルとパーティションのIDを再利用できます（そうでない場合、 BRは自動的に統計を論理的にロードします） `--fast-load-sys-tables`有効にすると、 BRはまず統計関連のシステムテーブルを一時システムデータベース`__TiDB_BR_Temporary_mysql`に復元し、次に`RENAME TABLE`ステートメントを使用してこれらのテーブルを`mysql`データベース内の対応するテーブルとアトミックにスワップします。 +v8.5.5以降、 BRは`--fast-load-sys-tables`パラメータを導入し、デフォルトで有効になっています。`br`ラインツールを使用して新しいクラスターにデータを復元する場合、上流クラスターと下流クラスター間のテーブルとパーティションのIDを再利用できます（そうでない場合、 BRは自動的に統計を論理的にロードします） `--fast-load-sys-tables`有効にすると、 BRはまず統計関連のシステムテーブルを一時システムデータベース`__TiDB_BR_Temporary_mysql`に復元し、次に`RENAME TABLE`ステートメントを使用してこれらのテーブルを`mysql`データベース内の対応するテーブルとアトミックにスワップします。 次に例を示します。 @@ -150,7 +150,7 @@ TiDB v5.3.0 以降では、次のパラメータを設定することでバッ - `--crypter.method` : 暗号化アルゴリズム`aes128-ctr` `aes192-ctr`または`aes256-ctr`いずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 -- `--crypter.key-file` : キーファイル。2 `crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 +- `--crypter.key-file` : キーファイル。`crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 次に例を示します。 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index dbc9bf6040a6a..26c3940dbd66c 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -61,7 +61,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `--pitr-concurrency` : ログ復元中の同時タスクの数。 - `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。 - `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。2、4、6 `lz4`サポートし、デフォルトは`zstd`です（通常は変更する必要`zstd`ありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を`snappy`してください。 -- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。2 `zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 +- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。`zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 ## フルバックアップのコマンド {#commands-of-full-backup} diff --git a/cached-tables.md b/cached-tables.md index a90b2d8264389..cd05162ad9308 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -72,7 +72,7 @@ SHOW CREATE TABLE users; 1 row in set (0.00 sec) ``` -キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。1 文[`TRACE`](/sql-statements/sql-statement-trace.md)使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 +キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。[`TRACE`](/sql-statements/sql-statement-trace.md)文を使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 ```sql TRACE SELECT * FROM users; @@ -234,7 +234,7 @@ Query OK, 0 rows affected (0.00 sec) ## TiDB移行ツールとの互換性 {#compatibility-with-tidb-migration-tools} -キャッシュテーブルは、MySQL構文に対するTiDBの拡張です。1 `ALTER TABLE ... CACHE`を認識できるのはTiDBのみです。TiDB移行ツール（Backup & Restore (BR)、TiCDC、 Dumplingなど）は、キャッシュテーブルをサポートし**ていません**。これらのツールは、キャッシュテーブルを通常のテーブルとして扱います。 +キャッシュテーブルは、MySQL構文に対するTiDBの拡張です。`ALTER TABLE ... CACHE`を認識できるのはTiDBのみです。TiDB移行ツール（Backup & Restore (BR)、TiCDC、 Dumplingなど）は、キャッシュテーブルをサポートし**ていません**。これらのツールは、キャッシュテーブルを通常のテーブルとして扱います。 つまり、キャッシュテーブルはバックアップとリストアが行われると、通常のテーブルになります。下流クラスターが別のTiDBクラスターであり、キャッシュテーブル機能を引き続き使用したい場合は、下流クラスターで`ALTER TABLE ... CACHE`実行することで、キャッシュテーブルを手動で有効化できます。 diff --git a/character-set-and-collation.md b/character-set-and-collation.md index 41d3961c86dc6..a2ab5f79567d1 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -178,7 +178,7 @@ MySQL と TiDB の両方で、 `utf8`と`utf8mb3`同じ文字セットのエイ TiDBはデフォルトで、文字セット`utf8`を最大3バイトに制限しています。これは、TiDBで作成されたデータがMySQLで安全に復元できることを保証するためです。システム変数[`tidb_check_mb4_value_in_utf8`](/system-variables.md#tidb_check_mb4_value_in_utf8)の値を`OFF`に変更することで、この制限を無効にすることができます。ただし、完全なUnicodeサポートと高い互換性のためには、代わりに`utf8mb4`使用することをお勧めします。 -以下は、4バイトの絵文字をテーブルに挿入する際のデフォルトの動作を示しています。1 `INSERT`文は`utf8`文字セットでは失敗しますが、 `utf8mb4`の文では成功します。 +以下は、4バイトの絵文字をテーブルに挿入する際のデフォルトの動作を示しています。`INSERT`文は`utf8`文字セットでは失敗しますが、 `utf8mb4`の文では成功します。 ```sql CREATE TABLE utf8_test ( @@ -382,7 +382,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; - デフォルト データベースの文字セットと照合順序は、システム変数`character_set_database`と`collation_database`の値です。 -`character_set_connection`と`collation_connection` 、各接続の文字セットと照合順序を指定するために使用できます。5 `character_set_client` 、クライアントの文字セットを設定するための変数です。 +`character_set_connection`と`collation_connection` 、各接続の文字セットと照合順序を指定するために使用できます。`character_set_client` 、クライアントの文字セットを設定するための変数です。 結果を返す前に、 `character_set_results`システム変数は、結果のメタデータを含む、サーバーがクライアントにクエリ結果を返す文字セットを示します。 @@ -390,7 +390,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; - `SET NAMES 'charset_name' [COLLATE 'collation_name']` - `SET NAMES` 、クライアントがサーバーに SQL ステートメントを送信するために使用する文字セットを示します。2 `SET NAMES utf8mb4` 、クライアントからのすべてのリクエストとサーバーからの結果に utf8mb4 が使用されることを示します。 + `SET NAMES` 、クライアントがサーバーに SQL ステートメントを送信するために使用する文字セットを示します。`SET NAMES utf8mb4` 、クライアントからのすべてのリクエストとサーバーからの結果に utf8mb4 が使用されることを示します。 `SET NAMES 'charset_name'`文は次の文の組み合わせと同等です。 diff --git a/check-before-deployment.md b/check-before-deployment.md index fe28a9b0187d1..3accb977d3b96 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -275,7 +275,7 @@ TiDB は、 ACIDモデルにおけるトランザクションの線形一貫性 NTP サービスがインストールされ、NTPサーバーと正常に同期しているかどうかを確認するには、次の手順を実行します。 -1. 次のコマンドを実行します。1 `running`返された場合、NTPサービスは実行中です。 +1. 次のコマンドを実行します。`running`返された場合、NTPサービスは実行中です。 ```bash sudo systemctl status ntpd.service @@ -359,7 +359,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 - オフセットが大きすぎると思われる場合は、コマンド`chronyc makestep`を実行してすぐに時間オフセットを修正できます。そうでない場合は、 `chronyd`実行して徐々に時間オフセットを修正します。 -NTPサービスの同期をできるだけ早く開始するには、次のコマンドを実行してください。1 `pool.ntp.org` NTPサーバーに置き換えてください。 +NTPサービスの同期をできるだけ早く開始するには、次のコマンドを実行してください。`pool.ntp.org` NTPサーバーに置き換えてください。 ```bash sudo systemctl stop ntpd.service && \ @@ -696,7 +696,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t tidb ALL=(ALL) NOPASSWD: ALL -3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。3 `10.0.1.1`ターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 +3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。`10.0.1.1`ターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 ```bash ssh-keygen -t rsa diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 6d21af324bb2e..9e99640a073ad 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -243,7 +243,7 @@ PingCAPテクニカルサポートスタッフにクラスター診断データ tiup diag upload ``` -アップロードが完了すると、出力に`Download URL`が表示されます。3 `Download URL`リンクを開いてアップロードされたデータを確認するか、以前に連絡したPingCAPテクニカルサポートスタッフにリンクを送信してください。 +アップロードが完了すると、出力に`Download URL`が表示されます。`Download URL`リンクを開いてアップロードされたデータを確認するか、以前に連絡したPingCAPテクニカルサポートスタッフにリンクを送信してください。 #### 方法2. データをパックしてアップロードする {#method-2-pack-and-upload-data} diff --git a/column-pruning.md b/column-pruning.md index 403e4040c4e19..0d29caac88aa0 100644 --- a/column-pruning.md +++ b/column-pruning.md @@ -13,7 +13,7 @@ summary: TiDB での列プルーニングの使用法について学習します select a from t where b> 5 ``` -このクエリでは、列aと列bのみが使用され、列cと列dは冗長です。この文のクエリプランでは、 `Selection`の演算子が列bを使用し、 `DataSource`演算子が列aと列bを使用します。5 `DataSource`演算子は列cと列dを読み取らないため、これらはプルーニング可能です。 +このクエリでは、列aと列bのみが使用され、列cと列dは冗長です。この文のクエリプランでは、 `Selection`の演算子が列bを使用し、 `DataSource`演算子が列aと列bを使用します。`DataSource`演算子は列cと列dを読み取らないため、これらはプルーニング可能です。 そのため、TiDBはロジック最適化フェーズでトップダウンスキャンを実行する際に、リソースの無駄を削減するために冗長な列をプルーニングします。このスキャン処理は「カラムの剪定」と呼ばれ、ルール`columnPruner`に対応しています。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 280dd40e95dff..7c9f7b74c56cb 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -122,7 +122,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト。 - デフォルト: `""` - 通常、リバースプロキシを経由してTiDBにアクセスする場合、TiDBはリバースプロキシサーバーのIPアドレスをクライアントのIPアドレスとして取得します。PROXYプロトコルを有効にすると、HAProxyなどのこのプロトコルをサポートするリバースプロキシは、実際のクライアントIPアドレスをTiDBに渡すことができます。 -- このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`使用します。3 `*`任意のIPアドレスを意味します。 +- このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`使用します。`*`任意のIPアドレスを意味します。 > **警告：** > diff --git a/configure-load-base-split.md b/configure-load-base-split.md index 8a5588d6a59ad..2c6849e52d79f 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -32,7 +32,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ - [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold) :リージョンがホットスポットと判断されるQPSのしきい値。4GB [`region-split-size`](/tikv-configuration-file.md#region-split-size)の場合はデフォルト値は1秒あたり`3000` 、それ以外の場合はデフォルト値は`7000`です。 - [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-new-in-v50) : (v5.0で導入)リージョンがホットスポットとして識別されるトラフィックしきい値。単位はバイトです`region-split-size`が4GB未満の場合はデフォルト値は30MiB/秒、それ以外の場合は100MiB/秒です。 -- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) : (v6.2.0 で導入)リージョンがホットスポットと判断される CPU 使用率のしきい値 (読み取りスレッドプールの CPU 時間の割合)。4 `region-split-size`未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 +- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) : (v6.2.0 で導入)リージョンがホットスポットと判断される CPU 使用率のしきい値 (読み取りスレッドプールの CPU 時間の割合)。`region-split-size`未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 リージョンが10 秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 03728301f06e5..24c6816595f8f 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -145,7 +145,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして > **注記：** > -> HashAgg のディスクスピルは、 `DISTINCT`集計関数を含む SQL 実行をサポートしていません。3 `DISTINCT`集計関数を含む SQL 実行でメモリ使用量が多すぎる場合、ディスクスピルは適用されません。 +> HashAgg のディスクスピルは、 `DISTINCT`集計関数を含む SQL 実行をサポートしていません。`DISTINCT`集計関数を含む SQL 実行でメモリ使用量が多すぎる場合、ディスクスピルは適用されません。 次の例では、メモリを消費する SQL ステートメントを使用して、HashAgg のディスク スピル機能を示します。 diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index bffbb0467c20d..70e4daf5da76c 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -53,7 +53,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 上記の表のフィールドの説明は次のとおりです。 - `HOST` :サーバーの IP アドレス。 -- `INSTANCE` :サーバーにデプロイされているインスタンスの数。たとえば、 `pd * 1`サーバーに PD インスタンスが 1 つデプロイされていることを意味します。4 `tidb * 2 pd * 1` 、サーバーに TiDB インスタンスが 2 つと PD インスタンスが 1 つデプロイされていることを意味します。 +- `INSTANCE` :サーバーにデプロイされているインスタンスの数。たとえば、 `pd * 1`サーバーに PD インスタンスが 1 つデプロイされていることを意味します。`tidb * 2 pd * 1` 、サーバーに TiDB インスタンスが 2 つと PD インスタンスが 1 つデプロイされていることを意味します。 - `CPU_CORES` :サーバーの CPU コア数 (物理コアまたは論理コア) を示します。 - `MEMORY` :サーバーのメモリサイズを示します。単位はGBです。 - `DISK` :サーバーのディスクサイズを示します。単位はGBです。 @@ -325,7 +325,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり ![Compare Report Time Range report](/media/dashboard/dashboard-diagnostics-compare-time.png) -上記の表では、 `t1`正常な時間範囲、つまり基準時間範囲です。3 `t2`異常な時間範囲です。 +上記の表では、 `t1`正常な時間範囲、つまり基準時間範囲です。`t2`異常な時間範囲です。 スロークエリに関連するテーブルは次のように表示されます。 @@ -361,7 +361,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり ![Maximum Different Item table](/media/dashboard/dashboard-diagnostics-maximum-different-item.png) - `Table` : この監視メトリックが比較レポート内のどのテーブルから取得されるかを示します。たとえば、 `TiKV, coprocessor_info` TiKVコンポーネントの`coprocessor_info`のテーブルを示します。 -- `METRIC_NAME` : 監視メトリック名。2 `expand`クリックすると、メトリックの異なるラベルの比較が表示されます。 +- `METRIC_NAME` : 監視メトリック名。`expand`クリックすると、メトリックの異なるラベルの比較が表示されます。 - `LABEL` : 監視メトリックに対応するラベル。例えば、監視メトリック`TiKV Coprocessor scan`には、TiKVアドレス、リクエストタイプ、操作タイプ、操作カラムファミリーを表す2つのラベル（ `instance` 、 `req` 、 `tag` 、 `sql_type` ）があります。 - `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`計算した結果の差の値。 diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index cff3050e93c2b..ee10b88533a47 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -42,7 +42,7 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き 2. アップグレード後、Prometheus インスタンスを使用して新しいクラスターをデプロイすると、メトリックが正常に表示されます。 -3. アップグレード後、既存のクラスターを再起動してメトリクスアドレスを報告できます。1 `CLUSTER_NAME`実際のクラスター名に置き換えてください。 +3. アップグレード後、既存のクラスターを再起動してメトリクスアドレスを報告できます。`CLUSTER_NAME`実際のクラスター名に置き換えてください。 ```bash tiup cluster start CLUSTER_NAME diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 8326c879521f1..a17ff3634337a 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -42,8 +42,8 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー ![tidb\_execute node example1](/media/dashboard/dashboard-metrics-relation-node-example1.png) - `tidb_execute` 、TiDB 実行エンジンでの SQL クエリの実行期間を表す監視メトリックの名前です。 -- `19306.46s` 、メトリック`tidb_execute`の合計実行時間が 19306.46 秒であることを示します。4 `89.40%` 、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 -- `9070.18s` 、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。4 `42.00%` 、9070.18 秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 +- `19306.46s` 、メトリック`tidb_execute`の合計実行時間が 19306.46 秒であることを示します。`89.40%` 、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 +- `9070.18s` 、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。`42.00%` 、9070.18 秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 ボックス領域にマウスを移動すると、 `tidb_execute`メトリック ノードの詳細が表示されます。 diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 9890376254374..8ee9b25503f1b 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -133,7 +133,7 @@ server_configs: tiup cluster edit-config CLUSTER_NAME ``` -2. `server_configs`の`pd`設定の下にある設定項目を変更または追加します。5 `server_configs`存在しない場合は、最上位レベルに追加します。 +2. `server_configs`の`pd`設定の下にある設定項目を変更または追加します。`server_configs`存在しない場合は、最上位レベルに追加します。 ```yaml monitored: diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index d208ab115d40a..2d47b23b8c35a 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -93,7 +93,7 @@ DATE ### TIME型 {#code-time-code-type} -`TIME`型の場合、フォーマットは`HH:MM:SS[.fraction]`で、有効な値の範囲は '-838:59:59.000000' から '838:59:59.000000' です。5 `TIME` 、1 日の時刻だけでなく、2 つのイベント間の時間間隔も示します。オプションで 0 から 6 の範囲の`fsp`値を指定し、小数秒の精度を指定できます。省略した場合、デフォルトの精度は 0 です。 +`TIME`型の場合、フォーマットは`HH:MM:SS[.fraction]`で、有効な値の範囲は '-838:59:59.000000' から '838:59:59.000000' です。`TIME` 、1 日の時刻だけでなく、2 つのイベント間の時間間隔も示します。オプションで 0 から 6 の範囲の`fsp`値を指定し、小数秒の精度を指定できます。省略した場合、デフォルトの精度は 0 です。 ```sql TIME[(fsp)] @@ -125,7 +125,7 @@ TIMESTAMP[(fsp)] #### タイムゾーンの処理 {#timezone-handling} -`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。5 `TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 +`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。`TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。 > **警告：** > @@ -177,7 +177,7 @@ CREATE TABLE t1 ( `DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます`DATETIME`型または`TIMESTAMP`型の列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。 -- 小数精度をサポートする列を定義するには`type_name(fsp)`使用します。3 `type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 +- 小数精度をサポートする列を定義するには`type_name(fsp)`使用します。`type_name` `TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 ```sql CREATE TABLE t1 (t TIME(3), dt DATETIME(6)); @@ -185,7 +185,7 @@ CREATE TABLE t1 ( `fsp` 0 から 6 までの範囲でなければなりません。 - `0`小数部がないことを意味します。2 `fsp`省略した場合、デフォルトは0です。 + `0`小数部がないことを意味します。`fsp`省略した場合、デフォルトは0です。 - 小数部を含む`TIME` 、 `DATETIME` 、または`TIMESTAMP`挿入する場合、小数部の桁数が少なすぎる、または多すぎる場合は、四捨五入が必要になることがあります。例： diff --git a/data-type-default-values.md b/data-type-default-values.md index cdefc492e06a5..d96c71d63352b 100644 --- a/data-type-default-values.md +++ b/data-type-default-values.md @@ -27,9 +27,9 @@ summary: TiDB のデータ型のデフォルト値について学習します。 暗黙のデフォルトは次のように定義されます。 -- 数値型の場合、デフォルトは 0 です。1 `AUTO_INCREMENT`で宣言された場合、デフォルトはシーケンス内の次の値になります。 -- `TIMESTAMP`以外の日付と時刻型の場合、デフォルト値はその型に適切な「ゼロ」値です。3 `TIMESTAMP`場合、デフォルト値は現在の日付と時刻です。 -- `ENUM`以外の文字列型の場合、デフォルト値は空文字列です。3 `ENUM`場合、デフォルト値は最初の列挙値です。 +- 数値型の場合、デフォルトは 0 です。`AUTO_INCREMENT`で宣言された場合、デフォルトはシーケンス内の次の値になります。 +- `TIMESTAMP`以外の日付と時刻型の場合、デフォルト値はその型に適切な「ゼロ」値です。`TIMESTAMP`場合、デフォルト値は現在の日付と時刻です。 +- `ENUM`以外の文字列型の場合、デフォルト値は空文字列です。`ENUM`場合、デフォルト値は最初の列挙値です。 ## 式をデフォルト値として指定する {#specify-expressions-as-default-values} diff --git a/data-type-overview.md b/data-type-overview.md index ff5bff57b9f32..9d56fc7469c46 100644 --- a/data-type-overview.md +++ b/data-type-overview.md @@ -29,4 +29,4 @@ TiDBは[文字列型](/data-type-string.md) MySQLの`SPATIAL`型を除くすべ - `D`浮動小数点型と固定小数点型に適用され、小数点以下の桁数 (スケール) を示します。 -- `fsp` `TIME` 、 `DATETIME` 、 `TIMESTAMP`型に適用され、小数秒の精度を表します。8 `fsp`指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 +- `fsp` `TIME` 、 `DATETIME` 、 `TIMESTAMP`型に適用され、小数秒の精度を表します。`fsp`指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 diff --git a/data-type-string.md b/data-type-string.md index 05af978d4623b..24f908573038f 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -19,7 +19,7 @@ TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEX ### VARCHAR型 {#code-varchar-code-type} -`VARCHAR`は可変長の文字列です。Mは列の最大長（バイト数ではありません）を文字数で表します。2 `VARCHAR`最大サイズは65,535バイトを超えることはできません。4 `VARCHAR`長さは、行の最大長と使用されている文字セットによって決まります。 +`VARCHAR`は可変長の文字列です。Mは列の最大長（バイト数ではありません）を文字数で表します。`VARCHAR`最大サイズは65,535バイトを超えることはできません。`VARCHAR`長さは、行の最大長と使用されている文字セットによって決まります。 1文字が占めるスペースは、文字セットによって異なります。次の表は、1文字が消費するバイト数と、各文字セットにおける`VARCHAR`列の長さの範囲を示しています。 diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 27fc9f4c6bbc9..8a82d6c359e5a 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -45,7 +45,7 @@ v8.5.0以降、TiDBはインデックス間のヒューリスティック比較 `tidb_stats_update_during_ddl`が`ON`の場合、 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)実行すると、再編成フェーズの終了後に埋め込まれた`ANALYZE`操作が自動的に実行されます。この`ANALYZE`操作は、新しく作成されたインデックスがユーザーに表示される前に、その統計情報を収集し、その後`ADD INDEX`残りのフェーズに進みます。 -`ANALYZE`時間がかかる可能性があることを考慮して、TiDB は最初の Reorg の実行時間に基づいてタイムアウトしきい値を設定します。3 `ANALYZE`タイムアウトすると、 `ADD INDEX` `ANALYZE`完了を同期的に待つのをやめ、後続のプロセスを続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、インデックス統計は`ANALYZE`非同期的に完了した後に更新されます。 +`ANALYZE`時間がかかる可能性があることを考慮して、TiDB は最初の Reorg の実行時間に基づいてタイムアウトしきい値を設定します。`ANALYZE`タイムアウトすると、 `ADD INDEX` `ANALYZE`完了を同期的に待つのをやめ、後続のプロセスを続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、インデックス統計は`ANALYZE`非同期的に完了した後に更新されます。 例えば： diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 849f0068982c2..fc6c1b716d4ef 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -95,7 +95,7 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67 > > - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)実行します。 > -> - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。5 `@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 +> - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。`@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 サポートレベル:**フル** @@ -127,7 +127,7 @@ implementation 'mysql:mysql-connector-java:8.0.33' - Hibernate を使用してネイティブJavaで TiDB アプリケーションを構築する例については、 [TiDBとHibernateを使ったシンプルなCRUDアプリの構築](/develop/dev-guide-sample-application-java-hibernate.md)参照してください。 - Spring Data JPA または Hibernate を使用して Spring で TiDB アプリケーションを構築する例については、 [Spring Bootを使用してTiDBアプリを構築する](/develop/dev-guide-sample-application-java-spring-boot.md)参照してください。 -さらに、 [Hibernate設定ファイル](https://www.tutorialspoint.com/hibernate/hibernate_configuration.htm) : `org.hibernate.dialect.TiDBDialect`で TiDB 方言を指定する必要があります。これは Hibernate `6.0.0.Beta2`以降でのみサポートされます。7 `Hibernate`バージョンが`6.0.0.Beta2`より前の場合は、まずアップグレードしてください。 +さらに、 [Hibernate設定ファイル](https://www.tutorialspoint.com/hibernate/hibernate_configuration.htm) : `org.hibernate.dialect.TiDBDialect`で TiDB 方言を指定する必要があります。これは Hibernate `6.0.0.Beta2`以降でのみサポートされます。`Hibernate`バージョンが`6.0.0.Beta2`より前の場合は、まずアップグレードしてください。 > **注記：** > diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 3e4cf68bccf8d..b5878c9dcd35c 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -152,7 +152,7 @@ OLTP（オンライン・トランザクション処理）シナリオでは、 #### バッチAPIを使用する {#use-batch-api} -バッチ挿入の場合は、 [`addBatch` / `executeBatch` API](https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html#executeBatch())を使用できます。3 `addBatch()`は、複数の SQL ステートメントを最初にクライアントにキャッシュし、 `executeBatch`メソッドを呼び出すときにそれらをまとめてデータベースサーバーに送信するために使用されます。 +バッチ挿入の場合は、 [`addBatch` / `executeBatch` API](https://docs.oracle.com/en/java/javase/25/docs/api/java.sql/java/sql/Statement.html#executeBatch())を使用できます。`addBatch()`は、複数の SQL ステートメントを最初にクライアントにキャッシュし、 `executeBatch`メソッドを呼び出すときにそれらをまとめてデータベースサーバーに送信するために使用されます。 > **注記：** > @@ -256,7 +256,7 @@ INSERT INTO `t` (`a`) VALUES(12); INSERT INTO `t` (`a`) values(10),(11),(12); ``` -`INSERT`のステートメントの書き換えは、複数の「values」キーワードの後の値を連結して、1つのSQLステートメントにすることです。3 `INSERT`のステートメントに他の違いがある場合は、書き換えることはできません。たとえば、次のようになります。 +`INSERT`のステートメントの書き換えは、複数の「values」キーワードの後の値を連結して、1つのSQLステートメントにすることです。`INSERT`のステートメントに他の違いがある場合は、書き換えることはできません。たとえば、次のようになります。 ```sql INSERT INTO `t` (`a`) VALUES (10) ON DUPLICATE KEY UPDATE `a` = 10; diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index 11a2d98884efe..0ebb5cebe45e8 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-join-tables/','/ja/tidbcloud/dev-guide-join # 複数テーブルの結合クエリ {#multi-table-join-queries} -多くのシナリオでは、1つのクエリで複数のテーブルからデータを取得する必要があります。1 `JOIN`ステートメントを使用して、2つ以上のテーブルのデータを結合できます。 +多くのシナリオでは、1つのクエリで複数のテーブルからデータを取得する必要があります。`JOIN`ステートメントを使用して、2つ以上のテーブルのデータを結合できます。 ## 結合タイプ {#join-types} diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index bb19a3490b725..e491b1da6d86b 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -106,7 +106,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; +---------------------------+---------+-----------+-------------------------------------+-------------------------------------------------------+ ``` -実行プランの`IndexLookup_10`からわかるように、TiDBは`title_idx`番目のインデックスを使ってデータをクエリします。5 `estRows`の値は`1.27`です。これは、オプティマイザが`1.27`行しかスキャンされないと見積もっていることを意味します。推定されるスキャン行数は、フルテーブルスキャンの`1000000.00`行のデータよりもはるかに少ないです。 +実行プランの`IndexLookup_10`からわかるように、TiDBは`title_idx`番目のインデックスを使ってデータをクエリします。`estRows`の値は`1.27`です。これは、オプティマイザが`1.27`行しかスキャンされないと見積もっていることを意味します。推定されるスキャン行数は、フルテーブルスキャンの`1000000.00`行のデータよりもはるかに少ないです。 実行プラン`IndexLookup_10`では、まず`IndexRangeScan_8`演算子を使用して`title_idx`インデックスを通じて条件を満たすインデックス データを読み取り、次に`TableLookup_9`演算子を使用して、インデックス データに格納されている行 ID に従って対応する行をクエリします。 diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index 744013ef926e0..9c8edf7876089 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -130,7 +130,7 @@ try (Connection connection = ds.getConnection()) { ### INSERT例 {#code-insert-code-example} -[`books`](/develop/dev-guide-bookshop-schema-design.md#books-table)を例に挙げると、 `title = TiDB Developer Guide` 、 `type = Science & Technology` 、 `stock = 100` 、 `price = 0.0` 、 `published_at = NOW()` （挿入時の現在時刻）の書籍を挿入する必要があります。17 `books`の**主キー**に`AUTO_RANDOM`属性を指定する必要がないことに注意してください。データの挿入に関する詳細は、 [データの挿入](/develop/dev-guide-insert-data.md)参照してください。 +[`books`](/develop/dev-guide-bookshop-schema-design.md#books-table)を例に挙げると、 `title = TiDB Developer Guide` 、 `type = Science & Technology` 、 `stock = 100` 、 `price = 0.0` 、 `published_at = NOW()` （挿入時の現在時刻）の書籍を挿入する必要があります。`books`の**主キー**に`AUTO_RANDOM`属性を指定する必要がないことに注意してください。データの挿入に関する詳細は、 [データの挿入](/develop/dev-guide-insert-data.md)を参照してください。 diff --git a/develop/dev-guide-time-to-live.md b/develop/dev-guide-time-to-live.md index 1b7da027f2fa5..dbf06faebd259 100644 --- a/develop/dev-guide-time-to-live.md +++ b/develop/dev-guide-time-to-live.md @@ -38,7 +38,7 @@ CREATE TABLE app_messages ( ) TTL = `created_at` + INTERVAL 3 MONTH; ``` -この例では、 `TTL = ...`有効期限ポリシーを定義します。3 `created_at`には各行の作成時刻が記録され、 `INTERVAL 3 MONTH`各行が最大 3 か月間保持されることを指定します。 +この例では、 `TTL = ...`有効期限ポリシーを定義します。`created_at`には各行の作成時刻が記録され、 `INTERVAL 3 MONTH`各行が最大 3 か月間保持されることを指定します。 ### 既存のテーブルのTTL属性を構成する {#configure-the-ttl-attribute-for-an-existing-table} diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 333bccef7ece4..c763853b69bde 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -144,7 +144,7 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo - DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`実行します。 - 初期化構成ファイルは`topology.yaml`です。 - `--user root` : `root`キーを使用してターゲット マシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 -- `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。10 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 +- `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]` 、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。10 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 - TiUP DMは組み込みのSSHクライアントを使用します。制御マシンシステムにネイティブのSSHクライアントを使用する場合は、 [システムのネイティブSSHクライアントを使用してクラスターに接続する](/dm/maintain-dm-using-tiup.md#use-the-systems-native-ssh-client-to-connect-to-cluster)に従って設定を編集してください。 出力ログの最後に``Deployed cluster `dm-test` successfully``表示されます。これは、デプロイメントが成功したことを示します。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index b49df9298cdec..54ba9323b748c 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -141,7 +141,7 @@ alertmanager_servers: > - TiUPノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 > - TiUPノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 -`master_servers.host.config`パラメータの詳細については[マスターパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)を参照してください。5 `worker_servers.host.config`のパラメータの詳細については[ワーカーパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 +`master_servers.host.config`パラメータの詳細については[マスターパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)を参照してください。`worker_servers.host.config`のパラメータの詳細については[ワーカーパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 ## ステップ3: デプロイメントコマンドを実行する {#step-3-execute-the-deployment-command} diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 7689f54b6da30..60d70d821563d 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -65,7 +65,7 @@ validators: - `--mode` : 検証モードを指定します。指定できる値は`fast`と`full`です。 - `--start-time` : 検証の開始時刻を指定します。形式は`2021-10-21 00:01:00`または`2021-10-21T00:01:00`に従います。 -- `task` : 継続的検証を有効にするタスク名を指定します。2 `--all-task`指定すると、すべてのタスクに対して検証が有効になります。 +- `task` : 継続的検証を有効にするタスク名を指定します。`--all-task`指定すると、すべてのタスクに対して検証が有効になります。 例えば： diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 131fe19e62965..c275f61516804 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -158,7 +158,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 2. `stop-task`使用して移行タスクを停止します。 -3. グローバル チェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name` 、エラーのあるbinlogファイルの名前に更新します。5 `binlog_pos` 、移行が完了した有効な位置の値 (例: 4) に更新します。 +3. グローバル チェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name` 、エラーのあるbinlogファイルの名前に更新します。`binlog_pos` 、移行が完了した有効な位置の値 (例: 4) に更新します。 例：エラーが発生したタスクの名前が`dm_test` 、対応するタスク`source-id`が`replica-1` 、対応するbinlogファイルが`mysql-bin|000001.004451`場合、次のコマンドを実行します。 @@ -182,7 +182,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ #### 理由 {#reasons} -- MySQLクライアントとMySQL/TiDBサーバーの両方に`max_allowed_packet`クォータ制限があります。3 `max_allowed_packet`いずれかが制限を超えると、クライアントはエラーメッセージを受け取ります。現在、最新バージョンのDMとTiDBサーバーでは、デフォルト値は`max_allowed_packet`ではなく`64M`です。 +- MySQLクライアントとMySQL/TiDBサーバーの両方に`max_allowed_packet`クォータ制限があります。`max_allowed_packet`いずれかが制限を超えると、クライアントはエラーメッセージを受け取ります。現在、最新バージョンのDMとTiDBサーバーでは、デフォルト値は`max_allowed_packet`ではなく`64M`です。 - DM の完全データ インポート処理ユニットは、DM のダンプ処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 1129293e864ae..4383a585d873c 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -116,7 +116,7 @@ MySQLはエクスポート時にスナップショットを指定できないた 4. `start-task`を使用してタスクを開始します。 -5. `query-status`までタスクの状態を観察します。3 `syncerBinlog` `checkpoint-T`と`checkpoint-S`のうち大きい方の値を超えた場合、 `safe-mode`元の値に戻し、タスクを再開します。この例では`(mysql-bin.000100, 1234)`です。 +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} @@ -143,7 +143,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために 構成項目`block-allow-list`と`table-route`を確認します。 -- `block-allow-list`下にある上流のデータベースとテーブルの名前を設定する必要があります。3 `do-tables`前に「~」を追加すると、正規表現を使用して名前を一致させることができます。 +- `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} @@ -179,7 +179,7 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings ## 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} -まず、 `sql-skip`実行した後もbinlogの位置が進んでいるかどうかを確認する必要があります。進んでいる場合は、 `sql-skip`有効になっていることを意味します。このエラーが繰り返し発生する理由は、アップストリームがサポートされていない複数の DDL 文を送信しているためです。5 `sql-skip -s `使用して、これらの文に一致するパターンを設定できます。 +まず、 `sql-skip`実行した後もbinlogの位置が進んでいるかどうかを確認する必要があります。進んでいる場合は、 `sql-skip`有効になっていることを意味します。このエラーが繰り返し発生する理由は、アップストリームがサポートされていない複数の DDL 文を送信しているためです。`sql-skip -s `使用して、これらの文に一致するパターンを設定できます。 場合によっては、エラー メッセージに`parse statement`情報が含まれます。次に例を示します。 diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index 9b35617f3f4a9..85b6e12647a83 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -94,7 +94,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 ### セーフモード {#safe-mode} -セーフモードは、テーブルスキーマに主キーまたは一意インデックスが存在する場合に、DML文を複数回インポートできるモードです。このモードでは、上流の文の一部は、書き換えられた後にのみ下流に移行されます。1 `INSERT`文は`REPLACE`に書き換えられ、 `UPDATE`文は`DELETE`と`REPLACE`に書き換えられます。 +セーフモードは、テーブルスキーマに主キーまたは一意インデックスが存在する場合に、DML文を複数回インポートできるモードです。このモードでは、上流の文の一部は、書き換えられた後にのみ下流に移行されます。`INSERT`文は`REPLACE`に書き換えられ、 `UPDATE`文は`DELETE`と`REPLACE`に書き換えられます。 このモードは、次のいずれかの状況で有効になります。 diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index 7c5c39b9f4db1..fc1c2bb1686a8 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -47,7 +47,7 @@ DMのリレー処理ユニットは、binlogイベントをDMメモリに読み ### リレーログファイルを書き込む {#write-relay-log-files} -binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックは`write relay log duration`です。3 `binlog event size`大きすぎる場合は、この値はマイクロ秒単位にする必要があります。5 `write relay log duration`大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 +binlogイベントをリレーログファイルに書き込む場合、関連するパフォーマンスメトリックは`write relay log duration`です。`binlog event size`大きすぎる場合は、この値はマイクロ秒単位にする必要があります。`write relay log duration`大きすぎる場合は、ディスクの書き込みパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 ## 負荷ユニット {#load-unit} @@ -68,7 +68,7 @@ Binlogレプリケーションユニットは、設定に応じて、上流のMy - DM のBinlogレプリケーション処理ユニットがアップストリーム MySQL/MariaDB からbinlogイベントを読み取る場合、問題を特定して解決するには、「リレー ログ ユニット」セクションの[binlogデータを読み取る](#read-binlog-data)参照してください。 -- DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。5 `read binlog event duration`大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 +- DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。`read binlog event duration`大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 ### binlogイベント変換 {#binlog-event-conversion} @@ -90,7 +90,7 @@ DMはbinlogイベントからSQL文を構築した後、 `worker-count`キュー - データ移行リンクに顕著なレイテンシーが見られ、各`q_*`に対応する`DML queue remain length`の曲線がほぼ同じで、ほぼ常に0である場合、DMが上流からのデータの読み取り、変換、または同時書き込みを時間内に実行できていないことを意味します（ボトルネックはリレーログユニットにある可能性があります）。トラブルシューティングについては、このドキュメントの前のセクションを参照してください。 -`DML queue remain length`に対応する曲線が0でない場合（通常、最大値は1024以下）、下流へのSQL文の書き込み時にボトルネックが発生していることを示します。3 `transaction execution latency`使用すると、下流への単一トランザクションの実行に要した時間を表示できます。 +`DML queue remain length`に対応する曲線が0でない場合（通常、最大値は1024以下）、下流へのSQL文の書き込み時にボトルネックが発生していることを示します。`transaction execution latency`使用すると、下流への単一トランザクションの実行に要した時間を表示できます。 `transaction execution latency`は通常数十ミリ秒です。この値が大きすぎる場合は、下流データベースの監視に基づいて下流のパフォーマンスを確認してください。また、DMと下流データベース間のネットワークレイテンシーが大きくないか確認することもできます。 diff --git a/dm/dm-pause-task.md b/dm/dm-pause-task.md index abe974766cd79..8dc0b0f454994 100644 --- a/dm/dm-pause-task.md +++ b/dm/dm-pause-task.md @@ -9,7 +9,7 @@ summary: TiDB データ移行でデータ移行タスクを一時停止する方 `pause-task` `stop-task`次の点で異なります: -- `pause-task`移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。4 `stop-task`移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`使用してステータス情報を照会することはできません。「チェックポイント」のような`dm_meta`や、下流に移行済みのデータは削除されません。 +- `pause-task`移行タスクを一時停止するだけです。タスクのステータス情報（メモリに保持されている）は`query-status`で照会できます。`stop-task`移行タスクを終了し、このタスクに関連するすべての情報をメモリから削除します。つまり、 `query-status`使用してステータス情報を照会することはできません。「チェックポイント」のような`dm_meta`や、下流に移行済みのデータは削除されません。 - `pause-task`実行して移行タスクを一時停止した場合、同じ名前の新しいタスクを開始することはできません。また、一時停止したタスクは既に存在するため、そのタスクのリレーログを削除することもできません`stop-task`実行してタスクを停止した場合、同じ名前の新しいタスクを開始できます。また、停止したタスクは既に存在しないため、そのタスクのリレーログを削除することができます。 - `pause-task`は通常、トラブルシューティングのためにタスクを一時停止するために使用され、 `stop-task`は移行タスクを永続的に削除するか、 `start-task`と連携して構成情報を更新するために使用されます。 diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md index 2c58d5ee2be09..830928aacc069 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -89,7 +89,7 @@ mydumpers: #### テスト結果を取得する {#get-test-results} -DM-worker のログを確認してください。1 `all data files have been finished`表示されている場合は、すべてのデータがインポートされたことを意味します。この場合、データのインポートにかかった時間を確認できます。サンプルログは次のとおりです。 +DM-worker のログを確認してください。`all data files have been finished`表示されている場合は、すべてのデータがインポートされたことを意味します。この場合、データのインポートにかかった時間を確認できます。サンプルログは次のとおりです。 [INFO] [loader.go:604] ["all data files have been finished"] [task=test] [unit=load] ["cost time"=52.439796ms] diff --git a/dm/dm-tune-configuration.md b/dm/dm-tune-configuration.md index c2028727fbd71..f5246d7f8029e 100644 --- a/dm/dm-tune-configuration.md +++ b/dm/dm-tune-configuration.md @@ -13,7 +13,7 @@ summary: データ移行タスクの構成を最適化して、データ移行 ### `rows` {#rows} -`rows`オプションを設定すると、マルチスレッドを使用して単一テーブルから同時にデータをエクスポートできます。3 `rows`値は、エクスポートされる各チャンクに含まれる行の最大数です。このオプションを有効にすると、MySQL 単一テーブルのデータを同時にエクスポートする際に、DM は分割ベンチマークとして列を選択します。この列は、主キー列、一意インデックス列、通常のインデックス列（優先度の高いものから`BIGINT`ものの順）のいずれかになります。この列`MEDIUMINT`整数型（例： `INT` ）であることを確認してください。 +`rows`オプションを設定すると、マルチスレッドを使用して単一テーブルから同時にデータをエクスポートできます。`rows`値は、エクスポートされる各チャンクに含まれる行の最大数です。このオプションを有効にすると、MySQL 単一テーブルのデータを同時にエクスポートする際に、DM は分割ベンチマークとして列を選択します。この列は、主キー列、一意インデックス列、通常のインデックス列（優先度の高いものから`BIGINT`ものの順）のいずれかになります。この列`MEDIUMINT`整数型（例： `INT` ）であることを確認してください。 `rows`の値は 10000 まで設定できます。この値は、テーブルの総行数とデータベースのパフォーマンスに応じて変更できます。また、同時実行スレッド数を制御するには`threads`設定する必要があります。デフォルトでは`threads`の値は 4 です。この値は必要に応じて調整できます。 diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md index 72026224f846a..49a6a46d610fc 100644 --- a/dm/feature-online-ddl.md +++ b/dm/feature-online-ddl.md @@ -93,7 +93,7 @@ gh-ost で主に使用される SQL ステートメントとそれに対応す rename test._test4_gho to test.test4; ``` - - DMは`rename to _test4_del`を実行しません。3 `rename ghost_table to origin table`実行する場合、DMは以下の手順を実行します。 + - DMは`rename to _test4_del`を実行しません。`rename ghost_table to origin table`実行する場合、DMは以下の手順を実行します。 - ステップ3でメモリに記録されたDDLを読み取ります - `ghost_table`と`ghost_schema` `origin_table`とそれに対応するスキーマに置き換えます @@ -183,7 +183,7 @@ pt-osc で主に使用される SQL 文とそれに対応する DM の操作は rename test._test4_new to test.test4; ``` - - DMは`rename to _test4_old`を実行しません。3 `rename ghost_table to origin table`実行する場合、DMは以下の手順を実行します。 + - DMは`rename to _test4_old`を実行しません。`rename ghost_table to origin table`実行する場合、DMは以下の手順を実行します。 - ステップ2でメモリに記録されたDDLを読み取ります - `ghost_table`と`ghost_schema` `origin_table`とそれに対応するスキーマに置き換えます diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index cdc1324ab372e..83daca1c75510 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -21,7 +21,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル ## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} -楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。5 `strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)参照してください。 +楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。`strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)参照してください。 ## 制限 {#restrictions} @@ -48,7 +48,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル - デフォルト値のない`NOT NULL`列を追加します: `ALTER TABLE table_name ADD COLUMN column_1 NOT NULL;` 。 - インデックスの名前を変更します: `ALTER TABLE table_name RENAME INDEX index_1 TO index_2;` 。 -シャードテーブルが上記のDDL文を実行する際、 `strict-optimistic-shard-mode: true`設定されている場合はタスクが直接中断され、エラーが報告されます。3 `strict-optimistic-shard-mode: false`設定されている場合、または指定されていない場合は、シャードテーブル内のDDL文の実行順序が異なるため、移行が中断されます。例： +シャードテーブルが上記のDDL文を実行する際、 `strict-optimistic-shard-mode: true`設定されている場合はタスクが直接中断され、エラーが報告されます。`strict-optimistic-shard-mode: false`設定されている場合、または指定されていない場合は、シャードテーブル内のDDL文の実行順序が異なるため、移行が中断されます。例： - シャード 1 は列の名前を変更し、列の種類を変更します。 1. 列の名前を変更します: `ALTER TABLE table_name RENAME COLUMN column_1 TO column_2;` . diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 5b3fe240d2216..8d8f0a269543a 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -269,7 +269,7 @@ tiup dm import --dir=/path/to/dm-ansible --cluster-version ${version} ## 操作ログを確認する {#view-the-operation-log} -操作ログを表示するには、 `audit`コマンドを使用します。3 `audit`の使用方法は次のとおりです。 +操作ログを表示するには、 `audit`コマンドを使用します。`audit`の使用方法は次のとおりです。 ```bash Usage: @@ -299,7 +299,7 @@ tiup dm audit 4D5kQY ## DM クラスター内のホストでコマンドを実行する {#run-commands-on-a-host-in-the-dm-cluster} -DMクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 +DMクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。`exec`のコマンドの使用方法は次のとおりです。 ```bash Usage: diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index f8771f47b8b59..d301ff52e94b7 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -42,7 +42,7 @@ shard-ddl-lock -h -- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM マスターに要求します。2 `[command]`値として`unlock`のみを受け入れます。 +- `shard-ddl-lock [command]` : 指定された DDL ロックを解放するように DM マスターに要求します。`[command]`値として`unlock`のみを受け入れます。 ## 使用例 {#usage-examples} diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 7512c09d2b78a..f8d96e9863209 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -119,7 +119,7 @@ from: port: 3306 ``` -MySQL2データソースで、上記の設定を`conf/source2.yaml`にコピーします。3 `name` `mysql-replica-02`に変更し、 `password`と`port`適切な値に変更する必要があります。 +MySQL2データソースで、上記の設定を`conf/source2.yaml`にコピーします。`name` `mysql-replica-02`に変更し、 `password`と`port`適切な値に変更する必要があります。 ### ソースを作成する {#create-a-source} diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 21860767f77ab..a031400be6586 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -357,7 +357,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー ## ステップ5: データ複製を確認する {#step-5-verify-the-data-replication} -移行タスクを開始したら、データレプリケーションが期待どおりに動作しているかどうかを確認します。1 `dmctl`を使用してタスクのステータスを確認し、ターゲット TiDB データベースに接続して、ソース MySQL データベースからデータが正常に複製されていることを確認します。 +移行タスクを開始したら、データレプリケーションが期待どおりに動作しているかどうかを確認します。`dmctl`を使用してタスクのステータスを確認し、ターゲット TiDB データベースに接続して、ソース MySQL データベースからデータが正常に複製されていることを確認します。 1. TiDB DM タスクのステータスを確認します。 diff --git a/dm/relay-log.md b/dm/relay-log.md index 8046effb439ed..2f521e55c5778 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -88,7 +88,7 @@ stop-relay -s mysql-replica-01 worker1 worker2
-DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`チェックされます。3 `enable-relay` `true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 +DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`チェックされます。`enable-relay` `true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 設定項目`enable-relay`設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 diff --git a/dm/usage-scenario-master-slave-switch.md b/dm/usage-scenario-master-slave-switch.md index 7cce9a31bb1bd..ac632fefcf18e 100644 --- a/dm/usage-scenario-master-slave-switch.md +++ b/dm/usage-scenario-master-slave-switch.md @@ -30,7 +30,7 @@ DM-worker が仮想 IP (VIP) を介してアップストリーム MySQL イン 2. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_purged;`コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。これらのセットを`gtid-P`としてマークします。 3. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_executed;`コマンドを使用して、正常に実行されたすべてのトランザクションに対応するGTIDセットを取得します。これらのセットに`gtid-E`とマークを付けます。 4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。 - - `gtid-S`には`gtid-P`含まれます。4 `gtid-P`空になる場合があります。 + - `gtid-S`には`gtid-P`含まれます。`gtid-P`空になる場合があります。 - `gtid-E`には`gtid-S`含まれます。 5. `pause-task`使用すると、データ移行の実行中のすべてのタスクが一時停止されます。 6. 新しい MySQL インスタンスに直接送信されるように VIP を変更します。 @@ -44,7 +44,7 @@ DM-worker 設定を変更して、DM-worker をアップストリーム内の新 2. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_purged;`コマンドを使用して、削除されたバイナリログに対応するGTIDセットを取得します。このセットを`gtid-P`としてマークします。 3. 新しいMySQLインスタンスで`SELECT @@GLOBAL.gtid_executed;`コマンドを使用して、正常に実行されたすべてのトランザクションに対応するGTIDセットを取得します。これらのセットを`gtid-E`としてマークします。 4. 以下の条件が満たされていることを確認してください。満たされていない場合、DM-work 接続を新しい MySQL インスタンスに切り替えることはできません。 - - `gtid-S`には`gtid-P`含まれます。4 `gtid-P`空になる場合があります。 + - `gtid-S`には`gtid-P`含まれます。`gtid-P`空になる場合があります。 - `gtid-E`には`gtid-S`含まれます。 5. `stop-task`使用すると、データ移行の実行中のタスクがすべて停止します。 6. `operator-source stop`コマンドを使用して、古い MySQL インスタンスのアドレスに対応するソース構成を DM クラスターから削除します。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 44d182539271f..4669a02dbb4b4 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -185,7 +185,7 @@ nohup ./minio server ./data --address :6060 & +----------------------+----------+--------------------+---------------------+---------------------+ 1 row in set (2.11 sec) - `BACKUP`のステートメントが実行されると、TiDBはバックアップデータに関するメタデータを返します。3 `BackupTS`のステートメントには注意してください。これは、バックアップ前に生成されたデータが含まれているためです。このドキュメントでは、 `BackupTS`**を増分マイグレーションの開始**として使用します。 + `BACKUP`のステートメントが実行されると、TiDBはバックアップデータに関するメタデータを返します。`BackupTS`のステートメントには注意してください。これは、バックアップ前に生成されたデータが含まれているためです。このドキュメントでは、 `BackupTS`**を増分マイグレーションの開始**として使用します。 3. データの復元。セカンダリクラスタで以下のステートメント`RESTORE`を実行してデータを復元します。 diff --git a/dynamic-config.md b/dynamic-config.md index d0fd7c54a36ee..cac05541c9f52 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -103,7 +103,7 @@ show warnings; 1 row in set (0.00 sec) ``` -バッチ変更はアトミック性を保証するものではありません。一部のインスタンスでは変更が成功し、他のインスタンスでは失敗する可能性があります。1 `set tikv key=val`使用して TiKV クラスター全体の設定を変更すると、一部のインスタンスで変更が失敗する可能性があります。3 `show warnings`使用して結果を確認できます。 +バッチ変更はアトミック性を保証するものではありません。一部のインスタンスでは変更が成功し、他のインスタンスでは失敗する可能性があります。`set tikv key=val`使用して TiKV クラスター全体の設定を変更すると、一部のインスタンスで変更が失敗する可能性があります。`show warnings`使用して結果を確認できます。 一部の変更が失敗した場合は、対応するステートメントを再実行するか、失敗したインスタンスを個別に変更する必要があります。ネットワークの問題やマシンの障害により一部のTiKVインスタンスにアクセスできない場合は、復旧後にこれらのインスタンスを変更してください。 diff --git a/encryption-at-rest.md b/encryption-at-rest.md index fd72cf4f465b4..3d6e9f1ff9110 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -123,7 +123,7 @@ AWS KMS を使用してマスターキーを指定するには、TiKV 設定フ region = "us-west-2" endpoint = "https://kms.us-west-2.amazonaws.com" -`key-id` KMS CMK のキー ID を指定します。3 `region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)使用する必要がある場合を除き、通常は指定する必要はありません。 +`key-id` KMS CMK のキー ID を指定します。`region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)使用する必要がある場合を除き、通常は指定する必要はありません。 AWSでも[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)使用できます。この場合、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。 @@ -303,7 +303,7 @@ AWS でキーを作成するには、TiKV のキーを作成する手順を参 security.encryption.data-encryption-method: "aes128-ctr" security.encryption.data-key-rotation-period: "168h" # 7 days -`data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。3 `data-key-rotation-period` 、 TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`サポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 +`data-encryption-method`に指定できる値は、「aes128-ctr」、「aes192-ctr」、「aes256-ctr」、「sm4-ctr」（v6.4.0 以降のみ）、「plaintext」です。デフォルト値は「plaintext」で、暗号化は無効です。`data-key-rotation-period` 、 TiFlash がデータキーをローテーションする頻度を定義します。暗号化は、新規TiFlashクラスターまたは既存のTiFlashクラスターで有効にできますが、暗号化が有効になった後に書き込まれたデータのみが暗号化されることが保証されます。暗号化を無効にするには、設定ファイルの`data-encryption-method`削除するか、「plaintext」にリセットし、 TiFlashを再起動します。暗号化方式を変更するには、設定ファイルの`data-encryption-method`更新し、 TiFlash を再起動します。暗号化アルゴリズムを変更するには、 `data-encryption-method`サポートされている暗号化アルゴリズムに置き換え、 TiFlash を再起動します。置き換え後、新しいデータが書き込まれると、以前の暗号化アルゴリズムで生成された暗号化ファイルは、新しい暗号化アルゴリズムで生成されたファイルに徐々に書き換えられます。 暗号化が有効になっている場合（つまり、 `data-encryption-method` 「プレーンテキスト」ではない場合）、マスターキーを指定する必要があります。AWS KMS CMK をマスターキーとして指定するには、 `tiflash-learner.toml`設定ファイルの`encryption`セクションの後に`encryption.master-key`セクションを追加します。 diff --git a/error-codes.md b/error-codes.md index 0c2a66dcdf2a4..46f40ea33650f 100644 --- a/error-codes.md +++ b/error-codes.md @@ -121,15 +121,15 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8032 - 無効な`year`形式が使用されています。3 `year` 1 桁、2 桁、または 4 桁のみを受け入れます。 + 無効な`year`形式が使用されています。`year` 1 桁、2 桁、または 4 桁のみを受け入れます。 - エラー番号: 8033 - 無効な値`year`が使用されています。3 `year`有効範囲は(1901, 2155)です。 + 無効な値`year`が使用されています。`year`有効範囲は(1901, 2155)です。 - エラー番号: 8037 - `week`関数で無効な`mode`形式が使用されています。5 `mode` [0, 7] 以内の 1 桁の数字でなければなりません。 + `week`関数で無効な`mode`形式が使用されています。`mode` [0, 7] 以内の 1 桁の数字でなければなりません。 - エラー番号: 8038 @@ -357,7 +357,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8154 - 現在、 `LOAD DATA` TiDBサーバーからのローカルデータのインポートをサポートしていません。3 `LOCAL`指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。5 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 + 現在、 `LOAD DATA` TiDBサーバーからのローカルデータのインポートをサポートしていません。`LOCAL`指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。5 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 - エラー番号: 8156 diff --git a/explain-index-merge.md b/explain-index-merge.md index 27ae22d47cb8c..65c0e95dd57b2 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -84,7 +84,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > - 3 つのフィルタ条件のそれぞれについて、それぞれの選択性は非常に高いため、単一のインデックスを使用した`IndexLookUp`の実行効率は理想的ではありません。 - 3 つのフィルター条件の全体的な選択性は低いです。 -交差型インデックスマージを使用してテーブルにアクセスする場合、オプティマイザはテーブルに対して複数のインデックスを使用し、各インデックスから返される結果をマージして、前述の出力例の`IndexMerge`の実行プランを生成することができます。7 `IndexMerge_9`の演算子の`operator info`の情報`type: intersection`は、この演算子が交差型インデックスマージであることを示しています。実行プランのその他の部分は、前述のユニオン型インデックスマージの例と同様です。 +交差型インデックスマージを使用してテーブルにアクセスする場合、オプティマイザはテーブルに対して複数のインデックスを使用し、各インデックスから返される結果をマージして、前述の出力例の`IndexMerge`の実行プランを生成することができます。`IndexMerge_9`の演算子の`operator info`の情報`type: intersection`は、この演算子が交差型インデックスマージであることを示しています。実行プランのその他の部分は、前述のユニオン型インデックスマージの例と同様です。 > **注記：** > diff --git a/explain-indexes.md b/explain-indexes.md index 7ec1a7286619c..858e49c6b89fd 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -247,7 +247,7 @@ EXPLAIN SELECT MAX(intkey) FROM t1; 5 rows in set (0.00 sec) ``` -上記の文では、各TiKVリージョンに対してタスク`IndexFullScan`が実行されます。3 `FullScan`名前にもかかわらず、読み取る必要があるのは最初の行（ `└─Limit_28` ）のみです。各TiKVリージョンは`MIN`または`MAX`値をTiDBに返し、TiDBはストリーム集計を実行して単一行をフィルタリングします。また、集約関数`MAX`または`MIN`使用したストリーム集計により、テーブルが空の場合に`NULL`返されることも保証されます。 +上記の文では、各TiKVリージョンに対してタスク`IndexFullScan`が実行されます。`FullScan`名前にもかかわらず、読み取る必要があるのは最初の行（ `└─Limit_28` ）のみです。各TiKVリージョンは`MIN`または`MAX`値をTiDBに返し、TiDBはストリーム集計を実行して単一行をフィルタリングします。また、集約関数`MAX`または`MIN`使用したストリーム集計により、テーブルが空の場合に`NULL`返されることも保証されます。 対照的に、インデックスなしの値に対して関数`MIN`実行すると、結果は`TableFullScan`になります。このクエリではTiKV内のすべての行をスキャンする必要がありますが、各TiKVリージョンがTiDBに1行のみを返すように、 `TopN`計算が実行されます。 `TopN` TiKVとTiDB間で過剰な行が転送されるのを防ぎますが、この文は、インデックスを利用できる上記の例`MIN`よりもはるかに効率が悪いと考えられます。 diff --git a/explain-overview.md b/explain-overview.md index 9200644202fb0..3053e5958bbc7 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -7,7 +7,7 @@ summary: TiDB の EXPLAIN` ステートメントによって返される実行 > **注記：** > -> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。3 `EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 +> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。`EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 SQLは宣言型言語です。クエリの結果がどのようになるべきかを記述するものであり、実際に結果を取得する**方法論**を記述するものではありません。TiDBは、テーブルを結合する順序や、インデックスの使用可能性など、クエリの実行方法の可能性をすべて考慮します。*クエリ実行プランを検討する*プロセスは、SQL最適化と呼ばれます。 @@ -35,7 +35,7 @@ Records: 2 Duplicates: 0 Warnings: 0 3 rows in set (0.00 sec) ``` -`EXPLAIN`実際のクエリを実行しません。2 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)クエリを実行し、 `EXPLAIN`情報を表示します。これは、選択された実行プランが最適ではないケースを診断するのに役立ちます。6 `EXPLAIN`使用例については、以下のドキュメントをご覧ください。 +`EXPLAIN`実際のクエリを実行しません。2 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)クエリを実行し、 `EXPLAIN`情報を表示します。これは、選択された実行プランが最適ではないケースを診断するのに役立ちます。`EXPLAIN`使用例については、以下のドキュメントをご覧ください。 - [インデックス](/explain-indexes.md) - [テーブル結合](/explain-joins.md) @@ -141,8 +141,8 @@ TiDBは、TiKV/ TiFlashからスキャンされたデータまたは計算結果 - **TableReader** : TiKV の`TableFullScan`や`TableRangeScan`の基礎となる演算子によって取得されたデータを集計します。 - **IndexReader** : TiKV の`IndexFullScan`や`IndexRangeScan`の基礎となる演算子によって取得されたデータを集計します。 -- **IndexLookUp** : まず、 `Build`側でスキャンされたRowID（TiKV内）を集計します。次に、 `Probe`側でこれらのRowIDに基づいてTiKVからデータを正確に読み取ります。6 `Build`には`IndexFullScan`や`IndexRangeScan`などの演算子があり、 `Probe`側には`TableRowIDScan`演算子があります。 -- **IndexMerge** : `IndexLookUp`と同様です。4 `IndexMerge` `IndexLookupReader`の拡張と見なすことができます。8 `IndexMerge`複数のインデックスの同時読み取りをサポートします。10 は`Build`あり、 `Probe`は1つです。14 の実行プロセスは`IndexMerge` `IndexLookUp`同じです。 +- **IndexLookUp** : まず、 `Build`側でスキャンされたRowID（TiKV内）を集計します。次に、 `Probe`側でこれらのRowIDに基づいてTiKVからデータを正確に読み取ります。`Build`には`IndexFullScan`や`IndexRangeScan`などの演算子があり、 `Probe`側には`TableRowIDScan`演算子があります。 +- **IndexMerge** : `IndexLookUp`と同様です。`IndexMerge` `IndexLookupReader`の拡張と見なすことができます。`IndexMerge`複数のインデックスの同時読み取りをサポートします。10 は`Build`あり、 `Probe`は1つです。14 の実行プロセスは`IndexMerge` `IndexLookUp`同じです。 構造はツリー構造のように見えますが、クエリの実行において子ノードが親ノードより先に完了している必要は必ずしもありません。TiDBはクエリ内並列処理をサポートしているため、より正確な表現は、子ノードが親ノード*に流れ込む*というものです。親ノード、子ノード、兄弟ノードの演算子によって、クエリの一部が並列実行される可能性*があります*。 @@ -172,6 +172,6 @@ SQL最適化の目標の一つは、計算を可能な限りTiKVに委ねるこ - `range: [1,1]` 、クエリのwhere句の述語（ `a = 1` ）がTiKV（タスクは`cop[tikv]` ）にプッシュダウンされたことを示しています。 - `keep order:false` 、このクエリのセマンティクスでは TiKV が結果を順番に返す必要がないことを示しています。クエリが順序付けを必要とするように変更された場合（例えば`SELECT * FROM t WHERE a = 1 ORDER BY id` ）、この条件は`keep order:true`になります。 -- `stats:pseudo` 、 `estRows`に示されている推定値が正確ではない可能性があることを示しています。TiDB はバックグラウンド処理の一環として定期的に統計を更新します。4 `ANALYZE TABLE t`実行して手動で更新することもできます。 +- `stats:pseudo` 、 `estRows`に示されている推定値が正確ではない可能性があることを示しています。TiDB はバックグラウンド処理の一環として定期的に統計を更新します。`ANALYZE TABLE t`実行して手動で更新することもできます。 `EXPLAIN`文の実行後、異なる演算子は異なる情報を出力します。オプティマイザヒントを使用してオプティマイザの動作を制御し、それによって物理演算子の選択を制御できます。例えば、 `/*+ HASH_JOIN(t1, t2) */`オプティマイザが`Hash Join`アルゴリズムを使用することを意味します。詳細については、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 diff --git a/explain-subqueries.md b/explain-subqueries.md index 6e8e14aadad99..1d7b49f6b0f6b 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -47,7 +47,7 @@ ANALYZE TABLE t1, t2, t3; ## 内部結合（一意でないサブクエリ） {#inner-join-non-unique-subquery} -次の例では、 `IN`サブクエリがテーブル`t2`からIDのリストを検索します。セマンティクスの正確性を保つため、TiDBは列`t1_id`一意であることを保証する必要があります。7 `EXPLAIN`のサブクエリを使用すると、重複を削除して`INNER JOIN`操作を実行するための実行プランを確認できます。 +次の例では、 `IN`サブクエリがテーブル`t2`からIDのリストを検索します。セマンティクスの正確性を保つため、TiDBは列`t1_id`一意であることを保証する必要があります。`EXPLAIN`のサブクエリを使用すると、重複を削除して`INNER JOIN`操作を実行するための実行プランを確認できます。 ```sql EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); diff --git a/explain-walkthrough.md b/explain-walkthrough.md index 5222c35d625e1..60a6b8e4930ef 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -118,7 +118,7 @@ SHOW STATS_HEALTHY; - TiDB ( `StreamAgg_20` )とTiKV ( `└─StreamAgg_9` )の両方で行数を集計するには、メモリ使用量の面で非常に効率的なストリーム集計を使用します。 -現在の実行プランの最大の問題は、述語`start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'`すぐに適用されないことです。まず演算子`TableFullScan`ですべての行が読み込まれ、その後選択が適用されます。5 `SHOW CREATE TABLE trips`出力から原因がわかります。 +現在の実行プランの最大の問題は、述語`start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'`すぐに適用されないことです。まず演算子`TableFullScan`ですべての行が読み込まれ、その後選択が適用されます。`SHOW CREATE TABLE trips`出力から原因がわかります。 ```sql SHOW CREATE TABLE trips\G diff --git a/extended-statistics.md b/extended-statistics.md index d2aabaa5ccfc2..8e789c1c00955 100644 --- a/extended-statistics.md +++ b/extended-statistics.md @@ -156,4 +156,4 @@ SELECT * FROM t WHERE col1 <= 1 OR col1 IS NULL; 前のクエリ結果に1を加えたものが、最終的な行数の推定値となります。これにより、独立仮定を用いる必要がなくなり、**大きな推定誤差を回避できます**。 -相関係数（この例では`1` ）がシステム変数`tidb_opt_correlation_threshold`の値より小さい場合、オプティマイザは独立仮定を使用しますが、ヒューリスティックに推定値も増加させます。5 `tidb_opt_correlation_exp_factor`値が大きいほど、推定結果は大きくなります。相関係数の絶対値が大きいほど、推定結果は大きくなります。 +相関係数（この例では`1` ）がシステム変数`tidb_opt_correlation_threshold`の値より小さい場合、オプティマイザは独立仮定を使用しますが、ヒューリスティックに推定値も増加させます。`tidb_opt_correlation_exp_factor`値が大きいほど、推定結果は大きくなります。相関係数の絶対値が大きいほど、推定結果は大きくなります。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 63482d8ba1d96..f887a16539416 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -51,7 +51,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ### TiDB でスロークエリログを個別に記録するにはどうすればよいですか? スロークエリの SQL ステートメントを見つけるにはどうすればよいでしょうか? {#how-to-separately-record-the-slow-query-log-in-tidb-how-to-locate-the-slow-query-sql-statement} -1. TiDBのスロークエリの定義は、TiDB設定ファイルにあります。1 `tidb_slow_log_threshold: 300`は、スロークエリのしきい値（単位：ミリ秒）を設定するために使用されます。 +1. TiDBのスロークエリの定義は、TiDB設定ファイルにあります。`tidb_slow_log_threshold: 300`は、スロークエリのしきい値（単位：ミリ秒）を設定するために使用されます。 2. スロークエリが発生した場合、Grafana を使用してスロークエリが発生している`tidb-server`インスタンスとスロークエリの時刻を特定し、該当ノードのログに記録された SQL 文の情報を見つけることができます。 diff --git a/faq/monitor-faq.md b/faq/monitor-faq.md index 676c6b5bc567a..8064ab911eb18 100644 --- a/faq/monitor-faq.md +++ b/faq/monitor-faq.md @@ -22,7 +22,7 @@ TiDBの監視システムは、PrometheusとGrafanaで構成されています ## リージョンヘルスモニター {#region-health-monitor} -TiDB 2.0では、リージョンの健全性はPDメトリック監視ページで監視されます。監視項目`Region Health`には、すべてのリージョンレプリカのステータスの統計が表示されます。3 `miss`レプリカ不足、 `extra`レプリカが不足していることを示します。さらに、 `Region Health`分離レベル`label`も示します。11 `level-1` 、リージョンレプリカが最初の`label`レベルで物理的に分離されていることを示します。17 `location label`設定されていない場合、すべてのリージョンは`level-0`になります。 +TiDB 2.0では、リージョンの健全性はPDメトリック監視ページで監視されます。監視項目`Region Health`には、すべてのリージョンレプリカのステータスの統計が表示されます。`miss`レプリカ不足、 `extra`レプリカが不足していることを示します。さらに、 `Region Health`分離レベル`label`も示します。11 `level-1` 、リージョンレプリカが最初の`label`レベルで物理的に分離されていることを示します。17 `location label`設定されていない場合、すべてのリージョンは`level-0`になります。 ## ステートメントカウントモニターのselectsimplefullの意味は何ですか? {#what-is-the-meaning-of-code-selectsimplefull-code-in-statement-count-monitor} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index b9a0bf480b590..7ee886cf79319 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -194,7 +194,7 @@ TiDBはマルチバージョン同時実行制御（MVCC）を使用している TiDB `SHOW PROCESSLIST`の表示内容は MySQL `SHOW PROCESSLIST`とほぼ同じです。TiDB `SHOW PROCESSLIST`ではシステムプロセスIDが表示されません。表示されるのは現在のセッションIDです。TiDB `SHOW PROCESSLIST`と MySQL `SHOW PROCESSLIST`の違いは次のとおりです。 -- TiDBは分散データベースであるため、 `tidb-server`インスタンスはSQL文を解析および実行するためのステートレスエンジンです（詳細は[TiDBアーキテクチャ](/tidb-architecture.md)を参照）。5 `SHOW PROCESSLIST` 、ユーザーがMySQLクライアントからログインした`tidb-server`インスタンスで実行されたセッションリストを表示します。クラスタ内で実行されているすべてのセッションのリストではありません。ただし、MySQLはスタンドアロンデータベースであり、 `SHOW PROCESSLIST`はMySQLで実行されたすべてのSQL文を表示します。 +- TiDBは分散データベースであるため、 `tidb-server`インスタンスはSQL文を解析および実行するためのステートレスエンジンです（詳細は[TiDBアーキテクチャ](/tidb-architecture.md)を参照）。`SHOW PROCESSLIST` 、ユーザーがMySQLクライアントからログインした`tidb-server`インスタンスで実行されたセッションリストを表示します。クラスタ内で実行されているすべてのセッションのリストではありません。ただし、MySQLはスタンドアロンデータベースであり、 `SHOW PROCESSLIST`はMySQLで実行されたすべてのSQL文を表示します。 - TiDBの`State`列は、クエリ実行中に継続的に更新されるわけではありません。TiDBは並列クエリをサポートしているため、各ステートメントが複数の*状態*にある場合があり、単一の値に単純化することが困難です。 ## SQL コミットの実行優先度を制御または変更するにはどうすればよいですか? {#how-to-control-or-change-the-execution-priority-of-sql-commits} @@ -439,7 +439,7 @@ ADMIN SHOW DDL; - `ADMIN SHOW DDL` : 実行中のDDLジョブを表示する - `ADMIN SHOW DDL JOBS` : 現在の DDL ジョブ キュー内のすべての結果 (実行中および実行待ちのタスクを含む) と、完了した DDL ジョブ キューの最後の 10 件の結果を表示します。 -- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...` : `job_id`に対応する DDL タスクの元の SQL ステートメントを表示します。4 `job_id`実行中の DDL ジョブと DDL 履歴ジョブ キュー内の最後の 10 件の結果のみを検索します。 +- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...` : `job_id`に対応する DDL タスクの元の SQL ステートメントを表示します。`job_id`実行中の DDL ジョブと DDL 履歴ジョブ キュー内の最後の 10 件の結果のみを検索します。 ### TiDB は CBO (コストベース最適化) をサポートしていますか? サポートしている場合、どの程度サポートしていますか? {#does-tidb-support-cbo-cost-based-optimization-if-yes-to-what-extent} @@ -457,9 +457,9 @@ ADMIN SHOW DDL; 現在、 TiDB のコンピューティング タスクは、タスク`cop task`と`root task`の 2 つの異なるタイプに属しています。 -`cop task`は、分散実行のために KV エンドにプッシュダウンされるコンピューティング タスクです。2 `root task` 、TiDB エンドでの単一ポイント実行のためのコンピューティング タスクです。 +`cop task`は、分散実行のために KV エンドにプッシュダウンされるコンピューティング タスクです。`root task` 、TiDB エンドでの単一ポイント実行のためのコンピューティング タスクです。 -通常、 `root task`の入力データは`cop task`から取得されます。5 `root task`データを処理している間、TiKVの`cop task`同時にデータを処理し、TiDBの`root task`からのプルを待機します。したがって、 `cop`タスクは`root task`と並行して実行されていると見なすことができますが、それらのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間並行して実行されます。たとえば、最初の`cop task`は[100, 200]のデータを処理し、2番目の`cop task`は[1, 100]のデータを処理します。詳細は[TiDBクエリプランの理解](/explain-overview.md)参照してください。 +通常、 `root task`の入力データは`cop task`から取得されます。`root task`データを処理している間、TiKVの`cop task`同時にデータを処理し、TiDBの`root task`からのプルを待機します。したがって、 `cop`タスクは`root task`と並行して実行されていると見なすことができますが、それらのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間並行して実行されます。たとえば、最初の`cop task`は[100, 200]のデータを処理し、2番目の`cop task`は[1, 100]のデータを処理します。詳細は[TiDBクエリプランの理解](/explain-overview.md)参照してください。 ## データベースの最適化 {#database-optimization} diff --git a/filter-dml-event.md b/filter-dml-event.md index 711a51c0ef5ab..119af2281ee66 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -41,7 +41,7 @@ expression-filter: INSERT INTO tbl(id, c) VALUES (1, 1), (2, 2), (3, 3), (4, 4); ``` -次に、下流のテーブル`tb1`に対してクエリを実行します。3 `c`奇数行のみがレプリケートされていることがわかります。 +次に、下流のテーブル`tb1`に対してクエリを実行します。`c`奇数行のみがレプリケートされていることがわかります。 ```sql MySQL [test]> select * from tbl; @@ -71,7 +71,7 @@ MySQL [test]> select * from tbl; SQL式は1つの列でも複数の列でも使用できます。また、TiDBでサポートされているSQL関数（ `c % 2 = 0` 、 `a*a + b*b = c*c` 、 `ts > NOW()`など）も使用できます。 -`TIMESTAMP`デフォルトタイムゾーンは、タスク設定ファイルで指定されたタイムゾーンです。デフォルト値はダウンストリームのタイムゾーンです。3 `c_timestamp = '2021-01-01 12:34:56.5678+08:00'`ように明示的にタイムゾーンを指定することもできます。 +`TIMESTAMP`デフォルトタイムゾーンは、タスク設定ファイルで指定されたタイムゾーンです。デフォルト値はダウンストリームのタイムゾーンです。`c_timestamp = '2021-01-01 12:34:56.5678+08:00'`ように明示的にタイムゾーンを指定することもできます。 `expression-filter`設定項目で複数のフィルタリングルールを設定できます。上流データソースは、 `expression-filters`の必要なルールを参照してルールを有効にします。複数のルールを使用する場合、**いずれ**かのルールに一致すると、行の変更全体がフィルタリングされます。 diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index 5336e0f6624bb..124c2244c9328 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -61,7 +61,7 @@ summary: TiDB でサポートされている集計関数について学習しま - `APPROX_COUNT_DISTINCT(expr, [expr...])` - この関数は、異なる値の数を数える点では`COUNT(DISTINCT)`に似ていますが、近似値を返します。3 `BJKST`アルゴリズムを使用することで、べき乗分布を持つ大規模なデータセットを処理する際のメモリ消費量を大幅に削減します。さらに、低カーディナリティデータの場合、この関数はCPU使用率を効率的に維持しながら高い精度を実現します。 + この関数は、異なる値の数を数える点では`COUNT(DISTINCT)`に似ていますが、近似値を返します。`BJKST`アルゴリズムを使用することで、べき乗分布を持つ大規模なデータセットを処理する際のメモリ消費量を大幅に削減します。さらに、低カーディナリティデータの場合、この関数はCPU使用率を効率的に維持しながら高い精度を実現します。 次の例は、この関数の使用方法を示しています。 @@ -91,7 +91,7 @@ TiDB v7.4.0以降、 `GROUP BY`句は`WITH ROLLUP`修飾子をサポートしま ## SQLモードのサポート {#sql-mode-support} -TiDBはSQLモード`ONLY_FULL_GROUP_BY`をサポートしており、有効にすると、曖昧な非集計列を含むクエリを拒否します。例えば、次のクエリは`ONLY_FULL_GROUP_BY`が有効になっていると無効になります。5 `SELECT`のリストにある非集計列「b」が`GROUP BY`ステートメントに含まれていないためです。 +TiDBはSQLモード`ONLY_FULL_GROUP_BY`をサポートしており、有効にすると、曖昧な非集計列を含むクエリを拒否します。例えば、次のクエリは`ONLY_FULL_GROUP_BY`が有効になっていると無効になります。`SELECT`のリストにある非集計列「b」が`GROUP BY`ステートメントに含まれていないためです。 ```sql drop table if exists t; diff --git a/functions-and-operators/cast-functions-and-operators.md b/functions-and-operators/cast-functions-and-operators.md index 82d5db3398594..60357b2748fcc 100644 --- a/functions-and-operators/cast-functions-and-operators.md +++ b/functions-and-operators/cast-functions-and-operators.md @@ -15,7 +15,7 @@ summary: キャスト関数と演算子について学習します。 > **注記：** > -> TiDBとMySQLは、 `SELECT CAST(MeN AS CHAR)` （またはそれに相当する`SELECT CONVERT(MeM, CHAR)` ）の結果に一貫性がありません。5 `MeN`倍精度浮動小数点数（科学的記数法）を表します。MySQLは`-15 <= N <= 14`場合は完全な数値を表示し、 `N < -15`または`N > 14`場合は科学的記数法を表示します。しかし、TiDBは常に完全な数値を表示します。例えば、MySQLでは`SELECT CAST(3.1415e15 AS CHAR)`の結果を`3.1415e15`と表示しますが、TiDBでは`3141500000000000`と表示します。 +> TiDBとMySQLは、 `SELECT CAST(MeN AS CHAR)` （またはそれに相当する`SELECT CONVERT(MeM, CHAR)` ）の結果に一貫性がありません。`MeN`倍精度浮動小数点数（科学的記数法）を表します。MySQLは`-15 <= N <= 14`場合は完全な数値を表示し、 `N < -15`または`N > 14`場合は科学的記数法を表示します。しかし、TiDBは常に完全な数値を表示します。例えば、MySQLでは`SELECT CAST(3.1415e15 AS CHAR)`の結果を`3.1415e15`と表示しますが、TiDBでは`3141500000000000`と表示します。 ## バイナリ {#binary} diff --git a/functions-and-operators/control-flow-functions.md b/functions-and-operators/control-flow-functions.md index 4090a510fb3aa..f5e072de0b8d3 100644 --- a/functions-and-operators/control-flow-functions.md +++ b/functions-and-operators/control-flow-functions.md @@ -87,7 +87,7 @@ SELECT n, IF(n MOD 2, "odd", "even") FROM d; ## IFNULL() {#ifnull} -[`IFNULL(expr1,expr2)`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull)関数は、クエリ内の NULL 値を処理するために使用されます。3 `expr1` `NULL`でない場合は`expr1`返し、そうでない場合は`expr2`返します。 +[`IFNULL(expr1,expr2)`](https://dev.mysql.com/doc/refman/8.0/en/flow-control-functions.html#function_ifnull)関数は、クエリ内の NULL 値を処理するために使用されます。`expr1` `NULL`でない場合は`expr1`返し、そうでない場合は`expr2`返します。 例： diff --git a/functions-and-operators/encryption-and-compression-functions.md b/functions-and-operators/encryption-and-compression-functions.md index 69c557247a5cf..b4ec073bde0f5 100644 --- a/functions-and-operators/encryption-and-compression-functions.md +++ b/functions-and-operators/encryption-and-compression-functions.md @@ -185,7 +185,7 @@ SELECT SHA1('abc'); ### `SHA2()` {#sha2} -`SHA2(str, n)`関数は`n` [SHA-2](https://en.wikipedia.org/wiki/SHA-2)ファミリーのアルゴリズムを使用してハッシュを計算します。5 引数はアルゴリズムを選択するために使用されます。7 `SHA2()` 、引数のいずれかが`NULL`の場合、または`n`で選択されたアルゴリズムが不明またはサポートされていない場合、 `NULL`返します。 +`SHA2(str, n)`関数は`n` [SHA-2](https://en.wikipedia.org/wiki/SHA-2)ファミリーのアルゴリズムを使用してハッシュを計算します。5 引数はアルゴリズムを選択するために使用されます。`SHA2()` 、引数のいずれかが`NULL`の場合、または`n`で選択されたアルゴリズムが不明またはサポートされていない場合、 `NULL`返します。 サポートされているアルゴリズムは次のとおりです。 diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 55665b83855c7..a38f47072e2ec 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -174,7 +174,7 @@ SELECT year, month, SUM(profit) AS profit, grouping(year) as grp_year, grouping( `Expand`演算子の実装は`Projection`演算子と似ています。違いは、 `Expand`多階層の`Projection`であり、複数階層の射影演算式を含むことです。生データの各行に対して、 `Projection`演算子は結果に 1 行のみを生成しますが、 `Expand`演算子は結果に複数行を生成します（行数は射影演算式のレベル数に等しくなります）。 -次の例は、 TiFlashノードのない TiDB クラスターの実行プランを示しています。3 `Expand`演算子のうちの`task` `root`であり、 `Expand`演算子が TiDB で実行されることを示しています。 +次の例は、 TiFlashノードのない TiDB クラスターの実行プランを示しています。`Expand`演算子のうちの`task` `root`であり、 `Expand`演算子が TiDB で実行されることを示しています。 ```sql EXPLAIN SELECT year, month, grouping(year), grouping(month), SUM(profit) AS profit FROM bank GROUP BY year, month WITH ROLLUP; @@ -191,7 +191,7 @@ EXPLAIN SELECT year, month, grouping(year), grouping(month), SUM(profit) AS prof 6 rows in set (0.00 sec) ``` -次の例は、 TiFlash MPP モードでの実行プランを示しています。3 `Expand`演算子のうち`task` `mpp[tiflash]`であり、これは`Expand`演算子がTiFlashで実行されることを示しています。 +次の例は、 TiFlash MPP モードでの実行プランを示しています。`Expand`演算子のうち`task` `mpp[tiflash]`であり、これは`Expand`演算子がTiFlashで実行されることを示しています。 ```sql EXPLAIN SELECT year, month, grouping(year), grouping(month), SUM(profit) AS profit FROM bank GROUP BY year, month WITH ROLLUP; diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index b3af3f6e13cc9..c0cd9487f4709 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -241,7 +241,7 @@ SELECT ROW_COUNT(); ### ユーザー（） {#user} -`USER()`関数は現在の接続のユーザーを返します。5 `USER()`ワイルドカードではなく実際のIPアドレスを表示するため、 `CURRENT_USER()`の出力とは若干異なる場合があります。 +`USER()`関数は現在の接続のユーザーを返します。`USER()`ワイルドカードではなく実際のIPアドレスを表示するため、 `CURRENT_USER()`の出力とは若干異なる場合があります。 ```sql SELECT USER(), CURRENT_USER(); diff --git a/functions-and-operators/json-functions.md b/functions-and-operators/json-functions.md index cb128a98d9522..aeccf75746d56 100644 --- a/functions-and-operators/json-functions.md +++ b/functions-and-operators/json-functions.md @@ -128,7 +128,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを | JSONパス | 説明 | 例[`JSON_EXTRACT()`](/functions-and-operators/json-functions/json-functions-search.md#json_extract) | | ------------------------------------- | -------------------------- | ---------------------------------------------------------------------------------------------------- | | `$` | 文書のルート | 完全な文書を返します | -| `$.database` | `database`オブジェクト | `"database"`から始まる完全な構造を返します。3 `"migration_tool"`それ以下の構造は含まれません。 | +| `$.database` | `database`オブジェクト | `"database"`から始まる完全な構造を返します。`"migration_tool"`それ以下の構造は含まれません。 | | `$.database.name` | データベースの名前。 | `"TiDB"` | | `$.database.features` | すべてのデータベース機能 | `["distributed", "scalable", "relational", "cloud native"]` | | `$.database.features[0]` | 最初のデータベース機能。 | `"distributed"` | diff --git a/functions-and-operators/json-functions/json-functions-aggregate.md b/functions-and-operators/json-functions/json-functions-aggregate.md index fb577dfeee191..c5085f38695e4 100644 --- a/functions-and-operators/json-functions/json-functions-aggregate.md +++ b/functions-and-operators/json-functions/json-functions-aggregate.md @@ -11,7 +11,7 @@ TiDB は MySQL 8.0 で利用可能な[2つの集計JSON関数](https://dev.mysql ## `JSON_ARRAYAGG()` {#json-arrayagg} -`JSON_ARRAYAGG(key)`関数は、指定された`key`に従ってキーの値を JSON 配列に集約します。5 `key`通常、式または列名です。 +`JSON_ARRAYAGG(key)`関数は、指定された`key`に従ってキーの値を JSON 配列に集約します。`key`通常、式または列名です。 例： diff --git a/functions-and-operators/json-functions/json-functions-modify.md b/functions-and-operators/json-functions/json-functions-modify.md index 18f078d486f68..b114ec2a4a2dc 100644 --- a/functions-and-operators/json-functions/json-functions-modify.md +++ b/functions-and-operators/json-functions/json-functions-modify.md @@ -282,7 +282,7 @@ SELECT JSON_UNQUOTE('"foo"'); +-----------------------+ 1 row in set (0.00 sec) -この関数は[`JSON_EXTRACT()`](/functions-and-operators/json-functions/json-functions-search.md#json_extract)と一緒に使用されることが多いです。以下の例では、最初の例では引用符付きのJSON値を抽出し、2番目の例では2つの関数を組み合わせて引用符を解除しています。3 `JSON_UNQUOTE(JSON_EXTRACT(...))`代わりに[`->>`](/functions-and-operators/json-functions/json-functions-search.md#--1)演算子を使用できることに注意してください。 +この関数は[`JSON_EXTRACT()`](/functions-and-operators/json-functions/json-functions-search.md#json_extract)と一緒に使用されることが多いです。以下の例では、最初の例では引用符付きのJSON値を抽出し、2番目の例では2つの関数を組み合わせて引用符を解除しています。`JSON_UNQUOTE(JSON_EXTRACT(...))`代わりに[`->>`](/functions-and-operators/json-functions/json-functions-search.md#--1)演算子を使用できることに注意してください。 ```sql SELECT JSON_EXTRACT('{"database": "TiDB"}', '$.database'); diff --git a/functions-and-operators/json-functions/json-functions-return.md b/functions-and-operators/json-functions/json-functions-return.md index 9c7d26964ab81..34f56a1467294 100644 --- a/functions-and-operators/json-functions/json-functions-return.md +++ b/functions-and-operators/json-functions/json-functions-return.md @@ -32,7 +32,7 @@ SELECT JSON_DEPTH('{"weather": {"current": "sunny"}}'); ## `JSON_LENGTH()` {#json-length} -`JSON_LENGTH(json_doc [,path])`番目の関数はJSONドキュメントの長さを返します。3 `path`引数が指定された場合は、パス内の値の長さを返します。 +`JSON_LENGTH(json_doc [,path])`番目の関数はJSONドキュメントの長さを返します。`path`引数が指定された場合は、パス内の値の長さを返します。 例: diff --git a/functions-and-operators/locking-functions.md b/functions-and-operators/locking-functions.md index ac4970fd8925c..0b07a2cb30555 100644 --- a/functions-and-operators/locking-functions.md +++ b/functions-and-operators/locking-functions.md @@ -15,7 +15,7 @@ TiDB は、MySQL 8.0 で利用可能なユーザー レベル[ロック関数](h | [`IS_FREE_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_is-free-lock) | ロックが空いているかどうかを確認します。 | | [`IS_USED_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_is-used-lock) | ロックが使用中かどうかを確認します。使用中の場合、対応する接続IDを返します。 | | [`RELEASE_ALL_LOCKS()`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_release-all-locks) | 現在のセッションによって保持されているすべてのロックを解除します。 | -| [`RELEASE_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_release-lock) | 以前に取得したロックを解除します。1 `lockName`パラメータは64文字以内でなければなりません。 | +| [`RELEASE_LOCK(lockName)`](https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html#function_release-lock) | 以前に取得したロックを解除します。`lockName`パラメータは64文字以内でなければなりません。 | ## MySQLの互換性 {#mysql-compatibility} diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md index 690b9942bcb54..cb449f07be042 100644 --- a/functions-and-operators/precision-math.md +++ b/functions-and-operators/precision-math.md @@ -44,11 +44,11 @@ DECIMAL 列の値は、9桁の小数点を4バイトにパックするバイナ | 5～6 | 3 | | 7～9 | 4 | -例えば、 `DECIMAL(18,9)`列は小数点の両側に9桁ずつあるため、整数部と小数部はそれぞれ4バイト必要です。3 `DECIMAL(20,6)`列は14桁の整数部と6桁の小数部で構成されます。整数部は9桁で4バイト、残りの5桁で3バイト必要です。小数部は6桁で3バイト必要です。 +例えば、 `DECIMAL(18,9)`列は小数点の両側に9桁ずつあるため、整数部と小数部はそれぞれ4バイト必要です。`DECIMAL(20,6)`列は14桁の整数部と6桁の小数部で構成されます。整数部は9桁で4バイト、残りの5桁で3バイト必要です。小数部は6桁で3バイト必要です。 -DECIMAL列には、先頭の`+`文字目、 `-`文字目、または先頭の`0`桁目は格納されません。9 `DECIMAL(5,1)`列に`+0003.1`挿入した場合、 `3.1`として格納されます。負の数の場合、リテラルの`-`文字目は格納されません。 +DECIMAL列には、先頭の`+`文字目、 `-`文字目、または先頭の`0`桁目は格納されません。`DECIMAL(5,1)`列に`+0003.1`挿入した場合、 `3.1`として格納されます。負の数の場合、リテラルの`-`文字目は格納されません。 -DECIMAL列では、列定義で指定された範囲を超える値は許可されません。例えば、 `DECIMAL(3,0)`列は`-999`から`999`までの範囲をサポートします。7 `DECIMAL(M,D)`列では、小数点の左側に最大`M - D`桁までしか許可されません。 +DECIMAL列では、列定義で指定された範囲を超える値は許可されません。例えば、 `DECIMAL(3,0)`列は`-999`から`999`までの範囲をサポートします。`DECIMAL(M,D)`列では、小数点の左側に最大`M - D`桁までしか許可されません。 DECIMAL 値の内部形式の詳細については、TiDB ソース コードの[`mydecimal.go`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/types/mydecimal.go)参照してください。 diff --git a/functions-and-operators/set-operators.md b/functions-and-operators/set-operators.md index 6b17f7d878ea4..517345391c29d 100644 --- a/functions-and-operators/set-operators.md +++ b/functions-and-operators/set-operators.md @@ -22,7 +22,7 @@ SELECT 1 UNION SELECT 2; 2 rows in set (0.00 sec) ``` -TiDB は`UNION DISTINCT`と`UNION ALL`両方の演算子をサポートします。5 `UNION DISTINCT`結果セットから重複レコードを削除し、 `UNION ALL`重複を含むすべてのレコードを保持します。TiDB では`UNION DISTINCT`デフォルトで使用されます。 +TiDB は`UNION DISTINCT`と`UNION ALL`両方の演算子をサポートします。`UNION DISTINCT`結果セットから重複レコードを削除し、 `UNION ALL`重複を含むすべてのレコードを保持します。TiDB では`UNION DISTINCT`デフォルトで使用されます。 ```sql CREATE TABLE t1 (a int); diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index 19eaecad26813..2115fad5a1818 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -537,7 +537,7 @@ SELECT FIND_IN_SET('Go', 'COBOL,BASIC,Rust,Go,Java,Fortran'); 引数: - `X` : 書式設定する数値。数値、数値文字列、または科学的記数法の数値を指定できます。 -- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。8 `X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。 +- `D` : 返される値の小数点以下の桁数。この関数は、数値を小数点以下`X`から`D`桁に丸めます。`X`実際の小数点以下の桁数よりも`D`大きい場合、結果の長さに合わせて0が補われます。 - `[locale]` : 小数点の区切り、千単位の区切り、および結果の数値の区切りに使用するロケール設定を指定します。有効なロケール値は、システム変数[`lc_time_names`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lc_time_names)の有効な値と同じです。指定されていない場合、または地域設定が`NULL`場合、デフォルトで地域設定`'en_US'`が使用されます。この引数はオプションです。 動作: @@ -819,7 +819,7 @@ SELECT INSTR(0123, "12"); LEFT(`str`, `len`) ``` -- `str` : 文字を抽出する元の文字列。2 `str`マルチバイト文字が含まれている場合、関数はそれを単一のコードポイントとしてカウントします。 +- `str` : 文字を抽出する元の文字列。`str`マルチバイト文字が含まれている場合、関数はそれを単一のコードポイントとしてカウントします。 - `len` : 返される文字の長さ。 - `len` 0 以下の場合、関数は空の文字列を返します。 - `len` `str`の長さ以上である場合、関数は元の`str`を返します。 @@ -1360,8 +1360,8 @@ SELECT CONCAT('«',LTRIM(' hello'),'»'); MAKE_SET(bits, str1, str2, ...) ``` -- `bits` : 結果セットに含める後続の文字列引数を制御します。2 `bits` `NULL`に設定されている場合、関数は`NULL`返します。 -- `str1, str2, ...` : 文字列のリスト。各文字列は、引数`bits`右から左へのビットに対応します。4 `str1`右から最初のビット、 `str2`右から2番目のビットに対応し、以下同様です。対応するビットが`1`の場合、文字列は結果に含まれます。それ以外の場合は含まれません。 +- `bits` : 結果セットに含める後続の文字列引数を制御します。`bits` `NULL`に設定されている場合、関数は`NULL`返します。 +- `str1, str2, ...` : 文字列のリスト。各文字列は、引数`bits`右から左へのビットに対応します。`str1`右から最初のビット、 `str2`右から2番目のビットに対応し、以下同様です。対応するビットが`1`の場合、文字列は結果に含まれます。それ以外の場合は含まれません。 例: @@ -1434,7 +1434,7 @@ SELECT MAKE_SET(b'111','foo','bar','baz'); `MID(str, pos[, len])`関数は、指定された`pos`位置から始まり、長さが`len`部分文字列を返します。 -TiDB v8.4.0以降、2つの引数を持つバリアント`MID(str, pos)`がサポートされます。3 `len`指定されていない場合、この関数は指定された`pos`番目の位置から文字列の末尾までの残りのすべての文字を返します。 +TiDB v8.4.0以降、2つの引数を持つバリアント`MID(str, pos)`がサポートされます。`len`指定されていない場合、この関数は指定された`pos`番目の位置から文字列の末尾までの残りのすべての文字を返します。 引数のいずれかが`NULL`の場合、関数は`NULL`返します。 @@ -2231,11 +2231,11 @@ WEIGHT_STRING(str [AS {CHAR|BINARY}(N)]) - `str` : 入力文字列式。2、4、6 `TEXT`の非バイナリ文字列の場合、戻り値`VARCHAR`は文字列の照合順序重みが含まれます。8、10、12 `BLOB`の`BINARY` `VARBINARY`列の場合、戻り値`CHAR`入力値と同じになります。 -- `AS {CHAR|BINARY}(N)` : 出力のタイプと長さを指定するために使用されるオプションのパラメータ。2 `CHAR`文字データ型を表し、 `BINARY`バイナリ データ型を表します。6 `N`出力長を指定します。これは 1 以上の整数です。 +- `AS {CHAR|BINARY}(N)` : 出力のタイプと長さを指定するために使用されるオプションのパラメータ。`CHAR`文字データ型を表し、 `BINARY`バイナリ データ型を表します。`N`出力長を指定します。これは 1 以上の整数です。 > **注記：** > -> `N`文字列の長さより短い場合、文字列は切り捨てられます。3 `N`文字列の長さを超える場合、 `AS CHAR(N)`指定された長さになるまで文字列にスペースを埋め込み、 `AS BINARY(N)`指定された長さになるまで文字列に`0x00`埋め込みます。 +> `N`文字列の長さより短い場合、文字列は切り捨てられます。`N`文字列の長さを超える場合、 `AS CHAR(N)`指定された長さになるまで文字列にスペースを埋め込み、 `AS BINARY(N)`指定された長さになるまで文字列に`0x00`埋め込みます。 例： diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 692ea2683b124..d0750c68f6827 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -11,8 +11,8 @@ summary: TiDB 固有の関数の使用法について学習します。 | 関数名 | 機能の説明 | | :------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 | -| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)参照してください。 | +| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します。[リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 | +| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。[`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)を参照してください。 | | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 現在の[TiDB のタイムスタンプ Oracle (TSO)](/tso.md)を返します。 | | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | @@ -36,8 +36,8 @@ summary: TiDB 固有の関数の使用法について学習します。 | 関数名 | 機能の説明 | | :------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループ名を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 | -| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)参照してください。 | +| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループ名を返します。[リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 | +| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。[`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)を参照してください。 | | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 現在の[TiDB のタイムスタンプ Oracle (TSO)](/tso.md)を返します。 | | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | @@ -266,7 +266,7 @@ ORDER BY TiDB実行プランは、スロークエリログにエンコードされた形式で保存されています。1関数`TIDB_DECODE_PLAN()` 、エンコードされたプランを人間が読める形式にデコードするために使用されます。 -この関数は、ステートメント実行時にプランが取得されるため便利です。1 `EXPLAIN`ステートメントを再実行すると、データの分布と統計が時間の経過とともに変化するため、異なる結果が生成される可能性があります。 +この関数は、ステートメント実行時にプランが取得されるため便利です。`EXPLAIN`ステートメントを再実行すると、データの分布と統計が時間の経過とともに変化するため、異なる結果が生成される可能性があります。 ```sql SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXRpbWU6NzEzLjHCtXMsIGxvb3BzOjIsIGNvcF90YXNrOiB7bnVtOiAxLCBtYXg6IDU2OC41wgErRHByb2Nfa2V5czogMCwgcnBjXxEpAQwFWBAgNTQ5LglZyGNvcHJfY2FjaGVfaGl0X3JhdGlvOiAwLjAwfQkzLjk5IEtCCU4vQQoxCTFfNgkxXzAJMwm2SGx0KHRlc3QudC5hLCAxMDAwMCkNuQRrdgmiAHsFbBQzMTMuOMIBmQnEDDk2MH0BUgEEGAoyCTQzXzUFVwX1oGFibGU6dCwga2VlcCBvcmRlcjpmYWxzZSwgc3RhdHM6cHNldWRvCTk2ISE2aAAIMTUzXmYA')\G @@ -285,7 +285,7 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR `TIDB_DECODE_SQL_DIGESTS()`関数は、クラスタ内のSQLダイジェストセットに対応する正規化されたSQL文（フォーマットと引数のない形式）を照会するために使用されます。この関数は1つまたは2つの引数を取ります。 - `digests` : 文字列。このパラメータはJSON文字列配列の形式であり、配列内の各文字列はSQLダイジェストです。 -- `stmtTruncateLength` : 整数（オプション）。返される結果内の各SQL文の長さを制限するために使用されます。SQL文が指定された長さを超えた場合、文は切り捨てられます。2 `0`長さが無制限であることを意味します。 +- `stmtTruncateLength` : 整数（オプション）。返される結果内の各SQL文の長さを制限するために使用されます。SQL文が指定された長さを超えた場合、文は切り捨てられます。`0`長さが無制限であることを意味します。 この関数は、JSON文字列配列形式の文字列を返します。配列の*i*番目の項目は、 `digests`パラメータの*i*番目の要素に対応する正規化されたSQL文です。 `digests`パラメータの要素が有効なSQLダイジェストでないか、システムが対応するSQL文を見つけられない場合、返される結果の対応する項目は`null`なります。切り捨て長が指定されている場合（ `stmtTruncateLength > 0` ）、返される結果のこの長さを超える各文については、最初の`stmtTruncateLength`文字が保持され、切り捨てを示すために末尾にサフィックス`"..."`が追加されます。 `digests`パラメータが`NULL`の場合、関数の戻り値は`NULL`なります。 diff --git a/global-indexes.md b/global-indexes.md index 58e4ac444ef17..4cd221af2080d 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -203,7 +203,7 @@ CREATE TABLE `sbtest` ( ) partition by hash(id) partitions 5; ``` -前述のテーブルスキーマを例に挙げましょう。1 `idx`ローカルインデックス、 `global_idx`はグローバルインデックスです。5 のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など`idx`つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 +前述のテーブルスキーマを例に挙げましょう。`idx`ローカルインデックス、 `global_idx`はグローバルインデックスです。5 のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など`idx`つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 `k`に関連するクエリ（例えば`SELECT * FROM sbtest WHERE k > 1`を実行すると、ローカルインデックス`idx`は5つの個別の範囲を生成しますが、グローバルインデックス`global_idx`は1つの範囲のみを生成します。TiDBの各範囲は1つ以上のRPCリクエストに対応するため、グローバルインデックスを使用することでRPCリクエストの数を数倍削減でき、インデックスクエリのパフォーマンスが向上します。 diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index a669748df2459..2157d02783bb0 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -180,7 +180,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_dag` : すべてのコプロセッサ要求内の DAG 要求の数。 - `super_batch` : スーパーバッチ機能を有効にするリクエストの数。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 - リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエスト タイプについて、1 秒あたりの合計処理時間の積み上げグラフを提供します。 - リクエスト期間: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - リクエスト処理時間：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 715650dfe473f..685adbe8cae33 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -17,32 +17,32 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en ## リクエストユニットに関するメトリクス {#metrics-about-request-unit} -- RU: 各リソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)の消費情報。リアルタイムで計算されます。3 `total`は、すべてのリソースグループで消費されるリクエストユニットの合計です。各リソースグループのリクエストユニット消費量は、読み取り消費量（読み取りリクエストユニット）と書き込み消費量（書き込みリクエストユニット）の合計と等しくなります。 +- RU: 各リソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)の消費情報。リアルタイムで計算されます。`total`は、すべてのリソースグループで消費されるリクエストユニットの合計です。各リソースグループのリクエストユニット消費量は、読み取り消費量（読み取りリクエストユニット）と書き込み消費量（書き込みリクエストユニット）の合計と等しくなります。 - クエリあたりのRU: 各SQL文が1秒あたりに消費するリクエストユニットの平均数。上記のRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- RRU: リアルタイムで計算される各リソース グループの読み取り要求単位消費情報。1 `total` 、すべてのリソース グループによって消費される読み取り要求単位の合計です。 +- RRU: リアルタイムで計算される各リソース グループの読み取り要求単位消費情報。`total` 、すべてのリソース グループによって消費される読み取り要求単位の合計です。 - クエリあたりのRRU: 各SQL文が1秒あたりに消費する平均読み取り要求ユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- WRU: リアルタイムで計算される各リソース グループの書き込み要求単位消費情報。1 `total` 、すべてのリソース グループによって消費される書き込み要求単位の合計です。 +- WRU: リアルタイムで計算される各リソース グループの書き込み要求単位消費情報。`total` 、すべてのリソース グループによって消費される書き込み要求単位の合計です。 - クエリあたりのWRU: 各SQL文が1秒あたりに消費する書き込みリクエストユニット（WRRU）の平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - 利用可能なRU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`場合、このリソースグループは`RU_PER_SEC`割合でトークンを消費し、レート制限状態にあるとみなされます。 - クエリの最大期間: リソース グループに関する最大クエリ期間。 ## リソースに関する指標 {#metrics-about-resources} -- KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。1 `total` 、すべてのリソースグループのKVリクエストの合計です。 +- KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。`total` 、すべてのリソースグループのKVリクエストの合計です。 - クエリあたりのKVリクエスト数: 各SQL文による1秒あたりの読み取りおよび書き込みKVリクエストの平均数。上記のKVリクエスト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1 秒あたりに計算)。1 `total` 、すべてのリソース グループによって読み取られたデータの合計です。 +- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1 秒あたりに計算)。`total` 、すべてのリソース グループによって読み取られたデータの合計です。 - クエリあたりの読み取りバイト数: 各SQL文が1秒あたりに読み取るデータの平均量。上記の読み取りバイト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 書き込みバイト数: 各リソース グループによって書き込まれたデータの量。リアルタイムで計算されます。1 `total` 、すべてのリソース グループによって書き込まれたデータの合計です。 +- 書き込みバイト数: 各リソース グループによって書き込まれたデータの量。リアルタイムで計算されます。`total` 、すべてのリソース グループによって書き込まれたデータの合計です。 - クエリあたりの書き込みバイト数: 各SQL文が1秒あたりに書き込むデータ量の平均。上記の「書き込みバイト数」メトリックを、1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- KV CPU 時間: 各リソース グループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。1 `total` 、すべてのリソース グループで消費された KVレイヤーCPU 時間の合計です。 -- SQL CPU 時間: 各リソース グループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。1 `total` 、すべてのリソース グループで消費された SQLレイヤーのCPU 時間の合計です。 +- KV CPU 時間: 各リソース グループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。`total` 、すべてのリソース グループで消費された KVレイヤーCPU 時間の合計です。 +- SQL CPU 時間: 各リソース グループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。`total` 、すべてのリソース グループで消費された SQLレイヤーのCPU 時間の合計です。 ## リソース コントローラー クライアントに関するメトリクス {#metrics-about-resource-controller-client} - アクティブ リソース グループ: リアルタイムで計算された、各リソース コントローラー クライアントのリソース グループの数。 -- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 -- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 -- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソース グループごとに計算されます。1 `total` 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 +- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total` 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 +- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total` 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 +- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total` 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 - 成功した KV 要求の待機期間 (99/90): 各リソース コントローラー クライアントの成功した KV 要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 - トークン要求処理期間 (999/99): 各リソース コントローラー クライアントのサーバー側からのトークン要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 - トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソース グループごとに計算されます。1 と`failed` `successful`すべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 0400ea802201e..e30eb09bdcfce 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -76,7 +76,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - トランザクション書き込みサイズバイト: トランザクションで書き込まれたデータのサイズ - 悲観的ロックの取得期間: ロックの追加にかかる時間 - TTL 寿命到達カウンタ: TTL の上限に達したトランザクションの数。TTL 上限のデフォルト値は 1 時間です。これは、悲観的トランザクションの最初のロック、または楽観的トランザクションの最初の事前書き込みから 1 時間が経過したことを意味します。TTL 上限のデフォルト値は 1 時間です。TTL 寿命の上限は、TiDB 設定ファイルで`max-txn-TTL`変更することで変更できます。 -- ロードセーフポイントOPS: `Safepoint`がロードされる回数。3 `Safepoint` 、トランザクションがデータを読み取る際に`Safepoint`より前のデータが読み込まれないようにすることで、データの安全性を確保するためのものです`Safepoint`より前のデータはGCによってクリーンアップされる可能性があります。 +- ロードセーフポイントOPS: `Safepoint`がロードされる回数。`Safepoint` 、トランザクションがデータを読み取る際に`Safepoint`より前のデータが読み込まれないようにすることで、データの安全性を確保するためのものです`Safepoint`より前のデータはGCによってクリーンアップされる可能性があります。 - 悲観的ステートメント再試行回数（OPS）：悲観的ステートメントの再試行回数。ステートメントがロックを追加しようとすると、書き込み競合が発生する可能性があります。この場合、ステートメントは新しいスナップショットを取得し、再度ロックを追加します。 - 1秒あたりのトランザクションタイプ: 2フェーズコミット (2PC)、非同期コミット、および1フェーズコミット (1PC) メカニズムを使用して1秒あたりにコミットされたトランザクションの数 (成功トランザクションと失敗トランザクションの両方を含む) diff --git a/information-schema/client-errors-summary-by-host.md b/information-schema/client-errors-summary-by-host.md index 218391370a028..3a1afb49b1707 100644 --- a/information-schema/client-errors-summary-by-host.md +++ b/information-schema/client-errors-summary-by-host.md @@ -56,7 +56,7 @@ DESC CLIENT_ERRORS_SUMMARY_BY_HOST; - `FIRST_SEEN` : このエラー (または警告) がクライアント ホストから初めて確認されました。 - `LAST_SEEN` : このエラー (または警告) がクライアント ホストから最後に確認された時刻。 -以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 +以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/client-errors-summary-by-user.md b/information-schema/client-errors-summary-by-user.md index d05ffd44e5886..d4009f59878a1 100644 --- a/information-schema/client-errors-summary-by-user.md +++ b/information-schema/client-errors-summary-by-user.md @@ -13,7 +13,7 @@ summary: CLIENT_ERRORS_SUMMARY_BY_USER` INFORMATION_SCHEMA テーブルについ - 権限エラー。 - 存在しないテーブル。 -クライアントエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。1 `INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_BY_USER`表は、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオにおいて、エラーを検査するための便利な方法を提供します。 +クライアントエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。`INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_BY_USER`表は、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオにおいて、エラーを検査するための便利な方法を提供します。 `CLIENT_ERRORS_SUMMARY_BY_USER`ユーザーごとにエラーを要約するため、あるユーザーサーバーが他のサーバーよりも多くのエラーを生成しているシナリオを診断するのに役立ちます。考えられるシナリオには以下が含まれます。 @@ -55,7 +55,7 @@ DESC CLIENT_ERRORS_SUMMARY_BY_USER; - `FIRST_SEEN` : このエラー (または警告) がユーザーに初めて送信されたとき。 - `LAST_SEEN` : このエラー (または警告) がユーザーに最後に送信された時刻。 -以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 +以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーはリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/client-errors-summary-global.md b/information-schema/client-errors-summary-global.md index 064d2c2576eef..5e632f6e4a71a 100644 --- a/information-schema/client-errors-summary-global.md +++ b/information-schema/client-errors-summary-global.md @@ -47,7 +47,7 @@ DESC CLIENT_ERRORS_SUMMARY_GLOBAL; - `FIRST_SEEN` : このエラー (または警告) が最初に送信されたとき。 - `LAST_SEEN` : このエラー (または警告) が最後に送信された時刻。 -以下の例は、ローカルTiDBサーバーへの接続時に生成される警告を示しています。1 `FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーがリセットされます。 +以下の例は、ローカルTiDBサーバーへの接続時に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`実行するとサマリーがリセットされます。 ```sql SELECT 0/0; diff --git a/information-schema/information-schema-collation-character-set-applicability.md b/information-schema/information-schema-collation-character-set-applicability.md index 701ffd3722a57..10630ad5d9bbb 100644 --- a/information-schema/information-schema-collation-character-set-applicability.md +++ b/information-schema/information-schema-collation-character-set-applicability.md @@ -5,7 +5,7 @@ summary: COLLATION_CHARACTER_SET_APPLICABILITY` INFORMATION_SCHEMA テーブル # 照合文字セットの適用性 {#collation-character-set-applicability} -`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルは、照合順序を該当する文字セット名にマッピングします。3 `COLLATIONS`と同様に、MySQL との互換性のためだけに含まれています。 +`COLLATION_CHARACTER_SET_APPLICABILITY`テーブルは、照合順序を該当する文字セット名にマッピングします。`COLLATIONS`と同様に、MySQL との互換性のためだけに含まれています。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-collations.md b/information-schema/information-schema-collations.md index 25d983690a97e..0864f0ca837c2 100644 --- a/information-schema/information-schema-collations.md +++ b/information-schema/information-schema-collations.md @@ -52,7 +52,7 @@ SELECT * FROM collations WHERE character_set_name='utf8mb4'; - `IS_DEFAULT` : この照合順序が、それが属する文字セットのデフォルトの照合順序であるかどうか。 - `IS_COMPILED` : 文字セットがサーバーにコンパイルされているかどうか。 - `SORTLEN` :照合順序が文字をソートするときに割り当てられるメモリの最小長。 -- `PAD_ATTRIBUTE` : 文字列の比較中に末尾のスペースを無視するかどうか。2 `PAD SPACE`末尾のスペースが無視されることを意味し (たとえば、 `'abc'` `'abc '`と等しい)、 `NO PAD`末尾のスペースが重要であることを意味します (たとえば、 `'abc'` `'abc '`等しくありません)。 +- `PAD_ATTRIBUTE` : 文字列の比較中に末尾のスペースを無視するかどうか。`PAD SPACE`末尾のスペースが無視されることを意味し (たとえば、 `'abc'` `'abc '`と等しい)、 `NO PAD`末尾のスペースが重要であることを意味します (たとえば、 `'abc'` `'abc '`等しくありません)。 ## 参照 {#see-also} diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index be6d25a5597db..ad1abb304dcfb 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -30,7 +30,7 @@ DESC deadlocks; +-------------------------+---------------------+------+------+---------+-------+ ``` -`DEADLOCKS`表では、複数の行を使用して同じデッドロックイベントを表示し、各行にはデッドロックイベントに関係するトランザクションの1つに関する情報が表示されます。TiDBノードが複数のデッドロックエラーを記録した場合、各エラーは`DEADLOCK_ID`列を使用して区別されます。同じ`DEADLOCK_ID`同じデッドロックイベントを示します。7 `DEADLOCK_ID`**グローバルな一意性を保証するものではなく、永続化されないことに**注意してください。同じ結果セット内の同じデッドロックイベントのみを示します。 +`DEADLOCKS`表では、複数の行を使用して同じデッドロックイベントを表示し、各行にはデッドロックイベントに関係するトランザクションの1つに関する情報が表示されます。TiDBノードが複数のデッドロックエラーを記録した場合、各エラーは`DEADLOCK_ID`列を使用して区別されます。同じ`DEADLOCK_ID`同じデッドロックイベントを示します。`DEADLOCK_ID`**グローバルな一意性を保証するものではなく、永続化されないことに**注意してください。同じ結果セット内の同じデッドロックイベントのみを示します。 `DEADLOCKS`テーブル内の各列フィールドの意味は次のとおりです。 @@ -194,7 +194,7 @@ SELECT * FROM INFORMATION_SCHEMA.DEADLOCKS; ## クラスターデッドロック {#cluster-deadlocks} -`CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロック エラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。5 `CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 +`CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロック エラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。`CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 `DEADLOCK_ID`グローバルな一意性が保証されないため、 `CLUSTER_DEADLOCKS`テーブルのクエリ結果では、結果セット内の異なるデッドロック エラーの情報を区別するために、 `INSTANCE`と`DEADLOCK_ID`一緒に使用する必要があることに注意してください。 diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index f9a8789a4141a..281c639b47bb6 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -50,7 +50,7 @@ DESC inspection_result; - `INSTANCE` : 診断されたインスタンスの特定のアドレス。 - `STATUS_ADDRESS` : インスタンスの HTTP API サービス アドレス。 - `VALUE` : 特定の診断項目の値。 -- `REFERENCE` ：この診断項目の基準値（閾値）。2 `VALUE`閾値を超えると、対応する診断情報が生成されます。 +- `REFERENCE` ：この診断項目の基準値（閾値）。`VALUE`閾値を超えると、対応する診断情報が生成されます。 - `SEVERITY` : 重大度レベル。オプションの値は`warning`と`critical`です。 - `DETAILS` : 診断の詳細。追加の診断のための SQL ステートメントまたはドキュメント リンクも含まれる場合があります。 diff --git a/information-schema/information-schema-inspection-summary.md b/information-schema/information-schema-inspection-summary.md index 8c0f9e9a05ebf..7835395057308 100644 --- a/information-schema/information-schema-inspection-summary.md +++ b/information-schema/information-schema-inspection-summary.md @@ -49,7 +49,7 @@ DESC inspection_summary; 使用例: -診断結果表と診断監視サマリー表はどちらも、 `hint`を使用して診断時間範囲を指定できます。3 `select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 、 `2020-03-07 12:00:00` ～ `2020-03-07 13:00:00`期間の監視サマリーです。監視サマリー表と同様に、 `inspection_summary`表を使用すると、異なる2期間のデータを比較することで、差異の大きい監視項目を素早く見つけることができます。 +診断結果表と診断監視サマリー表はどちらも、 `hint`を使用して診断時間範囲を指定できます。`select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 、 `2020-03-07 12:00:00` ～ `2020-03-07 13:00:00`期間の監視サマリーです。監視サマリー表と同様に、 `inspection_summary`表を使用すると、異なる2期間のデータを比較することで、差異の大きい監視項目を素早く見つけることができます。 次の例では、2 つの期間における読み取りリンクの監視メトリックを比較します。 diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 886f89f94ee82..e0e88fdbf0783 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -138,7 +138,7 @@ COMMENT | The quantile of TiDB query durations(second) - 期間t1: `("2020-03-03 17:08:00", "2020-03-03 17:11:00")` - 期間t2: `("2020-03-03 17:18:00", "2020-03-03 17:21:00")` -2 つの期間の監視項目は`METRICS_NAME`に従って結合され、差異値に従ってソートされます。3 `TIME_RANGE`クエリ時間を指定するヒントです。 +2 つの期間の監視項目は`METRICS_NAME`に従って結合され、差異値に従ってソートされます。`TIME_RANGE`クエリ時間を指定するヒントです。 ```sql SELECT GREATEST(t1.avg_value,t2.avg_value)/LEAST(t1.avg_value, diff --git a/information-schema/information-schema-sql-diagnostics.md b/information-schema/information-schema-sql-diagnostics.md index 519691da3ac65..dbb8acd7952d7 100644 --- a/information-schema/information-schema-sql-diagnostics.md +++ b/information-schema/information-schema-sql-diagnostics.md @@ -52,5 +52,5 @@ TiDB クラスターには多くの監視メトリックがあるため、TiDB 上記のクラスタ情報テーブルおよびクラスタ監視テーブルでは、クラスタのトラブルシューティングを行うために手動でSQL文を実行する必要があります。TiDB v4.0は自動診断をサポートしています。既存の基本情報テーブルをベースにした診断関連のシステムテーブルを使用することで、診断を自動実行できます。自動診断に関連するシステムテーブルは以下のとおりです。 -- 診断結果テーブル[`information_schema.inspection_result`](/information-schema/information-schema-inspection-result.md)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。3 `select * from inspection_result`実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 +- 診断結果テーブル[`information_schema.inspection_result`](/information-schema/information-schema-inspection-result.md)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。`select * from inspection_result`実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 - 診断サマリーテーブル[`information_schema.inspection_summary`](/information-schema/information-schema-inspection-summary.md) 、特定のリンクまたはモジュールの監視情報を要約したものです。モジュールまたはリンク全体のコンテキストに基づいて、トラブルシューティングを行い、問題を特定することができます。 diff --git a/information-schema/information-schema-tiflash-replica.md b/information-schema/information-schema-tiflash-replica.md index 3d424c764de45..300e471359d59 100644 --- a/information-schema/information-schema-tiflash-replica.md +++ b/information-schema/information-schema-tiflash-replica.md @@ -37,4 +37,4 @@ DESC TIFLASH_REPLICA; - `REPLICA_COUNT` : TiFlashレプリカの数。 - `LOCATION_LABELS` : TiFlashレプリカが作成されるときに設定される LocationLabelList。 - `AVAILABLE` : テーブルのTiFlashレプリカが利用可能かどうかを示します。値が`1` （利用可能）の場合、TiDB オプティマイザーはクエリコストに基づいて、クエリを TiKV またはTiFlashにプッシュダウンするかをインテリジェントに選択します。値が`0` （利用不可）の場合、TiDB はクエリをTiFlashにプッシュダウンしません。このフィールドの値が`1` （利用可能）になると、それ以上変化しなくなります。 -- `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。4 `AVAILABLE`が`1`で`PROGRESS` 1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 +- `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。`AVAILABLE`が`1`で`PROGRESS` 1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 diff --git a/information-schema/information-schema-tiflash-segments.md b/information-schema/information-schema-tiflash-segments.md index 21bfd52e18f46..15e80c0aa7320 100644 --- a/information-schema/information-schema-tiflash-segments.md +++ b/information-schema/information-schema-tiflash-segments.md @@ -59,7 +59,7 @@ DESC tiflash_segments; - `TIDB_DATABASE` : TiDB内のデータベース名。セグメントはこのデータベース内のテーブルに属します。 - `TIDB_TABLE` : TiDB内のテーブル名。セグメントはこのテーブルに属します。 - `TABLE_ID` : セグメントが属するテーブルの内部ID。このIDはTiDBクラスタ内で一意です。 -- `IS_TOMBSTONE` : セグメントが属するテーブルがリサイクル可能かどうかを示します。2 `1`テーブルがリサイクル可能であることを示します。4 `0`テーブルが通常の状態であることを示します。 +- `IS_TOMBSTONE` : セグメントが属するテーブルがリサイクル可能かどうかを示します。`1`テーブルがリサイクル可能であることを示します。`0`テーブルが通常の状態であることを示します。 - `SEGMENT_ID` : テーブル内で一意のセグメント ID。 - `RANGE` : セグメントに含まれるデータの範囲。 - `EPOCH` : セグメントの更新バージョン。各セグメントのバージョン番号は単調に増加します。 diff --git a/information-schema/information-schema-tiflash-tables.md b/information-schema/information-schema-tiflash-tables.md index c6aa66f783989..87483a2fe3fdc 100644 --- a/information-schema/information-schema-tiflash-tables.md +++ b/information-schema/information-schema-tiflash-tables.md @@ -80,7 +80,7 @@ DESC tiflash_tables; - `TIDB_DATABASE` : TiDB 内でテーブルが属するデータベースの名前。 - `TIDB_TABLE` : TiDB 内のテーブルの名前。 - `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 -- `IS_TOMBSTONE` : テーブルがリサイクル可能かどうかを示します。2 `1`テーブルがリサイクル可能であることを示し、 `0`テーブルが通常の状態であることを示します。 +- `IS_TOMBSTONE` : テーブルがリサイクル可能かどうかを示します。`1`テーブルがリサイクル可能であることを示し、 `0`テーブルが通常の状態であることを示します。 - `SEGMENT_COUNT` : テーブル内のセグメント数。セグメントはTiFlashにおけるデータ管理単位です。 - `TOTAL_ROWS` : テーブル内の行の合計数。 - `TOTAL_SIZE` : テーブルの合計サイズ (バイト単位)。 diff --git a/information-schema/information-schema-variables-info.md b/information-schema/information-schema-variables-info.md index 38bca48e99379..eb6246706ae58 100644 --- a/information-schema/information-schema-variables-info.md +++ b/information-schema/information-schema-variables-info.md @@ -46,7 +46,7 @@ SELECT * FROM variables_info ORDER BY variable_name LIMIT 3; `VARIABLES_INFO`テーブル内のフィールドは次のように説明されます。 - `VARIABLE_NAME` : システム変数の名前。 -- `VARIABLE_SCOPE` : システム変数のスコープ。2 `SESSION` 、システム変数が現在のセッションでのみ有効であることを意味します。4 `INSTANCE` 、システム変数が TiDB インスタンスで有効であることを意味します。6 `GLOBAL` 、システム変数が TiDB クラスターで有効であることを意味します。8 `NONE` 、システム変数が TiDB クラスターで読み取り専用であることを意味します。 +- `VARIABLE_SCOPE` : システム変数のスコープ。`SESSION` 、システム変数が現在のセッションでのみ有効であることを意味します。`INSTANCE` 、システム変数が TiDB インスタンスで有効であることを意味します。`GLOBAL` 、システム変数が TiDB クラスターで有効であることを意味します。`NONE` 、システム変数が TiDB クラスターで読み取り専用であることを意味します。 - `DEFAULT_VALUE` : システム変数のデフォルト値。 - `CURRENT_VALUE` : システム変数の現在の値。スコープに`SESSION`含まれる場合、現在のセッションでは`CURRENT_VALUE`値となります。 - `MIN_VALUE` : システム変数に許容される最小値。システム変数が数値でない場合、 `MIN_VALUE` NULL になります。 diff --git a/latency-breakdown.md b/latency-breakdown.md index ee161256538f2..a3f309023dba4 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -138,7 +138,7 @@ read value duration(from disk) = sum(rate(tikv_storage_rocksdb_perf{metric="block_read_time",req="get/batch_get_command"})) / sum(rate(tikv_storage_rocksdb_perf{metric="block_read_count",req="get/batch_get_command"})) ``` -TiKVはストレージエンジンとしてRocksDBを使用します。必要な値がブロックキャッシュに存在しない場合、TiKVはディスクから値をロードする必要があります。1 `tikv_storage_rocksdb_perf`場合、getリクエストは`get`または`batch_get_command`いずれかになります。 +TiKVはストレージエンジンとしてRocksDBを使用します。必要な値がブロックキャッシュに存在しない場合、TiKVはディスクから値をロードする必要があります。`tikv_storage_rocksdb_perf`場合、getリクエストは`get`または`batch_get_command`いずれかになります。 ### Batch PointGet {#batch-point-get} @@ -227,7 +227,7 @@ tidb_session_execute_duration_seconds{type="general"} = tidb_distsql_handle_query_duration_seconds{sql_type="general"} <= send request duration ``` -テーブルスキャンとインデックススキャンは同じように処理されます。1 `req_per_copr`分散タスク数です。コプロセッサの実行とクライアントへのデータ応答は異なるスレッドで行われるため、待機時間は`tidb_distsql_handle_query_duration_seconds{sql_type="general"}`となり、 `send request duration`よりも短くなります。 +テーブルスキャンとインデックススキャンは同じように処理されます。`req_per_copr`分散タスク数です。コプロセッサの実行とクライアントへのデータ応答は異なるスレッドで行われるため、待機時間は`tidb_distsql_handle_query_duration_seconds{sql_type="general"}`となり、 `send request duration`よりも短くなります。 `send request duration`と`req_per_copr`次のように計算されます。 diff --git a/literal-values.md b/literal-values.md index 8bbe99a3ccdc8..0c2257d39752f 100644 --- a/literal-values.md +++ b/literal-values.md @@ -130,7 +130,7 @@ SELECT TRUE, true, tRuE, FALSE, FaLsE, false; ## 16進数リテラル {#hexadecimal-literals} -16進数リテラル値は`X'val'`または`0xval`表記法で記述されます。5 `val`は16進数が含まれます。先頭の`0x`は大文字と小文字が区別され、 `0X`と表記することはできません。 +16進数リテラル値は`X'val'`または`0xval`表記法で記述されます。`val`は16進数が含まれます。先頭の`0x`は大文字と小文字が区別され、 `0X`と表記することはできません。 有効な16進数リテラル: @@ -184,7 +184,7 @@ mysql> SELECT X'54694442'; ## ビット値リテラル {#bit-value-literals} -ビット値リテラルは`b'val'`または`0bval`表記法で記述されます。5 `val` 0と1で記述された2進値です。先頭の`0b`は大文字と小文字が区別され、 `0B`と記述することはできません。 +ビット値リテラルは`b'val'`または`0bval`表記法で記述されます。`val` 0と1で記述された2進値です。先頭の`0b`は大文字と小文字が区別され、 `0B`と記述することはできません。 有効なビット値リテラル: diff --git a/log-redaction.md b/log-redaction.md index 0ea590c79e618..27174f45445be 100644 --- a/log-redaction.md +++ b/log-redaction.md @@ -33,7 +33,7 @@ ERROR 1062 (23000): Duplicate entry '1' for key 't.a' 上記のエラー ログから、値`tidb_redact_log`が`ON`に設定されると、データ セキュリティ リスクを回避するために、機密情報が TiDB ログで`?`マークに置き換えられることがわかります。 -さらに、TiDBには`MARKER`オプションが用意されています。3 `tidb_redact_log`値を`MARKER`に設定すると、TiDBはログ内の機密情報を直接置き換えるのではなく、 `‹›`でマークするため、編集ルールをカスタマイズできます。 +さらに、TiDBには`MARKER`オプションが用意されています。`tidb_redact_log`値を`MARKER`に設定すると、TiDBはログ内の機密情報を直接置き換えるのではなく、 `‹›`でマークするため、編集ルールをカスタマイズできます。 ```sql set @@global.tidb_redact_log = MARKER; diff --git a/metadata-lock.md b/metadata-lock.md index 477cc51cbf326..7b312975763d7 100644 --- a/metadata-lock.md +++ b/metadata-lock.md @@ -50,7 +50,7 @@ TiDB v6.5.0以降、メタデータロックはデフォルトで有効になり | `INSERT INTO t VALUES(1);` | | | `BEGIN;` | | | | `ALTER TABLE t ADD COLUMN b INT;` | - | `SELECT * FROM t;`
(テーブル`t`の現在のメタデータ バージョンを使用します。5 `(a=1, b=NULL)`返し、テーブル`t`をロックします。) | | + | `SELECT * FROM t;`
(テーブル`t`の現在のメタデータ バージョンを使用します。`(a=1, b=NULL)`返し、テーブル`t`をロックします。) | | | | `ALTER TABLE t ADD COLUMN c INT;` (セッション 1 によってブロックされています) | 繰り返し可能読み取り分離レベルでは、トランザクションの開始からテーブルのメタデータを決定する時点までの間に、インデックスの追加や列タイプの変更など、データの変更を必要とする DDL が実行されると、DDL は次のようにエラーを返します。 @@ -94,7 +94,7 @@ SQL_DIGESTS: ["begin","select * from `t`"] ``` -上記の出力から、 `SESSION ID`が`1547698182`あるトランザクションが`ADD COLUMN` DDLをブロックしていることがわかります。7 `SQL_DIGEST` 、このトランザクションによって実行されたSQL文（ ``["begin","select * from `t`"]``を示しています。ブロックされたDDLの実行を継続するには、次のグローバル`KILL`文を使用して`1547698182`トランザクションを強制終了します。 +上記の出力から、 `SESSION ID`が`1547698182`あるトランザクションが`ADD COLUMN` DDLをブロックしていることがわかります。`SQL_DIGEST` 、このトランザクションによって実行されたSQL文（ ``["begin","select * from `t`"]``を示しています。ブロックされたDDLの実行を継続するには、次のグローバル`KILL`文を使用して`1547698182`トランザクションを強制終了します。 ```sql mysql> KILL 1547698182; diff --git a/metrics-schema.md b/metrics-schema.md index a12d08ea267b6..e9bdd220f026f 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -113,9 +113,9 @@ SELECT * FROM information_schema.metrics_tables WHERE table_name='tidb_query_dur - `TABLE_NAME` : `metrics_schema`のテーブル名に対応します。この例では、テーブル名は`tidb_query_duration`です。 - `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータを要求し、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 -- `LABELS` : 監視項目のラベル。2 `tidb_query_duration`は`instance`と`sql_type` 2 つのラベルがあります。 +- `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type` 2 つのラベルがあります。 - `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 -- `COMMENT` : 監視テーブルの説明。2 `tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 +- `COMMENT` : 監視テーブルの説明。`tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 `tidb_query_duration`テーブルのスキーマをクエリするには、次のステートメントを実行します。 @@ -138,7 +138,7 @@ SHOW CREATE TABLE metrics_schema.tidb_query_duration; ``` - `time` : 監視項目の時間。 -- `instance`と`sql_type` : `tidb_query_duration`監視項目のラベル。6 `instance`監視アドレスを意味します。8 `sql_type`実行された SQL 文の種類を意味します。 +- `instance`と`sql_type` : `tidb_query_duration`監視項目のラベル。`instance`監視アドレスを意味します。`sql_type`実行された SQL 文の種類を意味します。 - `quantile` : パーセンタイル。ヒストグラム型の監視項目にはこの列があり、クエリのパーセンタイル時間を示します。例えば、 `quantile = 0.9` P90の時間をクエリすることを意味します。 - `value` : 監視項目の値。 @@ -164,7 +164,7 @@ SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AND tim +---------------------+-------------------+----------+----------+----------------+ ``` -上記のクエリ結果の最初の行は、2020年3月25日 23:40:00の時点において、TiDBインスタンス`172.16.5.40:10089`において、 `Insert`番目の文のP99実行時間が0.509929485256秒であることを意味します。他の行も同様の意味を持ちます。5 `sql_type`の列のその他の値は、以下のように記述されます。 +上記のクエリ結果の最初の行は、2020年3月25日 23:40:00の時点において、TiDBインスタンス`172.16.5.40:10089`において、 `Insert`番目の文のP99実行時間が0.509929485256秒であることを意味します。他の行も同様の意味を持ちます。`sql_type`の列のその他の値は、以下のように記述されます。 - `Select` : `select`型のステートメントが実行されます。 - `internal` : 統計情報を更新し、グローバル変数を取得するために使用される TiDB の内部 SQL ステートメント。 @@ -186,7 +186,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN 上記の結果から、実行プランには`PromQL` 、 `start_time` 、 `end_time` 、 `step`含まれていることがわかります。実行プロセス中、TiDBはPrometheusの`query_range` HTTP APIを呼び出して監視データを照会します。 -[ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行プランでは、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。7 `step`次の2つのセッション変数によって決定されます。 +[ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行プランでは、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。`step`次の2つのセッション変数によって決定されます。 - `tidb_metric_query_step` : クエリ解決ステップ幅。Prometheusから`query_range`データを取得するには、 `start_time` 、 `end_time` 、 `step`指定する必要があります。 `step` 、この変数の値が使用されます。 - `tidb_metric_query_range_duration` : 監視データが照会されると、 `PROMQL`の`$ RANGE_DURATION`のフィールドの値がこの変数の値に置き換えられます。デフォルト値は60秒です。 diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index dbc0ff7723a77..b2198bc8e6f2e 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -79,7 +79,7 @@ from: port: ${port} # For example: 3306 ``` -ターミナルで次のコマンドを実行します。1 `tiup dmctl`指定して、データソース構成を DM クラスターに読み込みます。 +ターミナルで次のコマンドを実行します。`tiup dmctl`指定して、データソース構成を DM クラスターに読み込みます。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -204,7 +204,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} ``` -エラーが発生した場合は、 `query-status ${task-name}`使用して詳細情報を表示してください。3 `query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)参照してください。 +エラーが発生した場合は、 `query-status ${task-name}`使用して詳細情報を表示してください。`query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)参照してください。 ## ステップ5. タスクを監視し、ログを確認する（オプション） {#step-5-monitor-tasks-and-check-logs-optional} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 43b32687af0fb..59e151c7b9981 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -73,11 +73,11 @@ DM がダウンストリーム テーブル スキーマを使用してアップ | パラメータ | 説明 | | :------------------ | :--------------------------------------------------------------------------------------------------------------- | - | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`指定します。3 `${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。 | + | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`指定します。`${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | - | `-s` | ソースを指定します。1 `${source-id}` MySQL データのソース ID を示します。 | + | `-s` | ソースを指定します。`${source-id}` MySQL データのソース ID を示します。 | | `${task-name}` | データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。 | - | `${database-name}` | データベースを指定します。1 `${database-name}`アップストリーム データベースの名前を示します。 | + | `${database-name}` | データベースを指定します。`${database-name}`アップストリーム データベースの名前を示します。 | | `${table-name}` | アップストリーム テーブルの名前を指定します。 | | `${schema-file}` | 設定するテーブル スキーマ ファイルを指定します。 | diff --git a/optimizer-hints.md b/optimizer-hints.md index fa0f49d2d8779..651fcedeb4658 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -826,7 +826,7 @@ SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; ### NTH_PLAN(N) {#nth-plan-n} -ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザーに通知します。5 `N`正の整数である必要があります。 +ヒント`NTH_PLAN(N)`は、物理的な最適化中に見つかった`N`番目の物理プランを選択するようにオプティマイザーに通知します。`N`正の整数である必要があります。 指定された`N`物理最適化の検索範囲を超える場合、TiDB は警告を返し、このヒントを無視する戦略に基づいて最適な物理プランを選択します。 diff --git a/oracle-functions-to-tidb.md b/oracle-functions-to-tidb.md index f2f4964f8ff6c..19495d92d7be4 100644 --- a/oracle-functions-to-tidb.md +++ b/oracle-functions-to-tidb.md @@ -23,7 +23,7 @@ summary: Oracle と TiDB の関数と構文の比較を学習します。 | 現在のシステム時間を秒精度で取得する | `SYSDATE` | `NOW()` | | | 現在のシステム時間をマイクロ秒精度で取得する | `SYSTIMESTAMP` | `CURRENT_TIMESTAMP(6)` | | | 2つの日付間の日数を取得する | `date1 - date2` | `DATEDIFF(date1, date2)` | | -| 2つの日付間の月数を取得する | `MONTHS_BETWEEN(ENDDATE,SYSDATE)` | `TIMESTAMPDIFF(MONTH,SYSDATE,ENDDATE)` | Oracleの`MONTHS_BETWEEN()`とTiDBの`TIMESTAMPDIFF()`の結果は異なります。5 `TIMESTAMPDIFF()`整数を返します。2つの関数のパラメータが入れ替わっていることに注意してください。 | +| 2つの日付間の月数を取得する | `MONTHS_BETWEEN(ENDDATE,SYSDATE)` | `TIMESTAMPDIFF(MONTH,SYSDATE,ENDDATE)` | Oracleの`MONTHS_BETWEEN()`とTiDBの`TIMESTAMPDIFF()`の結果は異なります。`TIMESTAMPDIFF()`整数を返します。2つの関数のパラメータが入れ替わっていることに注意してください。 | | 日付に`n`日を追加する | `DATEVAL + n` | `DATE_ADD(dateVal,INTERVAL n DAY)` | `n`負の値になる場合があります。 | | 日付に`n`月を加算する | `ADD_MONTHS(dateVal,n)` | `DATE_ADD(dateVal,INTERVAL n MONTH)` | `n`負の値になる場合があります。 | | デートの日をゲット | `TRUNC(SYSDATE)` |
  • `CAST(NOW() AS DATE)`
  • `DATE_FORMAT(NOW(),'%Y-%m-%d')`
    • | TiDB では、 `CAST`と`DATE_FORMAT`同じ結果を返します。 | @@ -116,7 +116,7 @@ Oracleでは、最初のクエリ結果には含まれているが2番目のク SELECT * FROM t1 MINUS SELECT * FROM t2 ``` -TiDBは`MINUS`演算をサポートしていません。3 `EXCEPT`の演算を使用できます。例: +TiDBは`MINUS`演算をサポートしていません。`EXCEPT`の演算を使用できます。例: ```sql SELECT * FROM t1 EXCEPT SELECT * FROM t2 diff --git a/password-management.md b/password-management.md index 125e64debd9d0..f2a2ca2941eba 100644 --- a/password-management.md +++ b/password-management.md @@ -372,7 +372,7 @@ TiDBは、アカウントのログイン失敗回数を追跡できます。ブ `CREATE USER`または`ALTER USER`ステートメントの`FAILED_LOGIN_ATTEMPTS`および`PASSWORD_LOCK_TIME`オプションを使用して、各アカウントのログイン失敗回数とロック時間を設定できます。使用可能な値オプションは次のとおりです。 -- `FAILED_LOGIN_ATTEMPTS` : N。2 `N`連続してログインに失敗すると、アカウントは一時的にロックされます。Nの値の範囲は0～32767です。 +- `FAILED_LOGIN_ATTEMPTS` : N。`N`連続してログインに失敗すると、アカウントは一時的にロックされます。Nの値の範囲は0～32767です。 - `PASSWORD_LOCK_TIME` : N | 無制限。 - Nは、連続してログインに失敗すると、アカウントが`N`日間一時的にロックされることを意味します。Nの値の範囲は0～32767です。 - `UNBOUNDED`ロック時間が無制限であり、アカウントを手動でロック解除する必要があることを意味します。Nの値の範囲は0から32767です。 @@ -418,5 +418,5 @@ ALTER USER 'test3'@'localhost' FAILED_LOGIN_ATTEMPTS 0 PASSWORD_LOCK_TIME 0; > > 連続してログインに失敗したためにアカウントがロックされた場合、アカウント ロック ポリシーを変更すると、次の影響があります。 > -> - `FAILED_LOGIN_ATTEMPTS`変更しても、アカウントのロック状態は変わりません。3 `FAILED_LOGIN_ATTEMPTS`変更は、アカウントのロックが解除され、再度ログインを試みた後に有効になります。 -> - `PASSWORD_LOCK_TIME`変更しても、アカウントのロック状態は変わりません。3 `PASSWORD_LOCK_TIME`変更は、アカウントが再度ログインしようとした際に有効になります。その際、TiDB は新しいロック時間が経過したかどうかを確認します。経過した場合、TiDB はユーザーのロックを解除します。 +> - `FAILED_LOGIN_ATTEMPTS`変更しても、アカウントのロック状態は変わりません。`FAILED_LOGIN_ATTEMPTS`変更は、アカウントのロックが解除され、再度ログインを試みた後に有効になります。 +> - `PASSWORD_LOCK_TIME`変更しても、アカウントのロック状態は変わりません。`PASSWORD_LOCK_TIME`変更は、アカウントが再度ログインしようとした際に有効になります。その際、TiDB は新しいロック時間が経過したかどうかを確認します。経過した場合、TiDB はユーザーのロックを解除します。 diff --git a/pd-control.md b/pd-control.md index 4f8fe35565d57..41a916f816001 100644 --- a/pd-control.md +++ b/pd-control.md @@ -19,7 +19,7 @@ PD Controlを使用するには、 `tiup ctl:v pd -u http:// pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set max-pending-peer-count 64 // Set the maximum number of pending peers to 64 ``` -- `max-merge-region-size`リージョンマージのサイズ上限を制御します（単位は MiB）。2 `regionSize`指定値を超える場合、PD は隣接するリージョンとマージしません。0 に設定すると、リージョンマージが無効になります。 +- `max-merge-region-size`リージョンマージのサイズ上限を制御します（単位は MiB）。`regionSize`指定値を超える場合、PD は隣接するリージョンとマージしません。0 に設定すると、リージョンマージが無効になります。 ```bash config set max-merge-region-size 16 // Set the upper limit on the size of Region Merge to 16 MiB ``` -- `max-merge-region-keys`リージョンマージのキー数の上限を制御します。2 `regionKeyCount`指定された値を超える場合、PD は隣接するリージョンとマージしません。 +- `max-merge-region-keys`リージョンマージのキー数の上限を制御します。`regionKeyCount`指定された値を超える場合、PD は隣接するリージョンとマージしません。 ```bash config set max-merge-region-keys 50000 // Set the upper limit on keyCount to 50000 @@ -204,13 +204,13 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set split-merge-interval 24h // Set the interval between `split` and `merge` to one day ``` -- `enable-one-way-merge` 、PD がリージョン を次のリージョンとの結合のみを許可するかどうかを制御します。2 `false`設定すると、PD はリージョン を隣接する 2 つの Region との結合を許可します。 +- `enable-one-way-merge` 、PD がリージョン を次のリージョンとの結合のみを許可するかどうかを制御します。`false`設定すると、PD はリージョン を隣接する 2 つの Region との結合を許可します。 ```bash config set enable-one-way-merge true // Enables one-way merging. ``` -- `enable-cross-table-merge` 、テーブル間のリージョンのマージを有効にするために使用されます。2 `false`設定すると、PD は異なるテーブルのリージョンをマージしません。このオプションは、キータイプが「テーブル」の場合にのみ機能します。 +- `enable-cross-table-merge` 、テーブル間のリージョンのマージを有効にするために使用されます。`false`設定すると、PD は異なるテーブルのリージョンをマージしません。このオプションは、キータイプが「テーブル」の場合にのみ機能します。 ```bash config set enable-cross-table-merge true // Enable cross table merge. @@ -219,7 +219,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `key-type` 、クラスターで使用されるキーエンコーディングの種類を指定します。サポートされているオプションは ["table", "raw", "txn"] で、デフォルト値は "table" です。 - クラスター内に TiDB インスタンスが存在しない場合は、 `key-type` 「raw」または「txn」になり、PD は`enable-cross-table-merge`設定に関係なくテーブル間でリージョンをマージできます。 - - クラスター内にTiDBインスタンスが存在する場合、 `key-type` 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。5 `key-type` 「raw」の場合、配置ルールは機能しません。 + - クラスター内にTiDBインスタンスが存在する場合、 `key-type` 「table」である必要があります。PDがテーブル間でリージョンをマージできるかどうかは、 `enable-cross-table-merge`によって決まります。`key-type` 「raw」の場合、配置ルールは機能しません。 ```bash config set key-type raw // Enable cross table merge. @@ -321,7 +321,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `enable-remove-down-replica`は`false`ダウンタイムレプリカの自動削除機能を有効にするために使用されます。2 に設定すると、PDはダウンタイムレプリカを自動的にクリーンアップしません。 -- `enable-replace-offline-replica`は、OfflineReplica の移行機能を有効にするために使用されます。2 `false`設定すると、PD はオフラインレプリカを移行しません。 +- `enable-replace-offline-replica`は、OfflineReplica の移行機能を有効にするために使用されます。`false`設定すると、PD はオフラインレプリカを移行しません。 - `enable-make-up-replica`はレプリカ作成機能を有効にするために使用されます。 `false`に設定すると、PDはレプリカが不足しているリージョンに対してレプリカを追加しません。 @@ -333,7 +333,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `enable-placement-rules`は配置ルールを有効にするために使用され、v5.0 以降のバージョンではデフォルトで有効になっています。 -- `store-limit-mode`はストア速度を制限するモードを制御するために使用されます。オプションのモードは`auto`と`manual`です。6 `auto`では、ストアは負荷に応じて自動的にバランス調整されます（非推奨）。 +- `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)を参照してください。 @@ -1101,7 +1101,7 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope scheduler config balance-hot-region-scheduler set byte-rate-rank-step-ratio 0.05 ``` -- `src-tolerance-ratio`と`dst-tolerance-ratio`期待値スケジューラの設定項目です。4 `tolerance-ratio`小さいほど、スケジューリングが容易になります。冗長なスケジューリングが発生する場合は、この値を適切に増やしてください。 +- `src-tolerance-ratio`と`dst-tolerance-ratio`期待値スケジューラの設定項目です。`tolerance-ratio`小さいほど、スケジューリングが容易になります。冗長なスケジューリングが発生する場合は、この値を適切に増やしてください。 ```bash scheduler config balance-hot-region-scheduler set src-tolerance-ratio 1.1 diff --git a/pd-microservices.md b/pd-microservices.md index 7d15867516ad5..9ddd58a541722 100644 --- a/pd-microservices.md +++ b/pd-microservices.md @@ -81,8 +81,8 @@ TiUP Playground を使用して TiDB ローカル クラスターに PD マイ PD マイクロサービスをデプロイして使用する場合、次の点に注意してください。 - マイクロサービスを有効にしてクラスターのPDを再起動すると、PDはクラスターへのTSOの割り当てを停止します。そのため、マイクロサービスを有効にする際には、クラスターに`tso`マイクロサービスをデプロイする必要があります。 -- `scheduling`マイクロサービスがクラスターにデプロイされている場合、クラスターのスケジューリング機能は`scheduling`マイクロサービスによって提供されます。5 `scheduling`マイクロサービスがデプロイされていない場合でも、クラスターのスケジューリング機能はPDによって提供されます。 -- `scheduling`マイクロサービスは動的スイッチングをサポートしており、これはデフォルトで有効になっています（ `enable-scheduling-fallback`デフォルトで`true`に設定されています）。7 `scheduling`サービスのプロセスが終了した場合、PD はデフォルトでクラスターのスケジューリングサービスを継続します。 +- `scheduling`マイクロサービスがクラスターにデプロイされている場合、クラスターのスケジューリング機能は`scheduling`マイクロサービスによって提供されます。`scheduling`マイクロサービスがデプロイされていない場合でも、クラスターのスケジューリング機能はPDによって提供されます。 +- `scheduling`マイクロサービスは動的スイッチングをサポートしており、これはデフォルトで有効になっています（ `enable-scheduling-fallback`デフォルトで`true`に設定されています）。`scheduling`サービスのプロセスが終了した場合、PD はデフォルトでクラスターのスケジューリングサービスを継続します。 `scheduling`マイクロサービスと PD のバイナリバージョンが異なる場合、スケジューリングロジックの変更を防ぐため、 `pd-ctl config set enable-scheduling-fallback false`実行して`scheduling`マイクロサービスの動的切り替え機能を無効化できます。この機能を無効化すると、 `scheduling`マイクロサービスのプロセスが終了しても PD はスケジューリングサービスを引き継ぎません。つまり、 `scheduling`マイクロサービスが再起動されるまで、クラスターのスケジューリングサービスは利用できなくなります。 @@ -94,4 +94,4 @@ PD マイクロサービスをデプロイして使用する場合、次の点 - PD がパフォーマンスのボトルネックになるかどうかをどのように判断すればよいですか? - クラスターが正常な状態であれば、Grafana PDパネルで監視メトリクスを確認できます。1 `TiDB - PD server TSO handle time`メトリクスでレイテンシーが著しく増加している場合、または`Heartbeat - TiKV side heartbeat statistics`メトリクスで保留中の項目が多数表示されている場合は、PDがパフォーマンスのボトルネックになっていることを示しています。 + クラスターが正常な状態であれば、Grafana PDパネルで監視メトリクスを確認できます。`TiDB - PD server TSO handle time`メトリクスでレイテンシーが著しく増加している場合、または`Heartbeat - TiKV side heartbeat statistics`メトリクスで保留中の項目が多数表示されている場合は、PDがパフォーマンスのボトルネックになっていることを示しています。 diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 01c62fb912b09..562faa6c93163 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -254,7 +254,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度 - `TiDB -> TiKV: internal` : 内部トランザクションが TiDB から TiKV に書き込まれる速度 - `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ - - `RocksDB Compaction` : RocksDBの圧縮操作によって生成される読み取りおよび書き込みI/Oフローの合計。2 `RocksDB Compaction` `TiKV -> Rocksdb`よりも大幅に大きく、平均行サイズが512バイトを超える場合は、min-blob-sizeを`"512B"`または`"1KB"`に設定し、blob-file-compressionを`"zstd"`に設定することで、Titanによる圧縮I/Oフローを削減できます。 + - `RocksDB Compaction` : RocksDBの圧縮操作によって生成される読み取りおよび書き込みI/Oフローの合計。`RocksDB Compaction` `TiKV -> Rocksdb`よりも大幅に大きく、平均行サイズが512バイトを超える場合は、min-blob-sizeを`"512B"`または`"1KB"`に設定し、blob-file-compressionを`"zstd"`に設定することで、Titanによる圧縮I/Oフローを削減できます。 ```toml [rocksdb.titan] @@ -331,7 +331,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - アプリケーションサーバーからデータベースへのネットワークレイテンシーが高い。例えば、パブリッククラウド環境では、アプリケーションとTiDBクラスタが同じリージョンに存在しない、またはDNSワークロードバランサとTiDBクラスタが同じリージョンに存在しない場合、ネットワークレイテンシーが高くなります。 - ボトルネックとなっているのはクライアントアプリケーションです。アプリケーションサーバーのCPUコアとNumaリソースを最大限に活用できていません。例えば、TiDBへの数千ものJDBC接続を確立するのに、たった1つのJVMしか使用されていません。 -「接続数」パネルでは、総接続数と各TiDBノードの接続数を確認できます。これにより、総接続数が正常かどうか、また各TiDBノードの接続数が不均衡かどうかを確認できます。1 `active connections`アクティブな接続数を示し、これは1秒あたりのデータベース時間に相当します。右側のY軸（ `disconnection/s` ）は、クラスター内の1秒あたりの切断数を示しており、アプリケーションが短い接続を使用しているかどうかを判断するのに役立ちます。 +「接続数」パネルでは、総接続数と各TiDBノードの接続数を確認できます。これにより、総接続数が正常かどうか、また各TiDBノードの接続数が不均衡かどうかを確認できます。`active connections`アクティブな接続数を示し、これは1秒あたりのデータベース時間に相当します。右側のY軸（ `disconnection/s` ）は、クラスター内の1秒あたりの切断数を示しており、アプリケーションが短い接続を使用しているかどうかを判断するのに役立ちます。 **例1: 切断回数が多すぎる** @@ -341,7 +341,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - すべての SQL ステートメントの平均レイテンシーと P99レイテンシーは、それぞれ 10.8 ミリ秒と 84.1 ミリ秒です。 - トランザクション`avg-in-txn`の平均接続アイドル時間は 9.4 ミリ秒です。 -- クラスタへの総接続数は3,700で、各TiDBノードへの接続数は1,800です。アクティブ接続の平均数は40.3で、ほとんどの接続がアイドル状態であることを示しています。1 `disconnection/s`平均数は55.8で、アプリケーションが頻繁に接続と切断を繰り返していることを示しています。短い接続の動作は、TiDBのリソースと応答時間に一定の影響を与えます。 +- クラスタへの総接続数は3,700で、各TiDBノードへの接続数は1,800です。アクティブ接続の平均数は40.3で、ほとんどの接続がアイドル状態であることを示しています。`disconnection/s`平均数は55.8で、アプリケーションが頻繁に接続と切断を繰り返していることを示しています。短い接続の動作は、TiDBのリソースと応答時間に一定の影響を与えます。 **例2: TiDBがユーザー応答時間のボトルネックとなっている** @@ -492,7 +492,7 @@ v5.4.0 では、gPRC モジュールが最適化され、 Raftログのレプリ `Commit Log Duration` `Apply Log Duration` 、raftstore内の主要な操作のレイテンシー指標です。これらのレイテンシはバッチ操作レベルで計測され、各操作は複数の書き込みリクエストを組み合わせます。したがって、これら`Append Log Duration`レイテンシは前述の`Store Duration`と`Apply Duration`に直接対応するものではありません。 -- `Commit Log Duration`と`Append Log Duration` 、 `Store`スレッドで実行された操作時間を記録します。6 `Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。8 `Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。12 は、通常、 `Append Log Duration`よりも大幅に大きくなります。 `Commit Log Duration` 、前者には、ネットワークを介してRaftログを他の TiKV ノードにコピーする時間が含まれるためです。 +- `Commit Log Duration`と`Append Log Duration` 、 `Store`スレッドで実行された操作時間を記録します。`Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。`Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。12 は、通常、 `Append Log Duration`よりも大幅に大きくなります。 `Commit Log Duration` 、前者には、ネットワークを介してRaftログを他の TiKV ノードにコピーする時間が含まれるためです。 - `Apply Log Duration` `Apply`スレッドによる`apply` Raftログのレイテンシーを記録します。 `Commit Log Duration`が長い場合の一般的なシナリオ: diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index 4a38d9b2bb39d..edb1a9879be1b 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -28,7 +28,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー ### データベース時間 {#database-time} -データベース時間は、データベースが提供するサービス時間の合計を示します。1 `ΔT`データベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。 +データベース時間は、データベースが提供するサービス時間の合計を示します。`ΔT`データベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。 データベースの時間を取得するには、次のいずれかの方法を使用できます。 diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index a104543980128..c1d7e75b399cb 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -296,7 +296,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 - シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2 回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 - SQLフェーズ別データベース時間では、 `execute`最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 -- 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。3 `tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 +- 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 TiDB v6.0 は`rc read`提供します。これは`tso cmd`削減することで`read committed`分離レベルを最適化します。この機能はグローバル変数`set global tidb_rc_read_check_ts=on;`によって制御されます。この変数を有効にすると、TiDB のデフォルトの動作は`repeatable-read`分離レベルと同じように動作し、PD から取得する必要があるのは`start-ts`と`commit-ts`です。トランザクション内のステートメントは、最初に`start-ts`使用して TiKV からデータを読み取ります。TiKV から読み取られたデータが`start-ts`より前の場合、データは直接返されます。TiKV から読み取られたデータが`start-ts`より後の場合、データは破棄されます。TiDB は PD から TSO を要求し、読み取りを再試行します。後続のステートメントの`for update ts`では、最新の PD TSO が使用されます。 diff --git a/pipelined-dml.md b/pipelined-dml.md index 51f04639ac86e..90a3de5db7a98 100644 --- a/pipelined-dml.md +++ b/pipelined-dml.md @@ -132,7 +132,7 @@ SELECT @@tidb_last_txn_info; ### パイプライン DML を使用してクエリが実行されなかったのはなぜですか? {#why-wasn-t-my-query-executed-using-pipelined-dml} -TiDBがパイプラインDMLを使用したステートメントの実行を拒否した場合、それに応じた警告メッセージが生成されます。1 `SHOW WARNINGS;`実行すると警告の内容を確認し、原因を特定できます。 +TiDBがパイプラインDMLを使用したステートメントの実行を拒否した場合、それに応じた警告メッセージが生成されます。`SHOW WARNINGS;`実行すると警告の内容を確認し、原因を特定できます。 一般的な理由: diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index e382fde3078b8..7f3269a981a49 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -148,7 +148,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and 上記のステートメントの結果: -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。6 フィールドが`AVAILABLE` `1`なると、このステータスは変更されなくなります。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`利用可能、 `0`利用不可を意味します。6 フィールドが`AVAILABLE` `1`なると、このステータスは変更されなくなります。 - `PROGRESS`レプリケーションの進行状況を表します。値は0.0～1.0の範囲です。1はTiFlashレプリカのレプリケーションの進行状況が完了したことを意味します。 ### ステップ5. HTAPを使用してデータをより速く分析する {#step-5-analyze-data-faster-using-htap} diff --git a/read-historical-data.md b/read-historical-data.md index a6610a8210ec4..8f7c61e1cdd1e 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -22,7 +22,7 @@ TiDB は、特別なクライアントやドライバーを使用せずに、標 ## TiDBが履歴バージョンからデータを読み取る方法 {#how-tidb-reads-data-from-history-versions} -[`tidb_snapshot`](/system-variables.md#tidb_snapshot)のシステム変数は、履歴データの読み取りをサポートするために導入されました。3 `tidb_snapshot`の変数について： +[`tidb_snapshot`](/system-variables.md#tidb_snapshot)のシステム変数は、履歴データの読み取りをサポートするために導入されました。`tidb_snapshot`の変数について： - 変数は`SESSION`スコープ内で有効です。 - その値は`SET`ステートメントを使用して変更できます。 diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index 8f9396d8adea3..061db317d0e47 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -30,7 +30,7 @@ TiDB Ansible バージョン: 2.1.17 - SQLオプティマイザー - `EvalSubquery`ビルド`Executor` 中にエラーが発生したときにエラーメッセージが正しく返されない問題を修正 [＃11811](https://github.com/pingcap/tidb/pull/11811) - - インデックスルックアップ結合において、外部テーブルの行数が単一バッチの行数より多い場合にクエリ結果が正しくない可能性がある問題を修正しました。インデックスルックアップ結合の機能範囲を拡張しました。1 `UnionScan` `IndexJoin` のサブノードとして使用できます。 [＃11843](https://github.com/pingcap/tidb/pull/11843) + - インデックスルックアップ結合において、外部テーブルの行数が単一バッチの行数より多い場合にクエリ結果が正しくない可能性がある問題を修正しました。インデックスルックアップ結合の機能範囲を拡張しました。`UnionScan` `IndexJoin` のサブノードとして使用できます。 [＃11843](https://github.com/pingcap/tidb/pull/11843) - 統計フィードバック処理中に無効なキーが発生する可能性がある状況に備えて、 `SHOW STAT_BUCKETS`構文に無効なキー（ `invalid encoded key flag 252`など）の表示を追加します[＃12098](https://github.com/pingcap/tidb/pull/12098) - SQL実行エンジン - `CAST`関数が数値型を変換するときに最初に`UINT`に変換される数値によって発生するいくつかの誤った結果 ( `select cast(13835058000000000000 as double)`など) を修正しました。 [＃11712](https://github.com/pingcap/tidb/pull/11712) diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index 85565b7678af1..d6dcf5cd75c08 100644 --- a/releases/release-2.1.19.md +++ b/releases/release-2.1.19.md @@ -17,7 +17,7 @@ TiDB Ansible バージョン: 2.1.19 - `select max(_tidb_rowid) from t`のシナリオを最適化して、テーブル全体のスキャンを回避する[＃13294](https://github.com/pingcap/tidb/pull/13294) - クエリ内のユーザー変数に割り当てられた誤った値と述語のプッシュダウンによって発生する誤った結果を修正しました[＃13230](https://github.com/pingcap/tidb/pull/13230) - 統計情報の更新時にデータ競合が発生し、統計情報が正確でない問題を修正しました[＃13690](https://github.com/pingcap/tidb/pull/13690) - - `UPDATE`ステートメントにサブクエリとストアされた生成列の両方が含まれている場合に結果が正しくない問題を修正しました。3 `UPDATE`ステートメントに異なるデータベースの同じ名前のテーブルが 2 つ含まれている場合にステートメント実行エラーが発生する問題を修正しました[＃13357](https://github.com/pingcap/tidb/pull/13357) + - `UPDATE`ステートメントにサブクエリとストアされた生成列の両方が含まれている場合に結果が正しくない問題を修正しました。`UPDATE`ステートメントに異なるデータベースの同じ名前のテーブルが 2 つ含まれている場合にステートメント実行エラーが発生する問題を修正しました[＃13357](https://github.com/pingcap/tidb/pull/13357) - `PhysicalUnionScan`演算子が統計誤って設定するため、クエリ プランが誤って選択される可能性がある問題を修正しました。 [＃14134](https://github.com/pingcap/tidb/pull/14134) - `minAutoAnalyzeRatio`制約を取り除き、自動`ANALYZE`をよりタイムリーにする [＃14013](https://github.com/pingcap/tidb/pull/14013) - `WHERE`句に一意キー等号条件が含まれている場合に推定行数が`1`より大きくなる問題を修正しました。 [＃13385](https://github.com/pingcap/tidb/pull/13385) diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index d3bb7ea323b64..3f5dfc0efcf9d 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -44,7 +44,7 @@ TiDB Ansible バージョン: 3.0.2 - `DATE_ADD`と`DATE_SUB`関数の結果が超える場合に`NULL`返されない場合がある問題を修正しました。 [＃11476](https://github.com/pingcap/tidb/pull/11476) - 長い文字列を整数に変換するときに、文字列に無効な文字が含まれているとMySQLの変換結果と異なる問題を修正しました。 [＃11469](https://github.com/pingcap/tidb/pull/11469) - この関数大文字と小文字の区別により、関数`REGEXP BINARY`の結果がMySQLと互換性がない問題を修正しました。 [＃11504](https://github.com/pingcap/tidb/pull/11504) - - `GRANT ROLE`文が`CURRENT_ROLE`受け取ったときにエラーが報告される問題を修正します。5 `REVOKE ROLE`が`mysql.default_role`権限を正しく取り消さない問題を修正します。 [＃11356](https://github.com/pingcap/tidb/pull/11356) + - `GRANT ROLE`文が`CURRENT_ROLE`受け取ったときにエラーが報告される問題を修正します。`REVOKE ROLE`が`mysql.default_role`権限を正しく取り消さない問題を修正します。 [＃11356](https://github.com/pingcap/tidb/pull/11356) - `SELECT ADDDATE('2008-01-34', -1)` のような文を実行する際の`Incorrect datetime value`警告情報の表示形式の問題を修正しました [＃11447](https://github.com/pingcap/tidb/pull/11447) - JSONデータの浮動小数点フィールドを整数に変換するときに結果がオーバーフローすると、エラーメッセージが`constant … overflows bigint`ではなく`constant … overflows float`報告する問題を修正しました。 [＃11534](https://github.com/pingcap/tidb/pull/11534) - `DATE_ADD`関数が`FLOAT` 、 `DOUBLE` 、 `DECIMAL`列のパラメータを受け取ったときに、誤った型変換によって結果が間違ってしまう可能性がある問題を修正しました[＃11527](https://github.com/pingcap/tidb/pull/11527) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 39bfb49ea889b..8d0381f5d70c7 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -19,7 +19,7 @@ TiDB Ansible バージョン: 3.0.6 - SQLバインディングで引用符が正しく処理されない問題を修正 [＃13117](https://github.com/pingcap/tidb/pull/13117) - `select max(_tidb_rowid) from t`シナリオを最適化してテーブル全体のスキャンを回避する[＃13095](https://github.com/pingcap/tidb/pull/13095) - クエリステートメントに変数代入式が含まれている場合にクエリ結果が正しくない問題を修正しました[＃13231](https://github.com/pingcap/tidb/pull/13231) - - `UPDATE`ステートメントにサブクエリと生成された列の両方が含まれている場合に結果が正しくない問題を修正しました。3 `UPDATE`ステートメントに異なるソース データベースからの同じ名前のテーブルが 2 つ含まれている場合に発生するステートメント実行エラーを修正しました[＃13350](https://github.com/pingcap/tidb/pull/13350) + - `UPDATE`ステートメントにサブクエリと生成された列の両方が含まれている場合に結果が正しくない問題を修正しました。`UPDATE`ステートメントに異なるソース データベースからの同じ名前のテーブルが 2 つ含まれている場合に発生するステートメント実行エラーを修正しました[＃13350](https://github.com/pingcap/tidb/pull/13350) - ポイントクエリのサポート`_tidb_rowid` [＃13416](https://github.com/pingcap/tidb/pull/13416) - パーティションテーブル統計の不適切な使用により、生成されたクエリ実行プランが正しくない問題を修正しました[＃13628](https://github.com/pingcap/tidb/pull/13628) - SQL実行エンジン diff --git a/releases/release-3.0.9.md b/releases/release-3.0.9.md index 890097867dd36..f26bba6db8e39 100644 --- a/releases/release-3.0.9.md +++ b/releases/release-3.0.9.md @@ -30,7 +30,7 @@ TiDB Ansible バージョン: 3.0.9 - `primary`列に`alter table ... add index`を使用して作成された匿名インデックスの結果がMySQL と一致しない問題を修正しました [＃14310](https://github.com/pingcap/tidb/pull/14310) - `drop table`構文で`VIEW`が誤って削除される問題を修正[＃14052](https://github.com/pingcap/tidb/pull/14052) - プランナー - - `select max(a), min(a) from t`のような文のパフォーマンスを最適化します。3 `a`にインデックスが存在する場合、文は`select * from (select a from t order by a desc limit 1) as t1, (select a from t order by a limit 1) as t2`に最適化され、フルテーブルスキャンを回避します。 [＃14410](https://github.com/pingcap/tidb/pull/14410) + - `select max(a), min(a) from t`のような文のパフォーマンスを最適化します。`a`にインデックスが存在する場合、文は`select * from (select a from t order by a desc limit 1) as t1, (select a from t order by a limit 1) as t2`に最適化され、フルテーブルスキャンを回避します。 [＃14410](https://github.com/pingcap/tidb/pull/14410) ## TiKV {#tikv} diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 40f315676641c..f0a454d66eac1 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -117,7 +117,7 @@ TiDB バージョン: 4.0.0-rc.1 - `show create table`文のデフォルトシーケンス値の誤った表示を修正 [＃16526](https://github.com/pingcap/tidb/pull/16526) - シーケンスが主キーのデフォルト値として使用されるために`not-null`エラーが返される問題を修正しました [＃16510](https://github.com/pingcap/tidb/pull/16510) - TiKVが`StaleCommand`エラーを返し続けているときに、ブロックされたSQL実行に対してエラーが報告されない問題を修正しました。 [＃16530](https://github.com/pingcap/tidb/pull/16530) -- データベースの作成時に`COLLATE`を指定するとエラーが報告される問題を修正しました。5 `SHOW CREATE DATABASE`の結果に不足している`COLLATE`部分を追加します[＃16540](https://github.com/pingcap/tidb/pull/16540) +- データベースの作成時に`COLLATE`を指定するとエラーが報告される問題を修正しました。`SHOW CREATE DATABASE`の結果に不足している`COLLATE`部分を追加します[＃16540](https://github.com/pingcap/tidb/pull/16540) - プランキャッシュが有効な場合のパーティションプルーニングの失敗を修正[＃16723](https://github.com/pingcap/tidb/pull/16723) - オーバーフロー処理時に誤った結果を返すバグ`PointGet`修正 [＃16755](https://github.com/pingcap/tidb/pull/16755) - 同じ時間値を持つ`slow_query`システムテーブルをクエリすると間違った結果が返される問題を修正しました[＃16806](https://github.com/pingcap/tidb/pull/16806) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 94f83a2fde705..e9c755453f544 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -211,7 +211,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - JSON形式での実行プランの出力をサポート[＃39261](https://github.com/pingcap/tidb/issues/39261) @ [fzzf678](https://github.com/fzzf678) - TiDB v6.5.0では、実行プランの出力形式が拡張されました。3 `EXPLAIN`に`FORMAT = "tidb_json"`指定することで、SQL実行プランをJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行プランをより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。 + TiDB v6.5.0では、実行プランの出力形式が拡張されました。`EXPLAIN`に`FORMAT = "tidb_json"`指定することで、SQL実行プランをJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行プランをより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。 詳細については[ドキュメント](/sql-statements/sql-statement-explain.md)参照してください。 @@ -331,7 +331,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`tidb_ttl_delete_batch_size`](/system-variables.md#tidb_ttl_delete_batch_size-new-in-v650) | 新しく追加された | この変数は、TTL ジョブ内の単一`DELETE`トランザクションで削除できる行の最大数を設定するために使用されます。 | | [`tidb_ttl_delete_rate_limit`](/system-variables.md#tidb_ttl_delete_rate_limit-new-in-v650) | 新しく追加された | この変数は、TTLジョブにおいて単一ノードで1秒あたりに許可される`DELETE`ステートメントの最大数を制限するために使用されます。この変数を`0`に設定すると、制限は適用されません。 | | [`tidb_ttl_delete_worker_count`](/system-variables.md#tidb_ttl_delete_worker_count-new-in-v650) | 新しく追加された | この変数は、各 TiDB ノード上の TTL ジョブの最大同時実行数を設定するために使用されます。 | -| [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650) | 新しく追加された | この変数は、TTLジョブを有効にするかどうかを制御するために使用されます。1 `OFF`設定すると、TTL属性を持つすべてのテーブルで期限切れデータのクリーンアップが自動的に停止されます。 | +| [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650) | 新しく追加された | この変数は、TTLジョブを有効にするかどうかを制御するために使用されます。`OFF`設定すると、TTL属性を持つすべてのテーブルで期限切れデータのクリーンアップが自動的に停止されます。 | | `tidb_ttl_job_run_interval` | 新しく追加された | この変数は、バックグラウンドでのTTLジョブのスケジュール間隔を制御するために使用されます。例えば、現在の値が`1h0m0s`に設定されている場合、TTL属性を持つ各テーブルは、期限切れのデータを1時間ごとにクリーンアップします。 | | [`tidb_ttl_job_schedule_window_start_time`](/system-variables.md#tidb_ttl_job_schedule_window_start_time-new-in-v650) | 新しく追加された | この変数は、バックグラウンドで実行されるTTLジョブのスケジュールウィンドウの開始時刻を制御するために使用されます。この変数の値を変更する際は、ウィンドウが小さいと期限切れデータのクリーンアップが失敗する可能性があるので注意してください。 | | [`tidb_ttl_job_schedule_window_end_time`](/system-variables.md#tidb_ttl_job_schedule_window_end_time-new-in-v650) | 新しく追加された | この変数は、バックグラウンドで実行されるTTLジョブのスケジュールウィンドウの終了時刻を制御するために使用されます。この変数の値を変更する際は、ウィンドウが小さいと期限切れデータのクリーンアップが失敗する可能性があるので注意してください。 | diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 4dad15890f21d..ae1b81e5566ca 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -142,7 +142,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDB v6.5.0以降、 `INSERT INTO SELECT`ステートメントの`SELECT`の句（分析クエリ）をTiFlashにプッシュダウンできるようになりました。これにより、 TiFlashクエリの結果を`INSERT INTO`の句で指定されたTiDBテーブルに簡単に保存し、さらに分析することができます。これは、結果のキャッシュ（つまり、結果のマテリアライゼーション）として機能します。 - この機能はバージョン7.1.0で一般公開されています。3 `INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザーは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 + この機能はバージョン7.1.0で一般公開されています。`INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザーは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)参照してください。 @@ -250,7 +250,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) | 変更 | バージョン7.1.0以降で有効となり、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を制御します。追加のテストを経て、デフォルト値を`"0s"`から`"1s"`に変更します。 | | [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、 TiFlash の遅延マテリアライゼーション機能がデフォルトで有効になっていることを意味します。 | | [`authentication_ldap_sasl_auth_method_name`](/system-variables.md#authentication_ldap_sasl_auth_method_name-new-in-v710) | 新しく追加された | LDAP SASL 認証における認証方法名を指定します。 | -| [`authentication_ldap_sasl_bind_base_dn`](/system-variables.md#authentication_ldap_sasl_bind_base_dn-new-in-v710) | 新しく追加された | LDAP SASL認証における検索ツリー内の検索範囲を制限します。1 `AS ...`の句を指定せずにユーザーが作成された場合、TiDBはユーザー名に基づいてLDAPサーバー内の`dn`の句を自動的に検索します。 | +| [`authentication_ldap_sasl_bind_base_dn`](/system-variables.md#authentication_ldap_sasl_bind_base_dn-new-in-v710) | 新しく追加された | LDAP SASL認証における検索ツリー内の検索範囲を制限します。`AS ...`の句を指定せずにユーザーが作成された場合、TiDBはユーザー名に基づいてLDAPサーバー内の`dn`の句を自動的に検索します。 | | [`authentication_ldap_sasl_bind_root_dn`](/system-variables.md#authentication_ldap_sasl_bind_root_dn-new-in-v710) | 新しく追加された | LDAP SASL 認証でユーザーを検索するために LDAPサーバーにログインするために使用される`dn`指定します。 | | [`authentication_ldap_sasl_bind_root_pwd`](/system-variables.md#authentication_ldap_sasl_bind_root_pwd-new-in-v710) | 新しく追加された | LDAP SASL 認証でユーザーを検索するために LDAPサーバーにログインするために使用されるパスワードを指定します。 | | [`authentication_ldap_sasl_ca_path`](/system-variables.md#authentication_ldap_sasl_ca_path-new-in-v710) | 新しく追加された | LDAP SASL 認証における StartTLS 接続用の証明機関ファイルの絶対パスを指定します。 | @@ -259,8 +259,8 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`authentication_ldap_sasl_server_host`](/system-variables.md#authentication_ldap_sasl_server_host-new-in-v710) | 新しく追加された | LDAP SASL 認証で LDAPサーバーホストを指定します。 | | [`authentication_ldap_sasl_server_port`](/system-variables.md#authentication_ldap_sasl_server_port-new-in-v710) | 新しく追加された | LDAP SASL 認証における LDAPサーバーのTCP/IP ポート番号を指定します。 | | [`authentication_ldap_sasl_tls`](/system-variables.md#authentication_ldap_sasl_tls-new-in-v710) | 新しく追加された | プラグインによる LDAPサーバーへの接続が LDAP SASL 認証の StartTLS で保護されるかどうかを指定します。 | -| [`authentication_ldap_simple_auth_method_name`](/system-variables.md#authentication_ldap_simple_auth_method_name-new-in-v710) | 新しく追加された | LDAP簡易認証における認証方式名を指定します。1 `SIMPLE`サポートされます。 | -| [`authentication_ldap_simple_bind_base_dn`](/system-variables.md#authentication_ldap_simple_bind_base_dn-new-in-v710) | 新しく追加された | LDAP簡易認証における検索ツリー内の検索範囲を制限します。1 `AS ...`の句を指定せずにユーザーが作成された場合、TiDBはユーザー名に基づいてLDAPサーバー内の`dn`の句を自動的に検索します。 | +| [`authentication_ldap_simple_auth_method_name`](/system-variables.md#authentication_ldap_simple_auth_method_name-new-in-v710) | 新しく追加された | LDAP簡易認証における認証方式名を指定します。`SIMPLE`サポートされます。 | +| [`authentication_ldap_simple_bind_base_dn`](/system-variables.md#authentication_ldap_simple_bind_base_dn-new-in-v710) | 新しく追加された | LDAP簡易認証における検索ツリー内の検索範囲を制限します。`AS ...`の句を指定せずにユーザーが作成された場合、TiDBはユーザー名に基づいてLDAPサーバー内の`dn`の句を自動的に検索します。 | | [`authentication_ldap_simple_bind_root_dn`](/system-variables.md#authentication_ldap_simple_bind_root_dn-new-in-v710) | 新しく追加された | LDAP 簡易認証でユーザーを検索するために LDAPサーバーにログインするために使用される`dn`指定します。 | | [`authentication_ldap_simple_bind_root_pwd`](/system-variables.md#authentication_ldap_simple_bind_root_pwd-new-in-v710) | 新しく追加された | LDAP 簡易認証でユーザーを検索するために LDAPサーバーにログインするために使用されるパスワードを指定します。 | | [`authentication_ldap_simple_ca_path`](/system-variables.md#authentication_ldap_simple_ca_path-new-in-v710) | 新しく追加された | LDAP 簡易認証での StartTLS 接続用の証明機関ファイルの絶対パスを指定します。 | diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 3154eec22c2fc..e6d14cd6013c4 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -176,7 +176,7 @@ TiDB バージョン: 7.4.0 - 照合順序`utf8mb4_0900_ai_ci`と`utf8mb4_0900_bin`をサポート [＃37566](https://github.com/pingcap/tidb/issues/37566) @ [YangKeao](https://github.com/YangKeao) @ [zimulala](https://github.com/zimulala) @ [bb7133](https://github.com/bb7133) - TiDB v7.4.0 では、MySQL 8.0 からのデータ移行のサポートが強化され、 `utf8mb4_0900_ai_ci`と`utf8mb4_0900_bin` 2 つの照合順序が追加されました。5 `utf8mb4_0900_ai_ci` MySQL 8.0 のデフォルトの照合順序です。 + TiDB v7.4.0 では、MySQL 8.0 からのデータ移行のサポートが強化され、 `utf8mb4_0900_ai_ci`と`utf8mb4_0900_bin` 2 つの照合順序が追加されました。`utf8mb4_0900_ai_ci` MySQL 8.0 のデフォルトの照合順序です。 TiDB v7.4.0では、MySQL 8.0と互換性のあるシステム変数`default_collation_for_utf8mb4`も導入されました。これにより、utf8mb4文字セットのデフォルトの照合順序を指定できるようになり、 MySQL 5.7以前のバージョンからの移行やデータレプリケーションとの互換性が確保されます。 @@ -258,7 +258,7 @@ TiDB バージョン: 7.4.0 | [`default_collation_for_utf8mb4`](/system-variables.md#default_collation_for_utf8mb4-new-in-v740) | 新しく追加された | `utf8mb4`文字セットのデフォルトの照合順序を制御します。デフォルト値は`utf8mb4_bin`です。 | | [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) | 新しく追加された | 有効にするクラウドストレージURI を指定します[グローバルソート](/tidb-global-sort.md) 。 | | [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。3 に`OFF`すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | -| [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。1 `moderate` TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。3 `determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | +| [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。`moderate` TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。`determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | | [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) | 新しく追加された | 現在のセッションのタスクタイプを明示的に指定します。タスクタイプは[リソース管理](/tidb-resource-control-ru-groups.md)によって識別および制御されます。例: `SET @@tidb_request_source_type = "background"` 。 | | [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740) | 新しく追加された | この変数は、TiDBインスタンスにキャッシュできる履歴スキーマバージョンの数を制限します。デフォルト値は`16`で、これはTiDBがデフォルトで16個の履歴スキーマバージョンをキャッシュすることを意味します。 | | [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) | 新しく追加された | この変数はインスタンスレベルのシステム変数です。これを使用して、 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)配下のTiDBノードのサービススコープを制御できます。TiDBノードの`tidb_service_scope` `background`に設定すると、DXFはそのTiDBノードで[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)や[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)などのDXFタスクを実行するようにスケジュールします。 | diff --git a/releases/versioning.md b/releases/versioning.md index 63a64f612441b..179b9951c55ba 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -32,7 +32,7 @@ TiDB v5.0.0 以前のバージョンのバージョン管理システムにつ 長期サポート (LTS) バージョンは約 6 か月ごとにリリースされ、新しい機能、改善、バグ修正、セキュリティ脆弱性修正が導入されます。 -LTS リリースのバージョンは`X.Y.Z`です。3 `Z`デフォルトは 0 です。 +LTS リリースのバージョンは`X.Y.Z`です。`Z`デフォルトは 0 です。 例のバージョン: @@ -41,7 +41,7 @@ LTS リリースのバージョンは`X.Y.Z`です。3 `Z`デフォルトは 0 LTS のライフサイクル中は、パッチリリースがオンデマンドで提供されます。パッチリリースにはバグ修正とセキュリティ脆弱性の修正が含まれており、新機能は導入されません。 -パッチリリースのバージョン番号は`X.Y.Z`です。3 `X.Y`対応する LTS バージョン番号と一致しています。パッチ番号`Z` 1 から増加します。 +パッチリリースのバージョン番号は`X.Y.Z`です。`X.Y`対応する LTS バージョン番号と一致しています。パッチ番号`Z` 1 から増加します。 例のバージョン: @@ -57,7 +57,7 @@ v5.1.0、v5.2.0、v5.3.0、v5.4.0 は、前のリリースからわずか 2 か 開発マイルストーンリリース（DMR）は、LTSを含まない約2ヶ月ごとにリリースされます。DMRバージョンでは、新機能、改善、バグ修正が導入されます。TiDBはDMRに基づくパッチリリースを提供しておらず、関連するバグは後続のリリースシリーズで修正されます。 -DMR のバージョン番号は`X.Y.Z`です。3 `Z`デフォルトで 0 になります。バージョン番号に`-DMR`というサフィックスが追加されます。 +DMR のバージョン番号は`X.Y.Z`です。`Z`デフォルトで 0 になります。バージョン番号に`-DMR`というサフィックスが追加されます。 例のバージョン: diff --git a/runtime-filter.md b/runtime-filter.md index 80480b274e9be..40a94d4eaec21 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -22,7 +22,7 @@ summary: ランタイム フィルターの動作原理とその使用方法を ### 例 {#example} -`store_sales`テーブルと`date_dim`テーブルの間に結合クエリがあり、結合方法はハッシュ結合であるとします。5 `store_sales`主に店舗の売上データを格納するファクトテーブルで、行数は100万行です。7 `date_dim`主に日付情報を格納する時間ディメンションテーブルです。2001年の売上データを取得するクエリを実行するため、 `date_dim`テーブルの365行が結合操作に関係します。 +`store_sales`テーブルと`date_dim`テーブルの間に結合クエリがあり、結合方法はハッシュ結合であるとします。`store_sales`主に店舗の売上データを格納するファクトテーブルで、行数は100万行です。`date_dim`主に日付情報を格納する時間ディメンションテーブルです。2001年の売上データを取得するクエリを実行するため、 `date_dim`テーブルの365行が結合操作に関係します。 ```sql SELECT * FROM store_sales, date_dim diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index bd3d0eaf9dc0a..bcecceac46aa3 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -84,8 +84,8 @@ scheduling_servers: 上記のコマンドでは、 - `scale-out.yml`はスケールアウト構成ファイルです。 -- `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 -- `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインにパスワードを使用しない設定をしている場合は、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。8 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 +- `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。`root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 +- `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインにパスワードを使用しない設定をしている場合は、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 `Scaled cluster out successfully`表示された場合、スケールアウト操作は成功しています。 diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index da495762cb29f..7b50de3ef6616 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -107,8 +107,8 @@ TiDB クラスターの容量は、オンライン サービスを中断する 上記のコマンドでは、 - `scale-out.yml`はスケールアウト構成ファイルです。 - - `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 - - `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。8 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 + - `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。`root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 + - `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 `Scaled cluster out successfully`表示された場合、スケールアウト操作は成功しています。 @@ -338,13 +338,13 @@ TiDB クラスターの容量は、オンライン サービスを中断する ### 1. 残りのTiFlashノードの数に応じてテーブルのレプリカ数を調整する {#1-adjust-the-number-of-replicas-of-the-tables-according-to-the-number-of-remaining-tiflash-nodes} -1. スケールイン後のTiFlashノード数を超えるTiFlashレプリカを持つテーブルがあるかどうかを照会します。1 `tobe_left_nodes`スケールイン後のTiFlashノード数を意味します。クエリ結果が空の場合、 TiFlashのスケールインを開始できます。クエリ結果が空でない場合は、関連テーブルのTiFlashレプリカ数を変更する必要があります。 +1. スケールイン後のTiFlashノード数を超えるTiFlashレプリカを持つテーブルがあるかどうかを照会します。`tobe_left_nodes`スケールイン後のTiFlashノード数を意味します。クエリ結果が空の場合、 TiFlashのスケールインを開始できます。クエリ結果が空でない場合は、関連テーブルのTiFlashレプリカ数を変更する必要があります。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE REPLICA_COUNT > 'tobe_left_nodes'; ``` -2. スケールイン後のTiFlashノードの数より多いTiFlashレプリカを持つすべてのテーブルに対して次のステートメントを実行します。1 `new_replica_num` `tobe_left_nodes`である必要があります。 +2. スケールイン後のTiFlashノードの数より多いTiFlashレプリカを持つすべてのテーブルに対して次のステートメントを実行します。`new_replica_num` `tobe_left_nodes`である必要があります。 ```sql ALTER TABLE . SET tiflash replica 'new_replica_num'; diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 4ef273417acda..01417437beb1b 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -223,7 +223,7 @@ host = "" > **注記：** > > - 設定を有効にするには、PDに`location-labels` 、TiKVに`labels`同時に設定する必要があります。そうしないと、PDはトポロジに従ってスケジューリングを実行しません。 -> - SQL の配置ルールを使用する場合、TiKV の場合は`labels`のみ設定する必要があります。現在、SQL の配置ルールは PD の`location-labels`設定と互換性がなく、この設定は無視されます。5 `location-labels` SQL の配置ルールを同時に使用することは推奨されません。予期しない結果が発生する可能性があります。 +> - SQL の配置ルールを使用する場合、TiKV の場合は`labels`のみ設定する必要があります。現在、SQL の配置ルールは PD の`location-labels`設定と互換性がなく、この設定は無視されます。`location-labels` SQL の配置ルールを同時に使用することは推奨されません。予期しない結果が発生する可能性があります。 `location-labels`構成するには、クラスターの状況に応じて次のいずれかの方法を選択します。 @@ -277,6 +277,6 @@ PD はラベルレイヤーに従ってレプリカをスケジュールし、 `isolation-level`設定が`zone`に設定されている場合、これは物理レベルでのリージョンレプリカの最小分離要件を指定します。この場合、PD は常に同じリージョンのレプリカが異なるゾーンに分散されることを保証します。この分離制限に従うことで`max-replicas`のマルチレプリカ要件が満たされない場合でも、PD はそれに応じてスケジュールを設定しません。3 つのデータ ゾーン (z1、z2、z3) に分散された TiKV クラスターを例にとると、各リージョンに 3 つのレプリカが必要な場合、PD は同じリージョンの 3 つのレプリカをそれぞれこれらの 3 つのデータ ゾーンに分散します。z1 で停電が発生し、一定時間 (デフォルトでは 30 分、 [`max-store-down-time`](/pd-configuration-file.md#max-store-down-time)によって制御) が経過しても回復できない場合、PD は z1 のリージョンレプリカが使用できなくなったと判断します。ただし、 `isolation-level` `zone`に設定されているため、PD は、同じリージョンの異なるレプリカが同じデータ ゾーンにスケジュールされないことを厳密に保証する必要があります。 z2 と z3 の両方にすでにレプリカがあるため、現時点でレプリカが 2 つしかない場合でも、PD は最小分離レベル制限`isolation-level`の下ではスケジュールを実行しません。 -同様に、 `isolation-level` `rack`に設定すると、同一データセンター内の異なるラックに最小分離レベルが適用されます。この構成では、ゾーンレイヤーでの分離が可能な限り最初に保証されます。ゾーンレベルでの分離が保証できない場合、PD は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。5 `host` `isolation-level`設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 +同様に、 `isolation-level` `rack`に設定すると、同一データセンター内の異なるラックに最小分離レベルが適用されます。この構成では、ゾーンレイヤーでの分離が可能な限り最初に保証されます。ゾーンレベルでの分離が保証できない場合、PD は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。`host` `isolation-level`設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 要約すると、PDは現在のトポロジに応じてクラスターの災害復旧を最大化します。したがって、一定レベルの災害復旧を実現したい場合は、トポロジに応じて、異なるサイトに`max-replicas`台以上のマシンを展開する必要があります。TiDBは、 `isolation-level`などの必須構成項目も提供しており、さまざまなシナリオに応じてデータのトポロジ分離レベルをより柔軟に制御できます。 diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index 6f135ae66cb90..b19ca5b9d59a1 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -49,7 +49,7 @@ These limitations can be summarized as that you need to ensure that there are no #### TiUPを使用してアップグレードする {#use-tiup-to-upgrade} -v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つまり、 `tiup cluster upgrade`コマンドを使用してTiDBクラスタを直接アップグレードできます。3 `tiup cluster patch`は現在サポートされていないことに注意してください。 +v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つまり、 `tiup cluster upgrade`コマンドを使用してTiDBクラスタを直接アップグレードできます。`tiup cluster patch`は現在サポートされていないことに注意してください。 #### TiDB Operatorを使用してアップグレードする {#use-tidb-operator-to-upgrade} diff --git a/sql-plan-management.md b/sql-plan-management.md index 4cb6bcb00aff4..5fe9346536751 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -196,7 +196,7 @@ USING explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; ``` -最初の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングを介して`sm_join(t1, t2)`ヒントを文に追加します。5 `explain`の結果における実行プランの最上位ノードはMergeJoinです。2番目の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングではなくSESSIONスコープのバインディングを使用し、 `hash_join(t1, t2)`ヒントを文に追加します。11 `explain`の結果における実行プランの最上位ノードはHashJoinです。 +最初の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングを介して`sm_join(t1, t2)`ヒントを文に追加します。`explain`の結果における実行プランの最上位ノードはMergeJoinです。2番目の`SELECT`番目の文が実行されると、オプティマイザはGLOBALスコープのバインディングではなくSESSIONスコープのバインディングを使用し、 `hash_join(t1, t2)`ヒントを文に追加します。11 `explain`の結果における実行プランの最上位ノードはHashJoinです。 各標準化SQL文には、 `CREATE BINDING`ずつ作成できるバインディングが1つだけです。同じ標準化SQL文に複数のバインディングが作成された場合、最後に作成されたバインディングが保持され、それ以前に作成されたバインディング（作成済みおよび展開済み）はすべて削除済みとしてマークされます。ただし、セッションバインディングとグローバルバインディングは共存可能であり、このロジックの影響を受けません。 @@ -324,7 +324,7 @@ drop session binding for SELECT * FROM t1, t2 WHERE t1.id = t2.id; explain SELECT * FROM t1,t2 WHERE t1.id = t2.id; ``` -上記の例では、SESSIONスコープ内の削除されたバインディングが、GLOBALスコープ内の対応するバインディングを隠蔽しています。オプティマイザは、文に`sm_join(t1, t2)`ヒントを追加しません。3 `explain`の結果における実行プランのトップノードは、このヒントによってMergeJoinに固定されるわけではありません。代わりに、オプティマイザはコスト見積もりに基づいてトップノードを独自に選択します。 +上記の例では、SESSIONスコープ内の削除されたバインディングが、GLOBALスコープ内の対応するバインディングを隠蔽しています。オプティマイザは、文に`sm_join(t1, t2)`ヒントを追加しません。`explain`の結果における実行プランのトップノードは、このヒントによってMergeJoinに固定されるわけではありません。代わりに、オプティマイザはコスト見積もりに基づいてトップノードを独自に選択します。 #### SQLダイジェストに従ってバインディングを削除する {#remove-a-binding-according-to-sql-digest} diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index c746c756b5970..8de41d0a1cba3 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -202,7 +202,7 @@ TiDBの実行プランを特定する場合、対象となるSQL文と実行プ ### PLAN REPLAYER CAPTUREを有効にする {#enable-code-plan-replayer-capture-code} -`PLAN REPLAYER CAPTURE`はシステム変数[`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture)によって制御されます。4 `PLAN REPLAYER CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 +`PLAN REPLAYER CAPTURE`はシステム変数[`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture)によって制御されます。`PLAN REPLAYER CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 ### PLAN REPLAYER CAPTURE使用する {#use-code-plan-replayer-capture-code} @@ -286,7 +286,7 @@ Empty set (0.01 sec) ### PLAN REPLAYER CONTINUOUS CAPTUREを有効にする {#enable-code-plan-replayer-continuous-capture-code} -`PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。4 `PLAN REPLAYER CONTINUOUS CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 +`PLAN REPLAYER CONTINUOUS CAPTURE`はシステム変数[`tidb_enable_plan_replayer_continuous_capture`](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700)によって制御されます。`PLAN REPLAYER CONTINUOUS CAPTURE`有効にするには、システム変数の値を`ON`に設定します。 ### キャプチャ結果を表示する {#view-the-capture-results} diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ca01408c77a8b..78dabefad5ea5 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -280,7 +280,7 @@ MySQL [test]> select @@last_plan_from_cache; -- The cached plan cannot be select 1 row in set (0.00 sec) ``` -現在、TiDBは`GLOBAL`実行計画キャッシュのクリアをサポートしていません。つまり、TiDBクラスタ全体のキャッシュされた計画をクリアすることはできません。3 `GLOBAL`実行計画キャッシュをクリアしようとすると、以下のエラーが報告されます。 +現在、TiDBは`GLOBAL`実行計画キャッシュのクリアをサポートしていません。つまり、TiDBクラスタ全体のキャッシュされた計画をクリアすることはできません。`GLOBAL`実行計画キャッシュをクリアしようとすると、以下のエラーが報告されます。 ```sql MySQL [test]> admin flush global plan_cache; diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 742ed21e6f504..d150dbcc1fe9b 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -35,7 +35,7 @@ WhereClauseOptional ::= - `OWNER_ID` : DDL所有者のUUID。2 [`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)参照してください。 - `OWNER_ADDRESS` : DDL 所有者の IP アドレス。 - `RUNNING_JOBS` : 実行中の DDL ジョブの詳細。 -- `SELF_ID` : 現在接続しているTiDBノードのUUID。2 `SELF_ID` `OWNER_ID`と同じ場合は、DDL所有者に接続していることを意味します。 +- `SELF_ID` : 現在接続しているTiDBノードのUUID。`SELF_ID` `OWNER_ID`と同じ場合は、DDL所有者に接続していることを意味します。 - `QUERY` : クエリのステートメント。 ```sql @@ -59,7 +59,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 -- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。2 `JOB_ID`グローバルに一意です。 +- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。`JOB_ID`グローバルに一意です。 - `DB_NAME` : DDL 操作が実行されるデータベースの名前。 - `TABLE_NAME` : DDL 操作が実行されるテーブルの名前。 - `JOB_TYPE` : DDL操作の種類。一般的なジョブの種類は次のとおりです。 @@ -96,14 +96,14 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `DXF` : [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)で構成された Distributed eXecution Framework (DXF) を使用して実行されるタスク。 - `service_scope` : [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)で設定された TiDB ノードのサービス スコープ。 - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。4 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)指定することで動的な変更が可能です。 - - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。4 `ADMIN ALTER DDL JOBS`指定することで動的な変更が可能です。 + - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。`ADMIN ALTER DDL JOBS`指定することで動的な変更が可能です。 - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。4 による動的な変更`ADMIN ALTER DDL JOBS`サポートされます。 -- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。2 `JOB_ID`グローバルに一意です。 +- `JOB_ID` : 各 DDL 操作は DDL ジョブに対応します。`JOB_ID`グローバルに一意です。 - `DB_NAME` : DDL 操作が実行されるデータベースの名前。 - `TABLE_NAME` : DDL 操作が実行されるテーブルの名前。 - `JOB_TYPE` : DDL 操作のタイプ。 diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index aff601ba453a8..f649f27baa263 100644 --- a/sql-statements/sql-statement-alter-sequence.md +++ b/sql-statements/sql-statement-alter-sequence.md @@ -68,7 +68,7 @@ ALTER SEQUENCE sequence_name - `NEXTVAL`または`NEXT VALUE FOR` - 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。3 `NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 + 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。`NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 - `LASTVAL` diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index a2dea678f684a..094f8a9892ff7 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -95,7 +95,7 @@ EXPLAIN SELECT * FROM t1 WHERE c1 = 3; 3 rows in set (0.00 sec) ``` -ステートメント[`ALTER TABLE .. ADD INDEX`](/sql-statements/sql-statement-add-index.md)は、テーブル t1 にインデックスを追加するために使用できます。3 `EXPLAIN`元のクエリでインデックス範囲スキャンが使用されるようになり、より効率的になっていることを確認します。 +ステートメント[`ALTER TABLE .. ADD INDEX`](/sql-statements/sql-statement-add-index.md)は、テーブル t1 にインデックスを追加するために使用できます。`EXPLAIN`元のクエリでインデックス範囲スキャンが使用されるようになり、より効率的になっていることを確認します。 ```sql ALTER TABLE t1 ADD INDEX (c1); diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index 74b640171989c..da9ef4843f0df 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -67,7 +67,7 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name - `NEXTVAL`または`NEXT VALUE FOR` - 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。3 `NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 + 基本的に、どちらもシーケンスオブジェクトの次の有効な値を取得する`NEXTVAL()`関数です。`NEXTVAL()`の関数の引数は、シーケンスの`identifier`の値です。 - `LASTVAL` diff --git a/sql-statements/sql-statement-create-view.md b/sql-statements/sql-statement-create-view.md index 58a50bf7445df..41c21d52794f7 100644 --- a/sql-statements/sql-statement-create-view.md +++ b/sql-statements/sql-statement-create-view.md @@ -89,7 +89,7 @@ ERROR 1105 (HY000): insert into view v1 is not supported now. ## MySQLの互換性 {#mysql-compatibility} -- 現在、TiDB 内のどのビューも挿入または更新できません (つまり、 `INSERT VIEW`と`UPDATE VIEW`サポートされていません)。5 `WITH CHECK OPTION`構文的に互換性があるだけで、有効ではありません。 +- 現在、TiDB 内のどのビューも挿入または更新できません (つまり、 `INSERT VIEW`と`UPDATE VIEW`サポートされていません)。`WITH CHECK OPTION`構文的に互換性があるだけで、有効ではありません。 - 現在、TiDB のビューは`ALTER VIEW`サポートしていませんが、代わりに`CREATE OR REPLACE`使用できます。 - 現在、 `ALGORITHM`フィールドは TiDB において構文的に互換性があるものの、効果がありません。TiDB は現在 MERGE アルゴリズムのみをサポートしています。 diff --git a/sql-statements/sql-statement-do.md b/sql-statements/sql-statement-do.md index 2d468fea05512..8f531bafb58fe 100644 --- a/sql-statements/sql-statement-do.md +++ b/sql-statements/sql-statement-do.md @@ -9,7 +9,7 @@ summary: TiDB データベースにおける DO の使用法の概要。 > **注記：** > -> `DO`式のみを実行します。2 `SELECT`使用できるすべてのケースで使用できるわけではありません。例えば、 `DO id FROM t1`テーブルを参照するため無効です。 +> `DO`式のみを実行します。`SELECT`使用できるすべてのケースで使用できるわけではありません。例えば、 `DO id FROM t1`テーブルを参照するため無効です。 MySQLでは、ストアドプロシージャやトリガーの実行が一般的なユースケースです。TiDBはストアドプロシージャやトリガーを提供していないため、この機能の用途は限定されます。 diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 3eb85e47b473f..0af0e8643dc3f 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -38,7 +38,7 @@ ExplainableStmt ::= | 属性名 | 説明 | | :----- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | アクトロウズ | 演算子によって出力される行数。 | -| 実行情報 | 演算子の実行情報。1 `time`演算子に入ってから演算子を出るまでの合計`wall time`表します。これには、すべてのサブ演算子の合計実行時間が含まれます。演算子が親演算子（ループ内）によって何度も呼び出される場合は、その累積時間を参照します。5 `loops` 、現在の演算子が親演算子によって呼び出された回数です。 | +| 実行情報 | 演算子の実行情報。`time`演算子に入ってから演算子を出るまでの合計`wall time`表します。これには、すべてのサブ演算子の合計実行時間が含まれます。演算子が親演算子（ループ内）によって何度も呼び出される場合は、その累積時間を参照します。`loops` 、現在の演算子が親演算子によって呼び出された回数です。 | | メモリ | 演算子によって占有されるメモリ領域。 | | ディスク | オペレータが占有するディスク領域。 | @@ -226,7 +226,7 @@ tiflash_scan: { - `dtfile` : テーブル スキャン中の DTFile (DeltaTree ファイル) 関連情報。TiFlashレイヤーのデータ スキャン ステータスを反映します。 - `total_scanned_packs` : DTFileでスキャンされたパックの総数。パックとは、 TiFlash DTFileで読み取ることができる最小単位です。デフォルトでは、8192行ごとに1パックが構成されます。 - - `total_skipped_packs` : DTFile 内のスキャンでスキップされたパックの総数。2 `WHERE`が粗集合インデックスにヒットするか、主キーの範囲フィルタリングに一致する場合、無関係なパックはスキップされます。 + - `total_skipped_packs` : DTFile 内のスキャンでスキップされたパックの総数。`WHERE`が粗集合インデックスにヒットするか、主キーの範囲フィルタリングに一致する場合、無関係なパックはスキップされます。 - `total_scanned_rows` : DTFile でスキャンされた行の総数。MVCC により更新または削除のバージョンが複数ある場合、各バージョンは個別にカウントされます。 - `total_skipped_rows` : DTFile 内のスキャンによってスキップされる行の合計数。 - `total_rs_index_load_time` : DTFile のラフ セット インデックスの読み取りに費やされた合計時間。 @@ -313,7 +313,7 @@ TiDB v7.1 を使用している場合、計算は`pd/pd-client/model.go`の`Befo ### その他の一般的な実行情報 {#other-common-execution-information} -コプロセッサーオペレータには通常、実行時間情報の2つの部分、 `cop_task`と`tikv_task`含まれます。5 `cop_task` TiDBによって記録された時間で、リクエストがサーバーに送信されてからレスポンスが受信されるまでの時間です。7 `tikv_task` TiKVコプロセッサー自体によって記録された時間です。この2つの値に大きな差がある場合は、レスポンスの待機時間が長すぎるか、gRPCまたはネットワークで費やされた時間が長すぎることを示している可能性があります。 +コプロセッサーオペレータには通常、実行時間情報の2つの部分、 `cop_task`と`tikv_task`含まれます。`cop_task` TiDBによって記録された時間で、リクエストがサーバーに送信されてからレスポンスが受信されるまでの時間です。`tikv_task` TiKVコプロセッサー自体によって記録された時間です。この2つの値に大きな差がある場合は、レスポンスの待機時間が長すぎるか、gRPCまたはネットワークで費やされた時間が長すぎることを示している可能性があります。 ## MySQLの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index c78d51472761e..72042d7a680c5 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -5,7 +5,7 @@ summary: TiDB データベースにおけるEXPLAINの使用法の概要。 # `EXPLAIN` {#explain} -`EXPLAIN`の文は、クエリを実行せずにその実行プランを表示します。これは、クエリを実行する`EXPLAIN ANALYZE`の文を補完するものです。5 `EXPLAIN`出力が期待される結果と一致しない場合は、クエリ内の各テーブルに対して`ANALYZE TABLE`実行して、テーブル統計が最新であることを確認することを検討してください。 +`EXPLAIN`の文は、クエリを実行せずにその実行プランを表示します。これは、クエリを実行する`EXPLAIN ANALYZE`の文を補完するものです。`EXPLAIN`出力が期待される結果と一致しない場合は、クエリ内の各テーブルに対して`ANALYZE TABLE`実行して、テーブル統計が最新であることを確認することを検討してください。 > **注記：** > @@ -39,7 +39,7 @@ ExplainableStmt ::= > **注記：** > -> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。3 `EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 +> MySQLクライアントを使用してTiDBに接続する場合、出力結果を行の折り返しなしでより明確に読み取るには、 `pager less -S`コマンドを使用します。`EXPLAIN`結果が出力された後、キーボードの右矢印→キーを押して出力を水平にスクロールします。 > **注記：** > @@ -50,7 +50,7 @@ ExplainableStmt ::= | 属性名 | 説明 | | :--------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | オペレータIDは、実行プラン全体におけるオペレータの一意の識別子です。TiDB 2.1では、このIDはオペレータのツリー構造を表すようにフォーマットされています。データは子ノードから親ノードへと流れます。オペレータごとに親ノードは1つだけです。 | -| estRows | 演算子が出力すると予想される行数。この数は、統計情報と演算子のロジックに基づいて推定されます。1 `estRows` 、TiDB 4.0 の以前のバージョンでは`count`呼ばれていました。 | +| estRows | 演算子が出力すると予想される行数。この数は、統計情報と演算子のロジックに基づいて推定されます。`estRows` 、TiDB 4.0 の以前のバージョンでは`count`呼ばれていました。 | | タスク | オペレータが属するタスクの種類。現在、実行プランは tidb-server 上で実行される**ルート**タスクと、 TiKV またはTiFlash上で並列実行される**cop**タスクの2つのタスクに分かれています。タスクレベルでの実行プランのトポロジは、ルートタスクの後に多数の cop タスクが続くというものです。ルートタスクは cop タスクの出力を入力として使用します。cop タスクとは、TiDB が TiKV またはTiFlashにプッシュダウンするタスクを指します。各 cop タスクは TiKV クラスターまたはTiFlashクラスターに分散され、複数のプロセスによって実行されます。 | | アクセスオブジェクト | オペレータがアクセスするデータ項目情報。この情報には、 `table` 、および`index` （存在する場合） `partition`含まれます。この情報は、データに直接アクセスするオペレータのみが使用できます。 | | オペレーター情報 | 演算子に関するその他の情報。演算子ごとに`operator info`異なります。以下の例を参照してください。 | diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index b230ed0a096ee..9ddb0b69648c7 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -69,7 +69,7 @@ FlashbackToNewName ::= `FLASHBACK TABLE t TO t1`の作業工程は以下のとおりです。 1. TiDBは最近のDDL履歴ジョブを検索し、テーブル`t`で最初のDDL操作（タイプ`DROP TABLE`またはタイプ`truncate table`を見つけます。TiDBが見つけられなかった場合は、エラーが返されます。 -2. TiDBは、DDLジョブの開始時刻が`tikv_gc_safe_point`より前かどうかを確認します。3 `tikv_gc_safe_point`前の場合、 `DROP`または`TRUNCATE`操作で削除されたテーブルがGCによってクリーンアップされたことを意味し、エラーが返されます。 +2. TiDBは、DDLジョブの開始時刻が`tikv_gc_safe_point`より前かどうかを確認します。`tikv_gc_safe_point`前の場合、 `DROP`または`TRUNCATE`操作で削除されたテーブルがGCによってクリーンアップされたことを意味し、エラーが返されます。 3. TiDB は、DDL ジョブの開始時刻をスナップショットとして使用して、履歴データを読み取り、テーブル メタデータを読み取ります。 4. TiDB は`mysql.gc_delete_range`のテーブル`t`に関連する GC タスクを削除します。 5. TiDBはテーブルのメタデータの`name` `t1`に変更し、このメタデータを使用して新しいテーブルを作成します。テーブル名のみが変更され、テーブルIDは変更されないことに注意してください。テーブルIDは、以前に削除されたテーブル`t`と同じです。 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 8bcd84048e00f..0ef50fc579074 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -13,7 +13,7 @@ TiDBでは、クライアントセッションがテーブルロックを取得 `LOCK TABLES` 、現在のクライアントセッションのテーブルロックを取得します。ロック対象となる各オブジェクトに対して`LOCK TABLES`および`SELECT`権限を持っている場合は、共通テーブルのテーブルロックを取得できます。 -`UNLOCK TABLES` 、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。2 `LOCK TABLES` 、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 +`UNLOCK TABLES` 、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。`LOCK TABLES` 、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 テーブルロックは、他のセッションによる読み取りや書き込みから保護します。1 ロックを保持しているセッションは、 `WRITE`や`TRUNCATE TABLE` `DROP TABLE`のテーブルレベルの操作を実行できます。 diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md index d0661deb2abf1..bfc08ff7dd7de 100644 --- a/sql-statements/sql-statement-savepoint.md +++ b/sql-statements/sql-statement-savepoint.md @@ -122,7 +122,7 @@ ROLLBACK TO SAVEPOINT sp1; Query OK, 0 rows affected (0.01 sec) ``` -トランザクションをコミットし、テーブルをクエリします。1 `sp1`前に挿入されたデータのみが返されます。 +トランザクションをコミットし、テーブルをクエリします。`sp1`前に挿入されたデータのみが返されます。 ```sql COMMIT; diff --git a/sql-statements/sql-statement-show-analyze-status.md b/sql-statements/sql-statement-show-analyze-status.md index 2c256fc9b0c65..ad76bf1600234 100644 --- a/sql-statements/sql-statement-show-analyze-status.md +++ b/sql-statements/sql-statement-show-analyze-status.md @@ -20,7 +20,7 @@ TiDB v7.3.0 以降では、システム テーブル`mysql.analyze_jobs`また | `Table_schema` | データベース名 | | `Table_name` | テーブル名 | | `Partition_name` | パーティション名 | -| `Job_info` | タスク情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。1 `tidb_analyze_version =2`場合、この情報にはサンプルレートなどの設定項目が含まれます。 | +| `Job_info` | タスク情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。`tidb_analyze_version =2`場合、この情報にはサンプルレートなどの設定項目が含まれます。 | | `Processed_rows` | 分析された行数 | | `Start_time` | タスクが開始される時間 | | `State` | タスクの状態`failed` `pending` `finished`含む`running` | diff --git a/sql-statements/sql-statement-truncate.md b/sql-statements/sql-statement-truncate.md index 7b94a0e2e3707..51991701395b0 100644 --- a/sql-statements/sql-statement-truncate.md +++ b/sql-statements/sql-statement-truncate.md @@ -5,7 +5,7 @@ summary: TiDB データベースにおける TRUNCATE の使用法の概要。 # TRUNCATE {#truncate} -`TRUNCATE`ステートメントは、非トランザクション方式でテーブルからすべてのデータを削除します。3 `TRUNCATE` 、前の定義の`DROP TABLE` + `CREATE TABLE`と意味的に同じであると考えることができます。 +`TRUNCATE`ステートメントは、非トランザクション方式でテーブルからすべてのデータを削除します。`TRUNCATE` 、前の定義の`DROP TABLE` + `CREATE TABLE`と意味的に同じであると考えることができます。 `TRUNCATE TABLE tableName`と`TRUNCATE tableName`どちらも有効な構文です。 diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..ba44143e33a0e 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -161,7 +161,7 @@ PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql 上の図では、プロトコルレイヤーの右側に TiDBサーバーのオプティマイザーがあり、次のように SQL ステートメントを処理します。 1. SQL ステートメントはプロトコルレイヤーを介して SQL オプティマイザーに到達し、抽象構文ツリー (AST) に解析されます。 -2. TiDBは、それが[ポイントゲット](/explain-indexes.md#point_get-and-batch_point_get)文であるかどうかを識別します。1文は、 `SELECT * FROM t WHERE pk_col = 1`や`SELECT * FROM t WHERE uk_col IN (1,2,3)`などの主キーまたは一意キーを介した単純な1テーブル検索です。7 `Point Get`の場合、TiDBは後続の最適化手順をスキップし、SQLエグゼキュータで直接実行します。 +2. TiDBは、それが[ポイントゲット](/explain-indexes.md#point_get-and-batch_point_get)文であるかどうかを識別します。1文は、 `SELECT * FROM t WHERE pk_col = 1`や`SELECT * FROM t WHERE uk_col IN (1,2,3)`などの主キーまたは一意キーを介した単純な1テーブル検索です。`Point Get`の場合、TiDBは後続の最適化手順をスキップし、SQLエグゼキュータで直接実行します。 3. クエリが`Point Get`でない場合、AST は論理変換され、TiDB は特定のルールに基づいて SQL を論理的に書き換えます。 4. 論理変換後、TiDB はコストベースの最適化を通じて AST を処理します。 5. コストベースの最適化では、オプティマイザーは統計を使用して適切な演算子を選択し、物理的な実行プランを生成します。 @@ -343,7 +343,7 @@ EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 `EXPLAIN ANALYZE`出力には以下が含まれます。 - `actRows` : 演算子によって出力される行数。 -- `execution info` : オペレータの詳細な実行情報。2 `time` 、すべてのサブオペレータの合計実行時間を含む合計`wall time`表します。オペレータが親オペレータによって何度も呼び出される場合、時間は累積時間を参照します。 +- `execution info` : オペレータの詳細な実行情報。`time` 、すべてのサブオペレータの合計実行時間を含む合計`wall time`表します。オペレータが親オペレータによって何度も呼び出される場合、時間は累積時間を参照します。 - `memory` : 演算子によって使用されるメモリ。 - `disk` : オペレータが使用するディスク容量。 @@ -418,7 +418,7 @@ EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 次の例では、プランツリーの最初のリーフノードである`IndexRangeScan_47`調べることから始めます。オプティマイザは、 `stars`テーブルから`name`と`id`列のみを選択します。これらの列は`name(name)`インデックスから取得できます。その結果、 `stars`のルートリーダーは`IndexReader_48`ではなく`TableReader`なります。 -`stars`と`planets`の結合はハッシュ結合です（ `HashJoin_44` ）。7 `planets`テーブルはフルテーブルスキャン（ `TableFullScan_45` ）を使用してアクセスされます。結合後、 `TopN_26`と`TopN_19`それぞれ`ORDER BY`と`LIMIT`句を適用します。最後の演算子`Projection_16` 、最後の列`t5.name`選択します。 +`stars`と`planets`の結合はハッシュ結合です（ `HashJoin_44` ）。`planets`テーブルはフルテーブルスキャン（ `TableFullScan_45` ）を使用してアクセスされます。結合後、 `TopN_26`と`TopN_19`それぞれ`ORDER BY`と`LIMIT`句を適用します。最後の演算子`Projection_16` 、最後の列`t5.name`選択します。 ```sql EXPLAIN @@ -481,7 +481,7 @@ LIMIT 3; - 推定精度を評価するには、 `actRows`と`estRows`を比較します。 - 実行時間の長さやその他のメトリックなど、 `execution info`の詳細なメトリックを分析します。 - 潜在的なリソース制約について、 `memory`と`disk`使用状況を確認します。 -3. これらの要因を相関させることで、パフォーマンス問題の根本原因を特定できます。例えば、 `TableFullScan`操作で`actRows`カウントが高く、 `execution info`で実行時間が長い場合は、インデックスの作成を検討してください。7 `HashJoin`操作でメモリ使用量と実行時間が高い場合は、結合順序を最適化するか、別の結合方法を使用することを検討してください。 +3. これらの要因を相関させることで、パフォーマンス問題の根本原因を特定できます。例えば、 `TableFullScan`操作で`actRows`カウントが高く、 `execution info`で実行時間が長い場合は、インデックスの作成を検討してください。`HashJoin`操作でメモリ使用量と実行時間が高い場合は、結合順序を最適化するか、別の結合方法を使用することを検討してください。 以下の実行プランでは、クエリは5分51秒間実行された後、キャンセルされます。主な問題点は次のとおりです。 diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 8032de6dd2f93..4d34cbc85486d 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -133,7 +133,7 @@ Titan は、選択された BLOB ファイルについて、各値に対応す ### min-blob-sizeがパフォーマンスに与える影響 {#impact-of-code-min-blob-size-code-on-performance} -[`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 、値が Titan に格納されるかどうかを決定します。値が`min-blob-size`以上の場合、Titan に格納されます。それ以外の場合は、ネイティブの RocksDB 形式で格納されます。4 `min-blob-size`小さすぎたり大きすぎたりすると、パフォーマンスに影響します。 +[`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 、値が Titan に格納されるかどうかを決定します。値が`min-blob-size`以上の場合、Titan に格納されます。それ以外の場合は、ネイティブの RocksDB 形式で格納されます。`min-blob-size`小さすぎたり大きすぎたりすると、パフォーマンスに影響します。 以下の表は、YCSBワークロードのQPSを異なる`min-blob-size`値に基づいて比較したものです。各テストラウンドでは、テストデータの行幅は`min-blob-size`に設定されており、Titanが有効な場合はデータがTitanに保存されます。 diff --git a/sys-schema/sys-schema.md b/sys-schema/sys-schema.md index c376ab2f5b96a..90a1be9e5d65c 100644 --- a/sys-schema/sys-schema.md +++ b/sys-schema/sys-schema.md @@ -5,7 +5,7 @@ summary: sys` スキーマ内のシステム テーブルについて学習し # sysスキーマ {#code-sys-code-schema} -TiDBはv8.0.0以降、 `sys`スキーマを提供します。3 `sys`のビューを使用して、TiDBのシステムテーブル[`INFORMATION_SCHEMA`](/information-schema/information-schema.md) [`PERFORMANCE SCHEMA`](/performance-schema/performance-schema.md)データを把握できます。 +TiDBはv8.0.0以降、 `sys`スキーマを提供します。`sys`のビューを使用して、TiDBのシステムテーブル[`INFORMATION_SCHEMA`](/information-schema/information-schema.md) [`PERFORMANCE SCHEMA`](/performance-schema/performance-schema.md)データを把握できます。 ## MySQL互換性のためのテーブル {#tables-for-mysql-compatibility} diff --git a/table-affinity.md b/table-affinity.md index 1f42906695528..da3b15093bf8f 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -84,7 +84,7 @@ ALTER TABLE t1 AFFINITY = ''; テーブルまたはパーティションのアフィニティ情報は、次の方法で表示できます。 -- [`SHOW AFFINITY`](/sql-statements/sql-statement-show-affinity.md)番目のステートメントを実行します。3 `Status`の列には、アフィニティが有効になっているテーブルまたはパーティションと、それらのスケジュールステータスが表示されます。5 `Status`の列の値の意味は次のとおりです。 +- [`SHOW AFFINITY`](/sql-statements/sql-statement-show-affinity.md)番目のステートメントを実行します。`Status`の列には、アフィニティが有効になっているテーブルまたはパーティションと、それらのスケジュールステータスが表示されます。`Status`の列の値の意味は次のとおりです。 - `Pending` : リーダーまたは投票者がまだ決定されていない場合など、PD はテーブルまたはパーティションのアフィニティ スケジューリングを開始していません。 - `Preparing` : PD はアフィニティ要件を満たすようにリージョンをスケジュールしています。 diff --git a/table-attributes.md b/table-attributes.md index 8b39905e595ec..f86b931501e67 100644 --- a/table-attributes.md +++ b/table-attributes.md @@ -143,6 +143,6 @@ ALTER TABLE t PARTITION p ATTRIBUTES 'merge_option=allow'; > **注記：** > > - パーティションを持つテーブルの場合、 `merge_option`属性がテーブルレベルでのみ設定されている場合、 `merge_option=allow`であっても、テーブルはデフォルトで実際のパーティション数に応じて複数のリージョンに分割されます。すべてのリージョンをマージするには、 [テーブルの属性をリセットする](#usage)実行する必要があります。 -> - `merge_option`の属性が設定されていない場合、リージョンが条件を満たしていれば、1時間後にリージョンを統合できます。3 `merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、1時間後にリージョンを統合するかどうかを決定します。 +> - `merge_option`の属性が設定されていない場合、リージョンが条件を満たしていれば、1時間後にリージョンを統合できます。`merge_option`属性が設定されている場合、PDは`merge_option`設定に基づいて、1時間後にリージョンを統合するかどうかを決定します。 diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 606d4f9738ac1..d9ae221b5cb10 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -163,7 +163,7 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co 1. Snowflake でデータベースとスキーマを作成します。 - Snowflakeコントロールコンソールで、 **「データ」** > **「データベース」**を選択します。5 `TPCC`名前のデータベースと`TiCDC`という名前のスキーマを作成します。 + Snowflakeコントロールコンソールで、 **「データ」** > **「データベース」**を選択します。`TPCC`名前のデータベースと`TiCDC`という名前のスキーマを作成します。 2. Confluent Cloud Consoleで、 **「データ統合」** > **「コネクタ」** > **「Snowflake Sink」**を選択します。以下のページが表示されます。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 4d7a7e9fef89e..1fdf6c6af30df 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -168,7 +168,7 @@ dispatchers = [ | SMALLINT | INT | int | 符号なしの場合、TIDB_TYPE は INT UNSIGNED になります。 | | MEDIUMINT | INT | int | 符号なしの場合、TIDB_TYPE は INT UNSIGNED になります。 | | INT | INT | int | 符号なしの場合、TIDB_TYPE は INT UNSIGNED になり、AVRO_TYPE は long になります。 | -| BIGINT | BIGINT | long | 符号なしの場合、TIDB_TYPEはBIGINT UNSIGNEDです。1 `avro-bigint-unsigned-handling-mode`文字列の場合、AVRO_TYPEは文字列です。 | +| BIGINT | BIGINT | long | 符号なしの場合、TIDB_TYPEはBIGINT UNSIGNEDです。`avro-bigint-unsigned-handling-mode`文字列の場合、AVRO_TYPEは文字列です。 | | TINYBLOB | BLOB | bytes | - | | BLOB | BLOB | bytes | - | | MEDIUMBLOB | BLOB | bytes | - | diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 26179c694c7f4..eb95f33ffd65c 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -82,7 +82,7 @@ TiCDC は、DDL イベントを次の Canal-JSON 形式にエンコードしま | mysqlType | object | isDdlが`false`場合、各列のデータ型がMySQLでどのように表現されるかを記録します。 | | データ | object | isDdlが`false`の場合、各列の名前とそのデータ値を記録します。 | | 古い | object | メッセージが更新イベントによって生成された場合のみ、更新前の各列の名前とデータ値を記録します。 | -| _tidb | object | TiDB拡張フィールド。1 を`enable-tidb-extension` `true`設定した場合にのみ存在します。5 `commitTs`値は、行の変更を引き起こしたトランザクションのTSOです。 | +| _tidb | object | TiDB拡張フィールド。1 を`enable-tidb-extension` `true`設定した場合にのみ存在します。`commitTs`値は、行の変更を引き起こしたトランザクションのTSOです。 | ### DMLイベント {#dml-event} @@ -338,7 +338,7 @@ values (127, 32767, 8388607, 2147483647, 9223372036854775807); update tp_int set c_int = 0, c_tinyint = 0 where c_smallint = 32767; ``` -`update`ステートメントでは、TiCDCは以下に示すように、 `type`を`UPDATE`としてイベントメッセージを出力します。7 `update`ステートメントは、列番号`c_int`と`c_tinyint`のみを変更します。出力イベントメッセージの`old`フィールドには、すべての列データが含まれます。 +`update`ステートメントでは、TiCDCは以下に示すように、 `type`を`UPDATE`としてイベントメッセージを出力します。`update`ステートメントは、列番号`c_int`と`c_tinyint`のみを変更します。出力イベントメッセージの`old`フィールドには、すべての列データが含まれます。 ```json { diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index 8ccde3e4d9120..2182809a0a7fc 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -144,7 +144,7 @@ ignore-event = ["create table", "drop table", "truncate table", "rename table"] | `DROP TABLE test.t1;` | 無視する |
  • | `test.t1`イベントフィルタルールに一致するため、イベント`DROP TABLE`は無視されます。テーブルが削除されたため、TiCDC は`t1`の DML イベントを複製しなくなります。 | | `TRUNCATE TABLE test.t1;` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `TRUNCATE TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | | `RENAME TABLE test.t1 TO test.t2;` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `RENAME TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | -| `RENAME TABLE test.t1 TO test.ignore;` | 無視する | 無視する | `test.t1`イベント フィルター ルールに一致するため、 `RENAME TABLE`イベントは無視されます。4 `test.ignore`イベント フィルター ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | +| `RENAME TABLE test.t1 TO test.ignore;` | 無視する | 無視する | `test.t1`イベント フィルター ルールに一致するため、 `RENAME TABLE`イベントは無視されます。`test.ignore`イベント フィルター ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | > **注記：** > diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md index 6dea71fa76b6c..50c83179927b8 100644 --- a/ticdc/ticdc-debezium.md +++ b/ticdc/ticdc-debezium.md @@ -152,7 +152,7 @@ TiCDC は、キーと値の両方を Debezium 形式でエンコードして、D | フィールド名 | 型 | 説明 | | :------------------- | :----- | :------------------------------------------------------------------------------------------------------------------------------- | -| payload.op | String | 変更イベントのタイプ。1 `"c"` `INSERT`イベント、 `"u"` `UPDATE`イベント、 `"d"` `DELETE`イベントを示します。 | +| payload.op | String | 変更イベントのタイプ。`"c"` `INSERT`イベント、 `"u"` `UPDATE`イベント、 `"d"` `DELETE`イベントを示します。 | | payload.ts_ms | number | TiCDC がこのメッセージを生成したときのタイムスタンプ (ミリ秒単位)。 | | payload.before | JSON | ステートメントの変更イベント前のデータ値。イベントが`"c"`場合、フィールド`before`の値は`null`なります。 | | payload.after | JSON | The data value after the change event of a statement. For `"d"` events, the value of the `after` field is `null`. | diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 8b4d6c129c7bc..0871f40dcb111 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -335,7 +335,7 @@ TiDB v7.1.0 以降、TiCDC はこれらの冗長な DML イベントを削除し ## DDL文を下流のMySQL 5.7に複製する際に、時間型フィールドのデフォルト値が一致しません。どうすればよいでしょうか？ {#the-default-value-of-the-time-type-field-is-inconsistent-when-replicating-a-ddl-statement-to-the-downstream-mysql-5-7-what-can-i-do} -上流のTiDBで`create table test (id int primary key, ts timestamp)`文が実行されたとします。TiCDCがこの文を下流のMySQL 5.7に複製する際、MySQLはデフォルト設定を使用します。複製後のテーブルスキーマは以下のようになります。3 `timestamp`のフィールドのデフォルト値は`CURRENT_TIMESTAMP`になります。 +上流のTiDBで`create table test (id int primary key, ts timestamp)`文が実行されたとします。TiCDCがこの文を下流のMySQL 5.7に複製する際、MySQLはデフォルト設定を使用します。複製後のテーブルスキーマは以下のようになります。`timestamp`のフィールドのデフォルト値は`CURRENT_TIMESTAMP`になります。 ```sql mysql root@127.0.0.1:test> show create table test; diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 71aad2817d900..4d0110af60cd4 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -274,7 +274,7 @@ force-replicate = true > **注記：** > -> v6.0.0以降、TiCDCはデフォルトでDB Sorterエンジンを使用し、Unified Sorterエンジンは使用しなくなりました。1 `sort engine`項目は設定しないことを推奨します。 +> v6.0.0以降、TiCDCはデフォルトでDB Sorterエンジンを使用し、Unified Sorterエンジンは使用しなくなりました。`sort engine`項目は設定しないことを推奨します。 統合ソートエンジンはTiCDCのソートエンジンです。以下のシナリオで発生するOOM問題を軽減できます。 diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 658fcb6f45be5..4d03bc558e6c9 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -108,7 +108,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/status - `id` : ノードのキャプチャ ID。 - `pid` : ノードのキャプチャプロセス ID (PID)。 - `is_owner` : ノードが所有者であるかどうかを示します。 -- `liveness` : このノードがライブかどうか。2 `0`正常を意味します。4 `1`ノードが`graceful shutdown`状態にあることを意味します。 +- `liveness` : このノードがライブかどうか。`0`正常を意味します。`1`ノードが`graceful shutdown`状態にあることを意味します。 ## TiCDC クラスターのヘルスステータスを確認する {#check-the-health-status-of-a-ticdc-cluster} @@ -250,15 +250,15 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `case_sensitive` | `BOOLEAN`型。テーブル名をフィルタリングする際に大文字と小文字を区別するかどうかを指定します。v6.5.6、v7.1.3、v7.5.0以降では、デフォルト値が`true`から`false`に変更されます。（オプション） | | `check_gc_safe_point` | `BOOLEAN`型。レプリケーションタスクの開始時刻がGC時刻よりも前であるかどうかを確認するかどうかを指定します。デフォルト値は`true`です。（オプション） | | `consistent` | REDOログの設定パラメータ。(オプション) | -| `enable_sync_point` | `BOOLEAN`型。2 `sync point`有効にするかどうかを決定します。（オプション） | +| `enable_sync_point` | `BOOLEAN`型。`sync point`有効にするかどうかを決定します。（オプション） | | `filter` | `filter`の設定パラメータ。(オプション) | | `force_replicate` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクは一意インデックスを持たないテーブルを強制的にレプリケートします。（オプション） | | `ignore_ineligible_table` | `BOOLEAN`型。デフォルト値は`false`です`true`に設定すると、レプリケーションタスクはレプリケートできないテーブルを無視します。（オプション） | | `memory_quota` | `UINT64`型。レプリケーションタスクのメモリクォータ。（オプション） | | `mounter` | `mounter`の設定パラメータ。(オプション) | | `sink` | `sink`の設定パラメータ。(オプション) | -| `sync_point_interval` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。4 `sync point`が有効な場合、このパラメータは同期ポイントが上流と下流のスナップショットを同期させる間隔を指定します。デフォルト値は`10m`で、最小値は`30s`です。（オプション） | -| `sync_point_retention` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。4 `sync point`が有効な場合、このパラメータは、下流テーブルにおける同期ポイントによるデータの保持期間を指定します。この期間を超えると、データはクリーンアップされます。デフォルト値は`24h`です。（オプション） | +| `sync_point_interval` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。`sync point`が有効な場合、このパラメータは同期ポイントが上流と下流のスナップショットを同期させる間隔を指定します。デフォルト値は`10m`で、最小値は`30s`です。（オプション） | +| `sync_point_retention` | `STRING`型。返される値は`UINT64`型のナノ秒単位の時間であることに注意してください。`sync point`が有効な場合、このパラメータは、下流テーブルにおける同期ポイントによるデータの保持期間を指定します。この期間を超えると、データはクリーンアップされます。デフォルト値は`24h`です。（オプション） | `consistent`パラメータは次のように記述されます。 @@ -357,7 +357,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `worker_count` | `INT`型。下流のクラウドストレージへのデータストレージの同時実行性が変更されます。 | | `flush_interval` | `STRING`型。下流のクラウドストレージへのデータ保存間隔が変更されます。 | | `file_size` | `INT`型。このファイル内のバイト数がこのパラメータの値を超えると、データ変更ファイルがクラウドストレージに保存されます。 | -| `file_expiration_days` | `INT`タイプ。ファイルを保持する期間。2 `date-separator` `day`に設定されている場合にのみ有効になります。 | +| `file_expiration_days` | `INT`タイプ。ファイルを保持する期間。`date-separator` `day`に設定されている場合にのみ有効になります。 | | `file_cleanup_cron_spec` | `STRING`型。crontab 設定と互換性のある、スケジュールされたクリーンアップタスクの実行サイクル。形式は` `です。 | | `flush_concurrency` | `INT`型。単一ファイルのアップロードの同時実行性。 | | `output_raw_change_event` | `BOOLEAN`タイプ。MySQL 以外のシンクの元のデータ変更イベントを出力するかどうかを制御します。 | @@ -803,7 +803,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1/synced 応答には次のフィールドが含まれます。 -- `synced` : このレプリケーションタスクが完了したかどうか。2 `true`タスクが完了したこと、 `false`タスクが完了していない可能性があることを意味します。6 `false`場合は、 `info`フィールドとその他のフィールドの両方で具体的なステータスを確認する必要があります。 +- `synced` : このレプリケーションタスクが完了したかどうか。`true`タスクが完了したこと、 `false`タスクが完了していない可能性があることを意味します。`false`場合は、 `info`フィールドとその他のフィールドの両方で具体的なステータスを確認する必要があります。 - `sink_checkpoint_ts` : シンク モジュールのチェックポイント ts 値 (PD 時間)。 - `puller_resolved_ts` : PD 時間での、プラー モジュールのresolved-ts値。 - `last_synced_ts` : TiCDC によって処理された最新のデータの commit-ts 値 (PD 時間)。 diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index c778a08f937d0..85c241a46d537 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -117,9 +117,9 @@ curl -X GET http://127.0.0.1:8300/api/v1/health 上記の表のその他のパラメータについては、次のようにさらに詳しく説明します。 -`force_replicate` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は一意インデックスを持たないテーブルを強制的に複製しようとします。 +`force_replicate` : このパラメータのデフォルトは`false`です。`true`指定すると、TiCDC は一意インデックスを持たないテーブルを強制的に複製しようとします。 -`ignore_ineligible_table` : このパラメータのデフォルトは`false`です。4 `true`指定すると、TiCDC は複製できないテーブルを無視します。 +`ignore_ineligible_table` : このパラメータのデフォルトは`false`です。`true`指定すると、TiCDC は複製できないテーブルを無視します。 `filter_rules` : テーブルスキーマフィルタリングのルール（例： `filter_rules = ['foo*.*','bar*.*']` ）。詳細については、 [テーブルフィルター](/table-filter.md)ドキュメントを参照してください。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index 5164998dd9a4e..b5a24773f3166 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -23,7 +23,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `cert` : TLS 接続用の PEM 形式の証明書ファイルのパスを指定します (オプション)。 - `cert-allowed-cn` : TLS 接続の PEM 形式の共通名のパスを指定します (オプション)。 - `key` : TLS 接続用の PEM 形式の秘密鍵ファイルのパスを指定します (オプション)。 -- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。6 `sink-uri` `time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。12 パラメータと`time-zone`パラメータの`tz`を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。 +- `tz` : TiCDC サービスが使用するタイムゾーン。TiCDC は、 `TIMESTAMP`などの時間データ型を内部的に変換するとき、またはデータをダウンストリームに複製するときに、このタイムゾーンを使用します。デフォルトは、プロセスが実行されるローカルタイムゾーンです。`sink-uri` `time-zone`パラメータは、 `mysql`と`tidb`シンクにのみ有効で、ダウンストリーム接続セッションのタイムゾーンを設定するために使用されることに注意してください。12 パラメータと`time-zone`パラメータの`tz`を指定する場合は、両方のパラメータで同じタイムゾーンを使用するようにしてください。これは、TiCDC プロセスは内部的に`tz`で指定されたタイムゾーンを使用するのに対し、MySQL シンクと TiDB シンクはダウンストリーム操作の実行時に`time-zone`で指定されたタイムゾーンを使用するためです。 - `cluster-id` : (オプション) TiCDC クラスターの ID。デフォルト値は`default`です。 `cluster-id`は TiCDC クラスターの一意の識別子です。同じ`cluster-id`を持つ TiCDC ノードは同じクラスターに属します。 `cluster-id`の長さは最大 128 文字です。 `cluster-id` `^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$`のパターンに従う必要があり、 `owner` 、 `capture` 、 `task` 、 `changefeed` 、 `job` 、 `meta`のいずれかにすることはできません。 ## cdc server構成ファイルのパラメータ {#code-cdc-server-code-configuration-file-parameters} diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index 84ef53c77a522..9331fa2552793 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -237,7 +237,7 @@ TiCDC は、DDL イベントを次の JSON 形式でエンコードします。 | `commitTs` | number | DDL ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | | `tableSchema` | object | テーブルの現在のスキーマ情報。詳細については、 [TableSchemaの定義](#tableschema-definition)参照してください。 | -| `preTableSchema` | object | DDL文が実行される前のテーブルのスキーマ情報。1 `CREATE`のDDLイベントを除くすべてのDDLイベントにこのフィールドがあります。 | +| `preTableSchema` | object | DDL文が実行される前のテーブルのスキーマ情報。`CREATE`のDDLイベントを除くすべてのDDLイベントにこのフィールドがあります。 | ### DML {#dml} diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index b2cdaaee478d6..8a6a6c7c9fb6d 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -54,7 +54,7 @@ URI の`[query_parameters]`には、次のパラメータを設定できます > **注記：** > -> データ変更ファイルは、 `flush-interval`または`file-size`いずれかが要件を満たしている場合に下流に保存されます。5 `protocol`パラメータは必須です。TiCDCが変更フィードの作成時にこのパラメータを受け取らない場合は、 `CDC:ErrSinkUnknownProtocol`エラーが返されます。 +> データ変更ファイルは、 `flush-interval`または`file-size`いずれかが要件を満たしている場合に下流に保存されます。`protocol`パラメータは必須です。TiCDCが変更フィードの作成時にこのパラメータを受け取らない場合は、 `CDC:ErrSinkUnknownProtocol`エラーが返されます。 ### 外部ストレージのシンクURIを構成する {#configure-sink-uri-for-external-storage} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index c125fbc8ab208..8f04dc8b4003d 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -307,7 +307,7 @@ dispatchers = [ > **注記：** > -> バージョン6.1.0以降、設定の意味を明確にするため、パーティションディスパッチャを指定するための設定が`dispatcher`から`partition`に変更されました。5 `partition` `dispatcher`の別名です。例えば、次の2つのルールは全く同じ意味です。 +> バージョン6.1.0以降、設定の意味を明確にするため、パーティションディスパッチャを指定するための設定が`dispatcher`から`partition`に変更されました。`partition` `dispatcher`の別名です。例えば、次の2つのルールは全く同じ意味です。 > > [sink] > dispatchers = [ diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 257c4b553c151..a986c2a9ad6d2 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -17,7 +17,7 @@ summary: TiCDC の使用時に発生する可能性のある問題のトラブ - Grafanaダッシュボードで、レプリケーションタスクの監視メトリック`changefeed checkpoint` （適切な`changefeed id`選択）を確認してください。メトリック値が変化しない場合、またはメトリック`checkpoint lag`が増加し続ける場合、レプリケーションタスクが中断されている可能性があります。 - 監視メトリック`exit error count`を確認してください。メトリック値が`0`より大きい場合、レプリケーションタスクでエラーが発生しました。 -- `cdc cli changefeed list`と`cdc cli changefeed query`実行して、レプリケーションタスクのステータスを確認します。5 `stopped`タスクが停止したことを意味し、 `error`は詳細なエラーメッセージを示します。エラー発生後、TiCDCサーバーログで`error on running processor`検索してエラースタックを確認し、トラブルシューティングを行うことができます。 +- `cdc cli changefeed list`と`cdc cli changefeed query`実行して、レプリケーションタスクのステータスを確認します。`stopped`タスクが停止したことを意味し、 `error`は詳細なエラーメッセージを示します。エラー発生後、TiCDCサーバーログで`error on running processor`検索してエラースタックを確認し、トラブルシューティングを行うことができます。 - 極端なケースでは、TiCDC サービスが再起動されることがあります。トラブルシューティングのために、TiCDCサーバーログの`FATAL`レベル目のログを検索できます。 ### レプリケーション タスクが手動で停止されたかどうかを確認するにはどうすればよいですか? {#how-do-i-know-whether-the-replication-task-is-stopped-manually} @@ -70,7 +70,7 @@ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it. -ダウンストリームが特殊なMySQL環境（パブリッククラウドRDSまたは一部のMySQL派生バージョン）であり、前述の方法によるタイムゾーンのインポートに失敗した場合は、シンクURIの`time-zone`空の値（例： `time-zone=""` ）に設定することで、ダウンストリームのデフォルトのタイムゾーンを使用できます。5 `time-zone` `mysql`と`tidb`シンクにのみ有効であることに注意してください。 +ダウンストリームが特殊なMySQL環境（パブリッククラウドRDSまたは一部のMySQL派生バージョン）であり、前述の方法によるタイムゾーンのインポートに失敗した場合は、シンクURIの`time-zone`空の値（例： `time-zone=""` ）に設定することで、ダウンストリームのデフォルトのタイムゾーンを使用できます。`time-zone` `mysql`と`tidb`シンクにのみ有効であることに注意してください。 `mysql`と`tidb`シンクを使用する場合は、タイムゾーンを明示的に指定することをお勧めします（例： `time-zone="Asia/Shanghai"` 。また、TiCDCサーバー構成で指定する`tz`とシンクURIで指定する`time-zone`が、下流データベースのタイムゾーン設定と一致していることを確認してください。これにより、タイムゾーンの不一致によるデータの不整合を防ぐことができます。 diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md index 6a974fda65a7b..7ee0d6215decf 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -71,7 +71,7 @@ TiDB Cloud がAmazon MSK プロビジョニングクラスターにアクセス password="pswd"; ``` -5. ACLを作成します。1 `bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-2.xxxxx.c18.kafka.us-east-1.amazonaws.com:9096` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 +5. ACLを作成します。`bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-2.xxxxx.c18.kafka.us-east-1.amazonaws.com:9096` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 ```shell /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config scram-client.properties --add --allow-principal User: --operation All --topic '*' @@ -117,7 +117,7 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler ``` -5. ACLを作成します。1 `bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-1.xxxxx.c18.kafka.us-east-1.amazonaws.com:9098` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 +5. ACLを作成します。`bootstrap-server` MSKブートストラップサーバーのアドレスとポート（例： `b-1.xxxxx.c18.kafka.us-east-1.amazonaws.com:9098` ）に置き換え、必要に応じてKafkaへのパスを置き換えます。 ```shell /home/ec2-user/kafka_2.13-3.7.1/bin/kafka-acls.sh --bootstrap-server --command-config iam-client.properties --add --allow-principal User: --operation All --topic '*' diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index 179d1bcd755b3..701ba3d975bda 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 @@ -187,7 +187,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。3 `INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md index b0eb764c9d827..4c594768622bf 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md @@ -130,7 +130,7 @@ Kafka VPC を作成するには、次の手順を実行します。 4. 要塞サブネットをパブリック サブネットに構成します。 - 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。3 `kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 + 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。`kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 2. **インターネット ゲートウェイの詳細**ページの**アクション**で、 **VPC に接続を**クリックして、インターネット ゲートウェイを Kafka VPC に接続します。 @@ -264,7 +264,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。3 `INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 diff --git a/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md index 1ee6cbd51e14d..74fb14a2d267e 100644 --- a/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md @@ -167,7 +167,7 @@ Kafka VPC を作成するには、次の手順を実行します。 4. 要塞サブネットをパブリック サブネットに構成します。 - 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。3 `kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 + 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。`kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 2. **インターネット ゲートウェイの詳細**ページの**アクション**で、 **VPC に接続を**クリックして、インターネット ゲートウェイを Kafka VPC に接続します。 @@ -301,7 +301,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。3 `INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 diff --git a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md index 6aaad95a01548..155e9f5c0d230 100644 --- a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md @@ -314,7 +314,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka consume_messages ``` -4. `produce.sh`と`consume.sh`スクリプトを実行します。これらのスクリプトは、接続とメッセージフローを自動的にテストし、Kafkaクラスターが正しく機能していることを確認します。5 `produce.sh`スクリプトは、 `--partitions 3 --replication-factor 3`でトピックを作成し、テストメッセージを送信し、 `--broker-list`パラメータを使用して3つのブローカーすべてに接続します。11 `consume.sh`スクリプトは、トピックからメッセージを読み取り、メッセージの配信が成功したことを確認します。 +4. `produce.sh`と`consume.sh`スクリプトを実行します。これらのスクリプトは、接続とメッセージフローを自動的にテストし、Kafkaクラスターが正しく機能していることを確認します。`produce.sh`スクリプトは、 `--partitions 3 --replication-factor 3`でトピックを作成し、テストメッセージを送信し、 `--broker-list`パラメータを使用して3つのブローカーすべてに接続します。11 `consume.sh`スクリプトは、トピックからメッセージを読み取り、メッセージの配信が成功したことを確認します。 ```shell # Test write message. diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 3c179c1474030..6666dc8e30f95 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -870,7 +870,7 @@ Terraform で管理されていない TiDB クラスターの場合は、イン status = "AVAILABLE" } -4. Terraformを使用してクラスタを管理するには、前の手順の出力を構成ファイルにコピーします。1 `id`と`status`行目はTerraformによって制御されるため、削除する必要があることに注意してください。 +4. Terraformを使用してクラスタを管理するには、前の手順の出力を構成ファイルにコピーします。`id`と`status`行目はTerraformによって制御されるため、削除する必要があることに注意してください。 resource "tidbcloud_cluster" "import_cluster" { cloud_provider = "AWS" diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index 756c02618104e..ca08060c9d163 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDB Cloud Dedicatedクラスタはプロジェクトに属します。TiDB Cloud Dedicatedクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDB Cloud Dedicatedクラスタはプロジェクトに属します。TiDB Cloud Dedicatedクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md index 6d7a23b15867a..5eb3b27827ef9 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -22,7 +22,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDBクラスタはプロジェクトに属します。TiDB Cloud Essentialクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDBクラスタはプロジェクトに属します。TiDB Cloud Essentialクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index dfaffd90e0145..1a0e8c5d64325 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDBクラスタはプロジェクトに属します。TiDB Cloud Starterクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDBクラスタはプロジェクトに属します。TiDB Cloud Starterクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 diff --git a/tidb-cloud/terraform-use-serverless-export-resource.md b/tidb-cloud/terraform-use-serverless-export-resource.md index b2e626a8751f6..439b882125e3a 100644 --- a/tidb-cloud/terraform-use-serverless-export-resource.md +++ b/tidb-cloud/terraform-use-serverless-export-resource.md @@ -15,7 +15,7 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud > **注記：** > -> `tidbcloud_serverless_export`リソースは変更できません。3 `tidbcloud_serverless_export`のリソースの設定を変更する場合は、既存のリソースを削除してから、新しいリソースを作成する必要があります。 +> `tidbcloud_serverless_export`リソースは変更できません。`tidbcloud_serverless_export`のリソースの設定を変更する場合は、既存のリソースを削除してから、新しいリソースを作成する必要があります。 ## 前提条件 {#prerequisites} @@ -115,7 +115,7 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud この例では、 `tidbcloud_serverless_export.example`リソースがクラスター全体からデータをエクスポートするエクスポート タスクを作成します。 - このリソースは同期されていません。1 `terraform refresh`使用すると最新の状態を取得できます。 + このリソースは同期されていません。`terraform refresh`使用すると最新の状態を取得できます。 5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_serverless_export.${resource-name}`使用します。コマンド 1 は、すべてのリソースとデータソースの状態を表示します。 diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index f882364a431f6..7b0c1f643cc81 100644 --- a/tidb-cloud/terraform-use-sql-user-resource.md +++ b/tidb-cloud/terraform-use-sql-user-resource.md @@ -189,7 +189,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ user_name = "example_user" } -`builtin_role` `role_readonly`に変更されます。5 `password`センシティブな値であるため表示されません。 +`builtin_role` `role_readonly`に変更されます。`password`センシティブな値であるため表示されません。 ## SQLユーザーをインポートする {#import-a-sql-user} diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md index 864bfca8692f0..cd2e6f74e4001 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md @@ -61,7 +61,7 @@ ticloud serverless audit-log config update -c --enabled=false | --rotation-size-mib int32 | 回転サイズ（MiB）。有効な範囲： `[1, 1024]` 。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.アクセスキーID文字列 | Amazon S3のアクセスキーID。 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.role-arn 文字列 | Amazon S3 のロール ARN。 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | -| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキー。1 `--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | +| --s3.secret-access-key 文字列 | Amazon S3のシークレットアクセスキー。`--s3.role-arn`いずれか、または`--s3.access-key-id`と`--s3.secret-access-key`両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.uri 文字列 | `s3:///`形式の Amazon S3 URI。 | いいえ | 非対話型モードでのみ動作します。 | | --unredacted | データベース監査ログを編集解除または編集します。 | いいえ | 非対話型モードでのみ動作します。 | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | diff --git a/tidb-cloud/tidb-cloud-htap-quickstart.md b/tidb-cloud/tidb-cloud-htap-quickstart.md index 856e4732ebaff..7c00bc886ffed 100644 --- a/tidb-cloud/tidb-cloud-htap-quickstart.md +++ b/tidb-cloud/tidb-cloud-htap-quickstart.md @@ -62,8 +62,8 @@ SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_ID, REPLICA_COUNT, LOCATION_LABELS, AVAIL 上記のステートメントの結果は次のようになります。 -- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。2 `1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 -- `PROGRESS`レプリケーションの進行状況を表します。値は`0`から`1`までです。6 `1`少なくとも1つのレプリカがレプリケートされていることを意味します。 +- `AVAILABLE` 、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`利用可能、 `0`利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 +- `PROGRESS`レプリケーションの進行状況を表します。値は`0`から`1`までです。`1`少なくとも1つのレプリカがレプリケートされていることを意味します。 ### ステップ2. HTAPを使用してデータをクエリする {#step-2-query-data-using-htap} diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index 1668cb5c3de3b..aa8bbf30036d4 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -150,7 +150,7 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し - `"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) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。1 `"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"`バケットのサンプル KMS キーです。 +- カスタマー管理のキー暗号化で AWS Key Management Service キー (SSE-KMS) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。`"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"`バケットのサンプル KMS キーです。 { "Sid": "AllowKMSkey", diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index ebd41f0445ddb..2b072e4374c4e 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -157,7 +157,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.dev.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v2/jobs/{job_id}'\ diff --git a/tidb-cloud/use-chat2query-sessions.md b/tidb-cloud/use-chat2query-sessions.md index ec44cc74c158f..dafce1b34b494 100644 --- a/tidb-cloud/use-chat2query-sessions.md +++ b/tidb-cloud/use-chat2query-sessions.md @@ -83,7 +83,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://eu-cen - `question` :*文字列*。必要なクエリを説明する自然言語での質問。 - `feedback_answer_id` ：*文字列*。フィードバック回答ID。このフィールドはオプションであり、フィードバックにのみ使用されます。 - `feedback_task_id` ：*文字列*。フィードバックタスクID。このフィールドはオプションであり、フィードバックにのみ使用されます。 -- `sql_generate_mode` :*文字列*。SQL文を生成するモード。値は`direct`または`auto_breakdown`です。8 `direct`設定すると、APIは指定された`question` SQL文に基づいて直接SQL文を生成します。12 に設定すると、APIは`auto_breakdown` `question` SQL文を複数のタスクに分割し、各タスクごとにSQL文を生成します。 +- `sql_generate_mode` :*文字列*。SQL文を生成するモード。値は`direct`または`auto_breakdown`です。`direct`設定すると、APIは指定された`question` SQL文に基づいて直接SQL文を生成します。12 に設定すると、APIは`auto_breakdown` `question` SQL文を複数のタスクに分割し、各タスクごとにSQL文を生成します。 応答の例は次のとおりです。 diff --git a/tidb-computing.md b/tidb-computing.md index 7e07dd5d674d5..6dbe6ac1ca71f 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -83,7 +83,7 @@ CREATE TABLE User ( t10_r2 --> ["TiKV", "KV Engine", 20] t10_r3 --> ["PD", " Manager", 30] -このテーブルには、主キーに加えて、一意ではない通常のセカンダリインデックス`idxAge`あります。3 `IndexID` `1`であるとすると、TiKV に保存されるインデックスデータは次のようになります。 +このテーブルには、主キーに加えて、一意ではない通常のセカンダリインデックス`idxAge`あります。`IndexID` `1`であるとすると、TiKV に保存されるインデックスデータは次のようになります。 t10_i1_10_1 --> null t10_i1_20_2 --> null diff --git a/tidb-control.md b/tidb-control.md index a7f01b1b77676..0f93cc093c8f5 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -140,7 +140,7 @@ tidb-ctl schema in #### tidサブコマンド {#the-code-tid-code-subcommand} -`tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。4 `in`コマンドを使用して特定のスキーマのすべてのテーブルIDを取得し、 `tid`サブコマンドを使用して詳細なテーブル情報を取得できます。 +`tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。`in`コマンドを使用して特定のスキーマのすべてのテーブルIDを取得し、 `tid`サブコマンドを使用して詳細なテーブル情報を取得できます。 例えば、テーブルID `mysql.stat_meta`は`21`です。テーブルID `tidb-ctl schema tid -i 21`を使用すると、テーブルID `mysql.stat_meta`の詳細を取得できます。 @@ -276,7 +276,7 @@ tidb-ctl base64decode [table_id] [base64_data] ### logコマンド {#the-code-log-code-command} -TiDBエラーログのスタック情報は1行形式です。1 `tidb-ctl log`指定すると、複数行形式に変更できます。 +TiDBエラーログのスタック情報は1行形式です。`tidb-ctl log`指定すると、複数行形式に変更できます。 ### keyrangeコマンド {#the-code-keyrange-code-command} diff --git a/tidb-external-ts.md b/tidb-external-ts.md index 7698f2dd9484f..353503ebe9659 100644 --- a/tidb-external-ts.md +++ b/tidb-external-ts.md @@ -15,7 +15,7 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る システム変数[`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640) 、 `tidb_enable_external_ts_read`が有効な場合に読み取る履歴データのタイムスタンプを指定します。 -システム変数[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) 、履歴データを現在のセッションで読み取るか、グローバルで読み取るかを制御します。デフォルト値は`OFF`で、履歴データの読み取り機能は無効であり、 `tidb_external_ts`は無視されます。7 `tidb_enable_external_ts_read`グローバルに`ON`に設定すると、すべてのクエリは`tidb_external_ts`で指定された時刻より前に履歴データを読み取ります。13 `tidb_enable_external_ts_read`特定のセッションのみ`ON`に設定すると、そのセッションのクエリのみが履歴データを読み取ります。 +システム変数[`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) 、履歴データを現在のセッションで読み取るか、グローバルで読み取るかを制御します。デフォルト値は`OFF`で、履歴データの読み取り機能は無効であり、 `tidb_external_ts`は無視されます。`tidb_enable_external_ts_read`グローバルに`ON`に設定すると、すべてのクエリは`tidb_external_ts`で指定された時刻より前に履歴データを読み取ります。13 `tidb_enable_external_ts_read`特定のセッションのみ`ON`に設定すると、そのセッションのクエリのみが履歴データを読み取ります。 `tidb_enable_external_ts_read`有効にすると、TiDB は読み取り専用になります。すべての書き込みクエリは`ERROR 1836 (HY000): Running in read-only mode`ようなエラーで失敗します。 diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 70ceb6cb370d4..2b949e2f893d0 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -7,9 +7,9 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 多くのユーザーから、 [TiDB Lightning](/tidb-lightning/tidb-lightning-configuration.md)の展開、構成、メンテナンスは、特に[並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)の大規模なデータセットが関係するシナリオでは複雑であるというフィードバックが寄せられています。 -皆様からのフィードバックに基づき、TiDBはTiDB Lightningの一部の機能を[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) SQL文に段階的に統合してきました。3 `IMPORT INTO`実行することでデータを直接インポートできるため、データインポートの効率が向上します。さらに、 `IMPORT INTO`自動分散タスクスケジューリングや[TiDB グローバルソート](/tidb-global-sort.md)といった、 TiDB Lightningにはない機能もサポートされています。 +皆様からのフィードバックに基づき、TiDBはTiDB Lightningの一部の機能を[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) SQL文に段階的に統合してきました。`IMPORT INTO`実行することでデータを直接インポートできるため、データインポートの効率が向上します。さらに、 `IMPORT INTO`自動分散タスクスケジューリングや[TiDB グローバルソート](/tidb-global-sort.md)といった、 TiDB Lightningにはない機能もサポートされています。 -`IMPORT INTO`はv7.2.0で導入され、v7.5.0で一般提供（GA）されます。今後のバージョンでも引き続き改良と最適化が行われます。2 `IMPORT INTO`機能がTiDB Lightningを完全に置き換えることが可能になった時点で、 TiDB Lightningは廃止されます。その際には、TiDBのリリースノートおよびドキュメントで事前にお知らせいたします。 +`IMPORT INTO`はv7.2.0で導入され、v7.5.0で一般提供（GA）されます。今後のバージョンでも引き続き改良と最適化が行われます。`IMPORT INTO`機能がTiDB Lightningを完全に置き換えることが可能になった時点で、 TiDB Lightningは廃止されます。その際には、TiDBのリリースノートおよびドキュメントで事前にお知らせいたします。 ## IMPORT INTOとTiDB Lightningの比較 {#comparison-between-code-import-into-code-and-tidb-lightning} diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 4c28b337393a4..f9274cfd47605 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -168,7 +168,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `keep-after-success` {#keep-after-success} -- すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。1 `false`場合、チェックポイントは削除されます。 +- すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。`false`場合、チェックポイントは削除されます。 - チェックポイントを保持するとデバッグが容易になりますが、データ ソースに関するメタデータが漏洩します。 @@ -202,7 +202,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `threshold` {#threshold} -- [`strategy`](#strategy)が`"replace"`または`"ignore"`の場合に処理できる競合エラーの最大数を制御します。7 `strategy` `"replace"`または`"ignore"`場合のみ設定できます。 +- [`strategy`](#strategy)が`"replace"`または`"ignore"`の場合に処理できる競合エラーの最大数を制御します。`strategy` `"replace"`または`"ignore"`場合のみ設定できます。 - `10000`より大きい値を設定すると、インポートプロセスのパフォーマンスが低下する可能性があります。 - デフォルト値: `10000` @@ -241,7 +241,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 物理インポート モードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 - デフォルト値: `'none'` - 値のオプション: - - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。2 `duplicate-resolution = 'none'`設定し、 `conflict.strategy`設定していない場合、 TiDB Lightningは自動的に`""`から`conflict.strategy`割り当てます。 + - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。`duplicate-resolution = 'none'`設定し、 `conflict.strategy`設定していない場合、 TiDB Lightningは自動的に`""`から`conflict.strategy`割り当てます。 - `'remove'` : `duplicate-resolution = 'remove'`設定し、 `conflict.strategy`設定しない場合、 TiDB Lightning は自動的に`conflict.strategy`に「置換」を割り当て、新しいバージョンの競合検出を有効にします。 #### `send-kv-pairs` {#send-kv-pairs} @@ -418,7 +418,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `max-region-size` {#max-region-size} -- [`strict-format`](#strict-format)が`true`の場合、 TiDB Lightning は大きな CSV ファイルを複数のチャンクに分割して並列処理します。5 `max-region-size`分割後の各チャンクの最大サイズです。 +- [`strict-format`](#strict-format)が`true`の場合、 TiDB Lightning は大きな CSV ファイルを複数のチャンクに分割して並列処理します。`max-region-size`分割後の各チャンクの最大サイズです。 - デフォルト値: `"256MiB"` #### `filter` {#filter} @@ -643,7 +643,7 @@ CSV ファイルの解析方法を構成します。 - `"optional"` : 管理者チェックサムを実行します。チェックサムに失敗した場合、 TiDB Lightning はWARN ログを報告しますが、エラーは無視されます。 - `"off"` : チェックサムを実行しません。 - チェックサムの失敗は通常、インポート例外（データの損失または不整合）を意味します。チェックサムは常に有効にすることをお勧めします。 -- 下位互換性のため、このフィールドでは bool 値`true`と`false`も許可されます。5 `true` `required`に相当し、 `false` `off`に相当します。 +- 下位互換性のため、このフィールドでは bool 値`true`と`false`も許可されます。`true` `required`に相当し、 `false` `off`に相当します。 #### `checksum-via-sql` {#checksum-via-sql} diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index dd8eee34f1be4..b59d389c37366 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -52,7 +52,7 @@ rename srcdb. tgtdb. *.sql - データファイル`pattern`の一致ルールは`^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)`です。 - `schema`を`'$1'`と指定すると、最初の正規表現の値`schema_regrex`は変更されません。または、 `schema` `'tgtdb'`などの文字列として指定すると、固定のターゲットデータベース名になります。 - `table`を`'$2'`と指定すると、2番目の正規表現の値`table_regrex`は変更されません。または、 `table` `'t1'`などの文字列として指定すると、固定のターゲットテーブル名になります。 -- `type` `'$3'` （データファイルの種類）として指定します。5 `type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。 +- `type` `'$3'` （データファイルの種類）として指定します。`type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。 ```toml [mydumper] diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 0f129cf749a7d..5f9abbb4314b9 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -18,7 +18,7 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に > > - 並列インポートは、TiDB 内の初期化された空のテーブルのみをサポートし、既存のサービスによって書き込まれたデータを含むテーブルへのデータ移行はサポートしません。そうしないと、データの不整合が発生する可能性があります。 > -> - 並列インポートは通常、物理インポートモードで使用されます。1 `parallel-import = true`設定する必要があります。 +> - 並列インポートは通常、物理インポートモードで使用されます。`parallel-import = true`設定する必要があります。 > > - 複数のTiDB Lightningインスタンスを使用して同じターゲットにデータをインポートする場合は、一度に1つのバックエンドのみを適用してください。例えば、同じTiDBクラスターに物理インポートモードと論理インポートモードの両方で同時にデータをインポートすることはできません。 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index c60fbc0b02b40..e7c89482fb3e6 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -26,7 +26,7 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ ## TiDB Lightningを適切に再起動するにはどうすればよいですか? {#how-to-properly-restart-tidb-lightning} 1. [`tidb-lightning`プロセスを停止する](#how-to-stop-the-tidb-lightning-process) 。 -2. 新しい`tidb-lightning`タスクを開始します。3 `nohup tiup tidb-lightning -config tidb-lightning.toml`の前の開始コマンドを実行します。 +2. 新しい`tidb-lightning`タスクを開始します。`nohup tiup tidb-lightning -config tidb-lightning.toml`の前の開始コマンドを実行します。 ## インポートされたデータの整合性を確保するにはどうすればよいですか? {#how-to-ensure-the-integrity-of-the-imported-data} diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 5b58043485fc6..f3003e014b317 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -70,7 +70,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode ### `checksum failed: checksum mismatched remote vs local` {#checksum-failed-checksum-mismatched-remote-vs-local} -**原因**: ローカルデータソースとリモートインポートデータベースのテーブルのチェックサムが異なります。このエラーには、より深刻な理由がいくつか考えられます。2 `checksum mismatched`含むログを確認することで、原因をさらに特定できます。 +**原因**: ローカルデータソースとリモートインポートデータベースのテーブルのチェックサムが異なります。このエラーには、より深刻な理由がいくつか考えられます。`checksum mismatched`含むログを確認することで、原因をさらに特定できます。 `checksum mismatched`を含む行は情報`total_kvs: x vs y`提供します。ここで、 `x`インポートの完了後にターゲット クラスターによって計算されたキーと値のペア (KV ペア) の数を示し、 `y`ローカル データ ソースによって生成されたキーと値のペアの数を示します。 @@ -139,7 +139,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= 2. クラスター全体で同じ最新バージョン`tzdata` (バージョン 2018i 以上) が使用されていることを確認します。 - CentOS では、 `yum info tzdata`実行してインストールされているバージョンとアップデートの有無を確認します。3 `yum upgrade tzdata`実行してパッケージをアップグレードします。 + CentOS では、 `yum info tzdata`実行してインストールされているバージョンとアップデートの有無を確認します。`yum upgrade tzdata`実行してパッケージをアップグレードします。 ### `[Error 8025: entry too large, the max entry size is 6291456]` {#error-8025-entry-too-large-the-max-entry-size-is-6291456} diff --git a/tidb-read-staleness.md b/tidb-read-staleness.md index 0e2fe25c6e14e..309aa206bd0b5 100644 --- a/tidb-read-staleness.md +++ b/tidb-read-staleness.md @@ -95,7 +95,7 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ > **注記：** > - > - `tidb_read_staleness`前には`@`ではなく`@@`使用します。7 `@@`システム変数、 `@`ユーザー変数を意味します。 + > - `tidb_read_staleness`前には`@`ではなく`@@`使用します。`@@`システム変数、 `@`ユーザー変数を意味します。 > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5 秒であるため、手順 3 と手順 4 を 5 秒以内に完了する必要があります。 ここで読み取られるデータは更新前のデータ、つまり履歴データです。 diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 50a3880f94fde..ec228918cc40d 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -55,7 +55,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 > **注記：** > -> ランナウェイクエリを特定のリソースグループに厳密に制限したい場合は、 `SWITCH_GROUP`と[`QUERY WATCH`](#query-watch-parameters)ステートメントを併用することをお勧めします。5 `QUERY_LIMIT` 、クエリが条件を満たした場合にのみ対応する`ACTION`操作をトリガーするため、このようなシナリオでは`SWITCH_GROUP`クエリを適切なタイミングで対象のリソースグループに切り替えられない可能性があります。 +> ランナウェイクエリを特定のリソースグループに厳密に制限したい場合は、 `SWITCH_GROUP`と[`QUERY WATCH`](#query-watch-parameters)ステートメントを併用することをお勧めします。`QUERY_LIMIT` 、クエリが条件を満たした場合にのみ対応する`ACTION`操作をトリガーするため、このようなシナリオでは`SWITCH_GROUP`クエリを適切なタイミングで対象のリソースグループに切り替えられない可能性があります。 ## 例 {#examples} @@ -98,7 +98,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2'; ``` -- SQLをSQLダイジェストに解析することで、リソースグループ`rg1`ランナウェイクエリ監視リストに一致する機能を追加します。3 `ACTION`指定されていない場合は、リソースグループ`rg1`に既に設定されているオプション`ACTION`使用されます。 +- SQLをSQLダイジェストに解析することで、リソースグループ`rg1`ランナウェイクエリ監視リストに一致する機能を追加します。`ACTION`指定されていない場合は、リソースグループ`rg1`に既に設定されているオプション`ACTION`使用されます。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2'; diff --git a/tidb-rowid.md b/tidb-rowid.md index cf98b701677a6..c410fd0527a2e 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -123,7 +123,7 @@ SELECT _tidb_rowid, a, b FROM t WHERE _tidb_rowid = 100; - `_tidb_rowid`という名前のユーザー列を作成することはできません。 - 既存のユーザー列の名前を`_tidb_rowid`に変更することはできません。 - `_tidb_rowid`はTiDBの内部列です。ビジネス上の主キーや長期的な識別子として扱わないでください。 -- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 +- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。`EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 - `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 ## ホットスポットの問題に対処する {#address-hotspot-issues} diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 8c53f4366a211..d5e21ca6da966 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -21,7 +21,7 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; > **注記：** > -> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。7 `1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)クラスターの場合、 TiFlashレプリカの`count` `2`しか設定できません。`1`を設定した場合、実行時に自動的に`2`に調整されます。2 より大きい数に設定した場合、レプリカ数に関するエラーが発生します。 同じテーブルに対して複数のDDL文を実行した場合、最後に実行された文のみが確実に有効になります。次の例では、テーブル`tpch50`に対して2つのDDL文が実行されていますが、2番目の文（レプリカを削除する文）のみが確実に有効になります。 @@ -60,7 +60,7 @@ ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0; ### レプリケーションの進行状況を確認する {#check-replication-progress} -特定のテーブルのTiFlashレプリカのステータスを確認するには、次のステートメントを使用します。テーブルは`WHERE`句で指定します。3 `WHERE`の句を削除すると、すべてのテーブルのレプリカステータスを確認できます。 +特定のテーブルのTiFlashレプリカのステータスを確認するには、次のステートメントを使用します。テーブルは`WHERE`句で指定します。`WHERE`の句を削除すると、すべてのテーブルのレプリカステータスを確認できます。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '' and TABLE_NAME = ''; @@ -68,8 +68,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ' 上記のステートメントの結果は次のようになります。 -- `AVAILABLE` 、このテーブルのTiFlashレプリカが使用可能かどうかを示します。2 `1`使用可能、 `0`使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 -- `PROGRESS`レプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。6 `1`少なくとも 1 つのレプリカがレプリケートされていることを意味します。 +- `AVAILABLE` 、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`使用可能、 `0`使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 +- `PROGRESS`レプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`少なくとも 1 つのレプリカがレプリケートされていることを意味します。 ## データベースのTiFlashレプリカを作成する {#create-tiflash-replicas-for-databases} diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index 027b56a5b8e42..8a96a31ef74f7 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -37,10 +37,10 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。1 `batch`バッチ要求の数です。3 `batch_cop`バッチ要求内のコプロセッサ要求の数です。5 `cop`コプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。7 `cop_dag`すべてのコプロセッサ要求内の DAG 要求の数です。9 `super_batch`スーパー バッチ機能を有効にするための要求の数です。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。1 `table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 +- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`バッチ要求の数です。`batch_cop`バッチ要求内のコプロセッサ要求の数です。`cop`コプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`すべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`スーパー バッチ機能を有効にするための要求の数です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`テーブル スキャン Executor です。3 は選択 Executor です`selection` `aggregation`集約 Executor です`top_n`は`TopN` Executor です`limit`制限 Executor です。 - リクエスト期間: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 -- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。1 `meet_lock`読み取りデータがロックされていることを意味します。3 `region_not_found`リージョンが存在しないことを意味します。5 `epoch_not_match`読み取りリージョンエポックがローカル エポックと一致していないことを意味します。7 `kv_client_error` TiKV との通信でエラーが返されたことを意味します`internal_error`はTiFlashの内部システム エラーです。11 `other`その他のタイプのエラーです。 +- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`読み取りデータがロックされていることを意味します。`region_not_found`リージョンが存在しないことを意味します。`epoch_not_match`読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error` TiKV との通信でエラーが返されたことを意味します`internal_error`はTiFlashの内部システム エラーです。11 `other`その他のタイプのエラーです。 - リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 - 応答バイト/秒: すべてのTiFlashインスタンスからの応答の合計バイト数。 - Cop タスクのメモリ使用量: コプロセッサ要求を処理するすべてのTiFlashインスタンスの合計メモリ使用量。 @@ -69,7 +69,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## ストレージ {#storage} - 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1 秒あたりに受信される書き込み要求の数。 -- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。1 `total`この開始以降の書き込み増幅で、 `5min`過去 5 分間の書き込み増幅です。 +- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`この開始以降の書き込み増幅で、 `5min`過去 5 分間の書き込み増幅です。 - 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1 秒あたりの読み取りタスクの数。 - 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 - 内部タスク OPS: すべてのTiFlashインスタンスが 1 秒あたりに内部データ ソート タスクを実行する回数。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index 100f0475941c4..b81bd8035f1d3 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -30,7 +30,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`場合にのみ有効です。 - `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`場合にのみ有効です。 - `--compression` : 対象の圧縮アルゴリズム。値のオプションは`LZ4` （デフォルト）、 `LZ4HC` 、 `zstd` 、 `none`です。 - - `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。2 `compression` `LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。8 `compression` `LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。 + - `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。`compression` `LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。`compression` `LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。 - `--config-file` : `dttool migrate`の設定ファイルは[`server`の設定ファイル](/tiflash/tiflash-command-line-flags.md#server---config-file)と同じです。詳細については`--imitative`参照してください。 - `--file-id` : DTFileのID。例えば、DTFile `dmf_123`のIDは`123`です。 - `--workdir` : `dmf_xxx`の親ディレクトリ。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 111820eb77beb..47bc0c2a7c1ef 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -140,28 +140,28 @@ I/O トラフィック制限設定を構成します。 -- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。1 `foreground_write_weight`フォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`フォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_write_weight` {#background-write-weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `background_write_weight` 、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight` 、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `foreground_read_weight` {#foreground-read-weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `foreground_read_weight` 、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight` 、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_read_weight` {#background-read-weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。1 `background_read_weight` 、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight` 、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 - I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 @@ -350,7 +350,7 @@ I/O トラフィック制限設定を構成します。 ##### `max_threads` {#max-threads} -- `max_threads` 、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。2 `0`設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 +- `max_threads` 、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。`0`設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 - このパラメータは、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) `-1`に設定されている場合にのみ有効になります。 - デフォルト値: `0` @@ -438,7 +438,7 @@ I/O トラフィック制限設定を構成します。 ##### `enable_resource_control`バージョン7.4.0の新機能 {#enable-resource-control-new-in-v740} -- TiFlashリソース制御機能を有効にするかどうかを制御します。1 `true`設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 +- TiFlashリソース制御機能を有効にするかどうかを制御します。`true`設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 - デフォルト値: `true` - 値`false`オプション: `true` @@ -536,7 +536,7 @@ I/O トラフィック制限設定を構成します。 ##### `snap-handle-pool-size` v4.0.0 の新機能 {#snap-handle-pool-size-new-in-v400} -- スナップショットを処理するスレッドの数。1 `0`設定すると、マルチスレッド最適化は無効になります。 +- スナップショットを処理するスレッドの数。`0`設定すると、マルチスレッド最適化は無効になります。 - デフォルト値: `2` #### 安全 {#security} diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index f3cc020a88b23..bc599c30295ef 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -25,7 +25,7 @@ TiFlashは、ClickHouseによって効率的に実装されたコプロセッサ TiFlashは、 TiKVノード内のデータのリアルタイムレプリケーションを低コストで実行します。これにより、TiKVへの書き込みがブロックされることはありません。同時に、TiKVと同様の読み取り一貫性を提供し、最新のデータが読み取られることを保証します。TiFlashのリージョンレプリカはTiKVのレプリカと論理的に同一であり、TiKVのLeaderレプリカと同時に分割・統合されます。 -Linux AMD64アーキテクチャでTiFlash を展開するには、CPU が AVX2 命令セットをサポートしている必要があります。1 `grep avx2 /proc/cpuinfo`出力が生成されることを確認して確認してください。Linux ARM64アーキテクチャの場合、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。3 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して確認してください。これらの命令セット拡張を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 +Linux AMD64アーキテクチャでTiFlash を展開するには、CPU が AVX2 命令セットをサポートしている必要があります。`grep avx2 /proc/cpuinfo`出力が生成されることを確認して確認してください。Linux ARM64アーキテクチャの場合、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。`grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して確認してください。これらの命令セット拡張を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 459dcbb8376cb..b8b77d1604199 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -7,7 +7,7 @@ summary: TiFlashのクエリ結果をトランザクションに保存する方 このドキュメントでは、 `INSERT INTO SELECT`トランザクションでTiFlashクエリ結果を指定された TiDB テーブルに保存する方法を紹介します。 -TiDB v6.5.0以降、 TiFlashクエリ結果をテーブルに保存すること、つまりTiFlashクエリ結果のマテリアライゼーションがサポートされています。1 `INSERT INTO SELECT`のステートメントの実行中に、TiDBが`SELECT`サブクエリをTiFlashにプッシュダウンすると、 `INSERT INTO`番目の句で指定されたTiDBテーブルにTiFlashクエリ結果を保存できます。v6.5.0より前のバージョンのTiDBでは、 TiFlashクエリ結果は読み取り専用であるため、 TiFlashクエリ結果を保存するには、アプリケーションレベルから結果を取得し、別のトランザクションまたはプロセスで保存する必要があります。 +TiDB v6.5.0以降、 TiFlashクエリ結果をテーブルに保存すること、つまりTiFlashクエリ結果のマテリアライゼーションがサポートされています。`INSERT INTO SELECT`のステートメントの実行中に、TiDBが`SELECT`サブクエリをTiFlashにプッシュダウンすると、 `INSERT INTO`番目の句で指定されたTiDBテーブルにTiFlashクエリ結果を保存できます。v6.5.0より前のバージョンのTiDBでは、 TiFlashクエリ結果は読み取り専用であるため、 TiFlashクエリ結果を保存するには、アプリケーションレベルから結果を取得し、別のトランザクションまたはプロセスで保存する必要があります。 > **注記：** > @@ -47,7 +47,7 @@ SELECT app_name, country FROM t1; - TiFlashによるオンライン アプリケーションの提供 - TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。1 `INSERT INTO SELECT`指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 + TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。`INSERT INTO SELECT`指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 ## 例 {#example} diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 91ea99d97dc4b..cd3cf7cbbc4dc 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -29,7 +29,7 @@ TiFlash は様々な理由により正常に起動しない場合があります 4. CPU が SIMD 命令をサポートしているかどうかを確認します。 - バージョン6.3以降、Linux AMD64アーキテクチャでTiFlashを展開するには、AVX2命令セットをサポートするCPUが必要です。1 `grep avx2 /proc/cpuinfo`出力が生成されることを確認して検証してください。Linux ARM64アーキテクチャの場合、CPUはARMv8命令セットアーキテクチャをサポートしている必要があります。3 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して検証してください。 + バージョン6.3以降、Linux AMD64アーキテクチャでTiFlashを展開するには、AVX2命令セットをサポートするCPUが必要です。`grep avx2 /proc/cpuinfo`出力が生成されることを確認して検証してください。Linux ARM64アーキテクチャの場合、CPUはARMv8命令セットアーキテクチャをサポートしている必要があります。`grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して検証してください。 仮想マシンにデプロイするときにこの問題が発生した場合は、VM の CPUアーキテクチャを Haswell に変更してから、 TiFlash を再デプロイしてみてください。 diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 9b4d1a1f228f5..583e8fd84324e 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -33,7 +33,7 @@ MPP実行プランは分散コンピューティングリソースを最大限 set @@tidb_enforce_mpp = ON; ``` -以下の例は、 `tidb_enforce_mpp`有効にする前後のクエリ結果を示しています。この変数を有効にする前は、TiDB は TiKV からデータを読み取り、 `Join`と`Aggregation` TiDB で実行する必要があります。7 `tidb_enforce_mpp`有効にすると、 `Join`と`Aggregation` TiFlashにプッシュダウンされます。また、オプティマイザは必ずしも MPP 実行プランを生成するとは限らないため、 `tidb_enforce_mpp`有効にすることで、オプティマイザに MPP 実行プランを強制的に生成させることができます。 +以下の例は、 `tidb_enforce_mpp`有効にする前後のクエリ結果を示しています。この変数を有効にする前は、TiDB は TiKV からデータを読み取り、 `Join`と`Aggregation` TiDB で実行する必要があります。`tidb_enforce_mpp`有効にすると、 `Join`と`Aggregation` TiFlashにプッシュダウンされます。また、オプティマイザは必ずしも MPP 実行プランを生成するとは限らないため、 `tidb_enforce_mpp`有効にすることで、オプティマイザに MPP 実行プランを強制的に生成させることができます。 MPP モードを有効にする前: @@ -304,7 +304,7 @@ mysql> explain analyze select max(l_shipdate), max(l_commitdate), max(l_receiptd set @@tidb_max_tiflash_threads = 20; ``` -以下の例は、 `tidb_max_tiflash_threads`再設定する前後のクエリ結果を示しています。3 `tidb_max_tiflash_threads`設定する前は、単一のTiFlashインスタンスに対するリクエスト実行の同時実行数は 8 スレッドです。クラスターには合計 3 つのTiFlashインスタンスがあるため、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 24 (8 × 3) です`tidb_max_tiflash_threads` `20`に設定すると、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 60 (20 × 3) になります。 +以下の例は、 `tidb_max_tiflash_threads`再設定する前後のクエリ結果を示しています。`tidb_max_tiflash_threads`設定する前は、単一のTiFlashインスタンスに対するリクエスト実行の同時実行数は 8 スレッドです。クラスターには合計 3 つのTiFlashインスタンスがあるため、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 24 (8 × 3) です`tidb_max_tiflash_threads` `20`に設定すると、すべてのTiFlashインスタンスにおけるリクエスト実行のスレッド数の合計は 60 (20 × 3) になります。 `tidb_max_tiflash_threads`再構成される前: diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index dd949f2e67da6..81e67f3b99a60 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -81,7 +81,7 @@ set @@session.tidb_enforce_mpp=1; ## MPPモードのアルゴリズムサポート {#algorithm-support-for-the-mpp-mode} -MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitという物理アルゴリズムをサポートしています。オプティマイザーは、クエリで使用するアルゴリズムを自動的に決定します。具体的なクエリ実行プランを確認するには、 `EXPLAIN`のステートメントを実行してください。3 `EXPLAIN`のステートメントの結果にExchangeSender演算子とExchangeReceiver演算子が表示された場合、MPPモードが有効になっていることを示します。 +MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitという物理アルゴリズムをサポートしています。オプティマイザーは、クエリで使用するアルゴリズムを自動的に決定します。具体的なクエリ実行プランを確認するには、 `EXPLAIN`のステートメントを実行してください。`EXPLAIN`のステートメントの結果にExchangeSender演算子とExchangeReceiver演算子が表示された場合、MPPモードが有効になっていることを示します。 次のステートメントは、TPC-H テスト セット内のテーブル構造を例として示しています。 diff --git a/tikv-control.md b/tikv-control.md index 037dc39b3f8cf..b620468a2d5e9 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -519,7 +519,7 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001 [storage] data-dir = "/path/to/tikv/data" -`--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。3 `--path`指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 +`--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。`--path`指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 ```shell tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/data/db/CURRENT @@ -540,7 +540,7 @@ tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/dat マスターキーがAWS KMSキーの場合、 `tikv-ctl` KMSキーへのアクセス権を持っている必要があります。AWS KMSキーへのアクセス権は、環境変数、AWSデフォルト設定ファイル、またはIAMロールのいずれか適切な方法で`tikv-ctl`に付与できます。使用方法についてはAWSドキュメントを参照してください。 -`--ids`オプションを使用すると、出力するデータ暗号化キーのIDをカンマ区切りのリストで指定できます。3 `--ids`指定しない場合は、すべてのデータ暗号化キーと、最新のアクティブなデータ暗号化キーのIDである現在のキーIDが出力されます。 +`--ids`オプションを使用すると、出力するデータ暗号化キーのIDをカンマ区切りのリストで指定できます。`--ids`指定しない場合は、すべてのデータ暗号化キーと、最新のアクティブなデータ暗号化キーのIDである現在のキーIDが出力されます。 このコマンドを使用すると、機密情報が公開される可能性があることを警告するメッセージが表示されます。続行するには「同意します」と入力してください。 diff --git a/time-to-live.md b/time-to-live.md index 45bb41bede6e2..41b8de820cfc8 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -271,7 +271,7 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー - 削除がデータ サイズを比較的安定させるのに十分な速さであるかどうかをどのように判断すればよいでしょうか? - [Grafana `TiDB`ダッシュボード](/grafana-tidb-dashboard.md)パネル`TTL Insert Rows Per Hour`は、過去 1 時間に挿入された行の総数を記録します。対応する`TTL Delete Rows Per Hour` 、過去 1 時間に TTL タスクによって削除された行の総数を記録します。7 `TTL Insert Rows Per Hour`長期間にわたって`TTL Delete Rows Per Hour`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: + [Grafana `TiDB`ダッシュボード](/grafana-tidb-dashboard.md)パネル`TTL Insert Rows Per Hour`は、過去 1 時間に挿入された行の総数を記録します。対応する`TTL Delete Rows Per Hour` 、過去 1 時間に TTL タスクによって削除された行の総数を記録します。`TTL Insert Rows Per Hour`長期間にわたって`TTL Delete Rows Per Hour`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: ![insert fast example](/media/ttl/insert-fast.png) diff --git a/tiproxy/tiproxy-api.md b/tiproxy/tiproxy-api.md index 32c1b74b5e8c7..89002ebb4bb13 100644 --- a/tiproxy/tiproxy-api.md +++ b/tiproxy/tiproxy-api.md @@ -11,7 +11,7 @@ summary: TiProxy API を使用して構成、ヘルス ステータス、監視 > > TiProxy APIはデバッグ用に特別に設計されており、TiProxyに将来導入される機能との互換性が完全には保証されない可能性があります。情報取得のためにこのツールをアプリケーションやユーティリティの開発に組み込むことは推奨されません。 -TiProxy APIにアクセスするためのアドレスは`http://${host}:${port}${path}`です。3 `${host}:${port}` TiProxy設定項目[`api.addr`](/tiproxy/tiproxy-configuration.md#addr-1)で指定され、 `${path}`アクセスしたい特定のAPIエンドポイントです。例： +TiProxy APIにアクセスするためのアドレスは`http://${host}:${port}${path}`です。`${host}:${port}` TiProxy設定項目[`api.addr`](/tiproxy/tiproxy-configuration.md#addr-1)で指定され、 `${path}`アクセスしたい特定のAPIエンドポイントです。例： ```bash curl http://127.0.0.1:3080/api/admin/config/ diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 5a58dbbc130d8..2ccaa1fd20cb8 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -65,20 +65,20 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `15` - ホットリロードのサポート: はい - 単位: 秒 -- TiProxy がシャットダウンする際、現在のトランザクション（ドレインクライアントとも呼ばれます）が`graceful-close-conn-timeout`秒以内に完了すると、接続が閉じられます。その後、すべての接続が一度に閉じられます。3 `graceful-close-conn-timeout` `graceful-wait-before-shutdown`後に発生します。このタイムアウトは、トランザクションのライフサイクルよりも長く設定することをお勧めします。 +- TiProxy がシャットダウンする際、現在のトランザクション（ドレインクライアントとも呼ばれます）が`graceful-close-conn-timeout`秒以内に完了すると、接続が閉じられます。その後、すべての接続が一度に閉じられます。`graceful-close-conn-timeout` `graceful-wait-before-shutdown`後に発生します。このタイムアウトは、トランザクションのライフサイクルよりも長く設定することをお勧めします。 #### `max-connections` {#max-connections} - デフォルト値: `0` - ホットリロードのサポート: はい -- 各 TiProxy インスタンスは最大`max-connections`接続を受け入れることができます。3 `0`制限がないことを意味します。 +- 各 TiProxy インスタンスは最大`max-connections`接続を受け入れることができます。`0`制限がないことを意味します。 #### `conn-buffer-size` {#conn-buffer-size} - デフォルト値: `32768` - ホットリロードのサポート: はい、ただし新規接続のみ - 範囲: `[1024, 16777216]` -- この設定項目では、接続バッファのサイズを指定できます。各接続は、読み取りバッファと書き込みバッファをそれぞれ1つずつ使用します。これはメモリとパフォーマンスのトレードオフです。バッファサイズを大きくするとパフォーマンスは向上しますが、メモリ消費量も増加します。1 `0`設定すると、TiProxy はデフォルトのバッファサイズを使用します。 +- この設定項目では、接続バッファのサイズを指定できます。各接続は、読み取りバッファと書き込みバッファをそれぞれ1つずつ使用します。これはメモリとパフォーマンスのトレードオフです。バッファサイズを大きくするとパフォーマンスは向上しますが、メモリ消費量も増加します。`0`設定すると、TiProxy はデフォルトのバッファサイズを使用します。 #### `pd-addrs` {#pd-addrs} @@ -91,7 +91,7 @@ SQL ポートのコンフィグレーション。 - デフォルト値: `""` - ホットリロードのサポート: はい、ただし新規接続のみ - 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。3 `"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 ### API {#api} @@ -101,14 +101,14 @@ HTTP ゲートウェイの構成。 - デフォルト値: `0.0.0.0:3080` - ホットリロードのサポート: いいえ -- APIゲートウェイアドレス。1 `ip:port`指定できます。 +- APIゲートウェイアドレス。`ip:port`指定できます。 #### `proxy-protocol` {#proxy-protocol} - デフォルト値: `""` - ホットリロードのサポート: いいえ - 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。3 `"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 ### バランス {#balance} diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index 19ef8918bded4..275939c0faef4 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -272,7 +272,7 @@ TiProxyとTiDBサーバー間のTLS接続は、以下のルールに従って有 TiProxyには、TiDBと互換性のない以下の動作があります。 -- `STATUS`と`SHOW STATUS`ステートメントは異なるTLS情報を返す可能性があります。5 `STATUS`のステートメントはクライアントとTiProxy間のTLS情報を返し、 `SHOW STATUS`ステートメントはTiProxyとTiDBサーバー間のTLS情報を返します。 +- `STATUS`と`SHOW STATUS`ステートメントは異なるTLS情報を返す可能性があります。`STATUS`のステートメントはクライアントとTiProxy間のTLS情報を返し、 `SHOW STATUS`ステートメントはTiProxyとTiDBサーバー間のTLS情報を返します。 - TiProxy は[証明書ベースの認証](/certificate-authentication.md)サポートしていません。そうでない場合、クライアントと TiProxy 間の TLS 証明書が TiProxy と TiDBサーバー間の TLS 証明書と異なるため、クライアントはログインに失敗する可能性があります。TiDBサーバーはTiProxy 上の TLS 証明書に基づいて TLS 証明書を検証します。 ## 制限事項 {#limitations} diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index 64457486abba8..133749ecd55e3 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -52,7 +52,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア tiproxyctl traffic capture --host 10.0.1.10 --port 3080 --output="/tmp/traffic" --duration=1h ``` - トラフィックファイルは自動的にローテーションされ、圧縮されます。1 `/tmp/traffic`内のファイルの例: + トラフィックファイルは自動的にローテーションされ、圧縮されます。`/tmp/traffic`内のファイルの例: ```shell ls /tmp/traffic diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index a3a73ebb67230..1f76d22b8fe23 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -129,7 +129,7 @@ monitored: ### `server_configs` {#server-configs} -`server_configs` 、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 `global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。4 `server_configs`は主に以下のフィールドが含まれます。 +`server_configs` 、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。`server_configs`は主に以下のフィールドが含まれます。 - `tidb` : TiDBサービス関連の設定。詳細な設定については[TiDB構成ファイル](/tidb-configuration-file.md)参照してください。 @@ -426,7 +426,7 @@ tiflash_servers: ### `tiproxy_servers` {#tiproxy-servers} -`tiproxy_servers` 、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。2 `tiproxy_servers`配列であり、配列の各要素には次のフィールドが含まれます。 +`tiproxy_servers` 、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。`tiproxy_servers`配列であり、配列の各要素には次のフィールドが含まれます。 - `host` : TiProxyサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 @@ -577,7 +577,7 @@ cdc_servers: ### `tso_servers` {#tso-servers} -`tso_servers` 、 `tso`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。4 `tso_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 +`tso_servers` 、 `tso`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。`tso_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 - `host` : `tso`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールド値は必須です。 - `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 @@ -607,7 +607,7 @@ tso_servers: ### `scheduling_servers` {#scheduling-servers} -`scheduling_servers` 、 `scheduling`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。4 `scheduling_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 +`scheduling_servers` 、 `scheduling`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。`scheduling_servers`配列であり、配列の各要素には以下のフィールドが含まれます。 - `host` : `scheduling`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 - `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index c106889838cb6..89b4cb79144b5 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -548,7 +548,7 @@ tiup cluster audit 4BLhr0 ## TiDB クラスター内のホストでコマンドを実行する {#run-commands-on-a-host-in-the-tidb-cluster} -TiDBクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 +TiDBクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。`exec`のコマンドの使用方法は次のとおりです。 ```bash Usage: diff --git a/tiup/tiup-command-install.md b/tiup/tiup-command-install.md index 576de769e87b2..df1634b5dd1c8 100644 --- a/tiup/tiup-command-install.md +++ b/tiup/tiup-command-install.md @@ -13,7 +13,7 @@ summary: "tiup installコマンドは、ミラーリポジトリからコンポ tiup install [:version] [component2...N] [flags] ``` -``と``コンポーネント名を表し、 `[version]`オプションのバージョン番号を表します。6 `version`追加されていない場合は、指定されたコンポーネントの最新の安定バージョンがインストールされます。8 `[component2...N]` 、複数のコンポーネント、または同じコンポーネントの複数のバージョンを同時に指定できることを意味します。 +``と``コンポーネント名を表し、 `[version]`オプションのバージョン番号を表します。`version`追加されていない場合は、指定されたコンポーネントの最新の安定バージョンがインストールされます。`[component2...N]` 、複数のコンポーネント、または同じコンポーネントの複数のバージョンを同時に指定できることを意味します。 ## オプション {#option} diff --git a/tiup/tiup-command-list.md b/tiup/tiup-command-list.md index 392006205fc1a..b88bd9a4e725e 100644 --- a/tiup/tiup-command-list.md +++ b/tiup/tiup-command-list.md @@ -13,7 +13,7 @@ summary: tiup list`コマンドは、ミラーで利用可能なコンポーネ tiup list [component] [flags] ``` -`[component]` 、特定のコンポーネントを指定するために使用されるオプションパラメータです。2 `[component]`設定されている場合、 TiUP は指定されたコンポーネントのすべてのバージョンを一覧表示します。そうでない場合、 TiUP はすべてのコンポーネントを一覧表示します。 +`[component]` 、特定のコンポーネントを指定するために使用されるオプションパラメータです。`[component]`設定されている場合、 TiUP は指定されたコンポーネントのすべてのバージョンを一覧表示します。そうでない場合、 TiUP はすべてのコンポーネントを一覧表示します。 ## オプション {#options} diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index ae73002d61978..d673a24b80d64 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -40,7 +40,7 @@ tiup mirror genkey [flags] ### - 保存 {#save} -- 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。3 `hash-prefix`鍵IDの最初の16ビットです。 +- 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。`hash-prefix`鍵IDの最初の16ビットです。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-command-mirror-grant.md b/tiup/tiup-command-mirror-grant.md index e224738524558..5dc865364f118 100644 --- a/tiup/tiup-command-mirror-grant.md +++ b/tiup/tiup-command-mirror-grant.md @@ -32,7 +32,7 @@ tiup mirror grant [flags] ### -n, --name {#n-name} -- コンポーネント所有者の名前を指定します。名前はコンポーネントリストの`Owner`フィールドに表示されます。3 `-n/--name`指定されていない場合は、 ``コンポーネント所有者の名前として使用されます。 +- コンポーネント所有者の名前を指定します。名前はコンポーネントリストの`Owner`フィールドに表示されます。`-n/--name`指定されていない場合は、 ``コンポーネント所有者の名前として使用されます。 - データ型: `STRING` - デフォルト: `` diff --git a/tiup/tiup-command-mirror-publish.md b/tiup/tiup-command-mirror-publish.md index b5ad6e77c22d0..61edbcc39f46f 100644 --- a/tiup/tiup-command-mirror-publish.md +++ b/tiup/tiup-command-mirror-publish.md @@ -46,7 +46,7 @@ tiup mirror publish [flags] ### --os {#os} -- ``のバイナリファイルが実行できるオペレーティングシステムを指定します。3 ``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 +- ``のバイナリファイルが実行できるオペレーティングシステムを指定します。``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 - `linux` : ファイルが Linux オペレーティング システムで実行されることを示します。 - `darwin` : ファイルが Darwin オペレーティング システムで実行されることを示します。 diff --git a/tiup/tiup-command-mirror-set.md b/tiup/tiup-command-mirror-set.md index 6329c9b939260..b937733b45932 100644 --- a/tiup/tiup-command-mirror-set.md +++ b/tiup/tiup-command-mirror-set.md @@ -34,7 +34,7 @@ tiup mirror set [flags] tiup mirror set -r /path/to/local/root.json -上記の手順では、 `wget`コマンドの前にミラーが攻撃された場合、ルート証明書が正しくないことが分かります。3 `wget`コマンドの後にミラーが攻撃された場合、 TiUPはミラーがルート証明書と一致しないことを検出します。 +上記の手順では、 `wget`コマンドの前にミラーが攻撃された場合、ルート証明書が正しくないことが分かります。`wget`コマンドの後にミラーが攻撃された場合、 TiUPはミラーがルート証明書と一致しないことを検出します。 - データ型: `String` - デフォルト: `{mirror-dir}/root.json` diff --git a/tiup/tiup-command-uninstall.md b/tiup/tiup-command-uninstall.md index ea220a00c46a5..b371637ca25eb 100644 --- a/tiup/tiup-command-uninstall.md +++ b/tiup/tiup-command-uninstall.md @@ -21,13 +21,13 @@ tiup uninstall : [component2...N] [flags] ### --all {#all} -- 指定されたコンポーネントのインストール済みバージョンをすべてアンインストールします。1 ``省略した場合は、このオプションを使用する必要があります。 +- 指定されたコンポーネントのインストール済みバージョンをすべてアンインストールします。``省略した場合は、このオプションを使用する必要があります。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### - 自己 {#self} -- TiUP自体をアンインストールします。このオプションを使用すると、ミラーからダウンロードされたすべてのデータが削除されますが、 TiUPとそのコンポーネントによって生成されたデータは保持されます。データは環境変数`TIUP_HOME`で指定されたディレクトリに保存されます。3 `TIUP_HOME`設定されていない場合、デフォルト値は`~/.tiup/`です。 +- TiUP自体をアンインストールします。このオプションを使用すると、ミラーからダウンロードされたすべてのデータが削除されますが、 TiUPとそのコンポーネントによって生成されたデータは保持されます。データは環境変数`TIUP_HOME`で指定されたディレクトリに保存されます。`TIUP_HOME`設定されていない場合、デフォルト値は`~/.tiup/`です。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index 28323d22d9f08..1735ac3a50e8a 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -39,7 +39,7 @@ tiup cluster deploy [flags] ### --ignore-config-check {#ignore-config-check} -- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。3 ``デプロイされたバイナリファイルのパスです。5 ``ユーザー設定に基づいて生成された構成ファイルです。 +- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。``デプロイされたバイナリファイルのパスです。``ユーザー設定に基づいて生成された構成ファイルです。 - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 - デフォルト: false diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 34faf9e746b1c..584a6840d813f 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -82,7 +82,7 @@ tiup cluster display [flags] - ポート: サービスが占有するポート番号 - OS/アーキテクチャ: このノードのオペレーティングシステムとマシンアーキテクチャ - ステータス: ノードサービスの現在のステータス - - データ ディレクトリ: サービスのデータ ディレクトリ。1 `-`データ ディレクトリがないことを意味します。 + - データ ディレクトリ: サービスのデータ ディレクトリ。`-`データ ディレクトリがないことを意味します。 - デプロイディレクトリ: サービスのデプロイディレクトリ ### ノードサービスステータス {#node-service-status} diff --git a/tiup/tiup-component-cluster-help.md b/tiup/tiup-component-cluster-help.md index 9ef4fc98d9b50..177c3009e6685 100644 --- a/tiup/tiup-component-cluster-help.md +++ b/tiup/tiup-component-cluster-help.md @@ -5,7 +5,7 @@ summary: tiup-cluster は、コマンドラインインターフェースでユ # tiup cluster help {#tiup-cluster-help} -tiup-cluster は、コマンドラインインターフェースでユーザー向けに豊富なヘルプ情報を提供します。ヘルプ情報は、コマンド`help`またはオプション`--help`で取得できます。5 `tiup cluster help `基本的に`tiup cluster --help`と同じです。 +tiup-cluster は、コマンドラインインターフェースでユーザー向けに豊富なヘルプ情報を提供します。ヘルプ情報は、コマンド`help`またはオプション`--help`で取得できます。`tiup cluster help `基本的に`tiup cluster --help`と同じです。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 55f0b371960c5..053fd6206efb3 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -35,7 +35,7 @@ tiup cluster reload [flags] ### --ignore-config-check {#ignore-config-check} -- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。3 ``デプロイされたバイナリファイルのパスです。5 ``ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 +- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。``デプロイされたバイナリファイルのパスです。``ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 - データ型: `BOOLEAN` - デフォルト: false @@ -87,7 +87,7 @@ tiup cluster reload [flags] - リロード前にスクリプトを実行します。 - データ型: `STRINGS` -- このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。1 `--skip-restart` `true`に設定した場合は無効になります。 +- このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。`--skip-restart` `true`に設定した場合は無効になります。 ### --post-restart-script {#post-restart-script} @@ -97,7 +97,7 @@ tiup cluster reload [flags] - リロード後にスクリプトを実行します。 - データ型: `STRINGS` -- このオプションは、ノードのリロード後に実行されるスクリプトのパスを指定します。1 `--skip-restart` `true`に設定されている場合は有効になりません。 +- このオプションは、ノードのリロード後に実行されるスクリプトのパスを指定します。`--skip-restart` `true`に設定されている場合は有効になりません。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-rename.md b/tiup/tiup-component-cluster-rename.md index 0ad094b9ebb46..a0fa5004f1289 100644 --- a/tiup/tiup-component-cluster-rename.md +++ b/tiup/tiup-component-cluster-rename.md @@ -11,7 +11,7 @@ summary: tiup cluster renameコマンドは、デプロイ後にクラスター > > TiUPクラスターの`dashboard_dir`フィールドが`grafana_servers`に設定されている場合、コマンド`tiup cluster rename`を実行してクラスターの名前を変更した後、次の追加手順が必要になります。 > -> - ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、各ファイルの`datasource`フィールドを新しいクラスター名に更新します。5 `datasource`値はクラスターの名前である必要があるためです。 +> - ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、各ファイルの`datasource`フィールドを新しいクラスター名に更新します。`datasource`値はクラスターの名前である必要があるためです。 > - コマンド`tiup cluster reload -R grafana`を実行します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index 8c21d57363a7b..cfcba92c3eb63 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -30,7 +30,7 @@ tiup cluster upgrade [flags] ### --transfer-timeout {#transfer-timeout} -- PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。1 `-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 +- PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。`-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 - データ型: `uint` - デフォルト: 600 @@ -40,7 +40,7 @@ tiup cluster upgrade [flags] ### --ignore-config-check {#ignore-config-check} -- バイナリの更新後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。3 ``新しくデプロイされたバイナリへのパス、 ``ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 +- バイナリの更新後、 ` --config-check `使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``新しくデプロイされたバイナリへのパス、 ``ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 - データ型: `BOOLEAN` - デフォルト: false diff --git a/tiup/tiup-component-dm-display.md b/tiup/tiup-component-dm-display.md index 32ce22d1ebc8e..2ccb54d2f0f53 100644 --- a/tiup/tiup-component-dm-display.md +++ b/tiup/tiup-component-dm-display.md @@ -55,7 +55,7 @@ tiup dm display [flags] - `Ports` : サービスで使用されるポート番号。 - `OS/Arch` : ノードのオペレーティング システムとマシンアーキテクチャ。 - `Status` : ノード上のサービスの現在のステータス。 - - `Data Dir` : サービスのデータ ディレクトリ。2 `-`データ ディレクトリが存在しないことを意味します。 + - `Data Dir` : サービスのデータ ディレクトリ。`-`データ ディレクトリが存在しないことを意味します。 - `Deploy Dir` : サービスのデプロイメント ディレクトリ。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-scale-out.md b/tiup/tiup-component-dm-scale-out.md index 5faa58fa68878..4f28b998ea335 100644 --- a/tiup/tiup-component-dm-scale-out.md +++ b/tiup/tiup-component-dm-scale-out.md @@ -5,7 +5,7 @@ summary: tiup dm scale-out` コマンドは、新しいノードへの SSH 接 # tiup dm scale-out {#tiup-dm-scale-out} -`tiup dm scale-out`コマンドはクラスタのスケールアウトに使用されます。クラスタのスケールアウトの内部ロジックは、クラスタのデプロイメントと同様です。3 `tiup-dm`コンポーネントは、まず新しいノードへのSSH接続を確立し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメントを実行してサービスを起動します。 +`tiup dm scale-out`コマンドはクラスタのスケールアウトに使用されます。クラスタのスケールアウトの内部ロジックは、クラスタのデプロイメントと同様です。`tiup-dm`コンポーネントは、まず新しいノードへのSSH接続を確立し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメントを実行してサービスを起動します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index d963b531d0585..c325a05d7e627 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -136,7 +136,7 @@ tiup status - `Name` : インスタンスのタグ名。 - `Component` : インスタンスのコンポーネント名。 - `PID` : 動作中のインスタンスのプロセス ID。 -- `Status` : インスタンスのステータス。2 `RUNNING`インスタンスが動作中であることを意味します。4 `TERM`インスタンスが終了していることを意味します。 +- `Status` : インスタンスのステータス。`RUNNING`インスタンスが動作中であることを意味します。`TERM`インスタンスが終了していることを意味します。 - `Created Time` : インスタンスの開始時刻。 - `Directory` : インスタンスの作業ディレクトリ`--tag`を使用して指定できます。 - `Binary` : インスタンスの実行可能プログラム`--binpath`を使用して指定できます。 @@ -154,7 +154,7 @@ tiup clean [tag] [flags] - `--all` : すべてのインスタンス情報をクリーンアップします。 -上記のコマンドでは、 `tag`クリーンアップするインスタンスタグです。3 `--all`使用すると、タグは渡されません。 +上記のコマンドでは、 `tag`クリーンアップするインスタンスタグです。`--all`使用すると、タグは渡されません。 例 1: `experiment`タグ名を持つコンポーネントインスタンスをクリーンアップします。 @@ -183,7 +183,7 @@ tiup uninstall [component][:version] [flags] - `--all` : すべてのコンポーネントまたはバージョンをアンインストールします。 - `--self` : TiUP自体をアンインストールします。 -`component`はアンインストールするコンポーネントです。2 `version`アンインストールするバージョンです。8 `tiup uninstall`では、 `component`と`version`どちらも無視できます。どちらか一方を無視する場合は、 `--all`フラグを追加する必要があります。 +`component`はアンインストールするコンポーネントです。`version`アンインストールするバージョンです。`tiup uninstall`では、 `component`と`version`どちらも無視できます。どちらか一方を無視する場合は、 `--all`フラグを追加する必要があります。 - バージョンを無視する場合、 `--all`を追加すると、このコンポーネントのすべてのバージョンがアンインストールされます。 - バージョンとコンポーネントの両方が無視される場合、 `--all`追加すると、すべてのバージョンのすべてのコンポーネントがアンインストールされます。 diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 3cd207ebedbbd..4aacbf428928a 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -25,7 +25,7 @@ TiUPを使用した DM クラスターのデプロイメントのトポロジ構 `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。2 ``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 +- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 - `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 - `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 @@ -63,7 +63,7 @@ global: ### `server_configs` {#server-configs} -`server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。6 `server_configs`は主に以下のフィールドが含まれます。 +`server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。`server_configs`は主に以下のフィールドが含まれます。 - `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)参照してください。 - `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)参照してください。 diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 5c2d08c7f7e55..bba556a7e1cf8 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -142,7 +142,7 @@ tiup playground scale-out --db 2 ## クラスタースケールイン {#scale-in-a-cluster} -対応するインスタンスでスケールするには、 `tiup playground scale-in`コマンドで`pid`を指定できます。5 `pid`表示するには、 `tiup playground display`実行します。 +対応するインスタンスでスケールするには、 `tiup playground scale-in`コマンドで`pid`を指定できます。`pid`表示するには、 `tiup playground display`実行します。 ```shell tiup playground scale-in --pid 86526 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index 1400313927b04..f4d745ec8517f 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -17,7 +17,7 @@ tiup [flags] [args...] # Runs a component `--help`コマンドを使用すると、特定のコマンドの情報を取得できます。各コマンドの概要には、そのパラメータと使用方法が表示されます。必須パラメータは山括弧で、オプションパラメータは角括弧で示されます。 -``コマンド名を表します。サポートされているコマンドのリストについては、以下の[コマンドリスト](#command-list)参照してください。4 ``コンポーネント名を表します。サポートされているコンポーネントのリストについては、以下の[コンポーネントリスト](#component-list)参照してください。 +``コマンド名を表します。サポートされているコマンドのリストについては、以下の[コマンドリスト](#command-list)参照してください。``コンポーネント名を表します。サポートされているコンポーネントのリストについては、以下の[コンポーネントリスト](#component-list)参照してください。 ## オプション {#options} @@ -25,7 +25,7 @@ tiup [flags] [args...] # Runs a component - このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 - - `tiup --binary `実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。5 ``インストールされていない場合はエラーが返されます。 + - `tiup --binary `実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。``インストールされていない場合はエラーが返されます。 - `tiup --binary :`実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 - データ型: `BOOLEAN` diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ba4809fba802..09966febbd206 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -11,11 +11,11 @@ summary: TiUPの使用中に問題が発生した場合のトラブルシュー ### tiup listを使用して最新のコンポーネントリストを表示できません {#can-t-see-the-latest-component-list-using-code-tiup-list-code} -TiUPはミラーサーバーから最新のコンポーネントリストを毎回更新するわけではありません。1 `tiup list`実行することで、コンポーネントリストを強制的に更新できます。 +TiUPはミラーサーバーから最新のコンポーネントリストを毎回更新するわけではありません。`tiup list`実行することで、コンポーネントリストを強制的に更新できます。 ### tiup list <component>を使用してコンポーネントの最新バージョン情報を表示できません {#can-t-see-the-latest-version-information-of-a-component-using-code-tiup-list-x3c-component-code} -前回の問題と同様に、コンポーネントのバージョン情報は、ローカルキャッシュが存在しない場合にのみミラーサーバーから取得されます。1 `tiup list `実行することでコンポーネントリストを更新できます。 +前回の問題と同様に、コンポーネントのバージョン情報は、ローカルキャッシュが存在しない場合にのみミラーサーバーから取得されます。`tiup list `実行することでコンポーネントリストを更新できます。 ### コンポーネントのダウンロードプロセスが中断されました {#component-downloading-process-is-interrupted} @@ -33,7 +33,7 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック この問題を解決するには、 `tiup cluster deploy -i identity_file`実行して秘密鍵を指定したかどうかを確認します。 -- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。3 `-i`使用して秘密鍵のパスを明示的に指定することをお勧めします。 +- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。`-i`使用して秘密鍵のパスを明示的に指定することをお勧めします。 - フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。3コマンド`ssh -i identity_file user@remote`手動で実行することで確認できます。 - リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index c28665f9290ce..1769ef1c2386c 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -15,7 +15,7 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる #### 現象 {#phenomenon} -- スローログにクエリ実行プランが出力されている場合は、プランを直接確認できます。1 `select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行プランを解析できます。 +- スローログにクエリ実行プランが出力されている場合は、プランを直接確認できます。`select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行プランを解析できます。 - モニター内のスキャンされたキーの数が異常に増加し、スローログでは`Scan Keys`の数が多くなります。 - TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行プランと比較することで、例えば`Join Order`異なるかどうかなどを確認できます。 @@ -27,7 +27,7 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる - 統計情報を更新する - `analyze table`手動で実行し、統計の正確性を維持するために、 `crontab`コマンドを使用して`analyze`定期的に実行します。 - - `auto analyze`自動的に実行します。3 `analyze ratio`しきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。 + - `auto analyze`自動的に実行します。`analyze ratio`しきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。 - `set global tidb_auto_analyze_ratio=0.2;` - `set global tidb_auto_analyze_start_time='00:00 +0800';` - `set global tidb_auto_analyze_end_time='06:00 +0800';` @@ -78,7 +78,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - TiKVが再開されたため再選。 - TiKVがパニック状態になった後、 `systemd`引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合は[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md) 。 - - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。3 `dmesg` TiKVログを確認して原因を確認してください。 + - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。`dmesg` TiKVログを確認して原因を確認してください。 - TiKV は OOM であり、再起動を引き起こします。 - `THP` (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。 diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index a4807918253a8..231ec075802a8 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -30,7 +30,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ **TiKV-Details** > **Raft IO**では、これら 2 つのインスタンスのディスク書き込みに関連するメトリックを確認できます。 -- `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。2 `.99`応答時間は50ミリ秒以内である必要があります。 +- `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。`.99`応答時間は50ミリ秒以内である必要があります。 - `Apply log duration` ：このメトリックは、実データを格納するRockDBへの書き込みの応答時間を示します。 `.99`時間は100ミリ秒以内である必要があります。 これら 2 つのメトリックには、書き込みホットスポットを表示するのに役立つ**サーバーごとの**監視パネルもあります。 @@ -67,7 +67,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ - クライアントが`server is busy`や特に`raftstore is busy`などのエラーを報告する場合、エラーは I/O の問題に関連している可能性があります。 - `busy`エラーの具体的な原因を確認するには、監視パネル（ **Grafana** -> **TiKV** -> **errors** ）を確認してください。9 `server is busy` TiKVのフロー制御メカニズムです。これにより、TiKVは`tidb/ti-client` 、現在のTiKVの負荷が高すぎるため、クライアントは後で再試行する必要があることを通知します。 + `busy`エラーの具体的な原因を確認するには、監視パネル（ **Grafana** -> **TiKV** -> **errors** ）を確認してください。`server is busy` TiKVのフロー制御メカニズムです。これにより、TiKVは`tidb/ti-client` 、現在のTiKVの負荷が高すぎるため、クライアントは後で再試行する必要があることを通知します。 - TiKV RocksDB ログに`Write stall`表示されます。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 3affeed9ad8ec..d1b266ce04233 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -41,7 +41,7 @@ TiDBは各テーブルにTableID、各インデックスにIndexID、各行にRo ### テーブルホットスポット {#table-hotspots} -TiDBのコーディングルールによれば、同一テーブルのデータはTableIDの先頭で始まる範囲に収められ、RowID値の順序で並べられます。テーブルへの挿入時にRowID値が増加する場合、挿入された行は末尾にのみ追加されます。Regionは一定のサイズに達すると分割されますが、その後も範囲の末尾にのみ追加できます。1 `INSERT`操作は1つのリージョンに対してのみ実行でき、ホットスポットを形成します。 +TiDBのコーディングルールによれば、同一テーブルのデータはTableIDの先頭で始まる範囲に収められ、RowID値の順序で並べられます。テーブルへの挿入時にRowID値が増加する場合、挿入された行は末尾にのみ追加されます。Regionは一定のサイズに達すると分割されますが、その後も範囲の末尾にのみ追加できます。`INSERT`操作は1つのリージョンに対してのみ実行でき、ホットスポットを形成します。 一般的なAUTO_INCREMENT主キーは、順次増加します。主キーが整数型の場合、デフォルトで主キーの値がRowIDとして使用されます。この場合、RowIDは順次増加し、 `INSERT`操作が多数発生すると、テーブルの書き込みホットスポットが発生します。 @@ -81,7 +81,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ ## SHARD_ROW_ID_BITSを使用してホットスポットを処理する {#use-code-shard-row-id-bits-code-to-process-hotspots} -非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的なAUTO_INCREMENT RowIDを使用します。1 `INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +非クラスター化主キーまたは主キーのないテーブルの場合、TiDBは暗黙的なAUTO_INCREMENT RowIDを使用します。`INSERT`操作が多数存在する場合、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)設定すると、行 ID が分散されて複数のリージョンに書き込まれるため、書き込みホットスポットの問題を軽減できます。 @@ -98,7 +98,7 @@ ALTER TABLE: ALTER TABLE t SHARD_ROW_ID_BITS = 4; `SHARD_ROW_ID_BITS`の値は動的に変更できます。変更された値は、新しく書き込まれたデータにのみ適用されます。 -`CLUSTERED`型の主キーを持つテーブルの場合、TiDBはテーブルの主キーをRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS`オプションはRowIDの生成ルールを変更するため使用できません。5 `NONCLUSTERED`の主キーを持つテーブルの場合、TiDBは自動的に割り当てられた64ビット整数をRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS` `CLUSTERED`が使用できます。9型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +`CLUSTERED`型の主キーを持つテーブルの場合、TiDBはテーブルの主キーをRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS`オプションはRowIDの生成ルールを変更するため使用できません。`NONCLUSTERED`の主キーを持つテーブルの場合、TiDBは自動的に割り当てられた64ビット整数をRowIDとして使用します。この場合、 `SHARD_ROW_ID_BITS` `CLUSTERED`が使用できます。9型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 以下の2つの負荷図は、主キーを持たない2つのテーブルで`SHARD_ROW_ID_BITS`使用してホットスポットを分散させた場合を示しています。最初の図はホットスポットを分散させる前の状況を示し、2番目の図はホットスポットを分散させた後の状況を示しています。 diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 41d0c8121021a..c4d1e1c5d9aef 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)トランザクションモデルを用いてトランザクションを実装します。3 `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 プロセスを開始します。 @@ -62,7 +62,7 @@ TiDBログを検索するキーワードとして`[kv:9007]Write conflict`を使 - `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`示します。4ツール`pd-ctl`使用して、 `start_ts`物理時間に変換できます。 - `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`示します。 - `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`示します。 -- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。2 `tableID`書き込み競合テーブルのIDを示します。4 `indexID`書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力。8 `indexValues`競合が発生しているインデックスの値を示します。 +- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。`tableID`書き込み競合テーブルのIDを示します。`indexID`書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力。`indexValues`競合が発生しているインデックスの値を示します。 - `primary={tableID=47, indexID=1, indexValues={string, }}` : 現在のトランザクションの主キー情報を示します。 `pd-ctl`ツールを使用して、タイムスタンプを読み取り可能な時間に変換できます。 diff --git a/tune-operating-system.md b/tune-operating-system.md index 51fe9742c944e..0905e544e9a62 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -99,7 +99,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler #### mountパラメータ {#code-mount-code-parameters} -`mount`コマンドで`noatime`オプションが有効になっている場合、ファイルの読み取り時にメタデータの更新が無効になります。5 `nodiratime`動作が有効になっている場合、ディレクトリの読み取り時にメタデータの更新が無効になります。 +`mount`コマンドで`noatime`オプションが有効になっている場合、ファイルの読み取り時にメタデータの更新が無効になります。`nodiratime`動作が有効になっている場合、ディレクトリの読み取り時にメタデータの更新が無効になります。 ### ネットワークチューニング {#network-tuning} diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index 355e6f743f553..6028db1b9620b 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -45,7 +45,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ3. TiUPが使用できる新しいPrometheusパッケージを作成する {#step-3-create-a-new-prometheus-package-that-tiup-can-use} 1. [ステップ1](#step-1-download-a-new-prometheus-installation-package-from-the-prometheus-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-prometheus-installation-package-provided-by-tidb)で抽出した`./prometheus-v{version}-linux-amd64/prometheus`ディレクトリ内のファイルを置き換えます。 -2. `./prometheus-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`prometheus-v{new-version}.tar.gz`という名前を付けます。5 `{new-version}`必要に応じて指定できます。 +2. `./prometheus-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`prometheus-v{new-version}.tar.gz`という名前を付けます。`{new-version}`必要に応じて指定できます。 ```bash cd prometheus-v{version}-linux-amd64 @@ -92,7 +92,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ3. TiUPが使用できる新しいGrafanaパッケージを作成する {#step-3-create-a-new-grafana-package-that-tiup-can-use} 1. [ステップ1](#step-1-download-a-new-grafana-installation-package-from-the-grafana-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-grafana-installation-package-provided-by-tidb)で抽出した`./grafana-v{version}-linux-amd64/`ディレクトリ内のファイルを置き換えます。 -2. `./grafana-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`grafana-v{new-version}.tar.gz`という名前を付けます。5 `{new-version}`必要に応じて指定できます。 +2. `./grafana-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`grafana-v{new-version}.tar.gz`という名前を付けます。`{new-version}`必要に応じて指定できます。 ```bash cd grafana-v{version}-linux-amd64 diff --git a/user-account-management.md b/user-account-management.md index 746ce29ff1e14..8cc7978dc5757 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -171,7 +171,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ 1. tidb-server インスタンスの 1 つが配置されているマシンにログインします。 2. TiDB ノードのデプロイメント ディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 - 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)追加します。5 `security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 + 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 [security] skip-grant-table = true diff --git a/wrong-index-solution.md b/wrong-index-solution.md index 65381573efae8..5cf475ac79209 100644 --- a/wrong-index-solution.md +++ b/wrong-index-solution.md @@ -21,7 +21,7 @@ summary: 間違ったインデックスの問題を解決する方法を学び ### 健康状態が低い {#low-health-state} -ヘルス状態が低いということは、TiDBが`ANALYZE`ステートメントを長期間実行していないことを意味します。3 `ANALYZE`コマンドを実行することで統計情報を更新できます。更新後もオプティマイザーが誤ったインデックスを使用している場合は、次のセクションを参照してください。 +ヘルス状態が低いということは、TiDBが`ANALYZE`ステートメントを長期間実行していないことを意味します。`ANALYZE`コマンドを実行することで統計情報を更新できます。更新後もオプティマイザーが誤ったインデックスを使用している場合は、次のセクションを参照してください。 ### ほぼ100%の健康状態 {#near-100-health-state}