diff --git a/README.md b/README.md index 7fbaf2ff12fa3..9ad41f2e4e751 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ TiDB ドキュメントへようこそ! TiDB ドキュメント内の特定のコンテンツを自由に並べ替えたり削除したりするなど、特定のシナリオのニーズに合わせて TiDB ドキュメントをローカルでカスタマイズして PDF 形式で出力する場合は、 [TiDBドキュメントPDF生成チュートリアル](/resources/tidb-pdf-generation-tutorial.md)を参照してください。 -現在、公式ドキュメントは次の 2 つの言語をサポートしています。 +現在、公式ドキュメントは次の2つの言語をサポートしています。 - `en` : [英語のドキュメント](https://docs.pingcap.com/tidb/stable) - `zh` : [中国語のドキュメント](https://docs.pingcap.com/zh/tidb/stable) @@ -63,7 +63,7 @@ Google翻訳を使えば、ドキュメントを様々な言語で閲覧でき 貢献者になるには[TiDB ドキュメント貢献ガイド](/CONTRIBUTING.md)ご覧ください！🤓 -pingcap/docs のアクティブな貢献者 - 過去 28 日間 +pingcap/docs のアクティブな貢献者 - 過去 28日間 ## ライセンス {#license} diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md index d49ab65f80c0d..1480bc3b2064a 100644 --- a/ai/guides/filtering.md +++ b/ai/guides/filtering.md @@ -15,7 +15,7 @@ summary: アプリケーションでフィルタリングを使用する方法 `pytidb`を使用する場合、 `table.query()` 、 `table.delete()` 、 `table.update()` 、および`table.search()`メソッドに**filters**パラメータを渡すことでフィルタリングを適用できます。 -**フィルター**パラメータは、 [辞書フィルター](#dictionary-filters)と[SQL文字列フィルター](#sql-string-filters) 2 つの形式をサポートします。 +**フィルター**パラメータは、 [辞書フィルター](#dictionary-filters)と[SQL文字列フィルター](#sql-string-filters) 2つの形式をサポートします。 ## 辞書フィルター {#dictionary-filters} diff --git a/ai/guides/reranking.md b/ai/guides/reranking.md index 9cf7fa437de3f..bbd6b35a77662 100644 --- a/ai/guides/reranking.md +++ b/ai/guides/reranking.md @@ -7,7 +7,7 @@ summary: アプリケーションで再ランキングを使用する方法を 再ランキングは、専用の再ランキング モデルを使用して検索結果を再評価および並べ替えることで、検索結果の関連性と精度を向上させるために使用される手法です。 -検索プロセスは次の 2 つの段階で行われます。 +検索プロセスは次の2つの段階で行われます。 1. **初期検索**: ベクトル検索により、コレクションから最も類似性の高い上位`k`ドキュメントが識別されます。 2. **再ランキング**: 再ランキング モデルは、クエリとドキュメント間の関連性に基づいてこれら`k`ドキュメントを評価し、それらを並べ替えて最終的な上位`n`結果 ( `n` ≤ `k` ) を生成します。 diff --git a/ai/guides/tables.md b/ai/guides/tables.md index 1951475a48d37..6c0422f502f7b 100644 --- a/ai/guides/tables.md +++ b/ai/guides/tables.md @@ -88,7 +88,7 @@ CREATE TABLE items (
-`table.insert()`メソッドを使用して、テーブルに 1 つのレコードを挿入します。 +`table.insert()`メソッドを使用して、テーブルに 1つのレコードを挿入します。 ```python table.insert( @@ -104,7 +104,7 @@ table.insert(
-`INSERT INTO`ステートメントを使用して、テーブルに 1 つのレコードを挿入します。 +`INSERT INTO`ステートメントを使用して、テーブルに 1つのレコードを挿入します。 ```sql INSERT INTO items(id, content, embedding, meta) @@ -162,7 +162,7 @@ VALUES
-辞書と共に`table.insert()`メソッドを使用して、テーブルに 1 つのレコードを挿入します。 +辞書と共に`table.insert()`メソッドを使用して、テーブルに 1つのレコードを挿入します。 ```python table.insert({ @@ -176,7 +176,7 @@ table.insert({
-`INSERT INTO`ステートメントを使用して、テーブルに 1 つのレコードを挿入します。 +`INSERT INTO`ステートメントを使用して、テーブルに 1つのレコードを挿入します。 ```sql INSERT INTO items(id, content, embedding, meta) diff --git a/ai/guides/vector-search-hybrid-search.md b/ai/guides/vector-search-hybrid-search.md index 88c911f039431..aaf41c8fb4a4a 100644 --- a/ai/guides/vector-search-hybrid-search.md +++ b/ai/guides/vector-search-hybrid-search.md @@ -147,7 +147,7 @@ df = ( 融合手法は、ベクトル（意味）検索と全文（キーワード）検索の結果を統合し、単一の統一されたランキングを作成します。これにより、最終結果が意味的な関連性とキーワードの一致の両方を活用できるようになります。 -`pytidb` 2 つの融合方法をサポートしています。 +`pytidb` 2つの融合方法をサポートしています。 - `rrf` : 相互ランク融合 (デフォルト) - `weighted` : 加重スコア融合 diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index 8e455c6ce4130..8acdadd920ab7 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -22,7 +22,7 @@ summary: アプリケーションでベクトル検索を使用する方法を `client.create_table()`を使用してテーブルを作成し、 `VectorField`を使用してベクトル フィールドを定義できます。 -次の例では、4 つの列を持つ`documents`テーブルを作成します。 +次の例では、4つの列を持つ`documents`テーブルを作成します。 - `id` : テーブルの主キー。 - `text` : ドキュメントのテキストコンテンツ。 @@ -71,7 +71,7 @@ CREATE TABLE documents ( - `text_vec`列は`VECTOR(3)`として定義されているため、この列に格納されるベクトルは 3 次元である必要があります。 - ベクトル検索のパフォーマンスを最適化するために、 `VEC_COSINE_DISTANCE`関数を使用してベクトル インデックスが作成されます。 -TiDB はベクトル インデックスに対して 2 つの距離関数をサポートしています。 +TiDB はベクトル インデックスに対して 2つの距離関数をサポートしています。 - `VEC_COSINE_DISTANCE` : 2つのベクトル間のコサイン距離を計算する - `VEC_L2_DISTANCE` : 2つのベクトル間のL2距離（ユークリッド距離）を計算する @@ -83,7 +83,7 @@ TiDB はベクトル インデックスに対して 2 つの距離関数をサ デモンストレーションとして、いくつかのテキストとそれに対応する埋め込みをテーブルに挿入します。 -次の例では、それぞれ単純な 3 次元ベクトル埋め込みを持つ 3 つのドキュメントを挿入します。 +次の例では、それぞれ単純な 3 次元ベクトル埋め込みを持つ 3つのドキュメントを挿入します。 - `dog`ベクトル埋め込み`[1, 2, 1]` - `fish`ベクトル埋め込み`[1, 2, 4]` @@ -293,7 +293,7 @@ LIMIT 10; TiDB でのベクトル検索では、スカラー フィールド (整数や文字列など) または JSON フィールドにメタデータ フィルタリングを適用できます。 -通常、メタデータ フィルタリングと組み合わせたベクトル検索には、次の 2 つのモードがあります。 +通常、メタデータ フィルタリングと組み合わせたベクトル検索には、次の2つのモードがあります。 - **後フィルタリング**：TiDBはまずベクトル検索を実行し、ベクトル空間全体から上位k個の候補を取得し、その候補セットにフィルターを適用します。ベクトル検索段階では、効率性を高めるため、通常、ベクトルインデックスが使用されます。 - **事前フィルタリング**：TiDBはベクトル検索の前にフィルタを適用します。フィルタの選択性が高く、フィルタリング対象フィールドにスカラーインデックスがある場合、このモードにより検索空間が縮小され、パフォーマンスが向上します。 diff --git a/ai/integrations/vector-search-integrate-with-django-orm.md b/ai/integrations/vector-search-integrate-with-django-orm.md index 90e0c35b242f1..c9c1c0354a2b8 100644 --- a/ai/integrations/vector-search-integrate-with-django-orm.md +++ b/ai/integrations/vector-search-integrate-with-django-orm.md @@ -241,7 +241,7 @@ TiDB Vectorは以下の距離関数をサポートしています。 - `CosineDistance` - `NegativeInnerProduct` -コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3 つのドキュメントを検索します。 +コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3つのドキュメントを検索します。 ```python results = Document.objects.annotate( diff --git a/ai/integrations/vector-search-integrate-with-langchain.md b/ai/integrations/vector-search-integrate-with-langchain.md index 843f37b3144c5..6beb7dce81918 100644 --- a/ai/integrations/vector-search-integrate-with-langchain.md +++ b/ai/integrations/vector-search-integrate-with-langchain.md @@ -415,7 +415,7 @@ TiDBベクトルストア内の各ドキュメントには、JSONオブジェク ### 例 {#example} -次の例では、2 つのドキュメントを`TiDBVectorStore`に追加し、各ドキュメントにメタデータとして`title`フィールドを追加します。 +次の例では、2つのドキュメントを`TiDBVectorStore`に追加し、各ドキュメントにメタデータとして`title`フィールドを追加します。 ```python vector_store.add_texts( diff --git a/ai/integrations/vector-search-integrate-with-peewee.md b/ai/integrations/vector-search-integrate-with-peewee.md index f4bd36fcd3962..000472907ffa3 100644 --- a/ai/integrations/vector-search-integrate-with-peewee.md +++ b/ai/integrations/vector-search-integrate-with-peewee.md @@ -232,7 +232,7 @@ Document.create(content='tree', embedding=[1, 0, 0]) ### 最近傍の文書を検索 {#search-the-nearest-neighbor-documents} -コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3 つのドキュメントを検索します。 +コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3つのドキュメントを検索します。 ```python distance = Document.embedding.cosine_distance([1, 2, 3]).alias('distance') diff --git a/ai/integrations/vector-search-integrate-with-sqlalchemy.md b/ai/integrations/vector-search-integrate-with-sqlalchemy.md index d5492f6e7fa65..1e8e0065f1558 100644 --- a/ai/integrations/vector-search-integrate-with-sqlalchemy.md +++ b/ai/integrations/vector-search-integrate-with-sqlalchemy.md @@ -198,7 +198,7 @@ with Session(engine) as session: ### 最近傍の文書を検索 {#search-the-nearest-neighbor-documents} -コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3 つのドキュメントを検索します。 +コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3つのドキュメントを検索します。 ```python with Session(engine) as session: diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md index 9c0de80dbe681..070fe142404a2 100644 --- a/ai/quickstart-via-python.md +++ b/ai/quickstart-via-python.md @@ -191,7 +191,7 @@ table.search( この例では、ベクトル検索はクエリベクトル`text_vec`テーブルの`chunks`フィールドに格納されているベクトルと比較し、類似度スコアに基づいて意味的に最も関連性の高い上位3つの結果を返します。 -`_distance`が近いほど、2 つのベクトルはより類似していることを意味します。 +`_distance`が近いほど、2つのベクトルはより類似していることを意味します。 ```json title="Expected output" [ diff --git a/ai/quickstart-via-sql.md b/ai/quickstart-via-sql.md index 27852c6532c6b..429201b6edb78 100644 --- a/ai/quickstart-via-sql.md +++ b/ai/quickstart-via-sql.md @@ -145,7 +145,7 @@ SELECT * FROM embedded_documents; この例では、検索語は「泳ぐ動物」であり、それに対応するベクトル埋め込みは`[1,2,3]`であると想定されています。実際のアプリケーションでは、埋め込みモデルを使用して、ユーザーの検索語をベクトル埋め込みに変換する必要があります。 -次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `vec_cosine_distance` ) を計算してソートすることにより、 `[1,2,3]`に最も近い上位 3 つのドキュメントを特定します。 +次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `vec_cosine_distance` ) を計算してソートすることにより、 `[1,2,3]`に最も近い上位 3つのドキュメントを特定します。 ```sql SELECT id, document, vec_cosine_distance(embedding, '[1,2,3]') AS distance @@ -167,7 +167,7 @@ LIMIT 3; 3 rows in set (0.15 sec) ``` -検索結果の 3 つの用語は、クエリされたベクトルからのそれぞれの距離によってソートされます。距離が小さいほど、対応する`document`の関連性が高くなります。 +検索結果の 3つの用語は、クエリされたベクトルからのそれぞれの距離によってソートされます。距離が小さいほど、対応する`document`の関連性が高くなります。 したがって、出力結果から判断すると、泳いでいる動物は魚か、泳ぎの才能に恵まれた犬である可能性が最も高い。 diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index cb5a3ef8cf9dd..8bc2a750e687c 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -90,14 +90,14 @@ INSERT INTO vector_table VALUES (2, '[0.3, 0.5]'); -- 2 dimensions vector, - `[1,2,3] = [1,2,3]` - `[2,2,3] > [1,2,3]` -異なる次元を持つ 2 つのベクトルは、次の規則に従って辞書式比較を使用して比較されます。 +異なる次元を持つ 2つのベクトルは、次の規則に従って辞書式比較を使用して比較されます。 -- 2 つのベクトルは最初から要素ごとに比較され、各要素は数値的に比較されます。 +- 2つのベクトルは最初から要素ごとに比較され、各要素は数値的に比較されます。 - 最初の不一致要素によって、どのベクトルが辞書式に他のベクトルより*小さい*か*大きいかが*決まります。 - あるベクトルが別のベクトルの接頭辞である場合、短いベクトルは辞書順でもう一方より*小さく*なります。例えば、 `[1,2,3] < [1,2,3,0]` 。 - 同じ長さで同一の要素を持つベクトルは辞書的に*等しい*です。 - 空ベクトルは、辞書順で空でないベクトルよりも*小さい*。例えば、 `[] < [1]` 。 -- 2 つの空のベクトルは辞書的に*等しい*です。 +- 2つの空のベクトルは辞書的に*等しい*です。 ベクトル定数を比較する場合は、文字列値に基づく比較を避けるために、文字列からベクトルへの[明示的なキャスト](#cast)実行を検討してください。 diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md index 06e8f70e07621..2e93608e64bd9 100644 --- a/ai/reference/vector-search-functions-and-operators.md +++ b/ai/reference/vector-search-functions-and-operators.md @@ -106,7 +106,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou VEC_L2_DISTANCE(vector1, vector2) ``` -次の式を使用して、2 つのベクトル間の[L2距離](https://en.wikipedia.org/wiki/Euclidean_distance) (ユークリッド距離) を計算します。 +次の式を使用して、2つのベクトル間の[L2距離](https://en.wikipedia.org/wiki/Euclidean_distance) (ユークリッド距離) を計算します。 $距離(p,q)=\sqrt {\sum \limits *{i=1}^{n}{(p* {i}-q_{i})^{2}}}$ @@ -132,7 +132,7 @@ SELECT VEC_L2_DISTANCE('[0, 3]', '[4, 0]'); VEC_COSINE_DISTANCE(vector1, vector2) ``` -次の式を使用して 2 つのベクトル間の[コサイン距離](https://en.wikipedia.org/wiki/Cosine_similarity)を計算します。 +次の式を使用して 2つのベクトル間の[コサイン距離](https://en.wikipedia.org/wiki/Cosine_similarity)を計算します。 $距離(p,q)=1.0 - {\frac {\sum \limits *{i=1}^{n}{p* {i}q_{i}}}{{\sqrt {\sum \limits *{i=1}^{n}{p* {i}^{2}}}}\cdot {\sqrt {\sum \limits *{i=1}^{n}{q* {i}^{2}}}}}}$ @@ -160,7 +160,7 @@ SELECT VEC_COSINE_DISTANCE('[1, 1]', '[-1, -1]'); VEC_NEGATIVE_INNER_PRODUCT(vector1, vector2) ``` -次の数式を使用して、2 つのベクトル間の[内積](https://en.wikipedia.org/wiki/Dot_product)の負の値を使用して距離を計算します。 +次の数式を使用して、2つのベクトル間の[内積](https://en.wikipedia.org/wiki/Dot_product)の負の値を使用して距離を計算します。 $DISTANCE(p,q)=- INNER_PROD(p,q)=-\sum \limits *{i=1}^{n}{p* {i}q_{i}}$ @@ -186,7 +186,7 @@ SELECT VEC_NEGATIVE_INNER_PRODUCT('[1, 2]', '[3, 4]'); VEC_L1_DISTANCE(vector1, vector2) ``` -次の式を使用して、2 つのベクトル間の[L1距離](https://en.wikipedia.org/wiki/Taxicab_geometry) (マンハッタン距離) を計算します。 +次の式を使用して、2つのベクトル間の[L1距離](https://en.wikipedia.org/wiki/Taxicab_geometry) (マンハッタン距離) を計算します。 $距離(p,q)=\sum \limits *{i=1}^{n}{|p* {i}-q_{i}|}$ diff --git a/ai/vector-search-get-started-using-python.md b/ai/vector-search-get-started-using-python.md index a18c826845137..d3d91a1851f9f 100644 --- a/ai/vector-search-get-started-using-python.md +++ b/ai/vector-search-get-started-using-python.md @@ -203,7 +203,7 @@ vector_store.insert( このステップでは、「泳ぐ動物」という単語を検索しますが、既存の文書にはこの単語と直接一致するものはありません。 -以下のコードは`text_to_embedding()`関数を再度使用してクエリテキストをベクトル埋め込みに変換し、その埋め込みを使用してクエリを実行して、最も近い上位 3 つの一致を見つけます。 +以下のコードは`text_to_embedding()`関数を再度使用してクエリテキストをベクトル埋め込みに変換し、その埋め込みを使用してクエリを実行して、最も近い上位 3つの一致を見つけます。 ```python def print_result(query, result): @@ -226,7 +226,7 @@ Search result ("a swimming animal"): - text: "tree", distance: 0.798545178640937 ``` -検索結果の 3 つの用語は、クエリされたベクトルからのそれぞれの距離によってソートされます。距離が小さいほど、対応する`document`の関連性が高くなります。 +検索結果の 3つの用語は、クエリされたベクトルからのそれぞれの距離によってソートされます。距離が小さいほど、対応する`document`の関連性が高くなります。 したがって、出力結果から判断すると、泳いでいる動物は魚か、泳ぎの才能に恵まれた犬である可能性が最も高い。 diff --git a/alert-rules.md b/alert-rules.md index 600d800468fc1..b4c77a7e15151 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -59,7 +59,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - TiDB の最新スキーマ情報の再読み込みに失敗した回数の合計。10 分間に 10 回以上再読み込みに失敗した場合にアラートがトリガーされます。 + TiDB の最新スキーマ情報の再読み込みに失敗した回数の合計。10分間に 10回以上再読み込みに失敗した場合にアラートがトリガーされます。 - 解決： @@ -105,7 +105,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - TiDB でのリクエスト処理のレイテンシー。リクエストの 99% の応答時間は 1 秒以内である必要があります。それ以外の場合は、アラートがトリガーされます。 + TiDB でのリクエスト処理のレイテンシー。リクエストの 99% の応答時間は 1秒以内である必要があります。それ以外の場合は、アラートがトリガーされます。 - 解決： @@ -184,7 +184,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - PD は長時間にわたって TiKV/ TiFlashハートビートを受信していません (デフォルト設定は 30 分です)。 + PD は長時間にわたって TiKV/ TiFlashハートビートを受信していません (デフォルト設定は 30分です)。 - 解決： @@ -481,7 +481,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - 1. [**TiKV詳細**> **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラートが発生した TiKV ノードのRaftプロポーズが他の TiKV ノードよりも大幅に高いかどうかを確認します。もしそうであれば、この TiKV に 1 つ以上のホットスポットがあることを意味します。ホットスポットのスケジューリングが適切に機能するかどうかを確認する必要があります。 + 1. [**TiKV詳細**> **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラートが発生した TiKV ノードのRaftプロポーズが他の TiKV ノードよりも大幅に高いかどうかを確認します。もしそうであれば、この TiKV に 1つ以上のホットスポットがあることを意味します。ホットスポットのスケジューリングが適切に機能するかどうかを確認する必要があります。 2. [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 3. [**TiKV詳細**>**Raftプロセス**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。 @@ -764,7 +764,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - TiKV 分割チェッカーによってスキャンされるリージョンの最大おおよそのサイズは、1 分以内に継続的に 1 GB を超えます。 + TiKV 分割チェッカーによってスキャンされるリージョンの最大おおよそのサイズは、1分以内に継続的に 1 GB を超えます。 - 解決： @@ -1101,9 +1101,9 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー - 説明： - ping のレイテンシーが1 秒を超えています。 + ping のレイテンシーが1秒を超えています。 - 解決： - - Grafana Blackbox Exporter ページで 2 つのノード間の pingレイテンシーを確認し、遅延が高すぎないかどうかを確認します。 + - Grafana Blackbox Exporter ページで 2つのノード間の pingレイテンシーを確認し、遅延が高すぎないかどうかを確認します。 - Grafana Node Exporter ページの TCP パネルをチェックして、パケット損失があるかどうかを確認します。 diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index bcb9fb3e174e8..2501b578af444 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -5,7 +5,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 # スロークエリを分析する {#analyze-slow-queries} -クエリの速度低下の問題を解決するには、次の 2 つの手順を実行する必要があります。 +クエリの速度低下の問題を解決するには、次の2つの手順を実行する必要があります。 1. 多数のクエリの中で、どのタイプのクエリが遅いかを特定します。 2. このタイプのクエリが遅い理由を分析します。 diff --git a/api/ticdc-api-overview.md b/api/ticdc-api-overview.md index 5d75e3e35bd98..643d7f868b76d 100644 --- a/api/ticdc-api-overview.md +++ b/api/ticdc-api-overview.md @@ -7,7 +7,7 @@ summary: TiCDC の API を学習します。 [TiCDC](/ticdc/ticdc-overview.md) 、TiDBから増分データを複製するために使用されるツールです。具体的には、TiCDCはTiKVの変更ログを取得し、キャプチャしたデータをソートし、行ベースの増分データを下流のデータベースにエクスポートします。 -TiCDC は、TiCDC クラスターのクエリと操作用に次の 2 つのバージョンの API を提供します。 +TiCDC は、TiCDC クラスターのクエリと操作用に次の2つのバージョンの API を提供します。 - [TiCDC OpenAPI v1](/ticdc/ticdc-open-api.md) - [TiCDC OpenAPI v2](/ticdc/ticdc-open-api-v2.md) diff --git a/as-of-timestamp.md b/as-of-timestamp.md index bdced1f8f79cb..0bcc416a3e0b2 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -15,7 +15,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 ## 構文 {#syntax} -`AS OF TIMESTAMP`句は次の 3 つの方法で使用できます。 +`AS OF TIMESTAMP`句は次の3つの方法で使用できます。 - [`SELECT ... FROM ... AS OF TIMESTAMP`](/sql-statements/sql-statement-select.md) - [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) @@ -27,10 +27,10 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 `AS OF TIMESTAMP`句の例をいくつか示します。 -- `AS OF TIMESTAMP '2016-10-08 16:45:26'` : 2016 年 10 月 8 日 16:45:26 に保存された最新のデータを読み取るように TiDB に指示します。 -- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` : TiDB に 10 秒前に保存された最新のデータを読み取るように指示します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` : 2016 年 10 月 8 日の 16:45:26 から 16:45:29 までの範囲内でできるだけ新しいデータを読み取るように TiDB に指示します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() - INTERVAL 20 SECOND, NOW())` : 20 秒前から現在までの時間範囲内で可能な限り新しいデータを読み取るように TiDB に指示します。 +- `AS OF TIMESTAMP '2016-10-08 16:45:26'` : 2016年 10月 8日 16:45:26 に保存された最新のデータを読み取るように TiDB に指示します。 +- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` : TiDB に 10秒前に保存された最新のデータを読み取るように指示します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` : 2016年 10月 8日の 16:45:26 から 16:45:29 までの範囲内でできるだけ新しいデータを読み取るように TiDB に指示します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() - INTERVAL 20 SECOND, NOW())` : 20秒前から現在までの時間範囲内で可能な限り新しいデータを読み取るように TiDB に指示します。 > **Note:** > diff --git a/auto-random.md b/auto-random.md index c5b5870954701..3a9c3fc9779d3 100644 --- a/auto-random.md +++ b/auto-random.md @@ -117,7 +117,7 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 | --------- | ------ | ------------ | | `64-R`ビット | `S`ビット | `R-S`ビット | -- `AUTO_RANDOM`カラムに符号付きビットがあるかどうかは、そのカラムに`UNSIGNED`属性があるかどうかによって決まります。`UNSIGNED`属性のないカラムには 1 つの符号付きビットがあり、`UNSIGNED`属性のあるカラムには符号付きビットがありません。 +- `AUTO_RANDOM`カラムに符号付きビットがあるかどうかは、そのカラムに`UNSIGNED`属性があるかどうかによって決まります。`UNSIGNED`属性のないカラムには 1つの符号付きビットがあり、`UNSIGNED`属性のあるカラムには符号付きビットがありません。 - `AUTO_RANDOM`カラムに暗黙的に割り当てられる値は常に正です。符号付きビットを持つカラムでは、暗黙的に割り当てられる値の符号付きビットは常に`0`です。このルールは、明示的に挿入される値には適用されません。 - 予約ビットの長さは`64-R`です。予約ビットは常に`0`です。 - AUTO_INCREMENTビットは少なくとも 27 ビット必要です。符号付きカラムでは、`R-1-S >= 27`を満たす必要があります。符号なしカラムでは、`R-S >= 27`を満たす必要があります。 diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index d343aaea4765e..23b088a3e7a5d 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -77,7 +77,7 @@ LIMIT ### ターゲットとなるTiKVクラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster} -ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に x 2 が含まれている理由は次のとおりです。 +ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に x 2 が含まれている理由は次のとおりです。 - インデックスには余分な容量が必要になる場合があります。 - RocksDBには空間増幅がある。 @@ -139,7 +139,7 @@ LIMIT nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & ``` -3. インポートが開始されたら、ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 +3. インポートが開始されたら、ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5分ごとに更新されます。 4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index 2cb3439212d8c..88c6144c155c9 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -60,7 +60,7 @@ creating view revenue1 ## TiFlashレプリカを作成する {#create-tiflash-replicas} -TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複製しません。`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; diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 5e8c48ac6ff76..fb01727639046 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -111,7 +111,7 @@ MySQL クライアントを再起動し、次の SQL ステートメントを実 create database sbtest; ``` -Sysbench スクリプトがインデックスを作成する順序を調整します。Sysbench は「テーブルの作成 -> データの挿入 -> インデックスの作成」という順序でデータをインポートするため、TiDB によるデータのインポートに時間がかかります。ユーザーはこの順序を調整することで、データのインポートを高速化できます。Sysbench バージョン[1.0.20](https://github.com/akopytov/sysbench/tree/1.0.20)を使用している場合、順序は次の 2 つの方法で調整できます。 +Sysbench スクリプトがインデックスを作成する順序を調整します。Sysbench は「テーブルの作成 -> データの挿入 -> インデックスの作成」という順序でデータをインポートするため、TiDB によるデータのインポートに時間がかかります。ユーザーはこの順序を調整することで、データのインポートを高速化できます。Sysbench バージョン[1.0.20](https://github.com/akopytov/sysbench/tree/1.0.20)を使用している場合、順序は次の2つの方法で調整できます。 - TiDB 用に変更された[oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench/sysbench-patch/oltp_common.lua)ファイルをダウンロードし、 `/usr/share/sysbench/oltp_common.lua`ファイルをそれで上書きします。 - `/usr/share/sysbench/oltp_common.lua`で、行[235-240](https://github.com/akopytov/sysbench/blob/1.0.20/src/lua/oltp_common.lua#L235-L240)行 198 のすぐ後ろに移動します。 diff --git a/benchmark/benchmark-tidb-using-tpcc.md b/benchmark/benchmark-tidb-using-tpcc.md index 274ca03cf4974..19358a8e3fda2 100644 --- a/benchmark/benchmark-tidb-using-tpcc.md +++ b/benchmark/benchmark-tidb-using-tpcc.md @@ -21,9 +21,9 @@ TPC-Cベンチマークでは、テスト前にデータベースの初期状態 - `STOCK`テーブルにはW * 100,000件のレコードがあります（各倉庫は100,000点の在庫データに対応します） - `DISTRICT`テーブルにはW * 10のレコードがあります（各倉庫は10の地区にサービスを提供しています） -- `CUSTOMER`テーブルには W * 10 * 3,000 のレコードがあります (各地区には 3,000 人の顧客がいます) -- `HISTORY`テーブルには W * 10 * 3,000 件のレコードがあります (各顧客には 1 つのトランザクション履歴があります) -- `ORDER`テーブルには W * 10 * 3,000 件のレコードがあります (各地区には 3,000 件の注文があり、生成された最後の 900 件の注文が`NEW-ORDER`テーブルに追加されます。各注文は 5 ~ 15 件の ORDER-LINE レコードをランダムに生成します。) +- `CUSTOMER`テーブルには W * 10 * 3,000 のレコードがあります (各地区には 3,000人の顧客がいます) +- `HISTORY`テーブルには W * 10 * 3,000件のレコードがあります (各顧客には 1つのトランザクション履歴があります) +- `ORDER`テーブルには W * 10 * 3,000件のレコードがあります (各地区には 3,000件の注文があり、生成された最後の 900件の注文が`NEW-ORDER`テーブルに追加されます。各注文は 5 ~ 15件の ORDER-LINE レコードをランダムに生成します。) このドキュメントでは、TiDB をテストするために、例として 1,000 個のウェアハウスを使用します。 @@ -37,7 +37,7 @@ tiup install bench TiUP Benchコンポーネントの詳細な使用方法については、 [TiUP Bench](/tiup/tiup-bench.md)を参照してください。 -172.16.5.140 と 172.16.5.141 にある 2 つの TiDB サーバーを含む TiDB クラスターを展開し、両方のサーバーがポート 4000 でリッスンしているとします。次の手順で TPC-C テストを実行できます。 +172.16.5.140 と 172.16.5.141 にある 2つの TiDB サーバーを含む TiDB クラスターを展開し、両方のサーバーがポート 4000 でリッスンしているとします。次の手順で TPC-C テストを実行できます。 ## データを読み込む {#load-data} diff --git a/benchmark/online-workloads-and-add-index-operations.md b/benchmark/online-workloads-and-add-index-operations.md index 6077d78bcc686..b71a3616a10b8 100644 --- a/benchmark/online-workloads-and-add-index-operations.md +++ b/benchmark/online-workloads-and-add-index-operations.md @@ -19,7 +19,7 @@ TiDB バージョン: v3.0.1 ## テスト環境 {#test-environment} -このテストは、3 つの TiDB インスタンス、3 つの TiKV インスタンス、3 つの PD インスタンスがデプロイされた Kubernetes クラスターで実行されます。 +このテストは、3つの TiDB インスタンス、3つの TiKV インスタンス、3つの PD インスタンスがデプロイされた Kubernetes クラスターで実行されます。 ### バージョン情報 {#version-information} @@ -85,7 +85,7 @@ sysbench $testname \ 2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_write`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 -5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 +5. 2つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 ### テスト結果 {#test-results} @@ -220,7 +220,7 @@ sysbench $testname \ 2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 -5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 +5. 2つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 ### テスト結果 {#test-results} @@ -282,7 +282,7 @@ sysbench $testname \ 2. 手順 1 と同時に実行します。`alter table test add index pad_idx(pad)`を使用してインデックスを追加します。 3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 -5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 +5. 2つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 ### テスト結果 {#test-results} diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index 47e9a78acc6e2..bf5f0be4d158a 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -196,7 +196,7 @@ set global tidb_tso_client_batch_max_wait_time = 2; # default: 0 チューニング後、次の効果が見られます。 -- 1 秒あたりの TSO リクエストは 64,800 に減少します。 +- 1秒あたりの TSO リクエストは 64,800 に減少します。 - CPU 使用率は約 4,600% から 1,400% に大幅に減少しました。 - P999 値`PD server TSO handle time`が 2ms から 0.5ms に減少します。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 30eecf949e8c0..56a4a9507ba5c 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -78,7 +78,7 @@ absent -> delete only -> write only -> write reorg -> public
-TiDB v6.2.0 より前では、所有者は一度に同じタイプ (論理または物理) の DDL タスクを 1 つしか実行できないため、制限が比較的厳しく、ユーザー エクスペリエンスに影響します。 +TiDB v6.2.0 より前では、所有者は一度に同じタイプ (論理または物理) の DDL タスクを 1つしか実行できないため、制限が比較的厳しく、ユーザー エクスペリエンスに影響します。 DDLタスク間に依存関係がない場合、並列実行はデータの正確性と一貫性に影響を与えません。例えば、ユーザーAがテーブル`T1`にインデックスを追加し、ユーザーBがテーブル`T2`から列を削除するとします。これらの2つのDDL文は並列実行可能です。 @@ -121,9 +121,9 @@ v6.2.0 より前では、 TiDB SQLレイヤーで非同期スキーマ変更を TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限がありました。 -- TiKV クラスターには、それぞれ論理 DDL と物理 DDL を処理するキュー`general job queue`と`add index job queue` 2 つのキューのみがあります。 +- TiKV クラスターには、それぞれ論理 DDL と物理 DDL を処理するキュー`general job queue`と`add index job queue` 2つのキューのみがあります。 - DDL 所有者は常に先入先出方式で DDL ジョブを処理します。 -- DDL 所有者は、一度に同じタイプ (論理または物理) の DDL タスクを 1 つだけ実行できます。これは比較的厳格であり、ユーザー エクスペリエンスに影響します。 +- DDL 所有者は、一度に同じタイプ (論理または物理) の DDL タスクを 1つだけ実行できます。これは比較的厳格であり、ユーザー エクスペリエンスに影響します。 これらの制限により、意図しないDDLブロッキング動作が発生する可能性があります。詳細については、 [SQL FAQ - DDL実行](https://docs.pingcap.com/tidb/stable/sql-faq#ddl-execution)を参照してください。 @@ -147,7 +147,7 @@ TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限 > **Tip:** > -> - 前述の 2 つの変数は、DDL タスクの実行中に動的に調整され、次のトランザクション バッチで有効になります。 +> - 前述の2つの変数は、DDL タスクの実行中に動的に調整され、次のトランザクション バッチで有効になります。 > - DDL操作の種類とアプリケーションの負荷状況に応じて、適切なタイミングでDDL操作を実行してください。例えば、アプリケーションの負荷が低い場合は、 `ADD INDEX`操作を実行することをお勧めします。 > - インデックスの追加には比較的長い時間がかかるため、TiDBはコマンド送信後、バックグラウンドでタスクを実行します。TiDBサーバーがダウンしていても、実行には影響ありません。 diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index d114a2fa2aa47..8cbd3d0a93f31 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -17,7 +17,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc TiDB 2.1.3以降のバージョンでは、TiDBモニタリングはプル方式をサポートしています。これは以下の利点を持つ優れた調整です。 - Prometheus を移行する必要がある場合、TiDB クラスター全体を再起動する必要はありません。調整前に Prometheus を移行するには、ターゲットアドレスを更新する必要があるため、クラスター全体を再起動する必要があります。 -- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2 つの個別のセットを展開できます。 +- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2つの個別のセットを展開できます。 - 単一障害点となる可能性のある Pushgateway が削除されます。 ## 監視データのソースと表示 {#source-and-display-of-monitoring-data} @@ -67,7 +67,7 @@ Prometheusは多くのクエリ式と関数をサポートしています。詳 ## Grafanaのヒント {#grafana-tips} -このセクションでは、Grafana を使用して TiDB のメトリックを効率的に監視および分析するための 7 つのヒントを紹介します。 +このセクションでは、Grafana を使用して TiDB のメトリックを効率的に監視および分析するための 7つのヒントを紹介します。 ### ヒント1: すべてのディメンションをチェックしてクエリ式を編集する {#tip-1-check-all-dimensions-and-edit-the-query-expression} @@ -148,7 +148,7 @@ PDダッシュボードには、現在のリーダーの指標のみが表示さ GrafanaはPrometheusのAPIを介してデータを取得します。このAPIを使用して情報を取得することもできます。さらに、以下の用途もあります。 - クラスターのサイズやステータスなどの情報を自動的に取得します。 -- 1 日あたりの QPS の合計量、1 日あたりの QPS のピーク値、1 日あたりの応答時間のカウントなど、レポートの情報を提供するために式に小さな変更を加えます。 +- 1日あたりの QPS の合計量、1日あたりの QPS のピーク値、1日あたりの応答時間のカウントなど、レポートの情報を提供するために式に小さな変更を加えます。 - 重要な指標について定期的な健全性検査を実行します。 Prometheus の API は次のようになります。 diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index bbf1859bd5ffc..558a9cf62c580 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -23,7 +23,7 @@ HAProxyは、LinuxカーネルのコアコントリビューターであるWilly ## 基本機能 {#basic-features} - [高可用性](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.4) : HAProxy は、正常なシャットダウンとシームレスな切り替えをサポートする高可用性を提供します。 -- [負荷分散](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-balance) : 2 つの主要なプロキシ モード (レイヤー4 とも呼ばれる TCP とレイヤー7 とも呼ばれる HTTP) がサポートされています。ラウンドロビン、Leastconn、ランダムなど、9 種類以上の負荷分散アルゴリズムがサポートされています。 +- [負荷分散](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-balance) : 2つの主要なプロキシ モード (レイヤー4 とも呼ばれる TCP とレイヤー7 とも呼ばれる HTTP) がサポートされています。ラウンドロビン、Leastconn、ランダムなど、9種類以上の負荷分散アルゴリズムがサポートされています。 - [健康チェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。 - [スティッキーセッション](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.6) : アプリケーションがスティッキーセッションをサポートしていない間、HAProxy はクライアントを特定のサーバーに固定することができます。 - [SSL](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.2) : HTTPS 通信と解決がサポートされます。 diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index c684f276e9ebe..50c8b769adb80 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -213,7 +213,7 @@ create table t (a int, b int) SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=3; - `SHARD_ROW_ID_BITS = 4` 、 `tidb_rowid`の値が 16 (16=2^4) の範囲にランダムに分散されることを意味します。 - `PRE_SPLIT_REGIONS=3` 、テーブルが作成後に 8 (2^3) 個のリージョンに事前に分割されることを意味します。 -テーブル`t`にデータの書き込みが開始されると、データは事前​​に分割された 8 つのリージョンに書き込まれます。これにより、テーブルの作成後に 1 つのリージョンのみが存在する場合に発生する可能性のあるホットスポットの問題が回避されます。 +テーブル`t`にデータの書き込みが開始されると、データは事前​​に分割された 8つのリージョンに書き込まれます。これにより、テーブルの作成後に 1つのリージョンのみが存在する場合に発生する可能性のあるホットスポットの問題が回避されます。 > **Note:** > diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index fe46f5e4ca2e9..ea8fdb8d4c092 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -110,7 +110,7 @@ DESC TIDB_INDEX_USAGE; #### データの更新が遅れている {#data-updates-are-delayed} -パフォーマンスへの影響を最小限に抑えるため、 `TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5 分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 +パフォーマンスへの影響を最小限に抑えるため、 `TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 #### インデックス使用状況データは保存されません {#index-usage-data-is-not-persisted} @@ -157,7 +157,7 @@ ORDER BY total_queries DESC; - データ更新の遅延 - パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5 分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 + パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 - メモリベースのストレージ @@ -263,10 +263,10 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; ### インデックスを不可視のままにできる期間はどのくらいですか? {#how-long-can-an-index-remain-invisible} - OLTP ワークロード: 毎日の変動を考慮するために少なくとも 1 週間監視します。 -- バッチ処理または ETL ワークロード: 月次財務レポートなどの 1 つの完全なレポート サイクルを許可します。 +- バッチ処理または ETL ワークロード: 月次財務レポートなどの 1つの完全なレポート サイクルを許可します。 - アドホック分析クエリ: クエリ ログを使用して、インデックスを削除する前にインデックスが必要ないことを確認します。 -安全のため、最終決定を下す前にすべてのワークロードがテストされていることを確認するために、少なくとも 1 つのビジネス サイクル全体にわたってインデックスを不可視にしておきます。 +安全のため、最終決定を下す前にすべてのワークロードがテストされていることを確認するために、少なくとも 1つのビジネス サイクル全体にわたってインデックスを不可視にしておきます。 ## インデックス最適化のベストプラクティストップ5 {#top-five-best-practices-for-index-optimization} @@ -297,7 +297,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; ORDER BY TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, SEQ_IN_INDEX; ``` - - 2 つのインデックスの先頭列が同じ場合は、代わりにそれらを複合インデックスにマージすることを検討してください。 + - 2つのインデックスの先頭列が同じ場合は、代わりにそれらを複合インデックスにマージすることを検討してください。 - 選択性の向上。選択性の低いインデックス（フィルタリングする行が多すぎるインデックス）は、次のように最適化できます。 diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index a864a884869e2..594468e8b2bf5 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -65,7 +65,7 @@ Grafana の**TiKV ダッシュボード**では、次の監視メトリックを ## パフォーマンスチューニング方法 {#performance-tuning-methods} -パフォーマンスの問題の原因を突き止めたら、次の 2 つの側面から解決を試みてください。 +パフォーマンスの問題の原因を突き止めたら、次の2つの側面から解決を試みてください。 - 単一の TiKV インスタンス上のリージョン数を減らす - 単一リージョンのメッセージ数を減らす @@ -98,7 +98,7 @@ config set max-merge-region-keys 540000 config set merge-schedule-limit 8 ``` -詳細については、 [リージョン結合](https://tikv.org/docs/4.0/tasks/configure/region-merge/)および[PD設定ファイル](/pd-configuration-file.md#schedule)の次の 3 つの構成パラメータを参照してください。 +詳細については、 [リージョン結合](https://tikv.org/docs/4.0/tasks/configure/region-merge/)および[PD設定ファイル](/pd-configuration-file.md#schedule)の次の3つの構成パラメータを参照してください。 - [`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size) - [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 77229547f3558..bdc7b44653459 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -85,7 +85,7 @@ SQLの複数列インデックスは辞書式順序で並べられます。`(cit ## 最適化されたクエリと結果 {#optimized-queries-and-results} -マルチカラムインデックスを使用すると、TiDB はスキャン範囲を効率的に絞り込み、サンフランシスコでベッドルームが 2 つあり、価格が 2,000 ドル未満の物件を検索できます。 +マルチカラムインデックスを使用すると、TiDB はスキャン範囲を効率的に絞り込み、サンフランシスコでベッドルームが 2つあり、価格が 2,000 ドル未満の物件を検索できます。 ```sql -- Query 2: Find two-bedroom listings in San Francisco under $2,000 @@ -133,7 +133,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが ### 例1: 重複する範囲 {#example-1-overlapping-ranges} -ニューヨークで、価格が 2 つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。 +ニューヨークで、価格が 2つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。 - 価格は`$1,000` ～ `$2,000` - 価格は`$1,500` ～ `$2,500` @@ -212,7 +212,7 @@ CREATE TABLE t1 ( (a1, b1) > (1, 10) AND (a1, b1) < (10, 20) ``` -このクエリでは複数の列を比較するため、TiDB オプティマイザーは次の 2 つの手順で処理する必要があります。 +このクエリでは複数の列を比較するため、TiDB オプティマイザーは次の2つの手順で処理する必要があります。 1. 表現を翻訳します。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 3a5fef18ac756..fa36db5553bcb 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -27,11 +27,11 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ### スケジュールプロセス {#scheduling-process} -スケジュール設定プロセスには通常、次の 3 つのステップがあります。 +スケジュール設定プロセスには通常、次の3つのステップがあります。 1. 情報を収集する - 各 TiKV ノードは、次の 2 種類のハートビートを定期的に PD に報告します。 + 各 TiKV ノードは、次の2種類のハートビートを定期的に PD に報告します。 - `StoreHeartbeat` : ディスク容量、使用可能なストレージ、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれます。 - `RegionHeartbeat` : 各リージョンの範囲、ピア分布、ピアステータス、データ量、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます。 @@ -72,7 +72,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ - 十分なストレージがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 - ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 -- どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 +- どちらの状況も当てはまらない場合は、上記の2つの要素の加重合計に基づきます。 ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 @@ -90,7 +90,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ クラスタトポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。 -リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker` `location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`クラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3 つに対してゾーン 2 つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。 +リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker` `location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`クラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。 ### スケールインと障害回復 {#scale-in-and-failure-recovery} @@ -289,7 +289,7 @@ v3.0.4およびv2.1.16以前では、特定の状況（主にテーブルの削 ### TiKVノードのトラブルシューティング {#troubleshoot-tikv-node} -TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30 分後 (構成項目`max-store-down-time`でカスタマイズ可能) に**ダウン**状態に設定し、関係するリージョンのレプリカを再調整します。 +TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30分後 (構成項目`max-store-down-time`でカスタマイズ可能) に**ダウン**状態に設定し、関係するリージョンのレプリカを再調整します。 実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。 diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index 4ea90b6a4f4d1..ee196f3b8ff6f 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -37,8 +37,7 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり - TiDB v8.4.0 以降、TiDB は SQL 実行中に、SQL ステートメントに関連するテーブル情報をオンデマンドで Infoschema キャッシュにロードします。 - TiDB ダッシュボードの**スキーマ ロード**パネルの下にある**Infoschema v2 キャッシュ サイズ**サブパネルと**Infoschema v2 キャッシュ操作**サブパネルを観察することで、Infoschema キャッシュのサイズとヒット率を監視できます。 - - システム変数[`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)を使用すると、ビジネスニーズに合わせて Infoschema キャッシュのメモリ制限を調整できます。Infoschema キャッシュのサイズは、SQL 実行に関係するテーブルの数に比例します。実際のテストでは、100 万テーブル（各テーブルに 4 つの列、1 つの主キー、1 つのインデックス）のメタデータを完全にキャッシュするには、約 2.4 GiB のメモリが必要です。 - + - システム変数[`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)を使用すると、ビジネスニーズに合わせて Infoschema キャッシュのメモリ制限を調整できます。Infoschema キャッシュのサイズは、SQL 実行に関係するテーブルの数に比例します。実際のテストでは、100 万テーブル（各テーブルに 4つの列、1つの主キー、1つのインデックス）のメタデータを完全にキャッシュするには、約 2.4 GiB のメモリが必要です。 - TiDB は、SQL 実行中に、SQL ステートメントに関係するテーブル統計をオンデマンドで統計キャッシュに読み込みます。 - TiDB ダッシュボードの**統計とプラン管理**パネルの**統計キャッシュ コスト**サブパネルと**統計キャッシュ OPS**サブパネルを観察することで、統計キャッシュのサイズとヒット率を監視できます。 @@ -64,7 +63,7 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり SELECT COUNT(*) FROM information_schema.tables; ``` -- 次の SQL ステートメントの実行には約 20 分かかります。 +- 次の SQL ステートメントの実行には約20分かかります。 ```sql SELECT COUNT(*) FROM information_schema.views; diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md index 7ec1053b8c68e..a6d020680079c 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/three-dc-local-read/'] ## 3つのデータセンターのTiDBクラスタをデプロイ {#deploy-a-tidb-cluster-of-three-data-centers} -3 つのデータセンターの展開方法については、 [1 つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。 +3つのデータセンターの展開方法については、 [1つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。 TiKVノードとTiDBノードの両方に構成項目`labels`設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 573976e22a954..9cb0828ccc694 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/three-nodes-hybrid-deployment/'] # 3ノードハイブリッド展開のベストプラクティス {#best-practices-for-three-node-hybrid-deployment} -TiDB クラスターの場合、高パフォーマンスは要求されないもののコストを抑える必要がある場合は、TiDB、TiKV、PD コンポーネントを 3 台のマシンにハイブリッド方式でデプロイできます。 +TiDB クラスターの場合、高パフォーマンスは要求されないもののコストを抑える必要がある場合は、TiDB、TiKV、PD コンポーネントを 3台のマシンにハイブリッド方式でデプロイできます。 このドキュメントでは、3ノードのハイブリッド展開例と、展開されたクラスターに対するTPC-Cテストを紹介します。この例に基づいて、展開シナリオとそのパラメータ調整に関するベストプラクティスを紹介します。 diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 6da8e35ae5584..0db0e8cc007f1 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -1,6 +1,6 @@ --- title: TiDB Best Practices -summary: このドキュメントでは、TiDB の最適な使用方法について、SQL の使用方法や OLAP および OLTP シナリオにおける最適化のヒントを、TiDB 固有の最適化オプションに焦点を当てて解説します。また、最適な使用方法について詳しく見ていく前に、TiDB の技術原理を紹介する 3 つのブログ記事を読むことをお勧めします。 +summary: このドキュメントでは、TiDB の最適な使用方法について、SQL の使用方法や OLAP および OLTP シナリオにおける最適化のヒントを、TiDB 固有の最適化オプションに焦点を当てて解説します。また、最適な使用方法について詳しく見ていく前に、TiDB の技術原理を紹介する 3つのブログ記事を読むことをお勧めします。 aliases: ['/ja/docs/dev/tidb-best-practices/','/ja/tidb/stable/tidb-best-practices/','/ja/tidb/dev/tidb-best-practices/'] --- @@ -30,7 +30,7 @@ TiDBは、MySQLのプロトコルと構文に対応した分散データベー Raftは、強力な一貫性を備えたデータ複製を保証する合意アルゴリズムです。TiDBは、最下層でRaftを使用してデータを複製します。TiDBは、成功の結果を返す前に、レプリカの過半数にデータを書き込みます。このようにして、少数のレプリカが失われた場合でも、システムは最新のデータを保持します。たとえば、レプリカが3つある場合、2つのレプリカにデータが書き込まれるまで、システムは成功の結果を返しません。レプリカが失われた場合でも、残りの2つのレプリカのうち少なくとも1つは最新のデータを保持します。 -3 つのレプリカを保存する場合、ソースレプリカのレプリケーションと比較して、 Raftの方が効率的です。Raft の書き込みレイテンシーは、最も遅いレプリカではなく、最も速い 2 つのレプリカに依存します。そのため、 Raftレプリケーションを使用することで、地理的に分散した複数のアクティブなデータセンターの実装が可能になります。2 つのサイトに 3 つのデータセンターが分散している典型的なシナリオでは、データの一貫性を保証するために、TiDB は 3 つのデータセンターすべてに書き込むのではなく、ローカル データセンターとより近いデータセンターにデータを正しく書き込むだけで済みます。ただし、これは、あらゆるシナリオでクロス データセンター展開を実装できるという意味ではありません。書き込むデータ量が多い場合、データセンター間の帯域幅とレイテンシーが重要な要素になります。書き込み速度が帯域幅を超えたり、レイテンシーが高すぎたりすると、 Raftレプリケーション メカニズムはうまく機能しません。 +3つのレプリカを保存する場合、ソースレプリカのレプリケーションと比較して、 Raftの方が効率的です。Raft の書き込みレイテンシーは、最も遅いレプリカではなく、最も速い 2つのレプリカに依存します。そのため、 Raftレプリケーションを使用することで、地理的に分散した複数のアクティブなデータセンターの実装が可能になります。2つのサイトに 3つのデータセンターが分散している典型的なシナリオでは、データの一貫性を保証するために、TiDB は 3つのデータセンターすべてに書き込むのではなく、ローカル データセンターとより近いデータセンターにデータを正しく書き込むだけで済みます。ただし、これは、あらゆるシナリオでクロス データセンター展開を実装できるという意味ではありません。書き込むデータ量が多い場合、データセンター間の帯域幅とレイテンシーが重要な要素になります。書き込み速度が帯域幅を超えたり、レイテンシーが高すぎたりすると、 Raftレプリケーション メカニズムはうまく機能しません。 ### 分散トランザクション {#distributed-transactions} @@ -75,7 +75,7 @@ TiDB は、SQL 構造を Key-Value 構造に自動的にマッピングします - データの行はキーと値のペアにマッピングされます。キーには`TableID`という接頭辞が付き、行IDが接尾辞として付加されます。 - インデックスはキーと値のペアとしてマッピングされます。キーには`TableID+IndexID`が接頭辞として付き、インデックス値が接尾辞として付きます。 -同じテーブル内のデータまたはインデックスには、同じ接頭辞が付きます。これらのキーと値は、TiKV のキー空間内で隣接する位置にあります。そのため、書き込むデータ量が多く、すべてが 1 つのテーブルに書き込まれる場合、書き込みホットスポットが発生します。連続して書き込まれるデータのインデックス値の一部も連続している場合 (たとえば、 `update time`のように時間とともに増加するフィールド) は、状況が悪化し、書き込みホットスポットがいくつか発生して、システム全体のボトルネックになります。 +同じテーブル内のデータまたはインデックスには、同じ接頭辞が付きます。これらのキーと値は、TiKV のキー空間内で隣接する位置にあります。そのため、書き込むデータ量が多く、すべてが 1つのテーブルに書き込まれる場合、書き込みホットスポットが発生します。連続して書き込まれるデータのインデックス値の一部も連続している場合 (たとえば、 `update time`のように時間とともに増加するフィールド) は、状況が悪化し、書き込みホットスポットがいくつか発生して、システム全体のボトルネックになります。 同様に、すべてのデータが特定の狭い範囲（例えば、連続する数万行または数十万行のデータ）から読み取られる場合、データのアクセス集中が発生する可能性が高くなります。 @@ -193,7 +193,7 @@ TiDB は[Grafana + Prometheus](/tidb-monitoring-framework.md)を使用してシ 監視システムには多くの項目があり、その大部分は TiDB 開発者向けです。ソースコードを深く理解していなくても、これらの項目を理解する必要はありません。アプリケーションやシステムの主要コンポーネントの状態に関連する項目は選択され、ユーザー向けに別の`overview`パネルに表示されます。 -監視に加えて、システムログを表示することもできます。TiDB の 3 つのコンポーネント、tidb-server、tikv-server、および pd-server には、それぞれ`--log-file`パラメータがあります。このパラメータがクラスタの起動時に構成されている場合、ログはパラメータで構成されたファイルに保存され、ログファイルは毎日自動的にアーカイブされます。 `--log-file`パラメータが構成されていない場合、ログは`stderr`に出力されます。 +監視に加えて、システムログを表示することもできます。TiDB の 3つのコンポーネント、tidb-server、tikv-server、および pd-server には、それぞれ`--log-file`パラメータがあります。このパラメータがクラスタの起動時に構成されている場合、ログはパラメータで構成されたファイルに保存され、ログファイルは毎日自動的にアーカイブされます。 `--log-file`パラメータが構成されていない場合、ログは`stderr`に出力されます。 TiDB 4.0 以降、TiDB は使いやすさを向上させるために[TiDB Dashboard](/dashboard/dashboard-intro.md)UI を提供します。 TiDB Dashboardにアクセスするには、ブラウザでにアクセスします。 TiDB Dashboardは、クラスターのステータスの表示、パフォーマンス分析、トラフィックの視覚化、クラスターの診断、ログ検索などの機能を提供します。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index 9d5742b27a7f5..57b17a0ecd6e9 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -237,8 +237,8 @@ TiDBでは、 [TTL (存続時間)](/time-to-live.md)を使用するか、パー このテストでは、TTL と`DROP PARTITION`のパフォーマンスを比較します。 -- TTL 構成: 10 分ごとに実行されます。 -- パーティション構成: 10 分ごとに 1 つのパーティションを削除します。 +- TTL 構成: 10分ごとに実行されます。 +- パーティション構成: 10分ごとに 1つのパーティションを削除します。 - ワークロード: 50 および 100 の同時スレッドによるバックグラウンド書き込みワークロード。 テストでは、実行時間、システム リソースの使用量、および削除された行の合計数を測定します。 @@ -251,8 +251,8 @@ TiDBでは、 [TTL (存続時間)](/time-to-live.md)を使用するか、パー TTL パフォーマンスに関する調査結果は次のとおりです。 -- スレッドが 50 個の場合、各 TTL ジョブには 8 ～ 10 分かかり、700 万～ 1,100 万行が削除されます。 -- 100 スレッドの場合、TTL は最大 2,000 万行を処理できますが、実行時間は 15 ～ 30 分に増加し、変動も大きくなります。 +- スレッドが 50 個の場合、各 TTL ジョブには 8 ～ 10分かかり、700 万～ 1,100 万行が削除されます。 +- 100 スレッドの場合、TTL は最大 2,000 万行を処理できますが、実行時間は 15 ～ 30分に増加し、変動も大きくなります。 - 負荷が高い場合、TTL ジョブは追加のスキャンと削除のオーバーヘッドにより全体的な QPS を低下させます。 `DROP PARTITION`パフォーマンスに関する調査結果は次のとおりです。 @@ -444,7 +444,7 @@ PARTITION BY KEY (id) PARTITIONS 16; **根本的な原因：** -デフォルトでは、TiDB はテーブルを作成すると、各パーティションに対して空のリージョンを作成します。一定期間データが書き込まれない場合、TiDB は複数の空のパーティションのリージョンを 1 つのリージョンにマージすることがあります。 +デフォルトでは、TiDB はテーブルを作成すると、各パーティションに対して空のリージョンを作成します。一定期間データが書き込まれない場合、TiDB は複数の空のパーティションのリージョンを 1つのリージョンにマージすることがあります。 **インパクト：** diff --git a/best-practices/uuid.md b/best-practices/uuid.md index aadbbd5c6be80..570334f27f5e8 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -26,7 +26,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys} -`UUID_TO_BIN()`関数は、 1 つの引数 (UUID)、または 2 つの引数 (2 番目の引数は`swap_flag`とともに使用できます。 +`UUID_TO_BIN()`関数は、 1つの引数 (UUID)、または 2つの引数 (2 番目の引数は`swap_flag`とともに使用できます。 [ホットスポット](/best-practices/high-concurrency-best-practices.md)回避するために、 TiDB で`swap_flag`設定しないことをお勧めします。 @@ -34,7 +34,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. `swap_flag`の効果を示すために、同じ構造を持つ2つのテーブルを示します。違いは、 `uuid_demo_1`に挿入されたデータは`UUID_TO_BIN(?, 0)`を使用し、 `uuid_demo_2` `UUID_TO_BIN(?, 1)`を使用していることです。 -以下の Key Visualizer のスクリーンショットでは、バイナリ形式でフィールドの順序が入れ替わった`uuid_demo_2`テーブルの 1 つのリージョンに書き込みが集中していることがわかります。 +以下の Key Visualizer のスクリーンショットでは、バイナリ形式でフィールドの順序が入れ替わった`uuid_demo_2`テーブルの 1つのリージョンに書き込みが集中していることがわかります。 ![Key Visualizer](/media/best-practices/uuid_keyviz.png) diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index cb8890f74900c..8914ba5593e6d 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -9,13 +9,13 @@ summary: 最適化ルールと式プッシュダウンの動作を制御する ## 最適化ルールのブロックリスト {#the-blocklist-of-optimization-rules} -最適化ルールのブロックリストは、最適化ルールを調整する 1 つの方法であり、主に一部の最適化ルールを手動で無効にするために使用されます。 +最適化ルールのブロックリストは、最適化ルールを調整する 1つの方法であり、主に一部の最適化ルールを手動で無効にするために使用されます。 ### 重要な最適化ルール {#important-optimization-rules} | **最適化ルール** | **ルール名** | **説明** | | :------------------------- | :--------------- | :------------------------------------------------------------------------------------ | -| カラムの剪定 | 列プルーン | 上位の実行プログラムに必要ない場合には、1 つの演算子がその列を削除します。 | +| カラムの剪定 | 列プルーン | 上位の実行プログラムに必要ない場合には、1つの演算子がその列を削除します。 | | 非相関サブクエリ | 相関関係をなくす | 相関サブクエリを非相関結合または集計に書き換えようとします。 | | 集計除去 | 集約を排除する | 実行計画から不要な集計演算子を削除しようとします。 | | 投影の除去 | 投影を排除する | 実行計画から不要な投影演算子を削除します。 | @@ -66,7 +66,7 @@ summary: 最適化ルールと式プッシュダウンの動作を制御する ## 表現プッシュダウンのブロックリスト {#the-blocklist-of-expression-pushdown} -式プッシュダウンのブロックリストは、式プッシュダウンを調整する 1 つの方法であり、主に特定のデータ型の式を手動で無効にするために使用されます。 +式プッシュダウンのブロックリストは、式プッシュダウンを調整する 1つの方法であり、主に特定のデータ型の式を手動で無効にするために使用されます。 ### プッシュダウンがサポートされている式 {#expressions-that-are-supported-to-be-pushed-down} @@ -108,7 +108,7 @@ DESC mysql.expr_pushdown_blacklist; #### ブロックリストに追加 {#add-to-the-blocklist} -ブロックリストに 1 つ以上の式 (関数または演算子) を追加するには、次の手順を実行します。 +ブロックリストに 1つ以上の式 (関数または演算子) を追加するには、次の手順を実行します。 1. 対応する関数名または演算子名と、プッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルに挿入します。 @@ -116,7 +116,7 @@ DESC mysql.expr_pushdown_blacklist; ### ブロックリストから削除 {#remove-from-the-blocklist} -ブロックリストから 1 つ以上の式を削除するには、次の手順を実行します。 +ブロックリストから 1つ以上の式を削除するには、次の手順を実行します。 1. 対応する関数名または演算子名、およびプッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルから削除します。 @@ -185,7 +185,7 @@ DESC mysql.expr_pushdown_blacklist; 3 rows in set (0.00 sec) ``` -4. ブロックリストから 1 つの式 (ここでは`>` ) を削除し、 `admin reload expr_pushdown_blacklist`を実行します。 +4. ブロックリストから 1つの式 (ここでは`>` ) を削除し、 `admin reload expr_pushdown_blacklist`を実行します。 ```sql DELETE FROM mysql.expr_pushdown_blacklist WHERE name = '>'; diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index e6bac22696e97..a521b1426f904 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -156,7 +156,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト - 完全バックアップと復元: [TiKV Configuration File Descriptions](/tikv-configuration-file.md)で`[backup].gcp-v2-enable`を`true`に設定します - ログバックアップ: [TiKV Configuration File Descriptions](/tikv-configuration-file.md)で`[log-backup].gcp-v2-enable`を`true`に設定します -前述の 2 つの設定項目のデフォルト値はどちらも`true`です。 `gcp_v2`を無効にすると、TiKV は引き続き従来の GCS 実装を使用します。この実装は Service Account JSON のみをサポートし、WIF の直接使用はサポートしません。 +前述の2つの設定項目のデフォルト値はどちらも`true`です。 `gcp_v2`を無効にすると、TiKV は引き続き従来の GCS 実装を使用します。この実装は Service Account JSON のみをサポートし、WIF の直接使用はサポートしません。 > **Note:** > @@ -181,7 +181,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト BRが実行されているノードで環境変数`$AZURE_CLIENT_ID` `$AZURE_TENANT_ID`および`$AZURE_CLIENT_SECRET`を設定します。 - - TiUPを使用してクラスターを起動すると、TiKV は systemd サービスを使用します。次の例は、TiKV の上記の 3 つの環境変数を設定する方法を示しています。 + - TiUPを使用してクラスターを起動すると、TiKV は systemd サービスを使用します。次の例は、TiKV の上記の3つの環境変数を設定する方法を示しています。 > **Note:** > @@ -193,7 +193,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト systemctl edit tikv-24000 ``` - 2. TiKV 構成ファイルを編集して、次の 3 つの環境変数を構成します。 + 2. TiKV 構成ファイルを編集して、次の3つの環境変数を構成します。 ``` [Service] diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index 221d695913110..afacc60974858 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -82,8 +82,8 @@ TiUPを使用してBRをインストールまたはアップグレードしま 最小限のデータ損失、迅速な回復、および 1 か月以内のビジネス監査の要件を満たすには、次のようにバックアップ ポリシーを設定できます。 - ログ バックアップを実行して、データベース内のデータの変更を継続的にバックアップします。 -- 2 日ごとに午前 0 時にスナップショット バックアップを実行します。 -- スナップショット バックアップ データとログ バックアップ データを 30 日以内に保持し、30 日以上経過したバックアップ データをクリーンアップします。 +- 2日ごとに午前 0 時にスナップショット バックアップを実行します。 +- スナップショット バックアップ データとログ バックアップ データを 30日以内に保持し、30日以上経過したバックアップ データをクリーンアップします。 ## ログバックアップを実行する {#run-log-backup} @@ -114,7 +114,7 @@ checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s crontabなどの自動ツールを使えば、スナップショットバックアップタスクを定期的に実行できます。例えば、2日ごとに00:00にスナップショットバックアップを実行するなどです。 -以下に 2 つのスナップショット バックアップの例を示します。 +以下に 2つのスナップショット バックアップの例を示します。 - 2022/05/14 00:00:00にスナップショットバックアップを実行します @@ -155,7 +155,7 @@ Restore KV Files <-------------------------------------------------------------- ## 古いデータをクリーンアップする {#clean-up-outdated-data} -crontab などの自動ツールを使用して、2 日ごとに古いデータをクリーンアップできます。 +crontab などの自動ツールを使用して、2日ごとに古いデータをクリーンアップできます。 たとえば、次のコマンドを実行して古いデータをクリーンアップできます。 diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index bbc961aa976a1..5e493ddb05528 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -51,8 +51,8 @@ tiup br restore full \ - クラスタ構成: - 15 個の TiKV インスタンス。各 TiKV インスタンスには、16 個の CPU コア、80 GB のメモリ、および RPC リクエストを処理するための 16 個のスレッド ( [`import.num-threads`](/tikv-configuration-file.md#num-threads) = 16) が搭載されています。 - - 3 つの TiDB インスタンス。各 TiDB インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 - - 3 つの PD インスタンス。各 PD インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 + - 3つの TiDB インスタンス。各 TiDB インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 + - 3つの PD インスタンス。各 PD インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 - 復元するデータのサイズ: 16.16 TB @@ -62,4 +62,4 @@ tiup br restore full \ '[2022/03/12 22:37:49.060 +08:00] [INFO] [collector.go:67] ["Full restore success summary"] [total-ranges=751760] [ranges-succeed=751760] [ranges-failed=0] [split-region=1h33m18.078448449s] [restore-ranges=542693] [total-take=1h41m35.471476438s] [restore-data-size(after-compressed)=8.337TB] [Size=8336694965072] [BackupTS=431773933856882690] [total-kv=148015861383] [total-kv-size=16.16TB] [average-speed=2.661GB/s]' ``` -テスト結果から、1 つの TiKV インスタンスを復元する平均速度は 181.65 MB/秒 ( `average-speed`に相当) であること`tikv_count`わかります。 +テスト結果から、1つの TiKV インスタンスを復元する平均速度は 181.65 MB/秒 ( `average-speed`に相当) であること`tikv_count`わかります。 diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index fe077bdb57d59..775c79fc0287d 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -31,7 +31,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを このような状況を回避するため、 `gcttl`が指定されていない場合、 `br`はデフォルトで`gc-safepoint`を約1時間保持します。必要に応じて、 `gcttl`パラメータを設定することで保持期間を延長できます。 -次の例では、 `gcttl` 15 時間 (54000 秒) に設定して、保持期間`gc-safepoint`を延長します。 +次の例では、 `gcttl` 15時間 (54000秒) に設定して、保持期間`gc-safepoint`を延長します。 ```shell tiup br backup full \ diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 8bc968a215772..562d9bda93f29 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -71,7 +71,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた > > v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータのストレージを指定できます。 -チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。 +チェックポイント復元操作は、スナップショット復元と PITR 復元の 2つの部分に分かれています。 ### スナップショットの復元 {#snapshot-restore} @@ -139,7 +139,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた `-- checkpoint.meta ``` -チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。 +チェックポイント復元操作は、スナップショット復元と PITR 復元の 2つの部分に分かれています。 ### スナップショットの復元 {#snapshot-restore} diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md index 43d01c162ac08..f23efd9369434 100644 --- a/br/br-compact-log-backup.md +++ b/br/br-compact-log-backup.md @@ -11,7 +11,7 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ 従来のログ バックアップでは、書き込み操作が極めて非構造化された方法で保存されるため、次のような問題が発生する可能性があります。 -- **回復パフォーマンスの低下**: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1 つずつ書き込む必要があります。 +- **回復パフォーマンスの低下**: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1つずつ書き込む必要があります。 - **書き込み増幅**: すべての書き込みは、L0 から最下レベルまでレベルごとに圧縮する必要があります。 - **完全バックアップへの依存**: リカバリ データの量を制御するには、頻繁な完全バックアップが必要であり、アプリケーションの操作に影響を及ぼす可能性があります。 @@ -36,7 +36,7 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ #### 前提条件 {#prerequisites} -ログ バックアップを手動で圧縮するには、 `tikv-ctl`と`br` 2 つのツールが必要です。 +ログ バックアップを手動で圧縮するには、 `tikv-ctl`と`br` 2つのツールが必要です。 #### ステップ1:ストレージをBase64でエンコードする {#step-1-encode-storage-to-base64} diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 1daf9df1e0520..62634742f403f 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -93,7 +93,7 @@ groups: - 警戒レベル: 重大 - 説明: ログデータが30分以上ストレージに保存されていません。このアラートは多くの場合、異常を示しています。原因を特定するには、TiKVログを確認してください。 -#### ログバックアップ一時停止中 (2 時間以上) {#logbackuppausingmorethan2h} +#### ログバックアップ一時停止中 (2時間以上) {#logbackuppausingmorethan2h} - 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` - 警戒レベル：警告 diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 62d1f4371ed4f..d07355b9fe9a1 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -18,7 +18,7 @@ br コマンドライン ツール (以下、 `br`と呼びます) を使用し > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 > - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 -ログ バックアップを開始するには、 `tiup br log start`を実行します。クラスターは 1 回につき 1 つのログ バックアップ タスクのみ実行できます。 +ログ バックアップを開始するには、 `tiup br log start`を実行します。クラスターは 1回につき 1つのログ バックアップ タスクのみ実行できます。 ```shell tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \ @@ -149,7 +149,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ > - `pitr-batch-size` :**バッチあたりの累積バイト数**(デフォルト**16 MiB** )。 > - `pitr-batch-count` :**バッチあたりのファイル数**(デフォルトは**8** )。 > -> 次のバッチを開始するかどうかを決定するときに、これら 2 つのしきい値は独立して評価されます。最初にいずれかのしきい値に達した場合、現在のバッチが閉じられ、次のバッチが開始されますが、もう一方のしきい値はそのバッチでは無視されます。 +> 次のバッチを開始するかどうかを決定するときに、これら2つのしきい値は独立して評価されます。最初にいずれかのしきい値に達した場合、現在のバッチが閉じられ、次のバッチが開始されますが、もう一方のしきい値はそのバッチでは無視されます。 テストシナリオ 1 ( [TiDB Cloud](https://tidbcloud.com)上) は次のとおりです。 diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 7368d0f159fe0..9d873f82ed6ad 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -205,7 +205,7 @@ checkpoint[global]: 2022-07-25 22:52:15.518 +0800; gap=2m52s - `status` : バックアップ タスクのステータス。 `NORMAL` 、 `ERROR` 、または`PAUSE`になります。 - `start` : バックアップタスクの開始時刻。バックアップタスクの開始時に指定された`start-ts`です。 - `storage` : バックアップストレージアドレス。 -- `speed` : バックアップタスクの合計 QPS。QPS は 1 秒あたりにバックアップされるログの数を意味します。 +- `speed` : バックアップタスクの合計 QPS。QPS は 1秒あたりにバックアップされるログの数を意味します。 - `checkpoint [global]` : このチェックポイントより前のすべてのデータがバックアップストレージにバックアップされています。これは、バックアップデータの復元に使用できる最新のタイムスタンプです。 - `error [store]` : ログ バックアップ プログラムがストレージノード上で検出したエラー。 @@ -547,7 +547,7 @@ tiup br restore point --pd="${PD_IP}:2379" \ > - フィルター オプションは、スナップショット バックアップとログ バックアップの両方の復元フェーズ中に適用されます。 > - 複数の`--filter`オプションを指定して、異なるパターンを含めたり除外したりできます。 > - PITRフィルタリングはシステムテーブルをまだサポートしていません。特定のシステムテーブルを復元する必要がある場合は、代わりにフィルターを指定した`br restore full`コマンドを使用してください。このコマンドはスナップショットバックアップデータのみを復元し、ログバックアップデータは復元しないことに注意してください。 -> - 復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の 3 つのケースが考えられます。 +> - 復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の3つのケースが考えられます。 > - テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。 > - テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`時点では一致しました。この場合、PITRはテーブルを復元します。 > - テーブルC（テーブルID = 3）：テーブル名は、 `restored-ts`より前の時点では正規表現`--filter`と一致していましたが、 `restored-ts`時点では一致**していません**。この場合、PITRはテーブルを復元しませ**ん**。 diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 77dc2dd9010e8..20ef2a868cdb7 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -224,7 +224,7 @@ tiup br restore full \ > **Note:** > -> `--ratelimit`を有効にすると、バックアップのスループットがさらに低下します。ほとんどの場合、既にオフピーク時間帯にバックアップを実行していて、 `backup.num-threads`を 1 に下げても、フォアグラウンドワークロードへのバックアップの影響が見られる場合は、クラスターがリソース制限に近づいていることを示しています。 +> `--ratelimit`を有効にすると、バックアップのスループットがさらに低下します。ほとんどの場合、既にオフピーク時間帯にバックアップを実行していて、 `backup.num-threads`を1に下げても、フォアグラウンドワークロードへのバックアップの影響が見られる場合は、クラスターがリソース制限に近づいていることを示しています。 > > このような状況では、以下の選択肢を検討できます。 > diff --git a/br/br-use-overview.md b/br/br-use-overview.md index 5f476dc80f687..1b2daea61a93d 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -27,7 +27,7 @@ BRは基本的なバックアップと復元機能のみを提供し、バック - フルバックアップデータとログバックアップデータのディレクトリはどのように整理すればよいですか? - ストレージシステム内の履歴バックアップ データをどのように処理しますか? -次のセクションでは、これらの質問に 1 つずつ答えていきます。 +次のセクションでは、これらの質問に 1つずつ答えていきます。 **バックアップストレージシステムを選択する** diff --git a/cached-tables.md b/cached-tables.md index 67651fd4a7515..3cbbf1059357b 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -14,7 +14,7 @@ TiDB v6.0.0では、頻繁にアクセスされるものの更新頻度の低い キャッシュされたテーブル機能は、次の特性を持つテーブルに適しています。 - テーブルのデータ量は小さく、たとえば 4 MiB 未満です。 -- テーブルは読み取り専用であるか、ほとんど更新されません (たとえば、書き込み QPS (1 秒あたりのクエリ数) が 1 分あたり 10 回未満)。 +- テーブルは読み取り専用であるか、ほとんど更新されません (たとえば、書き込み QPS (1秒あたりのクエリ数) が 1分あたり 10回未満)。 - テーブルは頻繁にアクセスされ、たとえば TiKV からの直接読み取り中に小さなテーブルでホットスポットが発生する場合など、読み取りパフォーマンスの向上が期待されます。 テーブルのデータ量が少ないにもかかわらず、データへのアクセス頻度が高い場合、TiKVではデータが特定のリージョンに集中し、ホットスポットリージョンと呼ばれるリージョンがパフォーマンスに影響を与えます。そのため、キャッシュテーブルの典型的な使用シナリオは以下のようになります。 diff --git a/certificate-authentication.md b/certificate-authentication.md index 9254a88d0bb4e..d55ba72925294 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -287,7 +287,7 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k ユーザー証明書情報（ `REQUIRE SUBJECT` `REQUIRE CIPHER`を取得したら、ユーザーの作成、権限の付与、またはユーザーの変更時にこれらの情報`REQUIRE SAN`検証されるように設定します。以下の文の`` `REQUIRE ISSUER`する情報に置き換えてください。 -スペースまたは`and`区切り文字として使用して、1 つのオプションまたは複数のオプションを設定できます。 +スペースまたは`and`区切り文字として使用して、1つのオプションまたは複数のオプションを設定できます。 - ユーザー作成時にユーザー証明書を設定します（ `CREATE USER` ）： diff --git a/character-set-and-collation.md b/character-set-and-collation.md index adad2ac41df21..1244a4b285a7a 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -319,7 +319,7 @@ SELECT @@character_set_database, @@collation_database; 1 row in set (0.00 sec) ``` -`INFORMATION_SCHEMA`には次の 2 つの値も表示されます。 +`INFORMATION_SCHEMA`には次の2つの値も表示されます。 ```sql SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME @@ -579,7 +579,7 @@ ERROR 1062 (23000): Duplicate entry 'a ' for key 't.PRIMARY' -- TiDB modifies th 式に異なる照合順序を持つ複数の節が含まれる場合、計算で使用される照合順序を推測する必要があります。そのルールは以下のとおりです。 - 明示的な`COLLATE`句の強制可能性値は`0`です。 -- 2 つの文字列の照合順序に互換性がない場合は、異なる照合順序を持つ 2 つの文字列の連結の強制可能性値は`1`なります。 +- 2つの文字列の照合順序に互換性がない場合は、異なる照合順序を持つ 2つの文字列の連結の強制可能性値は`1`なります。 - 列の照合順序`CAST()` 、 `CONVERT()` 、または`BINARY()`の強制値は`2`です。 - システム定数 ( `USER ()`または`VERSION ()`によって返される文字列) の強制値は`3`です。 - 定数の強制値は`4`です。 @@ -592,8 +592,8 @@ TiDBは照合順序を推論する際に、強制性値の低い式の照合順 次の状況では、TiDB は照合順序を推測できず、エラーを報告します。 -- 2 つの句の照合順序が異なり、両方の句の強制可能性値が`0`の場合。 -- 2 つの句の照合順序に互換性がなく、返される式の型が`String`の場合。 +- 2つの句の照合順序が異なり、両方の句の強制可能性値が`0`の場合。 +- 2つの句の照合順序に互換性がなく、返される式の型が`String`の場合。 ## `COLLATE`句 {#collate-clause} diff --git a/check-before-deployment.md b/check-before-deployment.md index c5b46cb4c860a..aa4192d31945b 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -780,7 +780,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t > - NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスを展開するのに適しています。 > - `tiup cluster deploy`を使用してデプロイメントを完了したら、 `exec`コマンドを使用してクラスター レベルの管理操作を実行できます。 -NUMA ツールをインストールするには、次の 2 つの方法のいずれかを実行します。 +NUMA ツールをインストールするには、次の2つの方法のいずれかを実行します。 **方法1** ：NUMAをインストールするには、ターゲットノードにログインします。CentOS Linuxリリース7.7.1908（Core）を例に挙げます。 diff --git a/choose-index.md b/choose-index.md index 08760827620e8..45c6c317978da 100644 --- a/choose-index.md +++ b/choose-index.md @@ -83,7 +83,7 @@ mysql> SHOW WARNINGS; - インデックスが[グローバルインデックス](/global-indexes.md)かどうか。パーティション テーブルでは、グローバル インデックスにより、通常のインデックスと比較して SQL の cop タスクの数が効果的に削減され、全体的なパフォーマンスが向上します。 -上記次元において、インデックス`idx_a`が 3 つの次元すべてにおいてインデックス`idx_b`と同等以上のパフォーマンスを発揮し、かつ 1 つの次元において`idx_b`よりも優れたパフォーマンスを発揮する場合、 `idx_a`が優先されます。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、スカイラインプルーニングによって一部のインデックスが除外された場合、TiDB は、スカイラインプルーニングによる除外後に残ったインデックスを一覧表示する NOTE レベルの警告を出力します。 +上記次元において、インデックス`idx_a`が 3つの次元すべてにおいてインデックス`idx_b`と同等以上のパフォーマンスを発揮し、かつ 1つの次元において`idx_b`よりも優れたパフォーマンスを発揮する場合、 `idx_a`が優先されます。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、スカイラインプルーニングによって一部のインデックスが除外された場合、TiDB は、スカイラインプルーニングによる除外後に残ったインデックスを一覧表示する NOTE レベルの警告を出力します。 次の例では、インデックス`idx_b`と`idx_e`はどちらも`idx_b_c`より劣るため、スカイライン剪定によって除外されます。 `SHOW WARNING`の戻り値には、スカイライン剪定後に残ったインデックスが表示されます。 @@ -455,7 +455,7 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +-------------------------------+---------+-----------+-----------------------------------------------------------------------------+---------------------------------------------+ ``` - - 複数の値を含む`json_contains`条件が`OR`に接続されている場合、または複数の値を含む`json_overlaps`条件が`AND`に接続されている場合、それらは意味論に一致しませんが、値が 1 つだけの場合は意味論に一致します。例: + - 複数の値を含む`json_contains`条件が`OR`に接続されている場合、または複数の値を含む`json_overlaps`条件が`AND`に接続されている場合、それらは意味論に一致しませんが、値が 1つだけの場合は意味論に一致します。例: ```sql -- Refer to the preceding examples for conditions that do not match the semantics. The following only provides examples of conditions that match the semantics. diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index 9adec6a2d457b..62b1ed03895bf 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -9,7 +9,7 @@ summary: PingCAP Clinic診断サービスは、 TiUPを使用してTiDBおよび PingCAP Clinicによって収集された診断データは、クラスターの問題のトラブルシューティングに**のみ**使用されます。 -クラウドに展開される診断サービスである Clinic Server は、データのストレージの場所に応じて 2 つの独立したサービスを提供します。 +クラウドに展開される診断サービスである Clinic Server は、データのストレージの場所に応じて 2つの独立したサービスを提供します。 - [国際ユーザー向けClinic Server](https://clinic.pingcap.com) ：収集したデータを国際ユーザー向けのClinic Serverにアップロードすると、データはPingCAPがAWS米国リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 - [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) ：収集したデータを中国本土のユーザー向けClinic Serverにアップロードすると、データはPingCAPが中国（北京）リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index 23ef15c448ae0..fcd6e00aeb2a2 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -7,7 +7,7 @@ summary: PingCAP Clinicは、 TiUPまたはTiDB Operatorを使用して導入さ PingCAP Clinic診断サービス（PingCAP Clinic）は、 TiUPまたはTiDB Operatorを使用して導入されたTiDBクラスタ向けにPingCAPが提供する診断サービスです。このサービスは、クラスタの問題をリモートでトラブルシューティングし、ローカルでクラスタの状態を迅速に確認するのに役立ちます。PingCAP Clinicを利用することで、TiDBクラスタのライフサイクル全体にわたる安定した運用を確保し、潜在的な問題を予測し、問題発生の可能性を低減し、クラスタの問題を迅速にトラブルシューティングして修復することができます。 -PingCAP Clinic は、クラスターの問題を診断するために次の 2 つのコンポーネントを提供します。 +PingCAP Clinic は、クラスターの問題を診断するために次の2つのコンポーネントを提供します。 - [Diagクライアント](https://github.com/pingcap/diag) : diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index c8b4c16044465..852269fe9c26c 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -1,6 +1,6 @@ --- title: Troubleshoot Clusters Using PingCAP Clinic -summary: PingCAP Clinic診断サービス (PingCAP Clinic) は、 TiUPを使用して導入された TiDB および DM クラスターのトラブルシューティングに役立ちます。Diag クライアントと Clinic Server を使用して、リモート トラブルシューティングとローカル クラスターの状態確認が可能です。前提条件として、Diag のインストール、アクセス トークンの設定、リージョンの構成が必要です。リモートでのトラブルシューティングには、診断データの収集、表示、アップロードが含まれます。ローカルでのクラスター状態のクイック チェックには、構成データの収集と診断が含まれます。データのアップロードはブレークポイント アップロードをサポートしており、アップロードされたデータは Clinic Server に最大 180 日間保存されます。 +summary: PingCAP Clinic診断サービス (PingCAP Clinic) は、 TiUPを使用して導入された TiDB および DM クラスターのトラブルシューティングに役立ちます。Diag クライアントと Clinic Server を使用して、リモート トラブルシューティングとローカル クラスターの状態確認が可能です。前提条件として、Diag のインストール、アクセス トークンの設定、リージョンの構成が必要です。リモートでのトラブルシューティングには、診断データの収集、表示、アップロードが含まれます。ローカルでのクラスター状態のクイック チェックには、構成データの収集と診断が含まれます。データのアップロードはブレークポイント アップロードをサポートしており、アップロードされたデータは Clinic Server に最大 180日間保存されます。 --- # PingCAP Clinicを使用したクラスターのトラブルシューティング {#troubleshoot-clusters-using-pingcap-clinic} @@ -136,7 +136,7 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ 1. Diag のデータ収集コマンドを実行します。 - たとえば、現在の時刻に基づいて 4 時間前から 2 時間前までの診断データを収集するには、次のコマンドを実行します。 + たとえば、現在の時刻に基づいて 4時間前から 2時間前までの診断データを収集するには、次のコマンドを実行します。
diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index 8006415bbe41c..ebc1ad96197ed 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -105,7 +105,7 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ 1. Diag を実行して診断データを収集します。 - たとえば、現在の時刻に基づいて 4 時間前から 2 時間前までの診断データを収集するには、次のコマンドを実行します。 + たとえば、現在の時刻に基づいて 4時間前から 2時間前までの診断データを収集するには、次のコマンドを実行します。 ```bash tiup diag collect ${cluster-name} -f="-4h" -t="-2h" diff --git a/clustered-indexes.md b/clustered-indexes.md index a42ea41c0ba64..37106cc799aca 100644 --- a/clustered-indexes.md +++ b/clustered-indexes.md @@ -11,7 +11,7 @@ TiDBはバージョン5.0以降、クラスター化インデックス機能を 現在、TiDBの主キーを含むテーブルは、以下の2つのカテゴリに分類されます。 -- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 +- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2つのキーと値のペアが必要です。それらは次のとおりです。 - `_tidb_rowid` （キー） - 行データ（値） - 主キーデータ（キー） - `_tidb_rowid` （値） - `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 @@ -164,7 +164,7 @@ TiDBは、クラスター化インデックスを持つテーブルのアップ クラスター化インデックス機能は、TiDB v3.0およびv4.0で部分的にサポートされています。以下の要件がすべて満たされている場合、デフォルトで有効になります。 - テーブルには`PRIMARY KEY`が含まれています。 -- `PRIMARY KEY`は 1 つの列のみで構成されています。 +- `PRIMARY KEY`は 1つの列のみで構成されています。 - `PRIMARY KEY`は`INTEGER`です。 TiDB v5.0 以降、クラスター化インデックス機能はすべてのタイプの主キーに対して完全にサポートされていますが、デフォルトの動作は TiDB v3.0 および v4.0 と一貫しています。デフォルトの動作を変更するには、システム変数`@@tidb_enable_clustered_index`を`ON`または`OFF`に設定します。詳細については、[クラスター化インデックスを持つテーブルを作成する](#create-a-table-with-clustered-indexes)を参照してください。 diff --git a/command-line-flags-for-pd-configuration.md b/command-line-flags-for-pd-configuration.md index ae82e145085ed..ad2ef2d91e646 100644 --- a/command-line-flags-for-pd-configuration.md +++ b/command-line-flags-for-pd-configuration.md @@ -49,7 +49,7 @@ PD は、コマンドラインフラグと環境変数を使用して構成で - ブートストラップのための初期クラスタ構成 - デフォルト: `"{name}=http://{advertise-peer-url}"` - たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 -- 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 +- 3つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 ``` pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index ee8e300b383f3..a7cc1c3e8aae6 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -96,7 +96,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - Prometheusクライアントのプッシュ間隔（秒） - デフォルト: `15s` -- 値を 0 に設定すると、Prometheus クライアントのプッシュが停止します。 +- 値を0に設定すると、Prometheus クライアントのプッシュが停止します。 ## `-P` {#-p} diff --git a/comment-syntax.md b/comment-syntax.md index 9fe8c1d627832..c6f423ab4533a 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -7,7 +7,7 @@ summary: このドキュメントでは、TiDB でサポートされているコ このドキュメントでは、TiDB でサポートされているコメント構文について説明します。 -TiDB は次の 3 つのコメント スタイルをサポートしています。 +TiDB は次の3つのコメント スタイルをサポートしています。 - 行をコメント化するには`#`を使用します。 @@ -39,7 +39,7 @@ TiDB は次の 3 つのコメント スタイルをサポートしています 1 row in set (0.00 sec) ``` - このスタイルでは、 `--`の後に少なくとも 1 つの空白が必要です。 + このスタイルでは、 `--`の後に少なくとも 1つの空白が必要です。 ```sql SELECT 1+1--1; @@ -120,7 +120,7 @@ MySQLでは、コメントにサーバーのバージョン番号（例： `/*!5 ## TiDB固有のコメント構文 {#tidb-specific-comment-syntax} -TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント構文) があり、次の 2 種類に分けられます。 +TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント構文) があり、次の2種類に分けられます。 - `/*T! Specific code */` : この構文は TiDB によってのみ解析および実行され、他のデータベースでは無視されます。 - `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。`AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。**`/*T![`文字内にスペースを入れないでください**。 diff --git a/configure-load-base-split.md b/configure-load-base-split.md index eee47692d3bbb..e009e998b06a6 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -15,7 +15,7 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ このシナリオは、完全なテーブルスキャンや小さなテーブルのインデックス検索、一部のフィールドへの頻繁なアクセスなど、主に読み取り要求であるワークロードで特に一般的です。 -以前は、この問題の解決策として、1 つ以上のホットスポットリージョンを分割するコマンドを手動で実行していましたが、この方法には 2 つの問題がありました。 +以前は、この問題の解決策として、1つ以上のホットスポットリージョンを分割するコマンドを手動で実行していましたが、この方法には 2つの問題がありました。 - リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。 - 人間の介入はタイムリーでも簡単でもない。 @@ -34,7 +34,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ - [`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 時間の割合)。`region-split-size`が4GB未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 -リージョンが10 秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 +リージョンが10秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 - 読み取り要求の合計が`split.qps-threshold`超えます。 - トラフィックが`split.byte-threshold`超えています。 @@ -42,7 +42,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ ロードベーススプリットはデフォルトで有効になっていますが、パラメータがかなり高い値に設定されています。この機能を無効にするには、 `split.qps-threshold`と`split.byte-threshold`十分に高い値に設定し、同時に`split.region-cpu-overload-threshold-ratio`を`0`に設定してください。 -パラメータを変更するには、次の 2 つの方法のいずれかを実行します。 +パラメータを変更するには、次の2つの方法のいずれかを実行します。 - SQL ステートメントを使用します。 @@ -63,7 +63,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ curl -X POST "http://ip:status_port/config" -H "accept: application/json" -d '{"split.region-cpu-overload-threshold-ratio":"0.5"}' ``` -したがって、次の 2 つの方法のいずれかで構成を表示できます。 +したがって、次の2つの方法のいずれかで構成を表示できます。 - SQL ステートメントを使用します。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 053775a6cadcf..c64b477a2783e 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -52,7 +52,7 @@ SET GLOBAL tidb_server_memory_limit = "32GB"; > - メモリ制御の過程で、TiDB の合計メモリ使用量が`tidb_server_memory_limit`で設定された制限をわずかに超える場合があります。 > - バージョン6.5.0以降、設定項目`server-memory-quota`は非推奨となりました。互換性を確保するため、クラスターをバージョン6.5.0以降にアップグレードすると、 `tidb_server_memory_limit`は`server-memory-quota`の値を継承します。アップグレード前に`server-memory-quota`を設定していない場合は、`tidb_server_memory_limit`のデフォルト値（`80%`）が使用されます。 -tidb-server インスタンスのメモリ使用量が総メモリの一定割合（割合はシステム変数[`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)によって制御されます）に達すると、tidb-server はメモリ負荷を軽減するためにGolang GC をトリガーしようとします。インスタンスメモリがしきい値付近で変動することで頻繁な GC が発生し、パフォーマンスに問題が生じるのを防ぐため、この GC 方式では GC は最大で 1 分に 1 回しかトリガーされません。 +tidb-server インスタンスのメモリ使用量が総メモリの一定割合（割合はシステム変数[`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)によって制御されます）に達すると、tidb-server はメモリ負荷を軽減するためにGolang GC をトリガーしようとします。インスタンスメモリがしきい値付近で変動することで頻繁な GC が発生し、パフォーマンスに問題が生じるのを防ぐため、この GC 方式では GC は最大で 1分に 1回しかトリガーされません。 > **Note:** > @@ -69,7 +69,7 @@ tidb-server インスタンスのメモリ使用量が総メモリの一定割 tidb-server インスタンスのメモリ使用量がメモリしきい値 (デフォルトでは合計メモリの 70%) を超え、次のいずれかの条件が満たされると、TiDB は関連するステータス ファイルを記録し、アラーム ログを出力。 - メモリ使用量がメモリしきい値を超えるのは初めてです。 -- メモリ使用量がメモリしきい値を超えており、前回のアラームから 60 秒以上経過しています。 +- メモリ使用量がメモリしきい値を超えており、前回のアラームから 60秒以上経過しています。 - メモリ使用量がメモリしきい値を超え、 `(Current memory usage - Memory usage at the last alarm) / Total memory > 10%` 。 システム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)を使用してメモリ使用率を変更することで、アラームをトリガーするメモリしきい値を制御できます。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index a3b1fdc374166..6572ec1942e71 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -48,7 +48,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで - `exists` : 指定されたラベル キーが含まれます。 - `notExists` : 指定されたラベル キーは含まれません。 -`LocationLabels`の意味と機能は、v4.0 以前のバージョンと同じです。例えば、 `[zone,rack,host]`をデプロイし、3 層トポロジを定義しているとします。クラスターには複数のゾーン（アベイラビリティゾーン）があり、各ゾーンには複数のラックがあり、各ラックには複数のホストがあります。スケジュールを実行する際、PD はまずリージョンのピアを異なるゾーンに配置しようとします。この試行が失敗した場合（レプリカは 3 つあるがゾーンは合計 2 つしかない場合など）、PD はこれらのレプリカを異なるラックに配置することを保証します。ラック数が分離を保証するのに十分でない場合、PD はホストレベルの分離を試みます。 +`LocationLabels`の意味と機能は、v4.0 以前のバージョンと同じです。例えば、 `[zone,rack,host]`をデプロイし、3 層トポロジを定義しているとします。クラスターには複数のゾーン（アベイラビリティゾーン）があり、各ゾーンには複数のラックがあり、各ラックには複数のホストがあります。スケジュールを実行する際、PD はまずリージョンのピアを異なるゾーンに配置しようとします。この試行が失敗した場合（レプリカは 3つあるがゾーンは合計2つしかない場合など）、PD はこれらのレプリカを異なるラックに配置することを保証します。ラック数が分離を保証するのに十分でない場合、PD はホストレベルの分離を試みます。 `IsolationLevel`の意味と機能については[クラスタトポロジ構成](/schedule-replicas-by-topology-labels.md)で詳しく説明します。例えば、 `LocationLabels`を含む3層トポロジを定義する`[zone,rack,host]`をデプロイし、 `IsolationLevel`を`zone`に設定した場合、PDはスケジューリング中に各リージョンのすべてのピアが異なるゾーンに配置されるように保証します。 `IsolationLevel`の最小分離レベル制限を満たすことができない場合（例えば、レプリカが3つ設定されているが、データゾーンが合計で2つしかない場合）、PDはこの制限を満たすために調整を試みません。デフォルト値`IsolationLevel`は空の文字列であり、無効であることを意味します。 @@ -101,7 +101,7 @@ PD は、 `max-replicas` 、 `location-labels` 、および`isolation-level`構 > **Note:** > > - 配置ルールが有効で複数のルールが存在する場合、以前に設定されたルール`max-replicas` 、 `location-labels` 、および`isolation-level`は適用されなくなります。レプリカポリシーを調整するには、配置ルールに関連するインターフェースを使用してください。 -> - 配置ルールが有効になっていて、デフォルト ルールが 1 つだけ存在する場合、 `max-replicas` 、 `location-labels` 、または`isolation-level`が変更されると、TiDB はこのデフォルト ルールを自動的に更新します。 +> - 配置ルールが有効になっていて、デフォルト ルールが 1つだけ存在する場合、 `max-replicas` 、 `location-labels` 、または`isolation-level`が変更されると、TiDB はこのデフォルト ルールを自動的に更新します。 ### 配置ルールを無効にする {#disable-placement-rules} @@ -306,7 +306,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) このセクションでは、配置ルールの一般的な使用シナリオを紹介します。 -### シナリオ 1: 通常のテーブルに 3 つのレプリカを使用し、メタデータに 5 つのレプリカを使用してクラスタの耐障害性を向上させる {#scenario-1-use-three-replicas-for-normal-tables-and-five-replicas-for-the-metadata-to-improve-cluster-disaster-tolerance} +### シナリオ 1: 通常のテーブルに 3つのレプリカを使用し、メタデータに 5つのレプリカを使用してクラスタの耐障害性を向上させる {#scenario-1-use-three-replicas-for-normal-tables-and-five-replicas-for-the-metadata-to-improve-cluster-disaster-tolerance} キーの範囲をメタデータの範囲に制限するルールを追加し、`count`の値を`5`に設定するだけです。このルールの例を以下に示します。 diff --git a/constraints.md b/constraints.md index 32b2285a76128..eb7f81b0af9da 100644 --- a/constraints.md +++ b/constraints.md @@ -262,7 +262,7 @@ ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' SELECT * FROM users FOR UPDATE; ``` - 次の出力例のように、TiDB のクエリ結果には`bills`が 2 つ含まれており、一意性制約を満たしていません。 + 次の出力例のように、TiDB のクエリ結果には`bills`が 2つ含まれており、一意性制約を満たしていません。 ```sql +----+----------+ @@ -382,8 +382,8 @@ Query OK, 0 rows affected (0.10 sec) ``` - 列`a`が主キーとして定義されており、NULL 値が許可されないため、テーブル`t2`を作成できませんでした。 -- テーブルには主キーを 1 つしか持てないため、テーブル`t3`を作成できませんでした。 -- 主キーは 1 つしか存在できませんが、TiDB では複数の列を複合主キーとして定義することがサポートされているため、テーブル`t4`が正常に作成されました。 +- テーブルには主キーを 1つしか持てないため、テーブル`t3`を作成できませんでした。 +- 主キーは 1つしか存在できませんが、TiDB では複数の列を複合主キーとして定義することがサポートされているため、テーブル`t4`が正常に作成されました。 上記のルールに加えて、TiDBは現在、 `NONCLUSTERED`型の主キーの追加と削除のみをサポートしています。例えば： diff --git a/cost-model.md b/cost-model.md index cd357b8e459ec..5dea39a5d93f8 100644 --- a/cost-model.md +++ b/cost-model.md @@ -29,7 +29,7 @@ mysql> SHOW CREATE TABLE t; 1 row in set (0.00 sec) ``` -`SELECT * FROM t WHERE b < 100 and c < 100`文を実行するときに、TiDB が`b < 100`条件を満たす行が 20 行、 `c < 100`行が 500 行で、 `INT`種類のインデックスの長さが 8 であると見積もったとします。この場合、TiDB は 2 つのインデックスのコストを計算します。 +`SELECT * FROM t WHERE b < 100 and c < 100`文を実行するときに、TiDB が`b < 100`条件を満たす行が 20 行、 `c < 100`行が 500 行で、 `INT`種類のインデックスの長さが 8 であると見積もったとします。この場合、TiDB は 2つのインデックスのコストを計算します。 - インデックス`b`のコスト = 行数`b < 100` * インデックス`b`の長さ = 20 * 8 = 160 - インデックス`c`のコスト = 行数`c < 100` * インデックス`c`の長さ = 500 * 8 = 4000 diff --git a/dashboard/continuous-profiling.md b/dashboard/continuous-profiling.md index 21a1573777bd6..f68024d249dfd 100644 --- a/dashboard/continuous-profiling.md +++ b/dashboard/continuous-profiling.md @@ -17,7 +17,7 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 継続的プロファイリングは[手動プロファイリング](/dashboard/dashboard-profiling.md)の拡張機能です。どちらも、各インスタンスの異なる種類のパフォーマンスデータを収集・分析するために使用できます。両者の違いは次のとおりです。 -- 手動プロファイリングでは、プロファイリングを開始した瞬間に短期間 (たとえば 30 秒) のみパフォーマンス データが収集されますが、継続プロファイリングが有効になっている場合は、継続的にデータが収集されます。 +- 手動プロファイリングでは、プロファイリングを開始した瞬間に短期間 (たとえば 30秒) のみパフォーマンス データが収集されますが、継続プロファイリングが有効になっている場合は、継続的にデータが収集されます。 - 手動プロファイリングは現在発生している問題を分析するためにのみ使用できますが、継続的プロファイリングは現在の問題と履歴の問題の両方を分析するために使用できます。 - 手動プロファイリングでは特定のインスタンスの特定のパフォーマンス データを収集できますが、継続的プロファイリングではすべてのインスタンスのすべてのパフォーマンス データを収集します。 - 継続的なプロファイリングでは、より多くのパフォーマンス データが保存されるため、より多くのディスク領域が使用されます。 diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index c3a436f7d4810..b783121d4b243 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -9,7 +9,7 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 ## ページにアクセスする {#access-the-page} -クラスター情報ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 +クラスター情報ページにアクセスするには、次の2つの方法のいずれかを使用できます。 - TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[クラスタ情報]**をクリックします。 @@ -61,7 +61,7 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 - ホスト アドレス: ホスト IP アドレス。 - CPU: ホスト CPU の論理コアの数。 -- CPU 使用率: 現在の 1 秒間のユーザー モードとカーネル モードの CPU 使用率。 +- CPU 使用率: 現在の 1秒間のユーザー モードとカーネル モードの CPU 使用率。 - メモリ: ホストの合計物理メモリサイズ。 - メモリ使用量: ホストの現在のメモリ使用量。 diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md index 7391c1d86269c..fc862f0bbf90f 100644 --- a/dashboard/dashboard-diagnostics-access.md +++ b/dashboard/dashboard-diagnostics-access.md @@ -46,7 +46,7 @@ TiDB Dashboardのクラスタ診断機能は、指定された時間範囲内で - 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`この時間範囲内では、システムは異常です。 - 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`この時間範囲内では、システムは正常です。 -前の 2 つの時間範囲の比較レポートを生成するには、次の手順に従います。 +前の 2つの時間範囲の比較レポートを生成するには、次の手順に従います。 1. システムが異常になる範囲の開始時刻である**範囲開始時刻** （例： `2022-05-21 14:40:00` ）を設定します。 2. **範囲期間**を設定します。通常、この期間はシステム異常の継続時間（5分など）です。 diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index 4c4597e47b462..26d8b289c9969 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 つデプロイされていることを意味します。`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です。 @@ -71,7 +71,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 - `INSTANCE` : インスタンス アドレス ( `IP:PORT`形式の文字列)。 - `STATUS_ADDRESS` : HTTP API サービス アドレス。 - `VERSION` : 対応するノードのセマンティック バージョン番号。 -- `GIT_HASH` : ノード バージョンをコンパイルするときの Git コミット ハッシュ。2 つのノードが完全に一貫したバージョンであるかどうかを識別するために使用されます。 +- `GIT_HASH` : ノード バージョンをコンパイルするときの Git コミット ハッシュ。2つのノードが完全に一貫したバージョンであるかどうかを識別するために使用されます。 - `START_TIME` : 対応するノードの開始時刻。 - `UPTIME` : 対応するノードの稼働時間。 @@ -147,10 +147,10 @@ TiDBには自動診断結果が組み込まれています。各フィールド - `TIME_RATIO` : この監視メトリックによって消費された合計時間と、監視行の合計時間の比率（ `TIME_RATIO`は`1`です。たとえば、 `kv_request`の合計消費時間は`tidb_query`の`1.65`倍（つまり`38325.58` / `23223.86` ）です。KVリクエストは同時に実行されるため、すべてのKVリクエストの合計時間は、クエリの合計実行時間（ `tidb_query` ）を超える可能性があります。 - `TOTAL_TIME` : この監視メトリックによって消費された合計時間。 - `TOTAL_COUNT` : この監視メトリックが実行された合計回数。 -- `P999` : この監視メトリックの最大 P999 時間。 -- `P99` : この監視メトリックの最大 P99 時間。 -- `P90` : この監視メトリックの最大 P90 時間。 -- `P80` : この監視メトリックの最大 P80 時間。 +- `P999` : この監視メトリックの最大 P999時間。 +- `P99` : この監視メトリックの最大 P99時間。 +- `P90` : この監視メトリックの最大 P90時間。 +- `P80` : この監視メトリックの最大 P80時間。 次の画像は、上記の監視メトリックにおける関連モジュールの時間消費の関係を示しています。 @@ -158,7 +158,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド 上の画像では、黄色のボックスは TiDB 関連の監視メトリックです。青色のボックスは TiKV 関連の監視メトリックであり、灰色のボックスは一時的に特定の監視メトリックに対応していません。 -上の画像では、時間消費量`tidb_query`には次の 4 つの部分が含まれます。 +上の画像では、時間消費量`tidb_query`には次の4つの部分が含まれます。 - `get_token` - `parse` @@ -198,7 +198,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド - `tikv_raft_apply_wait` - `tikv_raft_apply_log` -`TOTAL_TIME` 、P999 時間、および P99 時間を使用して、上記の時間消費間の関係に従ってどのモジュールがより長い時間を消費しているかを判断し、関連する監視メトリックを確認することができます。 +`TOTAL_TIME` 、P999時間、および P99時間を使用して、上記の時間消費間の関係に従ってどのモジュールがより長い時間を消費しているかを判断し、関連する監視メトリックを確認することができます。 > **Note:** > @@ -241,7 +241,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド 例： -上記の表では、レポート時間範囲内で、 `tidb_txn_kv_write_size` ：KV 書き込みトランザクションの合計は約 181,296 件で、KV 書き込みの合計サイズは 266.772 MB です。そのうち、KV 書き込みの単一トランザクションの最大 P999、P99、P90、P80 値は、116.913 KB、1.996 KB、1.905 KB、1.805 KB です。 +上記の表では、レポート時間範囲内で、 `tidb_txn_kv_write_size` ：KV 書き込みトランザクションの合計は約 181,296件で、KV 書き込みの合計サイズは 266.772 MB です。そのうち、KV 書き込みの単一トランザクションの最大 P999、P99、P90、P80 値は、116.913 KB、1.996 KB、1.905 KB、1.805 KB です。 ##### DDLオーナー {#ddl-owner} @@ -256,8 +256,8 @@ TiDBには自動診断結果が組み込まれています。各フィールド TiDB のその他の監視テーブルは次のとおりです。 - 統計情報: TiDB 統計情報の関連する監視メトリックを表示します。 -- スロークエリ上位 10 件: レポートの時間範囲内でスロークエリ上位 10 件の情報を表示します。 -- ダイジェストによるトップ 10 のスロークエリ グループ: SQL フィンガープリントに従って集計された、レポートの時間範囲内の上位 10 件のスロークエリ情報を表示します。 +- スロークエリ上位 10件: レポートの時間範囲内でスロークエリ上位 10件の情報を表示します。 +- ダイジェストによるトップ 10 のスロークエリ グループ: SQL フィンガープリントに従って集計された、レポートの時間範囲内の上位 10件のスロークエリ情報を表示します。 - 異なるプランを持つスロークエリ: レポートの時間範囲内で実行計画が変更される SQL ステートメント。 #### PD関連のモニタリング情報 {#pd-related-monitoring-information} @@ -321,7 +321,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり 2つの期間の比較レポートを生成できます。レポートの内容は、2つの期間の差異を示す比較列が追加されていることを除けば、単一の期間のレポートと同じです。以下のセクションでは、比較レポートに含まれるいくつかの独自のテーブルと、比較レポートの表示方法について説明します。 -まず、基本情報の`Compare Report Time Range`レポートには、比較のための 2 つの時間範囲が表示されます。 +まず、基本情報の`Compare Report Time Range`レポートには、比較のための 2つの時間範囲が表示されます。 ![Compare Report Time Range report](/media/dashboard/dashboard-diagnostics-compare-time.png) diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index 2acb9634628bc..6e51603c9203c 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -17,7 +17,7 @@ summary: TiDB Dashboardの診断レポートは、異なる時間範囲でのシ `go-ycsb`ストレステストの結果は上の画像に示されています。`2020-03-10 13:24:30`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの診断レポートを使用して原因を特定できます。 -次の 2 つの時間範囲でシステムを比較するレポートを生成します。 +次の2つの時間範囲でシステムを比較するレポートを生成します。 T1: `2020-03-10 13:21:00` ～ `2020-03-10 13:23:00` 。この範囲ではシステムは正常であり、基準範囲と呼ばれます。 @@ -35,7 +35,7 @@ T2: `2020-03-10 13:24:30` ～ `2020-03-10 13:27:30` 。この範囲ではQPSが - `tidb_query_duration` : P999 クエリのレイテンシーが1.54 倍増加しました。 - `tidb_cop_duration` : P999 コプロセッサ要求の処理レイテンシーが 2.48 倍に増加しました。 - `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。 -- `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3 つの TiKV インスタンスで大幅に改善されました。 +- `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3つの TiKV インスタンスで大幅に改善されました。 - `pd_operator_step_finish_total_count`では、転属リーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 - このレポートは、スロークエリが存在する可能性があることを示しており、SQL文を使用してスロークエリを照会できることを示しています。SQL文の実行結果は次のとおりです。 @@ -57,7 +57,7 @@ min(prev_stmt) | digest | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8d03df ``` -上記の結果から、 `13:24:30`から、バッチ削除の大規模な書き込みがあり、合計 196 回実行され、そのたびに 5,000 行のデータが削除され、合計所要時間は 46.8 秒であることがわかります。 +上記の結果から、 `13:24:30`から、バッチ削除の大規模な書き込みがあり、合計196回実行され、そのたびに 5,000 行のデータが削除され、合計所要時間は 46.8秒であることがわかります。 ### 例2 {#example-2} @@ -67,7 +67,7 @@ digest | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8 もう1つの`go-ycsb`ストレステストの結果を上の画像に示します。`2020-03-08 01:46:30`にQPSが急激に低下し始め、回復していないことがわかります。 -次の 2 つの時間範囲でシステムを比較するレポートを生成します。 +次の2つの時間範囲でシステムを比較するレポートを生成します。 T1: `2020-03-08 01:36:00` ～ `2020-03-08 01:41:00` 。この範囲ではシステムは正常であり、基準範囲と呼ばれます。 @@ -98,7 +98,7 @@ MESSAGE | [expensivequery.go:167] [expensive_query] [cost_time=60.085949605s] [ `go-ycsb`ストレステストの結果は上の画像に示されています。`2020-05-22 22:14:00`にQPSが急激に低下し始めたことがわかります。3分後、QPSは正常に戻り始めました。TiDB Dashboardの比較診断レポートを使用して、原因を特定できます。 -次の 2 つの時間範囲でシステムを比較するレポートを生成します。 +次の2つの時間範囲でシステムを比較するレポートを生成します。 T1: `2020-05-22 22:11:00` ～ `2020-05-22 22:14:00` 。この範囲ではシステムは正常であり、基準範囲と呼ばれます。 diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index b47827e6b96f3..fb3b124b191d1 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -19,7 +19,7 @@ TiDB Dashboardは[GitHub](https://github.com/pingcap-incubator/tidb-dashboard) ## TiDBクラスタの全体的な実行ステータスを表示します {#show-the-overall-running-status-of-the-tidb-cluster} -TiDB Dashboardを使用すると、TiDB クラスターの 1 秒あたりのクエリ数 (QPS)、実行時間、最も多くのリソースを消費する SQL ステートメントの種類などの概要情報を確認できます。 +TiDB Dashboardを使用すると、TiDB クラスターの 1秒あたりのクエリ数 (QPS)、実行時間、最も多くのリソースを消費する SQL ステートメントの種類などの概要情報を確認できます。 詳細は[TiDB Dashboardの概要](/dashboard/dashboard-overview.md)参照。 diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index fdfc38bc10e85..9c68417ead114 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -9,7 +9,7 @@ TiDB DashboardのKey Visualizerページは、TiDBの使用状況を分析し、 ## Key Visualizerページにアクセスする {#access-key-visualizer-page} -Key Visualizer ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 +Key Visualizer ページにアクセスするには、次の2つの方法のいずれかを使用できます。 - TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**Key Visualizer**をクリックします。 @@ -56,7 +56,7 @@ TiDBデータベースを使用する場合、ホットスポット問題が発 ### リージョン圧縮 {#region-compression} -TiDB クラスターには最大数十万のリージョンが含まれる場合があります。これほど多くのリージョンを画面に表示するのは困難です。そのため、各ヒートマップでは、これらのリージョンを 1,500 個の連続した範囲に圧縮し、各範囲を「バケット」と呼びます。ヒートマップでは、負荷の高いインスタンスに重点を置く必要があるため、Key Visualizer はトラフィックの少ない多数のリージョンを 1 つのバケットに圧縮し、トラフィックの多いリージョンも 1 つのバケットに表示するリージョンがあります。 +TiDB クラスターには最大数十万のリージョンが含まれる場合があります。これほど多くのリージョンを画面に表示するのは困難です。そのため、各ヒートマップでは、これらのリージョンを 1,500 個の連続した範囲に圧縮し、各範囲を「バケット」と呼びます。ヒートマップでは、負荷の高いインスタンスに重点を置く必要があるため、Key Visualizer はトラフィックの少ない多数のリージョンを 1つのバケットに圧縮し、トラフィックの多いリージョンも 1つのバケットに表示するリージョンがあります。 ## Key Visualizerを使用する {#use-key-visualizer} @@ -84,7 +84,7 @@ Key Visualizerページを初めてご利用になる場合は、 **設定**ペ ### 特定の期間またはリージョン範囲を観察する {#observe-a-certain-period-of-time-or-region-range} -Key Visualizer を開くと、デフォルトで過去 6 時間のデータベース全体のヒートマップが表示されます。このヒートマップでは、右側（現在時刻）に近いほど、各バケット列に対応する時間間隔が短くなります。特定の期間または特定のリージョン範囲を観察したい場合は、拡大して詳細を確認できます。具体的な手順は以下のとおりです。 +Key Visualizer を開くと、デフォルトで過去 6時間のデータベース全体のヒートマップが表示されます。このヒートマップでは、右側（現在時刻）に近いほど、各バケット列に対応する時間間隔が短くなります。特定の期間または特定のリージョン範囲を観察したい場合は、拡大して詳細を確認できます。具体的な手順は以下のとおりです。 1. ヒートマップを上または下にスクロールします。 2. 範囲を選択するには、次のいずれかのボタンをクリックしてドラッグします。 @@ -142,7 +142,7 @@ Key Visualizer を開くと、デフォルトで過去 6 時間のデータベ ## 一般的なヒートマップの種類 {#common-heatmap-types} -このセクションでは、Key Visualizer の一般的な 4 種類のヒートマップを示して解釈します。 +このセクションでは、Key Visualizer の一般的な 4種類のヒートマップを示して解釈します。 ### 均等に分散された作業負荷 {#evenly-distributed-workload} diff --git a/dashboard/dashboard-log-search.md b/dashboard/dashboard-log-search.md index d8143965e0a17..170493b9bf8e8 100644 --- a/dashboard/dashboard-log-search.md +++ b/dashboard/dashboard-log-search.md @@ -28,7 +28,7 @@ TiDB Dashboardにログインした後、 **ログの検索**をクリックし ![Search result](/media/dashboard/dashboard-log-search-result.png) -このページは次の 3 つの領域で構成されています。 +このページは次の3つの領域で構成されています。 - パラメータオプション（上記画像のエリア1）：これらのオプションは、検索ホームページのパラメータオプションと同じです。ボックス内のパラメータを再度選択して、新しい検索を開始できます。 - 進行状況 (上記画像の領域 2): ログ検索ステータスや各ノードの統計情報など、現在の検索進行状況がこのページの右側に表示されます。 @@ -50,7 +50,7 @@ TiDB Dashboardにログインした後、 **ログの検索**をクリックし - 成功: タスクが完了すると、自動的に**成功**ステータスになります。この時点で、ログはダッシュボードバックエンドが配置されているローカルディスクにキャッシュされており、フロントエンドに提供してダウンロードできます。 - 失敗: 検索タスクをキャンセルした場合、またはタスクがエラーで終了した場合、タスクは**失敗**ステータスになります。タスクが失敗すると、ローカルの一時ファイルは自動的に消去されます。 -検索進行領域には、次の 3 つのコントロール ボタンがあります。 +検索進行領域には、次の3つのコントロール ボタンがあります。 - **選択項目をダウンロード**: このボタンをクリックすると、選択したコンポーネント（完了したコンポーネントのみ選択可能）のログがダウンロードされ、tarファイルが生成されます。このtarファイルを解凍すると、1つまたは複数のzipファイルが生成されます（各コンポーネントに対応するzipファイルが1つずつあります）。zipファイルを解凍すると、ログテキストファイルが生成されます。 - **キャンセル**：このボタンをクリックすると、実行中のすべてのタスクがキャンセルされます。このボタンは、実行中のタスクがある場合にのみクリックできます。 diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index be5bff29da0b7..94aecbb646a51 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -23,8 +23,8 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー たとえば、監視メトリック`tidb_execute`のノードの意味は次のとおりです。 -- `tidb_execute`監視メトリックの合計実行時間は 19306.46 秒で、これはクエリの合計実行時間の 89.4% を占めます。 -- `tidb_execute`ノード自体の継続時間は 9070.18 秒で、これはクエリ全体の継続時間の 42% を占めます。 +- `tidb_execute`監視メトリックの合計実行時間は 19306.46秒で、これはクエリの合計実行時間の 89.4% を占めます。 +- `tidb_execute`ノード自体の継続時間は 9070.18秒で、これはクエリ全体の継続時間の 42% を占めます。 - ボックス領域にマウスを移動すると、合計期間、平均期間、平均 P99 (99 パーセンタイル) 期間などのメトリックの詳細情報が表示されます。 ![tidb\_execute node example](/media/dashboard/dashboard-metrics-relation-node-example.png) @@ -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 秒であることを示します。`89.40%`は、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 -- `9070.18s`は、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。`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`メトリック ノードの詳細が表示されます。 @@ -57,14 +57,14 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー ![tidb\_execute node relation example1](/media/dashboard/dashboard-metrics-relation-relation-example1.png) -上のグラフから、 `tidb_execute`の 2 つの子ノードがわかります。 +上のグラフから、 `tidb_execute`の 2つの子ノードがわかります。 -- `pd_start_tso_wait` : トランザクションの`start_tso`待機する合計時間。これは 300.66 秒です。 -- `tidb_txn_cmd` : TiDB が関連するトランザクション コマンドを実行する合計時間。9935.62 秒です。 +- `pd_start_tso_wait` : トランザクションの`start_tso`待機する合計時間。これは 300.66秒です。 +- `tidb_txn_cmd` : TiDB が関連するトランザクション コマンドを実行する合計時間。9935.62秒です。 さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。 -`tidb_execute`には`tidb_cop`メトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2 つのテーブルに対して`join`クエリを実行する`execute`の実行時間は 60 秒ですが、その間に結合した 2 つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。`cop`リクエストの実行時間がそれぞれ 40 秒と 30 秒の場合、 `cop`のリクエストの合計実行時間は 70 秒になります。しかし、 `execute`の実行時間はわずか 60 秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 +`tidb_execute`には`tidb_cop`メトリックの実行時間が含まれますが、同時に`cop`リクエストが実行される場合があります。例えば、2つのテーブルに対して`join`クエリを実行する`execute`の実行時間は 60秒ですが、その間に結合した 2つのテーブルに対してテーブルスキャンリクエストが同時に実行されます。`cop`リクエストの実行時間がそれぞれ 40秒と 30秒の場合、 `cop`のリクエストの合計実行時間は 70秒になります。しかし、 `execute`の実行時間はわずか 60秒です。したがって、親ノードの実行時間に子ノードの実行時間が完全に含まれていない場合、点線の矢印は子ノードを指します。 > **Note:** > @@ -86,4 +86,4 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー `tidb_kv_request`子ノードとして`tidb_kv_request.Get`と`tidb_kv_request.Cop`ノードを含みませんが、後者の2つのノードで構成されます。子ノードの名前プレフィックスは親ノードの名前に`.xxx`を加えたもので、これは子ノードが親ノードのサブクラスであることを意味します。このケースは次のように理解できます。 -TiDB がキー値要求を送信する合計時間は 14745.07 秒で、そのうち、タイプ`Get`と`Cop`キー値要求にはそれぞれ 9798.02 秒と 4946.46 秒かかります。 +TiDB がキー値要求を送信する合計時間は 14745.07秒で、そのうち、タイプ`Get`と`Cop`キー値要求にはそれぞれ 9798.02秒と 4946.46秒かかります。 diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index 76a83e28c72e6..ad90a9b51f19e 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -56,24 +56,24 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### QPS {#qps} -すべて`UPDATE` TiDB インスタンスで 1 秒あたりに実行された SQL 文の数 (タイプ別: `SELECT`など`INSERT` +すべて`UPDATE` TiDB インスタンスで 1秒あたりに実行された SQL 文の数 (タイプ別: `SELECT`など`INSERT` ### CPSタイプ別 {#cps-by-type} -タイプに基づいて、すべての TiDB インスタンスによって 1 秒あたりに処理されるコマンドの数 +タイプに基づいて、すべての TiDB インスタンスによって 1秒あたりに処理されるコマンドの数 ### プランキャッシュOPSを使用したクエリ {#queries-using-plan-cache-ops} -すべての TiDB インスタンスにおける 1 秒あたりのプラン キャッシュを使用するクエリの数 +すべての TiDB インスタンスにおける 1秒あたりのプラン キャッシュを使用するクエリの数 ### KV/TSO リクエスト OPS {#kv-tso-request-ops} - kvリクエスト合計: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 -- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1 秒あたりの KV リクエスト数 -- tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1 秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 -- tso - リクエスト: すべての TiDB インスタンスにおける 1 秒あたりの TSO リクエスト数 +- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1秒あたりの KV リクエスト数 +- tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 +- tso - リクエスト: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 -通常、 `tso - request` `tso - cmd`で割った値が、1 秒あたりの TSO 要求バッチの平均サイズになります。 +通常、 `tso - request` `tso - cmd`で割った値が、1秒あたりの TSO 要求バッチの平均サイズになります。 ### 接続数 {#connection-count} @@ -144,7 +144,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `Compile Duration` : 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 - `Execution Duration` : SQL文の実行計画の実行に費やされた時間 -これら 3 つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 +これら3つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 ### 平均 TiDB KV リクエスト期間 {#avg-tidb-kv-request-duration} @@ -158,7 +158,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `wait - avg` : すべての TiDB インスタンスで PD が TSO を返すのを待つ平均時間 - `rpc - avg` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでの平均時間 -- `wait - 99` : すべての TiDB インスタンスで PD が TSO を返すのを待つ P99 時間 +- `wait - 99` : すべての TiDB インスタンスで PD が TSO を返すのを待つ P99時間 - `rpc - 99` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでのP99時間 ### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} @@ -167,7 +167,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `Store Duration` : 非同期書き込み中のストアループで消費された時間 - `Apply Duration` : 非同期書き込み中の適用ループで消費された時間 -これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 +これら3つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 平均ストレージ非同期書き込み時間 = 平均保存時間 + 平均適用時間 @@ -177,4 +177,4 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `Commit Log Duration` : Raftがログをコミットするのにかかる時間 - `Apply Log Duration` : Raftがログを適用するのに要した時間 -これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 +これら3つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 15b3066d68595..61565d6c0fe1b 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -23,7 +23,7 @@ TiDB Dashboard UIは、v4.0以降のバージョンのPDコンポーネントに ## 複数のPDインスタンスを使用したデプロイメント {#deployment-with-multiple-pd-instances} -クラスターに複数の PD インスタンスがデプロイされている場合、これらのインスタンスのうち 1 つだけが TiDB Dashboardとして機能します。 +クラスターに複数の PD インスタンスがデプロイされている場合、これらのインスタンスのうち 1つだけが TiDB Dashboardとして機能します。 PDインスタンスが初めて実行される際、インスタンスは自動的に相互にネゴシエーションを行い、TiDB Dashboardを提供するインスタンスを1つ選択します。TiDB Dashboardは他のPDインスタンスでは実行されません。PDインスタンスが再起動されたり、新しいPDインスタンスが追加された場合でも、TiDB Dashboardサービスは選択されたPDインスタンスによって常に提供されます。ただし、TiDB Dashboardを提供するPDインスタンスがクラスターから削除（スケールイン）された場合は、再ネゴシエーションが行われます。このネゴシエーションプロセスではユーザーの介入は必要ありません。 diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md index 4296761973a72..6c4966ccb243c 100644 --- a/dashboard/dashboard-overview.md +++ b/dashboard/dashboard-overview.md @@ -7,7 +7,7 @@ summary: TiDB概要ページには、クラスターのQPS、レイテンシー このページには、次の情報を含む TiDB クラスター全体の概要が表示されます。 -- クラスター全体の 1 秒あたりのクエリ数 (QPS)。 +- クラスター全体の 1秒あたりのクエリ数 (QPS)。 - クラスター全体のクエリのレイテンシー。 - 最近の期間に最も長い実行時間を累積した SQL ステートメント。 - 最近の期間の実行時間がしきい値を超えたスロークエリ。 @@ -22,7 +22,7 @@ TiDB Dashboardにログインすると、デフォルトで概要ページが表 ## QPS {#qps} -この領域には、最近の 1 時間におけるクラスター全体の 1 秒あたりの成功したクエリと失敗したクエリの数が表示されます。 +この領域には、最近の 1時間におけるクラスター全体の 1秒あたりの成功したクエリと失敗したクエリの数が表示されます。 ![QPS](/media/dashboard/dashboard-overview-qps.png) @@ -32,7 +32,7 @@ TiDB Dashboardにログインすると、デフォルトで概要ページが表 ## レイテンシー {#latency} -この領域には、過去 1 時間におけるクラスター全体のクエリの 99.9%、99%、90% のレイテンシーが表示されます。 +この領域には、過去 1時間におけるクラスター全体のクエリの 99.9%、99%、90% のレイテンシーが表示されます。 ![Latency](/media/dashboard/dashboard-overview-latency.png) @@ -54,7 +54,7 @@ TiDB Dashboardにログインすると、デフォルトで概要ページが表 ## 最近のスロークエリ {#recent-slow-queries} -デフォルトでは、この領域には、過去 30 分間のクラスター全体の最新の 10 件のスロークエリが表示されます。 +デフォルトでは、この領域には、過去 30分間のクラスター全体の最新の 10件のスロークエリが表示されます。 ![Recent slow queries](/media/dashboard/dashboard-overview-slow-query.png) diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 91b49733aea49..071d265d3d365 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -43,7 +43,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 ## プロファイリングを開始 {#start-profiling} -インスタンス プロファイリング ページで、少なくとも 1 つのターゲット インスタンスを選択し、 **[プロファイリングの開始]**をクリックしてインスタンス プロファイリングを開始します。 +インスタンス プロファイリング ページで、少なくとも 1つのターゲット インスタンスを選択し、 **[プロファイリングの開始]**をクリックしてインスタンス プロファイリングを開始します。 ![Start instance profiling](/media/dashboard/dashboard-profiling-start.png) diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index 24ce03b15c697..5deaefa0b98c3 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -9,7 +9,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ ## ページにアクセスする {#access-the-page} -リソース マネージャー ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 +リソース マネージャー ページにアクセスするには、次の2つの方法のいずれかを使用できます。 - TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[リソース マネージャー] を**クリックします。 @@ -21,7 +21,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ ![TiDB Dashboard: Resource Manager](/media/dashboard/dashboard-resource-manager-info.png) -リソース マネージャー ページには、次の 3 つのセクションがあります。 +リソース マネージャー ページには、次の3つのセクションがあります。 - コンフィグレーション: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)を参照してください。 @@ -55,7 +55,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ 推定期間を10分から24時間まで選択できます。使用されるタイムゾーンはフロントエンドユーザーのタイムゾーンと同じです。 - - 時間ウィンドウの範囲が 10 分から 24 時間の範囲外の場合、次のエラーが表示されます`ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s` 。 + - 時間ウィンドウの範囲が 10分から 24時間の範囲外の場合、次のエラーが表示されます`ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s` 。 - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。 diff --git a/dashboard/dashboard-session-sso.md b/dashboard/dashboard-session-sso.md index 4f940a2104a0d..943f43686de4a 100644 --- a/dashboard/dashboard-session-sso.md +++ b/dashboard/dashboard-session-sso.md @@ -23,7 +23,7 @@ TiDB Dashboardは、SQLベースの[OIDC](https://openid.net/connect/)サイン 4. フォームの**OIDC クライアント ID**と**OIDC 検出 URL**フィールドに入力します。 - 通常、SSO サービス プロバイダーから次の 2 つのフィールドを取得できます。 + 通常、SSO サービス プロバイダーから次の2つのフィールドを取得できます。 - OIDC クライアント ID は、OIDC トークン発行者とも呼ばれます。 - OIDC Discovery URL は、OIDC Token Audience とも呼ばれます。 diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index efa457266abd2..974ca4ad14413 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -68,7 +68,7 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす ### 実行計画 {#execution-plans} -TiDB Dashboardでは、表、テキスト、グラフの 3 つの方法で実行計画を表示できます。実行計画の読み方については、[クエリ実行計画を理解する](/explain-overview.md)を参照してください。 +TiDB Dashboardでは、表、テキスト、グラフの 3つの方法で実行計画を表示できます。実行計画の読み方については、[クエリ実行計画を理解する](/explain-overview.md)を参照してください。 #### 実行計画を表形式で表示 {#execution-plan-in-table-format} diff --git a/dashboard/dashboard-statement-list.md b/dashboard/dashboard-statement-list.md index 1695c82f4658a..003cc162250b1 100644 --- a/dashboard/dashboard-statement-list.md +++ b/dashboard/dashboard-statement-list.md @@ -11,7 +11,7 @@ SQL文ページには、クラスター内のすべてのSQL文の実行状況 ## ページにアクセスする {#access-the-page} -SQL ステートメントの概要ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 +SQL ステートメントの概要ページにアクセスするには、次の2つの方法のいずれかを使用できます。 - TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[SQL ステートメント]**をクリックします。 diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index 1ccabafd97d3c..173002db0beeb 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -93,7 +93,7 @@ DATE ### `TIME`型 {#time-type} -`TIME`型の場合、フォーマットは`HH:MM:SS[.fraction]`で、有効な値の範囲は '-838:59:59.000000' から '838:59:59.000000' です。`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)] @@ -256,10 +256,10 @@ mysql> SELECT NOW(), NOW()+0, NOW(3)+0; - 01から69までの値は2001から2069までの値に変換されます - 70から99までの値は1970から1999までの値に変換されます -これらのルールは`YEAR`タイプにも適用されますが、1 つの例外があります。 +これらのルールは`YEAR`タイプにも適用されますが、1つの例外があります。 数字の`00`を`YEAR(4)`に代入すると、結果は 2000 ではなく 0000 になります。 -結果を 2000 にしたい場合は、値を 2000 に指定します。 +結果を2000にしたい場合は、値を2000に指定します。 `MIN()`や`MAX()`の一部の関数では、2桁の年部分が正しく計算されない場合があります。これらの関数では、4桁の形式の方が適しています。 diff --git a/data-type-default-values.md b/data-type-default-values.md index 431dad50ba106..4ebc36376e33f 100644 --- a/data-type-default-values.md +++ b/data-type-default-values.md @@ -89,4 +89,4 @@ CREATE TABLE t5 ( ); ``` -最後の 2 つの例は同様のデフォルトを示していますが、リテラルではなく式を使用しているため、最初の例のみが有効です。 +最後の 2つの例は同様のデフォルトを示していますが、リテラルではなく式を使用しているため、最初の例のみが有効です。 diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 3c8ac7be7eef3..d6f1cd1a7ca4e 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -5,7 +5,7 @@ summary: このドキュメントでは、新しく作成または再編成さ # DDL ステートメントに埋め込まれた`ANALYZE` (v8.5.4 で導入) {#analyze-embedded-in-ddl-statements-span-class-version-mark-introduced-in-v8-5-4-span} -このドキュメントでは、次の 2 種類の DDL ステートメントに組み込まれている`ANALYZE`機能について説明します。 +このドキュメントでは、次の2種類の DDL ステートメントに組み込まれている`ANALYZE`機能について説明します。 - 新しいインデックスを作成するDDL文: [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) - 既存のインデックスを再編成する DDL ステートメント: [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)と[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index bcfd9d7a39035..c87981f6420c6 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/dev-guide-choose-driver-or-orm/','/ja/tidbcloud/dev-g > **Note:** > -> TiDB は、ドライバーと ORM に対して次の 2 つのサポート レベルを提供します。 +> TiDB は、ドライバーと ORM に対して次の2つのサポート レベルを提供します。 > > - **完全**: TiDB がツールのほとんどの機能と互換性があり、最新バージョンとの互換性を維持していることを示します。PingCAP は、最新バージョン[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)との互換性テストを定期的に実施します。 > - **互換**：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index a65fb68cf5a9f..03d62809f84f8 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -238,7 +238,7 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 #### バッチ関連パラメータ {#batch-related-parameters} -バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。`addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: +バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`設定することをお勧めします。`addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1つずつ送信します。例: ```java pstmt = prepare("INSERT INTO `t` (a) values(?)"); @@ -304,7 +304,7 @@ UPDATE `t` SET `a` = 10 WHERE `id` = 1; UPDATE `t` SET `a` = 11 WHERE `id` = 2; #### タイムアウト関連のパラメータ {#timeout-related-parameters} -TiDB はタイムアウトを制御するために 2 つの MySQL 互換パラメータ ( [`wait_timeout`](/system-variables.md#wait_timeout)と[`max_execution_time`](/system-variables.md#max_execution_time) ) を提供します。これらの 2 つのパラメータはそれぞれ、 Javaアプリケーションとの接続アイドルタイムアウトと接続内の SQL 実行のタイムアウトを制御します。つまり、これらのパラメータは、TiDB とJavaアプリケーション間の接続の最長アイドル時間と最長ビジー時間を制御します。TiDB v5.4 以降、 `wait_timeout`のデフォルト値は`28800`秒で、8 時間です。v5.4 より前の TiDB バージョンでは、デフォルト値は`0`で、タイムアウトは無制限です。`max_execution_time`のデフォルト値は`0`で、SQL ステートメントの最大実行時間は無制限であり、 `SELECT`ステートメントすべて ( `SELECT ... FOR UPDATE`を含む) に適用されます。 +TiDB はタイムアウトを制御するために 2つの MySQL 互換パラメータ ( [`wait_timeout`](/system-variables.md#wait_timeout)と[`max_execution_time`](/system-variables.md#max_execution_time) ) を提供します。これらの 2つのパラメータはそれぞれ、 Javaアプリケーションとの接続アイドルタイムアウトと接続内の SQL 実行のタイムアウトを制御します。つまり、これらのパラメータは、TiDB とJavaアプリケーション間の接続の最長アイドル時間と最長ビジー時間を制御します。TiDB v5.4 以降、 `wait_timeout`のデフォルト値は`28800`秒で、8時間です。v5.4 より前の TiDB バージョンでは、デフォルト値は`0`で、タイムアウトは無制限です。`max_execution_time`のデフォルト値は`0`で、SQL ステートメントの最大実行時間は無制限であり、 `SELECT`ステートメントすべて ( `SELECT ... FOR UPDATE`を含む) に適用されます。 デフォルト値の[`wait_timeout`](/system-variables.md#wait_timeout)は比較的大きな値です。トランザクションが開始されてもコミットもロールバックもされないような状況では、ロックの保持時間が長引くのを防ぐために、よりきめ細かな制御と短いタイムアウトが必要になる場合があります。このような場合は、 [`tidb_idle_transaction_timeout`](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760) （TiDB v7.6.0で導入）を使用して、ユーザーセッション内のトランザクションのアイドルタイムアウトを制御できます。 diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 35b90ce4037a2..aed5db4f0c840 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -18,7 +18,7 @@ aliases: ['/ja/tidb/stable/dev-guide-create-table/','/ja/tidb/dev/dev-guide-crea ## テーブルとは何ですか {#what-is-a-table} -[テーブル](/develop/dev-guide-schema-design-overview.md#table)、TiDB の論理オブジェクトであり、 の[データベース](/develop/dev-guide-schema-design-overview.md#database)オブジェクトです。SQL ステートメントから送信されたデータを格納するために使用されます。テーブルは、行と列の形式でデータレコードを保存します。テーブルには少なくとも 1 つの列があります。 `n`列を定義した場合、各データ行には`n`列とまったく同じフィールドが含まれます。 +[テーブル](/develop/dev-guide-schema-design-overview.md#table)、TiDB の論理オブジェクトであり、 の[データベース](/develop/dev-guide-schema-design-overview.md#database)オブジェクトです。SQL ステートメントから送信されたデータを格納するために使用されます。テーブルは、行と列の形式でデータレコードを保存します。テーブルには少なくとも 1つの列があります。 `n`列を定義した場合、各データ行には`n`列とまったく同じフィールドが含まれます。 ## テーブルの名前を挙げてください {#name-a-table} @@ -136,7 +136,7 @@ TiDB は v5.0 以降、[クラスター化インデックス](/clustered-indexes 現在、TiDBの***主キーを含む***テーブルは、以下の2つのカテゴリに分類されます。 -- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 +- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2つのキーと値のペアが必要です。それらは次のとおりです。 - `_tidb_rowid` （キー） - 行データ（値） - 主キーデータ（キー） - `_tidb_rowid` （値） - `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 diff --git a/develop/dev-guide-delete-data.md b/develop/dev-guide-delete-data.md index 0a8e32b182112..ae48b76925af8 100644 --- a/develop/dev-guide-delete-data.md +++ b/develop/dev-guide-delete-data.md @@ -37,7 +37,7 @@ DELETE FROM {table} WHERE {filter} - `WHERE`ステートメントには、必ず`DELETE`句を指定してください。 `WHERE`句が指定されていない場合、TiDB はテーブル内の***すべての行***を削除します。 -- TiDB では 1 つのトランザクションのサイズが制限されているため (たとえば、1 万行以上)、大量の行を削除する場合は[一括削除](#bulk-delete)を使用します (段階[トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。 +- TiDB では 1つのトランザクションのサイズが制限されているため (たとえば、1 万行以上)、大量の行を削除する場合は[一括削除](#bulk-delete)を使用します (段階[トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。 - テーブル内のすべてのデータを削除する場合は、 `DELETE`ステートメントを使用しないでください。代わりに、 [`TRUNCATE`](/sql-statements/sql-statement-truncate.md)ステートメントを使用してください。 @@ -53,7 +53,7 @@ DELETE FROM {table} WHERE {filter} SELECT COUNT(*) FROM `ratings` WHERE `rated_at` >= "2022-04-15 00:00:00" AND `rated_at` <= "2022-04-15 00:15:00"; ``` -10,000 件を超えるレコードが返された場合は、[一括削除](#bulk-delete)を使用して削除します。 +10,000件を超えるレコードが返された場合は、[一括削除](#bulk-delete)を使用して削除します。 返されたレコード数が10,000件未満の場合は、以下の例を参考に削除してください。 @@ -196,7 +196,7 @@ TiDBは[統計情報](/statistics.md)を使用してインデックスの選択 ### 一括削除の例 {#bulk-delete-example} -特定の期間内にアプリケーションエラーが見つかったとします。この期間内の[評価](/develop/dev-guide-bookshop-schema-design.md#ratings-table)に関するすべてのデータ（例えば、 `2022-04-15 00:00:00`から`2022-04-15 00:15:00`まで）を削除する必要があり、15 分で 10,000 件以上のレコードが書き込まれるとします。次のように実行できます。 +特定の期間内にアプリケーションエラーが見つかったとします。この期間内の[評価](/develop/dev-guide-bookshop-schema-design.md#ratings-table)に関するすべてのデータ（例えば、 `2022-04-15 00:00:00`から`2022-04-15 00:15:00`まで）を削除する必要があり、15分で 10,000件以上のレコードが書き込まれるとします。次のように実行できます。
diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 1f29dea0c0bfa..d3ede17714a71 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -241,7 +241,7 @@ WITH orders_group_by_month AS ( SELECT * FROM acc; ``` -`EXPLAIN`ステートメントを使用して、上記のSQL文の実行計画を確認できます。タスク列に`cop[tiflash]`と`cop[tikv]`が同時に表示される場合、 TiFlashと TiKV の両方がこのクエリを完了するようにスケジュールされていることを意味します。TiFlash と TiKV のストレージエンジンは通常、異なる TiDB ノードを使用するため、2 つのクエリタイプは互いに影響を受けません。 +`EXPLAIN`ステートメントを使用して、上記のSQL文の実行計画を確認できます。タスク列に`cop[tiflash]`と`cop[tikv]`が同時に表示される場合、 TiFlashと TiKV の両方がこのクエリを完了するようにスケジュールされていることを意味します。TiFlash と TiKV のストレージエンジンは通常、異なる TiDB ノードを使用するため、2つのクエリタイプは互いに影響を受けません。 TiDBがTiFlashをどのように使用するかの詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)を参照してください。 diff --git a/develop/dev-guide-implicit-type-conversion.md b/develop/dev-guide-implicit-type-conversion.md index 9a9c497f8374f..b0668731a775a 100644 --- a/develop/dev-guide-implicit-type-conversion.md +++ b/develop/dev-guide-implicit-type-conversion.md @@ -19,7 +19,7 @@ TiDB における暗黙的な型変換のルールは次のとおりです。 - 両方の引数が整数の場合、それらは整数として比較されます。 - 数値との比較を行わない場合、16 進値はバイナリ文字列として扱われます。 - 引数の一方が小数値の場合、比較はもう一方の引数に依存します。もう一方の引数が小数値または整数値の場合、その引数は小数値と比較されます。もう一方の引数が浮動小数点値の場合、その引数は浮動小数点値と比較されます。 -- 引数の 1 つが`TIMESTAMP`列または`DATETIME`列で、もう 1 つの引数が定数の場合、比較が実行される前に定数はタイムスタンプに変換されます。 +- 引数の 1つが`TIMESTAMP`列または`DATETIME`列で、もう 1つの引数が定数の場合、比較が実行される前に定数はタイムスタンプに変換されます。 - それ以外の場合、引数は浮動小数点数 ( `DOUBLE`型) として比較されます。 ## 暗黙的な型変換によって生じる結果 {#consequences-caused-by-implicit-type-conversion} diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index a05abe1a3a405..b094f7a54ca00 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -61,7 +61,7 @@ DEALLOCATE PREPARE {prepared_statement_name}; ## 例 {#examples} -このセクションでは、プリペアドステートメントの例として、データの`SELECT`とデータの`INSERT`の 2 つを説明します。 +このセクションでは、プリペアドステートメントの例として、データの`SELECT`とデータの`INSERT`の 2つを説明します。 ### `SELECT`例 {#select-example} diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index 01ce9180c85a8..d2e83c5facad8 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -224,7 +224,7 @@ systemctl start docker プロンプトが表示されたら、 `Serverless Tier Host`のTiDB Cloud Starterインスタンスのエンドポイントを入力し、次にTiDB Cloud Starterインスタンスのユーザー名とパスワードを入力します。 - 以下は出力例です。現在の`tidb-cloud-connect`フォルダーの下に 3 つの設定ファイルが生成されていることがわかります。 + 以下は出力例です。現在の`tidb-cloud-connect`フォルダーの下に 3つの設定ファイルが生成されていることがわかります。 ``` [Begin] generating configuration files.. @@ -687,7 +687,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 上記の手順を実行すると、ProxySQLの管理画面が表示されます。 -2. 使用するTiDB Cloud Dedicatedクラスターを構成します。ProxySQL に 1 つまたは複数のTiDB Cloud Dedicatedクラスターを追加できます。たとえば、次のステートメントは 1 つのTiDB Cloud Dedicatedクラスターを追加します。 ``と``を、ご使用のTiDB Cloud Dedicatedエンドポイントとポートに置き換える必要があります (デフォルトのポートは`4000`です)。 +2. 使用するTiDB Cloud Dedicatedクラスターを構成します。ProxySQL に 1つまたは複数のTiDB Cloud Dedicatedクラスターを追加できます。たとえば、次のステートメントは 1つのTiDB Cloud Dedicatedクラスターを追加します。 ``と``を、ご使用のTiDB Cloud Dedicatedエンドポイントとポートに置き換える必要があります (デフォルトのポートは`4000`です)。 ```sql INSERT INTO mysql_servers(hostgroup_id, hostname, port) @@ -896,10 +896,10 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 全てが順調に進めば、以下のコンテナが起動されます。 - - ポート`4001`および`4002`を介して公開される TiDB クラスタの 2 つの Docker コンテナ - - ポート`6034`を介して公開される ProxySQL Docker コンテナが 1 つあります。 + - ポート`4001`および`4002`を介して公開される TiDB クラスタの 2つの Docker コンテナ + - ポート`6034`を介して公開される ProxySQL Docker コンテナが 1つあります。 -4. 2 つの TiDB コンテナでは、 `mysql`を使用して同様のスキーマ定義を持つテーブルを作成し、次に異なるデータ ( `'tidb-server01-port-4001'` 、 `'tidb-server02-port-4002'` ) を挿入してこれらのコンテナを識別します。 +4. 2つの TiDB コンテナでは、 `mysql`を使用して同様のスキーマ定義を持つテーブルを作成し、次に異なるデータ ( `'tidb-server01-port-4001'` 、 `'tidb-server02-port-4002'` ) を挿入してこれらのコンテナを識別します。 @@ -1002,7 +1002,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 ProxySQLパターンがクエリルールとどのように一致するかについての追加情報は以下のとおりです。 - - ProxySQL は`rule_id`の昇順でルールを 1 つずつ照合しようとします。 + - ProxySQL は`rule_id`の昇順でルールを 1つずつ照合しようとします。 - `^`記号は SQL ステートメントの開始と一致し、 `$`終了と一致します。 ProxySQLの正規表現とパターンマッチングの詳細については、ProxySQLドキュメントの[mysql-query_processor_regex](https://proxysql.com/documentation/global-variables/mysql-variables/#mysql-query_processor_regex)を参照してください。 diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 871b6881f1e5c..d0ec57f45d542 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -260,7 +260,7 @@ public SessionFactory getSessionFactory() { } ``` -この関数を使用する際は、 `${your_entity_class}`独自のデータエンティティクラスに置き換える必要があります。複数のエンティティクラスを使用する場合は、それぞれに`.addAnnotatedClass(${your_entity_class})`ステートメントを追加する必要があります。上記の関数は、Hibernate を設定する方法の 1 つにすぎません。設定で問題が発生した場合、または Hibernate についてさらに詳しく知りたい場合は、 [Hibernateの公式ドキュメント](https://hibernate.org/orm/documentation)を参照してください。 +この関数を使用する際は、 `${your_entity_class}`独自のデータエンティティクラスに置き換える必要があります。複数のエンティティクラスを使用する場合は、それぞれに`.addAnnotatedClass(${your_entity_class})`ステートメントを追加する必要があります。上記の関数は、Hibernate を設定する方法の 1つにすぎません。設定で問題が発生した場合、または Hibernate についてさらに詳しく知りたい場合は、 [Hibernateの公式ドキュメント](https://hibernate.org/orm/documentation)を参照してください。 ### データを挿入または更新する {#insert-or-update-data} diff --git a/develop/dev-guide-sample-application-nodejs-typeorm.md b/develop/dev-guide-sample-application-nodejs-typeorm.md index 9e24c7f70b474..5fa7792a5dea5 100644 --- a/develop/dev-guide-sample-application-nodejs-typeorm.md +++ b/develop/dev-guide-sample-application-nodejs-typeorm.md @@ -227,7 +227,7 @@ npm run migration:run
期待される実行出力 -以下の SQL ステートメントは`players`テーブルと`profiles`テーブルを作成し、2 つのテーブルは外部キーによって関連付けられます。 +以下の SQL ステートメントは`players`テーブルと`profiles`テーブルを作成し、2つのテーブルは外部キーによって関連付けられます。 ```sql query: SELECT VERSION() AS `version` diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md index bf4e4ebdbcd50..ce5d1f73981b0 100644 --- a/develop/dev-guide-sample-application-python-sqlalchemy.md +++ b/develop/dev-guide-sample-application-python-sqlalchemy.md @@ -67,7 +67,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 > **Note:** > -> 現在、 TiDB Cloud Starterインスタンスには制限があります。5 分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。 +> 現在、 TiDB Cloud Starterインスタンスには制限があります。5分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index b9dda274c9687..79980e93f48ba 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -266,7 +266,7 @@ client = Mysql2::Client.new(options) ### データを挿入する {#insert-data} -次のクエリは、2 つのフィールドを持つ単一のプレーヤーを作成し、 `last_insert_id`を返します。 +次のクエリは、2つのフィールドを持つ単一のプレーヤーを作成し、 `last_insert_id`を返します。 ```ruby def create_player(client, coins, goods) diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index a9b3ccede7bdb..980341d8de5e7 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -255,7 +255,7 @@ production: ### データを挿入する {#insert-data} -次のクエリは、2 つのフィールドを持つ単一の Player オブジェクトを作成し、作成された`Player`オブジェクトを返します。 +次のクエリは、2つのフィールドを持つ単一の Player オブジェクトを作成し、作成された`Player`オブジェクトを返します。 ```ruby new_player = Player.create!(coins: 100, goods: 100) diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 5d8d7145fb957..370d6dd9a751b 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -128,7 +128,7 @@ SELECT * FROM `users`; トランザクション分離レベルは、データベースのトランザクション処理の基礎となります。ACID**の**「I」（Isolation）は、トランザクションの分離を意味します。 -SQL-92 標準では、次の 4 つの分離レベルが定義されています。 +SQL-92 標準では、次の4つの分離レベルが定義されています。 - コミットされていない読み取り ( `READ UNCOMMITTED` ) - コミットされた読み取り ( `READ COMMITTED` ) diff --git a/develop/dev-guide-transaction-restraints.md b/develop/dev-guide-transaction-restraints.md index c13503e8baeef..e4172e341bacf 100644 --- a/develop/dev-guide-transaction-restraints.md +++ b/develop/dev-guide-transaction-restraints.md @@ -355,7 +355,7 @@ mysql> SELECT * FROM doctors; +----+-------+---------+----------+ ``` -どちらのトランザクションでも、アプリケーションはまず 2 人以上の医師が待機しているかどうかを確認します。待機している場合は、1 人の医師が安全に休暇を取れると想定します。データベースはスナップショット分離を使用しているため、どちらのチェックも`2`を返すため、両方のトランザクションは次のステージに進みます。 `Alice`自分のレコードを非番に更新し、 `Bob`も同様に更新します。両方のトランザクションは正常にコミットされます。これで、待機中の医師がいなくなり、少なくとも 1 人の医師が待機している必要があるという要件に違反します。次の図 ( ***Designing Data-Intensive Applications***から引用) は、実際に何が起こるかを示しています。 +どちらのトランザクションでも、アプリケーションはまず 2人以上の医師が待機しているかどうかを確認します。待機している場合は、1人の医師が安全に休暇を取れると想定します。データベースはスナップショット分離を使用しているため、どちらのチェックも`2`を返すため、両方のトランザクションは次のステージに進みます。 `Alice`自分のレコードを非番に更新し、 `Bob`も同様に更新します。両方のトランザクションは正常にコミットされます。これで、待機中の医師がいなくなり、少なくとも 1人の医師が待機している必要があるという要件に違反します。次の図 ( ***Designing Data-Intensive Applications***から引用) は、実際に何が起こるかを示しています。 ![Write Skew](/media/develop/write-skew.png) @@ -725,7 +725,7 @@ mysql> SELECT * FROM T2; ## 自動コミットされた`SELECT FOR UPDATE`ステートメントはロックを待機しません {#auto-committed-select-for-update-statements-do-not-wait-for-locks} -現在、自動コミットされた`SELECT FOR UPDATE`ステートメントにはロックが追加されません。次のスクリーンショットは、2 つの別々のセッションでの影響を示しています。 +現在、自動コミットされた`SELECT FOR UPDATE`ステートメントにはロックが追加されません。次のスクリーンショットは、2つの別々のセッションでの影響を示しています。 ![The situation in TiDB](/media/develop/autocommit_selectforupdate_nowaitlock.png) diff --git a/develop/dev-guide-transaction-troubleshoot.md b/develop/dev-guide-transaction-troubleshoot.md index f1912d05ff1c7..27b7210a68570 100644 --- a/develop/dev-guide-transaction-troubleshoot.md +++ b/develop/dev-guide-transaction-troubleshoot.md @@ -16,17 +16,17 @@ aliases: ['/ja/tidb/stable/dev-guide-transaction-troubleshoot/','/ja/tidbcloud/d ERROR 1213: Deadlock found when trying to get lock; try restarting transaction ``` -デッドロックは、2 つ以上のトランザクションが、それぞれが保持しているロックを解放するのを待機している場合、またはロックの順序に一貫性がないため、ロック リソースを待機するループが発生している場合に発生します。 +デッドロックは、2つ以上のトランザクションが、それぞれが保持しているロックを解放するのを待機している場合、またはロックの順序に一貫性がないため、ロック リソースを待機するループが発生している場合に発生します。 以下は、データベース[`bookshop`](/develop/dev-guide-bookshop-schema-design.md)のテーブル`books`を使用したデッドロックの例です。 -まず、テーブル`books`に 2 つの行を挿入します。 +まず、テーブル`books`に 2つの行を挿入します。 ```sql INSERT INTO books (id, title, stock, published_at) VALUES (1, 'book-1', 10, now()), (2, 'book-2', 10, now()); ``` -TiDB悲観的トランザクション モードでは、2 つのクライアントがそれぞれ次のステートメントを実行すると、デッドロックが発生します。 +TiDB悲観的トランザクション モードでは、2つのクライアントがそれぞれ次のステートメントを実行すると、デッドロックが発生します。 | クライアントA | クライアントB | | --------------------------------------------------------- | ------------------------------------------------------------- | @@ -54,7 +54,7 @@ TiDB悲観的トランザクション モードでは、2 つのクライアン | | UPDATE books SET stock=stock-1 WHERE id=2; | | | COMMIT; | -あるいは、1 つの SQL ステートメントで 2 冊の本を更新することもできます。これにより、デッドロックを回避し、より効率的に実行できます。 +あるいは、1つの SQL ステートメントで 2 冊の本を更新することもできます。これにより、デッドロックを回避し、より効率的に実行できます。 ```sql UPDATE books SET stock=stock-1 WHERE id IN (1, 2); diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index 3367433749ea6..d393e0d469602 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/dev-guide-unstable-result-set/','/ja/tidbcloud/dev-gu 便宜上、MySQLは`GROUP BY`構文を「拡張」し、 `SELECT`句で`GROUP BY`句で宣言されていない非集約フィールドを参照できるようにしています。つまり、 `NON-FULL GROUP BY`構文です。他のデータベースでは、これは不安定な結果セットを引き起こすため、構文***エラー***とみなされます。 -たとえば、次の 2 つのテーブルがあるとします。 +たとえば、次の2つのテーブルがあるとします。 - `stu_info`学生情報を保存します - `stu_score`生徒のテストのスコアが格納されます。 @@ -67,7 +67,7 @@ ORDER BY `a`.`stuname`; ``` -すると、この SQL に一致する 2 つの値が返されます。 +すると、この SQL に一致する 2つの値が返されます。 最初に返される値: @@ -120,7 +120,7 @@ SQLセマンティクスでは、 `ORDER BY`構文が使用されている場合 分散データベースであるTiDBは、複数のサーバーにデータを保存しています。また、TiDBレイヤーはデータページをキャッシュしないため、 `ORDER BY`を含まないSQL文の結果セットの順序は不安定であると認識されやすくなります。連続した結果セットを出力するには、SQLセマンティクスに準拠した`ORDER BY`句に明示的に順序フィールドを追加する必要があります。 -次の例では、 `ORDER BY`句に 1 つのフィールドのみが追加され、TiDB はその 1 つのフィールドのみで結果を並べ替えます。 +次の例では、 `ORDER BY`句に 1つのフィールドのみが追加され、TiDB はその1つのフィールドのみで結果を並べ替えます。 ```sql mysql> select a.class, a.stuname, b.course, b.courscore from stu_info a join stu_score b on a.stuno=b.stuno order by a.class; diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 2bb46029795fd..c7d356b6774b6 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -50,7 +50,7 @@ UPDATE {table} SET {update_column} = {update_value} WHERE {filter_column} = {fil データ更新に関するベストプラクティスを以下に示します。 - `WHERE`ステートメントには、必ず`UPDATE`句を指定してください。 `UPDATE`ステートメントに`WHERE`句がない場合、TiDB はテーブル内の***すべての行***を更新します。 -- 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)を使用します。 TiDB は 1 つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。 +- 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)を使用します。 TiDB は 1つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。 ### `UPDATE`例 {#update-example} @@ -105,7 +105,7 @@ INSERT INTO {table} ({columns}) VALUES ({values}) ### `INSERT ON DUPLICATE KEY UPDATE`のベストプラクティス {#insert-on-duplicate-key-update-best-practices} -- `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1 つだけのテーブルでのみ使用してください。このステートメントは***、一意キー***(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1 つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。 +- `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1つだけのテーブルでのみ使用してください。このステートメントは***、一意キー***(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。 - データを作成または更新する際に、このステートメントを使用してください。 ### `INSERT ON DUPLICATE KEY UPDATE`例 {#insert-on-duplicate-key-update-example} @@ -162,7 +162,7 @@ VALUES (?, ?, ?, NOW()) ON DUPLICATE KEY UPDATE `score` = ?, `rated_at` = NOW()" ### 例 {#example} -過去 1 年間`bookshop`ウェブサイトでユーザーから多くの書籍評価が寄せられたとします。しかし、当初の 5 段階評価では書籍評価の区別がつきにくく、ほとんどの書籍が`3`と評価されています。そこで、評価を区別するために、5 段階評価から 10 段階評価に変更することにしました。 +過去 1年間`bookshop`ウェブサイトでユーザーから多くの書籍評価が寄せられたとします。しかし、当初の 5 段階評価では書籍評価の区別がつきにくく、ほとんどの書籍が`3`と評価されています。そこで、評価を区別するために、5 段階評価から 10 段階評価に変更することにしました。 前の5段階評価の`2`テーブルのデータに`ratings`を乗算し、評価テーブルに行が更新されたかどうかを示す新しい列を追加する必要があります。この列を使用すると、 `SELECT`で更新された行を除外できるため、スクリプトがクラッシュして行が複数回更新され、不合理なデータが生成されることを防ぐことができます。 @@ -255,7 +255,7 @@ func placeHolder(n int) string { } ``` -各イテレーションでは、 `SELECT`は主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`time.Sleep(time.Second)`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 +各イテレーションでは、 `SELECT`は主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`time.Sleep(time.Second)`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1秒間一時停止させます。
@@ -421,7 +421,7 @@ public class BatchUpdateExample { ``` -各イテレーションでは、 `SELECT`は主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`TimeUnit.SECONDS.sleep(1);`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1 秒間一時停止させます。 +各イテレーションでは、 `SELECT`は主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `ten_point`が`false` ) の主キー値を最大`1000`件まで選択します。 `SELECT`ステートメントは、重複を防ぐために、前の`SELECT`の結果の中で最大の主キーよりも大きい主キーを選択します。次に、一括更新を使用して、 `score`列に`2`を掛け、 `ten_point`を`true`に設定します。 `ten_point`を更新する目的は、クラッシュ後に再起動した場合に更新アプリケーションが同じ行を繰り返し更新してデータ破損を引き起こすのを防ぐためです。各ループの`TimeUnit.SECONDS.sleep(1);`は、更新アプリケーションがハードウェア リソースを過剰に消費するのを防ぐために、更新アプリケーションを 1秒間一時停止させます。
diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index c695df2cd190e..4aa02f0340508 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -18,7 +18,7 @@ TiDB v5.1以降、TiDBはANSI SQL99標準のCTEと再帰をサポートしてい 共通テーブル式（CTE）は、SQL文内で複数回参照できる一時的な結果セットであり、文の可読性と実行効率を向上させます。CTEを使用するには、 [`WITH`](/sql-statements/sql-statement-with.md)文を適用します。 -共通テーブル式は、非再帰 CTE と再帰 CTE の 2 種類に分類できます。 +共通テーブル式は、非再帰 CTE と再帰 CTE の 2種類に分類できます。 ### 非再帰CTE {#non-recursive-cte} @@ -31,7 +31,7 @@ WITH AS ( SELECT ... FROM ; ``` -たとえば、最年長の 50 人の著者がそれぞれ何冊の本を書いたかを知りたい場合は、次の手順を実行します。 +たとえば、最年長の 50人の著者がそれぞれ何冊の本を書いたかを知りたい場合は、次の手順を実行します。
@@ -159,7 +159,7 @@ FROM 4 rows in set (0.06 sec) ``` -この SQL ステートメントでは、 `,`で区切られた 3 つの CTE ブロックが定義されています。 +この SQL ステートメントでは、 `,`で区切られた 3つの CTE ブロックが定義されています。 まず、CTEブロック`books_authored_by_rm`で著者（ID `2299112019` ）が執筆した書籍を調べます。次に、 `books_with_average_ratings`と`books_with_orders`でこれらの書籍の平均評価と順位をそれぞれ求めます。最後に、 `JOIN`ステートメントで結果を集計します。 diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index ae23e3121ec4d..e900680ff433f 100644 --- a/develop/dev-guide-use-stale-read.md +++ b/develop/dev-guide-use-stale-read.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-stale-read/','/ja/tidbcloud/dev-guide-u 実際には、 [使用シナリオ](/stale-read.md#usage-scenarios-of-stale-read)に基づいて、TiDB でステイル読み取り を有効にすることが適切かどうかを慎重に検討してください。アプリケーションが非リアルタイム データの読み取りを許容できない場合は、 ステイル読み取りを有効にしないでください。 -TiDB は、ステートメント レベル、トランザクション レベル、セッション レベルの 3 つのレベルのステイル読み取りを提供します。 +TiDB は、ステートメント レベル、トランザクション レベル、セッション レベルの 3つのレベルのステイル読み取りを提供します。 ## 導入 {#introduction} @@ -97,13 +97,13 @@ SELECT id, title, type, price FROM books AS OF TIMESTAMP '2022-04-20 15:20:00' O 正確な時間を指定することに加えて、次のことも指定できます。 -- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` 10 秒前の最新データを照会します。 +- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` 10秒前の最新データを照会します。 - `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` `2016-10-08 16:45:26`から`2016-10-08 16:45:29`の間の最新データを照会します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() -INTERVAL 20 SECOND, NOW())` 20 秒以内に最新のデータを照会します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() -INTERVAL 20 SECOND, NOW())` 20秒以内に最新のデータを照会します。 指定するタイムスタンプまたは間隔は、現在の時刻より早すぎたり遅すぎたりしないようにしてください。また、 `NOW()`はデフォルトで秒精度となります。より高い精度を実現するには、パラメータを追加することができます。例えば、 `NOW(3)`ではミリ秒精度となります。詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_now)を参照してください。 -期限切れのデータはTiDBで[ガベージコレクション](/garbage-collection-overview.md)リサイクルされ、クリアされるまでの短い期間保持されます。この期間は[GC の有効期間 (デフォルト 10 分)](/system-variables.md#tidb_gc_life_time-new-in-v50)呼ばれます。GCが開始されると、現在の時刻からこの期間を差し引いた値が**GCセーフポイント**として使用されます。GCセーフポイントより前にデータを読み取ろうとすると、TiDBは次のエラーを報告します。 +期限切れのデータはTiDBで[ガベージコレクション](/garbage-collection-overview.md)リサイクルされ、クリアされるまでの短い期間保持されます。この期間は[GC の有効期間 (デフォルト 10分)](/system-variables.md#tidb_gc_life_time-new-in-v50)呼ばれます。GCが開始されると、現在の時刻からこの期間を差し引いた値が**GCセーフポイント**として使用されます。GCセーフポイントより前にデータを読み取ろうとすると、TiDBは次のエラーを報告します。 ``` ERROR 9006 (HY000): GC life time is shorter than transaction duration... @@ -373,7 +373,7 @@ The latest book price (after the transaction commit): 150
-たとえば、次の`AS OF TIMESTAMP`ステートメントを使用して、進行中のトランザクションを読み取り専用モードに切り替え、5 秒前の履歴データを読み取ることができます。 +たとえば、次の`AS OF TIMESTAMP`ステートメントを使用して、進行中のトランザクションを読み取り専用モードに切り替え、5秒前の履歴データを読み取ることができます。 ```sql SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() - INTERVAL 5 SECOND; @@ -458,7 +458,7 @@ public class BookDAO { SET @@tidb_read_staleness="-5"; ``` -たとえば、値が`-5`に設定され、TiKV またはTiFlash に対応する履歴データがある場合、TiDB は 5 秒の時間範囲内で可能な限り新しいタイムスタンプを選択します。 +たとえば、値が`-5`に設定され、TiKV またはTiFlash に対応する履歴データがある場合、TiDB は 5秒の時間範囲内で可能な限り新しいタイムスタンプを選択します。 セッションでステイル読み取りを無効にします。 diff --git a/develop/dev-guide-use-subqueries.md b/develop/dev-guide-use-subqueries.md index 1c58e799d8b90..128b1e9b92a47 100644 --- a/develop/dev-guide-use-subqueries.md +++ b/develop/dev-guide-use-subqueries.md @@ -16,7 +16,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-subqueries/','/ja/tidbcloud/dev-guide-u ## サブクエリステートメント {#subquery-statement} -ほとんどの場合、サブクエリには次の 5 つの種類があります。 +ほとんどの場合、サブクエリには次の5つの種類があります。 - スカラーサブクエリ (例: `SELECT (SELECT s1 FROM t2) FROM t1` )。 - 派生テーブル (例: `SELECT t1.s1 FROM (SELECT s1 FROM t2) t1` )。 @@ -32,7 +32,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-subqueries/','/ja/tidbcloud/dev-guide-u ### 自己完結型サブクエリ {#self-contained-subquery} -サブクエリを比較演算子 ( `>` 、 `>=` 、 `<` 、 `<=` 、 `=` 、または`! =` ) のオペランドとして使用する自己完結型サブクエリの場合、内部サブクエリは 1 回だけクエリを実行し、実行計画 フェーズで TiDB によって定数として書き換えられます。 +サブクエリを比較演算子 ( `>` 、 `>=` 、 `<` 、 `<=` 、 `=` 、または`! =` ) のオペランドとして使用する自己完結型サブクエリの場合、内部サブクエリは 1回だけクエリを実行し、実行計画 フェーズで TiDB によって定数として書き換えられます。 たとえば、年齢が平均年齢より大きい`authors`のテーブル内の著者を照会するには、サブクエリを比較演算子のオペランドとして使用できます。 diff --git a/develop/dev-guide-use-temporary-tables.md b/develop/dev-guide-use-temporary-tables.md index 916394a56c62b..55d81cc1ec1bf 100644 --- a/develop/dev-guide-use-temporary-tables.md +++ b/develop/dev-guide-use-temporary-tables.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-temporary-tables/','/ja/tidbcloud/dev-g [書店](/develop/dev-guide-bookshop-schema-design.md)アプリケーションにおける最年長の著者について何かを知りたい場合は、最年長の著者のリストを使用する複数のクエリを記述する場合があります。 -たとえば、次のステートメントを使用して、 `authors`テーブルから上位 50 人の最年長著者を取得できます。 +たとえば、次のステートメントを使用して、 `authors`テーブルから上位 50人の最年長著者を取得できます。 ```sql SELECT a.id, a.name, (IFNULL(a.death_year, YEAR(NOW())) - a.birth_year) AS age @@ -46,7 +46,7 @@ LIMIT 50; ### 一時テーブルの種類 {#types-of-temporary-tables} -TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2 種類に分かれています。 +TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2種類に分かれています。 - ローカル一時テーブルの場合、テーブル定義とテーブル内のデータは現在のセッションでのみ参照可能です。このタイプは、セッション中の中間データを一時的に保存するのに適しています。 - グローバル一時テーブルの場合、テーブル定義はTiDBクラスタ全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 diff --git a/develop/dev-guide-use-views.md b/develop/dev-guide-use-views.md index b93b015c346ed..beb2e8df6bed6 100644 --- a/develop/dev-guide-use-views.md +++ b/develop/dev-guide-use-views.md @@ -49,7 +49,7 @@ TiDB がビューをクエリする場合、ビューに関連付けられた`SE ## ビューの更新 {#update-views} -現在、TiDB のビューは`ALTER VIEW view_name AS query;`をサポートしていませんが、次の 2 つの方法でビューを「更新」できます。 +現在、TiDB のビューは`ALTER VIEW view_name AS query;`をサポートしていませんが、次の2つの方法でビューを「更新」できます。 - `DROP VIEW view_name;`ステートメントで古いビューを削除し、 `CREATE VIEW view_name AS query;`ステートメントで新しいビューを作成してビューを更新します。 - 同じ名前の既存のビューを上書きするには、 `CREATE OR REPLACE VIEW view_name AS query;`ステートメントを使用します。 diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index bba397e973335..c9b4621acb250 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -54,7 +54,7 @@ OLTP (オンライン トランザクション処理) シナリオの場合、 > **Note:** > -> デフォルトの MySQL Connector/J 実装では、 `addBatch()`を使用してバッチに追加された SQL ステートメントの送信時間は`executeBatch()`が呼び出されるまで遅延されますが、実際のネットワーク転送中はステートメントは 1 つずつ送信されます。そのため、この方法では通常、通信オーバーヘッドは削減されません。 +> デフォルトの MySQL Connector/J 実装では、 `addBatch()`を使用してバッチに追加された SQL ステートメントの送信時間は`executeBatch()`が呼び出されるまで遅延されますが、実際のネットワーク転送中はステートメントは 1つずつ送信されます。そのため、この方法では通常、通信オーバーヘッドは削減されません。 > > ネットワーク転送をバッチ処理する場合は、JDBC 接続パラメータで`rewriteBatchedStatements = true`を構成する必要があります。詳細なパラメータ設定については、[バッチ関連パラメータ](#batch-related-parameters)を参照してください。 @@ -132,7 +132,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 #### バッチ関連パラメータ {#batch-related-parameters} -バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`を設定することをお勧めします。 `addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1 つずつ送信します。例: +バッチ書き込みを処理する際は、 `rewriteBatchedStatements=true`を設定することをお勧めします。 `addBatch()`または`executeBatch()`を使用した後でも、JDBC はデフォルトでは SQL を 1つずつ送信します。例: ```java pstmt = prepare("insert into t (a) values(?)"); @@ -158,7 +158,7 @@ insert into t(a) values(12); insert into t(a) values(10),(11),(12); ``` -`INSERT`ステートメントの書き換えは、複数の「values」キーワードの後の値を連結して 1 つの SQL ステートメントにするものであることに注意してください。 `INSERT`ステートメントに他の違いがある場合、書き換えることはできません。たとえば、次のようになります。 +`INSERT`ステートメントの書き換えは、複数の「values」キーワードの後の値を連結して 1つの SQL ステートメントにするものであることに注意してください。 `INSERT`ステートメントに他の違いがある場合、書き換えることはできません。たとえば、次のようになります。 ```sql insert into t (a) values (10) on duplicate key update a = 10; @@ -166,7 +166,7 @@ insert into t (a) values (11) on duplicate key update a = 11; insert into t (a) values (12) on duplicate key update a = 12; ``` -上記の`INSERT`文は 1 つの文に書き換えることはできません。しかし、3 つの文を次のように変更すると次のようになります。 +上記の`INSERT`文は 1つの文に書き換えることはできません。しかし、3つの文を次のように変更すると次のようになります。 ```sql insert into t (a) values (10) on duplicate key update a = values(a); @@ -174,7 +174,7 @@ insert into t (a) values (11) on duplicate key update a = values(a); insert into t (a) values (12) on duplicate key update a = values(a); ``` -すると、書き換え要件を満たします。上記の`INSERT`文は、次の 1 つの文に書き換えられます。 +すると、書き換え要件を満たします。上記の`INSERT`文は、次の1つの文に書き換えられます。 ```sql insert into t (a) values (10), (11), (12) on duplicate key update a = values(a); @@ -204,11 +204,11 @@ update t set a = 10 where id = 1; update t set a = 11 where id = 2; update t set TiDBは、以下のMySQL互換のタイムアウト制御パラメータを提供します。 -- `wait_timeout` : Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4 以降では、 `wait_timeout`のデフォルト値は`28800`秒、つまり 8 時間です。TiDB バージョンが v5.4 より前の場合、デフォルト値は`0`で、タイムアウトは無制限です。 +- `wait_timeout` : Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4 以降では、 `wait_timeout`のデフォルト値は`28800`秒、つまり 8時間です。TiDB バージョンが v5.4 より前の場合、デフォルト値は`0`で、タイムアウトは無制限です。 - `interactive_timeout` : Javaアプリケーションへの接続における対話型アイドルタイムアウトを制御します。デフォルト値は8時間です。 - `max_execution_time` : 接続における SQL 実行のタイムアウトを制御します。これは`SELECT`ステートメント ( `SELECT ... FOR UPDATE`を含む) にのみ有効です。デフォルト値は`0`で、接続が無限にビジー状態になることを許可します。つまり、SQL ステートメントが無限に長い時間実行されます。 -しかし、実際の本番環境では、アイドル状態の接続や実行時間が長すぎる SQL ステートメントは、データベースやアプリケーションに悪影響を及ぼします。アイドル状態の接続や実行時間が長すぎる SQL ステートメントを回避するには、アプリケーションの接続文字列で次の 2 つのパラメータを設定できます。たとえば、 `sessionVariables=wait_timeout=3600` (1 時間) と`sessionVariables=max_execution_time=300000` (5 分) を設定します。 +しかし、実際の本番環境では、アイドル状態の接続や実行時間が長すぎる SQL ステートメントは、データベースやアプリケーションに悪影響を及ぼします。アイドル状態の接続や実行時間が長すぎる SQL ステートメントを回避するには、アプリケーションの接続文字列で次の2つのパラメータを設定できます。たとえば、 `sessionVariables=wait_timeout=3600` (1時間) と`sessionVariables=max_execution_time=300000` (5分) を設定します。 #### 一般的なJDBC接続文字列パラメータ {#typical-jdbc-connection-string-parameters} @@ -253,9 +253,9 @@ hikari: - `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 -- `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 -- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 -- `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2 分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 +- `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 +- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 +- `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 ### プローブ構成 {#probe-configuration} @@ -349,11 +349,11 @@ Cursor queryAllPost(); ### `ExecutorType` {#executortype} -`ExecutorType`の間に { `openSession` } を選択できます。MyBatis は 3 種類の実行エンジンをサポートしています。 +`ExecutorType`の間に { `openSession` } を選択できます。MyBatis は 3種類の実行エンジンをサポートしています。 - Simple: プリペアドステートメントは、実行ごとにJDBCに呼び出されます（JDBC構成項目`cachePrepStmts`が有効になっている場合、繰り返し実行されるプリペアドステートメントは再利用されます）。 - Reuse: プリペアドステートメントは`executor`にキャッシュされるため、JDBC `cachePrepStmts`を使用せずにプリペアドステートメントの重複呼び出しを減らすことができます。 -- Batch: 各更新操作 ( `INSERT` / `DELETE` / `UPDATE` ) は、まずバッチに追加され、トランザクションがコミットされるか`SELECT`クエリが実行されるまで実行されます。JDBCレイヤーで`rewriteBatchStatements`が有効になっている場合は、ステートメントの書き換えが試みられます。そうでない場合は、ステートメントは 1 つずつ送信されます。 +- Batch: 各更新操作 ( `INSERT` / `DELETE` / `UPDATE` ) は、まずバッチに追加され、トランザクションがコミットされるか`SELECT`クエリが実行されるまで実行されます。JDBCレイヤーで`rewriteBatchStatements`が有効になっている場合は、ステートメントの書き換えが試みられます。そうでない場合は、ステートメントは 1つずつ送信されます。 通常、 `ExecutorType`のデフォルト値は`Simple`です。 `ExecutorType`を呼び出すときは`openSession` } を変更する必要があります。バッチ実行の場合、トランザクション内で`UPDATE`または`INSERT`ステートメントの実行は非常に高速ですが、データの読み取りやトランザクションのコミットは遅くなる場合があります。これは正常な動作ですので、SQL クエリの遅延をトラブルシューティングする際には、この点に注意してください。 diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index 077da0ebae6ee..cb336eeedc76f 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -19,7 +19,7 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン 次のサンプル シナリオに基づいて DM クラスターを展開するとします。 -2 つの DM ワーカー ノードと 3 つの DM マスター ノードが 5 台のサーバーに展開されます。 +2つの DM ワーカー ノードと 3つの DM マスター ノードが 5台のサーバーに展開されます。 各ノードのアドレスは次のとおりです。 @@ -37,9 +37,9 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン > > - 単一のサーバーに複数の DM マスターまたは DM ワーカー インスタンスを展開する場合、各インスタンスのポートと作業ディレクトリは一意である必要があります。 > -> - DM クラスターの高可用性を確保する必要がない場合は、DM マスター ノードを 1 つだけデプロイし、デプロイされる DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 +> - DM クラスターの高可用性を確保する必要がない場合は、DM マスター ノードを 1つだけデプロイし、デプロイされる DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 > -> - DM クラスターの高可用性を確保するには、3 つの DM マスター ノードを展開することをお勧めします。また、展開する DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカー ノードの数は、アップストリーム インスタンスの数より 2 つ多くなります)。 +> - DM クラスターの高可用性を確保するには、3つの DM マスター ノードを展開することをお勧めします。また、展開する DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカー ノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 > - DM マスター ノード間の`8291`ポートは相互接続されています。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 600183fd32416..e49f2e1b785be 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -72,7 +72,7 @@ source /home/tidb/.bash_profile 完全な構成テンプレートについては、「 [TiUP構成パラメータ テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) . 構成ファイルを作成する」 `topology.yaml`を参照してください。その他の複合シナリオでは、テンプレートに従って必要に応じて構成ファイルを編集します。 -3 つの DM マスター、3 つの DM ワーカー、および 1 つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 +3つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 ```yaml --- @@ -105,9 +105,9 @@ alertmanager_servers: > **Note:** > -> - DM クラスターの高可用性を確保する必要がない場合は、DM マスター ノードを 1 つだけデプロイし、デプロイされた DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 +> - DM クラスターの高可用性を確保する必要がない場合は、DM マスター ノードを 1つだけデプロイし、デプロイされた DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 > -> - DM クラスターの高可用性を確保するには、3 つの DM マスター ノードを展開することをお勧めします。また、展開する DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカー ノードの数は、アップストリーム インスタンスの数より 2 つ多くなります)。 +> - DM クラスターの高可用性を確保するには、3つの DM マスター ノードを展開することをお勧めします。また、展開する DM ワーカー ノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカー ノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > > - グローバルに有効にする必要があるパラメータについては、構成ファイルの`server_configs`セクションで対応するコンポーネントのこれらのパラメータを構成します。 > diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index 64afed319f48f..c41698ddc74fc 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -47,7 +47,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 コマンド`tiup dm template > topology.yaml`を使用すると、構成ファイル テンプレートをすばやく生成できます。 -3 つの DM マスター、3 つの DM ワーカー、および 1 つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 +3つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 ```yaml # The global variables apply to all other components in the configuration. If one specific value is missing in the component instance, the corresponding global variable serves as the default value. diff --git a/dm/dm-arch.md b/dm/dm-arch.md index 1a007a676b81f..30a0cae377059 100644 --- a/dm/dm-arch.md +++ b/dm/dm-arch.md @@ -7,7 +7,7 @@ summary: データ移行（DM）アーキテクチャは、DMマスター、DM このドキュメントでは、データ移行 (DM) のアーキテクチャについて説明します。 -DM は、DM マスター、DM ワーカー、dmctl の 3 つのコンポーネントで構成されます。 +DM は、DM マスター、DM ワーカー、dmctl の 3つのコンポーネントで構成されます。 ![Data Migration architecture](/media/dm/dm-architecture-2.0.png) @@ -49,7 +49,7 @@ dmctl は、DM クラスターを制御するために使用されるコマン 複数のDMマスターノードをデプロイする場合、すべてのDMマスターノードは組み込みのetcdを使用してクラスタを形成します。DMマスタークラスタは、クラスタノード情報やタスク設定などのメタデータを保存するために使用されます。etcdによって選出されたリーダーノードは、クラスタ管理やデータ移行タスク管理などのサービスを提供します。したがって、利用可能なDMマスターノードの数がデプロイされたノードの半数を超えても、DMクラスタは正常にサービスを提供できます。 -デプロイされた DM ワーカーノードの数が上流の MySQL/MariaDB ノードの数を超える場合、超過した DM ワーカーノードはデフォルトでアイドル状態になります。DM ワーカーノードがオフラインになったり、DM マスターリーダーから分離したりした場合、DM マスターは元の DM ワーカーノードのデータ移行タスクを他のアイドル状態の DM ワーカーノードに自動的にスケジュールします。（DM ワーカーノードが分離されると、そのノード上のデータ移行タスクが自動的に停止されます。）利用可能なアイドル状態の DM ワーカーノードがない場合、元の DM ワーカーのデータ移行タスクは、1 つの DM ワーカーノードがアイドル状態になるまで一時的に停止され、その後タスクが自動的に再開されます。 +デプロイされた DM ワーカーノードの数が上流の MySQL/MariaDB ノードの数を超える場合、超過した DM ワーカーノードはデフォルトでアイドル状態になります。DM ワーカーノードがオフラインになったり、DM マスターリーダーから分離したりした場合、DM マスターは元の DM ワーカーノードのデータ移行タスクを他のアイドル状態の DM ワーカーノードに自動的にスケジュールします。（DM ワーカーノードが分離されると、そのノード上のデータ移行タスクが自動的に停止されます。）利用可能なアイドル状態の DM ワーカーノードがない場合、元の DM ワーカーのデータ移行タスクは、1つの DM ワーカーノードがアイドル状態になるまで一時的に停止され、その後タスクが自動的に再開されます。 > **Note:** > diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 6a83a98fc5986..cb0e8365825db 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -145,8 +145,8 @@ MySQLシャードの移行とマージを行う際、上流のシャードの種 | シナリオ | DMマスターの展開 | DMワーカーの展開 | | :-------------------------------------------------------------------- | :----------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------- | -|
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDMマスターノードをデプロイ | 上流データソースの数に応じて、1～N 台の DM ワーカーノードをデプロイ。通常は 1 台の DM ワーカーノードを推奨します。 | -|
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3 つの DM マスター ノードを展開することをお勧めします。 | データソースまたは移行タスクの数に応じて、DMワーカーノードをデプロイ。稼働中のDMワーカーノードに加えて、アイドル状態のDMワーカーノードを1～3台展開することをお勧めします。 | +|
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDMマスターノードをデプロイ | 上流データソースの数に応じて、1～N 台の DM ワーカーノードをデプロイ。通常は 1台の DM ワーカーノードを推奨します。 | +|
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3つの DM マスター ノードを展開することをお勧めします。 | データソースまたは移行タスクの数に応じて、DMワーカーノードをデプロイ。稼働中のDMワーカーノードに加えて、アイドル状態のDMワーカーノードを1～3台展開することをお勧めします。 | | 長期データ複製 | DMマスターノードは3台必要です。クラウド上にDMマスターノードをデプロイする場合は、異なるアベイラビリティゾーン（AZ）にデプロイするようにしてください。 | データソース数や移行タスク数に応じて、DMワーカーノードをデプロイ。実際に必要なDMワーカーノード数の1.5～2倍を配置する必要があります。 | #### アップストリームデータソースを選択して構成する {#choose-and-configure-the-upstream-data-source} diff --git a/dm/dm-binlog-event-filter.md b/dm/dm-binlog-event-filter.md index 06a23e71a4ce3..f04984152ae57 100644 --- a/dm/dm-binlog-event-filter.md +++ b/dm/dm-binlog-event-filter.md @@ -101,7 +101,7 @@ DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィ ### すべてのシャーディング削除操作をフィルタリングする {#filter-all-sharding-deletion-operations} -すべての削除操作をフィルタリングするには、次の 2 つのフィルタリング ルールを構成します。 +すべての削除操作をフィルタリングするには、次の2つのフィルタリング ルールを構成します。 - `filter-table-rule`は、 `test_*`.`t_*`パターンに一致するすべてのテーブルの`TRUNCATE TABLE` 、 `DROP TABLE` 、および`DELETE STATEMENT`操作を除外します。 - `filter-schema-rule`は`test_*`パターンに一致するすべてのスキーマの`DROP DATABASE`操作を除外します。 @@ -121,7 +121,7 @@ filters: ### シャーディングDMLステートメントのみを移行する {#only-migrate-sharding-dml-statements} -シャーディング DML ステートメントのみを移行するには、次の 2 つのフィルタリング ルールを構成します。 +シャーディング DML ステートメントのみを移行するには、次の2つのフィルタリング ルールを構成します。 - `do-table-rule`は、 `test_*`.`t_*`パターンに一致するすべてのテーブルの`CREATE TABLE` 、 `INSERT` 、 `UPDATE` 、および`DELETE`ステートメントのみを移行します。 - `do-schema-rule`は、 `test_*`パターンに一致するすべてのスキーマの`CREATE DATABASE`のステートメントのみを移行します。 diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index a98c989e2abe6..a6f51a8855fbb 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -199,7 +199,7 @@ Flags: 検証ステータスにエラー行を表示したくない場合、またはエラー行を解決済みとしてマークしたい場合は、 `validation show-error`コマンドを使用してエラー行 ID を見つけ、その後、指定されたエラー ID を使用して処理することができます。 -dmctl は 3 つのエラー処理コマンドを提供します。 +dmctl は 3つのエラー処理コマンドを提供します。 - `clear-error` : エラー行をクリアします。`show-error`コマンドを実行すると、エラー行は表示されなくなります。 diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 3865b38a0f8f0..91e6de43f3447 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -45,7 +45,7 @@ summary: DM を使用する際のエラー システムと一般的なエラー - `scope` : エラー範囲。 - エラーが発生したときに、 DM オブジェクトのスコープとソースをマークするために使用されます。 `scope`は、 `not-set` 、 `upstream` 、 `downstream` 、 `internal` 4 つのタイプが含まれます。 + エラーが発生したときに、 DM オブジェクトのスコープとソースをマークするために使用されます。 `scope`は、 `not-set` 、 `upstream` 、 `downstream` 、 `internal` 4つのタイプが含まれます。 エラーのロジックが上流データベースと下流データベース間のリクエストに直接関係する場合、スコープは`upstream`または`downstream`に設定されます。それ以外の場合、現在は`internal`に設定されています。 @@ -132,7 +132,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 #### 理由 {#reason} -リレー ログ プルまたは増分レプリケーションの DM プロセス中に、アップストリームbinlogファイルのサイズが**4 GB**を超えると、この 2 つのエラーが発生する可能性があります。 +リレー ログ プルまたは増分レプリケーションの DM プロセス中に、アップストリームbinlogファイルのサイズが**4 GB**を超えると、この2つのエラーが発生する可能性があります。 **原因：**リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLではbinlogの位置を`uint32`で保存しています。そのため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 9432a1bebc1dc..ff2c49c01ee8d 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -61,7 +61,7 @@ TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを 最後の`rename ghost_table to origin table`ステップでは、DM はメモリ内の DDL 情報を読み取り、元のテーブルの DDL に復元します。 -ただし、メモリ内の DDL 情報は、次の 2 つの方法のいずれかで取得されます。 +ただし、メモリ内の DDL 情報は、次の2つの方法のいずれかで取得されます。 - DM [`alter ghost_table`操作中に gh-ost テーブルを処理する](/dm/feature-online-ddl.md#online-schema-change-gh-ost)および`ghost_table`の DDL 情報を記録します。 - DM ワーカーが再起動されてタスクが開始されると、DM は`dm_meta.{task_name}_onlineddl`から DDL を読み取ります。 @@ -146,7 +146,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために 構成項目`block-allow-list`と`table-route`を確認します。 - `block-allow-list`の下にある上流のデータベースとテーブルの名前を設定する必要があります。`do-tables`の前に「~」を追加すると、正規表現を使用して名前を一致させることができます。 -- `table-route` 、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_parttern_[0-63]` `table_parttern_0`から`table_pattern_6`までの 7 つのテーブルのみに一致します。 +- `table-route` 、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_parttern_[0-63]` `table_parttern_0`から`table_pattern_6`までの 7つのテーブルのみに一致します。 ## DM がアップストリームからレプリケートしていないのに、 `replicate lag`モニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-replicate-lag-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} @@ -203,7 +203,7 @@ DM-worker のログファイルを確認し、 `change count`を含む行を探 DM v2.0.1 以前のバージョンでは、完全インポートが完了する前に DM が再起動すると、上流のデータソースと DM ワーカーノード間のバインディングが変更される可能性があります。例えば、ダンプユニットの中間データが DM ワーカーノード A にあるにもかかわらず、ロードユニットが DM ワーカーノード B で実行されている場合、操作が失敗する可能性があります。 -この問題に対する解決策は次の 2 つです。 +この問題に対する解決策は次の2つです。 - データ量が少ない (1 TB 未満) 場合、またはタスクがシャーディングされたテーブルをマージする場合は、次の手順を実行します。 diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index 56e40b117a276..7c3412486745d 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -50,7 +50,7 @@ Binlogログレプリケーション処理ユニットは、DM-workerにおい ### ダンプ処理装置/ダンプユニット {#dump-processing-unit-dump-unit} -ダンプ処理単位は、DM-worker において上流からのすべてのデータをエクスポートするために使用される処理単位です。各サブタスクは 1 つのダンプ処理単位に対応します。 +ダンプ処理単位は、DM-worker において上流からのすべてのデータをエクスポートするために使用される処理単位です。各サブタスクは 1つのダンプ処理単位に対応します。 ## G {#g} @@ -82,7 +82,7 @@ TiDB データ移行ツールを使用して、アップストリーム デー ### リレー処理ユニット {#relay-processing-unit} -リレー処理ユニットは、DM-worker において上流からbinlogファイルを取得し、リレーログにデータを書き込むために使用される処理ユニットです。各 DM-worker インスタンスには、リレー処理ユニットが 1 つだけ存在します。 +リレー処理ユニットは、DM-worker において上流からbinlogファイルを取得し、リレーログにデータを書き込むために使用される処理ユニットです。各 DM-worker インスタンスには、リレー処理ユニットが 1つだけ存在します。 ### 複製/レプリケーション {#replicate-replication} @@ -101,7 +101,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 - タスク構成ファイルの`safe-mode`パラメータが`true`に設定されている場合、セーフ モードは有効なままになります。 - シャードマージのシナリオでは、すべてのシャードテーブルで DDL ステートメントが複製される前は、セーフ モードが有効なままになります。 - 完全移行タスクのダンプ処理単位に引数`--consistency none`が設定されている場合、エクスポート開始時のbinlogの変更がエクスポートされたデータに影響を与えるかどうかを判断できません。そのため、これらのbinlogの変更の増分レプリケーションではセーフモードが有効なままになります。 -- タスクがエラーによって一時停止され、その後再開された場合、一部のデータに対する操作が 2 回実行される可能性があります。 +- タスクがエラーによって一時停止され、その後再開された場合、一部のデータに対する操作が 2回実行される可能性があります。 ### シャードDDL {#shard-ddl} @@ -117,7 +117,7 @@ TiDB データ移行ツールを使用して、上流データベースの**増 ### サブタスク {#subtask} -サブタスクは、各 DM ワーカーインスタンスで実行されるデータ移行タスクの一部です。タスク構成によっては、1 つのデータ移行タスクに 1 つのサブタスクが含まれる場合もあれば、複数のサブタスクが含まれる場合もあります。 +サブタスクは、各 DM ワーカーインスタンスで実行されるデータ移行タスクの一部です。タスク構成によっては、1つのデータ移行タスクに 1つのサブタスクが含まれる場合もあれば、複数のサブタスクが含まれる場合もあります。 ### サブタスクのステータス {#subtask-status} diff --git a/dm/dm-handle-alerts.md b/dm/dm-handle-alerts.md index 808a9c6098358..9c866fc82b429 100644 --- a/dm/dm-handle-alerts.md +++ b/dm/dm-handle-alerts.md @@ -50,7 +50,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - シャーディング DDL 操作が 1 時間以上保留されている場合、このアラートがトリガーされます。 + シャーディング DDL 操作が 1時間以上保留されている場合、このアラートがトリガーされます。 - 解決： @@ -62,7 +62,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - DM ワーカーのサブタスクが 20 分以上`Paused`状態にある場合、アラートがトリガーされます。 + DM ワーカーのサブタスクが 20分以上`Paused`状態にある場合、アラートがトリガーされます。 - 解決： @@ -74,7 +74,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - リレー ログ処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に回復可能なエラー (例: ネットワークの問題) が複数発生した場合 (例: 2 分間に 3 回以上)、このアラートがトリガーされます。 + リレー ログ処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に回復可能なエラー (例: ネットワークの問題) が複数発生した場合 (例: 2分間に 3回以上)、このアラートがトリガーされます。 - 解決： @@ -128,7 +128,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレー ログ処理ユニットによってプルされた最新のbinlogファイルの数を 10 分間で 1**以上**超過すると、アラートがトリガーされます。 + 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレー ログ処理ユニットによってプルされた最新のbinlogファイルの数を 10分間で 1**以上**超過すると、アラートがトリガーされます。 - 解決： @@ -140,7 +140,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - ダンプ処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に (例: 2 分間に 3 回以上) 回復可能なエラー (例: ネットワークの問題) が複数発生した場合、このアラートがトリガーされます。 + ダンプ処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に (例: 2分間に 3回以上) 回復可能なエラー (例: ネットワークの問題) が複数発生した場合、このアラートがトリガーされます。 - 解決： @@ -150,7 +150,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - ロード処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に (例: 2 分間に 3 回以上) 回復可能なエラー (例: ネットワークの問題) が複数発生した場合、このアラートがトリガーされます。 + ロード処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に (例: 2分間に 3回以上) 回復可能なエラー (例: ネットワークの問題) が複数発生した場合、このアラートがトリガーされます。 - 解決： @@ -162,7 +162,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - binlogレプリケーション処理ユニットで自動回復不可能なエラー (binlogファイルが見つからないなど) が発生した場合、または短時間 (2 分間に 3 回以上など) に複数の回復可能なエラー (ネットワークの問題など) が発生した場合、このアラートがトリガーされます。 + binlogレプリケーション処理ユニットで自動回復不可能なエラー (binlogファイルが見つからないなど) が発生した場合、または短時間 (2分間に 3回以上など) に複数の回復可能なエラー (ネットワークの問題など) が発生した場合、このアラートがトリガーされます。 - 解決： @@ -172,7 +172,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレー ログ処理装置で処理された最新のbinlogファイルの数を 10 分間で 1**以上**超えると、アラートがトリガーされます。 + 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレー ログ処理装置で処理された最新のbinlogファイルの数を 10分間で 1**以上**超えると、アラートがトリガーされます。 - 解決： @@ -182,7 +182,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - 現在のリレーログ処理単位内のbinlogファイルの数が、binlogログレプリケーション処理単位で処理された最新のbinlogファイルの数より 10 分間に 1**以上**超過すると、アラートがトリガーされます。 + 現在のリレーログ処理単位内のbinlogファイルの数が、binlogログレプリケーション処理単位で処理された最新のbinlogファイルの数より 10分間に 1**以上**超過すると、アラートがトリガーされます。 - 解決： diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index e0b05a665fc4d..8cfe6e7136142 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -29,7 +29,7 @@ summary: DM に存在する可能性のある一般的なパフォーマンス - 単一データセンター内でのデータ移行では、 binlogデータの読み取りはパフォーマンスのボトルネックにはなりません。値が`read binlog event duration`に設定されている場合は、DM-workerとMySQL/MariaDB間のネットワーク接続を確認してください。 -- 地理的に分散された環境でのデータ移行では、DM ワーカーと MySQL/MariaDB を 1 つのデータ センターにデプロイし、TiDB クラスターをターゲット データ センターにデプロイするようにしてください。 +- 地理的に分散された環境でのデータ移行では、DM ワーカーと MySQL/MariaDB を 1つのデータ センターにデプロイし、TiDB クラスターをターゲット データ センターにデプロイするようにしてください。 アップストリーム データベースからbinlogデータを読み取るプロセスには、次のサブプロセスが含まれます。 diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md index f9bb0e3ac9c73..fd1db846d6e88 100644 --- a/dm/dm-manage-schema.md +++ b/dm/dm-manage-schema.md @@ -28,7 +28,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを - 現在 DM (スキーマ トラッカーコンポーネント) で管理されているテーブル スキーマ`schema-I`として識別されます。 - ダウンストリーム TiDB クラスター内のテーブル スキーマ`schema-D`として識別)。 -ほとんどの場合、前述の 4 つのテーブル スキーマは一貫しています。 +ほとんどの場合、前述の4つのテーブル スキーマは一貫しています。 上流データベースがテーブルスキーマを変更するDDL操作を実行すると、 `schema-U`が変更されます。このDDL操作を内部スキーマトラッカーコンポーネントと下流TiDBクラスタに適用することで、DMは`schema-I`と`schema-D`を順序正しく更新し、 `schema-U`との整合性を維持します。これにより、DMは`schema-B`テーブルスキーマに対応するbinlogイベントを正常に処理できます。つまり、DDL操作`schema-B`正常に移行された後も、 `schema-U` `schema-I`および`schema-D`整合性を維持します。 @@ -207,7 +207,7 @@ Global Flags: > **Note:** > -> DM で管理されているテーブル スキーマが削除された後、このテーブルに関連する DDL/DML ステートメントをダウンストリームに移行する必要がある場合、DM は次の 3 つのソースからテーブル スキーマを順番に取得しようとします。 +> DM で管理されているテーブル スキーマが削除された後、このテーブルに関連する DDL/DML ステートメントをダウンストリームに移行する必要がある場合、DM は次の3つのソースからテーブル スキーマを順番に取得しようとします。 > > - チェックポイントテーブルの`table_info`フィールド > - 楽観的シャーディングDDLのメタ情報 diff --git a/dm/dm-query-status.md b/dm/dm-query-status.md index 4fa4a4f04883e..5ae49362347bb 100644 --- a/dm/dm-query-status.md +++ b/dm/dm-query-status.md @@ -60,9 +60,9 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた | タスク内のサブタスクのステータス | タスクのステータス | | :----------------------------------------------------------- | :--------------------------------------------- | -| 1 つのサブタスクが`paused`状態にあり、エラー情報が返されます。 | `Error - Some error occurred in subtask` | -| 同期フェーズの 1 つのサブタスクは`Running`状態ですが`Paused` `Stopped` `Error` 。 | `Error - Relay status is Error/Paused/Stopped` | -| 1 つのサブタスクが`Paused`状態にあり、エラー情報は返されません。 | `Paused` | +| 1つのサブタスクが`paused`状態にあり、エラー情報が返されます。 | `Error - Some error occurred in subtask` | +| 同期フェーズの 1つのサブタスクは`Running`状態ですが`Paused` `Stopped` `Error` 。 | `Error - Relay status is Error/Paused/Stopped` | +| 1つのサブタスクが`Paused`状態にあり、エラー情報は返されません。 | `Paused` | | すべてのサブタスクは`New`状態にあります。 | `New` | | すべてのサブタスクは`Finished`状態にあります。 | `Finished` | | すべてのサブタスクは`Stopped`状態にあります。 | `Stopped` | @@ -245,8 +245,8 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - `unsynced` : このシャーディングDDL文を実行していない上流テーブル。上流テーブルのいずれかがレプリケーションを完了していない場合、 `blockingDDLs`が空になります。 - `synced` : 増分レプリケーションがアップストリームに追いつき、アップストリームと同じbinlog位置にあるかどうか。セーブポイントは`Sync`グラウンドでリアルタイムに更新されないため、 `synced`のうち`false`は必ずしもレプリケーション遅延が発生することを意味するわけではありません。 - `totalRows` : このサブタスクで複製される行の合計数。 - - `totalRps` : このサブタスクで 1 秒あたりに複製される行数。 - - `recentRps` : このサブタスクで最後の 1 秒間に複製された行の数。 + - `totalRps` : このサブタスクで 1秒あたりに複製される行数。 + - `recentRps` : このサブタスクで最後の 1秒間に複製された行の数。 - `load` : `Load`処理ユニットのレプリケーション情報。 - `finishedBytes` : ロードされたバイト数。 - `totalBytes` : ロードする必要があるバイトの合計数。 diff --git a/dm/dm-replication-logic.md b/dm/dm-replication-logic.md index 10191489dace2..812625edf8c51 100644 --- a/dm/dm-replication-logic.md +++ b/dm/dm-replication-logic.md @@ -23,7 +23,7 @@ summary: DM のコア処理ユニット Sync が DML ステートメントを複 1. [圧縮機](#compactor) : 同じレコード（同じ主キーを持つ）に対する複数の操作を1つの操作に統合します。この機能は`syncer.compact`で有効になります。 2. [因果関係](#causality) : レプリケーションの同時実行性を向上させるために、異なるレコード (異なる主キーを持つ) に対して競合検出を実行します。 - 3. [合併](#merger) : 複数のbinlogイベントを 1 つの DML ステートメントにマージします`syncer.multiple-rows`によって有効になります。 + 3. [合併](#merger) : 複数のbinlogイベントを 1つの DML ステートメントにマージします`syncer.multiple-rows`によって有効になります。 4. DML をダウンストリームに実行します。 @@ -33,7 +33,7 @@ summary: DM のコア処理ユニット Sync が DML ステートメントを複 ## DML最適化ロジック {#dml-optimization-logic} -同期ユニットは、Compactor、Causality、Merger の 3 つのステップを通じて DML 最適化ロジックを実装します。 +同期ユニットは、Compactor、Causality、Merger の 3つのステップを通じて DML 最適化ロジックを実装します。 ### 圧縮機 {#compactor} @@ -152,4 +152,4 @@ DML実行とチェックポイント更新の操作はアトミックではな ### 正確に1回だけ処理 {#exactly-once-processing} -現在、DM は結果整合性のみを保証しており、「正確に 1 回の処理」や「トランザクションの元の順序の維持」はサポートしていません。 +現在、DM は結果整合性のみを保証しており、「正確に 1回の処理」や「トランザクションの元の順序の維持」はサポートしていません。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index 8be21991f71b2..329b5628d2525 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -22,7 +22,7 @@ summary: DMセーフモードについて、その目的、動作原理、およ セーフモードでは、DMはSQL文を書き換えることでbinlogイベントの冪等性を保証します。具体的には、以下のSQL文が書き換えられます。 - `INSERT`ステートメントは`REPLACE`ステートメントに書き換えられます。 -- `UPDATE`ステートメントが分析され、更新された行の主キーまたは一意インデックスの値を取得します。次に`UPDATE`ステートメントが、次の 2 つのステップで`DELETE` + `REPLACE`ステートメントに書き換えられます。DM は、主キーまたは一意インデックスを使用して古いレコードを削除し、 `REPLACE`を使用して新しいレコードを挿入します。 +- `UPDATE`ステートメントが分析され、更新された行の主キーまたは一意インデックスの値を取得します。次に`UPDATE`ステートメントが、次の2つのステップで`DELETE` + `REPLACE`ステートメントに書き換えられます。DM は、主キーまたは一意インデックスを使用して古いレコードを削除し、 `REPLACE`を使用して新しいレコードを挿入します。 バージョン8.5.6以降、タスクセッションで`foreign_key_checks=1`を設定すると、DMは主キーまたは一意インデックス値を変更しない`DELETE` `UPDATE`ステップをスキップします。詳細については、[外部キーの処理](#foreign-key-handling-new-in-v856)キー を参照してください。 @@ -64,7 +64,7 @@ DMがチェックポイントから増分レプリケーションタスクを再 - チェックポイントに`safemode_exit_point`が含まれている場合、増分レプリケーション タスクは異常に一時停止されます。 DM がタスクを再開すると、再開するチェックポイントのbinlog位置 (**開始位置**) が`safemode_exit_point`より前になります。これは、開始位置と`safemode_exit_point`の間のbinlogイベントが下流で処理されている可能性があることを示しています。そのため、再開処理中に一部のbinlogイベントが繰り返し実行される可能性があります。したがって、セーフ モードを有効にすると、これらのbinlog位置を**安全**にすることができます。binlog位置が`safemode_exit_point`を超えると、セーフ モードが手動で有効にされない限り、DM は自動的にセーフ モードを無効にします。 -- チェックポイントに`safemode_exit_point`が含まれていない場合、次の 2 つのケースが考えられます。 +- チェックポイントに`safemode_exit_point`が含まれていない場合、次の2つのケースが考えられます。 1. これは新規タスクです。もしくは、このタスクは想定どおり一時停止されています。 2. このタスクは異常に一時停止されましたが、DM は`safemode_exit_point`を記録できませんでした。または、DM プロセスが異常終了しました。 diff --git a/dm/dm-source-configuration-file.md b/dm/dm-source-configuration-file.md index b2eec52c3d31c..41c581e9d07d6 100644 --- a/dm/dm-source-configuration-file.md +++ b/dm/dm-source-configuration-file.md @@ -140,7 +140,7 @@ from: > **Note:** > -> 自動データ消去戦略は、 [`interval`](#interval)が`0`でなく、 2 つの構成項目[`expires`](#expires)と[`remain-space`](#remain-space)のうち少なくとも 1 つが`0`でない場合にのみ有効になります。 +> 自動データ消去戦略は、 [`interval`](#interval)が`0`でなく、 2つの構成項目[`expires`](#expires)と[`remain-space`](#remain-space)のうち少なくとも 1つが`0`でない場合にのみ有効になります。 ### タスクステータスチェッカーの設定（ `checker` ） {#task-status-checker-configuration-checker} @@ -156,7 +156,7 @@ DMは定期的に現在のタスクステータスとエラーメッセージを #### `backoff-max` {#backoff-max} -- バックオフ戦略のチェック間隔の最大値は 1 秒より大きくなければなりません。 +- バックオフ戦略のチェック間隔の最大値は 1秒より大きくなければなりません。 ### Binlogイベントフィルター {#binlog-event-filter} diff --git a/dm/dm-stop-task.md b/dm/dm-stop-task.md index c54a029ee063a..782692a522640 100644 --- a/dm/dm-stop-task.md +++ b/dm/dm-stop-task.md @@ -62,4 +62,4 @@ stop-task test > `stop-task`コマンドで移行タスクを停止した後、 [`query-status`](/dm/dm-query-status.md)を実行してもタスクは表示されなくなります。ただし、このタスクのチェックポイントやその他の関連情報は`dm_meta`データベースに保持されます。 > > - 移行タスクを最初からやり直すには、 [`start-task`](/dm/dm-create-task.md)コマンドを実行するときに`--remove-meta`オプションを追加します。 -> - 移行タスクを完全に削除するには、タスク名をプレフィックスとして使用する 4 つのテーブルを`dm_meta`データベースから手動で削除します。 +> - 移行タスクを完全に削除するには、タスク名をプレフィックスとして使用する 4つのテーブルを`dm_meta`データベースから手動で削除します。 diff --git a/dm/dm-table-routing.md b/dm/dm-table-routing.md index 7506c2d01c7e3..0720cb457fb7e 100644 --- a/dm/dm-table-routing.md +++ b/dm/dm-table-routing.md @@ -9,7 +9,7 @@ TiDB Data Migration (DM) を使用してデータを移行する場合、テー > **Note:** > -> - 1 つのテーブルに対して複数の異なるルーティング ルールを構成することはサポートされていません。 +> - 1つのテーブルに対して複数の異なるルーティング ルールを構成することはサポートされていません。 > - セクション[テーブルルーティングを構成する](#configure-table-routing)の`rule-2`に示すように、 `CREATE/DROP SCHEMA xx`を移行するために使用されるスキーマの一致ルールを個別に構成する必要があります。 ## テーブルルーティングを構成する {#configure-table-routing} @@ -53,13 +53,13 @@ routes: ## 使用例 {#usage-examples} -このセクションでは、4 つの異なるシナリオでの使用例を示します。 +このセクションでは、4つの異なるシナリオでの使用例を示します。 小さなデータセットの MySQL シャードを TiDB に移行してマージする必要がある場合は、 [このチュートリアル](/migrate-small-mysql-shards-to-tidb.md)を参照してください。 ### シャーディングされたスキーマとテーブルをマージする {#merge-sharded-schemas-and-tables} -シャーディングされたスキーマとテーブルのシナリオを想定して、2 つのアップストリーム MySQL インスタンスの`test_{1,2,3...}`.`t_{1,2,3...}`テーブルをダウンストリーム TiDB インスタンスの`test`.`t`テーブルに移行します。 +シャーディングされたスキーマとテーブルのシナリオを想定して、2つのアップストリーム MySQL インスタンスの`test_{1,2,3...}`.`t_{1,2,3...}`テーブルをダウンストリーム TiDB インスタンスの`test`.`t`テーブルに移行します。 アップストリームインスタンスをダウンストリーム`test`.`t`に移行するには、次のルーティングルールを作成する必要があります。 @@ -123,7 +123,7 @@ CREATE TABLE `test`.`t` ( ); ``` -アップストリームに次の 2 つのデータ ソースがあると仮定します。 +アップストリームに次の2つのデータ ソースがあると仮定します。 データソース`mysql-01` : @@ -213,9 +213,9 @@ CREATE TABLE `test`.`t` ( ### シャードスキーマをマージする {#merge-sharded-schemas} -シャード スキーマのシナリオを想定して、2 つのアップストリーム MySQL インスタンスの`test_{1,2,3...}`.`t_{1,2,3...}`テーブルをダウンストリーム TiDB インスタンスの`test`.`t_{1,2,3...}`テーブルに移行します。 +シャード スキーマのシナリオを想定して、2つのアップストリーム MySQL インスタンスの`test_{1,2,3...}`.`t_{1,2,3...}`テーブルをダウンストリーム TiDB インスタンスの`test`.`t_{1,2,3...}`テーブルに移行します。 -アップストリーム スキーマをダウンストリーム`test`.`t_[1,2,3]`に移行するには、ルーティング ルールを 1 つだけ作成する必要があります。 +アップストリーム スキーマをダウンストリーム`test`.`t_[1,2,3]`に移行するには、ルーティング ルールを 1つだけ作成する必要があります。 ```yaml rule-1: @@ -225,7 +225,7 @@ CREATE TABLE `test`.`t` ( ### テーブルルーティングが正しくありません {#incorrect-table-routing} -次の 2 つのルーティング ルールが設定されていて、 `test_1_bak`.`t_1_bak`が`rule-1`と`rule-2`の両方に一致する場合、テーブル ルーティング設定が数値制限に違反するためエラーが報告されます。 +次の2つのルーティング ルールが設定されていて、 `test_1_bak`.`t_1_bak`が`rule-1`と`rule-2`の両方に一致する場合、テーブル ルーティング設定が数値制限に違反するためエラーが報告されます。 ```yaml rule-1: diff --git a/dm/dm-worker-configuration-file.md b/dm/dm-worker-configuration-file.md index e4d967dd48637..093d271ce21e7 100644 --- a/dm/dm-worker-configuration-file.md +++ b/dm/dm-worker-configuration-file.md @@ -62,7 +62,7 @@ cert-allowed-cn = ["dm"] #### `join` {#join} -- DM マスター構成ファイル内の 1 つ以上の[`master-addr`](/dm/dm-master-configuration-file.md#global-configuration)に対応します。 +- DM マスター構成ファイル内の 1つ以上の[`master-addr`](/dm/dm-master-configuration-file.md#global-configuration)に対応します。 #### `keepalive-ttl` {#keepalive-ttl} diff --git a/dm/dm-worker-intro.md b/dm/dm-worker-intro.md index 158478f188f07..c71f916926615 100644 --- a/dm/dm-worker-intro.md +++ b/dm/dm-worker-intro.md @@ -5,12 +5,12 @@ summary: DM-worker の機能について学びます。 # DMワーカー紹介 {#dm-worker-introduction} -DM-worker は、TiDB Data Migration (DM) のコンポーネントであり、DM-master によって割り当てられたタスクとサブタスクを実行します。フルおよび増分移行では、1 つの MySQL 互換ソースインスタンスからデータをダンプし、ダンプしたデータをターゲット TiDB クラスターにロードします。その後、レプリケーションクライアントとしてソース Binlog を読み取り、イベントを変換およびフィルタリングして、ターゲットに適用します。DM-master は、ソースとサブタスクのステータスについて DM-worker に問い合わせます。 +DM-worker は、TiDB Data Migration (DM) のコンポーネントであり、DM-master によって割り当てられたタスクとサブタスクを実行します。フルおよび増分移行では、1つの MySQL 互換ソースインスタンスからデータをダンプし、ダンプしたデータをターゲット TiDB クラスターにロードします。その後、レプリケーションクライアントとしてソース Binlog を読み取り、イベントを変換およびフィルタリングして、ターゲットに適用します。DM-master は、ソースとサブタスクのステータスについて DM-worker に問い合わせます。 ## 主要な概念 {#key-concepts} - ワーカーインスタンスがオフラインになると、DM-master はそのタスクを別の利用可能なワーカーに自動的に再スケジュールして、データレプリケーションを再開できます。これはフルエクスポート/インポートフェーズ中には適用されないことに注意してください。 -- 1 つの DM-worker プロセスは、一度に **1 つ** の上流ソースデータベースインスタンスに接続します。シャードテーブルのマージ時など、複数のソースから移行するには、複数の DM-worker プロセスを実行する必要があります。 +- 1つの DM-worker プロセスは、一度に **1つ** の上流ソースデータベースインスタンスに接続します。シャードテーブルのマージ時など、複数のソースから移行するには、複数の DM-worker プロセスを実行する必要があります。 > **Note:** > @@ -121,7 +121,7 @@ GRANT SELECT ON `db1`.* TO 'your_user'@'your_wildcard_of_host'; > - conn_number > ``` > -> この回避策では、MariaDB 権限パーサーの影響を受ける 3 つのチェックのみをスキップします。使用する前に、対応する権限と接続上限を手動で確認してください。詳細については、[DM precheck](/dm/dm-precheck.md) を参照してください。 +> この回避策では、MariaDB 権限パーサーの影響を受ける 3つのチェックのみをスキップします。使用する前に、対応する権限と接続上限を手動で確認してください。詳細については、[DM precheck](/dm/dm-precheck.md) を参照してください。 > **Note:** > diff --git a/dm/dmctl-introduction.md b/dm/dmctl-introduction.md index de315471e2c0b..567fd047f1bdb 100644 --- a/dm/dmctl-introduction.md +++ b/dm/dmctl-introduction.md @@ -74,7 +74,7 @@ Use "dmctl [command] --help" for more information about a command. > **Note:** > -> - dmctl コマンドの後には 1 つのタスク操作のみが続く必要があります。 +> - dmctl コマンドの後には 1つのタスク操作のみが続く必要があります。 > - v2.0.4 以降、DM は環境変数`DM_MASTER_ADDR`から`-master-addr`パラメータの読み取りをサポートします。 ```bash diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md index 1319e1c494c41..8504b4abf2ab5 100644 --- a/dm/feature-online-ddl.md +++ b/dm/feature-online-ddl.md @@ -15,13 +15,13 @@ DMを使用してMySQLからTiDBにデータを移行する場合、online-ddl ## オンラインスキーマ変更: gh-ost {#online-schema-change-gh-ost} -gh-ost がオンライン スキーマ変更を実装すると、次の 3 種類のテーブルが作成されます。 +gh-ost がオンライン スキーマ変更を実装すると、次の3種類のテーブルが作成されます。 - gho: DDLの適用に使用されます。データが完全に複製され、ghoテーブルが元のテーブルと整合性が取れている場合、元のテーブルは名前変更によって置き換えられます。 - ghc: オンライン スキーマ変更に関連する情報を保存するために使用されます。 - del: 元のテーブルの名前を変更して作成されました。 -移行プロセスでは、DM は上記のテーブルを 3 つのカテゴリに分割します。 +移行プロセスでは、DM は上記のテーブルを 3つのカテゴリに分割します。 - ゴーストテーブル: `_*_gho` - ゴミ箱テーブル: `_*_ghc` , `_*_del` @@ -86,9 +86,9 @@ gh-ost で主に使用される SQL ステートメントとそれに対応す Rename /* gh-ost */ table `test`.`test4` to `test`.`_test4_del`, `test`.`_test4_gho` to `test`.`test4`; ``` - DM は次の 2 つの操作を実行します。 + DM は次の2つの操作を実行します。 - - DM は上記の`rename`操作を 2 つの SQL 文に分割します。 + - DM は上記の`rename`操作を 2つの SQL 文に分割します。 ```sql rename test.test4 to test._test4_del; @@ -113,13 +113,13 @@ gh-ost で主に使用される SQL ステートメントとそれに対応す ## オンラインスキーマ変更: pt {#online-schema-change-pt} -pt-osc がオンライン スキーマ変更を実装すると、次の 2 種類のテーブルが作成されます。 +pt-osc がオンライン スキーマ変更を実装すると、次の2種類のテーブルが作成されます。 - `new` : DDLの適用に使用されます。データが完全に複製され、 `new`テーブルが元のテーブルと整合性が取れている場合、元のテーブルは名前変更によって置き換えられます。 - `old` : 元のテーブルの名前を変更して作成されました。 - 3種類`pt_osc_*_del`トリガー： `pt_osc_*_ins`のプロセスでは、元のテーブルで生成された新しいデータ`pt_osc_*_upd`トリガーによって`new`に複製されます。 -移行プロセスでは、DM は上記のテーブルを 3 つのカテゴリに分割します。 +移行プロセスでは、DM は上記のテーブルを 3つのカテゴリに分割します。 - ゴーストテーブル: `_*_new` - ゴミ箱テーブル: `_*_old` @@ -152,7 +152,7 @@ pt-osc で主に使用される SQL 文とそれに対応する DM の操作は REPLACE INTO dm_meta.{task_name}_onlineddl (id, ghost_schema , ghost_table , ddls) VALUES (......); ``` -3. データ移行に使用する 3 つのトリガーを作成します。 +3. データ移行に使用する 3つのトリガーを作成します。 ```sql CREATE TRIGGER `pt_osc_test_test4_del` AFTER DELETE ON `test`.`test4` ...... ; @@ -176,9 +176,9 @@ pt-osc で主に使用される SQL 文とそれに対応する DM の操作は RENAME TABLE `test`.`test4` TO `test`.`_test4_old`, `test`.`_test4_new` TO `test`.`test4` ``` - DM は次の 2 つの操作を実行します。 + DM は次の2つの操作を実行します。 - - DM は上記の`rename`操作を 2 つの SQL 文に分割します。 + - DM は上記の`rename`操作を 2つの SQL 文に分割します。 ```sql rename test.test4 to test._test4_old; @@ -197,7 +197,7 @@ pt-osc で主に使用される SQL 文とそれに対応する DM の操作は ALTER TABLE `test`.`test4` add column c3 int; ``` -6. オンライン DDL 操作の`_old`テーブルと 3 つのトリガーを削除します。 +6. オンライン DDL 操作の`_old`テーブルと 3つのトリガーを削除します。 ```sql DROP TABLE IF EXISTS `test`.`_test4_old`; diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 9eba1e4ceb1ab..8c0f687bbf521 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -29,7 +29,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル - DDL ステートメントのバッチを実行する前と実行後に、各シャード テーブルのスキーマが相互に一貫していることを確認します。 -- A/B テストを実行する場合は、1 つのシャード テーブルで**のみ**テストを実行します。 +- A/B テストを実行する場合は、1つのシャード テーブルで**のみ**テストを実行します。 - A/Bテストが完了したら、最も直接的なDDL文のみを最終スキーマに移行します。テストのすべてのステップを、正解か不正解かを問わず再実行しないでください。 @@ -61,7 +61,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル - `DROP TABLE`または`DROP DATABASE`はサポートされていません。 - `TRUNCATE TABLE`はサポートされていません。 -- 各 DDL ステートメントには、1 つのテーブルに対する操作のみを含める必要があります。 +- 各 DDL ステートメントには、1つのテーブルに対する操作のみを含める必要があります。 - TiDB でサポートされていない DDL ステートメントは、DM でもサポートされません。 - 新しく追加された列のデフォルト値には、 `current_timestamp` 、 `rand()` 、 `uuid()`を含めることはできません。そうしないと、上流と下流の間でデータの不整合が発生する可能性があります。 @@ -72,10 +72,10 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル ### データの不整合を引き起こす操作 {#operations-that-cause-data-inconsistency} - 各シャードテーブルのスキーマは互いに互換性がありません。例: - - 同じ名前の 2 つの列が 2 つのシャード テーブルにそれぞれ追加されていますが、列のタイプは異なります。 - - 同じ名前の 2 つの列が 2 つのシャード テーブルにそれぞれ追加されていますが、列のデフォルト値は異なります。 - - 同じ名前の 2 つの生成列がそれぞれ 2 つのシャード テーブルに追加されますが、列は異なる式を使用して生成されます。 - - 同じ名前の 2 つのインデックスが 2 つのシャード テーブルにそれぞれ追加されていますが、キーは異なります。 + - 同じ名前の 2つの列が 2つのシャード テーブルにそれぞれ追加されていますが、列のタイプは異なります。 + - 同じ名前の 2つの列が 2つのシャード テーブルにそれぞれ追加されていますが、列のデフォルト値は異なります。 + - 同じ名前の 2つの生成列がそれぞれ 2つのシャード テーブルに追加されますが、列は異なる式を使用して生成されます。 + - 同じ名前の 2つのインデックスが 2つのシャード テーブルにそれぞれ追加されていますが、キーは異なります。 - 同じ名前を持つ他の異なるテーブル スキーマ。 - シャード テーブル内のデータを破損する可能性のある DDL ステートメントを実行し、ロールバックを試みます。 @@ -83,7 +83,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル ### 例 {#example} -次の 3 つのシャード テーブルをマージして TiDB に移行します。 +次の3つのシャード テーブルをマージして TiDB に移行します。 ![optimistic-ddl-fail-example-1](/media/dm/optimistic-ddl-fail-example-1.png) diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index 03539ddfe23bd..3b74e378a1690 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -15,7 +15,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して - 論理**シャーディンググループ**では、すべてのアップストリームのシャーディングテーブル（スキーマ名とテーブル名は異なっていても構いません）において、同じDDLステートメントを同じ順序で実行する必要があり、現在のDDL操作が完全に完了するまで、次のDDLステートメントを実行することはできません。 - 例えば、 `column A`を`table_1`に追加してから`column B`を追加した場合、 `column B`を`table_2`に追加してから`column A` } を追加することはできません。DDL ステートメントを異なる順序で実行することはサポートされていません。 - シャーディンググループでは、対応するDDLステートメントは、すべてのアップストリームのシャーディングテーブルで実行される必要があります。 - - 例えば、 `DM-worker-2`に対応する 1 つ以上のアップストリーム シャーディング テーブルで DDL ステートメントが実行されない場合、DDL ステートメントを実行した他の DM-worker は移行タスクを一時停止し、 `DM-worker-2`がアップストリーム DDL ステートメントを受信するのを待ちます。 + - 例えば、 `DM-worker-2`に対応する 1つ以上のアップストリーム シャーディング テーブルで DDL ステートメントが実行されない場合、DDL ステートメントを実行した他の DM-worker は移行タスクを一時停止し、 `DM-worker-2`がアップストリーム DDL ステートメントを受信するのを待ちます。 - シャーディング グループ移行タスクは`DROP DATABASE` / `DROP TABLE`をサポートしていません。 - DM-worker の同期ユニットは、アップストリームのシャーディングされたテーブルの`DROP DATABASE` / `DROP TABLE`ステートメントを自動的に無視します。 - シャーディンググループ移行タスクは`TRUNCATE TABLE`をサポートしていません。 @@ -28,12 +28,12 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して - [テーブルルーティング](/dm/dm-table-routing.md)ルールを変更する必要がある場合は、すべてのシャーディング DDL ステートメントの移行が完了するまで待つ必要があります。 - シャーディング DDL ステートメントの移行中に、 `dmctl`を使用して`router-rules`を変更するとエラーが報告されます。 - DDL ステートメントが実行されるシャーディング グループに新しいテーブルを`CREATE`追加する必要がある場合は、テーブル スキーマが新しく変更されたテーブル スキーマと同じであることを確認する必要があります。 - - 例えば、元の`table_1`と`table_2`はどちらも最初は 2 つの列 (a、b) を持ち、シャーディング DDL 操作後には 3 つの列 (a、b、c) を持つため、移行後に新しく作成されたテーブルも 3 つの列 (a、b、c) を持つ必要があります。 + - 例えば、元の`table_1`と`table_2`はどちらも最初は 2つの列 (a、b) を持ち、シャーディング DDL 操作後には 3つの列 (a、b、c) を持つため、移行後に新しく作成されたテーブルも 3つの列 (a、b、c) を持つ必要があります。 - DDLステートメントを受信したDMワーカーは、他のDMワーカーがDDLステートメントを受信するまでタスクを一時停止するため、データ移行の遅延が増加します。 ## 背景 {#background} -現在、DM は`ROW`形式のbinlogを使用して移行タスクを実行します。binlogにはテーブルスキーマ情報は含まれていません。 `ROW`binlogを使用してデータを移行する場合、複数の上流テーブルを同じ下流テーブルに移行していない限り、下流テーブルのテーブルスキーマを更新できる上流テーブルの DDL 操作は 1 つしか存在しません。 `ROW`binlogは自己記述的な性質を持つと考えられます。移行プロセス中に、列の値と下流テーブルのスキーマに応じて DML ステートメントを構築できます。 +現在、DM は`ROW`形式のbinlogを使用して移行タスクを実行します。binlogにはテーブルスキーマ情報は含まれていません。 `ROW`binlogを使用してデータを移行する場合、複数の上流テーブルを同じ下流テーブルに移行していない限り、下流テーブルのテーブルスキーマを更新できる上流テーブルの DDL 操作は 1つしか存在しません。 `ROW`binlogは自己記述的な性質を持つと考えられます。移行プロセス中に、列の値と下流テーブルのスキーマに応じて DML ステートメントを構築できます。 ただし、シャーディングされたテーブルのマージと移行の過程で、テーブルスキーマを変更するために上流テーブルでDDLステートメントが実行された場合、列の値によって生成されたDMLステートメントと実際の下流テーブルスキーマとの間の不整合を回避するために、DDLステートメントを移行するための追加操作を実行する必要があります。 @@ -41,11 +41,11 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して ![shard-ddl-example-1](/media/dm/shard-ddl-example-1.png) -上記の例では、マージ処理が簡略化されており、上流には 2 つの MySQL インスタンスのみが存在し、各インスタンスには 1 つのテーブルしかありません。移行が開始されると、2 つのシャーディングされたテーブルのテーブル スキーマ バージョンは`schema V1`とマークされ、DDL ステートメントの実行後のテーブル スキーマ バージョンは`schema V2`とマークされます。 +上記の例では、マージ処理が簡略化されており、上流には 2つの MySQL インスタンスのみが存在し、各インスタンスには 1つのテーブルしかありません。移行が開始されると、2つのシャーディングされたテーブルのテーブル スキーマ バージョンは`schema V1`とマークされ、DDL ステートメントの実行後のテーブル スキーマ バージョンは`schema V2`とマークされます。 ここで、移行プロセスにおいて、上流の2つのシャーディングされたテーブルから受信したbinlogデータが、以下の時間シーケンスを持つと仮定します。 -1. 移行が開始されると、DM-worker の同期ユニットは、2 つのシャーディングされたテーブルから`schema V1`の DML イベントを受信します。 +1. 移行が開始されると、DM-worker の同期ユニットは、2つのシャーディングされたテーブルから`schema V1`の DML イベントを受信します。 2. `t1`では、インスタンス 1 からのシャーディング DDL イベントが受信されます。 3. `t2`以降、同期ユニットはインスタンス1から`schema V2`のDMLイベントを受信しますが、インスタンス2からは引き続き`schema V1`のDMLイベントを受信します。 4. `t3`では、インスタンス 2 からのシャーディング DDL イベントが受信されます。 @@ -107,7 +107,7 @@ sequenceDiagram 上記の例では、各DMワーカーに対応するアップストリームのMySQLインスタンスでマージする必要があるのは、シャーディングされたテーブル1つだけです。しかし、実際のシナリオでは、複数のシャーディングされたスキーマに複数のシャーディングされたテーブルが存在し、それらを1つのMySQLインスタンスでマージする必要がある場合があります。このような場合、シャーディングDDLの移行を調整するのがより複雑になります。 -`table_1`と`table_2`という 2 つのシャーディングされたテーブルを、1 つの MySQL インスタンスにマージすると仮定します。 +`table_1`と`table_2`という 2つのシャーディングされたテーブルを、1つの MySQL インスタンスにマージすると仮定します。 ![shard-ddl-example-2](/media/dm/shard-ddl-example-2.png) diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index 554dc9f88a8a4..f4b17a1233ede 100644 --- a/dm/handle-failed-ddl-statements.md +++ b/dm/handle-failed-ddl-statements.md @@ -431,7 +431,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DAN - タスクはエラーなしで正常に実行され、4 つの間違った DDL ステートメントはすべてスキップされていることがわかります。 + タスクはエラーなしで正常に実行され、4つの間違った DDL ステートメントはすべてスキップされていることがわかります。 ### 移行が中断された場合はDDLを置き換える {#replace-ddl-if-the-migration-gets-interrupted} @@ -571,8 +571,8 @@ ALTER TABLE `db1`.`tbl1` ADD COLUMN new_col INT UNIQUE; アップストリームにある以下の4つのテーブルを、ダウンストリームにある同じテーブル`` `shard_db`.`shard_table` ``にマージして移行する必要があると仮定します。タスクモードは「悲観的」です。 -- MySQL インスタンス 1 にはスキーマ`shard_db_1`があり、そこには`shard_table_1`と`shard_table_2` 2 つのテーブルがあります。 -- MySQL インスタンス 2 にはスキーマ`shard_db_2`があり、そこには`shard_table_1`と`shard_table_2` 2 つのテーブルがあります。 +- MySQL インスタンス 1 にはスキーマ`shard_db_1`があり、そこには`shard_table_1`と`shard_table_2` 2つのテーブルがあります。 +- MySQL インスタンス 2 にはスキーマ`shard_db_2`があり、そこには`shard_table_1`と`shard_table_2` 2つのテーブルがあります。 初期のテーブル スキーマは次のとおりです。 @@ -804,7 +804,7 @@ ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE; - タスクはエラーなしで正常に実行され、4 つの誤った DDL ステートメントがすべて置き換えられていることがわかります。 + タスクはエラーなしで正常に実行され、4つの誤った DDL ステートメントがすべて置き換えられていることがわかります。 ### その他のコマンド {#other-commands} diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index b70b593b0336b..ea853bb743773 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -239,7 +239,7 @@ DM マスター ホットフィックス パッケージが`/tmp/dm-master-hotfi tiup dm patch prod-cluster /tmp/dm-master-hotfix.tar.gz -R dm-master ``` -クラスター内の DM マスター パッケージを 1 つだけ置き換えることもできます。 +クラスター内の DM マスター パッケージを 1つだけ置き換えることもできます。 ```bash tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index 6fceff308b3eb..fba84644f93a2 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -147,7 +147,7 @@ shard-ddl-lock unlock test-`shard_db`.`shard_table` ## サポートされているシナリオ {#supported-scenarios} -現在、 `shard-ddl-lock unlock`コマンドは、次の 2 つの異常なシナリオでのシャーディング DDL ロックの処理のみをサポートしています。 +現在、 `shard-ddl-lock unlock`コマンドは、次の2つの異常なシナリオでのシャーディング DDL ロックの処理のみをサポートしています。 ### シナリオ1: MySQLソースの一部が削除される {#scenario-1-some-mysql-sources-are-removed} @@ -185,7 +185,7 @@ ALTER TABLE shard_db_*.shard_table_* ADD COLUMN c2 INT; MySQLとDMの操作プロセスは次のとおりです。 -1. 対応する DDL 操作が`mysql-replica-01`の 2 つのシャード テーブルに対して実行され、テーブル構造が変更されます。 +1. 対応する DDL 操作が`mysql-replica-01`の 2つのシャード テーブルに対して実行され、テーブル構造が変更されます。 ```sql ALTER TABLE shard_db_1.shard_table_1 ADD COLUMN c2 INT; @@ -195,7 +195,7 @@ MySQLとDMの操作プロセスは次のとおりです。 ALTER TABLE shard_db_1.shard_table_2 ADD COLUMN c2 INT; ``` -2. DM-worker は、受信した`mysql-replica-01`の 2 つのシャード テーブルの DDL 情報を DM-master に送信し、DM-master は対応する DDL ロックを作成します。 +2. DM-worker は、受信した`mysql-replica-01`の 2つのシャード テーブルの DDL 情報を DM-master に送信し、DM-master は対応する DDL ロックを作成します。 3. 現在の DDL ロックの情報を確認するには、 `shard-ddl-lock`を使用します。 diff --git a/dm/monitor-a-dm-cluster.md b/dm/monitor-a-dm-cluster.md index d0d4b1521294f..501f0acc34402 100644 --- a/dm/monitor-a-dm-cluster.md +++ b/dm/monitor-a-dm-cluster.md @@ -42,12 +42,12 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | メトリック名 | 説明 | 警告 | 重大度レベル | | :-------------------------- | :------------------------------------------ | :------------------------------- | :----- | -| 1分あたりのDMマスター開始リーダーコンポーネントの数 | DM マスターがリーダー関連コンポーネントを有効にしようとする 1 分あたりの試行回数 | 該当なし | 該当なし | -| 異なる州の労働者の数 | 各州のDM労働者の数 | 一部の DM ワーカーが 1 時間以上オフラインになっています | 致命的 | +| 1分あたりのDMマスター開始リーダーコンポーネントの数 | DM マスターがリーダー関連コンポーネントを有効にしようとする 1分あたりの試行回数 | 該当なし | 該当なし | +| 異なる州の労働者の数 | 各州のDM労働者の数 | 一部の DM ワーカーが 1時間以上オフラインになっています | 致命的 | | 労働者国家 | DMワーカーの状態 | 該当なし | 該当なし | | ワーカーイベントエラーの数 | DMワーカーエラーのさまざまなタイプの数 | 該当なし | 該当なし | -| 1分あたりのシャードDDLエラー | 1 分あたりのさまざまな種類のシャーディング DDL エラーの数 | シャーディングDDLエラーが発生した場合 | 致命的 | -| 保留中のシャード DDL の数 | 保留中のシャーディングDDL操作の数 | 保留中のシャーディング DDL 操作が 1 時間以上経過している | 致命的 | +| 1分あたりのシャードDDLエラー | 1分あたりのさまざまな種類のシャーディング DDL エラーの数 | シャーディングDDLエラーが発生した場合 | 致命的 | +| 保留中のシャード DDL の数 | 保留中のシャーディングDDL操作の数 | 保留中のシャーディング DDL 操作が 1時間以上経過している | 致命的 | ### タスクの状態 {#task-state} diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 04fc65a0bdbf8..0ee3b525b4dc6 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -11,7 +11,7 @@ summary: DM クラスターがデプロイされた後に移行タスクを作 次のサンプル シナリオに基づいてデータ移行タスクを作成するとします。 -- binlogを有効にした 2 つの MySQL インスタンスと 1 つの TiDB インスタンスをローカルにデプロイ。 +- binlogを有効にした 2つの MySQL インスタンスと 1つの TiDB インスタンスをローカルにデプロイ。 - DM クラスターの DM マスターを使用して、クラスターとデータ移行タスクを管理します。 各ノードの情報は以下の通りです。 diff --git a/dm/relay-log.md b/dm/relay-log.md index a7323380afbb6..5a7a485440969 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -68,7 +68,7 @@ start-relay -s mysql-replica-01 > > この起動方法はバージョン6.1で非推奨とされており、将来のリリースで削除される可能性があります。関連コマンドの出力には、次のプロンプトが表示されます: `start-relay/stop-relay with worker name will be deprecated soon. You can try stopping relay first and use start-relay without worker name instead` 。 -コマンド`start-relay`では、指定されたデータソースのリレーログを移行する 1 つ以上の DM ワーカーを設定できます。ただし、パラメータで指定する DM ワーカーは、空いているか、上流のデータソースにバインドされている必要があります。例を以下に示します。 +コマンド`start-relay`では、指定されたデータソースのリレーログを移行する 1つ以上の DM ワーカーを設定できます。ただし、パラメータで指定する DM ワーカーは、空いているか、上流のデータソースにバインドされている必要があります。例を以下に示します。 ```bash start-relay -s mysql-replica-01 worker1 worker2 @@ -226,7 +226,7 @@ resume-relay -s mysql-replica-01 ### リレーログを消去する {#purge-relay-logs} -DM では、リレーログをパージする方法として、手動パージと自動パージの 2 つの方法を提供しています。どちらの方法でも、アクティブなリレーログはパージされません。 +DM では、リレーログをパージする方法として、手動パージと自動パージの 2つの方法を提供しています。どちらの方法でも、アクティブなリレーログはパージされません。 > **Note:** > @@ -248,7 +248,7 @@ purge: - `purge.interval` - バックグラウンドでの自動パージの間隔（秒単位）。 - - デフォルトでは「3600」であり、バックグラウンド パージ タスクが 3600 秒ごとに実行されることを示します。 + - デフォルトでは「3600」であり、バックグラウンド パージ タスクが 3600秒ごとに実行されることを示します。 - `purge.expires` - リレー ログ (以前にリレー処理ユニットに書き込まれ、現在実行中のデータ移行タスクによって使用されていないか、後で読み取られないログ) を自動バックグラウンド パージで消去されるまで保持できる時間数。 diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index a9f4c1f6edcab..c0b1449ad49be 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -23,20 +23,20 @@ summary: シャードマージのシナリオにおけるデータ移行のベ 代わりに、次のことができます。 -- シャーディング DDL ロックの自動解放の失敗が[異常なシナリオを列挙した](/dm/manually-handling-sharding-ddl-locks.md#supported-scenarios)の 1 つである場合は、対応する手動ソリューションに従ってシナリオを処理します。 +- シャーディング DDL ロックの自動解放の失敗が[異常なシナリオを列挙した](/dm/manually-handling-sharding-ddl-locks.md#supported-scenarios)の 1つである場合は、対応する手動ソリューションに従ってシナリオを処理します。 - サポートされていないシナリオの場合は、データ移行タスク全体をやり直します。まず、ダウンストリーム データベースのデータと移行タスクに関連付けられた`dm_meta`情報を空にし、次に、完全および増分データ レプリケーションを再実行します。 ## 複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables} 複数のシャードテーブルのデータにより、主キーまたは一意インデックス間で競合が発生する可能性があります。シャードテーブルのシャーディングロジックに基づいて、それぞれの主キーまたは一意インデックスを確認する必要があります。以下は、主キーまたは一意インデックスに関連する3つのケースです。 -- シャード キー: 通常、同じシャード キーは 1 つのシャード テーブルにのみ存在するため、シャード キーでデータの競合は発生しません。 +- シャード キー: 通常、同じシャード キーは 1つのシャード テーブルにのみ存在するため、シャード キーでデータの競合は発生しません。 - AUTO_INCREMENT主キー：各シャードテーブルのAUTO_INCREMENT主キーは個別にカウントされるため、範囲が重複する可能性があります。この場合、次のセクション[AUTO_INCREMENT主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)を参照して解決してください。 - その他の主キーまたは一意インデックスについては、ビジネスロジックに基づいて分析する必要があります。データの競合が発生した場合は、次のセクション[AUTO_INCREMENT主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)を参照して解決してください。 ## AUTO_INCREMENT主キーの競合を処理する {#handle-conflicts-of-auto-increment-primary-key} -このセクションでは、AUTO_INCREMENT主キーの競合を処理するための 2 つの推奨ソリューションを紹介します。 +このセクションでは、AUTO_INCREMENT主キーの競合を処理するための 2つの推奨ソリューションを紹介します。 ### 列から`PRIMARY KEY`属性を削除します {#remove-the-primary-key-attribute-from-the-column} @@ -135,7 +135,7 @@ CREATE TABLE `tbl_multi_pk` ( 3. アップストリームに新しいシャード テーブルを作成します。 -4. `task.yaml`ファイル内の構成で、新しく追加されたシャード テーブルを他の既存のシャード テーブルと 1 つのダウンストリーム テーブルにマージできることを確認します。 +4. `task.yaml`ファイル内の構成で、新しく追加されたシャード テーブルを他の既存のシャード テーブルと 1つのダウンストリーム テーブルにマージできることを確認します。 5. タスクを開始するには`start-task`を実行します。 diff --git a/dm/table-selector.md b/dm/table-selector.md index def7d359c98e0..8ddbc9520d774 100644 --- a/dm/table-selector.md +++ b/dm/table-selector.md @@ -9,7 +9,7 @@ summary: データ移行のテーブル ルーティング、 binlogイベント ## ワイルドカード文字 {#wildcard-character} -テーブルセレクターは`schema-pattern`で次の 2 つのワイルドカード文字`table-pattern`を使用します。 +テーブルセレクターは`schema-pattern`で次の2つのワイルドカード文字`table-pattern`を使用します。 - アスタリスク文字（ `*` 、「スター」とも呼ばれる） @@ -18,7 +18,7 @@ summary: データ移行のテーブル ルーティング、 binlogイベント - 疑問符（ `?` ） - `?` 、空文字を除く 1 つの文字と一致します。 + `?` 、空文字を除く 1つの文字と一致します。 ## 試合ルール {#match-rules} diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index 198c0f9ba4231..8185710a7c5fd 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -241,7 +241,7 @@ mysql-instances: ## コンフィグレーション順序 {#configuration-order} -サンプル設定ファイルから、設定ファイルが`Global configuration`と`Instance configuration`の 2 つの部分から構成されていることがわかります。ここで、 `Global configuration`には`Basic configuration`と`Feature configuration set`が含まれています。設定順序は次のとおりです。 +サンプル設定ファイルから、設定ファイルが`Global configuration`と`Instance configuration`の 2つの部分から構成されていることがわかります。ここで、 `Global configuration`には`Basic configuration`と`Feature configuration set`が含まれています。設定順序は次のとおりです。 1. [グローバル設定](#global-configuration)を編集します。 2. グローバル構成に基づいて[インスタンス構成](#instance-configuration)を編集します。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 12b641e5120f8..bca86c91af93b 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -18,11 +18,11 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー > **Note:** > -> [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)データの範囲を意味し、「リージョン」という用語は物理的な場所を意味します。この 2 つの用語は互換性がありません。 +> [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)データの範囲を意味し、「リージョン」という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 ## クラスターをセットアップしてレプリカを構成する {#set-up-a-cluster-and-configure-replicas} -このセクションでは、 TiUPを使用して 5 つのレプリカを持つ 3 つのリージョンにまたがる TiDB クラスターを作成する方法と、データと PD ノードを適切に分散して DR を実現する方法を説明します。 +このセクションでは、 TiUPを使用して 5つのレプリカを持つ 3つのリージョンにまたがる TiDB クラスターを作成する方法と、データと PD ノードを適切に分散して DR を実現する方法を説明します。 この例では、TiDBには5つのレプリカと3つのリージョンが含まれています。リージョン1はプライマリリージョン、リージョン2はセカンダリリージョン、リージョン3は投票に使用されます。同様に、PDクラスターにも5つのレプリカが含まれており、TiDBクラスターと基本的に同じように機能します。 diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index 56aa6813e4ef0..bba8271b72347 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -93,13 +93,13 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 このアーキテクチャでは、TiDBクラスタ1がリージョン1にデプロイされます。BRはクラスタ1のデータを定期的にリージョン2にバックアップし、さらにこのクラスタのデータ変更ログも継続的にリージョン2にバックアップします。リージョン1で災害が発生し、クラスタ1が復旧できない場合、バックアップデータとデータ変更ログを使用して、リージョン2に新しいクラスタ（クラスタ2）を復元し、サービスを提供できます。 -BRに基づく DR ソリューションは、5 分未満の RPO と、復元するデータのサイズに応じて変化する RTO を提供します。 BR v6.5.0 の場合、復元速度については[スナップショット復元のパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)と[PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)を参照してください。通常、リージョン間のバックアップ機能はデータ セキュリティの最後の手段とみなされ、ほとんどのシステムにとって必須のソリューションでもあります。このソリューションの詳細については、 [BRに基づくDRソリューション](/dr-backup-restore.md)を参照してください。 +BRに基づく DR ソリューションは、5分未満の RPO と、復元するデータのサイズに応じて変化する RTO を提供します。 BR v6.5.0 の場合、復元速度については[スナップショット復元のパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)と[PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)を参照してください。通常、リージョン間のバックアップ機能はデータ セキュリティの最後の手段とみなされ、ほとんどのシステムにとって必須のソリューションでもあります。このソリューションの詳細については、 [BRに基づくDRソリューション](/dr-backup-restore.md)を参照してください。 一方、 BR はv6.5.0 以降、 [EBSボリュームのスナップショットからTiDBクラスタを復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-from-ebs-snapshot-across-multiple-kubernetes)をサポートします。クラスターが Kubernetes 上で実行されており、クラスターに影響を与えずにできるだけ早くクラスターを復元したい場合は、この機能を使用してシステムの RTO を短縮できます。 ### その他の災害復旧ソリューション {#other-dr-solutions} -前述の DR ソリューションに加えて、同じ都市のデュアルセンター シナリオでゼロ RPO が必須の場合は、DR-AUTO 同期ソリューションを使用することもできます。詳細については、[1 つの地域に展開された 2 つのデータ センター](/two-data-centers-in-one-city-deployment.md)をご覧ください。 +前述の DR ソリューションに加えて、同じ都市のデュアルセンター シナリオでゼロ RPO が必須の場合は、DR-AUTO 同期ソリューションを使用することもできます。詳細については、[1つの地域に展開された 2つのデータ センター](/two-data-centers-in-one-city-deployment.md)をご覧ください。 ## 解決策の比較 {#solution-comparison} diff --git a/dynamic-config.md b/dynamic-config.md index a11c5e4606fae..bcb4590bc4ac3 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -150,7 +150,7 @@ show warnings; | `raftstore.store-io-pool-size` | Raft I/Oタスクを処理するスレッドの数。これは StoreWriter スレッド プールのサイズでもあります (この値を 0 以外の値から 0 に、または 0 から 0 以外の値に変更**しないでください**) | | `raftstore.periodic-full-compact-start-max-cpu` | 完全圧縮が有効な場合に TiKV が定期的に完全圧縮を実行する CPU 使用率のしきい値 | | `readpool.unified.max-thread-count` | 読み取り要求を均一に処理するスレッド プール内のスレッドの最大数。これは UnifyReadPool スレッド プールのサイズです。 | -| `readpool.unified.max-tasks-per-worker` | 統合読み取りプール内の 1 つのスレッドに許可されるタスクの最大数。値を超えると`Server Is Busy`エラーが返されます。 | +| `readpool.unified.max-tasks-per-worker` | 統合読み取りプール内の 1つのスレッドに許可されるタスクの最大数。値を超えると`Server Is Busy`エラーが返されます。 | | `readpool.unified.auto-adjust-pool-size` | UnifyReadPool スレッド プールのサイズを自動的に調整するかどうかを決定します | | `resource-control.priority-ctl-strategy` | 低優先度タスクのフロー制御戦略を構成します。 | | `coprocessor.split-region-on-table` | テーブルごとにリージョンを分割できます | @@ -271,7 +271,7 @@ Query OK, 0 rows affected (0.01 sec) | `schedule.max-merge-region-keys` | `Region Merge`キーの最大数を指定します | | `schedule.patrol-region-interval` | チェッカーがリージョンのヘルス状態を検査する頻度を決定します | | `schedule.split-merge-interval` | 同じリージョンで分割および結合操作を実行する時間間隔を決定します | -| `schedule.max-snapshot-count` | 1 つのストアが同時に送信または受信できるスナップショットの最大数を決定します。 | +| `schedule.max-snapshot-count` | 1つのストアが同時に送信または受信できるスナップショットの最大数を決定します。 | | `schedule.max-pending-peer-count` | 単一ストア内の保留中のピアの最大数を決定します | | `schedule.max-store-down-time` | PDが切断されたストアを回復できないと判断するまでのダウンタイム | | `schedule.max-store-preparing-time` | ストアがオンラインになるまでの最大待ち時間を制御します | @@ -378,7 +378,7 @@ select @@tidb_slow_log_threshold; 現在、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)を使用してTiFlash構成`max_threads`を変更できます。この変数は、 TiFlashが要求を実行するための最大同時実行性を指​​定します。 -`tidb_max_tiflash_threads`のデフォルト値は`-1`で、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`を使用すると、 `max_threads`を 10 に設定できます。 +`tidb_max_tiflash_threads`のデフォルト値は`-1`で、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`を使用すると、 `max_threads`を10に設定できます。 ```sql set tidb_max_tiflash_threads = 10; diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 2582edb559c58..f56abe341c0fd 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -17,7 +17,7 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を 1. 証明書を準備します。 - TiDB、TiKV、PD それぞれにサーバー証明書を用意することをお勧めします。これらのコンポーネントが相互に認証できることを確認してください。TiDB、TiKV、PD の制御ツールは、1 つのクライアント証明書を共有することもできます。 + TiDB、TiKV、PD それぞれにサーバー証明書を用意することをお勧めします。これらのコンポーネントが相互に認証できることを確認してください。TiDB、TiKV、PD の制御ツールは、1つのクライアント証明書を共有することもできます。 自己署名証明書を生成するには`easy-rsa` `openssl` `cfssl`ツールを使用できます。 @@ -235,7 +235,7 @@ TiDBコンポーネント間の通信にTLSを設定したら、以下のコマ - TiDB クラスターがローカル データ センターに展開されている場合、証明書とキーを再ロードするために、TiDB、PD、TiKV、 TiFlash、TiCDC、およびすべての種類のクライアントは、新しい接続が作成されるたびに、TiDB クラスターを再起動せずに現在の証明書とキー ファイルを再読み取ります。 -- TiProxy は 1 時間に 1 回、ディスクから証明書を再読み込みします。 +- TiProxy は 1時間に 1回、ディスクから証明書を再読み込みします。 - TiDB クラスタを自社マネージドクラウドにデプロイしている場合は、TLS 証明書の発行がクラウドプロバイダーの証明書管理サービスと統合されていることを確認してください。TiDB、PD、TiKV、 TiFlash、および TiCDC コンポーネントの TLS 証明書は、TiDB クラスタを再起動することなく自動的にローテーションできます。 diff --git a/encryption-at-rest.md b/encryption-at-rest.md index a7fee77c77930..ffc2228b0d044 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -434,7 +434,7 @@ BRを使用して Azure Blob Storage にデータをバックアップする場 ### 方法1: 暗号化スコープを使用する {#method-1-use-an-encryption-scope} -バックアップ データの暗号化範囲を指定するには、次の 2 つの方法のいずれかを使用できます。 +バックアップ データの暗号化範囲を指定するには、次の2つの方法のいずれかを使用できます。 - `backup`コマンドに`--azblob.encryption-scope`オプションを含め、スコープ名に設定します。 @@ -458,7 +458,7 @@ tiup br restore full --pd --storage "azure:///" ### 方法2: 暗号化キーを使用する {#method-2-use-an-encryption-key} -バックアップ データの暗号化キーを指定するには、次の 3 つの方法のいずれかを使用できます。 +バックアップ データの暗号化キーを指定するには、次の3つの方法のいずれかを使用できます。 - `backup`コマンドに`--azblob.encryption-key`オプションを含め、AES256 暗号化キーを設定します。 diff --git a/error-codes.md b/error-codes.md index 133a3bc4d1f7f..a5bb84b14f9ae 100644 --- a/error-codes.md +++ b/error-codes.md @@ -579,7 +579,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 > **Note:** > - > 「30m」は、30 分前に生成されたデータのみをクリーンアップすることを意味します。これにより、追加のストレージスペースが消費される可能性があります。 + > 「30m」は、30分前に生成されたデータのみをクリーンアップすることを意味します。これにより、追加のストレージスペースが消費される可能性があります。 - エラー番号: 9500 diff --git a/explain-aggregation.md b/explain-aggregation.md index 5062c13cbc42c..82272c096625b 100644 --- a/explain-aggregation.md +++ b/explain-aggregation.md @@ -163,7 +163,7 @@ Query OK, 0 rows affected (0.28 sec) v7.4.0 以降、TiDB の`GROUP BY`句は`WITH ROLLUP`修飾子をサポートします。 -`GROUP BY`句では、1 つ以上の列をグループリストとして指定し、リストの後に`WITH ROLLUP`修飾子を付加できます。すると、TiDB はグループリスト内の列に基づいて多次元降順グループ化を実行し、各グループの要約結果を出力します。 +`GROUP BY`句では、1つ以上の列をグループリストとして指定し、リストの後に`WITH ROLLUP`修飾子を付加できます。すると、TiDB はグループリスト内の列に基づいて多次元降順グループ化を実行し、各グループの要約結果を出力します。 > **Note:** > @@ -188,6 +188,6 @@ explain SELECT year, month, grouping(year), grouping(month), SUM(profit) AS prof 10 rows in set (0.05 sec) ``` -前のステートメントの`GROUP BY year, month WITH ROLLUP`構文に従って、このステートメントの SQL 集計結果は、それぞれ`{year, month}` 、 `{year}` 、 `{}` 3 つのグループに計算され、連結されます。 +前のステートメントの`GROUP BY year, month WITH ROLLUP`構文に従って、このステートメントの SQL 集計結果は、それぞれ`{year, month}` 、 `{year}` 、 `{}` 3つのグループに計算され、連結されます。 詳細については[GROUP BY修飾子](/functions-and-operators/group-by-modifier.md)を参照してください。 diff --git a/explain-index-merge.md b/explain-index-merge.md index ded657f633817..ff2937c45276b 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -81,8 +81,8 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > フィルタ条件のいずれかの選択性が低い場合、オプティマイザは対応するインデックスを直接選択し、理想的な実行効率を実現します。ただし、データ分布が以下の3つの条件をすべて満たす場合は、交差型インデックスマージの使用を検討できます。 - テーブル全体のデータサイズが大きく、テーブル全体を直接読み取るのは非効率的です。 -- 3 つのフィルタ条件のそれぞれについて、それぞれの選択性は非常に高いため、単一のインデックスを使用した`IndexLookUp`の実行効率は理想的ではありません。 -- 3 つのフィルター条件の全体的な選択性は低いです。 +- 3つのフィルタ条件のそれぞれについて、それぞれの選択性は非常に高いため、単一のインデックスを使用した`IndexLookUp`の実行効率は理想的ではありません。 +- 3つのフィルター条件の全体的な選択性は低いです。 交差型インデックスマージを使用してテーブルにアクセスする場合、オプティマイザはテーブルに対して複数のインデックスを使用し、各インデックスから返される結果をマージして、前述の出力例の`IndexMerge`の実行計画を生成することができます。`IndexMerge_9`の演算子の`operator info`の情報`type: intersection`は、この演算子が交差型インデックスマージであることを示しています。実行計画のその他の部分は、前述のユニオン型インデックスマージの例と同様です。 diff --git a/explain-indexes.md b/explain-indexes.md index dc9b8bd25d8b5..ad6bfe64cb001 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -87,7 +87,7 @@ EXPLAIN SELECT * FROM t1 WHERE intkey >= 99 AND intkey <= 103; 3 rows in set (0.00 sec) ``` -`IndexLookup`演算子には 2 つの子ノードがあります。 +`IndexLookup`演算子には 2つの子ノードがあります。 - `├─IndexRangeScan_8(Build)`演算子は`intkey`インデックスの範囲スキャンを実行し、内部の`RowID` (このテーブルの場合は主キー) の値を取得します。 - 次に、 `└─TableRowIDScan_9(Probe)`演算子はテーブル データから完全な行を取得します。 diff --git a/explain-mpp.md b/explain-mpp.md index 57debfd9eee33..eee05ec9e728a 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -52,12 +52,12 @@ EXPLAIN SELECT COUNT(*) FROM t1 GROUP BY id; +------------------------------------+---------+-------------------+---------------+----------------------------------------------------+ ``` -上記の実行計画には、2 つのクエリ フラグメントが含まれています。 +上記の実行計画には、2つのクエリ フラグメントが含まれています。 -- 1 つ目は`[TableFullScan_25, HashAgg_9, ExchangeSender_28]`で、主に第 1 段階の集約を担当します。 +- 1つ目は`[TableFullScan_25, HashAgg_9, ExchangeSender_28]`で、主に第 1 段階の集約を担当します。 - 2 番目は`[ExchangeReceiver_29, HashAgg_27, Projection_26, ExchangeSender_30]`で、主に第 2 段階の集約を担当します。 -`ExchangeSender`演算子の`operator info`列には、交換の種類に関する情報が表示されます。現在、交換の種類は 3 つあります。以下をご覧ください。 +`ExchangeSender`演算子の`operator info`列には、交換の種類に関する情報が表示されます。現在、交換の種類は 3つあります。以下をご覧ください。 - ハッシュパーティション： `ExchangeSender`演算子は、まずハッシュ値に基づいてデータを分割し、次に上流のMPPタスクの`ExchangeReceiver`の演算子にデータを分配します。この交換タイプは、ハッシュ集計やシャッフルハッシュ結合アルゴリズムでよく使用されます。 - ブロードキャスト： `ExchangeSender`演算子は、ブロードキャストを介して上流のMPPタスクにデータを配信します。この交換タイプは、ブロードキャスト結合でよく使用されます。 diff --git a/explain-partitions.md b/explain-partitions.md index a7fe09c359550..5c65402a5d7ba 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -121,6 +121,6 @@ EXPLAIN SELECT COUNT(*) FROM t1 WHERE YEAR(d) = 2017; 上記の出力から: - TiDBは、すべてのパーティション`(p2016..pMax)`にアクセスする必要があると判断します。これは、述語`YEAR(d) = 2017`が[検索引数可能でない](https://en.wikipedia.org/wiki/Sargable)とみなされるためです。これはTiDBに固有の問題ではありません。 -- 各パーティションがスキャンされると、 `Selection`演算子によって 2017 年に一致しない行が除外されます。 +- 各パーティションがスキャンされると、 `Selection`演算子によって 2017年に一致しない行が除外されます。 - 各パーティションでストリーム集約が実行され、一致する行数がカウントされます。 - 演算子`└─PartitionUnion_21`は、各パーティションにアクセスした結果を結合します。 diff --git a/explain-views.md b/explain-views.md index 44c27484f4a16..95929bb8b5cb2 100644 --- a/explain-views.md +++ b/explain-views.md @@ -9,13 +9,13 @@ summary: TiDB の EXPLAIN` ステートメントによって返される実行 -[自転車シェアリングのサンプルデータベース](/import-example-data.md)から、次の 2 つのクエリが同様の方法で実行されていることがわかります。 +[自転車シェアリングのサンプルデータベース](/import-example-data.md)から、次の2つのクエリが同様の方法で実行されていることがわかります。 -[自転車シェアリングのサンプルデータベース](/tidb-cloud/import-sample-data.md)から、次の 2 つのクエリが同様の方法で実行されていることがわかります。 +[自転車シェアリングのサンプルデータベース](/tidb-cloud/import-sample-data.md)から、次の2つのクエリが同様の方法で実行されていることがわかります。 diff --git a/explain-walkthrough.md b/explain-walkthrough.md index d4e7991c2951d..a77f4d212c2fc 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -9,13 +9,13 @@ SQLは宣言型言語であるため、クエリが効率的に実行された -[自転車シェアリングのサンプルデータベース](/import-example-data.md)からの次の文は、2017 年 7 月 1 日に何回旅行が行われたかを数えています。 +[自転車シェアリングのサンプルデータベース](/import-example-data.md)からの次の文は、2017年 7月 1日に何回旅行が行われたかを数えています。 -[自転車シェアリングのサンプルデータベース](/tidb-cloud/import-sample-data.md)からの次の文は、2017 年 7 月 1 日に何回旅行が行われたかを数えています。 +[自転車シェアリングのサンプルデータベース](/tidb-cloud/import-sample-data.md)からの次の文は、2017年 7月 1日に何回旅行が行われたかを数えています。 @@ -40,7 +40,7 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 1. コプロセッサ（TiKV）は、 `trips`テーブル全体を`TableFullScan`演算として読み取ります。その後、読み取った行をTiKV内の`Selection_19`の演算子に渡します。 2. 述語`WHERE start_date BETWEEN ..`は演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18`には`stats:pseudo`と表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。`ANALYZE TABLE trips`を実行して統計情報を収集すると、統計の精度が向上することが期待されます。 -3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、この演算子も TiKV 内にあります ( `cop[tikv]` )。TiKV コプロセッサは、MySQL の組み込み関数を多数実行できます。そのうちの 1 つが`count`です。 +3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、この演算子も TiKV 内にあります ( `cop[tikv]` )。TiKV コプロセッサは、MySQL の組み込み関数を多数実行できます。そのうちの 1つが`count`です。 4. `StreamAgg_9`の結果は、TiDBサーバー内にある`TableReader_21`演算子（ `root`のタスク）に送信されます。この演算子の`estRows`列の値は`1`です。これは、演算子がアクセス対象のTiKVリージョンごとに1行ずつ受け取ることを意味します。これらのリクエストの詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を参照してください。 5. 次に、演算子`StreamAgg_20`は演算子`└─TableReader_21`の各行に関数`count`適用します。これは演算子[`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)からもわかるように、約 56 行になります。これはルート演算子であるため、結果をクライアントに返します。 @@ -93,7 +93,7 @@ Query OK, 0 rows affected (10.22 sec) 5 rows in set (0.93 sec) ``` -`ANALYZE TABLE`を実行すると、演算子`└─TableFullScan_18`推定行数が正確であり、演算子`└─Selection_19`の推定行数も大幅に近づいたことがわかります。上記の 2 つのケースでは、実行計画（TiDB がこのクエリを実行するために使用する演算子セット）は変更されていませんが、統計情報が古くなっているために、最適ではないプランが頻繁に発生します。 +`ANALYZE TABLE`を実行すると、演算子`└─TableFullScan_18`推定行数が正確であり、演算子`└─Selection_19`の推定行数も大幅に近づいたことがわかります。上記の2つのケースでは、実行計画（TiDB がこのクエリを実行するために使用する演算子セット）は変更されていませんが、統計情報が古くなっているために、最適ではないプランが頻繁に発生します。 `ANALYZE TABLE`に加えて、TiDB はしきい値[`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio)に達した後、バックグラウンド操作として統計情報を自動的に再生成します。[`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)ステートメントを実行すると、TiDB がこのしきい値にどれだけ近いか（TiDB が統計情報をどの程度健全であると見なしているか）を確認できます。 @@ -193,7 +193,7 @@ EXPLAIN ANALYZE SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 4 rows in set (0.00 sec) ``` -上記の結果から、クエリ時間は 1.03 秒から 0.0 秒に短縮されました。 +上記の結果から、クエリ時間は 1.03秒から 0.0秒に短縮されました。 > **Note:** > diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 8bad1875b9a57..99d21c8ad577a 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -17,7 +17,7 @@ TiDB がサポートするオペレーティング システムについては TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェア・サーバー・プラットフォーム、またはARMアーキテクチャのハードウェア・サーバー・プラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバー・ハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)を参照してください。 -### 10 ギガビットのネットワーク カード 2 枚の目的は何ですか? {#whats-the-purposes-of-2-network-cards-of-10-gigabit} +### 10 ギガビットのネットワーク カード 2枚の目的は何ですか? {#whats-the-purposes-of-2-network-cards-of-10-gigabit} 分散型クラスタであるTiDBは、特にPDに対して高い時間要件を要求します。これは、PDが一意のタイムスタンプを配布する必要があるためです。PDサーバーの時刻が一致していないと、PDサーバーを切り替える際に待機時間が長くなります。2枚のネットワークカードの結合によりデータ転送の安定性が保証され、10ギガビットの速度により転送速度が保証されます。ギガビットネットワークカードはボトルネックになりやすいため、10ギガビットネットワークカードの使用を強くお勧めします。 diff --git a/faq/high-availability-faq.md b/faq/high-availability-faq.md index 2df637a2cb337..8a53babe205d3 100644 --- a/faq/high-availability-faq.md +++ b/faq/high-availability-faq.md @@ -13,6 +13,6 @@ summary: TiDB の高可用性に関連する FAQ について説明します。 最下層では、TiKVはレプリケーションログ＋ステートマシンのモデルを用いてデータを複製します。書き込みリクエストの場合、データはLeaderに書き込まれ、Leaderはログの形式でコマンドをフォロワーに複製します。クラスター内の過半数のノードがこのログを受信すると、ログはコミットされ、ステートマシンに適用できるようになります。 -## 地理的に分散した 3 つのデータセンターを展開する場合に推奨されるソリューションは何ですか? {#what-s-the-recommended-solution-for-the-deployment-of-three-geo-distributed-data-centers} +## 地理的に分散した 3つのデータセンターを展開する場合に推奨されるソリューションは何ですか? {#what-s-the-recommended-solution-for-the-deployment-of-three-geo-distributed-data-centers} -TiDBのアーキテクチャは、地理的分散とマルチアクティブ性を完全にサポートすることを保証します。データとアプリケーションは常時稼働です。すべての障害はアプリケーションに対して透過的であり、データは自動的に復旧できます。動作はネットワークのレイテンシーと安定性に依存します。レイテンシーは5ミリ秒以内に抑えることを推奨します。現在、TiDBには同様のユースケースが既に存在します。詳細については、 [2 つの地域に配置された 3 つのデータ センター](/three-data-centers-in-two-cities-deployment.md)ご覧ください。 +TiDBのアーキテクチャは、地理的分散とマルチアクティブ性を完全にサポートすることを保証します。データとアプリケーションは常時稼働です。すべての障害はアプリケーションに対して透過的であり、データは自動的に復旧できます。動作はネットワークのレイテンシーと安定性に依存します。レイテンシーは5ミリ秒以内に抑えることを推奨します。現在、TiDBには同様のユースケースが既に存在します。詳細については、 [2つの地域に配置された 3つのデータ センター](/three-data-centers-in-two-cities-deployment.md)ご覧ください。 diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index 73b453664d8d5..f0017e9905367 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -206,7 +206,7 @@ DDLリクエストを受信するTiDBサーバーインスタンスが、DDLオ - 複数のDDLステートメントを同時に実行する場合、最後の数個のDDLステートメントの実行速度が遅くなる可能性があります。これは、TiDBクラスタではDDLステートメントが直列に実行されるためです。 - クラスターが正常に起動した後、最初のDDL操作の実行には通常30秒程度かかる場合があります。これは、TiDBクラスターがDDLステートメントを処理するリーダーを選出しているためです。 -- TiDB の起動後最初の 10 分間の DDL ステートメントの処理時間は、以下の条件を満たす場合、通常よりもはるかに長くなります。1) TiDB を停止する際に、TiDB が通常のように PD と通信できない場合 (停電の場合を含む)。2) TiDB が`kill -9`コマンドで停止されたため、TiDB が PD から登録データを適時にクリーンアップできない場合。この期間中に DDL ステートメントを実行すると、各 DDL の状態変更に対して、2 * リース (リース = 45 秒) の待機時間が必要になります。 +- TiDB の起動後最初の 10分間の DDL ステートメントの処理時間は、以下の条件を満たす場合、通常よりもはるかに長くなります。1) TiDB を停止する際に、TiDB が通常のように PD と通信できない場合 (停電の場合を含む)。2) TiDB が`kill -9`コマンドで停止されたため、TiDB が PD から登録データを適時にクリーンアップできない場合。この期間中に DDL ステートメントを実行すると、各 DDL の状態変更に対して、2 * リース (リース = 45秒) の待機時間が必要になります。 - クラスタ内のTiDBサーバーとPDサーバー間で通信障害が発生した場合、TiDBサーバーはPDサーバーからバージョン情報をタイムリーに取得または更新できません。この場合、各DDLの状態処理にはリース期間の2倍の時間待機する必要があります。 ### TiDBのバックエンドストレージエンジンとしてS3を使用できますか？ {#can-i-use-s3-as-the-backend-storage-engine-in-tidb} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index 495f76ac9c098..49701ae4956de 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -70,7 +70,7 @@ MySQLでは、クエリが単一スレッドで実行されるため、結果の > ``が指定されていない場合、 ``によって指定されたテーブルは T であり、T 内の行の順序は実装に依存します。 -次の 2 つのクエリでは、両方の結果が正当であると見なされます。 +次の2つのクエリでは、両方の結果が正当であると見なされます。 ```sql > select * from t; @@ -340,7 +340,7 @@ TiDB v6.2.0以降、TiDB DDLモジュールは並列フレームワークを採 ### JDBC URL で`connectionCollation`が構成されていない場合、JDBC 接続ではどの照合順序が使用されますか? {#what-collation-is-used-in-a-jdbc-connection-when-connectioncollation-is-not-configured-in-the-jdbc-url} -JDBC URL に`connectionCollation`が設定されていない場合、次の 2 つのシナリオが考えられます。 +JDBC URL に`connectionCollation`が設定されていない場合、次の2つのシナリオが考えられます。 **シナリオ 1** : JDBC URL に`connectionCollation`も`characterEncoding`も設定されていない @@ -444,8 +444,8 @@ RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganiz ### DDL ジョブを表示するにはどうすればいいですか? {#how-to-view-the-ddl-job} - `ADMIN SHOW DDL` : 実行中のDDLジョブを表示する -- `ADMIN SHOW DDL JOBS` : 現在の DDL ジョブ キュー内のすべての結果 (実行中および実行待ちのタスクを含む) と、完了した DDL ジョブ キューの最後の 10 件の結果を表示します。 -- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...` : `job_id`に対応する DDL タスクの元の SQL ステートメントを表示します。`job_id`は実行中の DDL ジョブと DDL 履歴ジョブ キュー内の最後の 10 件の結果のみを検索します。 +- `ADMIN SHOW DDL JOBS` : 現在の 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} @@ -461,7 +461,7 @@ RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganiz ### TiDBクエリプランでは、 `cop`タスクは同じルートにあります。それらは同時に実行されますか？ {#in-the-tidb-query-plan-cop-tasks-are-in-the-same-root-are-they-executed-concurrently} -現在、 TiDB のコンピューティング タスクは、タスク`cop task`と`root task`の 2 つの異なるタイプに属しています。 +現在、 TiDB のコンピューティング タスクは、タスク`cop task`と`root task`の 2つの異なるタイプに属しています。 `cop task`は、分散実行のために KV エンドにプッシュダウンされるコンピューティング タスクです。`root task` 、TiDB エンドでの単一ポイント実行のためのコンピューティング タスクです。 diff --git a/filter-binlog-event.md b/filter-binlog-event.md index 744735c3b21df..0d311c349c0cc 100644 --- a/filter-binlog-event.md +++ b/filter-binlog-event.md @@ -90,7 +90,7 @@ filters: ### シャーディングされたスキーマとテーブルのDML操作のみを移行する {#migrate-only-dml-operations-of-sharded-schemas-and-tables} -DML ステートメントのみをレプリケートするには、次に示すように`Binlog event filter rule`を 2 つ設定します。 +DML ステートメントのみをレプリケートするには、次に示すように`Binlog event filter rule`を 2つ設定します。 ``` filters: diff --git a/follower-read.md b/follower-read.md index 5b437b4e4e8c4..2e26f3ed3d7a6 100644 --- a/follower-read.md +++ b/follower-read.md @@ -79,7 +79,7 @@ set [session | global] tidb_replica_read = ''; - `tidb_replica_read`の値が`closest-adaptive`に設定されている場合: - - 読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の値である場合、TiDB は読み取り操作に同じアベイラビリティ ゾーン内のレプリカを選択することを優先します。 アベイラビリティ ゾーン間で読み取りトラフィックの不均衡な分散を回避するために、TiDB はすべてのオンライン TiDB および TiKV ノードのアベイラビリティ ゾーンの分散を動的に検出します。各アベイラビリティ ゾーンでは、 `closest-adaptive`構成が有効になる TiDB ノードの数は制限されており、これは常に TiDB ノードが最も少ないアベイラビリティ ゾーン内の TiDB ノードの数と同じであり、その他の TiDB ノードは自動的にリーダー レプリカから読み取ります。たとえば、TiDB ノードが 3 つのアベイラビリティ ゾーン (A、B、C) に分散されていて、A と B にそれぞれ 3 つの TiDB ノードが含まれ、C には 2 つの TiDB ノードのみが含まれる場合、各アベイラビリティ ゾーンで`closest-adaptive`構成が有効になる TiDB ノードの数は 2 であり、A および B アベイラビリティ ゾーンのそれぞれのその他の TiDB ノードは読み取り操作にリーダー レプリカを自動的に選択します。 + - 読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の値である場合、TiDB は読み取り操作に同じアベイラビリティ ゾーン内のレプリカを選択することを優先します。 アベイラビリティ ゾーン間で読み取りトラフィックの不均衡な分散を回避するために、TiDB はすべてのオンライン TiDB および TiKV ノードのアベイラビリティ ゾーンの分散を動的に検出します。各アベイラビリティ ゾーンでは、 `closest-adaptive`構成が有効になる TiDB ノードの数は制限されており、これは常に TiDB ノードが最も少ないアベイラビリティ ゾーン内の TiDB ノードの数と同じであり、その他の TiDB ノードは自動的にリーダー レプリカから読み取ります。たとえば、TiDB ノードが 3つのアベイラビリティ ゾーン (A、B、C) に分散されていて、A と B にそれぞれ 3つの TiDB ノードが含まれ、C には 2つの TiDB ノードのみが含まれる場合、各アベイラビリティ ゾーンで`closest-adaptive`構成が有効になる TiDB ノードの数は 2 であり、A および B アベイラビリティ ゾーンのそれぞれのその他の TiDB ノードは読み取り操作にリーダー レプリカを自動的に選択します。 - 読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)の値未満の場合、TiDB は読み取り操作に対してリーダー レプリカのみを選択できます。 - `tidb_replica_read`を`learner`に設定すると、TiDB はラーナーレプリカからデータを読み取ります。現在のリージョンで利用可能なラーナーレプリカがない場合、TiDB は利用可能なリーダーレプリカまたはフォロワーレプリカからデータを読み取ります。 diff --git a/foreign-key.md b/foreign-key.md index 4d05a860a38aa..2d9c0a2710381 100644 --- a/foreign-key.md +++ b/foreign-key.md @@ -94,7 +94,7 @@ CREATE TABLE child ( ); ``` -以下は`product_order`テーブルに、他の 2 つのテーブルを参照する 2 つの外部キーがある、より複雑な例です。一方の外部キーは`product`テーブルの 2 つのインデックスを参照し、もう一方の外部キーは`customer`テーブルの 1 つのインデックスを参照します。 +以下は`product_order`テーブルに、他の 2つのテーブルを参照する 2つの外部キーがある、より複雑な例です。一方の外部キーは`product`テーブルの 2つのインデックスを参照し、もう一方の外部キーは`customer`テーブルの 1つのインデックスを参照します。 ```sql CREATE TABLE product ( diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index 6470265e8d7ad..57c11671be22c 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -132,7 +132,7 @@ select distinct a, b from t order by c; 結果を順序付けるには、まず重複を排除する必要があります。しかし、そのためにはどの行を保持すべきでしょうか？ この選択は「c」の保持値に影響し、さらに順序付けにも影響を与え、結果的に順序付けを恣意的なものにしてしまいます。 -MySQL では、 `DISTINCT`と`ORDER BY`含むクエリは、 `ORDER BY`式のいずれかが以下の条件の少なくとも 1 つを満たしていない場合、無効として拒否されます。 +MySQL では、 `DISTINCT`と`ORDER BY`含むクエリは、 `ORDER BY`式のいずれかが以下の条件の少なくとも 1つを満たしていない場合、無効として拒否されます。 - 式は`SELECT`リストの1に等しい - 式によって参照され、クエリの選択されたテーブルに属するすべての列は、 `SELECT`リストの要素です。 diff --git a/functions-and-operators/bit-functions-and-operators.md b/functions-and-operators/bit-functions-and-operators.md index 4bfed50fc7789..ce7d1f95b093c 100644 --- a/functions-and-operators/bit-functions-and-operators.md +++ b/functions-and-operators/bit-functions-and-operators.md @@ -100,7 +100,7 @@ SELECT CONV(b'1010' & b'1000',10,2); `&`演算子を`INET_NTOA()`および`INET_ATON()`関数と組み合わせて使用​​すると、IP アドレスとネットワークマスクのビット単位の AND 演算を実行し、ネットワークアドレスを取得できます。これは、複数の IP アドレスが同じネットワークに属しているかどうかを判断するのに役立ちます。 -次の 2 つの例では、 IP アドレス`192.168.1.1`と`192.168.1.2`は、 `255.255.255.0`でマスクされているときに同じネットワーク`192.168.1.0/24`内にあります。 +次の2つの例では、 IP アドレス`192.168.1.1`と`192.168.1.2`は、 `255.255.255.0`でマスクされているときに同じネットワーク`192.168.1.0/24`内にあります。 ```sql SELECT INET_NTOA(INET_ATON('192.168.1.1') & INET_ATON('255.255.255.0')); @@ -172,7 +172,7 @@ SELECT CONV(~ b'1111111111111111111111111111111111111111111111110000111100001111 `|`演算子はビットごとのOR演算を実行します。2つの数値の対応するビットを比較します。対応するビットの少なくとも1つが1の場合、結果の対応するビットも1になります。 -たとえば、 `1010`と`1100`ビット単位の OR 演算では`1110`が返されます。これは、 2 つの数値の最初の 3 ビットのうち、対応するビットの少なくとも 1 つが 1 に設定されているためです。 +たとえば、 `1010`と`1100`ビット単位の OR 演算では`1110`が返されます。これは、 2つの数値の最初の 3 ビットのうち、対応するビットの少なくとも 1つが 1 に設定されているためです。 ``` 1010 @@ -200,7 +200,7 @@ SELECT CONV(b'1010' | b'1100',10,2); `^`演算子はビット単位のXOR（排他的論理和）演算を実行します。2つの数値の対応するビットを比較します。対応するビットが異なる場合、結果の対応するビットは1になります。 -たとえば、 `1010`と`1100`ビット単位の XOR 演算では、 2 つの数値の 2 番目と 3 番目のビットが異なるため、 `0110`が返されます。 +たとえば、 `1010`と`1100`ビット単位の XOR 演算では、 2つの数値の 2 番目と 3 番目のビットが異なるため、 `0110`が返されます。 ``` 1010 diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 2a9ba87bc45a3..e36672aebbde3 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -7,7 +7,7 @@ summary: TiDB GROUP BY 修飾子の使用方法を学習します。 v7.4.0 以降、TiDB の`GROUP BY`句は`WITH ROLLUP`修飾子をサポートします。 -`GROUP BY`句では、1 つ以上の列をグループリストとして指定し、リストの後に`WITH ROLLUP`修飾子を付加できます。すると、TiDB はグループリスト内の列に基づいて多次元降順グループ化を実行し、各グループの要約結果を出力します。 +`GROUP BY`句では、1つ以上の列をグループリストとして指定し、リストの後に`WITH ROLLUP`修飾子を付加できます。すると、TiDB はグループリスト内の列に基づいて多次元降順グループ化を実行し、各グループの要約結果を出力します。 - グループ化方法: @@ -24,7 +24,7 @@ v7.4.0 以降、TiDB の`GROUP BY`句は`WITH ROLLUP`修飾子をサポートし SELECT count(1) FROM t GROUP BY a,b,c WITH ROLLUP; ``` -この例では、TiDB は`count(1)`の計算結果を 4 つのグループ (つまり`{a, b, c}` 、 `{a, b}` 、 `{a}` 、 `{}` ) に集計し、各グループの概要結果を出力します。 +この例では、TiDB は`count(1)`の計算結果を 4つのグループ (つまり`{a, b, c}` 、 `{a, b}` 、 `{a}` 、 `{}` ) に集計し、各グループの概要結果を出力します。 > **Note:** > @@ -100,7 +100,7 @@ SELECT year, month, SUM(profit) AS profit from bank GROUP BY year, month WITH RO 6 rows in set (0.025 sec) ``` -上記の結果には、年と月の両方、年ごと、全体という異なるディメンションで集計されたデータが含まれています。結果において、 `NULL`値が存在しない行は、その行の`profit`が年と月の両方をグループ化して計算されていることを示します。`month`列の値が`NULL`である行は、その行の`profit`が 1 年間のすべての月を集計して計算されていることを示し、 `year`列の値が`NULL`である行は、その行の`profit`がすべての年を集計して計算されていることを示します。 +上記の結果には、年と月の両方、年ごと、全体という異なるディメンションで集計されたデータが含まれています。結果において、 `NULL`値が存在しない行は、その行の`profit`が年と月の両方をグループ化して計算されていることを示します。`month`列の値が`NULL`である行は、その行の`profit`が 1年間のすべての月を集計して計算されていることを示し、 `year`列の値が`NULL`である行は、その行の`profit`がすべての年を集計して計算されていることを示します。 具体的には： diff --git a/functions-and-operators/json-functions/json-functions-aggregate.md b/functions-and-operators/json-functions/json-functions-aggregate.md index 2fc1d01edcfad..4e9ba57fa183d 100644 --- a/functions-and-operators/json-functions/json-functions-aggregate.md +++ b/functions-and-operators/json-functions/json-functions-aggregate.md @@ -15,7 +15,7 @@ TiDB は MySQL 8.0 で利用可能な[2つの集計JSON関数](https://dev.mysql 例： -ここでは、テーブルの 1 つの列にある 2 つの行が JSON 配列に集約されます。 +ここでは、テーブルの 1つの列にある 2つの行が JSON 配列に集約されます。 ```sql SELECT JSON_ARRAYAGG(v) FROM (SELECT 1 'v' UNION SELECT 2); @@ -36,7 +36,7 @@ SELECT JSON_ARRAYAGG(v) FROM (SELECT 1 'v' UNION SELECT 2); 例： -まず、2 つのテーブルを作成し、そこにいくつかの行を追加します。 +まず、2つのテーブルを作成し、そこにいくつかの行を追加します。 ```sql CREATE TABLE plants ( diff --git a/functions-and-operators/json-functions/json-functions-modify.md b/functions-and-operators/json-functions/json-functions-modify.md index 8f7870e66378e..9b90b5519b3ae 100644 --- a/functions-and-operators/json-functions/json-functions-modify.md +++ b/functions-and-operators/json-functions/json-functions-modify.md @@ -89,7 +89,7 @@ SELECT JSON_ARRAY_INSERT('["Car", "Boat", "Train"]', '$[1]', "Airplane") AS "Tra ## `JSON_INSERT()` {#json_insert} -`JSON_INSERT(json_doc, path, value [,path, value] ...)`関数は、JSON ドキュメントに 1 つ以上の値を挿入し、結果を返します。 +`JSON_INSERT(json_doc, path, value [,path, value] ...)`関数は、JSON ドキュメントに 1つ以上の値を挿入し、結果を返します。 この関数は引数をペアで受け取ります。各ペアは`path`と`value`です。 @@ -152,7 +152,7 @@ SELECT JSON_MERGE_PATCH( ## `JSON_MERGE_PRESERVE()` {#json_merge_preserve} -`JSON_MERGE_PRESERVE(json_doc, json_doc [,json_doc] ...)`関数は、各キーに関連付けられたすべての値を保持しながら 2 つ以上の JSON ドキュメントをマージし、マージされた結果を返します。 +`JSON_MERGE_PRESERVE(json_doc, json_doc [,json_doc] ...)`関数は、各キーに関連付けられたすべての値を保持しながら 2つ以上の JSON ドキュメントをマージし、マージされた結果を返します。 例: diff --git a/functions-and-operators/json-functions/json-functions-return.md b/functions-and-operators/json-functions/json-functions-return.md index 83fb0e2de5fde..e563b04870330 100644 --- a/functions-and-operators/json-functions/json-functions-return.md +++ b/functions-and-operators/json-functions/json-functions-return.md @@ -13,7 +13,7 @@ TiDB は、MySQL 8.0 で利用可能な[JSON値属性を返すJSON関数](https: 例: -次の例では、レベルが 3 つあるため、 `JSON_DEPTH()` `3`を返します。 +次の例では、レベルが 3つあるため、 `JSON_DEPTH()` `3`を返します。 - ルート（ `$` ） - 天気 ( `$.weather` ) @@ -53,7 +53,7 @@ SELECT JSON_LENGTH('{"weather": {"current": "sunny", "tomorrow": "cloudy"}}','$' 1 row in set (0.00 sec) ``` -次の例では、 `$.weather`に`current`と`tomorrow` 2 つの項目があるため、返される値は`2`なります。 +次の例では、 `$.weather`に`current`と`tomorrow` 2つの項目があるため、返される値は`2`なります。 ```sql SELECT JSON_LENGTH('{"weather": {"current": "sunny", "tomorrow": "cloudy"}}','$.weather'); diff --git a/functions-and-operators/json-functions/json-functions-search.md b/functions-and-operators/json-functions/json-functions-search.md index a206c63521f92..3816c53520d9b 100644 --- a/functions-and-operators/json-functions/json-functions-search.md +++ b/functions-and-operators/json-functions/json-functions-search.md @@ -210,7 +210,7 @@ FROM ( 例: -次の例では、JSON ドキュメント内の 2 つの最上位キーを返します。 +次の例では、JSON ドキュメント内の 2つの最上位キーを返します。 ```sql SELECT JSON_KEYS('{"name": {"first": "John", "last": "Doe"}, "type": "Person"}'); @@ -242,7 +242,7 @@ SELECT JSON_KEYS('{"name": {"first": "John", "last": "Doe"}, "type": "Person"}', ## `JSON_SEARCH()` {#json_search} -`JSON_SEARCH(json_doc, one_or_all, str)`関数は、JSON ドキュメントで文字列の 1 つまたはすべての一致を検索します。 +`JSON_SEARCH(json_doc, one_or_all, str)`関数は、JSON ドキュメントで文字列の 1つまたはすべての一致を検索します。 例: diff --git a/functions-and-operators/json-functions/json-functions-validate.md b/functions-and-operators/json-functions/json-functions-validate.md index 69d23eb57b5fe..a1bc470e06ee4 100644 --- a/functions-and-operators/json-functions/json-functions-validate.md +++ b/functions-and-operators/json-functions/json-functions-validate.md @@ -198,7 +198,7 @@ SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array", "minItems" 1 row in set (0.00 sec) ``` -上記の出力は、 `fruits`少なくとも 3 つの項目を持つ配列であることを示しています。 +上記の出力は、 `fruits`少なくとも 3つの項目を持つ配列であることを示しています。 ```sql SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array", "minItems": 4}}}',@j); @@ -213,7 +213,7 @@ SELECT JSON_SCHEMA_VALID('{"properties": {"fruits": {"type": "array", "minItems" 1 row in set (0.00 sec) ``` -上記の出力から、 `fruits`は少なくとも 4 つの項目を持つ配列では**ないこと**がわかります。これは、最小項目数を満たしていないためです。 +上記の出力から、 `fruits`は少なくとも 4つの項目を持つ配列では**ないこと**がわかります。これは、最小項目数を満たしていないためです。 整数値の場合、特定の範囲内にあるかどうかを確認できます。 diff --git a/functions-and-operators/locking-functions.md b/functions-and-operators/locking-functions.md index c6fe6f9e62733..c25c4cfa69f05 100644 --- a/functions-and-operators/locking-functions.md +++ b/functions-and-operators/locking-functions.md @@ -19,7 +19,7 @@ TiDB は、MySQL 8.0 で利用可能なユーザー レベル[ロック関数](h ## MySQLとの互換性 {#mysql-compatibility} -- TiDB で許可される最小タイムアウトは 1 秒、最大タイムアウトは 1 時間 (3600 秒) です。これは、0 秒と無制限 ( `timeout=-1` ) の両方のタイムアウトが許可されている MySQL とは異なります。TiDB は範囲外の値を最も近い許容値に自動的に変換し、 `timeout=-1`は 3600 秒に変換されます。 +- TiDB で許可される最小タイムアウトは 1秒、最大タイムアウトは 1時間 (3600秒) です。これは、0秒と無制限 ( `timeout=-1` ) の両方のタイムアウトが許可されている MySQL とは異なります。TiDB は範囲外の値を最も近い許容値に自動的に変換し、 `timeout=-1`は 3600秒に変換されます。 - TiDBは、ユーザーレベルロックによるデッドロックを自動的に検出しません。デッドロックが発生したセッションは最大1時間後にタイムアウトしますが、影響を受けたセッションのいずれかで[`KILL`](/sql-statements/sql-statement-kill.md)を使用することで手動で解決することもできます。また、ユーザーレベルロックを常に同じ順序で取得することで、デッドロックを防ぐこともできます。 - ロックはクラスタ内のすべてのTiDBサーバーで有効になります。これは、ロックが単一のサーバーにローカルであるMySQL クラスタやグループレプリケーションとは異なります。 - `IS_USED_LOCK()` 、別のセッションから呼び出され、ロックを保持しているプロセスの ID を返すことができない場合は`1`を返します。 diff --git a/functions-and-operators/miscellaneous-functions.md b/functions-and-operators/miscellaneous-functions.md index 5150160d8f33f..01a68b6968122 100644 --- a/functions-and-operators/miscellaneous-functions.md +++ b/functions-and-operators/miscellaneous-functions.md @@ -25,7 +25,7 @@ TiDB は、MySQL 8.0 で利用可能な[その他の関数](https://dev.mysql.co | [`IS_IPV6()`](#is_ipv6) | 引数が IPv6 アドレスかどうか | | [`IS_UUID()`](#is_uuid) | 引数がUUIDかどうか | | [`NAME_CONST()`](#name_const) | 列名を変更するために使用できます | -| [`SLEEP()`](#sleep) | 指定された秒数だけスリープします。TiDB [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスの場合、 `SLEEP()`関数には制限があり、最大スリープ時間は 300 秒までしかサポートされないことに注意してください。 | +| [`SLEEP()`](#sleep) | 指定された秒数だけスリープします。TiDB [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスの場合、 `SLEEP()`関数には制限があり、最大スリープ時間は 300秒までしかサポートされないことに注意してください。 | | [`UUID()`](#uuid) | ユニバーサル一意識別子（UUID）を返します。 | | [`UUID_TO_BIN()`](#uuid_to_bin) | UUIDをテキスト形式からバイナリ形式に変換する | | [`VALUES()`](#values) | INSERT時に使用される値を定義します | @@ -57,11 +57,11 @@ SELECT ANY_VALUE(id),GROUP_CONCAT(id),name FROM fruits GROUP BY name; 4 rows in set (0.00 sec) ``` -前述の例では、 `SELECT`列が非集計列であり、 `id`句に含まれていないため、TiDB は最初の`GROUP BY`ステートメントに対してエラーを返します。この問題を解決するために、2 番目の`SELECT`クエリでは、 `ANY_VALUE()`を使用して各グループから任意の値を取得し、 `GROUP_CONCAT()`を使用して各グループ内の`id`列のすべての値を単一の文字列に連結します。この方法により、非集計列の SQL モードを変更することなく、各グループから 1 つの値とグループ内のすべての値を取得できます。 +前述の例では、 `SELECT`列が非集計列であり、 `id`句に含まれていないため、TiDB は最初の`GROUP BY`ステートメントに対してエラーを返します。この問題を解決するために、2 番目の`SELECT`クエリでは、 `ANY_VALUE()`を使用して各グループから任意の値を取得し、 `GROUP_CONCAT()`を使用して各グループ内の`id`列のすべての値を単一の文字列に連結します。この方法により、非集計列の SQL モードを変更することなく、各グループから 1つの値とグループ内のすべての値を取得できます。 ### BIN_TO_UUID() {#bin_to_uuid} -`BIN_TO_UUID()`と`UUID_TO_BIN()`は、テキスト形式の UUID とバイナリ形式の UUID を相互に変換するために使用できます。どちらの関数も 2 つの引数を受け取ります。 +`BIN_TO_UUID()`と`UUID_TO_BIN()`は、テキスト形式の UUID とバイナリ形式の UUID を相互に変換するために使用できます。どちらの関数も 2つの引数を受け取ります。 - 最初の引数は、変換する値を指定します。 - 2番目の引数（オプション）は、バイナリ形式におけるフィールドの順序を制御します。 diff --git a/functions-and-operators/set-operators.md b/functions-and-operators/set-operators.md index 41fa672d2c864..aa3a8c49b217e 100644 --- a/functions-and-operators/set-operators.md +++ b/functions-and-operators/set-operators.md @@ -9,7 +9,7 @@ TiDBは、UNION、EXCEPT、INTERSECT演算子を使用した3つの集合演算 ## UNION演算子 {#union-operator} -数学では、2 つの集合 A と B の和集合は、A または B に含まれるすべての要素から構成されます。例: +数学では、2つの集合 A と B の和集合は、A または B に含まれるすべての要素から構成されます。例: ```sql SELECT 1 UNION SELECT 2; @@ -58,7 +58,7 @@ SELECT * FROM t1 UNION ALL SELECT * FROM t2; ## EXCEPT演算子 {#except-operator} -A と B が 2 つのセットである場合、EXCEPT は、A にはあるが B にはない要素で構成される A と B の差セットを返します。 +A と B が 2つのセットである場合、EXCEPT は、A にはあるが B にはない要素で構成される A と B の差セットを返します。 ```sql SELECT * FROM t1 EXCEPT SELECT * FROM t2; @@ -74,7 +74,7 @@ SELECT * FROM t1 EXCEPT SELECT * FROM t2; ## INTERSECT演算子 {#intersect-operator} -数学では、2 つの集合 A と B の交差は、A と B の両方に含まれるすべての要素で構成され、他の要素は含まれません。 +数学では、2つの集合 A と B の交差は、A と B の両方に含まれるすべての要素で構成され、他の要素は含まれません。 ```sql SELECT * FROM t1 INTERSECT SELECT * FROM t2; diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index 7250ffdc7f6a1..a0fc3e352a068 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -237,7 +237,7 @@ SELECT CustomerName, CHAR_LENGTH(CustomerName) AS LengthOfName FROM Customers; ### `CONCAT()` {#concat} -`CONCAT()`関数は、1 つ以上の引数を 1 つの文字列に連結します。 +`CONCAT()`関数は、1つ以上の引数を 1つの文字列に連結します。 構文： @@ -362,7 +362,7 @@ SELECT CONCAT_WS(',', 'TiDB Server', 'TiKV', 'PD'); +----------------------------------------------+ ``` -- 連結される引数の 1 つだけが`NULL`でない場合、 `CONCAT_WS()`はその引数を返します。 +- 連結される引数の 1つだけが`NULL`でない場合、 `CONCAT_WS()`はその引数を返します。 例： @@ -453,7 +453,7 @@ EXPORT_SET(bits, on, off, [separator[, number_of_bits]]) 例: -次の例では、 `number_of_bits` `5`に設定され、 `|`で区切られた 5 つの値が生成されます。3 ビットしか指定されていないため、残りのビットは未設定とみなされます。したがって、 `number_of_bits`を`101`または`00101`に設定しても同じ出力になります。 +次の例では、 `number_of_bits` `5`に設定され、 `|`で区切られた 5つの値が生成されます。3 ビットしか指定されていないため、残りのビットは未設定とみなされます。したがって、 `number_of_bits`を`101`または`00101`に設定しても同じ出力になります。 ```sql SELECT EXPORT_SET(b'101',"ON",'off','|',5); @@ -932,10 +932,10 @@ SELECT LENGTH(NULL); `LIKE`演算子は単純な文字列マッチングに使用されます。式`expr LIKE pat [ESCAPE 'escape_char']` `1` ( `TRUE` ) または`0` ( `FALSE` ) を返します。`expr`または`pat`のいずれかが`NULL`の場合、結果は`NULL`になります。 -`LIKE`では次の 2 つのワイルドカード パラメータを使用できます。 +`LIKE`では次の2つのワイルドカード パラメータを使用できます。 - `%` 、ゼロ文字を含む任意の数の文字に一致します。 -- `_` 1 つの文字と一致します。 +- `_` 1つの文字と一致します。 次の例では、 `utf8mb4_bin`照合順序を使用しています。 @@ -1071,7 +1071,7 @@ SELECT '🍣🍺Sushi🍣🍺' COLLATE utf8mb4_unicode_ci LIKE '%SUSHI%' AS resu - 部分文字列`substr` `str`に存在しない場合、関数は`0`を返します。 - いずれかの引数が`NULL`の場合、関数は`NULL`を返します。 -- この関数はマルチバイトセーフであり、少なくとも 1 つの引数がバイナリ文字列である場合にのみ大文字と小文字を区別した検索を実行します。 +- この関数はマルチバイトセーフであり、少なくとも 1つの引数がバイナリ文字列である場合にのみ大文字と小文字を区別した検索を実行します。 次の例では、 `utf8mb4_bin`照合順序を使用しています。 @@ -1431,7 +1431,7 @@ SELECT MAKE_SET(b'100','foo','bar','baz'); 1 row in set (0.00 sec) ``` -次の例では、すべてのビットが`1`あるため、関数は 3 つの文字列すべてをコンマ区切りの結果セットで返します。 +次の例では、すべてのビットが`1`あるため、関数は 3つの文字列すべてをコンマ区切りの結果セットで返します。 ```sql SELECT MAKE_SET(b'111','foo','bar','baz'); @@ -1666,7 +1666,7 @@ SELECT QUOTE(0x002774657374); 例: -この例では、いくつかの文字列が 2 つの正規表現と照合されます。 +この例では、いくつかの文字列が 2つの正規表現と照合されます。 ```sql WITH vals AS ( @@ -1919,7 +1919,7 @@ SELECT REGEXP_LIKE('abc','^A','i'); 例: -次の例では、 2 つの o が`i`に置き換えられます。 +次の例では、 2つの o が`i`に置き換えられます。 ```sql SELECT REGEXP_REPLACE('TooDB', 'o{2}', 'i'); @@ -2116,7 +2116,7 @@ SELECT REPEAT('ha',3); ### `STRCMP()` {#strcmp} -2 つの文字列を比較します。 +2つの文字列を比較します。 ### `SUBSTR()` {#substr} diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 6615987c86231..1af77ff0ed4bf 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -65,7 +65,7 @@ summary: TiDB 固有の関数の使用法について学習します。 例: -ユーザー`user1`を作成し、リソース グループ`rg1`と`rg2` 2 つのリソース グループを作成し、ユーザー`user1`リソース グループ`rg1`にバインドします。 +ユーザー`user1`を作成し、リソース グループ`rg1`と`rg2` 2つのリソース グループを作成し、ユーザー`user1`リソース グループ`rg1`にバインドします。 ```sql CREATE USER 'user1'; @@ -338,7 +338,7 @@ SELECT TIDB_DECODE_SQL_DIGESTS(@digests, 10); 1 row in set (0.01 sec) ``` -上記の呼び出しでは、2 番目のパラメーター (つまり、切り捨ての長さ) を 10 に指定していますが、クエリ結果の 3 番目のステートメントの長さは 10 を超えています。したがって、最初の 10 文字のみが保持され、最後に切り捨てを示す`"..."`が追加されます。 +上記の呼び出しでは、2 番目のパラメーター (つまり、切り捨ての長さ) を10に指定していますが、クエリ結果の 3 番目のステートメントの長さは 10 を超えています。したがって、最初の 10 文字のみが保持され、最後に切り捨てを示す`"..."`が追加されます。 参照: @@ -398,7 +398,7 @@ SELECT TIDB_IS_DDL_OWNER(); `TIDB_PARSE_TSO()`関数は、TiDB TSO タイムスタンプから物理タイムスタンプを抽出します。[TSO](/tso.md)は Time Stamp Oracle を表し、PD (Placement Driver) によってトランザクションごとに発行される単調に増加するタイムスタンプです。 -TSO は次の 2 つの部分で構成される数値です。 +TSO は次の2つの部分で構成される数値です。 - 物理的なタイムスタンプ - 論理的なカウンター diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md index c9d6b62a6f469..3456987e572ad 100644 --- a/functions-and-operators/window-functions.md +++ b/functions-and-operators/window-functions.md @@ -105,7 +105,7 @@ FROM ( `FIRST_VALUE(expr)`は、ウィンドウ内の最初の値を返します。 -次の例では、 2 つの異なるウィンドウ定義を使用しています。 +次の例では、 2つの異なるウィンドウ定義を使用しています。 - `PARTITION BY n MOD 2 ORDER BY n`は、テーブル`a`のデータを`1, 3`と`2, 4`の2つのグループに分割します。したがって、これらのグループの最初の値である`1`または`2`が返されます。 - `PARTITION BY n <= 2 ORDER BY n`は、テーブル`a`のデータを`1, 2`と`3, 4`の2つのグループに分割します。したがって、 `n`がどのグループに属しているかに応じて`1`または`3`を返します。 diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index f217d3444b0f2..29cb980d92edb 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -27,7 +27,7 @@ TiDBトランザクションモデルは[GoogleのPercolator](https://ai.google/ 「ロックの解決」ステップは、セーフポイントの前のロックをクリアします。つまり、ロックの主キーがコミットされている場合は、このロックもコミットする必要があります。そうでない場合は、ロールバックする必要があります。主キーがまだロックされている場合（コミットもロールバックもされていない場合）、このトランザクションはタイムアウトと見なされ、ロールバックされます。 -ロックの解決ステップは、システム変数[`tidb_gc_scan_lock_mode`](/system-variables.md#tidb_gc_scan_lock_mode-new-in-v50)を使用して構成できる次の 2 つの方法のいずれかで実装されます。 +ロックの解決ステップは、システム変数[`tidb_gc_scan_lock_mode`](/system-variables.md#tidb_gc_scan_lock_mode-new-in-v50)を使用して構成できる次の2つの方法のいずれかで実装されます。 > **Warning:** > diff --git a/generated-columns.md b/generated-columns.md index 43380bdc15d5c..19f0aabe7eea6 100644 --- a/generated-columns.md +++ b/generated-columns.md @@ -17,7 +17,7 @@ summary: 生成列の使用方法を学習します。 ## 使用法 {#usage} -生成列の主な用途の 1 つは、JSON データ型からデータを抽出し、そのデータにインデックスを付けることです。 +生成列の主な用途の 1つは、JSON データ型からデータを抽出し、そのデータにインデックスを付けることです。 MySQL 8.0とTiDBの両方において、JSON型の列を直接インデックスすることはできません。つまり、以下のテーブルスキーマは**サポートされていません**。 diff --git a/geo-distributed-deployment-topology.md b/geo-distributed-deployment-topology.md index 7ced30c0a5f8b..3b6ae62587f30 100644 --- a/geo-distributed-deployment-topology.md +++ b/geo-distributed-deployment-topology.md @@ -70,7 +70,7 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 #### PDパラメータ {#pd-parameters} -- PD メタデータ情報には、TiKV クラスターのトポロジが記録されます。PD は、次の 4 つの次元に基づいてRaftグループのレプリカをスケジュールします。 +- PD メタデータ情報には、TiKV クラスターのトポロジが記録されます。PD は、次の4つの次元に基づいてRaftグループのレプリカをスケジュールします。 ```yaml replication.location-labels: ["zone","dc","rack","host"] diff --git a/get-started-with-tidb-lightning.md b/get-started-with-tidb-lightning.md index b9a4b69fe577c..1d9063ba76dd4 100644 --- a/get-started-with-tidb-lightning.md +++ b/get-started-with-tidb-lightning.md @@ -38,7 +38,7 @@ summary: TiDB Lightningは、MySQLデータをTiDBクラスタにインポート - `-t 16` : 16 スレッドを使用してデータをエクスポートします。 - `-F 256MB` : 各テーブルを複数のファイルに分割し、各ファイルのサイズは約 256 MB にします。 - `-B test` : `test`データベースからエクスポートします。 - - `-f 'test.t[12]'` : 2 つのテーブル`test.t1`と`test.t2`のみをエクスポートします。 + - `-f 'test.t[12]'` : 2つのテーブル`test.t1`と`test.t2`のみをエクスポートします。 エクスポートされた完全なバックアップデータは、 `/data/my_database`ディレクトリに保存されます。 diff --git a/global-indexes.md b/global-indexes.md index 24c7c76107ea1..714181c621b8d 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -209,11 +209,11 @@ CREATE TABLE `sbtest` ( ) partition by hash(id) partitions 5; ``` -前述のテーブルスキーマを例に挙げましょう。`idx`はローカルインデックス、 `global_idx`はグローバルインデックスです。`idx`のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など 5 つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 +前述のテーブルスキーマを例に挙げましょう。`idx`はローカルインデックス、 `global_idx`はグローバルインデックスです。`idx`のデータは`PartitionID1_i_xxx`や`PartitionID2_i_xxx`など 5つの異なる範囲に分散されていますが、 `global_idx`のデータは単一の範囲 ( `TableID_i_xxx` ) に集中しています。 `k`に関連するクエリ（例えば`SELECT * FROM sbtest WHERE k > 1`を実行すると、ローカルインデックス`idx`は5つの個別の範囲を生成しますが、グローバルインデックス`global_idx`は1つの範囲のみを生成します。TiDBの各範囲は1つ以上のRPCリクエストに対応するため、グローバルインデックスを使用することでRPCリクエストの数を数倍削減でき、インデックスクエリのパフォーマンスが向上します。 -次の図は、 `idx`と`global_idx`という 2 つの異なるインデックスを使用して`SELECT * FROM sbtest WHERE k > 1`ステートメントを実行した場合の RPC 要求とデータ フローの違いを示しています。 +次の図は、 `idx`と`global_idx`という 2つの異なるインデックスを使用して`SELECT * FROM sbtest WHERE k > 1`ステートメントを実行した場合の RPC 要求とデータ フローの違いを示しています。 ![Mechanism of Global Indexes](/media/global-index-mechanism.png) diff --git a/glossary.md b/glossary.md index 611894e9674d9..1d7188bef1535 100644 --- a/glossary.md +++ b/glossary.md @@ -149,7 +149,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### ホットスポット（Hotspot） {#hotspot} -ホットスポットとは、TiKV の読み取りおよび書き込みワークロードが 1 つまたは少数のリージョンまたはノードに集中している状況を指します。これによりパフォーマンスのボトルネックが発生し、最適なシステムパフォーマンスが妨げられる可能性があります。ホットスポットの問題を解決するには、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)を参照してください。 +ホットスポットとは、TiKV の読み取りおよび書き込みワークロードが 1つまたは少数のリージョンまたはノードに集中している状況を指します。これによりパフォーマンスのボトルネックが発生し、最適なシステムパフォーマンスが妨げられる可能性があります。ホットスポットの問題を解決するには、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)を参照してください。 ### ハイブリッドトランザクション・分析処理（HTAP） {#hybrid-transactional-and-analytical-processing-htap} @@ -308,7 +308,7 @@ TiKVクラスタ内のリージョンは、最初は分割されておらず、 ### リージョン／仲間／Raftグループ {#regionpeerraft-group} -TiKV におけるデータストレージの最小単位はリージョンであり、それぞれがデータ範囲 (デフォルトでは 256 MiB) を表します。各リージョンには、デフォルトで 3 つのレプリカがあります。リージョンのレプリカはピアと呼ばれます。同じリージョンの複数のピアは、 Raftコンセンサスアルゴリズムを使用してデータを複製するため、ピアもRaftインスタンスのメンバーとなります。TiKV は、マルチ Raft を使用してデータを管理します。つまり、各リージョンには、対応する独立したRaftグループが存在します。 +TiKV におけるデータストレージの最小単位はリージョンであり、それぞれがデータ範囲 (デフォルトでは 256 MiB) を表します。各リージョンには、デフォルトで 3つのレプリカがあります。リージョンのレプリカはピアと呼ばれます。同じリージョンの複数のピアは、 Raftコンセンサスアルゴリズムを使用してデータを複製するため、ピアもRaftインスタンスのメンバーとなります。TiKV は、マルチ Raft を使用してデータを管理します。つまり、各リージョンには、対応する独立したRaftグループが存在します。 ### リモートプロシージャコール（RPC） {#remote-procedure-call-rpc} diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index 28c09fc750a1d..071c8d83335d9 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -31,17 +31,17 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | PD | ホットリードリージョンのリーダー分布 | 各 TiKV インスタンス上の読み取りホットスポットであるリーダーの合計数。 | | | PD | リージョンのハートビートレポート | インスタンスごとに PD に報告されたハートビートの数。 | | | PD | 99%リージョンハートビートレイテンシー | TiKV インスタンスごとのハートビートレイテンシー(P99)。 | | -| TiDB | ステートメントOPS | 1 秒あたりに実行される異なるタイプの SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`などのステートメントのタイプに応じてカウントされます。 | | +| TiDB | ステートメントOPS | 1秒あたりに実行される異なるタイプの SQL ステートメントの数。`SELECT` 、 `INSERT` 、 `UPDATE`などのステートメントのタイプに応じてカウントされます。 | | | TiDB | 間隔 | 実行時間。
    1. クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後にクライアントに返されるまでの時間。通常、クライアント要求はSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。
    2. TiDBはマルチクエリをサポートしているため、 `select 1; select 1; select 1;`ように複数のSQL文を一度に送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 | | | TiDB | インスタンスごとのCPS | インスタンス別 CPS: コマンド実行結果の成功または失敗に応じて分類された、各 TiDB インスタンスのコマンド統計。 | | | TiDB | クエリ OPM の失敗 | 各TiDBインスタンスにおける1秒あたりのSQL文実行時に発生したエラー数に基づく、エラーの種類（構文エラーや主キーの競合など）の統計情報。エラーが発生したモジュールとエラーコードが含まれます。 | | | TiDB | 接続数 | 各 TiDB インスタンスの接続数。 | | | TiDB | メモリ使用量 | 各 TiDB インスタンスのメモリ使用量統計。プロセスによって占有されるメモリと、ヒープ上でGolangによって適用されたメモリに分割されます。 | | -| TiDB | トランザクションOPS | 1 秒あたりに実行されるトランザクションの数。 | | +| TiDB | トランザクションOPS | 1秒あたりに実行されるトランザクションの数。 | | | TiDB | トランザクション期間 | トランザクションの実行時間 | | | TiDB | KVコマンドオペレーション | 実行された KV コマンドの数。 | | | TiDB | KVコマンド持続時間99 | KV コマンドの実行時間。 | | -| TiDB | PD TSOオペレーション | TiDB が PD に送信する 1 秒あたりの gRPC 要求の数 (cmd) と TSO 要求の数 (request)。各 gRPC 要求には、TSO 要求のバッチが含まれます。 | | +| TiDB | PD TSOオペレーション | TiDB が PD に送信する 1秒あたりの gRPC 要求の数 (cmd) と TSO 要求の数 (request)。各 gRPC 要求には、TSO 要求のバッチが含まれます。 | | | TiDB | PD TSO 待機時間 | TiDB が PD から TSO が返されるのを待機する期間。 | | | TiDB | TiClientリージョンエラー OPS | TiKV によって返されたリージョン関連エラーの数。 | | | TiDB | ロック解決OPS | ロックを解決したTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、TiDBはロックを解決しようとします。 | | diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 57a8993630eac..e231f21158837 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -19,7 +19,7 @@ PD ダッシュボード メトリック項目の説明は次のとおりです - 現在のストレージ使用量: 現在のストレージ使用率 - 通常のストア: 正常なストレージインスタンスの数 - リージョン数: クラスターリージョンの総数 -- 異常なストア: 不健全なストアの数。正常値は`0`です。この数値が`0`より大きい場合、少なくとも 1 つのインスタンスが異常であることを意味します。 +- 異常なストア: 不健全なストアの数。正常値は`0`です。この数値が`0`より大きい場合、少なくとも 1つのインスタンスが異常であることを意味します。 - リージョンの健全性: 保留中のピア、ダウン中のピア、余分なピア、オフラインのピア、欠落しているピア、学習中のピア、不正な名前空間など、異常なリージョンの数でリージョンの健全性を示します。通常、保留中のピアの数は`100`未満である必要があります。欠落しているピアの数は`0`を超えてはなりません。空のリージョンが多数存在する場合は、リージョンマージを適時に有効化してください。 - 現在のピア数: すべてのクラスタピアの現在の数![PD Dashboard - Header](/media/pd-dashboard-header-v4.png) diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index fb803155b1c79..5b0d064949f14 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -37,10 +37,10 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### SQL実行時間の概要 {#sql-execute-time-overview} -- 実行時間: SQL 実行中に 1 秒あたりに消費されるデータベース時間 +- 実行時間: SQL 実行中に 1秒あたりに消費されるデータベース時間 - tso_wait: SQL実行中の1秒あたりの同時TSO待機時間 - KVリクエストタイプ: SQL実行中に各KVリクエストタイプを1秒あたりに待機する時間。KVリクエストは同時実行されるため、合計KVリクエスト待機時間はSQL実行時間を超える場合があります。 -- tiflash_mpp: SQL 実行中に 1 秒あたりにTiFlash要求を処理する時間。 +- tiflash_mpp: SQL 実行中に 1秒あたりにTiFlash要求を処理する時間。 緑のメトリクスは一般的なKV書き込みリクエスト（プリライトやコミットなど）、青のメトリクスは一般的な読み取りリクエスト、紫のメトリクスはTiFlash MPPリクエストを表します。その他の色のメトリクスは、注意が必要な予期しない状況を表します。例えば、悲観的ロックKVリクエストは赤で、TSO待機は濃い茶色で表示されます。 @@ -51,31 +51,31 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### QPS {#qps} -すべて`UPDATE` TiDB インスタンスで 1 秒あたりに実行された SQL 文の数 (タイプ別: `SELECT`など`INSERT` +すべて`UPDATE` TiDB インスタンスで 1秒あたりに実行された SQL 文の数 (タイプ別: `SELECT`など`INSERT` ### CPSタイプ別 {#cps-by-type} -タイプに基づいて、すべての TiDB インスタンスによって 1 秒あたりに処理されるコマンドの数 +タイプに基づいて、すべての TiDB インスタンスによって 1秒あたりに処理されるコマンドの数 ### プランキャッシュOPSを使用したクエリ {#queries-using-plan-cache-ops} -- 平均ヒット: すべての TiDB インスタンスで 1 秒あたりに実行計画 キャッシュを使用するクエリの数 -- avg-miss: すべての TiDB インスタンスにおける、実行計画 キャッシュを使用していないクエリの数 (1 秒あたり) +- 平均ヒット: すべての TiDB インスタンスで 1秒あたりに実行計画 キャッシュを使用するクエリの数 +- avg-miss: すべての TiDB インスタンスにおける、実行計画 キャッシュを使用していないクエリの数 (1秒あたり) -`avg-hit + avg-miss`は`StmtExecute`に等しく、これは 1 秒あたりに実行されるすべてのクエリの数です。 +`avg-hit + avg-miss`は`StmtExecute`に等しく、これは 1秒あたりに実行されるすべてのクエリの数です。 ### KV/TSO リクエスト OPS {#kv-tso-request-ops} - kvリクエスト合計: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 -- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1 秒あたりの KV リクエスト数 -- tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1 秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 -- tso - リクエスト: すべての TiDB インスタンスにおける 1 秒あたりの TSO リクエスト数 +- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1秒あたりの KV リクエスト数 +- tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 +- tso - リクエスト: すべての TiDB インスタンスにおける 1秒あたりの TSO リクエスト数 -通常、 `tso - request`を`tso - cmd`で割った値が、1 秒あたりの TSO 要求バッチの平均サイズになります。 +通常、 `tso - request`を`tso - cmd`で割った値が、1秒あたりの TSO 要求バッチの平均サイズになります。 ### ソース別KVリクエスト時間 {#kv-request-time-by-source} -- kv リクエスト合計時間: すべての TiDB インスタンスで 1 秒あたりに KV およびTiFlashリクエストを処理する合計時間 +- kv リクエスト合計時間: すべての TiDB インスタンスで 1秒あたりに KV およびTiFlashリクエストを処理する合計時間 - 各 KV リクエストとそれに対応するリクエスト ソースは積み上げ棒グラフを形成し、 `external`通常のビジネス リクエストを識別し、 `internal`内部アクティビティ リクエスト (DDL やauto analyzeリクエストなど) を識別します。 ### TiDB CPU {#tidb-cpu} @@ -128,7 +128,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - コンパイル時間: 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 - 実行時間: SQL文の実行計画の実行に要した時間 -これら 3 つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 +これら3つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 ### 平均 TiDB KV リクエスト期間 {#avg-tidb-kv-request-duration} @@ -151,7 +151,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - ストア期間: 非同期書き込み中にストアループで消費される時間 - 適用期間: 非同期書き込み中の適用ループで消費された時間 -これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 +これら3つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 平均ストレージ非同期書き込み時間 = 平均保存時間 + 平均適用時間 @@ -161,7 +161,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - コミットログ期間: Raftがログをコミットするのにかかる時間 - ログ適用期間: Raftがログを適用するのにかかる時間 -これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 +これら3つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 ### パフォーマンス概要パネルのインターフェース {#interface-of-the-performance-overview-panels} @@ -172,7 +172,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - CPU: TiFlashインスタンスごとの CPU 使用率。 - メモリ: TiFlashインスタンスごとのメモリ使用量。 - IO 使用率: TiFlashインスタンスごとの IO 使用率。 -- MPP クエリ数: TiFlashインスタンスあたりの 1 秒あたりのTiFlash MPP クエリ数。 +- MPP クエリ数: TiFlashインスタンスあたりの 1秒あたりのTiFlash MPP クエリ数。 - 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。 - `batch` : バッチリクエストの数。 @@ -181,7 +181,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `cop_dag` : すべてのコプロセッサ要求内の DAG 要求の数。 - `super_batch` : スーパーバッチ機能を有効にするリクエストの数。 - Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブル スキャン Executor です。`selection`は選択 Executor です。 `aggregation`は集約 Executor です`top_n`は`TopN` Executor です`limit`は制限 Executor です。 -- リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエスト タイプについて、1 秒あたりの合計処理時間の積み上げグラフを提供します。 +- リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエスト タイプについて、1秒あたりの合計処理時間の積み上げグラフを提供します。 - リクエスト期間: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - リクエスト処理時間：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - Raft待機インデックス期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信してから、リージョンインデックスが`read_index`になるまで待機する時間です。 @@ -205,11 +205,11 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - 3: 停止 - 4: 完了 - -1: 不明 -- Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1 秒あたりに送信する行数。 -- ソーター出力イベント/秒: TiCDC ノードのソーター モジュールがマウント モジュールに 1 秒あたりに送信する行数。 -- マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 -- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 -- SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1 秒あたりに送信する行数。 +- Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1秒あたりに送信する行数。 +- ソーター出力イベント/秒: TiCDC ノードのソーター モジュールがマウント モジュールに 1秒あたりに送信する行数。 +- マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1秒あたりに送信する行数。 +- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーター モジュールがシンク モジュールに 1秒あたりに送信する行数。 +- SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1秒あたりに送信する行数。 - トランザクションシンクの完全フラッシュ期間: TiCDC ノードの MySQL シンクによるダウンストリーム トランザクションの書き込みの平均レイテンシーと p999レイテンシー。 - MQ ワーカーのメッセージ送信期間パーセンタイル: ダウンストリームが Kafka の場合の MQ ワーカーによるメッセージ送信のレイテンシー。 - Kafka 送信バイト: MQ ワークロードでのダウンストリーム トランザクションの書き込みトラフィック。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 943a14eae7605..6f1458c36ab10 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -30,7 +30,7 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en - KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。`total`は 、すべてのリソースグループのKVリクエストの合計です。 - クエリあたりのKVリクエスト数: 各SQL文による1秒あたりの読み取りおよび書き込みKVリクエストの平均数。上記のKVリクエスト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1 秒あたりに計算)。`total`は 、すべてのリソース グループによって読み取られたデータの合計です。 +- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1秒あたりに計算)。`total`は 、すべてのリソース グループによって読み取られたデータの合計です。 - クエリあたりの読み取りバイト数: 各SQL文が1秒あたりに読み取るデータの平均量。上記の読み取りバイト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - 書き込みバイト数: 各リソース グループによって書き込まれたデータの量。リアルタイムで計算されます。`total`は 、すべてのリソース グループによって書き込まれたデータの合計です。 - クエリあたりの書き込みバイト数: 各SQL文が1秒あたりに書き込むデータ量の平均。上記の「書き込みバイト数」メトリックを、1秒あたりに実行されるSQL文の数で割ることで算出されます。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 9b610b51392b9..55a846231adfc 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -34,7 +34,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### クエリの詳細 {#query-detail} - 期間 80/95/99/999 インスタンス別: 各 TiDB インスタンスでの SQL 文の実行時間の統計 (異なるパーセンタイル) -- 失敗したクエリ OPM の詳細: 各 TiDB インスタンスで 1 分あたりに SQL ステートメントを実行したときに発生したエラーに応じたエラーの種類 (構文エラーや主キーの競合など) の統計 +- 失敗したクエリ OPM の詳細: 各 TiDB インスタンスで 1分あたりに SQL ステートメントを実行したときに発生したエラーに応じたエラーの種類 (構文エラーや主キーの競合など) の統計 - 内部SQL OPS: TiDBクラスタ全体で1秒あたりに実行された内部SQL文の数。内部SQL文は内部的に実行され、通常はユーザーのSQL文または内部的にスケジュールされたタスクによってトリガーされます。 ### サーバ {#server} @@ -63,7 +63,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - トランザクション再試行回数: トランザクションが再試行される回数 - セッション再試行エラーOPS: トランザクション再試行中に発生したエラーの数（1秒あたり）。この指標には、再試行失敗と再試行回数の上限超過という2種類のエラーが含まれます。 - コミットトークン待機時間: トランザクションのコミット中にフロー制御キューで待機する時間です。待機時間が長い場合、コミットするトランザクションが大きすぎてフローが制御されていることを意味します。システムにまだ利用可能なリソースがある場合は、システム変数`tidb_committer_concurrency`を増やすことでコミットプロセスを高速化できます。 -- KVトランザクションOPS: 各 TiDB インスタンス内で 1 秒あたりに実行されるトランザクションの数 +- KVトランザクションOPS: 各 TiDB インスタンス内で 1秒あたりに実行されるトランザクションの数 - ユーザートランザクションは、内部メタデータの読み取りやユーザートランザクションのアトミック再試行など、TiDB内で複数のトランザクション実行をトリガーする可能性があります。 - TiDBの内部的にスケジュールされたタスクもトランザクションを通じてデータベース上で動作し、このパネルにも含まれています。 - KVトランザクション期間: 各TiDB内でトランザクションを実行するのに費やされた時間 @@ -75,7 +75,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - トランザクション書き込みサイズバイトレートと合計: トランザクション内で書き込まれるバイト数と書き込まれたバイト数の合計 - トランザクション書き込みサイズバイト: トランザクションで書き込まれたデータのサイズ - 悲観的ロックの取得期間: ロックの追加にかかる時間 -- TTL 寿命到達カウンタ: TTL の上限に達したトランザクションの数。TTL 上限のデフォルト値は 1 時間です。これは、悲観的トランザクションの最初のロック、または楽観的トランザクションの最初の事前書き込みから 1 時間が経過したことを意味します。TTL 上限のデフォルト値は 1 時間です。TTL 寿命の上限は、TiDB 設定ファイルで`max-txn-TTL`変更することで変更できます。 +- TTL 寿命到達カウンタ: TTL の上限に達したトランザクションの数。TTL 上限のデフォルト値は 1時間です。これは、悲観的トランザクションの最初のロック、または楽観的トランザクションの最初の事前書き込みから 1時間が経過したことを意味します。TTL 上限のデフォルト値は 1時間です。TTL 寿命の上限は、TiDB 設定ファイルで`max-txn-TTL`変更することで変更できます。 - ロードセーフポイントOPS: `Safepoint`がロードされる回数。`Safepoint`は 、トランザクションがデータを読み取る際に`Safepoint`より前のデータが読み込まれないようにすることで、データの安全性を確保するためのものです`Safepoint`より前のデータはGCによってクリーンアップされる可能性があります。 - 悲観的ステートメント再試行回数（OPS）：悲観的ステートメントの再試行回数。ステートメントがロックを追加しようとすると、書き込み競合が発生する可能性があります。この場合、ステートメントは新しいスナップショットを取得し、再度ロックを追加します。 - 1秒あたりのトランザクションタイプ: 2フェーズコミット (2PC)、非同期コミット、および1フェーズコミット (1PC) メカニズムを使用して1秒あたりにコミットされたトランザクションの数 (成功トランザクションと失敗トランザクションの両方を含む) @@ -87,7 +87,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - 実行時間: SQL文の実行時間の統計 - 高負荷エグゼキュータOPS: 1秒あたりに多くのシステムリソースを消費するオペレータの統計`Merge Join` `Hash Join` `Index Look Up Join` `Hash Agg` `Stream Agg` `Sort` `TopN` - プランキャッシュOPSを使用したクエリ: プランキャッシュを使用したクエリの1秒あたりの統計 -- プラン キャッシュ ミス OPS: 1 秒あたりにプラン キャッシュがミスされた回数の統計 +- プラン キャッシュ ミス OPS: 1秒あたりにプラン キャッシュがミスされた回数の統計 - プランキャッシュメモリ使用量: 各 TiDB インスタンスにキャッシュされた実行計画によって消費されるメモリの合計 - プランキャッシュプラン数: 各 TiDB インスタンスにキャッシュされた実行計画の総数 @@ -95,7 +95,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - Distsql 実行時間: Distsql ステートメントの処理時間 - Distsql QPS: Distsql ステートメントの統計 -- Distsql 部分 QPS: 1 秒あたりの部分結果の数 +- Distsql 部分 QPS: 1秒あたりの部分結果の数 - スキャンキー数: 各クエリがスキャンするキーの数 - スキャンキー部分数: 各部分結果がスキャンするキーの数 - 部分数: 各SQL文の部分結果の数 @@ -116,10 +116,10 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - KVリクエスト期間 99（ストア別）: TiKVに従って表示されるKVリクエストの実行時間 - KVリクエスト期間 99 (タイプ別): リクエストタイプに応じて表示される KV リクエストの実行時間 - ステイル読み取りヒット/ミスオペレーション - - **ヒット**: 古い読み取りを正常に実行した 1 秒あたりのリクエスト数 + - **ヒット**: 古い読み取りを正常に実行した 1秒あたりのリクエスト数 - **ミス**: 古いデータを読み取ろうとしたが失敗したリクエストの1秒あたりの数 - ステイル読み取り要求操作: - - **クロスゾーン**: リモートゾーンで古いデータの読み取りを試みる 1 秒あたりのリクエスト数 + - **クロスゾーン**: リモートゾーンで古いデータの読み取りを試みる 1秒あたりのリクエスト数 - **ローカル**: ローカルゾーンで古いデータの読み取りを試みる1秒あたりのリクエスト数 - ステイル読み取り要求トラフィック: - **クロスゾーンイン**: リモートゾーンで古いデータの読み取りを試みる要求に対する応答の着信トラフィック @@ -134,9 +134,9 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### PDクライアント {#pd-client} -- PD クライアント CMD OPS: PD クライアントが 1 秒あたりに実行したコマンドの統計 +- PD クライアント CMD OPS: PD クライアントが 1秒あたりに実行したコマンドの統計 - PDクライアントCMD実行時間:PDクライアントがコマンドを実行するのにかかる時間 -- PD クライアント CMD 失敗 OPS: PD クライアントによって 1 秒あたりに実行された失敗したコマンドの統計 +- PD クライアント CMD 失敗 OPS: PD クライアントによって 1秒あたりに実行された失敗したコマンドの統計 - PD TSO OPS: TiDBがPDに送信する1秒あたりのgRPCリクエスト数（cmd）とTSOリクエスト数（request）。各gRPCリクエストには、TSOリクエストのバッチが含まれています。 - PD TSO 待機時間: TiDB が PD から TSO が返されるまで待機する時間 - PD TSO RPC 期間: TiDB が TSO を取得するために PD に gRPC 要求を送信してから TiDB が PD から gRPC 応答を受信するまでの期間 @@ -146,7 +146,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - スキーマのロード時間: TiDBがTiKVからスキーマを取得するのにかかる時間 - ロードスキーマOPS: TiDBがTiKVから1秒あたりに取得するスキーマの統計 -- スキーマ リース エラー OPM: スキーマ リース エラーには、 `change`と`outdate` 2 つのタイプがあります。 `change`スキーマが変更されたことを意味し、 `outdate`スキーマを更新できないことを意味します。これはより重大なエラーであり、アラートをトリガーします。 +- スキーマ リース エラー OPM: スキーマ リース エラーには、 `change`と`outdate` 2つのタイプがあります。 `change`スキーマが変更されたことを意味し、 `outdate`スキーマを更新できないことを意味します。これはより重大なエラーであり、アラートをトリガーします。 - Load Privilege OPS: TiDBがTiKVから1秒あたりに取得した権限情報の件数の統計 ### DDL {#ddl} @@ -180,7 +180,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### メタ {#meta} -- AutoID QPS: 3 つの操作 (グローバル ID 割り当て、単一テーブルの AutoID 割り当て、単一テーブルの AutoID リベース) を含む AutoID 関連の統計 +- AutoID QPS: 3つの操作 (グローバル ID 割り当て、単一テーブルの AutoID 割り当て、単一テーブルの AutoID リベース) を含む AutoID 関連の統計 - AutoID 期間: AutoID 関連の操作に費やされた時間 - リージョンキャッシュエラーOPS: TiDBにキャッシュされたリージョン情報で1秒あたりに発生したエラーの数 - メタ操作期間 99: メタ操作のレイテンシー @@ -209,10 +209,10 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - TiKV IO MBps: 各 TiKV インスタンスの I/O の合計バイト数。 - TiKV CPU: 各 TiKV インスタンスの CPU 使用率。 - タイプ別の TTL QPS: TTL ジョブによって生成されたさまざまなタイプのステートメントの QPS 情報。 -- 1 秒あたりの TTL 挿入行数: 1 秒あたりに TTL テーブルに挿入される行数。 -- 1 秒あたりの TTL 処理行数: 1 秒あたりに TTL ジョブによって処理された期限切れの行数。 -- 1 時間あたりの TTL 挿入行数: 1 時間ごとに TTL テーブルに挿入される行数。 -- 1 時間あたりの TTL 削除行数: TTL ジョブによって 1 時間ごとに削除される期限切れの行数。 +- 1秒あたりの TTL 挿入行数: 1秒あたりに TTL テーブルに挿入される行数。 +- 1秒あたりの TTL 処理行数: 1秒あたりに TTL ジョブによって処理された期限切れの行数。 +- 1時間あたりの TTL 挿入行数: 1時間ごとに TTL テーブルに挿入される行数。 +- 1時間あたりの TTL 削除行数: TTL ジョブによって 1時間ごとに削除される期限切れの行数。 - TTL スキャン/削除クエリ期間: TTL スキャン/削除ステートメントの実行時間。 - TTL スキャン/削除ワーカー時間 (フェーズ別): TTL 内部ワーカー スレッドのさまざまなフェーズで消費された時間。 - ステータス別の TTL ジョブ数: 現在実行中の TTL ジョブの数。 diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index cb92526100896..81600ad6ecb09 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -136,7 +136,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - サーバーごとの受信メッセージ数：各TiKVインスタンスが1秒あたりに受信するRaftメッセージの数 - メッセージ：1秒あたりに送信されるRaftメッセージの種類ごとの数 - 投票： Raftで1秒あたりに送信される投票メッセージの数 -- Raftドロップメッセージ数: 1 秒あたりの、種類別のドロップされたRaftメッセージ数 +- Raftドロップメッセージ数: 1秒あたりの、種類別のドロップされたRaftメッセージ数 ![TiKV Dashboard - Raft message metrics](/media/tikv-dashboard-raft-message.png) @@ -293,7 +293,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - 総リクエスト数：1秒あたりのリクエストの種類別数 - 処理時間：コプロセッサ要求を実際に処理した時間（1分あたり）のヒストグラム - 総リクエストエラー数：コプロセッサーが1秒あたりに発生させたリクエストエラーの数。短時間に多数のエラーが発生するべきではありません。 -- 合計 KV カーソル操作: 1 秒あたりのタイプ別の KV カーソル操作の合計数。例`select` 、 `index` 、 `analyze_table` 、 `analyze_index` 、 `checksum_table` 、 `checksum_index` 。 +- 合計 KV カーソル操作: 1秒あたりのタイプ別の KV カーソル操作の合計数。例`select` 、 `index` 、 `analyze_table` 、 `analyze_index` 、 `checksum_table` 、 `checksum_index` 。 - KVカーソル操作：1秒あたりのタイプ別KVカーソル操作のヒストグラム - RocksDBのパフォーマンス統計：RocksDBのパフォーマンスに関する統計情報 - 応答の合計サイズ：コプロセッサ応答の合計サイズ diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index fea986c710f58..86fb2137ddd8c 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -25,10 +25,10 @@ TiDBはv8.5 LTSにおいて、様々なオペレーティングシステムとCP > **Warning:** > - > - [CentOS Linux サポート終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)よると、CentOS Linux 7 のアップストリーム サポートは 2024 年 6 月 30 日に終了しました。 + > - [CentOS Linux サポート終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)よると、CentOS Linux 7 のアップストリーム サポートは 2024年 6月 30日に終了しました。 > - TiDBをアップグレードする前に、オペレーティングシステムのバージョンを確認してください。TiDB v8.4.0 DMRおよびv8.5.0では、glibc 2.17のサポートが終了し、CentOS Linux 7のサポートとテストも終了しました。Rocky Linux 9.1以降のバージョンを使用することをお勧めします。CentOS 7上のTiDBクラスタをv8.4.0またはv8.5.0にアップグレードすると、クラスタが利用できなくなるリスクがあります。 > - CentOS Linux 7 をまだ使用しているユーザーを支援するために、v8.5.1 以降、TiDB は glibc 2.17 のサポートを再開し、CentOS Linux 7 のテストを再開し、CentOS Linux 7 と互換性を持つようになりました。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)を確認し、Rocky Linux 9.1 や TiDB が本番用にサポートするオペレーティング システムに移行することを強くお勧めします。 後で。 - > - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。TiDB をアップグレードする前に、オペレーティングシステムのバージョンを確認してください。 + > - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024年 6月 30日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。TiDB をアップグレードする前に、オペレーティングシステムのバージョンを確認してください。 > **Note:** > @@ -42,9 +42,9 @@ TiDBはv8.5 LTSにおいて、様々なオペレーティングシステムとCP > > - Oracle Enterprise Linuxの場合、TiDBはRed Hat互換カーネル（RHCK）をサポートしており、Oracle Enterprise Linuxが提供するUnbreakable Enterprise Kernelはサポートしていません。 > - TiDBの今後のバージョンでは、Ubuntu 16.04のサポートは終了します。Ubuntu 18.04以降へのアップグレードを強くお勧めします。 - > - CentOS Stream 8 は、2024 年 5 月 31 日に[ビルド終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)。 + > - CentOS Stream 8 は、2024年 5月 31日に[ビルド終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)。 -- 前述の 2 つの表に記載されているオペレーティングシステムの 32 ビット版を使用している場合、TiDB は 32 ビットオペレーティングシステムおよび対応する CPUアーキテクチャ上でコンパイル、ビルド、またはデプロイできることが**保証されません**。また、TiDB は 32 ビットオペレーティングシステムに積極的に対応しません。 +- 前述の2つの表に記載されているオペレーティングシステムの 32 ビット版を使用している場合、TiDB は 32 ビットオペレーティングシステムおよび対応する CPUアーキテクチャ上でコンパイル、ビルド、またはデプロイできることが**保証されません**。また、TiDB は 32 ビットオペレーティングシステムに積極的に対応しません。 - 上記に記載されていない他のオペレーティングシステムバージョンでも動作する可能性はありますが、公式にはサポートされていません。 @@ -188,7 +188,7 @@ TiDBは、データベースメトリクスの可視化に[Grafana](https://graf ## TiFlashの分離型ストレージおよびコンピューティングアーキテクチャに必要なハードウェアおよびソフトウェア要件 {#hardware-and-software-requirements-for-tiflash-disaggregated-storage-and-compute-architecture} -前述のTiFlashソフトウェアおよびハードウェア要件は、結合されたストレージとコンピューティングアーキテクチャに関するものです。 v7.0.0 以降、 TiFlash は[分散型ストレージおよびコンピューティングアーキテクチャ](/tiflash/tiflash-disaggregated-and-s3.md)をサポートします。このアーキテクチャでは、 TiFlash は書き込みノードと計算ノードの 2 種類のノードに分割されます。これらのノードの要件は次のとおりです。 +前述のTiFlashソフトウェアおよびハードウェア要件は、結合されたストレージとコンピューティングアーキテクチャに関するものです。 v7.0.0 以降、 TiFlash は[分散型ストレージおよびコンピューティングアーキテクチャ](/tiflash/tiflash-disaggregated-and-s3.md)をサポートします。このアーキテクチャでは、 TiFlash は書き込みノードと計算ノードの 2種類のノードに分割されます。これらのノードの要件は次のとおりです。 - ソフトウェア: 結合されたストレージとコンピューティングアーキテクチャと同じままです。 [OSおよびプラットフォームの要件](#os-and-platform-requirements)を参照してください。 - ネットワーク ポート: 結合されたストレージとコンピューティングアーキテクチャと同じままです。[ネットワーク](#network-requirements)を参照してください。 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 2bd6e08e87033..dfe3e9ebe9fc6 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -73,7 +73,7 @@ insert into t select * from t; - `Succ` : ステートメントが正常に実行されたかどうか。 - `Backoff_time` : ステートメントが再試行を必要とするエラーに遭遇した場合の、再試行までの待機時間。このような一般的なエラーには、 `lock occurs` 、 `Region split` 、および`tikv server is busy`などがあります。 - `Plan` : ステートメントの実行計画。 `SELECT tidb_decode_plan('xxx...')`ステートメントを実行して、具体的な実行計画を解析します。 -- `Binary_plan` : バイナリエンコードされたステートメントの実行計画。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行します。 `Plan`および`Binary_plan`フィールドには同じ情報が含まれています。ただし、これら 2 つのフィールドから解析される実行計画の形式は異なります。 +- `Binary_plan` : バイナリエンコードされたステートメントの実行計画。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行します。 `Plan`および`Binary_plan`フィールドには同じ情報が含まれています。ただし、これら2つのフィールドから解析される実行計画の形式は異なります。 - `Prepared` : このステートメントが`Prepare`または`Execute`の要求であるかどうか。 - `Plan_from_cache` : このステートメントが実行プランキャッシュにヒットするかどうか。 - `Plan_from_binding` : このステートメントがバインドされた実行計画を使用するかどうか。 @@ -82,7 +82,7 @@ insert into t select * from t; - `Preproc_subqueries` : ステートメント内で事前に実行されるサブクエリの数。たとえば、 `where id in (select if from t)`サブクエリが事前に実行される場合があります。 - `Preproc_subqueries_time` : このステートメントのサブクエリを事前に実行するために要した時間。 - `Exec_retry_count` : このステートメントの再試行回数。このフィールドは通常、ロックが失敗した場合にステートメントが再試行される悲観的トランザクションに使用されます。 -- `Exec_retry_time` : このステートメントの実行再試行時間。たとえば、ステートメントが合計 3 回実行された場合 (最初の 2 回は失敗)、 `Exec_retry_time`は最初の 2 回の実行の合計時間を意味します。最後の実行の時間は、 `Query_time`から`Exec_retry_time`を引いた時間です。 +- `Exec_retry_time` : このステートメントの実行再試行時間。たとえば、ステートメントが合計3回実行された場合 (最初の 2回は失敗)、 `Exec_retry_time`は最初の 2回の実行の合計時間を意味します。最後の実行の時間は、 `Query_time`から`Exec_retry_time`を引いた時間です。 - `KV_total` : このステートメントによって、TiKV またはTiFlash上のすべての RPC リクエストに費やされた時間。 - `PD_total` : このステートメントによる PD 上のすべての RPC リクエストに費やされた時間。 - `Backoff_total` : このステートメントの実行中にすべてのバックオフに費やされた時間。 @@ -185,7 +185,7 @@ TiKVコプロセッサータスクフィールド： ### 統一されたルール構文と型制約 {#unified-rule-syntax-and-type-constraints} -- ルール容量と分離: `SESSION`と`GLOBAL`はそれぞれ最大 10 個のルールをサポートします。1 つのセッションで最大 20 個のアクティブなルールを持つことができます。ルールは`;`で分離されます。 +- ルール容量と分離: `SESSION`と`GLOBAL`はそれぞれ最大 10 個のルールをサポートします。1つのセッションで最大 20 個のアクティブなルールを持つことができます。ルールは`;`で分離されます。 - 条件の形式: 各条件は`field_name:value`の形式を使用します。単一のルール内の複数の条件は`,`で区切られます。 - フィールドとスコープ: フィールド名は大文字と小文字を区別しません (アンダースコアやその他の文字は保持されます)。 `SESSION`ルールは`Conn_ID`をサポートしていません。 `GLOBAL`ルールのみが`Conn_ID`をサポートしています。 - 意味の一致： @@ -283,7 +283,7 @@ TiKVコプロセッサータスクフィールド： SET GLOBAL tidb_slow_log_rules = 'Query_time: 0.5, Is_internal: false'; ``` -- 特定の接続に対するグローバルルール（ `Conn_ID:11`と`Conn_ID:12` 2 つの接続にそれぞれ適用されます）： +- 特定の接続に対するグローバルルール（ `Conn_ID:11`と`Conn_ID:12` 2つの接続にそれぞれ適用されます）： ```sql SET GLOBAL tidb_slow_log_rules = 'Conn_ID: 11, Query_time: 0.5, Is_internal: false; Conn_ID: 12, Query_time: 0.6, Process_time: 0.3, DB: db1'; @@ -305,8 +305,8 @@ TiKVコプロセッサータスクフィールド： > > `tidb_slow_log_rules`の時間関連フィールド（ `Query_time`や`Process_time`など）は単位として秒を使用し、小数点を含むことができますが、 [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)はミリ秒を使用します。 -- [`tidb_slow_log_max_per_sec`](/system-variables.md#tidb_slow_log_max_per_sec-new-in-v856) : 1 秒あたりに書き込めるスロークエリログエントリの最大数を設定します。デフォルト値は`0`です。この変数は v8.5.6 で導入されました。 - - `0`という値は、1 秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 +- [`tidb_slow_log_max_per_sec`](/system-variables.md#tidb_slow_log_max_per_sec-new-in-v856) : 1秒あたりに書き込めるスロークエリログエントリの最大数を設定します。デフォルト値は`0`です。この変数は v8.5.6 で導入されました。 + - `0`という値は、1秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 - `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。 - ルールベースのスロークエリログが頻繁にトリガーされるのを防ぐため、 `tidb_slow_log_rules`を有効にした後にこの変数を設定することをお勧めします。 @@ -391,13 +391,13 @@ TiDB 4.0 では、 `SLOW_QUERY`は、ローテーションされたスローロ TiDB 4.0 では、すべての TiDB ノードのスロー クエリ情報を照会するための[`CLUSTER_SLOW_QUERY`](/information-schema/information-schema-slow-query.md#cluster_slow_query-table)システム テーブルが追加されました。 `CLUSTER_SLOW_QUERY`テーブルのテーブル スキーマは`CLUSTER_SLOW_QUERY`に`INSTANCE`列が追加されている点で`SLOW_QUERY`テーブルのスキーマとは異なります。 `INSTANCE`列は、スロー クエリの行情報の TiDB ノード アドレスを表します。 `CLUSTER_SLOW_QUERY` 、 [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md)と同様に使用できます。 -`CLUSTER_SLOW_QUERY`テーブルに対してクエリを実行すると、TiDB は他のノードからすべてのスロークエリ情報を取得して 1 つの TiDB ノードで操作を実行するのではなく、計算と判断を他のノードにプッシュします。 +`CLUSTER_SLOW_QUERY`テーブルに対してクエリを実行すると、TiDB は他のノードからすべてのスロークエリ情報を取得して 1つの TiDB ノードで操作を実行するのではなく、計算と判断を他のノードにプッシュします。 ## `SLOW_QUERY` / `CLUSTER_SLOW_QUERY`使用例 {#slow_query--cluster_slow_query-usage-examples} ### 上位N件のスロークエリ {#top-n-slow-queries} -ユーザーのスロークエリ上位 2 件をクエリします。 `Is_internal=false` TiDB 内のスロークエリを除外し、ユーザーのスロークエリのみをクエリすることを意味します。 +ユーザーのスロークエリ上位 2件をクエリします。 `Is_internal=false` TiDB 内のスロークエリを除外し、ユーザーのスロークエリのみをクエリすることを意味します。 ```sql select query_time, query @@ -420,7 +420,7 @@ limit 2; ### `test`ユーザーの上位N件のスロークエリを照会する {#query-the-top-n-slow-queries-of-the-test-user} -次の例では、 `test`ユーザーによって実行されたスロークエリが照会され、最初の 2 つの結果が実行時間の逆順に表示されます。 +次の例では、 `test`ユーザーによって実行されたスロークエリが照会され、最初の 2つの結果が実行時間の逆順に表示されます。 ```sql select query_time, query, user diff --git a/index-advisor.md b/index-advisor.md index bb671ceb70675..2dc361146c07b 100644 --- a/index-advisor.md +++ b/index-advisor.md @@ -92,7 +92,7 @@ RECOMMEND INDEX RUN; このテーブルには数万から数十万ものクエリが含まれる可能性があり、インデックスアドバイザーのパフォーマンスに影響を与える可能性があります。この問題を解決するため、インデックスアドバイザーは実行頻度の高いクエリを優先します。これらのクエリはワークロード全体のパフォーマンスに大きな影響を与えるためです。デフォルトでは、インデックスアドバイザーは上位1,000件のクエリを選択します。この値は、 [`max_num_query`](#recommend-index-options)パラメーターを使用して調整できます。 -`RECOMMEND INDEX`ステートメントの結果は`mysql.index_advisor_results`テーブルに格納されます。このテーブルをクエリして、推奨インデックスを表示できます。次の例は、前の 2 つの`RECOMMEND INDEX`ステートメントの実行後のこのシステム テーブルの内容を示しています。 +`RECOMMEND INDEX`ステートメントの結果は`mysql.index_advisor_results`テーブルに格納されます。このテーブルをクエリして、推奨インデックスを表示できます。次の例は、前の 2つの`RECOMMEND INDEX`ステートメントの実行後のこのシステム テーブルの内容を示しています。 ```sql SELECT * FROM mysql.index_advisor_results; @@ -188,7 +188,7 @@ WHERE last_access_time IS NOT NULL AND percentage_access_0 + percentage_access_0 > **Note:** > -> `INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`のデータは最大 5 分遅延する可能性があり、TiDB ノードが再起動されるたびに使用状況データはリセットされます。また、インデックスの使用状況は、テーブルに有効な統計情報がある場合にのみ記録されます。 +> `INFORMATION_SCHEMA.CLUSTER_TIDB_INDEX_USAGE`のデータは最大 5分遅延する可能性があり、TiDB ノードが再起動されるたびに使用状況データはリセットされます。また、インデックスの使用状況は、テーブルに有効な統計情報がある場合にのみ記録されます。 ## 仮説インデックス {#hypothetical-indexes} diff --git a/information-schema/information-schema-cluster-info.md b/information-schema/information-schema-cluster-info.md index c74792817e686..e661106ffa22f 100644 --- a/information-schema/information-schema-cluster-info.md +++ b/information-schema/information-schema-cluster-info.md @@ -38,7 +38,7 @@ desc cluster_info; - `INSTANCE` : インスタンスアドレス。これは`IP:PORT`の形式の文字列です。 - `STATUS_ADDRESS` : HTTP API のサービス アドレス。tikv-ctl、pd-ctl、または tidb-ctl の一部のコマンドでは、この API とこのアドレスが使用される場合があります。このアドレスからクラスタに関する詳細情報を取得することもできます。詳細は[TiDB HTTP APIドキュメント](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)を参照してください。 - `VERSION` : 対応するインスタンスのセマンティックバージョン番号。MySQL のバージョン番号との互換性を保つため、TiDB のバージョンは`${mysql-version}-${tidb-version}`の形式で表示されます。 -- `GIT_HASH` : インスタンス バージョンをコンパイルする際の Git コミット ハッシュ。これは、2 つのインスタンスが完全に一貫したバージョンであるかどうかを識別するために使用されます。 +- `GIT_HASH` : インスタンス バージョンをコンパイルする際の Git コミット ハッシュ。これは、2つのインスタンスが完全に一貫したバージョンであるかどうかを識別するために使用されます。 - `START_TIME` : 対応するインスタンスの開始時刻。 - `UPTIME` : 対応するインスタンスの稼働時間。 - `SERVER_ID` : 対応するインスタンスのサーバーID。 diff --git a/information-schema/information-schema-columns.md b/information-schema/information-schema-columns.md index 756ac93962c17..e130aaefeed1f 100644 --- a/information-schema/information-schema-columns.md +++ b/information-schema/information-schema-columns.md @@ -98,7 +98,7 @@ CHARACTER_MAXIMUM_LENGTH: NULL - `COLUMN_TYPE` : 列のタイプ。 - `COLUMN_KEY` : この列がインデックスされているかどうか。このフィールドには次の値が含まれます。 - 空: この列にはインデックスが付いていません。または、この列にはインデックスが付いていて、複数列の一意でないインデックスの 2 番目の列です。 - - `PRI` : この列は主キーまたは複数の主キーの 1 つです。 + - `PRI` : この列は主キーまたは複数の主キーの 1つです。 - `UNI` : この列は、一意インデックスの最初の列です。 - `MUL` : 列は、特定の値が複数回出現することを許可される、一意でないインデックスの最初の列です。 - `EXTRA` : 指定された列の追加情報。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 27ffcb2fff214..2e5454aa8d9b8 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -46,13 +46,13 @@ DESC deadlocks; -`DEADLOCKS`テーブルに記録できるデッドロックイベントの最大数を調整するには、TiDB 設定ファイルの[`pessimistic-txn.deadlock-history-capacity`](/tidb-configuration-file.md#deadlock-history-capacity)設定を調整します。デフォルトでは、直近 10 件のデッドロックイベントの情報がテーブルに記録されます。 +`DEADLOCKS`テーブルに記録できるデッドロックイベントの最大数を調整するには、TiDB 設定ファイルの[`pessimistic-txn.deadlock-history-capacity`](/tidb-configuration-file.md#deadlock-history-capacity)設定を調整します。デフォルトでは、直近 10件のデッドロックイベントの情報がテーブルに記録されます。 -最近の 10 件のデッドロック イベントの情報が`DEADLOCKS`テーブルに記録されます。 +最近の 10件のデッドロック イベントの情報が`DEADLOCKS`テーブルに記録されます。 @@ -117,14 +117,14 @@ DESC deadlocks; UPDATE t SET v = v + 1 WHERE id = 1 OR id = 2; ``` -トランザクションB は次の 2 つのステートメントを連続して実行します。 +トランザクションB は次の2つのステートメントを連続して実行します。 ```sql UPDATE t SET v = 4 WHERE id = 2; UPDATE t SET v = 2 WHERE id = 1; ``` -次に、トランザクション A が`id = 1`と`id = 2`で 2 つの行をロックし、 2 つのトランザクションが次の順序で実行されるとします。 +次に、トランザクション A が`id = 1`と`id = 2`で 2つの行をロックし、 2つのトランザクションが次の順序で実行されるとします。 1. トランザクションA は行を`id = 1`でロックします。 2. トランザクションB は最初のステートメントを実行し、行を`id = 2`でロックします。 @@ -144,7 +144,7 @@ CREATE TABLE t (id int primary key, v int); INSERT INTO t VALUES (1, 10), (2, 20); ``` -2 つのトランザクションは次の順序で実行されます。 +2つのトランザクションは次の順序で実行されます。 | トランザクション1 | トランザクション2 | 説明 | | ----------------------------------- | ----------------------------------- | ---------------------------- | diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 9787696c88db8..b8a85ff17ec22 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -104,7 +104,7 @@ DETAILS | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was to 上記の診断結果から、次の問題が検出されます。 - 最初の行は、TiDB の`log.slow-threshold`値が`0`に設定されており、パフォーマンスに影響する可能性があることを示しています。 -- 2 行目は、クラスター内に 2 つの異なる TiDB バージョンが存在することを示します。 +- 2 行目は、クラスター内に 2つの異なる TiDB バージョンが存在することを示します。 - 3行目と4行目は、TiKVの書き込み遅延が長すぎることを示しています。予想される遅延は0.1秒以内ですが、実際の遅延は予想よりもはるかに長くなっています。 「2020-03-26 00:03:00」から「2020-03-26 00:08:00」までなど、指定した範囲内にある問題を診断することもできます。時間範囲を指定するには、SQLヒントに`/*+ time_range() */`を指定します。次のクエリ例をご覧ください。 @@ -137,7 +137,7 @@ DETAILS | max duration of 172.16.5.40:10089 tidb get-token-duration is too slo 上記の診断結果から、次の問題が検出されます。 - 最初の行は、 `172.16.5.40:4009` TiDB インスタンスが`2020/03/26 00:05:45.670`で再起動されることを示しています。 -- 2 行目は、 `172.16.5.40:10089` TiDB インスタンスの最大`get-token-duration`時間は 0.234 秒ですが、予想時間は 0.001 秒未満であることを示しています。 +- 2 行目は、 `172.16.5.40:10089` TiDB インスタンスの最大`get-token-duration`時間は 0.234秒ですが、予想時間は 0.001秒未満であることを示しています。 条件を指定して、たとえばレベル`critical`の診断結果を照会することもできます。 @@ -175,7 +175,7 @@ select * from information_schema.inspection_rules where type='inspection'; ### `config`診断ルール {#config-diagnostic-rule} -`config`診断ルールでは、 `CLUSTER_CONFIG`のシステム テーブルをクエリすることによって、次の 2 つの診断ルールが実行されます。 +`config`診断ルールでは、 `CLUSTER_CONFIG`のシステム テーブルをクエリすることによって、次の2つの診断ルールが実行されます。 - 同じコンポーネントの設定値が一貫しているかどうかを確認します。すべての設定項目でこの整合性チェックが実行されるわけではありません。整合性チェックの許可リストは次のとおりです。 @@ -240,7 +240,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo ### `critical-error`診断ルール {#critical-error-diagnostic-rule} -`critical-error`診断ルールでは、次の 2 つの診断ルールが実行されます。 +`critical-error`診断ルールでは、次の2つの診断ルールが実行されます。 - メトリック スキーマ内の関連する監視システム テーブルをクエリして、クラスターに次のエラーがあるかどうかを検出します。 @@ -278,7 +278,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | TiKV | リーダースコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリーダースコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | | TiKV | リージョンスコアバランス | pd_scheduler_store_status | < 0.05 | 各TiKVインスタンスのリージョンスコアが均衡しているかどうかを確認します。インスタンス間の期待される差は5%未満です。 | | TiKV | ストア利用可能バランス | pd_scheduler_store_status | < 0.2 | 各TiKVインスタンスの利用可能なストレージのバランスを確認します。インスタンス間の差は20%未満であることが想定されています。 | -| TiKV | リージョン数 | pd_scheduler_store_status | 20000未満 | 各 TiKV インスタンスのリージョン数を確認します。1 つのインスタンスあたりのリージョン数は 20,000 未満と想定されています。 | +| TiKV | リージョン数 | pd_scheduler_store_status | 20000未満 | 各 TiKV インスタンスのリージョン数を確認します。1つのインスタンスあたりのリージョン数は 20,000 未満と想定されています。 | | PD | リージョンの健康 | pd_region_health | 100未満 | クラスター内でスケジュール処理中のリージョンの数を検出します。想定される数は合計で100未満です。 | さらに、このルールは、TiKV インスタンス内の次のスレッドの CPU 使用率が高すぎるかどうかもチェックします。 diff --git a/information-schema/information-schema-inspection-summary.md b/information-schema/information-schema-inspection-summary.md index efed0e59069d2..1ed661a3d6728 100644 --- a/information-schema/information-schema-inspection-summary.md +++ b/information-schema/information-schema-inspection-summary.md @@ -51,7 +51,7 @@ DESC inspection_summary; 診断結果表と診断監視サマリー表はどちらも、 `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 つの期間における読み取りリンクの監視メトリックを比較します。 +次の例では、2つの期間における読み取りリンクの監視メトリックを比較します。 - `(2020-01-16 16:00:54.933, 2020-01-16 16:10:54.933)` - `(2020-01-16 16:10:54.933, 2020-01-16 16:20:54.933)` diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 8d68d1a8df7c0..14a237720b89d 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -5,14 +5,14 @@ summary: METRICS_SUMMARY システム テーブルについて学習します。 # METRICS_SUMMARY {#metrics-summary} -TiDB クラスタには多くの監視メトリックがあります。異常な監視メトリックを容易に検出できるように、TiDB 4.0 では次の 2 つの監視サマリーテーブルが導入されています。 +TiDB クラスタには多くの監視メトリックがあります。異常な監視メトリックを容易に検出できるように、TiDB 4.0 では次の2つの監視サマリーテーブルが導入されています。 - `information_schema.metrics_summary` - `information_schema.metrics_summary_by_label` > **Note:** > -> 上記の 2 つの監視概要テーブルは、TiDB Self-Managed にのみ適用され、 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/)では使用できません。 +> 上記の2つの監視概要テーブルは、TiDB Self-Managed にのみ適用され、 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/)では使用できません。 2つの表は、すべての監視データを要約したもので、各監視メトリックを効率的に確認できます。 `information_schema.metrics_summary`と比較して、表`information_schema.metrics_summary_by_label`には`label`列が追加され、異なるラベルに応じて区別された統計情報が表示されます。 @@ -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`に従って結合され、差異値に従ってソートされます。`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-runaway-watches.md b/information-schema/information-schema-runaway-watches.md index 9e042b68a89eb..9807ecb88362e 100644 --- a/information-schema/information-schema-runaway-watches.md +++ b/information-schema/information-schema-runaway-watches.md @@ -147,4 +147,4 @@ RESOURCE_GROUP_NAME: default - `Exact`は、SQLテキストが一致したことを示します。この場合、 `WATCH_TEXT`列にSQLテキストが表示されます。 - `SOURCE` ：監視対象アイテムの発生源。 `QUERY_LIMIT`ルールによって識別された場合は、識別されたTiDB IPアドレスが表示されます。手動で追加された場合は、 `manual`が表示されます。 - `ACTION` : 識別後の対応する操作。 -- `RULE` : 識別ルール。現在の 3 つのルールは`ElapsedTime` 、 `ProcessedKeys` 、および`RequestUnit`です。形式は`ProcessedKeys = 666(10)`で、 `666`は実際の値、 `10`はしきい値です。 +- `RULE` : 識別ルール。現在の 3つのルールは`ElapsedTime` 、 `ProcessedKeys` 、および`RequestUnit`です。形式は`ProcessedKeys = 666(10)`で、 `666`は実際の値、 `10`はしきい値です。 diff --git a/information-schema/information-schema-sql-diagnostics.md b/information-schema/information-schema-sql-diagnostics.md index 16a0cc8d1fd25..f99f60dc1884f 100644 --- a/information-schema/information-schema-sql-diagnostics.md +++ b/information-schema/information-schema-sql-diagnostics.md @@ -16,7 +16,7 @@ SQL 診断システムには、次の利点があります。 ## 概要 {#overview} -SQL 診断システムは、次の 3 つの主要部分で構成されます。 +SQL 診断システムは、次の3つの主要部分で構成されます。 - **クラスタ情報テーブル**：SQL診断システムは、各インスタンスの個別情報を統一的に取得できるクラスタ情報テーブルを導入します。このシステムは、クラスタトポロジ、ハードウェア情報、ソフトウェア情報、カーネルパラメータ、監視情報、システム情報、スロークエリ、ステートメント、そしてクラスタ全体のログをテーブルに完全に統合します。そのため、これらの情報をSQL文で照会できます。 diff --git a/information-schema/information-schema-tidb-hot-regions-history.md b/information-schema/information-schema-tidb-hot-regions-history.md index b757dd39accad..ac9a9ce17d203 100644 --- a/information-schema/information-schema-tidb-hot-regions-history.md +++ b/information-schema/information-schema-tidb-hot-regions-history.md @@ -13,7 +13,7 @@ summary: TIDB_HOT_REGIONS_HISTORY`情報スキーマテーブルについて学 -記録間隔は[`hot-regions-write-interval`](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を設定することで指定できます。デフォルト値は 10 分です。ホット リージョンの履歴情報を保持する期間は[`hot-regions-reserved-days`](/pd-configuration-file.md#hot-regions-reserved-days-new-in-v540)を設定することで指定できます。デフォルト値は 7 日です。詳細は、 [PD設定ファイルの説明](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を参照してください。 +記録間隔は[`hot-regions-write-interval`](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を設定することで指定できます。デフォルト値は 10分です。ホット リージョンの履歴情報を保持する期間は[`hot-regions-reserved-days`](/pd-configuration-file.md#hot-regions-reserved-days-new-in-v540)を設定することで指定できます。デフォルト値は 7日です。詳細は、 [PD設定ファイルの説明](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を参照してください。 diff --git a/information-schema/information-schema-tidb-index-usage.md b/information-schema/information-schema-tidb-index-usage.md index 648b801807313..8188d98e47ea9 100644 --- a/information-schema/information-schema-tidb-index-usage.md +++ b/information-schema/information-schema-tidb-index-usage.md @@ -99,7 +99,7 @@ DESC CLUSTER_TIDB_INDEX_USAGE; ## 制限事項 {#limitations} -- `TIDB_INDEX_USAGE`テーブルのデータは、最大 5 分遅れる場合があります。 +- `TIDB_INDEX_USAGE`テーブルのデータは、最大 5分遅れる場合があります。 - TiDBが再起動すると、 `TIDB_INDEX_USAGE`テーブルのデータがクリアされます。 - TiDBは、テーブルに有効な統計情報がある場合にのみ、そのテーブルのインデックス使用状況を記録します。 diff --git a/information-schema/information-schema-tikv-region-peers.md b/information-schema/information-schema-tikv-region-peers.md index 1f60b75323f3c..24e2cc53bc13a 100644 --- a/information-schema/information-schema-tikv-region-peers.md +++ b/information-schema/information-schema-tikv-region-peers.md @@ -33,7 +33,7 @@ DESC TIKV_REGION_PEERS; 7 rows in set (0.01 sec) ``` -例えば、次の SQL ステートメントを使用すると、 `WRITTEN_BYTES`の最大値を持つ上位 3 つのリージョンの特定の TiKV アドレスを照会できます。 +例えば、次の SQL ステートメントを使用すると、 `WRITTEN_BYTES`の最大値を持つ上位 3つのリージョンの特定の TiKV アドレスを照会できます。 ```sql SELECT diff --git a/join-reorder.md b/join-reorder.md index 77c721413f6b0..9d1d3f3c273b0 100644 --- a/join-reorder.md +++ b/join-reorder.md @@ -13,12 +13,12 @@ summary: 結合したテーブルの再配置アルゴリズムを使用して SELECT * FROM t1, t2, t3 WHERE t1.a=t2.a AND t3.a=t2.a; ``` -このクエリでは、テーブルを次の 2 つの順序で結合できます。 +このクエリでは、テーブルを次の2つの順序で結合できます。 - t1はt2に結合し、次にt3に結合します。 - t2はt3に結合し、次にt1に結合します。 -t1 と t3 のデータ量と分布は異なるため、これら 2 つの実行順序では異なるパフォーマンスが現れる場合があります。 +t1 と t3 のデータ量と分布は異なるため、これら2つの実行順序では異なるパフォーマンスが現れる場合があります。 したがって、オプティマイザは結合順序を決定するアルゴリズムを必要とします。現在、TiDBでは以下の2つの結合したテーブルの再配置アルゴリズムが使用されています。 @@ -27,7 +27,7 @@ t1 と t3 のデータ量と分布は異なるため、これら 2 つの実行 ## 例: 結合したテーブルの再配置の貪欲アルゴリズム {#example-the-greedy-algorithm-of-join-reorder} -前述の 3 つのテーブル (t1、t2、t3) を例に挙げます。 +前述の3つのテーブル (t1、t2、t3) を例に挙げます。 まず、TiDB は結合操作に参加するすべてのノードを取得し、行番号の昇順にノードをソートします。 @@ -39,7 +39,7 @@ t1 と t3 のデータ量と分布は異なるため、これら 2 つの実行 その後、TiDBは次の選択ラウンドに進みます。4つのテーブルを結合しようとすると、TiDBは出力結果セットのサイズを比較し続け、結果セットが小さい方のペアを選択します。 -この場合、結合されるテーブルは 3 つだけなので、TiDB は最終的な結合結果を取得します。 +この場合、結合されるテーブルは 3つだけなので、TiDB は最終的な結合結果を取得します。 ![join-reorder-3](/media/join-reorder-3.png) diff --git a/latency-breakdown.md b/latency-breakdown.md index a526a02c1181b..0b79760d3cf7b 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -73,7 +73,7 @@ e2e duration = ## クエリを読む {#read-queries} -読み取りクエリにはプロセス フォームが 1 つだけあります。 +読み取りクエリにはプロセス フォームが 1つだけあります。 ### PointGet {#point-get} @@ -313,7 +313,7 @@ Diagram( | 自動コミット | 実行 + ロック + コミット | 実行 + コミット | | 非自動コミット | 実行 + ロック | 実行する | -書き込みクエリは次の 3 つのフェーズに分かれています。 +書き込みクエリは次の3つのフェーズに分かれています。 - 実行フェーズ: 変更を実行し、TiDB のメモリに書き込みます。 - ロックフェーズ: 実行結果に対して悲観的ロックを取得します。 @@ -520,7 +520,7 @@ Commit_time = commit_round * tidb_tikvclient_request_seconds{type="Commit"} ``` -コミット期間は、次の 4 つの指標に分類できます。 +コミット期間は、次の4つの指標に分類できます。 - `Get_latest_ts_time`は、非同期コミットまたはシングル フェーズ コミット (1PC) トランザクションで最新の TSO を取得するのにかかる時間を記録します。 - `Prewrite_time`は事前書き込みフェーズの期間を記録します。 @@ -612,7 +612,7 @@ Diagram( - RPC クライアントは各ストアへの接続プール (ConnArray という名前) を維持し、各プールにはバッチ要求 (送信) チャネルを持つ BatchConn があります。 - ストアが TiKV であり、バッチ サイズが正の場合、バッチが有効になります。これはほとんどの場合に当てはまります。 - バッチ要求チャネルのサイズは[`tikv-client.max-batch-size`](/tidb-configuration-file.md#max-batch-size) (デフォルトは`128` ) で、エンキューの期間は`tidb_tikvclient_batch_wait_duration`として観測されます。 -- ストリーム要求には`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3 種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 +- ストリーム要求には`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 まだいくらかのレイテンシーが観測されていますが、 `tidb_tikvclient_request_seconds`は次のように概算できます。 @@ -722,7 +722,7 @@ async write duration(async io enabled) = tikv_raftstore_apply_log_duration_seconds ``` -非同期書き込みは次の 3 つのフェーズに分けられます。 +非同期書き込みは次の3つのフェーズに分けられます。 - 提案 - コミット diff --git a/literal-values.md b/literal-values.md index f2ed995a4ba0e..c3c7a94c34d8c 100644 --- a/literal-values.md +++ b/literal-values.md @@ -28,7 +28,7 @@ TiDBのリテラル値には、文字リテラル、数値リテラル、時刻 `ANSI_QUOTES` SQL モードが有効になっている場合、二重引用符で囲まれた文字列は識別子として解釈されるため、文字列リテラルは一重引用符で囲んでのみ囲むことができます。 -文字列は次の 2 つのタイプに分かれます。 +文字列は次の2つのタイプに分かれます。 - バイナリ文字列: 文字セットと照合順序が両方とも`binary`あるバイトのシーケンスで構成され、比較の単位として**バイト**を使用します。 - 非バイナリ文字列: 文字のシーケンスで構成され、 `binary`以外の様々な文字セットと照合順序を持ちます。非バイナリ文字列は、**文字を**単位として互いに比較されます。文字セットによっては、1文字に複数のバイトが含まれる場合があります。 diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index f12d9767e1199..15b752616c1e3 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -148,7 +148,7 @@ TiDB ホットフィックス パッケージが`/tmp/tidb-hotfix.tar.gz`にあ tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -R tidb ``` -クラスター内の 1 つの TiDB パッケージのみを置き換えることもできます。 +クラスター内の 1つの TiDB パッケージのみを置き換えることもできます。 ```bash tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -N 172.16.4.5:4000 diff --git a/max-min-eliminate.md b/max-min-eliminate.md index 3545efaa45094..db1a0c5fdf47b 100644 --- a/max-min-eliminate.md +++ b/max-min-eliminate.md @@ -7,7 +7,7 @@ summary: Max/Min関数を排除するための規則を紹介します。 SQL文に`max` `min`関数が含まれている場合、クエリオプティマイザは`max`最適化ルールを適用して、 `max` / `min`集計関数をTopN演算子に変換しようとします。これにより、TiDBはインデックスを通じてクエリ`min`より効率的に実行できます。 -この最適化ルールは`min` `select`ステートメント内の`max`関数の数に応じて次の 2 つのタイプに分けられます。 +この最適化ルールは`min` `select`ステートメント内の`max`関数の数に応じて次の2つのタイプに分けられます。 - [`max` / `min`関数が1つだけあるステートメント](#one-maxmin-function) - [複数の`max` / `min`関数を含むステートメント](#multiple-maxmin-functions) @@ -16,7 +16,7 @@ SQL文に`max` `min`関数が含まれている場合、クエリオプティマ SQL ステートメントが次の条件を満たす場合、このルールが適用されます。 -- ステートメントには、 `max`または`min`集計関数が 1 つだけ含まれています。 +- ステートメントには、 `max`または`min`集計関数が 1つだけ含まれています。 - 集計関数には関連する`group by`節がありません。 例えば： diff --git a/metrics-schema.md b/metrics-schema.md index b79b588ef0a03..a7ebd9987ca6c 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -113,7 +113,7 @@ SELECT * FROM information_schema.metrics_tables WHERE table_name='tidb_query_dur - `TABLE_NAME` : `metrics_schema`のテーブル名に対応します。この例では、テーブル名は`tidb_query_duration`です。 - `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータを要求し、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 -- `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type`の 2 つのラベルがあります。 +- `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type`の 2つのラベルがあります。 - `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 - `COMMENT` : 監視テーブルの説明。`tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 @@ -193,11 +193,11 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN 監視項目の値を異なる粒度で表示するには、監視テーブルをクエリする前に、上記の2つのセッション変数を変更します。例： -1. 2 つのセッション変数の値を変更し、時間の粒度を 30 秒に設定します。 +1. 2つのセッション変数の値を変更し、時間の粒度を 30秒に設定します。 > **Note:** > - > Prometheus でサポートされる最小粒度は 30 秒です。 + > Prometheus でサポートされる最小粒度は 30秒です。 ```sql set @@tidb_metric_query_step=30; diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index dfff242157cc3..03a5fcc925bf0 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -107,7 +107,7 @@ nohup tiup tidb-lightning -config tidb-lightning-schema.toml > nohup.out 2>&1 & 1 row in set (0.012 sec) ``` -2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)を参照してください。binlogの位置を取得したら、5 分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 +2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)を参照してください。binlogの位置を取得したら、5分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 #### 2.2 データファイル用のTiDB Lightning構成ファイルを作成する {#2-2-create-the-tidb-lightning-configuration-file-for-the-data-file} @@ -162,7 +162,7 @@ TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lig 2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 3. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index c52c74202d64b..893f874ceb0d1 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -96,7 +96,7 @@ pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:237 TiDB Lightningは、サイズが約256MiBの均一なCSVファイルからデータをインポートする場合、最高のパフォーマンスを発揮します。しかし、単一の大きなCSVファイルからデータをインポートする場合、 TiDB Lightningはデフォルトでは1つのスレッドしか使用できないため、インポート速度が低下する可能性があります。 -インポートを高速化するために、大きな CSV ファイルを小さなファイルに分割することができます。一般的な形式の CSV ファイルの場合、 TiDB Lightning がファイル全体を読み込む前に、各行の開始位置と終了位置を素早く特定するのは困難です。そのため、 TiDB Lightning はデフォルトでは CSV ファイルを自動的に分割しません。ただし、インポートする CSV ファイルが特定の形式要件を満たしている場合は、 `strict-format`モードを有効にすることができます。このモードでは、 TiDB Lightning は1 つの大きな CSV ファイルを約 256 MiB の複数のファイルに自動的に分割し、並列処理します。 +インポートを高速化するために、大きな CSV ファイルを小さなファイルに分割することができます。一般的な形式の CSV ファイルの場合、 TiDB Lightning がファイル全体を読み込む前に、各行の開始位置と終了位置を素早く特定するのは困難です。そのため、 TiDB Lightning はデフォルトでは CSV ファイルを自動的に分割しません。ただし、インポートする CSV ファイルが特定の形式要件を満たしている場合は、 `strict-format`モードを有効にすることができます。このモードでは、 TiDB Lightning は1つの大きな CSV ファイルを約 256 MiB の複数のファイルに自動的に分割し、並列処理します。 > **Note:** > @@ -126,7 +126,7 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 -- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 +- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進行状況を確認します。 TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-from-mariadb.md b/migrate-from-mariadb.md index 525212842c786..78837104757a0 100644 --- a/migrate-from-mariadb.md +++ b/migrate-from-mariadb.md @@ -186,7 +186,7 @@ WHERE TiDB は、MariaDB でよく使用される`latin1_swedish_ci`照合順序をサポートしていません。 -TiDB は、MariaDB 11.6 以降のバージョンのデフォルトの照合順序である`utf8mb4_uca1400_ai_ci`をサポートしていません。代わりに`utf8mb4_0900_ai_ci`を使用してください。これら 2 つの照合順序は[Unicode照合アルゴリズム（UCA）](http://www.unicode.org/reports/tr10/) : `utf8mb4_0900_ai_ci`は UCA 9.0.0 を使用し、 `utf8mb4_uca1400_ai_ci`は UCA 14.0.0 を使用します。 +TiDB は、MariaDB 11.6 以降のバージョンのデフォルトの照合順序である`utf8mb4_uca1400_ai_ci`をサポートしていません。代わりに`utf8mb4_0900_ai_ci`を使用してください。これら2つの照合順序は[Unicode照合アルゴリズム（UCA）](http://www.unicode.org/reports/tr10/) : `utf8mb4_0900_ai_ci`は UCA 9.0.0 を使用し、 `utf8mb4_uca1400_ai_ci`は UCA 14.0.0 を使用します。 TiDBがサポートする照合順序を確認するには、TiDBで次のステートメントを実行してください。 diff --git a/migrate-from-parquet-files-to-tidb.md b/migrate-from-parquet-files-to-tidb.md index 071a8e5c025a2..4c8b5a6021cb1 100644 --- a/migrate-from-parquet-files-to-tidb.md +++ b/migrate-from-parquet-files-to-tidb.md @@ -113,7 +113,7 @@ pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:237 2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認してください。 TiDB Lightningはインポートが完了すると自動的に終了します。 diff --git a/migrate-from-sql-files-to-tidb.md b/migrate-from-sql-files-to-tidb.md index 87b6baac8529d..bf211fc072491 100644 --- a/migrate-from-sql-files-to-tidb.md +++ b/migrate-from-sql-files-to-tidb.md @@ -81,7 +81,7 @@ TiDB Lightning は`~/.aws/credentials`からの認証情報ファイルの読み インポートが開始された後、以下のいずれかの方法で進行状況を確認できます。 -- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。このログはデフォルトで 5 分ごとに更新されます。 +- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。このログはデフォルトで 5分ごとに更新されます。 - Grafana ダッシュボードを使用します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 インポートが完了すると、 TiDB Lightning は自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合は、インポートは成功です。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 267be45bd52b2..feefd4e1fcc33 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -5,7 +5,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する # TiDB から MySQL 互換データベースへのデータ移行 {#migrate-data-from-tidb-to-mysql-compatible-databases} -このドキュメントでは、TiDB クラスターからAurora、MySQL、MariaDB などの MySQL 互換データベースへのデータ移行方法について説明します。プロセス全体は以下の 4 つのステップで構成されます。 +このドキュメントでは、TiDB クラスターからAurora、MySQL、MariaDB などの MySQL 互換データベースへのデータ移行方法について説明します。プロセス全体は以下の4つのステップで構成されます。 1. 環境を設定します。 2. 全データを移行します。 diff --git a/migrate-from-vitess.md b/migrate-from-vitess.md index 2e4ad2d2af018..1854edd2463fc 100644 --- a/migrate-from-vitess.md +++ b/migrate-from-vitess.md @@ -11,7 +11,7 @@ VitessのバックエンドはMySQLベースであるため、VitessからTiDB 通常、データ移行前にDMタスクの`task-mode`を`all`に、`import-mode`を`physical`に設定することを推奨します。詳細については、 [タスク構成ファイルテンプレート（上級）](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)を参照してください。 -データ サイズが 10 TiB を超える場合は、2 つの手順でインポートを実行することをお勧めします。 +データ サイズが 10 TiB を超える場合は、2つの手順でインポートを実行することをお勧めします。 1. 既存のデータをインポートするには、 DumplingとTiDB Lightning を使用します。 2. DM を使用して増分データをインポートします。 @@ -24,7 +24,7 @@ VitessとTiDBはどちらもMySQLプロトコルとSQL方言をサポートし ### DumplingとTiDB Lightning {#dumpling-and-tidb-lightning} -次の 2 つの例は、 DumplingとTiDB Lightningが連携して Vitess から TiDB にデータを移行する方法を示しています。 +次の2つの例は、 DumplingとTiDB Lightningが連携して Vitess から TiDB にデータを移行する方法を示しています。 - この例では、 TiDB Lightning は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を使用します。これは、最初にデータを SQL ステートメントにエンコードし、次に SQL ステートメントを実行してデータをインポートします。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index cf3663bda05b0..cc61dd7813254 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -11,7 +11,7 @@ summary: DumplingとTiDB Lightningを使用して、MySQLからTiDBへ大規模 MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規模データセットのMySQLシャードをTiDBに移行およびマージする](/migrate-small-mysql-shards-to-tidb.md)で説明されている手順に従うことができます。この手順では、完全移行と増分移行の両方がサポートされており、手順がより簡単です。 -このドキュメントの例では、 `my_db1`と`my_db2`の 2 つのデータベースがあることを前提としています。Dumplingを使用して`my_db1`から 2 つのテーブル`table1`と`table2`を、 `my_db2`から 2 つのテーブル`table3`と`table4`をそれぞれエクスポートします。その後、 TiDB Lightning を使用して、エクスポートされた 4 つのテーブルをターゲット TiDB の`mydb`にある同じ`table5`にインポートしてマージします。 +このドキュメントの例では、 `my_db1`と`my_db2`の 2つのデータベースがあることを前提としています。Dumplingを使用して`my_db1`から 2つのテーブル`table1`と`table2`を、 `my_db2`から 2つのテーブル`table3`と`table4`をそれぞれエクスポートします。その後、 TiDB Lightning を使用して、エクスポートされた 4つのテーブルをターゲット TiDB の`mydb`にある同じ`table5`にインポートしてマージします。 このドキュメントでは、以下の手順に従ってデータを移行する方法を説明します。 @@ -52,7 +52,7 @@ CREATE TABLE `table1` ( ) ENGINE=InnoDB DEFAULT CHARSET=latin1 ``` -これら 4 つのテーブルでは、 `id`列が主キーです。この列はAUTO_INCREMENTであるため、異なるシャーディング テーブルで重複する`id`範囲が生成され、移行中にターゲット テーブルで主キーの競合が発生します。一方、 `sid`列はシャーディング キーであり、インデックスがグローバルに一意であることを保証します。したがって、ターゲットの`table5`における`id`列の一意制約を削除することで、データ マージの競合を回避できます。 +これら4つのテーブルでは、 `id`列が主キーです。この列はAUTO_INCREMENTであるため、異なるシャーディング テーブルで重複する`id`範囲が生成され、移行中にターゲット テーブルで主キーの競合が発生します。一方、 `sid`列はシャーディング キーであり、インデックスがグローバルに一意であることを保証します。したがって、ターゲットの`table5`における`id`列の一意制約を削除することで、データ マージの競合を回避できます。 ```sql CREATE TABLE `table5` ( diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index e39d07ed7435c..faa49a0a0b882 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -62,7 +62,7 @@ LIMIT ### ターゲットとなるTiKVクラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster} -ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 +ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 - インデックスには余分な容量が必要になる場合があります。 - RocksDBには空間増幅がある。 @@ -151,7 +151,7 @@ LIMIT 3. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-with-pt-ghost.md b/migrate-with-pt-ghost.md index 4314c03359c4a..0b8d8baba602b 100644 --- a/migrate-with-pt-ghost.md +++ b/migrate-with-pt-ghost.md @@ -42,7 +42,7 @@ gh-ost または pt-osc のワークフロー: - DDL 実テーブルのデータをゴースト テーブルに複製します。 -- 2 つのテーブル間でデータの一貫性が保たれたら、名前変更ステートメントを使用して実際のテーブルをゴースト テーブルに置き換えます。 +- 2つのテーブル間でデータの一貫性が保たれたら、名前変更ステートメントを使用して実際のテーブルをゴースト テーブルに置き換えます。 DM のワークフロー: diff --git a/migration-overview.md b/migration-overview.md index 03a22c57c5438..3b120139a4064 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -24,7 +24,7 @@ summary: データ移行シナリオとソリューションの概要を学習 ## Aurora MySQLからTiDBへのデータ移行 {#migrate-data-from-aurora-mysql-to-tidb} -Auroraから AWS にデプロイされた TiDB クラスターにデータを移行する場合、データ移行には完全なデータ移行と増分レプリケーションの 2 つの操作が必要です。アプリケーションのニーズに応じて、対応する操作を選択できます。 +Auroraから AWS にデプロイされた TiDB クラスターにデータを移行する場合、データ移行には完全なデータ移行と増分レプリケーションの 2つの操作が必要です。アプリケーションのニーズに応じて、対応する操作を選択できます。 - [Amazon Auroraから TiDB へのデータ移行](/migrate-aurora-to-tidb.md) 。 diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 4e7d4e0513691..0dc68b8036378 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -1,6 +1,6 @@ --- title: Multiple Availability Zones in One Region Deployment -summary: 1 つのリージョン内の複数の可用性ゾーンへのデプロイメント ソリューションについて学習します。 +summary: 1つのリージョン内の複数の可用性ゾーンへのデプロイメント ソリューションについて学習します。 --- # 1つのリージョンに複数のアベイラビリティゾーンを展開 {#multiple-availability-zones-in-one-region-deployment} @@ -26,10 +26,10 @@ Raftは分散コンセンサスアルゴリズムです。このアルゴリズ Raft の信頼性を活用するには、実際の展開シナリオで次の条件を満たす必要があります。 -- 1 台のサーバーに障害が発生した場合に備えて、少なくとも 3 台のサーバーを使用します。 -- 1 つのラックが故障した場合に備えて、少なくとも 3 つのラックを使用してください。 -- 1 つの AZ に障害が発生した場合に備えて、少なくとも 3 つの AZ を使用します。 -- 1 つのリージョンでデータの安全性の問題が発生した場合に備えて、少なくとも 3 つのリージョンに TiDBをデプロイ。 +- 1台のサーバーに障害が発生した場合に備えて、少なくとも 3台のサーバーを使用します。 +- 1つのラックが故障した場合に備えて、少なくとも 3つのラックを使用してください。 +- 1つの AZ に障害が発生した場合に備えて、少なくとも 3つの AZ を使用します。 +- 1つのリージョンでデータの安全性の問題が発生した場合に備えて、少なくとも 3つのリージョンに TiDBをデプロイ。 ネイティブRaftプロトコルは、偶数個のレプリカを適切にサポートしていません。リージョン間のネットワークレイテンシーの影響を考慮すると、高可用性と耐障害性を備えたRaftデプロイメントには、同一リージョン内に3つのAZを配置することが最適なソリューションとなる可能性があります。 @@ -39,14 +39,14 @@ TiDBクラスターは、同一リージョン内の3つのAZにデプロイで ### シンプルなアーキテクチャ {#simple-architecture} -TiDB、TiKV、PD は 3 つの AZ に分散されており、これが最も一般的な展開であり、可用性が最も高くなります。 +TiDB、TiKV、PD は 3つの AZ に分散されており、これが最も一般的な展開であり、可用性が最も高くなります。 ![3-AZ Deployment Architecture](/media/deploy-3dc.png) **利点:** -- すべてのレプリカは 3 つの AZ に分散されており、高い可用性と災害復旧機能を備えています。 -- 1 つの AZ がダウンしてもデータは失われません (RPO = 0)。 +- すべてのレプリカは 3つの AZ に分散されており、高い可用性と災害復旧機能を備えています。 +- 1つの AZ がダウンしてもデータは失われません (RPO = 0)。 - 1つのAZがダウンした場合でも、他の2つのAZが自動的にリーダー選出を開始し、一定時間内（通常は20秒以内）にサービスを自動的に再開します。詳細については、次の図をご覧ください。 ![Disaster Recovery for 3-AZ Deployment](/media/deploy-3dc-dr.png) @@ -87,8 +87,8 @@ member leader_priority pdName3 3 **デメリット:** - 書き込みシナリオは、依然としてAZ間のネットワークレイテンシーの影響を受けます。これは、 Raftが多数決プロトコルに準拠し、書き込まれたすべてのデータが少なくとも2つのAZに複製される必要があるためです。 -- サービスを提供する TiDBサーバーは1 つの AZ にのみ存在します。 -- すべてのアプリケーション トラフィックは 1 つの AZ によって処理され、パフォーマンスはその AZ のネットワーク帯域幅の圧力によって制限されます。 +- サービスを提供する TiDBサーバーは1つの AZ にのみ存在します。 +- すべてのアプリケーション トラフィックは 1つの AZ によって処理され、パフォーマンスはその AZ のネットワーク帯域幅の圧力によって制限されます。 - TSO の取得能力と読み取りパフォーマンスは、アプリケーショントラフィックを処理する AZ 内の PDサーバーと TiKVサーバーが稼働しているかどうかによって影響を受けます。これらのサーバーがダウンしている場合でも、アプリケーションはセンター間ネットワークレイテンシーの影響を受けます。 ### 展開例 {#deployment-example} @@ -159,7 +159,7 @@ tikv_servers: server.labels: { zone: "z3", az: "az3", rack: "r2", host: "41" } ``` -上記の例では、 `zone`レプリカの分離を制御する論理可用性ゾーンレイヤーです (サンプル クラスターには 3 つのレプリカがあります)。 +上記の例では、 `zone`レプリカの分離を制御する論理可用性ゾーンレイヤーです (サンプル クラスターには 3つのレプリカがあります)。 将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`をスケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。 diff --git a/mysql-schema/mysql-schema-user.md b/mysql-schema/mysql-schema-user.md index 065e3d7ebf342..b3ed181fb6320 100644 --- a/mysql-schema/mysql-schema-user.md +++ b/mysql-schema/mysql-schema-user.md @@ -68,7 +68,7 @@ DESC mysql.user; 45 rows in set (0.00 sec) ``` -`mysql.user`テーブルには、次の 3 つのグループに分類できる複数のフィールドが含まれています。 +`mysql.user`テーブルには、次の3つのグループに分類できる複数のフィールドが含まれています。 diff --git a/mysql-schema/mysql-schema.md b/mysql-schema/mysql-schema.md index 6010872bda7cf..deed6f1ff623e 100644 --- a/mysql-schema/mysql-schema.md +++ b/mysql-schema/mysql-schema.md @@ -53,7 +53,7 @@ summary: TiDBのシステムテーブルについて学びましょう。 - `stats_history` : 履歴統計のその他の情報 - `analyze_options` : 各テーブルのデフォルトの`analyze`オプション - `column_stats_usage` : 列統計の使用方法 -- `analyze_jobs` : 進行中の統計収集タスクと過去 7 日間の履歴タスク記録 +- `analyze_jobs` : 進行中の統計収集タスクと過去 7日間の履歴タスク記録 ## 実行計画関連のシステムテーブル {#execution-plan-related-system-tables} @@ -82,11 +82,11 @@ summary: TiDBのシステムテーブルについて学びましょう。 - `tidb_ttl_table_status` : すべてのTTLテーブルに対して、以前に実行されたTTLジョブと進行中のTTLジョブ - `tidb_ttl_task` : 現在進行中のTTLサブタスク -- `tidb_ttl_job_history` : 過去 90 日間の TTL タスクの実行履歴 +- `tidb_ttl_job_history` : 過去 90日間の TTL タスクの実行履歴 ## 暴走クエリに関連するシステムテーブル {#system-tables-related-to-runaway-queries} -- `tidb_runaway_queries` : 過去 7 日間に検出されたすべての暴走クエリの履歴記録 +- `tidb_runaway_queries` : 過去 7日間に検出されたすべての暴走クエリの履歴記録 - `tidb_runaway_watch` : 暴走クエリの監視リスト - `tidb_runaway_watch_done` : 削除または期限切れの暴走クエリの監視リスト diff --git a/online-unsafe-recovery.md b/online-unsafe-recovery.md index 763c64a962e9b..1e1076fc35f18 100644 --- a/online-unsafe-recovery.md +++ b/online-unsafe-recovery.md @@ -47,7 +47,7 @@ pd-ctl -u unsafe remove-failed-stores > **Note:** > > - 上記のコマンドでは、回復不可能な**すべての**TiKVノードとTiFlashノードが一度に指定されていることを確認してください。回復不可能なノードを省略すると、回復プロセスがブロックされる可能性があります。 -> - 短期間内（1 日以内など）にオンライン アンセーフ リカバリを既に実行している場合は、このコマンドの後続の実行に、以前に処理された TiKV ノードとTiFlashノードがまだ含まれていることを確認してください。 +> - 短期間内（1日以内など）にオンライン アンセーフ リカバリを既に実行している場合は、このコマンドの後続の実行に、以前に処理された TiKV ノードとTiFlashノードがまだ含まれていることを確認してください。 リカバリタスクの最長時間を指定するには、 `--timeout `オプションを使用します。このオプションを指定しない場合、デフォルトの最長時間は5分です。タイムアウトが発生すると、リカバリは中断され、エラーが返されます。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index fffe2522ad80e..ddba45328561b 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -18,7 +18,7 @@ v6.5.3 および v7.1.0 以降、TiDB は、オプティマイザーの動作を 各修正は、特定の目的のためにTiDBオプティマイザーの動作を調整するために用いられる制御項目です。修正には、動作変更の技術的な詳細が記載されたGitHub Issueに対応する番号が付けられています。例えば、修正`44262`の場合、修正[問題44262](https://github.com/pingcap/tidb/issues/44262)でその制御内容を確認できます。 -システム変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 、複数の修正をカンマ区切りで 1 つの値として受け入れます ( `,` )。形式は`"<#issue1>:,<#issue2>:,...,<#issueN>:"`で、 `<#issueN>`修正番号です。例: +システム変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) 、複数の修正をカンマ区切りで 1つの値として受け入れます ( `,` )。形式は`"<#issue1>:,<#issue2>:,...,<#issueN>:"`で、 `<#issueN>`修正番号です。例: ```sql SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; @@ -88,7 +88,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON` - 可能`OFF`値: `ON` - クエリプランの各プランステップで適切な行数を正確に推定することは困難であるため、オプティマイザは`estRows`小さく推定する場合があります。この変数は、最小値`estRows`を制限するかどうかを制御します。 -- `ON` : 最小値`estRows`を 1 に制限します。これは、v8.4.0 で導入された新しい動作であり、Oracle や Db2 などの他のデータベースと一致しています。 +- `ON` : 最小値`estRows`を1に制限します。これは、v8.4.0 で導入された新しい動作であり、Oracle や Db2 などの他のデータベースと一致しています。 - `OFF` : 最小行数推定制限を無効にします。これにより、v8.4.0 より前のバージョンとの動作の一貫性が維持されます。この場合、 `estRows` 0 になる可能性があります。 ### `52592`バージョン8.4.0の新機能 {#52592-new-in-v840} @@ -123,4 +123,4 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON` - 可能`OFF`値: `ON` -- この変数は`ORDER BY`ステートメントで使用される重い式を 2 回計算することを回避するかどうかを制御します。 +- この変数は`ORDER BY`ステートメントで使用される重い式を 2回計算することを回避するかどうかを制御します。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 9909ed8a5dd1b..2b8f762858608 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -370,7 +370,7 @@ SELECT /*+ USE_INDEX(t1, idx1, idx2) */ * FROM t1; `FORCE_INDEX(t1_name, idx1_name [, idx2_name ...])`の使い方と効果は`USE_INDEX(t1_name, idx1_name [, idx2_name ...])`の使い方と効果と同じです。 -次の 4 つのクエリは同じ効果があります。 +次の4つのクエリは同じ効果があります。 ```sql SELECT /*+ USE_INDEX(t, idx1) */ * FROM t; @@ -629,7 +629,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * SELECT /*+ QB_NAME(v_1, v) USE_INDEX(t@v_1, idx) */ * FROM v; ``` -- ネストされたビューとサブクエリを含む複雑なステートメントの場合、次の例では、ビュー`v1`と`v2`の 2 つのクエリ ブロックのそれぞれの名前を指定します。 +- ネストされたビューとサブクエリを含む複雑なステートメントの場合、次の例では、ビュー`v1`と`v2`の 2つのクエリ ブロックのそれぞれの名前を指定します。 ```sql SELECT /* Comment: The name of the current query block is the default @SEL_1 */ * FROM v2 JOIN ( @@ -740,7 +740,7 @@ select /*+ USE_TOJA(TRUE) */ t1.a, t1.b from t1 where t1.a in (select t2.a from ### MAX_EXECUTION_TIME(N) {#max_execution_timen} -`MAX_EXECUTION_TIME(N)`ヒントは、サーバーが文の実行を終了させるまでの制限時間`N` （ミリ秒単位のタイムアウト値）を設定します。次のヒントでは、 `MAX_EXECUTION_TIME(1000)`タイムアウトが 1000 ミリ秒（つまり 1 秒）であることを意味します。 +`MAX_EXECUTION_TIME(N)`ヒントは、サーバーが文の実行を終了させるまでの制限時間`N` （ミリ秒単位のタイムアウト値）を設定します。次のヒントでは、 `MAX_EXECUTION_TIME(1000)`タイムアウトが 1000 ミリ秒（つまり 1秒）であることを意味します。 ```sql select /*+ MAX_EXECUTION_TIME(1000) */ * from t1 inner join t2 where t1.id = t2.id; diff --git a/overview.md b/overview.md index faae89858befc..bd210b03195cb 100644 --- a/overview.md +++ b/overview.md @@ -37,7 +37,7 @@ TiDB Self-Managedは、TiDBの製品オプションの一つであり、ユー - **クラウドネイティブ分散データベース** - TiDB はクラウド向けに設計された分散データベースで、クラウド プラットフォーム上で柔軟なスケーラビリティ、信頼性、セキュリティを提供します。ユーザーは、変化するワークロードの要件に合わせて TiDB を柔軟に拡張できます。TiDB では、各データに少なくとも 3 つのレプリカがあり、異なるクラウド可用性ゾーンにスケジュールすることで、データ センター全体の停止にも対応できます。TiDB [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview) Kubernetes 上での TiDB の管理を支援し、TiDB クラスターの運用に関連するタスクを自動化することで、マネージド Kubernetes を提供するあらゆるクラウドへの TiDB のデプロイを容易にします。フル マネージド TiDB サービスである[TiDB Cloud](https://pingcap.com/tidb-cloud/) 、[クラウド上のTiDB](https://docs.pingcap.com/tidbcloud/)の真の力を引き出す最も簡単で経済的かつ堅牢な方法であり、数回のクリックだけで TiDB クラスターをデプロイして実行できます。 + TiDB はクラウド向けに設計された分散データベースで、クラウド プラットフォーム上で柔軟なスケーラビリティ、信頼性、セキュリティを提供します。ユーザーは、変化するワークロードの要件に合わせて TiDB を柔軟に拡張できます。TiDB では、各データに少なくとも 3つのレプリカがあり、異なるクラウド可用性ゾーンにスケジュールすることで、データ センター全体の停止にも対応できます。TiDB [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview) Kubernetes 上での TiDB の管理を支援し、TiDB クラスターの運用に関連するタスクを自動化することで、マネージド Kubernetes を提供するあらゆるクラウドへの TiDB のデプロイを容易にします。フル マネージド TiDB サービスである[TiDB Cloud](https://pingcap.com/tidb-cloud/) 、[クラウド上のTiDB](https://docs.pingcap.com/tidbcloud/)の真の力を引き出す最も簡単で経済的かつ堅牢な方法であり、数回のクリックだけで TiDB クラスターをデプロイして実行できます。 - **MySQLプロトコルおよびMySQLエコシステムと互換性があります。** diff --git a/partition-pruning.md b/partition-pruning.md index 38f103115afe2..b027dc2ace9d5 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -39,7 +39,7 @@ EXPLAIN SELECT * FROM t1 WHERE id BETWEEN 80 AND 120; ## パーティションプルーニングの使用シナリオ {#usage-scenarios-of-partition-pruning} -パーティション プルーニングの使用シナリオは、範囲パーティション テーブルとハッシュ パーティション テーブルという 2 種類のパーティション テーブルで異なります。 +パーティション プルーニングの使用シナリオは、範囲パーティション テーブルとハッシュ パーティション テーブルという 2種類のパーティション テーブルで異なります。 ### ハッシュパーティションテーブルでパーティションプルーニングを使用する {#use-partition-pruning-in-hash-partitioned-tables} @@ -68,7 +68,7 @@ explain select * from t where x = 1; #### ハッシュパーティションテーブルに適用されないシナリオ {#inapplicable-scenarios-in-hash-partitioned-tables} -このセクションでは、ハッシュ パーティション テーブルでのパーティション プルーニングの適用されない 2 つの使用シナリオについて説明します。 +このセクションでは、ハッシュ パーティション テーブルでのパーティション プルーニングの適用されない 2つの使用シナリオについて説明します。 ##### シナリオ1 {#scenario-one} @@ -139,7 +139,7 @@ explain select * from t2 where x = (select * from t1 where t2.x = t1.x and t2.x #### 範囲パーティションテーブルに適用可能なシナリオ {#applicable-scenarios-in-range-partitioned-tables} -このセクションでは、範囲パーティション化されたテーブルでのパーティション プルーニングの適用可能な 3 つの使用シナリオについて説明します。 +このセクションでは、範囲パーティション化されたテーブルでのパーティション プルーニングの適用可能な 3つの使用シナリオについて説明します。 ##### シナリオ1 {#scenario-one} diff --git a/partitioned-table.md b/partitioned-table.md index 4efd22b9d5bf6..dcc27998ecaf8 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -154,7 +154,7 @@ PARTITION BY RANGE ( UNIX_TIMESTAMP(report_updated) ) ( ### 範囲列パーティショニング {#range-columns-partitioning} -範囲列パーティショニングは、範囲パーティショニングのバリアントです。1 つ以上の列をパーティショニング キーとして使用できます。パーティション列のデータ型は、整数、文字列 ( `CHAR`または`VARCHAR` )、 `DATE` 、および`DATETIME` 。列を使用しないパーティショニングなどの式はサポートされていません。 +範囲列パーティショニングは、範囲パーティショニングのバリアントです。1つ以上の列をパーティショニング キーとして使用できます。パーティション列のデータ型は、整数、文字列 ( `CHAR`または`VARCHAR` )、 `DATE` 、および`DATETIME` 。列を使用しないパーティショニングなどの式はサポートされていません。 範囲パーティショニングと同様に、範囲列パーティショニングでも、パーティション範囲は厳密に増加している必要があります。次の例のパーティション定義はサポートされていません。 @@ -525,7 +525,7 @@ PARTITION BY LIST COLUMNS(id,name) ( ハッシュパーティションテーブルを作成するには、 `PARTITION BY HASH (expr)`ステートメントに`CREATE TABLE` } 句を追加する必要があります。 `expr`は整数を返す式です。この列の型が整数型の場合は、列名にすることができます。さらに、 `PARTITIONS num`を追加する必要がある場合もあります。ここで、 `num`は、テーブルが分割されるパーティションの数を示す正の整数です。 -以下の操作は、 `store_id`によって 4 つのパーティションに分割されたハッシュパーティションテーブルを作成します。 +以下の操作は、 `store_id`によって 4つのパーティションに分割されたハッシュパーティションテーブルを作成します。 ```sql CREATE TABLE employees ( @@ -593,9 +593,9 @@ TiDBはバージョン7.0.0以降、キーパーティショニングをサポ キーパーティショニングとハッシュパーティショニングはどちらも、データを一定数のパーティションに均等に分散できます。違いは、ハッシュパーティショニングは指定された整数式または整数列に基づいてのみデータを分散できるのに対し、キーパーティショニングは列リストに基づいてデータを分散できる点です。また、キーパーティショニングのパーティション列は整数型に限定されません。TiDBのキーパーティショニングにおけるハッシュアルゴリズムはMySQLとは異なるため、テーブルデータの分散方法も異なります。 -キーパーティションテーブルを作成するには、 `PARTITION BY KEY (columnList)`ステートメントに`CREATE TABLE` } 句を追加する必要があります。 `columnList`は、1 つ以上の列名を含む列リストです。リスト内の各列のデータ型は`BLOB` 、 `JSON` 、および`GEOMETRY`除く任意の型にすることができます (TiDB は`GEOMETRY` } をサポートしていないことに注意してください)。さらに、 `PARTITIONS num` (ここで`num`テーブルが分割されるパーティションの数を示す正の整数) を追加したり、パーティション名の定義を追加したりする必要がある場合もあります。たとえば、 `(PARTITION p0, PARTITION p1)`を追加すると、テーブルが`p0`と`p1`という名前の 2 つのパーティションに分割されます。 +キーパーティションテーブルを作成するには、 `PARTITION BY KEY (columnList)`ステートメントに`CREATE TABLE` } 句を追加する必要があります。 `columnList`は、1つ以上の列名を含む列リストです。リスト内の各列のデータ型は`BLOB` 、 `JSON` 、および`GEOMETRY`除く任意の型にすることができます (TiDB は`GEOMETRY` } をサポートしていないことに注意してください)。さらに、 `PARTITIONS num` (ここで`num`テーブルが分割されるパーティションの数を示す正の整数) を追加したり、パーティション名の定義を追加したりする必要がある場合もあります。たとえば、 `(PARTITION p0, PARTITION p1)`を追加すると、テーブルが`p0`と`p1`という名前の 2つのパーティションに分割されます。 -以下の操作では、 `store_id`によって 4 つのパーティションに分割されたキーパーティションテーブルを作成します。 +以下の操作では、 `store_id`によって 4つのパーティションに分割されたキーパーティションテーブルを作成します。 ```sql CREATE TABLE employees ( @@ -631,7 +631,7 @@ PARTITION BY KEY(fname) PARTITIONS 4; ``` -複数の列に基づいてキーパーティションテーブルを作成することもできます。たとえば、 `fname`と`store_id`に基づいてテーブルを 4 つのパーティションに分割できます。 +複数の列に基づいてキーパーティションテーブルを作成することもできます。たとえば、 `fname`と`store_id`に基づいてテーブルを 4つのパーティションに分割できます。 ```sql CREATE TABLE employees ( @@ -1195,7 +1195,7 @@ SELECT fname, lname, region_code, dob 結果は`p1`または`p2`パーティションのいずれかに該当することは明らかです。つまり、 `p1`と`p2`で一致する行を検索するだけで済みます。不要なパーティションを除外することを「プルーニング」と呼びます。オプティマイザがパーティションの一部をプルーニングできる場合、パーティションテーブルでのクエリの実行は、パーティションテーブルでの実行よりもはるかに高速になります。 -オプティマイザは、次の 2 つのシナリオにおいて`WHERE`条件に基づいてパーティションをプルーニングすることができます。 +オプティマイザは、次の2つのシナリオにおいて`WHERE`条件に基づいてパーティションをプルーニングすることができます。 - パーティション列 = 定数 - partition_column IN (constant1, constant2, ..., constantN) @@ -1786,7 +1786,7 @@ show stats_meta where table_name like "t"; set global tidb_partition_prune_mode = dynamic ``` -`static`モードでは、TiDB は複数の演算子を使用して各パーティションに個別にアクセスし、 `Union`を使用して結果をマージします。次の例は、TiDB が`Union`を使用して対応する 2 つのパーティションの結果をマージする単純な読み取り操作です。 +`static`モードでは、TiDB は複数の演算子を使用して各パーティションに個別にアクセスし、 `Union`を使用して結果をマージします。次の例は、TiDB が`Union`を使用して対応する 2つのパーティションの結果をマージする単純な読み取り操作です。 ```sql mysql> create table t1(id int, age int, key(id)) partition by range(id) ( diff --git a/password-management.md b/password-management.md index 7d9cac3fa062f..3c6b499785915 100644 --- a/password-management.md +++ b/password-management.md @@ -90,7 +90,7 @@ SET GLOBAL validate_password.policy = LOW; SET GLOBAL validate_password.length = 10; ``` -パスワードには少なくとも 2 つの数字、1 つの大文字、1 つの小文字、および 1 つの特殊文字を含める必要があります。 +パスワードには少なくとも 2つの数字、1つの大文字、1つの小文字、および 1つの特殊文字を含める必要があります。 ```sql SET GLOBAL validate_password.number_count = 2; @@ -224,7 +224,7 @@ TiDB は、グローバル レベルとアカウント レベルでの自動パ グローバル自動パスワード有効期限ポリシーは、アカウント レベルのオーバーライドを持たないすべてのアカウントに適用されます。 - 次の例では、パスワードの有効期間が 180 日間のグローバル自動パスワード有効期限ポリシーを確立します。 + 次の例では、パスワードの有効期間が 180日間のグローバル自動パスワード有効期限ポリシーを確立します。 ```sql SET GLOBAL default_password_lifetime = 180; @@ -234,7 +234,7 @@ TiDB は、グローバル レベルとアカウント レベルでの自動パ 個々のアカウントに対して自動パスワード有効期限ポリシーを確立するには、 `CREATE USER`または`ALTER USER`ステートメントの`PASSWORD EXPIRE`オプションを使用します。 - 次の例では、ユーザー パスワードを 90 日ごとに変更する必要があります。 + 次の例では、ユーザー パスワードを 90日ごとに変更する必要があります。 ```sql CREATE USER 'test'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY; @@ -301,7 +301,7 @@ TiDB はアカウントのパスワード履歴を記録し、履歴からの新 グローバル パスワード再利用ポリシーを確立するには、システム変数[`password_history`](/system-variables.md#password_history-new-in-v650)と[`password_reuse_interval`](/system-variables.md#password_reuse_interval-new-in-v650)を使用します。 -たとえば、過去 6 個のパスワードと過去 365 日以内に使用されたパスワードの再利用を禁止するグローバル パスワード再利用ポリシーを確立するには、次のようにします。 +たとえば、過去 6 個のパスワードと過去 365日以内に使用されたパスワードの再利用を禁止するグローバル パスワード再利用ポリシーを確立するには、次のようにします。 ```sql SET GLOBAL password_history = 6; @@ -316,21 +316,21 @@ SET GLOBAL password_reuse_interval = 365; 例えば： -過去 5 つのパスワードの再利用を禁止するには: +過去 5つのパスワードの再利用を禁止するには: ```sql CREATE USER 'test'@'localhost' PASSWORD HISTORY 5; ALTER USER 'test'@'localhost' PASSWORD HISTORY 5; ``` -過去 365 日以内に使用したパスワードの再利用を禁止するには: +過去 365日以内に使用したパスワードの再利用を禁止するには: ```sql CREATE USER 'test'@'localhost' PASSWORD REUSE INTERVAL 365 DAY; ALTER USER 'test'@'localhost' PASSWORD REUSE INTERVAL 365 DAY; ``` -2 種類の再利用ポリシーを組み合わせるには、 `PASSWORD HISTORY`と`PASSWORD REUSE INTERVAL`両方を使用します。 +2種類の再利用ポリシーを組み合わせるには、 `PASSWORD HISTORY`と`PASSWORD REUSE INTERVAL`両方を使用します。 ```sql CREATE USER 'test'@'localhost' diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 5c29d6633b4b1..f56c4e12b0a37 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -57,7 +57,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの - ブートストラップのための初期クラスタ構成 - デフォルト値: `"{name}=http://{advertise-peer-url}"` - たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 -- 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 +- 3つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 ``` pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380 @@ -326,7 +326,7 @@ pd-server関連のコンフィグレーション項目 ### `max-snapshot-count` {#max-snapshot-count} -- 1 つのストアが同時に受信または送信するスナップショットの最大数を制御します。PD スケジューラは、この構成に依存して、通常のトラフィックに使用されるリソースがプリエンプトされるのを防ぎます。 +- 1つのストアが同時に受信または送信するスナップショットの最大数を制御します。PD スケジューラは、この構成に依存して、通常のトラフィックに使用されるリソースがプリエンプトされるのを防ぎます。 - デフォルト値: `64` ### `max-pending-peer-count` {#max-pending-peer-count} diff --git a/pd-control.md b/pd-control.md index d036149ce6a34..bc8890420c136 100644 --- a/pd-control.md +++ b/pd-control.md @@ -204,7 +204,7 @@ 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 がリージョン を次のリージョンとの結合のみを許可するかどうかを制御します。`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. @@ -251,7 +251,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - - `max-store-preparing-time`はストアがオンラインになるまでの最大待機時間を制御します。ストアがオンライン状態の間、PD はストアのオンライン進行状況を照会できます。指定された時間を超えると、PD はストアがオンライン状態になったとみなし、再度ストアのオンライン進行状況を照会できなくなります。ただし、これによってリージョンが新しいオンラインストアに移行するのが妨げられることはありません。ほとんどのシナリオでは、このパラメータを調整する必要はありません。 - 次のコマンドは、ストアがオンラインになるまでの最大待機時間が 4 時間であることを指定します。 + 次のコマンドは、ストアがオンラインになるまでの最大待機時間が 4時間であることを指定します。 ```bash config set max-store-preparing-time 4h @@ -269,13 +269,13 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set region-schedule-limit 2 // 2 tasks of Region scheduling at the same time at most ``` -- `replica-schedule-limit`は、レプリカを同時にスケジュールするタスクの数を制御します。この値は、ノードがダウンまたは削除された場合のスケジュール速度に影響します。値が大きいほど速度が速くなり、値を 0 に設定するとスケジュールが停止します。通常、レプリカのスケジュールは大きな負荷がかかるため、あまり大きな値を設定しないでください。この設定項目は通常、デフォルト値のままです。値を変更する場合は、実際の状況に応じて最適な値を見つけるために、いくつかの値を試す必要があります。 +- `replica-schedule-limit`は、レプリカを同時にスケジュールするタスクの数を制御します。この値は、ノードがダウンまたは削除された場合のスケジュール速度に影響します。値が大きいほど速度が速くなり、値を0に設定するとスケジュールが停止します。通常、レプリカのスケジュールは大きな負荷がかかるため、あまり大きな値を設定しないでください。この設定項目は通常、デフォルト値のままです。値を変更する場合は、実際の状況に応じて最適な値を見つけるために、いくつかの値を試す必要があります。 ```bash config set replica-schedule-limit 4 // 4 tasks of replica scheduling at the same time at most ``` -- `merge-schedule-limit`はリージョンマージのスケジュールタスクの数を制御します。値を 0 に設定すると、リージョンマージは終了します。通常、マージスケジュールは負荷が大きいため、あまり大きな値を設定しないでください。この設定項目は通常、デフォルト値のままです。値を変更する場合は、いくつかの値を試してみて、実際の状況に最適な値を見つける必要があります。 +- `merge-schedule-limit`はリージョンマージのスケジュールタスクの数を制御します。値を0に設定すると、リージョンマージは終了します。通常、マージスケジュールは負荷が大きいため、あまり大きな値を設定しないでください。この設定項目は通常、デフォルト値のままです。値を変更する場合は、いくつかの値を試してみて、実際の状況に最適な値を見つける必要があります。 ```bash config set merge-schedule-limit 16 // 16 tasks of Merge scheduling at the same time at most @@ -1463,7 +1463,7 @@ store --jq='.stores[].store | select(.labels | length>0 and contains([{"key":"en {"id":24,"peer_stores":[1,32,33]} ``` -`[store30, store31]`がダウンしている場合は、 `remove-peer`オペレータを作成して安全に処理できるすべてのリージョン、つまり DownPeer が 1 つだけあるリージョンを見つけます。 +`[store30, store31]`がダウンしている場合は、 `remove-peer`オペレータを作成して安全に処理できるすべてのリージョン、つまり DownPeer が 1つだけあるリージョンを見つけます。 ```bash >> region --jq=".regions[] | {id: .id, remove_peer: [.peers[].store_id] | select(length>1) | map(if .==(30,31) then . else empty end) | select(length==1)}" diff --git a/pd-microservices.md b/pd-microservices.md index a4e8cae193d1a..cb1592918284c 100644 --- a/pd-microservices.md +++ b/pd-microservices.md @@ -36,7 +36,7 @@ PDマイクロサービスは通常、PDにおけるパフォーマンスのボ - TiDBコンポーネントのみがサービス検出を通じて`tso`マイクロサービスへの直接接続をサポートしますが、他のコンポーネントはタイムスタンプを取得するために PD を通じて`tso`マイクロサービスにリクエストを転送する必要があります。 - マイクロサービスは[データレプリケーション自動同期（DR自動同期）](/two-data-centers-in-one-city-deployment.md)機能と互換性がありません。 - マイクロサービスは TiDB システム変数[`tidb_enable_tso_follower_proxy`](/system-variables.md#tidb_enable_tso_follower_proxy-new-in-v530)と互換性がありません。 -- [休止状態領域](/tikv-configuration-file.md#hibernate-regions)がクラスター内に存在する可能性があるため、 `scheduling`マイクロサービスのプライマリおよびセカンダリの切り替え中に、冗長なスケジュールを回避するために、クラスターのスケジュール機能が一定期間 (最大[`peer-stale-state-check-interval`](/tikv-configuration-file.md#peer-stale-state-check-interval) 、デフォルトでは 5 分) 使用できなくなる可能性があります。 +- [休止状態領域](/tikv-configuration-file.md#hibernate-regions)がクラスター内に存在する可能性があるため、 `scheduling`マイクロサービスのプライマリおよびセカンダリの切り替え中に、冗長なスケジュールを回避するために、クラスターのスケジュール機能が一定期間 (最大[`peer-stale-state-check-interval`](/tikv-configuration-file.md#peer-stale-state-check-interval) 、デフォルトでは 5分) 使用できなくなる可能性があります。 ## 使用法 {#usage} diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index f35abde48ac73..701dab6879385 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -56,7 +56,7 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 ### データベース時間とSQL実行時間の概要 {#database-time-and-sql-execution-time-overview} -データベース時間メトリックは、TiDB が 1 秒あたりに SQL を処理するレイテンシーの合計であり、これは TiDB が 1 秒あたりにアプリケーションの SQL 要求を同時に処理する合計時間でもあります (アクティブな接続の数に等しい)。 +データベース時間メトリックは、TiDB が 1秒あたりに SQL を処理するレイテンシーの合計であり、これは TiDB が 1秒あたりにアプリケーションの SQL 要求を同時に処理する合計時間でもあります (アクティブな接続の数に等しい)。 パフォーマンス概要ダッシュボードには、以下の3つの積み上げ面グラフが表示されます。これらのグラフは、データベースのワークロードプロファイルを把握し、SQL実行中のステートメント、SQLフェーズ、TiKVまたはPDリクエストタイプの観点からボトルネックの原因を迅速に特定するのに役立ちます。 @@ -141,11 +141,11 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 #### 1秒あたりのクエリ数、1秒あたりのコマンド数、プリペアドプランキャッシュ {#query-per-second-command-per-second-and-prepared-plan-cache} -パフォーマンス概要の次の 3 つのパネルを確認することで、アプリケーションのワークロード タイプ、アプリケーションが TiDB と対話する方法、アプリケーションが TiDB [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を最大限に活用しているかどうかを知ることができます。 +パフォーマンス概要の次の3つのパネルを確認することで、アプリケーションのワークロード タイプ、アプリケーションが TiDB と対話する方法、アプリケーションが TiDB [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を最大限に活用しているかどうかを知ることができます。 - QPS: Query Per Second（1秒あたりのクエリ数）の略。アプリケーションによって実行されたSQL文の数を示します。 - CPSタイプ別：Command Per Secondの略。コマンドはMySQLプロトコル固有のコマンドを示します。クエリ文は、クエリコマンドまたはプリペアドステートメントのいずれかによってTiDBに送信できます。 -- Queries Using Plan Cache OPS: `avg-hit` 、TiDB クラスターで 1 秒あたりに実行計画 キャッシュを使用するクエリの数であり、 `avg-miss` 、TiDB クラスターで 1 秒あたりに実行計画 キャッシュを使用しないクエリの数です。 +- Queries Using Plan Cache OPS: `avg-hit` 、TiDB クラスターで 1秒あたりに実行計画 キャッシュを使用するクエリの数であり、 `avg-miss` 、TiDB クラスターで 1秒あたりに実行計画 キャッシュを使用しないクエリの数です。 `avg-hit + avg-miss`は`StmtExecute`に等しく、これは1秒あたりに実行される全クエリ数です。TiDBでプリペアドプランキャッシュを有効にすると、以下の3つのシナリオが発生します。 @@ -158,7 +158,7 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 **例1: TPC-Cワークロード** -TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。合計 QPS は 1 秒あたり`StmtExecute`コマンドの数に等しく、後者は Queries Using Plan Cache OPS パネルでほぼ`avg-hit`に等しくなります。理想的には、クライアントはプリペアドステートメントのオブジェクトをキャッシュします。これにより、SQL ステートメントの実行時にキャッシュされたステートメントが直接呼び出されます。すべての SQL 実行はプリペアドプランキャッシュにヒットするため、実行計画を生成するために再コンパイルする必要はありません。 +TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。合計 QPS は 1秒あたり`StmtExecute`コマンドの数に等しく、後者は Queries Using Plan Cache OPS パネルでほぼ`avg-hit`に等しくなります。理想的には、クライアントはプリペアドステートメントのオブジェクトをキャッシュします。これにより、SQL ステートメントの実行時にキャッシュされたステートメントが直接呼び出されます。すべての SQL 実行はプリペアドプランキャッシュにヒットするため、実行計画を生成するために再コンパイルする必要はありません。 ![TPC-C](/media/performance/tpcc_qps.png) @@ -176,7 +176,7 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 `StmtPrepare`回 = `StmtExecute`回 = `StmtClose`回 ~= `StmtFetch`回。アプリケーションは準備 > 実行 > フェッチ > クローズのループを使用します。プリペアドステートメントオブジェクトのリークを防ぐため、多くのアプリケーションフレームワークは`execute`フェーズの後に`close`を呼び出します。これにより、2つの問題が発生します。 -- SQL 実行には 4 つのコマンドと 4 回のネットワーク ラウンドトリップが必要です。 +- SQL 実行には 4つのコマンドと 4回のネットワーク ラウンドトリップが必要です。 - Queries Using Plan Cache OPSは0で、プリペアドプランキャッシュのヒットがゼロであることを示しています。`StmtClose`のコマンドはデフォルトでキャッシュされた実行計画をクリアし、次の`StmtPrepare`コマンドで実行計画を再度生成する必要があります。 > **Note:** @@ -187,19 +187,19 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 **例4: プリペアドステートメントにリソースリークがある** -1 秒あたり`StmtPrepare`コマンドの数は 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、これはアプリケーションにプリペアドステートメントのオブジェクト リークがあることを示しています。 +1秒あたり`StmtPrepare`コマンドの数は 1秒あたり`StmtClose`コマンドの数よりはるかに多く、これはアプリケーションにプリペアドステートメントのオブジェクト リークがあることを示しています。 ![OLTP-Query](/media/performance/prepared_statement_leaking.png) - QPSパネルでは、赤い太線が失敗したクエリの数を示し、右側のY軸がその数値の座標値を示しています。この例では、1秒あたりの失敗したクエリの数は74.6です。 -- CPS By Type パネルでは、1 秒あたり`StmtPrepare`コマンドの数が 1 秒あたり`StmtClose`コマンドの数よりはるかに多く、プリペアドステートメントのアプリケーションでオブジェクト リークが発生していることを示しています。 +- CPS By Type パネルでは、1秒あたり`StmtPrepare`コマンドの数が 1秒あたり`StmtClose`コマンドの数よりはるかに多く、プリペアドステートメントのアプリケーションでオブジェクト リークが発生していることを示しています。 - Queries Using Plan Cache OPS パネルでは、 `avg-miss`がタイプ別 CPS パネルの`StmtExecute`とほぼ等しく、ほとんどすべての SQL 実行で実行計画 キャッシュが失われていることを示しています。 #### KV/TSO 要求 OPS とソース別の KV 要求時間 {#kv-tso-request-ops-and-kv-request-time-by-source} - KV/TSOリクエストOPSパネルでは、1秒あたりのKVおよびTSOリクエストの統計情報を確認できます。統計情報のうち、 `kv request total` TiDBからTiKVへのすべてのリクエストの合計を表します。TiDBからPDおよびTiKVへのリクエストの種類を観察することで、クラスター内のワークロードプロファイルを把握できます。 - KV リクエスト時間 (ソース別) パネルでは、各 KV リクエスト タイプとすべてのリクエスト ソースの時間比率を表示できます。 - - kv 要求合計時間: 1 秒あたりの KV およびTiFlash要求の処理時間の合計。 + - kv 要求合計時間: 1秒あたりの KV およびTiFlash要求の処理時間の合計。 - 各 KV リクエストと対応するリクエスト ソースは積み上げ棒グラフを形成し、 `external`通常のビジネス リクエストを識別し、 `internal`内部アクティビティ リクエスト (DDL やauto analyzeリクエストなど) を識別します。 **例1: 忙しい作業負荷** @@ -217,7 +217,7 @@ TPC-C ワークロードは主に`UPDATE` 、 `SELECT` 、 `INSERT`文です。 このワークロードでは、クラスター内で実行されているステートメントは`ANALYZE`だけです。 -- 1 秒あたりの KV リクエストの合計数は 35.5 で、1 秒あたりの Cop リクエストの数は 9.3 です。 +- 1秒あたりの KV リクエストの合計数は 35.5 で、1秒あたりの Cop リクエストの数は 9.3 です。 - KV 処理時間のほとんどは`Cop-internal_stats`に費やされており、最も時間のかかる KV 要求は内部`ANALYZE`操作のうちの`Cop`であることを示しています。 #### CPUとメモリの使用量 {#cpu-and-memory-usage} @@ -366,7 +366,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル TiDB では、クエリ ステートメントの送信から結果の返送までに[典型的な処理フロー](/sql-optimization-concepts.md)かかります。 -TiDB での SQL 処理は、 `get token` 、 `parse` 、 `compile` 、 `execute` 4 つのフェーズで構成されます。 +TiDB での SQL 処理は、 `get token` 、 `parse` 、 `compile` 、 `execute` 4つのフェーズで構成されます。 - `get token` : 通常は数マイクロ秒程度で無視できます。トークンは、単一のTiDBインスタンスへの接続数が[トークン制限](/tidb-configuration-file.md)上限に達した場合にのみ制限されます。 - `parse` : クエリ ステートメントは抽象構文ツリー (AST) に解析されます。 @@ -398,7 +398,7 @@ avg Query Duration = avg Get Token + avg Parse Duration + avg Compile Duration + #### KVおよびTSOリクエスト期間 {#kv-and-tso-request-duration} -TiDB はフェーズ`execute`で PD および TiKV と連携します。次の図に示すように、SQL 要求を処理する際、TiDB はフェーズ`parse`および`compile`入る前に TSO を要求します。PD クライアントは呼び出し元をブロックせず、 `TSFuture`を返し、バックグラウンドで非同期的に TSO 要求を送受信します。PD クライアントは TSO 要求の処理を完了すると、 `TSFuture`を返します。 `TSFuture`の所有者は、最後の TSO を取得するために Wait メソッドを呼び出す必要があります。TiDB はフェーズ`parse`および`compile`を完了するとフェーズ`execute`に入り、このフェーズでは次の 2 つの状況が発生する可能性があります。 +TiDB はフェーズ`execute`で PD および TiKV と連携します。次の図に示すように、SQL 要求を処理する際、TiDB はフェーズ`parse`および`compile`入る前に TSO を要求します。PD クライアントは呼び出し元をブロックせず、 `TSFuture`を返し、バックグラウンドで非同期的に TSO 要求を送受信します。PD クライアントは TSO 要求の処理を完了すると、 `TSFuture`を返します。 `TSFuture`の所有者は、最後の TSO を取得するために Wait メソッドを呼び出す必要があります。TiDB はフェーズ`parse`および`compile`を完了するとフェーズ`execute`に入り、このフェーズでは次の2つの状況が発生する可能性があります。 - TSO要求が完了した場合、Waitメソッドは利用可能なTSOまたはエラーを直ちに返します。 - TSO 要求がまだ完了していない場合、TSO が利用可能になるかエラーが表示されるまで (gRPC 要求は送信されたが結果が返されず、ネットワークレイテンシーが高くなる)、Wait メソッドはブロックされます。 @@ -410,7 +410,7 @@ TSO待機時間は`TSO WAIT`と記録され、TSO要求のネットワーク時 ![Execute](/media/performance/execute_phase.png) -このセクションのインジケーターは、次の 3 つのパネルに対応しています。 +このセクションのインジケーターは、次の3つのパネルに対応しています。 - 平均 TiDB KV リクエスト期間: TiDB によって測定された KV リクエストの平均レイテンシー - 平均 TiKV GRPC 期間: TiKV での gPRC メッセージの処理にかかる平均レイテンシー @@ -461,7 +461,7 @@ TiKV は次の手順で書き込み要求を処理します。 `Storage Async Write Duration`のメトリックは、書き込みリクエストがraftstoreに入った後のレイテンシーを記録します。データはリクエストごとに収集されます。 -`Storage Async Write Duration`メトリックは`Store Duration`と`Apply Duration` 2 つの部分で構成されます。次の式を使用して、書き込みリクエストのボトルネックが`Store`または`Apply`どちらのステップにあるかを判断できます。 +`Storage Async Write Duration`メトリックは`Store Duration`と`Apply Duration` 2つの部分で構成されます。次の式を使用して、書き込みリクエストのボトルネックが`Store`または`Apply`どちらのステップにあるかを判断できます。 ``` avg Storage Async Write Duration = avg Store Duration + avg Apply Duration @@ -498,7 +498,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`スレッドで実行された操作時間を記録します。`Commit Log Duration`は、 Raftログを他の TiKV ノードにコピーする時間が含まれます (raft-log の永続性を確保するため)。`Commit Log Duration`は通常、リーダー用とフォロワー用の 2 つの`Append Log Duration`操作が含まれます。`Commit Log Duration`は、通常、 `Append 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`操作が含まれます。`Commit Log Duration`は、通常、 `Append 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 86dcca0f8bb43..9888dd5916e8f 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -22,7 +22,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー 指定された時間範囲（ `ΔT` ）内のユーザー応答時間の合計を取得するには、次の数式を使用します。 -`ΔT`での合計ユーザー応答時間 = 平均 TPS (1 秒あたりのトランザクション数) x 平均ユーザー応答時間 x `ΔT` 。 +`ΔT`での合計ユーザー応答時間 = 平均 TPS (1秒あたりのトランザクション数) x 平均ユーザー応答時間 x `ΔT` 。 ![user\_response\_time](/media/performance/user_response_time_en.png) @@ -54,7 +54,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー ## パフォーマンスチューニングプロセス {#performance-tuning-process} -パフォーマンス チューニング プロセスは、次の 6 つのステップで構成されます。 +パフォーマンス チューニング プロセスは、次の6つのステップで構成されます。 1. チューニング目標を定義します。 2. パフォーマンス ベースラインを確立します。 diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index bdf265c02a327..774e0910ec9e1 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -7,7 +7,7 @@ summary: このドキュメントでは、OLTP ワークロードのパフォー TiDB は、TiDB Dashboardの[Top SQL](/dashboard/top-sql.md)と[継続的なプロファイリング](/dashboard/continuous-profiling.md)機能や、TiDB [パフォーマンス概要ダッシュボード](/grafana-performance-overview-dashboard.md)などの包括的なパフォーマンス診断および分析機能を提供します。 -このドキュメントでは、これらの機能を組み合わせて使用​​し、7 つの異なるランタイム シナリオで同じ OLTP ワークロードのパフォーマンスを分析および比較する方法について説明します。これにより、TiDB のパフォーマンスを効率的に分析および調整するのに役立つパフォーマンス チューニング プロセスが示されます。 +このドキュメントでは、これらの機能を組み合わせて使用​​し、7つの異なるランタイム シナリオで同じ OLTP ワークロードのパフォーマンスを分析および比較する方法について説明します。これにより、TiDB のパフォーマンスを効率的に分析および調整するのに役立つパフォーマンス チューニング プロセスが示されます。 > **Note:** > @@ -23,7 +23,7 @@ TiDB は、TiDB Dashboardの[Top SQL](/dashboard/top-sql.md)と[継続的なプ - 業務で使用されるSQL文：合計200文、そのうち90%がSELECT文です。これは典型的な読み取り中心のOLTPワークロードです。 - トランザクションで使用されるテーブル: 合計 60 テーブル。12 テーブルは更新操作に関連し、残りの 48 テーブルは読み取り専用です。 - アプリケーションで使用される分離レベル: `read committed` 。 -- TiDB クラスター構成: 3 つの TiDB ノードと 3 つの TiKV ノード、各ノードに 16 個の CPU が割り当てられます。 +- TiDB クラスター構成: 3つの TiDB ノードと 3つの TiKV ノード、各ノードに 16 個の CPU が割り当てられます。 - クライアントサーバー構成: 36 個の CPU。 ## シナリオ1. クエリインターフェースを使用する {#scenario-1-use-the-query-interface} @@ -167,7 +167,7 @@ QPSは24.4kから19.7kに低下しています。データベース時間の概 - SQL タイプ別のデータベース時間: `Select`ステートメント タイプが最も時間がかかり、次に`general`ステートメントが続きます。 - SQL フェーズ別のデータベース時間: フェーズ`execute`と`compile`にほとんどの時間がかかります。 - SQL 実行時間の概要: `Get` `Prewrite`および`tso wait` `Cop`ほとんどの時間がかかります。 -- タイプ別 CPS: 3 種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 +- タイプ別 CPS: 3種類のコマンド（`StmtPrepare`、`StmtExecute`、`StmtClose`）が使用されます。 - 平均QPS = 19.7k (24.4kから19.7k) - 実行計画 キャッシュにヒットしません。 @@ -188,7 +188,7 @@ TiDB の平均 CPU 使用率は 874% から 936% に増加します。 シナリオ2とは異なり、シナリオ3のアプリケーションはPrepared Statementインターフェースを有効にしていますが、それでもキャッシュにヒットしません。さらに、シナリオ2ではCPS By Typeコマンドの種類が1つ（ `Query` ）しかありませんが、シナリオ3ではコマンドの種類が3つ（ `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ）多くあります。シナリオ2と比較すると、シナリオ3はネットワークのラウンドトリップ遅延が2つ多くなっています。 -- QPS の減少に関する分析： **CPS By Type**ペインを見ると、シナリオ 2 には CPS By Type コマンドタイプが 1 つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3 つのコマンドタイプ ( `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ) が存在することがわかります。`StmtPrepare`と`StmtClose`は QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4 分の 1 以上を占めています。 +- QPS の減少に関する分析： **CPS By Type**ペインを見ると、シナリオ 2 には CPS By Type コマンドタイプが 1つ ( `Query` ) しか存在しないのに対し、シナリオ 3 にはさらに 3つのコマンドタイプ ( `StmtPrepare` 、 `StmtExecute` 、 `StmtClose` ) が存在することがわかります。`StmtPrepare`と`StmtClose`は QPS にカウントされない非従来型コマンドであるため、QPS が減少しています。非従来型コマンドの`StmtPrepare`と`StmtClose`は`general` SQL タイプにカウントされるため、シナリオ 3 のデータベース概要には`general`時間が表示され、これはデータベース時間の 4分の 1 以上を占めています。 - 平均クエリ時間が大幅に短縮された理由の分析：シナリオ3で新たに追加されたコマンドタイプ`StmtPrepare`と`StmtClose`については、TiDB内部処理においてクエリ時間が個別に計算されます。TiDBはこれらの2種類のコマンドを非常に高速に実行するため、平均クエリ時間が大幅に短縮されます。 シナリオ3ではPrepared Statementインターフェースを使用していますが、多くのアプリケーションフレームワークはメモリリークを防ぐためにメソッド`StmtExecute`の後にメソッド`StmtClose`を呼び出すため、実行計画のキャッシュは依然としてアクセスされません。v6.0.0以降では、グローバル変数`tidb_ignore_prepared_cache_close_stmt=on;`を設定できます。その後、アプリケーションがメソッド`StmtClose`を呼び出しても、TiDBはキャッシュされた実行計画をクリアしません。そのため、次のSQL実行では既存の実行計画を再利用でき、実行計画の繰り返しコンパイルを回避できます。 @@ -249,7 +249,7 @@ PreparseStmt CPU = 25% CPU 時間 = 12.75秒 ### アプリケーション構成 {#application-configuration} -シナリオ 4 と比較して、以下に説明するように、3 つの新しい JDBC パラメータ`cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480`が構成されます。 +シナリオ 4 と比較して、以下に説明するように、3つの新しい JDBC パラメータ`cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCacheSqlLimit=20480`が構成されます。 - `cachePrepStmts = true` : クライアント側で Prepared Statement オブジェクトをキャッシュし、StmtPrepare および StmtClose の呼び出しを排除します。 - `prepStmtCacheSize` : 値は 0 より大きくなければなりません。 @@ -273,7 +273,7 @@ useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=1000&prepStmtCache #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -パフォーマンス概要ダッシュボードで最も注目すべき変更点は、 **CPS By Type**ペインの 3 つの Stmt コマンド タイプが 1 つに減り、 **Database Time by SQL Type**ペインの`general`ステートメント タイプが消え、 **QPS**ペインの QPS が 30.9k に増加したことです。 +パフォーマンス概要ダッシュボードで最も注目すべき変更点は、 **CPS By Type**ペインの 3つの Stmt コマンド タイプが 1つに減り、 **Database Time by SQL Type**ペインの`general`ステートメント タイプが消え、 **QPS**ペインの QPS が 30.9k に増加したことです。 ![performance-overview-for-1-command](/media/performance/j-5.png) @@ -301,7 +301,7 @@ TiDBの平均CPU使用率は827%から577%に低下しました。QPSが増加 ### 分析の結論 {#analysis-conclusion} -- シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2 回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 +- シナリオ 4 と比較すると、シナリオ 5 の**CPS By Type**ペインには`StmtExecute`コマンドのみがあり、これにより 2回のネットワーク ラウンド トリップが回避され、システム全体の QPS が向上します。 - QPSが増加すると、解析時間、コンパイル時間、実行時間の観点からレイテンシーは減少しますが、クエリ時間は増加します。これは、TiDBが`StmtPrepare`と`StmtClose`非常に高速に処理するため、これら2つのコマンドタイプを削除すると平均クエリ時間が増加するためです。 - SQLフェーズ別データベース時間では、 `execute`最も時間がかかり、データベース時間とほぼ一致しています。一方、SQL実行時間の概要では、 `tso wait`最も時間がかかり、 `execute`の4分の1以上がTSOの待機に費やされています。 - 1秒あたり`tso wait`回の実行時間の合計は5.46秒です。`tso wait`実行時間の平均は196マイクロ秒、1秒あたり`tso cmd`回の実行時間は28,000回で、QPSの30,900に非常に近い値です。これは、TiDBの分離レベル`read committed`の実装により、トランザクション内のすべてのSQL文がPDにTSOを要求する必要があるためです。 @@ -326,7 +326,7 @@ TiDB CPU のフレーム チャートには大きな変化はありません。 #### パフォーマンス概要ダッシュボード {#performance-overview-dashboard} -RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 `tso wait`秒あたりに消費される時間は 5.46 秒から 456 ミリ秒に減少します。 +RC 読み取りを使用した後、QPS は 30.9k から 34.9k に増加し、 `tso wait`秒あたりに消費される時間は 5.46秒から 456 ミリ秒に減少します。 ![performance-overview-1-for-rc-read](/media/performance/j-6.png) @@ -409,7 +409,7 @@ QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズ`e ## まとめ {#summary} -次の表には、7 つの異なるシナリオのパフォーマンスが示されています。 +次の表には、7つの異なるシナリオのパフォーマンスが示されています。 | メトリクス | シナリオ1 | シナリオ2 | シナリオ3 | シナリオ4 | シナリオ5 | シナリオ6 | シナリオ7 | シナリオ5とシナリオ2の比較（％） | シナリオ7とシナリオ3の比較（％） | | ----- | ----- | ------ | ----- | ----- | ----- | ----- | ----- | ----------------- | ----------------- | @@ -418,7 +418,7 @@ QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズ`e これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションがプリペアドステートメント インターフェイスを使用する理想的なシナリオです。 -- シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベスト プラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすることで、各 SQL ステートメントで実行計画 キャッシュをヒットするために必要なコマンドとデータベース操作が 1 つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加し、TiDB の平均 CPU 使用率が 936% から 577% に低下していることがわかります。 +- シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベスト プラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすることで、各 SQL ステートメントで実行計画 キャッシュをヒットするために必要なコマンドとデータベース操作が 1つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加し、TiDB の平均 CPU 使用率が 936% から 577% に低下していることがわかります。 - シナリオ 7 とシナリオ 3 を比較すると、シナリオ 5 に RC 読み取りや小さなテーブル キャッシュなどの最新の TiDB 最適化機能を追加すると、レイテンシーが41% 削減され、QPS が 108% 増加し、平均 TiDB CPU 使用率が 936% から 478% に低下することがわかります。 各シナリオのパフォーマンスを比較すると、次のような結論を導き出すことができます。 diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index deea525c5db02..b9f6e3a26f85b 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -29,7 +29,7 @@ BEGIN PESSIMISTIC; BEGIN /*T! PESSIMISTIC */; ``` -`BEGIN PESSIMISTIC;`および`BEGIN OPTIMISTIC;`ステートメントは`tidb_txn_mode`システム変数よりも優先されます。これらの 2 つのステートメントで開始されたトランザクションは、システム変数を無視し、悲観的トランザクションモードと楽観的トランザクションモードの両方をサポートします。 +`BEGIN PESSIMISTIC;`および`BEGIN OPTIMISTIC;`ステートメントは`tidb_txn_mode`システム変数よりも優先されます。これらの 2つのステートメントで開始されたトランザクションは、システム変数を無視し、悲観的トランザクションモードと楽観的トランザクションモードの両方をサポートします。 ## 動作 {#behaviors} @@ -126,7 +126,7 @@ TiDB の悲観的なトランザクションは、MySQL のトランザクショ 6. ステートメント内の`EMBEDDED SELECT`によって読み取られたデータはロックされていません。 -7. TiDB では、オープンなトランザクションはガベージコレクション(GC) をブロックしません。デフォルトでは、これにより悲観的トランザクションの最大実行時間が 1 時間に制限されます。この制限は、TiDB 設定ファイルの`max-txn-ttl`の下にある`[performance]`編集することで変更できます。 +7. TiDB では、オープンなトランザクションはガベージコレクション(GC) をブロックしません。デフォルトでは、これにより悲観的トランザクションの最大実行時間が 1時間に制限されます。この制限は、TiDB 設定ファイルの`max-txn-ttl`の下にある`[performance]`編集することで変更できます。 ## 分離レベル {#isolation-level} diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md index 84d9fb2514221..14631976abfb3 100644 --- a/placement-rules-in-sql.md +++ b/placement-rules-in-sql.md @@ -23,7 +23,7 @@ SQL の配置ルール機能を使用すると、[配置ポリシーを作成し | レベル | 説明 | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| クラスタ | デフォルトでは、TiDB はクラスターに対して 3 つのレプリカのポリシーを構成します。クラスターのグローバル配置ポリシーを構成できます。詳細については、 [クラスターのレプリカ数をグローバルに指定します](#specify-the-number-of-replicas-globally-for-a-cluster)を参照してください。 | +| クラスタ | デフォルトでは、TiDB はクラスターに対して 3つのレプリカのポリシーを構成します。クラスターのグローバル配置ポリシーを構成できます。詳細については、 [クラスターのレプリカ数をグローバルに指定します](#specify-the-number-of-replicas-globally-for-a-cluster)を参照してください。 | | データベース | 特定のデータベースの配置ポリシーを構成できます。詳細については、 [データベースのデフォルトの配置ポリシーを指定します](#specify-a-default-placement-policy-for-a-database)を参照してください。 | | テーブル | 特定のテーブルの配置ポリシーを構成できます。詳細については、[テーブルの配置ポリシーを指定します](#specify-a-placement-policy-for-a-table)を参照してください。 | | パーティション | テーブル内のさまざまな行にパーティションを作成し、パーティションの配置ポリシーを個別に構成できます。詳細については、 [パーティションテーブルの配置ポリシーを指定します](#specify-a-placement-policy-for-a-partitioned-table)を参照してください。 | @@ -183,7 +183,7 @@ SHOW PLACEMENT LABELS; ALTER PLACEMENT POLICY myplacementpolicy FOLLOWERS=4; ``` -このステートメントでは、 `FOLLOWERS=4`オプションは、データに対して 4 つの Followers と 1 Leaderを含む 5 つのレプリカを構成することを意味します。構成可能な配置オプションとその意味の詳細については、[配置オプションの参考](#placement-option-reference)を参照してください。 +このステートメントでは、 `FOLLOWERS=4`オプションは、データに対して 4つの Followers と 1 Leaderを含む 5つのレプリカを構成することを意味します。構成可能な配置オプションとその意味の詳細については、[配置オプションの参考](#placement-option-reference)を参照してください。 ### ドロップ配置ポリシー {#drop-placement-policies} @@ -210,7 +210,7 @@ DROP PLACEMENT POLICY myplacementpolicy; | `PRIMARY_REGION` | このオプションの値と一致する`region`ラベルを持つノードにRaftリーダーを配置することを指定します。 | | `REGIONS` | このオプションの値と一致する`region`ラベルを持つノードにRaft Followers を配置することを指定します。 | | `SCHEDULE` | フォロワーの配置スケジュール戦略を指定します。値のオプションは`EVEN` (デフォルト) または`MAJORITY_IN_PRIMARY`です。 | -| `FOLLOWERS` | フォロワーの数を指定します。たとえば、 `FOLLOWERS=2`データのレプリカが 3 つ（フォロワー 2 つとLeader1 つ）存在することを意味します。 | +| `FOLLOWERS` | フォロワーの数を指定します。たとえば、 `FOLLOWERS=2`データのレプリカが 3つ（フォロワー 2つとLeader1つ）存在することを意味します。 | ### 高度な配置オプション {#advanced-placement-options} @@ -232,7 +232,7 @@ DROP PLACEMENT POLICY myplacementpolicy; | 制約形式 | 説明 | | ----- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | リスト形式 | 指定する制約がすべてのレプリカに適用される場合は、キーと値のリスト形式を使用できます。各キーは`+`または`-`で始まります。例:
    • `[+region=us-east-1]`は、 `region`ラベルを持つノードに`us-east-1`としてデータを配置することを意味します。
    • `[+region=us-east-1,-type=fault]`は、 `region`という`us-east-1`ラベルを持つノードにデータを配置することを意味しますが、 `type`という`fault`ラベルは持っていません。

    | -| 辞書形式 | 異なる制約に対して異なるレプリカ数を指定する必要がある場合は、辞書形式を使用できます。例：
    • `FOLLOWER_CONSTRAINTS="{+region=us-east-1: 1,+region=us-east-2: 1,+region=us-west-1: 1}";`は、 `us-east-1`にFollowerを 1 つ、 `us-east-2`にFollowerを1 つ、 `us-west-1`にフォロワーを 1 つFollower。
    • `FOLLOWER_CONSTRAINTS='{"+region=us-east-1,+type=scale-node": 1,"+region=us-west-1": 1}';`は、 `us-east-1` `type` } `scale-node`あるノードに 1 つのフォロワーを配置し、 `us-west-1`に 1 つのFollowerを意味します。
    辞書形式は`+`または`-`で始まる各キーをサポートし、特別な`#evict-leader`属性を設定できます。たとえば、 `FOLLOWER_CONSTRAINTS='{"+region=us-east-1":1, "+region=us-east-2": 2, "+region=us-west-1,#evict-leader": 1}'`は、 `us-west-1`で選出されたリーダーが、ディザスタリカバリ中に可能な限り排除されることを意味します。 | +| 辞書形式 | 異なる制約に対して異なるレプリカ数を指定する必要がある場合は、辞書形式を使用できます。例：
    • `FOLLOWER_CONSTRAINTS="{+region=us-east-1: 1,+region=us-east-2: 1,+region=us-west-1: 1}";`は、 `us-east-1`にFollowerを 1つ、 `us-east-2`にFollowerを1つ、 `us-west-1`にフォロワーを 1つFollower。
    • `FOLLOWER_CONSTRAINTS='{"+region=us-east-1,+type=scale-node": 1,"+region=us-west-1": 1}';`は、 `us-east-1` `type` } `scale-node`あるノードに 1つのフォロワーを配置し、 `us-west-1`に 1つのFollowerを意味します。
    辞書形式は`+`または`-`で始まる各キーをサポートし、特別な`#evict-leader`属性を設定できます。たとえば、 `FOLLOWER_CONSTRAINTS='{"+region=us-east-1":1, "+region=us-east-2": 2, "+region=us-west-1,#evict-leader": 1}'`は、 `us-west-1`で選出されたリーダーが、ディザスタリカバリ中に可能な限り排除されることを意味します。 | > **Note:** > @@ -352,7 +352,7 @@ SELECT store_id,address,label from INFORMATION_SCHEMA.TIKV_STORE_STATUS; データの正確な分散方法には特にこだわらず、ディザスタリカバリ要件を満たすことを優先する場合は、 `SURVIVAL_PREFERENCES`オプションを使用して、データの生存に関する設定を指定できます。 -前述の例と同様に、TiDB クラスタは 3 つのリージョンに分散され、各リージョンには 3 つのゾーンが含まれています。このクラスタの配置ポリシーを作成する場合、 `SURVIVAL_PREFERENCES`を次のように構成することを想定します。 +前述の例と同様に、TiDB クラスタは 3つのリージョンに分散され、各リージョンには 3つのゾーンが含まれています。このクラスタの配置ポリシーを作成する場合、 `SURVIVAL_PREFERENCES`を次のように構成することを想定します。 ```sql CREATE PLACEMENT POLICY multiaz SURVIVAL_PREFERENCES="[region, zone, host]"; @@ -429,7 +429,7 @@ CREATE PLACEMENT POLICY eastandwest PRIMARY_REGION="us-east-1" REGIONS="us-east- CREATE TABLE t1 (a INT) PLACEMENT POLICY=eastandwest; ``` -- `PRIMARY_REGION`リーダーの配布地域を指定します。このオプションでは、1 つの地域のみを指定できます。 +- `PRIMARY_REGION`リーダーの配布地域を指定します。このオプションでは、1つの地域のみを指定できます。 - `SCHEDULE`オプションは、TiDB がフォロワーの分布をどのようにバランスさせるかを指定します。 - デフォルトの`EVEN`スケジューリングルールは、すべてのリージョンにわたってフォロワーが均等に分散されることを保証します。 - `PRIMARY_REGION` (つまり`us-east-1` ) に十分な数のFollowerレプリカを配置したい場合は、 `MAJORITY_IN_PRIMARY`スケジューリングルールを使用できます。このスケジューリングルールは、可用性を多少犠牲にする代わりに、トランザクションのレイテンシーを低減します。プライマリリージョンが障害を起こした場合、 `MAJORITY_IN_PRIMARY`自動フェイルオーバーを提供しません。 diff --git a/post-installation-check.md b/post-installation-check.md index 5ffa10ff372fa..083bf47040b59 100644 --- a/post-installation-check.md +++ b/post-installation-check.md @@ -51,7 +51,7 @@ tiup cluster display tidb-test mysql -u root -h ${tidb_server_host_IP_address} -P 4000 ``` -`${tidb_server_host_IP_address}` 、 `10.0.1.7`などの[クラスタトポロジファイルを初期化する](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)の場合に`tidb_servers`に設定される IP アドレスの 1 つです。 +`${tidb_server_host_IP_address}` 、 `10.0.1.7`などの[クラスタトポロジファイルを初期化する](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)の場合に`tidb_servers`に設定される IP アドレスの 1つです。 次の情報はログインが成功したことを示します。 diff --git a/predicate-push-down.md b/predicate-push-down.md index 9bdc65ec37516..062eb4bb2530a 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -1,6 +1,6 @@ --- title: Predicates Push Down -summary: TiDB のロジック最適化ルールの 1 つである述語プッシュ ダウン (PPD) を導入します。 +summary: TiDB のロジック最適化ルールの 1つである述語プッシュ ダウン (PPD) を導入します。 --- # Predicate Push Down（PPD） {#predicates-push-down-ppd} diff --git a/privilege-management.md b/privilege-management.md index c9566f27d608e..559d0b0de2ede 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -539,7 +539,7 @@ SELECT User,Host,Select_priv,Insert_priv FROM mysql.user LIMIT 1; ユーザーの識別は、接続を開始するホスト`Host`とユーザー名`User`の2つの情報に基づいています。ユーザー名が空でない場合、指定されたユーザー名と完全に一致する必要があります。 -`User` + `Host` `user`テーブルの複数の行に一致する可能性があります。このシナリオに対処するため、 `user`テーブルの行はソートされます。クライアントが接続すると、テーブルの行が 1 つずつチェックされ、最初に一致した行が検証に使用されます。ソート時には、ホストがユーザーよりも優先されます。 +`User` + `Host` `user`テーブルの複数の行に一致する可能性があります。このシナリオに対処するため、 `user`テーブルの行はソートされます。クライアントが接続すると、テーブルの行が 1つずつチェックされ、最初に一致した行が検証に使用されます。ソート時には、ホストがユーザーよりも優先されます。 ### リクエストの確認 {#request-verification} diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index 814038723e772..9fb2161a8658e 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -210,7 +210,7 @@ tiup cluster template > topology.yaml 以下の2つの一般的なシナリオでは、コマンドを実行することで推奨トポロジーテンプレートを生成できます。 -- ハイブリッド デプロイメントの場合: 複数のインスタンスが 1 台のマシンにデプロイされます。詳細は[ハイブリッド展開トポロジー](/hybrid-deployment-topology.md)を参照。 +- ハイブリッド デプロイメントの場合: 複数のインスタンスが 1台のマシンにデプロイされます。詳細は[ハイブリッド展開トポロジー](/hybrid-deployment-topology.md)を参照。 ```shell tiup cluster template --full > topology.yaml @@ -318,7 +318,7 @@ alertmanager_servers: - `v8.5.4`は、デプロイする TiDB クラスタのバージョンです。 `tiup list tidb`を実行すると、サポートされている最新バージョンを確認できます。 - `topology.yaml`は初期化設定ファイルです。 - `--user root` `root`ユーザーとしてターゲット マシンにログインし、クラスタのデプロイを完了することを示します。 `root`ユーザーは、ターゲット マシンに対して`ssh`および`sudo`の権限を持っている必要があります。あるいは、 `ssh`および`sudo`の権限を持つ他のユーザーを使用してデプロイを完了することもできます。 -- `[-i]`と`[-p]`はオプションです。ターゲット マシンへのログインをパスワードなしで設定している場合は、これらのパラメーターは不要です。そうでない場合は、2 つのパラメーターのいずれかを選択してください。 `[-i]`は、ターゲット マシンへのアクセス権を持つルート ユーザー (または`--user`で指定された他のユーザー) の秘密鍵です。 `[-p]`は、ユーザー パスワードを対話的に入力するために使用されます。 +- `[-i]`と`[-p]`はオプションです。ターゲット マシンへのログインをパスワードなしで設定している場合は、これらのパラメーターは不要です。そうでない場合は、2つのパラメーターのいずれかを選択してください。 `[-i]`は、ターゲット マシンへのアクセス権を持つルート ユーザー (または`--user`で指定された他のユーザー) の秘密鍵です。 `[-p]`は、ユーザー パスワードを対話的に入力するために使用されます。 出力ログの最後に``Deployed cluster `tidb-test` successfully``と表示されます。これは、デプロイが成功したことを示しています。 @@ -349,7 +349,7 @@ TiUP cluster v1.9.0以降、新しい起動方法としてセーフスタート > **Note:** > > - TiDBクラスタの安全な起動後、パスワードなしでrootユーザーとしてTiDBにログインすることはできません。そのため、今後のログインのために、コマンド出力に表示されるパスワードを記録しておく必要があります。 -> - パスワードは 1 回だけ生成されます。記録していない場合、または忘れた場合は、 [`root`パスワードを忘れる](/user-account-management.md#forget-the-root-password)を参照してパスワードを変更してください。 +> - パスワードは 1回だけ生成されます。記録していない場合、または忘れた場合は、 [`root`パスワードを忘れる](/user-account-management.md#forget-the-root-password)を参照してパスワードを変更してください。 方法1：セーフスタート diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index 92bb6e9006699..f0422a14fc7a3 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -73,7 +73,7 @@ tiup playground table_schema='test'; ``` - 出力からわかるように、合計 8 つのテーブルが作成され、最大のテーブルには 650 万行があります (データはランダムに生成されるため、ツールによって作成される行数は実際の SQL クエリ結果によって異なります)。 + 出力からわかるように、合計8つのテーブルが作成され、最大のテーブルには 650 万行があります (データはランダムに生成されるため、ツールによって作成される行数は実際の SQL クエリ結果によって異なります)。 ```sql +---------------+----------------+-----------+------------+-----------+ @@ -190,7 +190,7 @@ limit 10; さらに、クエリ全体の各部分をTiFlashエンジンのみを使用して計算するように指定することもできます。詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)を参照してください。 -これら 2 つの方法のクエリ結果とクエリ パフォーマンスを比較できます。 +これら2つの方法のクエリ結果とクエリ パフォーマンスを比較できます。 ## 次は何？ {#what-s-next} diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 48d8823f6bec3..4f8acccb12238 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -76,7 +76,7 @@ summary: TiUP Playgroundを使ってTiDB Self-Managedを素早く使い始める > tiup playground --tag ${tag_name} > ``` - - 最新バージョンの TiDB クラスタを、TiDB インスタンス 1 つ、TiKV インスタンス 1 つ、PD インスタンス 1 つ、 TiFlashインスタンス 1 つで起動するには、次のコマンドを実行します。 + - 最新バージョンの TiDB クラスタを、TiDB インスタンス 1つ、TiKV インスタンス 1つ、PD インスタンス 1つ、 TiFlashインスタンス 1つで起動するには、次のコマンドを実行します。 ```shell tiup playground @@ -190,7 +190,7 @@ summary: TiUP Playgroundを使ってTiDB Self-Managedを素早く使い始める > tiup playground --tag ${tag_name} > ``` - - 最新バージョンの TiDB クラスタを、TiDB インスタンス 1 つ、TiKV インスタンス 1 つ、PD インスタンス 1 つ、 TiFlashインスタンス 1 つで起動するには、次のコマンドを実行します。 + - 最新バージョンの TiDB クラスタを、TiDB インスタンス 1つ、TiKV インスタンス 1つ、PD インスタンス 1つ、 TiFlashインスタンス 1つで起動するには、次のコマンドを実行します。 ```shell tiup playground diff --git a/releases/release-1.0-ga.md b/releases/release-1.0-ga.md index b624438701c97..999701369ef78 100644 --- a/releases/release-1.0-ga.md +++ b/releases/release-1.0-ga.md @@ -5,7 +5,7 @@ summary: TiDB 1.0は、MySQLとの互換性、SQLの最適化、安定性、そ # TiDB 1.0 リリースノート {#tidb-1-0-release-notes} -2017 年 10 月 16 日に、TiDB 1.0 がリリースされました。このリリースでは、MySQL との互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 +2017年 10月 16日に、TiDB 1.0 がリリースされました。このリリースでは、MySQL との互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 ## TiDB {#tidb} diff --git a/releases/release-1.0.1.md b/releases/release-1.0.1.md index e052acf66d7a3..061186e59082b 100644 --- a/releases/release-1.0.1.md +++ b/releases/release-1.0.1.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.1は2017年11月1日にリリースされました。アップ # TiDB 1.0.1 リリースノート {#tidb-1-0-1-release-notes} -2017 年 11 月 1 日に、次の更新を含む TiDB 1.0.1 がリリースされました。 +2017年 11月 1日に、次の更新を含む TiDB 1.0.1 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-1.0.2.md b/releases/release-1.0.2.md index 333b7bc884933..200879060699d 100644 --- a/releases/release-1.0.2.md +++ b/releases/release-1.0.2.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.2は2017年11月13日にリリースされました。アッ # TiDB 1.0.2 リリースノート {#tidb-1-0-2-release-notes} -2017 年 11 月 13 日に、次の更新を含む TiDB 1.0.2 がリリースされました。 +2017年 11月 13日に、次の更新を含む TiDB 1.0.2 がリリースされました。 ## TiDB {#tidb} @@ -22,7 +22,7 @@ summary: TiDB 1.0.2は2017年11月13日にリリースされました。アッ ## TiKV {#tikv} -- 1 つの領域に複数のテーブルのデータが含まれないようにテーブルを分割する機能をサポート +- 1つの領域に複数のテーブルのデータが含まれないようにテーブルを分割する機能をサポート - キーの長さを4KB以下に制限する - より正確な読み取りトラフィック統計 - コプロセッサスタックに強力な保護を実装する diff --git a/releases/release-1.0.3.md b/releases/release-1.0.3.md index d9576f3d01495..0f3dc60ee26ee 100644 --- a/releases/release-1.0.3.md +++ b/releases/release-1.0.3.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.3は2017年11月28日にリリースされました。アッ # TiDB 1.0.3 リリースノート {#tidb-1-0-3-release-notes} -2017 年 11 月 28 日に、次の更新を含む TiDB 1.0.3 がリリースされました。 +2017年 11月 28日に、次の更新を含む TiDB 1.0.3 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-1.0.4.md b/releases/release-1.0.4.md index 69512f143c523..aa7126401489f 100644 --- a/releases/release-1.0.4.md +++ b/releases/release-1.0.4.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.4は2017年12月11日にリリースされました。アッ # TiDB 1.0.4 リリースノート {#tidb-1-0-4-release-notes} -2017 年 12 月 11 日に、次の更新を含む TiDB 1.0.4 がリリースされました。 +2017年 12月 11日に、次の更新を含む TiDB 1.0.4 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-1.0.5.md b/releases/release-1.0.5.md index e715a068f85d7..f3e7e9ec4e6d6 100644 --- a/releases/release-1.0.5.md +++ b/releases/release-1.0.5.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.5は2017年12月26日にリリースされました。アッ # TiDB 1.0.5 リリースノート {#tidb-1-0-5-release-notes} -2017 年 12 月 26 日に、次の更新を含む TiDB 1.0.5 がリリースされました。 +2017年 12月 26日に、次の更新を含む TiDB 1.0.5 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-1.0.6.md b/releases/release-1.0.6.md index 4f02a7c9c93e3..1872bb7094447 100644 --- a/releases/release-1.0.6.md +++ b/releases/release-1.0.6.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.6は2018年1月8日にリリースされました。更新内 # TiDB 1.0.6 リリースノート {#tidb-1-0-6-release-notes} -2018 年 1 月 8 日に、次の更新を含む TiDB 1.0.6 がリリースされました。 +2018年 1月 8日に、次の更新を含む TiDB 1.0.6 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-1.0.7.md b/releases/release-1.0.7.md index e49e128689a60..6aa210dd8a24a 100644 --- a/releases/release-1.0.7.md +++ b/releases/release-1.0.7.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.7がリリースされました。コマンドの最適化、 # TiDB 1.0.7 リリースノート {#tidb-1-0-7-release-notes} -2018 年 1 月 22 日に、次の更新を含む TiDB 1.0.7 がリリースされました。 +2018年 1月 22日に、次の更新を含む TiDB 1.0.7 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-1.0.8.md b/releases/release-1.0.8.md index 18250d1638388..ded93aa3fb122 100644 --- a/releases/release-1.0.8.md +++ b/releases/release-1.0.8.md @@ -5,7 +5,7 @@ summary: TiDB 1.0.8がリリースされました。このアップデートに # TiDB 1.0.8 リリースノート {#tidb-1-0-8-release-notes} -2018 年 2 月 11 日に、次の更新を含む TiDB 1.0.8 がリリースされました。 +2018年 2月 11日に、次の更新を含む TiDB 1.0.8 がリリースされました。 ## TiDB {#tidb} diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 56f6ac94eb278..3f86f4f81659b 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -5,7 +5,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの # TiDB 2.0 リリースノート {#tidb-2-0-release-notes} -2018 年 4 月 27 日に、TiDB 2.0 GA がリリースされました。TiDB 1.0 と比較して、このリリースでは、MySQL 互換性、SQL オプティマイザー、エグゼキューター、安定性が大幅に向上しています。 +2018年 4月 27日に、TiDB 2.0 GA がリリースされました。TiDB 1.0 と比較して、このリリースでは、MySQL 互換性、SQL オプティマイザー、エグゼキューター、安定性が大幅に向上しています。 ## TiDB {#tidb} diff --git a/releases/release-2.0.6.md b/releases/release-2.0.6.md index 8e5ca5952fd99..8f99870572929 100644 --- a/releases/release-2.0.6.md +++ b/releases/release-2.0.6.md @@ -17,7 +17,7 @@ summary: TiDB 2.0.6は、システムの互換性と安定性の向上を伴い - 実行効率を向上させるために、 `Index Join`の外部テーブルとして推定行数が少ないテーブルを選択します[＃7277](https://github.com/pingcap/tidb/pull/7277) - `ANALYZE TABLE`の実行中に発生したパニックに対する回復メカニズムを追加し、統計収集するプロセスでの異常な動作によって tidb サーバーが利用できなくなることを回避します。 [＃7228](https://github.com/pingcap/tidb/pull/7228) - `RPAD`と`LPAD`の結果が`max_allowed_packet`システム変数の値を超えた場合、 `NULL`と対応する警告を返し、MySQL と互換性があります [＃7244](https://github.com/pingcap/tidb/pull/7244) - - `PREPARE`文のプレースホルダ数の上限を 65535 に設定し、MySQL と互換性を持たせます。 [＃7250](https://github.com/pingcap/tidb/pull/7250) + - `PREPARE`文のプレースホルダ数の上限を65535に設定し、MySQL と互換性を持たせます。 [＃7250](https://github.com/pingcap/tidb/pull/7250) - バグ修正 - `DROP USER`文が場合によっては MySQL の動作と互換性がない問題を修正[＃7014](https://github.com/pingcap/tidb/pull/7014) - `INSERT` / `LOAD DATA`のような文が`tidb_batch_insert` を有効にした後にOOMに遭遇する問題を修正しました [＃7092](https://github.com/pingcap/tidb/pull/7092) diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 4b58fb00ab445..833884af1a36c 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -5,7 +5,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ # TiDB 2.1 ベータ版リリースノート {#tidb-2-1-beta-release-notes} -2018 年 6 月 29 日に、TiDB 2.1 ベータ版がリリースされました。TiDB 2.0 と比較して、このリリースでは安定性、SQL オプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018年 6月 29日に、TiDB 2.1 ベータ版がリリースされました。TiDB 2.0 と比較して、このリリースでは安定性、SQL オプティマイザー、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index 8301d469537e2..278c3a5103cf6 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1 GA Release Notes -summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性、パフォーマンス、互換性、および使いやすさが大幅に向上しました。このリリースには、SQL オプティマイザー、SQL エグゼキューター、統計、式、サーバー、DDL、互換性、Placement Driver(PD)、TiKV、およびツールの最適化が含まれています。また、高速なフルデータ インポートを実現するTiDB Lightningが導入されています。ただし、TiDB 2.1 では、新しいストレージエンジンの採用により、v2.0.x 以前へのダウングレードはサポートされていません。さらに、TiDB 2.1 では並列 DDL が有効になっているため、バージョン 2.0.1 より前の TiDB を使用しているクラスターは、ローリング アップデートを使用して 2.1 にアップグレードできません。TiDB 2.0.6 以前から TiDB 2.1 にアップグレードする場合、進行中の DDL 操作によってアップグレード プロセスが遅くなる可能性があります。 +summary: TiDB 2.1 GA は 2018年 11月 30日にリリースされ、安定性、パフォーマンス、互換性、および使いやすさが大幅に向上しました。このリリースには、SQL オプティマイザー、SQL エグゼキューター、統計、式、サーバー、DDL、互換性、Placement Driver(PD)、TiKV、およびツールの最適化が含まれています。また、高速なフルデータ インポートを実現するTiDB Lightningが導入されています。ただし、TiDB 2.1 では、新しいストレージエンジンの採用により、v2.0.x 以前へのダウングレードはサポートされていません。さらに、TiDB 2.1 では並列 DDL が有効になっているため、バージョン 2.0.1 より前の TiDB を使用しているクラスターは、ローリング アップデートを使用して 2.1 にアップグレードできません。TiDB 2.0.6 以前から TiDB 2.1 にアップグレードする場合、進行中の DDL 操作によってアップグレード プロセスが遅くなる可能性があります。 --- # TiDB 2.1 GA リリースノート {#tidb-2-1-ga-release-notes} diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index 94a42c3f4ac58..a05deae0c2c8b 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -5,7 +5,7 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL # TiDB 2.1 RC1 リリースノート {#tidb-2-1-rc1-release-notes} -2018 年 8 月 24 日に、TiDB 2.1 RC1 がリリースされました。TiDB 2.1 ベータ版と比較して、このリリースでは安定性、SQL オプティマイザー、統計情報、実行エンジンが大幅に改善されています。 +2018年 8月 24日に、TiDB 2.1 RC1 がリリースされました。TiDB 2.1 ベータ版と比較して、このリリースでは安定性、SQL オプティマイザー、統計情報、実行エンジンが大幅に改善されています。 ## TiDB {#tidb} diff --git a/releases/release-2.1-rc.2.md b/releases/release-2.1-rc.2.md index 063e3e5616da0..5f12a8d66623f 100644 --- a/releases/release-2.1-rc.2.md +++ b/releases/release-2.1-rc.2.md @@ -27,7 +27,7 @@ summary: TiDB 2.1 RC2は2018年9月14日にリリースされ、安定性、SQL - 自動分析作業で統計を繰り返し分析する問題を修正 [＃7550](https://github.com/pingcap/tidb/pull/7550) - 統計情報に変更がない場合に発生する統計情報更新エラーを修正[＃7530](https://github.com/pingcap/tidb/pull/7530) - `Analyze`リクエストを構築するときはRC分離レベルと低い優先度を使用する [＃7496](https://github.com/pingcap/tidb/pull/7496) - - 1 日の特定の期間の統計を自動分析できるようにするサポート[＃7570](https://github.com/pingcap/tidb/pull/7570) + - 1日の特定の期間の統計を自動分析できるようにするサポート[＃7570](https://github.com/pingcap/tidb/pull/7570) - 統計情報のログ記録時に発生するpanic問題を修正[＃7588](https://github.com/pingcap/tidb/pull/7588) - `ANALYZE TABLE WITH BUCKETS`文を使用してヒストグラム内のバケット数の設定をサポートします [＃7619](https://github.com/pingcap/tidb/pull/7619) - 空のヒストグラムを更新するときにpanic問題を修正[＃7640](https://github.com/pingcap/tidb/pull/7640) diff --git a/releases/release-2.1.16.md b/releases/release-2.1.16.md index 2b37f5d4e986a..1817088bc7c5c 100644 --- a/releases/release-2.1.16.md +++ b/releases/release-2.1.16.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 2.1.16 - `INTERVAL`が負の場合に`DATE_ADD`関数が間違った結果を返す問題を修正しました [＃11616](https://github.com/pingcap/tidb/pull/11616) - `DATE_ADD`関数が`FLOAT` 、 `DOUBLE` 、または`DECIMAL`型の引数を受け入れるときに型変換を誤って実行するため、誤った結果が返される可能性がある問題を修正しました[＃11628](https://github.com/pingcap/tidb/pull/11628) - CAST(JSON AS SIGNED)がオーバーフローしたときにエラーメッセージが不正確になる問題を修正しました [＃11562](https://github.com/pingcap/tidb/pull/11562) - - 1 つの子ノードが閉じられず、Executor を閉じる処理中にエラーが返された場合に、他の子ノードが閉じられない問題を修正しました。 [＃11598](https://github.com/pingcap/tidb/pull/11598) + - 1つの子ノードが閉じられず、Executor を閉じる処理中にエラーが返された場合に、他の子ノードが閉じられない問題を修正しました。 [＃11598](https://github.com/pingcap/tidb/pull/11598) - タイムアウトまでにリージョン分散のスケジュールが完了していない場合に、エラーではなく、正常に分割されたリージョンの数と完了したパーセンテージを返す`SPLIT TABLE`ステートメントをサポートします。 [＃11487](https://github.com/pingcap/tidb/pull/11487) - MySQL との互換性を保つために、 `REGEXP BINARY`関数で大文字と小文字を区別する [＃11505](https://github.com/pingcap/tidb/pull/11505) - `DATE_ADD` / `DATE_SUB`の結果の`YEAR`の値が 0 より小さいかより大きい場合にオーバーフローするため、 `NULL`が正しく返されない問題を修正しました。 [＃11477](https://github.com/pingcap/tidb/pull/11477) diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index 073dee302e6fa..66b7b6b857fb5 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -53,7 +53,7 @@ TiDB Ansible バージョン: 2.1.17 - `tikvSnapshot`にリバーススキャンインターフェースを追加し、DDL履歴ジョブを効率的にクエリできるようにします。このインターフェースを使用することで、 `ADMIN SHOW DDL JOBS`実行時間が大幅に短縮されます[＃11789](https://github.com/pingcap/tidb/pull/11789) - `CREATE TABLE ... PRE_SPLIT_REGION`構文の改善: `PRE_SPLIT_REGION = N` の場合、事前分割されるリージョンの数を 2^(N-1) から 2^N に変更します。 [＃11797](https://github.com/pingcap/tidb/pull/11797/files) - オンラインワークロードに大きな影響を与えないように、 `Add Index`操作のバックグラウンドワーカースレッドのデフォルトパラメータ値を減らします[＃11875](https://github.com/pingcap/tidb/pull/11875) - - `SPLIT TABLE`構文の動作を改善します。`SPLIT TABLE ... REGIONS N`を使用して領域を分割すると、N 個のデータリージョンと 1 つのインデックスリージョンが生成されます。 [＃11929](https://github.com/pingcap/tidb/pull/11929) + - `SPLIT TABLE`構文の動作を改善します。`SPLIT TABLE ... REGIONS N`を使用して領域を分割すると、N 個のデータリージョンと 1つのインデックスリージョンが生成されます。 [＃11929](https://github.com/pingcap/tidb/pull/11929) - 設定ファイルに`split-region-max-num`パラメータ（デフォルトでは`10000` ）を追加して、 `SPLIT TABLE`構文で許可されるリージョンの最大数を調整可能にします[＃12080](https://github.com/pingcap/tidb/pull/12080) - システムがbinlog書き込むときに、この句のコメントが解除された`PRE_SPLIT_REGIONS`原因で、下流のMySQLで`CREATE TABLE`句を解析できない問題を修正しました。 [＃12121](https://github.com/pingcap/tidb/pull/12121) - `SHOW TABLE … REGIONS`と`SHOW TABLE .. INDEX … REGIONS`の`WHERE` のサブ条項を追加する [＃12124](https://github.com/pingcap/tidb/pull/12124) diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 7b56fea2dcb53..470e991b2cef0 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -69,7 +69,7 @@ TiDB Ansible バージョン: 2.1.18 ## TiDB Ansible {#tidb-ansible} -- TiDB Binlog に「キューサイズ」と「クエリヒストグラム」の 2 つの監視項目を追加します。 [＃952](https://github.com/pingcap/tidb-ansible/pull/952) +- TiDB Binlog に「キューサイズ」と「クエリヒストグラム」の 2つの監視項目を追加します。 [＃952](https://github.com/pingcap/tidb-ansible/pull/952) - TiDBアラートルールを更新 [＃961](https://github.com/pingcap/tidb-ansible/pull/961) - 展開およびアップグレードの前に構成ファイルを確認する[＃973](https://github.com/pingcap/tidb-ansible/pull/973) - TiDB のインデックス速度を監視するための新しいメトリックを追加します [＃987](https://github.com/pingcap/tidb-ansible/pull/987) diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index ffb5824f5122e..736b5160f90f1 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`ステートメントにサブクエリとストアされた生成列の両方が含まれている場合に結果が正しくない問題を修正しました。`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-2.1.7.md b/releases/release-2.1.7.md index 1070335daa644..e0149ef71036c 100644 --- a/releases/release-2.1.7.md +++ b/releases/release-2.1.7.md @@ -38,4 +38,4 @@ TiDB Ansible バージョン: 2.1.7 ## TiDB Ansible {#tidb-ansible} -Prometheus 監視データのデフォルトの保持期間を 30 日に変更します +Prometheus 監視データのデフォルトの保持期間を 30日に変更します diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 6058781e78d1b..3c1ccec2bdb18 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -130,7 +130,7 @@ TiDB Ansible バージョン: 3.0.0 - リージョンの結合方向を制御するには`enable-two-way-merge`追加します - ホットリージョンのスケジュールレートを制御するには`hot-region-schedule-limit`追加します - 複数のしきい値を連続して超える場合は、ホットスポットを識別するために`hot-region-cache-hits-threshold`追加します。 - - 1 分あたりに許可されるバランスリージョンオペレータの最大数を制御するための`store-balance-rate`構成項目を追加します。 + - 1分あたりに許可されるバランスリージョンオペレータの最大数を制御するための`store-balance-rate`構成項目を追加します。 - スケジューラの最適化 - 各ストアのオペレーターの速度を個別に制御するためのストア制限メカニズムを追加します。 - 異なるスケジューラ間のリソース競合を最適化するために`waitingOperator`キューをサポートします。 diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md index 93063a83e75d9..66d919a35181c 100644 --- a/releases/release-3.0.0-rc.2.md +++ b/releases/release-3.0.0-rc.2.md @@ -120,5 +120,5 @@ TiDB Ansible バージョン: 3.0.0-rc.2 - シャードデータベースとテーブルのマージをサポート[＃95](https://github.com/pingcap/tidb-lightning/pull/95) - KV書き込み失敗再試行メカニズムを追加 [＃176](https://github.com/pingcap/tidb-lightning/pull/176) - - デフォルト値`table-concurrency`を6 に更新 [＃175](https://github.com/pingcap/tidb-lightning/pull/175) + - デフォルト値`table-concurrency`を6に更新 [＃175](https://github.com/pingcap/tidb-lightning/pull/175) - `tidb.pd-addr`と`tidb.port`提供されていない場合は自動的に検出して必要な構成項目を削減します[＃173](https://github.com/pingcap/tidb-lightning/pull/173) diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index 4544865f18399..7fe961a8043de 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -61,7 +61,7 @@ TiDB Ansible バージョン: 3.0.0-rc.3 - 一方向のマージのみを許可するには、 `enable-two-way-merge`構成項目を追加します[＃1583](https://github.com/pingcap/pd/pull/1583) - `AddLightLearner`と`AddLightPeer`スケジューリング操作を追加して、 リージョン Scatterスケジューリングを制限メカニズムによって制限されないようにします。 [＃1563](https://github.com/pingcap/pd/pull/1563) -- システムの起動時にデータのレプリカレプリケーションが 1 つしか存在しないため信頼性が不十分になる問題を修正しました[＃1581](https://github.com/pingcap/pd/pull/1581) +- システムの起動時にデータのレプリカレプリケーションが 1つしか存在しないため信頼性が不十分になる問題を修正しました[＃1581](https://github.com/pingcap/pd/pull/1581) - 構成チェックロジックを最適化して構成項目エラーを回避する[＃1585](https://github.com/pingcap/pd/pull/1585) - `store-balance-rate`構成の定義を、1分あたりに生成されるバランスオペレータ数の上限に調整します。 [＃1591](https://github.com/pingcap/pd/pull/1591) - ストアがスケジュールされた操作を生成できない可能性がある問題を修正[＃1590](https://github.com/pingcap/pd/pull/1590) diff --git a/releases/release-3.0.13.md b/releases/release-3.0.13.md index 8d248533abe40..8f6ef4754beb7 100644 --- a/releases/release-3.0.13.md +++ b/releases/release-3.0.13.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.13 Release Notes -summary: TiDB 3.0.13 は 2020 年 4 月 22 日にリリースされました。バグ修正には、INSERT ... ON DUPLICATE KEY UPDATE` ステートメントの問題の解決と、TiKV の `リージョン Merge` 中にシステムが停止して使用できなくなる問題の修正が含まれています。 +summary: TiDB 3.0.13 は 2020年 4月 22日にリリースされました。バグ修正には、INSERT ... ON DUPLICATE KEY UPDATE` ステートメントの問題の解決と、TiKV の `リージョン Merge` 中にシステムが停止して使用できなくなる問題の修正が含まれています。 --- # TiDB 3.0.13 リリースノート {#tidb-3-0-13-release-notes} diff --git a/releases/release-3.0.17.md b/releases/release-3.0.17.md index 01370a1f02cb6..e663836011a56 100644 --- a/releases/release-3.0.17.md +++ b/releases/release-3.0.17.md @@ -14,7 +14,7 @@ TiDB バージョン: 3.0.17 - TiDB - `query-feedback-limit`構成項目のデフォルト値を1024から512に減らし、統計フィードバックメカニズムを改善してクラスタへの影響を軽減します。 [＃18770](https://github.com/pingcap/tidb/pull/18770) - - 1 回のリクエストのバッチ分割数を制限する[＃18694](https://github.com/pingcap/tidb/pull/18694) + - 1回のリクエストのバッチ分割数を制限する[＃18694](https://github.com/pingcap/tidb/pull/18694) - TiDB クラスタに多くの履歴 DDL ジョブがある場合に`/tiflash/replica` HTTP API を高速化する [＃18386](https://github.com/pingcap/tidb/pull/18386) - インデックスの等価条件行数推定の改善 [＃17609](https://github.com/pingcap/tidb/pull/17609) - `kill tidb conn_id` の実行を高速化する [＃18506](https://github.com/pingcap/tidb/pull/18506) diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index bab21f04a1f74..4961d87ceda8e 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -76,7 +76,7 @@ TiDB Ansible バージョン: 3.0.2 - 長さがゼロの非文字列列をインデックスするときにエラーが発生する問題を修正[＃11214](https://github.com/pingcap/tidb/pull/11214) - 外部キー制約とフルテキストインデックスを持つ列の変更を禁止します（注：TiDBは、構文で外部キー制約とフルテキストインデックスを引き続きサポートしています） [＃11274](https://github.com/pingcap/tidb/pull/11274) - `ALTER TABLE`文で変更された位置と列のデフォルト値が同時に使用されるため、列のインデックスオフセットが間違っている可能性がある問題を修正しました[＃11346](https://github.com/pingcap/tidb/pull/11346) - - JSON ファイルの解析時に発生する 2 つの問題を修正しました。 + - JSON ファイルの解析時に発生する 2つの問題を修正しました。 - `int64`は`ConvertJSONToFloat`の`uint64`の中間解析結果として使用され、精度オーバーフローエラーが発生します。 [＃11433](https://github.com/pingcap/tidb/pull/11433) - `int64`は`ConvertJSONToInt`の`uint64`の中間解析結果として使用され、精度オーバーフローエラーが発生します。 [＃11551](https://github.com/pingcap/tidb/pull/11551) - AUTO_INCREMENT列のインデックスの削除を禁止して、AUTO_INCREMENT列が誤った結果を取得する可能性を回避する[＃11399](https://github.com/pingcap/tidb/pull/11399) diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 60abbb6eae57d..7acfd9af7545b 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -31,7 +31,7 @@ TiDB Ansible バージョン: 3.0.5 - 型変換に関して、 `AND`と`OR`論理式が誤った結果を返す問題を修正しました。 [＃12811](https://github.com/pingcap/tidb/pull/12811) - サーバ - 後で大規模なトランザクションをサポートするためにトランザクションTTLを変更するインターフェース関数を実装します[＃12397](https://github.com/pingcap/tidb/pull/12397) - - 悲観的トランザクションをサポートするために、必要に応じてトランザクション TTL を延長する（最大 10 分）ことをサポートします[＃12579](https://github.com/pingcap/tidb/pull/12579) + - 悲観的トランザクションをサポートするために、必要に応じてトランザクション TTL を延長する（最大 10分）ことをサポートします[＃12579](https://github.com/pingcap/tidb/pull/12579) - TiDBがスキーマの変更とそれに対応する変更されたテーブル情報をキャッシュする回数を100から1024に調整し、 `tidb_max_delta_schema_count`システム変数を使用して変更をサポートします。 [＃12502](https://github.com/pingcap/tidb/pull/12502) - `kvrpc.Cleanup`プロトコルの動作を更新して、時間外ではないトランザクションのロックをクリーンアップしないようにしました[＃12417](https://github.com/pingcap/tidb/pull/12417) - パーティションテーブル情報を`information_schema.tables`テーブルに記録するサポート [＃12631](https://github.com/pingcap/tidb/pull/12631) diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 946b658acc05d..751355affe15b 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`ステートメントにサブクエリと生成列の両方が含まれている場合に結果が正しくない問題を修正しました。`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.8.md b/releases/release-3.0.8.md index 5a7d3efb20658..eab51dd1fcc53 100644 --- a/releases/release-3.0.8.md +++ b/releases/release-3.0.8.md @@ -37,7 +37,7 @@ TiDB Ansible バージョン: 3.0.8 - サーバ - ステートメントサマリーの改善: - SQL文をより詳細に分析できるように多数のSQLメトリックフィールドを追加します[＃14151](https://github.com/pingcap/tidb/pull/14151) [＃14168](https://github.com/pingcap/tidb/pull/14168) - - `stmt-summary.refresh-interval`パラメータを追加して、古いデータを`events_statements_summary_by_digest`テーブルから`events_statements_summary_by_digest_history`テーブルに移動するかどうかを制御します (デフォルトの間隔: 30 分) [＃14161](https://github.com/pingcap/tidb/pull/14161) + - `stmt-summary.refresh-interval`パラメータを追加して、古いデータを`events_statements_summary_by_digest`テーブルから`events_statements_summary_by_digest_history`テーブルに移動するかどうかを制御します (デフォルトの間隔: 30分) [＃14161](https://github.com/pingcap/tidb/pull/14161) - `events_statements_summary_by_digest` の古いデータを保存するには、 `events_statements_summary_by_digest_history`テーブルを追加します。 [＃14166](https://github.com/pingcap/tidb/pull/14166) - RBAC関連の内部SQL文実行時にbinlogが誤って出力される問題を修正[＃13890](https://github.com/pingcap/tidb/pull/13890) - TiDBサーバーバージョン変更する機能を制御するための`server-version`構成項目を追加します [＃13906](https://github.com/pingcap/tidb/pull/13906) diff --git a/releases/release-3.0.9.md b/releases/release-3.0.9.md index 787d4aa2d1738..1bb7de4a8e602 100644 --- a/releases/release-3.0.9.md +++ b/releases/release-3.0.9.md @@ -21,7 +21,7 @@ TiDB Ansible バージョン: 3.0.9 - 集計関数を`ENUM`列とコレクション列に適用した場合の誤った結果を修正しました [＃14364](https://github.com/pingcap/tidb/pull/14364) - サーバ - システム変数`auto_increment_increment`と`auto_increment_offset`サポート[＃14396](https://github.com/pingcap/tidb/pull/14396) - - `tidb_tikvclient_ttl_lifetime_reach_total`監視メトリックを追加して、TTL が 10 分の悲観的トランザクションの数を監視します[＃14300](https://github.com/pingcap/tidb/pull/14300) + - `tidb_tikvclient_ttl_lifetime_reach_total`監視メトリックを追加して、TTL が 10分の悲観的トランザクションの数を監視します[＃14300](https://github.com/pingcap/tidb/pull/14300) - SQLクエリの実行中にpanicが発生した場合に、SQL情報をログに出力します[＃14322](https://github.com/pingcap/tidb/pull/14322) - ステートメント要約テーブルに`plan`と`plan_digest`フィールドを追加して、実行されている`plan`と`plan`署名記録します。 [＃14285](https://github.com/pingcap/tidb/pull/14285) - `stmt-summary.max-stmt-count`構成項目のデフォルト値を`100`から`200`に調整します[＃14285](https://github.com/pingcap/tidb/pull/14285) diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index bb4ce1cc79f6e..2c15803e2d8cd 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0 GA Release Notes -summary: TiDB 4.0.0 GA は 2020 年 5 月 28 日にリリースされました。このバージョンでは、大規模トランザクションのエラー メッセージが最適化され、Changefeed` 構成ファイルの使いやすさが向上し、新しい構成項目とさまざまな構文および関数のサポートが追加され、TiKV、 TiFlash、PD、およびツールの複数のバグと問題が修正され、PD の新しい監視項目とさまざまな機能のサポートが追加され、Backup & Restore (BR) と TiCDC のさまざまな問題が修正されました。 +summary: TiDB 4.0.0 GA は 2020年 5月 28日にリリースされました。このバージョンでは、大規模トランザクションのエラー メッセージが最適化され、Changefeed` 構成ファイルの使いやすさが向上し、新しい構成項目とさまざまな構文および関数のサポートが追加され、TiKV、 TiFlash、PD、およびツールの複数のバグと問題が修正され、PD の新しい監視項目とさまざまな機能のサポートが追加され、Backup & Restore (BR) と TiCDC のさまざまな問題が修正されました。 --- # TiDB 4.0 GA リリースノート {#tidb-4-0-ga-release-notes} diff --git a/releases/release-4.0.0-beta.1.md b/releases/release-4.0.0-beta.1.md index c91e6285817f4..772435cec3022 100644 --- a/releases/release-4.0.0-beta.1.md +++ b/releases/release-4.0.0-beta.1.md @@ -70,7 +70,7 @@ TiDB Ansible バージョン: 4.0.0-beta.1 - Drainer の増分バックアップ データの削除をサポート [＃885](https://github.com/pingcap/tidb-binlog/pull/885) - TiDB Ansible - - 1 つのクラスターに複数の Grafana/Prometheus/Alertmanager をデプロイすることをサポート[＃1142](https://github.com/pingcap/tidb-ansible/pull/1142) + - 1つのクラスターに複数の Grafana/Prometheus/Alertmanager をデプロイすることをサポート[＃1142](https://github.com/pingcap/tidb-ansible/pull/1142) - TiFlashの設定ファイルに`metric_port`設定項目（デフォルトでは`8234` ）を追加します。 [＃1145](https://github.com/pingcap/tidb-ansible/pull/1145) - TiFlashの設定ファイルに`flash_proxy_status_port`設定項目（デフォルトでは`20292` ）を追加します。 [＃1141](https://github.com/pingcap/tidb-ansible/pull/1141) - TiFlash監視ダッシュボードを追加する[＃1147](https://github.com/pingcap/tidb-ansible/pull/1147) [＃1151](https://github.com/pingcap/tidb-ansible/pull/1151) diff --git a/releases/release-4.0.0-rc.2.md b/releases/release-4.0.0-rc.2.md index 90f58faf44cba..ec981d1f020e5 100644 --- a/releases/release-4.0.0-rc.2.md +++ b/releases/release-4.0.0-rc.2.md @@ -33,7 +33,7 @@ TiDB バージョン: 4.0.0-rc.2 - TiDB - - `WHERE`句に同等の条件が 1 つしかない場合に間違ったパーティションが選択される問題を修正[＃17054](https://github.com/pingcap/tidb/pull/17054) + - `WHERE`句に同等の条件が 1つしかない場合に間違ったパーティションが選択される問題を修正[＃17054](https://github.com/pingcap/tidb/pull/17054) - `WHERE`句に文字列列のみが含まれている場合に誤ったインデックス範囲を構築することで誤った結果が発生する問題を修正しました。 [＃16660](https://github.com/pingcap/tidb/pull/16660) - `DELETE`操作後にトランザクション内の`PointGet`クエリを実行するときに発生するpanic問題を修正しました [＃16991](https://github.com/pingcap/tidb/pull/16991) - エラーが発生したときにGCワーカーがデッドロックに遭遇する可能性がある問題を修正しました[＃16915](https://github.com/pingcap/tidb/pull/16915) diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index fb768a0f86af2..601d1223b7a2a 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -121,7 +121,7 @@ TiDB バージョン: 4.0.11 - 一致しないメモリ診断を修正[＃9589](https://github.com/tikv/tikv/pull/9589) - 部分的なRawKV復元範囲の終了キーが含む問題を修正 [＃9583](https://github.com/tikv/tikv/pull/9583) - TiCDC の増分スキャン中にロールバックされたトランザクションのキーの古い値をロードするときに発生する TiKV panicの問題を修正しました[＃9569](https://github.com/tikv/tikv/pull/9569) - - 異なる設定の変更フィードが 1 つのリージョンに接続したときに古い値の構成の不具合を修正しました。 [＃9565](https://github.com/tikv/tikv/pull/9565) + - 異なる設定の変更フィードが 1つのリージョンに接続したときに古い値の構成の不具合を修正しました。 [＃9565](https://github.com/tikv/tikv/pull/9565) - MAC アドレスのないネットワーク インターフェースを持つマシンで TiKV クラスターを実行すると発生するクラッシュの問題を修正しました (v4.0.9 で導入) [＃9516](https://github.com/tikv/tikv/pull/9516) - 巨大なリージョンをバックアップする際のTiKV OOMの問題を修正 [＃9448](https://github.com/tikv/tikv/pull/9448) - `region-split-check-diff`カスタマイズできない問題を修正[＃9530](https://github.com/tikv/tikv/pull/9530) diff --git a/releases/release-4.0.12.md b/releases/release-4.0.12.md index b263a4f5db64b..2e730da7bedc1 100644 --- a/releases/release-4.0.12.md +++ b/releases/release-4.0.12.md @@ -27,7 +27,7 @@ TiDB バージョン: 4.0.12 - `infoschema.partitions`テーブルから`partition_id`クエリをサポート [＃22489](https://github.com/pingcap/tidb/pull/22489) - SQL文の実行計画がバインディングヒントと一致しているかどうかをユーザーが知ることができるように`last_plan_from_binding`追加します。 [＃21430](https://github.com/pingcap/tidb/pull/21430) - `pre-split`オプションなしで切り捨てられたテーブルを散布する [＃22872](https://github.com/pingcap/tidb/pull/22872) - - `str_to_date`式に 3 つの書式指定子を追加します [＃22812](https://github.com/pingcap/tidb/pull/22812) + - `str_to_date`式に 3つの書式指定子を追加します [＃22812](https://github.com/pingcap/tidb/pull/22812) - メトリクスモニターで`PREPARE`実行失敗を`Failed Query OPM`として記録する [＃22672](https://github.com/pingcap/tidb/pull/22672) - `tidb_snapshot` 設定されている場合、 `PREPARE`実行でエラーを報告しません [＃22641](https://github.com/pingcap/tidb/pull/22641) diff --git a/releases/release-4.0.16.md b/releases/release-4.0.16.md index 8d095f1f2853b..f414703ad22f4 100644 --- a/releases/release-4.0.16.md +++ b/releases/release-4.0.16.md @@ -20,7 +20,7 @@ TiDBバージョン: 4.0.16 - TiCDC - TiCDC が Kafka クラスターに大きすぎるメッセージを送信しないように、Kafka シンク`max-message-bytes`のデフォルト値を 1 MB に変更します。 [＃2962](https://github.com/pingcap/tiflow/issues/2962) - - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を 3 に変更します[＃3337](https://github.com/pingcap/tiflow/issues/3337) + - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を3に変更します[＃3337](https://github.com/pingcap/tiflow/issues/3337) ## 改善点 {#improvements} diff --git a/releases/release-4.0.4.md b/releases/release-4.0.4.md index d64cc9dca55e1..2bea2481382dc 100644 --- a/releases/release-4.0.4.md +++ b/releases/release-4.0.4.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.4 Release Notes -summary: TiDB 4.0.4 は 2020 年 7 月 31 日にリリースされました。バグ修正には、information_schema.columns` のクエリに関する問題、`PointGet` および `BatchPointGet` 演算子のエラー、`BatchPointGet` の誤った結果、`set` または `enum` 型に遭遇した `HashJoin` 演算子の誤ったクエリ結果が含まれます。 +summary: TiDB 4.0.4 は 2020年 7月 31日にリリースされました。バグ修正には、information_schema.columns` のクエリに関する問題、`PointGet` および `BatchPointGet` 演算子のエラー、`BatchPointGet` の誤った結果、`set` または `enum` 型に遭遇した `HashJoin` 演算子の誤ったクエリ結果が含まれます。 --- # TiDB 4.0.4 リリースノート {#tidb-4-0-4-release-notes} diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index bfabef2f673d2..c40a69bfcefbd 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -207,7 +207,7 @@ TiDB バージョン: 4.0.9 - スキーマストレージがTiDB テーブルをキャッシュするときに、早期 GC または更新のレイテンシー`TableInfo`によって発生するレプリケーション中断の問題を修正しました。 [＃1114](https://github.com/pingcap/tiflow/pull/1114) - DDL操作が頻繁に行われる場合にスキーマストレージのメモリ消費量が多すぎる問題を修正しました[＃1127](https://github.com/pingcap/tiflow/pull/1127) - チェンジフィードが一時停止または停止したときのゴルーチンリークを修正[＃1075](https://github.com/pingcap/tiflow/pull/1075) - - 下流の Kafka サービスまたはネットワークジッターによるレプリケーションの中断を防ぐために、Kafka プロデューサーの最大再試行タイムアウトを 600 秒に増やします。 [＃1118](https://github.com/pingcap/tiflow/pull/1118) + - 下流の Kafka サービスまたはネットワークジッターによるレプリケーションの中断を防ぐために、Kafka プロデューサーの最大再試行タイムアウトを 600秒に増やします。 [＃1118](https://github.com/pingcap/tiflow/pull/1118) - Kafka のバッチサイズが有効にならないバグを修正[＃1112](https://github.com/pingcap/tiflow/pull/1112) - TiCDC と PD 間のネットワークにジッターがあり、一時停止中の変更フィードが同時に再開されると、一部のテーブルの行の変更が失われる可能性があるバグを修正しました[＃1213](https://github.com/pingcap/tiflow/pull/1213) - TiCDCとPD間のネットワークが安定していない場合にTiCDCプロセスが終了する可能性があるバグを修正[＃1218](https://github.com/pingcap/tiflow/pull/1218) diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index ac2f66da9854f..18657c9d421fd 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -27,8 +27,8 @@ v5.0 の主な新機能または改善点は次のとおりです。 クラスター化インデックス機能を有効にすると、次の場合に TiDB のパフォーマンスが大幅に向上します (たとえば、TPC-C tpmC テストでは、クラスター化インデックスを有効にすると TiDB のパフォーマンスが 39% 向上します)。 -- データが挿入されると、クラスター化インデックスにより、ネットワークからのインデックス データの書き込みが 1 回削減されます。 -- 同等の条件を持つクエリに主キーのみが関係する場合、クラスター化インデックスにより、ネットワークからのインデックス データの読み取りが 1 回削減されます。 +- データが挿入されると、クラスター化インデックスにより、ネットワークからのインデックス データの書き込みが 1回削減されます。 +- 同等の条件を持つクエリに主キーのみが関係する場合、クラスター化インデックスにより、ネットワークからのインデックス データの読み取りが 1回削減されます。 - 範囲条件を持つクエリに主キーのみが関係する場合、クラスター化インデックスにより、ネットワークからのインデックス データの複数回の読み取りが削減されます。 - 同等条件または範囲条件を持つクエリに主キー プレフィックスが含まれる場合、クラスター化インデックスによって、ネットワークからのインデックス データの複数回の読み取りが削減されます。 @@ -54,7 +54,7 @@ v5.0 の主な新機能または改善点は次のとおりです。 `INTERSECT`演算子は集合演算子であり、2つ以上のクエリの結果セットの積集合を返します。ある意味では、 `InnerJoin`演算子の代替として機能します。 -`EXCEPT`演算子はセット演算子であり、2 つのクエリの結果セットを結合し、最初のクエリ結果にはあるが 2 番目のクエリ結果にはない要素を返します。 +`EXCEPT`演算子はセット演算子であり、2つのクエリの結果セットを結合し、最初のクエリ結果にはあるが 2 番目のクエリ結果にはない要素を返します。 - [ユーザードキュメント](/functions-and-operators/set-operators.md) - 関連号: [＃18031](https://github.com/pingcap/tidb/issues/18031) @@ -184,6 +184,6 @@ SQLパフォーマンスの問題をトラブルシューティングする際 ## 展開と保守 {#deployment-and-maintenance} - 以前は、TiDB Ansibleの設定情報がTiUPにインポートされると、 TiUPはユーザー設定を`ansible-imported-configs`ディレクトリに保存していました。その後、ユーザーが`tiup cluster edit-config`を使用して設定を編集する必要がある場合、インポートされた設定はエディターインターフェースに表示されず、ユーザーの混乱を招く可能性がありました。TiDB v5.0では、TiDB Ansibleの設定がインポートされると、 TiUPは設定情報を`ansible-imported-configs`とエディターインターフェースの両方に保存します。この改善により、ユーザーはクラスター設定を編集する際に、インポートされた設定を確認できます。 -- 複数のミラーを 1 つにマージし、ローカル ミラーにコンポーネントを公開し、ローカル ミラーにコンポーネント所有者を追加する機能をサポートする拡張`mirror`コマンド[＃814](https://github.com/pingcap/tiup/issues/814) +- 複数のミラーを 1つにマージし、ローカル ミラーにコンポーネントを公開し、ローカル ミラーにコンポーネント所有者を追加する機能をサポートする拡張`mirror`コマンド[＃814](https://github.com/pingcap/tiup/issues/814) - 大規模企業、特に金融業界では、本番環境の変更は慎重に検討されます。バージョンごとにCDを使用してインストールする必要があると、面倒な作業になる可能性があります。TiDB v5.0では、 TiUPの`merge`コマンドで複数のインストールパッケージを1つにマージできるため、インストール作業が簡素化されます。 - v4.0では、自分で構築したミラーを公開するにはtiup-serverを起動する必要があり、使い勝手が悪かったです。v5.0では、 `tiup mirror set`を使用して現在のミラーをローカルミラーに設定するだけで、自分で構築したミラーを公開できます。 diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 3c8e27761ff72..074d08b7223f5 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -201,7 +201,7 @@ TPC-H 100ベンチマークテストにおいて、 TiFlash MPPは従来の分 テーブルデータが変更されると、データベースシステムはクラスター化インデックスと非クラスター化インデックスを自動的に維持します。 -デフォルトでは、すべての主キーは非クラスター化インデックスとして作成されます。主キーをクラスター化インデックスまたは非クラスター化インデックスとして作成するには、次の 2 つの方法のいずれかを使用できます。 +デフォルトでは、すべての主キーは非クラスター化インデックスとして作成されます。主キーをクラスター化インデックスまたは非クラスター化インデックスとして作成するには、次の2つの方法のいずれかを使用できます。 - テーブルを作成する際に、ステートメント内でキーワード`CLUSTERED | NONCLUSTERED`を指定すると、システムは指定された方法でテーブルを作成します。構文は以下のとおりです。 @@ -316,7 +316,7 @@ TiDBのスケジューリングプロセスは、I/O、ネットワーク、CPU TiDBがガベージコレクション（GC）とデータ圧縮を実行する際、パーティションはCPUとI/Oリソースを消費します。これらの2つのタスクの実行中は、データが重複している状態が発生します。 -GC の CPU および I/O リソースの消費を削減するために、GC コンパクション フィルタ機能は、これら 2 つのタスクを 1 つに結合し、同じタスクで実行します。この機能はデフォルトで有効になっています。 `gc.enable-compaction-filter = false`を設定することで無効にできます。 +GC の CPU および I/O リソースの消費を削減するために、GC コンパクション フィルタ機能は、これら2つのタスクを 1つに結合し、同じタスクで実行します。この機能はデフォルトで有効になっています。 `gc.enable-compaction-filter = false`を設定することで無効にできます。 #### TiFlashは、圧縮とデータソートにおけるI/Oリソースの使用を制限します（**実験的機能**）。 {#tiflash-limits-the-compression-and-data-sorting-s-use-of-i-o-resources-experimental-feature} @@ -342,7 +342,7 @@ SQL BINDING ステートメントを使用して SQL ステートメントを手 TiDBをアップグレードする際、パフォーマンスの不安定性を回避するために、ベースラインキャプチャ機能を有効にして、システムが最新の実行計画を自動的にキャプチャしてバインドし、システムテーブルに保存するように設定できます。TiDBのアップグレード後、 `SHOW GLOBAL BINDING`コマンドを実行してバインドされた実行計画をエクスポートし、これらのプランを削除するかどうかを決定できます。 -この機能はデフォルトでは無効になっています。サーバーを変更するか、グローバルシステム変数`tidb_capture_plan_baselines` `ON`に設定することで有効にできます。この機能が有効になると、システムは`bind-info-lease`ごと (デフォルト値は`3s` )、ステートメントサマリーから少なくとも 2 回出現する SQL ステートメントを取得し、これらの SQL ステートメントを自動的にキャプチャしてバインドします。 +この機能はデフォルトでは無効になっています。サーバーを変更するか、グローバルシステム変数`tidb_capture_plan_baselines` `ON`に設定することで有効にできます。この機能が有効になると、システムは`bind-info-lease`ごと (デフォルト値は`3s` )、ステートメントサマリーから少なくとも 2回出現する SQL ステートメントを取得し、これらの SQL ステートメントを自動的にキャプチャしてバインドします。 ### TiFlashクエリの安定性を向上させる {#improve-stability-of-tiflash-queries} diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index 35bbf6eb77084..5e44d3a9080d9 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -18,7 +18,7 @@ TiDB バージョン: 5.0.6 - `cdc server`コマンドエラーの出力を stdout から stderr に変更します [＃3133](https://github.com/pingcap/tiflow/issues/3133) - Kafkaシンク`max-message-bytes`のデフォルト値を`10M` に設定する [＃3081](https://github.com/pingcap/tiflow/issues/3081) - - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を 3 に変更します[＃3337](https://github.com/pingcap/ticdc/issues/3337) + - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を3に変更します[＃3337](https://github.com/pingcap/ticdc/issues/3337) ## 改善点 {#improvements} diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index b754245c93519..f1f7238499173 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -50,7 +50,7 @@ TiDB バージョン: 5.1.0 | TiKV設定ファイル | [`old-value-cache-memory-quota`](/tikv-configuration-file.md#old-value-cache-memory-quota) | 新しく追加された | TiCDCの古い値に基づいてメモリ使用量の上限を設定します。デフォルト値は`512MB`です。 | | TiKV設定ファイル | [`sink-memory-quota`](/tikv-configuration-file.md#sink-memory-quota) | 新しく追加された | TiCDCデータ変更イベントによるメモリ使用量の上限を設定します。デフォルト値は`512MB`です。 | | TiKV設定ファイル | [`incremental-scan-threads`](/tikv-configuration-file.md#incremental-scan-threads) | 新しく追加された | 履歴データを増分的にスキャンするタスクのスレッド数を設定します。デフォルト値は`4`で、これはタスクに4つのスレッドが使用されることを意味します。 | -| TiKV設定ファイル | [`incremental-scan-concurrency`](/tikv-configuration-file.md#incremental-scan-concurrency) | 新しく追加された | 履歴データの増分スキャンを行うタスクの同時実行の最大数を設定します。デフォルト値は`6`で、これは最大で 6 つのタスクを同時に実行できることを意味します。 | +| TiKV設定ファイル | [`incremental-scan-concurrency`](/tikv-configuration-file.md#incremental-scan-concurrency) | 新しく追加された | 履歴データの増分スキャンを行うタスクの同時実行の最大数を設定します。デフォルト値は`6`で、これは最大で 6つのタスクを同時に実行できることを意味します。 | | TiKV設定ファイル | [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 変更 | 保留中の圧縮バイトのソフトリミット。デフォルト値は`"64GB"`から`"192GB"`に変更されます。 | | TiKV設定ファイル | [`storage.io-rate-limit`](/tikv-configuration-file.md#storageio-rate-limit) | 新しく追加された | TiKV書き込みのI/Oレートを制御します。 `storage.io-rate-limit.max-bytes-per-sec`のデフォルト値は`"0MB"`です。 | | TiKV設定ファイル | [`resolved-ts.enable`](/tikv-configuration-file.md#enable) | 新しく追加された | すべてのリージョンリーダーに対して`resolved-ts`を維持するかどうかを決定します。デフォルト値は`true`です。 | diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index d39669b568a75..9859c29a586fd 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -109,7 +109,7 @@ TiDB バージョン: 5.1.1 - 特定のプラットフォームで期間計算がpanicになる可能性がある問題を修正[＃10569](https://github.com/tikv/tikv/pull/10569) - Load Base Splitが誤って`batch_get_command` のエンコードされていないキーを使用する問題を修正しました [＃10542](https://github.com/tikv/tikv/issues/10542) - `resolved-ts.advance-ts-interval`構成を動的に変更してもすぐには反映されない問題を修正[＃10426](https://github.com/tikv/tikv/issues/10426) - - レプリカが 4 つ以上ある場合に稀に発生するフォロワー メタデータ破損の問題を修正[＃10225](https://github.com/tikv/tikv/issues/10225) + - レプリカが 4つ以上ある場合に稀に発生するフォロワー メタデータ破損の問題を修正[＃10225](https://github.com/tikv/tikv/issues/10225) - 暗号化が有効になっている場合にスナップショットを2回構築すると発生するpanic問題を修正[＃9786](https://github.com/tikv/tikv/issues/9786) [＃10407](https://github.com/tikv/tikv/issues/10407) - 間違った`tikv_raftstore_hibernated_peer_state`指標を修正する[＃10330](https://github.com/tikv/tikv/issues/10330) - コプロセッサの関数`json_unquote()`の間違った引数の型を修正 [＃10176](https://github.com/tikv/tikv/issues/10176) diff --git a/releases/release-5.1.3.md b/releases/release-5.1.3.md index 2b5d5b2f34ad9..d4a6dce2acc98 100644 --- a/releases/release-5.1.3.md +++ b/releases/release-5.1.3.md @@ -1,6 +1,6 @@ --- title: TiDB 5.1.3 Release Note -summary: TiDB 5.1.3 は 2021 年 12 月 3 日にリリースされました。このバージョンには TiKV のバグ修正が含まれており、複数のキーによって呼び出されたときに GcKeys` タスクが機能せず、圧縮フィルター GC で潜在的な問題が発生するという問題に対処しています。 +summary: TiDB 5.1.3 は 2021年 12月 3日にリリースされました。このバージョンには TiKV のバグ修正が含まれており、複数のキーによって呼び出されたときに GcKeys` タスクが機能せず、圧縮フィルター GC で潜在的な問題が発生するという問題に対処しています。 --- # TiDB 5.1.3 リリースノート {#tidb-5-1-3-release-note} diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index ca827b42dec0c..bb30ece4822eb 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -128,7 +128,7 @@ TiDB バージョン: 5.1.4 - データを`DECIMAL`データ型にキャストする際のオーバーフローバグを修正 - `castStringAsReal` TiFlashとTiDB/TiKVの動作が一致しない問題を修正 - TiFlash が再起動後に`EstablishMPPConnection`エラーを返す可能性がある問題を修正しました - - TiFlashレプリカの数を 0 に設定した後に古いデータを再利用できない問題を修正しました + - TiFlashレプリカの数を0に設定した後に古いデータを再利用できない問題を修正しました - `CastStringAsDecimal` TiFlashとTiDB/TiKVの動作が一致しない問題を修正 - `where `句を含むクエリが間違った結果を返す問題を修正しました - MPPクエリが停止したときにTiFlashがpanicになる可能性がある問題を修正しました diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index 73be13f244482..a37e9cb77f7ef 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -92,7 +92,7 @@ TiDB バージョン: 5.2.0 - **オプティマイザのカーディナリティ推定の精度を向上させる** - TiDBのTopN/Limit推定精度を向上させます。例えば、 `order by col limit x`条件を含む大規模テーブルに対するページネーションクエリの場合、TiDBは適切なインデックスをより容易に選択し、クエリ応答時間を短縮できます。 - - 範囲外推定の精度を向上させます。たとえば、1 日の統計情報が更新されていなくても、TiDB は`where date=Now()`を含むクエリに対して対応するインデックスを正確に選択できます。 + - 範囲外推定の精度を向上させます。たとえば、1日の統計情報が更新されていなくても、TiDB は`where date=Now()`を含むクエリに対して対応するインデックスを正確に選択できます。 - オプティマイザが Limit/TopN をプッシュダウンする動作を制御するために`tidb_opt_limit_push_down_threshold`変数を導入します。これにより、誤った推定のために一部の状況で Limit/TopN をプッシュダウンすることができないという問題が解決されます。 [ユーザー向けドキュメント](/system-variables.md#tidb_opt_limit_push_down_threshold)、 [#26085](https://github.com/pingcap/tidb/issues/26085) diff --git a/releases/release-5.2.1.md b/releases/release-5.2.1.md index 062d681892e69..fc62f38b7ac5b 100644 --- a/releases/release-5.2.1.md +++ b/releases/release-5.2.1.md @@ -1,6 +1,6 @@ --- title: TiDB 5.2.1 Release Notes -summary: TiDB 5.2.1 は 2021 年 9 月 9 日にリリースされました。バグ修正には、誤った実行計画によって発生した TiDB のエラーの解決と、リージョンの移行時にRaftstoreデッドロックによって発生する TiKV が利用できなくなる問題の修正が含まれます。 +summary: TiDB 5.2.1 は 2021年 9月 9日にリリースされました。バグ修正には、誤った実行計画によって発生した TiDB のエラーの解決と、リージョンの移行時にRaftstoreデッドロックによって発生する TiKV が利用できなくなる問題の修正が含まれます。 --- # TiDB 5.2.1 リリースノート {#tidb-5-2-1-release-notes} diff --git a/releases/release-5.2.3.md b/releases/release-5.2.3.md index 246042e5c55b6..61b5beb7e80ce 100644 --- a/releases/release-5.2.3.md +++ b/releases/release-5.2.3.md @@ -1,6 +1,6 @@ --- title: TiDB 5.2.3 Release Note -summary: TiDB 5.2.3 は 2021 年 12 月 3 日にリリースされました。このバージョンには TiKV のバグ修正が含まれており、複数のキーによって呼び出された場合に GcKeys` タスクが機能せず、圧縮フィルター GC で潜在的な問題が発生する問題に対処しています。(#11217) +summary: TiDB 5.2.3 は 2021年 12月 3日にリリースされました。このバージョンには TiKV のバグ修正が含まれており、複数のキーによって呼び出された場合に GcKeys` タスクが機能せず、圧縮フィルター GC で潜在的な問題が発生する問題に対処しています。(#11217) --- # TiDB 5.2.3 リリースノート {#tidb-5-2-3-release-note} diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index c175b3a216dc1..d091d155beea8 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -90,7 +90,7 @@ TiDBバージョン：5.2.4 - `REPLACE`ステートメントが自動 ID が範囲外の場合に他の行を誤って変更してしまう問題を修正しました [#29483](https://github.com/pingcap/tidb/issues/29483) - スロークエリログが正常にログを出力できず、メモリを過剰に消費する可能性がある問題を修正しました [#32656](https://github.com/pingcap/tidb/issues/32656) - NATURAL JOINの結果に予期しない列が含まれる可能性がある問題を修正しました [#29481](https://github.com/pingcap/tidb/issues/29481) - - `ORDER BY`と`LIMIT`を 1 つのステートメントで一緒に使用すると、プレフィックス列インデックスを使用してデータをクエリする場合に誤った結果が出力される可能性がある問題を修正しました [#29711](https://github.com/pingcap/tidb/issues/29711) + - `ORDER BY`と`LIMIT`を 1つのステートメントで一緒に使用すると、プレフィックス列インデックスを使用してデータをクエリする場合に誤った結果が出力される可能性がある問題を修正しました [#29711](https://github.com/pingcap/tidb/issues/29711) - 楽観的トランザクションの再試行時に、DOUBLE型のAUTO_INCREMENT列が変更される可能性がある問題を修正しました [#29892](https://github.com/pingcap/tidb/issues/29892) - STR_TO_DATE関数がマイクロ秒部分の先頭のゼロを正しく処理できない問題を修正しました [#30078](https://github.com/pingcap/tidb/issues/30078) - TiFlashがまだ空の範囲のテーブル読み取りをサポートしていないにもかかわらず、TiDBが空の範囲のテーブルをスキャンする際に誤った結果を取得する問題を修正します。 [#33083](https://github.com/pingcap/tidb/issues/33083) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index ec5c36f361952..dff76c1395ca4 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -234,7 +234,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 TiCDCは、災害シナリオにおいて結果整合性のあるレプリケーション機能を提供します。プライマリTiDBクラスタで災害が発生し、短期間でサービスを再開できない場合、TiCDCはセカンダリクラスタのデータの整合性を確保する機能を提供する必要があります。同時に、TiCDCは、データベースが長時間利用できなくなり業務に支障をきたすことを回避するため、ビジネス部門がトラフィックをセカンダリクラスタに迅速に切り替えられるようにする必要があります。 - この機能は、TiCDC が TiDB クラスターからセカンダリリレーショナルデータベース TiDB/ Aurora/MySQL/MariaDB に増分データをレプリケーションすることをサポートします。プライマリクラスターがクラッシュした場合、災害発生前の TiCDC のレプリケーション状態が正常で、レプリケーション遅延が小さいという条件付きで、TiCDC は 5 分以内にセカンダリクラスターをプライマリクラスター内の特定のスナップショットに復旧できます。これにより、データ損失は 30 分未満、つまり RTO <= 5 分、RPO <= 30 分を実現できます。 + この機能は、TiCDC が TiDB クラスターからセカンダリリレーショナルデータベース TiDB/ Aurora/MySQL/MariaDB に増分データをレプリケーションすることをサポートします。プライマリクラスターがクラッシュした場合、災害発生前の TiCDC のレプリケーション状態が正常で、レプリケーション遅延が小さいという条件付きで、TiCDC は 5分以内にセカンダリクラスターをプライマリクラスター内の特定のスナップショットに復旧できます。これにより、データ損失は 30分未満、つまり RTO <= 5分、RPO <= 30分を実現できます。 [ユーザードキュメント](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios) @@ -403,7 +403,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - TiFlashストアサイズ統計の不正確さの問題を修正 - ライブラリ`nsl`がないため、一部のプラットフォームでTiFlashが起動に失敗する問題を修正しました。 - - 書き込み圧力が大きい場合、 `wait index`の無限待機をブロックします (デフォルトの 5 分のタイムアウトが追加されます)。これにより、 TiFlash がデータ複製を待機してサービスを提供するのに時間がかかりすぎるのを防ぎます。 + - 書き込み圧力が大きい場合、 `wait index`の無限待機をブロックします (デフォルトの 5分のタイムアウトが追加されます)。これにより、 TiFlash がデータ複製を待機してサービスを提供するのに時間がかかりすぎるのを防ぎます。 - ログボリュームが大きい場合にログ検索が遅くなり、結果が表示されない問題を修正しました - 古い履歴ログを検索するときに最新のログしか検索できない問題を修正しました - 新しい照合順序が有効になっているときに間違った結果になる可能性を修正しました diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index ead4c9908a47e..241ed0ede6dab 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -42,7 +42,7 @@ TiDB バージョン: 5.3.1 - TiCDCクライアントは証明書名が指定されていない場合でも動作します[＃3627](https://github.com/pingcap/tiflow/issues/3627) - チェックポイントのタイムスタンプが予期せず進むのを避けるために、テーブルごとにシンクのチェックポイントを管理する[＃3545](https://github.com/pingcap/tiflow/issues/3545) - チェンジフィードを再開するための指数バックオフメカニズムを追加します[＃3329](https://github.com/pingcap/tiflow/issues/3329) - - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を 3 に変更します[＃3337](https://github.com/pingcap/tiflow/issues/3337) + - TiCDC がメッセージを Kafka パーティション間でより均等に分散するように、Kafka シンク`partition-num`のデフォルト値を3に変更します[＃3337](https://github.com/pingcap/tiflow/issues/3337) - 「EventFeed 再試行レート制限」ログの数を減らす[＃4006](https://github.com/pingcap/tiflow/issues/4006) - デフォルト値の`max-message-bytes`を10M に設定する [＃4041](https://github.com/pingcap/tiflow/issues/4041) - `no owner alert` `table sink total row`含む`buffer sink total row` PrometheusとGrafana 監視メトリックとアラート追加します`mounter row` [＃4054](https://github.com/pingcap/tiflow/issues/4054) [＃1606](https://github.com/pingcap/tiflow/issues/1606) diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index 23cb26a63efaa..669504e0ebf1c 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -78,7 +78,7 @@ TiDB バージョン: 5.3.2 - tikv-ctl が間違った文字列一致のために誤った結果を返す問題を修正[＃12329](https://github.com/tikv/tikv/issues/12329) - レプリカ読み取りが線形化可能性に違反する可能性があるバグを修正しました [＃12109](https://github.com/tikv/tikv/issues/12109) - リージョンをマージする際に、ターゲットピアが初期化されずに破棄されたピアに置き換えられたときに発生するTiKV panic問題を修正しました。 [＃12048](https://github.com/tikv/tikv/issues/12048) - - TiKV が 2 年以上実行されている場合にpanicする可能性があるバグを修正[＃11940](https://github.com/tikv/tikv/issues/11940) + - TiKV が 2年以上実行されている場合にpanicする可能性があるバグを修正[＃11940](https://github.com/tikv/tikv/issues/11940) - PD diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index d65fa8d5b3595..33e51a81409ee 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -86,7 +86,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - Ubuntu 18.04 でTiKVがプロファイリングを実行するときに発生する可能性のあるpanic問題を修正しました [＃9765](https://github.com/tikv/tikv/issues/9765) - レプリカ読み取りが線形化可能性に違反する可能性があるバグを修正しました [＃12109](https://github.com/tikv/tikv/issues/12109) - リージョンをマージする際に、ターゲットピアが初期化されずに破棄されたピアに置き換えられたときに発生するTiKV panic問題を修正しました。 [＃12048](https://github.com/tikv/tikv/issues/12048) - - TiKV が 2 年以上実行されている場合にpanicする可能性があるバグを修正[＃11940](https://github.com/tikv/tikv/issues/11940) + - TiKV が 2年以上実行されている場合にpanicする可能性があるバグを修正[＃11940](https://github.com/tikv/tikv/issues/11940) - 解決ロックのステップ必要とする領域の数を減らすことで、TiCDC の回復時間を短縮します。 [＃11993](https://github.com/tikv/tikv/issues/11993) - ピアステータスが`Applying` ときにスナップショットファイルを削除すると発生するpanic問題を修正しました [＃11746](https://github.com/tikv/tikv/issues/11746) - ピアを破棄するとレイテンシーが大きくなる可能性がある問題を修正[＃10210](https://github.com/tikv/tikv/issues/10210) diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index a827c9e8ecccc..d9e49423f059f 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -34,7 +34,7 @@ TiDB バージョン: 6.0.0-DMR ## リリース戦略の変更 {#release-strategy-changes} -TiDB v6.0.0 以降、TiDB は次の 2 種類のリリースを提供します。 +TiDB v6.0.0 以降、TiDB は次の2種類のリリースを提供します。 - 長期サポートリリース @@ -106,7 +106,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 実行計画を共有するためにプリペアドステートメントを強化する - SQL 実行計画を再利用すると、SQL 文の解析時間を効果的に短縮し、CPU リソースの消費を抑え、SQL 実行効率を向上させることができます。SQL チューニングの重要な方法の 1 つは、SQL 実行計画を効果的に再利用することです。TiDB は、プリペアドステートメントと実行計画の共有をサポートしています。ただし、プリペアドステートメントが閉じられると、TiDB は対応するプラン キャッシュを自動的にクリアします。その後、TiDB は繰り返される SQL 文を不必要に解析し、実行効率に影響を与える可能性があります。v6.0.0 以降、TiDB は`tidb_ignore_prepared_cache_close_stmt`パラメータ (デフォルトでは無効) によって`COM_STMT_CLOSE`のコマンドを無視するかどうかを制御できるようになりました。パラメータを有効にすると、TiDB はプリペアドステートメントを閉じるコマンドを無視し、実行計画をキャッシュに保持するため、実行計画の再利用率が向上します。 + SQL 実行計画を再利用すると、SQL 文の解析時間を効果的に短縮し、CPU リソースの消費を抑え、SQL 実行効率を向上させることができます。SQL チューニングの重要な方法の 1つは、SQL 実行計画を効果的に再利用することです。TiDB は、プリペアドステートメントと実行計画の共有をサポートしています。ただし、プリペアドステートメントが閉じられると、TiDB は対応するプラン キャッシュを自動的にクリアします。その後、TiDB は繰り返される SQL 文を不必要に解析し、実行効率に影響を与える可能性があります。v6.0.0 以降、TiDB は`tidb_ignore_prepared_cache_close_stmt`パラメータ (デフォルトでは無効) によって`COM_STMT_CLOSE`のコマンドを無視するかどうかを制御できるようになりました。パラメータを有効にすると、TiDB はプリペアドステートメントを閉じるコマンドを無視し、実行計画をキャッシュに保持するため、実行計画の再利用率が向上します。 [ユーザードキュメント](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement) [＃31056](https://github.com/pingcap/tidb/issues/31056) @@ -160,7 +160,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - TiFlashのzstd圧縮アルゴリズムをサポート - TiFlash、 `profiles.default.dt_compression_method`と`profiles.default.dt_compression_level` 2 つのパラメータが導入されており、ユーザーはパフォーマンスと容量のバランスに基づいて最適な圧縮アルゴリズムを選択できます。 + TiFlash、 `profiles.default.dt_compression_method`と`profiles.default.dt_compression_level` 2つのパラメータが導入されており、ユーザーはパフォーマンスと容量のバランスに基づいて最適な圧縮アルゴリズムを選択できます。 [ユーザードキュメント](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) @@ -461,7 +461,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - クエリがエラーを報告したときに CTE がブロックされる可能性があるバグを修正[＃31302](https://github.com/pingcap/tidb/issues/31302) - 非厳密モードでテーブルを作成するときに、varbinary または varchar 列の長さが長すぎるとエラーが発生する可能性があるバグを修正しました[＃30328](https://github.com/pingcap/tidb/issues/30328) - `information_schema.placement_policies`でフォロワーが指定されていない場合のフォロワー数が間違っている問題を修正[＃31702](https://github.com/pingcap/tidb/issues/31702) - - TiDB でインデックスの作成時に列プレフィックス長を 0 に指定できる問題を修正[＃31972](https://github.com/pingcap/tidb/issues/31972) + - TiDB でインデックスの作成時に列プレフィックス長を0に指定できる問題を修正[＃31972](https://github.com/pingcap/tidb/issues/31972) - TiDBがスペースで終わるパーティション名を許可する問題を修正[＃31535](https://github.com/pingcap/tidb/issues/31535) - `RENAME TABLE`文のエラーメッセージを修正する [＃29893](https://github.com/pingcap/tidb/issues/29893) @@ -473,7 +473,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - GCワーカーがビジー状態のときにTiKVがデータ範囲を削除できない（つまり内部コマンド`unsafe_destroy_range`が実行される）バグを修正[＃11903](https://github.com/tikv/tikv/issues/11903) - `StoreMeta`のデータが一部のコーナーケースで誤って削除されたときに TiKV がパニックを起こすバグを修正[＃11852](https://github.com/tikv/tikv/issues/11852) - ARM プラットフォームでプロファイリングを実行するときに TiKV がパニックを起こすバグを修正[＃10658](https://github.com/tikv/tikv/issues/10658) - - TiKV が 2 年以上実行されている場合にpanicする可能性があるバグを修正[＃11940](https://github.com/tikv/tikv/issues/11940) + - TiKV が 2年以上実行されている場合にpanicする可能性があるバグを修正[＃11940](https://github.com/tikv/tikv/issues/11940) - SSE命令セット不足により発生するARM64アーキテクチャでのコンパイル問題を修正 [＃12034](https://github.com/tikv/tikv/issues/12034) - 初期化されていないレプリカを削除すると古いレプリカが再作成される可能性がある問題を修正[＃10533](https://github.com/tikv/tikv/issues/10533) - 古いメッセージによって TiKV がpanicを起こすバグを修正[＃12023](https://github.com/tikv/tikv/issues/12023) diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 151ed908fa936..d673e93eae1ac 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -86,7 +86,7 @@ TiDB バージョン: 6.1.0 [＃29932](https://github.com/pingcap/tidb/issues/29932) [`STRAIGHT_JOIN`](/optimizer-hints.md#straight_join) : [`LEADING`](/optimizer-hints.md#leadingt1_name--tl_name-) -- TiFlash はさらに 4 つの関数をサポートしています。 +- TiFlash はさらに 4つの関数をサポートしています。 - `FROM_DAYS` - `TO_DAYS` @@ -117,7 +117,7 @@ TiDB バージョン: 6.1.0 - TiDBは最大GC待機時間の設定をサポートしています - TiDB のトランザクションは、マルチバージョン同時実行制御 (MVCC) メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが格納されます。古いデータはガベージコレクション (GC) タスクによって定期的にクリーンアップされ、ストレージスペースの再利用を促進してクラスターのパフォーマンスと安定性を向上させます。GC は、デフォルトでは 10 分ごとにトリガーされます。長時間実行トランザクションが対応する履歴データにアクセスできるようにするため、実行中のトランザクションがある場合は GC タスクが遅延されます。GC タスクが無期限に遅延されないように、TiDB は GC タスクの最大遅延時間を制御するシステム変数[`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610)導入しています。最大遅延時間を超えると、GC は強制的に実行されます。変数のデフォルト値は 24 時間です。この機能により、GC の待機時間と長時間実行トランザクションの関係を制御でき、クラスターの安定性が向上します。 + TiDB のトランザクションは、マルチバージョン同時実行制御 (MVCC) メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが格納されます。古いデータはガベージコレクション (GC) タスクによって定期的にクリーンアップされ、ストレージスペースの再利用を促進してクラスターのパフォーマンスと安定性を向上させます。GC は、デフォルトでは 10分ごとにトリガーされます。長時間実行トランザクションが対応する履歴データにアクセスできるようにするため、実行中のトランザクションがある場合は GC タスクが遅延されます。GC タスクが無期限に遅延されないように、TiDB は GC タスクの最大遅延時間を制御するシステム変数[`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610)導入しています。最大遅延時間を超えると、GC は強制的に実行されます。変数のデフォルト値は 24時間です。この機能により、GC の待機時間と長時間実行トランザクションの関係を制御でき、クラスターの安定性が向上します。 [ユーザードキュメント](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index a5ae1a817acc8..7ad3ad954fe25 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -15,11 +15,11 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - TiDB - - 1 つのテーブルで配置ルールとTiFlashレプリカを同時に設定できるようにする [＃37171](https://github.com/pingcap/tidb/issues/37171) @[lcwangchao](https://github.com/lcwangchao) + - 1つのテーブルで配置ルールとTiFlashレプリカを同時に設定できるようにする [＃37171](https://github.com/pingcap/tidb/issues/37171) @[lcwangchao](https://github.com/lcwangchao) - TiKV - - 1 つのピアが到達不能になった後にRaftstore が過剰なメッセージをブロードキャストすることを回避するための`unreachable_backoff`項目の設定をサポートします[＃13054](https://github.com/tikv/tikv/issues/13054) @[5kbpers](https://github.com/5kbpers) + - 1つのピアが到達不能になった後にRaftstore が過剰なメッセージをブロードキャストすることを回避するための`unreachable_backoff`項目の設定をサポートします[＃13054](https://github.com/tikv/tikv/issues/13054) @[5kbpers](https://github.com/5kbpers) - RocksDB 書き込みストール設定をフロー制御しきい値より小さい値に設定できるようになりました。 [#13467](https://github.com/tikv/tikv/issues/13467) @[tabokie](https://github.com/tabokie) - ツール diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index fdf3e1bc39a58..5412f6896651c 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -261,7 +261,7 @@ TiDBバージョン: 6.2.0-DMR | [tidb_enable_noop_variables](/system-variables.md#tidb_enable_noop_variables-new-in-v620) | 新しく追加された | この変数は`noop`の結果に`SHOW [GLOBAL] VARIABLES` 変数を表示するかどうかを制御します。 | | [tidb_min_paging_size](/system-variables.md#tidb_min_paging_size-new-in-v620) | 新しく追加された | この変数は、コプロセッサのページング要求処理中に処理される行の最大数を設定するために使用されます。 | | [tidb_txn_commit_batch_size](/system-variables.md#tidb_txn_commit_batch_size-new-in-v620) | 新しく追加された | この変数は、TiDBがTiKVに送信するトランザクションコミット要求のバッチサイズを制御するために使用されます。 | -| tidb_enable_change_multi_schema | 削除済み | この変数は、v6.2.0 以降では、デフォルトで 1 つの`ALTER TABLE`ステートメントで複数の列またはインデックスを変更できるため、削除されます。 | +| tidb_enable_change_multi_schema | 削除済み | この変数は、v6.2.0 以降では、デフォルトで 1つの`ALTER TABLE`ステートメントで複数の列またはインデックスを変更できるため、削除されます。 | | [tidb_enable_outer_join_reorder](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610) | 変更 | この変数は、TiDB の結合したテーブルの再配置アルゴリズムが Outer Join をサポートするかどうかを制御します。v6.1.0 では、デフォルト値は`ON`であり、これは Join Reorder の Outer Join のサポートがデフォルトで有効になっていることを意味します。v6.2.0 以降では、デフォルト値は`OFF`であり、これはサポートがデフォルトで無効になっていることを意味します。 | ### コンフィグレーションファイルパラメータ {#configuration-file-parameters} @@ -310,7 +310,7 @@ TiDBバージョン: 6.2.0-DMR - TiDBコンポーネントがv6.2.0以降の場合、TiKVコンポーネントはv6.2.0より前のバージョンであってはなりません。 - TiKV は[動的構成](/dynamic-config.md#modify-tikv-configuration-dynamically)をサポートする構成アイテム`split.region-cpu-overload-threshold-ratio`を追加します。 - スロークエリログ、 `information_schema.statements_summary` 、および`information_schema.slow_query`は`binary_plan` 、またはバイナリ形式でエンコードされた実行計画をエクスポートできます。 -- `SHOW TABLE ... REGIONS`ステートメントに、 `SCHEDULING_CONSTRAINTS`と`SCHEDULING_STATE` 2 つの列が追加されます。これらはそれぞれ、SQL の配置におけるリージョンスケジューリング制約と現在のスケジューリング状態を示します。 +- `SHOW TABLE ... REGIONS`ステートメントに、 `SCHEDULING_CONSTRAINTS`と`SCHEDULING_STATE` 2つの列が追加されます。これらはそれぞれ、SQL の配置におけるリージョンスケジューリング制約と現在のスケジューリング状態を示します。 - TiDB v6.2.0以降では、 [TiKV-CDC](https://github.com/tikv/migration/tree/main/cdc)を介してRawKVのデータ変更をキャプチャできます。 - `ROLLBACK TO SAVEPOINT`を使用してトランザクションを特定のセーブポイントまでロールバックする場合、MySQL は指定されたセーブポイント以降に保持されているロックのみを解放しますが、TiDB の悲観的トランザクションでは、TiDB は指定されたセーブポイント以降に保持されているロックをすぐには解放しません。代わりに、TiDB はトランザクションがコミットまたはロールバックされたときにすべてのロックを解放します。 - TiDB v6.2.0以降、 `SELECT tidb_version()`ステートメントはストアタイプ（tikvまたはunistore）も返します。 diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 35f7ddff86d92..b864f8e8dcca3 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -42,7 +42,7 @@ TiDBバージョン: 6.3.0-DMR - [パーティション交換](/partitioned-table.md#partition-management)が GA になりました [#35996](https://github.com/pingcap/tidb/issues/35996) @[ymkzpx](https://github.com/ymkzpx) -- TiFlashへのさらに 2 つの[ウィンドウ関数](/tiflash/tiflash-supported-pushdown-calculations.md)のプッシュダウンをサポート [#5579](https://github.com/pingcap/tiflash/issues/5579) @[SeaRise](https://github.com/SeaRise) +- TiFlashへのさらに 2つの[ウィンドウ関数](/tiflash/tiflash-supported-pushdown-calculations.md)のプッシュダウンをサポート [#5579](https://github.com/pingcap/tiflash/issues/5579) @[SeaRise](https://github.com/SeaRise) - `LEAD()` - `LAG()` @@ -189,7 +189,7 @@ TiDBバージョン: 6.3.0-DMR - DM に新しい設定項目`safe-mode-duration`が追加されました [#6224](https://github.com/pingcap/tiflow/issues/6224) @[okJiang](https://github.com/okJiang) - この設定項目は、[タスク構成ファイル](/dm/task-configuration-file-full.md)ファイルに追加されます。DM が異常終了した後の自動セーフモードの継続時間を調整できます。デフォルト値は 60 秒です。 `safe-mode-duration` `"0s"`に設定すると、DM が異常再起動後にセーフモードに入ろうとしたときにエラーが報告されます。 + この設定項目は、[タスク構成ファイル](/dm/task-configuration-file-full.md)ファイルに追加されます。DM が異常終了した後の自動セーフモードの継続時間を調整できます。デフォルト値は 60秒です。 `safe-mode-duration` `"0s"`に設定すると、DM が異常再起動後にセーフモードに入ろうとしたときにエラーが報告されます。 ### TiDBデータ共有サブスクリプション {#tidb-data-share-subscription} diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 0b1887c86ce93..be802fdf4d7ac 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -139,7 +139,7 @@ TiDBバージョン: 6.4.0-DMR - バッチ書き込みリクエストが軽量トランザクション書き込みの応答時間に与える影響を軽減する [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) - 一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライン トランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッド ワークロード シナリオでの読み取り要求のスケジューリングを最適化するため、 [`readpool.unified.auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)構成項目を有効にすると、TiKV がすべての読み取り要求に対して UnifyReadPool スレッド プールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込み要求も動的に識別して優先順位を付け、1 回のポーリングで Apply スレッドが 1 つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響を軽減できます。 + 一部のシステムのビジネスロジックでは、定期的なバッチ DML タスクが必要ですが、これらのバッチ書き込みタスクを処理すると、オンライン トランザクションのレイテンシーが増加します。v6.3.0 では、TiKV はハイブリッド ワークロード シナリオでの読み取り要求のスケジューリングを最適化するため、 [`readpool.unified.auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)構成項目を有効にすると、TiKV がすべての読み取り要求に対して UnifyReadPool スレッド プールのサイズを自動的に調整します。v6.4.0 では、TiKV は書き込み要求も動的に識別して優先順位を付け、1回のポーリングで Apply スレッドが 1つの FSM (有限状態機械) に対して書き込むことができる最大バイト数を制御できるため、バッチ書き込み要求がトランザクション書き込みの応答時間に与える影響を軽減できます。 ### 使いやすさ {#ease-of-use} @@ -191,15 +191,15 @@ TiDBバージョン: 6.4.0-DMR v6.4.0 以降、TiDB で MySQL 互換の[範囲選択構文](https://dev.mysql.com/doc/refman/8.0/en/json.html#json-paths)を使用できるようになりました。 - - キーワード`to`を使用すると、配列要素の開始位置と終了位置を指定したり、配列内の連続した範囲の要素を選択したりできます。 `0`を使用すると、配列の最初の要素の位置を指定できます。たとえば、 `$[0 to 2]`を使用すると、配列の最初の 3 つの要素を選択できます。 + - キーワード`to`を使用すると、配列要素の開始位置と終了位置を指定したり、配列内の連続した範囲の要素を選択したりできます。 `0`を使用すると、配列の最初の要素の位置を指定できます。たとえば、 `$[0 to 2]`を使用すると、配列の最初の 3つの要素を選択できます。 - - キーワード`last`を使用すると、配列の最後の要素の位置を指定できます。これにより、右から左への位置設定が可能になります。たとえば、 `$[last-2 to last]`を使用すると、配列の最後の 3 つの要素を選択できます。 + - キーワード`last`を使用すると、配列の最後の要素の位置を指定できます。これにより、右から左への位置設定が可能になります。たとえば、 `$[last-2 to last]`を使用すると、配列の最後の 3つの要素を選択できます。 この機能により、SQL文の記述プロセスが簡素化され、JSON型の互換性がさらに向上し、MySQLアプリケーションをTiDBに移行する際の難易度が軽減されます。 - データベースユーザー向けの追加説明の追加をサポート [#38172](https://github.com/pingcap/tidb/issues/38172) @[CbcWestwolf](https://github.com/CbcWestwolf) - TiDB v6.4 では、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md)または[`ALTER USER`](/sql-statements/sql-statement-alter-user.md)を使用して、データベース ユーザーの追加の説明を追加できます。TiDB は 2 つの説明形式を提供します。 `COMMENT`を使用してテキスト コメントを追加したり、 `ATTRIBUTE`を使用して JSON 形式の構造化属性セットを追加したりできます。 + TiDB v6.4 では、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md)または[`ALTER USER`](/sql-statements/sql-statement-alter-user.md)を使用して、データベース ユーザーの追加の説明を追加できます。TiDB は 2つの説明形式を提供します。 `COMMENT`を使用してテキスト コメントを追加したり、 `ATTRIBUTE`を使用して JSON 形式の構造化属性セットを追加したりできます。 さらに、TiDB v6.4.0では[`USER_ATTRIBUTES`](/information-schema/information-schema-user-attributes.md)テーブルが追加され、ユーザーコメントやユーザー属性の情報を表示できるようになりました。 @@ -326,7 +326,7 @@ TiDBバージョン: 6.4.0-DMR ### その他 {#others} -- v6.4.0 以降、 `mysql.user`テーブルには、 `User_attributes`と`Token_issuer`という 2 つの新しい列が追加されています。以前の TiDB バージョンのバックアップ データから TiDB v6.4.0 に[`mysql`スキーマ内のシステムテーブルを復元します](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)と、 BR は`column count mismatch`テーブルの`mysql.user`エラーを報告します。 `mysql`スキーマ内のシステム テーブルを復元しない場合、このエラーは報告されません。 +- v6.4.0 以降、 `mysql.user`テーブルには、 `User_attributes`と`Token_issuer`という 2つの新しい列が追加されています。以前の TiDB バージョンのバックアップ データから TiDB v6.4.0 に[`mysql`スキーマ内のシステムテーブルを復元します](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)と、 BR は`column count mismatch`テーブルの`mysql.user`エラーを報告します。 `mysql`スキーマ内のシステム テーブルを復元しない場合、このエラーは報告されません。 - 名前が「 [Dumplingのエクスポートファイルの形式](/dumpling-overview.md#format-of-exported-files)一致するものの、末尾が非圧縮形式（例`test-schema-create.sql.origin`および`test.table-schema.sql.origin` ）で終わるファイルについては、 TiDB Lightning の処理方法が変更されました。v6.4.0 より前は、インポート対象ファイルにこのようなファイルが含まれている場合、TiDB Lightning はこれらのファイルのインポートをスキップしていました。v6.4.0 以降では、 TiDB Lightning TiDB Lightning はこれらのファイルがサポートされていない圧縮形式を使用しているとみなすため、インポート処理は失敗します。 - バージョン6.4.0以降、 `SYSTEM_VARIABLES_ADMIN`または`SUPER`の権限を持つチェンジフィードのみがTiCDC Syncpoint機能を使用できます。 diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index b2782aa8cd950..5952b9076833c 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -31,8 +31,8 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - パスワード コンプライアンス監査要件を満たす[パスワード管理](/password-management.md)ポリシーをサポートします。 - TiDB LightningとDumplingは、圧縮されたSQLおよびCSVファイルの[インポート](/tidb-lightning/tidb-lightning-data-source.md)および[エクスポート](/dumpling-overview.md#improve-export-efficiency-through-concurrency)をサポートします。 - TiDB Data Migration (DM) [継続的なデータ検証](/dm/dm-continuous-data-validation.md) GA になります。 -- TiDB バックアップ & リストアは、スナップショット チェックポイント バックアップをサポートし、 [PITR](/br/br-pitr-guide.md#run-pitr)のリカバリ パフォーマンスを 50% 向上させ、一般的なシナリオでの RPO を最短 5 分に短縮します。 -- [Kafkaへのデータの複製](/replicate-data-to-kafka.md)の TiCDC スループットを 4000 行/秒から 35000 行/秒に向上し、レプリケーションのレイテンシーを2 秒に短縮します。 +- TiDB バックアップ & リストアは、スナップショット チェックポイント バックアップをサポートし、 [PITR](/br/br-pitr-guide.md#run-pitr)のリカバリ パフォーマンスを 50% 向上させ、一般的なシナリオでの RPO を最短 5分に短縮します。 +- [Kafkaへのデータの複製](/replicate-data-to-kafka.md)の TiCDC スループットを 4000 行/秒から 35000 行/秒に向上し、レプリケーションのレイテンシーを2秒に短縮します。 - データのライフサイクルを管理するために行レベル[存続時間（TTL）](/time-to-live.md)を提供します (実験的)。 - TiCDC は、Amazon S3、Azure Blob Storage、NFS (実験的) など[変更ログをオブジェクトストレージに複製する](/ticdc/ticdc-sink-to-cloud-storage.md)サポートしています。 @@ -281,7 +281,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDBクラスタのテストシナリオでは、TiCDCのパフォーマンスが大幅に向上しました。具体的には、シナリオ[Kafkaへのデータの複製](/replicate-data-to-kafka.md)では、単一のTiCDCが処理できる行変更の最大量は3万行/秒に達し、レプリケーションのレイテンシーは10秒に短縮されました。TiKVとTiCDCのローリングアップグレード中でも、レプリケーションのレイテンシーは30秒未満です。 - 災害復旧 (DR) シナリオでは、TiCDC の再実行ログと同期ポイントを有効にすると、TiCDC のスループットを 4000 行/秒から 35000 行/秒に向上でき、レプリケーションのレイテンシーを2 秒に制限できます。 + 災害復旧 (DR) シナリオでは、TiCDC の再実行ログと同期ポイントを有効にすると、TiCDC のスループットを 4000 行/秒から 35000 行/秒に向上でき、レプリケーションのレイテンシーを2秒に制限できます。 ### バックアップと復元 {#backup-and-restore} @@ -366,7 +366,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では ### その他 {#others} -- v6.5.0 以降、 `mysql.user`テーブルに`Password_reuse_history`と`Password_reuse_time` 2 つの新しい列が追加されます。 +- v6.5.0 以降、 `mysql.user`テーブルに`Password_reuse_history`と`Password_reuse_time` 2つの新しい列が追加されます。 - バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全には互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)を参照してください。 ## 非推奨の機能 {#deprecated-feature} @@ -415,7 +415,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - TiDB Dashboard - - スロークエリページに 3 つの新しいフィールドを追加します:「Is Prepared?」、「Is Plan from Cache?」、「Is Plan from Binding?」 [＃1451](https://github.com/pingcap/tidb-dashboard/issues/1451) @[shhdgit](https://github.com/shhdgit) + - スロークエリページに 3つの新しいフィールドを追加します:「Is Prepared?」、「Is Plan from Cache?」、「Is Plan from Binding?」 [＃1451](https://github.com/pingcap/tidb-dashboard/issues/1451) @[shhdgit](https://github.com/shhdgit) - Backup & Restore (BR) diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 1bfbbf25698ca..0ab1153134d5f 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -91,7 +91,7 @@ TiDB バージョン: 6.5.10 - TiKV - - 1 つの TiKV ノードで遅い`check-leader`操作により、他の TiKV ノードの`resolved-ts`正常に進まなくなる問題を修正しました。 [＃15999](https://github.com/tikv/tikv/issues/15999) @[crazycs520](https://github.com/crazycs520) + - 1つの TiKV ノードで遅い`check-leader`操作により、他の TiKV ノードの`resolved-ts`正常に進まなくなる問題を修正しました。 [＃15999](https://github.com/tikv/tikv/issues/15999) @[crazycs520](https://github.com/crazycs520) - クエリ内の`CONV()`関数が数値システム変換中にオーバーフローし、TiKV panicが発生する問題を修正しました。 [＃16969](https://github.com/tikv/tikv/issues/16969) @[gengliqi](https://github.com/gengliqi) - 不安定なテストケースの問題を修正し、各テストが独立した一時ディレクトリを使用するようにして、オンライン構成の変更が他のテストケースに影響しないようにします。 [＃16871](https://github.com/tikv/tikv/issues/16871) @[glorv](https://github.com/glorv) - `DECIMAL`型の小数点部分が場合に正しくない問題を修正しました [＃16913](https://github.com/tikv/tikv/issues/16913) @[gengliqi](https://github.com/gengliqi) diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index 53e42f7b4985b..4327972d3db43 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -14,7 +14,7 @@ TiDBバージョン: 6.5.12 ## 互換性の変更 {#compatibility-changes} - openEuler 22.03 LTS SP3/SP4 オペレーティングシステムをサポートします。詳細については、 [OSおよびプラットフォームの要件](https://docs.pingcap.com/tidb/v6.5/hardware-and-software-requirements#os-and-platform-requirements)を参照してください。 -- [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-6.5/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を 2048 に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) +- [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-6.5/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を2048に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) - インデックスを追加する際の取り込みフェーズの最大速度を制限する新しいシステム変数[`tidb_ddl_reorg_max_write_speed`](https://docs.pingcap.com/tidb/v6.5/system-variables#tidb_ddl_reorg_max_write_speed-new-in-v6512)を追加します。 [＃57156](https://github.com/pingcap/tidb/issues/57156) @[CbcWestwolf](https://github.com/CbcWestwolf) ## 改善点 {#improvements} @@ -52,7 +52,7 @@ TiDBバージョン: 6.5.12 - `CAST`関数が文字セットの明示的な設定をサポートしていない問題を修正しました [＃55677](https://github.com/pingcap/tidb/issues/55677) @[Defined2014](https://github.com/Defined2014) - `LOAD DATA ... REPLACE INTO`操作でデータの不整合が発生する問題を修正[＃56408](https://github.com/pingcap/tidb/issues/56408) @[fzzf678](https://github.com/fzzf678) - `ADD INDEX` を実行するときに TiDB がインデックスの長さ制限をチェックしない問題を修正しました [＃56930](https://github.com/pingcap/tidb/issues/56930) @[fzzf678](https://github.com/fzzf678) - - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1 つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @[windtalker](https://github.com/windtalker) + - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @[windtalker](https://github.com/windtalker) - `IndexMerge` を構築するときに一部の述語が失われる可能性がある問題を修正しました [＃58476](https://github.com/pingcap/tidb/issues/58476) @[hawkingrei](https://github.com/hawkingrei) - `BIT`型から`CHAR`型にデータを変換すると TiKV パニックが発生する可能性がある問題を修正しました [＃56494](https://github.com/pingcap/tidb/issues/56494) @[lcwangchao](https://github.com/lcwangchao) - `CREATE VIEW`ステートメントで変数またはパラメータを使用してもエラーが報告されない問題を修正[＃53176](https://github.com/pingcap/tidb/issues/53176) @[mjonss](https://github.com/mjonss) diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index 95dfef5de65ae..7bd899055d01b 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -118,7 +118,7 @@ TiDB バージョン: 6.5.3 - 上流 TiDB で OOM が発生したときに TiCDC が停止する問題を修正しました [＃8561](https://github.com/pingcap/tiflow/issues/8561) @[overvenus](https://github.com/overvenus) - ネットワーク分離やPDオーナーノードの再起動などのPD障害時にTiCDCが停止する問題を修正[＃8808](https://github.com/pingcap/tiflow/issues/8808) [＃8812](https://github.com/pingcap/tiflow/issues/8812) [＃8877](https://github.com/pingcap/tiflow/issues/8877) @[asddongmen](https://github.com/asddongmen) - TiCDC タイムゾーン設定の問題を修正 [＃8798](https://github.com/pingcap/tiflow/issues/8798) @[Rustin170506](https://github.com/Rustin170506) - - 上流の TiKV ノードの 1 つがクラッシュするとチェックポイントの遅延が増加する問題を修正しました [＃8858](https://github.com/pingcap/tiflow/issues/8858) @[hicqu](https://github.com/hicqu) + - 上流の TiKV ノードの 1つがクラッシュするとチェックポイントの遅延が増加する問題を修正しました [＃8858](https://github.com/pingcap/tiflow/issues/8858) @[hicqu](https://github.com/hicqu) - 下流のMySQLにデータを複製するときに、上流のTiDB で`FLASHBACK CLUSTER TO TIMESTAMP`ステートメントが実行された後にレプリケーションエラーが発生する問題を修正しました。 [＃8040](https://github.com/pingcap/tiflow/issues/8040) @[asddongmen](https://github.com/asddongmen) - オブジェクトストレージにデータを複製する際に、上流の`EXCHANGE PARTITION`操作が下流のに正しく複製されない問題を修正しました。 [＃8914](https://github.com/pingcap/tiflow/issues/8914) @[CharlesCheung96](https://github.com/CharlesCheung96) - 一部の特殊なシナリオでソートコンポーネントの過剰なメモリ使用によって引き起こされる OOM 問題を修正[＃8974](https://github.com/pingcap/tiflow/issues/8974) @[hicqu](https://github.com/hicqu) diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index 222a8936efc0f..cfaa7b26d522f 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -161,7 +161,7 @@ TiDB バージョン: 6.5.4 - ダウンストリームでエラーが発生し、 で再試行すると、レプリケーションタスクが停止する可能性がある問題を修正しました。 [＃9450](https://github.com/pingcap/tiflow/issues/9450) @[hicqu](https://github.com/hicqu) - Kafka に同期するときに再試行間隔が短いためにレプリケーションタスクが失敗する問題を修正しました [＃9504](https://github.com/pingcap/tiflow/issues/9504) @[3AceShowHand](https://github.com/3AceShowHand) - - TiCDC がアップストリームの 1 つのトランザクションで複数の一意のキー行を変更するときに同期書き込み競合を引き起こす可能性がある問題を修正しました。 [＃9430](https://github.com/pingcap/tiflow/issues/9430) @[sdojjy](https://github.com/sdojjy) + - TiCDC がアップストリームの 1つのトランザクションで複数の一意のキー行を変更するときに同期書き込み競合を引き起こす可能性がある問題を修正しました。 [＃9430](https://github.com/pingcap/tiflow/issues/9430) @[sdojjy](https://github.com/sdojjy) - TiCDC が誤って名前変更 DDL 操作を同期する可能性がある問題を修正[＃9488](https://github.com/pingcap/tiflow/issues/9488) [＃9378](https://github.com/pingcap/tiflow/issues/9378) [＃9531](https://github.com/pingcap/tiflow/issues/9531) @[asddongmen](https://github.com/asddongmen) - 下流で短期的な障害が発生したときにレプリケーションタスクが停止する可能性がある問題を修正[＃9542](https://github.com/pingcap/tiflow/issues/9542) [＃9272](https://github.com/pingcap/tiflow/issues/9272) [＃9582](https://github.com/pingcap/tiflow/issues/9582) [＃9592](https://github.com/pingcap/tiflow/issues/9592) @[hicqu](https://github.com/hicqu) - TiCDC ノードのステータスが変化したときに発生する可能性のあるpanic問題を修正しました。 [＃9354](https://github.com/pingcap/tiflow/issues/9354) @[sdojjy](https://github.com/sdojjy) diff --git a/releases/release-6.5.7.md b/releases/release-6.5.7.md index 494c9019745e9..e8f33b73023ef 100644 --- a/releases/release-6.5.7.md +++ b/releases/release-6.5.7.md @@ -64,7 +64,7 @@ TiDB バージョン: 6.5.7 - TiDBがパニックを起こしてエラーを報告する問題を修正`invalid memory address or nil pointer dereference` [＃42739](https://github.com/pingcap/tidb/issues/42739) @[CbcWestwolf](https://github.com/CbcWestwolf) - CTEクエリが再試行プロセス中にエラー`type assertion for CTEStorageMap failed`を報告する可能性がある問題を修正しました [＃46522](https://github.com/pingcap/tidb/issues/46522) @[tiancaiamao](https://github.com/tiancaiamao) - 一部のタイムゾーンで夏時間が正しく表示されない問題を修正 [＃49586](https://github.com/pingcap/tidb/issues/49586) @[overvenus](https://github.com/overvenus) - - 依存関係のある 2 つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) + - 依存関係のある 2つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) - TiKV diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index 69968e1b57e06..3a3c506d9293f 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -33,7 +33,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - DDL操作のための分散並列実行フレームワークのサポート（実験的） [#37125](https://github.com/pingcap/tidb/issues/37125) @[zimulala](https://github.com/zimulala) - 以前のバージョンでは、TiDB クラスタ全体で 1 つの TiDB インスタンスのみが DDL オーナーとしてスキーマ変更タスクを処理できました。大規模テーブルの DDL 操作の DDL 並行性をさらに向上させるため、TiDB v6.6.0 では、DDL 用の分散並列実行フレームワークが導入されました。これにより、クラスタ内のすべての TiDB インスタンスが同じタスクの`StateWriteReorganization`フェーズを同時に実行して、DDL の実行を高速化できます。この機能はシステム変数[`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660)によって制御され、現在は`Add Index`操作のみでサポートされています。 + 以前のバージョンでは、TiDB クラスタ全体で 1つの TiDB インスタンスのみが DDL オーナーとしてスキーマ変更タスクを処理できました。大規模テーブルの DDL 操作の DDL 並行性をさらに向上させるため、TiDB v6.6.0 では、DDL 用の分散並列実行フレームワークが導入されました。これにより、クラスタ内のすべての TiDB インスタンスが同じタスクの`StateWriteReorganization`フェーズを同時に実行して、DDL の実行を高速化できます。この機能はシステム変数[`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660)によって制御され、現在は`Add Index`操作のみでサポートされています。 ### パフォーマンス {#performance} @@ -280,7 +280,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone ### テレメトリー {#telemetry} -- 2023 年 2 月 20 日以降、TiDB および TiDB Dashboard (v6.6.0 を含む) の新しいバージョンでは[テレメトリ機能](/telemetry.md)デフォルトで無効になります。デフォルトのテレメトリ構成を使用する以前のバージョンからアップグレードする場合、アップグレード後にテレメトリ機能は無効になります。特定のバージョンについては、 [TiDBのリリーススケジュール](/releases/release-timeline.md)を参照してください。 +- 2023年 2月 20日以降、TiDB および TiDB Dashboard (v6.6.0 を含む) の新しいバージョンでは[テレメトリ機能](/telemetry.md)デフォルトで無効になります。デフォルトのテレメトリ構成を使用する以前のバージョンからアップグレードする場合、アップグレード後にテレメトリ機能は無効になります。特定のバージョンについては、 [TiDBのリリーススケジュール](/releases/release-timeline.md)を参照してください。 - バージョン1.11.3以降、新規にデプロイされたTiUPでは、テレメトリ機能はデフォルトで無効になっています。以前のバージョンのTiUPからバージョン1.11.3以降にアップグレードした場合、テレメトリ機能はアップグレード前と同じ状態を維持します。 ## 互換性の変更 {#compatibility-changes} @@ -315,7 +315,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | `tidb_general_plan_cache_size` | 変更 | この変数は、General Plan Cache によってキャッシュできる実行計画の最大数を制御します。v6.6.0 以降、この変数は[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)に名前が変更されました。 | | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | この変数に新しい値オプション`learner`が追加され、TiDB が読み取り専用ノードからデータを読み取る際に使用するラーナーレプリカを指定できます。 | | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 変更 | TiDBクラスタの読み取り可用性を向上させるため、この変数に新しい値オプション`prefer-leader`が追加されました。このオプションを設定すると、TiDBはリーダーレプリカからの読み取りを優先します。リーダーレプリカのパフォーマンスが著しく低下した場合、TiDBは自動的にフォロワーレプリカからの読み取りに切り替わります。 | -| [`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size) | 変更 | この変数は`IndexLookUp`オペレータのコプロセッサータスクのバッチ サイズを制御します。 `0`バッチを無効にすることを意味します。v6.6.0 以降、デフォルト値は`0`から`4`に変更され、リクエストのバッチごとに 4 つのコプロセッサータスクが 1 つのタスクにまとめられます。 | +| [`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size) | 変更 | この変数は`IndexLookUp`オペレータのコプロセッサータスクのバッチ サイズを制御します。 `0`バッチを無効にすることを意味します。v6.6.0 以降、デフォルト値は`0`から`4`に変更され、リクエストのバッチごとに 4つのコプロセッサータスクが 1つのタスクにまとめられます。 | | [`mpp_exchange_compression_mode`](/system-variables.md#mpp_exchange_compression_mode-new-in-v660) | 新しく追加された | この変数は、MPP Exchange オペレータのデータ圧縮モードを指定します。この変数は、TiDB がバージョン番号`1`の MPP 実行計画を選択した場合に有効になります。デフォルト値`UNSPECIFIED`は、TiDB が自動的に`FAST`圧縮モードを選択することを意味します。 | | [`mpp_version`](/system-variables.md#mpp_version-new-in-v660) | 新しく追加された | この変数は、MPP実行計画のバージョンを指定します。バージョンを指定すると、TiDBは指定されたバージョンのMPP実行計画を選択します。デフォルト値`UNSPECIFIED` 、TiDBが最新バージョン`1`自動的に選択することを意味します。 | | [`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) | 新しく追加された | この変数は、DDL 再編成フェーズの分散実行を有効にしてこのフェーズを高速化するかどうかを制御します。デフォルト値`OFF`は、デフォルトでは DDL 再編成フェーズの分散実行を有効にしないことを意味します。現在、この変数は`ADD INDEX`に対してのみ有効です。 | @@ -548,7 +548,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - `binlog-schema delete`コマンドの実行に失敗する問題を修正しました [#7373](https://github.com/pingcap/tiflow/issues/7373) @[liumengya94](https://github.com/liumengya94) - 最後のbinlogがスキップされたDDLである場合にチェックポイントが進まない問題を修正 [#8175](https://github.com/pingcap/tiflow/issues/8175) @[D3Hunter](https://github.com/D3Hunter) - - 1 つのテーブルで「更新」タイプと「非更新」タイプの両方の式フィルターが指定されている場合、すべての`UPDATE`ステートメントがスキップされるバグを修正しました [#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) + - 1つのテーブルで「更新」タイプと「非更新」タイプの両方の式フィルターが指定されている場合、すべての`UPDATE`ステートメントがスキップされるバグを修正しました [#7831](https://github.com/pingcap/tiflow/issues/7831) @[lance6716](https://github.com/lance6716) - テーブルに`update-old-value-expr`または`update-new-value-expr`のいずれか一方のみが設定されている場合、フィルタルールが有効にならないか、DM がパニックを起こすバグを修正しました。 [#7774](https://github.com/pingcap/tiflow/issues/7774) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 38a953f5e9286..f4fa72bba0f8f 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone バージョン7.0.0-DMRの主な新機能と改善点は以下のとおりです。 -
    カテゴリ特徴説明
    拡張性とパフォーマンス
    		セッションレベルの非プリペアドSQLプランキャッシュ（実験的）セッションレベルでプランキャッシュを自動的に再利用することで、コンパイルを削減し、同じSQLパターンに対して事前に手動でプリペアドステートメントを設定することなくクエリ時間を短縮します。
    TiFlashは 、分散型ストレージおよびコンピューティングアーキテクチャとS3共有ストレージ（実験的）をサポートしています。 TiFlashは、オプションとしてクラウドネイティブアーキテクチャを導入します。
    • TiFlashのコンピューティング機能とストレージを分離することで、柔軟なHTAPリソース利用における画期的な進歩を実現しました。
    • S3ベースのストレージエンジンを導入し、より低コストで共有ストレージを提供可能にしました。
    信頼性と可用性
    		リソース制御機能強化（実験的）リソースグループを使用して、1 つのクラスタ内のさまざまなアプリケーションやワークロードにリソースを割り当て、分離することをサポートします。今回のリリースでは、TiDB はさまざまなリソースバインディングモード (ユーザー、セッション、ステートメントレベル) とユーザー定義の優先度をサポートします。さらに、コマンドを使用してリソースのキャリブレーション (リソース全体の量の見積もり) を実行することもできます。
    TiFlashはディスクへのスピルをサポートしていますTiFlashは、集計、ソート、ハッシュ結合などのデータ集約型操作におけるメモリ不足（OOM）を軽減するために、中間結果をディスクに書き出す機能をサポートしています。
    SQL行レベルTTL （GA）一定期間経過したデータを自動的に削除することで、データベースサイズの管理をサポートし、パフォーマンスを向上させます。
    LIST / RANGEパーティションを再編成するREORGANIZE PARTITIONステートメントは、隣接するパーティションをマージしたり、1 つのパーティションを複数のパーティションに分割したりするために使用でき、パーティション化されたテーブルの使いやすさを向上させます。
    データベースの運用と可観測性
    		TiDBはLOAD DATAステートメントの機能を拡張します（実験的）。 TiDBは、S3/GCSからのデータインポートをサポートするなど、 LOAD DATA SQLステートメントの機能を拡張します。
    TiCDCはオブジェクトストレージシンク（GA）をサポートしていますTiCDCは、Amazon S3、GCS、Azure Blob Storage、NFSなどのオブジェクトストレージサービスへの行変更イベントの複製をサポートしています。
    +
    カテゴリ特徴説明
    拡張性とパフォーマンス
    		セッションレベルの非プリペアドSQLプランキャッシュ（実験的）セッションレベルでプランキャッシュを自動的に再利用することで、コンパイルを削減し、同じSQLパターンに対して事前に手動でプリペアドステートメントを設定することなくクエリ時間を短縮します。
    TiFlashは 、分散型ストレージおよびコンピューティングアーキテクチャとS3共有ストレージ（実験的）をサポートしています。 TiFlashは、オプションとしてクラウドネイティブアーキテクチャを導入します。
    • TiFlashのコンピューティング機能とストレージを分離することで、柔軟なHTAPリソース利用における画期的な進歩を実現しました。
    • S3ベースのストレージエンジンを導入し、より低コストで共有ストレージを提供可能にしました。
    信頼性と可用性
    		リソース制御機能強化（実験的）リソースグループを使用して、1つのクラスタ内のさまざまなアプリケーションやワークロードにリソースを割り当て、分離することをサポートします。今回のリリースでは、TiDB はさまざまなリソースバインディングモード (ユーザー、セッション、ステートメントレベル) とユーザー定義の優先度をサポートします。さらに、コマンドを使用してリソースのキャリブレーション (リソース全体の量の見積もり) を実行することもできます。
    TiFlashはディスクへのスピルをサポートしていますTiFlashは、集計、ソート、ハッシュ結合などのデータ集約型操作におけるメモリ不足（OOM）を軽減するために、中間結果をディスクに書き出す機能をサポートしています。
    SQL行レベルTTL （GA）一定期間経過したデータを自動的に削除することで、データベースサイズの管理をサポートし、パフォーマンスを向上させます。
    LIST / RANGEパーティションを再編成するREORGANIZE PARTITIONステートメントは、隣接するパーティションをマージしたり、1つのパーティションを複数のパーティションに分割したりするために使用でき、パーティション化されたテーブルの使いやすさを向上させます。
    データベースの運用と可観測性
    		TiDBはLOAD DATAステートメントの機能を拡張します（実験的）。 TiDBは、S3/GCSからのデータインポートをサポートするなど、 LOAD DATA SQLステートメントの機能を拡張します。
    TiCDCはオブジェクトストレージシンク（GA）をサポートしていますTiCDCは、Amazon S3、GCS、Azure Blob Storage、NFSなどのオブジェクトストレージサービスへの行変更イベントの複製をサポートしています。
    ## 機能の詳細 {#feature-details} diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index ecb61edd721db..fde1b212be892 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -127,11 +127,11 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiB レベルのデータをインポートする際のTiDB Lightningの安定性を向上[＃43510](https://github.com/pingcap/tidb/issues/43510) [＃43657](https://github.com/pingcap/tidb/issues/43657) @[D3Hunter](https://github.com/D3Hunter) @[lance6716](https://github.com/lance6716) - v7.1.0 以降、 TiDB Lightning には、TiB レベルのデータをインポートする際の安定性を向上させるために 4 つの構成項目が追加されました。 + v7.1.0 以降、 TiDB Lightning には、TiB レベルのデータをインポートする際の安定性を向上させるために 4つの構成項目が追加されました。 - `tikv-importer.region-split-batch-size`バッチでリージョンを分割する際のリージョンの数を制御します。デフォルト値は`4096`です。 - `tikv-importer.region-split-concurrency`リージョン分割時の同時実行を制御します。デフォルト値は CPU コアの数です。 - - `tikv-importer.region-check-backoff-limit` 、分割および分散処理後にリージョンがオンラインになるまでの再試行回数を制御します。デフォルト値は`1800`で、最大再試行間隔は 2 秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。 + - `tikv-importer.region-check-backoff-limit` 、分割および分散処理後にリージョンがオンラインになるまでの再試行回数を制御します。デフォルト値は`1800`で、最大再試行間隔は 2秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。 - `tikv-importer.pause-pd-scheduler-scope` TiDB Lightning がPD スケジューリングを一時停止する範囲を制御します。値のオプションは`"table"`と`"global"`です。デフォルト値は`"table"`です。v6.1.0 より前のバージョンの TiDB では、データインポート中にグローバルスケジューリングを一時停止する`"global"`オプションのみを設定できます。v6.1.0 以降では、ターゲットテーブルデータが格納されているリージョンのスケジューリングのみを一時停止する`"table"`オプションがサポートされています。データ量が多いシナリオでは、安定性を向上させるために、この設定項目を`"global"`に設定することをお勧めします。 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 @@ -204,7 +204,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - LDAP認証をサポート [＃43580](https://github.com/pingcap/tidb/issues/43580) @[YangKeao](https://github.com/YangKeao) - v7.1.0 以降、TiDB は LDAP 認証をサポートし、 `authentication_ldap_sasl`と`authentication_ldap_simple` 2 つの認証プラグインを提供します。 + v7.1.0 以降、TiDB は LDAP 認証をサポートし、 `authentication_ldap_sasl`と`authentication_ldap_simple` 2つの認証プラグインを提供します。 詳細については[ドキュメント](/security-compatibility-with-mysql.md)を参照してください。 @@ -214,7 +214,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - より詳細な監査イベント定義とよりきめ細かな監査設定のために、「フィルター」と「ルール」の概念を導入します。 - JSON 形式でのルールの定義をサポートし、よりユーザーフレンドリーな構成方法を提供します。 - - 自動ログローテーションとスペース管理関数を追加し、保持時間とログサイズの 2 つの次元でのログローテーションの構成をサポートします。 + - 自動ログローテーションとスペース管理関数を追加し、保持時間とログサイズの 2つの次元でのログローテーションの構成をサポートします。 - 監査ログをTEXTと JSON 形式の両方で出力できるようにすることで、サードパーティ ツールとの統合が容易になります。 - 監査ログの秘匿化をサポートします。セキュリティ強化のため、すべてのリテラルを置き換えることができます。 @@ -246,7 +246,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | `tidb_ddl_distribute_reorg` | 削除済み | この変数の名前は[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)に変更されます。 | -| [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 2 つの新しい値オプション`authentication_ldap_sasl`と`authentication_ldap_simple`が導入されました。 | +| [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 2つの新しい値オプション`authentication_ldap_sasl`と`authentication_ldap_simple`が導入されました。 | | [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) | 変更 | バージョン7.1.0以降で有効となり、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を制御します。追加のテストを経て、デフォルト値を`"0s"`から`"1s"`に変更します。 | | [`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 認証における認証方法名を指定します。 | @@ -295,7 +295,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | PD | [`schedule.enable-diagnostic`](/pd-configuration-file.md#enable-diagnostic-new-in-v630) | 変更 | デフォルト値を`false`から`true`に変更します。これは、スケジューラの診断機能がデフォルトで有効であることを意味します。 | | TiFlash | `http_port` | 削除済み | HTTP サービス ポート (デフォルト`8123` ) を廃止します。 | | TiDB Lightning | [`tikv-importer.pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | TiDB LightningがPDスケジュールを一時停止する範囲を制御します。デフォルト値は`"table"`で、値のオプションは`"global"`と`"table"`です。 | -| TiDB Lightning | [`tikv-importer.region-check-backoff-limit`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | 分割および分散処理後にリージョンがオンラインになるまでの再試行回数を制御します。デフォルト値は`1800`です。最大再試行間隔は 2 秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。 | +| TiDB Lightning | [`tikv-importer.region-check-backoff-limit`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | 分割および分散処理後にリージョンがオンラインになるまでの再試行回数を制御します。デフォルト値は`1800`です。最大再試行間隔は 2秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。 | | TiDB Lightning | [`tikv-importer.region-split-batch-size`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | バッチでリージョンを分割する際のリージョン数を制御します。デフォルト値は`4096`です。 | | TiDB Lightning | [`tikv-importer.region-split-concurrency`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | リージョンを分割する際の同時実行を制御します。デフォルト値はCPUコアの数です。 | | TiCDC | [`insecure-skip-verify`](/ticdc/ticdc-sink-to-kafka.md) | 新しく追加された | Kafka にデータを複製するシナリオで TLS が有効になっている場合に認証アルゴリズムを設定するかどうかを制御します。 | @@ -439,7 +439,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiCDC タイムゾーン設定の問題を修正 [＃8798](https://github.com/pingcap/tiflow/issues/8798) @[Rustin170506](https://github.com/Rustin170506) - PDアドレスまたはリーダーに障害が発生したときにTiCDCが自動的に回復できない問題を修正[＃8812](https://github.com/pingcap/tiflow/issues/8812) [＃8877](https://github.com/pingcap/tiflow/issues/8877) @[asddongmen](https://github.com/asddongmen) - - 上流の TiKV ノードの 1 つがクラッシュするとチェックポイントの遅延が増加する問題を修正しました [＃8858](https://github.com/pingcap/tiflow/issues/8858) @[hicqu](https://github.com/hicqu) + - 上流の TiKV ノードの 1つがクラッシュするとチェックポイントの遅延が増加する問題を修正しました [＃8858](https://github.com/pingcap/tiflow/issues/8858) @[hicqu](https://github.com/hicqu) - オブジェクトストレージにデータを複製する際に、上流の`EXCHANGE PARTITION`操作が下流のに正しく複製されない問題を修正しました。 [＃8914](https://github.com/pingcap/tiflow/issues/8914) @[CharlesCheung96](https://github.com/CharlesCheung96) - いくつかの特殊なシナリオでソートコンポーネントの過剰なメモリ使用によって引き起こされる OOM 問題を修正しました[＃8974](https://github.com/pingcap/tiflow/issues/8974) @[hicqu](https://github.com/hicqu) - 下流の Kafka シンクがローリング再起動されたときに発生する TiCDC ノードpanicを修正しました[＃9023](https://github.com/pingcap/tiflow/issues/9023) @[asddongmen](https://github.com/asddongmen) diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index 6207f23b469a9..a0a90a7e41a13 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -81,7 +81,7 @@ TiDB バージョン: 7.1.2 - `GROUP_CONCAT` `ORDER BY`列を解析できない問題を修正 [＃41986](https://github.com/pingcap/tidb/issues/41986) @[AilinKid](https://github.com/AilinKid) - システムテーブル`INFORMATION_SCHEMA.TIKV_REGION_STATUS`をクエリすると、場合によっては誤った結果が返される問題を修正しました[＃45531](https://github.com/pingcap/tidb/issues/45531) @[Defined2014](https://github.com/Defined2014) - - メタデータの読み取りに 1 つの DDL リースよりも長い時間がかかる場合に TiDB のアップグレードが停止する問題を修正しました [＃45176](https://github.com/pingcap/tidb/issues/45176) @[zimulala](https://github.com/zimulala) + - メタデータの読み取りに 1つの DDL リースよりも長い時間がかかる場合に TiDB のアップグレードが停止する問題を修正しました [＃45176](https://github.com/pingcap/tidb/issues/45176) @[zimulala](https://github.com/zimulala) - CTE を含む DML 文を実行するとpanicが発生する問題を修正しました [＃46083](https://github.com/pingcap/tidb/issues/46083) @[winoros](https://github.com/winoros) - パーティション交換中にパーティション定義に準拠していないデータを検出できない問題を修正 [＃46492](https://github.com/pingcap/tidb/issues/46492) @[mjonss](https://github.com/mjonss) - `MERGE_JOIN`の結果が間違っている問題を修正[＃46580](https://github.com/pingcap/tidb/issues/46580) @[qw4990](https://github.com/qw4990) @@ -192,7 +192,7 @@ TiDB バージョン: 7.1.2 - CSV形式を使用するとTiCDCが誤って`UPDATE`演算を`INSERT`に変更する問題を修正 [＃9658](https://github.com/pingcap/tiflow/issues/9658) @[3AceShowHand](https://github.com/3AceShowHand) - アップストリームで同じDDL文で複数のテーブルの名前を変更するとレプリケーションエラーが発生する問題を修正 [＃9488](https://github.com/pingcap/tiflow/issues/9488) @[CharlesCheung96](https://github.com/CharlesCheung96) [＃9476](https://github.com/pingcap/tiflow/issues/9476) @[asddongmen](https://github.com/asddongmen) - Kafka に同期するときに再試行間隔が短いためにレプリケーションタスクが失敗する問題を修正しました [＃9504](https://github.com/pingcap/tiflow/issues/9504) @[3AceShowHand](https://github.com/3AceShowHand) - - アップストリームで 1 つのトランザクションで複数の行の一意のキーが変更されると、レプリケーション書き込み競合が発生する可能性がある問題を修正しました。 [＃9430](https://github.com/pingcap/tiflow/issues/9430) @[sdojjy](https://github.com/sdojjy) + - アップストリームで 1つのトランザクションで複数の行の一意のキーが変更されると、レプリケーション書き込み競合が発生する可能性がある問題を修正しました。 [＃9430](https://github.com/pingcap/tiflow/issues/9430) @[sdojjy](https://github.com/sdojjy) - ダウンストリームで短期的な障害が発生したときにレプリケーションタスクが停止する可能性がある問題を修正[＃9542](https://github.com/pingcap/tiflow/issues/9542) [＃9272](https://github.com/pingcap/tiflow/issues/9272) [＃9582](https://github.com/pingcap/tiflow/issues/9582) [＃9592](https://github.com/pingcap/tiflow/issues/9592) @[hicqu](https://github.com/hicqu) - ダウンストリームでエラーが発生し、 で再試行すると、レプリケーションタスクが停止する可能性がある問題を修正しました。 [＃9450](https://github.com/pingcap/tiflow/issues/9450) @[hicqu](https://github.com/hicqu) - Kafka にデータを複製するときに TiCDC が停止する可能性がある問題を修正しました [＃9855](https://github.com/pingcap/tiflow/issues/9855) @[hicqu](https://github.com/hicqu) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index 311b908843d1c..2c023854819da 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -87,7 +87,7 @@ TiDBバージョン: 7.1.4 - クエリに Apply 演算子が含まれており、 `fatal error: concurrent map writes`エラーが発生すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50347](https://github.com/pingcap/tidb/issues/50347) @[SeaRise](https://github.com/SeaRise) - 集計関数をグループ計算に使用すると発生する可能性のある`Can't find column ...`エラーを修正[＃50926](https://github.com/pingcap/tidb/issues/50926) @[qw4990](https://github.com/qw4990) - 定数伝播で`ENUM`または`SET`型を処理するときに TiDB が間違ったクエリ結果を返す問題を修正しました [＃49440](https://github.com/pingcap/tidb/issues/49440) @[winoros](https://github.com/winoros) - - 依存関係のある 2 つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) + - 依存関係のある 2つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) - `tidb_enable_prepared_plan_cache`システム変数が有効になってから無効になった後に`EXECUTE`ステートメントを使用して`PREPARE STMT`を実行すると、TiDB がpanicになる可能性がある問題を修正しました[＃49344](https://github.com/pingcap/tidb/issues/49344) @[qw4990](https://github.com/qw4990) - ネストされた`UNION`のクエリで`LIMIT`と`OPRDERBY`無効になる可能性がある問題を修正しました [＃49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [＃50067](https://github.com/pingcap/tidb/issues/50067) @[hawkingrei](https://github.com/hawkingrei) @@ -113,7 +113,7 @@ TiDBバージョン: 7.1.4 - TiKV - 例外的な状況で休止状態の領域がすぐに起動しない問題を修正[＃16368](https://github.com/tikv/tikv/issues/16368) @[LykxSassinator](https://github.com/LykxSassinator) - - ノードをオフラインにする前に、リージョン内のすべてのレプリカの最後のハートビート時間をチェックすることで、1 つのレプリカがオフラインになるとリージョン全体が使用できなくなる問題を修正しました[＃16465](https://github.com/tikv/tikv/issues/16465) @[tonyxuqqi](https://github.com/tonyxuqqi) + - ノードをオフラインにする前に、リージョン内のすべてのレプリカの最後のハートビート時間をチェックすることで、1つのレプリカがオフラインになるとリージョン全体が使用できなくなる問題を修正しました[＃16465](https://github.com/tikv/tikv/issues/16465) @[tonyxuqqi](https://github.com/tonyxuqqi) - Titan が有効になっているときに RocksDB に保存されるテーブルプロパティが不正確になる可能性がある問題を修正[＃16319](https://github.com/tikv/tikv/issues/16319) @[hicqu](https://github.com/hicqu) - クラスターにTiFlashノードがある場合に`tikv-ctl compact-cluster`実行が失敗する問題を修正しました [＃16189](https://github.com/tikv/tikv/issues/16189) @[frew](https://github.com/frew) - gRPC スレッドが`is_shutdown` をチェックしているときに TiKV がpanicする可能性がある問題を修正しました [＃16236](https://github.com/tikv/tikv/issues/16236) @[pingyu](https://github.com/pingyu) diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index f8a457058947b..8211556bcad91 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.1.6 ## 互換性の変更 {#compatibility-changes} -- [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.1/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を 2048 に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) +- [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.1/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を2048に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) - 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`目のイベントで主キーまたは非NULLの一意インデックス値が変更されると、TiCDCはこのイベントを`DELETE`目と`INSERT`目のイベントに分割していました。v7.1.6以降では、MySQLシンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS` TiCDC `thresholdTS` （TiCDCが対応するテーブルをダウンストリームに複製し始める際にPDから取得する現在のタイムスタンプ）より小さい場合、TiCDCは`UPDATE`件目のイベントを`DELETE`目と`INSERT`件目のイベントに分割します。この動作変更は、TiCDCが受信した`UPDATE`目のイベントの順序が誤っている可能性があり、その結果、分割された`DELETE`と`INSERT`目のイベントの順序が誤っている可能性があることで発生するダウンストリームデータの不整合の問題を解決します。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v7.1/ticdc-split-update-behavior#split-update-events-for-mysql-sinks) してください@[lidezhu](https://github.com/lidezhu) [＃10918](https://github.com/pingcap/tiflow/issues/10918) - TiDB Lightning `strict-format`を使用して CSV ファイルをインポートする場合は、行末文字を設定する必要があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) - TiKV構成項目[`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type)のスコープを変更します。 diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 669360cbc3c69..bcf3448a2ef32 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -19,7 +19,7 @@ TiDB バージョン: 7.2.0 ### パフォーマンス {#performance} -- TiFlash への次の 2 つの[ウィンドウ関数](/tiflash/tiflash-supported-pushdown-calculations.md)プッシュダウンをサポートします。 [#7427](https://github.com/pingcap/tiflash/issues/7427) @[xzhangxian1008](https://github.com/xzhangxian1008) +- TiFlash への次の2つの[ウィンドウ関数](/tiflash/tiflash-supported-pushdown-calculations.md)プッシュダウンをサポートします。 [#7427](https://github.com/pingcap/tiflash/issues/7427) @[xzhangxian1008](https://github.com/xzhangxian1008) - `FIRST_VALUE` - `LAST_VALUE` @@ -79,7 +79,7 @@ TiDB バージョン: 7.2.0 より適切な実行計画を生成するため、TiDB オプティマイザの動作は製品のバージョンアップごとに進化しています。しかし、特定のシナリオでは、変更によってパフォーマンスが低下する場合があります。TiDB v7.2.0 では、オプティマイザの細かい動作を制御できるオプティマイザ修正コントロールが導入されました。これにより、一部の新しい変更をロールバックしたり、制御したりすることが可能になります。 - 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザー修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1 つ以上の動作の目標値を設定できます。 + 制御可能な各動作は、修正番号に対応する GitHub の問題によって説明されます。制御可能な動作はすべてオプティマ[オプティマイザー修正コントロール](/optimizer-fix-controls.md)にリストされています。動作制御を実現するために[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)システム変数を設定することにより、1つ以上の動作の目標値を設定できます。 オプティマイザ修正制御メカニズムを使用すると、TiDBオプティマイザをきめ細かく制御できます。これにより、アップグレードプロセスによって発生するパフォーマンスの問題を修正する新しい手段が提供され、TiDBの安定性が向上します。 diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 7e08fb43b0a4a..79fbd8b7d2e7a 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.4.0 7.4.0 では、次の主な機能と改善が導入されています。 -
    カテゴリ特徴説明
    信頼性と可用性グローバルソートによるIMPORT INTOおよびADD INDEX操作のパフォーマンスと安定性を向上 (実験的) v7.4.0より前のバージョンでは、 TiDB Distributed eXecution Framework (DXF)を使用したADD INDEXやIMPORT INTOなどのタスクは、局所的かつ部分的なソートを意味しており、最終的にはTiKVが部分的なソートを補うために多くの追加作業を実行することになりました。また、これらのジョブを実行するには、TiDBノードがソート用のローカルディスク領域をTiKVにロードする前に割り当てる必要がありました。
    v7.4.0で導入されたグローバルソート機能により、データはTiKVにロードされる前に、グローバルソートのために外部共有ストレージ（このバージョンではS3）に一時的に保存されます。これにより、TiKVが余分なリソースを消費する必要がなくなり、 ADD INDEXやIMPORT INTOなどの操作のパフォーマンスと安定性が大幅に向上します。
    バックグラウンドタスクのリソース制御（実験的） v7.1.0では、ワークロード間のリソースおよびストレージアクセスの干渉を軽減するためのリソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクにも適用されます。v7.4.0では、自動分析、バックアップとリストア、 TiDB Lightningによるバルクロード、オンラインDDLなどのバックグラウンドタスクによって生成されるリソースをリソース制御が識別し、管理するようになりました。これは最終的にすべてのバックグラウンドタスクに適用されます。
    TiFlashは ストレージとコンピューティングの分離とS3 （GA）をサポートしますTiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 共有ストレージが一般提供開始:
    • TiFlash のコンピューティングとストレージを分離します。これは、弾力性のある HTAP リソース利用のマイルストーンとなります。
    • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンの使用をサポートします。
    SQL TiDBはパーティションタイプの管理をサポートv7.4.0 より前では、範囲/リスト パーティション テーブルは、 TRUNCATE 、 EXCHANGE 、 ADD 、 DROP 、 REORGANIZEなどのパーティション管理操作をサポートし、ハッシュ/キー パーティション テーブルは、 ADDやCOALESCEなどのパーティション管理操作をサポートします。

    現在、TiDB は次のパーティション タイプ管理操作もサポートしています。

    • パーティションテーブルを非パーティションテーブルに変換する
    • 既存のパーティション化されていないテーブルをパーティション化する
    • 既存のテーブルのパーティションタイプを変更する
    MySQL 8.0 互換性: 照合順序utf8mb4_0900_ai_ciサポートMySQL 8.0 の注目すべき変更点の 1 つは、デフォルトの文字セットが utf8mb4 になり、utf8mb4 のデフォルトの照合順序がutf8mb4_0900_ai_ciなったことです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行とレプリケーションがよりスムーズになりました。
    DB操作と可観測性IMPORT INTOおよびADD INDEX SQL ステートメントを実行するためのそれぞれの TiDB ノードを指定します (実験的) IMPORT INTOまたはADD INDEX SQL 文を、既存の TiDB ノードの一部、または新規に追加された TiDB ノードに対して実行するかどうかを柔軟に指定できます。このアプローチにより、他の TiDB ノードからのリソース分離が可能になり、業務への影響を防ぎながら、先行する SQL 文の実行に最適なパフォーマンスを確保できます。
    +
    カテゴリ特徴説明
    信頼性と可用性グローバルソートによるIMPORT INTOおよびADD INDEX操作のパフォーマンスと安定性を向上 (実験的) v7.4.0より前のバージョンでは、 TiDB Distributed eXecution Framework (DXF)を使用したADD INDEXやIMPORT INTOなどのタスクは、局所的かつ部分的なソートを意味しており、最終的にはTiKVが部分的なソートを補うために多くの追加作業を実行することになりました。また、これらのジョブを実行するには、TiDBノードがソート用のローカルディスク領域をTiKVにロードする前に割り当てる必要がありました。
    v7.4.0で導入されたグローバルソート機能により、データはTiKVにロードされる前に、グローバルソートのために外部共有ストレージ（このバージョンではS3）に一時的に保存されます。これにより、TiKVが余分なリソースを消費する必要がなくなり、 ADD INDEXやIMPORT INTOなどの操作のパフォーマンスと安定性が大幅に向上します。
    バックグラウンドタスクのリソース制御（実験的） v7.1.0では、ワークロード間のリソースおよびストレージアクセスの干渉を軽減するためのリソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクにも適用されます。v7.4.0では、自動分析、バックアップとリストア、 TiDB Lightningによるバルクロード、オンラインDDLなどのバックグラウンドタスクによって生成されるリソースをリソース制御が識別し、管理するようになりました。これは最終的にすべてのバックグラウンドタスクに適用されます。
    TiFlashは ストレージとコンピューティングの分離とS3 （GA）をサポートしますTiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 共有ストレージが一般提供開始:
    • TiFlash のコンピューティングとストレージを分離します。これは、弾力性のある HTAP リソース利用のマイルストーンとなります。
    • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンの使用をサポートします。
    SQL TiDBはパーティションタイプの管理をサポートv7.4.0 より前では、範囲/リスト パーティション テーブルは、 TRUNCATE 、 EXCHANGE 、 ADD 、 DROP 、 REORGANIZEなどのパーティション管理操作をサポートし、ハッシュ/キー パーティション テーブルは、 ADDやCOALESCEなどのパーティション管理操作をサポートします。

    現在、TiDB は次のパーティション タイプ管理操作もサポートしています。

    • パーティションテーブルを非パーティションテーブルに変換する
    • 既存のパーティション化されていないテーブルをパーティション化する
    • 既存のテーブルのパーティションタイプを変更する
    MySQL 8.0 互換性: 照合順序utf8mb4_0900_ai_ciサポートMySQL 8.0 の注目すべき変更点の 1つは、デフォルトの文字セットが utf8mb4 になり、utf8mb4 のデフォルトの照合順序がutf8mb4_0900_ai_ciなったことです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行とレプリケーションがよりスムーズになりました。
    DB操作と可観測性IMPORT INTOおよびADD INDEX SQL ステートメントを実行するためのそれぞれの TiDB ノードを指定します (実験的) IMPORT INTOまたはADD INDEX SQL 文を、既存の TiDB ノードの一部、または新規に追加された TiDB ノードに対して実行するかどうかを柔軟に指定できます。このアプローチにより、他の TiDB ノードからのリソース分離が可能になり、業務への影響を防ぎながら、先行する SQL 文の実行に最適なパフォーマンスを確保できます。
    ## 機能の詳細 {#feature-details} @@ -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 つの照合順序が追加されました。`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以前のバージョンからの移行やデータレプリケーションとの互換性が確保されます。 @@ -418,7 +418,7 @@ TiDB バージョン: 7.4.0 - PD のスケールアップおよびスケールダウン中に TiCDC が無効な古いアドレスにアクセスする問題を修正[＃9584](https://github.com/pingcap/tiflow/issues/9584) @[fubinzh](https://github.com/fubinzh) @[asddongmen](https://github.com/asddongmen) - 一部のシナリオでチェンジフィードが失敗する問題を修正[＃9309](https://github.com/pingcap/tiflow/issues/9309) [＃9450](https://github.com/pingcap/tiflow/issues/9450) [＃9542](https://github.com/pingcap/tiflow/issues/9542) [＃9685](https://github.com/pingcap/tiflow/issues/9685) @[hicqu](https://github.com/hicqu) @[CharlesCheung96](https://github.com/CharlesCheung96) - - アップストリームで 1 つのトランザクションで複数の行の一意のキーが変更されると、レプリケーション書き込み競合が発生する可能性がある問題を修正しました。 [＃9430](https://github.com/pingcap/tiflow/issues/9430) @[sdojjy](https://github.com/sdojjy) + - アップストリームで 1つのトランザクションで複数の行の一意のキーが変更されると、レプリケーション書き込み競合が発生する可能性がある問題を修正しました。 [＃9430](https://github.com/pingcap/tiflow/issues/9430) @[sdojjy](https://github.com/sdojjy) - アップストリームで同じDDL文で複数のテーブルの名前を変更するとレプリケーションエラーが発生する問題を修正 [＃9488](https://github.com/pingcap/tiflow/issues/9488) @[CharlesCheung96](https://github.com/CharlesCheung96) [＃9476](https://github.com/pingcap/tiflow/issues/9476) @[asddongmen](https://github.com/asddongmen) - CSVファイルで中国語の文字が検証されない問題を修正[＃9609](https://github.com/pingcap/tiflow/issues/9609) @[CharlesCheung96](https://github.com/CharlesCheung96) - すべての変更フィードが削除された後に上流の TiDB GC がブロックされる問題を修正[＃9633](https://github.com/pingcap/tiflow/issues/9633) @[sdojjy](https://github.com/sdojjy) diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index d17a753f0cfec..3d76eceb0da58 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.5.0 TiDB 7.5.0は長期サポートリリース（LTS）です。 -以前の LTS 7.1.0 と比較して、7.5.0 には[7.2.0-DMR](/releases/release-7.2.0.md) 、 [7.3.0-DMR](/releases/release-7.3.0.md) 、および[7.4.0-DMR](/releases/release-7.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。7.1.x から 7.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.2-to-v7.5-en-release-notes.pdf)をダウンロードして、2 つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、7.2.0 から 7.5.0 までのハイライトの一部を示しています。 +以前の LTS 7.1.0 と比較して、7.5.0 には[7.2.0-DMR](/releases/release-7.2.0.md) 、 [7.3.0-DMR](/releases/release-7.3.0.md) 、および[7.4.0-DMR](/releases/release-7.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。7.1.x から 7.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.2-to-v7.5-en-release-notes.pdf)をダウンロードして、2つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、7.2.0 から 7.5.0 までのハイライトの一部を示しています。
    カテゴリ特徴説明
    拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
    信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
    バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
    暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソース グループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソース グループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画 ダイジェストで識別できます。v7.3.0 では、データベース レベルの SQL ブロック リストと同様に、既知の不正なクエリを事前に監視できるようになりました。
    SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
    データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
    ADD INDEXおよびIMPORT INTO SQLステートメントを実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQLステートメントを実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQLステートメントの実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
    DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
    TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
    @@ -31,7 +31,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 - TiDB 分散実行フレームワーク (DXF) が一般提供 (GA) となり、 `ADD INDEX`および`IMPORT INTO`タスクの並列実行におけるパフォーマンスと安定性が向上しました [#45719](https://github.com/pingcap/tidb/issues/45719) @[wjhuang2016](https://github.com/wjhuang2016) - v7.1.0 で導入された DXF が GA になりました。TiDB v7.1.0 より前のバージョンでは、同時に実行できる TiDB ノードは 1 つだけでした。v7.1.0 以降では、DXF の下で複数の TiDB ノードが同じ DDL タスクを並列実行できます。v7.2.0 以降では、DXF は複数の TiDB ノードが同じ`IMPORT INTO`タスクを並列実行することをサポートし、TiDB クラスタのリソースをより有効に活用し、DDL および`IMPORT INTO`タスクのパフォーマンスを大幅に向上させます。さらに、TiDB ノードを増やすことで、これらのタスクのパフォーマンスを線形的に向上させることもできます。 + v7.1.0 で導入された DXF が GA になりました。TiDB v7.1.0 より前のバージョンでは、同時に実行できる TiDB ノードは 1つだけでした。v7.1.0 以降では、DXF の下で複数の TiDB ノードが同じ DDL タスクを並列実行できます。v7.2.0 以降では、DXF は複数の TiDB ノードが同じ`IMPORT INTO`タスクを並列実行することをサポートし、TiDB クラスタのリソースをより有効に活用し、DDL および`IMPORT INTO`タスクのパフォーマンスを大幅に向上させます。さらに、TiDB ノードを増やすことで、これらのタスクのパフォーマンスを線形的に向上させることもできます。 DXFを使用するには、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)値を`ON`に設定します。 diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index ad10e87c0d8ca..df98245a0c70d 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -108,7 +108,7 @@ TiDB バージョン: 7.5.1 - 集計関数をグループ計算に使用すると発生する可能性のある`Can't find column ...`エラーを修正[＃50926](https://github.com/pingcap/tidb/issues/50926) @[qw4990](https://github.com/qw4990) - 文字列型の変数に対する`SET_VAR`の制御が無効になる可能性がある問題を修正[＃50507](https://github.com/pingcap/tidb/issues/50507) @[qw4990](https://github.com/qw4990) - `tidb_server_memory_limit` による長期メモリ圧迫により TiDB の CPU 使用率が上昇する問題を修正 [＃48741](https://github.com/pingcap/tidb/issues/48741) @[XuHuaiyu](https://github.com/XuHuaiyu) - - 依存関係のある 2 つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) + - 依存関係のある 2つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [＃49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) - 無効なオプティマイザヒントによって有効なヒントが無効になる可能性がある問題を修正[＃49308](https://github.com/pingcap/tidb/issues/49308) @[hawkingrei](https://github.com/hawkingrei) - `CHECK`制約の DDL 文がスタックする問題を修正しました [＃47632](https://github.com/pingcap/tidb/issues/47632) @[jiyfhust](https://github.com/jiyfhust) - `CHECK`制約の`ENFORCED`オプションの動作がMySQL 8.0 と一致しない問題を修正 [＃47631](https://github.com/pingcap/tidb/issues/47631) @[jiyfhust](https://github.com/jiyfhust) [＃47567](https://github.com/pingcap/tidb/issues/47567) diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index 6f868a1911ce9..61747ffeff2cb 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -163,7 +163,7 @@ TiDB バージョン: 7.5.2 - 不安定なテストケースの問題を修正し、各テストが独立した一時ディレクトリを使用するようにして、オンライン構成の変更が他のテストケースに影響しないようにします。 [＃16871](https://github.com/tikv/tikv/issues/16871) @[glorv](https://github.com/glorv) - バイナリからJSON への変換中にTiKVがpanicする可能性がある問題を修正しました [＃16616](https://github.com/tikv/tikv/issues/16616) @[YangKeao](https://github.com/YangKeao) - tikv-ctlの`raft region`コマンドの出力にリージョンステータス情報が含まれていない問題を修正しました [＃17037](https://github.com/tikv/tikv/issues/17037) @[glorv](https://github.com/glorv) - - 1 つの TiKV ノードで遅い`check-leader`操作により、他の TiKV ノードの`resolved-ts`正常に進まなくなる問題を修正しました。 [＃15999](https://github.com/tikv/tikv/issues/15999) @[crazycs520](https://github.com/crazycs520) + - 1つの TiKV ノードで遅い`check-leader`操作により、他の TiKV ノードの`resolved-ts`正常に進まなくなる問題を修正しました。 [＃15999](https://github.com/tikv/tikv/issues/15999) @[crazycs520](https://github.com/crazycs520) - スナップショットの適用によってピアの破棄処理が中断された後、スナップショットの適用が完了しても再開されない問題を修正[＃16561](https://github.com/tikv/tikv/issues/16561) @[tonyxuqqi](https://github.com/tonyxuqqi) - `DECIMAL`型の小数点部分が場合に正しくない問題を修正しました [＃16913](https://github.com/tikv/tikv/issues/16913) @[gengliqi](https://github.com/gengliqi) - クエリ内の`CONV()`関数が数値システム変換中にオーバーフローし、TiKV panicが発生する問題を修正しました。 [＃16969](https://github.com/tikv/tikv/issues/16969) @[gengliqi](https://github.com/gengliqi) diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index b5c5f9deff1d8..2f12bb3f0523c 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.5.4 ## 互換性の変更 {#compatibility-changes} -- [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.5/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を 2048 に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) +- [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-7.5/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を2048に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @[joccau](https://github.com/joccau) ## 改善点 {#improvements} diff --git a/releases/release-7.5.5.md b/releases/release-7.5.5.md index 3286b2ee575cf..f9de1dd43aa7e 100644 --- a/releases/release-7.5.5.md +++ b/releases/release-7.5.5.md @@ -51,7 +51,7 @@ TiDB バージョン: 7.5.5 - DDL 所有者ノードが切り替えられた後、TiDB が以前の進行状況から再編成 DDL タスクを再開できない問題を修正しました。 [＃56506](https://github.com/pingcap/tidb/issues/56506) @[tangenta](https://github.com/tangenta) - 非厳密モードで無効な`NULL`値が挿入される問題を修正 ( `sql_mode = ''` ) [＃56381](https://github.com/pingcap/tidb/issues/56381) @[joechenrh](https://github.com/joechenrh) - Grafanaの**Stats Healthy Distribution**パネルのデータが正しくない可能性がある問題を修正しました[＃57176](https://github.com/pingcap/tidb/issues/57176) @[hawkingrei](https://github.com/hawkingrei) - - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1 つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @[windtalker](https://github.com/windtalker) + - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @[windtalker](https://github.com/windtalker) - v6.5からv7.5以降にアップグレードされたクラスターで、既存のTTLタスクが予期せず頻繁に実行される問題を修正[＃56539](https://github.com/pingcap/tidb/issues/56539) @[lcwangchao](https://github.com/lcwangchao) - `tidb_ttl_job_enable`変数が無効になった後、TTL タスクがキャンセルされない問題を修正[＃57404](https://github.com/pingcap/tidb/issues/57404) @[YangKeao](https://github.com/YangKeao) - 情報スキーマキャッシュミスにより、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 [＃53428](https://github.com/pingcap/tidb/issues/53428) @[crazycs520](https://github.com/crazycs520) diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index 1194ab2380028..dcf7947b3ce30 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -77,7 +77,7 @@ TiDB バージョン: 8.1.2 - 整数型の列に小さい表示幅を指定すると`out of range`エラーが発生する可能性がある問題を修正しました。 [＃55837](https://github.com/pingcap/tidb/issues/55837) @[windtalker](https://github.com/windtalker) - `LOAD DATA ... REPLACE INTO`操作でデータの不整合が発生する問題を修正[＃56408](https://github.com/pingcap/tidb/issues/56408) @[fzzf678](https://github.com/fzzf678) - `columnEvaluator`入力チャンク内の列参照を識別できず、SQL 文を実行すると`runtime error: index out of range`が発生する問題を修正しました。 [＃53713](https://github.com/pingcap/tidb/issues/53713) @[AilinKid](https://github.com/AilinKid) - - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1 つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @[windtalker](https://github.com/windtalker) + - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @[windtalker](https://github.com/windtalker) - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正[＃56511](https://github.com/pingcap/tidb/issues/56511) @[lcwangchao](https://github.com/lcwangchao) - `IMPORT INTO`文を使用して一時テーブルをインポートするときに TiDB がパニックになる問題を修正しました [＃55970](https://github.com/pingcap/tidb/issues/55970) @[D3Hunter](https://github.com/D3Hunter) - クエリ条件`column IS NULL` で一意インデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 [＃56116](https://github.com/pingcap/tidb/issues/56116) @[hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index c936075280be5..12e2989f04e5c 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -273,8 +273,8 @@ v8.4.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 -- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024年 6月 30日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 +- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024年 6月 30日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。 ## 削除された機能 {#removed-features} @@ -312,7 +312,7 @@ TiDB をアップグレードする前に、オペレーティング システ - 多数の列を持つテーブルをクエリする際のパフォーマンスを向上させるため、内部関数のロジックを最適化します [#52112](https://github.com/pingcap/tidb/issues/52112) @[Rustin170506](https://github.com/Rustin170506) - `a = 1 AND (a > 1 OR (a = 1 AND b = 2))`から`a = 1 AND b = 2`のようなフィルター条件を簡素化 [#56005](https://github.com/pingcap/tidb/issues/56005) @[ghazalfamilyusa](https://github.com/ghazalfamilyusa) - 最適ではない実行計画のリスクが高いシナリオでは、コストモデルでテーブルスキャンのコストを増やし、オプティマイザがインデックスを優先するようにします [#56012](https://github.com/pingcap/tidb/issues/56012) @[terry1purcell](https://github.com/terry1purcell) - - TiDB は 2 つの引数を持つバリアント`MID(str, pos)`をサポートしています [#52420](https://github.com/pingcap/tidb/issues/52420) @[dveeden](https://github.com/dveeden) + - TiDB は 2つの引数を持つバリアント`MID(str, pos)`をサポートしています [#52420](https://github.com/pingcap/tidb/issues/52420) @[dveeden](https://github.com/dveeden) - バイナリ型以外の主キーを持つテーブルのTTLタスクの分割をサポート [#55660](https://github.com/pingcap/tidb/issues/55660) @[lcwangchao](https://github.com/lcwangchao) - システムのメタデータ関連ステートメントのパフォーマンスを最適化する [#50305](https://github.com/pingcap/tidb/issues/50305) @[ywqzzy](https://github.com/ywqzzy) @[tangenta](https://github.com/tangenta)@[joechenrh](https://github.com/joechenrh) @[CbcWestwolf](https://github.com/CbcWestwolf) - 自動分析操作に新しい優先度キューを実装して、分析パフォーマンスを向上させ、キューの再構築コストを削減します [#55906](https://github.com/pingcap/tidb/issues/55906) @[Rustin170506](https://github.com/Rustin170506) @@ -412,7 +412,7 @@ TiDB をアップグレードする前に、オペレーティング システ - TiDB Lightning - - TiDB Lightning が、2 つのインスタンスが同時に並列インポートタスクを開始し、同じタスク ID が割り当てられた場合、 `verify allocator base failed`エラーを報告する問題を修正しました [#55384](https://github.com/pingcap/tidb/issues/55384) @[ei-sugimoto](https://github.com/ei-sugimoto) + - TiDB Lightning が、2つのインスタンスが同時に並列インポートタスクを開始し、同じタスク ID が割り当てられた場合、 `verify allocator base failed`エラーを報告する問題を修正しました [#55384](https://github.com/pingcap/tidb/issues/55384) @[ei-sugimoto](https://github.com/ei-sugimoto) ## 貢献者 {#contributors} diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 2d6de2fb39db8..1f44e16c401c4 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -15,7 +15,7 @@ TiDB バージョン: 8.5.0 TiDB 8.5.0は長期サポートリリース（LTS）です。 -以前の LTS 8.1.0 と比較して、8.5.0 には[8.2.0-DMR](/releases/release-8.2.0.md) 、 [8.3.0-DMR](/releases/release-8.3.0.md) 、および[8.4.0-DMR](/releases/release-8.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。8.1.x から 8.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v8.2-to-v8.5-en-release-notes.pdf)をダウンロードして、2 つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、8.1.0 から 8.5.0 までのハイライトの一部を示しています。 +以前の LTS 8.1.0 と比較して、8.5.0 には[8.2.0-DMR](/releases/release-8.2.0.md) 、 [8.3.0-DMR](/releases/release-8.3.0.md) 、および[8.4.0-DMR](/releases/release-8.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。8.1.x から 8.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v8.2-to-v8.5-en-release-notes.pdf)をダウンロードして、2つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、8.1.0 から 8.5.0 までのハイライトの一部を示しています。
    カテゴリ機能／改善点説明
    拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減するTiDBは、パフォーマンス向上のためにデータ処理を継続的に改良し、金融分野における低遅延SQL処理の要件を効果的に満たしています。主なアップデート内容は以下のとおりです。
    TiKV MVCC インメモリエンジン (IME) (バージョン8.5.0で導入) TiKV MVCCのインメモリエンジンは、最新のMVCCバージョンのデータをメモリにキャッシュすることで、古いバージョンをスキップして最新のデータを迅速に取得できるようにします。この機能は、データレコードが頻繁に更新される場合や、履歴バージョンが長期間保持される場合に、データスキャン性能を大幅に向上させることができます。
    アクティブなPDフォロワーを使用して、PDのリージョン情報クエリサービスを強化します（v8.5.0で一般提供開始）。 TiDB v7.6.0 では、実験的機能「アクティブ PDFollower」が導入されました。これにより、PD フォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数の TiDB ノードとリージョンを持つクラスターにおいて、PD クラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PD リーダーの CPU 負荷を軽減します。この機能は、v8.5.0 で一般提供 (GA) されます。
    インスタンスレベルの実行プランキャッシュ（実験的、v8.4.0で導入）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
    パーティションテーブルのグローバルインデックス（バージョン8.4.0で一般提供開始）グローバルインデックスは、パーティション化されていない列の取得効率を効果的に向上させ、一意キーにパーティションキーを含める必要があるという制約を取り除きます。この機能により、TiDBパーティションテーブルの利用シナリオが拡張され、パーティションテーブルのパフォーマンスが向上し、特定のクエリシナリオにおけるリソース消費量が削減されます。
    Projection演算子をストレージエンジンにデフォルトでプッシュダウンする機能（v8.3.0で導入） Projection演算子をストレージエンジンにプッシュダウンすることで、ストレージノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
    統計情報を収集する際に不要な列を無視する機能（バージョン8.3.0で導入）オプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行計画の選択を保証し、クラスタのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
    信頼性と可用性大規模クラスターの安定性を向上させるTiDBを使用してマルチテナントアプリケーションやSaaSアプリケーションを運用する企業は、多くの場合、大量のテーブルを保存する必要があります。バージョン8.5.0では、TiDBは大規模クラスタの安定性を大幅に向上させました。
    暴走クエリに対するトリガーの追加サポート、およびリソースグループの切り替えサポート（v8.4.0で導入）暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
    リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポート（実験的、v8.4.0で導入）リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
    TiProxyのユースケースを強化および拡張するTiDBの高可用性を実現する上で重要なコンポーネントであるTiProxyは、SQLトラフィックのアクセスと転送にとどまらず、クラスタ変更の評価をサポートする機能も備えています。主な機能は以下のとおりです。
    TiDBの並列HashAggアルゴリズムはディスクスピルをサポートしています（v8.2.0でGA対応）。 HashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリ パフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
    SQL外部キー（バージョン8.5.0でGA対応）外部キーは、データベースにおける制約であり、テーブル間の関係を確立し、データの一貫性と整合性を確保します。外部キーは、子テーブルで参照されるデータが親テーブルに存在することを保証し、無効なデータの挿入を防ぎます。また、外部キーはカスケード操作（削除や更新時の自動同期など）をサポートし、ビジネスロジックの実装を簡素化し、データ関係を手動で維持する複雑さを軽減します。
    ベクトル検索（実験的、v8.4.0で導入）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
    データベースの運用と可観測性TiKVおよびTiDBのCPU時間をメモリテーブルに表示する（バージョン8.4.0で導入） CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
    TiKVのCPU時間をテーブル別またはデータベース別に集計して表示する機能をサポート（v8.4.0で導入）ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
    Backup & Restore (BR)は、 AWS SDK for Rustを使用して外部ストレージにアクセスします (v8.5.0 で導入)。 BRは、TiKVからAmazon S3などの外部ストレージにアクセスするために、元のRusotoライブラリをAWS SDK for Rustに置き換えます。この変更により、 IMDSv2やEKS Pod IdentityなどのAWS機能との互換性が向上します。
    Securityスナップショットバックアップデータおよびログバックアップデータのクライアント側暗号化（v8.5.0で一般提供開始）バックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
    @@ -51,7 +51,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 - TiKV は MVCC インメモリ エンジン (IME) をサポートしており、広範な MVCC 履歴バージョンのスキャンを伴うクエリを高速化します [#16141](https://github.com/tikv/tikv/issues/16141) @[SpadeA-Tang](https://github.com/SpadeA-Tang)@[glorv](https://github.com/glorv)@[overvenus](https://github.com/overvenus) - レコードが頻繁に更新される場合、または TiDB が履歴バージョンを長期間 (例えば 24 時間) 保持する必要がある場合、MVCC バージョンの蓄積によりスキャン パフォーマンスが低下する可能性があります。TiKV の MVCC インメモリ エンジンは、最新の MVCC バージョンをメモリにキャッシュし、高速な GC メカニズムを使用して履歴バージョンをメモリから削除することで、スキャン パフォーマンスを向上させます。 + レコードが頻繁に更新される場合、または TiDB が履歴バージョンを長期間 (例えば 24時間) 保持する必要がある場合、MVCC バージョンの蓄積によりスキャン パフォーマンスが低下する可能性があります。TiKV の MVCC インメモリ エンジンは、最新の MVCC バージョンをメモリにキャッシュし、高速な GC メカニズムを使用して履歴バージョンをメモリから削除することで、スキャン パフォーマンスを向上させます。 バージョン8.5.0以降、TiKVはMVCCインメモリエンジンを導入しました。TiKVクラスタ内でMVCCバージョンが蓄積され、スキャンパフォーマンスが低下する場合は、TiKV構成パラメータ[`in-memory-engine.enable`](/tikv-in-memory-engine.md#usage)を設定することで、TiKV MVCCインメモリエンジンを有効にしてスキャンパフォーマンスを向上させることができます。 @@ -144,8 +144,8 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 -- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタをバージョン 8.4.0 以降にアップグレードすると、クラスタが利用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)によると、CentOS Linux 7 のアップストリームサポートは 2024年 6月 30日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024年 6月 30日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタをバージョン 8.4.0 以降にアップグレードすると、クラスタが利用できなくなります。 ## 削除された機能 {#removed-features} diff --git a/releases/release-8.5.5.md b/releases/release-8.5.5.md index 5bfb21bd3a75b..7383f52ecd0f5 100644 --- a/releases/release-8.5.5.md +++ b/releases/release-8.5.5.md @@ -23,7 +23,7 @@ TiDBバージョン：8.5.5 - データ切り捨てのリスクが検出されない場合、TiDBはメタデータのみを更新し、可能な限りインデックスの再構築を回避します。 - インデックスの再構築が必要な場合、TiDBはより効率的な取り込みプロセスを使用することで、インデックス再構築のパフォーマンスを大幅に向上させます。 - 以下の表は、114 GiB のデータと 6 億行のデータを含むテーブルに対するベンチマーク テストに基づいたパフォーマンス改善の例を示しています。テスト クラスタは、3 つの TiDB ノード、6 つの TiKV ノード、および 1 つの PD ノードで構成されています。すべてのノードは、16 個の CPU コアと 32 GiB のメモリで構成されています。 + 以下の表は、114 GiB のデータと 6 億行のデータを含むテーブルに対するベンチマーク テストに基づいたパフォーマンス改善の例を示しています。テスト クラスタは、3つの TiDB ノード、6つの TiKV ノード、および 1つの PD ノードで構成されています。すべてのノードは、16 個の CPU コアと 32 GiB のメモリで構成されています。 | シナリオ | 操作タイプ | 最適化前 | 最適化後 | パフォーマンスの向上 | | --------- | ------------------------- | ------ | ------ | ---------- | diff --git a/releases/release-8.5.6.md b/releases/release-8.5.6.md index 543758efa171e..e2e2f219f0dbd 100644 --- a/releases/release-8.5.6.md +++ b/releases/release-8.5.6.md @@ -39,7 +39,7 @@ TiDBバージョン：8.5.6 バージョン 8.5.6 より前では、TiDB でスロークエリを識別する主な方法は、 [`tidb_slow_log_threshold`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_threshold)システム変数を設定することでした。このメカニズムはインスタンスレベルでグローバルに適用されるため、スロークエリログのトリガーを大まかにしか制御できず、セッションレベルや SQL レベルでのきめ細かい制御はサポートされていません。さらに、トリガー条件として実行時間 ( `Query_time` ) しかサポートしていないため、複雑なシナリオでスロークエリログをより正確にキャプチャする必要性を満たすことができません。 - バージョン 8.5.6 以降、TiDB はスロークエリログの制御を強化しました。[`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) システム変数を使用して、`Query_time`、`Digest`、`Mem_max`、`KV_total` などの条件に基づいて、インスタンス、セッション、SQL の各レベルで多次元のスロークエリログ出力ルールを定義できます。[`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856) を使用して、1 秒あたりに書き込まれるログエントリの数を制限したり、[`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints) ヒントを使用して、特定の SQL ステートメントに対してスロークエリログを強制的に記録したりできます。これにより、スロークエリログをより柔軟かつきめ細かく制御できます。 + バージョン 8.5.6 以降、TiDB はスロークエリログの制御を強化しました。[`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) システム変数を使用して、`Query_time`、`Digest`、`Mem_max`、`KV_total` などの条件に基づいて、インスタンス、セッション、SQL の各レベルで多次元のスロークエリログ出力ルールを定義できます。[`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856) を使用して、1秒あたりに書き込まれるログエントリの数を制限したり、[`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints) ヒントを使用して、特定の SQL ステートメントに対してスロークエリログを強制的に記録したりできます。これにより、スロークエリログをより柔軟かつきめ細かく制御できます。 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/identify-slow-queries)を参照してください。 @@ -127,7 +127,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - インデックスプレフィックス列に対する`IN`述語を含むクエリのプラン選択を改善します。TiDB は`ORDER BY ... LIMIT`クエリの順序を保持するためにマージソートを使用できるようになり、不要なスキャンを削減してパフォーマンスを向上させます。 [#63449](https://github.com/pingcap/tidb/issues/63449) [#34882](https://github.com/pingcap/tidb/issues/34882) @[time-and-fate](https://github.com/time-and-fate) - 表示できないプリペアドステートメント引数を16進数として出力することで、スロークエリログの可読性を向上させる [#65383](https://github.com/pingcap/tidb/issues/65383) @[dveeden](https://github.com/dveeden) - - `cluster_id`を`mysql.tidb`に追加し、外部ツールが 2 つの TiDB インスタンスが同じクラスターに属しているかどうかを判断できるようにします [#59476](https://github.com/pingcap/tidb/issues/59476) @[YangKeao](https://github.com/YangKeao) + - `cluster_id`を`mysql.tidb`に追加し、外部ツールが 2つの TiDB インスタンスが同じクラスターに属しているかどうかを判断できるようにします [#59476](https://github.com/pingcap/tidb/issues/59476) @[YangKeao](https://github.com/YangKeao) - TiKV @@ -185,7 +185,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - ログバックアップで`flush_ts`が`0`になる可能性がある問題を修正 [#19406](https://github.com/tikv/tikv/issues/19406) @[YuJuncen](https://github.com/YuJuncen) - Amazon S3互換APIを介してS3スタイルの認証情報を使用してGoogle Cloud Storageにアクセスする際、Content-Lengthヘッダーが欠落しているため、マルチパートアップロード中にBRが失敗する可能性がある問題を修正しました。 [#19352](https://github.com/tikv/tikv/issues/19352) @[Leavrth](https://github.com/Leavrth) - - BR `restore point` `waiting for schema info finishes reloading`の状態に長時間留まり、15 分後にタイムアウトで失敗する問題を修正しました [#66110](https://github.com/pingcap/tidb/issues/66110) @[kennytm](https://github.com/kennytm) + - BR `restore point` `waiting for schema info finishes reloading`の状態に長時間留まり、15分後にタイムアウトで失敗する問題を修正しました [#66110](https://github.com/pingcap/tidb/issues/66110) @[kennytm](https://github.com/kennytm) - `SHARD_ROW_ID_BITS` 、 `PRE_SPLIT_REGIONS`BRを持つテーブルを復元する際に、 `merge_option`問題を修正します。 [#65060](https://github.com/pingcap/tidb/issues/65060) @[JoyC-dev](https://github.com/JoyC-dev) - TiCDC diff --git a/releases/release-8.5.7.md b/releases/release-8.5.7.md index c29a6d79c21d3..326fe8d275bf2 100644 --- a/releases/release-8.5.7.md +++ b/releases/release-8.5.7.md @@ -27,9 +27,9 @@ TiDB version: 8.5.7 ### 信頼性 {#reliability} -* 単一ユーザーが 1 つの TiDB インスタンス上で確立できる接続数の制限をサポート [#59203](https://github.com/pingcap/tidb/issues/59203) @[joccau](https://github.com/joccau) +* 単一ユーザーが 1つの TiDB インスタンス上で確立できる接続数の制限をサポート [#59203](https://github.com/pingcap/tidb/issues/59203) @[joccau](https://github.com/joccau) - v8.5.7 以降、`max_user_connections` システム変数を使用して、単一ユーザーが単一の TiDB サーバーインスタンスに対して確立できる最大接続数を制限できます。これにより、1 人のユーザーによる過剰な [token](https://docs.pingcap.com/tidb/v8.5/tidb-configuration-file#token-limit) 消費によって、他のユーザーからのリクエストへの応答が遅延する状況を防ぐのに役立ちます。 + v8.5.7 以降、`max_user_connections` システム変数を使用して、単一ユーザーが単一の TiDB サーバーインスタンスに対して確立できる最大接続数を制限できます。これにより、1人のユーザーによる過剰な [token](https://docs.pingcap.com/tidb/v8.5/tidb-configuration-file#token-limit) 消費によって、他のユーザーからのリクエストへの応答が遅延する状況を防ぐのに役立ちます。 さらに、`CREATE USER` および `ALTER USER` 文で `WITH MAX_USER_CONNECTIONS N` を使用して、対応するユーザーが確立できる最大接続数を制限できます。 @@ -198,7 +198,7 @@ v8.5.6 で新規にデプロイされた TiDB クラスター（つまり、以 + PD - - PD のメンテナンス用エンドポイントと `pd-ctl` コマンドを追加し、TiKV のメンテナンスタスクを直列化できるようにしました。これにより、一度に 1 つのメンテナンスタスクのみを有効にして Raft クォーラム喪失を防ぎます。[#9477](https://github.com/tikv/pd/issues/9477) @[SerjKol80](https://github.com/SerjKol80) @[HaoW30](https://github.com/HaoW30) + - PD のメンテナンス用エンドポイントと `pd-ctl` コマンドを追加し、TiKV のメンテナンスタスクを直列化できるようにしました。これにより、一度に 1つのメンテナンスタスクのみを有効にして Raft クォーラム喪失を防ぎます。[#9477](https://github.com/tikv/pd/issues/9477) @[SerjKol80](https://github.com/SerjKol80) @[HaoW30](https://github.com/HaoW30) -リージョン分割後の予期しないスケジューリングを避けるため、PD で split scatter をデフォルトで無効にしました。引き続き `schedule.split-scatter-schedule-limit` を正の値に設定することで有効化できます。[#10592](https://github.com/tikv/pd/issues/10592) @[lhy1024](https://github.com/lhy1024) - unsafe recovery の empty-region プラン生成を最適化し、多数のリージョンとギャップを持つ大規模クラスターでパフォーマンスを向上し、タイムアウトリスクを低減しました。[#10638](https://github.com/tikv/pd/issues/10638) @[Connor1996](https://github.com/Connor1996) - PD のトランザクション継続時間メトリクスを改善し、本番環境のレイテンシー分布をより適切に反映できるようにして、ダッシュボードとアラートでの可観測性を向上しました。[#10705](https://github.com/tikv/pd/issues/10705) @[bufferflies](https://github.com/bufferflies) @@ -302,7 +302,7 @@ v8.5.6 で新規にデプロイされた TiDB クラスター（つまり、以 - 高並行時に token bucket が過剰なトークンを蓄積し、PD の resource control rate limiting が弱くなる可能性がある問題を修正しました。[#10744](https://github.com/tikv/pd/issues/10744) @[YuhaoZhang00](https://github.com/YuhaoZhang00) - token bucket 通知タイマーのリセット時に発生する resource group client controller の goroutine リークを修正しました。[#9745](https://github.com/tikv/pd/issues/9745) @[lhy1024](https://github.com/lhy1024) - - 設定された RU fill rate が実際の RU 消費量より大幅に高い場合に、resource group への SQL リクエストで約 1 秒のレイテンシースパイクが発生する問題を修正しました。[#10251](https://github.com/tikv/pd/issues/10251) @[JmPotato](https://github.com/JmPotato) + - 設定された RU fill rate が実際の RU 消費量より大幅に高い場合に、resource group への SQL リクエストで約1秒のレイテンシースパイクが発生する問題を修正しました。[#10251](https://github.com/tikv/pd/issues/10251) @[JmPotato](https://github.com/JmPotato) - 配置ルールで要求される最高分離レベルが満たされていない場合でも、PD の affinity scheduling がリージョンを適切にレプリケート済みと見なしてしまい、誤ったレプリカ配置判断につながる可能性がある問題を修正しました。[#10149](https://github.com/tikv/pd/issues/10149) @[HunDunDM](https://github.com/HunDunDM) - Region heartbeat breakdown メトリクスがホストの monotonic clock の一時的な逆行に遭遇した際に、`counter cannot decrease in value` エラーを引き起こす可能性がある PD の panic を修正しました。[#10901](https://github.com/tikv/pd/issues/10901) @[JmPotato](https://github.com/JmPotato) - affinity group が設定されていない場合に、PD が affinity checker operator limit メトリクスを誤って報告する問題を修正しました。[#10687](https://github.com/tikv/pd/issues/10687) @[lhy1024](https://github.com/lhy1024) @@ -368,7 +368,7 @@ v8.5.6 で新規にデプロイされた TiDB クラスター（つまり、以 - 頻繁な DDL を伴う syncpoint 有効ワークロードで、重複する block status リクエストの処理に TiCDC が過剰な時間を費やし、maintainer slow log や barrier 処理遅延を引き起こす問題を修正しました。[#4957](https://github.com/pingcap/ticdc/issues/4957) @[hongyunyan](https://github.com/hongyunyan) - etcd クラスターのメンバーシップ変更後に、TiCDC `cli changefeed list` が異なるクラスターの changefeed を表示する可能性がある問題を修正しました。[#5137](https://github.com/pingcap/ticdc/issues/5137) @[wk989898](https://github.com/wk989898) - シャットダウン中にタスクが送信または再スケジュールされた際に、TiCDC のスレッドプールのシャットダウンがハングする可能性がある問題を修正しました。[#4640](https://github.com/pingcap/ticdc/issues/4640) @[wk989898](https://github.com/wk989898) - - dispatcher の `WAITING` ステータスが maintainer によって一時的に無視された場合に、`CREATE TABLE ... LIKE ...` などの一部の DDL で TiCDC が barrier を進める前に約 5 秒待機する問題を修正しました。[#4810](https://github.com/pingcap/ticdc/issues/4810) @[zier-one](https://github.com/zier-one) + - dispatcher の `WAITING` ステータスが maintainer によって一時的に無視された場合に、`CREATE TABLE ... LIKE ...` などの一部の DDL で TiCDC が barrier を進める前に約5秒待機する問題を修正しました。[#4810](https://github.com/pingcap/ticdc/issues/4810) @[zier-one](https://github.com/zier-one) - 多数の changefeed を一時停止して再開した後に、TiCDC の changefeed のラグが増加し CPU 使用率が高くなる問題を修正しました。[#4653](https://github.com/pingcap/ticdc/issues/4653) @[lidezhu](https://github.com/lidezhu) - ソーステーブルのスキーマが明示的に指定されていない場合に、TiCDC がデータベース間の `CREATE TABLE ... LIKE` ステートメントをレプリケートできない問題を修正しました。[#5025](https://github.com/pingcap/ticdc/issues/5025) @[lidezhu](https://github.com/lidezhu) - ビュー定義で修飾されていないソーステーブル名が使用されている場合に、TiCDC がスキーマ間の `CREATE VIEW` ステートメントを誤ってレプリケートし、下流のレプリケーションが失敗したりビューが誤ったテーブルを参照したりする可能性がある問題を修正しました。[#5026](https://github.com/pingcap/ticdc/issues/5026) @[lidezhu](https://github.com/lidezhu) diff --git a/releases/release-pre-ga.md b/releases/release-pre-ga.md index 58f56a6780928..710c8c96b3595 100644 --- a/releases/release-pre-ga.md +++ b/releases/release-pre-ga.md @@ -5,7 +5,7 @@ summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは # プレGAリリースノート {#pre-ga-release-notes} -2017 年 8 月 30 日に、TiDB Pre-GA がリリースされました。このリリースでは、MySQL の互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 +2017年 8月 30日に、TiDB Pre-GA がリリースされました。このリリースでは、MySQL の互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 ## TiDB {#tidb} @@ -36,4 +36,4 @@ summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは - 述語プッシュダウンを実装する - 集約プッシュダウンを実装する - 範囲プルーニングを実装する -- ビューのサポートを必要とする 1 つのクエリを除いて、TPC+H のフルセットを実行可能 +- ビューのサポートを必要とする 1つのクエリを除いて、TPC+H のフルセットを実行可能 diff --git a/releases/release-rc.3.md b/releases/release-rc.3.md index 975aa608fb03a..ebdc7039922e1 100644 --- a/releases/release-rc.3.md +++ b/releases/release-rc.3.md @@ -5,7 +5,7 @@ summary: 2017年6月16日にリリースされたTiDB RC3は、MySQLとの互換 # TiDB RC3 リリースノート {#tidb-rc3-release-notes} -2017 年 6 月 16 日に、TiDB RC3 がリリースされました。このリリースでは、MySQL の互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 +2017年 6月 16日に、TiDB RC3 がリリースされました。このリリースでは、MySQL の互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 ## ハイライト {#highlight} diff --git a/releases/release-rc.4.md b/releases/release-rc.4.md index 8d80e818b5d29..f431ecda77a33 100644 --- a/releases/release-rc.4.md +++ b/releases/release-rc.4.md @@ -5,7 +5,7 @@ summary: TiDB RC4は、MySQLとの互換性、SQLの最適化、安定性、パ # TiDB RC4 リリースノート {#tidb-rc4-release-notes} -2017 年 8 月 4 日に、TiDB RC4 がリリースされました。このリリースでは、MySQL の互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 +2017年 8月 4日に、TiDB RC4 がリリースされました。このリリースでは、MySQL の互換性、SQL の最適化、安定性、パフォーマンスに重点を置いています。 ## ハイライト {#highlight} @@ -53,4 +53,4 @@ summary: TiDB RC4は、MySQLとの互換性、SQLの最適化、安定性、パ - 予測プッシュダウンを実装する - 集約プッシュダウンを実装する - 範囲プルーニングを実装する -- ビューのサポートを必要とする 1 つのクエリを除いて、TPC-H のフルセットを実行可能 +- ビューのサポートを必要とする 1つのクエリを除いて、TPC-H のフルセットを実行可能 diff --git a/releases/versioning.md b/releases/versioning.md index 7a17931567595..4151232d47b2c 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -11,7 +11,7 @@ summary: TiDB のバージョン番号付けシステムについて学習しま -TiDB には 2 つのリリース シリーズがあります。 +TiDB には 2つのリリース シリーズがあります。 - 長期サポートリリース - 開発マイルストーンリリース（TiDB v6.0.0 で導入） @@ -49,7 +49,7 @@ LTS のライフサイクル中は、パッチリリースがオンデマンド -v5.1.0、v5.2.0、v5.3.0、v5.4.0 は、前のリリースからわずか 2 か月後にリリースされましたが、4 つのリリースはすべて LTS であり、パッチ リリースが提供されます。 +v5.1.0、v5.2.0、v5.3.0、v5.4.0 は、前のリリースからわずか 2 か月後にリリースされましたが、4つのリリースはすべて LTS であり、パッチ リリースが提供されます。 diff --git a/replicate-between-primary-and-secondary-clusters.md b/replicate-between-primary-and-secondary-clusters.md index 558504e897a4a..40f25a63ab316 100644 --- a/replicate-between-primary-and-secondary-clusters.md +++ b/replicate-between-primary-and-secondary-clusters.md @@ -17,7 +17,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー 1. TiDBクラスタをデプロイ。 - TiUP Playground を使用して、2 つの TiDB クラスター (1 つはアップストリーム、もう 1 つはダウンストリーム)をデプロイ。本番環境の場合は、 [TiUPを使用してオンラインTiDBクラスタをデプロイおよび管理](/tiup/tiup-cluster.md)を参照してクラスターをデプロイします。 + TiUP Playground を使用して、2つの TiDB クラスター (1つはアップストリーム、もう 1つはダウンストリーム)をデプロイ。本番環境の場合は、 [TiUPを使用してオンラインTiDBクラスタをデプロイおよび管理](/tiup/tiup-cluster.md)を参照してクラスターをデプロイします。 このドキュメントでは、2台のマシンに2つのクラスターをデプロイします。 diff --git a/replicate-data-to-kafka.md b/replicate-data-to-kafka.md index 478d3542ffaf5..9ec035792ee37 100644 --- a/replicate-data-to-kafka.md +++ b/replicate-data-to-kafka.md @@ -70,7 +70,7 @@ summary: TiCDC を使用して TiDB データを Apache Kafka および Apache F - コマンドを実行した後に結果が返されない場合は、コマンドを実行したサーバーとシンク URI で指定された Kafka マシン間のネットワーク接続を確認してください。 - 本番環境では、Kafka クラスターには複数のブローカーノードが存在します。そのため、シンク UIR に複数のブローカーのアドレスを追加できます。これにより、Kafka クラスターへの安定したアクセスが確保されます。Kafka クラスターがダウンした場合でも、変更フィードは引き続き機能します。Kafka クラスターに 3 つのブローカーノードがあり、IP アドレスがそれぞれ 127.0.0.1:9092、127.0.0.2:9092、127.0.0.3:9092 であるとします。この場合、次のシンク URI で変更フィードを作成できます。 + 本番環境では、Kafka クラスターには複数のブローカーノードが存在します。そのため、シンク UIR に複数のブローカーのアドレスを追加できます。これにより、Kafka クラスターへの安定したアクセスが確保されます。Kafka クラスターがダウンした場合でも、変更フィードは引き続き機能します。Kafka クラスターに 3つのブローカーノードがあり、IP アドレスがそれぞれ 127.0.0.1:9092、127.0.0.2:9092、127.0.0.3:9092 であるとします。この場合、次のシンク URI で変更フィードを作成できます。 ```shell tiup cdc:v cli changefeed create --server="http://127.0.0.1:8300" --sink-uri="kafka://127.0.0.1:9092,127.0.0.2:9092,127.0.0.3:9092/kafka-topic-name?protocol=canal-json&partition-num=3&replication-factor=1&max-message-bytes=1048576" --config="changefeed.conf" diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md index 2c649f22a9d91..aeaec16ae892e 100644 --- a/resources/doc-templates/template-concept.md +++ b/resources/doc-templates/template-concept.md @@ -54,7 +54,7 @@ xxx > > 一般的なヒントや注意事項については、注記を参照してください。例えば、履歴データを読み込む際、現在のテーブル構造が履歴データのテーブル構造と異なっていても、その時点の履歴データのテーブル構造で履歴データが返されます。 -注釈または警告がリスト内にネストされている場合は、4 つのスペースでインデントします。 +注釈または警告がリスト内にネストされている場合は、4つのスペースでインデントします。 誤った表示を防ぐため、PingCAP Web サイトのすべてのインデントは 4 スペースにする必要があります。 diff --git a/resources/doc-templates/template-new-feature.md b/resources/doc-templates/template-new-feature.md index 29dbc963580c0..7843c9590ee56 100644 --- a/resources/doc-templates/template-new-feature.md +++ b/resources/doc-templates/template-new-feature.md @@ -29,7 +29,7 @@ summary: このドキュメントを115～145文字で要約してください > > 情報によってシステムの可用性、セキュリティ、データ損失などのリスクがユーザーにもたらされる可能性がある場合は、警告を使用します。 -注釈または警告がリスト内にネストされている場合は、4 つのスペースでインデントします。 +注釈または警告がリスト内にネストされている場合は、4つのスペースでインデントします。 誤った表示を防ぐため、 **PingCAP Web サイトのすべてのインデントは 4 スペースにする必要があります。** diff --git a/resources/doc-templates/template-reference.md b/resources/doc-templates/template-reference.md index ba7f299462dec..e007fc493100d 100644 --- a/resources/doc-templates/template-reference.md +++ b/resources/doc-templates/template-reference.md @@ -47,7 +47,7 @@ xxx > > 一般的なヒントや注意事項については、注記を参照してください。例えば、履歴データを読み込む際、現在のテーブル構造が履歴データのテーブル構造と異なっていても、その時点の履歴データのテーブル構造で履歴データが返されます。 -注釈または警告がリスト内にネストされている場合は、4 つのスペースでインデントします。 +注釈または警告がリスト内にネストされている場合は、4つのスペースでインデントします。 誤った表示を防ぐため、PingCAP Web サイトのすべてのインデントは 4 スペースにする必要があります。 diff --git a/resources/doc-templates/template-task.md b/resources/doc-templates/template-task.md index 69603f9c5c017..6df6cc99e4d13 100644 --- a/resources/doc-templates/template-task.md +++ b/resources/doc-templates/template-task.md @@ -27,7 +27,7 @@ summary: このドキュメントを115～145文字で要約してください 1. xxx - この手順を説明する場合は、**スペースを 4 つ**インデントし、この段落の前に空白行を残します。 + この手順を説明する場合は、**スペースを 4つ**インデントし、この段落の前に空白行を残します。 **注釈**や**警告**を使用する必要がある場合は、次の形式で注釈を記述します。 @@ -39,13 +39,13 @@ summary: このドキュメントを115～145文字で要約してください > > 一般的なヒントや注意事項については、注記を使用してください。例えば、「履歴データを読み込む際、現在のテーブル構造が履歴データのテーブル構造と異なっていても、その時点の履歴データのテーブル構造で履歴データが返されます。」などです。 - 注釈または警告がリスト内にネストされている場合は、4 つのスペースでインデントします。 + 注釈または警告がリスト内にネストされている場合は、4つのスペースでインデントします。 誤った表示を防ぐため、PingCAP Web サイトのすべてのインデントは 4 スペースにする必要があります。 2. xxx - コード ブロックを使用する場合は、4 つのスペースをインデントし、ブロックの前に空白行を残します。 + コード ブロックを使用する場合は、4つのスペースをインデントし、ブロックの前に空白行を残します。 ```bash # command @@ -61,7 +61,7 @@ summary: このドキュメントを115～145文字で要約してください 3. xxx - リスト内に別のリストをネストする場合は、順序付きリスト (1、2、3、…) または順序なしリスト (*/+/-) を使用し、4 つのスペースでインデントします。 + リスト内に別のリストをネストする場合は、順序付きリスト (1、2、3、…) または順序なしリスト (*/+/-) を使用し、4つのスペースでインデントします。 1. サブステップ1 2. サブステップ2 diff --git a/resources/markdownlint-rules.md b/resources/markdownlint-rules.md index 9e9b12734891b..1f25f9c4e0edd 100644 --- a/resources/markdownlint-rules.md +++ b/resources/markdownlint-rules.md @@ -18,7 +18,7 @@ PRを送信する前に関連するMarkdownルールをよく理解しておら | :--- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | [MD001 - 見出しレベルは一度に1レベルずつ増加する必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md001---heading-levels-should-only-increment-by-one-level-at-a-time) | 見出しは第1レベルから開始する必要があります。複数の見出しレベルを使用する場合は、どのレベルも飛ばさないでください。例えば、第1レベルの見出しの直下に第3レベルの見出しを使用することはできません。また、第2レベルの見出しの直下に第4レベルの見出しを使用することはできません。 | | 2 | [MD003 - 見出しスタイル](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md003---heading-style) | 見出しは ATX スタイルで記述する必要があります。つまり、 `#`文字を使用して見出しレベルを指定します。 | -| 3 | [MD018 - ATX 形式の見出しのハッシュの後にスペースを入れないでください](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md018---no-space-after-hash-on-atx-style-heading) | `#`文字と見出しテキストの間には**1 つのスペース**を追加する必要があります。 | +| 3 | [MD018 - ATX 形式の見出しのハッシュの後にスペースを入れないでください](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md018---no-space-after-hash-on-atx-style-heading) | `#`文字と見出しテキストの間には**1つのスペース**を追加する必要があります。 | | 4 | [MD019 - ATX 形式の見出しのハッシュの後に複数のスペースがある](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md019---multiple-spaces-after-hash-on-atx-style-heading) | `#`文字と見出しテキストの間には**スペースを1つ**だけ追加できます。複数のスペースを追加することはできません。 | | 5 | [MD023 - 見出しは行の先頭から始まる必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md023---headings-must-start-at-the-beginning-of-the-line) | 見出しは行頭から始まる必要があります。見出しの`#`文字より前にスペースは挿入されません。 | | 6 | [MD026 - 見出しの末尾の句読点](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md026---trailing-punctuation-in-heading) | 見出しの末尾には、疑問符`?` 、バックティック`` ` `` 、二重引用符`"` 、一重引用符`'`といった特定の句読点のみを使用できます。コロン`:` 、コンマ`,` 、ピリオド`.` 、感嘆符`!`といったその他の句読点は、見出しの末尾には使用できません。 | @@ -31,7 +31,7 @@ PRを送信する前に関連するMarkdownルールをよく理解しておら | 13 | [MD012 - 連続する複数の空白行](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md012---multiple-consecutive-blank-lines) | 連続する複数の空白行は許可されません。 | | 14 | [MD027 - 引用符の後の複数のスペース](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md027---multiple-spaces-after-blockquote-symbol) | ブロック引用記号`>`の後に複数のスペースを入れることはできません。スペースは**1つ**だけ使用でき、その後に引用文を続けます。 | | 15 | [MD029 - 順序付きリスト項目の接頭辞](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md029---ordered-list-item-prefix) | 順序付きリストを使用する場合、項目のプレフィックスは`1.`から始まり、数値順に増加する必要があります。 | -| 16 | [MD030 - リストマーカーの後のスペース](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md030---spaces-after-list-markers) | リストを使用すると、リスト マーカー ( `+` 、または`*` ) とリスト項目のテキストの間に**スペースが 1 つ**`-`追加されます。 | +| 16 | [MD030 - リストマーカーの後のスペース](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md030---spaces-after-list-markers) | リストを使用すると、リスト マーカー ( `+` 、または`*` ) とリスト項目のテキストの間に**スペースが 1つ**`-`追加されます。 | | 17 | [MD032 - リストは空白行で囲む必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md032---lists-should-be-surrounded-by-blank-lines) | リスト (あらゆる種類) の前後には空白行が必要です。 | | 18 | [MD031 - 囲まれたコードブロックは空白行で囲む必要があります](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md031---fenced-code-blocks-should-be-surrounded-by-blank-lines) | コード ブロックの前後には空白行が必要です。 | | 19 | [MD034 - ベアURLが使用されている](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#md034---bare-url-used) | ドキュメント内ではURLそのものの使用は許可されていません。ユーザーがURLを直接クリックして開くようにしたい場合は、URLを山括弧で囲んでください（ `` ）。特別な状況下でURLそのものを使用する必要がある場合、ユーザーがクリックして開く必要がない場合は、URLをバッククォートで囲んでください（ `` `URL` `` ）。 | diff --git a/resources/tidb-pdf-generation-tutorial.md b/resources/tidb-pdf-generation-tutorial.md index 99a7b0987d9ac..dffcd8444630a 100644 --- a/resources/tidb-pdf-generation-tutorial.md +++ b/resources/tidb-pdf-generation-tutorial.md @@ -9,11 +9,11 @@ summary: 特定のシナリオのニーズに合わせて、TiDB ドキュメン ## 環境の準備 {#environment-preparation} -次の準備手順は、PDF ファイルを初めて生成するときに 1 回だけ実行する必要があり、今後の PDF 生成では直接スキップできます。 +次の準備手順は、PDF ファイルを初めて生成するときに 1回だけ実行する必要があり、今後の PDF 生成では直接スキップできます。 ### 準備1: Docker環境のインストールと設定 {#preparation-1-install-and-configure-the-docker-environment} -> 推定所要時間: 30 分。 +> 推定所要時間: 30分。 次の手順では、Docker Desktop のインストールとして macOS または Windows を例に説明します。 @@ -37,7 +37,7 @@ summary: 特定のシナリオのニーズに合わせて、TiDB ドキュメン ### 準備2: TiDBドキュメントリポジトリをローカルディスクにクローンする {#preparation-2-clone-the-tidb-documentation-repository-to-your-local-disk} -> 推定所要時間: 10 分。 +> 推定所要時間: 10分。 TiDB 英語ドキュメントリポジトリ: [https://github.com/pingcap/docs](https://github.com/pingcap/docs) ; TiDB 中国語ドキュメントリポジトリ: [https://github.com/pingcap/docs-cn](https://github.com/pingcap/docs-cn) @@ -68,7 +68,7 @@ TiDB 英語ドキュメントリポジトリ: [https://github.com/pingcap/docs]( ## 手順 {#steps} -> 推定時間: 以下の操作には 2 分しかかかりませんが、PDF の生成には 0.5 ～ 1 時間かかります。 +> 推定時間: 以下の操作には 2分しかかかりませんが、PDF の生成には 0.5 ～ 1時間かかります。 1. ローカルの TiDB ドキュメント リポジトリ内のファイルが、アップストリーム GitHub リポジトリの最新バージョンであることを確認します。 @@ -77,7 +77,7 @@ TiDB 英語ドキュメントリポジトリ: [https://github.com/pingcap/docs]( 1. ローカル リポジトリのルート ディレクトリにある`TOC.md`ファイルを開きます。 2. `TOC.md`ファイルを編集します。例えば、不要なドキュメントの章のタイトルとリンクをすべて削除できます。 -3. `TOC.md`ファイルに従って、すべてのドキュメントの章を 1 つの Markdown ファイルに統合します。 +3. `TOC.md`ファイルに従って、すべてのドキュメントの章を 1つの Markdown ファイルに統合します。 1. Docker アプリケーションを起動します。 diff --git a/role-based-access-control.md b/role-based-access-control.md index 581cbc90e4086..85d3f5609af6c 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -314,13 +314,13 @@ REVOKE INSERT, UPDATE, DELETE ON app_db.* FROM 'app_write'; DROP ROLE 'app_read', 'app_write'; ``` -この操作により、 `mysql.user`テーブル内の`app_read`と`app_write`ロール レコードと、承認テーブル内の関連レコードが削除され、2 つのロールに関連する承認が終了します。 +この操作により、 `mysql.user`テーブル内の`app_read`と`app_write`ロール レコードと、承認テーブル内の関連レコードが削除され、2つのロールに関連する承認が終了します。 ロールを削除するには、 `DROP ROLE`または`DROP USER`権限が必要です。 ### 承認テーブル {#authorization-table} -4 つのシステム[権限テーブル](/privilege-management.md#privilege-table)に加えて、RBAC システムでは 2 つの新しいシステム権限テーブルが導入されています。 +4つのシステム[権限テーブル](/privilege-management.md#privilege-table)に加えて、RBAC システムでは 2つの新しいシステム権限テーブルが導入されています。 - `mysql.role_edges` : ロールとユーザーの承認関係を記録します。 - `mysql.default_roles` : 各ユーザーのデフォルトのロールを記録します。 diff --git a/runtime-filter.md b/runtime-filter.md index e741700970b8b..17a8a1bbda11c 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -76,7 +76,7 @@ WHERE ss_date_sk = d_date_sk *(RFはランタイムフィルターの略です)* -上記 2 つの図から、スキャンされるデータ量が`store_sales`で 100 万から 5000 に削減されていることがわかります。スキャンされるデータ量を`TableFullScan`削減することで、Runtime Filter はハッシュ テーブルとの照合回数を削減し、不要な I/O とネットワーク転送を回避できるため、結合操作の効率が大幅に向上します。 +上記 2つの図から、スキャンされるデータ量が`store_sales`で 100 万から 5000 に削減されていることがわかります。スキャンされるデータ量を`TableFullScan`削減することで、Runtime Filter はハッシュ テーブルとの照合回数を削減し、不要な I/O とネットワーク転送を回避できるため、結合操作の効率が大幅に向上します。 ## ランタイムフィルターを使用する {#use-runtime-filter} @@ -93,7 +93,7 @@ ALTER TABLE catalog_sales SET tiflash REPLICA 1; ALTER TABLE date_dim SET tiflash REPLICA 1; ``` -2 つのテーブルのTiFlashレプリカが準備されるまで、つまりレプリカの`AVAILABLE`フィールドと`PROGRESS`フィールドが両方とも`1`なるまで待機します。 +2つのテーブルのTiFlashレプリカが準備されるまで、つまりレプリカの`AVAILABLE`フィールドと`PROGRESS`フィールドが両方とも`1`なるまで待機します。 ```sql SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA WHERE TABLE_NAME='catalog_sales'; @@ -222,7 +222,7 @@ EXPLAIN ANALYZE SELECT cs_ship_date_sk FROM catalog_sales, date_dim 9 rows in set (0.17 sec) ``` -2 つのクエリの実行情報を比較すると、次の改善点がわかります。 +2つのクエリの実行情報を比較すると、次の改善点がわかります。 - IO 削減: TableFullScan 演算子の`total_scanned_rows`比較すると、ランタイム フィルターを有効にすると`TableFullScan`のスキャン量が 2/3 削減されることがわかります。 - ハッシュ結合のパフォーマンス向上: `HashJoin`演算子の実行時間が 376.1 ミリ秒から 157.6 ミリ秒に短縮されました。 diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index 4071b50ac8ca8..627940770b5fc 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -194,7 +194,7 @@ tiup cluster display ## PD動作モードを切り替える {#switch-the-pd-working-mode} -PD サービスを次の 2 つの動作モード間で切り替えることができます。 +PD サービスを次の2つの動作モード間で切り替えることができます。 - 通常モード: PD ノードのみでルーティング サービス、タイムスタンプ割り当て、およびクラスター スケジューリング関数を提供します。 - マイクロサービスモード：PDタイムスタンプ割り当て機能をTSOノード（ `tso`マイクロサービスを提供）に、クラスタースケジューリング機能をスケジューリングノード（ `scheduling`マイクロサービスを提供）にそれぞれ個別にデプロイできます。これにより、これら2つの関数はPDのルーティング機能から分離され、PDノードはメタデータのルーティングサービスに集中できます。 diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index eae103493a0b0..07d89d9f6bea0 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -201,7 +201,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する ## TiCDC クラスターをスケールアウトする {#scale-out-a-ticdc-cluster} -このセクションでは、ホスト`10.0.1.3`と`10.0.1.4`に 2 つの TiCDC ノードを追加する方法を例で説明します。 +このセクションでは、ホスト`10.0.1.3`と`10.0.1.4`に 2つの TiCDC ノードを追加する方法を例で説明します。 1. `scale-out.yml`ファイルにノード情報を追加します。 diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index e012aa289c1be..409ad3501f101 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -23,9 +23,9 @@ TiUPを使用してクラスターをデプロイする場合、 [初期化設 以下の例では、2層トポロジ（ `zone/host` ）が定義されています。クラスターのTiDBノード、TiKVノード、およびTiFlashノードは、3つのゾーン（z1、z2、z3）に分散されています。 -- 各ゾーンには、TiDB インスタンスがデプロイされているホストが 2 つあり、各ホストには個別の TiDB インスタンスがデプロイされています。 +- 各ゾーンには、TiDB インスタンスがデプロイされているホストが 2つあり、各ホストには個別の TiDB インスタンスがデプロイされています。 - 各ゾーンには、TiKVインスタンスがデプロイされたホストが2つあります。z1では、各ホストに2つのTiKVインスタンスがデプロイされています。z2とz3では、各ホストに個別のTiKVインスタンスがデプロイされています。 -- 各ゾーンには、 TiFlashインスタンスがデプロイされているホストが 2 つあり、各ホストには個別のTiFlashインスタンスがデプロイされています。 +- 各ゾーンには、 TiFlashインスタンスがデプロイされているホストが 2つあり、各ホストには個別のTiFlashインスタンスがデプロイされています。 次の例では、 `tidb-host-machine-n` `n`番目の TiDB ノードの IP アドレスを表し、 `tikv-host-machine-n` `n`番目の TiKV ノードの IP アドレスを表し、 `tiflash-host-machine-n` `n`番目のTiFlashノードの IP アドレスを表します。 @@ -275,9 +275,9 @@ PD はラベルレイヤーに従ってレプリカをスケジュールし、 次に、クラスタレプリカの数が5（ `max-replicas=5` ）であると仮定します。ゾーンは合計3つしかないため、PDはゾーンレベルで各レプリカの分離を保証することができません。この場合、PDスケジューラはホストレベルでレプリカの分離を保証します。つまり、リージョンの複数のレプリカが同じゾーンに分散されていても、同じホスト上には分散されていない可能性があります。 -5 つのレプリカ構成の場合、z3 に障害が発生するか、z3 全体が分離され、一定期間 ( `max-store-down-time`で制御) 後に回復できない場合、PD はスケジュールによって 5 つのレプリカを構成します。この時点では、使用できるホストは 4 つだけです。つまり、ホストレベルの分離は保証されず、複数のレプリカが同じホストにスケジュールされる可能性があります。ただし、 `isolation-level`値が空のままではなく`zone`に設定されている場合、これはリージョンレプリカの最小の物理的な分離要件を指定します。つまり、PD は同じリージョンのレプリカが異なるゾーンに分散されていることを保証します。この分離制限に従っても、複数のレプリカの`max-replicas`の要件が満たされない場合でも、PD は対応するスケジュールを実行しません。 +5つのレプリカ構成の場合、z3 に障害が発生するか、z3 全体が分離され、一定期間 ( `max-store-down-time`で制御) 後に回復できない場合、PD はスケジュールによって 5つのレプリカを構成します。この時点では、使用できるホストは 4つだけです。つまり、ホストレベルの分離は保証されず、複数のレプリカが同じホストにスケジュールされる可能性があります。ただし、 `isolation-level`値が空のままではなく`zone`に設定されている場合、これはリージョンレプリカの最小の物理的な分離要件を指定します。つまり、PD は同じリージョンのレプリカが異なるゾーンに分散されていることを保証します。この分離制限に従っても、複数のレプリカの`max-replicas`の要件が満たされない場合でも、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`設定が`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 は同じゾーン内の同じラックに異なるレプリカがスケジュールされることを避けようとします。`host` `isolation-level`設定した場合も同様にスケジューリングが行われ、PD はまずラックの分離レベルを保証し、次にホストの分離レベルを保証します。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index faf375251f4c2..262323ac19041 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -148,7 +148,7 @@ The support for TLS authentication is configured differently. For detailed infor JWT consists of three parts: Header, Payload, and Signature. After being encoded using base64, they are concatenated into a string separated by dots (`.`) for transmission between the client and server. -ヘッダーには、3 つのパラメータを含む JWT のメタデータが記述されます。 +ヘッダーには、3つのパラメータを含む JWT のメタデータが記述されます。 - `alg` : 署名のアルゴリズム。デフォルトは`RS256`です。 - `typ` : トークンの種類 ( `JWT` )。 diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index 5a6ad558e35c8..633ffea1aa906 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -11,7 +11,7 @@ Starting from v7.1.0, when you upgrade TiDB to a later version, TiDB supports sm ## サポートされているバージョン {#supported-versions} -機能がスイッチによって制御される必要があるかどうかに応じて、スムーズ アップグレードを使用する方法は 2 つあります。 +機能がスイッチによって制御される必要があるかどうかに応じて、スムーズ アップグレードを使用する方法は 2つあります。 - この機能はデフォルトで有効になっており、スイッチによる制御は不要です。現在、この方法をサポートしているバージョンはv7.1.0、v7.1.1、v7.2.0、v7.3.0です。具体的には、以下のバージョンがサポートされています。 - Upgrade from v7.1.0 to v7.1.1, v7.2.0, or v7.3.0 @@ -98,7 +98,7 @@ You can take the following steps to upgrade TiDB manually or by using a script: - BR: BRは一時停止中のDDLジョブをTiDBに複製する可能性があります。一時停止中のDDLジョブは自動的に再開できないため、後でDDLジョブが停止する可能性があります。 - - DM および TiCDC: アップグレード プロセス中に DM または TiCDC を使用して SQL ステートメントを TiDB にインポートする場合、SQL ステートメントの 1 つに DDL 操作が含まれていると、インポート操作がブロックされ、未定義のエラーが発生する可能性があります。 + - DM および TiCDC: アップグレード プロセス中に DM または TiCDC を使用して SQL ステートメントを TiDB にインポートする場合、SQL ステートメントの 1つに DDL 操作が含まれていると、インポート操作がブロックされ、未定義のエラーが発生する可能性があります。 ### プラグインの制限 {#limitation-on-plugins} diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index d228a3b1e1777..50ab9a5c30573 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -44,7 +44,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache SET tidb_enable_non_prepared_plan_cache = ON; ``` -3. 次の 2 つのクエリを実行します。 +3. 次の2つのクエリを実行します。 ```sql SELECT * FROM t WHERE b < 10 AND a = 1; @@ -82,7 +82,7 @@ TiDBは、パラメータ化されたクエリに対して1つのプランのみ - [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でサポートされていないクエリまたはプランは、非プリペアドプラン キャッシュでもサポートされません。 - `Window`や`Having`などの複雑な演算子を含むクエリはサポートされていません。 -- 3 つ以上の`Join`テーブルまたはサブクエリを含むクエリはサポートされていません。 +- 3つ以上の`Join`テーブルまたはサブクエリを含むクエリはサポートされていません。 - `ORDER BY 1`や`GROUP BY a+1`など、 `ORDER BY`または`GROUP BY`直後に数字や式が含まれるクエリはサポートされていません`ORDER BY column_name`と`GROUP BY column_name`のみがサポートされています。 - `SELECT * FROM t WHERE json_col = '{}'`など、 `JSON` 、 `ENUM` 、 `SET` 、または`BIT`タイプの列でフィルタリングするクエリはサポートされていません。 - `SELECT * FROM t WHERE a is NULL`など、 `NULL`値でフィルタリングするクエリはサポートされていません。 @@ -160,7 +160,7 @@ SHOW warnings; SET @@tidb_enable_non_prepared_plan_cache=ON; ``` -3. 次の 3 つのクエリを実行します。 +3. 次の3つのクエリを実行します。 ```sql SELECT * FROM t WHERE a<1; diff --git a/sql-plan-management.md b/sql-plan-management.md index ac33e40b9f926..9b3d67ea245bc 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -84,7 +84,7 @@ USING > > `SELECT`サブクエリを持つ`INSERT` / `REPLACE`文の実行プランバインディングを作成する場合、バインドするオプティマイザヒントを`INSERT` / `REPLACE`キーワードの後ではなく、`SELECT`サブクエリに指定する必要があります。そうしないと、オプティマイザヒントは意図したとおりに機能しません。 -ここに 2 つの例を示します。 +ここに 2つの例を示します。 ```sql -- The hint takes effect in the following statement. @@ -124,7 +124,7 @@ SELECT * FROM bookshop . users WHERE balance > ? > SELECT * FROM bookshop . books WHERE type IN ( ... ) > ``` > -> 正規化後、長さの異なる`IN`述語が同じステートメントとして認識されるため、これらすべての述語に適用される 1 つのバインディングを作成するだけで済みます。 +> 正規化後、長さの異なる`IN`述語が同じステートメントとして認識されるため、これらすべての述語に適用される 1つのバインディングを作成するだけで済みます。 > > 例えば： > @@ -547,7 +547,7 @@ SHOW GLOBAL BINDINGS; クロスデータベースバインディングの作成構文は標準バインディングと異なりますが、削除構文とステータス変更構文は同じです。以下に詳細な使用例を示します。 -1. データベース`db1`と`db2`を作成し、各データベースに 2 つのテーブルを作成します。 +1. データベース`db1`と`db2`を作成し、各データベースに 2つのテーブルを作成します。 ```sql CREATE DATABASE db1; @@ -799,8 +799,7 @@ CREATE GLOBAL BINDING for SELECT * FROM t WHERE a < 100 AND b < 100 USING SELECT ベースライン進化により新しいバインディングが自動的に作成されるため、クエリ環境が変更されると、自動的に作成されたバインディングの動作が複数選択される場合があります。以下の点にご注意ください。 -- ベースライン進化では、少なくとも 1 つのグローバル バインディングを持つ正規化された SQL ステートメントのみが進化します。 - +- ベースライン進化では、少なくとも 1つのグローバル バインディングを持つ正規化された SQL ステートメントのみが進化します。 - 新しいバインディングを作成すると、以前のバインディングがすべて削除されるため (正規化された SQL ステートメントの場合)、新しいバインディングを手動で作成すると、自動的に進化したバインディングは削除されます。 - 計算プロセスに関連するすべてのヒントは、進化の間も保持されます。これらのヒントは以下の通りです。 diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index b77baf6124464..51d3349149790 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -196,7 +196,7 @@ TiDBの実行計画を特定する場合、対象となるSQL文と実行計画 - 対象となるSQL文と対象実行計画のダイジェストを事前にTiDBクラスタに登録し、対象クエリとのマッチングを開始します。 - ターゲット クエリが正常に一致すると、そのオプティマイザー関連の情報を直接キャプチャし、ZIP ファイルとしてエクスポートします。 -- 一致した SQL と実行計画ごとに、情報は 1 回だけキャプチャされます。 +- 一致した SQL と実行計画ごとに、情報は 1回だけキャプチャされます。 - システム テーブルを通じて、進行中の一致するタスクと生成されたファイルを表示します。 - 履歴ファイルを定期的にクリーンアップします。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index b00cac29df87a..3cc544b53df65 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -10,7 +10,7 @@ TiDBは、 `Prepare`と`Execute`クエリの実行計画のキャッシュをサ - プロトコル機能`COM_STMT_PREPARE`および`COM_STMT_EXECUTE`使用。 - SQL ステートメント`PREPARE`と`EXECUTE`を使用します。 -TiDB オプティマイザーは、これら 2 種類のクエリを同じ方法で処理します。準備時に、パラメータ化されたクエリは AST (抽象構文ツリー) に解析され、キャッシュされます。その後の実行時に、保存された AST と特定のパラメータ値に基づいて実行計画が生成されます。 +TiDB オプティマイザーは、これら2種類のクエリを同じ方法で処理します。準備時に、パラメータ化されたクエリは AST (抽象構文ツリー) に解析され、キャッシュされます。その後の実行時に、保存された AST と特定のパラメータ値に基づいて実行計画が生成されます。 実行プランキャッシュが有効な場合、最初の実行では、各`Prepare`ごとに現在のクエリが実行プランキャッシュを使用できるかどうかが確認され、使用できる場合は、生成された実行計画がLRU（Least Recently Used）リンクリストで実装されたキャッシュに格納されます。後続の`Execute`クエリでは、キャッシュから実行計画が取得され、その可用性が確認されます。確認が成功した場合、実行計画生成のステップはスキップされます。そうでない場合は、実行計画が再生成され、キャッシュに保存されます。 @@ -55,7 +55,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで - 実行計画は、キャッシュされているかどうかに関わらず、SQLバインディングの影響を受けます。キャッシュされていない実行計画（最初の`Execute` ）は、既存のSQLバインディングの影響を受けます。キャッシュされている実行計画は、新しいSQLバインディングが作成されると無効になります。 - キャッシュされたプランは、統計、最適化ルール、式によるブロックリストのプッシュダウンの変更の影響を受けません。 -- `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2 つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行計画を生成しません。 +- `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行計画を生成しません。 - キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行計画が生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行計画を生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`を使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行計画が比較的固定されているアプリケーション シナリオに適しています。 バージョン6.1.0以降、実行プランキャッシュはデフォルトで有効になっています。プリペアドプランキャッシュはシステム変数[`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)を介して制御できます。 @@ -289,7 +289,7 @@ ERROR 1105 (HY000): Do not support the 'admin flush global scope.' ## `COM_STMT_CLOSE`コマンドと`DEALLOCATE PREPARE`ステートメントを無視します。 {#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement} -SQL ステートメントの構文解析コストを削減するには、 `prepare stmt` 1 回実行し、次に`execute stmt`複数回実行してから`deallocate prepare`を実行することをお勧めします。 +SQL ステートメントの構文解析コストを削減するには、 `prepare stmt` 1回実行し、次に`execute stmt`複数回実行してから`deallocate prepare`を実行することをお勧めします。 ```sql MySQL [test]> prepare stmt from '...'; -- Prepare once @@ -354,6 +354,6 @@ TiDBページの**Executor**セクションの[Grafanaダッシュボード](/gr -[TiDB Cloudコンソール](https://tidbcloud.com/)の[**監視**](/tidb-cloud/built-in-monitoring.md)ページで`Queries Using Plan Cache OPS`メトリックをチェックして、すべての TiDB インスタンスで 1 秒あたりにプランキャッシュを使用している、またはプランキャッシュがないクエリの数を取得できます。 +[TiDB Cloudコンソール](https://tidbcloud.com/)の[**監視**](/tidb-cloud/built-in-monitoring.md)ページで`Queries Using Plan Cache OPS`メトリックをチェックして、すべての TiDB インスタンスで 1秒あたりにプランキャッシュを使用している、またはプランキャッシュがないクエリの数を取得できます。 diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index 5b89f9bacd5b4..241698b32cf39 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -10,7 +10,7 @@ category: reference -[チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 +[チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2つのテーブルでは、チェックサムは異なります。 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `が実行されます。 @@ -18,7 +18,7 @@ category: reference -[チェックサム](https://docs.pingcap.com/tidb/stable/tidb-lightning-glossary#checksum)テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 +[チェックサム](https://docs.pingcap.com/tidb/stable/tidb-lightning-glossary#checksum)テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2つのテーブルでは、チェックサムは異なります。 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
    `実行されます。 diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index e22406039d0e4..561feffed83b5 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -190,7 +190,7 @@ mysql> ADMIN SHOW DDL JOB QUERIES 51; 1 row in set (0.02 sec) ``` -DDL 履歴ジョブ キュー内の過去 10 件の結果のうち、 `job_id`に対応する実行中の DDL ジョブのみを検索できます。 +DDL 履歴ジョブ キュー内の過去 10件の結果のうち、 `job_id`に対応する実行中の DDL ジョブのみを検索できます。 ### `ADMIN SHOW DDL JOB QUERIES LIMIT m OFFSET n` {#admin-show-ddl-job-queries-limit-m-offset-n} diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md index 390c49b34eff0..0b0c5c3227f68 100644 --- a/sql-statements/sql-statement-admin.md +++ b/sql-statements/sql-statement-admin.md @@ -201,7 +201,7 @@ TableNameList ::= ## 例 {#examples} -現在実行中の DDL ジョブ キューで完了した最新の 10 件の DDL ジョブを表示するには、次のコマンドを実行します。 `NUM`が指定されていない場合、デフォルトでは完了した最新の 10 件の DDL ジョブのみが表示されます。 +現在実行中の DDL ジョブ キューで完了した最新の 10件の DDL ジョブを表示するには、次のコマンドを実行します。 `NUM`が指定されていない場合、デフォルトでは完了した最新の 10件の DDL ジョブのみが表示されます。 ```sql ADMIN SHOW DDL JOBS; @@ -275,7 +275,7 @@ ADMIN SHOW DDL JOBS 5 WHERE state != 'synced' AND db_name = 'test'; +--------+---------+------------+---------------------+----------------+-----------+----------+-----------+-----------------------------------+-----------------------------------+---------------+ ``` -- `JOB_ID` : 各 DDL 操作は 1 つの DDL ジョブに対応します。 `JOB_ID`はグローバルに一意です。 +- `JOB_ID` : 各 DDL 操作は 1つの DDL ジョブに対応します。 `JOB_ID`はグローバルに一意です。 - `DB_NAME` : DDL操作が実行されるデータベースの名前。 - `TABLE_NAME` : DDL操作が実行されるテーブルの名前。 - `JOB_TYPE` : DDL操作のタイプ。 diff --git a/sql-statements/sql-statement-alter-range.md b/sql-statements/sql-statement-alter-range.md index 0c479eee4e621..61b7ba9f2ba41 100644 --- a/sql-statements/sql-statement-alter-range.md +++ b/sql-statements/sql-statement-alter-range.md @@ -18,7 +18,7 @@ AlterRangeStmt ::= 'ALTER' 'RANGE' Identifier PlacementPolicyOption ``` -`ALTER RANGE` 、以下の 2 つのパラメータをサポートしています。 +`ALTER RANGE` 、以下の2つのパラメータをサポートしています。 - `global` : クラスター内のすべてのデータの範囲を示します。 - `meta` : TiDB に格納されている内部メタデータの範囲を示します。 @@ -33,4 +33,4 @@ ALTER RANGE global PLACEMENT POLICY = "deploy111"; ALTER RANGE meta PLACEMENT POLICY = "five_replicas"; ``` -上記の例では、2 つの配置ポリシー ( `deploy111`と`five_replicas` ) を作成し、異なる領域の制約を指定した後、 `deploy111`配置ポリシーをクラスタ範囲内のすべてのデータに適用し、 `five_replicas`配置ポリシーをメタデータ範囲に適用しています。 +上記の例では、2つの配置ポリシー ( `deploy111`と`five_replicas` ) を作成し、異なる領域の制約を指定した後、 `deploy111`配置ポリシーをクラスタ範囲内のすべてのデータに適用し、 `five_replicas`配置ポリシーをメタデータ範囲に適用しています。 diff --git a/sql-statements/sql-statement-alter-resource-group.md b/sql-statements/sql-statement-alter-resource-group.md index 1874900ff0a6e..bb631504577bd 100644 --- a/sql-statements/sql-statement-alter-resource-group.md +++ b/sql-statements/sql-statement-alter-resource-group.md @@ -85,7 +85,7 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで | `RU_PER_SEC` | RUのバックフィル速度（1秒あたり） | `RU_PER_SEC = 500`は、このリソースグループが毎秒500 RUでバックフィルされていることを示します。 | | `PRIORITY` | TiKVで処理されるタスクの絶対的な優先順位 | `PRIORITY = HIGH`は優先度が高いことを示します。指定しない場合、デフォルト値は`MEDIUM`です。 | | `BURSTABLE` | `BURSTABLE`属性が設定されている場合、TiDBは、割り当て量を超過したときに、対応するリソースグループが利用可能なシステムリソースを使用することを許可します。 | | -| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60 秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10 分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 | +| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 | | `BACKGROUND` | バックグラウンドタスクを設定します。詳細については、 [バックグラウンドタスクの管理](/tidb-resource-control-background-tasks.md)を参照してください。 | `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)`は、バックアップと復元、統計情報の収集に関連するタスクがバックグラウンドタスクとしてスケジュールされ、バックグラウンドタスクはTiKVリソースの最大30%を消費できることを示しています。 | > **Note:** diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index 148204262fafa..66b24b037f515 100644 --- a/sql-statements/sql-statement-alter-sequence.md +++ b/sql-statements/sql-statement-alter-sequence.md @@ -94,7 +94,7 @@ CREATE SEQUENCE s1; Query OK, 0 rows affected (0.15 sec) ``` -次の SQL ステートメントを 2 回実行して、シーケンスから次の 2 つの値を取得します。 +次の SQL ステートメントを 2回実行して、シーケンスから次の2つの値を取得します。 ```sql SELECT NEXTVAL(s1); @@ -132,7 +132,7 @@ ALTER SEQUENCE s1 INCREMENT=2; Query OK, 0 rows affected (0.18 sec) ``` -ここで、シーケンスから次の 2 つの値を再度取得します。 +ここで、シーケンスから次の2つの値を再度取得します。 ```sql SELECT NEXTVAL(s1); diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md index 0574e7a2cb3c5..5300639631fc1 100644 --- a/sql-statements/sql-statement-alter-table-compact.md +++ b/sql-statements/sql-statement-alter-table-compact.md @@ -26,7 +26,7 @@ AlterTableCompactStmt ::= ### テーブル内のコンパクトなTiFlashレプリカ {#compact-tiflash-replicas-in-a-table} -以下は、2 つのTiFlashレプリカを持つ 4 つのパーティションを持つ`employees`テーブルを例として示します。 +以下は、2つのTiFlashレプリカを持つ 4つのパーティションを持つ`employees`テーブルを例として示します。 ```sql CREATE TABLE employees ( @@ -43,7 +43,7 @@ PARTITION BY LIST (store_id) ( ALTER TABLE employees SET TIFLASH REPLICA 2; ``` -次のステートメントを実行すると、 `employees`テーブル内のすべてのパーティションの 2 つのTiFlashレプリカの圧縮を直ちに開始できます。 +次のステートメントを実行すると、 `employees`テーブル内のすべてのパーティションの 2つのTiFlashレプリカの圧縮を直ちに開始できます。 ```sql ALTER TABLE employees COMPACT TIFLASH REPLICA; @@ -51,7 +51,7 @@ ALTER TABLE employees COMPACT TIFLASH REPLICA; ### テーブル内の指定されたパーティションのコンパクトTiFlashレプリカ {#compact-tiflash-replicas-of-specified-partitions-in-a-table} -以下は、2 つのTiFlashレプリカを持つ 4 つのパーティションを持つ`employees`テーブルを例として示します。 +以下は、2つのTiFlashレプリカを持つ 4つのパーティションを持つ`employees`テーブルを例として示します。 ```sql CREATE TABLE employees ( @@ -69,7 +69,7 @@ PARTITION BY LIST (store_id) ( ALTER TABLE employees SET TIFLASH REPLICA 2; ``` -次のステートメントを実行すると、テーブル`employees`のパーティション`pNorth`と`pEast`の 2 つのTiFlashレプリカの圧縮を直ちに開始できます。 +次のステートメントを実行すると、テーブル`employees`のパーティション`pNorth`と`pEast`の 2つのTiFlashレプリカの圧縮を直ちに開始できます。 ```sql ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA; diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index e190fa1223d04..ec65358ca0699 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -160,7 +160,7 @@ TiDB の`ALTER TABLE`には次の主な制限が適用されます。 - 同じオブジェクトを複数回変更することはサポートされていません。 - TiDBは**実行前に**テーブルスキーマに従ってステートメントを検証します。例えば、 `ALTER TABLE t ADD COLUMN c1 INT, ADD COLUMN c2 INT AFTER c1;`を実行すると、列`c1`テーブルに存在しないためエラーが返されます。 - - `ALTER TABLE`ステートメントの場合、TiDB での実行順序は左から右への変更が 1 つずつ順番に実行されるため、場合によっては MySQL と互換性がありません。 + - `ALTER TABLE`ステートメントの場合、TiDB での実行順序は左から右への変更が 1つずつ順番に実行されるため、場合によっては MySQL と互換性がありません。 - 主キー列の[再編成データ](/sql-statements/sql-statement-modify-column.md#reorg-data-change)種類の変更はサポートされていません。 diff --git a/sql-statements/sql-statement-alter-user.md b/sql-statements/sql-statement-alter-user.md index df865a89b8215..4c0dcbc3ea2ff 100644 --- a/sql-statements/sql-statement-alter-user.md +++ b/sql-statements/sql-statement-alter-user.md @@ -141,7 +141,7 @@ ALTER USER 'newuser' PASSWORD EXPIRE NEVER; Query OK, 0 rows affected (0.02 sec) ``` -`ALTER USER ... PASSWORD REUSE INTERVAL ... DAY`を使用して、 `newuser`パスワード再利用ポリシーを変更し、過去 90 日以内に使用されたパスワードの再利用を禁止します。 +`ALTER USER ... PASSWORD REUSE INTERVAL ... DAY`を使用して、 `newuser`パスワード再利用ポリシーを変更し、過去 90日以内に使用されたパスワードの再利用を禁止します。 ```sql ALTER USER 'newuser' PASSWORD REUSE INTERVAL 90 DAY; diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md index dea4da1c74cd4..9912c57863f8a 100644 --- a/sql-statements/sql-statement-backup.md +++ b/sql-statements/sql-statement-backup.md @@ -18,7 +18,7 @@ summary: TiDBデータベースにおけるBACKUPの使用方法の概要。 `BACKUP`ステートメントは、バックアップ タスク全体が完了、失敗、またはキャンセルされるまでブロックされます。 `BACKUP`を実行するには、長時間接続を準備する必要があります。タスクは、[`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md)ステートメントを使用してキャンセルできます。 -`BACKUP`および[`RESTORE`](/sql-statements/sql-statement-restore.md)タスクは、一度に 1 つしか実行できません。 `BACKUP`または`RESTORE`ステートメントが同じ TiDBサーバーで既に実行されている場合、新しい`BACKUP`の実行は、以前のすべてのタスクが完了するまで待機します。 +`BACKUP`および[`RESTORE`](/sql-statements/sql-statement-restore.md)タスクは、一度に 1つしか実行できません。 `BACKUP`または`RESTORE`ステートメントが同じ TiDBサーバーで既に実行されている場合、新しい`BACKUP`の実行は、以前のすべてのタスクが完了するまで待機します。 `BACKUP` 「tikv」ストレージエンジンでのみ使用できます。「unistore」エンジンで`BACKUP`を使用すると失敗します。 diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index fc5221c539d29..1e6fd7cdb4937 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -32,7 +32,7 @@ WorkloadOption ::= ## 容量を推定する方法 {#methods-for-estimating-capacity} -TiDB は推定に 2 つの方法を提供します。 +TiDB は推定に 2つの方法を提供します。 ### 実際の作業負荷に基づいて容量を見積もる {#estimate-capacity-based-on-actual-workload} @@ -40,7 +40,7 @@ TiDB は推定に 2 つの方法を提供します。 - `START_TIME`パラメータを使用して、推定を開始する時刻を`2006-01-02 15:04:05`形式で指定します。推定のデフォルトの終了時刻は現在の時刻です。 - `START_TIME`パラメータを指定した後、 `END_TIME`パラメータを使用して推定終了時刻を指定したり、 `DURATION`パラメータを使用して`START_TIME`からの推定時間ウィンドウを指定したりできます。 -- 時間枠は 10 分から 24 時間までです。 +- 時間枠は 10分から 24時間までです。 - 指定された時間枠内で、TiDB と TiKV の CPU 使用率が低すぎる場合、容量を見積もることはできません。 > **Note:** @@ -87,7 +87,7 @@ CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' END_TIME '2023-04-18 08:20:0 1 row in set (0.01 sec) ``` -時間ウィンドウ範囲`DURATION` 10 分から 24 時間の範囲にない場合は、エラーが発生します。 +時間ウィンドウ範囲`DURATION` 10分から 24時間の範囲にない場合は、エラーが発生します。 ```sql CALIBRATE RESOURCE START_TIME '2023-04-18 08:00:00' DURATION '25h'; diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md index a19cd1f3cc371..365b7b1af2aa9 100644 --- a/sql-statements/sql-statement-create-resource-group.md +++ b/sql-statements/sql-statement-create-resource-group.md @@ -82,7 +82,7 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで | `RU_PER_SEC` | RUのバックフィル速度（1秒あたり） | `RU_PER_SEC = 500`は、このリソースグループが毎秒500 RUでバックフィルされていることを示します。 | | `PRIORITY` | TiKVで処理されるタスクの絶対的な優先順位 | `PRIORITY = HIGH`は優先度が高いことを示します。指定しない場合、デフォルト値は`MEDIUM`です。 | | `BURSTABLE` | `BURSTABLE`属性が設定されている場合、TiDBは、割り当て量を超過したときに、対応するリソースグループが利用可能なシステムリソースを使用することを許可します。 | | -| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60 秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10 分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 | +| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 | > **Note:** > @@ -91,7 +91,7 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで ## 例 {#examples} -`rg1`と`rg2` 2 つのリソース グループを作成します。 +`rg1`と`rg2` 2つのリソース グループを作成します。 ```sql DROP RESOURCE GROUP IF EXISTS rg1; diff --git a/sql-statements/sql-statement-create-user.md b/sql-statements/sql-statement-create-user.md index f41bdddd51127..fbb37c13496ea 100644 --- a/sql-statements/sql-statement-create-user.md +++ b/sql-statements/sql-statement-create-user.md @@ -122,7 +122,7 @@ SELECT * FROM information_schema.user_attributes; 1 rows in set (0.00 sec) ``` -過去 5 回のパスワードの再利用を許可しないユーザーを作成します。 +過去 5回のパスワードの再利用を許可しないユーザーを作成します。 ```sql CREATE USER 'newuser8'@'%' PASSWORD HISTORY 5; diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 9bc829b0c9b95..306148e34f91b 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -135,7 +135,7 @@ prepare:109.616µs, check_insert:{total_time:1.431678ms, mem_insert_time:667.878 - `total_time` : ステップ`check_insert`に費やされた合計時間。 - `mem_insert_time` : TiDB トランザクション キャッシュにデータを書き込むのにかかる時間。 - `prefetch` : TiKVから競合チェックが必要なデータを取得する時間。このステップでは、データを取得するために`Batch_Get` RPCリクエストをTiKVに送信します。 - - `rpc` : TiKV への RPC 要求の送信に費やされた合計時間。これには通常、 `BatchGet`と`Get` 2 種類の RPC 時間が含まれます。 + - `rpc` : TiKV への RPC 要求の送信に費やされた合計時間。これには通常、 `BatchGet`と`Get` 2種類の RPC 時間が含まれます。 - `prefetch`ステップで`BatchGet` RPC 要求が送信されます。 - `insert on duplicate`ステートメントが実行されると、 `Get` `duplicate update` RPC 要求が送信されます。 - `backoff` : さまざまなタイプのバックオフとバックオフの合計待機時間が含まれます。 diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index 3563093e5a507..db38d0ae9bf99 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -183,7 +183,7 @@ EXPLAIN DELETE FROM t1 WHERE c1=3; | `tidb_json` | `EXPLAIN`ステートメントは実行計画を JSON 形式で出力し、演算子情報を JSON 配列に格納します。 | | `verbose` | `EXPLAIN`文は`row`形式で結果を出力し、さらに`estCost`列にクエリの推定コストが表示されます。この形式の使用方法の詳細については、 [SQLプラン管理](/sql-plan-management.md)を参照してください。 | | `plan_cache` | `EXPLAIN`ステートメントは、 [プランキャッシュ](/sql-non-prepared-plan-cache.md#diagnostics)情報を警告として含めて、 `row`形式で結果を出力します。 | -| `cost_trace` | `EXPLAIN`ステートメントは、推定コストの`estCost`とコストの計算式の`costFormula`列の 2 つの追加列を含む拡張`row`形式で結果を出力します。 | +| `cost_trace` | `EXPLAIN`ステートメントは、推定コストの`estCost`とコストの計算式の`costFormula`列の 2つの追加列を含む拡張`row`形式で結果を出力します。 | diff --git a/sql-statements/sql-statement-flush-stats-delta.md b/sql-statements/sql-statement-flush-stats-delta.md index 872f45fa54db6..c757708f17809 100644 --- a/sql-statements/sql-statement-flush-stats-delta.md +++ b/sql-statements/sql-statement-flush-stats-delta.md @@ -7,7 +7,7 @@ summary: TiDB データベースにおける FLUSH STATS_DELTA の使用方法 `FLUSH STATS_DELTA` は、TiDB のメモリにバッファされている保留中の統計デルタを、[`mysql.stats_meta`](/mysql-schema/mysql-schema.md#statistics-system-tables) システムテーブルに即座に永続化します。 -`INSERT`、`UPDATE`、`DELETE` などの DML 文を使用してデータを変更すると、TiDB は影響を受けた各テーブルの総行数と変更行数の変化を記録し、これらの変更（統計デルタと呼ばれます）を、その文を実行した TiDB ノードのメモリにバッファします。デフォルトでは、TiDB は 20 * [`stats-lease`](/tidb-configuration-file.md#stats-lease) ごと（デフォルトでは 60 秒ごと）に統計デルタを `mysql.stats_meta` システムテーブルへ永続化します。詳細は、[自動更新](/statistics.md#automatic-update) を参照してください。 +`INSERT`、`UPDATE`、`DELETE` などの DML 文を使用してデータを変更すると、TiDB は影響を受けた各テーブルの総行数と変更行数の変化を記録し、これらの変更（統計デルタと呼ばれます）を、その文を実行した TiDB ノードのメモリにバッファします。デフォルトでは、TiDB は 20 * [`stats-lease`](/tidb-configuration-file.md#stats-lease) ごと（デフォルトでは 60秒ごと）に統計デルタを `mysql.stats_meta` システムテーブルへ永続化します。詳細は、[自動更新](/statistics.md#automatic-update) を参照してください。 [テーブルの統計ヘルス状態](/sql-statements/sql-statement-show-stats-healthy.md)、[`SHOW STATS_META`](/sql-statements/sql-statement-show-stats-meta.md) の出力、および自動統計収集のスケジューリングは、永続化された統計メタデータに依存します。そのため、オプティマイザの動作を検証するテストシナリオなど、永続化された統計メタデータに最近のデータ変更を即座に反映させる必要がある場合に、`FLUSH STATS_DELTA` は有用です。[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) を実行する前に `FLUSH STATS_DELTA` を実行する必要はありません。TiDB は、テーブルの統計を収集する前に、そのテーブルの保留中の統計デルタを自動的にフラッシュするためです。 @@ -40,7 +40,7 @@ ClusterOption ::= ## オプション {#options} -- **Targets (`FlushTargetList`)**: 統計デルタをフラッシュする対象テーブルを指定します。少なくとも 1 つの対象を指定する必要があります。 +- **Targets (`FlushTargetList`)**: 統計デルタをフラッシュする対象テーブルを指定します。少なくとも 1つの対象を指定する必要があります。 - `table_name`: 現在のデータベース内の特定のテーブルの統計デルタをフラッシュします。データベースを選択していない場合、TiDB は `No database selected` エラーを返します。 - `db_name.table_name`: 指定したデータベース内の特定のテーブルの統計デルタをフラッシュします。 - `db_name.*`: 指定したデータベース内のすべてのテーブルの統計デルタをフラッシュします。 diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 329ad3d723c6b..fc7cf2afb043d 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -5,7 +5,7 @@ summary: TiDBにおけるIMPORT INTOの使用方法の概要。 # IMPORT INTO {#import-into} -`IMPORT INTO`ステートメントを使用すると、 TiDB Lightningの[物理インポートモード](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)を介して TiDB にデータをインポートできます。 `IMPORT INTO` 、次の 2 つの方法で使用できます。 +`IMPORT INTO`ステートメントを使用すると、 TiDB Lightningの[物理インポートモード](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)を介して TiDB にデータをインポートできます。 `IMPORT INTO` 、次の2つの方法で使用できます。 - `IMPORT INTO ... FROM FILE` : `CSV` 、 `SQL` 、 `PARQUET`などの形式のデータファイルを TiDB の空のテーブルにインポートします。 - `IMPORT INTO ... FROM SELECT` : `SELECT`ステートメントのクエリ結果を TiDB の空のテーブルにインポートします。また、 [`AS OF TIMESTAMP`](/as-of-timestamp.md)でクエリされた履歴データをインポートするためにも使用できます。 @@ -46,7 +46,7 @@ summary: TiDBにおけるIMPORT INTOの使用方法の概要。 ### `IMPORT INTO ... FROM SELECT`制限 {#import-into-from-select-restrictions} - `IMPORT INTO ... FROM SELECT` 、現在のユーザーが接続している TiDB ノードでのみ実行でき、インポートが完了するまで現在の接続をブロックします。 -- `IMPORT INTO ... FROM SELECT` 、 `THREAD`と`DISABLE_PRECHECK` 2 つのインポート[インポートオプション](#withoptions)のみをサポートします。 +- `IMPORT INTO ... FROM SELECT` 、 `THREAD`と`DISABLE_PRECHECK` 2つのインポート[インポートオプション](#withoptions)のみをサポートします。 - `IMPORT INTO ... FROM SELECT` `SHOW IMPORT JOB(s)`や`CANCEL IMPORT JOB `などのタスク管理ステートメントをサポートしていません。 - TiDB では、 `SELECT`ステートメントのクエリ結果全体を格納するのに十分なスペースが必要です ( `DISK_QUOTA`オプション[一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)設定は現在サポートされていません)。 - [`tidb_snapshot`](/read-historical-data.md)を使用した履歴データのインポートはサポートされていません。 @@ -147,7 +147,7 @@ OptionItem ::= | `FIELDS_ENCLOSED_BY=''` | CSV | フィールド区切り文字を指定します。デフォルトの区切り文字は`"`です。 | | `FIELDS_ESCAPED_BY=''` | CSV | フィールドのエスケープ文字を指定します。デフォルトのエスケープ文字は`\`です。 | | `FIELDS_DEFINED_NULL_BY=''` | CSV | フィールド内の`NULL`を表す値を指定します。デフォルト値は`\N`です。 | -| `LINES_TERMINATED_BY=''` | CSV | 行末文字を指定します。デフォルトでは、 `IMPORT INTO`は、 `\n` 、 `\r` 、または`\r\n`行末文字として自動的に識別します。行末文字がこれら 3 つのいずれかである場合は、このオプションを明示的に指定する必要はありません。 | +| `LINES_TERMINATED_BY=''` | CSV | 行末文字を指定します。デフォルトでは、 `IMPORT INTO`は、 `\n` 、 `\r` 、または`\r\n`行末文字として自動的に識別します。行末文字がこれら3つのいずれかである場合は、このオプションを明示的に指定する必要はありません。 | | `SKIP_ROWS=` | CSV | スキップする行数を指定します。デフォルト値は`0`です。このオプションを使用すると、CSV ファイルのヘッダーをスキップできます。インポートするソース ファイルを指定するためにワイルド カードを使用する場合、このオプションは`fileLocation`のワイルド カードに一致するすべてのソース ファイルに適用されます。 | | `SPLIT_FILE` | CSV | インポート効率を向上させるため、単一のCSVファイルを約256MiBの複数の小さなチャンクに分割し、並列処理を行います。このパラメータは**非圧縮**CSVファイルでのみ有効で、 TiDB Lightning [`strict-format`](https://docs.pingcap.com/tidb/stable/tidb-lightning-data-source#strict-format)と同様の使用制限があります。このオプションを使用するには`LINES_TERMINATED_BY`明示的に指定する必要があることに注意してください。 | | `DISK_QUOTA=''` | すべてのファイル形式 | データソート中に使用できるディスク容量のしきい値を指定します。デフォルト値は、TiDB のディスク容量の 80% です。 ディスクの合計サイズを取得できない場合は、デフォルト値は 50 GiB です。 `DISK_QUOTA`を明示的に指定する場合は、その値が TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)ディレクトリのディスク容量の 80% を超えないようにしてください。 | @@ -285,7 +285,7 @@ IMPORT INTO t(id, name, @1) FROM '/path/to/file.csv' WITH skip_rows=1; #### ワイルドカードを使用して複数のデータファイルをインポートする {#import-multiple-data-files-using-wildcards} -`/path/to/`ディレクトリに`file-01.csv` 、 `file-02.csv` 、 `file-03.csv`という名前のファイルが 3 つあるとします。これらの 3 つのファイルを`IMPORT INTO`を使用してターゲット テーブル`t`にインポートするには、次の SQL ステートメントを実行します。 +`/path/to/`ディレクトリに`file-01.csv` 、 `file-02.csv` 、 `file-03.csv`という名前のファイルが 3つあるとします。これらの 3つのファイルを`IMPORT INTO`を使用してターゲット テーブル`t`にインポートするには、次の SQL ステートメントを実行します。 ```sql IMPORT INTO t FROM '/path/to/file-*.csv'; diff --git a/sql-statements/sql-statement-kill.md b/sql-statements/sql-statement-kill.md index 5b12b7279b53e..d0314dee422da 100644 --- a/sql-statements/sql-statement-kill.md +++ b/sql-statements/sql-statement-kill.md @@ -15,7 +15,7 @@ KillStmt ::= 'KILL' 'TIDB'? ( 'CONNECTION' | 'QUERY' )? CONNECTION_ID ## 例 {#examples} -次の例は、現在のクラスター内のすべてのアクティブなクエリを取得し、そのうちの 1 つを終了する方法を示しています。 +次の例は、現在のクラスター内のすべてのアクティブなクエリを取得し、そのうちの 1つを終了する方法を示しています。 ```sql SELECT ID, USER, INSTANCE, INFO FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST; diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 998bae402f7bb..fdc6fc6d3fa9c 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -188,8 +188,8 @@ IGNORE 1 LINES; > **Note:** > > - TiDB v4.0.0 より前のバージョンでは、20000 行ごとに`LOAD DATA`コミットが実行され、これは構成できません。 -> - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1 つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 -> - TiDB v7.0.0 以降では、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、TiDB は 1 つのトランザクションですべての行をコミットします。 +> - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 +> - TiDB v7.0.0 以降では、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、TiDB は 1つのトランザクションですべての行をコミットします。 > - TiDB v4.0.0 以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`発生する場合があります。このエラーを解決するには、 `tidb.toml`ファイルの[`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)値を増やすことをお勧めします。 > - TiDB v7.6.0 より前のバージョンでは、トランザクションでコミットされる行数に関係なく、明示的なトランザクションの[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)ステートメントによって`LOAD DATA`ロールバックされることはありません。 > - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクション モードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクション モードで実行されます。 @@ -205,8 +205,8 @@ IGNORE 1 LINES; > **Note:** > > - TiDB v4.0.0 より前のバージョンでは、20000 行ごとに`LOAD DATA`コミットが実行され、これは構成できません。 -> - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1 つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 -> - v7.0.0 以降、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、 TiDB は 1 つのトランザクションですべての行をコミットします。 +> - TiDB v4.0.0 から v6.6.0 までのバージョンでは、TiDB はデフォルトですべての行を 1つのトランザクションでコミットします。ただし、 `LOAD DATA`ステートメントで一定数の行をコミットする必要がある場合は、必要な行数を[`tidb_dml_batch_size`](/system-variables.md#tidb_dml_batch_size)に設定できます。 +> - v7.0.0 以降、 `tidb_dml_batch_size` `LOAD DATA`には影響しなくなり、 TiDB は 1つのトランザクションですべての行をコミットします。 > - TiDB v4.0.0以前のバージョンからアップグレードすると、 `ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058`発生する場合があります。このエラーを解決するには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)値を増やすことができます。 > - TiDB v7.6.0 より前のバージョンでは、トランザクションでコミットされる行数に関係なく、明示的なトランザクションの[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)ステートメントによって`LOAD DATA`ロールバックされることはありません。 > - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクション モードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクション モードで実行されます。 diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index e444cd90cbdba..16c9661cc0fee 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -147,7 +147,7 @@ CREATE TABLE `t1` ( > alter table t1 modify column col1 varchar(4); > ERROR 1406 (22001): Data Too Long, field len 4, data len 5 > -> - 非同期コミット機能との互換性のため、 [メタデータロック](/metadata-lock.md)無効になっている場合、DDL ステートメントは、Reorg-Data への処理を開始する前に一定期間 (約 2.5 秒) 待機します。 +> - 非同期コミット機能との互換性のため、 [メタデータロック](/metadata-lock.md)無効になっている場合、DDL ステートメントは、Reorg-Data への処理を開始する前に一定期間 (約 2.5秒) 待機します。 > > Query OK, 0 rows affected (2.52 sec) diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index 6ebe243d789b1..4bef23c39dee6 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -47,7 +47,7 @@ NUM ::= intLit RECOVER TABLE t; ``` - このメソッドは、最近の DDL ジョブ履歴を検索し、 `DROP TABLE`タイプの最初の DDL 操作を見つけ、 `RECOVER TABLE`ステートメントで指定された 1 つのテーブル名と同じ名前を持つ削除されたテーブルを回復します。 + このメソッドは、最近の DDL ジョブ履歴を検索し、 `DROP TABLE`タイプの最初の DDL 操作を見つけ、 `RECOVER TABLE`ステートメントで指定された 1つのテーブル名と同じ名前を持つ削除されたテーブルを回復します。 - 使用されたテーブル`DDL JOB ID`に応じて、削除されたテーブルを回復します。 diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md index ef6a00d0796f1..63d9fcea9d034 100644 --- a/sql-statements/sql-statement-restore.md +++ b/sql-statements/sql-statement-restore.md @@ -22,7 +22,7 @@ summary: TiDBデータベースにおけるRESTOREの使用方法の概要。 `RESTORE`ステートメントはブロッキング処理であり、リストアタスク全体が完了、失敗、またはキャンセルされるまで終了しません。 `RESTORE`を実行するには、長時間接続を準備する必要があります。タスクは[`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md)ステートメントを使用してキャンセルできます。 -`BACKUP`と`RESTORE`のタスクは、一度に 1 つしか実行できません。 `BACKUP`または`RESTORE`タスクが同じ TiDBサーバーで既に実行されている場合、新しい`RESTORE`実行は、以前のすべてのタスクが完了するまで待機します。 +`BACKUP`と`RESTORE`のタスクは、一度に 1つしか実行できません。 `BACKUP`または`RESTORE`タスクが同じ TiDBサーバーで既に実行されている場合、新しい`RESTORE`実行は、以前のすべてのタスクが完了するまで待機します。 `RESTORE` 「tikv」ストレージエンジンでのみ使用できます。「unistore」エンジンで`RESTORE`を使用すると失敗します。 diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index 1c0348f7481a8..988c23e17a4b1 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -98,9 +98,9 @@ TableSample ::= | `GROUP BY` | `GROUP BY`ステートメントは、結果セットをグループ化するために使用されます。 | | `HAVING where_condition` | `HAVING`句と`WHERE`句はどちらも結果をフィルタリングするために使用されます。 `HAVING`句は`GROUP BY`の結果をフィルタリングし、 `WHERE`句は集計前に結果をフィルタリングします。 | | `ORDER BY` | `ORDER BY`句は、 `select_expr`リスト内の列、式、または項目に基づいて、データを昇順または降順に並べ替えるために使用されます。 | -| `LIMIT` | `LIMIT`句を使用すると、行数を制限できます。 `LIMIT`は、1 つまたは 2 つの数値引数を取ります。引数が 1 つの場合、引数は返される行の最大数を指定します。返される最初の行は、デフォルトではテーブルの最初の行です。引数が 2 つの場合、最初の引数は返される最初の行のオフセットを指定し、2 番目の引数は返される行の最大数を指定します。TiDB は、 `FETCH FIRST/NEXT n ROW/ROWS ONLY`と同じ効果を持つ`LIMIT n`構文もサポートしています。この構文では`n`を省略でき、その効果は`LIMIT 1`と同じです。 | +| `LIMIT` | `LIMIT`句を使用すると、行数を制限できます。 `LIMIT`は、1つまたは 2つの数値引数を取ります。引数が 1つの場合、引数は返される行の最大数を指定します。返される最初の行は、デフォルトではテーブルの最初の行です。引数が 2つの場合、最初の引数は返される最初の行のオフセットを指定し、2 番目の引数は返される行の最大数を指定します。TiDB は、 `FETCH FIRST/NEXT n ROW/ROWS ONLY`と同じ効果を持つ`LIMIT n`構文もサポートしています。この構文では`n`を省略でき、その効果は`LIMIT 1`と同じです。 | | `Window window_definition` | これはウィンドウ関数の構文であり、通常は分析計算を行うために使用されます。詳細については、 [ウィンドウ機能](/functions-and-operators/window-functions.md)を参照してください。 | -| `FOR UPDATE` | `SELECT FOR UPDATE`句は、結果セット内のすべてのデータをロックして、他のトランザクションからの同時更新を検出します。クエリ条件に一致するが結果セットに存在しないデータは、読み取りロックされません。たとえば、現在のトランザクションが開始された後に他のトランザクションによって書き込まれた行データなどです。TiDB が[楽観的トランザクションモード](/optimistic-transaction.md)モードを使用する場合、ステートメント実行フェーズではトランザクションの競合は検出されません。したがって、現在のトランザクションは、PostgreSQL などの他のデータベースのように、他のトランザクションが`UPDATE` 、 `DELETE` 、または`SELECT FOR UPDATE`を実行するのをブロックしません。コミットフェーズでは、 `SELECT FOR UPDATE`によって読み取られた行は 2 つのフェーズでコミットされるため、競合検出に参加することもできます。書き込み競合が発生した場合、 `SELECT FOR UPDATE`句を含むすべてのトランザクションのコミットは失敗します。競合が検出されなかった場合、コミットは成功します。また、ロックされた行に対して新しいバージョンが生成されるため、コミットされていない他のトランザクションが後でコミットされるときに書き込み競合を検出できます。 TiDB が[悲観的なトランザクションモード](/pessimistic-transaction.md)を使用する場合、動作は基本的に他のデータベースと同じです。詳細については、 [MySQL InnoDBとの違い](/pessimistic-transaction.md#differences-from-mysql-innodb)を参照してください。 TiDB は`NOWAIT`の`FOR UPDATE`修飾子をサポートしています。詳細については[TiDB悲観的トランザクションモード](/pessimistic-transaction.md#behaviors)を参照してください。 | +| `FOR UPDATE` | `SELECT FOR UPDATE`句は、結果セット内のすべてのデータをロックして、他のトランザクションからの同時更新を検出します。クエリ条件に一致するが結果セットに存在しないデータは、読み取りロックされません。たとえば、現在のトランザクションが開始された後に他のトランザクションによって書き込まれた行データなどです。TiDB が[楽観的トランザクションモード](/optimistic-transaction.md)モードを使用する場合、ステートメント実行フェーズではトランザクションの競合は検出されません。したがって、現在のトランザクションは、PostgreSQL などの他のデータベースのように、他のトランザクションが`UPDATE` 、 `DELETE` 、または`SELECT FOR UPDATE`を実行するのをブロックしません。コミットフェーズでは、 `SELECT FOR UPDATE`によって読み取られた行は 2つのフェーズでコミットされるため、競合検出に参加することもできます。書き込み競合が発生した場合、 `SELECT FOR UPDATE`句を含むすべてのトランザクションのコミットは失敗します。競合が検出されなかった場合、コミットは成功します。また、ロックされた行に対して新しいバージョンが生成されるため、コミットされていない他のトランザクションが後でコミットされるときに書き込み競合を検出できます。 TiDB が[悲観的なトランザクションモード](/pessimistic-transaction.md)を使用する場合、動作は基本的に他のデータベースと同じです。詳細については、 [MySQL InnoDBとの違い](/pessimistic-transaction.md#differences-from-mysql-innodb)を参照してください。 TiDB は`NOWAIT`の`FOR UPDATE`修飾子をサポートしています。詳細については[TiDB悲観的トランザクションモード](/pessimistic-transaction.md#behaviors)を参照してください。 | | `LOCK IN SHARE MODE` | 互換性を保証するため、TiDBはこれら3つの修飾子を解析しますが、無視します。 | | `TABLESAMPLE` | テーブルから行のサンプルを取得する。 | diff --git a/sql-statements/sql-statement-set-resource-group.md b/sql-statements/sql-statement-set-resource-group.md index 9feb45317606b..a40145925376d 100644 --- a/sql-statements/sql-statement-set-resource-group.md +++ b/sql-statements/sql-statement-set-resource-group.md @@ -33,7 +33,7 @@ ResourceGroupName ::= ## 例 {#examples} -ユーザー`user1`を作成し、2 つのリソース グループ`rg1`と`rg2`を作成し、ユーザー`user1`をリソース グループ`rg1`にバインドします。 +ユーザー`user1`を作成し、2つのリソース グループ`rg1`と`rg2`を作成し、ユーザー`user1`をリソース グループ`rg1`にバインドします。 ```sql CREATE USER 'user1'; diff --git a/sql-statements/sql-statement-show-affinity.md b/sql-statements/sql-statement-show-affinity.md index 05639bdb060de..20c5a9eb158cc 100644 --- a/sql-statements/sql-statement-show-affinity.md +++ b/sql-statements/sql-statement-show-affinity.md @@ -18,7 +18,7 @@ ShowAffinityStmt ::= ## 例 {#examples} -次の例では、アフィニティ スケジュールを有効にした 2 つのテーブルを作成し、そのスケジュール情報を表示する方法を示します。 +次の例では、アフィニティ スケジュールを有効にした 2つのテーブルを作成し、そのスケジュール情報を表示する方法を示します。 ```sql CREATE TABLE t1 (a INT) AFFINITY = 'table'; diff --git a/sql-statements/sql-statement-show-analyze-status.md b/sql-statements/sql-statement-show-analyze-status.md index c6b90e323c59b..3d9a814869953 100644 --- a/sql-statements/sql-statement-show-analyze-status.md +++ b/sql-statements/sql-statement-show-analyze-status.md @@ -9,7 +9,7 @@ summary: TiDB データベースの SHOW ANALYZE STATUS の使用法の概要。 TiDB v6.1.0以降、 `SHOW ANALYZE STATUS`ステートメントはクラスターレベルのタスクの表示をサポートします。TiDBの再起動後でも、このステートメントを使用して再起動前のタスクレコードを表示できます。TiDB v6.1.0より前のバージョンでは、 `SHOW ANALYZE STATUS`ステートメントはインスタンスレベルのタスクのみを表示でき、タスクレコードはTiDBの再起動後に消去されます。 -TiDB v6.1.0 以降では、システム テーブル`mysql.analyze_jobs`を通じて過去 7 日間の履歴タスクを表示できます。 +TiDB v6.1.0 以降では、システム テーブル`mysql.analyze_jobs`を通じて過去 7日間の履歴タスクを表示できます。 TiDB v7.3.0 以降では、システム テーブル`mysql.analyze_jobs`または`SHOW ANALYZE STATUS`を通じて現在の`ANALYZE`タスクの進行状況を表示できます。 diff --git a/sql-statements/sql-statement-show-placement-for.md b/sql-statements/sql-statement-show-placement-for.md index 7d1d80e292d26..f4967dcf0226b 100644 --- a/sql-statements/sql-statement-show-placement-for.md +++ b/sql-statements/sql-statement-show-placement-for.md @@ -13,7 +13,7 @@ summary: TiDB における SHOW PLACEMENT FOR の使用方法。 このステートメントは`Scheduling_State`フィールドがPlacement Driver(PD) が配置スケジュールに関して現在行っている進捗状況を示す結果セットを返します。 -- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスタで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`なのに、フォロワー候補となる TiKV ストアが 3 つしかない場合などです。 +- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスタで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`なのに、フォロワー候補となる TiKV ストアが 3つしかない場合などです。 - `INPROGRESS` : PD は現在配置のスケジュールを調整中です。 - `SCHEDULED` : PD は配置を正常にスケジュールしました。 diff --git a/sql-statements/sql-statement-show-placement.md b/sql-statements/sql-statement-show-placement.md index 9564fc7b0c173..37ca6a34a8663 100644 --- a/sql-statements/sql-statement-show-placement.md +++ b/sql-statements/sql-statement-show-placement.md @@ -13,7 +13,7 @@ summary: TiDBにおけるSHOW PLACEMENTの使用方法。 このステートメントは`Scheduling_State`フィールドがPlacement Driver(PD) が配置スケジュールに関して現在行っている進捗状況を示す結果セットを返します。 -- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスタで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`なのに、フォロワー候補となる TiKV ストアが 3 つしかない場合などです。 +- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスタで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`なのに、フォロワー候補となる TiKV ストアが 3つしかない場合などです。 - `INPROGRESS` : PD は現在配置のスケジュールを調整中です。 - `SCHEDULED` : PD は配置を正常にスケジュールしました。 diff --git a/sql-statements/sql-statement-show-table-regions.md b/sql-statements/sql-statement-show-table-regions.md index e6daeef1bfb7a..f0afb24b4a7e2 100644 --- a/sql-statements/sql-statement-show-table-regions.md +++ b/sql-statements/sql-statement-show-table-regions.md @@ -152,7 +152,7 @@ mysql> SHOW TABLE t REGIONS; 上記の例では： -- テーブル t は 6 つの領域に対応しています。これらの領域では、 `102` 、 `106` 、 `110` 、 `114` 、および`3`に行データが格納され、 `98`にインデックスデータが格納されます。 +- テーブル t は 6つの領域に対応しています。これらの領域では、 `102` 、 `106` 、 `110` 、 `114` 、および`3`に行データが格納され、 `98`にインデックスデータが格納されます。 - リージョン`START_KEY`の`END_KEY`および`102`について、 `t_43`はテーブルのプレフィックスと ID を示します。 `_r`テーブル t のレコード データのプレフィックスです。 `_i`はインデックス データのプレフィックスです。 - リージョン`102` 、 `START_KEY` 、および`END_KEY`では、 `[-inf, 20000)`の範囲内のストレージデータが格納されます。同様に、領域 ( `106` 、 `110` 、 `114` 、 `3` ) におけるデータ格納範囲も計算できます。 - リージョン`98`にはインデックスデータが格納されます。テーブル t のインデックスデータの開始キーは`t_43_i`であり、これはリージョン`98`の範囲内にあります。 @@ -168,7 +168,7 @@ test> SHOW TABLE t REGIONS WHERE leader_store_id =1; +-----------+-----------+---------+-----------+-----------------+--------------+------------+---------------+------------+----------------------+------------------+------------------------+------------------+ ``` -`SPLIT TABLE REGION`を使用して、インデックス データを領域に分割します。次の例では、テーブル t のインデックス データ`name`が`[a,z]`の範囲内の 2 つの領域に分割されます。 +`SPLIT TABLE REGION`を使用して、インデックス データを領域に分割します。次の例では、テーブル t のインデックス データ`name`が`[a,z]`の範囲内の 2つの領域に分割されます。 ```sql test> SPLIT TABLE t INDEX name BETWEEN ("a") AND ("z") REGIONS 2; @@ -180,7 +180,7 @@ test> SPLIT TABLE t INDEX name BETWEEN ("a") AND ("z") REGIONS 2; 1 row in set ``` -テーブル t は 7 つの領域に対応しています。そのうち 5 つ ( `102` 、 `106` 、 `110` 、 `114` 、 `3` ) にはテーブル t のレコード データが格納され、残りの 2 つ ( `135` 、 `98` ) にはインデックス データ`name`格納されます。 +テーブル t は 7つの領域に対応しています。そのうち 5つ ( `102` 、 `106` 、 `110` 、 `114` 、 `3` ) にはテーブル t のレコード データが格納され、残りの 2つ ( `135` 、 `98` ) にはインデックス データ`name`格納されます。 ```sql test> SHOW TABLE t REGIONS; diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index 1eb779e164130..ee4d4bf560716 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -76,7 +76,7 @@ RowValue ::= > 以下の2つのセッション変数は`SPLIT`ステートメントの動作に影響を与える可能性があります。 > > - `tidb_wait_split_region_finish` : リージョンの分散には時間がかかる場合があります。この期間は、PD スケジューリングと TiKV の負荷によって異なります。この変数は、 `SPLIT REGION`ステートメントの実行時に、すべてのリージョンが分散されるまで結果をクライアントに返すかどうかを制御するために使用されます。値が`1` (デフォルト) に設定されている場合、TiDB は分散が完了した後にのみ結果を返します。値が`0`に設定されている場合、TiDB は分散状態に関係なく結果を返します。 -> - `tidb_wait_split_region_timeout` : この変数は、 `SPLIT REGION`ステートメントの実行タイムアウトを秒単位で設定します。デフォルト値は 300 秒です。 `split`操作が指定された時間内に完了しない場合、TiDB はタイムアウト エラーを返します。 +> - `tidb_wait_split_region_timeout` : この変数は、 `SPLIT REGION`ステートメントの実行タイムアウトを秒単位で設定します。デフォルト値は 300秒です。 `split`操作が指定された時間内に完了しない場合、TiDB はタイムアウト エラーを返します。 ### 分割テーブルリージョン {#split-table-region} @@ -132,7 +132,7 @@ t[table_id]_i[index_id][index_value] t22_i5abc ``` -1 つのテーブル内の同じインデックス データの`table_id`と`index_id`は同じです。インデックスリージョンを分割するには、 `index_value`に基づいてリージョンを分割する必要があります。 +1つのテーブル内の同じインデックス データの`table_id`と`index_id`は同じです。インデックスリージョンを分割するには、 `index_value`に基づいてリージョンを分割する必要があります。 #### 均等に分割 {#even-spilt} @@ -178,13 +178,13 @@ SPLIT TABLE t INDEX idx2 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00: SPLIT TABLE t INDEX idx2 BETWEEN ("2020-06-01 00:00:00") AND ("2020-07-01 00:00:00") REGIONS 30; ``` -このステートメントは、テーブル`t`のインデックス`idx2` の 2020 年 6 月のデータを 30 のリージョンに分割します。各リージョンは1 日を表します。 +このステートメントは、テーブル`t`のインデックス`idx2` の 2020年 6月のデータを 30 のリージョンに分割します。各リージョンは1日を表します。 他のタイプのインデックス列に対するリージョン分割方法も同様です。 結合インデックスのデータリージョン分割の場合、唯一の違いは、複数の列の値を指定できる点です。 -例えば、インデックス`idx3 (a, b)`には 2 つの列が含まれており、列`a`はタイムスタンプ型、列`b`は int 型です。列`a`に基づいて時間範囲を分割するだけであれば、単一列の時間インデックスを分割する SQL ステートメントを使用できます。この場合、列`b`と`lower_value`では列`upper_velue`でください。 +例えば、インデックス`idx3 (a, b)`には 2つの列が含まれており、列`a`はタイムスタンプ型、列`b`は int 型です。列`a`に基づいて時間範囲を分割するだけであれば、単一列の時間インデックスを分割する SQL ステートメントを使用できます。この場合、列`b`と`lower_value`では列`upper_velue`でください。 ```sql SPLIT TABLE t INDEX idx3 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00:00") REGIONS 10; @@ -239,7 +239,7 @@ SPLIT TABLE t1 INDEX idx4 BY ("a", "2000-01-01 00:00:01"), ("b", "2019-04-17 14: #### パーティション化されたテーブルの分割リージョンの例 {#examples-of-split-regions-for-partitioned-tables} -1. パーティションテーブル`t`を作成します。ハッシュテーブルを 2 つのパーティションに分割して作成したいとします。例のステートメントは次のとおりです。 +1. パーティションテーブル`t`を作成します。ハッシュテーブルを 2つのパーティションに分割して作成したいとします。例のステートメントは次のとおりです。 ```sql CREATE TABLE t (a INT, b INT, INDEX idx(a)) PARTITION BY HASH(a) PARTITIONS 2; @@ -295,7 +295,7 @@ SPLIT TABLE t1 INDEX idx4 BY ("a", "2000-01-01 00:00:01"), ("b", "2019-04-17 14: +-----------+---------------+---------------+-----------+-----------------+------------------+------------+---------------+------------+----------------------+------------------+ ``` -4. 各パーティションのインデックスごとにリージョンを分割することもできます。たとえば、 `[1000,10000]`インデックスの`idx`範囲を 2 つのリージョンに分割できます。例のステートメントは次のとおりです。 +4. 各パーティションのインデックスごとにリージョンを分割することもできます。たとえば、 `[1000,10000]`インデックスの`idx`範囲を 2つのリージョンに分割できます。例のステートメントは次のとおりです。 ```sql SPLIT PARTITION TABLE t INDEX idx BETWEEN (1000) AND (10000) REGIONS 2; @@ -344,7 +344,7 @@ SPLIT TABLE t1 INDEX idx4 BY ("a", "2000-01-01 00:00:01"), ("b", "2019-04-17 14: +-----------+----------------+----------------+-----------+-----------------+------------------+------------+---------------+------------+----------------------+------------------+ ``` -5. `[0,20000]`および`idx`インデックスの`p1` `p2`範囲を 2 つのリージョンに分割したいとします。例となるステートメントは次のとおりです。 +5. `[0,20000]`および`idx`インデックスの`p1` `p2`範囲を 2つのリージョンに分割したいとします。例となるステートメントは次のとおりです。 ```sql SPLIT PARTITION TABLE t PARTITION (p1,p2) INDEX idx BETWEEN (0) AND (20000) REGIONS 2; @@ -366,7 +366,7 @@ SPLIT TABLE t1 INDEX idx4 BY ("a", "2000-01-01 00:00:01"), ("b", "2019-04-17 14: CREATE TABLE t (a INT, b INT, INDEX idx1(a)) SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=2; ``` -テーブルを作成した後、このステートメントはテーブル t の`4 + 1`リージョンを分割します。 `4 (2^2)`リージョンはテーブルの行データを保存するのに使用され、1 つのリージョンは`idx1`のインデックス データを保存するために使用されます。 +テーブルを作成した後、このステートメントはテーブル t の`4 + 1`リージョンを分割します。 `4 (2^2)`リージョンはテーブルの行データを保存するのに使用され、1つのリージョンは`idx1`のインデックス データを保存するために使用されます。 4つの表リージョンの範囲は以下のとおりです。 diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index d25496f3820be..99c7797791fc1 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -191,7 +191,7 @@ TiDBはコストベースオプティマイザ（CBO）を使用して、SQL文 統計はTiDBオプティマイザにとって不可欠です。TiDBは統計をオプティマイザの入力として使用し、SQL実行計画の各ステップで処理される行数を推定します。 -統計は次の 2 つのレベルに分かれています。 +統計は次の2つのレベルに分かれています。 - **テーブル レベルの統計**: テーブル内の行の合計数と、最後の統計収集以降に変更された行数が含まれます。 - **インデックス/列レベルの統計**: ヒストグラム、Count-Min Sketch、Top-N (最も多く出現する値またはインデックス)、さまざまな値の分布と量、NULL 値の数などの詳細情報が含まれます。 @@ -265,7 +265,7 @@ SHOW VARIABLES LIKE 'tidb\_auto\_analyze%'; #### TiDBが実行計画を構築する方法 {#how-tidb-builds-an-execution-plan} -SQL ステートメントは、TiDB オプティマイザーで主に 3 つの最適化段階を経ます。 +SQL ステートメントは、TiDB オプティマイザーで主に 3つの最適化段階を経ます。 1. [前処理](#1-pre-processing) 2. [論理変換](#2-logical-transformation) @@ -389,7 +389,7 @@ FROM ( 「最初の子が先」ルールとは、演算子が出力を生成する前に、すべての子演算子から行を取得する必要があることを意味します。例えば、結合演算子は結合を実行するために、両方の子演算子から行を取得する必要があります。「再帰下降」ルールとは、各演算子が子演算子の出力に依存するため、実際のデータは下から上へと流れるものの、プランは上から下へと分析することを意味します。 -実行計画を読むときは、次の 2 つの重要な概念を考慮してください。 +実行計画を読むときは、次の2つの重要な概念を考慮してください。 - 親子相互作用：親演算子は子演算子を順番に呼び出しますが、複数回循環して実行される場合もあります。例えば、インデックス検索やネストループ結合では、親演算子は最初の子演算子から行のバッチを取得し、次に2番目の子演算子から0行以上の行を取得します。このプロセスは、最初の子演算子の結果セットが完全に処理されるまで繰り返されます。 @@ -688,7 +688,7 @@ LIMIT 実行計画には170ミリ秒の期間が表示されています。TiDBは`test_index`を使用して、フィルター`snapshot_id = 459840`で`IndexRangeScan_20`を実行します。次に、テーブルからすべての列を取得し、 `IndexLookUp_23`の後に5,715行をTiDBに返します。TiDBはこれらの行をソートし、1,000行を返します。 -列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`は順序を保証しません。これは、`test_idx`はインデックスプレフィックス列`snapshot_id`の後に 2 つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。 +列`id`は主キーであるため、暗黙的にインデックス`test_idx`に含まれます。ただし、 `IndexRangeScan_20`は順序を保証しません。これは、`test_idx`はインデックスプレフィックス列`snapshot_id`の後に 2つの追加列（ `user_id`と`status` ）が含まれているためです。その結果、列`id`の順序は保持されません。 当初の計画は次のとおりです。 @@ -880,7 +880,7 @@ SaaSアプリケーションでは、テーブルでテナント識別情報を 異なるストレージエンジンで同じクエリを実行すると、パフォーマンスに大きな違いが見られます。 -- TiKV プラン: TiKV ではクエリに 2 分 38.6 秒かかります。データが 5,121 のリージョンに分散されているため、 `TableRangeScan`によって、5,121 の cop タスクが送信されます。 +- TiKV プラン: TiKV ではクエリに 2分 38.6秒かかります。データが 5,121 のリージョンに分散されているため、 `TableRangeScan`によって、5,121 の cop タスクが送信されます。 - TiFlashプラン：同じクエリをTiFlash MPPエンジンで実行すると、わずか3.44秒で実行できます。これは約46倍の高速化です。TiFlashはデータを主キーでソートして保存するため、主キーのプレフィックスでフィルタリングされたクエリでは、テーブル全体をスキャンする代わりに`TableRangeScan`のタスクで済みます。TiFlashに必要なMPPタスクは、TiKVの5,121タスクと比較してわずか2タスクです。 クエリステートメントは次のとおりです。 diff --git a/stale-read.md b/stale-read.md index 8d4be08038807..42794bc26e738 100644 --- a/stale-read.md +++ b/stale-read.md @@ -69,13 +69,13 @@ create table t1(id int); alter table t1 set tiflash replica 1; ``` -1 分後に次の DDL 操作を実行します。 +1分後に次の DDL 操作を実行します。 ```sql alter table t1 add column c1 int not null; ``` -次に、 ステイル読み取りを使用して 1 分前のデータをクエリします。 +次に、 ステイル読み取りを使用して 1分前のデータをクエリします。 ```sql set @@session.tidb_enforce_mpp=1; diff --git a/statement-summary-tables.md b/statement-summary-tables.md index b2be92ed44f78..631a043bcc472 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -40,7 +40,7 @@ select * from employee where id in (...) and salary between ? and ?; ここでいう「プランダイジェスト」とは、正規化された実行計画によって計算される一意の識別子を指します。正規化処理では定数は無視されます。同じSQL文でも実行計画が異なる場合があるため、異なるカテゴリに分類されることがあります。同じカテゴリのSQL文は、同じ実行計画を持ちます。 -`statements_summary`は、SQL モニタリング メトリックの集計結果が格納されます。一般的に、各モニタリング メトリックには、最大値と平均値が含まれます。たとえば、実行レイテンシーメトリックは、 `AVG_LATENCY` (平均レイテンシー) と`MAX_LATENCY` (最大レイテンシー) の 2 つのフィールドに対応します。 +`statements_summary`は、SQL モニタリング メトリックの集計結果が格納されます。一般的に、各モニタリング メトリックには、最大値と平均値が含まれます。たとえば、実行レイテンシーメトリックは、 `AVG_LATENCY` (平均レイテンシー) と`MAX_LATENCY` (最大レイテンシー) の 2つのフィールドに対応します。 監視メトリクスが最新の状態であることを確認するため、 `statements_summary`テーブルのデータは定期的にクリアされ、最新の集計結果のみが保持されて表示されます。定期的なデータクリアは、 `tidb_stmt_summary_refresh_interval`システム変数によって制御されます。クリア直後にクエリを実行すると、表示されるデータが非常に少なくなる場合があります。 @@ -154,11 +154,11 @@ set global tidb_stmt_summary_refresh_interval = 1800; set global tidb_stmt_summary_history_size = 24; ``` -前述の設定が有効になると、 `statements_summary`テーブルは 30 分ごとにクリアされ、 `statements_summary_history`テーブルには最大 3000 種類の SQL ステートメントが格納されます。各タイプについて、 `statements_summary_history`テーブルには直近 24 期間のデータが格納されます。 `statements_summary_evicted`テーブルには、ステートメント サマリーから SQL ステートメントが削除された直近 24 期間が記録されます。 `statements_summary_evicted`テーブルは 30 分ごとに更新されます。 +前述の設定が有効になると、 `statements_summary`テーブルは 30分ごとにクリアされ、 `statements_summary_history`テーブルには最大 3000種類の SQL ステートメントが格納されます。各タイプについて、 `statements_summary_history`テーブルには直近 24 期間のデータが格納されます。 `statements_summary_evicted`テーブルには、ステートメント サマリーから SQL ステートメントが削除された直近 24 期間が記録されます。 `statements_summary_evicted`テーブルは 30分ごとに更新されます。 > **Note:** > -> - SQL タイプが毎分出現する場合、 `statements_summary_history`には直近 12 時間分のデータが格納されます。SQL タイプが毎日 00:00 から 00:30 の間にのみ出現する場合、 `statements_summary_history`には直近 24 期間分のデータが格納されます。各期間は 1 日です。したがって、 `statements_summary_history`にはこの SQL タイプに関する直近 24 日分のデータが格納されます。 +> - SQL タイプが毎分出現する場合、 `statements_summary_history`には直近 12時間分のデータが格納されます。SQL タイプが毎日 00:00 から 00:30 の間にのみ出現する場合、 `statements_summary_history`には直近 24 期間分のデータが格納されます。各期間は 1日です。したがって、 `statements_summary_history`にはこの SQL タイプに関する直近 24日分のデータが格納されます。 > - `tidb_stmt_summary_history_size` 、 `tidb_stmt_summary_max_stmt_count` 、および`tidb_stmt_summary_max_sql_length`構成項目はメモリ使用量に影響します。これらの構成は、ニーズ、SQLサイズ、SQL数、およびマシン構成に基づいて調整することをお勧めします。大きすぎる値を設定することはお勧めしません。メモリ使用量は`tidb_stmt_summary_history_size` * `tidb_stmt_summary_max_stmt_count` * `tidb_stmt_summary_max_sql_length` * `3` 。 ### 明細書の要約に適切なサイズを設定してください。 {#set-a-proper-size-for-statement-summary} @@ -257,7 +257,7 @@ tidb_stmt_summary_enable_persistent = true > **Note:** > -> - ステートメントサマリーの永続化が有効になっている場合、メモリが履歴データを保持しないため、[パラメータ設定](#parameter-configuration)セクションで説明されている`tidb_stmt_summary_history_size`構成は無効になります。代わりに、永続化のための履歴データの保持期間とサイズを制御するために、次の 3 つの構成が使用されます[`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660) 、 [`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) 、および[`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660) 。 +> - ステートメントサマリーの永続化が有効になっている場合、メモリが履歴データを保持しないため、[パラメータ設定](#parameter-configuration)セクションで説明されている`tidb_stmt_summary_history_size`構成は無効になります。代わりに、永続化のための履歴データの保持期間とサイズを制御するために、次の3つの構成が使用されます[`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660) 、 [`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) 、および[`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660) 。 > - `tidb_stmt_summary_refresh_interval`の値が小さいほど、ディスクに書き込まれるデータ量は多くなります。しかし、これは同時に、ディスクに書き込まれる冗長なデータ量も多くなることを意味します。 @@ -327,7 +327,7 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `QUERY_SAMPLE_TEXT` : SQLカテゴリの元のSQLステートメント。元のステートメントは1つだけ取得されます。 - `TABLE_NAMES` : SQL ステートメントに関係するすべてのテーブル。テーブルが複数ある場合は、それぞれをカンマで区切ります。 - `INDEX_NAMES` : SQL文で使用されるすべてのSQLインデックス。インデックスが複数ある場合は、それぞれをカンマで区切ります。 -- `SAMPLE_USER` : このカテゴリの SQL ステートメントを実行するユーザー。1 人のユーザーのみが対象となります。 +- `SAMPLE_USER` : このカテゴリの SQL ステートメントを実行するユーザー。1人のユーザーのみが対象となります。 - `PLAN_DIGEST` : 実行計画の概要。 - `PLAN` : 元の実行計画。複数のステートメントがある場合は、1つのステートメントのプランのみが使用されます。 - `BINARY_PLAN` : バイナリ形式でエンコードされた元の実行計画。複数のステートメントがある場合は、1つのステートメントのプランのみが使用されます。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行してください。 diff --git a/statistics.md b/statistics.md index 5860c4bcf531f..6f691a168581c 100644 --- a/statistics.md +++ b/statistics.md @@ -89,7 +89,7 @@ TiDBは、テーブルへの変更回数に基づいて、自動的に[`ANALYZE` ヒストグラムは、データの分布を近似的に表現したものです。値の全範囲を複数のバケットに分割し、各バケットに含まれる値の数など、単純なデータを用いて各バケットを記述します。TiDBでは、各テーブルの特定の列に対して等深ヒストグラムが作成されます。この等深ヒストグラムは、区間クエリの推定に利用できます。 -ここで「等深」とは、各バケットに入る値の数が可能な限り均等になることを意味します。たとえば、与えられたセット {1.6, 1.9, 1.9, 2.0, 2.4, 2.6, 2.7, 2.7, 2.8, 2.9, 3.4, 3.5} に対して、4 つのバケットを生成したいとします。等深ヒストグラムは次のようになります。これには [1.6, 1.9]、[2.0, 2.6]、[2.7, 2.8]、[2.9, 3.5] の 4 つのバケットが含まれます。バケットの深さは 3 です。 +ここで「等深」とは、各バケットに入る値の数が可能な限り均等になることを意味します。たとえば、与えられたセット {1.6, 1.9, 1.9, 2.0, 2.4, 2.6, 2.7, 2.7, 2.8, 2.9, 3.4, 3.5} に対して、4つのバケットを生成したいとします。等深ヒストグラムは次のようになります。これには [1.6, 1.9]、[2.0, 2.6]、[2.7, 2.8]、[2.9, 3.5] の 4つのバケットが含まれます。バケットの深さは 3 です。 ![Equal-depth Histogram Example](/media/statistics-1.png) @@ -106,7 +106,7 @@ Count-Min Sketch はハッシュ構造です。 `a = 1`や`IN`クエリ (例え Count-Min Sketch はハッシュ構造であるため、ハッシュ衝突が発生する可能性があります。[`EXPLAIN`](/sql-statements/sql-statement-explain.md)ステートメントにおいて、同等のクエリの推定値が実際の値から大きく乖離する場合、より大きな値とより小さな値がハッシュ化されているとみなすことができます。この場合、ハッシュ衝突を回避するために、以下のいずれかの方法を取ることができます。 - `WITH NUM TOPN`パラメータを変更します。TiDB は、高頻度 (上位 x) のデータを別々に格納し、その他のデータは Count-Min Sketch に格納します。そのため、より大きな値とより小さな値が一緒にハッシュ化されるのを防ぐには、 `WITH NUM TOPN`の値を増やすことができます。TiDB では、デフォルト値は 20 です。最大値は 1024 です。このパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 -- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2 つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2 つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2 つのパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 +- `WITH NUM CMSKETCH DEPTH`と`WITH NUM CMSKETCH WIDTH`の 2つのパラメータを変更します。どちらもハッシュ バケットの数と衝突確率に影響します。実際のシナリオに応じて 2つのパラメータの値を適切に増やすことでハッシュ衝突の確率を減らすことができますが、統計情報のメモリ使用量が増加します。TiDB では、 `WITH NUM CMSKETCH DEPTH`のデフォルト値は 5、 `WITH NUM CMSKETCH WIDTH`のデフォルト値は 2048 です。2つのパラメータの詳細については、 [手動収集](#manual-collection)を参照してください。 ### トップN {#top-n} @@ -165,7 +165,7 @@ TiDB が SQL ステートメントを実行する際、オプティマイザは - TiDB は常に`PREDICATE COLUMNS`情報を[`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables)システム テーブルに 300 秒ごとに書き込みます。 + TiDB は常に`PREDICATE COLUMNS`情報を[`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables)システム テーブルに 300秒ごとに書き込みます。 @@ -233,7 +233,7 @@ TiDBは、統計情報の収集パフォーマンスを向上させるための2 ### 統計サンプリング {#statistics-sampling} -サンプリングは`ANALYZE`ステートメントの 2 つのオプションで利用可能であり、それぞれ異なる収集アルゴリズムに対応しています。 +サンプリングは`ANALYZE`ステートメントの 2つのオプションで利用可能であり、それぞれ異なる収集アルゴリズムに対応しています。 - `WITH NUM SAMPLES`は、TiDB のリザーバーサンプリング方式で実装されているサンプリングセットのサイズを指定します。テーブルが大きい場合、この方式を使用して統計情報を収集することは推奨されません。リザーバーサンプリングの中間結果セットには冗長な結果が含まれるため、メモリなどのリソースに余分な負荷がかかります。 - `WITH FLOAT_NUM SAMPLERATE`は、v5.3.0 で導入されたサンプリング方法です。値の範囲`(0, 1]`を指定することで、サンプリングレートを設定できます。TiDB ではベルヌーイサンプリング方式で実装されており、大規模なテーブルのサンプリングに適しており、収集効率とリソース使用量の面で優れたパフォーマンスを発揮します。 @@ -364,7 +364,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; > > v8.5.6 以降、統計バージョン 1 ( `tidb_analyze_version = 1` ) は非推奨となり、将来のリリースでは削除される予定です。統計バージョン 2 ( `tidb_analyze_version = 2` ) および[統計バージョン1を使用している既存のオブジェクトをバージョン2に移行する](#switch-between-statistics-versions)ことをお勧めします。 -[`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510)変数は、TiDB によって収集される統計情報を制御します。現在、TiDB は`tidb_analyze_version = 1`と`tidb_analyze_version = 2` 2 つの統計バージョンをサポートしています。 +[`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510)変数は、TiDB によって収集される統計情報を制御します。現在、TiDB は`tidb_analyze_version = 1`と`tidb_analyze_version = 2` 2つの統計バージョンをサポートしています。 - TiDB Self-Managedの場合、v5.3.0以降、この変数のデフォルト値が`1`から`2`に変更されます。 - TiDB Cloudの場合、v6.5.0 以降、この変数のデフォルト値が`1`から`2`に変更されます。 @@ -419,7 +419,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; TiDB v6.1.0 以降では、 `SHOW ANALYZE STATUS`ステートメントでクラスタレベルのタスクを表示できるようになりました。TiDB を再起動した後でも、このステートメントを使用すれば再起動前のタスクレコードを表示できます。TiDB v6.1.0 より前では、 `SHOW ANALYZE STATUS`ステートメントではインスタンスレベルのタスクしか表示できず、TiDB の再起動後にタスクレコードはクリアされていました。 -`SHOW ANALYZE STATUS`には、最新のタスク記録のみが表示されます。TiDB v6.1.0 以降では、システムテーブル`mysql.analyze_jobs`を通じて、過去 7 日間の履歴タスクを表示できます。 +`SHOW ANALYZE STATUS`には、最新のタスク記録のみが表示されます。TiDB v6.1.0 以降では、システムテーブル`mysql.analyze_jobs`を通じて、過去 7日間の履歴タスクを表示できます。 [`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610)が設定されていて、TiDB のバックグラウンドで実行されている自動`ANALYZE`タスクがこのしきい値を超えるメモリを使用している場合、タスクは再試行されます。失敗したタスクと再試行されたタスクは`SHOW ANALYZE STATUS`ステートメントの出力で確認できます。 diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index 09b62de5d8413..7c641cca01867 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -71,7 +71,7 @@ TitanはRocksDBと互換性があるため、RocksDBを使用する既存のTiKV Titan を有効にした後、RocksDB に保存されている既存のデータは、すぐに Titan エンジンに移動されるわけではありません。新しいデータが TiKV に書き込まれ、RocksDB が圧縮を実行すると、**値は徐々にキーから分離され、 Titan に書き込まれます**。同様に、 BRスナップショット/ログを通じて復元されたデータ、スケーリング中に変換されたデータ、またはTiDB Lightning物理インポート モードによってインポートされたデータは、Titan に直接書き込まれません。圧縮が進むにつれて、処理された SST ファイル内のデフォルト値 ( `32KB` ) の[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)を超える大きな値が Titan に分離されます。TiKV**の詳細 > Titan kv > blob ファイル サイズ**パネルを観察してデータ サイズを見積もることで、Titan に保存されているファイルのサイズを監視できます。 -書き込みプロセスを高速化したい場合は、tikv-ctl を使用して TiKV クラスター全体のデータを手動で圧縮できます。詳細は[手作業による圧縮](/tikv-control.md#compact-data-of-the-whole-tikv-cluster-manually)を参照してください。RocksDB から Titan への変換中はデータアクセスが継続的に行われるため、RocksDB のブロックキャッシュによってデータ変換プロセスが大幅に高速化されます。テストでは、tikv-ctl を使用することで、670 GiB の TiKV データを 1 時間で Titan に変換できました。 +書き込みプロセスを高速化したい場合は、tikv-ctl を使用して TiKV クラスター全体のデータを手動で圧縮できます。詳細は[手作業による圧縮](/tikv-control.md#compact-data-of-the-whole-tikv-cluster-manually)を参照してください。RocksDB から Titan への変換中はデータアクセスが継続的に行われるため、RocksDB のブロックキャッシュによってデータ変換プロセスが大幅に高速化されます。テストでは、tikv-ctl を使用することで、670 GiB の TiKV データを 1時間で Titan に変換できました。 Titan BLOBファイル内の値は連続しておらず、Titanのキャッシュは値レベルであるため、圧縮時にはBLOBキャッシュは役に立ちません。TitanからRocksDBへの変換速度は、RocksDBからTitanへの変換速度よりも桁違いに遅くなります。テストでは、TiKVノード上の800GiBのTitanデータをtikv-ctlでRocksDBに完全圧縮変換するのに12時間かかりました。 diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index b1d636ca3d6ce..8c56d4b869109 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -148,6 +148,6 @@ Titan は、選択された BLOB ファイルについて、各値に対応す > **Note:** > -> `scan100` 100 件のレコードをスキャンすることを意味し、 `scan10000` 10000 件のレコードをスキャンすることを意味します。 +> `scan100` 100件のレコードをスキャンすることを意味し、 `scan10000` 10000件のレコードをスキャンすることを意味します。 表から、行幅が`16KB`の場合、すべてのYCSBワークロードにおいて、TitanがRocksDBよりも優れたパフォーマンスを発揮することがわかります。ただし、 Dumplingの実行など、スキャン負荷が高い極端なシナリオでは、行幅が`16KB`の場合のTitanのパフォーマンスは10%低下します。したがって、ワークロードが主に書き込みとポイント読み取りである場合は、 `min-blob-size`から`1KB`に設定することをお勧めします。ワークロードに大量のスキャンが含まれる場合は、 `min-blob-size`から少なくとも`16KB`に設定することをお勧めします。 diff --git a/sync-diff-inspector/route-diff.md b/sync-diff-inspector/route-diff.md index b965b10d7d123..e1fa7e9c42c26 100644 --- a/sync-diff-inspector/route-diff.md +++ b/sync-diff-inspector/route-diff.md @@ -82,7 +82,7 @@ target-table = "t_2" # The name of the target table ### 例 {#examples} -アップストリーム クラスターに 7 つのテーブルがあるとします。 +アップストリーム クラスターに 7つのテーブルがあるとします。 - `inspector_mysql_0.tb_emp1` - `Inspector_mysql_0.tb_emp1` diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md index 49a4fecfa45ca..a4542db5b83da 100644 --- a/sync-diff-inspector/sync-diff-inspector-overview.md +++ b/sync-diff-inspector/sync-diff-inspector-overview.md @@ -266,7 +266,7 @@ sync-diff-inspector のログは`${output}/sync_diff.log`に保存され、そ ### 進捗 {#progress} -実行中の sync-diff-inspector は定期的に (10 秒ごと) チェックポイントの進行状況を出力。チェックポイントは`${output}/checkpoint/sync_diff_checkpoints.pb`にあり、その中で`${output}`は`output-dir`ファイル内の`config.toml`の値です。 +実行中の sync-diff-inspector は定期的に (10秒ごと) チェックポイントの進行状況を出力。チェックポイントは`${output}/checkpoint/sync_diff_checkpoints.pb`にあり、その中で`${output}`は`output-dir`ファイル内の`config.toml`の値です。 ### 結果 {#result} diff --git a/system-variables.md b/system-variables.md index 4adfd354f71d5..63d64a2dc9d5f 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1350,7 +1350,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 範囲: `[0, 2147483647]` - この変数は、TiDB `backoff`の最大再試行待機時間の重みを増やすために使用されます。つまり、内部ネットワークまたは他のコンポーネント(TiKV、PD) の障害が発生した場合に再試行要求を送信する際の最大再試行待機時間です。この変数を使用して最大再試行待機時間を調整でき、最小値は`1`です。 - 例えば、TiDB が TiKV から KV を取得する際の基本再試行待機時間は 15 秒です。 `tidb_backoff_weight = 2`の場合、KV を取得する際の最大再試行待機時間は、*基本時間 * 2 = 30 秒*です。 + 例えば、TiDB が TiKV から KV を取得する際の基本再試行待機時間は 15秒です。 `tidb_backoff_weight = 2`の場合、KV を取得する際の最大再試行待機時間は、*基本時間 * 2 = 30秒*です。 ネットワーク環境が悪い場合、この変数の値を適切に増やすことで、タイムアウトによってアプリケーション側に発生するエラー報告を効果的に軽減できます。アプリケーション側でエラー情報をより迅速に受信したい場合は、この変数の値を最小化してください。 @@ -1814,10 +1814,10 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; 例： -4 つの TiDB ノードと複数の TiKV ノードを持つクラスタがあるとします。このクラスタでは、各 TiDB ノードがインデックスのバックフィルを実行でき、リージョンはすべての TiKV ノードに均等に分散されています。 `tidb_ddl_reorg_max_write_speed`を`100MiB`に設定すると、次のようになります。 +4つの TiDB ノードと複数の TiKV ノードを持つクラスタがあるとします。このクラスタでは、各 TiDB ノードがインデックスのバックフィルを実行でき、リージョンはすべての TiKV ノードに均等に分散されています。 `tidb_ddl_reorg_max_write_speed`を`100MiB`に設定すると、次のようになります。 -- グローバルソートが無効になっている場合、一度に TiDB ノードが TiKV に書き込むのは 1 つだけです。この場合、TiKV ノードあたりの最大書き込み帯域幅は`100MiB`です。 -- グローバルソートが有効になっている場合、4 つの TiDB ノードすべてが同時に TiKV に書き込むことができます。この場合、TiKV ノードあたりの最大書き込み帯域幅は`4 * 100MiB = 400MiB`です。 +- グローバルソートが無効になっている場合、一度に TiDB ノードが TiKV に書き込むのは 1つだけです。この場合、TiKV ノードあたりの最大書き込み帯域幅は`100MiB`です。 +- グローバルソートが有効になっている場合、4つの TiDB ノードすべてが同時に TiKV に書き込むことができます。この場合、TiKV ノードあたりの最大書き込み帯域幅は`4 * 100MiB = 400MiB`です。 ### tidb_ddl_reorg_worker_cnt @@ -1860,7 +1860,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - この変数は、行数を推定する際のフィルタ条件における`like` 、 `rlike` 、および`regexp`関数のデフォルトの選択性を設定するために使用されます。また、この変数は、これらの関数の推定を支援するために TopN を有効にするかどうかも制御します。 - TiDB は統計情報を使用してフィルタ条件`like`を推定しようとします。しかし、 `like`が複雑な文字列に一致する場合、または`rlike`や`regexp`を使用する場合、TiDB は統計情報を十分に使用できないことが多く、代わりにデフォルト値`0.8`が選択率として設定され、推定が不正確になります。 - この変数は、前述の動作を変更するために使用されます。変数が`0`以外の値に設定されている場合、選択率は`0.8`ではなく、指定された変数の値になります。 -- 変数が`0`に設定されている場合、TiDB は統計情報で TopN を使用して評価し、精度を向上させ、前述の 3 つの関数を推定する際に統計情報で NULL の数を考慮します。前提条件として、 [`tidb_analyze_version`](#tidb_analyze_version-new-in-v510)が`2`に設定されているときに統計情報が収集されます。このような評価は、パフォーマンスに若干影響を与える可能性があります。 +- 変数が`0`に設定されている場合、TiDB は統計情報で TopN を使用して評価し、精度を向上させ、前述の3つの関数を推定する際に統計情報で NULL の数を考慮します。前提条件として、 [`tidb_analyze_version`](#tidb_analyze_version-new-in-v510)が`2`に設定されているときに統計情報が収集されます。このような評価は、パフォーマンスに若干影響を与える可能性があります。 - 変数が`0.8`以外の値に設定されている場合、TiDB は`not like` 、 `not rlike` 、および`not regexp`の推定値をそれに応じて調整します。 ### tidb_disable_txn_auto_retry @@ -1926,7 +1926,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 単位：行 - この値が`0`より大きい場合、TiDB は`INSERT`などのコミットステートメントをより小さなトランザクションにバッチ処理します。これによりメモリ使用量が削減され、一括変更によって`txn-total-size-limit`に達しないようにすることができます。 - `0`という値のみがACID準拠を保証します。この値を他の値に設定すると、TiDB の原子性と分離性の保証が損なわれます。 -- この変数を機能させるには、 `tidb_enable_batch_dml`と、 `tidb_batch_insert`および`tidb_batch_delete`の少なくとも 1 つを有効にする必要があります。 +- この変数を機能させるには、 `tidb_enable_batch_dml`と、 `tidb_batch_insert`および`tidb_batch_delete`の少なくとも 1つを有効にする必要があります。 > **Note:** > @@ -2044,7 +2044,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、非推奨の batch-dml 機能を有効にするかどうかを制御します。有効にすると、特定のステートメントが複数のトランザクションに分割される可能性があり、これは非アトミックであるため、慎重に使用する必要があります。batch-dml を使用する場合は、操作対象のデータに対して同時実行操作がないことを確認する必要があります。これを機能させるには、 `tidb_batch_dml_size`に正の値を指定し、 `tidb_batch_insert`と`tidb_batch_delete`の少なくとも 1 つを有効にする必要があります。 +- この変数は、非推奨の batch-dml 機能を有効にするかどうかを制御します。有効にすると、特定のステートメントが複数のトランザクションに分割される可能性があり、これは非アトミックであるため、慎重に使用する必要があります。batch-dml を使用する場合は、操作対象のデータに対して同時実行操作がないことを確認する必要があります。これを機能させるには、 `tidb_batch_dml_size`に正の値を指定し、 `tidb_batch_insert`と`tidb_batch_delete`の少なくとも 1つを有効にする必要があります。 ### `tidb_enable_batch_query_region` New in v8.5.7 - スコープ: GLOBAL @@ -2052,11 +2052,11 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value) への適用: No - 型: Boolean - デフォルト値: `OFF` -- この変数は、Batch Query Region 機能を有効にするかどうかを制御します。TiDB がデータにアクセスする際、ローカルの Region キャッシュを更新するために、Region のルーティング情報を PD に問い合わせます。デフォルトでは、`GetRegion`（キーを含む Region を問い合わせる）、`GetPrevRegion`（キーに基づいて直前に隣接する Region を問い合わせる）、`GetRegionByID`（Region ID によって問い合わせる）などのポイントクエリリクエストは、それぞれ独立した unary gRPC リクエストです。Batch Query Region 機能は、これら 3 種類のリクエストをバッチ化してマージします。 +- この変数は、Batch Query Region 機能を有効にするかどうかを制御します。TiDB がデータにアクセスする際、ローカルの Region キャッシュを更新するために、Region のルーティング情報を PD に問い合わせます。デフォルトでは、`GetRegion`（キーを含む Region を問い合わせる）、`GetPrevRegion`（キーに基づいて直前に隣接する Region を問い合わせる）、`GetRegionByID`（Region ID によって問い合わせる）などのポイントクエリリクエストは、それぞれ独立した unary gRPC リクエストです。Batch Query Region 機能は、これら3種類のリクエストをバッチ化してマージします。 - この変数が `OFF` の場合、TiDB は Region 情報に対する各ポイントクエリを、独立した unary gRPC リクエストとして PD に送信します。 - この変数が `ON` の場合、TiDB は短時間内に同時発生した Region 情報へのポイントクエリリクエストを `QueryRegion` gRPC stream を通じてバッチ化し、まとめて PD に送信します。PD はそれらを処理して結果を返します。TSO リクエストのバッチ化メカニズムと同様に、この機能により gRPC リクエスト数を大幅に削減でき、その結果、大量の Region クエリリクエストを処理する際の PD leader の CPU オーバーヘッドを低減できます。 -- この変数は、`BatchScanRegions` のような scan リクエストには影響しません。`BatchScanRegions` は複数のキー範囲に対するクエリを 1 つのリクエストにマージできますが、これは独立した unary gRPC リクエストであり、`QueryRegion` のバッチ処理経路は通りません。 -- この変数の変更は、TiDB を再起動しなくてもクラスター全体に即座に反映されるため、動的に有効化または無効化できます。この変数を有効にすると、TiDB は Region 情報の取得にバッチモードへ切り替わります。無効にすると、TiDB は unary gRPC リクエストを 1 件ずつ送信する方式に戻ります。 +- この変数は、`BatchScanRegions` のような scan リクエストには影響しません。`BatchScanRegions` は複数のキー範囲に対するクエリを 1つのリクエストにマージできますが、これは独立した unary gRPC リクエストであり、`QueryRegion` のバッチ処理経路は通りません。 +- この変数の変更は、TiDB を再起動しなくてもクラスター全体に即座に反映されるため、動的に有効化または無効化できます。この変数を有効にすると、TiDB は Region 情報の取得にバッチモードへ切り替わります。無効にすると、TiDB は unary gRPC リクエストを 1件ずつ送信する方式に戻ります。 - 次のようなシナリオでは、Batch Query Region 機能を有効にできます。 - クラスター内の Region 数が多く、TiDB のクエリ同時実行性が高く、Region キャッシュのミスや無効化によって多数の同時 Region クエリリクエストが発生し、PD leader に高い CPU 負荷がかかっている場合。 - クラスター内で Region split、Region merge、または Leader migration などの変更が頻繁に発生し、多数の Region キャッシュ無効化が起こってクエリリクエストの集中的なリトライが引き起こされ、その結果、大量の Region クエリリクエストが生成される場合。 @@ -2116,7 +2116,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 指定可能な値: `OFF` 、 `ON` -- この変数は、対応する TiDB インスタンスが DDL の所有者になれるかどうかを制御します。現在の TiDB クラスタに TiDB インスタンスが 1 つしかない場合、それが DDL の所有者になることを防ぐことはできません。つまり、 `OFF`に設定することはできません。 +- この変数は、対応する TiDB インスタンスが DDL の所有者になれるかどうかを制御します。現在の TiDB クラスタに TiDB インスタンスが 1つしかない場合、それが DDL の所有者になることを防ぐことはできません。つまり、 `OFF`に設定することはできません。 ### tidb_enable_collect_execution_info @@ -2348,7 +2348,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用: Yes - 型: Boolean - デフォルト値: `OFF` -- この変数は、`Prepare` ステートメントの結果をキャッシュするかどうかを制御します。通常、アプリケーションは `Prepare` を 1 回だけ実行し、その後 `Execute` を複数回実行するだけで済みます。以降のすべての `Execute` 操作では、最初の `Prepare` の結果を再利用できます。アプリケーションが同じ `Prepare` ステートメントを繰り返し送信する場合は、この変数を有効にすることで、TiDB が同一の `Prepare` ステートメントの結果をキャッシュして再利用できるようになり、リソース消費を削減できます。 +- この変数は、`Prepare` ステートメントの結果をキャッシュするかどうかを制御します。通常、アプリケーションは `Prepare` を 1回だけ実行し、その後 `Execute` を複数回実行するだけで済みます。以降のすべての `Execute` 操作では、最初の `Prepare` の結果を再利用できます。アプリケーションが同じ `Prepare` ステートメントを繰り返し送信する場合は、この変数を有効にすることで、TiDB が同一の `Prepare` ステートメントの結果をキャッシュして再利用できるようになり、リソース消費を削減できます。 ### tidb_enable_gogc_tuner New in v6.4.0 @@ -2745,11 +2745,11 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、データを読み取るオペレータに対して動的メモリ制御機能を有効にするかどうかを制御します。デフォルトでは、このオペレータは、 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)がデータ読み取りに許可する最大スレッド数を有効にします。単一の SQL ステートメントのメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データを読み取るオペレータは 1 つのスレッドを停止します。 +- この変数は、データを読み取るオペレータに対して動的メモリ制御機能を有効にするかどうかを制御します。デフォルトでは、このオペレータは、 [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)がデータ読み取りに許可する最大スレッド数を有効にします。単一の SQL ステートメントのメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データを読み取るオペレータは 1つのスレッドを停止します。 -- データを読み取るオペレーターにスレッドが 1 つだけ残っており、単一の SQL ステートメントのメモリ使用量が常に[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超える場合、この SQL ステートメントは[データをディスクに書き出す](/system-variables.md#tidb_enable_tmp_storage_on_oom)などの他のメモリ制御動作をトリガーします。 +- データを読み取るオペレーターにスレッドが 1つだけ残っており、単一の SQL ステートメントのメモリ使用量が常に[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超える場合、この SQL ステートメントは[データをディスクに書き出す](/system-variables.md#tidb_enable_tmp_storage_on_oom)などの他のメモリ制御動作をトリガーします。 - この変数は、SQL ステートメントがデータの読み取りのみを行う場合にメモリ使用量を効果的に制御します。結合や集計などの計算操作が必要な場合、メモリ使用量は`tidb_mem_quota_query`の制御下にない可能性があり、メモリ不足エラーのリスクが高まります。 @@ -2822,7 +2822,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 指定可能な値: `OFF` 、 `ON` -- この変数は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。現在の TiDB クラスタに TiDB インスタンスが 1 つしかない場合、このインスタンスで統計の自動更新を無効にすることはできません。つまり、この変数を`OFF`に設定することはできません。 +- この変数は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。現在の TiDB クラスタに TiDB インスタンスが 1つしかない場合、このインスタンスで統計の自動更新を無効にすることはできません。つまり、この変数を`OFF`に設定することはできません。 ### tidb_enable_stmt_summary New in v3.0.4 @@ -3236,7 +3236,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > - 頻繁に更新されるシナリオでは、 `tidb_gc_life_time`の値が大きい場合（日数または月数）、次のような潜在的な問題が発生する可能性があります。 > - ストレージ使用量の増加 > - 大量の履歴データは、特に`select count(*) from t`のような範囲クエリの場合、パフォーマンスに一定の影響を与える可能性があります。 -> - `tidb_gc_life_time`より長く実行されているトランザクションがある場合、GC の実行を継続するために、 `start_ts`以降のデータが保持されます。たとえば、 `tidb_gc_life_time`が 10 分に設定されている場合、実行中のすべてのトランザクションの中で、最も早く開始されたトランザクションが 15 分間実行されている場合、GC は直近 15 分間のデータを保持します。 +> - `tidb_gc_life_time`より長く実行されているトランザクションがある場合、GC の実行を継続するために、 `start_ts`以降のデータが保持されます。たとえば、 `tidb_gc_life_time`が 10分に設定されている場合、実行中のすべてのトランザクションの中で、最も早く開始されたトランザクションが 15分間実行されている場合、GC は直近 15分間のデータを保持します。 ### tidb_gc_max_wait_time New in v6.1.0 @@ -3487,7 +3487,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 範囲: `[1, 256]` - 単位：スレッド - この変数は`hash aggregation` `final`アルゴリズムの並行性を設定するために使用されます。 -- 集計関数のパラメータが区別できない場合、 `HashAgg`は、 `partial`フェーズと`final`の 2 つのフェーズで同時に実行されます。 +- 集計関数のパラメータが区別できない場合、 `HashAgg`は、 `partial`フェーズと`final`の 2つのフェーズで同時に実行されます。 - `-1`という値が指定された場合、代わりに`tidb_executor_concurrency`という値が使用されます。 ### tidb_hashagg_partial_concurrency @@ -3504,7 +3504,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 範囲: `[1, 256]` - 単位：スレッド - この変数は`hash aggregation` `partial`アルゴリズムの並行性を設定するために使用されます。 -- 集計関数のパラメータが区別できない場合、 `HashAgg`は、 `partial`フェーズと`final`の 2 つのフェーズで同時に実行されます。 +- 集計関数のパラメータが区別できない場合、 `HashAgg`は、 `partial`フェーズと`final`の 2つのフェーズで同時に実行されます。 - `-1`という値が指定された場合、代わりに`tidb_executor_concurrency`という値が使用されます。 ### tidb_historical_stats_duration New in v6.6.0 @@ -3795,7 +3795,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - この変数は、以下のシナリオで特定のキーをロックするかどうかを制御するために使用されます。値が`ON`に設定されている場合、これらのキーはロックされます。値が`OFF`に設定されている場合、これらのキーはロックされません。 - `INSERT IGNORE`および`REPLACE`ステートメントに重複するキーがあります。v6.1.6 より前は、これらのキーはロックされていませんでした。この問題は[#42121](https://github.com/pingcap/tidb/issues/42121)で修正されました。 - `UPDATE`ステートメント内の一意キーは、キーの値が変更されない場合にロックされます。v6.5.2 より前は、これらのキーはロックされていませんでした。この問題は[#36438](https://github.com/pingcap/tidb/issues/36438)で修正されました。 -- トランザクションの一貫性と合理性を維持するため、この値を変更することは推奨されません。TiDB のアップグレードによってこれら 2 つの修正が原因で深刻なパフォーマンスの問題が発生し、ロックなしの動作が許容できる場合 (前述の問題を参照)、この変数を`OFF`に設定できます。 +- トランザクションの一貫性と合理性を維持するため、この値を変更することは推奨されません。TiDB のアップグレードによってこれら2つの修正が原因で深刻なパフォーマンスの問題が発生し、ロックなしの動作が許容できる場合 (前述の問題を参照)、この変数を`OFF`に設定できます。 ### tidb_log_file_max_days New in v5.3.0 @@ -4991,7 +4991,7 @@ EXPLAIN FORMAT='brief' SELECT COUNT(1) FROM t WHERE a = 1 AND b IS NOT NULL; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `ON` 。v8.3.0 より前のバージョンでは、デフォルト値は`OFF`です。 -- オプティマイザが`Projection`演算子を TiKV コプロセッサにプッシュダウンすることを許可するかどうかを指定します。有効にすると、オプティマイザは次の 3 種類の`Projection`演算子を TiKV にプッシュダウンする可能性があります。 +- オプティマイザが`Projection`演算子を TiKV コプロセッサにプッシュダウンすることを許可するかどうかを指定します。有効にすると、オプティマイザは次の3種類の`Projection`演算子を TiKV にプッシュダウンする可能性があります。 - 演算子のトップレベル式はすべて[JSONクエリ関数](/functions-and-operators/json-functions/json-functions-search.md)または[JSON値属性関数](/functions-and-operators/json-functions/json-functions-return.md)です。例: `SELECT JSON_EXTRACT(data, '$.name') FROM users;` 。 - 演算子の最上位式には、JSON クエリ関数または JSON 値属性関数と、直接列読み取りが混在しています。例: `SELECT JSON_DEPTH(data), name FROM users;` 。 - 演算子の最上位式はすべて直接列読み取りであり、出力列の数は入力列の数よりも少ないです。例: `SELECT name FROM users;` 。 @@ -5169,7 +5169,7 @@ SHOW WARNINGS; - 型: Boolean - デフォルト値: `ON` - この変数は`COUNT(DISTINCT)`集計を MPP モードの 3 段階集計に書き換えるかどうかを指定します。 -- この変数は現在、 `COUNT(DISTINCT)`を 1 つだけ含む集計に適用されます。 +- この変数は現在、 `COUNT(DISTINCT)`を 1つだけ含む集計に適用されます。 ### tidb_opt_tiflash_concurrency_factor @@ -5614,7 +5614,7 @@ SHOW WARNINGS; - 型: 整数 - デフォルト値: `0` - 範囲: `[-2147483648, 0]` -- この変数は、TiDB が現在のセッションで読み取ることができる履歴データの時間範囲を設定するために使用されます。値を設定すると、TiDB はこの変数で許可されている範囲から可能な限り新しいタイムスタンプを選択し、以降のすべての読み取り操作はこのタイムスタンプに対して実行されます。たとえば、この変数の値が`-5`に設定されている場合、TiKV に対応する履歴バージョンのデータが存在するという条件の下で、TiDB は 5 秒以内の時間範囲内で可能な限り新しいタイムスタンプを選択します。 +- この変数は、TiDB が現在のセッションで読み取ることができる履歴データの時間範囲を設定するために使用されます。値を設定すると、TiDB はこの変数で許可されている範囲から可能な限り新しいタイムスタンプを選択し、以降のすべての読み取り操作はこのタイムスタンプに対して実行されます。たとえば、この変数の値が`-5`に設定されている場合、TiKV に対応する履歴バージョンのデータが存在するという条件の下で、TiDB は 5秒以内の時間範囲内で可能な限り新しいタイムスタンプを選択します。 ### tidb_record_plan_in_slow_log @@ -5725,7 +5725,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントと[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。このシステム変数が`ON`に設定されている場合、これらの 2 つの方法で現在のセッションまたは現在のステートメントのバインドされたリソース グループを変更するには`SUPER` 、 `RESOURCE_GROUP_ADMIN` 、または`RESOURCE_GROUP_USER`の特権が必要です。 `OFF`に設定されている場合、これらの権限は不要となり、この変数がない以前の TiDB バージョンと同じ動作になります。 +- この変数は[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントと[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。このシステム変数が`ON`に設定されている場合、これらの 2つの方法で現在のセッションまたは現在のステートメントのバインドされたリソース グループを変更するには`SUPER` 、 `RESOURCE_GROUP_ADMIN` 、または`RESOURCE_GROUP_USER`の特権が必要です。 `OFF`に設定されている場合、これらの権限は不要となり、この変数がない以前の TiDB バージョンと同じ動作になります。 - TiDB クラスターを以前のバージョンから v8.2.0 以降にアップグレードすると、この変数のデフォルト値は`OFF`に設定され、この機能はデフォルトで無効になります。 ### tidb_retry_limit @@ -5762,7 +5762,7 @@ SHOW WARNINGS; - 型: Enumeration - デフォルト値: `OFF` - 指定可能な値: `OFF` 、 `LOCAL` -- ランタイムフィルタのモード、つまり**フィルタ送信演算子**と**フィルタ受信演算子**の関係を制御します。モードは`OFF`と`LOCAL`の 2 つあります。 `OFF`はランタイムフィルタを無効にすることを意味します。 `LOCAL`はローカルモードでランタイムフィルタを有効にすることを意味します。詳細については、[ランタイムフィルタモード](/runtime-filter.md#runtime-filter-mode)を参照してください。 +- ランタイムフィルタのモード、つまり**フィルタ送信演算子**と**フィルタ受信演算子**の関係を制御します。モードは`OFF`と`LOCAL`の 2つあります。 `OFF`はランタイムフィルタを無効にすることを意味します。 `LOCAL`はローカルモードでランタイムフィルタを有効にすることを意味します。詳細については、[ランタイムフィルタモード](/runtime-filter.md#runtime-filter-mode)を参照してください。 ### tidb_runtime_filter_type New in v7.2.0 @@ -5772,7 +5772,7 @@ SHOW WARNINGS; - 型: Enumeration - デフォルト値: `IN` - 指定可能な値: `IN` -- 生成されたフィルター演算子によって使用される述語のタイプを制御します。現在、サポートされているタイプは`IN` 1 つだけです。詳細については、[ランタイムフィルタタイプ](/runtime-filter.md#runtime-filter-type)を参照してください。 +- 生成されたフィルター演算子によって使用される述語のタイプを制御します。現在、サポートされているタイプは`IN` 1つだけです。詳細については、[ランタイムフィルタタイプ](/runtime-filter.md#runtime-filter-type)を参照してください。 ### tidb_scatter_region @@ -5900,8 +5900,7 @@ SHOW WARNINGS; - 型: 整数 - デフォルト値: `9223372036854775807` - 範囲: `[1, 9223372036854775807]` -- この変数は、 [`AUTO_RANDOM`](/auto-random.md)または[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)属性に割り当てる連続 ID の最大数を制御します。通常、 `AUTO_RANDOM` ID または`SHARD_ROW_ID_BITS`注釈付き行 ID は、1 つのトランザクション内で増分され、連続しています。この変数を使用すると、大規模なトランザクションシナリオにおけるホットスポットの問題を解決できます。 - +- この変数は、 [`AUTO_RANDOM`](/auto-random.md)または[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)属性に割り当てる連続 ID の最大数を制御します。通常、 `AUTO_RANDOM` ID または`SHARD_ROW_ID_BITS`注釈付き行 ID は、1つのトランザクション内で増分され、連続しています。この変数を使用すると、大規模なトランザクションシナリオにおけるホットスポットの問題を解決できます。 ### tidb_shard_row_id_bits New in v8.4.0 - 対象範囲: セッション | グローバル @@ -5989,7 +5988,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: 整数 - 範囲: `[0, 1000000]` - この変数は、TiDBノードごとに1秒あたりに書き込めるスロークエリログエントリの最大数を制御します。 - - `0`という値は、1 秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 + - `0`という値は、1秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 - `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。 - この変数は、高負荷条件下で過剰なスロークエリログが生成されるのを防ぐために、 [`tidb_slow_log_rules`](#tidb_slow_log_rules-new-in-v856)と組み合わせて使用されることが多いです。 @@ -6540,8 +6539,8 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - この変数は、TiDB が TSO RPC リクエストを PD に送信するモードを切り替えます。このモードによって、TSO RPC リクエストが並列処理されるかどうかが決まり、各 TS 取得操作のバッチ待機時間に影響します。これにより、特定のシナリオにおいて、クエリ実行中の TS 取得の待機時間を短縮できます。 - `DEFAULT` : TiDB は、特定の期間にわたる TS 取得操作を単一の TSO RPC リクエストに収集し、バッチでタイムスタンプを取得するために PD に送信します。したがって、各 TS 取得操作の所要時間は、バッチ処理を待つ時間と RPC の実行時間で構成されます。 `DEFAULT`モードでは、異なる TSO RPC リクエストが直列に処理され、各 TS 取得操作の平均所要時間は、TSO RPC リクエストの実際の時間コストの約 1.5 倍になります。 - - `PARALLEL` : このモードでは、TiDB は各バッチの収集時間を`DEFAULT`モードの半分に短縮し、同時に 2 つの TSO RPC リクエストを維持しようとします。このようにして、各 TS 取得操作の平均時間は理論的には TSO RPC 時間の約 1.25 倍に短縮でき、これは`DEFAULT`モードの時間コストの約 83% になります。ただし、バッチ処理の効果は低下し、TSO RPC リクエストの数は`DEFAULT`モードの約 2 倍に増加します。 - - `PARALLEL-FAST` : `PARALLEL`モードと同様に、このモードでは、TiDB は各バッチの収集時間を`DEFAULT`モードの 4 分の 1 に短縮し、同時に 4 つの TSO RPC リクエストを維持しようとします。このようにして、各 TS 取得操作の平均時間は、理論的には TSO RPC 時間の約 1.125 倍に短縮でき、これは`DEFAULT`モードの時間コストの約 75% になります。ただし、バッチ処理の効果はさらに低下し、TSO RPC リクエストの数は`DEFAULT`モードの約 4 倍に増加します。 + - `PARALLEL` : このモードでは、TiDB は各バッチの収集時間を`DEFAULT`モードの半分に短縮し、同時に 2つの TSO RPC リクエストを維持しようとします。このようにして、各 TS 取得操作の平均時間は理論的には TSO RPC 時間の約 1.25 倍に短縮でき、これは`DEFAULT`モードの時間コストの約 83% になります。ただし、バッチ処理の効果は低下し、TSO RPC リクエストの数は`DEFAULT`モードの約 2 倍に増加します。 + - `PARALLEL-FAST` : `PARALLEL`モードと同様に、このモードでは、TiDB は各バッチの収集時間を`DEFAULT`モードの 4分の 1 に短縮し、同時に 4つの TSO RPC リクエストを維持しようとします。このようにして、各 TS 取得操作の平均時間は、理論的には TSO RPC 時間の約 1.125 倍に短縮でき、これは`DEFAULT`モードの時間コストの約 75% になります。ただし、バッチ処理の効果はさらに低下し、TSO RPC リクエストの数は`DEFAULT`モードの約 4 倍に増加します。 - 以下の条件が満たされた場合、パフォーマンスの向上を目的として、この変数を`PARALLEL`または`PARALLEL-FAST`に切り替えることを検討してください。 @@ -6578,7 +6577,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `0` - 範囲: `[0, 9223372036854775807]` -- この変数は、各 TiDB ノード上の TTL ジョブにおける`DELETE`ステートメントのレートを制限するために使用されます。この値は、TTL ジョブ内の単一ノードで 1 秒あたりに許可される`DELETE`ステートメントの最大数を表します。この変数が`0`に設定されている場合、制限は適用されません。詳細については、[存続時間（TTL）](/time-to-live.md)を参照してください。 +- この変数は、各 TiDB ノード上の TTL ジョブにおける`DELETE`ステートメントのレートを制限するために使用されます。この値は、TTL ジョブ内の単一ノードで 1秒あたりに許可される`DELETE`ステートメントの最大数を表します。この変数が`0`に設定されている場合、制限は適用されません。詳細については、[存続時間（TTL）](/time-to-live.md)を参照してください。 ### tidb_ttl_delete_batch_size New in v6.5.0 @@ -6880,7 +6879,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > **Note:** > > - この変数は、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)が`0`より大きい場合にのみ有効になります。つまり、 [tiflash_mem_quota_query_per_node](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)が`0`または`-1`の場合、 `tiflash_query_spill_ratio`が`0`より大きい場合でも、クエリレベルのスピルは有効になりません。 -> - TiFlashクエリ レベルのスピルが有効になっている場合、個々のTiFlashオペレーターのスピルしきい値は自動的に無効になります。つまり、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)と`tiflash_query_spill_ratio`両方が 0 より大きい場合、3 つの変数[tidb_max_bytes_before_tiflash_external_sort](/system-variables.md#tidb_max_bytes_before_tiflash_external_sort-new-in-v700) 、 [tidb_max_bytes_before_tiflash_external_group_by](/system-variables.md#tidb_max_bytes_before_tiflash_external_group_by-new-in-v700) 、および[tidb_max_bytes_before_tiflash_external_join](/system-variables.md#tidb_max_bytes_before_tiflash_external_join-new-in-v700)は自動的に無効になり、 `0`に設定するのと同等になります。 +> - TiFlashクエリ レベルのスピルが有効になっている場合、個々のTiFlashオペレーターのスピルしきい値は自動的に無効になります。つまり、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)と`tiflash_query_spill_ratio`両方が 0 より大きい場合、3つの変数[tidb_max_bytes_before_tiflash_external_sort](/system-variables.md#tidb_max_bytes_before_tiflash_external_sort-new-in-v700) 、 [tidb_max_bytes_before_tiflash_external_group_by](/system-variables.md#tidb_max_bytes_before_tiflash_external_group_by-new-in-v700) 、および[tidb_max_bytes_before_tiflash_external_join](/system-variables.md#tidb_max_bytes_before_tiflash_external_join-new-in-v700)は自動的に無効になり、 `0`に設定するのと同等になります。 ### tiflash_replica_read New in v7.3.0 @@ -6930,9 +6929,9 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `0` - 範囲: `[0, 2147483647]` - 単位：ミリ秒 -- `tikv_client_read_timeout`を使用すると、クエリで TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定できます。TiDB クラスタが不安定なネットワーク環境または深刻な TiKV I/Oレイテンシーのジッターがある環境にあり、アプリケーションが SQL クエリのレイテンシーに敏感な場合は、 `tikv_client_read_timeout`を設定して、TiKV RPC 読み取りリクエストのタイムアウトを短縮できます。この場合、TiKV ノードで I/Oレイテンシーのジッターが発生すると、TiDB はすぐにタイムアウトして、次の TiKVリージョンピアがある TiKV ノードに RPC リクエストを再送信できます。すべての TiKVリージョンピアのリクエストがタイムアウトした場合、TiDB はデフォルトのタイムアウト (通常 40 秒) で再試行します。 +- `tikv_client_read_timeout`を使用すると、クエリで TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定できます。TiDB クラスタが不安定なネットワーク環境または深刻な TiKV I/Oレイテンシーのジッターがある環境にあり、アプリケーションが SQL クエリのレイテンシーに敏感な場合は、 `tikv_client_read_timeout`を設定して、TiKV RPC 読み取りリクエストのタイムアウトを短縮できます。この場合、TiKV ノードで I/Oレイテンシーのジッターが発生すると、TiDB はすぐにタイムアウトして、次の TiKVリージョンピアがある TiKV ノードに RPC リクエストを再送信できます。すべての TiKVリージョンピアのリクエストがタイムアウトした場合、TiDB はデフォルトのタイムアウト (通常 40秒) で再試行します。 - クエリ内でオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用すると、TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定できます。オプティマイザヒントとこのシステム変数の両方が設定されている場合は、オプティマイザヒントが優先されます。 -- デフォルト値`0`は、デフォルトのタイムアウト（通常は 40 秒）が使用されることを示します。 +- デフォルト値`0`は、デフォルトのタイムアウト（通常は 40秒）が使用されることを示します。 > **Note:** > diff --git a/table-affinity.md b/table-affinity.md index 35a195638cfc9..32fe1b9bcbf64 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -29,7 +29,7 @@ PDアフィニティスケジューリングはデフォルトで無効になっ 1. アフィニティ スケジューリングを有効にするには、PD 構成項目[`schedule.affinity-schedule-limit`](/pd-configuration-file.md#affinity-schedule-limit-new-in-v855) `0`より大きい値に設定します。 - たとえば、次のコマンドは値を`4`に設定し、PD が最大 4 つのアフィニティ スケジューリング タスクを同時に実行できるようにします。 + たとえば、次のコマンドは値を`4`に設定し、PD が最大 4つのアフィニティ スケジューリング タスクを同時に実行できるようにします。 ```bash pd-ctl config set schedule.affinity-schedule-limit 4 @@ -49,7 +49,7 @@ PDアフィニティスケジューリングはデフォルトで無効になっ | --------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `AFFINITY='table'` | パーティションテーブル | テーブルのアフィニティを有効にします。PD はテーブルのすべてのリージョンに対して単一のアフィニティ グループを作成します。 | | `AFFINITY='partition'` | パーティションテーブル | テーブル内の各パーティションのアフィニティを有効にします。PDは各パーティションのリージョンごとに個別のアフィニティグループを作成します。例えば、4つのパーティションを持つテーブルの場合、PDは4つの独立したアフィニティグループを作成します。 | -| `AFFINITY=''`または`AFFINITY='none'` | `AFFINITY='table'`または`AFFINITY='partition'`で構成されたテーブル | テーブルまたはパーティションのアフィニティを無効にします。アフィニティを無効にすると、PD は対象のテーブルまたはパーティションに対応するアフィニティグループを削除します。これにより、そのテーブルまたはパーティションのリージョンはアフィニティのスケジュール制約の対象外となります。TiKV の自動リージョン分割は、最大 10 分以内にデフォルトの動作に戻ります。 | +| `AFFINITY=''`または`AFFINITY='none'` | `AFFINITY='table'`または`AFFINITY='partition'`で構成されたテーブル | テーブルまたはパーティションのアフィニティを無効にします。アフィニティを無効にすると、PD は対象のテーブルまたはパーティションに対応するアフィニティグループを削除します。これにより、そのテーブルまたはパーティションのリージョンはアフィニティのスケジュール制約の対象外となります。TiKV の自動リージョン分割は、最大 10分以内にデフォルトの動作に戻ります。 | **例** @@ -100,7 +100,7 @@ ALTER TABLE t1 AFFINITY = ''; - **縮退および有効期限切れのメカニズム**：アフィニティグループ内の対象のリーダーまたは投票者をホストするTiKVノードが利用できなくなった場合（例えば、ノード障害やディスク容量不足など）、Leaderが排除された場合、または既存の配置ルールと競合した場合、PDはアフィニティグループを縮退状態としてマークします。縮退中は、対応するテーブルまたはパーティションのアフィニティスケジューリングが一時停止されます。 - - 影響を受けたノードが 10 分以内に回復した場合、PD は元のアフィニティ設定に基づいてスケジュールを再開します。 + - 影響を受けたノードが 10分以内に回復した場合、PD は元のアフィニティ設定に基づいてスケジュールを再開します。 - 影響を受けたノードが10分以内に回復しない場合、アフィニティグループは期限切れとしてマークされます。この時点で、PDは通常のスケジューリング動作を復元し（ [`SHOW AFFINITY`](/sql-statements/sql-statement-show-affinity.md)の状態が`Pending`に戻ります）、アフィニティグループ内のリーダーと投票者を自動的に更新して、アフィニティスケジューリングを再度有効にします。 ## 関連するステートメントと構成 {#related-statements-and-configurations} diff --git a/table-filter.md b/table-filter.md index 034e1523594c3..1b9cc668308a0 100644 --- a/table-filter.md +++ b/table-filter.md @@ -108,7 +108,7 @@ TOMLファイル内のテーブルフィルターは[文字列の配列](https:/ - `*` — 0文字以上の文字に一致 - `?` — 1文字に一致 - `[a-z]` — 「a」から「z」までの間の1文字に一致します -- `[!a-z]` — 「a」から「z」を除く 1 つの文字に一致します。 +- `[!a-z]` — 「a」から「z」を除く 1つの文字に一致します。 @@ -120,7 +120,7 @@ TOMLファイル内のテーブルフィルターは[文字列の配列](https:/ - U+00E9 (é) は 1 文字です。 - U+0065 U+0301 (é) は 2 文字です。 -- U+1F926 U+1F3FF U+200D U+2640 U+FE0F (🤦🏿‍♀️) は 5 つの文字です。 +- U+1F926 U+1F3FF U+200D U+2640 U+FE0F (🤦🏿‍♀️) は 5つの文字です。 ### ファイルのインポート {#file-import} @@ -131,7 +131,7 @@ TOMLファイル内のテーブルフィルターは[文字列の配列](https:/ employees.* *.WorkOrder -次の 2 つの呼び出しは同等です。 +次の2つの呼び出しは同等です。 ```bash tiup dumpling -f '@config/filter.txt' diff --git a/temporary-tables.md b/temporary-tables.md index 06f18720b1aa2..49c2288b7431f 100644 --- a/temporary-tables.md +++ b/temporary-tables.md @@ -20,7 +20,7 @@ TiDB 一時テーブルは、次のシナリオで使用できます。 ## 一時テーブルの種類 {#types-of-temporary-tables} -TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2 種類に分かれています。 +TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2種類に分かれています。 - ローカル一時テーブルの場合、テーブル定義とテーブル内のデータは現在のセッションでのみ参照可能です。このタイプは、セッション中の中間データを一時的に保存するのに適しています。 - グローバル一時テーブルの場合、テーブル定義はTiDBクラスタ全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 35b8680705bf1..1d86e2f39f251 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -1,11 +1,11 @@ --- title: Three Availability Zones in Two Regions Deployment -summary: 2 つのリージョンにある 3 つのアベイラビリティーゾーンへのデプロイメント ソリューションを学習します。 +summary: 2つのリージョンにある 3つのアベイラビリティーゾーンへのデプロイメント ソリューションを学習します。 --- # 2つのリージョンに3つのアベイラビリティゾーンを展開 {#three-availability-zones-in-two-regions-deployment} -このドキュメントでは、2 つのリージョン展開における 3 つの可用性ゾーン (AZ) のアーキテクチャと構成について説明します。 +このドキュメントでは、2つのリージョン展開における 3つの可用性ゾーン (AZ) のアーキテクチャと構成について説明します。 このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 @@ -17,13 +17,13 @@ summary: 2 つのリージョンにある 3 つのアベイラビリティーゾ ## デプロイメントアーキテクチャ {#deployment-architecture} -このセクションでは、シアトルとサンフランシスコを例に、TiDB の分散データベースの 2 つのリージョンにおける 3 つの AZ の展開モードについて説明します。 +このセクションでは、シアトルとサンフランシスコを例に、TiDB の分散データベースの 2つのリージョンにおける 3つの AZ の展開モードについて説明します。 この例では、2つのAZ（AZ1とAZ2）がシアトルにあり、もう1つのAZ（AZ3）がサンフランシスコにあります。AZ1とAZ2間のネットワークレイテンシーは3ミリ秒未満です。シアトルのAZ3とAZ1/AZ2間のネットワークレイテンシーは約20ミリ秒です（ISP専用ネットワークを使用）。 クラスター展開のアーキテクチャは次のとおりです。 -- TiDB クラスターは、シアトルの AZ1、シアトルの AZ2、サンフランシスコの AZ3 の 2 つのリージョンの 3 つの AZ にデプロイされています。 +- TiDB クラスターは、シアトルの AZ1、シアトルの AZ2、サンフランシスコの AZ3 の 2つのリージョンの 3つの AZ にデプロイされています。 - クラスターには5つのレプリカがあり、AZ1に2つ、AZ2に2つ、AZ3に1つあります。TiKVコンポーネントでは、各ラックにラベルが付けられており、各ラックにレプリカがあることを意味します。 - ユーザーにとって透過的なデータの一貫性と高可用性を確保するために、 Raftプロトコルが採用されています。 @@ -35,17 +35,17 @@ summary: 2 つのリージョンにある 3 つのアベイラビリティーゾ - リージョンリーダーは、レイテンシーが低い同じリージョンの AZ にあるため、書き込みが高速になります。 - 2つのAZが同時にサービスを提供できるため、リソースの使用率が高くなります。 - - 1 つの AZ に障害が発生しても、サービスは引き続き利用可能であり、データの安全性は確保されます。 + - 1つの AZ に障害が発生しても、サービスは引き続き利用可能であり、データの安全性は確保されます。 - **デメリット** - データの一貫性はRaftアルゴリズムによって実現されるため、同一リージョン内の2つのAZが同時に障害に見舞われた場合、別のリージョン（サンフランシスコ）の災害復旧AZに1つのレプリカのみが残ります。これは、ほとんどのレプリカが残るというRaftアルゴリズムの要件を満たしていません。その結果、クラスターが一時的に利用できなくなる可能性があります。保守担当者は、残った1つのレプリカからクラスターを復旧する必要があり、複製されていない少量のホットデータが失われることになります。ただし、このようなケースはまれです。 - ISP 専用ネットワークが使用されるため、このアーキテクチャのネットワーク インフラストラクチャには高いコストがかかります。 - - 2 つのリージョンの 3 つの AZ に 5 つのレプリカが構成され、データの冗長性が高まり、ストレージコストが高くなります。 + - 2つのリージョンの 3つの AZ に 5つのレプリカが構成され、データの冗長性が高まり、ストレージコストが高くなります。 ### 展開の詳細 {#deployment-details} -2 つのリージョン (シアトルとサンフランシスコ) の 3 つの AZ の展開プランの構成は、次のようになります。 +2つのリージョン (シアトルとサンフランシスコ) の 3つの AZ の展開プランの構成は、次のようになります。 ![3-AZ-2-region](/media/three-data-centers-in-two-cities-deployment-02.png) @@ -161,7 +161,7 @@ tikv_servers: ### パラメータ設定を最適化する {#optimize-parameter-configuration} -2 つのリージョンに 3 つの AZ を展開する場合、パフォーマンスを最適化するには、通常のパラメータを設定するだけでなく、コンポーネントパラメータも調整する必要があります。 +2つのリージョンに 3つの AZ を展開する場合、パフォーマンスを最適化するには、通常のパラメータを設定するだけでなく、コンポーネントパラメータも調整する必要があります。 - TiKVでgRPCメッセージ圧縮を有効にします。クラスターのデータはネットワーク経由で送信されるため、gRPCメッセージ圧縮を有効にするとネットワークトラフィックを削減できます。 diff --git a/ticdc-performance-tuning-methods.md b/ticdc-performance-tuning-methods.md index deb2e66df8963..aed43e1427db3 100644 --- a/ticdc-performance-tuning-methods.md +++ b/ticdc-performance-tuning-methods.md @@ -9,7 +9,7 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ ## TiCDC クラスターのリソース利用率 {#resource-utilization-of-a-ticdc-cluster} -次の 3 つのメトリックを使用すると、TiCDC クラスターのリソース使用率を簡単に取得できます。 +次の3つのメトリックを使用すると、TiCDC クラスターのリソース使用率を簡単に取得できます。 - CPU 使用率: TiCDC ノードごとの CPU 使用率。 - メモリ使用量: TiCDC ノードごとのメモリ使用量。 @@ -23,7 +23,7 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ - Changefeed チェックポイント ラグ: アップストリームとダウンストリーム間のデータ複製の進行ラグ (秒単位で測定)。 - TiCDC がデータを消費し、下流に書き込む速度が上流のデータの変化に追いついている場合、この指標は小さなレイテンシー範囲内（通常は 10 秒以内）に留まります。そうでない場合、この指標は増加し続けます。 + TiCDC がデータを消費し、下流に書き込む速度が上流のデータの変化に追いついている場合、この指標は小さなレイテンシー範囲内（通常は 10秒以内）に留まります。そうでない場合、この指標は増加し続けます。 このメトリック (つまり`Changefeed checkpoint lag` ) が増加する場合、一般的な理由は次のとおりです。 @@ -51,11 +51,11 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ 次のメトリックを使用すると、TiCDC のデータフロー スループットとダウンストリームレイテンシーを知ることができます。 -- Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1 秒あたりに送信する行数。 -- ソーター出力イベント/秒: TiCDC ノードのソーター モジュールがマウント モジュールに 1 秒あたりに送信する行数。 -- マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 -- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 -- SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1 秒あたりに送信する行数。 +- Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1秒あたりに送信する行数。 +- ソーター出力イベント/秒: TiCDC ノードのソーター モジュールがマウント モジュールに 1秒あたりに送信する行数。 +- マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1秒あたりに送信する行数。 +- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーター モジュールがシンク モジュールに 1秒あたりに送信する行数。 +- SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1秒あたりに送信する行数。 - トランザクションシンクの完全フラッシュ期間: TiCDC ノードの MySQL シンクによるダウンストリーム トランザクションの書き込みの平均レイテンシーと p999レイテンシー。 - MQ ワーカーのメッセージ送信期間パーセンタイル: ダウンストリームが Kafka の場合の MQ ワーカーによるメッセージ送信のレイテンシー。 - Kafka 送信バイト: MQ ワークロードでのダウンストリーム トランザクションの書き込みトラフィック。 diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index cba977e3437af..7d516e7251fc0 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -106,7 +106,7 @@ TiCDCクラスタをアップグレードする際には、以下の点に注意 ## TiUPを使用してTiCDCクラスタ構成を変更します。 {#modify-ticdc-cluster-configurations-using-tiup} -このセクションでは[`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)コマンドを使用して TiCDC の設定を変更する方法について説明します。次の例では、 `gc-ttl`のデフォルト値を`86400`から`172800` (48 時間) に変更する必要があると想定しています。 +このセクションでは[`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)コマンドを使用して TiCDC の設定を変更する方法について説明します。次の例では、 `gc-ttl`のデフォルト値を`86400`から`172800` (48時間) に変更する必要があると想定しています。 1. `tiup cluster edit-config`コマンドを実行します。 ``実際のクラスター名に置き換えてください。 @@ -127,7 +127,7 @@ TiCDCクラスタをアップグレードする際には、以下の点に注意 gc-ttl: 172800 ``` - 上記のコマンドでは、 `gc-ttl`が 48 時間に設定されています。 + 上記のコマンドでは、 `gc-ttl`が 48時間に設定されています。 3. `tiup cluster reload -R cdc`コマンドを実行して設定を再読み込みします。 diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index 14a259af08998..5ae99993c04ee 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -102,7 +102,7 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 - 入力バイト/秒: イベントストアが1秒あたりに処理するデータ量 - 書き込みリクエスト数/秒: イベントストアが1秒あたりに実行する書き込みリクエストの数 - 書き込みワーカービジー率: イベントストア書き込みスレッドの合計実行時間に対するI/O時間の比率 -- 圧縮行数/秒: イベント ストアで 1 秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) +- 圧縮行数/秒: イベント ストアで 1秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) - 書き込み時間: イベントストアの書き込み操作にかかる時間 - 書き込みバッチサイズ: 1回の書き込み操作のバッチサイズ - 書き込みバッチイベント数: 1回の書き込みバッチに含まれる行変更イベントの数 @@ -170,9 +170,9 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 ![TiCDC Dashboard - Changefeed metrics 2](/media/ticdc/ticdc-dashboard-changefeed-2.png) - シンク書き込み時間: TiCDCがトランザクションの変更をダウンストリームに書き込むのに費やした時間のヒストグラム -- シンク書き込み期間パーセンタイル: TiCDC が 1 秒以内にトランザクションの変更をダウンストリームに書き込むのに費やした時間 (P95、P99、および P999) +- シンク書き込み期間パーセンタイル: TiCDC が 1秒以内にトランザクションの変更をダウンストリームに書き込むのに費やした時間 (P95、P99、および P999) - フラッシュシンク期間: TiCDC が非同期的にデータを下流にフラッシュするのにかかった時間のヒストグラム -- フラッシュシンク期間パーセンタイル: TiCDC が 1 秒以内にデータを非同期にダウンストリームにフラッシュするのにかかる時間 (P95、P99、および P999) +- フラッシュシンク期間パーセンタイル: TiCDC が 1秒以内にデータを非同期にダウンストリームにフラッシュするのにかかる時間 (P95、P99、および P999) ![TiCDC Dashboard - Changefeed metrics 3](/media/ticdc/ticdc-dashboard-changefeed-3.png) @@ -208,7 +208,7 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 - エントリソーターのマージ期間: TiCDCノードがソートされたイベントをマージするのにかかった時間のヒストグラム - エントリソーターのマージ所要時間パーセンタイル: TiCDCがソートされたイベントを1秒以内にマージするのにかかる時間(P95、P99、P999) - マウンターのアンマーシャリング期間: TiCDCノードがイベントをアンマーシャリングするのにかかった時間のヒストグラム -- マウンターのアンマーシャリング期間のパーセンタイル: TiCDC アンマーシャリング イベントが 1 秒間に要した時間 (P95、P99、および P999) +- マウンターのアンマーシャリング期間のパーセンタイル: TiCDC アンマーシャリング イベントが 1秒間に要した時間 (P95、P99、および P999) - KVクライアントディスパッチイベント数/秒: KVクライアントモジュールがTiCDCノード間でディスパッチするイベント数 - KVクライアントのバッチ解決サイズ: TiKVがTiCDCに送信する解決済みタイムスタンプメッセージのバッチサイズ diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index c6f4c33915e6a..68b4b4fd4ef08 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -21,7 +21,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクが 10 分以上遅延します。 + レプリケーション タスクが 10分以上遅延します。 - 解決： @@ -35,7 +35,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクの解決された TS が 5 分以上遅延します。 + レプリケーション タスクの解決された TS が 5分以上遅延します。 - 解決： @@ -81,7 +81,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - TiCDC クラスターに 10 分以上所有者が存在しません。 + TiCDC クラスターに 10分以上所有者が存在しません。 - 解決： @@ -123,7 +123,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - TiKV CDC の最小解決 TS 1 は 1 分間進んでいません。 + TiKV CDC の最小解決 TS 1 は 1分間進んでいません。 - 解決： @@ -137,7 +137,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - TiKV CDC モジュールは、増分レプリケーションを 10 分以上スキャンしました。 + TiKV CDC モジュールは、増分レプリケーションを 10分以上スキャンしました。 - 解決： diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 1f9244e9cf204..8e8e61fd30d2d 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -49,7 +49,7 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート - 増分スキャンパフォーマンスのボトルネック: 増分スキャンタスクの完了に過度に時​​間がかかり、レプリケーションのレイテンシーが継続的に増加します。 - 超高トラフィックシナリオ：変更フィードの総トラフィックが700 MiB/秒を超える場合。 -- MySQL シンクで高スループット書き込みを行う単一テーブル: ターゲットテーブルには**、主キーまたは NULL 以外の一意キーが 1 つだけ**あります。 +- MySQL シンクで高スループット書き込みを行う単一テーブル: ターゲットテーブルには**、主キーまたは NULL 以外の一意キーが 1つだけ**あります。 - 大規模なテーブルレプリケーション：レプリケーション対象のテーブル数が10万を超える場合。 - 頻繁な DDL 操作によるレイテンシー: DDL ステートメントの頻繁な実行は、レプリケーションのレイテンシーを大幅に増加させます。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 7d57ac0b5dc01..71bd23718aceb 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -125,7 +125,7 @@ dispatchers = [ ] } -`enable-tidb-extension`無効になっている値のデータ形式と比較すると、 `_tidb_op` 、 `_tidb_commit_ts` 、 `_tidb_commit_physical_time` 3 つの新しいフィールドが追加されます。 +`enable-tidb-extension`無効になっている値のデータ形式と比較すると、 `_tidb_op` 、 `_tidb_commit_ts` 、 `_tidb_commit_physical_time` 3つの新しいフィールドが追加されます。 ### カラムデータ形式 {#column-data-format} @@ -141,7 +141,7 @@ dispatchers = [ } } -1 つの列が NULL になる可能性がある場合、カラムのデータ形式は次のようになります。 +1つの列が NULL になる可能性がある場合、カラムのデータ形式は次のようになります。 { "default":null, @@ -195,7 +195,7 @@ dispatchers = [ | DECIMAL | DECIMAL | bytes | `avro-decimal-handling-mode`文字列の場合、AVRO_TYPE は文字列です。 | | TiDBVECTORFloat32 | TiDBVECTORFloat32 | string | - | -Avro プロトコルでは、他の 2 つの`sink-uri`パラメータ`avro-decimal-handling-mode`と`avro-bigint-unsigned-handling-mode`もカラムデータ形式に影響する可能性があります。 +Avro プロトコルでは、他の 2つの`sink-uri`パラメータ`avro-decimal-handling-mode`と`avro-bigint-unsigned-handling-mode`もカラムデータ形式に影響する可能性があります。 - `avro-decimal-handling-mode` 、Avro が小数フィールドを処理する方法を制御します。これには以下が含まれます。 diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index 2df52393ef412..3dc9c6230ca7f 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -7,13 +7,13 @@ summary: TiCDC の双方向レプリケーションの使用方法を学習し TiCDCは、2つのTiDBクラスタ間の双方向レプリケーション（BDR）をサポートしています。この機能を利用することで、TiCDCを使用したマルチアクティブTiDBソリューションを構築できます。 -このセクションでは、2 つの TiDB クラスターを例にして双方向レプリケーションを使用する方法について説明します。 +このセクションでは、2つの TiDB クラスターを例にして双方向レプリケーションを使用する方法について説明します。 ## 双方向レプリケーションをデプロイ {#deploy-bidirectional-replication} TiCDCは、指定されたタイムスタンプ以降に発生した増分データ変更のみを下流クラスターに複製します。双方向レプリケーションを開始する前に、次の手順を実行する必要があります。 -1. (オプション) 必要に応じて、データ エクスポート ツール[Dumpling](/dumpling-overview.md)とデータ インポート ツール[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用して、2 つの TiDB クラスターのデータを相互にインポートします。 +1. (オプション) 必要に応じて、データ エクスポート ツール[Dumpling](/dumpling-overview.md)とデータ インポート ツール[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用して、2つの TiDB クラスターのデータを相互にインポートします。 2. 2つのTiDBクラスターの間に2つのTiCDCクラスターをデプロイ。クラスタートポロジは以下のとおりです。図中の矢印はデータフローの方向を示しています。 @@ -36,7 +36,7 @@ TiCDCは、指定されたタイムスタンプ以降に発生した増分デー ## DDLタイプ {#ddl-types} -v7.6.0 以降、双方向レプリケーションで DDL レプリケーションを可能な限りサポートするために、TiDB は、DDL がビジネスに与える影響に応じて、 [TiCDCが元々サポートしていたDDL](/ticdc/ticdc-ddl.md)をレプリケート可能な DDL とレプリケート不可能な DDL の 2 種類に分割します。 +v7.6.0 以降、双方向レプリケーションで DDL レプリケーションを可能な限りサポートするために、TiDB は、DDL がビジネスに与える影響に応じて、 [TiCDCが元々サポートしていたDDL](/ticdc/ticdc-ddl.md)をレプリケート可能な DDL とレプリケート不可能な DDL の 2種類に分割します。 ### 複製可能なDDL {#replicable-ddls} diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 91fc4469f1580..5099c2613ce55 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -11,7 +11,7 @@ Canal-JSONは、 [アリババCanal](https://github.com/alibaba/canal)で定義 Message Queue (MQ) を下流の Sink として使用する場合、 `sink-uri`で Canal-JSON を指定できます。TiCDC は、Canal-JSON メッセージを Event を基本単位としてラップして構築し、TiDB データ変更イベントを下流に送信します。 -イベントには 3 つの種類があります。 +イベントには 3つの種類があります。 - DDLイベント: DDL変更レコードを表します。上流のDDL文が正常に実行された後に送信されます。DDLイベントは、インデックスが0のMQパーティションに送信されます。 - DMLイベント：行データの変更レコードを表します。このタイプのイベントは、行の変更が発生したときに送信されます。変更後の行に関する情報が含まれます。 @@ -138,7 +138,7 @@ TiCDC は、DML データ変更イベントの行を次のようにエンコー TiCDCは、 `enable-tidb-extension`を`true`に設定した場合のみ、WATERMARKイベントを送信します。 `type`フィールドの値は`TIDB_WATERMARK`です。イベントには`_tidb`フィールドが含まれており、このフィールドにはパラメータ`watermarkTs`のみが含まれます。 `watermarkTs`の値は、イベント送信時に記録されるTSOです。 -このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は「少なくとも 1 回」のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 +このタイプのイベントを受信すると、 `commitTs`が`watermarkTs`より小さいすべてのイベントが送信されています。TiCDC は「少なくとも 1回」のセマンティクスを提供するため、データが繰り返し送信される可能性があります。その後に`commitTs`が`watermarkTs`より小さいイベントを受信した場合は、このイベントを無視しても問題ありません。 以下は WATERMARK イベントの例です。 diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index 872235882320d..b612866fe5f0a 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -164,7 +164,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl 1. リージョン数に基づいてテーブルを割り当て、各TiCDCノードがほぼ同数のリージョンを処理するようにします。テーブルのリージョン数が[`region-threshold`](#region-threshold)の値を超えると、そのテーブルはレプリケーションのために複数のノードに割り当てられます。 2. 書き込みトラフィックに基づいてテーブルを割り当て、各TiCDCノードがほぼ同じ数の変更行を処理するようにします。この割り当ては、テーブル内の1分あたりの変更行数が[`write-key-threshold`](#write-key-threshold)の値を超えた場合にのみ有効になります。 - 2 つのモードのうち、いずれか 1 つだけを設定すれば十分です。 `region-threshold`と`write-key-threshold`の両方が設定されている場合、TiCDC はトラフィック割り当てモード、つまり`write-key-threshold`を優先します。 + 2つのモードのうち、いずれか 1つだけを設定すれば十分です。 `region-threshold`と`write-key-threshold`の両方が設定されている場合、TiCDC はトラフィック割り当てモード、つまり`write-key-threshold`を優先します。 - デフォルト値は`false`です。この機能を有効にするには、 `true`に設定してください。 @@ -610,7 +610,7 @@ token="xxxx" - ファイルを保持する期間。これは、 `date-separator`が`day`に設定されている場合にのみ有効になります。 - デフォルト値： `0` 。これは、ファイルクリーンアップが無効になっていることを意味します。 -- `file-expiration-days = 1`と`file-cleanup-cron-spec = "0 0 0 * * *"`を仮定すると、TiCDC は 24 時間を超えて保存されたファイルに対して、毎日 00:00:00 にクリーンアップを実行します。たとえば、2023/12/02 の 00:00:00 に、TiCDC は 2023/12/01 より前に生成されたファイルをクリーンアップしますが、2023/12/01 に生成されたファイルは影響を受けません。 +- `file-expiration-days = 1`と`file-cleanup-cron-spec = "0 0 0 * * *"`を仮定すると、TiCDC は 24時間を超えて保存されたファイルに対して、毎日 00:00:00 にクリーンアップを実行します。たとえば、2023/12/02 の 00:00:00 に、TiCDC は 2023/12/01 より前に生成されたファイルをクリーンアップしますが、2023/12/01 に生成されたファイルは影響を受けません。 #### `file-cleanup-cron-spec` {#file-cleanup-cron-spec} diff --git a/ticdc/ticdc-classic-architecture.md b/ticdc/ticdc-classic-architecture.md index 9ac8bfa2b569b..09e1be9bea119 100644 --- a/ticdc/ticdc-classic-architecture.md +++ b/ticdc/ticdc-classic-architecture.md @@ -20,7 +20,7 @@ summary: TiCDC の従来のアーキテクチャと動作原理を学びます ## TiCDC コンポーネント {#ticdc-components} -上の図では、TiCDC クラスターは TiCDC インスタンスを実行する複数のノードで構成されています。各 TiCDC インスタンスはキャプチャプロセスを実行します。キャプチャプロセスの 1 つがオーナーキャプチャとして選出され、ワークロードのスケジュール設定、DDL ステートメントのレプリケーション、および管理タスクの実行を担当します。 +上の図では、TiCDC クラスターは TiCDC インスタンスを実行する複数のノードで構成されています。各 TiCDC インスタンスはキャプチャプロセスを実行します。キャプチャプロセスの 1つがオーナーキャプチャとして選出され、ワークロードのスケジュール設定、DDL ステートメントのレプリケーション、および管理タスクの実行を担当します。 各キャプチャプロセスには、上流TiDBのテーブルからデータを複製するための1つまたは複数のプロセッサスレッドが含まれています。テーブルはTiCDCにおけるデータ複製の最小単位であるため、プロセッサは複数のテーブルパイプラインで構成されます。 @@ -88,7 +88,7 @@ TiCDCの上流は、トランザクションをサポートする分散リレー ## TiCDCの主要概念 {#key-concepts-of-ticdc} -下流のリレーショナルデータベースでは、TiCDC は単一テーブル内のトランザクションの一貫性と、複数テーブルにおける最終的なトランザクションの一貫性を保証します。さらに、TiCDC は上流の TiDB クラスターで発生したデータ変更が下流に少なくとも 1 回は複製されることを保証します。 +下流のリレーショナルデータベースでは、TiCDC は単一テーブル内のトランザクションの一貫性と、複数テーブルにおける最終的なトランザクションの一貫性を保証します。さらに、TiCDC は上流の TiDB クラスターで発生したデータ変更が下流に少なくとも 1回は複製されることを保証します。 ### 建築関連の概念 {#architecture-related-concepts} diff --git a/ticdc/ticdc-client-authentication.md b/ticdc/ticdc-client-authentication.md index a74c796031000..5b980cc8b01cb 100644 --- a/ticdc/ticdc-client-authentication.md +++ b/ticdc/ticdc-client-authentication.md @@ -10,7 +10,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB - mTLS 認証はトランスポートレイヤーでのセキュリティ制御を提供し、TiCDC がクライアント ID を検証できるようにします。 - TiDB のユーザー名とパスワード認証は、アプリケーションレイヤーでセキュリティ制御を提供し、許可されたユーザーのみが TiCDC ノードを通じてログインできるようにします。 -これら 2 つの認証方法は、さまざまなシナリオやセキュリティ要件を満たすために、単独で使用することも、組み合わせて使用することもできます。 +これら2つの認証方法は、さまざまなシナリオやセキュリティ要件を満たすために、単独で使用することも、組み合わせて使用することもできます。 > **Note:** > diff --git a/ticdc/ticdc-debezium.md b/ticdc/ticdc-debezium.md index 345f93c80e9e4..dd522d98b7475 100644 --- a/ticdc/ticdc-debezium.md +++ b/ticdc/ticdc-debezium.md @@ -40,7 +40,7 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --changefeed-id="kafka- Debeziumの出力形式には、下流のコンシューマーが現在の行のデータ構造をより適切に理解できるように、現在の行のスキーマ情報が含まれています。スキーマ情報が不要なシナリオでは、changefeed設定ファイルで`debezium-disable-schema`パラメータを`true`または`sink-uri`に設定することで、スキーマ出力を無効にすることもできます。 -さらに、元の Debezium 形式には、TiDB の `CommitTS` の一意なトランザクション識別子などの重要なフィールドが含まれていません。データの整合性を確保するために、TiCDC は Debezium 形式に `CommitTs` と `ClusterID` の 2 つのフィールドを追加し、TiDB データ変更の関連情報を識別します。 +さらに、元の Debezium 形式には、TiDB の `CommitTS` の一意なトランザクション識別子などの重要なフィールドが含まれていません。データの整合性を確保するために、TiCDC は Debezium 形式に `CommitTs` と `ClusterID` の 2つのフィールドを追加し、TiDB データ変更の関連情報を識別します。 ## メッセージ形式の定義 {#message-format-definition} diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 17804df15a947..c3b5243c063f9 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -173,7 +173,7 @@ TiCDCサーバーの起動時に、GCセーフポイントのTime To Live（TTL > **Note:** > -> 一部のシナリオ、例えばDumpling/BRを使用した完全レプリケーション後に TiCDC による増分レプリケーションを実行する場合など、デフォルトの 24 時間（ `gc-ttl`では不十分な場合があります。TiCDCサーバーを起動する際に、適切な値`gc-ttl`を指定する必要があります。 +> 一部のシナリオ、例えばDumpling/BRを使用した完全レプリケーション後に TiCDC による増分レプリケーションを実行する場合など、デフォルトの 24時間（ `gc-ttl`では不十分な場合があります。TiCDCサーバーを起動する際に、適切な値`gc-ttl`を指定する必要があります。 ## TiCDCガベージコレクション(GC) セーフポイントの完全な動作は何ですか? {#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint} @@ -181,7 +181,7 @@ TiCDCサービスの起動後にレプリケーションタスクが開始され レプリケーションタスクが`gc-ttl`で指定された時間を超えて中断された場合、レプリケーションタスクは`failed`状態になり、再開できなくなります。PDに対応するサービスGCセーフポイントは継続されます。 -TiCDC がサービス GC セーフポイントに設定するデフォルトの Time-To-Live (TTL) は 24 時間です。つまり、TiCDC サービスが中断されてから 24 時間以内に回復できる場合、GC メカニズムはレプリケーションを続行するために TiCDC が必要とするデータを削除しません。 +TiCDC がサービス GC セーフポイントに設定するデフォルトの Time-To-Live (TTL) は 24時間です。つまり、TiCDC サービスが中断されてから 24時間以内に回復できる場合、GC メカニズムはレプリケーションを続行するために TiCDC が必要とするデータを削除しません。 ## レプリケーション タスクが失敗した後に回復するにはどうすればよいですか? {#how-to-recover-a-replication-task-after-it-fails} @@ -243,7 +243,7 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="kafka://127 `protocol` `avro`または`canal-json`に設定すると、行の変更ごとにメッセージが送信されます。1つのKafkaメッセージには1つの行の変更のみが含まれ、通常はKafkaの制限を超えることはありません。したがって、1つのメッセージのサイズを制限する必要はありません。1つのKafkaメッセージのサイズがKafkaの制限を超える場合は、 [TiCDC から Kafka へのレイテンシーがどんどん高くなるのはなぜですか?](/ticdc/ticdc-faq.md#why-does-the-latency-from-ticdc-to-kafka-become-higher-and-higher)を参照してください。 -`protocol` `open-protocol`に設定すると、メッセージはバッチで送信されます。そのため、1 つの Kafka メッセージのサイズが過度に大きくなる可能性があります。このような状況を回避するには、 `max-message-bytes`パラメータを設定して、Kafka ブローカーに送信されるデータの最大サイズを制御できます（オプション、デフォルトは`10MB` ）。また、 `max-batch-size`パラメータを設定して（オプション、デフォルトは`16` ）、各 Kafka メッセージに含まれる変更レコードの最大数を指定することもできます。 +`protocol` `open-protocol`に設定すると、メッセージはバッチで送信されます。そのため、1つの Kafka メッセージのサイズが過度に大きくなる可能性があります。このような状況を回避するには、 `max-message-bytes`パラメータを設定して、Kafka ブローカーに送信されるデータの最大サイズを制御できます（オプション、デフォルトは`10MB` ）。また、 `max-batch-size`パラメータを設定して（オプション、デフォルトは`16` ）、各 Kafka メッセージに含まれる変更レコードの最大数を指定することもできます。 ## トランザクションで行を複数回変更した場合、TiCDC は複数の行変更イベントを出力しますか? {#if-i-modify-a-row-multiple-times-in-a-transaction-will-ticdc-output-multiple-row-change-events} @@ -251,7 +251,7 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="kafka://127 ## TiCDC がデータを Kafka に複製する場合、メッセージには複数の種類のデータ変更が含まれますか? {#when-ticdc-replicates-data-to-kafka-does-a-message-contain-multiple-types-of-data-changes} -はい。1 つのメッセージに複数の`update`または`delete`が含まれる場合があり、 `update`と`delete`共存することもあります。 +はい。1つのメッセージに複数の`update`または`delete`が含まれる場合があり、 `update`と`delete`共存することもあります。 ## TiCDC がデータを Kafka に複製する場合、TiCDC オープン プロトコルの出力でタイムスタンプ、テーブル名、スキーマ名を表示するにはどうすればよいですか? {#when-ticdc-replicates-data-to-kafka-how-do-i-view-the-timestamp-table-name-and-schema-name-in-the-output-of-ticdc-open-protocol} @@ -401,7 +401,7 @@ BR はバージョンに応じて互換性を異なる方法で処理します 変更フィードが再開されると、TiCDC は TiKV 内のデータの履歴バージョンをスキャンし、一時停止中に生成された増分データログに追いつく必要があります。レプリケーションプロセスはスキャンが完了した後にのみ続行されます。スキャンプロセスには数分から数十分かかる場合があります。 -## 異なるリージョンにある 2 つの TiDB クラスター間でデータをレプリケートするには、TiCDC をどのようにデプロイすればよいですか? {#how-should-i-deploy-ticdc-to-replicate-data-between-two-tidb-cluster-located-in-different-regions} +## 異なるリージョンにある 2つの TiDB クラスター間でデータをレプリケートするには、TiCDC をどのようにデプロイすればよいですか? {#how-should-i-deploy-ticdc-to-replicate-data-between-two-tidb-cluster-located-in-different-regions} TiCDC v6.5.2より前のバージョンでは、TiCDCをダウンストリームTiDBクラスタにデプロイすることをお勧めします。アップストリームとダウンストリーム間のネットワークレイテンシーが大きい場合（例えば100ミリ秒を超える場合）、MySQL転送プロトコルの問題により、TiCDCがダウンストリームにSQL文を実行する際のレイテンシーが大幅に増加する可能性があります。その結果、システムスループットが低下します。しかし、ダウンストリームにTiCDCをデプロイすることで、この問題を大幅に軽減できます。最適化後、TiCDC v6.5.2以降では、TiCDCをアップストリームTiDBクラスタにデプロイすることをお勧めします。 @@ -488,7 +488,7 @@ CREATE TABLE data_table ( ) CHARSET=utf8mb4 COLLATE=utf8mb4_bin; ``` -アップストリームがテーブル内の 2 つの行の`value`のフィールドを交換しようとした場合: +アップストリームがテーブル内の 2つの行の`value`のフィールドを交換しようとした場合: ```sql DELETE FROM data_table WHERE id = 1; @@ -497,7 +497,7 @@ INSERT INTO data_table (id, value) VALUES (1, 'v3'); INSERT INTO data_table (id, value) VALUES (2, 'v1'); ``` -TiDB は 2 つの`UPDATE`行の変更を生成するため、TiCDC はそれを下流へのレプリケーション用の 2 つの`UPDATE`ステートメントに変換します。 +TiDB は 2つの`UPDATE`行の変更を生成するため、TiCDC はそれを下流へのレプリケーション用の 2つの`UPDATE`ステートメントに変換します。 ```sql UPDATE data_table SET value = 'v3' WHERE id = 1; @@ -518,7 +518,7 @@ mysql://user:password@host:port/?safe-mode=true TiCDCはSaramaクライアントを使用してKafkaにデータを複製します。データの順序が乱れるのを防ぐため、TiCDCはSaramaの自動再試行メカニズムを無効化します（再試行回数を0に設定）。その結果、TiCDCとKafka間の接続が一定時間アイドル状態になった後にKafkaによって切断された場合、TiCDCからの後続の書き込みは`write: broken pipe`エラーをトリガーし、レプリケーションタスクが失敗します。 -このエラーにより変更フィードが失敗する可能性がありますが、TiCDC は影響を受けた変更フィードを自動的に再起動するため、レプリケーションタスクは正常に実行を継続できます。再起動プロセス中、変更フィードのレプリケーションレイテンシー（ラグ）が一時的にわずかに（通常は 30 秒以内）増加する場合がありますが、その後自動的に正常に戻ります。 +このエラーにより変更フィードが失敗する可能性がありますが、TiCDC は影響を受けた変更フィードを自動的に再起動するため、レプリケーションタスクは正常に実行を継続できます。再起動プロセス中、変更フィードのレプリケーションレイテンシー（ラグ）が一時的にわずかに（通常は 30秒以内）増加する場合がありますが、その後自動的に正常に戻ります。 アプリケーションが changefeed のレイテンシーに非常に敏感な場合は、次の操作を実行することをお勧めします。 diff --git a/ticdc/ticdc-glossary.md b/ticdc/ticdc-glossary.md index c2f00df5be78a..8c45053a92cc9 100644 --- a/ticdc/ticdc-glossary.md +++ b/ticdc/ticdc-glossary.md @@ -27,7 +27,7 @@ TiCDC の増分レプリケーション タスク。TiDB クラスター内の ### 所有者 {#owner} -TiCDC クラスターを管理し、クラスターのレプリケーションタスクをスケジュールする特別なロールの[capture](#capture) 。所有者はキャプチャによって選出され、常に最大 1 人の所有者しか存在しません。 +TiCDC クラスターを管理し、クラスターのレプリケーションタスクをスケジュールする特別なロールの[capture](#capture) 。所有者はキャプチャによって選出され、常に最大 1人の所有者しか存在しません。 ## P {#p} diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 1975eebce200c..d79d7ce354385 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -268,7 +268,7 @@ force-replicate = true > **Warning:** > -> `force-replicate` `true`に設定すると、データの一貫性が保証されません。有効なインデックスのないテーブルの場合、 `INSERT`や`REPLACE`などの操作は再入不可能であるため、データの冗長性が発生するリスクがあります。TiCDC は、レプリケーションプロセス中にデータが少なくとも 1 回だけ分散されることを保証します。したがって、この機能を有効にして有効なインデックスのないテーブルをレプリケーションすると、確実にデータの冗長性が発生します。データの冗長性を許容しない場合は、 `AUTO RANDOM`属性を持つ主キー列を追加するなど、有効なインデックスを追加することをお勧めします。 +> `force-replicate` `true`に設定すると、データの一貫性が保証されません。有効なインデックスのないテーブルの場合、 `INSERT`や`REPLACE`などの操作は再入不可能であるため、データの冗長性が発生するリスクがあります。TiCDC は、レプリケーションプロセス中にデータが少なくとも 1回だけ分散されることを保証します。したがって、この機能を有効にして有効なインデックスのないテーブルをレプリケーションすると、確実にデータの冗長性が発生します。データの冗長性を許容しない場合は、 `AUTO RANDOM`属性を持つ主キー列を追加するなど、有効なインデックスを追加することをお勧めします。 ## 統合ソーター {#unified-sorter} diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md index 0c7f43c7babf8..2632a6797eafd 100644 --- a/ticdc/ticdc-open-protocol.md +++ b/ticdc/ticdc-open-protocol.md @@ -15,15 +15,15 @@ TiCDCオープンプロトコルは、データ変更イベントを下流に複 ## 制限 {#restrictions} -- ほとんどの場合、バージョンの行変更イベントは 1 回だけ送信されますが、ノード障害やネットワーク パーティションなどの特別な状況では、同じバージョンの行変更イベントが複数回送信されることがあります。 +- ほとんどの場合、バージョンの行変更イベントは 1回だけ送信されますが、ノード障害やネットワーク パーティションなどの特別な状況では、同じバージョンの行変更イベントが複数回送信されることがあります。 - 同じテーブルで、最初に送信された各バージョンの行変更イベントは、イベント ストリーム内のタイムスタンプ (TS) の順に増加します。 - 解決済みイベントは、各MQパーティションに定期的にブロードキャストされます。解決済みイベントとは、解決済みイベントTSよりも前のTSを持つイベントがダウンストリームに送信されたことを意味します。 - DDL イベントは各 MQ パーティションにブロードキャストされます。 -- 1 つの行の複数の行変更イベントが同じ MQ パーティションに送信されます。 +- 1つの行の複数の行変更イベントが同じ MQ パーティションに送信されます。 ## メッセージ形式 {#message-format} -メッセージには、次の形式で配置された 1 つ以上のイベントが含まれます。 +メッセージには、次の形式で配置された 1つ以上のイベントが含まれます。 鍵： @@ -230,7 +230,7 @@ COMMIT; ``` - 次のログ 5 とログ 6 から、同じテーブル上の行変更イベントは主キーに基づいて異なるパーティションに送信される可能性がありますが、同じ行への変更は同じパーティションに送信されるため、ダウンストリームでイベントを簡単に同時に処理できることがわかります。 -- ログ 6 以降、トランザクション内の同じ行に対する複数の変更は、1 つの行変更イベントでのみ送信されます。 +- ログ 6 以降、トランザクション内の同じ行に対する複数の変更は、1つの行変更イベントでのみ送信されます。 - ログ 8 は、ログ 7 の繰り返しイベントです。行変更イベントは繰り返される可能性がありますが、各バージョンの最初のイベントは順番に送信されます。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 278f8ee50fec3..ecbc9cf381be2 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -78,7 +78,7 @@ TiCDCのアーキテクチャを次の図に示す。 ## 有効なインデックス {#valid-index} -一般的に、TiCDC は有効なインデックスを少なくとも 1 つ持つテーブルのみをダウンストリームにレプリケートします。テーブル内のインデックスが以下のいずれかの要件を満たしている場合、そのインデックスは有効です。 +一般的に、TiCDC は有効なインデックスを少なくとも 1つ持つテーブルのみをダウンストリームにレプリケートします。テーブル内のインデックスが以下のいずれかの要件を満たしている場合、そのインデックスは有効です。 - 主キー（ `PRIMARY KEY` ）は有効なインデックスです。 - 一意インデックス ( `UNIQUE INDEX` ) は、インデックスのすべての列が明示的に非 null 許容 ( `NOT NULL` ) として定義され、インデックスに仮想生成列 ( `VIRTUAL GENERATED COLUMNS` ) がない場合に有効です。 @@ -94,7 +94,7 @@ TiCDCのアーキテクチャを次の図に示す。 - TiCDCのバージョンがv6.5.2より前の場合は、下流のTiDBクラスタが配置されているリージョン（IDC）にTiCDCをデプロイすることをお勧めします。 - TiCDC v6.5.2以降に導入された一連の改善により、TiCDCは上流のTiDBクラスタが配置されているリージョン（IDC）にデプロイすることが推奨されます。 -- TiCDC によって複製される各テーブルには、少なくとも 1 つの[有効なインデックス](#valid-index)があります。 +- TiCDC によって複製される各テーブルには、少なくとも 1つの[有効なインデックス](#valid-index)があります。 - TiCDC をディザスタリカバリに使用する際に最終的な整合性を確保するには、 [リドゥログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)を設定し、上流で災害が発生した場合でも、リドゥログが書き込まれるストレージシステムが正常に読み取れるようにする必要があります。 @@ -120,7 +120,7 @@ MySQLのbinlogは、アップストリームで実行されたすべてのDML SQ TiCDCは、データ変更情報に基づいて、さまざまなダウンストリームタイプに適した形式でデータを生成し、ダウンストリームに送信します。例えば、Canal-JSONやAvroなどの形式でデータを生成してKafkaに書き込んだり、データをSQL文に変換してダウンストリームのMySQLやTiDBに送信したりします。 -現在、TiCDC が対応するプロトコルのデータ変更情報を適応させる場合、特定の`UPDATE`イベントについて、それらのイベントを 1 つの`DELETE`イベントと 1 つの`INSERT`イベントに分割する場合があります。詳細については、 [MySQLシンクの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)および[MySQL以外のシンクにおける、主キーまたは一意キーを分割した`UPDATE`イベント](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 +現在、TiCDC が対応するプロトコルのデータ変更情報を適応させる場合、特定の`UPDATE`イベントについて、それらのイベントを 1つの`DELETE`イベントと 1つの`INSERT`イベントに分割する場合があります。詳細については、 [MySQLシンクの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)および[MySQL以外のシンクにおける、主キーまたは一意キーを分割した`UPDATE`イベント](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 ダウンストリームがMySQLまたはTiDBの場合、TiCDCはダウンストリームに書き込まれるSQL文がアップストリームで実行されるSQL文と完全に一致することを保証できません。これは、TiCDCがアップストリームで実行される元のDML文を直接取得するのではなく、データ変更情報に基づいてSQL文を生成するためです。ただし、TiCDCは最終結果の一貫性を保証します。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index df4671da79c29..5296cfb927a24 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -16,7 +16,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `pd` : PD エンドポイントのコンマ区切りリスト。 - `config` : TiCDCが使用する設定ファイルのアドレス（オプション）。このオプションはTiCDC v5.0.0以降でサポートされています。このオプションはTiUP v1.4.0以降のTiCDCデプロイメントで使用できます。詳細な設定については、 [TiCDC Changefeed構成](/ticdc/ticdc-changefeed-config.md)を参照してください。 - `data-dir` : TiCDC がファイルを保存するためにディスクを使用する必要があるときに使用するディレクトリを指定します。TiCDC が使用するソートエンジンと REDO ログは、このディレクトリに一時ファイルを保存します。このディレクトリの空きディスク容量は 500 GiB 以上確保することをお勧めします。TiUPを使用している場合は、セクション[`cdc_servers`](/tiup/tiup-cluster-topology-reference.md#cdc_servers)で`data_dir`設定するか、 `global`でデフォルトのパス`data_dir`を直接使用できます。 -- `gc-ttl` : TiCDC によって設定される PD のサービスレベル`GC safepoint`の TTL (Time To Live) と、レプリケーションタスクが一時停止できる期間（秒単位）。デフォルト値は`86400`で、これは 24 時間を意味します。注: TiCDC レプリケーションタスクの一時停止は、TiCDC GC セーフポイントの進行に影響します。つまり、 [TiCDC GCセーフポイントの完全な動作](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)で詳述されているように、上流の TiDB GC の進行にも影響します。 +- `gc-ttl` : TiCDC によって設定される PD のサービスレベル`GC safepoint`の TTL (Time To Live) と、レプリケーションタスクが一時停止できる期間（秒単位）。デフォルト値は`86400`で、これは 24時間を意味します。注: TiCDC レプリケーションタスクの一時停止は、TiCDC GC セーフポイントの進行に影響します。つまり、 [TiCDC GCセーフポイントの完全な動作](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)で詳述されているように、上流の TiDB GC の進行にも影響します。 - `log-file` : TiCDCプロセス実行時にログが出力されるパス。このパラメータが指定されていない場合、ログは標準出力（stdout）に書き込まれます。 - `log-level` : TiCDCプロセス実行時のログレベル。デフォルト値は`"info"`です。 - `ca` : TLS 接続用の PEM 形式の CA 証明書ファイルのパスを指定します (オプション)。 @@ -116,7 +116,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 ### `owner-flush-interval` {#owner-flush-interval} - TiCDCクラスタ内のオーナーモジュールがレプリケーションの進行状況をプッシュしようとする間隔を指定します。このパラメータはオプションで、デフォルト値は`50000000`ナノ秒（つまり50ミリ秒）です。 -- このパラメータは、数値のみを指定する（たとえば、 `40000000`に設定すると 40000000 ナノ秒、つまり 40 ミリ秒を表します）、または数値と単位の両方を指定する（たとえば、直接`40ms`に設定する）という 2 つの方法で設定できます。 +- このパラメータは、数値のみを指定する（たとえば、 `40000000`に設定すると 40000000 ナノ秒、つまり 40 ミリ秒を表します）、または数値と単位の両方を指定する（たとえば、直接`40ms`に設定する）という 2つの方法で設定できます。 - デフォルト値: `50000000` 、つまり50ミリ秒 ### `processor-flush-interval` {#processor-flush-interval} @@ -154,7 +154,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 #### `cache-size-in-mb` {#cache-size-in-mb} -- デフォルトで起動される 8 つの Pebble DB の Sorter モジュール内の共有 Pebbleブロックキャッシュのサイズを指定します。 +- デフォルトで起動される 8つの Pebble DB の Sorter モジュール内の共有 Pebbleブロックキャッシュのサイズを指定します。 - デフォルト値: `128` - 単位: MiB @@ -178,7 +178,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 #### `region-retry-duration` {#region-retry-duration} - リージョン接続の再試行期間を指定します。このパラメータはオプションです。 -- このパラメータは次の 2 つの方法で設定できます。 +- このパラメータは次の2つの方法で設定できます。 - 数字のみを指定します。たとえば、 `50000000` 50000000ナノ秒（50ミリ秒）を表します。 - 数値と単位の両方を指定します（例： `50ms` - デフォルト値: `60000000000` (1分) diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index a53eb5cefc2af..1f87fd2ea23dc 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -487,7 +487,7 @@ TiCDC は`BOOTSTRAP`イベントを次の JSON 形式でエンコードします ### WATERMARK {#watermark} -- 生成時間: TiCDC は、変更フィードのレプリケーションの進行状況を示すために、定期的に`WATERMARK`イベントを送信します。現在の間隔は 1 秒です。 +- 生成時間: TiCDC は、変更フィードのレプリケーションの進行状況を示すために、定期的に`WATERMARK`イベントを送信します。現在の間隔は 1秒です。 - 宛先: TiCDC は、対応するトピックのすべてのパーティションに`WATERMARK`イベントを送信します。 ### BOOTSTRAP {#bootstrap} @@ -508,7 +508,7 @@ TiCDC SimpleプロトコルはDMLメッセージの送信時にテーブルの - 各 DDL メッセージには、DDL イベントの前後のテーブルのスキーマ情報をマークするための`tableSchema`フィールドと`preTableSchema`フィールドが含まれています。 - 各 BOOTSTRAP メッセージには、BOOTSTRAP メッセージに対応するテーブルのスキーマ情報をマークするための`tableSchema`フィールドが含まれています。 -消費方法を次の 2 つのシナリオで紹介します。 +消費方法を次の2つのシナリオで紹介します。 ### シナリオ1: コンシューマーが最初から消費を始める {#scenario-1-the-consumer-starts-consuming-from-the-beginning} diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index 2221d5b984ca8..01a41df187288 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -277,7 +277,7 @@ CDC000005.csv - `TableVersion` : テーブルバージョン。 - `Query` : DDL ステートメント。 - `Type` : DDL タイプ。 -- `TableColumns` : 1 つ以上のマップの配列。各マップはソース テーブル内の列を表します。 +- `TableColumns` : 1つ以上のマップの配列。各マップはソース テーブル内の列を表します。 - `ColumnName` :カラム名。 - `ColumnType` :カラムの種類。詳細は[データ型](#data-type)を参照してください。 - `ColumnLength` :カラムの長さ。詳細は[データ型](#data-type)参照。 diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index b7228a8ca6ee3..a73510c53641a 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -83,7 +83,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na | `compression` | メッセージを送信する際に使用する圧縮アルゴリズム（値の選択肢は`none` 、 `lz4` 、 `gzip` 、 `snappy` 、 `zstd` 。デフォルトは`none` ）。Snappy圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)である必要があります。その他のSnappy圧縮形式はサポートされていません。 | | `auto-create-topic` | 渡された`topic-name` Kafka クラスターに存在しない場合に、TiCDC がトピックを自動的に作成するかどうかを決定します (オプション、デフォルトは`true` )。 | | `enable-tidb-extension` | オプション。デフォルトは`false` 。出力プロトコルが`canal-json`の場合、値が`true`であれば、TiCDC は[ウォーターマークイベント](/ticdc/ticdc-canal-json.md#watermark-event)を送信し、Kafka メッセージに[TiDB拡張フィールド](/ticdc/ticdc-canal-json.md#tidb-extension-field)を追加します。v6.1.0 以降では、このパラメータは`avro`プロトコルにも適用されます。値が`true`であれば、TiCDC は Kafka メッセージに[3つのTiDB拡張フィールド](/ticdc/ticdc-avro-protocol.md#tidb-extension-fields)を追加します。 | -| `max-batch-size` | v4.0.9 の新機能。メッセージプロトコルが 1 つの Kafka メッセージに複数のデータ変更を出力することをサポートしている場合、このパラメータは 1 つの Kafka メッセージに含まれるデータ変更の最大数を指定します。現在、このパラメータは Kafka の`protocol`が`open-protocol` （オプション、デフォルトは`16` ）の場合にのみ有効です。 | +| `max-batch-size` | v4.0.9 の新機能。メッセージプロトコルが 1つの Kafka メッセージに複数のデータ変更を出力することをサポートしている場合、このパラメータは 1つの Kafka メッセージに含まれるデータ変更の最大数を指定します。現在、このパラメータは Kafka の`protocol`が`open-protocol` （オプション、デフォルトは`16` ）の場合にのみ有効です。 | | `enable-tls` | ダウンストリーム Kafka インスタンスに接続するために TLS を使用するかどうか (オプション、デフォルトは`false` )。 | | `ca` | ダウンストリーム Kafka インスタンスに接続するために必要な CA 証明書ファイルのパス (オプション)。 | | `cert` | ダウンストリーム Kafka インスタンスに接続するために必要な証明書ファイルのパス (オプション)。 | @@ -115,7 +115,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na > **Note:** > -> `protocol`が`open-protocol`の場合、TiCDC は複数のイベントを 1 つの Kafka メッセージにエンコードし、 `max-message-bytes`で指定された長さを超えるメッセージの生成を回避します。1 行の変更イベントのエンコード結果が`max-message-bytes`を超える場合、changefeed はエラーを報告し、ログを出力。 +> `protocol`が`open-protocol`の場合、TiCDC は複数のイベントを 1つの Kafka メッセージにエンコードし、 `max-message-bytes`で指定された長さを超えるメッセージの生成を回避します。1 行の変更イベントのエンコード結果が`max-message-bytes`を超える場合、changefeed はエラーを報告し、ログを出力。 ### TiCDCはKafkaの認証と認可を使用します {#ticdc-uses-the-authentication-and-authorization-of-kafka} @@ -414,7 +414,7 @@ large-message-handle-compression = "none" `large-message-handle-compression`を設定した場合、TiCDC はメッセージを受信すると、まずメッセージサイズ制限パラメータの値と比較し、サイズ制限を超えるメッセージを圧縮します。[`sink-uri`](#configure-sink-uri-for-kafka)に`compression`も設定した場合、TiCDC は`sink-uri`設定に基づいて、送信データ要求全体をシンクレベルで再度圧縮します。 -前述の 2 つの圧縮方法の圧縮率は次のように計算されます`compression ratio = size before compression / size after compression * 100` 。 +前述の2つの圧縮方法の圧縮率は次のように計算されます`compression ratio = size before compression / size after compression * 100` 。 ### ハンドルキーのみ送信 {#send-handle-keys-only} @@ -544,7 +544,7 @@ Kafkaコンシューマーは、外部ストレージ内の大きなメッセー } ``` -`key`と`value`フィールドは、Kafka メッセージ内の同名のフィールドに対応しています。コンシューマーは、これらの 2 つのフィールドのデータを解析することで、元の大きなメッセージを取得できます。オープンプロトコルでエンコードされた Kafka メッセージのみが、 `key`フィールドに有効なコンテンツを含みます。TiCDC は、 `key`と`value`両方を単一の JSON オブジェクトにエンコードして、完全なメッセージを一度に配信します。他のプロトコルでは、 `key`フィールドは常に空です。 +`key`と`value`フィールドは、Kafka メッセージ内の同名のフィールドに対応しています。コンシューマーは、これらの 2つのフィールドのデータを解析することで、元の大きなメッセージを取得できます。オープンプロトコルでエンコードされた Kafka メッセージのみが、 `key`フィールドに有効なコンテンツを含みます。TiCDC は、 `key`と`value`両方を単一の JSON オブジェクトにエンコードして、完全なメッセージを一度に配信します。他のプロトコルでは、 `key`フィールドは常に空です。 #### `value`フィールドを外部ストレージにのみ送信する {#send-the-value-field-to-external-storage-only} diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index d675b6191a33d..31082347d6e3c 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -9,7 +9,7 @@ summary: TiCDC が UPDATE` イベントを分割するかどうかに関する v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`を取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 -- 1 つまたは複数の`UPDATE`変更を含むトランザクションの場合、トランザクション`commitTS` `thresholdTS`未満であれば、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割してから、それらを Sorter モジュールに書き込みます。 +- 1つまたは複数の`UPDATE`変更を含むトランザクションの場合、トランザクション`commitTS` `thresholdTS`未満であれば、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割してから、それらを Sorter モジュールに書き込みます。 - トランザクション`commitTS`が`thresholdTS`以上である`UPDATE`イベントの場合、TiCDC はそれらを分割しません。詳細については、GitHub の問題[＃10918](https://github.com/pingcap/tiflow/issues/10918)を参照してください。 > **Note:** @@ -110,7 +110,7 @@ COMMIT; この例では、2つの行の主キーを交換する3つのSQL文を実行することで、TiCDCは主キー`a` `1`から`2`に変更し、主キー`a` `2`から`1`に変更するという2つの更新変更イベントのみを受け取ります。コンシューマーがこれらの2つの`UPDATE`イベントをダウンストリームに直接書き込むと、主キーの競合が発生し、変更フィードエラーが発生します。 -したがって、TiCDC はこれら 2 つのイベントを 4 つのイベントに分割します。つまり、レコード`(1, 1)`と`(2, 2)`を削除し、レコード`(2, 1)`と`(1, 2)`を書き込みます。 +したがって、TiCDC はこれら2つのイベントを 4つのイベントに分割します。つまり、レコード`(1, 1)`と`(2, 2)`を削除し、レコード`(2, 1)`と`(1, 2)`を書き込みます。 ### 主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御する {#control-whether-to-split-primary-or-unique-key-update-events} diff --git a/ticdc/ticdc-summary-monitor.md b/ticdc/ticdc-summary-monitor.md index cfca9c388c27e..a8d501f088bb4 100644 --- a/ticdc/ticdc-summary-monitor.md +++ b/ticdc/ticdc-summary-monitor.md @@ -100,6 +100,6 @@ v7.0.0以降、 TiUPを使用してGrafanaをデプロイすると、TiCDCサマ ![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-redo.png) - **Redo 書き込み行数/秒**: Redo モジュールによって1秒あたりに書き込まれる行数。Redo 機能が有効になっている場合、レプリケーションタスクのレイテンシーが増加すると、このメトリックと Puller 出力イベント数/秒の値に大きな差があるかどうかを確認できます。差がある場合、レイテンシーの増加は Redo モジュールの書き込み容量不足が原因である可能性があります。 -- **Redo 書き込みバイト/秒**: Redo モジュールによって 1 秒あたりにデータが書き込まれる速度。 +- **Redo 書き込みバイト/秒**: Redo モジュールによって 1秒あたりにデータが書き込まれる速度。 - **Redoフラッシュログ時間**：Redoモジュールがデータを下流にフラッシュするのにかかる時間。このメトリック値が高い場合、この操作はレプリケーション速度に影響を与える可能性があります。 - **Redo フラッシュオール期間**: データの変更が Redo モジュールに留まる合計時間。 diff --git a/ticdc/ticdc-table-routing.md b/ticdc/ticdc-table-routing.md index 7275ad891628f..78094e7770b62 100644 --- a/ticdc/ticdc-table-routing.md +++ b/ticdc/ticdc-table-routing.md @@ -21,7 +21,7 @@ TiCDC のテーブルルーティングを使用すると、changefeed の設定 > **Note:** > > テーブルルーティングは、上流テーブルから下流ターゲットテーブルへの一対一のマッピングのみをサポートします。複数の上流テーブルを同じ下流テーブルにマージすることはサポートしていません。 -> テーブルルーティングは、1 つの上流テーブルを複数の下流テーブルに分割したり、行データの内容を変換したりすることはサポートしていません。 +> テーブルルーティングは、1つの上流テーブルを複数の下流テーブルに分割したり、行データの内容を変換したりすることはサポートしていません。 ## テーブルルーティングを設定する {#configure-table-routing} @@ -59,7 +59,7 @@ changefeed の開始後、TiCDC は `sales.orders` の DML および DDL イベ 一致動作は次のとおりです。 - テーブルルーティングには、`target-schema` または `target-table` を指定した `sink.dispatchers` ルールのみが使用されます。 -- 1 つのテーブルが複数のテーブルルーティングルールに一致する場合、`sink.dispatchers` 内で最初に一致したルールのみが有効になります。 +- 1つのテーブルが複数のテーブルルーティングルールに一致する場合、`sink.dispatchers` 内で最初に一致したルールのみが有効になります。 - `matcher` は常に上流のデータベース名とテーブル名に一致し、ルーティング後のターゲットデータベース名やテーブル名には一致しません。 - changefeed 設定項目 `case-sensitive` は、テーブルルーティング内の `matcher` が大文字小文字を区別するかどうかにのみ影響します。`{schema}` および `{table}` から展開される値の大文字小文字は変更しません。詳細は [`case-sensitive`](/ticdc/ticdc-changefeed-config.md#case-sensitive) を参照してください。 @@ -85,7 +85,7 @@ changefeed の開始後、TiCDC は `sales.orders` の DML および DDL イベ ## 例 {#examples} -### 1 つのデータベース内のすべてのテーブルをルーティングする {#route-all-tables-in-one-database} +### 1つのデータベース内のすべてのテーブルをルーティングする {#route-all-tables-in-one-database} 次の設定では、`sales` データベース内のすべてのテーブルを `archive` データベースにルーティングし、ターゲットテーブル名に `_bak` を追加します。 @@ -192,7 +192,7 @@ changefeed の作成時または更新時に、TiCDC は現在レプリケーシ ## ルート競合の検出 {#route-conflict-detection} -ルート競合は、1 つの changefeed 内で 2 つの異なる上流テーブルが同じ下流の `(schema, table)` にルーティングされる場合に発生します。TiCDC は、複数の上流テーブルを同じ下流テーブルにマージすることをサポートしていません。 +ルート競合は、1つの changefeed 内で 2つの異なる上流テーブルが同じ下流の `(schema, table)` にルーティングされる場合に発生します。TiCDC は、複数の上流テーブルを同じ下流テーブルにマージすることをサポートしていません。 たとえば、次の設定では競合が発生する可能性があります。 @@ -214,9 +214,9 @@ target-table = "{table}" `sales.orders` と `crm.orders` の両方がレプリケーション範囲に含まれている場合、両方のテーブルは `archive.orders` にルーティングされます。TiCDC は changefeed の作成または更新を拒否し、`CDC:ErrTableRouteConflict` エラーを返します。 -changefeed の実行中に、`CREATE TABLE` や `RENAME TABLE` などの DDL 文によって、現在レプリケーション範囲に含まれている 2 つの上流テーブルが同じターゲットテーブルにルーティングされるようになると、changefeed は失敗し、`CDC:ErrTableRouteConflict` エラーを返します。 +changefeed の実行中に、`CREATE TABLE` や `RENAME TABLE` などの DDL 文によって、現在レプリケーション範囲に含まれている 2つの上流テーブルが同じターゲットテーブルにルーティングされるようになると、changefeed は失敗し、`CDC:ErrTableRouteConflict` エラーを返します。 -上流テーブルが削除またはリネームされると、TiCDC はその上流テーブルとターゲットテーブルの間のルーティング関係を削除します。その後、新しい上流テーブルはそのターゲットテーブルを引き続き使用できます。ただし、任意の時点において、同じターゲットテーブルに対応できるのは、現在の changefeed によってレプリケートされている 1 つの上流テーブルのみです。 +上流テーブルが削除またはリネームされると、TiCDC はその上流テーブルとターゲットテーブルの間のルーティング関係を削除します。その後、新しい上流テーブルはそのターゲットテーブルを引き続き使用できます。ただし、任意の時点において、同じターゲットテーブルに対応できるのは、現在の changefeed によってレプリケートされている 1つの上流テーブルのみです。 > **Warning:** > @@ -228,8 +228,8 @@ changefeed の実行中に、`CREATE TABLE` や `RENAME TABLE` などの DDL 文 | :--- | :--- | :--- | | changefeed の作成または更新時に、TiCDC が `CDC:ErrInvalidTableRoutingRule` エラーを報告する。 | `matcher` の構文が無効であるか、`target-schema` または `target-table` に不明なプレースホルダーまたは対応しない中括弧が含まれている。 | `matcher` が [table filter syntax](/table-filter.md#syntax) に準拠しているか確認し、`target-schema` と `target-table` ではリテラルテキスト、`{schema}`、`{table}` のみを使用していることを確認してください。 | | MQ topic 名が引き続き上流のデータベース名とテーブル名を使用している。 | テーブルルーティングでは topic やパーティションのディスパッチルールは変更されない。 | topic 名を変更する必要がある場合は、`sink.dispatchers` で `topic` を個別に設定してください。 | -| DDL レプリケーション中に、TiCDC が `CDC:ErrTableRoutingFailed` エラーを報告する。 | TiCDC がテーブルルーティング用に DDL を安全に書き換えられないか、データベースレベル DDL のターゲットデータベースが曖昧である。 | DDL の種類とルーティングルールを確認してください。データベースレベル DDL の場合は、同じ上流データベースが 1 つのターゲットデータベースにのみマッピングされるようにしてください。 | -| 実行中に changefeed が失敗し、TiCDC が `CDC:ErrTableRouteConflict` エラーを報告する。 | テーブルの作成またはリネーム後に、2 つの異なる上流テーブルが同じ下流テーブルにルーティングされる。 | 単一の changefeed 内で、任意の時点において各ターゲットテーブルが現在の changefeed によってレプリケートされている 1 つの上流テーブルにのみ対応するよう、テーブルルーティングルールまたは上流 DDL を調整してください。 | +| DDL レプリケーション中に、TiCDC が `CDC:ErrTableRoutingFailed` エラーを報告する。 | TiCDC がテーブルルーティング用に DDL を安全に書き換えられないか、データベースレベル DDL のターゲットデータベースが曖昧である。 | DDL の種類とルーティングルールを確認してください。データベースレベル DDL の場合は、同じ上流データベースが 1つのターゲットデータベースにのみマッピングされるようにしてください。 | +| 実行中に changefeed が失敗し、TiCDC が `CDC:ErrTableRouteConflict` エラーを報告する。 | テーブルの作成またはリネーム後に、2つの異なる上流テーブルが同じ下流テーブルにルーティングされる。 | 単一の changefeed 内で、任意の時点において各ターゲットテーブルが現在の changefeed によってレプリケートされている 1つの上流テーブルにのみ対応するよう、テーブルルーティングルールまたは上流 DDL を調整してください。 | ## 関連ドキュメント {#related-documentation} diff --git a/tidb-architecture.md b/tidb-architecture.md index 85637a3c08208..490e1eb9aa445 100644 --- a/tidb-architecture.md +++ b/tidb-architecture.md @@ -7,7 +7,7 @@ summary: TiDBプラットフォームの主要なアーキテクチャコンポ -TiDB には、クラシック TiDBアーキテクチャと[TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)という 2 つのアーキテクチャがあります。このドキュメントでは、クラシック TiDBアーキテクチャについて説明します。 +TiDB には、クラシック TiDBアーキテクチャと[TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)という 2つのアーキテクチャがあります。このドキュメントでは、クラシック TiDBアーキテクチャについて説明します。 @@ -54,7 +54,7 @@ TiDB には、クラシック TiDBアーキテクチャと[TiDB Xアーキテク -各 TiKV ノードには複数のリージョンが存在します。TiKV API は、キーと値のペアレベルでの分散トランザクションをネイティブにサポートし、デフォルトでスナップショット分離レベルの分離をサポートします。これは、TiDB が SQL レベルで分散トランザクションをサポートする方法の中核です。TiDBサーバーはSQL 文を処理した後、SQL 実行計画を TiKV API への実際の呼び出しに変換します。そのため、データは TiKV に保存されます。TiKV 内のすべてのデータは複数のレプリカ（デフォルトでは 3 つのレプリカ）に自動的に保持されるため、TiKV はネイティブの高可用性を備え、自動フェイルオーバーをサポートします。 +各 TiKV ノードには複数のリージョンが存在します。TiKV API は、キーと値のペアレベルでの分散トランザクションをネイティブにサポートし、デフォルトでスナップショット分離レベルの分離をサポートします。これは、TiDB が SQL レベルで分散トランザクションをサポートする方法の中核です。TiDBサーバーはSQL 文を処理した後、SQL 実行計画を TiKV API への実際の呼び出しに変換します。そのため、データは TiKV に保存されます。TiKV 内のすべてのデータは複数のレプリカ（デフォルトでは 3つのレプリカ）に自動的に保持されるため、TiKV はネイティブの高可用性を備え、自動フェイルオーバーをサポートします。 ### TiFlashサーバー {#tiflash-server} diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 82aec28327de0..8ab6cf5d90e5d 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -111,7 +111,7 @@ TiDB Cloud BYOC のデプロイには、次の主要なコンポーネントが - **TiDB Cloud control plane**: TiDB Cloud コンソール、組織およびプロジェクト管理、課金、ライフサイクルのオーケストレーション、監視ビュー、アラート、メンテナンスワークフローを提供します。 - **BYOC data plane**: お客様のクラウドアカウント内で TiDB サービスおよび関連インフラストラクチャを実行します。TiDB Cloud は、BYOC オンボーディング時に付与された権限に基づいてこの環境を運用します。 -- **Resource pool**: 1 つ以上の {{{ .byoc }}} インスタンスに対する基盤となる物理リソース、ネットワーク、および容量の境界を定義します。各リソースプールには、独自の容量設定、リソースプール CIDR、高可用性モード、および AWS リソースタグがあります。 +- **Resource pool**: 1つ以上の {{{ .byoc }}} インスタンスに対する基盤となる物理リソース、ネットワーク、および容量の境界を定義します。各リソースプールには、独自の容量設定、リソースプール CIDR、高可用性モード、および AWS リソースタグがあります。 - **TiDB service VPC**: アプリケーショントラフィックを処理する TiDB サービスのコンポーネントをホストします。 - **Observability service VPC**: BYOC デプロイのメトリクス、ログ、運用データを収集するために使用される observability コンポーネントをホストします。 - **Application VPC**: お客様のアプリケーションをホストします。この VPC はお客様が管理し、BYOC TiDB サービスにアクセスするためのネットワーク接続を設定します。 @@ -134,7 +134,7 @@ VPC、VM、マネージドKubernetesサービス、クラウドストレージ TiDB Cloud Lake は、分析ワークロード向けのクラウドネイティブなデータウェアハウスサービスです。コンピュートとストレージを分離することで、ウェアハウスを個別にプロビジョニングし、ワークロードの変化に応じてスケールし、オブジェクトストレージにデータをコスト効率よく保存できます。 -TiDB Cloud Lake は、ANSI SQL、半構造化データ処理、ベクトル検索、AI 指向のワークフローを 1 つのプラットフォームでサポートします。基盤となるインフラストラクチャを自ら運用することなく、マネージドな分析エクスペリエンスを求めるチーム向けに設計されています。 +TiDB Cloud Lake は、ANSI SQL、半構造化データ処理、ベクトル検索、AI 指向のワークフローを 1つのプラットフォームでサポートします。基盤となるインフラストラクチャを自ら運用することなく、マネージドな分析エクスペリエンスを求めるチーム向けに設計されています。 詳細については、[TiDB Cloud Lake Overview](https://docs.pingcap.com/tidbcloudlake/lake-overview/) を参照してください。 diff --git a/tidb-cloud/branch-manage.md b/tidb-cloud/branch-manage.md index e411965394a70..9cb6976187e28 100644 --- a/tidb-cloud/branch-manage.md +++ b/tidb-cloud/branch-manage.md @@ -18,7 +18,7 @@ summary: TiDB Cloudブランチの管理方法を学びましょう。 > **Note:** > -> 2023 年 7 月 5 日以降に作成されたTiDB Cloud Starterインスタンスのブランチのみを作成できます。その他の制限事項については[制限事項と割り当て](/tidb-cloud/branch-overview.md#limitations-and-quotas)を参照してください。 +> 2023年 7月 5日以降に作成されたTiDB Cloud Starterインスタンスのブランチのみを作成できます。その他の制限事項については[制限事項と割り当て](/tidb-cloud/branch-overview.md#limitations-and-quotas)を参照してください。 ブランチを作成するには、以下の手順を実行します。 diff --git a/tidb-cloud/branch-overview.md b/tidb-cloud/branch-overview.md index 2ce8e399fe5ae..e5cd8174e9150 100644 --- a/tidb-cloud/branch-overview.md +++ b/tidb-cloud/branch-overview.md @@ -39,11 +39,11 @@ TiDB Cloudは、高速かつシームレスなブランチ作成を実現する 現在、 TiDB Cloud Branchingはパブリックプレビューです。 -- TiDB Cloudの各組織では、デフォルトではTiDB Cloud Starterインスタンス全体で最大 5 つのブランチを作成できます。TiDB CloudはTiDB Cloud Starterインスタンスのブランチをインスタンスと同じリージョンに作成します。また、スロットリングが適用されている、または 100 GiB を超えるサイズのTiDB Cloud Starterインスタンスにはブランチを作成できません。 +- TiDB Cloudの各組織では、デフォルトではTiDB Cloud Starterインスタンス全体で最大 5つのブランチを作成できます。TiDB CloudはTiDB Cloud Starterインスタンスのブランチをインスタンスと同じリージョンに作成します。また、スロットリングが適用されている、または 100 GiB を超えるサイズのTiDB Cloud Starterインスタンスにはブランチを作成できません。 > **Note:** > - > エージェント プラットフォームや多数のブランチを必要とするその他のサービスを構築している有料組織向けに、 TiDB Cloud は5 つを超えるブランチを作成できる**インスタンス容量計画**を提供します。詳細については、 [インスタンス容量計画](/tidb-cloud/select-cluster-tier.md#instance-capacity-plan)を参照してください。 + > エージェント プラットフォームや多数のブランチを必要とするその他のサービスを構築している有料組織向けに、 TiDB Cloud は5つを超えるブランチを作成できる**インスタンス容量計画**を提供します。詳細については、 [インスタンス容量計画](/tidb-cloud/select-cluster-tier.md#instance-capacity-plan)を参照してください。 - 無料のTiDB Cloud Starterインスタンスの各ブランチには、10 GiB のストレージが許可されます。利用制限が 0 より大きいTiDB Cloud Starterインスタンスの各ブランチには、100 GiB のストレージが許可されます。ストレージ容量が上限に達すると、ストレージを減らすまで、このブランチでの読み取りおよび書き込み操作が制限されます。 diff --git a/tidb-cloud/built-in-monitoring.md b/tidb-cloud/built-in-monitoring.md index 1e02f36216386..338f2fa2f3f00 100644 --- a/tidb-cloud/built-in-monitoring.md +++ b/tidb-cloud/built-in-monitoring.md @@ -33,12 +33,12 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | メトリック名 | ラベル | 説明 | | :------------------ | :-------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| SQLタイプ別のデータベース時間 | データベース時刻、{SQLタイプ} | データベース時間：1秒あたりのデータベース処理時間の合計。
    {SQL type}: SQL ステートメントが 1 秒あたりに消費するデータベース時間。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | -| 1秒あたりのクエリ数 | {SQL型} | すべての TiDB ノードで 1 秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | +| SQLタイプ別のデータベース時間 | データベース時刻、{SQLタイプ} | データベース時間：1秒あたりのデータベース処理時間の合計。
    {SQL type}: SQL ステートメントが 1秒あたりに消費するデータベース時間。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | +| 1秒あたりのクエリ数 | {SQL型} | すべての TiDB ノードで 1秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | | クエリ実行時間 | 平均-{SQLタイプ}、99-{SQLタイプ} | クライアントから TiDB にリクエストが送信されてから、TiDB がリクエストを実行して結果をクライアントに返すまでの時間。一般的に、クライアントのリクエストは SQL ステートメントの形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間が含まれる場合があります。TiDB はマルチクエリをサポートしており、クライアントは`select 1; select 1; select 1;`のように複数の SQL ステートメントを一度に送信できます。この場合、このクエリの合計実行時間には、すべての SQL ステートメントの実行時間が含まれます。 | | 失敗したクエリ | すべて、{エラータイプ} @ {インスタンス} | 各TiDBノードにおける1分あたりのSQL文実行エラー数に基づいた、エラーの種類（構文エラーや主キーの競合など）に関する統計情報です。エラーが発生したモジュールとエラーコードが含まれています。 | -| 1秒あたりのコマンド数 | クエリ、ステートメント実行、およびステートメント準備 | コマンドの種類に基づいて、すべての TiDB ノードが 1 秒あたりに処理するコマンドの数。 | -| プランキャッシュOPSを使用したクエリ | ヒット、ミス | hit: すべてのTiDBノードにおいて、1秒あたりにプランキャッシュを使用するクエリの数。
    miss: すべての TiDB ノードにおいて、1 秒あたりにプラン キャッシュに見つからないクエリの数。 | +| 1秒あたりのコマンド数 | クエリ、ステートメント実行、およびステートメント準備 | コマンドの種類に基づいて、すべての TiDB ノードが 1秒あたりに処理するコマンドの数。 | +| プランキャッシュOPSを使用したクエリ | ヒット、ミス | hit: すべてのTiDBノードにおいて、1秒あたりにプランキャッシュを使用するクエリの数。
    miss: すべての TiDB ノードにおいて、1秒あたりにプラン キャッシュに見つからないクエリの数。 | | トランザクション/秒 | {タイプ}-{トランザクションモデル} | 1秒あたりに実行されるトランザクション数。 | | トランザクション期間 | 平均-{トランザクションモデル}、99-{トランザクションモデル} | トランザクションの平均期間、または99パーセンタイル値。 | | 接続数 | すべて、アクティブな接続 | All: すべてのTiDBノードへの接続数。
    アクティブな接続数：すべてのTiDBノードへのアクティブな接続数。 | @@ -108,7 +108,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | ユニットをリクエストする | RU/秒 | リクエストユニット（RU）は、 TiDB Cloud Starterインスタンスにおけるクエリまたはトランザクションのリソース消費量を追跡するために使用される測定単位です。ユーザークエリに加えて、バックグラウンドアクティビティもRUを消費するため、QPSが0の場合でも、1秒あたりのRU使用量はゼロにならない場合があります。 | | 容量対使用量（RU/秒） | プロビジョニング済み容量（RCU）、消費RU/秒 | TiDB Cloud Essentialインスタンスにおける、1秒あたりのリクエストキャパシティユニット（RCU）と消費リクエストユニット（RU）。 | | 使用済みストレージサイズ | 行ベースストレージ、行ベースStandardストレージ、列ベースストレージ | 行ベースストレージ、行ベースStandardストレージ、列ベースストレージのサイズ。TiDB Cloud は、各ストレージタイプのサイズが50 MiB以上の場合にのみこのメトリックを表示します。**Row-based standard storage**は**Row-based storage**と同じ意味です。| -| 1秒あたりのクエリ数 | すべて、{SQLタイプ} | 1 秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | +| 1秒あたりのクエリ数 | すべて、{SQLタイプ} | 1秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | | クエリ実行時間 | 平均値、P99、P99-{SQLタイプ} | クライアントからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにリクエストが送信されてから、インスタンスがリクエストを実行して結果をクライアントに返すまでの時間。 | | クエリが失敗しました | 全て | 1秒あたりのSQL文実行エラー数。 | | トランザクション/秒 | 全て | 1秒あたりに実行されるトランザクション数。 | diff --git a/tidb-cloud/calibrate-resource.md b/tidb-cloud/calibrate-resource.md index f3b477afd8418..5d358a1da40aa 100644 --- a/tidb-cloud/calibrate-resource.md +++ b/tidb-cloud/calibrate-resource.md @@ -32,7 +32,7 @@ TiDB Cloud Dedicated クラスターでは、TiDB Cloud コンソールの **Mon - `OLTP_READ_WRITE`: データの読み取りと書き込みが均等なワークロードに適用されます。`sysbench oltp_read_write` に類似したワークロードモデルに基づいて見積もられます。 - `OLTP_READ_ONLY`: データ読み取りが多いワークロードに適用されます。`sysbench oltp_read_only` に類似したワークロードモデルに基づいて見積もられます。 - - **Calibrate by Workload**: 選択した時間枠内の実際のワークロードに基づいて容量を見積もります。時間枠は 10 分から 24 時間までです。 + - **Calibrate by Workload**: 選択した時間枠内の実際のワークロードに基づいて容量を見積もります。時間枠は 10分から 24時間までです。 選択した時間枠内のワークロードが低すぎる場合、TiDB は容量見積もりを生成できません。この場合は、より高いワークロードの別の時間枠を選択するか、代わりにハードウェアに基づいてリソースをキャリブレーションしてください。 diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index ba3bab4f132da..80871d7c0ec57 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -18,7 +18,7 @@ TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサ > **Note:** > -> - 現在、 TiDB Cloudでは、 TiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスごとに最大 100 件の変更フィードのみが許可されます。 +> - 現在、 TiDB Cloudでは、 TiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスごとに最大 100件の変更フィードのみが許可されます。 > - 現在、 TiDB Cloud、変更フィードごとに最大100個のテーブルフィルタルールしか設定できません。 > - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 > - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスの場合、変更フィード機能はリクエストに応じてのみ利用できます。詳細については、 [変更フィード](/tidb-cloud/essential-changefeed-overview.md)を参照してください。 @@ -85,8 +85,8 @@ TiDB Cloud Premiumでは、チェンジフィードのTiCDC 変更フィード > **Note:** > -> - TiDB Cloud Dedicatedクラスターの変更フィードをスケーリングするには、このクラスターのすべての変更フィードが 2023 年 3 月 28 日以降に作成されていることを確認してください。 -> - TiDB Cloud Dedicatedクラスターに 2023 年 3 月 28 日より前に作成された変更フィードがある場合、このクラスターの既存の変更フィードも新しく作成された変更フィードもスケールアップまたはスケールダウンをサポートしません。 +> - TiDB Cloud Dedicatedクラスターの変更フィードをスケーリングするには、このクラスターのすべての変更フィードが 2023年 3月 28日以降に作成されていることを確認してください。 +> - TiDB Cloud Dedicatedクラスターに 2023年 3月 28日より前に作成された変更フィードがある場合、このクラスターの既存の変更フィードも新しく作成された変更フィードもスケールアップまたはスケールダウンをサポートしません。 @@ -169,4 +169,4 @@ TiDB Cloudでの変更フィードの請求については、[Changefeedの請 - `DELETING` : レプリケーション タスクが削除されています。 - `DELETED` : レプリケーション タスクが削除されました。 - `WARNING` : レプリケーション タスクが警告を返します。回復可能なエラーのため、レプリケーションを続行できません。この状態の変更フィードは、状態が`RUNNING`に遷移するまで再開を試み続けます。この状態の変更フィードは[GCオペレーション](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)ブロックします 。 -- `FAILED` : レプリケーション タスクが失敗しました。エラーが発生したため、レプリケーション タスクを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期間 (TTL) は 24 時間です。つまり、変更フィードが中断されてから 24 時間以内に GC メカニズムによってデータが削除されることはありません。 +- `FAILED` : レプリケーション タスクが失敗しました。エラーが発生したため、レプリケーション タスクを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期間 (TTL) は 24時間です。つまり、変更フィードが中断されてから 24時間以内に GC メカニズムによってデータが削除されることはありません。 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index f5fea2a677777..3e75211610b0b 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -310,7 +310,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 変更フィードで全ての変更ログに対して1つのKafkaトピックを作成する場合は、このモードを選択してください。そうすると、変更フィード内のすべてのKafkaメッセージが1つのKafkaトピックに送信されます。トピック名は**Topic Name**フィールドで指定できます。 -8. **Partition Distribution**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloud、次の 4 種類のディスパッチャが提供されています。 +8. **Partition Distribution**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloud、次の4種類のディスパッチャが提供されています。 - **主キーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** @@ -318,7 +318,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - **変更ログをテーブルごとにKafkaパーティションに分散する** - 変更フィードによってテーブルの Kafka メッセージを 1 つの Kafka パーティションに送信する場合は、この分散方法を選択してください。行の変更ログのテーブル名によって、変更ログが送信されるパーティションが決まります。この分散方法はテーブルの順序性を保証しますが、パーティションのバランスが崩れる可能性があります。 + 変更フィードによってテーブルの Kafka メッセージを 1つの Kafka パーティションに送信する場合は、この分散方法を選択してください。行の変更ログのテーブル名によって、変更ログが送信されるパーティションが決まります。この分散方法はテーブルの順序性を保証しますが、パーティションのバランスが崩れる可能性があります。 - **変更ログをタイムスタンプに基づいてKafkaパーティションに分散する** diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 87cbfd762b5cb..c823ffb1d8636 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -167,7 +167,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 Pulsarはマルチテナントをサポートしているため、デフォルト設定と異なる場合は、 **Pulsar Tenant**と**Pulsar Namespace**を設定することもできます。 -6. **Partition Distribution**領域では、Pulsar メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloud、変更イベントを Pulsar パーティションに分散するための 4 つのルール オプションが提供されています。 +6. **Partition Distribution**領域では、Pulsar メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloud、変更イベントを Pulsar パーティションに分散するための 4つのルール オプションが提供されています。 - **主キーまたは一意インデックス** @@ -175,7 +175,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 - **テーブル** - 変更フィードによってテーブルの Pulsar メッセージを 1 つの Pulsar パーティションに送信する場合は、この配信方法を選択してください。行の変更ログのテーブル名によって、変更ログの送信先パーティションが決まります。この配信方法はテーブルの順序性を確保しますが、パーティションのバランスが崩れる可能性があります。 + 変更フィードによってテーブルの Pulsar メッセージを 1つの Pulsar パーティションに送信する場合は、この配信方法を選択してください。行の変更ログのテーブル名によって、変更ログの送信先パーティションが決まります。この配信方法はテーブルの順序性を確保しますが、パーティションのバランスが崩れる可能性があります。 - **タイムスタンプ** diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index b37440c050912..7a6ec7cf98aff 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -98,7 +98,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること 既存のデータを読み込むには： -1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の 2 つの操作の合計時間よりも長く設定することで、その期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 +1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の2つの操作の合計時間よりも長く設定することで、その期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 - 既存データのエクスポートとインポートにかかる時間 - **Sink to MySQL**を作成する時間 diff --git a/tidb-cloud/changefeed-sink-to-tidb-cloud.md b/tidb-cloud/changefeed-sink-to-tidb-cloud.md index 020d7f709a0c9..36af0c7465c3c 100644 --- a/tidb-cloud/changefeed-sink-to-tidb-cloud.md +++ b/tidb-cloud/changefeed-sink-to-tidb-cloud.md @@ -36,7 +36,7 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから 変更フィードを作成する前に、ソースのTiDB Cloud Dedicatedクラスターから既存のデータをエクスポートし、そのデータを宛先のTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにロードする必要があります。 -1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の 2 つの操作の合計時間よりも長く設定することで、その期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 +1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の2つの操作の合計時間よりも長く設定することで、その期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 - 既存データのエクスポートとインポートにかかる時間 - **Sink to TiDB Cloud**を作成する時間 diff --git a/tidb-cloud/connect-via-standard-connection-serverless.md b/tidb-cloud/connect-via-standard-connection-serverless.md index a983e4e9fc619..d980b56e67a8d 100644 --- a/tidb-cloud/connect-via-standard-connection-serverless.md +++ b/tidb-cloud/connect-via-standard-connection-serverless.md @@ -11,8 +11,8 @@ summary: パブリックエンドポイントを介して、 TiDB Cloud Starter TiDB Cloudプランに応じて、適切なエンドポイントモデルを選択します。 -- {{{ .starter }}} インスタンス、または 2026 年 7 月 1 日より前に作成された {{{ .essential }}} インスタンスの場合は、 [**エンドポイント共有モデル**](#connect-via-a-public-endpoint-endpoint-shared-model)を使用します。このモデルでは、単一のパブリックエンドポイントを同じリージョン内の複数の {{{ .starter }}} インスタンスおよび Essential インスタンスで共有できます。 -- 2026 年 7 月 1 日以降に作成された {{{ .essential }}} インスタンスの場合は、 [**エンドポイント占有モデル**](#connect-via-a-public-endpoint-endpoint-exclusive-model)を使用します。このモデルでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンパブリックエンドポイントを使用します。このモデルでは接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がなくなりますが、各 {{{ .essential }}} インスタンスに対してセットアップ手順を繰り返す必要があります。 +- {{{ .starter }}} インスタンス、または 2026年 7月 1日より前に作成された {{{ .essential }}} インスタンスの場合は、 [**エンドポイント共有モデル**](#connect-via-a-public-endpoint-endpoint-shared-model)を使用します。このモデルでは、単一のパブリックエンドポイントを同じリージョン内の複数の {{{ .starter }}} インスタンスおよび Essential インスタンスで共有できます。 +- 2026年 7月 1日以降に作成された {{{ .essential }}} インスタンスの場合は、 [**エンドポイント占有モデル**](#connect-via-a-public-endpoint-endpoint-exclusive-model)を使用します。このモデルでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンパブリックエンドポイントを使用します。このモデルでは接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がなくなりますが、各 {{{ .essential }}} インスタンスに対してセットアップ手順を繰り返す必要があります。 ## 公開エンドポイント経由で接続します（エンドポイント共有モデル） {#connect-via-a-public-endpoint-endpoint-shared-model} @@ -63,7 +63,7 @@ TiDB Cloudプランに応じて、適切なエンドポイントモデルを選 > **Note:** > -> 現在、エンドポイント占有モデルは、特定のリージョンで 2026 年 7 月 1 日以降に作成された {{{ .essential }}} インスタンスでのみ使用できます。お使いのインスタンスで利用できない場合は、代わりに[エンドポイント共有モデル](#connect-via-a-public-endpoint-endpoint-shared-model)を使用できます。 +> 現在、エンドポイント占有モデルは、特定のリージョンで 2026年 7月 1日以降に作成された {{{ .essential }}} インスタンスでのみ使用できます。お使いのインスタンスで利用できない場合は、代わりに[エンドポイント共有モデル](#connect-via-a-public-endpoint-endpoint-shared-model)を使用できます。 エンドポイント占有モデルでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンパブリックエンドポイントを使用します。このモデルでは接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がなくなりますが、各 {{{ .essential }}} インスタンスに対してセットアップ手順を繰り返す必要があります。 diff --git a/tidb-cloud/connected-care-overview.md b/tidb-cloud/connected-care-overview.md index 6033fa1b1ab5e..00da2d7321e3b 100644 --- a/tidb-cloud/connected-care-overview.md +++ b/tidb-cloud/connected-care-overview.md @@ -16,7 +16,7 @@ aliases: ['/ja/tidbcloud/connected-care-announcement'] Connected Care サービスは、最新のコミュニケーション ツール、プロアクティブなサポート、高度な AI 機能を通じてTiDB Cloudとの接続を強化し、シームレスで顧客中心のエクスペリエンスを実現するように設計されています。 -Connected Care サービスには、 **Basic** 、 **Developer** (従来の**Standard**プランに相当)、 **Enterprise** 、 **Premium の**4 つのサポート プランがあります。 +Connected Care サービスには、 **Basic** 、 **Developer** (従来の**Standard**プランに相当)、 **Enterprise** 、 **Premium の**4つのサポート プランがあります。 > **Note** > @@ -39,7 +39,7 @@ Connected Care サービスには、 **Basic** 、 **Developer** (従来の**Sta > **Note** > -> 4 つのサポート プランすべてのお客様は、サービス リクエストに[PingCAPサポートポータル](https://tidb.support.pingcap.com/)を利用できます。 +> 4つのサポート プランすべてのお客様は、サービス リクエストに[PingCAPサポートポータル](https://tidb.support.pingcap.com/)を利用できます。 ## 従来のサポートサービスとConnected Careサポートサービスの違い {#differences-between-legacy-support-services-and-connected-care-support-services} diff --git a/tidb-cloud/create-tidb-cluster-serverless.md b/tidb-cloud/create-tidb-cluster-serverless.md index 15aaa377e9a9f..64f26f69e2b12 100644 --- a/tidb-cloud/create-tidb-cluster-serverless.md +++ b/tidb-cloud/create-tidb-cluster-serverless.md @@ -56,7 +56,7 @@ TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbc - TiDB Cloud Starterインスタンスの利用限度額を更新できます。利用限度額を0に設定すると、インスタンスは無料のままです。利用限度額を0より大きい値に設定する場合は、 TiDB Cloud Starterインスタンスを作成する前にクレジットカードを追加する必要があります。 - - デフォルトでは、各組織は最大 5 つ [無料のTiDB Cloud Starterインスタンス](/tidb-cloud/select-cluster-tier.md#starter)を作成できます。追加のTiDB Cloud Starterインスタンスを作成するには、クレジット カードを追加し、使用制限を指定する必要があります。 + - デフォルトでは、各組織は最大 5つ [無料のTiDB Cloud Starterインスタンス](/tidb-cloud/select-cluster-tier.md#starter)を作成できます。追加のTiDB Cloud Starterインスタンスを作成するには、クレジット カードを追加し、使用制限を指定する必要があります。 - **Essential**プラン： diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 38d25bd233403..b988162f0b747 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -26,11 +26,11 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access - TiDB Cloud Data Serviceでは、デフォルトではAPIキーごとに1分あたり最大100件のリクエスト（rpm）が許可されています。 - API キーのレート制限は、キーを[作成する](#create-an-api-key)または[編集](#edit-an-api-key)するときに編集できます。サポートされている値の範囲は、 `1`から`1000`です。 1 分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1000 rpm を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。 + API キーのレート制限は、キーを[作成する](#create-an-api-key)または[編集](#edit-an-api-key)するときに編集できます。サポートされている値の範囲は、 `1`から`1000`です。 1分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1000 rpm を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。 各APIリクエストは、制限に関する以下のヘッダーを返します。 - - `X-Ratelimit-Limit-Minute` : 1 分あたりに許可されるリクエスト数。 + - `X-Ratelimit-Limit-Minute` : 1分あたりに許可されるリクエスト数。 - `X-Ratelimit-Remaining-Minute` : 現在の1分間に残っているリクエスト数。この数が`0`に達すると、APIは`429`エラーを返し、レート制限を超過したことを示します。 - `X-Ratelimit-Reset` : 現在のレート制限がリセットされるまでの時間（秒）。 @@ -108,7 +108,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access 3. （オプション）APIキーの希望するレート制限を設定します。 - 1 分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1 分あたり 1000 リクエスト (rpm) を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。 + 1分あたりのリクエストがレート制限を超えると、API は`429`エラーを返します。 API キーごとに 1分あたり 1000 リクエスト (rpm) を超える割り当てを取得するには、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。 4. （オプション）APIキーの有効期限を設定します。 diff --git a/tidb-cloud/data-service-app-config-files.md b/tidb-cloud/data-service-app-config-files.md index 09b56c165fab0..a9fb44d4e969b 100644 --- a/tidb-cloud/data-service-app-config-files.md +++ b/tidb-cloud/data-service-app-config-files.md @@ -34,7 +34,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 各データアプリは、1つまたは複数のTiDBクラスターにリンクできます。 -以下は`cluster.json`の構成例です。この例では、このデータアプリにリンクされたクラスターが 2 つあります。 +以下は`cluster.json`の構成例です。この例では、このデータアプリにリンクされたクラスターが 2つあります。 ```json [ @@ -102,7 +102,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 各データアプリには、1つまたは複数のエンドポイントが存在する可能性があります。データアプリのすべてのエンドポイントの設定は`http_endpoints/config.json`で確認できます。 -以下は`config.json`の構成例です。この例では、このデータアプリには 2 つのエンドポイントがあります。 +以下は`config.json`の構成例です。この例では、このデータアプリには 2つのエンドポイントがあります。 ```json [ @@ -171,7 +171,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 | `method` | string | エンドポイントの HTTP メソッド。 `GET`を使用してデータを取得し、 `POST`を使用してデータを作成または挿入し、 `PUT`を使用してデータを更新または変更し、 `DELETE`を使用してデータを削除できます。 | | `endpoint` | string | データ アプリ内のエンドポイントの一意のパス。パスには、文字、数字、アンダースコア ( `_` )、およびスラッシュ ( `/` ) のみを使用できます。パスはスラッシュ ( `/` ) で始まり、文字、数字、またはアンダースコア ( `_` ) で終わる必要があります。例: `/my_endpoint/get_id` 。パスの長さは 64 文字未満である必要があります。 | | `cluster_id` | string | エンドポイントのTiDB Cloud Starterインスタンスの ID です。インスタンスの URL から取得できます。たとえば、インスタンスの URL が`https://tidbcloud.com/tidbs/1234567891234567890/overview?orgId=`の場合、インスタンス ID は`1234567891234567890`です。 | -| `params` | 配列 | エンドポイントで使用されるパラメーター。パラメーターを定義することで、エンドポイントを介してクエリ内のパラメーター値を動的に置き換えることができます。 `params`では、1 つまたは複数のパラメーターを定義できます。各パラメーターについて、 `name` 、 `type` 、 `required` 、および`default`フィールドを定義する必要があります。エンドポイントにパラメーターが必要ない場合は、 `"params": []`のように`params`を空のままにすることができます。 | +| `params` | 配列 | エンドポイントで使用されるパラメーター。パラメーターを定義することで、エンドポイントを介してクエリ内のパラメーター値を動的に置き換えることができます。 `params`では、1つまたは複数のパラメーターを定義できます。各パラメーターについて、 `name` 、 `type` 、 `required` 、および`default`フィールドを定義する必要があります。エンドポイントにパラメーターが必要ない場合は、 `"params": []`のように`params`を空のままにすることができます。 | | `params.name` | string | パラメータ名。名前には文字、数字、アンダースコアのみを使用できます（ `_` ）。また、文字またはアンダースコアで始まる必要があります（ `_` ）。 `page`および`page_size`はリクエスト結果のページネーション用に**予約されて**いるため、パラメータ名として使用しないでください。 | | `params.type` | string | パラメーターのデータ型。サポートされている値は`string` 、 `number` 、 `integer` 、 `boolean` 、および`array` 。 `string`型のパラメーターを使用する場合は、引用符（ `'`または`"` ）を追加する必要はありません。例えば、 `foo` `string`タイプに対して有効であり、 `"foo"`として処理されますが、 `"foo"`は`"\"foo\""`として処理されます。 | | `params.required` | integer | リクエストでパラメータが必須かどうかを指定します。サポートされている値は、 `0` (必須ではない) と`1` (必須) です。デフォルト値は`0`です。 | @@ -185,7 +185,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 | `settings.cache_enabled` | integer | `GET`リクエストによって返されたレスポンスを、指定された有効期限 (TTL) 期間内にキャッシュするかどうかを制御します。サポートされている値は、 `0` (無効) と`1` (有効) です。デフォルト値は`0`です。 | | `settings.cache_ttl` | integer | `settings.cache_enabled`を`1`に設定した場合のキャッシュされた応答の有効期間 (TTL) を秒単位で指定します。30 ～ 600 のinteger値を設定できます。TTL 期間中に同じ`GET`リクエストを再度行うと、Data Serviceは対象データベースからデータを再度取得する代わりに、キャッシュされた応答を直接返します。これにより、クエリのパフォーマンスが向上します。 | | `tag` | string | エンドポイントのタグ。デフォルト値は`"Default"`です。 | -| `batch_operation` | integer | エンドポイントをバッチモードで動作させるかどうかを制御します。サポートされている値は`0` (無効) と`1` (有効) です。 `1`に設定すると、1 つのリクエストで複数の行を操作できます。このオプションを有効にするには、リクエストメソッドが`POST`または`PUT`であることを確認してください。 | +| `batch_operation` | integer | エンドポイントをバッチモードで動作させるかどうかを制御します。サポートされている値は`0` (無効) と`1` (有効) です。 `1`に設定すると、1つのリクエストで複数の行を操作できます。このオプションを有効にするには、リクエストメソッドが`POST`または`PUT`であることを確認してください。 | | `sql_file` | string | エンドポイントの SQL ファイルディレクトリ。例: `"sql/GET-v1.sql"` 。 | | `type` | string | エンドポイントのタイプ。定義済みのシステムエンドポイントの場合は`"system-data"` 、その他のエンドポイントの場合は`"sql_endpoint"`となります。 | | `return_type` | string | エンドポイントの応答形式は`"json"`のみです。 | diff --git a/tidb-cloud/data-service-get-started.md b/tidb-cloud/data-service-get-started.md index b4c3b65267cad..6756514906fbd 100644 --- a/tidb-cloud/data-service-get-started.md +++ b/tidb-cloud/data-service-get-started.md @@ -156,7 +156,7 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 WindowsまたはLinuxの場合： - - エディタにステートメントが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **[実行]**。 + - エディタにステートメントが 1つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **[実行]**。 - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **Ctrl + Enter**キーを押すか、 **[実行]**をクリックします。 diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index 904ffc36dfa47..9b905a0efd18d 100644 --- a/tidb-cloud/data-service-manage-endpoint.md +++ b/tidb-cloud/data-service-manage-endpoint.md @@ -48,10 +48,10 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の 選択したテーブルに [ベクトルデータ型](/ai/reference/vector-search-data-types.md)が含まれている場合は、**Vector Search Operations**オプションを有効にしてベクトル距離関数を選択することで、選択した距離関数に基づいてベクトル距離を自動的に計算するベクトル検索エンドポイントを生成できます。サポートされている[ベクトル距離関数](/ai/reference/vector-search-functions-and-operators.md)は次のものが含まれます。 - - `VEC_L2_DISTANCE` (デフォルト): 2 つのベクトル間の L2 距離 (ユークリッド距離) を計算します。 - - `VEC_COSINE_DISTANCE` : 2 つのベクトル間のコサイン距離を計算します。 - - `VEC_NEGATIVE_INNER_PRODUCT` : 2 つのベクトルの内積の負の値を使用して距離を計算します。 - - `VEC_L1_DISTANCE` : 2 つのベクトル間の L1 距離 (マンハッタン距離) を計算します。 + - `VEC_L2_DISTANCE` (デフォルト): 2つのベクトル間の L2 距離 (ユークリッド距離) を計算します。 + - `VEC_COSINE_DISTANCE` : 2つのベクトル間のコサイン距離を計算します。 + - `VEC_NEGATIVE_INNER_PRODUCT` : 2つのベクトルの内積の負の値を使用して距離を計算します。 + - `VEC_L1_DISTANCE` : 2つのベクトル間の L1 距離 (マンハッタン距離) を計算します。 3. （オプション）操作のタイムアウトとタグを設定します。生成されたすべてのエンドポイントは、設定されたプロパティを自動的に継承しますが、必要に応じて後で変更できます。 @@ -162,7 +162,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > > `GET /var/{var2}` > - > `GET /var/123`両方に一致するため、これら 2 つのパスは互いに競合します。 + > `GET /var/123`両方に一致するため、これら2つのパスは互いに競合します。 > > - パラメータを含むパスは、パラメータを含まないパスよりも優先度が低くなります。例： > @@ -170,7 +170,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > > `GET /var/123` > - > `GET /var/123`が優先されるため、これら 2 つのパスは競合しません。 + > `GET /var/123`が優先されるため、これら2つのパスは競合しません。 > > - パス パラメーターは SQL で直接使用できます。詳細については、[パラメータを設定する](#configure-parameters)を参照してください。 @@ -261,7 +261,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 WindowsまたはLinuxの場合： - - エディタにステートメントが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **[実行]**。 + - エディタにステートメントが 1つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **[実行]**。 - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **Ctrl + Enter**キーを押すか、 **[実行]**をクリックします。 @@ -467,8 +467,8 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ - エンドポイントのリクエストメソッドが`POST`または`PUT`の場合は、操作対象のデータ行に応じて`--data-raw`オプションを入力してください。 - - **Batch Operation**が有効になっているエンドポイントの場合、 `--data-raw`オプションは、データ オブジェクトの配列を含む`items`フィールドを持つオブジェクトを受け入れるため、1 つのエンドポイントを使用して複数のデータ行を操作できます。 - - **Batch Operation**が有効になっていないエンドポイントの場合、 `--data-raw`オプションは 1 つのデータ オブジェクトのみを受け入れます。 + - **Batch Operation**が有効になっているエンドポイントの場合、 `--data-raw`オプションは、データ オブジェクトの配列を含む`items`フィールドを持つオブジェクトを受け入れるため、1つのエンドポイントを使用して複数のデータ行を操作できます。 + - **Batch Operation**が有効になっていないエンドポイントの場合、 `--data-raw`オプションは 1つのデータ オブジェクトのみを受け入れます。 - エンドポイントにパラメータが含まれている場合は、エンドポイントを呼び出す際にパラメータ値を指定してください。 diff --git a/tidb-cloud/data-service-postman-integration.md b/tidb-cloud/data-service-postman-integration.md index 08adb208fd05b..cb9dce5ccc652 100644 --- a/tidb-cloud/data-service-postman-integration.md +++ b/tidb-cloud/data-service-postman-integration.md @@ -19,7 +19,7 @@ Postmanにデータアプリをインポートする前に、以下のものを - [Postmanデスクトップアプリ](https://www.postman.com/downloads)(オプション)。あるいは、アプリをダウンロードせずに Postman Web バージョンを使用することもできます。 -- 明確に定義された[終点](/tidb-cloud/data-service-manage-endpoint.md)が少なくとも 1 つある[データアプリ](/tidb-cloud/data-service-manage-data-app.md)。次の要件を満たすエンドポイントのみを Postman にインポートできます。 +- 明確に定義された[終点](/tidb-cloud/data-service-manage-endpoint.md)が少なくとも 1つある[データアプリ](/tidb-cloud/data-service-manage-data-app.md)。次の要件を満たすエンドポイントのみを Postman にインポートできます。 - 対象のTiDB Cloud Starterインスタンスが選択されました。 - エンドポイントパスとリクエストメソッドが設定されました。 diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index e685252c5f9fb..a0d2745fd1b4a 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -151,7 +151,7 @@ TiDBの主キー制約はMySQLと同様に一意性制約を含んでおり、 ### 外部キー制約 {#foreign-key-constraints} -外部キーは、2 つのテーブル間の参照整合性を強制するデータベース制約です。これは、一方のテーブル (子テーブル) の列をもう一方のテーブル (親テーブル) の列にリンクすることによって実現されます。これにより、子テーブルの外部キー列の値が、親テーブルの主キーまたは一意キー列の値と一致することが保証されます。たとえば、 `orders`テーブルのレコードは、 `customers`テーブルの顧客にリンクする外部キーを持つことができ、各注文が有効な顧客に関連付けられていることが保証されます。 +外部キーは、2つのテーブル間の参照整合性を強制するデータベース制約です。これは、一方のテーブル (子テーブル) の列をもう一方のテーブル (親テーブル) の列にリンクすることによって実現されます。これにより、子テーブルの外部キー列の値が、親テーブルの主キーまたは一意キー列の値と一致することが保証されます。たとえば、 `orders`テーブルのレコードは、 `customers`テーブルの顧客にリンクする外部キーを持つことができ、各注文が有効な顧客に関連付けられていることが保証されます。 TiDBはバージョン6.6.0以降、実験的機能として外部キー制約をサポートしています。この機能により、関連データのテーブル間参照が可能になり、参照整合性を強制することでデータの一貫性を維持できます。ただし、この機能は実験的であり、特にデータ量が多い場合、パフォーマンスの問題が発生する可能性があるため、本番環境での本番は推奨されません。 diff --git a/tidb-cloud/delete-tidb-cluster.md b/tidb-cloud/delete-tidb-cluster.md index bddb07ebfaa73..ac0598efe5f08 100644 --- a/tidb-cloud/delete-tidb-cluster.md +++ b/tidb-cloud/delete-tidb-cluster.md @@ -25,7 +25,7 @@ summary: TiDB Cloudリソースを削除する方法を学びましょう。 4. 削除確認ウィンドウで、削除を確定してください。 - - 手動または自動バックアップが少なくとも 1 つある場合は、バックアップの数とバックアップの課金ポリシーを確認できます。 **[続行]**をクリックして`//`と入力します。 + - 手動または自動バックアップが少なくとも 1つある場合は、バックアップの数とバックアップの課金ポリシーを確認できます。 **[続行]**をクリックして`//`と入力します。 - バックアップがない場合は、 `//`と入力してください。 今後、削除したTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスターを復元したい場合は、必ずバックアップを作成してください。バックアップがない場合、復元することはできません。 diff --git a/tidb-cloud/essential-changefeed-overview.md b/tidb-cloud/essential-changefeed-overview.md index 65a2b90d4795d..ddc2d18be7c72 100644 --- a/tidb-cloud/essential-changefeed-overview.md +++ b/tidb-cloud/essential-changefeed-overview.md @@ -198,4 +198,4 @@ ticloud serverless changefeed delete --cluster-id --changefeed-id < - `RUNNING` : changefeed は正常に実行され、checkpoint-ts も正常に進行します。 - `PAUSED` : 変更フィードが一時停止されています。 - `WARNING` : 変更フィードが警告を返します。回復可能なエラーのため、変更フィードは続行できません。この状態の変更フィードは、状態が`RUNNING`に遷移するまで再開を試み続けます。この状態の変更フィードは[GCオペレーション](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)ブロックします 。 -- `RUNNING_FAILED` : 変更フィードが失敗しました。何らかのエラーにより、変更フィードを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期限 (TTL) は 24 時間です。つまり、変更フィードが中断されてから 24 時間以内に GC メカニズムによってデータが削除されることはありません。 +- `RUNNING_FAILED` : 変更フィードが失敗しました。何らかのエラーにより、変更フィードを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期限 (TTL) は 24時間です。つまり、変更フィードが中断されてから 24時間以内に GC メカニズムによってデータが削除されることはありません。 diff --git a/tidb-cloud/explore-data-with-chat2query.md b/tidb-cloud/explore-data-with-chat2query.md index 68d659b5139d3..d05182162b338 100644 --- a/tidb-cloud/explore-data-with-chat2query.md +++ b/tidb-cloud/explore-data-with-chat2query.md @@ -93,7 +93,7 @@ SQLエディタでは、独自のデータセットを使用してSQLクエリ macOSの場合： - - エディタにクエリが 1 つしかない場合は、それを実行するには、 **⌘ + Enter**キーを押すか、クリックします。 **[実行]**。 + - エディタにクエリが 1つしかない場合は、それを実行するには、 **⌘ + Enter**キーを押すか、クリックします。 **[実行]**。 - エディタに複数のクエリがある場合、それらの1つまたは複数を順番に実行するには、カーソルで対象のクエリの行を選択し、 **⌘ + Enter キー**を押すか、 **[実行]**をクリックします。 @@ -105,7 +105,7 @@ SQLエディタでは、独自のデータセットを使用してSQLクエリ WindowsまたはLinuxの場合： - - エディターにクエリが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **[実行]**。 + - エディターにクエリが 1つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **[実行]**。 - エディターに複数のクエリがある場合、それらのクエリを1つまたは複数順番に実行するには、カーソルで対象のクエリの行を選択し、 **Ctrl + Enter**を押すか、 **[実行]**をクリックします。 @@ -149,8 +149,7 @@ SQLエディタでは、SQLクエリを複数のSQLファイルに保存し、 - SQLファイルを追加するには、 **SQLファイル**タブの**+**をクリックします。 - SQL ファイルの名前を変更するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックして、 **[名前の変更]**を選択します。 -- SQL ファイルを削除するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックしてから、 **削除**を選択します。なお、 **SQL Files**タブに SQL ファイルが 1 つしかない場合は、削除できません。 - +- SQL ファイルを削除するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックしてから、 **削除**を選択します。なお、 **SQL Files**タブに SQL ファイルが 1つしかない場合は、削除できません。 ## API経由でChat2Queryにアクセスする {#access-chat2query-via-api} Chat2QueryにはUI経由でアクセスできるだけでなく、API経由でもアクセスできます。そのためには、まずChat2Queryデータアプリを作成する必要があります。 diff --git a/tidb-cloud/high-availability-with-multi-az.md b/tidb-cloud/high-availability-with-multi-az.md index a45582eda0f77..d3049ab249c20 100644 --- a/tidb-cloud/high-availability-with-multi-az.md +++ b/tidb-cloud/high-availability-with-multi-az.md @@ -7,7 +7,7 @@ summary: TiDB Cloud Dedicated は、マルチ AZ デプロイメントによる TiDBはRaftコンセンサスアルゴリズムを使用し、 Raftグループ内のストレージ全体にデータの高可用性と安全なレプリケーションを実現します。データはストレージノード間で冗長コピーされ、異なるアベイラビリティゾーンに配置されるため、マシンやデータセンターの障害から保護されます。自動フェイルオーバー機能により、TiDBはサービスの常時稼働を保証します。 -TiDB Cloud Dedicated クラスタは、TiDB ノード、TiKV ノード、 TiFlashノードという 3 つの主要コンポーネントで構成されています。TiDB Cloud Dedicated の各コンポーネントの高可用性実装は次のとおりです。 +TiDB Cloud Dedicated クラスタは、TiDB ノード、TiKV ノード、 TiFlashノードという 3つの主要コンポーネントで構成されています。TiDB Cloud Dedicated の各コンポーネントの高可用性実装は次のとおりです。 - **TiDBノード** @@ -19,4 +19,4 @@ TiDB Cloud Dedicated クラスタは、TiDB ノード、TiKV ノード、 TiFlas - **TiFlashノード** - [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 、TiKV の列指向ストレージ拡張機能であり、TiDB を本質的にハイブリッドトランザクション/分析処理 (HTAP) データベースにする重要なコンポーネントです。TiFlash、列指向レプリカはRaft Learnerコンセンサスアルゴリズムに従って非同期的に複製されます。TiDB Cloud Dedicated は、 TiFlashノードをリージョン内の異なるアベイラビリティゾーンに均等にデプロイします。本番環境での高可用性を確保するため、各TiDB Cloud Dedicated クラスターに少なくとも 2 つのTiFlashノードを設定し、少なくとも 2 つのデータレプリカを作成本番ことをお勧めします。 + [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 、TiKV の列指向ストレージ拡張機能であり、TiDB を本質的にハイブリッドトランザクション/分析処理 (HTAP) データベースにする重要なコンポーネントです。TiFlash、列指向レプリカはRaft Learnerコンセンサスアルゴリズムに従って非同期的に複製されます。TiDB Cloud Dedicated は、 TiFlashノードをリージョン内の異なるアベイラビリティゾーンに均等にデプロイします。本番環境での高可用性を確保するため、各TiDB Cloud Dedicated クラスターに少なくとも 2つのTiFlashノードを設定し、少なくとも 2つのデータレプリカを作成本番ことをお勧めします。 diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index 73ca5dc879434..708ffbfe5425d 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -111,7 +111,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **Storage Provider**： **Amazon S3**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** ：AWSロールARNの値を入力してください。 @@ -164,7 +164,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **Storage Provider**： **Google Cloud Storage**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[gcs|gs]://sampledata/ingest/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[gcs|gs]://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 - **認証情報**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 @@ -215,7 +215,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **Storage Provider**： **Azure Blob Storage**を選択します。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[azure|https]://sampledata/ingest/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[azure|https]://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 @@ -266,7 +266,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `oss://sampledata/ingest/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `oss://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index a39f0be6b071f..e2290ddf4c53b 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -113,7 +113,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **Storage Provider**： **Amazon S3**を選択してください。 - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する]**をクリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得し、 IAMロールを手動で作成します。 @@ -168,7 +168,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **Storage Provider**： **Google Cloud Storage**を選択してください。 - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `gs://mybucket/myfolder/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `gs://mybucket/myfolder/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 - **Google Cloud サービス アカウント ID** : TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)を参照してください。 @@ -222,7 +222,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **Storage Provider**： **Azure Blob Storage**を選択します。 - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`の形式で入力してください。例： `https://myaccount.blob.core.windows.net/mycontainer/myfolder/` 。 - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 diff --git a/tidb-cloud/import-parquet-files-serverless.md b/tidb-cloud/import-parquet-files-serverless.md index a91a0f752a1ab..56d33e8cb77d8 100644 --- a/tidb-cloud/import-parquet-files-serverless.md +++ b/tidb-cloud/import-parquet-files-serverless.md @@ -115,7 +115,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **Storage Provider**： **Amazon S3**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://sampledata/ingest/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** ：AWSロールARNの値を入力してください。 @@ -168,7 +168,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **Storage Provider**： **Google Cloud Storage**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[gcs|gs]://sampledata/ingest/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[gcs|gs]://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 - **認証情報**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 @@ -219,7 +219,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **Storage Provider**： **Azure Blob Storage**を選択します。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[azure|https]://sampledata/ingest/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[azure|https]://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 @@ -270,7 +270,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index 2950564c06c98..bc2b48ce1f42e 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -118,7 +118,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **Storage Provider**： **Amazon S3**を選択してください。 - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する]**をクリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得し、 IAMロールを手動で作成します。 @@ -171,7 +171,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **Storage Provider**： **Google Cloud Storage**を選択してください。 - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `gs://mybucket/myfolder/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `gs://mybucket/myfolder/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 - **認証情報**: TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)を参照してください。 @@ -223,7 +223,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **Storage Provider**： **Azure Blob Storage**を選択します。 - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.parquet` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`の形式で入力してください。例： `https://myaccount.blob.core.windows.net/mycontainer/myfolder/` 。 - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 diff --git a/tidb-cloud/import-sample-data-serverless.md b/tidb-cloud/import-sample-data-serverless.md index f8c4d8bc4ea26..31d94dcb5f0e4 100644 --- a/tidb-cloud/import-sample-data-serverless.md +++ b/tidb-cloud/import-sample-data-serverless.md @@ -5,7 +5,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud EssentialにUI経由でサンプ # クラウドストレージからサンプルデータ（SQLファイル）をTiDB Cloud StarterまたはEssentialにインポートする {#import-sample-data-sql-files-into-tidb-cloud-starter-or-essential-from-cloud-storage} -このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud StarterまたはTiDB Cloud Essentialにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、 TiDB Cloud StarterまたはEssential のインスタンスが 1 つ必要です。 +このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud StarterまたはTiDB Cloud Essentialにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、 TiDB Cloud StarterまたはEssential のインスタンスが 1つ必要です。 > **Note:** > diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index 72c796d150578..88851ea0b2854 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -5,7 +5,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー # クラウドストレージからサンプルデータ（SQLファイル）をTiDB Cloud Dedicatedにインポートする {#import-sample-data-sql-files-from-cloud-storage-into-tidb-cloud-dedicated} -このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud Dedicatedにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、TiDB クラスタが 1 つ必要です。 +このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud Dedicatedにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、TiDB クラスタが 1つ必要です。
    diff --git a/tidb-cloud/integrate-tidbcloud-with-dbt.md b/tidb-cloud/integrate-tidbcloud-with-dbt.md index a5c55f0738ca0..e3a51d0a10902 100644 --- a/tidb-cloud/integrate-tidbcloud-with-dbt.md +++ b/tidb-cloud/integrate-tidbcloud-with-dbt.md @@ -174,7 +174,7 @@ cd jaffle_shop 2. TiDB Cloudで結果を確認してください。 - `show databases`コマンドは、dbt が作成した新しい`analytics`データベースを一覧表示します。 `show tables`コマンドは、 `analytics`データベースに、作成したテーブルに対応する 3 つのテーブルが存在することを示します。 + `show databases`コマンドは、dbt が作成した新しい`analytics`データベースを一覧表示します。 `show tables`コマンドは、 `analytics`データベースに、作成したテーブルに対応する 3つのテーブルが存在することを示します。 ```sql mysql> SHOW DATABASES; @@ -256,7 +256,7 @@ cd jaffle_shop Done. PASS=5 WARN=0 ERROR=0 SKIP=0 TOTAL=5 ``` - 結果によると、2 つのテーブル ( `analytics.customers`と`analytics.orders` ) と 3 つのビュー ( `analytics.stg_customers` 、 `analytics.stg_orders` 、および`analytics.stg_payments` ) が正常に作成されました。 + 結果によると、2つのテーブル ( `analytics.customers`と`analytics.orders` ) と 3つのビュー ( `analytics.stg_customers` 、 `analytics.stg_orders` 、および`analytics.stg_payments` ) が正常に作成されました。 2. TiDB Cloudにアクセスして、変換が成功したことを確認してください。 diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index c681cf4feb6b8..2954375aba301 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -224,7 +224,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ ### サポート対象のオペレーション {#supported-operations} -TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/#regular-nodes)として機能し、次の 5 つの操作のみをサポートします。 +TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/#regular-nodes)として機能し、次の5つの操作のみをサポートします。 - **Create Serverless Cluster**: TiDB Cloud Starterインスタンスを作成します。 - **Execute SQL**：TiDBでSQL文を実行します。 diff --git a/tidb-cloud/integrate-tidbcloud-with-vercel.md b/tidb-cloud/integrate-tidbcloud-with-vercel.md index c627bbcab2b2e..c2f3905db83c0 100644 --- a/tidb-cloud/integrate-tidbcloud-with-vercel.md +++ b/tidb-cloud/integrate-tidbcloud-with-vercel.md @@ -213,7 +213,7 @@ Gitリポジトリに変更をプッシュすると、Vercelがプレビュー > **Note:** > -> TiDB Cloudの各組織では、デフォルトではTiDB Cloud Starterインスタンス用に最大 5 つのブランチを作成できます。制限を超えないようにするには、不要になったTiDB Cloud Starterインスタンスのブランチを削除してください。詳細については、 [TiDB Cloudブランチを管理する](/tidb-cloud/branch-manage.md)を参照してください。 . +> TiDB Cloudの各組織では、デフォルトではTiDB Cloud Starterインスタンス用に最大 5つのブランチを作成できます。制限を超えないようにするには、不要になったTiDB Cloud Starterインスタンスのブランチを削除してください。詳細については、 [TiDB Cloudブランチを管理する](/tidb-cloud/branch-manage.md)を参照してください。 . ## 環境変数を手動で設定して接続します {#connect-via-manually-setting-environment-variables} diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index b855ad0ddfbb0..126117956c90a 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -199,13 +199,13 @@ TiDB Cloudのトリガーは、多数の結果を返すポーリングAPI呼び API 内のアイテムが複数の異なるポーリングに存在する場合にアクションが複数回トリガーされないようにするため、 TiDB Cloudトリガーは`id`フィールドを使用してデータの重複を排除します。 -`New Cluster`および`New Table`トリガーは、 `cluster_id`または`table_id`を`id`フィールドとして使用して重複排除を行います。この 2 つのトリガーについては、何もする必要はありません。 +`New Cluster`および`New Table`トリガーは、 `cluster_id`または`table_id`を`id`フィールドとして使用して重複排除を行います。この2つのトリガーについては、何もする必要はありません。 **新しい行のトリガー** `New Row`トリガーは、フェッチごとに10,000件の結果を制限します。そのため、新しい行が10,000件の結果に含まれていない場合、Zapierはトリガーされません。 -これを回避する方法の一つは、トリガーで`Order By`設定を指定することです。例えば、行を生成時刻でソートすると、新しい行は常に 10,000 件の結果に含まれるようになります。 +これを回避する方法の一つは、トリガーで`Order By`設定を指定することです。例えば、行を生成時刻でソートすると、新しい行は常に 10,000件の結果に含まれるようになります。 `New Row`トリガーは、重複排除を行う`id`フィールドを生成するために、柔軟な戦略も使用します。トリガーは`id`フィールドを次の順序で生成します。 @@ -217,7 +217,7 @@ API 内のアイテムが複数の異なるポーリングに存在する場合 **新規行（カスタムクエリ）トリガー** -`New Row (Custom Query)`トリガーは、フェッチごとに 1,000,000 件の結果を制限します。1,000,000 は大きな数値であり、システム全体を保護するためにのみ設定されています。クエリには`ORDER BY`と`LIMIT`を含めることをお勧めします。 +`New Row (Custom Query)`トリガーは、フェッチごとに 1,000,000件の結果を制限します。1,000,000 は大きな数値であり、システム全体を保護するためにのみ設定されています。クエリには`ORDER BY`と`LIMIT`を含めることをお勧めします。 重複排除を実行するには、クエリ結果に一意のIDフィールドが必要です。そうでない場合、 `You must return the results with id field`エラーが発生します。 diff --git a/tidb-cloud/limited-sql-features-tidb-x.md b/tidb-cloud/limited-sql-features-tidb-x.md index 87578ff494945..397f999f42558 100644 --- a/tidb-cloud/limited-sql-features-tidb-x.md +++ b/tidb-cloud/limited-sql-features-tidb-x.md @@ -93,7 +93,7 @@ TiDB Cloud は TiDB がサポートするほぼすべてのワークロードに | 関数と演算子 | {{{ .premium }}} | {{{ .starter }}} and {{{ .essential }}} | |:-|:-|:-| -| `SLEEP` | 制限はありません | [`SLEEP()` function](https://docs.pingcap.com/tidbcloud/miscellaneous-functions) 関数は、最大 300 秒のスリープ時間をサポートします。 | +| `SLEEP` | 制限はありません | [`SLEEP()` function](https://docs.pingcap.com/tidbcloud/miscellaneous-functions) 関数は、最大 300秒のスリープ時間をサポートします。 | ## システムテーブル {#system-tables} @@ -365,4 +365,4 @@ TiDB Cloud は TiDB がサポートするほぼすべてのワークロードに [^10]: この変数は {{{ .starter }}} と {{{ .essential }}} では読み取り専用です。 -[^11]: {{{ .starter }}} と {{{ .essential }}} では、[example](https://docs.pingcap.com/tidb/stable/sql-plan-replayer#examples-of-exporting-cluster-information) に示されているように、`${tidb-server-status-port}` を介して `PLAN REPLAYER` がエクスポートしたファイルをダウンロードすることはサポートされていません。代わりに、{{{ .starter }}} と {{{ .essential }}} では、ファイルをダウンロードするための [presigned URL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) が生成されます。この URL は生成後 10 時間有効です。 \ No newline at end of file +[^11]: {{{ .starter }}} と {{{ .essential }}} では、[example](https://docs.pingcap.com/tidb/stable/sql-plan-replayer#examples-of-exporting-cluster-information) に示されているように、`${tidb-server-status-port}` を介して `PLAN REPLAYER` がエクスポートしたファイルをダウンロードすることはサポートされていません。代わりに、{{{ .starter }}} と {{{ .essential }}} では、ファイルをダウンロードするための [presigned URL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) が生成されます。この URL は生成後 10時間有効です。 \ No newline at end of file diff --git a/tidb-cloud/manage-serverless-spend-limit.md b/tidb-cloud/manage-serverless-spend-limit.md index bde2898af22af..2855f77608d17 100644 --- a/tidb-cloud/manage-serverless-spend-limit.md +++ b/tidb-cloud/manage-serverless-spend-limit.md @@ -11,11 +11,11 @@ summary: TiDB Cloud Starterインスタンスの利用限度額を管理する 支出制限とは、特定のワークロードに対して1か月間に支出できる最大金額のことです。これは、TiDB Cloud Starterインスタンスの予算を設定できるコスト管理メカニズムです。 -TiDB Cloudの各組織につき、最大 5 つの [無料のTiDB Cloud Starterインスタンス](/tidb-cloud/select-cluster-tier.md#starter)デフォルトで作成できます。TiDB Cloud Starterインスタンスをさらに作成するには、クレジットカードを追加し、月間利用限度額を設定する必要があります。ただし、新しいインスタンスを作成する前に以前のTiDB Cloud Starterインスタンスを削除した場合、新しいTiDB Cloud Starterインスタンスはクレジットカードなしで作成できます。 +TiDB Cloudの各組織につき、最大 5つの [無料のTiDB Cloud Starterインスタンス](/tidb-cloud/select-cluster-tier.md#starter)デフォルトで作成できます。TiDB Cloud Starterインスタンスをさらに作成するには、クレジットカードを追加し、月間利用限度額を設定する必要があります。ただし、新しいインスタンスを作成する前に以前のTiDB Cloud Starterインスタンスを削除した場合、新しいTiDB Cloud Starterインスタンスはクレジットカードなしで作成できます。 ## 使用クォータ {#usage-quota} -組織内の最初の 5 つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 +組織内の最初の 5つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 - 行ベースストレージ：5 GiB - カラム型ストレージ：5 GiB diff --git a/tidb-cloud/manage-user-access.md b/tidb-cloud/manage-user-access.md index 82b5c1f495840..a9fcc61f41782 100644 --- a/tidb-cloud/manage-user-access.md +++ b/tidb-cloud/manage-user-access.md @@ -99,7 +99,7 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル ### 組織における役割 {#organization-roles} -組織レベルでは、 TiDB Cloud は5 つの役割を定義しており、 `Organization Owner`はメンバーを招待したり、メンバーに組織の役割を付与したりできます。 +組織レベルでは、 TiDB Cloud は5つの役割を定義しており、 `Organization Owner`はメンバーを招待したり、メンバーに組織の役割を付与したりできます。 | 許可 | `Organization Owner` | `Organization Billing Manager` | `Organization Billing Viewer` | `Organization Console Audit Manager` | `Organization Viewer` | | ------------------------------------------------------------------------------------------------ | -------------------- | ------------------------------ | ----------------------------- | ------------------------------------ | --------------------- | @@ -119,7 +119,7 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル ### プロジェクトの役割 {#project-roles} -プロジェクトレベルでは、 TiDB Cloud は4 つの役割を定義しており、 `Project Owner`はメンバーを招待したり、メンバーにプロジェクトの役割を付与したりできます。 +プロジェクトレベルでは、 TiDB Cloud は4つの役割を定義しており、 `Project Owner`はメンバーを招待したり、メンバーにプロジェクトの役割を付与したりできます。 > **Note:** > diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 4a2d410deb0c3..52e0cfd2140f7 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -121,12 +121,11 @@ Alibaba Cloud RDSをデータソースとして使用する場合、すべての - 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**再開**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Essentialインスタンス内の競合レコードをMySQLソースレコードに置き換えます。 -- 増分データ移行 (進行中の変更をTiDB Cloud Essentialインスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Essentialインスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Essentialインスタンスで重複した行が発生する可能性があります。 - +- 増分データ移行 (進行中の変更をTiDB Cloud Essentialインスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Essentialインスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Essentialインスタンスで重複した行が発生する可能性があります。 -- 増分データ移行 (進行中の変更をTiDB Cloud Dedicatedクラスターに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Dedicatedクラスターに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Dedicated Dedicated クラスターで重複した行が発生する可能性があります。 +- 増分データ移行 (進行中の変更をTiDB Cloud Dedicatedクラスターに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Dedicatedクラスターに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Dedicated Dedicated クラスターで重複した行が発生する可能性があります。 - 以下のシナリオでは、移行ジョブに24時間以上かかる場合、ソースデータベースのバイナリログを削除しないでください。これにより、データ移行ツールは増分データ移行のために連続したバイナリログを取得できます。 @@ -137,7 +136,7 @@ Alibaba Cloud RDSをデータソースとして使用する場合、すべての -- 増分データ移行 (進行中の変更をTiDB Cloud Premium インスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Premium インスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Premium インスタンスで重複した行が発生する可能性があります。 +- 増分データ移行 (進行中の変更をTiDB Cloud Premium インスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Premium インスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Premium インスタンスで重複した行が発生する可能性があります。 diff --git a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md index bffb97ba66563..1a5e34c054f8f 100644 --- a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md @@ -48,7 +48,7 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa - ソースデータベースでGTIDモードが有効になっていることを確認してください。 - ソースデータベースがMySQLの場合、MySQLのバージョンは5.6以降である必要があり、ストレージエンジンはInnoDBである必要があります。 -- 移行ジョブがアップストリームのセカンダリデータベースに接続する場合、 `REPLICATE CREATE TABLE ... SELECT`イベントは移行できません。これは、ステートメントが同じ GTID が割り当てられた 2 つのトランザクション ( `CREATE TABLE`と`INSERT` ) に分割されるためです。その結果、 `INSERT`ステートメントはセカンダリデータベースによって無視されます。 +- 移行ジョブがアップストリームのセカンダリデータベースに接続する場合、 `REPLICATE CREATE TABLE ... SELECT`イベントは移行できません。これは、ステートメントが同じ GTID が割り当てられた 2つのトランザクション ( `CREATE TABLE`と`INSERT` ) に分割されるためです。その結果、 `INSERT`ステートメントはセカンダリデータベースによって無視されます。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/migrate-prometheus-metrics-integrations.md b/tidb-cloud/migrate-prometheus-metrics-integrations.md index 39288d12eb939..bc6d8944da3c4 100644 --- a/tidb-cloud/migrate-prometheus-metrics-integrations.md +++ b/tidb-cloud/migrate-prometheus-metrics-integrations.md @@ -5,7 +5,7 @@ summary: 従来のプロジェクトレベルのPrometheus統合から、新し # Prometheus統合の移行 {#migrate-prometheus-integrations} -TiDB Cloud は、 [Prometheusとの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)クラスタレベルで管理するようになり、よりきめ細かな制御と構成が可能になりました。従来のプロジェクトレベルの Prometheus 統合 (ベータ版) は、2026 年 1 月 9 日に廃止されました。組織でこれらの従来の統合をまだ使用している場合は、このガイドに従って新しいクラスタレベルの Prometheus 統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +TiDB Cloud は、 [Prometheusとの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)クラスタレベルで管理するようになり、よりきめ細かな制御と構成が可能になりました。従来のプロジェクトレベルの Prometheus 統合 (ベータ版) は、2026年 1月 9日に廃止されました。組織でこれらの従来の統合をまだ使用している場合は、このガイドに従って新しいクラスタレベルの Prometheus 統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md index da1f8272073c3..f475de7fa7cee 100644 --- a/tidb-cloud/migrate-sql-shards.md +++ b/tidb-cloud/migrate-sql-shards.md @@ -61,7 +61,7 @@ Amazon S3 バケット内に、第 1 階層ディレクトリ`store` (データ - MySQLインスタンス1のデータを`s3://dumpling-s3/store/sales/instance01/`に移行します。 - MySQLインスタンス2のデータを`s3://dumpling-s3/store/sales/instance02/`に移行します。 -複数のインスタンスにシャードがある場合は、データベースごとに第 1 レベルのディレクトリを 1 つ作成し、シャーディングされたテーブルごとに第 2 レベルのディレクトリを 1 つ作成します。次に、管理を容易にするために、MySQL インスタンスごとに第 3 レベルのディレクトリを作成します。たとえば、MySQL インスタンス 1 と MySQL インスタンス 2 のテーブル`stock_N.product_N`をTiDB Cloudのテーブル`stock.products`に移行およびマージする場合は、次のディレクトリを作成できます。 +複数のインスタンスにシャードがある場合は、データベースごとに第 1 レベルのディレクトリを 1つ作成し、シャーディングされたテーブルごとに第 2 レベルのディレクトリを 1つ作成します。次に、管理を容易にするために、MySQL インスタンスごとに第 3 レベルのディレクトリを作成します。たとえば、MySQL インスタンス 1 と MySQL インスタンス 2 のテーブル`stock_N.product_N`をTiDB Cloudのテーブル`stock.products`に移行およびマージする場合は、次のディレクトリを作成できます。 - `s3://dumpling-s3/stock/products/instance01/` - `s3://dumpling-s3/stock/products/instance02/` diff --git a/tidb-cloud/monitor-alert-lark.md b/tidb-cloud/monitor-alert-lark.md index bd54717a6399d..d63582bb0eb36 100644 --- a/tidb-cloud/monitor-alert-lark.md +++ b/tidb-cloud/monitor-alert-lark.md @@ -39,7 +39,7 @@ TiDB Cloud では、Lark、[email](/tidb-cloud/monitor-alert-email.md)、[Slack] > **Tip:** > -> {{{ .dedicated }}} では、アラートの購読は現在のプロジェクト内のすべてのアラートに対して適用されます。プロジェクト内に複数の {{{ .dedicated }}} クラスターがある場合でも、購読は 1 回だけで済みます。 +> {{{ .dedicated }}} では、アラートの購読は現在のプロジェクト内のすべてのアラートに対して適用されます。プロジェクト内に複数の {{{ .dedicated }}} クラスターがある場合でも、購読は 1回だけで済みます。 1. [TiDB Cloud console](https://tidbcloud.com) で、組織の [**My TiDB**](https://tidbcloud.com/tidbs) ページに移動し、**Project view** タブをクリックします。 2. プロジェクトビューで対象のプロジェクトを見つけ、プロジェクトの をクリックします。 @@ -93,7 +93,7 @@ TiDB Cloud では、Lark、[email](/tidb-cloud/monitor-alert-email.md)、[Slack] -アラート条件が変わらない場合、アラートは 3 時間ごとに通知を送信します。 +アラート条件が変わらない場合、アラートは 3時間ごとに通知を送信します。 ## アラート通知の購読を解除する {#unsubscribe-from-alert-notifications} diff --git a/tidb-cloud/monitor-alert-webhook.md b/tidb-cloud/monitor-alert-webhook.md index 4ce4519430f6a..e30c66187b210 100644 --- a/tidb-cloud/monitor-alert-webhook.md +++ b/tidb-cloud/monitor-alert-webhook.md @@ -93,7 +93,7 @@ TiDB Cloud では、[汎用webhook](/tidb-cloud/monitor-alert-webhook.md)、[ema -アラート条件が変わらない場合、アラートは 3 時間ごとに通知を送信します。 +アラート条件が変わらない場合、アラートは 3時間ごとに通知を送信します。 ## アラート通知の購読を解除する {#unsubscribe-from-alert-notifications} diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index cefd2de530ca6..c4e3864b2eb69 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -117,7 +117,7 @@ TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md) | データ移行ジョブでデータエクスポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | | データ移行ジョブのデータインポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | | データ移行ジョブで増分移行中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | -| データ移行ジョブが増分移行中に6時間以上一時停止しています | データの増分移行中に、データ移行ジョブが 6 時間以上一時停止されました。アップストリーム データベースのbinlogがパージされる可能性があり (データベースのbinlogパージ戦略によって異なります)、増分移行が失敗する可能性があります。ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | +| データ移行ジョブが増分移行中に6時間以上一時停止しています | データの増分移行中に、データ移行ジョブが 6時間以上一時停止されました。アップストリーム データベースのbinlogがパージされる可能性があり (データベースのbinlogパージ戦略によって異なります)、増分移行が失敗する可能性があります。ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | | レプリケーション遅延は10分を超え、20分以上経過しても増加し続けている。 | ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | ### TiDB Cloud Dedicatedの変更フィードアラート {#changefeed-alerts-for-tidb-cloud-dedicated} diff --git a/tidb-cloud/monitor-datadog-integration-for-tidb-x.md b/tidb-cloud/monitor-datadog-integration-for-tidb-x.md index c06ad852f38b2..0265db6fb16e2 100644 --- a/tidb-cloud/monitor-datadog-integration-for-tidb-x.md +++ b/tidb-cloud/monitor-datadog-integration-for-tidb-x.md @@ -30,8 +30,8 @@ TiDB Cloud は Datadog との統合をサポートしています。TiDB Cloud - - 2026 年 7 月 1 日以降に作成された TiDB Cloud Essential インスタンスの場合は、この JSON ファイルをダウンロードします: 。`v2` サフィックスは、ダッシュボード JSON ファイルのバージョンのみを示すことに注意してください。 - - 2026 年 7 月 1 日より前に作成された TiDB Cloud Essential インスタンスの場合は、この JSON ファイルをダウンロードします: 。 + - 2026年 7月 1日以降に作成された TiDB Cloud Essential インスタンスの場合は、この JSON ファイルをダウンロードします: 。`v2` サフィックスは、ダッシュボード JSON ファイルのバージョンのみを示すことに注意してください。 + - 2026年 7月 1日より前に作成された TiDB Cloud Essential インスタンスの場合は、この JSON ファイルをダウンロードします: 。 @@ -102,13 +102,13 @@ Datadog は、{{{ .essential }}} | `tidb_cloud.db_total_connection` | gauge | `instance_id: `
    `instance_name: ` | TiDB server における現在の接続数 | | `tidb_cloud.db_active_connections` | gauge | `instance_id: `
    `instance_name: ` | アクティブな接続数 | | `tidb_cloud.db_disconnections` | gauge | `result: Error\|...`
    `instance_id: `
    `instance_name: ` | 接続結果ごとに切断されたクライアント数 | -| `tidb_cloud.db_database_time` | gauge | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | TiDB で実行中のすべての SQL 文が 1 秒あたりに消費した合計時間。すべてのプロセスの CPU 時間と、アイドル状態ではない待機時間を含みます | -| `tidb_cloud.db_query_per_second` | gauge | `type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | 文の種類ごとに集計された、1 秒あたりに実行された SQL 文の数 | -| `tidb_cloud.db_failed_queries` | gauge | `type: planner:xxx\|executor:2345\|...`
    `instance_id: `
    `instance_name: ` | SQL 文の実行時に 1 秒あたりに発生したエラー種別（構文エラーや主キー競合など）の統計 | -| `tidb_cloud.db_command_per_second` | gauge | `type: Query\|Ping\|...`
    `instance_id: `
    `instance_name: ` | TiDB が 1 秒あたりに処理したコマンド数 | -| `tidb_cloud.db_queries_using_plan_cache_ops` | gauge | `instance_id: `
    `instance_name: ` | 1 秒あたりに実行計画キャッシュにヒットしたクエリ数 | +| `tidb_cloud.db_database_time` | gauge | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | TiDB で実行中のすべての SQL 文が 1秒あたりに消費した合計時間。すべてのプロセスの CPU 時間と、アイドル状態ではない待機時間を含みます | +| `tidb_cloud.db_query_per_second` | gauge | `type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | 文の種類ごとに集計された、1秒あたりに実行された SQL 文の数 | +| `tidb_cloud.db_failed_queries` | gauge | `type: planner:xxx\|executor:2345\|...`
    `instance_id: `
    `instance_name: ` | SQL 文の実行時に 1秒あたりに発生したエラー種別（構文エラーや主キー競合など）の統計 | +| `tidb_cloud.db_command_per_second` | gauge | `type: Query\|Ping\|...`
    `instance_id: `
    `instance_name: ` | TiDB が 1秒あたりに処理したコマンド数 | +| `tidb_cloud.db_queries_using_plan_cache_ops` | gauge | `instance_id: `
    `instance_name: ` | 1秒あたりに実行計画キャッシュにヒットしたクエリ数 | | `tidb_cloud.db_average_query_duration` | gauge | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | ネットワークリクエストが TiDB に送信されてから、レスポンスがクライアントに返されるまでの時間 | -| `tidb_cloud.db_transaction_per_second` | gauge | `type: Commit\|Rollback\|...`
    `txn_mode: optimistic\|pessimistic`
    `instance_id: `
    `instance_name: ` | 1 秒あたりに実行されたトランザクション数 | +| `tidb_cloud.db_transaction_per_second` | gauge | `type: Commit\|Rollback\|...`
    `txn_mode: optimistic\|pessimistic`
    `instance_id: `
    `instance_name: ` | 1秒あたりに実行されたトランザクション数 | | `tidb_cloud.db_row_storage_used_bytes` | gauge | `instance_id: `
    `instance_name: ` | {{{ .essential }}} インスタンスの行ベースストレージサイズ（バイト） | | `tidb_cloud.db_columnar_storage_used_bytes` | gauge | `instance_id: `
    `instance_name: ` | {{{ .essential }}} インスタンスのカラムナー ストレージサイズ（バイト）。TiFlash が有効でない場合は 0 を返します | | `tidb_cloud.resource_manager_resource_request_unit_total` | gauge | `instance_id: `
    `instance_name: ` | 消費された合計 Request Units/s (RU/s) | @@ -122,13 +122,13 @@ Datadog は、{{{ .essential }}} | `tidb_cloud.db_total_connection` | gauge | `instance_id: `
    `instance_name: ` | TiDB server における現在の接続数 | | `tidb_cloud.db_active_connections` | gauge | `instance_id: `
    `instance_name: ` | アクティブな接続数 | | `tidb_cloud.db_disconnections` | gauge | `result: Error\|...`
    `instance_id: `
    `instance_name: ` | 接続結果ごとに切断されたクライアント数 | -| `tidb_cloud.db_database_time` | gauge | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | TiDB で実行中のすべての SQL 文が 1 秒あたりに消費した合計時間。すべてのプロセスの CPU 時間と、アイドル状態ではない待機時間を含みます | -| `tidb_cloud.db_query_per_second` | gauge | `type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | 文の種類ごとに集計された、1 秒あたりに実行された SQL 文の数 | -| `tidb_cloud.db_failed_queries` | gauge | `type: planner:xxx\|executor:2345\|...`
    `instance_id: `
    `instance_name: ` | SQL 文の実行時に 1 秒あたりに発生したエラー種別（構文エラーや主キー競合など）の統計 | -| `tidb_cloud.db_command_per_second` | gauge | `type: Query\|Ping\|...`
    `instance_id: `
    `instance_name: ` | TiDB が 1 秒あたりに処理したコマンド数 | -| `tidb_cloud.db_queries_using_plan_cache_ops` | gauge | `instance_id: `
    `instance_name: ` | 1 秒あたりに実行計画キャッシュにヒットしたクエリ数 | +| `tidb_cloud.db_database_time` | gauge | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | TiDB で実行中のすべての SQL 文が 1秒あたりに消費した合計時間。すべてのプロセスの CPU 時間と、アイドル状態ではない待機時間を含みます | +| `tidb_cloud.db_query_per_second` | gauge | `type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | 文の種類ごとに集計された、1秒あたりに実行された SQL 文の数 | +| `tidb_cloud.db_failed_queries` | gauge | `type: planner:xxx\|executor:2345\|...`
    `instance_id: `
    `instance_name: ` | SQL 文の実行時に 1秒あたりに発生したエラー種別（構文エラーや主キー競合など）の統計 | +| `tidb_cloud.db_command_per_second` | gauge | `type: Query\|Ping\|...`
    `instance_id: `
    `instance_name: ` | TiDB が 1秒あたりに処理したコマンド数 | +| `tidb_cloud.db_queries_using_plan_cache_ops` | gauge | `instance_id: `
    `instance_name: ` | 1秒あたりに実行計画キャッシュにヒットしたクエリ数 | | `tidb_cloud.db_average_query_duration` | gauge | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | ネットワークリクエストが TiDB に送信されてから、レスポンスがクライアントに返されるまでの時間 | -| `tidb_cloud.db_transaction_per_second` | gauge | `type: Commit\|Rollback\|...`
    `txn_mode: optimistic\|pessimistic`
    `instance_id: `
    `instance_name: ` | 1 秒あたりに実行されたトランザクション数 | +| `tidb_cloud.db_transaction_per_second` | gauge | `type: Commit\|Rollback\|...`
    `txn_mode: optimistic\|pessimistic`
    `instance_id: `
    `instance_name: ` | 1秒あたりに実行されたトランザクション数 | | `tidb_cloud.db_row_storage_used_bytes` | gauge | `instance_id: `
    `instance_name: ` | {{{ .premium }}} インスタンスの行ベースストレージサイズ（バイト） | | `tidb_cloud.db_columnar_storage_used_bytes` | gauge | `instance_id: `
    `instance_name: ` | {{{ .premium }}} インスタンスのカラムナー ストレージサイズ（バイト） | | `tidb_cloud.resource_manager_resource_request_unit_total` | gauge | `instance_id: `
    `instance_name: ` | 消費された合計 Request Units/s (RU/s) | diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index 5111edbce98d2..1c0c42ee1b9d2 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -20,7 +20,7 @@ TiDB CloudはDatadogとの連携をサポートしています。TiDB Cloudを TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合（ベータ版）をサポートしてきました。2025年7月31日より、TiDB CloudレベルのDatadog統合（PREVIEW）を導入します。2025年9月30日より、クラスターレベルのDatadog統合が一般提供（GA）となります。 - **クラスタレベルのDatadog統合**：2025年7月31日までに組織内に削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのDatadog統合を提供します。 -- **従来のプロジェクトレベルの Datadog 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloudは、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの Datadog 統合は、2025 年 10 月 31 日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +- **従来のプロジェクトレベルの Datadog 統合 (ベータ版)** : 2025年 7月 31日時点で組織内に少なくとも 1つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloudは、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの Datadog 統合は、2025年 10月 31日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} @@ -113,14 +113,14 @@ Datadogは、TiDBクラスタに関して以下のメトリクスを追跡しま | メトリック名 | メトリックタイプ | ラベル | 説明 | | :----------------------------------------- | :------- | :---------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tidb_cloud.db_database_time | ゲージ | sql_type: Select|Insert|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | TiDBで実行されているすべてのSQLステートメントが1秒あたりに消費する合計時間。これには、すべてのプロセスのCPU時間と、アイドル状態ではない待機時間が含まれます。 | -| tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | すべての TiDB ノードで 1 秒あたりに実行される SQL ステートメントの数。ステートメントの種類 ( `SELECT` 、 `INSERT` 、または`UPDATE` ) ごとにカウントされます。 | +| tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | すべての TiDB ノードで 1秒あたりに実行される SQL ステートメントの数。ステートメントの種類 ( `SELECT` 、 `INSERT` 、または`UPDATE` ) ごとにカウントされます。 | | tidb_cloud.db_average_query_duration | ゲージ | sql_type: Select|Insert|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | クライアントのネットワーク要求がTiDBに送信されてから、TiDBが要求を実行した後、クライアントに要求が返されるまでの時間。 | | tidb_cloud.db_failed_queries | ゲージ | タイプ: 実行者:xxxx|パーサー:xxxx|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | 各TiDBノードで1秒あたりに発生するSQL実行エラーに基づいた、エラーの種類（構文エラーや主キーの競合など）の統計情報。 | | tidb_cloud.db_total_connection | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | TiDBサーバーにおける現在の接続数。 | | tidb_cloud.db_active_connections | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | アクティブな接続数。 | | tidb_cloud.db_disconnections | ゲージ | 結果：OK｜エラー｜不明
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | 接続が切断されたクライアントの数。 | | tidb_cloud.db_command_per_second | ゲージ | タイプ: クエリ|ステートメント準備|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | TiDBが1秒間に処理するコマンド数。コマンド実行結果の成否に応じて分類されます。 | -| tidb_cloud.db_queries_using_plan_cache_ops | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | [プランキャッシュ](/sql-prepared-plan-cache.md)を使用したクエリの 1 秒あたりの統計。実行計画 キャッシュは、プリペアドステートメントコマンドのみをサポートします。 | +| tidb_cloud.db_queries_using_plan_cache_ops | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | [プランキャッシュ](/sql-prepared-plan-cache.md)を使用したクエリの 1秒あたりの統計。実行計画 キャッシュは、プリペアドステートメントコマンドのみをサポートします。 | | tidb_cloud.db_transaction_per_second | ゲージ | txn_mode:悲観的|楽観的
    タイプ: 中止|コミット|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | 1秒あたりに実行されるトランザクション数。 | | tidb_cloud.node_storage_used_bytes | ゲージ | クラスター名: ``
    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…
    コンポーネント: tikv|tiflash | TiKV またはTiFlashノードのディスク使用量（バイト単位）。このメトリックは主にストレージエンジンの論理データ サイズを表し、WAL ファイルと一時ファイルは除外されます。実際のディスク使用率を計算するには、代わりに`(capacity - available) / capacity`を使用してください。TiKV のストレージ使用率が 80% を超えると、レイテンシーの急増が発生する可能性があり、使用率が高くなるとリクエストが失敗する可能性があります。すべてのTiFlashノードのストレージ使用率が 80% に達すると、 TiFlashレプリカを追加する DDL ステートメントは無期限にハングします。 | | tidb_cloud.node_storage_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…
    コンポーネント: tikv|tiflash | TiKV/ TiFlashノードのディスク容量（バイト単位）。 | diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index a66aaec3b8283..637db8b1d4fca 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -12,7 +12,7 @@ TiDB CloudはNew Relicとの連携をサポートしています。TiDB Cloudを TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統合（ベータ版）をサポートしてきました。2025年7月31日より、TiDB CloudレベルのNew Relic統合（PREVIEW）を導入します。2025年9月30日より、クラスターレベルのNew Relic統合が一般提供（GA）となります。 - **クラスタレベルのNew Relic統合**：2025年7月31日までに組織内で削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのNew Relic統合を提供します。 -- **従来のプロジェクトレベルの New Relic 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの New Relic 統合は、2025 年 10 月 31 日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +- **従来のプロジェクトレベルの New Relic 統合 (ベータ版)** : 2025年 7月 31日時点で組織内に少なくとも 1つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの New Relic 統合は、2025年 10月 31日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} @@ -147,14 +147,14 @@ New Relicは、TiDBクラスタに関して以下のメトリクスを追跡し | メトリック名 | メトリックタイプ | ラベル | 説明 | | :----------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tidb_cloud.db_database_time | ゲージ | sql_type: Select|Insert|...

    クラスター名: ``

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

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

    クラスター名: ``

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

    コンポーネント: `tidb` | すべての TiDB ノードで 1 秒あたりに実行される SQL ステートメントの数。これは`SELECT` 、 `INSERT` 、 `UPDATE` 、およびその他のタイプのステートメントに従ってカウントされます。 | +| tidb_cloud.db_query_per_second | ゲージ | タイプ: 選択|挿入|...

    クラスター名: ``

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

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

    クラスター名: ``

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

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

    クラスター名: ``

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

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

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

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

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

    コンポーネント: `tidb` | アクティブな接続数。 | | tidb_cloud.db_disconnections | ゲージ | 結果：OK｜エラー｜不明

    クラスター名: ``

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

    コンポーネント: `tidb` | 接続が切断されたクライアントの数。 | | tidb_cloud.db_command_per_second | ゲージ | タイプ: クエリ|ステートメント準備|...

    クラスター名: ``

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

    コンポーネント: `tidb` | TiDBが1秒間に処理するコマンド数。コマンド実行結果の成否に応じて分類されます。 | -| tidb_cloud.db_queries_using_plan_cache_ops | ゲージ | クラスター名: ``

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

    コンポーネント: `tidb` | [プランキャッシュ](/sql-prepared-plan-cache.md)を使用したクエリの 1 秒あたりの統計。実行計画 キャッシュは、プリペアドステートメントコマンドのみをサポートします。 | +| tidb_cloud.db_queries_using_plan_cache_ops | ゲージ | クラスター名: ``

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

    コンポーネント: `tidb` | [プランキャッシュ](/sql-prepared-plan-cache.md)を使用したクエリの 1秒あたりの統計。実行計画 キャッシュは、プリペアドステートメントコマンドのみをサポートします。 | | tidb_cloud.db_transaction_per_second | ゲージ | txn_mode:悲観的|楽観的

    タイプ: 中止|コミット|...

    クラスター名: ``

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

    コンポーネント: `tidb` | 1秒あたりに実行されるトランザクション数。 | | tidb_cloud.node_storage_used_bytes | ゲージ | クラスター名: ``

    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…

    コンポーネント: tikv|tiflash | TiKV またはTiFlashノードのディスク使用量（バイト単位）。このメトリックは主にストレージエンジンの論理データ サイズを表し、WAL ファイルと一時ファイルは除外されます。実際のディスク使用率を計算するには、代わりに`(capacity - available) / capacity`を使用してください。TiKV のストレージ使用率が 80% を超えると、レイテンシーの急増が発生する可能性があり、使用率が高くなるとリクエストが失敗する可能性があります。すべてのTiFlashノードのストレージ使用率が 80% に達すると、 TiFlashレプリカを追加する DDL ステートメントは無期限にハングします。 | | tidb_cloud.node_storage_capacity_bytes | ゲージ | クラスター名: ``

    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…

    コンポーネント: tikv|tiflash | TiKV/ TiFlashノードのディスク容量（バイト単位）。 | diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index 6c22411486d0f..d704cb7187279 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -15,7 +15,7 @@ TiDB Cloudは、2022年3月15日よりプロジェクトレベルのPrometheus - **クラスタレベルのPrometheus統合**：2025年10月21日までに組織内に削除されていない従来のプロジェクトレベルのPrometheus統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのPrometheus統合を提供します。 -- **従来のプロジェクトレベルの Prometheus 統合 (ベータ版)** : 2025 年 10 月 21 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Prometheus 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。 +- **従来のプロジェクトレベルの Prometheus 統合 (ベータ版)** : 2025年 10月 21日時点で組織内に少なくとも 1つの従来のプロジェクトレベルの Prometheus 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。 > **Note** > diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 5e3b498428e7f..0bb5a106f7a01 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -61,7 +61,7 @@ TiDB Cloud Premiumは、本番環境向けに強化された自動バックア | バックアップモード | サポートされるバックアップタイプ | 保持期間と復元オプション | 料金モデル | | --- | --- | --- | --- | | **Standard Bundle Mode** |
    • PITR
    • 時間単位のバックアップスナップショット
    • 日次バックアップスナップショット
    |
    • PITR: 7日間
    • 時間単位スナップショット: 7日間
    • 日次スナップショット: 33日間
    • 日次スナップショットは UTC 00:00 に作成されます。
    | 増分データ量に基づきます。 | -| **Custom Retention Mode** |
    • PITR
    • 日次バックアップスナップショット
    | 保持期間は 3 日から 33 日まで設定できます。PITR と日次スナップショットには、設定した保持期間が適用されます。 | スナップショットサイズに保持期間を乗じて課金されます。各バックアップは個別のオブジェクトとして課金されます。 | +| **Custom Retention Mode** |
    • PITR
    • 日次バックアップスナップショット
    | 保持期間は 3日から 33日まで設定できます。PITR と日次スナップショットには、設定した保持期間が適用されます。 | スナップショットサイズに保持期間を乗じて課金されます。各バックアップは個別のオブジェクトとして課金されます。 | @@ -70,7 +70,7 @@ TiDB Cloud Premiumは、本番環境向けに強化された自動バックア | バックアップモード | サポートされるバックアップタイプ | 保持期間と復元オプション | | --- | --- | --- | | **Standard Bundle Mode** |
    • PITR
    • 時間単位のバックアップスナップショット
    • 日次バックアップスナップショット
    |
    • PITR: 7日間
    • 時間単位スナップショット: 7日間
    • 日次スナップショット: 33日間
    • 日次スナップショットは 00:00 UTC に作成されます。
    | -| **Custom Retention Mode** |
    • PITR
    • 日次バックアップスナップショット
    | 保持期間は 3 日から 33 日まで設定できます。PITR と日次スナップショットには、設定した保持期間が適用されます。 | +| **Custom Retention Mode** |
    • PITR
    • 日次バックアップスナップショット
    | 保持期間は 3日から 33日まで設定できます。PITR と日次スナップショットには、設定した保持期間が適用されます。 | @@ -91,7 +91,7 @@ PITR を使用すると、保持期間内の任意の時点にデータを復元 5. **Custom Retention Mode** を選択した場合は、以下の設定を構成します。それ以外の場合は、この手順をスキップします。 - - **Backup Retention**: 3 日から 33 日の保持期間を選択します。デフォルト値は 7 日です。 + - **Backup Retention**: 3日から 33日の保持期間を選択します。デフォルト値は 7日です。 - **Daily Backup Time**: 日次スナップショットの時刻を選択します。タイムゾーンはこの設定の横に表示されます。 6. **Overview** セクションを確認し、**Save** をクリックします。 diff --git a/tidb-cloud/premium/built-in-monitoring-premium.md b/tidb-cloud/premium/built-in-monitoring-premium.md index 7003ac43fb7f2..d3e626775c1a7 100644 --- a/tidb-cloud/premium/built-in-monitoring-premium.md +++ b/tidb-cloud/premium/built-in-monitoring-premium.md @@ -31,11 +31,11 @@ TiDB Cloud Premiumインスタンスの場合、メトリクスデータは7日 | メトリック名 | ラベル | 説明 | | :------------------ | :------------------------------------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1秒あたりのリクエストユニット数 | 1秒あたりの合計RU、平均RU/秒 | リクエストユニット (RU) は、クエリまたはトランザクションのリソース消費を追跡するために使用される測定単位です。 `Total RU per second` 1 秒あたりのリアルタイム RU 消費量を表示します。 `AVG RU/s`選択した時間範囲における 1 秒あたりの平均 RU 消費量を表示し、リソース消費量をよりよく理解するのに役立ちます。実行するクエリに加えて、バックグラウンド アクティビティも RU を消費する可能性があります。そのため、QPS が 0 の場合でも、1 秒あたりの RU 消費量は 0 を超える場合があります。 | +| 1秒あたりのリクエストユニット数 | 1秒あたりの合計RU、平均RU/秒 | リクエストユニット (RU) は、クエリまたはトランザクションのリソース消費を追跡するために使用される測定単位です。 `Total RU per second` 1秒あたりのリアルタイム RU 消費量を表示します。 `AVG RU/s`選択した時間範囲における 1秒あたりの平均 RU 消費量を表示し、リソース消費量をよりよく理解するのに役立ちます。実行するクエリに加えて、バックグラウンド アクティビティも RU を消費する可能性があります。そのため、QPS が 0 の場合でも、1秒あたりの RU 消費量は 0 を超える場合があります。 | | 使用済みストレージサイズ | {タイプ} | 行ストアのサイズと列ストアのサイズ。 | -| 1秒あたりのクエリ数 | すべて、{SQLタイプ} | 1 秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | +| 1秒あたりのクエリ数 | すべて、{SQLタイプ} | 1秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | | クエリ実行時間 | avg、avg-{SQLタイプ}、99、99-{SQLタイプ} | クライアントからTiDBへのリクエストを受信して​​から、TiDBがリクエストを実行し、結果をクライアントに返すまでの時間。 | -| SQLタイプ別のデータベース処理時間 | すべて、{SQLタイプ} | すべて：1秒あたりのデータベース処理時間の合計。
    {SQL type}: SQL ステートメントが 1 秒あたりに消費するデータベース時間。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | +| SQLタイプ別のデータベース処理時間 | すべて、{SQLタイプ} | すべて：1秒あたりのデータベース処理時間の合計。
    {SQL type}: SQL ステートメントが 1秒あたりに消費するデータベース時間。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | | 失敗したクエリ | 全て | 1分あたりのSQL文実行エラー数に基づいた、エラーの種類（構文エラーや主キーの競合など）の統計情報。 | | 1秒あたりのコマンド数 | {タイプ} | コマンドの種類に基づいた、1秒あたりに処理されるコマンドの数。 | | プランキャッシュOPSを使用したクエリ | ヒット、ミス | hit: プランキャッシュを使用するクエリが1秒あたりに実行される回数。
    miss: 1秒あたりにプランキャッシュに見つからないクエリの数。 | diff --git a/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md b/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md index 0e15346ab3bde..a04fb2b353ac6 100644 --- a/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md +++ b/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md @@ -56,7 +56,7 @@ AWS VPC 設定で DNS ホスト名と DNS 解決の両方が有効になって > **Note:** > > - すでにプライベートエンドポイント接続を作成している場合、アクティブなエンドポイントが接続ダイアログに表示されます。追加のプライベートエンドポイント接続を作成するには、左側のナビゲーションペインで **Settings** > **Networking** をクリックして **Networking** ページに移動します。 -> - 各 {{{ .premium }}} または {{{ .byoc }}} インスタンスについて、対応するエンドポイントサービスはインスタンス作成後 3 ～ 4 分で自動的に作成されます。 +> - 各 {{{ .premium }}} または {{{ .byoc }}} インスタンスについて、対応するエンドポイントサービスはインスタンス作成後 3 ～ 4分で自動的に作成されます。 ### Step 2. AWS で VPC endpoint を作成する {#step-2-create-a-vpc-endpoint-in-aws} @@ -88,7 +88,7 @@ AWS CLI を使用して VPC endpoint を作成するには、次の手順を実 > > - コマンドを実行する前に、AWS CLI をインストールして設定しておく必要があります。詳細は [AWS CLI configuration basics](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) を参照してください。 > -> - サービスが 3 つを超える availability zone (AZ) にまたがっている場合、VPC endpoint service が subnet の AZ をサポートしていないことを示すエラーメッセージが表示されます。この問題は、選択したリージョンに、{{{ .premium }}} または {{{ .byoc }}} インスタンスが配置されている AZ に加えて、余分な AZ が存在する場合に発生します。この場合は、[PingCAP Technical Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) にお問い合わせください。 +> - サービスが 3つを超える availability zone (AZ) にまたがっている場合、VPC endpoint service が subnet の AZ をサポートしていないことを示すエラーメッセージが表示されます。この問題は、選択したリージョンに、{{{ .premium }}} または {{{ .byoc }}} インスタンスが配置されている AZ に加えて、余分な AZ が存在する場合に発生します。この場合は、[PingCAP Technical Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) にお問い合わせください。
    @@ -110,7 +110,7 @@ AWS Management Console を使用して VPC endpoint を作成するには、次 > **Tip:** > - > サービスが 3 つを超える availability zone (AZ) にまたがっている場合、**Subnets** エリアで AZ を選択できないことがあります。この問題は、選択したリージョンに、{{{ .premium }}} または {{{ .byoc }}} インスタンスが配置されている AZ に加えて、余分な AZ が存在する場合に発生します。この場合は、[PingCAP Technical Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) にお問い合わせください。 + > サービスが 3つを超える availability zone (AZ) にまたがっている場合、**Subnets** エリアで AZ を選択できないことがあります。この問題は、選択したリージョンに、{{{ .premium }}} または {{{ .byoc }}} インスタンスが配置されている AZ に加えて、余分な AZ が存在する場合に発生します。この場合は、[PingCAP Technical Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) にお問い合わせください。 8. **Security groups** エリアで、適切な security group を選択します。 @@ -176,7 +176,7 @@ AWS マネジメントコンソールでプライベート DNS を有効にす プライベートエンドポイント接続が作成されると、接続ダイアログにリダイレクトされます。 -1. プライベートエンドポイント接続のステータスが **System Checking** から **Active** に変わるまで待機してください（約 5 分）。 +1. プライベートエンドポイント接続のステータスが **System Checking** から **Active** に変わるまで待機してください（約5分）。 2. **Connection Type** ドロップダウンリストで、**Private Endpoint** を選択します。 3. **Endpoint ID** ドロップダウンリストで、使用するアクティブな VPC エンドポイントを選択します。 diff --git a/tidb-cloud/premium/connect-to-tidb-instance.md b/tidb-cloud/premium/connect-to-tidb-instance.md index 533c7f45af2dd..7313b85037b48 100644 --- a/tidb-cloud/premium/connect-to-tidb-instance.md +++ b/tidb-cloud/premium/connect-to-tidb-instance.md @@ -23,7 +23,7 @@ TiDB Cloud で {{{ .premium }}} または {{{ .byoc } ## ネットワーク {#network} -{{{ .premium }}} および {{{ .byoc }}} には、2 種類のネットワーク接続タイプがあります。 +{{{ .premium }}} および {{{ .byoc }}} には、2種類のネットワーク接続タイプがあります。 - [プライベートエンドポイント](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)(推奨) diff --git a/tidb-cloud/premium/delete-tidb-instance.md b/tidb-cloud/premium/delete-tidb-instance.md index e378ca7a7d45a..c6f8319a39bc9 100644 --- a/tidb-cloud/premium/delete-tidb-instance.md +++ b/tidb-cloud/premium/delete-tidb-instance.md @@ -27,7 +27,7 @@ summary: TiDB Cloud Premiumインスタンスを削除する方法を学びま バックアップ済みの {{{ .premium }}} または {{{ .byoc }}} インスタンスを削除すると、そのインスタンスの既存のバックアップファイルはごみ箱に移動されます。 - 自動バックアップは、保存期間が終了すると期限切れとなり、自動的に削除されます。保存期間は、変更しない場合はデフォルトで 7 日間です。 + 自動バックアップは、保存期間が終了すると期限切れとなり、自動的に削除されます。保存期間は、変更しない場合はデフォルトで 7日間です。 > **Note:** > diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 47f445c4a6190..5ef7da2cf6d88 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -108,7 +108,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **Storage Provider**： **Amazon S3**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** : AWS ロール ARN の値を入力してください。新しいロールを作成する必要がある場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロールを作成] をクリックし**、ガイド付き手順に従って、提供されているテンプレートを起動し、 IAM警告を確認し、スタックを作成し、生成された ARN をTiDB Cloud Premium にコピーしてください。 @@ -163,7 +163,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.csv` 。 + - 1つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 - **Test Bucket Access**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 diff --git a/tidb-cloud/recovery-group-get-started.md b/tidb-cloud/recovery-group-get-started.md index 2a926f7ac8a58..74851799863fb 100644 --- a/tidb-cloud/recovery-group-get-started.md +++ b/tidb-cloud/recovery-group-get-started.md @@ -77,7 +77,7 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 - 整合性は保証されません。リカバリグループのレプリケーション中、下流クラスタはトランザクションの整合性読み取りを保証しません。上流クラスタが利用できなくなった場合、下流クラスタのデータをトランザクションの整合性のある状態に復元することはできません。 -TiDB Cloud は、近い将来、次の 2 つの追加の回復力レベルを提供する予定です。 +TiDB Cloud は、近い将来、次の2つの追加の回復力レベルを提供する予定です。 - 最終的な整合性。リカバリグループのレプリケーション中、下流クラスターはトランザクションの整合性読み取りを保証しません。ただし、上流クラスターが利用できなくなった場合は、下流クラスターのデータをトランザクションの整合性が保たれた状態に復元できます。 - ほぼリアルタイムの整合性。リカバリグループのレプリケーション中、下流クラスタはほぼリアルタイムのトランザクション整合性読み取りを提供します。上流クラスタが利用できなくなった場合でも、下流クラスタのデータをトランザクション整合性状態に復元できます。 diff --git a/tidb-cloud/recovery-group-overview.md b/tidb-cloud/recovery-group-overview.md index 52cb02fb70ff0..dd2a3eda0e484 100644 --- a/tidb-cloud/recovery-group-overview.md +++ b/tidb-cloud/recovery-group-overview.md @@ -24,7 +24,7 @@ TiDB Cloudリカバリグループを使用すると、 TiDB Cloud Dedicated ク ## 主な機能と制限 {#key-features-and-limitations} - 現在、AWS でホストされているTiDB Cloud Dedicated クラスターのみがリカバリ グループをサポートしています。 -- リカバリ グループは 2 つのクラスター間に確立されます。 +- リカバリ グループは 2つのクラスター間に確立されます。 - リカバリ グループでは、データベースの双方向レプリケーションはサポートされません。 > **Warning** diff --git a/tidb-cloud/releases/_index.md b/tidb-cloud/releases/_index.md index 5fd3b17af06c3..8e4780ee2ba0d 100644 --- a/tidb-cloud/releases/_index.md +++ b/tidb-cloud/releases/_index.md @@ -7,7 +7,7 @@ summary: TiDB Cloud のリリース ノート、カーネルのバージョン [TiDB Cloud](https://www.pingcap.com/tidb/cloud/)は、オープンソースのハイブリッドトランザクションおよび分析処理（HTAP）データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)をクラウドに提供する、フルマネージドの Database-as-a-Service（DBaaS）です。 -TiDB Cloud には、[クラウドプラットフォーム リリース](#cloud-platform-release-notes) と [データベース カーネル リリース](#database-kernel-release-notes) の 2 種類のリリースがあります。これらは独立したリリース サイクルに従い、別々に文書化されています。 +TiDB Cloud には、[クラウドプラットフォーム リリース](#cloud-platform-release-notes) と [データベース カーネル リリース](#database-kernel-release-notes) の 2種類のリリースがあります。これらは独立したリリース サイクルに従い、別々に文書化されています。 ## クラウドプラットフォーム リリースノート diff --git a/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md b/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md index 864a1235231c9..a21a0b652f3aa 100644 --- a/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md @@ -1,11 +1,11 @@ --- title: 2023-08-31 TiDB Cloud Console Maintenance Notification -summary: 2023 年 8 月 31 日のTiDB Cloud Console メンテナンスの詳細 (メンテナンス ウィンドウ、理由、影響など) について説明します。 +summary: 2023年 8月 31日のTiDB Cloud Console メンテナンスの詳細 (メンテナンス ウィンドウ、理由、影響など) について説明します。 --- # [2023-08-31] TiDB Cloudコンソールメンテナンスのお知らせ {#2023-08-31-tidb-cloud-console-maintenance-notification} -この通知では、2023 年 8 月 31 日の[TiDB Cloudコンソール](https://tidbcloud.com/)メンテナンスについて知っておく必要のある詳細について説明します。 +この通知では、2023年 8月 31日の[TiDB Cloudコンソール](https://tidbcloud.com/)メンテナンスについて知っておく必要のある詳細について説明します。 ## メンテナンスウィンドウ {#maintenance-window} diff --git a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md index ccdf1653ba5ba..d654ee2355726 100644 --- a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md @@ -1,11 +1,11 @@ --- title: 2023-09-26 TiDB Cloud Console Maintenance Notification -summary: 2023 年 9 月 26 日のTiDB Cloud Console メンテナンスの詳細 (メンテナンス ウィンドウ、理由、影響など) について説明します。 +summary: 2023年 9月 26日のTiDB Cloud Console メンテナンスの詳細 (メンテナンス ウィンドウ、理由、影響など) について説明します。 --- # [2023-09-26] TiDB Cloudコンソールメンテナンスのお知らせ {#2023-09-26-tidb-cloud-console-maintenance-notification} -この通知では、2023 年 9 月 26 日の[TiDB Cloudコンソール](https://tidbcloud.com/)目のメンテナンスについて知っておく必要のある詳細について説明します。 +この通知では、2023年 9月 26日の[TiDB Cloudコンソール](https://tidbcloud.com/)目のメンテナンスについて知っておく必要のある詳細について説明します。 ## メンテナンスウィンドウ {#maintenance-window} diff --git a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md index 4c6859a2aca2a..0857ae6460889 100644 --- a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md @@ -1,11 +1,11 @@ --- title: 2023-11-14 TiDB Cloud Dedicated Scale Feature Maintenance Notification -summary: 2023 年 11 月 14 日のTiDB Cloud Dedicated Scale 機能メンテナンスの詳細 (メンテナンス ウィンドウや影響など) について説明します。 +summary: 2023年 11月 14日のTiDB Cloud Dedicated Scale 機能メンテナンスの詳細 (メンテナンス ウィンドウや影響など) について説明します。 --- # [2023-11-14] TiDB Cloud Dedicatedスケール機能メンテナンスのお知らせ {#2023-11-14-tidb-cloud-dedicated-scale-feature-maintenance-notification} -この通知では、2023 年 11 月 14 日のTiDB Cloud Dedicated の[スケール機能](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#scale-your-tidb-cluster)メンテナンスについて知っておく必要のある詳細について説明します。 +この通知では、2023年 11月 14日のTiDB Cloud Dedicated の[スケール機能](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#scale-your-tidb-cluster)メンテナンスについて知っておく必要のある詳細について説明します。 ## メンテナンスウィンドウ {#maintenance-window} diff --git a/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md b/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md index 89ece9fea9621..d6ef99a22d246 100644 --- a/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md @@ -1,11 +1,11 @@ --- title: 2024-04-11 TiDB Cloud Data Migration (DM) Feature Maintenance Notification -summary: 2024 年 4 月 11 日のTiDB Cloud Data Migration (DM) 機能メンテナンスの詳細（メンテナンス ウィンドウや影響など）について説明します。 +summary: 2024年 4月 11日のTiDB Cloud Data Migration (DM) 機能メンテナンスの詳細（メンテナンス ウィンドウや影響など）について説明します。 --- # [2024-04-11] TiDB Cloudデータ移行（DM）機能メンテナンスのお知らせ {#2024-04-11-tidb-cloud-data-migration-dm-feature-maintenance-notification} -この通知では、2024 年 4 月 11 日のTiDB Cloud Dedicated の[データ移行（DM）機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)のメンテナンスについて知っておく必要のある詳細について説明します。 +この通知では、2024年 4月 11日のTiDB Cloud Dedicated の[データ移行（DM）機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)のメンテナンスについて知っておく必要のある詳細について説明します。 ## メンテナンスウィンドウ {#maintenance-window} @@ -36,7 +36,7 @@ AWS にデプロイされたクラスターの場合: Google Cloud にデプロイされたクラスタの場合: -- DM コンソールは最大 30 分間利用できなくなります。この間は、DM タスクの作成や管理はできません。 +- DM コンソールは最大 30分間利用できなくなります。この間は、DM タスクの作成や管理はできません。 - DMタスクが増分移行段階にある場合、最大30分間中断されます。この間、MySQLデータベースのバイナリログをパージしないでください。アップグレードが完了すると、DMタスクは自動的に再開されます。 - DMタスクがフルデータのエクスポートとインポートの段階にある場合、アップグレード中に失敗し、アップグレード後に再開することはできません。アップグレード開始時にフルデータのエクスポートとインポートの段階にあるDMタスクが存在しないように、アップグレードを実行する当日はDMタスクを作成しないことをお勧めします。 diff --git a/tidb-cloud/releases/notification-2024-04-18-dm-feature-maintenance.md b/tidb-cloud/releases/notification-2024-04-18-dm-feature-maintenance.md index e8f92918ee61b..15bc1be5ed0e2 100644 --- a/tidb-cloud/releases/notification-2024-04-18-dm-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2024-04-18-dm-feature-maintenance.md @@ -1,11 +1,11 @@ --- title: 2024-04-18 TiDB Cloud Data Migration (DM) Feature Maintenance Notification -summary: 2024 年 4 月 18 日のTiDB Cloud Data Migration (DM) 機能メンテナンスの詳細 (メンテナンス ウィンドウや影響など) について説明します。 +summary: 2024年 4月 18日のTiDB Cloud Data Migration (DM) 機能メンテナンスの詳細 (メンテナンス ウィンドウや影響など) について説明します。 --- # [2024-04-18] TiDB Cloudデータ移行（DM）機能メンテナンスのお知らせ {#2024-04-18-tidb-cloud-data-migration-dm-feature-maintenance-notification} -この通知では、2024 年 4 月 18 日のTiDB Cloud Dedicated [データ移行（DM）機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)のメンテナンスについて知っておく必要のある詳細について説明します。 +この通知では、2024年 4月 18日のTiDB Cloud Dedicated [データ移行（DM）機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)のメンテナンスについて知っておく必要のある詳細について説明します。 ## メンテナンスウィンドウ {#maintenance-window} diff --git a/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md b/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md index 11c94e6fb949c..d4d8ad69df402 100644 --- a/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md +++ b/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md @@ -1,11 +1,11 @@ --- title: 2024-09-15 TiDB Cloud Console Maintenance Notification -summary: 2024 年 9 月 15 日のTiDB Cloud Console メンテナンスの詳細 (メンテナンス ウィンドウ、理由、影響など) について説明します。 +summary: 2024年 9月 15日のTiDB Cloud Console メンテナンスの詳細 (メンテナンス ウィンドウ、理由、影響など) について説明します。 --- # [2024-09-15] TiDB Cloudコンソールメンテナンスのお知らせ {#2024-09-15-tidb-cloud-console-maintenance-notification} -この通知では、2024 年 9 月 15 日の[TiDB Cloudコンソール](https://tidbcloud.com/)目のメンテナンスについて知っておく必要のある詳細について説明します。 +この通知では、2024年 9月 15日の[TiDB Cloudコンソール](https://tidbcloud.com/)目のメンテナンスについて知っておく必要のある詳細について説明します。 ## メンテナンスウィンドウ {#maintenance-window} diff --git a/tidb-cloud/releases/release-notes-2020.md b/tidb-cloud/releases/release-notes-2020.md index db854c2dc32b5..5d70cee59c1c3 100644 --- a/tidb-cloud/releases/release-notes-2020.md +++ b/tidb-cloud/releases/release-notes-2020.md @@ -1,11 +1,11 @@ --- title: TiDB Cloud Release Notes in 2020 -summary: 2020 年のTiDB Cloudのリリース ノートについて説明します。 +summary: 2020年のTiDB Cloudのリリース ノートについて説明します。 --- # 2020年のTiDB Cloudリリースノート {#tidb-cloud-release-notes-in-2020} -このページには、2020 年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 +このページには、2020年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 ## 2020年12月30日 {#december-30-2020} @@ -15,7 +15,7 @@ summary: 2020 年のTiDB Cloudのリリース ノートについて説明しま ## 2020年12月16日 {#december-16-2020} -- すべてのクラスタ層で TiDB ノードの最小数を 1 に調整します。 +- すべてのクラスタ層で TiDB ノードの最小数を1に調整します。 - SQL Web シェルでシステム コマンドの実行を禁止する - TiDB クラスターの redact-log をデフォルトで有効にする diff --git a/tidb-cloud/releases/release-notes-2021.md b/tidb-cloud/releases/release-notes-2021.md index 2f796b94b36ce..967ecfd1eff00 100644 --- a/tidb-cloud/releases/release-notes-2021.md +++ b/tidb-cloud/releases/release-notes-2021.md @@ -1,11 +1,11 @@ --- title: TiDB Cloud Release Notes in 2021 -summary: 2021 年のTiDB Cloudのリリース ノートについて説明します。 +summary: 2021年のTiDB Cloudのリリース ノートについて説明します。 --- # 2021年のTiDB Cloudリリースノート {#tidb-cloud-release-notes-in-2021} -このページには、2021 年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 +このページには、2021年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 ## 2021年12月28日 {#december-28-2021} @@ -40,13 +40,13 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま ## 2021年11月8日 {#november-8-2021} -- Launch [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)では、 TiDB Cloudの 1 年間の無料トライアルが提供されます。 +- Launch [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)では、 TiDB Cloudの 1年間の無料トライアルが提供されます。 各Developer Tierクラスターはフル機能の TiDB クラスターであり、次のものが含まれます。 - 1つのTiDB共有ノード - - 1 つの TiKV 共有ノード (500 MiB の OLTPストレージ付き) - - 1 つのTiFlash共有ノード (500 MiB の OLAPストレージ付き) + - 1つの TiKV 共有ノード (500 MiB の OLTPストレージ付き) + - 1つのTiFlash共有ノード (500 MiB の OLAPストレージ付き) 始めましょ[ここ](/tidb-cloud/tidb-cloud-quickstart.md) . diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index c5e81a890ee45..6b851c403948c 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -1,11 +1,11 @@ --- title: TiDB Cloud Release Notes in 2022 -summary: 2022 年のTiDB Cloudのリリース ノートについて説明します。 +summary: 2022年のTiDB Cloudのリリース ノートについて説明します。 --- # 2022年のTiDB Cloudリリースノート {#tidb-cloud-release-notes-in-2022} -このページには、2022 年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 +このページには、2022年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 ## 2022年12月28日 {#december-28-2022} @@ -140,7 +140,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま PITR 機能を使用するには、TiDB クラスターのバージョンが少なくとも v6.3.0 であり、TiKV ノードのサイズが少なくとも 8 vCPU および 16 GiB であることを確認してください。 - デフォルトでは、バックアップデータはクラスタが作成されたリージョンに保存されます。日本では、GCP 上でホストされ PITR が有効になっている TiDB クラスタの場合、バックアップデータを 1 つまたは 2 つのリージョン（東京または大阪、あるいはその両方）に保存することを選択できます。別のリージョンからデータを復元することで、より高いレベルのデータ安全性が確保され、リージョン障害にも耐えることができます。 + デフォルトでは、バックアップデータはクラスタが作成されたリージョンに保存されます。日本では、GCP 上でホストされ PITR が有効になっている TiDB クラスタの場合、バックアップデータを 1つまたは 2つのリージョン（東京または大阪、あるいはその両方）に保存することを選択できます。別のリージョンからデータを復元することで、より高いレベルのデータ安全性が確保され、リージョン障害にも耐えることができます。 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 @@ -268,7 +268,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま [スロークエリ] ページでは、TiDB クラスター内のすべてのスロークエリを検索して表示し、 [実行計画](https://docs.pingcap.com/tidbcloud/explain-overview) 、SQL 実行情報、その他の詳細を表示して各スロークエリのボトルネックを調査できます。 -- アカウントのパスワードをリセットすると、 TiDB Cloud は入力された新しいパスワードを過去 4 回のパスワードと照合し、それらのパスワードを使用しないよう通知します。使用した 4 回のパスワードはいずれも許可されません。 +- アカウントのパスワードをリセットすると、 TiDB Cloud は入力された新しいパスワードを過去 4回のパスワードと照合し、それらのパスワードを使用しないよう通知します。使用した 4回のパスワードはいずれも許可されません。 詳細は[パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)参照。 @@ -555,7 +555,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloudが一般提供を開始しました。以下の[サインアップ](https://tidbcloud.com/signup)かのオプションを選択してください。 - まずは[Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)から無料で始めましょう。 -- 14 日間の PoC トライアルを無料でお申し込みいただくには、お問い合わせください。 +- 14日間の PoC トライアルを無料でお申し込みいただくには、お問い合わせください。 - [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)でフルアクセスを取得します。 ## 2022年3月25日 {#march-25-2022} @@ -619,4 +619,4 @@ TiDB Cloudが一般提供を開始しました。以下の[サインアップ](h バグ修正: - パスワードに一重引用符が含まれている場合にユーザーがクラスターを作成できない問題を修正しました。 -- 組織に所有者が 1 人しかいない場合でも、所有者を削除したり別の役割に変更したりできる問題を修正しました。 +- 組織に所有者が 1人しかいない場合でも、所有者を削除したり別の役割に変更したりできる問題を修正しました。 diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 279d77d3caf83..aca7f0b7d008c 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -1,11 +1,11 @@ --- title: TiDB Cloud Release Notes in 2023 -summary: 2023 年のTiDB Cloudのリリース ノートについて説明します。 +summary: 2023年のTiDB Cloudのリリース ノートについて説明します。 --- # 2023年のTiDB Cloudリリースノート {#tidb-cloud-release-notes-in-2023} -このページには、2023 年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 +このページには、2023年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 ## 2023年12月5日 {#december-5-2023} @@ -71,9 +71,9 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 以下のリソース使用状況アラートを追加します。新しいアラートはデフォルトで無効になっています。必要に応じて有効にすることができます。 - - TiDB ノード全体の最大メモリ使用率が 10 分間 70% を超えました + - TiDB ノード全体の最大メモリ使用率が 10分間 70% を超えました - TiKVノード全体の最大メモリ使用率が10分間70%を超えました - - TiDB ノード全体の最大 CPU 使用率が 10 分間 80% を超えました + - TiDB ノード全体の最大 CPU 使用率が 10分間 80% を超えました - TiKVノード全体の最大CPU使用率が10分間80%を超えました 詳細については[TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md#resource-usage-alerts)を参照してください。 @@ -138,7 +138,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから 2 つの vCPU TiDB ノードと TiKV ノードを削除します。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから 2つの vCPU TiDB ノードと TiKV ノードを削除します。 2 vCPU オプションは、 **[クラスタの作成]**ページまたは**[クラスタの変更]**ページで使用できなくなりました。 @@ -172,7 +172,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - クラスターの主な変更の記録を提供する、 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターの**イベント**ページを紹介します。 - このページでは、過去 7 日間のイベント履歴を表示し、トリガー時間やアクションを開始したユーザーなどの重要な詳細を追跡できます。 + このページでは、過去 7日間のイベント履歴を表示し、トリガー時間やアクションを開始したユーザーなどの重要な詳細を追跡できます。 詳細については[TiDB Cloudクラスター イベント](/tidb-cloud/tidb-cloud-events.md)を参照してください。 @@ -236,7 +236,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[高度なプロパティ](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)を参照してください。 -- AWS でホストされ、2023 年 8 月 15 日以降に作成された[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの負荷分散の改善を無効にします。これには以下が含まれます。 +- AWS でホストされ、2023年 8月 15日以降に作成された[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの負荷分散の改善を無効にします。これには以下が含まれます。 - AWS でホストされている TiDB ノードをスケールアウトするときに、既存の接続を新しい TiDB ノードに自動的に移行することを無効にします。 - AWS でホストされている TiDB ノードをスケールインするときに、利用可能な TiDB ノードへの既存の接続の自動移行を無効にします。 @@ -338,7 +338,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloudのインポート機能を最適化し、データのインポートエクスペリエンスを向上させました。以下の改善が行われました。 - TiDB Cloud Serverless の統合インポート エントリ: データのインポートのエントリを統合し、ローカル ファイルのインポートと Amazon S3 からのファイルのインポートをシームレスに切り替えることができます。 - - 合理化された構成: Amazon S3 からのデータのインポートは 1 つのステップだけで済むため、時間と労力を節約できます。 + - 合理化された構成: Amazon S3 からのデータのインポートは 1つのステップだけで済むため、時間と労力を節約できます。 - 強化された CSV 構成: CSV 構成設定がファイル タイプ オプションの下に配置されるようになり、必要なパラメータを簡単にすばやく構成できるようになりました。 - ターゲットテーブルの選択機能強化：チェックボックスをクリックすることで、データインポートの対象となるターゲットテーブルを選択できるようになりました。この改善により、複雑な式を入力する必要がなくなり、ターゲットテーブルの選択が簡素化されます。 - 表示情報の改良：インポート処理中に表示される不正確な情報に関する問題を解決しました。また、不完全なデータ表示や誤解を招く情報を避けるため、プレビュー機能を削除しました。 @@ -350,7 +350,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)が一般公開されました。 -- 多言語サポート、24 時間 365 日のリアルタイム応答、統合ドキュメント アクセスを提供する OpenAI 搭載チャットボット、TiDB Bot (ベータ版) をご紹介します。 +- 多言語サポート、24時間 365日のリアルタイム応答、統合ドキュメント アクセスを提供する OpenAI 搭載チャットボット、TiDB Bot (ベータ版) をご紹介します。 TiDB Bot には次のような利点があります。 @@ -364,7 +364,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloud、 TiDB Cloud Serverless クラスターのブランチを作成できます。クラスターのブランチとは、元のクラスターから分岐したデータのコピーを含む独立したインスタンスです。これにより分離された環境が提供され、元のクラスターへの影響を心配することなく、自由に接続して実験を行うことができます。 - [TiDB Cloudコンソール](/tidb-cloud/branch-manage.md)または[TiDB Cloud CLI](/tidb-cloud/ticloud-branch-create.md)のいずれかを使用して、2023 年 7 月 5 日以降に作成されたTiDB Cloud Serverless クラスターのブランチを作成できます。 + [TiDB Cloudコンソール](/tidb-cloud/branch-manage.md)または[TiDB Cloud CLI](/tidb-cloud/ticloud-branch-create.md)のいずれかを使用して、2023年 7月 5日以降に作成されたTiDB Cloud Serverless クラスターのブランチを作成できます。 アプリケーション開発にGitHubをご利用の場合、 TiDB Cloud Serverlessブランチ機能をGitHub CI/CDパイプラインに統合することで、本番のデータベースに影響を与えることなく、ブランチを使用してプルリクエストを自動的にテストできます。詳細については、 [TiDB Cloud Serverless Branching（ベータ版）をGitHubと統合する](/tidb-cloud/branch-github-integration.md)ご覧ください。 @@ -420,7 +420,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[クラスターのサイズ](/tidb-cloud/size-your-cluster.md)を参照してください。 -- [監視メトリクスの保持期間](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) for [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターを 3 日から 7 日に延長します。 +- [監視メトリクスの保持期間](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) for [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターを 3日から 7日に延長します。 メトリクスの保持期間を延長することで、より多くの履歴データにアクセスできるようになります。これにより、クラスターの傾向やパターンを特定し、より適切な意思決定と迅速なトラブルシューティングが可能になります。 @@ -516,7 +516,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 新しいナビゲーションにより、機能エントリをより簡単に、より直感的に見つけられるようになりました。新しいナビゲーションを表示するには、クラスターの概要ページにアクセスしてください。 -- Dedicated Tierクラスターの**診断**ページの次の 2 つのタブに新しいネイティブ Web インフラストラクチャをリリースします。 +- Dedicated Tierクラスターの**診断**ページの次の2つのタブに新しいネイティブ Web インフラストラクチャをリリースします。 - [スロークエリ](/tidb-cloud/tune-performance.md#slow-query) - [SQL文](/tidb-cloud/tune-performance.md#statement-analysis) @@ -527,7 +527,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 2023 年 4 月 26 日以降に作成された GCP ホスト クラスタのノード サイズの変更をサポートします。 +- 2023年 4月 26日以降に作成された GCP ホスト クラスタのノード サイズの変更をサポートします。 この機能により、需要の増加に合わせて高パフォーマンスノードにアップグレードしたり、コスト削減のために低パフォーマンスノードにダウングレードしたりできます。この柔軟性の向上により、ワークロードに合わせてクラスターの容量を調整し、コストを最適化できます。 @@ -600,12 +600,11 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま メンテナンスの頻度を最小限に抑えるよう努めます。メンテナンス期間が予定されている場合、デフォルトの開始時刻は対象週の水曜日の午前3時（ TiDB Cloud組織のタイムゾーンに基づきます）です。サービス中断の可能性を回避するために、メンテナンススケジュールをご確認いただき、それに応じて運用を計画していただくことが重要です。 - - 最新情報をお届けするために、 TiDB Cloud はメンテナンス ウィンドウごとに 3 つの電子メール通知を送信します。1 つはメンテナンス タスクの前、1 つは開始時、もう 1 つはメンテナンス タスクの後のものです。 + - 最新情報をお届けするために、 TiDB Cloud はメンテナンス ウィンドウごとに 3つの電子メール通知を送信します。1つはメンテナンス タスクの前、1つは開始時、もう 1つはメンテナンス タスクの後のものです。 - メンテナンスの影響を最小限に抑えるには、 **メンテナンス**ページでメンテナンスの開始時刻を希望の時間に変更したり、メンテナンス アクティビティを延期したりすることができます。 - 詳細については[メンテナンスウィンドウを構成する](/tidb-cloud/configure-maintenance-window.md)を参照してください。 -- 2023 年 4 月 25 日以降に作成され、AWS でホストされている[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの TiDB ノードをスケーリングするときに、TiDB の負荷分散を改善し、接続の切断を減らします。 +- 2023年 4月 25日以降に作成され、AWS でホストされている[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの TiDB ノードをスケーリングするときに、TiDB の負荷分散を改善し、接続の切断を減らします。 - TiDB ノードをスケールアウトするときに、既存の接続を新しい TiDB ノードに自動的に移行することをサポートします。 - TiDB ノードをスケールインするときに、既存の接続を利用可能な TiDB ノードに自動的に移行することをサポートします。 @@ -678,10 +677,10 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 誤検知を防ぐため、 [TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md#tidb-cloud-built-in-alert-conditions)から以下の 2 つのアラートを削除します。これは、ノードの 1 つで一時的なオフラインまたはメモリ不足 (OOM) が発生しても、クラスター全体の健全性に大きな影響を与えないためです。 +- 誤検知を防ぐため、 [TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md#tidb-cloud-built-in-alert-conditions)から以下の2つのアラートを削除します。これは、ノードの 1つで一時的なオフラインまたはメモリ不足 (OOM) が発生しても、クラスター全体の健全性に大きな影響を与えないためです。 - - クラスター内の少なくとも 1 つの TiDB ノードでメモリが発生しました。 - - 1 つ以上のクラスター ノードがオフラインです。 + - クラスター内の少なくとも 1つの TiDB ノードでメモリが発生しました。 + - 1つ以上のクラスター ノードがオフラインです。 **コンソールの変更** @@ -723,7 +722,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま これらの新しい仕様を使用することで、以前は 16 個の RCU が必要だったシナリオと比較して、データ複製コストを最大 87.5% 削減できます。 -- 2023 年 3 月 28 日以降に作成された[チェンジフィード](/tidb-cloud/changefeed-overview.md)スケールアップまたはスケールダウン仕様をサポートします。 +- 2023年 3月 28日以降に作成された[チェンジフィード](/tidb-cloud/changefeed-overview.md)スケールアップまたはスケールダウン仕様をサポートします。 より高い仕様を選択するとレプリケーションのパフォーマンスが向上し、より低い仕様を選択するとレプリケーションのコストが削減されます。 @@ -733,7 +732,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[TiDB Cloudにシンク](/tidb-cloud/changefeed-sink-to-tidb-cloud.md)を参照してください。 -- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能に対して 2 つの新しい GCP リージョン ( `Singapore (asia-southeast1)`と`Oregon (us-west1)`をサポートします。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能に対して 2つの新しい GCP リージョン ( `Singapore (asia-southeast1)`と`Oregon (us-west1)`をサポートします。 これらの新しいリージョンにより、 TiDB Cloudへのデータ移行の選択肢が広がります。アップストリームデータがこれらのリージョン内またはその付近に保存されている場合、GCP からTiDB Cloudへのより高速で信頼性の高いデータ移行を活用できるようになります。 @@ -766,7 +765,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [Data Serviceを始める](/tidb-cloud/data-service-get-started.md) - [Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md) -- AWS でホストされ、2022 年 12 月 31 日以降に作成される[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでスケールするために、TiDB、TiKV、およびTiFlashノードのサイズを縮小することをサポートします。 +- AWS でホストされ、2022年 12月 31日以降に作成される[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでスケールするために、TiDB、TiKV、およびTiFlashノードのサイズを縮小することをサポートします。 ノード サイズを[TiDB Cloudコンソール経由](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)または[TiDB Cloud API（ベータ版）経由](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)減らすことができます。 @@ -871,10 +870,10 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この方法はロールARNを使用するよりも簡単です。詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 -- [監視メトリクスの保持期間](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) 2 日からより長い期間に延長します。 +- [監視メトリクスの保持期間](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) 2日からより長い期間に延長します。 - - Dedicated Tierクラスターの場合、過去 7 日間のメトリック データを表示できます。 - - Serverless Tierクラスターの場合、過去 3 日間のメトリック データを表示できます。 + - Dedicated Tierクラスターの場合、過去 7日間のメトリック データを表示できます。 + - Serverless Tierクラスターの場合、過去 3日間のメトリック データを表示できます。 メトリクスの保持期間を延長することで、より多くの履歴データにアクセスできるようになります。これにより、クラスターの傾向やパターンを特定し、より適切な意思決定と迅速なトラブルシューティングが可能になります。 @@ -904,7 +903,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターの**監視**ページを紹介します。 - **モニタリング**ページには、1 秒あたりに実行される SQL ステートメントの数、クエリの平均実行時間、失敗したクエリの数など、さまざまなメトリックとデータが提供され、 Serverless Tierクラスター内の SQL ステートメントの全体的なパフォーマンスをよりよく理解するのに役立ちます。 + **モニタリング**ページには、1秒あたりに実行される SQL ステートメントの数、クエリの平均実行時間、失敗したクエリの数など、さまざまなメトリックとデータが提供され、 Serverless Tierクラスター内の SQL ステートメントの全体的なパフォーマンスをよりよく理解するのに役立ちます。 詳細については[TiDB Cloud組み込み監視](/tidb-cloud/built-in-monitoring.md)を参照してください。 @@ -975,13 +974,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- AWS でホストされ、2022 年 12 月 31 日以降に作成されたTiDB Cloud Dedicated クラスターの**ノード サイズ (vCPU + RAM) を**増やすことで、TiDB、TiKV、およびTiFlashノードのスケールアップをサポートします。 +- AWS でホストされ、2022年 12月 31日以降に作成されたTiDB Cloud Dedicated クラスターの**ノード サイズ (vCPU + RAM) を**増やすことで、TiDB、TiKV、およびTiFlashノードのスケールアップをサポートします。 ノード サイズを[TiDB Cloudコンソールを使用する](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)または[TiDB Cloud API（ベータ版）を使用する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)増やすことができます。 -- [**監視**](/tidb-cloud/built-in-monitoring.md)ページのメトリックの保持期間を 2 日間に延長します。 +- [**監視**](/tidb-cloud/built-in-monitoring.md)ページのメトリックの保持期間を 2日間に延長します。 - これで、過去 2 日間のメトリック データにアクセスできるようになり、クラスターのパフォーマンスと傾向をより柔軟かつ明確に把握できるようになります。 + これで、過去 2日間のメトリック データにアクセスできるようになり、クラスターのパフォーマンスと傾向をより柔軟かつ明確に把握できるようになります。 この改善は追加費用なしで、クラスターの[**監視**](/tidb-cloud/built-in-monitoring.md)ページの**診断**タブからアクセスできます。これにより、パフォーマンスの問題を特定してトラブルシューティングし、クラスター全体の健全性をより効果的に監視できるようになります。 diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 2e8f4575f0f76..552b7cb096dea 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -178,7 +178,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) AWS上でのロードバランシングに関する課金体系の変更。 - 2024 年 8 月 1 日以降、 TiDB Cloud Dedicated の請求書には、[AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)に伴い、パブリック IPv4 アドレスに対する新しい AWS 料金が含まれます。各パブリック IPv4 アドレスの料金は 1 時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 + 2024年 8月 1日以降、 TiDB Cloud Dedicated の請求書には、[AWSの料金改定は2024年2月1日から適用されます](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/)に伴い、パブリック IPv4 アドレスに対する新しい AWS 料金が含まれます。各パブリック IPv4 アドレスの料金は 1時間あたり 0.005 ドルで、これは AWS でホストされるTiDB Cloud Dedicatedクラスターごとに月額約 10 ドルになります。 この料金は、お客様の既存の**TiDB Cloud Dedicated - Data Transfer - Load Balancing**サービスの下に表示されます。 [請求明細](/tidb-cloud/tidb-cloud-billing.md#billing-details)。 @@ -364,7 +364,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **全般的な変更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスター向けに、**無料プラン**と**スケーラブルプラン**の 2 つのサービス プランを導入します。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスター向けに、**無料プラン**と**スケーラブルプラン**の 2つのサービス プランを導入します。 TiDB Cloud Serverlessは、多様なユーザーニーズに対応するため、無料プランと拡張可能なサービスプランを提供しています。これからサービスを開始する場合でも、アプリケーションの需要増加に合わせて規模を拡大する場合でも、これらのプランは必要な柔軟性と機能を提供します。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 0bb813784066e..fe6af8968cd46 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -1,11 +1,11 @@ --- title: TiDB Cloud Release Notes in 2025 -summary: 2025 年のTiDB Cloudのリリース ノートについて説明します。 +summary: 2025年のTiDB Cloudのリリース ノートについて説明します。 --- # 2025年のTiDB Cloudリリースノート {#tidb-cloud-release-notes-in-2025} -このページには、2025 年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 +このページには、2025年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリース ノートが記載されています。 ## 2025年12月30日 {#december-30-2025} @@ -150,7 +150,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud Starter とTiDB Cloud Essential** - 接続の安定性を向上させ、TiDBサーバーの再起動またはメンテナンス中に予期しない切断を防ぐには、データベース接続の最大有効期間を 30 分未満に設定することをお勧めします。 + 接続の安定性を向上させ、TiDBサーバーの再起動またはメンテナンス中に予期しない切断を防ぐには、データベース接続の最大有効期間を 30分未満に設定することをお勧めします。 詳細については[接続の有効期間を設定する](/develop/dev-guide-connection-parameters.md#configure-the-lifetime-of-connections)を参照してください。 @@ -225,7 +225,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 現在、この機能はベータ版です。詳細については、 [TiDB Cloud Essential のデータベース監査ログ](/tidb-cloud/essential-database-audit-logging.md)ご覧ください。 - - TiDB Cloud Essential では、クラスターのリクエストキャパシティユニット (RCU) 消費量が 1 時間以内に設定された最大値に複数回達したときに通知する新しいイベント`ResourceLimitation`が追加されました。 + - TiDB Cloud Essential では、クラスターのリクエストキャパシティユニット (RCU) 消費量が 1時間以内に設定された最大値に複数回達したときに通知する新しいイベント`ResourceLimitation`が追加されました。 使用量の上限を超えると、処理能力が制限される可能性があります。サービスへの影響を避けるため、最大RCUを増やすことをご検討ください。 @@ -304,7 +304,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud Starter** - 新しく作成された[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターでは、ゾーン高可用性のみが有効になっており、構成することはできません。 - - **2025 年 9 月 9 日**より前にリージョン高可用性が有効にされた既存のTiDB Cloud Starter クラスターの場合、リージョン高可用性は引き続きサポートされ、影響を受けません。 + - **2025年 9月 9日**より前にリージョン高可用性が有効にされた既存のTiDB Cloud Starter クラスターの場合、リージョン高可用性は引き続きサポートされ、影響を受けません。 @@ -324,7 +324,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud Essential** - - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターに対して`Jakarta (ap-southeast-5)` `Mexico (na-south-1)` 3 つの新しい Alibaba Cloud リージョン`Tokyo (ap-northeast-1)`サポートします。 + - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターに対して`Jakarta (ap-southeast-5)` `Mexico (na-south-1)` 3つの新しい Alibaba Cloud リージョン`Tokyo (ap-northeast-1)`サポートします。 - **TiDB Cloud Dedicated** @@ -558,7 +558,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - 新しいアイコンが左上隅に表示されるようになりました。これにより、必要に応じて左側のナビゲーション ペインを簡単に非表示または表示できます。 - - 左上隅にコンボ ボックスが追加され、組織、プロジェクト、クラスターを 1 つの中央の場所から簡単に切り替えられるようになりました。 + - 左上隅にコンボ ボックスが追加され、組織、プロジェクト、クラスターを 1つの中央の場所から簡単に切り替えられるようになりました。 @@ -572,10 +572,10 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - Microsoft Azure の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)がパブリック プレビューで利用できるようになりました。 - このリリースにより、 TiDB Cloud はAWS、Google Cloud、Azure の 3 つの主要なパブリック クラウド プラットフォームすべてをサポートするようになり、ビジネス ニーズとクラウド戦略に最適な場所にTiDB Cloud Dedicated クラスターを展開できるようになりました。 + このリリースにより、 TiDB Cloud はAWS、Google Cloud、Azure の 3つの主要なパブリック クラウド プラットフォームすべてをサポートするようになり、ビジネス ニーズとクラウド戦略に最適な場所にTiDB Cloud Dedicated クラスターを展開できるようになりました。 - AWS および Google Cloud で利用可能なすべてのコア機能は、Azure で完全にサポートされています。 - - Azure サポートは現在、米国東部 2、東日本、東南アジアの 3 つのリージョンで利用可能であり、近日中にさらに多くのリージョンで利用可能になる予定です。 + - Azure サポートは現在、米国東部 2、東日本、東南アジアの 3つのリージョンで利用可能であり、近日中にさらに多くのリージョンで利用可能になる予定です。 - Azure 上のTiDB Cloud Dedicated クラスターには、TiDB バージョン v7.5.3 以降が必要です。 Azure でTiDB Cloud Dedicated をすぐに使い始めるには、次のドキュメントを参照してください。 @@ -683,7 +683,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **リソースの分離**: - - TiDB ノードを論理的に分離されたユニットにグループ化し、1 つのグループのワークロードが他のグループに影響を与えないようにします。 + - TiDB ノードを論理的に分離されたユニットにグループ化し、1つのグループのワークロードが他のグループに影響を与えないようにします。 - アプリケーションまたはビジネス ユニット間のリソース競合を防止します。 - **簡素化された管理**： @@ -804,7 +804,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - すべてのテーブルに対して単一のパーティション ディスパッチャーを定義することも、テーブルごとに異なるパーティション ディスパッチャーを定義することもサポートします。 - - Kafka メッセージのパーティション分散用に、タイムスタンプと列値という 2 つの新しいディスパッチャ タイプを導入しました。 + - Kafka メッセージのパーティション分散用に、タイムスタンプと列値という 2つの新しいディスパッチャ タイプを導入しました。 詳細については[Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 diff --git a/tidb-cloud/releases/tidb-cloud-kernel-versioning.md b/tidb-cloud/releases/tidb-cloud-kernel-versioning.md index 147c7ddcdc4e9..469cb6538a077 100644 --- a/tidb-cloud/releases/tidb-cloud-kernel-versioning.md +++ b/tidb-cloud/releases/tidb-cloud-kernel-versioning.md @@ -31,10 +31,10 @@ TiDB-X-CLOUD.202510.1 各要素の意味は次のとおりです。 -- `YYYYMM` は、カーネルの開発に使用されたベースラインコードブランチを示します。たとえば、`202510` はベースラインブランチが 2025 年 10 月に作成されたことを意味します。これは、カーネルバージョンのリリース時期を示すものではありません。 +- `YYYYMM` は、カーネルの開発に使用されたベースラインコードブランチを示します。たとえば、`202510` はベースラインブランチが 2025年 10月に作成されたことを意味します。これは、カーネルバージョンのリリース時期を示すものではありません。 - `x` は、そのベースラインブランチに対するパッチリリース番号を示します。 -たとえば、`TiDB-X-CLOUD.202510.1` は、そのカーネルが 2025 年 10 月に作成されたブランチに基づいており、そのブランチからビルドされた最初のパッチリリースであることを示します。 +たとえば、`TiDB-X-CLOUD.202510.1` は、そのカーネルが 2025年 10月に作成されたブランチに基づいており、そのブランチからビルドされた最初のパッチリリースであることを示します。 カーネルの開発スケジュールとリリーススケジュールは独立しているため、カーネルバージョンはベースラインブランチの作成から数か月後にリリースされる場合があります。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index cdb8be7c689aa..ff9c87a24b0ca 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -20,7 +20,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', これにより、DB User、SQL type、DB、table、SQL digest などの複数の次元で、SQL ステートメントの RU 消費量、レイテンシー、実行回数を分析できるようになりました。さらに、主な要因をひと目で確認できるため、高いリソース消費や処理遅延の原因を特定しやすくなります。 - 現在、この機能はパブリックプレビュー段階であり、8 月 19 日以降に作成された一部の TiDB Cloud Premium インスタンスでのみ利用できます。 + 現在、この機能はパブリックプレビュー段階であり、8月 19日以降に作成された一部の TiDB Cloud Premium インスタンスでのみ利用できます。 詳細については、[Statement Insight (PREVIEW)](https://docs.pingcap.com/tidbcloud/statement-insight/?plan=premium) を参照してください。 @@ -88,9 +88,9 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - TiDB Cloud Premium インスタンスの自動バックアップに **Custom Retention Mode** を導入しました。 - TiDB Cloud Premium では、2 つの自動バックアップモードを利用できるようになりました。 + TiDB Cloud Premium では、2つの自動バックアップモードを利用できるようになりました。 - - **Custom Retention Mode:** 保持期間を 3 日から 33 日まで指定し、日次スナップショットを作成するタイミングを選択できます。 + - **Custom Retention Mode:** 保持期間を 3日から 33日まで指定し、日次スナップショットを作成するタイミングを選択できます。 - **Standard Bundle Mode:** PITR、時間単位のスナップショット、および日次スナップショットに対する従来のデフォルト自動バックアップ設定を維持します。 詳細については、[Automatic backup modes](/tidb-cloud/premium/backup-and-restore-premium.md#automatic-backup-modes) を参照してください。 @@ -231,7 +231,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - Alibaba Cloud: `Singapore (ap-southeast-1)` および `Tokyo (ap-northeast-1)` - この機能は、1 分単位で RU 消費量が上位の SQL ステートメントを表示し、最もリソースを消費するクエリをすばやく特定してコスト削減に役立てることができます。 + この機能は、1分単位で RU 消費量が上位の SQL ステートメントを表示し、最もリソースを消費するクエリをすばやく特定してコスト削減に役立てることができます。 この機能は段階的に展開されています。早期アクセスについては [support@pingcap.com](mailto:support@pingcap.com) までお問い合わせください。 @@ -248,7 +248,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - TiDB Cloud Lake がパブリックプレビューになりました。 - TiDB Cloud Lake は、モダンな分析および AI 指向のデータワークフロー向けの、TiDB Cloud におけるクラウドネイティブな分析ウェアハウスです。弾力的なウェアハウス、ANSI SQL 分析、オブジェクトストレージ、全文検索、ベクトル検索、地理空間分析を 1 つのマネージドサービスで提供し、個別の分析インフラを管理することなく、構造化データおよび半構造化データを分析できるよう支援します。 + TiDB Cloud Lake は、モダンな分析および AI 指向のデータワークフロー向けの、TiDB Cloud におけるクラウドネイティブな分析ウェアハウスです。弾力的なウェアハウス、ANSI SQL 分析、オブジェクトストレージ、全文検索、ベクトル検索、地理空間分析を 1つのマネージドサービスで提供し、個別の分析インフラを管理することなく、構造化データおよび半構造化データを分析できるよう支援します。 このパブリックプレビューでは、弾力的なウェアハウスで SQL 分析を実行し、組み込みの検索機能を BI、ログ分析、セマンティック検索、その他のモダンな分析および AI のユースケースに活用できます。 @@ -363,7 +363,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - **TiDB Cloud Starter** - - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で[全文検索](https://docs.pingcap.com/ai/vector-search-full-text-search-python/)(パブリックプレビュー) 用の新しい AWS リージョンが 2 つ追加されました: `Tokyo (ap-northeast-1)`と`Oregon (us-west-2)` 。この機能は、以下の AWS リージョンで利用可能になりました。 + - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で[全文検索](https://docs.pingcap.com/ai/vector-search-full-text-search-python/)(パブリックプレビュー) 用の新しい AWS リージョンが 2つ追加されました: `Tokyo (ap-northeast-1)`と`Oregon (us-west-2)` 。この機能は、以下の AWS リージョンで利用可能になりました。 - `Tokyo (ap-northeast-1)` - `Oregon (us-west-2)` diff --git a/tidb-cloud/releases/tidb-x-cloud.202510.1.md b/tidb-cloud/releases/tidb-x-cloud.202510.1.md index 6d533666d2d27..356dddb61f3ca 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202510.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202510.1.md @@ -15,7 +15,7 @@ summary: TiDB-X-CLOUD.202510.1 カーネルの機能について説明します `TiDB-X-CLOUD.202510.1` では、次のようになります。 -- `202510` は、このカーネルバージョンのベースラインコードブランチが 2025 年 10 月に作成されたことを示しており、リリース日とは異なります。 +- `202510` は、このカーネルバージョンのベースラインコードブランチが 2025年 10月に作成されたことを示しており、リリース日とは異なります。 - `1` は、`TiDB-X-CLOUD.202510` ベースラインブランチからビルドされた最初のパッチリリースであることを示します。 `TiDB-X-CLOUD.202510.1` カーネルは [TiDB v8.5.0](https://docs.pingcap.com/tidb/stable/release-8.5.0/) カーネルをベースとしており、TiDB v8.5.0 で導入された機能と改善の大部分を含んでいます。 @@ -44,7 +44,7 @@ summary: TiDB-X-CLOUD.202510.1 カーネルの機能について説明します [`SHOW TABLE DISTRIBUTION`](https://docs.pingcap.com/tidbcloud/sql-statement-show-table-distribution/?plan=premium) ステートメントを使用して、特定のテーブルのデータがすべての TiKV ノードにどのように分散されているかを確認できるようになりました。データ分散が不均衡な場合は、[`DISTRIBUTE TABLE`](https://docs.pingcap.com/tidbcloud/sql-statement-distribute-table/?plan=premium) ステートメントを使用して、テーブルのデータを再分散（実験的）し、負荷分散を改善できます。 - 特定のテーブルのデータ再分散は、タイムアウト制限のある 1 回限りのタスクであることに注意してください。分散タスクがタイムアウトまでに完了しない場合、自動的に終了します。 + 特定のテーブルのデータ再分散は、タイムアウト制限のある 1回限りのタスクであることに注意してください。分散タスクがタイムアウトまでに完了しない場合、自動的に終了します。 詳細は、[ドキュメント](https://docs.pingcap.com/tidbcloud/sql-statement-distribute-table/?plan=premium) を参照してください。 diff --git a/tidb-cloud/scale-tidb-cluster.md b/tidb-cloud/scale-tidb-cluster.md index b75f48a358264..0df919027ca18 100644 --- a/tidb-cloud/scale-tidb-cluster.md +++ b/tidb-cloud/scale-tidb-cluster.md @@ -62,7 +62,7 @@ TiDB、TiKV、またはTiFlashノードの vCPU と RAM を増減できます。 > - AWS でホストされ、2022/12/31 以降に作成されています。 > - Google Cloud でホストされ、2023/04/26 以降に作成されています。 > - Azure でホストされます。 -> - AWS では、vCPU と RAM の変更にクールダウン期間があります。TiDB クラスターが AWS でホストされている場合、TiKV またはTiFlashの vCPU と RAM を変更した後、再度変更するには少なくとも 6 時間待つ必要があります。 +> - AWS では、vCPU と RAM の変更にクールダウン期間があります。TiDB クラスターが AWS でホストされている場合、TiKV またはTiFlashの vCPU と RAM を変更した後、再度変更するには少なくとも 6時間待つ必要があります。 > - vCPUを減らす前に、TiKVまたはTiFlashの現在のノードストレージが、対象のvCPUの最大ノードストレージを超えていないことを確認してください。詳細は[TiKVノードストレージ](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)と[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)を参照してください。いずれかのコンポーネントの現在のストレージが上限を超えている場合は、vCPUを減らすことはできません。 TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更するには、次の手順を実行します。 @@ -90,7 +90,7 @@ TiKV またはTiFlashのストレージを増やすことができます。 > **Warning:** > > - 実行中のクラスターの場合、AWS、Azure、Google Cloud では、インプレースストレージ容量のダウングレードは許可されません。 -> - AWS と Azure では、ストレージ変更のクールダウン期間があります。TiDB クラスターが AWS または Azure でホストされている場合、TiKV またはTiFlashのストレージ、または vCPU と RAM を変更した後、再度変更するには少なくとも 6 時間待つ必要があります。 +> - AWS と Azure では、ストレージ変更のクールダウン期間があります。TiDB クラスターが AWS または Azure でホストされている場合、TiKV またはTiFlashのストレージ、または vCPU と RAM を変更した後、再度変更するには少なくとも 6時間待つ必要があります。 TiKV またはTiFlashのストレージを変更するには、次の手順を実行します。 diff --git a/tidb-cloud/select-cluster-tier.md b/tidb-cloud/select-cluster-tier.md index b8ca7445ec1cd..02668e939d4f6 100644 --- a/tidb-cloud/select-cluster-tier.md +++ b/tidb-cloud/select-cluster-tier.md @@ -51,7 +51,7 @@ TiDB Cloud Starterは、フルマネージド型のマルチテナント対応Ti TiDB Cloudでは、組織ごとにデフォルトで最大5つのTiDB Cloud Starterインスタンスを無料で作成できます。それ以上のTiDB Cloud Starterインスタンスを作成するには、クレジットカードを追加して利用限度額を指定する必要があります。 -組織内の最初の 5 つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 +組織内の最初の 5つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 - 行ベースストレージ：5 GiB - カラム型ストレージ：5 GiB @@ -69,7 +69,7 @@ TiDB Cloudの各組織につき、最大 5[支店](/tidb-cloud/branch-overview.m TiDB Cloudの有料組織ごとに、合計で最大100個のTiDB Cloud Starterインスタンスとブランチを作成できます。各ブランチは個別のインスタンスとしてカウントされます。 -エージェントプラットフォームや、多数のインスタンスとブランチを必要とするその他のサービスを構築する有料組織向けに、 TiDB Cloud は**Instance Capacity Plan**を提供しています。このプランでは、有料のTiDB Cloud組織は 5 つ以上のブランチを作成でき、 TiDB Cloud Starter のインスタンスとブランチの 100 個という制限を受けません。インスタンス容量プランの詳細と申し込みについては、 [申込書](https://www.pingcap.com/programs/agentic-ai-instance-capacity)にご記入ください。 +エージェントプラットフォームや、多数のインスタンスとブランチを必要とするその他のサービスを構築する有料組織向けに、 TiDB Cloud は**Instance Capacity Plan**を提供しています。このプランでは、有料のTiDB Cloud組織は 5つ以上のブランチを作成でき、 TiDB Cloud Starter のインスタンスとブランチの 100 個という制限を受けません。インスタンス容量プランの詳細と申し込みについては、 [申込書](https://www.pingcap.com/programs/agentic-ai-instance-capacity)にご記入ください。 TiDB Cloudインスタンス容量プランの申請が承認されると、メールで通知が届きます。 diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index 21e0b3ddce48a..e15f2c80906c4 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -429,7 +429,7 @@ ticloud serverless export cancel -c -e - **TiDB Cloud Starter**: - - 使用制限を 0 に設定すると、エクスポート速度は最大 25 MiB/s になります。 + - 使用制限を0に設定すると、エクスポート速度は最大 25 MiB/s になります。 - 支出限度額が 0 より大きい場合、エクスポート速度は最大 100 MiB/s になります。 - **TiDB Cloud Essential** : 最大 100 MiB/秒。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index c69f949f0f8ab..89a18316e2bdb 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -18,7 +18,7 @@ TiDB Cloud Starterは、お客様と組織に完全なHTAP機能を備えたTiDB ### TiDB Cloud Starter とTiDB Cloud Serverless の関係は何ですか? {#what-is-the-relationship-between-tidb-cloud-starter-and-tidb-cloud-serverless} -TiDB Cloud Starter は、2025 年 8 月 12 日よりTiDB Cloud Serverless の新しい名前になります。 +TiDB Cloud Starter は、2025年 8月 12日よりTiDB Cloud Serverless の新しい名前になります。 Starter に名前が変更される前、 TiDB Cloudの Serverless 層は何千人もの開発者のエントリ ポイントとして機能し、自動的にスケーリングされ、数秒で起動し、十分な無料割り当てを超えるまでコストがかからない、本番環境対応のデータベースを提供していました。 @@ -29,7 +29,7 @@ Starter に名前が変更される前、 TiDB Cloudの Serverless 層は何千 - 行ベースと列ベースの両方のストレージを備えた完全に管理されたデータベースで、ハイブリッド OLTP および OLAP ワークロードに最適です。 - 自動かつリクエスト主導型のスケーリング。容量計画や手動の調整は必要ありません。 - ベクトル検索とフルテキスト検索が組み込まれており、GenAI 検索、チャットボット、その他の AI アプリケーションを強化します。 -- 組織ごとに最大 5 つのクラスターまで、月間クォータが常時無料です (5 GiB の行データ + 5 GiB の列データ + クラスターあたり 5,000 万[RU](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) )。 +- 組織ごとに最大 5つのクラスターまで、月間クォータが常時無料です (5 GiB の行データ + 5 GiB の列データ + クラスターあたり 5,000 万[RU](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) )。 ### TiDB Cloud Starter を使い始めるにはどうすればよいですか? {#how-do-i-get-started-with-tidb-cloud-starter} @@ -96,7 +96,7 @@ TiDB Cloud Starterは従量課金モデルを採用しており、ストレー ### TiDB Cloud Starter には無料プランはありますか? {#is-there-any-free-plan-available-for-tidb-cloud-starter} -組織内の最初の 5 つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 +組織内の最初の 5つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 - 行ベースのストレージ: 5 GiB - 列指向ストレージ: 5 GiB @@ -154,7 +154,7 @@ TiDB Cloud Starter の列指向ストレージの料金は、行指向ストレ TiDB Cloud Starterの列指向ストレージは、追加のレプリカが必要となり、データレプリケーションに必要なストレージとリソースが増えるため、追加コストが発生します。ただし、分析クエリを実行する際には、列指向ストレージがコスト効率が高くなります。 -TPC-H ベンチマーク テストによると、列ベースのストレージで分析クエリを実行するコストは、行ベースのストレージを使用する場合のコストの約 3 分の 1 になります。 +TPC-H ベンチマーク テストによると、列ベースのストレージで分析クエリを実行するコストは、行ベースのストレージを使用する場合のコストの約3分の 1 になります。 したがって、追加のレプリカによる初期コストは発生する可能性がありますが、分析時の計算コストが削減されるため、特定のユースケースではより費用対効果の高いものになる可能性があります。特に分析ニーズが高いユーザーにとって、列指向ストレージはコストを大幅に削減し、大幅なコスト削減の機会を提供します。 diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index 1185adbf4e0d3..8a72726fa5ff1 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -39,7 +39,7 @@ TiDB Cloudは、ゾーン別高可用性とリージョン別高可用性によ - **ゾーン高可用性**：このオプションでは、すべてのノードを単一の可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。ゾーン間でアプリケーションレベルの冗長性を必要とせずに高可用性を確保するため、単一ゾーン内での低レイテンシーを優先するアプリケーションに適しています。詳細については、[ゾーン別高可用性アーキテクチャ](#zonal-high-availability-architecture)を参照してください。 -- **地域別高可用性 (PREVIEW)** : このオプションでは、ノードを複数の可用性ゾーンに分散し、インフラストラクチャの分離と冗長性を最大限に高めます。最高レベルの可用性を提供しますが、ゾーン間でアプリケーションレベルの冗長性が必要です。ゾーン内のインフラストラクチャ障害に対する最大限の可用性保護が必要な場合は、このオプションを選択することをお勧めします。レイテンシーが増加し、ゾーン間のデータ転送料金が発生する可能性があることに注意してください。この機能は、3 つ以上の可用性ゾーンを持つリージョンで利用できます。詳細については、[地域的な高可用性アーキテクチャ](#regional-high-availability-architecture)を参照してください。 +- **地域別高可用性 (PREVIEW)** : このオプションでは、ノードを複数の可用性ゾーンに分散し、インフラストラクチャの分離と冗長性を最大限に高めます。最高レベルの可用性を提供しますが、ゾーン間でアプリケーションレベルの冗長性が必要です。ゾーン内のインフラストラクチャ障害に対する最大限の可用性保護が必要な場合は、このオプションを選択することをお勧めします。レイテンシーが増加し、ゾーン間のデータ転送料金が発生する可能性があることに注意してください。この機能は、3つ以上の可用性ゾーンを持つリージョンで利用できます。詳細については、[地域的な高可用性アーキテクチャ](#regional-high-availability-architecture)を参照してください。 ## ゾーン別高可用性アーキテクチャ {#zonal-high-availability-architecture} diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index 42aa157a89ac4..1f994d19d6089 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -27,7 +27,7 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを > **Note:** > -> [AWS Global Acceleratorの制限](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-how-it-works.html#about-idle-timeout)のため、AWS のパブリックエンドポイント接続のアイドルタイムアウトは 340 秒です。同じ理由から、TCP キープアライブパケットを使用して接続を維持することはできません。 +> [AWS Global Acceleratorの制限](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-how-it-works.html#about-idle-timeout)のため、AWS のパブリックエンドポイント接続のアイドルタイムアウトは 340秒です。同じ理由から、TCP キープアライブパケットを使用して接続を維持することはできません。 ### 暗号化 {#encryption} @@ -66,7 +66,7 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを TiDB Cloudでは、組織ごとに最大5つのクラスター（デフォルトでは[無料のTiDB Cloud Starterクラスター](/tidb-cloud/select-cluster-tier.md#starter)を作成できます。TiDB Cloud Starterクラスターをさらに作成するには、クレジットカード情報と使用量に応じた[毎月の支出限度額を設定する](/tidb-cloud/manage-serverless-spend-limit.md)追加する必要があります。 -組織内の最初の 5 つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 +組織内の最初の 5つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 - 行ベースのストレージ: 5 GiB - 列指向ストレージ: 5 GiB 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 170d990574013..cc55211619654 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 @@ -67,8 +67,8 @@ Alibaba Cloud アカウント ID とアベイラビリティーゾーンを表 Kafka VPC には次のものが必要です。 -- ブローカー用のプライベート vSwitch が 3 つ (AZ ごとに 1 つ)。 -- 任意の AZ にパブリック vSwitch を 1 つ、インターネットに接続できる Bastion ノードを 1 つ、プライベート vSwitch を 3 つ配置することで、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の Bastion ノードを配置することもできます。 +- ブローカー用のプライベート vSwitch が 3つ (AZ ごとに 1つ)。 +- 任意の AZ にパブリック vSwitch を 1つ、インターネットに接続できる Bastion ノードを 1つ、プライベート vSwitch を 3つ配置することで、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の Bastion ノードを配置することもできます。 Kafka VPC を作成するには、次の手順を実行します。 @@ -110,7 +110,7 @@ Kafka VPC を作成するには、次の手順を実行します。 **2.2. ブローカーノードを作成する** -[ECSコンソール](https://ecs.console.alibabacloud.com/home#/)に進みます。vSwitch に 3 つのブローカー ノード (AZ ごとに 1 つ) を作成します。 +[ECSコンソール](https://ecs.console.alibabacloud.com/home#/)に進みます。vSwitch に 3つのブローカー ノード (AZ ごとに 1つ) を作成します。 - vSwitch `broker-ap-southeast-1a`のブローカー 1 @@ -184,10 +184,10 @@ Kafka VPC を作成するには、次の手順を実行します。 各ノードはブローカーとコントローラーの役割を担います。各ブローカーに対して以下の操作を実行してください。 -1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 +1. `listeners`項目の場合、3つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 @@ -502,7 +502,7 @@ Kafka クラスターが TiDB クラスターと同じリージョンおよび A listener.security.protocol.map=...,EXTERNAL:PLAINTEXT ``` -3. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +3. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 #### 2. 内部ネットワークで外部リスナーの設定をテストする {#2-test-external-listener-settings-in-your-internal-network} @@ -547,7 +547,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null ロードバランサーを設定するには、次の手順を実行します。 -1. [サーバーグループ](https://slb.console.alibabacloud.com/nlb/ap-southeast-1/server-groups)に進み、4 つのサーバーグループを作成します。 +1. [サーバーグループ](https://slb.console.alibabacloud.com/nlb/ap-southeast-1/server-groups)に進み、4つのサーバーグループを作成します。 - ブートストラップサーバーグループ @@ -593,7 +593,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - **Instance Name**: `kafka-nlb` - **Create Now**をクリックしてロードバランサーを作成します。 -3. 作成したロード バランサーを見つけて、 **Create Listener**をクリックして 4 つの TCP リスナーを作成します。 +3. 作成したロード バランサーを見つけて、 **Create Listener**をクリックして 4つの TCP リスナーを作成します。 - ブートストラップサーバーグループ @@ -661,6 +661,6 @@ TiDB Cloudでプライベート リンク接続を作成するには、次の手 ## ステップ4. Kafka設定内の一意の名前プレースホルダーを置き換える {#step-4-replace-the-unique-name-placeholder-in-kafka-configuration} 1. Kafka ブローカー ノードに戻り、各ブローカーの`advertised.listeners`構成内の`unique_name`プレースホルダーを、前の手順で取得した実際の一意の名前に置き換えます。 -2. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +2. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 これで、このプライベート リンク接続と 9092 をブートストラップ ポートとして使用し、 TiDB Cloudから Kafka クラスターに接続できるようになります。 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 566b129cb7f47..2735b7bde4fdf 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 @@ -61,8 +61,8 @@ AWS アカウント ID とアベイラビリティーゾーンを表示するに Kafka VPC には次のものが必要です。 -- ブローカー用のプライベート サブネットが 3 つ (AZ ごとに 1 つ)。 -- 任意の AZ に 1 つのパブリックサブネットがあり、インターネットに接続できる要塞ノードと 3 つのプライベートサブネットがあるため、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の要塞ノードが必要になる場合があります。 +- ブローカー用のプライベート サブネットが 3つ (AZ ごとに 1つ)。 +- 任意の AZ に 1つのパブリックサブネットがあり、インターネットに接続できる要塞ノードと 3つのプライベートサブネットがあるため、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の要塞ノードが必要になる場合があります。 サブネットを作成する前に、AZ IDとAZ名のマッピングに基づいてAZ内にサブネットを作成します。以下のマッピングを例に挙げます。 @@ -163,7 +163,7 @@ Kafka VPC を作成するには、次の手順を実行します。 **2.2. ブローカーノードを作成する** -[EC2 リストページ](https://console.aws.amazon.com/ec2/home#Instances:)に進みます。ブローカー サブネットに、各 AZ に 1 つずつ、合計 3 つのブローカー ノードを作成します。 +[EC2 リストページ](https://console.aws.amazon.com/ec2/home#Instances:)に進みます。ブローカー サブネットに、各 AZ に 1つずつ、合計3つのブローカー ノードを作成します。 - サブネット`broker-usw2-az1`のブローカー 1 @@ -261,10 +261,10 @@ Kafka VPC を作成するには、次の手順を実行します。 各ノードはブローカーとコントローラーの役割を担います。各ブローカーに対して以下の操作を実行してください。 -1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 +1. `listeners`項目の場合、3つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 @@ -583,7 +583,7 @@ Kafka クラスターが TiDB クラスターと同じリージョンおよび A listener.security.protocol.map=...,EXTERNAL:PLAINTEXT ``` -3. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +3. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 #### 2. 内部ネットワークで外部リスナーの設定をテストする {#2-test-external-listener-settings-in-your-internal-network} @@ -628,7 +628,7 @@ b3.usw2-az3.unique_name.aws.plc.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: ロードバランサーを設定するには、次の手順を実行します。 -1. [対象グループ](https://console.aws.amazon.com/ec2/home#CreateTargetGroup:)に進み、4 つのターゲット グループを作成します。 +1. [対象グループ](https://console.aws.amazon.com/ec2/home#CreateTargetGroup:)に進み、4つのターゲット グループを作成します。 - ブートストラップターゲットグループ @@ -739,6 +739,6 @@ TiDB Cloudでプライベート リンク接続を作成するには、次の手 ## ステップ4. Kafka設定内の一意の名前プレースホルダーを置き換える {#step-4-replace-the-unique-name-placeholder-in-kafka-configuration} 1. Kafka ブローカー ノードに戻り、各ブローカーの`advertised.listeners`構成内の`unique_name`プレースホルダーを、前の手順で取得した実際の一意の名前に置き換えます。 -2. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +2. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 これで、このプライベート リンク接続と 9092 をブートストラップ ポートとして使用し、 TiDB Cloudから Kafka クラスターに接続できるようになります。 diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index 96ce789f0dd37..4468b91dbb81c 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -60,8 +60,8 @@ ticloud serverless private-link-connection zones --cluster-id > **Note:** > - > - TiDB Cloud Essential インスタンスが 2026 年 7 月 1 日以降に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント専用モードでプライベートリンク接続が作成されます。このモードでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンプライベートエンドポイントを使用するため、接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がありません。 - > - TiDB Cloud Essential インスタンスが 2026 年 7 月 1 日より前に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント共有モードでプライベートリンク接続が作成されます。このモードでは、同じ AWS Region 内の複数の {{{ .essential }}} インスタンスで 1 つのプライベートエンドポイントを共有できます。 + > - TiDB Cloud Essential インスタンスが 2026年 7月 1日以降に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント専用モードでプライベートリンク接続が作成されます。このモードでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンプライベートエンドポイントを使用するため、接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がありません。 + > - TiDB Cloud Essential インスタンスが 2026年 7月 1日より前に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント共有モードでプライベートリンク接続が作成されます。このモードでは、同じ AWS Region 内の複数の {{{ .essential }}} インスタンスで 1つのプライベートエンドポイントを共有できます。 4. **[外部サービス用プライベートエンドポイントの作成]**ダイアログで、必要な情報を入力します。 @@ -108,8 +108,8 @@ Amazon MSK プロビジョニングプライベートリンク接続を作成す > **Note:** > - > - TiDB Cloud Essential インスタンスが 2026 年 7 月 1 日以降に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント専用モードでプライベートリンク接続が作成されます。このモードでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンプライベートエンドポイントを使用するため、接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がありません。 - > - TiDB Cloud Essential インスタンスが 2026 年 7 月 1 日より前に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント共有モードでプライベートリンク接続が作成されます。このモードでは、同じ AWS Region 内の複数の {{{ .essential }}} インスタンスで 1 つのプライベートエンドポイントを共有できます。 + > - TiDB Cloud Essential インスタンスが 2026年 7月 1日以降に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント専用モードでプライベートリンク接続が作成されます。このモードでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンプライベートエンドポイントを使用するため、接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がありません。 + > - TiDB Cloud Essential インスタンスが 2026年 7月 1日より前に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント共有モードでプライベートリンク接続が作成されます。このモードでは、同じ AWS Region 内の複数の {{{ .essential }}} インスタンスで 1つのプライベートエンドポイントを共有できます。 4. **[外部サービス用プライベートエンドポイントの作成]**ダイアログで、必要な情報を入力します。 @@ -150,8 +150,8 @@ ticloud serverless private-link-connection zones --cluster-id > **Note:** > - > - TiDB Cloud Essential インスタンスが 2026 年 7 月 1 日以降に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント専用モードでプライベートリンク接続が作成されます。このモードでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンプライベートエンドポイントを使用するため、接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がありません。 - > - TiDB Cloud Essential インスタンスが 2026 年 7 月 1 日より前に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント共有モードでプライベートリンク接続が作成されます。このモードでは、同じ Alibaba Cloud Region 内の複数の {{{ .essential }}} インスタンスで 1 つのプライベートエンドポイントを共有できます。 + > - TiDB Cloud Essential インスタンスが 2026年 7月 1日以降に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント専用モードでプライベートリンク接続が作成されます。このモードでは、各 {{{ .essential }}} インスタンスが独自のスタンドアロンプライベートエンドポイントを使用するため、接続時に[アカウントプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を含める必要がありません。 + > - TiDB Cloud Essential インスタンスが 2026年 7月 1日より前に作成されている場合、**Create Private Endpoint for External Services** をクリックすると、エンドポイント共有モードでプライベートリンク接続が作成されます。このモードでは、同じ Alibaba Cloud Region 内の複数の {{{ .essential }}} インスタンスで 1つのプライベートエンドポイントを共有できます。 4. **[外部サービス用プライベートエンドポイントの作成]**ダイアログで、必要な情報を入力します。 diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md b/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md index d779da6f44eeb..a51ce8ec93456 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md @@ -49,7 +49,7 @@ Google Cloud Private Service Connect のアーキテクチャは以下のとお - 各TiDBクラスタは、最大10個のエンドポイントからの接続を処理できます。 - 各Google Cloudプロジェクトは、最大10個のエンドポイントをTiDBクラスタに接続できます。 - 2025年8月12日以降、Google Cloud上のTiDB Cloud Dedicatedクラスターでリージョンごとに作成できるGoogle Private Service Connect（PSC）接続の最大数は、NATサブネットCIDRブロックサイズによって異なります。 - - `/20` : 地域ごとに最大 7 つの PSC 接続 + - `/20` : 地域ごとに最大 7つの PSC 接続 - `/19` : 地域ごとに最大 23 の PSC 接続 - `/18` : 地域ごとに最大55のPSC接続 - `/17` : 地域ごとに最大 119 の PSC 接続 diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index 2aefba577a072..efc9f093a55cd 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -67,7 +67,7 @@ AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっている > **Note:** > -> 2023 年 3 月 28 日以降に作成されたTiDB Cloud Dedicated クラスターごとに、クラスターの作成後 3 ～ 4 分後に対応するエンドポイント サービスが自動的に作成されます。 +> 2023年 3月 28日以降に作成されたTiDB Cloud Dedicated クラスターごとに、クラスターの作成後 3 ～ 4分後に対応するエンドポイント サービスが自動的に作成されます。 `TiDB Private Link Service is ready`メッセージが表示された場合、対応するエンドポイントサービスは準備完了です。エンドポイントを作成するには、以下の情報を提供してください。 @@ -140,7 +140,7 @@ AWS マネジメントコンソールを使用して VPC インターフェイ > **Tip:** > -> プライベート エンドポイント接続は、次の 2 つのページで表示および管理できます。 +> プライベート エンドポイント接続は、次の2つのページで表示および管理できます。 > > - クラスター レベルの**Networking**ページ: 組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Settings** > **Networking**をクリックします。 > - プロジェクト レベルの**Network Access**ページ: 組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、**Project view** タブをクリックして対象のプロジェクトを見つけ、そのプロジェクトの をクリックし、**Project Settings** の下にある **Network Access** をクリックします。 @@ -179,7 +179,7 @@ AWS マネジメントコンソールでプライベート DNS を有効にす プライベート エンドポイント接続を承認すると、接続ダイアログにリダイレクトされます。 -1. プライベート エンドポイントの接続ステータスが**System Checking**から**Active**に変わるまで待ちます (約 5 分)。 +1. プライベート エンドポイントの接続ステータスが**System Checking**から**Active**に変わるまで待ちます (約5分)。 2. **Connect With**ドロップダウンリストで、希望する接続方法を選択します。対応する接続文字列がダイアログの下部に表示されます。 3. 接続文字列を使用してクラスターに接続します。 @@ -204,9 +204,9 @@ AWS マネジメントコンソールでプライベート DNS を有効にす プライベート エンドポイント サービスの可能なステータスについては、次のように説明されます。 -- **Creating**: エンドポイント サービスを作成中です。これには 3 ～ 5 分かかります。 +- **Creating**: エンドポイント サービスを作成中です。これには 3 ～ 5分かかります。 - **Active**: プライベート エンドポイントが作成されたかどうかに関係なく、エンドポイント サービスが作成されます。 -- **Deleting**: エンドポイント サービスまたはクラスターを削除中です。これには 3 ～ 5 分かかります。 +- **Deleting**: エンドポイント サービスまたはクラスターを削除中です。これには 3 ～ 5分かかります。 ## トラブルシューティング {#troubleshooting} diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index f1ef56d0c832a..50934b23c747d 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -82,7 +82,7 @@ VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジ - VPC ID - VPC CIDR - このような情報は、 [AWS マネジメントコンソール](https://console.aws.amazon.com/)の VPC 詳細ページから取得できます。TiDB Cloud は、同じリージョン内または 2 つの異なるリージョンの VPC 間の VPC ピアリングの作成をサポートしています。 + このような情報は、 [AWS マネジメントコンソール](https://console.aws.amazon.com/)の VPC 詳細ページから取得できます。TiDB Cloud は、同じリージョン内または 2つの異なるリージョンの VPC 間の VPC ピアリングの作成をサポートしています。 ![VPC peering](/media/tidb-cloud/vpc-peering/vpc-peering-creating-infos.png) @@ -112,7 +112,7 @@ VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジ - VPC ID - VPC CIDR - このような情報は、 [AWS マネジメントコンソール](https://console.aws.amazon.com/)の VPC 詳細ページから取得できます。TiDB Cloud は、同じリージョン内または 2 つの異なるリージョンの VPC 間の VPC ピアリングの作成をサポートしています。 + このような情報は、 [AWS マネジメントコンソール](https://console.aws.amazon.com/)の VPC 詳細ページから取得できます。TiDB Cloud は、同じリージョン内または 2つの異なるリージョンの VPC 間の VPC ピアリングの作成をサポートしています。 ![VPC peering](/media/tidb-cloud/vpc-peering/vpc-peering-creating-infos.png) @@ -321,7 +321,7 @@ gcloud beta compute networks peerings create --project **Tip:** > @@ -159,7 +159,7 @@ multi-VPC connectivity は、MSK クラスターへの PrivateLink アクセス 1. [Amazon MSK コンソール](https://console.aws.amazon.com/msk/)で、MSK クラスターの **Properties** タブに移動します。**Network settings** > **Multi-VPC connectivity** で、[multi-VPC connectivity を有効にします](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-turn-on.html)。 2. VPC connectivity のクライアント認証は **SASL/SCRAM** 認証のみを使用するように設定します（TiDB Cloud 接続には IAM および mutual TLS (mTLS) 認証は不要です）。 - クラスター更新が完了するまで待ちます。この操作には通常約 40 ～ 60 分かかります。進行状況は MSK コンソールの **Cluster operations** タブで確認できます。クラスターのステータスが **Active** に戻るまで待ってください。 + クラスター更新が完了するまで待ちます。この操作には通常約 40 ～ 60分かかります。進行状況は MSK コンソールの **Cluster operations** タブで確認できます。クラスターのステータスが **Active** に戻るまで待ってください。 3. 更新完了後、次の項目を確認します。 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 9ff0ba3f7dbeb..d7da34274038a 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 @@ -19,7 +19,7 @@ aliases: ['/ja/tidbcloud/setup-self-hosted-kafka-private-link-service'] ![Connect to AWS Self-Hosted Kafka Private Link Service](/media/tidb-cloud/changefeed/connect-to-aws-self-hosted-kafka-privatelink-service.jpeg) -このドキュメントでは、AWS の 3 つのアベイラビリティゾーン (AZ) にデプロイされた Kafka Private Link サービスへの接続例を示します。同様のポートマッピング原則に基づいて他の構成も可能ですが、このドキュメントでは Kafka Private Link サービスの基本的な設定手順について説明します。本番環境では、運用の保守性と可観測性を強化した、より耐障害性の高い Kafka Private Link サービスの使用をお勧めします。 +このドキュメントでは、AWS の 3つのアベイラビリティゾーン (AZ) にデプロイされた Kafka Private Link サービスへの接続例を示します。同様のポートマッピング原則に基づいて他の構成も可能ですが、このドキュメントでは Kafka Private Link サービスの基本的な設定手順について説明します。本番環境では、運用の保守性と可観測性を強化した、より耐障害性の高い Kafka Private Link サービスの使用をお勧めします。 ## 前提条件 {#prerequisites} @@ -98,8 +98,8 @@ aliases: ['/ja/tidbcloud/setup-self-hosted-kafka-private-link-service'] Kafka VPC には次のものが必要です。 -- ブローカー用のプライベート サブネットが 3 つ (AZ ごとに 1 つ)。 -- 任意の AZ に 1 つのパブリックサブネットがあり、インターネットに接続できる要塞ノードと 3 つのプライベートサブネットがあるため、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の要塞ノードが必要になる場合があります。 +- ブローカー用のプライベート サブネットが 3つ (AZ ごとに 1つ)。 +- 任意の AZ に 1つのパブリックサブネットがあり、インターネットに接続できる要塞ノードと 3つのプライベートサブネットがあるため、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の要塞ノードが必要になる場合があります。 サブネットを作成する前に、AZ IDとAZ名のマッピングに基づいてAZ内にサブネットを作成します。以下のマッピングを例に挙げます。 @@ -200,7 +200,7 @@ Kafka VPC を作成するには、次の手順を実行します。 **2.2. ブローカーノードを作成する** -[EC2 リストページ](https://console.aws.amazon.com/ec2/home#Instances:)に進みます。ブローカー サブネットに、各 AZ に 1 つずつ、合計 3 つのブローカー ノードを作成します。 +[EC2 リストページ](https://console.aws.amazon.com/ec2/home#Instances:)に進みます。ブローカー サブネットに、各 AZ に 1つずつ、合計3つのブローカー ノードを作成します。 - サブネット`broker-usw2-az1`のブローカー 1 @@ -298,10 +298,10 @@ Kafka VPC を作成するには、次の手順を実行します。 各ノードはブローカーとコントローラーの役割を担います。各ブローカーに対して以下の操作を実行してください。 -1. `listeners`項目の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 +1. `listeners`項目の場合、3つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. **ブローカー**リスナーを 2 つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 + 2. **ブローカー**リスナーを 2つ構成します。`INTERNAL`は内部アクセス用、 `EXTERNAL`はTiDB Cloudからの外部アクセス用です。 2. `advertised.listeners`項目については、次の操作を行います。 @@ -629,7 +629,7 @@ Kafka クラスターが TiDB インスタンスと同じリージョンおよ listener.security.protocol.map=...,EXTERNAL:PLAINTEXT ``` -3. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +3. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 #### 2. 内部ネットワークで外部リスナーの設定をテストする {#2-test-external-listener-settings-in-your-internal-network} @@ -674,7 +674,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E ロードバランサーを設定するには、次の手順を実行します。 -1. [対象グループ](https://console.aws.amazon.com/ec2/home#CreateTargetGroup:)に進み、4 つのターゲット グループを作成します。 +1. [対象グループ](https://console.aws.amazon.com/ec2/home#CreateTargetGroup:)に進み、4つのターゲット グループを作成します。 - ブートストラップターゲットグループ @@ -776,10 +776,10 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E 2. **Configure the changefeed target > Connectivity Method > Private Link**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 - - **Kafka Type**: `3 AZs`。クラスターが同じ 3 つの AZ にデプロイされていることを確認します。 + - **Kafka Type**: `3 AZs`。クラスターが同じ 3つの AZ にデプロイされていることを確認します。 - **Kafka Advertised Listener Pattern**: `abc` 。これは、 [前提条件](#prerequisites)で**Kafka Advertised Listener Pattern**を生成するために使用する一意のランダム文字列と同じです。 - **Endpoint Service Name**: Kafka サービス名。 - - **Bootstrap Ports**: `9092`。背後に専用のブートストラップ ターゲット グループを構成するため、1 つのポートで十分です。 + - **Bootstrap Ports**: `9092`。背後に専用のブートストラップ ターゲット グループを構成するため、1つのポートで十分です。 3. [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)の手順に進みます。 @@ -787,7 +787,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E ## FAQ {#faq} -### 2 つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Link サービスに接続するにはどうすればよいですか? {#how-to-connect-to-the-same-kafka-private-link-service-from-two-different-tidb-cloud-projects} +### 2つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Link サービスに接続するにはどうすればよいですか? {#how-to-connect-to-the-same-kafka-private-link-service-from-two-different-tidb-cloud-projects} このドキュメントに従って最初のプロジェクトからの接続をすでに正常に設定している場合は、次のようにして 2 番目のプロジェクトから同じ Kafka Private Link サービスに接続できます。 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 5a5528d34e2d6..298b3f901bae8 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 @@ -145,9 +145,9 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 1. 3つのノードでKRaft Kafkaクラスターをセットアップします。各ノードはブローカーとコントローラーの両方の役割を果たします。各ブローカーノードに対して、以下の手順を実行します。 - 1. `listeners`を構成します。3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 + 1. `listeners`を構成します。3つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。ブローカーロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーを省略できます。 - 2. 2 つのブローカー リスナーを構成します。内部 Kafka クライアント アクセス用の**INTERNAL**と、 TiDB Cloudからのアクセス用の**EXTERNAL です**。 + 2. 2つのブローカー リスナーを構成します。内部 Kafka クライアント アクセス用の**INTERNAL**と、 TiDB Cloudからのアクセス用の**EXTERNAL です**。 2. `advertised.listeners`については、次の操作を行います。 1. ブローカー ノードの内部 IP アドレスを使用して、各ブローカーの内部アドバタイズ リスナーを構成します。これにより、内部 Kafka クライアントはアドバタイズ アドレスを介してブローカーに接続できるようになります。 @@ -392,7 +392,7 @@ Kafka クラスターが TiDB クラスターと同じリージョンにデプ listener.security.protocol.map=...,EXTERNAL:PLAINTEXT ``` -3. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +3. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 **2. 内部ネットワークで外部リスナーの設定をテストする** @@ -444,13 +444,13 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. - **課題**： `Dynamic` - **Availability zone**: `Zone-redundant` -4. **Backend pools**タブで、次の 3 つのバックエンド プールを追加し、 **Next : Inbound rules**をクリックします。 +4. **Backend pools**タブで、次の3つのバックエンド プールを追加し、 **Next : Inbound rules**をクリックします。 - 名前: `pool1` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-1` - 名前: `pool2` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-2` - 名前: `pool3` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-3` -5. **Inbound rules**タブで、次の 3 つの負荷分散規則を追加します。 +5. **Inbound rules**タブで、次の3つの負荷分散規則を追加します。 1. ルール1 @@ -535,7 +535,7 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. ## FAQ {#faq} -### 2 つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Link サービスに接続するにはどうすればよいですか? {#how-to-connect-to-the-same-kafka-private-link-service-from-two-different-tidb-cloud-projects} +### 2つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Link サービスに接続するにはどうすればよいですか? {#how-to-connect-to-the-same-kafka-private-link-service-from-two-different-tidb-cloud-projects} このドキュメントの手順に従って最初のプロジェクトからの接続をすでに正常に設定している場合は、次のようにして 2 番目のプロジェクトから同じ Kafka Private Link サービスに接続できます。 diff --git a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md index 87522f4013b04..50e4ec8f1a8da 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -14,13 +14,13 @@ summary: このドキュメントでは、Google Cloud でセルフホスト型 3. 各 Kafka ブローカーは、 TiDB Cloud VPC 内の一意のポートにマッピングされます。 4. マッピングを実現するには、Kafka ブートストラップ メカニズムと Google Cloud リソースを活用します。 -Google Cloud でセルフホスト型 Kafka に Private Service Connect を設定するには、次の 2 つの方法があります。 +Google Cloud でセルフホスト型 Kafka に Private Service Connect を設定するには、次の2つの方法があります。 - Private Service Connect（PSC）ポートマッピングメカニズムを使用します。この方法では、静的なポートブローカーマッピング設定が必要です。EXTERNALリスナーとアドバタイズリスナーのグループを追加するには、既存のKafkaクラスターを再構成する必要があります。詳細は[PSC ポート マッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定](#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping)を参照してください。 - [Kafkaプロキシ](https://github.com/grepplabs/kafka-proxy)を使用してください。この方法では、Kafka クライアントと Kafka ブローカー間のプロキシとして、追加の実行プロセスが導入されます。プロキシはポートとブローカーのマッピングを動的に設定し、リクエストを転送します。既存の Kafka クラスターを再設定する必要はありません。詳細は[Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)を参照してください。 -このドキュメントでは、Google Cloud の 3 つのアベイラビリティゾーン（AZ）にデプロイされた Kafka Private Service Connect サービスへの接続例を示します。同様のポートマッピング原則に基づいて他の構成も可能ですが、このドキュメントでは Kafka Private Service Connect サービスの基本的な設定プロセスについて説明します。本番環境では、運用の保守性と可観測性を強化した、より回復力の高い Kafka Private Service Connect サービスの使用を推奨します。 +このドキュメントでは、Google Cloud の 3つのアベイラビリティゾーン（AZ）にデプロイされた Kafka Private Service Connect サービスへの接続例を示します。同様のポートマッピング原則に基づいて他の構成も可能ですが、このドキュメントでは Kafka Private Service Connect サービスの基本的な設定プロセスについて説明します。本番環境では、運用の保守性と可観測性を強化した、より回復力の高い Kafka Private Service Connect サービスの使用を推奨します。 ## 前提条件 {#prerequisites} @@ -75,7 +75,7 @@ PSCポートマッピングメカニズムを使用して、各Kafkaブローカ **1. Kafka VPC をセットアップする** -Kafka クラスターを簡単に構成できるように、Kafka VPC 用に 2 つのサブネット (1 つは Kafka ブローカー用、もう 1 つは要塞ノード用) を作成する必要があります。 +Kafka クラスターを簡単に構成できるように、Kafka VPC 用に 2つのサブネット (1つは Kafka ブローカー用、もう 1つは要塞ノード用) を作成する必要があります。 [Google Cloud コンソール](https://cloud.google.com/cloud-console)に進み、 [VPCネットワーク](https://console.cloud.google.com/networking/networks/list)ページに移動して、次の属性を持つ Kafka VPC を作成します。 @@ -167,9 +167,9 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con 1. 3つのノードでKRaft Kafkaクラスターをセットアップします。各ノードはブローカーとコントローラーの役割を持ちます。各ブローカーに対して、以下の手順を実行します。 - 1. `listeners`の場合、3 つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 + 1. `listeners`の場合、3つのブローカーはすべて同じであり、ブローカーとコントローラーのロールとして機能します。 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 - 2. 2 つの**ブローカー**リスナーを構成します。内部アクセスの場合は INTERNAL、 TiDB Cloudからの外部アクセスの場合は EXTERNAL です。 + 2. 2つの**ブローカー**リスナーを構成します。内部アクセスの場合は INTERNAL、 TiDB Cloudからの外部アクセスの場合は EXTERNAL です。 2. `advertised.listeners`については、次の操作を行います。 1. ブローカー ノードの内部 IP アドレスを使用して、各ブローカーの内部アドバタイズ リスナーを構成します。これにより、内部 Kafka クライアントはアドバタイズ アドレスを介してブローカーに接続できるようになります。 2. TiDB Cloudから取得した**Kafka Advertised Listener Pattern**に基づいて、各ブローカーノードにEXTERNALアドバタイズリスナーを設定することで、TiDB Cloudが複数のブローカーを区別できるようになります。異なるEXTERNALアドバタイズリスナーを設定することで、 TiDB Cloud側のKafkaクライアントはリクエストを適切なブローカーにルーティングできるようになります。 @@ -434,7 +434,7 @@ Kafka クラスターが TiDB クラスターと同じリージョンにデプ listener.security.protocol.map=...,EXTERNAL:PLAINTEXT ``` -3. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 +3. すべてのブローカーを再構成したら、Kafka ブローカーを 1つずつ再起動します。 **2. 内部ネットワークで外部リスナーの設定をテストする** @@ -564,7 +564,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **External IPv4 address**： `Ephemeral` -proxyの設定を容易にするため、インターネットアクセスを有効にしてください。本番環境では**なし**を選択し、任意の方法でノードにログインできます。 - **場所**： `Single zone` - **リージョン**: `us-west1` - - **ゾーン**: ブローカーのゾーンの 1 つを選択します。 + - **ゾーン**: ブローカーのゾーンの 1つを選択します。 - **Autoscaling mode**: `Off` - **Minimum number of instances**: `1` - **Maximum number of instances**: `1` 。Kafkaプロキシはクラスターモードをサポートしていないため、デプロイできるインスタンスは1つだけです。各Kafkaプロキシはローカルポートをブローカーのポートにランダムにマッピングするため、プロキシごとにマッピングが異なります。ロードバランサーの背後に複数のKafkaプロキシをデプロイすると、問題が発生する可能性があります。Kafkaクライアントが1つのプロキシに接続し、別のプロキシを経由してブローカーにアクセスすると、リクエストが誤ったブローカーにルーティングされる可能性があります。 @@ -643,7 +643,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **名前**: `kafka-proxy-hc` - **範囲**： `Regional` - **プロトコル**： `TCP` - - **ポート**: `9092` -proxy でブートストラップ ポートの 1 つを選択できます。 + - **ポート**: `9092` -proxy でブートストラップ ポートの 1つを選択できます。 2. [**Private Service Connect** > **PUBLISH SERVICE**](https://console.cloud.google.com/net-services/psc/list/producers)に進みます。 @@ -683,9 +683,9 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが ## FAQ {#faq} -### 2 つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Service Connect サービスに接続するにはどうすればよいですか? {#how-to-connect-to-the-same-kafka-private-service-connect-service-from-two-different-tidb-cloud-projects} +### 2つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Service Connect サービスに接続するにはどうすればよいですか? {#how-to-connect-to-the-same-kafka-private-service-connect-service-from-two-different-tidb-cloud-projects} -すでにこのドキュメントの手順に従って最初のプロジェクトからの接続を正常に設定していて、2 番目のプロジェクトから 2 番目の接続を設定する場合は、次のようにして 2 つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Service Connect サービスに接続できます。 +すでにこのドキュメントの手順に従って最初のプロジェクトからの接続を正常に設定していて、2 番目のプロジェクトから 2 番目の接続を設定する場合は、次のようにして 2つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Service Connect サービスに接続できます。 - PSC ポート マッピングによって Kafka PSC を設定する場合は、次の手順を実行します。 diff --git a/tidb-cloud/size-your-cluster.md b/tidb-cloud/size-your-cluster.md index e8fba22ce549b..8baad99fd07aa 100644 --- a/tidb-cloud/size-your-cluster.md +++ b/tidb-cloud/size-your-cluster.md @@ -44,13 +44,13 @@ TiDB のノード数、vCPU、RAM を構成できます。 ### TiDBノード数 {#tidb-node-count} -高可用性を確保するには、 TiDB Cloudクラスターごとに少なくとも 2 つの TiDB ノードを構成することをお勧めします。 +高可用性を確保するには、 TiDB Cloudクラスターごとに少なくとも 2つの TiDB ノードを構成することをお勧めします。 一般的に、TiDBのパフォーマンスはTiDBノード数に比例して増加します。しかし、TiDBノード数が8を超えると、パフォーマンスの向上は線形比例からわずかに減少します。ノード数が8増えるごとに、パフォーマンスの偏差係数は約5%になります。 例えば： -- TiDB ノードが 9 台の場合、パフォーマンス偏差係数は約 5% となるため、TiDB パフォーマンスは単一の TiDB ノードの約`9 * (1 - 5%) = 8.55`倍の性能になります。 +- TiDB ノードが 9台の場合、パフォーマンス偏差係数は約 5% となるため、TiDB パフォーマンスは単一の TiDB ノードの約`9 * (1 - 5%) = 8.55`倍の性能になります。 - TiDB ノードが 16 個ある場合、パフォーマンス偏差係数は約 10% なので、TiDB パフォーマンスは単一の TiDB ノードの`16 * (1 - 10%) = 14.4`倍のパフォーマンスになります。 TiDB ノードの指定されたレイテンシーでは、TiDB のパフォーマンスは読み取り/書き込み比率によって異なります。 @@ -77,7 +77,7 @@ TiDBノード数が8未満の場合、パフォーマンス偏差係数はほぼ 8 ノードのパフォーマンス偏差係数は約 5% なので、推定 TiDB パフォーマンスは`8 * 15,500 * (1 - 5%) = 117,800`となり、期待される 110,000 QPS のパフォーマンスを満たすことができます。 -したがって、8 つの TiDB ノード (8 vCPU、16 GiB) が推奨されます。 +したがって、8つの TiDB ノード (8 vCPU、16 GiB) が推奨されます。 ## サイズ TiKV {#size-tikv} @@ -110,13 +110,13 @@ TiKV のノード数、vCPU と RAM、ストレージを構成できます。 ### TiKVノード数 {#tikv-node-count} -TiKV ノードの数は**少なくとも 1 セット (3 つの異なる利用可能ゾーン内の 3 つのノード) で**ある必要があります。 +TiKV ノードの数は**少なくとも 1 セット (3つの異なる利用可能ゾーン内の 3つのノード) で**ある必要があります。 TiDB Cloudは、耐久性と高可用性を実現するために、選択したリージョン内のすべてのアベイラビリティゾーン（少なくとも3つ）にTiKVノードを均等にデプロイします。典型的な3レプリカ構成では、データはすべてのアベイラビリティゾーンのTiKVノードに均等に分散され、各TiKVノードのディスクに永続化されます。 > **Note:** > -> TiDB クラスターをスケールすると、3 つのアベイラビリティゾーンのノードが同時に増減します。ニーズに応じて TiDB クラスターをスケールインまたはスケールアウトする方法については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)を参照してください。 +> TiDB クラスターをスケールすると、3つのアベイラビリティゾーンのノードが同時に増減します。ニーズに応じて TiDB クラスターをスケールインまたはスケールアウトする方法については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)を参照してください。 TiKVは主にデータストレージに使用されますが、TiKVノードのパフォーマンスはワークロードによって異なります。そのため、TiKVノードの数を計画する際には、 [**データ量**](#estimate-tikv-node-count-according-to-data-volume)と[期待されるパフォーマンス](#estimate-tikv-node-count-according-to-expected-performance)両方に基づいて見積もり、そのうち大きい方の見積もりを推奨ノード数とする必要があります。 @@ -167,7 +167,7 @@ TiKVノード数が8未満の場合、パフォーマンス偏差係数はほぼ 7 は 8 未満なので、7 ノードのパフォーマンス偏差係数は 0 です。推定 TiKV パフォーマンスは`7 * 17,800 * (1 - 0) = 124,600`であり、期待される 110,000 QPS のパフォーマンスを満たすことができます。 -したがって、予想されるパフォーマンスに応じて、7 つの TiKV ノード (8 vCPU、32 GiB) が推奨されます。 +したがって、予想されるパフォーマンスに応じて、7つの TiKV ノード (8 vCPU、32 GiB) が推奨されます。 次に、データ量に応じて計算された TiKV ノード数と、予想されるパフォーマンスに応じて計算された数を比較し、大きい方を TiKV ノードの推奨数とします。 @@ -200,7 +200,7 @@ Basicストレージは、Standardストレージよりもパフォーマンス Basicストレージタイプは、AWS でホストされている次のクラスターに自動的に適用されます。 -- 2025 年 4 月 1 日より前に作成された既存のクラスター。 +- 2025年 4月 1日より前に作成された既存のクラスター。 - v7.5.5、v8.1.2、または v8.5.0 より前のバージョンの TiDB で作成された新しいクラスター。 #### Standardストレージ {#standard-storage} @@ -238,7 +238,7 @@ TiFlashノードの最小数は、特定のテーブルのTiFlashレプリカ数 TiFlashノードの最小数: `min((compressed size of table A * replicas for table A + compressed size of table B * replicas for table B) / size of each TiFlash capacity, max(replicas for table A, replicas for table B))` -たとえば、AWS 上の各TiFlashノードのノードストレージを1024 GiB に設定し、テーブル A にレプリカを 2 つ (圧縮サイズは 800 GiB)、テーブル B にレプリカを 1 つ (圧縮サイズは 100 GiB) 設定した場合、必要なTiFlashノードの数は次のようになります。 +たとえば、AWS 上の各TiFlashノードのノードストレージを1024 GiB に設定し、テーブル A にレプリカを 2つ (圧縮サイズは 800 GiB)、テーブル B にレプリカを 1つ (圧縮サイズは 100 GiB) 設定した場合、必要なTiFlashノードの数は次のようになります。 TiFlashノードの最小数: `min((800 GiB * 2 + 100 GiB * 1) / 1024 GiB, max(2, 1)) ≈ 2` diff --git a/tidb-cloud/statement-insight.md b/tidb-cloud/statement-insight.md index 505d5e5ead359..87bb26e077862 100644 --- a/tidb-cloud/statement-insight.md +++ b/tidb-cloud/statement-insight.md @@ -11,7 +11,7 @@ Statement Insight は、履歴データに基づいてベースラインを把 > **Note:** > -> Statement Insight はパブリックプレビュー中であり、8 月 19 日以降に作成された一部の {{{ .premium }}}{{{ .premium }}} and {{{ .byoc }}} インスタンスでのみ利用できます。今後のリリースで、より広範囲に展開される予定です。早期アクセスを希望する場合は、[TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 +> Statement Insight はパブリックプレビュー中であり、8月 19日以降に作成された一部の {{{ .premium }}}{{{ .premium }}} and {{{ .byoc }}} インスタンスでのみ利用できます。今後のリリースで、より広範囲に展開される予定です。早期アクセスを希望する場合は、[TiDB Cloud Support](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 > Statement Insight がまだ利用できないインスタンスでは、当面の間、ステートメント分析に [SQL Statement](/tidb-cloud/tune-performance.md#statement-analysis) タブを引き続き使用できます。 ## 始める前に {#before-you-begin} @@ -19,7 +19,7 @@ Statement Insight は、履歴データに基づいてベースラインを把 Statement Insight は、インスタンスで有効化された後にのみデータ収集を開始するため、初めてページを開く際は次の点に注意してください。 - 過去データは補完されません。表示されるのは、この機能がインスタンスで有効化された時点以降のデータのみです。 -- 利用可能な時間範囲は日ごとに増えていきます。たとえば、機能の稼働開始から 1 日後には、約 1 日分のデータが表示されます。 +- 利用可能な時間範囲は日ごとに増えていきます。たとえば、機能の稼働開始から 1日後には、約1日分のデータが表示されます。 ## Statement Insight を開く {#open-statement-insight} diff --git a/tidb-cloud/terraform-migrate-cluster-resource.md b/tidb-cloud/terraform-migrate-cluster-resource.md index 563a234b3a4a5..b7a921740f5b4 100644 --- a/tidb-cloud/terraform-migrate-cluster-resource.md +++ b/tidb-cloud/terraform-migrate-cluster-resource.md @@ -5,7 +5,7 @@ summary: クラスター リソースをサーバーレスまたは専用のク # クラスタリソースをサーバーレスまたは専用クラスタリソースに移行する {#migrate-cluster-resource-to-serverless-or-dedicated-cluster-resource} -TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソースが`tidbcloud_serverless_cluster`と`tidbcloud_dedicated_cluster` 2 つの新しいリソースに置き換えられます。TiDB Cloud Terraform Provider v0.4.0 以降のバージョンをご利用の場合は、このドキュメントに従って`tidbcloud_cluster`リソースを`tidbcloud_serverless_cluster`または`tidbcloud_dedicated_cluster`リソースに移行できます。 +TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソースが`tidbcloud_serverless_cluster`と`tidbcloud_dedicated_cluster` 2つの新しいリソースに置き換えられます。TiDB Cloud Terraform Provider v0.4.0 以降のバージョンをご利用の場合は、このドキュメントに従って`tidbcloud_cluster`リソースを`tidbcloud_serverless_cluster`または`tidbcloud_dedicated_cluster`リソースに移行できます。 > **Tip:** > diff --git a/tidb-cloud/terraform-tidbcloud-provider-overview.md b/tidb-cloud/terraform-tidbcloud-provider-overview.md index 0c2655c06ad8f..79cd7fb4c6229 100644 --- a/tidb-cloud/terraform-tidbcloud-provider-overview.md +++ b/tidb-cloud/terraform-tidbcloud-provider-overview.md @@ -25,7 +25,7 @@ summary: Terraform を使用してTiDB Cloudリソースを作成、管理、更 ## サポートされているリソースとデータソース {#supported-resources-and-data-sources} -[リソース](https://www.terraform.io/language/resources)と[データソース](https://www.terraform.io/language/data-sources) 、Terraform 言語で最も重要な 2 つの要素です。 +[リソース](https://www.terraform.io/language/resources)と[データソース](https://www.terraform.io/language/data-sources) 、Terraform 言語で最も重要な 2つの要素です。 TiDB Cloud は次のリソースとデータ ソースをサポートしています。 diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 9e8e0f15e4c3f..2efccf09cb3ee 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -422,7 +422,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを } ``` - クラスターのステータスは`CREATING`です。この場合、ステータスが`AVAILABLE`に変わるまで待つ必要があります。これには通常、少なくとも 10 分かかります。 + クラスターのステータスは`CREATING`です。この場合、ステータスが`AVAILABLE`に変わるまで待つ必要があります。これには通常、少なくとも 10分かかります。 6. 最新の状態を確認したい場合は、 `terraform refresh`コマンドを実行して状態を更新した後、 `terraform state show tidbcloud_cluster.${resource-name}`コマンドを実行して状態を表示します。 @@ -535,7 +535,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の ``` - 上記の実行計画のように、 TiFlashが追加され、リソースが 1 つ変更されます。 + 上記の実行計画のように、 TiFlashが追加され、リソースが 1つ変更されます。 3. 計画の内容がすべて問題ない場合は、「 `yes`と入力して続行します。 @@ -592,7 +592,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の 1. [クラスターを作成する](#create-a-cluster-using-the-cluster-resource)際に使用される`cluster.tf`ファイルで、 `components`構成を編集します。 - たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります。[クラスタ仕様からこの情報を取得](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 + たとえば、TiDB 用にさらに 1つのノード、TiKV 用にさらに 3つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります。[クラスタ仕様からこの情報を取得](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1つのノードを追加するには、次のように構成を編集します。 components = { tidb = { diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index cbb2a3ccba070..d0e7e74e26723 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -242,7 +242,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi Apply complete! Resources: 1 added, 0 changed, 0 destroyed. ``` - 通常、 TiDB Cloud Dedicated クラスターの作成には少なくとも 10 分かかります。 + 通常、 TiDB Cloud Dedicated クラスターの作成には少なくとも 10分かかります。 5. リソースの状態を確認するには、コマンド`terraform show`または`terraform state show tidbcloud_dedicated_cluster.${resource-name}`を使用します。前者のコマンドは、すべてのリソースとデータソースの状態を表示します。 @@ -473,7 +473,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 Enter a value: yes ``` - 上記の実行計画では、 TiFlashが追加され、1 つのリソースが変更されます。 + 上記の実行計画では、 TiFlashが追加され、1つのリソースが変更されます。 3. 計画の内容がすべて問題ない場合は、「 `yes`と入力して続行します。 @@ -562,7 +562,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 1. [クラスターを作成する](#create-a-tidb-cloud-dedicated-cluster)際に使用する`cluster.tf`ファイルで、 `tidb_node_setting` 、 `tikv_node_setting` 、 `tiflash_node_setting`の設定を編集します。 - たとえば、TiDB ノードを 1 つ、TiKV ノードを 3 つ (スケーリング ステップが 3 であるため、TiKV ノードの数は 3 の倍数である必要があります)、およびTiFlashノードを 1 つ追加するには、次のように構成を編集します。 + たとえば、TiDB ノードを 1つ、TiKV ノードを 3つ (スケーリング ステップが 3 であるため、TiKV ノードの数は 3 の倍数である必要があります)、およびTiFlashノードを 1つ追加するには、次のように構成を編集します。 tidb_node_setting = { node_spec_key = "8C16G" @@ -815,7 +815,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 1. [クラスターを作成する](#create-a-tidb-cloud-dedicated-cluster)を実行するときに使用する`cluster.tf`ファイルに、 `tidbcloud_dedicated_node_group`構成を追加します。 - たとえば、3 つのノードを持つ TiDB ノード グループを追加するには、次のように構成を編集します。 + たとえば、3つのノードを持つ TiDB ノード グループを追加するには、次のように構成を編集します。 resource "tidbcloud_dedicated_node_group" "example_group" { cluster_id = tidbcloud_dedicated_cluster.example_cluster.cluster_id diff --git a/tidb-cloud/ticloud-import-start.md b/tidb-cloud/ticloud-import-start.md index 1df77d79e0e2f..77a0899600ec4 100644 --- a/tidb-cloud/ticloud-import-start.md +++ b/tidb-cloud/ticloud-import-start.md @@ -20,7 +20,7 @@ ticloud serverless import create [flags] > **Note:** > -> 現在、1 つのローカル インポート タスクにつき 1 つの CSV ファイルのみをインポートできます。 +> 現在、1つのローカル インポート タスクにつき 1つの CSV ファイルのみをインポートできます。 ## 例 {#examples} diff --git a/tidb-cloud/tidb-cloud-auditing-legacy.md b/tidb-cloud/tidb-cloud-auditing-legacy.md index 1ddb4ac661181..732c882adecee 100644 --- a/tidb-cloud/tidb-cloud-auditing-legacy.md +++ b/tidb-cloud/tidb-cloud-auditing-legacy.md @@ -260,7 +260,7 @@ TiDB Cloud がデータベース監査ログを書き込む宛先として、組 1. **DB Audit Logging** ページの **Log Filter Rules** セクションで **Add Filter Rule** をクリックし、監査フィルタールールを追加します。 - 一度に追加できる監査ルールは 1 つです。各ルールでは、ユーザー式、データベース式、テーブル式、およびアクセス種別を指定します。監査要件に応じて複数の監査ルールを追加できます。 + 一度に追加できる監査ルールは 1つです。各ルールでは、ユーザー式、データベース式、テーブル式、およびアクセス種別を指定します。監査要件に応じて複数の監査ルールを追加できます。 2. **Log Filter Rules** セクションで **>** をクリックして展開し、追加した監査ルールの一覧を表示します。 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index e752ef1fb3a5f..d1c67cbdfd1a2 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -12,7 +12,7 @@ TiDB Cloud は、実行された SQL ステートメントなど、データベ > データベース監査ログは、次の要件を満たす対象の TiDB Cloud Dedicated クラスターでパブリックプレビューとして利用できます。 > > - AWS および Google Cloud でホストされるクラスターの場合: TiDB バージョンが v7.5.6 以降、または v8.5.2 以降である必要があります。 -> - Azure でホストされるクラスターの場合: TiDB バージョンが v7.5.6 以降、または v8.5.2 以降であり、クラスターが 2026 年 4 月 15 日以降に作成されている必要があります。 +> - Azure でホストされるクラスターの場合: TiDB バージョンが v7.5.6 以降、または v8.5.2 以降であり、クラスターが 2026年 4月 15日以降に作成されている必要があります。 > > その他のすべての TiDB バージョンまたはクラスター構成では、データベース監査ログはリクエストに応じて利用できます。対象外のクラスターへのアクセスをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**？**をクリックし、 **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **説明**欄に「データベース監査ログの申請」と入力して、 **「送信」を**クリックしてください。 > diff --git a/tidb-cloud/tidb-cloud-billing-dm.md b/tidb-cloud/tidb-cloud-billing-dm.md index 0b74452a20eae..961f44c6e8271 100644 --- a/tidb-cloud/tidb-cloud-billing-dm.md +++ b/tidb-cloud/tidb-cloud-billing-dm.md @@ -37,7 +37,7 @@ TiDB Cloudは、データ移行のキャパシティをレプリケーション データ移行ジョブは、ターゲット TiDB ノードと同じリージョンにあります。 -AWS PrivateLink または VPC ピアリング接続を使用しており、ソースデータベースと TiDB ノードが同じリージョンまたは同じアベイラビリティーゾーン (AZ) にない場合は、クロスリージョントラフィック料金とクロス AZ トラフィック料金の 2 つの追加トラフィック料金が発生することに注意してください。 +AWS PrivateLink または VPC ピアリング接続を使用しており、ソースデータベースと TiDB ノードが同じリージョンまたは同じアベイラビリティーゾーン (AZ) にない場合は、クロスリージョントラフィック料金とクロス AZ トラフィック料金の 2つの追加トラフィック料金が発生することに注意してください。 - ソース データベースと TiDB ノードが同じリージョンにない場合、データ移行ジョブがソース データベースからデータを収集するときに、リージョン間のトラフィック料金が発生します。 diff --git a/tidb-cloud/tidb-cloud-billing.md b/tidb-cloud/tidb-cloud-billing.md index 323d4f098587e..2f9f229f71d6b 100644 --- a/tidb-cloud/tidb-cloud-billing.md +++ b/tidb-cloud/tidb-cloud-billing.md @@ -41,7 +41,7 @@ TiDB Cloud Lake の料金は、ウェアハウス、ストレージ、クラウ 組織内で`Organization Owner`または`Organization Billing Manager`の役割を担っている場合は、 TiDB Cloudの請求書情報を管理できます。それ以外の場合は、このセクションをスキップしてください。 -支払い方法を設定した後、コストが割り当て (デフォルトでは 500 ドル) に達すると、 TiDB Cloud は請求書を生成します。割り当てを引き上げたい場合、または月に 1 回の請求書を受け取りたい場合は、[営業担当者にお問い合わせください](https://www.pingcap.com/contact-us/)。 +支払い方法を設定した後、コストが割り当て (デフォルトでは 500 ドル) に達すると、 TiDB Cloud は請求書を生成します。割り当てを引き上げたい場合、または月に 1回の請求書を受け取りたい場合は、[営業担当者にお問い合わせください](https://www.pingcap.com/contact-us/)。 @@ -120,7 +120,7 @@ TiDB Cloud Lake の料金は、ウェアハウス、ストレージ、クラウ - **Columnar storage**: カラム型ストレージは **TiFlash** エンジンによって提供されます。 -- **Dual-layer encryption**: 行ベースのストレージとカラム型ストレージはどちらもデュアルレイヤー暗号化をサポートしています。このメカニズムは、2 つの独立した暗号化レイヤーでデータを保護し、1 つのレイヤーが侵害された場合でもデータが保護された状態を維持できるようにします。 +- **Dual-layer encryption**: 行ベースのストレージとカラム型ストレージはどちらもデュアルレイヤー暗号化をサポートしています。このメカニズムは、2つの独立した暗号化レイヤーでデータを保護し、1つのレイヤーが侵害された場合でもデータが保護された状態を維持できるようにします。 - Storage-layer encryption: 基盤となるクラウドプロバイダーは、ネイティブのストレージ暗号化メカニズムを使用して、保存中のすべてのデータを暗号化します。 - Database-layer encryption: クラウドプロバイダーの暗号化に加えて、TiDB Cloud は顧客管理暗号化キー (CMEK) またはエスクロー鍵のいずれかを使用して、自動的に第 2 の暗号化レイヤーを適用します。 @@ -194,7 +194,7 @@ TiDB Cloudは、概念実証（PoC）ユーザー向けに一定数のクレジ > > PoCプロセス中： > -> - お支払い方法を追加する前にすべてのクレジットが期限切れになった場合、新しいTiDB Cloud Dedicatedクラスターを作成することはできません。3 日後には、既存のすべてのTiDB Cloud Dedicatedクラスターがリサイクルされます。7 日後には、すべてのバックアップがリサイクルされます。処理を再開するには、お支払い方法を追加してください。 +> - お支払い方法を追加する前にすべてのクレジットが期限切れになった場合、新しいTiDB Cloud Dedicatedクラスターを作成することはできません。3日後には、既存のすべてのTiDB Cloud Dedicatedクラスターがリサイクルされます。7日後には、すべてのバックアップがリサイクルされます。処理を再開するには、お支払い方法を追加してください。 > - 支払い方法を追加した後にすべてのクレジットが期限切れになった場合でも、PoCプロセスは続行され、手数料は支払い方法から差し引かれます。 ## 割引 {#discounts} diff --git a/tidb-cloud/tidb-cloud-budget.md b/tidb-cloud/tidb-cloud-budget.md index c9a873dbc609c..dc03fc4281b00 100644 --- a/tidb-cloud/tidb-cloud-budget.md +++ b/tidb-cloud/tidb-cloud-budget.md @@ -9,7 +9,7 @@ TiDB Cloudでは、予算機能を使用してコストを監視し、支出を 月々の実際の費用が指定の予算の割合のしきい値を超えると、組織のオーナーと請求管理者にアラートメールが送信されます。これらの通知は、最新情報を入手し、支出を管理するための積極的な対策を講じ、予算に合わせた支出管理に役立ちます。 -TiDB Cloud、支出を追跡するのに役立つ 2 種類の予算を提供しています。 +TiDB Cloud、支出を追跡するのに役立つ 2種類の予算を提供しています。 - **Starter Spending Limit**予算：支出制限が0を超えるTiDB Cloud Starterごとに、 TiDB Cloudは**Starter Spending Limit**予算を自動的に作成します。この予算は、そのクラスターに設定されている[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)予算に対する実際のコストを追跡するのに役立ちます。予算には、予算の75%、90%、100%という3つのしきい値ルールが含まれており、編集できません。 @@ -53,7 +53,7 @@ TiDB Cloud、支出を追跡するのに役立つ 2 種類の予算を提供し 6. 予算のアラートしきい値を設定します。選択した期間中に実際の支出が指定されたしきい値を超えた場合、 TiDB Cloud は組織のオーナーと課金管理者に予算通知メールを送信します。 - - TiDB Cloud はデフォルトで、予算額の 75%、90%、100% の 3 つのアラートしきい値を提供しています。これらのパーセンテージは必要に応じて変更できます。 + - TiDB Cloud はデフォルトで、予算額の 75%、90%、100% の 3つのアラートしきい値を提供しています。これらのパーセンテージは必要に応じて変更できます。 - 新しいアラートしきい値を追加するには、 **Add alert threshold.**をクリックします。 - しきい値を削除するには、しきい値の横にある削除アイコンをクリックします。 diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index 6d2a6242dd242..7d91134c97071 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -65,7 +65,7 @@ TiDB Cloud ClinicはGrafanaを使用して、TiDBクラスターの包括的な TiDB Cloudコンソールのデフォルトの[**Slow Queries**](/tidb-cloud/tune-performance.md#slow-query)ページでは、パフォーマンスに影響を与えるクエリを特定することが困難になる場合があります。特に、スロークエリが多数存在するクラスタではなおさらです。TiDB Cloud Clinicの**Top Slow Queries**機能は、スロークエリのログに基づいて集計分析を提供します。この機能により、パフォーマンスに問題のあるクエリを簡単に特定できるため、全体的なパフォーマンスチューニング時間を少なくとも半分に短縮できます。 -上位のスロークエリには、SQL ダイジェストによって集計された上位 10 件のクエリが、次のディメンションで並べ替えられて表示されます。 +上位のスロークエリには、SQL ダイジェストによって集計された上位 10件のクエリが、次のディメンションで並べ替えられて表示されます。 - 合計レイテンシー - 最大レイテンシー @@ -87,7 +87,7 @@ TiDB Cloudコンソールのデフォルトの[**Slow Queries**](/tidb-cloud/tun 5. (オプション) 時間範囲、データベース、またはステートメントの種類別にスロークエリをフィルタリングします。 -スロークエリの保持ポリシーは 7 日間です。 +スロークエリの保持ポリシーは 7日間です。 詳細については[TiDB Dashboardのスロークエリ](https://docs.pingcap.com/tidb/stable/dashboard-slow-query)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-console-auditing.md b/tidb-cloud/tidb-cloud-console-auditing.md index cf046ceb0f139..2dddfbb1b6626 100644 --- a/tidb-cloud/tidb-cloud-console-auditing.md +++ b/tidb-cloud/tidb-cloud-console-auditing.md @@ -34,7 +34,7 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー > **Note:** > > - 組織でコンソール監査ログを初めて有効にする場合、コンソール監査ログは空です。監査対象イベントが実行されると、対応するログが表示されます。 -> - コンソール監査ログが無効になってから 90 日以上経過した場合、ログは表示されません。 +> - コンソール監査ログが無効になってから 90日以上経過した場合、ログは表示されません。 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 2. 左側のナビゲーション ペインで、 **[Console Audit Logging]**をクリックします。 @@ -53,7 +53,7 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー ## コンソール監査ログストレージポリシー {#console-audit-log-storage-policy} -コンソール監査ログのストレージ期間は 90 日間で、その後はログは自動的にクリーンアップされます。 +コンソール監査ログのストレージ期間は 90日間で、その後はログは自動的にクリーンアップされます。 > **Note:** > @@ -64,7 +64,7 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー 規制コンプライアンス要件への対応を支援するために、TiDB Cloud はコンソール監査ログについて次の制御を提供します。 -- **Completeness**: 組織でコンソール監査ログが有効になっている場合、監査システムは[サポートされているイベントタイプ](#console-audit-event-types)をトリガーするユーザー操作を記録します。ログエントリは通常、イベント発生から 60 分以内に、表示、ダウンロード、および API を介したプログラムによるアクセスが可能になります。 +- **Completeness**: 組織でコンソール監査ログが有効になっている場合、監査システムは[サポートされているイベントタイプ](#console-audit-event-types)をトリガーするユーザー操作を記録します。ログエントリは通常、イベント発生から 60分以内に、表示、ダウンロード、および API を介したプログラムによるアクセスが可能になります。 > **Note:** > diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index 5687935d7fceb..dc3da49fe5a94 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -20,7 +20,7 @@ aliases: ['/ja/tidbcloud/tidb-cloud-encrypt-cmek'] - CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスタを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 - 現在、CMEK 対応プロジェクトでは、AWS と Azure でホストされるクラスターを[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)つだけ作成できます。 - 現在、CMEK 対応プロジェクトでは、 [デュアルリージョンバックアップ](/tidb-cloud/backup-and-restore-concepts.md#dual-region-backup)サポートされていません。 -- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1 つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 +- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 ## CMEKを有効にする {#enable-cmek} diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md index 33c64298d42b1..dc57693ec968e 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md @@ -15,7 +15,7 @@ summary: 顧客管理暗号化キー (CMEK) を使用して、Azure でホスト - CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスタを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 - 現在、CMEK 対応プロジェクトでは、AWS と Azure でホストされる[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのみ作成できます。 - 現在、CMEK 対応プロジェクトでは、 [デュアルリージョンバックアップ](/tidb-cloud/backup-and-restore-concepts.md#dual-region-backup)はサポートされていません。 -- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1 つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 +- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 ## CMEKを有効にする {#enable-cmek} diff --git a/tidb-cloud/tidb-cloud-events.md b/tidb-cloud/tidb-cloud-events.md index 5c4511e3e171c..27fe696bdbe6f 100644 --- a/tidb-cloud/tidb-cloud-events.md +++ b/tidb-cloud/tidb-cloud-events.md @@ -65,4 +65,4 @@ TiDB Cloud は、次の種類のクラスターイベントを記録します。 ## イベント保持ポリシー {#event-retention-policy} -イベントデータは 7 日間保持されます。 \ No newline at end of file +イベントデータは 7日間保持されます。 \ No newline at end of file diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 699873defe89b..40175f60bc95a 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -138,7 +138,7 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー 削除された[TiDB Cloudのリソース](#tidb-cloud-resource)のデータと有効なバックアップが保存される場所。 -バックアップされたTiDB Cloudリソースが削除されると、その既存のバックアップ ファイルはごみ箱に移動されます。自動バックアップからのバックアップ ファイルについては、ごみ箱に指定された期間保持されます。バックアップの保持期間は**Backup Setting**で設定でき、デフォルトは 7 日です。手動バックアップからのバックアップ ファイルには有効期限はありません。データ損失を防ぐため、新しいTiDB Cloudリソースにデータを速やかに復元してください。なお、 TiDB Cloudリソース**にバックアップがない**場合、削除されたリソースはごみ箱に表示されません。 +バックアップされたTiDB Cloudリソースが削除されると、その既存のバックアップ ファイルはごみ箱に移動されます。自動バックアップからのバックアップ ファイルについては、ごみ箱に指定された期間保持されます。バックアップの保持期間は**Backup Setting**で設定でき、デフォルトは 7日です。手動バックアップからのバックアップ ファイルには有効期限はありません。データ損失を防ぐため、新しいTiDB Cloudリソースにデータを速やかに復元してください。なお、 TiDB Cloudリソース**にバックアップがない**場合、削除されたリソースはごみ箱に表示されません。 現在、ごみ箱機能をサポートしているTiDB Cloudリソースの種類は以下のとおりです。 @@ -166,7 +166,7 @@ TiDB Cloud は、TiCDC Replication Capacity Unit (RCU) の[変更フィード](/ ### リクエストキャパシティユニット（RCU） {#request-capacity-unit-rcu} -TiDB Cloud EssentialおよびTiDB Cloud Premium では、リクエストキャパシティユニット (RCU) は、 TiDB Cloud EssentialまたはTiDB Cloud Premium インスタンスにプロビジョニングされたコンピューティング容量を表す単位です。1 RCU は、1 秒あたり一定数の RU を処理できる固定量のコンピューティング リソースを提供します。プロビジョニングする RCU の数によって、インスタンスのベースライン パフォーマンスとスループット容量が決まります。ただし、RCU の管理方法は、 TiDB Cloud EssentialとTiDB Cloud Premium で異なります。 +TiDB Cloud EssentialおよびTiDB Cloud Premium では、リクエストキャパシティユニット (RCU) は、 TiDB Cloud EssentialまたはTiDB Cloud Premium インスタンスにプロビジョニングされたコンピューティング容量を表す単位です。1 RCU は、1秒あたり一定数の RU を処理できる固定量のコンピューティング リソースを提供します。プロビジョニングする RCU の数によって、インスタンスのベースライン パフォーマンスとスループット容量が決まります。ただし、RCU の管理方法は、 TiDB Cloud EssentialとTiDB Cloud Premium で異なります。 - TiDB Cloud Essential は、ワークロードに基づいて RCU を自動的にプロビジョニングします。QPS が増加すると、 TiDB Cloud はプロビジョニングされた RCU を動的にスケールアップしてパフォーマンスを維持します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 - TiDB Cloud Premium では、ワークロードの RCU の最大数 ( `RCU_max` ) を指定できます。 TiDB Cloudは、リアルタイムの需要に基づいて、 `0.25 * RCU_max`から`RCU_max`の範囲内で容量を自動的にスケーリングします。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)を参照してください。 @@ -176,9 +176,8 @@ TiDB Cloud EssentialおよびTiDB Cloud Premium では、リクエストキャ TiDB Cloud Starter、 Essential、およびPremiumプランでは、リクエストユニット（RU）は、データベースへの単一のリクエストによって消費されるリソース量を表す単位です。リクエストによって消費されるRUの量は、操作の種類や取得または変更されるデータの量など、さまざまな要因によって異なります。ただし、これらのプランの課金モデルは異なります。 - TiDB Cloud Starter は、消費された RU の合計数に基づいて請求されます。詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 -- TiDB Cloud Essentialは、プロビジョニングされた[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)の数に基づいて請求されます。 1 つの RCU は、1 秒あたり特定の数の RU を処理できる固定量のコンピューティング リソースを提供します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 -- TiDB Cloud Premium は、ワークロードによって消費された実際のリクエストキャパシティユニット (RCU) に基づいて請求されます。 TiDB Cloudは1 秒あたりの平均 RU を毎分計算し、その平均値を[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)として請求に使用します。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)を参照してください。 - +- TiDB Cloud Essentialは、プロビジョニングされた[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)の数に基づいて請求されます。 1つの RCU は、1秒あたり特定の数の RU を処理できる固定量のコンピューティング リソースを提供します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 +- TiDB Cloud Premium は、ワークロードによって消費された実際のリクエストキャパシティユニット (RCU) に基づいて請求されます。 TiDB Cloudは1秒あたりの平均 RU を毎分計算し、その平均値を[リクエストキャパシティユニット（RCU）](#request-capacity-unit-rcu)として請求に使用します。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)を参照してください。 TiDB Cloud Dedicatedおよび TiDB Self-Managedの場合、リクエスト ユニット (RU) はシステム リソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベース要求によって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 ## S {#s} diff --git a/tidb-cloud/tidb-cloud-import-local-files.md b/tidb-cloud/tidb-cloud-import-local-files.md index 25af859497bec..cb8a774811b76 100644 --- a/tidb-cloud/tidb-cloud-import-local-files.md +++ b/tidb-cloud/tidb-cloud-import-local-files.md @@ -7,11 +7,11 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする ローカルファイルをTiDB Cloud Starterに直接インポートできます。タスク設定は数回クリックするだけで完了し、ローカルCSVデータがTiDBクラスターに素早くインポートされます。この方法を使用すると、クラウドストレージや認証情報を入力する必要がありません。インポートプロセス全体が迅速かつスムーズです。 -現在、この方法では、1 つのタスクに対して 1 つの CSV ファイルを既存の空のテーブルまたは新しいテーブルにインポートすることがサポートされています。 +現在、この方法では、1つのタスクに対して 1つの CSV ファイルを既存の空のテーブルまたは新しいテーブルにインポートすることがサポートされています。 ## 制限事項 {#limitations} -- 現在、 TiDB Cloud は、1 つのタスクにつき 250 MiB 以内の CSV 形式のローカル ファイルのインポートのみをサポートしています。 +- 現在、 TiDB Cloud は、1つのタスクにつき 250 MiB 以内の CSV 形式のローカル ファイルのインポートのみをサポートしています。 - ローカル ファイルのインポートは、 TiDB Cloud Starter クラスターでのみサポートされ、 TiDB Cloud Essential クラスターおよび TiDB Cloud Dedicated クラスターではサポートされません。 - 複数のインポート タスクを同時に実行することはできません。 diff --git a/tidb-cloud/tidb-cloud-org-sso-authentication.md b/tidb-cloud/tidb-cloud-org-sso-authentication.md index 645cf81f6f681..770bf76d898be 100644 --- a/tidb-cloud/tidb-cloud-org-sso-authentication.md +++ b/tidb-cloud/tidb-cloud-org-sso-authentication.md @@ -7,7 +7,7 @@ summary: カスタマイズされた組織認証を使用してTiDB Cloudコン シングル サインオン (SSO) は、 TiDB Cloud [組織](/tidb-cloud/tidb-cloud-glossary.md#organization)のメンバーが電子メール アドレスとパスワードの代わりに ID プロバイダー (IdP) の ID を使用してTiDB Cloudにログインできるようにする認証スキームです。 -TiDB Cloud は、次の 2 種類の SSO 認証をサポートしています。 +TiDB Cloud は、次の2種類の SSO 認証をサポートしています。 - [標準SSO](/tidb-cloud/tidb-cloud-sso-authentication.md) : メンバーはGitHub、Google、またはMicrosoftの認証方法を使用して[TiDB Cloudコンソール](https://tidbcloud.com/)にログインできます。TiDB Cloudのすべての組織では、標準SSOがデフォルトで有効になっています。 @@ -49,7 +49,7 @@ TiDB Cloud は、Cloud Organization SSO に次の認証方法を提供します - OIDC - SAML -Cloud Organization SSO を有効にすると、最初の 4 つの認証方法がデフォルトで有効になります。組織で SSO の使用を強制したい場合は、ユーザー名とパスワードによる認証方法を無効にすることができます。 +Cloud Organization SSO を有効にすると、最初の 4つの認証方法がデフォルトで有効になります。組織で SSO の使用を強制したい場合は、ユーザー名とパスワードによる認証方法を無効にすることができます。 有効になっているすべての認証方法はカスタムTiDB Cloudログイン ページに表示されるため、事前に有効または無効にする認証方法を決定する必要があります。 diff --git a/tidb-cloud/tidb-cloud-partners.md b/tidb-cloud/tidb-cloud-partners.md index 610a3330333ef..fa9aae0dcf631 100644 --- a/tidb-cloud/tidb-cloud-partners.md +++ b/tidb-cloud/tidb-cloud-partners.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidbcloud/managed-service-provider'] TiDB Cloudパートナー Web コンソールは、SaaS ソリューションに重点を置くパートナー向けに設計されており、PingCAP とパートナー間の強力なパートナーシップを構築および育成し、顧客により良いサービスを提供することを目的としています。 -TiDB Cloudパートナーには 2 つの種類があります。 +TiDB Cloudパートナーには 2つの種類があります。 - 再販業者: AWS Marketplace チャネルパートナープライベートオファー (CPPO) を通じてTiDB Cloud を再販します - マネージド サービス プロバイダー (MSP): TiDB Cloudを再販し、付加価値サービスを提供します @@ -23,7 +23,7 @@ TiDB Cloudパートナーには 2 つの種類があります。 ### 再販業者の日常業務を管理する {#manage-daily-tasks-for-a-reseller} -再販業者には、日常の管理タスクを管理する 2 つの方法があります。 +再販業者には、日常の管理タスクを管理する 2つの方法があります。 - [TiDB Cloudパートナーコンソール](https://partner-console.tidbcloud.com) - パートナー管理 API。オープン API ドキュメントは、 TiDB Cloudパートナー コンソールの**サポート**ページでご覧いただけます。 @@ -46,7 +46,7 @@ MSPプログラムにご興味があり、パートナーとしてご参加を - 会社名 - 会社の連絡先メールアドレス - 会社公式サイトURL -- 会社のロゴ（ライトモード用に 1 つの SVG ファイル、ダークモード用に 1 つの SVG ファイル。256 x 48 ピクセルの横長のロゴが推奨されます） +- 会社のロゴ（ライトモード用に 1つの SVG ファイル、ダークモード用に 1つの SVG ファイル。256 x 48 ピクセルの横長のロゴが推奨されます） 上記の情報は、顧客専用のサインアップ URL と会社ロゴ入りのページを生成するために使用されます。 @@ -54,7 +54,7 @@ MSPプログラムにご興味があり、パートナーとしてご参加を ### MSPの日常業務を管理する {#manage-daily-tasks-for-an-msp} -TiDB Cloud MSP パートナーとして、日常の管理タスクを管理するには 2 つの方法があります。 +TiDB Cloud MSP パートナーとして、日常の管理タスクを管理するには 2つの方法があります。 - [TiDB Cloudパートナーコンソール](https://partner-console.tidbcloud.com) - [MSP 管理 API (非推奨)](https://docs.pingcap.com/tidbcloud/api/v1beta1/msp) diff --git a/tidb-cloud/tidb-cloud-password-authentication.md b/tidb-cloud/tidb-cloud-password-authentication.md index 18aad32090156..fa4e14211dc0b 100644 --- a/tidb-cloud/tidb-cloud-password-authentication.md +++ b/tidb-cloud/tidb-cloud-password-authentication.md @@ -49,10 +49,10 @@ TiDB Cloudは、登録ユーザーに対してデフォルトのパスワード デフォルトのパスワード ポリシーは次のとおりです。 - 長さは 8 文字以上。 -- 少なくとも 1 つの大文字 (A から Z)。 -- 少なくとも 1 つの小文字 (az)。 -- 少なくとも 1 つの数字 (0 ～ 9)。 -- 新しいパスワードは、以前の 4 つのパスワードと同じであってはなりません。 +- 少なくとも 1つの大文字 (A から Z)。 +- 少なくとも 1つの小文字 (az)。 +- 少なくとも 1つの数字 (0 ～ 9)。 +- 新しいパスワードは、以前の 4つのパスワードと同じであってはなりません。 ## パスワードをリセットする {#reset-a-password} @@ -83,7 +83,7 @@ TiDB Cloudは、登録ユーザーに対してデフォルトのパスワード > **Note:** > > - このセクションは、メールアドレスとパスワードを使用してTiDB Cloudに[サインアップ](https://tidbcloud.com/free-trial)する場合にのみ適用されます。Google、GitHub、またはMicrosoft SSOを使用してTiDB Cloudにサインアップする場合は、選択したID管理プラットフォームでMFAを有効にできます。 -> - SSO ログイン シナリオでTiDB Cloud MFA を有効にしている場合は、アカウントのセキュリティを確保するために、 **2025 年 9 月 30 日**までに MFA 管理を SSO ID 管理プラットフォームに移行してください。 +> - SSO ログイン シナリオでTiDB Cloud MFA を有効にしている場合は、アカウントのセキュリティを確保するために、 **2025年 9月 30日**までに MFA 管理を SSO ID 管理プラットフォームに移行してください。 多要素認証（MFA）は、認証アプリを使用してログイン時にワンタイム認証コードを生成することで、セキュリティを強化します。ログインすると、 TiDB Cloud はパスワードとMFA認証コードの両方を検証します。このパスワードを生成するには、iOS または Android App Store で提供されている Google Authenticator や Authy などの認証アプリを使用できます。 diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index 01ed358eb5400..3d8474a092d9c 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -200,7 +200,7 @@ PoCはいつでも終了し、テスト環境を削除できます。詳細に ### 1. データのバックアップと復元にはどのくらいの時間がかかりますか? {#1-how-long-does-it-take-to-back-up-and-restore-my-data} -TiDB Cloud は、自動バックアップと手動バックアップの 2 種類のデータベースバックアップを提供しています。どちらの方法でも、データベース全体がバックアップされます。 +TiDB Cloud は、自動バックアップと手動バックアップの 2種類のデータベースバックアップを提供しています。どちらの方法でも、データベース全体がバックアップされます。 データのバックアップとリストアにかかる時間は、テーブル数、ミラーコピー数、CPU負荷レベルによって異なります。1つのTiKVノードにおけるバックアップとリストアの速度は約50 MB/秒です。 diff --git a/tidb-cloud/tidb-cloud-quickstart.md b/tidb-cloud/tidb-cloud-quickstart.md index d2cfce837a1cc..6d3e915776a45 100644 --- a/tidb-cloud/tidb-cloud-quickstart.md +++ b/tidb-cloud/tidb-cloud-quickstart.md @@ -60,7 +60,7 @@ AWS でホストされているTiDB Cloud Starter クラスターでは、 TiDB 3. SQL エディターで、macOS の場合は⌘ + I (Windows または Linux の場合はControl + I ) を押して、 [Chat2Query（PREVIEW）](/tidb-cloud/tidb-cloud-glossary.md#chat2query)に SQL クエリを自動的に生成するように指示します。 - たとえば、2 つの列 (列`id`と列`name` ) を持つ新しいテーブル`test.t`を作成するには、 `use test;`と入力してデータベースを指定し、 ⌘ + Iを押して、指示として`create a new table t with id and name`を入力し、 **Enter**を押すと、AI によってそれに応じた SQL ステートメントが生成されます。 + たとえば、2つの列 (列`id`と列`name` ) を持つ新しいテーブル`test.t`を作成するには、 `use test;`と入力してデータベースを指定し、 ⌘ + Iを押して、指示として`create a new table t with id and name`を入力し、 **Enter**を押すと、AI によってそれに応じた SQL ステートメントが生成されます。 生成されたステートメントについては、 **承認**をクリックして承認し、必要に応じてさらに編集するか、 **「破棄」を**クリックして拒否することができます。 diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index db4dfeba70b2c..e50f9bf75158e 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -20,7 +20,7 @@ summary: TiDB Cloudで SQL パフォーマンスを分析および調整する 指定された時間範囲（ `ΔT` ）内のユーザー応答時間の合計を取得するには、次の数式を使用します。 -`ΔT`での合計ユーザー応答時間 = 平均 TPS (1 秒あたりのトランザクション数) x 平均ユーザー応答時間 x `ΔT` 。 +`ΔT`での合計ユーザー応答時間 = 平均 TPS (1秒あたりのトランザクション数) x 平均ユーザー応答時間 x `ΔT` 。 ![user\_response\_time](/media/performance/user_response_time_en.png) @@ -49,7 +49,7 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ - **SQL Statement**を使用すると、ページ上のSQL実行を直接観察し、システムテーブルをクエリすることなくパフォーマンスの問題を簡単に特定できます。SQL文をクリックすると、クエリの実行計画をさらに詳しく表示して、トラブルシューティングや分析を行うことができます。SQLパフォーマンスチューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)を参照してください。 - **Key Visualizer**を使用すると、TiDB のデータ アクセス パターンとデータ ホットスポットを観察できます。 -- [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) : このページでは、リクエスト単位、使用済みストレージサイズ、1 秒あたりのクエリ数、平均クエリ実行時間などのメトリックを表示できます。 +- [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) : このページでは、リクエスト単位、使用済みストレージサイズ、1秒あたりのクエリ数、平均クエリ実行時間などのメトリックを表示できます。 追加のメトリックをリクエストするには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 diff --git a/tidb-cloud/tidb-node-group-management.md b/tidb-cloud/tidb-node-group-management.md index 0a1c38b4134c0..b0c15cdc219ee 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -55,7 +55,7 @@ TiDB ノード グループを作成するには、次の手順を実行しま 5. 新しい TiDB ノードは、新しい TiDB ノードグループとともに追加され、クラスターの課金に影響します。右側のペインでクラスターのサイズを確認し、 **確認**をクリックしてください。 -デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5 つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 TiDBノードグループを作成しても、デフォルトグループのエンドポイントを使用してクラスターに接続すると、TiDBノードグループ内のTiDBノードはワークロードを引き受けることができず、リソースが無駄になります。新しいTiDBノードグループ内のTiDBノードへの新しい接続を作成する必要があります。[TiDBノードグループに接続する](#connect-to-a-tidb-node-group)を参照してください。 @@ -113,7 +113,7 @@ TiDBノードグループを作成しても、デフォルトグループのエ ### VPCピアリング経由で接続する {#connect-via-vpc-peering} -すべての TiDB ノード グループはクラスターと同じ VPC を共有するため、すべてのグループのアクセスを有効にするには、1 つの VPC ピアリング接続を作成するだけで済みます。 +すべての TiDB ノード グループはクラスターと同じ VPC を共有するため、すべてのグループのアクセスを有効にするには、1つの VPC ピアリング接続を作成するだけで済みます。 1. [VPC ピアリング経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-vpc-peering-connections.md)の手順に従って、このクラスターの VPC ピアリングを作成します。 2. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 diff --git a/tidb-cloud/tidb-node-group-overview.md b/tidb-cloud/tidb-node-group-overview.md index 3c55a466f03e3..c626252bd7605 100644 --- a/tidb-cloud/tidb-node-group-overview.md +++ b/tidb-cloud/tidb-node-group-overview.md @@ -48,8 +48,8 @@ TiDBノードグループ機能は、TiDB Cloud Dedicatedクラスタのリソ 現在、TiDBノードグループ機能は無料です。制限事項とクォータは次のとおりです。 - TiDB ノードグループは、AWS または Google Cloud 上のTiDB Cloud Dedicated クラスターでのみ作成できます。他のクラウドプロバイダーへのサポートは、近い将来に予定されています。 -- 4 つの vCPU と 16 GiB のメモリを備えた TiDB クラスターは、TiDB ノード グループ機能をサポートしません。 -- デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5 つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +- 4つの vCPU と 16 GiB のメモリを備えた TiDB クラスターは、TiDB ノード グループ機能をサポートしません。 +- デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 - 各TiDBノードグループには、少なくとも1つのTiDBノードが含まれている必要があります。グループ内のノード数に制限はありませんが、 TiDB Cloud Dedicatedクラスタ内のTiDBノードの総数は150を超えてはなりません。 - TiDB Cloudは、ノードグループの境界に関係なく、TiDBオーナーノード上で自動統計収集タスクを実行します。これらのタスクは、個々のTiDBノードグループ内で分離することはできません。 - v8.1.2 より前のバージョンの TiDB クラスターの場合、 `ADD INDEX`タスクを個々の TiDB ノード グループ内で分離することはできません。 @@ -58,4 +58,4 @@ TiDBノードグループ機能は、TiDB Cloud Dedicatedクラスタのリソ TiDB Cloud [サービスレベル契約（SLA）](https://www.pingcap.com/legal/service-level-agreement-for-tidb-cloud-services/)によると、複数のTiDBノードを展開したTiDB Cloud Dedicatedクラスタの月間稼働率は最大99.99%に達します。しかし、TiDBノードグループを導入した後、各グループに1つのTiDBノードのみを含む複数のTiDBノードグループを作成すると、グループの高可用性が失われ、クラスタの月間稼働率は単一のTiDBノード展開モデル（つまり最大99.9%）に低下します。 -高可用性を確保するには、TiDB ノード グループごとに少なくとも 2 つの TiDB ノードを構成することをお勧めします。 +高可用性を確保するには、TiDB ノード グループごとに少なくとも 2つの TiDB ノードを構成することをお勧めします。 diff --git a/tidb-cloud/tidb-x-architecture.md b/tidb-cloud/tidb-x-architecture.md index 00e63b649be0a..efa444c4c1bb0 100644 --- a/tidb-cloud/tidb-x-architecture.md +++ b/tidb-cloud/tidb-x-architecture.md @@ -133,9 +133,9 @@ TiDB X は、 [リクエストキャパシティユニット](/tidb-cloud/tidb-c ### LSMツリーからLSMフォレストへ {#from-lsm-tree-to-lsm-forest} -従来の TiDB では、各 TiKV ノードで単一の RocksDB インスタンスが実行され、すべてのリージョンのデータが 1 つの大きな LSM ツリーに格納されます。数千のリージョンのデータが混在するため、リージョンの移動、スケールアウト、スケールインなどの操作によって大規模な圧縮がトリガーされる可能性があります。これにより、CPU および I/O リソースが大幅に消費され、オンライン トラフィックに影響が出る可能性があります。単一の LSM ツリーはグローバル ミューテックスによって保護されています。データ サイズが大きくなると、大規模 (たとえば、TiKV ノードあたり 6 TiB を超えるデータ、または 300,000 を超える SST ファイル) では、グローバル ミューテックス ロックの競合が増加し、読み取りと書き込みの両方のパフォーマンスに影響が出る可能性があります。 +従来の TiDB では、各 TiKV ノードで単一の RocksDB インスタンスが実行され、すべてのリージョンのデータが 1つの大きな LSM ツリーに格納されます。数千のリージョンのデータが混在するため、リージョンの移動、スケールアウト、スケールインなどの操作によって大規模な圧縮がトリガーされる可能性があります。これにより、CPU および I/O リソースが大幅に消費され、オンライン トラフィックに影響が出る可能性があります。単一の LSM ツリーはグローバル ミューテックスによって保護されています。データ サイズが大きくなると、大規模 (たとえば、TiKV ノードあたり 6 TiB を超えるデータ、または 300,000 を超える SST ファイル) では、グローバル ミューテックス ロックの競合が増加し、読み取りと書き込みの両方のパフォーマンスに影響が出る可能性があります。 -TiDB X は、単一の LSM ツリーから**LSM フォレスト**へと移行することで、ストレージエンジンを再設計しました。論理的なリージョン抽象化は維持しつつ、TiDB X は各リージョンに独自の独立した LSM ツリーを割り当てます。この物理的な分離により、スケーリング、リージョンの移動、データ ロードなどの操作中にリージョン間圧縮のオーバーヘッドが解消されます。1 つのリージョンに対する操作は、そのリージョンのツリー内に限定され、グローバルなミューテックスの競合は発生しません。 +TiDB X は、単一の LSM ツリーから**LSM フォレスト**へと移行することで、ストレージエンジンを再設計しました。論理的なリージョン抽象化は維持しつつ、TiDB X は各リージョンに独自の独立した LSM ツリーを割り当てます。この物理的な分離により、スケーリング、リージョンの移動、データ ロードなどの操作中にリージョン間圧縮のオーバーヘッドが解消されます。1つのリージョンに対する操作は、そのリージョンのツリー内に限定され、グローバルなミューテックスの競合は発生しません。 ![Classic TiDB vs TiDB X](/media/tidb-x/tidb-classic-vs-tidb-x-2.png) diff --git a/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md b/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md index 8341d2e66adae..bcbec8bdfb5a3 100644 --- a/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md +++ b/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md @@ -5,7 +5,7 @@ summary: TiDB Cloud が TiDB X インスタンス向けに個別のプロジェ # {{{ .starter }}} と Essential のための Project API 移行ガイド -2026 年 4 月 15 日より、TiDB Cloud はリソースタイプごとに個別のプロジェクトタイプを導入します。{{{ .starter }}} と Essential インスタンスについては、TiDB X プロジェクト内、または組織レベルで管理できるようになります。詳細は、[TiDB X Instances の Project Migration FAQ](/tidb-cloud/tidbx-instance-move-faq.md) を参照してください。 +2026年 4月 15日より、TiDB Cloud はリソースタイプごとに個別のプロジェクトタイプを導入します。{{{ .starter }}} と Essential インスタンスについては、TiDB X プロジェクト内、または組織レベルで管理できるようになります。詳細は、[TiDB X Instances の Project Migration FAQ](/tidb-cloud/tidbx-instance-move-faq.md) を参照してください。 このガイドは、既存の `v1beta` 呼び出しの大部分を引き続き動作させつつ、{{{ .starter }}} と Essential インスタンスに対するプロジェクト検索およびクラスタ作成にのみ最小限の変更を加えたい API 呼び出し元を対象としています。 @@ -26,7 +26,7 @@ summary: TiDB Cloud が TiDB X インスタンス向けに個別のプロジェ |---|---| | `dedicated` | TiDB Cloud Dedicated クラスタのみを含むプロジェクトです。 | | `tidbx` | {{{ .starter }}} や Essential など、TiDB X インスタンスのみを含むプロジェクトです。 | -| `tidbx_virtual` | どのプロジェクトにも割り当てられていない TiDB X インスタンス用の、デフォルトの組織レベルプロジェクトです。各組織には 1 つの `tidbx_virtual` プロジェクトのみ存在します。 | +| `tidbx_virtual` | どのプロジェクトにも割り当てられていない TiDB X インスタンス用の、デフォルトの組織レベルプロジェクトです。各組織には 1つの `tidbx_virtual` プロジェクトのみ存在します。 | > **Note:** > diff --git a/tidb-cloud/tiproxy-management.md b/tidb-cloud/tiproxy-management.md index 8e2cf3fe60039..a50295791ca12 100644 --- a/tidb-cloud/tiproxy-management.md +++ b/tidb-cloud/tiproxy-management.md @@ -26,7 +26,7 @@ TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスタのQPS | 小さい | 30K | 93 MiB/秒 | | 大きい | 120K | 312 MiB/秒 | -利用可能な TiProxy のサイズは`Small`と`Large`です。利用可能な TiProxy ノード数は 2、3、6、9、12、15、18、21、24 です。デフォルトの 2 つの小型 TiProxy ノードは、60K QPS と 186 MiB/s のネットワーク帯域幅を提供できます。高レイテンシーを防ぐために、QPS 容量の 20% を予約することをお勧めします。 +利用可能な TiProxy のサイズは`Small`と`Large`です。利用可能な TiProxy ノード数は 2、3、6、9、12、15、18、21、24 です。デフォルトの 2つの小型 TiProxy ノードは、60K QPS と 186 MiB/s のネットワーク帯域幅を提供できます。高レイテンシーを防ぐために、QPS 容量の 20% を予約することをお勧めします。 例えば、クラスターの最大QPSが10万、最大ネットワーク帯域幅が100MiB/sの場合、TiProxyノードのサイズと数は主にQPSによって決まります。この場合、小型のTiProxyノードを6個選択できます。 @@ -95,7 +95,7 @@ TiProxyのメトリクスを表示するには、以下の手順を実行して - **TiProxy CPU Usage**：各TiProxyノードのCPU使用率統計情報。上限は100%です。CPU使用率が80%を超える場合は、TiProxyのスケールアウトをお勧めします。 - **TiProxy Connections**：各TiProxyノード上の接続数。 -- **TiProxy Throughput**: 各 TiProxy ノードで 1 秒あたりに転送されるバイト数。最大スループットが最大ネットワーク帯域幅に達した場合は、TiProxy をスケールアウトすることをお勧めします。最大ネットワーク帯域幅の詳細については、 [TiProxyノードのサイズと数を決定する](#decide-the-size-and-number-of-tiproxy-nodes)を参照してください。 +- **TiProxy Throughput**: 各 TiProxy ノードで 1秒あたりに転送されるバイト数。最大スループットが最大ネットワーク帯域幅に達した場合は、TiProxy をスケールアウトすることをお勧めします。最大ネットワーク帯域幅の詳細については、 [TiProxyノードのサイズと数を決定する](#decide-the-size-and-number-of-tiproxy-nodes)を参照してください。 - **TiProxy Sessions Migration Reasons**：1分ごとに発生するセッション移行の数とその理由。たとえば、TiDBがスケールインし、TiProxyがセッションを他のTiDBノードに移行する場合、理由は`status`です。その他の移行理由については、 [TiProxyのモニタリング指標](https://docs.pingcap.com/tidb/stable/tiproxy-grafana#balance)を参照してください。 ### TiProxyの請求書を確認する {#view-tiproxy-bills} diff --git a/tidb-cloud/top-ru.md b/tidb-cloud/top-ru.md index ff539232f6dbb..3e792c4487b6d 100644 --- a/tidb-cloud/top-ru.md +++ b/tidb-cloud/top-ru.md @@ -163,5 +163,5 @@ Top RUは、インスタンスレベルでのリクエストユニット（RU） ### メトリクスにおけるRU使用状況とトップRUの違いは何ですか？ {#what-is-the-difference-between-the-ru-usage-in-metrics-and-top-ru} -- RU/s メトリックは、インスタンス全体レベルでの 1 分間の平均 RU レート (RU/s) を示します。 +- RU/s メトリックは、インスタンス全体レベルでの 1分間の平均 RU レート (RU/s) を示します。 - トップRUは、選択した期間におけるSQLステートメントごとの累積RU（RU/秒×実行時間）を表示し、どのSQLステートメントが合計で最も多くのリソースを消費しているかを特定するのに役立ちます。 diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index b901ab4a85ca0..e66fa98ecde09 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -207,7 +207,7 @@ S3バケットを暗号化する方法は複数あります。バケット内の 2. バケットのリストで、対象のバケットを見つけてクリックします。バケット情報ページが表示されます。 3. バケット情報ページで、 **Properties**タブをクリックし、 **Default encryption**領域まで下にスクロールして、この領域の設定を確認します。 -サーバー側暗号化には、Amazon S3 マネージドキー (SSE-S3) と AWS Key Management Service (SSE-KMS) の 2 種類があります。SSE-S3 の場合、アクセス拒否エラーが発生しないため、これ以上の確認は不要です。SSE-KMS の場合は、以下の点を確認する必要があります。 +サーバー側暗号化には、Amazon S3 マネージドキー (SSE-S3) と AWS Key Management Service (SSE-KMS) の 2種類があります。SSE-S3 の場合、アクセス拒否エラーが発生しないため、これ以上の確認は不要です。SSE-KMS の場合は、以下の点を確認する必要があります。 - 当該エリア内の AWS KMS キー ARN が下線なしの黒色で表示されている場合、その AWS KMS キーは AWS 管理キー (aws/s3) です。 - 該当エリアのAWS KMSキーARNが青色でリンク付きで表示されている場合は、そのキーARNをクリックしてキー情報ページを開きます。左側のナビゲーションバーで具体的な暗号化タイプを確認してください。AWS管理キー（aws/s3）またはカスタマー管理キーのいずれかです。 diff --git a/tidb-cloud/upgrade-tidb-cluster.md b/tidb-cloud/upgrade-tidb-cluster.md index dc9bd17f5137b..fceb9fba83aab 100644 --- a/tidb-cloud/upgrade-tidb-cluster.md +++ b/tidb-cloud/upgrade-tidb-cluster.md @@ -5,7 +5,7 @@ summary: TiDB クラスターをアップグレードする方法を学びます # TiDBクラスタのアップグレード {#upgrade-a-tidb-cluster} -このドキュメントでは、 TiDB Cloud上の TiDB クラスターをアップグレードする方法について説明します。TiDB Cloud は、 TiDB バージョンをアップグレードするための 2 つのアップグレード メカニズムを提供します。 +このドキュメントでは、 TiDB Cloud上の TiDB クラスターをアップグレードする方法について説明します。TiDB Cloud は、 TiDB バージョンをアップグレードするための 2つのアップグレード メカニズムを提供します。 ## 定期的にアップグレードする {#regularly-upgrade} diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index c036ae1532e4b..d5a843c268078 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -88,7 +88,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index baf46e062c394..9155d935f90de 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -89,7 +89,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 7db8ee22d636e..e2c95db1e1858 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -89,7 +89,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] SET tidb_index_serial_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index 430050d8feb92..05767590d0ba7 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -100,7 +100,7 @@ raft-engine.prefill-for-recycle = true SET tidb_analyze_distsql_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 72de74a9b3791..5f10eafbe6f59 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -100,7 +100,7 @@ raft-engine.prefill-for-recycle = true SET tidb_analyze_distsql_scan_concurrency=16; ``` -5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2 時間かかります。 +5. TiDB Cloud Dedicated クラスタでストレステストを実行するには、以下のコマンドを`go-tpc tpcc`を実行します。同時実行ごとにテストは 2時間かかります。 ```shell go-tpc tpcc --host ${HOST} -P 4000 --warehouses 1000 run -D tpcc -T ${THREAD} --time 2h0m0s -p ${PASSWORD} --ignore-error diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index 82b1ced64a49e..b9cd85a2d1780 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -85,7 +85,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ ### テスト環境 {#test-environment} - クラスタトポロジ: TiDB (32 vCPU、64 GiB) * 3 + TiKV (32 vCPU、64 GiB) * 6 -- ワークロード: 読み取り/書き込み比率 2:1、クラウド ディスク IO の遅延または 1 つの TiKV ノードでのハングをシミュレート +- ワークロード: 読み取り/書き込み比率 2:1、クラウド ディスク IO の遅延または 1つの TiKV ノードでのハングをシミュレート ### テスト結果 {#test-results} diff --git a/tidb-computing.md b/tidb-computing.md index 67f48402c2850..84a9dafbf620a 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -122,7 +122,7 @@ SQL コンピューティングの最もシンプルなソリューションは このソリューションは直感的で実現可能ですが、分散データベースのシナリオでは明らかな問題がいくつかあります。 -- データがスキャンされる際、各行は少なくとも 1 つの RPC オーバーヘッドを伴う KV 操作を介して TiKV から読み取られますが、スキャンするデータの量が多い場合は、このオーバーヘッドが非常に高くなる可能性があります。 +- データがスキャンされる際、各行は少なくとも 1つの RPC オーバーヘッドを伴う KV 操作を介して TiKV から読み取られますが、スキャンするデータの量が多い場合は、このオーバーヘッドが非常に高くなる可能性があります。 - すべての行に適用されるわけではありません。条件を満たさないデータは読み取る必要はありません。 - このクエリの返された結果では、要件に一致する行の数のみが必要であり、それらの行の値は必要ありません。 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index b116efc9b85a5..179daff6487bb 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -215,7 +215,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > > TiDBがサーバーをシャットダウンするまでの待機時間は、以下のパラメータによっても影響を受けます。 > -> - SystemD を使用するプラットフォームの場合、デフォルトの停止タイムアウトは 90 秒です。より長いタイムアウトが必要な場合は、 [`TimeoutStopSec=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#TimeoutStopSec=)を設定できます。 +> - SystemD を使用するプラットフォームの場合、デフォルトの停止タイムアウトは 90秒です。より長いタイムアウトが必要な場合は、 [`TimeoutStopSec=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#TimeoutStopSec=)を設定できます。 > > - TiUP クラスタコンポーネントを使用する場合、デフォルトの[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout)は120秒です。 > @@ -378,7 +378,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - 保持するログの最大数。 - デフォルト値: `0` -- デフォルトでは、すべてのログファイルが保持されます。 `7`に設定すると、最大で 7 つのログファイルが保持されます。 +- デフォルトでは、すべてのログファイルが保持されます。 `7`に設定すると、最大で 7つのログファイルが保持されます。 #### `compression` （v8.0.0の新機能） {#compression-new-in-v800} @@ -569,7 +569,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - `stats-lease`の間隔で、TiDB はメモリにロードする必要のある列統計をチェックします。 - `200 * stats-lease`の間隔で、TiDB はメモリにキャッシュされたフィードバックをシステム テーブルに書き込みます。 - `5 * stats-lease`の間隔で、TiDB はシステム テーブル内のフィードバックを読み取り、メモリにキャッシュされた統計情報を更新します。 -- `stats-lease`を 0s に設定すると、TiDB はシステム テーブル内のフィードバックを定期的に読み取り、メモリにキャッシュされた統計情報を 3 秒ごとに更新します。ただし、TiDB は、以下の統計情報関連のシステム テーブルを自動的に変更しなくなります。 +- `stats-lease`を 0s に設定すると、TiDB はシステム テーブル内のフィードバックを定期的に読み取り、メモリにキャッシュされた統計情報を 3秒ごとに更新します。ただし、TiDB は、以下の統計情報関連のシステム テーブルを自動的に変更しなくなります。 - `mysql.stats_meta` : TiDB は、トランザクションによって変更されたテーブル行の数を自動的に記録し、このシステム テーブルに更新しなくなりました。 - `mysql.stats_histograms` / `mysql.stats_buckets`および`mysql.stats_top_n` : TiDB は統計情報を自動的に分析して積極的に更新しなくなりました。 - `mysql.stats_feedback` : TiDB は、クエリされたデータによって返される統計情報の一部に基づいて、テーブルとインデックスの統計情報を更新しなくなりました。 @@ -673,7 +673,7 @@ opentracing.sampler に関連するコンフィグレーション項目。 - OpenTracingサンプラーのパラメータ。 - `const`タイプの場合、値は`0`または`1`となり、これは`const`サンプラーを有効にするかどうかを示します。 - `probabilistic`タイプの場合、パラメータはサンプリング確率を指定します。サンプリング確率は、 `0`から`1`までの浮動小数点数になります。 - - `ratelimiting`タイプの場合、パラメータは 1 秒あたりにサンプリングされるスパンの数を指定します。 + - `ratelimiting`タイプの場合、パラメータは 1秒あたりにサンプリングされるスパンの数を指定します。 - `remote`タイプの場合、パラメータはサンプリング確率を指定します。サンプリング確率は、 `0`から`1`までの浮動小数点数になります。 - デフォルト値: `1.0` diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index e48fcaf8e7d31..d947942bea613 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -21,7 +21,7 @@ TiDBは、優れたスケーラビリティと弾力性を備えたコンピュ - 定期的に実行する必要があるかもしれませんが、頻度は低くなります。 - リソースが適切に制御されていない場合、TP および AP タスクに影響を与え、データベース サービスの品質が低下する可能性があります。 -DXF を有効にすると上記の問題が解決され、次の 3 つの利点があります。 +DXF を有効にすると上記の問題が解決され、次の3つの利点があります。 - このフレームワークは、高いスケーラビリティ、高い可用性、および高いパフォーマンスを実現する統合された機能を提供します。 - DXF はタスクの分散実行をサポートしており、TiDB クラスター全体の利用可能なコンピューティング リソースを柔軟にスケジュールできるため、TiDB クラスター内のコンピューティング リソースをより有効に活用できます。 diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 46d89be61ae3b..d9ce6325343f7 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -88,7 +88,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ 1. TiDB ノードが特定の範囲のデータをスキャンした後 (データ ソースは CSV データまたは TiKV のテーブル データのいずれかになります)。 1. TiDB ノードはそれらをキーと値のペアにエンコードします。 - 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1 つのファイルであり、クラウドストレージにアップロードされます。 + 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1つのファイルであり、クラウドストレージにアップロードされます。 2. TiDBノードは、各セグメントの実際のキーと値の範囲（統計ファイルと呼ばれます）も連続して記録します。これは、スケーラブルなソート実装のための重要な準備です。これらのファイルは、実際のデータと共にクラウドストレージにアップロードされます。 diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 8d0f422bc0ba4..9fa4e7816459a 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -49,7 +49,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - コンフィグレーションパラメータ - `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。 - - `send-kv-pairs` : 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 + - `send-kv-pairs` : 1回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 - `disk-quota` : 物理インポート モードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスク クォータ。 - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。[`GOMEMLIMIT`を適切に設定します](#change-configuration-parameters) @@ -81,7 +81,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni ## ストレージスペースの見積もり {#estimate-storage-space} -データのインポートに必要なストレージ容量を見積もるには、次の 2 つの方法のいずれかを使用できます。 +データのインポートに必要なストレージ容量を見積もるには、次の2つの方法のいずれかを使用できます。 - 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。 - データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。 @@ -138,7 +138,7 @@ TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10 - `send-kv-pairs`を`3200`に設定します。この方法はTiDB v7.1.0以前のバージョンに適用されます。v7.2.0以降では、このパラメータは`send-kv-size`に置き換えられ、追加の設定は不要です。 - インスタンスが配置されているノード上のメモリを`GOMEMLIMIT` ～ 80% に調整します。 -インポートプロセス中の PD 散布リージョンのレイテンシーが30 分を超える場合は、次の最適化を検討してください。 +インポートプロセス中の PD 散布リージョンのレイテンシーが30分を超える場合は、次の最適化を検討してください。 - TiKV クラスターで I/O ボトルネックが発生しているかどうかを確認します。 - TiKV `raftstore.apply-pool-size`をデフォルト値の`2`から`4`または`8`に増やします。 diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index 2ed494e478c0c..1d9079a5c4a94 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -214,7 +214,7 @@ scrape_configs: - **`lightning_row_kv_deliver_seconds`** (ヒストグラム) - 1 つの SQL 行に対応する KV ペアのセットを配信するために必要な時間のバケット化されたヒストグラム。 + 1つの SQL 行に対応する KV ペアのセットを配信するために必要な時間のバケット化されたヒストグラム。 - **`lightning_block_deliver_seconds`** （ヒストグラム） diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 04a587d1eb3ed..1df530ba0861e 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/tidb-lightning/tidb-lightning-checkpoints.md @@ -47,7 +47,7 @@ driver = "file" ## チェックポイントのストレージ {#checkpoints-storage} -TiDB Lightning は、ローカル ファイルまたはリモート MySQL 互換データベースの 2 種類のチェックポイントストレージをサポートしています。 +TiDB Lightning は、ローカル ファイルまたはリモート MySQL 互換データベースの 2種類のチェックポイントストレージをサポートしています。 - `driver = "file"`の場合、チェックポイントは`dsn`で指定されたパスのローカルファイルに保存されます。チェックポイントは頻繁に更新されるため、RAMディスクなど、書き込み耐久性が非常に高いドライブにチェックポイントファイルを置くことを強くお勧めします。 @@ -100,7 +100,7 @@ tidb-lightning-ctl --checkpoint-remove='`schema`.`table`' tidb-lightning-ctl --checkpoint-remove=all ``` -このオプションは、ステータスに関係なく、1 つのテーブルまたはすべてのテーブルに関するすべてのチェックポイント情報を削除します。 +このオプションは、ステータスに関係なく、1つのテーブルまたはすべてのテーブルに関するすべてのチェックポイント情報を削除します。 ### `--checkpoint-dump` {#--checkpoint-dump} diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 13e10bbd80910..d08221e129a3c 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -250,13 +250,13 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 > > バージョン7.2.0以降、このパラメータは非推奨となり、設定後は無効になります。1回のリクエストでTiKVに送信されるデータ量を調整したい場合は、代わりに[`send-kv-size`](#send-kv-size-new-in-v720)パラメータを使用してください。 -- 物理インポート モードで TiKV にデータを送信するときに、1 つの要求内の KV ペアの最大数を指定します。 +- 物理インポート モードで TiKV にデータを送信するときに、1つの要求内の KV ペアの最大数を指定します。 #### `send-kv-size` v7.2.0 の新機能 {#send-kv-size-new-in-v720} -- 物理インポート モードで TiKV にデータを送信するときの 1 つのリクエストの最大サイズを指定します。 +- 物理インポート モードで TiKV にデータを送信するときの 1つのリクエストの最大サイズを指定します。 - デフォルト値: `"16K"` #### `compress-kv-pairs` {#compress-kv-pairs} @@ -456,7 +456,7 @@ CSV ファイルの解析方法を構成します。 #### `header-schema-match` {#header-schema-match} - CSV ファイル ヘッダー内の列名が、ターゲット テーブルで定義されている列名と一致するかどうかを制御します。 -- デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲット テーブルの列名と一致していることが確認されたことを意味します。そのため、2 つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 +- デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲット テーブルの列名と一致していることが確認されたことを意味します。そのため、2つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 - CSVテーブルヘッダーとターゲットテーブルの列名が一致しない（例えば、CSVテーブルヘッダーの一部の列名がターゲットテーブルに見つからない）ものの、列の順序が同じ場合は、この設定を`false`に設定してください。この場合、 TiDB Lightningはエラーを回避するためにCSVヘッダーを無視し、ターゲットテーブルの列の順序でデータを直接インポートします。したがって、列の順序が同じでない場合は、インポート前にCSVファイル内の列の順序をターゲットテーブルの順序と一致するように手動で調整する必要があります。そうしないと、データの不一致が発生する可能性があります。 - デフォルト値: `true` - 値のオプション: `true` 、 `false` @@ -680,4 +680,4 @@ CSV ファイルの解析方法を構成します。 #### `check-disk-quota` {#check-disk-quota} - 物理インポート モードを使用するときに、ローカル ディスク クォータをチェックする時間間隔を指定します。 -- デフォルト値: `"60s"` 、これは 60 秒を意味します。 +- デフォルト値: `"60s"` 、これは 60秒を意味します。 diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 522a8cdff024d..8fc11084d1556 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -227,8 +227,8 @@ trim-last-separator = false A,,B,, ``` - - `trim-last-separator = false`の場合、これは 5 つのフィールド`('A', '', 'B', '', '')`の行として解釈されます。 - - `trim-last-separator = true`の場合、これは 3 つのフィールド`('A', '', 'B')`の行として解釈されます。 + - `trim-last-separator = false`の場合、これは 5つのフィールド`('A', '', 'B', '', '')`の行として解釈されます。 + - `trim-last-separator = true`の場合、これは 3つのフィールド`('A', '', 'B')`の行として解釈されます。 - このオプションは非推奨です。代わりにオプション`terminator`を使用してください。 @@ -269,7 +269,7 @@ strict-format = true - 区切り文字が空です。 - 各フィールドにはターミネータ自体が含まれません。デフォルト設定では、これは各フィールドに CR ( `\r` ) または LF ( `\n` ) が含まれないことを意味します。 -CSV ファイルが厳密ではなく、 `strict-format`が誤って`true`に設定されている場合、複数行にまたがるフィールドが 2 つのチャンクに分割され、解析が失敗したり、破損したデータが暗黙的にインポートされたりする可能性があります。 +CSV ファイルが厳密ではなく、 `strict-format`が誤って`true`に設定されている場合、複数行にまたがるフィールドが 2つのチャンクに分割され、解析が失敗したり、破損したデータが暗黙的にインポートされたりする可能性があります。 ### 一般的な構成例 {#common-configuration-examples} diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 8076603abb9e9..47aa381646ad4 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -45,11 +45,11 @@ TiDB Lightningは、生成されたキーバリューデータを、対応する TiDB Lightningを使用して共有データベースとテーブルを並列にインポートする場合は、データの量に応じて適切な数のTiDB Lightningインスタンスを選択します。 -- MySQL のデータ量が 2 TiB 未満の場合、1 つのTiDB Lightningインスタンスを並列インポートに使用できます。 -- MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 未満の場合、MySQL インスタンスごとに 1 つのTiDB Lightningインスタンスを使用することをお勧めします。また、並列TiDB Lightningインスタンスの数は 10 を超えないようにしてください。 +- MySQL のデータ量が 2 TiB 未満の場合、1つのTiDB Lightningインスタンスを並列インポートに使用できます。 +- MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 未満の場合、MySQL インスタンスごとに 1つのTiDB Lightningインスタンスを使用することをお勧めします。また、並列TiDB Lightningインスタンスの数は 10 を超えないようにしてください。 - MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 を超える場合は、これらの MySQL インスタンスによってエクスポートされたデータをインポートするために 5 ～ 10 個のTiDB Lightningインスタンスを割り当てることをお勧めします。 -次に、このドキュメントでは、2 つの例を使用して、さまざまなシナリオでの並列インポートの操作手順を詳しく説明します。 +次に、このドキュメントでは、2つの例を使用して、さまざまなシナリオでの並列インポートの操作手順を詳しく説明します。 - 例1: Dumpling + TiDB Lightningを使用して、シャードデータベースとテーブルをTiDBに並列にインポートする - 例2: 単一のテーブルを並列にインポートする @@ -73,7 +73,7 @@ TiDB Lightning は実行時に一部のリソースを排他的に使用しま ### ステップ1: Dumplingを使用してデータをエクスポートする {#step-1-use-dumpling-to-export-data} -TiDB Lightningがデプロイされている 5 つのノード上の 2 つのシャード テーブルをエクスポートします。 +TiDB Lightningがデプロイされている 5つのノード上の 2つのシャード テーブルをエクスポートします。 - 2つのシャードテーブルが同じMySQLインスタンス内にある場合、 Dumplingのパラメータ`--filter`を使用して直接エクスポートできます。TiDB Lightningを使用してインポートする場合は、 Dumplingがデータをエクスポートするディレクトリとして`data-source-dir`を指定できます。 - 2つのシャードテーブルのデータが異なるMySQLノードに分散されている場合は、 Dumplingを使用して個別にエクスポートする必要があります。エクスポートしたデータは、同じ親ディレクトリ内、かつ異なるサブディレクトリに配置する必要があります。TiDB Lightningを使用して並列インポートを実行する場合は、親ディレクトリとして`data-source-dir`を指定する必要があります。 @@ -186,7 +186,7 @@ parallel-import = true ### 一部のTiDB Lightningノードが異常終了する {#some-tidb-lightning-nodes-exit-abnormally} -並列インポート中に 1 つ以上のTiDB Lightningノードが異常終了した場合は、ログに記録されたエラーに基づいて原因を特定し、エラーの種類に応じてエラーを処理します。 +並列インポート中に 1つ以上のTiDB Lightningノードが異常終了した場合は、ログに記録されたエラーに基づいて原因を特定し、エラーの種類に応じてエラーを処理します。 - エラーが通常の終了 (たとえば、kill コマンドに応答して終了) または OOM によるオペレーティング システムによる終了を示している場合は、構成を調整してから、 TiDB Lightningノードを再起動します。 diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index 66c9ddbf3e0bd..a47e16f83a4a7 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -74,7 +74,7 @@ TiDB Lightning がインポート中にエラーに遭遇した場合、終了 task-info-schema-name = 'lightning_task_info' ``` -TiDB Lightning はこのデータベースに 3 つのテーブルと 1 つのビューを作成します。 +TiDB Lightning はこのデータベースに 3つのテーブルと 1つのビューを作成します。 ```sql CREATE TABLE type_error_v1 ( @@ -229,7 +229,7 @@ CREATE VIEW conflict_view AS tiup tidb-lightning -c config.toml ``` -5. インポートされたテーブルに次の 2 つの通常の行のみが含まれていることを確認します。 +5. インポートされたテーブルに次の2つの通常の行のみが含まれていることを確認します。 ```sql $ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from example.t' @@ -241,7 +241,7 @@ CREATE VIEW conflict_view AS +---+-----+ ``` -6. `type_error_v1`テーブルに型変換を含む 3 つの行が含まれているかどうかを確認します。 +6. `type_error_v1`テーブルに型変換を含む 3つの行が含まれているかどうかを確認します。 ```sql $ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from lightning_task_info.type_error_v1;' -E @@ -274,7 +274,7 @@ CREATE VIEW conflict_view AS row_data: (600,'six hundred') ``` -7. `conflict_error_v3`テーブルに、一意/主キーの競合がある 4 つの行が含まれているかどうかを確認します。 +7. `conflict_error_v3`テーブルに、一意/主キーの競合がある 4つの行が含まれているかどうかを確認します。 ```sql $ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from lightning_task_info.conflict_error_v3;' --binary-as-hex -E diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index 3bff847040fa0..233826b9c1951 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -19,9 +19,9 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ 権限の詳細については[TiDB Lightningを使用するための前提条件](/tidb-lightning/tidb-lightning-requirements.md)を参照してください。 -## TiDB Lightning で1 つのテーブルのインポート中にエラーが発生しました。他のテーブルにも影響しますか？プロセスは終了しますか？ {#tidb-lightning-encountered-an-error-when-importing-one-table-will-it-affect-other-tables-will-the-process-be-terminated} +## TiDB Lightning で1つのテーブルのインポート中にエラーが発生しました。他のテーブルにも影響しますか？プロセスは終了しますか？ {#tidb-lightning-encountered-an-error-when-importing-one-table-will-it-affect-other-tables-will-the-process-be-terminated} -1 つのテーブルのみにエラーが発生した場合でも、残りのテーブルは正常に処理されます。 +1つのテーブルのみにエラーが発生した場合でも、残りのテーブルは正常に処理されます。 ## TiDB Lightningを適切に再起動するにはどうすればよいですか? {#how-to-properly-restart-tidb-lightning} diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 73f3b6603a734..ab4f56de1da9d 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -57,7 +57,7 @@ TiDB Lightning [インポートされたデータを検証する](/tidb-lightnin ### Chunk {#chunk} -ソース データの連続した範囲。通常は、データ ソース内の 1 つのファイルに相当します。 +ソース データの連続した範囲。通常は、データ ソース内の 1つのファイルに相当します。 ファイルが大きすぎる場合、 TiDB Lightning はファイルを複数のチャンクに分割することがあります。 @@ -121,7 +121,7 @@ TiDB Lightningは実行中に自動的にインポートモードを切り替え インデックスをソートする場合は[エンジン](/tidb-lightning/tidb-lightning-glossary.md#engine) 。 -インデックスの数に関係なく、すべてのテーブルは 1 つのインデックス エンジンに関連付けられます。 +インデックスの数に関係なく、すべてのテーブルは 1つのインデックス エンジンに関連付けられます。 TiDB Lightningは複数のインデックスエンジンを同時に処理します。これは`lightning.index-concurrency`設定によって制御されます。各テーブルには1つのインデックスエンジンがあるため、同時に処理できるテーブルの最大数も設定されます。 diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md index a5bed8633e131..c0a014edc1e0c 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -56,7 +56,7 @@ log-level = "error" | `"error"` | 競合するデータが検出された場合、インポートを中止します。 | `INSERT INTO ...` | | `""` | `"error"`に変換されました。これは、競合するデータが検出された場合、インポートを終了することを意味します。 | なし | -戦略が`"error"`の場合、競合するデータによって発生したエラーはインポートタスクを直接終了させます。戦略が`"replace"`または`"ignore"`の場合、 [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することで許容される競合の最大数を制御できます。デフォルト値は`10000`で、これは 10000 件のエラーが許容されることを意味します。 +戦略が`"error"`の場合、競合するデータによって発生したエラーはインポートタスクを直接終了させます。戦略が`"replace"`または`"ignore"`の場合、 [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することで許容される競合の最大数を制御できます。デフォルト値は`10000`で、これは 10000件のエラーが許容されることを意味します。 戦略が`"ignore"`の場合、競合するデータは下流の`conflict_records`テーブルに記録されます。詳細については、 [エラーレポート](/tidb-lightning/tidb-lightning-error-resolution.md#error-report)を参照してください。v8.1.0 より前は、 [`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することでレコードを制限でき、制限を超える競合データはスキップされ、記録されません。v8.1.0 以降は、TiDB Lightning が[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)入力に関係なく`max-record-rows`の値に`threshold`の値を自動的に割り当てるため、代わりにTiDB Lightning を設定する必要があります。 diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md index 3207cb81fa6cc..089723f73effa 100644 --- a/tidb-lightning/tidb-lightning-overview.md +++ b/tidb-lightning/tidb-lightning-overview.md @@ -27,7 +27,7 @@ TiDB Lightning は次のソースからデータを読み取ることができ ![Architecture of TiDB Lightning tool set](/media/tidb-lightning-architecture.png) -TiDB Lightning は、 `backend`で設定された 2 つのインポート モードをサポートしています。インポート モードによって、TiDB へのデータのインポート方法が決まります。 +TiDB Lightning は、 `backend`で設定された 2つのインポート モードをサポートしています。インポート モードによって、TiDB へのデータのインポート方法が決まります。 - [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) : TiDB Lightningは、まずデータをキーと値のペアにエンコードし、ローカルの一時ディレクトリに保存します。次に、これらのキーと値のペアを各TiKVノードにアップロードし、最後にTiKV 取り込みインターフェースを呼び出してTiKVのRocksDBにデータを挿入します。初期インポートを実行する必要がある場合は、インポート速度が速い物理インポートモードを検討してください。物理インポートモードのバックエンドは`local`です。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index 154bbdaee5413..fe0b1eb7ac54d 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -143,7 +143,7 @@ analyze = "optional" 旧バージョンの競合検出では、 TiDB Lightningは2つの戦略を提供していました。 - `remove` (推奨): ターゲット TiDB の一貫した状態を確保するために、ターゲット テーブルから競合するすべてのレコードを記録して削除します。 -- `none` : 重複レコードを検出しません。 `none` 2 つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 +- `none` : 重複レコードを検出しません。 `none` 2つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 バージョン5.3より前のTiDB Lightningは、競合検出をサポートしていません。競合データが存在する場合、インポート処理はチェックサムの段階で失敗します。競合検出が有効になっている場合、競合データが存在すると、 TiDB Lightningはチェックサムの段階をスキップします（常に失敗するため）。 @@ -272,7 +272,7 @@ io-concurrency = 5 `index-concurrency`と`table-concurrency`はインポート速度にほとんど影響を与えません。デフォルト値のままで問題ありません。 -`io-concurrency`ファイル読み取りの同時実行数を制御します。デフォルト値は 5 です。常に 5 つのハンドルのみが読み取り操作を実行します。ファイル読み取り速度は通常ボトルネックにならないため、この設定はデフォルト値のままにしておくことができます。 +`io-concurrency`ファイル読み取りの同時実行数を制御します。デフォルト値は 5 です。常に 5つのハンドルのみが読み取り操作を実行します。ファイル読み取り速度は通常ボトルネックにならないため、この設定はデフォルト値のままにしておくことができます。 ファイルデータが読み込まれた後、Lightning はデータのエンコードやローカルでのソートなどの後処理を行う必要があります。これらの操作の同時実行は`region-concurrency`によって制御されます。デフォルト値は CPU コア数です。この設定はデフォルト値のままにしておくことができます。Lightning は他のコンポーネントとは別のサーバーにデプロイすることをお勧めします。Lightning を他のコンポーネントと一緒にデプロイする必要がある場合は、負荷に応じて`region-concurrency`の値を下げる必要があります。 @@ -299,4 +299,4 @@ check-disk-quota = "30s" `disk-quota` TiDB Lightningが使用するストレージ容量を制限します。デフォルト値は MaxInt64 で、9223372036854775807 バイトです。この値はインポートに必要なディスク容量よりもはるかに大きいため、デフォルト値のままにしておくことは、ディスククォータを設定しないことと同じです。 -`check-disk-quota`は、ディスククォータをチェックする間隔です。デフォルト値は 60 秒です。TiDB Lightning がディスククォータをチェックすると、関連データに対して排他ロックを取得し、すべてのインポートスレッドをブロックします。そのため、 TiDB Lightning が書き込みの前に毎回ディスククォータをチェックすると、書き込み効率が大幅に低下します (シングルスレッド書き込みと同じくらい遅くなります)。効率的な書き込みを実現するために、ディスククォータは書き込みの前に毎回チェックされません。代わりに、 TiDB Lightning はすべてのインポートスレッドを一時停止し、 `check-disk-quota`間隔ごとにディスククォータをチェックします。つまり、 `check-disk-quota`の値を大きな値に設定すると、 TiDB Lightningが使用するディスク領域が設定したディスククォータを超える可能性があり、ディスククォータが無効になります。したがって、 `check-disk-quota`の値は小さい値に設定することをお勧めします。この項目の具体的な値は、 TiDB Lightningが実行される環境によって決まります。TiDB Lightning は、環境によって一時ファイルの書き込み速度が異なります。理論的には、書き込み速度が速いほど、 `check-disk-quota`の値は小さくする必要があります。 +`check-disk-quota`は、ディスククォータをチェックする間隔です。デフォルト値は 60秒です。TiDB Lightning がディスククォータをチェックすると、関連データに対して排他ロックを取得し、すべてのインポートスレッドをブロックします。そのため、 TiDB Lightning が書き込みの前に毎回ディスククォータをチェックすると、書き込み効率が大幅に低下します (シングルスレッド書き込みと同じくらい遅くなります)。効率的な書き込みを実現するために、ディスククォータは書き込みの前に毎回チェックされません。代わりに、 TiDB Lightning はすべてのインポートスレッドを一時停止し、 `check-disk-quota`間隔ごとにディスククォータをチェックします。つまり、 `check-disk-quota`の値を大きな値に設定すると、 TiDB Lightningが使用するディスク領域が設定したディスククォータを超える可能性があり、ディスククォータが無効になります。したがって、 `check-disk-quota`の値は小さい値に設定することをお勧めします。この項目の具体的な値は、 TiDB Lightningが実行される環境によって決まります。TiDB Lightning は、環境によって一時ファイルの書き込み速度が異なります。理論的には、書き込み速度が速いほど、 `check-disk-quota`の値は小さくする必要があります。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index d92ac86db023c..d53f079b94fe1 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -77,7 +77,7 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ - 複数のTiDB Lightningインスタンスを同時に実行して同じTiDBクラスタにデータをインポートする場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)を有効にしてインポートを調整できます。各インスタンスが**異なるテーブル**にデータをインポートする場合は、並列インポートオプションは必要ありません。ただし、複数のインスタンスが**同じテーブル**にデータをインポートする場合は、競合を防ぎ、データの整合性を確保するために、並列インポートを有効にする必要があります。 - 複数のTiDB Lightningを使用して同じターゲットクラスタにデータをインポートする場合、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。 - データのインポート中は、ターゲットテーブルでDDLおよびDML操作を実行しないでください。そうしないと、インポートが失敗したり、データの不整合が生じたりする可能性があります。また、読み取り操作は、読み取ったデータに不整合が生じる可能性があるため、実行しないことをお勧めします。インポート操作が完了したら、読み取りおよび書き込み操作を実行できます。 -- 1 つの Lightning プロセスでインポートできるのは、最大 10 TiB のテーブル 1 つだけです。並列インポートでは、最大 10 個の Lightning インスタンスを使用できます。 +- 1つの Lightning プロセスでインポートできるのは、最大 10 TiB のテーブル 1つだけです。並列インポートでは、最大 10 個の Lightning インスタンスを使用できます。 ### 他のコンポーネントと併用する場合のヒント {#tips-for-using-with-other-components} diff --git a/tidb-read-staleness.md b/tidb-read-staleness.md index 3520e26e0885a..8cfcf4d6e6915 100644 --- a/tidb-read-staleness.md +++ b/tidb-read-staleness.md @@ -9,14 +9,14 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ ## 機能の説明 {#feature-description} -システム変数`tidb_read_staleness` 、TiDB が現在のセッションで読み取ることができる履歴データの時間範囲を設定するために使用されます。この変数のデータ型は int 型で、スコープは`SESSION`です。値を設定すると、TiDB はこの変数で許可された範囲から可能な限り新しいタイムスタンプを選択し、以降のすべての読み取り操作はこのタイムスタンプに対して実行されます。例えば、この変数の値が`-5`に設定されている場合、TiKV に対応する履歴バージョンのデータが存在するという条件で、TiDB は 5 秒の時間範囲内で可能な限り新しいタイムスタンプを選択します。 +システム変数`tidb_read_staleness` 、TiDB が現在のセッションで読み取ることができる履歴データの時間範囲を設定するために使用されます。この変数のデータ型は int 型で、スコープは`SESSION`です。値を設定すると、TiDB はこの変数で許可された範囲から可能な限り新しいタイムスタンプを選択し、以降のすべての読み取り操作はこのタイムスタンプに対して実行されます。例えば、この変数の値が`-5`に設定されている場合、TiKV に対応する履歴バージョンのデータが存在するという条件で、TiDB は 5秒の時間範囲内で可能な限り新しいタイムスタンプを選択します。 `tidb_read_staleness`有効にした後でも、次の操作を実行できます。 - 現在のセッションでデータの挿入、変更、削除、またはDML操作を実行します。これらの文は`tidb_read_staleness`の影響を受けません。 - 現在のセッションで対話型トランザクションを開始します。このトランザクション内のクエリは最新のデータを読み取ります。 -履歴データを読み取った後、次の 2 つの方法で最新データを読み取ることができます。 +履歴データを読み取った後、次の2つの方法で最新データを読み取ることができます。 - 新しいセッションを開始します。 - `SET`ステートメントを使用して、変数`tidb_read_staleness`の値を`""`に設定します。 @@ -85,7 +85,7 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ この変数のスコープは`SESSION`です。値を設定すると、TiDB は値で設定された時間より前の最新バージョンのデータを読み取ります。 - 次の設定は、TiDB が 5 秒前から現在までの時間範囲内で可能な限り新しいタイムスタンプを選択し、それを履歴データの読み取り用のタイムスタンプとして使用することを示しています。 + 次の設定は、TiDB が 5秒前から現在までの時間範囲内で可能な限り新しいタイムスタンプを選択し、それを履歴データの読み取り用のタイムスタンプとして使用することを示しています。 ```sql set @@tidb_read_staleness="-5"; @@ -96,7 +96,7 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ > **Note:** > > - `tidb_read_staleness`の前には`@`ではなく`@@`を使用します。`@@`はシステム変数、 `@`はユーザー変数を意味します。 - > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5 秒であるため、手順 3 と手順 4 を 5 秒以内に完了する必要があります。 + > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5秒であるため、手順 3 と手順 4 を 5秒以内に完了する必要があります。 ここで読み取られるデータは更新前のデータ、つまり履歴データです。 diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 7fd625002c05c..22db46965cd85 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -144,7 +144,7 @@ TiDB Cloud Dedicated では、`CALIBRATE RESOURCE` ステートメントはサ [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)コマンドを使用して、クラスターのリソース グループを作成できます。 -既存のリソースグループの場合、 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)を使用して、リソースグループの`RU_PER_SEC`オプション (1 秒あたりの RU バックフィル率) を変更できます。リソースグループへの変更は即座に有効になります。 +既存のリソースグループの場合、 [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)を使用して、リソースグループの`RU_PER_SEC`オプション (1秒あたりの RU バックフィル率) を変更できます。リソースグループへの変更は即座に有効になります。 [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md)を使用してリソースグループを削除できます。 @@ -357,7 +357,7 @@ SELECT * FROM request_unit_by_group LIMIT 5; > **Note:** > -> `mysql.request_unit_by_group`のデータは、TiDB のスケジュールされたタスクによって毎日終了時に自動的にインポートされます。特定の日にリソース グループの RU 消費量が 0 の場合、レコードは生成されません。デフォルトでは、このテーブルには過去 3 か月 (最大 92 日) のデータが格納されます。この期間を超えるデータは自動的にクリアされます。 +> `mysql.request_unit_by_group`のデータは、TiDB のスケジュールされたタスクによって毎日終了時に自動的にインポートされます。特定の日にリソース グループの RU 消費量が 0 の場合、レコードは生成されません。デフォルトでは、このテーブルには過去 3 か月 (最大 92日) のデータが格納されます。この期間を超えるデータは自動的にクリアされます。 ## 指標とグラフのモニタリング {#monitoring-metrics-and-charts} diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 85820fb3f22e6..511af81d0a0b3 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -33,7 +33,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 システムリソースを枯渇させる過剰な同時実行のランナウェイクエリを回避するために、リソース制御機能では、ランナウェイクエリを迅速に識別して分離できる迅速な識別メカニズムを導入しています。 `WATCH`句を通じてこの機能を使用できます。クエリがランナウェイクエリとして識別されると、このメカニズムはクエリの一致する特徴 ( `WATCH`後のパラメータで定義) を抽出します。次の期間 ( `DURATION`で定義) に、ランナウェイクエリの一致する特徴が監視リストに追加され、TiDB インスタンスはクエリを監視リストと照合します。一致したクエリは、条件によって識別されるのを待たずに、直接ランナウェイクエリとしてマークされ、対応するアクションに従って分離されます。 `KILL`操作はクエリを終了し、エラー`Quarantined and interrupted because of being in runaway watch list`を報告します。 -`WATCH`素早く識別するために一致させる方法は 3 つあります。 +`WATCH`素早く識別するために一致させる方法は 3つあります。 - `EXACT` 、まったく同じ SQL テキストを持つ SQL ステートメントのみが迅速に識別されることを示します。 - `SIMILAR` 、同じパターンを持つすべての SQL ステートメントが SQL ダイジェストに一致し、リテラル値が無視されることを示します。 @@ -47,7 +47,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 | パラメータ | 説明 | 注記 | | ---------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | -| `EXEC_ELAPSED` | クエリ実行時間がこの値を超えると、暴走クエリとして識別されます。 | EXEC_ELAPSED = `60s` 、クエリの実行に 60 秒以上かかる場合、クエリがランナウェイ クエリとして識別されることを意味します。 | +| `EXEC_ELAPSED` | クエリ実行時間がこの値を超えると、暴走クエリとして識別されます。 | EXEC_ELAPSED = `60s` 、クエリの実行に 60秒以上かかる場合、クエリがランナウェイ クエリとして識別されることを意味します。 | | `PROCESSED_KEYS` | コプロセッサーによって処理されるキーの数がこの値を超えると、クエリは暴走クエリとして識別されます。 | `PROCESSED_KEYS = 1000` 、コプロセッサーによって処理されるキーの数が 1000 を超えると、クエリがランナウェイ クエリとして識別されることを意味します。 | | `RU` | クエリによって消費される読み取りおよび書き込みRUの合計数がこの値を超えると、このクエリはランナウェイクエリとして識別されます。 | `RU = 1000` 、クエリによって消費される読み取り RU と書き込み RU の合計数が 1000 を超える場合に、クエリがランナウェイ クエリとして識別されることを意味します。 | | `ACTION` | 暴走クエリが特定された場合のアクション | オプションの値は`DRYRUN` 、 `COOLDOWN` 、 `KILL` 、 `SWITCH_GROUP`です。 | @@ -59,13 +59,13 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ## 例 {#examples} -1. 1 秒あたり 500 RU のクォータを持つリソース グループ`rg1`を作成し、60 秒を超えるクエリをランナウェイ クエリとして定義し、ランナウェイ クエリの優先度を下げます。 +1. 1秒あたり 500 RU のクォータを持つリソース グループ`rg1`を作成し、60秒を超えるクエリをランナウェイ クエリとして定義し、ランナウェイ クエリの優先度を下げます。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN); ``` -2. `rg1`リソース グループを変更して、ランナウェイ クエリを終了し、次の 10 分以内に、同じパターンのクエリをランナウェイ クエリとして直ちにマークします。 +2. `rg1`リソース グループを変更して、ランナウェイ クエリを終了し、次の10分以内に、同じパターンのクエリをランナウェイ クエリとして直ちにマークします。 ```sql ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m'); @@ -87,7 +87,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 - `ACTION`の意味は`QUERY LIMIT`と同じです。このパラメータは省略可能です。省略した場合、識別後の対応するアクションは、リソースグループ内の`QUERY LIMIT`で設定された`ACTION`を採用し、 `QUERY LIMIT`設定によってアクションは変更されません。リソースグループ内に`ACTION`が設定されていない場合は、エラーが報告されます。 -- `QueryWatchTextOption`パラメータには、 `SQL DIGEST` 、 `PLAN DIGEST` 、 `SQL TEXT` 3 つのオプションがあります。 +- `QueryWatchTextOption`パラメータには、 `SQL DIGEST` 、 `PLAN DIGEST` 、 `SQL TEXT` 3つのオプションがあります。 - `SQL DIGEST`は`SIMILAR`と同じです。以下のパラメータは、文字列、ユーザー定義変数、または文字列を返すその他の式を受け入れます。文字列の長さは64文字でなければなりません。これはTiDBのダイジェスト定義と同じです。 - `PLAN DIGEST`は`PLAN`と同じです。次のパラメータはダイジェスト文字列です。 - `SQL TEXT`入力SQLを生の文字列（ `EXACT` ）として一致させるか、次のパラメータに応じて`SQL DIGEST` （ `SIMILAR` ）または`PLAN DIGEST` （ `PLAN` ）に解析してコンパイルします。 @@ -144,7 +144,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイ クエリに関する詳細情報は、次のシステム テーブルおよび`INFORMATION_SCHEMA`から取得できます。 -- `mysql.tidb_runaway_queries`テーブルには、過去 7 日間に特定されたすべてのランナウェイクエリの履歴レコードが含まれています。例として、1 つの行を見てみましょう。 +- `mysql.tidb_runaway_queries`テーブルには、過去 7日間に特定されたすべてのランナウェイクエリの履歴レコードが含まれています。例として、1つの行を見てみましょう。 ```sql MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G diff --git a/tidb-scheduling.md b/tidb-scheduling.md index c028242642856..e15f2298c540b 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -14,7 +14,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン ここで、次のような状況について考えてみましょう。 - ストレージスペースを効率的に利用するには、同じリージョンの複数のレプリカを、リージョンのサイズに応じて異なるノードに適切に分散する必要があります。 -- 複数のデータセンター トポロジの場合、1 つのデータセンターに障害が発生すると、すべてのリージョンの 1 つのレプリカのみが失敗します。 +- 複数のデータセンター トポロジの場合、1つのデータセンターに障害が発生すると、すべてのリージョンの 1つのレプリカのみが失敗します。 - 新しい TiKV ストアが追加されると、そのストアにデータを再バランスさせることができます。 - TiKV ストアに障害が発生した場合、PD は次のことを考慮する必要があります。 - 障害が発生したストアの回復時間。 @@ -31,7 +31,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン ## スケジュール要件 {#scheduling-requirements} -上記の状況は、次の 2 つのタイプに分類できます。 +上記の状況は、次の2つのタイプに分類できます。 1. 分散型で可用性の高いストレージシステムは、次の要件を満たす必要があります。 @@ -53,7 +53,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン ## 基本的なスケジュール演算子 {#basic-scheduling-operators} -すべてのスケジュール プランには、次の 3 つの基本演算子が含まれています。 +すべてのスケジュール プランには、次の3つの基本演算子が含まれています。 - 新しいレプリカを追加する - レプリカを削除する @@ -96,7 +96,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン - オフラインレプリカの数 - データの読み取り/書き込み速度 -PD は 2 種類のハートビートによってクラスター情報を収集し、それに基づいて決定を下します。 +PD は 2種類のハートビートによってクラスター情報を収集し、それに基づいて決定を下します。 さらに、PDは拡張インターフェースからより多くの情報を取得し、より正確な判断を下すことができます。例えば、ストアのハートビートが途切れた場合、PDはピアが一時的にダウンしているのか、それとも永久にダウンしているのかを判断できません。PDはしばらく（デフォルトでは30分）待機し、それでもハートビートが受信されない場合はストアをオフラインと見なします。その後、PDはストア上のすべてのリージョンを他のストアに分散させます。 @@ -118,7 +118,7 @@ PDは、リージョンリーダーのハートビートから、リージョン ここでの「位置」は「マシン」とは異なることに注意してください。通常、PDは、ピアの障害によって複数のレプリカが失われるのを防ぐため、リージョンのレプリカが同じピアに存在しないようにすることしかできません。ただし、本番では、次のような要件がある場合があります。 -- 複数の TiKV ピアが 1 台のマシンに存在します。 +- 複数の TiKV ピアが 1台のマシンに存在します。 - TiKV ピアは複数のラックに配置されており、ラックに障害が発生してもシステムは利用可能であると予想されます。 - TiKV ピアは複数のデータセンターにあり、データセンターに障害が発生した場合でもシステムは利用可能であると予想されます。 diff --git a/tidb-storage.md b/tidb-storage.md index 0868f13bd2ca5..aca286089a29a 100644 --- a/tidb-storage.md +++ b/tidb-storage.md @@ -26,7 +26,7 @@ RocksDBは、Facebookがオープンソース化した優れたスタンドア ## Raftプロトコル {#raft-protocol} -さらに、TiKV の実装では、1 台のマシンに障害が発生した場合でもデータの安全性を確保するという、より困難な問題に直面します。 +さらに、TiKV の実装では、1台のマシンに障害が発生した場合でもデータの安全性を確保するという、より困難な問題に直面します。 簡単な方法は、データを複数のマシンに複製することです。こうすることで、1台のマシンに障害が発生しても、他のマシンのレプリカが引き続き利用可能になります。つまり、信頼性が高く、効率的で、レプリカに障害が発生した場合でも対処できるデータ複製スキームが必要です。これらはすべて、 Raftアルゴリズムによって可能になります。 @@ -58,7 +58,7 @@ TiKVは、キーと値の空間全体を連続するキーセグメントに分 - クラスター内のすべてのノードにデータを分散し、リージョンを基本単位として使用します。各ノードのリージョン数がほぼ同じになるようにしてください。 - リージョン内でRaftレプリケーションとメンバーシップ管理を実行します。 -これら 2 つのタスクは非常に重要なので、1 つずつ紹介します。 +これら2つのタスクは非常に重要なので、1つずつ紹介します。 - まず、データはキーに基づいて複数のリージョンに分割され、各リージョンのデータは1つのノードにのみ保存されます（複数のレプリカは無視されます）。TiDBシステムには、クラスター内のすべてのノードにリージョンを可能な限り均等に分散させるPDコンポーネントがあります。これにより、ストレージ容量が水平方向に拡張され（他のノードのリージョンは新しく追加されたノードに自動的にスケジュールされます）、負荷分散が実現されます（あるノードに大量のデータがある一方で、他のノードにはほとんどデータがないという状況は発生しません）。 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index bb52804fc4e0f..37e256f7179ed 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -11,7 +11,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング ### 1.1 クライアントから`Region is Unavailable`エラーが報告されました {#11-the-client-reports-region-is-unavailable-error} -- 1.1.1 `Region is Unavailable`エラーは通常、リージョンが一定期間利用できないことが原因です。 `TiKV server is busy`が発生する場合や、 `not leader`または`epoch not match` } が原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする場合があります。このような場合、TiDB は`backoff`再試行メカニズムを実行します。 `backoff`がしきい値 (デフォルトでは 20 秒) を超えると、エラーがクライアントに送信されます。 `backoff`のしきい値内であれば、このエラーはクライアントには表示されません。 +- 1.1.1 `Region is Unavailable`エラーは通常、リージョンが一定期間利用できないことが原因です。 `TiKV server is busy`が発生する場合や、 `not leader`または`epoch not match` } が原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする場合があります。このような場合、TiDB は`backoff`再試行メカニズムを実行します。 `backoff`がしきい値 (デフォルトでは 20秒) を超えると、エラーがクライアントに送信されます。 `backoff`のしきい値内であれば、このエラーはクライアントには表示されません。 - 1.1.2 複数のTiKVインスタンスが同時にメモリ不足（OOM）になると、OOM期間中にLeaderが存在しない状態になります。中国語版の[ケース991](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case991.md)を参照してください。 @@ -83,7 +83,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 詳細な原因と解決策については、 [`Information schema is changed`エラーが報告される理由](/faq/sql-faq.md#what-triggers-the-information-schema-is-changed-error)を参照してください。 - - 背景： `schema version`の増加数は、各 DDL 変更操作の`schema state`の数と一致しています。たとえば、 `create table`操作ではバージョン変更が 1 回、 `add column`操作ではバージョン変更が 4 回発生します。したがって、列変更操作が多すぎると`schema version`が急速に増加する可能性があります。詳細は[オンラインスキーマの変更](https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf)を参照してください。 + - 背景： `schema version`の増加数は、各 DDL 変更操作の`schema state`の数と一致しています。たとえば、 `create table`操作ではバージョン変更が 1回、 `add column`操作ではバージョン変更が 4回発生します。したがって、列変更操作が多すぎると`schema version`が急速に増加する可能性があります。詳細は[オンラインスキーマの変更](https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf)を参照してください。 - 3.1.4 TiDB はログに`information schema is out of date`を報告します @@ -171,7 +171,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ - 原因： - MySQL では、2 つの大きな精度`Decimal`を割り算し、結果が最大小数精度 ( `30`を超える場合、 `30`桁のみが予約され、エラーは報告されません。 + MySQL では、2つの大きな精度`Decimal`を割り算し、結果が最大小数精度 ( `30`を超える場合、 `30`桁のみが予約され、エラーは報告されません。 TiDB では、計算結果は MySQL と同じですが、 `Decimal`を表すデータ構造内では、小数点精度のフィールドが実際の精度を保持します。 @@ -239,7 +239,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.3.1 TiKV RocksDB は`write stall`を検出します。 - TiKV インスタンスには 2 つの RocksDB インスタンスがあり、1 つは`data/raft`にありRaftログを格納し、もう 1 つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 + TiKV インスタンスには 2つの RocksDB インスタンスがあり、1つは`data/raft`にありRaftログを格納し、もう 1つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。 @@ -434,7 +434,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - マスターbinlogがパージされているかどうかを確認してください。 - `relay.meta`に記録されている位置情報を確認してください。 - - `relay.meta`は空の GTID 情報を記録しました。DM-worker は終了時または 30 秒ごとに、メモリ内の GTID 情報を`relay.meta`に保存します。DM-worker が上流の GTID 情報を取得できない場合は、空の GTID 情報を`relay.meta`に保存します。詳細は、 [ケース772](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case772.md) （中国語）を参照してください。 + - `relay.meta`は空の GTID 情報を記録しました。DM-worker は終了時または 30秒ごとに、メモリ内の GTID 情報を`relay.meta`に保存します。DM-worker が上流の GTID 情報を取得できない場合は、空の GTID 情報を`relay.meta`に保存します。詳細は、 [ケース772](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case772.md) （中国語）を参照してください。 - `relay.meta`に記録されたbinlogイベントにより、不完全なリカバリプロセスがトリガーされ、誤ったGTID情報が記録されます。この問題はv1.0.2で修正されていますが、それ以前のバージョンでは発生する可能性があります。 @@ -448,7 +448,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 6.2.2 インポート速度が遅すぎる。 - - `region-concurrency`設定値が高すぎるため、スレッド競合が発生し、パフォーマンスが低下します。トラブルシューティング方法は次の 3 つです。 + - `region-concurrency`設定値が高すぎるため、スレッド競合が発生し、パフォーマンスが低下します。トラブルシューティング方法は次の3つです。 - 設定は、ログの先頭から`region-concurrency`検索することで見つけることができます。 - TiDB Lightning が他のサービス (たとえば Importer) とサーバーを共有している場合は、 `region-concurrency`そのサーバーの CPU コアの総数の 75% に手動で設定する必要があります。 diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md index 67b7174ba1bf3..ee6e3d60abee6 100644 --- a/tidb-upgrade-migration-guide.md +++ b/tidb-upgrade-migration-guide.md @@ -71,8 +71,8 @@ SET GLOBAL tidb_gc_life_time=60h; - **時間の見積もり**: 最適なハードウェア条件 (ディスク I/O またはネットワーク帯域幅のボトルネックがない) では、推定時間は次のとおりです。 - - バックアップ速度: 8 つのスレッドで TiKV ノードごとに 1 TiB のデータのバックアップに約 1 時間かかります。 - - 復元速度: TiKV ノードごとに 1 TiB のデータの復元には約 20 分かかります。 + - バックアップ速度: 8つのスレッドで TiKV ノードごとに 1 TiB のデータのバックアップに約1時間かかります。 + - 復元速度: TiKV ノードごとに 1 TiB のデータの復元には約20分かかります。 - **コンフィグレーションの整合性**：古いクラスタと新しいクラスタの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。 @@ -155,11 +155,11 @@ tiup cluster start # Start the cluster 増分データ レプリケーション中は、レプリケーション チャネルの状態を継続的に監視し、必要に応じて設定を調整します。 -- レイテンシ メトリック: `Changefeed checkpoint lag`が 5 分以内などの許容範囲内に留まることを確認します。 +- レイテンシ メトリック: `Changefeed checkpoint lag`が 5分以内などの許容範囲内に留まることを確認します。 - スループットの健全性: `Sink flush rows/s`が一貫してビジネス書き込みレートを超えていることを確認します。 - エラーとアラート: TiCDC ログとアラート情報を定期的に確認してください。 - (オプション) テスト データ レプリケーション: テスト データを更新し、Changefeed がそれを新しいクラスターに正しく複製することを確認します。 -- (オプション) TiCDC 構成項目[`gc-ttl`](/ticdc/ticdc-server-config.md#gc-ttl)を調整します (デフォルトは 24 時間)。 +- (オプション) TiCDC 構成項目[`gc-ttl`](/ticdc/ticdc-server-config.md#gc-ttl)を調整します (デフォルトは 24時間)。 レプリケーションタスクが利用できない、または中断され、時間内に解決できない場合、 `gc-ttl` TiCDC に必要なデータがガベージコレクション(GC) によって消去されることなく TiKV に保持されることを保証します。この期間を超えると、レプリケーションタスクは`failed`状態になり、回復できなくなります。この場合、PD の GC セーフポイントは引き続き前進し、プロセスを再開するには新しいバックアップが必要になります。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 56c2d7c560b15..c03c0180287e2 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -9,7 +9,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ ## TiFlashクラスタのリソース利用率 {#resource-utilization-of-a-tiflash-cluster} -次の 3 つのメトリックを使用すると、 TiFlashクラスターのリソース使用率を簡単に取得できます。 +次の3つのメトリックを使用すると、 TiFlashクラスターのリソース使用率を簡単に取得できます。 - CPU: TiFlashインスタンスごとの CPU 使用率。 - メモリ: TiFlashインスタンスごとのメモリ使用量。 @@ -40,7 +40,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次のメトリックを使用して、 TiFlashのレイテンシーを取得できます。 -- リクエスト期間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエスト タイプの 1 秒あたりの合計処理期間の積み上げグラフを提供します。 +- リクエスト期間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエスト タイプの 1秒あたりの合計処理期間の積み上げグラフを提供します。 - リクエストのタイプが`run_mpp_task` 、 `dispatch_mpp_task` 、または`mpp_establish_conn`の場合、SQL文の実行がTiFlashに部分的または完全にプッシュダウンされたことを示します。これには通常、結合操作とデータ分散操作が含まれます。これはTiFlashで最も一般的なリクエストタイプです。 - リクエストのタイプが`cop`の場合、そのリクエストに関連するステートメントがTiFlashに完全にプッシュダウンされていないことを示します。通常、TiDB はデータアクセスとフィルタリングのために、テーブルフルスキャン演算子をTiFlashにプッシュダウンします。積み上げチャートで`cop`が最も多く表示されるリクエストタイプになった場合は、それが妥当かどうかを確認する必要があります。 @@ -110,6 +110,6 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 例2: パブリッククラウド導入環境におけるRaftとIOメトリクス[CH-benCHmark ワークロード](/benchmark/benchmark-tidb-using-ch.md) -次の図に示すように、 `Raft Wait Index Duration`の 99 パーセンタイルは最大 438 ミリ秒、 `Raft Batch Read Index Duration`の 99 パーセンタイルは最大 125 ミリ秒です。このクラスターにはTiFlashノードが 1 つだけあります。TiKV は、1 秒あたり約 5 MB の増分データをTiFlashに複製します。安定レイヤー(ファイル記述子) の最大書き込みトラフィックは 78 MB/秒、最大読み取りトラフィックは 221 MB/秒です。一方、デルタレイヤー(ページ) の最大書き込みトラフィックは 8 MB/秒、最大読み取りトラフィックは 18 MB/秒です。この環境では、 TiFlash は比較的 IO スループットが低い AWS EBS クラウドディスクを使用しています。 +次の図に示すように、 `Raft Wait Index Duration`の 99 パーセンタイルは最大 438 ミリ秒、 `Raft Batch Read Index Duration`の 99 パーセンタイルは最大 125 ミリ秒です。このクラスターにはTiFlashノードが 1つだけあります。TiKV は、1秒あたり約 5 MB の増分データをTiFlashに複製します。安定レイヤー(ファイル記述子) の最大書き込みトラフィックは 78 MB/秒、最大読み取りトラフィックは 221 MB/秒です。一方、デルタレイヤー(ページ) の最大書き込みトラフィックは 8 MB/秒、最大読み取りトラフィックは 18 MB/秒です。この環境では、 TiFlash は比較的 IO スループットが低い AWS EBS クラウドディスクを使用しています。 ![CH-TiFlash-MPP](/media/performance/tiflash/ch-1tiflash-raft-io-flow-cloud.png) diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index 9475153bc0de5..b925fbfab0f3a 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -125,7 +125,7 @@ TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version ## v6.x または v7.x から`storage.format_version = 5`が設定された v7.3 へ {#from-v6-x-or-v7-x-to-v7-3-with-storage-format-version-5-configured} -TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1 つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash構成パラメータ](/tiflash/tiflash-configuration.md) `storage.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータ圧縮時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。 +TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash構成パラメータ](/tiflash/tiflash-configuration.md) `storage.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータ圧縮時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。 TiFlashをv7.3にアップグレードし、V3 DTFilesを使用するように設定した後、 TiFlashを以前のバージョンに戻す必要がある場合は、DTToolをオフラインで使用してV3 DTFilesをV2 DTFilesに書き換えることができます。詳細については、 [DTTool 移行ツール](/tiflash/tiflash-command-line-flags.md#dttool-migrate)を参照してください。 diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 139210ae1fb4a..b961b326d17f7 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -25,7 +25,7 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; 同じテーブルに対して複数のDDL文を実行した場合、最後に実行された文のみが確実に有効になります。次の例では、テーブル`tpch50`に対して2つのDDL文が実行されていますが、2番目の文（レプリカを削除する文）のみが確実に有効になります。 -テーブルのレプリカを 2 つ作成します。 +テーブルのレプリカを 2つ作成します。 ```sql ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 2; @@ -69,7 +69,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ' 上記のステートメントの結果は次のようになります。 - `AVAILABLE`は、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`は使用可能、 `0`は使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 -- `PROGRESS`はレプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`は少なくとも 1 つのレプリカがレプリケートされていることを意味します。 +- `PROGRESS`はレプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`は少なくとも 1つのレプリカがレプリケートされていることを意味します。 ## データベースのTiFlashレプリカを作成する {#create-tiflash-replicas-for-databases} @@ -83,7 +83,7 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; 例: -- データベース`tpch50`内のすべてのテーブルに対して 2 つのレプリカを作成します。 +- データベース`tpch50`内のすべてのテーブルに対して 2つのレプリカを作成します。 ```sql ALTER DATABASE `tpch50` SET TIFLASH REPLICA 2; @@ -100,7 +100,7 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; > - この文は実際には一連のDDL操作を実行しますが、これらの操作はリソースを大量に消費します。文の実行中に中断された場合、実行済みの操作はロールバックされず、未実行の操作は続行されません。 > > - ステートメント実行後、**このデータベース内のすべてのテーブルがレプリケートされる**まで、 TiFlashレプリカの数を設定したり、このデータベースに対してDDL操作を実行したりしないでください。そうしないと、次のような予期しない結果が発生する可能性があります。 -> - TiFlashレプリカの数を 2 に設定し、データベース内のすべてのテーブルがレプリケートされる前にその数を 1 に変更した場合、すべてのテーブルのTiFlashレプリカの最終的な数は必ずしも 1 または 2 になるとは限りません。 +> - TiFlashレプリカの数を2に設定し、データベース内のすべてのテーブルがレプリケートされる前にその数を1に変更した場合、すべてのテーブルのTiFlashレプリカの最終的な数は必ずしも 1 または 2 になるとは限りません。 > - ステートメントを実行した後、ステートメントの実行が完了する前にこのデータベースにテーブルを作成すると、これらの新しいテーブルに対してTiFlashレプリカが作成される**場合と作成されない場合があります**。 > - ステートメントを実行した後、ステートメントの実行が完了する前にデータベース内のテーブルのインデックスを追加すると、ステートメントがハングし、インデックスが追加された後にのみ再開される可能性があります。 > @@ -281,7 +281,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla -ラベルを使用してレプリカをスケジュールする方法の詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md) 、 [1 つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md) 、および[2 つの地域に配置された 3 つのデータ センター](/three-data-centers-in-two-cities-deployment.md)を参照してください。 +ラベルを使用してレプリカをスケジュールする方法の詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md) 、 [1つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md) 、および[2つの地域に配置された 3つのデータ センター](/three-data-centers-in-two-cities-deployment.md)を参照してください。 TiFlashは、異なるゾーンに対するレプリカ選択戦略の設定をサポートしています。詳細については、 [`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)を参照してください。 diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index 6c9f14dc152f5..fbcc234b8940f 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -9,7 +9,7 @@ summary: TiFlashクラスターを保守する際の一般的な操作を学習 ## TiFlashのバージョンを確認する {#check-the-tiflash-version} -TiFlash のバージョンを確認するには、次の 2 つの方法があります。 +TiFlash のバージョンを確認するには、次の2つの方法があります。 - TiFlashのバイナリファイル名が`tiflash`の場合、 `./tiflash version`コマンドを実行することでバージョンを確認できます。 diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index 814faa99789b3..c1b17c9a2b331 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -27,7 +27,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas - 稼働時間: 前回の再起動以降のTiFlashの実行時間。 - メモリ: TiFlashインスタンスごとのメモリ使用量。 - CPU 使用率: TiFlashインスタンスごとの CPU 使用率。 -- FSync OPS: TiFlashインスタンスあたりの 1 秒あたりの fsync 操作の数。 +- FSync OPS: TiFlashインスタンスあたりの 1秒あたりの fsync 操作の数。 - ファイルオープン OPS: TiFlashインスタンスあたりの`open`秒あたりの操作数。 - 開かれたファイル数: 現在各TiFlashインスタンスによって開かれているファイル記述子の数。 @@ -63,21 +63,21 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas - スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 - スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 -- スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 +- スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1分あたりに実行された特定の DDL 操作の数。 - スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 ## ストレージ {#storage} -- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1 秒あたりに受信される書き込み要求の数。 -- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`はこの開始以降の書き込み増幅で、 `5min`は過去 5 分間の書き込み増幅です。 -- 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1 秒あたりの読み取りタスクの数。 -- 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 -- 内部タスク OPS: すべてのTiFlashインスタンスが 1 秒あたりに内部データ ソート タスクを実行する回数。 +- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1秒あたりに受信される書き込み要求の数。 +- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`はこの開始以降の書き込み増幅で、 `5min`は過去 5分間の書き込み増幅です。 +- 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1秒あたりの読み取りタスクの数。 +- 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 +- 内部タスク OPS: すべてのTiFlashインスタンスが 1秒あたりに内部データ ソート タスクを実行する回数。 - 内部タスクの所要時間: すべてのTiFlashインスタンスが内部データ ソート タスクに費やした時間。 -- ページ GC タスク OPM: すべてのTiFlashインスタンスが 1 分間に Delta データ ソート タスクを実行する回数。 +- ページ GC タスク OPM: すべてのTiFlashインスタンスが 1分間に Delta データ ソート タスクを実行する回数。 - ページ GC タスクの所要時間: Delta データ ソート タスクを実行するためにすべてのTiFlashインスタンスで消費される時間の分布。 -- ディスク書き込み OPS: すべてのTiFlashインスタンスによる 1 秒あたりのディスク書き込み数。 -- ディスク読み取り OPS: すべてのTiFlashインスタンスによる 1 秒あたりのディスク読み取り数。 +- ディスク書き込み OPS: すべてのTiFlashインスタンスによる 1秒あたりのディスク書き込み数。 +- ディスク読み取り OPS: すべてのTiFlashインスタンスによる 1秒あたりのディスク読み取り数。 - 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 - 読み取りフロー: すべてのTiFlashインスタンスによるディスク読み取りのトラフィック。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index 817c185f1cf7b..3c0c01a19a90a 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -29,7 +29,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 説明： - 適用期間が 20 秒を超える確率が 99% を超えると、アラートがトリガーされます。 + 適用期間が 20秒を超える確率が 99% を超えると、アラートがトリガーされます。 - 解決： @@ -43,7 +43,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 説明： - 読み取りインデックスの継続時間が 3 秒を超える確率が 99% を超えると、アラートがトリガーされます。 + 読み取りインデックスの継続時間が 3秒を超える確率が 99% を超えると、アラートがトリガーされます。 > **Note:** > @@ -61,7 +61,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 説明： - TiFlashのリージョン Raft Index の待機時間が 2 秒を超える確率が 99% を超えると、アラートがトリガーされます。 + TiFlashのリージョン Raft Index の待機時間が 2秒を超える確率が 99% を超えると、アラートがトリガーされます。 - 解決： diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index a24e244de86ba..af2df25049a2d 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -43,7 +43,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま > **Note:** > -> セキュリティ上の理由から、DTTool は移行モードにおいて作業ディレクトリにロックを追加しようとします。そのため、同じディレクトリ内で同時に移行タスクを実行できるのは 1 つの DTTool のみです。ロックが解除されていない状態で DTTool を強制終了すると、後で DTTool を再実行しようとした際に移行タスクの実行が拒否される可能性があります。 +> セキュリティ上の理由から、DTTool は移行モードにおいて作業ディレクトリにロックを追加しようとします。そのため、同じディレクトリ内で同時に移行タスクを実行できるのは 1つの DTTool のみです。ロックが解除されていない状態で DTTool を強制終了すると、後で DTTool を再実行しようとした際に移行タスクの実行が拒否される可能性があります。 > > このような状況が発生した場合、LOCK ファイルを削除してもデータが破損しないことが分かっている場合は、作業ディレクトリ内の LOCK ファイルを手動で削除してロックを解除できます。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 2353338e9a656..17877cb74042a 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -141,28 +141,28 @@ 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 種類の要求に帯域幅を割り当てます。 +- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_write_weight` {#background_write_weight} - TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `foreground_read_weight` {#foreground_read_weight} - TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら4種類の要求に帯域幅を割り当てます。 - 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 - デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_read_weight` {#background_read_weight} - TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- 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% の割り当てを表します。 @@ -318,7 +318,7 @@ I/O トラフィック制限設定を構成します。 ##### `size` {#size} -- 1 つのログ ファイルのサイズ。 +- 1つのログ ファイルのサイズ。 - デフォルト値: `"100M"` ##### `count` {#count} diff --git a/tiflash/tiflash-late-materialization.md b/tiflash/tiflash-late-materialization.md index de5a8e816706d..3054b9169ff91 100644 --- a/tiflash/tiflash-late-materialization.md +++ b/tiflash/tiflash-late-materialization.md @@ -92,7 +92,7 @@ SET GLOBAL tidb_opt_enable_late_materialization=ON; フィルター条件が TableScan オペレーターにプッシュダウンされると、TableScan オペレーターの実行プロセスには主に次の手順が含まれます。 -1. 3 つの列``を読み取り、マルチバージョン同時実行制御 (MVCC) フィルタリングを実行し、MVCC ビットマップを生成します。 +1. 3つの列``を読み取り、マルチバージョン同時実行制御 (MVCC) フィルタリングを実行し、MVCC ビットマップを生成します。 2. フィルター条件に関連する列を読み取り、条件を満たす行をフィルターして、フィルター ビットマップを生成します。 3. MVCC ビットマップとフィルター ビットマップの間で`AND`演算を実行して、最終ビットマップを生成します。 4. 最終ビットマップに従って、残りの列の対応する行を読み取ります。 diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index a27e973868f3e..a5d961bb25bf6 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -48,7 +48,7 @@ EXPLAIN SELECT count(*) FROM t0 a JOIN t0 b ON a.id = b.id; 例えば、上記のクエリは各TiFlashノードに2つのMPPタスクを生成しますが、 `ExchangeSender_45`のエグゼキューターを含むMPPタスクは`ExchangeSender_21`エグゼキューターを含むMPPタスクに依存しています。同時実行性の高いシナリオでは、スケジューラーが各クエリに対して`ExchangeSender_45`のエグゼキューターを含むMPPタスクをスケジュールすると、システムはデッドロック状態になります。 -デッドロックを回避するために、 TiFlash は次の 2 つのレベルのスレッド制限を導入します。 +デッドロックを回避するために、 TiFlash は次の2つのレベルのスレッド制限を導入します。 - thread_soft_limit: システムで使用されるスレッド数を制限するために使用されます。特定のMPPタスクでは、デッドロックを回避するためにこの制限を超えることができます。 - thread_hard_limit: システムを保護するために使用されます。システムで使用されるスレッド数がハードリミットを超えると、 TiFlashはデッドロックを回避するためにエラーを報告します。 diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index 257d88c96be4c..fbd8db530f4b9 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -11,7 +11,7 @@ TiFlashでは、列指向レプリカはRaft Learnerコンセンサスアルゴ -TiDB Cloud を使用すると、HTAP ワークロードに応じて 1 つ以上のTiFlashノードを指定するだけで、HTAP クラスターを簡単に作成できます。クラスター作成時にTiFlashノード数を指定していない場合、またはTiFlashノードを追加したい場合は、ノード数を[クラスターのスケーリング](/tidb-cloud/scale-tidb-cluster.md)することで変更できます。 +TiDB Cloud を使用すると、HTAP ワークロードに応じて 1つ以上のTiFlashノードを指定するだけで、HTAP クラスターを簡単に作成できます。クラスター作成時にTiFlashノード数を指定していない場合、またはTiFlashノードを追加したい場合は、ノード数を[クラスターのスケーリング](/tidb-cloud/scale-tidb-cluster.md)することで変更できます。 @@ -54,7 +54,7 @@ TiFlash には次の主な機能があります。 TiFlash内のレプリカは、特別なロールであるRaft Learnerとして非同期的に複製されます。つまり、 TiFlashノードがダウンしたり、ネットワークのレイテンシーが長くなった場合でも、TiKV内のアプリケーションは正常に動作し続けることができます。 -このレプリケーション メカニズムは、自動負荷分散と高可用性という TiKV の 2 つの利点を継承しています。 +このレプリケーション メカニズムは、自動負荷分散と高可用性という TiKV の 2つの利点を継承しています。 - TiFlash は追加のレプリケーション チャネルに依存せず、多対多の方法で TiKV からデータを直接受信します。 - TiKV でデータが失われていない限り、いつでもTiFlashでレプリカを復元できます。 @@ -67,13 +67,13 @@ TiFlash が読み取り要求を受信するたびに、リージョンレプリ ### 賢い選択 {#intelligent-choice} -TiDB は、 TiFlash (列単位) または TiKV (行単位) の使用を自動的に選択するか、または 1 つのクエリで両方を使用して、最高のパフォーマンスを確保できます。 +TiDB は、 TiFlash (列単位) または TiKV (行単位) の使用を自動的に選択するか、または 1つのクエリで両方を使用して、最高のパフォーマンスを確保できます。 この選択メカニズムは、クエリ実行時に異なるインデックスを選択するTiDBのメカニズムに似ています。TiDBオプティマイザーは、読み取りコストの統計に基づいて適切な選択を行います。 ### コンピューティングの加速 {#computing-acceleration} -TiFlash は、次の 2 つの方法で TiDB のコンピューティングを高速化します。 +TiFlash は、次の2つの方法で TiDB のコンピューティングを高速化します。 - 列型ストレージエンジンは読み取り操作の実行においてより効率的です。 - TiFlash はTiDB のコンピューティング ワークロードの一部を共有します。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 8e5403f239723..2eaad7121ae73 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -47,7 +47,7 @@ SELECT app_name, country FROM t1; - TiFlashによるオンライン アプリケーションの提供 - TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。`INSERT INTO SELECT`を指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 + TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。`INSERT INTO SELECT`を指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 ## 例 {#example} diff --git a/tiflash/tiflash-spill-disk.md b/tiflash/tiflash-spill-disk.md index fdb84c57e470e..47e10e717ea65 100644 --- a/tiflash/tiflash-spill-disk.md +++ b/tiflash/tiflash-spill-disk.md @@ -15,7 +15,7 @@ summary: TiFlash がデータをディスクに書き出す方法と、書き出 ## こぼれを誘発する {#trigger-the-spilling} -TiFlash は、データをディスクに書き出すための 2 つのトリガー メカニズムを提供します。 +TiFlash は、データをディスクに書き出すための 2つのトリガー メカニズムを提供します。 - オペレータ レベルのスピル: 各オペレータのデータ スピルしきい値を指定することにより、 TiFlash がそのオペレータのデータをディスクにスピルするタイミングを制御できます。 - クエリ レベルのスピル: TiFlashノードでのクエリの最大メモリ使用量とスピルのメモリ比率を指定することにより、 TiFlash がクエリでサポートされている演算子のデータを必要に応じてディスクにスピルするタイミングを制御できます。 diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 9e54636e768ad..f3fabfaf97ee5 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -162,11 +162,11 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 - 値`count`がクラスター内の TiKV ノードの数以下の場合は、次の手順に進みます。 - - `count`の値がクラスタ内の TiKV ノードの数より大きい場合（例えば、テストクラスタに TiKV ノードが 1 つしかなく、 `count`が`3`の場合）、PD はTiFlashノードにリージョンピアを追加しません。この問題に対処するには、 `count`をクラスタ内の TiKV ノードの数以下の整数に変更してください。 + - `count`の値がクラスタ内の TiKV ノードの数より大きい場合（例えば、テストクラスタに TiKV ノードが 1つしかなく、 `count`が`3`の場合）、PD はTiFlashノードにリージョンピアを追加しません。この問題に対処するには、 `count`をクラスタ内の TiKV ノードの数以下の整数に変更してください。 > **Note:** > - > デフォルト値は`count`で、 `3`です。本番環境では、通常、この値は TiKV ノードの数よりも小さくなります。テスト環境で、リージョンレプリカが 1 つだけで問題ない場合は、この値を`1`に設定できます。 + > デフォルト値は`count`で、 `3`です。本番環境では、通常、この値は TiKV ノードの数よりも小さくなります。テスト環境で、リージョンレプリカが 1つだけで問題ない場合は、この値を`1`に設定できます。 ```shell curl -X POST -d '{ diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 10e52f71e2b05..9b93e53b12164 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -175,7 +175,7 @@ TiFlashは、 `Sum`列など、 `Distinct`列を受け入れる一部の集計 set @@tidb_opt_distinct_agg_push_down = ON; ``` -以下の例は、変数`tidb_opt_distinct_agg_push_down`を有効にする前と有効にした後のクエリ結果を示しています。この変数を有効にする前は、TiDB はTiFlashからすべてのデータを読み取り、TiDB 内で`distinct`を実行する必要があります。この変数を有効にすると、 `distinct a`がTiFlashにプッシュダウンされ、新しい`group by`列である`test.t.a`が`HashAgg_6`に追加されます。クエリ結果の 2 つの警告は、集計関数をTiFlashに完全にプッシュダウンできないことを示しています。 +以下の例は、変数`tidb_opt_distinct_agg_push_down`を有効にする前と有効にした後のクエリ結果を示しています。この変数を有効にする前は、TiDB はTiFlashからすべてのデータを読み取り、TiDB 内で`distinct`を実行する必要があります。この変数を有効にすると、 `distinct a`がTiFlashにプッシュダウンされ、新しい`group by`列である`test.t.a`が`HashAgg_6`に追加されます。クエリ結果の 2つの警告は、集計関数をTiFlashに完全にプッシュダウンできないことを示しています。 `tidb_opt_distinct_agg_push_down`が有効になる前: @@ -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`を再設定する前後のクエリ結果を示しています。`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-fastscan.md b/tiflash/use-fastscan.md index 0b3ca4961e5ef..3caea106779de 100644 --- a/tiflash/use-fastscan.md +++ b/tiflash/use-fastscan.md @@ -83,7 +83,7 @@ TiFlash は古いデータの圧縮をバックグラウンドで自動的に開 ## FastScanの仕組み {#mechanism-of-fastscan} -TiFlashのストレージレイヤーのデータは、デルタレイヤーと安定レイヤーの 2 つの層に保存されます。 +TiFlashのストレージレイヤーのデータは、デルタレイヤーと安定レイヤーの 2つの層に保存されます。 デフォルトでは、FastScan は有効になっておらず、TableScan オペレーターは次の手順でデータを処理します。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 64899a8b9b3f9..eb9e362854805 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -52,7 +52,7 @@ explain analyze select count(*) from test.t; -次の 2 つの構成レベルでエンジンを指定できます。 +次の2つの構成レベルでエンジンを指定できます。 - TiDBインスタンスレベル、つまりINSTANCEレベル。TiDB設定ファイルに以下の設定項目を追加します。 @@ -127,7 +127,7 @@ select /*+ read_from_storage(tiflash[alias_a,alias_b]) */ ... from table_name_1 ## スマート選択、エンジン分離、手動ヒントの関係 {#the-relationship-of-smart-selection-engine-isolation-and-manual-hint} -上記の 3 つのTiFlashレプリカの読み取り方法では、エンジン分離によって、使用可能なエンジンのレプリカの全体的な範囲が指定されます。この範囲内で、手動ヒントによって、よりきめ細かなステートメント レベルおよびテーブル レベルのエンジン選択が提供されます。最後に、CBO が決定を下し、指定されたエンジン リスト内のコスト見積もりに基づいてエンジンのレプリカを選択します。 +上記の3つのTiFlashレプリカの読み取り方法では、エンジン分離によって、使用可能なエンジンのレプリカの全体的な範囲が指定されます。この範囲内で、手動ヒントによって、よりきめ細かなステートメント レベルおよびテーブル レベルのエンジン選択が提供されます。最後に、CBO が決定を下し、指定されたエンジン リスト内のコスト見積もりに基づいてエンジンのレプリカを選択します。 > **Note:** > diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index d5f30ac63710e..360a48e69803f 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -27,7 +27,7 @@ TiFlashは、クエリ実行にMPPモードをサポートしています。こ 変数`tidb_allow_mpp` 、TiDBがクエリ実行時にMPPモードを選択できるかどうかを制御します。変数`tidb_enforce_mpp` 、オプティマイザのコスト見積もりを無視し、クエリ実行時にTiFlashのMPPモードを強制的に使用するかどうかを制御します。 -これら 2 つの変数のすべての値に対応する結果は次のとおりです。 +これら2つの変数のすべての値に対応する結果は次のとおりです。 | | tidb_allow_mpp=オフ | tidb_allow_mpp=on (デフォルト) | | --------------------------- | ----------------- | ----------------------------------------- | @@ -107,7 +107,7 @@ explain select count(*) from customer c join nation n on c.c_nationkey=n.n_natio この実行計画の例には、演算子`ExchangeReceiver`と演算子`ExchangeSender`含まれています。この実行計画は、演算子`ExchangeSender`テーブル`nation`読み取った後、各ノードにテーブルをブロードキャストし、演算子`HashJoin`と演算子`HashAgg`テーブル`nation`とテーブル`customer`に対して実行され、結果がTiDBに返されることを示しています。 -TiFlash は、ブロードキャスト ハッシュ結合を使用するかどうかを制御する次の 3 つのグローバル/セッション変数を提供します。 +TiFlash は、ブロードキャスト ハッシュ結合を使用するかどうかを制御する次の3つのグローバル/セッション変数を提供します。 - [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50) : 値の単位はバイトです。テーブルサイズ（バイト単位）が変数の値より小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 - [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50) : 値の単位は行です。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できないため、結果セットの行数によってサイズが決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 731ff4c2fbcfa..a3539eb831cb7 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -101,7 +101,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - TiKVが保持するログファイルの最大数。 - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はすべてのログ ファイルを保持します。 - - 設定項目が`0`以外の値に設定されている場合、TiKV は`max-backups`で指定された数までの古いログファイルを保持します。たとえば、値が`7`に設定されている場合、TiKV は最大 7 つの古いログファイルを保持します。 + - 設定項目が`0`以外の値に設定されている場合、TiKV は`max-backups`で指定された数までの古いログファイルを保持します。たとえば、値が`7`に設定されている場合、TiKV は最大 7つの古いログファイルを保持します。 - デフォルト値: `0` ## server {#server} @@ -2827,8 +2827,8 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ - リージョンがホットスポットとして識別されるトラフィックのしきい値を制御します。 - デフォルト値: - - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、1 秒あたり`30MiB` 。 - - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合、1 秒あたり`100MiB` 。 + - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、1秒あたり`30MiB` 。 + - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合、1秒あたり`100MiB` 。 ### `qps-threshold` {#qps-threshold} diff --git a/tikv-control.md b/tikv-control.md index a4d799da6fb61..6c3ae1a579c72 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -85,7 +85,7 @@ tiup ctl:v tikv ## 一般オプション {#general-options} -`tikv-ctl`には 2 つの動作モードがあります。 +`tikv-ctl`には 2つの動作モードがあります。 - リモートモード: `--host`オプションを使用して、TiKVのサービスアドレスを引数として受け入れます @@ -112,7 +112,7 @@ tiup ctl:v tikv 特に明記されていない限り、すべてのコマンドはリモート モードとローカル モードの両方をサポートします。 -さらに、 `tikv-ctl`は`--to-hex`と`--to-escaped` 2 つの簡単なコマンドがあり、これらを使用してキーの形式に簡単な変更を加えます。 +さらに、 `tikv-ctl`は`--to-hex`と`--to-escaped` 2つの簡単なコマンドがあり、これらを使用してキーの形式に簡単な変更を加えます。 通常は、キーの`escaped`形式を使用します。例： @@ -209,7 +209,7 @@ tikv-ctl --data-dir /path/to/tikv size -r 2 ### スキャンして特定の範囲のMVCCを表示する {#scan-to-view-mvcc-of-a-specific-range} -`scan`コマンドの`--from`および`--to`オプションは、2 つのエスケープ形式の生のキーを受け入れ、 `--show-cf`フラグを使用して、表示する必要がある列ファミリを指定します。 +`scan`コマンドの`--from`および`--to`オプションは、2つのエスケープ形式の生のキーを受け入れ、 `--show-cf`フラグを使用して、表示する必要がある列ファミリを指定します。 ```shell tikv-ctl --data-dir /path/to/tikv scan --from 'zm' --limit 2 --show-cf lock,default,write diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 16bda249b1db5..92e8ece2388df 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -121,7 +121,7 @@ LIMIT 5; 例： -以下の結果は、 `db1.tbl1`テーブルに深刻な MVCC 増幅を伴うクエリが存在することを示しています。TiKV は 1358517 個の MVCC バージョンを処理し、2 つのバージョンのみを返します。 +以下の結果は、 `db1.tbl1`テーブルに深刻な MVCC 増幅を伴うクエリが存在することを示しています。TiKV は 1358517 個の MVCC バージョンを処理し、2つのバージョンのみを返します。 ``` +----------------------------+-----+-------------------+--------------+------------+-----------------------------------+--------------------+--------------------+--------------------+ diff --git a/tikv-overview.md b/tikv-overview.md index 250261c76ebe7..02226162c515b 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -9,7 +9,7 @@ TiKVは、 ACID準拠のトランザクションAPIを提供する分散型ト ## アーキテクチャの概要 {#architecture-overview} -TiKV は、Google Spanner の設計に基づいて、マルチ raft グループ レプリカ メカニズムを実装しています。リージョンはキーと値のデータの移動の基本単位で、ストア内のデータ範囲を参照します。各リージョンは複数のノードに複製されます。これらの複数のレプリカがRaftグループを形成します。リージョンのレプリカはピアと呼ばれます。通常、リージョンには 3 つのピアがあります。そのうちの 1 つがリーダーで、読み取りおよび書き込みサービスを提供します。PDコンポーネントは、すべてのリージョンのバランスを自動的に調整して、TiKV クラスター内のすべてのノード間で読み取りおよび書き込みのスループットが均等になるようにします。PD と慎重に設計されたRaftグループにより、TiKV は水平方向のスケーラビリティに優れ、100 TB を超えるデータを簡単に保存できます。 +TiKV は、Google Spanner の設計に基づいて、マルチ raft グループ レプリカ メカニズムを実装しています。リージョンはキーと値のデータの移動の基本単位で、ストア内のデータ範囲を参照します。各リージョンは複数のノードに複製されます。これらの複数のレプリカがRaftグループを形成します。リージョンのレプリカはピアと呼ばれます。通常、リージョンには 3つのピアがあります。そのうちの 1つがリーダーで、読み取りおよび書き込みサービスを提供します。PDコンポーネントは、すべてのリージョンのバランスを自動的に調整して、TiKV クラスター内のすべてのノード間で読み取りおよび書き込みのスループットが均等になるようにします。PD と慎重に設計されたRaftグループにより、TiKV は水平方向のスケーラビリティに優れ、100 TB を超えるデータを簡単に保存できます。 ![TiKV Architecture](/media/tikv-arch.png) diff --git a/time-to-live.md b/time-to-live.md index 7f9ff6b4bb72b..bf907bf022668 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -171,7 +171,7 @@ TiDBはTTLに関する実行時情報を定期的に収集し、Grafanaでこれ -さらに、TiDB は TTL ジョブに関する詳細情報を取得するための 3 つのテーブルを提供します。 +さらに、TiDB は TTL ジョブに関する詳細情報を取得するための 3つのテーブルを提供します。 - `mysql.tidb_ttl_table_status`テーブルには、すべての TTL テーブルについて、以前に実行された TTL ジョブと進行中の TTL ジョブに関する情報が含まれています。 @@ -201,13 +201,13 @@ TiDBはTTLに関する実行時情報を定期的に収集し、Grafanaでこれ 1 row in set (0.040 sec) ``` - 列`table_id`はパーティションテーブルの ID であり、列`parent_table_id`はテーブルの ID で、列[`information_schema.tables`](/information-schema/information-schema-tables.md)の ID に対応します。テーブルがパーティションテーブルでない場合、2 つの ID は同じになります。 + 列`table_id`はパーティションテーブルの ID であり、列`parent_table_id`はテーブルの ID で、列[`information_schema.tables`](/information-schema/information-schema-tables.md)の ID に対応します。テーブルがパーティションテーブルでない場合、2つの ID は同じになります。 列`{last, current}_job_{start_time, finish_time, ttl_expire}`は、それぞれ、前回または現在実行中のTTLジョブで使用された開始時刻、終了時刻、有効期限を示します。列`last_job_summary`は、前回のTTLタスクの実行ステータス（合計行数、成功行数、失敗行数など）を示します。 - `mysql.tidb_ttl_task`テーブルには、実行中の TTL サブタスクに関する情報が含まれています。TTL ジョブは複数のサブタスクに分割され、このテーブルには現在実行中のサブタスクが記録されます。 -- `mysql.tidb_ttl_job_history`テーブルには、実行された TTL ジョブに関する情報が含まれています。TTL ジョブの履歴は 90 日間保存されます。 +- `mysql.tidb_ttl_job_history`テーブルには、実行された TTL ジョブに関する情報が含まれています。TTL ジョブの履歴は 90日間保存されます。 ```sql TABLE mysql.tidb_ttl_job_history LIMIT 1\G @@ -275,7 +275,7 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー - 削除がデータ サイズを比較的安定させるのに十分な速さであるかどうかをどのように判断すればよいでしょうか? - [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`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: + [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-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index c52f3cfac3f73..a42389f40de1a 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -31,7 +31,7 @@ summary: TiProxy のコマンドライン起動フラグについて学習しま ### TiProxyコントロールをインストールする {#install-tiproxy-control} -TiProxy Control は、次の 2 つの方法のいずれかを使用してインストールできます。 +TiProxy Control は、次の2つの方法のいずれかを使用してインストールできます。 > **Note:** > @@ -164,11 +164,11 @@ level = 'warning' オプション: - `--output` : (必須) トラフィック ファイルを保存するディレクトリを指定します。 -- `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`を指定すると 1 時間のトラフィックがキャプチャされます。 +- `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`を指定すると 1時間のトラフィックがキャプチャされます。 例： -次のコマンドは、 `10.0.1.10:3080`の TiProxy インスタンスに接続し、1 時間のトラフィックをキャプチャし、それを TiProxy インスタンスの`/tmp/traffic`ディレクトリに保存します。 +次のコマンドは、 `10.0.1.10:3080`の TiProxy インスタンスに接続し、1時間のトラフィックをキャプチャし、それを TiProxy インスタンスの`/tmp/traffic`ディレクトリに保存します。 ```shell tiproxyctl traffic capture --host 10.0.1.10 --port 3080 --output="/tmp/traffic" --duration=1h diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index bc2bdad048f40..67af21b6849f5 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -153,7 +153,7 @@ TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートさ > > - 仮想 IP は Linux オペレーティング システムでのみサポートされます。 > - TiProxy を実行する Linux ユーザーには、IP アドレスをバインドする権限が必要です。 -> - 1 つの TiProxy インスタンスの実際の IP アドレスと仮想 IP アドレスは、同じ CIDR 範囲内にある必要があります。 +> - 1つの TiProxy インスタンスの実際の IP アドレスと仮想 IP アドレスは、同じ CIDR 範囲内にある必要があります。 #### `interface` {#interface} @@ -218,7 +218,7 @@ TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートさ > > TiProxyは1時間に1回、ディスクから証明書を再読み込みします。そのため、ディスク上の証明書ファイルに加えた変更が有効になるまでに最大1時間かかる場合があります。 -`[security]`セクションには、名前の異なる TLS オブジェクトが 4 つあります。これらは設定形式とフィールドは同じですが、名前によって解釈が異なります。 +`[security]`セクションには、名前の異なる TLS オブジェクトが 4つあります。これらは設定形式とフィールドは同じですが、名前によって解釈が異なります。 ```toml [security] diff --git a/tiproxy/tiproxy-grafana.md b/tiproxy/tiproxy-grafana.md index ddf41c45c25b3..8cb4692a8ab4f 100644 --- a/tiproxy/tiproxy-grafana.md +++ b/tiproxy/tiproxy-grafana.md @@ -11,7 +11,7 @@ TiUPを使用してTiDBクラスターをデプロイする場合、監視シス Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、TiProxy、Node_exporterを含む一連のサブダッシュボードに分かれています。診断に役立つ多くのメトリクスが用意されています。各ダッシュボードには、パネルグループとそのパネルが含まれています。 -TiProxy には 4 つのパネルグループがあります。これらのパネルに表示されるメトリックは、TiProxy の現在のステータスを示します。 +TiProxy には 4つのパネルグループがあります。これらのパネルに表示されるメトリックは、TiProxy の現在のステータスを示します。 - **TiProxy-Server** : インスタンス情報。 - **TiProxy-Query-Summary** : CPS などの SQL クエリ メトリック。 @@ -24,7 +24,7 @@ TiProxy には 4 つのパネルグループがあります。これらのパネ - メモリ使用量: 各 TiProxy インスタンスのメモリ使用量 - 稼働時間: 前回の再起動以降の各 TiProxy インスタンスの実行時間 - 接続数: 各 TiProxy インスタンスに接続されているクライアントの数 -- 接続作成 OPM: 各 TiProxy インスタンスで 1 分ごとに作成される接続の数 +- 接続作成 OPM: 各 TiProxy インスタンスで 1分ごとに作成される接続の数 - 切断OPM：1分ごとの切断理由別の数。切断理由には以下が含まれます。 - 成功: クライアントは正常に切断されます - クライアントネットワークの切断：クライアントが切断前に`QUIT`コマンドを送信しない。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性がある。 @@ -47,9 +47,9 @@ TiProxy には 4 つのパネルグループがあります。これらのパネ - 所要時間: 平均、P95、P99 SQL文の実行時間。TiDBサーバーでのSQL文の実行時間も含まれるため、TiDB Grafanaパネルで表示される時間よりも長くなります。 - インスタンスごとのP99実行時間: 各TiProxyインスタンスのP99ステートメント実行時間 - バックエンド別のP99実行時間: 各TiDBインスタンスで実行されるステートメントのP99ステートメント実行時間 -- インスタンスごとの CPS: 各 TiProxy インスタンスの 1 秒あたりのコマンド数 -- バックエンド別の CPS: 各 TiDB インスタンスの 1 秒あたりのコマンド数 -- CPS by CMD: SQL コマンドの種類別にグループ化された 1 秒あたりのコマンド数 +- インスタンスごとの CPS: 各 TiProxy インスタンスの 1秒あたりのコマンド数 +- バックエンド別の CPS: 各 TiDB インスタンスの 1秒あたりのコマンド数 +- CPS by CMD: SQL コマンドの種類別にグループ化された 1秒あたりのコマンド数 - ハンドシェイク期間: クライアントと TiProxy 間のハンドシェイク フェーズの平均、P95、および P99 期間 ## バランス {#balance} @@ -74,8 +74,8 @@ TiProxy には 4 つのパネルグループがあります。これらのパネ ## 渋滞 {#traffic} -- バックエンドからのバイト/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1 秒あたりに送信されたデータの量 (バイト単位)。 -- バックエンドからのパケット/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1 秒あたりに送信された MySQL パケットの数。 -- バックエンドへのバイト/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1 秒あたりに送信されたデータの量 (バイト単位)。 -- バックエンドへのパケット数/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1 秒あたりに送信される MySQL パケットの数。 -- クロスロケーション バイト/秒: 各 TiProxy インスタンスから異なる場所にある TiDB インスタンスに 1 秒あたりに送信されるデータの量 (バイト単位)。 +- バックエンドからのバイト/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1秒あたりに送信されたデータの量 (バイト単位)。 +- バックエンドからのパケット/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1秒あたりに送信された MySQL パケットの数。 +- バックエンドへのバイト/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1秒あたりに送信されたデータの量 (バイト単位)。 +- バックエンドへのパケット数/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1秒あたりに送信される MySQL パケットの数。 +- クロスロケーション バイト/秒: 各 TiProxy インスタンスから異なる場所にある TiDB インスタンスに 1秒あたりに送信されるデータの量 (バイト単位)。 diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 163f57e675598..3c8288360879f 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -5,7 +5,7 @@ summary: TiProxy の負荷分散ポリシーとその適用可能なシナリオ # TiProxy 負荷分散ポリシー {#tiproxy-load-balancing-policies} -TiProxy v1.0.0 は、TiDB サーバーに対してステータスベースおよび接続数ベースの負荷分散ポリシーのみをサポートしています。v1.1.0 以降では、ラベルベース、ヘルスベース、メモリベース、CPU ベース、ロケーションベースの 5 つの負荷分散ポリシーが追加されています。 +TiProxy v1.0.0 は、TiDB サーバーに対してステータスベースおよび接続数ベースの負荷分散ポリシーのみをサポートしています。v1.1.0 以降では、ラベルベース、ヘルスベース、メモリベース、CPU ベース、ロケーションベースの 5つの負荷分散ポリシーが追加されています。 デフォルトでは、TiProxy は次の優先順位でこれらのポリシーを適用します。 @@ -38,9 +38,9 @@ TiProxy は、SQL ポートとステータス ポートを使用して、TiDBサ トランザクションとBIの両方のワークロードを処理するアプリケーションを考えてみましょう。これらのワークロードが互いに干渉しないようにするには、クラスターを次のように構成します。 1. TiProxy で[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)を`"app"`に設定すると、TiDB サーバーはラベル名`"app"`によって照合され、接続は一致するラベル値を持つ TiDB サーバーにルーティングされます。 -2. 少なくとも 2 つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 +2. 少なくとも 2つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 3. オプション：高可用性を実現するには、少なくとも4つのTiProxyインスタンスを導入し、ワークロードごとに異なる仮想IPアドレスを設定します。例えば、トランザクションワークロード用のTiProxyインスタンス2つを仮想IP `10.0.1.10/24`に設定し、BIワークロード用のインスタンス2つを仮想IP `10.0.1.20/24`に設定します。この機能を使用するには、TiProxy v1.3.1以降が必要です。 -4. TiDB インスタンスを 2 つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 +4. TiDB インスタンスを 2つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 6. 仮想IPが設定されている場合、トランザクションクライアントとBIクライアントはそれぞれ2つの仮想IPアドレスに接続します。仮想IPが設定されていない場合、トランザクションクライアントとBIクライアントはそれぞれ2つのTiProxyアドレスに接続します。 @@ -117,7 +117,7 @@ TiDBサーバーがOOMの危険にさらされている場合、TiProxyはその このポリシーには次の制限があります。 -- TiDBサーバーのメモリ使用量が急激に増加し、30 秒以内に OOM に達した場合、TiProxy は OOM のリスクを時間内に検出できず、接続が終了する可能性があります。 +- TiDBサーバーのメモリ使用量が急激に増加し、30秒以内に OOM に達した場合、TiProxy は OOM のリスクを時間内に検出できず、接続が終了する可能性があります。 - TiProxyは、クライアント接続を切断することなく維持することを目的としており、TiDBサーバーのメモリ使用量を削減してOOMを回避することを目的としているわけではありません。そのため、TiDBサーバーは依然としてOOMに遭遇する可能性があります。 - このポリシーはTiDBサーバーv8.0.0以降のバージョンにのみ適用されます。それより前のバージョンのTiDBサーバーでは、このポリシーは適用されません。 diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index 3c6bb1d433549..b105812a379fa 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -46,7 +46,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア > - TiProxyのCPU使用率が高いほど、トラフィックキャプチャによるQPSへの影響が大きくなります。本番クラスタへの影響を軽減するには、CPU容量の少なくとも30%を予約することをお勧めします。これにより、平均QPSが約3%低下します。詳細なパフォーマンスデータについては、 [トラフィックキャプチャテスト](/tiproxy/tiproxy-performance-test.md#traffic-capture-test)ご覧ください。 > - TiProxyはトラフィックを再度キャプチャする際に、以前のキャプチャファイルを自動的に削除しません。手動で削除する必要があります。 - たとえば、次のコマンドは、 `10.0.1.10:3080`の TiProxy インスタンスに接続し、1 時間のトラフィックをキャプチャし、それを TiProxy インスタンスの`/tmp/traffic`ディレクトリに保存します。 + たとえば、次のコマンドは、 `10.0.1.10:3080`の TiProxy インスタンスに接続し、1時間のトラフィックをキャプチャし、それを TiProxy インスタンスの`/tmp/traffic`ディレクトリに保存します。 ```shell tiproxyctl traffic capture --host 10.0.1.10 --port 3080 --output="/tmp/traffic" --duration=1h diff --git a/tiup/tiup-bench.md b/tiup/tiup-bench.md index 17a95ff01982c..d4038742be03f 100644 --- a/tiup/tiup-bench.md +++ b/tiup/tiup-bench.md @@ -75,7 +75,7 @@ Flags: TPC-Cテストを実行するための簡略化された手順を以下に示します。詳細な手順については、 [TiDBでTPC-Cテストを実行する方法](/benchmark/benchmark-tidb-using-tpcc.md)を参照してください。 -1. ハッシュを使用して 4 つのパーティションを使用して 4 つの倉庫を作成します。 +1. ハッシュを使用して 4つのパーティションを使用して 4つの倉庫を作成します。 ```shell tiup bench tpcc --warehouses 4 --parts 4 prepare diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 4beb3947d82c5..95df09dbfc0ad 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -226,7 +226,7 @@ component_versions: - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`pd`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`pd`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`pd`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`pd`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 @@ -280,7 +280,7 @@ pd_servers: - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`tidb`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tidb`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tidb`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tidb`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 @@ -332,7 +332,7 @@ tidb_servers: - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`tikv`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tikv`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tikv`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tikv`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 @@ -392,7 +392,7 @@ tikv_servers: - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`tiflash`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiflash`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tiflash`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiflash`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `learner_config` : 各TiFlashノードには特別な TiKV が組み込まれています。この設定項目は、この特別な TiKV を設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。 @@ -440,7 +440,7 @@ tiflash_servers: - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、 cpubind および membind ポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。値は NUMA ノードの ID（例： `"0,1"`です。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`tiproxy`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiproxy`内容とマージされます。これら 2 つのフィールドが重複している場合、このフィールドの内容が有効になります。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tiproxy`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiproxy`内容とマージされます。これら2つのフィールドが重複している場合、このフィールドの内容が有効になります。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 @@ -584,7 +584,7 @@ cdc_servers: - `port` : `tso`マイクロサービスのリスニングポートを指定します。デフォルト値は`3379`です。 - `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 - `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`tso`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tso`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tso`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tso`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 @@ -614,7 +614,7 @@ tso_servers: - `port` : `scheduling`マイクロサービスのリスニングポートを指定します。デフォルト値は`3379`です。 - `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 - `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`scheduling`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`scheduling`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`scheduling`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`scheduling`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 - `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 4160dc4380a41..781778a24029f 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -468,7 +468,7 @@ TiDB ホットフィックス パッケージが`/tmp/tidb-hotfix.tar.gz`にあ tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -R tidb ``` -クラスター内の 1 つの TiDB パッケージのみを置き換えることもできます。 +クラスター内の 1つの TiDB パッケージのみを置き換えることもできます。 ```bash tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -N 172.16.4.5:4000 diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index 31a96ca934b65..e43eaae19d106 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -5,7 +5,7 @@ summary: TiUP mirror genkey は、 TiUP用の秘密鍵を生成するための # tiup mirror genkey {#tiup-mirror-genkey} -TiUP [ミラー](/tiup/tiup-mirror-reference.md)の定義によれば、ユーザーには 3 つの役割があります。 +TiUP [ミラー](/tiup/tiup-mirror-reference.md)の定義によれば、ユーザーには 3つの役割があります。 - ミラー管理者: `root.json` 、 `index.json` 、 `snapshot.json` 、 `timestamp.json`を変更する権限があります。 - コンポーネント所有者: 対応するコンポーネントを変更する権限を持ちます。 diff --git a/tiup/tiup-command-mirror-grant.md b/tiup/tiup-command-mirror-grant.md index 2cecc2117da7f..bfef33e7c39fa 100644 --- a/tiup/tiup-command-mirror-grant.md +++ b/tiup/tiup-command-mirror-grant.md @@ -26,7 +26,7 @@ tiup mirror grant [flags] ### -k, --key {#k-key} - 導入されたコンポーネントの所有者のキーを指定します。このキーは公開キーまたは秘密キーのいずれかです。秘密キーの場合、 TiUP はそれを対応する公開キーに変換してからミラーに保存します。 -- キーは 1 つのコンポーネント所有者のみが使用できます。 +- キーは 1つのコンポーネント所有者のみが使用できます。 - データ型: `STRING` - デフォルト: "${TIUP_HOME}/keys/private.json" diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index b5bd6133e1a98..b6788e538bed3 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -5,7 +5,7 @@ summary: 「tiup mirror merge」コマンドは、1つまたは複数のミラ # tiup mirror merge {#tiup-mirror-merge} -`tiup mirror merge`コマンドは、1 つ以上のミラーを現在のミラーにマージするために使用されます。 +`tiup mirror merge`コマンドは、1つ以上のミラーを現在のミラーにマージするために使用されます。 このコマンドを実行するには、次の条件を満たしている必要があります。 diff --git a/tiup/tiup-command-mirror-rotate.md b/tiup/tiup-command-mirror-rotate.md index 5844cff05965b..4a8b550a040bd 100644 --- a/tiup/tiup-command-mirror-rotate.md +++ b/tiup/tiup-command-mirror-rotate.md @@ -13,7 +13,7 @@ summary: TiUPミラーローテートは、 TiUPミラー内のroot.jsonファ - index.json - snapshot.json - timestamp.json -- `root.json`の有効期限。公式ミラーの場合、有効期限は作成日`root.json`の 1 年後となります。 +- `root.json`の有効期限。公式ミラーの場合、有効期限は作成日`root.json`の 1年後となります。 TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup/tiup-mirror-reference.md)を参照してください。 diff --git a/tiup/tiup-command-mirror-set.md b/tiup/tiup-command-mirror-set.md index 3ac4da9e03f33..acabfbda6860a 100644 --- a/tiup/tiup-command-mirror-set.md +++ b/tiup/tiup-command-mirror-set.md @@ -5,7 +5,7 @@ summary: tiup mirror set コマンドは、現在のミラーをローカルフ # tiup mirror set {#tiup-mirror-set} -`tiup mirror set`コマンドは現在のミラーを切り替えるために使用され、ローカル ファイル システムとリモート ネットワーク アドレスの 2 つの形式のミラーをサポートします。 +`tiup mirror set`コマンドは現在のミラーを切り替えるために使用され、ローカル ファイル システムとリモート ネットワーク アドレスの 2つの形式のミラーをサポートします。 公式ミラーのアドレスは`https://tiup-mirrors.pingcap.com`です。 @@ -15,7 +15,7 @@ summary: tiup mirror set コマンドは、現在のミラーをローカルフ tiup mirror set [flags] ``` -``はミラー アドレスであり、次の 2 つの形式があります。 +``はミラー アドレスであり、次の2つの形式があります。 - ネットワークアドレス: `http`または`https`で始まります。例: `http://172.16.5.5:8080` 、 `https://tiup-mirrors.pingcap.com` 。 - ローカルファイルパス: ミラーディレクトリの絶対パス。例: `/path/to/local-tiup-mirror` 。 diff --git a/tiup/tiup-command-mirror-sign.md b/tiup/tiup-command-mirror-sign.md index 5662df4889b30..fc72beb1f6c5f 100644 --- a/tiup/tiup-command-mirror-sign.md +++ b/tiup/tiup-command-mirror-sign.md @@ -13,7 +13,7 @@ summary: tiup mirror sign` コマンドは、 TiUPミラー内のメタデータ tiup mirror sign [flags] ``` -``は署名するファイルのアドレスであり、次の 2 つの形式があります。 +``は署名するファイルのアドレスであり、次の2つの形式があります。 - HTTPまたはHTTPSで始まるネットワークアドレス（例： `http://172.16.5.5:8080/rotate/root.json` - ローカルファイルパス（相対パスまたは絶対パス） diff --git a/tiup/tiup-component-cluster-audit-cleanup.md b/tiup/tiup-component-cluster-audit-cleanup.md index a519260f95f0a..1293fa9bf59f9 100644 --- a/tiup/tiup-component-cluster-audit-cleanup.md +++ b/tiup/tiup-component-cluster-audit-cleanup.md @@ -20,7 +20,7 @@ tiup cluster audit cleanup [flags] - ログを保持する日数を指定します。 - データ型: `INT` - デフォルト値: `60` (日単位)。 -- デフォルトでは、過去 60 日以内に生成されたログが保持されます。つまり、60 日より前に生成されたログは削除されます。 +- デフォルトでは、過去 60日以内に生成されたログが保持されます。つまり、60日より前に生成されたログは削除されます。 ### -h, --help {#h-help} diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 344a888aa77cf..7446181218dbf 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -120,7 +120,7 @@ ext4パーティションのマウントオプションを確認してくださ ### Fioディスクパフォーマンステスト {#fio-disk-performance-test} -フレキシブル I/O テスター (fio) を使用して、次の 3 つのテスト項目を含む、 `data_dir`が配置されているディスクのパフォーマンスをテストします。 +フレキシブル I/O テスター (fio) を使用して、次の3つのテスト項目を含む、 `data_dir`が配置されているディスクのパフォーマンスをテストします。 - fio_randread_write_latency - fio_randread_write diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 30c43b093c74c..390d744b48d4b 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -63,7 +63,7 @@ tiup cluster reload [flags] ### --skip-restart {#--skip-restart} -`tiup cluster reload`コマンドは 2 つの操作を実行します。 +`tiup cluster reload`コマンドは 2つの操作を実行します。 - すべてのノード構成を更新します - 指定されたノードを再起動します diff --git a/tiup/tiup-component-cluster-template.md b/tiup/tiup-component-cluster-template.md index 7b04bd28ef057..36c9f7b2d60cd 100644 --- a/tiup/tiup-component-cluster-template.md +++ b/tiup/tiup-component-cluster-template.md @@ -16,12 +16,12 @@ tiup cluster template [flags] このオプションを指定しない場合、出力のデフォルト テンプレートには次のインスタンスが含まれます。 - 3つのPDインスタンス -- 3 つの TiKV インスタンス -- 3 つの TiDB インスタンス -- 2 つのTiFlashインスタンス +- 3つの TiKV インスタンス +- 3つの TiDB インスタンス +- 2つのTiFlashインスタンス - 1つのPrometheusインスタンス -- 1 つの Grafana インスタンス -- 1 つの Alertmanager インスタンス +- 1つの Grafana インスタンス +- 1つの Alertmanager インスタンス ## オプション {#options} diff --git a/tiup/tiup-component-cluster-tls.md b/tiup/tiup-component-cluster-tls.md index 86cd25cffd8a6..b8b4192a03260 100644 --- a/tiup/tiup-component-cluster-tls.md +++ b/tiup/tiup-component-cluster-tls.md @@ -17,7 +17,7 @@ tiup cluster tls [flags] > **Note:** > -> 現在、 `tiup cluster tls`コマンドは、単一の PD ノードを持つクラスタでのみ TLS の有効化または無効化をサポートしています。複数の PD ノードを持つクラスタの場合、TLS ステータスの切り替えによって PD ノード間で通信例外が発生する可能性があるため、 `tiup cluster tls`コマンドを直接実行するとエラーが返されます。複数の PD ノードを持つクラスタで TLS を有効化または無効化するには、まず PD ノードを 1 つのノードに[`scale-in`](/tiup/tiup-component-cluster-scale-in.md)から、 `tiup cluster tls`コマンドを実行してください。 +> 現在、 `tiup cluster tls`コマンドは、単一の PD ノードを持つクラスタでのみ TLS の有効化または無効化をサポートしています。複数の PD ノードを持つクラスタの場合、TLS ステータスの切り替えによって PD ノード間で通信例外が発生する可能性があるため、 `tiup cluster tls`コマンドを直接実行するとエラーが返されます。複数の PD ノードを持つクラスタで TLS を有効化または無効化するには、まず PD ノードを 1つのノードに[`scale-in`](/tiup/tiup-component-cluster-scale-in.md)から、 `tiup cluster tls`コマンドを実行してください。 ## オプション {#options} diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index ba1a2756ef5ae..3b9d720b9ef89 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -41,7 +41,7 @@ tiup dm reload [flags] ### --skip-restart {#skip-restart} -`tiup dm reload`コマンドは 2 つの操作を実行します。 +`tiup dm reload`コマンドは 2つの操作を実行します。 - すべてのノード構成を更新します - 指定されたノードを再起動します diff --git a/tiup/tiup-component-dm-template.md b/tiup/tiup-component-dm-template.md index 11253332382e8..e3ae8f4d69d81 100644 --- a/tiup/tiup-component-dm-template.md +++ b/tiup/tiup-component-dm-template.md @@ -15,11 +15,11 @@ tiup dm template [flags] このオプションを指定しない場合、出力のデフォルト テンプレートには次のインスタンスが含まれます。 -- 3 つの DM マスター インスタンス -- 3 つの DM ワーカー インスタンス +- 3つの DM マスター インスタンス +- 3つの DM ワーカー インスタンス - 1つのPrometheusインスタンス -- 1 つの Grafana インスタンス -- 1 つの Alertmanager インスタンス +- 1つの Grafana インスタンス +- 1つの Alertmanager インスタンス ## オプション {#options} diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 2139dbd4170bd..746d2f92f5ad2 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -12,7 +12,7 @@ TiUPミラーは、コンポーネントとそのメタデータを保存するT ## ミラーの作成と更新 {#create-and-update-mirror} -次の 2 つの方法のいずれかを使用してTiUPミラーを作成できます。 +次の2つの方法のいずれかを使用してTiUPミラーを作成できます。 - ミラーを最初から作成するには、 `tiup mirror init`を実行します。 - 既存のミラーからクローンを作成するには、 `tiup mirror clone`を実行します。 diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 9cfcdf1264da1..e65d1e430709b 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -9,7 +9,7 @@ TiDB 4.0以降、パッケージマネージャーであるTiUPにより、 TiUP ## TiUPをインストールする {#install-tiup} -Darwin と Linux の両方のオペレーティング システムで、1 つのコマンドを使用してTiUPをインストールできます。 +Darwin と Linux の両方のオペレーティング システムで、1つのコマンドを使用してTiUPをインストールできます。 ```bash curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh @@ -97,7 +97,7 @@ Flags: Use "tiup [command] --help" for more information about a command. ``` -出力は長くなりますが、次の 2 つの部分だけに注目してください。 +出力は長くなりますが、次の2つの部分だけに注目してください。 - 利用可能なコマンド - install:コンポーネントの特定のバージョンをインストールするために使用されます diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 3f2f6a71e8e64..69cee052aa79d 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -15,14 +15,14 @@ Playgroundコンポーネントの基本的な使用方法を以下に示しま tiup playground ${version} [flags] ``` -`tiup playground`コマンドを直接実行すると、 TiUP はローカルにインストールされている TiDB、TiKV、および PD コンポーネントを使用するか、これらのコンポーネントの安定版をインストールして、1 つの TiKV インスタンス、1 つの TiDB インスタンス、1 つの PD インスタンス、および 1 つのTiFlashインスタンスで構成される TiDB クラスタを起動します。 +`tiup playground`コマンドを直接実行すると、 TiUP はローカルにインストールされている TiDB、TiKV、および PD コンポーネントを使用するか、これらのコンポーネントの安定版をインストールして、1つの TiKV インスタンス、1つの TiDB インスタンス、1つの PD インスタンス、および 1つのTiFlashインスタンスで構成される TiDB クラスタを起動します。 このコマンドは実際には以下の操作を実行します。 - このコマンドではPlaygroundコンポーネントのバージョンが指定されていないため、 TiUP はまずインストールされているPlaygroundコンポーネントの最新バージョンを確認します。最新バージョンが v1.12.3 であると仮定すると、このコマンドは`tiup playground:v1.12.3`と同じように動作します。 - TiUP playgroundを使用してTiDB、TiKV、およびPDコンポーネントをインストールしていない場合、playgroundコンポーネントはこれらのコンポーネントの最新の安定版をインストールし、その後これらのインスタンスを起動します。 - このコマンドでは TiDB、PD、TiKVコンポーネントのバージョンが指定されていないため、 TiUP playground はデフォルトで各コンポーネントの最新バージョンを使用します。最新バージョンが v8.5.4 であると仮定すると、このコマンドは`tiup playground:v1.12.3 v8.5.4`と同じように動作します。 -- このコマンドでは各コンポーネントの数を指定しないため、 TiUP playground はデフォルトで、TiDB インスタンス、TiKV インスタンス、PD インスタンス、 TiFlashインスタンスがそれぞれ 1 つずつで構成される最小のクラスタを起動します。 +- このコマンドでは各コンポーネントの数を指定しないため、 TiUP playground はデフォルトで、TiDB インスタンス、TiKV インスタンス、PD インスタンス、 TiFlashインスタンスがそれぞれ 1つずつで構成される最小のクラスタを起動します。 - TiDB の各コンポーネントを起動した後、 TiUP Playgroundはクラスターが正常に起動したことを通知し、MySQL クライアントを介して TiDB クラスターに接続する方法や、 [TiDB Dashboard](/dashboard/dashboard-intro.md)にアクセスする方法など、いくつかの有用な情報を提供します。 Playgroundコンポーネントのコマンドラインフラグを表示するには、次のコマンドを使用できます。 diff --git a/tiup/tiup-terminology-and-concepts.md b/tiup/tiup-terminology-and-concepts.md index 9d526e0845366..690b20f8bc2e8 100644 --- a/tiup/tiup-terminology-and-concepts.md +++ b/tiup/tiup-terminology-and-concepts.md @@ -16,13 +16,13 @@ TiUPプログラムには、コンポーネントのダウンロード、アッ - `tiup [:version]`を通じてコンポーネントのバージョンを指定する場合: - コンポーネントにローカルにバージョンがインストールされていない場合、 TiUP はミラーサーバーから最新の安定バージョンをダウンロードします。 - - コンポーネントにローカルに 1 つ以上のバージョンがインストールされていて、指定されたバージョンがない場合、 TiUP はミラーサーバーから指定されたバージョンをダウンロードします。 + - コンポーネントにローカルに 1つ以上のバージョンがインストールされていて、指定されたバージョンがない場合、 TiUP はミラーサーバーから指定されたバージョンをダウンロードします。 - 指定されたバージョンのコンポーネントがローカルにインストールされている場合、 TiUP はインストールされているバージョンを実行するように環境変数を設定します。 - コンポーネントを`tiup `まで実行し、バージョンを指定しない場合: - コンポーネントにローカルにバージョンがインストールされていない場合、 TiUP はミラーサーバーから最新の安定バージョンをダウンロードします。 - - 1 つ以上のバージョンがローカルにインストールされている場合、 TiUP はインストールされている最新バージョンを実行するように環境変数を設定します。 + - 1つ以上のバージョンがローカルにインストールされている場合、 TiUP はインストールされている最新バージョンを実行するように環境変数を設定します。 ## TiUPミラー {#tiup-mirrors} diff --git a/topn-limit-push-down.md b/topn-limit-push-down.md index 2f3510d8dfb59..6521bc3f5178c 100644 --- a/topn-limit-push-down.md +++ b/topn-limit-push-down.md @@ -86,7 +86,7 @@ explain select * from t join s on t.a = s.a order by t.id limit 10; 6 rows in set (0.00 sec) ``` -TopN は`Inner Join`より前にプッシュダウンすることはできません。上記のクエリを例に挙げると、Join 後に 100 件のレコードを取得した場合、TopN 後には 10 件のレコードが残ります。しかし、最初に TopN を実行して 10 件のレコードを取得した場合、Join 後には 5 件のレコードしか残りません。このような場合、プッシュダウンの結果は異なります。 +TopN は`Inner Join`より前にプッシュダウンすることはできません。上記のクエリを例に挙げると、Join 後に 100件のレコードを取得した場合、TopN 後には 10件のレコードが残ります。しかし、最初に TopN を実行して 10件のレコードを取得した場合、Join 後には 5件のレコードしか残りません。このような場合、プッシュダウンの結果は異なります。 同様に、TopN は Outer Join の内部テーブルにプッシュダウンすることも、TopN のソートルールが`t.a+s.a`のように複数のテーブルの列に関連している場合もプッシュダウンすることはできません。TopN のソートルールが外部テーブルの列のみに依存している場合にのみ、TopN をプッシュダウンできます。 diff --git a/transaction-overview.md b/transaction-overview.md index 1e2aba4660687..1038c038fc146 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -290,7 +290,7 @@ START TRANSACTION WITH CAUSAL CONSISTENCY ONLY; TiDBはデフォルトで線形一貫性を保証します。線形一貫性の場合、トランザクション1がコミットされた後にトランザクション2がコミットされた場合、論理的にはトランザクション2はトランザクション1の後に発生するはずです。因果一貫性は線形一貫性よりも弱い保証です。因果一貫性の場合、2つのトランザクションのコミット順序と発生順序の一貫性が保証されるのは、トランザクション1とトランザクション2によってロックまたは書き込まれたデータが交差している場合のみです。つまり、2つのトランザクションはデータベースに既知の因果関係があることを意味します。現在、TiDBは外部因果関係の伝播をサポートしていません。 -因果一貫性が有効になっている 2 つのトランザクションには、次の特性があります。 +因果一貫性が有効になっている 2つのトランザクションには、次の特性があります。 - [潜在的な因果関係を持つトランザクションは、一貫した論理順序と物理的なコミット順序を持つ](#transactions-with-potential-causal-relationship-have-the-consistent-logical-order-and-physical-commit-order) - [因果関係のないトランザクションは、一貫した論理順序と物理的なコミット順序を保証しません](#transactions-with-no-causal-relationship-do-not-guarantee-consistent-logical-order-and-physical-commit-order) diff --git a/troubleshoot-data-inconsistency-errors.md b/troubleshoot-data-inconsistency-errors.md index ffe911f23cf67..1c26060c24232 100644 --- a/troubleshoot-data-inconsistency-errors.md +++ b/troubleshoot-data-inconsistency-errors.md @@ -65,7 +65,7 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st `ERROR 8003 (HY000): table count 3 != index(idx) count 2` -このエラーは、 [`ADMIN CHECK`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントが実行されたテーブルに行のキーと値のペアが 3 つあるが、インデックスのキーと値のペアが 2 つしかないことを示します。 +このエラーは、 [`ADMIN CHECK`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントが実行されたテーブルに行のキーと値のペアが 3つあるが、インデックスのキーと値のペアが 2つしかないことを示します。 #### エラー8134 {#error-8134} diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index ae18a5dff901b..b8ec9c5b55e86 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -19,7 +19,7 @@ I/Oの問題を特定する最も簡単な方法は、 TiUPによってデフォ **概要** > **システム情報** > **IO Util**では、クラスター内の各マシンのI/Oステータスを確認できます。この指標はLinux `iostat`モニターの`util`に似ています。パーセンテージが高いほど、ディスクI/O使用率が高いことを示します。 -- モニターで I/O 使用率が高いマシンが 1 台だけの場合、現在このマシンに読み取りおよび書き込みのホットスポットがある可能性があります。 +- モニターで I/O 使用率が高いマシンが 1台だけの場合、現在このマシンに読み取りおよび書き込みのホットスポットがある可能性があります。 - モニター内のほとんどのマシンの I/O 使用率が高い場合、クラスターの I/O 負荷が高くなっています。 上記の最初の状況（I/O使用率が高いマシンが1台のみ）の場合、**ディスクパフォーマンスダッシュボード**のI/Oメトリック（ `Disk Latency`や`Disk Load`など）をさらに観察し、異常の有無を確認できます。必要に応じて、fioツールを使用してディスクをチェックしてください。 @@ -28,12 +28,12 @@ I/Oの問題を特定する最も簡単な方法は、 TiUPによってデフォ TiDBクラスターのメインストレージコンポーネントはTiKVです。1つのTiKVインスタンスには2つのRocksDBインスタンスが含まれます。1つはRaftログを保存するためのもので、 `data/raft`に配置されています。もう1つは実データを保存するためのもので、 `data/db`に配置されています。 -**TiKV-Details** > **Raft IO**では、これら 2 つのインスタンスのディスク書き込みに関連するメトリックを確認できます。 +**TiKV-Details** > **Raft IO**では、これら2つのインスタンスのディスク書き込みに関連するメトリックを確認できます。 - `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。`.99`の応答時間は50ミリ秒以内である必要があります。 - `Apply log duration` ：このメトリックは、実データを格納するRockDBへの書き込みの応答時間を示します。 `.99`時間は100ミリ秒以内である必要があります。 -これら 2 つのメトリックには、書き込みホットスポットを表示するのに役立つ**サーバーごとの**監視パネルもあります。 +これら2つのメトリックには、書き込みホットスポットを表示するのに役立つ**サーバーごとの**監視パネルもあります。 #### 3番目のタイプの監視パネル {#the-third-type-of-monitoring-panels} diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index d3ac5174da5b9..a72fa8b86da28 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -35,7 +35,7 @@ Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue Value: rowID ``` -インデックス データには、一意インデックスと非一意インデックスの 2 種類があります。 +インデックス データには、一意インデックスと非一意インデックスの 2種類があります。 - 一意インデックスの場合は、上記のコーディング規則に従うことができます。 - 非一意インデックスの場合、このエンコーディングでは一意キーを構築できません。これは、同じインデックスの`tablePrefix{TableID}_indexPrefixSep{IndexID}`は同じですが、複数の行の`ColumnsValue`は同じになる可能性があるためです。非一意インデックスのエンコーディング規則は次のとおりです。 diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 7657c5b8858e1..7de9286c79b95 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -102,7 +102,7 @@ Resolver: ### ログを使用して診断する {#use-logs-to-diagnose} -TiKV は 10 秒ごとに次のメトリックをチェックします。 +TiKV は 10秒ごとに次のメトリックをチェックします。 - resolved-tsが最小であるリージョンリーダー - safe-tsが最小のリージョンフォロワー diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index 8924fc884e818..895ec27f54e7b 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -73,7 +73,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - ファイルは使用中です。 - 1 つのデータベース ファイル ディレクトリで 2 つの TiKV ファイルを開かないでください。 + 1つのデータベース ファイル ディレクトリで 2つの TiKV ファイルを開かないでください。 ## `pd-server`を起動できません {#cannot-start-pd-server} diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index aff161dc71446..cf780a0aa88fd 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -107,7 +107,7 @@ OOM 問題のさまざまな原因に応じて、SQL ステートメントのメ メモリ容量を計画する必要があります。トランザクションが実行されると、TiDBプロセスのメモリ使用量はトランザクションサイズに応じて増加し、最大でトランザクションサイズの2～3倍以上にまで達することがあります。 -1 つの大きなトランザクションを複数の小さなトランザクションに分割できます。 +1つの大きなトランザクションを複数の小さなトランザクションに分割できます。 #### 統計情報を収集して読み込むプロセスはメモリを大量に消費します {#the-process-of-collecting-and-loading-statistical-information-consumes-too-much-memory} diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 2cafd6d71174c..f6b0dac71ca5e 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -15,7 +15,7 @@ TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/ クライアントが TiDB に`COMMIT`リクエストを送信すると、TiDB は 2PC プロセスを開始します。 -1. TiDB は、トランザクション内のすべてのキーから 1 つのキーをトランザクションの主キーとして選択します。 +1. TiDB は、トランザクション内のすべてのキーから 1つのキーをトランザクションの主キーとして選択します。 2. TiDBは、このコミットに関係するすべてのTiKVリージョンに`prewrite`リクエストを送信します。TiKVは、すべてのキーが正常にプレビューできるかどうかを判断します。 3. TiDB は、 `prewrite`リクエストがすべて成功したという結果を受け取ります。 4. TiDB は PD から`commit_ts`を取得します。 @@ -28,13 +28,13 @@ TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/ TiDB Grafana パネルで、 **KV エラー**の下にある次の監視メトリックを確認します。 -- **KV バックオフ OPS は**、TiKV によって返される 1 秒あたりのエラー メッセージの数を示します。 +- **KV バックオフ OPS は**、TiKV によって返される 1秒あたりのエラー メッセージの数を示します。 ![kv-backoff-ops](/media/troubleshooting-write-conflict-kv-backoff-ops.png) メトリック`txnlock`は書き込み競合を示します。メトリック`txnLockFast`は読み取り競合を示します。 -- **ロック解決 OPS は、** 1 秒あたりのトランザクション競合に関連する項目の数を示します。 +- **ロック解決 OPS は、** 1秒あたりのトランザクション競合に関連する項目の数を示します。 ![lock-resolve-ops](/media/troubleshooting-write-conflict-lock-resolve-ops.png) diff --git a/tso.md b/tso.md index f9dd472d5e10d..fa885f8f148c7 100644 --- a/tso.md +++ b/tso.md @@ -59,9 +59,9 @@ SELECT TIDB_PARSE_TSO_LOGICAL(443852055297916932); 000000000000000100 ← The last 18 bits are the logical timestamp ``` -TSO タイムスタンプには 2 つの部分があります。 +TSO タイムスタンプには 2つの部分があります。 -- 物理タイムスタンプ: 1970 年 1 月 1 日からのミリ秒単位の UNIX タイムスタンプ。 +- 物理タイムスタンプ: 1970年 1月 1日からのミリ秒単位の UNIX タイムスタンプ。 - 論理タイムスタンプ：増分するカウンターで、同じミリ秒内に複数のタイムスタンプが必要なシナリオや、特定のイベントによって時計の進行が逆転する可能性がある場合に使用されます。このような場合、物理タイムスタンプは変化せず、論理タイムスタンプは着実に進みます。このメカニズムにより、TSOタイムスタンプの整合性が確保されます。TSOタイムスタンプは常に前進し、後退することはありません。 この知識があれば、SQL で TSO タイムスタンプをもう少し詳しく調べることができます。 diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index 69932529b1655..c5453cf8a88a9 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -1,11 +1,11 @@ --- title: Two Availability Zones in One Region Deployment -summary: 1 つのリージョンに 2 つの可用性ゾーンを展開するソリューションについて学習します。 +summary: 1つのリージョンに 2つの可用性ゾーンを展開するソリューションについて学習します。 --- # 1つのリージョンに2つのアベイラビリティゾーンを展開 {#two-availability-zones-in-one-region-deployment} -このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1 つのリージョン内の 2 つのアベイラビリティ ゾーン (AZ) のデプロイメント モードについて説明します。 +このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1つのリージョン内の 2つのアベイラビリティ ゾーン (AZ) のデプロイメント モードについて説明します。 このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 @@ -17,7 +17,7 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ ## デプロイメントアーキテクチャ {#deployment-architecture} -このセクションでは、AZ1 と AZ2 という 2 つのアベイラビリティゾーンがそれぞれ東と西に配置されているリージョンを例に説明します。AZ1 はプライマリ AZ で、AZ2 は災害復旧 (DR) AZ です。 +このセクションでは、AZ1 と AZ2 という 2つのアベイラビリティゾーンがそれぞれ東と西に配置されているリージョンを例に説明します。AZ1 はプライマリ AZ で、AZ2 は災害復旧 (DR) AZ です。 クラスター展開のアーキテクチャは次のとおりです。 @@ -36,7 +36,7 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ ### 例 {#example} -次の`tiup topology.yaml`サンプル ファイルは、1 つのリージョン展開モードにおける 2 つの可用性ゾーンの一般的なトポロジ構成です。 +次の`tiup topology.yaml`サンプル ファイルは、1つのリージョン展開モードにおける 2つの可用性ゾーンの一般的なトポロジ構成です。 ```yaml # # Global variables are applied to all deployments and used as the default value of @@ -89,7 +89,7 @@ alertmanager_servers: ### 配置ルール {#placement-rules} -計画されたトポロジに基づいてクラスターをデプロイするには、 [配置ルール](/configure-placement-rules.md)を使用してクラスターレプリカの配置場所を決定する必要があります。4 つのレプリカ（Voter レプリカ 2 つをプライマリ AZ、Voter レプリカ 1 つをディザスタリカバリ AZ に、 Learnerレプリカ 1 つをディザスタリカバリ AZ に配置）のデプロイを例に挙げると、配置ルールを使用してレプリカを次のように設定できます。 +計画されたトポロジに基づいてクラスターをデプロイするには、 [配置ルール](/configure-placement-rules.md)を使用してクラスターレプリカの配置場所を決定する必要があります。4つのレプリカ（Voter レプリカ 2つをプライマリ AZ、Voter レプリカ 1つをディザスタリカバリ AZ に、 Learnerレプリカ 1つをディザスタリカバリ AZ に配置）のデプロイを例に挙げると、配置ルールを使用してレプリカを次のように設定できます。 ``` cat rule.json @@ -259,10 +259,10 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status #### ステータススイッチ {#status-switch} -クラスターのレプリケーション モードは、次の 3 つのステータス間を自動的かつ適応的に切り替えることができます。 +クラスターのレプリケーション モードは、次の3つのステータス間を自動的かつ適応的に切り替えることができます。 - クラスターが正常な場合、同期レプリケーション モードが有効になり、災害復旧 AZ のデータ整合性が最大限に高まります。 -- 2 つの AZ 間のネットワーク接続に障害が発生した場合、または災害復旧 AZ が故障した場合、事前に設定された保護間隔の後に、クラスターは非同期レプリケーション モードを有効にして、アプリケーションの可用性を確保します。 +- 2つの AZ 間のネットワーク接続に障害が発生した場合、または災害復旧 AZ が故障した場合、事前に設定された保護間隔の後に、クラスターは非同期レプリケーション モードを有効にして、アプリケーションの可用性を確保します。 - ネットワークが再接続するか、災害復旧AZが復旧すると、TiKVノードはクラスターに再び参加し、データを段階的にレプリケーションします。最終的に、クラスターは同期レプリケーションモードに切り替わります。 ステータススイッチの詳細は次のとおりです。 @@ -271,11 +271,11 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status 2. **同期から非同期への切り替え**：PDは定期的にTiKVのハートビート情報をチェックし、TiKVノードに障害が発生したか、切断されているかを判断します。障害が発生したノードの数がプライマリAZ（ `primary-replicas` ）と災害復旧AZ（ `dr-replicas` ）のレプリカ数を超えると、同期レプリケーションモードではデータレプリケーションを提供できなくなり、ステータスを切り替える必要があります。障害または切断の時間が`wait-store-timeout`で設定された時間を超えると、PDはクラスターのステータスを非同期モードに切り替えます。次に、PDはすべてのTiKVノードに非同期のステータスを送信し、TiKVのレプリケーションモードは2つのアベイラビリティゾーンのレプリケーションからネイティブのRaftマジョリティに切り替わります。 -3. **非同期から同期への切り替え**: PD は TiKV のハートビート情報を定期的にチェックし、TiKV ノードが再接続されたかどうかを判断します。障害が発生したノードの数がプライマリ AZ ( `primary-replicas` ) と災害復旧 AZ ( `dr-replicas` ) のレプリカ数より少ない場合、同期レプリケーション モードを再度有効にできます。PD は最初にクラスターのステータスを sync-recover に切り替え、そのステータス情報をすべての TiKV ノードに送信します。TiKV のすべてのリージョンは、2 つのアベイラビリティ ゾーンの同期レプリケーション モードに徐々に切り替わり、ハートビート情報を PD に報告します。PD は TiKV リージョンのステータスを記録し、リカバリの進行状況を計算します。すべての TiKV リージョンで切り替えが完了すると、PD はレプリケーション モードを同期に切り替えます。 +3. **非同期から同期への切り替え**: PD は TiKV のハートビート情報を定期的にチェックし、TiKV ノードが再接続されたかどうかを判断します。障害が発生したノードの数がプライマリ AZ ( `primary-replicas` ) と災害復旧 AZ ( `dr-replicas` ) のレプリカ数より少ない場合、同期レプリケーション モードを再度有効にできます。PD は最初にクラスターのステータスを sync-recover に切り替え、そのステータス情報をすべての TiKV ノードに送信します。TiKV のすべてのリージョンは、2つのアベイラビリティ ゾーンの同期レプリケーション モードに徐々に切り替わり、ハートビート情報を PD に報告します。PD は TiKV リージョンのステータスを記録し、リカバリの進行状況を計算します。すべての TiKV リージョンで切り替えが完了すると、PD はレプリケーション モードを同期に切り替えます。 ### 災害復旧 {#disaster-recovery} -このセクションでは、1 つのリージョン展開における 2 つの AZ の災害復旧ソリューションを紹介します。 +このセクションでは、1つのリージョン展開における 2つの AZ の災害復旧ソリューションを紹介します。 同期レプリケーションモードのクラスタに災害が発生した場合、 `RPO = 0`でデータリカバリを実行できます。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 4bb37a4d1d668..544eeb4e43040 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -302,7 +302,7 @@ Cluster version: v8.5.4 - オフラインアップグレードに`kill -9`コマンドを使用しているため、アップグレードが停止します。 - - 注意事項： `kill -9`コマンドを使用してオフラインアップグレードを実行することは避けてください。どうしても必要な場合は、2 分後に新しいバージョンの TiDB ノードを再起動してください。 + - 注意事項： `kill -9`コマンドを使用してオフラインアップグレードを実行することは避けてください。どうしても必要な場合は、2分後に新しいバージョンの TiDB ノードを再起動してください。 - アップグレードが既に停止している場合は、影響を受けているTiDBノードを再起動してください。問題が発生したばかりの場合は、2分後にノードを再起動することをお勧めします。 - DDL所有者の変更によりアップグレードが停止する diff --git a/user-account-management.md b/user-account-management.md index e5fd4c8678483..92fc6670b4332 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -173,7 +173,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ 1. 設定ファイルを変更します。 - 1. tidb-server インスタンスの 1 つが配置されているマシンにログインします。 + 1. tidb-server インスタンスの 1つが配置されているマシンにログインします。 2. TiDB ノードのデプロイメント ディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)を追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 diff --git a/user-defined-variables.md b/user-defined-variables.md index 4321b44e6df2a..03a1f2a8e0c7b 100644 --- a/user-defined-variables.md +++ b/user-defined-variables.md @@ -13,7 +13,7 @@ summary: ユーザー定義変数の使用方法を学習します。 ユーザー定義変数の形式は`@var_name`です。 `var_name`を構成する文字は、識別子を構成できる任意の文字（数字`0-9` 、文字`a-zA-Z` 、アンダースコア`_` 、ドル記号`$` 、UTF-8文字など）です。さらに、英語のピリオド`.`も含まれます。ユーザー定義変数は大文字と小文字を区別しません。 -ユーザー定義変数はセッション固有であるため、1 つのクライアント接続で定義されたユーザー変数は、他のクライアント接続では表示または使用できません。 +ユーザー定義変数はセッション固有であるため、1つのクライアント接続で定義されたユーザー変数は、他のクライアント接続では表示または使用できません。 ## ユーザー定義変数を設定する {#set-the-user-defined-variables}