diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 423a756498d04..fa0817b34ae91 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -31,7 +31,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタイルに合わせて使用できる[いくつかのドキュメントテンプレート](/resources/doc-templates)ドキュメントを提供します。 -プル リクエストを送信する前に、次のテンプレートを確認してください。 +プルリクエストを送信する前に、次のテンプレートを確認してください。 - [概念](/resources/doc-templates/template-concept.md) - [タスク](/resources/doc-templates/template-task.md) @@ -139,7 +139,7 @@ git push -u origin new-branch-name # "-u" is used to track the remote branch fro ## 影響を受けるバージョンを選択するためのガイドライン {#guideline-for-choosing-the-affected-version-s} -プル リクエストを作成するときは、プル リクエスト ページの説明テンプレートで、ドキュメントの変更を適用するリリース バージョンを選択する必要があります。 +プルリクエストを作成するときは、プルリクエスト ページの説明テンプレートで、ドキュメントの変更を適用するリリース バージョンを選択する必要があります。 変更が以下のいずれかの状況に該当する場合は、 **「マスターブランチのみを選択」すること**をお勧めします。PRがマージされると、変更はすぐに[PingCAP ドキュメント ウェブサイトの開発ページ](https://docs.pingcap.com/tidb/dev/)に表示されます。TiDBの次のメジャーバージョンまたはマイナーバージョンがリリースされると、変更は新しいバージョンのウェブサイトページにも表示されます。 diff --git a/README.md b/README.md index 7fbaf2ff12fa3..4bf2bb69f654e 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ TiDB ドキュメントへようこそ! -このリポジトリには[PingCAP ウェブサイトの TiDB ドキュメント](https://docs.pingcap.com/tidb/stable)のすべてのソース ファイルが格納され、 [pingcap/docs-cn](https://github.com/pingcap/docs-cn)リポジトリには[TiDB の中国語ドキュメント](https://docs.pingcap.com/zh/tidb/stable)のすべてのソース ファイルが格納されます。 +このリポジトリには[PingCAP ウェブサイトの TiDB ドキュメント](https://docs.pingcap.com/tidb/stable)のすべてのソースファイルが格納され、 [pingcap/docs-cn](https://github.com/pingcap/docs-cn)リポジトリには[TiDB の中国語ドキュメント](https://docs.pingcap.com/zh/tidb/stable)のすべてのソースファイルが格納されます。 ドキュメントに問題が見つかった場合は、お気軽に[問題を作成する](https://github.com/pingcap/docs/issues/new/choose)までご連絡いただくか、直接[プルリクエストを作成する](/CONTRIBUTING.md#how-to-contribute)ご連絡いただき、修正または更新をお手伝いください。 diff --git a/ai/concepts/vector-search-overview.md b/ai/concepts/vector-search-overview.md index ca4ff9f2629f9..336b5b66fb416 100644 --- a/ai/concepts/vector-search-overview.md +++ b/ai/concepts/vector-search-overview.md @@ -29,13 +29,13 @@ aliases: ['/ja/tidb/stable/vector-search-overview/','/ja/tidb/dev/vector-search- ベクトル埋め込みは機械学習において不可欠であり、意味的類似性検索の基盤となる。 -TiDB は、ベクトル埋め込みのストレージと検索を最適化するように設計された[ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を導入し、AI アプリケーションでの使用を強化します。ベクトル埋め込みを TiDB に保存し、ベクトル検索クエリを実行して、これらのデータ タイプを使用して最も関連性の高いデータを見つけることができます。 +TiDB は、ベクトル埋め込みのストレージと検索を最適化するように設計された[ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を導入し、AI アプリケーションでの使用を強化します。ベクトル埋め込みを TiDB に保存し、ベクトル検索クエリを実行して、これらのデータタイプを使用して最も関連性の高いデータを見つけることができます。 ### 埋め込みモデル {#embedding-model} 埋め込みモデルは、データを[ベクトル埋め込み](#vector-embedding)に変換するアルゴリズムです。 -適切な埋め込みモデルを選択することは、セマンティック検索結果の精度と関連性を確保するために重要です。非構造化テキスト データの場合は、 [大規模テキスト埋め込みベンチマーク（MTEB）リーダーボード](https://huggingface.co/spaces/mteb/leaderboard)リーダーボードで最高のパフォーマンスのテキスト埋め込みモデルを見つけることができます。 +適切な埋め込みモデルを選択することは、セマンティック検索結果の精度と関連性を確保するために重要です。非構造化テキストデータの場合は、 [大規模テキスト埋め込みベンチマーク（MTEB）リーダーボード](https://huggingface.co/spaces/mteb/leaderboard)リーダーボードで最高のパフォーマンスのテキスト埋め込みモデルを見つけることができます。 特定のデータタイプに対応したベクトル埋め込みを生成する方法については、統合チュートリアルまたは埋め込みモデルの例を参照してください。 diff --git a/ai/guides/auto-embedding.md b/ai/guides/auto-embedding.md index 9467186dbb4bb..1c2451c32e9ab 100644 --- a/ai/guides/auto-embedding.md +++ b/ai/guides/auto-embedding.md @@ -5,7 +5,7 @@ summary: アプリケーションで自動埋め込みを使用する方法を # 自動埋め込み {#auto-embedding} -自動埋め込み機能は、テキスト データのベクトル埋め込みを自動的に生成します。 +自動埋め込み機能は、テキストデータのベクトル埋め込みを自動的に生成します。 > **Note:** > @@ -17,7 +17,7 @@ summary: アプリケーションで自動埋め込みを使用する方法を ### ステップ1. 埋め込み関数を定義する {#step-1-define-an-embedding-function} -テキスト データのベクトル埋め込みを生成するための埋め込み関数を定義します。 +テキストデータのベクトル埋め込みを生成するための埋め込み関数を定義します。 ```python from pytidb.embeddings import EmbeddingFunction @@ -29,7 +29,7 @@ embed_func = EmbeddingFunction( ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-a-vector-field} -テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`を使用します。 +テーブルスキーマにベクトルフィールドを作成するには、 `embed_func.VectorField()`を使用します。 自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`設定します。 diff --git a/ai/guides/connect.md b/ai/guides/connect.md index 006b96ae7b5a6..6166570d53989 100644 --- a/ai/guides/connect.md +++ b/ai/guides/connect.md @@ -46,7 +46,7 @@ db = TiDBClient.connect( > **Note:** > -> TiDB Cloud Starterの場合、パブリック エンドポイントを使用する場合はデータベース[データベースへのTLS接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters/)が必要です。 `pytidb`クライアントは、 TiDB Cloud Starterインスタンスの TLS を**自動的に**有効にします。 +> TiDB Cloud Starterの場合、パブリックエンドポイントを使用する場合はデータベース[データベースへのTLS接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters/)が必要です。 `pytidb`クライアントは、 TiDB Cloud Starterインスタンスの TLS を**自動的に**有効にします。
@@ -99,7 +99,7 @@ db = TiDBClient.connect( > **Note:** > -> TiDB Cloud Starterの場合、パブリック エンドポイントを使用する場合はデータベース[データベースへのTLS接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters/)が必要となるため、接続文字列に`ssl_verify_cert=true&ssl_verify_identity=true`を設定する必要があります。 +> TiDB Cloud Starterの場合、パブリックエンドポイントを使用する場合はデータベース[データベースへのTLS接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters/)が必要となるため、接続文字列に`ssl_verify_cert=true&ssl_verify_identity=true`を設定する必要があります。
diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md index d49ab65f80c0d..954fc0f0ceebb 100644 --- a/ai/guides/filtering.md +++ b/ai/guides/filtering.md @@ -5,7 +5,7 @@ summary: アプリケーションでフィルタリングを使用する方法 # フィルタリング {#filtering} -リレーショナル データベースである TiDB は、正確なクエリを実行するための[SQL演算子](https://docs.pingcap.com/tidbcloud/operators/)なフィルタリング条件と柔軟な組み合わせをサポートします。 +リレーショナルデータベースである TiDB は、正確なクエリを実行するための[SQL演算子](https://docs.pingcap.com/tidbcloud/operators/)なフィルタリング条件と柔軟な組み合わせをサポートします。 ## 概要 {#overview} diff --git a/ai/guides/join-queries.md b/ai/guides/join-queries.md index ff9da5a515638..854ca7c005e09 100644 --- a/ai/guides/join-queries.md +++ b/ai/guides/join-queries.md @@ -16,7 +16,7 @@ summary: アプリケーションで複数のテーブル結合を使用する `TiDBClient`を使用して、すでに[TiDBに接続](/ai/guides/connect.md)していると仮定します。 -`documents`テーブルを作成し、いくつかのサンプル データを挿入します。 +`documents`テーブルを作成し、いくつかのサンプルデータを挿入します。 ```python from pytidb import Session @@ -37,7 +37,7 @@ client.table("documents").bulk_insert([ ]) ``` -`chunks`テーブルを作成し、いくつかのサンプル データを挿入します。 +`chunks`テーブルを作成し、いくつかのサンプルデータを挿入します。 ```python class Chunk(TableModel): @@ -58,7 +58,7 @@ client.table("chunks").bulk_insert([
-`documents`テーブルを作成し、いくつかのサンプル データを挿入します。 +`documents`テーブルを作成し、いくつかのサンプルデータを挿入します。 ```sql CREATE TABLE documents ( @@ -72,7 +72,7 @@ INSERT INTO documents (id, title) VALUES (3, 'The Art of Happiness'); ``` -`chunks`テーブルを作成し、いくつかのサンプル データを挿入します。 +`chunks`テーブルを作成し、いくつかのサンプルデータを挿入します。 ```sql CREATE TABLE chunks ( diff --git a/ai/guides/raw-queries.md b/ai/guides/raw-queries.md index 8b4575a408891..516641de202ca 100644 --- a/ai/guides/raw-queries.md +++ b/ai/guides/raw-queries.md @@ -31,7 +31,7 @@ client.execute( ## 生のSQLでデータをクエリする {#query-data-with-raw-sql} -`client.query()`メソッドを使用して、 `SELECT` 、 `SHOW` 、およびその他のクエリ ステートメントを実行します。 +`client.query()`メソッドを使用して、 `SELECT` 、 `SHOW` 、およびその他のクエリステートメントを実行します。 ### クエリ結果を出力する {#output-query-result} diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index 8e455c6ce4130..e860b2629252e 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -20,7 +20,7 @@ summary: アプリケーションでベクトル検索を使用する方法を
-`client.create_table()`を使用してテーブルを作成し、 `VectorField`を使用してベクトル フィールドを定義できます。 +`client.create_table()`を使用してテーブルを作成し、 `VectorField`を使用してベクトルフィールドを定義できます。 次の例では、4 つの列を持つ`documents`テーブルを作成します。 @@ -69,9 +69,9 @@ CREATE TABLE documents ( この例では、 - `text_vec`列は`VECTOR(3)`として定義されているため、この列に格納されるベクトルは 3 次元である必要があります。 -- ベクトル検索のパフォーマンスを最適化するために、 `VEC_COSINE_DISTANCE`関数を使用してベクトル インデックスが作成されます。 +- ベクトル検索のパフォーマンスを最適化するために、 `VEC_COSINE_DISTANCE`関数を使用してベクトルインデックスが作成されます。 -TiDB はベクトル インデックスに対して 2 つの距離関数をサポートしています。 +TiDB はベクトルインデックスに対して 2 つの距離関数をサポートしています。 - `VEC_COSINE_DISTANCE` : 2つのベクトル間のコサイン距離を計算する - `VEC_L2_DISTANCE` : 2つのベクトル間のL2距離（ユークリッド距離）を計算する @@ -289,7 +289,7 @@ LIMIT 10; ## メタデータフィルタリング {#metadata-filtering} -リレーショナル データベースである TiDB は、豊富なセット[SQL演算子](https://docs.pingcap.com/tidbcloud/operators/)をサポートし、フィルタリング条件の柔軟な組み合わせを可能にします。 +リレーショナルデータベースである TiDB は、豊富なセット[SQL演算子](https://docs.pingcap.com/tidbcloud/operators/)をサポートし、フィルタリング条件の柔軟な組み合わせを可能にします。 TiDB でのベクトル検索では、スカラー フィールド (整数や文字列など) または JSON フィールドにメタデータ フィルタリングを適用できます。 @@ -305,7 +305,7 @@ TiDB でのベクトル検索では、スカラー フィールド (整数や文 フィルター辞書を持つ`.filter()`メソッドを使用して、ベクトル検索にフィルターを適用します。 -デフォルトでは、 `table.search()` API はポストフィルタリング モードを使用して、ベクトル インデックスによる検索パフォーマンスを最大化します。 +デフォルトでは、 `table.search()` API はポストフィルタリング モードを使用して、ベクトルインデックスによる検索パフォーマンスを最大化します。 **例: ポストフィルタリングによるベクトル検索** @@ -330,17 +330,17 @@ results = (
-現在、ベクトル インデックスは、次のような厳密な ANN (近似最近傍) クエリでのみ有効です。 +現在、ベクトルインデックスは、次のような厳密な ANN (近似最近傍) クエリでのみ有効です。 ```sql SELECT * FROM ORDER BY () LIMIT ``` -つまり、同じクエリ内で`WHERE`句とベクトル インデックスを一緒に使用することはできません。 +つまり、同じクエリ内で`WHERE`句とベクトルインデックスを一緒に使用することはできません。 ベクトル検索と追加のフィルタリング条件を組み合わせる必要がある場合は、ポストフィルタリングパターンを使用できます。このアプローチでは、ANNクエリは2つの部分に分割されます。 -- 内部クエリは、ベクトル インデックスを使用してベクトル検索を実行します。 +- 内部クエリは、ベクトルインデックスを使用してベクトル検索を実行します。 - 外側のクエリは`WHERE`条件を適用して結果をフィルタリングします。 ```sql hl_lines="8" @@ -414,7 +414,7 @@ TiDB は、単一のテーブルに複数のベクトル列を定義すること
-スキーマ内に複数のベクトル フィールドを定義し、 `.vector_column()`メソッドを使用して指定されたベクトル フィールドに対してベクトル検索を実行できます。 +スキーマ内に複数のベクトルフィールドを定義し、 `.vector_column()`メソッドを使用して指定されたベクトルフィールドに対してベクトル検索を実行できます。 **例: 検索するベクトル場を指定する** diff --git a/ai/integrations/tidb-mcp-claude-code.md b/ai/integrations/tidb-mcp-claude-code.md index 5bf7b4da4c649..c891467d09fe4 100644 --- a/ai/integrations/tidb-mcp-claude-code.md +++ b/ai/integrations/tidb-mcp-claude-code.md @@ -51,7 +51,7 @@ claude mcp add --transport stdio TiDB \ ### 方法2：プロジェクト設定ファイル {#method-2-project-config-file} -次の設定をプロジェクト レベルの`.mcp.json`ファイルに追加します。詳細については、 [Claude Code MCP ドキュメント](https://code.claude.com/docs/en/mcp#project-scope)を参照してください。 +次の設定をプロジェクトレベルの`.mcp.json`ファイルに追加します。詳細については、 [Claude Code MCP ドキュメント](https://code.claude.com/docs/en/mcp#project-scope)を参照してください。 ```json { diff --git a/ai/integrations/vector-search-auto-embedding-overview.md b/ai/integrations/vector-search-auto-embedding-overview.md index 6db7f1804e9cc..014fdf5a247ec 100644 --- a/ai/integrations/vector-search-auto-embedding-overview.md +++ b/ai/integrations/vector-search-auto-embedding-overview.md @@ -71,7 +71,7 @@ LIMIT 3; ## 自動埋め込み + ベクトルインデックス {#auto-embedding--vector-index} -自動埋め込みはクエリのパフォーマンスを向上させるための[ベクトルインデックス](/ai/reference/vector-search-index.md)と互換性があります。生成されたベクトル列にベクトル インデックスを定義でき、それは自動的に使用されます。 +自動埋め込みはクエリのパフォーマンスを向上させるための[ベクトルインデックス](/ai/reference/vector-search-index.md)と互換性があります。生成されたベクトル列にベクトルインデックスを定義でき、それは自動的に使用されます。 ```sql -- Create a table with auto-embedding and a vector index diff --git a/ai/integrations/vector-search-integrate-with-django-orm.md b/ai/integrations/vector-search-integrate-with-django-orm.md index 90e0c35b242f1..85b662eeea9f3 100644 --- a/ai/integrations/vector-search-integrate-with-django-orm.md +++ b/ai/integrations/vector-search-integrate-with-django-orm.md @@ -208,7 +208,7 @@ if TIDB_CA_PATH: } ``` -プロジェクトのルート ディレクトリに`.env`ファイルを作成し、環境変数`TIDB_HOST` 、 `TIDB_PORT` 、 `TIDB_USERNAME` 、 `TIDB_PASSWORD` 、 `TIDB_DATABASE` 、および`TIDB_CA_PATH` TiDB の実際の値で設定できます。 +プロジェクトのルートディレクトリに`.env`ファイルを作成し、環境変数`TIDB_HOST` 、 `TIDB_PORT` 、 `TIDB_USERNAME` 、 `TIDB_PASSWORD` 、 `TIDB_DATABASE` 、および`TIDB_CA_PATH` TiDB の実際の値で設定できます。 ### ベクトルテーブルを作成する {#create-vector-tables} diff --git a/ai/integrations/vector-search-integrate-with-jinaai-embedding.md b/ai/integrations/vector-search-integrate-with-jinaai-embedding.md index aad2c875181c4..c50e0cd1a44e9 100644 --- a/ai/integrations/vector-search-integrate-with-jinaai-embedding.md +++ b/ai/integrations/vector-search-integrate-with-jinaai-embedding.md @@ -113,7 +113,7 @@ export TIDB_DATABASE_URL="mysql+pymysql://:@:/`はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスタを初めて起動する場合はこのフィールドを省略できます。 +ご使用の TiDB クラスタに合わせて、上記のコマンドのパラメータを置き換える必要があります。ローカルマシンで TiDB を実行している場合、 ``はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスタを初めて起動する場合はこのフィールドを省略できます。 各パラメータの説明は以下のとおりです。 diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index cb5a3ef8cf9dd..94701245b53c3 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -6,23 +6,23 @@ aliases: ['/ja/tidb/stable/vector-search-data-types/','/ja/tidbcloud/vector-sear # ベクトルデータ型 {#vector-data-types} -ベクトルは、 `[0.3, 0.5, -0.1, ...]`などの浮動小数点数のシーケンスです。TiDB は、AI アプリケーションで広く使用されているベクトル埋め込みを効率的に保存およびクエリするために特別に最適化されたベクトル データ型を提供します。 +ベクトルは、 `[0.3, 0.5, -0.1, ...]`などの浮動小数点数のシーケンスです。TiDB は、AI アプリケーションで広く使用されているベクトル埋め込みを効率的に保存およびクエリするために特別に最適化されたベクトルデータ型を提供します。 > **Note:** > > - ベクトルデータ型はパブリックプレビューであり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 > - ベクトルデータ型は[TiDB Self-Managed](/overview.md) および [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で使用できます。TiDB Self-Managed の場合、TiDB バージョンは v8.4.0 以降である必要があります（v8.5.0 以降を推奨）。 -現在、次のベクトル データ型が利用可能です。 +現在、次のベクトルデータ型が利用可能です。 - `VECTOR` : 任意の次元の単精度浮動小数点数のシーケンス。 - `VECTOR(D)` : 固定次元`D`を持つ単精度浮動小数点数のシーケンス。 -ベクトル データ型を使用すると、 [`JSON`](/data-type-json.md)型を使用する場合に比べて次の利点があります。 +ベクトルデータ型を使用すると、 [`JSON`](/data-type-json.md)型を使用する場合に比べて次の利点があります。 -- ベクトル インデックスのサポート: ベクトルの検索を高速化するために[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を構築できます。 +- ベクトルインデックスのサポート: ベクトルの検索を高速化するために[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を構築できます。 - 次元の強制: 異なる次元のベクトルの挿入を禁止する次元を指定できます。 -- 最適化されたストレージ形式: ベクトル データ型はベクトル データの処理に最適化されており、 `JSON`型と比較して優れたスペース効率とパフォーマンスを実現します。 +- 最適化されたストレージ形式: ベクトルデータ型はベクトルデータの処理に最適化されており、 `JSON`型と比較して優れたスペース効率とパフォーマンスを実現します。 ## 構文 {#syntax} @@ -59,7 +59,7 @@ ERROR 1105 (HY000): Invalid vector text: [5, ] ERROR 1105 (HY000): vector has 2 dimensions, does not fit VECTOR(3) ``` -ベクトル データ型で使用できる関数と演算子については、 [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md)を参照してください。 +ベクトルデータ型で使用できる関数と演算子については、 [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md)を参照してください。 ベクトル検索インデックスの構築と使用の詳細については、 [ベクトル検索インデックス](/ai/reference/vector-search-index.md)を参照してください。 @@ -231,15 +231,15 @@ Vector と String 間のキャストを行うには、次の関数を使用し 現在、 Vector と他のデータ型（ `JSON`など）間の直接キャストはサポートされていません。この制限を回避するには、SQL文でキャストする際の中間データ型として String を使用してください。 -テーブルに格納されているベクトル データ型の列は、 `ALTER TABLE ... MODIFY COLUMN ...`を使用して他のデータ型に変換できないことに注意してください。 +テーブルに格納されているベクトルデータ型の列は、 `ALTER TABLE ... MODIFY COLUMN ...`を使用して他のデータ型に変換できないことに注意してください。 ## 制限 {#restrictions} -ベクトル データ型の制限については、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)および[ベクトルインデックスの制限](/ai/reference/vector-search-index.md#restrictions)を参照してください。 +ベクトルデータ型の制限については、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)および[ベクトルインデックスの制限](/ai/reference/vector-search-index.md#restrictions)を参照してください。 ## MySQLとの互換性 {#mysql-compatibility} -ベクトル データ型は TiDB 固有であり、MySQL ではサポートされていません。 +ベクトルデータ型は TiDB 固有であり、MySQL ではサポートされていません。 ## 参照 {#see-also} diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md index 06e8f70e07621..371ca70c63173 100644 --- a/ai/reference/vector-search-functions-and-operators.md +++ b/ai/reference/vector-search-functions-and-operators.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou # ベクトル関数と演算子 {#vector-functions-and-operators} -このドキュメントでは、ベクトル データ型で使用できる関数と演算子の一覧を示します。 +このドキュメントでは、ベクトルデータ型で使用できる関数と演算子の一覧を示します。 > **Note:** > @@ -310,7 +310,7 @@ SELECT VEC_AS_TEXT('[1.000, 2.5]'); ## MySQLとの互換性 {#mysql-compatibility} -ベクトル関数と、ベクトル データ型に対する組み込み関数および演算子の拡張使用は TiDB 固有のものであり、MySQL ではサポートされていません。 +ベクトル関数と、ベクトルデータ型に対する組み込み関数および演算子の拡張使用は TiDB 固有のものであり、MySQL ではサポートされていません。 ## 参照 {#see-also} diff --git a/ai/reference/vector-search-improve-performance.md b/ai/reference/vector-search-improve-performance.md index 751accc830bdf..2886b0cb8d775 100644 --- a/ai/reference/vector-search-improve-performance.md +++ b/ai/reference/vector-search-improve-performance.md @@ -1,6 +1,6 @@ --- title: Improve Vector Search Performance -summary: TiDB Vector Search のパフォーマンスを向上させるためのベスト プラクティスを学びます。 +summary: TiDB Vector Search のパフォーマンスを向上させるためのベストプラクティスを学びます。 aliases: ['/ja/tidb/stable/vector-search-improve-performance/','/ja/tidbcloud/vector-search-improve-performance/'] --- @@ -39,4 +39,4 @@ OpenAI `text-embedding-3-large`などの特定の埋め込みモデルは[埋め 一度も使用されていない、または長期間アクセスされていないインデックス（コールドアクセス）にアクセスする場合、TiDBはインデックス全体をメモリではなくクラウドストレージまたはディスクから読み込む必要があります。このプロセスには時間がかかり、多くの場合、クエリのレイテンシーが長くなります。さらに、長期間（例えば数時間）SQLクエリが実行されない場合、コンピューティングリソースが再利用されるため、以降のアクセスはコールドアクセスになります。 -このようなクエリのレイテンシーを回避するには、実際のワークロードの前に、ベクトル インデックスにヒットする同様のベクトル検索クエリを実行して、インデックスをウォームアップします。 +このようなクエリのレイテンシーを回避するには、実際のワークロードの前に、ベクトルインデックスにヒットする同様のベクトル検索クエリを実行して、インデックスをウォームアップします。 diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index b8a622ba8d6e0..32ab2ea42c9b3 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -1,6 +1,6 @@ --- title: Vector Search Index -summary: ベクトル検索インデックスを構築して使用し、TiDB で K 近傍法 (KNN) クエリを高速化する方法を学びます。 +summary: ベクトル検索インデックスを構築して使用し、TiDB で K近傍法 (KNN) クエリを高速化する方法を学びます。 aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-index/'] --- @@ -25,7 +25,7 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in - ベクトル検索インデックスの作成および使用時には、距離関数を指定する必要があります。現在、コサイン距離`VEC_COSINE_DISTANCE()`とL2距離`VEC_L2_DISTANCE()`の関数のみがサポートされています。 - 同じ列に対して、同じ距離関数を使用して複数のベクトル検索インデックスを作成することはサポートされていません。 - ベクトル検索インデックスが設定された列を直接削除することはサポートされていません。このような列を削除するには、まずその列のベクトル検索インデックスを削除し、次に列自体を削除します。 -- ベクトル インデックスを持つ列の型の変更はサポートされていません。 +- ベクトルインデックスを持つ列の型の変更はサポートされていません。 - ベクトル検索インデックスを[見えない](/sql-statements/sql-statement-alter-index.md)に設定することはサポートされていません。 - [保存時の暗号化](/encryption-at-rest.md)有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。 @@ -63,7 +63,7 @@ TiDB では、次のいずれかの方法で、 [ベクトルデータ型](/ai/r > - テーブルの作成時にベクトル検索インデックスが定義されている場合、TiDB はテーブルのTiFlashレプリカを自動的に作成します。 > - テーブルの作成時にベクトル検索インデックスが定義されておらず、テーブルに現在TiFlashレプリカが存在しない場合は、テーブルにベクトル検索インデックスを追加する前に、手動でTiFlashレプリカを作成する必要があります。例: `ALTER TABLE 'table_name' SET TIFLASH REPLICA 1;` 。 -HNSW ベクトル インデックスを作成するときは、ベクトルの距離関数を指定する必要があります。 +HNSW ベクトルインデックスを作成するときは、ベクトルの距離関数を指定する必要があります。 - コサイン距離: `((VEC_COSINE_DISTANCE(embedding)))` - L2距離: `((VEC_L2_DISTANCE(embedding)))` @@ -74,7 +74,7 @@ HNSW ベクトル インデックスを作成するときは、ベクトルの ## ベクトルインデックスを使用する {#use-the-vector-index} -ベクトル検索インデックスは、次のように`ORDER BY ... LIMIT`句を使用して K 近傍検索クエリで使用できます。 +ベクトル検索インデックスは、次のように`ORDER BY ... LIMIT`句を使用して K近傍検索クエリで使用できます。 ```sql SELECT * @@ -83,7 +83,7 @@ ORDER BY VEC_COSINE_DISTANCE(embedding, '[1, 2, 3, 4, 5]') LIMIT 10 ``` -ベクトル検索でインデックスを使用するには、 `ORDER BY ... LIMIT`句がベクトル インデックスの作成時に指定したものと同じ距離関数を使用していることを確認します。 +ベクトル検索でインデックスを使用するには、 `ORDER BY ... LIMIT`句がベクトルインデックスの作成時に指定したものと同じ距離関数を使用していることを確認します。 ## フィルター付きベクトルインデックスを使用する {#use-the-vector-index-with-filters} @@ -98,7 +98,7 @@ ORDER BY VEC_COSINE_DISTANCE(embedding, '[1, 2, 3]') LIMIT 5; ``` -フィルター付きのベクトル インデックスを使用するには、まずベクトル検索を使用して K 近傍を照会し、次に不要な結果をフィルター処理します。 +フィルター付きのベクトルインデックスを使用するには、まずベクトル検索を使用して K近傍を照会し、次に不要な結果をフィルター処理します。 ```sql -- For the following query, the `WHERE` filter is performed after KNN, so the vector index cannot be used: @@ -190,7 +190,7 @@ LIMIT 10; 6 rows in set, 1 warning (0.01 sec) ``` -ベクトル インデックスが使用できない場合、原因の調査に役立つ警告が表示される場合があります。 +ベクトルインデックスが使用できない場合、原因の調査に役立つ警告が表示される場合があります。 ```sql -- Using a wrong distance function: @@ -212,7 +212,7 @@ ANN index not used: index can be used only when ordering by vec_cosine_distance( ## ベクトル検索のパフォーマンスを分析する {#analyze-vector-search-performance} -ベクトル インデックスの使用方法に関する詳細情報を確認するには、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを実行し、出力の`execution info`列を確認します。 +ベクトルインデックスの使用方法に関する詳細情報を確認するには、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを実行し、出力の`execution info`列を確認します。 ```sql [tidb]> EXPLAIN ANALYZE SELECT * FROM vector_table_with_index diff --git a/ai/reference/vector-search-limitations.md b/ai/reference/vector-search-limitations.md index 05e26a9675f29..6fa2f709e1a77 100644 --- a/ai/reference/vector-search-limitations.md +++ b/ai/reference/vector-search-limitations.md @@ -33,13 +33,13 @@ aliases: ['/ja/tidb/stable/vector-search-limitations/','/ja/tidb/dev/vector-sear - TiDB Cloudの機能： - - [TiDB Cloudコンソールのデータ移行機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)MySQL ベクトル データ型のTiDB Cloudへの移行または複製をサポートしていません。 + - [TiDB Cloudコンソールのデータ移行機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)MySQL ベクトルデータ型のTiDB Cloudへの移行または複製をサポートしていません。 - TiDB Self-Managedツール： - データのバックアップと復元には、 [BR](/br/backup-and-restore-overview.md)のバージョン8.4.0以降を使用していることを確認してください。ベクトルデータ型のテーブルをTiDBバージョン8.4.0より前のバージョンに復元することはサポートされていません。 - [TiDB Data Migration (DM)](/dm/dm-overview.md) MySQLベクトルデータ型をTiDBに移行または複製することをサポートしていません。 - - [TiCDC](/ticdc/ticdc-overview.md)ベクトル データ タイプをサポートしていないダウンストリームにベクトル データをレプリケートすると、ベクトル データ タイプが別のタイプに変更されます。詳細については、 [ベクトルデータ型との互換性](/ticdc/ticdc-compatibility.md#compatibility-with-vector-data-types)を参照してください。 + - [TiCDC](/ticdc/ticdc-overview.md)ベクトルデータタイプをサポートしていないダウンストリームにベクトルデータをレプリケートすると、ベクトルデータタイプが別のタイプに変更されます。詳細については、 [ベクトルデータ型との互換性](/ticdc/ticdc-compatibility.md#compatibility-with-vector-data-types)を参照してください。 ## フィードバック {#feedback} diff --git a/ai/vector-search-get-started-using-python.md b/ai/vector-search-get-started-using-python.md index a18c826845137..9cbbf1bf31807 100644 --- a/ai/vector-search-get-started-using-python.md +++ b/ai/vector-search-get-started-using-python.md @@ -120,7 +120,7 @@ TiDBをローカルマシンで実行している場合、 ``はデフォ ### ステップ4．埋め込みモデルを初期化する {#step-4-initialize-the-embedding-model} -[埋め込みモデル](/ai/concepts/vector-search-overview.md#embedding-model)データを[ベクトル埋め込み](/ai/concepts/vector-search-overview.md#vector-embedding)に変換します。この例では、テキスト埋め込みに事前トレーニング済みモデル[**msmarco-MiniLM-L12-cos-v5**](https://huggingface.co/sentence-transformers/msmarco-MiniLM-L12-cos-v5)を使用します。 `sentence-transformers`ライブラリによって提供されるこの軽量モデルは、テキスト データを 384 次元のベクトル埋め込みに変換します。 +[埋め込みモデル](/ai/concepts/vector-search-overview.md#embedding-model)データを[ベクトル埋め込み](/ai/concepts/vector-search-overview.md#vector-embedding)に変換します。この例では、テキスト埋め込みに事前トレーニング済みモデル[**msmarco-MiniLM-L12-cos-v5**](https://huggingface.co/sentence-transformers/msmarco-MiniLM-L12-cos-v5)を使用します。 `sentence-transformers`ライブラリによって提供されるこの軽量モデルは、テキストデータを 384 次元のベクトル埋め込みに変換します。 モデルを設定するには、次のコードを`example.py`ファイルにコピーしてください。このコードは`SentenceTransformer`インスタンスを初期化し、後で使用するために`text_to_embedding()`関数を定義します。 diff --git a/alert-rules.md b/alert-rules.md index 600d800468fc1..0bd4bb04a2f6a 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -1,13 +1,13 @@ --- title: TiDB Cluster Alert Rules -summary: TiDB クラスターのアラート ルールについて学習します。 +summary: TiDB クラスターのアラートルールについて学習します。 --- # TiDBクラスタアラートルール {#tidb-cluster-alert-rules} -このドキュメントでは、TiDB、TiKV、PD、 TiFlash、TiCDC、Node_exporter、Blackbox_exporter のアラート項目のルールの説明と解決策を含む、TiDB クラスター内のさまざまなコンポーネントのアラート ルールについて説明します。 +このドキュメントでは、TiDB、TiKV、PD、 TiFlash、TiCDC、Node_exporter、Blackbox_exporter のアラート項目のルールの説明と解決策を含む、TiDB クラスター内のさまざまなコンポーネントのアラートルールについて説明します。 アラートルールは、重大度レベルに応じて、緊急レベル、重大レベル、警告レベルの3つのカテゴリ（高から低の順）に分類されます。この重大度レベルの区分は、以下の各コンポーネントのすべてのアラート項目に適用されます。 @@ -19,7 +19,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま ## TiDBアラートルール {#tidb-alert-rules} -このセクションでは、TiDBコンポーネントのアラート ルールについて説明します。 +このセクションでは、TiDBコンポーネントのアラートルールについて説明します。 ### 緊急レベルの警報 {#emergency-level-alerts-1} @@ -172,7 +172,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま ## PDアラートルール {#pd-alert-rules} -このセクションでは、PDコンポーネントのアラート ルールについて説明します。 +このセクションでは、PDコンポーネントのアラートルールについて説明します。 ### 緊急レベルの警報 {#emergency-level-alerts-2} @@ -417,7 +417,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま ## TiKVアラートルール {#tikv-alert-rules} -このセクションでは、TiKVコンポーネントのアラート ルールについて説明します。 +このセクションでは、TiKVコンポーネントのアラートルールについて説明します。 ### 緊急レベルの警報 {#emergency-level-alerts-3} @@ -553,7 +553,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - 1. TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。 + 1. TiDB ログからスロークエリログを確認し、クエリでインデックスまたは完全なテーブルスキャンが使用されているかどうか、または分析に必要かどうかを確認します。 2. ホットスポットがあるかどうかを確認します。 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`が一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`があるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 @@ -772,15 +772,15 @@ summary: TiDB クラスターのアラート ルールについて学習しま ## TiFlashアラートルール {#tiflash-alert-rules} -TiFlashアラート ルールの詳細な説明については、 [TiFlashアラートルール](/tiflash/tiflash-alert-rules.md)を参照してください。 +TiFlashアラートルールの詳細な説明については、 [TiFlashアラートルール](/tiflash/tiflash-alert-rules.md)を参照してください。 ## TiCDCアラートルール {#ticdc-alert-rules} -TiCDC アラート ルールの詳細な説明については、 [TiCDCアラートルール](/ticdc/ticdc-alert-rules.md)を参照してください。 +TiCDC アラートルールの詳細な説明については、 [TiCDCアラートルール](/ticdc/ticdc-alert-rules.md)を参照してください。 ## Node_exporterホストアラートルール {#node_exporter-host-alert-rules} -このセクションでは、Node_exporter ホストのアラート ルールについて説明します。 +このセクションでは、Node_exporter ホストのアラートルールについて説明します。 ### 緊急レベルの警報 {#emergency-level-alerts-4} @@ -927,7 +927,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー ## Blackbox_exporter TCP、ICMP、HTTP アラートルール {#blackbox_exporter-tcp-icmp-and-http-alert-rules} -このセクションでは、Blackbox_exporter の TCP、ICMP、および HTTP のアラート ルールについて説明します。 +このセクションでは、Blackbox_exporter の TCP、ICMP、および HTTP のアラートルールについて説明します。 ### 緊急レベルの警報 {#emergency-level-alerts} diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index bcb9fb3e174e8..9d2db31b69573 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -40,7 +40,7 @@ summary: スロークエリを見つけて分析する方法を学びます。 上記の方法は、以下の点で異なります。 -- スロー ログには、解析から結果の返却まで、SQL 実行のほぼすべての段階の期間が記録され、比較的包括的です (TiDB Dashboardでスロー ログを直感的にクエリおよび分析できます)。 +- スローログには、解析から結果の返却まで、SQL 実行のほぼすべての段階の期間が記録され、比較的包括的です (TiDB Dashboardでスローログを直感的にクエリおよび分析できます)。 - `EXPLAIN ANALYZE`を実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。 まとめると、スローログと`EXPLAIN ANALYZE`ステートメントは、SQLクエリの実行がどのコンポーネント（TiDBまたはTiKV）でどの段階で遅いのかを判断するのに役立ちます。これにより、クエリのパフォーマンスボトルネックを正確に特定できます。 @@ -74,7 +74,7 @@ TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から さらに、スローログのフィールド`Cop_process`と`Cop_wait`分析に役立ちます。次の例では、クエリの合計実行時間は約`180.85ms`で、最大の`coptask`の実行には`171ms`かかっています。これは、このクエリのボトルネックが TiKV 側にあることを示しています。 -スロー ログの各フィールドの説明については、 [フィールドの説明](/identify-slow-queries.md#fields-description)を参照してください。 +スローログの各フィールドの説明については、 [フィールドの説明](/identify-slow-queries.md#fields-description)を参照してください。 ```log # Query_time: 0.18085 @@ -90,7 +90,7 @@ TiKV がボトルネックであると特定したら、次のセクションで SQL文の実行中に、TiDBは複数のTiKVインスタンスからデータを取得する場合があります。1つのTiKVインスタンスの応答が遅いと、SQL文全体の実行速度が低下します。 -スロー ログの`Cop_wait`フィールドは、この原因を特定するのに役立ちます。 +スローログの`Cop_wait`フィールドは、この原因を特定するのに役立ちます。 ```log # Cop_wait: Avg_time: 1ms P90_time: 2ms Max_time: 110ms Max_Addr: 10.6.131.78 @@ -151,7 +151,7 @@ mysql> explain analyze select count(*) from t where a=(select max(t1.a) from t t 5 rows in set (7.77 sec) ``` -ただし、このタイプのサブクエリ実行はスロー ログで識別できます。 +ただし、このタイプのサブクエリ実行はスローログで識別できます。 ``` # Query_time: 7.770634843 @@ -238,7 +238,7 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a; オプティマイザの問題を分析するには、実行計画が妥当かどうかを判断する必要があります。最適化プロセスと各演算子についてある程度の理解が必要です。 -次の例では、テーブル スキーマが`create table t (id int, a int, b int, c int, primary key(id), key(a), key(b, c))`であると想定します。 +次の例では、テーブルスキーマが`create table t (id int, a int, b int, c int, primary key(id), key(a), key(b, c))`であると想定します。 1. `select * from t` : フィルター条件はなく、テーブル全体のスキャンが実行されます。そのため、データの読み取りには`TableFullScan`演算子が使用されます。 2. `select a from t where a=2` : フィルター条件があり、インデックス列のみが読み取られるため、 `IndexReader`演算子を使用してデータを読み取ります。 diff --git a/api/dm-api-overview.md b/api/dm-api-overview.md index 6d0fa9b7e0996..674b924cff2c4 100644 --- a/api/dm-api-overview.md +++ b/api/dm-api-overview.md @@ -11,8 +11,8 @@ DM は、 [dmctlツール](/dm/dmctl-introduction.md)と同様に、DM クラス DM API を使用して、DM クラスターで次のメンテナンス操作を実行できます。 -- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスター ノードと DM ワーカー ノードに関する情報を取得したり、停止したりします。 -- [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データ ソースを作成、更新、削除、有効化、無効化し、リレー ログ機能を管理し、データ ソースと DM ワーカー間のバインディングを変更します。 -- [レプリケーションタスク管理](/dm/dm-open-api.md#apis-for-managing-replication-tasks) : レプリケーション タスクを作成、更新、削除、開始、または停止し、スキーマと移行ルールを管理します。 +- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスターノードと DM ワーカーノードに関する情報を取得したり、停止したりします。 +- [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データソースを作成、更新、削除、有効化、無効化し、リレーログ機能を管理し、データソースと DM ワーカー間のバインディングを変更します。 +- [レプリケーションタスク管理](/dm/dm-open-api.md#apis-for-managing-replication-tasks) : レプリケーションタスクを作成、更新、削除、開始、または停止し、スキーマと移行ルールを管理します。 リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [OpenAPI を使用して DM クラスターを管理](/dm/dm-open-api.md)を参照してください。 diff --git a/api/tidb-cloud-api-v1beta1.md b/api/tidb-cloud-api-v1beta1.md index 3a15113f6f07d..be38bd20a5843 100644 --- a/api/tidb-cloud-api-v1beta1.md +++ b/api/tidb-cloud-api-v1beta1.md @@ -10,8 +10,8 @@ TiDB Cloud API v1beta1 は、 TiDB Cloud内の管理オブジェクトをプロ 現在、次の v1beta1 API を使用してTiDB Cloud内のリソースを管理できます。 - クラスターレベルのリソース: - - [TiDB Cloud Starter または Essential クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless) : TiDB Cloud Starter または Essential クラスターのクラスター、ブランチ、データ エクスポート タスク、およびデータ インポート タスクを管理します。 - - [TiDB Cloud Dedicatedクラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated) : TiDB Cloud Dedicated クラスターのクラスター、リージョン、プライベート エンドポイント接続、およびデータ インポート タスクを管理します。 + - [TiDB Cloud Starter または Essential クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless) : TiDB Cloud Starter または Essential クラスターのクラスター、ブランチ、データエクスポート タスク、およびデータインポートタスクを管理します。 + - [TiDB Cloud Dedicatedクラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated) : TiDB Cloud Dedicated クラスターのクラスター、リージョン、プライベートエンドポイント接続、およびデータインポートタスクを管理します。 - 組織またはプロジェクトレベルのリソース: - [請求](https://docs.pingcap.com/tidbcloud/api/v1beta1/billing) : TiDB Cloudクラスターの課金を管理します。 - [Data Service](https://docs.pingcap.com/tidbcloud/api/v1beta1/dataservice) : TiDB CloudクラスターのData Service内のリソースを管理します。 diff --git a/auto-increment.md b/auto-increment.md index 5d8880e61e5e7..f400c4b831071 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -335,7 +335,7 @@ SELECT * FROM t; 新しく割り当てられた値は`101` 。これは、AUTO_INCREMENT IDを割り当てるためのキャッシュのサイズが`100`であることを示しています。 -さらに、バッチ`INSERT`ステートメント内の連続 ID の長さが`AUTO_ID_CACHE`を超えると、TiDB はそれに応じてキャッシュ サイズを増やし、ステートメントがデータを適切に挿入できるようにします。 +さらに、バッチ`INSERT`ステートメント内の連続 ID の長さが`AUTO_ID_CACHE`を超えると、TiDB はそれに応じてキャッシュサイズを増やし、ステートメントがデータを適切に挿入できるようにします。 ### AUTO_INCREMENT IDキャッシュをクリアする {#clear-the-auto-increment-id-cache} @@ -463,7 +463,7 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発 現在、 `AUTO_INCREMENT` TiDB で使用する場合、次の制限があります。 -- TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックス プレフィックスのいずれかである必要があります。 +- TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックスプレフィックスのいずれかである必要があります。 - `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。 - `DEFAULT`列の値と同じ列には指定できません。 - `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。 diff --git a/basic-features.md b/basic-features.md index 83620aab5d322..226f61671da09 100644 --- a/basic-features.md +++ b/basic-features.md @@ -11,7 +11,7 @@ summary: TiDBの機能概要について学びましょう。 > **Note:** > -> PingCAP は、DMR バージョンのパッチ リリースを提供しません。バグは将来のリリースで修正される予定です。一般的な用途には、[最新のLTSバージョン](https://docs.pingcap.com/tidb/stable)を使用することをお勧めします。 +> PingCAP は、DMR バージョンのパッチリリースを提供しません。バグは将来のリリースで修正される予定です。一般的な用途には、[最新のLTSバージョン](https://docs.pingcap.com/tidb/stable)を使用することをお勧めします。 > > 下記の表の略語は、それぞれ以下の意味を持ちます。 > @@ -323,6 +323,6 @@ summary: TiDBの機能概要について学びましょう。 [^4]: [v6.4.0](/releases/release-6.4.0.md)以降、TiDB は[高性能かつグローバルに単調な`AUTO_INCREMENT`列](/auto-increment.md#mysql-compatibility-mode)をサポートします -[^5]: [TiDB v7.0.0](/releases/release-7.0.0.md)以降、新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的機能です。[v7.6.0](/releases/release-7.6.0.md)以降、TiDB は`LOAD DATA`トランザクションで MySQL と同じように処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB トランザクション モード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 +[^5]: [TiDB v7.0.0](/releases/release-7.0.0.md)以降、新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的機能です。[v7.6.0](/releases/release-7.6.0.md)以降、TiDB は`LOAD DATA`トランザクションで MySQL と同じように処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB トランザクションモード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 [^6]: バージョン 7.5.0 以降、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)レプリケーションは非推奨となりました。バージョン 8.3.0 以降、TiDB Binlogは完全に非推奨となりました。バージョン 8.4.0 以降、TiDB Binlogは削除されました。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスタをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 diff --git a/benchmark/benchmark-sysbench-v3.md b/benchmark/benchmark-sysbench-v3.md index 51d97dc577a50..162abfdd6ed47 100644 --- a/benchmark/benchmark-sysbench-v3.md +++ b/benchmark/benchmark-sysbench-v3.md @@ -101,7 +101,7 @@ block-cache-size = "20GB" ![point select](/media/sysbench_v3_point_select.png) -上記の統計によると、TiDB 2.1 の`Point Select`クエリ パフォーマンスは TiDB 2.0 よりも**50%**向上しました。 +上記の統計によると、TiDB 2.1 の`Point Select`クエリパフォーマンスは TiDB 2.0 よりも**50%**向上しました。 ### `Update Non-Index` {#update-non-index-test} diff --git a/benchmark/benchmark-sysbench-v4-vs-v3.md b/benchmark/benchmark-sysbench-v4-vs-v3.md index 190c5078d036a..4ffbd5e516d8b 100644 --- a/benchmark/benchmark-sysbench-v4-vs-v3.md +++ b/benchmark/benchmark-sysbench-v4-vs-v3.md @@ -94,7 +94,7 @@ set global tidb_disable_txn_auto_retry=0; 3. 各テーブルに対して`analyze table`ステートメントを実行します。 4. さまざまな同時実行テストの前に、復元に使用するデータをバックアップします。これにより、各テストのデータの一貫性が確保されます。 5. Sysbenchクライアントを起動して`update_index` `update_non_index` `point_select` `read_write`を実行します。AWS NLB経由でTiDBのストレステストを実行します。各テストのウォームアップには1分、テストには5分かかります。 -6. 各タイプのテストが完了したら、クラスターを停止し、手順 4 のバックアップ データでクラスターを上書きして、クラスターを再起動します。 +6. 各タイプのテストが完了したら、クラスターを停止し、手順 4 のバックアップデータでクラスターを上書きして、クラスターを再起動します。 ### テストデータを準備する {#prepare-test-data} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 5e8c48ac6ff76..f25b9f73ed999 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -27,7 +27,7 @@ server_configs: ### TiKV構成 {#tikv-configuration} -ログ レベルが高いほど、TiKV のパフォーマンスも向上します。 +ログレベルが高いほど、TiKV のパフォーマンスも向上します。 TiKVクラスターには複数のカラムファミリーがあり、主に異なる種類のデータを格納するために使用されます。デフォルトカラムファミリー、書き込みカラムファミリー、ロックカラムファミリーなどです。Sysbenchテストでは、デフォルトカラムファミリーと書き込みカラムファミリーのみに注目してください。データのインポートに使用されるカラムファミリーは、TiDBクラスター間で一定の割合で存在します。 @@ -51,7 +51,7 @@ server_configs: storage.block-cache.capacity: "30GB" ``` -TiKV パフォーマンス チューニングの詳細については、 [TiKVパフォーマンスの調整](/tune-tikv-memory-performance.md)を参照してください。 +TiKV パフォーマンスチューニングの詳細については、 [TiKVパフォーマンスの調整](/tune-tikv-memory-performance.md)を参照してください。 ## テストプロセス {#test-process} diff --git a/benchmark/benchmark-tidb-using-tpcc.md b/benchmark/benchmark-tidb-using-tpcc.md index 274ca03cf4974..cadd40a0b5d69 100644 --- a/benchmark/benchmark-tidb-using-tpcc.md +++ b/benchmark/benchmark-tidb-using-tpcc.md @@ -86,7 +86,7 @@ tiup bench tpcc -H 172.16.5.140,172.16.5.141 -P 4000 -D tpcc --warehouses 1000 - ## テストデータをクリーンアップする {#clean-up-test-data} -テスト データをクリーンアップするには、次のコマンドを実行します。 +テストデータをクリーンアップするには、次のコマンドを実行します。 ```shell tiup bench tpcc -H 172.16.5.140 -P 4000 -D tpcc --warehouses 4 cleanup diff --git a/benchmark/online-workloads-and-add-index-operations.md b/benchmark/online-workloads-and-add-index-operations.md index 6077d78bcc686..f414363f72eda 100644 --- a/benchmark/online-workloads-and-add-index-operations.md +++ b/benchmark/online-workloads-and-add-index-operations.md @@ -1,13 +1,13 @@ --- title: Interaction Test on Online Workloads and `ADD INDEX` Operations -summary: このドキュメントでは、オンライン ワークロードと ADD INDEX` 操作間の相互作用効果をテストします。 +summary: このドキュメントでは、オンラインワークロードと ADD INDEX` 操作間の相互作用効果をテストします。 --- # オンラインワークロードと`ADD INDEX`操作のインタラクションテスト {#interaction-test-on-online-workloads-and-add-index-operations} ## テスト目的 {#test-purpose} -このドキュメントでは、OLTP シナリオにおけるオンライン ワークロードと`ADD INDEX`操作間の相互作用効果をテストします。 +このドキュメントでは、OLTP シナリオにおけるオンラインワークロードと`ADD INDEX`操作間の相互作用効果をテストします。 ## テストバージョン、時間、場所 {#test-version-time-and-place} @@ -274,7 +274,7 @@ sysbench $testname \ ### テストの結論 {#test-conclusion} -`ADD INDEX`のステートメントのターゲット列に対してのみクエリ操作を実行する場合、 `ADD INDEX`操作がオンライン ワークロードに与える影響は明らかではありません。 +`ADD INDEX`のステートメントのターゲット列に対してのみクエリ操作を実行する場合、 `ADD INDEX`操作がオンラインワークロードに与える影響は明らかではありません。 ## テストプラン3: `ADD INDEX`文のターゲット列はオンラインワークロードとは無関係です {#test-plan-3-the-target-column-of-the-add-index-statement-is-irrelevant-to-online-workloads} @@ -336,9 +336,9 @@ sysbench $testname \ ### テストの結論 {#test-conclusion} -`ADD INDEX`のステートメントのターゲット列がオンライン ワークロードに関係ない場合、 `ADD INDEX`の操作がワークロードに与える影響は明らかではありません。 +`ADD INDEX`のステートメントのターゲット列がオンラインワークロードに関係ない場合、 `ADD INDEX`の操作がワークロードに与える影響は明らかではありません。 ## まとめ {#summary} - `ADD INDEX`ステートメントの対象列に対して、書き込み操作（ `INSERT` `DELETE`操作を含む）を頻繁に実行すると、デフォルトの`ADD INDEX` `UPDATE`では比較的頻繁に書き込み競合が発生し、オンラインワークロードに大きな影響を与えます。同時に、 `ADD INDEX`操作は継続的な再試行により完了までに長い時間がかかります。このテストでは、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の積をデフォルト値の1/32に変更できます。例えば、 `tidb_ddl_reorg_worker_cnt`を`4`に、 `tidb_ddl_reorg_batch_size`を`256`に設定すると、パフォーマンスが向上します。 -- `ADD INDEX`ステートメントのターゲット列に対してのみクエリ操作を実行する場合、またはターゲット列がオンライン ワークロードに直接関連していない場合は、デフォルトの`ADD INDEX`構成を使用できます。 +- `ADD INDEX`ステートメントのターゲット列に対してのみクエリ操作を実行する場合、またはターゲット列がオンラインワークロードに直接関連していない場合は、デフォルトの`ADD INDEX`構成を使用できます。 diff --git a/benchmark/v4.0-performance-benchmarking-with-tpch.md b/benchmark/v4.0-performance-benchmarking-with-tpch.md index db162978908dc..db26a415d5a37 100644 --- a/benchmark/v4.0-performance-benchmarking-with-tpch.md +++ b/benchmark/v4.0-performance-benchmarking-with-tpch.md @@ -9,7 +9,7 @@ summary: TiDB 4.0 と TiDB 3.0 の TPC-H パフォーマンスを比較します このテストの目的は、オンライン分析処理 (OLAP) シナリオにおける TiDB 4.0 と TiDB 3.0 の TPC-H パフォーマンスを比較することです。 -[TiFlash](/tiflash/tiflash-overview.md) TiDB のハイブリッド トランザクションおよび分析処理 (HTAP) 機能を強化する TiDB v4.0 で導入されたため、このレポートのテスト オブジェクトは次のとおりです。 +[TiFlash](/tiflash/tiflash-overview.md) TiDB のハイブリッドトランザクションおよび分析処理 (HTAP) 機能を強化する TiDB v4.0 で導入されたため、このレポートのテスト オブジェクトは次のとおりです。 - TiKV からのみデータを読み取る TiDB v3.0。 - TiKV からのみデータを読み取る TiDB v4.0。 diff --git a/best-practices-for-security-configuration.md b/best-practices-for-security-configuration.md index 7992ac1c51922..03fd265979384 100644 --- a/best-practices-for-security-configuration.md +++ b/best-practices-for-security-configuration.md @@ -1,6 +1,6 @@ --- title: Best Practices for TiDB Security Configuration -summary: 潜在的なセキュリティ リスクを軽減するために、TiDB セキュリティ構成のベスト プラクティスを学習します。 +summary: 潜在的なセキュリティリスクを軽減するために、TiDB セキュリティ構成のベストプラクティスを学習します。 --- # TiDBセキュリティ設定のベストプラクティス {#best-practices-for-tidb-security-configuration} @@ -15,16 +15,16 @@ TiDBのセキュリティは、データの整合性と機密性を保護する デフォルトでは、新規作成されたTiDBクラスタのrootユーザーにはパスワードが設定されていないため、潜在的なセキュリティリスクが生じます。パスワードが設定されていない場合、誰でもrootユーザーとしてTiDBデータベースにログインを試みることができ、データにアクセスして変更される可能性があります。 -このリスクを回避するには、デプロイメント中にルート パスワードを設定することをお勧めします。 +このリスクを回避するには、デプロイメント中にルートパスワードを設定することをお勧めします。 -- TiUPを使用したデプロイメントの場合は、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md#step-7-start-a-tidb-cluster)を参照して、ルート ユーザーのランダム パスワードを生成します。 +- TiUPを使用したデプロイメントの場合は、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md#step-7-start-a-tidb-cluster)を参照して、ルートユーザーのランダム パスワードを生成します。 - TiDB Operatorを使用したデプロイメントの場合は、 [初期アカウントとパスワードを設定する](https://docs.pingcap.com/tidb-in-kubernetes/stable/initialize-a-cluster#set-initial-account-and-password)を参照して root パスワードを設定してください。 -[`--initialize-secure`](/command-line-flags-for-tidb-configuration.md#--initialize-secure)オプションを使用して、初期ルート ユーザーのネットワーク アクセスを制限することもできます。 +[`--initialize-secure`](/command-line-flags-for-tidb-configuration.md#--initialize-secure)オプションを使用して、初期ルートユーザーのネットワーク アクセスを制限することもできます。 ## パスワードの複雑さのチェックを有効にする {#enable-password-complexity-checks} -デフォルトでは、TiDB はパスワードの複雑さのポリシーを強制しないため、弱いパスワードや空のパスワードが使用され、セキュリティ リスクが増大する可能性があります。 +デフォルトでは、TiDB はパスワードの複雑さのポリシーを強制しないため、弱いパスワードや空のパスワードが使用され、セキュリティリスクが増大する可能性があります。 データベースユーザーが強力なパスワードを作成できるようにするには、適切な[パスワードの複雑さのポリシー](/password-management.md#password-complexity-policy)ポリシーを設定することをお勧めします。例えば、パスワードに大文字、小文字、数字、特殊文字の組み合わせを含めることを要求するポリシーを設定します。パスワードの複雑さのチェックを強制することで、データベースのセキュリティを向上させ、ブルートフォース攻撃を防ぎ、内部の脅威を軽減し、規制へのコンプライアンスを確保し、データ侵害のリスクを低減し、全体的なセキュリティを強化できます。 diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index 47e9a78acc6e2..f58eb318088ae 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -1,6 +1,6 @@ --- title: TiDB Best Practices on Public Cloud -summary: パブリック クラウドに TiDB をデプロイするためのベスト プラクティスについて説明します。 +summary: パブリッククラウドに TiDB をデプロイするためのベストプラクティスについて説明します。 aliases: ['/ja/tidb/stable/best-practices-on-public-cloud/'] --- @@ -63,7 +63,7 @@ sdd 1033.00 4132.00 1141.33 31685.33 571.00 0.94 100.00 #### ミドルレンジディスク {#middle-range-disk} -さまざまなパブリック クラウドに推奨されるミドルレンジ ディスクは次のとおりです。 +さまざまなパブリッククラウドに推奨されるミドルレンジ ディスクは次のとおりです。 - AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 30eecf949e8c0..ab60f946e21f0 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -1,6 +1,6 @@ --- title: Best Practices for DDL Execution in TiDB -summary: TiDB での DDL ステートメントの実装方法、オンライン変更プロセス、およびベスト プラクティスについて学習します。 +summary: TiDB での DDL ステートメントの実装方法、オンライン変更プロセス、およびベストプラクティスについて学習します。 aliases: ['/ja/tidb/stable/ddl-introduction/','/ja/tidbcloud/ddl-introduction/'] --- @@ -20,7 +20,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ 対象となるDDLオブジェクトに含まれるデータを操作するかどうかによって、DDL文は次の種類に分類されます。 -- **論理 DDL ステートメント**: 論理 DDL ステートメントは通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベース オブジェクトのメタデータのみを変更します。 +- **論理 DDL ステートメント**: 論理 DDL ステートメントは通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベースオブジェクトのメタデータのみを変更します。 TiDBでは、論理DDL文は「汎用DDL」とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。 @@ -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文は並列実行可能です。 @@ -123,7 +123,7 @@ TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限 - 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)を参照してください。 @@ -138,7 +138,7 @@ TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限 - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) : この変数は、バックフィルの同時実行を制御する DDL 操作の再編成ワーカーの数を設定します。 -- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : この変数は、`re-organize`フェーズの DDL 操作のバッチ サイズを設定し、バックフィルされるデータの量を制御します。 +- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : この変数は、`re-organize`フェーズの DDL 操作のバッチサイズを設定し、バックフィルされるデータの量を制御します。 推奨値: diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index d114a2fa2aa47..d6bb968ff4be7 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc ## 監視アーキテクチャ {#monitoring-architecture} -[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。[Grafana](https://grafana.com/)は、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 +[Prometheus](https://prometheus.io/)は、多次元データモデルと柔軟なクエリ言語を備えた時系列データベースです。[Grafana](https://grafana.com/)は、メトリックを分析および視覚化するためのオープン ソースの監視システムです。 ![The monitoring architecture in the TiDB cluster](/media/prometheus-in-tidb.png) diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index bbf1859bd5ffc..22a62d653e522 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -59,7 +59,7 @@ HAProxy をデプロイする前に、ハードウェアとソフトウェアの > **Note:** > -> - サポートされているその他のオペレーティング システムの詳細については、 [HAProxyドキュメント](https://github.com/haproxy/haproxy/blob/master/INSTALL)を参照してください。 +> - サポートされているその他のオペレーティングシステムの詳細については、 [HAProxyドキュメント](https://github.com/haproxy/haproxy/blob/master/INSTALL)を参照してください。 #### 依存関係 {#dependencies} diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index c684f276e9ebe..b883d449e1b3e 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high- # 高同時実行書き込みのベストプラクティス {#best-practices-for-high-concurrency-writes} -このドキュメントでは、TiDB で同時実行性の高い書き込み負荷の高いワークロードを処理するためのベスト プラクティスについて説明します。これは、アプリケーション開発を容易にするのに役立ちます。 +このドキュメントでは、TiDB で同時実行性の高い書き込み負荷の高いワークロードを処理するためのベストプラクティスについて説明します。これは、アプリケーション開発を容易にするのに役立ちます。 ## 対象読者 {#target-audience} diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index fe46f5e4ca2e9..39caeb9bf4d02 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -1,6 +1,6 @@ --- title: Best Practices for Managing Indexes and Identifying Unused Indexes -summary: TiDB でインデックスを管理および最適化し、未使用のインデックスを識別して削除するためのベスト プラクティスを学習します。 +summary: TiDB でインデックスを管理および最適化し、未使用のインデックスを識別して削除するためのベストプラクティスを学習します。 aliases: ['/ja/tidb/stable/index-management-best-practices/'] --- @@ -45,19 +45,19 @@ TiDB は、次のツールを導入することでインデックスの最適化 ## `TIDB_INDEX_USAGE`を使用してインデックスの使用状況を追跡する {#track-index-usage-using-tidb-index-usage} -[TiDB v8.0.0](/releases/release-8.0.0.md)で導入された`TIDB_INDEX_USAGE`システム テーブルは、インデックスの使用方法に関するリアルタイムの分析情報を提供し、クエリ パフォーマンスの最適化や不要なインデックスの削除に役立ちます。 +[TiDB v8.0.0](/releases/release-8.0.0.md)で導入された`TIDB_INDEX_USAGE`システムテーブルは、インデックスの使用方法に関するリアルタイムの分析情報を提供し、クエリパフォーマンスの最適化や不要なインデックスの削除に役立ちます。 -具体的には、 `TIDB_INDEX_USAGE`システム テーブルを使用して次の操作を実行できます。 +具体的には、 `TIDB_INDEX_USAGE`システムテーブルを使用して次の操作を実行できます。 - 未使用のインデックスの検出: クエリによってアクセスされていないインデックスを識別し、安全に削除できるインデックスを判断するのに役立ちます。 - インデックスの効率を分析する: インデックスが使用される頻度と、効率的なクエリ実行に貢献しているかどうかを追跡します。 -- クエリ パターンを評価する: インデックスが読み取り操作、データ スキャン、キー値 (KV) 要求にどのように影響するかを理解します。 +- クエリパターンを評価する: インデックスが読み取り操作、データスキャン、キー値 (KV) 要求にどのように影響するかを理解します。 -[TiDB v8.4.0](/releases/release-8.4.0.md)から始まる`TIDB_INDEX_USAGE`システム テーブルには、クラスター化されたテーブルの主キーも含まれており、インデックスのパフォーマンスをより詳細に把握できます。 +[TiDB v8.4.0](/releases/release-8.4.0.md)から始まる`TIDB_INDEX_USAGE`システムテーブルには、クラスター化されたテーブルの主キーも含まれており、インデックスのパフォーマンスをより詳細に把握できます。 ### `TIDB_INDEX_USAGE`の主要な指標 {#key-metrics-in-tidb-index-usage} -`TIDB_INDEX_USAGE`システム テーブルのフィールドを確認する場合は、次の SQL ステートメントを実行します。 +`TIDB_INDEX_USAGE`システムテーブルのフィールドを確認する場合は、次の SQL ステートメントを実行します。 ```sql USE INFORMATION_SCHEMA; @@ -90,7 +90,7 @@ DESC TIDB_INDEX_USAGE; ### `TIDB_INDEX_USAGE`を使用して未使用および非効率的なインデックスを特定する {#identify-unused-and-inefficient-indexes-using-tidb-index-usage} -このセクションでは、 `TIDB_INDEX_USAGE`システム テーブルを使用して、未使用のインデックスと非効率的なインデックスを識別する方法について説明します。 +このセクションでは、 `TIDB_INDEX_USAGE`システムテーブルを使用して、未使用のインデックスと非効率的なインデックスを識別する方法について説明します。 - 未使用のインデックス: @@ -99,14 +99,14 @@ DESC TIDB_INDEX_USAGE; - 非効率的なインデックス: - - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックス スキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 + - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックススキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。 -`TIDB_INDEX_USAGE`システム テーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。 +`TIDB_INDEX_USAGE`システムテーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。 ### `TIDB_INDEX_USAGE`効果的に使用する {#use-tidb-index-usage-effectively} -次の点は、 `TIDB_INDEX_USAGE`システム テーブルを正しく理解して使用するのに役立ちます。 +次の点は、 `TIDB_INDEX_USAGE`システムテーブルを正しく理解して使用するのに役立ちます。 #### データの更新が遅れている {#data-updates-are-delayed} @@ -147,13 +147,13 @@ ORDER BY total_queries DESC; | 特徴 | `TIDB_INDEX_USAGE` | `CLUSTER_TIDB_INDEX_USAGE` | | -------- | -------------------------------------- | ---------------------------------- | -| 範囲 | 単一のデータベース インスタンス内のインデックスの使用状況を追跡します。 | TiDB クラスター全体のインデックスの使用状況を集計します。 | -| インデックス追跡 | データは各データベース インスタンスに対してローカルです。 | クラスター全体の集中ビューを提供します。 | -| 主な使用例 | データベース インスタンス レベルでインデックスの使用状況をデバッグします。 | グローバル インデックス パターンとマルチノードの動作を分析します。 | +| 範囲 | 単一のデータベースインスタンス内のインデックスの使用状況を追跡します。 | TiDB クラスター全体のインデックスの使用状況を集計します。 | +| インデックス追跡 | データは各データベースインスタンスに対してローカルです。 | クラスター全体の集中ビューを提供します。 | +| 主な使用例 | データベースインスタンスレベルでインデックスの使用状況をデバッグします。 | グローバルインデックスパターンとマルチノードの動作を分析します。 | ### `CLUSTER_TIDB_INDEX_USAGE`効果的に使用する {#use-cluster-tidb-index-usage-effectively} -`CLUSTER_TIDB_INDEX_USAGE`システム テーブルは複数のノードからのデータを統合するため、次の点に注意してください。 +`CLUSTER_TIDB_INDEX_USAGE`システムテーブルは複数のノードからのデータを統合するため、次の点に注意してください。 - データ更新の遅延 @@ -173,7 +173,7 @@ ORDER BY total_queries DESC; - 使用されなくなったインデックスを識別し、不要なストレージコストを削減します。 - `INSERT` 、 `UPDATE` 、 `DELETE`クエリにオーバーヘッドを追加するインデックスを削除することで、DML 操作を高速化します。 -- クエリ パターンを手動で分析する必要なく、インデックス監査を合理化します。 +- クエリパターンを手動で分析する必要なく、インデックス監査を合理化します。 `schema_unused_indexes`を使用すると、不要なインデックスをすばやく識別し、最小限の労力でデータベースのオーバーヘッドを削減できます。 @@ -249,7 +249,7 @@ SELECT * FROM sys.schema_unused_indexes; ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; ``` -インデックスを不可視にした後、システムのクエリ パフォーマンスを観察します。 +インデックスを不可視にした後、システムのクエリパフォーマンスを観察します。 - パフォーマンスに変化がない場合、インデックスは不要である可能性が高いため、安全に削除できます。 - クエリのレイテンシーが増加すると、インデックスが依然として必要になる可能性があります。 @@ -264,7 +264,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - OLTP ワークロード: 毎日の変動を考慮するために少なくとも 1 週間監視します。 - バッチ処理または ETL ワークロード: 月次財務レポートなどの 1 つの完全なレポート サイクルを許可します。 -- アドホック分析クエリ: クエリ ログを使用して、インデックスを削除する前にインデックスが必要ないことを確認します。 +- アドホック分析クエリ: クエリログを使用して、インデックスを削除する前にインデックスが必要ないことを確認します。 安全のため、最終決定を下す前にすべてのワークロードがテストされていることを確認するために、少なくとも 1 つのビジネス サイクル全体にわたってインデックスを不可視にしておきます。 @@ -282,7 +282,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - [`ALTER TABLE ... INVISIBLE`](/sql-statements/sql-statement-alter-table.md)を使用してインデックスを不可視にし、一時的にインデックスを無効にして、完全に削除する前にその影響を確認します。 - クエリのパフォーマンスが安定している場合は、インデックスの削除に進みます。 - - 最終決定を下す前に、すべてのクエリ パターンを考慮するのに十分な観察期間を確保してください。 + - 最終決定を下す前に、すべてのクエリパターンを考慮するのに十分な観察期間を確保してください。 3. **既存のインデックスを最適化します。** @@ -302,7 +302,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - 選択性の向上。選択性の低いインデックス（フィルタリングする行が多すぎるインデックス）は、次のように最適化できます。 - フィルタリングの効率を向上させるために列を追加します。 - - インデックス構造の変更 (プレフィックス インデックス、複合インデックスなど)。 + - インデックス構造の変更 (プレフィックスインデックス、複合インデックスなど)。 - インデックスの選択性を分析します。`TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`を使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 @@ -317,4 +317,4 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - TiDB の実行計画分析ツールを使用して、インデックスが最適に使用されているかどうかを確認します。 - 新しいインデックスを追加するときは、予期しない回帰を防ぐために、まず分離された環境でテストしてください。 -これらのベスト プラクティスに従うことで、効率的なクエリ実行を実現し、不要なストレージオーバーヘッドを削減し、最適なデータベース パフォーマンスを維持できます。 +これらのベストプラクティスに従うことで、効率的なクエリ実行を実現し、不要なストレージオーバーヘッドを削減し、最適なデータベース パフォーマンスを維持できます。 diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index a864a884869e2..dd7a17a31783d 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -20,7 +20,7 @@ TiKVインスタンスには複数のリージョンが存在します。Raftsto > > この図はRaftstoreのワークフローを示すものであり、実際のコード構造を表すものではありません。 -上の図から、TiDB サーバーからのリクエストは、gRPC モジュールとストレージモジュールを通過した後、KV (キーと値のペア) の読み取りおよび書き込みメッセージになり、対応するリージョンに送信されることがわかります。これらのメッセージはすぐに処理されず、一時的に保存されます。Raftstoreは、各リージョンに処理するメッセージがあるかどうかをポーリングして確認します。リージョンに処理するメッセージがある場合、 Raftstore はこのリージョンのRaftステート マシンを駆動してこれらのメッセージを処理し、これらのメッセージの状態変化に応じて後続の操作を実行します。たとえば、書き込みリクエストが到着すると、 Raftステート マシンはログをディスクに保存し、他のリージョンのレプリカにログを送信します。ハートビート間隔に達すると、 Raftステート マシンはハートビート情報を他のリージョンのレプリカに送信します。 +上の図から、TiDB サーバーからのリクエストは、gRPC モジュールとストレージモジュールを通過した後、KV (キーと値のペア) の読み取りおよび書き込みメッセージになり、対応するリージョンに送信されることがわかります。これらのメッセージはすぐに処理されず、一時的に保存されます。Raftstoreは、各リージョンに処理するメッセージがあるかどうかをポーリングして確認します。リージョンに処理するメッセージがある場合、 Raftstore はこのリージョンのRaftステートマシンを駆動してこれらのメッセージを処理し、これらのメッセージの状態変化に応じて後続の操作を実行します。たとえば、書き込みリクエストが到着すると、 Raftステートマシンはログをディスクに保存し、他のリージョンのレプリカにログを送信します。ハートビート間隔に達すると、 Raftステートマシンはハートビート情報を他のリージョンのレプリカに送信します。 ## パフォーマンスの問題 {#performance-problem} diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 77229547f3558..b1ab7490f393d 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -66,7 +66,7 @@ SQLの複数列インデックスは辞書式順序で並べられます。`(cit ## サンプルデータ {#sample-data} -次の表は、複数列のインデックスによって検索結果がどのように絞り込まれるかを示すサンプル データセットを示しています。 +次の表は、複数列のインデックスによって検索結果がどのように絞り込まれるかを示すサンプルデータセットを示しています。 | 市 | 寝室 | 価格 | | -------- | -- | ---- | @@ -104,14 +104,14 @@ EXPLAIN FORMAT = "brief" +------------------------+------+---------------------------------------------------------------------------------------------+---------------------------------+ ``` -このクエリは、サンプル データから次のフィルター処理された結果を返します。 +このクエリは、サンプルデータから次のフィルター処理された結果を返します。 | 市 | 寝室 | 価格 | | -------- | -- | ---- | | サンフランシスコ | 2 | 1000 | | サンフランシスコ | 2 | 1500 | -複数列のインデックスを使用することで、TiDB は不要な行スキャンを回避し、クエリ パフォーマンスを大幅に向上させます。 +複数列のインデックスを使用することで、TiDB は不要な行スキャンを回避し、クエリパフォーマンスを大幅に向上させます。 ## インデックス範囲の導出 {#index-range-derivation} @@ -238,7 +238,7 @@ CREATE TABLE t1 ( ### 例2: クエリプラン {#example-2-query-plan} -次のクエリ プランは、派生した範囲を示しています。 +次のクエリプランは、派生した範囲を示しています。 ```sql -- Query 5: Conjunctive conditions on (a1, b1) @@ -265,4 +265,4 @@ EXPLAIN FORMAT = "brief" TiDBオプティマイザは、マルチカラムインデックスと高度な範囲導出を使用することで、複雑なSQLクエリのデータアクセスコストを大幅に削減します。結合条件（ `AND` ）と分離条件（ `OR` ）の両方を効果的に管理することで、TiDBは行ベースの式を最適なアクセスパスに変換し、クエリ時間を短縮し、パフォーマンスを向上させます。MySQLとは異なり、TiDBはマルチカラムインデックスの和集合演算と積集合演算をサポートしているため、複雑なフィルタを効率的に処理できます。実用上、この最適化により、TiDBはわずか数ミリ秒でクエリを完了できます。最適化を行わない場合は2分以上かかるため、レイテンシーが大幅に短縮されます。 -MySQL と TiDB のアーキテクチャの違いをさらに詳しく知るには、 [比較ホワイトペーパー](https://www.pingcap.com/ebook-whitepaper/tidb-vs-mysql-product-comparison-guide/)を参照してください。また、これがスケーラビリティ、信頼性、ハイブリッド トランザクションおよび分析ワークロードにとってなぜ重要なのかについても説明します。 +MySQL と TiDB のアーキテクチャの違いをさらに詳しく知るには、 [比較ホワイトペーパー](https://www.pingcap.com/ebook-whitepaper/tidb-vs-mysql-product-comparison-guide/)を参照してください。また、これがスケーラビリティ、信頼性、ハイブリッドトランザクションおよび分析ワークロードにとってなぜ重要なのかについても説明します。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 3a5fef18ac756..6cc98ba2924a4 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -137,12 +137,12 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー ### ホットリージョンのステータス {#hot-region-status} -**Grafana PD/統計- ホットスポット**ページには、次のようなホット リージョンに関するメトリックが表示されます。 +**Grafana PD/統計- ホットスポット**ページには、次のようなホットリージョンに関するメトリックが表示されます。 - ホットライトリージョンのリーダー/ピア分布: ホットライトリージョンにおけるリーダー/ピア分布 - ホット読み取りリージョンのリーダー分布: ホット読み取りリージョンにおけるリーダー分布 -次のコマンドで pd-ctl を使用してホット リージョンのステータスを照会することもできます。 +次のコマンドで pd-ctl を使用してホットリージョンのステータスを照会することもできます。 - `hot read` : ホット読み取りリージョンを照会する - `hot write` : ホット書き込みリージョンを照会する @@ -194,7 +194,7 @@ pd-ctl の`config show`コマンドを使用してスケジュール設定を確 ## 一般的なシナリオにおけるPDスケジューリング {#pd-scheduling-in-common-scenarios} -このセクションでは、いくつかの一般的なシナリオを通じて PD スケジューリング戦略のベスト プラクティスについて説明します。 +このセクションでは、いくつかの一般的なシナリオを通じて PD スケジューリング戦略のベストプラクティスについて説明します。 ### リーダー/リージョンが均等に分布していない {#leadersregions-are-not-evenly-distributed} @@ -244,7 +244,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー ### ホットリージョンが均等に分布していない {#hot-regions-are-not-evenly-distributed} -ホット リージョンのスケジュールの問題は、通常、次のカテゴリに分類されます。 +ホットリージョンのスケジュールの問題は、通常、次のカテゴリに分類されます。 - ホットリージョンは PD メトリックを通じて観察できますが、スケジュール速度が追いつかず、ホットリージョンを時間内に再分配できません。 diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index 4ea90b6a4f4d1..5da3de65a35fa 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -1,6 +1,6 @@ --- title: Best Practices for Handling Millions of Tables in SaaS Multi-Tenant Scenarios -summary: SaaS (Software as a Service) マルチテナント シナリオ、特に単一クラスター内のテーブル数が 100 万を超える環境における TiDB のベスト プラクティスを学習します。 +summary: SaaS (Software as a Service) マルチテナントシナリオ、特に単一クラスター内のテーブル数が 100 万を超える環境における TiDB のベストプラクティスを学習します。 aliases: ['/ja/tidb/stable/saas-best-practices/'] --- @@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/saas-best-practices/'] > > TiDB v8.5.0 以降のバージョンを使用することをお勧めします。 -これらのベスト プラクティスの実際のケース スタディについては、ブログ投稿[300万テーブルへの拡張: TiDB が Atlassian Forge の SaaS プラットフォームを支える仕組み](https://www.pingcap.com/blog/scaling-3-million-tables-how-tidb-powers-atlassian-forge-saas-platform/)を参照してください。 +これらのベストプラクティスの実際のケーススタディについては、ブログ投稿[300万テーブルへの拡張: TiDB が Atlassian Forge の SaaS プラットフォームを支える仕組み](https://www.pingcap.com/blog/scaling-3-million-tables-how-tidb-powers-atlassian-forge-saas-platform/)を参照してください。 ## TiDB ハードウェア推奨事項 {#tidb-hardware-recommendations} @@ -36,8 +36,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 ダッシュボードの**スキーマ ロード**パネルの下にある**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 は、SQL 実行中に、SQL ステートメントに関係するテーブル統計をオンデマンドで統計キャッシュに読み込みます。 diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 6da8e35ae5584..3995bae9ad9fb 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -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} @@ -44,7 +44,7 @@ TiDBは完全な分散トランザクションを提供し、そのモデルは[ - 悲観的トランザクションモード - TiDB では、悲観的トランザクション モードは MySQL とほぼ同じ動作をします。トランザクションは実行フェーズ中にロックを適用し、競合状況での再試行を回避して成功率を高めます。悲観的ロックを適用することで、 `SELECT FOR UPDATE`を使用してデータを事前にロックすることもできます。 + TiDB では、悲観的トランザクションモードは MySQL とほぼ同じ動作をします。トランザクションは実行フェーズ中にロックを適用し、競合状況での再試行を回避して成功率を高めます。悲観的ロックを適用することで、 `SELECT FOR UPDATE`を使用してデータを事前にロックすることもできます。 しかし、アプリケーションシナリオにおける競合が少ない場合は、楽観的トランザクションモデルの方が優れたパフォーマンスを発揮します。 @@ -81,7 +81,7 @@ TiDB は、SQL 構造を Key-Value 構造に自動的にマッピングします ### セカンダリインデックス {#secondary-index} -TiDB は、[グローバルインデックス](/global-indexes.md)インデックスでもある完全なセカンダリインデックスをサポートしています。多くのクエリはインデックスによって最適化できます。したがって、アプリケーションではセカンダリ インデックスを有効に活用することが重要です。 +TiDB は、[グローバルインデックス](/global-indexes.md)インデックスでもある完全なセカンダリインデックスをサポートしています。多くのクエリはインデックスによって最適化できます。したがって、アプリケーションではセカンダリインデックスを有効に活用することが重要です。 MySQLで培った多くの経験は、TiDBにも応用できます。ただし、TiDBには独自の機能があることに留意してください。以下は、TiDBでセカンダリインデックスを使用する際の注意点です。 @@ -114,7 +114,7 @@ MySQLで培った多くの経験は、TiDBにも応用できます。ただし - クエリの同時実行性 - データは複数のリージョンに分散されているため、TiDB ではクエリが並行して実行されます。ただし、システム リソースを大量に消費する可能性があるため、デフォルトでは並行処理の頻度は高くありません。また、OLTP クエリは通常、大量のデータを扱わないため、低い並行処理頻度で十分です。一方、OLAP クエリでは並行処理の頻度が高く、TiDB は以下のシステム変数によってクエリの並行処理頻度を調整します。 + データは複数のリージョンに分散されているため、TiDB ではクエリが並行して実行されます。ただし、システムリソースを大量に消費する可能性があるため、デフォルトでは並行処理の頻度は高くありません。また、OLTP クエリは通常、大量のデータを扱わないため、低い並行処理頻度で十分です。一方、OLAP クエリでは並行処理の頻度が高く、TiDB は以下のシステム変数によってクエリの並行処理頻度を調整します。 - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) : @@ -148,7 +148,7 @@ TiDBクラスタのデプロイには[TiUP](/production-deployment-using-tiup.md ### データインポート {#data-import} -インポート プロセス中の書き込みパフォーマンスを向上させるには、 [TiKVメモリパラメータのパフォーマンスを調整する](/tune-tikv-memory-performance.md)。 +インポートプロセス中の書き込みパフォーマンスを向上させるには、 [TiKVメモリパラメータのパフォーマンスを調整する](/tune-tikv-memory-performance.md)。 ### 書き込み {#write} @@ -162,7 +162,7 @@ TiDBクラスタのデプロイには[TiUP](/production-deployment-using-tiup.md 大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`を使用することをお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`条件としてループを終了します。 -一度に削除する必要のあるデータ量が多い場合、各削除が逆方向にたどるため、このループ方式はどんどん遅くなります。前のデータを削除した後、削除済みフラグが短時間残り（その後、ガベージ コレクションによってすべてクリアされます）、次の`DELETE`ステートメントに影響を与えます。可能であれば、 `WHERE`条件を改良することをお勧めします。 `2017-05-26`上のすべてのデータを削除する必要がある場合は、次のステートメントを使用できます。 +一度に削除する必要のあるデータ量が多い場合、各削除が逆方向にたどるため、このループ方式はどんどん遅くなります。前のデータを削除した後、削除済みフラグが短時間残り（その後、ガベージコレクションによってすべてクリアされます）、次の`DELETE`ステートメントに影響を与えます。可能であれば、 `WHERE`条件を改良することをお勧めします。 `2017-05-26`上のすべてのデータを削除する必要がある場合は、次のステートメントを使用できます。 ```sql for i from 0 to 23: diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index 9d5742b27a7f5..6f520107f028f 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -1,12 +1,12 @@ --- title: Best Practices for Using TiDB Partitioned Tables -summary: TiDB パーティション テーブルを使用してパフォーマンスを向上させ、データ管理を簡素化し、大規模なデータセットを効率的に処理するためのベスト プラクティスを学習します。 +summary: TiDB パーティションテーブルを使用してパフォーマンスを向上させ、データ管理を簡素化し、大規模なデータセットを効率的に処理するためのベストプラクティスを学習します。 aliases: ['/ja/tidb/stable/tidb-partitioned-tables-best-practices/','/ja/tidb/dev/tidb-partitioned-tables-best-practices/'] --- # TiDB パーティションテーブルの使用に関するベストプラクティス {#best-practices-for-using-tidb-partitioned-tables} -このガイドでは、TiDB でパーティション テーブルを使用してパフォーマンスを向上させ、データ管理を簡素化し、大規模なデータセットを効率的に処理する方法について説明します。 +このガイドでは、TiDB でパーティションテーブルを使用してパフォーマンスを向上させ、データ管理を簡素化し、大規模なデータセットを効率的に処理する方法について説明します。 TiDBのパーティションテーブルは、大規模データセットの管理、クエリ効率の向上、一括データ削除の容易化、書き込みホットスポット問題の緩和など、多用途なアプローチを提供します。データを論理セグメントに分割することで、TiDBはパーティションプルーニングを活用し、クエリ実行時に不要なデータをスキップします。これにより、リソース消費が削減され、特に大規模データセットを扱うオンライン分析処理（OLAP）ワークロードにおいてパフォーマンスが向上します。 @@ -20,7 +20,7 @@ TiDBのパーティションテーブルは、大規模データセットの管 > **Note:** > -> 基礎を学ぶには、パーティション プルーニング、インデックス タイプ、パーティション分割方法などの主要な概念について説明している[パーティショニング](/partitioned-table.md)を参照してください。 +> 基礎を学ぶには、パーティションプルーニング、インデックス タイプ、パーティション分割方法などの主要な概念について説明している[パーティショニング](/partitioned-table.md)を参照してください。 ## クエリ効率の向上 {#improve-query-efficiency} @@ -41,7 +41,7 @@ TiDBのパーティションテーブルは、大規模データセットの管 その他の使用例については、 [パーティションプルーニング](/partition-pruning.md)を参照してください。 -### セカンダリ インデックスのクエリ パフォーマンス: 非パーティション テーブルとローカル インデックスとグローバル インデックスの比較 {#query-performance-on-secondary-indexes-non-partitioned-tables-vs-local-indexes-vs-global-indexes} +### セカンダリインデックスのクエリパフォーマンス: 非パーティションテーブルとローカルインデックスとグローバルインデックスの比較 {#query-performance-on-secondary-indexes-non-partitioned-tables-vs-local-indexes-vs-global-indexes} TiDBでは、パーティションテーブルはデフォルトでローカルインデックスを使用し、各パーティションが独自のインデックスセットを保持します。一方、グローバルインデックスは、テーブル全体を1つのインデックスでカバーし、すべてのパーティションにまたがる行を追跡します。 @@ -49,7 +49,7 @@ TiDBでは、パーティションテーブルはデフォルトでローカル #### テスト済みのテーブルタイプ {#tested-table-types} -このテストでは、次のテーブル構成間でのクエリ パフォーマンスを比較します。 +このテストでは、次のテーブル構成間でのクエリパフォーマンスを比較します。 - パーティションテーブル - ローカルインデックスを持つパーティションテーブル @@ -60,7 +60,7 @@ TiDBでは、パーティションテーブルはデフォルトでローカル テストでは次の構成を使用します。 - パーティションテーブルには、 `date`列で定義された 365 個の範囲パーティションが含まれています。 -- ワークロードは、各インデックス キーが複数の行と一致する大量の OLTP クエリ パターンをシミュレートします。 +- ワークロードは、各インデックスキーが複数の行と一致する大量の OLTP クエリパターンをシミュレートします。 - このテストでは、さまざまなパーティション数も評価し、パーティションの粒度がクエリのレイテンシーとインデックスの効率にどのように影響するかを測定します。 #### スキーマ {#schema} @@ -104,10 +104,10 @@ WHERE `fa`.`sid` IN ( ); ``` -このクエリ パターンが代表的なものである理由は次のとおりです。 +このクエリパターンが代表的なものである理由は次のとおりです。 -- パーティション キーのないセカンダリ インデックスをフィルターします。 -- プルーニングが不足しているため、各パーティションのローカル インデックス検索がトリガーされます。 +- パーティションキーのないセカンダリインデックスをフィルターします。 +- プルーニングが不足しているため、各パーティションのローカルインデックス検索がトリガーされます。 - パーティション化されたテーブルに対して、大幅に多くのテーブル検索タスクが生成されます。 #### テスト結果 {#test-results} @@ -121,8 +121,8 @@ WHERE `fa`.`sid` IN ( | グローバルインデックスを持つパーティションテーブル | 14.8ミリ秒 | 69 | 383 | 452 | - **非パーティションテーブル**：最小限のタスクで最高のパフォーマンスを提供します。ほとんどのOLTPワークロードに適しています。 -- **グローバル インデックスを持つパーティション テーブル**: インデックス スキャンの効率は向上しますが、多くの行が一致する場合、テーブル検索のコストは依然として高くなります。 -- **ローカル インデックスを持つパーティション テーブル**: クエリ条件にパーティション キーが含まれていない場合、ローカル インデックス クエリはすべてのパーティションをスキャンします。 +- **グローバルインデックスを持つパーティションテーブル**: インデックススキャンの効率は向上しますが、多くの行が一致する場合、テーブル検索のコストは依然として高くなります。 +- **ローカルインデックスを持つパーティションテーブル**: クエリ条件にパーティションキーが含まれていない場合、ローカルインデックス クエリはすべてのパーティションをスキャンします。 > **Note:** > @@ -171,12 +171,12 @@ WHERE `fa`.`sid` IN ( #### パーティションテーブルにグローバルインデックスを作成する {#create-a-global-index-on-a-partitioned-table} -次のいずれかの方法を使用して、パーティションテーブルにグローバル インデックスを作成できます。 +次のいずれかの方法を使用して、パーティションテーブルにグローバルインデックスを作成できます。 > **Note:** > > - TiDB v8.5.3以前のバージョンでは、一意の列に対してのみグローバルインデックスを作成できました。v8.5.4以降では、一意でない列に対してもグローバルインデックスを作成できます。この制限は、将来のLTSバージョンで解除される予定です。 -> - 一意でないグローバル インデックスの場合は、 `ADD UNIQUE INDEX`ではなく`ADD INDEX`を使用します。 +> - 一意でないグローバルインデックスの場合は、 `ADD UNIQUE INDEX`ではなく`ADD INDEX`を使用します。 > - `GLOBAL`キーワードを明示的に指定する必要があります。 ##### オプション1: `ALTER TABLE`を使用する {#option-1-use-alter-table} @@ -190,7 +190,7 @@ ADD UNIQUE INDEX (col1, col2) GLOBAL; ##### オプション2: テーブル作成時にインデックスを定義する {#option-2-define-the-index-at-table-creation} -テーブルを作成するときにグローバル インデックスを作成するには、 `CREATE TABLE`ステートメントでグローバル インデックスをインラインで定義します。 +テーブルを作成するときにグローバルインデックスを作成するには、 `CREATE TABLE`ステートメントでグローバルインデックスをインラインで定義します。 ```sql CREATE TABLE t ( @@ -209,7 +209,7 @@ PARTITION BY RANGE (id) ( #### パフォーマンス概要 {#performance-summary} -TiDB パーティション テーブルのパフォーマンス オーバーヘッドは、パーティションの数とインデックスの種類によって異なります。 +TiDB パーティションテーブルのパフォーマンスオーバーヘッドは、パーティションの数とインデックスの種類によって異なります。 - **パーティション数**：パーティション数が増えるとパフォーマンスが低下します。パーティション数が少ない場合は影響は無視できるかもしれませんが、ワークロードによって異なります。 - **ローカルインデックス**：クエリに有効なパーティションプルーニング条件が含まれていない場合、パーティション数が直接的に[リモート プロシージャ コール (RPC)](https://docs.pingcap.com/tidb/stable/glossary/#remote-procedure-call-rpc)の数を決定します。つまり、パーティション数が増えると、通常、RPCが増加し、レイテンシーが増加します。 @@ -217,12 +217,12 @@ TiDB パーティション テーブルのパフォーマンス オーバーヘ #### 推奨事項 {#recommendations} -TiDB でパーティション テーブルとインデックスを設計するときは、次のガイドラインに従います。 +TiDB でパーティションテーブルとインデックスを設計するときは、次のガイドラインに従います。 - パーティションテーブルは必要な場合にのみ使用してください。ほとんどのOLTPワークロードでは、適切にインデックスが設定されたパーティションテーブルの方がパフォーマンスが向上し、管理が簡単になります。 -- すべてのクエリに、少数のパーティションに一致する有効なパーティション プルーニング条件が含まれている場合は、ローカル インデックスを使用します。 -- 効果的なパーティション プルーニング条件がなく、多数のパーティションに一致する重要なクエリには、グローバル インデックスを使用します。 -- DDL 操作の効率 (高速`DROP PARTITION`など) が優先され、潜在的なパフォーマンスへの影響が許容できる場合にのみ、ローカル インデックスを使用します。 +- すべてのクエリに、少数のパーティションに一致する有効なパーティションプルーニング条件が含まれている場合は、ローカルインデックスを使用します。 +- 効果的なパーティションプルーニング条件がなく、多数のパーティションに一致する重要なクエリには、グローバルインデックスを使用します。 +- DDL 操作の効率 (高速`DROP PARTITION`など) が優先され、潜在的なパフォーマンスへの影響が許容できる場合にのみ、ローカルインデックスを使用します。 ## 一括データ削除を容易にする {#facilitate-bulk-data-deletion} @@ -241,13 +241,13 @@ TiDBでは、 [TTL (存続時間)](/time-to-live.md)を使用するか、パー - パーティション構成: 10 分ごとに 1 つのパーティションを削除します。 - ワークロード: 50 および 100 の同時スレッドによるバックグラウンド書き込みワークロード。 -テストでは、実行時間、システム リソースの使用量、および削除された行の合計数を測定します。 +テストでは、実行時間、システムリソースの使用量、および削除された行の合計数を測定します。 #### 調査結果 {#findings} > **Note:** > -> このセクションで説明するパフォーマンス上の利点は、グローバル インデックスのないパーティション テーブルにのみ適用されます。 +> このセクションで説明するパフォーマンス上の利点は、グローバルインデックスのないパーティションテーブルにのみ適用されます。 TTL パフォーマンスに関する調査結果は次のとおりです。 @@ -265,7 +265,7 @@ TTL パフォーマンスに関する調査結果は次のとおりです。 以下の例では匿名化されたテーブル構造を使用しています。TTLの詳細については、 [TTL（Time to Live）を使用して定期的にデータを削除する](/time-to-live.md)を参照してください。 -次の例は、TTL 対応のテーブル スキーマを示しています。 +次の例は、TTL 対応のテーブルスキーマを示しています。 ```sql CREATE TABLE `ad_cache` ( @@ -349,15 +349,15 @@ ALTER TABLE A DROP PARTITION A_2024363; #### 推奨事項 {#recommendations} -- パーティションテーブルでグローバル インデックスが使用される場合、 `DROP PARTITION` 、 `TRUNCATE PARTITION` 、 `REORGANIZE PARTITION`などの DDL 操作の実行時間が長くなることが予想されます。 -- パーティションを頻繁に削除し、パフォーマンスへの影響を最小限に抑える必要がある場合は、ローカル インデックスを使用して、より高速で効率的なパーティション管理を実現します。 +- パーティションテーブルでグローバルインデックスが使用される場合、 `DROP PARTITION` 、 `TRUNCATE PARTITION` 、 `REORGANIZE PARTITION`などの DDL 操作の実行時間が長くなることが予想されます。 +- パーティションを頻繁に削除し、パフォーマンスへの影響を最小限に抑える必要がある場合は、ローカルインデックスを使用して、より高速で効率的なパーティション管理を実現します。 ## ホットスポットの問題を軽減する {#mitigate-hotspot-issues} TiDB では、読み取りまたは書き込みトラフィックが[リージョン](/tidb-storage.md#region)に不均等に分散されている場合にホットスポットが発生します。ホットスポットは、次のような場合によく発生します。 - 単調に増加する主キー ( `AUTO_INCREMENT`主キーと`AUTO_ID_CACHE=1`など)。 -- デフォルト値が`CURRENT_TIMESTAMP`である datetime 列のセカンダリ インデックス。 +- デフォルト値が`CURRENT_TIMESTAMP`である datetime 列のセカンダリインデックス。 TiDBは新しい行とインデックスエントリを「右端」のリージョンに追加します。時間が経つにつれて、この動作は次のような問題を引き起こす可能性があります。 @@ -412,17 +412,17 @@ PARTITION BY KEY (id) PARTITIONS 16; パーティション化されたテーブルには次のような利点があります。 - **バランスの取れた書き込みワークロード**: ホットスポットが複数のパーティションとリージョンに分散され、競合が軽減され、挿入パフォーマンスが向上します。 -- **パーティション プルーニングによるクエリ パフォーマンスの向上**: パーティション キーでフィルターするクエリの場合、TiDB は無関係なパーティションをスキップし、スキャンされるデータを削減して、クエリのレイテンシーを改善します。 +- **パーティションプルーニングによるクエリパフォーマンスの向上**: パーティションキーでフィルターするクエリの場合、TiDB は無関係なパーティションをスキップし、スキャンされるデータを削減して、クエリのレイテンシーを改善します。 ### 制限事項 {#limitations} -パーティション テーブルを使用する前に、次の制限を考慮してください。 +パーティションテーブルを使用する前に、次の制限を考慮してください。 - パーティションテーブルをパーティションテーブルに変換すると、TiDB によってパーティションごとに個別のリージョンが作成されるため、リージョンの合計数が増加します。 - パーティションキーでフィルタリングしないクエリでは、パーティションプルーニングを使用できません。TiDBはすべてのパーティションをスキャンするか、すべてのパーティションにわたってインデックス検索を実行する必要があるため、コプロセッサタスクの数が増加し、パフォーマンスが低下する可能性があります。 - たとえば、次のクエリではパーティション キー ( `id` ) が使用されていないため、パフォーマンスが低下する可能性があります。 + たとえば、次のクエリではパーティションキー ( `id` ) が使用されていないため、パフォーマンスが低下する可能性があります。 ```sql SELECT * FROM server_info WHERE `serial_no` = ?; @@ -440,7 +440,7 @@ PARTITION BY KEY (id) PARTITIONS 16; ### ホットスポットを読む {#read-hotspots} -範囲パーティション化されたテーブルでは、クエリがパーティション キーでデータをフィルター処理しない場合、新しい空のパーティションが読み取りホットスポットになる可能性があります。 +範囲パーティション化されたテーブルでは、クエリがパーティションキーでデータをフィルター処理しない場合、新しい空のパーティションが読み取りホットスポットになる可能性があります。 **根本的な原因：** @@ -452,7 +452,7 @@ PARTITION BY KEY (id) PARTITIONS 16; ### ホットスポットを書き込む {#write-hotspots} -時間ベースの列をパーティション キーとして使用すると、トラフィックが新しいパーティションに移行したときに書き込みホットスポットが発生する可能性があります。 +時間ベースの列をパーティションキーとして使用すると、トラフィックが新しいパーティションに移行したときに書き込みホットスポットが発生する可能性があります。 **根本的な原因：** @@ -466,7 +466,7 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの ### パーティションテーブルの種類の比較 {#comparison-of-partitioned-table-types} -次の表は、非クラスター化パーティション テーブル、クラスター化パーティション テーブル、およびクラスター化非パーティション テーブルを比較したものです。 +次の表は、非クラスター化パーティションテーブル、クラスター化パーティションテーブル、およびクラスター化非パーティションテーブルを比較したものです。 | テーブルタイプ | リージョンの事前分割 | 読み取りパフォーマンス | 書き込みスケーラビリティ | パーティションごとのデータクリーンアップ | | -------------------- | ---------- | ------------ | ------------ | -------------------- | @@ -487,7 +487,7 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの #### 適切なシナリオ {#suitable-scenarios} -低レイテンシの読み取りよりも書き込みのスケーラビリティと操作のシンプルさが重要な場合は、クラスター化されていないパーティション テーブルを使用します。 +低レイテンシの読み取りよりも書き込みのスケーラビリティと操作のシンプルさが重要な場合は、クラスター化されていないパーティションテーブルを使用します。 #### ベストプラクティス {#best-practices} @@ -561,7 +561,7 @@ SPLIT PARTITION TABLE employees INDEX `PRIMARY` BETWEEN (1, "1970-01-01") AND (1 この例では、各パーティションの主キー範囲を指定された境界内の``リージョンに分割します。 -パーティションテーブル内のすべてのパーティションのセカンダリ インデックスのリージョンを分割するには、次の SQL ステートメントを使用します。 +パーティションテーブル内のすべてのパーティションのセカンダリインデックスのリージョンを分割するには、次の SQL ステートメントを使用します。 ```sql SPLIT PARTITION TABLE employees INDEX `idx_employees_on_store_id` BETWEEN (1) AND (1000) REGIONS ; @@ -624,7 +624,7 @@ SHOW TABLE employees PARTITION (p4) regions; - [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) : `IMPORT INTO ... FROM SELECT ...` - [オンラインDDL](/dm/feature-online-ddl.md) : `ALTER TABLE`を使用した直接スキーマ変換 -このセクションでは、両方の変換方向についてこれらの方法の効率と影響を比較し、ベスト プラクティスの推奨事項を示します。 +このセクションでは、両方の変換方向についてこれらの方法の効率と影響を比較し、ベストプラクティスの推奨事項を示します。 ### パーティションテーブルスキーマ: `fa` {#partitioned-table-schema-fa} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index aadbbd5c6be80..14a47e2559281 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -13,12 +13,12 @@ UUID（Universally Unique Identifiers）は、分散データベースにおけ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment.md)整数と比較して次の利点があります。 - UUIDは複数のシステムで競合のリスクなく生成できます。場合によっては、TiDBへのネットワーク通信回数を削減し、パフォーマンスを向上させることができます。 -- UUID は、ほとんどのプログラミング言語とデータベース システムでサポートされています。 +- UUID は、ほとんどのプログラミング言語とデータベースシステムでサポートされています。 - URLの一部として使用される場合、UUIDは列挙攻撃に対して脆弱ではありません。一方、 `AUTO_INCREMENT`数字を使用すると、請求書IDやユーザーIDを推測される可能性があります。 ## ベストプラクティス {#best-practices} -このセクションでは、TiDB で UUID を保存およびインデックス付けするためのベスト プラクティスについて説明します。 +このセクションでは、TiDB で UUID を保存およびインデックス付けするためのベストプラクティスについて説明します。 ### バイナリとして保存 {#store-as-binary} diff --git a/binary-package.md b/binary-package.md index 6d286fbc4b417..9a585b955ebd6 100644 --- a/binary-package.md +++ b/binary-package.md @@ -1,11 +1,11 @@ --- title: TiDB Installation Packages -summary: TiDB インストール パッケージと、含まれる特定のコンポーネントについて説明します。 +summary: TiDB インストールパッケージと、含まれる特定のコンポーネントについて説明します。 --- -# TiDB インストール パッケージ {#tidb-installation-packages} +# TiDB インストールパッケージ {#tidb-installation-packages} -[TiUPをオフラインで展開する](/production-deployment-using-tiup.md#deploy-tiup-offline)前に、 [TiUPオフラインコンポーネントパッケージを準備する](/production-deployment-using-tiup.md#prepare-the-tiup-offline-component-package)で説明されているように TiDB のバイナリ パッケージをダウンロードする必要があります。 +[TiUPをオフラインで展開する](/production-deployment-using-tiup.md#deploy-tiup-offline)前に、 [TiUPオフラインコンポーネントパッケージを準備する](/production-deployment-using-tiup.md#prepare-the-tiup-offline-component-package)で説明されているように TiDB のバイナリパッケージをダウンロードする必要があります。 TiDBバイナリパッケージは、amd64およびarm64アーキテクチャで利用可能です。どちらのアーキテクチャでも、TiDBは`TiDB-community-server`と`TiDB-community-toolkit` 2つのバイナリパッケージを提供します。 diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index cb8890f74900c..5518378e01b96 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -20,11 +20,11 @@ summary: 最適化ルールと式プッシュダウンの動作を制御する | 集計除去 | 集約を排除する | 実行計画から不要な集計演算子を削除しようとします。 | | 投影の除去 | 投影を排除する | 実行計画から不要な投影演算子を削除します。 | | 最大/最小排除 | 最大最小排除 | 集計におけるいくつかの最大/最小関数を`order by` + `limit 1`形式に書き換えます。 | -| 述語プッシュダウン | 述語プッシュダウン | 述語を、データ ソースに近い演算子にプッシュダウンしようとします。 | +| 述語プッシュダウン | 述語プッシュダウン | 述語を、データソースに近い演算子にプッシュダウンしようとします。 | | 外部結合の除去 | 外部結合の排除 | 実行計画から不要な左結合または右結合を削除しようとします。 | | パーティションプルーニング | パーティションプロセッサ | 述語によって拒否されたパーティションをプルーニングし、パーティションテーブルクエリを`UnionAll + Partition Datasource`形式に書き換えます。 | | 集計プッシュダウン | 集約プッシュダウン | 集約をその子にプッシュダウンしようとします。 | -| TopNプッシュダウン | トップnプッシュダウン | TopN 演算子をデータ ソースに近い場所にプッシュしようとします。 | +| TopNプッシュダウン | トップnプッシュダウン | TopN 演算子をデータソースに近い場所にプッシュしようとします。 | | 結合順序の変更 | 結合順序の変更 | 複数テーブルの結合順序を決定します。 | | ウィンドウ関数からTopNまたはLimitを導出する | ウィンドウからトップnを派生する | ウィンドウ関数から TopN または Limit 演算子を導出します。 | diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 65f5c888ed0ca..2008e478964d5 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -84,7 +84,7 @@ TiDB BRは以下の機能を提供します。 - フルバックアップを復元する - - クラスターのスナップショット バックアップの復元: スナップショット バックアップ データを、空のクラスター、またはデータの競合がないクラスター (同じスキーマまたはテーブルを持つ) に復元できます。詳細については、 [スナップショットバックアップを復元する](/br/br-snapshot-guide.md#restore-cluster-snapshots)を参照してください。さらに、バックアップ データから特定のデータベースまたはテーブルを復元し、不要なデータを除外することができます。詳細については、 [バックアップデータから特定のデータベースまたはテーブルを復元する](/br/br-snapshot-guide.md#restore-a-database-or-a-table)を参照してください。 + - クラスターのスナップショットバックアップの復元: スナップショットバックアップデータを、空のクラスター、またはデータの競合がないクラスター (同じスキーマまたはテーブルを持つ) に復元できます。詳細については、 [スナップショットバックアップを復元する](/br/br-snapshot-guide.md#restore-cluster-snapshots)を参照してください。さらに、バックアップデータから特定のデータベースまたはテーブルを復元し、不要なデータを除外することができます。詳細については、 [バックアップデータから特定のデータベースまたはテーブルを復元する](/br/br-snapshot-guide.md#restore-a-database-or-a-table)を参照してください。 - 任意の時点へのデータ復元（PITR） @@ -93,7 +93,7 @@ TiDB BRは以下の機能を提供します。 #### TiDBクラスターのパフォーマンスと影響を回復する {#restore-performance-and-impact-on-tidb-clusters} - データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 [パフォーマンスとインパクトを回復](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)をご覧ください。 -- 各 TiKV ノードでは、PITR は 30 GiB/h でログ データを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)ご覧ください。 +- 各 TiKV ノードでは、PITR は 30 GiB/h でログデータを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)ご覧ください。 ## バックアップストレージ {#backup-storage} @@ -112,9 +112,9 @@ TiDBの一部の機能が有効化または無効化されている場合、バ | --------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GBK文字セット | | v5.4.0より前のバージョンのBRは`charset=GBK`テーブルの復元をサポートしていません。また、v5.4.0より前のTiDBクラスタへの`charset=GBK`テーブルのリカバリをサポートするBRのバージョンもありません。 | | クラスター化インデックス | [#565](https://github.com/pingcap/br/issues/565) | リストア時にグローバル変数`tidb_enable_clustered_index`の値がバックアップ時の値と一致していることを確認してください。一致しない場合、 `default not found`エラーやデータインデックスの不整合など、データの不整合が発生する可能性があります。 | -| 新しい照合順序 | [#352](https://github.com/pingcap/br/issues/352) | 復元中の`new_collation_enabled`テーブル内の`mysql.tidb`変数の値がバックアップ中の値と一致していることを確認してください。そうしないと、データ インデックスの不整合が発生し、チェックサムが失敗する可能性があります。詳細については、 [FAQ - BRが`new_collations_enabled_on_first_bootstrap`不一致を報告するのはなぜですか？](/faq/backup-and-restore-faq.md#why-is-new_collation_enabled-mismatch-reported-during-restore)を参照してください。 | +| 新しい照合順序 | [#352](https://github.com/pingcap/br/issues/352) | 復元中の`new_collation_enabled`テーブル内の`mysql.tidb`変数の値がバックアップ中の値と一致していることを確認してください。そうしないと、データインデックスの不整合が発生し、チェックサムが失敗する可能性があります。詳細については、 [FAQ - BRが`new_collations_enabled_on_first_bootstrap`不一致を報告するのはなぜですか？](/faq/backup-and-restore-faq.md#why-is-new_collation_enabled-mismatch-reported-during-restore)を参照してください。 | | グローバル一時テーブル | | データのバックアップと復元には、 BRのバージョン5.3.0以降を使用していることを確認してください。そうでない場合、バックアップ対象のグローバル一時テーブルの定義でエラーが発生します。 | -| TiDB Lightning物理インポート | | アップストリーム データベースがTiDB Lightningの物理インポート モードを使用している場合、ログ バックアップでデータをバックアップできません。データのインポート後に完全バックアップを実行することをお勧めします。詳細については、 [上流データベースがTiDB Lightningを使用して物理インポートモードでデータをインポートすると、ログバックアップ機能が利用できなくなります。なぜでしょうか？](/faq/backup-and-restore-faq.md#when-the-upstream-database-imports-data-using-tidb-lightning-in-the-physical-import-mode-the-log-backup-feature-becomes-unavailable-why)を参照してください。 | +| TiDB Lightning物理インポート | | アップストリーム データベースがTiDB Lightningの物理インポートモードを使用している場合、ログバックアップでデータをバックアップできません。データのインポート後に完全バックアップを実行することをお勧めします。詳細については、 [上流データベースがTiDB Lightningを使用して物理インポートモードでデータをインポートすると、ログバックアップ機能が利用できなくなります。なぜでしょうか？](/faq/backup-and-restore-faq.md#when-the-upstream-database-imports-data-using-tidb-lightning-in-the-physical-import-mode-the-log-backup-feature-becomes-unavailable-why)を参照してください。 | | TiCDC | | BR v8.2.0 以降: リストア対象のクラスターにチェンジフィードがあり、チェンジフィードの[CheckpointTS](/ticdc/ticdc-classic-architecture.md#checkpointts)が BackupTS より前の場合、 BR はリストアを実行しません。 BRバージョン v8.2.0 より前: リストア対象のクラスターにアクティブな TiCDC チェンジフィードがある場合、 BR はリストアを実行しません。 | | ベクトル検索 | | データのバックアップと復元には、 BR v8.4.0 以降のバージョンを使用していることを確認してください。テーブルを で復元することは [ベクトルデータ型](/ai/reference/vector-search-data-types.md)v8.4.0 より前の TiDB クラスタではサポートされていません。 | @@ -126,7 +126,7 @@ TiDBの一部の機能が有効化または無効化されている場合、バ バックアップとリストアを実行する前に、 BR はTiDB クラスタのバージョンを自身のバージョンと比較し、互換性を確認します。バージョンに互換性がない場合、 BR はエラーを報告して終了します。バージョンチェックを強制的にスキップするには、 `--check-requirements=false`を設定します。バージョンチェックをスキップすると、データに互換性の問題が生じる可能性があることに注意してください。 -バージョン 7.0.0 以降、TiDB は SQL ステートメントによるバックアップおよびリストア操作を段階的にサポートしています。そのため、クラスタ データのバックアップおよびリストアを行う際には、TiDB クラスタと同じメジャー バージョンのBRツールを使用することを強く推奨します。また、メジャー バージョンをまたいでのデータ バックアップおよびリストア操作は避けてください。これにより、リストア操作のスムーズな実行とデータの一貫性が確保されます。バージョン 7.6.0 以降、 BR はデフォルトで一部の`mysql`システム テーブルにデータをリストアします。つまり、 `--with-sys-table`オプションはデフォルトで`true`に設定されます。異なるバージョンの TiDB クラスタにデータを復元する際に、システム テーブルのスキーマが異なるために`[BR:Restore:ErrRestoreIncompatibleSys]incompatible system table`と同様のエラーが発生した場合は、 `--with-sys-table=false`を設定してシステム テーブルの復元をスキップし、このエラーを回避できます。 +バージョン 7.0.0 以降、TiDB は SQL ステートメントによるバックアップおよびリストア操作を段階的にサポートしています。そのため、クラスタデータのバックアップおよびリストアを行う際には、TiDB クラスタと同じメジャーバージョンのBRツールを使用することを強く推奨します。また、メジャーバージョンをまたいでのデータバックアップおよびリストア操作は避けてください。これにより、リストア操作のスムーズな実行とデータの一貫性が確保されます。バージョン 7.6.0 以降、 BR はデフォルトで一部の`mysql`システムテーブルにデータをリストアします。つまり、 `--with-sys-table`オプションはデフォルトで`true`に設定されます。異なるバージョンの TiDB クラスタにデータを復元する際に、システムテーブルのスキーマが異なるために`[BR:Restore:ErrRestoreIncompatibleSys]incompatible system table`と同様のエラーが発生した場合は、 `--with-sys-table=false`を設定してシステムテーブルの復元をスキップし、このエラーを回避できます。 #### TiDB v6.6.0より前のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-before-tidb-v660} @@ -134,7 +134,7 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 | バックアップバージョン（縦軸）／復元バージョン（横軸） | TiDB v6.0に復元する | TiDB v6.1に復元する | TiDB v6.2に復元する | TiDB v6.3、v6.4、またはv6.5に復元してください。 | TiDB v6.6に復元する | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | -------------- | -------------- | -------------------------------- | ------------------------ | -| TiDB v6.0、v6.1、v6.2、v6.3、v6.4、または v6.5 スナップショット バックアップ | 互換性あり（既知の問題[#36379](https://github.com/pingcap/tidb/issues/36379) ：バックアップデータに空のスキーマが含まれている場合、 BR がエラーを報告する可能性があります。） | 互換性がある | 互換性がある | 互換性がある | 互換性あり（BRはv6.6である必要があります） | +| TiDB v6.0、v6.1、v6.2、v6.3、v6.4、または v6.5 スナップショットバックアップ | 互換性あり（既知の問題[#36379](https://github.com/pingcap/tidb/issues/36379) ：バックアップデータに空のスキーマが含まれている場合、 BR がエラーを報告する可能性があります。） | 互換性がある | 互換性がある | 互換性がある | 互換性あり（BRはv6.6である必要があります） | | TiDB v6.3、v6.4、v6.5、またはv6.6のログバックアップ | 互換性がない | 互換性がない | 互換性がない | 互換性がある | 互換性がある | #### TiDB v6.5.0とv8.5.0間のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-between-tidb-v650-and-v850} @@ -169,7 +169,7 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 > **Note:** > > - システムテーブル以外のデータのみがバックアップされる場合（フルバックアップまたはログバックアップ）、すべてのバージョンは互換性があります。 -> - `mysql`システム テーブルの復元が互換性のないシナリオでは、 `--with-sys-table=false`を設定してすべてのシステム テーブルの復元をスキップするか、より細かいフィルターを使用して互換性のないシステム テーブルのみをスキップすることで問題を解決できます。たとえば、 `--filter '*.*' --filter "__TiDB_BR_Temporary_*.*" --filter '!mysql.*' --filter 'mysql.bind_info' --filter 'mysql.user' --filter 'mysql.global_priv' --filter 'mysql.global_grants' --filter 'mysql.default_roles' --filter 'mysql.role_edges' --filter '!sys.*' --filter '!INFORMATION_SCHEMA.*' --filter '!PERFORMANCE_SCHEMA.*' --filter '!METRICS_SCHEMA.*' --filter '!INSPECTION_SCHEMA.*'`などです。 +> - `mysql`システムテーブルの復元が互換性のないシナリオでは、 `--with-sys-table=false`を設定してすべてのシステムテーブルの復元をスキップするか、より細かいフィルターを使用して互換性のないシステムテーブルのみをスキップすることで問題を解決できます。たとえば、 `--filter '*.*' --filter "__TiDB_BR_Temporary_*.*" --filter '!mysql.*' --filter 'mysql.bind_info' --filter 'mysql.user' --filter 'mysql.global_priv' --filter 'mysql.global_grants' --filter 'mysql.default_roles' --filter 'mysql.role_edges' --filter '!sys.*' --filter '!INFORMATION_SCHEMA.*' --filter '!PERFORMANCE_SCHEMA.*' --filter '!METRICS_SCHEMA.*' --filter '!INSPECTION_SCHEMA.*'`などです。 > - `-`該当するシナリオに互換性の制限がないことを意味します。 ## 関連項目 {#see-also} diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index e6bac22696e97..b3db062bea38f 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -80,14 +80,14 @@ tiup br restore full --pd "${PD_IP}:2379" \
-**スナップショット データを Azure Blob Storage にバックアップする** +**スナップショットデータを Azure Blob Storage にバックアップする** ```shell tiup br backup full -u "${PD_IP}:2379" \ --storage "azure://external/backup-20220915?account-name=${account-name}&account-key=${account-key}" ``` -**Azure Blob Storage のスナップショット バックアップ データから`test`データベースを復元します。** +**Azure Blob Storage のスナップショットバックアップデータから`test`データベースを復元します。** ```shell tiup br restore db --db test -u "${PD_IP}:2379" \ @@ -104,10 +104,10 @@ tiup br restore db --db test -u "${PD_IP}:2379" \
-バックアップの前に、S3 上のバックアップ ディレクトリにアクセスするための次の権限を設定します。 +バックアップの前に、S3 上のバックアップディレクトリにアクセスするための次の権限を設定します。 -- バックアップ中に`s3:DeleteObject`およびバックアップ & リストア ( BR ) `s3:AbortMultipartUpload`バックアップ ディレクトリ`s3:GetObject`アクセスするための最小権限: `s3:ListBucket` 、および`s3:PutObject` -- 復元中に TiKV とBRがバックアップ ディレクトリにアクセスするための最小権限: `s3:ListBucket`と`s3:GetObject` 。 +- バックアップ中に`s3:DeleteObject`およびバックアップ & リストア ( BR ) `s3:AbortMultipartUpload`バックアップディレクトリ`s3:GetObject`アクセスするための最小権限: `s3:ListBucket` 、および`s3:PutObject` +- 復元中に TiKV とBRがバックアップディレクトリにアクセスするための最小権限: `s3:ListBucket`と`s3:GetObject` 。 バックアップディレクトリをまだ作成していない場合は、 [バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照して指定のリージョンに S3 バケットを作成してください。必要に応じて、 [フォルダを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)を参照してバケット内にフォルダを作成することもできます。 @@ -185,8 +185,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト > **Note:** > - > この方法を使用する場合は、手順 3 で TiKV を再起動する必要があります。クラスターを再起動できない場合は、 **方法 1: バックアップと復元のアクセス キーを指定する**を使用します。 - + > この方法を使用する場合は、手順 3 で TiKV を再起動する必要があります。クラスターを再起動できない場合は、 **方法 1: バックアップと復元のアクセスキーを指定する**を使用します。 1. このノードの TiKV ポートが`24000` 、つまり systemd サービスの名前が`tikv-24000`であるとします。 ```shell diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index 221d695913110..ea6375fafc849 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -18,7 +18,7 @@ PITR を使用すると、前述の要件を満たすことができます。 PITRを使用するには、TiDBクラスタ（v6.2.0以上）をデプロイし、 BRをTiDBクラスタと同じバージョンにアップデートする必要があります。このドキュメントでは、例としてv8.5.5を使用しています。 -次の表は、TiDB クラスターで PITR を使用するために推奨されるハードウェア リソースを示しています。 +次の表は、TiDB クラスターで PITR を使用するために推奨されるハードウェアリソースを示しています。 | コンポーネント | CPU | メモリ | ディスク | AWSインスタンス | インスタンス数 | | ---- | ----- | ------- | ---- | --------- | ------- | @@ -54,11 +54,11 @@ TiUPを使用してBRをインストールまたはアップグレードしま ## バックアップストレージ（Amazon S3）を構成する {#configure-backup-storage-amazon-s3} -バックアップ タスクを開始する前に、次の点を含めてバックアップストレージを準備します。 +バックアップタスクを開始する前に、次の点を含めてバックアップストレージを準備します。 1. バックアップデータを保存する S3 バケットとディレクトリを準備します。 2. S3 バケットにアクセスするための権限を設定します。 -3. 各バックアップ データを保存するサブディレクトリを計画します。 +3. 各バックアップデータを保存するサブディレクトリを計画します。 詳細な手順は次のとおりです。 @@ -72,7 +72,7 @@ TiUPを使用してBRをインストールまたはアップグレードしま - バックアップ クラスター内の TiKV とBRには`s3:GetObject` `s3://tidb-pitr-bucket/backup-data`ディレクトリ`s3:DeleteObject` `s3:ListBucket` 、および`s3:PutObject` `s3:AbortMultipartUpload`権限が必要です。 - 復元クラスター内の TiKV とBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`と`s3:GetObject`権限が必要です。 -3. スナップショット (完全) バックアップやログ バックアップなどのバックアップ データを保存するディレクトリ構造を計画します。 +3. スナップショット (完全) バックアップやログバックアップなどのバックアップデータを保存するディレクトリ構造を計画します。 - すべてのスナップショットバックアップデータは`s3://tidb-pitr-bucket/backup-data/snapshot-${date}`ディレクトリに保存されます。 `${date}`スナップショットバックアップの開始時刻です。例えば、2022/05/12 00:01:30 に開始されたスナップショットバックアップは`s3://tidb-pitr-bucket/backup-data/snapshot-20220512000130`に保存されます。 - ログバックアップデータは`s3://tidb-pitr-bucket/backup-data/log-backup/`ディレクトリに保存されます。 @@ -81,9 +81,9 @@ TiUPを使用してBRをインストールまたはアップグレードしま 最小限のデータ損失、迅速な回復、および 1 か月以内のビジネス監査の要件を満たすには、次のようにバックアップ ポリシーを設定できます。 -- ログ バックアップを実行して、データベース内のデータの変更を継続的にバックアップします。 -- 2 日ごとに午前 0 時にスナップショット バックアップを実行します。 -- スナップショット バックアップ データとログ バックアップ データを 30 日以内に保持し、30 日以上経過したバックアップ データをクリーンアップします。 +- ログバックアップを実行して、データベース内のデータの変更を継続的にバックアップします。 +- 2 日ごとに午前 0 時にスナップショットバックアップを実行します。 +- スナップショットバックアップデータとログバックアップデータを 30 日以内に保持し、30 日以上経過したバックアップデータをクリーンアップします。 ## ログバックアップを実行する {#run-log-backup} @@ -94,7 +94,7 @@ tiup br log start --task-name=pitr --pd="${PD_IP}:2379" \ --storage='s3://tidb-pitr-bucket/backup-data/log-backup' ``` -ログ バックアップ タスクの実行中に、バックアップ ステータスを照会できます。 +ログバックアップタスクの実行中に、バックアップ ステータスを照会できます。 ```shell tiup br log status --task-name=pitr --pd="${PD_IP}:2379" @@ -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にスナップショットバックアップを実行します diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 708da0648a5f8..9ff7d502fe85a 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -31,7 +31,7 @@ TiKVは自動チューニング機能の動的な設定をサポートしてい tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v ``` -オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 `tikv-ctl`を使用して`backup.num-threads`の値をより大きな数値に変更できます。 +オフライン クラスターでバックアップタスクを実行する場合、バックアップを高速化するために、 `tikv-ctl`を使用して`backup.num-threads`の値をより大きな数値に変更できます。 ## 制限事項 {#limitations} @@ -45,7 +45,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v バックアッププロセスには、SSTのデコード、エンコード、圧縮、解凍といった多くの処理が含まれており、CPUリソースを消費します。さらに、過去のテストケースでは、バックアッププロセス中に、バックアップに使用されるスレッドプールのCPU使用率が100%に近づくことが確認されています。これは、バックアップタスクが多くのCPUリソースを消費していることを意味します。TiKVは、バックアップタスクで使用されるスレッド数を調整することで、バックアップタスクで使用されるCPUコア数を制限し、バックアップタスクがクラスターのパフォーマンスに与える影響を軽減します。 -- 問題 2:**ホットスポットのあるクラスター**の場合、ホットスポットがある TiKV ノード上のバックアップ タスクが過度に制限され、全体的なバックアップ プロセスが遅くなることがあります。 +- 問題 2:**ホットスポットのあるクラスター**の場合、ホットスポットがある TiKV ノード上のバックアップタスクが過度に制限され、全体的なバックアッププロセスが遅くなることがあります。 - 解決策: ホットスポット ノードを削除するか、ホットスポット ノードの自動調整を無効にします (これにより、クラスターのパフォーマンスが低下する可能性があります)。 @@ -55,21 +55,21 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v ## 実装 {#implementation} -自動チューニングは、バックアップ タスクで使用されるスレッド プールのサイズを調整して、クラスターの全体的な CPU 使用率が特定のしきい値を超えないようにします。 +自動チューニングは、バックアップタスクで使用されるスレッドプールのサイズを調整して、クラスターの全体的な CPU 使用率が特定のしきい値を超えないようにします。 この機能には、TiKV設定ファイルに記載されていない関連する設定項目が2つあります。これらの設定項目は内部調整のみを目的としています。バックアップタスクを実行する際に、これらの設定項目を設定する必要は**ありません**。 - `backup.auto-tune-remain-threads` : - - 自動調整は、バックアップ タスクで使用されるリソースを制御し、同じノード上の他のタスクで少なくとも`backup.auto-tune-remain-threads`コアが使用可能であることを保証します。 + - 自動調整は、バックアップタスクで使用されるリソースを制御し、同じノード上の他のタスクで少なくとも`backup.auto-tune-remain-threads`コアが使用可能であることを保証します。 - デフォルト値: `round(0.2 * vCPU)` - `backup.auto-tune-refresh-interval` : - - 自動調整により、 `backup.auto-tune-refresh-interval`分ごとに統計が更新され、バックアップ タスクで使用できる CPU コアの最大数が再計算されます。 + - 自動調整により、 `backup.auto-tune-refresh-interval`分ごとに統計が更新され、バックアップタスクで使用できる CPU コアの最大数が再計算されます。 - デフォルト値: `1m` -以下は、自動チューニングの動作例です。`*`はバックアップ タスクで使用される CPU コアを示します。`^`は他のタスクで使用される CPU コアを示します。`-`は、アイドル状態の CPU コアを示します。 +以下は、自動チューニングの動作例です。`*`はバックアップタスクで使用される CPU コアを示します。`^`は他のタスクで使用される CPU コアを示します。`-`は、アイドル状態の CPU コアを示します。 ``` |--------| The server has 8 logical CPU cores. @@ -78,7 +78,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v |^^^^**--| Because the cluster workload gets higher, auto-tune adjusts the size of the thread pool to `2`. After that, the cluster still has 2 idle CPU cores. ``` -**バックアップ CPU 使用率**パネルでは、自動調整によって調整されたスレッド プールのサイズを確認できます。 +**バックアップ CPU 使用率**パネルでは、自動調整によって調整されたスレッドプールのサイズを確認できます。 ![Grafana dashboard example of backup auto-tune metrics](/media/br/br-auto-throttle.png) diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 8bc968a215772..fe26b689c938f 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -105,12 +105,12 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints" > ``` -外部ストレージでは、チェックポイント データのディレクトリ構造は次のようになります。 +外部ストレージでは、チェックポイントデータのディレクトリ構造は次のようになります。 -- ルート パス`restore-{downstream-cluster-ID}`は、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 -- パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。 -- パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 -- パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイント データが保存されます。 +- ルートパス`restore-{downstream-cluster-ID}`は、ダウンストリームクラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 +- パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログファイルのチェックポイントデータが保存されます。 +- パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログバックアップによってバックアップされない SST ファイルのチェックポイントデータが保存されます。 +- パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイントデータが保存されます。 @@ -155,7 +155,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 初期リストアでは、 `br`はスナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 -初期復元中にログ復元フェーズに入ると、 `br`は指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 +初期復元中にログ復元フェーズに入ると、 `br`は指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイントデータ、アップストリームクラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`を指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 初期リストア中のログリストアフェーズに入る前に、 `br`が`restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。 **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。** diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md index 43d01c162ac08..fdc818d870092 100644 --- a/br/br-compact-log-backup.md +++ b/br/br-compact-log-backup.md @@ -1,6 +1,6 @@ --- title: Compact Log Backup -summary: ログ バックアップを SST 形式に圧縮することで、ポイントインタイム リカバリ (PITR) の効率を向上させる方法を学習します。 +summary: ログバックアップを SST 形式に圧縮することで、ポイントインタイムリカバリ (PITR) の効率を向上させる方法を学習します。 --- # コンパクトログバックアップ {#compact-log-backup} @@ -9,7 +9,7 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ ## 概要 {#overview} -従来のログ バックアップでは、書き込み操作が極めて非構造化された方法で保存されるため、次のような問題が発生する可能性があります。 +従来のログバックアップでは、書き込み操作が極めて非構造化された方法で保存されるため、次のような問題が発生する可能性があります。 - **回復パフォーマンスの低下**: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1 つずつ書き込む必要があります。 - **書き込み増幅**: すべての書き込みは、L0 から最下レベルまでレベルごとに圧縮する必要があります。 @@ -32,11 +32,11 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ ### 手作業による圧縮 {#manual-compaction} -このセクションでは、ログ バックアップを手動で圧縮する手順について説明します。 +このセクションでは、ログバックアップを手動で圧縮する手順について説明します。 #### 前提条件 {#prerequisites} -ログ バックアップを手動で圧縮するには、 `tikv-ctl`と`br` 2 つのツールが必要です。 +ログバックアップを手動で圧縮するには、 `tikv-ctl`と`br` 2 つのツールが必要です。 #### ステップ1:ストレージをBase64でエンコードする {#step-1-encode-storage-to-base64} @@ -49,7 +49,7 @@ br operator base64ify --storage "s3://your/log/backup/storage/here" --load-creds > **Note:** > > - 上記のコマンドを実行する際にオプション`--load-creds`を指定した場合、エンコードされたBase64文字列には、現在のBR環境から読み込まれた認証情報が含まれます。適切なセキュリティとアクセス制御を確保するためにご注意ください。 -> - `--storage`の値は、ログ バックアップ タスクの`log status`コマンドの出力と一致する必要があります。 +> - `--storage`の値は、ログバックアップタスクの`log status`コマンドの出力と一致する必要があります。 #### ステップ2: ログ圧縮を実行する {#step-2-execute-log-compaction} diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index 2c0595c6f67d4..efeeaf843f76c 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -13,7 +13,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ ## 制限事項 {#limitations} -増分バックアップの復元では、増分 DDL ステートメントをフィルター処理するためにバックアップ時点のデータベース テーブルのスナップショットを使用するため、増分バックアップ プロセス中に削除されたテーブルはデータの復元後も存在する可能性があり、手動で削除する必要があります。 +増分バックアップの復元では、増分 DDL ステートメントをフィルター処理するためにバックアップ時点のデータベーステーブルのスナップショットを使用するため、増分バックアッププロセス中に削除されたテーブルはデータの復元後も存在する可能性があり、手動で削除する必要があります。 増分バックアップでは、テーブル名の一括変更はサポートされていません。増分バックアップ中にテーブル名の一括変更が行われた場合、データの復元が失敗する可能性があります。テーブル名の一括変更後に完全バックアップを実行し、復元時に最新の完全バックアップを使用して増分データを置き換えることをお勧めします。 @@ -21,7 +21,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ - デフォルト値`true`ままにしておくと、増分リストアを開始する前に、再生が必要なDDLが厳密にチェックされます。このモードでは、 `ADD INDEX` 、 `MODIFY COLUMN` 、 `REORG PARTITION`まだサポートされていません。増分バックアップとログバックアップを併用する場合は、増分バックアッププロセス中に、前述のDDLが存在しないことを確認してください。そうでない場合、これら3つのDDLを正しく再生できません。 -- リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`から`false`設定して増分リカバリ フェーズでのチェックをスキップできます。 +- リカバリプロセス全体でログバックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`から`false`設定して増分リカバリ フェーズでのチェックをスキップできます。 ## 増分データをバックアップする {#back-up-incremental-data} @@ -41,21 +41,21 @@ tiup br backup full --pd "${PD_IP}:2379" \ ``` - `--lastbackupts` : 最後のバックアップのタイムスタンプ。 -- `--ratelimit` : バックアップ タスクを実行する**TiKV あたりの**最大速度 (MiB/秒)。 +- `--ratelimit` : バックアップタスクを実行する**TiKV あたりの**最大速度 (MiB/秒)。 - `storage` : バックアップデータのストレージパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 ## 増分データを復元する {#restore-incremental-data} 増分データをリストアする際は、 `LAST_BACKUP_TS`より前にバックアップされたすべてのデータがターゲットクラスターにリストアされていることを確認してください。また、増分リストアはデータを更新するため、リストア中に他の書き込みが行われていないことを確認する必要があります。そうしないと、競合が発生する可能性があります。 -次のコマンドは、 `backup-101/snapshot-202209081330`ディレクトリに保存されている完全バックアップ データを復元します。 +次のコマンドは、 `backup-101/snapshot-202209081330`ディレクトリに保存されている完全バックアップデータを復元します。 ```shell tiup br restore full --pd "${PD_IP}:2379" \ --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` -次のコマンドは、 `backup-101/snapshot-202209081330/incr`ディレクトリに保存されている増分バックアップ データを復元します。 +次のコマンドは、 `backup-101/snapshot-202209081330/incr`ディレクトリに保存されている増分バックアップデータを復元します。 ```shell tiup br restore full --pd "${PD_IP}:2379" \ diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index 33f82c0c91db5..2b7d9008f6134 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -118,7 +118,7 @@ PITRの全プロセスは以下のとおりです。 2. BRはバックアップデータを完全に復元します。 - - 完全なバックアップ データを復元します。スナップショットバックアップデータの復元プロセスの詳細については、 [スナップショットバックアップデータを復元する](/br/br-snapshot-architecture.md#process-of-restore)を参照してください。 + - 完全なバックアップデータを復元します。スナップショットバックアップデータの復元プロセスの詳細については、 [スナップショットバックアップデータを復元する](/br/br-snapshot-architecture.md#process-of-restore)を参照してください。 3. BRはログバックアップデータを復元します。 @@ -147,9 +147,9 @@ PITRの全プロセスは以下のとおりです。 ログバックアップでは、以下の種類のファイルが生成されます。 -- `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)を参照してください。 +- `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログバックアップデータをアップロードするたびに生成され、今回アップロードされたすべてのログバックアップデータファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)を参照してください。 - `{store_id}.ts`ファイル: 各 TiKV ノードがログバックアップデータをアップロードするたびに、グローバルチェックポイント ts で更新されます。 `{store_id}`は TiKV ノードのストア ID です。 -- `{min_ts}-{uuid}.log`ファイル: バックアップ タスクの KV 変更ログ データを格納します。 `{min_ts}`は、ファイル内の KV 変更ログ データの最小 TSO タイムスタンプであり、 `{uuid}`はファイル作成時にランダムに生成されます。 +- `{min_ts}-{uuid}.log`ファイル: バックアップタスクの KV 変更ログデータを格納します。 `{min_ts}`は、ファイル内の KV 変更ログデータの最小 TSO タイムスタンプであり、 `{uuid}`はファイル作成時にランダムに生成されます。 - `v1_stream_truncate_safepoint.txt`ファイル: `br log truncate`によって削除されたストレージ内の最新のバックアップデータに対応するタイムスタンプを保存します。 ### バックアップファイルの構造 {#structure-of-backup-files} @@ -176,7 +176,7 @@ PITRの全プロセスは以下のとおりです。 - `flushTs` : バックアップファイルが定期的に外部ストレージにアップロードされる際のタイムスタンプ。この値はPDから取得され、グローバルに一意です。 - `minDefaultTs` （書き込みCFファイルのみに適用）：このバックアップでカバーされる最も早いトランザクション開始時刻。 - - `minTs`および`maxTs` : バックアップ ファイルに含まれるすべてのキー値データの最小および最大タイムスタンプ。 + - `minTs`および`maxTs` : バックアップファイルに含まれるすべてのキー値データの最小および最大タイムスタンプ。 これらのタイムスタンプはすべて、長さが一定になるように左側にゼロを埋め込んだ、固定長の16桁の16進数文字列としてエンコードされます。このエンコード方式により、ファイル名が自然に辞書順にソートされるため、外部ストレージシステムでのバッチリスト表示や範囲フィルタリング操作を効率的に実行できます。 diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 1daf9df1e0520..f723da090a7db 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -35,21 +35,21 @@ summary: このドキュメントでは、ログバックアップの監視、 | **tikv_log_backup_handle_kv_batch** | ヒストグラム | Raftstoreによって送信された KV ペア バッチのサイズのリージョンレベルの統計。 | | **tikv_log_backup_initial_scan_disk_read** | カウンタ | 初期スキャン中にディスクから読み取られたデータのサイズ。Linuxでは、この情報はprocfsから取得され、ブロックデバイスから実際に読み取られたデータのサイズです。このメトリックには、設定項目`initial-scan-rate-limit`適用されます。 | | **tikv_log_backup_incremental_scan_bytes** | ヒストグラム | 初期スキャン中に実際に生成されたKVペアのサイズ。圧縮とリードアンプリフィケーションのため、この値は`tikv_log_backup_initial_scan_disk_read`と異なる場合があります。 | -| **tikv_log_backup_skip_kv_count** | カウンタ | バックアップに役立たないため、ログ バックアップ中にスキップされるRaftイベントの数。 | -| **tikv_log_backup_errors** | カウンタ | ログ バックアップ中に再試行または無視できるエラー。
`type :: ErrorType` | +| **tikv_log_backup_skip_kv_count** | カウンタ | バックアップに役立たないため、ログバックアップ中にスキップされるRaftイベントの数。 | +| **tikv_log_backup_errors** | カウンタ | ログバックアップ中に再試行または無視できるエラー。
`type :: ErrorType` | | **tikv_log_backup_fatal_errors** | カウンタ | ログバックアップ中に再試行または無視できないエラー。このタイプのエラーが発生すると、ログバックアップは一時停止されます。
`type :: ErrorType` | -| **tikv_log_backup_heap_memory** | ゲージ | ログ バックアップ中の初期スキャンで検出された、消費されていないイベントによって占有されているメモリ。 | +| **tikv_log_backup_heap_memory** | ゲージ | ログバックアップ中の初期スキャンで検出された、消費されていないイベントによって占有されているメモリ。 | | **tikv_log_backup_on_event_duration_seconds** | ヒストグラム | KV イベントを一時ファイルに保存する期間。
`stage :: {"write_to_tempfile", "syscall_write"}` | | **tikv_log_backup_store_checkpoint_ts** | ゲージ | ストアレベルのチェックポイントTSは非推奨です。現在のストアによって登録されたGCセーフポイントに近いです。
`task :: string` | | **tidb_log_backup_last_checkpoint** | ゲージ | グローバルチェックポイントTS。ログデータがバックアップされている時点です。
`task :: string` | | **tikv_log_backup_flush_duration_sec** | ヒストグラム | ローカルの一時ファイルを外部ストレージに移動する時間。
`stage :: {"generate_metadata", "save_files", "clear_temp_files"}` | | **tikv_log_backup_flush_file_size** | ヒストグラム | バックアップ中に生成されたファイルのサイズの統計。 | | **tikv_log_backup_initial_scan_duration_sec** | ヒストグラム | 初期スキャンの全体的な所要時間の統計。 | -| **tikv_log_backup_skip_retry_observe** | カウンタ | ログ バックアップ中に無視できるエラーの統計、または再試行がスキップされる理由。
`reason :: {"region-absent", "not-leader", "stale-command"}` | +| **tikv_log_backup_skip_retry_observe** | カウンタ | ログバックアップ中に無視できるエラーの統計、または再試行がスキップされる理由。
`reason :: {"region-absent", "not-leader", "stale-command"}` | | **tikv_log_backup_initial_scan_operations** | カウンタ | 初期スキャン中の RocksDB 関連操作の統計。
`cf :: {"default", "write", "lock"}, op :: RocksDBOP` | | **tikv_log_backup_enabled** | カウンタ | ログバックアップを有効にするかどうか。値が`0`より大きい場合、ログバックアップは有効になります。 | | **tikv_log_backup_observed_region** | ゲージ | リッスンされているリージョンの数。 | -| **tikv_log_backup_task_status** | ゲージ | ログ バックアップ タスクのステータス。`0`は実行中、 `1`は一時停止中、 `2`はエラーを意味します。
`task :: string` | +| **tikv_log_backup_task_status** | ゲージ | ログバックアップタスクのステータス。`0`は実行中、 `1`は一時停止中、 `2`はエラーを意味します。
`task :: string` | | **tikv_log_backup_pending_initial_scan** | ゲージ | 保留中の初期スキャンの統計。
`stage :: {"queuing", "executing"}` | ### ログバックアップアラート {#log-backup-alerts} @@ -61,7 +61,7 @@ summary: このドキュメントでは、ログバックアップの監視、 PITR でアラート項目を構成するには、次の手順に従います。 1. Prometheusが配置されているノードのアラートルール用の設定ファイル（例： `pitr.rules.yml` ）を作成します。このファイルには、 [Prometheusのドキュメント](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 、以下の推奨アラート項目、および設定サンプルに従ってアラートルールを記述します。 -2. Prometheus 構成ファイルの`rule_files`フィールドに、アラート ルール ファイルのパスを追加します。 +2. Prometheus 構成ファイルの`rule_files`フィールドに、アラートルール ファイルのパスを追加します。 3. Prometheusプロセスにシグナル`SIGHUP`送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。 推奨されるアラート項目は次のとおりです。 diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 62d1f4371ed4f..74d3f8f8882a1 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -7,7 +7,7 @@ summary: TiDB ログバックアップおよび PITR ガイドでは、br コマ フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスタ全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたストレージにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)選択できます。 -br コマンドライン ツール (以下、 `br`と呼びます) を使用してデータをバックアップまたは復元する前に、まず[インストール`br`](/br/br-use-overview.md#deploy-and-use-br)行う必要があります。 +br コマンドラインツール (以下、 `br`と呼びます) を使用してデータをバックアップまたは復元する前に、まず[インストール`br`](/br/br-use-overview.md#deploy-and-use-br)行う必要があります。 ## TiDBクラスタのバックアップ {#back-up-tidb-cluster} @@ -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" \ @@ -49,11 +49,11 @@ checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s フィールドの説明は次のとおりです。 -- `name` : ログ バックアップ タスクの名前。 -- `status` : ログ バックアップ タスクのステータス`NORMAL` 、 `PAUSED` 、 `ERROR`を含む)。 -- `start` : ログ バックアップ タスクの開始タイムスタンプ。 +- `name` : ログバックアップタスクの名前。 +- `status` : ログバックアップタスクのステータス`NORMAL` 、 `PAUSED` 、 `ERROR`を含む)。 +- `start` : ログバックアップタスクの開始タイムスタンプ。 - `end` : ログバックアップタスクの終了タイムスタンプ。現在、このフィールドは無効です。 -- `storage` : ログ バックアップの外部ストレージの URI。 +- `storage` : ログバックアップの外部ストレージの URI。 - `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**TiKV-Details**ダッシュボードの`Log Backup`行を確認してください。 - `checkpoint[global]` : ログバックアップの現在の進行状況。PITRを使用して、このタイムスタンプより前の時点に復元できます。 @@ -64,11 +64,11 @@ checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s - `pause-operator-pid` : 一時停止操作を実行するプロセスの PID。 - `pause-payload` : タスクが一時停止されているときに付加される追加情報。 -一時停止の原因が TiKV のエラーである場合は、TiKV からの追加のエラー レポートも表示される場合があります。 +一時停止の原因が TiKV のエラーである場合は、TiKV からの追加のエラーレポートも表示される場合があります。 -- `error[store=*]` : TiKV のエラー コード。 +- `error[store=*]` : TiKV のエラーコード。 - `error-happen-at[store=*]` : TiKV でエラーが発生した時刻。 -- `error-message[store=*]` : TiKV のエラー メッセージ。 +- `error-message[store=*]` : TiKV のエラーメッセージ。 ### 定期的に完全バックアップを実行する {#run-full-backup-regularly} @@ -110,7 +110,7 @@ Restore KV Files <-------------------------------------------------------------- PITRを実行するには、復元ポイントより前のフルバックアップと、フルバックアップポイントから復元ポイントまでのログバックアップを復元する必要があります。そのため、バックアップ保持期間を超えるログバックアップについては、 `tiup br log truncate`を使用して指定時点より前のバックアップを削除できます。**フルスナップショットより前のログバックアップのみを削除することをお勧めします**。 -次の手順では、バックアップ保持期間を超えたバックアップ データをクリーンアップする方法について説明します。 +次の手順では、バックアップ保持期間を超えたバックアップデータをクリーンアップする方法について説明します。 1. バックアップ保持期間外の**最後の完全バックアップ**を取得します。 @@ -134,7 +134,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ ## PITRのパフォーマンス機能 {#performance-capabilities-of-pitr} -- 各 TiKV ノードでは、PITR はスナップショット データ (完全復元) を 2 TiB/h の速度で復元し、ログ データ (メタ ファイルと KV ファイルを含む) を 30 GiB/h の速度で復元できます。 +- 各 TiKV ノードでは、PITR はスナップショットデータ (完全復元) を 2 TiB/h の速度で復元し、ログデータ (メタファイルと KV ファイルを含む) を 30 GiB/h の速度で復元できます。 - BRは古くなったログバックアップデータ（ `tiup br log truncate` ）を600GB/hの速度で削除します。 > **Note:** @@ -144,7 +144,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ > - スナップショットデータの復元速度 = クラスター内のすべての TiKV ノードで復元されたスナップショットデータの合計サイズ / (所要時間 * TiKV ノードの数) > - ログデータの復元速度 = クラスター内のすべての TiKV ノードに復元されたログデータの合計サイズ / (期間 * TiKV ノードの数) > -> 外部ストレージには、単一のレプリカの KV データのみが含まれます。そのため、外部ストレージのデータ サイズは、クラスターで復元された実際のデータ サイズを表すものではありません。BRは、クラスターに設定されているレプリカの数に応じて、すべてのレプリカを復元します。レプリカの数が多いほど、実際に復元できるデータも多くなります。テストのすべてのクラスターのデフォルトのレプリカ数は 3 です。全体的な復元パフォーマンスを向上させるには、TiKV 設定ファイルの[`import.num-threads`](/tikv-configuration-file.md#import)項目とBRコマンドの[`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)オプションを変更できます。アップストリーム クラスターに**多くのリージョン**があり、**フラッシュ間隔が短い**場合、PITR によって多数の小さなファイルが生成されます。これにより、復元中のバッチ処理とディスパッチのオーバーヘッドが増加します。バッチごとに処理されるファイル数を増やすには、次のパラメーターの値を**適度に**増やすことができます。 +> 外部ストレージには、単一のレプリカの KV データのみが含まれます。そのため、外部ストレージのデータサイズは、クラスターで復元された実際のデータサイズを表すものではありません。BRは、クラスターに設定されているレプリカの数に応じて、すべてのレプリカを復元します。レプリカの数が多いほど、実際に復元できるデータも多くなります。テストのすべてのクラスターのデフォルトのレプリカ数は 3 です。全体的な復元パフォーマンスを向上させるには、TiKV 設定ファイルの[`import.num-threads`](/tikv-configuration-file.md#import)項目とBRコマンドの[`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)オプションを変更できます。アップストリームクラスターに**多くのリージョン**があり、**フラッシュ間隔が短い**場合、PITR によって多数の小さなファイルが生成されます。これにより、復元中のバッチ処理とディスパッチのオーバーヘッドが増加します。バッチごとに処理されるファイル数を増やすには、次のパラメーターの値を**適度に**増やすことができます。 > > - `pitr-batch-size` :**バッチあたりの累積バイト数**(デフォルト**16 MiB** )。 > - `pitr-batch-count` :**バッチあたりのファイル数**(デフォルトは**8** )。 @@ -173,7 +173,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ ログバックアップタスクが分散されると、各TiKVノードは継続的にデータを外部ストレージに書き込みます。このプロセスの監視データは**、「TiKV詳細」>「バックアップログ」**ダッシュボードで確認できます。 -メトリックが通常の範囲から外れた場合の通知を受信するには、 [ログバックアップアラート](/br/br-monitoring-and-alert.md#log-backup-alerts)を参照してアラート ルールを構成してください。 +メトリックが通常の範囲から外れた場合の通知を受信するには、 [ログバックアップアラート](/br/br-monitoring-and-alert.md#log-backup-alerts)を参照してアラートルールを構成してください。 ## 参照 {#see-also} diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 7368d0f159fe0..2915eceacdcb0 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -1,20 +1,20 @@ --- title: TiDB Log Backup and PITR Command Manual -summary: TiDB ログ バックアップとポイントインタイム リカバリ (PITR) で使用されるコマンドを紹介します。 +summary: TiDB ログバックアップとポイントインタイムリカバリ (PITR) で使用されるコマンドを紹介します。 --- # TiDB ログバックアップと PITR コマンドマニュアル {#tidb-log-backup-and-pitr-command-manual} -このドキュメントでは、TiDB ログ バックアップとポイントインタイム リカバリ (PITR) で使用されるコマンドについて説明します。 +このドキュメントでは、TiDB ログバックアップとポイントインタイムリカバリ (PITR) で使用されるコマンドについて説明します。 -ログ バックアップと PITR の詳細については、以下を参照してください。 +ログバックアップと PITR の詳細については、以下を参照してください。 - [ログバックアップとPITRガイド](/br/br-pitr-guide.md) - [バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) ## ログバックアップを実行する {#perform-log-backup} -`tiup br log`コマンドを使用してログ バックアップを開始および管理できます。 +`tiup br log`コマンドを使用してログバックアップを開始および管理できます。 ```shell tiup br log --help @@ -36,13 +36,13 @@ Available Commands: 各サブコマンドの説明は次のとおりです。 -- `tiup br log start` : ログ バックアップ タスクを開始します。 -- `tiup br log status` : ログ バックアップ タスクのステータスを照会します。 -- `tiup br log pause` : ログ バックアップ タスクを一時停止します。 -- `tiup br log resume` : 一時停止されたログ バックアップ タスクを再開します。 -- `tiup br log stop` : ログ バックアップ タスクを停止し、タスク メタデータを削除します。 -- `tiup br log truncate` : バックアップストレージからログ バックアップ データをクリーンアップします。 -- `tiup br log metadata` : ログ バックアップ データのメタデータを照会します。 +- `tiup br log start` : ログバックアップタスクを開始します。 +- `tiup br log status` : ログバックアップタスクのステータスを照会します。 +- `tiup br log pause` : ログバックアップタスクを一時停止します。 +- `tiup br log resume` : 一時停止されたログバックアップタスクを再開します。 +- `tiup br log stop` : ログバックアップタスクを停止し、タスク メタデータを削除します。 +- `tiup br log truncate` : バックアップストレージからログバックアップデータをクリーンアップします。 +- `tiup br log metadata` : ログバックアップデータのメタデータを照会します。 ### ログバックアップタスクを開始する {#start-a-log-backup-task} @@ -76,7 +76,7 @@ Global Flags: - `--start-ts` : ログバックアップの開始タイムスタンプを指定します。このパラメータが指定されていない場合、バックアッププログラムは現在の時刻を`start-ts`として使用します。 - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 - `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 -- `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 +- `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログバックアップタスクを開始するために PD にアクセスする必要があります。 - `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -90,9 +90,9 @@ tiup br log start \ ### ログバックアップデータを暗号化する {#encrypt-the-log-backup-data} -BR を使用すると、ログ バックアップ データをバックアップストレージにアップロードする前に暗号化できます。 +BR を使用すると、ログバックアップデータをバックアップストレージにアップロードする前に暗号化できます。 -TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。 +TiDB v8.4.0 以降では、ログバックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログバックアップデータを暗号化できます。 - `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 @@ -114,7 +114,7 @@ tiup br log start \ - `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。 -ローカル ディスクに保存されているマスター キーを使用して暗号化します。 +ローカルディスクに保存されているマスターキーを使用して暗号化します。 ```shell tiup br log start \ @@ -149,12 +149,12 @@ tiup br log start \ > **Note:** > -> - キーが失われると、ログ バックアップ データをクラスターに復元できなくなります。 +> - キーが失われると、ログバックアップデータをクラスターに復元できなくなります。 > - 暗号化機能は、 `br`および TiDB クラスター v8.4.0 以降で使用する必要があります。暗号化されたログバックアップデータは、v8.4.0 より前のクラスターでは復元できません。 ### ログバックアップのステータスを照会する {#query-the-log-backup-status} -`tiup br log status`コマンドを実行して、ログ バックアップの状態を照会できます。 +`tiup br log status`コマンドを実行して、ログバックアップの状態を照会できます。 ヘルプ情報を表示するには、 `tiup br log status --help`を実行します。 @@ -202,16 +202,16 @@ checkpoint[global]: 2022-07-25 22:52:15.518 +0800; gap=2m52s 出力フィールドの説明は次のとおりです。 -- `status` : バックアップ タスクのステータス。 `NORMAL` 、 `ERROR` 、または`PAUSE`になります。 +- `status` : バックアップタスクのステータス。 `NORMAL` 、 `ERROR` 、または`PAUSE`になります。 - `start` : バックアップタスクの開始時刻。バックアップタスクの開始時に指定された`start-ts`です。 - `storage` : バックアップストレージアドレス。 - `speed` : バックアップタスクの合計 QPS。QPS は 1 秒あたりにバックアップされるログの数を意味します。 - `checkpoint [global]` : このチェックポイントより前のすべてのデータがバックアップストレージにバックアップされています。これは、バックアップデータの復元に使用できる最新のタイムスタンプです。 -- `error [store]` : ログ バックアップ プログラムがストレージノード上で検出したエラー。 +- `error [store]` : ログバックアッププログラムがストレージノード上で検出したエラー。 ### ログバックアップタスクを一時停止して再開する {#pause-and-resume-a-log-backup-task} -実行中のログ バックアップ タスクを一時停止するには、 `tiup br log pause`コマンドを実行します。 +実行中のログバックアップタスクを一時停止するには、 `tiup br log pause`コマンドを実行します。 ヘルプ情報を表示するには、 `tiup br log pause --help`を実行します。 @@ -245,7 +245,7 @@ Global Flags: tiup br log pause --task-name=pitr --pd="${PD_IP}:2379" ``` -一時停止されたバックアップ タスクを再開するには、 `tiup br log resume`コマンドを実行します。 +一時停止されたバックアップタスクを再開するには、 `tiup br log resume`コマンドを実行します。 ヘルプ情報を表示するには、 `tiup br log resume --help`を実行します。 @@ -277,7 +277,7 @@ tiup br log resume --task-name=pitr --pd="${PD_IP}:2379" ### ログバックアップタスクを停止して再開する {#stop-and-restart-a-log-backup-task} -`tiup br log stop`コマンドを実行してログ バックアップ タスクを停止し、元の`--storage`ディレクトリを使用して停止したログ バックアップ タスクを再開できます。 +`tiup br log stop`コマンドを実行してログバックアップタスクを停止し、元の`--storage`ディレクトリを使用して停止したログバックアップタスクを再開できます。 ### ログバックアップタスクを停止する {#stop-a-log-backup-task} @@ -323,7 +323,7 @@ tiup br log stop --task-name=pitr --pd="${PD_IP}:2379" ### ログバックアップデータをクリーンアップする {#clean-up-log-backup-data} -`tiup br log truncate`コマンドを実行して、古くなった、または不要になったログ バックアップ データをクリーンアップできます。 +`tiup br log truncate`コマンドを実行して、古くなった、または不要になったログバックアップデータをクリーンアップできます。 ヘルプ情報を表示するには、 `tiup br log truncate --help`を実行します。 @@ -348,7 +348,7 @@ Global Flags: このコマンドはバックアップストレージにのみアクセスし、TiDBクラスターにはアクセスしません。パラメータの説明は以下のとおりです。 - `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 -- `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 +- `--until` : 指定されたタイムスタンプより前のすべてのログバックアップデータを削除します。 - `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -370,7 +370,7 @@ Removing metadata... DONE; take = 24.038962ms ### ログバックアップのメタデータを確認する {#view-the-log-backup-metadata} -`tiup br log metadata`コマンドを実行すると、復元できる最も古いタイムスタンプや最新のタイムスタンプなど、ストレージシステム内のログ バックアップ メタデータを表示できます。 +`tiup br log metadata`コマンドを実行すると、復元できる最も古いタイムスタンプや最新のタイムスタンプなど、ストレージシステム内のログバックアップメタデータを表示できます。 ヘルプ情報を表示するには、 `tiup br log metadata --help`を実行します。 @@ -408,9 +408,9 @@ tiup br log metadata --storage='s3://backup-101/logbackup?access-key=${access-ke > **Note:** > -> `restore point`の増分バックアップ アドレスとして`--full-backup-storage`を指定した場合、このバックアップと以前の増分バックアップを復元するには、増分バックアップと後続のログ バックアップとの互換性を確保するために、パラメータ`--allow-pitr-from-incremental`を`true`に設定する必要があります。 +> `restore point`の増分バックアップ アドレスとして`--full-backup-storage`を指定した場合、このバックアップと以前の増分バックアップを復元するには、増分バックアップと後続のログバックアップとの互換性を確保するために、パラメータ`--allow-pitr-from-incremental`を`true`に設定する必要があります。 -`tiup br restore point`コマンドを実行して、新しいクラスターで PITR を実行したり、ログ バックアップ データを復元したりできます。 +`tiup br restore point`コマンドを実行して、新しいクラスターで PITR を実行したり、ログバックアップデータを復元したりできます。 ヘルプ情報を表示するには、 `tiup br restore point --help`を実行します。 @@ -489,7 +489,7 @@ tiup br restore point --pd="${PD_IP}:2379" --log.crypter.key 0123456789abcdef0123456789abcdef ``` -ログ バックアップがマスター キーを使用して暗号化されている場合は、次のコマンドを使用してバックアップ データを復号化して復元できます。 +ログバックアップがマスターキーを使用して暗号化されている場合は、次のコマンドを使用してバックアップデータを復号化して復元できます。 ```shell tiup br restore point --pd="${PD_IP}:2379" @@ -544,7 +544,7 @@ tiup br restore point --pd="${PD_IP}:2379" \ > **Note:** > > - フィルターを使用してデータを復元する前に、ターゲットクラスターにフィルターに一致するデータベースまたはテーブルが含まれていないことを確認してください。含まれていない場合、復元はエラーで失敗します。 -> - フィルター オプションは、スナップショット バックアップとログ バックアップの両方の復元フェーズ中に適用されます。 +> - フィルター オプションは、スナップショットバックアップとログバックアップの両方の復元フェーズ中に適用されます。 > - 複数の`--filter`オプションを指定して、異なるパターンを含めたり除外したりできます。 > - PITRフィルタリングはシステムテーブルをまだサポートしていません。特定のシステムテーブルを復元する必要がある場合は、代わりにフィルターを指定した`br restore full`コマンドを使用してください。このコマンドはスナップショットバックアップデータのみを復元し、ログバックアップデータは復元しないことに注意してください。 > - 復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の 3 つのケースが考えられます。 @@ -584,20 +584,20 @@ tiup br restore point --pd="${PD_IP}:2379" \ ### 進行中のログバックアップとスナップショット復元の互換性 {#compatibility-between-ongoing-log-backup-and-snapshot-restore} -v8.5.5 以降では、ログ バックアップ タスクの実行中に、次の条件がすべて満たされている場合は、スナップショット リストア ( `br restore [full|database|table]` ) を実行し、進行中のログ バックアップ (以下、「ログ バックアップ」) によってリストアされたデータを適切に記録することができます。 +v8.5.5 以降では、ログバックアップタスクの実行中に、次の条件がすべて満たされている場合は、スナップショットリストア ( `br restore [full|database|table]` ) を実行し、進行中のログバックアップ (以下、「ログバックアップ」) によってリストアされたデータを適切に記録することができます。 - バックアップおよび復元操作を実行するノードには、次の必要な権限があります。 - スナップショットの復元のための、バックアップソースを含む外部ストレージへの読み取りアクセス - ログバックアップで使用されるターゲット外部ストレージへの書き込みアクセス - ログバックアップの対象となる外部ストレージは、Amazon S3（ `s3://` ）、Google Cloud Storage（ `gcs://` ）、またはAzure Blob Storage（ `azblob://` ）です。 -- 復元するデータは、ログ バックアップのターゲットストレージと同じ種類の外部ストレージを使用します。 +- 復元するデータは、ログバックアップのターゲットストレージと同じ種類の外部ストレージを使用します。 - 復元対象のデータとログバックアップのどちらにもローカル暗号化が有効になっていません。詳細については、 [ログバックアップの暗号化](#encrypt-the-log-backup-data)と[スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)を参照してください。 上記の条件のいずれかが満たされていない場合は、次の手順に従ってデータを復元できます。 1. [ログバックアップタスクを停止する](#stop-a-log-backup-task) 。 2. データの復元を実行します。 -3. 復元が完了したら、新しいスナップショット バックアップを実行します。 +3. 復元が完了したら、新しいスナップショットバックアップを実行します。 4. [ログバックアップタスクを再開する](#restart-a-log-backup-task) 。 > **Note:** @@ -615,7 +615,7 @@ TiDB v8.5.5以降では、ログバックアップタスクの実行中にPITR 期間`[t1, t2)`にこのような不整合が発生した場合、この期間のデータを直接復元することはできません。代わりに、以下のいずれかの方法を選択してください。 - データを`t1`まで復元します（不整合期間前のデータを取得します）。 -- `t2`の後に新しいスナップショット バックアップを実行し、それを将来の PITR 操作のベースとして使用します。 +- `t2`の後に新しいスナップショットバックアップを実行し、それを将来の PITR 操作のベースとして使用します。 ### 復元操作を中止する {#abort-restore-operations} diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 431c37f21d016..5614f72469c3d 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -135,8 +135,8 @@ sequenceDiagram スナップショットバックアップでは、以下の種類のファイルが生成されます。 - `SST`ファイル: TiKV ノードがバックアップするデータを格納します。 `SST`ファイルのサイズは、リージョンのサイズと同じです。 -- `backupmeta`ファイル: バックアップ タスクのメタデータを格納します。これには、すべてのバックアップ ファイルの数、キー範囲、サイズ、および各バックアップ ファイルのハッシュ (sha256) 値が含まれます。 -- `backup.lock`ファイル: 複数のバックアップ タスクが同じディレクトリにデータを保存するのを防ぎます。 +- `backupmeta`ファイル: バックアップタスクのメタデータを格納します。これには、すべてのバックアップファイルの数、キー範囲、サイズ、および各バックアップファイルのハッシュ (sha256) 値が含まれます。 +- `backup.lock`ファイル: 複数のバックアップタスクが同じディレクトリにデータを保存するのを防ぎます。 ### SSTファイルの命名形式 {#naming-format-of-sst-files} @@ -160,7 +160,7 @@ sequenceDiagram ### SSTファイルの保存形式 {#storage-format-of-sst-files} - SST ファイルのストレージ形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。 -- SST ファイルのバックアップ データのエンコード形式の詳細については、[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)を参照してください。 +- SST ファイルのバックアップデータのエンコード形式の詳細については、[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)を参照してください。 ### バックアップファイルの構造 {#structure-of-backup-files} diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 77dc2dd9010e8..12d90cc9482f2 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -5,7 +5,7 @@ summary: このドキュメントでは、brコマンドラインツールを使 # スナップショットのバックアップと復元ガイド {#snapshot-backup-and-restore-guide} -このドキュメントでは、br コマンドライン ツール (以下`br`と呼びます) を使用して TiDB スナップショットをバックアップおよび復元する方法について説明します。データをバックアップおよび復元する前に、 [brコマンドラインツールをインストールします](/br/br-use-overview.md#deploy-and-use-br)必要があります。 +このドキュメントでは、br コマンドラインツール (以下`br`と呼びます) を使用して TiDB スナップショットをバックアップおよび復元する方法について説明します。データをバックアップおよび復元する前に、 [brコマンドラインツールをインストールします](/br/br-use-overview.md#deploy-and-use-br)必要があります。 スナップショットバックアップを使用すると、クラスタ全体をバックアップできます。これは[マルチバージョン同時実行制御 (MVCC)](/tidb-storage.md#mvcc)に基づいており、指定されたスナップショット内のすべてのデータをターゲットストレージにバックアップします。バックアップデータのサイズは、クラスタ内の圧縮された単一レプリカのサイズとほぼ同じです。バックアップが完了したら、バックアップデータを空のクラスタまたは競合データを含まないクラスタ（同じスキーマまたは同じテーブルを持つクラスタ）に復元したり、クラスタをスナップショットバックアップの時点に復元したり、クラスタレプリカ設定に従って複数のレプリカを復元したりできます。 @@ -18,7 +18,7 @@ summary: このドキュメントでは、brコマンドラインツールを使 > **Note:** > -> - 以下の例では、Amazon S3 アクセス キーとシークレット キーを使用して権限を認証することを前提としていますIAMロールを使用して権限を認証する場合は、 `--send-credentials-to-tikv` `false`に設定する必要があります。 +> - 以下の例では、Amazon S3 アクセスキーとシークレット キーを使用して権限を認証することを前提としていますIAMロールを使用して権限を認証する場合は、 `--send-credentials-to-tikv` `false`に設定する必要があります。 > - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、[バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 `tiup br backup full`コマンドを実行すると、TiDB クラスタのスナップショットをバックアップできます。ヘルプ情報を表示するには、 `tiup br backup full --help`を実行してください。 @@ -32,7 +32,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ 前述のコマンドでは： - `--backupts` : スナップショットのタイムポイント。形式は[TSO](/tso.md)またはタイムスタンプで、 `400036290571534337`や`2018-05-11 01:42:23 +08:00`などです。このスナップショットのデータがガベージコレクションされると、 `tiup br backup`コマンドはエラーを返し、 `br`は終了します。タイムスタンプを使用してバックアップする場合は、タイムゾーンも指定することをお勧めします。そうしないと、 `br`はデフォルトでローカルタイムゾーンを使用してタイムスタンプを構築するため、バックアップのタイムポイントが正しくない可能性があります。このパラメーターを指定しない場合、 `br`バックアップ開始時刻に対応するスナップショットを選択します。 -- `--storage` : バックアップ データのストレージアドレス。スナップショット バックアップは、Amazon S3、Google Cloud Storage、および Azure Blob Storage をバックアップストレージとしてサポートします。前述のコマンドでは、例として Amazon S3 を使用しています。詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--storage` : バックアップデータのストレージアドレス。スナップショットバックアップは、Amazon S3、Google Cloud Storage、および Azure Blob Storage をバックアップストレージとしてサポートします。前述のコマンドでは、例として Amazon S3 を使用しています。詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 バックアップ中は、下図のように端末に進行状況バーが表示されます。進行状況バーが100%に達すると、バックアップタスクが完了し、合計バックアップ時間、平均バックアップ速度、バックアップデータサイズなどの統計情報が表示されます。 @@ -76,7 +76,7 @@ tiup br validate decode --field="end-version" \ `tiup br restore full`コマンドを実行すると、スナップショットバックアップを復元できます。ヘルプ情報を表示するには、 `tiup br restore full --help`を実行してください。 -次の例では[前のバックアップスナップショット](#back-up-cluster-snapshots)をターゲット クラスターに復元します。 +次の例では[前のバックアップスナップショット](#back-up-cluster-snapshots)をターゲットクラスターに復元します。 ```shell tiup br restore full --pd "${PD_IP}:2379" \ @@ -150,7 +150,7 @@ tiup br restore full \ - BR v5.1.0以降では、スナップショットをバックアップすると、 BRは`mysql`スキーマ内の**システムテーブルを**自動的にバックアップしますが、デフォルトではこれらのシステムテーブルを復元しません。 - バージョン6.2.0以降、 BRでは`--with-sys-table`を指定して、**一部のシステムテーブルのデータを**復元できます。 - バージョン7.6.0以降、 BRは`--with-sys-table`デフォルトで有効にしており、これはBRがデフォルトで**一部のシステムテーブルのデータを**復元することを意味します。 -- バージョン 8.5.5 以降、 BRシステム テーブルの物理的な復元をサポートする`--fast-load-sys-tables`パラメーターが導入されました。このパラメーターはデフォルトで有効になっています。この方式では`RENAME TABLE` DDL ステートメントを使用して、 `__TiDB_BR_Temporary_mysql`データベースのシステム テーブルと`mysql`データベースのシステム テーブルをアトミックに交換します。 `REPLACE INTO` SQL ステートメントを使用したシステム テーブルの論理的な復元とは異なり、物理的な復元ではシステム テーブル内の既存のデータが完全に上書きされます。 +- バージョン 8.5.5 以降、 BRシステムテーブルの物理的な復元をサポートする`--fast-load-sys-tables`パラメーターが導入されました。このパラメーターはデフォルトで有効になっています。この方式では`RENAME TABLE` DDL ステートメントを使用して、 `__TiDB_BR_Temporary_mysql`データベースのシステムテーブルと`mysql`データベースのシステムテーブルをアトミックに交換します。 `REPLACE INTO` SQL ステートメントを使用したシステムテーブルの論理的な復元とは異なり、物理的な復元ではシステムテーブル内の既存のデータが完全に上書きされます。 **BRは、以下のシステムテーブルのデータを復元できます。** @@ -218,9 +218,9 @@ tiup br restore full \ 以下の方法を使用すると、バックアップタスクがクラスタのパフォーマンスに与える影響を手動で制御できます。ただし、これらの2つの方法は、バックアップタスクがクラスタに与える影響を軽減する一方で、バックアップタスクの速度も低下させます。 -- 推奨される方法: TiKV 構成パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。このパラメータは、バックアップ タスクで使用されるワーカー スレッドの数を制御します。バックアップは CPU 負荷の高い操作であるため、このパラメータを調整することで TiKV の CPU 使用率をより正確に制御でき、リソースの分離と予測性を向上させることができます。ほとんどのシナリオでは、 `num-threads`を調整するだけで、バックアップがクラスタに与える影響を制限できます。内部テストでは、スレッド数を`8`以下に設定し、クラスタ全体の CPU 使用率が 60% 未満に維持されている場合、バックアップがフォアグラウンド ワークロードに与える影響はごくわずかであることが示されています。 +- 推奨される方法: TiKV 構成パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。このパラメータは、バックアップタスクで使用されるワーカースレッドの数を制御します。バックアップは CPU 負荷の高い操作であるため、このパラメータを調整することで TiKV の CPU 使用率をより正確に制御でき、リソースの分離と予測性を向上させることができます。ほとんどのシナリオでは、 `num-threads`を調整するだけで、バックアップがクラスタに与える影響を制限できます。内部テストでは、スレッド数を`8`以下に設定し、クラスタ全体の CPU 使用率が 60% 未満に維持されている場合、バックアップがフォアグラウンド ワークロードに与える影響はごくわずかであることが示されています。 -- 代替方法: `backup.num-threads`を既に小さな値 (たとえば`1` ) に設定しているが、バックアップがクラスタに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップ ファイルを外部ストレージに書き込むために使用される帯域幅を MiB/s で制限します。実際のレート制限効果は、圧縮データのサイズによって異なることに注意してください。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`が有効になっている場合、 BR は自動的に`--concurrency`を`1`に設定して、同時リクエストの数を減らします。 +- 代替方法: `backup.num-threads`を既に小さな値 (たとえば`1` ) に設定しているが、バックアップがクラスタに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップファイルを外部ストレージに書き込むために使用される帯域幅を MiB/s で制限します。実際のレート制限効果は、圧縮データのサイズによって異なることに注意してください。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`が有効になっている場合、 BR は自動的に`--concurrency`を`1`に設定して、同時リクエストの数を減らします。 > **Note:** > @@ -242,7 +242,7 @@ tiup br restore full \ 通常の場合、 `--tikv-max-restore-concurrency`はクラスタ構成に基づいて自動的に調整されるため、手動構成は不要です。Grafana の**TiKV-Details** > **Backup & Import** > **Import RPC count**監視メトリックで、 BR がダウンロードするファイルの数が長期間 0 に近いままで、 BRが取り込むファイルの数が常に上限に達している場合、ファイル取り込みタスクが蓄積され、ジョブキューが最大長に達していることを示しています。この場合、タスクの蓄積問題を軽減するために、次の対策を講じることができます。 - - `--ratelimit`パラメータを設定してダウンロード速度を制限し、ファイル取り込みタスクに必要なリソースを確保します。たとえば、いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップ ファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`を超える場合は、このパラメータを`--ratelimit x/2`に設定できます。いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップ ファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`以下である場合は、 `--ratelimit`パラメータを設定せずにそのままにできます。 + - `--ratelimit`パラメータを設定してダウンロード速度を制限し、ファイル取り込みタスクに必要なリソースを確保します。たとえば、いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`を超える場合は、このパラメータを`--ratelimit x/2`に設定できます。いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`以下である場合は、 `--ratelimit`パラメータを設定せずにそのままにできます。 - ジョブキューの最大長を増やすには、 `--tikv-max-restore-concurrency`の値を増やします。 ## 関連項目 {#see-also} diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 6619f9399231e..dd8ca948bc270 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -5,7 +5,7 @@ summary: TiDBスナップショットのバックアップと復元コマンド # TiDB スナップショットのバックアップと復元コマンドマニュアル {#tidb-snapshot-backup-and-restore-command-manual} -このドキュメントでは、次のようなアプリケーション シナリオに応じて、TiDB スナップショットのバックアップと復元のコマンドについて説明します。 +このドキュメントでは、次のようなアプリケーションシナリオに応じて、TiDB スナップショットのバックアップと復元のコマンドについて説明します。 - [クラスターのスナップショットをバックアップする](#back-up-cluster-snapshots) - [データベースまたはテーブルをバックアップする](#back-up-a-database-or-a-table) @@ -46,7 +46,7 @@ tiup br backup full \ > **Note:** > -> - v8.5.0 以降、 BRツールは、バックアップ パフォーマンスを向上させるために、フル バックアップ中のテーブル レベルのチェックサム計算をデフォルトで無効にします ( `--checksum=false` )。 +> - v8.5.0 以降、 BRツールは、バックアップ パフォーマンスを向上させるために、フルバックアップ中のテーブルレベルのチェックサム計算をデフォルトで無効にします ( `--checksum=false` )。 > - BRツールは既にGCへの自己適応をサポートしています。バックアップ中にTiDBのGCセーフポイントが先に進まないように、PDのタイムスタンプ`backupTS` （デフォルトでは最新のPDタイムスタンプ）をPDの`safePoint`に自動的に登録することで、GC設定を手動で設定する必要がなくなります。 バックアップ中は、ターミナルに以下のようにプログレスバーが表示されます。プログレスバーが100%に達すると、バックアップが完了します。 @@ -110,9 +110,9 @@ tiup br backup full \ TiDB v7.5.0以降、 `br`コマンドラインツールに`--ignore-stats`パラメータが導入されました。このパラメータを`false`に設定すると、 `br`コマンドラインツールは列、インデックス、およびテーブルの統計情報のバックアップをサポートします。この場合、バックアップから復元されたTiDBデータベースの統計情報収集タスクを手動で実行したり、自動収集タスクの完了を待ったりする必要はありません。この機能により、データベースのメンテナンス作業が簡素化され、クエリパフォーマンスが向上します。 -このパラメータを`false`に設定しない場合、 `br`コマンドライン ツールはデフォルト設定の`--ignore-stats=true`を使用します。つまり、データのバックアップ中に統計はバックアップされません。 +このパラメータを`false`に設定しない場合、 `br`コマンドラインツールはデフォルト設定の`--ignore-stats=true`を使用します。つまり、データのバックアップ中に統計はバックアップされません。 -以下は、クラスター スナップショット データをバックアップし、テーブル統計を`--ignore-stats=false`でバックアップする例です。 +以下は、クラスター スナップショットデータをバックアップし、テーブル統計を`--ignore-stats=false`でバックアップする例です。 ```shell tiup br backup full \ @@ -120,7 +120,7 @@ tiup br backup full \ --ignore-stats=false ``` -上記の構成でデータをバックアップした後、データを復元すると、バックアップにテーブル統計が含まれている場合、 `br`コマンドライン ツールによってテーブル統計が自動的に復元されます (v8.0.0 以降、 `br`コマンドライン ツールに`--load-stats`パラメータが導入され、バックアップ統計を復元するかどうかが制御されます。デフォルトの動作では、バックアップ統計が復元されます。ほとんどの場合、 `false`に設定する必要はありません)。 +上記の構成でデータをバックアップした後、データを復元すると、バックアップにテーブル統計が含まれている場合、 `br`コマンドラインツールによってテーブル統計が自動的に復元されます (v8.0.0 以降、 `br`コマンドラインツールに`--load-stats`パラメータが導入され、バックアップ統計を復元するかどうかが制御されます。デフォルトの動作では、バックアップ統計が復元されます。ほとんどの場合、 `false`に設定する必要はありません)。 ```shell tiup br restore full \ @@ -146,7 +146,7 @@ tiup br restore full \ BRはバックアップ側でのバックアップデータの暗号化と[Amazon S3にバックアップする際のストレージ側](/br/backup-and-restore-storages.md#amazon-s3-server-side-encryption)サポートしています。必要に応じていずれかの暗号化方式を選択できます。 -TiDB v5.3.0 以降では、次のパラメータを設定することでバックアップ データを暗号化できます。 +TiDB v5.3.0 以降では、次のパラメータを設定することでバックアップデータを暗号化できます。 - `--crypter.method` : 暗号化アルゴリズム`aes128-ctr` `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 - `--crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 @@ -164,7 +164,7 @@ tiup br backup full\ > **Note:** > -> - キーが失われると、バックアップ データをクラスターに復元できなくなります。 +> - キーが失われると、バックアップデータをクラスターに復元できなくなります。 > - 暗号化機能は、 `br`および TiDB クラスタ v5.3.0 以降で使用する必要があります。暗号化されたバックアップデータは、v5.3.0 より前のクラスタでは復元できません。 ## クラスタースナップショットを復元する {#restore-cluster-snapshots} @@ -208,7 +208,7 @@ tiup br restore full \ > **Note:** > -> `REPLACE INTO` SQL ステートメントを使用したシステム テーブルの論理的な復元とは異なり、物理的な復元ではシステム テーブル内の既存のデータが完全に上書きされます。 +> `REPLACE INTO` SQL ステートメントを使用したシステムテーブルの論理的な復元とは異なり、物理的な復元ではシステムテーブル内の既存のデータが完全に上書きされます。 ## データベースまたはテーブルを復元する {#restore-a-database-or-a-table} @@ -218,7 +218,7 @@ tiup br restore full \ データベースをクラスターに復元するには、 `tiup br restore db`コマンドを実行します。 -次の例では、バックアップ データから`test`データベースをターゲット クラスターに復元します。 +次の例では、バックアップデータから`test`データベースをターゲットクラスターに復元します。 ```shell tiup br restore db \ @@ -239,7 +239,7 @@ tiup br restore db \ 単一のテーブルをクラスターに復元するには、 `tiup br restore table`コマンドを実行します。 -次の例では、 `test.usertable`テーブルを Amazon S3 からターゲット クラスターに復元します。 +次の例では、 `test.usertable`テーブルを Amazon S3 からターゲットクラスターに復元します。 ```shell tiup br restore table \ @@ -255,7 +255,7 @@ tiup br restore table \ ### テーブルフィルターを使用して複数のテーブルを復元する {#restore-multiple-tables-with-table-filter} -より複雑なフィルター ルールを使用して複数のテーブルを復元するには、 `tiup br restore full`コマンドを実行し、 [テーブルフィルター](/table-filter.md)を`--filter`または`-f`に指定します。 +より複雑なフィルタールールを使用して複数のテーブルを復元するには、 `tiup br restore full`コマンドを実行し、 [テーブルフィルター](/table-filter.md)を`--filter`または`-f`に指定します。 次の例では、 `db*.tbl*`フィルタルールに一致するテーブルを Amazon S3 からターゲットクラスターに復元します。 diff --git a/br/br-use-overview.md b/br/br-use-overview.md index 5f476dc80f687..b06e3c5fcfdbb 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -5,7 +5,7 @@ summary: TiDB バックアップ＆リストアは、バックアップ方法の # TiDB バックアップとリストアの使用概要 {#usage-overview-of-tidb-backup-and-restore} -このドキュメントでは、バックアップ方法の選択方法、バックアップ データの管理方法、バックアップおよび復元ツールのインストールと展開方法など、TiDB のバックアップおよび復元機能の使用に関するベスト プラクティスについて説明します。 +このドキュメントでは、バックアップ方法の選択方法、バックアップデータの管理方法、バックアップおよび復元ツールのインストールと展開方法など、TiDB のバックアップおよび復元機能の使用に関するベストプラクティスについて説明します。 ## 推奨されるプラクティス {#recommended-practices} @@ -23,9 +23,9 @@ TiDB のバックアップおよび復元機能を使用する前に、推奨さ BRは基本的なバックアップと復元機能のみを提供し、バックアップ管理はサポートしていません。そのため、バックアップデータの管理方法をご自身で決定する必要があります。具体的には、以下のような点についてご検討ください。 - どのバックアップストレージシステムを選択すればよいですか? -- バックアップ タスク中にバックアップ データをどのディレクトリに配置すればよいですか? +- バックアップタスク中にバックアップデータをどのディレクトリに配置すればよいですか? - フルバックアップデータとログバックアップデータのディレクトリはどのように整理すればよいですか? -- ストレージシステム内の履歴バックアップ データをどのように処理しますか? +- ストレージシステム内の履歴バックアップデータをどのように処理しますか? 次のセクションでは、これらの質問に 1 つずつ答えていきます。 @@ -33,10 +33,10 @@ BRは基本的なバックアップと復元機能のみを提供し、バック バックアップデータはAmazon S3、Google Cloud Storage（GCS）、またはAzure Blob Storageに保存することをお勧めします。これらのシステムを使用すれば、バックアップ容量や帯域幅の割り当てを気にする必要がありません。 -TiDB クラスターを独自に構築したデータ センターに導入する場合は、次のプラクティスが推奨されます。 +TiDB クラスターを独自に構築したデータセンターに導入する場合は、次のプラクティスが推奨されます。 - バックアップストレージシステムとして[MinIO](https://docs.min.io/docs/minio-quickstart-guide.html)構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。 -- ネットワーク ファイル システム (NFS、NAS など) ディスクを br コマンドライン ツールとすべての TiKV インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用して、バックアップ データを対応する NFS ディレクトリに書き込みます。 +- ネットワークファイルシステム (NFS、NAS など) ディスクを br コマンドラインツールとすべての TiKV インスタンスにマウントし、POSIX ファイルシステム インターフェイスを使用して、バックアップデータを対応する NFS ディレクトリに書き込みます。 > **Note:** > @@ -44,8 +44,8 @@ TiDB クラスターを独自に構築したデータ センターに導入す **バックアップデータディレクトリを整理する** -- 統合管理のため、スナップショット バックアップとログ バックアップを同じディレクトリ (例: `backup-${cluster-id}` ) に保存します。 -- 各スナップショット バックアップを、バックアップの日付が含まれるディレクトリ (例: `backup-${cluster-id}/fullbackup-202209081330` ) に保存します。 +- 統合管理のため、スナップショットバックアップとログバックアップを同じディレクトリ (例: `backup-${cluster-id}` ) に保存します。 +- 各スナップショットバックアップを、バックアップの日付が含まれるディレクトリ (例: `backup-${cluster-id}/fullbackup-202209081330` ) に保存します。 - ログバックアップは固定ディレクトリ（例： `backup-${cluster-id}/logbackup` ）に保存されます。ログバックアッププログラムは、毎日`logbackup`ディレクトリの下にサブディレクトリを作成し、毎日バックアップされたデータを区別します。 **履歴バックアップデータの処理** @@ -53,12 +53,12 @@ TiDB クラスターを独自に構築したデータ センターに導入す 各バックアップデータのライフサイクル（例えば7日間）を設定する必要があるとします。このようなライフサイクルは**バックアップ保持期間**と呼ばれ、バックアップチュートリアルでも説明されています。 - PITRを実行するには、復元ポイントより前の完全バックアップと、完全バックアップと復元ポイント間のログバックアップを復元する必要があります。そのため、**完全スナップショットより前のログバックアップのみを削除することをお勧めします**。バックアップ保持期間を超えるログバックアップの場合は、 `tiup br log truncate`コマンドを使用して、指定した時点より前のバックアップを削除できます。 -- 保存期間を超えたバックアップ データについては、バックアップ ディレクトリを削除またはアーカイブできます。 +- 保存期間を超えたバックアップデータについては、バックアップディレクトリを削除またはアーカイブできます。 ### データを復元するにはどうすればいいですか? {#how-to-restore-data} -- 完全バックアップ データのみを復元するには、 `tiup br restore`を使用して、指定したバックアップの完全復元を実行できます。 -- ログ バックアップを開始し、定期的に完全バックアップを実行している場合は、 `tiup br restore point`コマンドを実行して、バックアップ保持期間内の任意の時点にデータを復元できます。 +- 完全バックアップデータのみを復元するには、 `tiup br restore`を使用して、指定したバックアップの完全復元を実行できます。 +- ログバックアップを開始し、定期的に完全バックアップを実行している場合は、 `tiup br restore point`コマンドを実行して、バックアップ保持期間内の任意の時点にデータを復元できます。 ## BRをデプロイて使用する {#deploy-and-use-br} @@ -73,7 +73,7 @@ BRを展開するには、次の要件が満たされていることを確認し ### br コマンドラインツールを使用する（推奨） {#use-br-command-line-tool-recommended} -TiDB は、br コマンドライン ツールを使用したバックアップと復元をサポートしています。 +TiDB は、br コマンドラインツールを使用したバックアップと復元をサポートしています。 - `tiup install br`コマンドを[TiUPオンラインを使用してbrコマンドラインツールをインストールする](/migration-tools.md#install-tools-using-tiup)まで実行できます。 - `br`コマンドを使用してデータをバックアップおよび復元する方法の詳細については、次のドキュメントを参照してください。 @@ -86,8 +86,8 @@ TiDB は、br コマンドライン ツールを使用したバックアップ TiDB は、SQL ステートメントを使用した完全バックアップと復元をサポートします。 -- [`BACKUP`](/sql-statements/sql-statement-backup.md) : 完全なスナップショット データをバックアップします。 -- [`RESTORE`](/sql-statements/sql-statement-restore.md) : スナップショット バックアップ データを復元します。 +- [`BACKUP`](/sql-statements/sql-statement-backup.md) : 完全なスナップショットデータをバックアップします。 +- [`RESTORE`](/sql-statements/sql-statement-restore.md) : スナップショットバックアップデータを復元します。 - [`SHOW BACKUPS|RESTORES`](/sql-statements/sql-statement-show-backups.md) : バックアップと復元の進行状況を表示します。 ### Kubernetes でTiDB Operatorを使用する {#use-tidb-operator-on-kubernetes} diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index d3591637b2dd2..80b4afd8fb7fe 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -22,7 +22,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `backup` : `tiup br`のサブコマンド。 - `full` : `tiup br backup`のサブコマンド。 -- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。`"s3://backup-data/snapshot-202209081330/"`は`-s`のパラメーターです。 +- `-s` (または`--storage` ): バックアップファイルが保存されるパスを指定するオプション。`"s3://backup-data/snapshot-202209081330/"`は`-s`のパラメーターです。 - `--pd` : PD サービス アドレスを指定するオプション`"${PD_IP}:2379"`は`--pd`のパラメーターです。 ### コマンドとサブコマンド {#commands-and-sub-commands} @@ -30,9 +30,9 @@ tiup br backup full --pd "${PD_IP}:2379" \ `tiup br`コマンドは複数のサブコマンドの階層で構成されています。現在、br コマンドラインツールには以下のサブコマンドがあります。 - `tiup br backup` : TiDB クラスターのデータをバックアップするために使用されます。 -- `tiup br log` : ログ バックアップ タスクの開始と管理に使用されます。 -- `tiup br restore` : TiDB クラスターのバックアップ データを復元するために使用されます。 -- `tiup br debug` : バックアップ メタデータの解析、バックアップ データのチェックなどに使用されます。 +- `tiup br log` : ログバックアップタスクの開始と管理に使用されます。 +- `tiup br restore` : TiDB クラスターのバックアップデータを復元するために使用されます。 +- `tiup br debug` : バックアップメタデータの解析、バックアップデータのチェックなどに使用されます。 `tiup br backup`および`tiup br restore`は次のサブコマンドが含まれます。 @@ -42,12 +42,12 @@ tiup br backup full --pd "${PD_IP}:2379" \ `tiup br debug`には次のサブコマンドが含まれます。 -- `checksum` : (隠しパラメーター) バックアップ データの整合性をオフラインでチェックし、すべてのバックアップ ファイルが[`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md)で計算された CRC64 チェックサム結果と一致することを確認するために使用されます。 +- `checksum` : (隠しパラメーター) バックアップデータの整合性をオフラインでチェックし、すべてのバックアップファイルが[`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md)で計算された CRC64 チェックサム結果と一致することを確認するために使用されます。 - `backupmeta` : バックアップデータファイル間に交差が存在するかどうかを確認するために使用されます。通常、バックアップデータファイルは交差しません。 - `decode` : 完全バックアップのメタデータファイル`backupmeta` JSON形式に解析するために使用されます。さらに、 `--field`パラメータを使用して特定のフィールドを解析することもできます。 -- `encode` : 完全バックアップの`backupmeta.json`メタデータ ファイルを、データの復元中に使用される protobuf 形式にエンコードするために使用されます。 +- `encode` : 完全バックアップの`backupmeta.json`メタデータファイルを、データの復元中に使用される protobuf 形式にエンコードするために使用されます。 - `reset-pd-config-as-default` : (非推奨) データ回復プロセス中に変更された PD 構成をデフォルト構成に復元するために使用されます。 -- `search-log-backup` : ログ バックアップ データ内の特定のキー情報を検索するために使用されます。 +- `search-log-backup` : ログバックアップデータ内の特定のキー情報を検索するために使用されます。 ### 一般的なオプション {#common-options} @@ -75,7 +75,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ ## ログバックアップのコマンド {#commands-of-log-backup} -ログ バックアップを開始し、ログ バックアップ タスクを管理するには、 `tiup br log`コマンドを実行します。 +ログバックアップを開始し、ログバックアップタスクを管理するには、 `tiup br log`コマンドを実行します。 - [ログバックアップタスクを開始する](/br/br-pitr-manual.md#start-a-log-backup-task) - [ログバックアップのステータスを照会する](/br/br-pitr-manual.md#query-the-log-backup-status) diff --git a/cached-tables.md b/cached-tables.md index 67651fd4a7515..0d8751f9a53e1 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -1,6 +1,6 @@ --- title: Cached Tables -summary: めったに更新されない小さなホットスポット テーブルで読み取りパフォーマンスを向上させるために使用される、TiDB のキャッシュ テーブル機能について学習します。 +summary: めったに更新されない小さなホットスポット テーブルで読み取りパフォーマンスを向上させるために使用される、TiDB のキャッシュテーブル機能について学習します。 --- # キャッシュされたテーブル {#cached-tables} @@ -41,7 +41,7 @@ CREATE TABLE users ( ); ``` -このテーブルをキャッシュ テーブルに設定するには、 `ALTER TABLE`ステートメントを使用します。 +このテーブルをキャッシュテーブルに設定するには、 `ALTER TABLE`ステートメントを使用します。 ```sql ALTER TABLE users CACHE; diff --git a/certificate-authentication.md b/certificate-authentication.md index 9254a88d0bb4e..e9ac69d6ec6ac 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -128,7 +128,7 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの サーバーの鍵と証明書を生成したら、クライアント用の鍵と証明書を生成する必要があります。多くの場合、ユーザーごとに異なる鍵と証明書を生成する必要があります。 -1. 次のコマンドを実行してクライアント キーを生成します。 +1. 次のコマンドを実行してクライアントキーを生成します。 ```bash sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem @@ -219,9 +219,9 @@ TiDBを起動し、ログを確認します。ログに以下の情報が表示 ### クライアント証明書を使用するようにクライアントを構成する {#configure-the-client-to-use-client-certificate} -クライアントがログインにクライアント キーと証明書を使用するようにクライアントを構成します。 +クライアントがログインにクライアントキーと証明書を使用するようにクライアントを構成します。 -MySQL クライアントを例にとると、 `ssl-cert` 、 `ssl-key` 、 `ssl-ca`を指定して、新しく作成されたクライアント証明書、クライアント キー、および CA を使用できます。 +MySQL クライアントを例にとると、 `ssl-cert` 、 `ssl-key` 、 `ssl-ca`を指定して、新しく作成されたクライアント証明書、クライアントキー、および CA を使用できます。 ```bash mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-key /path/to/client-key.new.pem --ssl-ca /path/to/ca-cert.pem @@ -414,7 +414,7 @@ CA証明書は、クライアントとサーバー間の相互検証の基盤と sudo openssl x509 -req -in client-req.new.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.new.pem ``` -3. 新しいクライアント キーと証明書を使用して、クライアント (MySQL など) を TiDB に接続します。 +3. 新しいクライアントキーと証明書を使用して、クライアント (MySQL など) を TiDB に接続します。 ```bash mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-key /path/to/client-key.new.pem --ssl-ca /path/to/ca-cert.pem diff --git a/character-set-and-collation.md b/character-set-and-collation.md index adad2ac41df21..4f8f8a27f62d5 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -394,7 +394,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; - サーバーの文字セットと照合順序は、システム変数`character_set_server`と`collation_server`の値です。 -- デフォルト データベースの文字セットと照合順序は、システム変数`character_set_database`と`collation_database`の値です。 +- デフォルトデータベースの文字セットと照合順序は、システム変数`character_set_database`と`collation_database`の値です。 `character_set_connection`と`collation_connection`を使用して、各接続の文字セットと照合順序を指定するために使用できます。`character_set_client`は、クライアントの文字セットを設定するための変数です。 diff --git a/check-before-deployment.md b/check-before-deployment.md index c5b46cb4c860a..d52fa07a0dbdf 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -11,13 +11,13 @@ summary: TiDB をデプロイする前に環境チェック操作について学 本番環境では、TiKVデータの保存にEXT4ファイルシステムのNVMe SSDを使用することをお勧めします。この構成はベストプラクティスであり、その信頼性、セキュリティ、安定性は多数のオンラインシナリオで実証されています。 -`root`ユーザー アカウントを使用してターゲット マシンにログインします。 +`root`ユーザーアカウントを使用してターゲットマシンにログインします。 データディスクをext4ファイルシステムにフォーマットし、マウントオプション`nodelalloc`と`noatime`ファイルシステムに追加してください。オプション`nodelalloc`を追加しないと、 TiUPデプロイメントは事前チェックに合格できません。オプション`noatime`は任意です。 > **Note:** > -> データ ディスクが ext4 にフォーマットされ、マウント オプションが追加されている場合は、 `umount /dev/nvme0n1p1`コマンドを実行してアンインストールし、以下の 5 番目の手順に直接進んで`/etc/fstab`ファイルを編集し、オプションをファイル システムに再度追加できます。 +> データ ディスクが ext4 にフォーマットされ、マウントオプションが追加されている場合は、 `umount /dev/nvme0n1p1`コマンドを実行してアンインストールし、以下の 5 番目の手順に直接進んで`/etc/fstab`ファイルを編集し、オプションをファイルシステムに再度追加できます。 `/dev/nvme0n1`データ ディスクを例に挙げます。 @@ -73,7 +73,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 └─nvme0n1p1 ext4 c51eb23b-195c-4061-92a9-3fad812cc12f ``` -5. `/etc/fstab`ファイルを編集し、 `nodelalloc`マウント オプションを追加します。 +5. `/etc/fstab`ファイルを編集し、 `nodelalloc`マウントオプションを追加します。 ```bash vi /etc/fstab @@ -101,7 +101,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 /dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered) ``` - ファイルシステムが ext4 であり、マウント オプションに`nodelalloc`が含まれている場合、ターゲット マシンにオプションを使用してデータ ディスク ext4 ファイルシステムを正常にマウントしています。 + ファイルシステムが ext4 であり、マウントオプションに`nodelalloc`が含まれている場合、ターゲットマシンにオプションを使用してデータ ディスク ext4 ファイルシステムを正常にマウントしています。 ## システムスワップをチェックして無効にする {#check-and-disable-system-swap} @@ -109,8 +109,8 @@ TiDB は動作に十分な量のメモリを必要とします。TiDB が使用 - スワップを有効化して使用すると、パフォーマンスのジッター問題が発生する可能性があります。低レイテンシかつ安定性が重要なデータベースサービスでは、オペレーティングシステム層のスワップを恒久的に無効化することをお勧めします。スワップを恒久的に無効化するには、以下の方法があります。 - - オペレーティング システムの初期化フェーズでは、スワップ パーティション ディスクを個別にパーティション分割しないでください。 - - オペレーティング システムの初期化フェーズ中に既に別のスワップ パーティション ディスクをパーティション分割し、スワップを有効にしている場合は、次のコマンドを実行してスワップを無効にします。 + - オペレーティングシステムの初期化フェーズでは、スワップパーティション ディスクを個別にパーティション分割しないでください。 + - オペレーティングシステムの初期化フェーズ中に既に別のスワップパーティション ディスクをパーティション分割し、スワップを有効にしている場合は、次のコマンドを実行してスワップを無効にします。 ```bash echo "vm.swappiness = 0">> /etc/sysctl.conf @@ -139,7 +139,7 @@ TiDBの一部の操作では、サーバーへの一時ファイルの書き込 > **Note:** > - > アプリケーション内に大きなオブジェクトに対する DDL 操作が存在する場合は、 [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630)用に独立した大きなファイル システムを構成することを強くお勧めします。 + > アプリケーション内に大きなオブジェクトに対する DDL 操作が存在する場合は、 [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630)用に独立した大きなファイルシステムを構成することを強くお勧めします。 ```shell sudo mkdir -p /data/tidb-deploy/tempdir @@ -161,7 +161,7 @@ TiDBクラスターでは、読み取り・書き込みリクエストやデー ### ファイアウォールを停止して無効にする {#stop-and-disable-firewalld} -このセクションでは、ターゲット マシンのファイアウォール サービスを停止および無効にする方法について説明します。 +このセクションでは、ターゲットマシンのファイアウォール サービスを停止および無効にする方法について説明します。 1. ファイアウォールの状態を確認してください。以下の例では、CentOS Linuxリリース7.7.1908（Core）を使用しています。 @@ -277,7 +277,7 @@ firewall-cmd --permanent --zone=public --add-service=grafana ## NTPサービスを確認してインストールする {#check-and-install-the-ntp-service} -TiDB は、 ACIDモデルにおけるトランザクションの線形一貫性を保証するためにノード間のクロック同期を必要とする分散データベース システムです。 +TiDB は、 ACIDモデルにおけるトランザクションの線形一貫性を保証するためにノード間のクロック同期を必要とする分散データベースシステムです。 現在、クロック同期の一般的なソリューションは、ネットワークタイムプロトコル（NTP）サービスを使用することです。インターネット上の`pool.ntp.org`タイミングサービスを使用することも、オフライン環境で独自のNTPサービスを構築することもできます。 @@ -401,7 +401,7 @@ sudo systemctl enable ntpd.service ## オペレーティングシステムの最適なパラメータを確認して構成する {#check-and-configure-the-optimal-parameters-of-the-operating-system} -本番環境の TiDB の場合、次の方法でオペレーティング システム構成を最適化することをお勧めします。 +本番環境の TiDB の場合、次の方法でオペレーティングシステム構成を最適化することをお勧めします。 - [透過的巨大ページ（THP）](/tune-operating-system.md#memorytransparent-huge-page-thp)を無効にします。データベースのメモリアクセスは通常、スパースです。高位メモリが著しく断片化されると、THP によるメモリ割り当てのレイテンシーが増大する可能性があります。したがって、パフォーマンスの変動を避けるため、THP を無効にすることをお勧めします。 @@ -428,9 +428,9 @@ sudo systemctl enable ntpd.service > > `[always] madvise never`が出力された場合、THP が有効になっています。無効にする必要があります。 -2. 次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/O Scheduler を確認します。 +2. 次のコマンドを実行して、データディレクトリが配置されているディスクのI/O Scheduler を確認します。 - データ ディレクトリで SD または VD デバイスを使用している場合は、次のコマンドを実行してI/Oスケジューラを確認します。 + データディレクトリで SD または VD デバイスを使用している場合は、次のコマンドを実行してI/Oスケジューラを確認します。 ```bash cat /sys/block/sd[bc]/queue/scheduler @@ -445,7 +445,7 @@ sudo systemctl enable ntpd.service > > `noop [deadline] cfq`が出力された場合、ディスクのI/Oスケジューラは`deadline`モードになっています。これを`noop`に変更する必要があります。 - データ ディレクトリで NVMe デバイスを使用している場合は、次のコマンドを実行してI/Oスケジューラを確認します。 + データディレクトリで NVMe デバイスを使用している場合は、次のコマンドを実行してI/Oスケジューラを確認します。 ```bash cat /sys/block/nvme[01]*/queue/scheduler @@ -473,7 +473,7 @@ sudo systemctl enable ntpd.service > **Note:** > - > - 複数のディスクにデータ ディレクトリが割り当てられている場合は、各ディスクの`ID_SERIAL`を記録するために、各ディスクに対して上記のコマンドを実行する必要があります。 + > - 複数のディスクにデータディレクトリが割り当てられている場合は、各ディスクの`ID_SERIAL`を記録するために、各ディスクに対して上記のコマンドを実行する必要があります。 > - デバイスが`noop`または`none`スケジューラを使用している場合は、 `ID_SERIAL`を記録したり、udev ルールや調整されたプロファイルを構成したりする必要はありません。 4. cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。 @@ -492,11 +492,11 @@ sudo systemctl enable ntpd.service > > `The governor "powersave"`が出力された場合、 cpufreq モジュールの電源ポリシーは`powersave`です。これを`performance`に変更する必要があります。仮想マシンまたはクラウドホストを使用している場合、出力は通常`Unable to determine current policy`であり、何も変更する必要はありません。 -5. オペレーティング システムの最適なパラメータを構成します。 +5. オペレーティングシステムの最適なパラメータを構成します。 - 方法 1:tuned を使用する (推奨) - 1. 現在のオペレーティング システムの調整されたプロファイルを表示するには、 `tuned-adm list`コマンドを実行します。 + 1. 現在のオペレーティングシステムの調整されたプロファイルを表示するには、 `tuned-adm list`コマンドを実行します。 ```bash tuned-adm list @@ -541,7 +541,7 @@ sudo systemctl enable ntpd.service elevator=noop ``` - 出力`include=balanced`は、オペレーティング システムの最適化構成を現在の`balanced`プロファイルに追加することを意味します。 + 出力`include=balanced`は、オペレーティングシステムの最適化構成を現在の`balanced`プロファイルに追加することを意味します。 3. 新しく調整されたプロファイルを適用します。 @@ -555,7 +555,7 @@ sudo systemctl enable ntpd.service - 方法2：スクリプトを使用して設定する。既に方法1を使用している場合は、この方法をスキップしてください。 - 1. デフォルトのカーネル バージョンを確認するには、 `grubby`コマンドを実行します。 + 1. デフォルトのカーネルバージョンを確認するには、 `grubby`コマンドを実行します。 > **Note:** > @@ -587,7 +587,7 @@ sudo systemctl enable ntpd.service > **Note:** > - > `--info`の後には実際のデフォルトのカーネル バージョンが続きます。 + > `--info`の後には実際のデフォルトのカーネルバージョンが続きます。 ``` index=0 @@ -660,7 +660,7 @@ sudo systemctl enable ntpd.service always madvise [never] ``` -7. 次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/Oスケジューラを確認します。 +7. 次のコマンドを実行して、データディレクトリが配置されているディスクのI/Oスケジューラを確認します。 ```bash cat /sys/block/sd[bc]/queue/scheduler @@ -700,7 +700,7 @@ sudo systemctl enable ntpd.service > **Note:** > - > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネル パラメータです。 + > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネルパラメータです。 > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 > - `vm.min_free_kbytes`を少なくとも`1048576` KiB（1 GiB）に設定することをお勧めします。[NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 > - Linux カーネル 4.11 以前を実行しているシステムの場合は、 `net.ipv4.tcp_tw_recycle = 0`を設定することをお勧めします。 @@ -727,7 +727,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t - Backup & Restore (BR) の使用: すべてのBRおよび TiDB 関連の操作を同じユーザーで実行することを強くお勧めします。 - NFSなどのネットワークストレージを使用する場合：ユーザーがすべてのノードで同じUIDとGIDを持っていることを確認してください。NFSは、基盤となるUIDとGIDに基づいてファイルアクセス権限を決定します。ノード間でUIDまたはGIDが異なる場合、またはBRを実行しているユーザーがTiDBを実行しているユーザーと異なる場合（特に`sudo`権限がない場合）、バックアップまたはリストア操作中に権限拒否エラーが発生する可能性があります。 -1. それぞれ`root`ユーザー アカウントを使用してターゲット マシンにログインし、 `tidb`ユーザーを作成してログイン パスワードを設定します。 +1. それぞれ`root`ユーザーアカウントを使用してターゲットマシンにログインし、 `tidb`ユーザーを作成してログイン パスワードを設定します。 ```bash useradd -m -d /home/tidb tidb @@ -778,7 +778,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t > **Note:** > > - NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスを展開するのに適しています。 -> - `tiup cluster deploy`を使用してデプロイメントを完了したら、 `exec`コマンドを使用してクラスター レベルの管理操作を実行できます。 +> - `tiup cluster deploy`を使用してデプロイメントを完了したら、 `exec`コマンドを使用してクラスターレベルの管理操作を実行できます。 NUMA ツールをインストールするには、次の 2 つの方法のいずれかを実行します。 @@ -796,7 +796,7 @@ sudo yum -y install numactl tiup cluster deploy tidb-test v6.1.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] ``` -2. `sudo`権限を使用して`tiup cluster exec`コマンドを実行し、 `tidb-test`クラスター内のすべてのターゲット マシンに NUMA をインストールします。 +2. `sudo`権限を使用して`tiup cluster exec`コマンドを実行し、 `tidb-test`クラスター内のすべてのターゲットマシンに NUMA をインストールします。 ```bash tiup cluster exec tidb-test --sudo --command "yum -y install numactl" diff --git a/choose-index.md b/choose-index.md index 08760827620e8..372704298e6fd 100644 --- a/choose-index.md +++ b/choose-index.md @@ -81,7 +81,7 @@ mysql> SHOW WARNINGS; - インデックスが特定の順序を満たすかどうかを選択します。インデックスの読み取りでは特定の列セットの順序が保証されるため、クエリの順序を満たすインデックスは、この次元で満たさないインデックスよりも優れています。 -- インデックスが[グローバルインデックス](/global-indexes.md)かどうか。パーティション テーブルでは、グローバル インデックスにより、通常のインデックスと比較して SQL の cop タスクの数が効果的に削減され、全体的なパフォーマンスが向上します。 +- インデックスが[グローバルインデックス](/global-indexes.md)かどうか。パーティションテーブルでは、グローバルインデックスにより、通常のインデックスと比較して SQL の cop タスクの数が効果的に削減され、全体的なパフォーマンスが向上します。 上記次元において、インデックス`idx_a`が 3 つの次元すべてにおいてインデックス`idx_b`と同等以上のパフォーマンスを発揮し、かつ 1 つの次元において`idx_b`よりも優れたパフォーマンスを発揮する場合、 `idx_a`が優先されます。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、スカイラインプルーニングによって一部のインデックスが除外された場合、TiDB は、スカイラインプルーニングによる除外後に残ったインデックスを一覧表示する NOTE レベルの警告を出力します。 @@ -145,7 +145,7 @@ mysql> SHOW WARNINGS; ## 多値インデックスを使用する {#use-multi-valued-indexes} -[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)は通常のインデックスとは異なります。 TiDB は現在、多値インデックスにアクセスするために[インデックスマージ](/explain-index-merge.md)のみを使用します。したがって、データ アクセスに多値インデックスを使用するには、システム変数[`tidb_enable_index_merge`](/system-variables.md#tidb_enable_index_merge-new-in-v40)の値が`ON`に設定されていることを確認してください。 +[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)は通常のインデックスとは異なります。 TiDB は現在、多値インデックスにアクセスするために[インデックスマージ](/explain-index-merge.md)のみを使用します。したがって、データアクセスに多値インデックスを使用するには、システム変数[`tidb_enable_index_merge`](/system-variables.md#tidb_enable_index_merge-new-in-v40)の値が`ON`に設定されていることを確認してください。 多値インデックスの制限事項については、 [`CREATE INDEX`](/sql-statements/sql-statement-create-index.md#limitations)を参照してください。 diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index 9adec6a2d457b..d7600fac5d160 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -72,7 +72,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの | ログ | `ticdc.log` | `--include=log` | | エラーログ | `ticdc_stderr.log` | `--include=log` | | コンフィグレーションファイル | `ticdc.toml` | `--include=config` | -| デバッグデータ | `info.txt` `status.txt` `changefeeds.txt` `captures.txt` `processors.txt` | `--include=debug` (Diag はデフォルトではこのデータ タイプを収集しません) | +| デバッグデータ | `info.txt` `status.txt` `changefeeds.txt` `captures.txt` `processors.txt` | `--include=debug` (Diag はデフォルトではこのデータタイプを収集しません) | ### Prometheus監視データ {#prometheus-monitoring-data} @@ -85,8 +85,8 @@ PingCAP Clinicによって収集された診断データは、クラスターの | データ型 | エクスポートされたファイル | PingCAP Clinicによるデータ収集パラメータ | | :---------- | :--------------------- | :----------------------------------------------------------------------------------------- | -| TiDB システム変数 | `mysql.tidb.csv` | `--include=db_vars` (Diag はデフォルトではこのデータ タイプを収集しません。このデータ タイプを収集する必要がある場合は、データベース資格情報が必要です) | -| | `global_variables.csv` | `--include=db_vars` (Diag はデフォルトではこのデータ タイプを収集しません) | +| TiDB システム変数 | `mysql.tidb.csv` | `--include=db_vars` (Diag はデフォルトではこのデータタイプを収集しません。このデータタイプを収集する必要がある場合は、データベース資格情報が必要です) | +| | `global_variables.csv` | `--include=db_vars` (Diag はデフォルトではこのデータタイプを収集しません) | ### クラスタノードのシステム情報 {#system-information-of-the-cluster-node} @@ -149,6 +149,6 @@ PingCAP Clinicによって収集された診断データは、クラスターの ログの種類: - `std` : ファイル名に`stderr`含まれるログファイル。 -- `rocksdb` : プレフィックスが`rocksdb` 、サフィックスが`.info`ログ ファイル。 -- `slow` : クエリ ログ ファイルが遅い。 -- `unknown` : 上記のいずれの種類にも一致しないログ ファイル。 +- `rocksdb` : プレフィックスが`rocksdb` 、サフィックスが`.info`ログファイル。 +- `slow` : クエリログファイルが遅い。 +- `unknown` : 上記のいずれの種類にも一致しないログファイル。 diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index 23ef15c448ae0..60810d9225019 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -42,11 +42,11 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 - SCP 経由でサーバーファイルを転送する - TiUPを使用して展開されたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログ ファイルと構成ファイルを直接収集できます。 + TiUPを使用して展開されたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログファイルと構成ファイルを直接収集できます。 - SSH経由でリモートコマンドを実行してデータを収集する - TiUPを使用して展開されたクラスターの場合、Diag は SSH ( セキュリティ Shell) を介してターゲットコンポーネントシステムに接続し、コマンド (Insight など) を実行して、カーネル ログ、カーネル パラメーター、システムとハードウェアの基本情報などのシステム情報を取得できます。 + TiUPを使用して展開されたクラスターの場合、Diag は SSH ( セキュリティ Shell) を介してターゲットコンポーネントシステムに接続し、コマンド (Insight など) を実行して、カーネル ログ、カーネルパラメーター、システムとハードウェアの基本情報などのシステム情報を取得できます。 - HTTP呼び出しを通じてデータを収集する diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index c8b4c16044465..ccbf4af3dbff3 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} @@ -17,7 +17,7 @@ TiUPを使用して導入された TiDB クラスターおよび DM クラスタ - [クラスタの問題をリモートでトラブルシューティングする](#troubleshoot-cluster-problems-remotely) - - クラスターに問題がある場合、PingCAP から[サポートを受ける](/support.md)必要があります。リモート トラブルシューティングを容易にするために、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードし、データ アクセス リンクをテクニカル サポート スタッフに提供するための次の操作を実行できます。 + - クラスターに問題がある場合、PingCAP から[サポートを受ける](/support.md)必要があります。リモート トラブルシューティングを容易にするために、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードし、データアクセス リンクをテクニカルサポート スタッフに提供するための次の操作を実行できます。 - クラスターに何らかの問題があり、すぐに問題を分析できない場合は、Diag を使用してデータを収集し、後で分析できるように保存することができます。 - [ローカルでクラスタのステータスをクイックチェックする](#perform-a-quick-check-on-the-cluster-status-locally) @@ -30,7 +30,7 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ 1. Diag をインストールします。 - - コントロール マシンにTiUPがインストールされている場合は、次のコマンドを実行して Diag をインストールします。 + - コントロールマシンにTiUPがインストールされている場合は、次のコマンドを実行して Diag をインストールします。 ```bash tiup install diag @@ -47,7 +47,7 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ > - インターネット接続のないクラスタでは、Diagをオフラインで展開する必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 > - Diag は、TiDB Server オフライン ミラー パッケージ v5.4.0 以降で**のみ**提供されます。 -2. データをアップロードするためのアクセス トークン (トークン) を取得して設定します。 +2. データをアップロードするためのアクセストークン (トークン) を取得して設定します。 Diag を通じて収集したデータをアップロードする際、ユーザー認証用のトークンが必要です。既にトークン Diag を設定している場合は、そのトークンを再利用してこの手順を省略できます。 @@ -280,7 +280,7 @@ tiup diag upload Download URL: "https://clinic.pingcap.com.cn/portal/#/orgs/4/clusters/XXXX" ``` -3. アップロードが完了したら、 `Download URL`のリンクを開いてアップロードされたデータを確認するか、以前に連絡した PingCAP テクニカル サポート スタッフにリンクを送信することができます。 +3. アップロードが完了したら、 `Download URL`のリンクを開いてアップロードされたデータを確認するか、以前に連絡した PingCAP テクニカルサポート スタッフにリンクを送信することができます。 ## ローカルでクラスタのステータスをクイックチェックする {#perform-a-quick-check-on-the-cluster-status-locally} diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index 8006415bbe41c..db8f308dfbaca 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -11,7 +11,7 @@ PingCAP Clinicは、 [Diagクライアント](https://github.com/pingcap/diag) ## ユーザーシナリオ {#user-scenarios} -- PingCAP テクニカル サポートからリモートで支援を受ける際にクラスターの問題を正確に特定し、迅速に解決するには、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードして、データ アクセス リンクをテクニカル サポートに提供することができます。 +- PingCAP テクニカルサポートからリモートで支援を受ける際にクラスターの問題を正確に特定し、迅速に解決するには、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードして、データアクセス リンクをテクニカルサポートに提供することができます。 - クラスターが正常に実行されており、クラスターのステータスを確認する必要がある場合は、Diag を使用して診断データを収集し、そのデータを Clinic Server にアップロードして、Health Report の結果を表示できます。 > **Note:** @@ -23,7 +23,7 @@ PingCAP Clinicは、 [Diagクライアント](https://github.com/pingcap/diag) PingCAP Clinicを使用する前に、Diag をインストールし、データをアップロードするための環境を準備する必要があります。 -1. TiUPがインストールされているコントロール マシンで、次のコマンドを実行して Diag をインストールします。 +1. TiUPがインストールされているコントロールマシンで、次のコマンドを実行して Diag をインストールします。 ```bash tiup install diag @@ -135,11 +135,11 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ - クラスターが設置されているネットワークがインターネットにアクセスできない場合は、収集したデータをパックしてアップロードする必要があります。詳細は[方法2. データをパックしてアップロードする](/clinic/clinic-user-guide-for-tiup.md#method-2-pack-and-upload-data)ご覧ください。 -3. アップロードが完了したら、コマンド出力の`Download URL`からデータ アクセス リンクを取得します。 +3. アップロードが完了したら、コマンド出力の`Download URL`からデータアクセス リンクを取得します。 デフォルトでは、診断データには、クラスター名、クラスター トポロジ情報、収集された診断データ内のログ コンテンツ、収集されたデータ内のメトリックに基づいて再構成された Grafana ダッシュボード情報が含まれます。 - データを使用してクラスターの問題を自分でトラブルシューティングすることも、PingCAP テクニカル サポート スタッフにデータ アクセス リンクを提供してリモート トラブルシューティングを容易にすることもできます。 + データを使用してクラスターの問題を自分でトラブルシューティングすることも、PingCAP テクニカルサポート スタッフにデータアクセス リンクを提供してリモート トラブルシューティングを容易にすることもできます。 4. ヘルスレポートの結果を表示する diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md index 387e62e9700be..cb5e69cb1facc 100644 --- a/command-line-flags-for-scheduling-configuration.md +++ b/command-line-flags-for-scheduling-configuration.md @@ -1,6 +1,6 @@ --- title: Scheduling Configuration Flags -summary: スケジュール構成フラグは、コマンド ライン フラグまたは環境変数を介して構成できます。 +summary: スケジュール構成フラグは、コマンドラインフラグまたは環境変数を介して構成できます。 --- # スケジュールコンフィグレーションフラグ {#scheduling-configuration-flags} @@ -21,7 +21,7 @@ summary: スケジュール構成フラグは、コマンド ライン フラグ ## `--cacert` {#cacert} -- TLS を有効にするために使用される CA のファイル パス。 +- TLS を有効にするために使用される CA のファイルパス。 - デフォルト: `""` ## `--cert` {#cert} @@ -37,7 +37,7 @@ summary: スケジュール構成フラグは、コマンド ライン フラグ ## `--data-dir` {#data-dir} -- スケジューリング ノード上のデータ ディレクトリへのパス。 +- スケジューリング ノード上のデータディレクトリへのパス。 - デフォルト: `"default.${name}"` ## `--key` {#key} @@ -53,7 +53,7 @@ summary: スケジュール構成フラグは、コマンド ライン フラグ ## `--log-file` {#log-file} -- ログ ファイル。 +- ログファイル。 - デフォルト: `""` - このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 @@ -65,7 +65,7 @@ summary: スケジュール構成フラグは、コマンド ライン フラグ ## `-L` {#l} -- ログ レベル。 +- ログレベル。 - デフォルト: `"info"` - `"warn"` `"fatal"` `"error"` `"debug"` `"info"` diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index ee8e300b383f3..b55e32fdb06af 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -220,7 +220,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--redact` {#--redact} -- サブコマンド`collect-log`を使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 +- サブコマンド`collect-log`を使用するときに、 TiDBサーバーがログファイルを非感度化するかどうかを決定します。 - デフォルト: false - 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `を実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)を参照してください。 diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md index ff28a8036b451..5f40cc51ab3f0 100644 --- a/command-line-flags-for-tso-configuration.md +++ b/command-line-flags-for-tso-configuration.md @@ -1,6 +1,6 @@ --- title: TSO Configuration Flags -summary: TSO 構成フラグは、コマンド ライン フラグまたは環境変数を介して構成できます。 +summary: TSO 構成フラグは、コマンドラインフラグまたは環境変数を介して構成できます。 --- # TSOコンフィグレーションフラグ {#tso-configuration-flags} @@ -21,7 +21,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## `--cacert` {#cacert} -- TLS を有効にするために使用される CA のファイル パス。 +- TLS を有効にするために使用される CA のファイルパス。 - デフォルト: `""` ## `--cert` {#cert} @@ -37,7 +37,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## `--data-dir` {#data-dir} -- TSO ノード上のデータ ディレクトリへのパス。 +- TSO ノード上のデータディレクトリへのパス。 - デフォルト: `"default.${name}"` ## `--key` {#key} @@ -53,7 +53,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## `--log-file` {#log-file} -- ログ ファイル。 +- ログファイル。 - デフォルト: `""` - このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 @@ -65,7 +65,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## `-L` {#l} -- ログ レベル。 +- ログレベル。 - デフォルト: `"info"` - `"warn"` `"fatal"` `"error"` `"debug"` `"info"` diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 053775a6cadcf..74ed64306f9b9 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -58,15 +58,15 @@ tidb-server インスタンスのメモリ使用量が総メモリの一定割 > > ハイブリッド展開シナリオでは、物理マシン全体の合計メモリしきい値ではなく、単一の tidb-server インスタンスのメモリ使用量しきい値は`tidb_server_memory_limit`になります。 -## INFORMATION_SCHEMA システム テーブルを使用して、現在の tidb-server インスタンスのメモリ使用量を表示する {#view-the-memory-usage-of-the-current-tidb-server-instance-using-the-information_schema-system-table} +## INFORMATION_SCHEMA システムテーブルを使用して、現在の tidb-server インスタンスのメモリ使用量を表示する {#view-the-memory-usage-of-the-current-tidb-server-instance-using-the-information_schema-system-table} -現在のインスタンスまたはクラスターのメモリ使用量を表示するには、システム テーブル[`INFORMATION_SCHEMA.(CLUSTER_)MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md)をクエリします。 +現在のインスタンスまたはクラスターのメモリ使用量を表示するには、システムテーブル[`INFORMATION_SCHEMA.(CLUSTER_)MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md)をクエリします。 現在のインスタンスまたはクラスターのメモリ関連の操作と実行基準を確認するには、システムテーブル[`INFORMATION_SCHEMA.(CLUSTER_)MEMORY_USAGE_OPS_HISTORY`](/information-schema/information-schema-memory-usage-ops-history.md)をクエリします。このテーブルには、インスタンスごとに最新の50件のレコードが保持されます。 ## 過剰なメモリ使用量のアラームをトリガーする {#trigger-the-alarm-of-excessive-memory-usage} -tidb-server インスタンスのメモリ使用量がメモリしきい値 (デフォルトでは合計メモリの 70%) を超え、次のいずれかの条件が満たされると、TiDB は関連するステータス ファイルを記録し、アラーム ログを出力。 +tidb-server インスタンスのメモリ使用量がメモリしきい値 (デフォルトでは合計メモリの 70%) を超え、次のいずれかの条件が満たされると、TiDB は関連するステータスファイルを記録し、アラーム ログを出力。 - メモリ使用量がメモリしきい値を超えるのは初めてです。 - メモリ使用量がメモリしきい値を超えており、前回のアラームから 60 秒以上経過しています。 @@ -76,7 +76,7 @@ tidb-server インスタンスのメモリ使用量がメモリしきい値 (デ 過剰なメモリ使用量のアラームがトリガーされると、TiDB は次のアクションを実行します。 -- TiDB は、TiDB ログ ファイル[`filename`](/tidb-configuration-file.md#filename)が配置されているディレクトリに次の情報を記録します。 +- TiDB は、TiDB ログファイル[`filename`](/tidb-configuration-file.md#filename)が配置されているディレクトリに次の情報を記録します。 - 現在実行中のすべてのSQL文の中で、メモリ使用量が最も多い上位10個のSQL文と実行時間が最も長い上位10個のSQL文に関する情報 - ゴルーチンスタック情報 @@ -104,20 +104,20 @@ tidb-server インスタンスのメモリ使用量がメモリしきい値 (デ 3. `select * from t t1 join t t2 join t t3 order by t1.a`を実行します。この SQL 文は 10 億件のレコードを出力し、大量のメモリを消費するため、アラームがトリガーされます。 -4. システムメモリの合計、現在のシステムメモリ使用量、tidb-server インスタンスのメモリ使用量、およびステータス ファイルのディレクトリを記録する`tidb.log`ファイルを確認します。 +4. システムメモリの合計、現在のシステムメモリ使用量、tidb-server インスタンスのメモリ使用量、およびステータスファイルのディレクトリを記録する`tidb.log`ファイルを確認します。 ``` [2022/10/11 16:39:02.281 +08:00] [WARN] [memoryusagealarm.go:212] ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"] ["is tidb_server_memory_limit set"=false] ["system memory total"=33682427904] ["system memory usage"=22120655360] ["tidb-server memory usage"=21468556992] [memory-usage-alarm-ratio=0.85] ["record path"=/tiup/deploy/tidb-4000/log/oom_record] ``` - 上記のサンプル ログ ファイルのフィールドは次のように説明されています。 + 上記のサンプル ログファイルのフィールドは次のように説明されています。 - `is tidb_server_memory_limit set`は [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)が設定されているかどうかを示します。 - `system memory total`は現在のシステムの合計メモリを示します。 - `system memory usage`は現在のシステムメモリ使用量を示します。 - `tidb-server memory usage`は、tidb-server インスタンスのメモリ使用量を示します。 - `memory-usage-alarm-ratio`はシステム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)の値を示します。 - - `record path`はステータス ファイルのディレクトリを示します。 + - `record path`はステータスファイルのディレクトリを示します。 5. ステータスファイルのディレクトリ（上記の例ではディレクトリ`/tiup/deploy/tidb-4000/log/oom_record` ）を確認すると、対応するタイムスタンプ（例： `record2022-10-09T17:18:38+08:00` ）を持つレコードディレクトリが表示されます。レコードディレクトリには、 `goroutinue` 、 `heap` 、 `running_sql`の3つのファイルが含まれています。これらの3つのファイルには、ステータスファイルが記録された時刻が末尾に付加されます。これらのファイルには、それぞれ、ゴルーチンのスタック情報、ヒープメモリの使用状況、アラーム発生時の実行SQL情報が記録されています。 `running_sql`の内容については、 [`expensive-queries`](/identify-expensive-queries.md)を参照してください。 @@ -140,16 +140,16 @@ TiDBが使用するトランザクションモデルでは、トランザクシ TiDBは、実行演算子のディスクへの書き込みをサポートしています。SQL実行のメモリ使用量がメモリクォータを超えた場合、tidb-serverは実行演算子の中間データをディスクに書き出すことで、メモリ負荷を軽減します。ディスクへの書き込みをサポートする演算子には、Sort、MergeJoin、HashJoin、HashAggなどがあります。 - ディスクスピル動作は、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) 、 [`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path) 、および[`tmp-storage-quota`](/tidb-configuration-file.md#tmp-storage-quota)パラメータによって共同で制御されます。 -- ディスク スピルがトリガーされると、TiDB はキーワード`memory exceeds quota, spill to disk now`または`memory exceeds quota, set aggregate mode to spill-mode`を含むログを出力します。 +- ディスクスピルがトリガーされると、TiDB はキーワード`memory exceeds quota, spill to disk now`または`memory exceeds quota, set aggregate mode to spill-mode`を含むログを出力します。 - Sort、MergeJoin、およびHashJoin演算子のディスクスピルはv4.0.0で導入されました。HashAgg演算子の非並列アルゴリズムのディスクスピルはv5.2.0で導入されました。HashAgg演算子の並列アルゴリズムのディスクスピルはv8.0.0で実験的機能として導入され、v8.2.0で一般提供（GA）されました。TopN演算子のディスクスピルはv8.3.0で導入されました。 - [`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)システム変数を使用して、ディスクスピルをサポートする並列HashAggアルゴリズムを有効にするかどうかを制御できます。この変数は将来のリリースで廃止される予定です。 -- Sort、MergeJoin、HashJoin、HashAgg、または TopN を含む SQL 実行によって OOM が発生すると、TiDB はデフォルトでディスク スピルをトリガーします。 +- Sort、MergeJoin、HashJoin、HashAgg、または TopN を含む SQL 実行によって OOM が発生すると、TiDB はデフォルトでディスクスピルをトリガーします。 > **Note:** > > HashAgg のディスクスピルは、 `DISTINCT`集計関数を含む SQL 実行をサポートしていません。`DISTINCT`集計関数を含む SQL 実行でメモリ使用量が多すぎる場合、ディスクスピルは適用されません。 -次の例では、メモリを消費する SQL ステートメントを使用して、HashAgg のディスク スピル機能を示します。 +次の例では、メモリを消費する SQL ステートメントを使用して、HashAgg のディスクスピル機能を示します。 1. SQL ステートメントのメモリクォータを 1 GB (デフォルトは 1 GB) に設定します。 @@ -165,7 +165,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして [tidb]> explain analyze select /*+ HASH_AGG() */ count(*) from t t1 join t t2 join t t3 group by t1.a, t2.a, t3.a; ``` - この SQL ステートメントを実行するとメモリが大量に消費されるため、次の「メモリ クォータ不足」エラー メッセージが返されます。 + この SQL ステートメントを実行するとメモリが大量に消費されるため、次の「メモリクォータ不足」エラーメッセージが返されます。 ```sql ERROR 1105 (HY000): Out Of Memory Quota![conn_id=3] diff --git a/configure-time-zone.md b/configure-time-zone.md index a9e311714ec98..74cad8ae46ad1 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -8,7 +8,7 @@ summary: TiDBのタイムゾーン設定は、`time_zone`システム変数に TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables.md#time_zone)によって決定されます。セッションレベルまたはグローバルレベルで設定できます。`time_zone`のデフォルト値は`SYSTEM`です。`SYSTEM`に対応する実際のタイムゾーンは、TiDBクラスタのブートストラップが初期化される際に設定されます。詳細なロジックは次のとおりです。 1. TiDB は`TZ`環境変数の使用を優先します。 -2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイム ゾーンを読み取ります。 +2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイムゾーンを読み取ります。 3. 上記の両方の方法が失敗した場合、TiDB はシステムタイムゾーンとして`UTC`を使用します。 ## タイムゾーン設定を表示する {#view-time-zone-settings} @@ -23,25 +23,25 @@ SELECT @@global.time_zone, @@session.time_zone, @@global.system_time_zone; TiDB では、 `time_zone`システム変数の値は次のいずれかの形式で設定できます。 -- `SYSTEM` (デフォルト値) は、タイム ゾーンがシステムのタイム ゾーンと同じであることを示します。 +- `SYSTEM` (デフォルト値) は、タイムゾーンがシステムのタイムゾーンと同じであることを示します。 - UTC オフセット（`'+10:00'`または`'-6:00'`など）。 - `'Europe/Helsinki'` 、 `'US/Eastern'` 、 `'MET'`などの名前付きタイムゾーン。 -ニーズに応じて、次のように TiDB のタイムゾーンをグローバル レベルまたはセッション レベルで設定できます。 +ニーズに応じて、次のように TiDB のタイムゾーンをグローバルレベルまたはセッションレベルで設定できます。 -- TiDB のタイムゾーンをグローバル レベルで設定します。 +- TiDB のタイムゾーンをグローバルレベルで設定します。 ```sql SET GLOBAL time_zone = ${time-zone-value}; ``` - たとえば、グローバル タイム ゾーンを UTC に設定します。 + たとえば、グローバル タイムゾーンを UTC に設定します。 ```sql SET GLOBAL time_zone = 'UTC'; ``` -- セッション レベルで TiDB のタイム ゾーンを設定します。 +- セッションレベルで TiDB のタイムゾーンを設定します。 ```sql SET time_zone = ${time-zone-value}; @@ -111,7 +111,7 @@ select * from t; ## タイムゾーン設定に関する重要な考慮事項 {#important-considerations-for-time-zone-settings} - `TIMESTAMP`と`DATETIME`値の変換中にはタイムゾーンが関係し、現在のセッションの`time_zone`に基づいて処理されます。 -- データ移行では、プライマリ データベースとセカンダリ データベースのタイム ゾーン設定が一致しているかどうかに特に注意する必要があります。 +- データ移行では、プライマリ データベースとセカンダリ データベースのタイムゾーン設定が一致しているかどうかに特に注意する必要があります。 - 正確なタイムスタンプを取得するには、ネットワークタイムプロトコル（NTP）または高精度時間プロトコル（PTP）サービスを使用して信頼性の高いクロックを設定することを強くお勧めします。NTPサービスの確認方法については、 [NTPサービスを確認してインストールする](/check-before-deployment.md#check-and-install-the-ntp-service)を参照してください。 - 夏時間を採用しているタイムゾーンを使用すると、特にそれらのタイムスタンプを使用して計算を実行するときに、タイムスタンプがあいまいになったり、タイムスタンプが存在しなくなったりする可能性があることに注意してください。 - MySQLは[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.4/en/mysql-tzinfo-to-sql.html)を使用して、オペレーティングシステムのタイムゾーンデータベースを`mysql`データベースのテーブルに変換します。一方、TiDBはオペレーティングシステムのタイムゾーンデータベースからタイムゾーンデータファイルを直接読み取り、Goプログラミング言語に組み込まれたタイムゾーン処理機能を活用します。 diff --git a/constraints.md b/constraints.md index 32b2285a76128..53ab31358851d 100644 --- a/constraints.md +++ b/constraints.md @@ -143,7 +143,7 @@ ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; ### 楽観的トランザクション {#optimistic-transactions} -デフォルトでは、楽観的トランザクションの場合、TiDB は実行フェーズで一意制約[怠惰に](/transaction-overview.md#lazy-check-of-constraints)チェックし、コミット フェーズで厳密にチェックします。これにより、ネットワーク オーバーヘッドが削減され、パフォーマンスが向上します。 +デフォルトでは、楽観的トランザクションの場合、TiDB は実行フェーズで一意制約[怠惰に](/transaction-overview.md#lazy-check-of-constraints)チェックし、コミットフェーズで厳密にチェックします。これにより、ネットワーク オーバーヘッドが削減され、パフォーマンスが向上します。 例えば： diff --git a/correlated-subquery-optimization.md b/correlated-subquery-optimization.md index 41701d8336417..926cdfcc6aec0 100644 --- a/correlated-subquery-optimization.md +++ b/correlated-subquery-optimization.md @@ -48,7 +48,7 @@ explain select * from t1 where t1.a < (select sum(t2.a) from t2 where t2.b = t1. 上記は最適化が効いた例です。 `HashJoin_11`通常の`inner join`です。 -次に、 `NO_DECORRELATE`オプティマイザ ヒントを使用して、サブクエリの非相関化を実行しないようにオプティマイザに指示できます。 +次に、 `NO_DECORRELATE`オプティマイザヒントを使用して、サブクエリの非相関化を実行しないようにオプティマイザに指示できます。 ```sql explain select * from t1 where t1.a < (select /*+ NO_DECORRELATE() */ sum(t2.a) from t2 where t2.b = t1.b); diff --git a/cost-model.md b/cost-model.md index cd357b8e459ec..c6627ef9897ee 100644 --- a/cost-model.md +++ b/cost-model.md @@ -1,6 +1,6 @@ --- title: Cost Model -summary: 物理的な最適化中に TiDB によって使用されるコスト モデルがどのように機能するかを学習します。 +summary: 物理的な最適化中に TiDB によって使用されるコストモデルがどのように機能するかを学習します。 --- # コストモデル {#cost-model} @@ -40,12 +40,12 @@ mysql> SHOW CREATE TABLE t; ## コストモデル バージョン 2 {#cost-model-version-2} -TiDB v6.2.0 では、新しいコスト モデルであるコスト モデル バージョン 2 が導入されています。 +TiDB v6.2.0 では、新しいコストモデルであるコストモデル バージョン 2 が導入されています。 -コスト モデル バージョン 2 では、コスト式のより正確な回帰キャリブレーションが提供され、コスト式の一部が調整され、以前のバージョンのコスト式よりも正確になっています。 +コストモデル バージョン 2 では、コスト式のより正確な回帰キャリブレーションが提供され、コスト式の一部が調整され、以前のバージョンのコスト式よりも正確になっています。 コストモデルのバージョンを切り替えるには、 [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定します。 > **Note:** > -> コスト モデルのバージョンを切り替えると、クエリ プランが変更される可能性があります。 +> コストモデルのバージョンを切り替えると、クエリプランが変更される可能性があります。 diff --git a/dashboard/continuous-profiling.md b/dashboard/continuous-profiling.md index 21a1573777bd6..6f0542eb8d6c1 100644 --- a/dashboard/continuous-profiling.md +++ b/dashboard/continuous-profiling.md @@ -17,14 +17,14 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 継続的プロファイリングは[手動プロファイリング](/dashboard/dashboard-profiling.md)の拡張機能です。どちらも、各インスタンスの異なる種類のパフォーマンスデータを収集・分析するために使用できます。両者の違いは次のとおりです。 -- 手動プロファイリングでは、プロファイリングを開始した瞬間に短期間 (たとえば 30 秒) のみパフォーマンス データが収集されますが、継続プロファイリングが有効になっている場合は、継続的にデータが収集されます。 +- 手動プロファイリングでは、プロファイリングを開始した瞬間に短期間 (たとえば 30 秒) のみパフォーマンスデータが収集されますが、継続プロファイリングが有効になっている場合は、継続的にデータが収集されます。 - 手動プロファイリングは現在発生している問題を分析するためにのみ使用できますが、継続的プロファイリングは現在の問題と履歴の問題の両方を分析するために使用できます。 -- 手動プロファイリングでは特定のインスタンスの特定のパフォーマンス データを収集できますが、継続的プロファイリングではすべてのインスタンスのすべてのパフォーマンス データを収集します。 -- 継続的なプロファイリングでは、より多くのパフォーマンス データが保存されるため、より多くのディスク領域が使用されます。 +- 手動プロファイリングでは特定のインスタンスの特定のパフォーマンスデータを収集できますが、継続的プロファイリングではすべてのインスタンスのすべてのパフォーマンスデータを収集します。 +- 継続的なプロファイリングでは、より多くのパフォーマンスデータが保存されるため、より多くのディスク領域が使用されます。 ## サポートされているパフォーマンスデータ {#supported-performance-data} -[手動プロファイリング](/dashboard/dashboard-profiling.md#supported-performance-data)内のすべてのパフォーマンス データが収集されます。 +[手動プロファイリング](/dashboard/dashboard-profiling.md#supported-performance-data)内のすべてのパフォーマンスデータが収集されます。 - CPU: TiDB、TiKV、 TiFlash、PDインスタンスの各内部関数のCPUオーバーヘッド @@ -66,7 +66,7 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 ## 過去のパフォーマンスデータを表示する {#view-historical-performance-data} -リスト ページでは、この機能を有効にしてから収集されたすべてのパフォーマンス データを確認できます。 +リスト ページでは、この機能を有効にしてから収集されたすべてのパフォーマンスデータを確認できます。 ![History results](/media/dashboard/dashboard-conprof-history.png) diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index 09a499a3d0391..0ec5c82e32d25 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -55,7 +55,7 @@ TiDB Dashboardでは次の言語がサポートされています。 - 英語 - 中国語（簡体字） -**SQL ユーザー サインイン**ページで、**言語の切り替え**ドロップダウン リストをクリックしてインターフェイス言語を切り替えることができます。 +**SQL ユーザー サインイン**ページで、**言語の切り替え**ドロップダウンリストをクリックしてインターフェイス言語を切り替えることができます。 ![Switch language](/media/dashboard/dashboard-access-switch-language.png) diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index c3a436f7d4810..5f20b1316efad 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -29,8 +29,8 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 - ステータス: インスタンスの実行ステータス。 - 稼働時間: インスタンスの開始時刻。 - バージョン: インスタンスのバージョン番号。 -- Git ハッシュ: インスタンス バイナリ ファイルに対応する Git ハッシュ値。 -- デプロイメント ディレクトリ: インスタンス バイナリ ファイルが配置されているディレクトリ。 +- Git ハッシュ: インスタンス バイナリファイルに対応する Git ハッシュ値。 +- デプロイメントディレクトリ: インスタンス バイナリファイルが配置されているディレクトリ。 ### インスタンスのステータス {#instance-status} @@ -81,7 +81,7 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 - ホスト アドレス: ホスト IP アドレス。 - マウント ディレクトリ: インスタンスが実行されているホスト上のこのディスクのマウント パス。 -- ファイル システム: インスタンスが実行されているホスト上のこのディスクのファイル システム タイプ。 +- ファイルシステム: インスタンスが実行されているホスト上のこのディスクのファイルシステム タイプ。 - ディスク容量: インスタンスが実行されているホスト上のディスクの合計容量。 - ディスク使用量: インスタンスが実行されているホスト上のディスクのスペース使用量。 - インスタンス: このホスト上で実行されているインスタンス。 diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index 4c4597e47b462..8b004ba839fb3 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -281,7 +281,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり - `Coprocessor Info` : TiKV 内のコプロセッサーモジュールに関連する監視情報。 - `Raft Info` : TiKV 内のRaftモジュールの監視情報。 - `Snapshot Info` : TiKV 内のスナップショット関連の監視情報。 -- `GC Info` : TiKV 内のガベージ コレクション (GC) 関連の監視情報。 +- `GC Info` : TiKV 内のガベージコレクション (GC) 関連の監視情報。 - `Cache Hit` : TiKV 内の RocksDB の各キャッシュのヒット率情報。 ### コンフィグレーション情報 {#configuration-information} diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 2848aafc4a7d1..fac44e46ade12 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -14,7 +14,7 @@ summary: このドキュメントは、TiDB Dashboardに関するよくある質 クラスター内に複数のPlacement Driver（PD）インスタンスがデプロイされている場合、TiDB Dashboardサービスを実際に実行するPDインスタンスは1つだけです。このPDインスタンスではなく他のPDインスタンスにアクセスすると、ブラウザは別のアドレスにリダイレクトします。TiDB Dashboardへのアクセス用にファイアウォールまたはリバースプロキシが適切に設定されていない場合、ダッシュボードにアクセスした際に、ファイアウォールまたはリバースプロキシによって保護されている内部アドレスにリダイレクトされる可能性があります。 - 複数の PD インスタンスを使用した TiDB Dashboardの動作原理については、 [TiDB Dashboardのマルチ PD インスタンスの展開](/dashboard/dashboard-ops-deploy.md)を参照してください。 -- リバース プロキシを正しく構成する方法については、 [リバースプロキシ経由でTiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 +- リバースプロキシを正しく構成する方法については、 [リバースプロキシ経由でTiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 - ファイアウォールを正しく構成する方法については、 [TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 ### TiDB Dashboardがデュアルネットワークインターフェースカード（NIC）で展開されている場合、別のNICを使用してTiDB Dashboardにアクセスすることはできません。 {#when-tidb-dashboard-is-deployed-with-dual-network-interface-cards-nics-tidb-dashboard-cannot-be-accessed-using-another-nic} @@ -106,7 +106,7 @@ Web ページに`required component NgMonitoring is not started`が表示され tiup cluster reload ${cluster-name} --role prometheus ``` -上記の手順を実行した後もエラー メッセージが表示される場合は、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 +上記の手順を実行した後もエラーメッセージが表示される場合は、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index b47827e6b96f3..20ccdc489f00a 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -55,13 +55,13 @@ TiDB Dashboardの診断機能は、クラスター内に一般的なリスク ( ## すべてのコンポーネントのクエリログ {#query-logs-of-all-components} -TiDB Dashboardの [ログの検索] ページでは、クラスター内で実行中のすべてのインスタンスのログをキーワード、時間範囲、その他の条件ですばやく検索し、これらのログをパッケージ化してローカル マシンにダウンロードできます。 +TiDB Dashboardの [ログの検索] ページでは、クラスター内で実行中のすべてのインスタンスのログをキーワード、時間範囲、その他の条件ですばやく検索し、これらのログをパッケージ化してローカルマシンにダウンロードできます。 詳細は[検索ログページ](/dashboard/dashboard-log-search.md)参照。 ## リソース制御のためのクラスター容量の見積もり {#estimate-cluster-capacity-for-resource-control} -[リソース管理](/tidb-resource-control-ru-groups.md)機能を使用してリソース分離を実装するには、クラスター管理者がリソース グループを作成し、各グループにクォータを設定できます。 +[リソース管理](/tidb-resource-control-ru-groups.md)機能を使用してリソース分離を実装するには、クラスター管理者がリソースグループを作成し、各グループにクォータを設定できます。 リソース計画を立てる前に、クラスター全体の容量を把握しておく必要があります。詳細については、 [リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)を参照してください。 diff --git a/dashboard/dashboard-log-search.md b/dashboard/dashboard-log-search.md index d8143965e0a17..04529193be3b9 100644 --- a/dashboard/dashboard-log-search.md +++ b/dashboard/dashboard-log-search.md @@ -34,7 +34,7 @@ TiDB Dashboardにログインした後、 **ログの検索**をクリックし - 進行状況 (上記画像の領域 2): ログ検索ステータスや各ノードの統計情報など、現在の検索進行状況がこのページの右側に表示されます。 - 検索結果（上記画像の領域3）: - 時間: ログが生成された時刻。タイムゾーンはフロントエンドユーザーのタイムゾーンと同じです。 - - レベル: ログ レベル。 + - レベル: ログレベル。 - コンポーネント:コンポーネント名とアドレスを表示します。 - ログ: 各ログレコードの本文部分（ログ時間とログレベルを除く）。ログが長すぎる場合は自動的に切り捨てられます。行をクリックすると、全内容が表示されます。ログ全体は最大512文字まで表示できます。 diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index 76a83e28c72e6..5b564ccecbf4b 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -64,7 +64,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### プランキャッシュOPSを使用したクエリ {#queries-using-plan-cache-ops} -すべての TiDB インスタンスにおける 1 秒あたりのプラン キャッシュを使用するクエリの数 +すべての TiDB インスタンスにおける 1 秒あたりのプランキャッシュを使用するクエリの数 ### KV/TSO リクエスト OPS {#kv-tso-request-ops} diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 15b3066d68595..d729a3952092e 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -51,7 +51,7 @@ http://192.168.0.123:2379/dashboard/ > **Note:** > -> この機能は、 `tiup cluster`デプロイメント ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 +> この機能は、 `tiup cluster`デプロイメントツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 > >
TiUPクラスタのアップグレード > @@ -83,7 +83,7 @@ tiup cluster display CLUSTER_NAME --dashboard > **Warning:** > -> TiDB Dashboard を実行するインスタンスを変更すると、Key Visualize 履歴や検索履歴など、以前の TiDB Dashboard インスタンスに保存されたローカル データが失われます。 +> TiDB Dashboard を実行するインスタンスを変更すると、Key Visualize 履歴や検索履歴など、以前の TiDB Dashboard インスタンスに保存されたローカルデータが失われます。 ## TiDB Dashboardを無効にする {#disable-tidb-dashboard} @@ -123,7 +123,7 @@ TiDB Dashboardを提供するPDインスタンスを手動で指定すること > **Warning:** > -> 新しく有効になった TiDB Dashboard インスタンスが、TiDB Dashboardを提供していた以前のインスタンスと異なる場合、Key Visualize 履歴や検索履歴など、以前の TiDB Dashboard インスタンスに保存されたローカル データは失われます。 +> 新しく有効になった TiDB Dashboard インスタンスが、TiDB Dashboardを提供していた以前のインスタンスと異なる場合、Key Visualize 履歴や検索履歴など、以前の TiDB Dashboard インスタンスに保存されたローカルデータは失われます。 ## 次は何か {#what-s-next} diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index bb11f272a1489..d76163fa297e2 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -5,7 +5,7 @@ summary: TiDB Dashboardは、リバースプロキシを使用して安全に公 # リバースプロキシの背後でTiDB Dashboardを使用する {#use-tidb-dashboard-behind-a-reverse-proxy} -リバース プロキシを使用すると、TiDB Dashboard サービスを内部ネットワークから外部に安全に公開できます。 +リバースプロキシを使用すると、TiDB Dashboard サービスを内部ネットワークから外部に安全に公開できます。 ## 手順 {#procedures} @@ -27,7 +27,7 @@ http://192.168.0.123:2379/dashboard/ > **Note:** > -> この機能は、 `tiup cluster`デプロイメント ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 +> この機能は、 `tiup cluster`デプロイメントツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 > >
TiUPクラスタのアップグレード > @@ -64,13 +64,13 @@ http://192.168.0.123:2379/dashboard/ 2. 設定を有効にするには、HAProxy を再起動します。 -3. リバース プロキシが有効かどうかをテストします。HAProxy が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。 +3. リバースプロキシが有効かどうかをテストします。HAProxy が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。
NGINXを使用する -[NGINX](https://nginx.org/)リバース プロキシとして使用する場合は、次の手順を実行します。 +[NGINX](https://nginx.org/)リバースプロキシとして使用する場合は、次の手順を実行します。 1. TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。NGINX設定ファイルに以下の設定を追加します。 @@ -95,7 +95,7 @@ http://192.168.0.123:2379/dashboard/ sudo nginx -s reload ``` -3. リバース プロキシが有効かどうかをテストします。NGINX が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。 +3. リバースプロキシが有効かどうかをテストします。NGINX が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。
@@ -179,7 +179,7 @@ server_configs:
-TiDB Dashboard サービスをルート パス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。 +TiDB Dashboard サービスをルートパス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。 ```yaml server_configs: @@ -214,7 +214,7 @@ backend tidb_dashboard_back > > **このパス内のサービスのみが**リバースプロキシの背後にあることを保証するには、 `use_backend`ディレクティブの`if`部分を保持する必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 -TiDB Dashboard サービスをルート パス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。 +TiDB Dashboard サービスをルートパス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。 ```haproxy frontend tidb_dashboard_front @@ -249,7 +249,7 @@ server { > > `proxy_pass`ディレクティブの`/dashboard/`パスは必ず保持し**、このパス内のサービスのみが**リバースプロキシの背後にあるようにする必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 -TiDB Dashboard サービスをルート パス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。 +TiDB Dashboard サービスをルートパス ( `http://example.com:8033/`など) で実行する場合は、次の構成を使用します。 ```nginx server { diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index 150ebd0e6fa92..b004037e5e5f0 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -37,7 +37,7 @@ TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:23 > > TiDB、TiKV、その他のコンポーネントは、PDクライアントポートを介してPDコンポーネントと通信する必要があるため、コンポーネント間の内部ネットワークへのアクセスをブロックしないでください。ブロックすると、クラスターが使用できなくなります。 -- リバース プロキシを構成して、別のポートで TiDB Dashboard サービスを外部ネットワークに安全に提供する方法の詳細については、 [リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 +- リバースプロキシを構成して、別のポートで TiDB Dashboard サービスを外部ネットワークに安全に提供する方法の詳細については、 [リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 ### 複数のPDインスタンスを展開するときにTiDB Dashboardポートへのアクセスを開く方法 {#how-to-open-access-to-tidb-dashboard-port-when-deploying-multiple-pd-instances} @@ -49,7 +49,7 @@ TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:23 複数のPDインスタンスがデプロイされている場合、TiDB Dashboardは実際に1つのPDインスタンスのみで実行され、他のPDインスタンスにアクセスするとブラウザのリダイレクトが発生します。そのため、ファイアウォールに正しいIPアドレスが設定されていることを確認する必要があります。このメカニズムの詳細については、 [複数のPDインスタンスを使用したデプロイメント](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances)を参照してください。 -TiUPデプロイメント ツールを使用する場合、次のコマンドを実行すると、実際に TiDB Dashboardを実行している PD インスタンスのアドレスを表示できます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 +TiUPデプロイメントツールを使用する場合、次のコマンドを実行すると、実際に TiDB Dashboardを実行している PD インスタンスのアドレスを表示できます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 ```bash tiup cluster display CLUSTER_NAME --dashboard @@ -59,7 +59,7 @@ tiup cluster display CLUSTER_NAME --dashboard > **Note:** > -> この機能は、 `tiup cluster`デプロイメント ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 +> この機能は、 `tiup cluster`デプロイメントツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 > >
TiUPクラスタのアップグレード > @@ -78,15 +78,15 @@ http://192.168.0.123:2379/dashboard/ この例では、ファイアウォールは、開いている IP `192.168.0.123`のポート`2379`への受信アクセスを設定する必要があり、TiDB Dashboardには[http://192.168.0.123:2379/dashboard/](http://192.168.0.123:2379/dashboard/)経由でアクセスします。 -## TiDB Dashboard専用のリバース プロキシ {#reverse-proxy-only-for-tidb-dashboard} +## TiDB Dashboard専用のリバースプロキシ {#reverse-proxy-only-for-tidb-dashboard} [ファイアウォールを使用して信頼できないアクセスをブロックする](#ファイアウォールを使用して信頼できないアクセスをブロックする)で述べたように、PDクライアントポートで提供されるサービスには、TiDB Dashboard（ [http://IP:2379/dashboard/](http://IP:2379/dashboard/)に配置）だけでなく、PD内の他の特権インターフェース（ [http://IP:2379/pd/api/v1/members](http://IP:2379/pd/api/v1/members)など）も含まれます。したがって、リバースプロキシを使用してTiDB Dashboardを外部ネットワークに提供する場合は、外部ネットワークが**リバース**プロキシを介してPD内の特権インターフェースにアクセスできないように、ポート内のすべてのサービスで**はなく**、プレフィックスが`/dashboard`サービスのみを提供するようにしてください。 -安全で推奨されるリバース プロキシ構成を確認するには、 [リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照することをお勧めします。 +安全で推奨されるリバースプロキシ構成を確認するには、 [リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照することをお勧めします。 ## リバースプロキシのTLSを有効にする {#enable-tls-for-reverse-proxy} -トランスポートレイヤーのセキュリティをさらに強化するには、リバース プロキシに対して TLS を有効にし、さらに mTLS を導入してユーザー証明書を認証することもできます。 +トランスポートレイヤーのセキュリティをさらに強化するには、リバースプロキシに対して TLS を有効にし、さらに mTLS を導入してユーザー証明書を認証することもできます。 詳細は[HTTPSサーバーの設定](http://nginx.org/en/docs/http/configuring_https_servers.html)と[HAProxy SSL 終了](https://www.haproxy.com/blog/haproxy-ssl-termination/)ご覧ください。 diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 91b49733aea49..7c3dc1f4fc15d 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -11,13 +11,13 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 手動プロファイリングを使用すると、TiDB、TiKV、PD、 TiFlashの各インスタンスの現在のパフォーマンスデータをワンクリックでオン**デマンドで**収集できます。収集されたパフォーマンスデータは、FlameGraphまたはDAG形式で視覚化できます。 -これらのパフォーマンス データを使用すると、専門家はインスタンスの CPU やメモリなどの現在のリソース消費の詳細を分析し、CPU オーバーヘッドの増加、メモリ使用量の増加、プロセスの停止など、進行中の高度なパフォーマンスの問題を正確に特定できます。 +これらのパフォーマンスデータを使用すると、専門家はインスタンスの CPU やメモリなどの現在のリソース消費の詳細を分析し、CPU オーバーヘッドの増加、メモリ使用量の増加、プロセスの停止など、進行中の高度なパフォーマンスの問題を正確に特定できます。 プロファイリングを開始すると、TiDB Dashboardは一定期間（デフォルトでは30秒）現在のパフォーマンスデータを収集します。そのため、この機能はクラスターが現在直面している進行中の問題の分析にのみ使用でき、過去の問題には大きな影響を与えません。**いつでも**パフォーマンスデータを収集して分析したい場合は、 [継続的なプロファイリング](/dashboard/continuous-profiling.md)を参照してください。 ## サポートされているパフォーマンスデータ {#supported-performance-data} -現在、次のパフォーマンス データがサポートされています。 +現在、次のパフォーマンスデータがサポートされています。 - CPU: TiDB、TiKV、PD、 TiFlashインスタンスの各内部関数のCPUオーバーヘッド @@ -33,7 +33,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 ## ページにアクセスする {#access-the-page} -次のいずれかの方法でインスタンス プロファイリング ページにアクセスできます。 +次のいずれかの方法でインスタンスプロファイリング ページにアクセスできます。 - TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[高度なデバッグ]** > **[インスタンスのプロファイリング]** > **[手動プロファイリング]**をクリックします。 @@ -43,7 +43,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 ## プロファイリングを開始 {#start-profiling} -インスタンス プロファイリング ページで、少なくとも 1 つのターゲット インスタンスを選択し、 **[プロファイリングの開始]**をクリックしてインスタンス プロファイリングを開始します。 +インスタンスプロファイリング ページで、少なくとも 1 つのターゲット インスタンスを選択し、 **[プロファイリングの開始]**をクリックしてインスタンスプロファイリングを開始します。 ![Start instance profiling](/media/dashboard/dashboard-profiling-start.png) @@ -61,8 +61,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 ## パフォーマンスデータをダウンロード {#download-performance-data} -すべてのインスタンスのプロファイリングが完了したら、右上隅の**プロファイリング結果のダウンロード**をクリックして、すべてのパフォーマンス データをダウンロードできます。 - +すべてのインスタンスのプロファイリングが完了したら、右上隅の**プロファイリング結果のダウンロード**をクリックして、すべてのパフォーマンスデータをダウンロードできます。 ![Download profiling result](/media/dashboard/dashboard-profiling-download.png) 表内の個々のインスタンスをクリックすると、そのプロファイリング結果を表示できます。また、... にマウスを合わせると、生データをダウンロードできます。 diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index 24ce03b15c697..2c7317176dc1f 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -9,19 +9,19 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ ## ページにアクセスする {#access-the-page} -リソース マネージャー ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 +リソースマネージャー ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[リソース マネージャー] を**クリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[リソースマネージャー] を**クリックします。 - ブラウザで[http://127.0.0.1:2379/dashboard/#/resource_manager](http://127.0.0.1:2379/dashboard/#/resource_manager)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 ## リソースマネージャーページ {#resource-manager-page} -次の図は、リソース マネージャーの詳細ページを示しています。 +次の図は、リソースマネージャーの詳細ページを示しています。 ![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)を参照してください。 @@ -72,7 +72,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ パネル上のメトリクスを観察することで、クラスター全体の現在のリソース消費状況を把握できます。監視メトリクスとその意味は次のとおりです。 - 消費された RU の合計: リアルタイムでカウントされた要求ユニットの合計消費量。 -- リソース グループによって消費された RU: リソース グループによってリアルタイムで消費された要求ユニットの数。 +- リソースグループによって消費された RU: リソースグループによってリアルタイムで消費された要求ユニットの数。 - TiDB - CPU クォータ: TiDB の最大 CPU 使用量。 - CPU 使用率: すべての TiDB インスタンスの合計 CPU 使用率。 diff --git a/dashboard/dashboard-session-share.md b/dashboard/dashboard-session-share.md index 838e5e118ef96..e9e4778e82516 100644 --- a/dashboard/dashboard-session-share.md +++ b/dashboard/dashboard-session-share.md @@ -5,7 +5,7 @@ summary: TiDB Dashboardでは、ユーザーが現在のセッションを他の # TiDB Dashboardセッションを共有する {#share-tidb-dashboard-sessions} -TiDB Dashboardの現在のセッションを他のユーザーと共有して、他のユーザーがユーザー パスワードを入力せずに TiDB Dashboardにアクセスして操作できるようにすることができます。 +TiDB Dashboardの現在のセッションを他のユーザーと共有して、他のユーザーがユーザーパスワードを入力せずに TiDB Dashboardにアクセスして操作できるようにすることができます。 ## 招待者の手順 {#steps-for-the-inviter} diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index efa457266abd2..bd83286211455 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -21,7 +21,7 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす - ブラウザで[http://127.0.0.1:2379/dashboard/#/slow_query](http://127.0.0.1:2379/dashboard/#/slow_query)にアクセスしてください。 `127.0.0.1:2379`を実際の PD アドレスとポートに置き換えてください。 -スロー クエリ ページに表示されるすべてのデータは、TiDB スロー クエリ システム テーブルおよびスロー クエリ ログから取得されます。詳細については[スロークエリログ](/identify-slow-queries.md)を参照してください。 +スロークエリ ページに表示されるすべてのデータは、TiDB スロークエリ システムテーブルおよびスロークエリログから取得されます。詳細については[スロークエリログ](/identify-slow-queries.md)を参照してください。 ### フィルターを変更する {#change-filters} diff --git a/dashboard/dashboard-statement-details.md b/dashboard/dashboard-statement-details.md index 7e1c61a02f946..b219740185218 100644 --- a/dashboard/dashboard-statement-details.md +++ b/dashboard/dashboard-statement-details.md @@ -7,7 +7,7 @@ summary: TiDB Dashboardは、SQLテンプレートの概要、実行計画一覧 リスト内の任意の項目をクリックすると、SQL文の詳細ページに移動し、より詳細な情報が表示されます。この情報には、以下の部分が含まれます。 -- SQL ステートメントの概要。これには、SQL テンプレート、SQL テンプレート ID、表示されている SQL 実行の現在の時間範囲、実行計画の数、SQL ステートメントが実行されるデータベース、および高速プラン バインディング機能が含まれます (次の図の領域 1)。 +- SQL ステートメントの概要。これには、SQL テンプレート、SQL テンプレート ID、表示されている SQL 実行の現在の時間範囲、実行計画の数、SQL ステートメントが実行されるデータベース、および高速プランバインディング機能が含まれます (次の図の領域 1)。 - 実行計画リスト：SQL文に複数の実行計画がある場合、このリストが表示されます。実行計画のテキスト情報に加え、TiDB v6.2.0ではビジュアル実行計画が導入され、文の各演算子や詳細情報をより直感的に把握できるようになりました。複数の実行計画を選択すると、選択したプランの詳細がリストの下に表示されます（下図の領域2）。 - プランの実行詳細。選択した実行計画の詳細情報が表示されます。1（下図の領域3） [実行計画の詳細](#execution-details-of-plans)を参照してください。 @@ -49,7 +49,7 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま ### 制限 {#limitation} -現在、高速プラン バインディング機能では、次の種類の SQL ステートメントはサポートされていません。 +現在、高速プランバインディング機能では、次の種類の SQL ステートメントはサポートされていません。 - `SELECT` `INSERT` `UPDATE` `REPLACE` `DELETE` - サブクエリを含むクエリ @@ -86,7 +86,7 @@ TiDB Dashboardでは、実行計画を表、テキスト、グラフの3つの - 列幅は自由に調整できます。 - コンテンツが列幅を超えると、自動的に切り捨てられ、完全な情報のツールヒントが表示されます。 -- 実行計画が大きい場合は、ローカル分析用にテキスト ファイルとしてダウンロードできます。 +- 実行計画が大きい場合は、ローカル分析用にテキストファイルとしてダウンロードできます。 - 列ピッカーを使用して列を非表示にしたり管理したりできます。 ![Execution plan in table format - column picker](/media/dashboard/dashboard-table-plan-columnpicker.png) @@ -142,7 +142,7 @@ SQL実行の基本情報には、テーブル名、インデックス名、実 #### スロークエリタブ {#slow-query-tab} -実行計画の実行が遅すぎる場合は、 **[Slow Query]**タブで関連するスロー クエリ レコードを確認できます。 +実行計画の実行が遅すぎる場合は、 **[Slow Query]**タブで関連するスロークエリ レコードを確認できます。 ![Slow Query](/media/dashboard/dashboard-statement-plans-slow-queries.png) diff --git a/dashboard/dashboard-statement-list.md b/dashboard/dashboard-statement-list.md index 1695c82f4658a..223899baf0b7d 100644 --- a/dashboard/dashboard-statement-list.md +++ b/dashboard/dashboard-statement-list.md @@ -17,7 +17,7 @@ SQL ステートメントの概要ページにアクセスするには、次の - ブラウザで[http://127.0.0.1:2379/dashboard/#/statement](http://127.0.0.1:2379/dashboard/#/statement)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 -SQL文の概要ページに表示されるすべてのデータは、TiDB ステートメント サマリー テーブルから取得されます。テーブルの詳細については、 [TiDB ステートメント サマリー テーブル](/statement-summary-tables.md)を参照してください。 +SQL文の概要ページに表示されるすべてのデータは、TiDB ステートメントサマリー テーブルから取得されます。テーブルの詳細については、 [TiDB ステートメントサマリー テーブル](/statement-summary-tables.md)を参照してください。 > **Note:** > @@ -60,7 +60,7 @@ SQL文の概要ページの上部で、表示するSQL実行の時間範囲を > **Note:** > -> - ステートメント システム テーブルはメモリ内にのみ保存されるため、SQL ステートメント機能が無効にされると、システム テーブル内のデータはクリアされます。 +> - ステートメント システムテーブルはメモリ内にのみ保存されるため、SQL ステートメント機能が無効にされると、システムテーブル内のデータはクリアされます。 > > - `Collect interval`と`retain duration`の値はメモリ使用量に影響するため、実際の状況に応じて調整することをお勧めします`retain duration`の値は大きすぎないようにしてください。 diff --git a/data-type-json.md b/data-type-json.md index 88f942ec3326c..fa3fcf6bb4ecb 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -50,7 +50,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` - 現在、TiDBはTiFlashへのプッシュダウンを限定的に`JSON`関数のみサポートしています。詳細については[プッシュダウン式](/tiflash/tiflash-supported-pushdown-calculations.md#push-down-expressions)をご覧ください。 - TiDBバックアップ＆リストア（BR）は、v6.3.0でJSON列データのエンコード方法を変更します。そのため、JSON列を含むデータをBRを使用してv6.3.0より前のTiDBクラスターにリストアすることは推奨されません。 -- `DATE` 、 `DATETIME` 、 `TIME`などの非標準`JSON`データ型を含むデータをレプリケートする場合は、レプリケーション ツールを使用しないでください。 +- `DATE` 、 `DATETIME` 、 `TIME`などの非標準`JSON`データ型を含むデータをレプリケートする場合は、レプリケーションツールを使用しないでください。 ## MySQLとの互換性 {#mysql-compatibility} diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 3c8ac7be7eef3..4487207f2db6c 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -39,7 +39,7 @@ EXPLAIN SELECT * FROM t WHERE a > 4; 3 rows in set (0.002 sec) ``` -前のプランでは、新しく作成されたインデックスにはまだ統計情報がないため、TiDB はパス推定にヒューリスティック ルールのみに頼ることができます。インデックス アクセス パスでテーブル検索が不要でコストが大幅に低い場合を除き、オプティマイザはより安定した既存のパスを選択する傾向があります。前の例では、フル テーブル スキャンが選択されています。ただし、データ分散の観点から見ると、 `t.a > 4`実際には 0 行を返します。新しいインデックス`idx_a`が使用された場合、クエリは関連する行をすばやく見つけて、フル テーブル スキャンを回避できます。この例では、DDL がインデックスを作成した後、統計がすぐに収集されないため、生成されたプランは最適ではありませんが、オプティマイザは元のプランを引き続き使用するため、クエリのパフォーマンスは大幅に低下しません。ただし、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)によると、場合によってはヒューリスティックによって古いインデックスと新しいインデックスが不当に比較され、元のプランが依存しているインデックスが削除され、最終的にフル テーブル スキャンにフォールバックすることがあります。 +前のプランでは、新しく作成されたインデックスにはまだ統計情報がないため、TiDB はパス推定にヒューリスティック ルールのみに頼ることができます。インデックス アクセス パスでテーブル検索が不要でコストが大幅に低い場合を除き、オプティマイザはより安定した既存のパスを選択する傾向があります。前の例では、フルテーブルスキャンが選択されています。ただし、データ分散の観点から見ると、 `t.a > 4`実際には 0 行を返します。新しいインデックス`idx_a`が使用された場合、クエリは関連する行をすばやく見つけて、フルテーブルスキャンを回避できます。この例では、DDL がインデックスを作成した後、統計がすぐに収集されないため、生成されたプランは最適ではありませんが、オプティマイザは元のプランを引き続き使用するため、クエリのパフォーマンスは大幅に低下しません。ただし、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)によると、場合によってはヒューリスティックによって古いインデックスと新しいインデックスが不当に比較され、元のプランが依存しているインデックスが削除され、最終的にフルテーブルスキャンにフォールバックすることがあります。 v8.5.0以降、TiDBはインデックス間のヒューリスティック比較と、統計情報が欠落している場合の動作を改善しました。それでもなお、複雑なシナリオでは、DDLに`ANALYZE`を埋め込むことがプラン変更を防ぐ最善の方法です。システム変数[`tidb_stats_update_during_ddl`](/system-variables.md#tidb_stats_update_during_ddl-new-in-v854)を使用して、インデックス作成時または再編成時に埋め込み`ANALYZE`を実行するかどうかを制御できます。デフォルト値は`OFF`です。 diff --git a/deploy-monitoring-services.md b/deploy-monitoring-services.md index f290fe279af7b..277e265361046 100644 --- a/deploy-monitoring-services.md +++ b/deploy-monitoring-services.md @@ -210,18 +210,18 @@ Grafana サービスを開始します。 > > **パスワードの変更**手順では、 **スキップ**を選択できます。 -2. Grafana サイドバー メニューで、**コンフィグレーション**内の**データ ソース**をクリックします。 +2. Grafana サイドバー メニューで、**コンフィグレーション**内の**データソース**をクリックします。 -3. **データ ソースの追加を**クリックします。 +3. **データソースの追加を**クリックします。 -4. データ ソース情報を指定します。 +4. データソース情報を指定します。 - - データ ソースの**名前**を指定します。 + - データソースの**名前**を指定します。 - **タイプ**には**Prometheus**を選択します。 - **URL**には、Prometheus アドレスを指定します。 - 必要に応じて他のフィールドを指定します。 -5. 新しいデータ ソースを保存するには、 **[追加]**をクリックします。 +5. 新しいデータソースを保存するには、 **[追加]**をクリックします。 ### ステップ2: Grafanaダッシュボードをインポートする {#step-2-import-a-grafana-dashboard} @@ -239,7 +239,7 @@ PDサーバー、TiKVサーバー、および TiDBサーバーの Grafana ダッ 4. **[ロード]**をクリックします。 -5. Prometheus データ ソースを選択します。 +5. Prometheus データソースを選択します。 6. **インポート**をクリックします。Prometheusダッシュボードがインポートされます。 diff --git a/develop/_index.md b/develop/_index.md index 8f0b423f3d9e2..37cc2f8abe803 100644 --- a/develop/_index.md +++ b/develop/_index.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-overview/','/ja/tidb/dev/dev-guide-overview # 開発者ガイドの概要 {#developer-guide-overview} -[TiDB](https://github.com/pingcap/tidb)は、ハイブリッド トランザクションおよび分析処理 (HTAP) ワークロードをサポートするオープン ソースの分散 SQL データベースです。 +[TiDB](https://github.com/pingcap/tidb)は、ハイブリッドトランザクションおよび分析処理 (HTAP) ワークロードをサポートするオープン ソースの分散 SQL データベースです。 このガイドは、アプリケーション開発者が TiDB への接続、データベースの設計、データの書き込みとクエリ、TiDB 上での信頼性の高い高パフォーマンスのアプリケーションの構築方法を迅速に習得するのに役立ちます。 @@ -16,7 +16,7 @@ aliases: ['/ja/tidb/stable/dev-guide-overview/','/ja/tidb/dev/dev-guide-overview ## 言語とフレームワーク別のガイド {#guides-by-language-and-framework} -サンプル コード付きのガイドに従って、使用する言語でアプリケーションを構築します。 +サンプルコード付きのガイドに従って、使用する言語でアプリケーションを構築します。 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index 07db0b85e925a..2064c214b0965 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -72,7 +72,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration > > - `--guided`オプションでは、プロンプトが表示され、デプロイの手順を案内します。入力内容は構成ファイルに保存され、デフォルトでは`samconfig.toml`というファイルになります。 > - `stack_name`デプロイする AWS Lambda の名前を指定します。 - > - このガイドでは、TiDB Cloud Starterのクラウド プロバイダーとして AWS を使用しています。ソースまたは宛先として Amazon S3 を使用するには、AWS Lambda の`region`を Amazon S3 と同じに設定する必要があります。 + > - このガイドでは、TiDB Cloud Starterのクラウドプロバイダーとして AWS を使用しています。ソースまたは宛先として Amazon S3 を使用するには、AWS Lambda の`region`を Amazon S3 と同じに設定する必要があります。 > - 既に`sam deploy --guided`を実行したことがある場合は、代わりに`sam deploy`を実行するだけで、SAM CLI は設定ファイル`samconfig.toml`を使用して操作を簡素化します。 以下のような出力が表示された場合、このLambda関数は正常にデプロイされています。 diff --git a/develop/dev-guide-build-cluster-in-cloud.md b/develop/dev-guide-build-cluster-in-cloud.md index ea3b6e3b86b52..177d89e9d41eb 100644 --- a/develop/dev-guide-build-cluster-in-cloud.md +++ b/develop/dev-guide-build-cluster-in-cloud.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-build-cluster-in-cloud/','/ja/tidb/dev/dev- このドキュメントでは、TiDB を使い始めるための最も簡単な方法を説明します。TiDB [TiDB Cloud](https://www.pingcap.com/tidb-cloud)を使用してTiDB Cloud Starterインスタンスを作成し、それに接続して、サンプル アプリケーションを実行します。 -ローカル マシンで TiDB を実行する必要がある場合は、 [TiDBをローカルで起動する](/quick-start-with-tidb.md)を参照してください。 +ローカルマシンで TiDB を実行する必要がある場合は、 [TiDBをローカルで起動する](/quick-start-with-tidb.md)を参照してください。 ## ステップ1. TiDB Cloud Starterインスタンスを作成します {#step-1-create-a-starter-instance} {#step-1-create-a-starter-instance} diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index bcfd9d7a39035..b48bdb8bf8d24 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -10,10 +10,10 @@ aliases: ['/ja/tidb/stable/dev-guide-choose-driver-or-orm/','/ja/tidbcloud/dev-g > > TiDB は、ドライバーと ORM に対して次の 2 つのサポート レベルを提供します。 > -> - **完全**: TiDB がツールのほとんどの機能と互換性があり、最新バージョンとの互換性を維持していることを示します。PingCAP は、最新バージョン[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)との互換性テストを定期的に実施します。 +> - **完全**: TiDB がツールのほとんどの機能と互換性があり、最新バージョンとの互換性を維持していることを示します。PingCAP は、最新バージョン[TiDB でサポートされているサードパーティツール](/develop/dev-guide-third-party-support.md)との互換性テストを定期的に実施します。 > - **互換**：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 > -> 詳細については[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)を参照してください。 +> 詳細については[TiDB でサポートされているサードパーティツール](/develop/dev-guide-third-party-support.md)を参照してください。 TiDBはMySQLプロトコルと高い互換性がありますが、一部の機能はMySQLと互換性がありません。互換性の違いに関する完全なリストについては、 [MySQLとの互換性](/mysql-compatibility.md)を参照してください。 diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index a65fb68cf5a9f..5253538825de5 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -156,7 +156,7 @@ OLTP（オンライン・トランザクション処理）シナリオでは、 現在、ほとんどの上位フレームワークはSQL実行のためにPrepare APIを呼び出しています。開発でJDBC APIを直接使用する場合は、Prepare APIを選択するように注意してください。 -さらに、MySQL Connector/J のデフォルト実装では、クライアント側のステートメントのみが前処理され、クライアント側で`?`が置換された後、ステートメントはテキスト ファイルとしてサーバーに送信されます。したがって、Prepare API を使用するだけでなく、TiDBサーバーでステートメントの前処理を実行する前に、JDBC 接続パラメータで`useServerPrepStmts = true`を設定する必要があります。パラメータ設定の詳細については、 [MySQL JDBC パラメータ](#mysql-jdbc-parameters)を参照してください。 +さらに、MySQL Connector/J のデフォルト実装では、クライアント側のステートメントのみが前処理され、クライアント側で`?`が置換された後、ステートメントはテキストファイルとしてサーバーに送信されます。したがって、Prepare API を使用するだけでなく、TiDBサーバーでステートメントの前処理を実行する前に、JDBC 接続パラメータで`useServerPrepStmts = true`を設定する必要があります。パラメータ設定の詳細については、 [MySQL JDBC パラメータ](#mysql-jdbc-parameters)を参照してください。 #### バッチAPIを使用する {#use-batch-api} diff --git a/develop/dev-guide-create-secondary-indexes.md b/develop/dev-guide-create-secondary-indexes.md index ab6c02b513f27..967773acde09c 100644 --- a/develop/dev-guide-create-secondary-indexes.md +++ b/develop/dev-guide-create-secondary-indexes.md @@ -27,29 +27,27 @@ TiDB では、[既存のテーブルにセカンダリインデックスを追 ## 既存のテーブルにセカンダリインデックスを追加する {#add-a-secondary-index-to-an-existing-table} -既存のテーブルにセカンダリ インデックスを追加するには、次のように[CREATE INDEX](/sql-statements/sql-statement-create-index.md)ステートメントを使用できます。 - +既存のテーブルにセカンダリインデックスを追加するには、次のように[CREATE INDEX](/sql-statements/sql-statement-create-index.md)ステートメントを使用できます。 ```sql CREATE INDEX {index_name} ON {table_name} ({column_names}); ``` パラメータの説明: -- `{index_name}` : セカンダリ インデックスの名前。 +- `{index_name}` : セカンダリインデックスの名前。 - `{table_name}` : テーブル名。 - `{column_names}` : インデックスを作成する列の名前をセミコロンとカンマで区切ります。 ## 新しいテーブルを作成する際にセカンダリインデックスを作成する {#create-a-secondary-index-when-creating-a-new-table} -テーブルの作成と同時にセカンダリ インデックスを作成するには、[CREATE TABLE](/sql-statements/sql-statement-create-table.md)の末尾に`KEY`キーワードを含む句を追加します。 - +テーブルの作成と同時にセカンダリインデックスを作成するには、[CREATE TABLE](/sql-statements/sql-statement-create-table.md)の末尾に`KEY`キーワードを含む句を追加します。 ```sql KEY `{index_name}` (`{column_names}`) ``` パラメータの説明: -- `{index_name}` : セカンダリ インデックスの名前。 +- `{index_name}` : セカンダリインデックスの名前。 - `{column_names}` : インデックスを作成する列の名前をセミコロンとカンマで区切ります。 ## セカンダリインデックス作成におけるルール {#rules-in-secondary-index-creation} @@ -146,7 +144,7 @@ SQLパフォーマンスチューニングの詳細については、以下の > **Note:** > -> TiDB はクエリ時のインデックスの明示的な使用もサポートしており、[オプティマイザのヒント](/optimizer-hints.md)や[SQLプラン管理（SPM）](/sql-plan-management.md)を使用してインデックスの使用を人為的に制御できます。ただし、インデックス、オプティマイザ ヒント、または SPM についてよく知らない場合は、予期しない結果を避けるためにこの機能を使用**しないでください**。 +> TiDB はクエリ時のインデックスの明示的な使用もサポートしており、[オプティマイザのヒント](/optimizer-hints.md)や[SQLプラン管理（SPM）](/sql-plan-management.md)を使用してインデックスの使用を人為的に制御できます。ただし、インデックス、オプティマイザヒント、または SPM についてよく知らない場合は、予期しない結果を避けるためにこの機能を使用**しないでください**。 テーブルのインデックスをクエリするには、[SHOW INDEXES](/sql-statements/sql-statement-show-indexes.md)ステートメントを使用できます。 @@ -168,7 +166,7 @@ SHOW INDEXES FROM `bookshop`.`books`; ## 次のステップ {#next-step} -データベースを作成し、テーブルとセカンダリ インデックスを追加したら、アプリケーションにデータ[書く](/develop/dev-guide-insert-data.md)機能と[読む](/develop/dev-guide-get-data-from-single-table.md)機能を追加できます。 +データベースを作成し、テーブルとセカンダリインデックスを追加したら、アプリケーションにデータ[書く](/develop/dev-guide-insert-data.md)機能と[読む](/develop/dev-guide-get-data-from-single-table.md)機能を追加できます。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 35b90ce4037a2..42e554c78d643 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -230,7 +230,7 @@ CREATE TABLE `bookshop`.`users` ( > **Note:** > -> このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)を参照してください。 +> このセクションで説明する手順は、クイックスタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)を参照してください。 `bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。 @@ -336,7 +336,7 @@ SHOW TABLES IN `bookshop`; ### テーブル名を付ける際のガイドライン {#guidelines-to-follow-when-naming-a-table} - **完全修飾**テーブル名（例： `CREATE TABLE {database_name}. {table_name}` ）を使用してください。データベース名を指定しない場合、TiDB は**SQL セッション**で現在使用されているデータベースを使用します。SQL セッションでデータベースを指定する際に`USE {databasename};`を使用しない場合、TiDB はエラーを返します。 -- 意味のあるテーブル名を使用してください。たとえば、ユーザー テーブルを作成する必要がある場合は、 `user` 、 `t_user` 、 `users`のような名前を使用するか、会社または組織の命名規則に従ってください。会社または組織に命名規則がない場合は、 [テーブル命名規則](/develop/dev-guide-object-naming-guidelines.md#table-naming-convention)を参照してください。 `t1` 、 `table1`のようなテーブル名は使用しないでください。 +- 意味のあるテーブル名を使用してください。たとえば、ユーザーテーブルを作成する必要がある場合は、 `user` 、 `t_user` 、 `users`のような名前を使用するか、会社または組織の命名規則に従ってください。会社または組織に命名規則がない場合は、 [テーブル命名規則](/develop/dev-guide-object-naming-guidelines.md#table-naming-convention)を参照してください。 `t1` 、 `table1`のようなテーブル名は使用しないでください。 - 複数の単語はアンダースコアで区切られ、名前は32文字以内にすることをお勧めします。 - 異なるビジネスモジュールのテーブル用に個別の`DATABASE`を作成し、それに応じてコメントを追加してください。 @@ -381,7 +381,7 @@ SHOW TABLES IN `bookshop`; ## あと一歩 {#one-more-step} -このドキュメントで作成されたすべてのテーブルにはセカンダリ インデックスが含まれていないことに注意してください。セカンダリ インデックスを追加するガイドについては、 [セカンダリインデックスの作成](/develop/dev-guide-create-secondary-indexes.md)を参照してください。 +このドキュメントで作成されたすべてのテーブルにはセカンダリインデックスが含まれていないことに注意してください。セカンダリインデックスを追加するガイドについては、 [セカンダリインデックスの作成](/develop/dev-guide-create-secondary-indexes.md)を参照してください。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-delete-data.md b/develop/dev-guide-delete-data.md index 0a8e32b182112..6b5d6780c0a85 100644 --- a/develop/dev-guide-delete-data.md +++ b/develop/dev-guide-delete-data.md @@ -172,7 +172,7 @@ with connection: ### TiDB GCメカニズム {#tidb-gc-mechanism} -TiDB は`DELETE`ステートメントを実行した直後にデータを削除するわけではありません。代わりに、削除準備完了としてデータをマークします。その後、TiDB GC (ガベージ コレクション) が古いデータをクリーンアップするまで待機します。したがって、 `DELETE`ステートメントを実行しても、ディスク使用量はすぐには削減さ***れません***。 +TiDB は`DELETE`ステートメントを実行した直後にデータを削除するわけではありません。代わりに、削除準備完了としてデータをマークします。その後、TiDB GC (ガベージコレクション) が古いデータをクリーンアップするまで待機します。したがって、 `DELETE`ステートメントを実行しても、ディスク使用量はすぐには削減さ***れません***。 デフォルトでは、GC（ガベージコレクション）は10分ごとに実行されます。各GCでは、 **safe_point**と呼ばれる時点が計算されます。この時点より前のデータは再利用されないため、TiDBは安全にクリーンアップできます。 @@ -356,7 +356,7 @@ with connection: ### 非トランザクション一括削除の前提条件 {#prerequisites-of-non-transactional-bulk-delete} -非トランザクション一括削除を使用する前に、[非トランザクションDMLステートメントのドキュメント](/non-transactional-dml.md)ドキュメントを必ず読んでください。非トランザクション一括削除により、バッチ データ処理シナリオのパフォーマンスと使いやすさが向上しますが、トランザクションの原子性と分離性が損なわれます。 +非トランザクション一括削除を使用する前に、[非トランザクションDMLステートメントのドキュメント](/non-transactional-dml.md)ドキュメントを必ず読んでください。非トランザクション一括削除により、バッチデータ処理シナリオのパフォーマンスと使いやすさが向上しますが、トランザクションの原子性と分離性が損なわれます。 したがって、誤った取り扱いによる重大な結果（データ損失など）を避けるため、慎重に使用する必要があります。 diff --git a/develop/dev-guide-gui-datagrip.md b/develop/dev-guide-gui-datagrip.md index 4c37827b28687..0f4220ea3ac1f 100644 --- a/develop/dev-guide-gui-datagrip.md +++ b/develop/dev-guide-gui-datagrip.md @@ -95,13 +95,12 @@ DataGripは2つの方法で使用できます。 - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 8. 新しく作成したプロジェクトで、**データベースエクスプローラー**パネルの左上隅にある**+**をクリックし、 **データソース** > **その他** > **TiDB**を選択します。 -9. 適切な接続文字列をコピーして、DataGrip の [**データ ソースとドライバー]**ウィンドウに貼り付けてください。DataGrip のフィールドとTiDB Cloud Premium の接続文字列のマッピングは以下のとおりです。 +9. 適切な接続文字列をコピーして、DataGrip の [**データソースとドライバー]**ウィンドウに貼り付けてください。DataGrip のフィールドとTiDB Cloud Premium の接続文字列のマッピングは以下のとおりです。 | データグリップフィールド | TiDB Cloud Premium接続文字列 | | ------------ | ----------------------- | @@ -128,7 +127,7 @@ DataGripは2つの方法で使用できます。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 @@ -138,7 +137,7 @@ DataGripは2つの方法で使用できます。 ![Select a data source in DataGrip](/media/develop/datagrip-data-source-select.jpg) -6. 適切な接続文字列をコピーして、DataGrip の [**データ ソースとドライバ]**ウィンドウに貼り付けてください。DataGrip フィールドとTiDB Cloud Dedicated接続文字列のマッピングは以下のとおりです。 +6. 適切な接続文字列をコピーして、DataGrip の [**データソースとドライバ]**ウィンドウに貼り付けてください。DataGrip フィールドとTiDB Cloud Dedicated接続文字列のマッピングは以下のとおりです。 | データグリップフィールド | TiDB Cloud Dedicated接続文字列 | | ------------ | ------------------------- | diff --git a/develop/dev-guide-gui-dbeaver.md b/develop/dev-guide-gui-dbeaver.md index 66de5567ab7d1..cffbb4138f5cb 100644 --- a/develop/dev-guide-gui-dbeaver.md +++ b/develop/dev-guide-gui-dbeaver.md @@ -28,7 +28,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt さらに、 **Windows**上の DBeaver からTiDB Cloud StarterまたはTiDB Cloud Essential のパブリックエンドポイントに接続するには、以下の手順で追加の SSL 証明書 (ISRG Root X1) を設定する必要があります。設定しない場合、接続は失敗します。その他のオペレーティングシステムの場合は、これらの手順はスキップできます。 -1. [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)をダウンロードし、 `C:\certs\isrgrootx1.pem`などのローカル パスに保存します。 +1. [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)をダウンロードし、 `C:\certs\isrgrootx1.pem`などのローカルパスに保存します。 2. DBeaverで接続設定を編集し、 **SSL**タブに移動します。 @@ -106,8 +106,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. DBeaverを起動し、左上隅の**新しいデータベース接続**をクリックします。 **データベースへの接続**ダイアログで、リストから**TiDBを**選択し、 **次へ**をクリックします。 8. 適切な接続文字列をコピーして、DBeaverの接続パネルに貼り付けてください。DBeaverのフィールドとTiDB Cloud Premiumの接続文字列のマッピングは以下のとおりです。 @@ -136,7 +135,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. DBeaverを起動し、左上隅の**新しいデータベース接続**をクリックします。 **データベースへの接続**ダイアログで、リストから**TiDBを**選択し、 **次へ**をクリックします。 diff --git a/develop/dev-guide-gui-mysql-workbench.md b/develop/dev-guide-gui-mysql-workbench.md index d222334e1068d..70a8db5cd2880 100644 --- a/develop/dev-guide-gui-mysql-workbench.md +++ b/develop/dev-guide-gui-mysql-workbench.md @@ -97,8 +97,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. MySQL Workbenchを起動し、 **MySQL接続**タイトルの横にある**+**をクリックします。 8. **新しい接続の設定**ダイアログで、以下の接続パラメータを設定します。 @@ -124,7 +123,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 diff --git a/develop/dev-guide-gui-navicat.md b/develop/dev-guide-gui-navicat.md index 4a7189fbd7c7c..333d10bc44627 100644 --- a/develop/dev-guide-gui-navicat.md +++ b/develop/dev-guide-gui-navicat.md @@ -93,8 +93,7 @@ TiDBはMySQL互換データベースであり、[Navicat](https://www.navicat.co - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. Navicat Premiumを起動し、左上隅の**接続**をクリックし、**ベンダーフィルタ**リストから**PingCAP**を選択し、右側のパネルで**TiDBを**ダブルクリックします。 8. **新規接続（TiDB）**ダイアログで、以下の接続パラメータを設定します。 @@ -122,7 +121,7 @@ TiDBはMySQL互換データベースであり、[Navicat](https://www.navicat.co IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. **CA証明書をダウンロードするには、「CA証明書**」をクリックしてください。 diff --git a/develop/dev-guide-gui-vscode-sqltools.md b/develop/dev-guide-gui-vscode-sqltools.md index a2716c0ccda13..e3117c8687573 100644 --- a/develop/dev-guide-gui-vscode-sqltools.md +++ b/develop/dev-guide-gui-vscode-sqltools.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-gui-vscode-sqltools/','/ja/tidb/dev/dev-gui # Visual Studio Codeを使用してTiDBに接続する {#connect-to-tidb-with-visual-studio-code} -TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code)](https://code.visualstudio.com/)は軽量かつ強力なソース コード エディターです。このチュートリアルでは、TiDB を[公式ドライバー](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)としてサポートする[SQLツール](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools)拡張機能を使用します。 +TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code)](https://code.visualstudio.com/)は軽量かつ強力なソースコード エディターです。このチュートリアルでは、TiDB を[公式ドライバー](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)としてサポートする[SQLツール](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools)拡張機能を使用します。 このチュートリアルでは、Visual Studio Code を使用して TiDB に接続する方法を学ぶことができます。 @@ -116,8 +116,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **[接続]**セクションで**[新しい接続を追加]**をクリックし、データベースドライバとして**TiDB**を選択します。 8. 設定画面で、以下の接続パラメータを設定します。 @@ -150,7 +149,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **[接続]**セクションで**[新しい接続を追加]**をクリックし、データベースドライバとして**TiDB**を選択します。 diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 1f29dea0c0bfa..b6519c222b0ae 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -20,7 +20,7 @@ TiDBは、オンライントランザクション処理（OLTP）には行ベー tiup demo bookshop prepare --users=200000 --books=500000 --authors=100000 --ratings=1000000 --orders=1000000 --host 127.0.0.1 --port 4000 --drop-tables ``` -または、 [TiDB Cloudのインポート機能を使用する](/develop/dev-guide-bookshop-schema-design.md#tidb-cloud-via-the-import-feature)を実行して事前に準備されたサンプル データをインポートすることもできます。 +または、 [TiDB Cloudのインポート機能を使用する](/develop/dev-guide-bookshop-schema-design.md#tidb-cloud-via-the-import-feature)を実行して事前に準備されたサンプルデータをインポートすることもできます。 ## ウィンドウ関数 {#window-functions} diff --git a/develop/dev-guide-index-best-practice.md b/develop/dev-guide-index-best-practice.md index 82753235d5411..607bac9a08bc4 100644 --- a/develop/dev-guide-index-best-practice.md +++ b/develop/dev-guide-index-best-practice.md @@ -1,6 +1,6 @@ --- title: Best Practices for Indexing -summary: TiDB でインデックスを作成して使用するためのベスト プラクティスをいくつか学習します。 +summary: TiDB でインデックスを作成して使用するためのベストプラクティスをいくつか学習します。 aliases: ['/ja/tidb/stable/dev-guide-index-best-practice/','/ja/tidbcloud/dev-guide-index-best-practice/'] --- @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/dev-guide-index-best-practice/','/ja/tidbcloud/dev-gu # インデックス作成のベストプラクティス {#best-practices-for-indexing} -このドキュメントでは、TiDB でインデックスを作成および使用するためのベスト プラクティスをいくつか紹介します。 +このドキュメントでは、TiDB でインデックスを作成および使用するためのベストプラクティスをいくつか紹介します。 ## 始める前に {#before-you-begin} @@ -103,7 +103,7 @@ CREATE TABLE `books` ( SELECT title, published_at FROM books WHERE title = 'database'; ``` - 次のクエリ ステートメントでは結合インデックス`(title, published_at)`を使用できますが、インデックスのない列をクエリするための追加コストが発生し、TiDB はインデックス データに格納されている参照 (通常は主キー情報) に従って行データをクエリする必要があります。 + 次のクエリステートメントでは結合インデックス`(title, published_at)`を使用できますが、インデックスのない列をクエリするための追加コストが発生し、TiDB はインデックスデータに格納されている参照 (通常は主キー情報) に従って行データをクエリする必要があります。 ```sql SELECT * FROM books WHERE title = 'database'; diff --git a/develop/dev-guide-insert-data.md b/develop/dev-guide-insert-data.md index b4d24643c0374..a3bcf56e9ba2a 100644 --- a/develop/dev-guide-insert-data.md +++ b/develop/dev-guide-insert-data.md @@ -243,7 +243,7 @@ TiDBに大量のデータを迅速にインポートする必要がある場合
- データエクスポート： [Dumpling](/dumpling-overview.md) 。MySQLまたはTiDBのデータをローカルまたはAmazon S3にエクスポートできます。 -- データインポート: [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 。 **Dumpling**でエクスポートされたデータ、 **CSV**ファイル、 [Amazon AuroraからTiDBへのデータ移行](/migrate-aurora-to-tidb.md)をインポートできます。ローカル ディスクまたは Amazon S3 クラウド ディスクからのデータの読み取りもサポートします。 +- データインポート: [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 。 **Dumpling**でエクスポートされたデータ、 **CSV**ファイル、 [Amazon AuroraからTiDBへのデータ移行](/migrate-aurora-to-tidb.md)をインポートできます。ローカルディスクまたは Amazon S3 クラウドディスクからのデータの読み取りもサポートします。 - データレプリケーション： [TiDB Data Migration](/dm/dm-overview.md)MySQL、MariaDB、Amazon AuroraデータベースをTiDBにレプリケートできます。また、ソースデータベースからのシャーディングされたインスタンスとテーブルのマージおよび移行もサポートしています。 - データのバックアップと復元:[Backup & Restore (BR)](/br/backup-and-restore-overview.md) 。 **Dumpling**と比較して、 **BR**は***ビッグデータの***シナリオにより適しています。 diff --git a/develop/dev-guide-object-naming-guidelines.md b/develop/dev-guide-object-naming-guidelines.md index 0e91f99aeaa96..a01c4e59700be 100644 --- a/develop/dev-guide-object-naming-guidelines.md +++ b/develop/dev-guide-object-naming-guidelines.md @@ -6,14 +6,14 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d # オブジェクトの命名規則 {#object-naming-convention} -このドキュメントでは、データベース、テーブル、インデックス、ユーザーなどのデータベース オブジェクトの命名規則について説明します。 +このドキュメントでは、データベース、テーブル、インデックス、ユーザーなどのデータベースオブジェクトの命名規則について説明します。 ## 一般的なルール {#general-rules} - 意味のある英語の単語をアンダースコアで区切って使用することをお勧めします。 - 名前には文字、数字、アンダースコアのみを使用してください。 - `group`や`order`などの TiDB 予約語を列名として使用しないでください。 -- すべてのデータベース オブジェクトには小文字を使用することをお勧めします。 +- すべてのデータベースオブジェクトには小文字を使用することをお勧めします。 ## データベースの命名規則 {#database-naming-convention} diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index 630c8814875e9..51ceea0fd0213 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -1,16 +1,16 @@ --- title: Performance Tuning Best Practices -summary: TiDB パフォーマンスをチューニングするためのベスト プラクティスを紹介します。 +summary: TiDB パフォーマンスをチューニングするためのベストプラクティスを紹介します。 aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-best-practices/','/ja/tidbcloud/dev-guide-optimize-sql-best-practices/'] --- # 性能チューニングのベストプラクティス {#performance-tuning-best-practices} -このドキュメントでは、TiDB データベースの使用に関するベスト プラクティスをいくつか紹介します。 +このドキュメントでは、TiDB データベースの使用に関するベストプラクティスをいくつか紹介します。 ## DMLのベストプラクティス {#dml-best-practices} -このセクションでは、TiDB で DML を使用する場合のベスト プラクティスについて説明します。 +このセクションでは、TiDB で DML を使用する場合のベストプラクティスについて説明します。 ### 複数行のステートメントを使用する {#use-multi-row-statements} @@ -119,7 +119,7 @@ DELETE FROM t; ## DDLのベストプラクティス {#ddl-best-practices} -このセクションでは、TiDB の DDL を使用する際のベスト プラクティスについて説明します。 +このセクションでは、TiDB の DDL を使用する際のベストプラクティスについて説明します。 ### 主キーのベストプラクティス {#primary-key-best-practices} @@ -154,9 +154,9 @@ SET @@global.tidb_ddl_reorg_batch_size = 128; トランザクションの競合を見つけて解決する方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)を参照してください。 -## TiDB を使用したJavaアプリケーション開発のベスト プラクティス {#best-practices-for-developing-java-applications-with-tidb} +## TiDB を使用したJavaアプリケーション開発のベストプラクティス {#best-practices-for-developing-java-applications-with-tidb} -[TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md)参照。 +[TiDB を使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md)参照。 ### 参照 {#see-also} diff --git a/develop/dev-guide-optimize-sql-overview.md b/develop/dev-guide-optimize-sql-overview.md index 02747fca19a96..551d9cafa1944 100644 --- a/develop/dev-guide-optimize-sql-overview.md +++ b/develop/dev-guide-optimize-sql-overview.md @@ -1,6 +1,6 @@ --- title: Overview of Optimizing SQL Performance -summary: TiDB アプリケーション開発者向けに、SQL パフォーマンス チューニングの概要を説明します。 +summary: TiDB アプリケーション開発者向けに、SQL パフォーマンスチューニングの概要を説明します。 aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev-guide-optimize-sql-overview/'] --- @@ -9,7 +9,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev- このドキュメントでは、TiDBにおけるSQL文のパフォーマンスを最適化する方法を紹介します。良好なパフォーマンスを得るには、まず以下の点に着目してください。 - SQLパフォーマンスチューニング -- スキーマ設計: アプリケーションのワークロード パターンに基づいて、トランザクションの競合やホット スポットを回避するためにテーブル スキーマを変更する必要がある場合があります。 +- スキーマ設計: アプリケーションのワークロードパターンに基づいて、トランザクションの競合やホットスポットを回避するためにテーブルスキーマを変更する必要がある場合があります。 ## SQLパフォーマンスチューニング {#sql-performance-tuning} @@ -22,7 +22,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev- ## スキーマ設計 {#schema-design} -[SQLパフォーマンスのチューニング](#sql-performance-tuning)後もアプリケーションのパフォーマンスがまだ良好でない場合は、次の問題を回避するためにスキーマ設計とデータ アクセス パターンを確認する必要がある可能性があります。 +[SQLパフォーマンスのチューニング](#sql-performance-tuning)後もアプリケーションのパフォーマンスがまだ良好でない場合は、次の問題を回避するためにスキーマ設計とデータアクセス パターンを確認する必要がある可能性があります。 - トランザクションの競合。トランザクションの競合を診断して解決する方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)を参照してください。 - ホットスポット。ホットスポットの診断と解決方法については、 [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)を参照してください。 diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index c9e3ceebaea07..7c78f499e9ce5 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -1,6 +1,6 @@ --- title: SQL Performance Tuning -summary: TiDB の SQL パフォーマンス チューニング スキームと分析アプローチを紹介します。 +summary: TiDB の SQL パフォーマンスチューニング スキームと分析アプローチを紹介します。 aliases: ['/ja/tidb/stable/dev-guide-optimize-sql/','/ja/tidbcloud/dev-guide-optimize-sql/'] --- @@ -16,13 +16,13 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql/','/ja/tidbcloud/dev-guide-opt tiup demo bookshop prepare --host 127.0.0.1 --port 4000 --books 1000000 ``` -または、事前に準備されたサンプル データをインポートする場合は[TiDB Cloudのインポート機能を使用する](/develop/dev-guide-bookshop-schema-design.md#tidb-cloud-via-the-import-feature) 。 +または、事前に準備されたサンプルデータをインポートする場合は[TiDB Cloudのインポート機能を使用する](/develop/dev-guide-bookshop-schema-design.md#tidb-cloud-via-the-import-feature) 。 ## 問題: テーブル全体のスキャン {#issue-full-table-scan} -SQL クエリが遅くなる最も一般的な理由は、 `SELECT`ステートメントが完全なテーブル スキャンを実行するか、間違ったインデックスを使用することです。 +SQL クエリが遅くなる最も一般的な理由は、 `SELECT`ステートメントが完全なテーブルスキャンを実行するか、間違ったインデックスを使用することです。 -TiDB が主キーではない列またはセカンダリ インデックス内の列に基づいて大規模なテーブルから少数の行を取得する場合、通常はパフォーマンスが低下します。 +TiDB が主キーではない列またはセカンダリインデックス内の列に基づいて大規模なテーブルから少数の行を取得する場合、通常はパフォーマンスが低下します。 ```sql SELECT * FROM books WHERE title = 'Marian Yost'; @@ -64,7 +64,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; ### 解決策: セカンダリインデックスを使用する {#solution-use-secondary-index} -上記のクエリを高速化するには、 `books.title`列にセカンダリ インデックスを追加します。 +上記のクエリを高速化するには、 `books.title`列にセカンダリインデックスを追加します。 ```sql CREATE INDEX title_idx ON books (title); @@ -108,13 +108,13 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; 実行計画の`IndexLookup_10`からわかるように、TiDBは`title_idx`インデックスを使ってデータをクエリします。`estRows`の値は`1.27`です。これは、オプティマイザが`1.27`行しかスキャンされないと見積もっていることを意味します。推定されるスキャン行数は、フルテーブルスキャンの`1000000.00`行のデータよりもはるかに少ないです。 -実行計画`IndexLookup_10`では、まず`IndexRangeScan_8`演算子を使用して`title_idx`インデックスを通じて条件を満たすインデックス データを読み取り、次に`TableLookup_9`演算子を使用して、インデックス データに格納されている行 ID に従って対応する行をクエリします。 +実行計画`IndexLookup_10`では、まず`IndexRangeScan_8`演算子を使用して`title_idx`インデックスを通じて条件を満たすインデックスデータを読み取り、次に`TableLookup_9`演算子を使用して、インデックスデータに格納されている行 ID に従って対応する行をクエリします。 TiDB 実行計画の詳細については、 [TiDB クエリ実行計画の概要](/explain-overview.md)を参照してください。 ### 解決策: カバリングインデックスを使用する {#solution-use-covering-index} -インデックスが、SQL ステートメントによってクエリされるすべての列を含むカバーリング インデックスである場合は、インデックス データをスキャンするだけでクエリに十分です。 +インデックスが、SQL ステートメントによってクエリされるすべての列を含むカバーリング インデックスである場合は、インデックスデータをスキャンするだけでクエリに十分です。 たとえば、次のクエリでは、 `title`に基づいて対応する`price`クエリするだけで済みます。 @@ -136,7 +136,7 @@ SELECT title, price FROM books WHERE title = 'Marian Yost'; Time: 0.007s ``` -`title_idx`インデックスには`title`列のデータのみが含まれているため、TiDB は最初にインデックス データをスキャンし、次にテーブルから`price`列をクエリする必要があります。 +`title_idx`インデックスには`title`列のデータのみが含まれているため、TiDB は最初にインデックスデータをスキャンし、次にテーブルから`price`列をクエリする必要があります。 ```sql EXPLAIN SELECT title, price FROM books WHERE title = 'Marian Yost'; @@ -162,7 +162,7 @@ ALTER TABLE books DROP INDEX title_idx; CREATE INDEX title_price_idx ON books (title, price); ``` -`price`データは`title_price_idx`インデックスに格納されているため、次のクエリではインデックス データのスキャンのみが必要です。 +`price`データは`title_price_idx`インデックスに格納されているため、次のクエリではインデックスデータのスキャンのみが必要です。 ```sql EXPLAIN SELECT title, price FROM books WHERE title = 'Marian Yost'; diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 696d3953d4b48..4a7c9e5a58e3e 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -214,7 +214,7 @@ pageMetaList.forEach((pageMeta) -> { ### 非クラスター化インデックステーブル {#non-clustered-index-table} -非クラスター化インデックス テーブル (「非インデックス構成テーブル」とも呼ばれます) の場合、内部フィールド`_tidb_rowid`ページ区切りキーとして使用でき、ページ区切りの方法は単一フィールドの主キー テーブルの場合と同じです。 +非クラスター化インデックステーブル (「非インデックス構成テーブル」とも呼ばれます) の場合、内部フィールド`_tidb_rowid`ページ区切りキーとして使用でき、ページ区切りの方法は単一フィールドの主キー テーブルの場合と同じです。 > **Tip:** > @@ -258,7 +258,7 @@ ORDER BY page_num; ### クラスター化インデックステーブル {#clustered-index-table} -クラスター化インデックス テーブル (「インデックス構成テーブル」とも呼ばれます) の場合、 `concat`関数を使用して複数の列の値をキーとして連結し、ウィンドウ関数を使用してページング情報を照会できます。 +クラスター化インデックステーブル (「インデックス構成テーブル」とも呼ばれます) の場合、 `concat`関数を使用して複数の列の値をキーとして連結し、ウィンドウ関数を使用してページング情報を照会できます。 この時点ではキーは文字列であり、 `min`と`max`集約関数を介したスライスで正しい`start_key`と`end_key`を取得するには、文字列の長さが常に一定であることを確認する必要があります。文字列連結のフィールドの長さが固定でない場合は、 `LPAD`関数を使用してパディングすることができます。 diff --git a/develop/dev-guide-playground-gitpod.md b/develop/dev-guide-playground-gitpod.md index 63a67f09c08c9..d0441e5ef15e8 100644 --- a/develop/dev-guide-playground-gitpod.md +++ b/develop/dev-guide-playground-gitpod.md @@ -14,9 +14,9 @@ Gitpodは、コードを直接記述する開発環境向けのオープンソ ## クイックスタート {#quick-start} -1. TiDB アプリケーション開発用のサンプル コード リポジトリ[pingcap-inc/tidb-example-java](https://github.com/pingcap-inc/tidb-example-java)をフォークします。 +1. TiDB アプリケーション開発用のサンプルコード リポジトリ[pingcap-inc/tidb-example-java](https://github.com/pingcap-inc/tidb-example-java)をフォークします。 -2. ブラウザのアドレスバーでサンプル コード リポジトリの URL の前に`https://gitpod.io/#`付けて、Gitpod ワークスペースを起動します。 +2. ブラウザのアドレスバーでサンプルコード リポジトリの URL の前に`https://gitpod.io/#`付けて、Gitpod ワークスペースを起動します。 - たとえば、 `https://gitpod.io/#https://github.com/pingcap-inc/tidb-example-java` 。 @@ -46,7 +46,7 @@ TiDB Playground の準備が完了すると、さらに`Spring JPA Hibernate`タ ### Gitpodの設定をカスタマイズする {#customize-gitpod-configurations} -[例.gitpod.yml](https://github.com/pingcap-inc/tidb-example-java/blob/main/.gitpod.yml)を参照して、プロジェクトのルート ディレクトリに`.gitpod. yml`ファイルを作成し、Gitpod ワークスペースを構成します。 +[例.gitpod.yml](https://github.com/pingcap-inc/tidb-example-java/blob/main/.gitpod.yml)を参照して、プロジェクトのルートディレクトリに`.gitpod. yml`ファイルを作成し、Gitpod ワークスペースを構成します。 ```yml # This configuration file was automatically generated by Gitpod. diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index 01ce9180c85a8..d336f7a8ad146 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -730,7 +730,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > - `password` : TiDB パスワード。 > - `active` : ユーザーがアクティブかどうかを制御します。 `1`ユーザーが**アクティブ**でログインに使用できることを示し、 `0`はユーザーが非アクティブであることを示します。 > - `default_hostgroup` : ユーザーが使用するデフォルトのホストグループ。クエリ ルールがトラフィックを特定のホストグループに上書きしない限り、SQL トラフィックはこのホストグループに分散されます。 - > - `transaction_persistent` : `1`は、永続的なトランザクションを示します。ユーザーが接続内でトランザクションを開始すると、トランザクションがコミットまたはロールバックされるまで、すべてのクエリ ステートメントは同じホスト グループにルーティングされます。 + > - `transaction_persistent` : `1`は、永続的なトランザクションを示します。ユーザーが接続内でトランザクションを開始すると、トランザクションがコミットまたはロールバックされるまで、すべてのクエリステートメントは同じホスト グループにルーティングされます。 ##### オプション2：設定ファイルを使用してProxySQLを設定する {#option-2-configure-proxysql-using-a-configuration-file} diff --git a/develop/dev-guide-sample-application-aws-lambda.md b/develop/dev-guide-sample-application-aws-lambda.md index c9bde4a486316..d15ec3e740de5 100644 --- a/develop/dev-guide-sample-application-aws-lambda.md +++ b/develop/dev-guide-sample-application-aws-lambda.md @@ -131,8 +131,7 @@ npm install - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. 対応する接続​​文字列をコピーして`env.json`に貼り付けてください。以下に例を示します。 ```json diff --git a/develop/dev-guide-sample-application-golang-gorm.md b/develop/dev-guide-sample-application-golang-gorm.md index fdcba8a68fb1b..f1e17f63fd6ca 100644 --- a/develop/dev-guide-sample-application-golang-gorm.md +++ b/develop/dev-guide-sample-application-golang-gorm.md @@ -118,8 +118,7 @@ cd tidb-golang-gorm-quickstart - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -152,7 +151,7 @@ cd tidb-golang-gorm-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-golang-sql-driver.md b/develop/dev-guide-sample-application-golang-sql-driver.md index c73090afbddc9..ed7411c501d27 100644 --- a/develop/dev-guide-sample-application-golang-sql-driver.md +++ b/develop/dev-guide-sample-application-golang-sql-driver.md @@ -118,8 +118,7 @@ cd tidb-golang-sql-driver-quickstart - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -152,7 +151,7 @@ cd tidb-golang-sql-driver-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 871b6881f1e5c..2b228b4c99685 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -119,8 +119,7 @@ cd tidb-java-hibernate-quickstart - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -153,7 +152,7 @@ cd tidb-java-hibernate-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-java-jdbc.md b/develop/dev-guide-sample-application-java-jdbc.md index 0c399d005e3c3..4152f54e3c6f5 100644 --- a/develop/dev-guide-sample-application-java-jdbc.md +++ b/develop/dev-guide-sample-application-java-jdbc.md @@ -121,8 +121,7 @@ cd tidb-java-jdbc-quickstart - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -156,7 +155,7 @@ cd tidb-java-jdbc-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-java-mybatis.md b/develop/dev-guide-sample-application-java-mybatis.md index 33f352105c833..812d41d45d44d 100644 --- a/develop/dev-guide-sample-application-java-mybatis.md +++ b/develop/dev-guide-sample-application-java-mybatis.md @@ -119,8 +119,7 @@ cd tidb-java-mybatis-quickstart - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -153,7 +152,7 @@ cd tidb-java-mybatis-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-java-spring-boot.md b/develop/dev-guide-sample-application-java-spring-boot.md index 0f2e57480e13d..92430e7ecf582 100644 --- a/develop/dev-guide-sample-application-java-spring-boot.md +++ b/develop/dev-guide-sample-application-java-spring-boot.md @@ -119,8 +119,7 @@ cd tidb-java-springboot-jpa-quickstart - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -153,7 +152,7 @@ cd tidb-java-springboot-jpa-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-nextjs.md b/develop/dev-guide-sample-application-nextjs.md index abb745acbe394..ae85e88891b34 100644 --- a/develop/dev-guide-sample-application-nextjs.md +++ b/develop/dev-guide-sample-application-nextjs.md @@ -136,8 +136,7 @@ npm install - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```bash diff --git a/develop/dev-guide-sample-application-nodejs-mysql2.md b/develop/dev-guide-sample-application-nodejs-mysql2.md index 2704cf5c252f1..ee3e635dc31c1 100644 --- a/develop/dev-guide-sample-application-nodejs-mysql2.md +++ b/develop/dev-guide-sample-application-nodejs-mysql2.md @@ -125,8 +125,7 @@ npm install mysql2 dotenv --save - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -157,7 +156,7 @@ npm install mysql2 dotenv --save IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -277,7 +276,7 @@ void main(); > **Note** > -> TiDB Cloud StarterおよびTiDB Cloud Essentialでは、パブリック エンドポイントを使用する場合、 `TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。ただし、Node.js はデフォルトで組み込みの Mozilla CA を使用するため、 `TIDB_CA_PATH`を介して SSL CA 証明書を指定する必要はありません。この組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)はTiDB Cloud Starterによって信頼されています。 +> TiDB Cloud StarterおよびTiDB Cloud Essentialでは、パブリックエンドポイントを使用する場合、 `TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。ただし、Node.js はデフォルトで組み込みの Mozilla CA を使用するため、 `TIDB_CA_PATH`を介して SSL CA 証明書を指定する必要はありません。この組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)はTiDB Cloud Starterによって信頼されています。 ### データを挿入する {#insert-data} @@ -337,7 +336,7 @@ console.log(rsh.affectedRows); ## 次のステップ {#next-steps} - node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://github.com/sidorares/node-mysql2#readme)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-mysqljs.md b/develop/dev-guide-sample-application-nodejs-mysqljs.md index 1bbef7a9fca2a..ca95f2bc9bda1 100644 --- a/develop/dev-guide-sample-application-nodejs-mysqljs.md +++ b/develop/dev-guide-sample-application-nodejs-mysqljs.md @@ -125,8 +125,7 @@ npm install mysql dotenv --save - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -157,7 +156,7 @@ npm install mysql dotenv --save IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -273,7 +272,7 @@ conn.end(); > **Note** > -> TiDB Cloud StarterおよびTiDB Cloud Essentialでは、パブリック エンドポイントを使用する場合、 `TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。ただし、Node.js はデフォルトで組み込みの Mozilla CA を使用するため、 `TIDB_CA_PATH`を介して SSL CA 証明書を指定する必要はありません。この組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)はTiDB Cloud Starterによって信頼されています。 +> TiDB Cloud StarterおよびTiDB Cloud Essentialでは、パブリックエンドポイントを使用する場合、 `TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。ただし、Node.js はデフォルトで組み込みの Mozilla CA を使用するため、 `TIDB_CA_PATH`を介して SSL CA 証明書を指定する必要はありません。この組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)はTiDB Cloud Starterによって信頼されています。 ### データを挿入する {#insert-data} @@ -351,7 +350,7 @@ conn.query('DELETE FROM players WHERE id = ?;', [1], (err, ok) => { > **Note** > - > `mysqljs/mysql`パッケージはまだプリペアド ステートメントをサポートしておらず、クライアント側で値をエスケープするだけです (関連する問題:[mysqljs/mysql#274](https://github.com/mysqljs/mysql/issues/274) )。 + > `mysqljs/mysql`パッケージはまだプリペアドステートメントをサポートしておらず、クライアント側で値をエスケープするだけです (関連する問題:[mysqljs/mysql#274](https://github.com/mysqljs/mysql/issues/274) )。 > > SQLインジェクション攻撃を回避したり、バッチ挿入/更新の効率を向上させたりするためにこの機能を使用したい場合は、代わりに[mysql2](https://github.com/sidorares/node-mysql2)パッケージを使用することをお勧めします。 @@ -362,7 +361,7 @@ conn.query('DELETE FROM players WHERE id = ?;', [1], (err, ok) => { ## 次のステップ {#next-steps} - mysql.js ドライバーの使用方法の詳細については[mysql.jsのドキュメント](https://github.com/mysqljs/mysql#readme)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-prisma.md b/develop/dev-guide-sample-application-nodejs-prisma.md index 4e08d283337c4..bfd5815e3ea9c 100644 --- a/develop/dev-guide-sample-application-nodejs-prisma.md +++ b/develop/dev-guide-sample-application-nodejs-prisma.md @@ -129,8 +129,7 @@ npm install prisma typescript ts-node @types/node --save-dev - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -165,7 +164,7 @@ npm install prisma typescript ts-node @types/node --save-dev IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -227,7 +226,7 @@ npm install prisma typescript ts-node @types/node --save-dev ### ステップ4．データベーススキーマを初期化する {#step-4-initialize-the-database-schema} -次のコマンドを実行して[Prisma Migrate](https://www.prisma.io/docs/concepts/components/prisma-migrate)を呼び出し、 `prisma/prisma.schema`で定義されたデータ モデルでデータベースを初期化します。 +次のコマンドを実行して[Prisma Migrate](https://www.prisma.io/docs/concepts/components/prisma-migrate)を呼び出し、 `prisma/prisma.schema`で定義されたデータモデルでデータベースを初期化します。 ```shell npx prisma migrate dev @@ -260,7 +259,7 @@ model Profile { } ``` -Prisma でデータ モデルを定義する方法については、データモデル[データモデル](https://www.prisma.io/docs/concepts/components/prisma-schema/data-model)ドキュメントを確認してください。 +Prisma でデータモデルを定義する方法については、データモデル[データモデル](https://www.prisma.io/docs/concepts/components/prisma-schema/data-model)ドキュメントを確認してください。 **期待される実行出力:** @@ -404,7 +403,7 @@ await prisma.player.delete({ ## 次のステップ {#next-steps} - ORM フレームワーク Prisma ドライバーの使用方法の詳細については[Prismaのドキュメント](https://www.prisma.io/docs)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-sequelize.md b/develop/dev-guide-sample-application-nodejs-sequelize.md index 95f73fd513c41..05f7fe109d62c 100644 --- a/develop/dev-guide-sample-application-nodejs-sequelize.md +++ b/develop/dev-guide-sample-application-nodejs-sequelize.md @@ -128,8 +128,7 @@ npm install - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -161,7 +160,7 @@ npm install IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-nodejs-typeorm.md b/develop/dev-guide-sample-application-nodejs-typeorm.md index 9e24c7f70b474..ba536bac8d304 100644 --- a/develop/dev-guide-sample-application-nodejs-typeorm.md +++ b/develop/dev-guide-sample-application-nodejs-typeorm.md @@ -109,7 +109,7 @@ npm install @types/node ts-node typescript --save-dev > **Note** > - > TiDB Cloud StarterおよびTiDB Cloud Essentialの場合、パブリック エンドポイントを使用する際には`TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 + > TiDB Cloud StarterおよびTiDB Cloud Essentialの場合、パブリックエンドポイントを使用する際には`TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 7. `.env`ファイルを保存します。 @@ -133,8 +133,7 @@ npm install @types/node ts-node typescript --save-dev - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -165,7 +164,7 @@ npm install @types/node ts-node typescript --save-dev IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -396,7 +395,7 @@ export class ActionLog { ## 次のステップ {#next-steps} - TypeORM の使用法の詳細については[TypeORMのドキュメント](https://typeorm.io/)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-django.md b/develop/dev-guide-sample-application-python-django.md index 6c56f44c9ae36..a50d42e6a2eca 100644 --- a/develop/dev-guide-sample-application-python-django.md +++ b/develop/dev-guide-sample-application-python-django.md @@ -136,8 +136,7 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -169,7 +168,7 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-python-mysql-connector.md b/develop/dev-guide-sample-application-python-mysql-connector.md index 26658e6186bfc..6bfcd5aa8bea1 100644 --- a/develop/dev-guide-sample-application-python-mysql-connector.md +++ b/develop/dev-guide-sample-application-python-mysql-connector.md @@ -124,8 +124,7 @@ pip install -r requirements.txt - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -157,7 +156,7 @@ pip install -r requirements.txt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-python-mysqlclient.md b/develop/dev-guide-sample-application-python-mysqlclient.md index 5d978cd16dd32..16ce686dc9e76 100644 --- a/develop/dev-guide-sample-application-python-mysqlclient.md +++ b/develop/dev-guide-sample-application-python-mysqlclient.md @@ -128,8 +128,7 @@ pip install -r requirements.txt - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -162,7 +161,7 @@ pip install -r requirements.txt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-python-peewee.md b/develop/dev-guide-sample-application-python-peewee.md index f91d812c9594b..719e0e19dd57c 100644 --- a/develop/dev-guide-sample-application-python-peewee.md +++ b/develop/dev-guide-sample-application-python-peewee.md @@ -128,8 +128,7 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -161,7 +160,7 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-python-pymysql.md b/develop/dev-guide-sample-application-python-pymysql.md index 3af1a0ed77a95..1b4c2b8d3d398 100644 --- a/develop/dev-guide-sample-application-python-pymysql.md +++ b/develop/dev-guide-sample-application-python-pymysql.md @@ -124,8 +124,7 @@ pip install -r requirements.txt - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -157,7 +156,7 @@ pip install -r requirements.txt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md index bf4e4ebdbcd50..442f579cb2ea7 100644 --- a/develop/dev-guide-sample-application-python-sqlalchemy.md +++ b/develop/dev-guide-sample-application-python-sqlalchemy.md @@ -134,8 +134,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -167,7 +166,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index b9dda274c9687..0a4d03a71f31d 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -102,7 +102,7 @@ bundle add mysql2 dotenv > **Note** > - > [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリック エンドポイントを使用する際には`DATABASE_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 + > [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリックエンドポイントを使用する際には`DATABASE_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 7. `.env`ファイルを保存します。 @@ -126,8 +126,7 @@ bundle add mysql2 dotenv - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -158,7 +157,7 @@ bundle add mysql2 dotenv IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -262,7 +261,7 @@ client = Mysql2::Client.new(options) > **Note** > -> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリック エンドポイントを使用する際には`DATABASE_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**が、mysql2 gem が特定の順序で既存の CA 証明書を検索してファイルが見つかるまで検索するため、 `DATABASE_SSL_CA`を介して SSL CA 証明書を指定する必要はありません。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリックエンドポイントを使用する際には`DATABASE_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**が、mysql2 gem が特定の順序で既存の CA 証明書を検索してファイルが見つかるまで検索するため、 `DATABASE_SSL_CA`を介して SSL CA 証明書を指定する必要はありません。 ### データを挿入する {#insert-data} @@ -338,7 +337,7 @@ CA証明書のパスを手動で指定することも可能ですが、異なる ## 次のステップ {#next-steps} - mysql2 ドライバーの使用方法の詳細については[mysql2のドキュメント](https://github.com/brianmario/mysql2#readme)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index a9b3ccede7bdb..f25f29c9c55ae 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -116,8 +116,7 @@ bundle add mysql2 dotenv - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - まだパスワードを設定していない場合は、ダイアログの**ルートパスワードを設定**をクリックしてください。 - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA証明書**をクリックしてダウンロードしてください。 - - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベート エンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 - + - **パブリック**接続タイプに加えて、 TiDB Cloud Premium は**プライベートエンドポイント**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell @@ -143,7 +142,7 @@ bundle add mysql2 dotenv IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベートエンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -251,7 +250,7 @@ production: > **Note** > -> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリック エンドポイントを使用する際には**、** `ssl_mode`の`verify_identity`クエリ パラメータを`DATABASE_URL`に設定して TLS 接続を有効にする必要がありますが、mysql2 gem が特定の順序で既存の CA 証明書を検索してファイルが見つかるまで検索するため、 `DATABASE_URL`を介して SSL CA 証明書を指定する必要**はあり**ません。 +> [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリックエンドポイントを使用する際には**、** `ssl_mode`の`verify_identity`クエリパラメータを`DATABASE_URL`に設定して TLS 接続を有効にする必要がありますが、mysql2 gem が特定の順序で既存の CA 証明書を検索してファイルが見つかるまで検索するため、 `DATABASE_URL`を介して SSL CA 証明書を指定する必要**はあり**ません。 ### データを挿入する {#insert-data} @@ -307,7 +306,7 @@ CA証明書のパスを手動で指定することも可能ですが、異なる ## 次のステップ {#next-steps} - ActiveRecord ORM の使用法について詳しくは[ActiveRecordのドキュメント](https://guides.rubyonrails.org/active_record_basics.html)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベストプラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index eb2e814dbfdc4..5ac5844c8e8d6 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -48,7 +48,7 @@ TiDBには`test`という名前のデフォルトデータベースが付属し #### 専門索引 {#specialized-indexes} -さまざまなユーザー シナリオのクエリ パフォーマンスを向上させるために、TiDB はいくつかの特殊なタイプのインデックスを提供します。各タイプの詳細については、[インデックスと制約](/basic-features.md#indexing-and-constraints)を参照してください。 +さまざまなユーザーシナリオのクエリパフォーマンスを向上させるために、TiDB はいくつかの特殊なタイプのインデックスを提供します。各タイプの詳細については、[インデックスと制約](/basic-features.md#indexing-and-constraints)を参照してください。 ### その他のサポートされている論理オブジェクト {#other-supported-logical-objects} @@ -60,7 +60,7 @@ TiDBは、**テーブル**と同じレベルで以下の論理オブジェクト ## アクセス制御 {#access-control} -TiDB は、ユーザーベースとロールベースの両方のアクセス制御をサポートします。ユーザーがデータ オブジェクトおよびデータ スキーマを表示、変更、または削除できるようにするには、[ユーザー](/user-account-management.md)に直接[権限](/privilege-management.md)付与するか、[役割](/role-based-access-control.md)を通じて[権限](/privilege-management.md)ユーザーに付与します。 +TiDB は、ユーザーベースとロールベースの両方のアクセス制御をサポートします。ユーザーがデータオブジェクトおよびデータ スキーマを表示、変更、または削除できるようにするには、[ユーザー](/user-account-management.md)に直接[権限](/privilege-management.md)付与するか、[役割](/role-based-access-control.md)を通じて[権限](/privilege-management.md)ユーザーに付与します。 ## データベーススキーマの変更 {#database-schema-changes} diff --git a/develop/dev-guide-third-party-support.md b/develop/dev-guide-third-party-support.md index 9b89ee34c5a23..12039571bd46c 100644 --- a/develop/dev-guide-third-party-support.md +++ b/develop/dev-guide-third-party-support.md @@ -1,10 +1,10 @@ --- title: Third-Party Tools Supported by TiDB -summary: TiDB でサポートされているサードパーティ ツールについて説明します。 +summary: TiDB でサポートされているサードパーティツールについて説明します。 aliases: ['/ja/tidb/stable/dev-guide-third-party-support/','/ja/tidb/dev/dev-guide-third-party-support/','/ja/tidbcloud/dev-guide-third-party-support/'] --- -# TiDB でサポートされているサードパーティ ツール {#third-party-tools-supported-by-tidb} +# TiDB でサポートされているサードパーティツール {#third-party-tools-supported-by-tidb} > **Note:** > @@ -14,7 +14,7 @@ TiDB は[MySQLプロトコルとの高い互換性](/mysql-compatibility.md)あ ## サポートレベル {#support-level} -PingCAP はコミュニティと連携し、サードパーティ ツールに対して次のサポート レベルを提供します。 +PingCAP はコミュニティと連携し、サードパーティツールに対して次のサポート レベルを提供します。 - ***完全***：TiDB は対応するサードパーティ製ツールのほとんどの機能と既に互換性があり、最新バージョンとの互換性も維持していることを示します。PingCAP は、ツールの最新バージョンとの互換性テストを定期的に実施します。 - ***互換***：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index d2a87e2267dc6..534f622dd3a5a 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -1,6 +1,6 @@ --- title: Known Incompatibility Issues with Third-Party Tools -summary: テスト中に発見されたサードパーティ ツールとの TiDB 互換性の問題について説明します。 +summary: テスト中に発見されたサードパーティツールとの TiDB 互換性の問題について説明します。 aliases: ['/ja/tidb/stable/dev-guide-third-party-tools-compatibility/','/ja/tidbcloud/dev-guide-third-party-tools-compatibility/'] --- diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md index 0b7d2b2ab7b52..7b693c44dff3f 100644 --- a/develop/dev-guide-timeouts-in-tidb.md +++ b/develop/dev-guide-timeouts-in-tidb.md @@ -29,7 +29,7 @@ TiDBのトランザクション実装では、MVCC（Multiple Version Concurrenc > **Tip:** > -> 具体的には、 Dumplingが TiDB (1 TB 未満) からデータをエクスポートする際に、TiDB のバージョンが v4.0.0 以降であり、 Dumpling がTiDB クラスターの PD アドレスと[`INFORMATION_SCHEMA.CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md)テーブルにアクセスできる場合、 Dumpling はGC セーフ ポイントを自動的に調整して、元のクラスターに影響を与えずに GC をブロックします。 +> 具体的には、 Dumplingが TiDB (1 TB 未満) からデータをエクスポートする際に、TiDB のバージョンが v4.0.0 以降であり、 Dumpling がTiDB クラスターの PD アドレスと[`INFORMATION_SCHEMA.CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md)テーブルにアクセスできる場合、 Dumpling はGC セーフポイントを自動的に調整して、元のクラスターに影響を与えずに GC をブロックします。 > > ただし、次のいずれかのシナリオでは、 Dumpling はGC 時間を自動的に調整できません。 > @@ -56,7 +56,7 @@ TiDB には、単一の SQL 文の実行時間を制限するシステム変数 ## JDBCクエリタイムアウト {#jdbc-query-timeout} -v6.1.0 以降では、 [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610)構成項目がデフォルト値`true`に設定されている場合、MySQL JDBC によって提供される`setQueryTimeout()`メソッドを使用してクエリ タイムアウトを制御できます。 +v6.1.0 以降では、 [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610)構成項目がデフォルト値`true`に設定されている場合、MySQL JDBC によって提供される`setQueryTimeout()`メソッドを使用してクエリタイムアウトを制御できます。 > **Note:** > diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 5d8d7145fb957..d8243faf69bac 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -19,7 +19,7 @@ BobはAliceに20ドルを送金したいと考えています。このトラン トランザクションにより、上記の操作の両方が正常に実行されるか、または両方とも失敗するかを確認できます。 -[書店](/develop/dev-guide-bookshop-schema-design.md)データベースの`users`テーブルを使用して、テーブルにいくつかのサンプル データを挿入します。 +[書店](/develop/dev-guide-bookshop-schema-design.md)データベースの`users`テーブルを使用して、テーブルにいくつかのサンプルデータを挿入します。 ```sql INSERT INTO users (id, nickname, balance) diff --git a/develop/dev-guide-transaction-troubleshoot.md b/develop/dev-guide-transaction-troubleshoot.md index f1912d05ff1c7..7dc04bbda12d3 100644 --- a/develop/dev-guide-transaction-troubleshoot.md +++ b/develop/dev-guide-transaction-troubleshoot.md @@ -1,12 +1,12 @@ --- title: Handle Transaction Errors -summary: デッドロックやアプリケーション再試行エラーなどのトランザクション エラーを処理する方法について学習します。 +summary: デッドロックやアプリケーション再試行エラーなどのトランザクションエラーを処理する方法について学習します。 aliases: ['/ja/tidb/stable/dev-guide-transaction-troubleshoot/','/ja/tidbcloud/dev-guide-transaction-troubleshoot/'] --- # トランザクションエラーの処理 {#handle-transaction-errors} -このドキュメントでは、デッドロックやアプリケーションの再試行エラーなどのトランザクション エラーを処理する方法について説明します。 +このドキュメントでは、デッドロックやアプリケーションの再試行エラーなどのトランザクションエラーを処理する方法について説明します。 ## デッドロック {#deadlocks} @@ -26,7 +26,7 @@ ERROR 1213: Deadlock found when trying to get lock; try restarting transaction 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 | | --------------------------------------------------------- | ------------------------------------------------------------- | @@ -78,7 +78,7 @@ TiDBはMySQLと可能な限り互換性がありますが、分散システム 開発者がデータベース接続に使用するアダプタとORMは、MySQLやOracleといった従来のデータベース向けにカスタマイズされています。これらのデータベースでは、デフォルトの分離レベルではトランザクションのコミットが失敗することはほとんどないため、再試行メカニズムは必要ありません。トランザクションのコミットが失敗すると、これらのデータベースでは例外として扱われるため、クライアントはエラーとして処理を中止します。 -MySQL などの従来のデータベースとは異なり、TiDB では、楽観的トランザクション モデルを使用してコミットの失敗を回避する場合、アプリケーションで関連する例外を処理するメカニズムを追加する必要があります。 +MySQL などの従来のデータベースとは異なり、TiDB では、楽観的トランザクションモデルを使用してコミットの失敗を回避する場合、アプリケーションで関連する例外を処理するメカニズムを追加する必要があります。 以下のPython擬似コードは、アプリケーションレベルの再試行を実装する方法を示しています。ドライバーやORMに高度な再試行ロジックを実装する必要はありません。あらゆるプログラミング言語や環境で使用できます。 @@ -88,11 +88,11 @@ MySQL などの従来のデータベースとは異なり、TiDB では、楽観 - SQL実行例外をキャッチするには`try ... catch ...`を使用します。以下のエラーが発生した場合は再試行してください。その他のエラーが発生した場合はロールバックしてください。 - `Error 8002: can not retry select for update statement` : SELECT FOR UPDATE 書き込み競合エラー - `Error 8022: Error: KV error safe to retry` : トランザクションのコミットに失敗したエラー。 - - `Error 8028: Information schema is changed during the execution of the statement` : DDL 操作によってテーブル スキーマが変更され、トランザクションのコミットでエラーが発生しました。 - - `Error 9007: Write conflict` : 書き込み競合エラー。通常、楽観的トランザクション モードが使用されているときに、複数のトランザクションが同じデータ行を変更することによって発生します。 + - `Error 8028: Information schema is changed during the execution of the statement` : DDL 操作によってテーブルスキーマが変更され、トランザクションのコミットでエラーが発生しました。 + - `Error 9007: Write conflict` : 書き込み競合エラー。通常、楽観的トランザクションモードが使用されているときに、複数のトランザクションが同じデータ行を変更することによって発生します。 - try ブロックの最後にあるトランザクションを`COMMIT` 。 -エラー コードの詳細については、 [エラーコードとトラブルシューティング](/error-codes.md)を参照してください。 +エラーコードの詳細については、 [エラーコードとトラブルシューティング](/error-codes.md)を参照してください。 ```python while True: @@ -118,7 +118,7 @@ while True: > **Note:** > -> `Error 9007: Write conflict`頻繁に発生する場合は、スキーマ設計とワークロードのデータ アクセス パターンを確認して競合の根本原因を特定し、設計を改善して競合を回避する必要があります。 +> `Error 9007: Write conflict`頻繁に発生する場合は、スキーマ設計とワークロードのデータアクセス パターンを確認して競合の根本原因を特定し、設計を改善して競合を回避する必要があります。 トランザクションの競合のトラブルシューティングと解決方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)を参照してください。 diff --git a/develop/dev-guide-troubleshoot-overview.md b/develop/dev-guide-troubleshoot-overview.md index de7c65588aa53..73cd37fdf654d 100644 --- a/develop/dev-guide-troubleshoot-overview.md +++ b/develop/dev-guide-troubleshoot-overview.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-troubleshoot-overview/','/ja/tidbcloud/dev- ## SQLクエリの問題のトラブルシューティング {#troubleshoot-sql-query-problems} -SQL クエリのパフォーマンスを向上させる場合は、 [SQL性能チューニング](/develop/dev-guide-optimize-sql-overview.md)手順に従って、完全なテーブル スキャンやインデックスの欠落などのパフォーマンスの問題を解決してください。 +SQL クエリのパフォーマンスを向上させる場合は、 [SQL性能チューニング](/develop/dev-guide-optimize-sql-overview.md)手順に従って、完全なテーブルスキャンやインデックスの欠落などのパフォーマンスの問題を解決してください。 それでもパフォーマンスの問題が発生する場合は、次のドキュメントを参照してください。 diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index 3367433749ea6..b5516021984fa 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/dev-guide-unstable-result-set/','/ja/tidbcloud/dev-gu - `stu_info`学生情報を保存します - `stu_score`生徒のテストのスコアが格納されます。 -次に、次のような SQL クエリ ステートメントを記述します。 +次に、次のような SQL クエリステートメントを記述します。 ```sql SELECT diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 2bb46029795fd..d13aaad8a5298 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -255,7 +255,7 @@ func placeHolder(n int) string { } ``` -各イテレーションでは、 `SELECT`は主キーの順にクエリを実行します。10 ポイントスケールに更新されていない行 ( `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-follower-read.md b/develop/dev-guide-use-follower-read.md index 16fe3cf8a5544..353fcbcc2563c 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -1,12 +1,12 @@ --- title: Follower Read -summary: Follower Readを使用してクエリ パフォーマンスを最適化する方法を学習します。 +summary: Follower Readを使用してクエリパフォーマンスを最適化する方法を学習します。 aliases: ['/ja/tidb/stable/dev-guide-use-follower-read/','/ja/tidbcloud/dev-guide-use-follower-read/'] --- # Follower Read {#follower-read} -このドキュメントでは、Follower Readを使用してクエリ パフォーマンスを最適化する方法について説明します。 +このドキュメントでは、Follower Readを使用してクエリパフォーマンスを最適化する方法について説明します。 ## 導入 {#introduction} diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index ae23e3121ec4d..15fa7f5785fbb 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} @@ -74,7 +74,7 @@ Bookshopアプリケーションでは、書籍のリアルタイム価格の表
-特定の時間より前の書籍の価格を照会するには、上記のクエリ ステートメントに`AS OF TIMESTAMP `句を追加します。 +特定の時間より前の書籍の価格を照会するには、上記のクエリステートメントに`AS OF TIMESTAMP `句を追加します。 ```sql SELECT id, title, type, price FROM books AS OF TIMESTAMP '2022-04-20 15:20:00' ORDER BY published_at DESC LIMIT 5; @@ -275,7 +275,7 @@ SELECT id, title, type, price FROM books ORDER BY published_at DESC LIMIT 5;
-トランザクションのヘルパー クラスを定義して、トランザクション レベルでステイル読み取りを有効にするコマンドをヘルパー メソッドとしてカプセル化することができます。 +トランザクションのヘルパー クラスを定義して、トランザクションレベルでステイル読み取りを有効にするコマンドをヘルパー メソッドとしてカプセル化することができます。 ```java public static class StaleReadHelper { @@ -382,7 +382,7 @@ SET TRANSACTION READ ONLY AS OF TIMESTAMP NOW() - INTERVAL 5 SECOND;
-トランザクションのヘルパー クラスを定義して、トランザクション レベルでステイル読み取りを有効にするコマンドをヘルパー メソッドとしてカプセル化することができます。 +トランザクションのヘルパー クラスを定義して、トランザクションレベルでステイル読み取りを有効にするコマンドをヘルパー メソッドとしてカプセル化することができます。 ```java public static class TxnHelper { diff --git a/develop/dev-guide-use-subqueries.md b/develop/dev-guide-use-subqueries.md index 1c58e799d8b90..0d50dc8c36439 100644 --- a/develop/dev-guide-use-subqueries.md +++ b/develop/dev-guide-use-subqueries.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-subqueries/','/ja/tidbcloud/dev-guide-u # サブクエリ {#subquery} -このドキュメントでは、TiDB のサブクエリ ステートメントとカテゴリについて説明します。 +このドキュメントでは、TiDB のサブクエリステートメントとカテゴリについて説明します。 ## 概要 {#overview} diff --git a/develop/dev-guide-use-temporary-tables.md b/develop/dev-guide-use-temporary-tables.md index 916394a56c62b..2f8b0e5668fbc 100644 --- a/develop/dev-guide-use-temporary-tables.md +++ b/develop/dev-guide-use-temporary-tables.md @@ -53,7 +53,7 @@ TiDB の一時テーブルは、ローカル一時テーブルとグローバル ### ローカル一時テーブルを作成する {#create-a-local-temporary-table} -ローカル一時テーブルを作成する前に、現在のデータベース ユーザーに`CREATE TEMPORARY TABLES`権限を追加する必要があります。 +ローカル一時テーブルを作成する前に、現在のデータベースユーザーに`CREATE TEMPORARY TABLES`権限を追加する必要があります。
@@ -218,7 +218,7 @@ public List getTop50EldestAuthorInfo() throws SQLException { ## 一時テーブルをクエリする {#query-a-temporary-table} -一時テーブルの準備ができたら、通常のデータ テーブルとしてクエリを実行できます。 +一時テーブルの準備ができたら、通常のデータテーブルとしてクエリを実行できます。 ```sql SELECT * FROM top_50_eldest_authors; diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md index 2953bc4b09e33..1490eef13423a 100644 --- a/develop/dev-guide-vector-search.md +++ b/develop/dev-guide-vector-search.md @@ -40,16 +40,16 @@ RAG シナリオでの検索品質を向上させるには、ベクトル検索 ## パフォーマンスを向上させる {#improve-performance} -ベクトル検索クエリのパフォーマンスを最適化するには、ベクトル インデックスの追加、インデックス構築の進行状況の監視、ディメンションの削減、ベクトル列の除外、インデックスのウォームアップなどの一連のベスト プラクティスに従うことができます。 +ベクトル検索クエリのパフォーマンスを最適化するには、ベクトルインデックスの追加、インデックス構築の進行状況の監視、ディメンションの削減、ベクトル列の除外、インデックスのウォームアップなどの一連のベストプラクティスに従うことができます。 -これらのベスト プラクティスの詳細については、 [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md)を参照してください。 +これらのベストプラクティスの詳細については、 [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md)を参照してください。 ## 制限事項 {#limitations} ベクトル検索を実装する前に、次の制限事項に注意してください。 - ベクトルあたり最大16383次元 -- ベクトル列は主キー、一意インデックス、パーティション キーとして使用することはできません。 +- ベクトル列は主キー、一意インデックス、パーティションキーとして使用することはできません。 - ベクトルと他のデータ型間の直接キャストは行いません（文字列を中間として使用します） 完全なリストについては、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)を参照してください。 diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index bba397e973335..edb0a9d3718a7 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -16,7 +16,7 @@ JavaアプリケーションでTiDBデータベースと連携する一般的な - JDBC APIとJDBCドライバ： Javaアプリケーションは通常、標準の[JDBC（Javaデータベース接続）](https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/) APIを使用してデータベースにアクセスします。TiDBに接続するには、JDBC APIを介してMySQLプロトコルを実装するJDBCドライバを使用できます。MySQL用の一般的なJDBCドライバには[MySQL Connector/J](https://github.com/mysql/mysql-connector-j)や[MariaDB Connector/J](https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j#about-mariadb-connectorj)などがあります。 - データベース接続プール：アプリケーションは通常、接続要求のたびに接続を作成するオーバーヘッドを削減するために、接続プールを使用して接続をキャッシュし、再利用します。JDBCData [データソース](https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)接続プールAPIを定義しています。必要に応じて、さまざまなオープンソースの接続プール実装から選択できます。 - データアクセスフレームワーク: アプリケーションは通常、 [MyBatis](https://mybatis.org/mybatis-3/index.html)や[Hibernate](https://hibernate.org/)などのデータアクセスフレームワークを使用して、データベースアクセス操作をさらに簡素化および管理します。 -- アプリケーションの実装: アプリケーション ロジックは、いつどのコマンドをデータベースに送信するかを制御します。一部のアプリケーションは[春のトランザクション](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html)アスペクトを使用して、トランザクションの開始およびコミットのロジックを管理します。 +- アプリケーションの実装: アプリケーションロジックは、いつどのコマンドをデータベースに送信するかを制御します。一部のアプリケーションは[春のトランザクション](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html)アスペクトを使用して、トランザクションの開始およびコミットのロジックを管理します。 ![Java application components](/media/best-practices/java-practice-1.png) @@ -119,7 +119,7 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 ##### `prepStmtCacheSize` {#prepstmtcachesize} -`prepStmtCacheSize`キャッシュされるプリペアド ステートメントの数を制御します (デフォルト値は`25`です)。アプリケーションで多くの種類の SQL ステートメントを「準備」する必要があり、プリペアド ステートメントを再利用したい場合は、この値を増やすことができます。 +`prepStmtCacheSize`キャッシュされるプリペアドステートメントの数を制御します (デフォルト値は`25`です)。アプリケーションで多くの種類の SQL ステートメントを「準備」する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 @@ -272,7 +272,7 @@ Javaアプリケーションで以下のエラーが頻繁に発生する場合 The last packet sent successfully to the server was 3600000 milliseconds ago. The driver has not received any packets from the server. com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure ``` -`n`内の`n milliseconds ago`の値が`0`または非常に小さい値である場合、通常は実行された SQL 操作によって TiDB が異常終了したことが原因です。原因を特定するには、TiDB の標準エラー ログを確認することをお勧めします。 +`n`内の`n milliseconds ago`の値が`0`または非常に小さい値である場合、通常は実行された SQL 操作によって TiDB が異常終了したことが原因です。原因を特定するには、TiDB の標準エラーログを確認することをお勧めします。 `n`の値が非常に大きい場合 (上記の例の`3600000`など)、この接続が長時間アイドル状態になり、中間プロキシによって閉じられた可能性が高いです。通常の解決策は、プロキシのアイドル設定の値を増やし、接続プールが次の操作を実行できるようにすることです。 diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index 077da0ebae6ee..309a406b5ac18 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 台のサーバーに展開されます。 各ノードのアドレスは次のとおりです。 @@ -35,16 +35,16 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン > **Note:** > -> - 単一のサーバーに複数の DM マスターまたは DM ワーカー インスタンスを展開する場合、各インスタンスのポートと作業ディレクトリは一意である必要があります。 +> - 単一のサーバーに複数の 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`ポートは相互接続されています。 -> - 各 DM マスター ノードは、すべての DM ワーカー ノードの`8262`ポートに接続できます。 -> - 各 DM ワーカー ノードは、すべての DM マスター ノードの`8261`ポートに接続できます。 +> - DM マスターノード間の`8291`ポートは相互接続されています。 +> - 各 DM マスターノードは、すべての DM ワーカーノードの`8262`ポートに接続できます。 +> - 各 DM ワーカーノードは、すべての DM マスターノードの`8261`ポートに接続できます。 ### DMマスターをデプロイ {#deploy-dm-master} @@ -52,7 +52,7 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン #### DMマスターのコマンドラインパラメータ {#dm-master-command-line-parameters} -DM マスターのコマンドライン パラメータの説明は次のとおりです。 +DM マスターのコマンドラインパラメータの説明は次のとおりです。 ```bash ./dm-master --help @@ -133,7 +133,7 @@ Usage of dm-master: #### DM-workerのコマンドラインパラメータ {#dm-worker-command-line-parameters} -DM-worker のコマンドライン パラメータの説明は次のとおりです。 +DM-worker のコマンドラインパラメータの説明は次のとおりです。 ```bash ./dm-worker --help diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 600183fd32416..23e4ff1837216 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -53,7 +53,7 @@ summary: TiUPを使用して DM クラスターをオフラインで展開する ## ステップ2: オフラインTiUPコンポーネントをデプロイ {#step-2-deploy-the-offline-tiup-component} -パッケージをターゲット クラスターの制御マシンに送信した後、次のコマンドを実行してTiUPコンポーネントをインストールします。 +パッケージをターゲットクラスターの制御マシンに送信した後、次のコマンドを実行してTiUPコンポーネントをインストールします。 ```bash # You can modify ${version} to the needed version. @@ -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`セクションで対応するコンポーネントのこれらのパラメータを構成します。 > @@ -118,11 +118,11 @@ alertmanager_servers: > - 詳細なパラメータの説明については、 [マスター`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)と[ワーカー`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 -> - DM マスター ノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 -> - 各 DM マスター ノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 -> - 各 DM ワーカー ノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - DM マスターノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 +> - 各 DM マスターノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - 各 DM ワーカーノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 ## ステップ4: デプロイメントコマンドを実行する {#step-4-execute-the-deployment-command} @@ -132,7 +132,7 @@ alertmanager_servers: > > - 秘密鍵を使用する場合は、 `-i`または`--identity_file`を通じて鍵のパスを指定できます。 > - パスワードを使用する場合は、パスワード対話ウィンドウに入るために`-p`フラグを追加します。 -> - ターゲット マシンへのパスワードなしのログインが構成されている場合、認証は必要ありません。 +> - ターゲットマシンへのパスワードなしのログインが構成されている場合、認証は必要ありません。 ```shell tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] @@ -143,7 +143,7 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo - デプロイされた DM クラスターの名前は`dm-test`です。 - DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`を実行します。 - 初期化構成ファイルは`topology.yaml`です。 -- `--user root` : `root`キーを使用してターゲット マシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 +- `--user root` : `root`キーを使用してターゲットマシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 - `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]`は、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]`は、ユーザーパスワードを対話的に入力するために使用されます。 - TiUP DMは組み込みのSSHクライアントを使用します。制御マシンシステムにネイティブのSSHクライアントを使用する場合は、 [システムのネイティブSSHクライアントを使用してクラスターに接続する](/dm/maintain-dm-using-tiup.md#use-the-systems-native-ssh-client-to-connect-to-cluster)に従って設定を編集してください。 @@ -171,7 +171,7 @@ dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/ tiup dm display dm-test ``` -予想される出力には、インスタンス ID、ロール、ホスト、リスニング ポート、ステータス (クラスターはまだ起動されていないため、ステータス`inactive` `Down`です)、および`dm-test`クラスターのディレクトリ情報が含まれます。 +予想される出力には、インスタンス ID、ロール、ホスト、リスニングポート、ステータス (クラスターはまだ起動されていないため、ステータス`inactive` `Down`です)、および`dm-test`クラスターのディレクトリ情報が含まれます。 ## ステップ7: クラスターを起動する {#step-7-start-the-cluster} diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index 64afed319f48f..fe180120d771c 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -11,7 +11,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 > **Note:** > -> ターゲットマシンのオペレーティング システムが SELinux をサポートしている場合は、SELinux が**無効になっている**ことを確認してください。 +> ターゲットマシンのオペレーティングシステムが SELinux をサポートしている場合は、SELinux が**無効になっている**ことを確認してください。 ## 前提条件 {#prerequisites} @@ -135,11 +135,11 @@ alertmanager_servers: > - 1台のホストで多数のDMワーカーを実行することは推奨されません。各DMワーカーには、少なくとも2コアのCPUと4GiBのメモリを割り当てる必要があります。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 -> - DM マスター ノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 -> - 各 DM マスター ノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 -> - 各 DM ワーカー ノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - DM マスターノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 +> - 各 DM マスターノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - 各 DM ワーカーノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 `master_servers.host.config`パラメータの詳細については[マスターパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)を参照してください。`worker_servers.host.config`のパラメータの詳細については[ワーカーパラメータ](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)を参照してください。 @@ -151,7 +151,7 @@ alertmanager_servers: > > - 秘密鍵を使用する場合は、 `-i`または`--identity_file`を通じて鍵のパスを指定できます。 > - パスワードを使用する場合は、パスワード対話ウィンドウに入るために`-p`フラグを追加します。 -> - ターゲット マシンへのパスワードなしのログインが構成されている場合、認証は必要ありません。 +> - ターゲットマシンへのパスワードなしのログインが構成されている場合、認証は必要ありません。 ```shell tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/root/.ssh/gcp_rsa] @@ -164,7 +164,7 @@ tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/ | `${name}` | DM クラスターの名前 (例: dm-test) | | `${version}` | DM クラスターのバージョン`tiup list dm-master`を実行すると、サポートされている他のバージョンを確認できます。 | | `./topology.yaml` | トポロジ構成ファイルのパス。 | -| `-u`または`--user` | クラスターの展開を完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザー アカウントとしてターゲット マシンにログインします。 | +| `-u`または`--user` | クラスターの展開を完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザーアカウントとしてターゲットマシンにログインします。 | | `-p`または`--password` | 対象ホストのパスワード。指定すると、パスワード認証が使用されます。 | | `-i`または`--identity_file` | SSH IDファイルのパス。指定すると公開鍵認証が使用されます（デフォルトは「/root/.ssh/id_rsa」）。 | @@ -192,7 +192,7 @@ dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/ tiup dm display dm-test ``` -予想される出力には`inactive`インスタンス ID、ロール、ホスト、リスニング ポート、ステータス (クラスターはまだ起動されていないため、ステータスは`Down`です)、およびディレクトリ情報が含まれます。 +予想される出力には`inactive`インスタンス ID、ロール、ホスト、リスニングポート、ステータス (クラスターはまだ起動されていないため、ステータスは`Down`です)、およびディレクトリ情報が含まれます。 ## ステップ6: DMクラスターを起動する {#step-6-start-the-dm-cluster} diff --git a/dm/dm-alert-rules.md b/dm/dm-alert-rules.md index dbb8412f47dbb..883f8d167809e 100644 --- a/dm/dm-alert-rules.md +++ b/dm/dm-alert-rules.md @@ -7,6 +7,6 @@ summary: DMのアラート情報を紹介します。 TiUPを使用して DM クラスターをデプロイすると、 [警報システム](/dm/migrate-data-using-dm.md#step-8-monitor-the-task-and-check-logs)がデフォルトでデプロイされます。 -DM アラート ルールとソリューションの詳細については、 [アラートを処理する](/dm/dm-handle-alerts.md)を参照してください。 +DM アラートルールとソリューションの詳細については、 [アラートを処理する](/dm/dm-handle-alerts.md)を参照してください。 DMアラート情報と監視メトリクスはどちらもPrometheusに基づいています。両者の関係性の詳細については、 [DM監視メトリクス](/dm/monitor-a-dm-cluster.md)を参照してください。 diff --git a/dm/dm-arch.md b/dm/dm-arch.md index 1a007a676b81f..f114f213e3f6c 100644 --- a/dm/dm-arch.md +++ b/dm/dm-arch.md @@ -36,7 +36,7 @@ DM-workerの詳細については[DMワーカー紹介](/dm/dm-worker-intro.md) ### dmctl {#dmctl} -dmctl は、DM クラスターを制御するために使用されるコマンド ライン ツールです。 +dmctl は、DM クラスターを制御するために使用されるコマンドライン ツールです。 - データ移行タスクの作成、更新、または削除 - データ移行タスクの状態を確認する diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 6a83a98fc5986..cae32b1405dd8 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -1,6 +1,6 @@ --- title: TiDB Data Migration (DM) Best Practices -summary: TiDB Data Migration (DM) を使用してデータを移行する場合のベスト プラクティスについて説明します。 +summary: TiDB Data Migration (DM) を使用してデータを移行する場合のベストプラクティスについて説明します。 --- # TiDB Data Migration (DM) のベストプラクティス {#tidb-data-migration-dm-best-practices} @@ -72,10 +72,10 @@ TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。 | シナリオ | 推奨される解決策 | 長所 | 短所 | | :-------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは、主キー ID の連続性に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`を設定します。主キー列として`SEQUENCE`を使用します。 | データ書き込みのホットスポットを回避し、ビジネス データの継続性と単調な増加を確保できます。 |
  • データ書き込みの継続性を確保するために、データ書き込みのスループット容量が低下します。
  • 主キークエリのパフォーマンスが低下します。
    • | -|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは、主キー ID の増分に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`を設定します。アプリケーションIDジェネレータを使用して主キーIDを生成します。 | データ書き込みホットスポットを回避し、データ書き込みのパフォーマンスを保証し、ビジネスデータの増分を保証しますが、継続性を保証することはできません。 |
  • アプリケーションをカスタマイズする必要があります。
  • 外部 ID ジェネレーターはクロックの精度に大きく依存しており、障害が発生する可能性があります。
    • | -|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネス ロジックは主キー ID の連続性に依存しません。
    • | クラスター化インデックスを持つテーブルを作成し、主キー列に`AUTO_RANDOM`を設定します。 |
  • データ書き込みホットスポットを回避でき、主キーのクエリ パフォーマンスが優れています。
  • `AUTO_INCREMENT`から`AUTO_RANDOM`への切り替えもスムーズに行えます。
    • |
  • 主キー ID はランダムです。
  • 書き込みスループット能力は制限されています。
  • 挿入時間列を使用してビジネス データを並べ替えることをお勧めします。
  • 主キー ID を使用してデータを並べ替える必要がある場合は、クエリに対して 5 ビットを左シフトすることができ、これによりデータの増分が保証されます。
    • | -| TiDB は読み取り専用データベースとして機能します。 | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`を設定します。主キー列はデータソースと一貫性を保ちます。 |
  • データ書き込みホットスポットを回避できます。
  • カスタマイズコストが少なくて済みます。
    • | 主キーのクエリ パフォーマンスが影響を受けます。 | +|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネスロジックは、主キー ID の連続性に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`を設定します。主キー列として`SEQUENCE`を使用します。 | データ書き込みのホットスポットを回避し、ビジネスデータの継続性と単調な増加を確保できます。 |
  • データ書き込みの継続性を確保するために、データ書き込みのスループット容量が低下します。
  • 主キークエリのパフォーマンスが低下します。
    • | +|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネスロジックは、主キー ID の増分に大きく依存します。
    • | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`を設定します。アプリケーションIDジェネレータを使用して主キーIDを生成します。 | データ書き込みホットスポットを回避し、データ書き込みのパフォーマンスを保証し、ビジネスデータの増分を保証しますが、継続性を保証することはできません。 |
  • アプリケーションをカスタマイズする必要があります。
  • 外部 ID ジェネレーターはクロックの精度に大きく依存しており、障害が発生する可能性があります。
    • | +|
  • TiDB は、プライマリおよび書き込み集中型データベースとして機能します。
  • ビジネスロジックは主キー ID の連続性に依存しません。
    • | クラスター化インデックスを持つテーブルを作成し、主キー列に`AUTO_RANDOM`を設定します。 |
  • データ書き込みホットスポットを回避でき、主キーのクエリパフォーマンスが優れています。
  • `AUTO_INCREMENT`から`AUTO_RANDOM`への切り替えもスムーズに行えます。
    • |
  • 主キー ID はランダムです。
  • 書き込みスループット能力は制限されています。
  • 挿入時間列を使用してビジネスデータを並べ替えることをお勧めします。
  • 主キー ID を使用してデータを並べ替える必要がある場合は、クエリに対して 5 ビットを左シフトすることができ、これによりデータの増分が保証されます。
    • | +| TiDB は読み取り専用データベースとして機能します。 | 非クラスター化インデックスを持つテーブルを作成し、 `SHARD_ROW_ID_BIT`を設定します。主キー列はデータソースと一貫性を保ちます。 |
  • データ書き込みホットスポットを回避できます。
  • カスタマイズコストが少なくて済みます。
    • | 主キーのクエリパフォーマンスが影響を受けます。 | ### MySQLシャードの重要なポイント {#key-points-for-mysql-shards} @@ -123,7 +123,7 @@ TiDB v6.0.0以降、GBKがサポートされています。詳細については #### DMマスターとDMワーカーをデプロイ {#deploy-dm-master-and-dm-worker} -DM は DM マスター ノードと DM ワーカー ノードで構成されます。 +DM は DM マスターノードと DM ワーカーノードで構成されます。 - DMマスターは、移行タスクのメタデータを管理し、DMワーカーノードのスケジュールを管理します。これはDMプラットフォーム全体の中核です。そのため、DMマスターをクラスターとして展開することで、DMプラットフォームの高可用性を確保できます。 @@ -146,16 +146,16 @@ 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 以上）と 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} -DM は、フルデータ移行を実行する際にデータベース全体のデータをバックアップし、並列論理バックアップ方式を採用しています。MySQL のバックアップ中に、グローバル読み取りロック[`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)が追加されます。上流データベースの DML および DDL 操作は短時間ブロックされます。そのため、上流のバックアップ データベースを使用してフルデータ バックアップを実行し、データ ソースの GTID 機能を有効にすることを強くお勧めします ( `enable-gtid: true` )。これにより、上流からの影響を回避し、上流のマスター ノードに切り替えて増分移行中のレイテンシーを削減できます。上流の MySQL データ ソースを切り替える手順については、 [アップストリーム MySQL インスタンス間の DM ワーカー接続を切り替える](/dm/usage-scenario-master-slave-switch.md#switch-dm-worker-connection-via-virtual-ip)を参照してください。 +DM は、フルデータ移行を実行する際にデータベース全体のデータをバックアップし、並列論理バックアップ方式を採用しています。MySQL のバックアップ中に、グローバル読み取りロック[`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)が追加されます。上流データベースの DML および DDL 操作は短時間ブロックされます。そのため、上流のバックアップデータベースを使用してフルデータバックアップを実行し、データソースの GTID 機能を有効にすることを強くお勧めします ( `enable-gtid: true` )。これにより、上流からの影響を回避し、上流のマスターノードに切り替えて増分移行中のレイテンシーを削減できます。上流の MySQL データソースを切り替える手順については、 [アップストリーム MySQL インスタンス間の DM ワーカー接続を切り替える](/dm/usage-scenario-master-slave-switch.md#switch-dm-worker-connection-via-virtual-ip)を参照してください。 次の点に注意してください。 -- 完全なデータ バックアップは、アップストリーム データベースのマスター ノードでのみ実行できます。 +- 完全なデータバックアップは、アップストリーム データベースのマスターノードでのみ実行できます。 このシナリオでは、設定ファイル内の`consistency`パラメータを`none` `mydumpers.global.extra-args: "--consistency none"` ）に設定することで、マスターノードへのグローバル読み取りロックの追加を回避できます。ただし、これはフルバックアップのデータ整合性に影響を与え、アップストリームとダウンストリーム間でデータの不整合が生じる可能性があります。 @@ -225,7 +225,7 @@ DMは、移行タスクの中断を引き起こすDDL文のスキップまたは データ移行後にデータの整合性を検証することをお勧めします。TiDB は、データ検証を完了するために役立つ[sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)提供します。 -sync-diff-inspector は、DM タスクを通じてデータ整合性チェック対象のテーブルリストを自動管理できるようになりました。以前の手動設定と比較して、より効率的です。詳細は[DM レプリケーション シナリオにおけるデータ チェック](/sync-diff-inspector/dm-diff.md)ご覧ください。 +sync-diff-inspector は、DM タスクを通じてデータ整合性チェック対象のテーブルリストを自動管理できるようになりました。以前の手動設定と比較して、より効率的です。詳細は[DM レプリケーションシナリオにおけるデータチェック](/sync-diff-inspector/dm-diff.md)ご覧ください。 DM v6.2.0以降、DMは増分レプリケーションにおける継続的なデータ検証をサポートしています。詳細については、 [DMにおける継続的なデータ検証](/dm/dm-continuous-data-validation.md)を参照してください。 diff --git a/dm/dm-binlog-event-filter.md b/dm/dm-binlog-event-filter.md index 06a23e71a4ce3..6a6ee5fbde726 100644 --- a/dm/dm-binlog-event-filter.md +++ b/dm/dm-binlog-event-filter.md @@ -1,6 +1,6 @@ --- title: TiDB Data Migration Binlog Event Filter -summary: DM のbinlogイベント フィルター機能の使用方法を学習します。 +summary: DM のbinlogイベントフィルター機能の使用方法を学習します。 --- # TiDB データ移行Binlogイベントフィルター {#tidb-data-migration-binlog-event-filter} diff --git a/dm/dm-block-allow-table-lists.md b/dm/dm-block-allow-table-lists.md index e996ecfe36671..1f6bd95ad0845 100644 --- a/dm/dm-block-allow-table-lists.md +++ b/dm/dm-block-allow-table-lists.md @@ -5,7 +5,7 @@ summary: DM ブロックおよび許可リスト機能の使用方法を学習 # TiDB データ移行のブロックリストと許可リスト {#tidb-data-migration-block-and-allow-lists} -TiDB Data Migration (DM) を使用してデータを移行する場合、ブロック リストと許可リストを構成して、一部のデータベースまたは一部のテーブルのすべての操作をフィルター処理したり、一部の操作のみを移行したりできます。 +TiDB Data Migration (DM) を使用してデータを移行する場合、ブロックリストと許可リストを構成して、一部のデータベースまたは一部のテーブルのすべての操作をフィルター処理したり、一部の操作のみを移行したりできます。 ## ブロックリストと許可リストを設定する {#configure-the-block-and-allow-lists} @@ -43,7 +43,7 @@ block-allow-list: # Use black-white-list if the DM version is earlie ## パラメータの説明 {#parameter-descriptions} - `do-dbs` : MySQL の[`replicate-do-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-db)と同様に、移行するスキーマのリストを許可します。 -- `ignore-dbs` : 移行するスキーマのブロック リスト (MySQL の[`replicate-ignore-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-db)に類似)。 +- `ignore-dbs` : 移行するスキーマのブロックリスト (MySQL の[`replicate-ignore-db`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-db)に類似)。 - `do-tables` : 移行するテーブルのリストを許可します（MySQLの[`replicate-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-do-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 - `ignore-tables` : 移行対象テーブルのブロックリスト（MySQLの[`replicate-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-ignore-table)に相当）。`db-name`と`tbl-name`の両方を指定する必要があります。 @@ -56,7 +56,7 @@ block-allow-list: # Use black-white-list if the DM version is earlie > **Note:** > -> DM と MySQL では、ブロック リストと許可リストのフィルタリング ルールが次の点で異なります。 +> DM と MySQL では、ブロックリストと許可リストのフィルタリング ルールが次の点で異なります。 > > - MySQLでは、 [`replicate-wild-do-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-wild-do-table)と[`replicate-wild-ignore-table`](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#option_mysqld_replicate-wild-ignore-table)ワイルドカード文字をサポートしています。DMでは、一部のパラメータ値は`~`で始まる正規表現を直接サポートしています。 > - DMは現在、 `ROW`形式のバイナリログのみをサポートしており、 `STATEMENT`形式と`MIXED`形式のバイナリログはサポートしていません。そのため、DMのフィルタリングルールはMySQLの`ROW`形式のフィルタリングルールに対応しています。 @@ -137,6 +137,6 @@ block-allow-list: # Use black-white-list if the DM version is earlier than or e | `logs` `messages_2018` | はい | スキーマ`logs`がいずれの`do-dbs`にも一致しません。 | | `forum_backup_2016` `messages` | はい | スキーマ`forum_backup_2016`がいずれの`do-dbs`にも一致しません。 | | `forum_backup_2017` `messages` | はい | スキーマ`forum_backup_2017`がいずれの`do-dbs`にも一致しません。 | -| `forum` `users` | はい |
  • スキーマ`forum`が `do-dbs`と一致し、テーブル レベルでフィルタリングを続行します。
    2. スキーマとテーブルが`do-tables`と`ignore-tables`いずれにも一致せず、 `do-tables`が空ではありません。
    • | -| `forum` `messages` | いいえ |
  • スキーマ`forum`が `do-dbs`と一致し、テーブル レベルでフィルタリングを続行します。
    2. 表`messages` `do-tables`の`db-name: "~^forum.*",tbl-name: "messages"`にあります。
    • | -| `forum_backup_2018` `messages` | いいえ |
  • スキーマ`forum_backup_2018`が `do-dbs`と一致し、テーブル レベルでフィルタリングを続行します。
    2. スキーマとテーブルは`do-tables`中`db-name: "~^forum.*",tbl-name: "messages"`一致します。
    • | +| `forum` `users` | はい |
  • スキーマ`forum`が `do-dbs`と一致し、テーブルレベルでフィルタリングを続行します。
    2. スキーマとテーブルが`do-tables`と`ignore-tables`いずれにも一致せず、 `do-tables`が空ではありません。
    • | +| `forum` `messages` | いいえ |
  • スキーマ`forum`が `do-dbs`と一致し、テーブルレベルでフィルタリングを続行します。
    2. 表`messages` `do-tables`の`db-name: "~^forum.*",tbl-name: "messages"`にあります。
    • | +| `forum_backup_2018` `messages` | いいえ |
  • スキーマ`forum_backup_2018`が `do-dbs`と一致し、テーブルレベルでフィルタリングを続行します。
    2. スキーマとテーブルは`do-tables`中`db-name: "~^forum.*",tbl-name: "messages"`一致します。
    • | diff --git a/dm/dm-command-line-flags.md b/dm/dm-command-line-flags.md index 96c7bf97959f1..bf93caf70f040 100644 --- a/dm/dm-command-line-flags.md +++ b/dm/dm-command-line-flags.md @@ -1,11 +1,11 @@ --- title: TiDB Data Migration Command-line Flags -summary: DM のコマンドライン フラグについて学習します。 +summary: DM のコマンドラインフラグについて学習します。 --- # TiDB データ移行コマンドラインフラグ {#tidb-data-migration-command-line-flags} -このドキュメントでは、DM のコマンドライン フラグについて説明します。 +このドキュメントでは、DM のコマンドラインフラグについて説明します。 ## DMマスター {#dm-master} diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index 41d9aeab898f8..feb81d0e60554 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -19,7 +19,7 @@ summary: このドキュメントでは、データ移行構成ファイルの データ移行タスクを作成するには、次の手順に従います。 -1. [dmctl を使用してデータ ソース構成を DM クラスターにロードします](/dm/dm-manage-source.md#operate-data-source) 。 +1. [dmctl を使用してデータソース構成を DM クラスターにロードします](/dm/dm-manage-source.md#operate-data-source) 。 2. [タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)の説明を参考に設定ファイル`your_task.yaml`を作成します。 3. [dmctlを使用してデータ移行タスクを作成する](/dm/dm-create-task.md) 。 diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index a98c989e2abe6..f64a150e314b0 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -44,7 +44,7 @@ validators: - `mode` : 検証モード。可能な値は`none` 、 `full` 、 `fast`です。 - `none` : デフォルト値。検証は実行されないことを意味します。 - `full` : 変更された行と下流データベースで取得された行を比較します。 - - `fast` : 変更された行がダウンストリーム データベースに存在するかどうかのみを確認します。 + - `fast` : 変更された行がダウンストリームデータベースに存在するかどうかのみを確認します。 - `worker-count` : バックグラウンドで実行される検証ワーカーの数。各ワーカーはゴルーチンです。 - `row-error-delay` : 指定された時間内に行が検証に合格できない場合、エラー行としてマークされます。デフォルト値は30分です。 @@ -294,7 +294,7 @@ DM における継続的なデータ検証 (バリデータ) のアーキテク ## 制限事項 {#limitations} -- 検証するソース テーブルには、主キーまたは null 以外の一意のキーが必要です。 +- 検証するソーステーブルには、主キーまたは null 以外の一意のキーが必要です。 - DM がアップストリーム データベースから DDL を移行する場合、次の制限が適用されます。 - DDL では、主キーを変更したり、列の順序を変更したり、既存の列を削除したりしてはなりません。 - テーブルを削除しないでください。 diff --git a/dm/dm-create-task.md b/dm/dm-create-task.md index 3e74bcd4ccade..f1764e8bc8918 100644 --- a/dm/dm-create-task.md +++ b/dm/dm-create-task.md @@ -42,13 +42,13 @@ start-task [ -s "mysql-replica-01"] ./task.yaml ## フラグの説明 {#flags-description} - `-s` : (オプション) 実行するMySQLソースを指定します`task.yaml` 。設定されている場合、コマンドはMySQLソース上で指定されたタスクのサブタスクのみを開始します。 -- `config-file` : (必須) `task.yaml`のファイル パスを指定します。 +- `config-file` : (必須) `task.yaml`のファイルパスを指定します。 - `remove-meta` : (オプション) タスクを開始するときに、タスクの以前のメタデータを削除するかどうかを指定します。 - `start-time` : (オプション) binlogレプリケーションの開始時刻を指定します。 - 形式: `'2021-10-21 00:01:00'`または`2021-10-21T00:01:00` 。 - 増分タスクの場合、このフラグを使用してタスクの大まかな開始位置を指定できます。このフラグは、タスク設定ファイル内のbinlogの位置や下流チェックポイント内のbinlogの位置よりも優先されます。 - タスクに既にチェックポイントがある場合、このフラグを使用してタスクを開始すると、レプリケーションがチェックポイントを通過するまでDMは自動的にセーフモードを有効にします。これは、タスクを以前の位置にリセットすることで発生するデータ重複エラーを回避するためです。 - - タスクを以前の位置にリセットすると、その時点でのテーブル スキーマが現在の時点でのダウンストリームと異なる場合、タスクはエラーを報告する可能性があります。 + - タスクを以前の位置にリセットすると、その時点でのテーブルスキーマが現在の時点でのダウンストリームと異なる場合、タスクはエラーを報告する可能性があります。 - タスクを後の位置にリセットする場合、スキップされたbinlogの下流にダーティ データが残る可能性があることに注意してください。 - より早い開始時刻を指定すると、DM は利用可能な最も古いbinlog位置から移行を開始します。 - 開始時刻を遅く指定すると、DM はエラーを報告します: `start-time {input-time} is too late, no binlog location matches it` 。 diff --git a/dm/dm-customized-secret-key.md b/dm/dm-customized-secret-key.md index ac426d7078378..3b0da204a73e3 100644 --- a/dm/dm-customized-secret-key.md +++ b/dm/dm-customized-secret-key.md @@ -1,6 +1,6 @@ --- title: Customize a Secret Key for DM Encryption and Decryption -summary: DM（データ移行）データ ソースおよび移行タスク構成で使用されるパスワードを暗号化および復号化するための秘密キーをカスタマイズする方法を学習します。 +summary: DM（データ移行）データソースおよび移行タスク構成で使用されるパスワードを暗号化および復号化するための秘密キーをカスタマイズする方法を学習します。 --- # DM 暗号化と復号化用の秘密鍵をカスタマイズする {#customize-a-secret-key-for-dm-encryption-and-decryption} @@ -29,7 +29,7 @@ DM はバージョン 8.0.0 以降では固定秘密キーを使用しなくな > **Note:** > - > - すべての DM マスター ノードが同じ秘密キー構成に更新されていることを確認します。 + > - すべての DM マスターノードが同じ秘密キー構成に更新されていることを確認します。 > - 秘密鍵の更新中は、新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)または[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成しないでください。 2. DM マスターのローリング再起動を実行します。 diff --git a/dm/dm-daily-check.md b/dm/dm-daily-check.md index e031445c7dc05..10fa2dda0c375 100644 --- a/dm/dm-daily-check.md +++ b/dm/dm-daily-check.md @@ -9,9 +9,9 @@ summary: TiDB Data Migration (DM) の毎日のチェックについて説明し - 方法1：コマンド`query-status`を実行して、タスクの実行状態とエラー出力（ある場合）を確認します。詳細は[クエリステータス](/dm/dm-query-status.md)を参照してください。 -- 方法2： TiUPを使用してDMクラスターをデプロイする際にPrometheusとGrafanaが正しくデプロイされていれば、GrafanaでDMの監視メトリクスを確認できます。例えば、Grafanaのアドレスが`172.16.10.71`の場合、 [http://172.16.10.71:3000](http://172.16.10.71:3000)に進み、Grafanaダッシュボードに入り、DMダッシュボードを選択してDMの監視メトリクスを確認します。これらのメトリクスの詳細については、 [DM モニタリング メトリック](/dm/monitor-a-dm-cluster.md)を参照してください。 +- 方法2： TiUPを使用してDMクラスターをデプロイする際にPrometheusとGrafanaが正しくデプロイされていれば、GrafanaでDMの監視メトリクスを確認できます。例えば、Grafanaのアドレスが`172.16.10.71`の場合、 [http://172.16.10.71:3000](http://172.16.10.71:3000)に進み、Grafanaダッシュボードに入り、DMダッシュボードを選択してDMの監視メトリクスを確認します。これらのメトリクスの詳細については、 [DM モニタリングメトリック](/dm/monitor-a-dm-cluster.md)を参照してください。 -- 方法 3: ログ ファイルを使用して、DM の実行状態とエラー (ある場合) を確認します。 +- 方法 3: ログファイルを使用して、DM の実行状態とエラー (ある場合) を確認します。 - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、DMマスターノードのログディレクトリは`{log_dir}`になります。 - DMワーカーのログディレクトリ：DMワーカープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDMワーカーノードの`{log_dir}`になります。 diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 3865b38a0f8f0..fa062fd840267 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -15,7 +15,7 @@ summary: DM を使用する際のエラー システムと一般的なエラー DMでは、同じエラータイプに対して同じエラーコードが使用されます。DMのバージョンが変更されても、エラーコードは変更されません。 - DM 反復処理中に一部のエラーが削除される可能性がありますが、エラー コードは削除されません。DM は、新しいエラーに対して既存のエラー コードではなく新しいエラー コードを使用します。 + DM 反復処理中に一部のエラーが削除される可能性がありますが、エラーコードは削除されません。DM は、新しいエラーに対して既存のエラーコードではなく新しいエラーコードを使用します。 - `class` : エラータイプ。 @@ -69,7 +69,7 @@ summary: DM を使用する際のエラー システムと一般的なエラー DMがエラースタック情報を出力するかどうかは、エラーの重大度と必要性によって異なります。エラースタックには、エラー発生時のスタック呼び出し情報がすべて記録されます。基本情報とエラーメッセージだけではエラーの原因を特定できない場合は、エラースタックを使用することで、エラー発生時のコード実行パスを追跡できます。 -エラー コードの完全なリストについては、 [エラーコードリスト](https://github.com/pingcap/tiflow/blob/release-8.5/dm/_utils/terror_gen/errors_release.txt)を参照してください。 +エラーコードの完全なリストについては、 [エラーコードリスト](https://github.com/pingcap/tiflow/blob/release-8.5/dm/_utils/terror_gen/errors_release.txt)を参照してください。 ## トラブルシューティング {#troubleshooting} @@ -93,14 +93,14 @@ DM の実行中にエラーが発生した場合は、次の手順に従って | エラーコード | エラーの説明 | 取り扱い方法 | | :----------- | :------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `code=10001` | 異常なデータベース操作です。 | エラー メッセージとエラー スタックをさらに分析します。 | +| `code=10001` | 異常なデータベース操作です。 | エラーメッセージとエラースタックをさらに分析します。 | | `code=10002` | 基盤データベースからのエラー`bad connection`です。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在要求されているデータがTiDBに送信されていないことを示します。 | DMはこのようなエラーに対して自動リカバリを提供します。長時間リカバリが成功しない場合は、ネットワークまたはTiDBのステータスを確認してください。 | | `code=10003` | 基盤データベースからのエラー`invalid connection`です。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在要求されているデータの一部がTiDBに送信されていることを示します。 | DMはこのようなエラーに対して自動回復機能を提供します。長時間回復できない場合は、エラーメッセージをさらに確認し、実際の状況に基づいて情報を分析してください。 | | `code=10005` | `QUERY`種類の SQL ステートメントを実行するときに発生します。 | | | `code=10006` | `EXECUTE`タイプのSQL文（ `INSERT` `UPDATE`または`DELETE`タイプのDDL文およびDML文を含む）の実行時に発生します。詳細なエラー情報については、通常、データベース操作で返されるエラーコードとエラー情報を含むエラーメッセージを確認してください。 | | | | | | | `code=11006` | DM の組み込みパーサーが互換性のない DDL ステートメントを解析するときに発生します。 | 解決策については[データ移行 - 互換性のない DDL ステートメント](/dm/dm-faq.md#how-to-handle-incompatible-ddl-statements)を参照してください。 | -| `code=20010` | タスク構成で指定されたデータベース パスワードを復号化するときに発生します。 | 構成タスクで指定されたダウンストリーム データベース パスワードが[dmctlを使用して正しく暗号化されました](/dm/dm-manage-source.md#encrypt-the-database-password)あるかどうかを確認します。 | +| `code=20010` | タスク構成で指定されたデータベース パスワードを復号化するときに発生します。 | 構成タスクで指定されたダウンストリームデータベース パスワードが[dmctlを使用して正しく暗号化されました](/dm/dm-manage-source.md#encrypt-the-database-password)あるかどうかを確認します。 | | `code=26002` | タスクチェックでデータベース接続を確立できませんでした。詳細なエラー情報については、エラーメッセージを確認してください。エラーメッセージには通常、データベース操作で返されたエラーコードとエラー情報が含まれています。 | DM マスターが配置されているマシンにアップストリームにアクセスする権限があるかどうかを確認します。 | | `code=32001` | 異常ダンプ処理装置 | エラーメッセージに`mydumper: argument list too long.`が含まれている場合は、ブロック/許可リストに従って、 `task.yaml`ファイルの Mydumper 引数`extra-args`に`--regex`正規表現を手動で追加して、エクスポートするテーブルを設定します。例えば、 `hello`という名前のテーブルをすべてエクスポートするには`--regex '.*\\.hello$'`を追加し、すべてのテーブルをエクスポートするには`--regex '.*'`を追加します。 | | `code=38008` | DM コンポーネント間の gRPC 通信でエラーが発生します。 | チェック`class` ：どのコンポーネントの相互作用でエラーが発生しているかを確認します。通信エラーの種類を特定します。gRPC接続の確立時にエラーが発生する場合は、通信サーバーが正常に動作しているかどうかを確認します。 | @@ -115,7 +115,7 @@ DM の実行中にエラーが発生した場合は、次の手順に従って DMは移行タスクにおいてデータを下流へ並行して移行する機能を備えているため、タスクが中断されると様々なエラーが発生する可能性があります。これらのエラーは`query-status`を使用して確認できます。 -- 増分レプリケーション プロセス中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 +- 増分レプリケーションプロセス中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 - バージョンの問題により DM が自動的に再試行されない場合、または再試行に失敗した場合は、 `stop-task`を使用してタスクを停止し、 `start-task`を使用してタスクを再起動します。 ### 移行タスクが`driver: bad connection`エラーが返されました {#a-migration-task-is-interrupted-with-the-driver-bad-connection-error-returned} @@ -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の位置がオーバーフローし、上記のエラーが発生します。 @@ -144,7 +144,7 @@ DMは移行タスクにおいてデータを下流へ並行して移行する機 2. DM ワーカーを停止します。 -3. アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。 +3. アップストリーム内の対応するbinlogファイルをリレーログファイルとしてリレーログディレクトリにコピーします。 4. リレーログディレクトリ内の対応する`relay.meta`のファイルを更新し、次のbinlogファイルから取得します。DMワーカーに`enable_gtid`を`true`に指定した場合は、 `relay.meta`ファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。 @@ -158,7 +158,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ 2. `stop-task`を使用して移行タスクを停止します。 -3. グローバル チェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name`を 、エラーのあるbinlogファイルの名前に更新します。`binlog_pos`を 、移行が完了した有効な位置の値 (例: 4) に更新します。 +3. グローバルチェックポイントとダウンストリーム`dm_meta`データベースの各テーブル チェックポイントの`binlog_name`を 、エラーのあるbinlogファイルの名前に更新します。`binlog_pos`を 、移行が完了した有効な位置の値 (例: 4) に更新します。 例：エラーが発生したタスクの名前が`dm_test` 、対応するタスク`source-id`が`replica-1` 、対応するbinlogファイルが`mysql-bin|000001.004451`の場合、次のコマンドを実行します。 @@ -184,7 +184,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ - MySQLクライアントとMySQL/TiDBサーバーの両方に`max_allowed_packet`のクォータ制限があります。`max_allowed_packet`のいずれかが制限を超えると、クライアントはエラーメッセージを受け取ります。現在、最新バージョンのDMとTiDBサーバーでは、`max_allowed_packet`のデフォルト値は`64M`です。 -- DM の完全データ インポート処理ユニットは、DM のダンプ処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。 +- DM の完全データインポート処理ユニットは、DM のダンプ処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。 #### ソリューション {#solutions} diff --git a/dm/dm-export-import-config.md b/dm/dm-export-import-config.md index f66f7c108988f..17a5143fac4d7 100644 --- a/dm/dm-export-import-config.md +++ b/dm/dm-export-import-config.md @@ -1,15 +1,15 @@ --- title: Export and Import Data Sources and Task Configuration of Clusters -summary: DM を使用するときに、データ ソースとクラスターのタスク構成をエクスポートおよびインポートする方法を学習します。 +summary: DM を使用するときに、データソースとクラスターのタスク構成をエクスポートおよびインポートする方法を学習します。 --- # データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション {#export-and-import-data-sources-and-task-configuration-of-clusters} -`config`コマンドは、クラスターのデータ ソースとタスク構成をエクスポートおよびインポートするために使用されます。 +`config`コマンドは、クラスターのデータソースとタスク構成をエクスポートおよびインポートするために使用されます。 > **Note:** > -> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データ ソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 +> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 ```bash » help config @@ -28,7 +28,7 @@ Use "dmctl config [command] --help" for more information about a command. ## クラスターのデータソースとタスク構成をエクスポートする {#export-the-data-source-and-task-configuration-of-clusters} -`export`コマンドを使用して、クラスターのデータ ソースとタスク構成を指定されたファイルにエクスポートできます。 +`export`コマンドを使用して、クラスターのデータソースとタスク構成を指定されたファイルにエクスポートできます。 ```bash config export [--dir directory] @@ -53,7 +53,7 @@ export configs to directory `/tmp/configs` succeed ## クラスターのデータソースとタスク構成をインポートする {#import-the-data-source-and-task-configuration-of-clusters} -`import`コマンドを使用して、指定されたファイルからクラスターのデータ ソースとタスク構成をインポートできます。 +`import`コマンドを使用して、指定されたファイルからクラスターのデータソースとタスク構成をインポートできます。 ```bash config import [--dir directory] diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 9432a1bebc1dc..b2046c8feb230 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -11,11 +11,11 @@ summary: TiDB Data Migration (DM) に関するよくある質問 (FAQ) につい 現在、DMはMySQLまたはMariaDBの標準バージョンのbinlogのデコードのみをサポートしています。Alibaba Cloud RDSやその他のクラウドデータベースではテストされていません。binlogが標準形式であることが確認できれば、サポートされます。 -Alibaba Cloud RDS の主キーのないアップストリーム テーブルの場合、そのbinlogに非表示の主キー列が含まれたままになり、元のテーブル構造と一致しないという既知の問題があります。 +Alibaba Cloud RDS の主キーのないアップストリームテーブルの場合、そのbinlogに非表示の主キー列が含まれたままになり、元のテーブル構造と一致しないという既知の問題があります。 互換性に関する既知の問題は次のとおりです。 -- **Alibaba Cloud RDS**では、主キーのないアップストリーム テーブルの場合、そのbinlog には非表示の主キー列がまだ含まれており、元のテーブル構造と一致していません。 +- **Alibaba Cloud RDS**では、主キーのないアップストリームテーブルの場合、そのbinlog には非表示の主キー列がまだ含まれており、元のテーブル構造と一致していません。 - **HUAWEI Cloud RDS**では、 binlogファイルの直接読み取りはサポートされていません。詳細については、 [HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?](https://support.huaweicloud.com/en-us/rds_faq/rds_faq_0210.html)を参照してください。 ## タスク構成のブロックおよび許可リストの正規表現は`non-capturing (?!)`をサポートしていますか? {#does-the-regular-expression-of-the-block-and-allow-list-in-the-task-configuration-support-non-capturing-} @@ -141,7 +141,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために このエラーをさらに分析するには、エラーメッセージとログファイルを確認してください。原因としては、権限不足のためにダンプユニットが正しいメタデータファイルを生成していないことが考えられます。 -## シャーディングされたスキーマとテーブルを複製するときに DM が致命的なエラーを報告しないのに、ダウンストリーム データが失われるのはなぜですか? {#why-does-dm-report-no-fatal-error-when-replicating-sharded-schemas-and-tables-but-downstream-data-is-lost} +## シャーディングされたスキーマとテーブルを複製するときに DM が致命的なエラーを報告しないのに、ダウンストリームデータが失われるのはなぜですか? {#why-does-dm-report-no-fatal-error-when-replicating-sharded-schemas-and-tables-but-downstream-data-is-lost} 構成項目`block-allow-list`と`table-route`を確認します。 @@ -152,7 +152,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために DM 1.0では、監視データを生成するには`enable-heartbeat`を有効にする必要があります。DM 2.0以降のバージョンでは、この機能はサポートされていないため、監視メトリック`replicate lag`にはデータが存在しないことが想定されます。 -## DM がタスクを開始しているときに、 `context deadline exceeded`を示すエラー メッセージの`RawCause`で`fail to initial unit Sync of subtask`エラーを処理する方法を教えてください。 {#how-to-handle-the-error-fail-to-initial-unit-sync-of-subtask-when-dm-is-starting-a-task-with-the-rawcause-in-the-error-message-showing-context-deadline-exceeded} +## DM がタスクを開始しているときに、 `context deadline exceeded`を示すエラーメッセージの`RawCause`で`fail to initial unit Sync of subtask`エラーを処理する方法を教えてください。 {#how-to-handle-the-error-fail-to-initial-unit-sync-of-subtask-when-dm-is-starting-a-task-with-the-rawcause-in-the-error-message-showing-context-deadline-exceeded} これはDM 2.0.0バージョンの既知の問題であり、DM 2.0.1バージョンで修正される予定です。レプリケーションタスクで処理するテーブル数が多い場合に発生する可能性があります。TiUPを使用してDMをデプロイしている場合は、DMをナイトリーバージョンにアップグレードすることでこの問題を修正できます。または、GitHubの[DMのリリースページ](https://github.com/pingcap/tiflow/releases)から2.0.0-hotfixバージョンをダウンロードし、実行ファイルを手動で置き換えることもできます。 @@ -160,7 +160,7 @@ DM 1.0では、監視データを生成するには`enable-heartbeat`を有効 まず、以下の点を確認して確認する必要があります。 -- レプリケーション タスクで`disable-detect`が構成されていません (v2.0.7 以前のバージョン)。 +- レプリケーションタスクで`disable-detect`が構成されていません (v2.0.7 以前のバージョン)。 - データは手動でも他のレプリケーション プログラムによっても挿入されません。 - このテーブルに関連付けられた DML フィルターは構成されていません。 @@ -173,17 +173,17 @@ curl -X POST -d "tidb_general_log=1" http://{TiDBIP}:10080/settings curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings ``` -`duplicate entry`エラーが発生した場合は、競合データを含むレコードのログ ファイルを確認する必要があります。 +`duplicate entry`エラーが発生した場合は、競合データを含むレコードのログファイルを確認する必要があります。 ## 一部の監視パネルに`No data point`と表示されるのはなぜですか? {#why-do-some-monitoring-panels-show-no-data-point} -一部のパネルにデータが表示されないのは正常です。例えば、エラーが報告されていない場合、DDLロックがない場合、またはリレーログ機能が有効になっていない場合、対応するパネルには`No data point`が表示されます。各パネルの詳細については、 [DM モニタリング メトリック](/dm/monitor-a-dm-cluster.md)を参照してください。 +一部のパネルにデータが表示されないのは正常です。例えば、エラーが報告されていない場合、DDLロックがない場合、またはリレーログ機能が有効になっていない場合、対応するパネルには`No data point`が表示されます。各パネルの詳細については、 [DM モニタリングメトリック](/dm/monitor-a-dm-cluster.md)を参照してください。 ## DM v1.0 では、タスクにエラーがある場合にコマンド`sql-skip`一部のステートメントをスキップできないのはなぜですか? {#in-dm-v10-why-does-the-command-sql-skip-fail-to-skip-some-statements-when-the-task-is-in-error} まず、 `sql-skip`を実行した後もbinlogの位置が進んでいるかどうかを確認する必要があります。進んでいる場合は、 `sql-skip`が有効になっていることを意味します。このエラーが繰り返し発生する理由は、アップストリームがサポートされていない複数の DDL 文を送信しているためです。`sql-skip -s `を使用して、これらの文に一致するパターンを設定できます。 -場合によっては、エラー メッセージに`parse statement`情報が含まれます。次に例を示します。 +場合によっては、エラーメッセージに`parse statement`情報が含まれます。次に例を示します。 ``` if the DDL is not needed, you can use a filter rule with \"*\" schema-pattern to ignore it.\n\t : parse statement: line 1 column 11 near \"EVENT `event_del_big_table` \r\nDISABLE\" %!!(MISSING)(EXTRA string=ALTER EVENT `event_del_big_table` \r\nDISABLE @@ -199,7 +199,7 @@ DM v6.0以降、 `sql-skip`と`handle-error`が`binlog`に置き換えられま DM-worker のログファイルを確認し、 `change count`を含む行を探してください。その行の`new count`が0 でない場合、セーフモードが有効になっています。セーフモードが有効になっている理由を確認するには、セーフモードがいつ発生するか、またそれ以前にエラーが報告されているかどうかを確認してください。 -## DM v2.0 では、タスク中に DM が再起動すると、完全インポート タスクが失敗するのはなぜですか? {#in-dm-v20-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} +## DM v2.0 では、タスク中に DM が再起動すると、完全インポートタスクが失敗するのはなぜですか? {#in-dm-v20-why-does-the-full-import-task-fail-if-dm-restarts-during-the-task} DM v2.0.1 以前のバージョンでは、完全インポートが完了する前に DM が再起動すると、上流のデータソースと DM ワーカーノード間のバインディングが変更される可能性があります。例えば、ダンプユニットの中間データが DM ワーカーノード A にあるにもかかわらず、ロードユニットが DM ワーカーノード B で実行されている場合、操作が失敗する可能性があります。 @@ -207,31 +207,31 @@ DM v2.0.1 以前のバージョンでは、完全インポートが完了する - データ量が少ない (1 TB 未満) 場合、またはタスクがシャーディングされたテーブルをマージする場合は、次の手順を実行します。 - 1. ダウンストリーム データベースにインポートされたデータをクリーンアップします。 + 1. ダウンストリームデータベースにインポートされたデータをクリーンアップします。 2. エクスポートされたデータのディレクトリ内のすべてのファイルを削除します。 3. dmctl を使用してタスクを削除し、コマンド`start-task --remove-meta`を実行して新しいタスクを作成します。 - 新しいタスクが開始したら、冗長な DM ワーカー ノードが存在しないことを確認し、完全インポート中に DM クラスターの再起動やアップグレードを行わないようにすることをお勧めします。 + 新しいタスクが開始したら、冗長な DM ワーカーノードが存在しないことを確認し、完全インポート中に DM クラスターの再起動やアップグレードを行わないようにすることをお勧めします。 - データ量が大きい場合 (1 TB を超える場合) は、次の手順を実行します。 - 1. ダウンストリーム データベースにインポートされたデータをクリーンアップします。 + 1. ダウンストリームデータベースにインポートされたデータをクリーンアップします。 2. データを処理する DM ワーカーノードに TiDB-Lightningをデプロイします。 - 3. DM ダンプ ユニットがエクスポートするデータをインポートするには、TiDB-Lightning のローカル バックエンド モードを使用します。 + 3. DM ダンプユニットがエクスポートするデータをインポートするには、TiDB-Lightning のローカルバックエンド モードを使用します。 4. 完全インポートが完了したら、次の方法でタスク構成ファイルを編集し、タスクを再起動します。 - `task-mode`を`incremental`に変更します。 - ダンプユニットが出力するメタデータファイルに記録されている位置に値`mysql-instance.meta.pos`を設定します。 ## 増分タスク中に再起動すると、DM がエラー`ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.`はなぜですか? {#why-does-dm-report-the-error-error-1236-hy000-the-slave-is-connecting-using-change-master-to-master_auto_position--1-but-the-master-has-purged-binary-logs-containing-gtids-that-the-slave-requires-if-it-restarts-during-an-incremental-task} -このエラーは、ダンプ ユニットによって出力されたメタデータ ファイルに記録されたアップストリームbinlogの位置が、完全な移行中に消去されたことを示します。 +このエラーは、ダンプユニットによって出力されたメタデータファイルに記録されたアップストリームbinlogの位置が、完全な移行中に消去されたことを示します。 -この問題が発生した場合は、タスクを一時停止し、ダウンストリーム データベースに移行されたすべてのデータを削除して、 `--remove-meta`オプションで新しいタスクを開始する必要があります。 +この問題が発生した場合は、タスクを一時停止し、ダウンストリームデータベースに移行されたすべてのデータを削除して、 `--remove-meta`オプションで新しいタスクを開始する必要があります。 次の方法で設定することで、この問題を事前に回避できます。 1. 移行タスクが完了する前に必要なbinlogファイルが誤って削除されるのを防ぐため、上流のMySQLデータベースの値を`expire_logs_days`に増やしてください。データ量が多い場合は、タスクを高速化するために、DumplingとTiDB Lightningを同時に使用することをお勧めします。 -2. このタスクのリレー ログ機能を有効にすると、binlogの位置が消去されていても DM がリレー ログからデータを読み取ることができます。 +2. このタスクのリレーログ機能を有効にすると、binlogの位置が消去されていても DM がリレーログからデータを読み取ることができます。 ## クラスターがTiUP v1.3.0 または v1.3.1 を使用してデプロイされている場合、DM クラスターの Grafana ダッシュボードに`failed to fetch dashboard`と表示されるのはなぜですか? {#why-does-the-grafana-dashboard-of-a-dm-cluster-display-failed-to-fetch-dashboard-if-the-cluster-is-deployed-using-tiup-v130-or-v131} @@ -331,26 +331,26 @@ query-status test この例では、データソース`mysql1`の`syncerBinlogGtid`が連続していません。この場合、データ損失に対処するには、次のいずれかの方法を実行できます。 - 現在の時刻から完全エクスポート タスクのメタデータに記録された位置までのアップストリーム バイナリ ログが消去されていない場合は、次の手順を実行できます。 - 1. 現在のタスクを停止し、連続しない GTID を持つすべてのデータ ソースを削除します。 + 1. 現在のタスクを停止し、連続しない GTID を持つすべてのデータソースを削除します。 2. すべてのソース構成ファイルで`enable-relay`を`false`に設定します。 - 3. 連続しない GTID を持つデータ ソース (上記の例の`mysql1`など) の場合は、タスクを増分タスクに変更し、 `binlog-name` 、 `binlog-pos` 、および`binlog-gtid`情報を含む各完全エクスポート タスクのメタデータ情報を使用して関連する`mysql-instances.meta`を構成します。 + 3. 連続しない GTID を持つデータソース (上記の例の`mysql1`など) の場合は、タスクを増分タスクに変更し、 `binlog-name` 、 `binlog-pos` 、および`binlog-gtid`情報を含む各完全エクスポート タスクのメタデータ情報を使用して関連する`mysql-instances.meta`を構成します。 4. 増分タスクの`task.yaml`に`syncers.safe-mode`を`true`に設定し、タスクを再開します。 5. 増分タスクがすべての欠落データをダウンストリームに複製した後、タスクを停止し、 `task.yaml`の`safe-mode`を`false`に変更します。 6. タスクを再度開始します。 -- アップストリーム バイナリ ログが消去されたが、ローカル リレー ログが残っている場合は、次の手順を実行できます。 +- アップストリーム バイナリ ログが消去されたが、ローカルリレーログが残っている場合は、次の手順を実行できます。 1. 現在のタスクを停止します。 - 2. 連続しない GTID を持つデータ ソース (上記の例の`mysql1`など) の場合は、タスクを増分タスクに変更し、 `binlog-name` 、 `binlog-pos` 、および`binlog-gtid`情報を含む各完全エクスポート タスクのメタデータ情報を使用して関連する`mysql-instances.meta`を構成します。 + 2. 連続しない GTID を持つデータソース (上記の例の`mysql1`など) の場合は、タスクを増分タスクに変更し、 `binlog-name` 、 `binlog-pos` 、および`binlog-gtid`情報を含む各完全エクスポート タスクのメタデータ情報を使用して関連する`mysql-instances.meta`を構成します。 3. 増分タスクの`task.yaml`で、 `binlog-gtid`の前の値を`previous_gtids`の前の値に変更します。上記の例では、 `1-y`を`6-y`に変更します。 4. `task.yaml`の`syncers.safe-mode`を`true`に設定し、タスクを再開します。 5. 増分タスクがすべての欠落データをダウンストリームに複製した後、タスクを停止し、 `task.yaml`の`safe-mode`を`false`に変更します。 6. タスクを再度開始します。 - 7. データ ソースを再起動し、ソース構成ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 + 7. データソースを再起動し、ソース構成ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 - 上記の条件がいずれも満たされていない場合、またはタスクのデータ量が少ない場合は、次の手順を実行できます。 - 1. ダウンストリーム データベースにインポートされたデータをクリーンアップします。 - 2. データ ソースを再起動し、ソース構成ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 + 1. ダウンストリームデータベースにインポートされたデータをクリーンアップします。 + 2. データソースを再起動し、ソース構成ファイルで`enable-relay`または`enable-gtid`を`false`に設定します。 3. 新しいタスクを作成し、コマンド`start-task task.yaml --remove-meta`を実行して、データを最初から再度移行します。 -上記の 1 番目と 2 番目のソリューションで正常にレプリケートできるデータ ソース (上記の例の`mysql2`など) の場合は、増分タスクを設定するときに、 `subTaskStatus.sync`の`syncerBinlog`と`syncerBinlogGtid`情報を使用して関連する`mysql-instances.meta`を構成します。 +上記の 1 番目と 2 番目のソリューションで正常にレプリケートできるデータソース (上記の例の`mysql2`など) の場合は、増分タスクを設定するときに、 `subTaskStatus.sync`の`syncerBinlog`と`syncerBinlogGtid`情報を使用して関連する`mysql-instances.meta`を構成します。 ## DM v2.0 では、 `heartbeat`機能が有効になっている仮想 IP 環境で DM ワーカーと MySQL インスタンス間の接続を切り替えるときに、「ハートビート構成が以前使用したものと異なります: serverID が等しくありません」というエラーをどのように処理すればよいですか? {#in-dm-v20-how-do-i-handle-the-error-heartbeat-config-is-different-from-previous-used-serverid-not-equal-when-switching-the-connection-between-dm-workers-and-mysql-instances-in-a-virtual-ip-environment-with-the-heartbeat-feature-enabled} @@ -382,8 +382,8 @@ flush local meta, Rawcause: open relay-dir/xxx.000001/relay.metayyyy: no such fi 上記のエラーは次の場合に発生する可能性があります。 -- DM は v2.0.1 以前から v2.0.2 - v2.0.6 にアップグレードされており、アップグレード前にリレー ログが開始され、アップグレード後に再起動されます。 -- stop-relay コマンドを実行してリレー ログを一時停止してから再開します。 +- DM は v2.0.1 以前から v2.0.2 - v2.0.6 にアップグレードされており、アップグレード前にリレーログが開始され、アップグレード後に再起動されます。 +- stop-relay コマンドを実行してリレーログを一時停止してから再開します。 次のオプションによりこのエラーを回避できます。 diff --git a/dm/dm-generate-self-signed-certificates.md b/dm/dm-generate-self-signed-certificates.md index da7daeef064fe..66ea41b6fda65 100644 --- a/dm/dm-generate-self-signed-certificates.md +++ b/dm/dm-generate-self-signed-certificates.md @@ -80,7 +80,7 @@ DM マスター インスタンスに証明書を発行するには、次の手 cp /usr/lib/ssl/openssl.cnf . ``` - 実際の場所がわからない場合は、ルート ディレクトリで探します。 + 実際の場所がわからない場合は、ルートディレクトリで探します。 ```bash find / -name openssl.cnf @@ -136,7 +136,7 @@ DM マスター インスタンスに証明書を発行するには、次の手 > **Note:** > -> DM ワーカー インスタンスの証明書を発行するプロセスも同様であるため、このドキュメントでは繰り返しません。 +> DM ワーカーインスタンスの証明書を発行するプロセスも同様であるため、このドキュメントでは繰り返しません。 ### クライアントの証明書を発行する (dmctl) {#issue-certificates-for-the-client-dmctl} diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index 56e40b117a276..627d9080eba71 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -39,7 +39,7 @@ Binlogログレプリケーション処理ユニットは、DM-workerにおい ### チェックポイント {#checkpoint} -チェックポイントは、完全なデータ インポートまたは増分レプリケーション タスクが一時停止されて再開される位置、または停止されて再起動される位置を示します。 +チェックポイントは、完全なデータインポートまたは増分レプリケーションタスクが一時停止されて再開される位置、または停止されて再起動される位置を示します。 - フルインポートタスクでは、チェックポイントは、インポート対象のファイル内の正常にインポートされたデータのオフセットなどの情報に対応します。チェックポイントは、データインポートタスクと同期して更新されます。 - 増分レプリケーションでは、チェックポイントは、正常に解析され下流に移行された[binlogイベント](#binlog-event)の[binlogの位置](#binlog-position)とその他の情報に対応します。チェックポイントは、DDL操作が正常に移行された後、または最後の更新から30秒後に更新されます。 @@ -68,7 +68,7 @@ GTIDはMySQLまたはMariaDBのグローバルトランザクションIDです ### 移行/移行 {#migrate-migration} -TiDB データ移行ツールを使用して、アップストリーム データベースの**完全なデータを**ダウンストリーム データベースにコピーするプロセス。 +TiDB データ移行ツールを使用して、アップストリーム データベースの**完全なデータを**ダウンストリームデータベースにコピーするプロセス。 「完全」と明記している場合、「完全または増分」とは明記していない場合、「完全 + 増分」と明記している場合は、replicate/replication ではなく migrate/migration を使用します。 @@ -78,7 +78,7 @@ TiDB データ移行ツールを使用して、アップストリーム デー リレーログとは、DM-workerが上流のMySQLまたはMariaDBから取得し、ローカルディスクに保存するbinlogファイルを指します。リレーログの形式は標準的なbinlogファイルであり、互換性のあるバージョンの[mysqlbinlog](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html)などのツールで解析できます。その役割は[MySQLリレーログ](https://dev.mysql.com/doc/refman/8.0/en/replica-logs-relaylog.html)および[MariaDB リレーログ](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log/relay-log)と同様です。 -リレー ログのディレクトリ構造、初期移行ルール、TiDB DM のデータ パージなどの詳細については、 [TiDB DMリレーログ](/dm/relay-log.md)を参照してください。 +リレーログのディレクトリ構造、初期移行ルール、TiDB DM のデータ パージなどの詳細については、 [TiDB DMリレーログ](/dm/relay-log.md)を参照してください。 ### リレー処理ユニット {#relay-processing-unit} @@ -98,8 +98,8 @@ TiDB データ移行ツールを使用して、上流データベースの**増 このモードは、次のいずれかの状況で有効になります。 -- タスク構成ファイルの`safe-mode`パラメータが`true`に設定されている場合、セーフ モードは有効なままになります。 -- シャードマージのシナリオでは、すべてのシャードテーブルで DDL ステートメントが複製される前は、セーフ モードが有効なままになります。 +- タスク構成ファイルの`safe-mode`パラメータが`true`に設定されている場合、セーフモードは有効なままになります。 +- シャードマージのシナリオでは、すべてのシャードテーブルで DDL ステートメントが複製される前は、セーフモードが有効なままになります。 - 完全移行タスクのダンプ処理単位に引数`--consistency none`が設定されている場合、エクスポート開始時のbinlogの変更がエクスポートされたデータに影響を与えるかどうかを判断できません。そのため、これらのbinlogの変更の増分レプリケーションではセーフモードが有効なままになります。 - タスクがエラーによって一時停止され、その後再開された場合、一部のデータに対する操作が 2 回実行される可能性があります。 diff --git a/dm/dm-handle-alerts.md b/dm/dm-handle-alerts.md index 808a9c6098358..7521961d0411a 100644 --- a/dm/dm-handle-alerts.md +++ b/dm/dm-handle-alerts.md @@ -13,14 +13,14 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - すべての DM マスター ノードがオフラインの場合、このアラートがトリガーされます。 + すべての DM マスターノードがオフラインの場合、このアラートがトリガーされます。 - 解決： アラートを処理するには、次の手順を実行できます。 1. クラスターの環境を確認します。 - 2. トラブルシューティングのために、すべての DM マスター ノードのログを確認してください。 + 2. トラブルシューティングのために、すべての DM マスターノードのログを確認してください。 ### `DM_worker_offline` {#dm-worker-offline} @@ -32,7 +32,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 アラートを処理するには、次の手順を実行できます。 - 1. 対応する DM ワーカー ノードの動作ステータスを確認する。 + 1. 対応する DM ワーカーノードの動作ステータスを確認する。 2. ノードが接続されているかどうかを確認します。 3. ログを通じてエラーをトラブルシューティングします。 @@ -74,7 +74,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - リレー ログ処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に回復可能なエラー (例: ネットワークの問題) が複数発生した場合 (例: 2 分間に 3 回以上)、このアラートがトリガーされます。 + リレーログ処理ユニットで自動回復不可能なエラー (例: binlogファイルが見つからない) が発生した場合、または短時間に回復可能なエラー (例: ネットワークの問題) が複数発生した場合 (例: 2 分間に 3 回以上)、このアラートがトリガーされます。 - 解決： @@ -118,7 +118,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - リレー ログ処理ユニットがbinlogイベントをリレー ログ ファイルに書き込むときにエラーが発生すると、このユニットは`Paused`状態に移行し、アラートがトリガーされます。 + リレーログ処理ユニットがbinlogイベントをリレーログファイルに書き込むときにエラーが発生すると、このユニットは`Paused`状態に移行し、アラートがトリガーされます。 - 解決： @@ -128,7 +128,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレー ログ処理ユニットによってプルされた最新のbinlogファイルの数を 10 分間で 1**以上**超過すると、アラートがトリガーされます。 + 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレーログ処理ユニットによってプルされた最新のbinlogファイルの数を 10 分間で 1**以上**超過すると、アラートがトリガーされます。 - 解決： @@ -172,7 +172,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 - 説明： - 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレー ログ処理装置で処理された最新のbinlogファイルの数を 10 分間で 1**以上**超えると、アラートがトリガーされます。 + 現在のアップストリーム MySQL/MariaDB のbinlogファイルの数が、リレーログ処理装置で処理された最新のbinlogファイルの数を 10 分間で 1**以上**超えると、アラートがトリガーされます。 - 解決： diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index e0b05a665fc4d..7d7a08d265b24 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データを読み取るプロセスには、次のサブプロセスが含まれます。 @@ -66,7 +66,7 @@ Binlogレプリケーションユニットのパフォーマンス問題を診 Binlogレプリケーションユニットは、設定に応じて、上流のMySQL/MariaDBからbinlogイベントを読み取るか、リレーログファイルから読み取るかを決定します。関連するパフォーマンスメトリックは`read binlog event duration`で、通常は数マイクロ秒から数十マイクロ秒の範囲です。 -- DM のBinlogレプリケーション処理ユニットがアップストリーム MySQL/MariaDB からbinlogイベントを読み取る場合、問題を特定して解決するには、「リレー ログ ユニット」セクションの[binlogデータを読み取る](#read-binlog-data)を参照してください。 +- DM のBinlogレプリケーション処理ユニットがアップストリーム MySQL/MariaDB からbinlogイベントを読み取る場合、問題を特定して解決するには、「リレーログユニット」セクションの[binlogデータを読み取る](#read-binlog-data)を参照してください。 - DMのBinlogレプリケーション処理ユニットがリレーログファイルからbinlogイベントを読み取る場合、 `binlog event size`が大きすぎない場合、 `read binlog event duration`の値はマイクロ秒単位にする必要があります。`read binlog event duration`が大きすぎる場合は、ディスクの読み取りパフォーマンスを確認してください。書き込みパフォーマンスの低下を回避するには、DMワーカーにローカルSSDを使用してください。 @@ -78,7 +78,7 @@ Binlogレプリケーションユニットは、DMLを構築し、DDLを解析 ### 下流にSQL文を書き込む {#write-sql-statements-to-downstream} -Binlogレプリケーション ユニットが変換された SQL ステートメントをダウンストリームに書き込む場合、関連するパフォーマンス メトリックは`DML queue remain length`と`transaction execution latency`なります。 +Binlogレプリケーション ユニットが変換された SQL ステートメントをダウンストリームに書き込む場合、関連するパフォーマンスメトリックは`DML queue remain length`と`transaction execution latency`なります。 DMはbinlogイベントからSQL文を構築した後、 `worker-count`キューを使用してこれらの文を下流に同時に書き込みます。ただし、監視エントリが過度に多くなりすぎないようにするため、DMは同時キューのIDに対して`8`を法とする演算を実行します。つまり、すべての同時キューは`q_0`から`q_7`までの1つのアイテムに対応します。 diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md index f9bb0e3ac9c73..c5270bc5b5570 100644 --- a/dm/dm-manage-schema.md +++ b/dm/dm-manage-schema.md @@ -9,26 +9,26 @@ summary: DM で移行するテーブルのスキーマを管理する方法を DMが増分レプリケーションを実行する際、まず上流のbinlogを読み取り、SQL文を作成して下流で実行します。ただし、上流のbinlogには完全なテーブルスキーマは含まれていません。SQL文を生成するために、DMは移行対象のテーブルのスキーマ情報を内部的に保持します。これを内部テーブルスキーマと呼びます。 -特別な状況に対処したり、テーブル スキーマの不一致によって発生する移行の中断を処理したりするために、DM は内部テーブル スキーマを取得、変更、および削除する`binlog-schema`コマンドを提供します。 +特別な状況に対処したり、テーブルスキーマの不一致によって発生する移行の中断を処理したりするために、DM は内部テーブルスキーマを取得、変更、および削除する`binlog-schema`コマンドを提供します。 ## 実装原理 {#implementation-principles} -内部テーブル スキーマは次のソースから取得されます。 +内部テーブルスキーマは次のソースから取得されます。 - 完全データ移行（ `task-mode=all` ）では、移行タスクはダンプ/ロード/同期の3段階（完全エクスポート、完全インポート、増分レプリケーション）を経ます。ダンプ段階では、DMはデータとともにテーブルスキーマ情報をエクスポートし、下流の対応するテーブルを自動的に作成します。同期段階では、このテーブルスキーマが増分レプリケーションの開始テーブルスキーマとして使用されます。 -- 同期ステージでは、DM が`ALTER TABLE`などの DDL ステートメントを処理するときに、同時に内部テーブル スキーマを更新します。 +- 同期ステージでは、DM が`ALTER TABLE`などの DDL ステートメントを処理するときに、同時に内部テーブルスキーマを更新します。 - タスクが増分移行（ `task-mode=incremental` ）の場合、下流のデータベースで移行対象のテーブルの作成が完了していると、DMは下流のデータベースからテーブルスキーマ情報を取得します。この動作はDMのバージョンによって異なります。 増分レプリケーションでは、スキーマのメンテナンスが複雑になります。データレプリケーション全体を通して、以下の4つのテーブルスキーマが関係します。これらのスキーマは、互いに整合性が取れている場合もあれば、不整合になっている場合もあります。 ![schema](/media/dm/operate-schema.png) -- 現在の時点のアップストリーム テーブル スキーマ`schema-U`として識別されます。 +- 現在の時点のアップストリームテーブルスキーマ`schema-U`として識別されます。 - 現在DMで消費されているbinlogイベントのテーブルスキーマ（ `schema-B`で識別）。このスキーマは、過去の時点のアップストリームテーブルスキーマに対応しています。 -- 現在 DM (スキーマ トラッカーコンポーネント) で管理されているテーブル スキーマ`schema-I`として識別されます。 -- ダウンストリーム TiDB クラスター内のテーブル スキーマ`schema-D`として識別)。 +- 現在 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`整合性を維持します。 @@ -38,7 +38,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを - 下流テーブルに上流テーブルよりも多くの列がある場合、 `schema-D` `schema-B`および`schema-I`と不整合になる可能性があります。完全なデータ移行（ `task-mode=all` ）では、DMが自動的に不整合を処理します。増分移行（ `task-mode=incremental` ）では、タスクが初めて開始され、内部スキーマ情報がまだないため、DMは自動的に下流スキーマ（ `schema-D` ）を読み取り、 `schema-I`を更新します（この動作はDMのバージョンによって異なります）。その後、DMが`schema-I`を使用して`schema-B`のbinlogを解析すると、 `Column count doesn't match value count`エラーが報告されます。詳細については、 [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md)を参照してください。 -`binlog-schema`コマンドを実行して、DM で管理されている`schema-I`テーブル スキーマを取得、変更、または削除できます。 +`binlog-schema`コマンドを実行して、DM で管理されている`schema-I`テーブルスキーマを取得、変更、または削除できます。 > **Note:** > @@ -72,14 +72,14 @@ Use "dmctl binlog-schema [command] --help" for more information about a command. > **Note:** > -> - データ移行中にテーブル スキーマが変更される可能性があるため、予測可能なテーブル スキーマを取得するには、現在、データ移行タスクが`Paused`状態にある場合にのみ`binlog-schema`コマンドを使用できます。 -> - 誤った取り扱いによるデータ損失を避けるため、スキーマを変更する前に、まずテーブル スキーマを取得してバックアップすること**を強くお勧めします**。 +> - データ移行中にテーブルスキーマが変更される可能性があるため、予測可能なテーブルスキーマを取得するには、現在、データ移行タスクが`Paused`状態にある場合にのみ`binlog-schema`コマンドを使用できます。 +> - 誤った取り扱いによるデータ損失を避けるため、スキーマを変更する前に、まずテーブルスキーマを取得してバックアップすること**を強くお勧めします**。 ## パラメータ {#parameters} -- `delete` : テーブル スキーマを削除します。 -- `list` : テーブル スキーマを一覧表示します。 -- `update` : テーブル スキーマを更新します。 +- `delete` : テーブルスキーマを削除します。 +- `list` : テーブルスキーマを一覧表示します。 +- `update` : テーブルスキーマを更新します。 - `-s`または`--source` : - 必須。 - 操作が適用される MySQL ソースを指定します。 @@ -88,7 +88,7 @@ Use "dmctl binlog-schema [command] --help" for more information about a command. ### テーブルスキーマを取得する {#get-the-table-schema} -テーブル スキーマを取得するには、コマンド`binlog-schema list`を実行します。 +テーブルスキーマを取得するには、コマンド`binlog-schema list`を実行します。 ```bash help binlog-schema list @@ -107,7 +107,7 @@ Global Flags: -s, --source strings MySQL Source ID. ``` -`db_single`タスク内の`mysql-replica-01` MySQL ソースに対応する`` `db_single`.`t1` ``テーブルのテーブル スキーマを取得する場合は、次のコマンドを実行します。 +`db_single`タスク内の`mysql-replica-01` MySQL ソースに対応する`` `db_single`.`t1` ``テーブルのテーブルスキーマを取得する場合は、次のコマンドを実行します。 ```bash binlog-schema list -s mysql-replica-01 task_single db_single t1 @@ -130,7 +130,7 @@ binlog-schema list -s mysql-replica-01 task_single db_single t1 ### テーブルスキーマを更新する {#update-the-table-schema} -テーブル スキーマを更新するには、 `binlog-schema update`コマンドを実行します。 +テーブルスキーマを更新するには、 `binlog-schema update`コマンドを実行します。 ```bash help binlog-schema update @@ -186,7 +186,7 @@ operate-schema set -s mysql-replica-01 task_single -d db_single -t t1 db_single. ### テーブルスキーマを削除する {#delete-the-table-schema} -テーブル スキーマを削除するには、 `binlog-schema delete`コマンドを実行します。 +テーブルスキーマを削除するには、 `binlog-schema delete`コマンドを実行します。 ```bash help binlog-schema delete @@ -207,13 +207,13 @@ Global Flags: > **Note:** > -> DM で管理されているテーブル スキーマが削除された後、このテーブルに関連する DDL/DML ステートメントをダウンストリームに移行する必要がある場合、DM は次の 3 つのソースからテーブル スキーマを順番に取得しようとします。 +> DM で管理されているテーブルスキーマが削除された後、このテーブルに関連する DDL/DML ステートメントをダウンストリームに移行する必要がある場合、DM は次の 3 つのソースからテーブルスキーマを順番に取得しようとします。 > > - チェックポイントテーブルの`table_info`フィールド > - 楽観的シャーディングDDLのメタ情報 > - 下流TiDBの対応するテーブル -`db_single`タスク内の`mysql-replica-01` MySQL ソースに対応する`` `db_single`.`t1` ``テーブルのテーブル スキーマを削除する場合は、次のコマンドを実行します。 +`db_single`タスク内の`mysql-replica-01` MySQL ソースに対応する`` `db_single`.`t1` ``テーブルのテーブルスキーマを削除する場合は、次のコマンドを実行します。 ```bash binlog-schema delete -s mysql-replica-01 task_single db_single t1 diff --git a/dm/dm-manage-source.md b/dm/dm-manage-source.md index 7aeed007fad2a..3e2a64104b596 100644 --- a/dm/dm-manage-source.md +++ b/dm/dm-manage-source.md @@ -5,7 +5,7 @@ summary: TiDB データ移行でアップストリーム MySQL インスタン # TiDB データ移行におけるデータソース構成の管理 {#manage-data-source-configurations-in-tidb-data-migration} -このドキュメントでは、MySQL パスワードの暗号化、データ ソースの操作、 [dmctl](/dm/dmctl-introduction.md)を使用したアップストリーム MySQL インスタンスと DM ワーカー間のバインディングの変更など、データ ソース構成を管理する方法について説明します。 +このドキュメントでは、MySQL パスワードの暗号化、データソースの操作、 [dmctl](/dm/dmctl-introduction.md)を使用したアップストリーム MySQL インスタンスと DM ワーカー間のバインディングの変更など、データソース構成を管理する方法について説明します。 ## データベースのパスワードを暗号化する {#encrypt-the-database-password} @@ -25,7 +25,7 @@ MKxn0Qo3m3XOyjCnhEMtsUCm83EhGQDZ/T4= ## データソースを操作する {#operate-data-source} -`operate-source`コマンドを使用して、データ ソース構成を DM クラスターにロード、一覧表示、または削除できます。 +`operate-source`コマンドを使用して、データソース構成を DM クラスターにロード、一覧表示、または削除できます。 ```bash help operate-source @@ -51,9 +51,9 @@ Global Flags: - `stop` : 1つ以上の上流データベースソースを停止します。複数のデータソースの停止に失敗した場合、一部のデータソースが停止される可能性があります。 -- `show` : 追加されたデータ ソースと対応する DM ワーカーを表示します。 +- `show` : 追加されたデータソースと対応する DM ワーカーを表示します。 -- `config-file` : `source.yaml`のファイル パスを指定し、複数のファイル パスを渡すことができます。 +- `config-file` : `source.yaml`のファイルパスを指定し、複数のファイルパスを渡すことができます。 - `--print-sample-config` : サンプル設定ファイルを印刷します。このパラメータは他のパラメータを無視します。 @@ -90,7 +90,7 @@ operate-source create ./source.yaml > > `config`コマンドは DM v6.0 以降のバージョンでのみサポートされます。それ以前のバージョンでは、 `get-config`コマンドを使用する必要があります。 -`source-id`がわかっている場合は、 `dmctl --master-addr config source `を実行してデータ ソース構成を取得できます。 +`source-id`がわかっている場合は、 `dmctl --master-addr config source `を実行してデータソース構成を取得できます。 ```bash config source mysql-replica-01 @@ -111,7 +111,7 @@ config source mysql-replica-01 } ``` -`source-id`がわからない場合は、まず`dmctl --master-addr operate-source show`を実行してすべてのデータ ソースを一覧表示できます。 +`source-id`がわからない場合は、まず`dmctl --master-addr operate-source show`を実行してすべてのデータソースを一覧表示できます。 ```bash operate-source show diff --git a/dm/dm-master-configuration-file.md b/dm/dm-master-configuration-file.md index ae7b055c81709..c8b66e73077d0 100644 --- a/dm/dm-master-configuration-file.md +++ b/dm/dm-master-configuration-file.md @@ -50,7 +50,7 @@ secret-key-path = "/path/to/secret/key" #### `log-level` {#log-level} -- ログ レベルを指定します。 +- ログレベルを指定します。 - デフォルト値: `info` - `fatal` `warn` `info` `error` `debug` @@ -68,7 +68,7 @@ secret-key-path = "/path/to/secret/key" #### `peer-urls` {#peer-urls} -- DM マスター ノードのピア URL を指定します。 +- DM マスターノードのピア URL を指定します。 #### `advertise-peer-urls` {#advertise-peer-urls} @@ -76,7 +76,7 @@ secret-key-path = "/path/to/secret/key" #### `initial-cluster` {#initial-cluster} -- 値`initial-cluster`は、初期クラスター内のすべての DM マスター ノードの[`advertise-peer-urls`](#advertise-peer-urls)値の組み合わせです。 +- 値`initial-cluster`は、初期クラスター内のすべての DM マスターノードの[`advertise-peer-urls`](#advertise-peer-urls)値の組み合わせです。 #### `join` {#join} diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index 363ef39d3731d..4785ee308010f 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -15,7 +15,7 @@ OpenAPI を有効にするには、次のいずれかの操作を実行します openapi = true ``` -- DM クラスターがTiUPを使用してデプロイされている場合は、トポロジ ファイルに次の構成を追加します。 +- DM クラスターがTiUPを使用してデプロイされている場合は、トポロジファイルに次の構成を追加します。 ```yaml server_configs: @@ -27,7 +27,7 @@ OpenAPI を有効にするには、次のいずれかの操作を実行します > > - DMはOpenAPI 3.0.0標準に準拠した[仕様書](https://github.com/pingcap/tiflow/blob/release-8.5/dm/openapi/spec/dm.yaml)提供します。このドキュメントには、すべてのリクエストパラメータと戻り値が含まれています。このドキュメントのyamlをコピーして、 [Swaggerエディター](https://editor.swagger.io/)でプレビューできます。 > -> - DM マスター ノードを展開した後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 +> - DM マスターノードを展開した後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 > > - 設定ファイルでサポートされている一部の機能は、OpenAPIではサポートされていません。これらの機能は完全には連携されていません。本番環境では、 [設定ファイル](/dm/dm-config-overview.md)を使用することをお勧めします。 @@ -78,7 +78,7 @@ API を使用して、DM クラスターで次のメンテナンス操作を実 ## APIエラーメッセージテンプレート {#api-error-message-template} -API リクエストの送信後にエラーが発生した場合、返されるエラー メッセージは次の形式になります。 +API リクエストの送信後にエラーが発生した場合、返されるエラーメッセージは次の形式になります。 ```json { @@ -87,7 +87,7 @@ API リクエストの送信後にエラーが発生した場合、返される } ``` -上記の JSON 出力では、 `error_msg`エラー メッセージを示し、 `error_code`対応するエラー コードを示します。 +上記の JSON 出力では、 `error_msg`エラーメッセージを示し、 `error_code`対応するエラーコードを示します。 ## DMマスターノードの情報を取得する {#get-the-information-of-a-dm-master-node} @@ -348,7 +348,7 @@ curl -X 'DELETE' \ > **Note:** > -> この API を使用してデータ ソース構成を更新する場合は、現在のデータ ソースで実行中のタスクがないことを確認してください。 +> この API を使用してデータソース構成を更新する場合は、現在のデータソースで実行中のタスクがないことを確認してください。 ### リクエストURI {#request-uri} @@ -424,7 +424,7 @@ curl -X 'PUT' \ ## データソースを有効にする {#enable-a-data-source} -これは、リクエストが成功するとデータ ソースを有効にし、このデータ ソースに依存するタスクのすべてのサブタスクをバッチで開始する同期インターフェイスです。 +これは、リクエストが成功するとデータソースを有効にし、このデータソースに依存するタスクのすべてのサブタスクをバッチで開始する同期インターフェイスです。 ### リクエストURI {#request-uri} @@ -441,7 +441,7 @@ curl -X 'POST' \ ## データソースを無効にする {#disable-a-data-source} -これは、リクエストが成功するとこのデータ ソースを非アクティブ化し、それに依存するタスクのすべてのサブタスクをバッチで停止する同期インターフェイスです。 +これは、リクエストが成功するとこのデータソースを非アクティブ化し、それに依存するタスクのすべてのサブタスクをバッチで停止する同期インターフェイスです。 ### リクエストURI {#request-uri} @@ -1008,7 +1008,7 @@ curl -X 'GET' \ ## レプリケーションタスクを削除する {#delete-a-replication-task} -このインターフェースは同期インターフェースであり、要求が成功すると返される本体のステータス コードは 204 になります。 +このインターフェースは同期インターフェースであり、要求が成功すると返される本体のステータスコードは 204 になります。 ### リクエストURI {#request-uri} diff --git a/dm/dm-pause-task.md b/dm/dm-pause-task.md index 44fb269ff6bb2..70e2772e0f577 100644 --- a/dm/dm-pause-task.md +++ b/dm/dm-pause-task.md @@ -39,7 +39,7 @@ pause-task [-s "mysql-replica-01"] task-name ## フラグの説明 {#flags-description} - `-s` : (オプション) 移行タスクのサブタスクを一時停止するMySQLソースを指定します。設定されている場合、このコマンドは指定されたMySQLソースのサブタスクのみを一時停止します。 -- `task-name| task-file` : (必須) タスク名またはタスク ファイル パスを指定します。 +- `task-name| task-file` : (必須) タスク名またはタスク ファイルパスを指定します。 ## 返された結果 {#returned-results} diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md index f5345a42504f1..ebc71023bb885 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -13,7 +13,7 @@ MySQL -> DM -> TiDB という単純な移行データフローを使用し ## テスト環境をデプロイ {#deploy-test-environment} -- すべてのデフォルト構成で、 TiUPを使用して TiDB テスト クラスターをデプロイ。 +- すべてのデフォルト構成で、 TiUPを使用して TiDB テストクラスターをデプロイ。 - MySQL サービスをデプロイ。binlogの`ROW`モードを有効にし、その他の設定項目はデフォルト設定を使用します。 - DM ワーカーと DM マスターを使用して DM クラスターをデプロイ。 @@ -95,7 +95,7 @@ DM-worker のログを確認してください。`all data files have been finis [INFO] [loader.go:604] ["all data files have been finished"] [task=test] [unit=load] ["cost time"=52.439796ms] ``` -テスト データのサイズとデータのインポートにかかる時間に応じて、完全なデータの移行速度を計算できます。 +テストデータのサイズとデータのインポートにかかる時間に応じて、完全なデータの移行速度を計算できます。 ### 増分レプリケーションのベンチマークケース {#incremental-replication-benchmark-case} diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index 6d00fba122824..3290d33cbbbf6 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -137,7 +137,7 @@ tiup dmctl check-task ./task.yaml - `binlog_format=ROW`が設定されているかどうかを確認してください（DMはROW形式のbinlogの移行のみをサポートしています）。 - `binlog_row_image=FULL`が設定されているかどうかを確認してください (DM は`binlog_row_image=FULL`のみをサポートしています)。 - `binlog_transaction_compression=OFF`が設定されているかどうかを確認してください (DM はトランザクション圧縮をサポートしていません)。 - - `binlog_do_db`または`binlog_ignore_db`が設定されている場合は、移行対象のデータベース テーブルが`binlog_do_db`および`binlog_ignore_db`の条件を満たしているかどうかを確認します。 + - `binlog_do_db`または`binlog_ignore_db`が設定されている場合は、移行対象のデータベーステーブルが`binlog_do_db`および`binlog_ignore_db`の条件を満たしているかどうかを確認します。 - （必須）MariaDBbinlogの設定 @@ -145,7 +145,7 @@ tiup dmctl check-task ./task.yaml - `binlog_legacy_event_pos`が`ON`に設定されているかどうかを確認してください。 - `binlog_format=ROW`が設定されているかどうかを確認してください（DMはROW形式のbinlogの移行のみをサポートしています）。 - `binlog_row_image=FULL`が設定されているかどうかを確認してください (DM は`binlog_row_image=FULL`のみをサポートしています)。 - - `binlog_do_db`または`binlog_ignore_db`が設定されている場合は、移行対象のデータベース テーブルが`binlog_do_db`および`binlog_ignore_db`の条件を満たしているかどうかを確認します。 + - `binlog_do_db`または`binlog_ignore_db`が設定されている場合は、移行対象のデータベーステーブルが`binlog_do_db`および`binlog_ignore_db`の条件を満たしているかどうかを確認します。 - `binlog_annotate_row_events`が`OFF`に設定されているかどうかを確認してください。 - `log_bin_compress`が`OFF`に設定されているかどうかを確認してください。 diff --git a/dm/dm-query-status.md b/dm/dm-query-status.md index 4fa4a4f04883e..ef05e75bc3911 100644 --- a/dm/dm-query-status.md +++ b/dm/dm-query-status.md @@ -48,7 +48,7 @@ summary: データ複製タスクのステータスを照会する方法を学 クエリ結果の一部のフィールドは次のように説明されます。 - `result` : クエリが成功したかどうか。 -- `msg` : クエリが失敗したときに返されるエラー メッセージ。 +- `msg` : クエリが失敗したときに返されるエラーメッセージ。 - `tasks` : 移行タスクのリスト。各タスクには以下のフィールドが含まれます。 - `taskName` : タスクの名前。 - `taskStatus` : タスクのステータス`taskStatus`の詳細については[タスクのステータス](#task-status)を参照してください。 @@ -220,7 +220,7 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた 返される結果の一部のフィールドは次のように説明されます。 - `result` : クエリが成功したかどうか。 -- `msg` : クエリが失敗したときに返されるエラー メッセージ。 +- `msg` : クエリが失敗したときに返されるエラーメッセージ。 - `sources` : アップストリーム MySQL インスタンスのリスト。各ソースには以下のフィールドが含まれます。 - `result` - `msg` @@ -238,7 +238,7 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - `syncerBinlogGtid` : GTID を使用して複製されたbinlogの位置。 - `blockingDDLs` : 現在ブロックされているDDLリスト。このDMワーカーのすべての上流テーブルが「同期済み」ステータスにある場合にのみ空になります。この場合、実行されるかスキップされるシャーディングDDL文を示します。 - `unresolvedGroups` : 解決されていないシャーディンググループ。各グループには以下のフィールドが含まれます。 - - `target` : 複製されるダウンストリーム データベース テーブル。 + - `target` : 複製されるダウンストリームデータベーステーブル。 - `DDLs` : DDL ステートメントのリスト。 - `firstPos` : シャーディング DDL ステートメントの開始位置。 - `synced` : 実行されたシャーディング DDL ステートメントが`Sync`ユニットによって読み取られた上流のシャーディングされたテーブル。 @@ -288,7 +288,7 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - `Finished` : - 完了したサブタスクのステータス。 - - 完全なレプリケーション サブタスクが正常に終了した場合にのみ、タスクはこのステータスに切り替わります。 + - 完全なレプリケーションサブタスクが正常に終了した場合にのみ、タスクはこのステータスに切り替わります。 ### ステータススイッチ図 {#status-switch-diagram} diff --git a/dm/dm-replication-logic.md b/dm/dm-replication-logic.md index 10191489dace2..0fa751f0098ef 100644 --- a/dm/dm-replication-logic.md +++ b/dm/dm-replication-logic.md @@ -11,12 +11,12 @@ summary: DM のコア処理ユニット Sync が DML ステートメントを複 同期ユニットは、DML ステートメントを次のように処理します。 -1. MySQL、MariaDB、またはリレー ログからbinlogイベントを読み取ります。 +1. MySQL、MariaDB、またはリレーログからbinlogイベントを読み取ります。 -2. データ ソースから読み取ったbinlogイベントを変換します。 +2. データソースから読み取ったbinlogイベントを変換します。 1. [Binlogフィルター](/dm/dm-binlog-event-filter.md) : `filters`で設定されたbinlog式に従ってbinlogイベントをフィルタリングします。 - 2. [テーブルルーティング](/dm/dm-table-routing.md) : `routes`で設定された「データベース/テーブル」ルーティング ルールに従って「データベース/テーブル」名を変換します。 + 2. [テーブルルーティング](/dm/dm-table-routing.md) : `routes`で設定された「データベース/テーブル」ルーティングルールに従って「データベース/テーブル」名を変換します。 3. [表現フィルター](/filter-dml-event.md) : `expression-filter`で設定された SQL 式に従ってbinlogイベントをフィルタリングします。 3. DML 実行計画を最適化します。 @@ -97,8 +97,8 @@ syncers: # The configuration parameters of the sync p DM には、上流と下流のスキーマ情報を記録するスキーマ トラッカーが組み込まれています。 -- DM は DDL ステートメントを受信すると、内部スキーマ トラッカーのテーブル スキーマを更新します。 -- DM は DML ステートメントを受信すると、スキーマ トラッカーのテーブル スキーマに従って対応する DML を生成します。 +- DM は DDL ステートメントを受信すると、内部スキーマ トラッカーのテーブルスキーマを更新します。 +- DM は DML ステートメントを受信すると、スキーマ トラッカーのテーブルスキーマに従って対応する DML を生成します。 DML 生成のロジックは次のとおりです。 @@ -107,7 +107,7 @@ DML 生成のロジックは次のとおりです。 - 増分タスクを開始する場合、MySQL binlog にはテーブル構造情報が記録されないため、Sync は**下流の対応するテーブルのテーブル構造を**上流の初期テーブル構造として使用します。 2. ユーザーの上流テーブルと下流テーブルの構造に不整合がある可能性があります。例えば、下流テーブルに上流テーブルよりも多くの列がある場合や、上流テーブルと下流テーブルの主キーが不整合な場合などです。そのため、データ複製の正確性を確保するために、DMは**対応するテーブルの主キーと一意キーの情報を下流テーブルに**記録します。 3. DM は DML を生成します。 - - **スキーマ トラッカーに記録されたアップストリーム テーブル構造**を使用して、DML ステートメントの列名を生成します。 + - **スキーマ トラッカーに記録されたアップストリームテーブル構造**を使用して、DML ステートメントの列名を生成します。 - **binlogに記録された列の値**を使用して、DML ステートメントの列の値を生成します。 - **スキーマトラッカーに記録されたダウンストリーム主キーまたは一意キー**を使用して、DML文の`WHERE`条件を生成します。テーブル構造に一意キーがない場合、DMはbinlogに記録されたすべての列値を`WHERE`条件として使用します。 @@ -143,9 +143,9 @@ DMは行レベルでデータを複製するため、トランザクションの DML実行とチェックポイント更新の操作はアトミックではなく、チェックポイント更新と下流へのデータ書き込みの操作もアトミックではありません。DMが異常終了した場合、チェックポイントは終了時刻より前のリカバリポイントのみを記録する可能性があります。そのため、タスクが再開されると、DMは同じデータを複数回書き込む可能性があります。これは、DMが実際には「少なくとも1回の処理」ロジックを提供していることを意味し、同じデータが複数回処理される可能性があります。 -データが再入可能であることを確認するために、DM は異常終了から再起動するときにセーフ モードに入ります。 +データが再入可能であることを確認するために、DM は異常終了から再起動するときにセーフモードに入ります。 -セーフ モードが有効になっている場合、データが複数回処理されることを確認するために、DM は次の変換を実行します。 +セーフモードが有効になっている場合、データが複数回処理されることを確認するために、DM は次の変換を実行します。 - アップストリームの`INSERT`のステートメントを`REPLACE`ステートメントに書き換えます。 - アップストリームの`UPDATE`ステートメントを`DELETE` + `REPLACE`ステートメントに書き換えます。 diff --git a/dm/dm-resume-task.md b/dm/dm-resume-task.md index b9f691a12b58e..b19c88c850f2d 100644 --- a/dm/dm-resume-task.md +++ b/dm/dm-resume-task.md @@ -33,7 +33,7 @@ resume-task [-s "mysql-replica-01"] task-name ## フラグの説明 {#flags-description} - `-s` : (オプション) 移行タスクのサブタスクを再開するMySQLソースを指定します。設定されている場合、コマンドは指定されたMySQLソースのサブタスクのみを再開します。 -- `task-name | task-file` : (必須) タスク名またはタスク ファイル パスを指定します。 +- `task-name | task-file` : (必須) タスク名またはタスク ファイルパスを指定します。 ## 返された結果 {#returned-results} diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index 8be21991f71b2..f631e43ca276d 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -58,11 +58,11 @@ DMはSQL文を書き換えることで、重複挿入または更新操作を実 DMがチェックポイントから増分レプリケーションタスクを再開する場合（例えば、DMワーカーの再起動やネットワークの再接続など）、DMは自動的に一定期間（デフォルトでは60秒）セーフモードを有効にします。 -セーフモードを有効にするかどうかは、チェックポイント内の`safemode_exit_point`に関連しています。増分レプリケーション タスクが異常に一時停止された場合、DM はメモリ内のすべての DML ステートメントをダウンストリームにレプリケートしようとし、DML ステートメントの中で最新のbinlog位置を`safemode_exit_point`として記録し、最後のチェックポイントに保存します。 +セーフモードを有効にするかどうかは、チェックポイント内の`safemode_exit_point`に関連しています。増分レプリケーションタスクが異常に一時停止された場合、DM はメモリ内のすべての DML ステートメントをダウンストリームにレプリケートしようとし、DML ステートメントの中で最新のbinlog位置を`safemode_exit_point`として記録し、最後のチェックポイントに保存します。 詳細なロジックは以下のとおりです。 -- チェックポイントに`safemode_exit_point`が含まれている場合、増分レプリケーション タスクは異常に一時停止されます。 DM がタスクを再開すると、再開するチェックポイントのbinlog位置 (**開始位置**) が`safemode_exit_point`より前になります。これは、開始位置と`safemode_exit_point`の間のbinlogイベントが下流で処理されている可能性があることを示しています。そのため、再開処理中に一部のbinlogイベントが繰り返し実行される可能性があります。したがって、セーフ モードを有効にすると、これらのbinlog位置を**安全**にすることができます。binlog位置が`safemode_exit_point`を超えると、セーフ モードが手動で有効にされない限り、DM は自動的にセーフ モードを無効にします。 +- チェックポイントに`safemode_exit_point`が含まれている場合、増分レプリケーションタスクは異常に一時停止されます。 DM がタスクを再開すると、再開するチェックポイントのbinlog位置 (**開始位置**) が`safemode_exit_point`より前になります。これは、開始位置と`safemode_exit_point`の間のbinlogイベントが下流で処理されている可能性があることを示しています。そのため、再開処理中に一部のbinlogイベントが繰り返し実行される可能性があります。したがって、セーフモードを有効にすると、これらのbinlog位置を**安全**にすることができます。binlog位置が`safemode_exit_point`を超えると、セーフモードが手動で有効にされない限り、DM は自動的にセーフモードを無効にします。 - チェックポイントに`safemode_exit_point`が含まれていない場合、次の 2 つのケースが考えられます。 @@ -71,7 +71,7 @@ DMがチェックポイントから増分レプリケーションタスクを再 2番目のケースでは、DMはチェックポイント後のどのbinlogイベントがダウンストリームで実行されるかを把握できません。繰り返し実行されるbinlogイベントが問題を引き起こさないようにするため、DMは最初の2つのチェックポイント間隔の間、自動的にセーフモードを有効にします。2つのチェックポイント間のデフォルトの間隔は30秒です。つまり、通常の増分レプリケーションタスクが開始されると、最初の60秒間（2×30秒）はセーフモードが適用されます。 - 通常、増分レプリケーション タスクの開始時にセーフ モード期間を調整するためにチェックポイント間隔を変更することはお勧めできません。ただし、変更が必要な場合は、[セーフモードを手動で有効にする](#manually-enable)(推奨)か、同期設定の`checkpoint-flush-interval`項目を変更できます。 + 通常、増分レプリケーションタスクの開始時にセーフモード期間を調整するためにチェックポイント間隔を変更することはお勧めできません。ただし、変更が必要な場合は、[セーフモードを手動で有効にする](#manually-enable)(推奨)か、同期設定の`checkpoint-flush-interval`項目を変更できます。 ### 手動で有効化 {#manually-enable} @@ -99,7 +99,7 @@ mysql-instances: > > この機能は実験的です。本番環境での使用は推奨されません。予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tiflow/issues)を報告してください。 -セーフ モードを有効にしてダウンストリーム タスク セッションで`foreign_key_checks=1`を設定すると、 `DELETE`ステートメントのデフォルトの`REPLACE` + `UPDATE`書き換えにより、子行に意図しない`ON DELETE CASCADE`の影響が発生する可能性があります。v8.5.6 以降、DM ではこの問題に対処するために以下の改善が導入されています。 +セーフモードを有効にしてダウンストリーム タスク セッションで`foreign_key_checks=1`を設定すると、 `DELETE`ステートメントのデフォルトの`REPLACE` + `UPDATE`書き換えにより、子行に意図しない`ON DELETE CASCADE`の影響が発生する可能性があります。v8.5.6 以降、DM ではこの問題に対処するために以下の改善が導入されています。 ### 非キー`UPDATE`最適化 {#non-key-update-optimization} @@ -136,9 +136,9 @@ REPLACE INTO dummydb.dummytbl (id, int_value, ...) VALUES (123, 888999, ...); - ### 複数ワーカーの外部キー因果関係 {#multi-worker-foreign-key-causality} -`foreign_key_checks=1`、`worker-count > 1` で、レプリケーション タスクに外部キーを持つテーブルが含まれている場合、タスクの開始時に DM は下流の`CREATE TABLE`スキーマから外部キーの関係を読み取ります。DM は、各 DML 操作に対して、これらの関係に基づいて因果関係キーを挿入します。これにより、DM によって親行とその子行に対する操作が同じ DML ワーカー キューに割り当てられることが保証されます。 +`foreign_key_checks=1`、`worker-count > 1` で、レプリケーションタスクに外部キーを持つテーブルが含まれている場合、タスクの開始時に DM は下流の`CREATE TABLE`スキーマから外部キーの関係を読み取ります。DM は、各 DML 操作に対して、これらの関係に基づいて因果関係キーを挿入します。これにより、DM によって親行とその子行に対する操作が同じ DML ワーカー キューに割り当てられることが保証されます。 -v8.5.7 以降、このモードでは、DM はスキーマ名またはテーブル名の変更などの静的な 1 対 1 のテーブル ルーティングをサポートします。DM は引き続き、タスク内の複数のソース テーブルを同じターゲット テーブルにマップするルーティング ルールを拒否します。 +v8.5.7 以降、このモードでは、DM はスキーマ名またはテーブル名の変更などの静的な 1 対 1 のテーブルルーティングをサポートします。DM は引き続き、タスク内の複数のソーステーブルを同じターゲットテーブルにマップするルーティングルールを拒否します。 詳細な制約については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)を参照してください。 diff --git a/dm/dm-shard-merge.md b/dm/dm-shard-merge.md index 46318ae408260..607e801286425 100644 --- a/dm/dm-shard-merge.md +++ b/dm/dm-shard-merge.md @@ -5,7 +5,7 @@ summary: DM のシャードマージ機能について学習します。 # TiDB データ移行シャードマージ {#tidb-data-migration-shard-merge} -TiDB Data Migration (DM) は、アップストリーム MySQL/MariaDB シャード テーブル内の DML および DDL データのマージと、マージされたデータのダウンストリーム TiDB テーブルへの移行をサポートします。 +TiDB Data Migration (DM) は、アップストリーム MySQL/MariaDB シャードテーブル内の DML および DDL データのマージと、マージされたデータのダウンストリーム TiDB テーブルへの移行をサポートします。 小さなデータセットの MySQL シャードを TiDB に移行してマージする必要がある場合は、 [このチュートリアル](/migrate-small-mysql-shards-to-tidb.md)を参照してください。 diff --git a/dm/dm-source-configuration-file.md b/dm/dm-source-configuration-file.md index b2eec52c3d31c..3b1dcb1dc71b9 100644 --- a/dm/dm-source-configuration-file.md +++ b/dm/dm-source-configuration-file.md @@ -92,7 +92,7 @@ from: #### `relay-dir` {#relay-dir} -- リレー ログ ディレクトリを指定します。 +- リレーログディレクトリを指定します。 - デフォルト値: `"./relay_log"` #### `host` {#host} @@ -121,13 +121,13 @@ from: #### `interval` {#interval} -- リレー ログの有効期限を定期的にチェックする間隔 (秒単位) を指定します。 +- リレーログの有効期限を定期的にチェックする間隔 (秒単位) を指定します。 - デフォルト値: `3600` - 単位: 秒 #### `expires` {#expires} -- リレー ログの有効期限を指定します。 +- リレーログの有効期限を指定します。 - リレー処理ユニットによって書き込まれていない、または既存のデータ移行タスクによって読み取る必要がないリレーログは、有効期限を過ぎるとDMによって削除されます。このパラメータが指定されていない場合、自動パージは実行されません。 - デフォルト値: `0` - 単位: 時間 @@ -160,7 +160,7 @@ DMは定期的に現在のタスクステータスとエラーメッセージを ### Binlogイベントフィルター {#binlog-event-filter} -DM v2.0.2 以降では、ソース構成ファイルでbinlogイベント フィルターを構成できます。 +DM v2.0.2 以降では、ソース構成ファイルでbinlogイベントフィルターを構成できます。 #### `case-sensitive` {#case-sensitive} diff --git a/dm/dm-stop-task.md b/dm/dm-stop-task.md index c54a029ee063a..085ee8380df78 100644 --- a/dm/dm-stop-task.md +++ b/dm/dm-stop-task.md @@ -33,7 +33,7 @@ stop-task [-s "mysql-replica-01"] task-name ## フラグの説明 {#flags-description} - `-s` : (オプション) 停止する移行タスクのサブタスクが実行されるMySQLソースを指定します。このパラメータが設定されている場合、指定されたMySQLソース上のサブタスクのみが停止されます。 -- `task-name | task-file` : (必須) タスク名またはタスク ファイル パスを指定します。 +- `task-name | task-file` : (必須) タスク名またはタスク ファイルパスを指定します。 ## 返された結果 {#returned-results} diff --git a/dm/dm-table-routing.md b/dm/dm-table-routing.md index 7506c2d01c7e3..7c2ec1673c567 100644 --- a/dm/dm-table-routing.md +++ b/dm/dm-table-routing.md @@ -1,15 +1,15 @@ --- title: TiDB Data Migration Table Routing -summary: DM におけるテーブル ルーティングの使用方法と注意事項を学びます。 +summary: DM におけるテーブルルーティングの使用方法と注意事項を学びます。 --- # TiDB Data Migrationテーブルルーティング {#tidb-data-migration-table-routing} -TiDB Data Migration (DM) を使用してデータを移行する場合、テーブル ルーティングを構成して、アップストリーム MySQL または MariaDB インスタンスの特定のテーブルをダウンストリームの指定されたテーブルに移行できます。 +TiDB Data Migration (DM) を使用してデータを移行する場合、テーブルルーティングを構成して、アップストリーム MySQL または MariaDB インスタンスの特定のテーブルをダウンストリームの指定されたテーブルに移行できます。 > **Note:** > -> - 1 つのテーブルに対して複数の異なるルーティング ルールを構成することはサポートされていません。 +> - 1 つのテーブルに対して複数の異なるルーティングルールを構成することはサポートされていません。 > - セクション[テーブルルーティングを構成する](#configure-table-routing)の`rule-2`に示すように、 `CREATE/DROP SCHEMA xx`を移行するために使用されるスキーマの一致ルールを個別に構成する必要があります。 ## テーブルルーティングを構成する {#configure-table-routing} @@ -88,9 +88,9 @@ routes: アップストリームインスタンスをダウンストリーム`test`.`t`に移行するには、前のセクション[シャーディングされたスキーマとテーブルをマージする](#merge-sharded-schemas-and-tables)と同様のルーティングルールを作成する必要があります。さらに、 `extract-table` 、 `extract-schema` 、および`extract-source`設定を追加する必要があります。 -- `extract-table` : `schema-pattern`と`table-pattern`に一致するシャード テーブルの場合、DM は`table-regexp`を使用してシャード テーブル名を抽出し、 `t_`部分を除いた名前サフィックスを結合されたテーブルの`target-column` (つまり、 `c_table`列) に書き込みます。 +- `extract-table` : `schema-pattern`と`table-pattern`に一致するシャードテーブルの場合、DM は`table-regexp`を使用してシャードテーブル名を抽出し、 `t_`部分を除いた名前サフィックスを結合されたテーブルの`target-column` (つまり、 `c_table`列) に書き込みます。 - `extract-schema` : `schema-pattern`と`table-pattern`に一致するシャード スキーマの場合、DM は`schema-regexp`を使用してシャード スキーマ名を抽出し、 `test_`部分を除いた名前サフィックスを、結合されたテーブルの`target-column` (つまり、 `c_schema`列) に書き込みます。 -- `extract-source` : `schema-pattern`と`table-pattern`に一致するシャード テーブルの場合、DM はソース インスタンス情報をマージされたテーブルの`target-column` 、つまり`c_source`列に書き込みます。 +- `extract-source` : `schema-pattern`と`table-pattern`に一致するシャードテーブルの場合、DM はソースインスタンス情報をマージされたテーブルの`target-column` 、つまり`c_source`列に書き込みます。 ```yaml rule-1: @@ -123,7 +123,7 @@ CREATE TABLE `test`.`t` ( ); ``` -アップストリームに次の 2 つのデータ ソースがあると仮定します。 +アップストリームに次の 2 つのデータソースがあると仮定します。 データソース`mysql-01` : @@ -215,7 +215,7 @@ CREATE TABLE `test`.`t` ( シャード スキーマのシナリオを想定して、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-task-configuration-guide.md b/dm/dm-task-configuration-guide.md index 4982cd86147cd..6e38db461c323 100644 --- a/dm/dm-task-configuration-guide.md +++ b/dm/dm-task-configuration-guide.md @@ -12,10 +12,10 @@ summary: Data Migration (DM) でデータ移行タスクを構成する方法を タスクの移行対象となるデータソースを設定する前に、DMが対応するデータソースの設定ファイルをロードしていることを確認する必要があります。以下に操作手順を示します。 - データソースを表示するには、 [データソースの構成を確認する](/dm/dm-manage-source.md#check-data-source-configurations)を参照してください。 -- データ ソースを作成するには、 [データソースを作成する](/dm/migrate-data-using-dm.md#step-3-create-data-source)を参照してください。 -- データ ソース構成ファイルを生成するには、 [ソース構成ファイルの紹介](/dm/dm-source-configuration-file.md)を参照してください。 +- データソースを作成するには、 [データソースを作成する](/dm/migrate-data-using-dm.md#step-3-create-data-source)を参照してください。 +- データソース構成ファイルを生成するには、 [ソース構成ファイルの紹介](/dm/dm-source-configuration-file.md)を参照してください。 -次の例`mysql-instances`は、データ移行タスクで移行する必要があるデータ ソースを構成する方法を示しています。 +次の例`mysql-instances`は、データ移行タスクで移行する必要があるデータソースを構成する方法を示しています。 ```yaml --- @@ -58,9 +58,9 @@ target-database: # Configuration of target TiDB database. > > 特定のテーブルをフィルタリングしたり、特定のテーブルを移行したりする必要がない場合は、この構成をスキップします。 -データ移行タスクのデータ ソース テーブルのブロック リストと許可リストを構成するには、次の手順を実行します。 +データ移行タスクのデータソーステーブルのブロックリストと許可リストを構成するには、次の手順を実行します。 -1. タスク構成ファイルで、ブロックおよび許可リストのグローバル フィルター ルール セットを構成します。 +1. タスク構成ファイルで、ブロックおよび許可リストのグローバル フィルタールール セットを構成します。 ```yaml block-allow-list: @@ -80,7 +80,7 @@ target-database: # Configuration of target TiDB database. 詳細な設定ルールについては[ブロックと許可のテーブルリスト](/dm/dm-block-allow-table-lists.md)を参照してください。 -2. データ ソース構成のブロック リスト ルールと許可リスト ルールを参照して、移行するテーブルをフィルター処理します。 +2. データソース構成のブロックリスト ルールと許可リスト ルールを参照して、移行するテーブルをフィルター処理します。 ```yaml mysql-instances: @@ -98,7 +98,7 @@ target-database: # Configuration of target TiDB database. データ移行タスクのbinlogイベントのフィルターを構成するには、次の手順を実行します。 -1. タスク構成ファイルで、 binlogイベントのグローバル フィルター ルール セットを構成します。 +1. タスク構成ファイルで、 binlogイベントのグローバル フィルタールール セットを構成します。 ```yaml filters: # The filter rule set of data source binlog events. You can set multiple rules at the same time. @@ -115,7 +115,7 @@ target-database: # Configuration of target TiDB database. 詳細な設定ルールについては[Binlogイベントフィルター](/dm/dm-binlog-event-filter.md)を参照してください。 -2. データ ソース構成内のbinlogイベント フィルタリング ルールを参照して、データ ソース内の指定されたテーブルまたはスキーマの指定されたbinlogイベントをフィルタリングします。 +2. データソース構成内のbinlogイベントフィルタリング ルールを参照して、データソース内の指定されたテーブルまたはスキーマの指定されたbinlogイベントをフィルタリングします。 ```yaml mysql-instances: @@ -131,13 +131,13 @@ target-database: # Configuration of target TiDB database. > **Note:** > -> - データ ソースの特定のテーブルをダウンストリーム TiDB インスタンス内の別の名前のテーブルに移行する必要がない場合は、この構成をスキップします。 +> - データソースの特定のテーブルをダウンストリーム TiDB インスタンス内の別の名前のテーブルに移行する必要がない場合は、この構成をスキップします。 > > - シャードマージタスクの場合は、タスク構成ファイルでマッピングルールを設定する**必要があります**。 -データ ソース テーブルを指定されたダウンストリーム TiDB テーブルに移行するためのルーティング マッピング ルールを構成するには、次の手順を実行します。 +データソーステーブルを指定されたダウンストリーム TiDB テーブルに移行するためのルーティング マッピングルールを構成するには、次の手順を実行します。 -1. タスク構成ファイルでグローバル ルーティング マッピング ルール セットを構成します。 +1. タスク構成ファイルでグローバル ルーティング マッピングルール セットを構成します。 ```yaml routes: # The routing mapping rule set between the data source tables and downstream TiDB tables. You can set multiple rules at the same time. @@ -153,7 +153,7 @@ target-database: # Configuration of target TiDB database. 詳細な設定ルールについては[テーブルルーティング](/dm/dm-table-routing.md)を参照してください。 -2. データ ソース構成内のルーティング マッピング ルールを参照して、移行するテーブルをフィルター処理します。 +2. データソース構成内のルーティング マッピングルールを参照して、移行するテーブルをフィルター処理します。 ```yaml mysql-instances: diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md index faea0802acbcc..6bb15202b5129 100644 --- a/dm/dm-webui-guide.md +++ b/dm/dm-webui-guide.md @@ -64,10 +64,10 @@ DMでは、移行タスクの各サブタスクは、フルダンプ -> フ 移行タスクに設定された移行ルールのステータスは**、「レプリケーションの詳細」**ページで確認できます。このページでは、タスク、ソース、データベース名によるクエリがサポートされています。 -クエリ結果には、アップストリーム テーブルとダウンストリーム テーブルの対応する情報が含まれます。クエリ結果が多すぎるとページの応答が遅くなる可能性があるため、 `.*`を使用するときは注意してください。 +クエリ結果には、アップストリームテーブルとダウンストリームテーブルの対応する情報が含まれます。クエリ結果が多すぎるとページの応答が遅くなる可能性があるため、 `.*`を使用するときは注意してください。 ## クラスタ {#cluster} ### メンバー {#members} -**メンバー**ページには、DM クラスター内のすべてのマスター ノードとワーカー ノード、およびワーカー ノードとソース間のバインド関係が表示されます。 +**メンバー**ページには、DM クラスター内のすべてのマスターノードとワーカーノード、およびワーカーノードとソース間のバインド関係が表示されます。 \ No newline at end of file diff --git a/dm/dm-worker-configuration-file.md b/dm/dm-worker-configuration-file.md index e4d967dd48637..50ebdb0e4f408 100644 --- a/dm/dm-worker-configuration-file.md +++ b/dm/dm-worker-configuration-file.md @@ -44,7 +44,7 @@ cert-allowed-cn = ["dm"] #### `log-level` {#log-level} -- ログ レベルを指定します。 +- ログレベルを指定します。 - デフォルト値: `info` - `fatal` `warn` `info` `error` `debug` @@ -66,13 +66,13 @@ cert-allowed-cn = ["dm"] #### `keepalive-ttl` {#keepalive-ttl} -- DM ワーカー ノードの上流データ ソースがリレー ログを有効にしていない場合の、DM ワーカー ノードから DM マスター ノードへのキープアライブ時間 (秒単位)。 +- DM ワーカーノードの上流データソースがリレーログを有効にしていない場合の、DM ワーカーノードから DM マスターノードへのキープアライブ時間 (秒単位)。 - デフォルト値: `60` - 単位: 秒 #### `relay-keepalive-ttl` DM v2.0.2の新機能 {#relay-keepalive-ttl-new-in-dm-v202} -- DM ワーカー ノードの上流データ ソースがリレー ログを有効にしている場合の、DM ワーカー ノードから DM マスター ノードへのキープアライブ時間 (秒単位)。 +- DM ワーカーノードの上流データソースがリレーログを有効にしている場合の、DM ワーカーノードから DM マスターノードへのキープアライブ時間 (秒単位)。 - デフォルト値: `1800` - 単位: 秒 diff --git a/dm/dm-worker-intro.md b/dm/dm-worker-intro.md index 158478f188f07..12e533b7e9f9e 100644 --- a/dm/dm-worker-intro.md +++ b/dm/dm-worker-intro.md @@ -26,7 +26,7 @@ DM-worker は、TiDB Data Migration (DM) のコンポーネントであり、DM- ### ダンプ処理装置 {#dump-processing-unit} -ダンプ処理ユニットは、アップストリームの MySQL/MariaDB から完全なデータをローカル ディスクにダンプします。 +ダンプ処理ユニットは、アップストリームの MySQL/MariaDB から完全なデータをローカルディスクにダンプします。 ### ロード処理装置 {#load-processing-unit} @@ -38,7 +38,7 @@ Binlogログレプリケーション/同期処理ユニットは、上流の MyS ## DMワーカーに必要な権限 {#privileges-required-by-dm-worker} -このセクションでは、DM-worker に必要な上流および下流のデータベース ユーザーの権限と、それぞれの処理ユニットに必要なユーザー権限について説明します。 +このセクションでは、DM-worker に必要な上流および下流のデータベースユーザーの権限と、それぞれの処理ユニットに必要なユーザー権限について説明します。 ### 上流データベースユーザー権限 {#upstream-database-user-privileges} @@ -135,7 +135,7 @@ GRANT SELECT ON `db1`.* TO 'your_user'@'your_wildcard_of_host'; ### 下流データベースユーザー権限 {#downstream-database-user-privileges} -ダウンストリーム データベース (TiDB) ユーザーには、次の権限が必要です。 +ダウンストリームデータベース (TiDB) ユーザーには、次の権限が必要です。 | 権限 | 範囲 | | :------- | :---------- | diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md index 1319e1c494c41..3b36156e42c50 100644 --- a/dm/feature-online-ddl.md +++ b/dm/feature-online-ddl.md @@ -11,14 +11,14 @@ DMを使用してMySQLからTiDBにデータを移行する場合、online-ddl ## オンライン DDL ツールを使用した DM の動作詳細 {#working-details-for-dm-with-online-ddl-tools} -このセクションでは、オンライン スキーマ変更を実装する場合の、オンライン DDL ツール[gh-ost](https://github.com/github/gh-ost)および[pt-osc](https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html)を使用した DM の動作の詳細について説明します。 +このセクションでは、オンラインスキーマ変更を実装する場合の、オンライン DDL ツール[gh-ost](https://github.com/github/gh-ost)および[pt-osc](https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html)を使用した DM の動作の詳細について説明します。 ## オンラインスキーマ変更: gh-ost {#online-schema-change-gh-ost} -gh-ost がオンライン スキーマ変更を実装すると、次の 3 種類のテーブルが作成されます。 +gh-ost がオンラインスキーマ変更を実装すると、次の 3 種類のテーブルが作成されます。 - gho: DDLの適用に使用されます。データが完全に複製され、ghoテーブルが元のテーブルと整合性が取れている場合、元のテーブルは名前変更によって置き換えられます。 -- ghc: オンライン スキーマ変更に関連する情報を保存するために使用されます。 +- ghc: オンラインスキーマ変更に関連する情報を保存するために使用されます。 - del: 元のテーブルの名前を変更して作成されました。 移行プロセスでは、DM は上記のテーブルを 3 つのカテゴリに分割します。 @@ -113,7 +113,7 @@ gh-ost で主に使用される SQL ステートメントとそれに対応す ## オンラインスキーマ変更: pt {#online-schema-change-pt} -pt-osc がオンライン スキーマ変更を実装すると、次の 2 種類のテーブルが作成されます。 +pt-osc がオンラインスキーマ変更を実装すると、次の 2 種類のテーブルが作成されます。 - `new` : DDLの適用に使用されます。データが完全に複製され、 `new`テーブルが元のテーブルと整合性が取れている場合、元のテーブルは名前変更によって置き換えられます。 - `old` : 元のテーブルの名前を変更して作成されました。 diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 9eba1e4ceb1ab..0e5a669ade28c 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -1,6 +1,6 @@ --- title: Merge and Migrate Data from Sharded Tables in Optimistic Mode -summary: DM が楽観的モードでシャード テーブルからデータをマージおよび移行する方法を学習します。 +summary: DM が楽観的モードでシャードテーブルからデータをマージおよび移行する方法を学習します。 --- # 楽観的モードでシャードテーブルからデータをマージおよび移行する {#merge-and-migrate-data-from-sharded-tables-in-optimistic-mode} @@ -27,9 +27,9 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル 楽観的モードの使用には多少のリスクが伴います。使用する際は、以下のルールに従ってください。 -- DDL ステートメントのバッチを実行する前と実行後に、各シャード テーブルのスキーマが相互に一貫していることを確認します。 +- DDL ステートメントのバッチを実行する前と実行後に、各シャードテーブルのスキーマが相互に一貫していることを確認します。 -- A/B テストを実行する場合は、1 つのシャード テーブルで**のみ**テストを実行します。 +- A/B テストを実行する場合は、1 つのシャードテーブルで**のみ**テストを実行します。 - A/Bテストが完了したら、最も直接的なDDL文のみを最終スキーマに移行します。テストのすべてのステップを、正解か不正解かを問わず再実行しないでください。 @@ -72,18 +72,18 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル ### データの不整合を引き起こす操作 {#operations-that-cause-data-inconsistency} - 各シャードテーブルのスキーマは互いに互換性がありません。例: - - 同じ名前の 2 つの列が 2 つのシャード テーブルにそれぞれ追加されていますが、列のタイプは異なります。 - - 同じ名前の 2 つの列が 2 つのシャード テーブルにそれぞれ追加されていますが、列のデフォルト値は異なります。 - - 同じ名前の 2 つの生成列がそれぞれ 2 つのシャード テーブルに追加されますが、列は異なる式を使用して生成されます。 - - 同じ名前の 2 つのインデックスが 2 つのシャード テーブルにそれぞれ追加されていますが、キーは異なります。 - - 同じ名前を持つ他の異なるテーブル スキーマ。 -- シャード テーブル内のデータを破損する可能性のある DDL ステートメントを実行し、ロールバックを試みます。 + - 同じ名前の 2 つの列が 2 つのシャードテーブルにそれぞれ追加されていますが、列のタイプは異なります。 + - 同じ名前の 2 つの列が 2 つのシャードテーブルにそれぞれ追加されていますが、列のデフォルト値は異なります。 + - 同じ名前の 2 つの生成列がそれぞれ 2 つのシャードテーブルに追加されますが、列は異なる式を使用して生成されます。 + - 同じ名前の 2 つのインデックスが 2 つのシャードテーブルにそれぞれ追加されていますが、キーは異なります。 + - 同じ名前を持つ他の異なるテーブルスキーマ。 +- シャードテーブル内のデータを破損する可能性のある DDL ステートメントを実行し、ロールバックを試みます。 たとえば、列`X`を削除し、この列を再度追加します。 ### 例 {#example} -次の 3 つのシャード テーブルをマージして TiDB に移行します。 +次の 3 つのシャードテーブルをマージして TiDB に移行します。 ![optimistic-ddl-fail-example-1](/media/dm/optimistic-ddl-fail-example-1.png) @@ -146,7 +146,7 @@ ALTER TABLE `tbl01` ADD COLUMN `Level` INT; ![optimistic-ddl-example-5](/media/dm/optimistic-ddl-example-5.png) -この時点で、ダウンストリームにはすでに同じ`Level`列があるため、DM マスターはテーブル スキーマを比較した後、何も操作を実行しません。 +この時点で、ダウンストリームにはすでに同じ`Level`列があるため、DM マスターはテーブルスキーマを比較した後、何も操作を実行しません。 `tbl01`に`Name`列をドロップします。 @@ -186,7 +186,7 @@ ALTER TABLE `tbl02` DROP COLUMN `Name`; ![optimistic-ddl-example-9](/media/dm/optimistic-ddl-example-9.png) -その時までに、 `Name`列はすべてのシャード テーブルから削除され、ダウンストリームで安全に削除できるようになります。 +その時までに、 `Name`列はすべてのシャードテーブルから削除され、ダウンストリームで安全に削除できるようになります。 ```sql ALTER TABLE `tbl` DROP COLUMN `Name`; diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index 03539ddfe23bd..8ed9c2b0aa299 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -15,8 +15,8 @@ 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 ステートメントを受信するのを待ちます。 -- シャーディング グループ移行タスクは`DROP DATABASE` / `DROP TABLE`をサポートしていません。 + - 例えば、 `DM-worker-2`に対応する 1 つ以上のアップストリーム シャーディングテーブルで DDL ステートメントが実行されない場合、DDL ステートメントを実行した他の DM-worker は移行タスクを一時停止し、 `DM-worker-2`がアップストリーム DDL ステートメントを受信するのを待ちます。 +- シャーディンググループ移行タスクは`DROP DATABASE` / `DROP TABLE`をサポートしていません。 - DM-worker の同期ユニットは、アップストリームのシャーディングされたテーブルの`DROP DATABASE` / `DROP TABLE`ステートメントを自動的に無視します。 - シャーディンググループ移行タスクは`TRUNCATE TABLE`をサポートしていません。 - DM-worker の同期ユニットは、アップストリームのシャーディングされたテーブルの`TRUNCATE TABLE`ステートメントを自動的に無視します。 @@ -27,7 +27,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して - 増分レプリケーションタスクの開始時点では、各シャーディングテーブルのテーブルスキーマは同じである必要があります。これにより、異なるシャーディングテーブルのDMLステートメントが明確なテーブルスキーマでダウンストリームに移行され、後続のシャーディングDDLステートメントが正しくマッチングおよび移行されることが保証されます。 - [テーブルルーティング](/dm/dm-table-routing.md)ルールを変更する必要がある場合は、すべてのシャーディング DDL ステートメントの移行が完了するまで待つ必要があります。 - シャーディング DDL ステートメントの移行中に、 `dmctl`を使用して`router-rules`を変更するとエラーが報告されます。 -- DDL ステートメントが実行されるシャーディング グループに新しいテーブルを`CREATE`追加する必要がある場合は、テーブル スキーマが新しく変更されたテーブル スキーマと同じであることを確認する必要があります。 +- DDL ステートメントが実行されるシャーディンググループに新しいテーブルを`CREATE`追加する必要がある場合は、テーブルスキーマが新しく変更されたテーブルスキーマと同じであることを確認する必要があります。 - 例えば、元の`table_1`と`table_2`はどちらも最初は 2 つの列 (a、b) を持ち、シャーディング DDL 操作後には 3 つの列 (a、b、c) を持つため、移行後に新しく作成されたテーブルも 3 つの列 (a、b、c) を持つ必要があります。 - DDLステートメントを受信したDMワーカーは、他のDMワーカーがDDLステートメントを受信するまでタスクを一時停止するため、データ移行の遅延が増加します。 @@ -41,7 +41,7 @@ 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データが、以下の時間シーケンスを持つと仮定します。 @@ -51,7 +51,7 @@ DM の悲観的モードでは、シャーディング DDL の使用に関して 4. `t3`では、インスタンス 2 からのシャーディング DDL イベントが受信されます。 5. `t4`以降、同期ユニットはインスタンス2からの`schema V2`のDMLイベントも受信します。 -シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブル スキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`t2`から`t3`までの`schema V1`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブル スキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 +シャーディングされたテーブルの DDL ステートメントは、移行プロセス中に処理されないものとします。インスタンス 1 の DDL ステートメントがダウンストリームに移行された後、ダウンストリームのテーブルスキーマは`schema V2`に変更されます。しかし、インスタンス 2 では、DM-worker の同期ユニットは`t2`から`t3`までの`schema V1`の DML イベントをまだ受信しています。そのため、 `schema V1`の DML ステートメントがダウンストリームに移行される際に、DML ステートメントとテーブルスキーマの不整合によりエラーが発生し、データが正常に移行されない可能性があります。 ## 原則 {#principles} @@ -101,7 +101,7 @@ sequenceDiagram - タスク構成とDMクラスタ展開トポロジ情報に基づいて、DDL移行を調整するための論理シャーディンググループ`DM-master`に構築されます。グループメンバーは、移行タスクから分割された各サブタスクを処理するDMワーカーです。 - binlogイベントから DDL ステートメントを受け取った後、各 DM-worker は DDL 情報を`DM-master`に送信します。 -- `DM-master`は各 DM-worker から受信した DDL 情報とシャーディング グループ情報に基づいて、DDL ロックを作成または更新します。 +- `DM-master`は各 DM-worker から受信した DDL 情報とシャーディンググループ情報に基づいて、DDL ロックを作成または更新します。 - シャーディンググループのすべてのメンバーが同じ特定のDDLステートメントを受信した場合、これは、アップストリームのシャーディングされたテーブルでのDDL実行前のすべてのDMLステートメントが完全に移行されたことを示しており、このDDLステートメントを実行できます。その後、DMは後続のDMLステートメントの移行を続行できます。 - [テーブルルーター](/dm/dm-table-routing.md)によって変換された後、上流のシャーディングされたテーブルのDDLステートメントは、下流で実行されるDDLステートメントと一致している必要があります。したがって、このDDLステートメントはDDL所有者によって一度だけ実行されればよく、他のすべてのDMワーカーはこのDDLステートメントを無視できます。 @@ -143,7 +143,7 @@ DMでは、DMワーカー内でDDLステートメントをシャーディング 1. 各DMワーカーは、アップストリームのMySQLインスタンス内の複数のシャーディングテーブルで構成される対応するシャーディンググループに対して、DDLステートメントの移行を個別に調整します。 2. DMワーカーは、シャーディングされたすべてのテーブルのDDLステートメントを受け取った後、DDL情報を`DM-master`に送信します。 -3. `DM-master`は受信した DDL 情報に基づいて、DM-workers で構成されるシャーディング グループの DDL 移行を調整します。 +3. `DM-master`は受信した DDL 情報に基づいて、DM-workers で構成されるシャーディンググループの DDL 移行を調整します。 4. すべての DM-worker から DDL 情報を受信した後、 `DM-master`は DDL ロック所有者 (特定の DM-worker) に DDL ステートメントを実行するように要求します。 5. DDLロックの所有者はDDLステートメントを実行し、結果を`DM-master`に返します。その後、所有者はDDL移行の内部調整中に以前に無視されたDMLステートメントの移行を再開します。 6. `DM-master`は、所有者が DDL ステートメントを正常に実行したことを確認した後、他のすべての DM-worker に移行を続行するように要求します。 diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index 554dc9f88a8a4..accf753d24824 100644 --- a/dm/handle-failed-ddl-statements.md +++ b/dm/handle-failed-ddl-statements.md @@ -17,7 +17,7 @@ summary: TiDB データ移行ツールを使用してデータを移行すると - 失敗した DDL ステートメントを他の DDL ステートメントに置き換えることはできません。 - その他の DDL ステートメントをダウンストリーム TiDB に挿入してはなりません。 -たとえば、 `DROP PRIMARY KEY` 。このシナリオでは、新しいテーブル スキーマを使用してダウンストリームに新しいテーブルを作成し (DDL ステートメントを実行した後)、すべてのデータをこの新しいテーブルに再インポートすることしかできません。 +たとえば、 `DROP PRIMARY KEY` 。このシナリオでは、新しいテーブルスキーマを使用してダウンストリームに新しいテーブルを作成し (DDL ステートメントを実行した後)、すべてのデータをこの新しいテーブルに再インポートすることしかできません。 ## サポートされているシナリオ {#supported-scenarios} @@ -132,7 +132,7 @@ SHOW CREATE TABLE db1.tbl1; +-------+--------------------------------------------------+ ``` -ここで、アップストリームで次の DDL ステートメントが実行され、テーブル スキーマが変更されます (つまり、c2 の DECIMAL(11, 3) が DECIMAL(10, 3) に変更されます)。 +ここで、アップストリームで次の DDL ステートメントが実行され、テーブルスキーマが変更されます (つまり、c2 の DECIMAL(11, 3) が DECIMAL(10, 3) に変更されます)。 ```sql ALTER TABLE db1.tbl1 CHANGE c2 c2 DECIMAL (10, 3); @@ -229,7 +229,7 @@ ERROR 8200 (HY000): Unsupported modify column: can't change decimal column preci - MySQL インスタンス 1 には、 `shard_table_1`と`shard_table_2`テーブルを含む`shard_db_1`スキーマが含まれています。 - MySQL インスタンス 2 には、 `shard_table_1`と`shard_table_2`テーブルを含む`shard_db_2`スキーマが含まれています。 -初期のテーブル スキーマは次のとおりです。 +初期のテーブルスキーマは次のとおりです。 ```sql SHOW CREATE TABLE shard_db.shard_table; @@ -246,7 +246,7 @@ SHOW CREATE TABLE shard_db.shard_table; +-------+-----------------------------------------------------------------------------------------------------------+ ``` -次に、すべてのアップストリーム シャード テーブルに対して次の DDL ステートメントを実行して、文字セットを変更します。 +次に、すべてのアップストリーム シャードテーブルに対して次の DDL ステートメントを実行して、文字セットを変更します。 ```sql ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DANISH_CI; @@ -574,7 +574,7 @@ ALTER TABLE `db1`.`tbl1` ADD COLUMN new_col INT UNIQUE; - MySQL インスタンス 1 にはスキーマ`shard_db_1`があり、そこには`shard_table_1`と`shard_table_2` 2 つのテーブルがあります。 - MySQL インスタンス 2 にはスキーマ`shard_db_2`があり、そこには`shard_table_1`と`shard_table_2` 2 つのテーブルがあります。 -初期のテーブル スキーマは次のとおりです。 +初期のテーブルスキーマは次のとおりです。 ```sql SHOW CREATE TABLE shard_db.shard_table; @@ -591,7 +591,7 @@ SHOW CREATE TABLE shard_db.shard_table; +-------+-----------------------------------------------------------------------------------------------------------+ ``` -次に、すべてのアップストリーム シャード テーブルに対して次の DDL 操作を実行し、UNIQUE 制約を持つ新しい列を追加します。 +次に、すべてのアップストリーム シャードテーブルに対して次の DDL 操作を実行し、UNIQUE 制約を持つ新しい列を追加します。 ```sql ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE; diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index b70b593b0336b..90218a1b351ac 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -12,11 +12,11 @@ DM クラスターをまだ展開していない場合は、手順[TiUPを使用 > **Note:** > > - 以下のコンポーネント間のポートが相互接続されていることを確認してください -> - DM マスター ノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 -> - 各 DM マスター ノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 -> - 各 DM ワーカー ノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM マスター ノードの`port` (デフォルトでは`8261` ) に接続できます。 -> - TiUPノードは、すべての DM ワーカー ノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - DM マスターノードのうち`peer_port` (デフォルトでは`8291` ) が相互接続されています。 +> - 各 DM マスターノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 +> - 各 DM ワーカーノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM マスターノードの`port` (デフォルトでは`8261` ) に接続できます。 +> - TiUPノードは、すべての DM ワーカーノードの`port` (デフォルトでは`8262` ) に接続できます。 TiUP DMコンポーネントのヘルプ情報については、次のコマンドを実行します。 @@ -61,7 +61,7 @@ Flags: ## クラスターリストを確認する {#view-the-cluster-list} -クラスターが正常にデプロイされたら、次のコマンドを実行してクラスター リストを表示します。 +クラスターが正常にデプロイされたら、次のコマンドを実行してクラスターリストを表示します。 ```bash tiup dm list @@ -81,7 +81,7 @@ prod-cluster tidb ${version} /root/.tiup/storage/dm/clusters/test /root/.tiu tiup dm start prod-cluster ``` -クラスターの名前を忘れた場合は、 `tiup dm list`を実行してクラスター リストを表示します。 +クラスターの名前を忘れた場合は、 `tiup dm list`を実行してクラスターリストを表示します。 ## クラスターのステータスを確認する {#check-the-cluster-status} @@ -119,7 +119,7 @@ DMマスターコンポーネントの場合、ステータスに`|L`が付加 1. コンポーネントプロセスを停止します。 2. DM-master の API を呼び出して`member`を削除します。 -3. ノードに関連するデータ ファイルをクリーンアップします。 +3. ノードに関連するデータファイルをクリーンアップします。 スケールイン コマンドの基本的な使用法: @@ -137,11 +137,11 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 ## クラスターをスケールアウトする {#scale-out-a-cluster} -スケールアウト操作には、デプロイメントと同様の内部ロジックがあります。TiUP TiUP DMコンポーネントは、まずノードの SSH 接続を確認し、ターゲット ノードに必要なディレクトリを作成し、次にデプロイメント操作を実行して、ノード サービスを開始します。 +スケールアウト操作には、デプロイメントと同様の内部ロジックがあります。TiUP TiUP DMコンポーネントは、まずノードの SSH 接続を確認し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメント操作を実行して、ノード サービスを開始します。 -たとえば、クラスター`prod-cluster`内の DM ワーカー ノードをスケール アウトするには、次の手順を実行します (DM マスターのスケール アウトにも同様の手順があります)。 +たとえば、クラスター`prod-cluster`内の DM ワーカーノードをスケールアウトするには、次の手順を実行します (DM マスターのスケールアウトにも同様の手順があります)。 -1. `scale.yaml`ファイルを作成し、新しいワーカー ノードの情報を追加します。 +1. `scale.yaml`ファイルを作成し、新しいワーカーノードの情報を追加します。 > **Note:** > @@ -171,7 +171,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 > > アップグレード前に、 `config export`を使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`を使用して以前の設定ファイルをインポートできます。 > -> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データ ソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 +> v2.0.5 より前のクラスターの場合は、dmctl (>= v2.0.5 かつ < v8.0.0) を使用して、データソースおよびタスク構成ファイルをエクスポートおよびインポートできます。 > > v2.0.2以降のクラスターでは、現在、リレーワーカー関連の設定の自動インポートはサポートされていません。`start-relay`コマンドを使用して手動で[リレーログを開始](/dm/relay-log.md#enable-and-disable-relay-log)を実行できます。 @@ -203,7 +203,7 @@ TiUP DMは設定ファイルをviエディタで開きます。他のエディ tiup dm reload prod-cluster ``` -このコマンドは、構成をターゲット マシンに送信し、クラスターを再起動して構成を有効にします。 +このコマンドは、構成をターゲットマシンに送信し、クラスターを再起動して構成を有効にします。 ## コンポーネントの更新 {#update-component} @@ -270,10 +270,10 @@ tiup dm import --dir=/path/to/dm-ansible --cluster-version ${version} `import`コマンドを使用するプロセスは次のとおりです。 -1. TiUP は、DM-Ansible を使用して以前にデプロイされた DM クラスターに基づいてトポロジ ファイル[`topology.yml`](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)を生成します。 -2. トポロジ ファイルが生成されたことを確認したら、それを使用して v2.0 以降のバージョンの DM クラスターをデプロイできます。 +1. TiUP は、DM-Ansible を使用して以前にデプロイされた DM クラスターに基づいてトポロジファイル[`topology.yml`](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)を生成します。 +2. トポロジファイルが生成されたことを確認したら、それを使用して v2.0 以降のバージョンの DM クラスターをデプロイできます。 -デプロイメントが完了したら、 `tiup dm start`コマンドを実行してクラスターを起動し、DM カーネルのアップグレード プロセスを開始できます。 +デプロイメントが完了したら、 `tiup dm start`コマンドを実行してクラスターを起動し、DM カーネルのアップグレードプロセスを開始できます。 ## 操作ログを確認する {#view-the-operation-log} @@ -358,9 +358,9 @@ tiup dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml - 認証にSSHプラグインを使用するには - カスタマイズされたSSHクライアントを使用するには -次に、 `--native-ssh`コマンドライン フラグを使用して、システムネイティブのコマンドライン ツールを有効にできます。 +次に、 `--native-ssh`コマンドラインフラグを使用して、システムネイティブのコマンドラインツールを有効にできます。 -- クラスターをデプロイ: `tiup dm deploy --native-ssh` ``にクラスターの名前、 ``にデプロイする DM バージョン ( `v8.5.3`など)、 ``にトポロジ ファイル名を入力します。 +- クラスターをデプロイ: `tiup dm deploy --native-ssh` ``にクラスターの名前、 ``にデプロイする DM バージョン ( `v8.5.3`など)、 ``にトポロジファイル名を入力します。 - クラスターを起動します: `tiup dm start --native-ssh` . - クラスターのアップグレード: `tiup dm upgrade ... --native-ssh` @@ -380,4 +380,4 @@ export TIUP_NATIVE_SSH=enable > **Note:** > -> クラスターの展開プロセス中に、接続にパスワードを使用する必要がある場合、またはキー ファイルに`passphrase`が設定されている場合は、コントロール マシンに`sshpass`がインストールされていることを確認する必要があります。そうでない場合、タイムアウト エラーが報告されます。 +> クラスターの展開プロセス中に、接続にパスワードを使用する必要がある場合、またはキー ファイルに`passphrase`が設定されている場合は、コントロールマシンに`sshpass`がインストールされていることを確認する必要があります。そうでない場合、タイムアウトエラーが報告されます。 diff --git a/dm/manually-handling-sharding-ddl-locks.md b/dm/manually-handling-sharding-ddl-locks.md index 6fceff308b3eb..e4913c5f4ba0b 100644 --- a/dm/manually-handling-sharding-ddl-locks.md +++ b/dm/manually-handling-sharding-ddl-locks.md @@ -177,7 +177,7 @@ SHOW CREATE TABLE shard_db_1.shard_table_1; +---------------+------------------------------------------+ ``` -テーブル構造を変更するために、アップストリームのシャード テーブルで次の DDL 操作が実行されます。 +テーブル構造を変更するために、アップストリームのシャードテーブルで次の DDL 操作が実行されます。 ```sql ALTER TABLE shard_db_*.shard_table_* ADD COLUMN c2 INT; @@ -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`を使用します。 @@ -286,7 +286,7 @@ MySQLとDMの操作プロセスは次のとおりです。 > **Note:** > -> `shard-ddl-lock unlock`を実行した後、オフラインになった MySQL ソースが再ロードされ、DM ワーカーがシャード テーブルのデータを移行しようとすると、データとダウンストリーム テーブル構造の間で一致エラーが発生する可能性があります。 +> `shard-ddl-lock unlock`を実行した後、オフラインになった MySQL ソースが再ロードされ、DM ワーカーがシャードテーブルのデータを移行しようとすると、データとダウンストリームテーブル構造の間で一致エラーが発生する可能性があります。 ### シナリオ2: DDLロック解除プロセス中に一部のDMワーカーが異常停止するか、ネットワーク障害が発生する {#scenario-2-some-dm-workers-stop-abnormally-or-the-network-failure-occurs-during-the-ddl-unlocking-process} @@ -294,9 +294,9 @@ MySQLとDMの操作プロセスは次のとおりです。 `DM-master`がすべての DM ワーカーの DDL イベントを受信した後、 `unlock DDL lock`が自動的に実行され、主に次の手順が含まれます。 -1. ロックの所有者に DDL を実行し、対応するシャード テーブルのチェックポイントを更新するように依頼します。 +1. ロックの所有者に DDL を実行し、対応するシャードテーブルのチェックポイントを更新するように依頼します。 2. 所有者が DDL を正常に実行した後、 `DM-master`に保存されている DDL ロック情報を削除します。 -3. 所有者が DDL を正常に実行した後、他のすべての非所有者に DDL をスキップし、対応するシャード テーブルのチェックポイントを更新するように依頼します。 +3. 所有者が DDL を正常に実行した後、他のすべての非所有者に DDL をスキップし、対応するシャードテーブルのチェックポイントを更新するように依頼します。 4. すべての所有者または非所有者の操作が成功した後、DM マスターは対応する DDL ロック情報を削除します。 現在、上記のロック解除プロセスはアトミックではありません。非オーナーがDDL操作を正常にスキップした場合、非オーナーが配置されているDMワーカーが異常停止するか、下流のTiDBでネットワーク異常が発生し、チェックポイントの更新が失敗する可能性があります。 diff --git a/dm/monitor-a-dm-cluster.md b/dm/monitor-a-dm-cluster.md index d0d4b1521294f..3f5c479e0feba 100644 --- a/dm/monitor-a-dm-cluster.md +++ b/dm/monitor-a-dm-cluster.md @@ -108,7 +108,7 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です > **Note:** > -> 現在、DM v2.0 ではリレー ログ機能の有効化はサポートされていません。 +> 現在、DM v2.0 ではリレーログ機能の有効化はサポートされていません。 | メトリック名 | 説明 | 警告 | 重大度レベル | | :------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------------------------ | :----- | diff --git a/dm/quick-start-create-source.md b/dm/quick-start-create-source.md index 4a83df03fa8cc..359af8f340c74 100644 --- a/dm/quick-start-create-source.md +++ b/dm/quick-start-create-source.md @@ -1,15 +1,15 @@ --- title: Create a Data Source for TiDB Data Migration -summary: データ移行 (DM) のデータ ソースを作成する方法を学習します。 +summary: データ移行 (DM) のデータソースを作成する方法を学習します。 --- # TiDB Data Migration用のデータソースを作成する {#create-a-data-source-for-tidb-data-migration} > **Note:** > -> データ ソースを作成する前に、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を実行する必要があります。 +> データソースを作成する前に、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を実行する必要があります。 -このドキュメントでは、TiDB Data Migration (DM) のデータ移行タスク用のデータ ソースを作成する方法について説明します。 +このドキュメントでは、TiDB Data Migration (DM) のデータ移行タスク用のデータソースを作成する方法について説明します。 データソースには、上流の移行タスクにアクセスするための情報が含まれています。データ移行タスクは、アクセスの設定情報を取得するために、対応するデータソースを参照する必要があるため、データ移行タスクを作成する前に、タスクのデータソースを作成する必要があります。具体的なデータソース管理コマンドについては、 [データソース構成の管理](/dm/dm-manage-source.md)を参照してください。 @@ -49,7 +49,7 @@ summary: データ移行 (DM) のデータ ソースを作成する方法を学 ## ステップ2: データソースを作成する {#step-2-create-a-data-source} -次のコマンドを使用してデータ ソースを作成できます。 +次のコマンドを使用してデータソースを作成できます。 ```bash tiup dmctl --master-addr operate-source create ./source-mysql-01.yaml @@ -76,9 +76,9 @@ tiup dmctl --master-addr operate-source create ./source-mysql-01.y ## ステップ3: 作成したデータソースをクエリする {#step-3-query-the-data-source-you-created} -データ ソースを作成したら、次のコマンドを使用してデータ ソースをクエリできます。 +データソースを作成したら、次のコマンドを使用してデータソースをクエリできます。 -- データ ソースの`source-id`がわかっている場合は、 `dmctl config source `コマンドを使用してデータ ソースの構成を直接確認できます。 +- データソースの`source-id`がわかっている場合は、 `dmctl config source `コマンドを使用してデータソースの構成を直接確認できます。 ```bash tiup dmctl --master-addr config source mysql-01 @@ -99,7 +99,7 @@ tiup dmctl --master-addr operate-source create ./source-mysql-01.y } ``` -- `source-id`がわからない場合は、 `dmctl operate-source show`コマンドを使用してソース データベース リストを確認し、そこから対応するデータ ソースを見つけることができます。 +- `source-id`がわからない場合は、 `dmctl operate-source show`コマンドを使用してソースデータベース リストを確認し、そこから対応するデータソースを見つけることができます。 ```bash tiup dmctl --master-addr operate-source show diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 04fc65a0bdbf8..eb47ff0ac6b8f 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -77,7 +77,7 @@ mv tidb-latest-linux-amd64/bin/tidb-server ./ ## MySQLデータソースを構成する {#configure-the-mysql-data-source} -データ移行タスクを開始する前に、MySQL データ ソースを構成する必要があります。 +データ移行タスクを開始する前に、MySQL データソースを構成する必要があります。 ### パスワードを暗号化する {#encrypt-the-password} @@ -100,7 +100,7 @@ mv tidb-latest-linux-amd64/bin/tidb-server ./ fCxfQ9XKCezSzuCD0Wf5dUD+LsKegSg= ``` -この暗号化された値を保存し、次の手順で MySQL データ ソースを作成するときに使用します。 +この暗号化された値を保存し、次の手順で MySQL データソースを作成するときに使用します。 ### ソース構成ファイルを編集する {#edit-the-source-configuration-file} @@ -125,7 +125,7 @@ MySQL2データソースで、上記の設定を`conf/source2.yaml`にコピー ### ソースを作成する {#create-a-source} -dmctl を使用して MySQL1 のデータ ソース構成を DM クラスターにロードするには、ターミナルで次のコマンドを実行します。 +dmctl を使用して MySQL1 のデータソース構成を DM クラスターにロードするには、ターミナルで次のコマンドを実行します。 ```bash ./dmctl --master-addr=127.0.0.1:8261 operate-source create conf/source1.yaml @@ -209,7 +209,7 @@ MySQL2 の場合、上記のコマンドの設定ファイルを MySQL2 の設 } ``` -これで、MySQL1 および MySQL2 インスタンスから TiDB にシャード テーブルを移行するタスクが正常に作成されました。 +これで、MySQL1 および MySQL2 インスタンスから TiDB にシャードテーブルを移行するタスクが正常に作成されました。 ## データを検証する {#verify-data} diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index c9e2ac8f3ea66..2f8f08713a610 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -309,7 +309,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー > **Note:** > - > この手順では、 [ステップ2](#step-2-prepare-a-source-database-optional)で説明されているように、ソース データベースにレプリケーション権限を持つ`tidb-dm`ユーザーがすでに作成されていることを前提としています。 + > この手順では、 [ステップ2](#step-2-prepare-a-source-database-optional)で説明されているように、ソースデータベースにレプリケーション権限を持つ`tidb-dm`ユーザーがすでに作成されていることを前提としています。 ```yaml source-id: "mysql-01" @@ -320,7 +320,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー port: 3306 ``` -2. DM データ ソースを作成します。 +2. DM データソースを作成します。 ```shell tiup dmctl --master-addr 127.0.0.1:8261 operate-source create mysql-01.yaml @@ -424,7 +424,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー > **Note:** > - > すべての MySQL データ ファイルを削除する場合は、MySQL データ ディレクトリ (通常は`/opt/homebrew/var/mysql`にあります) を削除します。 + > すべての MySQL データファイルを削除する場合は、MySQL データディレクトリ (通常は`/opt/homebrew/var/mysql`にあります) を削除します。
    @@ -439,7 +439,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー > **Note:** > - > すべての MySQL データ ファイルを削除する場合は、MySQL データ ディレクトリ (通常は`/var/lib/mysql`にあります) を削除します。 + > すべての MySQL データファイルを削除する場合は、MySQL データディレクトリ (通常は`/var/lib/mysql`にあります) を削除します。
    @@ -455,7 +455,7 @@ Ubuntu では、公式の Ubuntu リポジトリから MySQL をインストー > **Note:** > - > すべての MySQL データ ファイルを削除する場合は、MySQL データ ディレクトリ (通常は`/var/lib/mysql`にあります) を削除します。 + > すべての MySQL データファイルを削除する場合は、MySQL データディレクトリ (通常は`/var/lib/mysql`にあります) を削除します。
    diff --git a/dm/relay-log.md b/dm/relay-log.md index a7323380afbb6..df074e03c7c09 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -1,11 +1,11 @@ --- title: Data Migration Relay Log -summary: DM リレー ログのディレクトリ構造、初期移行ルール、およびデータ パージについて学習します。 +summary: DM リレーログのディレクトリ構造、初期移行ルール、およびデータ パージについて学習します。 --- # データ移行リレーログ {#data-migration-relay-log} -データ移行 (DM) リレー ログは、データベースの変更を記述するイベントを含む番号付きファイルの複数のセットと、使用されたすべてのリレー ログ ファイルの名前を含むインデックス ファイルで構成されます。 +データ移行 (DM) リレーログは、データベースの変更を記述するイベントを含む番号付きファイルの複数のセットと、使用されたすべてのリレーログファイルの名前を含むインデックスファイルで構成されます。 リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DMワーカー構成ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 @@ -17,7 +17,7 @@ MySQLではストレージ容量が限られているため、最大保存期間 完全データ移行タスクと増分データ移行タスク（ `task-mode=all` ）では、DMはまず完全データを移行し、その後、binlogに基づいて増分移行を実行する必要があります。完全移行フェーズに時間がかかると、上流のbinlogが消去され、増分移行が失敗する可能性があります。このような状況を回避するには、リレーログ機能を有効にすることで、DMがローカルディスクに十分なログを自動的に保持し、**増分移行タスクが正常に実行されるようにします**。 -通常はリレー ログを有効にすることをお勧めしますが、次の潜在的な問題に注意してください。 +通常はリレーログを有効にすることをお勧めしますが、次の潜在的な問題に注意してください。 リレーログはディスクに書き込む必要があるため、外部IOおよびCPUリソースを消費します。これにより、データレプリケーションプロセス全体が長くなり、データレプリケーションのレイテンシーが増加します。**レイテンシが重要な**シナリオでは、リレーログを有効にすることは推奨されません。 @@ -27,7 +27,7 @@ MySQLではストレージ容量が限られているため、最大保存期間 ## リレーログを使用する {#use-relay-log} -このセクションでは、リレー ログを有効化および無効化する方法、リレー ログの状態を照会する方法、リレー ログを消去する方法について説明します。 +このセクションでは、リレーログを有効化および無効化する方法、リレーログの状態を照会する方法、リレーログを消去する方法について説明します。 ### リレーログの有効化と無効化 {#enable-and-disable-relay-log} @@ -39,7 +39,7 @@ v5.4.0以降のバージョンでは、 `enable-relay`を`true`に設定する 詳しい設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 -さらに、 `start-relay`または`stop-relay`コマンドを使用してデータ ソースの`enable-relay`構成を動的に調整し、リレー ログイン時間を有効または無効にすることもできます。 +さらに、 `start-relay`または`stop-relay`コマンドを使用してデータソースの`enable-relay`構成を動的に調整し、リレーログイン時間を有効または無効にすることもできます。 ```bash start-relay -s mysql-replica-01 @@ -105,7 +105,7 @@ DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない） ### リレーログのステータスを照会する {#query-relay-log-status} -コマンド`query-status -s`を使用してリレー ログのステータスを照会できます。 +コマンド`query-status -s`を使用してリレーログのステータスを照会できます。 ```bash query-status -s mysql-replica-01 @@ -232,7 +232,7 @@ DM では、リレーログをパージする方法として、手動パージ > > - アクティブリレーログ：リレーログはデータ移行タスクによって使用されています。アクティブリレーログは現在、Syncerユニット内でのみ更新および書き込みされます。「すべて」モードのデータ移行タスクが、データソースのパージで設定された有効期限よりも長い時間、フルエクスポート/インポートを実行した場合でも、リレーログはパージされます。 > -> - 期限切れのリレー ログ: リレー ログ ファイルの最終変更時刻と現在の時刻の差が、構成ファイルの`expires`フィールドの値よりも大きくなっています。 +> - 期限切れのリレーログ: リレーログファイルの最終変更時刻と現在の時刻の差が、構成ファイルの`expires`フィールドの値よりも大きくなっています。 #### 自動パージ {#automatic-purge} @@ -251,12 +251,12 @@ purge: - デフォルトでは「3600」であり、バックグラウンド パージ タスクが 3600 秒ごとに実行されることを示します。 - `purge.expires` - - リレー ログ (以前にリレー処理ユニットに書き込まれ、現在実行中のデータ移行タスクによって使用されていないか、後で読み取られないログ) を自動バックグラウンド パージで消去されるまで保持できる時間数。 + - リレーログ (以前にリレー処理ユニットに書き込まれ、現在実行中のデータ移行タスクによって使用されていないか、後で読み取られないログ) を自動バックグラウンド パージで消去されるまで保持できる時間数。 - デフォルトは「0」で、リレーログの更新時刻に応じてデータのパージが実行されないことを示します。 - `purge.remain-space` - 指定されたDMワーカーマシンが、自動バックグラウンドパージで安全にパージできるリレーログをパージしようとするディスク残量（GB単位）です`0`に設定すると、ディスク残量に応じたデータパージは実行されません。 - - デフォルトでは「15」で、使用可能なディスク容量が 15 GB 未満になると、DM マスターはリレー ログを安全に消去しようとします。 + - デフォルトでは「15」で、使用可能なディスク容量が 15 GB 未満になると、DM マスターはリレーログを安全に消去しようとします。 #### 手動パージ {#manual-purge} diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index a9f4c1f6edcab..3dc13d1b3a215 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -5,11 +5,11 @@ summary: シャードマージのシナリオにおけるデータ移行のベ # シャード統合シナリオにおけるデータ移行のベストプラクティス {#best-practices-of-data-migration-in-the-shard-merge-scenario} -このドキュメントでは、シャード マージ シナリオにおける[TiDB Data Migration (DM)](/dm/dm-overview.md)の機能と制限について説明し、アプリケーションのデータ移行のベスト プラクティス ガイドを提供します (デフォルトの「悲観的」モードが使用されます)。 +このドキュメントでは、シャードマージ シナリオにおける[TiDB Data Migration (DM)](/dm/dm-overview.md)の機能と制限について説明し、アプリケーションのデータ移行のベストプラクティス ガイドを提供します (デフォルトの「悲観的」モードが使用されます)。 ## 別のデータ移行タスクを使用する {#use-a-separate-data-migration-task} -[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)ドキュメントでは、「シャーディング グループ」の定義が次のように示されています。シャーディング グループは、同じダウンストリーム テーブルにマージおよび移行する必要があるすべてのアップストリーム テーブルで構成されます。 +[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)ドキュメントでは、「シャーディンググループ」の定義が次のように示されています。シャーディンググループは、同じダウンストリームテーブルにマージおよび移行する必要があるすべてのアップストリームテーブルで構成されます。 現在のシャーディングDDLメカニズムには、異なるシャーディングされたテーブルにおけるDDL操作によってもたらされるスキーマ変更を調整するための[使用制限](/dm/feature-shard-merge-pessimistic.md#restrictions)の制約があります。予期しない理由によりこれらの制約に違反した場合は、 [DMでシャーディングDDLロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を実行するか、データ移行タスク全体をやり直す必要があります。 @@ -17,20 +17,20 @@ summary: シャードマージのシナリオにおけるデータ移行のベ ## シャーディングDDLロックを手動で処理する {#handle-sharding-ddl-locks-manually} -[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)から、DM のシャーディング DDL ロックは、複数の上流シャード テーブルから下流への DDL 操作の実行を調整するためのメカニズムであることが簡単にわかります。 +[シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge-pessimistic.md#principles)から、DM のシャーディング DDL ロックは、複数の上流シャードテーブルから下流への DDL 操作の実行を調整するためのメカニズムであることが簡単にわかります。 したがって、 `DM-master`の`shard-ddl-lock`コマンドでシャーディング DDL ロックが見つかった場合、または`query-status`コマンドで一部の DM ワーカーに`unresolvedGroups`または`blockingDDLs`ロックが見つかった場合は、 `shard-ddl-lock unlock`コマンドでシャーディング DDL ロックを手動で解除しようとしないでください。 代わりに、次のことができます。 - シャーディング DDL ロックの自動解放の失敗が[異常なシナリオを列挙した](/dm/manually-handling-sharding-ddl-locks.md#supported-scenarios)の 1 つである場合は、対応する手動ソリューションに従ってシナリオを処理します。 -- サポートされていないシナリオの場合は、データ移行タスク全体をやり直します。まず、ダウンストリーム データベースのデータと移行タスクに関連付けられた`dm_meta`情報を空にし、次に、完全および増分データ レプリケーションを再実行します。 +- サポートされていないシナリオの場合は、データ移行タスク全体をやり直します。まず、ダウンストリームデータベースのデータと移行タスクに関連付けられた`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)を参照して解決してください。 @@ -55,11 +55,11 @@ CREATE TABLE `tbl_no_pk` ( 以下の要件を満たしている場合: - `auto_pk_c1`列はアプリケーションに影響を与えず、列の`PRIMARY KEY`属性に依存しません。 -- `uk_c2`列には`UNIQUE KEY`属性があり、すべてのアップストリーム シャード テーブル内でグローバルに一意です。 +- `uk_c2`列には`UNIQUE KEY`属性があり、すべてのアップストリーム シャードテーブル内でグローバルに一意です。 -次に、次の手順を実行して、シャード テーブルをマージするときに`auto_pk_c1`列によって発生する可能性のある`ERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'`エラーを修正できます。 +次に、次の手順を実行して、シャードテーブルをマージするときに`auto_pk_c1`列によって発生する可能性のある`ERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'`エラーを修正できます。 -1. 完全なデータ移行の前に、ダウンストリーム データベースにデータをマージおよび移行するためのテーブルを作成し、 `auto_pk_c1`列の`PRIMARY KEY`属性を通常のインデックスに変更します。 +1. 完全なデータ移行の前に、ダウンストリームデータベースにデータをマージおよび移行するためのテーブルを作成し、 `auto_pk_c1`列の`PRIMARY KEY`属性を通常のインデックスに変更します。 ```sql CREATE TABLE `tbl_no_pk_2` ( @@ -100,7 +100,7 @@ CREATE TABLE `tbl_multi_pk` ( - `auto_pk_c1`と`uuid_c2`列で構成される複合主キーは、グローバルに一意です。 - アプリケーションでは複合主キーを使用することが可能です。 -次に、次の手順を実行して、シャード テーブルをマージするときに`auto_pk_c1`列によって発生する可能性のある`ERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'`エラーを修正できます。 +次に、次の手順を実行して、シャードテーブルをマージするときに`auto_pk_c1`列によって発生する可能性のある`ERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY'`エラーを修正できます。 1. 完全なデータ移行を行う前に、下流データベースにデータのマージと移行のためのテーブルを作成してください。`auto_pk_c1`列に`PRIMARY KEY`属性を指定せず、 `auto_pk_c1`列と`uuid_c2`列を使用して複合主キーを構成してください。 @@ -127,15 +127,15 @@ CREATE TABLE `tbl_multi_pk` ( ### アップストリームにシャードテーブルを作成する {#create-sharded-tables-in-the-upstream} -アップストリームに新しいシャード テーブルを作成する必要がある場合は、次の手順を実行します。 +アップストリームに新しいシャードテーブルを作成する必要がある場合は、次の手順を実行します。 -1. アップストリームのシャード テーブルで実行されたすべてのシャーディング DDL の調整が完了するまで待機します。 +1. アップストリームのシャードテーブルで実行されたすべてのシャーディング DDL の調整が完了するまで待機します。 2. データ移行タスクを停止するには、 `stop-task`を実行します。 -3. アップストリームに新しいシャード テーブルを作成します。 +3. アップストリームに新しいシャードテーブルを作成します。 -4. `task.yaml`ファイル内の構成で、新しく追加されたシャード テーブルを他の既存のシャード テーブルと 1 つのダウンストリーム テーブルにマージできることを確認します。 +4. `task.yaml`ファイル内の構成で、新しく追加されたシャードテーブルを他の既存のシャードテーブルと 1 つのダウンストリームテーブルにマージできることを確認します。 5. タスクを開始するには`start-task`を実行します。 @@ -153,7 +153,7 @@ CREATE TABLE `tbl_multi_pk` ( 4. タスクを停止するには`stop-task`を実行します。 -5. `task.yaml`ファイル内の構成で、アップストリーム内の削除されたシャード テーブルが無視されることを確認します。 +5. `task.yaml`ファイル内の構成で、アップストリーム内の削除されたシャードテーブルが無視されることを確認します。 6. タスクを開始するには`start-task`を実行します。 diff --git a/dm/table-selector.md b/dm/table-selector.md index def7d359c98e0..99b1d80a98b1a 100644 --- a/dm/table-selector.md +++ b/dm/table-selector.md @@ -1,6 +1,6 @@ --- title: Table Selector of TiDB Data Migration -summary: データ移行のテーブル ルーティング、 binlogイベント フィルタリング、列マッピング ルールで使用されるテーブル セレクターについて学習します。 +summary: データ移行のテーブルルーティング、 binlogイベントフィルタリング、列マッピングルールで使用されるテーブル セレクターについて学習します。 --- # TiDB Data Migrationのテーブルセレクター {#table-selector-of-tidb-data-migration} diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index 198c0f9ba4231..8143b21cd0d37 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -256,7 +256,7 @@ mysql-instances: - 値: 文字列 ( `full` 、 `incremental` 、または`all` )。 - `full` 、上流データベースの完全なバックアップを作成し、その後、完全なデータを下流データベースにインポートします。 - `incremental` :binlogを使用して、アップストリームデータベースの増分データのみをダウンストリームデータベースに複製します。インスタンス構成の`meta`構成項目を設定することで、増分レプリケーションの開始位置を指定できます。 - - `all` : `full` + `incremental` 。アップストリーム データベースの完全バックアップを作成し、ダウンストリーム データベースに完全なデータをインポートしてから、完全バックアップ プロセス中にエクスポートされた位置 ( binlog位置) から開始して、 binlogを使用してダウンストリーム データベースへの増分レプリケーションを作成します。 + - `all` : `full` + `incremental` 。アップストリーム データベースの完全バックアップを作成し、ダウンストリームデータベースに完全なデータをインポートしてから、完全バックアッププロセス中にエクスポートされた位置 ( binlog位置) から開始して、 binlogを使用してダウンストリームデータベースへの増分レプリケーションを作成します。 ### 機能構成セット {#feature-configuration-set} @@ -268,11 +268,11 @@ mysql-instances: #### `filters` {#filters} -- アップストリーム データベース インスタンスの一致するテーブルのbinlogイベント フィルター ルール セット。 binlogフィルタリングが必要ない場合、この項目を設定する必要はありません。使用シナリオとサンプル構成については、 [Binlogイベントフィルタ](/dm/dm-binlog-event-filter.md)を参照してください。 +- アップストリーム データベースインスタンスの一致するテーブルのbinlogイベントフィルタールール セット。 binlogフィルタリングが必要ない場合、この項目を設定する必要はありません。使用シナリオとサンプル構成については、 [Binlogイベントフィルタ](/dm/dm-binlog-event-filter.md)を参照してください。 #### `block-allow-list` {#block-allow-list} -- 上流のデータベース インスタンスの一致するテーブルのブロック許可リストのフィルター ルール セット。この項目で移行する必要があるスキーマとテーブルを指定することをお勧めします。指定しないと、すべてのスキーマとテーブルが移行されます。使用シナリオとサンプル構成については、 [Binlogイベントフィルタ](/dm/dm-binlog-event-filter.md)と[ブロックリストと許可リスト](/dm/dm-block-allow-table-lists.md)を参照してください。 +- 上流のデータベースインスタンスの一致するテーブルのブロック許可リストのフィルタールール セット。この項目で移行する必要があるスキーマとテーブルを指定することをお勧めします。指定しないと、すべてのスキーマとテーブルが移行されます。使用シナリオとサンプル構成については、 [Binlogイベントフィルタ](/dm/dm-binlog-event-filter.md)と[ブロックリストと許可リスト](/dm/dm-block-allow-table-lists.md)を参照してください。 #### `mydumpers` {#mydumpers} diff --git a/download-ecosystem-tools.md b/download-ecosystem-tools.md index 2a436e9c32499..f2a1b5619e928 100644 --- a/download-ecosystem-tools.md +++ b/download-ecosystem-tools.md @@ -31,7 +31,7 @@ https://download.pingcap.com/tidb-community-toolkit-{version}-linux-{arch}.tar.g > **Note:** > -> [PD Control](/pd-control.md)ツール`pd-ctl`をダウンロードする必要がある場合は、TiDB インストール パッケージを`https://download.pingcap.com/tidb-community-server-{version}-linux-{arch}.tar.gz`から別途ダウンロードしてください。 +> [PD Control](/pd-control.md)ツール`pd-ctl`をダウンロードする必要がある場合は、TiDB インストールパッケージを`https://download.pingcap.com/tidb-community-server-{version}-linux-{arch}.tar.gz`から別途ダウンロードしてください。 ## TiDB Toolkitの説明 {#tidb-toolkit-description} diff --git a/dr-backup-restore.md b/dr-backup-restore.md index 8d1c049895bd6..934123fa5799a 100644 --- a/dr-backup-restore.md +++ b/dr-backup-restore.md @@ -8,7 +8,7 @@ summary: TiDB のバックアップと復元機能に基づいて災害復旧を TiDBクラスタは複数のレプリカを持つため、単一のデータセンターまたはリージョンの障害にも耐え、サービス提供を継続できます。自然災害、ソフトウェアの脆弱性、ハードウェア障害、ウイルス攻撃、誤操作など、単一のデータセンターまたはリージョンよりも広い範囲に影響を及ぼすような事態が発生した場合、TiDBのバックアップ＆リストア（BR）機能により、独立した災害復旧（DR）ストレージデバイスにデータをバックアップし、ユーザーデータを損害から保護することができます。他のDRソリューションと比較して、 BR機能はより柔軟性、信頼性、復旧性、そして費用対効果に優れています。 - 柔軟性：いつでも、どの頻度でもデータをバックアップできます。これにより、バックアップとリストアが柔軟になり、さまざまなビジネスシナリオに適応しやすくなります。 -- 信頼性: バックアップ データは通常、独立したストレージデバイスに保存されるため、データのセキュリティが強化されます。 +- 信頼性: バックアップデータは通常、独立したストレージデバイスに保存されるため、データのセキュリティが強化されます。 - 回復性：予期せぬ状況によって元のデータが失われたり損傷したりした場合でも、バックアップデータを復元することで回復できます。これにより、 BR機能の回復性は高まり、データベースの正常な使用が保証されます。 - コスト効率: BRを使用すると、多額の費用をかけずにデータベースを保護できます。 @@ -28,6 +28,6 @@ TiDBクラスタは複数のレプリカを持つため、単一のデータセ TiDBは、DRシナリオにおけるバックアップとリストア機能の使用方法を理解するのに役立つ詳細なドキュメントも提供しています。その中には、 -- [TiDB バックアップとリストアの使用概要](/br/br-use-overview.md) 、バックアップ戦略やバックアップ データの構成など、 BR機能の概要です。 +- [TiDB バックアップとリストアの使用概要](/br/br-use-overview.md) 、バックアップ戦略やバックアップデータの構成など、 BR機能の概要です。 - [バックアップと復元に関するよくある質問](/faq/backup-and-restore-faq.md) 、TiDB バックアップ & リストア (BR) に関するよくある質問 (FAQ) と解決策が記載されています。 -- [TiDB バックアップとリストアのアーキテクチャの概要](/br/backup-and-restore-design.md) 、バックアップと復元のプロセス、バックアップ ファイルの設計など、 BR機能の設計アーキテクチャについて説明します。 +- [TiDB バックアップとリストアのアーキテクチャの概要](/br/backup-and-restore-design.md) 、バックアップと復元のプロセス、バックアップファイルの設計など、 BR機能の設計アーキテクチャについて説明します。 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index 12b641e5120f8..7d1028f3a292c 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -26,7 +26,7 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー この例では、TiDBには5つのレプリカと3つのリージョンが含まれています。リージョン1はプライマリリージョン、リージョン2はセカンダリリージョン、リージョン3は投票に使用されます。同様に、PDクラスターにも5つのレプリカが含まれており、TiDBクラスターと基本的に同じように機能します。 -1. 次のようなトポロジ ファイルを作成します。 +1. 次のようなトポロジファイルを作成します。 ```toml global: @@ -89,7 +89,7 @@ summary: 単一クラスターのマルチレプリカ災害復旧ソリュー 上記の構成では、次のオプションを使用して、リージョン間 DR を最適化します。 - - `server.grpc-compression-type: gzip`設定すると、TiKV での gRPC メッセージ圧縮が有効になり、ネットワーク トラフィックが削減されます。 + - `server.grpc-compression-type: gzip`設定すると、TiKV での gRPC メッセージ圧縮が有効になり、ネットワークトラフィックが削減されます。 - `raftstore.raft-min-election-timeout-ticks`と`raftstore.raft-max-election-timeout-ticks`設定して、リージョン 3 が選挙に参加するまでの時間を延長し、このリージョン内のレプリカがリーダーとして投票されるのを防ぎます。 2. 上記の構成ファイルを使用してクラスターを作成します。 @@ -166,7 +166,7 @@ GrafanaまたはTiDB Dashboardにアクセスすることで、TiKV、TiDB、PD 計画的スイッチオーバーとは、メンテナンスの必要性に基づいてプライマリリージョンとセカンダリリージョン間でスケジュールされたスイッチオーバーです。DRシステムが正常に動作しているかどうかを確認するために使用できます。このセクションでは、計画的スイッチオーバーの実行方法について説明します。 -1. 次のコマンドを実行して、すべてのユーザー テーブルと PD リーダーをリージョン 2 に切り替えます。 +1. 次のコマンドを実行して、すべてのユーザーテーブルと PD リーダーをリージョン 2 に切り替えます。 ```sql -- Apply the rule secondary_rule_for_region2 to the corresponding user tables. @@ -197,7 +197,7 @@ GrafanaまたはTiDB Dashboardにアクセスすることで、TiKV、TiDB、PD tiup cluster stop drtest -N tidb-dr-test1:20160,tidb-dr-test2:20160,tidb-dr-test1:2379,tidb-dr-test2:2379 ``` -2. 次のコマンドを実行して、すべてのユーザー テーブルのリーダーをリージョン 2 に切り替えます。 +2. 次のコマンドを実行して、すべてのユーザーテーブルのリーダーをリージョン 2 に切り替えます。 ```sql -- Apply the rule secondary_rule_for_region2 to the corresponding user tables. @@ -208,4 +208,4 @@ GrafanaまたはTiDB Dashboardにアクセスすることで、TiKV、TiDB、PD SELECT STORE_ID, address, leader_count, label FROM TIKV_STORE_STATUS ORDER BY store_id; ``` - リージョン 1 が回復したら、前述のコマンドと同様のコマンドを使用して、ユーザー テーブルのリーダーをリージョン 1 に戻すことができます。 + リージョン 1 が回復したら、前述のコマンドと同様のコマンドを使用して、ユーザーテーブルのリーダーをリージョン 1 に戻すことができます。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index ef77f6a464117..9c541b3a527f3 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -65,7 +65,7 @@ TiDBプライマリクラスタとセカンダリクラスタのデプロイ方 TiCDCを導入する際は、セカンダリクラスタとTiCDCを一緒に導入・管理する必要があり、両者間のネットワークが接続されている必要があることに注意してください。 -- 既存のプライマリ クラスターに TiCDC をデプロイするには、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)を参照してください。 +- 既存のプライマリクラスターに TiCDC をデプロイするには、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)を参照してください。 - 新しいプライマリクラスタとTiCDCをデプロイするには、以下のデプロイテンプレートを使用し、必要に応じて構成パラメータを変更してください。 ```yaml @@ -145,7 +145,7 @@ s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0 #### データの移行 {#migrate-data} -[バックアップと復元機能](/br/backup-and-restore-overview.md)を使用して、プライマリ クラスターからセカンダリ クラスターにデータを移行します。 +[バックアップと復元機能](/br/backup-and-restore-overview.md)を使用して、プライマリクラスターからセカンダリクラスターにデータを移行します。 1. GCを無効にします。増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスタのGCを無効にする必要があります。こうすることで、履歴データが削除されるのを防ぐことができます。 @@ -210,7 +210,7 @@ s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0 #### 増分データを複製する {#replicate-incremental-data} -前のセクションで説明したようにデータを移行した後、 **BackupTS**からプライマリ クラスターからセカンダリ クラスターに増分データを複製できます。 +前のセクションで説明したようにデータを移行した後、 **BackupTS**からプライマリクラスターからセカンダリクラスターに増分データを複製できます。 1. 変更フィードを作成します。 diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index 56aa6813e4ef0..03320d07ffc0d 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -99,7 +99,7 @@ BRに基づく DR ソリューションは、5 分未満の RPO と、復元す ### その他の災害復旧ソリューション {#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/dumpling-overview.md b/dumpling-overview.md index 9e189cf07c4e0..f9d9fa43fba7b 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -11,7 +11,7 @@ summary: TiDBからデータをエクスポートするには、Dumplingツー [TiUP](/tiup/tiup-overview.md)を使用してDumplingを取得するには、 `tiup install dumpling`を実行します。その後、 `tiup dumpling ...`を使用してDumplingを実行できます。 -Dumplingインストール パッケージは、 TiDB Toolkitに含まれています。 TiDB Toolkitをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 +Dumplingインストールパッケージは、 TiDB Toolkitに含まれています。 TiDB Toolkitをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 @@ -73,7 +73,7 @@ Dumplingには次のような利点があります。 - プロセス：クラスタ情報を照会してPDアドレスを取得し、PDを介してGCを制御する必要があります。 - SELECT: テーブルをエクスポートする際に必須です。 -- RELOAD: `consistency`のレベルが`flush`の場合に必要です。アップストリームが RDS データベースまたはマネージド サービスの場合は、この権限を無視できます。 +- RELOAD: `consistency`のレベルが`flush`の場合に必要です。アップストリームが RDS データベースまたはマネージドサービスの場合は、この権限を無視できます。 - テーブルのロック: `consistency`のレベルが`lock`の場合に必要です。この権限は、エクスポートするすべてのデータベースとテーブルに対して付与する必要があります。 - レプリケーションクライアント：データスナップショットを記録するためにメタデータをエクスポートする場合に必要です。この権限はオプションであり、メタデータをエクスポートする必要がない場合は無視できます。 - ビューの表示：エクスポート用のビューメタデータを収集するために必要です。 @@ -92,11 +92,11 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 2 - `-h` 、 `-P` 、および`-u`オプションは、それぞれアドレス、ポート、およびユーザーを意味します。認証にパスワードが必要な場合は、 `-p $YOUR_SECRET_PASSWORD`を使用してパスワードをDumplingに渡すことができます。 -- `-o` (または`--output` ) オプションは、ストレージのエクスポート ディレクトリを指定します。これは、絶対ローカル ファイル パスまたは[外部ストレージURI](/external-storage-uri.md)をサポートします。 +- `-o` (または`--output` ) オプションは、ストレージのエクスポート ディレクトリを指定します。これは、絶対ローカルファイルパスまたは[外部ストレージURI](/external-storage-uri.md)をサポートします。 - `-t`オプションは、エクスポートに使用するスレッド数を指定します。スレッド数を増やすと、Dumplingの並列処理能力とエクスポート速度が向上しますが、データベースのメモリ使用量も増加します。そのため、スレッド数をあまり大きく設定することは推奨されません。通常は 64 未満に設定します。 -- `-r`オプションは、テーブル内同時実行を有効にしてエクスポートを高速化します。デフォルトでは無効になっています (値`0` )。 `0`より大きい値で有効にした場合、動作はソース データベースによって異なります。 +- `-r`オプションは、テーブル内同時実行を有効にしてエクスポートを高速化します。デフォルトでは無効になっています (値`0` )。 `0`より大きい値で有効にした場合、動作はソースデータベースによって異なります。 - TiDBの場合、 Dumplingはリージョン情報を使用して分割を行うため、メモリ使用量も削減されます。指定された`-r`の値は、分割アルゴリズムには影響しません。 - MySQLの場合、このオプションは、主キー（または複合主キーの最初の列）が`INT`または`STRING`型である場合にサポートされます。 @@ -133,7 +133,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'se -- `--sql`オプションを使用すると、 Dumpling はエクスポートされたテーブルとスキーマ情報を取得できません。 `--output-filename-template`オプションを使用すると、CSV ファイルのファイル名形式を指定できます。これにより、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してデータ ファイルをインポートする際に便利です。たとえば、 `--output-filename-template='test.sbtest1.{{.Index}}'`は、エクスポートされた CSV ファイルの名前が`test.sbtest1.000000000`または`test.sbtest1.000000001`となることを指定します。 +- `--sql`オプションを使用すると、 Dumpling はエクスポートされたテーブルとスキーマ情報を取得できません。 `--output-filename-template`オプションを使用すると、CSV ファイルのファイル名形式を指定できます。これにより、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してデータファイルをインポートする際に便利です。たとえば、 `--output-filename-template='test.sbtest1.{{.Index}}'`は、エクスポートされた CSV ファイルの名前が`test.sbtest1.000000000`または`test.sbtest1.000000001`となることを指定します。 @@ -236,7 +236,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -r 200000 -o "s3://${Bucket}/${Folder #### `--where`オプションを使用してデータをフィルタリングします {#use-the-where-option-to-filter-data} -デフォルトでは、 Dumpling はシステム データベース ( `mysql` 、 `sys` 、 `INFORMATION_SCHEMA` 、 `PERFORMANCE_SCHEMA` 、 `METRICS_SCHEMA` 、および`INSPECTION_SCHEMA` ) を除くすべてのデータベースをエクスポートします。 `--where `を使用して、エクスポートするレコードを選択できます。 +デフォルトでは、 Dumpling はシステムデータベース ( `mysql` 、 `sys` 、 `INFORMATION_SCHEMA` 、 `PERFORMANCE_SCHEMA` 、 `METRICS_SCHEMA` 、および`INSPECTION_SCHEMA` ) を除くすべてのデータベースをエクスポートします。 `--where `を使用して、エクスポートするレコードを選択できます。 ```shell tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --where "id < 100" @@ -273,7 +273,7 @@ Dumpling、 `-B`オプションを使用して特定のデータベースをエ エクスポートされたファイルは、デフォルトでは`./export-`ディレクトリに保存されます。よく使用されるオプションは以下のとおりです。 - `-t`オプションは、エクスポートに使用するスレッド数を指定します。スレッド数を増やすと、Dumplingの並列処理能力とエクスポート速度が向上しますが、データベースのメモリ使用量も増加します。そのため、スレッド数をあまり大きく設定することはお勧めしません。 -- `-r`オプションは、テーブル内同時実行を有効にしてエクスポートを高速化します。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソース データベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソースデータベースがMySQLで、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 +- `-r`オプションは、テーブル内同時実行を有効にしてエクスポートを高速化します。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソースデータベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソースデータベースがMySQLで、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 - `--compress `オプションは、ダンプの圧縮形式を指定します。このオプションは、 `gzip` 、 `snappy` 、および`zstd`の圧縮アルゴリズムをサポートしています。ストレージがボトルネックになっている場合や、ストレージ容量が懸念される場合は、このオプションを使用するとデータのダンプを高速化できます。ただし、CPU 使用率が増加するという欠点があります。各ファイルは個別に圧縮されます。 上記のオプションを指定することで、 Dumplingはより高速なデータエクスポートを実現できます。 @@ -286,7 +286,7 @@ Dumpling、 `-B`オプションを使用して特定のデータベースをエ Dumpling は`--consistency `オプションを使用して、「一貫性の保証」のためにデータをエクスポートする方法を制御します。スナップショットを使用して一貫性を確保する場合、 `--snapshot`オプションを使用してバックアップするタイムスタンプを指定できます。また、次のレベルの一貫性も使用できます。 -- `flush` : [`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)を使用すると、レプリカ データベースの DML および DDL 操作を一時的に中断し、バックアップ 接続のグローバルな一貫性を確保し、binlog位置 (POS) 情報を記録できます。ロックは、すべてのバックアップ 接続がトランザクションを開始すると解放されます。フル バックアップは、ピーク時以外の時間帯、または MySQL レプリカ データベースで実行することをお勧めします。TiDB はこの値をサポートしていないことに注意してください。 +- `flush` : [`FLUSH TABLES WITH READ LOCK`](https://dev.mysql.com/doc/refman/8.0/en/flush.html#flush-tables-with-read-lock)を使用すると、レプリカ データベースの DML および DDL 操作を一時的に中断し、バックアップ 接続のグローバルな一貫性を確保し、binlog位置 (POS) 情報を記録できます。ロックは、すべてのバックアップ 接続がトランザクションを開始すると解放されます。フルバックアップは、ピーク時以外の時間帯、または MySQL レプリカ データベースで実行することをお勧めします。TiDB はこの値をサポートしていないことに注意してください。 - `snapshot` : 指定されたタイムスタンプの一貫性のあるスナップショットを取得し、エクスポートします。 - `lock` : エクスポートするすべてのテーブルに読み取りロックを追加します。 - `none` : 一貫性は保証されません。 @@ -313,7 +313,7 @@ ls -lh /tmp/test | awk '{print $5 "\t" $9}' Dumpling は`--snapshot`オプションを指定して、特定の[`tidb_snapshot`](/read-historical-data.md#how-tidb-reads-data-from-history-versions)のデータをエクスポートできます。 -`--snapshot`オプションは、TSO ( `Position`コマンドによって出力される`SHOW MASTER STATUS`フィールド) または`datetime`データ タイプの有効時間 ( `YYYY-MM-DD hh:mm:ss`の形式) に設定できます。例: +`--snapshot`オプションは、TSO ( `Position`コマンドによって出力される`SHOW MASTER STATUS`フィールド) または`datetime`データタイプの有効時間 ( `YYYY-MM-DD hh:mm:ss`の形式) に設定できます。例: ```shell tiup dumpling --snapshot 417773951312461825 @@ -326,8 +326,8 @@ TSOが`417773951312461825`で時刻が`2020-07-02 17:12:45`のときのTiDB履 DumplingがTiDBから大きな単一テーブルをエクスポートする際、エクスポートされるデータサイズが大きすぎるためにメモリ不足（OOM）が発生し、接続が中断されてエクスポートが失敗する場合があります。TiDBのメモリ使用量を削減するには、以下のパラメータを使用してください。 -- `-r`を設定すると、エクスポートするデータがチャンクに分割されます。これにより、TiDB のデータ スキャンのメモリオーバーヘッドが削減され、同時テーブル データ ダンプが可能になり、エクスポート効率が向上します。アップストリーム データベースが TiDB v3.0 以降のバージョンの場合、 `-r`の値が 0 より大きい場合は、TiDB リージョン情報が分割に使用され、特定の`-r`の値は分割アルゴリズムに影響しません。 -- `--tidb-mem-quota-query`の値を`8589934592` (8 GB) 以下まで減らしてください。 `--tidb-mem-quota-query` TiDB の単一クエリ ステートメントのメモリ使用量を制御します。 +- `-r`を設定すると、エクスポートするデータがチャンクに分割されます。これにより、TiDB のデータスキャンのメモリオーバーヘッドが削減され、同時テーブルデータ ダンプが可能になり、エクスポート効率が向上します。アップストリーム データベースが TiDB v3.0 以降のバージョンの場合、 `-r`の値が 0 より大きい場合は、TiDB リージョン情報が分割に使用され、特定の`-r`の値は分割アルゴリズムに影響しません。 +- `--tidb-mem-quota-query`の値を`8589934592` (8 GB) 以下まで減らしてください。 `--tidb-mem-quota-query` TiDB の単一クエリステートメントのメモリ使用量を制御します。 - `--params "tidb_distsql_scan_concurrency=5"`パラメータを調整します。[`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)は、TiDB でのスキャン操作の同時実行性を制御するセッション変数です。 ### TiDBのGC時間を手動で設定する {#manually-set-the-tidb-gc-time} @@ -364,7 +364,7 @@ SET GLOBAL tidb_gc_life_time = '10m'; | `--case-sensitive` | テーブルフィルターが大文字と小文字を区別するかどうか | 偽（大文字小文字を区別しない） | | `-h`または`--host` | 接続されたデータベースホストのIPアドレス | 「127.0.0.1」 | | `-t`または`--threads` | 同時バックアップスレッド数 | 4 | -| `-r`または`--rows` | テーブル内同時実行を有効にすると、エクスポートが高速化されます。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソース データベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソース データベースが MySQL で、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 | | +| `-r`または`--rows` | テーブル内同時実行を有効にすると、エクスポートが高速化されます。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソースデータベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソースデータベースが MySQL で、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 | | | `-L`または`--logfile` | ログ出力アドレス。空欄の場合は、ログはコンソールに出力されます。 | 「」 | | `--loglevel` | ログレベル {debug,info,warn,error,dpanic, panic,fatal} | "info" | | `--logfmt` | ログ出力形式：{text,json} | "text" | diff --git a/dynamic-config.md b/dynamic-config.md index a11c5e4606fae..336fd41a5557a 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -113,7 +113,7 @@ show warnings; | コンフィグレーション項目 | 説明 | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | -| ログレベル | ログ レベル。 | +| ログレベル | ログレベル。 | | `raftstore.raft-max-inflight-msgs` | 確認するRaftログの数。この数を超えると、 Raftステートマシンはログの送信速度を低下させます。 | | `raftstore.raft-log-gc-tick-interval` | Raftログを削除するポーリングタスクがスケジュールされる時間間隔 | | `raftstore.raft-log-gc-threshold` | 残存Raftログの最大許容数に関するソフト制限 | @@ -143,15 +143,15 @@ show warnings; | `raftstore.local-read-batch-size` | 1バッチで処理される読み取り要求の最大数 | | `raftstore.apply-yield-write-size` | 適用スレッドが各ラウンドで1つのFSM（有限状態機械）に書き込むことができる最大バイト数 | | `raftstore.hibernate-timeout` | 起動時に休止状態に入るまでの最短待機時間。この時間内は、TiKV は休止状態になりません（解放されません）。 | -| `raftstore.apply-pool-size` | ディスクにデータをフラッシュするプール内のスレッドの数。これは適用スレッド プールのサイズです。 | +| `raftstore.apply-pool-size` | ディスクにデータをフラッシュするプール内のスレッドの数。これは適用スレッドプールのサイズです。 | | `raftstore.store-pool-size` | Raftを処理するプール内のスレッドの数。これはRaftstoreスレッドプールのサイズです。 | | `raftstore.apply-max-batch-size` | Raftステートマシンは、BatchSystemによってデータ書き込みリクエストをバッチ処理します。この設定項目は、1バッチでリクエストを実行できるRaftステートマシンの最大数を指定します。 | | `raftstore.store-max-batch-size` | Raftステートマシンは、BatchSystemによってログをディスクにフラッシュするリクエストをバッチ処理します。この設定項目は、1回のバッチでリクエストを処理できるRaftステートマシンの最大数を指定します。 | -| `raftstore.store-io-pool-size` | Raft I/Oタスクを処理するスレッドの数。これは StoreWriter スレッド プールのサイズでもあります (この値を 0 以外の値から 0 に、または 0 から 0 以外の値に変更**しないでください**) | +| `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-thread-count` | 読み取り要求を均一に処理するスレッドプール内のスレッドの最大数。これは UnifyReadPool スレッドプールのサイズです。 | | `readpool.unified.max-tasks-per-worker` | 統合読み取りプール内の 1 つのスレッドに許可されるタスクの最大数。値を超えると`Server Is Busy`エラーが返されます。 | -| `readpool.unified.auto-adjust-pool-size` | UnifyReadPool スレッド プールのサイズを自動的に調整するかどうかを決定します | +| `readpool.unified.auto-adjust-pool-size` | UnifyReadPool スレッドプールのサイズを自動的に調整するかどうかを決定します | | `resource-control.priority-ctl-strategy` | 低優先度タスクのフロー制御戦略を構成します。 | | `coprocessor.split-region-on-table` | テーブルごとにリージョンを分割できます | | `coprocessor.batch-split-limit` | バッチでのリージョン分割のしきい値 | diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md index 45fe3b468845c..e446abc5e7876 100644 --- a/ecosystem-tool-user-case.md +++ b/ecosystem-tool-user-case.md @@ -21,7 +21,7 @@ Kubernetes上でTiDBをデプロイ・運用する必要がある場合は、Kub ## MySQL/ Auroraから完全なデータをインポート {#import-full-data-from-mysql-aurora} -MySQL/ Auroraから完全なデータをインポートする必要がある場合は、まず[Dumpling](/dumpling-overview.md)を使用してデータを SQL ダンプ ファイルとしてエクスポートし、次に[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してデータを TiDB クラスターにインポートします。 +MySQL/ Auroraから完全なデータをインポートする必要がある場合は、まず[Dumpling](/dumpling-overview.md)を使用してデータを SQL ダンプファイルとしてエクスポートし、次に[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してデータを TiDB クラスターにインポートします。 ## MySQL/ Auroraからデータを移行する {#migrate-data-from-mysql-aurora} @@ -37,7 +37,7 @@ TiDB クラスターをバックアップする必要がある場合、または ## TiDBへのデータの移行 {#migrate-data-to-tidb} -TiDB クラスターから別の TiDB クラスターにデータを移行する必要がある場合は、 [Dumpling](/dumpling-overview.md)を使用して TiDB から完全なデータを SQL ダンプ ファイルとしてエクスポートし、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してデータを別の TiDB クラスターにインポートします。 +TiDB クラスターから別の TiDB クラスターにデータを移行する必要がある場合は、 [Dumpling](/dumpling-overview.md)を使用して TiDB から完全なデータを SQL ダンプファイルとしてエクスポートし、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してデータを別の TiDB クラスターにインポートします。 増分データも移行する必要がある場合は、 [TiCDC](/ticdc/ticdc-overview.md)を使用できます。 diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md index 2303555f1b56d..0e0fc598db1cf 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -63,7 +63,7 @@ DM の基本は次のとおりです。 ### 完全なデータエクスポート - Dumpling {#full-data-export-dumpling} -[Dumpling](/dumpling-overview.md)は、MySQL または TiDB からの論理的な完全データ エクスポートをサポートします。 +[Dumpling](/dumpling-overview.md)は、MySQL または TiDB からの論理的な完全データエクスポートをサポートします。 Dumplingの基本は次のとおりです。 diff --git a/enable-disk-spill-encrypt.md b/enable-disk-spill-encrypt.md index 1f8113af7895e..bc769ed7397b6 100644 --- a/enable-disk-spill-encrypt.md +++ b/enable-disk-spill-encrypt.md @@ -1,6 +1,6 @@ --- title: Enable Encryption for Disk Spill -summary: TiDB でディスク スピルの暗号化を有効にする方法を学習します。 +summary: TiDB でディスクスピルの暗号化を有効にする方法を学習します。 --- # ディスク流出時の暗号化機能を有効にする {#enable-encryption-for-disk-spill} @@ -11,7 +11,7 @@ summary: TiDB でディスク スピルの暗号化を有効にする方法を ## 設定 {#configure} -ディスク スピル ファイルの暗号化を有効にするには、TiDB 構成ファイルのセクション`[security]`の項目[`spilled-file-encryption-method`](/tidb-configuration-file.md#spilled-file-encryption-method)構成します。 +ディスクスピル ファイルの暗号化を有効にするには、TiDB 構成ファイルのセクション`[security]`の項目[`spilled-file-encryption-method`](/tidb-configuration-file.md#spilled-file-encryption-method)構成します。 ```toml [security] diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 2582edb559c58..786773fc42b2e 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -233,7 +233,7 @@ TiDBコンポーネント間の通信にTLSを設定したら、以下のコマ ## 証明書を再読み込みする {#reload-certificates} -- TiDB クラスターがローカル データ センターに展開されている場合、証明書とキーを再ロードするために、TiDB、PD、TiKV、 TiFlash、TiCDC、およびすべての種類のクライアントは、新しい接続が作成されるたびに、TiDB クラスターを再起動せずに現在の証明書とキー ファイルを再読み取ります。 +- TiDB クラスターがローカルデータセンターに展開されている場合、証明書とキーを再ロードするために、TiDB、PD、TiKV、 TiFlash、TiCDC、およびすべての種類のクライアントは、新しい接続が作成されるたびに、TiDB クラスターを再起動せずに現在の証明書とキー ファイルを再読み取ります。 - TiProxy は 1 時間に 1 回、ディスクから証明書を再読み込みします。 diff --git a/encryption-at-rest.md b/encryption-at-rest.md index a7fee77c77930..6416d4bd764da 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -21,7 +21,7 @@ TiDBクラスターをデプロイすると、ユーザーデータの大部分 TiKVは保存時の暗号化をサポートしています。この機能により、TiKVは[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)または[SM4](https://en.wikipedia.org/wiki/SM4_(cipher)) in [CTR](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)モードを使用してデータファイルを透過的に暗号化できます。保存時の暗号化を有効にするには、ユーザーが暗号化キーを提供する必要があります。このキーはマスターキーと呼ばれます。TiKVは、実際のデータファイルの暗号化に使用したデータキーを自動的にローテーションします。マスターキーは手動で随時ローテーションできます。保存時の暗号化は、保存中のデータ（つまりディスク上）のみを暗号化し、ネットワーク経由で転送中のデータは暗号化しないことに注意してください。保存時の暗号化とTLSを併用することをお勧めします。 -クラウド展開とセルフホスト展開の両方でキー管理サービス (KMS) を使用することも、プレーンテキストのマスター キーをファイルで提供することもできます。 +クラウド展開とセルフホスト展開の両方でキー管理サービス (KMS) を使用することも、プレーンテキストのマスターキーをファイルで提供することもできます。 TiKVは現在、コアダンプから暗号鍵とユーザーデータを除外していません。保存時の暗号化を使用する場合は、TiKVプロセスのコアダンプを無効にすることをお勧めします。これは現在、TiKV自体では処理されていません。 @@ -84,7 +84,7 @@ data-key-rotation-period = "168h" # 7 days - `data-key-rotation-period`は、TiKV がキーをローテーションする頻度を指定します。 -暗号化が有効になっている場合（つまり、 `data-encryption-method`の値が`"plaintext"`ではない場合）、次のいずれかの方法でマスター キーを指定する必要があります。 +暗号化が有効になっている場合（つまり、 `data-encryption-method`の値が`"plaintext"`ではない場合）、次のいずれかの方法でマスターキーを指定する必要があります。 - [KMS経由でマスターキーを指定する](#specify-a-master-key-via-kms) - [ファイル経由でマスターキーを指定する](#specify-a-master-key-via-a-file) @@ -158,7 +158,7 @@ gcloud kms keys create "key-name" --keyring "key-ring-name" --location "global" **ステップ2. マスターキーを設定する** -Google Cloud KMS を使用してマスター キーを指定するには、 `[security.encryption]`セクションの後に`[security.encryption.master-key]`構成を追加します。 +Google Cloud KMS を使用してマスターキーを指定するには、 `[security.encryption]`セクションの後に`[security.encryption.master-key]`構成を追加します。 ``` [security.encryption.master-key] @@ -198,7 +198,7 @@ Azure でキーを作成するには、 [Azure ポータルを使用して Azure **ステップ2. マスターキーを設定する** -Azure KMS を使用してマスター キーを指定するには、TiKV 構成ファイルの`[security.encryption]`セクションの後に`[security.encryption.master-key]`構成を追加します。 +Azure KMS を使用してマスターキーを指定するには、TiKV 構成ファイルの`[security.encryption]`セクションの後に`[security.encryption.master-key]`構成を追加します。 ``` [security.encryption.master-key] @@ -228,7 +228,7 @@ client_secret = "" #### ファイル経由でマスターキーを指定する {#specify-a-master-key-via-a-file} -ファイルに保存されているマスター キーを指定する場合、マスター キーの構成は次のようになります。 +ファイルに保存されているマスターキーを指定する場合、マスターキーの構成は次のようになります。 ``` [security.encryption.master-key] @@ -269,7 +269,7 @@ TiKVをGrafanaでデプロイしている場合は、保存時の暗号化を監 - 暗号化の初期化: TiKV起動時に暗号化が初期化された場合は1、それ以外の場合は0。マスターキーのローテーションの場合、暗号化が初期化された後は、TiKVは以前のマスターキーにアクセスする必要はありません。 - 暗号化データキー：既存のデータキーの数。データキーのローテーションが発生するたびに、この数は1ずつ増加します。この指標を使用して、データキーのローテーションが期待どおりに機能しているかどうかを監視します。 - 暗号化ファイル: 現在存在する暗号化データファイルの数。この数とデータディレクトリ内の既存のデータファイル数を比較することで、暗号化されていないクラスタの暗号化を有効にする際に、暗号化されるデータの量を推定できます。 -- 暗号化メタファイル サイズ: 暗号化メタデータ ファイルのサイズ。 +- 暗号化メタファイルサイズ: 暗号化メタデータファイルのサイズ。 - 読み取り/書き込み暗号化メタ期間: 暗号化のメタデータを操作するための追加のオーバーヘッド。 デバッグのために、 `tikv-ctl`コマンドを使用すると、ファイルの暗号化に使用された暗号化方式やデータキーID、データキーのリストなどの暗号化メタデータをダンプできます。この操作により機密データが漏洩する可能性があるため、本番での使用は推奨されません。[TiKV Control](/tikv-control.md#dump-encryption-metadata)ドキュメントを参照してください。 @@ -348,7 +348,7 @@ server_configs: 上記の設定項目の意味は TiKV と同じです。 -ファイルに保存されているマスター キーを指定するには、 `tiflash-learner.toml`構成ファイルに次の構成を追加します。 +ファイルに保存されているマスターキーを指定するには、 `tiflash-learner.toml`構成ファイルに次の構成を追加します。 ``` [security.encryption.master-key] @@ -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..49ce0a37eab6e 100644 --- a/error-codes.md +++ b/error-codes.md @@ -1,6 +1,6 @@ --- title: Error Codes and Troubleshooting -summary: TiDB のエラー コードと解決策について学習します。 +summary: TiDB のエラーコードと解決策について学習します。 --- # エラーコードとトラブルシューティング {#error-codes-and-troubleshooting} @@ -15,7 +15,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 > > 一部のエラーコードは内部エラーを表します。通常、TiDBはエラーをユーザーに返すのではなく、処理するため、一部のエラーコードはここには記載されていません。 > -> ここに記載されていないエラー コードが発生した場合は、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 +> ここに記載されていないエラーコードが発生した場合は、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 - エラー番号: 8001 @@ -287,7 +287,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8113 - `Prepare`ステートメントの実行後、 `EXECUTE`ステートメントに関連付けられたテーブル スキーマが変更されました。 + `Prepare`ステートメントの実行後、 `EXECUTE`ステートメントに関連付けられたテーブルスキーマが変更されました。 - エラー番号: 8115 @@ -485,7 +485,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8250 - 完全なエラー メッセージは次のとおりです。 + 完全なエラーメッセージは次のとおりです。 `ERROR 8250 (HY000) : Resource control feature is disabled. Run "SET GLOBAL tidb_enable_resource_control='on'" to enable the feature` @@ -497,7 +497,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8252 - 完全なエラー メッセージは次のとおりです。 + 完全なエラーメッセージは次のとおりです。 `ERROR 8252 (HY000) : Exceeded resource group quota limitation` diff --git a/explain-aggregation.md b/explain-aggregation.md index 5062c13cbc42c..0fcc4067acc35 100644 --- a/explain-aggregation.md +++ b/explain-aggregation.md @@ -65,7 +65,7 @@ EXPLAIN SELECT COUNT(*) FROM t1; 4 rows in set (0.00 sec) ``` -これは`EXPLAIN ANALYZE`で最も簡単に確認できます。`EXPLAIN ANALYZE`では、 `TableFullScan`が使用されており、セカンダリ インデックスがないため、 `actRows`は`SHOW TABLE REGIONS`のリージョンの数と一致しています。 +これは`EXPLAIN ANALYZE`で最も簡単に確認できます。`EXPLAIN ANALYZE`では、 `TableFullScan`が使用されており、セカンダリインデックスがないため、 `actRows`は`SHOW TABLE REGIONS`のリージョンの数と一致しています。 ```sql EXPLAIN ANALYZE SELECT COUNT(*) FROM t1; diff --git a/explain-indexes.md b/explain-indexes.md index dc9b8bd25d8b5..585a26489d701 100644 --- a/explain-indexes.md +++ b/explain-indexes.md @@ -12,7 +12,7 @@ TiDB は、インデックスを利用してクエリの実行を高速化する - [`Point_Get`と`Batch_Point_Get`](#point_get-and-batch_point_get) - [`IndexFullScan`](#indexfullscan) -このドキュメントの例は、次のサンプル データに基づいています。 +このドキュメントの例は、次のサンプルデータに基づいています。 ```sql CREATE TABLE t1 ( @@ -90,7 +90,7 @@ EXPLAIN SELECT * FROM t1 WHERE intkey >= 99 AND intkey <= 103; `IndexLookup`演算子には 2 つの子ノードがあります。 - `├─IndexRangeScan_8(Build)`演算子は`intkey`インデックスの範囲スキャンを実行し、内部の`RowID` (このテーブルの場合は主キー) の値を取得します。 -- 次に、 `└─TableRowIDScan_9(Probe)`演算子はテーブル データから完全な行を取得します。 +- 次に、 `└─TableRowIDScan_9(Probe)`演算子はテーブルデータから完全な行を取得します。 `IndexLookup`タスクには2つのステップが必要なため、多数の行が一致するシナリオでは、SQLオプティマイザーは[統計](/statistics.md)に基づいて`TableFullScan`演算子を選択する可能性があります。次の例では、多数の行が`intkey > 100`条件に一致するため、 `TableFullScan`が選択されます。 diff --git a/explain-joins.md b/explain-joins.md index 7b068c9ff1ffa..6585f87d031d1 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -173,7 +173,7 @@ EXPLAIN ANALYZE SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.int_ インデックス結合のパフォーマンスは、次のシステム変数の影響を受けます。 -- [`tidb_index_join_batch_size`](/system-variables.md#tidb_index_join_batch_size) (デフォルト値: `25000` ) - `index lookup join`操作のバッチ サイズ。 +- [`tidb_index_join_batch_size`](/system-variables.md#tidb_index_join_batch_size) (デフォルト値: `25000` ) - `index lookup join`操作のバッチサイズ。 - [`tidb_index_lookup_join_concurrency`](/system-variables.md#tidb_index_lookup_join_concurrency) (デフォルト値: `4` ) - 同時インデックス検索タスクの数。 ## ハッシュ結合 {#hash-join} @@ -202,9 +202,9 @@ EXPLAIN SELECT /*+ HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; `HashJoin_27`の実行プロセスでは、TiDB は次の操作を順番に実行します。 1. `Build`面分のデータをメモリにキャッシュします。 -2. キャッシュされたデータに基づいて`Build`側にハッシュ テーブルを構築します。 +2. キャッシュされたデータに基づいて`Build`側にハッシュテーブルを構築します。 3. `Probe`面のデータを読み取ります。 -4. `Probe`側のデータを使用してハッシュ テーブルをプローブします。 +4. `Probe`側のデータを使用してハッシュテーブルをプローブします。 5. 適格なデータをユーザーに返します。 結果テーブル`EXPLAIN`の`operator info`列には、クエリが内部結合か外部結合か、結合条件など、 `HashJoin_27`に関するその他の情報も記録されます。上記の例では、クエリは内部結合であり、結合条件`equal:[eq(test.t1.id, test.t2.id)]`はクエリ条件`WHERE t1.id = t2.id`と部分的に一致しています。以降の例における他の結合演算子の演算子情報も、これと同様です。 diff --git a/explain-mpp.md b/explain-mpp.md index 57debfd9eee33..ca294f38c761e 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -7,7 +7,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行計 TiDBは、 [MPPモード](/tiflash/use-tiflash-mpp-mode.md)を使用したクエリ実行をサポートしています。MPPモードでは、TiDBオプティマイザはMPP用の実行計画を生成します。MPPモードは、 [TiFlash](/tiflash/tiflash-overview.md)にレプリカを持つテーブルでのみ使用できることに注意してください。 -このドキュメントの例は、次のサンプル データに基づいています。 +このドキュメントの例は、次のサンプルデータに基づいています。 ```sql CREATE TABLE t1 (id int, value int); @@ -52,7 +52,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 GROUP BY id; +------------------------------------+---------+-------------------+---------------+----------------------------------------------------+ ``` -上記の実行計画には、2 つのクエリ フラグメントが含まれています。 +上記の実行計画には、2 つのクエリフラグメントが含まれています。 - 1 つ目は`[TableFullScan_25, HashAgg_9, ExchangeSender_28]`で、主に第 1 段階の集約を担当します。 - 2 番目は`[ExchangeReceiver_29, HashAgg_27, Projection_26, ExchangeSender_30]`で、主に第 2 段階の集約を担当します。 @@ -70,7 +70,7 @@ MPPは結合操作にもよく適用されます。TiDBのMPPモードは、以 - シャッフルハッシュ結合：HashPartition交換タイプを使用して、結合操作からの入力データをシャッフルします。その後、上流のMPPタスクが同じパーティション内のデータを結合します。 - ブロードキャスト結合: 結合操作内の小さなテーブルのデータを各ノードにブロードキャストし、その後各ノードはデータを個別に結合します。 -以下は、シャッフル ハッシュ結合の一般的な実行計画です。 +以下は、シャッフルハッシュ結合の一般的な実行計画です。 ```sql SET tidb_broadcast_join_threshold_count=0; @@ -100,9 +100,9 @@ EXPLAIN SELECT COUNT(*) FROM t1 a JOIN t1 b ON a.id = b.id; 上記の実行計画では、 -- クエリ フラグメント`[TableFullScan_20, Selection_21, ExchangeSender_22]`はテーブル b からデータを読み取り、上流の MPP タスクにデータをシャッフルします。 -- クエリ フラグメント`[TableFullScan_16, Selection_17, ExchangeSender_18]`はテーブル a からデータを読み取り、上流の MPP タスクにデータをシャッフルします。 -- クエリ フラグメント`[ExchangeReceiver_19, ExchangeReceiver_23, HashJoin_44, ExchangeSender_47]`はすべてのデータを結合し、TiDB に返します。 +- クエリフラグメント`[TableFullScan_20, Selection_21, ExchangeSender_22]`はテーブル b からデータを読み取り、上流の MPP タスクにデータをシャッフルします。 +- クエリフラグメント`[TableFullScan_16, Selection_17, ExchangeSender_18]`はテーブル a からデータを読み取り、上流の MPP タスクにデータをシャッフルします。 +- クエリフラグメント`[ExchangeReceiver_19, ExchangeReceiver_23, HashJoin_44, ExchangeSender_47]`はすべてのデータを結合し、TiDB に返します。 Broadcast Join の一般的な実行計画は次のとおりです。 @@ -129,8 +129,8 @@ EXPLAIN SELECT COUNT(*) FROM t1 a JOIN t1 b ON a.id = b.id; 上記の実行計画では、 -- クエリ フラグメント`[TableFullScan_17, Selection_18, ExchangeSender_19]` 、小さなテーブル (テーブル a) からデータを読み取り、大きなテーブル (テーブル b) のデータを含む各ノードにデータをブロードキャストします。 -- クエリ フラグメント`[TableFullScan_21, Selection_22, ExchangeReceiver_20, HashJoin_43, ExchangeSender_46]`はすべてのデータを結合し、TiDB に返します。 +- クエリフラグメント`[TableFullScan_17, Selection_18, ExchangeSender_19]` 、小さなテーブル (テーブル a) からデータを読み取り、大きなテーブル (テーブル b) のデータを含む各ノードにデータをブロードキャストします。 +- クエリフラグメント`[TableFullScan_21, Selection_22, ExchangeReceiver_20, HashJoin_43, ExchangeSender_46]`はすべてのデータを結合し、TiDB に返します。 ## MPPモードでの`EXPLAIN ANALYZE`文 {#explain-analyze-statements-in-the-mpp-mode} diff --git a/explain-overview.md b/explain-overview.md index 48c4ac453a252..51674e9a23cf6 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -134,7 +134,7 @@ Records: 2 Duplicates: 0 Warnings: 0 - **TableFullScan** : テーブル全体のスキャン - **TableRangeScan** : 指定された範囲でテーブルをスキャンします - **TableRowIDScan** : RowIDに基づいてテーブルデータをスキャンします。通常、インデックス読み取り操作の後に、一致するデータ行を取得します。 -- **IndexFullScan** : テーブル データではなくインデックスがスキャンされる点を除いて、「フル テーブル スキャン」に似ています。 +- **IndexFullScan** : テーブルデータではなくインデックスがスキャンされる点を除いて、「フルテーブルスキャン」に似ています。 - **IndexRangeScan** : 指定された範囲でインデックスをスキャンします。 TiDBは、TiKV/ TiFlashからスキャンされたデータまたは計算結果を集約します。データ集約演算子は以下のカテゴリに分類できます。 diff --git a/explain-partitions.md b/explain-partitions.md index a7fe09c359550..73146827dde09 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -7,7 +7,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行計 `EXPLAIN`文は、TiDBがクエリを実行するためにアクセスする必要があるパーティションを表示します。[パーティションプルーニング](/partition-pruning.md)のため、表示されるパーティションはパーティション全体のサブセットのみであることがよくあります。このドキュメントでは、一般的なパーティションテーブルに対する最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 -このドキュメントで使用されているサンプル データ: +このドキュメントで使用されているサンプルデータ: ```sql CREATE TABLE t1 ( @@ -77,7 +77,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 WHERE d = '2017-06-01'; - `└─Selection_20`一致する行は、 `count`関数をネイティブに理解するコプロセッサでストリーム集約されます。 - 次に、各コプロセッサ要求は TiDB 内の`└─TableReader_22`に 1 行を送り返し、それが`StreamAgg_21`にストリーム集約されて、1 行がクライアントに返されます。 -次の例では、パーティション プルーニングによってパーティションが削除されません。 +次の例では、パーティションプルーニングによってパーティションが削除されません。 ```sql EXPLAIN SELECT COUNT(*) FROM t1 WHERE YEAR(d) = 2017; diff --git a/explain-subqueries.md b/explain-subqueries.md index 1f0910e84df71..3c80212ec0607 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -7,7 +7,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行計 TiDBはサブクエリのパフォーマンスを向上させるために[いくつかの最適化](/subquery-optimization.md)を実行します。このドキュメントでは、一般的なサブクエリに対するこれらの最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 -このドキュメントの例は、次のサンプル データに基づいています。 +このドキュメントの例は、次のサンプルデータに基づいています。 ```sql CREATE TABLE t1 (id BIGINT NOT NULL PRIMARY KEY auto_increment, pad1 BLOB, pad2 BLOB, pad3 BLOB, int_col INT NOT NULL DEFAULT 0); @@ -69,7 +69,7 @@ EXPLAIN SELECT * FROM t1 WHERE id IN (SELECT t1_id FROM t2); 上記のクエリ結果から、TiDBがインデックス結合操作`IndexJoin_15`を使用してサブクエリを結合および変換していることがわかります。実行計画では、実行プロセスは次のようになります。 -1. TiKV 側のインデックス スキャン演算子`└─IndexFullScan_26` 、 `t2.t1_id`列の値を読み取ります。 +1. TiKV 側のインデックススキャン演算子`└─IndexFullScan_26` 、 `t2.t1_id`列の値を読み取ります。 2. `└─StreamAgg_34`演算子の一部のタスクは、TiKV 内の`t1_id`の値を重複排除します。 3. 演算子`├─StreamAgg_44(Build)`のいくつかのタスクは、TiDB内の`t1_id`値を重複排除します。重複排除は集計関数`firstrow(test.t2.t1_id)`によって実行されます。 4. 演算結果はテーブル`t1`の主キーと結合されます。結合条件は`eq(test.t1.id, test.t2.t1_id)`です。 diff --git a/explore-htap.md b/explore-htap.md index 1667df530c66b..4b68bb33e92c1 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -96,7 +96,7 @@ TiDBを使用する場合、TiDBクラスタの状態とパフォーマンス指 - [TiDB Dashboard](/dashboard/dashboard-intro.md): TiDBクラスターの全体的な実行ステータスを確認し、読み取りおよび書き込みトラフィックの分布と傾向を分析し、スロークエリの詳細な実行情報を知ることができます。 - [監視システム（PrometheusおよびGrafana）](/grafana-overview-dashboard.md) : PD、TiDB、TiKV、 TiFlash、TiCDC、Node_exporterなどのTiDBクラスター関連コンポーネントの監視パラメータを確認できます。 -TiDB クラスターおよびTiFlashクラスターのアラート ルールを確認するには、 [TiDBクラスタアラートルール](/alert-rules.md)および[TiFlashアラートルール](/tiflash/tiflash-alert-rules.md)を参照してください。 +TiDB クラスターおよびTiFlashクラスターのアラートルールを確認するには、 [TiDBクラスタアラートルール](/alert-rules.md)および[TiFlashアラートルール](/tiflash/tiflash-alert-rules.md)を参照してください。 ## トラブルシューティング {#troubleshooting} @@ -112,5 +112,5 @@ TiDBの使用中に問題が発生した場合は、以下のドキュメント ## 次は？ {#what-s-next} -- TiFlash のバージョン、重要なログ、システム テーブルを確認するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 +- TiFlash のバージョン、重要なログ、システムテーブルを確認するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 - 特定のTiFlashノードを削除するには、 [TiFlashクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)を参照してください。 diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md index fe84274c75c49..b230dbae3b5fa 100644 --- a/exporting-grafana-snapshots.md +++ b/exporting-grafana-snapshots.md @@ -36,11 +36,11 @@ MetricsToolは[https://metricstool.pingcap.net/](https://metricstool.pingcap.net MetricsToolによってエクスポートされるスナップショットファイルには、取得時の実際の値が含まれています。また、Visualizerを使用すると、レンダリングされたグラフをライブGrafanaダッシュボードのように操作でき、シリーズの切り替え、より狭い時間範囲へのズームイン、特定の時点の正確な値の確認などの操作が可能です。これにより、MetricsToolは画像やPDFよりもはるかに強力になります。 -### スナップショット ファイルには何が含まれていますか? {#what-are-included-in-the-snapshot-file} +### スナップショットファイルには何が含まれていますか? {#what-are-included-in-the-snapshot-file} スナップショットファイルには、選択した時間範囲におけるすべてのグラフとパネルの値が含まれます。データソースの元のメトリックは保存されません（そのため、ビジュアライザーでクエリ式を編集することはできません）。 -### Visualizer はアップロードされたスナップショット ファイルを PingCAP のサーバーに保存しますか? {#will-the-visualizer-save-the-uploaded-snapshot-files-in-pingcap-s-servers} +### Visualizer はアップロードされたスナップショットファイルを PingCAP のサーバーに保存しますか? {#will-the-visualizer-save-the-uploaded-snapshot-files-in-pingcap-s-servers} いいえ、Visualizerはスナップショットファイルをすべてブラウザ内で解析します。PingCAPには何も送信されません。機密性の高いソースから受信したスナップショットファイルは自由に閲覧でき、Visualizerを通じて第三者に漏洩する心配はありません。 diff --git a/external-storage-uri.md b/external-storage-uri.md index 99e0a91879190..e00f486e4d68d 100644 --- a/external-storage-uri.md +++ b/external-storage-uri.md @@ -21,7 +21,7 @@ URI の基本的な形式は次のとおりです。 - `host` : `bucket name` - `parameters` : - - `access-key` : アクセス キーを指定します。 + - `access-key` : アクセスキーを指定します。 - `secret-access-key` : 秘密アクセスキーを指定します。 - `session-token` : 一時セッショントークンを指定します。BRはv7.6.0以降でこのパラメータをサポートしています。 - `use-accelerate-endpoint` : Amazon S3 の高速エンドポイントを使用するかどうかを指定します (デフォルトは`false` )。 @@ -58,7 +58,7 @@ tiup cdc:v7.5.0 cli changefeed create \ - `host` : `bucket name` - `parameters` : - - `access-key` : アクセス キーを指定します。 + - `access-key` : アクセスキーを指定します。 - `secret-access-key` : 秘密アクセスキーを指定します。 @@ -129,7 +129,7 @@ gcs://external/test.csv?credentials-file=${credentials-file-path} - `parameters` : - `account-name` :ストレージのアカウント名を指定します。 - - `account-key` : アクセス キーを指定します。 + - `account-key` : アクセスキーを指定します。 - `sas-token` : 共有アクセス署名 (SAS) トークンを指定します。 - `access-tier` : アップロードされたオブジェクトのアクセス層を指定します（例： `Hot` 、 `Cool` 、 `Archive` ）。既定値は、ストレージアカウントのデフォルトのアクセス層です。 - `encryption-scope` : サーバー側の暗号化に[暗号化範囲](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-manage?tabs=powershell#upload-a-blob-with-an-encryption-scope)を指定します。 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 18ab17fb5982c..5756e4c6566c2 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -11,7 +11,7 @@ summary: よくある質問 (FAQ) とバックアップおよび復元のソリ TiDB v6.4.0では、フラッシュバック機能が導入されました。この機能を使用すると、GC時間内に特定の時点までデータを迅速に復旧できます。そのため、誤操作が発生した場合でも、この機能を使用してデータを復旧できます。詳細は[`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md)と[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md)を参照してください。 -## TiDB v5.4.0 以降のバージョンでは、ワークロードが高いクラスターでバックアップ タスクを実行すると、バックアップ タスクの速度が遅くなるのはなぜですか? {#in-tidb-v540-and-later-versions-when-backup-tasks-are-performed-on-the-cluster-under-a-heavy-workload-why-does-the-speed-of-backup-tasks-become-slow} +## TiDB v5.4.0 以降のバージョンでは、ワークロードが高いクラスターでバックアップタスクを実行すると、バックアップタスクの速度が遅くなるのはなぜですか? {#in-tidb-v540-and-later-versions-when-backup-tasks-are-performed-on-the-cluster-under-a-heavy-workload-why-does-the-speed-of-backup-tasks-become-slow} TiDB v5.4.0以降、 BRはバックアップタスクの自動チューニング機能を導入しました。v5.4.0以降のバージョンのクラスターでは、この機能はデフォルトで有効になっています。クラスターのワークロードが高い場合、この機能はバックアップタスクで使用されるリソースを制限し、オンラインクラスターへの影響を軽減します。詳細については、 [バックアップオートチューン](/br/br-auto-tune.md)を参照してください。 @@ -22,9 +22,9 @@ TiKVは[動的構成](/tikv-control.md#modify-the-tikv-configuration-dynamically `tikv-ctl`を使用して自動調整を有効または無効にするには、 [オートチューンを使用する](/br/br-auto-tune.md#use-auto-tune)を参照してください。 -さらに、自動チューニングにより、バックアップ タスクで使用されるデフォルトのスレッド数が削減されます。詳細については、 `backup.num-threads` ](/tikv-configuration-file.md#num-threads-1) を参照してください。そのため、Grafana ダッシュボードでは、バックアップ タスクで使用される速度、CPU 使用率、および I/O リソース使用率が、v5.4.0 より前のバージョンよりも低くなります。v5.4.0 より前では、デフォルト値`backup.num-threads`は`CPU * 0.75`でした。つまり、バックアップ タスクで使用されるスレッド数は、論理 CPU コアの 75% を占めていました。その最大値は`32`でした。v5.4.0 以降、この構成項目のデフォルト値は`CPU * 0.5` 、最大値は`8`です。 +さらに、自動チューニングにより、バックアップタスクで使用されるデフォルトのスレッド数が削減されます。詳細については、 `backup.num-threads` ](/tikv-configuration-file.md#num-threads-1) を参照してください。そのため、Grafana ダッシュボードでは、バックアップタスクで使用される速度、CPU 使用率、および I/O リソース使用率が、v5.4.0 より前のバージョンよりも低くなります。v5.4.0 より前では、デフォルト値`backup.num-threads`は`CPU * 0.75`でした。つまり、バックアップタスクで使用されるスレッド数は、論理 CPU コアの 75% を占めていました。その最大値は`32`でした。v5.4.0 以降、この構成項目のデフォルト値は`CPU * 0.5` 、最大値は`8`です。 -オフライン クラスターでバックアップ タスクを実行する場合、バックアップを高速化するために、 `tikv-ctl`を使用して`backup.num-threads`の値をより大きな数値に変更できます。 +オフライン クラスターでバックアップタスクを実行する場合、バックアップを高速化するために、 `tikv-ctl`を使用して`backup.num-threads`の値をより大きな数値に変更できます。 ## PITRの問題 {#pitr-issues} @@ -46,13 +46,13 @@ TiKVは[動的構成](/tikv-control.md#modify-the-tikv-configuration-dynamically クラスター内でネットワークパーティション障害が発生すると、バックアップタスクはログのバックアップを続行できなくなります。一定の再試行時間後、タスクは状態`ERROR`に設定されます。この時点で、バックアップタスクは停止しています。 -この問題を解決するには、 `br log resume`コマンドを手動で実行して、ログ バックアップ タスクを再開する必要があります。 +この問題を解決するには、 `br log resume`コマンドを手動で実行して、ログバックアップタスクを再開する必要があります。 ## `br restore point`コマンドを使用してダウンストリームクラスターを復元した後、 TiFlashからデータにアクセスできなくなりました。どうすればよいでしょうか？ {#after-restoring-a-downstream-cluster-using-the-br-restore-point-command-data-cannot-be-accessed-from-tiflash-what-should-i-do} 現在、PITRはリストアフェーズ中にTiFlashへの直接データ書き込みをサポートしていません。代わりに、brコマンドラインツールが`ALTER TABLE table_name SET TIFLASH REPLICA ***` DDLを実行してデータを複製します。そのため、PITRによるデータリストアが完了した直後にTiFlashレプリカは利用できません。TiKVノードからデータが複製されるまで、一定時間待つ必要があります。レプリケーションの進行状況を確認するには、 `INFORMATION_SCHEMA.tiflash_replica`表の`progress`情報を確認してください。 -### ログ バックアップ タスクの`status`が`ERROR`になった場合はどうすればよいでしょうか? {#what-should-i-do-if-the-status-of-a-log-backup-task-becomes-error} +### ログバックアップタスクの`status`が`ERROR`になった場合はどうすればよいでしょうか? {#what-should-i-do-if-the-status-of-a-log-backup-task-becomes-error} ログバックアップタスクの実行中に、タスクが失敗し、再試行しても回復できない場合、タスクステータスは`ERROR`になります。以下に例を示します。 @@ -97,7 +97,7 @@ checkpoint[global]: 2022-07-25 14:46:50.118 +0000; gap=6m28s > > この機能は、複数のバージョンのデータをバックアップします。長時間のバックアップタスクが失敗し、ステータスが`ERROR`になると、このタスクのチェックポイントデータは`safe point`に設定され、 `safe point`のデータは24時間以内にガベージコレクションされません。そのため、エラーからの再開後、バックアップタスクは最後のチェックポイントから続行されます。タスクが24時間以上失敗し、最後のチェックポイントデータがガベージコレクションされている場合、タスクを再開するとエラーが報告されます。この場合、まず`br log stop`コマンドを実行してタスクを停止し、新しいバックアップタスクを開始する必要があります。 -### `br log resume`コマンドを使用して中断されたタスクを再開するときに、エラー メッセージ`ErrBackupGCSafepointExceeded`返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task} +### `br log resume`コマンドを使用して中断されたタスクを再開するときに、エラーメッセージ`ErrBackupGCSafepointExceeded`返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-errbackupgcsafepointexceeded-is-returned-when-using-the-br-log-resume-command-to-resume-a-suspended-task} ```shell Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepoint 433193092308795392 exceed TS 433177834291200000: [BR:Backup:ErrBackupGCSafepointExceeded]backup GC safepoint exceeded @@ -107,7 +107,7 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo この問題を解決するには、 `br log stop`を使用して現在のタスクを削除し、 `br log start`を使用してログバックアップタスクを作成します。同時に、後続の PITR のためにフルバックアップを実行できます。 -### PITR テーブル フィルターの使用時にエラー メッセージ`[ddl:8204]invalid ddl job type: none`が返された場合はどうすればよいですか? {#what-should-i-do-if-the-error-message-ddl8204invalid-ddl-job-type-none-is-returned-when-using-the-pitr-table-filter} +### PITR テーブルフィルターの使用時にエラーメッセージ`[ddl:8204]invalid ddl job type: none`が返された場合はどうすればよいですか? {#what-should-i-do-if-the-error-message-ddl8204invalid-ddl-job-type-none-is-returned-when-using-the-pitr-table-filter} ```shell failed to refresh meta for database with schemaID=124, dbName=pitr_test: [ddl:8204]invalid ddl job type: none @@ -117,13 +117,13 @@ failed to refresh meta for database with schemaID=124, dbName=pitr_test: [ddl:82 ## 機能の互換性の問題 {#feature-compatibility-issues} -### br コマンドライン ツールを使用して復元されたデータが TiCDC のアップストリーム クラスターに複製できないのはなぜですか? {#why-does-data-restored-using-br-command-line-tool-cannot-be-replicated-to-the-upstream-cluster-of-ticdc} +### br コマンドラインツールを使用して復元されたデータが TiCDC のアップストリームクラスターに複製できないのはなぜですか? {#why-does-data-restored-using-br-command-line-tool-cannot-be-replicated-to-the-upstream-cluster-of-ticdc} -- **BRを使用して復元されたデータは、ダウンストリームに複製できません**。これは、 BR がSST ファイルを直接インポートしますが、ダウンストリーム クラスタがアップストリームからこれらのファイルを取得できないためです。 +- **BRを使用して復元されたデータは、ダウンストリームに複製できません**。これは、 BR がSST ファイルを直接インポートしますが、ダウンストリームクラスタがアップストリームからこれらのファイルを取得できないためです。 - v4.0.3より前のバージョンでは、復元中に生成されたDDLジョブによって、TiCDCで予期しないDDL実行が発生する可能性があります。そのため、TiCDCの上流クラスターで復元を実行する必要がある場合は、brコマンドラインツールを使用して復元したすべてのテーブルをTiCDCのブロックリストに追加してください。 -[`filter.rules`](https://github.com/pingcap/tiflow/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16)を使用して、TiCDC のブロック リストを構成できます。 +[`filter.rules`](https://github.com/pingcap/tiflow/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16)を使用して、TiCDC のブロックリストを構成できます。 ### 復元中に`new_collation_enabled`不一致が報告されるのはなぜですか? {#why-is-new_collation_enabled-mismatch-reported-during-restore} @@ -152,13 +152,13 @@ v6.0.0より前では、 BRは[配置ルール](/placement-rules-in-sql.md)サ このエラーは、復元するクラスターの容量が不足している場合に発生する可能性があります。このクラスターの監視メトリックまたはTiKVログを確認することで、原因をさらに確認できます。 -この問題に対処するには、クラスター リソースをスケール アウトし、復元の値`tikv-max-restore-concurrency`を減らして、オプション`ratelimit`を有効にしてみてください。 +この問題に対処するには、クラスター リソースをスケールアウトし、復元の値`tikv-max-restore-concurrency`を減らして、オプション`ratelimit`を有効にしてみてください。 -### `the entry too large, the max entry size is 6291456, the size of data is 7690800` 」というエラー メッセージが表示されて復元が失敗した場合は、どうすればよいでしょうか。 {#what-should-i-do-if-the-restore-fails-with-the-error-message-the-entry-too-large-the-max-entry-size-is-6291456-the-size-of-data-is-7690800} +### `the entry too large, the max entry size is 6291456, the size of data is 7690800` 」というエラーメッセージが表示されて復元が失敗した場合は、どうすればよいでしょうか。 {#what-should-i-do-if-the-restore-fails-with-the-error-message-the-entry-too-large-the-max-entry-size-is-6291456-the-size-of-data-is-7690800} `--ddl-batch-size` ～ `128`またはそれより小さい値を設定することで、バッチで作成されるテーブルの数を減らすことができます。 -BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-create-table)の値が`1`より大きいバックアップ データを復元する場合、TiDB はテーブル作成の DDL ジョブを TiKV が管理する DDL ジョブ キューに書き込みます。このとき、ジョブ メッセージの最大値がデフォルトで`6 MB`であるため (この値を変更することは**推奨されません**。詳細については、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)と[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を参照してください)、TiDB が一度に送信するすべてのテーブル スキーマの合計サイズは 6 MB を超えてはなりません。したがって、 `--ddl-batch-size`過度に大きな値に設定すると、TiDB が一度にバッチで送信するテーブルのスキーマ サイズが指定値を超え、 BR が`entry too large, the max entry size is 6291456, the size of data is 7690800`エラーを報告します。 +BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-create-table)の値が`1`より大きいバックアップデータを復元する場合、TiDB はテーブル作成の DDL ジョブを TiKV が管理する DDL ジョブキューに書き込みます。このとき、ジョブ メッセージの最大値がデフォルトで`6 MB`であるため (この値を変更することは**推奨されません**。詳細については、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)と[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を参照してください)、TiDB が一度に送信するすべてのテーブルスキーマの合計サイズは 6 MB を超えてはなりません。したがって、 `--ddl-batch-size`過度に大きな値に設定すると、TiDB が一度にバッチで送信するテーブルのスキーマ サイズが指定値を超え、 BR が`entry too large, the max entry size is 6291456, the size of data is 7690800`エラーを報告します。 ### `local`ストレージを使用する場合、バックアップされたファイルはどこに保存されますか? {#where-are-the-backed-up-files-stored-when-i-use-local-storage} @@ -168,7 +168,7 @@ BRを使用して[`--ddl-batch-size`](/br/br-batch-create-table.md#use-batch-cre ローカルストレージを使用する場合、 BRが稼働しているノードに`backupmeta`が生成され、各リージョンのLeaderノードにバックアップファイルが生成されます。 -### データの復元中に`could not read local://...:download sst failed`というエラー メッセージが返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-could-not-read-localdownload-sst-failed-is-returned-during-data-restore} +### データの復元中に`could not read local://...:download sst failed`というエラーメッセージが返された場合、どうすればよいですか? {#what-should-i-do-if-the-error-message-could-not-read-localdownload-sst-failed-is-returned-during-data-restore} データを復元する場合、各ノードは**すべての**バックアップファイル（SSTファイル）にアクセスできる必要があります。デフォルトでは、ストレージを`local`を使用している場合、バックアップファイルが複数のノードに分散しているため、データを復元できません。そのため、各TiKVノードのバックアップファイルを他のTiKVノードにコピーする必要があります。**バックアップデータは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、またはNFSに保存することをお勧めします**。 @@ -178,7 +178,7 @@ TiKVがバックアップディレクトリにアクセスできるかどうか バックアップ操作中、ストレージメディアがローカルディスクまたはネットワークファイルシステム（NFS）の場合、 `br`を起動するユーザーとTiKVを起動するユーザーが一致していることを確認してください（ `br`とTiKVが異なるマシン上にある場合は、ユーザーのUIDが一致している必要があります）。一致していない場合、 `Permission denied`問題が発生する可能性があります。 -バックアップ ファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因で`br`を`root`ユーザーとして実行すると失敗する可能性があります。 +バックアップファイル (SST ファイル) は TiKV によって保存されるため、ディスク権限が原因で`br`を`root`ユーザーとして実行すると失敗する可能性があります。 > **Note:** > @@ -267,7 +267,7 @@ br restore full -f '*.*' -f '!mysql.*' -f 'mysql.usertable' -s $external_storage br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table ``` -[テーブルフィルター](/table-filter.md#syntax)設定しても、 **BR は次のシステム テーブルを復元しないこと**に注意してください。 +[テーブルフィルター](/table-filter.md#syntax)設定しても、 **BR は次のシステムテーブルを復元しないこと**に注意してください。 - 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。[統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照してください。 - システム変数テーブル（ `mysql.tidb` `mysql.global_variables` @@ -283,13 +283,13 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table データバックアップ中、各リージョンのLeaderノードにバックアップファイルが生成されます。バックアップのサイズはデータサイズと等しく、冗長レプリカは作成されません。したがって、合計データサイズは、TiKVデータの総数をレプリカ数で割った値とほぼ等しくなります。 -ただし、ローカルストレージからデータを復元する場合、各 TiKV がすべてのバックアップ ファイルにアクセスできる必要があるため、レプリカの数は TiKV ノードの数と同じになります。 +ただし、ローカルストレージからデータを復元する場合、各 TiKV がすべてのバックアップファイルにアクセスできる必要があるため、レプリカの数は TiKV ノードの数と同じになります。 ### BRを使用してバックアップまたは復元した後、監視ノードに表示されるディスク使用量が一致しないのはなぜですか? {#why-is-the-disk-usage-shown-on-the-monitoring-node-inconsistent-after-backup-or-restore-using-br} この不整合は、バックアップで使用されるデータ圧縮率が、復元で使用されるデフォルトの圧縮率と異なるために発生します。チェックサムが成功した場合は、この問題は無視できます。 -### BR がバックアップ データを復元した後、テーブルとインデックスの TiDB の統計を更新するために、テーブルに対して`ANALYZE`ステートメントを実行する必要がありますか? {#after-br-restores-the-backup-data-do-i-need-to-execute-the-analyze-statement-on-the-table-to-update-the-statistics-of-tidb-on-the-tables-and-indexes} +### BR がバックアップデータを復元した後、テーブルとインデックスの TiDB の統計を更新するために、テーブルに対して`ANALYZE`ステートメントを実行する必要がありますか? {#after-br-restores-the-backup-data-do-i-need-to-execute-the-analyze-statement-on-the-table-to-update-the-statistics-of-tidb-on-the-tables-and-indexes} BRは統計情報をバックアップしません（v4.0.9を除く）。そのため、バックアップデータを復元した後は、 `ANALYZE TABLE`手動で実行するか、TiDBが`ANALYZE`自動的に実行するのを待つ必要があります。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 8bad1875b9a57..f191f87d67175 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -9,15 +9,15 @@ summary: TiDB のデプロイメントに関連する FAQ について説明し ## ソフトウェアとハ​​ードウェアの要件 {#software-and-hardware-requirements} -### TiDB はどのオペレーティング システムをサポートしていますか? {#what-operating-systems-does-tidb-support} +### TiDB はどのオペレーティングシステムをサポートしていますか? {#what-operating-systems-does-tidb-support} -TiDB がサポートするオペレーティング システムについては、 [ソフトウェアとハ​​ードウェアの推奨事項](/hardware-and-software-requirements.md)を参照してください。 +TiDB がサポートするオペレーティングシステムについては、 [ソフトウェアとハ​​ードウェアの推奨事項](/hardware-and-software-requirements.md)を参照してください。 ### 開発、テスト、または本番環境における TiDB クラスターの推奨ハードウェア構成は何ですか? {#what-is-the-recommended-hardware-configuration-for-a-tidb-cluster-in-the-development-test-or-production-environment} 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ギガビットネットワークカードの使用を強くお勧めします。 @@ -39,7 +39,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ### TiKV/PD 用に変更された`toml`構成が有効にならないのはなぜですか? {#why-the-modified-toml-configuration-for-tikvpd-does-not-take-effect} -`toml`設定を有効にするには、TiKV/PD で`--config`パラメータを設定する必要があります。TiKV/PD はデフォルトでは設定を読み取りません。現在、この問題はバイナリを使用してデプロイする場合にのみ発生します。TiKV の場合は、設定を編集してサービスを再起動してください。PD の場合は、設定ファイルは PD の初回起動時にのみ読み込まれ、その後は pd-ctl を使用して設定を変更できます。詳細は[PD Controlユーザー ガイド](/pd-control.md)を参照してください。 +`toml`設定を有効にするには、TiKV/PD で`--config`パラメータを設定する必要があります。TiKV/PD はデフォルトでは設定を読み取りません。現在、この問題はバイナリを使用してデプロイする場合にのみ発生します。TiKV の場合は、設定を編集してサービスを再起動してください。PD の場合は、設定ファイルは PD の初回起動時にのみ読み込まれ、その後は pd-ctl を使用して設定を変更できます。詳細は[PD Controlユーザーガイド](/pd-control.md)を参照してください。 ### TiDB モニタリングフレームワーク (Prometheus + Grafana) はスタンドアロンマシンにデプロイするべきでしょうか、それとも複数のマシンにデプロイするべきでしょうか? 推奨される CPU とメモリはどれくらいでしょうか? {#should-i-deploy-the-tidb-monitoring-framework-prometheus--grafana-on-a-standalone-machine-or-on-multiple-machines-what-is-the-recommended-cpu-and-memory} @@ -61,11 +61,11 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ TiDB `label`の設定は、クラスタのデプロイメントアーキテクチャに関連しています。これは重要であり、PDがグローバル管理とスケジューリングを実行するための基盤となります。以前のクラスタのデプロイメント時に`label`設定していない場合は、PD管理ツール`pd-ctl`を使用して`location-labels`情報を手動で追加し、デプロイメント構造を調整する必要があります（例： `config set location-labels "zone,rack,host"` ）。（実際の`label`レベル名に基づいて設定する必要があります）。 -`pd-ctl`の使い方については[PD Controlユーザー ガイド](/pd-control.md)を参照してください。 +`pd-ctl`の使い方については[PD Controlユーザーガイド](/pd-control.md)を参照してください。 ### ディスク テストの`dd`コマンドが`oflag=direct`オプションを使用するのはなぜですか? {#why-does-the-dd-command-for-the-disk-test-use-the-oflagdirect-option} -ダイレクト モードでは、書き込み要求を I/O コマンドにラップし、このコマンドをディスクに送信してファイル システム キャッシュをバイパスし、ディスクの実際の I/O 読み取り/書き込みパフォーマンスを直接テストします。 +ダイレクト モードでは、書き込み要求を I/O コマンドにラップし、このコマンドをディスクに送信してファイルシステム キャッシュをバイパスし、ディスクの実際の I/O 読み取り/書き込みパフォーマンスを直接テストします。 ### `fio`コマンドを使用して TiKV インスタンスのディスク パフォーマンスをテストするにはどうすればよいですか? {#how-to-use-the-fio-command-to-test-the-disk-performance-of-the-tikv-instance} @@ -83,7 +83,7 @@ TiDB `label`の設定は、クラスタのデプロイメントアーキテク ./fio -ioengine=psync -bs=32k -direct=1 -thread -rw=randrw -percentage_random=100,0 -time_based -size=10G -filename=fio_randread_write_test.txt -name='fio mixed randread and sequential write test' -iodepth=1 -runtime=60 -numjobs=4 -group_reporting --output-format=json --output=fio_randread_write_test.json ``` -## 現在 TiDB でサポートされているパブリック クラウド ベンダーは何ですか? {#what-public-cloud-vendors-are-currently-supported-by-tidb} +## 現在 TiDB でサポートされているパブリッククラウド ベンダーは何ですか? {#what-public-cloud-vendors-are-currently-supported-by-tidb} TiDB は[Google Cloud GKE](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-on-gcp-gke) 、 [AWS EKS](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-on-aws-eks) 、 [アリババクラウドACK](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-on-alibaba-cloud)でのデプロイメントをサポートします。 diff --git a/faq/high-availability-faq.md b/faq/high-availability-faq.md index 2df637a2cb337..0fb2a00ea9348 100644 --- a/faq/high-availability-faq.md +++ b/faq/high-availability-faq.md @@ -15,4 +15,4 @@ summary: TiDB の高可用性に関連する FAQ について説明します。 ## 地理的に分散した 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/high-reliability-faq.md b/faq/high-reliability-faq.md index e59101a4a9495..7612c2774fca3 100644 --- a/faq/high-reliability-faq.md +++ b/faq/high-reliability-faq.md @@ -38,6 +38,6 @@ MySQL と同様に、TiDB はユーザー ログイン認証とパスワード ## ユーザーのパスワードと権限を変更するにはどうすればよいですか? {#how-to-modify-the-user-password-and-privilege} -TiDB でユーザー パスワードを変更する場合は、他のノードのパスワードがタイムリーに更新されない可能性がある`UPDATE mysql.user`ではなく、 `ALTER USER` (たとえば、 `ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';` ) を使用することをお勧めします。 +TiDB でユーザーパスワードを変更する場合は、他のノードのパスワードがタイムリーに更新されない可能性がある`UPDATE mysql.user`ではなく、 `ALTER USER` (たとえば、 `ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';` ) を使用することをお勧めします。 ユーザーのパスワードと権限を変更する際は、公式の標準ステートメントを使用することをお勧めします。詳細については、 [TiDB ユーザーアカウント管理](/user-account-management.md)を参照してください。 diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index 73b453664d8d5..da4af53b67c67 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -29,7 +29,7 @@ TiKVデータは[`--data-dir`](/command-line-flags-for-tikv-configuration.md#--d ### TiDBのシステムテーブルとは何ですか？ {#what-are-the-system-tables-in-tidb} -MySQL と同様に、TiDB にはシステム テーブルも含まれており、サーバーの実行時に必要な情報を保存するために使用されます。 [TiDBシステムテーブル](/mysql-schema/mysql-schema.md)を参照してください。 +MySQL と同様に、TiDB にはシステムテーブルも含まれており、サーバーの実行時に必要な情報を保存するために使用されます。 [TiDBシステムテーブル](/mysql-schema/mysql-schema.md)を参照してください。 ### TiDB/PD/TiKVのログはどこにありますか？ {#where-are-the-tidb-pd-tikv-logs} @@ -239,7 +239,7 @@ TiDB が SQL ステートメントを実行する際、各オペレータが 10, ### TiDBでテーブルのサイズを推定するにはどうすればよいですか？ {#how-do-i-estimate-the-size-of-a-table-in-tidb} -TiDB のテーブルのサイズを推定するには、次のクエリ ステートメントを使用できます。 +TiDB のテーブルのサイズを推定するには、次のクエリステートメントを使用できます。 ```sql SELECT diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 60d3bf97de486..1f198717c0ebc 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -83,7 +83,7 @@ Db2 または Oracle から TiDB にすべてのデータを移行するか、 - OGG、Gateway、CDC (Change Data Capture) などの Oracle の公式移行ツールを使用します。 - データをインポートおよびエクスポートするためのプログラムを開発します。 -- スプールをテキスト ファイルとしてエクスポートし、Load infile を使用してデータをインポートします。 +- スプールをテキストファイルとしてエクスポートし、Load infile を使用してデータをインポートします。 - サードパーティのデータ移行ツールを使用します。 現在はOGGの使用が推奨されています。 @@ -154,9 +154,9 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do `DELETE` 、 `TRUNCATE` 、 `DROP`操作はいずれもデータを即時に解放しません。`TRUNCATE`と`DROP`操作では、TiDB GC（ガベージコレクション）時間（デフォルトでは10分）後にデータが削除され、領域が解放されます。`DELETE`操作では、データは削除されますが、TiDB GCに従って領域は解放されません。後続のデータがRocksDBに書き込まれ、 `COMPACT`が実行されると、領域は再利用されます。 -### データをロードするときに、ターゲット テーブルで DDL 操作を実行できますか? {#can-i-execute-ddl-operations-on-the-target-table-when-loading-data} +### データをロードするときに、ターゲットテーブルで DDL 操作を実行できますか? {#can-i-execute-ddl-operations-on-the-target-table-when-loading-data} -いいえ。データをロードするときに、ターゲット テーブルで DDL 操作を実行することはできません。そうしないと、データのロードに失敗します。 +いいえ。データをロードするときに、ターゲットテーブルで DDL 操作を実行することはできません。そうしないと、データのロードに失敗します。 ### TiDB は`replace into`構文をサポートしていますか? {#does-tidb-support-the-replace-into-syntax} diff --git a/faq/monitor-faq.md b/faq/monitor-faq.md index af4bf170db00d..d1511752f8c17 100644 --- a/faq/monitor-faq.md +++ b/faq/monitor-faq.md @@ -28,7 +28,7 @@ TiDB 2.0では、リージョンの健全性はPDメトリック監視ページ ## ステートメントカウントモニターの`selectsimplefull`の意味は何ですか? {#what-is-the-meaning-of-selectsimplefull-in-statement-count-monitor} -これは完全なテーブルスキャンを意味しますが、テーブルは小さなシステム テーブルである可能性があります。 +これは完全なテーブルスキャンを意味しますが、テーブルは小さなシステムテーブルである可能性があります。 ## モニターの`QPS`と`Statement OPS`の違いは何ですか? {#what-is-the-difference-between-qps-and-statement-ops-in-the-monitor} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index 495f76ac9c098..a7a0fea4b0964 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -28,7 +28,7 @@ summary: TiDB SQLに関連する FAQ について説明します。 TiDBにはコストベースのオプティマイザが搭載されています。ほとんどの場合、オプティマイザが最適なクエリプランを選択します。オプティマイザがうまく機能しない場合でも、 [オプティマイザヒント](/optimizer-hints.md)を使用してオプティマイザに介入することができます。 -さらに、 [SQLバインディング](/sql-plan-management.md#sql-binding)を使用して、特定の SQL ステートメントのクエリ プランを修正することもできます。 +さらに、 [SQLバインディング](/sql-plan-management.md#sql-binding)を使用して、特定の SQL ステートメントのクエリプランを修正することもできます。 ## 特定の SQL ステートメントの実行を防ぐにはどうすればよいでしょうか? {#how-to-prevent-the-execution-of-a-particular-sql-statement} @@ -140,7 +140,7 @@ TiDBのデフォルトの文字セットは`utf8mb4`です。文字列はmemcomp トランザクション内のステートメントの最大数は、デフォルトでは 5000 です。 -楽観的トランザクション モードでトランザクションの再試行が有効になっている場合、デフォルトの上限は 5000 です[`stmt-count-limit`](/tidb-configuration-file.md#stmt-count-limit)パラメータを使用して制限を調整できます。 +楽観的トランザクションモードでトランザクションの再試行が有効になっている場合、デフォルトの上限は 5000 です[`stmt-count-limit`](/tidb-configuration-file.md#stmt-count-limit)パラメータを使用して制限を調整できます。 ## TiDB で、後から挿入されたデータのAUTO_INCREMENT ID が、前に挿入されたデータのAUTO_INCREMENT ID よりも小さくなるのはなぜですか? {#why-does-the-auto-increment-id-of-the-later-inserted-data-is-smaller-than-that-of-the-earlier-inserted-data-in-tidb} @@ -223,7 +223,7 @@ TiDBは、 [グローバル](/system-variables.md#tidb_force_priority)単位ま REPLACE HIGH_PRIORITY | LOW_PRIORITY | DELAYED INTO table_name; ``` -2. フル テーブル スキャン ステートメントは、自動的に低い優先度に調整されます。 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 、デフォルトで低い優先度を持ちます。 +2. フルテーブルスキャン ステートメントは、自動的に低い優先度に調整されます。 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 、デフォルトで低い優先度を持ちます。 ## TiDB での`auto analyze`のトリガー戦略は何ですか? {#whats-the-trigger-strategy-for-auto-analyze-in-tidb} @@ -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} diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index e96f207cdb521..da238a4ab5767 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -29,11 +29,11 @@ TiDBクラスタは、TiDBサーバー、PD（Placement Driver）サーバー、 ### TiDB は MySQL に基づいていますか? {#is-tidb-based-on-mysql} -いいえ。TiDB は MySQL の構文とプロトコルをサポートしていますが、PingCAP, Inc. によって開発および保守されている新しいオープン ソース データベースです。 +いいえ。TiDB は MySQL の構文とプロトコルをサポートしていますが、PingCAP, Inc. によって開発および保守されている新しいオープン ソースデータベースです。 ### TiDB、TiKV、PD (Placement Driver) のそれぞれの責任は何ですか? {#what-is-the-respective-responsibility-of-tidb-tikv-and-pd-placement-driver} -- TiDB は SQL コンピューティングレイヤーとして機能し、主に SQL の解析、クエリ プランの指定、エグゼキュータの生成を担当します。 +- TiDB は SQL コンピューティングレイヤーとして機能し、主に SQL の解析、クエリプランの指定、エグゼキュータの生成を担当します。 - TiKVは分散型のキーバリューストレージエンジンとして動作し、実データの保存に使用されます。つまり、TiKVはTiDBのストレージエンジンです。 - PD は TiDB のクラスター マネージャーとして機能し、TiKV メタデータを管理し、タイムスタンプを割り当て、データの配置と負荷分散の決定を行います。 @@ -103,7 +103,7 @@ Usage of ./bin/tidb-server: Atomikosの2つのデータソースを設定したら、JDBCドライブをXAに設定します。AtomikosがTMおよびRM（DB）を操作する際、AtomikosはXAを含むコマンドをJDBCレイヤーに送信します。MySQLを例に挙げると、JDBCレイヤーでXAが有効になっている場合、JDBCはDMLを使用して`redo`ログを変更するなど、一連のXAロジック操作をInnoDBに送信します。これは2相コミットの動作です。現在のTiDBバージョンは、上位アプリケーションレイヤーのJTA/XAをサポートしておらず、Atomikosから送信されたXA操作を解析しません。 -スタンドアロン データベースとして、MySQL は XA を使用したデータベース間トランザクションのみを実装できます。一方、TiDB は Google Percolator トランザクション モデルを使用した分散トランザクションをサポートし、パフォーマンスの安定性は XA よりも高いため、TiDB は JTA/XA をサポートしておらず、TiDB が XA をサポートする必要もありません。 +スタンドアロン データベースとして、MySQL は XA を使用したデータベース間トランザクションのみを実装できます。一方、TiDB は Google Percolator トランザクションモデルを使用した分散トランザクションをサポートし、パフォーマンスの安定性は XA よりも高いため、TiDB は JTA/XA をサポートしておらず、TiDB が XA をサポートする必要もありません。 ### TiDB は、パフォーマンスを損なうことなく、列指向ストレージエンジン (TiFlash) への大量の同時`INSERT`または`UPDATE`操作をどのようにサポートできるでしょうか? {#how-could-tidb-support-high-concurrent-insert-or-update-operations-to-the-columnar-storage-engine-tiflash-without-hurting-performance} diff --git a/filter-binlog-event.md b/filter-binlog-event.md index 744735c3b21df..6cdbcd2b5fd2e 100644 --- a/filter-binlog-event.md +++ b/filter-binlog-event.md @@ -14,7 +14,7 @@ summary: データを移行するときにbinlogイベントをフィルター ## コンフィグレーション {#configuration} -binlogイベント フィルターを使用するには、以下に示すように、DM のタスク構成ファイルに`filter`を追加します。 +binlogイベントフィルターを使用するには、以下に示すように、DM のタスク構成ファイルに`filter`を追加します。 ```yaml filters: @@ -69,7 +69,7 @@ filters: ## アプリケーションシナリオ {#application-scenarios} -このセクションでは、 binlogイベント フィルターの適用シナリオについて説明します。 +このセクションでは、 binlogイベントフィルターの適用シナリオについて説明します。 ### すべてのシャーディング削除操作を除外する {#filter-out-all-sharding-deletion-operations} diff --git a/filter-dml-event.md b/filter-dml-event.md index 9fff717d62f26..be7968dc2dc2b 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -35,7 +35,7 @@ expression-filter: 上記の設定例では、ルール`even_c`が設定され、データソース`mysql-replica-01`によって参照されています。このルールによれば、スキーマ`expr_filter`のテーブル`tb1`において、列`c` （ `c % 2 = 0` ）に偶数が挿入された場合、この文`insert`は下流に複製されません。次の例は、このルールの効果を示しています。 -次のデータをアップストリーム データ ソースに増分挿入します。 +次のデータをアップストリームデータソースに増分挿入します。 ```sql INSERT INTO tbl(id, c) VALUES (1, 1), (2, 2), (3, 3), (4, 4); diff --git a/follower-read.md b/follower-read.md index 5b437b4e4e8c4..07ac13e768853 100644 --- a/follower-read.md +++ b/follower-read.md @@ -67,7 +67,7 @@ set [session | global] tidb_replica_read = ''; より正確な読み取りレプリカ選択ポリシーを使用する場合は、次のように使用可能な構成の完全なリストを参照してください。 -- 値を`tidb_replica_read` ～ `leader`または空の文字列に設定すると、TiDB はデフォルトの動作を維持し、すべての読み取り操作をリーダー レプリカに送信して実行します。 +- 値を`tidb_replica_read` ～ `leader`または空の文字列に設定すると、TiDB はデフォルトの動作を維持し、すべての読み取り操作をリーダーレプリカに送信して実行します。 - `tidb_replica_read`を`follower`に設定すると、TiDB は読み取り操作を実行するためにリージョンのフォロワーレプリカを選択します。リージョンにラーナーレプリカがある場合、TiDB は同じ優先度で読み取り操作の対象としてそれらも考慮します。現在のリージョンに利用可能なフォロワーレプリカまたはラーナーレプリカが存在しない場合、TiDB はリーダーレプリカから読み取ります。 @@ -79,8 +79,8 @@ 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_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 は利用可能なリーダーレプリカまたはフォロワーレプリカからデータを読み取ります。 @@ -123,12 +123,12 @@ Follower Read機能は、TiDBのスナップショット分離トランザクシ #### `leader` {#leader} -- 場所に関係なく、読み取りには常にリーダー レプリカを選択します。 +- 場所に関係なく、読み取りには常にリーダーレプリカを選択します。 #### `closest-replicas` {#closest-replicas} -- TiDB と同じ AZ 内のレプリカがリーダー ノードである場合、TiDB はそこからFollower Read を実行しません。 -- TiDB と同じ AZ にあるレプリカがフォロワー ノードの場合、TiDB はそこからFollower Read を実行します。 +- TiDB と同じ AZ 内のレプリカがリーダーノードである場合、TiDB はそこからFollower Read を実行しません。 +- TiDB と同じ AZ にあるレプリカがフォロワーノードの場合、TiDB はそこからFollower Read を実行します。 #### `closest-adaptive` {#closest-adaptive} diff --git a/foreign-key.md b/foreign-key.md index 4d05a860a38aa..c7042cb710d81 100644 --- a/foreign-key.md +++ b/foreign-key.md @@ -314,7 +314,7 @@ Create Table | CREATE TABLE `child` ( - [DM](/dm/dm-overview.md) : v8.5.6以降、DMは実験的機能として外部キー制約を使用するテーブルのレプリケーションをサポートしています。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)を参照してください。 v8.5.6より前のバージョンでは、DMはTiDBへのデータレプリケーション時に[`foreign_key_checks`](/system-variables.md#foreign_key_checks)システム変数を無効にするため、カスケード操作はダウンストリームクラスタにレプリケートされません。 - [TiCDC](/ticdc/ticdc-overview.md) v6.6.0 は外部キーに対応しています。以前のバージョンの TiCDC では、外部キーを持つテーブルをレプリケートする際にエラーが発生する場合があります。TiCDC バージョン 6.6.0 より前のバージョンを使用する場合は、ダウンストリーム TiDB クラスタの`foreign_key_checks`を無効にすることをお勧めします。 - [BR](/br/backup-and-restore-overview.md) v6.6.0 は外部キーに対応しています。以前のバージョンのBRでは、外部キーを持つテーブルを v6.6.0 以降のクラスタに復元する際にエラーが発生する場合があります。v6.6.0 より前のバージョンのBRを使用する場合は、クラスタを復元する前に、ダウンストリーム TiDB クラスタの`foreign_key_checks`無効にすることをお勧めします。 -- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用する場合、対象テーブルで外部キーが使用されている場合は、データのインポート前にダウンストリーム TiDB クラスタの`foreign_key_checks`を無効にすることをお勧めします。v6.6.0 より前のバージョンでは、このシステム変数を無効にしても効果がなく、ダウンストリーム データベース ユーザーに`REFERENCES`権限を付与するか、ダウンストリーム データベースに対象テーブルを事前に手動で作成して、スムーズなデータインポートを確保する必要があります。 +- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用する場合、対象テーブルで外部キーが使用されている場合は、データのインポート前にダウンストリーム TiDB クラスタの`foreign_key_checks`を無効にすることをお勧めします。v6.6.0 より前のバージョンでは、このシステム変数を無効にしても効果がなく、ダウンストリームデータベースユーザーに`REFERENCES`権限を付与するか、ダウンストリームデータベースに対象テーブルを事前に手動で作成して、スムーズなデータインポートを確保する必要があります。 @@ -322,7 +322,7 @@ Create Table | CREATE TABLE `child` ( -- [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用してアップストリーム データベースとダウンストリーム データベースの間でデータを比較するときに、データベースのバージョンが異なり、[下流のTiDBに無効な外部キーがあります](#compatibility-between-tidb-versions)がある場合、sync-diff-inspector はテーブル スキーマの不整合エラーを報告することがあります。これは、TiDB v6.6.0 が無効な外部キーに対する`/* FOREIGN KEY INVALID */`コメントを追加しているためです。 +- [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用してアップストリーム データベースとダウンストリームデータベースの間でデータを比較するときに、データベースのバージョンが異なり、[下流のTiDBに無効な外部キーがあります](#compatibility-between-tidb-versions)がある場合、sync-diff-inspector はテーブルスキーマの不整合エラーを報告することがあります。これは、TiDB v6.6.0 が無効な外部キーに対する`/* FOREIGN KEY INVALID */`コメントを追加しているためです。 diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index 55b150e1b2c2a..aad15eb1cb9da 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -130,7 +130,7 @@ SELECT CURRENT_USER(); ### DATABASE() {#database} -`DATABASE()`関数は、現在のセッションで使用されているデータベース スキーマを返します。 +`DATABASE()`関数は、現在のセッションで使用されているデータベーススキーマを返します。 ```sql SELECT DATABASE(); @@ -313,7 +313,7 @@ Store: tikv | 名前 | 説明 | | :---------------------------------------------------------------------------------------------- | :---------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](/functions-and-operators/tidb-functions.md#current_resource_group) | 現在のセッションがバインドされているリソース グループの名前を返します | +| [`CURRENT_RESOURCE_GROUP()`](/functions-and-operators/tidb-functions.md#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します | ## サポートされていない関数 {#unsupported-functions} diff --git a/functions-and-operators/operators.md b/functions-and-operators/operators.md index 161ff29db8ecf..727eaeb5e3f66 100644 --- a/functions-and-operators/operators.md +++ b/functions-and-operators/operators.md @@ -40,7 +40,7 @@ summary: 演算子の優先順位、比較関数と演算子、論理演算子 | [<](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_less-than) | 小なり演算子 | | [<=](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_less-than-or-equal) | 以下演算子 | | [LIKE](https://dev.mysql.com/doc/refman/8.0/en/string-comparison-functions.html#operator_like) | シンプルなパターンマッチング | -| [LIKE](https://www.postgresql.org/docs/current/functions-matching.html) | 大文字と小文字を区別しない単純なパターン マッチング (TiDB ではサポートされていますが、MySQL ではサポートされていません) | +| [LIKE](https://www.postgresql.org/docs/current/functions-matching.html) | 大文字と小文字を区別しない単純なパターンマッチング (TiDB ではサポートされていますが、MySQL ではサポートされていません) | | [-](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_minus) | マイナス演算子 | | [%、MOD](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_mod) | モジュロ演算子 | | [NOT](https://dev.mysql.com/doc/refman/8.0/en/logical-operators.html#operator_not) | 値を否定する | @@ -109,7 +109,7 @@ OR, || | [<](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_less-than) | 小なり演算子 | | [<=](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_less-than-or-equal) | 以下演算子 | | [LIKE](https://dev.mysql.com/doc/refman/8.0/en/string-comparison-functions.html#operator_like) | シンプルなパターンマッチング | -| [LIKE](https://www.postgresql.org/docs/current/functions-matching.html) | 大文字と小文字を区別しない単純なパターン マッチング (TiDB ではサポートされていますが、MySQL ではサポートされていません) | +| [LIKE](https://www.postgresql.org/docs/current/functions-matching.html) | 大文字と小文字を区別しない単純なパターンマッチング (TiDB ではサポートされていますが、MySQL ではサポートされていません) | | [NOT BETWEEN](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_not-between) | 値が範囲内にないか確認する | | [!=, `<>`](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_not-equal) | 等しくない演算子 | | [NOT IN()](https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_not-in) | 値が値セット内にないかどうかを確認します | diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md index ea08bee64d960..ecff33ec92311 100644 --- a/functions-and-operators/precision-math.md +++ b/functions-and-operators/precision-math.md @@ -50,7 +50,7 @@ DECIMAL列には、先頭の`+`文字、 `-`文字、または先頭の`0`桁は DECIMAL列では、列定義で指定された範囲を超える値は許可されません。例えば、 `DECIMAL(3,0)`列は`-999`から`999`までの範囲をサポートします。`DECIMAL(M,D)`列では、小数点の左側に最大`M - D`桁までしか許可されません。 -DECIMAL 値の内部形式の詳細については、TiDB ソース コードの[`mydecimal.go`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/types/mydecimal.go)を参照してください。 +DECIMAL 値の内部形式の詳細については、TiDB ソースコードの[`mydecimal.go`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/types/mydecimal.go)を参照してください。 ## 式の処理 {#expression-handling} diff --git a/functions-and-operators/string-functions.md b/functions-and-operators/string-functions.md index 7250ffdc7f6a1..a93a179be853e 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -1488,7 +1488,7 @@ SELECT MID('abcdef',2); ### `NOT LIKE` {#not-like} -単純なパターン マッチングの否定。 +単純なパターンマッチングの否定。 この関数は[`LIKE`](#like)の逆演算を実行します。 @@ -1662,7 +1662,7 @@ SELECT QUOTE(0x002774657374); ### `REGEXP` {#regexp} -正規表現を使用したパターン マッチング。 +正規表現を使用したパターンマッチング。 例: diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 6615987c86231..288c8409e74af 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -18,7 +18,7 @@ summary: TiDB 固有の関数の使用法について学習します。 | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | | [`TIDB_DECODE_PLAN()`](#tidb_decode_plan) | TiDB 実行計画をデコードします。 | | [`TIDB_DECODE_SQL_DIGESTS()`](#tidb_decode_sql_digests) | クラスター内の一連の SQL ダイジェストに対応する正規化された SQL ステートメント (形式と引数のない形式) を照会します。 | -| [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key) | インデックス キーをエンコードします。 | +| [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key) | インデックスキーをエンコードします。 | | [`TIDB_ENCODE_RECORD_KEY()`](#tidb_encode_record_key) | レコード キーをエンコードします。 | | [`TIDB_ENCODE_SQL_DIGEST()`](#tidb_encode_sql_digest) | クエリ文字列のダイジェストを取得します。 | | [`TIDB_IS_DDL_OWNER()`](#tidb_is_ddl_owner) | 接続しているTiDBインスタンスがDDLオーナーであるかどうかを確認します。DDLオーナーとは、クラスター内の他のすべてのノードに代わってDDLステートメントを実行する役割を担うTiDBインスタンスです。 | @@ -43,7 +43,7 @@ summary: TiDB 固有の関数の使用法について学習します。 | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | | [`TIDB_DECODE_PLAN()`](#tidb_decode_plan) | TiDB 実行計画をデコードします。 | | [`TIDB_DECODE_SQL_DIGESTS()`](#tidb_decode_sql_digests) | クラスター内の一連の SQL ダイジェストに対応する正規化された SQL ステートメント (形式と引数のない形式) を照会します。 | -| [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key) | インデックス キーをエンコードします。 | +| [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key) | インデックスキーをエンコードします。 | | [`TIDB_ENCODE_RECORD_KEY()`](#tidb_encode_record_key) | レコード キーをエンコードします。 | | [`TIDB_ENCODE_SQL_DIGEST()`](#tidb_encode_sql_digest) | クエリ文字列のダイジェストを取得します。 | | [`TIDB_IS_DDL_OWNER()`](#tidb_is_ddl_owner) | 接続しているTiDBインスタンスがDDLオーナーであるかどうかを確認します。DDLオーナーとは、クラスター内の他のすべてのノードに代わってDDLステートメントを実行する役割を担うTiDBインスタンスです。 | @@ -65,7 +65,7 @@ summary: TiDB 固有の関数の使用法について学習します。 例: -ユーザー`user1`を作成し、リソース グループ`rg1`と`rg2` 2 つのリソース グループを作成し、ユーザー`user1`リソース グループ`rg1`にバインドします。 +ユーザー`user1`を作成し、リソースグループ`rg1`と`rg2` 2 つのリソースグループを作成し、ユーザー`user1`リソースグループ`rg1`にバインドします。 ```sql CREATE USER 'user1'; @@ -74,7 +74,7 @@ CREATE RESOURCE GROUP rg2 RU_PER_SEC = 2000; ALTER USER 'user1' RESOURCE GROUP `rg1`; ``` -`user1`を使用してログインし、現在のユーザーにバインドされているリソース グループを表示します。 +`user1`を使用してログインし、現在のユーザーにバインドされているリソースグループを表示します。 ```sql SELECT CURRENT_RESOURCE_GROUP(); @@ -89,7 +89,7 @@ SELECT CURRENT_RESOURCE_GROUP(); 1 row in set (0.00 sec) ``` -`SET RESOURCE GROUP`を実行して、現在のセッションのリソース グループを`rg2`に設定し、現在のユーザーにバインドされているリソース グループを表示します。 +`SET RESOURCE GROUP`を実行して、現在のセッションのリソースグループを`rg2`に設定し、現在のユーザーにバインドされているリソースグループを表示します。 ```sql SET RESOURCE GROUP `rg2`; @@ -497,7 +497,7 @@ SELECT *, TIDB_ROW_CHECKSUM() FROM t WHERE id = 1; - シナリオ: - - 一意のセカンダリ インデックス上のキーが単調に増加または減少することによって書き込みホットスポットが発生し、インデックスに整数型のフィールドが含まれています。 + - 一意のセカンダリインデックス上のキーが単調に増加または減少することによって書き込みホットスポットが発生し、インデックスに整数型のフィールドが含まれています。 - このSQL文は、セカンダリインデックスの全フィールドに基づいて等価性クエリを実行します。これは、 `SELECT`独立したクエリとして、または`UPDATE` 、 `DELETE`などによって生成された内部クエリとして実行されます。等価性クエリには、 `a = 1`または`a IN (1, 2, ......)` 2つの方法があります。 - 制限事項: @@ -601,7 +601,7 @@ TIDB_ENCODE_INDEX_KEY(, , , ..., - 主キーが`CLUSTERED`で、単一列の整数の場合、ハンドル値は主キー列の値になります。 - 主キーが`CLUSTERED`で、複合主キーまたは非整数型 (共通ハンドル) の場合、ハンドル値はすべての主キー列の値を順番に含んだものになります。 -次の例は、異なる主キー タイプで複合セカンダリ インデックス`idx(c1, c2)`に対してこの関数を呼び出す方法を示しています。 +次の例は、異なる主キー タイプで複合セカンダリインデックス`idx(c1, c2)`に対してこの関数を呼び出す方法を示しています。 ```sql -- For tables without a primary key or with a NONCLUSTERED primary key, use the _tidb_rowid column. @@ -662,7 +662,7 @@ TIDB_ENCODE_RECORD_KEY(, , ...) パラメータの説明: -- `` : ターゲット テーブルを含むデータベースの名前。 +- `` : ターゲットテーブルを含むデータベースの名前。 - `` : 対象テーブルの名前。パーティションテーブルの場合は、 ``にパーティション名を指定できます（例： `'t(p0)'` ）。 - `...` : 対応する行のハンドル（行キー）値。ハンドルの正確な構成は、テーブルの主キーの種類（例えば、主キーが`CLUSTERED` （共通ハンドル）であるか、非表示列`_tidb_rowid`を使用しているかなど）によって異なります。詳細については、 [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key)の`...`の説明を参照してください。 diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index 96e108a3428d5..4c800184c9f88 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -12,7 +12,7 @@ summary: GC 構成パラメータについて学習します。 - [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) : 各 GC でデータが保持される時間制限を指定します。 - [`tidb_gc_concurrency`](/system-variables.md#tidb_gc_concurrency-new-in-v50) : GC の[ロックを解決する](/garbage-collection-overview.md#resolve-locks)のステップのスレッド数を指定します。 - [`tidb_gc_scan_lock_mode`](/system-variables.md#tidb_gc_scan_lock_mode-new-in-v50) : GC のロック解決ステップでロックをスキャンする方法を指定します。 -- [`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) : アクティブなトランザクションが GC セーフ ポイントをブロックする最大時間を指定します。 +- [`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) : アクティブなトランザクションが GC セーフポイントをブロックする最大時間を指定します。 システム変数の値を変更する方法の詳細については、 [システム変数](/system-variables.md)を参照してください。 diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index f217d3444b0f2..f98aedf9868ba 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -1,6 +1,6 @@ --- title: GC Overview -summary: TiDB のガベージ コレクションについて学習します。 +summary: TiDB のガベージコレクションについて学習します。 --- # GCの概要 {#gc-overview} @@ -13,7 +13,7 @@ TiDBはMVCCを使用してトランザクションの同時実行を制御しま TiDBでは、GCが定期的に実行されます。GCごとに、TiDBはまず「セーフポイント」と呼ばれるタイムスタンプを計算します。次に、セーフポイント以降のすべてのスナップショットがデータの整合性を保持しているという前提で、TiDBは古いデータをクリアします。具体的には、各GCプロセスには以下の3つのステップが含まれます。 -1. ロックを解決します。このステップでは、TiDB はすべてのリージョンのセーフ ポイントの前のロックをスキャンし、これらのロックをクリアします。 +1. ロックを解決します。このステップでは、TiDB はすべてのリージョンのセーフポイントの前のロックをスキャンし、これらのロックをクリアします。 2. 範囲を削除します。このステップでは、 `DROP TABLE` / `DROP INDEX`操作で生成された範囲全体の古いデータがすぐにクリアされます。 3. GC を実行します。このステップでは、各 TiKV ノードがそのデータ全体をスキャンし、各キーの不要な古いバージョンを削除します。 diff --git a/generate-self-signed-certificates.md b/generate-self-signed-certificates.md index 6068e5349beb5..430b9a22d0326 100644 --- a/generate-self-signed-certificates.md +++ b/generate-self-signed-certificates.md @@ -87,7 +87,7 @@ TiKV インスタンスに証明書を発行するには、次の手順を実行 cp /usr/lib/ssl/openssl.cnf . ``` - 実際の場所がわからない場合は、ルート ディレクトリで探します。 + 実際の場所がわからない場合は、ルートディレクトリで探します。 ```bash find / -name openssl.cnf diff --git a/geo-distributed-deployment-topology.md b/geo-distributed-deployment-topology.md index 7ced30c0a5f8b..3bab919bec48f 100644 --- a/geo-distributed-deployment-topology.md +++ b/geo-distributed-deployment-topology.md @@ -24,7 +24,7 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 - [地理的に分散したトポロジテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} @@ -100,4 +100,4 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 > **Note:** > > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、コントロールマシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/global-indexes.md b/global-indexes.md index 24c7c76107ea1..c7b1890ddd5c9 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -1,6 +1,6 @@ --- title: Global Indexes -summary: TiDB グローバル インデックスの使用例、利点、使用方法、動作原理、制限について学習します。 +summary: TiDB グローバルインデックスの使用例、利点、使用方法、動作原理、制限について学習します。 --- # グローバルインデックス {#global-indexes} @@ -11,13 +11,13 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 ## 利点 {#advantages} -グローバル インデックスを使用すると、クエリのパフォーマンスが大幅に向上し、インデックスの柔軟性が高まり、データの移行とアプリケーションの変更にかかるコストが削減されます。 +グローバルインデックスを使用すると、クエリのパフォーマンスが大幅に向上し、インデックスの柔軟性が高まり、データの移行とアプリケーションの変更にかかるコストが削減されます。 ### クエリパフォーマンスの向上 {#improved-query-performance} グローバルインデックスは、非パーティション列へのクエリの効率を効果的に向上させます。クエリに非パーティション列が含まれる場合、グローバルインデックスは関連データを迅速に特定できるため、すべてのパーティションにわたるフルテーブルスキャンを回避できます。これにより、コプロセッサー（COP）タスクの数が大幅に削減され、特にパーティション数が多いシナリオで大きな効果を発揮します。 -ベンチマーク テストでは、テーブルに 100 個のパーティションが含まれている場合、sysbench `select_random_points`シナリオでのパフォーマンスが最大 53 倍向上することが示されています。 +ベンチマークテストでは、テーブルに 100 個のパーティションが含まれている場合、sysbench `select_random_points`シナリオでのパフォーマンスが最大 53 倍向上することが示されています。 ### 強化されたインデックスの柔軟性 {#enhanced-indexing-flexibility} @@ -31,12 +31,12 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 ## グローバルインデックスの制限 {#limitations-of-global-indexes} -- インデックス定義で`GLOBAL`キーワードが明示的に指定されていない場合、TiDB はデフォルトでローカル インデックスを作成します。 +- インデックス定義で`GLOBAL`キーワードが明示的に指定されていない場合、TiDB はデフォルトでローカルインデックスを作成します。 - キーワード`GLOBAL`と`LOCAL`はパーティションテーブルにのみ適用され、非パーティションテーブルには影響しません。つまり、非パーティションテーブルでは、グローバルインデックスとローカルインデックスに違いはありません。 - `DROP PARTITION` `REORGANIZE PARTITION`の DDL 操作も、グローバルインデックスの更新をトリガーします。これらの DDL 操作は`TRUNCATE PARTITION`結果を返す前にグローバルインデックスの更新が完了するのを待つ必要があるため、実行時間が長くなります。これは、 `DROP PARTITION`や`TRUNCATE PARTITION`などのデータアーカイブのシナリオで特に顕著です。グローバルインデックスがない場合、これらの操作は通常すぐに完了します。しかし、グローバルインデックスがある場合、更新が必要なインデックスの数が増えるにつれて実行時間が長くなります。 -- グローバル インデックスを含むテーブルは`EXCHANGE PARTITION`操作をサポートしません。 +- グローバルインデックスを含むテーブルは`EXCHANGE PARTITION`操作をサポートしません。 - デフォルトでは、パーティションテーブルの主キーはクラスター化インデックスであり、パーティションキーを含める必要があります。主キーからパーティションキーを除外する必要がある場合は、テーブル作成時に主キーを非クラスター化グローバルインデックスとして明示的に指定できます（例： `PRIMARY KEY(col1, col2) NONCLUSTERED GLOBAL` ）。 -- 式列にグローバル インデックスが追加された場合、またはグローバル インデックスがプレフィックス インデックスでもある場合 (たとえば`UNIQUE KEY idx_id_prefix (id(10)) GLOBAL` )、このグローバル インデックスの統計を手動で収集する必要があります。 +- 式列にグローバルインデックスが追加された場合、またはグローバルインデックスがプレフィックスインデックスでもある場合 (たとえば`UNIQUE KEY idx_id_prefix (id(10)) GLOBAL` )、このグローバルインデックスの統計を手動で収集する必要があります。 ## 機能の進化 {#feature-evolution} @@ -44,29 +44,29 @@ summary: TiDB グローバル インデックスの使用例、利点、使用 - **v7.6.0** : グローバルインデックスを有効にするシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)が導入されました。ただし、この機能は現時点ではまだ開発中であり、本番での使用は推奨されません。 - **v8.3.0** : グローバルインデックスが実験的機能としてリリースされました。インデックスを定義する際に`GLOBAL`キーワードを使用することで、明示的にグローバルインデックスを作成できます。 - **v8.4.0** : グローバルインデックス機能が一般提供（GA）されました。システム変数`tidb_enable_global_index`を設定せずに、キーワード`GLOBAL`を使って直接グローバルインデックスを作成できます。このバージョン以降、システム変数は非推奨となり、値は`ON`に固定されます。つまり、グローバルインデックスはデフォルトで有効になります。 -- **v8.5.0** : グローバル インデックスは、パーティション式のすべての列を含めることをサポートします。 +- **v8.5.0** : グローバルインデックスは、パーティション式のすべての列を含めることをサポートします。 ## グローバルインデックスとローカルインデックス {#global-indexes-vs-local-indexes} -次の図は、グローバル インデックスとローカル インデックスの違いを示しています。 +次の図は、グローバルインデックスとローカルインデックスの違いを示しています。 ![Global Index vs. Local Index](/media/global-index-vs-local-index.png) **グローバルインデックスのシナリオ**: - **頻度の低いデータアーカイブ**：例えば、医療業界では、一部のビジネスデータは最大30年間保持する必要があります。このようなデータは月ごとにパーティション分割されることが多く、一度に360個のパーティションが作成され、その後`DROP` ～ `TRUNCATE`操作が発生することは非常にまれです。このようなシナリオでは、パーティション間の一貫性とクエリパフォーマンスの向上を実現するグローバルインデックスの方が適しています。 -- **複数のパーティションにまたがるクエリ**: クエリが複数のパーティションにわたるデータにアクセスする必要がある場合、グローバル インデックスを使用すると、すべてのパーティションにわたるフル スキャンを回避し、クエリの効率を高めることができます。 +- **複数のパーティションにまたがるクエリ**: クエリが複数のパーティションにわたるデータにアクセスする必要がある場合、グローバルインデックスを使用すると、すべてのパーティションにわたるフルスキャンを回避し、クエリの効率を高めることができます。 **ローカルインデックスのシナリオ**: -- **頻繁なデータ アーカイブ**: データ アーカイブ操作が頻繁に発生し、ほとんどのクエリが単一のパーティションに制限されている場合は、ローカル インデックスの方がパフォーマンスが向上します。 +- **頻繁なデータ アーカイブ**: データ アーカイブ操作が頻繁に発生し、ほとんどのクエリが単一のパーティションに制限されている場合は、ローカルインデックスの方がパフォーマンスが向上します。 - **パーティション交換の使用**：銀行などの業界では、処理済みのデータをまず通常のテーブルに書き込み、検証後にパーティションテーブルに交換することで、パーティションテーブルへのパフォーマンスへの影響を最小限に抑える場合があります。この場合、グローバルインデックスを使用するとパーティションテーブルはパーティション交換をサポートしなくなるため、ローカルインデックスが推奨されます。 ## グローバルインデックスとクラスター化インデックス {#global-indexes-vs-clustered-indexes} クラスター化インデックスとグローバルインデックスの根本的な制約により、1つのインデックスをクラスター化インデックスとグローバルインデックスの両方の機能を同時に使用することはできません。ただし、それぞれのインデックスは、クエリシナリオに応じて異なるパフォーマンス上のメリットをもたらします。両方のメリットを活用する必要がある場合は、パーティション列をクラスター化インデックスに含め、パーティション列を含まない別のグローバルインデックスを作成することができます。 -次のようなテーブル スキーマがあるとします。 +次のようなテーブルスキーマがあるとします。 ```sql CREATE TABLE `t` ( @@ -82,7 +82,7 @@ PARTITION BY RANGE (UNIX_TIMESTAMP(`ts`)) 前述のテーブル`t`では、列`id`に一意の値が含まれています。ポイントクエリと範囲クエリの両方を最適化するには、テーブル作成ステートメントでクラスター化インデックス`PRIMARY KEY(id, ts)`と、パーティション列を含まないグローバルインデックス`UNIQUE KEY id(id)`を定義します。これにより、 `id`に基づくポイントクエリはグローバルインデックス`id`を使用し、実行計画`PointGet`を選択します。範囲クエリではクラスター化インデックスが使用されます。これは、クラスター化インデックスはグローバルインデックスと比較して追加のテーブル参照を回避し、クエリ効率を向上させるためです。 -変更されたテーブル スキーマは次のとおりです。 +変更されたテーブルスキーマは次のとおりです。 ```sql CREATE TABLE `t` ( @@ -102,7 +102,7 @@ PARTITION BY RANGE (UNIX_TIMESTAMP(`ts`)) ## 使用法 {#usage} -グローバル インデックスを作成するには、インデックス定義に`GLOBAL`キーワードを追加します。 +グローバルインデックスを作成するには、インデックス定義に`GLOBAL`キーワードを追加します。 > **Note:** > @@ -122,7 +122,7 @@ PARTITION BY HASH(col3) PARTITIONS 4; ``` -前の例では、一意インデックス`uidx12`と一意でないインデックス`idx1`はグローバル インデックスになりますが、 `uidx3`通常の一意インデックスのままです。 +前の例では、一意インデックス`uidx12`と一意でないインデックス`idx1`はグローバルインデックスになりますが、 `uidx3`通常の一意インデックスのままです。 クラスター化インデックスはグローバルインデックスにはなり得ないことに注意してください。例: @@ -144,7 +144,7 @@ ERROR 1503 (HY000): A CLUSTERED INDEX must include all columns in the table's pa PRIMARY KEY(col1, col2) NONCLUSTERED GLOBAL ``` -[`SHOW CREATE TABLE`](/sql-statements/sql-statement-show-create-table.md)の出力で`GLOBAL`インデックス オプションをチェックすることで、グローバル インデックスを識別できます。 +[`SHOW CREATE TABLE`](/sql-statements/sql-statement-show-create-table.md)の出力で`GLOBAL`インデックスオプションをチェックすることで、グローバルインデックスを識別できます。 ```sql SHOW CREATE TABLE t1\G @@ -165,7 +165,7 @@ PARTITION BY HASH (`col3`) PARTITIONS 4 1 row in set (0.00 sec) ``` -あるいは、 [`INFORMATION_SCHEMA.TIDB_INDEXES`](/information-schema/information-schema-tidb-indexes.md)テーブルをクエリし、出力の`IS_GLOBAL`列をチェックしてグローバル インデックスを識別することもできます。 +あるいは、 [`INFORMATION_SCHEMA.TIDB_INDEXES`](/information-schema/information-schema-tidb-indexes.md)テーブルをクエリし、出力の`IS_GLOBAL`列をチェックしてグローバルインデックスを識別することもできます。 ```sql SELECT * FROM information_schema.tidb_indexes WHERE table_name='t1'; @@ -183,7 +183,7 @@ SELECT * FROM information_schema.tidb_indexes WHERE table_name='t1'; 3 rows in set (0.00 sec) ``` -通常のテーブルをパーティション分割する場合、またはパーティションテーブルを再パーティションする場合、必要に応じてインデックスをグローバル インデックスまたはローカル インデックスに更新できます。 +通常のテーブルをパーティション分割する場合、またはパーティションテーブルを再パーティションする場合、必要に応じてインデックスをグローバルインデックスまたはローカルインデックスに更新できます。 例えば、次のSQL文は、列`col1`に基づいて表`t1`再パーティション化し、グローバルインデックス`uidx12`と`idx1`ローカルインデックスに更新し、ローカルインデックス`uidx3`グローバルインデックスに更新します。列`uidx3`は列`col3`の一意インデックスです。すべてのパーティションにわたって列`col3`の一意性を確保するには、列`uidx3`グローバルインデックスにする必要があります。列`uidx12`と`idx1`は列`col1`のインデックスであり、グローバルインデックスまたはローカルインデックスのどちらでも構いません。 @@ -193,7 +193,7 @@ ALTER TABLE t1 PARTITION BY HASH (col1) PARTITIONS 3 UPDATE INDEXES (uidx12 LOCA ## 動作メカニズム {#working-mechanism} -このセクションでは、グローバル インデックスの設計原則と実装を含む、グローバル インデックスの動作メカニズムについて説明します。 +このセクションでは、グローバルインデックスの設計原則と実装を含む、グローバルインデックスの動作メカニズムについて説明します。 ### 設計原則 {#design-principles} @@ -213,7 +213,7 @@ CREATE TABLE `sbtest` ( `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) @@ -275,9 +275,9 @@ Value: ## パフォーマンステスト結果 {#performance-test-results} -次のテストは、sysbench の`select_random_points`シナリオに基づいており、主にさまざまなパーティション戦略とインデックス作成方法でのクエリ パフォーマンスを比較するために使用されます。 +次のテストは、sysbench の`select_random_points`シナリオに基づいており、主にさまざまなパーティション戦略とインデックス作成方法でのクエリパフォーマンスを比較するために使用されます。 -テストで使用されるテーブル スキーマは次のとおりです。 +テストで使用されるテーブルスキーマは次のとおりです。 ```sql CREATE TABLE `sbtest` ( @@ -307,7 +307,7 @@ WHERE k IN (xx, xx, xx) | ----------------------------------------------- | ----- | -------- | -------- | ------ | | クラスター化された非パーティションテーブル | 225 | 19,999 | 30,293 | 7.92 | | PK でパーティション化されたクラスター化テーブル範囲 | 68 | 480 | 511 | 114.87 | -| PK によって範囲分割されたクラスター化テーブル、 `k` `c`グローバル インデックスあり | 207 | 17,798 | 27,707 | 11.73 | +| PK によって範囲分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 207 | 17,798 | 27,707 | 11.73 | ハッシュパーティション（100パーティション）: diff --git a/glossary.md b/glossary.md index 611894e9674d9..a59ba3687957e 100644 --- a/glossary.md +++ b/glossary.md @@ -117,7 +117,7 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### 分散実行フレームワーク（DXF） {#distributed-execution-framework-dxf} -分散実行フレームワーク (DXF) は、TiDB が特定のタスク (インデックスの作成やデータのインポートなど) を一元的にスケジュールし、分散的に実行するために使用するフレームワークです。DXF は、リソースの使用を制御し、コア業務トランザクションへの影響を軽減しながら、クラスタ リソースを効率的に使用するように設計されています。詳細については、 [DXFの概要](/tidb-distributed-execution-framework.md)を参照してください。 +分散実行フレームワーク (DXF) は、TiDB が特定のタスク (インデックスの作成やデータのインポートなど) を一元的にスケジュールし、分散的に実行するために使用するフレームワークです。DXF は、リソースの使用を制御し、コア業務トランザクションへの影響を軽減しながら、クラスタリソースを効率的に使用するように設計されています。詳細については、 [DXFの概要](/tidb-distributed-execution-framework.md)を参照してください。 ### 動的プルーニング（Dynamic Pruning） {#dynamic-pruning} @@ -256,7 +256,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 ### PD Control（pd-ctl） {#pd-control-pd-ctl} -PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対話するために使用されるコマンドライン ツールです。これを使用して、クラスタの状態情報を取得したり、クラスタ構成を変更したりできます。詳細については、 [PD Controlユーザーガイド](/pd-control.md)を参照してください。 +PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対話するために使用されるコマンドラインツールです。これを使用して、クラスタの状態情報を取得したり、クラスタ構成を変更したりできます。詳細については、 [PD Controlユーザーガイド](/pd-control.md)を参照してください。 ### 保留中／ダウン中（Pending/Down） {#pendingdown} @@ -367,7 +367,7 @@ TiKV におけるデータストレージの最小単位はリージョンであ ### TiCDC {#ticdc} -[TiCDC](/ticdc/ticdc-overview.md)は、TiDB からさまざまなダウンストリーム ターゲットへの増分データ レプリケーションを可能にするツールです。これらのダウンストリーム ターゲットには、他の TiDB インスタンス、MySQL 互換データベース、ストレージサービス、ストリーミング プロセッサ (Kafka や Pulsar など) が含まれます。TiCDC は、アップストリーム TiKV からデータ変更ログを取得し、それを順序付き行レベル変更データに解析し、ダウンストリームにデータを出力します。TiCDC の概念と用語の詳細については、 [TiCDC用語集](/ticdc/ticdc-glossary.md)を参照してください。 +[TiCDC](/ticdc/ticdc-overview.md)は、TiDB からさまざまなダウンストリーム ターゲットへの増分データレプリケーションを可能にするツールです。これらのダウンストリーム ターゲットには、他の TiDB インスタンス、MySQL 互換データベース、ストレージサービス、ストリーミング プロセッサ (Kafka や Pulsar など) が含まれます。TiCDC は、アップストリーム TiKV からデータ変更ログを取得し、それを順序付き行レベル変更データに解析し、ダウンストリームにデータを出力します。TiCDC の概念と用語の詳細については、 [TiCDC用語集](/ticdc/ticdc-glossary.md)を参照してください。 ### TiDB Lightning {#tidb-lightning} diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index 28c09fc750a1d..f0843ef510954 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -53,7 +53,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | TiKV | ストアサイズ | 各 TiKV インスタンスによって使用されるストレージスペースのサイズ。 | | | TiKV | cfサイズ | 各カラムファミリー(略して CF) のサイズ。 | | | TiKV | チャネルフル | 各 TiKV インスタンスでの「チャネルフル」エラーの数。 | 0 | -| TiKV | サーバーレポートの失敗 | 各 TiKV インスタンスによって報告されたエラー メッセージの数。 | 0 | +| TiKV | サーバーレポートの失敗 | 各 TiKV インスタンスによって報告されたエラーメッセージの数。 | 0 | | TiKV | スケジューラ保留コマンド | 各 TiKV インスタンス上の保留中のコマンドの数。 | | | TiKV | コプロセッサ実行者数 | TiKVが1秒あたりに受信したコプロセッサ操作の数。コプロセッサの種類ごとに個別にカウントされます。 | | | TiKV | コプロセッサ要求期間 | コプロセッサの読み取り要求を処理するのに費やされた時間。 | | @@ -64,7 +64,7 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、 | システム情報 | CPU使用率 | CPU使用率、最大100%。 | | | システム情報 | 荷重 [1m] | 1分間の負荷。 | | | システム情報 | 使用可能なメモリ | 使用可能なメモリのサイズ。 | | -| システム情報 | ネットワークトラフィック | ネットワーク トラフィックの統計。 | | +| システム情報 | ネットワークトラフィック | ネットワークトラフィックの統計。 | | | システム情報 | TCP再送信 | TOC 再送信の頻度。 | | | システム情報 | IO使用率 | ディスク使用率は最大でも 100% ですが、一般的には使用率が 80% ～ 90% までになると新しいノードの追加を検討する必要があります。 | | diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index fb803155b1c79..9e65cc2b973e3 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -76,7 +76,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### ソース別KVリクエスト時間 {#kv-request-time-by-source} - kv リクエスト合計時間: すべての TiDB インスタンスで 1 秒あたりに KV およびTiFlashリクエストを処理する合計時間 -- 各 KV リクエストとそれに対応するリクエスト ソースは積み上げ棒グラフを形成し、 `external`通常のビジネス リクエストを識別し、 `internal`内部アクティビティ リクエスト (DDL やauto analyzeリクエストなど) を識別します。 +- 各 KV リクエストとそれに対応するリクエストソースは積み上げ棒グラフを形成し、 `external`通常のビジネス リクエストを識別し、 `internal`内部アクティビティ リクエスト (DDL やauto analyzeリクエストなど) を識別します。 ### TiDB CPU {#tidb-cpu} @@ -180,8 +180,8 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_dag` : すべてのコプロセッサ要求内の DAG 要求の数。 - `super_batch` : スーパーバッチ機能を有効にするリクエストの数。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブル スキャン Executor です。`selection`は選択 Executor です。 `aggregation`は集約 Executor です`top_n`は`TopN` Executor です`limit`は制限 Executor です。 -- リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエスト タイプについて、1 秒あたりの合計処理時間の積み上げグラフを提供します。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブルスキャン Executor です。`selection`は選択 Executor です。 `aggregation`は集約 Executor です`top_n`は`TopN` Executor です`limit`は制限 Executor です。 +- リクエスト期間の概要: すべてのTiFlashインスタンスのすべてのリクエストタイプについて、1 秒あたりの合計処理時間の積み上げグラフを提供します。 - リクエスト期間: すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの合計処理期間。コプロセッサリクエストの受信からリクエストへの応答が完了するまでの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - リクエスト処理時間：すべてのTiFlashインスタンスにおける各MPPおよびコプロセッサリクエストタイプの実際の処理時間。コプロセッサリクエストの実行開始から完了までの時間であり、平均レイテンシーとp99レイテンシーが含まれます。 - Raft待機インデックス期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信してから、リージョンインデックスが`read_index`になるまで待機する時間です。 @@ -195,7 +195,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - CPU 使用率: TiCDC ノードごとの CPU 使用率。 - メモリ使用量: TiCDC ノードごとのメモリ使用量。 - ゴルーチン数: TiCDC ノードあたりのゴルーチンの数。 -- Changefeed チェックポイント ラグ: アップストリームとダウンストリーム間のデータ複製の進行ラグ (単位は秒)。 +- Changefeed チェックポイントラグ: アップストリームとダウンストリーム間のデータ複製の進行ラグ (単位は秒)。 - Changefeed 解決 ts ラグ: アップストリーム ノードと TiCDC ノード間のデータ複製の進行ラグ (単位は秒)。 - チェンジフィードのステータス: @@ -206,9 +206,9 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - 4: 完了 - -1: 不明 - Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1 秒あたりに送信する行数。 -- ソーター出力イベント/秒: TiCDC ノードのソーター モジュールがマウント モジュールに 1 秒あたりに送信する行数。 +- ソーター出力イベント/秒: TiCDC ノードのソーターモジュールがマウント モジュールに 1 秒あたりに送信する行数。 - マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 -- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 +- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーターモジュールがシンク モジュールに 1 秒あたりに送信する行数。 - SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1 秒あたりに送信する行数。 - トランザクションシンクの完全フラッシュ期間: TiCDC ノードの MySQL シンクによるダウンストリーム トランザクションの書き込みの平均レイテンシーと p999レイテンシー。 - MQ ワーカーのメッセージ送信期間パーセンタイル: ダウンストリームが Kafka の場合の MQ ワーカーによるメッセージ送信のレイテンシー。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 943a14eae7605..29edc84238a57 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -19,30 +19,30 @@ TiDBはフロー制御に[トークンバケットアルゴリズム](https://en - RU: 各リソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)の消費情報。リアルタイムで計算されます。`total`は、すべてのリソースグループで消費されるリクエストユニットの合計です。各リソースグループのリクエストユニット消費量は、読み取り消費量（読み取りリクエストユニット）と書き込み消費量（書き込みリクエストユニット）の合計と等しくなります。 - クエリあたりのRU: 各SQL文が1秒あたりに消費するリクエストユニットの平均数。上記のRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- RRU: リアルタイムで計算される各リソース グループの読み取り要求単位消費情報。`total`は 、すべてのリソース グループによって消費される読み取り要求単位の合計です。 +- RRU: リアルタイムで計算される各リソースグループの読み取り要求単位消費情報。`total`は 、すべてのリソースグループによって消費される読み取り要求単位の合計です。 - クエリあたりのRRU: 各SQL文が1秒あたりに消費する平均読み取り要求ユニット数。上記のRRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- WRU: リアルタイムで計算される各リソース グループの書き込み要求単位消費情報。`total`は 、すべてのリソース グループによって消費される書き込み要求単位の合計です。 +- WRU: リアルタイムで計算される各リソースグループの書き込み要求単位消費情報。`total`は 、すべてのリソースグループによって消費される書き込み要求単位の合計です。 - クエリあたりのWRU: 各SQL文が1秒あたりに消費する書き込みリクエストユニット（WRRU）の平均数。上記のWRUメトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 - 利用可能なRU: 各リソースグループのRUトークンバケット内の利用可能なトークン数。この値が`0`の場合、このリソースグループは`RU_PER_SEC`の割合でトークンを消費し、レート制限状態にあるとみなされます。 -- クエリの最大期間: リソース グループに関する最大クエリ期間。 +- クエリの最大期間: リソースグループに関する最大クエリ期間。 ## リソースに関する指標 {#metrics-about-resources} - KVリクエスト数: 各リソースグループに対するKVリクエストの数（1秒あたり）。リクエストは読み取りと書き込みの2種類に分類されます。`total`は 、すべてのリソースグループのKVリクエストの合計です。 - クエリあたりのKVリクエスト数: 各SQL文による1秒あたりの読み取りおよび書き込みKVリクエストの平均数。上記のKVリクエスト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 読み取りバイト数: 各リソース グループによって読み取られたデータの量 (1 秒あたりに計算)。`total`は 、すべてのリソース グループによって読み取られたデータの合計です。 +- 読み取りバイト数: 各リソースグループによって読み取られたデータの量 (1 秒あたりに計算)。`total`は 、すべてのリソースグループによって読み取られたデータの合計です。 - クエリあたりの読み取りバイト数: 各SQL文が1秒あたりに読み取るデータの平均量。上記の読み取りバイト数メトリックを1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- 書き込みバイト数: 各リソース グループによって書き込まれたデータの量。リアルタイムで計算されます。`total`は 、すべてのリソース グループによって書き込まれたデータの合計です。 +- 書き込みバイト数: 各リソースグループによって書き込まれたデータの量。リアルタイムで計算されます。`total`は 、すべてのリソースグループによって書き込まれたデータの合計です。 - クエリあたりの書き込みバイト数: 各SQL文が1秒あたりに書き込むデータ量の平均。上記の「書き込みバイト数」メトリックを、1秒あたりに実行されるSQL文の数で割ることで算出されます。 -- KV CPU 時間: 各リソース グループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソース グループで消費された KVレイヤーCPU 時間の合計です。 -- SQL CPU 時間: 各リソース グループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソース グループで消費された SQLレイヤーのCPU 時間の合計です。 +- KV CPU 時間: 各リソースグループで消費された KVレイヤーCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソースグループで消費された KVレイヤーCPU 時間の合計です。 +- SQL CPU 時間: 各リソースグループで消費された SQLレイヤーのCPU 時間 (リアルタイムで計算)。`total`は 、すべてのリソースグループで消費された SQLレイヤーのCPU 時間の合計です。 ## リソース コントローラー クライアントに関するメトリクス {#metrics-about-resource-controller-client} -- アクティブ リソース グループ: リアルタイムで計算された、各リソース コントローラー クライアントのリソース グループの数。 -- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 -- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 -- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソース グループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 -- 成功した KV 要求の待機期間 (99/90): 各リソース コントローラー クライアントの成功した KV 要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 -- トークン要求処理期間 (999/99): 各リソース コントローラー クライアントのサーバー側からのトークン要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソース グループごとに計算されます。 -- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソース グループごとに計算されます。`successful`と`failed`はすべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 +- アクティブ リソースグループ: リアルタイムで計算された、各リソース コントローラー クライアントのリソースグループの数。 +- 合計 KV 要求数: 各リソース コントローラー クライアントの KV 要求の数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの KV 要求の合計です。 +- 失敗した KV 要求数: 各リソース コントローラー クライアントの失敗した KV 要求の数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの失敗した KV 要求の合計です。 +- 成功した KV 要求数: 各リソース コントローラー クライアントの成功した KV 要求の数。リアルタイムでリソースグループごとに計算されます。`total`は 、すべてのリソース コントローラー クライアントの成功した KV 要求の合計です。 +- 成功した KV 要求の待機期間 (99/90): 各リソース コントローラー クライアントの成功した KV 要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソースグループごとに計算されます。 +- トークン要求処理期間 (999/99): 各リソース コントローラー クライアントのサーバー側からのトークン要求の待機時間 (異なるパーセンタイル)。リアルタイムでリソースグループごとに計算されます。 +- トークン要求数: 各リソース コントローラー クライアントに対するサーバー側からのトークン要求の数。リアルタイムでリソースグループごとに計算されます。`successful`と`failed`はすべてのリソース コントローラー クライアントの成功したトークン要求と失敗したトークン要求の合計です。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 9b610b51392b9..701f9213c8ab9 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -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 インスタンスにキャッシュされた実行計画の総数 @@ -103,7 +103,7 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す ### KVエラー {#kv-errors} - KVバックオフ期間: KV再試行リクエストの合計継続時間。TiDBはTiKVへのリクエスト送信時にエラーが発生する可能性があります。TiDBはTiKVへのすべてのリクエストに対して再試行メカニズムを備えています。この`KV Backoff Duration`項目は、リクエストの再試行の合計時間を記録します。 -- TiClientリージョンエラー OPS: TiKV によって返されたリージョン関連のエラー メッセージの数 +- TiClientリージョンエラー OPS: TiKV によって返されたリージョン関連のエラーメッセージの数 - KVバックオフOPS: TiKVによって返されたエラーメッセージの数 - ロック解決OPS: ロックを解決するためのTiDB操作の数。TiDBの読み取りまたは書き込み要求がロックに遭遇すると、ロックを解決しようとする。 - その他のエラー OPS: ロックのクリアや`SafePoint`の更新など、その他の種類のエラーの数 @@ -214,6 +214,6 @@ TiDB ダッシュボードに表示される主要なメトリックを理解す - 1 時間あたりの TTL 挿入行数: 1 時間ごとに TTL テーブルに挿入される行数。 - 1 時間あたりの TTL 削除行数: TTL ジョブによって 1 時間ごとに削除される期限切れの行数。 - TTL スキャン/削除クエリ期間: TTL スキャン/削除ステートメントの実行時間。 -- TTL スキャン/削除ワーカー時間 (フェーズ別): TTL 内部ワーカー スレッドのさまざまなフェーズで消費された時間。 +- TTL スキャン/削除ワーカー時間 (フェーズ別): TTL 内部ワーカースレッドのさまざまなフェーズで消費された時間。 - ステータス別の TTL ジョブ数: 現在実行中の TTL ジョブの数。 - ステータス別の TTL タスク数: 現在実行中の TTL タスクの数。 diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index cb92526100896..5f5b7abc476ac 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -36,7 +36,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - 重大なエラー: 重大なエラーの数 - サーバーがビジー状態です: 書き込み停止やチャネル満杯など、TiKV インスタンスが一時的に利用できなくなるイベントが発生したことを示します。通常の場合は`0`となります。 -- サーバー報告の失敗:サーバーによって報告されたエラー メッセージの数。通常は`0`になります。 +- サーバー報告の失敗:サーバーによって報告されたエラーメッセージの数。通常は`0`になります。 - Raftstoreエラー：各TiKVインスタンスにおけるタイプ別のRaftstoreエラー数 - スケジューラエラー: TiKVインスタンスごとに、タイプ別のスケジューラエラーの数 - コプロセッサーエラー：各TiKVインスタンスにおけるタイプ別のコプロセッサエラー数 @@ -437,7 +437,7 @@ TiKVコンポーネントのステータス概要は、主要な指標が表示 - 最古の自動GCセーフポイント：メモリ内エンジンにキャッシュされたリージョンの最古の自動GCセーフポイント - 最新の自動GCセーフポイント：メモリ内エンジンにキャッシュされたリージョン用の最新の自動GCセーフポイント - 自動GCセーフポイントギャップ：インメモリエンジンにキャッシュされたリージョンについて、最新の自動GCセーフポイントと最も古い自動GCセーフポイントの間の時間差。 -- TiKV を使用した自動 GC セーフポイントのギャップ: インメモリ エンジンにキャッシュされたリージョンについて、TiKV の自動 GC セーフポイントと最も古い自動 GC セーフポイントとの間のギャップ。 +- TiKV を使用した自動 GC セーフポイントのギャップ: インメモリエンジンにキャッシュされたリージョンについて、TiKV の自動 GC セーフポイントと最も古い自動 GC セーフポイントとの間のギャップ。 ### 悲観的ロック {#pessimistic-locking} diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index fea986c710f58..9e0f97d22c6ca 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -27,7 +27,7 @@ TiDBはv8.5 LTSにおいて、様々なオペレーティングシステムとCP > > - [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 が本番用にサポートするオペレーティング システムに移行することを強くお勧めします。 後で。 + > - 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 をアップグレードする前に、オペレーティングシステムのバージョンを確認してください。 > **Note:** diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index f9c8c1c3a43a8..9ade7c2157a6a 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -17,7 +17,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて | :------------- | :--- | :-------------------------- | :----------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | 6 | 32 VCore 64GB | 10.0.1.1
    10.0.1.2
    10.0.1.3 | CPUコアをバインドするためにNUMAを構成する | | PD | 3 | 16 VCore 32 GB | 10.0.1.4
    10.0.1.5
    10.0.1.6 | `location_labels`パラメータを設定する | -| TiKV | 6 | 32 VCore 64GB | 10.0.1.7
    10.0.1.8
    10.0.1.9 |
  • インスタンス レベルのポートと status_port を分離します。
    2. グローバルパラメータ`readpool` `storage`設定します`raftstore`
    3. インスタンス レベルのホストのラベルを構成します。
    4. CPUコアをバインドするためのNUMAを構成する
    • | +| TiKV | 6 | 32 VCore 64GB | 10.0.1.7
    10.0.1.8
    10.0.1.9 |
  • インスタンスレベルのポートと status_port を分離します。
    2. グローバルパラメータ`readpool` `storage`設定します`raftstore`
    3. インスタンスレベルのホストのラベルを構成します。
    4. CPUコアをバインドするためのNUMAを構成する
    • | | モニタリングとGrafana | 1 | 4 VCore 8GB * 1 500GB (SSD) | 10.0.1.10 | デフォルト設定 | > **Note:** @@ -29,7 +29,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて - [ハイブリッド展開のためのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml) - [ハイブリッド展開のための複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} @@ -102,4 +102,4 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて > - 構成ファイル テンプレートを編集するときは、必要なパラメータ、IP、ポート、およびディレクトリを変更します。 > - 各コンポーネントは、グローバルポートの`/-`デフォルトでポート`deploy_dir`として使用します。例えば、TiDBがポート`4001`を指定した場合、そのポート`deploy_dir`デフォルトで`/tidb-deploy/tidb-4001`なります。したがって、マルチインスタンスのシナリオでは、デフォルト以外のポートを指定する場合、ディレクトリを再度指定する必要はありません。 > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、コントロールマシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index 02cf48694e7d2..9a52e3c5dc647 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -9,7 +9,7 @@ TiDBを使用すると、SQL実行中に高負荷なクエリを特定できる > **Note:** > -> 負荷の高いクエリ ログは、次の点で[スロークエリログ](/identify-slow-queries.md)と異なります。TiDB は、ステートメントがリソース使用量 (実行時間またはメモリ使用量) のしきい値を超える**とすぐに**ステートメント情報を負荷の高いクエリ ログに出力出力。一方、TiDB は、ステートメントの実行**後に**ステートメント情報をスロークエリ ログに出力。 +> 負荷の高いクエリログは、次の点で[スロークエリログ](/identify-slow-queries.md)と異なります。TiDB は、ステートメントがリソース使用量 (実行時間またはメモリ使用量) のしきい値を超える**とすぐに**ステートメント情報を負荷の高いクエリログに出力出力。一方、TiDB は、ステートメントの実行**後に**ステートメント情報をスロークエリログに出力。 ## 負荷の高いクエリログの例 {#expensive-query-log-example} diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 2bd6e08e87033..7034d0e8e2722 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -93,9 +93,9 @@ insert into t select * from t; 以下の項目はトランザクションの実行に関連しています。 -- `Prewrite_time` : 2 フェーズ トランザクション コミットの最初のフェーズ (プリライト) の期間。 -- `Commit_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) の期間。 -- `Get_commit_ts_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) で`commit_ts`を取得するのに費やされた時間。 +- `Prewrite_time` : 2 フェーズ トランザクションコミットの最初のフェーズ (プリライト) の期間。 +- `Commit_time` : 2 フェーズ トランザクションコミットの第 2 フェーズ (コミット) の期間。 +- `Get_commit_ts_time` : 2 フェーズ トランザクションコミットの第 2 フェーズ (コミット) で`commit_ts`を取得するのに費やされた時間。 - `Local_latch_wait_time` : TiDB が 2 相トランザクションコミットの第 2 相 (コミット) の前にロックを待機するのに費やす時間。 - `Write_keys` : トランザクションが TiKV の Write CF に書き込むキーの数。 - `Write_size` : トランザクションがコミットされたときに書き込まれるキーまたは値の合計サイズ。 @@ -162,7 +162,7 @@ TiKVコプロセッサータスクフィールド： リソース制御に関連する分野： -- `Resource_group` : ステートメントがバインドされているリソース グループ。 +- `Resource_group` : ステートメントがバインドされているリソースグループ。 - `Request_unit_read` : ステートメントによって消費された読み取り RU の合計。 - `Request_unit_write` : ステートメントによって消費された書き込み RU の合計。 - `Time_queued_by_rc` : ステートメントが利用可能なリソースを待機する合計時間。 @@ -389,7 +389,7 @@ TiDB 4.0 では、 `SLOW_QUERY`は、ローテーションされたスローロ > > 指定された期間のスローログファイルが削除された場合、またはスロークエリが存在しない場合、クエリはNULLを返します。 -TiDB 4.0 では、すべての TiDB ノードのスロー クエリ情報を照会するための[`CLUSTER_SLOW_QUERY`](/information-schema/information-schema-slow-query.md#cluster_slow_query-table)システム テーブルが追加されました。 `CLUSTER_SLOW_QUERY`テーブルのテーブル スキーマは`CLUSTER_SLOW_QUERY`に`INSTANCE`列が追加されている点で`SLOW_QUERY`テーブルのスキーマとは異なります。 `INSTANCE`列は、スロー クエリの行情報の TiDB ノード アドレスを表します。 `CLUSTER_SLOW_QUERY` 、 [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md)と同様に使用できます。 +TiDB 4.0 では、すべての TiDB ノードのスロークエリ情報を照会するための[`CLUSTER_SLOW_QUERY`](/information-schema/information-schema-slow-query.md#cluster_slow_query-table)システムテーブルが追加されました。 `CLUSTER_SLOW_QUERY`テーブルのテーブルスキーマは`CLUSTER_SLOW_QUERY`に`INSTANCE`列が追加されている点で`SLOW_QUERY`テーブルのスキーマとは異なります。 `INSTANCE`列は、スロークエリの行情報の TiDB ノード アドレスを表します。 `CLUSTER_SLOW_QUERY` 、 [`SLOW_QUERY`](/information-schema/information-schema-slow-query.md)と同様に使用できます。 `CLUSTER_SLOW_QUERY`テーブルに対してクエリを実行すると、TiDB は他のノードからすべてのスロークエリ情報を取得して 1 つの TiDB ノードで操作を実行するのではなく、計算と判断を他のノードにプッシュします。 @@ -584,7 +584,7 @@ select instance, count(*) from information_schema.cluster_slow_query where time ### クエリの遅延ログが異常な時間帯にのみ発生する {#query-slow-logs-occurring-only-in-abnormal-time-period} -`2020-03-10 13:24:00`から`2020-03-10 13:27:00`までの期間に QPS の低下やレイテンシーの増加などの問題が発生した場合、原因は大規模なクエリが発生している可能性があります。次の SQL ステートメントを実行して、異常な期間にのみ発生するスロー ログを照会します。 `2020-03-10 13:20:00`から`2020-03-10 13:23:00`までの期間は通常の期間を指します。 +`2020-03-10 13:24:00`から`2020-03-10 13:27:00`までの期間に QPS の低下やレイテンシーの増加などの問題が発生した場合、原因は大規模なクエリが発生している可能性があります。次の SQL ステートメントを実行して、異常な期間にのみ発生するスローログを照会します。 `2020-03-10 13:20:00`から`2020-03-10 13:23:00`までの期間は通常の期間を指します。 ```sql SELECT * FROM diff --git a/import-example-data.md b/import-example-data.md index d3b6f3008f762..c2a97e204295d 100644 --- a/import-example-data.md +++ b/import-example-data.md @@ -1,6 +1,6 @@ --- title: Import Example Database -summary: Bikeshare サンプル データベースをインストールします。 +summary: Bikeshare サンプルデータベースをインストールします。 --- # サンプルデータベースのインポート {#import-example-database} diff --git a/index-advisor.md b/index-advisor.md index bb671ceb70675..8294ea0095dde 100644 --- a/index-advisor.md +++ b/index-advisor.md @@ -11,13 +11,13 @@ TiDB v8.5.0では、クエリパフォーマンスを向上させるインデッ > > 現在、この機能は[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスではご利用いただけません。 -インデックス アドバイザーは、クエリを分析して、 `WHERE` 、 `GROUP BY` 、 `ORDER BY`などの句からインデックス可能な列を特定します。次に、インデックス候補を生成し、仮想インデックスを使用してパフォーマンス上のメリットを推定します。TiDB は、遺伝的探索アルゴリズムを使用して最適なインデックスセットを選択します。まず単一列のインデックスから始め、複数列のインデックスを反復的に探索し、「What-If」分析を活用して、オプティマイザ プランのコストへの影響に基づいて潜在的なインデックスを評価します。アドバイザーは、インデックスを使用せずにクエリを実行する場合と比較して、インデックスによって全体のコストが削減される場合に、インデックスを推奨します。 +インデックスアドバイザーは、クエリを分析して、 `WHERE` 、 `GROUP BY` 、 `ORDER BY`などの句からインデックス可能な列を特定します。次に、インデックス候補を生成し、仮想インデックスを使用してパフォーマンス上のメリットを推定します。TiDB は、遺伝的探索アルゴリズムを使用して最適なインデックスセットを選択します。まず単一列のインデックスから始め、複数列のインデックスを反復的に探索し、「What-If」分析を活用して、オプティマイザ プランのコストへの影響に基づいて潜在的なインデックスを評価します。アドバイザーは、インデックスを使用せずにクエリを実行する場合と比較して、インデックスによって全体のコストが削減される場合に、インデックスを推奨します。 [新しい指標を推奨する](#recommend-indexes-using-the-recommend-index-statement)ことに加えて、インデックスアドバイザーは効率的なインデックス管理を確保するために[非アクティブなインデックスの削除](#remove-unused-indexes)も提案します。 ## `RECOMMEND INDEX`ステートメントを使用してインデックスを推奨します。 {#recommend-indexes-using-the-recommend-index-statement} -TiDB では、インデックス アドバイザ タスク用の`RECOMMEND INDEX` SQL ステートメントが導入されました。 `RUN`サブコマンドは、過去のワークロードを分析し、推奨事項をシステム テーブルに保存します。 `FOR`オプションを使用すると、以前に実行されていない特定の SQL ステートメントを対象にすることができます。さらに、[オプション](#recommend-index-options)の を使用して高度な制御を行うこともできます。構文は次のとおりです。 +TiDB では、インデックスアドバイザ タスク用の`RECOMMEND INDEX` SQL ステートメントが導入されました。 `RUN`サブコマンドは、過去のワークロードを分析し、推奨事項をシステムテーブルに保存します。 `FOR`オプションを使用すると、以前に実行されていない特定の SQL ステートメントを対象にすることができます。さらに、[オプション](#recommend-index-options)の を使用して高度な制御を行うこともできます。構文は次のとおりです。 ```sql RECOMMEND INDEX RUN [ FOR ] [] @@ -43,7 +43,7 @@ create_index_statement: CREATE INDEX idx_a_b ON t(a,b); インデックスアドバイザーは`a`と`b`の単一列インデックスを個別に評価し、最終的に最適なパフォーマンスを実現するためにそれらを単一のインデックスに統合します。 -以下の`EXPLAIN`の結果は、インデックスなしの場合と、推奨される 2 列の仮想インデックスを使用した場合のクエリ実行を比較したものです。インデックス アドバイザーは、両方のケースを内部的に評価し、コストが最小となるオプションを選択します。インデックス アドバイザーは`a`および`b`上の単一列の仮想インデックスも検討しますが、これらは 2 列のインデックスを組み合わせた場合よりも優れたパフォーマンスを提供しません。簡潔にするため、実行計画は省略しています。 +以下の`EXPLAIN`の結果は、インデックスなしの場合と、推奨される 2 列の仮想インデックスを使用した場合のクエリ実行を比較したものです。インデックスアドバイザーは、両方のケースを内部的に評価し、コストが最小となるオプションを選択します。インデックスアドバイザーは`a`および`b`上の単一列の仮想インデックスも検討しますが、これらは 2 列のインデックスを組み合わせた場合よりも優れたパフォーマンスを提供しません。簡潔にするため、実行計画は省略しています。 ```sql EXPLAIN FORMAT='VERBOSE' SELECT a, b FROM t WHERE a=1 AND b=1; @@ -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; @@ -157,7 +157,7 @@ Query OK, 1 row affected (0.00 sec) ### `sys.schema_unused_indexes`を使用します {#use-sysschema_unused_indexes} -[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)ビューは、すべての TiDB インスタンスの最後の起動以降に使用されていないインデックスを識別します。このビューは、スキーマ、テーブル、および列情報を含むシステム テーブルに基づいており、スキーマ、テーブル、およびインデックス名を含む、各インデックスの完全な仕様を提供します。このビューを照会することで、どのインデックスを非表示にするか、または削除するかを決定できます。 +[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)ビューは、すべての TiDB インスタンスの最後の起動以降に使用されていないインデックスを識別します。このビューは、スキーマ、テーブル、および列情報を含むシステムテーブルに基づいており、スキーマ、テーブル、およびインデックス名を含む、各インデックスの完全な仕様を提供します。このビューを照会することで、どのインデックスを非表示にするか、または削除するかを決定できます。 > **Warning:** > @@ -194,7 +194,7 @@ WHERE last_access_time IS NOT NULL AND percentage_access_0 + percentage_access_0 `EXPLAIN`ステートメントでは、クエリプランナーが考慮する仮説インデックスを定義するために、`/*+ HYPO_INDEX(...) */` SQLコメント構文を使用できます。この方法により、インデックスを物理的に作成するオーバーヘッドなしに、軽量なインデックス実験が可能になります。 -例えば、 `/*+ HYPO_INDEX(t, idx_ab, a, b) */`コメントは、クエリ プランナーに対し、 `idx_ab`テーブル上に、 `t`に対して、 `a` `b`名前の仮想インデックスを作成するように指示します。プランナーはインデックスのメタデータを生成しますが、物理的にインデックスを作成することはありません。該当する場合、プランナーはインデックス作成に伴うコストを発生させることなく、クエリ最適化中にこの仮想インデックスを考慮します。 +例えば、 `/*+ HYPO_INDEX(t, idx_ab, a, b) */`コメントは、クエリプランナーに対し、 `idx_ab`テーブル上に、 `t`に対して、 `a` `b`名前の仮想インデックスを作成するように指示します。プランナーはインデックスのメタデータを生成しますが、物理的にインデックスを作成することはありません。該当する場合、プランナーはインデックス作成に伴うコストを発生させることなく、クエリ最適化中にこの仮想インデックスを考慮します。 `RECOMMEND INDEX`アドバイザーは、仮説的なインデックスを使用して「もしも」分析を行い、さまざまなインデックスの潜在的なメリットを評価します。また、仮説的なインデックスを直接使用して、インデックスを作成する前にインデックス設計を試すこともできます。 diff --git a/information-schema/client-errors-summary-by-host.md b/information-schema/client-errors-summary-by-host.md index 2993c5efa6ae8..5c4b9b04a4e5f 100644 --- a/information-schema/client-errors-summary-by-host.md +++ b/information-schema/client-errors-summary-by-host.md @@ -17,7 +17,7 @@ summary: CLIENT_ERRORS_SUMMARY_BY_HOST` INFORMATION_SCHEMA テーブルについ `CLIENT_ERRORS_SUMMARY_BY_HOST`リモートホストごとにエラーを要約するため、あるアプリケーションサーバーが他のサーバーよりも多くのエラーを生成しているシナリオを診断するのに役立ちます。考えられるシナリオは次のとおりです。 -- 時代遅れの MySQL クライアント ライブラリ。 +- 時代遅れの MySQL クライアントライブラリ。 - 古いアプリケーション (新しいデプロイメントを展開するときにこのサーバーが見逃された可能性があります)。 - ユーザー権限の「ホスト」部分の使用方法が間違っています。 - 信頼性の低いネットワーク接続により、タイムアウトや接続切断がさらに発生します。 @@ -48,9 +48,9 @@ DESC CLIENT_ERRORS_SUMMARY_BY_HOST; フィールドの説明: -- `HOST` : クライアントのリモート ホスト。 +- `HOST` : クライアントのリモートホスト。 - `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 -- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 +- `ERROR_MESSAGE` : エラー番号に一致するエラーメッセージ (プリペアドステートメント形式)。 - `ERROR_COUNT` : このエラーがクライアント ホストに返された回数。 - `WARNING_COUNT` : この警告がクライアント ホストに返された回数。 - `FIRST_SEEN` : このエラー (または警告) がクライアント ホストから初めて確認されました。 diff --git a/information-schema/client-errors-summary-by-user.md b/information-schema/client-errors-summary-by-user.md index c5787c5841542..a47a630ddef0c 100644 --- a/information-schema/client-errors-summary-by-user.md +++ b/information-schema/client-errors-summary-by-user.md @@ -49,7 +49,7 @@ DESC CLIENT_ERRORS_SUMMARY_BY_USER; - `USER` : 認証されたユーザー。 - `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 -- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 +- `ERROR_MESSAGE` : エラー番号に一致するエラーメッセージ (プリペアドステートメント形式)。 - `ERROR_COUNT` : このエラーがユーザーに返された回数。 - `WARNING_COUNT` : この警告がユーザーに返された回数。 - `FIRST_SEEN` : このエラー (または警告) がユーザーに初めて送信されたとき。 diff --git a/information-schema/client-errors-summary-global.md b/information-schema/client-errors-summary-global.md index 71296e372fec6..886234a3c35a6 100644 --- a/information-schema/client-errors-summary-global.md +++ b/information-schema/client-errors-summary-global.md @@ -41,7 +41,7 @@ DESC CLIENT_ERRORS_SUMMARY_GLOBAL; フィールドの説明: - `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 -- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 +- `ERROR_MESSAGE` : エラー番号に一致するエラーメッセージ (プリペアドステートメント形式)。 - `ERROR_COUNT` : このエラーが返された回数。 - `WARNING_COUNT` : この警告が返された回数。 - `FIRST_SEEN` : このエラー (または警告) が最初に送信されたとき。 diff --git a/information-schema/information-schema-cluster-hardware.md b/information-schema/information-schema-cluster-hardware.md index 0c85457eb8fd5..bd4772ade298e 100644 --- a/information-schema/information-schema-cluster-hardware.md +++ b/information-schema/information-schema-cluster-hardware.md @@ -39,7 +39,7 @@ DESC cluster_hardware; - `cpu` : ハードウェア名は cpu です。 - `memory` : ハードウェア名はメモリです。 - `disk` : ディスク名。 - - `net` : ネットワーク カード名。 + - `net` : ネットワークカード名。 - `NAME` : ハードウェアの異なる情報名。例えば、CPUには`cpu-logical-cores`と`cpu-physical-cores`という2つの情報名があり、それぞれ論理コア番号と物理コア番号を意味します。 - `VALUE` : ディスクボリュームや CPU コア数などの対応するハードウェア情報の値。 diff --git a/information-schema/information-schema-cluster-load.md b/information-schema/information-schema-cluster-load.md index f8047688af19b..29973d23e9baf 100644 --- a/information-schema/information-schema-cluster-load.md +++ b/information-schema/information-schema-cluster-load.md @@ -38,7 +38,7 @@ DESC cluster_load; - `DEVICE_NAME` : ハードウェア名`DEVICE_NAME`の値は`DEVICE_TYPE`に応じて変化します。 - `cpu` : ハードウェア名は cpu です。 - `disk` : ディスク名。 - - `net` : ネットワーク カード名。 + - `net` : ネットワークカード名。 - `memory` : ハードウェア名はメモリです。 - `NAME` : 異なる負荷タイプ。例えば、CPU `load15`は`load1` `load5` 3つの負荷タイプがあり、それぞれ1分、5分、15分以内のCPUの平均負荷を意味します。 - `VALUE` : ハードウェア負荷の値。例えば、 `1min` 、 `5min` 、 `15min`それぞれ、1分、5分、15分以内のハードウェアの平均負荷を意味します。 diff --git a/information-schema/information-schema-cluster-systeminfo.md b/information-schema/information-schema-cluster-systeminfo.md index 022bde44e2929..97c902eda9eef 100644 --- a/information-schema/information-schema-cluster-systeminfo.md +++ b/information-schema/information-schema-cluster-systeminfo.md @@ -1,6 +1,6 @@ --- title: CLUSTER_SYSTEMINFO -summary: CLUSTER_SYSTEMINFO` カーネル パラメータ テーブルについて学習します。 +summary: CLUSTER_SYSTEMINFO` カーネルパラメータ テーブルについて学習します。 --- # CLUSTER_SYSTEMINFO {#cluster-systeminfo} @@ -39,7 +39,7 @@ DESC cluster_systeminfo; - `NAME` : `sysctl`に対応する構成名。 - `VALUE` : `sysctl`に対応する構成項目の値。 -次の例は、 `CLUSTER_SYSTEMINFO`システム情報テーブルを使用して、クラスター内のすべてのサーバーのカーネル バージョンを照会する方法を示しています。 +次の例は、 `CLUSTER_SYSTEMINFO`システム情報テーブルを使用して、クラスター内のすべてのサーバーのカーネルバージョンを照会する方法を示しています。 ```sql SELECT * FROM cluster_systeminfo WHERE name LIKE '%kernel.osrelease%' diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index 69dba2e57001d..5083432f79ee5 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -58,8 +58,8 @@ DESC data_lock_waits; - `"unknown"` : ハンドル タイプは現在サポートされていません。 - `"handle_value"` : ハンドル値。 - `"index_id"` : インデックスキー（インデックスを格納するキー）が属するインデックス ID。 -- `"index_name"` : インデックス キーが属するインデックスの名前。 -- `"index_values"` : インデックス キー内のインデックス値。 +- `"index_name"` : インデックスキーが属するインデックスの名前。 +- `"index_values"` : インデックスキー内のインデックス値。 上記のフィールドのうち、該当しない、または現在利用できない場合、そのフィールドはクエリ結果から省略されます。例えば、行キー情報には`index_id` 、 `index_name` 、 `index_values`は含まれません。インデックスキーには`handle_type`と`handle_value`は含まれません。非パーティションテーブルでは`partition_id`と`partition_name`は表示されません。削除されたテーブルのキー情報では`table_name` 、 `db_id` 、 `db_name` 、 `index_name`などのスキーマ情報を取得できず、テーブルがパーティションテーブルであるかどうかを区別できません。 diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 27ffcb2fff214..1187eda8f6a3c 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -5,7 +5,7 @@ summary: DEADLOCKS` INFORMATION_SCHEMA テーブルについて学習します # DEADLOCKS {#deadlocks} -`DEADLOCKS`テーブルには、現在の TiDB ノードで最近発生したいくつかのデッドロック エラーの情報が表示されます。 +`DEADLOCKS`テーブルには、現在の TiDB ノードで最近発生したいくつかのデッドロックエラーの情報が表示されます。 ```sql USE INFORMATION_SCHEMA; @@ -35,7 +35,7 @@ DESC deadlocks; `DEADLOCKS`テーブル内の各列フィールドの意味は次のとおりです。 - `DEADLOCK_ID` : デッドロックイベントのID。テーブル内に複数のデッドロックエラーが存在する場合、この列を使用して、異なるデッドロックエラーに属する行を区別できます。 -- `OCCUR_TIME` : デッドロック エラーが発生した時刻。 +- `OCCUR_TIME` : デッドロックエラーが発生した時刻。 - `RETRYABLE` : デッドロックエラーを再試行できるかどうか。再試行可能なデッドロックエラーの説明については、セクション[再試行可能なデッドロックエラー](#retryable-deadlock-errors)を参照してください。 - `TRY_LOCK_TRX_ID` : ロックを取得しようとするトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 - `CURRENT_SQL_DIGEST` : ロックを取得するトランザクションで現在実行されている SQL ステートメントのダイジェスト。 @@ -52,7 +52,7 @@ DESC deadlocks; -最近の 10 件のデッドロック イベントの情報が`DEADLOCKS`テーブルに記録されます。 +最近の 10 件のデッドロックイベントの情報が`DEADLOCKS`テーブルに記録されます。 @@ -77,8 +77,8 @@ DESC deadlocks; - `"unknown"` : ハンドル タイプは現在サポートされていません。 - `"handle_value"` : ハンドル値。 - `"index_id"` : インデックスキー（インデックスを格納するキー）が属するインデックス ID。 -- `"index_name"` : インデックス キーが属するインデックスの名前。 -- `"index_values"` : インデックス キー内のインデックス値。 +- `"index_name"` : インデックスキーが属するインデックスの名前。 +- `"index_values"` : インデックスキー内のインデックス値。 上記のフィールドのうち、該当しない、または現在利用できない場合、そのフィールドはクエリ結果から省略されます。例えば、行キー情報には`index_id` 、 `index_name` 、 `index_values`は含まれません。インデックスキーには`handle_type`と`handle_value`は含まれません。非パーティションテーブルでは`partition_id`と`partition_name`は表示されません。削除されたテーブルのキー情報では`table_name` 、 `db_id` 、 `db_name` 、 `index_name`などのスキーマ情報を取得できず、テーブルがパーティションテーブルであるかどうかを区別できません。 @@ -109,7 +109,7 @@ DESC deadlocks; - ケース 1:トランザクションB は、トランザクション A の開始後、トランザクション A がブロックされる前に実行されたステートメントによって生成されたロックによって (直接的または間接的に) ブロックされる可能性があります。 - ケース 2:トランザクションB も、トランザクション A で現在実行中のステートメントによってブロックされる可能性があります。 -ケース 1 では、TiDB はトランザクション A のクライアントにデッドロック エラーを報告し、トランザクションを終了します。 +ケース 1 では、TiDB はトランザクション A のクライアントにデッドロックエラーを報告し、トランザクションを終了します。 ケース2では、トランザクションAで現在実行中の文がTiDBで自動的に再試行されます。例えば、トランザクションAが以下の文を実行するとします。 @@ -153,7 +153,7 @@ INSERT INTO t VALUES (1, 10), (2, 20); | `UPDATE t SET v = 11 WHERE id = 1;` | | | | | `UPDATE t SET v = 21 WHERE id = 2;` | | | `UPDATE t SET v = 12 WHERE id = 2;` | | トランザクション1 はブロックされます。 | -| | `UPDATE t SET v = 22 WHERE id = 1;` | トランザクション2 はデッドロック エラーを報告します。 | +| | `UPDATE t SET v = 22 WHERE id = 1;` | トランザクション2 はデッドロックエラーを報告します。 | 次に、トランザクション2がデッドロックエラーを報告します。この時点で、テーブル`DEADLOCKS`クエリを実行します。 @@ -194,9 +194,9 @@ SELECT * FROM INFORMATION_SCHEMA.DEADLOCKS; ## クラスターデッドロック {#cluster_deadlocks} -`CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロック エラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。`CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 +`CLUSTER_DEADLOCKS`テーブルは、クラスター全体の各 TiDB ノードの最近のデッドロックエラーに関する情報を返します。これは、各ノードの`DEADLOCKS`テーブルの情報を組み合わせたものです。`CLUSTER_DEADLOCKS`は、異なる TiDB ノードを区別するために、ノードの IP アドレスとポートを表示する追加の`INSTANCE`列も含まれています。 -`DEADLOCK_ID`グローバルな一意性が保証されないため、 `CLUSTER_DEADLOCKS`テーブルのクエリ結果では、結果セット内の異なるデッドロック エラーの情報を区別するために、 `INSTANCE`と`DEADLOCK_ID`一緒に使用する必要があることに注意してください。 +`DEADLOCK_ID`グローバルな一意性が保証されないため、 `CLUSTER_DEADLOCKS`テーブルのクエリ結果では、結果セット内の異なるデッドロックエラーの情報を区別するために、 `INSTANCE`と`DEADLOCK_ID`一緒に使用する必要があることに注意してください。 ```sql USE INFORMATION_SCHEMA; diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 9787696c88db8..d28fa57566211 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -155,7 +155,7 @@ select * from information_schema.inspection_result where rule='critical-error'; 診断モジュールには一連のルールが含まれています。これらのルールは、既存の監視テーブルとクラスタ情報テーブルを照会した後、結果をしきい値と比較します。結果がしきい値を超えた場合、 `warning`または`critical`診断が生成され、対応する情報が`details`列に表示されます。 -`inspection_rules`システム テーブルをクエリすることによって、既存の診断ルールをクエリできます。 +`inspection_rules`システムテーブルをクエリすることによって、既存の診断ルールをクエリできます。 ```sql select * from information_schema.inspection_rules where type='inspection'; @@ -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 つの診断ルールが実行されます。 - 同じコンポーネントの設定値が一貫しているかどうかを確認します。すべての設定項目でこの整合性チェックが実行されるわけではありません。整合性チェックの許可リストは次のとおりです。 @@ -242,7 +242,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo `critical-error`診断ルールでは、次の 2 つの診断ルールが実行されます。 -- メトリック スキーマ内の関連する監視システム テーブルをクエリして、クラスターに次のエラーがあるかどうかを検出します。 +- メトリック スキーマ内の関連する監視システムテーブルをクエリして、クラスターに次のエラーがあるかどうかを検出します。 | コンポーネント | エラー名 | 監視テーブル | エラーの説明 | | ---- | ----------------------- | ---------------------------------- | -------------------------------------------- | @@ -253,11 +253,11 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | TiKV | チャネルがいっぱいです | tikv_チャンネルの合計数 | TiKV で「チャネルがいっぱいです」というエラーが発生します。 | | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV で「ストール」エラーが発生します。 | -- `metrics_schema.up`監視テーブルと`CLUSTER_LOG`システム テーブルを照会して、コンポーネントが再起動されているかどうかを確認します。 +- `metrics_schema.up`監視テーブルと`CLUSTER_LOG`システムテーブルを照会して、コンポーネントが再起動されているかどうかを確認します。 ### `threshold-check`診断ルール {#threshold-check-diagnostic-rule} -`threshold-check`診断ルールは、メトリック スキーマ内の関連する監視システム テーブルを照会して、クラスター内の次のメトリックがしきい値を超えているかどうかを確認します。 +`threshold-check`診断ルールは、メトリック スキーマ内の関連する監視システムテーブルを照会して、クラスター内の次のメトリックがしきい値を超えているかどうかを確認します。 | コンポーネント | 監視メトリック | 監視テーブル | 期待値 | 説明 | | :--- | :------------------- | :---------------------------------- | :-------- | :--------------------------------------------------------------------------------------------------------------- | diff --git a/information-schema/information-schema-memory-usage-ops-history.md b/information-schema/information-schema-memory-usage-ops-history.md index 8d2f1523ce861..855690530b632 100644 --- a/information-schema/information-schema-memory-usage-ops-history.md +++ b/information-schema/information-schema-memory-usage-ops-history.md @@ -1,6 +1,6 @@ --- title: MEMORY_USAGE_OPS_HISTORY -summary: MEMORY_USAGE_OPS_HISTORY` information_schema システム テーブルについて学習します。 +summary: MEMORY_USAGE_OPS_HISTORY` information_schema システムテーブルについて学習します。 --- # MEMORY_USAGE_OPS_HISTORY {#memory-usage-ops-history} diff --git a/information-schema/information-schema-memory-usage.md b/information-schema/information-schema-memory-usage.md index 39bd490a4d43b..7cad9d6c42dbe 100644 --- a/information-schema/information-schema-memory-usage.md +++ b/information-schema/information-schema-memory-usage.md @@ -1,6 +1,6 @@ --- title: MEMORY_USAGE -summary: MEMORY_USAGE` information_schema システム テーブルについて学習します。 +summary: MEMORY_USAGE` information_schema システムテーブルについて学習します。 --- # MEMORY_USAGE {#memory-usage} diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 8d68d1a8df7c0..e4a035522a25f 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -1,6 +1,6 @@ --- title: METRICS_SUMMARY -summary: METRICS_SUMMARY システム テーブルについて学習します。 +summary: METRICS_SUMMARY システムテーブルについて学習します。 --- # METRICS_SUMMARY {#metrics-summary} diff --git a/information-schema/information-schema-metrics-tables.md b/information-schema/information-schema-metrics-tables.md index 2e5ba7f77a7e4..8b79cbf8bbf35 100644 --- a/information-schema/information-schema-metrics-tables.md +++ b/information-schema/information-schema-metrics-tables.md @@ -1,6 +1,6 @@ --- title: METRICS_TABLES -summary: METRICS_TABLES` システム テーブルについて学習します。 +summary: METRICS_TABLES` システムテーブルについて学習します。 --- # METRICS_TABLES {#metrics-tables} diff --git a/information-schema/information-schema-processlist.md b/information-schema/information-schema-processlist.md index 757140943e016..31e10dca8c778 100644 --- a/information-schema/information-schema-processlist.md +++ b/information-schema/information-schema-processlist.md @@ -15,7 +15,7 @@ summary: PROCESSLIST` information_schema テーブルについて学習します - 処理中のリクエストによって使用されているメモリをバイト単位で表示する`MEM`列。 - ディスク使用量をバイト単位で表示する`DISK`列。 - トランザクションの開始時刻を表示する`TxnStart`列。 -- リソース グループ名を表示する`RESOURCE_GROUP`列。 +- リソースグループ名を表示する`RESOURCE_GROUP`列。 - 現在のセッションのエイリアスを表示する`SESSION_ALIAS`列。 - ステートメントによって現在影響を受けている行数を示す`ROWS_AFFECTED`列。 - `TIDB_CPU`列は、ステートメントがTiDBサーバーのCPUを消費した時間をナノ秒単位で示します。この列は、 [Top SQL](/dashboard/top-sql.md)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 @@ -29,7 +29,7 @@ summary: PROCESSLIST` information_schema テーブルについて学習します - 処理中のリクエストによって使用されているメモリをバイト単位で表示する`MEM`列。 - ディスク使用量をバイト単位で表示する`DISK`列。 - トランザクションの開始時刻を表示する`TxnStart`列。 -- リソース グループ名を表示する`RESOURCE_GROUP`列。 +- リソースグループ名を表示する`RESOURCE_GROUP`列。 - 現在のセッションのエイリアスを表示する`SESSION_ALIAS`列。 - ステートメントによって現在影響を受けている行数を示す`ROWS_AFFECTED`列。 - `TIDB_CPU`列は、ステートメントがTiDBサーバーのCPUを消費した時間をナノ秒単位で示します。この列は、 [Top SQL](https://docs.pingcap.com/tidb/stable/top-sql)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 @@ -98,7 +98,7 @@ RESOURCE_GROUP: default - `ID` : ユーザー接続の ID。 - `USER` : `PROCESS`を実行しているユーザーの名前。 - `HOST` : ユーザーが接続しているアドレス。 -- `DB` : 現在接続されているデフォルト データベースの名前。 +- `DB` : 現在接続されているデフォルトデータベースの名前。 - `COMMAND` : `PROCESS`が実行しているコマンドの種類。 - `TIME` : 現在の実行時間`PROCESS` (秒)。 - `STATE` : 現在の接続状態。 @@ -107,7 +107,7 @@ RESOURCE_GROUP: default - `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 - `DISK` : ディスク使用量（バイト単位）。 - `TxnStart` : トランザクションの開始時刻。 -- `RESOURCE_GROUP` : リソース グループ名。 +- `RESOURCE_GROUP` : リソースグループ名。 - `SESSION_ALIAS` : 現在のセッションのエイリアス。 - `ROWS_AFFECTED` : 現在ステートメントによって影響を受けている行数。 - `TIDB_CPU` : ステートメントがTiDBサーバーのCPUを消費する時間（ナノ秒単位）。この列は、 [Top SQL](/dashboard/top-sql.md)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 @@ -120,7 +120,7 @@ RESOURCE_GROUP: default - `ID` : ユーザー接続の ID。 - `USER` : `PROCESS`を実行しているユーザーの名前。 - `HOST` : ユーザーが接続しているアドレス。 -- `DB` : 現在接続されているデフォルト データベースの名前。 +- `DB` : 現在接続されているデフォルトデータベースの名前。 - `COMMAND` : `PROCESS`が実行しているコマンドの種類。 - `TIME` : 現在の実行時間`PROCESS` (秒)。 - `STATE` : 現在の接続状態。 @@ -129,7 +129,7 @@ RESOURCE_GROUP: default - `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 - `DISK` : ディスク使用量（バイト単位）。 - `TxnStart` : トランザクションの開始時刻。 -- `RESOURCE_GROUP` : リソース グループ名。 +- `RESOURCE_GROUP` : リソースグループ名。 - `SESSION_ALIAS` : 現在のセッションのエイリアス。 - `ROWS_AFFECTED` : 現在ステートメントによって影響を受けている行数。 - `TIDB_CPU` : ステートメントがTiDBサーバーのCPUを消費する時間（ナノ秒単位）。この列は、 [Top SQL](https://docs.pingcap.com/tidb/stable/top-sql)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 diff --git a/information-schema/information-schema-resource-groups.md b/information-schema/information-schema-resource-groups.md index ef6e8fc7358f5..ae13fd9255592 100644 --- a/information-schema/information-schema-resource-groups.md +++ b/information-schema/information-schema-resource-groups.md @@ -5,7 +5,7 @@ summary: RESOURCE_GROUPS`情報スキーマテーブルについて学習して # RESOURCE_GROUPS {#resource-groups} -`RESOURCE_GROUPS`テーブルには、すべてのリソース グループに関する情報が表示されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 +`RESOURCE_GROUPS`テーブルには、すべてのリソースグループに関する情報が表示されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 > **Note:** > @@ -78,11 +78,11 @@ SELECT * FROM information_schema.resource_groups WHERE NAME = 'rg1'; -- View the `RESOURCE_GROUPS`テーブルの列の説明は以下のとおりです。 -- `NAME` : リソース グループの名前。 -- `RU_PER_SEC` : リソース グループのバックフィル速度。単位は RU/秒で、RU [リクエストユニット](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)を意味します。 -- `PRIORITY` : TiKV で処理されるタスクの絶対優先度。異なるリソースは`PRIORITY`の設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。 `PRIORITY`が同じリソース グループの場合、タスクは`RU_PER_SEC`の設定に従って比例的にスケジュールされます。 `PRIORITY`が指定されていない場合、デフォルトの優先度は`MEDIUM`です。 -- `BURSTABLE` : リソース グループが利用可能なシステム リソースを過剰に使用することを許可するかどうか。 +- `NAME` : リソースグループの名前。 +- `RU_PER_SEC` : リソースグループのバックフィル速度。単位は RU/秒で、RU [リクエストユニット](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)を意味します。 +- `PRIORITY` : TiKV で処理されるタスクの絶対優先度。異なるリソースは`PRIORITY`の設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。 `PRIORITY`が同じリソースグループの場合、タスクは`RU_PER_SEC`の設定に従って比例的にスケジュールされます。 `PRIORITY`が指定されていない場合、デフォルトの優先度は`MEDIUM`です。 +- `BURSTABLE` : リソースグループが利用可能なシステムリソースを過剰に使用することを許可するかどうか。 > **Note:** > -> TiDB はクラスタ初期化時に`default`リソース グループを自動的に作成します。このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。どのリソース グループにもバインドされていないすべてのリクエストは、自動的にこの`default`リソース グループにバインドされます。別のリソース グループの新しい構成を作成する場合は、必要に応じて`default`リソース グループの構成を変更することをお勧めします。 +> TiDB はクラスタ初期化時に`default`リソースグループを自動的に作成します。このリソースグループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。どのリソースグループにもバインドされていないすべてのリクエストは、自動的にこの`default`リソースグループにバインドされます。別のリソースグループの新しい構成を作成する場合は、必要に応じて`default`リソースグループの構成を変更することをお勧めします。 diff --git a/information-schema/information-schema-runaway-watches.md b/information-schema/information-schema-runaway-watches.md index 9e042b68a89eb..560239a1a60be 100644 --- a/information-schema/information-schema-runaway-watches.md +++ b/information-schema/information-schema-runaway-watches.md @@ -138,7 +138,7 @@ RESOURCE_GROUP_NAME: default `RUNAWAY_WATCHES`テーブルの各列フィールドの意味は次のとおりです。 - `ID` : ウォッチアイテムのID。 -- `RESOURCE_GROUP_NAME` : リソース グループの名前。 +- `RESOURCE_GROUP_NAME` : リソースグループの名前。 - `START_TIME` : 開始時刻。 - `END_TIME` ：終了時刻。 `UNLIMITED`は、ウォッチアイテムの有効期間が無制限であることを意味します。 - `WATCH` : クイック識別のマッチタイプ。値は次のとおりです。 diff --git a/information-schema/information-schema-session-variables.md b/information-schema/information-schema-session-variables.md index 036708a66da8b..232fef90920d3 100644 --- a/information-schema/information-schema-session-variables.md +++ b/information-schema/information-schema-session-variables.md @@ -52,5 +52,5 @@ SELECT * FROM SESSION_VARIABLES ORDER BY variable_name LIMIT 10; `SESSION_VARIABLES`表の列の説明は次のとおりです。 -- `VARIABLE_NAME` : データベース内のセッション レベル変数の名前。 -- `VARIABLE_VALUE` : データベース内のセッション レベルの変数の値。 +- `VARIABLE_NAME` : データベース内のセッションレベル変数の名前。 +- `VARIABLE_VALUE` : データベース内のセッションレベルの変数の値。 diff --git a/information-schema/information-schema-sql-diagnostics.md b/information-schema/information-schema-sql-diagnostics.md index 16a0cc8d1fd25..e37bad088fe5b 100644 --- a/information-schema/information-schema-sql-diagnostics.md +++ b/information-schema/information-schema-sql-diagnostics.md @@ -10,7 +10,7 @@ SQL診断はTiDB v4.0で導入された機能です。この機能を使用す SQL 診断システムには、次の利点があります。 - システム全体のすべてのコンポーネントからの情報を統合します。 -- システム テーブルを通じて上位レイヤーへの一貫したインターフェイスを提供します。 +- システムテーブルを通じて上位レイヤーへの一貫したインターフェイスを提供します。 - 監視の概要と自動診断を提供します。 - クラスター情報のクエリが簡単になります。 @@ -41,7 +41,7 @@ TiDB v4.0より前のシステムテーブルでは、現在のインスタン 異なる期間におけるクラスタの状態を動的に監視・比較するために、SQL診断システムはクラスタ監視システムテーブルを導入しています。すべての監視テーブルは`metrics_schema`に格納されており、SQL文を用いて監視情報を照会できます。この方法を用いることで、クラスタ全体のすべての監視情報に対して相関クエリを実行し、異なる期間の結果を比較することで、パフォーマンスのボトルネックを迅速に特定できます。 -- [`information_schema.metrics_tables`](/information-schema/information-schema-metrics-tables.md) : 現在、多くのシステム テーブルが存在するため、 `information_schema.metrics_tables`テーブルでこれらの監視テーブルのメタ情報を照会できます。 +- [`information_schema.metrics_tables`](/information-schema/information-schema-metrics-tables.md) : 現在、多くのシステムテーブルが存在するため、 `information_schema.metrics_tables`テーブルでこれらの監視テーブルのメタ情報を照会できます。 TiDB クラスターには多くの監視メトリックがあるため、TiDB は v4.0 で次の監視サマリー テーブルを提供します。 diff --git a/information-schema/information-schema-tables.md b/information-schema/information-schema-tables.md index 6b6650770e7e8..e381eb3d8b261 100644 --- a/information-schema/information-schema-tables.md +++ b/information-schema/information-schema-tables.md @@ -127,7 +127,7 @@ SHOW TABLES - `"NOT_SHARDED(PK_IS_HANDLE)"` : 行 ID として整数の主キーを定義するテーブルはシャード化されません。 - `"PK_AUTO_RANDOM_BITS={bit_number}"` : 整数の主キーを行 ID として定義するテーブルは、主キーに`AUTO_RANDOM`属性が割り当てられているため、シャードされます。 - `"SHARD_BITS={bit_number}"` : テーブルは`SHARD_ROW_ID_BITS={bit_number}`を使用して分割されます。 - - `NULL` : テーブルはシステム テーブルまたはビューであるため、シャード化できません。 + - `NULL` : テーブルはシステムテーブルまたはビューであるため、シャード化できません。 - `TIDB_PK_TYPE` : テーブルの主キーの種類。可能な値は`CLUSTERED` (クラスター化主キー) と`NONCLUSTERED` (非クラスター化主キー) です。 - `TIDB_PLACEMENT_POLICY_NAME` : テーブルに適用された配置ポリシーの名前。 - `TIDB_TABLE_MODE` : テーブルのモード。たとえば、 `Normal` 、 `Import` 、 `Restore` 。 diff --git a/information-schema/information-schema-tidb-hot-regions-history.md b/information-schema/information-schema-tidb-hot-regions-history.md index b757dd39accad..0d0a2f4b66bea 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-tiflash-segments.md b/information-schema/information-schema-tiflash-segments.md index 36d390debab88..103db6ac7643a 100644 --- a/information-schema/information-schema-tiflash-segments.md +++ b/information-schema/information-schema-tiflash-segments.md @@ -9,7 +9,7 @@ summary: TIFLASH_SEGMENTS` information_schema テーブルについて学習し > > このテーブルは不安定であり、TiDB の新しいリリースで予告なく変更される可能性があるため、本番環境では使用しないでください。 -`TIFLASH_SEGMENTS`テーブルは、 TiFlashのデータ テーブル内のセグメントに関する統計情報を提供します。 +`TIFLASH_SEGMENTS`テーブルは、 TiFlashのデータテーブル内のセグメントに関する統計情報を提供します。 ```sql USE information_schema; diff --git a/information-schema/information-schema-tiflash-tables.md b/information-schema/information-schema-tiflash-tables.md index e2002a36d773a..c20d1b4944467 100644 --- a/information-schema/information-schema-tiflash-tables.md +++ b/information-schema/information-schema-tiflash-tables.md @@ -9,7 +9,7 @@ summary: TIFLASH_TABLES` information_schema テーブルについて学習しま > > このテーブルは不安定であり、TiDB の新しいリリースで予告なく変更される可能性があるため、本番環境では使用しないでください。 -`TIFLASH_TABLES`表は、 TiFlashのデータ テーブルに関する統計情報を提供します。 +`TIFLASH_TABLES`表は、 TiFlashのデータテーブルに関する統計情報を提供します。 ```sql USE information_schema; diff --git a/latency-breakdown.md b/latency-breakdown.md index a526a02c1181b..42507b30447b5 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -182,7 +182,7 @@ read handles duration = read values duration = tidb_tikvclient_rpc_net_latency_seconds{store="?"}(transaction) ``` -`tidb_tikvclient_batch_wait_duration(transaction)` 、 `tidb_tikvclient_batch_send_latency(transaction)` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}(transaction)`などの前述のバッチ クライアント期間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 +`tidb_tikvclient_batch_wait_duration(transaction)` 、 `tidb_tikvclient_batch_send_latency(transaction)` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}(transaction)`などの前述のバッチクライアント期間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 `tikv_grpc_msg_duration_seconds{type="kv_batch_get"}`期間は次のように計算されます。 @@ -218,7 +218,7 @@ Diagram( ) ``` -テーブル スキャンおよびインデックス スキャン中、 `tidb_session_execute_duration_seconds{type="general"}`期間は次のように計算されます。 +テーブルスキャンおよびインデックススキャン中、 `tidb_session_execute_duration_seconds{type="general"}`期間は次のように計算されます。 ```text tidb_session_execute_duration_seconds{type="general"} = @@ -286,7 +286,7 @@ tidb_session_execute_duration_seconds{type="general"} = req_per_copr = rate(tidb_distsql_handle_query_duration_seconds_count) / rate(tidb_distsql_scan_keys_partial_num_count) ``` -インデックス ルックアップは、パイプラインで処理されるインデックス スキャンとテーブル スキャンを組み合わせたものです。 +インデックスルックアップは、パイプラインで処理されるインデックススキャンとテーブルスキャンを組み合わせたものです。 ## クエリを書く {#write-queries} @@ -317,7 +317,7 @@ Diagram( - 実行フェーズ: 変更を実行し、TiDB のメモリに書き込みます。 - ロックフェーズ: 実行結果に対して悲観的ロックを取得します。 -- コミット フェーズ: 2 フェーズ コミット プロトコル (2PC) を使用してトランザクションをコミットします。 +- コミットフェーズ: 2 フェーズコミット プロトコル (2PC) を使用してトランザクションをコミットします。 実行フェーズでは、TiDBはメモリ内のデータを操作します。主なレイテンシーは必要なデータの読み取りに起因します。更新クエリと削除クエリの場合、TiDBはまずTiKVからデータを読み取り、次にメモリ内の行を更新または削除します。 @@ -408,7 +408,7 @@ tidb_tikvclient_request_seconds{type="PessimisticLock"} = tidb_tikvclient_rpc_net_latency_seconds{store="?"} ``` -`tidb_tikvclient_batch_wait_duration` 、 `tidb_tikvclient_batch_send_latency` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}`などの前述のバッチ クライアント期間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 +`tidb_tikvclient_batch_wait_duration` 、 `tidb_tikvclient_batch_send_latency` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}`などの前述のバッチクライアント期間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 `tikv_grpc_msg_duration_seconds{type="kv_pessimistic_lock"}`期間は次のように計算されます。 @@ -489,7 +489,7 @@ Diagram( ) ``` -コミット フェーズの期間は次のように計算されます。 +コミットフェーズの期間は次のように計算されます。 ```text commit = @@ -522,7 +522,7 @@ Commit_time = コミット期間は、次の 4 つの指標に分類できます。 -- `Get_latest_ts_time`は、非同期コミットまたはシングル フェーズ コミット (1PC) トランザクションで最新の TSO を取得するのにかかる時間を記録します。 +- `Get_latest_ts_time`は、非同期コミットまたはシングル フェーズコミット (1PC) トランザクションで最新の TSO を取得するのにかかる時間を記録します。 - `Prewrite_time`は事前書き込みフェーズの期間を記録します。 - `Get_commit_ts_time`は、一般的な 2PC トランザクションの期間を記録します。 - `Commit_time`はコミットフェーズの所要時間を記録します。非同期コミットまたは1PCトランザクションにはこのフェーズはありません。 @@ -545,7 +545,7 @@ tidb_tikvclient_request_seconds{type="Commit"} = tidb_tikvclient_rpc_net_latency_seconds{store="?"} ``` -`tidb_tikvclient_batch_wait_duration` 、 `tidb_tikvclient_batch_send_latency` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}`などの前述のバッチ クライアント期間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 +`tidb_tikvclient_batch_wait_duration` 、 `tidb_tikvclient_batch_send_latency` 、 `tidb_tikvclient_rpc_net_latency_seconds{store="?"}`などの前述のバッチクライアント期間の詳細については、 [バッチクライアント](#batch-client)セクションを参照してください。 `tikv_grpc_msg_duration_seconds{type="kv_prewrite"}`は次のように計算されます。 @@ -583,7 +583,7 @@ commit read duration(from disk) = ## バッチクライアント {#batch-client} -以下はバッチ クライアントの時間コスト図です。 +以下はバッチクライアントの時間コスト図です。 ```railroad+diagram Diagram( @@ -610,7 +610,7 @@ Diagram( - リクエストの送信にかかる全体的な所要時間は`tidb_tikvclient_request_seconds`と測定されます。 - RPC クライアントは各ストアへの接続プール (ConnArray という名前) を維持し、各プールにはバッチ要求 (送信) チャネルを持つ BatchConn があります。 -- ストアが TiKV であり、バッチ サイズが正の場合、バッチが有効になります。これはほとんどの場合に当てはまります。 +- ストアが TiKV であり、バッチサイズが正の場合、バッチが有効になります。これはほとんどの場合に当てはまります。 - バッチ要求チャネルのサイズは[`tikv-client.max-batch-size`](/tidb-configuration-file.md#max-batch-size) (デフォルトは`128` ) で、エンキューの期間は`tidb_tikvclient_batch_wait_duration`として観測されます。 - ストリーム要求には`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3 種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 @@ -663,7 +663,7 @@ RocksDB からスナップショットを取得する操作は通常は高速な ## 非同期書き込み {#async-write} -非同期書き込みは、TiKV がコールバックを使用して Raft ベースの複製されたステート マシンに非同期的にデータを書き込むプロセスです。 +非同期書き込みは、TiKV がコールバックを使用して Raft ベースの複製されたステートマシンに非同期的にデータを書き込むプロセスです。 - 以下は、非同期 IO が無効になっている場合の非同期書き込み操作の時間コスト図です。 @@ -745,7 +745,7 @@ propose duration = Raftプロセスはウォーターフォール方式で記録されます。そのため、提案された所要時間は2つのメトリックの差から計算されます。 -コミット フェーズの期間は次のように計算されます。 +コミットフェーズの期間は次のように計算されます。 ```text async io disabled commit = max( diff --git a/log-redaction.md b/log-redaction.md index 6d5aede11e698..aa16fd85d7af1 100644 --- a/log-redaction.md +++ b/log-redaction.md @@ -27,13 +27,13 @@ insert into t values (1),(1); ERROR 1062 (23000): Duplicate entry '1' for key 't.a' ``` -上記の`INSERT`ステートメントのエラー ログは次のように出力されます。 +上記の`INSERT`ステートメントのエラーログは次のように出力されます。 ``` [2024/07/02 11:35:32.686 +08:00] [INFO] [conn.go:1146] ["command dispatched failed"] [conn=1482686470] [session_alias=] [connInfo="id:1482686470, addr:127.0.0.1:52258 status:10, collation:utf8mb4_0900_ai_ci, user:root"] [command=Query] [status="inTxn:0, autocommit:1"] [sql="insert into `t` values ( ... )"] [txn_mode=PESSIMISTIC] [timestamp=450859193514065921] [err="[kv:1062]Duplicate entry '?' for key 't.a'"] ``` -上記のエラー ログから、値`tidb_redact_log`が`ON`に設定されると、データ セキュリティ リスクを回避するために、機密情報が TiDB ログで`?`マークに置き換えられることがわかります。 +上記のエラーログから、値`tidb_redact_log`が`ON`に設定されると、データ セキュリティリスクを回避するために、機密情報が TiDB ログで`?`マークに置き換えられることがわかります。 さらに、TiDBには`MARKER`オプションが用意されています。`tidb_redact_log`の値を`MARKER`に設定すると、TiDBはログ内の機密情報を直接置き換えるのではなく、 `‹›`でマークするため、秘匿化ルールをカスタマイズできます。 diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index f12d9767e1199..057068ef40402 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -318,7 +318,7 @@ grafana_servers: #### 切り替え前に生成された履歴メトリックを表示する（オプション） {#view-historical-metrics-generated-before-the-switch-optional} -切り替え前に生成された履歴メトリックを表示する必要がある場合は、次のように Grafana のデータ ソースを切り替えます。 +切り替え前に生成された履歴メトリックを表示する必要がある場合は、次のように Grafana のデータソースを切り替えます。 1. クラスター構成を編集します。 diff --git a/metadata-lock.md b/metadata-lock.md index 43ebc2cc94976..b178fb4da9d4c 100644 --- a/metadata-lock.md +++ b/metadata-lock.md @@ -1,11 +1,11 @@ --- title: Metadata Lock -summary: TiDB のメタデータ ロックの概念、原則、実装の詳細を紹介します。 +summary: TiDB のメタデータロックの概念、原則、実装の詳細を紹介します。 --- # メタデータロック {#metadata-lock} -このドキュメントでは、TiDB のメタデータ ロックについて説明します。 +このドキュメントでは、TiDB のメタデータロックについて説明します。 ## 概念 {#concept} @@ -15,7 +15,7 @@ TiDBは、オンライン非同期スキーマ変更アルゴリズムを使用 ## シナリオ {#scenarios} -TiDB のメタデータ ロックは、次のようなすべての DDL ステートメントに適用されます。 +TiDB のメタデータロックは、次のようなすべての DDL ステートメントに適用されます。 - [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) - [`ADD COLUMN`](/sql-statements/sql-statement-add-column.md) @@ -40,8 +40,8 @@ TiDB v6.5.0以降、メタデータロックはデフォルトで有効になり ## インパクト {#impact} -- DML の場合、メタデータ ロックは実行をブロックせず、デッドロックも発生しません。 -- メタデータ ロックを有効にすると、トランザクション内のメタデータ オブジェクトの情報は最初のアクセス時に決定され、その後は変更されません。 +- DML の場合、メタデータロックは実行をブロックせず、デッドロックも発生しません。 +- メタデータロックを有効にすると、トランザクション内のメタデータオブジェクトの情報は最初のアクセス時に決定され、その後は変更されません。 - DDLの場合、メタデータの状態を変更すると、古いトランザクションによってDDLがブロックされる可能性があります。以下に例を示します。 | セッション1 | セッション2 | @@ -50,7 +50,7 @@ TiDB v6.5.0以降、メタデータロックはデフォルトで有効になり | `INSERT INTO t VALUES(1);` | | | `BEGIN;` | | | | `ALTER TABLE t ADD COLUMN b INT;` | - | `SELECT * FROM t;`
    (テーブル`t`の現在のメタデータ バージョンを使用します。`(a=1, b=NULL)`を返し、テーブル`t`をロックします。) | | + | `SELECT * FROM t;`
    (テーブル`t`の現在のメタデータバージョンを使用します。`(a=1, b=NULL)`を返し、テーブル`t`をロックします。) | | | | `ALTER TABLE t ADD COLUMN c INT;` (セッション 1 によってブロックされています) | 繰り返し可能読み取り分離レベルでは、トランザクションの開始からテーブルのメタデータを決定する時点までの間に、インデックスの追加や列タイプの変更など、データの変更を必要とする DDL が実行されると、DDL は次のようにエラーを返します。 diff --git a/metrics-schema.md b/metrics-schema.md index b79b588ef0a03..73ede3109fafd 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -89,7 +89,7 @@ SHOW TABLES; 626 rows in set (0.00 sec) ``` -`METRICS_SCHEMA` 、（ [`metrics_summary`](/information-schema/information-schema-metrics-summary.md) 、 [`metrics_summary_by_label`](/information-schema/information-schema-metrics-summary.md) 、 [`inspection_summary`](/information-schema/information-schema-inspection-summary.md)などの監視関連の要約テーブルのデータ ソースとして使用されます。 +`METRICS_SCHEMA` 、（ [`metrics_summary`](/information-schema/information-schema-metrics-summary.md) 、 [`metrics_summary_by_label`](/information-schema/information-schema-metrics-summary.md) 、 [`inspection_summary`](/information-schema/information-schema-inspection-summary.md)などの監視関連の要約テーブルのデータソースとして使用されます。 ## 追加の例 {#additional-examples} diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index dfff242157cc3..83cb0f0c8d72b 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -22,11 +22,11 @@ summary: DBスナップショットを使用して、Amazon AuroraからTiDBへ ### ステップ1. スキーマファイルのエクスポートとインポート {#step-1-export-and-import-the-schema-file} -このセクションでは、Amazon Auroraからスキーマ ファイルをエクスポートし、TiDB にインポートする方法について説明します。対象データベースにテーブルを手動で作成している場合は、この手順をスキップできます。 +このセクションでは、Amazon Auroraからスキーマファイルをエクスポートし、TiDB にインポートする方法について説明します。対象データベースにテーブルを手動で作成している場合は、この手順をスキップできます。 #### 1.1 Amazon Auroraからスキーマファイルをエクスポートする {#1-1-export-the-schema-file-from-amazon-aurora} -Amazon Auroraのスナップショット ファイルには DDL ステートメントが含まれていないため、 Dumplingを使用してスキーマをエクスポートし、 TiDB Lightningを使用してターゲット データベースにスキーマを作成する必要があります。 +Amazon Auroraのスナップショットファイルには DDL ステートメントが含まれていないため、 Dumplingを使用してスキーマをエクスポートし、 TiDB Lightningを使用してターゲットデータベースにスキーマを作成する必要があります。 次のコマンドを実行して、 Dumplingを使用してスキーマをエクスポートします。このコマンドには`--filter`パラメータが含まれており、目的のテーブルスキーマのみをエクスポートできます。パラメータの詳細については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)を参照してください。 @@ -38,7 +38,7 @@ tiup dumpling --host ${host} --port 3306 --user root --password ${password} --fi 上記コマンドでエクスポートされたスキーマのURI（例：「s3://my-bucket/schema-backup」）を記録しておいてください。これは後でスキーマファイルをインポートする際に使用します。 -Amazon S3 にアクセスするには、この Amazon S3ストレージパスへのアクセス権を持つアカウントのシークレット アクセス キーとアクセス キーを環境変数としてDumplingまたはTiDB Lightningノードに渡します。Dumpling とTiDB Lightning は`~/.aws/credentials`からの認証情報ファイルの読み取りもサポートしています。この方法により、そのDumplingまたはTiDB Lightningノード上のすべてのタスクでシークレット アクセス キーとアクセス キーを再度指定する必要がなくなります。 +Amazon S3 にアクセスするには、この Amazon S3ストレージパスへのアクセス権を持つアカウントのシークレットアクセスキーとアクセスキーを環境変数としてDumplingまたはTiDB Lightningノードに渡します。Dumpling とTiDB Lightning は`~/.aws/credentials`からの認証情報ファイルの読み取りもサポートしています。この方法により、そのDumplingまたはTiDB Lightningノード上のすべてのタスクでシークレットアクセスキーとアクセスキーを再度指定する必要がなくなります。 #### 1.2 スキーマファイル用のTiDB Lightning設定ファイルを作成する {#1-2-create-the-tidb-lightning-configuration-file-for-the-schema-file} @@ -298,8 +298,8 @@ TiUPを使用してDMをデプロイした際に、Prometheus、Alertmanager、 DMが実行されている間、DM-worker、DM-master、およびdmctlは関連情報をログに出力します。これらのコンポーネントのログディレクトリは以下のとおりです。 -- DM-master: DM-master プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 -- DM-worker: DM-worker プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 +- DM-master: DM-master プロセスパラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 +- DM-worker: DM-worker プロセスパラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 ## 次は？ {#what-s-next} diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index c52c74202d64b..43e9ccc5b99a6 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -27,7 +27,7 @@ TiDB Lightning は、このディレクトリとそのサブディレクトリ CSVファイルにはスキーマ情報が含まれていないため、CSVファイルからTiDBにデータをインポートする前に、対象テーブルのスキーマを作成する必要があります。対象テーブルのスキーマは、以下の2つの方法のいずれかで作成できます。 -- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 +- **方法 1** : TiDB Lightningを使用してターゲットテーブルスキーマを作成します。 必要なDDLステートメントを含むSQLファイルを作成します。 diff --git a/migrate-from-mariadb.md b/migrate-from-mariadb.md index 525212842c786..bb4718e46e3d9 100644 --- a/migrate-from-mariadb.md +++ b/migrate-from-mariadb.md @@ -119,7 +119,7 @@ WHERE ### ストレージエンジン {#storage-engines} -MariaDB は`InnoDB` 、 `MyISAM` 、 `Aria`などのストレージデータ用のストレージ エンジンを提供しています。これらのデータ形式は TiDB で直接サポートされていませんが、移行は問題なく行えます。ただし、 `CONNECT`ストレージエンジンや`Spider`など、サーバー外にデータを配置するエンジンもあります。これらのテーブルを TiDB に移行することはできますが、TiDB は TiDB クラスタ外にデータを保存する機能を提供していません。 +MariaDB は`InnoDB` 、 `MyISAM` 、 `Aria`などのストレージデータ用のストレージエンジンを提供しています。これらのデータ形式は TiDB で直接サポートされていませんが、移行は問題なく行えます。ただし、 `CONNECT`ストレージエンジンや`Spider`など、サーバー外にデータを配置するエンジンもあります。これらのテーブルを TiDB に移行することはできますが、TiDB は TiDB クラスタ外にデータを保存する機能を提供していません。 使用しているストレージエンジンを確認するには、次のステートメントを実行してください。 @@ -256,7 +256,7 @@ ORDER BY ### インデックスの長さ {#index-length} -次の例に示すように、MariaDB はインデックスを自動的にプレフィックス インデックスに変換し、インデックスが最大キー長を超える場合は警告を返します。MariaDB とは異なり、TiDB は MySQL の動作に従います。つまり、自動変換は行わず、代わりにエラーを返します。したがって、MariaDB DDL を TiDB に移行する際、インデックス付き列が TiDB でサポートされる最大キー長を超える可能性がある場合は、プレフィックス インデックスを明示的に作成するようにスクリプトを変更する必要があります。 +次の例に示すように、MariaDB はインデックスを自動的にプレフィックスインデックスに変換し、インデックスが最大キー長を超える場合は警告を返します。MariaDB とは異なり、TiDB は MySQL の動作に従います。つまり、自動変換は行わず、代わりにエラーを返します。したがって、MariaDB DDL を TiDB に移行する際、インデックス付き列が TiDB でサポートされる最大キー長を超える可能性がある場合は、プレフィックスインデックスを明示的に作成するようにスクリプトを変更する必要があります。 ``` MariaDB> \W diff --git a/migrate-from-parquet-files-to-tidb.md b/migrate-from-parquet-files-to-tidb.md index 071a8e5c025a2..a405f0fed4c24 100644 --- a/migrate-from-parquet-files-to-tidb.md +++ b/migrate-from-parquet-files-to-tidb.md @@ -41,7 +41,7 @@ Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`を指定 DROP TABLE temp; ``` -3. Hive からエクスポートされた Parquet ファイルには`.parquet`サフィックスが付いていない場合があるため、TiDB Lightning はそれらを正しく識別できません。ファイルをインポートする前に、ファイル名を変更して `.parquet`サフィックスを追加し、ファイル名全体をTiDB Lightning が認識する形式（例: `${db_name}.${table_name}.parquet`）に変更する必要があります。ファイルの種類とパターンに関する詳細については、 [TiDB Lightningデータソース](/tidb-lightning/tidb-lightning-data-source.md)を参照してください。また、正しい[カスタマイズされた表現](/tidb-lightning/tidb-lightning-data-source.md#match-customized-files)を設定することでデータ ファイルを一致させることもできます。 +3. Hive からエクスポートされた Parquet ファイルには`.parquet`サフィックスが付いていない場合があるため、TiDB Lightning はそれらを正しく識別できません。ファイルをインポートする前に、ファイル名を変更して `.parquet`サフィックスを追加し、ファイル名全体をTiDB Lightning が認識する形式（例: `${db_name}.${table_name}.parquet`）に変更する必要があります。ファイルの種類とパターンに関する詳細については、 [TiDB Lightningデータソース](/tidb-lightning/tidb-lightning-data-source.md)を参照してください。また、正しい[カスタマイズされた表現](/tidb-lightning/tidb-lightning-data-source.md#match-customized-files)を設定することでデータファイルを一致させることもできます。 4. すべての Parquet ファイルを、例えば`/data/my_datasource/`や`s3://my-bucket/sql-backup`のような単一のディレクトリに配置してください。TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.parquet`ファイルを再帰的に検索します。 @@ -49,7 +49,7 @@ Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`を指定 ParquetファイルからTiDBにデータをインポートする前に、ターゲットテーブルスキーマを作成する必要があります。ターゲットテーブルスキーマは、以下の2つの方法のいずれかで作成できます。 -- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 +- **方法 1** : TiDB Lightningを使用してターゲットテーブルスキーマを作成します。 必要なDDLステートメントを含むSQLファイルを作成します。 diff --git a/migrate-from-sql-files-to-tidb.md b/migrate-from-sql-files-to-tidb.md index 87b6baac8529d..572de75278ea0 100644 --- a/migrate-from-sql-files-to-tidb.md +++ b/migrate-from-sql-files-to-tidb.md @@ -22,7 +22,7 @@ TiDBにデータをインポートするには、対象データベースのテ Dumplingを使用してデータをエクスポートする場合、テーブルスキーマファイルは自動的にエクスポートされます。その他の方法でエクスポートされたデータについては、以下のいずれかの方法でテーブルスキーマを作成できます。 -- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 +- **方法 1** : TiDB Lightningを使用してターゲットテーブルスキーマを作成します。 必要なDDLステートメントを含むSQLファイルを作成します。 diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 267be45bd52b2..c3159219122e8 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -157,7 +157,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する 2. 変更フィードを作成します。 - アップストリーム クラスターで次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。 + アップストリームクラスターで次のコマンドを実行して、アップストリームクラスターからダウンストリームクラスターへの変更フィードを作成します。 ```shell tiup cdc:v cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="mysql://root:@127.0.0.1:3306" --changefeed-id="upstream-to-downstream" --start-ts="434217889191428107" diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 1f9edb149c978..9f1cb14d5764f 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -8,7 +8,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー このドキュメントでは、あるTiDBクラスタから別のTiDBクラスタにデータを移行する方法について説明します。この機能は、以下のシナリオに適用されます。 - データベースの分割: TiDB クラスターが大きすぎる場合、またはクラスターのサービス間への影響を避けたい場合は、データベースを分割できます。 -- データベースの再配置: データ センターの変更など、データベースを物理的に再配置します。 +- データベースの再配置: データセンターの変更など、データベースを物理的に再配置します。 - 新しいバージョンの TiDB クラスターにデータを移行する: データのセキュリティと精度の要件を満たすために、新しいバージョンの TiDB クラスターにデータを移行します。 このドキュメントでは、移行プロセス全体を例示し、次の手順について説明します。 @@ -142,7 +142,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 2. データをバックアップします。 - データをバックアップするには、アップストリーム クラスターで`BACKUP`ステートメントを実行します。 + データをバックアップするには、アップストリームクラスターで`BACKUP`ステートメントを実行します。 ```sql MySQL [(none)]> BACKUP DATABASE * TO 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true' RATE_LIMIT = 120 MB/SECOND; @@ -161,7 +161,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 3. データを復元します。 - ダウンストリーム クラスターで`RESTORE`コマンドを実行してデータを復元します。 + ダウンストリームクラスターで`RESTORE`コマンドを実行してデータを復元します。 ```sql mysql> RESTORE DATABASE * FROM 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true'; @@ -218,7 +218,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 2. 変更フィードを作成します。 - アップストリーム クラスターで次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。 + アップストリームクラスターで次のコマンドを実行して、アップストリームクラスターからダウンストリームクラスターへの変更フィードを作成します。 ```shell tiup cdc cli changefeed create --server=http://172.16.6.122:8300 --sink-uri="mysql://root:@172.16.6.125:4000" --changefeed-id="upstream-to-downstream" --start-ts="431434047157698561" diff --git a/migrate-from-vitess.md b/migrate-from-vitess.md index 2e4ad2d2af018..ab751107d3463 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 を使用して増分データをインポートします。 diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index cf3663bda05b0..64beedfa45fd1 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -9,7 +9,7 @@ summary: DumplingとTiDB Lightningを使用して、MySQLからTiDBへ大規模 この文書では、例を用いて、このような移行の全手順を説明します。 -MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規模データセットのMySQLシャードをTiDBに移行およびマージする](/migrate-small-mysql-shards-to-tidb.md)で説明されている手順に従うことができます。この手順では、完全移行と増分移行の両方がサポートされており、手順がより簡単です。 +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`にインポートしてマージします。 @@ -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` ( @@ -114,11 +114,11 @@ TiDB Lightningによる移行を開始する前に、チェックポイントの 大量のデータを移行するには、通常数時間、場合によっては数日かかります。長時間かかる処理が予期せず中断される可能性も少なからずあります。たとえデータの一部が既にインポートされていたとしても、すべてを最初からやり直すのは非常に面倒な作業です。 -幸いなことに、 TiDB Lightning には`checkpoints`という機能があり、 TiDB Lightning はインポートの進行状況を`checkpoints`として定期的に保存するため、中断されたインポート タスクを再起動時に最新のチェックポイントから再開できます。 +幸いなことに、 TiDB Lightning には`checkpoints`という機能があり、 TiDB Lightning はインポートの進行状況を`checkpoints`として定期的に保存するため、中断されたインポートタスクを再起動時に最新のチェックポイントから再開できます。 TiDB Lightningタスクが回復不能なエラー（データ破損など）によりクラッシュした場合、チェックポイントから再開せず、エラーを報告してタスクを終了します。インポートされたデータの安全性を確保するため、他の手順に進む前に`tidb-lightning-ctl`コマンドを使用してこれらのエラーを解決する必要があります。オプションは次のとおりです。 -- --checkpoint-error-destroy: このオプションを使用すると、失敗したターゲット テーブルへのデータインポートを最初からやり直すことができます。そのためには、まずそれらのテーブル内の既存のデータをすべて削除する必要があります。 +- --checkpoint-error-destroy: このオプションを使用すると、失敗したターゲットテーブルへのデータインポートを最初からやり直すことができます。そのためには、まずそれらのテーブル内の既存のデータをすべて削除する必要があります。 - --checkpoint-error-ignore: マイグレーションが失敗した場合、このオプションはエラーが発生しなかったかのようにエラー状態をクリアします。 - --checkpoint-remove: このオプションは、エラーの有無に関わらず、すべてのチェックポイントを削除します。 @@ -366,7 +366,7 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} DMが実行されている場合、DM-master、DM-worker、およびdmctlは、移行タスクに関する情報を含むログを出力します。各コンポーネントのログディレクトリは以下のとおりです。 - DM-master ログディレクトリ: これは、DM-master コマンドラインパラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 - - DM-worker のログ ディレクトリ: これは、DM-worker コマンドライン パラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログ ディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 + - DM-worker のログディレクトリ: これは、DM-worker コマンドラインパラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 関連項目 {#see-also} diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index e39d07ed7435c..e7e9257637c27 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -94,7 +94,7 @@ LIMIT `${data-path}`には、エクスポートされたすべての上流テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 -2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 +2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 ``` SHOW MASTER STATUS: @@ -275,8 +275,8 @@ TiUPを使用してDMをデプロイした際に、Prometheus、Alertmanager、 DMが実行されている間、DM-worker、DM-master、およびdmctlは関連情報をログに出力します。これらのコンポーネントのログディレクトリは以下のとおりです。 -- DM-master: DM-master プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 -- DM-worker: DM-worker プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 +- DM-master: DM-master プロセスパラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 +- DM-worker: DM-worker プロセスパラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 ## 次は？ {#what-s-next} diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 3042179c9804c..5c58f024418a6 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -63,7 +63,7 @@ CREATE TABLE `sale` ( ## ステップ1. データソースを読み込む {#step-1-load-data-sources} -`source1.yaml`という新しいデータ ソース ファイルを作成し、DM にアップストリーム データ ソースを構成して、次のコンテンツを追加します。 +`source1.yaml`という新しいデータソースファイルを作成し、DM にアップストリームデータソースを構成して、次のコンテンツを追加します。 ```yaml # Configuration. @@ -90,9 +90,9 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml | パラメータ | 説明 | | ----------------------- | ------------------------------------------------------------------ | | `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261 | -| `operate-source create` | データ ソースを DM クラスターにロードします。 | +| `operate-source create` | データソースを DM クラスターにロードします。 | -すべてのデータ ソースが DM クラスターに追加されるまで、上記の手順を繰り返します。 +すべてのデータソースが DM クラスターに追加されるまで、上記の手順を繰り返します。 ## ステップ2. 移行タスクを構成する {#step-2-configure-the-migration-task} diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index 4d1570e0d7c87..943181c1be87e 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -7,7 +7,7 @@ summary: 小さなデータセットを MySQL から TiDB に移行する方法 このドキュメントでは、TiDB Data Migration (DM) を使用して、MySQL から TiDB へ小規模データセットを移行する方法について説明します。移行モードは完全移行モードと増分レプリケーションモードです。このドキュメントにおける「小規模データセット」とは、1 TiB 未満のデータサイズを指します。 -移行速度は、テーブル スキーマ内のインデックスの数、ハードウェア、ネットワーク環境などの複数の要因に応じて、30 GB/時間から 50 GB/時間まで変化します。 +移行速度は、テーブルスキーマ内のインデックスの数、ハードウェア、ネットワーク環境などの複数の要因に応じて、30 GB/時間から 50 GB/時間まで変化します。 @@ -34,7 +34,7 @@ from: port: 3306 ``` -次に、次のコマンドを実行して、 `tiup dmctl`を使用してデータ ソース構成を DM クラスターにロードします。 +次に、次のコマンドを実行して、 `tiup dmctl`を使用してデータソース構成を DM クラスターにロードします。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -45,7 +45,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml | パラメータ | 説明 | | :---------------------- | :-------------------------------------------------------------------- | | `--master-addr` | `dmctl`が接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261。 | -| `operate-source create` | データ ソースを DM クラスターにロードします。 | +| `operate-source create` | データソースを DM クラスターにロードします。 | ## ステップ2. 移行タスクを作成する {#step-2-create-the-migration-task} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index aa82b3bde1997..c3ac5afa787cd 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -1,6 +1,6 @@ --- title: Migrate Data to a Downstream TiDB Table with More Columns -summary: 対応するアップストリーム テーブルよりも多くの列を持つダウンストリーム TiDB テーブルにデータを移行する方法を学習します。 +summary: 対応するアップストリームテーブルよりも多くの列を持つダウンストリーム TiDB テーブルにデータを移行する方法を学習します。 --- # より多くの列を持つ下流の TiDB テーブルにデータを移行する {#migrate-data-to-a-downstream-tidb-table-with-more-columns} @@ -30,7 +30,7 @@ summary: 対応するアップストリーム テーブルよりも多くの列 ] ``` -以下はアップストリーム テーブル スキーマの例です。 +以下はアップストリームテーブルスキーマの例です。 ```sql # Upstream table schema @@ -40,7 +40,7 @@ CREATE TABLE `messages` ( ) ``` -以下はダウンストリーム テーブル スキーマの例です。 +以下はダウンストリームテーブルスキーマの例です。 ```sql # Downstream table schema @@ -51,7 +51,7 @@ CREATE TABLE `messages` ( ) ``` -DM がダウンストリーム テーブル スキーマを使用してアップストリームによって生成されたbinlogイベントを解析しようとすると、DM は上記の`Column count doesn't match`エラーを報告します。 +DM がダウンストリームテーブルスキーマを使用してアップストリームによって生成されたbinlogイベントを解析しようとすると、DM は上記の`Column count doesn't match`エラーを報告します。 このような場合、 `binlog-schema`コマンドを使用して、データソースから移行するテーブルのテーブルスキーマを設定できます。指定するテーブルスキーマは、DM によって複製されるbinlogイベントデータに対応している必要があります。シャーディングされたテーブルを移行する場合は、シャーディングされたテーブルごとに、binlogイベントデータを解析するためのテーブルスキーマを DM で設定する必要があります。手順は以下のとおりです。 @@ -77,13 +77,13 @@ DM がダウンストリーム テーブル スキーマを使用してアップ | パラメータ | 説明 | | :------------------ | :--------------------------------------------------------------------------------------------------------------- | - | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスター ノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM マスターが外部にアドバタイズするアドレスを示します。 | + | `-master-addr` | dmctl が接続されるクラスター内の任意の DM マスターノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM マスターが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | | `-s` | ソースを指定します。`${source-id}`は MySQL データのソース ID を示します。 | | `${task-name}` | データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。 | | `${database-name}` | データベースを指定します。`${database-name}`はアップストリーム データベースの名前を示します。 | - | `${table-name}` | アップストリーム テーブルの名前を指定します。 | - | `${schema-file}` | 設定するテーブル スキーマ ファイルを指定します。 | + | `${table-name}` | アップストリームテーブルの名前を指定します。 | + | `${schema-file}` | 設定するテーブルスキーマファイルを指定します。 | 例えば： diff --git a/migrate-with-pt-ghost.md b/migrate-with-pt-ghost.md index 4314c03359c4a..26f3fe6cb72b8 100644 --- a/migrate-with-pt-ghost.md +++ b/migrate-with-pt-ghost.md @@ -36,7 +36,7 @@ DM で online-ddl を有効にすると、gh-ost または pt-osc を複製す gh-ost または pt-osc のワークフロー: -- DDL 実テーブルのテーブル スキーマに従ってゴースト テーブルを作成します。 +- DDL 実テーブルのテーブルスキーマに従ってゴースト テーブルを作成します。 - ゴースト テーブルに DDL を適用します。 @@ -60,7 +60,7 @@ DM のワークフロー: - ダウンストリーム TiDB はゴースト テーブルを作成して複製する必要がないため、ストレージスペースとネットワーク転送のオーバーヘッドが節約されます。 -- シャード テーブルからデータを移行およびマージする場合、レプリケーションの正確性を確保するために、シャード ゴースト テーブルごとに RENAME 操作は無視されます。 +- シャードテーブルからデータを移行およびマージする場合、レプリケーションの正確性を確保するために、シャード ゴースト テーブルごとに RENAME 操作は無視されます。 ## 参照 {#see-also} diff --git a/migration-overview.md b/migration-overview.md index 03a22c57c5438..33f5407381ed5 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -9,8 +9,8 @@ summary: データ移行シナリオとソリューションの概要を学習 - 完全なデータ移行。 - Amazon Auroraスナップショット、CSV ファイル、または SQL ダンプファイルを TiDB にインポートするには、 TiDB Lightningを使用して完全な移行を実行できます。 - - すべての TiDB データを CSV ファイルまたは SQL ダンプ ファイルとしてエクスポートするには、 Dumplingを使用して完全な移行を実行できます。これにより、MySQL または MariaDB からのデータ移行が容易になります。 - - データ サイズのボリュームが小さい (たとえば、1 TiB 未満) データベースからすべてのデータを移行するには、TiDB Data Migration (DM) を使用することもできます。 + - すべての TiDB データを CSV ファイルまたは SQL ダンプファイルとしてエクスポートするには、 Dumplingを使用して完全な移行を実行できます。これにより、MySQL または MariaDB からのデータ移行が容易になります。 + - データサイズのボリュームが小さい (たとえば、1 TiB 未満) データベースからすべてのデータを移行するには、TiDB Data Migration (DM) を使用することもできます。 - TiDBのクイック初期化。TiDB Lightningは、データの高速インポートをサポートし、TiDB内の特定のテーブルを高速に初期化できます。この機能を使用する前に、クイック初期化はTiDBに大きな影響を与え、初期化中はクラスタがサービスを提供できないことにご注意ください。 diff --git a/migration-tools.md b/migration-tools.md index eac4a22ba3e62..508a90ed9d667 100644 --- a/migration-tools.md +++ b/migration-tools.md @@ -38,7 +38,7 @@ TiDB は、完全なデータ移行、増分データ移行、バックアップ - インポートの進行状況を保存するチェックポイントをサポートし、再起動後、`tidb-lightning`は中断したところからインポートを続行します - データフィルタリングをサポート - **制限事項**： - - データのインポートに[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md)を使用すると、インポート プロセス中に TiDB クラスターはサービスを提供できません。 + - データのインポートに[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md)を使用すると、インポートプロセス中に TiDB クラスターはサービスを提供できません。 - TiDB サービスに影響を与えたくない場合は、 TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md)に従ってデータのインポートを実行してください。 ## Dumpling {#dumpling} diff --git a/minimal-deployment-topology.md b/minimal-deployment-topology.md index 84a36c6a8ba6f..be35cf52491ca 100644 --- a/minimal-deployment-topology.md +++ b/minimal-deployment-topology.md @@ -25,9 +25,9 @@ summary: TiDB クラスターの最小限のデプロイメント トポロジ - [最小トポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml) - [最小トポロジーの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 > **Note:** > > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUP クラスターコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/mysql-compatibility.md b/mysql-compatibility.md index f0d53a838b2a9..5c97fce82d11a 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -160,7 +160,7 @@ TiDB は[PrometheusとGrafana](/tidb-monitoring-api.md)の組み合わせを利 -TiDB Cloudのパフォーマンス メトリックを確認するには、 TiDB Cloudコンソールのクラスター概要ページを確認するか、 [サードパーティ製監視ツールとの連携](/tidb-cloud/third-party-monitoring-integrations.md)を使用します。ほとんどの [パフォーマンススキーマテーブル](/performance-schema/performance-schema.md)TiDB で空の結果を返します。 +TiDB Cloudのパフォーマンスメトリックを確認するには、 TiDB Cloudコンソールのクラスター概要ページを確認するか、 [サードパーティ製監視ツールとの連携](/tidb-cloud/third-party-monitoring-integrations.md)を使用します。ほとんどの [パフォーマンススキーマテーブル](/performance-schema/performance-schema.md)TiDB で空の結果を返します。 @@ -180,7 +180,7 @@ TiDBはMySQLの組み込み関数のほとんどをサポートしています TiDBでは、サポートされているすべてのDDL変更をオンラインで実行できます。ただし、TiDBのDDL操作には、MySQLと比較していくつかの大きな制限があります。 -- 単一の`ALTER TABLE`ステートメントを使用してテーブルの複数のスキーマ オブジェクト (列やインデックスなど) を変更する場合、同じオブジェクトを複数の変更で指定することはサポートされていません。たとえば、 `ALTER TABLE t1 MODIFY COLUMN c1 INT, DROP COLUMN c1`コマンドを実行すると、 `Unsupported operate same column/index`エラーが出力されます。 +- 単一の`ALTER TABLE`ステートメントを使用してテーブルの複数のスキーマオブジェクト (列やインデックスなど) を変更する場合、同じオブジェクトを複数の変更で指定することはサポートされていません。たとえば、 `ALTER TABLE t1 MODIFY COLUMN c1 INT, DROP COLUMN c1`コマンドを実行すると、 `Unsupported operate same column/index`エラーが出力されます。 - 同じ`ALTER TABLE`ステートメント内で、`SHARD_ROW_ID_BITS`と`AUTO_ID_CACHE`を同時に変更することはサポートされていません。 - TiDB は`ALTER TABLE`を使用した一部のデータ型の変更をサポートしていません。たとえば、TiDB は`DECIMAL`型から`DATE`型への変更をサポートしていません。データ型の変更がサポートされていない場合、TiDB は`Unsupported modify column: type %d not match origin %d`エラーを報告します。詳細については、 [`ALTER TABLE`](/sql-statements/sql-statement-modify-column.md)を参照してください。 - `ALGORITHM={INSTANT,INPLACE,COPY}`構文はTiDBではアサーションとしてのみ機能し、 `ALTER`アルゴリズムを変更しません。詳細については、 [`ALTER TABLE`](/sql-statements/sql-statement-alter-table.md)を参照してください。 diff --git a/mysql-schema/mysql-schema-user.md b/mysql-schema/mysql-schema-user.md index 065e3d7ebf342..510d3be60762b 100644 --- a/mysql-schema/mysql-schema-user.md +++ b/mysql-schema/mysql-schema-user.md @@ -5,7 +5,7 @@ summary: mysql` スキーマの `user` テーブルについて学習します # `mysql.user` {#mysql-user} -`mysql.user`表は、ユーザー アカウントとその権限に関する情報を提供します。 +`mysql.user`表は、ユーザーアカウントとその権限に関する情報を提供します。 `mysql.user`の構造を表示するには、次の SQL ステートメントを使用します。 @@ -82,7 +82,7 @@ DESC mysql.user; - セキュリティ： - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 - - `Account_locked` : ユーザー アカウントがロックされているかどうかを示します。 + - `Account_locked` : ユーザーアカウントがロックされているかどうかを示します。 - `Password_reuse_history`と`Password_reuse_time` : [パスワード再利用ポリシー](/password-management.md#password-reuse-policy)に使用されます。 - `User_attributes` : ユーザーのコメントとユーザー属性に関する情報を提供します。 - `Token_issuer` : [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証プラグインに使用されます。 @@ -102,7 +102,7 @@ DESC mysql.user; - セキュリティ： - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 - - `Account_locked` : ユーザー アカウントがロックされているかどうかを示します。 + - `Account_locked` : ユーザーアカウントがロックされているかどうかを示します。 - `Password_reuse_history`と`Password_reuse_time` : [パスワード再利用ポリシー](https://docs.pingcap.com/tidb/stable/password-management#password-reuse-policy)に使用されます。 - `User_attributes` : ユーザーのコメントとユーザー属性に関する情報を提供します。 - `Token_issuer` : [`tidb_auth_token`](https://docs.pingcap.com/tidb/stable/security-compatibility-with-mysql#tidb_auth_token)認証プラグインに使用されます。 diff --git a/mysql-schema/mysql-schema.md b/mysql-schema/mysql-schema.md index 6010872bda7cf..73ef3de0c622d 100644 --- a/mysql-schema/mysql-schema.md +++ b/mysql-schema/mysql-schema.md @@ -31,7 +31,7 @@ summary: TiDBのシステムテーブルについて学びましょう。 - `bootstrapped` : TiDBクラスタが初期化されているかどうか。この値は読み取り専用であり、変更できません。 - `tidb_server_version` : TiDB の初期化時のバージョン情報。この値は読み取り専用であり、変更できません。 - - `system_tz` : TiDB のシステム タイム ゾーン。 + - `system_tz` : TiDB のシステム タイムゾーン。 - `new_collation_enabled` : TiDB が[照合順序のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)を有効にしたかどうか。この値は読み取り専用であり、変更できないことに注意してください。 - `cluster_id` （v8.5.6で追加）：TiDBクラスタの一意の識別子。この値は読み取り専用であり、変更できません。 @@ -92,8 +92,8 @@ summary: TiDBのシステムテーブルについて学びましょう。 ## メタデータロックに関連するシステムテーブル {#system-tables-related-to-metadata-locks} -- [`tidb_mdl_view`](/mysql-schema/mysql-schema-tidb-mdl-view.md) : メタデータ ロックのビュー。これを使用して、現在ブロックされている DDL ステートメントに関する情報を表示できます。[メタデータロック](/metadata-lock.md)も参照してください。 -- `tidb_mdl_info` : TiDB が内部的に使用して、ノード間でメタデータ ロックを同期します。 +- [`tidb_mdl_view`](/mysql-schema/mysql-schema-tidb-mdl-view.md) : メタデータロックのビュー。これを使用して、現在ブロックされている DDL ステートメントに関する情報を表示できます。[メタデータロック](/metadata-lock.md)も参照してください。 +- `tidb_mdl_info` : TiDB が内部的に使用して、ノード間でメタデータロックを同期します。 ## DDLステートメントに関連するシステムテーブル {#system-tables-related-to-ddl-statements} diff --git a/non-transactional-dml.md b/non-transactional-dml.md index 685770e4282d2..43cb1d75a6942 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -244,7 +244,7 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 4. 非トランザクション DML ステートメントを実行します。 -5. エラーが報告された場合は、エラー メッセージまたはログから特定の失敗したデータ範囲を取得し、再試行するか手動で処理します。 +5. エラーが報告された場合は、エラーメッセージまたはログから特定の失敗したデータ範囲を取得し、再試行するか手動で処理します。 ## パラメータの説明 {#parameter-description} @@ -259,7 +259,7 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; - アプリケーションデータの分布がわかっている場合は、条件`WHERE`に従って、バッチ処理後にデータをより狭い範囲に分割する列を選択します。 - 理想的には、条件`WHERE`ではシャード列のインデックスを利用することで、バッチごとにスキャンするデータ量を削減できます。例えば、各トランザクションの開始時刻と終了時刻を記録するトランザクションテーブルがあり、終了時刻が1か月前であるすべてのトランザクションレコードを削除したいとします。トランザクションの開始時刻にインデックスがあり、トランザクションの開始時刻と終了時刻が比較的近い場合は、開始時刻列をシャード列として選択できます。 - - 理想的とは言えないケースでは、シャード列のデータ分布は`WHERE`条件から完全に独立しており、シャード列のインデックスを使用してデータ スキャンの範囲を縮小することはできません。 + - 理想的とは言えないケースでは、シャード列のデータ分布は`WHERE`条件から完全に独立しており、シャード列のインデックスを使用してデータスキャンの範囲を縮小することはできません。 - クラスター化インデックスが存在する場合は、実行効率を高めるために、主キー（ `INT`主キーと`_tidb_rowid`含む）をシャード列として使用することをお勧めします。 - 重複する値が少ない列を選択してください。 @@ -296,7 +296,7 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 非トランザクションDML文の動作原理は、TiDBにSQL文の自動分割機能を組み込むことです。非トランザクションDML文がない場合、SQL文を手動で分割する必要があります。非トランザクションDML文の動作を理解するには、以下のタスクを実行するユーザースクリプトと考えてください。 -非トランザクション DML `BATCH ON $C$ LIMIT $N$ DELETE FROM ... WHERE $P$`の場合、$C$ は分割に使用される列、$N$ はバッチ サイズ、$P$ はフィルター条件です。 +非トランザクション DML `BATCH ON $C$ LIMIT $N$ DELETE FROM ... WHERE $P$`の場合、$C$ は分割に使用される列、$N$ はバッチサイズ、$P$ はフィルター条件です。 1. TiDBは、元のステートメントのフィルタ条件$P$と分割対象として指定された列$C$に基づいて、$P$を満たすすべての$C$をクエリします。TiDBはこれらの$C$を$N$に基づいてグループ$B_1 \dots B_k$に分類します。すべての$B_i$について、TiDBは最初と最後の$C$を$S_i$と$E_i$として保持します。このステップで実行されたクエリステートメントは、 [`DRY RUN QUERY`](/non-transactional-dml.md#query-the-batch-dividing-statement)を通して確認できます。 2. $B_i$に含まれるデータは、$P_i$を満たすサブセットです: $C$ BETWEEN $S_i$ AND $E_i$。$P_i$を使用することで、各バッチで処理する必要があるデータの範囲を絞り込むことができます。 @@ -305,7 +305,7 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; ## バッチDMLとの比較 {#comparison-with-batch-dml} -batch-dml は、DML ステートメントの実行中にトランザクションを複数のトランザクション コミットに分割するメカニズムです。 +batch-dml は、DML ステートメントの実行中にトランザクションを複数のトランザクションコミットに分割するメカニズムです。 > **Note:** > @@ -380,11 +380,11 @@ WHERE t.c1 IS NULL; ### 実際のバッチサイズは指定されたバッチサイズと同じではありません {#the-actual-batch-size-is-not-the-same-as-the-specified-batch-size} -非トランザクション DML ステートメントの実行中に、最後のバッチで処理されるデータのサイズが、指定されたバッチ サイズよりも小さくなる可能性があります。 +非トランザクション DML ステートメントの実行中に、最後のバッチで処理されるデータのサイズが、指定されたバッチサイズよりも小さくなる可能性があります。 **シャード列に重複した値が存在する**場合、各バッチには、そのバッチ内のシャード列の最後の要素の重複した値がすべて含まれます。そのため、このバッチの行数は指定されたバッチサイズよりも大きくなる可能性があります。 -さらに、他の同時書き込みが発生すると、各バッチで処理される行数は指定されたバッチ サイズと異なる場合があります。 +さらに、他の同時書き込みが発生すると、各バッチで処理される行数は指定されたバッチサイズと異なる場合があります。 ### 実行中に、 `Failed to restore the delete statement, probably because of unsupported type of the shard column`エラーが発生します。 {#the-failed-to-restore-the-delete-statement-probably-because-of-unsupported-type-of-the-shard-column-error-occurs-during-execution} diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index fffe2522ad80e..76e88902b8605 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -48,13 +48,13 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `200` - 可能な値: `[0, 2147483647]` -- メモリを節約するために、プラン キャッシュでは、この変数で指定された数を超えるパラメータを持つクエリはキャッシュされません。 `0`制限がないことを意味します。 +- メモリを節約するために、プランキャッシュでは、この変数で指定された数を超えるパラメータを持つクエリはキャッシュされません。 `0`制限がないことを意味します。 ### `44830` v6.5.7 および v7.3.0 の新機能 {#44830-new-in-v657-and-v730} - デフォルト値: `OFF` - 可能`OFF`値: `ON` -- この変数は、物理的な最適化中に生成された`PointGet`演算子を使用して実行計画をプラン キャッシュがキャッシュできるかどうかを制御します。 +- この変数は、物理的な最適化中に生成された`PointGet`演算子を使用して実行計画をプランキャッシュがキャッシュできるかどうかを制御します。 ### `44855` v6.5.4 および v7.3.0 の新機能 {#44855-new-in-v654-and-v730} @@ -75,7 +75,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON` - 可能`OFF`値: `ON` -- この変数は、プラン キャッシュが[生成列](/generated-columns.md)にアクセスする実行計画をキャッシュできるかどうかを制御します。 +- この変数は、プランキャッシュが[生成列](/generated-columns.md)にアクセスする実行計画をキャッシュできるかどうかを制御します。 ### `46177` v6.5.6、v7.1.3、v7.5.0 の新機能 {#46177-new-in-v656-v713-and-v750} @@ -105,8 +105,8 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON`。v8.5.7 より前では、デフォルト値は `OFF` です。 - 可能`OFF`値: `ON` -- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリ プランに対して単一インデックス スキャン方式 (フル テーブル スキャン以外) を選択できるとき、オプティマイザはインデックス マージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 -- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックス マージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 +- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できるとき、オプティマイザはインデックスマージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 +- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 ### `54337`バージョン8.3.0の新機能 {#54337-new-in-v830} diff --git a/optimizer-hints.md b/optimizer-hints.md index 9909ed8a5dd1b..7191a813714e7 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -11,7 +11,7 @@ TiDBは、 MySQL 5.7で導入されたコメント形式の構文に基づいた ## 構文 {#syntax} -オプティマイザ ヒントは大文字と小文字を区別せず、SQL ステートメントの`SELECT` 、 `INSERT` 、 `UPDATE` 、または`DELETE`キーワードに続く`/*+ ... */`コメント内で指定されます。 +オプティマイザヒントは大文字と小文字を区別せず、SQL ステートメントの`SELECT` 、 `INSERT` 、 `UPDATE` 、または`DELETE`キーワードに続く`/*+ ... */`コメント内で指定されます。 複数のヒントはカンマで区切って指定できます。例えば、次のクエリでは3つの異なるヒントが使用されています。 @@ -47,12 +47,12 @@ SELECT * FROM (SELECT * FROM t) t1, (SELECT * FROM t) t2; SELECT /*+ HASH_JOIN(@sel_1 t1@sel_1, t3) */ * FROM (SELECT t1.a, t1.b FROM t t1, t t2 WHERE t1.a = t2.a) t1, t t3 WHERE t1.b = t3.b; ``` -このヒントは`sel_1`クエリ ブロックで有効になり、そのパラメータは`sel_1`の`t1`と`t3`テーブルです ( `sel_2`は`t1`テーブルも含まれています)。 +このヒントは`sel_1`クエリブロックで有効になり、そのパラメータは`sel_1`の`t1`と`t3`テーブルです ( `sel_2`は`t1`テーブルも含まれています)。 -上で説明したように、ヒント内のクエリ ブロックの名前は次の方法で指定できます。 +上で説明したように、ヒント内のクエリブロックの名前は次の方法で指定できます。 - ヒントの最初のパラメータとしてクエリブロック名を設定し、他のパラメータとはスペースで区切ってください。このセクションにリストされているすべてのヒントには、 `QB_NAME`に加えて、オプションの隠しパラメータ`@QB_NAME`も存在します。このパラメータを使用することで、ヒントの有効範囲を指定できます。 -- パラメータ内のテーブル名に`@QB_NAME`を追加して、このテーブルがどのクエリ ブロックに属するかを明示的に指定します。 +- パラメータ内のテーブル名に`@QB_NAME`を追加して、このテーブルがどのクエリブロックに属するかを明示的に指定します。 > **Note:** > @@ -68,11 +68,11 @@ SELECT /*+ HASH_JOIN(@sel_1 t1@sel_1, t3) */ * FROM (SELECT t1.a, t1.b FROM t t1 SELECT /*+ QB_NAME(QB1) */ * FROM (SELECT * FROM t) t1, (SELECT * FROM t) t2; ``` -このヒントは、外側の`SELECT`クエリ ブロックの名前を`QB1`に指定します。これにより、 `QB1`とデフォルト名`sel_1`の両方がクエリ ブロックに対して有効になります。 +このヒントは、外側の`SELECT`クエリブロックの名前を`QB1`に指定します。これにより、 `QB1`とデフォルト名`sel_1`の両方がクエリブロックに対して有効になります。 > **Note:** > -> 上記の例では、ヒントが`QB_NAME`を`sel_2`に指定し、元の 2 番目のクエリ ブロック`SELECT`に新しい`QB_NAME`を指定していない場合、2 番目のクエリ ブロック`SELECT`に対して`sel_2`は無効な名前になります。 +> 上記の例では、ヒントが`QB_NAME`を`sel_2`に指定し、元の 2 番目のクエリブロック`SELECT`に新しい`QB_NAME`を指定していない場合、2 番目のクエリブロック`SELECT`に対して`sel_2`は無効な名前になります。 ### MERGE_JOIN(t1_name [, tl_name ...]) {#merge_joint1_name--tl_name-} @@ -256,7 +256,7 @@ SELECT /*+ BROADCAST_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; `NO_DECORRELATE()`ヒントは、指定されたクエリブロック内の相関サブクエリに対して、相関解除を実行しないようにオプティマイザに指示します。このヒントは`EXISTS` 、 `IN` 、 `ANY` 、 `ALL` 、 `SOME`サブクエリ、および相関列を含むスカラーサブクエリ（つまり、相関サブクエリ）に適用されます。 -このヒントがクエリ ブロック内で使用される場合、オプティマイザーはサブクエリとその外側のクエリ ブロック間の相関列の非相関化を試行せず、常に Apply 演算子を使用してクエリを実行します。 +このヒントがクエリブロック内で使用される場合、オプティマイザーはサブクエリとその外側のクエリブロック間の相関列の非相関化を試行せず、常に Apply 演算子を使用してクエリを実行します。 デフォルトでは、TiDBは相関サブクエリに対して[相関除去を実行する](/correlated-subquery-optimization.md)ことで実行効率を高めようとします。しかし、 [いくつかのシナリオ](/correlated-subquery-optimization.md#restrictions)では、相関除去によって実行効率が低下する可能性があります。このような場合は、このヒントを使用してオプティマイザに相関除去を行わないよう手動で指示することができます。例えば、次のようになります。 @@ -424,7 +424,7 @@ EXPLAIN SELECT /*+ ORDER_INDEX(t, a) */ a FROM t ORDER BY a LIMIT 10; `NO_ORDER_INDEX(t1_name, idx1_name [, idx2_name ...])`ヒントは、指定されたテーブルに対して指定されたインデックスのみを使用し、指定されたインデックスを順番に読み取らないようにオプティマイザに指示します。このヒントは通常、以下のシナリオに適用されます。 -次の例は、クエリ ステートメントの効果が`SELECT * FROM t t1 use index(idx1, idx2);`と同等であることを示しています。 +次の例は、クエリステートメントの効果が`SELECT * FROM t t1 use index(idx1, idx2);`と同等であることを示しています。 ```sql CREATE TABLE t(a INT, b INT, key(a), key(b)); @@ -526,7 +526,7 @@ select /*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */ t1.a from t t1, t t2 wher ヒント`USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...])`は、オプティマイザにインデックスマージ方式で特定のテーブルにアクセスするよう指示します。インデックスマージには、交差型と結合型の2種類があります。詳細は[インデックスマージを使用したステートメントの説明](/explain-index-merge.md)を参照してください。 -インデックスのリストを明示的に指定すると、TiDB はリストからインデックスを選択してインデックス マージを構築します。インデックスのリストを指定しないと、TiDB は利用可能なすべてのインデックスからインデックスを選択してインデックス マージを構築します。 +インデックスのリストを明示的に指定すると、TiDB はリストからインデックスを選択してインデックスマージを構築します。インデックスのリストを指定しないと、TiDB は利用可能なすべてのインデックスからインデックスを選択してインデックスマージを構築します。 交差型インデックスマージの場合、指定されたインデックスリストはヒントの必須パラメータです。和集合型インデックスマージの場合、指定されたインデックスリストはヒントのオプションパラメータです。次の例を参照してください。 @@ -614,7 +614,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > > `@QueryBlockName`と直後の`.ViewName@QueryBlockName`の間には空白があります。そうでない場合、 `.ViewName@QueryBlockName`は`QueryBlockName`の一部として扱われます。例えば、 `QB_NAME(v2_1, v2@SEL_1 .@SEL_1)`は有効ですが、 `QB_NAME(v2_1, v2@SEL_1.@SEL_1)`は正しく解析できません。 -- 単一のビューとサブクエリのない単純なステートメントの場合、次の例では、ビュー`v`の最初のクエリ ブロック名を指定します。 +- 単一のビューとサブクエリのない単純なステートメントの場合、次の例では、ビュー`v`の最初のクエリブロック名を指定します。 ```sql SELECT /* Comment: The name of the current query block is the default @SEL_1 */ * FROM v; @@ -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 ( @@ -638,7 +638,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * 最初のビュー`v2`の場合、最初のクエリステートメントから始まるリストの最初のビュー名は`v2@SEL_1`です。2番目のビュー`v2`の場合、最初のビュー名は`v2@SEL_2`です。次の例では、最初のビュー`v2`のみを考慮しています。 - ビュー`v2`の最初のクエリ ブロックは`QB_NAME(v2_1, v2@SEL_1 .@SEL_1)`として宣言でき、ビュー`v2`の 2 番目のクエリ ブロックは`QB_NAME(v2_2, v2@SEL_1 .@SEL_2)`として宣言できます。 + ビュー`v2`の最初のクエリブロックは`QB_NAME(v2_1, v2@SEL_1 .@SEL_1)`として宣言でき、ビュー`v2`の 2 番目のクエリブロックは`QB_NAME(v2_2, v2@SEL_1 .@SEL_2)`として宣言できます。 ```sql CREATE VIEW v2 AS @@ -661,41 +661,41 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > > - ビューでグローバルヒントを使用するには、対応する`QB_NAME`ヒントをビューに定義する必要があります。そうしないと、グローバルヒントは有効になりません。 > -> - ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリ ブロック内にあることを確認する必要があります。 +> - ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリブロック内にあることを確認する必要があります。 > -> - 最も外側のクエリ ブロックのビューで`QB_NAME`ヒントを定義すると、次のようになります。 +> - 最も外側のクエリブロックのビューで`QB_NAME`ヒントを定義すると、次のようになります。 > > - `QB_NAME`のビューリストの最初の項目において、 `@SEL_`が明示的に宣言されていない場合、デフォルトは`QB_NAME`が定義されているクエリブロックの位置と一致します。つまり、クエリ`SELECT /*+ QB_NAME(qb1, v2) */ * FROM v2 JOIN (SELECT /*+ QB_NAME(qb2, v2) */ * FROM v2) vv;`は`SELECT /*+ QB_NAME(qb1, v2@SEL_1) */ * FROM v2 JOIN (SELECT /*+ QB_NAME(qb2, v2@SEL_2) */ * FROM v2) vv;`と同等です。 > - `QB_NAME`ビューリストの最初の項目以外の項目については、 `@SEL_1`のみを省略できます。つまり、現在のビューの最初のクエリブロックで`@SEL_1`が宣言されている場合、 `@SEL_1`を省略できます。それ以外の場合、 `@SEL_`は省略できません。上記の例の場合： > -> - ビュー`v2`の最初のクエリ ブロックは`QB_NAME(v2_1, v2)`として宣言できます。 -> - ビュー`v2`の 2 番目のクエリ ブロックは`QB_NAME(v2_2, v2.@SEL_2)`として宣言できます。 -> - ビュー`v1`の最初のクエリ ブロックは`QB_NAME(v1_1, v2.v1@SEL_2)`として宣言できます。 -> - ビュー`v1`の 2 番目のクエリ ブロックは`QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2)`として宣言できます。 +> - ビュー`v2`の最初のクエリブロックは`QB_NAME(v2_1, v2)`として宣言できます。 +> - ビュー`v2`の 2 番目のクエリブロックは`QB_NAME(v2_2, v2.@SEL_2)`として宣言できます。 +> - ビュー`v1`の最初のクエリブロックは`QB_NAME(v1_1, v2.v1@SEL_2)`として宣言できます。 +> - ビュー`v1`の 2 番目のクエリブロックは`QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2)`として宣言できます。 ### ステップ2: ターゲットヒントを追加する {#step-2-add-the-target-hints} ビューのクエリブロックに`QB_NAME`ヒントを定義した後、ビュー内で有効にするために、必要な[クエリブロックで有効になるヒント](#hints-that-take-effect-in-query-blocks)ヒントを`ViewName@QueryBlockName`の形式で追加できます。例： -- ビュー`v2`の最初のクエリ ブロックに`MERGE_JOIN()`ヒントを指定します。 +- ビュー`v2`の最初のクエリブロックに`MERGE_JOIN()`ヒントを指定します。 ```sql SELECT /*+ QB_NAME(v2_1, v2) merge_join(t@v2_1) */ * FROM v2; ``` -- ビュー`v2`の 2 番目のクエリ ブロックにヒント`MERGE_JOIN()`と`STREAM_AGG()`を指定します。 +- ビュー`v2`の 2 番目のクエリブロックにヒント`MERGE_JOIN()`と`STREAM_AGG()`を指定します。 ```sql SELECT /*+ QB_NAME(v2_2, v2.@SEL_2) merge_join(t1@v2_2) stream_agg(@v2_2) */ * FROM v2; ``` -- ビュー`v1`の最初のクエリ ブロックに`HASH_JOIN()`ヒントを指定します。 +- ビュー`v1`の最初のクエリブロックに`HASH_JOIN()`ヒントを指定します。 ```sql SELECT /*+ QB_NAME(v1_1, v2.v1@SEL_2) hash_join(t@v1_1) */ * FROM v2; ``` -- ビュー`v1`の 2 番目のクエリ ブロックにヒント`HASH_JOIN()`と`HASH_AGG()`を指定します。 +- ビュー`v1`の 2 番目のクエリブロックにヒント`HASH_JOIN()`と`HASH_AGG()`を指定します。 ```sql SELECT /*+ QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2) hash_join(t1@v1_2) hash_agg(@v1_2) */ * FROM v2; @@ -711,7 +711,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * ### NO_INDEX_MERGE() {#no_index_merge} -ヒント`NO_INDEX_MERGE()`は、オプティマイザのインデックス マージ機能を無効にします。 +ヒント`NO_INDEX_MERGE()`は、オプティマイザのインデックスマージ機能を無効にします。 たとえば、次のクエリではインデックスのマージは使用されません。 @@ -772,11 +772,11 @@ select /*+ READ_CONSISTENT_REPLICA() */ * from t; ### IGNORE_PLAN_CACHE() {#ignore_plan_cache} -`IGNORE_PLAN_CACHE()`ヒントは、現在の`prepare`ステートメントを処理するときにプラン キャッシュを使用しないようにオプティマイザーに通知します。 +`IGNORE_PLAN_CACHE()`ヒントは、現在の`prepare`ステートメントを処理するときにプランキャッシュを使用しないようにオプティマイザーに通知します。 -このヒントは、 [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)有効な場合に、特定の種類のクエリのプラン キャッシュを一時的に無効にするために使用されます。 +このヒントは、 [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)有効な場合に、特定の種類のクエリのプランキャッシュを一時的に無効にするために使用されます。 -次の例では、 `prepare`ステートメントを実行するときにプラン キャッシュが強制的に無効になります。 +次の例では、 `prepare`ステートメントを実行するときにプランキャッシュが強制的に無効になります。 ```sql prepare stmt from 'select /*+ IGNORE_PLAN_CACHE() */ * from t where t.id = ?'; diff --git a/overview.md b/overview.md index faae89858befc..9ab7ad4f3bcf8 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..bb9d9faf8f438 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -1,6 +1,6 @@ --- title: Partition Pruning -summary: TiDB パーティション プルーニングの使用シナリオについて学習します。 +summary: TiDB パーティションプルーニングの使用シナリオについて学習します。 --- # パーティションプルーニング {#partition-pruning} @@ -39,15 +39,15 @@ EXPLAIN SELECT * FROM t1 WHERE id BETWEEN 80 AND 120; ## パーティションプルーニングの使用シナリオ {#usage-scenarios-of-partition-pruning} -パーティション プルーニングの使用シナリオは、範囲パーティション テーブルとハッシュ パーティション テーブルという 2 種類のパーティション テーブルで異なります。 +パーティションプルーニングの使用シナリオは、範囲パーティションテーブルとハッシュパーティションテーブルという 2 種類のパーティションテーブルで異なります。 ### ハッシュパーティションテーブルでパーティションプルーニングを使用する {#use-partition-pruning-in-hash-partitioned-tables} -このセクションでは、ハッシュ パーティション テーブルでのパーティション プルーニングの適用可能な使用シナリオと適用できない使用シナリオについて説明します。 +このセクションでは、ハッシュパーティションテーブルでのパーティションプルーニングの適用可能な使用シナリオと適用できない使用シナリオについて説明します。 #### ハッシュパーティションテーブルに適用可能なシナリオ {#applicable-scenario-in-hash-partitioned-tables} -パーティション プルーニングは、ハッシュ パーティション テーブル内の等価比較のクエリ条件にのみ適用されます。 +パーティションプルーニングは、ハッシュパーティションテーブル内の等価比較のクエリ条件にのみ適用されます。 ```sql create table t (x int) partition by hash(x) partitions 4; @@ -68,7 +68,7 @@ explain select * from t where x = 1; #### ハッシュパーティションテーブルに適用されないシナリオ {#inapplicable-scenarios-in-hash-partitioned-tables} -このセクションでは、ハッシュ パーティション テーブルでのパーティション プルーニングの適用されない 2 つの使用シナリオについて説明します。 +このセクションでは、ハッシュパーティションテーブルでのパーティションプルーニングの適用されない 2 つの使用シナリオについて説明します。 ##### シナリオ1 {#scenario-one} @@ -99,7 +99,7 @@ explain select * from t where x > 2; +------------------------------+----------+-----------+-----------------------+--------------------------------+ ``` -この場合、対応するハッシュ パーティションが`x > 2`条件によって確認できないため、パーティション プルーニングは適用できません。 +この場合、対応するハッシュパーティションが`x > 2`条件によって確認できないため、パーティションプルーニングは適用できません。 ##### シナリオ2 {#scenario-two} @@ -135,11 +135,11 @@ explain select * from t2 where x = (select * from t1 where t2.x = t1.x and t2.x ### 範囲パーティション化されたテーブルでパーティションプルーニングを使用する {#use-partition-pruning-in-range-partitioned-tables} -このセクションでは、範囲パーティション化されたテーブルでのパーティション プルーニングの適用可能な使用シナリオと適用できない使用シナリオについて説明します。 +このセクションでは、範囲パーティション化されたテーブルでのパーティションプルーニングの適用可能な使用シナリオと適用できない使用シナリオについて説明します。 #### 範囲パーティションテーブルに適用可能なシナリオ {#applicable-scenarios-in-range-partitioned-tables} -このセクションでは、範囲パーティション化されたテーブルでのパーティション プルーニングの適用可能な 3 つの使用シナリオについて説明します。 +このセクションでは、範囲パーティション化されたテーブルでのパーティションプルーニングの適用可能な 3 つの使用シナリオについて説明します。 ##### シナリオ1 {#scenario-one} @@ -220,7 +220,7 @@ explain select * from t where x between 7 and 14; ##### シナリオ3 {#scenario-three} -パーティション プルーニングは、パーティション式が`fn(col)`という単純な形式であり、クエリ条件が`>` 、 `<` 、 `=` 、 `>=` 、 `<=`のいずれかであり、 `fn`関数が単調であるシナリオに適用されます。 +パーティションプルーニングは、パーティション式が`fn(col)`という単純な形式であり、クエリ条件が`>` 、 `<` 、 `=` 、 `>=` 、 `<=`のいずれかであり、 `fn`関数が単調であるシナリオに適用されます。 `fn`関数が単調である場合、任意の`x`と`y`に対して、また`x > y`であれば`fn(x) > fn(y)` 。したがって、この`fn`関数は厳密に単調であると言えます。任意の`x`と`y`に対して、 `x > y`であれば`fn(x) >= fn(y)` 。この場合、 `fn` 「単調」と言えるでしょう。理論的には、厳密に単調であるかどうかにかかわらず、すべての単調関数がパーティションプルーニングによってサポートされます。現在、TiDBは次の単調関数のみをサポートしています。 @@ -228,7 +228,7 @@ explain select * from t where x between 7 and 14; - [`TO_DAYS()`](/functions-and-operators/date-and-time-functions.md) - [`EXTRACT(
    コンフィグレーションファイルコンフィグレーションタイプを変更説明
    TiDBstmt-summary.enable
    stmt-summary.enable-internal-query
    stmt-summary.history-size
    stmt-summary.max-sql-length
    stmt-summary.max-stmt-count
    stmt-summary.refresh-interval    		削除済みステートメントサマリーテーブルに関連するコンフィグレーション。これらの設定項目はすべて削除されました。ステートメントサマリーテーブルを制御するには、SQL変数を使用する必要があります。
    TiDBnew_collations_enabled_on_first_bootstrap変更新しい照合順序のサポートを有効にするかどうかを制御します。バージョン6.0以降、デフォルト値はfalseからtrueに変更されました。この設定項目は、クラスターが初めて初期化されたときにのみ有効になります。最初のブートストラップ後は、この設定項目を使用して新しい照合順序順序フレームワークを有効化または無効化することはできません。
    TiKVbackup.num-threads変更値の範囲は[1, CPU]に変更されます。
    TiKVraftstore.apply-max-batch-size変更最大値は10240に変更されます。
    TiKVraftstore.raft-max-size-per-msg変更最小値が0から0より大きい値に変更されます。
    最大値は3GBに設定されています。
    単位がMBからKB|MB|GBに変更されます。
    TiKVraftstore.store-max-batch-size変更最大値は10240に設定されています。
    TiKVreadpool.unified.max-thread-count変更調整可能な範囲は[min-thread-count, MAX(4, CPU)]に変更されます。
    TiKVrocksdb.enable-pipelined-write変更デフォルト値がtrueからfalseに変更されました。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。
    TiKVrocksdb.max-background-flushes変更CPU コア数が 10 の場合、デフォルト値は3です。
    CPU コア数が 8 の場合、デフォルト値は2です。
    TiKVrocksdb.max-background-jobs変更CPU コア数が 10 の場合、デフォルト値は9です。
    CPU コア数が 8 の場合、デフォルト値は7です。
    TiFlashprofiles.default.dt_enable_logical_split変更DeltaTreeストレージエンジンのセグメントが論理分割を使用するかどうかを決定します。デフォルト値はtrueからfalseに変更されます。
    TiFlashprofiles.default.enable_elastic_threadpool変更エラスティックスレッドプールを有効にするかどうかを制御します。デフォルト値はfalseからtrueに変更されます。
    TiFlashstorage.format_version変更TiFlashのデータ検証機能を制御します。デフォルト値は2から3に変更されます。
    format_version 3に設定すると、ハードウェア障害による誤った読み取りを回避するために、すべてのTiFlashデータの読み取り操作に対して一貫性チェックが実行されます。
    新しい形式のバージョンは、v5.4 より前のバージョンにそのままダウングレードすることはできないことに注意してください。
    TiDBpessimistic-txn.pessimistic-auto-commit新しく追加された悲観的トランザクション モードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクション モードを決定します。
    TiKVpessimistic-txn.in-memory新しく追加されたインメモリ悲観的ロックを有効にするかどうかを制御します。この機能を有効にすると、悲観的トランザクションは、悲観的ロックをディスクに書き込んだり他のレプリカに複製したりするのではなく、可能な限りTiKVメモリに悲観的ロックを保存します。これにより、悲観的トランザクションのパフォーマンスが向上しますが、悲観的ロックが失われる可能性がわずかながらあり、その結果、悲観的トランザクションがコミットに失敗する可能性があります。デフォルト値はtrueです。
    TiKVquota新しく追加されたフロントエンドリクエストが占有するリソースを制限するQuota Limiter関連の設定項目を追加しました。Quota Limiterは実験的機能であり、デフォルトでは無効になっています。新しいクォータ関連の設定項目は、 foreground-cpu-time 、 foreground-write-bandwidth 、 foreground-read-bandwidth 、 max-delay-durationです。
    TiFlashprofiles.default.dt_compression_method新しく追加されたTiFlashの圧縮アルゴリズムを指定します。オプションの値はLZ4 、 zstd 、 LZ4HCで、いずれも大文字と小文字は区別されません。デフォルト値はLZ4です。
    TiFlashprofiles.default.dt_compression_level新しく追加されたTiFlashの圧縮レベルを指定します。デフォルト値は1です。
    DM loaders.<name>.import-mode新しく追加されたフルインポートフェーズにおけるインポートモード。v6.0以降、DMはフルインポートフェーズでTiDB LightningのTiDBバックエンドモードを使用してデータをインポートします。以前のLoaderコンポーネントは使用されなくなりました。これは内部的な置き換えであり、日常業務への影響は見られません。
    デフォルト値はsqlに設定されており、これはtidb-backendモードを使用することを意味します。稀に、tidb-backendは完全な互換性を持たない場合があります。このパラメータをloaderに設定することで、Loaderモードにフォールバックできます。
    DM loaders.<name>.on-duplicate新しく追加されたフルインポートフェーズで競合を解決する方法を指定します。デフォルト値はreplaceで、これは新しいデータを使用して既存のデータを置き換えることを意味します。
    TiCDC dial-timeout新しく追加された下流のKafkaとの接続を確立する際のタイムアウト。デフォルト値は10sです。
    TiCDC read-timeout新しく追加された下流のKafkaから返されるレスポンスを取得する際のタイムアウト。デフォルト値は10sです。
    TiCDC write-timeout新しく追加された下流のKafkaにリクエストを送信する際のタイムアウト。デフォルト値は10sです。
    +
    コンフィグレーションファイルコンフィグレーションタイプを変更説明
    TiDBstmt-summary.enable
    stmt-summary.enable-internal-query
    stmt-summary.history-size
    stmt-summary.max-sql-length
    stmt-summary.max-stmt-count
    stmt-summary.refresh-interval    		削除済みステートメントサマリーテーブルに関連するコンフィグレーション。これらの設定項目はすべて削除されました。ステートメントサマリーテーブルを制御するには、SQL変数を使用する必要があります。
    TiDBnew_collations_enabled_on_first_bootstrap変更新しい照合順序のサポートを有効にするかどうかを制御します。バージョン6.0以降、デフォルト値はfalseからtrueに変更されました。この設定項目は、クラスターが初めて初期化されたときにのみ有効になります。最初のブートストラップ後は、この設定項目を使用して新しい照合順序順序フレームワークを有効化または無効化することはできません。
    TiKVbackup.num-threads変更値の範囲は[1, CPU]に変更されます。
    TiKVraftstore.apply-max-batch-size変更最大値は10240に変更されます。
    TiKVraftstore.raft-max-size-per-msg変更最小値が0から0より大きい値に変更されます。
    最大値は3GBに設定されています。
    単位がMBからKB|MB|GBに変更されます。
    TiKVraftstore.store-max-batch-size変更最大値は10240に設定されています。
    TiKVreadpool.unified.max-thread-count変更調整可能な範囲は[min-thread-count, MAX(4, CPU)]に変更されます。
    TiKVrocksdb.enable-pipelined-write変更デフォルト値がtrueからfalseに変更されました。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。
    TiKVrocksdb.max-background-flushes変更CPU コア数が 10 の場合、デフォルト値は3です。
    CPU コア数が 8 の場合、デフォルト値は2です。
    TiKVrocksdb.max-background-jobs変更CPU コア数が 10 の場合、デフォルト値は9です。
    CPU コア数が 8 の場合、デフォルト値は7です。
    TiFlashprofiles.default.dt_enable_logical_split変更DeltaTreeストレージエンジンのセグメントが論理分割を使用するかどうかを決定します。デフォルト値はtrueからfalseに変更されます。
    TiFlashprofiles.default.enable_elastic_threadpool変更エラスティックスレッドプールを有効にするかどうかを制御します。デフォルト値はfalseからtrueに変更されます。
    TiFlashstorage.format_version変更TiFlashのデータ検証機能を制御します。デフォルト値は2から3に変更されます。
    format_version 3に設定すると、ハードウェア障害による誤った読み取りを回避するために、すべてのTiFlashデータの読み取り操作に対して一貫性チェックが実行されます。
    新しい形式のバージョンは、v5.4 より前のバージョンにそのままダウングレードすることはできないことに注意してください。
    TiDBpessimistic-txn.pessimistic-auto-commit新しく追加された悲観的トランザクションモードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクションモードを決定します。
    TiKVpessimistic-txn.in-memory新しく追加されたインメモリ悲観的ロックを有効にするかどうかを制御します。この機能を有効にすると、悲観的トランザクションは、悲観的ロックをディスクに書き込んだり他のレプリカに複製したりするのではなく、可能な限りTiKVメモリに悲観的ロックを保存します。これにより、悲観的トランザクションのパフォーマンスが向上しますが、悲観的ロックが失われる可能性がわずかながらあり、その結果、悲観的トランザクションがコミットに失敗する可能性があります。デフォルト値はtrueです。
    TiKVquota新しく追加されたフロントエンドリクエストが占有するリソースを制限するQuota Limiter関連の設定項目を追加しました。Quota Limiterは実験的機能であり、デフォルトでは無効になっています。新しいクォータ関連の設定項目は、 foreground-cpu-time 、 foreground-write-bandwidth 、 foreground-read-bandwidth 、 max-delay-durationです。
    TiFlashprofiles.default.dt_compression_method新しく追加されたTiFlashの圧縮アルゴリズムを指定します。オプションの値はLZ4 、 zstd 、 LZ4HCで、いずれも大文字と小文字は区別されません。デフォルト値はLZ4です。
    TiFlashprofiles.default.dt_compression_level新しく追加されたTiFlashの圧縮レベルを指定します。デフォルト値は1です。
    DM loaders.<name>.import-mode新しく追加されたフルインポートフェーズにおけるインポートモード。v6.0以降、DMはフルインポートフェーズでTiDB LightningのTiDBバックエンドモードを使用してデータをインポートします。以前のLoaderコンポーネントは使用されなくなりました。これは内部的な置き換えであり、日常業務への影響は見られません。
    デフォルト値はsqlに設定されており、これはtidb-backendモードを使用することを意味します。稀に、tidb-backendは完全な互換性を持たない場合があります。このパラメータをloaderに設定することで、Loaderモードにフォールバックできます。
    DM loaders.<name>.on-duplicate新しく追加されたフルインポートフェーズで競合を解決する方法を指定します。デフォルト値はreplaceで、これは新しいデータを使用して既存のデータを置き換えることを意味します。
    TiCDC dial-timeout新しく追加された下流のKafkaとの接続を確立する際のタイムアウト。デフォルト値は10sです。
    TiCDC read-timeout新しく追加された下流のKafkaから返されるレスポンスを取得する際のタイムアウト。デフォルト値は10sです。
    TiCDC write-timeout新しく追加された下流のKafkaにリクエストを送信する際のタイムアウト。デフォルト値は10sです。
    ### その他 {#others} @@ -447,7 +447,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - サーバーの再起動後にパーティションテーブルの一覧表示でパーティションテーブルのプルーニングが機能しない可能性があるバグを修正[＃32416](https://github.com/pingcap/tidb/issues/32416) - `SET timestamp`の後に`add column`で間違ったデフォルトのタイムスタンプが使用される可能性があるバグを修正[＃31968](https://github.com/pingcap/tidb/issues/31968) - MySQL 5.5 または 5.6 クライアントから TiDB パスワードなしアカウントへの接続が失敗する可能性があるバグを修正[＃32334](https://github.com/pingcap/tidb/issues/32334) - - トランザクションで動的モードでパーティション テーブルを読み取るときに誤った結果が発生する問題を修正しました。 [＃29851](https://github.com/pingcap/tidb/issues/29851) + - トランザクションで動的モードでパーティションテーブルを読み取るときに誤った結果が発生する問題を修正しました。 [＃29851](https://github.com/pingcap/tidb/issues/29851) - TiDBが重複したタスクをTiFlash にディスパッチする可能性があるバグを修正しました [＃32814](https://github.com/pingcap/tidb/issues/32814) - `timdiff`関数の入力にミリ秒が含まれている場合に返される誤った結果を修正[＃31680](https://github.com/pingcap/tidb/issues/31680) - パーティションを明示的に読み取り、IndexJoin プランを使用した場合に誤った結果が発生する問題を修正しました。 [＃32007](https://github.com/pingcap/tidb/issues/32007) diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 151ed908fa936..0399ded8840a0 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -95,11 +95,11 @@ TiDB バージョン: 6.1.0 [ユーザードキュメント](/tiflash/tiflash-supported-pushdown-calculations.md) [＃4679](https://github.com/pingcap/tiflash/issues/4679) [＃4678](https://github.com/pingcap/tiflash/issues/4678) [＃4677](https://github.com/pingcap/tiflash/issues/4677) -- TiFlash は、動的プルーニング モードでパーティション化されたテーブルをサポートします。 +- TiFlash は、動的プルーニングモードでパーティション化されたテーブルをサポートします。 OLAPシナリオにおけるパフォーマンス向上のため、パーティションテーブルでは動的プルーニングモードがサポートされています。TiDBをv6.0.0より前のバージョンからアップグレードする場合は、パフォーマンスを最大限に高めるために、既存のパーティションテーブルの統計情報を手動で更新することをお勧めします（新規インストールの場合、またはv6.1.0へのアップグレード後に新しく作成されたパーティションの場合は必要ありません）。 - [＃3873](https://github.com/pingcap/tiflash/issues/3873) [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode) : [MPP モードでパーティション テーブルにアクセスする](/tiflash/use-tiflash-mpp-mode.md#access-partitioned-tables-in-the-mpp-mode) + [＃3873](https://github.com/pingcap/tiflash/issues/3873) [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode) : [MPP モードでパーティションテーブルにアクセスする](/tiflash/use-tiflash-mpp-mode.md#access-partitioned-tables-in-the-mpp-mode) ### 安定性 {#stability} @@ -242,7 +242,7 @@ TiDB バージョン: 6.1.0 | [`tidb_enable_new_only_full_group_by_check`](/system-variables.md#tidb_enable_new_only_full_group_by_check-new-in-v610) | 新しく追加された | この変数は、TiDB が`ONLY_FULL_GROUP_BY`チェックを実行するときの動作を制御します。 | | [`tidb_enable_outer_join_reorder`](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610) | 新しく追加された | バージョン6.1.0以降、TiDBの結合したテーブルの再配置アルゴリズムは外部結合をサポートしています。この変数はサポートの動作を制御し、デフォルト値は`ON`です。 | | [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) | 新しく追加された | この設定は以前は`tidb.toml`オプション ( `prepared-plan-cache.enabled` ) でしたが、TiDB v6.1.0 以降ではシステム変数に変更されました。 | -| [`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) | 新しく追加された | この変数は、コミットされていないトランザクションによってブロックされる GC セーフ ポイントの最大時間を設定するために使用されます。 | +| [`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) | 新しく追加された | この変数は、コミットされていないトランザクションによってブロックされる GC セーフポイントの最大時間を設定するために使用されます。 | | [tidb_max_auto_analyze_time](/system-variables.md#tidb_max_auto_analyze_time-new-in-v610) | 新しく追加された | This variable is used to specify the maximum execution time of auto analyze. | | [`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) | 新しく追加された | この変数は、 TiFlash がリクエストを実行するための最大同時実行性を設定するために使用されます。 | | [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610) | 新しく追加された | この設定は以前は`tidb.toml`オプション ( `oom-action` ) でしたが、TiDB v6.1.0 以降ではシステム変数に変更されました。 | @@ -274,7 +274,7 @@ TiDB バージョン: 6.1.0 | TiKV | [`coprocessor.region-bucket-size`](/tikv-configuration-file.md#region-bucket-size-new-in-v610) | 新しく追加された | The size of a bucket when `enable-region-bucket` is true. | | TiKV | [`causal-ts.renew-batch-min-size`](/tikv-configuration-file.md#renew-batch-min-size) | 新しく追加された | ローカルにキャッシュされるタイムスタンプの最小数。 | | TiKV | [`causal-ts.renew-interval`](/tikv-configuration-file.md#renew-interval) | 新しく追加された | The interval at which the locally cached timestamps are refreshed. | -| TiKV | [`max-snapshot-file-raw-size`](/tikv-configuration-file.md#max-snapshot-file-raw-size-new-in-v610) | 新しく追加された | スナップショット ファイルのサイズがこの値を超えると、スナップショット ファイルは複数のファイルに分割されます。 | +| TiKV | [`max-snapshot-file-raw-size`](/tikv-configuration-file.md#max-snapshot-file-raw-size-new-in-v610) | 新しく追加された | スナップショットファイルのサイズがこの値を超えると、スナップショットファイルは複数のファイルに分割されます。 | | TiKV | [`raft-engine.memory-limit`](/tikv-configuration-file.md#memory-limit) | 新しく追加された | Raft Engineのメモリ使用量の制限を指定します。 | | TiKV | [`storage.background-error-recovery-window`](/tikv-configuration-file.md#background-error-recovery-window-new-in-v610) | 新しく追加された | The maximum recovery time is allowed after RocksDB detects a recoverable background error. | | TiKV | [`storage.api-version`](/tikv-configuration-file.md#api-version-new-in-v610) | 新しく追加された | TiKV が生のキー値ストアとして機能するときに TiKV によって使用されるストレージ形式とインターフェース バージョン。 | @@ -284,7 +284,7 @@ TiDB バージョン: 6.1.0 | TiCDC | [`avro-decimal-handling-mode`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)
    [`avro-bigint-unsigned-handling-mode`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka) | 新しく追加された | Determines the output details of Avro format. | | TiCDC | [`dispatchers.topic`](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink) | 新しく追加された | TiCDC が増分データをさまざまな Kafka トピックに送信する方法を制御します。 | | TiCDC | [`dispatchers.partition`](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink) | 新しく追加された | `dispatchers.partition`は`dispatchers.dispatcher`の別名です。TiCDC が増分データを Kafka パーティションに送信する方法を制御します。 | -| TiCDC | [`schema-registry`](/ticdc/ticdc-sink-to-kafka.md#integrate-ticdc-with-kafka-connect-confluent-platform) | 新しく追加された | Avro スキーマを保存するスキーマ レジストリ エンドポイントを指定します。 | +| TiCDC | [`schema-registry`](/ticdc/ticdc-sink-to-kafka.md#integrate-ticdc-with-kafka-connect-confluent-platform) | 新しく追加された | Avro スキーマを保存するスキーマレジストリ エンドポイントを指定します。 | | DM | `dmctl start-relay`コマンドの`worker` | 削除済み | このパラメータの使用は推奨されません。よりシンプルな実装を提供します。 | | DM | `relay-dir` in the source configuration file | 削除済み | ワーカー構成ファイル内の同じ構成項目に置き換えられます。 | | DM | タスク設定ファイル内の`is-sharding` | 削除済み | `shard-mode`構成項目に置き換えられました。 | diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index c32a42bc7eee6..f93ed03879999 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -80,13 +80,13 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - CTE スキーマハッシュコードが誤って複製され、CTE が複数回参照されると`Can't find column ... in schema ...`エラーが発生する問題を修正しました[＃35404](https://github.com/pingcap/tidb/issues/35404) @[AilinKid](https://github.com/AilinKid) - 一部の右外部結合シナリオで結合順序が間違っていると、間違ったクエリ結果が発生する問題を修正しました。 [＃36912](https://github.com/pingcap/tidb/issues/36912) @[winoros](https://github.com/winoros) - EqualAll の場合でTiFlash `firstrow`集計関数の誤って推論された null フラグの問題を修正しました [＃34584](https://github.com/pingcap/tidb/issues/34584) @[fixdb](https://github.com/fixdb) - - `IGNORE_PLAN_CACHE`ヒントでバインディングを作成するとプラン キャッシュが機能しない問題を修正しました [＃34596](https://github.com/pingcap/tidb/issues/34596) @[fzzf678](https://github.com/fzzf678) + - `IGNORE_PLAN_CACHE`ヒントでバインディングを作成するとプランキャッシュが機能しない問題を修正しました [＃34596](https://github.com/pingcap/tidb/issues/34596) @[fzzf678](https://github.com/fzzf678) - ハッシュパーティションウィンドウと単一パーティションウィンドウの間に`EXCHANGE`演算子が欠落している問題を修正しました。 [＃35990](https://github.com/pingcap/tidb/issues/35990) @[LittleFall](https://github.com/LittleFall) - パーティションテーブルがインデックスを完全に使用してデータをスキャンできない場合がある問題を修正[#33966](https://github.com/pingcap/tidb/issues/33966) @[mjonss](https://github.com/mjonss) - 集計がプッシュダウンされた後に部分集計に間違ったデフォルト値が設定された場合の間違ったクエリ結果の問題を修正しました [＃35295](https://github.com/pingcap/tidb/issues/35295) @[tiancaiamao](https://github.com/tiancaiamao) - パーティションテーブルをクエリすると、場合によってはで`index-out-of-range`エラーが発生する可能性がある問題を修正しました。 [＃35181](https://github.com/pingcap/tidb/issues/35181) @[mjonss](https://github.com/mjonss) - クエリ条件でパーティションキーが使用され、照合順序がクエリパーティションテーブルの照合順序と異なる場合にパーティションが誤ってプルーニングされる問題を修正しました。 [＃32749](https://github.com/pingcap/tidb/issues/32749) @[mjonss](https://github.com/mjonss) - - TiDB Binlogが有効な場合、 `ALTER SEQUENCE`文を実行するとメタデータ バージョンが間違って発生し、 Drainer が終了する可能性がある問題を修正しました。 [#36276](https://github.com/pingcap/tidb/issues/36276) @[AilinKid](https://github.com/AilinKid) + - TiDB Binlogが有効な場合、 `ALTER SEQUENCE`文を実行するとメタデータバージョンが間違って発生し、 Drainer が終了する可能性がある問題を修正しました。 [#36276](https://github.com/pingcap/tidb/issues/36276) @[AilinKid](https://github.com/AilinKid) - 極端なケースで起動時に誤った TiDB ステータスが表示される問題を修正[＃36791](https://github.com/pingcap/tidb/issues/36791) @[xhebox](https://github.com/xhebox) - TiDB Dashboardでパーティションテーブルの実行計画をクエリするときに発生する可能性のある`UnknownPlanID`問題を修正しました。 [＃35153](https://github.com/pingcap/tidb/issues/35153) @[time-and-fate](https://github.com/time-and-fate) - LOAD DATA ステートメントでカラムリストが機能しない問題を修正しました [＃35198](https://github.com/pingcap/tidb/issues/35198) @[SpadeA-Tang](https://github.com/SpadeA-Tang) diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index a5ae1a817acc8..30770c54cfff0 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -77,9 +77,9 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - TiDB Data Migration (DM) - DMタスクが同期ユニットに入り、中断されると上流のテーブル構造情報が失われる問題を修正[#7159](https://github.com/pingcap/tiflow/issues/7159) @[lance6716](https://github.com/lance6716) - - チェックポイントを保存するときに SQL ステートメントを分割して、大規模なトランザクション エラーを修正します。 [＃5010](https://github.com/pingcap/tiflow/issues/5010) @[lance6716](https://github.com/lance6716) + - チェックポイントを保存するときに SQL ステートメントを分割して、大規模なトランザクションエラーを修正します。 [＃5010](https://github.com/pingcap/tiflow/issues/5010) @[lance6716](https://github.com/lance6716) - DM事前チェックに`INFORMATION_SCHEMA` の`SELECT`権限が必要になる問題を修正 [＃7317](https://github.com/pingcap/tiflow/issues/7317) @[lance6716](https://github.com/lance6716) - - 高速/完全バリデータで DM タスクを実行した後に DM ワーカーがデッドロック エラーをトリガーする問題を修正しました [＃7241](https://github.com/pingcap/tiflow/issues/7241) @[buchuitoudegou](https://github.com/buchuitoudegou) + - 高速/完全バリデータで DM タスクを実行した後に DM ワーカーがデッドロックエラーをトリガーする問題を修正しました [＃7241](https://github.com/pingcap/tiflow/issues/7241) @[buchuitoudegou](https://github.com/buchuitoudegou) - DMが`Specified key was too long`エラーを報告する問題を修正 [＃5315](https://github.com/pingcap/tiflow/issues/5315) @[lance6716](https://github.com/lance6716) - レプリケーション中に latin1 データが破損する可能性がある問題を修正しました [＃7028](https://github.com/pingcap/tiflow/issues/7028) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-6.1.7.md b/releases/release-6.1.7.md index 0f6693fc74353..1d95c35e1582c 100644 --- a/releases/release-6.1.7.md +++ b/releases/release-6.1.7.md @@ -39,7 +39,7 @@ TiDB バージョン: 6.1.7 - 特定のケースにおける TiDB のpanic問題を修正[＃40857](https://github.com/pingcap/tidb/issues/40857) @[Dousir9](https://github.com/Dousir9) - SQLコンパイルエラーログが秘匿化されない問題を修正[＃41831](https://github.com/pingcap/tidb/issues/41831) @[lance6716](https://github.com/lance6716) - テーブルパーティション定義で`FLOOR()`関数を使用してパーティション列を丸めた場合、 `SELECT`ステートメントがパーティションテーブルに対してエラーを返す問題を修正しました。 [＃42323](https://github.com/pingcap/tidb/issues/42323) @[jiyfhust](https://github.com/jiyfhust) - - リージョン分割中にパーティション テーブルをクエリするとエラーが発生する可能性がある問題を修正しました。 [＃43144](https://github.com/pingcap/tidb/issues/43144) @[lcwangchao](https://github.com/lcwangchao) + - リージョン分割中にパーティションテーブルをクエリするとエラーが発生する可能性がある問題を修正しました。 [＃43144](https://github.com/pingcap/tidb/issues/43144) @[lcwangchao](https://github.com/lcwangchao) - 統計情報読み取り中に不要なメモリが使用される問題を修正 [＃42052](https://github.com/pingcap/tidb/issues/42052) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - 多数の空のパーティションテーブルを作成した後に過剰なメモリ使用が発生する問題を修正しました [＃44308](https://github.com/pingcap/tidb/issues/44308) @[hawkingrei](https://github.com/hawkingrei) - `tidb_opt_agg_push_down`有効になっている場合にクエリが誤った結果を返す可能性がある問題を修正[＃44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) @@ -52,7 +52,7 @@ TiDB バージョン: 6.1.7 - テーブル名の変更中に TiCDC が行の変更の一部を失う可能性がある問題を修正[＃43338](https://github.com/pingcap/tidb/issues/43338) @[tangenta](https://github.com/tangenta) - パーティション化されたテーブルにおける配置ルールの動作の問題を修正し、削除されたパーティションにおける配置ルールが正しく設定され、再利用されるようになりました[＃44116](https://github.com/pingcap/tidb/issues/44116) @[lcwangchao](https://github.com/lcwangchao) - `tidb_scatter_region`有効にすると、パーティションが切り捨てられた後にリージョンが自動的に分割されない問題を修正しました[＃43174](https://github.com/pingcap/tidb/issues/43174) [＃43028](https://github.com/pingcap/tidb/issues/43028) - - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) + - 多数のパーティションとTiFlashレプリカを持つパーティションテーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) - ウィンドウ関数をTiFlash にプッシュダウンする際の実行計画が正しくない問題を修正しました [＃43922](https://github.com/pingcap/tidb/issues/43922) @[gengliqi](https://github.com/gengliqi) - 非相関サブクエリを含むステートメントで共通テーブル式 (CTE) を使用すると誤った結果が返される可能性がある問題を修正しました [＃44051](https://github.com/pingcap/tidb/issues/44051) @[winoros](https://github.com/winoros) - カーソルフェッチで`memTracker`を使用するとメモリリークが発生する問題を修正[＃44254](https://github.com/pingcap/tidb/issues/44254) @[YangKeao](https://github.com/YangKeao) diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index fdf3e1bc39a58..570a00bbdadf8 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -23,9 +23,9 @@ TiDBバージョン: 6.2.0-DMR - 新しい並行DDLフレームワーク：DDLステートメントのブロックが減り、実行効率が向上します。 - TiKV は[CPU使用率を自動的に調整する](/tikv-configuration-file.md#background-quota-limiter)をサポートしており、安定した効率的なデータベース運用を保証します。 - [特定時点リカバリ（PITR）](/br/backup-and-restore-overview.md)は、過去の任意の時点から TiDB クラスターのスナップショットを新しいクラスターに復元するために導入されました。 -- TiDB Lightning は、クラスター レベルではなく、物理インポート モードでテーブル[テーブルレベルでのスケジューリングを一時停止する](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)をサポートしています。 +- TiDB Lightning は、クラスターレベルではなく、物理インポートモードでテーブル[テーブルレベルでのスケジューリングを一時停止する](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)をサポートしています。 - BR は[ユーザーおよび権限データの復元](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)サポートしており、バックアップと復元がよりスムーズになります。 -- TiCDC[特定の種類のDDLイベントをフィルタリングする](/ticdc/ticdc-filter.md)フィルタリングすることをサポートすることで、より多くのデータ レプリケーション シナリオを可能にします。 +- TiCDC[特定の種類のDDLイベントをフィルタリングする](/ticdc/ticdc-filter.md)フィルタリングすることをサポートすることで、より多くのデータレプリケーションシナリオを可能にします。 - [`SAVEPOINT`機構](/sql-statements/sql-statement-savepoint.md)がサポートされており、トランザクション内のロールバックポイントを柔軟に制御できます。 - TiDB は[1つの`ALTER TABLE`ステートメントだけで、複数の列またはインデックスの追加、削除、変更を行う](/sql-statements/sql-statement-alter-table.md)サポートしています。 - [クラスター間RawKV複製](/tikv-configuration-file.md#api-version-new-in-v610)サポートされるようになりました。 @@ -52,7 +52,7 @@ TiDBバージョン: 6.2.0-DMR - TiDB Dashboardにモニタリングページが追加されました - 新しいモニタリング ページには、パフォーマンス チューニングに必要な主要な指標が表示され、これに基づいて[データベース時間によるパフォーマンスチューニング](/performance-tuning-methods.md)を参照してパフォーマンスを分析および調整できます。 + 新しいモニタリング ページには、パフォーマンスチューニングに必要な主要な指標が表示され、これに基づいて[データベース時間によるパフォーマンスチューニング](/performance-tuning-methods.md)を参照してパフォーマンスを分析および調整できます。 具体的には、ユーザー応答時間とデータベース時間を全体的かつトップダウンの視点から分析することで、ユーザー応答時間のボトルネックがデータベースの問題によるものかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要とSQLレイテンシーの内訳を使用してボトルネックを特定し、パフォーマンスを調整できます。 @@ -289,8 +289,8 @@ TiDBバージョン: 6.2.0-DMR | TiKV | [rocksdb.lockcf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | | PD | レプリケーションモード.dr-auto-sync.wait-async-timeout | 削除済み | この設定は有効にならず、削除されます。 | | PD | レプリケーションモード.dr-auto-sync.wait-sync-timeout | 削除済み | この設定は有効にならず、削除されます。 | -| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 変更 | `format_version`のデフォルト値が`4`に変更されます。これは v6.2.0 以降のバージョンのデフォルト形式であり、書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 | -| TiFlash | [profiles.default.dt_enable_read_thread](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定は、ストレージエンジンからの読み取り要求を処理するためにスレッド プールを使用するかどうかを制御します。デフォルト値は`false`です。 | +| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 変更 | `format_version`のデフォルト値が`4`に変更されます。これは v6.2.0 以降のバージョンのデフォルト形式であり、書き込み増幅とバックグラウンドタスクのリソース消費を削減します。 | +| TiFlash | [profiles.default.dt_enable_read_thread](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定は、ストレージエンジンからの読み取り要求を処理するためにスレッドプールを使用するかどうかを制御します。デフォルト値は`false`です。 | | TiFlash | [profiles.default.dt_page_gc_threshold](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定では、PageStorageデータファイル内の有効データの最小比率を指定します。 | | TiCDC | [--overwrite-checkpoint-ts](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task) | 新しく追加された | この設定は`cdc cli changefeed resume`サブコマンドに追加されます。 | | TiCDC | [--確認しない](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task) | 新しく追加された | この設定は`cdc cli changefeed resume`サブコマンドに追加されます。 | @@ -304,7 +304,7 @@ TiDBバージョン: 6.2.0-DMR - TiFlash `format_version` `4`から`3`にダウングレードすることはできません。詳細については、 [TiFlashアップグレードガイド](/tiflash-upgrade-guide.md)を参照してください。 - バージョン6.2.0以降では、デフォルト値の`false`を`dt_enable_logical_split`のままにして、 `true`に変更しないことを強くお勧めします。詳細は、既知の問題[#5576](https://github.com/pingcap/tiflash/issues/5576)を参照してください。 -- バックアップ クラスタにTiFlashレプリカがある場合、PITR を実行すると、リストア クラスタにはTiFlashレプリカ内のデータが含まれません。TiFlash レプリカからデータをリストアするには、 TiFlashレプリカを手動で構成する必要があります。 `exchange partition` DDL ステートメントを実行すると、PITR が失敗する可能性があります。アップストリームデータベースが TiDB Lightning の物理インポート モードを使用してデータをインポートする場合、ログ バックアップでデータをバックアップできません。データ インポート後にフル バックアップを実行することをお勧めします。PITR のその他の互換性の問題については、 [PITRの制限](/br/backup-and-restore-overview.md#before-you-use)を参照してください。 +- バックアップ クラスタにTiFlashレプリカがある場合、PITR を実行すると、リストア クラスタにはTiFlashレプリカ内のデータが含まれません。TiFlash レプリカからデータをリストアするには、 TiFlashレプリカを手動で構成する必要があります。 `exchange partition` DDL ステートメントを実行すると、PITR が失敗する可能性があります。アップストリームデータベースが TiDB Lightning の物理インポートモードを使用してデータをインポートする場合、ログバックアップでデータをバックアップできません。データインポート後にフルバックアップを実行することをお勧めします。PITR のその他の互換性の問題については、 [PITRの制限](/br/backup-and-restore-overview.md#before-you-use)を参照してください。 - TiDB v6.2.0以降では、データ復元時に`mysql`パラメータを指定することで`--with-sys-table=true`スキーマのテーブルを復元できます。 - `ALTER TABLE`ステートメントを実行して複数の列またはインデックスを追加、削除、または変更する場合、TiDB は同じ DDL ステートメントの変更内容に関わらず、ステートメント実行前後のテーブルを比較してテーブルの一貫性をチェックします。DDL の実行順序は、シナリオによっては MySQL と完全には互換性がない場合があります。 - TiDBコンポーネントがv6.2.0以降の場合、TiKVコンポーネントはv6.2.0より前のバージョンであってはなりません。 @@ -331,7 +331,7 @@ TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非 - 一部のシステム変数に対する検証チェックを追加 [#35048](https://github.com/pingcap/tidb/issues/35048) @[morgo](https://github.com/morgo) - - 一部の型変換のエラー メッセージを最適化 [#32744](https://github.com/pingcap/tidb/issues/32744) @[fanrenhoo](https://github.com/fanrenhoo) + - 一部の型変換のエラーメッセージを最適化 [#32744](https://github.com/pingcap/tidb/issues/32744) @[fanrenhoo](https://github.com/fanrenhoo) - `KILL`コマンドが DDL 操作をサポートするようになりました [#24144](https://github.com/pingcap/tidb/issues/24144) @[morgo](https://github.com/morgo) @@ -347,7 +347,7 @@ TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非 - 一部の演算子 (HashJoin、HashAgg、Update、Delete) のメモリ追跡の精度を最適化しました ( [#35634](https://github.com/pingcap/tidb/issues/35634) 、 [#35631](https://github.com/pingcap/tidb/issues/35631) 、 [#35635](https://github.com/pingcap/tidb/issues/35635) @[wshwsh12](https://github.com/wshwsh12) ) ( [#34096](https://github.com/pingcap/tidb/issues/34096) @[ekexium](https://github.com/ekexium)) - - システム テーブル`INFORMATION_SCHEMA.DATA_LOCK_WAIT`楽観的トランザクションのロック情報の記録をサポートしています [#34609](https://github.com/pingcap/tidb/issues/34609) @[longfangsong](https://github.com/longfangsong) + - システムテーブル`INFORMATION_SCHEMA.DATA_LOCK_WAIT`楽観的トランザクションのロック情報の記録をサポートしています [#34609](https://github.com/pingcap/tidb/issues/34609) @[longfangsong](https://github.com/longfangsong) - トランザクションの監視メトリクスを追加 [#34456](https://github.com/pingcap/tidb/issues/34456) @[longfangsong](https://github.com/longfangsong) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 35f7ddff86d92..3187fd383e430 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -49,7 +49,7 @@ TiDBバージョン: 6.3.0-DMR - DDL変更時のDML成功率を向上させるための軽量メタデータロックを提供する（実験的） [#37275](https://github.com/pingcap/tidb/issues/37275) @[wjhuang2016](https://github.com/wjhuang2016) - TiDB は、変更されるメタデータ オブジェクトをサポートするために、オンライン非同期スキーマ変更アルゴリズムを使用します。トランザクションが実行されると、トランザクションの開始時に対応するメタデータ スナップショットを取得します。トランザクション中にメタデータが変更された場合、データの一貫性を確保するために、TiDB は`Information schema is changed`エラーを返し、トランザクションはコミットに失敗します。この問題を解決するために、TiDB v6.3.0 では、オンライン DDL アルゴリズムに[メタデータロック](/metadata-lock.md)が導入されました。可能な限り DML エラーを回避するために、TiDB はテーブル メタデータの変更中に DML と DDL の優先順位を調整し、実行中の DDL が古いメタデータを持つ DML のコミットを待つようにします。 + TiDB は、変更されるメタデータオブジェクトをサポートするために、オンライン非同期スキーマ変更アルゴリズムを使用します。トランザクションが実行されると、トランザクションの開始時に対応するメタデータスナップショットを取得します。トランザクション中にメタデータが変更された場合、データの一貫性を確保するために、TiDB は`Information schema is changed`エラーを返し、トランザクションはコミットに失敗します。この問題を解決するために、TiDB v6.3.0 では、オンライン DDL アルゴリズムに[メタデータロック](/metadata-lock.md)が導入されました。可能な限り DML エラーを回避するために、TiDB はテーブルメタデータの変更中に DML と DDL の優先順位を調整し、実行中の DDL が古いメタデータを持つ DML のコミットを待つようにします。 - インデックス追加のパフォーマンスを向上させ、DML トランザクションへの影響を軽減します (実験的) [#35983](https://github.com/pingcap/tidb/issues/35983) @[benjamin2037](https://github.com/benjamin2037) @@ -67,7 +67,7 @@ TiDBバージョン: 6.3.0-DMR - TiDB JDBC は SM3 アルゴリズムによる認証をサポート [#25](https://github.com/pingcap/mysql-connector-j/issues/25) @[lastincisor](https://github.com/lastincisor) - ユーザー パスワードの認証には、クライアント側のサポートが必要です。 [JDBCはSM3アルゴリズムをサポートしています](/develop/dev-guide-choose-driver-or-orm.md#java-drivers)ので、TiDB-JDBC経由でSM3認証を使用してTiDBに接続できるようになります。 + ユーザーパスワードの認証には、クライアント側のサポートが必要です。 [JDBCはSM3アルゴリズムをサポートしています](/develop/dev-guide-choose-driver-or-orm.md#java-drivers)ので、TiDB-JDBC経由でSM3認証を使用してTiDBに接続できるようになります。 ### 可観測性 {#observability} @@ -77,7 +77,7 @@ TiDBバージョン: 6.3.0-DMR - スローログと`TRACE`ステートメントの出力強化 [#34106](https://github.com/pingcap/tidb/issues/34106) @[cfzjywxk](https://github.com/cfzjywxk) - TiDB v6.3.0 では、スロー ログと`TRACE`の出力が強化されています。TiDB の解析から KV RocksDB によるディスクへの書き込みまでの SQL クエリの[フルリンク期間](/latency-breakdown.md)を観察できるため、診断機能がさらに強化されます。 + TiDB v6.3.0 では、スローログと`TRACE`の出力が強化されています。TiDB の解析から KV RocksDB によるディスクへの書き込みまでの SQL クエリの[フルリンク期間](/latency-breakdown.md)を観察できるため、診断機能がさらに強化されます。 - TiDB Dashboardはデッドロック履歴情報を提供します [#34106](https://github.com/pingcap/tidb/issues/34106) @[cfzjywxk](https://github.com/cfzjywxk) @@ -97,7 +97,7 @@ TiDBバージョン: 6.3.0-DMR この機能はバージョン6.2.0では実験的に提供されており、バージョン6.3.0で正式リリースとなります。 -- TiFlashデータ レプリケーションのパフォーマンスが向上 [#5237](https://github.com/pingcap/tiflash/issues/5237) @[breezewish](https://github.com/breezewish) +- TiFlashデータレプリケーションのパフォーマンスが向上 [#5237](https://github.com/pingcap/tiflash/issues/5237) @[breezewish](https://github.com/breezewish) TiFlashは、TiKVからのデータレプリケーションにRaftプロトコルを使用します。v6.3.0より前は、大量のレプリカデータのレプリケーションに時間がかかることがよくありました。TiDB v6.3.0では、 TiFlashのデータレプリケーションメカニズムが最適化され、レプリケーション速度が大幅に向上しました。BRを使用してデータをリカバリする場合、 TiDB Lightningを使用してデータをインポートする場合、または新しいTiFlashレプリカを追加する場合、 TiFlashレプリカのレプリケーションがより迅速に行われます。TiFlashを使用したクエリもより迅速に実行できます。さらに、 TiFlashレプリカのスケールアップ、スケールダウン、またはレプリカ数の変更時にも、 TiFlashレプリカはより迅速に安全でバランスの取れた状態に到達します。 @@ -113,7 +113,7 @@ TiDBバージョン: 6.3.0-DMR TiDB v6.3.0 では、新しい結合[ヌル値認識型アンチジョイン（NAAJ）](/explain-subqueries.md#null-aware-anti-semi-join-not-in-and--all-subqueries)が導入されています。 NAAJ は、コレクション操作を処理するときに、コレクションが空であるか、 `NULL`であるかを認識できます。これにより`IN`や`= ANY`などの操作の実行効率が最適化され、SQL パフォーマンスが向上します。 -- ハッシュ結合のビルド終了を制御するオプティマイザー ヒントを追加 [#35439](https://github.com/pingcap/tidb/issues/35439) @[Reminiscent](https://github.com/Reminiscent) +- ハッシュ結合のビルド終了を制御するオプティマイザーヒントを追加 [#35439](https://github.com/pingcap/tidb/issues/35439) @[Reminiscent](https://github.com/Reminiscent) バージョン6.3.0では、TiDBオプティマイザに、ハッシュ結合、そのプローブ終了、および構築終了を指定するための2つのヒント、 `HASH_JOIN_BUILD()`と`HASH_JOIN_PROBE()`が導入されました。オプティマイザが最適な実行計画を選択できない場合、これらのヒントを使用してプランに介入できます。 @@ -139,7 +139,7 @@ TiDBバージョン: 6.3.0-DMR - 統計情報が古くなった場合に統計情報を読み込むデフォルトポリシーを変更する [#27601](https://github.com/pingcap/tidb/issues/27601) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - v5.3.0 では、統計情報が古くなったときのオプティマイザの動作を制御するために、システム変数[`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530)が導入されました。デフォルト値は`ON`で、これは旧バージョンの動作を維持することを意味します。つまり、SQL ステートメントに関係するオブジェクトの統計情報が古くなった場合、オプティマイザは (テーブルの総行数以外の) 統計情報はもはや信頼できないと判断し、代わりに擬似統計情報を使用します。実際のユーザー シナリオのテストと分析の結果、v6.3.0 以降、デフォルト値`tidb_enable_pseudo_for_outdated_stats`は`OFF`に変更されました。統計情報が古くなっても、オプティマイザはテーブル上の統計情報を使用するため、実行計画がより安定します。 + v5.3.0 では、統計情報が古くなったときのオプティマイザの動作を制御するために、システム変数[`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-new-in-v530)が導入されました。デフォルト値は`ON`で、これは旧バージョンの動作を維持することを意味します。つまり、SQL ステートメントに関係するオブジェクトの統計情報が古くなった場合、オプティマイザは (テーブルの総行数以外の) 統計情報はもはや信頼できないと判断し、代わりに擬似統計情報を使用します。実際のユーザーシナリオのテストと分析の結果、v6.3.0 以降、デフォルト値`tidb_enable_pseudo_for_outdated_stats`は`OFF`に変更されました。統計情報が古くなっても、オプティマイザはテーブル上の統計情報を使用するため、実行計画がより安定します。 - Titan の無効化が GA に@[tabokie](https://github.com/tabokie) @@ -147,7 +147,7 @@ TiDBバージョン: 6.3.0-DMR - グローバル統計が準備できていない場合は、 `static`パーティションプルーニングを使用します [#37535](https://github.com/pingcap/tidb/issues/37535) @[Yisaer](https://github.com/Yisaer) - [`dynamic pruning`](/partitioned-table.md#dynamic-pruning-mode)が有効になっている場合、オプティマイザは[世界の統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)に基づいて実行計画を選択します。グローバル統計が完全に収集される前に擬似統計を使用すると、パフォーマンスが低下する可能性があります。v6.3.0 では、グローバル統計の収集が完了する前に`dynamic`プルーニング モードを有効にすると、グローバル統計が完全に収集されるまで TiDB は`static`モードのままになります。これにより、パーティション プルーニングの設定を変更したときのパフォーマンスの安定性が確保されます。 + [`dynamic pruning`](/partitioned-table.md#dynamic-pruning-mode)が有効になっている場合、オプティマイザは[世界の統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)に基づいて実行計画を選択します。グローバル統計が完全に収集される前に擬似統計を使用すると、パフォーマンスが低下する可能性があります。v6.3.0 では、グローバル統計の収集が完了する前に`dynamic`プルーニングモードを有効にすると、グローバル統計が完全に収集されるまで TiDB は`static`モードのままになります。これにより、パーティションプルーニングの設定を変更したときのパフォーマンスの安定性が確保されます。 ### 使いやすさ {#ease-of-use} @@ -181,7 +181,7 @@ TiDBバージョン: 6.3.0-DMR - BRは AWS S3 オブジェクト ロックをサポートします [#13442](https://github.com/tikv/tikv/issues/13442) @[3pointer](https://github.com/3pointer) - [S3オブジェクトロック](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)を有効にすることで、AWS 上のバックアップ データが改ざんまたは削除されないように保護できます。 + [S3オブジェクトロック](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)を有効にすることで、AWS 上のバックアップデータが改ざんまたは削除されないように保護できます。 ### データ移行 {#data-migration} @@ -195,11 +195,11 @@ TiDBバージョン: 6.3.0-DMR - TiCDCは、地理的に分散した複数のデータソースからデータを複製できるデプロイメントトポロジーをサポートしています [#5301](https://github.com/pingcap/tiflow/issues/5301) @[sdojjy](https://github.com/sdojjy) - v6.3.0 以降、単一の TiDB クラスターから複数の地理的に分散されたデータ システムへのデータの複製をサポートするために、 [TiCDCは複数のIDCに展開できます](/ticdc/deploy-ticdc.md) 。この機能は、地理的に分散されたデータ レプリケーションおよび展開トポロジの機能を提供するのに役立ちます。 + v6.3.0 以降、単一の TiDB クラスターから複数の地理的に分散されたデータ システムへのデータの複製をサポートするために、 [TiCDCは複数のIDCに展開できます](/ticdc/deploy-ticdc.md) 。この機能は、地理的に分散されたデータレプリケーションおよび展開トポロジの機能を提供するのに役立ちます。 - TiCDCは、アップストリームとダウンストリーム間でスナップショットの一貫性を維持することをサポートしています（同期ポイント） [#6977](https://github.com/pingcap/tiflow/issues/6977) @[asddongmen](https://github.com/asddongmen) - ディザスタリカバリのためのデータ レプリケーションのシナリオでは、TiCDC は、ダウンストリーム スナップショットがアップストリーム スナップショットと一貫性を保つように [定期的に下流データのスナップショットを維持する](/ticdc/ticdc-upstream-downstream-check.md)をサポートします。この機能により、TiCDC は読み取りと書き込みが分離されるシナリオをより適切にサポートし、コストの削減に役立ちます。 + ディザスタリカバリのためのデータレプリケーションのシナリオでは、TiCDC は、ダウンストリーム スナップショットがアップストリーム スナップショットと一貫性を保つように [定期的に下流データのスナップショットを維持する](/ticdc/ticdc-upstream-downstream-check.md)をサポートします。この機能により、TiCDC は読み取りと書き込みが分離されるシナリオをより適切にサポートし、コストの削減に役立ちます。 - TiCDC はグレースフル アップグレードをサポート [#4757](https://github.com/pingcap/tiflow/issues/4757) @[overvenus](https://github.com/overvenus)@[3AceShowHand](https://github.com/3AceShowHand) @@ -244,8 +244,8 @@ TiDBバージョン: 6.3.0-DMR | TiDB | [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) | 新しく追加された | TiDB が一時データを格納するために使用するファイルシステム上の場所を指定します。機能が TiDB ノードでローカルストレージを必要とする場合、TiDB は対応する一時データをこの場所に格納します。デフォルト値は`/tmp/tidb`です。 | | TiKV | [`auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630) | 新しく追加された | スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在のCPU使用率に基づいてUnifyReadPoolスレッドプールのサイズを自動的に調整することで、TiKVの読み取りパフォーマンスが最適化されます。 | | TiKV | [`data-encryption-method`](/tikv-configuration-file.md#data-encryption-method) | 変更 | 新しい値オプション`sm4-ctr`が導入されました。この設定項目が`sm4-ctr`に設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 | -| TiKV | [`enable-log-recycle`](/tikv-configuration-file.md#enable-log-recycle-new-in-v630) | 新しく追加された | Raft Engineで古いログ ファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログ ファイルは再利用のために予約されます。これにより、書き込みワークロードのロング テールレイテンシーが削減されます。この設定項目は[フォーマットバージョン](/tikv-configuration-file.md#format-version-new-in-v630)が 2 以上の場合のみ使用できます。 | -| TiKV | [`format-version`](/tikv-configuration-file.md#format-version-new-in-v630) | 新しく追加された | Raft Engineのログ ファイルのバージョンを指定します。デフォルトのログ ファイル バージョンは、TiKV v6.3.0 より前のバージョンでは`1`です。ログ ファイルは、TiKV >= v6.1.0 で読み取ることができます。デフォルトのログ ファイル バージョンは、TiKV v6.3.0 以降では`2`です。TiKV v6.3.0 以降では、ログ ファイルを読み取ることができます。 | +| TiKV | [`enable-log-recycle`](/tikv-configuration-file.md#enable-log-recycle-new-in-v630) | 新しく追加された | Raft Engineで古いログファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログファイルは再利用のために予約されます。これにより、書き込みワークロードのロングテールレイテンシーが削減されます。この設定項目は[フォーマットバージョン](/tikv-configuration-file.md#format-version-new-in-v630)が 2 以上の場合のみ使用できます。 | +| TiKV | [`format-version`](/tikv-configuration-file.md#format-version-new-in-v630) | 新しく追加された | Raft Engineのログファイルのバージョンを指定します。デフォルトのログファイル バージョンは、TiKV v6.3.0 より前のバージョンでは`1`です。ログファイルは、TiKV >= v6.1.0 で読み取ることができます。デフォルトのログファイル バージョンは、TiKV v6.3.0 以降では`2`です。TiKV v6.3.0 以降では、ログファイルを読み取ることができます。 | | TiKV | [`log-backup.enable`](/tikv-configuration-file.md#enable-new-in-v620) | 変更 | バージョン6.3.0以降、デフォルト値が`false`から`true`に変更されました。 | | TiKV | [`log-backup.max-flush-interval`](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 変更 | バージョン6.3.0以降、デフォルト値が`5min`から`3min`に変更されました。 | | PD | [診断を有効にする](/pd-configuration-file.md#enable-diagnostic-new-in-v630) | 新しく追加された | 診断機能を有効にするかどうかを制御します。デフォルト値は`false`です。 | @@ -357,7 +357,7 @@ TiDBバージョン: 6.3.0-DMR - JSON集計関数で単精度浮動小数点数が使用できない問題を修正 [#37287](https://github.com/pingcap/tidb/issues/37287) @[YangKeao](https://github.com/YangKeao) - `UNION`演算子が予期しない空の結果を返す可能性がある問題を修正 [#36903](https://github.com/pingcap/tidb/issues/36903) @[tiancaiamao](https://github.com/tiancaiamao) - `castRealAsTime`式の結果が MySQL と一致しない問題を修正します [#37462](https://github.com/pingcap/tidb/issues/37462) @[mengxin9014](https://github.com/mengxin9014) - - 悲観的DML 操作が非一意インデックス キーをロックする問題を修正 [#36235](https://github.com/pingcap/tidb/issues/36235) @[ekexium](https://github.com/ekexium) + - 悲観的DML 操作が非一意インデックスキーをロックする問題を修正 [#36235](https://github.com/pingcap/tidb/issues/36235) @[ekexium](https://github.com/ekexium) - `auto-commit`の変更がトランザクションコミットの動作に影響を与える問題を修正 [#36581](https://github.com/pingcap/tidb/issues/36581) @[cfzjywxk](https://github.com/cfzjywxk) - DML実行エンジンを使用した`EXPLAIN ANALYZE`ステートメントがトランザクションコミットが完了する前に結果を返す可能性がある問題を修正しました [#37373](https://github.com/pingcap/tidb/issues/37373) @[cfzjywxk](https://github.com/cfzjywxk) - UPDATE 文が場合によっては誤って投影を削除し、 `Can't find column` エラーが発生する問題を修正しました。 [#37568](https://github.com/pingcap/tidb/issues/37568) @[AilinKid](https://github.com/AilinKid) diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 0b1887c86ce93..f891ae603fc7d 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -47,7 +47,7 @@ TiDBバージョン: 6.4.0-DMR `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、 `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 - `FLASHBACK CLUSTER TO TIMESTAMP`を実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーション タスクを一時停止し、 `FLASHBACK`が完了した後に再開する必要があります。そうしないと、レプリケーション タスクが失敗する可能性があります。 + `FLASHBACK CLUSTER TO TIMESTAMP`を実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーションタスクを一時停止し、 `FLASHBACK`が完了した後に再開する必要があります。そうしないと、レプリケーションタスクが失敗する可能性があります。 詳細については、 [ユーザー向けドキュメント](/sql-statements/sql-statement-flashback-cluster.md)を参照してください。 @@ -77,7 +77,7 @@ TiDBバージョン: 6.4.0-DMR - コプロセッサタスクの同時実行適応メカニズムを導入します [#37724](https://github.com/pingcap/tidb/issues/37724) @[you06](https://github.com/you06) - TiKV の処理速度に基づいて、コプロセッサ タスクの数が増えると、TiDB は自動的に並列度を上げて ( [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)の値を調整して)、コプロセッサ タスク キューを減らし、レイテンシーを削減します。 + TiKV の処理速度に基づいて、コプロセッサタスクの数が増えると、TiDB は自動的に並列度を上げて ( [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)の値を調整して)、コプロセッサタスク キューを減らし、レイテンシーを削減します。 - テーブル結合順序を決定するための動的計画アルゴリズムを追加 [#37825](https://github.com/pingcap/tidb/issues/37825) @[winoros](https://github.com/winoros) @@ -99,7 +99,7 @@ TiDBバージョン: 6.4.0-DMR 詳細については、 [ユーザー向けドキュメント](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を参照してください。 -- 相関サブクエリの非相関化を実行するかどうかを制御する新しいオプティマイザー ヒント`NO_DECORRELATE`を導入します [#37789](https://github.com/pingcap/tidb/issues/37789) @[time-and-fate](https://github.com/time-and-fate) +- 相関サブクエリの非相関化を実行するかどうかを制御する新しいオプティマイザーヒント`NO_DECORRELATE`を導入します [#37789](https://github.com/pingcap/tidb/issues/37789) @[time-and-fate](https://github.com/time-and-fate) TiDB はデフォルトでは、相関のあるサブクエリを書き換えて相関解除を実行しようとします。これにより、通常は実行効率が向上します。しかし、シナリオによっては相関解除によって実行効率が低下する場合があります。v6.4.0 では、オプティマイザヒント`NO_DECORRELATE`が導入され、特定のクエリブロックに対して相関解除を実行しないようにオプティマイザに指示することで、シナリオによってはクエリのパフォーマンスが向上します。 @@ -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} @@ -199,7 +199,7 @@ TiDBバージョン: 6.4.0-DMR - データベースユーザー向けの追加説明の追加をサポート [#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)テーブルが追加され、ユーザーコメントやユーザー属性の情報を表示できるようになりました。 @@ -236,7 +236,7 @@ TiDBバージョン: 6.4.0-DMR - DMは、下流のマージ済みテーブルの拡張列に上流のデータソース情報を書き込むことをサポートしています [#37797](https://github.com/pingcap/tidb/issues/37797) @[lichunzhu](https://github.com/lichunzhu) - 上流から TiDB へシャーディングされたスキーマとテーブルをマージする際、ターゲット テーブルに複数のフィールド (拡張列) を手動で追加し、DM タスクの設定時にその値を指定できます。たとえば、拡張列に上流のシャーディングされたスキーマとテーブルの名前を指定すると、DM によって下流に書き込まれるデータにはスキーマ名とテーブル名が含まれます。下流のデータが通常と異なる場合、この機能を使用して、スキーマ名やテーブル名など、ターゲット テーブル内のデータ ソース情報をすばやく特定できます。 + 上流から TiDB へシャーディングされたスキーマとテーブルをマージする際、ターゲットテーブルに複数のフィールド (拡張列) を手動で追加し、DM タスクの設定時にその値を指定できます。たとえば、拡張列に上流のシャーディングされたスキーマとテーブルの名前を指定すると、DM によって下流に書き込まれるデータにはスキーマ名とテーブル名が含まれます。下流のデータが通常と異なる場合、この機能を使用して、スキーマ名やテーブル名など、ターゲットテーブル内のデータソース情報をすばやく特定できます。 詳細については、 [テーブル、スキーマ、ソース情報を抽出し、マージされたテーブルに書き込みます](/dm/dm-table-routing.md#extract-table-schema-and-source-information-and-write-into-the-merged-table) @@ -298,7 +298,7 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_external_ts`](/system-variables.md#tidb_external_ts-new-in-v640) | 新しく追加された | デフォルト値は`0`です。tidb_enable_external_ts_read [`tidb_enable_external_ts_read`](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) `ON`に設定されている場合、TiDB はこの変数で指定されたタイムスタンプを持つデータを読み取ります。 | | [`tidb_gogc_tuner_threshold`](/system-variables.md#tidb_gogc_tuner_threshold-new-in-v640) | 新しく追加された | GOGC のチューニングにおける最大メモリしきい値を指定します。メモリがこのしきい値を超えると、GOGC Tuner は動作を停止します。デフォルト値は`0.6`です。 | | [`tidb_memory_usage_alarm_keep_record_num`](/system-variables.md#tidb_memory_usage_alarm_keep_record_num-new-in-v640) | 新しく追加された | tidb-serverのメモリ使用量がメモリアラームのしきい値を超えてアラームが発生した場合、TiDBはデフォルトでは直近5件のアラーム発生時に生成されたステータスファイルのみを保持します。この件数は、この変数で調整できます。 | -| [`tidb_opt_prefix_index_single_scan`](/system-variables.md#tidb_opt_prefix_index_single_scan-new-in-v640) | 新しく追加された | TiDB オプティマイザが不要なテーブル検索を回避し、クエリのパフォーマンスを向上させるために、一部のフィルタ条件をプレフィックス インデックスにプッシュダウンするかどうかを制御します。デフォルト値は`ON`です。 | +| [`tidb_opt_prefix_index_single_scan`](/system-variables.md#tidb_opt_prefix_index_single_scan-new-in-v640) | 新しく追加された | TiDB オプティマイザが不要なテーブル検索を回避し、クエリのパフォーマンスを向上させるために、一部のフィルタ条件をプレフィックスインデックスにプッシュダウンするかどうかを制御します。デフォルト値は`ON`です。 | | [`tidb_opt_range_max_size`](/system-variables.md#tidb_opt_range_max_size-new-in-v640) | 新しく追加された | オプティマイザがスキャン範囲を構築するためのメモリ使用量の上限を指定します。デフォルト値は`67108864` (64 MiB) です。 | | [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640) | 新しく追加された | オプティマイザがスキャン範囲を構築するためのメモリ使用量の上限を制御します（実験的）。デフォルト値は`0`で、メモリ制限がないことを意味します。 | | [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640) | 新しく追加された | TiDB が GC をトリガーしようとするしきい値を制御します (実験的)。デフォルト値は`70%`です。 | @@ -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機能を使用できます。 @@ -381,7 +381,7 @@ TiDBバージョン: 6.4.0-DMR - TiDB Data Migration (DM) - 役に立たない`operate-source update`コマンドを dmctl から削除します [#7246](https://github.com/pingcap/tiflow/issues/7246) @[buchuitoudegou](https://github.com/buchuitoudegou) - - 上流データベースが TiDB と互換性のない DDL ステートメントを使用している場合に DM の完全インポートが失敗する問題を修正しました。TiDB でサポートされている DDL ステートメントを使用して、事前に TiDB でターゲット テーブルのスキーマを手動で作成することで、インポートの成功を確実にすることができます [#37984](https://github.com/pingcap/tidb/issues/37984) @[lance6716](https://github.com/lance6716) + - 上流データベースが TiDB と互換性のない DDL ステートメントを使用している場合に DM の完全インポートが失敗する問題を修正しました。TiDB でサポートされている DDL ステートメントを使用して、事前に TiDB でターゲットテーブルのスキーマを手動で作成することで、インポートの成功を確実にすることができます [#37984](https://github.com/pingcap/tidb/issues/37984) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index b2782aa8cd950..869b3bdd99b07 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -19,7 +19,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では > > 以前の LTS 6.1.0 と比較して、 TiDB 6.5.0 には、 [6.2.0-DMR](/releases/release-6.2.0.md) 、 [6.3.0-DMR](/releases/release-6.3.0.md) 、 [6.4.0-DMR](/releases/release-6.4.0.md)でリリースされた新機能、改善、バグ修正も含まれています。 > -> - 6.1.0 LTS バージョンと 6.5.0 LTS バージョン間の変更点の完全なリストを取得するには、このリリース ノートに加えて、 [6.2.0-DMR リリースノート](/releases/release-6.2.0.md) 、 [6.3.0-DMR リリースノート](/releases/release-6.3.0.md) 、および[6.4.0-DMR リリースノート](/releases/release-6.4.0.md)も参照してください。 +> - 6.1.0 LTS バージョンと 6.5.0 LTS バージョン間の変更点の完全なリストを取得するには、このリリースノートに加えて、 [6.2.0-DMR リリースノート](/releases/release-6.2.0.md) 、 [6.3.0-DMR リリースノート](/releases/release-6.3.0.md) 、および[6.4.0-DMR リリースノート](/releases/release-6.4.0.md)も参照してください。 > - 6.1.0 LTS バージョンと 6.5.0 LTS バージョンの主な機能を簡単に比較するには、 [TiDBの機能](/basic-features.md)の`v6.1`と`v6.5`列を確認してください。 - [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能が一般提供 (GA) され、v6.1.0 と比較してインデックス追加のパフォーマンスが約 10 倍向上しました。 @@ -44,7 +44,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDB v6.3.0では、インデックス作成時のバックフィル速度を向上させる実験的機能として[インデックス加速を追加](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)導入されました。v6.5.0ではこの機能がGAとなり、デフォルトで有効化されます。大規模テーブルにおけるパフォーマンスはv6.1.0と比較して約10倍向上すると予想されます。この高速化機能は、単一のSQL文がインデックスを逐次追加するシナリオに適しています。複数のSQL文が並列でインデックスを追加する場合は、そのうちの1つのSQL文のみが高速化されます。 -- DDL 変更時の DML 成功率を向上させる軽量メタデータ ロックを提供する (GA) [＃37275](https://github.com/pingcap/tidb/issues/37275) @[wjhuang2016](https://github.com/wjhuang2016) +- DDL 変更時の DML 成功率を向上させる軽量メタデータロックを提供する (GA) [＃37275](https://github.com/pingcap/tidb/issues/37275) @[wjhuang2016](https://github.com/wjhuang2016) TiDB v6.3.0 では、 [メタデータロック](/metadata-lock.md)実験的機能として導入されています。DML 文によって発生する`Information schema is changed`エラーを回避するため、TiDB はテーブルメタデータの変更時に DML と DDL の優先順位を調整し、実行中の DDL を古いメタデータを持つ DML のコミットまで待機させます。v6.5.0 ではこの機能が GA となり、デフォルトで有効化されます。これは、さまざまな種類の DDL 変更シナリオに適しています。既存のクラスターを v6.5.0 より前のバージョンから v6.5.0 以降にアップグレードすると、TiDB は自動的にメタデータロックを有効にします。この機能を無効にするには、システム変数[`tidb_enable_metadata_lock`](/system-variables.md#tidb_enable_metadata_lock-new-in-v630)を`OFF`に設定します。 @@ -140,8 +140,8 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiFlashおよび CDC パネルは、 TiFlashおよび TiCDC の監視情報を再編成します。これにより、 TiFlashおよび TiCDC のパフォーマンスの問題の分析とトラブルシューティングの効率が大幅に向上します。 - - [TiFlashパネル](/grafana-performance-overview-dashboard.md#tiflash)では、 TiFlashクラスターのリクエスト タイプ、レイテンシー分析、リソース使用状況の概要を簡単に表示できます。 - - [CDCパネル](/grafana-performance-overview-dashboard.md#cdc)では、TiCDC クラスターの健全性、レプリケーションのレイテンシー、データ フロー、ダウンストリームの書き込みレイテンシーを簡単に確認できます。 + - [TiFlashパネル](/grafana-performance-overview-dashboard.md#tiflash)では、 TiFlashクラスターのリクエストタイプ、レイテンシー分析、リソース使用状況の概要を簡単に表示できます。 + - [CDCパネル](/grafana-performance-overview-dashboard.md#cdc)では、TiCDC クラスターの健全性、レプリケーションのレイテンシー、データフロー、ダウンストリームの書き込みレイテンシーを簡単に確認できます。 詳細については[ドキュメント](/performance-tuning-methods.md)を参照してください。 @@ -181,7 +181,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)が実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行計画を選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 - コスト モデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 + コストモデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 詳細については[ドキュメント](/cost-model.md#cost-model-version-2)を参照してください。 @@ -309,9 +309,9 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | ------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `tidb_enable_amend_pessimistic_txn` | 非推奨 | v6.5.0 以降、この変数は非推奨となり、TiDB は`Information schema is changed`エラーを回避するためにデフォルトで[メタデータロック](/metadata-lock.md)機能を使用します。 | | [`tidb_enable_outer_join_reorder`](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 [結合したテーブルの再配置](/join-reorder.md)アルゴリズムの Outer Join のサポートがデフォルトで有効になります。 | -| [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620) | 変更 | さらにテストを行った後、デフォルト値を`1`から`2`に変更します。つまり、インデックス選択と演算子選択には、デフォルトでコスト モデル バージョン 2 が使用されることになります。 | +| [`tidb_cost_model_version`](/system-variables.md#tidb_cost_model_version-new-in-v620) | 変更 | さらにテストを行った後、デフォルト値を`1`から`2`に変更します。つまり、インデックス選択と演算子選択には、デフォルトでコストモデル バージョン 2 が使用されることになります。 | | [`tidb_enable_gc_aware_memory_track`](/system-variables.md#tidb_enable_gc_aware_memory_track) | 変更 | デフォルト値を`ON`から`OFF`に変更します。GC対応メモリトラックはテストで不正確であることが判明し、追跡されるメモリサイズが大きくなりすぎるため、メモリトラックは無効化されています。また、 Golang 1.19では、GC対応メモリトラックによって追跡されるメモリは、全体のメモリに大きな影響を与えません。 | -| [`tidb_enable_metadata_lock`](/system-variables.md#tidb_enable_metadata_lock-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。これは、メタデータ ロック機能がデフォルトで有効になっていることを意味します。 | +| [`tidb_enable_metadata_lock`](/system-variables.md#tidb_enable_metadata_lock-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。これは、メタデータロック機能がデフォルトで有効になっていることを意味します。 | | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 変更 | 6.5.0以降で有効になります。`INSERT` 、 `DELETE` 、 `UPDATE`を含むSQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 変更 | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 `ADD INDEX`と`CREATE INDEX`の加速はデフォルトで有効になります。 | | [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) | 変更 | TiDB v6.5.0より前のバージョンでは、この変数はクエリのメモリクォータのしきい値を設定するために使用されます。TiDB v6.5.0以降のバージョンでは、DMLステートメントのメモリをより正確に制御するために、この変数はセッションのメモリクォータのしきい値を設定するために使用されます。 | diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index afb4453b1704b..268b586716d18 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -25,7 +25,7 @@ TiDB バージョン: 6.5.1 - TiKV [`advance-ts-interval`](/tikv-configuration-file.md#advance-ts-interval)設定項目のデフォルト値が`1s`から`20s`に変更されました。この設定項目を変更することで、レイテンシーを短縮し、 ステイル読み取りデータの適時性を向上させることができます。詳細は[ステイル読み取りのレイテンシーを削減](/stale-read.md#reduce-stale-read-latency)ご覧ください。 -- ネットワーク トラフィックを削減するために、TiKV [`cdc.min-ts-interval`](/tikv-configuration-file.md#min-ts-interval)構成項目の既定値が`"200ms"`から`"1s"`に変更されました。 +- ネットワークトラフィックを削減するために、TiKV [`cdc.min-ts-interval`](/tikv-configuration-file.md#min-ts-interval)構成項目の既定値が`"200ms"`から`"1s"`に変更されました。 ## 改善点 {#improvements} @@ -104,7 +104,7 @@ TiDB バージョン: 6.5.1 - `cop`の上限同時実行数が制限されない問題を修正 [＃41134](https://github.com/pingcap/tidb/issues/41134) @[you06](https://github.com/you06) - `cursor read`分の`statement context`が誤ってキャッシュされる問題を修正 [＃39998](https://github.com/pingcap/tidb/issues/39998) @[zyguan](https://github.com/zyguan) - メモリリークとパフォーマンスの低下を防ぐため、古くなったリージョンキャッシュを定期的にクリーンアップします[＃40355](https://github.com/pingcap/tidb/issues/40355) @[sticnarf](https://github.com/sticnarf) - - `year const`含むクエリでプラン キャッシュを使用すると間違った結果が返される可能性がある問題を修正しました [＃41626](https://github.com/pingcap/tidb/issues/41626) @[qw4990](https://github.com/qw4990) + - `year const`含むクエリでプランキャッシュを使用すると間違った結果が返される可能性がある問題を修正しました [＃41626](https://github.com/pingcap/tidb/issues/41626) @[qw4990](https://github.com/qw4990) - 大きな範囲と大量のデータ変更を伴うクエリを実行するときに大きな推定エラーが発生する問題を修正[＃39593](https://github.com/pingcap/tidb/issues/39593) @[time-and-fate](https://github.com/time-and-fate) - Plan Cache の使用時に、一部の条件が Join 演算子を通じてプッシュダウンできない問題を修正しました。 [＃38205](https://github.com/pingcap/tidb/issues/38205) @[qw4990](https://github.com/qw4990) [＃40093](https://github.com/pingcap/tidb/issues/40093) - IndexMerge プランが SET 型の列 に誤った範囲を生成する可能性がある問題を修正しました [＃41293](https://github.com/pingcap/tidb/issues/41293) @[time-and-fate](https://github.com/time-and-fate) [＃41273](https://github.com/pingcap/tidb/issues/41273) @@ -162,7 +162,7 @@ TiDB バージョン: 6.5.1 - ログバックアップが実行中のクラスタにデータを復元すると、ログバックアップファイルが復元できなくなる問題を修正[＃40797](https://github.com/pingcap/tidb/issues/40797) @[Leavrth](https://github.com/Leavrth) - 完全バックアップの失敗後にチェックポイントからバックアップを再開しようとしたときに発生するpanicの問題を修正[＃40704](https://github.com/pingcap/tidb/issues/40704) @[Leavrth](https://github.com/Leavrth) - PITRエラーが上書きされる問題を修正 [＃40576](https://github.com/pingcap/tidb/issues/40576) @[Leavrth](https://github.com/Leavrth) - - PITR バックアップ タスクで、先行所有者と GC 所有者が異なる場合にチェックポイントが進まない問題を修正しました[＃41806](https://github.com/pingcap/tidb/issues/41806) @[joccau](https://github.com/joccau) + - PITR バックアップタスクで、先行所有者と GC 所有者が異なる場合にチェックポイントが進まない問題を修正しました[＃41806](https://github.com/pingcap/tidb/issues/41806) @[joccau](https://github.com/joccau) - TiCDC diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 1bfbbf25698ca..650cfd762a6cc 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.10 - TiDB - `SHOW CREATE TABLE` の出力に表示される式のデフォルト値のMySQL互換性を改善しました [＃52939](https://github.com/pingcap/tidb/issues/52939) @[CbcWestwolf](https://github.com/CbcWestwolf) - - MPP ロード バランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) + - MPP ロードバランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) - TiKV @@ -69,7 +69,7 @@ TiDB バージョン: 6.5.10 - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが制限を超えると TiDB がクラッシュする可能性がある問題を修正しました。 [＃52601](https://github.com/pingcap/tidb/issues/52601) @[hawkingrei](https://github.com/hawkingrei) - `UPDATE`リスト内のサブクエリによって TiDB がpanicする可能性がある問題を修正[＃52687](https://github.com/pingcap/tidb/issues/52687) @[winoros](https://github.com/winoros) - 述語の`Longlong`型のオーバーフローの問題を修正 [＃45783](https://github.com/pingcap/tidb/issues/45783) @[hawkingrei](https://github.com/hawkingrei) - - 一意インデックスを追加するときに同時 DML 操作によって発生するデータ インデックスの不整合の問題を修正しました。 [＃52914](https://github.com/pingcap/tidb/issues/52914) @[wjhuang2016](https://github.com/wjhuang2016) + - 一意インデックスを追加するときに同時 DML 操作によって発生するデータインデックスの不整合の問題を修正しました。 [＃52914](https://github.com/pingcap/tidb/issues/52914) @[wjhuang2016](https://github.com/wjhuang2016) - インデックスデータを解析するときに TiDB がpanicする可能性がある問題を修正しました [＃47115](https://github.com/pingcap/tidb/issues/47115) @[zyguan](https://github.com/zyguan) - スライスの浅いコピーを使用せずに列プルーニングを行うと、TiDB がpanicする可能性がある問題を修正しました[＃52768](https://github.com/pingcap/tidb/issues/52768) @[winoros](https://github.com/winoros) - 再帰CTE でビューの使用が機能しない問題を修正 [＃49721](https://github.com/pingcap/tidb/issues/49721) @[hawkingrei](https://github.com/hawkingrei) @@ -116,11 +116,11 @@ TiDB バージョン: 6.5.10 - Backup & Restore (BR) - テストケース`TestGetTSWithRetry`実行に時間がかかりすぎる問題を修正[＃52547](https://github.com/pingcap/tidb/issues/52547) @[Leavrth](https://github.com/Leavrth) - - BRを使用してデータを復元する場合、または物理インポート モードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) + - BRを使用してデータを復元する場合、または物理インポートモードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) - PD接続障害により、ログバックアップアドバンサ所有者が配置されているTiDBインスタンスがpanicになる可能性がある問題を修正しました。 [＃52597](https://github.com/pingcap/tidb/issues/52597) @[YuJuncen](https://github.com/YuJuncen) - ログバックアップタスクを一時停止、停止、再構築した後、タスクの状態は正常であるが、チェックポイントが進まない問題を修正しました。 [＃53047](https://github.com/pingcap/tidb/issues/53047) @[RidRisR](https://github.com/RidRisR) - TiKVノードにリーダーがいないためにデータ復元が遅くなる問題を修正 [＃50566](https://github.com/pingcap/tidb/issues/50566) @[Leavrth](https://github.com/Leavrth) - - TiKV の再起動により、ログ バックアップのグローバル チェックポイントが実際のバックアップ ファイルの書き込みポイントよりも先に進められ、少量のバックアップ データが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) + - TiKV の再起動により、ログバックアップのグローバルチェックポイントが実際のバックアップファイルの書き込みポイントよりも先に進められ、少量のバックアップデータが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) - PDリーダーの転送により、データ復元時にBRがpanicになる可能性がある問題を修正しました。 [＃53724](https://github.com/pingcap/tidb/issues/53724) @[Leavrth](https://github.com/Leavrth) - PD へのネットワーク接続が不安定な状態で一時停止中のログバックアップタスクを再開すると TiKV がpanicする可能性がある問題を修正しました [＃17020](https://github.com/tikv/tikv/issues/17020) @[YuJuncen](https://github.com/YuJuncen) - アドバンサー所有者の移行後にログバックアップが一時停止される可能性がある問題を修正しました [＃53561](https://github.com/pingcap/tidb/issues/53561) @[RidRisR](https://github.com/RidRisR) diff --git a/releases/release-6.5.11.md b/releases/release-6.5.11.md index 55250c3fdd932..7485da90a27da 100644 --- a/releases/release-6.5.11.md +++ b/releases/release-6.5.11.md @@ -57,7 +57,7 @@ TiDBバージョン: 6.5.11 - 厳密に自己増分ではないRANGEパーティションテーブルが作成できる問題を修正 [＃54829](https://github.com/pingcap/tidb/issues/54829) @[Defined2014](https://github.com/Defined2014) - 最初の引数が`month`で、2番目の引数が負の場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 [＃54908](https://github.com/pingcap/tidb/issues/54908) @[xzhangxian1008](https://github.com/xzhangxian1008) - `auth_socket`認証プラグインを使用しているときに、TiDB が認証されていないユーザーの接続を拒否できないことがある問題を修正しました。 [＃54031](https://github.com/pingcap/tidb/issues/54031) @[lcwangchao](https://github.com/lcwangchao) - - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワーク パーティションによって、データ インデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @[tangenta](https://github.com/tangenta) + - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワークパーティションによって、データインデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @[tangenta](https://github.com/tangenta) - メモリ使用量が`tidb_mem_quota_query` で設定された制限を超えたためにクエリが終了したときに停止する可能性がある問題を修正しました [＃55042](https://github.com/pingcap/tidb/issues/55042) @[yibin87](https://github.com/yibin87) - 特定の状況下でプランキャッシュを使用する際に、メタデータロックの不適切な使用によって異常なデータが書き込まれる可能性がある問題を修正しました[＃53634](https://github.com/pingcap/tidb/issues/53634) @[zimulala](https://github.com/zimulala) - 再帰CTEクエリが無効なポインタを生成する可能性がある問題を修正しました [＃54449](https://github.com/pingcap/tidb/issues/54449) @[hawkingrei](https://github.com/hawkingrei) @@ -80,7 +80,7 @@ TiDBバージョン: 6.5.11 - 大きなテーブルやパーティションを削除した後に発生する可能性のあるトラフィック制御の問題を修正しました [＃17304](https://github.com/tikv/tikv/issues/17304) @[Connor1996](https://github.com/Connor1996) - 削除された`sst_importer` SST ファイルを取り込むことにより TiKV がpanicになる可能性がある問題を修正しました [＃15053](https://github.com/tikv/tikv/issues/15053) @[lance6716](https://github.com/lance6716) - 古いレプリカがRaftスナップショットを処理するときに、遅い分割操作と新しいレプリカの即時削除によってトリガーされ、TiKV がpanicになる可能性がある問題を修正しました。 [＃17469](https://github.com/tikv/tikv/issues/17469) @[hbisheng](https://github.com/hbisheng) - - 破損したRaftデータ スナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [＃15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) + - 破損したRaftデータスナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [＃15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) - gRPC メッセージ圧縮方式を`grpc-compression-type`で設定しても、TiKV から TiDB に送信されるメッセージには反映されない問題を修正しました。 [＃17176](https://github.com/tikv/tikv/issues/17176) @[ekexium](https://github.com/ekexium) - CDC とログバックアップが`advance-ts-interval`構成を使用して`check_leader`のタイムアウトを制限しないため、TiKV が正常に再起動したときに`resolved_ts`遅延が大きくなる場合がある問題を修正しました[＃17107](https://github.com/tikv/tikv/issues/17107) @[MyonKeminta](https://github.com/MyonKeminta) @@ -99,7 +99,7 @@ TiDBバージョン: 6.5.11 - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [＃9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 外部結合を含むクエリの実行中にエラーが発生した場合にTiFlashがクラッシュする可能性がある問題を修正しました。 [＃9190](https://github.com/pingcap/tiflash/issues/9190) @[windtalker](https://github.com/windtalker) - データ型を`DECIMAL`に変換すると、一部のコーナーケースで誤ったクエリ結果が発生する可能性がある問題を修正しました[＃53892](https://github.com/pingcap/tidb/issues/53892) @[guo-shaoge](https://github.com/guo-shaoge) - - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブル メタデータのレプリケーションが遅くなり、クエリ パフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @[JaySon-Huang](https://github.com/JaySon-Huang) + - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブルメタデータのレプリケーションが遅くなり、クエリパフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @[JaySon-Huang](https://github.com/JaySon-Huang) - ツール @@ -121,7 +121,7 @@ TiDBバージョン: 6.5.11 - TiDB Data Migration (DM) - インデックスの長さがデフォルト値の`max-index-length` を超えるとデータレプリケーションが中断される問題を修正しました [＃11459](https://github.com/pingcap/tiflow/issues/11459) @[michaelmdeng](https://github.com/michaelmdeng) - - スキーマ トラッカーが LIST パーティション テーブルを誤って処理し、DM エラーが発生する問題を修正しました。 [＃11408](https://github.com/pingcap/tiflow/issues/11408) @[lance6716](https://github.com/lance6716) + - スキーマ トラッカーが LIST パーティションテーブルを誤って処理し、DM エラーが発生する問題を修正しました。 [＃11408](https://github.com/pingcap/tiflow/issues/11408) @[lance6716](https://github.com/lance6716) - LISTパーティションテーブルの`ALTER TABLE ... DROP PARTITION`文を複製するときにDMがエラーを返す問題を修正しました。 [＃54760](https://github.com/pingcap/tidb/issues/54760) @[lance6716](https://github.com/lance6716) - DMが`ALTER DATABASE`ステートメントを処理するときにデフォルトのデータベースを設定せず、レプリケーションエラーが発生する問題を修正しました。 [＃11503](https://github.com/pingcap/tiflow/issues/11503) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index 53e42f7b4985b..4885916aa8553 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -36,7 +36,7 @@ TiDBバージョン: 6.5.12 - Backup & Restore (BR) - 完全復元のためにターゲットクラスタが空のクラスタであるかどうかを確認するチェックを追加します[＃35744](https://github.com/pingcap/tidb/issues/35744) @[3pointer](https://github.com/3pointer) - - 非完全復元の場合、ターゲット クラスターに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 [＃55087](https://github.com/pingcap/tidb/issues/55087) @[RidRisR](https://github.com/RidRisR) + - 非完全復元の場合、ターゲットクラスターに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 [＃55087](https://github.com/pingcap/tidb/issues/55087) @[RidRisR](https://github.com/RidRisR) - `br log restore`サブコマンドを除き、他の`br log`サブコマンドはすべて、メモリ消費量を削減するために TiDB `domain`データ構造のロードをスキップすることをサポートしています[＃52088](https://github.com/pingcap/tidb/issues/52088) @[Leavrth](https://github.com/Leavrth) - バックアップパフォーマンスを向上させるために、フルバックアップ中のテーブルレベルのチェックサム計算をデフォルトで無効にする（ `--checksum=false` ） [＃56373](https://github.com/pingcap/tidb/issues/56373) @[Tristan1900](https://github.com/Tristan1900) @@ -78,7 +78,7 @@ TiDBバージョン: 6.5.12 - Prepareプロトコルで、クライアントがUTF8以外の文字セットを使用するとエラーが発生する問題を修正しました。 [＃58870](https://github.com/pingcap/tidb/issues/58870) @[xhebox](https://github.com/xhebox) - 一時テーブルをクエリすると、場合によっては予期しない TiKV リクエストがトリガーされる可能性がある問題を修正しました[＃58875](https://github.com/pingcap/tidb/issues/58875) @[tiancaiamao](https://github.com/tiancaiamao) - ビューのステートメントに`ONLY_FULL_GROUP_BY`設定が反映されない問題を修正しました [＃53175](https://github.com/pingcap/tidb/issues/53175) @[mjonss](https://github.com/mjonss) - - 不一致な値型と型変換エラーを含む`IN`条件を使用してパーティション テーブルをクエリすると、誤ったクエリ結果が発生する問題を修正しました [＃54746](https://github.com/pingcap/tidb/issues/54746) @[mjonss](https://github.com/mjonss) + - 不一致な値型と型変換エラーを含む`IN`条件を使用してパーティションテーブルをクエリすると、誤ったクエリ結果が発生する問題を修正しました [＃54746](https://github.com/pingcap/tidb/issues/54746) @[mjonss](https://github.com/mjonss) - 特定のフィールドに空の値が含まれている場合にスローログのクエリが失敗する可能性がある問題を修正[＃58147](https://github.com/pingcap/tidb/issues/58147) @[yibin87](https://github.com/yibin87) - `RADIANS()`関数が誤った順序で値を計算する問題を修正[＃57671](https://github.com/pingcap/tidb/issues/57671) @[gengliqi](https://github.com/gengliqi) - `BIT`列のデフォルト値が正しくない問題を修正[＃57301](https://github.com/pingcap/tidb/issues/57301) @[YangKeao](https://github.com/YangKeao) @@ -142,7 +142,7 @@ TiDBバージョン: 6.5.12 - TiKV にリクエストを送信するときに`rpcClient is idle`エラーが発生し、 BR が復元に失敗する問題を修正しました。 [＃58845](https://github.com/pingcap/tidb/issues/58845) @[Tristan1900](https://github.com/Tristan1900) - `br log status --json` を使用してログバックアップタスクをクエリすると、結果に`status`フィールドが表示されない問題を修正しました。 [＃57959](https://github.com/pingcap/tidb/issues/57959) @[Leavrth](https://github.com/Leavrth) - ログバックアップ中のPDLeaderI/Oレイテンシーによりチェックポイントレイテンシーが増加する可能性がある問題を修正しました。 [＃58574](https://github.com/pingcap/tidb/issues/58574) @[YuJuncen](https://github.com/YuJuncen) - - `tiup br restore`コマンドがデータベースまたはテーブルの復元中にターゲット クラスタ テーブルが既に存在するかどうかのチェックを省略し、既存のテーブルを上書きする可能性がある問題を修正しました。 [＃58168](https://github.com/pingcap/tidb/issues/58168) @[RidRisR](https://github.com/RidRisR) + - `tiup br restore`コマンドがデータベースまたはテーブルの復元中にターゲットクラスタ テーブルが既に存在するかどうかのチェックを省略し、既存のテーブルを上書きする可能性がある問題を修正しました。 [＃58168](https://github.com/pingcap/tidb/issues/58168) @[RidRisR](https://github.com/RidRisR) - アドバンサー所有者が切り替わったときに、ログバックアップが予期せず一時停止状態になる可能性がある問題を修正しました。 [＃58031](https://github.com/pingcap/tidb/issues/58031) @[3pointer](https://github.com/3pointer) - ログバックアップが残留ロックをすぐに解決できず、チェックポイントが進まない問題を修正しました。 [＃57134](https://github.com/pingcap/tidb/issues/57134) @[3pointer](https://github.com/3pointer) - BR統合テストケースが不安定になる問題を修正し、スナップショットまたはログバックアップファイルの破損をシミュレートする新しいテストケースを追加します[＃53835](https://github.com/pingcap/tidb/issues/53835) @[Leavrth](https://github.com/Leavrth) @@ -159,7 +159,7 @@ TiDBバージョン: 6.5.12 - `changefeed pause`コマンドで`--overwrite-checkpoint-ts`パラメータを使用すると、変更フィードが停止する可能性がある問題を修正しました。 [＃12055](https://github.com/pingcap/tiflow/issues/12055) @[hongyunyan](https://github.com/hongyunyan) - `CREATE TABLE IF NOT EXISTS`または`CREATE DATABASE IF NOT EXISTS`ステートメントを複製するときに TiCDC がpanicする可能性がある問題を修正しました [＃11839](https://github.com/pingcap/tiflow/issues/11839) @[CharlesCheung96](https://github.com/CharlesCheung96) - 有効なインデックスのないテーブルで`TRUNCATE TABLE` DDL を複製するときに TiCDC がエラーを報告する可能性がある問題を修正しました。 [＃11765](https://github.com/pingcap/tiflow/issues/11765) @[asddongmen](https://github.com/asddongmen) - - TiDB DDL 所有者の変更中に DDL タスクのスキーマ バージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) + - TiDB DDL 所有者の変更中に DDL タスクのスキーマバージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) - 新しい TiKV ノードがクラスターに追加された後に、変更フィードがスタックする可能性がある問題を修正しました。 [＃11766](https://github.com/pingcap/tiflow/issues/11766) @[lidezhu](https://github.com/lidezhu) - Sarama クライアントによって再送信された順序外メッセージによって Kafka メッセージの順序が正しくなくなる問題を修正[＃11935](https://github.com/pingcap/tiflow/issues/11935) @[3AceShowHand](https://github.com/3AceShowHand) - PullerモジュールのResolved TSレイテンシーモニタリングで誤った値が表示される問題を修正しました [＃11561](https://github.com/pingcap/tiflow/issues/11561) @[wlwilliamx](https://github.com/wlwilliamx) diff --git a/releases/release-6.5.2.md b/releases/release-6.5.2.md index ba69571efd7a7..264a15e19b999 100644 --- a/releases/release-6.5.2.md +++ b/releases/release-6.5.2.md @@ -30,7 +30,7 @@ TiDB バージョン: 6.5.2 - TiFlash - - TiFlash読み取り時のタスク スケジューリングの CPU 消費を削減[＃6495](https://github.com/pingcap/tiflash/issues/6495) @[JinheLin](https://github.com/JinheLin) + - TiFlash読み取り時のタスクスケジューリングの CPU 消費を削減[＃6495](https://github.com/pingcap/tiflash/issues/6495) @[JinheLin](https://github.com/JinheLin) - デフォルト設定でBRおよびTiDB LightningからTiFlashへのデータインポートのパフォーマンスを向上 [＃7272](https://github.com/pingcap/tiflash/issues/7272) @[breezewish](https://github.com/breezewish) - ツール @@ -51,9 +51,9 @@ TiDB バージョン: 6.5.2 - TiDB - キャッシュテーブルに新しい列が追加された後、列のデフォルト値ではなく値が`NULL`なる問題を修正しました。 [＃42928](https://github.com/pingcap/tidb/issues/42928) @[lqs](https://github.com/lqs) - - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) + - 多数のパーティションとTiFlashレプリカを持つパーティションテーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) - `DROP TABLE`操作が実行されているときに`ADMIN SHOW DDL JOBS`結果にテーブル名が表示されない問題を修正[＃42268](https://github.com/pingcap/tidb/issues/42268) @[tiancaiamao](https://github.com/tiancaiamao) - - cgroup 情報の読み取りエラーにより、TiDBサーバーが起動できない問題を修正しました。エラー メッセージは「cgroup v1 からファイルメモリ.stat を読み取れません: /sys/メモリ.stat をオープンすると、そのようなファイルまたはディレクトリが見つかりません」です[＃42659](https://github.com/pingcap/tidb/issues/42659) @[hawkingrei](https://github.com/hawkingrei) + - cgroup 情報の読み取りエラーにより、TiDBサーバーが起動できない問題を修正しました。エラーメッセージは「cgroup v1 からファイルメモリ.stat を読み取れません: /sys/メモリ.stat をオープンすると、そのようなファイルまたはディレクトリが見つかりません」です[＃42659](https://github.com/pingcap/tidb/issues/42659) @[hawkingrei](https://github.com/hawkingrei) - DDLデータバックフィルを実行するときにトランザクションで頻繁に発生する書き込み競合を修正 [＃24427](https://github.com/pingcap/tidb/issues/24427) @[mjonss](https://github.com/mjonss) - 実行計画を生成する際に不整合な InfoSchema が取得され、TiDB panicが発生する問題を修正しました。 [＃41622](https://github.com/pingcap/tidb/issues/41622) @[tiancaiamao](https://github.com/tiancaiamao) - DDLを使用して浮動小数点型を変更し、長さを変更せずに小数点以下の桁数を減らしても、古いデータが同じままになる問題を修正しました[＃41281](https://github.com/pingcap/tidb/issues/41281) @[zimulala](https://github.com/zimulala) diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index 95dfef5de65ae..7b5e5e5f37a78 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.3 - TiDB - - 配置ルールでパーティション テーブル上の`TRUNCATE`のパフォーマンスを向上します。 [＃43070](https://github.com/pingcap/tidb/issues/43070) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 配置ルールでパーティションテーブル上の`TRUNCATE`のパフォーマンスを向上します。 [＃43070](https://github.com/pingcap/tidb/issues/43070) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - ロックを解決した後の無効なステイル読み取り再試行を回避する [＃43659](https://github.com/pingcap/tidb/issues/43659) @[you06](https://github.com/you06) - ステイル読み取りで`DataIsNotReady`エラーが発生した場合にリーダー読み取りを使用してレイテンシーを削減します。 [＃765](https://github.com/tikv/client-go/pull/765) @[Tema](https://github.com/Tema) - ステイル読み取り を使用するときにヒット率とトラフィックを追跡するために`Stale Read OPS`と`Stale Read MBps`メトリックを追加します [＃43325](https://github.com/pingcap/tidb/issues/43325) @[you06](https://github.com/you06) diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index 222a8936efc0f..c6cd41e6cbca4 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -181,7 +181,7 @@ TiDB バージョン: 6.5.4 - TiDB Lightning - - エンジンがデータをインポートしているときにディスク クォータ チェックがブロックされる可能性がある問題を修正しました [＃44867](https://github.com/pingcap/tidb/issues/44867) @[D3Hunter](https://github.com/D3Hunter) + - エンジンがデータをインポートしているときにディスククォータ チェックがブロックされる可能性がある問題を修正しました [＃44867](https://github.com/pingcap/tidb/issues/44867) @[D3Hunter](https://github.com/D3Hunter) - ターゲットクラスタで SSL が有効になっているときにチェックサムがエラー`Region is unavailable`を報告する問題を修正しました [＃45462](https://github.com/pingcap/tidb/issues/45462) @[D3Hunter](https://github.com/D3Hunter) - エンコードエラーが正しく記録されない問題を修正[＃44321](https://github.com/pingcap/tidb/issues/44321) @[lyzx2001](https://github.com/lyzx2001) - CSVデータをインポートする際にルートがpanicになる可能性がある問題を修正 [＃43284](https://github.com/pingcap/tidb/issues/43284) @[lyzx2001](https://github.com/lyzx2001) diff --git a/releases/release-6.5.5.md b/releases/release-6.5.5.md index dffc75c80fb83..7e62bd0eee37f 100644 --- a/releases/release-6.5.5.md +++ b/releases/release-6.5.5.md @@ -22,7 +22,7 @@ TiDB バージョン: 6.5.5 - 接続再試行のプロセスでPDクライアントのバックオフメカニズムを追加し、エラー再試行中に再試行間隔を徐々に増やしてPD圧力を軽減します。 [＃15428](https://github.com/tikv/tikv/issues/15428) @[nolouch](https://github.com/nolouch) - スナップショットの監視メトリックを追加します [＃15401](https://github.com/tikv/tikv/issues/15401) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - - リーダー転送中の PITR チェックポイント ラグの安定性を向上[＃13638](https://github.com/tikv/tikv/issues/13638) @[YuJuncen](https://github.com/YuJuncen) + - リーダー転送中の PITR チェックポイントラグの安定性を向上[＃13638](https://github.com/tikv/tikv/issues/13638) @[YuJuncen](https://github.com/YuJuncen) - `safe-ts` に関連するログと監視メトリックを追加します [＃15082](https://github.com/tikv/tikv/issues/15082) @[ekexium](https://github.com/ekexium) - `resolved-ts` のログと監視メトリックをさらに提供 [＃15082](https://github.com/tikv/tikv/issues/15082) @[ekexium](https://github.com/ekexium) @@ -73,4 +73,4 @@ TiDB バージョン: 6.5.5 - ターゲットサーバーにTiCDCがデプロイされているときにTiDB Lightningが起動に失敗する問題を修正 [＃41040](https://github.com/pingcap/tidb/issues/41040) @[lance6716](https://github.com/lance6716) - PDトポロジが変更されるとTiDB Lightningが起動に失敗する問題を修正[＃46688](https://github.com/pingcap/tidb/issues/46688) @[lance6716](https://github.com/lance6716) - PD のリーダーを切り替えた後にTiDB Lightning がデータのインポートを続行できない問題を修正しました [＃46540](https://github.com/pingcap/tidb/issues/46540) @[lance6716](https://github.com/lance6716) - - 事前チェックがターゲット クラスターで実行中の TiCDC の存在を正確に検出できない問題を修正しました。 [＃41040](https://github.com/pingcap/tidb/issues/41040) @[lance6716](https://github.com/lance6716) + - 事前チェックがターゲットクラスターで実行中の TiCDC の存在を正確に検出できない問題を修正しました。 [＃41040](https://github.com/pingcap/tidb/issues/41040) @[lance6716](https://github.com/lance6716) diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 386a76c8438f8..e259b607c0ff6 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -68,7 +68,7 @@ TiDB バージョン: 6.5.6 - CAST に精度損失がないのに条件`cast(col)=range`で FullScan が発生する問題を修正[＃45199](https://github.com/pingcap/tidb/issues/45199) @[AilinKid](https://github.com/AilinKid) - `batch-client` in `client-go` のpanic問題を修正 [＃47691](https://github.com/pingcap/tidb/issues/47691) @[crazycs520](https://github.com/crazycs520) - 非整数クラスター化インデックスでのテーブル分割操作を禁止する [＃47350](https://github.com/pingcap/tidb/issues/47350) @[tangenta](https://github.com/tangenta) - - 時間変換中に準備済みプラン キャッシュと準備されていないプラン キャッシュの動作間の非互換性の問題を修正しました [＃42439](https://github.com/pingcap/tidb/issues/42439) @[qw4990](https://github.com/qw4990) + - 時間変換中に準備済みプランキャッシュと準備されていないプランキャッシュの動作間の非互換性の問題を修正しました [＃42439](https://github.com/pingcap/tidb/issues/42439) @[qw4990](https://github.com/qw4990) - 取り込みモードを使用して空のテーブルにインデックスを作成できないことがある問題を修正しました [＃39641](https://github.com/pingcap/tidb/issues/39641) @[tangenta](https://github.com/tangenta) - パーティション交換中にパーティション定義に準拠していないデータを検出できない問題を修正 [＃46492](https://github.com/pingcap/tidb/issues/46492) @[mjonss](https://github.com/mjonss) - `GROUP_CONCAT` `ORDER BY`列を解析できない問題を修正 [＃41986](https://github.com/pingcap/tidb/issues/41986) @[AilinKid](https://github.com/AilinKid) @@ -165,7 +165,7 @@ TiDB バージョン: 6.5.6 - TiDB Data Migration (DM) - DMが楽観的モードでパーティションDDLをスキップする問題を修正 [＃9788](https://github.com/pingcap/tiflow/issues/9788) @[GMHDBJD](https://github.com/GMHDBJD) - - オンライン DDL をスキップするときに DM が上流のテーブル スキーマを適切に追跡できない問題を修正しました [＃9587](https://github.com/pingcap/tiflow/issues/9587) @[GMHDBJD](https://github.com/GMHDBJD) + - オンライン DDL をスキップするときに DM が上流のテーブルスキーマを適切に追跡できない問題を修正しました [＃9587](https://github.com/pingcap/tiflow/issues/9587) @[GMHDBJD](https://github.com/GMHDBJD) - 失敗した DDL がスキップされ、後続の DDL が実行されない場合に、DM によって返されるレプリケーション ラグが増大し続ける問題を修正しました[＃9605](https://github.com/pingcap/tiflow/issues/9605) @[D3Hunter](https://github.com/D3Hunter) - 楽観的モードでタスクを再開するときに DM がすべての DML をスキップする問題を修正しました [＃9588](https://github.com/pingcap/tiflow/issues/9588) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-6.5.7.md b/releases/release-6.5.7.md index 494c9019745e9..d5b3046ee09a6 100644 --- a/releases/release-6.5.7.md +++ b/releases/release-6.5.7.md @@ -33,7 +33,7 @@ TiDB バージョン: 6.5.7 - Backup & Restore (BR) - 大規模なデータセットシナリオで`RESTORE`ステートメントのテーブル作成パフォーマンスを向上 [＃48301](https://github.com/pingcap/tidb/issues/48301) @[Leavrth](https://github.com/Leavrth) - - EBS ベースのスナップショット バックアップとTiDB Lightningインポート間の互換性の問題を解決[＃46850](https://github.com/pingcap/tidb/issues/46850) @[YuJuncen](https://github.com/YuJuncen) + - EBS ベースのスナップショットバックアップとTiDB Lightningインポート間の互換性の問題を解決[＃46850](https://github.com/pingcap/tidb/issues/46850) @[YuJuncen](https://github.com/YuJuncen) - リージョンリーダーシップの移行が発生すると、PITR ログバックアップの進行のレイテンシーが長くなるという問題を軽減します[＃13638](https://github.com/tikv/tikv/issues/13638) @[YuJuncen](https://github.com/YuJuncen) - TiCDC diff --git a/releases/release-6.5.8.md b/releases/release-6.5.8.md index 69bac3401ca1d..17b0e58270348 100644 --- a/releases/release-6.5.8.md +++ b/releases/release-6.5.8.md @@ -75,7 +75,7 @@ TiDB バージョン: 6.5.8 - 古いバージョンのバックアップからデータを復元するときに`Unsupported collation`エラーが報告される問題を修正しました [＃49466](https://github.com/pingcap/tidb/issues/49466) @[3pointer](https://github.com/3pointer) - S3 からファイル コンテンツを読み取っているときにエラーが発生した場合にBR が再試行できない問題を修正しました [＃49942](https://github.com/pingcap/tidb/issues/49942) @[Leavrth](https://github.com/Leavrth) - - 同じノードで TiKV IP アドレスを変更した後にログ バックアップが停止する問題を修正しました [＃50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) + - 同じノードで TiKV IP アドレスを変更した後にログバックアップが停止する問題を修正しました [＃50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) - TiCDC diff --git a/releases/release-6.5.9.md b/releases/release-6.5.9.md index 4c778859f7154..5f8a855e484ad 100644 --- a/releases/release-6.5.9.md +++ b/releases/release-6.5.9.md @@ -26,7 +26,7 @@ TiDB バージョン: 6.5.9 - TiKV - 不要な非同期ブロックを削除してメモリ使用量を削減する[＃16540](https://github.com/tikv/tikv/issues/16540) @[overvenus](https://github.com/overvenus) - - TiKV の安定性を向上させるために、raftstore スレッドでスナップショット ファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) + - TiKV の安定性を向上させるために、raftstore スレッドでスナップショットファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) - ピアのスローログを追加し、メッセージを保存します [＃16600](https://github.com/tikv/tikv/issues/16600) @[Connor1996](https://github.com/Connor1996) - ツール @@ -35,7 +35,7 @@ TiDB バージョン: 6.5.9 - ローリング再起動時のログバックアップのRPO（目標復旧時点）を最適化します。これにより、ローリング再起動時のログバックアップタスクのチェックポイントラグが短縮されます[＃15410](https://github.com/tikv/tikv/issues/15410) @[YuJuncen](https://github.com/YuJuncen) 。 - ログバックアップのマージ操作に対する許容度を向上します。比較的長いマージ操作が発生した場合、ログバックアップタスクがエラー状態に陥る可能性が低くなります。 [＃16554](https://github.com/tikv/tikv/issues/16554) @[YuJuncen](https://github.com/YuJuncen) - - チェックポイントの遅延が大きい場合にログ バックアップ タスクを自動的に中止する機能をサポートし、GC の長時間のブロッキングや潜在的なクラスターの問題を回避します[＃50803](https://github.com/pingcap/tidb/issues/50803) @[RidRisR](https://github.com/RidRisR) + - チェックポイントの遅延が大きい場合にログバックアップタスクを自動的に中止する機能をサポートし、GC の長時間のブロッキングや潜在的なクラスターの問題を回避します[＃50803](https://github.com/pingcap/tidb/issues/50803) @[RidRisR](https://github.com/RidRisR) - リージョンリーダーシップの移行が発生すると、PITR ログバックアップの進行のレイテンシーが長くなるという問題を軽減します[＃13638](https://github.com/tikv/tikv/issues/13638) @[YuJuncen](https://github.com/YuJuncen) - より効率的なアルゴリズムを使用して、データ復元中に SST ファイルをマージする速度を改善します [＃50613](https://github.com/pingcap/tidb/issues/50613) @[Leavrth](https://github.com/Leavrth) - データ復元中に SST ファイルをバッチで取り込むことをサポート[＃16267](https://github.com/tikv/tikv/issues/16267) @[3pointer](https://github.com/3pointer) @@ -50,7 +50,7 @@ TiDB バージョン: 6.5.9 - ドロップされたテーブルがGrafana `Stats Healthy Distribution`パネルでまだカウントされる問題を修正 [＃39349](https://github.com/pingcap/tidb/issues/39349) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - SQL文のクエリに`MemTableScan`の演算子が含まれている場合、TiDBがSQL文の`WHERE `のフィルタリング条件を処理しない問題を修正しました。 [＃40937](https://github.com/pingcap/tidb/issues/40937) @[zhongzc](https://github.com/zhongzc) - サブクエリの`HAVING`句に相関列が含まれている場合にクエリ結果が正しくない可能性がある問題を修正しました。 [＃51107](https://github.com/pingcap/tidb/issues/51107) @[hawkingrei](https://github.com/hawkingrei) - - 共通テーブル式 (CTE) を使用して、統計情報が欠落しているパーティション テーブルにアクセスすると、クエリ結果が正しくなくなる可能性がある問題を修正しました[＃51873](https://github.com/pingcap/tidb/issues/51873) @[qw4990](https://github.com/qw4990) + - 共通テーブル式 (CTE) を使用して、統計情報が欠落しているパーティションテーブルにアクセスすると、クエリ結果が正しくなくなる可能性がある問題を修正しました[＃51873](https://github.com/pingcap/tidb/issues/51873) @[qw4990](https://github.com/qw4990) - SQL 文に`JOIN`が含まれ、文内の`SELECT`リストに定数のみが含まれる場合に、MPP を使用してクエリを実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました。 [＃50358](https://github.com/pingcap/tidb/issues/50358) @[yibin87](https://github.com/yibin87) - AUTO_INCREMENT ID を割り当てるときに、 `AUTO_INCREMENT`属性によって不要なトランザクション競合が発生し、ID が連続しなくなる問題を修正しました。 [＃50819](https://github.com/pingcap/tidb/issues/50819) @[tiancaiamao](https://github.com/tiancaiamao) - Grafana の監視メトリック`tidb_statistics_auto_analyze_total`整数として表示されない問題を修正しました [＃51051](https://github.com/pingcap/tidb/issues/51051) @[hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index 69968e1b57e06..6d2aa525486a8 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -47,13 +47,13 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - バッチ集計データ要求 [#39361](https://github.com/pingcap/tidb/issues/39361) @[cfzjywxk](https://github.com/cfzjywxk) @[you06](https://github.com/you06) - TiDB が TiKV にデータ要求を送信すると、TiDB はデータが存在するリージョンに応じて要求を複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンの要求のみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC 要求が発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータ要求を部分的にマージする機能をサポートしており、サブタスクの数と RPC 要求のオーバーヘッドを削減します。データの分散度が高く、gRPC スレッド プールのリソースが不足している場合、要求をバッチ処理することでパフォーマンスを 50% 以上向上させることができます。 + TiDB が TiKV にデータ要求を送信すると、TiDB はデータが存在するリージョンに応じて要求を複数のサブタスクにコンパイルし、各サブタスクは単一のリージョンの要求のみを処理します。アクセスするデータが高度に分散している場合、データのサイズが大きくなくても、多くのサブタスクが生成され、結果として多くの RPC 要求が発生し、余分な時間を消費します。v6.6.0 以降、TiDB は同じ TiKV インスタンスに送信されるデータ要求を部分的にマージする機能をサポートしており、サブタスクの数と RPC 要求のオーバーヘッドを削減します。データの分散度が高く、gRPC スレッドプールのリソースが不足している場合、要求をバッチ処理することでパフォーマンスを 50% 以上向上させることができます。 この機能はデフォルトで有効になっています。システム変数[`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size)を使用して、リクエストのバッチサイズを設定できます。 - `LIMIT`条項の制限を解除 [#40219](https://github.com/pingcap/tidb/issues/40219) @[fzzf678](https://github.com/fzzf678) - バージョン 6.6.0 以降、TiDB プラン キャッシュは`LIMIT`や`LIMIT ?`などの変数を`LIMIT 10, ?`パラメータとして指定した実行計画のキャッシュをサポートします。この機能により、より多くの SQL ステートメントがプラン キャッシュの恩恵を受けられるようになり、実行効率が向上します。現在、セキュリティ上の理由から、TiDB は`?`が 10000 を超えない実行計画のみをキャッシュできます。 + バージョン 6.6.0 以降、TiDB プランキャッシュは`LIMIT`や`LIMIT ?`などの変数を`LIMIT 10, ?`パラメータとして指定した実行計画のキャッシュをサポートします。この機能により、より多くの SQL ステートメントがプランキャッシュの恩恵を受けられるようになり、実行効率が向上します。現在、セキュリティ上の理由から、TiDB は`?`が 10000 を超えない実行計画のみをキャッシュできます。 詳細については、[ドキュメント](/sql-prepared-plan-cache.md)を参照してください。 @@ -75,7 +75,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone ### 信頼性 {#reliability} -- リソース グループに基づくリソース制御のサポート (実験的) [#38825](https://github.com/pingcap/tidb/issues/38825) @[nolouch](https://github.com/nolouch)@[BornChanger](https://github.com/BornChanger)@[glorv](https://github.com/glorv)@[tiancaiamao](https://github.com/tiancaiamao)@[Connor1996](https://github.com/Connor1996) @[JmPotato](https://github.com/JmPotato) @[hnes](https://github.com/hnes) @[CabinfeverB](https://github.com/CabinfeverB) @[HuSharp](https://github.com/HuSharp) +- リソースグループに基づくリソース制御のサポート (実験的) [#38825](https://github.com/pingcap/tidb/issues/38825) @[nolouch](https://github.com/nolouch)@[BornChanger](https://github.com/BornChanger)@[glorv](https://github.com/glorv)@[tiancaiamao](https://github.com/tiancaiamao)@[Connor1996](https://github.com/Connor1996) @[JmPotato](https://github.com/JmPotato) @[hnes](https://github.com/hnes) @[CabinfeverB](https://github.com/CabinfeverB) @[HuSharp](https://github.com/HuSharp) TiDBクラスタのリソースグループを作成し、異なるデータベースユーザーを対応するリソースグループにバインドし、実際のニーズに応じて各リソースグループのクォータを設定できるようになりました。クラスタのリソースが制限されている場合、同じリソースグループ内のセッションで使用されるすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。TiDBは、Grafanaダッシュボード上でリソースの実際の使用状況を表示する組み込みビューを提供し、リソースをより合理的に割り当てるのに役立ちます。 @@ -88,7 +88,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。 - v6.6 では、リソース制御を有効にするには、TiDB のグローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)と TiKV 設定項目[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)両方を有効にする必要があります。現在サポートされているクォータ方式は「 [リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) 」に基づいています。RU は、CPU や IO などのシステム リソースに対する TiDB の統一抽象化ユニットです。 + v6.6 では、リソース制御を有効にするには、TiDB のグローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)と TiKV 設定項目[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)両方を有効にする必要があります。現在サポートされているクォータ方式は「 [リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) 」に基づいています。RU は、CPU や IO などのシステムリソースに対する TiDB の統一抽象化ユニットです。 詳細については、[ドキュメント](/tidb-resource-control-ru-groups.md)を参照してください。 @@ -98,7 +98,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone 詳細については、 [ドキュメント](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)を参照してください。 -- いくつかのオプティマイザー ヒントを追加 [#39964](https://github.com/pingcap/tidb/issues/39964) @[Reminiscent](https://github.com/Reminiscent) +- いくつかのオプティマイザーヒントを追加 [#39964](https://github.com/pingcap/tidb/issues/39964) @[Reminiscent](https://github.com/Reminiscent) TiDB は v6.6.0 で`LIMIT`操作の実行計画の選択を制御するためのオプティマイザヒントをいくつか追加しました。 @@ -109,7 +109,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - DDL操作のリソース使用量を動的に管理するサポート（実験的） [#38025](https://github.com/pingcap/tidb/issues/38025) @[hawkingrei](https://github.com/hawkingrei) - TiDB v6.6.0 では、DDL 操作のリソース管理が導入されており、これらの操作の CPU 使用率を自動的に制御することで、オンライン アプリケーションに対する DDL 変更の影響を軽減します。この機能は[DDL分散並列実行フレームワーク](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660)が有効になった後にのみ有効です。 + TiDB v6.6.0 では、DDL 操作のリソース管理が導入されており、これらの操作の CPU 使用率を自動的に制御することで、オンラインアプリケーションに対する DDL 変更の影響を軽減します。この機能は[DDL分散並列実行フレームワーク](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660)が有効になった後にのみ有効です。 ### 可用性 {#availability} @@ -124,7 +124,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - `FLASHBACK CLUSTER TO TIMESTAMP`ステートメントによる DDL 操作のロールバックのサポート [#14045](https://github.com/tikv/tikv/issues/14045) @[Defined2014](https://github.com/Defined2014) @[JmPotato](https://github.com/JmPotato) - [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)ステートメントは、ガベージ コレクション (GC) の有効期間内の指定された時点にクラスタ全体を復元することをサポートします。TiDB v6.6.0 では、この機能に DDL 操作のロールバック機能が追加されました。これにより、クラスタ上で発生した DML または DDL 操作の誤りを迅速に取り消したり、クラスタを数分以内にロールバックしたり、タイムライン上でクラスタを複数回ロールバックして特定のデータ変更が発生したタイミングを特定したりすることができます。 + [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)ステートメントは、ガベージコレクション (GC) の有効期間内の指定された時点にクラスタ全体を復元することをサポートします。TiDB v6.6.0 では、この機能に DDL 操作のロールバック機能が追加されました。これにより、クラスタ上で発生した DML または DDL 操作の誤りを迅速に取り消したり、クラスタを数分以内にロールバックしたり、タイムライン上でクラスタを複数回ロールバックして特定のデータ変更が発生したタイミングを特定したりすることができます。 詳細については、 [ドキュメント](/sql-statements/sql-statement-flashback-cluster.md)を参照してください。 @@ -148,7 +148,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - リソースを大量に消費するタスク向けに読み取り専用ストレージノードを構成する機能をサポート @[v01dstar](https://github.com/v01dstar) - 本番環境では、バックアップや大規模なデータ読み取りと分析など、読み取り専用操作が定期的に大量のリソースを消費し、クラスタ全体のパフォーマンスに影響を与える場合があります。TiDB v6.6.0 では、リソースを消費する読み取り専用タスク用に読み取り専用ストレージノードを構成して、オンライン アプリケーションへの影響を軽減できます。現在、TiDB、TiSpark、およびBR は、読み取り専用ストレージノードからのデータ読み取りをサポートしています。 [手順](/best-practices/readonly-nodes.md#procedures)のパフォーマンスの安定性を確保するため、システム変数`tidb_replica_read` 、TiSpark 構成項目`spark.tispark.replica_read` 、または br コマンドライン引数`--replica-read-label` 、読み取り先を指定して、読み取り専用ストレージ ノードを次のように構成できます。 + 本番環境では、バックアップや大規模なデータ読み取りと分析など、読み取り専用操作が定期的に大量のリソースを消費し、クラスタ全体のパフォーマンスに影響を与える場合があります。TiDB v6.6.0 では、リソースを消費する読み取り専用タスク用に読み取り専用ストレージノードを構成して、オンラインアプリケーションへの影響を軽減できます。現在、TiDB、TiSpark、およびBR は、読み取り専用ストレージノードからのデータ読み取りをサポートしています。 [手順](/best-practices/readonly-nodes.md#procedures)のパフォーマンスの安定性を確保するため、システム変数`tidb_replica_read` 、TiSpark 構成項目`spark.tispark.replica_read` 、または br コマンドライン引数`--replica-read-label` 、読み取り先を指定して、読み取り専用ストレージ ノードを次のように構成できます。 詳細については、[ドキュメント](/best-practices/readonly-nodes.md)を参照してください。 @@ -160,7 +160,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - TiDBクラスタ初期化時に実行されるSQLスクリプトの指定をサポートする [#35624](https://github.com/pingcap/tidb/issues/35624) @[morgo](https://github.com/morgo) - TiDB クラスタを初めて起動する際に、コマンドライン パラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行する必要がある場合に使用できます。 + TiDB クラスタを初めて起動する際に、コマンドラインパラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行する必要がある場合に使用できます。 詳細については、 [ドキュメント](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)を参照してください。 @@ -172,7 +172,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone 詳細については、 [ドキュメント](/dm/dm-precheck.md#check-items-for-physical-import)を参照してください。 -- TiDB Lightning は、ソース ファイルとターゲット テーブル間の列名の不一致の問題に対処するため、新しい構成パラメータ`"header-schema-match"`を追加しました。@[dsdashun](https://github.com/dsdashun) +- TiDB Lightning は、ソースファイルとターゲットテーブル間の列名の不一致の問題に対処するため、新しい構成パラメータ`"header-schema-match"`を追加しました。@[dsdashun](https://github.com/dsdashun) TiDB Lightning v6.6.0では、新しいプロファイルパラメータ`"header-schema-match"`が追加されました。デフォルト値は`true`で、これはソースCSVファイルの最初の行が列名として扱われ、ターゲットテーブルの列名と一致することを意味します。CSVテーブルヘッダーのフィールド名がターゲットテーブルの列名と一致しない場合は、この設定を`false`に設定できます。TiDB Lightningはエラーを無視し、ターゲットテーブルの列の順序でデータのインポートを続行します。 @@ -315,21 +315,21 @@ 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`に対してのみ有効です。 | | [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | 新しく追加された | この変数は`PLAN REPLAYER CAPTURE`で取得される情報に、デフォルトで履歴統計が含まれるかどうかを制御します。デフォルト値の`OFF`は、デフォルトでは履歴統計が含まれないことを意味します。 | | [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | 新しく追加された | この変数は`Limit`の後に`COUNT`が含まれる実行計画をプリペアドプランキャッシュがキャッシュするかどうかを制御します。デフォルト値は`ON`で、これはプリペアドプランキャッシュ がそのような実行計画のキャッシュをサポートすることを意味します。ただし、 プリペアドプランキャッシュ は、 10000 を超える数値をカウントする`COUNT`条件を含む実行計画のキャッシュをサポートしていないことに注意してください。 | -| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値は`OFF`です。この変数を`ON`に設定すると、TiDB クラスタはリソース グループに基づいたアプリケーションのリソース分離をサポートします。 | +| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値は`OFF`です。この変数を`ON`に設定すると、TiDB クラスタはリソースグループに基づいたアプリケーションのリソース分離をサポートします。 | | [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-new-in-v660) | 新しく追加された | この変数は、過去の統計情報をストレージに保存する期間を制御します。デフォルト値は7日間です。 | | [`tidb_index_join_double_read_penalty_cost_rate`](/system-variables.md#tidb_index_join_double_read_penalty_cost_rate-new-in-v660) | 新しく追加された | この変数は、インデックス結合の選択にペナルティコストを追加するかどうかを制御します。デフォルト値`0`は、この機能がデフォルトで無効になっていることを意味します。 | | [`tidb_pessimistic_txn_aggressive_locking`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660) | 新しく追加された | この変数は、悲観的トランザクションに対して拡張悲観的ロックウェイクアップモデルを使用するかどうかを制御します。デフォルト値`OFF`は、デフォルトでは悲観的トランザクションに対してこのようなウェイクアップモデルを使用しないことを意味します。 | | [`tidb_stmt_summary_enable_persistent`](/system-variables.md#tidb_stmt_summary_enable_persistent-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)を有効にするかどうかを制御します。この変数の値は、構成項目[`tidb_stmt_summary_enable_persistent`](/tidb-configuration-file.md#tidb_stmt_summary_enable_persistent-new-in-v660)の値と同じです。 | | [`tidb_stmt_summary_filename`](/system-variables.md#tidb_stmt_summary_filename-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に永続データが書き込まれるファイルを指定します。この変数の値は、構成項目[`tidb_stmt_summary_filename`](/tidb-configuration-file.md#tidb_stmt_summary_filename-new-in-v660)の値と同じです。 | -| [`tidb_stmt_summary_file_max_backups`](/system-variables.md#tidb_stmt_summary_file_max_backups-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に保存できるデータ ファイルの最大数を指定します。この変数の値は、構成項目[`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660)の値と同じです。 | -| [`tidb_stmt_summary_file_max_days`](/system-variables.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に、永続的なデータ ファイルを保持する最大日数を指定します。この変数の値は、構成項目[`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`](/system-variables.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合の永続データ ファイルの最大サイズを指定します。この変数の値は、構成項目[`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`](/system-variables.md#tidb_stmt_summary_file_max_backups-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に保存できるデータファイルの最大数を指定します。この変数の値は、構成項目[`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660)の値と同じです。 | +| [`tidb_stmt_summary_file_max_days`](/system-variables.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に、永続的なデータファイルを保持する最大日数を指定します。この変数の値は、構成項目[`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`](/system-variables.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合の永続データファイルの最大サイズを指定します。この変数の値は、構成項目[`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660)の値と同じです。 | ### コンフィグレーションファイルパラメータ {#configuration-file-parameters} @@ -352,7 +352,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | TiDB | [`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | 明細書の要約データの永続化が有効になっている場合、この設定では永続データファイルを保持する最大日数を指定します。 | | TiDB | [`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | ステートメントサマリーの永続化が有効になっている場合、この設定では永続データファイルの最大サイズ（MiB単位）を指定します。 | | TiDB | [`tidb_stmt_summary_filename`](/tidb-configuration-file.md#tidb_stmt_summary_filename-new-in-v660) | 新しく追加された | 明細書の要約データの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 | -| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソース グループの要求単位 (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソース グループの RU に基づくスケジューリングを無効にすることを意味します。 | +| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソースグループの要求単位 (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソースグループの RU に基づくスケジューリングを無効にすることを意味します。 | | TiKV | [`storage.engine`](/tikv-configuration-file.md#engine-new-in-v660) | 新しく追加された | この構成項目は、ストレージエンジンのタイプを指定します。値のオプションは`"raft-kv"`と`"partitioned-raft-kv"`です。この構成項目は、クラスタ作成時にのみ指定でき、一度指定すると変更できません。 | | TiKV | [`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660) | 新しく追加された | この設定項目は、現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 | | TiKV | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 新しく追加された | この設定項目は、単一の TiKV 内のすべての RocksDB インスタンス`memtable`が使用する合計メモリの制限を指定します。デフォルト値は、マシン全体のメモリの 25% です。 | @@ -387,8 +387,8 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - 警告メッセージ生成後のステートメントの実行効率を最適化する [#39702](https://github.com/pingcap/tidb/issues/39702) @[tiancaiamao](https://github.com/tiancaiamao) - `ADD INDEX`の分散データバックフィルをサポート（実験的） [#37119](https://github.com/pingcap/tidb/issues/37119) @[zimulala](https://github.com/zimulala) - `CURDATE()`を列のデフォルト値として使用することをサポートします [#38356](https://github.com/pingcap/tidb/issues/38356) @[CbcWestwolf](https://github.com/CbcWestwolf) - - `partial order prop push down`が LIST 型のパーティション テーブルをサポートするようになりました [#40273](https://github.com/pingcap/tidb/issues/40273) @[winoros](https://github.com/winoros) - - オプティマイザーのヒントと実行計画のバインディング間の競合に関するエラー メッセージを追加 [#40910](https://github.com/pingcap/tidb/issues/40910) @[Reminiscent](https://github.com/Reminiscent) + - `partial order prop push down`が LIST 型のパーティションテーブルをサポートするようになりました [#40273](https://github.com/pingcap/tidb/issues/40273) @[winoros](https://github.com/winoros) + - オプティマイザーのヒントと実行計画のバインディング間の競合に関するエラーメッセージを追加 [#40910](https://github.com/pingcap/tidb/issues/40910) @[Reminiscent](https://github.com/Reminiscent) - プランキャッシュ戦略を最適化し、一部のシナリオでプランキャッシュを使用する際に最適でないプランを回避する[#40312](https://github.com/pingcap/tidb/pull/40312) [#40218](https://github.com/pingcap/tidb/pull/40218) [#40280](https://github.com/pingcap/tidb/pull/40280) [#41136](https://github.com/pingcap/tidb/pull/41136) [#40686](https://github.com/pingcap/tidb/pull/40686) @[qw4990](https://github.com/qw4990) - メモリリークとパフォーマンスの低下を避けるために、期限切れの領域キャッシュを定期的にクリアします [#40461](https://github.com/pingcap/tidb/issues/40461) @[sticnarf](https://github.com/sticnarf) - `MODIFY COLUMN`はパーティションテーブルではサポートされていません [#39915](https://github.com/pingcap/tidb/issues/39915) @[wjhuang2016](https://github.com/wjhuang2016) @@ -429,7 +429,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - TiDB Data Migration (DM) - - DM アラート ルールとコンテンツを最適化 [#7376](https://github.com/pingcap/tiflow/issues/7376) @[D3Hunter](https://github.com/D3Hunter) + - DM アラートルールとコンテンツを最適化 [#7376](https://github.com/pingcap/tiflow/issues/7376) @[D3Hunter](https://github.com/D3Hunter) 従来は、関連するエラーが発生するたびに「DM_XXX_process_exits_with_error」のようなアラートが発生していました。しかし、一部のアラートはアイドル状態のデータベース接続が原因で発生し、再接続後に回復できる場合があります。このようなアラートを減らすため、DMはエラーを自動的に回復可能なエラーと回復不可能なエラーの2種類に分類します。 @@ -504,7 +504,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - TiKV - `const Enum`型を他の型にキャストする際に発生するエラーを修正します [#14156](https://github.com/tikv/tikv/issues/14156) @[wshwsh12](https://github.com/wshwsh12) - - 解決された TS によりネットワーク トラフィックが増加する問題を修正 [#14092](https://github.com/tikv/tikv/issues/14092) @[overvenus](https://github.com/overvenus) + - 解決された TS によりネットワークトラフィックが増加する問題を修正 [#14092](https://github.com/tikv/tikv/issues/14092) @[overvenus](https://github.com/overvenus) - TiDBとTiKV間のネットワーク障害によって発生するデータ不整合の問題を修正。DML実行中に悲観的DMLが失敗した後に発生するデータ不整合の問題を修正 [#14038](https://github.com/tikv/tikv/issues/14038) @[MyonKeminta](https://github.com/MyonKeminta) - PD @@ -558,7 +558,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - 事前チェックでターゲットクラスター内で実行中の TiCDC の存在を正確に検出できない問題を修正します [#41040](https://github.com/pingcap/tidb/issues/41040) @[lance6716](https://github.com/lance6716) - TiDB Lightningが分割リージョンフェーズでパニックを起こす問題を修正 [#40934](https://github.com/pingcap/tidb/issues/40934) @[lance6716](https://github.com/lance6716) - 競合解決ロジック ( `duplicate-resolution` ) がチェックサムの不一致を引き起こす可能性がある問題を修正 [#40657](https://github.com/pingcap/tidb/issues/40657) @[sleepymole](https://github.com/sleepymole) - - データ ファイルに閉じられていない区切り文字がある場合に発生する可能性のある OOM 問題を修正 [#40400](https://github.com/pingcap/tidb/issues/40400) @[buchuitoudegou](https://github.com/buchuitoudegou) + - データファイルに閉じられていない区切り文字がある場合に発生する可能性のある OOM 問題を修正 [#40400](https://github.com/pingcap/tidb/issues/40400) @[buchuitoudegou](https://github.com/buchuitoudegou) - エラーレポート内のファイルオフセットがファイルサイズを超える問題を修正 [#40034](https://github.com/pingcap/tidb/issues/40034) @[buchuitoudegou](https://github.com/buchuitoudegou) - PDClient の新しいバージョンで並列インポートが失敗する可能性がある問題を修正 [#40493](https://github.com/pingcap/tidb/issues/40493) @[AmoebaProtozoa](https://github.com/AmoebaProtozoa) - TiDB Lightningの事前チェックで、以前のインポート失敗によって残されたダーティデータを見つけられない問題を修正 [#39477](https://github.com/pingcap/tidb/issues/39477) @[dsdashun](https://github.com/dsdashun) diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index 38a953f5e9286..d85edb5d472df 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -89,7 +89,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - Fast Online DDL による一意インデックス作成のサポート [#40730](https://github.com/pingcap/tidb/issues/40730) @[tangenta](https://github.com/tangenta) - TiDB v6.5.0 では、Fast Online DDL による通常のセカンダリ インデックスの作成がサポートされています。TiDB v7.0.0 では、Fast Online DDL によるユニーク インデックスの作成がサポートされています。v6.1.0 と比較して、大規模テーブルへのユニーク インデックスの追加は、パフォーマンスの向上により数倍高速化されることが期待されます。 + TiDB v6.5.0 では、Fast Online DDL による通常のセカンダリインデックスの作成がサポートされています。TiDB v7.0.0 では、Fast Online DDL によるユニーク インデックスの作成がサポートされています。v6.1.0 と比較して、大規模テーブルへのユニーク インデックスの追加は、パフォーマンスの向上により数倍高速化されることが期待されます。 詳細については、[ドキュメント](/best-practices/ddl-introduction.md)を参照してください。 @@ -131,14 +131,14 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone バージョン7.0.0では、TiDBは統計情報の収集ロジックをさらに最適化し、収集時間を約25%短縮しました。この最適化により、大規模データベースクラスタの運用効率と安定性が向上し、統計情報の収集がクラスタのパフォーマンスに与える影響が軽減されます。 -- MPP 最適化のための新しいオプティマイザー ヒントを追加 [#39710](https://github.com/pingcap/tidb/issues/39710) @[Reminiscent](https://github.com/Reminiscent) +- MPP 最適化のための新しいオプティマイザーヒントを追加 [#39710](https://github.com/pingcap/tidb/issues/39710) @[Reminiscent](https://github.com/Reminiscent) バージョン7.0.0では、TiDBはMPP実行計画の生成に影響を与える一連のオプティマイザヒントを追加しました。 - [`SHUFFLE_JOIN()`](/optimizer-hints.md#shuffle_joint1_name--tl_name-) : MPP で有効になります。指定されたテーブルに対してシャッフル結合アルゴリズムを使用するようにオプティマイザに指示します。 - [`BROADCAST_JOIN()`](/optimizer-hints.md#broadcast_joint1_name--tl_name-) : MPP で有効になります。指定されたテーブルに対してブロードキャスト結合アルゴリズムを使用するようにオプティマイザに指示します。 - [`MPP_1PHASE_AGG()`](/optimizer-hints.md#mpp_1phase_agg) ：MPP（最大パフォーマンス）に有効です。指定されたクエリブロック内のすべての集計関数に対して、オプティマイザに1フェーズ集計アルゴリズムを使用するように指示します。 - - [`MPP_2PHASE_AGG()`](/optimizer-hints.md#mpp_2phase_agg) : MPP で有効になります。指定されたクエリ ブロック内のすべての集計関数に対して、2 段階集計アルゴリズムを使用するようにオプティマイザに指示します。 + - [`MPP_2PHASE_AGG()`](/optimizer-hints.md#mpp_2phase_agg) : MPP で有効になります。指定されたクエリブロック内のすべての集計関数に対して、2 段階集計アルゴリズムを使用するようにオプティマイザに指示します。 MPPオプティマイザのヒントを使用すると、HTAPクエリに介入して、HTAPワークロードのパフォーマンスと安定性を向上させることができます。 @@ -156,7 +156,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - `prefer-leader`オプションをサポートします。このオプションは、読み取り操作の可用性を高め、不安定なネットワーク状況での応答レイテンシーを低減します。 [#40905](https://github.com/pingcap/tidb/issues/40905) @[LykxSassinator](https://github.com/LykxSassinator) - TiDB のデータ読み取り動作は、システム変数[`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)で制御できます。v7.0.0 では、この変数に`prefer-leader`オプションが追加されました。この変数を`prefer-leader`に設定すると、TiDB はリーダー レプリカを選択して読み取り操作を実行することを優先します。ディスクやネットワークのパフォーマンス変動などによりリーダー レプリカの処理速度が著しく低下した場合、TiDB は利用可能な他のフォロワー レプリカを選択して読み取り操作を実行し、可用性を高め、応答レイテンシーを削減します。 + TiDB のデータ読み取り動作は、システム変数[`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)で制御できます。v7.0.0 では、この変数に`prefer-leader`オプションが追加されました。この変数を`prefer-leader`に設定すると、TiDB はリーダーレプリカを選択して読み取り操作を実行することを優先します。ディスクやネットワークのパフォーマンス変動などによりリーダーレプリカの処理速度が著しく低下した場合、TiDB は利用可能な他のフォロワー レプリカを選択して読み取り操作を実行し、可用性を高め、応答レイテンシーを削減します。 詳細については、[ドキュメント](/develop/dev-guide-use-follower-read.md)を参照してください。 @@ -209,7 +209,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - `LOAD DATA`ステートメントの機能を強化し、クラウドストレージからのデータインポートをサポートする (実験的) [#40499](https://github.com/pingcap/tidb/issues/40499) @[lance6716](https://github.com/lance6716) - TiDB v7.0.0 より前は、 `LOAD DATA`ステートメントではクライアント側からのデータ ファイルのインポートしかできませんでした。クラウドストレージからデータをインポートするには、 TiDB Lightningを使用する必要がありました。しかし、 TiDB Lightning を別途デプロイすると、追加のデプロイおよび管理コストが発生します。v7.0.0 では、 `LOAD DATA`ステートメントを使用してクラウドストレージから直接データをインポートできます。この機能の例を以下に示します。 + TiDB v7.0.0 より前は、 `LOAD DATA`ステートメントではクライアント側からのデータファイルのインポートしかできませんでした。クラウドストレージからデータをインポートするには、 TiDB Lightningを使用する必要がありました。しかし、 TiDB Lightning を別途デプロイすると、追加のデプロイおよび管理コストが発生します。v7.0.0 では、 `LOAD DATA`ステートメントを使用してクラウドストレージから直接データをインポートできます。この機能の例を以下に示します。 - Amazon S3およびGoogle Cloud StorageからTiDBへのデータインポートをサポートします。ワイルドカードを使用して、複数のソースファイルを一度にTiDBにインポートすることをサポートします。 - `DEFINED NULL BY`を使用して null を定義することをサポートします。 @@ -365,7 +365,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - MQ シンクに Large Row モニタリング メトリクスを追加します [#8286](https://github.com/pingcap/tiflow/issues/8286) @[Rustin170506](https://github.com/Rustin170506) - - リージョンに複数のテーブルのデータが含まれるシナリオで、TiKV ノードと TiCDC ノード間のネットワーク トラフィックを削減します [#6346](https://github.com/pingcap/tiflow/issues/6346) @[overvenus](https://github.com/overvenus) + - リージョンに複数のテーブルのデータが含まれるシナリオで、TiKV ノードと TiCDC ノード間のネットワークトラフィックを削減します [#6346](https://github.com/pingcap/tiflow/issues/6346) @[overvenus](https://github.com/overvenus) - Checkpoint TSとResolved TSのP99メトリクスパネルをラグ分析パネルに移動します [#8524](https://github.com/pingcap/tiflow/issues/8524) @[Rustin170506](https://github.com/Rustin170506) @@ -375,7 +375,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - TiDB Lightning - - TiDB Lightning物理インポート モードは、データ インポートとインデックス インポートの分離をサポートし、インポート速度と安定性を向上させます [#42132](https://github.com/pingcap/tidb/issues/42132) @[sleepymole](https://github.com/sleepymole) + - TiDB Lightning物理インポートモードは、データインポートとインデックス インポートの分離をサポートし、インポート速度と安定性を向上させます [#42132](https://github.com/pingcap/tidb/issues/42132) @[sleepymole](https://github.com/sleepymole) `add-index-by-sql`パラメータを追加します。デフォルト値は`false`で、これはTiDB Lightning が行データとインデックスデータの両方を KV ペアにエンコードし、それらをまとめて TiKV にインポートすることを意味します。これを`true`に設定すると、 TiDB Lightningデータのインポート後に`ADD INDEX` SQL ステートメントを使用してインデックスを追加し、インポートの速度と安定性を向上させます。 @@ -396,7 +396,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - プリペアドプランキャッシュが有効になっている場合に、フルインデックススキャンでエラーが発生する可能性がある問題を修正しました [#42150](https://github.com/pingcap/tidb/issues/42150) @[fzzf678](https://github.com/fzzf678) - `IFNULL(NOT NULL COLUMN, ...)`が間違った結果を返す可能性がある問題を修正 [#41734](https://github.com/pingcap/tidb/issues/41734) @[LittleFall](https://github.com/LittleFall) - パーティションテーブル内のすべてのデータが単一のリージョンにある場合に、TiDBが誤った結果を生成する可能性がある問題を修正します [#41801](https://github.com/pingcap/tidb/issues/41801) @[Defined2014](https://github.com/Defined2014) - - TiDB で、異なるパーティション テーブルが単一の SQL ステートメントに現れる場合に誤った結果が生成される可能性がある問題を修正しました [#42135](https://github.com/pingcap/tidb/issues/42135) @[mjonss](https://github.com/mjonss) + - TiDB で、異なるパーティションテーブルが単一の SQL ステートメントに現れる場合に誤った結果が生成される可能性がある問題を修正しました [#42135](https://github.com/pingcap/tidb/issues/42135) @[mjonss](https://github.com/mjonss) - パーティションテーブルに新しいインデックスを追加した後、パーティションパーティションテーブルで統計情報の自動収集が正しくトリガーされない可能性がある問題を修正しました [#41638](https://github.com/pingcap/tidb/issues/41638) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - TiDBが統計情報を2回連続で収集した後に誤った列統計情報を読み取る可能性がある問題を修正 [#42073](https://github.com/pingcap/tidb/issues/42073) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - プリペアドプランキャッシュが有効になっている場合に IndexMerge が誤った結果を生成する可能性がある問題を修正しました [#41828](https://github.com/pingcap/tidb/issues/41828) @[qw4990](https://github.com/qw4990) @@ -404,7 +404,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - 非 BIGINT 符号なし整数が文字列/10 進数と比較したときに誤った結果を生成する可能性がある問題を修正 [#41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) - メモリ制限超過により以前の`ANALYZE`ステートメントが強制終了されると、同じセッション内の現在の`ANALYZE`ステートメントも強制終了される可能性がある問題を修正しました [#41825](https://github.com/pingcap/tidb/issues/41825) @[XuHuaiyu](https://github.com/XuHuaiyu) - バッチコプロセッサの情報収集プロセス中にデータ競合が発生する可能性がある問題を修正しました [#41412](https://github.com/pingcap/tidb/issues/41412) @[you06](https://github.com/you06) - - アサーション エラーによりパーティション テーブルの MVCC 情報が印刷できない問題を修正 [#40629](https://github.com/pingcap/tidb/issues/40629) @[ekexium](https://github.com/ekexium) + - アサーション エラーによりパーティションテーブルの MVCC 情報が印刷できない問題を修正 [#40629](https://github.com/pingcap/tidb/issues/40629) @[ekexium](https://github.com/ekexium) - フェアロックモードで存在しないキーにロックが追加される問題を修正 [#41527](https://github.com/pingcap/tidb/issues/41527) @[ekexium](https://github.com/ekexium) - `INSERT IGNORE`および`REPLACE`ステートメントが値を変更しないキーをロックしない問題を修正 [#42121](https://github.com/pingcap/tidb/issues/42121) @[zyguan](https://github.com/zyguan) @@ -438,7 +438,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - `stopped`ステータスの変更フィードが自動的に再起動する可能性がある問題を修正 [#8330](https://github.com/pingcap/tiflow/issues/8330) @[sdojjy](https://github.com/sdojjy) - すべてのダウンストリーム Kafka サーバーが利用できないときに TiCDCサーバーがパニックになる問題を修正 [#8523](https://github.com/pingcap/tiflow/issues/8523) @[3AceShowHand](https://github.com/3AceShowHand) - ダウンストリームがMySQLで、実行されたステートメントがTiDBと互換性がない場合にデータが失われる可能性がある問題を修正します [#8453](https://github.com/pingcap/tiflow/issues/8453) @[asddongmen](https://github.com/asddongmen) - - ローリング アップグレードが TiCDC OOM を引き起こす可能性がある問題、またはチェックポイントがスタックする問題を修正 [#8329](https://github.com/pingcap/tiflow/issues/8329) @[overvenus](https://github.com/overvenus) + - ローリングアップグレードが TiCDC OOM を引き起こす可能性がある問題、またはチェックポイントがスタックする問題を修正 [#8329](https://github.com/pingcap/tiflow/issues/8329) @[overvenus](https://github.com/overvenus) - Kubernetes で TiCDC クラスターの正常なアップグレードが失敗する問題を修正 [#8484](https://github.com/pingcap/tiflow/issues/8484) @[overvenus](https://github.com/overvenus) - TiDB Data Migration (DM) diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index ecb61edd721db..40123885c1ace 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -33,7 +33,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiFlashは遅延マテリアライゼーション（GA） をサポートします [＃5829](https://github.com/pingcap/tiflash/issues/5829) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - v7.0.0 では、クエリ パフォーマンスを最適化するための実験的機能として、 TiFlashに遅延マテリアライゼーションが導入されました。この機能はデフォルトでは無効になっています ( [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)システム変数はデフォルトで`OFF`に設定されます)。フィルタ条件 ( `WHERE`句) を含む`SELECT`ステートメントを処理する場合、 TiFlash はクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルタリングおよび集計します。遅延マテリアライゼーションを有効にすると、TiDB はフィルタ条件の一部を TableScan 演算子にプッシュ ダウンすることをサポートします。つまり、 TiFlash は最初に TableScan 演算子にプッシュ ダウンされるフィルタ条件に関連する列データをスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列データをスキャンしてさらに計算を行うため、IO スキャンとデータ処理の計算が削減されます。 + v7.0.0 では、クエリパフォーマンスを最適化するための実験的機能として、 TiFlashに遅延マテリアライゼーションが導入されました。この機能はデフォルトでは無効になっています ( [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)システム変数はデフォルトで`OFF`に設定されます)。フィルタ条件 ( `WHERE`句) を含む`SELECT`ステートメントを処理する場合、 TiFlash はクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルタリングおよび集計します。遅延マテリアライゼーションを有効にすると、TiDB はフィルタ条件の一部を TableScan 演算子にプッシュダウンすることをサポートします。つまり、 TiFlash は最初に TableScan 演算子にプッシュダウンされるフィルタ条件に関連する列データをスキャンし、条件を満たす行をフィルタリングしてから、これらの行の他の列データをスキャンしてさらに計算を行うため、IO スキャンとデータ処理の計算が削減されます。 バージョン7.1.0以降、 TiFlashの遅延マテリアライゼーション機能が一般提供され、デフォルトで有効化されています（システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)はデフォルトで`ON`に設定されています）。TiDBオプティマイザーは、クエリの統計情報とフィルター条件に基づいて、TableScan演算子にプッシュダウンするフィルターを決定します。 @@ -200,7 +200,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiFlashシステムテーブル情報のクエリに使用されるインターフェイスを置き換えます[＃6941](https://github.com/pingcap/tiflash/issues/6941) @[flowbehappy](https://github.com/flowbehappy) - v7.1.0 以降、TiDB の[`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md)および[`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md)システム テーブルのクエリ サービスを提供する際に、 TiFlash はHTTP ポートではなく gRPC ポートを使用するようになりました。これにより、HTTP サービスのセキュリティ リスクが回避されます。 + v7.1.0 以降、TiDB の[`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md)および[`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md)システムテーブルのクエリサービスを提供する際に、 TiFlash はHTTP ポートではなく gRPC ポートを使用するようになりました。これにより、HTTP サービスのセキュリティリスクが回避されます。 - LDAP認証をサポート [＃43580](https://github.com/pingcap/tidb/issues/43580) @[YangKeao](https://github.com/YangKeao) @@ -210,12 +210,12 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - データベース監査機能の強化（Enterprise Edition） - v7.1.0 では、TiDB Enterprise Edition でデータベース監査機能が強化され、その機能が大幅に拡張され、ユーザー エクスペリエンスが向上して、企業のデータベース セキュリティ コンプライアンスのニーズに対応できるようになりました。 + v7.1.0 では、TiDB Enterprise Edition でデータベース監査機能が強化され、その機能が大幅に拡張され、ユーザーエクスペリエンスが向上して、企業のデータベース セキュリティ コンプライアンスのニーズに対応できるようになりました。 - より詳細な監査イベント定義とよりきめ細かな監査設定のために、「フィルター」と「ルール」の概念を導入します。 - JSON 形式でのルールの定義をサポートし、よりユーザーフレンドリーな構成方法を提供します。 - 自動ログローテーションとスペース管理関数を追加し、保持時間とログサイズの 2 つの次元でのログローテーションの構成をサポートします。 - - 監査ログをTEXTと JSON 形式の両方で出力できるようにすることで、サードパーティ ツールとの統合が容易になります。 + - 監査ログをTEXTと JSON 形式の両方で出力できるようにすることで、サードパーティツールとの統合が容易になります。 - 監査ログの秘匿化をサポートします。セキュリティ強化のため、すべてのリテラルを置き換えることができます。 データベース監査は、TiDB Enterprise Editionの重要な機能です。この機能は、企業のデータセキュリティとコンプライアンスを確保するための強力な監視・監査ツールを提供します。企業の管理者は、データベース操作の発生源と影響を追跡し、不正なデータ盗難や改ざんを防止することができます。さらに、データベース監査は、企業が様々な規制やコンプライアンス要件を満たし、法的および倫理的コンプライアンスを確保するのにも役立ちます。この機能は、企業の情報セキュリティにとって重要なアプリケーション価値を持っています。 @@ -232,9 +232,9 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - セキュリティを向上させるために、 TiFlashはHTTPサービスポート（デフォルト`8123` ）を廃止し、代わりにgRPCポートを使用します。 - TiFlash をv7.1.0 にアップグレードした場合、TiDB を v7.1.0 にアップグレードする際に、TiDB はTiFlashシステム テーブル ( [`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md)と[`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md) ) を読み取ることができません。 + TiFlash をv7.1.0 にアップグレードした場合、TiDB を v7.1.0 にアップグレードする際に、TiDB はTiFlashシステムテーブル ( [`INFORMATION_SCHEMA.TIFLASH_TABLES`](/information-schema/information-schema-tiflash-tables.md)と[`INFORMATION_SCHEMA.TIFLASH_SEGMENTS`](/information-schema/information-schema-tiflash-segments.md) ) を読み取ることができません。 -- TiDB バージョン v6.2.0 から v7.0.0 のTiDB Lightning は、TiDB クラスターのバージョンに基づいてグローバル スケジューリングを一時停止するかどうかを決定します。TiDB クラスター バージョン >= v6.1.0 の場合、スケジュールはターゲット テーブル データを格納するリージョンに対してのみ一時停止され、ターゲット テーブルのインポートが完了すると再開されます。その他のバージョンの場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。TiDB v7.1.0 以降では、 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)設定することで、グローバル スケジューリングを一時停止するかどうかを制御できます。デフォルトでは、 TiDB Lightning はターゲット テーブル データを格納するリージョンのスケジュールを一時停止します。ターゲット クラスターのバージョンが v6.1.0 より前の場合、エラーが発生します。この場合、パラメータの値を`"global"`に変更して再試行できます。 +- TiDB バージョン v6.2.0 から v7.0.0 のTiDB Lightning は、TiDB クラスターのバージョンに基づいてグローバルスケジューリングを一時停止するかどうかを決定します。TiDB クラスター バージョン >= v6.1.0 の場合、スケジュールはターゲットテーブルデータを格納するリージョンに対してのみ一時停止され、ターゲットテーブルのインポートが完了すると再開されます。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。TiDB v7.1.0 以降では、 [`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)設定することで、グローバルスケジューリングを一時停止するかどうかを制御できます。デフォルトでは、 TiDB Lightning はターゲットテーブルデータを格納するリージョンのスケジュールを一時停止します。ターゲットクラスターのバージョンが v6.1.0 より前の場合、エラーが発生します。この場合、パラメータの値を`"global"`に変更して再試行できます。 - TiDB v7.1.0で[`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)を使用すると、FLASHBACK操作が完了した後も、一部のリージョンがFLASHBACKプロセスに残る可能性があります。v7.1.0ではこの機能の使用を避けることをお勧めします。詳細については、問題を参照してください。この問題が発生した場合は、機能[TiDBスナップショットのバックアップと復元](/br/br-snapshot-guide.md)を使用してデータを復元できます。 [＃44292](https://github.com/pingcap/tidb/issues/44292) @@ -273,7 +273,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-new-in-v710) | 新しく追加された | DML ステートメントに対して[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)機能を有効にするかどうかを制御します。 | | [`tidb_enable_row_level_checksum`](/system-variables.md#tidb_enable_row_level_checksum-new-in-v710) | 新しく追加された | 単一行データ機能に対して TiCDC データ整合性検証を有効にするかどうかを制御します。 | | [`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710) | 新しく追加された | この変数は、オプティマイザをより細かく制御し、オプティマイザの動作の変更によって引き起こされるアップグレード後のパフォーマンスの低下を防ぐのに役立ちます。 | -| [`tidb_plan_cache_invalidation_on_fresh_stats`](/system-variables.md#tidb_plan_cache_invalidation_on_fresh_stats-new-in-v710) | 新しく追加された | 関連テーブルの統計が更新されたときにプラン キャッシュを自動的に無効にするかどうかを制御します。 | +| [`tidb_plan_cache_invalidation_on_fresh_stats`](/system-variables.md#tidb_plan_cache_invalidation_on_fresh_stats-new-in-v710) | 新しく追加された | 関連テーブルの統計が更新されたときにプランキャッシュを自動的に無効にするかどうかを制御します。 | | [`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-new-in-v710) | 新しく追加された | プリペアドプランキャッシュまたは非プリペアドプランキャッシュにキャッシュできるプランの最大サイズを制御します。 | | [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) | 新しく追加された | ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 | | [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710) | 新しく追加された | キャッシュできるプランの最大数を制御します。プリペアドプランキャッシュと非プリペアドプランキャッシュは同じキャッシュを共有します。 | @@ -362,15 +362,15 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `DROP TABLE`操作が実行されているときに`ADMIN SHOW DDL JOBS`結果にテーブル名が表示されない問題を修正[＃42268](https://github.com/pingcap/tidb/issues/42268) @[tiancaiamao](https://github.com/tiancaiamao) - Grafana モニタリング パネルで`Ignore Event Per Minute`と`Stats Cache LRU Cost`チャートが正常に表示されないことがある問題を修正しました [＃42562](https://github.com/pingcap/tidb/issues/42562) @[pingandb](https://github.com/pingandb) - `INFORMATION_SCHEMA.COLUMNS`テーブルをクエリするときに`ORDINAL_POSITION`列が誤った結果を返す問題を修正しました [＃43379](https://github.com/pingcap/tidb/issues/43379) @[bb7133](https://github.com/bb7133) - - キャッシュ テーブルに新しい列が追加された後、列のデフォルト値ではなく値が`NULL`になる問題を修正しました。 [＃42928](https://github.com/pingcap/tidb/issues/42928) @[lqs](https://github.com/lqs) + - キャッシュテーブルに新しい列が追加された後、列のデフォルト値ではなく値が`NULL`になる問題を修正しました。 [＃42928](https://github.com/pingcap/tidb/issues/42928) @[lqs](https://github.com/lqs) - 述語をプッシュダウンするときに CTE 結果が正しくない問題を修正しました [＃43645](https://github.com/pingcap/tidb/issues/43645) @[winoros](https://github.com/winoros) - - 多数のパーティションとTiFlashレプリカを持つパーティション テーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) + - 多数のパーティションとTiFlashレプリカを持つパーティションテーブルに対して`TRUNCATE TABLE`を実行するときに書き込み競合によって発生する DDL 再試行の問題を修正しました。 [＃42940](https://github.com/pingcap/tidb/issues/42940) @[mjonss](https://github.com/mjonss) - パーティションテーブル の作成時に`SUBPARTITION`を使用すると警告が表示されない問題を修正 [＃41200](https://github.com/pingcap/tidb/issues/41200) @[mjonss](https://github.com/mjonss) [＃41198](https://github.com/pingcap/tidb/issues/41198) - 生成列の値オーバーフローの問題を処理する際の MySQL との非互換性の問題を修正しました [＃40066](https://github.com/pingcap/tidb/issues/40066) @[jiyfhust](https://github.com/jiyfhust) - `REORGANIZE PARTITION`他の DDL 操作と同時に実行できない問題を修正 [＃42442](https://github.com/pingcap/tidb/issues/42442) @[bb7133](https://github.com/bb7133) - DDL でパーティション再編成タスクをキャンセルすると、後続の DDL 操作が失敗する可能性がある問題を修正しました[＃42448](https://github.com/pingcap/tidb/issues/42448) @[lcwangchao](https://github.com/lcwangchao) - 特定の条件下で削除操作のアサーションが正しくない問題を修正[＃42426](https://github.com/pingcap/tidb/issues/42426) @[tiancaiamao](https://github.com/tiancaiamao) - - cgroup 情報の読み取りエラーにより、TiDBサーバーが起動できない問題を修正しました。エラー メッセージは「cgroup v1 からファイルメモリ.stat を読み取れません: open /sys/ メモリ.stat no such file or directory」です[＃42659](https://github.com/pingcap/tidb/issues/42659) @[hawkingrei](https://github.com/hawkingrei) + - cgroup 情報の読み取りエラーにより、TiDBサーバーが起動できない問題を修正しました。エラーメッセージは「cgroup v1 からファイルメモリ.stat を読み取れません: open /sys/ メモリ.stat no such file or directory」です[＃42659](https://github.com/pingcap/tidb/issues/42659) @[hawkingrei](https://github.com/hawkingrei) - グローバルインデックスを持つパーティションテーブルの行のパーティションキーを更新するときに発生する`Duplicate Key`問題を修正しました [＃42312](https://github.com/pingcap/tidb/issues/42312) @[L-maple](https://github.com/L-maple) - TTLモニタリングパネルの`Scan Worker Time By Phase`チャートにデータが表示されない問題を修正しました [＃42515](https://github.com/pingcap/tidb/issues/42515) @[lcwangchao](https://github.com/lcwangchao) - グローバルインデックスを持つパーティションテーブルに対する一部のクエリが誤った結果を返す問題を修正[＃41991](https://github.com/pingcap/tidb/issues/41991) [＃42065](https://github.com/pingcap/tidb/issues/42065) @[L-maple](https://github.com/L-maple) @@ -397,8 +397,8 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `ADMIN SHOW DDL JOBS LIMIT`誤った結果を返す問題を修正[＃42298](https://github.com/pingcap/tidb/issues/42298) @[CbcWestwolf](https://github.com/CbcWestwolf) - `UNION` でユニオンビューと一時テーブルをクエリするときに発生する TiDBのpanic問題を修正しました。 [＃42563](https://github.com/pingcap/tidb/issues/42563) @[lcwangchao](https://github.com/lcwangchao) - トランザクションで複数のステートメントをコミットするときにテーブル名の変更が有効にならない問題を修正しました [＃39664](https://github.com/pingcap/tidb/issues/39664) @[tiancaiamao](https://github.com/tiancaiamao) - - 時間変換中に準備済みプラン キャッシュと非プリペアドプラン キャッシュの動作間の非互換性の問題を修正しました [＃42439](https://github.com/pingcap/tidb/issues/42439) @[qw4990](https://github.com/qw4990) - - Decimal 型のプラン キャッシュによって発生する誤った結果を修正しました [＃43311](https://github.com/pingcap/tidb/issues/43311) @[qw4990](https://github.com/qw4990) + - 時間変換中に準備済みプランキャッシュと非プリペアドプランキャッシュの動作間の非互換性の問題を修正しました [＃42439](https://github.com/pingcap/tidb/issues/42439) @[qw4990](https://github.com/qw4990) + - Decimal 型のプランキャッシュによって発生する誤った結果を修正しました [＃43311](https://github.com/pingcap/tidb/issues/43311) @[qw4990](https://github.com/qw4990) - 間違ったフィールドタイプチェックによる、null 認識アンチ結合 (NAAJ) での TiDBのpanic問題を修正しました。 [＃42459](https://github.com/pingcap/tidb/issues/42459) @[AilinKid](https://github.com/AilinKid) - RC分離レベルでの悲観的トランザクションにおけるDML実行の失敗により、データとインデックスの間に不整合が発生する可能性がある問題を修正しました。 [＃43294](https://github.com/pingcap/tidb/issues/43294) @[ekexium](https://github.com/ekexium) - 極端なケースで、悲観的トランザクションの最初のステートメントが再試行されるときに、このトランザクションのロックを解決するとトランザクションの正確性に影響する可能性がある問題を修正しました[＃42937](https://github.com/pingcap/tidb/issues/42937) @[MyonKeminta](https://github.com/MyonKeminta) diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index 5174ed730875f..583bf1f21e9b5 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -76,7 +76,7 @@ TiDB バージョン: 7.1.1 - 削除されたテーブルが`INFORMATION_SCHEMA` から引き続き読み取ることができる問題を修正しました [＃43714](https://github.com/pingcap/tidb/issues/43714) @[tangenta](https://github.com/tangenta) - アップグレード前に一時停止された DDL 操作がある場合にクラスターのアップグレードが失敗する問題を修正[＃44225](https://github.com/pingcap/tidb/issues/44225) @[zimulala](https://github.com/zimulala) - BR を使用して`AUTO_ID_CACHE=1`テーブルを復元するときに発生する`duplicate entry`エラーを修正します [＃44716](https://github.com/pingcap/tidb/issues/44716) @[tiancaiamao](https://github.com/tiancaiamao) - - DDL 所有者の複数回の切り替えによって引き起こされるデータ インデックスの不整合の問題を修正しました。 [＃44619](https://github.com/pingcap/tidb/issues/44619) @[tangenta](https://github.com/tangenta) + - DDL 所有者の複数回の切り替えによって引き起こされるデータインデックスの不整合の問題を修正しました。 [＃44619](https://github.com/pingcap/tidb/issues/44619) @[tangenta](https://github.com/tangenta) - `none`ステータスの`ADD INDEX` DDL タスクをキャンセルすると、このタスクが Distributed eXecution Framework (DXF) タスク キューから削除されないため、メモリリークが発生する可能性がある問題を修正しました。 [＃44205](https://github.com/pingcap/tidb/issues/44205) @[tangenta](https://github.com/tangenta) - 特定のエラーデータを処理するときにプロキシプロトコルが`Header read timeout`エラーを報告する問題を修正しました [＃43205](https://github.com/pingcap/tidb/issues/43205) @[blacktear23](https://github.com/blacktear23) - PD分離により実行中のDDL がブロックされる可能性がある問題を修正しました [＃44267](https://github.com/pingcap/tidb/issues/44267) @[wjhuang2016](https://github.com/wjhuang2016) @@ -101,7 +101,7 @@ TiDB バージョン: 7.1.1 - PD - - リソース マネージャーが既定のリソース グループを繰り返し初期化する問題を修正しました。 [＃6787](https://github.com/tikv/pd/issues/6787) @[glorv](https://github.com/glorv) + - リソースマネージャーが既定のリソースグループを繰り返し初期化する問題を修正しました。 [＃6787](https://github.com/tikv/pd/issues/6787) @[glorv](https://github.com/glorv) - SQLの配置ルールで設定された`location-labels` 、期待どおりにスケジュールされない場合がある問題を修正しました。 [＃6662](https://github.com/tikv/pd/issues/6662) @[rleungx](https://github.com/rleungx) - 一部のコーナーケースで冗長レプリカが自動的に修復されない問題を修正[＃6573](https://github.com/tikv/pd/issues/6573) @[nolouch](https://github.com/nolouch) @@ -140,7 +140,7 @@ TiDB バージョン: 7.1.1 - TiDB Lightning - TiDB LightningとPD間の接続失敗を再試行できない問題を修正し、インポート成功率を向上 [＃43400](https://github.com/pingcap/tidb/issues/43400) @[lichunzhu](https://github.com/lichunzhu) - - TiKV にデータを書き込むときに、スペース不足エラーが返されるときに、 TiDB Lightning がエラー メッセージを正しく表示しない問題を修正しました。 [＃44733](https://github.com/pingcap/tidb/issues/44733) @[lance6716](https://github.com/lance6716) + - TiKV にデータを書き込むときに、スペース不足エラーが返されるときに、 TiDB Lightning がエラーメッセージを正しく表示しない問題を修正しました。 [＃44733](https://github.com/pingcap/tidb/issues/44733) @[lance6716](https://github.com/lance6716) - チェックサム操作中に`Region is unavailable`エラーが報告される問題を修正 [＃45462](https://github.com/pingcap/tidb/issues/45462) @[D3Hunter](https://github.com/D3Hunter) - `experimental.allow-expression-index`が有効でデフォルト値が UUID の場合に発生するTiDB Lightning panic問題を修正しました [＃44497](https://github.com/pingcap/tidb/issues/44497) @[lichunzhu](https://github.com/lichunzhu) - 競合条件によりディスククォータが不正確になる可能性がある問題を修正 [＃44867](https://github.com/pingcap/tidb/issues/44867) @[D3Hunter](https://github.com/D3Hunter) diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index 6207f23b469a9..8d608db1f347a 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -137,7 +137,7 @@ TiDB バージョン: 7.1.2 - PD - - v2 スケジューラ アルゴリズムでホット リージョンがスケジュールされない可能性がある問題を修正しました [＃6645](https://github.com/tikv/pd/issues/6645) @[lhy1024](https://github.com/lhy1024) + - v2 スケジューラ アルゴリズムでホットリージョンがスケジュールされない可能性がある問題を修正しました [＃6645](https://github.com/tikv/pd/issues/6645) @[lhy1024](https://github.com/lhy1024) - TLSハンドシェイクにより空のクラスタでCPU使用率が上昇する可能性がある問題を修正 [＃6913](https://github.com/tikv/pd/issues/6913) @[nolouch](https://github.com/nolouch) - PDノード間の注入エラーによりPD panicが発生する可能性がある問題を修正しました [＃6858](https://github.com/tikv/pd/issues/6858) @[HuSharp](https://github.com/HuSharp) - ストア情報の同期によりPDリーダーが終了し、 で停止する可能性がある問題を修正しました。 [＃6918](https://github.com/tikv/pd/issues/6918) @[rleungx](https://github.com/rleungx) @@ -203,7 +203,7 @@ TiDB バージョン: 7.1.2 - DM が大文字と小文字を区別しない照合順序で競合を正しく処理できない問題を修正しました [＃9489](https://github.com/pingcap/tiflow/issues/9489) @[hihihuhu](https://github.com/hihihuhu) - DM バリデーターのデッドロック問題を修正し、再試行を強化しました。 [＃9257](https://github.com/pingcap/tiflow/issues/9257) @[D3Hunter](https://github.com/D3Hunter) - 楽観的モードでタスクを再開するときに DM がすべての DML をスキップする問題を修正しました [＃9588](https://github.com/pingcap/tiflow/issues/9588) @[GMHDBJD](https://github.com/GMHDBJD) - - オンライン DDL をスキップするときに DM が上流のテーブル スキーマを適切に追跡できない問題を修正しました [＃9587](https://github.com/pingcap/tiflow/issues/9587) @[GMHDBJD](https://github.com/GMHDBJD) + - オンライン DDL をスキップするときに DM が上流のテーブルスキーマを適切に追跡できない問題を修正しました [＃9587](https://github.com/pingcap/tiflow/issues/9587) @[GMHDBJD](https://github.com/GMHDBJD) - DMが楽観的モードでパーティションDDLをスキップする問題を修正 [＃9788](https://github.com/pingcap/tiflow/issues/9788) @[GMHDBJD](https://github.com/GMHDBJD) - TiDB Lightning diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 5ac34264faa4a..39daf8e4d295f 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -111,7 +111,7 @@ TiDB バージョン: 7.1.3 - `CALIBRATE RESOURCE` を実行すると TiDB Dashboardの`resource_manager_resource_unit`メトリックが空になる問題を修正しました [＃45166](https://github.com/pingcap/tidb/issues/45166) @[CabinfeverB](https://github.com/CabinfeverB) - ワークロードによる調整ページでエラーが報告される問題を修正しました [＃48162](https://github.com/pingcap/tidb/issues/48162) @[CabinfeverB](https://github.com/CabinfeverB) - - リソース グループを削除すると DDL の原子性が損なわれる可能性がある問題を修正しました [＃45050](https://github.com/pingcap/tidb/issues/45050) @[glorv](https://github.com/glorv) + - リソースグループを削除すると DDL の原子性が損なわれる可能性がある問題を修正しました [＃45050](https://github.com/pingcap/tidb/issues/45050) @[glorv](https://github.com/glorv) - PDリーダーが転送され、新しいリーダーとPDクライアントの間にネットワークパーティションがある場合、PDクライアントがリーダーの情報を更新できない問題を修正しました。 [＃7416](https://github.com/tikv/pd/issues/7416) @[CabinfeverB](https://github.com/CabinfeverB) - 大規模クラスタに複数の TiKV ノードを追加すると、TiKVハートビートレポートが遅くなったり停止したりする可能性がある問題を修正しました[＃7248](https://github.com/tikv/pd/issues/7248) @[rleungx](https://github.com/rleungx) - TiDB DashboardがPD `trace`データを正しく読み取れない問題を修正[＃7253](https://github.com/tikv/pd/issues/7253) @[nolouch](https://github.com/nolouch) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index 311b908843d1c..10c66c916dae0 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -95,7 +95,7 @@ TiDBバージョン: 7.1.4 - 無効なオプティマイザヒントによって有効なヒントが無効になる可能性がある問題を修正[＃49308](https://github.com/pingcap/tidb/issues/49308) @[hawkingrei](https://github.com/hawkingrei) - 一部のタイムゾーンで夏時間が正しく表示されない問題を修正 [＃49586](https://github.com/pingcap/tidb/issues/49586) @[overvenus](https://github.com/overvenus) - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`を実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [＃49166](https://github.com/pingcap/tidb/issues/49166) @[qw4990](https://github.com/qw4990) - - PD との相互作用の問題により、 `tiup cluster upgrade/start`を使用してローリング アップグレードを実行すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50152](https://github.com/pingcap/tidb/issues/50152) @[zimulala](https://github.com/zimulala) + - PD との相互作用の問題により、 `tiup cluster upgrade/start`を使用してローリングアップグレードを実行すると TiDB がpanicになる可能性がある問題を修正しました。 [＃50152](https://github.com/pingcap/tidb/issues/50152) @[zimulala](https://github.com/zimulala) - 空のテーブルにインデックスを追加したときに期待される最適化が有効にならない問題を修正しました [＃49682](https://github.com/pingcap/tidb/issues/49682) @[zimulala](https://github.com/zimulala) - 多数のテーブルまたはパーティションが作成された場合に TiDB が OOM になる可能性がある問題を修正[＃50077](https://github.com/pingcap/tidb/issues/50077) @[zimulala](https://github.com/zimulala) - ネットワークが不安定な場合にインデックスを追加するとインデックスデータの不整合が発生する可能性がある問題を修正[＃49773](https://github.com/pingcap/tidb/issues/49773) @[tangenta](https://github.com/tangenta) @@ -124,9 +124,9 @@ TiDBバージョン: 7.1.4 - PD - - リソース グループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) + - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - 一部のTSOログでエラー原因が出力されない問題を修正しました [＃7496](https://github.com/tikv/pd/issues/7496) @[CabinfeverB](https://github.com/CabinfeverB) - - `BURSTABLE`有効になっているときにデフォルトのリソース グループに不要なトークンが蓄積される問題を修正[＃7206](https://github.com/tikv/pd/issues/7206) @[CabinfeverB](https://github.com/CabinfeverB) + - `BURSTABLE`有効になっているときにデフォルトのリソースグループに不要なトークンが蓄積される問題を修正[＃7206](https://github.com/tikv/pd/issues/7206) @[CabinfeverB](https://github.com/CabinfeverB) - `evict-leader-scheduler`インターフェースが呼び出されたときに出力がない問題を修正しました [＃7672](https://github.com/tikv/pd/issues/7672) @[CabinfeverB](https://github.com/CabinfeverB) - `watch etcd`正しくオフになっていない場合に発生するメモリリークの問題を修正[＃7807](https://github.com/tikv/pd/issues/7807) @[rleungx](https://github.com/rleungx) - `MergeLabels`関数が呼び出されたときにデータ競合が発生する問題を修正しました [＃7535](https://github.com/tikv/pd/issues/7535) @[lhy1024](https://github.com/lhy1024) @@ -135,7 +135,7 @@ TiDBバージョン: 7.1.4 - データレプリケーション自動同期（DR自動同期）モードを採用しているクラスタで`available_stores`誤って計算される問題を修正[＃7221](https://github.com/tikv/pd/issues/7221) @[disksing](https://github.com/disksing) - 配置ルールの設定が複雑な場合、データレプリケーション自動同期（DR自動同期）モードを採用しているクラスタで`canSync`と`hasMajority`誤って計算される可能性がある問題を修正しました[＃7201](https://github.com/tikv/pd/issues/7201) @[disksing](https://github.com/disksing) - データレプリケーション自動同期（DR自動同期）モードを採用しているクラスターで、セカンダリAZがダウンしているときにプライマリAZがTiKVノードを追加できない問題を修正しました。 [＃7218](https://github.com/tikv/pd/issues/7218) @[disksing](https://github.com/disksing) - - リソース グループをバッチでクエリすると PD がpanicになる可能性がある問題を修正しました [＃7206](https://github.com/tikv/pd/issues/7206) @[nolouch](https://github.com/nolouch) + - リソースグループをバッチでクエリすると PD がpanicになる可能性がある問題を修正しました [＃7206](https://github.com/tikv/pd/issues/7206) @[nolouch](https://github.com/nolouch) - `pd-ctl`を使用してリーダーのないリージョンを照会すると、PD がpanicになる可能性がある問題を修正しました。 [＃7630](https://github.com/tikv/pd/issues/7630) @[rleungx](https://github.com/rleungx) - リーダースイッチ後にPD監視項目`learner-peer-count`古い値を同期しない問題を修正 [＃7728](https://github.com/tikv/pd/issues/7728) @[CabinfeverB](https://github.com/CabinfeverB) - PDが`systemd` で起動したときにリソース制限を読み取れない問題を修正 [＃7628](https://github.com/tikv/pd/issues/7628) @[bufferflies](https://github.com/bufferflies) @@ -159,7 +159,7 @@ TiDBバージョン: 7.1.4 - ログバックアップタスクを停止すると TiDB がクラッシュする問題を修正[＃50839](https://github.com/pingcap/tidb/issues/50839) @[YuJuncen](https://github.com/YuJuncen) - TiKVノードにリーダーがいないためにデータの復元が遅くなる問題を修正しました [＃50566](https://github.com/pingcap/tidb/issues/50566) @[Leavrth](https://github.com/Leavrth) - - 同じノードで TiKV IP アドレスを変更した後にログ バックアップが停止する問題を修正しました [＃50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) + - 同じノードで TiKV IP アドレスを変更した後にログバックアップが停止する問題を修正しました [＃50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) - S3 からファイル コンテンツを読み取っているときにエラーが発生した場合にBR が再試行できない問題を修正しました [＃49942](https://github.com/pingcap/tidb/issues/49942) @[Leavrth](https://github.com/Leavrth) - 古いバージョンのバックアップからデータを復元するときに`Unsupported collation`エラーが報告される問題を修正しました [＃49466](https://github.com/pingcap/tidb/issues/49466) @[3pointer](https://github.com/3pointer) diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index ea69be33cb887..c22b7a86a88eb 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -26,7 +26,7 @@ TiDB バージョン: 7.1.5 - TiKV - ピアのスローログを追加し、メッセージを保存します [＃16600](https://github.com/tikv/tikv/issues/16600) @[Connor1996](https://github.com/Connor1996) - - TiKV の安定性を向上させるために、raftstore スレッドでスナップショット ファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) + - TiKV の安定性を向上させるために、raftstore スレッドでスナップショットファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) - PD @@ -36,7 +36,7 @@ TiDB バージョン: 7.1.5 - Backup & Restore (BR) - - チェックポイントの遅延が大きい場合にログ バックアップ タスクを自動的に中止する機能をサポートし、GC の長時間のブロッキングや潜在的なクラスターの問題を回避します[＃50803](https://github.com/pingcap/tidb/issues/50803) @[RidRisR](https://github.com/RidRisR) + - チェックポイントの遅延が大きい場合にログバックアップタスクを自動的に中止する機能をサポートし、GC の長時間のブロッキングや潜在的なクラスターの問題を回避します[＃50803](https://github.com/pingcap/tidb/issues/50803) @[RidRisR](https://github.com/RidRisR) - ログバックアップの互換性テストとインデックスアクセラレーションをカバーするPITR統合テストケースを追加します。 [＃51987](https://github.com/pingcap/tidb/issues/51987) @[Leavrth](https://github.com/Leavrth) - ログバックアップの開始時にアクティブなDDLジョブの無効な検証を削除します[＃52733](https://github.com/pingcap/tidb/issues/52733) @[Leavrth](https://github.com/Leavrth) @@ -101,7 +101,7 @@ TiDB バージョン: 7.1.5 - フルバックアップでピアが見つからない場合に TiKV がパニックを起こす問題を修正[＃16394](https://github.com/tikv/tikv/issues/16394) @[Leavrth](https://github.com/Leavrth) - PD接続障害により、ログバックアップアドバンサ所有者が配置されているTiDBインスタンスがpanicになる可能性がある問題を修正しました。 [＃52597](https://github.com/pingcap/tidb/issues/52597) @[YuJuncen](https://github.com/YuJuncen) - 不安定なテストケースを修正する [＃52547](https://github.com/pingcap/tidb/issues/52547) @[Leavrth](https://github.com/Leavrth) - - TiKV の再起動により、ログ バックアップのグローバル チェックポイントが実際のバックアップ ファイルの書き込みポイントよりも先に進められ、少量のバックアップ データが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) + - TiKV の再起動により、ログバックアップのグローバルチェックポイントが実際のバックアップファイルの書き込みポイントよりも先に進められ、少量のバックアップデータが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) - 特別なイベントタイミングにより、ログバックアップでデータ損失が発生する可能性があるという稀な問題を修正しました。 [＃16739](https://github.com/tikv/tikv/issues/16739) @[YuJuncen](https://github.com/YuJuncen) - TiCDC diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index f8a457058947b..296af5af9bd8b 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -26,7 +26,7 @@ TiDB バージョン: 7.1.6 - TiDB - 統計情報がすべて TopN で構成され、対応するテーブル統計の変更された行数が 0 以外である場合に、TopN にヒットしない等価条件の推定結果を 0 から 1 に調整します[＃47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - - MPP ロード バランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) + - MPP ロードバランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) - `SHOW CREATE TABLE` の出力に表示される式のデフォルト値のMySQL互換性を改善しました [＃52939](https://github.com/pingcap/tidb/issues/52939) @[CbcWestwolf](https://github.com/CbcWestwolf) - TiFlash配置ルールを一括削除することで、パーティションテーブルで`TRUNCATE`または`DROP`操作を実行した後のデータGCの処理速度が向上します。 [＃54068](https://github.com/pingcap/tidb/issues/54068) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 同期ロードパフォーマンスを改善し、統計情報のロード時のレイテンシーを削減します[＃52294](https://github.com/pingcap/tidb/issues/52294) @[hawkingrei](https://github.com/hawkingrei) @@ -73,10 +73,10 @@ TiDB バージョン: 7.1.6 - TiDB - - 一意インデックスを追加するときに同時 DML 操作によって発生するデータ インデックスの不一致の問題を修正しました。 [＃52914](https://github.com/pingcap/tidb/issues/52914) @[wjhuang2016](https://github.com/wjhuang2016) + - 一意インデックスを追加するときに同時 DML 操作によって発生するデータインデックスの不一致の問題を修正しました。 [＃52914](https://github.com/pingcap/tidb/issues/52914) @[wjhuang2016](https://github.com/wjhuang2016) - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が発生する問題を修正[＃50235](https://github.com/pingcap/tidb/issues/50235) @[qw4990](https://github.com/qw4990) - SQLが異常に中断されたときに`INDEX_HASH_JOIN`正常に終了できない問題を修正[＃54688](https://github.com/pingcap/tidb/issues/54688) @[wshwsh12](https://github.com/wshwsh12) - - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワーク パーティションによって、データ インデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @[tangenta](https://github.com/tangenta) + - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワークパーティションによって、データインデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @[tangenta](https://github.com/tangenta) - `SHOW WARNINGS;`を使用して警告を取得するとpanicが発生する可能性がある問題を修正しました [＃48756](https://github.com/pingcap/tidb/issues/48756) @[xhebox](https://github.com/xhebox) - `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY`テーブルをクエリすると TiDB がpanicを起こす可能性がある問題を修正[＃54324](https://github.com/pingcap/tidb/issues/54324) @[tiancaiamao](https://github.com/tiancaiamao) - `HashJoin`または`IndexLookUp`演算子が`Apply`演算子の駆動側サブノードである場合に`memTracker`切り離されないことで発生する異常に高いメモリ使用量の問題を修正しました。 [＃54005](https://github.com/pingcap/tidb/issues/54005) @[XuHuaiyu](https://github.com/XuHuaiyu) @@ -153,7 +153,7 @@ TiDB バージョン: 7.1.6 - DML文にネストされた生成列が含まれている場合にエラーが発生する問題を修正しました [＃53967](https://github.com/pingcap/tidb/issues/53967) @[wjhuang2016](https://github.com/wjhuang2016) - 常に`true` となる述語を持つ`SHOW ERRORS`ステートメントを実行すると TiDB がパニックを起こす問題を修正しました。 [＃46962](https://github.com/pingcap/tidb/issues/46962) @[elsa0520](https://github.com/elsa0520) - 特定の状況下でプランキャッシュを使用する際に、メタデータロックの不適切な使用によって異常なデータが書き込まれる可能性がある問題を修正しました[＃53634](https://github.com/pingcap/tidb/issues/53634) @[zimulala](https://github.com/zimulala) - - インデックス追加中の再試行によって発生するデータ インデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) + - インデックス追加中の再試行によって発生するデータインデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) - 列の不安定な一意のIDにより、 `UPDATE`文がエラーを返す可能性がある問題を修正しました。 [＃53236](https://github.com/pingcap/tidb/issues/53236) @[winoros](https://github.com/winoros) - トランザクション内のステートメントが OOM によって強制終了された後、TiDB が同じトランザクション内で次のステートメントの実行を継続すると、エラー`Trying to start aggressive locking while it's already started`が発生し、panicが発生する可能性がある問題を修正しました。 [＃53540](https://github.com/pingcap/tidb/issues/53540) @[MyonKeminta](https://github.com/MyonKeminta) - `RECOVER TABLE BY JOB JOB_ID;`を実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @[crazycs520](https://github.com/crazycs520) @@ -204,16 +204,16 @@ TiDB バージョン: 7.1.6 - PD - ラベル統計のメモリリーク問題を修正 [＃8700](https://github.com/tikv/pd/issues/8700) @[lhy1024](https://github.com/lhy1024) - - リソース グループが過剰なログを出力する問題を修正しました [＃8159](https://github.com/tikv/pd/issues/8159) @[nolouch](https://github.com/nolouch) + - リソースグループが過剰なログを出力する問題を修正しました [＃8159](https://github.com/tikv/pd/issues/8159) @[nolouch](https://github.com/nolouch) - 乱数ジェネレータの頻繁な作成によって発生するパフォーマンスジッターの問題を修正しました [＃8674](https://github.com/tikv/pd/issues/8674) @[rleungx](https://github.com/rleungx) - リージョン統計のメモリリーク問題を修正 [＃8710](https://github.com/tikv/pd/issues/8710) @[rleungx](https://github.com/rleungx) - ホットスポット キャッシュのメモリリーク問題を修正 [＃8698](https://github.com/tikv/pd/issues/8698) @[lhy1024](https://github.com/lhy1024) - 同じストアID で繰り返し作成された場合に`evict-leader-scheduler`正常に動作しない問題を修正 [＃8756](https://github.com/tikv/pd/issues/8756) @[okJiang](https://github.com/okJiang) - `replication.strictly-match-label`から`true`に設定するとTiFlash が起動しなくなる問題を修正 [＃8480](https://github.com/tikv/pd/issues/8480) @[rleungx](https://github.com/rleungx) - 設定ファイル経由でログレベルを変更しても反映されない問題を修正[＃8117](https://github.com/tikv/pd/issues/8117) @[rleungx](https://github.com/rleungx) - - 同時実行性が高い場合にリソース グループがリソース使用量を効果的に制限できない問題を修正[＃8435](https://github.com/tikv/pd/issues/8435) @[nolouch](https://github.com/nolouch) + - 同時実行性が高い場合にリソースグループがリソース使用量を効果的に制限できない問題を修正[＃8435](https://github.com/tikv/pd/issues/8435) @[nolouch](https://github.com/nolouch) - PD がオペレータ チェック中に遭遇するデータ競合問題を修正しました [＃8263](https://github.com/tikv/pd/issues/8263) @[lhy1024](https://github.com/lhy1024) - - 500 ミリ秒を超えるトークンをリクエストするとリソース グループがクォータ制限に達する問題を修正[＃8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) + - 500 ミリ秒を超えるトークンをリクエストするとリソースグループがクォータ制限に達する問題を修正[＃8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) - 一部のログが秘匿化されない問題を修正[＃8419](https://github.com/tikv/pd/issues/8419) @[rleungx](https://github.com/rleungx) - ロールをリソースグループにバインドするときにエラーが報告されない問題を修正しました [＃54417](https://github.com/pingcap/tidb/issues/54417) @[JmPotato](https://github.com/JmPotato) - 多数のリージョンが存在する場合にPDのリージョンAPIをリクエストできない問題を修正[＃55872](https://github.com/pingcap/tidb/issues/55872) @[rleungx](https://github.com/rleungx) @@ -223,7 +223,7 @@ TiDB バージョン: 7.1.6 - リソースグループのデータ競合問題を修正 [＃8267](https://github.com/tikv/pd/issues/8267) @[HuSharp](https://github.com/HuSharp) - TiKV構成項目[`coprocessor.region-split-size`](/tikv-configuration-file.md#region-split-size) 1 MiB未満の値に設定するとPD panicが発生する問題を修正しました [＃8323](https://github.com/tikv/pd/issues/8323) @[JmPotato](https://github.com/JmPotato) - `evict-leader-scheduler`で間違ったパラメータを使用すると、PD がエラーを正しく報告せず、一部のスケジューラが利用できなくなる問題を修正しました[＃8619](https://github.com/tikv/pd/issues/8619) @[rleungx](https://github.com/rleungx) - - リソース グループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) + - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - 配置ルールを使用しているときに、ダウンしたピアが回復しない可能性がある問題を修正しました。 [＃7808](https://github.com/tikv/pd/issues/7808) @[rleungx](https://github.com/rleungx) - TiFlash @@ -235,14 +235,14 @@ TiDB バージョン: 7.1.6 - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[＃9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [＃9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - BRまたはTiDB Lightning 経由でデータをインポートした後、FastScanモードで多数の重複行が読み取られる可能性がある問題を修正しました。 [＃9118](https://github.com/pingcap/tiflash/issues/9118) @[JinheLin](https://github.com/JinheLin) - - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 遅延マテリアライゼーションが有効になった後、仮想生成列を含むクエリが誤った結果を返す可能性がある問題を修正[＃9188](https://github.com/pingcap/tiflash/issues/9188) @[JinheLin](https://github.com/JinheLin) - データベース間で`ALTER TABLE ... EXCHANGE PARTITION`を実行した後にTiFlash がスキーマの同期に失敗する可能性がある問題を修正しました [＃7296](https://github.com/pingcap/tiflash/issues/7296) @[JaySon-Huang](https://github.com/JaySon-Huang) - データベースが作成直後に削除されるとTiFlash がpanicする可能性がある問題を修正[＃9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[＃8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - TiFlash が高同時実行読み取りシナリオで一時的に誤った結果を返す可能性がある問題を修正[＃8845](https://github.com/pingcap/tiflash/issues/8845) @[JinheLin](https://github.com/JinheLin) - `SUBSTRING_INDEX()`関数が一部のコーナーケースでTiFlash のクラッシュを引き起こす可能性がある問題を修正[＃9116](https://github.com/pingcap/tiflash/issues/9116) @[wshwsh12](https://github.com/wshwsh12) - - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブル メタデータのレプリケーションが遅くなり、クエリ パフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @[JaySon-Huang](https://github.com/JaySon-Huang) + - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブルメタデータのレプリケーションが遅くなり、クエリパフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @[JaySon-Huang](https://github.com/JaySon-Huang) - 空のキー範囲を持つクエリがTiFlash上で読み取りタスクを正しく生成できず、 TiFlashクエリがブロックされる可能性がある問題を修正しました。 [＃9108](https://github.com/pingcap/tiflash/issues/9108) @[JinheLin](https://github.com/JinheLin) - 特定のケースで関数`CAST AS DECIMAL`の結果の符号が正しくない問題を修正[＃9301](https://github.com/pingcap/tiflash/issues/9301) @[guo-shaoge](https://github.com/guo-shaoge) - `SUBSTRING()`関数が特定の整数型に対して`pos`と`len`引数をサポートせず、クエリエラーが発生する問題を修正しました [＃9473](https://github.com/pingcap/tiflash/issues/9473) @[gengliqi](https://github.com/gengliqi) @@ -263,7 +263,7 @@ TiDB バージョン: 7.1.6 - PD へのネットワーク接続が不安定な状態で一時停止中のログバックアップタスクを再開すると TiKV がpanicする可能性がある問題を修正しました [＃17020](https://github.com/tikv/tikv/issues/17020) @[YuJuncen](https://github.com/YuJuncen) - バックアッププロセス中に TiKV が応答しなくなった場合にバックアップタスクが停止する可能性がある問題を修正[＃53480](https://github.com/pingcap/tidb/issues/53480) @[Leavrth](https://github.com/Leavrth) - バックアップと復元のチェックポイントパスが一部の外部ストレージと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @[Leavrth](https://github.com/Leavrth) - - BRを使用してデータを復元する場合、または物理インポート モードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) + - BRを使用してデータを復元する場合、または物理インポートモードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) - PDリーダーの転送により、データの復元時にBRがpanicになる可能性がある問題を修正しました。 [＃53724](https://github.com/pingcap/tidb/issues/53724) @[Leavrth](https://github.com/Leavrth) - ログバックアップタスクを一時停止、停止、再構築した後、タスクの状態は正常であるが、チェックポイントが進まない問題を修正しました。 [＃53047](https://github.com/pingcap/tidb/issues/53047) @[RidRisR](https://github.com/RidRisR) - ログバックアップが残留ロックをすぐに解決できず、チェックポイントが進まない問題を修正しました。 [＃57134](https://github.com/pingcap/tidb/issues/57134) @[3pointer](https://github.com/3pointer) diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 669360cbc3c69..3dc607a085a46 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -124,7 +124,7 @@ TiDB バージョン: 7.2.0 `IMPORT INTO`ステートメントは、 TiDB Lightningの[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)機能を統合します。このステートメントを使用すると、CSV、SQL、PARQUET などの形式のデータを TiDB の空のテーブルにすばやくインポートできます。このインポート方法により、 TiDB Lightningの個別のデプロイと管理が不要になり、データインポートの複雑さが軽減され、インポート効率が大幅に向上します。 - Amazon S3 または GCS に保存されているデータ ファイルの場合、 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっていると、 `IMPORT INTO`は、データ インポート ジョブを複数のサブ ジョブに分割し、それらを複数の TiDB ノードにスケジュールして並列インポートを行うこともサポートしており、インポート パフォーマンスをさらに向上させます。 + Amazon S3 または GCS に保存されているデータファイルの場合、 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっていると、 `IMPORT INTO`は、データインポートジョブを複数のサブジョブに分割し、それらを複数の TiDB ノードにスケジュールして並列インポートを行うこともサポートしており、インポートパフォーマンスをさらに向上させます。 詳細については、 [ドキュメント](/sql-statements/sql-statement-import-into.md)を参照してください。 @@ -172,7 +172,7 @@ TiDB バージョン: 7.2.0 | TiDB Lightning | `send-kv-pairs` | 非推奨 | バージョン7.2.0以降、パラメータ`send-kv-pairs`は非推奨となりました。物理インポートモードでTiKVにデータを送信する際の1リクエストの最大サイズを制御するには、 [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md)を使用してください。 | | TiDB Lightning | [`character-set`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 変更 | データインポートでサポートされる文字セットに、新しい値オプション`latin1`が追加されました。このオプションを使用すると、Latin-1 文字セットのソースファイルをインポートできます。 | | TiDB Lightning | [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | 物理インポートモードでTiKVにデータを送信する際の、1リクエストあたりの最大サイズを指定します。キーと値のペアのサイズが指定されたしきい値に達すると、 TiDB Lightningは直ちにそれらをTiKVに送信します。これにより、大規模なワイドテーブルをインポートする際に、 TiDB Lightningノードがメモリ内に大量のキーと値のペアを蓄積することによって発生するメモリ不足（OOM）の問題を回避できます。このパラメータを調整することで、メモリ使用量とインポート速度のバランスを取り、インポートプロセスの安定性と効率性を向上させることができます。 | -| データ移行 | [`strict-optimistic-shard-mode`](/dm/feature-shard-merge-optimistic.md) | 新しく追加された | この構成項目は、TiDB Data Migration v2.0 の DDL シャード マージ動作との互換性を確保するために使用されます。この構成項目は、楽観的モードで有効にできます。有効にすると、レプリケーション タスクはタイプ 2 の DDL ステートメントに遭遇した際に中断されます。複数のテーブルの DDL 変更間に依存関係があるシナリオでは、適切なタイミングで中断を行うことができます。アップストリームとダウンストリーム間のデータの一貫性を確保するため、レプリケーション タスクを再開する前に、各テーブルの DDL ステートメントを手動で処理する必要があります。 | +| データ移行 | [`strict-optimistic-shard-mode`](/dm/feature-shard-merge-optimistic.md) | 新しく追加された | この構成項目は、TiDB Data Migration v2.0 の DDL シャードマージ動作との互換性を確保するために使用されます。この構成項目は、楽観的モードで有効にできます。有効にすると、レプリケーションタスクはタイプ 2 の DDL ステートメントに遭遇した際に中断されます。複数のテーブルの DDL 変更間に依存関係があるシナリオでは、適切なタイミングで中断を行うことができます。アップストリームとダウンストリーム間のデータの一貫性を確保するため、レプリケーションタスクを再開する前に、各テーブルの DDL ステートメントを手動で処理する必要があります。 | | TiCDC | [`sink.protocol`](/ticdc/ticdc-changefeed-config.md) | 変更 | ダウンストリームが Kafka の場合に、新しい値オプション`"open-protocol"`を導入します。メッセージのエンコードに使用されるプロトコル形式を指定します。 | | TiCDC | [`sink.delete-only-output-handle-key-columns`](/ticdc/ticdc-changefeed-config.md) | 新しく追加された | DELETE イベントの出力を指定します。このパラメーターは`"canal-json"`および`"open-protocol"`プロトコルでのみ有効です。デフォルト値は`false`で、これはすべての列を出力することを意味します。これを`true`に設定すると、主キー列または一意インデックス列のみが出力されます。 | diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md index a479edcc925eb..59a7fec409513 100644 --- a/releases/release-7.3.0.md +++ b/releases/release-7.3.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.3.0 7.3.0では、以下の主要機能が導入されています。さらに、7.3.0には、TiDBサーバーおよびTiFlashにおけるクエリの安定性を向上させるための一連の機能強化（[機能の詳細](#feature-details)セクションで説明）も含まれています。これらの機能強化は、より細かなものであり、ユーザーに直接影響を与えるものではないため、以下の表には含まれていません。 -
    カテゴリ特徴説明
    拡張性とパフォーマンスTiDB Lightningはパーティション化されたRaft KVをサポートしています（実験的）。 TiDB Lightningは、アーキテクチャの近々の一般提供開始の一環として、新しいパーティション化されたRaft KVアーキテクチャをサポートするようになりました。
    信頼性と可用性データインポート時に自動的な競合検出と解決機能を追加するTiDB Lightningの物理インポートモードでは、競合検出の新しいバージョンがサポートされています。このバージョンでは、競合が発生した場合に、競合データを置換（ replace ）または無視（ ignore ）するセマンティクスが実装されています。競合データを自動的に処理し、競合解決のパフォーマンスを向上させます。
    暴走クエリの手動管理（実験的）クエリの実行に予想以上に時間がかかる場合があります。新しいリソース グループの監視リストを使用すると、クエリをより効果的に管理し、優先順位を下げたり、強制終了したりできます。この機能により、オペレーターは対象のクエリを正確な SQL テキスト、SQL ダイジェスト、またはプラン ダイジェストでマークし、リソース グループ レベルでクエリを処理できるため、予期しない大規模なクエリがクラスターに及ぼす潜在的な影響をより詳細に制御できます。
    SQLクエリプランナーにオプティマイザヒントを追加することで、クエリの安定性に対するオペレーターの制御を強化します。追加されたヒント: NO_INDEX_JOIN() 、 NO_MERGE_JOIN() 、 NO_INDEX_MERGE_JOIN() 、 NO_HASH_JOIN() 、 NO_INDEX_HASH_JOIN()
    データベースの運用と可観測性統計収集タスクの進捗状況を表示します。 SHOW ANALYZE STATUSステートメントまたはmysql.analyze_jobsシステム テーブルを使用して、 ANALYZEタスクの進行状況を表示することをサポートします。
    +
    カテゴリ特徴説明
    拡張性とパフォーマンスTiDB Lightningはパーティション化されたRaft KVをサポートしています（実験的）。 TiDB Lightningは、アーキテクチャの近々の一般提供開始の一環として、新しいパーティション化されたRaft KVアーキテクチャをサポートするようになりました。
    信頼性と可用性データインポート時に自動的な競合検出と解決機能を追加するTiDB Lightningの物理インポートモードでは、競合検出の新しいバージョンがサポートされています。このバージョンでは、競合が発生した場合に、競合データを置換（ replace ）または無視（ ignore ）するセマンティクスが実装されています。競合データを自動的に処理し、競合解決のパフォーマンスを向上させます。
    暴走クエリの手動管理（実験的）クエリの実行に予想以上に時間がかかる場合があります。新しいリソースグループの監視リストを使用すると、クエリをより効果的に管理し、優先順位を下げたり、強制終了したりできます。この機能により、オペレーターは対象のクエリを正確な SQL テキスト、SQL ダイジェスト、またはプランダイジェストでマークし、リソースグループ レベルでクエリを処理できるため、予期しない大規模なクエリがクラスターに及ぼす潜在的な影響をより詳細に制御できます。
    SQLクエリプランナーにオプティマイザヒントを追加することで、クエリの安定性に対するオペレーターの制御を強化します。追加されたヒント: NO_INDEX_JOIN() 、 NO_MERGE_JOIN() 、 NO_INDEX_MERGE_JOIN() 、 NO_HASH_JOIN() 、 NO_INDEX_HASH_JOIN()
    データベースの運用と可観測性統計収集タスクの進捗状況を表示します。 SHOW ANALYZE STATUSステートメントまたはmysql.analyze_jobsシステムテーブルを使用して、 ANALYZEタスクの進行状況を表示することをサポートします。
    ## 機能の詳細 {#feature-details} @@ -21,13 +21,13 @@ TiDB バージョン: 7.3.0 - TiFlashはレプリカ選択戦略をサポートしています [#44106](https://github.com/pingcap/tidb/issues/44106) @[XuHuaiyu](https://github.com/XuHuaiyu) - バージョン 7.3.0 より前のTiFlashでは、パフォーマンスを最大化するために、すべてのノードのレプリカを使用してデータ スキャンと MPP 計算を行っていました。バージョン 7.3.0 以降では、 TiFlash はレプリカ選択戦略を導入し、システム変数[`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)を使用して設定できるようになりました。この戦略では、ノードの[ゾーン属性](/schedule-replicas-by-topology-labels.md#optional-configure-labels-for-tidb)に基づいて特定のレプリカを選択し、データ スキャンと MPP 計算のために特定のノードをスケジュールすることができます。 + バージョン 7.3.0 より前のTiFlashでは、パフォーマンスを最大化するために、すべてのノードのレプリカを使用してデータスキャンと MPP 計算を行っていました。バージョン 7.3.0 以降では、 TiFlash はレプリカ選択戦略を導入し、システム変数[`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)を使用して設定できるようになりました。この戦略では、ノードの[ゾーン属性](/schedule-replicas-by-topology-labels.md#optional-configure-labels-for-tidb)に基づいて特定のレプリカを選択し、データスキャンと MPP 計算のために特定のノードをスケジュールすることができます。 複数のデータセンターに展開され、各データセンターに完全なTiFlashデータレプリカが存在するクラスターの場合、この戦略を設定して、現在のデータセンターのTiFlashレプリカのみを選択することができます。これにより、データスキャンとMPP計算は現在のデータセンター内のTiFlashノードでのみ実行されるため、データセンター間での過剰なネットワークデータ転送を回避できます。 詳細については、 [ドキュメント](/system-variables.md#tiflash_replica_read-new-in-v730)を参照してください。 -- TiFlash はノード内のランタイム フィルターをサポート [#40220](https://github.com/pingcap/tidb/issues/40220) @[elsa0520](https://github.com/elsa0520) +- TiFlash はノード内のランタイムフィルターをサポート [#40220](https://github.com/pingcap/tidb/issues/40220) @[elsa0520](https://github.com/elsa0520) ランタイムフィルタは、クエリプランニングフェーズ中に生成される**動的な述語**です。テーブル結合処理において、これらの動的な述語は結合条件を満たさない行を効果的にフィルタリングし、スキャン時間とネットワークオーバーヘッドを削減し、テーブル結合の効率を向上させます。TiFlashはv7.3.0以降、ノード内でランタイムフィルタをサポートし、分析クエリの全体的なパフォーマンスを向上させています。一部のTPC-DSワークロードでは、パフォーマンスが10%から50%向上する可能性があります。 @@ -95,7 +95,7 @@ TiDB バージョン: 7.3.0 - TiDB Lightning で競合データ検出および処理戦略の新バージョンが導入されました [#41629](https://github.com/pingcap/tidb/issues/41629) @[lance6716](https://github.com/lance6716) - 以前のバージョンでは、 TiDB Lightning は論理インポート モードと物理インポート モードに対して異なる競合検出および処理方法を使用しており、設定が複雑でユーザーが理解しにくいものでした。さらに、物理インポート モードでは`replace`または`ignore`戦略を使用して競合を処理することができませんでした。v7.3.0 以降、 TiDB Lightning は論理インポート モードと物理インポート モードの両方に対して統一された競合検出および処理戦略を導入しました。競合が発生した場合、競合するデータをエラーとして報告 ( `error` )、置換 ( `replace` )、または無視 ( `ignore` ) するかを選択できます。競合レコードの数を制限することもでき、たとえば、指定した数の競合レコードを処理した後、タスクが中断されて終了します。さらに、このシステムはトラブルシューティングのために矛盾するデータを記録することもできます。 + 以前のバージョンでは、 TiDB Lightning は論理インポートモードと物理インポートモードに対して異なる競合検出および処理方法を使用しており、設定が複雑でユーザーが理解しにくいものでした。さらに、物理インポートモードでは`replace`または`ignore`戦略を使用して競合を処理することができませんでした。v7.3.0 以降、 TiDB Lightning は論理インポートモードと物理インポートモードの両方に対して統一された競合検出および処理戦略を導入しました。競合が発生した場合、競合するデータをエラーとして報告 ( `error` )、置換 ( `replace` )、または無視 ( `ignore` ) するかを選択できます。競合レコードの数を制限することもでき、たとえば、指定した数の競合レコードを処理した後、タスクが中断されて終了します。さらに、このシステムはトラブルシューティングのために矛盾するデータを記録することもできます。 競合が多数含まれるインポートデータの場合、パフォーマンス向上のため、競合検出および処理戦略の新しいバージョンを使用することをお勧めします。ラボ環境では、新しいバージョンの戦略は、競合検出および処理のパフォーマンスを旧バージョンよりも最大3倍高速化できます。このパフォーマンス値は参考値です。実際のパフォーマンスは、構成、テーブル構造、および競合データの割合によって異なる場合があります。なお、競合戦略の新バージョンと旧バージョンは同時に使用できません。旧バージョンの競合検出および処理戦略は、将来的に廃止される予定です。 @@ -260,7 +260,7 @@ TiDB バージョン: 7.3.0 - PD - - PD の再起動によって`default`リソース グループが再初期化される可能性がある問題を修正 [#6787](https://github.com/tikv/pd/issues/6787) @[glorv](https://github.com/glorv) + - PD の再起動によって`default`リソースグループが再初期化される可能性がある問題を修正 [#6787](https://github.com/tikv/pd/issues/6787) @[glorv](https://github.com/glorv) - etcdが既に起動しているがクライアントがまだ接続していない場合に、クライアントを呼び出すとPDがpanicを起こす可能性がある問題を修正しました [#6860](https://github.com/tikv/pd/issues/6860) @[HuSharp](https://github.com/HuSharp) - リージョンの出力 `health-check` が、リージョン ID を照会して返されるリージョン情報と一致しない問題を修正します。 [#6560](https://github.com/tikv/pd/issues/6560) @[JmPotato](https://github.com/JmPotato) - `unsafe recovery`で失敗したラーナーピアが`auto-detect`モードでは無視される問題を修正 [#6690](https://github.com/tikv/pd/issues/6690) @[v01dstar](https://github.com/v01dstar) @@ -270,7 +270,7 @@ TiDB バージョン: 7.3.0 - TiFlash - TiFlashがデッドロックのためにパーティション化されたテーブルを正常に複製できない問題を修正 [#7758](https://github.com/pingcap/tiflash/issues/7758) @[hongyunyan](https://github.com/hongyunyan) - - `INFORMATION_SCHEMA.TIFLASH_REPLICA`システム テーブルにユーザーがアクセスする権限を持たないテーブルが含まれる問題を修正 [#7795](https://github.com/pingcap/tiflash/issues/7795) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - `INFORMATION_SCHEMA.TIFLASH_REPLICA`システムテーブルにユーザーがアクセスする権限を持たないテーブルが含まれる問題を修正 [#7795](https://github.com/pingcap/tiflash/issues/7795) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 同じ MPP タスク内に複数の HashAgg 演算子が存在する場合、MPP タスクのコンパイルに非常に長い時間がかかり、クエリのパフォーマンスに深刻な影響を与える問題を修正しました [#7810](https://github.com/pingcap/tiflash/issues/7810) @[SeaRise](https://github.com/SeaRise) - ツール diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 7e08fb43b0a4a..784d9458ca26a 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} @@ -125,11 +125,11 @@ TiDB バージョン: 7.4.0 データバックアップや自動統計収集などのバックグラウンドタスクは、優先度が低いにもかかわらず、多くのリソースを消費します。これらのタスクは通常、定期的または不定期にトリガーされます。実行中に大量のリソースを消費するため、オンラインの高優先度タスクのパフォーマンスに影響を与えます。v7.4.0以降、TiDBリソース制御機能はバックグラウンドタスクの管理をサポートします。この機能により、低優先度タスクがオンラインアプリケーションに及ぼすパフォーマンスへの影響を軽減し、合理的なリソース割り当てを実現し、クラスターの安定性を大幅に向上させます。 - TiDB は次の種類のバックグラウンド タスクをサポートしています。 + TiDB は次の種類のバックグラウンドタスクをサポートしています。 - - `lightning` : [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してインポート タスクを実行します。 + - `lightning` : [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してインポートタスクを実行します。 - `br` : [BR](/br/backup-and-restore-overview.md)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 - - `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 + - `ddl` : Reorg DDL のバッチデータ書き戻しフェーズ中のリソース使用量を制御します。 - `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 デフォルトでは、バックグラウンドタスクとしてマークされたタスクタイプは空で、バックグラウンドタスクの管理は無効になっています。このデフォルトの動作は、TiDB v7.4.0より前のバージョンと同じです。バックグラウンドタスクを管理するには、 `default`リソースグループのバックグラウンドタスクタイプを手動で変更する必要があります。 @@ -192,7 +192,7 @@ TiDB バージョン: 7.4.0 - TiDB Dashboardは、実行計画をテーブルビューで表示することをサポートしています[＃1589](https://github.com/pingcap/tidb-dashboard/issues/1589) @[baurine](https://github.com/baurine) - v7.4.0 では、TiDB Dashboardは、診断エクスペリエンスを向上させるために、**スロー クエリ ページ**と**SQL ステートメント**ページで実行計画をテーブル ビューで表示することをサポートしています。 + v7.4.0 では、TiDB Dashboardは、診断エクスペリエンスを向上させるために、**スロークエリ ページ**と**SQL ステートメント**ページで実行計画をテーブル ビューで表示することをサポートしています。 詳細については[ドキュメント](/dashboard/dashboard-statement-details.md)を参照してください。 @@ -204,7 +204,7 @@ TiDB バージョン: 7.4.0 さらに、v7.4.0 では、 `IMPORT INTO`機能に次の機能が導入されています。 - - `Split_File`オプションの構成をサポートします。これにより、大きな CSV ファイルを複数の 256 MiB の小さな CSV ファイルに分割して並列処理し、インポート パフォーマンスを向上させることができます。 + - `Split_File`オプションの構成をサポートします。これにより、大きな CSV ファイルを複数の 256 MiB の小さな CSV ファイルに分割して並列処理し、インポートパフォーマンスを向上させることができます。 - 圧縮されたCSVファイルとSQLファイル`.snappy`インポート`.zst`サポートします。サポートされている`.zstd`形式は、 `.gzip` `.gz` 。 詳細については[ドキュメント](/sql-statements/sql-statement-import-into.md)を参照してください。 @@ -274,7 +274,7 @@ TiDB バージョン: 7.4.0 | TiDB | [`enable-stats-cache-mem-quota`](/tidb-configuration-file.md#enable-stats-cache-mem-quota-new-in-v610) | 変更 | デフォルト値は`false`から`true`に変更され、TiDB 統計のキャッシュのメモリ制限がデフォルトで有効になることを意味します。 | | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720) | 変更 | RocksDBの定期的なコンパクションをデフォルトで無効化するため、デフォルト値を`"30d"`から`"0s"`に変更しました。この変更により、TiDBのアップグレード後に大量のコンパクションがトリガーされ、フロントエンドの読み取りおよび書き込みパフォーマンスに影響が出るのを回避できます。 | | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720) | 変更 | デフォルト値が`"30d"`から`"0s"`に変更され、SST ファイルは TTL によりデフォルトで圧縮をトリガーしなくなり、フロントエンドの読み取りおよび書き込みパフォーマンスに影響を与えなくなります。 | -| TiFlash | [`flash.compact_log_min_gap`](/tiflash/tiflash-configuration.md) | 新しく追加された | 現在のRaftステート マシンによって進められた`applied_index`と最後のディスク スピル時の`applied_index`の差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 | +| TiFlash | [`flash.compact_log_min_gap`](/tiflash/tiflash-configuration.md) | 新しく追加された | 現在のRaftステートマシンによって進められた`applied_index`と最後のディスクスピル時の`applied_index`の差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 | | TiFlash | [`profiles.default.enable_resource_control`](/tiflash/tiflash-configuration.md) | 新しく追加された | TiFlashリソース制御機能を有効にするかどうかを制御します。 | | TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md) | 変更 | デフォルト値を`4`から`5`に変更します。新しい形式では、小さなファイルを結合することで物理ファイルの数を削減できます。 | | TiFlash | [`task_scheduler_active_set_soft_limit`](/tiflash/tiflash-configuration.md#task_scheduler_active_set_soft_limit-new-in-v640) | 変更 | デフォルト値を`vcpu * 0.25`から`vcpu * 2`に変更します。 | @@ -320,7 +320,7 @@ TiDB バージョン: 7.4.0 - TiFlash - TiFlash書き込みプロセスのスピルポリシーを最適化することで、ランダム書き込みワークロード中の書き込みパフォーマンスを向上します[＃7564](https://github.com/pingcap/tiflash/issues/7564) @[CalvinNeo](https://github.com/CalvinNeo) - - TiFlash のRaftレプリケーション プロセスに関するメトリクスを追加します。 [＃8068](https://github.com/pingcap/tiflash/issues/8068) @[CalvinNeo](https://github.com/CalvinNeo) + - TiFlash のRaftレプリケーションプロセスに関するメトリクスを追加します。 [＃8068](https://github.com/pingcap/tiflash/issues/8068) @[CalvinNeo](https://github.com/CalvinNeo) - ファイルシステムの inode が枯渇する可能性を回避するために、小さなファイルの数を減らします。 [＃7595](https://github.com/pingcap/tiflash/issues/7595) @[hongyunyan](https://github.com/hongyunyan) - ツール @@ -430,7 +430,7 @@ TiDB バージョン: 7.4.0 - DM が大文字と小文字を区別しない照合順序で競合を正しく処理できない問題を修正しました [＃9489](https://github.com/pingcap/tiflow/issues/9489) @[hihihuhu](https://github.com/hihihuhu) - DM バリデーターのデッドロック問題を修正し、再試行を強化しました。 [＃9257](https://github.com/pingcap/tiflow/issues/9257) @[D3Hunter](https://github.com/D3Hunter) - 失敗した DDL がスキップされ、後続の DDL が実行されない場合に、DM によって返されるレプリケーション ラグが増大し続ける問題を修正しました[＃9605](https://github.com/pingcap/tiflow/issues/9605) @[D3Hunter](https://github.com/D3Hunter) - - オンライン DDL をスキップするときに DM が上流のテーブル スキーマを適切に追跡できない問題を修正しました [＃9587](https://github.com/pingcap/tiflow/issues/9587) @[GMHDBJD](https://github.com/GMHDBJD) + - オンライン DDL をスキップするときに DM が上流のテーブルスキーマを適切に追跡できない問題を修正しました [＃9587](https://github.com/pingcap/tiflow/issues/9587) @[GMHDBJD](https://github.com/GMHDBJD) - 楽観的モードでタスクを再開するときに DM がすべての DML をスキップする問題を修正しました [＃9588](https://github.com/pingcap/tiflow/issues/9588) @[GMHDBJD](https://github.com/GMHDBJD) - DMが楽観的モードでパーティションDDLをスキップする問題を修正 [＃9788](https://github.com/pingcap/tiflow/issues/9788) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index d17a753f0cfec..d4eeb60dfde09 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -15,7 +15,7 @@ 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 までのハイライトの一部を示しています。 -
    カテゴリ特徴説明
    拡張性とパフォーマンス複数の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のヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
    +
    カテゴリ特徴説明
    拡張性とパフォーマンス複数の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のヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
    ## 機能の詳細 {#feature-details} @@ -70,7 +70,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 - TiDB Dashboardは TiKV のヒープ プロファイリングをサポートします [#15927](https://github.com/tikv/tikv/issues/15927) @[Connor1996](https://github.com/Connor1996) - 従来、TiKV の OOM やメモリ使用量過多の問題に対処するには、インスタンス環境でヒープ プロファイルを生成するために`jeprof`を手動で実行する必要がありました。v7.5.0 以降、TiKV はヒープ プロファイルのリモート処理に対応しました。ヒープ プロファイルのフレーム グラフとコール グラフに直接アクセスできるようになりました。この機能により、Go のヒープ プロファイリングと同様に、シンプルで使いやすい操作性を実現しています。 + 従来、TiKV の OOM やメモリ使用量過多の問題に対処するには、インスタンス環境でヒーププロファイルを生成するために`jeprof`を手動で実行する必要がありました。v7.5.0 以降、TiKV はヒーププロファイルのリモート処理に対応しました。ヒーププロファイルのフレーム グラフとコール グラフに直接アクセスできるようになりました。この機能により、Go のヒープ プロファイリングと同様に、シンプルで使いやすい操作性を実現しています。 詳細については、[ドキュメント](/dashboard/dashboard-profiling.md)を参照してください。 diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index ad10e87c0d8ca..6b0ef894a6fd5 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -31,10 +31,10 @@ TiDB バージョン: 7.5.1 リソースグループを使用してアプリケーションのワークロードを分離するユーザーが増えるにつれ、リソースコントロールはリソースグループに基づいた拡張データを提供します。これにより、リソースグループのワークロードと設定を監視し、次のような問題を迅速に特定し、正確に診断できるようになります。 - - [スロークエリ](/identify-slow-queries.md) : リソース グループ名、リソース ユニット (RU) の消費量、およびリソースの待機時間を追加します。 - - [ステートメントサマリーテーブル](/statement-summary-tables.md) : リソース グループ名、RU 消費量、リソースの待機時間を追加します。 + - [スロークエリ](/identify-slow-queries.md) : リソースグループ名、リソース ユニット (RU) の消費量、およびリソースの待機時間を追加します。 + - [ステートメントサマリーテーブル](/statement-summary-tables.md) : リソースグループ名、RU 消費量、リソースの待機時間を追加します。 - システム変数[`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-new-in-v4014)に、SQL文によって消費されたリソース量[ロシア](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)を示す新しいエントリ`ru_consumption`を追加します。この変数を使用して、セッション内の最後の文のリソース消費量を取得できます。 - - リソース グループに基づいてデータベース メトリックを追加します: QPS/TPS、実行時間 (P999/P99/P95)、障害数、接続数。 + - リソースグループに基づいてデータベース メトリックを追加します: QPS/TPS、実行時間 (P999/P99/P95)、障害数、接続数。 - `CANCEL IMPORT JOB`文を同期文に変更します。 [＃48736](https://github.com/pingcap/tidb/issues/48736) @[D3Hunter](https://github.com/D3Hunter) @@ -174,10 +174,10 @@ TiDB バージョン: 7.5.1 - PD - - リソース グループをバッチでクエリすると PD がpanicになる可能性がある問題を修正しました [＃7206](https://github.com/tikv/pd/issues/7206) @[nolouch](https://github.com/nolouch) + - リソースグループをバッチでクエリすると PD がpanicになる可能性がある問題を修正しました [＃7206](https://github.com/tikv/pd/issues/7206) @[nolouch](https://github.com/nolouch) - PDが`systemd` で起動したときにリソース制限を読み取れない問題を修正 [＃7628](https://github.com/tikv/pd/issues/7628) @[bufferflies](https://github.com/bufferflies) - PD ディスクレイテンシーの継続的なジッタにより、PD が新しいリーダーを選択できない可能性がある問題を修正しました。 [＃7251](https://github.com/tikv/pd/issues/7251) @[HuSharp](https://github.com/HuSharp) - - PD のネットワーク パーティションにより、スケジュールがすぐに開始されない可能性がある問題を修正[＃7016](https://github.com/tikv/pd/issues/7016) @[HuSharp](https://github.com/HuSharp) + - PD のネットワークパーティションにより、スケジュールがすぐに開始されない可能性がある問題を修正[＃7016](https://github.com/tikv/pd/issues/7016) @[HuSharp](https://github.com/HuSharp) - リーダースイッチ後にPD監視項目`learner-peer-count`古い値を同期しない問題を修正 [＃7728](https://github.com/tikv/pd/issues/7728) @[CabinfeverB](https://github.com/CabinfeverB) - PDリーダーが転送され、新しいリーダーとPDクライアントの間にネットワークパーティションがある場合、PDクライアントがリーダーの情報を更新できない問題を修正しました。 [＃7416](https://github.com/tikv/pd/issues/7416) @[CabinfeverB](https://github.com/CabinfeverB) - Gin Web Framework のバージョンを v1.8.1 から v1.9.1 にアップグレードして、いくつかのセキュリティ問題を修正しました[＃7438](https://github.com/tikv/pd/issues/7438) @[niubell](https://github.com/niubell) @@ -195,7 +195,7 @@ TiDB バージョン: 7.5.1 - 短いクエリが正常に実行され、過剰な情報ログが出力される問題を修正しました。 [＃8592](https://github.com/pingcap/tiflash/issues/8592) @[windtalker](https://github.com/windtalker) - クエリの低速化によりメモリ使用量が大幅に増加する問題を修正 [＃8564](https://github.com/pingcap/tiflash/issues/8564) @[JinheLin](https://github.com/JinheLin) - `lowerUTF8`と`upperUTF8`関数で、大文字と小文字が異なるバイトを占めることができない問題を修正しました。 [＃8484](https://github.com/pingcap/tiflash/issues/8484) @[gengliqi](https://github.com/gengliqi) - - ストリーム読み取り中に複数のパーティション テーブルをスキャンするときに発生する可能性のある OOM 問題を修正しました。 [＃8505](https://github.com/pingcap/tiflash/issues/8505) @[gengliqi](https://github.com/gengliqi) + - ストリーム読み取り中に複数のパーティションテーブルをスキャンするときに発生する可能性のある OOM 問題を修正しました。 [＃8505](https://github.com/pingcap/tiflash/issues/8505) @[gengliqi](https://github.com/gengliqi) - クエリ中にTiFlash がメモリ制限に遭遇した場合のメモリリークの問題を修正しました [＃8447](https://github.com/pingcap/tiflash/issues/8447) @[JinheLin](https://github.com/JinheLin) - TiFlash が同時 DDL 実行中に競合に遭遇した場合のTiFlash panic問題を修正[＃8578](https://github.com/pingcap/tiflash/issues/8578) @[JaySon-Huang](https://github.com/JaySon-Huang) - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`を実行した後にTiFlash がパニックを起こし、null 許容列が非 null 許容に変更される問題を修正しました。 [＃8419](https://github.com/pingcap/tiflash/issues/8419) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -211,13 +211,13 @@ TiDB バージョン: 7.5.1 - Backup & Restore (BR) - TiKVノードにリーダーがいないためにデータの復元が遅くなる問題を修正しました [＃50566](https://github.com/pingcap/tidb/issues/50566) @[Leavrth](https://github.com/Leavrth) - - `--filter`オプションを指定した後でも、完全な復元を行うにはターゲット クラスターが空である必要があるという問題を修正しました[＃51009](https://github.com/pingcap/tidb/issues/51009) @[3pointer](https://github.com/3pointer) + - `--filter`オプションを指定した後でも、完全な復元を行うにはターゲットクラスターが空である必要があるという問題を修正しました[＃51009](https://github.com/pingcap/tidb/issues/51009) @[3pointer](https://github.com/3pointer) - データの復元に失敗した後、チェックポイントから再開するとエラー`the target cluster is not fresh`が発生する問題を修正しました[＃50232](https://github.com/pingcap/tidb/issues/50232) @[Leavrth](https://github.com/Leavrth) - ログバックアップタスクを停止すると TiDB がクラッシュする問題を修正[＃50839](https://github.com/pingcap/tidb/issues/50839) @[YuJuncen](https://github.com/YuJuncen) - 古いバージョンのバックアップからデータを復元するときに`Unsupported collation`エラーが報告される問題を修正しました [＃49466](https://github.com/pingcap/tidb/issues/49466) @[3pointer](https://github.com/3pointer) - タスク初期化中にPDへの接続に失敗すると、ログバックアップタスクは開始できるが正常に動作しない問題を修正[＃16056](https://github.com/tikv/tikv/issues/16056) @[YuJuncen](https://github.com/YuJuncen) - BRが外部ストレージファイルに対して誤ったURIを生成する問題を修正 [＃48452](https://github.com/pingcap/tidb/issues/48452) @[3AceShowHand](https://github.com/3AceShowHand) - - 同じノードで TiKV IP アドレスを変更した後にログ バックアップが停止する問題を修正しました [＃50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) + - 同じノードで TiKV IP アドレスを変更した後にログバックアップが停止する問題を修正しました [＃50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) - S3 からファイル コンテンツを読み取っているときにエラーが発生した場合にBR が再試行できない問題を修正しました [＃49942](https://github.com/pingcap/tidb/issues/49942) @[Leavrth](https://github.com/Leavrth) - TiCDC @@ -237,4 +237,4 @@ TiDB バージョン: 7.5.1 - TiDB Data Migration (DM) - 下流のテーブル構造に`shard_row_id_bits` が含まれている場合に移行タスクエラーが発生する問題を修正しました [＃10308](https://github.com/pingcap/tiflow/issues/10308) @[GMHDBJD](https://github.com/GMHDBJD) - - DM が「イベント タイプ切り捨てが無効です」というエラーに遭遇し、アップグレードが失敗する問題を修正しました[＃10282](https://github.com/pingcap/tiflow/issues/10282) @[GMHDBJD](https://github.com/GMHDBJD) + - DM が「イベントタイプ切り捨てが無効です」というエラーに遭遇し、アップグレードが失敗する問題を修正しました[＃10282](https://github.com/pingcap/tiflow/issues/10282) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index 6f868a1911ce9..ea474b71b807b 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -26,9 +26,9 @@ TiDB バージョン: 7.5.2 - `SHOW CREATE TABLE` の出力に表示される式のデフォルト値のMySQL互換性を改善しました [＃52939](https://github.com/pingcap/tidb/issues/52939) @[CbcWestwolf](https://github.com/CbcWestwolf) - 常に`false`である DNF 項目の処理を強化し、そのようなフィルタ条件を直接無視することで、不要なテーブル全体のスキャンを回避します[＃40997](https://github.com/pingcap/tidb/issues/40997) @[Rustin170506](https://github.com/Rustin170506) - `EXPLAIN ANALYZE` のTiFlash `TableScan`オペレータの実行プロセスの統計を最適化します [＃51727](https://github.com/pingcap/tidb/issues/51727) @[JinheLin](https://github.com/JinheLin) - - MPP ロード バランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) + - MPP ロードバランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) - PD からリージョンを一括ロードすることをサポートし、大規模なテーブルをクエリするときに KV 範囲からリージョンへの変換プロセスを高速化します。 [＃51326](https://github.com/pingcap/tidb/issues/51326) @[SeaRise](https://github.com/SeaRise) - - `Resource Control`監視ページで、各リソース グループの最大 RU 消費率を表示する新しいパネル`RU(Max)`を追加します。 [＃49318](https://github.com/pingcap/tidb/issues/49318) @[nolouch](https://github.com/nolouch) + - `Resource Control`監視ページで、各リソースグループの最大 RU 消費率を表示する新しいパネル`RU(Max)`を追加します。 [＃49318](https://github.com/pingcap/tidb/issues/49318) @[nolouch](https://github.com/nolouch) - 同期ロードパフォーマンスを改善し、統計情報のロードのレイテンシーを削減します[＃52994](https://github.com/pingcap/tidb/issues/52294) @[hawkingrei](https://github.com/hawkingrei) - 統計初期化の同時実行性を高めて起動を高速化します[＃52466](https://github.com/pingcap/tidb/issues/52466) [＃52102](https://github.com/pingcap/tidb/issues/52102) [＃52553](https://github.com/pingcap/tidb/issues/52553) @[hawkingrei](https://github.com/hawkingrei) @@ -36,7 +36,7 @@ TiDB バージョン: 7.5.2 - コプロセッサエラーのログレベルを`warn`から`debug`に調整して、クラスタの不要なログを削減します。 [＃15881](https://github.com/tikv/tikv/issues/15881) @[cfzjywxk](https://github.com/cfzjywxk) - CDC イベント処理のキュー時間の監視メトリックを追加して、下流の CDC イベントレイテンシー問題のトラブルシューティングを容易にします[＃16282](https://github.com/tikv/tikv/issues/16282) @[hicqu](https://github.com/hicqu) - - TiKV の安定性を向上させるために、raftstore スレッドでスナップショット ファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) + - TiKV の安定性を向上させるために、raftstore スレッドでスナップショットファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) - ピアのスローログを追加し、メッセージを保存します [＃16600](https://github.com/tikv/tikv/issues/16600) @[Connor1996](https://github.com/Connor1996) - TiKVは破損したSSTファイルの存在を検出すると、破損の具体的な理由をログに記録します[＃16308](https://github.com/tikv/tikv/issues/16308) @[overvenus](https://github.com/overvenus) - 不要な非同期ブロックを削除してメモリ使用量を削減する[＃16540](https://github.com/tikv/tikv/issues/16540) @[overvenus](https://github.com/overvenus) @@ -77,9 +77,9 @@ TiDB バージョン: 7.5.2 - TiDB - - 一意インデックスを追加するときに同時 DML 操作によって発生するデータ インデックスの不整合の問題を修正しました。 [＃52914](https://github.com/pingcap/tidb/issues/52914) @[wjhuang2016](https://github.com/wjhuang2016) + - 一意インデックスを追加するときに同時 DML 操作によって発生するデータインデックスの不整合の問題を修正しました。 [＃52914](https://github.com/pingcap/tidb/issues/52914) @[wjhuang2016](https://github.com/wjhuang2016) - パーティションテーブルに複数のスキーマ変更を含むインデックスを追加することで発生するデータインデックスの不整合の問題を修正しました。 [＃52080](https://github.com/pingcap/tidb/issues/52080) @[tangenta](https://github.com/tangenta) - - 複数値インデックスを追加することによって発生するデータ インデックスの不整合の問題を修正しました [＃51162](https://github.com/pingcap/tidb/issues/51162) @[ywqzzy](https://github.com/ywqzzy) + - 複数値インデックスを追加することによって発生するデータインデックスの不整合の問題を修正しました [＃51162](https://github.com/pingcap/tidb/issues/51162) @[ywqzzy](https://github.com/ywqzzy) - ネットワークの問題によりDDL操作が停止する問題を修正[＃47060](https://github.com/pingcap/tidb/issues/47060) @[wjhuang2016](https://github.com/wjhuang2016) - 起動時に統計情報をロードするときにTiDBがGCによるエラーを報告する可能性がある問題を修正[＃53592](https://github.com/pingcap/tidb/issues/53592) @[you06](https://github.com/you06) - TiDBが準備完了していないTiKVノードにリクエストを送信する可能性がある問題を修正 [＃50758](https://github.com/pingcap/tidb/issues/50758) @[zyguan](https://github.com/zyguan) @@ -93,7 +93,7 @@ TiDB バージョン: 7.5.2 - クラスター化インデックスを述語として使用すると`SELECT INTO OUTFILE`が機能しない問題を修正[＃42093](https://github.com/pingcap/tidb/issues/42093) @[qw4990](https://github.com/qw4990) - TopN演算子が誤ってプッシュダウンされる可能性がある問題を修正しました [＃37986](https://github.com/pingcap/tidb/issues/37986) @[qw4990](https://github.com/qw4990) - 空の投影により TiDB がpanicを引き起こす問題を修正しました [＃49109](https://github.com/pingcap/tidb/issues/49109) @[winoros](https://github.com/winoros) - - インデックス プランが順序に保たれている場合に、インデックス マージによって部分的な制限が誤ってプッシュダウンされる問題を修正しました。 [＃52947](https://github.com/pingcap/tidb/issues/52947) @[AilinKid](https://github.com/AilinKid) + - インデックス プランが順序に保たれている場合に、インデックスマージによって部分的な制限が誤ってプッシュダウンされる問題を修正しました。 [＃52947](https://github.com/pingcap/tidb/issues/52947) @[AilinKid](https://github.com/AilinKid) - 再帰CTE でビューの使用が機能しない問題を修正 [＃49721](https://github.com/pingcap/tidb/issues/49721) @[hawkingrei](https://github.com/hawkingrei) - 列の不安定な一意のIDにより、 `UPDATE`文がエラーを返す可能性がある問題を修正しました。 [＃53236](https://github.com/pingcap/tidb/issues/53236) @[winoros](https://github.com/winoros) - 常に`true` となる述語を持つ`SHOW ERRORS`文を実行すると TiDB がパニックを起こす問題を修正しました。 [＃46962](https://github.com/pingcap/tidb/issues/46962) @[elsa0520](https://github.com/elsa0520) @@ -112,7 +112,7 @@ TiDB バージョン: 7.5.2 - `TIDB_HOT_REGIONS`テーブルをクエリすると、誤って`INFORMATION_SCHEMA`テーブルが返される可能性がある問題を修正しました。 [＃50810](https://github.com/pingcap/tidb/issues/50810) @[Defined2014](https://github.com/Defined2014) - 統計の初期化が完了する前に自動統計収集がトリガーされる問題を修正[＃52346](https://github.com/pingcap/tidb/issues/52346) @[Rustin170506](https://github.com/Rustin170506) - AutoIDLeaderの変更により、 `AUTO_ID_CACHE=1` の場合にAUTO_INCREMENT列の値が減少する可能性がある問題を修正しました。 [＃52600](https://github.com/pingcap/tidb/issues/52600) @[tiancaiamao](https://github.com/tiancaiamao) - - 共通テーブル式 (CTE) を使用して、統計情報が欠落しているパーティション テーブルにアクセスすると、クエリ結果が正しくなくなる可能性がある問題を修正しました[＃51873](https://github.com/pingcap/tidb/issues/51873) @[qw4990](https://github.com/qw4990) + - 共通テーブル式 (CTE) を使用して、統計情報が欠落しているパーティションテーブルにアクセスすると、クエリ結果が正しくなくなる可能性がある問題を修正しました[＃51873](https://github.com/pingcap/tidb/issues/51873) @[qw4990](https://github.com/qw4990) - TiDB Dashboardのモニタリングページにおける接続数（接続数）の計算と表示が誤っていた問題を修正しました。 [＃51889](https://github.com/pingcap/tidb/issues/51889) @[YangKeao](https://github.com/YangKeao) - 外部キーを持つテーブルを復元するときに DDL 操作が停止する問題を修正しました [＃51838](https://github.com/pingcap/tidb/issues/51838) @[YangKeao](https://github.com/YangKeao) - 列のデフォルト値が削除されている場合、列のデフォルト値を取得するとエラーが返される問題を修正[＃50043](https://github.com/pingcap/tidb/issues/50043) [＃51324](https://github.com/pingcap/tidb/issues/51324) @[crazycs520](https://github.com/crazycs520) @@ -139,7 +139,7 @@ TiDB バージョン: 7.5.2 - 分散実行フレームワーク (DXF) を有効にした後に、大きなテーブルにインデックスを追加できない問題を修正しました。 [＃52640](https://github.com/pingcap/tidb/issues/52640) @[tangenta](https://github.com/tangenta) - TTL 機能により、データ範囲の分割が不正確になり、場合によってはでデータ ホットスポットが発生する問題を修正しました。 [＃51527](https://github.com/pingcap/tidb/issues/51527) @[lcwangchao](https://github.com/lcwangchao) - 主キーの型が`VARCHAR` の場合に`ALTER TABLE ... COMPACT TIFLASH REPLICA`誤って終了する可能性がある問題を修正しました [＃51810](https://github.com/pingcap/tidb/issues/51810) @[breezewish](https://github.com/breezewish) - - インデックス追加中にクラスターのアップグレードによって発生するデータ インデックスの不整合の問題を修正しました。 [＃52411](https://github.com/pingcap/tidb/issues/52411) @[tangenta](https://github.com/tangenta) + - インデックス追加中にクラスターのアップグレードによって発生するデータインデックスの不整合の問題を修正しました。 [＃52411](https://github.com/pingcap/tidb/issues/52411) @[tangenta](https://github.com/tangenta) - TableDual で述語プッシュダウンを無効にすることで発生するパフォーマンス低下の問題を修正しました [＃50614](https://github.com/pingcap/tidb/issues/50614) @[time-and-fate](https://github.com/time-and-fate) - TiDBサーバーがHTTPインターフェース経由でラベルを追加し成功を返すが、それが有効にならない問題を修正[＃51427](https://github.com/pingcap/tidb/issues/51427) @[you06](https://github.com/you06) - 取り込みモードでインデックスを追加すると、一部のコーナーケースでデータインデックスの不整合が発生する可能性がある問題を修正[＃51954](https://github.com/pingcap/tidb/issues/51954) @[lance6716](https://github.com/lance6716) @@ -177,14 +177,14 @@ TiDB バージョン: 7.5.2 - TiDBネットワークパーティションの障害回復後の接続panicの問題を修正しました [＃7926](https://github.com/tikv/pd/issues/7926) @[CabinfeverB](https://github.com/CabinfeverB) - オンラインデータ復旧後にスケジュールが誤って一時停止される可能性がある問題を修正 [＃8095](https://github.com/tikv/pd/issues/8095) @[JmPotato](https://github.com/JmPotato) - - リソース グループを有効にした後に、CPS By Type 監視タイプが正しく表示されない問題を修正しました。 [＃52605](https://github.com/pingcap/tidb/issues/52605) @[nolouch](https://github.com/nolouch) + - リソースグループを有効にした後に、CPS By Type 監視タイプが正しく表示されない問題を修正しました。 [＃52605](https://github.com/pingcap/tidb/issues/52605) @[nolouch](https://github.com/nolouch) - 設定ファイル経由でログレベルを変更しても反映されない問題を修正[＃8117](https://github.com/tikv/pd/issues/8117) @[rleungx](https://github.com/rleungx) - リソースグループクエリをキャンセルするときに再試行回数が多すぎる問題を修正 [＃8217](https://github.com/tikv/pd/issues/8217) @[nolouch](https://github.com/nolouch) - `ALTER PLACEMENT POLICY`配置ポリシー を変更できない問題を修正 [＃51712](https://github.com/pingcap/tidb/issues/51712) @[jiyfhust](https://github.com/jiyfhust) [＃52257](https://github.com/pingcap/tidb/issues/52257) - 配置ルールを使用しているときに、ダウンしたピアが回復しない可能性がある問題を修正しました。 [＃7808](https://github.com/tikv/pd/issues/7808) @[rleungx](https://github.com/rleungx) - PDリーダーを手動で転送すると失敗する可能性がある問題を修正しました [＃8225](https://github.com/tikv/pd/issues/8225) @[HuSharp](https://github.com/HuSharp) - 書き込みホットスポットのスケジュール設定により配置ポリシーの制約が破られる可能性がある問題を修正[＃7848](https://github.com/tikv/pd/issues/7848) @[lhy1024](https://github.com/lhy1024) - - リソース グループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) + - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - スケーリングの進行状況が正しく表示されない問題を修正[＃7726](https://github.com/tikv/pd/issues/7726) @[CabinfeverB](https://github.com/CabinfeverB) - 展開された2つのデータセンター間でリーダーを切り替えるとLeaderが失敗する問題を修正[＃7992](https://github.com/tikv/pd/issues/7992) @[TonsnakeLin](https://github.com/TonsnakeLin) - PDの`Filter target`監視メトリックが散布範囲情報を提供しない問題を修正[＃8125](https://github.com/tikv/pd/issues/8125) @[HuSharp](https://github.com/HuSharp) @@ -193,7 +193,7 @@ TiDB バージョン: 7.5.2 - TiFlash - 分散ストレージおよびコンピューティングアーキテクチャで、DDL操作で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 [＃9084](https://github.com/pingcap/tiflash/issues/9084) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - 空のパーティションを含むパーティション テーブルでクエリを実行するときに発生するクエリ タイムアウトの問題を修正しました。 [＃9024](https://github.com/pingcap/tiflash/issues/9024) @[JinheLin](https://github.com/JinheLin) + - 空のパーティションを含むパーティションテーブルでクエリを実行するときに発生するクエリタイムアウトの問題を修正しました。 [＃9024](https://github.com/pingcap/tiflash/issues/9024) @[JinheLin](https://github.com/JinheLin) - 分散ストレージとコンピューティングアーキテクチャで、コンピューティングノードのプロセスが停止するとTiFlash がpanicする可能性がある問題を修正しました[＃8860](https://github.com/pingcap/tiflash/issues/8860) @[guo-shaoge](https://github.com/guo-shaoge) - 生成列をクエリするとエラーが返される問題を修正しました [＃8787](https://github.com/pingcap/tiflash/issues/8787) @[guo-shaoge](https://github.com/guo-shaoge) - クラスタをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -212,10 +212,10 @@ TiDB バージョン: 7.5.2 - 特別なイベントタイミングにより、ログバックアップでデータ損失が発生する可能性があるという稀な問題を修正しました。 [＃16739](https://github.com/tikv/tikv/issues/16739) @[YuJuncen](https://github.com/YuJuncen) - フルバックアップが失敗したときにログが多すぎる問題を修正[＃51572](https://github.com/pingcap/tidb/issues/51572) @[Leavrth](https://github.com/Leavrth) - PD接続障害により、ログバックアップアドバンサ所有者が配置されているTiDBインスタンスがpanicになる可能性がある問題を修正しました。 [＃52597](https://github.com/pingcap/tidb/issues/52597) @[YuJuncen](https://github.com/YuJuncen) - - TiKV の再起動により、ログ バックアップのグローバル チェックポイントが実際のバックアップ ファイルの書き込みポイントよりも先に進められ、少量のバックアップ データが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) + - TiKV の再起動により、ログバックアップのグローバルチェックポイントが実際のバックアップファイルの書き込みポイントよりも先に進められ、少量のバックアップデータが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) - PD へのネットワーク接続が不安定な状態で一時停止中のログバックアップタスクを再開すると TiKV がpanicする可能性がある問題を修正しました [＃17020](https://github.com/tikv/tikv/issues/17020) @[YuJuncen](https://github.com/YuJuncen) - 不安定なテストケースを修正する [＃52547](https://github.com/pingcap/tidb/issues/52547) @[Leavrth](https://github.com/Leavrth) - - BRを使用してデータを復元する場合、または物理インポート モードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) + - BRを使用してデータを復元する場合、または物理インポートモードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) - フルバックアップでピアが見つからない場合に TiKV がパニックを起こす問題を修正[＃16394](https://github.com/tikv/tikv/issues/16394) @[Leavrth](https://github.com/Leavrth) - ログバックアップタスクを一時停止後に削除しても、GCセーフポイントがすぐに復元されない問題を修正しました。 [＃52082](https://github.com/pingcap/tidb/issues/52082) @[3pointer](https://github.com/3pointer) - 不安定なテストケース`TestClearCache` を修正 [＃50743](https://github.com/pingcap/tidb/issues/50743) @[3pointer](https://github.com/3pointer) diff --git a/releases/release-7.5.3.md b/releases/release-7.5.3.md index ce02cd7ad78e9..64dffa042a180 100644 --- a/releases/release-7.5.3.md +++ b/releases/release-7.5.3.md @@ -35,7 +35,7 @@ TiDB バージョン: 7.5.3 - Backup & Restore (BR) - `br log restore`サブコマンドを除き、他の`br log`サブコマンドはすべて、メモリ消費量を削減するために TiDB `domain`データ構造のロードをスキップすることをサポートしています[＃52088](https://github.com/pingcap/tidb/issues/52088) @[Leavrth](https://github.com/Leavrth) - - チェックポイントの遅延が大きい場合にログ バックアップ タスクを自動的に中止し、GC の長時間のブロッキングや潜在的なクラスターの問題を回避することをサポートします[＃50803](https://github.com/pingcap/tidb/issues/50803) @[RidRisR](https://github.com/RidRisR) + - チェックポイントの遅延が大きい場合にログバックアップタスクを自動的に中止し、GC の長時間のブロッキングや潜在的なクラスターの問題を回避することをサポートします[＃50803](https://github.com/pingcap/tidb/issues/50803) @[RidRisR](https://github.com/RidRisR) - DNSエラーによる失敗の再試行回数を増やす [＃53029](https://github.com/pingcap/tidb/issues/53029) @[YuJuncen](https://github.com/YuJuncen) - ログバックアップの互換性テストとインデックスアクセラレーションの追加をカバーするPITR統合テストケースを追加します。 [＃51987](https://github.com/pingcap/tidb/issues/51987) @[Leavrth](https://github.com/Leavrth) - リージョンのリーダー不在による失敗の再試行回数を増やす [＃54017](https://github.com/pingcap/tidb/issues/54017) @[Leavrth](https://github.com/Leavrth) @@ -64,7 +64,7 @@ TiDB バージョン: 7.5.3 - `sql_mode=''` の場合に、フィールドの`UNSIGNED`型を`-1`に更新すると`0`ではなく`null`が返される問題を修正しました。 [＃47816](https://github.com/pingcap/tidb/issues/47816) @[lcwangchao](https://github.com/lcwangchao) - 最初の引数が`month`で、2番目の引数が負の場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 [＃54908](https://github.com/pingcap/tidb/issues/54908) @[xzhangxian1008](https://github.com/xzhangxian1008) - ハンドシェイクが完了する前に一部の接続が終了した場合に、Grafana の接続数監視メトリックが正しくない問題を修正しました[＃54428](https://github.com/pingcap/tidb/issues/54428) @[YangKeao](https://github.com/YangKeao) - - TiProxy とリソース グループを使用するときに、各リソース グループの接続数が正しくない問題を修正しました。 [＃54545](https://github.com/pingcap/tidb/issues/54545) @[YangKeao](https://github.com/YangKeao) + - TiProxy とリソースグループを使用するときに、各リソースグループの接続数が正しくない問題を修正しました。 [＃54545](https://github.com/pingcap/tidb/issues/54545) @[YangKeao](https://github.com/YangKeao) - `CREATE OR REPLACE VIEW`同時に実行すると`table doesn't exist`エラーが発生する可能性がある問題を修正 [＃53673](https://github.com/pingcap/tidb/issues/53673) @[tangenta](https://github.com/tangenta) - データ変更操作を含むトランザクションで仮想列を持つテーブルをクエリすると、TiDB が誤ったクエリ結果を返す可能性がある問題を修正しました [＃53951](https://github.com/pingcap/tidb/issues/53951) @[qw4990](https://github.com/qw4990) - `SELECT DISTINCT CAST(col AS DECIMAL), CAST(col AS SIGNED) FROM ...`クエリを実行すると誤った結果が返される可能性がある問題を修正[＃53726](https://github.com/pingcap/tidb/issues/53726) @[hawkingrei](https://github.com/hawkingrei) @@ -89,12 +89,12 @@ TiDB バージョン: 7.5.3 - gRPC メッセージ圧縮方式を`grpc-compression-type`で設定しても、TiKV から TiDB に送信されるメッセージには反映されない問題を修正しました。 [＃17176](https://github.com/tikv/tikv/issues/17176) @[ekexium](https://github.com/ekexium) - 同時実行性の高いコプロセッサー要求により TiKV OOM が発生する可能性がある問題を修正しました [＃16653](https://github.com/tikv/tikv/issues/16653) @[overvenus](https://github.com/overvenus) - CDC とログバックアップが`advance-ts-interval`構成を使用して`check_leader`のタイムアウトを制限しないため、TiKV が正常に再起動したときに`resolved_ts`遅延が大きくなる場合がある問題を修正しました[＃17107](https://github.com/tikv/tikv/issues/17107) @[MyonKeminta](https://github.com/MyonKeminta) - - 破損したRaftデータ スナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [＃15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) + - 破損したRaftデータスナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [＃15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) - PD - - リソース グループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - - 500 ミリ秒を超えるトークンをリクエストするとリソース グループがクォータ制限に達する問題を修正[＃8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) + - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) + - 500 ミリ秒を超えるトークンをリクエストするとリソースグループがクォータ制限に達する問題を修正[＃8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) - リソースグループのデータ競合問題を修正 [＃8267](https://github.com/tikv/pd/issues/8267) @[HuSharp](https://github.com/HuSharp) - PD がオペレータ チェック中に遭遇するデータ競合問題を修正しました [＃8263](https://github.com/tikv/pd/issues/8263) @[lhy1024](https://github.com/lhy1024) - 削除されたノードがetcdクライアントの候補接続リストにまだ表示される問題を修正 [＃8286](https://github.com/tikv/pd/issues/8286) @[JmPotato](https://github.com/JmPotato) diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index b5c5f9deff1d8..fb33c63a466a0 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -70,7 +70,7 @@ TiDB バージョン: 7.5.4 - 整数型の列に小さい表示幅が指定された場合、 `out of range`エラーが発生する可能性がある問題を修正しました。 [＃55837](https://github.com/pingcap/tidb/issues/55837) @[windtalker](https://github.com/windtalker) - 一意インデックスを追加するときに`duplicate entry`発生する可能性がある問題を修正 [＃56161](https://github.com/pingcap/tidb/issues/56161) @[tangenta](https://github.com/tangenta) - `IMPORT INTO`文を使用して一時テーブルをインポートするときに TiDB がパニックになる問題を修正しました [＃55970](https://github.com/pingcap/tidb/issues/55970) @[D3Hunter](https://github.com/D3Hunter) - - インデックス追加中の再試行によって発生するデータ インデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) + - インデックス追加中の再試行によって発生するデータインデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) - TiKV @@ -86,7 +86,7 @@ TiDB バージョン: 7.5.4 - 多数のリージョンが存在する場合にPDのリージョンAPIをリクエストできない問題を修正[＃55872](https://github.com/pingcap/tidb/issues/55872) @[rleungx](https://github.com/rleungx) - `evict-leader-scheduler`で間違ったパラメータを使用すると、PD がエラーを正しく報告せず、一部のスケジューラが利用できなくなる問題を修正しました[＃8619](https://github.com/tikv/pd/issues/8619) @[rleungx](https://github.com/rleungx) - マイクロサービスモードでPDリーダーが切り替えられたときにスケジューリングサーバーでデータ競合が発生する可能性がある問題を修正しました [＃8538](https://github.com/tikv/pd/issues/8538) @[lhy1024](https://github.com/lhy1024) - - リソース グループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) + - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - `INFORMATION_SCHEMA.RUNAWAY_WATCHES`テーブルの時間データ型が正しくない問題を修正[＃54770](https://github.com/pingcap/tidb/issues/54770) @[HuSharp](https://github.com/HuSharp) - `replication.strictly-match-label`を`true`に設定するとTiFlashが起動しなくなる問題を修正 [＃8480](https://github.com/tikv/pd/issues/8480) @[rleungx](https://github.com/rleungx) @@ -96,7 +96,7 @@ TiDB バージョン: 7.5.4 - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラーが発生する可能性がある問題を修正しました。 [＃9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[＃8754](https://github.com/pingcap/tiflash/issues/8754) @[solotzg](https://github.com/solotzg) - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 [＃9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) - - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 遅延マテリアライゼーションが有効になっている場合に一部のクエリでエラーが報告される可能性がある問題を修正[＃9472](https://github.com/pingcap/tiflash/issues/9472) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - データ型を`DECIMAL`型に変換すると、極端なケースで間違ったクエリ結果が返される可能性がある問題を修正しました[＃53892](https://github.com/pingcap/tidb/issues/53892) @[guo-shaoge](https://github.com/guo-shaoge) diff --git a/releases/release-7.5.5.md b/releases/release-7.5.5.md index 3286b2ee575cf..e84e7987592e9 100644 --- a/releases/release-7.5.5.md +++ b/releases/release-7.5.5.md @@ -77,10 +77,10 @@ TiDB バージョン: 7.5.5 - `RECOVER TABLE BY JOB JOB_ID;`を実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @[crazycs520](https://github.com/crazycs520) - クエリに利用可能なインデックスマージ実行計画がある場合に`read_from_storage`ヒントが有効にならない可能性がある問題を修正しました [＃56217](https://github.com/pingcap/tidb/issues/56217) @[AilinKid](https://github.com/AilinKid) - 異常終了時に`INDEX_HASH_JOIN`アップする可能性がある問題を修正[＃54055](https://github.com/pingcap/tidb/issues/54055) @[wshwsh12](https://github.com/wshwsh12) - - 分散実行フレームワーク (DXF) に関連するシステム テーブルをクエリすると、アップグレードが失敗する可能性がある問題を修正しました[＃49263](https://github.com/pingcap/tidb/issues/49263) @[D3Hunter](https://github.com/D3Hunter) + - 分散実行フレームワーク (DXF) に関連するシステムテーブルをクエリすると、アップグレードが失敗する可能性がある問題を修正しました[＃49263](https://github.com/pingcap/tidb/issues/49263) @[D3Hunter](https://github.com/D3Hunter) - DDL内部トランザクションエラー`GC life time is shorter than transaction duration`によりインデックス追加が失敗する問題を修正[＃57043](https://github.com/pingcap/tidb/issues/57043) @[tangenta](https://github.com/tangenta) - `EXCHANGE PARTITION`を実行して無効な行に遭遇すると、InfoSchema が完全にロードされ、エラー`failed to load schema diff`が報告される問題を修正しました。 [＃56685](https://github.com/pingcap/tidb/issues/56685) @[D3Hunter](https://github.com/D3Hunter) - - `tidb_ddl_enable_fast_reorg`と`new_collations_enabled_on_first_bootstrap`有効になっているときに照合順序が正しく処理されず、データ インデックスが不一致になる問題を修正しました。 [＃58036](https://github.com/pingcap/tidb/issues/58036) @[djshow832](https://github.com/djshow832) + - `tidb_ddl_enable_fast_reorg`と`new_collations_enabled_on_first_bootstrap`有効になっているときに照合順序が正しく処理されず、データインデックスが不一致になる問題を修正しました。 [＃58036](https://github.com/pingcap/tidb/issues/58036) @[djshow832](https://github.com/djshow832) - プランキャッシュがインデックスを追加するときに間違ったスキーマを使用するため、データインデックスが不整合になる問題を修正しました。 [＃56733](https://github.com/pingcap/tidb/issues/56733) @[wjhuang2016](https://github.com/wjhuang2016) - アップグレード中に`ALTER TABLE TIFLASH REPLICA`を実行するとTiDBノードがクラッシュする問題を修正[＃57863](https://github.com/pingcap/tidb/issues/57863) @[tangenta](https://github.com/tangenta) - クエリ`INFORMATION_SCHEMA.columns`のパフォーマンスが低下する問題を修正 [＃58184](https://github.com/pingcap/tidb/issues/58184) @[lance6716](https://github.com/lance6716) @@ -115,7 +115,7 @@ TiDB バージョン: 7.5.5 - etcdリーダー遷移中にPDがリーダーを素早く再選出できない問題を修正 [＃8823](https://github.com/tikv/pd/issues/8823) @[rleungx](https://github.com/rleungx) - ラベル統計のメモリリーク問題を修正 [＃8700](https://github.com/tikv/pd/issues/8700) @[lhy1024](https://github.com/lhy1024) - 同じストアID で繰り返し作成された場合に`evict-leader-scheduler`正常に動作しない問題を修正 [＃8756](https://github.com/tikv/pd/issues/8756) @[okJiang](https://github.com/okJiang) - - リソース グループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) + - リソースグループ クライアントでスロットが完全に削除されず、割り当てられたトークンの数が指定された値より少なくなる問題を修正しました。 [＃7346](https://github.com/tikv/pd/issues/7346) @[guo-shaoge](https://github.com/guo-shaoge) - `evict-leader-scheduler`で間違ったパラメータを使用すると、PD がエラーを正しく報告せず、一部のスケジューラが利用できなくなる問題を修正しました[＃8619](https://github.com/tikv/pd/issues/8619) @[rleungx](https://github.com/rleungx) - ホットスポット キャッシュのメモリリーク問題を修正 [＃8698](https://github.com/tikv/pd/issues/8698) @[lhy1024](https://github.com/lhy1024) - 乱数ジェネレータの頻繁な作成によって発生するパフォーマンスジッターの問題を修正しました [＃8674](https://github.com/tikv/pd/issues/8674) @[rleungx](https://github.com/rleungx) @@ -125,7 +125,7 @@ TiDB バージョン: 7.5.5 - TiFlash が同時 DDL 実行中に競合に遭遇した場合のTiFlash panic問題を修正[＃8578](https://github.com/pingcap/tiflash/issues/8578) @[JaySon-Huang](https://github.com/JaySon-Huang) - `LPAD()`と`RPAD()`関数が、場合によっては誤った結果を返す問題を修正しました[＃9465](https://github.com/pingcap/tiflash/issues/9465) @[guo-shaoge](https://github.com/guo-shaoge) - 2番目のパラメータが負のの場合に`SUBSTRING()`関数が誤った結果を返す問題を修正しました [＃9604](https://github.com/pingcap/tiflash/issues/9604) @[guo-shaoge](https://github.com/guo-shaoge) - - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 分散ストレージおよびコンピューティングアーキテクチャで新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました [＃9665](https://github.com/pingcap/tiflash/issues/9665) @[zimulala](https://github.com/zimulala) - ツール @@ -145,7 +145,7 @@ TiDB バージョン: 7.5.5 - Simpleプロトコルメッセージでパーティションテーブルの`tableID`正しく設定されていない問題を修正しました。 [＃11846](https://github.com/pingcap/tiflow/issues/11846) @[3AceShowHand](https://github.com/3AceShowHand) - やり直しモジュールがエラーを正しく報告できない問題を修正しました [＃11744](https://github.com/pingcap/tiflow/issues/11744) @[CharlesCheung96](https://github.com/CharlesCheung96) - `ignore-event`で`add table partition`イベントをフィルタリングするように設定した後、TiCDC が関連パーティションの他のタイプの DML 変更をダウンストリームに複製しない問題を修正しました。 [＃10524](https://github.com/pingcap/tiflow/issues/10524) @[CharlesCheung96](https://github.com/CharlesCheung96) - - TiDB DDL 所有者の変更中に DDL タスクのスキーマ バージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) + - TiDB DDL 所有者の変更中に DDL タスクのスキーマバージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) - TiDB Data Migration (DM) diff --git a/releases/release-7.5.6.md b/releases/release-7.5.6.md index 179ad524f76a1..5af606d96ad5d 100644 --- a/releases/release-7.5.6.md +++ b/releases/release-7.5.6.md @@ -38,7 +38,7 @@ TiDB バージョン: 7.5.6 - Backup & Restore (BR) - バックアップパフォーマンスを向上させるために、フルバックアップ中のテーブルレベルのチェックサム計算をデフォルトで無効にする（ `--checksum=false` ） [＃56373](https://github.com/pingcap/tidb/issues/56373) @[Tristan1900](https://github.com/Tristan1900) - - 非完全リストアの場合、ターゲット クラスタに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 [＃55087](https://github.com/pingcap/tidb/issues/55087) @[RidRisR](https://github.com/RidRisR) + - 非完全リストアの場合、ターゲットクラスタに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 [＃55087](https://github.com/pingcap/tidb/issues/55087) @[RidRisR](https://github.com/RidRisR) - TiDB Lightning @@ -53,7 +53,7 @@ TiDB バージョン: 7.5.6 - 同じ名前のビューを2つ作成してもエラーが報告されない問題を修正[＃58769](https://github.com/pingcap/tidb/issues/58769) @[tiancaiamao](https://github.com/tiancaiamao) - `BIT`型から`CHAR`型にデータを変換すると TiKV パニックが発生する可能性がある問題を修正しました [＃56494](https://github.com/pingcap/tidb/issues/56494) @[lcwangchao](https://github.com/lcwangchao) - ハートビートを失った TTL ジョブが他のジョブのハートビートの取得をブロックする問題を修正しました [＃57915](https://github.com/pingcap/tidb/issues/57915) @[YangKeao](https://github.com/YangKeao) - - 不一致な値タイプとタイプ変換エラーを含む`IN`条件を使用してパーティション テーブルをクエリすると、誤ったクエリ結果が発生する問題を修正しました。 [＃54746](https://github.com/pingcap/tidb/issues/54746) @[mjonss](https://github.com/mjonss) + - 不一致な値タイプとタイプ変換エラーを含む`IN`条件を使用してパーティションテーブルをクエリすると、誤ったクエリ結果が発生する問題を修正しました。 [＃54746](https://github.com/pingcap/tidb/issues/54746) @[mjonss](https://github.com/mjonss) - `BIT`列のデフォルト値が正しくない問題を修正[＃57301](https://github.com/pingcap/tidb/issues/57301) @[YangKeao](https://github.com/YangKeao) - Prepareプロトコルで、クライアントがUTF8以外の文字セットを使用するとエラーが発生する問題を修正しました。 [＃58870](https://github.com/pingcap/tidb/issues/58870) @[xhebox](https://github.com/xhebox) - `CREATE VIEW`ステートメントで変数またはパラメータを使用してもエラーが報告されない問題を修正[＃53176](https://github.com/pingcap/tidb/issues/53176) @[mjonss](https://github.com/mjonss) @@ -70,7 +70,7 @@ TiDB バージョン: 7.5.6 - 分散ストレージおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスターで`ALTER TABLE ... PLACEMENT POLICY ...`を実行した後、リージョンピアが誤ってTiFlashコンピューティングノードに追加される可能性がある問題を修正しました。 [＃58633](https://github.com/pingcap/tidb/issues/58633) @[JaySon-Huang](https://github.com/JaySon-Huang) - DDL所有者が変更されるとジョブステータスが上書きされる問題を修正 [＃52747](https://github.com/pingcap/tidb/issues/52747) @[D3Hunter](https://github.com/D3Hunter) - ハッシュパーティションテーブルで条件`is null`クエリを実行するとpanicが発生する問題を修正 [＃58374](https://github.com/pingcap/tidb/issues/58374) @[Defined2014](https://github.com/Defined2014) - - 生成列を含むパーティション テーブルをクエリするときにエラーが発生する問題を修正しました。 [＃58475](https://github.com/pingcap/tidb/issues/58475) @[joechenrh](https://github.com/joechenrh) + - 生成列を含むパーティションテーブルをクエリするときにエラーが発生する問題を修正しました。 [＃58475](https://github.com/pingcap/tidb/issues/58475) @[joechenrh](https://github.com/joechenrh) - TTLジョブが無視されたり、複数回処理されたりする問題を修正[＃59347](https://github.com/pingcap/tidb/issues/59347) @[YangKeao](https://github.com/YangKeao) - パーティション交換での誤った判断により実行エラーが発生する問題を修正[＃59534](https://github.com/pingcap/tidb/issues/59534) @[mjonss](https://github.com/mjonss) - `tidb_audit_log`変数を複数レベルの相対パスで設定すると、ログディレクトリでエラーが発生する問題を修正しました。 [＃58971](https://github.com/pingcap/tidb/issues/58971) @[lcwangchao](https://github.com/lcwangchao) @@ -106,10 +106,10 @@ TiDB バージョン: 7.5.6 - メモリ使用量が少ないときにTiFlash が予期せずRaftメッセージの処理を拒否する可能性がある問題を修正[＃9745](https://github.com/pingcap/tiflash/issues/9745) @[CalvinNeo](https://github.com/CalvinNeo) - 大量のデータをインポートした後にTiFlash のメモリ使用量が高くなる可能性がある問題を修正[＃9812](https://github.com/pingcap/tiflash/issues/9812) @[CalvinNeo](https://github.com/CalvinNeo) - パーティションテーブルに対するクエリが、パーティションテーブルで`ALTER TABLE ... RENAME COLUMN`を実行した後にエラーを返す可能性がある問題を修正しました。 [＃9787](https://github.com/pingcap/tiflash/issues/9787) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - 特定の状況でTiFlash が予期せず終了したときにエラー スタック トレースを印刷できないことがある問題を修正[＃9902](https://github.com/pingcap/tiflash/issues/9902) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 特定の状況でTiFlash が予期せず終了したときにエラースタック トレースを印刷できないことがある問題を修正[＃9902](https://github.com/pingcap/tiflash/issues/9902) @[JaySon-Huang](https://github.com/JaySon-Huang) - `profiles.default.init_thread_count_scale` `0` に設定するとTiFlash の起動がブロックされる可能性がある問題を修正しました [＃9906](https://github.com/pingcap/tiflash/issues/9906) @[JaySon-Huang](https://github.com/JaySon-Huang) - クエリに仮想列が含まれており、リモート読み取りをトリガーするときに`Not found column`エラーが発生する可能性がある問題を修正しました。 [＃9561](https://github.com/pingcap/tiflash/issues/9561) @[guo-shaoge](https://github.com/guo-shaoge) - - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlashコンピューティング ノードがリージョンピアを追加するためのターゲット ノードとして誤って選択される可能性がある問題を修正しました。 [＃9750](https://github.com/pingcap/tiflash/issues/9750) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlashコンピューティングノードがリージョンピアを追加するためのターゲットノードとして誤って選択される可能性がある問題を修正しました。 [＃9750](https://github.com/pingcap/tiflash/issues/9750) @[JaySon-Huang](https://github.com/JaySon-Huang) - ツール diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index 43ca73918376e..45d257a6ad520 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -79,7 +79,7 @@ TiDB バージョン: 7.5.7 - `ALTER RANGE meta SET PLACEMENT POLICY` のキー範囲が正しくない問題を修正しました [＃60888](https://github.com/pingcap/tidb/issues/60888) @[nolouch](https://github.com/nolouch) - Grafanaの**Stats Healthy Distribution**パネルのデータが正しくない可能性がある問題を修正しました[＃57176](https://github.com/pingcap/tidb/issues/57176) @[hawkingrei](https://github.com/hawkingrei) - `latin1_bin`の比較動作が`utf8mb4_bin`および`utf8_bin` と異なる問題を修正しました [＃60701](https://github.com/pingcap/tidb/issues/60701) @[hawkingrei](https://github.com/hawkingrei) - - メタデータ ロック (MDL) を無効にした後、スキーマ バージョン更新に失敗して DDL 操作が停止する問題を修正しました。 [＃61210](https://github.com/pingcap/tidb/issues/61210) @[wjhuang2016](https://github.com/wjhuang2016) + - メタデータロック (MDL) を無効にした後、スキーマバージョン更新に失敗して DDL 操作が停止する問題を修正しました。 [＃61210](https://github.com/pingcap/tidb/issues/61210) @[wjhuang2016](https://github.com/wjhuang2016) - 特定のシナリオでログの秘匿化が有効にならない問題を修正[＃59279](https://github.com/pingcap/tidb/issues/59279) @[tangenta](https://github.com/tangenta) - 修正コントロール#44855が有効になっている場合にTiDBセッションがクラッシュする可能性がある問題を修正[＃59762](https://github.com/pingcap/tidb/issues/59762) @[winoros](https://github.com/winoros) - `IndexLookup`オペレータが`context canceled`エラーに遭遇したときに冗長なログエントリを削除します [＃61072](https://github.com/pingcap/tidb/issues/61072) @[yibin87](https://github.com/yibin87) @@ -104,7 +104,7 @@ TiDB バージョン: 7.5.7 - 列またはインデックスの統計情報が欠落している場合、 `JOIN`行数推定が非常に不正確になる可能性がある問題を修正しました[＃61602](https://github.com/pingcap/tidb/issues/61602) @[qw4990](https://github.com/qw4990) - システム変数`tidb_cost_model_version`のデフォルト値が誤って設定されている問題を修正[＃61565](https://github.com/pingcap/tidb/issues/61565) @[hawkingrei](https://github.com/hawkingrei) - テーブルの最初の列が仮想生成列の場合に統計が正しくない可能性がある問題を修正しました [＃61606](https://github.com/pingcap/tidb/issues/61606) @[winoros](https://github.com/winoros) - - 述語の簡素化でプラン キャッシュが誤ってスキップされる問題を修正しました [＃61513](https://github.com/pingcap/tidb/issues/61513) @[hawkingrei](https://github.com/hawkingrei) + - 述語の簡素化でプランキャッシュが誤ってスキップされる問題を修正しました [＃61513](https://github.com/pingcap/tidb/issues/61513) @[hawkingrei](https://github.com/hawkingrei) - インデックスの追加中に`ADMIN CANCEL DDL JOBS`を実行すると、インデックスの追加プロセスがハングする問題を修正しました。 [＃61087](https://github.com/pingcap/tidb/issues/61087) @[tangenta](https://github.com/tangenta) - 一部の内部 SQL 実行が失敗した後でも`ADMIN CHECK`が成功を返す問題を修正[＃61612](https://github.com/pingcap/tidb/issues/61612) @[joechenrh](https://github.com/joechenrh) - マルチスキーマ変更で複数のインデックスを追加した後にデータとインデックスが不整合になる問題を修正 [＃61255](https://github.com/pingcap/tidb/issues/61255) @[tangenta](https://github.com/tangenta) @@ -145,7 +145,7 @@ TiDB バージョン: 7.5.7 - Backup & Restore (BR) - PITRが3072バイトを超えるインデックスの復元に失敗する問題を修正[＃58430](https://github.com/pingcap/tidb/issues/58430) @[YuJuncen](https://github.com/YuJuncen) - - 大量のデータを転送するときに Azure Blob Storage へのログ バックアップのアップロードが遅くなる問題を修正[＃18410](https://github.com/tikv/tikv/issues/18410) @[YuJuncen](https://github.com/YuJuncen) + - 大量のデータを転送するときに Azure Blob Storage へのログバックアップのアップロードが遅くなる問題を修正[＃18410](https://github.com/tikv/tikv/issues/18410) @[YuJuncen](https://github.com/YuJuncen) - `-f` でテーブルをフィルタリングするときに、 BR が対応するテーブルがクラスター内に存在するかどうかをチェックしない問題を修正しました。 [＃61592](https://github.com/pingcap/tidb/issues/61592) @[RidRisR](https://github.com/RidRisR) - TiCDC diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index 45d4b0626cf94..7ad5806393b3d 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -19,11 +19,11 @@ TiDB バージョン: 7.6.0 ### 拡張性 {#scalability} -- Active PD Follower機能を使用して PD のリージョン情報クエリ サービスのスケーラビリティを強化する (実験的) [#7431](https://github.com/tikv/pd/issues/7431) @[CabinfeverB](https://github.com/CabinfeverB) +- Active PD Follower機能を使用して PD のリージョン情報クエリサービスのスケーラビリティを強化する (実験的) [#7431](https://github.com/tikv/pd/issues/7431) @[CabinfeverB](https://github.com/CabinfeverB) リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 - 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリ サービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 + 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 詳細については、 [ドキュメント](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)を参照してください。 @@ -146,7 +146,7 @@ TiDB バージョン: 7.6.0 - 長時間実行されているアイドル状態のトランザクションを自動的に終了させる機能のサポート [#48714](https://github.com/pingcap/tidb/pull/48714) @[crazycs520](https://github.com/crazycs520) - ネットワーク切断やアプリケーション障害が発生するシナリオでは、 `COMMIT` / `ROLLBACK`ステートメントがデータベースに送信されない可能性があります。これにより、データベース ロックの解放が遅延し、トランザクション ロック待機が発生し、データベース接続が急増する可能性があります。このような問題はテスト環境ではよく発生しますが、本番環境でも時折発生する可能性があり、迅速な診断が難しい場合があります。これらの問題を回避するために、TiDB v7.6.0 では、長時間実行されているアイドル状態のトランザクションを自動的に終了する[`tidb_idle_transaction_timeout`](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760)システム変数が導入されました。トランザクション状態のユーザー セッションがこの変数の値を超える期間アイドル状態になると、TiDB はトランザクションのデータベース接続を終了し、トランザクションをロールバックします。 + ネットワーク切断やアプリケーション障害が発生するシナリオでは、 `COMMIT` / `ROLLBACK`ステートメントがデータベースに送信されない可能性があります。これにより、データベース ロックの解放が遅延し、トランザクション ロック待機が発生し、データベース接続が急増する可能性があります。このような問題はテスト環境ではよく発生しますが、本番環境でも時折発生する可能性があり、迅速な診断が難しい場合があります。これらの問題を回避するために、TiDB v7.6.0 では、長時間実行されているアイドル状態のトランザクションを自動的に終了する[`tidb_idle_transaction_timeout`](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760)システム変数が導入されました。トランザクション状態のユーザーセッションがこの変数の値を超える期間アイドル状態になると、TiDB はトランザクションのデータベース接続を終了し、トランザクションをロールバックします。 詳細については、 [ドキュメント](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760)を参照してください。 @@ -168,7 +168,7 @@ TiDB バージョン: 7.6.0 詳細については、 [ドキュメント](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)を参照してください。 -- BR はデフォルトでユーザー データなどのシステム テーブルを復元します[#48567](https://github.com/pingcap/tidb/issues/48567) @[BornChanger](https://github.com/BornChanger) [#49627](https://github.com/pingcap/tidb/issues/49627) @[Leavrth](https://github.com/Leavrth) +- BR はデフォルトでユーザーデータなどのシステムテーブルを復元します[#48567](https://github.com/pingcap/tidb/issues/48567) @[BornChanger](https://github.com/BornChanger) [#49627](https://github.com/pingcap/tidb/issues/49627) @[Leavrth](https://github.com/Leavrth) バージョン5.1.0以降、スナップショットをバックアップすると、 BRは`mysql`スキーマ内のシステムテーブルを自動的にバックアップしますが、デフォルトではこれらのシステムテーブルを復元しません。バージョン6.2.0では、 BRは`--with-sys-table`パラメータを追加し、一部のシステムテーブルのデータを復元できるようにすることで、操作の柔軟性を向上させています。 @@ -180,10 +180,10 @@ TiDB バージョン: 7.6.0 - リソース制御に関する可観測性の強化 [#49318](https://github.com/pingcap/tidb/issues/49318) @[glorv](https://github.com/glorv)@[bufferflies](https://github.com/bufferflies)@[nolouch](https://github.com/nolouch) - アプリケーションのワークロードを分離するためにリソース グループを使用するユーザーが増えるにつれ、リソース コントロールはリソース グループに基づいた強化されたデータを提供します。これにより、リソース グループのワークロードと設定を監視し、次のような問題を迅速かつ正確に特定して診断できるようになります。 + アプリケーションのワークロードを分離するためにリソースグループを使用するユーザーが増えるにつれ、リソース コントロールはリソースグループに基づいた強化されたデータを提供します。これにより、リソースグループのワークロードと設定を監視し、次のような問題を迅速かつ正確に特定して診断できるようになります。 - - [スロークエリ](/identify-slow-queries.md): リソース グループ名、リソース ユニット (RU) の消費量、およびリソースの待機時間を追加します。 - - [ステートメントサマリーテーブル](/statement-summary-tables.md): リソース グループ名、RU 消費量、リソースの待機時間を追加します。 + - [スロークエリ](/identify-slow-queries.md): リソースグループ名、リソース ユニット (RU) の消費量、およびリソースの待機時間を追加します。 + - [ステートメントサマリーテーブル](/statement-summary-tables.md): リソースグループ名、RU 消費量、リソースの待機時間を追加します。 - システム変数[`tidb_last_query_info`](/system-variables.md#tidb_last_query_info-new-in-v4014)に、SQL ステートメントによって消費された[RU](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)を示す新しいエントリ`ru_consumption`を追加します。この変数を使用して、セッション内の最後のステートメントのリソース消費量を取得できます。 - リソースグループに基づいてデータベースのメトリックを追加します。具体的には、QPS/TPS、実行時間（P999/P99/P95）、障害発生回数、接続数などです。 - すべてのリソースグループの1日あたりのRU消費量の履歴レコードを記録するために、システムテーブル[`request_unit_by_group`](/mysql-schema/mysql-schema.md#system-tables-related-to-resource-control)を追加します。 @@ -224,7 +224,7 @@ TiDB バージョン: 7.6.0 ### MySQLとの互換性 {#mysql-compatibility} -- TiDB v7.6.0 より前は、 `LOAD DATA`操作は、単一のトランザクションですべての行をコミットするか、トランザクションをバッチでコミットしていました。これは MySQL の動作とは若干異なります。v7.6.0 以降、TiDB は`LOAD DATA` MySQL と同様にトランザクションで処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB のトランザクション モード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 [#49079](https://github.com/pingcap/tidb/pull/49079) @[ekexium](https://github.com/ekexium) +- TiDB v7.6.0 より前は、 `LOAD DATA`操作は、単一のトランザクションですべての行をコミットするか、トランザクションをバッチでコミットしていました。これは MySQL の動作とは若干異なります。v7.6.0 以降、TiDB は`LOAD DATA` MySQL と同様にトランザクションで処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB のトランザクションモード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 [#49079](https://github.com/pingcap/tidb/pull/49079) @[ekexium](https://github.com/ekexium) ### システム変数 {#system-variables} @@ -267,14 +267,14 @@ TiDB バージョン: 7.6.0 - TiDBでサポートされているすべてのキーワードの情報を表示するために、新しいシステムテーブル[`INFORMATION_SCHEMA.KEYWORDS`](/information-schema/information-schema-keywords.md)を追加します。 - システムテーブル[`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md)に、リソース制御に関連する以下のフィールドを追加します。 - - `Resource_group` : ステートメントがバインドされているリソース グループ。 + - `Resource_group` : ステートメントがバインドされているリソースグループ。 - `Request_unit_read` : ステートメントによって消費された読み取り RU の合計。 - `Request_unit_write` : ステートメントによって消費された書き込み RU の合計。 - `Time_queued_by_rc` : ステートメントが利用可能なリソースを待機する合計時間。 ## オフラインパッケージの変更 {#offline-package-changes} -v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-package.md)には、プロキシ コンポーネント[TiProxy](/tiproxy/tiproxy-overview.md)のインストール パッケージである`tiproxy-{version}-linux-{arch}.tar.gz`含まれるようになりました。 +v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-package.md)には、プロキシ コンポーネント[TiProxy](/tiproxy/tiproxy-overview.md)のインストールパッケージである`tiproxy-{version}-linux-{arch}.tar.gz`含まれるようになりました。 ## 非推奨機能 {#deprecated-features} @@ -302,7 +302,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - TiKV - 非同期タスクを照会するためのAPIエンドポイント`/async_tasks`を追加 [#15759](https://github.com/tikv/tikv/issues/15759) @[YuJuncen](https://github.com/YuJuncen) - - gRPC モニタリングに優先度ラベルを追加して、異なる優先度のリソース グループ データを表示します [#49318](https://github.com/pingcap/tidb/issues/49318) @[bufferflies](https://github.com/bufferflies) + - gRPC モニタリングに優先度ラベルを追加して、異なる優先度のリソースグループ データを表示します [#49318](https://github.com/pingcap/tidb/issues/49318) @[bufferflies](https://github.com/bufferflies) - `readpool.unified.max-tasks-per-worker`の値を動的に調整することで、優先度に基づいて実行中のタスク数を個別に計算できます [#16026](https://github.com/tikv/tikv/issues/16026) @[glorv](https://github.com/glorv) - GCスレッド数を動的に調整する機能をサポート。デフォルト値は`1` [#16101](https://github.com/tikv/tikv/issues/16101) @[tonyxuqqi](https://github.com/tonyxuqqi) @@ -372,7 +372,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - `ALTER TABLE t PARTITION BY`を実行する際に配置ルールを指定すると`ERROR 8239`というエラーが報告される問題を修正しました。 [#48630](https://github.com/pingcap/tidb/issues/48630) @[mjonss](https://github.com/mjonss) - `START_TIME`の`INFORMATION_SCHEMA.CLUSTER_INFO`列タイプが無効であるという問題を修正します [#45221](https://github.com/pingcap/tidb/issues/45221) @[dveeden](https://github.com/dveeden) - `EXTRA`の列タイプが無効であるために`INFORMATION_SCHEMA.COLUMNS`エラー`Data Too Long, field len 30, data len 45`が発生する問題を修正しました。 [#42030](https://github.com/pingcap/tidb/issues/42030) @[tangenta](https://github.com/tangenta) - - `IN (...)`で`INFORMATION_SCHEMA.STATEMENTS_SUMMARY`で異なるプラン ダイジェストが発生する問題を修正 [#33559](https://github.com/pingcap/tidb/issues/33559) @[King-Dylan](https://github.com/King-Dylan) + - `IN (...)`で`INFORMATION_SCHEMA.STATEMENTS_SUMMARY`で異なるプランダイジェストが発生する問題を修正 [#33559](https://github.com/pingcap/tidb/issues/33559) @[King-Dylan](https://github.com/King-Dylan) - `TIME`型を`YEAR`型に変換する際に、返される結果に`TIME`と年が混在する問題を修正しました。 [#48557](https://github.com/pingcap/tidb/issues/48557) @[YangKeao](https://github.com/YangKeao) - `tidb_enable_collect_execution_info`を無効にするとコプロセッサキャッシュがpanicを起こす問題を修正 [#48212](https://github.com/pingcap/tidb/issues/48212) @[you06](https://github.com/you06) - `shuffleExec`が予期せず終了した際にTiDBがクラッシュする問題を修正 [#48230](https://github.com/pingcap/tidb/issues/48230) @[wshwsh12](https://github.com/wshwsh12) @@ -412,9 +412,9 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - `UPDATE` 、 `DELETE` 、および`INSERT`ステートメントが、 `SQL_MODE`が厳密でない場合に警告ではなくオーバーフローエラーを返す問題を修正します [#49137](https://github.com/pingcap/tidb/issues/49137) @[YangKeao](https://github.com/YangKeao) - テーブルに多値インデックスと非バイナリ型文字列で構成される複合インデックスがある場合にデータを挿入できない問題を修正 [#49680](https://github.com/pingcap/tidb/issues/49680) @[YangKeao](https://github.com/YangKeao) - 多階層にネストされた`LIMIT`クエリ内の`UNION`無効になる可能性がある問題を修正 [#49874](https://github.com/pingcap/tidb/issues/49874) @[Defined2014](https://github.com/Defined2014) - - `BETWEEN ... AND ...`条件を使用してパーティション テーブルをクエリすると誤った結果が返される問題を修正 [#49842](https://github.com/pingcap/tidb/issues/49842) @[Defined2014](https://github.com/Defined2014) + - `BETWEEN ... AND ...`条件を使用してパーティションテーブルをクエリすると誤った結果が返される問題を修正 [#49842](https://github.com/pingcap/tidb/issues/49842) @[Defined2014](https://github.com/Defined2014) - `REPLACE INTO`ステートメントでヒントが使用できない問題を修正 [#34325](https://github.com/pingcap/tidb/issues/34325) @[YangKeao](https://github.com/YangKeao) - - ハッシュ パーティション テーブルのクエリ時に TiDB が間違ったパーティションを選択する可能性がある問題を修正 [#50044](https://github.com/pingcap/tidb/issues/50044) @[Defined2014](https://github.com/Defined2014) + - ハッシュパーティションテーブルのクエリ時に TiDB が間違ったパーティションを選択する可能性がある問題を修正 [#50044](https://github.com/pingcap/tidb/issues/50044) @[Defined2014](https://github.com/Defined2014) - 圧縮を有効にして MariaDB Connector/J を使用するときに発生する接続エラーを修正 [#49845](https://github.com/pingcap/tidb/issues/49845) @[onlyacat](https://github.com/onlyacat) - TiKV @@ -480,7 +480,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - TiDB Data Migration (DM) - - DM で「イベント タイプ truncate が無効です」というエラーが発生し、アップグレードが失敗する問題を修正します [#10282](https://github.com/pingcap/tiflow/issues/10282) @[GMHDBJD](https://github.com/GMHDBJD) + - DM で「イベントタイプ truncate が無効です」というエラーが発生し、アップグレードが失敗する問題を修正します [#10282](https://github.com/pingcap/tiflow/issues/10282) @[GMHDBJD](https://github.com/GMHDBJD) - GTID モードでデータをレプリケートする際のパフォーマンス低下の問題を修正 [#9676](https://github.com/pingcap/tiflow/issues/9676) @[feran-morgan-pingcap](https://github.com/feran-morgan-pingcap) - 下流テーブル構造に`shard_row_id_bits`が含まれている場合にマイグレーションタスクエラーが発生する問題を修正 [#10308](https://github.com/pingcap/tiflow/issues/10308) @[GMHDBJD](https://github.com/GMHDBJD) diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 5c38088365439..d9750d180db3a 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -58,11 +58,11 @@ TiDB バージョン: 8.0.0 詳細については、 [ドキュメント](/tiflash/tiflash-supported-pushdown-calculations.md)を参照してください。 -- TiDB の並列 HashAgg アルゴリズムはディスク スピルをサポートします (実験的) [#35637](https://github.com/pingcap/tidb/issues/35637) @[xzhangxian1008](https://github.com/xzhangxian1008) +- TiDB の並列 HashAgg アルゴリズムはディスクスピルをサポートします (実験的) [#35637](https://github.com/pingcap/tidb/issues/35637) @[xzhangxian1008](https://github.com/xzhangxian1008) TiDBの以前のバージョンでは、HashAgg演算子の並行処理アルゴリズムはディスクスピルをサポートしていませんでした。SQL文の実行計画に並列HashAgg演算子が含まれている場合、そのSQL文のすべてのデータはメモリ内でしか処理できません。そのため、TiDBは大量のデータをメモリ内で処理する必要があります。データサイズがメモリ制限を超えると、TiDBは並列処理を行わないアルゴリズムしか選択できず、パフォーマンス向上のための並行処理を活用できません。 - バージョン 8.0.0 では、TiDB の並列 HashAgg アルゴリズムがディスク スピルをサポートしています。並列処理のあらゆる状況において、HashAgg オペレータはメモリ使用量に基づいてデータ スピルを自動的にトリガーし、パフォーマンスとデータ スループットのバランスを取ることができます。現在、実験的機能として、TiDB はディスク スピルをサポートする並列 HashAgg アルゴリズムを有効にするかどうかを制御する`tidb_enable_parallel_hashagg_spill`変数を導入しています。この変数が`ON`の場合、有効になっていることを意味します。この機能が将来のリリースで一般提供されるようになった後、この変数は非推奨となります。 + バージョン 8.0.0 では、TiDB の並列 HashAgg アルゴリズムがディスクスピルをサポートしています。並列処理のあらゆる状況において、HashAgg オペレータはメモリ使用量に基づいてデータスピルを自動的にトリガーし、パフォーマンスとデータ スループットのバランスを取ることができます。現在、実験的機能として、TiDB はディスクスピルをサポートする並列 HashAgg アルゴリズムを有効にするかどうかを制御する`tidb_enable_parallel_hashagg_spill`変数を導入しています。この変数が`ON`の場合、有効になっていることを意味します。この機能が将来のリリースで一般提供されるようになった後、この変数は非推奨となります。 詳細については、 [ドキュメント](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)を参照してください。 @@ -87,7 +87,7 @@ TiDB バージョン: 8.0.0 - オプティマイザーが多値インデックスのサポートを強化[#47759](https://github.com/pingcap/tidb/issues/47759) [#46539](https://github.com/pingcap/tidb/issues/46539) @[Arenatlx](https://github.com/Arenatlx)@[time-and-fate](https://github.com/time-and-fate) - TiDB v6.6.0 では[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)が導入され、JSON データ型のクエリ パフォーマンスが向上しました。v8.0.0 では、オプティマイザが多値インデックスのサポートを強化し、複雑なシナリオでクエリを最適化するために、それらを正しく識別して利用できるようになりました。 + TiDB v6.6.0 では[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)が導入され、JSON データ型のクエリパフォーマンスが向上しました。v8.0.0 では、オプティマイザが多値インデックスのサポートを強化し、複雑なシナリオでクエリを最適化するために、それらを正しく識別して利用できるようになりました。 - オプティマイザは、多値インデックスに関する統計情報を収集し、その統計情報に基づいて実行計画を決定します。SQL文で複数の多値インデックスを選択できる場合、オプティマイザはコストが最も低いインデックスを特定できます。 - `OR`を使用して複数の`member of`条件を接続する場合、オプティマイザは各 DNF 項目 ( `member of`条件) に対して有効なインデックス部分パスを照合し、これらのパスを Union を使用して結合して`Index Merge`を形成できます。これにより、条件フィルタリングとデータ取得の効率が向上します。 @@ -224,7 +224,7 @@ TiDB バージョン: 8.0.0 - `IMPORT INTO ... FROM SELECT`の機能を拡張するために`IMPORT INTO`構文をサポートします (実験的) [#49883](https://github.com/pingcap/tidb/issues/49883) @[D3Hunter](https://github.com/D3Hunter) - 以前の TiDB バージョンでは、クエリ結果をターゲット テーブルにインポートするには`INSERT INTO ... SELECT`ステートメントを使用するしかなく、大規模なデータセットのシナリオでは効率が悪かった。v8.0.0 以降では、TiDB で`IMPORT INTO ... FROM SELECT`を使用して`SELECT`クエリの結果を空の TiDB ターゲット テーブルにインポートできるようになり、 `INSERT INTO ... SELECT`の最大 8 倍のパフォーマンスを実現し、インポート時間を大幅に短縮できる。 + 以前の TiDB バージョンでは、クエリ結果をターゲットテーブルにインポートするには`INSERT INTO ... SELECT`ステートメントを使用するしかなく、大規模なデータセットのシナリオでは効率が悪かった。v8.0.0 以降では、TiDB で`IMPORT INTO ... FROM SELECT`を使用して`SELECT`クエリの結果を空の TiDB ターゲットテーブルにインポートできるようになり、 `INSERT INTO ... SELECT`の最大 8 倍のパフォーマンスを実現し、インポート時間を大幅に短縮できる。 さらに、 `IMPORT INTO ... FROM SELECT`を使用して、 [`AS OF TIMESTAMP`](/as-of-timestamp.md)でクエリされた履歴データをインポートできます。 @@ -232,7 +232,7 @@ TiDB バージョン: 8.0.0 - TiDB Lightning は競合解決戦略を簡素化し、 `replace`戦略を使用した競合データの処理をサポートします (実験的) [#51036](https://github.com/pingcap/tidb/issues/51036) @[lyzx2001](https://github.com/lyzx2001) - 以前のバージョンでは、 TiDB Lightning には論理インポート モード用の[データ競合解決戦略](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#conflict-detection)と物理インポート モード用の[2つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)ありましたが、これらは理解して設定するのが簡単ではありませんでした。 + 以前のバージョンでは、 TiDB Lightning には論理インポートモード用の[データ競合解決戦略](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#conflict-detection)と物理インポートモード用の[2つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)ありましたが、これらは理解して設定するのが簡単ではありませんでした。 バージョン 8.0.0 以降、 TiDB Lightning は[旧バージョンの競合検出](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)物理インポートモードの戦略を非推奨とし、 [`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md)パラメータを使用して論理インポートモードと物理インポートモードの両方の競合検出戦略を制御できるようにし、このパラメータの設定を簡素化しました。さらに、物理インポートモードでは、 `replace`戦略が、インポート時に主キーまたは一意キーの競合があるデータが検出された場合、最新のデータを保持して古いデータを上書きすることをサポートするようになりました。 @@ -242,7 +242,7 @@ TiDB バージョン: 8.0.0 バージョン7.4.0より前では、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を使用して`IMPORT INTO`タスクを実行すると、ローカルストレージ容量が限られているため、TiDBはデータの一部をローカルでソートしてからTiKVにインポートしていました。このため、TiKVにインポートされたデータにかなりの重複が生じ、インポート中にTiKVが追加の圧縮操作を実行する必要が生じ、TiKVのパフォーマンスと安定性に影響が出ていました。 - v7.4.0 で導入された実験的機能であるグローバル ソートを使用すると、TiDB はインポートするデータを TiKV にインポートする前に、グローバル ソートのために一時的に外部ストレージ(Amazon S3 など) に保存できます。これにより、インポート中の TiKV 圧縮操作が不要になります。v8.0.0 では、グローバル ソートが GA になります。この機能により、TiKV のリソース消費が削減され、 `IMPORT INTO`のパフォーマンスと安定性が大幅に向上します。グローバル ソートを有効にすると、各`IMPORT INTO`タスクは 40 TiB 以内のデータのインポートをサポートします。 + v7.4.0 で導入された実験的機能であるグローバルソートを使用すると、TiDB はインポートするデータを TiKV にインポートする前に、グローバルソートのために一時的に外部ストレージ(Amazon S3 など) に保存できます。これにより、インポート中の TiKV 圧縮操作が不要になります。v8.0.0 では、グローバルソートが GA になります。この機能により、TiKV のリソース消費が削減され、 `IMPORT INTO`のパフォーマンスと安定性が大幅に向上します。グローバルソートを有効にすると、各`IMPORT INTO`タスクは 40 TiB 以内のデータのインポートをサポートします。 詳細については、[ドキュメント](/tidb-global-sort.md)を参照してください。 @@ -260,7 +260,7 @@ TiDB バージョン: 8.0.0 - セキュリティ強化モード（SEM）で[`require_secure_transport`](/system-variables.md#require_secure_transport-new-in-v610) `ON`に設定することを禁止し、ユーザーの接続に関する潜在的な問題を防止します。 [#47665](https://github.com/pingcap/tidb/issues/47665) @[tiancaiamao](https://github.com/tiancaiamao) - DM では、暗号化および復号化用の固定秘密キーが削除され、暗号化および復号化用の秘密キーをカスタマイズできるようになります。アップグレード前に[データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの設定](/dm/task-configuration-file-full.md)で暗号化されたパスワードが使用されている場合、追加の操作については[DMの暗号化と復号化のための秘密鍵をカスタマイズする](/dm/dm-customized-secret-key.md)のアップグレード手順を参照する必要があります。 [#9492](https://github.com/pingcap/tiflow/issues/9492) @[D3Hunter](https://github.com/D3Hunter) -- v8.0.0 より前では、 `ADD INDEX`および`CREATE INDEX` ( `tidb_ddl_enable_fast_reorg = ON` ) の高速化を有効にした後、エンコードされたインデックス キーは、下流の TiKV 容量に応じて動的に調整できない固定の同時実行数`16`で TiKV にデータを取り込みます。v8.0.0 以降では、 [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)システム変数を使用して同時実行数を調整できます。デフォルト値は`4`です。以前のデフォルト値`16`と比較すると、新しいデフォルト値では、インデックス付きキーと値のペアを取り込むときのパフォーマンスが低下します。このシステム変数は、クラスターのワークロードに基づいて調整できます。 +- v8.0.0 より前では、 `ADD INDEX`および`CREATE INDEX` ( `tidb_ddl_enable_fast_reorg = ON` ) の高速化を有効にした後、エンコードされたインデックスキーは、下流の TiKV 容量に応じて動的に調整できない固定の同時実行数`16`で TiKV にデータを取り込みます。v8.0.0 以降では、 [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)システム変数を使用して同時実行数を調整できます。デフォルト値は`4`です。以前のデフォルト値`16`と比較すると、新しいデフォルト値では、インデックス付きキーと値のペアを取り込むときのパフォーマンスが低下します。このシステム変数は、クラスターのワークロードに基づいて調整できます。 ### MySQLとの互換性 {#mysql-compatibility} @@ -273,7 +273,7 @@ TiDB バージョン: 8.0.0 | [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) | 非推奨 | バージョン8.0.0以降、このシステム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。[悲観的トランザクションモード](/pessimistic-transaction.md)の使用をお勧めします。楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行できます。 | | `tidb_ddl_version` | 名称変更 | TiDB DDL V2 を有効にするかどうかを制御します。バージョン 8.0.0 以降、この変数は目的をより明確にするために[`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)に名称変更されました。 | | [`tidb_enable_collect_execution_info`](/system-variables.md#tidb_enable_collect_execution_info) | 変更 | [インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかのコントロールを追加します。デフォルト値は`ON`です。 | -| [`tidb_redact_log`](/system-variables.md#tidb_redact_log) | 変更 | TiDB ログおよびスロー ログを記録する際に、SAL テキスト内のユーザー情報をどのように処理するかを制御します。値のオプションは`OFF` (ログ内のユーザー情報を処理しないことを示す) と`ON` (ログ内のユーザー情報を非表示にすることを示す) です。ログ内のユーザー情報をより詳細に処理できるように、v8.0.0 ではログ情報をマークするための`MARKER`オプションが追加されました。 | +| [`tidb_redact_log`](/system-variables.md#tidb_redact_log) | 変更 | TiDB ログおよびスローログを記録する際に、SAL テキスト内のユーザー情報をどのように処理するかを制御します。値のオプションは`OFF` (ログ内のユーザー情報を処理しないことを示す) と`ON` (ログ内のユーザー情報を非表示にすることを示す) です。ログ内のユーザー情報をより詳細に処理できるように、v8.0.0 ではログ情報をマークするための`MARKER`オプションが追加されました。 | | [`div_precision_increment`](/system-variables.md#div_precision_increment-new-in-v800) | 新しく追加された | `/` 演算子を使用した除算の結果桁数を増やすかどうかを制御します。この変数はMySQLと同じです。 | | [`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800) | 新しく追加された | DML ステートメントの実行モードを制御します。値のオプションは`"standard"`と`"bulk"`です。 | | [`tidb_enable_auto_analyze_priority_queue`](/system-variables.md#tidb_enable_auto_analyze_priority_queue-new-in-v800) | 新しく追加された | 統計情報の自動収集タスクをスケジュールするための優先度キューを有効にするかどうかを制御します。この変数を有効にすると、TiDB は統計情報を最も必要とするテーブルの統計情報の収集を優先します。 | @@ -295,7 +295,7 @@ TiDB バージョン: 8.0.0 | TiDB | [`log.general-log-file`](/tidb-configuration-file.md#general-log-file-new-in-v800) | 新しく追加された | 一般ログを保存するファイルを指定します。デフォルト値はnullで、これは一般ログがインスタンスファイルに書き込まれることを意味します。 | | TiDB | [`tikv-client.enable-replica-selector-v2`](/tidb-configuration-file.md#enable-replica-selector-v2-new-in-v800) | 新しく追加された | TiKV に RPC リクエストを送信する際に、リージョンレプリカセレクターの新しいバージョンを使用するかどうかを制御します。デフォルト値は`true`です。 | | TiKV | [`log-backup.initial-scan-rate-limit`](/tikv-configuration-file.md#initial-scan-rate-limit-new-in-v620) | 変更 | 最小値として`1MiB`の制限を追加します。 | -| TiKV | [`raftstore.store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530) | 変更 | TiKV のパフォーマンスを向上させるため、デフォルト値を`0`から`1`に変更します。つまり、StoreWriter スレッド プールのサイズはデフォルトで`1`になります。 | +| TiKV | [`raftstore.store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530) | 変更 | TiKV のパフォーマンスを向上させるため、デフォルト値を`0`から`1`に変更します。つまり、StoreWriter スレッドプールのサイズはデフォルトで`1`になります。 | | TiKV | [`rocksdb.defaultcf.titan.blob-cache-size`](/tikv-configuration-file.md#blob-cache-size) | 変更 | バージョン8.0.0以降、TiKVは`shared-blob-cache`設定項目を導入し、デフォルトで有効にしているため、 `blob-cache-size`を別途設定する必要はありません。 `blob-cache-size`の設定は、 `shared-blob-cache`が`false`に設定されている場合にのみ有効になります。 | | TiKV | [`rocksdb.titan.max-background-gc`](/tikv-configuration-file.md#max-background-gc) | 変更 | Titan GC プロセスによるスレッド リソースの占有を減らすため、デフォルト値を`4`から`1`に変更します。 | | TiKV | [`security.encryption.master-key.vendor`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 変更 | サービスプロバイダで使用可能なタイプとして`gcp`を追加します。 | @@ -420,7 +420,7 @@ TiDB バージョン: 8.0.0 - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正 [#50067](https://github.com/pingcap/tidb/issues/50067) @[hawkingrei](https://github.com/hawkingrei) - `BIT`型の列が一部の関数の計算に関与している場合、デコードエラーによりクエリエラーが発生する可能性がある問題を修正しました。 [#49566](https://github.com/pingcap/tidb/issues/49566) [#50850](https://github.com/pingcap/tidb/issues/50850) [#50855](https://github.com/pingcap/tidb/issues/50855) @[jiyfhust](https://github.com/jiyfhust) - PDとの相互作用の問題により、 `tiup cluster upgrade/start`を使用してローリングアップグレードを実行するとTiDBがpanicする可能性がある問題を修正しました [#50152](https://github.com/pingcap/tidb/issues/50152) @[zimulala](https://github.com/zimulala) - - `UNIQUE`句を使用して`ORDER BY`インデックス ルックアップを実行するとエラーが発生する可能性がある問題を修正 [#49920](https://github.com/pingcap/tidb/issues/49920) @[jackysp](https://github.com/jackysp) + - `UNIQUE`句を使用して`ORDER BY`インデックスルックアップを実行するとエラーが発生する可能性がある問題を修正 [#49920](https://github.com/pingcap/tidb/issues/49920) @[jackysp](https://github.com/jackysp) - TiDBが`ENUM`または`SET`型を定数伝播で処理する際に誤ったクエリ結果を返す問題を修正 [#49440](https://github.com/pingcap/tidb/issues/49440) @[winoros](https://github.com/winoros) - クエリに Apply 演算子が含まれている場合に TiDB がpanicを起こし、 `fatal error: concurrent map writes`エラーが発生する問題を修正しました [#50347](https://github.com/pingcap/tidb/issues/50347) @[SeaRise](https://github.com/SeaRise) - 文字列型の変数に対する`SET_VAR`の制御が無効になる可能性がある問題を修正しました [#50507](https://github.com/pingcap/tidb/issues/50507) @[qw4990](https://github.com/qw4990) @@ -432,7 +432,7 @@ TiDB バージョン: 8.0.0 - `tidb_stats_load_sync_wait`が有効にならない問題を修正 [#50872](https://github.com/pingcap/tidb/issues/50872) @[jiyfhust](https://github.com/jiyfhust) - `max_execute_time`設定が複数のレベルで互いに干渉する問題を修正 [#50914](https://github.com/pingcap/tidb/issues/50914) @[jiyfhust](https://github.com/jiyfhust) - 統計情報の同時更新によって発生するスレッドセーフティの問題を修正 [#50835](https://github.com/pingcap/tidb/issues/50835) @[Rustin170506](https://github.com/Rustin170506) - - パーティション テーブルで`auto analyze`を実行すると TiDB がpanicを引き起こす可能性がある問題を修正 [#51187](https://github.com/pingcap/tidb/issues/51187) @[Rustin170506](https://github.com/Rustin170506) + - パーティションテーブルで`auto analyze`を実行すると TiDB がpanicを引き起こす可能性がある問題を修正 [#51187](https://github.com/pingcap/tidb/issues/51187) @[Rustin170506](https://github.com/Rustin170506) - SQL文中の`IN()`に異なる数の値が含まれている場合、SQLバインディングが機能しない可能性がある問題を修正しました [#51222](https://github.com/pingcap/tidb/issues/51222) @[hawkingrei](https://github.com/hawkingrei) - TiDB が式内のシステム変数の型を正しく変換できない問題を修正 [#43527](https://github.com/pingcap/tidb/issues/43527) @[Rustin170506](https://github.com/Rustin170506) - `force-init-stats`が設定されている場合に TiDB が対応するポートをリッスンしない問題を修正 [#51473](https://github.com/pingcap/tidb/issues/51473) @[hawkingrei](https://github.com/hawkingrei) @@ -455,7 +455,7 @@ TiDB バージョン: 8.0.0 - `CAST(AS DATETIME)`が特定の状況下で時間精度を失う可能性がある問題を修正 [#49555](https://github.com/pingcap/tidb/issues/49555) @[SeaRise](https://github.com/SeaRise) - テーブルにクラスター化インデックスがある場合、並列処理`Apply`が誤った結果を生成する可能性がある問題を修正 [#51372](https://github.com/pingcap/tidb/issues/51372) @[guo-shaoge](https://github.com/guo-shaoge) - `ALTER TABLE ... COMPACT TIFLASH REPLICA`が主キーの型が`VARCHAR`の場合に正しく終了しない可能性がある問題を修正 [#51810](https://github.com/pingcap/tidb/issues/51810) @[breezewish](https://github.com/breezewish) - - `NULL`ステートメントを使用してパーティション テーブルを交換する際に`DEFAULT NULL`属性の`EXCHANGE PARTITION`値のチェックが正しく行われない問題を修正しました。 [#47167](https://github.com/pingcap/tidb/issues/47167) @[jiyfhust](https://github.com/jiyfhust) + - `NULL`ステートメントを使用してパーティションテーブルを交換する際に`DEFAULT NULL`属性の`EXCHANGE PARTITION`値のチェックが正しく行われない問題を修正しました。 [#47167](https://github.com/pingcap/tidb/issues/47167) @[jiyfhust](https://github.com/jiyfhust) - パーティションテーブルの定義が、UTF8以外の文字セットを使用した場合に誤った動作を引き起こす可能性がある問題を修正しました [#49251](https://github.com/pingcap/tidb/issues/49251) @[YangKeao](https://github.com/YangKeao) - 一部のシステム変数について、 `INFORMATION_SCHEMA.VARIABLES_INFO`テーブルに誤ったデフォルト値が表示される問題を修正しました [#49461](https://github.com/pingcap/tidb/issues/49461) @[jiyfhust](https://github.com/jiyfhust) - データベース名に空の文字列を使用した場合にエラーが報告されない場合がある問題を修正 [#45873](https://github.com/pingcap/tidb/issues/45873) @[yoshikipom](https://github.com/yoshikipom) @@ -518,9 +518,9 @@ TiDB バージョン: 8.0.0 - 同じノード上の TiKV IP アドレスを変更した後にログのバックアップが停止する問題を修正 [#50445](https://github.com/pingcap/tidb/issues/50445) @[3pointer](https://github.com/3pointer) - S3からファイルコンテンツを読み取る際にエラーが発生した場合にBRが再試行できない問題を修正 [#49942](https://github.com/pingcap/tidb/issues/49942) @[Leavrth](https://github.com/Leavrth) - データ復元失敗後にチェックポイントから再開するとエラー`the target cluster is not fresh`発生する問題を修正 [#50232](https://github.com/pingcap/tidb/issues/50232) @[Leavrth](https://github.com/Leavrth) - - ログ バックアップ タスクを停止すると TiDB がクラッシュする問題を修正 [#50839](https://github.com/pingcap/tidb/issues/50839) @[YuJuncen](https://github.com/YuJuncen) + - ログバックアップタスクを停止すると TiDB がクラッシュする問題を修正 [#50839](https://github.com/pingcap/tidb/issues/50839) @[YuJuncen](https://github.com/YuJuncen) - TiKVノードにリーダーがいないためにデータ復元が遅くなる問題を修正 [#50566](https://github.com/pingcap/tidb/issues/50566) @[Leavrth](https://github.com/Leavrth) - - `--filter`オプションを指定した後でも完全復元ではターゲット クラスターが空である必要がある問題を修正 [#51009](https://github.com/pingcap/tidb/issues/51009) @[3pointer](https://github.com/3pointer) + - `--filter`オプションを指定した後でも完全復元ではターゲットクラスターが空である必要がある問題を修正 [#51009](https://github.com/pingcap/tidb/issues/51009) @[3pointer](https://github.com/3pointer) - TiCDC diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 8e7040de37236..8ab1359112581 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -17,7 +17,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 以前のLTSバージョン7.5.0と比較して、8.1.0にはバージョン[7.6.0-DMR](/releases/release-7.6.0.md)と[8.0.0-DMR](/releases/release-8.0.0.md)でリリースされた新機能、改善、バグ修正が含まれています。7.5.xから8.1.0にアップグレードする場合は、バージョン[TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.6-to-v8.1-en-release-notes.pdf)をダウンロードして、2つのLTSバージョン間のすべてのリリースノートをご覧いただけます。以下の表は、7.6.0から8.1.0への主な変更点です。 -
    カテゴリ機能/拡張機能説明
    スケーラビリティとパフォーマンスクラスター スナップショットの復元速度の高速化(v8.0.0 で GA)この機能により、 BRはクラスタのスケールメリットを最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスタにおける大規模データセットの復元速度が大幅に向上します。実環境テストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
    バッチでテーブルを作成する場合、最大 10 倍の高速化を実現します(実験的、v7.6.0 で導入) v7.6.0での新しいDDLアーキテクチャの実装により、バッチテーブル作成のパフォーマンスが大幅に向上し、最大10倍高速化しました。この大幅な機能強化により、多数のテーブル作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが頻繁に使用されるSaaSシナリオにおいて特に顕著です。
    アクティブ PD フォロワーを使用して、PD のリージョン情報クエリ サービスを強化します(実験的、v7.6.0 で導入) TiDB v7.6.0では、PDフォロワーがリージョン情報クエリサービスを提供できる実験的機能「Active PD Follower 」が導入されました。この機能により、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターのGetRegionおよびScanRegionsリクエスト処理能力が向上し、PDリーダーのCPU負荷が軽減されます。
    大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入)大規模なクリーンアップジョブ、結合、集計といった大規模なバッチDMLジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模なスケールでは制限されていました。バルクDML（ tidb_dml_type = "bulk" ）は、トランザクション保証を提供し、OOM（メモリ不足）の問題を軽減しながら、大規模なバッチDMLタスクをより効率的に処理するための新しいDMLタイプです。この機能は、データのロードに使用する場合、インポート、ロード、リストアの各操作とは異なります。
    膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入)マルチテナントアプリケーションの記録システムとしてTiDBを使用しているSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブル数を処理することは可能でしたが、全体的なユーザーエクスペリエンスが低下する可能性がありました。TiDB v8.0.0では、 auto analyzeに優先キューを実装することで状況が改善され、プロセスの柔軟性が向上し、より広範なテーブルにわたる安定性が向上しました。
    信頼性と可用性グローバルソート（v8.0.0 で GA）グローバルソート機能は、 IMPORT INTOおよびCREATE INDEXの安定性と効率性を向上させることを目的としています。処理対象のデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上し、結果としてデータのインポートとインデックス作成におけるユーザーエクスペリエンスとサービス品質が向上します。グローバルソートを有効にすると、各IMPORT INTOまたはCREATE INDEXステートメントで、最大40TiBのデータのインポートまたはインデックスの追加がサポートされるようになりました。
    データベース間 SQL バインディング(v7.6.0 で導入)同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体にSQLバインディングを適用する必要があることがよくあります。例えば、SaaSまたはPaaSデータプラットフォームでは、各ユーザーは通常、同じスキーマを持つ別々のデータベースを操作し、それらに対して類似のSQLクエリを実行します。このような場合、各データベースにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等なすべてのデータベース間で一致するバインディングを可能にする、データベース間SQLバインディングが導入されています。
    TiProxy をサポート(v8.0.0 で GA)デプロイメント ツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング リスタート、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持できるようにします。
    データ移行（DM）はMySQL 8.0（バージョン7.6.0でGA）を正式にサポートしますこれまで、DMを使用したMySQL 8.0からのデータ移行は実験的機能であり、本番環境ではご利用いただけませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に実行できるようになります。v7.6.0では、この機能が一般提供（GA）されます。
    TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) TiDBは、リソースグループのルールを通じて、予想以上にリソースを消費するクエリを自動的に識別し、それらのクエリを制限またはキャンセルすることができます。ルールで識別されないクエリでも、手動でクエリ特性を追加し、適切な対策を講じることで、突発的なクエリパフォーマンスの問題がデータベース全体に与える影響を軽減できます。
    DB操作と可観測性インデックス使用状況統計の監視をサポート（v8.0.0 で導入）適切なインデックス設計は、データベースのパフォーマンス維持に不可欠な前提条件です。TiDB v8.0.0では、インデックスの使用状況統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
    データ移行TiCDC はSimpleプロトコルをサポートしています (v8.0.0 で導入) TiCDCは、新しいプロトコル「Simpleプロトコル」を導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、スキーマをインバンドで追跡する機能を提供します。
    TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 TiCDC は新しいプロトコル、Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクにパブリッシュできるようになりました。
    TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) TiCDCは、相互トランスポート層Security（mTLS）またはTiDBユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLIまたはOpenAPIクライアントはTiCDCへの接続を認証できます。
    +
    カテゴリ機能/拡張機能説明
    スケーラビリティとパフォーマンスクラスター スナップショットの復元速度の高速化(v8.0.0 で GA)この機能により、 BRはクラスタのスケールメリットを最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスタにおける大規模データセットの復元速度が大幅に向上します。実環境テストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
    バッチでテーブルを作成する場合、最大 10 倍の高速化を実現します(実験的、v7.6.0 で導入) v7.6.0での新しいDDLアーキテクチャの実装により、バッチテーブル作成のパフォーマンスが大幅に向上し、最大10倍高速化しました。この大幅な機能強化により、多数のテーブル作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが頻繁に使用されるSaaSシナリオにおいて特に顕著です。
    アクティブ PD フォロワーを使用して、PD のリージョン情報クエリサービスを強化します(実験的、v7.6.0 で導入) TiDB v7.6.0では、PDフォロワーがリージョン情報クエリサービスを提供できる実験的機能「Active PD Follower 」が導入されました。この機能により、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターのGetRegionおよびScanRegionsリクエスト処理能力が向上し、PDリーダーのCPU負荷が軽減されます。
    大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入)大規模なクリーンアップジョブ、結合、集計といった大規模なバッチDMLジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模なスケールでは制限されていました。バルクDML（ tidb_dml_type = "bulk" ）は、トランザクション保証を提供し、OOM（メモリ不足）の問題を軽減しながら、大規模なバッチDMLタスクをより効率的に処理するための新しいDMLタイプです。この機能は、データのロードに使用する場合、インポート、ロード、リストアの各操作とは異なります。
    膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入)マルチテナントアプリケーションの記録システムとしてTiDBを使用しているSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブル数を処理することは可能でしたが、全体的なユーザーエクスペリエンスが低下する可能性がありました。TiDB v8.0.0では、 auto analyzeに優先キューを実装することで状況が改善され、プロセスの柔軟性が向上し、より広範なテーブルにわたる安定性が向上しました。
    信頼性と可用性グローバルソート（v8.0.0 で GA）グローバルソート機能は、 IMPORT INTOおよびCREATE INDEXの安定性と効率性を向上させることを目的としています。処理対象のデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上し、結果としてデータのインポートとインデックス作成におけるユーザーエクスペリエンスとサービス品質が向上します。グローバルソートを有効にすると、各IMPORT INTOまたはCREATE INDEXステートメントで、最大40TiBのデータのインポートまたはインデックスの追加がサポートされるようになりました。
    データベース間 SQL バインディング(v7.6.0 で導入)同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体にSQLバインディングを適用する必要があることがよくあります。例えば、SaaSまたはPaaSデータプラットフォームでは、各ユーザーは通常、同じスキーマを持つ別々のデータベースを操作し、それらに対して類似のSQLクエリを実行します。このような場合、各データベースにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等なすべてのデータベース間で一致するバインディングを可能にする、データベース間SQLバインディングが導入されています。
    TiProxy をサポート(v8.0.0 で GA)デプロイメントツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング リスタート、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持できるようにします。
    データ移行（DM）はMySQL 8.0（バージョン7.6.0でGA）を正式にサポートしますこれまで、DMを使用したMySQL 8.0からのデータ移行は実験的機能であり、本番環境ではご利用いただけませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に実行できるようになります。v7.6.0では、この機能が一般提供（GA）されます。
    TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) TiDBは、リソースグループのルールを通じて、予想以上にリソースを消費するクエリを自動的に識別し、それらのクエリを制限またはキャンセルすることができます。ルールで識別されないクエリでも、手動でクエリ特性を追加し、適切な対策を講じることで、突発的なクエリパフォーマンスの問題がデータベース全体に与える影響を軽減できます。
    DB操作と可観測性インデックス使用状況統計の監視をサポート（v8.0.0 で導入）適切なインデックス設計は、データベースのパフォーマンス維持に不可欠な前提条件です。TiDB v8.0.0では、インデックスの使用状況統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
    データ移行TiCDC はSimpleプロトコルをサポートしています (v8.0.0 で導入) TiCDCは、新しいプロトコル「Simpleプロトコル」を導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、スキーマをインバンドで追跡する機能を提供します。
    TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 TiCDC は新しいプロトコル、Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクにパブリッシュできるようになりました。
    TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) TiCDCは、相互トランスポート層Security（mTLS）またはTiDBユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLIまたはOpenAPIクライアントはTiCDCへの接続を認証できます。
    ## 機能の詳細 {#feature-details} @@ -75,7 +75,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - TiDB Lightningは競合解決戦略を簡素化し、 `replace`戦略（GA） を使用して競合するデータの処理をサポートします。 [＃51036](https://github.com/pingcap/tidb/issues/51036) @[lyzx2001](https://github.com/lyzx2001) - v8.0.0 より前のTiDB Lightningには、論理インポート モードが[1つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#conflict-detection) 、物理インポート モードが[2つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)があり、理解して構成するのは簡単ではありません。 + v8.0.0 より前のTiDB Lightningには、論理インポートモードが[1つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md#conflict-detection) 、物理インポートモードが[2つのデータ競合解決戦略](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)があり、理解して構成するのは簡単ではありません。 TiDB Lightning v8.0.0では、物理インポートモードにおける[競合検出の古いバージョン](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)戦略が廃止され、 [`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md)パラメータ（実験的）を介して論理インポートモードと物理インポートモードの両方で競合検出戦略を制御できるようになり、このパラメータの設定が簡素化されました。さらに、物理インポートモードでは、 `replace`戦略により、インポート時に主キーまたは一意キーの競合が検出された場合に、最新のデータを保持し、古いデータを上書きすることがサポートされます。v8.1.0では、 `replace`戦略で競合データを処理する機能が一般提供（GA）されます。 @@ -148,14 +148,14 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - 取り込みモードで複数のインデックスを同時に追加できるようになりました [＃52596](https://github.com/pingcap/tidb/issues/52596) @[lance6716](https://github.com/lance6716) - システム変数`tidb_service_scope`さまざまな値で構成することをサポートし、分散実行フレームワーク（DXF） の利用率を高めます。 [＃52441](https://github.com/pingcap/tidb/issues/52441) @[ywqzzy](https://github.com/ywqzzy) - 常に`false`である DNF 項目の処理を強化し、そのようなフィルタ条件を直接無視することで、不要なテーブル全体のスキャンを回避します[＃40997](https://github.com/pingcap/tidb/issues/40997) @[Rustin170506](https://github.com/Rustin170506) - - オプティマイザがクエリに対して単一インデックス スキャン方式 (フル テーブル スキャン以外) を選択できる場合、オプティマイザがクエリに対してインデックス マージを自動的に選択しないという制限を削除するために、オプティマイザ修正コントロールの使用をサポートします。 [＃52869](https://github.com/pingcap/tidb/issues/52869) @[time-and-fate](https://github.com/time-and-fate) + - オプティマイザがクエリに対して単一インデックススキャン方式 (フルテーブルスキャン以外) を選択できる場合、オプティマイザがクエリに対してインデックスマージを自動的に選択しないという制限を削除するために、オプティマイザ修正コントロールの使用をサポートします。 [＃52869](https://github.com/pingcap/tidb/issues/52869) @[time-and-fate](https://github.com/time-and-fate) - コプロセッサー演算子の列`execution info`に`total_kv_read_wall_time`メトリックを追加します。 [＃28937](https://github.com/pingcap/tidb/issues/28937) @[cfzjywxk](https://github.com/cfzjywxk) - リソースコントロールダッシュボードに`RU (max)`メトリックを追加する[＃49318](https://github.com/pingcap/tidb/issues/49318) @[nolouch](https://github.com/nolouch) - リソースロック（RLock）が内に解放されない問題を回避するために、LDAP認証にタイムアウトメカニズムを追加します@[YangKeao](https://github.com/YangKeao) [＃51883](https://github.com/pingcap/tidb/issues/51883) - TiKV - - TiKV の安定性を向上させるために、 Raftstoreスレッドでスナップショット ファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) + - TiKV の安定性を向上させるために、 Raftstoreスレッドでスナップショットファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @[Connor1996](https://github.com/Connor1996) - TiKV のシャットダウン速度を加速 [＃16680](https://github.com/tikv/tikv/issues/16680) @[LykxSassinator](https://github.com/LykxSassinator) - スレッドごとのメモリ使用量のメトリックを追加します。 [＃15927](https://github.com/tikv/tikv/issues/15927) @[Connor1996](https://github.com/Connor1996) @@ -188,19 +188,19 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - 複数値インデックスを持つテーブルを含むSQL文を実行すると、 `Can't find a proper physical plan for this query`エラーが返される可能性がある問題を修正しました。 [＃49438](https://github.com/pingcap/tidb/issues/49438) @[qw4990](https://github.com/qw4990) - OOMエラー発生後に自動統計収集が停止する問題を修正[＃51993](https://github.com/pingcap/tidb/issues/51993) @[Rustin170506](https://github.com/Rustin170506) - BRを使用して統計情報のないテーブルを復元した後、そのテーブルの統計の健全性が 100% のままになる問題を修正しました。 [＃29769](https://github.com/pingcap/tidb/issues/29769) @[winoros](https://github.com/winoros) - - アップグレード中に TiDB がシステム テーブルの統計を作成する問題を修正しました [＃52040](https://github.com/pingcap/tidb/issues/52040) @[Rustin170506](https://github.com/Rustin170506) + - アップグレード中に TiDB がシステムテーブルの統計を作成する問題を修正しました [＃52040](https://github.com/pingcap/tidb/issues/52040) @[Rustin170506](https://github.com/Rustin170506) - 統計の初期化が完了する前に自動統計収集がトリガーされる問題を修正[＃52346](https://github.com/pingcap/tidb/issues/52346) @[Rustin170506](https://github.com/Rustin170506) - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが制限を超えると TiDB がクラッシュする可能性がある問題を修正しました。 [＃52601](https://github.com/pingcap/tidb/issues/52601) @[hawkingrei](https://github.com/hawkingrei) - TiDBの同期的な統計読み込みメカニズムが空の統計の読み込みを無期限に再試行し、 `fail to get stats version for this histogram` log を出力問題を修正しました。 [＃52657](https://github.com/pingcap/tidb/issues/52657) @[hawkingrei](https://github.com/hawkingrei) - 照合順序の新しいフレームワークが無効になっているときに、異なる照合順序を含む式によってクエリがpanicになる可能性がある問題を修正しました[＃52772](https://github.com/pingcap/tidb/issues/52772) @[wjhuang2016](https://github.com/wjhuang2016) - `CPS by type`メトリックに誤った値が表示される問題を修正しました [＃52605](https://github.com/pingcap/tidb/issues/52605) @[nolouch](https://github.com/nolouch) - `INFORMATION_SCHEMA.TIKV_REGION_STATUS` をクエリすると nil ポインタエラーが発生する問題を修正しました [＃52013](https://github.com/pingcap/tidb/issues/52013) @[JmPotato](https://github.com/JmPotato) - - 列に無効なデフォルト値が指定されたときに表示される誤ったエラー メッセージを修正しました。 [＃51592](https://github.com/pingcap/tidb/issues/51592) @[danqixu](https://github.com/danqixu) + - 列に無効なデフォルト値が指定されたときに表示される誤ったエラーメッセージを修正しました。 [＃51592](https://github.com/pingcap/tidb/issues/51592) @[danqixu](https://github.com/danqixu) - 取り込みモードでインデックスを追加すると、一部のコーナーケースでデータインデックスの不整合が発生する可能性がある問題を修正[＃51954](https://github.com/pingcap/tidb/issues/51954) @[lance6716](https://github.com/lance6716) - 外部キーを持つテーブルを復元するときに DDL 操作が停止する問題を修正しました [＃51838](https://github.com/pingcap/tidb/issues/51838) @[YangKeao](https://github.com/YangKeao) - TiDBネットワークが分離されているときにインデックスの追加が失敗する問題を修正 [＃51846](https://github.com/pingcap/tidb/issues/51846) @[ywqzzy](https://github.com/ywqzzy) - インデックス名を変更した後に同じ名前のインデックスを追加するとエラーが発生する問題を修正[＃51431](https://github.com/pingcap/tidb/issues/51431) @[lance6716](https://github.com/lance6716) - - インデックス追加中にクラスターのアップグレードによって発生するデータ インデックスの不整合の問題を修正しました。 [＃52411](https://github.com/pingcap/tidb/issues/52411) @[tangenta](https://github.com/tangenta) + - インデックス追加中にクラスターのアップグレードによって発生するデータインデックスの不整合の問題を修正しました。 [＃52411](https://github.com/pingcap/tidb/issues/52411) @[tangenta](https://github.com/tangenta) - 分散実行フレームワーク (DXF) を有効にした後に、大きなテーブルにインデックスを追加できない問題を修正しました。 [＃52640](https://github.com/pingcap/tidb/issues/52640) @[tangenta](https://github.com/tangenta) - インデックスを同時に追加するとエラー`no such file or directory` が報告される問題を修正しました [＃52475](https://github.com/pingcap/tidb/issues/52475) @[tangenta](https://github.com/tangenta) - インデックスの追加が失敗した後に一時データをクリーンアップできない問題を修正[＃52639](https://github.com/pingcap/tidb/issues/52639) @[lance6716](https://github.com/lance6716) @@ -227,7 +227,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - PD - - PD マイクロサービス モードのオン/オフを切り替えるときに TSO が停止する可能性がある問題を修正[＃7849](https://github.com/tikv/pd/issues/7849) @[JmPotato](https://github.com/JmPotato) + - PD マイクロサービスモードのオン/オフを切り替えるときに TSO が停止する可能性がある問題を修正[＃7849](https://github.com/tikv/pd/issues/7849) @[JmPotato](https://github.com/JmPotato) - DR自動同期の`State`監視メトリックにデータが表示されない問題を修正[＃7974](https://github.com/tikv/pd/issues/7974) @[lhy1024](https://github.com/lhy1024) - バイナリバージョンのチェックでPD panicが発生する可能性がある問題を修正 [＃7978](https://github.com/tikv/pd/issues/7978) @[JmPotato](https://github.com/JmPotato) - TTLパラメータを解析する際に発生する型変換エラーを修正[＃7980](https://github.com/tikv/pd/issues/7980) @[HuSharp](https://github.com/HuSharp) @@ -255,9 +255,9 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - BRが`AUTO_RANDOM`列を含むユニオンクラスター化インデックスの`AUTO_RANDOM` ID割り当ての進行状況をバックアップできない問題を修正しました。 [＃52255](https://github.com/pingcap/tidb/issues/52255) @[Leavrth](https://github.com/Leavrth) - ログバックアップタスクを一時停止後に削除しても、GCセーフポイントがすぐに復元されない問題を修正しました。 [＃52082](https://github.com/pingcap/tidb/issues/52082) @[3pointer](https://github.com/3pointer) - 特別なイベントタイミングにより、ログバックアップでデータ損失が発生する可能性があるという稀な問題を修正しました。 [＃16739](https://github.com/tikv/tikv/issues/16739) @[YuJuncen](https://github.com/YuJuncen) - - TiKV の再起動により、ログ バックアップのグローバル チェックポイントが実際のバックアップ ファイルの書き込みポイントよりも先に進められ、少量のバックアップ データが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) + - TiKV の再起動により、ログバックアップのグローバルチェックポイントが実際のバックアップファイルの書き込みポイントよりも先に進められ、少量のバックアップデータが失われる可能性がある問題を修正しました[＃16809](https://github.com/tikv/tikv/issues/16809) @[YuJuncen](https://github.com/YuJuncen) - フルバックアップ中に`--concurrency`に関連する紛らわしい情報がログに表示される問題を修正 [＃50837](https://github.com/pingcap/tidb/issues/50837) @[BornChanger](https://github.com/BornChanger) - - BRを使用してデータを復元する場合、または物理インポート モードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) + - BRを使用してデータを復元する場合、または物理インポートモードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @[Leavrth](https://github.com/Leavrth) - ログバックアップタスクを一時停止、停止、再構築した後、タスクの状態は正常であるが、チェックポイントが進まない問題を修正しました。 [＃53047](https://github.com/pingcap/tidb/issues/53047) @[RidRisR](https://github.com/RidRisR) - 不安定なテストケース`TestClearCache` を修正 [＃51671](https://github.com/pingcap/tidb/issues/51671) @[zxc111](https://github.com/zxc111) - 不安定なテストケース`TestGetMergeRegionSizeAndCount` を修正 [＃52095](https://github.com/pingcap/tidb/issues/52095) @[3pointer](https://github.com/3pointer) diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 4f0195d1e9322..6d469804380ef 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -30,7 +30,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiDB - TiFlash配置ルールを一括削除することで、パーティションテーブルで`TRUNCATE`または`DROP`操作を実行した後のデータGCの処理速度が向上します。 [＃54068](https://github.com/pingcap/tidb/issues/54068) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - MPP ロード バランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) + - MPP ロードバランシング中にリージョンのないストアを削除する [＃52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) - TiKV の高負荷時に広範囲にわたるタイムアウトを回避するために、統計を同期的にロードするタスクの優先度を一時的に高く調整します。タイムアウトにより、統計がロードされない可能性があります[＃50332](https://github.com/pingcap/tidb/issues/50332) @[winoros](https://github.com/winoros) - `EXPLAIN`ステートメントは`tidb_redact_log`設定の適用をサポートし、ログ処理ロジックをさらに最適化します。 - `EXPLAIN`ステートメントの出力に`tidb_redact_log`設定を適用し、ログの処理ロジックをさらに最適化することをサポート [＃54565](https://github.com/pingcap/tidb/issues/54565) @[hawkingrei](https://github.com/hawkingrei) @@ -62,7 +62,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiDB - - HashAgg 演算子のディスク スピルにより並列計算中に誤ったクエリ結果が発生する問題を修正しました。 [＃55290](https://github.com/pingcap/tidb/issues/55290) @[xzhangxian1008](https://github.com/xzhangxian1008) + - HashAgg 演算子のディスクスピルにより並列計算中に誤ったクエリ結果が発生する問題を修正しました。 [＃55290](https://github.com/pingcap/tidb/issues/55290) @[xzhangxian1008](https://github.com/xzhangxian1008) - SQLが異常に中断されたときに`INDEX_HASH_JOIN`正常に終了できない問題を修正[＃54688](https://github.com/pingcap/tidb/issues/54688) @[wshwsh12](https://github.com/wshwsh12) - 厳密に自己増分ではないRANGEパーティションテーブルが作成できる問題を修正 [＃54829](https://github.com/pingcap/tidb/issues/54829) @[Defined2014](https://github.com/Defined2014) - `_tidb_rowid`の`PointGet`実行計画が生成できる問題を修正 [＃54583](https://github.com/pingcap/tidb/issues/54583) @[Defined2014](https://github.com/Defined2014) @@ -83,7 +83,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - 自動統計収集中にシステム変数`tidb_enable_async_merge_global_stats`と`tidb_analyze_partition_concurrency`有効にならない問題を修正[＃53972](https://github.com/pingcap/tidb/issues/53972) @[hi-rustin](https://github.com/hi-rustin) - 最初の引数が`month`で、2番目の引数が負の場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 [＃54908](https://github.com/pingcap/tidb/issues/54908) @[xzhangxian1008](https://github.com/xzhangxian1008) - ハンドシェイクが完了する前に一部の接続が終了した場合に、Grafana の接続数監視メトリックが正しくない問題を修正しました[＃54428](https://github.com/pingcap/tidb/issues/54428) @[YangKeao](https://github.com/YangKeao) - - TiProxy とリソース グループを使用するときに、各リソース グループの接続数が正しくない問題を修正しました。 [＃54545](https://github.com/pingcap/tidb/issues/54545) @[YangKeao](https://github.com/YangKeao) + - TiProxy とリソースグループを使用するときに、各リソースグループの接続数が正しくない問題を修正しました。 [＃54545](https://github.com/pingcap/tidb/issues/54545) @[YangKeao](https://github.com/YangKeao) - 再帰CTE でビューの使用が機能しない問題を修正 [＃49721](https://github.com/pingcap/tidb/issues/49721) @[hawkingrei](https://github.com/hawkingrei) - 大規模並列処理 (MPP) で`final` AggMode と`non-final` AggMode が共存できない問題を修正しました [＃51362](https://github.com/pingcap/tidb/issues/51362) @[AilinKid](https://github.com/AilinKid) - オプティマイザーヒント使用時に誤った警告情報が表示される問題を修正しました [＃53767](https://github.com/pingcap/tidb/issues/53767) @[hawkingrei](https://github.com/hawkingrei) @@ -113,7 +113,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - グローバルソートを使用してインデックスを追加するときにパフォーマンスが不安定になる問題を修正しました [＃54147](https://github.com/pingcap/tidb/issues/54147) @[tangenta](https://github.com/tangenta) - v7.1 からアップグレードした後に`SHOW IMPORT JOBS`エラー`Unknown column 'summary'`を報告する問題を修正しました [＃54241](https://github.com/pingcap/tidb/issues/54241) @[tangenta](https://github.com/tangenta) - `root`ユーザーが`tidb_mdl_view` を照会できない問題を修正 [＃53292](https://github.com/pingcap/tidb/issues/53292) @[tangenta](https://github.com/tangenta) - - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワーク パーティションによって、データ インデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @[tangenta](https://github.com/tangenta) + - 分散実行フレームワーク (DXF) を使用してインデックスを追加する際のネットワークパーティションによって、データインデックスの不整合が発生する可能性がある問題を修正しました。 [＃54897](https://github.com/pingcap/tidb/issues/54897) @[tangenta](https://github.com/tangenta) - TiDB Lightning物理インポートモードの初期化中にエラーが発生し、リソースリークが発生する可能性がある問題を修正[＃53659](https://github.com/pingcap/tidb/issues/53659) @[D3Hunter](https://github.com/D3Hunter) - ビュー定義でサブクエリが列定義として使用されている場合、 `information_schema.columns`を使用して列情報を取得すると警告1356が返される問題を修正しました。 [＃54343](https://github.com/pingcap/tidb/issues/54343) @[lance6716](https://github.com/lance6716) - インデックスアクセラレーションを使用して一意インデックスを追加すると、所有者が切り替えられたときに`Duplicate entry`エラーが発生する可能性がある問題を修正しました。 [＃49233](https://github.com/pingcap/tidb/issues/49233) @[lance6716](https://github.com/lance6716) @@ -127,10 +127,10 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - CDC とログバックアップが`advance-ts-interval`構成を使用して`check_leader`のタイムアウトを制限しないため、TiKV が正常に再起動したときに`resolved_ts`遅延が大きくなる場合がある問題を修正しました[＃17107](https://github.com/tikv/tikv/issues/17107) @[MyonKeminta](https://github.com/MyonKeminta) - gRPC メッセージ圧縮方式を`grpc-compression-type`で設定しても、TiKV から TiDB に送信されるメッセージには反映されない問題を修正しました。 [＃17176](https://github.com/tikv/tikv/issues/17176) @[ekexium](https://github.com/ekexium) - `make docker`と`make docker_test`の失敗を修正[＃17075](https://github.com/tikv/tikv/issues/17075) @[shunki-fujita](https://github.com/shunki-fujita) - - **gRPC リクエスト ソースの継続時間**メトリックが監視ダッシュボードに誤って表示される問題を修正しました [＃17133](https://github.com/tikv/tikv/issues/17133) @[King-Dylan](https://github.com/King-Dylan) + - **gRPC リクエストソースの継続時間**メトリックが監視ダッシュボードに誤って表示される問題を修正しました [＃17133](https://github.com/tikv/tikv/issues/17133) @[King-Dylan](https://github.com/King-Dylan) - tikv-ctlの`raft region`コマンドの出力にリージョンステータス情報が含まれていない問題を修正しました [＃17037](https://github.com/tikv/tikv/issues/17037) @[glorv](https://github.com/glorv) - `raftstore.periodic-full-compact-start-times`構成項目をオンラインで変更すると、TiKVがpanicを起こす可能性がある問題を修正しました[＃17066](https://github.com/tikv/tikv/issues/17066) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - - 破損したRaftデータ スナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [＃15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) + - 破損したRaftデータスナップショットを適用すると TiKV が繰り返しpanicする可能性がある問題を修正しました。 [＃15292](https://github.com/tikv/tikv/issues/15292) @[LykxSassinator](https://github.com/LykxSassinator) - キャッシュエントリが永続化される前に解放すると TiKV がpanicを起こす問題を修正しました [＃17040](https://github.com/tikv/tikv/issues/17040) @[glorv](https://github.com/glorv) - PD @@ -141,12 +141,12 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - `Filter`監視メトリックでデータが欠落している問題を修正しました [＃8098](https://github.com/tikv/pd/issues/8098) @[nolouch](https://github.com/nolouch) - TLS が有効になっているときに HTTP クライアントがpanicする可能性がある問題を修正[＃8237](https://github.com/tikv/pd/issues/8237) @[okJiang](https://github.com/okJiang) - 暗号化マネージャーが使用前に初期化されない問題を修正[＃8384](https://github.com/tikv/pd/issues/8384) @[rleungx](https://github.com/rleungx) - - 同時実行性が高い場合にリソース グループがリソース使用量を効果的に制限できない問題を修正[＃8435](https://github.com/tikv/pd/issues/8435) @[nolouch](https://github.com/nolouch) + - 同時実行性が高い場合にリソースグループがリソース使用量を効果的に制限できない問題を修正[＃8435](https://github.com/tikv/pd/issues/8435) @[nolouch](https://github.com/nolouch) - `store limit` に関連するデータ競合問題を修正 [＃8253](https://github.com/tikv/pd/issues/8253) @[lhy1024](https://github.com/lhy1024) - `scheduling`マイクロサービスが有効化された後にスケーリングの進行状況が正しく表示されない問題を修正しました [＃8331](https://github.com/tikv/pd/issues/8331) @[rleungx](https://github.com/rleungx) - `tso`マイクロサービスが有効になった後、TSO ノードが動的に更新されない問題を修正[＃8154](https://github.com/tikv/pd/issues/8154) @[rleungx](https://github.com/rleungx) - リソースグループのデータ競合問題を修正 [＃8267](https://github.com/tikv/pd/issues/8267) @[HuSharp](https://github.com/HuSharp) - - 500 ミリ秒を超えるトークンをリクエストするとリソース グループがクォータ制限に達する問題を修正[＃8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) + - 500 ミリ秒を超えるトークンをリクエストするとリソースグループがクォータ制限に達する問題を修正[＃8349](https://github.com/tikv/pd/issues/8349) @[nolouch](https://github.com/nolouch) - PDリーダーを手動で転送すると失敗する可能性がある問題を修正しました [＃8225](https://github.com/tikv/pd/issues/8225) @[HuSharp](https://github.com/HuSharp) - 削除されたノードがetcdクライアントの候補接続リストにまだ表示される問題を修正 [＃8286](https://github.com/tikv/pd/issues/8286) @[JmPotato](https://github.com/JmPotato) - `ALTER PLACEMENT POLICY`配置ポリシー を変更できない問題を修正 [＃51712](https://github.com/pingcap/tidb/issues/51712) @[jiyfhust](https://github.com/jiyfhust) [＃52257](https://github.com/pingcap/tidb/issues/52257) @@ -166,7 +166,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[＃9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - 分散ストレージおよびコンピューティングアーキテクチャで、DDL操作で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 [＃9084](https://github.com/pingcap/tiflash/issues/9084) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - データベースにまたがる空のパーティションを持つパーティションテーブルで`RENAME TABLE ... TO ...`を実行した後にTiFlash がpanicする可能性がある問題を修正しました。 [＃9132](https://github.com/pingcap/tiflash/issues/9132) @[JaySon-Huang](https://github.com/JaySon-Huang) - - 空のパーティションを含むパーティション テーブルでクエリを実行するときに発生するクエリ タイムアウトの問題を修正しました。 [＃9024](https://github.com/pingcap/tiflash/issues/9024) @[JinheLin](https://github.com/JinheLin) + - 空のパーティションを含むパーティションテーブルでクエリを実行するときに発生するクエリタイムアウトの問題を修正しました。 [＃9024](https://github.com/pingcap/tiflash/issues/9024) @[JinheLin](https://github.com/JinheLin) - 遅延マテリアライゼーションが有効になった後に、一部のクエリで列タイプの不一致エラーが報告される可能性がある問題を修正[＃9175](https://github.com/pingcap/tiflash/issues/9175) @[JinheLin](https://github.com/JinheLin) - 遅延マテリアライゼーションが有効になった後、仮想生成列を含むクエリが誤った結果を返す可能性がある問題を修正[＃9188](https://github.com/pingcap/tiflash/issues/9188) @[JinheLin](https://github.com/JinheLin) @@ -185,7 +185,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiCDC - リージョンの変更によりダウンストリームpanicが発生する問題を修正[＃17233](https://github.com/tikv/tikv/issues/17233) @[hicqu](https://github.com/hicqu) - - アップストリームで新しい照合順序が無効になっている場合、TiCDC がクラスター化インデックス テーブルの主キーを正しくデコードできない問題を修正しました。 [＃11371](https://github.com/pingcap/tiflow/issues/11371) @[lidezhu](https://github.com/lidezhu) + - アップストリームで新しい照合順序が無効になっている場合、TiCDC がクラスター化インデックステーブルの主キーを正しくデコードできない問題を修正しました。 [＃11371](https://github.com/pingcap/tiflow/issues/11371) @[lidezhu](https://github.com/lidezhu) - `UPDATE`イベントを分割した後、チェックサムが正しく`0`に設定されない問題を修正しました。 [＃11402](https://github.com/pingcap/tiflow/issues/11402) @[3AceShowHand](https://github.com/3AceShowHand) - マルチノード環境で大量の`UPDATE`操作を実行する際にChangefeedを繰り返し再起動するとデータの不整合が発生する可能性がある問題を修正[＃11219](https://github.com/pingcap/tiflow/issues/11219) @[lidezhu](https://github.com/lidezhu) - 下流の Kafka にアクセスできない場合にプロセッサモジュールがスタックする可能性がある問題を修正[＃11340](https://github.com/pingcap/tiflow/issues/11340) @[asddongmen](https://github.com/asddongmen) @@ -195,7 +195,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - MariaDBデータの移行中に`SET`ステートメントがDM panicを引き起こす問題を修正[＃10206](https://github.com/pingcap/tiflow/issues/10206) @[dveeden](https://github.com/dveeden) - `go-mysql` にアップグレードして接続ブロックの問題を修正しました [＃11041](https://github.com/pingcap/tiflow/issues/11041) @[D3Hunter](https://github.com/D3Hunter) - インデックスの長さがデフォルト値の`max-index-length` を超えるとデータレプリケーションが中断される問題を修正しました [＃11459](https://github.com/pingcap/tiflow/issues/11459) @[michaelmdeng](https://github.com/michaelmdeng) - - スキーマ トラッカーが LIST パーティション テーブルを誤って処理し、DM エラーが発生する問題を修正しました。 [＃11408](https://github.com/pingcap/tiflow/issues/11408) @[lance6716](https://github.com/lance6716) + - スキーマ トラッカーが LIST パーティションテーブルを誤って処理し、DM エラーが発生する問題を修正しました。 [＃11408](https://github.com/pingcap/tiflow/issues/11408) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index 1194ab2380028..0e71c36cf3046 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -73,7 +73,7 @@ TiDB バージョン: 8.1.2 - `IndexNestedLoopHashJoin` のデータ競合問題を修正 [＃49692](https://github.com/pingcap/tidb/issues/49692) @[solotzg](https://github.com/solotzg) - `StreamAggExec`分の`groupOffset`空の場合に TiDB がpanicを起こす可能性がある問題を修正しました [＃53867](https://github.com/pingcap/tidb/issues/53867) @[xzhangxian1008](https://github.com/xzhangxian1008) - 相関サブクエリと CTE を含むクエリを実行すると、TiDB がハングしたり、誤った結果が返されたりする問題を修正しました。 [＃55551](https://github.com/pingcap/tidb/issues/55551) @[guo-shaoge](https://github.com/guo-shaoge) - - インデックス追加中の再試行によって発生するデータ インデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) + - インデックス追加中の再試行によって発生するデータインデックスの不整合の問題を修正しました [＃55808](https://github.com/pingcap/tidb/issues/55808) @[lance6716](https://github.com/lance6716) - 整数型の列に小さい表示幅を指定すると`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) @@ -117,17 +117,17 @@ TiDB バージョン: 8.1.2 - 乱数ジェネレータの頻繁な作成によって発生するパフォーマンスジッターの問題を修正しました [＃8674](https://github.com/tikv/pd/issues/8674) @[rleungx](https://github.com/rleungx) - ホットスポット キャッシュのメモリリーク問題を修正 [＃8698](https://github.com/tikv/pd/issues/8698) @[lhy1024](https://github.com/lhy1024) - ラベル統計のメモリリーク問題を修正 [＃8700](https://github.com/tikv/pd/issues/8700) @[lhy1024](https://github.com/lhy1024) - - 削除されたリソース グループが監視パネルに引き続き表示される問題を修正しました [＃8716](https://github.com/tikv/pd/issues/8716) @[AndreMouche](https://github.com/AndreMouche) + - 削除されたリソースグループが監視パネルに引き続き表示される問題を修正しました [＃8716](https://github.com/tikv/pd/issues/8716) @[AndreMouche](https://github.com/AndreMouche) - マイクロサービスモードでPDリーダーが切り替えられたときにスケジューリングサーバーでデータ競合が発生する可能性がある問題を修正しました [＃8538](https://github.com/tikv/pd/issues/8538) @[lhy1024](https://github.com/lhy1024) - `evict-leader-scheduler`で間違ったパラメータを使用すると、PD がエラーを正しく報告せず、一部のスケジューラが利用できなくなる問題を修正しました[＃8619](https://github.com/tikv/pd/issues/8619) @[rleungx](https://github.com/rleungx) - - リソース グループ セレクターがどのパネルでも有効にならない問題を修正しました [＃56572](https://github.com/pingcap/tidb/issues/56572) @[glorv](https://github.com/glorv) + - リソースグループセレクターがどのパネルでも有効にならない問題を修正しました [＃56572](https://github.com/pingcap/tidb/issues/56572) @[glorv](https://github.com/glorv) - TiFlash - 複数のリージョンがスナップショットを同時に適用しているときに発生する誤ったリージョン重複チェックの失敗によりTiFlash がpanicになる可能性がある問題を修正しました。 [＃9329](https://github.com/pingcap/tiflash/issues/9329) @[CalvinNeo](https://github.com/CalvinNeo) - 2番目のパラメータが負のの場合に`SUBSTRING()`関数が誤った結果を返す問題を修正しました [＃9604](https://github.com/pingcap/tiflash/issues/9604) @[guo-shaoge](https://github.com/guo-shaoge) - 遅延マテリアライゼーションが有効になっている場合に一部のクエリでエラーが報告される可能性がある問題を修正[＃9472](https://github.com/pingcap/tiflash/issues/9472) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - テーブルに無効な文字を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブルスキーマを解析できない問題を修正しました。 [＃9461](https://github.com/pingcap/tiflash/issues/9461) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlashでサポートされていない一部の JSON関数がTiFlash にプッシュダウンされる問題を修正しました [＃9444](https://github.com/pingcap/tiflash/issues/9444) @[windtalker](https://github.com/windtalker) - 特定のケースで関数`CAST AS DECIMAL`の結果の符号が正しくない問題を修正[＃9301](https://github.com/pingcap/tiflash/issues/9301) @[guo-shaoge](https://github.com/guo-shaoge) - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 [＃9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) @@ -149,9 +149,9 @@ TiDB バージョン: 8.1.2 - TiCDC - PullerモジュールのResolved TSレイテンシーモニタリングで誤った値が表示される問題を修正しました [＃11561](https://github.com/pingcap/tiflow/issues/11561) @[wlwilliamx](https://github.com/wlwilliamx) - - `enable-table-across-nodes`有効にすると、リージョン分割中にテーブルの一部のスパン レプリケーション タスクが失われる可能性がある問題を修正しました。 [＃11675](https://github.com/pingcap/tiflow/issues/11675) @[wk989898](https://github.com/wk989898) + - `enable-table-across-nodes`有効にすると、リージョン分割中にテーブルの一部のスパン レプリケーションタスクが失われる可能性がある問題を修正しました。 [＃11675](https://github.com/pingcap/tiflow/issues/11675) @[wk989898](https://github.com/wk989898) - やり直しモジュールがエラーを正しく報告できない問題を修正しました [＃11744](https://github.com/pingcap/tiflow/issues/11744) @[CharlesCheung96](https://github.com/CharlesCheung96) - - TiDB DDL 所有者の変更中に DDL タスクのスキーマ バージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) + - TiDB DDL 所有者の変更中に DDL タスクのスキーマバージョンが非増分になったときに、TiCDC が誤って DDL タスクを破棄する問題を修正[＃11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) - チェンジフィードチェックポイントの**barrier-ts**監視メトリックが不正確になる可能性がある問題を修正しました[＃11553](https://github.com/pingcap/tiflow/issues/11553) @[3AceShowHand](https://github.com/3AceShowHand) - TiDB Data Migration (DM) diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index e14c1375acb4e..6f0a4fd18c1b8 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 8.2.0 バージョン8.2.0では、以下の主要な機能と改善点が導入されています。 -
    カテゴリ機能／改善点説明
    信頼性と可用性TiProxyは複数のロードバランシングポリシーをサポートしています。 TiDB v8.2.0では、TiProxyはステータス、接続数、健全性、メモリ、CPU、ロケーションなど、さまざまな要素に基づいてTiDBノードを評価し、ランク付けします。 policy構成項目で指定された負荷分散ポリシーに従って、TiProxyはデータベース操作を実行する最適なTiDBノードを動的に選択します。これにより、リソース使用率全体が最適化され、クラスタのパフォーマンスが向上し、スループットが増加します。
    TiDB の並列 HashAgg アルゴリズムはディスク スピル (GA) をサポートしますHashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリ パフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
    統計情報の読み込み効率を最大10倍向上SaaSやPaaSサービスなど、テーブルとパーティションの数が多いクラスタでは、統計情報のロード効率を改善することで、TiDBインスタンスの起動速度低下の問題を解決し、統計情報の動的ロードの成功率を高めることができます。この改善により、統計情報のロード失敗によるパフォーマンス低下が軽減され、クラスタの安定性が向上します。
    データベースの運用と可観測性リソースグループの切り替えに対する特権制御を導入するリソース制御は広く利用されているため、リソースグループの切り替えに関する権限制御は、データベースユーザーによるリソースの不正使用を防ぎ、管理者によるリソース使用全体の保護を強化し、クラスタの安定性を向上させることができる。
    +
    カテゴリ機能／改善点説明
    信頼性と可用性TiProxyは複数のロードバランシングポリシーをサポートしています。 TiDB v8.2.0では、TiProxyはステータス、接続数、健全性、メモリ、CPU、ロケーションなど、さまざまな要素に基づいてTiDBノードを評価し、ランク付けします。 policy構成項目で指定された負荷分散ポリシーに従って、TiProxyはデータベース操作を実行する最適なTiDBノードを動的に選択します。これにより、リソース使用率全体が最適化され、クラスタのパフォーマンスが向上し、スループットが増加します。
    TiDB の並列 HashAgg アルゴリズムはディスクスピル (GA) をサポートしますHashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリパフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
    統計情報の読み込み効率を最大10倍向上SaaSやPaaSサービスなど、テーブルとパーティションの数が多いクラスタでは、統計情報のロード効率を改善することで、TiDBインスタンスの起動速度低下の問題を解決し、統計情報の動的ロードの成功率を高めることができます。この改善により、統計情報のロード失敗によるパフォーマンス低下が軽減され、クラスタの安定性が向上します。
    データベースの運用と可観測性リソースグループの切り替えに対する特権制御を導入するリソース制御は広く利用されているため、リソースグループの切り替えに関する権限制御は、データベースユーザーによるリソースの不正使用を防ぎ、管理者によるリソース使用全体の保護を強化し、クラスタの安定性を向上させることができる。
    ## 機能の詳細 {#feature-details} @@ -35,7 +35,7 @@ TiDB バージョン: 8.2.0 詳細については、 [ドキュメント](/system-variables.md#tidb_executor_concurrency-new-in-v50)を参照してください。 -- TiDB の並列 HashAgg アルゴリズムは、ディスク スピル (GA) をサポートしています。 [#35637](https://github.com/pingcap/tidb/issues/35637) @[xzhangxian1008](https://github.com/xzhangxian1008) +- TiDB の並列 HashAgg アルゴリズムは、ディスクスピル (GA) をサポートしています。 [#35637](https://github.com/pingcap/tidb/issues/35637) @[xzhangxian1008](https://github.com/xzhangxian1008) TiDB v8.0.0 では、実験的機能としてディスクスピルをサポートする並列 HashAgg アルゴリズムが導入されました。v8.2.0 では、この機能が一般提供 (GA) されます。並列 HashAgg アルゴリズムを使用すると、TiDB はメモリ使用量に基づいて自動的にデータスピルをトリガーし、クエリのパフォーマンスとデータスループットのバランスを取ります。この機能はデフォルトで有効になっています。この機能を制御するシステム変数`tidb_enable_parallel_hashagg_spill`は、今後のリリースで非推奨となります。 @@ -107,7 +107,7 @@ TiDB バージョン: 8.2.0 - TiFlashログの感度低下を強化 [#8977](https://github.com/pingcap/tiflash/issues/8977) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiDB v8.0.0 では、ログの匿名化機能が強化され、TiDB ログ内のユーザー データがマーカー`‹ ›`で囲まれるかどうかを制御できるようになりました。マークされたログに基づいて、ログを表示する際にマークされた情報を削除するかどうかを決定できるため、ログの匿名化の柔軟性が向上します。v8.2.0 では、 TiFlash でログの匿名化に関する同様の機能強化が導入されています。この機能を使用するには、 TiFlash構成項目`security.redact_info_log`を`marker`に設定します。 + TiDB v8.0.0 では、ログの匿名化機能が強化され、TiDB ログ内のユーザーデータがマーカー`‹ ›`で囲まれるかどうかを制御できるようになりました。マークされたログに基づいて、ログを表示する際にマークされた情報を削除するかどうかを決定できるため、ログの匿名化の柔軟性が向上します。v8.2.0 では、 TiFlash でログの匿名化に関する同様の機能強化が導入されています。この機能を使用するには、 TiFlash構成項目`security.redact_info_log`を`marker`に設定します。 詳細については、 [ドキュメント](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)を参照してください。 @@ -115,7 +115,7 @@ TiDB バージョン: 8.2.0 - 複数の変更フィード間で TiCDC 同期ポイントを調整する [#11212](https://github.com/pingcap/tiflow/issues/11212) @[hongyunyan](https://github.com/hongyunyan) - バージョン 8.2.0 より前は、複数のチェンジフィード間で TiCDC 同期ポイントを整合させるのは困難でした。チェンジフィードの作成時に、他のチェンジフィードの同期ポイントと整合するように、チェンジフィードの`startTs` `sync-point-interval`構成の倍数として作成されます。この変更により、同じ`sync-point-interval`構成を持つ複数のチェンジフィード間で同期ポイントを整合させることが可能になり、複数のダウンストリーム クラスタの整合が簡素化され、機能が向上します。 + バージョン 8.2.0 より前は、複数のチェンジフィード間で TiCDC 同期ポイントを整合させるのは困難でした。チェンジフィードの作成時に、他のチェンジフィードの同期ポイントと整合するように、チェンジフィードの`startTs` `sync-point-interval`構成の倍数として作成されます。この変更により、同じ`sync-point-interval`構成を持つ複数のチェンジフィード間で同期ポイントを整合させることが可能になり、複数のダウンストリームクラスタの整合が簡素化され、機能が向上します。 詳細については、 [ドキュメント](/ticdc/ticdc-upstream-downstream-check.md#notes)を参照してください。 @@ -133,11 +133,11 @@ TiDB バージョン: 8.2.0 ### 動作の変更 {#behavior-changes} -- TiDB Lightningを使用して CSV ファイルをインポートする場合、 `strict-format = true`を設定して大きな CSV ファイルを複数の小さな CSV ファイルに分割し、同時実行性とインポート パフォーマンスを向上させる場合は、 `terminator`明示的に指定する必要があります。指定できる値は、 `\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSV ファイル データの解析時に例外が発生する可能性があります。 [#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) +- TiDB Lightningを使用して CSV ファイルをインポートする場合、 `strict-format = true`を設定して大きな CSV ファイルを複数の小さな CSV ファイルに分割し、同時実行性とインポートパフォーマンスを向上させる場合は、 `terminator`明示的に指定する必要があります。指定できる値は、 `\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSV ファイル データの解析時に例外が発生する可能性があります。 [#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) -- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用して CSV ファイルをインポートする場合、大きな CSV ファイルを複数の小さな CSV ファイルに分割して同時実行性とインポート パフォーマンスを向上させるために`SPLIT_FILE`パラメーターを指定すると、行末文字`LINES_TERMINATED_BY`を明示的に指定する必要があります。指定できる値は`\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSV ファイル データの解析時に例外が発生する可能性があります。 [#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) +- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用して CSV ファイルをインポートする場合、大きな CSV ファイルを複数の小さな CSV ファイルに分割して同時実行性とインポートパフォーマンスを向上させるために`SPLIT_FILE`パラメーターを指定すると、行末文字`LINES_TERMINATED_BY`を明示的に指定する必要があります。指定できる値は`\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSV ファイル データの解析時に例外が発生する可能性があります。 [#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) -- BR v8.2.0 より前は、TiCDC レプリケーション タスクを持つクラスタで[BRデータ復元](/br/backup-and-restore-overview.md)を実行することはサポートされていませんでした。v8.2.0 以降、 BR はTiCDC のデータ復元に関する制限を緩和しました。復元対象データの BackupTS (バックアップ時刻) が changefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) (現在のレプリケーションの進行状況を示すタイムスタンプ) より前であれば、 BR は正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオで、 BR はTiCDC レプリケーション タスクを持つクラスタのデータ復元をサポートしていると考えられます。 [#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen) +- BR v8.2.0 より前は、TiCDC レプリケーションタスクを持つクラスタで[BRデータ復元](/br/backup-and-restore-overview.md)を実行することはサポートされていませんでした。v8.2.0 以降、 BR はTiCDC のデータ復元に関する制限を緩和しました。復元対象データの BackupTS (バックアップ時刻) が changefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) (現在のレプリケーションの進行状況を示すタイムスタンプ) より前であれば、 BR は正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオで、 BR はTiCDC レプリケーションタスクを持つクラスタのデータ復元をサポートしていると考えられます。 [#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen) ### MySQLとの互換性 {#mysql-compatibility} @@ -168,7 +168,7 @@ TiDB バージョン: 8.2.0 ### システムテーブル {#system-tables} -- [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md)および[`INFORMATION_SCHEMA.CLUSTER_PROCESSLIST`](/information-schema/information-schema-processlist.md#cluster_processlist)システム テーブルに`SESSION_ALIAS`フィールドを追加して、現在のセッションのエイリアスを表示します。 [#46889](https://github.com/pingcap/tidb/issues/46889) @[lcwangchao](https://github.com/lcwangchao) +- [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md)および[`INFORMATION_SCHEMA.CLUSTER_PROCESSLIST`](/information-schema/information-schema-processlist.md#cluster_processlist)システムテーブルに`SESSION_ALIAS`フィールドを追加して、現在のセッションのエイリアスを表示します。 [#46889](https://github.com/pingcap/tidb/issues/46889) @[lcwangchao](https://github.com/lcwangchao) ### コンパイラバージョン {#compiler-versions} @@ -221,7 +221,7 @@ TiDB バージョン: 8.2.0 - PD - リージョンハートビート処理のパフォーマンスを改善 [#7897](https://github.com/tikv/pd/issues/7897) @[nolouch](https://github.com/nolouch)@[rleungx](https://github.com/rleungx) @[JmPotato](https://github.com/JmPotato) - - pd-ctl は、バイトまたはクエリ次元によるホット リージョンのクエリをサポートします [#7369](https://github.com/tikv/pd/issues/7369) @[lhy1024](https://github.com/lhy1024) + - pd-ctl は、バイトまたはクエリ次元によるホットリージョンのクエリをサポートします [#7369](https://github.com/tikv/pd/issues/7369) @[lhy1024](https://github.com/lhy1024) - TiFlash diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 7781807259f67..a475389a66372 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -85,7 +85,7 @@ TiDBバージョン：8.3.0 詳細については、 [ドキュメント](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)を参照してください。 -- パーティション テーブルはグローバル インデックスをサポートします (実験的) [#45133](https://github.com/pingcap/tidb/issues/45133) @[mjonss](https://github.com/mjonss)@[Defined2014](https://github.com/Defined2014) @[jiyfhust](https://github.com/jiyfhust)@[L-maple](https://github.com/L-maple) +- パーティションテーブルはグローバルインデックスをサポートします (実験的) [#45133](https://github.com/pingcap/tidb/issues/45133) @[mjonss](https://github.com/mjonss)@[Defined2014](https://github.com/Defined2014) @[jiyfhust](https://github.com/jiyfhust)@[L-maple](https://github.com/L-maple) 以前のバージョンのパーティションテーブルでは、グローバルインデックスがサポートされていないため、いくつかの制限がありました。たとえば、一意キーはテーブルのパーティション式内のすべての列を使用する必要があります。クエリ条件でパーティションキーを使用しない場合、クエリはすべてのパーティションをスキャンするため、パフォーマンスが低下します。v7.6.0以降では、グローバルインデックス機能を有効にするためにシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)が導入されました。ただし、この機能は当時開発中であったため、有効にすることは推奨されません。 @@ -206,7 +206,7 @@ TiDBバージョン：8.3.0 ### システムテーブル {#system-tables} -- [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md)および[`INFORMATION_SCHEMA.CLUSTER_PROCESSLIST`](/information-schema/information-schema-processlist.md#cluster_processlist)システム テーブルに`SESSION_ALIAS`フィールドが追加され、DML ステートメントによって現在影響を受けている行数が表示されます。[#46889](https://github.com/pingcap/tidb/issues/46889) @[lcwangchao](https://github.com/lcwangchao) +- [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md)および[`INFORMATION_SCHEMA.CLUSTER_PROCESSLIST`](/information-schema/information-schema-processlist.md#cluster_processlist)システムテーブルに`SESSION_ALIAS`フィールドが追加され、DML ステートメントによって現在影響を受けている行数が表示されます。[#46889](https://github.com/pingcap/tidb/issues/46889) @[lcwangchao](https://github.com/lcwangchao) ## 非推奨機能 {#deprecated-features} @@ -265,7 +265,7 @@ TiDBバージョン：8.3.0 - `async-io`が有効になっている場合、 Raftログの書き込みバッチ処理ポリシーを最適化して、ディスク I/O 帯域幅リソースの消費を削減します [#16907](https://github.com/tikv/tikv/issues/16907) @[LykxSassinator](https://github.com/LykxSassinator) - リージョン部分購読をより適切にサポートするために、TiCDCデリゲートとダウンストリームモジュールを再設計します [#16362](https://github.com/tikv/tikv/issues/16362) @[hicqu](https://github.com/hicqu) - - 単一のスロークエリ ログのサイズを削減 [#17294](https://github.com/tikv/tikv/issues/17294) @[Connor1996](https://github.com/Connor1996) + - 単一のスロークエリログのサイズを削減 [#17294](https://github.com/tikv/tikv/issues/17294) @[Connor1996](https://github.com/Connor1996) - 新しいモニタリング指標を追加`min safe ts` [#17307](https://github.com/tikv/tikv/issues/17307) @[mittalrishabh](https://github.com/mittalrishabh) - ピアメッセージチャネルのメモリ使用量を削減します [#16229](https://github.com/tikv/tikv/issues/16229) @[Connor1996](https://github.com/Connor1996) @@ -355,7 +355,7 @@ TiDBバージョン：8.3.0 - 仮想生成列を含むクエリが遅延マテリアライゼーション有効後に誤った結果を返す可能性がある問題を修正 [#9188](https://github.com/pingcap/tiflash/issues/9188) @[JinheLin](https://github.com/JinheLin) - TiFlashでSSL証明書の設定を空文字列に設定するとTLSが誤って有効になり、 TiFlashが起動に失敗する問題を修正しました [#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - データベース作成直後にデータベースが削除されるとTiFlash がpanicすることがある問題を修正 [#9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlashと任意の PD 間のネットワーク パーティション (ネットワークの切断) により、読み取りリクエストのタイムアウト エラーが発生する可能性がある問題を修正 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlashと任意の PD 間のネットワークパーティション (ネットワークの切断) により、読み取りリクエストのタイムアウトエラーが発生する可能性がある問題を修正 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 分散ストレージおよびコンピューティングアーキテクチャでTiFlash書き込みノードの再起動に失敗することがある問題を修正 [#9282](https://github.com/pingcap/tiflash/issues/9282) @[JaySon-Huang](https://github.com/JaySon-Huang) - 分散ストレージおよびコンピューティングアーキテクチャにおいて、 TiFlash書き込みノードの読み取りスナップショットがタイムリーに解放されない問題を修正します [#9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index c936075280be5..818a0915d4dcf 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 8.4.0 バージョン8.4.0では、以下の主要な機能と改善点が導入されています。 -
    カテゴリ機能／改善点説明
    拡張性とパフォーマンスインスタンスレベルの実行プランキャッシュ（実験的）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
    パーティションテーブルのグローバルインデックス（GA）グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行に必要なアプリケーションの変更作業の一部が不要になります。
    TSOリクエストの並列モード高並行処理環境では、この機能を使用することでTSOの取得待ち時間を短縮し、クラスタのスループットを向上させることができます。
    キャッシュされたテーブルのクエリパフォーマンスを向上させるキャッシュされたテーブルに対するインデックススキャンのクエリパフォーマンスが向上し、場合によっては最大5.4倍の改善が見られます。小規模なテーブルに対する高速クエリの場合、キャッシュされたテーブルを使用することで、全体的なパフォーマンスを大幅に向上させることができます。
    信頼性と可用性 暴走クエリに対するトリガーの追加と、リソースグループの切り替えのサポート暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
    リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートするリソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
    TiProxyはトラフィックのキャプチャと再生をサポートします（実験的）。 TiProxyを使用して、クラスターのアップグレード、移行、デプロイメントの変更などの主要な操作を行う前に、TiDB本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲットのテストクラスターで再生することで、パフォーマンスを検証し、変更が確実に成功することを確認します。
    同時自動統計収集TiDBクラスタ内での同時実行自動分析操作の数を制御するために、システム変数tidb_auto_analyze_concurrencyを導入します。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動による調整が削減され、クラスタの安定したパフォーマンスが確保されます。
    SQLベクトル検索（実験的）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
    データベースの運用と可観測性TiKVとTiDBのCPU時間をメモリテーブルに表示するCPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
    テーブルまたはデータベースごとに集計されたTiKV CPU時間を表示する機能をサポートします。ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
    IMDSv2サービスが有効になっているTiKVインスタンスのバックアップをサポートします。 AWS EC2 では、デフォルトのメタデータサービスとして IMDSv2 が使用されるようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータバックアップをサポートしており、パブリック クラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。
    Securityログバックアップデータのクライアント側暗号化（実験的）ログバックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
    +
    カテゴリ機能／改善点説明
    拡張性とパフォーマンスインスタンスレベルの実行プランキャッシュ（実験的）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行計画をキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
    パーティションテーブルのグローバルインデックス（GA）グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行に必要なアプリケーションの変更作業の一部が不要になります。
    TSOリクエストの並列モード高並行処理環境では、この機能を使用することでTSOの取得待ち時間を短縮し、クラスタのスループットを向上させることができます。
    キャッシュされたテーブルのクエリパフォーマンスを向上させるキャッシュされたテーブルに対するインデックススキャンのクエリパフォーマンスが向上し、場合によっては最大5.4倍の改善が見られます。小規模なテーブルに対する高速クエリの場合、キャッシュされたテーブルを使用することで、全体的なパフォーマンスを大幅に向上させることができます。
    信頼性と可用性 暴走クエリに対するトリガーの追加と、リソースグループの切り替えのサポート暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
    リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートするリソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
    TiProxyはトラフィックのキャプチャと再生をサポートします（実験的）。 TiProxyを使用して、クラスターのアップグレード、移行、デプロイメントの変更などの主要な操作を行う前に、TiDB本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲットのテストクラスターで再生することで、パフォーマンスを検証し、変更が確実に成功することを確認します。
    同時自動統計収集TiDBクラスタ内での同時実行自動分析操作の数を制御するために、システム変数tidb_auto_analyze_concurrencyを導入します。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動による調整が削減され、クラスタの安定したパフォーマンスが確保されます。
    SQLベクトル検索（実験的）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
    データベースの運用と可観測性TiKVとTiDBのCPU時間をメモリテーブルに表示するCPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
    テーブルまたはデータベースごとに集計されたTiKV CPU時間を表示する機能をサポートします。ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
    IMDSv2サービスが有効になっているTiKVインスタンスのバックアップをサポートします。 AWS EC2 では、デフォルトのメタデータサービスとして IMDSv2 が使用されるようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータバックアップをサポートしており、パブリッククラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。
    Securityログバックアップデータのクライアント側暗号化（実験的）ログバックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
    ## 機能の詳細 {#feature-details} @@ -49,23 +49,23 @@ TiDB バージョン: 8.4.0 - 冗長性を排除し、同じメモリ消費量でより多くの実行計画をキャッシュします。 - インスタンスに固定サイズのメモリを割り当て、メモリ使用量をより効果的に制限します。 - v8.4.0 では、インスタンス レベルの実行計画 キャッシュはクエリ実行計画のキャッシュのみをサポートしており、デフォルトでは無効になっています。 [`tidb_enable_instance_plan_cache`](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)を使用してこの機能を有効にし、 [`tidb_instance_plan_cache_max_size`](/system-variables.md#tidb_instance_plan_cache_max_size-new-in-v840)を使用して最大メモリ使用量を設定できます。この機能を有効にする前に、[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)と[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を無効にしてください。 + v8.4.0 では、インスタンスレベルの実行計画 キャッシュはクエリ実行計画のキャッシュのみをサポートしており、デフォルトでは無効になっています。 [`tidb_enable_instance_plan_cache`](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)を使用してこの機能を有効にし、 [`tidb_instance_plan_cache_max_size`](/system-variables.md#tidb_instance_plan_cache_max_size-new-in-v840)を使用して最大メモリ使用量を設定できます。この機能を有効にする前に、[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)と[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を無効にしてください。 詳細については、 [ドキュメント](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840)を参照してください。 - TiDB Lightningの論理インポートモードは、プリペアドステートメントとクライアントステートメントキャッシュをサポートします [#54850](https://github.com/pingcap/tidb/issues/54850) @[dbsid](https://github.com/dbsid) - `logical-import-prep-stmt`設定項目を有効にすると、TiDB Lightning の論理インポートモードで実行される SQL ステートメントは、プリペアド ステートメントとクライアント ステートメント キャッシュを使用します。これにより、 TiDB SQLの解析とコンパイルのコストが削減され、SQL の実行効率が向上し、実行計画 キャッシュへのアクセス確率が高まるため、論理インポートが高速化されます。 + `logical-import-prep-stmt`設定項目を有効にすると、TiDB Lightning の論理インポートモードで実行される SQL ステートメントは、プリペアドステートメントとクライアント ステートメントキャッシュを使用します。これにより、 TiDB SQLの解析とコンパイルのコストが削減され、SQL の実行効率が向上し、実行計画 キャッシュへのアクセス確率が高まるため、論理インポートが高速化されます。 詳細については、 [ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 -- パーティション テーブルはグローバル インデックスをサポート (GA) [#45133](https://github.com/pingcap/tidb/issues/45133) @[mjonss](https://github.com/mjonss)@[Defined2014](https://github.com/Defined2014) @[jiyfhust](https://github.com/jiyfhust)@[L-maple](https://github.com/L-maple) +- パーティションテーブルはグローバルインデックスをサポート (GA) [#45133](https://github.com/pingcap/tidb/issues/45133) @[mjonss](https://github.com/mjonss)@[Defined2014](https://github.com/Defined2014) @[jiyfhust](https://github.com/jiyfhust)@[L-maple](https://github.com/L-maple) TiDBの初期バージョンでは、パーティションテーブルはグローバルインデックスをサポートしていないため、いくつかの制限がありました。たとえば、一意キーはテーブルのパーティション式内のすべての列を使用する必要があります。クエリ条件でパーティションキーを使用しない場合、クエリはすべてのパーティションをスキャンするため、パフォーマンスが低下します。v7.6.0以降では、グローバルインデックス機能を有効にするためにシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)が導入されました。しかし、この機能は当時開発中であったため、有効にすることは推奨されません。 バージョン8.3.0以降、グローバルインデックス機能は実験的機能としてリリースされました。 `GLOBAL`キーワードを使用すると、パーティションテーブルのグローバルインデックスを明示的に作成できます。これにより、パーティションテーブルの一意キーにパーティション式で使用されるすべての列を含める必要があるという制約がなくなり、より柔軟なアプリケーション要件に対応できるようになります。さらに、グローバルインデックスは、パーティション化されていない列に基づくクエリのパフォーマンスも向上させます。 - バージョン 8.4.0 では、この機能が一般提供 (GA) になります。グローバル インデックス機能を有効にするためにシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)を設定する代わりに、キーワード`GLOBAL`を使用してグローバル インデックスを作成できます。バージョン 8.4.0 以降、このシステム変数は非推奨となり、常に`ON`になります。 + バージョン 8.4.0 では、この機能が一般提供 (GA) になります。グローバルインデックス機能を有効にするためにシステム変数[`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760)を設定する代わりに、キーワード`GLOBAL`を使用してグローバルインデックスを作成できます。バージョン 8.4.0 以降、このシステム変数は非推奨となり、常に`ON`になります。 詳細については、[ドキュメント](/global-indexes.md)を参照してください。 @@ -133,7 +133,7 @@ TiDB バージョン: 8.4.0 ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。 - v8.4.0 以降、TiDB は [ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)をサポートし、強力なベクトル検索機能を提供します。 TiDB ベクトル データ タイプは、最大 16,383 次元をサポートし、L2 距離 (ユークリッド距離)、コサイン距離、負の内積、L1 距離 (マンハッタン距離) を含むさまざまな[距離関数](/ai/reference/vector-search-functions-and-operators.md#vector-functions)をサポートします。 + v8.4.0 以降、TiDB は [ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)をサポートし、強力なベクトル検索機能を提供します。 TiDB ベクトルデータタイプは、最大 16,383 次元をサポートし、L2 距離 (ユークリッド距離)、コサイン距離、負の内積、L1 距離 (マンハッタン距離) を含むさまざまな[距離関数](/ai/reference/vector-search-functions-and-operators.md#vector-functions)をサポートします。 ベクトル検索を開始するには、ベクトルデータ型のテーブルを作成し、ベクトルデータを挿入し、ベクトルデータに対するクエリを実行するだけで済みます。ベクトルデータと従来の関係データを組み合わせたクエリを実行することも可能です。 @@ -143,7 +143,7 @@ TiDB バージョン: 8.4.0 ### データベース操作 {#db-operations} -- BRはログ バックアップ データのクライアント側暗号化をサポートします (実験的) [#55834](https://github.com/pingcap/tidb/issues/55834) @[Tristan1900](https://github.com/Tristan1900) +- BRはログバックアップデータのクライアント側暗号化をサポートします (実験的) [#55834](https://github.com/pingcap/tidb/issues/55834) @[Tristan1900](https://github.com/Tristan1900) 以前のTiDBバージョンでは、スナップショットバックアップデータのみがクライアント側で暗号化されていました。v8.4.0以降では、ログバックアップデータもクライアント側で暗号化できるようになりました。ログバックアップデータをバックアップストレージにアップロードする前に、以下のいずれかの方法でバックアップデータを暗号化してセキュリティを確保できます。 @@ -163,7 +163,7 @@ TiDB バージョン: 8.4.0 - TiDBとTiKVが消費したCPU時間をシステムテーブルに表示する [#55542](https://github.com/pingcap/tidb/issues/55542) @[yibin87](https://github.com/yibin87) - [TiDB Dashboard](/dashboard/dashboard-intro.md)の[Top SQLページ](/dashboard/top-sql.md)CPU 使用率の高い SQL ステートメントを表示します。バージョン 8.4.0 以降、TiDB はシステム テーブルに CPU 使用時間情報を追加し、セッションや SQL の他のメトリックと並べて表示することで、CPU 使用率の高い操作をさまざまな視点から簡単に把握できるようにしました。この情報は、インスタンスの CPU スパイクやクラスタ内の読み書きホットスポットなどのシナリオで、問題の原因を迅速に特定するのに役立ちます。 + [TiDB Dashboard](/dashboard/dashboard-intro.md)の[Top SQLページ](/dashboard/top-sql.md)CPU 使用率の高い SQL ステートメントを表示します。バージョン 8.4.0 以降、TiDB はシステムテーブルに CPU 使用時間情報を追加し、セッションや SQL の他のメトリックと並べて表示することで、CPU 使用率の高い操作をさまざまな視点から簡単に把握できるようにしました。この情報は、インスタンスの CPU スパイクやクラスタ内の読み書きホットスポットなどのシナリオで、問題の原因を迅速に特定するのに役立ちます。 - [ステートメントサマリーテーブル](/statement-summary-tables.md)には`AVG_TIDB_CPU_TIME`と`AVG_TIKV_CPU_TIME`が追加され、過去の個々の SQL ステートメントによって消費された平均 CPU 時間が表示されます。 - [INFORMATION_SCHEMA.PROCESSLIST](/information-schema/information-schema-processlist.md)テーブルには、 `TIDB_CPU`と`TIKV_CPU`が追加され、現在セッションで実行されている SQL ステートメントの累積 CPU 消費量が表示されます。 @@ -215,7 +215,7 @@ TiDB バージョン: 8.4.0 | ------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `log_bin` | 削除済み | バージョン8.4.0では、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。この変数はTiDB Binlogが使用されているかどうかを示し、バージョン8.4.0以降は削除されます。 | | `sql_log_bin` | 削除済み | バージョン8.4.0では、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。この変数は、変更内容をTiDB Binlogに書き込むかどうかを示すもので、バージョン8.4.0以降は削除されます。 | -| [`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760) | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値`ON`に固定されます。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 `GLOBAL`または`CREATE TABLE`を実行してグローバル インデックスを作成する際に、対応する列にキーワード`ALTER TABLE`追加するだけで済みます。 | +| [`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760) | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値`ON`に固定されます。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 `GLOBAL`または`CREATE TABLE`を実行してグローバルインデックスを作成する際に、対応する列にキーワード`ALTER TABLE`追加するだけで済みます。 | | [`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。その値はデフォルト値`ON`に固定され、[リスト分割](/partitioned-table.md#list-partitioning)がデフォルトで有効になります。 | | [`tidb_enable_table_partition`](/system-variables.md#tidb_enable_table_partition) | 非推奨 | v8.4.0 では、この変数は非推奨になりました。その値はデフォルト値`ON`に固定されます。つまり、[テーブルパーティショニング](/partitioned-table.md)はデフォルトで有効になります。 | | [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) | 変更 | 値の範囲を`[1, 18446744073709551615]`から`[1, 128]`に変更します。 | @@ -271,7 +271,7 @@ v8.4.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ ### オペレーティングシステムとプラットフォームの要件変更 {#operating-system-and-platform-requirement-changes} -TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 +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 以降にアップグレードすると、クラスタが使用できなくなります。 @@ -366,7 +366,7 @@ TiDB をアップグレードする前に、オペレーティング システ - 非バイナリ照合順序を持つ文字列列の統計情報が、統計情報の初期化時にロードに失敗する可能性がある問題を修正 [#55684](https://github.com/pingcap/tidb/issues/55684) @[winoros](https://github.com/winoros) - クエリ条件`column IS NULL`を使用して一意インデックスにアクセスする際に、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 [#56116](https://github.com/pingcap/tidb/issues/56116) @[hawkingrei](https://github.com/hawkingrei) - クエリに`(... AND ...) OR (... AND ...) ...`のようなフィルタ条件が含まれている場合、オプティマイザが行数推定に最適な複数列統計情報を使用しない問題を修正します [#54323](https://github.com/pingcap/tidb/issues/54323) @[time-and-fate](https://github.com/time-and-fate) - - クエリに利用可能なインデックス マージ実行計画がある場合、 `read_from_storage`ヒントが有効にならない可能性がある問題を修正 [#56217](https://github.com/pingcap/tidb/issues/56217) @[AilinKid](https://github.com/AilinKid) + - クエリに利用可能なインデックスマージ実行計画がある場合、 `read_from_storage`ヒントが有効にならない可能性がある問題を修正 [#56217](https://github.com/pingcap/tidb/issues/56217) @[AilinKid](https://github.com/AilinKid) - `IndexNestedLoopHashJoin` のデータ競合問題を修正 [#49692](https://github.com/pingcap/tidb/issues/49692) @[solotzg](https://github.com/solotzg) - `SUB_PART`テーブル内の`INFORMATION_SCHEMA.STATISTICS`の値が`NULL`になっている問題を修正します [#55812](https://github.com/pingcap/tidb/issues/55812) @[Defined2014](https://github.com/Defined2014) - DMLステートメントにネストされた生成列が含まれている場合にエラーが発生する問題を修正しました [#53967](https://github.com/pingcap/tidb/issues/53967) @[wjhuang2016](https://github.com/wjhuang2016) @@ -408,7 +408,7 @@ TiDB をアップグレードする前に、オペレーティング システ - TiDB Data Migration (DM) - 複数のDMマスターノードが同時にリーダーになる可能性があり、データ不整合を引き起こす問題を修正しました [#11602](https://github.com/pingcap/tiflow/issues/11602) @[GMHDBJD](https://github.com/GMHDBJD) - - `ALTER DATABASE`ステートメントを処理する際に DM がデフォルト データベースを設定しないことでレプリケーション エラーが発生する問題を修正します [#11503](https://github.com/pingcap/tiflow/issues/11503) @[lance6716](https://github.com/lance6716) + - `ALTER DATABASE`ステートメントを処理する際に DM がデフォルトデータベースを設定しないことでレプリケーション エラーが発生する問題を修正します [#11503](https://github.com/pingcap/tiflow/issues/11503) @[lance6716](https://github.com/lance6716) - TiDB Lightning diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 2d6de2fb39db8..abd7da4117cec 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -17,7 +17,7 @@ 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 までのハイライトの一部を示しています。 -
    カテゴリ機能／改善点説明
    拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減する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で一般提供開始）バックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
    +
    カテゴリ機能／改善点説明
    拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減する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で一般提供開始）バックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、保管中および転送中のセキュリティを確保できます。
    ## 機能の詳細 {#feature-details} @@ -35,7 +35,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 - 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリ サービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定します。この機能が有効になると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 + 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリサービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760)を`ON`に設定します。この機能が有効になると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 詳細については、 [ドキュメント](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)を参照してください。 @@ -49,9 +49,9 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 詳細については、[ドキュメント](/accelerated-table-creation.md)を参照してください。 -- 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) +- 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インメモリエンジンを有効にしてスキャンパフォーマンスを向上させることができます。 @@ -81,13 +81,13 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 - `ADMIN ALTER DDL JOBS job_id THREAD = 8;` : 指定された DDL ジョブの`tidb_ddl_reorg_worker_cnt`をオンラインで調整します。 - `ADMIN ALTER DDL JOBS job_id BATCH_SIZE = 256;` : 指定されたジョブの`tidb_ddl_reorg_batch_size`をオンラインで調整します。 - - `ADMIN ALTER DDL JOBS job_id MAX_WRITE_SPEED = '200MiB';` : オンラインの各 TiKV ノードへのインデックス データの書き込みトラフィックを調整します。 + - `ADMIN ALTER DDL JOBS job_id MAX_WRITE_SPEED = '200MiB';` : オンラインの各 TiKV ノードへのインデックスデータの書き込みトラフィックを調整します。 詳細については、 [ドキュメント](/sql-statements/sql-statement-admin-alter-ddl.md)を参照してください。 ### セキュリティ {#security} -- BR は、完全バックアップ データとログ バックアップ データの両方のクライアント側暗号化をサポートします (GA) [#28640](https://github.com/pingcap/tidb/issues/28640) [#56433](https://github.com/pingcap/tidb/issues/56433) @[joccau](https://github.com/joccau)@[Tristan1900](https://github.com/Tristan1900) +- BR は、完全バックアップデータとログバックアップデータの両方のクライアント側暗号化をサポートします (GA) [#28640](https://github.com/pingcap/tidb/issues/28640) [#56433](https://github.com/pingcap/tidb/issues/56433) @[joccau](https://github.com/joccau)@[Tristan1900](https://github.com/Tristan1900) - TiDB v5.3.0で実験的的に導入された、クライアント側でのフルバックアップデータの暗号化機能を使用すると、カスタムの固定キーを使用してクライアント側でバックアップデータを暗号化できます。 @@ -133,16 +133,16 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`deprecate-integer-display-length`](/tidb-configuration-file.md#deprecate-integer-display-length) | 変更 | バージョン8.5.0以降、整数表示幅機能は非推奨となりました。この設定項目のデフォルト値は`false`から`true`に変更されました。 | | TiKV | [`raft-client-queue-size`](/tikv-configuration-file.md#raft-client-queue-size) | 変更 | デフォルト値を`8192`から`16384`に変更します。 | -| TiKV | [`in-memory-engine.capacity`](/tikv-configuration-file.md#capacity-new-in-v850) | 新しく追加された | TiKV MVCC インメモリ エンジンが使用できる最大メモリサイズを制御します。デフォルト値は`min(the system memory * 10%, 5 GiB)`です。 | +| TiKV | [`in-memory-engine.capacity`](/tikv-configuration-file.md#capacity-new-in-v850) | 新しく追加された | TiKV MVCC インメモリエンジンが使用できる最大メモリサイズを制御します。デフォルト値は`min(the system memory * 10%, 5 GiB)`です。 | | TiKV | [`in-memory-engine.enable`](/tikv-configuration-file.md#enable-new-in-v850) | 新しく追加された | TiKV MVCCのインメモリエンジンを有効にして、マルチバージョンクエリを高速化するかどうかを制御します。デフォルト値は`false`で、これはインメモリエンジンが無効になっていることを意味します。 | -| TiKV | [`in-memory-engine.gc-run-interval`](/tikv-configuration-file.md#gc-run-interval-new-in-v850) | 新しく追加された | インメモリ エンジンがキャッシュされた MVCC バージョンに対してガベージコレクション(GC) を実行する時間間隔を制御します。デフォルト値は`"3m"`です。 | +| TiKV | [`in-memory-engine.gc-run-interval`](/tikv-configuration-file.md#gc-run-interval-new-in-v850) | 新しく追加された | インメモリエンジンがキャッシュされた MVCC バージョンに対してガベージコレクション(GC) を実行する時間間隔を制御します。デフォルト値は`"3m"`です。 | | TiKV | [`in-memory-engine.mvcc-amplification-threshold`](/tikv-configuration-file.md#mvcc-amplification-threshold-new-in-v850) | 新しく追加された | インメモリエンジンがリージョンを選択してロードする際の、MVCC読み取り増幅のしきい値を制御します。デフォルト値は`10`で、リージョン内の1行を読み取るのに10を超えるMVCCバージョンを処理する必要がある場合は、そのリージョンがインメモリエンジンにロードされる可能性があることを示します。 | | PD | [`patrol-region-worker-count`](/pd-configuration-file.md#patrol-region-worker-count-new-in-v850) | 新しく追加された | リージョンの健全性状態を検査する際にチェッカーによって作成される同時[オペレーター](/glossary.md#operator)の数を制御します。 | | BR | [`--checksum`](/br/br-snapshot-manual.md) | 変更 | デフォルト値を`true`から`false`に変更します。これは、デフォルトではBR がフルバックアップ中にテーブルレベルのチェックサムを計算しないことを意味し、バックアップのパフォーマンスを向上させます。 | ### オペレーティングシステムとプラットフォームの要件変更 {#operating-system-and-platform-requirement-changes} -TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 +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 以降にアップグレードすると、クラスタが利用できなくなります。 @@ -178,8 +178,8 @@ TiDB をアップグレードする前に、オペレーティング システ - インデックス追加時の取り込みフェーズの最大速度を制限するために、新しいシステム変数`tidb_ddl_reorg_max_write_speed`を追加します [#57156](https://github.com/pingcap/tidb/issues/57156) @[CbcWestwolf](https://github.com/CbcWestwolf) - `information_schema.tables`のクエリのパフォーマンスを場合によっては改善する [#57295](https://github.com/pingcap/tidb/issues/57295) @[tangenta](https://github.com/tangenta) - DDLジョブパラメータの動的調整をサポートする [#57526](https://github.com/pingcap/tidb/issues/57526) @[fzzf678](https://github.com/fzzf678) - - パーティション式のすべての列を含むグローバル インデックスをサポート [#56230](https://github.com/pingcap/tidb/issues/56230) @[Defined2014](https://github.com/Defined2014) - - 範囲クエリのシナリオでリスト パーティション テーブルのパーティション プルーニングをサポート [#56673](https://github.com/pingcap/tidb/issues/56673) @[Defined2014](https://github.com/Defined2014) + - パーティション式のすべての列を含むグローバルインデックスをサポート [#56230](https://github.com/pingcap/tidb/issues/56230) @[Defined2014](https://github.com/Defined2014) + - 範囲クエリのシナリオでリストパーティションテーブルのパーティションプルーニングをサポート [#56673](https://github.com/pingcap/tidb/issues/56673) @[Defined2014](https://github.com/Defined2014) - FixControl#46177 をデフォルトで有効にして、場合によってはインデックス範囲スキャンではなくフルテーブルスキャンが誤って選択される問題を修正します [#46177](https://github.com/pingcap/tidb/issues/46177) @[terry1purcell](https://github.com/terry1purcell) - 複数列および多値インデックスの統計情報をより有効に活用するために内部推定ロジックを改善し、多値インデックスを含む特定のクエリの推定精度を向上させます [#56915](https://github.com/pingcap/tidb/issues/56915) @[time-and-fate](https://github.com/time-and-fate) - 特定のシナリオにおけるフルテーブルスキャンのコスト見積もりを改善し、フルテーブルスキャンを誤って選択する可能性を低減します [#57085](https://github.com/pingcap/tidb/issues/57085) @[terry1purcell](https://github.com/terry1purcell) @@ -201,7 +201,7 @@ TiDB をアップグレードする前に、オペレーティング システ - TiFlash - クラスター化インデックスを使用したテーブルのバックグラウンドでの古いデータのガベージコレクション速度を向上 [#9529](https://github.com/pingcap/tiflash/issues/9529) @[JaySon-Huang](https://github.com/JaySon-Huang) - - データ更新シナリオにおけるベクトル検索のクエリ パフォーマンスを向上 [#9599](https://github.com/pingcap/tiflash/issues/9599) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - データ更新シナリオにおけるベクトル検索のクエリパフォーマンスを向上 [#9599](https://github.com/pingcap/tiflash/issues/9599) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - ベクトルインデックス構築中の CPU 使用率の監視メトリクスを追加 [#9032](https://github.com/pingcap/tiflash/issues/9032) @[JaySon-Huang](https://github.com/JaySon-Huang) - 論理演算子の実行効率を向上 [#9146](https://github.com/pingcap/tiflash/issues/9146) @[windtalker](https://github.com/windtalker) @@ -210,7 +210,7 @@ TiDB をアップグレードする前に、オペレーティング システ - Backup & Restore (BR) - バックアップ中の不要なログ出力を減らす [#55902](https://github.com/pingcap/tidb/issues/55902) @[Leavrth](https://github.com/Leavrth) - - 暗号化キー`--crypter.key`のエラー メッセージを最適化 [#56388](https://github.com/pingcap/tidb/issues/56388) @[Tristan1900](https://github.com/Tristan1900) + - 暗号化キー`--crypter.key`のエラーメッセージを最適化 [#56388](https://github.com/pingcap/tidb/issues/56388) @[Tristan1900](https://github.com/Tristan1900) - データベース作成時のBRにおける同時実行数を増やし、データ復元パフォーマンスを向上させる [#56866](https://github.com/pingcap/tidb/issues/56866) @[Leavrth](https://github.com/Leavrth) - フルバックアップ中にテーブルレベルのチェックサム計算をデフォルトで無効にする（ `--checksum=false` ）バックアップパフォーマンスを向上させる [#56373](https://github.com/pingcap/tidb/issues/56373) @[Tristan1900](https://github.com/Tristan1900) - 各ストレージノードの接続タイムアウトを個別に追跡およびリセットするメカニズムを追加して、低速ノードの処理を強化し、バックアップ操作のハングを防止します [#57666](https://github.com/pingcap/tidb/issues/57666) @[3pointer](https://github.com/3pointer) @@ -320,7 +320,7 @@ TiDB をアップグレードする前に、オペレーティング システ - Debeziumプロトコル使用時にKafkaメッセージにキーフィールドが欠落する問題を修正 [#1799](https://github.com/pingcap/tiflow/issues/1799) @[wk989898](https://github.com/wk989898) - 再実行モジュールがエラーを正しく報告できない問題を修正 [#11744](https://github.com/pingcap/tiflow/issues/11744) @[CharlesCheung96](https://github.com/CharlesCheung96) - - TiDB DDL の所有者変更中に DDL タスクのスキーマ バージョンが非増分になった場合に TiCDC が誤って DDL タスクを破棄してしまう問題を修正しました [#11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) + - TiDB DDL の所有者変更中に DDL タスクのスキーマバージョンが非増分になった場合に TiCDC が誤って DDL タスクを破棄してしまう問題を修正しました [#11714](https://github.com/pingcap/tiflow/issues/11714) @[wlwilliamx](https://github.com/wlwilliamx) - TiDB Lightning diff --git a/releases/release-8.5.1.md b/releases/release-8.5.1.md index 64468297f8b9e..25d1618da849d 100644 --- a/releases/release-8.5.1.md +++ b/releases/release-8.5.1.md @@ -64,7 +64,7 @@ CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDB - `DROP DATABASE`ステートメントの実行後に統計情報がクリアされない問題を修正しました [#57230](https://github.com/pingcap/tidb/issues/57230) @[Rustin170506](https://github.com/Rustin170506) - `IndexMerge`を構築する際に一部の述語が失われる可能性がある問題を修正しました [#58476](https://github.com/pingcap/tidb/issues/58476) @[hawkingrei](https://github.com/hawkingrei) - 3000次元を超える列にベクトル検索インデックスを作成すると`KeyTooLong`エラーが発生する問題を修正 [#58836](https://github.com/pingcap/tidb/issues/58836) @[breezewish](https://github.com/breezewish) - - `REORGANIZE PARTITION`操作が置換されたグローバル インデックスを正しくクリーンアップせず、非クラスター化テーブルの一意インデックスを処理する問題を修正しました [#56822](https://github.com/pingcap/tidb/issues/56822) @[mjonss](https://github.com/mjonss) + - `REORGANIZE PARTITION`操作が置換されたグローバルインデックスを正しくクリーンアップせず、非クラスター化テーブルの一意インデックスを処理する問題を修正しました [#56822](https://github.com/pingcap/tidb/issues/56822) @[mjonss](https://github.com/mjonss) - パーティションテーブルの Range INTERVAL 構文糖衣が`MINUTE`間隔として使用できない問題を修正 [#57698](https://github.com/pingcap/tidb/issues/57698) @[mjonss](https://github.com/mjonss) - タイムゾーンを変更すると、スローログのクエリ時にクエリ結果が正しくなくなる問題を修正しました [#58452](https://github.com/pingcap/tidb/issues/58452) @[lcwangchao](https://github.com/lcwangchao) - スキャンタスクのTTLワーカーを縮小する際に、タスクキャンセルの失敗によってタスクがリークする可能性がある問題を修正しました [#57708](https://github.com/pingcap/tidb/issues/57708) @[YangKeao](https://github.com/YangKeao) diff --git a/releases/release-8.5.2.md b/releases/release-8.5.2.md index 8ef69185361e1..66c502de59be6 100644 --- a/releases/release-8.5.2.md +++ b/releases/release-8.5.2.md @@ -53,7 +53,7 @@ TiDBバージョン：8.5.2 - ログの秘匿化を有効にしても特定のシナリオで効果がない問題を修正 [#59279](https://github.com/pingcap/tidb/issues/59279) @[tangenta](https://github.com/tangenta) - `rowContainer`が特定のシナリオで TiDB をpanicする可能性がある問題を修正 [#59976](https://github.com/pingcap/tidb/issues/59976) @[YangKeao](https://github.com/YangKeao) - パーティション化されたテーブルの`Point_Get`シナリオでパーティションプルーニングが正しくない可能性がある問題を修正 [#59827](https://github.com/pingcap/tidb/issues/59827) @[mjonss](https://github.com/mjonss) - - DDL 実行中にパーティション テーブル内のレコードを更新するとデータ破損が発生する可能性がある問題を修正 [#57588](https://github.com/pingcap/tidb/issues/57588) @[Defined2014](https://github.com/Defined2014) + - DDL 実行中にパーティションテーブル内のレコードを更新するとデータ破損が発生する可能性がある問題を修正 [#57588](https://github.com/pingcap/tidb/issues/57588) @[Defined2014](https://github.com/Defined2014) - `information_schema`のパフォーマンスと安定性が特定のシナリオで影響を受ける問題を修正しました[#58142](https://github.com/pingcap/tidb/issues/58142) [#58363](https://github.com/pingcap/tidb/issues/58363) [#58712](https://github.com/pingcap/tidb/issues/58712) @[tiancaiamao](https://github.com/tiancaiamao) - 分散実行フレームワーク（DXF）が有効になっている場合、内部TiDBセッションで`tidb_txn_entry_size_limit`を動的に調整できない問題を修正します [#59506](https://github.com/pingcap/tidb/issues/59506) @[D3Hunter](https://github.com/D3Hunter) - `IMPORT INTO`機能がグローバルソートが有効になっている場合に一意キーの競合を適切に処理できない問題を修正します [#59650](https://github.com/pingcap/tidb/issues/59650) @[lance6716](https://github.com/lance6716) @@ -102,15 +102,15 @@ TiDBバージョン：8.5.2 - ソート中にデータが流出してTiFlashがクラッシュする可能性がある問題を修正 [#9999](https://github.com/pingcap/tiflash/issues/9999) @[windtalker](https://github.com/windtalker) - TiFlashが`Exception: Block schema mismatch`を含むSQL文を実行する際に`GROUP BY ... WITH ROLLUP`エラーを返す可能性がある問題を修正しました。 [#10110](https://github.com/pingcap/tiflash/issues/10110) @[gengliqi](https://github.com/gengliqi) - - 分散ストレージとコンピューティングアーキテクチャで、 TiFlashコンピューティング ノードがリージョンピアを追加するターゲット ノードとして誤って選択される可能性がある問題を修正 [#9750](https://github.com/pingcap/tiflash/issues/9750) @[JaySon-Huang](https://github.com/JaySon-Huang) - - 特定の状況でTiFlash が予期せず終了した場合に、エラー スタック トレースの出力に失敗することがある問題を修正 [#9902](https://github.com/pingcap/tiflash/issues/9902) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージとコンピューティングアーキテクチャで、 TiFlashコンピューティングノードがリージョンピアを追加するターゲットノードとして誤って選択される可能性がある問題を修正 [#9750](https://github.com/pingcap/tiflash/issues/9750) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 特定の状況でTiFlash が予期せず終了した場合に、エラースタック トレースの出力に失敗することがある問題を修正 [#9902](https://github.com/pingcap/tiflash/issues/9902) @[JaySon-Huang](https://github.com/JaySon-Huang) - 大量のデータをインポートした後にTiFlash が高いメモリ使用量を維持する可能性がある問題を修正 [#9812](https://github.com/pingcap/tiflash/issues/9812) @[CalvinNeo](https://github.com/CalvinNeo) - `profiles.default.init_thread_count_scale`が`0`に設定されている場合、 TiFlash の起動がブロックされる場合がある問題を修正 [#9906](https://github.com/pingcap/tiflash/issues/9906) @[JaySon-Huang](https://github.com/JaySon-Huang) - パーティションテーブルで`ALTER TABLE ... RENAME COLUMN`を実行した後、そのパーティションテーブルに対するクエリがエラーを返すことがある問題を修正 [#9787](https://github.com/pingcap/tiflash/issues/9787) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - クエリに仮想列が含まれ、リモート読み取りがトリガーされた場合に`Not found column`エラーが発生する可能性がある問題を修正 [#9561](https://github.com/pingcap/tiflash/issues/9561) @[guo-shaoge](https://github.com/guo-shaoge) - クラスター内のテーブルに多数の`ENUM`タイプのカラムが含まれている場合、 TiFlash が大量のメモリを消費する可能性がある問題を修正 [#9947](https://github.com/pingcap/tiflash/issues/9947) @[JaySon-Huang](https://github.com/JaySon-Huang) - 16 MiB を超えるデータを 1 行挿入するとTiFlash が再起動に失敗することがある問題を修正 [#10052](https://github.com/pingcap/tiflash/issues/10052) @[JaySon-Huang](https://github.com/JaySon-Huang) - - ベクトル インデックスを持つテーブルに新しいデータが挿入された後、 TiFlash が一部のディスク データを正しくクリーンアップできず、ディスク容量が異常に消費される問題を修正 [#9946](https://github.com/pingcap/tiflash/issues/9946) @[JaySon-Huang](https://github.com/JaySon-Huang) + - ベクトルインデックスを持つテーブルに新しいデータが挿入された後、 TiFlash が一部のディスク データを正しくクリーンアップできず、ディスク容量が異常に消費される問題を修正 [#9946](https://github.com/pingcap/tiflash/issues/9946) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashが同じテーブルに複数のベクトルインデックスを作成した後、以前に作成されたベクトルインデックスを予期せず削除し、パフォーマンスの低下を引き起こす可能性がある問題を修正しました [#9971](https://github.com/pingcap/tiflash/issues/9971) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlashが分散ストレージおよびコンピューティングアーキテクチャでベクトルインデックスを使用してベクトル検索クエリを高速化できない可能性がある問題を修正 [#9847](https://github.com/pingcap/tiflash/issues/9847) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlash が分散ストレージおよびコンピューティングアーキテクチャで大量の`tag=EnumParseOverflowContainer`ログを出力する可能性がある問題を修正 [#9955](https://github.com/pingcap/tiflash/issues/9955) @[JaySon-Huang](https://github.com/JaySon-Huang) diff --git a/releases/release-8.5.3.md b/releases/release-8.5.3.md index 9bbd8b263c714..9789acbc3ab13 100644 --- a/releases/release-8.5.3.md +++ b/releases/release-8.5.3.md @@ -24,7 +24,7 @@ TiDBバージョン：8.5.3 - 統計情報が完全に TopN で構成され、対応するテーブル統計情報の変更された行数がゼロでない場合、TopN に到達しない等価条件の推定結果を 0 から 1 に調整します。 [#47400](https://github.com/pingcap/tidb/issues/47400) @[terry1purcell](https://github.com/terry1purcell) - グローバルソートを使用した一意インデックスの追加パフォーマンスを改善し、重複する一意インデックスを追加する際のエラーメッセージを改善します [#61689](https://github.com/pingcap/tidb/issues/61689) @[CbcWestwolf](https://github.com/CbcWestwolf) - `IMPORT INTO`がグローバルソートを有効にしている場合、TiKV のインポートモードへの切り替えを無効にする [#60361](https://github.com/pingcap/tidb/issues/60361) @[D3Hunter](https://github.com/D3Hunter) - - インデックス追加中の TiKV への書き込み速度を監視するためのモニタリング メトリックを追加 [#60925](https://github.com/pingcap/tidb/issues/60925) @[CbcWestwolf](https://github.com/CbcWestwolf) + - インデックス追加中の TiKV への書き込み速度を監視するためのモニタリングメトリックを追加 [#60925](https://github.com/pingcap/tidb/issues/60925) @[CbcWestwolf](https://github.com/CbcWestwolf) - `merge sort`サブタスクのスケジューリングロジックを最適化してソートパフォーマンスを向上させる [#60375](https://github.com/pingcap/tidb/issues/60375) @[tangenta](https://github.com/tangenta) - 外部キーを持つ多数のテーブルを作成する際のテーブル作成を高速化し、メモリ使用効率を最適化する [#61126](https://github.com/pingcap/tidb/issues/61126) @[GMHDBJD](https://github.com/GMHDBJD) - `information_schema.tables` テーブルの読み取りパフォーマンスを改善します [#62020](https://github.com/pingcap/tidb/issues/62020) @[tangenta](https://github.com/tangenta) @@ -61,8 +61,8 @@ TiDBバージョン：8.5.3 - Backup & Restore (BR) - PITR中のインデックス修復速度を向上させるため、インデックスを同時修復する [#59158](https://github.com/pingcap/tidb/issues/59158) @[Leavrth](https://github.com/Leavrth) - - TiKV のダウンロード API は、バックアップ ファイルをダウンロードする際に、特定の時間範囲内のデータをフィルタリングして除外することをサポートしています。これにより、復元中に古いバージョンまたは将来のデータ バージョンがインポートされるのを回避できます [#18399](https://github.com/tikv/tikv/issues/18399) @[3pointer](https://github.com/3pointer) - - タイムスタンプによるログ バックアップ メタデータ ファイルのフィルタリングをサポートし、PITR 中のメタデータの読み取りにかかる時間を削減します [#61318](https://github.com/pingcap/tidb/issues/61318) @[3pointer](https://github.com/3pointer) + - TiKV のダウンロード API は、バックアップファイルをダウンロードする際に、特定の時間範囲内のデータをフィルタリングして除外することをサポートしています。これにより、復元中に古いバージョンまたは将来のデータバージョンがインポートされるのを回避できます [#18399](https://github.com/tikv/tikv/issues/18399) @[3pointer](https://github.com/3pointer) + - タイムスタンプによるログバックアップメタデータファイルのフィルタリングをサポートし、PITR 中のメタデータの読み取りにかかる時間を削減します [#61318](https://github.com/pingcap/tidb/issues/61318) @[3pointer](https://github.com/3pointer) ## バグ修正 {#bug-fixes} @@ -84,7 +84,7 @@ TiDBバージョン：8.5.3 - メタデータロック（MDL）を無効にした後、スキーマバージョンの更新に失敗してDDL操作が停止する問題を修正しました [#61210](https://github.com/pingcap/tidb/issues/61210) @[wjhuang2016](https://github.com/wjhuang2016) - 非公開インデックスが統計システムテーブルに表示される問題を修正 [#60430](https://github.com/pingcap/tidb/issues/60430) @[tangenta](https://github.com/tangenta) - HashAgg演算子におけるメモリ追跡の誤りにより、大量のエラーログが発生する問題を修正しました [#58822](https://github.com/pingcap/tidb/issues/58822) @[xzhangxian1008](https://github.com/xzhangxian1008) - - HashAgg オペレーターでディスク スピル中に`nil`内の`basePartialResult4GroupConcat`バッファがpanicを引き起こす問題を修正しました [#61749](https://github.com/pingcap/tidb/issues/61749) @[xzhangxian1008](https://github.com/xzhangxian1008) + - HashAgg オペレーターでディスクスピル中に`nil`内の`basePartialResult4GroupConcat`バッファがpanicを引き起こす問題を修正しました [#61749](https://github.com/pingcap/tidb/issues/61749) @[xzhangxian1008](https://github.com/xzhangxian1008) - 集計式のエンコードロジックにおける誤った戻り値がクエリ実行中にpanicを引き起こす問題を修正 [#61735](https://github.com/pingcap/tidb/issues/61735) @[YangKeao](https://github.com/YangKeao) - HashJoin演算子がメモリの過剰使用によりゴルーチンリークを引き起こす問題を修正 [#60926](https://github.com/pingcap/tidb/issues/60926) @[xzhangxian1008](https://github.com/xzhangxian1008) - `IndexMerge`および`IndexLookUp`オペレーターで共有 KV リクエストがクエリのプッシュダウン時にデータ競合を引き起こす問題を修正しました [#60175](https://github.com/pingcap/tidb/issues/60175) @[you06](https://github.com/you06) diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index c788e9ed90daa..d8f2697bf8ee0 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -111,7 +111,7 @@ TiDBバージョン：8.5.4 - 不要なアラートを減らすため、特定の TiKV エラーのログレベルを`ERROR`から`WARN`に変更します [#18745](https://github.com/tikv/tikv/issues/18745) @[exit-code-1](https://github.com/exit-code-1) - RaftモジュールのGCチェックプロセスを2つのフェーズに分割し、リージョン内の冗長なMVCCバージョンのガベージコレクションの効率を向上させる [#18695](https://github.com/tikv/tikv/issues/18695) @[v01dstar](https://github.com/v01dstar) - GCセーフポイントとRocksDB統計に基づいてMVCC冗長性を計算し、圧縮の効率と精度を向上させる [#18697](https://github.com/tikv/tikv/issues/18697) @[v01dstar](https://github.com/v01dstar) - - リージョン MVCC の GC 処理ロジックを GC ワーカー スレッドで実行するように変更し、GC 処理ロジック全体を統一します [#18727](https://github.com/tikv/tikv/issues/18727) @[v01dstar](https://github.com/v01dstar) + - リージョン MVCC の GC 処理ロジックを GC ワーカースレッドで実行するように変更し、GC 処理ロジック全体を統一します [#18727](https://github.com/tikv/tikv/issues/18727) @[v01dstar](https://github.com/v01dstar) - デフォルトのgRPCスレッドプールサイズの計算方法を最適化し、固定値ではなくCPUクォータの合計に基づいて動的に計算するようにすることで、gRPCスレッド不足によるパフォーマンスボトルネックを回避します [#18613](https://github.com/tikv/tikv/issues/18613) @[LykxSassinator](https://github.com/LykxSassinator) - 多数のSSTファイルが存在する環境における非同期スナップショットおよび書き込み操作のテールレイテンシーを最適化する [#18743](https://github.com/tikv/tikv/issues/18743) @[Connor1996](https://github.com/Connor1996) @@ -125,7 +125,7 @@ TiDBバージョン：8.5.4 - `TableScan`パフォーマンスを向上させるために不要なデータ読み取りをスキップします [#9875](https://github.com/pingcap/tiflash/issues/9875) @[gengliqi](https://github.com/gengliqi) - TiFlashで、多くの列とスパースデータ (つまり、大量の`NULL`または空の値) を含む広いテーブルでの`TableScan`パフォーマンスを最適化します [#10361](https://github.com/pingcap/tiflash/issues/10361) @[JaySon-Huang](https://github.com/JaySon-Huang) - - 多数のテーブルを持つクラスターにベクトル インデックスを追加することによって生じるTiFlash CPU オーバーヘッドを削減 [#10357](https://github.com/pingcap/tiflash/issues/10357) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 多数のテーブルを持つクラスターにベクトルインデックスを追加することによって生じるTiFlash CPU オーバーヘッドを削減 [#10357](https://github.com/pingcap/tiflash/issues/10357) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - 無駄なRaftコマンド処理時の不要なログ出力を最小限にしてログ容量を削減 [#10467](https://github.com/pingcap/tiflash/issues/10467) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashの小さなパーティション分割テーブルでの`TableScan`パフォーマンスを向上 [#10487](https://github.com/pingcap/tiflash/issues/10487) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -192,7 +192,7 @@ TiDBバージョン：8.5.4 - Backup & Restore (BR) - - ログ バックアップの zstd 圧縮が有効にならず、出力が圧縮されないままになる問題を修正 [#18836](https://github.com/tikv/tikv/issues/18836) @[3pointer](https://github.com/3pointer) + - ログバックアップの zstd 圧縮が有効にならず、出力が圧縮されないままになる問題を修正 [#18836](https://github.com/tikv/tikv/issues/18836) @[3pointer](https://github.com/3pointer) - Azure Blob Storageへのデータバックアップ時にフラッシュ操作が時々遅くなる問題を修正 [#18410](https://github.com/tikv/tikv/issues/18410) @[YuJuncen](https://github.com/YuJuncen) - ファイル削除が失敗した場合に`log truncate`が発生する可能性がある問題を修正 [#63358](https://github.com/pingcap/tidb/issues/63358) @[YuJuncen](https://github.com/YuJuncen) - バックアップ中に`--checksum`を`false`に設定すると、リストア後に`count`テーブルの`mysql.stats_meta`列が`0`になる可能性がある問題を修正 [#60978](https://github.com/pingcap/tidb/issues/60978) @[Leavrth](https://github.com/Leavrth) diff --git a/releases/release-8.5.5.md b/releases/release-8.5.5.md index 5bfb21bd3a75b..f923e7103e6bf 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 のメモリで構成されています。 | シナリオ | 操作タイプ | 最適化前 | 最適化後 | パフォーマンスの向上 | | --------- | ------------------------- | ------ | ------ | ---------- | @@ -53,9 +53,9 @@ TiDBバージョン：8.5.5 - テーブルレベルのデータアフィニティをサポートしてクエリのパフォーマンスを向上させる（実験的） [#9764](https://github.com/tikv/pd/issues/9764) @[lhy1024](https://github.com/lhy1024) - バージョン 8.5.5 以降では、テーブルの作成または変更時に`AFFINITY`テーブル オプションを`table`または`partition`として構成できます。このオプションを有効にすると、PD は同じテーブルまたは同じパーティションに属するリージョンを単一のアフィニティ グループにグループ化します。スケジューリング中、PD はこれらのリージョンのリーダー レプリカと投票者レプリカを少数の TiKV ノードの同じサブセットに配置することを優先します。このシナリオでは、クエリで[`INDEX_LOOKUP_PUSHDOWN`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855)ヒントを使用することで、オプティマイザにインデックス ルックアップを TiKV にプッシュダウンするように明示的に指示でき、ノード間分散クエリによって発生するレイテンシーを削減し、クエリ パフォーマンスを向上させることができます。 + バージョン 8.5.5 以降では、テーブルの作成または変更時に`AFFINITY`テーブルオプションを`table`または`partition`として構成できます。このオプションを有効にすると、PD は同じテーブルまたは同じパーティションに属するリージョンを単一のアフィニティグループにグループ化します。スケジューリング中、PD はこれらのリージョンのリーダーレプリカと投票者レプリカを少数の TiKV ノードの同じサブセットに配置することを優先します。このシナリオでは、クエリで[`INDEX_LOOKUP_PUSHDOWN`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855)ヒントを使用することで、オプティマイザにインデックスルックアップを TiKV にプッシュダウンするように明示的に指示でき、ノード間分散クエリによって発生するレイテンシーを削減し、クエリパフォーマンスを向上させることができます。 - この機能は現在実験的であり、デフォルトでは無効になっています。有効にするには、PD 設定項目[`schedule.affinity-schedule-limit`](https://docs.pingcap.com/tidb/v8.5/pd-configuration-file#affinity-schedule-limit-new-in-v855)を`0`より大きい値に設定してください。この設定項目は、PD が同時に実行できるアフィニティ スケジューリング タスクの最大数を制御します。 + この機能は現在実験的であり、デフォルトでは無効になっています。有効にするには、PD 設定項目[`schedule.affinity-schedule-limit`](https://docs.pingcap.com/tidb/v8.5/pd-configuration-file#affinity-schedule-limit-new-in-v855)を`0`より大きい値に設定してください。この設定項目は、PD が同時に実行できるアフィニティスケジューリング タスクの最大数を制御します。 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/table-affinity)を参照してください。 @@ -109,13 +109,13 @@ TiDBバージョン：8.5.5 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#graceful-shutdown-timeout-new-in-v855)を参照してください。 -- 進行中のログ バックアップとスナップショットの復元の間の互換性を向上 [#58685](https://github.com/pingcap/tidb/issues/58685) @[BornChanger](https://github.com/BornChanger) +- 進行中のログバックアップとスナップショットの復元の間の互換性を向上 [#58685](https://github.com/pingcap/tidb/issues/58685) @[BornChanger](https://github.com/BornChanger) バージョン8.5.5以降では、ログバックアップタスクの実行中でも、前提条件を満たしていればスナップショット復元を実行できます。これにより、復元処理中に進行中のログバックアップを停止することなく続行でき、復元されたデータは進行中のログバックアップに正しく記録されます。 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/br-pitr-manual#compatibility-between-ongoing-log-backup-and-snapshot-restore)を参照してください。 -- ログ バックアップからのテーブル レベルの復元をサポート [#57613](https://github.com/pingcap/tidb/issues/57613) @[Tristan1900](https://github.com/Tristan1900) +- ログバックアップからのテーブルレベルの復元をサポート [#57613](https://github.com/pingcap/tidb/issues/57613) @[Tristan1900](https://github.com/Tristan1900) バージョン8.5.5以降では、フィルタを使用してログバックアップから個々のテーブルのポイントインタイムリカバリ（PITR）を実行できます。クラスタ全体ではなく特定のテーブルを特定の時点に復元することで、より柔軟で影響の少ないリカバリオプションが提供されます。 @@ -272,7 +272,7 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま - グローバルソートを有効にして`IMPORT INTO`を実行すると、ファイルの読み込み中に無限ループが発生する問題を修正しました [#61177](https://github.com/pingcap/tidb/issues/61177) @[CbcWestwolf](https://github.com/CbcWestwolf) - `IMPORT INTO`の処理中に生成列を処理する際にpanicが発生する問題を修正しました [#64657](https://github.com/pingcap/tidb/issues/64657) @[D3Hunter](https://github.com/D3Hunter) - 単一の SQL ステートメントに複数の`AS OF TIMESTAMP`が含まれている場合にエラーが誤って報告される可能性がある問題を修正しました [#65090](https://github.com/pingcap/tidb/issues/65090) @[you06](https://github.com/you06) - - `information_schema.tables`をクエリする際に発生する可能性のある OOM 問題を修正するため、システム テーブルをクエリする際のメモリ使用量の監視を改善しました [#58985](https://github.com/pingcap/tidb/issues/58985) @[tangenta](https://github.com/tangenta) + - `information_schema.tables`をクエリする際に発生する可能性のある OOM 問題を修正するため、システムテーブルをクエリする際のメモリ使用量の監視を改善しました [#58985](https://github.com/pingcap/tidb/issues/58985) @[tangenta](https://github.com/tangenta) - `client-go`の潜在的なメモリリークを修正 [#65522](https://github.com/pingcap/tidb/issues/65522) @[bufferflies](https://github.com/bufferflies) - TiKV diff --git a/releases/release-8.5.6.md b/releases/release-8.5.6.md index 543758efa171e..5bcb83e945178 100644 --- a/releases/release-8.5.6.md +++ b/releases/release-8.5.6.md @@ -53,7 +53,7 @@ TiDBバージョン：8.5.6 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/column-privilege-management)を参照してください。 -- `FOR UPDATE OF`句でのテーブル エイリアスの使用をサポート [#63035](https://github.com/pingcap/tidb/issues/63035) @[cryo-zd](https://github.com/cryo-zd) +- `FOR UPDATE OF`句でのテーブルエイリアスの使用をサポート [#63035](https://github.com/pingcap/tidb/issues/63035) @[cryo-zd](https://github.com/cryo-zd) v8.5.6 より前のバージョンでは、 `SELECT ... FOR UPDATE OF `ステートメントがロック句でテーブルエイリアスを参照する場合、エイリアスが有効であっても、TiDB がエイリアスを正しく解決できず、 `table not exists`エラーを返すことがありました。 @@ -82,7 +82,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 ### MySQLとの互換性 {#mysql-compatibility} - バージョン8.5.6以降、TiDBはMySQL互換の列レベルの権限管理メカニズムをサポートしています。テーブルレベルで特定の列に対して、 `SELECT` 、 `INSERT` 、 `UPDATE` 、および`REFERENCES`の権限または取り消すことができます。詳細については、 [列レベルの権限管理](https://docs.pingcap.com/tidb/v8.5/column-privilege-management)を参照してください。 -- バージョン 8.5.6 以降、TiDB は`FOR UPDATE OF`句でテーブル エイリアスの使用をサポートしています。下位互換性を維持するために、エイリアスが定義されている場合でもベース テーブル名を参照できますが、明示的なエイリアスの使用を推奨する警告が表示されます。詳細については、 [`SELECT`](https://docs.pingcap.com/tidb/v8.5/sql-statement-select)を参照してください。 +- バージョン 8.5.6 以降、TiDB は`FOR UPDATE OF`句でテーブルエイリアスの使用をサポートしています。下位互換性を維持するために、エイリアスが定義されている場合でもベース テーブル名を参照できますが、明示的なエイリアスの使用を推奨する警告が表示されます。詳細については、 [`SELECT`](https://docs.pingcap.com/tidb/v8.5/sql-statement-select)を参照してください。 - バージョン8.5.6以降、 Dumplingは更新されたMySQLバイナリログの命名に対応することで、MySQL 8.4からのデータエクスポートをサポートしています。 [#53082](https://github.com/pingcap/tidb/issues/53082) @[dveeden](https://github.com/dveeden) - バージョン8.5.6以降、TiDB Data Migration (DM) は、このバージョンで導入された新しい用語とバージョン検出ロジックに対応することで、アップストリームデータソースとしてMySQL 8.4をサポートします。 [#11020](https://github.com/pingcap/tiflow/issues/11020) @[dveeden](https://github.com/dveeden) diff --git a/releases/release-rc.3.md b/releases/release-rc.3.md index 975aa608fb03a..563173ea1d141 100644 --- a/releases/release-rc.3.md +++ b/releases/release-rc.3.md @@ -9,7 +9,7 @@ summary: 2017年6月16日にリリースされたTiDB RC3は、MySQLとの互換 ## ハイライト {#highlight} -- 権限管理が改良され、ユーザーは MySQL と同じ方法でデータ アクセス権限を管理できるようになりました。 +- 権限管理が改良され、ユーザーは MySQL と同じ方法でデータアクセス権限を管理できるようになりました。 - DDL が加速されます。 - 負荷分散ポリシーとプロセスはパフォーマンスのために最適化されています。 - TiDB Ansibleはオープンソースです。TiDB Ansibleを使用すると、ワンクリックでTiDBクラスターのデプロイ、アップグレード、起動、シャットダウンが可能です。 @@ -58,4 +58,4 @@ summary: 2017年6月16日にリリースされたTiDB RC3は、MySQLとの互換 - バッチ適用を使用してCPU使用量を削減し、書き込みパフォーマンスを向上させます - トランザクションの書き込み速度を向上させるために並列プリライトをサポート - コプロセッサスレッドプールのスケジュールを最適化して、PointGetに対する大きなクエリの影響を軽減します。 -- 新しいローダーは、テーブル レベルでのデータのインポートをサポートするほか、大きなテーブルを小さな論理ブロックに分割して同時にインポートすることで、データのインポート速度を向上させます。 +- 新しいローダーは、テーブルレベルでのデータのインポートをサポートするほか、大きなテーブルを小さな論理ブロックに分割して同時にインポートすることで、データのインポート速度を向上させます。 diff --git a/releases/versioning.md b/releases/versioning.md index 7a17931567595..fcb2aa02d1d15 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -7,7 +7,7 @@ summary: TiDB のバージョン番号付けシステムについて学習しま -リリース シリーズの最新のパッチ リリースに常にアップグレードすることをお勧めします。 +リリース シリーズの最新のパッチリリースに常にアップグレードすることをお勧めします。 @@ -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..6f861b4060133 100644 --- a/replicate-between-primary-and-secondary-clusters.md +++ b/replicate-between-primary-and-secondary-clusters.md @@ -152,7 +152,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー 1 row in set (2.11 sec) ``` - `BACKUP`コマンドが実行されると、TiDB はバックアップ データに関するメタデータを返します。 `BackupTS`には、それ以前に生成されたデータがバックアップされるため、注意してください。このドキュメントでは、 `BackupTS`**データ チェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 + `BACKUP`コマンドが実行されると、TiDB はバックアップデータに関するメタデータを返します。 `BackupTS`には、それ以前に生成されたデータがバックアップされるため、注意してください。このドキュメントでは、 `BackupTS`**データチェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 3. データを復元します。 @@ -173,7 +173,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー 4. （オプション）データの検証。 - [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用して、特定の時刻におけるアップストリームとダウンストリーム間のデータの一貫性を確認します。前述の`BACKUP`出力は、アップストリーム クラスタが 431434047157698561 にバックアップを完了したことを示しています。前述の`RESTORE`出力は、ダウンストリームが 431434141450371074 にリストアを完了したことを示しています。 + [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用して、特定の時刻におけるアップストリームとダウンストリーム間のデータの一貫性を確認します。前述の`BACKUP`出力は、アップストリームクラスタが 431434047157698561 にバックアップを完了したことを示しています。前述の`RESTORE`出力は、ダウンストリームが 431434141450371074 にリストアを完了したことを示しています。 ```shell sync_diff_inspector -C ./config.yaml @@ -215,7 +215,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー 1. TiCDCをデプロイ。 - データの完全移行が完了したら、増分データを複製するために TiCDC をデプロイして構成します。本番環境では、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md)の手順に従ってデプロイしてください。このドキュメントでは、テスト クラスターの作成時に TiCDC ノードが起動されているため、TiCDC のデプロイ手順は省略し、changefeed の構成に進みます。 + データの完全移行が完了したら、増分データを複製するために TiCDC をデプロイして構成します。本番環境では、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md)の手順に従ってデプロイしてください。このドキュメントでは、テストクラスターの作成時に TiCDC ノードが起動されているため、TiCDC のデプロイ手順は省略し、changefeed の構成に進みます。 2. 変更フィードを作成します。 diff --git a/resources/doc-templates/template-new-feature.md b/resources/doc-templates/template-new-feature.md index 29dbc963580c0..37ffb95d0dd5b 100644 --- a/resources/doc-templates/template-new-feature.md +++ b/resources/doc-templates/template-new-feature.md @@ -109,7 +109,7 @@ FAQ が多数ある場合は、この機能用に個別のFAQドキュメント このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 +- TiFlash のバージョン、重要なログ、システムテーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 - TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 diff --git a/resources/doc-templates/template-task.md b/resources/doc-templates/template-task.md index 69603f9c5c017..80bf7989901ce 100644 --- a/resources/doc-templates/template-task.md +++ b/resources/doc-templates/template-task.md @@ -117,7 +117,7 @@ summary: このドキュメントを115～145文字で要約してください このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 +- TiFlash のバージョン、重要なログ、システムテーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 - TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 diff --git a/resources/tidb-pdf-generation-tutorial.md b/resources/tidb-pdf-generation-tutorial.md index 99a7b0987d9ac..89ff157a04ffd 100644 --- a/resources/tidb-pdf-generation-tutorial.md +++ b/resources/tidb-pdf-generation-tutorial.md @@ -74,7 +74,7 @@ TiDB 英語ドキュメントリポジトリ: [https://github.com/pingcap/docs]( 2. 必要に応じて、TiDB ドキュメントの内容を並べ替えたり削除したりします。 - 1. ローカル リポジトリのルート ディレクトリにある`TOC.md`ファイルを開きます。 + 1. ローカル リポジトリのルートディレクトリにある`TOC.md`ファイルを開きます。 2. `TOC.md`ファイルを編集します。例えば、不要なドキュメントの章のタイトルとリンクをすべて削除できます。 3. `TOC.md`ファイルに従って、すべてのドキュメントの章を 1 つの Markdown ファイルに統合します。 diff --git a/role-based-access-control.md b/role-based-access-control.md index 581cbc90e4086..af6504f82e9fa 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -186,7 +186,7 @@ SET DEFAULT ROLE app_read, app_write TO 'rw_user1'@'localhost'; SET DEFAULT ROLE ALL TO 'dev1'@'localhost'; ``` -次のステートメントを使用して、 `dev1@localhost`のすべてのデフォルト ロールを無効にすることができます。 +次のステートメントを使用して、 `dev1@localhost`のすべてのデフォルトロールを無効にすることができます。 ```sql SET DEFAULT ROLE NONE TO 'dev1'@'localhost'; @@ -194,7 +194,7 @@ SET DEFAULT ROLE NONE TO 'dev1'@'localhost'; > **Note:** > -> このロールにデフォルト ロールを設定する前に、ユーザーにロールを付与する必要があります。 +> このロールにデフォルトロールを設定する前に、ユーザーにロールを付与する必要があります。 ### 現在のセッションでロールを有効にする {#enable-a-role-in-the-current-session} @@ -216,7 +216,7 @@ SET ROLE { SET ROLE 'app_read', 'app_write'; ``` -現在のユーザーのデフォルト ロールを有効にするには、次のステートメントを使用できます。 +現在のユーザーのデフォルトロールを有効にするには、次のステートメントを使用できます。 ```sql SET ROLE DEFAULT @@ -364,7 +364,7 @@ SELECT * FROM mysql.default_roles; ``` - `HOST`と`USER`それぞれユーザーのホスト名とユーザー名を示します。 -- `DEFAULT_ROLE_HOST`と`DEFAULT_ROLE_USER` 、それぞれデフォルト ロールのホスト名とユーザー名を示します。 +- `DEFAULT_ROLE_HOST`と`DEFAULT_ROLE_USER` 、それぞれデフォルトロールのホスト名とユーザー名を示します。 ### リファレンス {#references} diff --git a/runtime-filter.md b/runtime-filter.md index e741700970b8b..e1b877bea94e6 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -1,6 +1,6 @@ --- title: Runtime Filter -summary: ランタイム フィルターの動作原理とその使用方法を学びます。 +summary: ランタイムフィルターの動作原理とその使用方法を学びます。 --- # ランタイムフィルター {#runtime-filter} @@ -50,7 +50,7 @@ WHERE ss_date_sk = d_date_sk *（上図では交換ノードとその他のノードを省略しています。）* -ランタイム フィルターの実行プロセスは次のとおりです。 +ランタイムフィルターの実行プロセスは次のとおりです。 1. `date_dim`テーブルのデータをスキャンします。 2. `PhysicalHashJoin` `date_dim in (2001/01/01~2001/12/31)`などのビルド側のデータに基づいてフィルター条件を計算します。 @@ -76,13 +76,13 @@ 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} -ランタイム フィルターを使用するには、 TiFlashレプリカを含むテーブルを作成し、 [`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)を`LOCAL`に設定する必要があります。 +ランタイムフィルターを使用するには、 TiFlashレプリカを含むテーブルを作成し、 [`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)を`LOCAL`に設定する必要があります。 -このセクションでは、TPC-DS データセットを例に、結合操作にテーブル`catalog_sales`とテーブル`date_dim`を使用して、ランタイム フィルターによってクエリ効率がどのように向上するかを説明します。 +このセクションでは、TPC-DS データセットを例に、結合操作にテーブル`catalog_sales`とテーブル`date_dim`を使用して、ランタイムフィルターによってクエリ効率がどのように向上するかを説明します。 ### ステップ1. 結合するテーブルのTiFlashレプリカを作成する {#step-1-create-tiflash-replicas-for-tables-to-be-joined} @@ -113,7 +113,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA WHERE TABLE_NAME='date_dim'; ### ステップ2. ランタイムフィルターを有効にする {#step-2-enable-runtime-filter} -ランタイム フィルターを有効にするには、システム変数[`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)の値を`LOCAL`に設定します。 +ランタイムフィルターを有効にするには、システム変数[`tidb_runtime_filter_mode`](/system-variables.md#tidb_runtime_filter_mode-new-in-v720)の値を`LOCAL`に設定します。 ```sql SET tidb_runtime_filter_mode="LOCAL"; @@ -130,11 +130,11 @@ SHOW VARIABLES LIKE "tidb_runtime_filter_mode"; +--------------------------+-------+ ``` -システム変数の値が`LOCAL`の場合、ランタイム フィルターは有効になります。 +システム変数の値が`LOCAL`の場合、ランタイムフィルターは有効になります。 ### ステップ3. クエリを実行する {#step-3-execute-the-query} -クエリを実行する前に、 [`EXPLAIN`文](/sql-statements/sql-statement-explain.md)を使用して実行計画を表示し、ランタイム フィルターが有効になっているかどうかを確認します。 +クエリを実行する前に、 [`EXPLAIN`文](/sql-statements/sql-statement-explain.md)を使用して実行計画を表示し、ランタイムフィルターが有効になっているかどうかを確認します。 ```sql EXPLAIN SELECT cs_ship_date_sk FROM catalog_sales, date_dim @@ -142,7 +142,7 @@ WHERE d_date = '2002-2-01' AND cs_ship_date_sk = d_date_sk; ``` -ランタイム フィルターが有効になると、対応するランタイム フィルターがノード`HashJoin`とノード`TableScan`にマウントされ、ランタイム フィルターが正常に適用されたことが示されます。 +ランタイムフィルターが有効になると、対応するランタイムフィルターがノード`HashJoin`とノード`TableScan`にマウントされ、ランタイムフィルターが正常に適用されたことが示されます。 ``` TableFullScan: runtime filter:0[IN] -> tpcds50.catalog_sales.cs_ship_date_sk @@ -168,7 +168,7 @@ HashJoin: runtime filter:0[IN] <- tpcds50.date_dim.d_date_sk | 9 rows in set (0.01 sec) ``` -ここで、SQL クエリを実行すると、ランタイム フィルターが適用されます。 +ここで、SQL クエリを実行すると、ランタイムフィルターが適用されます。 ```sql SELECT cs_ship_date_sk FROM catalog_sales, date_dim @@ -180,7 +180,7 @@ WHERE d_date = '2002-2-01' AND この例では、50 GBのTPC-DSデータを使用しています。ランタイムフィルターを有効にすると、クエリ時間は0.38秒から0.17秒に短縮され、効率は 50 %向上します。`ANALYZE`ステートメントを使用すると、ランタイムフィルター有効後の各演算子の実行時間を確認できます。 -ランタイム フィルターが有効になっていない場合のクエリの実行情報は次のとおりです。 +ランタイムフィルターが有効になっていない場合のクエリの実行情報は次のとおりです。 ```sql EXPLAIN ANALYZE SELECT cs_ship_date_sk FROM catalog_sales, date_dim WHERE d_date = '2002-2-01' AND cs_ship_date_sk = d_date_sk; @@ -200,7 +200,7 @@ EXPLAIN ANALYZE SELECT cs_ship_date_sk FROM catalog_sales, date_dim WHERE d_date 9 rows in set (0.38 sec) ``` -ランタイム フィルターが有効な場合のクエリの実行情報は次のとおりです。 +ランタイムフィルターが有効な場合のクエリの実行情報は次のとおりです。 ```sql EXPLAIN ANALYZE SELECT cs_ship_date_sk FROM catalog_sales, date_dim @@ -224,7 +224,7 @@ EXPLAIN ANALYZE SELECT cs_ship_date_sk FROM catalog_sales, date_dim 2 つのクエリの実行情報を比較すると、次の改善点がわかります。 -- IO 削減: TableFullScan 演算子の`total_scanned_rows`比較すると、ランタイム フィルターを有効にすると`TableFullScan`のスキャン量が 2/3 削減されることがわかります。 +- IO 削減: TableFullScan 演算子の`total_scanned_rows`比較すると、ランタイムフィルターを有効にすると`TableFullScan`のスキャン量が 2/3 削減されることがわかります。 - ハッシュ結合のパフォーマンス向上: `HashJoin`演算子の実行時間が 376.1 ミリ秒から 157.6 ミリ秒に短縮されました。 ### ベストプラクティス {#best-practices} @@ -235,7 +235,7 @@ TPC-DS におけるテーブル`Sales`とテーブル`date_dim`の結合操作 ## ランタイムフィルターを構成する {#configure-runtime-filter} -ランタイム フィルターを使用する場合、ランタイム フィルターのモードと述語タイプを構成できます。 +ランタイムフィルターを使用する場合、ランタイムフィルターのモードと述語タイプを構成できます。 ### ランタイムフィルターモード {#runtime-filter-mode} @@ -253,8 +253,8 @@ TPC-DS におけるテーブル`Sales`とテーブル`date_dim`の結合操作 ## 制限事項 {#limitations} -- ランタイム フィルターは MPPアーキテクチャの最適化であり、 TiFlashにプッシュダウンされたクエリにのみ適用できます。 +- ランタイムフィルターは MPPアーキテクチャの最適化であり、 TiFlashにプッシュダウンされたクエリにのみ適用できます。 - 結合タイプ：左外部結合、完全外部結合、およびアンチ結合（左テーブルがプローブ側の場合）は、ランタイムフィルターをサポートしていません。ランタイムフィルターは結合に関係するデータを事前にフィルタリングするため、上記の結合タイプでは不一致データが破棄されず、ランタイムフィルターは使用できません。 - 等価結合式：等価結合式内のプローブ列が複雑な式である場合、またはプローブ列の型がJSON、Blob、配列などの複雑なデータ型である場合、ランタイムフィルターは生成されません。主な理由は、これらの型の列が結合列として使用されることはほとんどないためです。フィルターが生成されたとしても、フィルタリング率は通常低くなります。 -上記の制限事項について、ランタイム フィルターが正しく生成されたかどうかを確認する必要がある場合は、 [`EXPLAIN`文](/sql-statements/sql-statement-explain.md)を使用して実行計画を検証できます。 +上記の制限事項について、ランタイムフィルターが正しく生成されたかどうかを確認する必要がある場合は、 [`EXPLAIN`文](/sql-statements/sql-statement-explain.md)を使用して実行計画を検証できます。 diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index 4071b50ac8ca8..cabe338a729f4 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -114,7 +114,7 @@ tiup cluster display > **Note:** > -> PD マイクロサービスが有効になっているクラスターを非マイクロサービス モードに切り替える必要がある場合は、代わりに[マイクロサービスモードから通常モードに切り替える](#switch-from-microservices-mode-to-regular-mode)の手順に従ってください。 +> PD マイクロサービスが有効になっているクラスターを非マイクロサービスモードに切り替える必要がある場合は、代わりに[マイクロサービスモードから通常モードに切り替える](#switch-from-microservices-mode-to-regular-mode)の手順に従ってください。 このセクションでは、複数の TSO ノードまたはスケジューリング ノードを持つ TiDB クラスターから TSO ノード (IP アドレス`10.0.1.8` ) とスケジューリング ノード (IP アドレス`10.0.1.9` ) を削除する方法を例示します。 @@ -205,7 +205,7 @@ PD サービスを次の 2 つの動作モード間で切り替えることが ### 通常モードからマイクロサービスモードに切り替える {#switch-from-regular-mode-to-microservices-mode} -PD マイクロサービスが有効になっていないクラスターの場合は、次のように PD マイクロサービス モードに切り替えて、TSO ノード (IP アドレス`10.0.1.8` ) とスケジューリング ノード (IP アドレス`10.0.1.9` ) を追加できます。 +PD マイクロサービスが有効になっていないクラスターの場合は、次のように PD マイクロサービスモードに切り替えて、TSO ノード (IP アドレス`10.0.1.8` ) とスケジューリング ノード (IP アドレス`10.0.1.9` ) を追加できます。 1. `scale-out.yml`ファイルにスケールアウト トポロジ構成を追加します。 @@ -224,7 +224,7 @@ PD マイクロサービスが有効になっていないクラスターの場 port: 3379 ``` -2. クラスター構成を変更し、クラスターを PD マイクロサービス モードに切り替えます。 +2. クラスター構成を変更し、クラスターを PD マイクロサービスモードに切り替えます。 ```shell tiup cluster edit-config @@ -245,7 +245,7 @@ PD マイクロサービスが有効になっていないクラスターの場 pd_mode: ms ``` -3. PD ノード構成のローリング アップデートを実行します。 +3. PD ノード構成のローリングアップデートを実行します。 ```shell tiup cluster reload -R pd @@ -263,9 +263,9 @@ PD マイクロサービスが有効になっていないクラスターの場 ### マイクロサービスモードから通常モードに切り替える {#switch-from-microservices-mode-to-regular-mode} -PD マイクロサービスが有効になっているクラスター (IP アドレス`10.0.1.8`に TSO ノードがあり、IP アドレス`10.0.1.9`にスケジューリング ノードがあると想定) の場合は、次のように非マイクロサービス モードに切り替えることができます。 +PD マイクロサービスが有効になっているクラスター (IP アドレス`10.0.1.8`に TSO ノードがあり、IP アドレス`10.0.1.9`にスケジューリング ノードがあると想定) の場合は、次のように非マイクロサービスモードに切り替えることができます。 -1. クラスター構成を変更し、クラスターを非マイクロサービス モードに切り替えます。 +1. クラスター構成を変更し、クラスターを非マイクロサービスモードに切り替えます。 ```shell tiup cluster edit-config @@ -295,7 +295,7 @@ PD マイクロサービスが有効になっているクラスター (IP アド > > 前の`scale-in`コマンドを実行した後、PD タイムスタンプ割り当てサービスは利用できなくなりますが、次のステップの`reload`コマンドの実行が完了すると再び利用できるようになります。 -3. PD ノード構成のローリング アップデートを実行します。 +3. PD ノード構成のローリングアップデートを実行します。 ```shell tiup cluster reload -R pd diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index eae103493a0b0..c24a5b641cd7d 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -5,7 +5,7 @@ summary: TiUPを使用して TiDB クラスターをスケーリングする方 # TiUPを使用して TiDBクラスタをスケールする {#scale-a-tidb-cluster-using-tiup} -TiDB クラスターの容量は、オンライン サービスを中断することなく増減できます。 +TiDB クラスターの容量は、オンラインサービスを中断することなく増減できます。 このドキュメントでは、 TiUPを使用して TiDB、TiKV、PD、TiCDC、またはTiFlashクラスターをスケーリングする方法について説明します。TiUPをインストールしていない場合は、 [ステップ2. 制御マシンにTiUPをデプロイ](/production-deployment-using-tiup.md#step-2-deploy-tiup-on-the-control-machine)の手順を参照してください。 @@ -380,7 +380,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する tiup cluster display ``` -4. 削除されたTiFlashノードのステータスが`Tombstone`になったら、削除されたノードの情報をTiUPトポロジから削除します (TiUP は`Tombstone`ノードの関連データ ファイルを自動的にクリーンアップします)。 +4. 削除されたTiFlashノードのステータスが`Tombstone`になったら、削除されたノードの情報をTiUPトポロジから削除します (TiUP は`Tombstone`ノードの関連データファイルを自動的にクリーンアップします)。 ```shell tiup cluster prune @@ -392,7 +392,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する 1. このTiFlashノードに対応するストア ID を表示するには、pd-ctl の store コマンドを使用します。 - - [pd-ctl](/pd-control.md)に store コマンドを入力します (バイナリ ファイルは tidb-ansible ディレクトリの`resources/bin`の下にあります)。 + - [pd-ctl](/pd-control.md)に store コマンドを入力します (バイナリファイルは tidb-ansible ディレクトリの`resources/bin`の下にあります)。 - TiUPデプロイメントを使用する場合は、 `pd-ctl` `tiup ctl:v pd`に置き換えます。 @@ -420,7 +420,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する 3. TiFlashプロセスを停止する前に、 TiFlashノードのストアが消えるか、 `state_name` `Tombstone`になるまで待ちます。 -4. 削除されたノードの情報をTiUPトポロジから削除します (TiUP は`Tombstone`ノードの関連データ ファイルを自動的にクリーンアップします)。 +4. 削除されたノードの情報をTiUPトポロジから削除します (TiUP は`Tombstone`ノードの関連データファイルを自動的にクリーンアップします)。 ```shell tiup cluster prune diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index e012aa289c1be..4616d3b6299bd 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -246,7 +246,7 @@ host = "" `location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 -上記の手順に従って`location-labels`をゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、次のように`isolation-level`を`zone`に設定できます。 +上記の手順に従って`location-labels`をゾーン -> ラック -> ホストと設定して 3 層クラスタトポロジを作成したと仮定すると、次のように`isolation-level`を`zone`に設定できます。 ```toml [replication] diff --git a/scheduling-configuration-file.md b/scheduling-configuration-file.md index eed51375fdc9a..d3b3a8dc8e05e 100644 --- a/scheduling-configuration-file.md +++ b/scheduling-configuration-file.md @@ -70,7 +70,7 @@ summary: スケジューリング構成ファイルには、ノード名、デ ### `redact-info-log` {#redact-info-log} - スケジュール ノード ログでログの秘匿化を有効にするかどうかを制御します。 -- 構成値を`true`に設定すると、スケジュール ノード ログでユーザー データが秘匿化されます。 +- 構成値を`true`に設定すると、スケジュール ノード ログでユーザーデータが秘匿化されます。 - デフォルト値: `false` ## log {#log} @@ -108,13 +108,13 @@ summary: スケジューリング構成ファイルには、ノード名、デ ### `max-days` {#max-days} - ログが保持される最大日数。 -- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、スケジュールではログ ファイルがクリーンアップされません。 +- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、スケジュールではログファイルがクリーンアップされません。 - デフォルト値: `0` ### `max-backups` {#max-backups} -- 保持されるログ ファイルの最大数。 -- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、スケジュールはすべてのログ ファイルを保持します。 +- 保持されるログファイルの最大数。 +- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、スケジュールはすべてのログファイルを保持します。 - デフォルト値: `0` ## metric {#metric} diff --git a/schema-cache.md b/schema-cache.md index 038d3bb08fa8b..32a794041297d 100644 --- a/schema-cache.md +++ b/schema-cache.md @@ -59,7 +59,7 @@ summary: TiDBは、スキーマ情報に対してLRU（Least Recently Used：最 - `FLASHBACK` - `ALTER TABLE ... SET TIFLASH MODE ...` -- [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)属性を持つテーブルを使用する場合、スキーマ キャッシュ サイズが小さいと、これらのテーブルのメタデータが頻繁にキャッシュに出入りする可能性があります。その結果、割り当てられた ID 範囲が完全に使用される前に無効になり、ID ジャンプが発生する可能性があります。書き込みが集中するシナリオでは、ID 範囲が枯渇することさえあります。異常な ID 割り当て動作を最小限に抑え、システムの安定性を向上させるために、次の対策を講じることをお勧めします。 +- [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)属性を持つテーブルを使用する場合、スキーマキャッシュサイズが小さいと、これらのテーブルのメタデータが頻繁にキャッシュに出入りする可能性があります。その結果、割り当てられた ID 範囲が完全に使用される前に無効になり、ID ジャンプが発生する可能性があります。書き込みが集中するシナリオでは、ID 範囲が枯渇することさえあります。異常な ID 割り当て動作を最小限に抑え、システムの安定性を向上させるために、次の対策を講じることをお勧めします。 - 監視パネルでスキーマキャッシュのヒット率とサイズを確認し、キャッシュ設定が適切かどうかを評価してください。スキーマキャッシュのサイズを適切に増やすことで、キャッシュの強制削除頻度を減らすことができます。 - IDジャンプを防ぐには、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache) `1`に設定してください。 diff --git a/schema-object-names.md b/schema-object-names.md index 8d1a6839175e8..038e64f0d466c 100644 --- a/schema-object-names.md +++ b/schema-object-names.md @@ -1,13 +1,13 @@ --- title: Schema Object Names -summary: TiDB SQLステートメントのスキーマ オブジェクト名について学習します。 +summary: TiDB SQLステートメントのスキーマオブジェクト名について学習します。 --- # Schema Object Names {#schema-object-names} -このドキュメントでは、TiDB SQLステートメントのスキーマ オブジェクト名について説明します。 +このドキュメントでは、TiDB SQLステートメントのスキーマオブジェクト名について説明します。 スキーマオブジェクト名は、データベース、テーブル、インデックス、列、エイリアスなど、TiDB内のすべてのスキーマオブジェクトの名前として使用されます。SQL文では、識別子を使用してこれらのオブジェクトを引用符で囲むことができます。 diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index a0e811f0a2dc7..2e3179ec4e566 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -28,7 +28,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 > **Warning:** > -> `_tidb_rowid`は TiDB によって暗黙的に割り当てられる内部行 ID です。すべての場合においてグローバルに一意であると想定しないでください。クラスター化インデックスを使用しないパーティション テーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`異なるパーティションに同じ`_tidb_rowid`値を残す可能性があります。詳細については、 [`_tidb_rowid`](/tidb-rowid.md)を参照してください。 +> `_tidb_rowid`は TiDB によって暗黙的に割り当てられる内部行 ID です。すべての場合においてグローバルに一意であると想定しないでください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`異なるパーティションに同じ`_tidb_rowid`値を残す可能性があります。詳細については、 [`_tidb_rowid`](/tidb-rowid.md)を参照してください。 > **Note:** > diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index 5a6ad558e35c8..120c82ebcfa7a 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -1,17 +1,17 @@ --- title: TiDB Smooth Upgrade -summary: このドキュメントでは、DDL 操作を手動でキャンセルせずに TiDB クラスターのアップグレードをサポートする、TiDB のスムーズ アップグレード機能について説明します。 +summary: このドキュメントでは、DDL 操作を手動でキャンセルせずに TiDB クラスターのアップグレードをサポートする、TiDB のスムーズアップグレード機能について説明します。 --- # TiDB スムーズアップグレード {#tidb-smooth-upgrade} -このドキュメントでは、DDL 操作を手動でキャンセルせずに TiDB クラスターのアップグレードをサポートする、TiDB のスムーズ アップグレード機能について説明します。 +このドキュメントでは、DDL 操作を手動でキャンセルせずに TiDB クラスターのアップグレードをサポートする、TiDB のスムーズアップグレード機能について説明します。 Starting from v7.1.0, when you upgrade TiDB to a later version, TiDB supports smooth upgrade. This feature removes the limitations during the upgrade process and provides a more user-friendly upgrade experience. Note that you need to ensure that there are no user-initiated DDL operations during the upgrade process. ## サポートされているバージョン {#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 @@ -31,14 +31,14 @@ Starting from v7.1.0, when you upgrade TiDB to a later version, TiDB supports sm | バージョン7.1.1 | v7.2.0 または v7.3.0 | スムーズなアップグレードが自動的にサポートされます。追加の操作は必要ありません。 | Experimental機能です。 | | バージョン7.2.0 | バージョン7.3.0 | スムーズなアップグレードが自動的にサポートされます。追加の操作は必要ありません。 | Experimental機能です。 | | [v7.1.2、v7.2.0) | [v7.1.2、v7.2.0) | `/upgrade/start` HTTPリクエストを送信することでスムーズなアップグレードが可能になります。方法は[TiUPを使用する](#use-tiup-to-upgrade)と[その他のアップグレード方法](#other-upgrade-methods) 2つあります。 | When smooth upgrade is not enabled, ensure that no DDL operations are performed during the upgrade. | -| [v7.1.2、v7.2.0) または >= v7.4.0 | = v7.4.0 | `/upgrade/start` HTTPリクエストを送信することでスムーズなアップグレードが可能になります。方法は[TiUPを使用する](#use-tiup-to-upgrade)と[Other upgrade methods](#other-upgrade-methods) 2つがあります。 | スムーズ アップグレードが有効になっていない場合は、アップグレード中に DDL 操作が実行されないようにしてください。 | +| [v7.1.2、v7.2.0) または >= v7.4.0 | = v7.4.0 | `/upgrade/start` HTTPリクエストを送信することでスムーズなアップグレードが可能になります。方法は[TiUPを使用する](#use-tiup-to-upgrade)と[Other upgrade methods](#other-upgrade-methods) 2つがあります。 | スムーズアップグレードが有効になっていない場合は、アップグレード中に DDL 操作が実行されないようにしてください。 | | v7.1.0、v7.1.1、v7.2.0、および v7.3.0 | = v7.4.0 | スムーズなアップグレードはサポートされません。 | | ## Feature introduction {#feature-introduction} Before the smooth upgrade feature is introduced, there are the following limitations on DDL operations during the upgrade process: -- アップグレード プロセス中に DDL 操作を実行すると、TiDB で未定義の動作が発生する可能性があります。 +- アップグレードプロセス中に DDL 操作を実行すると、TiDB で未定義の動作が発生する可能性があります。 - DDL 操作中に TiDB をアップグレードすると、TiDB で未定義の動作が発生する可能性があります。 These limitations can be summarized as that you need to ensure that there are no user-initiated DDL operations during the upgrade process. After the smooth upgrade feature is introduced, TiDB is no longer subject to this limitation during the upgrade process. @@ -64,14 +64,14 @@ You can take the following steps to upgrade TiDB manually or by using a script: - The DDL operations to be performed are paused. 2. Replace the TiDB binary and perform a rolling upgrade. This process is the same as the original upgrade process. - - システム DDL 操作はアップグレード プロセス中に実行されます。 + - システム DDL 操作はアップグレードプロセス中に実行されます。 3. クラスター内のすべての TiDB ノードが正常にアップグレードされたら、任意の TiDB ノードに HTTP アップグレード完了要求を送信します`curl -X POST http://{TiDBIP}:10080/upgrade/finish` . - ユーザーの一時停止された DDL 操作が再開されます。 ## Limitations {#limitations} -スムーズ アップグレード機能を使用する場合は、次の制限に注意してください。 +スムーズアップグレード機能を使用する場合は、次の制限に注意してください。 > **Note:** > @@ -88,7 +88,7 @@ You can take the following steps to upgrade TiDB manually or by using a script: - アップグレード中は、次の操作は許可されません。 - - システム テーブル ( `mysql.*` 、 `information_schema.*` 、 `performance_schema.*` 、および`metrics_schema.*` ) に対して DDL 操作を実行します。 + - システムテーブル ( `mysql.*` 、 `information_schema.*` 、 `performance_schema.*` 、および`metrics_schema.*` ) に対して DDL 操作を実行します。 - DDL ジョブを手動でキャンセルします: `ADMIN CANCEL DDL JOBS job_id [, job_id] ...;` . - データをインポートします。 @@ -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-mode.md b/sql-mode.md index 04cc7e9183711..14d80bd501bd9 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -19,7 +19,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ - `ANSI` : このモードは標準 SQL に準拠しています。このモードでは、データがチェックされます。データが定義された型または長さに準拠していない場合、データ型が調整またはトリミングされ、 `warning`が返されます。 - `STRICT_TRANS_TABLES` : 厳密モード。データが厳密にチェックされます。データに誤りがある場合は、テーブルに挿入できず、エラーが返されます。 -- `TRADITIONAL` : このモードでは、TiDB は「従来型」の SQL データベース システムのように動作します。列に誤った値が挿入された場合、警告ではなくエラーが返されます。その後、 `INSERT`または`UPDATE`ステートメントは直ちに停止されます。 +- `TRADITIONAL` : このモードでは、TiDB は「従来型」の SQL データベースシステムのように動作します。列に誤った値が挿入された場合、警告ではなくエラーが返されます。その後、 `INSERT`または`UPDATE`ステートメントは直ちに停止されます。 ## SQLモードテーブル {#sql-mode-table} diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index d228a3b1e1777..6fc6a5ab44432 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -14,7 +14,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache 非プリペアドプランキャッシュは、 [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)とキャッシュを共有するセッションレベルの機能です。非プリペアドプランキャッシュの基本原理は次のとおりです。 1. 非プリペアドプランキャッシュを有効にすると、TiDBはまず抽象構文木（AST）に基づいてクエリをパラメータ化します。例えば、 `SELECT * FROM t WHERE b < 10 AND a = 1` `SELECT * FROM t WHERE b < ? and a = ?`としてパラメータ化されます。 -2. 次に、TiDB はパラメータ化されたクエリを使用してプラン キャッシュを検索します。 +2. 次に、TiDB はパラメータ化されたクエリを使用してプランキャッシュを検索します。 3. 再利用可能なプランが見つかった場合は、それが直接使用され、最適化フェーズはスキップされます。 4. それ以外の場合、オプティマイザーは新しいプランを生成し、それをキャッシュに戻して、後続のクエリで再利用します。 @@ -30,7 +30,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache ## 例 {#example} -次の例は、非プリペアドプラン キャッシュを使用する方法を示しています。 +次の例は、非プリペアドプランキャッシュを使用する方法を示しています。 1. テスト用にテーブル`t`を作成します。 @@ -38,7 +38,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache CREATE TABLE t (a INT, b INT, KEY(b)); ``` -2. 非プリペアドプラン キャッシュを有効にします。 +2. 非プリペアドプランキャッシュを有効にします。 ```sql SET tidb_enable_non_prepared_plan_cache = ON; @@ -80,7 +80,7 @@ TiDBは、パラメータ化されたクエリに対して1つのプランのみ 上記のリスクと、実行プランキャッシュが大きなメリットをもたらすのは単純なクエリのみであるという事実（クエリが複雑で実行に時間がかかる場合、実行プランキャッシュの使用はあまり役に立たない可能性があります）を考慮し、TiDBでは非プリペアドプランキャッシュのスコープに厳しい制限を設けています。制限は次のとおりです。 -- [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でサポートされていないクエリまたはプランは、非プリペアドプラン キャッシュでもサポートされません。 +- [プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でサポートされていないクエリまたはプランは、非プリペアドプランキャッシュでもサポートされません。 - `Window`や`Having`などの複雑な演算子を含むクエリはサポートされていません。 - 3 つ以上の`Join`テーブルまたはサブクエリを含むクエリはサポートされていません。 - `ORDER BY 1`や`GROUP BY a+1`など、 `ORDER BY`または`GROUP BY`直後に数字や式が含まれるクエリはサポートされていません`ORDER BY column_name`と`GROUP BY column_name`のみがサポートされています。 @@ -138,11 +138,11 @@ SHOW warnings; 1 row in set (0.00 sec) ``` -前の例では、非プリペアドプラン キャッシュが`+`操作をサポートしていないため、クエリはキャッシュにヒットできません。 +前の例では、非プリペアドプランキャッシュが`+`操作をサポートしていないため、クエリはキャッシュにヒットできません。 ## 監視 {#monitoring} -非プリペアドプラン キャッシュを有効にすると、次のペインでメモリ使用量、キャッシュ内のプランの数、キャッシュ ヒット率を監視できます。 +非プリペアドプランキャッシュを有効にすると、次のペインでメモリ使用量、キャッシュ内のプランの数、キャッシュヒット率を監視できます。 ![non-prepare-plan-cache](/media/tidb-non-prepared-plan-cache-metrics.png) @@ -154,7 +154,7 @@ SHOW warnings; CREATE TABLE t (a int); ``` -2. 非プリペアドプラン キャッシュを有効にします。 +2. 非プリペアドプランキャッシュを有効にします。 ```sql SET @@tidb_enable_non_prepared_plan_cache=ON; diff --git a/sql-physical-optimization.md b/sql-physical-optimization.md index e1b993eac5182..f23d06c4c36be 100644 --- a/sql-physical-optimization.md +++ b/sql-physical-optimization.md @@ -13,4 +13,4 @@ summary: 物理最適化は、論理実行計画に基づく物理実行計画 - [統計入門](/statistics.md)では、テーブルのデータ分布を取得するために TiDB が収集する統計について学習します。 - [インデックス問題の解決方法](/wrong-index-solution.md) 、インデックスが間違って選択されていることがわかった場合に、正しいインデックスを使用する方法を紹介します。 - [クエリの最適化](/agg-distinct-optimization.md) 、物理最適化における`DISTINCT`キーワードに関連する最適化が導入されています。このセクションでは、その利点と欠点、そして使用方法について説明します。 -- [コストモデル](/cost-model.md) 、物理的な最適化中にコスト モデルに基づいて最適な実行計画を選択する方法を紹介します。 +- [コストモデル](/cost-model.md) 、物理的な最適化中にコストモデルに基づいて最適な実行計画を選択する方法を紹介します。 diff --git a/sql-plan-management.md b/sql-plan-management.md index ac33e40b9f926..a8de83805cc27 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -218,8 +218,7 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; > **Note:** > -> `PREPARE` / `EXECUTE`およびバイナリ プロトコルで実行されるクエリの場合、 `PREPARE` / `EXECUTE`ステートメントではなく、実際のクエリ ステートメントのバインディングを作成する必要があります。 - +> `PREPARE` / `EXECUTE`およびバイナリプロトコルで実行されるクエリの場合、 `PREPARE` / `EXECUTE`ステートメントではなく、実際のクエリステートメントのバインディングを作成する必要があります。 #### 履歴実行計画に従ってバインディングを作成する {#create-a-binding-according-to-a-historical-execution-plan} SQL文の実行計画を過去の実行計画に固定するには、Plan Digestを使用して過去の実行計画をSQL文にバインドします。これは、SQL文ごとにバインドするよりも便利です。さらに、複数のSQL文の実行計画を一度にバインドすることも可能です。詳細と例については、 [`CREATE [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-create-binding.md)を参照してください。 @@ -543,8 +542,7 @@ SHOW GLOBAL BINDINGS; `SHOW GLOBAL BINDINGS`出力では、クロスデータベースバインディングの`Default_db`フィールド値が空で、 `Original_sql`フィールドと`Bind_sql`フィールドのデータベース名は`*`として表されています。このバインディングは、特定のデータベースだけでなく、すべてのデータベースの`select * from t`クエリに適用されます。 -同じクエリに対して、クロスデータベース バインディングと標準バインディングの両方が共存できます。TiDB は、バインディングを次の順序で一致させます: SESSION スコープの標準バインディング > SESSION スコープのクロスデータベース バインディング > GLOBAL スコープの標準バインディング > GLOBAL スコープのクロスデータベース バインディング。 - +同じクエリに対して、クロスデータベースバインディングと標準バインディングの両方が共存できます。TiDB は、バインディングを次の順序で一致させます: SESSION スコープの標準バインディング > SESSION スコープのクロスデータベースバインディング > GLOBAL スコープの標準バインディング > GLOBAL スコープのクロスデータベースバインディング。 クロスデータベースバインディングの作成構文は標準バインディングと異なりますが、削除構文とステータス変更構文は同じです。以下に詳細な使用例を示します。 1. データベース`db1`と`db2`を作成し、各データベースに 2 つのテーブルを作成します。 @@ -638,7 +636,7 @@ SHOW GLOBAL BINDINGS; > **Note:** > -> 自動バインディング作成機能は[ステートメントの概要](/statement-summary-tables.md)に依存しているため、自動バインディングを使用する前にステートメント サマリーを有効にしてください。 +> 自動バインディング作成機能は[ステートメントの概要](/statement-summary-tables.md)に依存しているため、自動バインディングを使用する前にステートメントサマリーを有効にしてください。 自動バインディング作成を有効にすると、ステートメントサマリー内の過去のSQL文が`bind-info-lease`回（デフォルト値は`3s` ）ごとに走査され、2回以上出現するSQL文に対してバインディングが自動的に作成されます。これらのSQL文に対して、TiDBはステートメントサマリーに記録された実行計画を自動的にバインドします。 @@ -653,8 +651,7 @@ SHOW GLOBAL BINDINGS; > > 現在、バインディングは、クエリ文によって生成された実行計画を固定するためのヒント群を生成します。これにより、同じクエリでは実行計画が変わらなくなります。同じインデックスや結合アルゴリズム（HashJoinやIndexJoinなど）を使用するクエリを含むほとんどのOLTPクエリでは、TiDBはバインディング前後のプランの一貫性を保証します。ただし、ヒントの制限により、2つ以上のテーブルの結合、MPPクエリ、複雑なOLAPクエリなど、一部の複雑なクエリではプランの一貫性を保証できません。 -`PREPARE` / `EXECUTE`およびバイナリ プロトコルで実行されたクエリの場合、TiDB は`PREPARE`ステートメントではなく、実際の`EXECUTE`ステートメントのバインディングを自動的にキャプチャします。 - +`PREPARE` / `EXECUTE`およびバイナリプロトコルで実行されたクエリの場合、TiDB は`PREPARE`ステートメントではなく、実際の`EXECUTE`ステートメントのバインディングを自動的にキャプチャします。 > **Note:** > > TiDB には一部の機能の正確性を確保するための SQL ステートメントが埋め込まれているため、ベースライン キャプチャではデフォルトでこれらの SQL ステートメントが自動的に保護されます。 diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index b77baf6124464..38d7dee77bd6e 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -37,7 +37,7 @@ TiDB は、 `sql-statement`に基づいて、次のオンサイト情報を整 > **Note:** > -> `PLAN REPLAYER`テーブル データをエクスポートし**ません**。 +> `PLAN REPLAYER`テーブルデータをエクスポートし**ません**。 ### クラスター情報のエクスポートの例 {#examples-of-exporting-cluster-information} @@ -125,7 +125,7 @@ curl http://127.0.0.1:10080/plan_replayer/dump/replayer_JOGvpu4t7dssySqJfTtS4A== > **Warning:** > -> TiDB クラスターのオンサイト情報を別のクラスターにインポートすると、後者のクラスターの TiDB セッション変数、SQL バインディング、テーブル スキーマ、および統計が変更されます。 +> TiDB クラスターのオンサイト情報を別のクラスターにインポートすると、後者のクラスターの TiDB セッション変数、SQL バインディング、テーブルスキーマ、および統計が変更されます。 `PLAN REPLAYER`を使用してエクスポートされた既存の`ZIP`ファイルがあれば、 `PLAN REPLAYER`インポートインターフェースを使用して、クラスタのオンサイト情報を他の TiDB クラスタに復元できます。構文は次のとおりです。 @@ -197,7 +197,7 @@ TiDBの実行計画を特定する場合、対象となるSQL文と実行計画 - 対象となるSQL文と対象実行計画のダイジェストを事前にTiDBクラスタに登録し、対象クエリとのマッチングを開始します。 - ターゲット クエリが正常に一致すると、そのオプティマイザー関連の情報を直接キャプチャし、ZIP ファイルとしてエクスポートします。 - 一致した SQL と実行計画ごとに、情報は 1 回だけキャプチャされます。 -- システム テーブルを通じて、進行中の一致するタスクと生成されたファイルを表示します。 +- システムテーブルを通じて、進行中の一致するタスクと生成されたファイルを表示します。 - 履歴ファイルを定期的にクリーンアップします。 ### `PLAN REPLAYER CAPTURE`を有効にする {#enable-plan-replayer-capture} diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index b00cac29df87a..9e3a8ae7d36f5 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -19,7 +19,7 @@ TiDBは、 `Prepare` / `Execute`文と同様に、 `PREPARE`以外の文につ TiDB の現在のバージョンでは、 `Prepare`ステートメントが次のいずれかの条件を満たす場合、クエリまたはプランはキャッシュされません。 - クエリには、 `SELECT` 、 `UPDATE` 、 `INSERT` 、 `DELETE` 、 `Union` 、 `Intersect` 、 `Except`以外の SQL ステートメントが含まれています。 -- クエリは一時テーブル、または生成列を含むテーブルにアクセスするか、静的モード (つまり、 [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51)が`static`に設定される) を使用してパーティション テーブルにアクセスします。 +- クエリは一時テーブル、または生成列を含むテーブルにアクセスするか、静的モード (つまり、 [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51)が`static`に設定される) を使用してパーティションテーブルにアクセスします。 - クエリには、 `SELECT * FROM t1 WHERE t1.a > (SELECT 1 FROM t2 WHERE t2.b < 1)`などの非相関サブクエリが含まれています。 - クエリには、実行計画に`SELECT * FROM t1 WHERE t1.a > (SELECT a FROM t2 WHERE t1.b > t2.b)`などの`PhysicalApply`演算子を持つ相関サブクエリが含まれています。 - クエリには、 `SELECT /*+ ignore_plan_cache() */ * FROM t`や`SELECT /*+ set_var(max_execution_time=1) */ * FROM t`などの`ignore_plan_cache`または`set_var`ヒントが含まれています。 @@ -51,12 +51,12 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで 検証テストに合格すると、実行計画のスキャン範囲が現在のパラメータ値に応じて調整され、データクエリの実行に使用されます。 -実行計画のキャッシュとクエリ パフォーマンスに関して注目すべき点がいくつかあります。 +実行計画のキャッシュとクエリパフォーマンスに関して注目すべき点がいくつかあります。 - 実行計画は、キャッシュされているかどうかに関わらず、SQLバインディングの影響を受けます。キャッシュされていない実行計画（最初の`Execute` ）は、既存のSQLバインディングの影響を受けます。キャッシュされている実行計画は、新しいSQLバインディングが作成されると無効になります。 - キャッシュされたプランは、統計、最適化ルール、式によるブロックリストのプッシュダウンの変更の影響を受けません。 - `Execute`のパラメータが異なることを考慮し、実行プランキャッシュは、適応性を確保するために、特定のパラメータ値に密接に関連する一部の積極的なクエリ最適化手法を禁止します。これにより、クエリプランが特定のパラメータ値に対して最適にならない可能性があります。例えば、クエリのフィルタ条件が`where a > ? And a < ?`で、最初の`Execute`ステートメントのパラメータがそれぞれ`2`と`1`あるとします。これらの 2 つのパラメータが次回の実行時に`1`と`2`なる可能性があることを考慮すると、オプティマイザは現在のパラメータ値に固有の最適な`TableDual`実行計画を生成しません。 -- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行計画が生成されます。たとえば、フィルター条件が`where a < ?`で、最初の実行に使用されたパラメーター値が`1`の場合、オプティマイザーは最適な`IndexScan`実行計画を生成し、それをキャッシュに格納します。後続の実行で値が`10000`になった場合、 `TableScan`プランの方が適している可能性があります。ただし、実行プランキャッシュがあるため、以前に生成された`IndexScan`を使用して実行されます。そのため、実行プランキャッシュは、クエリが単純 (コンパイル率が高い) で実行計画が比較的固定されているアプリケーション シナリオに適しています。 +- キャッシュの無効化と削除を考慮しない場合、実行プランキャッシュはさまざまなパラメーター値に適用され、理論上は特定の値に対して最適ではない実行計画が生成されます。たとえば、フィルター条件が`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)を介して制御できます。 @@ -64,7 +64,7 @@ LRUリンクリストは、 `Prepare` / `Execute`セッションをまたいで > > [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610)システム変数は、 `Prepare` / `Execute`クエリの実行プランキャッシュのみを制御し、通常のクエリは制御しません。通常のクエリの実行プランキャッシュについては、 [SQL 非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を参照してください。 -実行プランキャッシュ機能を有効にすると、セッション レベルのシステム変数[`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-new-in-v40)を使用して、前の`Execute`ステートメントがキャッシュされた実行計画を使用したかどうかを確認できます。次に例を示します。 +実行プランキャッシュ機能を有効にすると、セッションレベルのシステム変数[`last_plan_from_cache`](/system-variables.md#last_plan_from_cache-new-in-v40)を使用して、前の`Execute`ステートメントがキャッシュされた実行計画を使用したかどうかを確認できます。次に例を示します。 ```sql MySQL [test]> create table t(a int); diff --git a/sql-statements/sql-statement-admin-cleanup.md b/sql-statements/sql-statement-admin-cleanup.md index 6c1ad9cea95b5..e3a826583aac8 100644 --- a/sql-statements/sql-statement-admin-cleanup.md +++ b/sql-statements/sql-statement-admin-cleanup.md @@ -62,7 +62,7 @@ Query OK, 0 rows affected (0.01 sec) > - 行データとインデックスデータの両方が失われている可能性があります。一貫性を回復するには、 `ADMIN CLEANUP INDEX`と[`ADMIN RECOVER INDEX`](/sql-statements/sql-statement-admin-recover.md)ステートメントを一緒に使用してください。 > - `ADMIN CLEANUP INDEX`ステートメントは常に単一スレッドで実行されます。テーブルデータが大きい場合は、インデックスを再構築してインデックスデータを回復することをお勧めします。 > - `ADMIN CLEANUP INDEX`文を実行すると、対応するテーブルまたはインデックスはロックされず、TiDB は他のセッションによるテーブルレコードの同時変更を許可します。ただし、この場合、 `ADMIN CLEANUP INDEX`ではすべてのテーブルレコードを正しく処理できない可能性があります。したがって、 `ADMIN CLEANUP INDEX`を実行する際は、テーブルデータの同時変更を避けてください。 -> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](/support.md)サポート エンジニアに問い合わせて支援を受けることができます。 +> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](/support.md)サポートエンジニアに問い合わせて支援を受けることができます。 > > `ADMIN CLEANUP INDEX`文はアトミックではありません。実行中に文が中断された場合は、成功するまで再度実行することをお勧めします。 @@ -77,7 +77,7 @@ Query OK, 0 rows affected (0.01 sec) > - 行データとインデックスデータの両方が失われている可能性があります。一貫性を回復するには、 `ADMIN CLEANUP INDEX`と[`ADMIN RECOVER INDEX`](/sql-statements/sql-statement-admin-recover.md)ステートメントを一緒に使用してください。 > - `ADMIN CLEANUP INDEX`ステートメントは常に単一スレッドで実行されます。テーブルデータが大きい場合は、インデックスを再構築してインデックスデータを回復することをお勧めします。 > - `ADMIN CLEANUP INDEX`文を実行すると、対応するテーブルまたはインデックスはロックされず、TiDB は他のセッションによるテーブルレコードの同時変更を許可します。ただし、この場合、 `ADMIN CLEANUP INDEX`ではすべてのテーブルレコードを正しく処理できない可能性があります。したがって、 `ADMIN CLEANUP INDEX`を実行する際は、テーブルデータの同時変更を避けてください。 -> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](https://tidb.support.pingcap.com/)サポート エンジニアに問い合わせて支援を受けることができます。 +> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](https://tidb.support.pingcap.com/)サポートエンジニアに問い合わせて支援を受けることができます。 > > `ADMIN CLEANUP INDEX`文はアトミックではありません。実行中に文が中断された場合は、成功するまで再度実行することをお勧めします。 diff --git a/sql-statements/sql-statement-admin-recover.md b/sql-statements/sql-statement-admin-recover.md index 97fe776bdb57a..3456b9c2f440b 100644 --- a/sql-statements/sql-statement-admin-recover.md +++ b/sql-statements/sql-statement-admin-recover.md @@ -60,7 +60,7 @@ Query OK, 0 rows affected (0.01 sec) > - 行データとインデックスデータの両方が失われている可能性があります。この問題に対処するには、 [`ADMIN CLEANUP INDEX`](/sql-statements/sql-statement-admin-cleanup.md)と`ADMIN RECOVER INDEX`ステートメントを組み合わせて使用し、行データとインデックスデータの一貫性を回復してください。 > - `ADMIN RECOVER INDEX`ステートメントは常に単一スレッドで実行されます。テーブルデータが大きい場合は、インデックスを再構築してインデックスデータを回復することをお勧めします。 > - `ADMIN RECOVER INDEX`文を実行すると、対応するテーブルまたはインデックスはロックされず、TiDB は他のセッションによるテーブルレコードの同時変更を許可します。ただし、この場合、 `ADMIN RECOVER INDEX`ではすべてのテーブルレコードを正しく処理できない可能性があります。したがって、 `ADMIN RECOVER INDEX`を実行する際は、テーブルデータの同時変更を避けてください。 -> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](/support.md)サポート エンジニアに問い合わせて支援を受けることができます。 +> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](/support.md)サポートエンジニアに問い合わせて支援を受けることができます。 > > `ADMIN RECOVER INDEX`文はアトミックではありません。実行中に文が中断された場合は、成功するまで再度実行することをお勧めします。 @@ -75,7 +75,7 @@ Query OK, 0 rows affected (0.01 sec) > - 行データとインデックスデータの両方が失われている可能性があります。この問題に対処するには、 [`ADMIN CLEANUP INDEX`](/sql-statements/sql-statement-admin-cleanup.md)と`ADMIN RECOVER INDEX`ステートメントを組み合わせて使用し、行データとインデックスデータの一貫性を回復してください。 > - `ADMIN RECOVER INDEX`ステートメントは常に単一スレッドで実行されます。テーブルデータが大きい場合は、インデックスを再構築してインデックスデータを回復することをお勧めします。 > - `ADMIN RECOVER INDEX`文を実行すると、対応するテーブルまたはインデックスはロックされず、TiDB は他のセッションによるテーブルレコードの同時変更を許可します。ただし、この場合、 `ADMIN RECOVER INDEX`ではすべてのテーブルレコードを正しく処理できない可能性があります。したがって、 `ADMIN RECOVER INDEX`を実行する際は、テーブルデータの同時変更を避けてください。 -> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](https://tidb.support.pingcap.com/)サポート エンジニアに問い合わせて支援を受けることができます。 +> - TiDB Enterprise Editionを使用する場合は、 [リクエストを送信する](https://tidb.support.pingcap.com/)サポートエンジニアに問い合わせて支援を受けることができます。 > > `ADMIN RECOVER INDEX`文はアトミックではありません。実行中に文が中断された場合は、成功するまで再度実行することをお勧めします。 diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index e22406039d0e4..8f8c6f6cc891d 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..87184ed4b8f5b 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; @@ -289,7 +289,7 @@ ADMIN SHOW DDL JOBS 5 WHERE state != 'synced' AND db_name = 'test'; - `START_TIME` : DDL操作の開始時刻。 - `END_TIME` : DDL 操作の終了時刻。 - `STATE` : DDL操作の状態。一般的な状態には以下が含まれます。 - - `none` : これは、操作タスクが DDL ジョブ キューに入れられたものの、前のタスクの完了を待っているため、まだ実行されていないことを示します。別の理由としては、ドロップ操作の実行後に`none`状態になるものの、すぐに`synced`状態に更新されることが考えられます。これは、すべての TiDB インスタンスがこの状態に同期されたことを意味します。 + - `none` : これは、操作タスクが DDL ジョブキューに入れられたものの、前のタスクの完了を待っているため、まだ実行されていないことを示します。別の理由としては、ドロップ操作の実行後に`none`状態になるものの、すぐに`synced`状態に更新されることが考えられます。これは、すべての TiDB インスタンスがこの状態に同期されたことを意味します。 - `running` : これは、操作が実行されていることを示します。 - `synced` : これは、操作が正常に実行され、すべての TiDB インスタンスがこの状態に同期されたことを示します。 - `rollback done` : 操作が失敗し、ロールバックが完了したことを示します。 diff --git a/sql-statements/sql-statement-alter-database.md b/sql-statements/sql-statement-alter-database.md index a4a11a1cc95ce..61b9d629cb0eb 100644 --- a/sql-statements/sql-statement-alter-database.md +++ b/sql-statements/sql-statement-alter-database.md @@ -19,7 +19,7 @@ DatabaseOption ::= ## 例 {#examples} -utf8mb4 文字セットを使用するようにテスト データベース スキーマを変更します。 +utf8mb4 文字セットを使用するようにテストデータベーススキーマを変更します。 ```sql ALTER DATABASE test DEFAULT CHARACTER SET = utf8mb4; diff --git a/sql-statements/sql-statement-alter-resource-group.md b/sql-statements/sql-statement-alter-resource-group.md index 1874900ff0a6e..1f145fc001000 100644 --- a/sql-statements/sql-statement-alter-resource-group.md +++ b/sql-statements/sql-statement-alter-resource-group.md @@ -5,7 +5,7 @@ summary: TiDBにおけるALTER RESOURCE GROUPの使い方を学びましょう # ALTER RESOURCE GROUP {#alter-resource-group} -`ALTER RESOURCE GROUP`ステートメントは、データベース内のリソース グループを変更するために使用されます。 +`ALTER RESOURCE GROUP`ステートメントは、データベース内のリソースグループを変更するために使用されます。 > **Note:** > @@ -78,7 +78,7 @@ DirectBackgroundOption ::= | "UTILIZATION_LIMIT" EqOpt LengthNum ``` -TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)は、CPU、IO、およびその他のシステム リソースに対する TiDB の統合抽象化ユニットです。 +TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)は、CPU、IO、およびその他のシステムリソースに対する TiDB の統合抽象化ユニットです。 | オプション | 説明 | 例 | | ------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -92,7 +92,7 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで > > - `ALTER RESOURCE GROUP`ステートメントは、グローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)が`ON`に設定されている場合にのみ実行できます。 > - `ALTER RESOURCE GROUP`ステートメントは、指定されていないパラメーターを変更せずに、増分的な変更をサポートします。ただし、 `QUERY_LIMIT`と`BACKGROUND`は全体として使用されるため、部分的に変更することはできません。 -> - 現在、 `default`リソース グループのみが`BACKGROUND`構成の変更をサポートしています。 +> - 現在、 `default`リソースグループのみが`BACKGROUND`構成の変更をサポートしています。 ## 例 {#examples} @@ -153,7 +153,7 @@ SELECT * FROM information_schema.resource_groups WHERE NAME ='rg1'; 1 rows in set (1.30 sec) ``` -`BACKGROUND`リソース グループの`default` } オプションを変更します。 +`BACKGROUND`リソースグループの`default` } オプションを変更します。 ```sql ALTER RESOURCE GROUP default BACKGROUND = (TASK_TYPES = "br,ddl", UTILIZATION_LIMIT=30); diff --git a/sql-statements/sql-statement-alter-sequence.md b/sql-statements/sql-statement-alter-sequence.md index 148204262fafa..58dfe456a3276 100644 --- a/sql-statements/sql-statement-alter-sequence.md +++ b/sql-statements/sql-statement-alter-sequence.md @@ -55,7 +55,7 @@ ALTER SEQUENCE sequence_name | `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`1`です。`INCREMENT` < `0`の場合、デフォルト値は`-9223372036854775807`です。 | | `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | | `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | -| `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | +| `CACHE` | `1000` | TiDB 内のシーケンスのローカルキャッシュサイズを指定します。 | | `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | > **Note:** diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index e190fa1223d04..065ec57125975 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -156,7 +156,7 @@ Query OK, 0 rows affected, 1 warning (0.25 sec) TiDB の`ALTER TABLE`には次の主な制限が適用されます。 -- `ALTER TABLE`つのステートメントで複数のスキーマ オブジェクトを変更する場合: +- `ALTER TABLE`つのステートメントで複数のスキーマオブジェクトを変更する場合: - 同じオブジェクトを複数回変更することはサポートされていません。 - TiDBは**実行前に**テーブルスキーマに従ってステートメントを検証します。例えば、 `ALTER TABLE t ADD COLUMN c1 INT, ADD COLUMN c2 INT AFTER c1;`を実行すると、列`c1`テーブルに存在しないためエラーが返されます。 diff --git a/sql-statements/sql-statement-alter-user.md b/sql-statements/sql-statement-alter-user.md index df865a89b8215..cf79751c43126 100644 --- a/sql-statements/sql-statement-alter-user.md +++ b/sql-statements/sql-statement-alter-user.md @@ -167,9 +167,9 @@ SELECT User, Host, max_user_connections FROM mysql.user WHERE User='newuser'; 1 row in set (0.01 sec) ``` -### ユーザーにバインドされているリソース グループを変更する {#modify-the-resource-group-bound-to-the-user} +### ユーザーにバインドされているリソースグループを変更する {#modify-the-resource-group-bound-to-the-user} -`ALTER USER ... RESOURCE GROUP`を使用して、ユーザー`newuser` ～ `rg1`のリソース グループを変更します。 +`ALTER USER ... RESOURCE GROUP`を使用して、ユーザー`newuser` ～ `rg1`のリソースグループを変更します。 ```sql ALTER USER 'newuser' RESOURCE GROUP rg1; @@ -179,7 +179,7 @@ ALTER USER 'newuser' RESOURCE GROUP rg1; Query OK, 0 rows affected (0.02 sec) ``` -現在のユーザーにバインドされているリソース グループを表示する。 +現在のユーザーにバインドされているリソースグループを表示する。 ```sql SELECT USER, JSON_EXTRACT(User_attributes, "$.resource_group") FROM mysql.user WHERE user = "newuser"; @@ -194,7 +194,7 @@ SELECT USER, JSON_EXTRACT(User_attributes, "$.resource_group") FROM mysql.user W 1 row in set (0.02 sec) ``` -ユーザーをリソース グループからバインド解除します。つまり、ユーザーを`default`リソース グループにバインドします。 +ユーザーをリソースグループからバインド解除します。つまり、ユーザーを`default`リソースグループにバインドします。 ```sql ALTER USER 'newuser' RESOURCE GROUP `default`; diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md index dea4da1c74cd4..2a25c1accc3ad 100644 --- a/sql-statements/sql-statement-backup.md +++ b/sql-statements/sql-statement-backup.md @@ -16,7 +16,7 @@ summary: TiDBデータベースにおけるBACKUPの使用方法の概要。 `BACKUP`を実行するには`BACKUP_ADMIN`または`SUPER`権限が必要です。さらに、バックアップを実行する TiDB ノードとクラスタ内のすべての TiKV ノードの両方が、宛先への読み取りまたは書き込み権限を持っている必要があります。 [セキュリティ強化モード](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合、ローカルストレージ( `local://`で始まるストレージパス) は許可されません。 -`BACKUP`ステートメントは、バックアップ タスク全体が完了、失敗、またはキャンセルされるまでブロックされます。 `BACKUP`を実行するには、長時間接続を準備する必要があります。タスクは、[`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md)ステートメントを使用してキャンセルできます。 +`BACKUP`ステートメントは、バックアップタスク全体が完了、失敗、またはキャンセルされるまでブロックされます。 `BACKUP`を実行するには、長時間接続を準備する必要があります。タスクは、[`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md)ステートメントを使用してキャンセルできます。 `BACKUP`および[`RESTORE`](/sql-statements/sql-statement-restore.md)タスクは、一度に 1 つしか実行できません。 `BACKUP`または`RESTORE`ステートメントが同じ TiDBサーバーで既に実行されている場合、新しい`BACKUP`の実行は、以前のすべてのタスクが完了するまで待機します。 diff --git a/sql-statements/sql-statement-cancel-import-job.md b/sql-statements/sql-statement-cancel-import-job.md index 2bbfb495fe8c6..c10e172ce6c28 100644 --- a/sql-statements/sql-statement-cancel-import-job.md +++ b/sql-statements/sql-statement-cancel-import-job.md @@ -5,11 +5,11 @@ summary: TiDB での CANCEL IMPORT の使用法の概要。 # CANCEL IMPORT {#cancel-import} -`CANCEL IMPORT`ステートメントは、TiDB で作成されたデータ インポート ジョブをキャンセルするために使用されます。 +`CANCEL IMPORT`ステートメントは、TiDB で作成されたデータインポートジョブをキャンセルするために使用されます。 ## 必要な権限 {#required-privileges} -データ インポート ジョブをキャンセルするには、インポート ジョブの作成者であるか、 `SUPER`権限を持っている必要があります。 +データインポートジョブをキャンセルするには、インポートジョブの作成者であるか、 `SUPER`権限を持っている必要があります。 ## 概要 {#synopsis} @@ -20,7 +20,7 @@ CancelImportJobsStmt ::= ## 例 {#example} -ID が`1`のインポート ジョブをキャンセルするには、次のステートメントを実行します。 +ID が`1`のインポートジョブをキャンセルするには、次のステートメントを実行します。 ```sql CANCEL IMPORT JOB 1; diff --git a/sql-statements/sql-statement-create-binding.md b/sql-statements/sql-statement-create-binding.md index 03c43237944c6..cf94f90c63a9e 100644 --- a/sql-statements/sql-statement-create-binding.md +++ b/sql-statements/sql-statement-create-binding.md @@ -37,9 +37,9 @@ StringLiteralOrUserVariable ::= SQL ステートメントまたは履歴実行計画に従ってバインディングを作成できます。 -履歴実行計画に従ってバインディングを作成する場合は、対応するプラン ダイジェストを指定する必要があります。 +履歴実行計画に従ってバインディングを作成する場合は、対応するプランダイジェストを指定する必要があります。 -- プラン ダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 +- プランダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 - 複数のプランダイジェストを指定して、複数のステートメントのバインディングを同時に作成できます。この場合、複数の文字列を指定し、各文字列に複数のダイジェストを含めることができます。文字列またはダイジェストはカンマで区切る必要があることに注意してください。 次の例は、SQL ステートメントに従ってバインディングを作成する方法を示しています。 diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 5245450488733..7601c805a302e 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -246,7 +246,7 @@ SELECT MAX(LOWER(col1)) FROM t; SELECT MIN(col1) FROM t GROUP BY LOWER(col1); ``` -式インデックスに対応する式を確認するには、 [`SHOW INDEX`](/sql-statements/sql-statement-show-indexes.md)を実行するか、システム テーブル[`information_schema.tidb_indexes`](/information-schema/information-schema-tidb-indexes.md)およびテーブル[`information_schema.STATISTICS`](/information-schema/information-schema-statistics.md)を確認してください。出力の`Expression`列は、対応する式を示します。式インデックス以外の場合は、 `NULL`が表示されます。 +式インデックスに対応する式を確認するには、 [`SHOW INDEX`](/sql-statements/sql-statement-show-indexes.md)を実行するか、システムテーブル[`information_schema.tidb_indexes`](/information-schema/information-schema-tidb-indexes.md)およびテーブル[`information_schema.STATISTICS`](/information-schema/information-schema-statistics.md)を確認してください。出力の`Expression`列は、対応する式を示します。式インデックス以外の場合は、 `NULL`が表示されます。 式インデックスの維持コストは、他のインデックスの維持コストよりも高くなります。これは、行が挿入または更新されるたびに式の値を計算する必要があるためです。式の値は既にインデックスに格納されているため、オプティマイザが式インデックスを選択する際に、この値を再計算する必要はありません。 diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md index a19cd1f3cc371..b3c7643ba2716 100644 --- a/sql-statements/sql-statement-create-resource-group.md +++ b/sql-statements/sql-statement-create-resource-group.md @@ -5,7 +5,7 @@ summary: TiDBにおけるCREATE RESOURCE GROUPの使い方を学びましょう # CREATE RESOURCE GROUP {#create-resource-group} -`CREATE RESOURCE GROUP`ステートメントを使用してリソース グループを作成できます。 +`CREATE RESOURCE GROUP`ステートメントを使用してリソースグループを作成できます。 > **Note:** > @@ -75,7 +75,7 @@ ResourceGroupRunawayActionOption ::= リソースグループ名パラメータ（ `ResourceGroupName` ）は、グローバルに一意である必要があります。 -TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)は、CPU、IO、およびその他のシステム リソースに対する TiDB の統合抽象化ユニットです。 +TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)は、CPU、IO、およびその他のシステムリソースに対する TiDB の統合抽象化ユニットです。 | オプション | 説明 | 例 | | ------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -86,12 +86,12 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで > **Note:** > -> - `CREATE RESOURCE GROUP`ステートメントは、グローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)が`ON`に設定されている場合にのみ実行できます。 TiDB は、クラスタ初期化時に`default`リソース グループを自動的に作成します。 このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) であり、 `BURSTABLE`モードです。いずれのリソースグループにも紐付けられていないすべてのリクエストは、自動的にこの`default`リソースグループに紐付けられます。別のリソースグループの新しい構成を作成する場合は、必要に応じて`default`リソースグループの構成を変更することをお勧めします。 -> - 現在、 `default`リソース グループのみが`BACKGROUND`構成の変更をサポートしています。 +> - `CREATE RESOURCE GROUP`ステートメントは、グローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)が`ON`に設定されている場合にのみ実行できます。 TiDB は、クラスタ初期化時に`default`リソースグループを自動的に作成します。 このリソースグループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) であり、 `BURSTABLE`モードです。いずれのリソースグループにも紐付けられていないすべてのリクエストは、自動的にこの`default`リソースグループに紐付けられます。別のリソースグループの新しい構成を作成する場合は、必要に応じて`default`リソースグループの構成を変更することをお勧めします。 +> - 現在、 `default`リソースグループのみが`BACKGROUND`構成の変更をサポートしています。 ## 例 {#examples} -`rg1`と`rg2` 2 つのリソース グループを作成します。 +`rg1`と`rg2` 2 つのリソースグループを作成します。 ```sql DROP RESOURCE GROUP IF EXISTS rg1; diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index ca07743eadd56..bf2ba39e81196 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -58,7 +58,7 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name | `MINVALUE` | `1`または`-9223372036854775807` | シーケンスの最小値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`1`です。`INCREMENT` < `0`の場合、デフォルト値は`-9223372036854775807`です。 | | `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | | `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | -| `CACHE` | `1000` | TiDB 内のシーケンスのローカル キャッシュ サイズを指定します。 | +| `CACHE` | `1000` | TiDB 内のシーケンスのローカルキャッシュサイズを指定します。 | | `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | ## `SEQUENCE`関数 {#sequence-function} diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md index 060118087a9fe..cd9b7f134a2ba 100644 --- a/sql-statements/sql-statement-create-table.md +++ b/sql-statements/sql-statement-create-table.md @@ -298,7 +298,7 @@ mysql> DESC t1; - `[ASC | DESC]`内の`index_col_name`は現在解析されますが無視されます (MySQL 5.7互換の動作)。 - `COMMENT`属性は`WITH PARSER`オプションをサポートしていません。 - TiDBは、デフォルトでは1つのテーブルで1017列、最大4096列をサポートします。InnoDBにおける対応する列数の制限は1017列、MySQLにおけるハードリミットは4096列です。詳細は[TiDBの制限事項](/tidb-limitations.md)を参照してください。 -- TiDB は`HASH` 、 `RANGE` 、 `LIST` 、および`KEY`サポートしています[パーティショニングの種類](/partitioned-table.md#partitioning-types)されていないパーティション タイプの場合、TiDB は`Warning: Unsupported partition type %s, treat as normal table`を返します。ここで、 `%s`はサポートされていない特定のパーティション タイプです。 +- TiDB は`HASH` 、 `RANGE` 、 `LIST` 、および`KEY`サポートしています[パーティショニングの種類](/partitioned-table.md#partitioning-types)されていないパーティションタイプの場合、TiDB は`Warning: Unsupported partition type %s, treat as normal table`を返します。ここで、 `%s`はサポートされていない特定のパーティションタイプです。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-create-user.md b/sql-statements/sql-statement-create-user.md index f41bdddd51127..f743351aae1a1 100644 --- a/sql-statements/sql-statement-create-user.md +++ b/sql-statements/sql-statement-create-user.md @@ -158,7 +158,7 @@ SELECT User, Host, max_user_connections FROM mysql.user WHERE User='newuser10'; 1 row in set (0.01 sec) ``` -リソース グループ`rg1`を使用するユーザーを作成します。 +リソースグループ`rg1`を使用するユーザーを作成します。 ```sql CREATE USER 'newuser11'@'%' RESOURCE GROUP rg1; diff --git a/sql-statements/sql-statement-drop-binding.md b/sql-statements/sql-statement-drop-binding.md index 83fb91e2a18b2..d25459db0c9be 100644 --- a/sql-statements/sql-statement-drop-binding.md +++ b/sql-statements/sql-statement-drop-binding.md @@ -35,7 +35,7 @@ SQL ステートメントまたは SQL ダイジェストに従ってバイン SQL ダイジェストに従ってバインディングを削除する場合は、対応する SQL ダイジェストを指定する必要があります。 -- プラン ダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 +- プランダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 - 複数の文字列値を指定し、各文字列に複数のダイジェストを含めることができます。文字列またはダイジェストはカンマで区切る必要があることに注意してください。 次の例は、SQL ステートメントに従ってバインディングを削除する方法を示しています。 diff --git a/sql-statements/sql-statement-drop-resource-group.md b/sql-statements/sql-statement-drop-resource-group.md index 640ae7a3972a4..62422cb676838 100644 --- a/sql-statements/sql-statement-drop-resource-group.md +++ b/sql-statements/sql-statement-drop-resource-group.md @@ -5,7 +5,7 @@ summary: TiDBにおけるDROP RESOURCE GROUPの使い方を学びましょう。 # DROP RESOURCE GROUP {#drop-resource-group} -`DROP RESOURCE GROUP`ステートメントを使用してリソース グループを削除できます。 +`DROP RESOURCE GROUP`ステートメントを使用してリソースグループを削除できます。 > **Note:** > @@ -28,11 +28,11 @@ ResourceGroupName ::= > **Note:** > > - `DROP RESOURCE GROUP`ステートメントは、グローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)が`ON`に設定されている場合にのみ実行できます。 -> - `default`リソース グループは予約済みであり、削除できません。 +> - `default`リソースグループは予約済みであり、削除できません。 ## 例 {#examples} -`rg1`という名前のリソース グループを削除します。 +`rg1`という名前のリソースグループを削除します。 ```sql DROP RESOURCE GROUP IF EXISTS rg1; diff --git a/sql-statements/sql-statement-drop-stats.md b/sql-statements/sql-statement-drop-stats.md index e131f0c9f027e..74e9c5a296e13 100644 --- a/sql-statements/sql-statement-drop-stats.md +++ b/sql-statements/sql-statement-drop-stats.md @@ -39,7 +39,7 @@ DROP STATS TableName PARTITION PartitionNameList; Query OK, 0 rows affected (0.00 sec) ``` -次のステートメントは、指定されたテーブルの動的プルーニング モードで生成されたグローバル統計のみを削除します。 +次のステートメントは、指定されたテーブルの動的プルーニングモードで生成されたグローバル統計のみを削除します。 ```sql DROP STATS TableName GLOBAL; diff --git a/sql-statements/sql-statement-explain-analyze.md b/sql-statements/sql-statement-explain-analyze.md index 9bc829b0c9b95..c6926b380e4d4 100644 --- a/sql-statements/sql-statement-explain-analyze.md +++ b/sql-statements/sql-statement-explain-analyze.md @@ -147,7 +147,7 @@ prepare:109.616µs, check_insert:{total_time:1.431678ms, mem_insert_time:667.878 1. 外側のワーカーは N 個の外側の行を読み取り、それをタスクにラップして、結果チャネルと内側のワーカー チャネルに送信します。 2. 内部ワーカーはタスクを受け取り、タスクからキー範囲を構築し、キー範囲に従って内部行を取得します。そして、内部行ハッシュテーブルを構築します。 3. メイン`IndexJoin`スレッドは結果チャネルからタスクを受け取り、内部ワーカーがタスクの処理を完了するまで待機します。 -4. メイン`IndexJoin`スレッドは、内側の行のハッシュ テーブルを参照して、各外側の行を結合します。 +4. メイン`IndexJoin`スレッドは、内側の行のハッシュテーブルを参照して、各外側の行を結合します。 `IndexJoin`演算子には次の実行情報が含まれています。 @@ -161,8 +161,8 @@ inner:{total:4.297515932s, concurrency:5, task:17, construct:97.96291ms, fetch:4 - `task` : 内部ワーカーによって処理されたタスクの合計数。 - `construct` : 内部ワーカーがタスクに対応する内部テーブル行を読み取る前の準備時間。 - `fetch` : 内部ワーカーが内部テーブル行を読み取るのにかかる合計時間。 - - `Build` : 内部ワーカーが対応する内部テーブル行のハッシュ テーブルを構築するのにかかる合計時間。 -- `probe` : メイン`IndexJoin`スレッドが外部テーブル行と内部テーブル行のハッシュ テーブルとの結合操作を実行するのに費やした合計時間。 + - `Build` : 内部ワーカーが対応する内部テーブル行のハッシュテーブルを構築するのにかかる合計時間。 +- `probe` : メイン`IndexJoin`スレッドが外部テーブル行と内部テーブル行のハッシュテーブルとの結合操作を実行するのに費やした合計時間。 ### IndexHashJoin {#indexhashjoin} @@ -184,17 +184,17 @@ inner:{total:4.429220003s, concurrency:5, task:17, construct:96.207725ms, fetch: - `task` : 内部ワーカーによって処理されたタスクの合計数。 - `construct` : 内部ワーカーが内部テーブルの行を読み取る前の準備時間。 - `fetch` : 内部ワーカーが内部テーブル行を読み取るのに費やされた合計時間。 - - `Build` : 内部ワーカーが外部テーブル行のハッシュ テーブルを構築するのに費やされた合計時間。 - - `join` : 内部ワーカーが内部テーブル行と外部テーブル行のハッシュ テーブルを結合するのにかかる合計時間。 + - `Build` : 内部ワーカーが外部テーブル行のハッシュテーブルを構築するのに費やされた合計時間。 + - `join` : 内部ワーカーが内部テーブル行と外部テーブル行のハッシュテーブルを結合するのにかかる合計時間。 ### HashJoin {#hashjoin} `HashJoin`演算子は、内部ワーカー、外部ワーカー、および N 個の結合ワーカーで構成されます。詳細な実行プロセスは次のとおりです。 -1. 内部ワーカーは内部テーブルの行を読み取り、ハッシュ テーブルを構築します。 +1. 内部ワーカーは内部テーブルの行を読み取り、ハッシュテーブルを構築します。 2. 外部ワーカーは外部テーブルの行を読み取り、それをタスクにラップして結合ワーカーに送信します。 -3. 結合ワーカーは、ステップ 1 のハッシュ テーブルの構築が完了するまで待機します。 -4. 結合ワーカーは、タスク内の外部テーブルの行とハッシュ テーブルを使用して結合操作を実行し、結合結果を結果チャネルに送信します。 +3. 結合ワーカーは、ステップ 1 のハッシュテーブルの構築が完了するまで待機します。 +4. 結合ワーカーは、タスク内の外部テーブルの行とハッシュテーブルを使用して結合操作を実行し、結合結果を結果チャネルに送信します。 5. `HashJoin`のメイン スレッドは結果チャネルから結合結果を受信します。 `HashJoin`演算子には次の実行情報が含まれています。 @@ -206,12 +206,12 @@ build_hash_table:{total:146.071334ms, fetch:110.338509ms, build:35.732825ms}, pr - `build_hash_table` : 内部テーブルのデータを読み取り、ハッシュテーブルの実行情報を構築します。 - `total` : 合計消費時間。 - `fetch` : 内部テーブルデータの読み取りに費やされた合計時間。 - - `build` : ハッシュ テーブルの構築に費やされた合計時間。 + - `build` : ハッシュテーブルの構築に費やされた合計時間。 - `probe` : 結合ワーカーの実行情報: - `concurrency` : 結合ワーカーの数。 - `total` : すべての結合ワーカーによって消費された合計時間。 - `max` : 単一の結合ワーカーが実行される最長時間。 - - `probe` : 外部テーブルの行とハッシュ テーブルとの結合に費やされた合計時間。 + - `probe` : 外部テーブルの行とハッシュテーブルとの結合に費やされた合計時間。 - `fetch` : 結合ワーカーが外部テーブルの行データを読み取るために待機する合計時間。 ### TableFullScan (TiFlash) {#tablefullscan-tiflash} @@ -232,7 +232,7 @@ tiflash_scan: { } ``` -- `dtfile` : テーブル スキャン中の DTFile (DeltaTree ファイル) 関連情報。TiFlashレイヤーのデータ スキャン ステータスを反映します。 +- `dtfile` : テーブルスキャン中の DTFile (DeltaTree ファイル) 関連情報。TiFlashレイヤーのデータスキャン ステータスを反映します。 - `total_scanned_packs` : DTFileでスキャンされたパックの総数。パックとは、 TiFlash DTFileで読み取ることができる最小単位です。デフォルトでは、8192行ごとに1パックが構成されます。 - `total_skipped_packs` : DTFile 内のスキャンでスキップされたパックの総数。`WHERE`が粗集合インデックスにヒットするか、主キーの範囲フィルタリングに一致する場合、無関係なパックはスキップされます。 - `total_scanned_rows` : DTFile でスキャンされた行の総数。MVCC により更新または削除のバージョンが複数ある場合、各バージョンは個別にカウントされます。 diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index 3563093e5a507..19ec04f845206 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -326,7 +326,7 @@ EXPLAIN FORMAT = "tidb_json" SELECT id FROM t WHERE a = 1; `EXPLAIN FOR CONNECTION` 、現在実行中のSQLクエリ、または接続内で最後に実行されたSQLクエリの実行計画を取得するために使用されます。出力形式は`EXPLAIN`と同じです。ただし、TiDBにおける`EXPLAIN FOR CONNECTION`の実装はMySQLとは異なります。出力形式以外の違いは次のとおりです。 -- 接続がスリープ状態の場合、MySQL は空の結果を返しますが、TiDB は最後に実行されたクエリ プランを返します。 +- 接続がスリープ状態の場合、MySQL は空の結果を返しますが、TiDB は最後に実行されたクエリプランを返します。 - 現在のセッションの実行計画を取得しようとすると、MySQL はエラーを返しますが、TiDB は通常どおり結果を返します。 - MySQL では、ログイン ユーザーがクエリ対象の接続と同じであるか、ログイン ユーザーが**`PROCESS`**権限を持っている必要があります。一方、TiDB では、ログイン ユーザーがクエリ対象の接続と同じであるか、ログイン ユーザーが**`SUPER`**権限を持っている必要があります。 diff --git a/sql-statements/sql-statement-flashback-cluster.md b/sql-statements/sql-statement-flashback-cluster.md index 2c17d042dd415..901795cdb1b3c 100644 --- a/sql-statements/sql-statement-flashback-cluster.md +++ b/sql-statements/sql-statement-flashback-cluster.md @@ -48,7 +48,7 @@ FlashbackToTimestampStmt ## 注記 {#notes} -- `FLASHBACK`ステートメントで指定する時間は、ガベージ コレクション (GC) の有効期間内である必要があります。システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) (デフォルト: `10m0s` ) は、行の以前のバージョンの保持時間を定義します。ガベージコレクションが実行された現在の`safePoint`は、次のクエリで取得できます。 +- `FLASHBACK`ステートメントで指定する時間は、ガベージコレクション (GC) の有効期間内である必要があります。システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) (デフォルト: `10m0s` ) は、行の以前のバージョンの保持時間を定義します。ガベージコレクションが実行された現在の`safePoint`は、次のクエリで取得できます。 ```sql SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point'; @@ -61,7 +61,7 @@ FlashbackToTimestampStmt - `FLASHBACK`ステートメントで指定された時点では、完全に実行されていない DDL ステートメントは存在してはなりません。そのような DDL が存在する場合、TiDB はそれを拒否します。 - `FLASHBACK CLUSTER`を実行する前に、TiDB は関連するすべての接続を切断し、 `FLASHBACK CLUSTER`ステートメントが完了するまで、これらのテーブルに対する読み取りおよび書き込み操作を禁止します。 - `FLASHBACK CLUSTER`ステートメントは、実行後にキャンセルすることはできません。TiDB は成功するまで再試行を続けます。 -- `FLASHBACK CLUSTER`の実行中にデータをバックアップする必要がある場合は、[バックアップと復元](/br/br-snapshot-guide.md)を使用し、 `BackupTS`の開始時刻より前の`FLASHBACK CLUSTER`を指定することのみが可能です。さらに、 `FLASHBACK CLUSTER`の実行中、[ログバックアップ](/br/br-pitr-guide.md)有効化は失敗します。したがって、 `FLASHBACK CLUSTER`が完了した後でログ バックアップを有効にしてみてください。 +- `FLASHBACK CLUSTER`の実行中にデータをバックアップする必要がある場合は、[バックアップと復元](/br/br-snapshot-guide.md)を使用し、 `BackupTS`の開始時刻より前の`FLASHBACK CLUSTER`を指定することのみが可能です。さらに、 `FLASHBACK CLUSTER`の実行中、[ログバックアップ](/br/br-pitr-guide.md)有効化は失敗します。したがって、 `FLASHBACK CLUSTER`が完了した後でログバックアップを有効にしてみてください。 - `FLASHBACK CLUSTER`ステートメントによってメタデータ (テーブル構造、データベース構造) のロールバックが発生した場合、関連する変更は TiCDC によって複製され**ません**。そのため、タスクを手動で一時停止し、 `FLASHBACK CLUSTER`の完了を待ってから、上流と下流のスキーマ定義を手動で複製して、それらが整合していることを確認する必要があります。その後、TiCDC 変更フィードを再作成する必要があります。 diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md index 21f4a507f9c25..1fcadd1229d9c 100644 --- a/sql-statements/sql-statement-flashback-table.md +++ b/sql-statements/sql-statement-flashback-table.md @@ -40,7 +40,7 @@ FlashbackToNewName ::= ## 例 {#example} -- `DROP`操作で削除されたテーブル データを回復します。 +- `DROP`操作で削除されたテーブルデータを回復します。 ```sql DROP TABLE t; @@ -70,7 +70,7 @@ FlashbackToNewName ::= 1. TiDBは最近のDDL履歴ジョブを検索し、テーブル`t`で最初のDDL操作（タイプ`DROP TABLE`またはタイプ`truncate table`を見つけます。TiDBが見つけられなかった場合は、エラーが返されます。 2. TiDBは、DDLジョブの開始時刻が`tikv_gc_safe_point`より前かどうかを確認します。`tikv_gc_safe_point`より前の場合、 `DROP`または`TRUNCATE`操作で削除されたテーブルがGCによってクリーンアップされたことを意味し、エラーが返されます。 -3. TiDB は、DDL ジョブの開始時刻をスナップショットとして使用して、履歴データを読み取り、テーブル メタデータを読み取ります。 +3. TiDB は、DDL ジョブの開始時刻をスナップショットとして使用して、履歴データを読み取り、テーブルメタデータを読み取ります。 4. TiDB は`mysql.gc_delete_range`のテーブル`t`に関連する GC タスクを削除します。 5. TiDBはテーブルのメタデータの`name` `t1`に変更し、このメタデータを使用して新しいテーブルを作成します。テーブル名のみが変更され、テーブルIDは変更されないことに注意してください。テーブルIDは、以前に削除されたテーブル`t`と同じです。 diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 329ad3d723c6b..be038802bafdc 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -24,7 +24,7 @@ summary: TiDBにおけるIMPORT INTOの使用方法の概要。 - `IMPORT INTO` 、同じテーブルの他のパーティションに既にデータが含まれている場合、空のパーティションへのデータインポートをサポートしていません。インポート操作を行うには、対象テーブルが完全に空である必要があります。 - `IMPORT INTO`[一時テーブル](/temporary-tables.md)またはキャッシュ[キャッシュされたテーブル](/cached-tables.md)へのデータのインポートをサポートしていません。 - `IMPORT INTO`トランザクションまたはロールバックをサポートしていません。明示的なトランザクション ( `IMPORT INTO` / { `BEGIN`内) で`END`を実行するとエラーが返されます。 -- `IMPORT INTO`は、[バックアップと復元](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)、 [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) 、 [インデックス追加処理の高速化](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)、 TiDB Lightning を使用したデータ インポート、TiCDC を使用したデータ レプリケーション、または[特定時点復旧（PITR）](https://docs.pingcap.com/tidb/stable/br-log-architecture)などの機能との同時作業をサポートしていません。互換性の詳細については、 [TiDB Lightningと`IMPORT INTO`の、TiCDCおよびログバックアップとの互換性](https://docs.pingcap.com/tidb/stable/tidb-lightning-compatibility-and-scenarios)を参照してください。 +- `IMPORT INTO`は、[バックアップと復元](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)、 [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) 、 [インデックス追加処理の高速化](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)、 TiDB Lightning を使用したデータインポート、TiCDC を使用したデータレプリケーション、または[特定時点復旧（PITR）](https://docs.pingcap.com/tidb/stable/br-log-architecture)などの機能との同時作業をサポートしていません。互換性の詳細については、 [TiDB Lightningと`IMPORT INTO`の、TiCDCおよびログバックアップとの互換性](https://docs.pingcap.com/tidb/stable/tidb-lightning-compatibility-and-scenarios)を参照してください。 - データインポート処理中は、対象テーブルに対してDDLまたはDML操作を実行したり、対象データベースに対して[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md)を実行したりしないでください。これらの操作は、インポートの失敗やデータの不整合を引き起こす可能性があります。また、インポート処理中に読み取り操作を実行することも推奨さ**れません**。読み取られるデータに不整合が生じる可能性があるためです。読み取りおよび書き込み操作は、インポートが完了した後にのみ実行してください。 - インポートプロセスはシステムリソースを大幅に消費します。 TiDB セルフマネージドの場合、パフォーマンスを向上させるために、少なくとも 32 コアと 64 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 TiDB はインポート中にソートされたデータを TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)に書き込むため、フラッシュメモリなどの TiDB 自己管理用の高性能ストレージメディアを構成することをお勧めします。詳細については、 [物理インポートモードの制限](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode#requirements-and-restrictions)を参照してください。 - TiDB Self-Managedの場合、TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)は少なくとも90 GiBの空き容量が必要です。インポートするデータ量と同等以上のストレージ容量を割り当てることをお勧めします。 @@ -38,9 +38,9 @@ summary: TiDBにおけるIMPORT INTOの使用方法の概要。 - TiDB Self-Managedの場合、各`IMPORT INTO`タスクは10 TiB以内のデータインポートをサポートします。 機能を有効にすると、各`IMPORT INTO`タスク[グローバルソート](/tidb-global-sort.md)40 TiB以内のデータインポートをサポートします。 - [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)の場合、インポートするデータが 500 GiB を超える場合は、少なくとも 16 コアの TiDB ノードを使用し、[グローバルソート](/tidb-global-sort.md)機能を有効にすることをお勧めします。そうすると、各`IMPORT INTO`タスクは 40 TiB 以内のデータのインポートをサポートします。インポートするデータが 500 GiB 以内である場合、または TiDB ノードのコア数が 16 未満の場合は、[グローバルソート](/tidb-global-sort.md)機能を有効にしないことをお勧めします。 - `IMPORT INTO ... FROM FILE`の実行は、インポートが完了するまで現在の接続をブロックします。ステートメントを非同期で実行するには、 `DETACHED`オプションを追加してください。 -- 最大 16 個の`IMPORT INTO`タスクを各クラスターで同時に実行できます ( [TiDB分散実行フレームワーク（DXF）の使用制限](/tidb-distributed-execution-framework.md#limitation)を参照)。クラスターに十分なリソースが不足している場合、またはタスクの最大数に達している場合、新しく送信されたインポート タスクは実行のためにキューに入れられます。 +- 最大 16 個の`IMPORT INTO`タスクを各クラスターで同時に実行できます ( [TiDB分散実行フレームワーク（DXF）の使用制限](/tidb-distributed-execution-framework.md#limitation)を参照)。クラスターに十分なリソースが不足している場合、またはタスクの最大数に達している場合、新しく送信されたインポートタスクは実行のためにキューに入れられます。 - データのインポートに[グローバルソート](/tidb-global-sort.md)機能を使用する場合、 `THREAD`オプションの値は少なくとも`8`である必要があります。 -- [グローバルソート](/tidb-global-sort.md)機能を使用してデータをインポートする場合、エンコード後の 1 行のデータ サイズは 32 MiB を超えてはなりません。 +- [グローバルソート](/tidb-global-sort.md)機能を使用してデータをインポートする場合、エンコード後の 1 行のデータサイズは 32 MiB を超えてはなりません。 - [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっていないときに作成されたすべての`IMPORT INTO`タスクは、タスクが送信されたノードで直接実行され、後で DXF が有効になった後でも、他の TiDB ノードで実行するようにスケジュールされません。DXF が有効になった後は、S3 または GCS からデータをインポートする新しく作成された`IMPORT INTO`タスクのみが、自動的にスケジュールされるか、他の TiDB ノードにフェイルオーバーして実行されます。 ### `IMPORT INTO ... FROM SELECT`制限 {#import-into-from-select-restrictions} @@ -98,7 +98,7 @@ OptionItem ::= ### 列名またはユーザー変数リスト {#columnnameoruservarlist} -これは、データ ファイル内の各フィールドがターゲット テーブルの列にどのように対応するかを指定します。また、フィールドを変数にマッピングしてインポート時に特定のフィールドをスキップしたり、 `SetClause`で使用したりすることもできます。 +これは、データファイル内の各フィールドがターゲットテーブルの列にどのように対応するかを指定します。また、フィールドを変数にマッピングしてインポート時に特定のフィールドをスキップしたり、 `SetClause`で使用したりすることもできます。 - このパラメータが指定されていない場合、データファイルの各行のフィールド数は、対象テーブルの列数と一致する必要があります。フィールドは、対応する列に順番にインポートされます。 - このパラメータを指定する場合、指定する列数または変数数は、データファイルの各行のフィールド数と一致していなければなりません。 @@ -119,7 +119,7 @@ OptionItem ::= > **Note:** > -> ターゲット クラスターで[SEM](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合、 `fileLocation`をローカル ファイル パスとして指定することはできません。 +> ターゲットクラスターで[SEM](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合、 `fileLocation`をローカルファイルパスとして指定することはできません。 `fileLocation`パラメータでは、単一のファイルを指定するか、 `*`および`[]`ワイルドカードを使用して、インポートする複数のファイルに一致させることができます。ワイルドカードはファイル名にのみ使用できることに注意してください。ディレクトリには一致せず、サブディレクトリ内のファイルも再帰的に一致しません。Amazon S3 に保存されているファイルを例にとると、パラメータは次のように設定できます。 @@ -132,7 +132,7 @@ OptionItem ::= ### 形式 {#format} -`IMPORT INTO`ステートメントは、 `CSV` 、 `SQL` 、および`PARQUET`データ ファイル形式をサポートしています。指定しない場合、デフォルトの形式は`CSV`です。 +`IMPORT INTO`ステートメントは、 `CSV` 、 `SQL` 、および`PARQUET`データファイル形式をサポートしています。指定しない場合、デフォルトの形式は`CSV`です。 ### オプション付き {#withoptions} @@ -148,15 +148,15 @@ OptionItem ::= | `FIELDS_ESCAPED_BY=''` | CSV | フィールドのエスケープ文字を指定します。デフォルトのエスケープ文字は`\`です。 | | `FIELDS_DEFINED_NULL_BY=''` | CSV | フィールド内の`NULL`を表す値を指定します。デフォルト値は`\N`です。 | | `LINES_TERMINATED_BY=''` | CSV | 行末文字を指定します。デフォルトでは、 `IMPORT INTO`は、 `\n` 、 `\r` 、または`\r\n`行末文字として自動的に識別します。行末文字がこれら 3 つのいずれかである場合は、このオプションを明示的に指定する必要はありません。 | -| `SKIP_ROWS=` | CSV | スキップする行数を指定します。デフォルト値は`0`です。このオプションを使用すると、CSV ファイルのヘッダーをスキップできます。インポートするソース ファイルを指定するためにワイルド カードを使用する場合、このオプションは`fileLocation`のワイルド カードに一致するすべてのソース ファイルに適用されます。 | +| `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% を超えないようにしてください。 | | `DISABLE_TIKV_IMPORT_MODE` | すべてのファイル形式 | インポート処理中に TiKV をインポートモードに切り替える機能を無効にするかどうかを指定します。デフォルトでは、TiKV をインポートモードに切り替える機能は無効になっていません。クラスタ内で読み書き操作が進行中の場合は、このオプションを有効にすることで、インポート処理による影響を回避できます。 | | `THREAD=` | `SELECT`のすべてのファイル形式とクエリ結果 | インポートの同時実行数を指定します。 `IMPORT INTO ... FROM FILE`の場合、 `THREAD`のデフォルト値は TiDB ノードの CPU コア数の 50%、最小値は`1` 、最大値は CPU コア数です。 `IMPORT INTO ... FROM SELECT`の場合、 `THREAD`のデフォルト値は`2` 、最小値は`1` 、最大値は TiDB ノードの CPU コア数の 2 倍です。データのない新しいクラスタにデータをインポートする場合は、インポートのパフォーマンスを向上させるために、この同時実行数を適切に増やすことをお勧めします。対象クラスターが既に本番環境で使用されている場合は、アプリケーションの要件に応じてこの同時実行数を調整することをお勧めします。 | | `MAX_WRITE_SPEED=''` | すべてのファイル形式 | TiKVノードへの書き込み速度を制御します。デフォルトでは速度制限はありません。たとえば、このオプションを`1MiB`と指定すると、書き込み速度を1 MiB/sに制限できます。 | -| `CHECKSUM_TABLE=''` | すべてのファイル形式 | インポート後にターゲット テーブルに対してチェックサム チェックを実行してインポートの整合性を検証するかどうかを設定します。サポートされている値は、 `"required"` (デフォルト)、 `"optional"` 、および`"off"`です。 `"required"`インポート後にチェックサム チェックを実行することを意味します。チェックサム チェックが失敗した場合、TiDB はエラーを返し、インポートは終了します。 `"optional"`インポート後にチェックサム チェックを実行することを意味します。エラーが発生した場合、TiDB は警告を返し、エラーを無視します。 `"off"`インポート後にチェックサム チェックを実行しないことを意味します。 | +| `CHECKSUM_TABLE=''` | すべてのファイル形式 | インポート後にターゲットテーブルに対してチェックサム チェックを実行してインポートの整合性を検証するかどうかを設定します。サポートされている値は、 `"required"` (デフォルト)、 `"optional"` 、および`"off"`です。 `"required"`インポート後にチェックサム チェックを実行することを意味します。チェックサム チェックが失敗した場合、TiDB はエラーを返し、インポートは終了します。 `"optional"`インポート後にチェックサム チェックを実行することを意味します。エラーが発生した場合、TiDB は警告を返し、エラーを無視します。 `"off"`インポート後にチェックサム チェックを実行しないことを意味します。 | | `DETACHED` | すべてのファイル形式 | `IMPORT INTO`非同期で実行するかどうかを制御します。このオプションを有効にすると、 `IMPORT INTO`の実行によりインポートジョブの情報 ( `Job_ID`など) がすぐに返され、ジョブはバックエンドで非同期に実行されます。 | -| `CLOUD_STORAGE_URI` | すべてのファイル形式 | [グローバルソート](/tidb-global-sort.md)用のエンコードされた KV データが保存されるターゲット アドレスを指定します。 `CLOUD_STORAGE_URI`が指定されていない場合、 `IMPORT INTO`システム変数[`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)の値に基づいてグローバル ソートを使用するかどうかを決定します。このシステム変数でターゲットストレージアドレスが指定されている場合、 `IMPORT INTO`このアドレスをグローバル ソートに使用します。 `CLOUD_STORAGE_URI`に空でない値が指定されている場合、 `IMPORT INTO`その値をターゲットストレージアドレスとして使用します。 `CLOUD_STORAGE_URI`に空の値が指定されている場合、ローカル ソートが適用されます。現在、ターゲットストレージアドレスは S3 のみをサポートしています。URI 構成の詳細については、 [Amazon S3 URI形式](/external-storage-uri.md#amazon-s3-uri-format)を参照してください。この機能を使用する場合、すべての TiDB ノードは、対象の S3 バケットに対する読み取りおよび書き込みアクセス権を持っている必要があり、少なくとも次の権限が必要です: `s3:ListBucket` 、 `s3:GetObject` 、 `s3:DeleteObject` 、 `s3:PutObject` 、 `s3: AbortMultipartUpload` 。 | +| `CLOUD_STORAGE_URI` | すべてのファイル形式 | [グローバルソート](/tidb-global-sort.md)用のエンコードされた KV データが保存されるターゲット アドレスを指定します。 `CLOUD_STORAGE_URI`が指定されていない場合、 `IMPORT INTO`システム変数[`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)の値に基づいてグローバルソートを使用するかどうかを決定します。このシステム変数でターゲットストレージアドレスが指定されている場合、 `IMPORT INTO`このアドレスをグローバルソートに使用します。 `CLOUD_STORAGE_URI`に空でない値が指定されている場合、 `IMPORT INTO`その値をターゲットストレージアドレスとして使用します。 `CLOUD_STORAGE_URI`に空の値が指定されている場合、ローカル ソートが適用されます。現在、ターゲットストレージアドレスは S3 のみをサポートしています。URI 構成の詳細については、 [Amazon S3 URI形式](/external-storage-uri.md#amazon-s3-uri-format)を参照してください。この機能を使用する場合、すべての TiDB ノードは、対象の S3 バケットに対する読み取りおよび書き込みアクセス権を持っている必要があり、少なくとも次の権限が必要です: `s3:ListBucket` 、 `s3:GetObject` 、 `s3:DeleteObject` 、 `s3:PutObject` 、 `s3: AbortMultipartUpload` 。 | | `DISABLE_PRECHECK` | `SELECT`のすべてのファイル形式とクエリ結果 | このオプションを設定すると、CDCやPITRタスクの有無など、重要度の低い項目の事前チェックが無効になります。 | @@ -171,7 +171,7 @@ OptionItem ::= TiDB Self-Managed の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3、GCS、および TiDB ローカルストレージに保存されているファイルからのデータインポートをサポートしています。 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3 および GCS に保存されているファイルからのデータインポートをサポートしています。 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3 および Alibaba Cloud OSS に保存されているファイルからのデータインポートをサポートしています。 -- Amazon S3 または GCS に保存されているデータ ファイルの場合、 `IMPORT INTO ... FROM FILE` [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)での実行をサポートしています。 +- Amazon S3 または GCS に保存されているデータファイルの場合、 `IMPORT INTO ... FROM FILE` [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)での実行をサポートしています。 - DXF が有効になっている場合 ( [tidb_enable_dist_task](/system-variables.md#tidb_enable_dist_task-new-in-v710)が`ON`の場合)、 `IMPORT INTO`データインポートジョブを複数のサブジョブに分割し、これらのサブジョブを異なる TiDB ノードに分散して実行することで、インポート効率を向上させます。 - DXF が無効になっている場合、 `IMPORT INTO ... FROM FILE`現在のユーザーが接続している TiDB ノードでの実行のみをサポートします。 @@ -207,7 +207,7 @@ TiDB Self-Managed の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3、GCS、 - `IMPORT INTO` 、データファイルの走査順序に基づいてサブジョブを分割します。通常は、ファイル名で辞書順にソートされます。 - 対象テーブルに多数のインデックスが存在する場合、またはインデックス列の値がデータファイル内に分散している場合、各サブジョブのエンコードによって生成されるインデックスKVも重複します。 -[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合、 `CLOUD_STORAGE_URI` `IMPORT INTO`を指定するか、システム変数[`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)を使用してエンコードされた KV データのターゲットストレージアドレスを指定することで、[グローバルソート](/tidb-global-sort.md)を有効にできます。現在、グローバル ソートはストレージアドレスとして Amazon S3 の使用をサポートしています。グローバル ソートが有効になっている場合、 `IMPORT INTO`はエンコードされた KV データをクラウドストレージに書き込み、クラウドストレージでグローバル ソートを実行し、グローバルにソートされたインデックスとテーブル データを TiKV に並列にインポートします。これにより、KV の重複によって発生する問題が防止され、インポートの安定性とパフォーマンスが向上します。 +[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合、 `CLOUD_STORAGE_URI` `IMPORT INTO`を指定するか、システム変数[`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)を使用してエンコードされた KV データのターゲットストレージアドレスを指定することで、[グローバルソート](/tidb-global-sort.md)を有効にできます。現在、グローバルソートはストレージアドレスとして Amazon S3 の使用をサポートしています。グローバルソートが有効になっている場合、 `IMPORT INTO`はエンコードされた KV データをクラウドストレージに書き込み、クラウドストレージでグローバルソートを実行し、グローバルにソートされたインデックスとテーブルデータを TiKV に並列にインポートします。これにより、KV の重複によって発生する問題が防止され、インポートの安定性とパフォーマンスが向上します。 グローバルソートは大量のメモリリソースを消費します。データインポートの前に、 [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)および[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)変数を設定することをお勧めします。これにより、Go言語のガベージコレクションが頻繁にトリガーされることを防ぎ、インポート効率への影響を軽減できます。 @@ -249,7 +249,7 @@ IMPORT INTO t FROM '/path/to/small.csv' WITH DETACHED; ### インポートジョブの表示と管理 {#view-and-manage-import-jobs} -`DETACHED`モードが有効になっているインポート ジョブの場合、 [`SHOW IMPORT`](/sql-statements/sql-statement-show-import-job.md)を使用して現在のジョブの進行状況を表示できます。 +`DETACHED`モードが有効になっているインポートジョブの場合、 [`SHOW IMPORT`](/sql-statements/sql-statement-show-import-job.md)を使用して現在のジョブの進行状況を表示できます。 インポートジョブが開始された後、 [`CANCEL IMPORT JOB `](/sql-statements/sql-statement-cancel-import-job.md)を使用してキャンセルできます。 @@ -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-load-data.md b/sql-statements/sql-statement-load-data.md index 998bae402f7bb..25c367b997171 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -46,9 +46,9 @@ Fields ::= ### `LOCAL` {#local} -`LOCAL`を使用して、インポートするクライアント上のデータ ファイルを指定できます。ファイル パラメーターは、クライアント上のファイル システム パスである必要があります。 +`LOCAL`を使用して、インポートするクライアント上のデータファイルを指定できます。ファイル パラメーターは、クライアント上のファイルシステム パスである必要があります。 -TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使用してローカル データ ファイルをロードするには、 TiDB Cloudに接続するときに接続文字列に`--local-infile`オプションを追加する必要があります。 +TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使用してローカルデータファイルをロードするには、 TiDB Cloudに接続するときに接続文字列に`--local-infile`オプションを追加する必要があります。 - 以下は、 TiDB Cloud Starter の接続文字列の例です。 @@ -101,7 +101,7 @@ TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使 - `FIELDS ENCLOSED BY` : データの囲み文字を指定します。 - `LINES TERMINATED BY` : 特定の文字で行を終了する場合に、行末文字を指定します。 -`DEFINED NULL BY`を使用すると、データ ファイル内で NULL 値をどのように表現するかを指定できます。 +`DEFINED NULL BY`を使用すると、データファイル内で NULL 値をどのように表現するかを指定できます。 - MySQL の動作と一致して、 `ESCAPED BY`が NULL でない場合、たとえばデフォルト値`\`が使用されると、 `\N`は NULL 値と見なされます。 - `DEFINED NULL BY 'my-null'`のように`DEFINED NULL BY`を使用すると、 `my-null`は NULL 値と見なされます。 @@ -192,10 +192,10 @@ IGNORE 1 LINES; > - 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`ステートメントは常に楽観的トランザクション モードで実行されます。 +> - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクションモードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクションモードで実行されます。 > - v7.6.0 以降、TiDB は他の DML ステートメントと同じ方法で`LOAD DATA` in トランザクションを処理します。 > - `LOAD DATA`ステートメントは、現在のトランザクションをコミットせず、新しいトランザクションを開始しません。 -> - `LOAD DATA`ステートメントは、TiDB トランザクション モード設定 (楽観的または悲観的トランザクション) の影響を受けます。 +> - `LOAD DATA`ステートメントは、TiDB トランザクションモード設定 (楽観的または悲観的トランザクション) の影響を受けます。 > - トランザクション内の`LOAD DATA`のステートメントは、トランザクション内の[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)のステートメントによってロールバックできます。 @@ -209,10 +209,10 @@ IGNORE 1 LINES; > - 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`ステートメントは常に楽観的トランザクション モードで実行されます。 +> - TiDB v7.6.0 より前のバージョンでは、TiDB トランザクションモードの構成に関係なく、 `LOAD DATA`ステートメントは常に楽観的トランザクションモードで実行されます。 > - v7.6.0 以降、TiDB は他の DML ステートメントと同じ方法で`LOAD DATA` in トランザクションを処理します。 > - `LOAD DATA`ステートメントは、現在のトランザクションをコミットせず、新しいトランザクションを開始しません。 -> - `LOAD DATA`ステートメントは、TiDB トランザクション モード設定 (楽観的または悲観的トランザクション) の影響を受けます。 +> - `LOAD DATA`ステートメントは、TiDB トランザクションモード設定 (楽観的または悲観的トランザクション) の影響を受けます。 > - トランザクション内の`LOAD DATA`のステートメントは、トランザクション内の[`ROLLBACK`](/sql-statements/sql-statement-rollback.md)のステートメントによってロールバックできます。 diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index 08f18ffdd243d..6349a7a834733 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -13,16 +13,16 @@ TiDBでは、クライアントセッションがテーブルロックを取得 `LOCK TABLES` 、現在のクライアントセッションのテーブルロックを取得します。ロック対象となる各オブジェクトに対して`LOCK TABLES`および`SELECT`権限を持っている場合は、共通テーブルのテーブルロックを取得できます。 -`UNLOCK TABLES`は、現在のセッションによって保持されているすべてのテーブル ロックを明示的に解放します。`LOCK TABLES`は、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブル ロックを暗黙的に解放します。 +`UNLOCK TABLES`は、現在のセッションによって保持されているすべてのテーブルロックを明示的に解放します。`LOCK TABLES`は、新しいロックを取得する前に、現在のセッションによって保持されているすべてのテーブルロックを暗黙的に解放します。 テーブルロックは、他のセッションによる読み取りや書き込みから保護します。 `WRITE`ロックを保持しているセッションは、 `DROP TABLE`や`TRUNCATE TABLE`などのテーブルレベルの操作を実行できます。 > **Note:** > -> テーブル ロック機能はデフォルトで無効になっています。 +> テーブルロック機能はデフォルトで無効になっています。 > -> - TiDB Self-Managed の場合、テーブル ロック機能を有効にするには、すべての TiDB インスタンスの構成ファイルで[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) ～ `true`設定する必要があります。 -> - TiDB Cloud Dedicated の場合、テーブル ロック機能を有効にするには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400)を`true`に設定する必要があります。 +> - TiDB Self-Managed の場合、テーブルロック機能を有効にするには、すべての TiDB インスタンスの構成ファイルで[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400) ～ `true`設定する必要があります。 +> - TiDB Cloud Dedicated の場合、テーブルロック機能を有効にするには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)連絡して[`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400)を`true`に設定する必要があります。 > - [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、 [`enable-table-lock`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#enable-table-lock-new-in-v400)から`true`設定はサポートされていません。 ## 概要 {#synopsis} @@ -71,7 +71,7 @@ ERROR 8020 (HY000): Table 't1' was locked in WRITE by server: f4799bcb-cad7-4285 上記のエラーメッセージは、TiDB `f4799bcb-cad7-4285-8a6d-23d3555173f1`の ID `2199023255959`のセッションが既にテーブル`t1`の`WRITE`ロックを保持していることを示しています。したがって、現在のセッションはテーブル`t1`の`READ`ロックを取得できません。 -`LOCK TABLES`つのステートメントで同じテーブル ロックを複数回取得することはできません。 +`LOCK TABLES`つのステートメントで同じテーブルロックを複数回取得することはできません。 ```sql > LOCK TABLES t WRITE, t READ; @@ -89,9 +89,9 @@ ERROR 1066 (42000): Not unique table/alias: 't' ## テーブルロックの制限と条件 {#table-locking-restrictions-and-conditions} -テーブル ロックを保持しているセッションを安全に終了するには、 `KILL`を使用できます。 +テーブルロックを保持しているセッションを安全に終了するには、 `KILL`を使用できます。 -次のデータベース内のテーブルに対してテーブル ロックを取得することはできません。 +次のデータベース内のテーブルに対してテーブルロックを取得することはできません。 - `INFORMATION_SCHEMA` - `PERFORMANCE_SCHEMA` @@ -108,4 +108,4 @@ ERROR 1066 (42000): Not unique table/alias: 't' ### テーブルロックの解除 {#table-lock-release} -TiDB セッションでトランザクションが明示的に開始されると (たとえば、 `BEGIN`ステートメントを使用)、TiDB はセッションによって保持されているテーブル ロックを暗黙的に解放しませんが、MySQL は解放します。 +TiDB セッションでトランザクションが明示的に開始されると (たとえば、 `BEGIN`ステートメントを使用)、TiDB はセッションによって保持されているテーブルロックを暗黙的に解放しませんが、MySQL は解放します。 diff --git a/sql-statements/sql-statement-overview.md b/sql-statements/sql-statement-overview.md index 63f94fda53f81..48d96535a4ba7 100644 --- a/sql-statements/sql-statement-overview.md +++ b/sql-statements/sql-statement-overview.md @@ -170,7 +170,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) | リソースグループを削除します。 | | [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) | 暴走クエリの監視リストを管理します。 | | [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) | リソースグループを設定します。 | -| [`SHOW CREATE RESOURCE GROUP`](/sql-statements/sql-statement-show-create-resource-group.md) | リソース グループの`CREATE`ステートメントを表示します。 | +| [`SHOW CREATE RESOURCE GROUP`](/sql-statements/sql-statement-show-create-resource-group.md) | リソースグループの`CREATE`ステートメントを表示します。 | @@ -183,7 +183,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) | リソースグループを削除します。 | | [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md) | 暴走クエリの監視リストを管理します。 | | [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md) | リソースグループを設定します。 | -| [`SHOW CREATE RESOURCE GROUP`](/sql-statements/sql-statement-show-create-resource-group.md) | リソース グループの`CREATE`ステートメントを表示します。 | +| [`SHOW CREATE RESOURCE GROUP`](/sql-statements/sql-statement-show-create-resource-group.md) | リソースグループの`CREATE`ステートメントを表示します。 | diff --git a/sql-statements/sql-statement-query-watch.md b/sql-statements/sql-statement-query-watch.md index 4b3d420881ca7..8691b37870e15 100644 --- a/sql-statements/sql-statement-query-watch.md +++ b/sql-statements/sql-statement-query-watch.md @@ -5,7 +5,7 @@ summary: TiDBデータベースにおけるQUERY WATCHの使用方法の概要 # QUERY WATCH {#query-watch} -`QUERY WATCH`ステートメントは、リソース グループ内の暴走クエリの監視リストを手動で管理するために使用されます。 +`QUERY WATCH`ステートメントは、リソースグループ内の暴走クエリの監視リストを手動で管理するために使用されます。 > **Note:** > diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md index 6ebe243d789b1..dbbcc0a2ea98b 100644 --- a/sql-statements/sql-statement-recover-table.md +++ b/sql-statements/sql-statement-recover-table.md @@ -5,7 +5,7 @@ summary: TiDB データベースの RECOVER TABLE の使用法の概要。 # RECOVER TABLE {#recover-table} -`RECOVER TABLE` 、 `DROP TABLE`ステートメントが実行された後、GC (ガベージ コレクション) の有効期間内に削除されたテーブルとその上のデータを回復するために使用されます。 +`RECOVER TABLE` 、 `DROP TABLE`ステートメントが実行された後、GC (ガベージコレクション) の有効期間内に削除されたテーブルとその上のデータを回復するために使用されます。 ## 構文 {#syntax} diff --git a/sql-statements/sql-statement-restore.md b/sql-statements/sql-statement-restore.md index ef6a00d0796f1..698f24a2e4f81 100644 --- a/sql-statements/sql-statement-restore.md +++ b/sql-statements/sql-statement-restore.md @@ -112,19 +112,19 @@ RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/' `RATE_LIMIT`を使用して、TiKVノードあたりの平均ダウンロード速度を制限し、ネットワーク帯域幅を削減します。 -リストアが完了する前に、 `RESTORE`はデフォルトでバックアップ ファイル内のデータに対してチェックサムを実行し、データの正当性を検証します。単一テーブルに対するチェックサム タスクのデフォルトの同時実行数は 4 ですが、 `CHECKSUM_CONCURRENCY`パラメータを使用して調整できます。データの検証が不要であると確信している場合は、 `CHECKSUM`パラメータを`FALSE`に設定することでチェックを無効にできます。 +リストアが完了する前に、 `RESTORE`はデフォルトでバックアップファイル内のデータに対してチェックサムを実行し、データの正当性を検証します。単一テーブルに対するチェックサム タスクのデフォルトの同時実行数は 4 ですが、 `CHECKSUM_CONCURRENCY`パラメータを使用して調整できます。データの検証が不要であると確信している場合は、 `CHECKSUM`パラメータを`FALSE`に設定することでチェックを無効にできます。 統計情報がバックアップされている場合、復元時にデフォルトで復元されます。統計情報を復元する必要がない場合は、 `LOAD_STATS`パラメーターを`FALSE`に設定できます。 -システム テーブルはデフォルトで復元されます。システム[権限テーブル](/privilege-management.md#privilege-table)テーブルを復元する必要がない場合は、 `WITH_SYS_TABLE`パラメーターを`FALSE`に設定できます。 +システムテーブルはデフォルトで復元されます。システム[権限テーブル](/privilege-management.md#privilege-table)テーブルを復元する必要がない場合は、 `WITH_SYS_TABLE`パラメーターを`FALSE`に設定できます。 -システム テーブルはデフォルトで復元されます。システム[権限テーブル](https://docs.pingcap.com/tidb/stable/privilege-management#privilege-table)テーブルを復元する必要がない場合は、 `WITH_SYS_TABLE`パラメーターを`FALSE`に設定できます。 +システムテーブルはデフォルトで復元されます。システム[権限テーブル](https://docs.pingcap.com/tidb/stable/privilege-management#privilege-table)テーブルを復元する必要がない場合は、 `WITH_SYS_TABLE`パラメーターを`FALSE`に設定できます。 diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index 1c0348f7481a8..84218fb35cf5d 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -106,7 +106,7 @@ TableSample ::= > **Note:** > -> - バージョン 8.5.6 以降、TiDB は`FOR UPDATE OF`句でテーブル エイリアスの使用をサポートしています。下位互換性を維持するために、エイリアスが定義されている場合でもベース テーブル名を参照できますが、明示的なエイリアスの使用を推奨する警告が表示されます。クエリが異なるデータベースにまたがる同じ名前の複数のテーブル (たとえば`FROM db1.t, db2.t FOR UPDATE OF t` ) に関係する場合、TiDB は現在のデータベース コンテキストではなく、 `FROM`句の順序に基づいて、対象テーブルを左から右に照合するようになりました。曖昧さを避けるため、 `FOR UPDATE OF`句でデータベース名を指定するか、エイリアスを使用することをお勧めします。 +> - バージョン 8.5.6 以降、TiDB は`FOR UPDATE OF`句でテーブルエイリアスの使用をサポートしています。下位互換性を維持するために、エイリアスが定義されている場合でもベース テーブル名を参照できますが、明示的なエイリアスの使用を推奨する警告が表示されます。クエリが異なるデータベースにまたがる同じ名前の複数のテーブル (たとえば`FROM db1.t, db2.t FOR UPDATE OF t` ) に関係する場合、TiDB は現在のデータベース コンテキストではなく、 `FROM`句の順序に基づいて、対象テーブルを左から右に照合するようになりました。曖昧さを避けるため、 `FOR UPDATE OF`句でデータベース名を指定するか、エイリアスを使用することをお勧めします。 > - v6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)サポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQLステートメントを実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQLステートメントのスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、ステートメントの優先度（ `HIGH_PRIORITY` ）は適用されなくなります。 を使用して、異なるSQLステートメントの[リソース制御](/tidb-resource-control-ru-groups.md)使用量を管理することをお勧めします。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-set-password.md b/sql-statements/sql-statement-set-password.md index 5d0669baa8cf6..4ffdaa9b11c36 100644 --- a/sql-statements/sql-statement-set-password.md +++ b/sql-statements/sql-statement-set-password.md @@ -5,7 +5,7 @@ summary: TiDB データベースの SET PASSWORD の使用法の概要。 # SET PASSWORD {#set-password} -このステートメントは、TiDB システム データベース内のユーザー アカウントのユーザー パスワードを変更します。 +このステートメントは、TiDB システムデータベース内のユーザーアカウントのユーザーパスワードを変更します。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-set-resource-group.md b/sql-statements/sql-statement-set-resource-group.md index 9feb45317606b..17608dd73532f 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'; @@ -41,7 +41,7 @@ CREATE RESOURCE GROUP 'rg1' RU_PER_SEC = 1000; ALTER USER 'user1' RESOURCE GROUP `rg1`; ``` -`user1`を使用してログインし、現在のユーザーに紐づけられたリソース グループを表示します。 +`user1`を使用してログインし、現在のユーザーに紐づけられたリソースグループを表示します。 ```sql SELECT CURRENT_RESOURCE_GROUP(); @@ -56,7 +56,7 @@ SELECT CURRENT_RESOURCE_GROUP(); 1 row in set (0.00 sec) ``` -`SET RESOURCE GROUP`を実行して、現在のセッションのリソース グループを`rg2`に設定します。 +`SET RESOURCE GROUP`を実行して、現在のセッションのリソースグループを`rg2`に設定します。 ```sql SET RESOURCE GROUP `rg2`; @@ -72,7 +72,7 @@ SELECT CURRENT_RESOURCE_GROUP(); 1 row in set (0.00 sec) ``` -`SET RESOURCE GROUP`を実行して、現在のセッションでデフォルトのリソース グループを使用するように指定します。 +`SET RESOURCE GROUP`を実行して、現在のセッションでデフォルトのリソースグループを使用するように指定します。 ```sql SET RESOURCE GROUP `default`; diff --git a/sql-statements/sql-statement-set-variable.md b/sql-statements/sql-statement-set-variable.md index 8aca319c65814..b2e6547f210ee 100644 --- a/sql-statements/sql-statement-set-variable.md +++ b/sql-statements/sql-statement-set-variable.md @@ -108,7 +108,7 @@ SELECT @myvar, @myvar + 1; - MySQLでは、 `SET GLOBAL`で行われた変更はレプリカには適用されません。しかし、TiDBでは、 `SET GLOBAL`の適用範囲は特定のシステム変数によって異なります。 - グローバル変数: ほとんどのシステム変数 (たとえば、クラスターの動作やオプティマイザーの動作に影響するもの) の場合、 `SET GLOBAL`で行われた変更はクラスター内のすべての TiDB インスタンスに適用されます。 - - インスタンス レベルの変数: 一部のシステム変数 (たとえば、 `max_connections` ) の場合、 `SET GLOBAL`で行われた変更は、現在の接続で使用されている TiDB インスタンスにのみ適用されます。 + - インスタンスレベルの変数: 一部のシステム変数 (たとえば、 `max_connections` ) の場合、 `SET GLOBAL`で行われた変更は、現在の接続で使用されている TiDB インスタンスにのみ適用されます。 したがって、 `SET GLOBAL`を使用して変数を変更する場合は、常にその変数の[ドキュメント](/system-variables.md) 、特に「クラスターに保持」属性をチェックして、変更の範囲を確認してください。 diff --git a/sql-statements/sql-statement-show-affinity.md b/sql-statements/sql-statement-show-affinity.md index 05639bdb060de..5ac971a50d302 100644 --- a/sql-statements/sql-statement-show-affinity.md +++ b/sql-statements/sql-statement-show-affinity.md @@ -43,10 +43,10 @@ SHOW AFFINITY; - `Leader_store_id` 、 `Voter_store_ids` : PDによって記録されたTiKVストアのID。テーブルまたはパーティションのターゲットLeaderとVoterレプリカをホストするストアを示します。アフィニティグループのターゲットレプリカの場所が決定されていない場合、または[`schedule.affinity-schedule-limit`](/pd-configuration-file.md#affinity-schedule-limit-new-in-v855) `0`に設定されている場合、値は`NULL`と表示されます。 - `Status` : アフィニティスケジューリングの現在の状態を示します。可能な値は次のとおりです。 - - `Pending` : リーダーまたは投票者がまだ決定されていない場合など、PD はテーブルまたはパーティションのアフィニティ スケジューリングを開始していません。 + - `Pending` : リーダーまたは投票者がまだ決定されていない場合など、PD はテーブルまたはパーティションのアフィニティスケジューリングを開始していません。 - `Preparing` : PD はアフィニティ要件を満たすようにリージョンをスケジュールしています。 - `Stable` : すべてのリージョンが目標配布に到達しました。 -- `Region_count` : アフィニティ グループ内の現在のリージョン数。 +- `Region_count` : アフィニティグループ内の現在のリージョン数。 - `Affinity_region_count` : 現在アフィニティレプリカ分散要件を満たしているリージョンの数。 - `Affinity_region_count` `Region_count`未満の場合、一部のリージョンがアフィニティに基づいてレプリカのスケジュールをまだ完了していないことを示します。 - `Affinity_region_count` `Region_count`に等しい場合、アフィニティに基づくレプリカのスケジューリングが完了していることを示します。つまり、関連するすべてのリージョンの分散がアフィニティ要件を満たしていることを意味します。ただし、これは関連するリージョンのマージ操作が完了したことを示すものではありません。 diff --git a/sql-statements/sql-statement-show-analyze-status.md b/sql-statements/sql-statement-show-analyze-status.md index c6b90e323c59b..eed35ac82df54 100644 --- a/sql-statements/sql-statement-show-analyze-status.md +++ b/sql-statements/sql-statement-show-analyze-status.md @@ -9,9 +9,9 @@ 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`タスクの進行状況を表示できます。 +TiDB v7.3.0 以降では、システムテーブル`mysql.analyze_jobs`または`SHOW ANALYZE STATUS`を通じて現在の`ANALYZE`タスクの進行状況を表示できます。 現在、 `SHOW ANALYZE STATUS`ステートメントは次の列を返します。 diff --git a/sql-statements/sql-statement-show-collation.md b/sql-statements/sql-statement-show-collation.md index d474f38dd4b55..0ac175d558eef 100644 --- a/sql-statements/sql-statement-show-collation.md +++ b/sql-statements/sql-statement-show-collation.md @@ -5,7 +5,7 @@ summary: TiDB データベースの SHOW COLLATION の使用法の概要。 # SHOW COLLATION {#show-collation} -このステートメントは照合順序の静的リストを提供し、MySQL クライアント ライブラリとの互換性を提供するために含まれています。 +このステートメントは照合順序の静的リストを提供し、MySQL クライアントライブラリとの互換性を提供するために含まれています。 > **Note:** > diff --git a/sql-statements/sql-statement-show-create-resource-group.md b/sql-statements/sql-statement-show-create-resource-group.md index d26825fdf073b..ad14d5d4e9c99 100644 --- a/sql-statements/sql-statement-show-create-resource-group.md +++ b/sql-statements/sql-statement-show-create-resource-group.md @@ -5,7 +5,7 @@ summary: TiDBにおけるSHOW CREATE RESOURCE GROUPの使い方を学びまし # SHOW CREATE RESOURCE GROUP {#show-create-resource-group} -`SHOW CREATE RESOURCE GROUP`ステートメントを使用すると、リソース グループの現在の定義を表示できます。 +`SHOW CREATE RESOURCE GROUP`ステートメントを使用すると、リソースグループの現在の定義を表示できます。 > **Note:** > diff --git a/sql-statements/sql-statement-show-import-job.md b/sql-statements/sql-statement-show-import-job.md index 6e6be1b9cfb2d..095d81881dbcd 100644 --- a/sql-statements/sql-statement-show-import-job.md +++ b/sql-statements/sql-statement-show-import-job.md @@ -10,7 +10,7 @@ summary: TiDB での SHOW IMPORT の使用法の概要。 ## 必要な権限 {#required-privileges} - `SHOW IMPORT JOBS` : ユーザーが権限`SUPER`持っている場合、このステートメントは TiDB 内のすべてのインポートジョブを表示します。それ以外の場合は、現在のユーザーが作成したジョブのみを表示します。 -- `SHOW IMPORT JOB ` : インポート ジョブの作成者または`SUPER`権限を持つユーザーのみがこのステートメントを使用して特定のジョブを表示できます。 +- `SHOW IMPORT JOB ` : インポートジョブの作成者または`SUPER`権限を持つユーザーのみがこのステートメントを使用して特定のジョブを表示できます。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-show-table-regions.md b/sql-statements/sql-statement-show-table-regions.md index e6daeef1bfb7a..d0b85f9d51cff 100644 --- a/sql-statements/sql-statement-show-table-regions.md +++ b/sql-statements/sql-statement-show-table-regions.md @@ -153,7 +153,7 @@ mysql> SHOW TABLE t REGIONS; 上記の例では： - テーブル t は 6 つの領域に対応しています。これらの領域では、 `102` 、 `106` 、 `110` 、 `114` 、および`3`に行データが格納され、 `98`にインデックスデータが格納されます。 -- リージョン`START_KEY`の`END_KEY`および`102`について、 `t_43`はテーブルのプレフィックスと ID を示します。 `_r`テーブル t のレコード データのプレフィックスです。 `_i`はインデックス データのプレフィックスです。 +- リージョン`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..f45aaed4d9c98 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} @@ -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-statements/sql-statement-trace.md b/sql-statements/sql-statement-trace.md index 992ede5d4e9be..90c12693c0c51 100644 --- a/sql-statements/sql-statement-trace.md +++ b/sql-statements/sql-statement-trace.md @@ -58,7 +58,7 @@ TRACE FORMAT='row' SELECT * FROM mysql.user; TRACE FORMAT='json' SELECT * FROM mysql.user; ``` -JSON 形式のトレースは、TiDB ステータス ポート経由でアクセスできるトレース ビューアーに貼り付けることができます。 +JSON 形式のトレースは、TiDB ステータスポート経由でアクセスできるトレース ビューアーに貼り付けることができます。 ![TiDB Trace Viewer-1](/media/trace-paste.png) diff --git a/sql-statements/sql-statement-use.md b/sql-statements/sql-statement-use.md index 0a66c54ec1135..f2bced4e83948 100644 --- a/sql-statements/sql-statement-use.md +++ b/sql-statements/sql-statement-use.md @@ -5,7 +5,7 @@ summary: TiDB データベースにおける USE の使用法の概要。 # USE {#use} -`USE`ステートメントは、ユーザー セッションの現在のデータベースを選択します。 +`USE`ステートメントは、ユーザーセッションの現在のデータベースを選択します。 ## 概要 {#synopsis} diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index d25496f3820be..29b40e617496f 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -9,7 +9,7 @@ summary: パフォーマンスを向上させるために SQL クエリを最適 - 参入障壁が低い: チューニングの概念と方法を段階的に導入します。 - 実践指向: それぞれの最適化のヒントについて具体的な手順と例を提供します。 -- クイック スタート: 最も一般的で効果的な最適化方法を優先します。 +- クイックスタート: 最も一般的で効果的な最適化方法を優先します。 - 緩やかな学習曲線: 複雑な理論ではなく実践的なテクニックを重視します。 - シナリオベース: 実際のビジネス ケースを使用して最適化の効果を実証します。 @@ -19,8 +19,8 @@ SQLチューニングは、データベースのパフォーマンスを最適 1. 影響の大きい SQL ステートメントを特定します。 - - SQL 実行履歴を確認して、大量のシステム リソースを消費したり、アプリケーションのワークロードに大きく影響したりするステートメントを見つけます。 - - 監視ツールとパフォーマンス メトリックを使用して、リソースを大量に消費するクエリを識別します。 + - SQL 実行履歴を確認して、大量のシステムリソースを消費したり、アプリケーションのワークロードに大きく影響したりするステートメントを見つけます。 + - 監視ツールとパフォーマンスメトリックを使用して、リソースを大量に消費するクエリを識別します。 2. 実行計画を分析します。 @@ -59,7 +59,7 @@ SQLチューニングは、クエリの機能を変えずに同じワークロ 1. 実行計画の改善: - より効率的な処理のためにクエリ構造を分析および変更します。 - - 適切なインデックスを使用して、データ アクセスと処理時間を短縮します。 + - 適切なインデックスを使用して、データアクセスと処理時間を短縮します。 - 大規模なデータセットに対する分析クエリにTiFlashを有効にし、複雑な集計や結合に[超並列処理（MPP）](/glossary.md#massively-parallel-processing-mpp)エンジンを活用します。 2. データアクセス方法の強化: @@ -123,7 +123,7 @@ TiDB Dashboardに加えて、他のツールを使用してリソースを大量 PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql-statement; ``` -可能な限り`EXPLAIN ANALYZE`を使用してください。これは、実行計画と実際のパフォーマンス メトリックの両方が提供され、クエリ パフォーマンスに関するより正確な分析情報が得られるためです。 +可能な限り`EXPLAIN ANALYZE`を使用してください。これは、実行計画と実際のパフォーマンスメトリックの両方が提供され、クエリパフォーマンスに関するより正確な分析情報が得られるためです。 ## SQLチューニングガイド {#sql-tuning-guide} @@ -179,7 +179,7 @@ TiDBはコストベースオプティマイザ（CBO）を使用して、SQL文 - インデックス統計 - カラム統計 -これらの入力に基づいて、コスト モデルは、TiDB が SQL ステートメントを実行する方法を詳細に示す実行計画を生成します。これには次の内容が含まれます。 +これらの入力に基づいて、コストモデルは、TiDB が SQL ステートメントを実行する方法を詳細に示す実行計画を生成します。これには次の内容が含まれます。 - アクセス方法 - 結合方法 @@ -193,7 +193,7 @@ TiDBはコストベースオプティマイザ（CBO）を使用して、SQL文 統計は次の 2 つのレベルに分かれています。 -- **テーブル レベルの統計**: テーブル内の行の合計数と、最後の統計収集以降に変更された行数が含まれます。 +- **テーブルレベルの統計**: テーブル内の行の合計数と、最後の統計収集以降に変更された行数が含まれます。 - **インデックス/列レベルの統計**: ヒストグラム、Count-Min Sketch、Top-N (最も多く出現する値またはインデックス)、さまざまな値の分布と量、NULL 値の数などの詳細情報が含まれます。 統計の正確性と健全性を確認するには、次の SQL ステートメントを使用できます。 @@ -213,7 +213,7 @@ TiDBはコストベースオプティマイザ（CBO）を使用して、SQL文 Row_count: 20000 1 row in set (0.03 sec) -- [`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md) : テーブル統計のヘルス ステータスを表示します。 +- [`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md) : テーブル統計のヘルスステータスを表示します。 ```sql SHOW STATS_HEALTHY WHERE table_name='T2'\G; @@ -486,7 +486,7 @@ LIMIT 3; 以下の実行計画では、クエリは5分51秒間実行された後、キャンセルされます。主な問題点は次のとおりです。 1. 重大な過小評価：最初のリーフノード`IndexReader_76`インデックス`index_orders_on_adjustment_id(adjustment_id)`からデータを読み取ります。実際の行数（ `actRows` ）は256,811,189で、推定された1行（ `estRows` ）よりも大幅に多くなっています。 -2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`が予想よりもはるかに多くのデータを含むハッシュ テーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 +2. メモリ オーバーフロー: この過小評価により、ハッシュ結合演算子`HashJoin_69`が予想よりもはるかに多くのデータを含むハッシュテーブルを構築し、過剰なメモリ(22.6 GB) とディスク領域 (7.65 GB) を消費します。 3. クエリの終了： `HashJoin_69`とその上位の演算子の`actRows`の値が`0`の場合、一致する行がないか、リソース制約によりクエリが終了したことを示します。この場合、ハッシュ結合はメモリを過剰に消費し、メモリ制御メカニズムがトリガーされてクエリが終了します。 4. 結合順序が正しくありません: この非効率的な計画の根本的な原因は、 `IndexRangeScan_75`に対する`estRows`を大幅に過小評価していることであり、オプティマイザーが誤った結合順序を選択することになります。 @@ -558,7 +558,7 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 複合インデックスの場合は、次の推奨列順序ガイドラインに従ってください。 -1. 直接アクセスするには、インデックス プレフィックス列から始めます。 +1. 直接アクセスするには、インデックスプレフィックス列から始めます。 - 同等の条件を持つ列 - 条件が`IS NULL`である列 - `IN`条件に1つの値（例： `IN (1)`）が含まれる列 @@ -705,7 +705,7 @@ LIMIT クエリを最適化するには、 `(snapshot_id)`に新しいインデックスを作成します。これにより、 `id`が各`snapshot_id`グループ内でソートされるようになります。このインデックスにより、実行時間は96ミリ秒に短縮されます。 `IndexRangeScan_33`の`keep order`プロパティは`true`になり、 `TopN`は`Limit`に置き換えられます。その結果、 `IndexLookUp_35`はTiDBに1,000行のみを返すため、追加のソート操作は不要になります。 -以下は、最適化されたインデックスを含むクエリ ステートメントです。 +以下は、最適化されたインデックスを含むクエリステートメントです。 ```sql CREATE INDEX test_new ON test(snapshot_id); @@ -777,7 +777,7 @@ KEY `index_orders_on_created_at` (`created_at`) - 効率的なインデックスの使用：新しいインデックスにより、最も選択性の高い述語である`user_id` 、 `mode` 、 `id`に対するインデックス範囲スキャンが可能になります。これにより、スキャンされる行数が数百万行からわずか224行に削減されます。 - インデックスのみのソート: 実行計画の`keep order:true`が、ソートがインデックス構造を使用して実行されることを示し、個別のソート操作は不要です。 - 早期フィルタリング: 最も選択的な述語が最初に適用され、さらにフィルタリングされる前に結果セットが 224 行に削減されます。 -- 制限プッシュダウン: `LIMIT`句がインデックス スキャンにプッシュダウンされ、101 行が見つかった時点でスキャンを早期に終了できるようになります。 +- 制限プッシュダウン: `LIMIT`句がインデックススキャンにプッシュダウンされ、101 行が見つかった時点でスキャンを早期に終了できるようになります。 この事例は、適切に設計されたインデックスがクエリのパフォーマンスに大きく影響することを示しています。インデックス構造をクエリの述語、ソート順、および必要な列と一致させることで、クエリのパフォーマンスは5桁以上向上します。 @@ -946,7 +946,7 @@ TiFlash上の実行計画は次のとおりです。 大量のマルチテナント データを持つテーブルに対してTiFlashレプリカを有効にすると、オプティマイザーは行数に基づいてクエリを TiKV またはTiFlashのいずれかにルーティングします。 -- 小規模テナント: TiKV は、テーブル範囲スキャンによる小規模クエリに高い同時実行性を提供するため、データ サイズが小さいテナントに適しています。 +- 小規模テナント: TiKV は、テーブル範囲スキャンによる小規模クエリに高い同時実行性を提供するため、データサイズが小さいテナントに適しています。 - 大規模テナント: 大規模なデータセット (この場合は 1,000 万行など) を持つテナントの場合、 TiFlash は次の利点により効率的です。 - TiFlash は、特定のインデックスを必要とせずに動的なフィルタリング条件を処理します。 - TiDB は、 `COUNT` 、 `SORT` 、 `LIMIT`操作をTiFlashにプッシュダウンできます。 diff --git a/stale-read.md b/stale-read.md index 8d4be08038807..ae36a390aa90d 100644 --- a/stale-read.md +++ b/stale-read.md @@ -27,7 +27,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 ## 使用法 {#usages} -TiDB は、次のようにステートメント レベル、セッション レベル、およびグローバル レベルでステイル読み取りを実行する方法を提供します。 +TiDB は、次のようにステートメントレベル、セッションレベル、およびグローバルレベルでステイル読み取りを実行する方法を提供します。 - ステートメントレベル - 正確な時点の指定（**推奨**）：TiDB が特定の時点からグローバルに一貫性のあるデータを分離レベルに違反することなく読み取る必要がある場合は、クエリ文でその時点の対応するタイムスタンプを指定できます。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)を参照してください。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index b2be92ed44f78..b0d64af793408 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -7,7 +7,7 @@ summary: TiDBのステートメントサマリーテーブルについて学び SQL のパフォーマンス問題をより適切に処理するために、MySQL は、統計情報を使用して SQL を監視するための`performance_schema`の[ステートメントサマリーテーブル](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html)を提供しています。これらのテーブルの中でも、 `events_statements_summary_by_digest`は、レイテンシー、実行時間、スキャンされた行数、フルテーブルスキャンなどの豊富なフィールドを備えているため、SQL の問題を特定する際に非常に役立ちます。 -したがって、v4.0.0-rc.1 以降、TiDB は`information_schema`と機能面で類似したシステム テーブルを`performance_schema` } `events_statements_summary_by_digest`*ではなく*) で提供します。 +したがって、v4.0.0-rc.1 以降、TiDB は`information_schema`と機能面で類似したシステムテーブルを`performance_schema` } `events_statements_summary_by_digest`*ではなく*) で提供します。 - [`statements_summary`](#statements_summary) - [`statements_summary_history`](#statements_summary_history) @@ -23,7 +23,7 @@ SQL のパフォーマンス問題をより適切に処理するために、MySQ ## `statements_summary` {#statements_summary} -`statements_summary`は`information_schema`内のシステム テーブルです。 `statements_summary`は、SQL ステートメントをリソース グループ、SQL ダイジェスト、およびプラン ダイジェストごとにグループ化し、各 SQL カテゴリの統計情報を提供します。 +`statements_summary`は`information_schema`内のシステムテーブルです。 `statements_summary`は、SQL ステートメントをリソースグループ、SQL ダイジェスト、およびプランダイジェストごとにグループ化し、各 SQL カテゴリの統計情報を提供します。 ここでいう「SQLダイジェスト」とは、スローログで使用されるものと同じ意味で、正規化されたSQLステートメントから計算される一意の識別子です。正規化プロセスでは定数や空白文字は無視され、大文字と小文字は区別されません。したがって、構文が一貫しているステートメントは同じダイジェストを持ちます。例： @@ -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`システム変数によって制御されます。クリア直後にクエリを実行すると、表示されるデータが非常に少なくなる場合があります。 @@ -82,7 +82,7 @@ select * from employee where id in (...) and salary between ? and ?; > **Note:** > > - TiDBでは、ステートメントサマリーテーブルのフィールドの時間単位はナノ秒（ns）ですが、MySQLではピコ秒（ps）です。 -> - v7.5.1 および v7.6.0 以降、 が有効に[リソース制御](/tidb-resource-control-ru-groups.md)ているクラスターでは、 `statements_summary`リソース グループごとに集約されます。たとえば、異なるリソース グループで実行された同じステートメントは、異なるレコードとして収集されます。 +> - v7.5.1 および v7.6.0 以降、 が有効に[リソース制御](/tidb-resource-control-ru-groups.md)ているクラスターでは、 `statements_summary`リソースグループごとに集約されます。たとえば、異なるリソースグループで実行された同じステートメントは、異なるレコードとして収集されます。 ## `statements_summary_history` {#statements_summary_history} @@ -126,7 +126,7 @@ select * from employee where id in (...) and salary between ? and ?; 明細書の要約を制御するために、以下のシステム変数が使用されます。 -- `tidb_enable_stmt_summary` : 明細サマリー機能を有効にするかどうかを決定します。 `1`は`enable`を表し、 `0`は`disable`を意味します。この機能はデフォルトで有効になっています。この機能が無効になっている場合、システム テーブルの統計情報はクリアされます。統計情報は、次回この機能が有効になったときに再計算されます。テストの結果、この機能を有効にしてもパフォーマンスへの影響はほとんどないことがわかっています。 +- `tidb_enable_stmt_summary` : 明細サマリー機能を有効にするかどうかを決定します。 `1`は`enable`を表し、 `0`は`disable`を意味します。この機能はデフォルトで有効になっています。この機能が無効になっている場合、システムテーブルの統計情報はクリアされます。統計情報は、次回この機能が有効になったときに再計算されます。テストの結果、この機能を有効にしてもパフォーマンスへの影響はほとんどないことがわかっています。 - `tidb_stmt_summary_refresh_interval` : `statements_summary`テーブルが更新される間隔。時間の単位は秒 (s) です。デフォルト値は`1800`です。 @@ -154,7 +154,7 @@ 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:** > @@ -331,10 +331,10 @@ SELECT sum_latency, avg_latency, exec_count, query_sample_text - `PLAN_DIGEST` : 実行計画の概要。 - `PLAN` : 元の実行計画。複数のステートメントがある場合は、1つのステートメントのプランのみが使用されます。 - `BINARY_PLAN` : バイナリ形式でエンコードされた元の実行計画。複数のステートメントがある場合は、1つのステートメントのプランのみが使用されます。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行してください。 -- `PLAN_CACHE_HITS` : このカテゴリの SQL ステートメントがプラン キャッシュにヒットした合計回数。 -- `PLAN_IN_CACHE` : このカテゴリの SQL ステートメントの以前の実行がプラン キャッシュにヒットしたかどうかを示します。 -- `PLAN_CACHE_UNQUALIFIED` : このカテゴリの SQL ステートメントがプラン キャッシュにヒットしなかった回数。 -- `PLAN_CACHE_UNQUALIFIED_LAST_REASON` : このカテゴリの SQL ステートメントが前回プラン キャッシュにヒットしなかった理由。 +- `PLAN_CACHE_HITS` : このカテゴリの SQL ステートメントがプランキャッシュにヒットした合計回数。 +- `PLAN_IN_CACHE` : このカテゴリの SQL ステートメントの以前の実行がプランキャッシュにヒットしたかどうかを示します。 +- `PLAN_CACHE_UNQUALIFIED` : このカテゴリの SQL ステートメントがプランキャッシュにヒットしなかった回数。 +- `PLAN_CACHE_UNQUALIFIED_LAST_REASON` : このカテゴリの SQL ステートメントが前回プランキャッシュにヒットしなかった理由。 実行時間に関連するフィールド： @@ -443,7 +443,7 @@ TiKVコプロセッサータスクに関連するフィールド： - `MAX_REQUEST_UNIT_READ` : SQL ステートメントによって消費される読み取り RU の最大数。 - `AVG_QUEUED_RC_TIME` : SQL ステートメントを実行する際に、利用可能な RU を待つ平均時間。 - `MAX_QUEUED_RC_TIME` : SQL ステートメントを実行する際に、使用可能な RU の最大待機時間。 -- `RESOURCE_GROUP` : SQL ステートメントにバインドされたリソース グループ。 +- `RESOURCE_GROUP` : SQL ステートメントにバインドされたリソースグループ。 ストレージエンジンに関連する分野： diff --git a/statistics.md b/statistics.md index 5860c4bcf531f..e346a455fb4f6 100644 --- a/statistics.md +++ b/statistics.md @@ -159,13 +159,13 @@ TiDB が SQL ステートメントを実行する際、オプティマイザは - TiDB は常に`PREDICATE COLUMNS`情報を 100 * [`stats-lease`](/tidb-configuration-file.md#stats-lease)ごとに[`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables)システム テーブルに書き込みます。 + TiDB は常に`PREDICATE COLUMNS`情報を 100 * [`stats-lease`](/tidb-configuration-file.md#stats-lease)ごとに[`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables)システムテーブルに書き込みます。 - 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 秒ごとに書き込みます。 @@ -173,7 +173,7 @@ TiDB が SQL ステートメントを実行する際、オプティマイザは > **Note:** > - > - [`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables)システム テーブルにそのテーブルに対して`PREDICATE COLUMNS`が記録されていない場合、上記の構文は、そのテーブルのインデックス付き列とすべてのインデックスに関する統計情報を収集します。 + > - [`mysql.column_stats_usage`](/mysql-schema/mysql-schema.md#statistics-system-tables)システムテーブルにそのテーブルに対して`PREDICATE COLUMNS`が記録されていない場合、上記の構文は、そのテーブルのインデックス付き列とすべてのインデックスに関する統計情報を収集します。 > - 手動で列をリストアップするか、 `PREDICATE COLUMNS`を使用して収集対象から除外した列の統計情報は上書きされません。新しいタイプの SQL クエリを実行すると、オプティマイザは、そのような列に古い統計情報が存在する場合はそれを使用し、統計情報が収集されたことがない列の場合は擬似列統計情報を使用します。 `PREDICATE COLUMNS`を使用した次の ANALYZE で、これらの列の統計情報が収集されます。 - すべての列とインデックスに関する統計情報を収集するには、次の構文を使用します。 diff --git a/status-variables.md b/status-variables.md index 392362530c6b2..5f304c52884c1 100644 --- a/status-variables.md +++ b/status-variables.md @@ -95,7 +95,7 @@ summary: ステータス変数を使用してシステムとセッションの - スコープ: セッション - タイプ: タイムスタンプ -- プラン バインディングの最終更新の日時。 +- プランバインディングの最終更新の日時。 ### server_id {#server-id} @@ -131,4 +131,4 @@ summary: ステータス変数を使用してシステムとセッションの - スコープ: セッション | グローバル - タイプ: 文字列 -- [GC](/garbage-collection-overview.md)セーフ ポイントのタイムスタンプ。 +- [GC](/garbage-collection-overview.md)セーフポイントのタイムスタンプ。 diff --git a/storage-engine/rocksdb-overview.md b/storage-engine/rocksdb-overview.md index fe09d2058e64e..52e88b3321d09 100644 --- a/storage-engine/rocksdb-overview.md +++ b/storage-engine/rocksdb-overview.md @@ -39,7 +39,7 @@ RocksDBに書き込まれるデータは、まずMemTableに書き込まれま - スペース増幅：各レベルのファイルの合計サイズは前のレベルのx倍（デフォルトは10）であるため、データの90%が最終レベルに保存されます。これは、RocksDBのスペース増幅が1.11を超えないことを意味します（L0はデータ量が少ないため無視できます）。 - TiKVの領域拡張：TiKVは独自のMVCC戦略を採用しています。ユーザーがキーを書き込むと、RocksDBに書き込まれる実際のデータはキー + commit_tsです。つまり、更新と削除によって新しいキーもRocksDBに書き込まれます。TiKVは一定間隔で古いバージョンのデータを削除します（RocksDBのDeleteインターフェース経由）。そのため、ユーザーがTiKVに保存するデータの実際の領域は、1.11に過去10分間に書き込まれたデータを加えたものと考えられます（TiKVが古いデータを速やかに削除すると仮定）。 -## RocksDB のバックグラウンド スレッドと圧縮 {#rocksdb-background-threads-and-compaction} +## RocksDB のバックグラウンドスレッドと圧縮 {#rocksdb-background-threads-and-compaction} RocksDBでは、 MemTableをSSTファイルに変換したり、様々なレベルでSSTファイルをマージしたりする操作は、バックグラウンドスレッドプールで実行されます。バックグラウンドスレッドプールのデフォルトサイズは8です。マシンのCPU数が8以下の場合、バックグラウンドスレッドプールのデフォルトサイズはCPU数から1を引いたサイズになります。 diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index 09b62de5d8413..b79b743daf470 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -69,7 +69,7 @@ TitanはRocksDBと互換性があるため、RocksDBを使用する既存のTiKV > > Titanが無効になっている場合、RocksDBはTitanに移動されたデータを読み取ることができません。Titanが既に有効になっているTiKVインスタンスでTitanを誤って無効にした場合（誤って`rocksdb.titan.enabled`を`false`に設定した場合）、TiKVは起動に失敗し、TiKVログに`You have disabled titan when its data directory is not empty`エラーが表示されます。Titanを正しく無効にするには、 [Titanを無効にする](#disable-titan)を参照してください。 -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 に保存されているファイルのサイズを監視できます。 +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 に変換できました。 @@ -99,7 +99,7 @@ Titanの値のキャッシュサイズを制御するには、 [`blob-cache-size BLOBファイル内の古いデータ（対応するキーが更新または削除されたデータ）の割合が、 [`discardable-ratio`](/tikv-configuration-file.md#discardable-ratio)で設定されたしきい値を超えると、Titan GCがトリガーされます。このしきい値を下げると、スペースの増幅を軽減できますが、Titan GCの頻度が高くなる可能性があります。この値を上げると、Titan GC、I/O帯域幅、CPU消費量を削減できますが、ディスク容量の使用量は増加します。 -**TiKV の詳細**-**スレッド CPU** - **RocksDB CPU**から、Titan GC スレッドが長時間にわたってフル ロード状態になっていることが確認された場合は、 [`max-background-gc`](/tikv-configuration-file.md#max-background-gc)調整して Titan GC スレッド プールのサイズを増やすことを検討してください。 +**TiKV の詳細**-**スレッド CPU** - **RocksDB CPU**から、Titan GC スレッドが長時間にわたってフルロード状態になっていることが確認された場合は、 [`max-background-gc`](/tikv-configuration-file.md#max-background-gc)調整して Titan GC スレッドプールのサイズを増やすことを検討してください。 ### `rate-bytes-per-sec` {#rate-bytes-per-sec} diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index b1d636ca3d6ce..095b6aa6398e0 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -96,8 +96,8 @@ RocksDBは、古いデータを破棄してスペースを再利用するため ![EventListener](/media/titan/titan-5.png) -- *inputs は*、圧縮に参加するすべての SST の BLOB ファイル サイズのプロパティを表します。 -- *出力は*、圧縮で生成されたすべての SST の BLOB ファイル サイズのプロパティを表します。 +- *inputs は*、圧縮に参加するすべての SST の BLOB ファイルサイズのプロパティを表します。 +- *出力は*、圧縮で生成されたすべての SST の BLOB ファイルサイズのプロパティを表します。 - *破棄可能サイズ*は、入力と出力に基づいて計算された、各BLOBファイルごとに破棄されるファイルのサイズです。最初の列はBLOBファイルのIDです。2番目の列は破棄されるファイルのサイズです。 Titanは、有効なBLOBファイルごとに、破棄可能サイズ変数をメモリ内に保持します。圧縮が行われるたびに、対応するBLOBファイルについてこの変数が累積されます。GCが開始されるたびに、破棄可能サイズが最も大きいBLOBファイルがGCの候補ファイルとして選択されます。書き込み増幅を抑えるため、一定レベルのスペース増幅が許容されます。つまり、破棄可能ファイルのサイズが特定の割合に達した場合にのみ、BLOBファイルでGCが開始されます。 diff --git a/sync-diff-inspector/dm-diff.md b/sync-diff-inspector/dm-diff.md index 15d3b23781a13..889dbc4876955 100644 --- a/sync-diff-inspector/dm-diff.md +++ b/sync-diff-inspector/dm-diff.md @@ -1,9 +1,9 @@ --- title: Data Check in the DM Replication Scenario -summary: データ チェックを実行するために DM-master` から特定の `task-name` 構成を設定する方法について説明します。 +summary: データチェックを実行するために DM-master` から特定の `task-name` 構成を設定する方法について説明します。 --- -# DM レプリケーション シナリオにおけるデータ チェック {#data-check-in-the-dm-replication-scenario} +# DM レプリケーションシナリオにおけるデータチェック {#data-check-in-the-dm-replication-scenario} [TiDB Data Migration](/dm/dm-overview.md)のようなレプリケーションツールを使用する場合、レプリケーション処理の前後でデータの整合性を確認する必要があります。`DM-master`から特定の`task-name`設定を設定することで、データチェックを実行できます。 diff --git a/sync-diff-inspector/route-diff.md b/sync-diff-inspector/route-diff.md index b965b10d7d123..c8b48a4f1ea16 100644 --- a/sync-diff-inspector/route-diff.md +++ b/sync-diff-inspector/route-diff.md @@ -5,7 +5,7 @@ summary: さまざまなデータベース名またはテーブル名のデー # 異なるスキーマまたはテーブル名を持つテーブルのデータチェック {#data-check-for-tables-with-different-schema-or-table-names} -[TiDB Data Migration](/dm/dm-overview.md)などのレプリケーション ツールを使用する場合、 `route-rules`を設定すると、ダウンストリーム内の指定されたテーブルにデータをレプリケートできます。 sync-diff-inspector では、 `rules`を設定することで、異なるスキーマ名またはテーブル名を持つテーブルを検証できます。 +[TiDB Data Migration](/dm/dm-overview.md)などのレプリケーションツールを使用する場合、 `route-rules`を設定すると、ダウンストリーム内の指定されたテーブルにデータをレプリケートできます。 sync-diff-inspector では、 `rules`を設定することで、異なるスキーマ名またはテーブル名を持つテーブルを検証できます。 以下は簡単な設定例です。詳細な設定については、 [sync-diff-inspector ユーザーガイド](/sync-diff-inspector/sync-diff-inspector-overview.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` @@ -92,7 +92,7 @@ target-table = "t_2" # The name of the target table - `inspector_mysql_1.Tb_emp1` - `Inspector_mysql_1.Tb_emp1` -設定例では、アップストリーム クラスターにルール`Source.rule1`があり、ターゲット テーブルは`inspector_mysql_1.tb_emp1`です。 +設定例では、アップストリームクラスターにルール`Source.rule1`があり、ターゲットテーブルは`inspector_mysql_1.tb_emp1`です。 #### 例1 {#example-1} diff --git a/sync-diff-inspector/shard-diff.md b/sync-diff-inspector/shard-diff.md index b00781e1cace4..4e1aee285e3b4 100644 --- a/sync-diff-inspector/shard-diff.md +++ b/sync-diff-inspector/shard-diff.md @@ -1,6 +1,6 @@ --- title: Data Check in the Sharding Scenario -summary: シャーディング シナリオでのデータ チェックについて学習します。 +summary: シャーディング シナリオでのデータチェックについて学習します。 --- # シャーディングシナリオにおけるデータチェック {#data-check-in-the-sharding-scenario} @@ -75,7 +75,7 @@ target-table = "table-0" # The name of the target table target-check-tables = ["test.table-0"] ``` -アップストリームのシャード テーブルが多数あり、すべてのシャード テーブルの命名規則に次のようなパターンがある場合は、構成に`table-rules`を使用できます。 +アップストリームのシャードテーブルが多数あり、すべてのシャードテーブルの命名規則に次のようなパターンがある場合は、構成に`table-rules`を使用できます。 ![shard-table-replica-2](/media/shard-table-replica-2.png) diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md index 49a4fecfa45ca..ed59147fe491f 100644 --- a/sync-diff-inspector/sync-diff-inspector-overview.md +++ b/sync-diff-inspector/sync-diff-inspector-overview.md @@ -30,7 +30,7 @@ TiDB v8.5.6以降の場合： tiup install sync-diff-inspector ``` -- バイナリ パッケージ: TiDB Toolkitに含まれています。ツールキットをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 +- バイナリパッケージ: TiDB Toolkitに含まれています。ツールキットをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 - Dockerイメージ：以下のコマンドを実行してダウンロードしてください。 @@ -40,7 +40,7 @@ TiDB v8.5.6以降の場合： バージョン8.5.6より前のバージョンの場合： -- バイナリ パッケージ: TiDB Toolkitに含まれています (従来の[`tidb-tools`](https://github.com/pingcap/tidb-tools)リポジトリから)。ツールキットをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 +- バイナリパッケージ: TiDB Toolkitに含まれています (従来の[`tidb-tools`](https://github.com/pingcap/tidb-tools)リポジトリから)。ツールキットをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 - Dockerイメージ（旧バージョン）：以下のコマンドを実行してダウンロードしてください。 @@ -326,7 +326,7 @@ REPLACE INTO `sbtest`.`sbtest99`(`id`,`k`,`c`,`pad`) VALUES (3700000,2501808,'he - 自動入力される timestamp カラムを含むデータセットを検証する場合は、`DEFAULT CURRENT_TIMESTAMP` に依存するのではなく、検証データに対して決定論的な TIMESTAMP 値を設定することを検討してください。あるいは、その正確な値が検証目的にとって重要でない場合は、`ignore-columns` を使用して自動入力される TIMESTAMP カラムを除外してください。 - アップストリームテーブルとダウンストリームテーブルで主キーが異なる場合、sync-diff-inspector は元の主キー列を使用してチャンクを分割しません。たとえば、MySQL のシャーディングされたテーブルが、元の主キーとシャードキーを含む複合主キーを使用して TiDB にマージされる場合などです。この場合、 `index-fields`を使用して元の主キー列を構成し、 `check-data-only`を`true`に設定します。 - sync-diff-inspector は、まず TiDB の統計情報に基づいてデータをチャンクに分割します。統計情報の正確性を保証する必要があります。TiDB サーバーの*ワークロードが軽い*場合は、 `analyze table {table_name}`コマンドを手動で実行できます。 -- `table-rules`に特に注意してください。 `schema-pattern="test1"` 、 `table-pattern = "t_1"` 、 `target-schema="test2"` 、 `target-table = "t_2"`構成すると、ソース データベースの`test1` 、 `t_1`スキーマと、ターゲット データベースの`test2` 、 `t_2`スキーマが比較されます。 sync-diff-inspector ではシャーディングがデフォルトで有効になっているため、ソース データベースに`test2` . `t_2`テーブルがある場合、シャーディングとして機能しているソース データベースの`test1` . `t_1`テーブルと`test2` . `t_2`テーブルが、ターゲット データベースの`test2` . `t_2`テーブルと比較されます。 +- `table-rules`に特に注意してください。 `schema-pattern="test1"` 、 `table-pattern = "t_1"` 、 `target-schema="test2"` 、 `target-table = "t_2"`構成すると、ソースデータベースの`test1` 、 `t_1`スキーマと、ターゲットデータベースの`test2` 、 `t_2`スキーマが比較されます。 sync-diff-inspector ではシャーディングがデフォルトで有効になっているため、ソースデータベースに`test2` . `t_2`テーブルがある場合、シャーディングとして機能しているソースデータベースの`test1` . `t_1`テーブルと`test2` . `t_2`テーブルが、ターゲットデータベースの`test2` . `t_2`テーブルと比較されます。 - 生成されたSQLファイルは、データ修復の際の参照としてのみ使用されます。データ修復のためにこれらのSQL文を実行する前に、必ず内容を確認してください。 ## 関連リソース {#related-resources} diff --git a/sys-schema/sys-schema.md b/sys-schema/sys-schema.md index a01ba5da0cc54..213ba26860445 100644 --- a/sys-schema/sys-schema.md +++ b/sys-schema/sys-schema.md @@ -1,6 +1,6 @@ --- title: sys Schema -summary: sys` スキーマ内のシステム テーブルについて学習します。 +summary: sys` スキーマ内のシステムテーブルについて学習します。 --- # `sys`スキーマ {#sys-schema} diff --git a/system-variable-reference.md b/system-variable-reference.md index ceb3931592640..a81d5d7105f97 100644 --- a/system-variable-reference.md +++ b/system-variable-reference.md @@ -440,7 +440,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md) +- [TiDB を使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md) - [TiDB Cloudで制限されたSQL機能](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#interactive_timeout) - [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) @@ -527,7 +527,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md) +- [TiDB を使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md) - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [オプティマイザヒント](/optimizer-hints.md) - [SQL プラン管理 (SPM)](/sql-plan-management.md) @@ -1471,7 +1471,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [システム変数](/system-variables.md#tidb_enable_clustered_index-new-in-v50) - [TiDB バックアップと復元の概要](/br/backup-and-restore-overview.md) - [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) -- [TiDB データベース スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md) +- [TiDB データベーススキーマ設計の概要](/develop/dev-guide-schema-design-overview.md) - [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md) - [TiDB 6.4.0 リリースノート](/releases/release-6.4.0.md) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) @@ -1687,7 +1687,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md) +- [TiDB を使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md) - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [システム変数](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) - [TiDB 8.3.0 リリースノート](/releases/release-8.3.0.md) @@ -2051,7 +2051,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md) +- [TiDB を使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md) - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [ディスク流出時の暗号化機能を有効にする](/enable-disk-spill-encrypt.md) - [テーブル結合を使用するステートメントを説明する](/explain-joins.md) @@ -4507,7 +4507,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md) +- [TiDB を使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md) - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [TiDB Cloudで制限されたSQL機能](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#wait_timeout) diff --git a/system-variables.md b/system-variables.md index 4adfd354f71d5..bcfdf1f9aab6d 100644 --- a/system-variables.md +++ b/system-variables.md @@ -732,9 +732,9 @@ mysql> SELECT * FROM t1; - 値のオプション: `UNSPECIFIED` 、 `0` 、 `1` 、 `2` - この変数は、MPP実行計画の異なるバージョンを指定するために使用されます。バージョンが指定されると、TiDBは指定されたバージョンのMPP実行計画を選択します。変数の値の意味は次のとおりです。 - `UNSPECIFIED` : 未指定を意味します。TiDB は最新バージョン`2`を自動的に選択します。 - - `0` : すべての TiDB クラスタ バージョンと互換性があります。 `0`より大きい MPP バージョンを持つ機能は、このモードでは有効になりません。 + - `0` : すべての TiDB クラスタバージョンと互換性があります。 `0`より大きい MPP バージョンを持つ機能は、このモードでは有効になりません。 - `1` : v6.6.0 の新機能。 TiFlashで圧縮を伴うデータ交換を有効にするために使用されます。詳細については、 [MPPバージョンとデータ圧縮の交換](/explain-mpp.md#mpp-version-and-exchange-data-compression)を参照してください。 - - `2` : v7.3.0 で新しく追加され、 TiFlashで MPP タスクがエラーに遭遇したときに、より正確なエラー メッセージを提供するために使用されます。 + - `2` : v7.3.0 で新しく追加され、 TiFlashで MPP タスクがエラーに遭遇したときに、より正確なエラーメッセージを提供するために使用されます。 ### OutPacketBytes New in v8.5.6 @@ -1091,7 +1091,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: "" -- この変数は、TiKV にフォールバックする可能性のあるストレージエンジンのリストを指定するために使用されます。リストで指定されたストレージエンジンの障害により SQL ステートメントの実行が失敗した場合、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。この変数は "" または "tiflash" に設定できます。この変数が "tiflash" に設定されている場合、 TiFlash がタイムアウト エラー (エラー コード: ErrTiFlashServerTimeout) を返すと、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。 +- この変数は、TiKV にフォールバックする可能性のあるストレージエンジンのリストを指定するために使用されます。リストで指定されたストレージエンジンの障害により SQL ステートメントの実行が失敗した場合、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。この変数は "" または "tiflash" に設定できます。この変数が "tiflash" に設定されている場合、 TiFlash がタイムアウトエラー (エラーコード: ErrTiFlashServerTimeout) を返すと、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。 ### tidb_allow_function_for_expression_index New in v5.2.0 @@ -1294,7 +1294,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 型: Float - デフォルト値: `0.5` - 範囲: `(0, 1]` 。v8.0.0 以前のバージョンの範囲は`[0, 18446744073709551615]`です。 -- この変数は、TiDB がバックグラウンド スレッドで[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)を自動的に実行してテーブル統計を更新する際のしきい値を設定するために使用されます。たとえば、値が 0.5 の場合、テーブル内の行の 50% 以上が変更されたときに自動分析がトリガーされます。 `tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`を指定することで、自動分析を特定の時間帯のみ実行するように制限できます。 +- この変数は、TiDB がバックグラウンドスレッドで[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)を自動的に実行してテーブル統計を更新する際のしきい値を設定するために使用されます。たとえば、値が 0.5 の場合、テーブル内の行の 50% 以上が変更されたときに自動分析がトリガーされます。 `tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`を指定することで、自動分析を特定の時間帯のみ実行するように制限できます。 > **Note:** > @@ -1633,7 +1633,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 値のオプション： - `1` : TiDB v6.4.0 以前のバージョンでデフォルトで使用されているコストモデルバージョン 1 を有効にします。 - `2` :[コストモデル バージョン2](/cost-model.md#cost-model-version-2)を有効にします。これは TiDB v6.5.0 で一般提供されており、内部テストではバージョン 1 よりも正確です。 -- コスト モデルのバージョンは、オプティマイザーの計画決定に影響します。詳細については、[コストモデル](/cost-model.md)を参照してください。 +- コストモデルのバージョンは、オプティマイザーの計画決定に影響します。詳細については、[コストモデル](/cost-model.md)を参照してください。 ### tidb_current_ts @@ -1715,20 +1715,20 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - この変数は[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を有効にするかどうかを制御するために使用されます。フレームワークが有効になると、DDLやインポートなどのDXFタスクは、クラスタ内の複数のTiDBノードによって分散的に実行および完了されます。 - TiDB v7.1.0以降、DXFはパーティションテーブルに対する[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)ステートメントの分散実行をサポートしています。 - TiDB v7.2.0以降、DXFはインポートジョブにおける[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)ステートメントの分散実行をサポートしています。 -- TiDB v8.1.0 以降では、この変数はデフォルトで有効になっています。DXF が有効になっているクラスタを v8.1.0 以降にアップグレードする場合は、アップグレード前に DXF を無効にしてください ( `tidb_enable_dist_task`を`OFF`に設定)。これにより、アップグレード中に`ADD INDEX`操作が発生してデータ インデックスの不整合が発生するのを回避できます。アップグレード後、DXF を手動で有効にすることができます。 +- TiDB v8.1.0 以降では、この変数はデフォルトで有効になっています。DXF が有効になっているクラスタを v8.1.0 以降にアップグレードする場合は、アップグレード前に DXF を無効にしてください ( `tidb_enable_dist_task`を`OFF`に設定)。これにより、アップグレード中に`ADD INDEX`操作が発生してデータインデックスの不整合が発生するのを回避できます。アップグレード後、DXF を手動で有効にすることができます。 - この変数は`tidb_ddl_distribute_reorg`から名前が変更されました。 ### tidb_cloud_storage_uri New in v7.4.0 > **Note:** > -> 現在、[グローバルソート](/tidb-global-sort.md)プロセスは TiDB ノードのコンピューティング リソースとメモリリソースを大量に消費します。ユーザー業務アプリケーションの実行中にオンラインでインデックスを追加するなどのシナリオでは、クラスタに新しい TiDB ノードを追加し、これらのノードの[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を構成して、これらのノードに接続してタスクを作成することをお勧めします。このようにして、分散フレームワークはタスクをこれらのノードにスケジュールし、ワークロードを他の TiDB ノードから分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンド タスクの実行がユーザー業務アプリケーションに与える影響を軽減します。 +> 現在、[グローバルソート](/tidb-global-sort.md)プロセスは TiDB ノードのコンピューティングリソースとメモリリソースを大量に消費します。ユーザー業務アプリケーションの実行中にオンラインでインデックスを追加するなどのシナリオでは、クラスタに新しい TiDB ノードを追加し、これらのノードの[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を構成して、これらのノードに接続してタスクを作成することをお勧めします。このようにして、分散フレームワークはタスクをこれらのノードにスケジュールし、ワークロードを他の TiDB ノードから分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンド タスクの実行がユーザー業務アプリケーションに与える影響を軽減します。 - 対象範囲：グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `""` -- この変数は、[グローバルソート](/tidb-global-sort.md)を有効にするための Amazon S3 クラウドストレージURI を指定するために使用されます。 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を有効にすると、URI を構成し、ストレージへのアクセスに必要な権限を持つ適切なクラウドストレージパスを指すようにすることで、グローバル ソート機能を使用できるようになります。詳細については、 [Amazon S3 URI形式](/external-storage-uri.md#amazon-s3-uri-format)を参照してください。 +- この変数は、[グローバルソート](/tidb-global-sort.md)を有効にするための Amazon S3 クラウドストレージURI を指定するために使用されます。 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を有効にすると、URI を構成し、ストレージへのアクセスに必要な権限を持つ適切なクラウドストレージパスを指すようにすることで、グローバルソート機能を使用できるようになります。詳細については、 [Amazon S3 URI形式](/external-storage-uri.md#amazon-s3-uri-format)を参照してください。 - 以下のステートメントでは、グローバルソート機能を使用できます。 - [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)文。 - インポートジョブ用の[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)ステートメント。 @@ -1774,9 +1774,9 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - デフォルト値: `256` - 範囲: `[32, 10240]` - 単位：行 -- この変数は、DDL 操作の`re-organize`フェーズ中にバッチ サイズを設定するために使用されます。たとえば、TiDB が`ADD INDEX`操作を実行すると、インデックス データは`tidb_ddl_reorg_worker_cnt` (数) 個の同時実行ワーカーによってバックフィルされる必要があります。各ワーカーは、インデックス データをバッチ単位でバックフィルします。 +- この変数は、DDL 操作の`re-organize`フェーズ中にバッチサイズを設定するために使用されます。たとえば、TiDB が`ADD INDEX`操作を実行すると、インデックスデータは`tidb_ddl_reorg_worker_cnt` (数) 個の同時実行ワーカーによってバックフィルされる必要があります。各ワーカーは、インデックスデータをバッチ単位でバックフィルします。 - `tidb_ddl_enable_fast_reorg`が`OFF`に設定されている場合、 `ADD INDEX`はトランザクションとして実行されます。 `ADD INDEX`の実行中に、対象列で`UPDATE`や`REPLACE`などの更新操作が多数発生する場合、バッチサイズが大きいほどトランザクション競合が発生する可能性が高くなります。この場合、バッチサイズを小さい値に設定することをお勧めします。最小値は 32 です。 - - トランザクションの競合が存在しない場合、または`tidb_ddl_enable_fast_reorg`が`ON`に設定されている場合は、バッチ サイズを大きな値に設定できます。これにより、データのバックフィルが高速になりますが、TiKV への書き込み圧力も増加します。適切なバッチ サイズについては、 `tidb_ddl_reorg_worker_cnt`の値も参照する必要があります。参考として[オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](https://docs.pingcap.com/tidb/dev/online-workloads-and-add-index-operations)を参照してください。 + - トランザクションの競合が存在しない場合、または`tidb_ddl_enable_fast_reorg`が`ON`に設定されている場合は、バッチサイズを大きな値に設定できます。これにより、データのバックフィルが高速になりますが、TiKV への書き込み圧力も増加します。適切なバッチサイズについては、 `tidb_ddl_reorg_worker_cnt`の値も参照する必要があります。参考として[オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](https://docs.pingcap.com/tidb/dev/online-workloads-and-add-index-operations)を参照してください。 - バージョン8.3.0以降、このパラメータはセッションレベルでサポートされています。グローバルレベルでパラメータを変更しても、現在実行中のDDLステートメントには影響しません。変更は、新規セッションで送信されるDDLにのみ適用されます。 - バージョン 8.5.0 以降では、 `ADMIN ALTER DDL JOBS BATCH_SIZE = ;`を実行することで、実行中の DDL ジョブのこのパラメータを変更できます。TiDB バージョン 8.5.5 より前のバージョンでは、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)が有効になっている場合、 `ADD INDEX` DDL に対してこの操作はサポートされていないことに注意してください。詳細については、 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)を参照してください。 @@ -2129,7 +2129,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 - デフォルト値: `ON` -- この変数は、スロー クエリ ログに各オペレーターの実行情報を記録するかどうか、および[インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかを制御します。 +- この変数は、スロークエリログに各オペレーターの実行情報を記録するかどうか、および[インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかを制御します。 ### tidb_enable_column_tracking New in v5.4.0 @@ -2165,7 +2165,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - SEMは、 [セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)などのシステムの設計に触発されています。MySQLの`SUPER`権限を持つユーザーの能力を制限し、代わりに`RESTRICTED`のようなきめ細かい権限を付与することを要求します。これらのきめ細かい権限には以下が含まれます。 - - `RESTRICTED_TABLES_ADMIN` : `mysql`スキーマのシステム テーブルにデータを書き込む機能、および`information_schema`テーブルの機密列を表示する機能。 + - `RESTRICTED_TABLES_ADMIN` : `mysql`スキーマのシステムテーブルにデータを書き込む機能、および`information_schema`テーブルの機密列を表示する機能。 - `RESTRICTED_STATUS_ADMIN` : コマンド`SHOW STATUS`で機密変数を表示する機能。 - `RESTRICTED_VARIABLES_ADMIN` : `SHOW [GLOBAL] VARIABLES`および`SET`内の機密変数を表示および設定する機能。 - `RESTRICTED_USER_ADMIN` : 他のユーザーが変更を加えたり、ユーザーアカウントを削除したりすることを防止できる機能。 @@ -2225,7 +2225,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; > **Note:** > -> この変数は[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)およびプレフィックス インデックスに対しては機能しません。 +> この変数は[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)およびプレフィックスインデックスに対しては機能しません。 - 範囲: セッション | グローバル - クラスターに永続化：はい @@ -2268,7 +2268,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 - デフォルト値: `ON` -- この変数は、パーティション テーブルに対して[グローバルインデックス](/global-indexes.md)の作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`を指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 +- この変数は、パーティションテーブルに対して[グローバルインデックス](/global-indexes.md)の作成をサポートするかどうかを制御します。この変数を有効にすると、TiDB では、インデックス定義で`GLOBAL`を指定することで**、パーティション式で使用されているすべての列を含まない**一意インデックスを作成できます。 - この変数は v8.4.0 以降非推奨になりました。その値はデフォルト値`ON`に固定されています。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 ### tidb_enable_lazy_cursor_fetch New in v8.3.0 @@ -2565,7 +2565,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` -- この変数は、インスタンス プラン キャッシュ機能を有効にするかどうかを制御します。この機能はインスタンス レベルの実行計画 キャッシュを実装しており、同じ TiDB インスタンス内のすべてのセッションが実行計画 キャッシュを共有できるため、メモリ使用率が向上します。インスタンス プラン キャッシュを有効にする前に、セッション レベル[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)と[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を無効にすることをお勧めします。 +- この変数は、インスタンスプランキャッシュ機能を有効にするかどうかを制御します。この機能はインスタンスレベルの実行計画 キャッシュを実装しており、同じ TiDB インスタンス内のすべてのセッションが実行計画 キャッシュを共有できるため、メモリ使用率が向上します。インスタンスプランキャッシュを有効にする前に、セッションレベル[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)と[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)を無効にすることをお勧めします。 ### tidb_enable_ordered_result_mode @@ -2611,7 +2611,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 - デフォルト値: `ON` -- この変数は、TiDB が並列 HashAgg アルゴリズムでディスク スピルをサポートするかどうかを制御します。この変数が`ON`の場合、HashAgg オペレータは、あらゆる並列条件下でメモリ使用量に基づいてデータ スピルを自動的にトリガーできるため、パフォーマンスとデータ スループットのバランスが取れます。この変数を`OFF`に設定することは推奨されません。v8.2.0 以降では、 `OFF`に設定するとエラーが報告されます。この変数は、将来のリリースで非推奨になります。 +- この変数は、TiDB が並列 HashAgg アルゴリズムでディスクスピルをサポートするかどうかを制御します。この変数が`ON`の場合、HashAgg オペレータは、あらゆる並列条件下でメモリ使用量に基づいてデータスピルを自動的にトリガーできるため、パフォーマンスとデータ スループットのバランスが取れます。この変数を`OFF`に設定することは推奨されません。v8.2.0 以降では、 `OFF`に設定するとエラーが報告されます。この変数は、将来のリリースで非推奨になります。 ### tidb_enable_pipelined_window_function @@ -2771,7 +2771,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` - 型: Boolean -- この変数は[リソース制御機能](/tidb-resource-control-ru-groups.md)のスイッチです。この変数が`ON`に設定されている場合、TiDB クラスターはリソース グループに基づいてアプリケーション リソースを分離できます。 +- この変数は[リソース制御機能](/tidb-resource-control-ru-groups.md)のスイッチです。この変数が`ON`に設定されている場合、TiDB クラスターはリソースグループに基づいてアプリケーションリソースを分離できます。 ### tidb_enable_reuse_chunk New in v6.4.0 @@ -3536,7 +3536,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Boolean - デフォルト値: `OFF` - この変数は、プリペアドステートメントキャッシュを閉じるコマンドを無視するかどうかを設定するために使用されます。 -- この変数が`ON`に設定されている場合、バイナリ プロトコルの`COM_STMT_CLOSE`コマンドとテキスト プロトコルの[`DEALLOCATE PREPARE`](/sql-statements/sql-statement-deallocate.md)ステートメントは無視されます。詳細については、 [`COM_STMT_CLOSE`コマンドと`DEALLOCATE PREPARE`ステートメントは無視してください](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement)を参照してください。 +- この変数が`ON`に設定されている場合、バイナリプロトコルの`COM_STMT_CLOSE`コマンドとテキスト プロトコルの[`DEALLOCATE PREPARE`](/sql-statements/sql-statement-deallocate.md)ステートメントは無視されます。詳細については、 [`COM_STMT_CLOSE`コマンドと`DEALLOCATE PREPARE`ステートメントは無視してください](/sql-prepared-plan-cache.md#ignore-the-com_stmt_close-command-and-the-deallocate-prepare-statement)を参照してください。 ### tidb_ignore_inlist_plan_digest New in v7.6.0 @@ -3680,7 +3680,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: Float - デフォルト値: `0.1` - 範囲: `[0, 1]` -- この変数は、メモリ削除後に[インスタンスプランキャッシュ](#tidb_enable_instance_plan_cache-new-in-v840)用に予約されるアイドルメモリの割合を制御します。インスタンス プラン キャッシュで使用されるメモリが[`tidb_instance_plan_cache_max_size`](#tidb_instance_plan_cache_max_size-new-in-v840)で設定された制限に達すると、TiDB はアイドル メモリの割合が[`tidb_instance_plan_cache_reserved_percentage`](#tidb_instance_plan_cache_reserved_percentage-new-in-v840)で設定された値を超えるまで、Least Recently Used (LRU) アルゴリズムを使用してメモリからメモリプランを削除し始めます。 +- この変数は、メモリ削除後に[インスタンスプランキャッシュ](#tidb_enable_instance_plan_cache-new-in-v840)用に予約されるアイドルメモリの割合を制御します。インスタンスプランキャッシュで使用されるメモリが[`tidb_instance_plan_cache_max_size`](#tidb_instance_plan_cache_max_size-new-in-v840)で設定された制限に達すると、TiDB はアイドルメモリの割合が[`tidb_instance_plan_cache_reserved_percentage`](#tidb_instance_plan_cache_reserved_percentage-new-in-v840)で設定された値を超えるまで、Least Recently Used (LRU) アルゴリズムを使用してメモリからメモリプランを削除し始めます。 ### tidb_instance_plan_cache_max_size New in v8.4.0 @@ -3758,7 +3758,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `"1s"` - 範囲: `[0s, 1h]` - 型: String -- この変数は、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を設定するために使用されます。リーダー ノードの推定キュー時間がしきい値を超えると、TiDB はフォロワー ノードからのデータの読み取りを優先します。形式は、 `"100ms"`や`"1s"`などの期間です。詳細については、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)を参照してください。 +- この変数は、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を設定するために使用されます。リーダーノードの推定キュー時間がしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。形式は、 `"100ms"`や`"1s"`などの期間です。詳細については、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)を参照してください。 @@ -3770,7 +3770,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `"1s"` - 範囲: `[0s, 1h]` - 型: String -- この変数は、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を設定するために使用されます。リーダー ノードの推定キュー時間がしきい値を超えると、TiDB はフォロワー ノードからのデータの読み取りを優先します。形式は、 `"100ms"`や`"1s"`などの期間です。詳細については、 [ホットスポットの問題をトラブルシューティングする](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#scatter-read-hotspots)を参照してください。 +- この変数は、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を設定するために使用されます。リーダーノードの推定キュー時間がしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。形式は、 `"100ms"`や`"1s"`などの期間です。詳細については、 [ホットスポットの問題をトラブルシューティングする](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#scatter-read-hotspots)を参照してください。 @@ -4035,7 +4035,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `-1` - 範囲: `[-1, 9223372036854775807]` - 単位：バイト -- この変数は、TiDB の統計情報更新における最大メモリ使用量を制御します。このようなメモリ使用量は、手動で[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)を実行したとき、および TiDB がバックグラウンドでタスクを自動的に分析するときに発生します。合計メモリ使用量がこのしきい値を超えると、ユーザーが実行した`ANALYZE`は終了し、より低いサンプリング レートを試すか、後で再試行するように促すエラー メッセージが表示されます。メモリしきい値を超えたために TiDB のバックグラウンドで自動タスクが終了し、使用されているサンプリング レートがデフォルト値よりも高い場合、TiDB はデフォルトのサンプリング レートを使用して更新を再試行します。この変数の値が負またはゼロの場合、TiDB は手動および自動更新タスクの両方のメモリ使用量を制限しません。 +- この変数は、TiDB の統計情報更新における最大メモリ使用量を制御します。このようなメモリ使用量は、手動で[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)を実行したとき、および TiDB がバックグラウンドでタスクを自動的に分析するときに発生します。合計メモリ使用量がこのしきい値を超えると、ユーザーが実行した`ANALYZE`は終了し、より低いサンプリングレートを試すか、後で再試行するように促すエラーメッセージが表示されます。メモリしきい値を超えたために TiDB のバックグラウンドで自動タスクが終了し、使用されているサンプリングレートがデフォルト値よりも高い場合、TiDB はデフォルトのサンプリングレートを使用して更新を再試行します。この変数の値が負またはゼロの場合、TiDB は手動および自動更新タスクの両方のメモリ使用量を制限しません。 > **Note:** > @@ -4050,7 +4050,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `33554432` (32 MiB) - 範囲: `[0, 9223372036854775807]` - 単位：バイト -- この変数は`Apply`演算子のローカル キャッシュのメモリ使用量しきい値を設定するために使用されます。 +- この変数は`Apply`演算子のローカルキャッシュのメモリ使用量しきい値を設定するために使用されます。 - `Apply`演算子のローカルキャッシュは`Apply`演算子の計算を高速化するために使用されます。 変数を`0`に設定すると、 `Apply`キャッシュ機能を無効にできます。 ### tidb_mem_quota_binding_cache New in v6.0.0 @@ -4824,8 +4824,8 @@ mysql> desc select count(distinct a) from test.t; - 型: Enumeration - デフォルト値: `DISABLE` - 指定可能な値: `DISABLE` 、 `COST` -- クエリに`ORDER BY ... LIMIT`が含まれている場合に、オプティマイザがインデックスの部分順序を利用して TopN 計算を最適化できるかどうかを制御します。ソート列がインデックスの順序と一致する場合 (たとえば、ソート列がインデックス列であるか、プレフィックス インデックスを持っている場合)、インデックス スキャンによって返されるデータは、その列で既に部分的に順序付けられています。この場合、オプティマイザはスキャン中に TopN 結果を段階的に構築し、 `LIMIT`が満たされたら早期に停止できるため、ソートのオーバーヘッドを削減できます。 -- 使用シナリオ: `ORDER BY ... LIMIT`句のソート列がプレフィックス インデックスのみを持つ長い文字列である場合、TopN ソートのオーバーヘッドを削減するために、この変数を`COST`に設定し、クエリで`USE INDEX`または`FORCE INDEX`ヒントを指定して、部分順序 TopN 最適化を有効にできます。 +- クエリに`ORDER BY ... LIMIT`が含まれている場合に、オプティマイザがインデックスの部分順序を利用して TopN 計算を最適化できるかどうかを制御します。ソート列がインデックスの順序と一致する場合 (たとえば、ソート列がインデックス列であるか、プレフィックスインデックスを持っている場合)、インデックススキャンによって返されるデータは、その列で既に部分的に順序付けられています。この場合、オプティマイザはスキャン中に TopN 結果を段階的に構築し、 `LIMIT`が満たされたら早期に停止できるため、ソートのオーバーヘッドを削減できます。 +- 使用シナリオ: `ORDER BY ... LIMIT`句のソート列がプレフィックスインデックスのみを持つ長い文字列である場合、TopN ソートのオーバーヘッドを削減するために、この変数を`COST`に設定し、クエリで`USE INDEX`または`FORCE INDEX`ヒントを指定して、部分順序 TopN 最適化を有効にできます。 - デフォルト値は`DISABLE`で、これは部分順序による TopN 最適化が無効になっていることを意味します。この場合、オプティマイザは TopN に対して標準的なグローバルソート方式を使用します。 @@ -4928,7 +4928,7 @@ explain select * from t where age=5; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: `ON` - この変数は、TiDBオプティマイザが不要なテーブル検索を回避し、クエリパフォーマンスを向上させるために、一部のフィルタ条件をプレフィックスインデックスにプッシュダウンするかどうかを制御します。 -- この変数の値が`ON`に設定されている場合、一部のフィルタ条件がプレフィックス インデックスにプッシュダウンされます。たとえば、 `col`列がテーブルのインデックス プレフィックス 列であるとします。クエリ内の`col is null`または`col is not null`条件は、テーブル参照のフィルタ条件ではなく、インデックスのフィルタ条件として処理されるため、不要なテーブル参照が回避されます。 +- この変数の値が`ON`に設定されている場合、一部のフィルタ条件がプレフィックスインデックスにプッシュダウンされます。たとえば、 `col`列がテーブルのインデックスプレフィックス 列であるとします。クエリ内の`col is null`または`col is not null`条件は、テーブル参照のフィルタ条件ではなく、インデックスのフィルタ条件として処理されるため、不要なテーブル参照が回避されます。
    tidb_opt_prefix_index_single_scanの使用例 @@ -5426,7 +5426,7 @@ SHOW WARNINGS; - 型: Enumeration - デフォルト値: `dynamic` - 指定可能な値: `static` 、 `dynamic` 、 `static-only` 、 `dynamic-only` -- パーティション テーブルに`dynamic`モードと`static`モードのどちらを使用するかを指定します。動的パーティショニングは、完全なテーブルレベル統計、またはグローバル統計が収集された後にのみ有効であることに注意してください。グローバル統計の収集が完了する前に`dynamic`プルーニング モードを有効にすると、TiDB はグローバル統計が完全に収集されるまで`static`モードのままになります。グローバル統計の詳細については、 [動的プルーニングモードでパーティションテーブルの統計情報を収集する](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)を参照してください。動的プルーニング モードの詳細については、 [パーティションテーブルの動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を参照してください。 +- パーティションテーブルに`dynamic`モードと`static`モードのどちらを使用するかを指定します。動的パーティショニングは、完全なテーブルレベル統計、またはグローバル統計が収集された後にのみ有効であることに注意してください。グローバル統計の収集が完了する前に`dynamic`プルーニングモードを有効にすると、TiDB はグローバル統計が完全に収集されるまで`static`モードのままになります。グローバル統計の詳細については、 [動的プルーニングモードでパーティションテーブルの統計情報を収集する](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)を参照してください。動的プルーニングモードの詳細については、 [パーティションテーブルの動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を参照してください。 ### tidb_persist_analyze_options New in v5.4.0 @@ -5488,7 +5488,7 @@ SHOW WARNINGS; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値： `2097152` （2 MiB） - 範囲: `[0, 9223372036854775807]` 、バイト単位。単位が「KiB|MiB|GiB|TiB」のメモリ形式もサポートされています。 `0`は制限なしを意味します。 -- この変数は、プリペアドプラン キャッシュまたは非プリペアドプラン キャッシュにキャッシュできるプランの最大サイズを制御します。プランのサイズがこの値を超える場合、プランはキャッシュされません。詳細については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)と[非プリペアドプランキャッシュ](/sql-plan-management.md#usage)を参照してください。 +- この変数は、プリペアドプランキャッシュまたは非プリペアドプランキャッシュにキャッシュできるプランの最大サイズを制御します。プランのサイズがこの値を超える場合、プランはキャッシュされません。詳細については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)と[非プリペアドプランキャッシュ](/sql-plan-management.md#usage)を参照してください。 ### tidb_pprof_sql_cpu New in v4.0 @@ -5699,8 +5699,7 @@ SHOW WARNINGS; - `tidb_restricted_read_only`を`ON`に設定すると、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)が`ON`に更新されます。 - `tidb_restricted_read_only`を`OFF`に設定しても、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は変更されません。 - `tidb_restricted_read_only`が`ON`の場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を`OFF`に設定することはできません。 -- TiDB の DBaaS プロバイダーの場合、TiDB クラスタが別のデータベースのダウンストリーム データベースである場合、TiDB クラスタを読み取り専用にするには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にした上で`tidb_restricted_read_only`を使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を使用してクラスタを書き込み可能にすることができなくなります。これを実現するには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`を制御し、データベース ユーザーには、 `SUPER`権限を持つルート ユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。 -- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 +- TiDB の DBaaS プロバイダーの場合、TiDB クラスタが別のデータベースのダウンストリームデータベースである場合、TiDB クラスタを読み取り専用にするには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にした上で`tidb_restricted_read_only`を使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)を使用してクラスタを書き込み可能にすることができなくなります。これを実現するには、 [セキュリティ強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`を制御し、データベースユーザーには、 `SUPER`権限を持つルートユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` 、 `SHOW` など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 - この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 - TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。 - この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。 @@ -5725,7 +5724,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 @@ -5801,8 +5800,8 @@ SHOW WARNINGS; - 範囲: `0`または`[67108864, 9223372036854775807]` - TiDB v8.4.0 より前では、この変数のデフォルト値は`0`です。 - TiDB v8.4.0以降では、デフォルト値は`536870912`です。以前のバージョンからv8.4.0以降にアップグレードすると、以前のバージョンで設定されていた値が使用されます。 -- この変数は、TiDB のスキーマ キャッシュのサイズを制御します。単位はバイトです。この変数を`0`に設定すると、キャッシュ制限機能が無効になります。この機能を有効にするには、 `[67108864, 9223372036854775807]`の範囲内の値を設定する必要があります。TiDB はこの値を最大使用可能メモリ制限として使用し、Least Recently Used (LRU) アルゴリズムを適用して必要なテーブルをキャッシュすることで、スキーマ情報によって使用されるメモリを効果的に削減します。 -- クラスターに多数のパーティション テーブルが含まれている場合、またはパーティション テーブル ( `TRUNCATE`や`DROP PARTITION`など) に対して DDL 操作を頻繁に実行する場合は、この変数を`0`に設定することをお勧めします。 +- この変数は、TiDB のスキーマキャッシュのサイズを制御します。単位はバイトです。この変数を`0`に設定すると、キャッシュ制限機能が無効になります。この機能を有効にするには、 `[67108864, 9223372036854775807]`の範囲内の値を設定する必要があります。TiDB はこの値を最大使用可能メモリ制限として使用し、Least Recently Used (LRU) アルゴリズムを適用して必要なテーブルをキャッシュすることで、スキーマ情報によって使用されるメモリを効果的に削減します。 +- クラスターに多数のパーティションテーブルが含まれている場合、またはパーティションテーブル ( `TRUNCATE`や`DROP PARTITION`など) に対して DDL 操作を頻繁に実行する場合は、この変数を`0`に設定することをお勧めします。 ### tidb_schema_version_cache_limit New in v7.4.0 @@ -5812,7 +5811,7 @@ SHOW WARNINGS; - デフォルト値: `16` - 範囲: `[2, 255]` - この変数は、TiDBインスタンスにキャッシュできる履歴スキーマバージョンの数を制限します。デフォルト値は`16`で、これはTiDBがデフォルトで16個の履歴スキーマバージョンをキャッシュすることを意味します。 -- 通常、この変数を変更する必要はありません。[ステイル読み取り](/stale-read.md)機能を使用し、DDL 操作が非常に頻繁に実行されると、スキーマ バージョンが頻繁に変更されます。その結果、ステイル読み取りがスナップショットからスキーマ情報を取得しようとすると、スキーマ キャッシュ ミスにより情報の再構築に時間がかかる場合があります。この場合、 `tidb_schema_version_cache_limit`の値を増やすことで (例えば、 `32` )、スキーマ キャッシュ ミスの問題を回避できます。 +- 通常、この変数を変更する必要はありません。[ステイル読み取り](/stale-read.md)機能を使用し、DDL 操作が非常に頻繁に実行されると、スキーマバージョンが頻繁に変更されます。その結果、ステイル読み取りがスナップショットからスキーマ情報を取得しようとすると、スキーマキャッシュ ミスにより情報の再構築に時間がかかる場合があります。この場合、 `tidb_schema_version_cache_limit`の値を増やすことで (例えば、 `32` )、スキーマキャッシュ ミスの問題を回避できます。 - この変数を変更すると、TiDBのメモリ使用量がわずかに増加します。メモリ不足の問題を回避するため、TiDBのメモリ使用量を監視してください。 ### tidb_server_memory_limit New in v6.4.0 @@ -6183,7 +6182,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` -- この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に保存できるデータ ファイルの最大数を指定します。 +- この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に保存できるデータファイルの最大数を指定します。 @@ -6210,7 +6209,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: 整数 - デフォルト値: `3` - 単位：日 -- この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に、永続的なデータ ファイルを保持する最大日数を指定します。 +- この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に、永続的なデータファイルを保持する最大日数を指定します。 @@ -6237,7 +6236,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: 整数 - デフォルト値: `64` - 単位: MiB -- この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合の永続データ ファイルの最大サイズを指定します。 +- この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合の永続データファイルの最大サイズを指定します。 @@ -6725,7 +6724,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) -- この変数は、TiDB が TiKV に送信するトランザクション コミット リクエストのバッチ サイズを制御するために使用されます。アプリケーション ワークロード内のトランザクションの大部分で書き込み操作が多数発生する場合、この変数の値を大きくすることでバッチ処理のパフォーマンスを向上させることができます。ただし、この変数を大きすぎる値に設定して TiKV の単一ログの最大サイズ (デフォルトでは 8 MiB) の制限を超えると、コミットが失敗する可能性があります。 +- この変数は、TiDB が TiKV に送信するトランザクションコミット リクエストのバッチサイズを制御するために使用されます。アプリケーション ワークロード内のトランザクションの大部分で書き込み操作が多数発生する場合、この変数の値を大きくすることでバッチ処理のパフォーマンスを向上させることができます。ただし、この変数を大きすぎる値に設定して TiKV の単一ログの最大サイズ (デフォルトでは 8 MiB) の制限を超えると、コミットが失敗する可能性があります。 @@ -6767,7 +6766,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: Enumeration - デフォルト値: `pessimistic` - 指定可能な値: `pessimistic` 、 `optimistic` -- この変数はトランザクション モードを設定するために使用されます。 TiDB 3.0 は悲観的トランザクションをサポートします。 TiDB 3.0.8 以降、[悲観的トランザクションモード](/pessimistic-transaction.md)はデフォルトで有効になっています。 +- この変数はトランザクションモードを設定するために使用されます。 TiDB 3.0 は悲観的トランザクションをサポートします。 TiDB 3.0.8 以降、[悲観的トランザクションモード](/pessimistic-transaction.md)はデフォルトで有効になっています。 - TiDBをv3.0.7以前のバージョンからv3.0.8以降のバージョンにアップグレードしても、デフォルトのトランザクションモードは変更されません。**新しく作成されたクラスタのみが、デフォルトで悲観的トランザクションモードを使用します**。 - この変数が「楽観的」または「」に設定されている場合、TiDB は[楽観的トランザクションモード](/optimistic-transaction.md)を使用します。 @@ -6831,7 +6830,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: `OFF` - 型: Boolean -- [ファストスキャン](/tiflash/use-fastscan.md)が有効になっている場合 ( `ON`に設定されている場合)、 TiFlash はより効率的なクエリ パフォーマンスを提供しますが、クエリ結果の精度やデータの一貫性は保証されません。 +- [ファストスキャン](/tiflash/use-fastscan.md)が有効になっている場合 ( `ON`に設定されている場合)、 TiFlash はより効率的なクエリパフォーマンスを提供しますが、クエリ結果の精度やデータの一貫性は保証されません。 ### tiflash_fine_grained_shuffle_batch_size New in v6.2.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 diff --git a/table-affinity.md b/table-affinity.md index 35a195638cfc9..67f5971315640 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -15,7 +15,7 @@ PDアフィニティスケジューリングを有効にし、テーブルの`AF ## 制限事項 {#limitations} -テーブル レベルのデータ アフィニティを使用する前に、次の制限に注意してください。 +テーブルレベルのデータ アフィニティを使用する前に、次の制限に注意してください。 - この機能は[PDマイクロサービスモード](/pd-microservices.md)では有効になりません。 - この機能は[一時テーブル](/temporary-tables.md)および[ビュー](/views.md)では動作しません。 @@ -27,9 +27,9 @@ PDアフィニティスケジューリングを有効にし、テーブルの`AF PDアフィニティスケジューリングはデフォルトで無効になっています。テーブルまたはパーティションのアフィニティを設定する前に、この機能を有効にして設定する必要があります。 -1. アフィニティ スケジューリングを有効にするには、PD 構成項目[`schedule.affinity-schedule-limit`](/pd-configuration-file.md#affinity-schedule-limit-new-in-v855) `0`より大きい値に設定します。 +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 @@ -47,7 +47,7 @@ PDアフィニティスケジューリングはデフォルトで無効になっ | 親和性レベル | 範囲 | 効果 | | --------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `AFFINITY='table'` | パーティションテーブル | テーブルのアフィニティを有効にします。PD はテーブルのすべてのリージョンに対して単一のアフィニティ グループを作成します。 | +| `AFFINITY='table'` | パーティションテーブル | テーブルのアフィニティを有効にします。PD はテーブルのすべてのリージョンに対して単一のアフィニティグループを作成します。 | | `AFFINITY='partition'` | パーティションテーブル | テーブル内の各パーティションのアフィニティを有効にします。PDは各パーティションのリージョンごとに個別のアフィニティグループを作成します。例えば、4つのパーティションを持つテーブルの場合、PDは4つの独立したアフィニティグループを作成します。 | | `AFFINITY=''`または`AFFINITY='none'` | `AFFINITY='table'`または`AFFINITY='partition'`で構成されたテーブル | テーブルまたはパーティションのアフィニティを無効にします。アフィニティを無効にすると、PD は対象のテーブルまたはパーティションに対応するアフィニティグループを削除します。これにより、そのテーブルまたはパーティションのリージョンはアフィニティのスケジュール制約の対象外となります。TiKV の自動リージョン分割は、最大 10 分以内にデフォルトの動作に戻ります。 | @@ -86,7 +86,7 @@ ALTER TABLE t1 AFFINITY = ''; - [`SHOW AFFINITY`](/sql-statements/sql-statement-show-affinity.md)番目のステートメントを実行します。`Status`の列には、アフィニティが有効になっているテーブルまたはパーティションと、それらのスケジュールステータスが表示されます。`Status`の列の値の意味は次のとおりです。 - - `Pending` : リーダーまたは投票者がまだ決定されていない場合など、PD はテーブルまたはパーティションのアフィニティ スケジューリングを開始していません。 + - `Pending` : リーダーまたは投票者がまだ決定されていない場合など、PD はテーブルまたはパーティションのアフィニティスケジューリングを開始していません。 - `Preparing` : PD はアフィニティ要件を満たすようにリージョンをスケジュールしています。 - `Stable` : すべてのリージョンが目標配布に到達しました。 diff --git a/table-filter.md b/table-filter.md index 034e1523594c3..1f7ef017ee04a 100644 --- a/table-filter.md +++ b/table-filter.md @@ -1,6 +1,6 @@ --- title: Table Filter -summary: TiDB ツールでのテーブル フィルター機能の使用。 +summary: TiDB ツールでのテーブルフィルター機能の使用。 --- # テーブルフィルター {#table-filter} @@ -204,7 +204,7 @@ tiup dumpling -f 'employees.*' -f '*.WorkOrder' テーブル名がフィルター リスト内のどのルールにも一致しない場合は、デフォルトの動作ではそのような一致しないテーブルは無視されます。 -ブロック リストを作成するには、最初のルールとして明示的に`*.*`を使用する必要があります。そうしないと、すべてのテーブルが除外されます。 +ブロックリストを作成するには、最初のルールとして明示的に`*.*`を使用する必要があります。そうしないと、すべてのテーブルが除外されます。 ```bash # every table will be filtered out diff --git a/temporary-tables.md b/temporary-tables.md index 06f18720b1aa2..6ac778fdc2c7b 100644 --- a/temporary-tables.md +++ b/temporary-tables.md @@ -7,7 +7,7 @@ summary: TiDB の一時テーブル機能について学習し、一時テーブ TiDB v5.3.0では、一時テーブル機能が導入されました。この機能は、アプリケーションの中間結果を一時的に保存するという問題を解決し、頻繁なテーブルの作成と削除から解放します。中間計算データは一時テーブルに保存できます。中間データが不要になると、TiDBは自動的に一時テーブルをクリーンアップして再利用します。これにより、ユーザーアプリケーションの複雑化を防ぎ、テーブル管理のオーバーヘッドを削減し、パフォーマンスを向上させます。 -このドキュメントでは、ユーザー シナリオと一時テーブルの種類を紹介し、一時テーブルのメモリ使用量を制限する使用例と手順を示し、他の TiDB 機能との互換性の制限について説明します。 +このドキュメントでは、ユーザーシナリオと一時テーブルの種類を紹介し、一時テーブルのメモリ使用量を制限する使用例と手順を示し、他の TiDB 機能との互換性の制限について説明します。 ## ユーザーシナリオ {#user-scenarios} @@ -134,7 +134,7 @@ TiDB ローカル一時テーブルの次の機能と制限は、MySQL 一時テ TiDB のローカル一時テーブルは、次の点で MySQL の一時テーブルと互換性がありません。 - TiDB ローカル一時テーブルは`ALTER TABLE`サポートしていません。 -- TiDB ローカル一時テーブルは`ENGINE`テーブル オプションを無視し、常に[メモリ制限](#limit-the-memory-usage-of-temporary-tables)を使用して一時テーブル データを TiDBメモリに格納します。 +- TiDB ローカル一時テーブルは`ENGINE`テーブルオプションを無視し、常に[メモリ制限](#limit-the-memory-usage-of-temporary-tables)を使用して一時テーブルデータを TiDBメモリに格納します。 - ストレージエンジンとして`MEMORY`宣言されている場合、TiDB ローカル一時テーブルは`MEMORY`ストレージエンジンによって制限されません。 - ストレージエンジンとして`INNODB`または`MYISAM`宣言されている場合、TiDB ローカル一時テーブルは InnoDB 一時テーブルに固有のシステム変数を無視します。 - MySQLでは、同じSQL文内で同じ一時テーブルを複数回参照することはできません。TiDBのローカル一時テーブルにはこの制限はありません。 diff --git a/ticdc-deployment-topology.md b/ticdc-deployment-topology.md index 9c80b7c89bc83..62050b0f71355 100644 --- a/ticdc-deployment-topology.md +++ b/ticdc-deployment-topology.md @@ -9,7 +9,7 @@ summary: 最小限の TiDB トポロジに基づく TiCDC のデプロイメン > > TiCDCはv4.0.6以降、一般提供（GA）された機能です。本番環境でご利用いただけます。 -このドキュメントでは、最小限のクラスタ トポロジに基づく[TiCDC](/ticdc/ticdc-overview.md)のデプロイメント トポロジについて説明します。 +このドキュメントでは、最小限のクラスタトポロジに基づく[TiCDC](/ticdc/ticdc-overview.md)のデプロイメント トポロジについて説明します。 TiCDCは、TiDB 4.0で導入されたTiDBの増分データを複製するためのツールです。TiDB、MySQL、Kafka、MQ、ストレージサービスなど、複数のダウンストリームプラットフォームをサポートします。TiCDCは低レイテンシーとネイティブな高可用性を備えています。 @@ -32,9 +32,9 @@ TiCDCは、TiDB 4.0で導入されたTiDBの増分データを複製するため - [TiCDCトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml) - [TiCDCトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 > **Note:** > > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPクラスタコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/ticdc-performance-tuning-methods.md b/ticdc-performance-tuning-methods.md index deb2e66df8963..243d34856a994 100644 --- a/ticdc-performance-tuning-methods.md +++ b/ticdc-performance-tuning-methods.md @@ -19,20 +19,20 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ ### TiCDC の全体的な指標 {#ticdc-overall-metrics} -次のメトリックを使用すると、TiCDC データ レプリケーションの概要を把握できます。 +次のメトリックを使用すると、TiCDC データレプリケーションの概要を把握できます。 -- Changefeed チェックポイント ラグ: アップストリームとダウンストリーム間のデータ複製の進行ラグ (秒単位で測定)。 +- Changefeed チェックポイントラグ: アップストリームとダウンストリーム間のデータ複製の進行ラグ (秒単位で測定)。 TiCDC がデータを消費し、下流に書き込む速度が上流のデータの変化に追いついている場合、この指標は小さなレイテンシー範囲内（通常は 10 秒以内）に留まります。そうでない場合、この指標は増加し続けます。 このメトリック (つまり`Changefeed checkpoint lag` ) が増加する場合、一般的な理由は次のとおりです。 - - システム リソースが不十分: TiCDC の CPU、メモリ、またはディスク領域が不十分な場合、データ処理が遅くなりすぎて、TiCDC 変更フィードのチェックポイントが長くなる可能性があります。 + - システムリソースが不十分: TiCDC の CPU、メモリ、またはディスク領域が不十分な場合、データ処理が遅くなりすぎて、TiCDC 変更フィードのチェックポイントが長くなる可能性があります。 - ネットワークの問題: TiCDC でネットワークの中断、遅延、または帯域幅不足が発生すると、データ転送速度に影響し、TiCDC 変更フィードのチェックポイントが長くなる可能性があります。 - アップストリームのQPSが高い場合：TiCDCで処理するデータが過度に大きい場合、データ処理のタイムアウトが発生し、TiCDCチェンジフィードのチェックポイントが増加する可能性があります。通常、単一のTiCDCノードは最大約60KのQPSを処理できます。 - データベースの問題: - アップストリームTiKVクラスタの`min resolved ts`と最新のPD TSOのギャップが大きくなっています。この問題は通常、アップストリームの書き込みワークロードが過度に重い場合に、TiKVが解決済みのTSを時間内に進めることができないために発生します。 - - ダウンストリーム データベースのレイテンシーが大きいため、TiCDC がダウンストリームにデータをタイムリーに複製できなくなります。 + - ダウンストリームデータベースのレイテンシーが大きいため、TiCDC がダウンストリームにデータをタイムリーに複製できなくなります。 - Changefeed 解決 ts ラグ: TiCDC ノードの内部レプリケーション状態と上流との間の進捗ラグ（秒単位）。このメトリックが高い場合、TiCDC Puller または Sorter モジュールのデータ処理能力が不足しているか、ネットワークレイテンシーやディスクの読み取り/書き込み速度の低下などの問題が発生している可能性があります。このような場合、TiCDC の効率的かつ安定した運用を確保するには、TiCDC ノードの数を増やす、ネットワーク構成を最適化するなどの適切な対策を講じる必要があります。 @@ -52,9 +52,9 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ 次のメトリックを使用すると、TiCDC のデータフロー スループットとダウンストリームレイテンシーを知ることができます。 - Puller 出力イベント/秒: TiCDC ノードの Puller モジュールが Sorter モジュールに 1 秒あたりに送信する行数。 -- ソーター出力イベント/秒: TiCDC ノードのソーター モジュールがマウント モジュールに 1 秒あたりに送信する行数。 +- ソーター出力イベント/秒: TiCDC ノードのソーターモジュールがマウント モジュールに 1 秒あたりに送信する行数。 - マウンター出力イベント/秒: TiCDC ノードのマウンター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 -- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーター モジュールがシンク モジュールに 1 秒あたりに送信する行数。 +- テーブル シンク出力イベント/秒: TiCDC ノードのテーブル ソーターモジュールがシンク モジュールに 1 秒あたりに送信する行数。 - SinkV2 - シンク フラッシュ行数/秒: TiCDC ノードのシンク モジュールがダウンストリームに 1 秒あたりに送信する行数。 - トランザクションシンクの完全フラッシュ期間: TiCDC ノードの MySQL シンクによるダウンストリーム トランザクションの書き込みの平均レイテンシーと p999レイテンシー。 - MQ ワーカーのメッセージ送信期間パーセンタイル: ダウンストリームが Kafka の場合の MQ ワーカーによるメッセージ送信のレイテンシー。 diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index cba977e3437af..28adcddc96547 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -39,7 +39,7 @@ cdc_servers: > **Note:** > -> TiCDC をインストールする前に、 TiUPコントロール マシンと TiCDC ホストの間に[SSH相互信頼とパスワードなしのsudoを手動で設定](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)いることを確認してください。 +> TiCDC をインストールする前に、 TiUPコントロールマシンと TiCDC ホストの間に[SSH相互信頼とパスワードなしのsudoを手動で設定](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)いることを確認してください。 ## TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします。 {#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup} @@ -98,7 +98,7 @@ TiCDCクラスタをアップグレードする際には、以下の点に注意 - TiCDC v4.0.2 は`changefeed`を再構成しました。詳細については、 [コンフィグレーションファイルの互換性に関する注意事項](/ticdc/ticdc-compatibility.md#cli-and-configuration-file-compatibility)を参照してください。 - アップグレード中に問題が発生した場合は、解決策について[アップグレードに関するよくある質問](/upgrade-tidb-using-tiup.md#faq)を参照してください。 -- v6.3.0 以降、TiCDC はローリング アップグレードをサポートしています。マイナー バージョン間のローリング アップグレードを直接実行できます (たとえば、v8.5.0 -> v8.5.3 はマイナー バージョン アップグレードであり、v8.1.x -> v8.5.x はメジャー バージョン アップグレードです)。 TiCDC クラシックアーキテクチャの場合、メジャー バージョン間のアップグレード中に変更フィードを実行しないでください。クラシックアーキテクチャをアップグレードする前に、変更フィードを一時停止してください。新しい TiCDCアーキテクチャは、ローリング アップグレード プロセス中の変更フィードの実行をサポートします。詳細については、 [以前のTiCDCバージョンからのローリングアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。次の条件が満たされる場合、ローリング アップグレードは自動的に有効になります。 +- v6.3.0 以降、TiCDC はローリングアップグレードをサポートしています。マイナー バージョン間のローリングアップグレードを直接実行できます (たとえば、v8.5.0 -> v8.5.3 はマイナー バージョン アップグレードであり、v8.1.x -> v8.5.x はメジャーバージョン アップグレードです)。 TiCDC クラシックアーキテクチャの場合、メジャーバージョン間のアップグレード中に変更フィードを実行しないでください。クラシックアーキテクチャをアップグレードする前に、変更フィードを一時停止してください。新しい TiCDCアーキテクチャは、ローリングアップグレードプロセス中の変更フィードの実行をサポートします。詳細については、 [以前のTiCDCバージョンからのローリングアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。次の条件が満たされる場合、ローリングアップグレードは自動的に有効になります。 - TiCDCはバージョン6.3.0以降です。 - TiUPはバージョン1.11.3以降です。 diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 4ea9153cd5f58..958a8f5e423aa 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -42,7 +42,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ [Confluent Cloud](https://confluent.cloud)にサインインします。**データ統合**> **APIキー**>**キーの作成 を**選択します。表示される**APIキーのスコープの選択**ページで、**グローバルアクセス**を選択します。 - 作成後、以下に示すようにキー ペア ファイルが生成されます。 + 作成後、以下に示すようにキーペア ファイルが生成されます。 === Confluent Cloud API key: xxx-xxxxx === @@ -55,17 +55,17 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ Bootstrap server: xxx-xxxxx.ap-east-1.aws.confluent.cloud:9092 -2. スキーマ レジストリ エンドポイントを記録します。 +2. スキーマレジストリ エンドポイントを記録します。 Confluent Cloud Console で、 **スキーマレジストリ** > **API エンドポイント**を選択します。スキーマレジストリエンドポイントを記録します。以下は例です。 https://yyy-yyyyy.us-east-2.aws.confluent.cloud -3. スキーマ レジストリ API キーを作成します。 +3. スキーマレジストリ API キーを作成します。 Confluent Cloud Console で、 **スキーマレジストリ** > **API 認証情報**を選択します。 **編集**をクリックし、 **「キーの作成」を**クリックします。 - 作成後、次に示すようにキー ペア ファイルが生成されます。 + 作成後、次に示すようにキーペア ファイルが生成されます。 === Confluent Cloud API key: yyy-yyyyy === API key: diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index 14a259af08998..c9c4d515b78bb 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -7,7 +7,7 @@ summary: Grafana TiCDC ダッシュボードに表示されるいくつかの主 TiCDCの現在の状況の概要は、主要な指標が表示されるTiCDCダッシュボードから確認できます。このドキュメントでは、これらの主要な指標について詳しく説明します。 -このドキュメントのメトリックの説明は、デフォルト設定を使用して MySQL にデータを複製する次のレプリケーション タスクの例に基づいています。 +このドキュメントのメトリックの説明は、デフォルト設定を使用して MySQL にデータを複製する次のレプリケーションタスクの例に基づいています。 ```shell cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://root:123456@127.0.0.1:3306/" --changefeed-id="simple-replication-task" @@ -88,11 +88,11 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 ### イベントストア {#event-store} -以下は、**イベント ストア**パネルの例です。 +以下は、**イベントストア**パネルの例です。 ![Event Store](/media/ticdc/ticdc-new-arch-metric-event-store.png) -**イベント ストア**パネルの各メトリックの説明は次のとおりです。 +**イベントストア**パネルの各メトリックの説明は次のとおりです。 - 解決されたTsラグ: イベントストアの処理の進行と上流データベース間のラグ - レジスタディスパッチャStartTsラグ:ディスパッチャ登録StartTsと現在の時刻のラグ @@ -102,7 +102,7 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 - 入力バイト/秒: イベントストアが1秒あたりに処理するデータ量 - 書き込みリクエスト数/秒: イベントストアが1秒あたりに実行する書き込みリクエストの数 - 書き込みワーカービジー率: イベントストア書き込みスレッドの合計実行時間に対するI/O時間の比率 -- 圧縮行数/秒: イベント ストアで 1 秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) +- 圧縮行数/秒: イベントストアで 1 秒あたりに圧縮された行数 (行サイズがしきい値を超えた場合にのみトリガーされます) - 書き込み時間: イベントストアの書き込み操作にかかる時間 - 書き込みバッチサイズ: 1回の書き込み操作のバッチサイズ - 書き込みバッチイベント数: 1回の書き込みバッチに含まれる行変更イベントの数 diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index c6f4c33915e6a..d315a74f2d81e 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -1,6 +1,6 @@ --- title: TiCDC Alert Rules -summary: TiCDC アラート ルールとアラートの処理方法について学習します。 +summary: TiCDC アラートルールとアラートの処理方法について学習します。 --- # TiCDCアラートルール {#ticdc-alert-rules} @@ -21,7 +21,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクが 10 分以上遅延します。 + レプリケーションタスクが 10 分以上遅延します。 - 解決： @@ -35,7 +35,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクの解決された TS が 5 分以上遅延します。 + レプリケーションタスクの解決された TS が 5 分以上遅延します。 - 解決： @@ -49,7 +49,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクで回復不可能なエラーが発生し、失敗状態になります。 + レプリケーションタスクで回復不可能なエラーが発生し、失敗状態になります。 - 解決： @@ -95,7 +95,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクでエラーが発生しました。 + レプリケーションタスクでエラーが発生しました。 - 解決： @@ -109,7 +109,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクはエラーを報告して終了します。 + レプリケーションタスクはエラーを報告して終了します。 - 解決： @@ -151,7 +151,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 説明： - レプリケーション タスクがダウンストリームにデータを書き込むときにエラーが発生します。 + レプリケーションタスクがダウンストリームにデータを書き込むときにエラーが発生します。 - 解決： diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 1f9244e9cf204..8ccf092cab30a 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -167,7 +167,7 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ 2. TiDBクラスタのバージョンがv8.5.4より前の場合は、新しいアーキテクチャのTiCDCバイナリパッケージを手動でダウンロードし、ダウンロードしたファイルをTiDBクラスタにパッチ適用する必要があります。それ以外の場合は、この手順をスキップしてください。 - ダウンロード リンクは次の形式に従います: `https://tiup-mirrors.pingcap.com/cdc-${version}-${os}-${arch}.tar.gz` 。ここで、 `${version}`は TiCDC バージョン (利用可能なバージョン[TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)方向へのリリースを参照)、 `${os}`はオペレーティング システムです。 `${arch}`は、コンポーネントが実行されるプラットフォーム ( `amd64`または`arm64` ) です。 + ダウンロードリンクは次の形式に従います: `https://tiup-mirrors.pingcap.com/cdc-${version}-${os}-${arch}.tar.gz` 。ここで、 `${version}`は TiCDC バージョン (利用可能なバージョン[TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)方向へのリリースを参照)、 `${os}`はオペレーティングシステムです。 `${arch}`は、コンポーネントが実行されるプラットフォーム ( `amd64`または`arm64` ) です。 例えば、Linux (x86-64) 用の TiCDC v8.5.4-release.1 のバイナリパッケージをダウンロードするには、次のコマンドを実行します。 @@ -200,7 +200,7 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ newarch: true ``` -6. すべてのレプリケーション タスクを再開するには、 [レプリケーションタスクを再開する](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task)を参照してください。 +6. すべてのレプリケーションタスクを再開するには、 [レプリケーションタスクを再開する](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task)を参照してください。 ```shell # The default server port of TiCDC is 8300. diff --git a/ticdc/ticdc-avro-checksum-verification.md b/ticdc/ticdc-avro-checksum-verification.md index 55cf242095041..32952480ffa55 100644 --- a/ticdc/ticdc-avro-checksum-verification.md +++ b/ticdc/ticdc-avro-checksum-verification.md @@ -1,13 +1,13 @@ --- title: TiCDC Row Data Checksum Verification Based on Avro -summary: TiCDC 行データ チェックサム検証の詳細な実装を紹介します。 +summary: TiCDC 行データチェックサム検証の詳細な実装を紹介します。 --- # Avroに基づくTiCDC行データチェックサム検証 {#ticdc-row-data-checksum-verification-based-on-avro} このドキュメントでは、TiCDC によって Kafka に送信され、 Golangを使用して Avro プロトコルでエンコードされたデータを使用する方法と、 [単一行データチェックサム機能](/ticdc/ticdc-integrity-check.md)を使用してデータ検証を実行する方法を紹介します。 -この例のソース コードは[`avro-checksum-verification`](https://github.com/pingcap/tiflow/tree/release-8.5/examples/golang/avro-checksum-verification)ディレクトリにあります。 +この例のソースコードは[`avro-checksum-verification`](https://github.com/pingcap/tiflow/tree/release-8.5/examples/golang/avro-checksum-verification)ディレクトリにあります。 このドキュメントの例では、 [kafka-go](https://github.com/segmentio/kafka-go)を使用してシンプルなKafkaコンシューマープログラムを作成します。このプログラムは、指定されたトピックから継続的にデータを読み取り、チェックサムを計算し、その値を検証します。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 7d57ac0b5dc01..186ca6cdb80f2 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -281,7 +281,7 @@ TiCDC Avro プロトコルは[`io.confluent.kafka.serializers.KafkaAvroDeseriali ### イベントの種類を区別する {#distinguish-event-types} -コンシューマー プログラムは、次のルールによって DML イベント タイプを区別できます。 +コンシューマー プログラムは、次のルールによって DML イベントタイプを区別できます。 - Key部分のみの場合はDeleteイベントになります。 - キーと値の両方がある場合、挿入イベントまたは更新イベントのいずれかです。[TiDB拡張フィールド](#tidb-extension-fields)が有効になっている場合は、 `_tidb_op`フィールドを使用して挿入イベントか更新イベントかを識別できます。TiDB拡張フィールドが有効になっていない場合は、それらを区別できません。 diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index 2df52393ef412..647a7345bf0c9 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -13,13 +13,13 @@ TiCDCは、2つのTiDBクラスタ間の双方向レプリケーション（BDR 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クラスターをデプロイ。クラスタートポロジは以下のとおりです。図中の矢印はデータフローの方向を示しています。 ![TiCDC bidirectional replication](/media/ticdc/ticdc-bidirectional-replication.png) -3. アップストリーム クラスターとダウンストリーム クラスターのデータ複製の開始時点を指定します。 +3. アップストリームクラスターとダウンストリームクラスターのデータ複製の開始時点を指定します。 1. 上流クラスタと下流クラスタの時点を確認します。2つのTiDBクラスタがある場合は、特定の時点において2つのクラスタのデータが整合していることを確認します。例えば、TiDB 1の`ts=1`時点のデータとTiDB 2の`ts=2`のデータは整合しています。 @@ -102,7 +102,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま ### 複製可能なDDLのレプリケーションシナリオ {#replication-scenarios-of-replicable-ddls} -1. TiDB クラスターを選択し、 `ADMIN SET BDR ROLE PRIMARY`を実行してそれをプライマリ クラスターとして設定します。 +1. TiDB クラスターを選択し、 `ADMIN SET BDR ROLE PRIMARY`を実行してそれをプライマリクラスターとして設定します。 ```sql ADMIN SET BDR ROLE PRIMARY; @@ -120,7 +120,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま +----------+ ``` -2. 他の TiDB クラスターで`ADMIN SET BDR ROLE SECONDARY`を実行して、それらをセカンダリ クラスターとして設定します。 +2. 他の TiDB クラスターで`ADMIN SET BDR ROLE SECONDARY`を実行して、それらをセカンダリクラスターとして設定します。 3. プライマリクラスターで**レプリケート可能なDDL**を実行します。正常に実行されたDDLは、TiCDCによってセカンダリクラスターにレプリケートされます。 @@ -128,8 +128,8 @@ BDRロールが設定されていない場合、任意のDDLを実行できま > > 不正使用を防ぐために: > -> - プライマリ クラスターで**レプリケートできない DDL を**実行しようとすると、 [エラー8263](/error-codes.md)が返されます。 -> - セカンダリ クラスターで**レプリケート可能な DDL**または**レプリケート不可能な DDL を**実行しようとすると、 [エラー8263](/error-codes.md)が返されます。 +> - プライマリクラスターで**レプリケートできない DDL を**実行しようとすると、 [エラー8263](/error-codes.md)が返されます。 +> - セカンダリクラスターで**レプリケート可能な DDL**または**レプリケート不可能な DDL を**実行しようとすると、 [エラー8263](/error-codes.md)が返されます。 ### 複製不可能なDDLのレプリケーションシナリオ {#replication-scenarios-of-non-replicable-ddls} @@ -137,7 +137,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま 2. すべてのクラスターで DDL を実行する必要があるテーブルへのデータの書き込みを停止します。 3. すべてのクラスター内の対応するテーブルへのすべての書き込みが他のクラスターに複製されるまで待機し、各 TiDB クラスターですべての DDL を手動で実行します。 4. DDL が完了するまで待ってから、データの書き込みを再開します。 -5. レプリケート可能な DDL のレプリケーション シナリオに戻すには、手順[複製可能なDDLのレプリケーションシナリオ](#replication-scenarios-of-replicable-ddls)に従います。 +5. レプリケート可能な DDL のレプリケーションシナリオに戻すには、手順[複製可能なDDLのレプリケーションシナリオ](#replication-scenarios-of-replicable-ddls)に従います。 > **Warning:** > @@ -153,9 +153,9 @@ BDRロールが設定されていない場合、任意のDDLを実行できま - BDR ロールは次のシナリオでのみ使用してください。 - - 1 `PRIMARY`クラスターと n `SECONDARY`クラスター（複製可能な DDL のレプリケーション シナリオ） + - 1 `PRIMARY`クラスターと n `SECONDARY`クラスター（複製可能な DDL のレプリケーションシナリオ） - - BDR ロールを持たない n 個のクラスタ（各クラスタで複製不可能な DDL を手動で実行できるレプリケーション シナリオ） + - BDR ロールを持たない n 個のクラスタ（各クラスタで複製不可能な DDL を手動で実行できるレプリケーションシナリオ） > **Note:** > diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 91fc4469f1580..6311bae937782 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -27,8 +27,8 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --changefeed-id="kafka- Canal-JSONプロトコルは元々MySQL用に設計されており、CommitTSトランザクションのTiDB固有の一意の識別子などの重要なフィールドが含まれていません。この問題を解決するために、TiCDCはCanal-JSONプロトコル形式にTiDB拡張フィールドを追加します`sink-uri`で`enable-tidb-extension`を`true` （デフォルトは`false` ）に設定すると、TiCDCはCanal-JSONメッセージを生成する際に次のように動作します。 -- TiCDC は、 `_tidb`名前のフィールドを含む DML イベント メッセージと DDL イベント メッセージを送信します。 -- TiCDC は WATERMARK イベント メッセージを送信します。 +- TiCDC は、 `_tidb`名前のフィールドを含む DML イベントメッセージと DDL イベントメッセージを送信します。 +- TiCDC は WATERMARK イベントメッセージを送信します。 次に例を示します。 @@ -375,7 +375,7 @@ update tp_int set c_int = 0, c_tinyint = 0 where c_smallint = 32767; } ``` -公式 Canal の場合、出力イベント メッセージの`old`フィールドには、以下に示すように、変更された列データのみが含まれます。 +公式 Canal の場合、出力イベントメッセージの`old`フィールドには、以下に示すように、変更された列データのみが含まれます。 ```json { diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index 872235882320d..ea54b8ba9fecf 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -21,7 +21,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl - `--changefeed-id` : レプリケーションタスクのID。形式は`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 -- `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って設定します。現在、このスキームは`mysql` 、 `tidb` 、および`kafka`をサポートしています。 +- `--sink-uri` : レプリケーションタスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って設定します。現在、このスキームは`mysql` 、 `tidb` 、および`kafka`をサポートしています。 ``` [scheme]://[userinfo@][host]:[port][/path]?[query_parameters] @@ -192,7 +192,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl - changefeed のダウンストリームが MQ シンクの場合、`dispatchers` を使用してイベントディスパッチャを設定できます。v8.5.7 以降、[新しい TiCDC アーキテクチャ](/ticdc/ticdc-architecture.md) では、`dispatchers` を使用してテーブルルーティングを設定し、アップストリームテーブルを特定のダウンストリームデータベース名またはテーブル名にマッピングすることもできます。詳細については、[TiCDC テーブルルーティング](/ticdc/ticdc-table-routing.md) を参照してください。 - バージョン6.1.0以降、TiDBはパーティションとトピックという2種類のイベントディスパッチャをサポートしています。 - マッチャーのマッチング構文は、フィルタルールの構文と同じです。 -- ダウンストリーム MQ が Pulsar の場合、 `partition`のルーティング ルールが`ts` 、 `index-value` 、 `table` 、または`default`にも指定されていない場合、各 Pulsar メッセージは、キーとして設定した文字列を使用してルーティングされます。たとえば、マッチャーのルーティング ルールを文字列`code`として指定した場合、そのマッチャーに一致するすべての Pulsar メッセージは`code`をキーとしてルーティングされます。 +- ダウンストリーム MQ が Pulsar の場合、 `partition`のルーティングルールが`ts` 、 `index-value` 、 `table` 、または`default`にも指定されていない場合、各 Pulsar メッセージは、キーとして設定した文字列を使用してルーティングされます。たとえば、マッチャーのルーティングルールを文字列`code`として指定した場合、そのマッチャーに一致するすべての Pulsar メッセージは`code`をキーとしてルーティングされます。 #### `column-selectors` v7.5.0の新機能） {#column-selectors-new-in-v750} diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index f9b6c4e343dba..af11092eec3a2 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -24,7 +24,7 @@ summary: チェンジフィードの基本的な概念、状態の定義、お > **Note:** > > - GCがchangefeedによってブロックされた場合、changefeedは`gc-ttl`で指定された時間までGCの進行をブロックします。その後、changefeedはエラータイプが`ErrGCTTLExceeded`である状態`failed`に設定され、GCの進行をブロックしなくなります。 -> - 変更フィードでエラー コード`ErrGCTTLExceeded` 、または`ErrStartTsBeforeGC` `ErrSnapshotLostByGC`が発生した場合、GC 操作はブロックされません。 +> - 変更フィードでエラーコード`ErrGCTTLExceeded` 、または`ErrStartTsBeforeGC` `ErrSnapshotLostByGC`が発生した場合、GC 操作はブロックされません。 上記の状態遷移図の数字は以下のように表されます。 @@ -36,7 +36,7 @@ summary: チェンジフィードの基本的な概念、状態の定義、お - ⑥ changefeed は回復不能なエラーに遭遇し、直接 failed 状態に移行します。このとき、changefeed は`gc-ttl`で指定された期間、上流の GC をブロックし続けます。 - ⑦ changefeedのレプリケーション進行状況が`target-ts`で設定した値に到達し、レプリケーションが完了します。 - ⑧ チェンジフィードが`gc-ttl`で指定された値よりも長い期間中断されたため、GC 進行エラーが発生し、再開できません。 -- ⑨ 失敗の原因が解決され、変更フィードが`gc-ttl`で指定された値よりも短い期間中断された場合は、 `changefeed resume`コマンドを実行してレプリケーション タスクを再開します。 +- ⑨ 失敗の原因が解決され、変更フィードが`gc-ttl`で指定された値よりも短い期間中断された場合は、 `changefeed resume`コマンドを実行してレプリケーションタスクを再開します。 ## チェンジフィードを操作する {#operate-changefeeds} diff --git a/ticdc/ticdc-classic-architecture.md b/ticdc/ticdc-classic-architecture.md index 9ac8bfa2b569b..0cbb4f088a4ea 100644 --- a/ticdc/ticdc-classic-architecture.md +++ b/ticdc/ticdc-classic-architecture.md @@ -63,10 +63,10 @@ dispatchers = [ 上記のコマンド`cdc cli changefeed create`は、 `test1.tab1` 、 `test1.tab2` 、 `test3.tab3` 、 `test4.tab4` Kafkaクラスターに複製する changefeed タスクを作成します。TiCDCがこのコマンドを受信した後の処理フローは以下のとおりです。 -1. TiCDC はこのタスクを所有者のキャプチャ プロセスに送信します。 +1. TiCDC はこのタスクを所有者のキャプチャプロセスに送信します。 2. 所有者の Capture プロセスは、この changefeed タスクに関する情報を PD の etcd に保存します。 -3. 所有者のキャプチャ プロセスは、変更フィード タスクを複数のタスクに分割し、完了するタスクを他のキャプチャ プロセスに通知します。 -4. キャプチャ プロセスは TiKV ノードからデータの取得を開始し、データを処理してレプリケーションを完了します。 +3. 所有者のキャプチャプロセスは、変更フィード タスクを複数のタスクに分割し、完了するタスクを他のキャプチャプロセスに通知します。 +4. キャプチャプロセスは TiKV ノードからデータの取得を開始し、データを処理してレプリケーションを完了します。 以下は、Changefeed と Task が含まれた TiCDCアーキテクチャ図です。 @@ -122,7 +122,7 @@ TiCDCは、データ複製の状態を示すために、一連のタイムスタ このタイムスタンプはTiCDCにのみ存在します。これは、このタイムスタンプより前に発生したデータ変更が下流システムに複製されていることを意味します。 -- テーブル CheckpointTS: TiCDC はテーブル内のデータを複製するため、テーブル checkpointTS は、CheckpointTS がテーブル レベルで複製される前に発生したすべてのデータ変更を示します。 +- テーブル CheckpointTS: TiCDC はテーブル内のデータを複製するため、テーブル checkpointTS は、CheckpointTS がテーブルレベルで複製される前に発生したすべてのデータ変更を示します。 - プロセッサ CheckpointTS: プロセッサ上の最小テーブル CheckpointTS を示します。 - グローバル CheckpointTS: すべてのプロセッサ間の最小 CheckpointTS を示します。 @@ -163,14 +163,14 @@ Sorterモジュールは、Pullerモジュールが受信したデータをタ - 所有者ではない TiCDC ノードの場合は、次のように動作します。 - 1. キャプチャ プロセスを開始します。 + 1. キャプチャプロセスを開始します。 2. プロセッサを起動します。 3. 所有者によって実行されたタスク スケジュール コマンドを受け取ります。 4. スケジュール コマンドに従って tablePipeline を開始または停止します。 - 所有者 TiCDC ノードの場合、次のように動作します。 - 1. キャプチャ プロセスを開始します。 + 1. キャプチャプロセスを開始します。 2. ノードがオーナーとして選出され、対応するスレッドが開始されます。 3. 変更フィード情報を読み取ります。 4. 変更フィード管理プロセスを開始します。 @@ -184,6 +184,6 @@ Sorterモジュールは、Pullerモジュールが受信したデータをタ 1. ノードは自身を停止するコマンドを受信します。 2. ノードはサービス ステータスを利用不可に設定します。 -3. ノードは新しいレプリケーション タスクの受信を停止します。 +3. ノードは新しいレプリケーションタスクの受信を停止します。 4. ノードは、オーナー ノードにデータ複製タスクを他のノードに転送するように通知します。 -5. レプリケーション タスクが他のノードに転送されると、ノードは停止します。 +5. レプリケーションタスクが他のノードに転送されると、ノードは停止します。 diff --git a/ticdc/ticdc-client-authentication.md b/ticdc/ticdc-client-authentication.md index a74c796031000..c17a944f400d7 100644 --- a/ticdc/ticdc-client-authentication.md +++ b/ticdc/ticdc-client-authentication.md @@ -1,6 +1,6 @@ --- title: TiCDC Client Authentication -summary: コマンドライン ツールまたは OpenAPI を使用して TiCDC クライアント認証を実行する方法を紹介します。 +summary: コマンドラインツールまたは OpenAPI を使用して TiCDC クライアント認証を実行する方法を紹介します。 --- # TiCDC クライアント認証 {#ticdc-client-authentication} diff --git a/ticdc/ticdc-compatibility.md b/ticdc/ticdc-compatibility.md index fcf62f0666c59..f04697ac74a28 100644 --- a/ticdc/ticdc-compatibility.md +++ b/ticdc/ticdc-compatibility.md @@ -18,7 +18,7 @@ TiCDCの新しいアーキテクチャは、TiDBクラスタv7.5.0以降をサ 論理インポートモードでは、 TiDB Lightning はSQL ステートメントを実行してデータをインポートします。このモードは TiCDC と互換性があります。TiDB Lightning の論理インポートモードを TiCDC でデータレプリケーションに使用するには、次の手順を実行します。 1. チェンジフィードを作成します。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)を参照してください。 -2. TiDB Lightningを起動し、論理インポート モードを使用してデータをインポートします。詳細については、 [論理インポートモードを使用する](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md)を参照してください。 +2. TiDB Lightningを起動し、論理インポートモードを使用してデータをインポートします。詳細については、 [論理インポートモードを使用する](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md)を参照してください。 物理インポートモードでは、 TiDB Lightning はSST ファイルを TiKV に挿入することでデータをインポートします。TiCDC はこのモードと互換性がなく、物理インポートモードでインポートされたデータの複製をサポートしていません。TiDB Lightning の物理インポートモードと TiCDC の両方を使用する必要がある場合は、ダウンストリームシステムに基づいて、以下のいずれかのソリューションを選択してください。 @@ -92,9 +92,9 @@ TiCDC クラシック アーキテクチャと新しいアーキテクチャの TiCDC v5.0.0-rc の`cdc cli`ツールを使用して v4.0.x TiCDC クラスターを操作する場合、次のような異常な状況が発生する可能性があります。 -- TiCDC クラスターが v4.0.8 以前のバージョンである場合、v5.0.0-rc `cdc cli`ツールを使用してレプリケーション タスクを作成すると、クラスターの異常が発生し、レプリケーション タスクが停止する可能性があります。 +- TiCDC クラスターが v4.0.8 以前のバージョンである場合、v5.0.0-rc `cdc cli`ツールを使用してレプリケーションタスクを作成すると、クラスターの異常が発生し、レプリケーションタスクが停止する可能性があります。 -- TiCDC クラスターが v4.0.9 以降のバージョンである場合、v5.0.0-rc `cdc cli`ツールを使用してレプリケーション タスクを作成すると、古い値と統合ソーター機能がデフォルトで予期せず有効になります。 +- TiCDC クラスターが v4.0.9 以降のバージョンである場合、v5.0.0-rc `cdc cli`ツールを使用してレプリケーションタスクを作成すると、古い値と統合ソーター機能がデフォルトで予期せず有効になります。 解決策： diff --git a/ticdc/ticdc-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index 6eb7343432ebe..27beb2624a62e 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -32,13 +32,13 @@ TiCDC は、次の種類のアップストリーム データの変更をサポ - **サポート対象:** - - DDL および DML ステートメント (システム テーブルを除く)。 + - DDL および DML ステートメント (システムテーブルを除く)。 - インデックス操作（ `ADD INDEX` `CREATE INDEX` ：ダウンストリームがTiDB、TiCDC [`ADD INDEX`および`CREATE INDEX` DDL操作を非同期的に実行します](/ticdc/ticdc-ddl.md#asynchronous-execution-of-add-index-and-create-index-ddls)の場合、変更フィードレプリケーションのレイテンシーへの影響を軽減します。 - 外部キー制約DDL文（ `ADD FOREIGN KEY` ）：TiCDCは上流のシステム変数設定を複製し**ません**。下流の外部キー制約チェックを有効にするには、下流で[`foreign_key_checks`](/system-variables.md#foreign_key_checks)手動で設定する必要があります。また、下流にデータを書き込む際に、TiCDCはセッションレベルの設定`SET SESSION foreign_key_checks = OFF;`を自動的に有効にします。したがって、下流でグローバル外部キーチェックが有効になっている場合でも、TiCDCによって書き込まれたデータは外部キー制約の検証をトリガーしません。 - **サポートされていません**: - - アップストリーム システム テーブルで実行された DDL および DML ステートメント ( `mysql.*`および`information_schema.*`を含む)。 + - アップストリーム システムテーブルで実行された DDL および DML ステートメント ( `mysql.*`および`information_schema.*`を含む)。 - アップストリーム一時テーブルで実行された DDL および DML ステートメント。 - DQL (データ クエリ言語) および DCL (データ制御言語) ステートメント。 @@ -48,7 +48,7 @@ TiCDC は、次の種類のアップストリーム データの変更をサポ - TiCDCは上流データの変更の整合性のみを検証します。変更が上流または下流の制約に準拠しているかどうかは検証しません。データが下流の制約に違反している場合、TiCDCは下流への書き込み時にエラーを返します。 - たとえば、変更フィードがすべての DDL イベントをフィルターするように設定されている場合、アップストリームが`DROP COLUMN`操作を実行しても、その列に関連する`INSERT`ステートメントの書き込みを継続すると、テーブル スキーマの不一致により、TiCDC はこれらの DML 変更をダウンストリームに複製できません。 + たとえば、変更フィードがすべての DDL イベントをフィルターするように設定されている場合、アップストリームが`DROP COLUMN`操作を実行しても、その列に関連する`INSERT`ステートメントの書き込みを継続すると、テーブルスキーマの不一致により、TiCDC はこれらの DML 変更をダウンストリームに複製できません。 - TiCDC [古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)の場合、単一の TiCDC クラスターによって複製されるテーブルの数が次の推奨値を超えると、TiCDC が安定して動作しない可能性があります。 @@ -62,4 +62,4 @@ TiCDC は、次の種類のアップストリーム データの変更をサポ > > パーティション化されたテーブルを複製する場合、TiCDC は各パーティションを個別のテーブルとして扱います。そのため、複製するテーブルの総数を計算する際には、パーティション数も考慮されます。 - 複製するテーブルの数が前述の推奨値を超える場合は、 [TiCDCの新しいアーキテクチャ](/ticdc/ticdc-architecture.md)を使用することをお勧めします。新しいアーキテクチャでは、変更フィードごとに 100 万を超えるテーブルの複製がサポートされているため、大規模なレプリケーション シナリオに適しています。 + 複製するテーブルの数が前述の推奨値を超える場合は、 [TiCDCの新しいアーキテクチャ](/ticdc/ticdc-architecture.md)を使用することをお勧めします。新しいアーキテクチャでは、変更フィードごとに 100 万を超えるテーブルの複製がサポートされているため、大規模なレプリケーションシナリオに適しています。 diff --git a/ticdc/ticdc-ddl.md b/ticdc/ticdc-ddl.md index a9de3b26e1846..069453cac8aba 100644 --- a/ticdc/ticdc-ddl.md +++ b/ticdc/ticdc-ddl.md @@ -21,7 +21,7 @@ summary: TiCDC でサポートされている DDL ステートメントといく > **Note** > > - アップストリームテーブルに有効なインデックスがなく、かつ`force-replicate=true`が設定されていない場合、テーブルはレプリケートされません。ただし、このテーブルに有効なインデックスを作成する後続のDDL文（ `CREATE INDEX` 、 `ADD INDEX` 、 `ADD PRIMARY KEY`を含む）はレプリケートされます。これにより、ダウンストリームテーブルとアップストリームテーブルのスキーマ間に不整合が生じ、その後のデータレプリケーションが失敗する可能性があります。 -> - 最後の有効なインデックスを削除する DDL ステートメント ( `DROP INDEX`と`DROP PRIMARY KEY`を含む) は複製されないため、後続のデータ レプリケーションが失敗します。 +> - 最後の有効なインデックスを削除する DDL ステートメント ( `DROP INDEX`と`DROP PRIMARY KEY`を含む) は複製されないため、後続のデータレプリケーションが失敗します。 | DDL | 有効なインデックスが存在します | 有効なインデックスが存在せず、 `force-replicate`は`false` (デフォルト) です | 有効なインデックスが存在せず、 `force-replicate` `true`に設定されている | | ------------------------------ | :-------------: | :--------------------------------------------------: | :----------------------------------------------: | @@ -72,7 +72,7 @@ TiCDC は通常 DDL ステートメントを順番にレプリケートします ### テーブル名の変更に関するDDLレプリケーションの考慮事項 {#ddl-replication-considerations-for-renaming-tables} -レプリケーション プロセス中に一部のコンテキストが欠如しているため、TiCDC では`RENAME TABLE` DDL のレプリケーションにいくつかの制約があります。 +レプリケーションプロセス中に一部のコンテキストが欠如しているため、TiCDC では`RENAME TABLE` DDL のレプリケーションにいくつかの制約があります。 #### DDL ステートメントで単一のテーブルの名前を変更する {#rename-a-single-table-in-a-ddl-statement} @@ -97,7 +97,7 @@ TiCDC はこのタイプの DDL を次のように処理します。 #### DDL ステートメントで複数のテーブルの名前を変更する {#rename-multiple-tables-in-a-ddl-statement} -DDL ステートメントで複数のテーブルの名前を変更する場合、TiCDC は、**古いデータベース名**、**古いテーブル名**、および**新しいデータベース名が**すべてフィルター ルールに一致する場合にのみ、DDL ステートメントを複製します。 +DDL ステートメントで複数のテーブルの名前を変更する場合、TiCDC は、**古いデータベース名**、**古いテーブル名**、および**新しいデータベース名が**すべてフィルタールールに一致する場合にのみ、DDL ステートメントを複製します。 また、TiCDCはテーブル名を入れ替える`RENAME TABLE` DDLをサポートしていません。以下に例を示します。 @@ -112,16 +112,16 @@ TiCDC はこのタイプの DDL を次のように処理します。 | DDL | 複製するかどうか | 取り扱い理由 | | -------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------- | -| `RENAME TABLE test.t1 TO test.t2, test.t3 TO test.t4` | 複製する | すべてのデータベース名とテーブル名はフィルター ルールに一致します。 | -| `RENAME TABLE test.t1 TO test.ignore1, test.t3 TO test.ignore2` | 複製する | 古いデータベース名、古いテーブル名、および新しいデータベース名は、フィルター ルールと一致します。 | -| `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;` | エラーを報告する | 新しいデータベース名`ignore`フィルター ルールと一致しません。 | +| `RENAME TABLE test.t1 TO test.t2, test.t3 TO test.t4` | 複製する | すべてのデータベース名とテーブル名はフィルタールールに一致します。 | +| `RENAME TABLE test.t1 TO test.ignore1, test.t3 TO test.ignore2` | 複製する | 古いデータベース名、古いテーブル名、および新しいデータベース名は、フィルタールールと一致します。 | +| `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;` | エラーを報告する | 新しいデータベース名`ignore`フィルタールールと一致しません。 | | `RENAME TABLE test.t1 TO test.t4, test.t3 TO test.t1, test.t4 TO test.t3;` | エラーを報告する | `RENAME TABLE` DDL文は、1つのDDL文内で`test.t1`と`test.t3`の名前を入れ替えているため、TiCDCはこれを正しく処理できません。この場合、エラーメッセージを参照して対処してください。 | ### DDL文の考慮事項 {#ddl-statement-considerations} アップストリームでクロスデータベースDDL文（例： `CREATE TABLE db1.t1 LIKE t2` ）を実行する場合、関連するすべてのデータベース名をDDL文（例： `CREATE TABLE db1.t1 LIKE db2.t2` ）で明示的に指定することをお勧めします。そうしないと、データベース名情報が不足しているため、ダウンストリームでクロスデータベースDDL文が正しく実行されない可能性があります。 -### イベント フィルタ ルールを使用して DDL イベントをフィルタする場合の注意事項 {#notes-on-using-event-filter-rules-to-filter-ddl-events} +### イベントフィルタルールを使用して DDL イベントをフィルタする場合の注意事項 {#notes-on-using-event-filter-rules-to-filter-ddl-events} フィルタリングされたDDL文がテーブルの作成または削除を伴う場合、TiCDCはDML文のレプリケーション動作に影響を与えることなく、DDL文のみをフィルタリングします。以下に例を示します。 @@ -139,12 +139,12 @@ ignore-event = ["create table", "drop table", "truncate table", "rename table"] | DDL | DDLの動作 | DMLの動作 | 説明 | | ------------------------------------------------------ | ------ | --------- | ---------------------------------------------------------------------------------------------------------------------------- | | `CREATE TABLE test.t1 (id INT, name VARCHAR(50));` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `CREATE TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | -| `CREATE TABLE test.t2 (id INT, name VARCHAR(50));` | 複製する | 複製する | `test.t2`はイベント フィルタ ルールと一致しません。 | -| `CREATE TABLE test.ignore (id INT, name VARCHAR(50));` | 無視する | 無視する | `test.ignore`イベント フィルタ ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | +| `CREATE TABLE test.t2 (id INT, name VARCHAR(50));` | 複製する | 複製する | `test.t2`はイベントフィルタルールと一致しません。 | +| `CREATE TABLE test.ignore (id INT, name VARCHAR(50));` | 無視する | 無視する | `test.ignore`イベントフィルタルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | | `DROP TABLE test.t1;` | 無視する |
  • | `test.t1`イベントフィルタルールに一致するため、イベント`DROP TABLE`は無視されます。テーブルが削除されたため、TiCDC は`t1`の DML イベントを複製しなくなります。 | | `TRUNCATE TABLE test.t1;` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `TRUNCATE TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | | `RENAME TABLE test.t1 TO test.t2;` | 無視する | 複製する | `test.t1`イベントフィルタルールに一致するため、 `RENAME TABLE`イベントは無視されます。DMLイベントのレプリケーションは影響を受けません。 | -| `RENAME TABLE test.t1 TO test.ignore;` | 無視する | 無視する | `test.t1`イベント フィルター ルールに一致するため、 `RENAME TABLE`イベントは無視されます。`test.ignore`イベント フィルター ルールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | +| `RENAME TABLE test.t1 TO test.ignore;` | 無視する | 無視する | `test.t1`イベントフィルタールールに一致するため、 `RENAME TABLE`イベントは無視されます。`test.ignore`イベントフィルタールールに一致するため、DDL イベントと DML イベントの両方が無視されます。 | > **Note:** > diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 17804df15a947..2c9919c8cf4eb 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -18,13 +18,13 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい - `start-ts`という値は、現在の TiDB クラスターの`tikv_gc_safe_point`という値よりも大きいです。それ以外の場合、タスクの作成時にエラーが発生します。 - タスクを開始する前に、ダウンストリームにすべてのデータが`start-ts`あることを確認してください。メッセージキューにデータを複製するなどのシナリオでは、アップストリームとダウンストリーム間のデータの整合性が要求されない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。 -`start-ts`を指定しない場合、または`start-ts` `0`として指定した場合、レプリケーション タスクが開始されると、TiCDC は現在の TSO を取得し、この TSO からタスクを開始します。 +`start-ts`を指定しない場合、または`start-ts` `0`として指定した場合、レプリケーションタスクが開始されると、TiCDC は現在の TSO を取得し、この TSO からタスクを開始します。 ## TiCDC でタスクを作成するときに一部のテーブルを複製できないのはなぜですか? {#why-cant-some-tables-be-replicated-when-i-create-a-task-in-ticdc} `cdc cli changefeed create`を実行してレプリケーションタスクを作成すると、TiCDC は上流のテーブルが[レプリケーション要件](/ticdc/ticdc-overview.md#best-practices)を満たしているかどうかを確認します。要件を満たしていないテーブルがある場合は、 `some tables are not eligible to replicate`が、不適格なテーブルのリストとともに返されます。タスクの作成を続行するには`Y`または`y`を選択できます。この場合、これらのテーブルに対するすべての更新はレプリケーション中に自動的に無視されます。 `Y`または`y`以外の入力を選択した場合、レプリケーションタスクは作成されません。 -## TiCDC レプリケーション タスクの状態を確認するにはどうすればよいですか? {#how-do-i-view-the-state-of-ticdc-replication-tasks} +## TiCDC レプリケーションタスクの状態を確認するにはどうすればよいですか? {#how-do-i-view-the-state-of-ticdc-replication-tasks} TiCDC レプリケーションタスクのステータスを表示するには、 `cdc cli`を使用します。例: @@ -87,7 +87,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 - **方法 1** : 変更フィードのチェックポイントを照会します (推奨)。 - すべてのレプリケーション タスクのチェックポイントを表示するには、 [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md) `cdc cli`を使用します。 + すべてのレプリケーションタスクのチェックポイントを表示するには、 [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md) `cdc cli`を使用します。 ```shell cdc cli changefeed list --server=http://127.0.0.1:8300 @@ -162,7 +162,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 v4.0.0-rc.1以降、PDはサービスレベルのGCセーフポイントの設定において外部サービスをサポートします。どのサービスでもGCセーフポイントを登録・更新できます。PDは、このGCセーフポイント以降のキーバリューデータがGCによってクリーンアップされないようにします。 -この機能により、レプリケーション タスクが利用できないか中断された場合でも、TiCDC によって消費されるデータは GC によって消去されることなく TiKV に保持されます。 +この機能により、レプリケーションタスクが利用できないか中断された場合でも、TiCDC によって消費されるデータは GC によって消去されることなく TiKV に保持されます。 TiCDCサーバーの起動時に、GCセーフポイントのTime To Live（TTL）期間を`gc-ttl`設定することで指定できます。また、 [TiUPを使用して変更する](/ticdc/deploy-ticdc.md#modify-ticdc-cluster-configurations-using-tiup) `gc-ttl`を設定することもできます。デフォルト値は24時間です。TiCDCでは、この値は以下の意味を持ちます。 @@ -183,18 +183,18 @@ TiCDCサービスの起動後にレプリケーションタスクが開始され TiCDC がサービス GC セーフポイントに設定するデフォルトの Time-To-Live (TTL) は 24 時間です。つまり、TiCDC サービスが中断されてから 24 時間以内に回復できる場合、GC メカニズムはレプリケーションを続行するために TiCDC が必要とするデータを削除しません。 -## レプリケーション タスクが失敗した後に回復するにはどうすればよいですか? {#how-to-recover-a-replication-task-after-it-fails} +## レプリケーションタスクが失敗した後に回復するにはどうすればよいですか? {#how-to-recover-a-replication-task-after-it-fails} -1. `cdc cli changefeed query`を使用してレプリケーション タスクのエラー情報を照会し、できるだけ早くエラーを修正します。 -2. 値を`gc-ttl`に増やすと、エラーを修正するための時間が長くなり、エラーが修正された後にレプリケーションの遅延が`gc-ttl`超えたためにレプリケーション タスクが`failed`ステータスにならないようになります。 -3. システムへの影響を評価した後、TiDB の値を[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)増やして GC をブロックし、データを保持して、エラーが修正された後に GC がデータをクリーンアップすることによってレプリケーション タスクが`failed`ステータスにならないようにします。 +1. `cdc cli changefeed query`を使用してレプリケーションタスクのエラー情報を照会し、できるだけ早くエラーを修正します。 +2. 値を`gc-ttl`に増やすと、エラーを修正するための時間が長くなり、エラーが修正された後にレプリケーションの遅延が`gc-ttl`超えたためにレプリケーションタスクが`failed`ステータスにならないようになります。 +3. システムへの影響を評価した後、TiDB の値を[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)増やして GC をブロックし、データを保持して、エラーが修正された後に GC がデータをクリーンアップすることによってレプリケーションタスクが`failed`ステータスにならないようにします。 ## TiCDC タイムゾーンとupstream/downstreamデータベースのタイムゾーンの関係を理解するにはどうすればよいでしょうか? {#how-to-understand-the-relationship-between-the-ticdc-time-zone-and-the-time-zones-of-the-upstreamdownstream-databases} | | 上流タイムゾーン | TiCDCタイムゾーン | 下流タイムゾーン | | :----------: | :-------------------------------------------------------------------------: | :----------------------------------------------------------------------------------: | :------------------------------------------------------------------------------: | | コンフィグレーション方法 | [タイムゾーンのサポート](/configure-time-zone.md)参照 | TiCDCサーバーを起動するときに`--tz`パラメータを使用して設定されます | `sink-uri`の`time-zone`パラメータを使用して設定します。このパラメータは、シンクが`mysql`または`tidb`の場合のみ有効です。 | -| 説明 | アップストリーム TiDB のタイムゾーン。タイムスタンプ タイプの DML 操作と、タイムスタンプ タイプの列に関連する DDL 操作に影響します。 | TiCDC は、アップストリーム TiDB のタイム ゾーンが TiCDC のタイム ゾーン構成と同じであると想定し、タイムスタンプ列に対して関連する操作を実行します。 | ダウンストリーム`mysql`および`tidb`シンクは、接続セッションのタイム ゾーン設定に従って、DML および DDL 操作のタイムスタンプを処理します。 | +| 説明 | アップストリーム TiDB のタイムゾーン。タイムスタンプ タイプの DML 操作と、タイムスタンプ タイプの列に関連する DDL 操作に影響します。 | TiCDC は、アップストリーム TiDB のタイムゾーンが TiCDC のタイムゾーン構成と同じであると想定し、タイムスタンプ列に対して関連する操作を実行します。 | ダウンストリーム`mysql`および`tidb`シンクは、接続セッションのタイムゾーン設定に従って、DML および DDL 操作のタイムスタンプを処理します。 | > **Note:** > @@ -204,13 +204,13 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの > > TiCDCサーバーのタイムゾーンを設定する際は、時刻タイプの変換に使用されるため、注意してください。上流のタイムゾーン、TiCDCのタイムゾーン、下流のタイムゾーンは一致させてください。TiCDCサーバーは、以下の優先順位でタイムゾーンを選択します。 > -> - TiCDC はまず`--tz`を使用して指定されたタイム ゾーンを使用します。 -> - `--tz`利用できない場合、TiCDC は`TZ`環境変数を使用してタイム ゾーン セットを読み取ろうとします。 +> - TiCDC はまず`--tz`を使用して指定されたタイムゾーンを使用します。 +> - `--tz`利用できない場合、TiCDC は`TZ`環境変数を使用してタイムゾーン セットを読み取ろうとします。 > - `TZ`環境変数が使用できない場合、TiCDC はマシンのデフォルトのタイムゾーンを使用します。 -## `--config`で構成ファイルを指定せずにレプリケーション タスクを作成した場合、TiCDC のデフォルトの動作はどうなりますか? {#what-is-the-default-behavior-of-ticdc-if-i-create-a-replication-task-without-specifying-the-configuration-file-in---config} +## `--config`で構成ファイルを指定せずにレプリケーションタスクを作成した場合、TiCDC のデフォルトの動作はどうなりますか? {#what-is-the-default-behavior-of-ticdc-if-i-create-a-replication-task-without-specifying-the-configuration-file-in---config} -`-config`パラメータを指定せずに`cdc cli changefeed create`コマンドを使用すると、TiCDC は次のデフォルト動作でレプリケーション タスクを作成します。 +`-config`パラメータを指定せずに`cdc cli changefeed create`コマンドを使用すると、TiCDC は次のデフォルト動作でレプリケーションタスクを作成します。 - システムテーブルを除くすべてのテーブルを複製します - [有効なインデックス](/ticdc/ticdc-overview.md#best-practices)を含むテーブルのみを複製します @@ -253,7 +253,7 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="kafka://127 はい。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} +## 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} 情報はKafkaメッセージのキーに含まれます。例: @@ -272,9 +272,9 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="kafka://127 Kafka メッセージのキーの`ts` 18 ビット右に移動すると、Unix タイムスタンプを取得できます。 -## TiCDC オープン プロトコルは`null`どのように表現しますか? {#how-does-ticdc-open-protocol-represent-null} +## TiCDC オープンプロトコルは`null`どのように表現しますか? {#how-does-ticdc-open-protocol-represent-null} -TiCDC オープン プロトコルでは、タイプ コード`6`は`null`表します。 +TiCDC オープンプロトコルでは、タイプ コード`6`は`null`表します。 | タイプ | コード | 出力例 | 注記 | | :-- | :-- | :----------------- | :- | @@ -282,7 +282,7 @@ TiCDC オープン プロトコルでは、タイプ コード`6`は`null`表し 詳細については[TiCDCオープンプロトコル列タイプコード](/ticdc/ticdc-open-protocol.md#column-type-code)を参照してください。 -## TiCDC オープン プロトコルの行変更イベントが`INSERT`イベントなのか`UPDATE`イベントなのかをどのように判断すればよいですか? {#how-can-i-tell-if-a-row-changed-event-of-ticdc-open-protocol-is-an-insert-event-or-an-update-event} +## TiCDC オープンプロトコルの行変更イベントが`INSERT`イベントなのか`UPDATE`イベントなのかをどのように判断すればよいですか? {#how-can-i-tell-if-a-row-changed-event-of-ticdc-open-protocol-is-an-insert-event-or-an-update-event} - `UPDATE`イベントには`"p"`と`"u"`両方のフィールドが含まれます - `INSERT`イベントには`"u"`フィールドのみが含まれます @@ -307,7 +307,7 @@ v6.0.0以降、TiCDCはメタデータストレージメカニズムを最適化 TiCDCは、大規模トランザクション（5GBを超える）を部分的にサポートしています。シナリオによっては、以下のリスクが発生する可能性があります。 - プライマリ - セカンダリ レプリケーションのレイテンシーが大幅に増加する可能性があります。 -- TiCDC の内部処理能力が不足している場合、レプリケーション タスク エラー`ErrBufferReachLimit`が発生する可能性があります。 +- TiCDC の内部処理能力が不足している場合、レプリケーションタスク エラー`ErrBufferReachLimit`が発生する可能性があります。 - TiCDC の内部処理能力が不足している場合、または TiCDC のダウンストリームのスループット能力が不足している場合、メモリ不足 (OOM) が発生する可能性があります。 TiCDC v6.2以降、単一テーブルトランザクションを複数のトランザクションに分割できるようになりました。これにより、大規模トランザクションのレプリケーションにおけるレイテンシーとメモリ消費量を大幅に削減できます。したがって、アプリケーションでトランザクションのアトミック性に対する要件がそれほど高くない場合は、レプリケーションのレイテンシーとOOM（オブジェクトオーバーヘッド）を回避するために、大規模トランザクションの分割を有効にすることを推奨します。分割を有効にするには、シンクURIパラメータの値を[`transaction-atomicity`](/ticdc/ticdc-sink-to-mysql.md#configure-sink-uri-for-mysql-or-tidb)から`none`に設定してください。 @@ -317,7 +317,7 @@ TiCDC v6.2以降、単一テーブルトランザクションを複数のトラ 1. 大規模トランザクションにより終了した changefeed の`checkpoint-ts`を記録し、この TSO をBR増分バックアップの`--lastbackupts`として使用して[増分データバックアップ](/br/br-incremental-guide.md#back-up-incremental-data)を実行します。 2. 増分データをバックアップした後、 BRログ出力に`["Full backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0"] [BackupTS=421758868510212097]`に似たログレコードが見つかります。このログに`BackupTS`を記録してください。 3. [増分データを復元する](/br/br-incremental-guide.md#restore-incremental-data) 。 -4. 新しい変更フィードを作成し、レプリケーション タスクを`BackupTS`から開始します。 +4. 新しい変更フィードを作成し、レプリケーションタスクを`BackupTS`から開始します。 5. 古い変更フィードを削除します。 ## TiCDC は、損失のある DDL 操作によって発生したデータの変更をダウンストリームに複製しますか? {#does-ticdc-replicate-data-changes-caused-by-lossy-ddl-operations-to-the-downstream} @@ -355,7 +355,7 @@ mysql root@127.0.0.1:test> show create table test; v5.0.1 または v4.0.13 以降、MySQL へのレプリケーションごとに、TiCDC は上流と下流の間で時刻型の一貫性を保つために、自動的に`explicit_defaults_for_timestamp = ON`設定します。v5.0.1 または v4.0.13 より前のバージョンでは、TiCDC を使用して時刻型データをレプリケーションする際に、不一致な`explicit_defaults_for_timestamp`値によって発生する互換性の問題にご注意ください。 -## TiCDC レプリケーション タスクを作成するときに`safe-mode` `true`に設定すると、アップストリームからの`INSERT` / `UPDATE`ステートメントがダウンストリームにレプリケートされた後に`REPLACE INTO`になるのはなぜですか? {#why-do-insertupdate-statements-from-the-upstream-become-replace-into-after-being-replicated-to-the-downstream-if-i-set-safe-mode-to-true-when-i-create-a-ticdc-replication-task} +## TiCDC レプリケーションタスクを作成するときに`safe-mode` `true`に設定すると、アップストリームからの`INSERT` / `UPDATE`ステートメントがダウンストリームにレプリケートされた後に`REPLACE INTO`になるのはなぜですか? {#why-do-insertupdate-statements-from-the-upstream-become-replace-into-after-being-replicated-to-the-downstream-if-i-set-safe-mode-to-true-when-i-create-a-ticdc-replication-task} TiCDCは、すべてのデータが少なくとも1回は複製されることを保証します。下流に重複データが存在する場合、書き込み競合が発生します。この問題を回避するために、TiCDCは`INSERT`と`UPDATE`ステートメントを`REPLACE INTO`ステートメントに変換します。この動作は`safe-mode`パラメータによって制御されます。 @@ -367,29 +367,29 @@ v6.1.3以降のバージョンでは、デフォルト値の`safe-mode`が`false 上流の書き込みトラフィックがピーク時になると、下流ではすべてのデータをタイムリーに消費できず、データが蓄積される可能性があります。TiCDCは、蓄積されたデータをディスクで処理します。TiCDCは通常の動作中にディスクにデータを書き込む必要があります。しかし、ディスクへの書き込みは100ミリ秒以内のレイテンシーしか発生しないため、これは通常、レプリケーションのスループットとレイテンシーのボトルネックにはなりません。TiCDCはメモリを使用してディスクからのデータの読み取りを高速化し、レプリケーションのパフォーマンスを向上させます。 -## TiDB Lightning物理インポート モードと TiCDC 間の互換性の制限は何ですか? {#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc} +## TiDB Lightning物理インポートモードと TiCDC 間の互換性の制限は何ですか? {#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc} TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)はSSTファイルを直接生成し、TiKVクラスターにインポートします。このインポートモードでは通常のデータ書き込みプロセスをバイパスするため、変更ログは生成されません。ほとんどの場合、変更フィードはこれらのデータ変更を検出できません。変更フィードは、変更フィードの初期化時、またはリージョンの変更（分割、マージ、リーダー移行など）によって増分スキャンがトリガーされた場合にのみ、このデータを検出できます。そのため、変更フィードはTiDB Lightningの物理インポートモードでインポートされたデータを完全にキャプチャすることはできません。 TiDB Lightning物理インポートモードを使用してインポートされたテーブルが、変更フィードによって監視されているテーブルと重複している場合、不完全なデータキャプチャにより、レプリケーションの停止や上流と下流間のデータ不整合などのエラーが発生する可能性があります。TiCDC によってレプリケートされたテーブルをTiDB Lightning物理インポートモードを使用してインポートする必要がある場合は、以下の手順に従ってください。 -1. これらのテーブルに関連する TiCDC レプリケーション タスクを削除します。 +1. これらのテーブルに関連する TiCDC レプリケーションタスクを削除します。 -2. TiDB Lightning物理インポート モードを使用して、TiCDC の上流クラスターと下流クラスターにそれぞれデータをインポートします。 +2. TiDB Lightning物理インポートモードを使用して、TiCDC の上流クラスターと下流クラスターにそれぞれデータをインポートします。 -3. インポートが完了したら、アップストリーム クラスターとダウンストリーム クラスター内の対応するテーブルのデータの整合性を確認します。 +3. インポートが完了したら、アップストリームクラスターとダウンストリームクラスター内の対応するテーブルのデータの整合性を確認します。 -4. インポート完了後のタイムスタンプ (TSO) を`start-ts`として使用して、増分レプリケーションを再開するための新しい TiCDC レプリケーション タスクを作成します。 +4. インポート完了後のタイムスタンプ (TSO) を`start-ts`として使用して、増分レプリケーションを再開するための新しい TiCDC レプリケーションタスクを作成します。 ```shell cdc cli changefeed create -c "upstream-to-downstream-some-tables" --start-ts=431434047157698561 --sink-uri="mysql://root@127.0.0.1:4000?time-zone=" ``` -TiDB Lightning物理インポート モードによってインポートされたテーブルが、どの変更フィードによっても監視されるテーブルと重複しない場合は、 TiDB Lightning構成ファイルで[`check-requirements`](/tidb-lightning/tidb-lightning-configuration.md#check-requirements) ～ `false`設定して、データのインポートを強制することができます。 +TiDB Lightning物理インポートモードによってインポートされたテーブルが、どの変更フィードによっても監視されるテーブルと重複しない場合は、 TiDB Lightning構成ファイルで[`check-requirements`](/tidb-lightning/tidb-lightning-configuration.md#check-requirements) ～ `false`設定して、データのインポートを強制することができます。 ## BRと TiCDC 間の互換性の制限は何ですか? {#what-are-the-compatibility-limitations-between-br-and-ticdc} -BR （バックアップ＆リストア）はSSTファイルを直接生成し、TiKVクラスターにインポートするため、変更フィードではBRによって復元されたデータを完全にキャプチャすることを保証できません。詳細については、 [TiDB Lightning物理インポート モードと TiCDC 間の互換性の制限は何ですか?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 +BR （バックアップ＆リストア）はSSTファイルを直接生成し、TiKVクラスターにインポートするため、変更フィードではBRによって復元されたデータを完全にキャプチャすることを保証できません。詳細については、 [TiDB Lightning物理インポートモードと TiCDC 間の互換性の制限は何ですか?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 BR はバージョンに応じて互換性を異なる方法で処理します。 @@ -415,7 +415,7 @@ TiCDC v6.5.2より前のバージョンでは、TiCDCをダウンストリーム `ADD INDEX` および `CREATE INDEX` については、ダウンストリームが TiDB の場合、TiCDC は changefeed レプリケーションのレイテンシーへの影響を最小限に抑えるために、これらの DDL を非同期に実行し、ダウンストリームでの実行完了を待たずに戻ります。詳細については、 [ `ADD INDEX`および`CREATE INDEX` DDLの非同期実行](/ticdc/ticdc-ddl.md#asynchronous-execution-of-add-index-and-create-index-ddls)を参照してください。 -## アップストリーム データとダウンストリーム データが一貫しているかどうかをどのように確認すればよいですか? {#how-should-i-check-whether-the-upstream-and-downstream-data-is-consistent} +## アップストリーム データとダウンストリームデータが一貫しているかどうかをどのように確認すればよいですか? {#how-should-i-check-whether-the-upstream-and-downstream-data-is-consistent} ダウンストリームが TiDB クラスターまたは MySQL インスタンスの場合は、 [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用してデータを比較することをお勧めします。 @@ -504,17 +504,17 @@ UPDATE data_table SET value = 'v3' WHERE id = 1; UPDATE data_table SET value = 'v1' WHERE id = 2; ``` -2 番目の`UPDATE`ステートメントを実行するときにダウンストリーム テーブルにまだ`v1`含まれている場合、 `value`列の一意キー制約に違反し、 `CDC:ErrMySQLDuplicateEntryCDC`エラーが発生します。 +2 番目の`UPDATE`ステートメントを実行するときにダウンストリームテーブルにまだ`v1`含まれている場合、 `value`列の一意キー制約に違反し、 `CDC:ErrMySQLDuplicateEntryCDC`エラーが発生します。 -`CDC:ErrMySQLDuplicateEntryCDC`エラーが頻繁に発生する場合は、 [`sink-uri`](/ticdc/ticdc-sink-to-mysql.md#configure-sink-uri-for-mysql-or-tidb)構成で`safe-mode=true`パラメータを設定することで TiCDC セーフ モードを有効にすることができます。 +`CDC:ErrMySQLDuplicateEntryCDC`エラーが頻繁に発生する場合は、 [`sink-uri`](/ticdc/ticdc-sink-to-mysql.md#configure-sink-uri-for-mysql-or-tidb)構成で`safe-mode=true`パラメータを設定することで TiCDC セーフモードを有効にすることができます。 ``` mysql://user:password@host:port/?safe-mode=true ``` -セーフ モードでは、TiCDC は`UPDATE`操作を`DELETE + REPLACE INTO`に分割して実行し、一意のキーの競合エラーを回避します。 +セーフモードでは、TiCDC は`UPDATE`操作を`DELETE + REPLACE INTO`に分割して実行し、一意のキーの競合エラーを回避します。 -## Kafka への TiCDC レプリケーション タスクが`broken pipe`エラーで頻繁に失敗するのはなぜですか? {#why-do-ticdc-replication-tasks-to-kafka-often-fail-with-broken-pipe-errors} +## Kafka への TiCDC レプリケーションタスクが`broken pipe`エラーで頻繁に失敗するのはなぜですか? {#why-do-ticdc-replication-tasks-to-kafka-often-fail-with-broken-pipe-errors} TiCDCはSaramaクライアントを使用してKafkaにデータを複製します。データの順序が乱れるのを防ぐため、TiCDCはSaramaの自動再試行メカニズムを無効化します（再試行回数を0に設定）。その結果、TiCDCとKafka間の接続が一定時間アイドル状態になった後にKafkaによって切断された場合、TiCDCからの後続の書き込みは`write: broken pipe`エラーをトリガーし、レプリケーションタスクが失敗します。 diff --git a/ticdc/ticdc-filter.md b/ticdc/ticdc-filter.md index 3db84975bd43e..3b85215dbbe85 100644 --- a/ticdc/ticdc-filter.md +++ b/ticdc/ticdc-filter.md @@ -1,6 +1,6 @@ --- title: Changefeed Log Filters -summary: TiCDC のテーブル フィルターとイベント フィルターの使用方法を学習します。 +summary: TiCDC のテーブルフィルターとイベントフィルターの使用方法を学習します。 --- # 変更フィードログフィルター {#changefeed-log-filters} @@ -9,7 +9,7 @@ TiCDCは、テーブルとイベントによるデータのフィルタリング ## テーブルフィルター {#table-filter} -テーブル フィルターは、次の構成を指定して、特定のデータベースとテーブルを保持または除外できる機能です。 +テーブルフィルターは、次の構成を指定して、特定のデータベースとテーブルを保持または除外できる機能です。 ```toml [filter] @@ -36,7 +36,7 @@ rules = ['*.*', '!test.*'] TiCDC v6.2.0以降では、イベントフィルターがサポートされています。イベントフィルタールールを設定することで、指定した条件を満たすDMLイベントとDDLイベントを除外できます。 -以下はイベント フィルタ ルールの例です。 +以下はイベントフィルタルールの例です。 ```toml [filter] diff --git a/ticdc/ticdc-glossary.md b/ticdc/ticdc-glossary.md index c2f00df5be78a..face5539300f0 100644 --- a/ticdc/ticdc-glossary.md +++ b/ticdc/ticdc-glossary.md @@ -17,11 +17,11 @@ TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)を ### 変更されたデータ {#changed-data} -DML によるデータ変更と DDL によるテーブル スキーマの変更を含む、上流の TiDB クラスターから TiCDC に書き込まれるデータ。 +DML によるデータ変更と DDL によるテーブルスキーマの変更を含む、上流の TiDB クラスターから TiCDC に書き込まれるデータ。 ### チェンジフィード {#changefeed} -TiCDC の増分レプリケーション タスク。TiDB クラスター内の複数のテーブルのデータ変更ログを指定されたダウンストリームに出力します。 +TiCDC の増分レプリケーションタスク。TiDB クラスター内の複数のテーブルのデータ変更ログを指定されたダウンストリームに出力します。 ## お {#o} diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 1975eebce200c..8de0ddfc8a9c1 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -9,7 +9,7 @@ summary: TiCDC 変更フィードを管理する方法を学びます。 ## レプリケーションタスクを作成する {#create-a-replication-task} -レプリケーション タスクを作成するには、次のコマンドを実行します。 +レプリケーションタスクを作成するには、次のコマンドを実行します。 ```shell cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://root:123456@127.0.0.1:3306/" --changefeed-id="simple-replication-task" @@ -23,7 +23,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl ## レプリケーションタスクリストをクエリする {#query-the-replication-task-list} -レプリケーション タスク リストを照会するには、次のコマンドを実行します。 +レプリケーションタスクリストを照会するには、次のコマンドを実行します。 ```shell cdc cli changefeed list --server=http://10.0.10.25:8300 @@ -42,10 +42,10 @@ cdc cli changefeed list --server=http://10.0.10.25:8300 ``` - `checkpoint` 、TiCDC がこの時点より前にデータをダウンストリームにすでに複製していることを示します。 -- `state`レプリケーション タスクの状態を示します。 - - `normal` : レプリケーション タスクは正常に実行されます。 - - `stopped` : レプリケーション タスクが停止されています (手動で一時停止されています)。 - - `error` : レプリケーション タスクが停止しました (エラーにより)。 +- `state`レプリケーションタスクの状態を示します。 + - `normal` : レプリケーションタスクは正常に実行されます。 + - `stopped` : レプリケーションタスクが停止されています (手動で一時停止されています)。 + - `error` : レプリケーションタスクが停止しました (エラーにより)。 - `removed` : レプリケーションタスクは削除されています。この状態のタスクは、 `--all`オプションを指定した場合のみ表示されます。このオプションを指定せずにこれらのタスクを表示するには、 `changefeed query`コマンドを実行してください。 - `finished` : レプリケーションタスクが完了しました（データは`target-ts`にレプリケートされています）。この状態のタスクは、 `--all`オプションを指定した場合のみ表示されます。このオプションを指定せずにこれらのタスクを表示するには、 `changefeed query`コマンドを実行してください。 @@ -146,11 +146,11 @@ cdc cli changefeed query --server=http://10.0.10.25:8300 --changefeed-id=simple- - `1` : タスクは一時停止されています。タスクが一時停止されると、複製されたすべての`processor`秒が終了します。タスクの設定とレプリケーション状態は保持されるため、 `checkpoint-ts`からタスクを再開できます。 - `2` : タスクが再開されます。レプリケーションタスクは`checkpoint-ts`から再開されます。 - `3` : タスクは削除されます。タスクが削除されると、すべての`processor`が終了し、レプリケーションタスクの設定情報はクリアされます。レプリケーションステータスのみが保持され、後続のクエリに使用されます。 -- `task-status`クエリされた変更フィード内の各レプリケーション サブタスクの状態を示します。 +- `task-status`クエリされた変更フィード内の各レプリケーションサブタスクの状態を示します。 ## レプリケーションタスクを一時停止する {#pause-a-replication-task} -レプリケーション タスクを一時停止するには、次のコマンドを実行します。 +レプリケーションタスクを一時停止するには、次のコマンドを実行します。 ```shell cdc cli changefeed pause --server=http://10.0.10.25:8300 --changefeed-id simple-replication-task @@ -158,17 +158,17 @@ cdc cli changefeed pause --server=http://10.0.10.25:8300 --changefeed-id simple- 上記のコマンドでは、次のようになります。 -- `--changefeed-id=uuid` 、一時停止するレプリケーション タスクに対応する変更フィード ID を表します。 +- `--changefeed-id=uuid` 、一時停止するレプリケーションタスクに対応する変更フィード ID を表します。 ## レプリケーションタスクを再開する {#resume-a-replication-task} -一時停止されたレプリケーション タスクを再開するには、次のコマンドを実行します。 +一時停止されたレプリケーションタスクを再開するには、次のコマンドを実行します。 ```shell cdc cli changefeed resume --server=http://10.0.10.25:8300 --changefeed-id simple-replication-task ``` -- `--changefeed-id=uuid` 、再開するレプリケーション タスクに対応する変更フィード ID を表します。 +- `--changefeed-id=uuid` 、再開するレプリケーションタスクに対応する変更フィード ID を表します。 - `--overwrite-checkpoint-ts` : v6.2.0以降では、レプリケーションタスクを再開する開始TSOを指定できます。TiCDCは指定されたTSOからデータのプルを開始します。引数には`now`または特定のTSO（434873584621453313など）を指定できます。指定するTSOは、GCセーフポイントからCurrentTSOまでの範囲内である必要があります。この引数を指定しない場合、TiCDCはデフォルトで現在の`checkpoint-ts`からデータを複製します。現在のTSO値`checkpoint-ts`を確認するには、 `cdc cli changefeed list`コマンドを使用します。 - `--no-confirm` : レプリケーションが再開されたときに、関連情報を確認する必要はありません。デフォルトは`false`です。 @@ -179,7 +179,7 @@ cdc cli changefeed resume --server=http://10.0.10.25:8300 --changefeed-id simple ## レプリケーションタスクを削除する {#remove-a-replication-task} -レプリケーション タスクを削除するには、次のコマンドを実行します。 +レプリケーションタスクを削除するには、次のコマンドを実行します。 ```shell cdc cli changefeed remove --server=http://10.0.10.25:8300 --changefeed-id simple-replication-task @@ -187,7 +187,7 @@ cdc cli changefeed remove --server=http://10.0.10.25:8300 --changefeed-id simple 上記のコマンドでは、次のようになります。 -- `--changefeed-id=uuid`を削除するレプリケーション タスクに対応する変更フィードの ID を表します。 +- `--changefeed-id=uuid`を削除するレプリケーションタスクに対応する変更フィードの ID を表します。 ## タスク構成の更新 {#update-task-configuration} @@ -223,7 +223,7 @@ cdc cli changefeed resume -c test-cf --server=http://10.0.10.25:8300 ] ``` -- 特定のレプリケーション タスクのステータスに対応する特定の変更フィードに対してクエリを実行します。 +- 特定のレプリケーションタスクのステータスに対応する特定の変更フィードに対してクエリを実行します。 ```shell cdc cli processor query --server=http://10.0.10.25:8300 --changefeed-id=simple-replication-task --capture-id=b293999a-4168-4988-a4f4-35d9589b226b diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index c7ec49dffff31..7117c33b1b14c 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -36,7 +36,7 @@ API を使用して、TiCDC クラスターで次のメンテナンス操作を ## APIエラーメッセージテンプレート {#api-error-message-template} -API リクエストの送信後にエラーが発生した場合、返されるエラー メッセージは次の形式になります。 +API リクエストの送信後にエラーが発生した場合、返されるエラーメッセージは次の形式になります。 ```json { @@ -45,7 +45,7 @@ API リクエストの送信後にエラーが発生した場合、返される } ``` -上記の JSON 出力では、 `error_msg`エラー メッセージを示し、 `error_code`対応するエラー コードを示します。 +上記の JSON 出力では、 `error_msg`エラーメッセージを示し、 `error_code`対応するエラーコードを示します。 ## APIリストインターフェースの戻り形式 {#return-format-of-the-api-list-interface} @@ -130,7 +130,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health {} ``` -クラスターが正常でない場合、応答はエラー メッセージを含む JSON オブジェクトになります。 +クラスターが正常でない場合、応答はエラーメッセージを含む JSON オブジェクトになります。 ## レプリケーションタスクを作成する {#create-a-replication-task} @@ -376,7 +376,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health ### 例 {#example} -次のリクエストは、ID が`test5`で`blackhome://` `sink_uri`あるレプリケーション タスクを作成します。 +次のリクエストは、ID が`test5`で`blackhome://` `sink_uri`あるレプリケーションタスクを作成します。 ```shell curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/changefeeds -d '{"changefeed_id":"test5","sink_uri":"blackhole://"}' @@ -500,18 +500,18 @@ curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/ch | :---------------- | :---------------------------------------------------------------------------------- | | `admin_job_type` | `INTEGER`タイプ。管理ジョブのタイプ。 | | `checkpoint_time` | `STRING`タイプ。レプリケーションタスクの現在のチェックポイントのフォーマットされた時刻。 | -| `checkpoint_ts` | `STRING`タイプ。レプリケーション タスクの現在のチェックポイントの TSO。 | +| `checkpoint_ts` | `STRING`タイプ。レプリケーションタスクの現在のチェックポイントの TSO。 | | `config` | レプリケーションタスクの設定。構造と意味は、レプリケーションタスク作成時の`replica_config`の設定と同じです。 | | `create_time` | `STRING`型。レプリケーションタスクが作成された時刻。 | | `creator_version` | `STRING`タイプ。レプリケーションタスク作成時の TiCDC バージョン。 | -| `error` | レプリケーション タスク エラー。 | -| `id` | `STRING`タイプ。レプリケーション タスク ID。 | -| `resolved_ts` | `UINT64`タイプ。レプリケーション タスクは ts を解決しました。 | -| `sink_uri` | `STRING`タイプ。レプリケーション タスク シンクの URI。 | +| `error` | レプリケーションタスク エラー。 | +| `id` | `STRING`タイプ。レプリケーションタスク ID。 | +| `resolved_ts` | `UINT64`タイプ。レプリケーションタスクは ts を解決しました。 | +| `sink_uri` | `STRING`タイプ。レプリケーションタスク シンクの URI。 | | `start_ts` | `UINT64`タイプ。レプリケーションタスクが開始されます。 | | `state` | `STRING`型。レプリケーションタスクのステータス。`normal` 、 `stopped` 、 `error` 、 `failed` 、または`finished`になります。 | | `target_ts` | `UINT64`タイプ。レプリケーションタスクのターゲット ts。 | -| `task_status` | レプリケーション タスクのディスパッチの詳細なステータス。 | +| `task_status` | レプリケーションタスクのディスパッチの詳細なステータス。 | `task_status`パラメータは次のように記述されます。 @@ -542,11 +542,11 @@ curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/ch | パラメータ名 | 説明 | | :-------------- | :---------------------------------- | -| `changefeed_id` | 削除するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 削除するレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクを削除します。 +次のリクエストは、ID `test1`のレプリケーションタスクを削除します。 ```shell curl -X DELETE http://127.0.0.1:8300/api/v2/changefeeds/test1 @@ -570,7 +570,7 @@ changefeed 設定を変更するには、 `pause the replication task -> modify | パラメータ名 | 説明 | | :-------------- | :---------------------------------- | -| `changefeed_id` | 更新するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 更新するレプリケーションタスク (changefeed) の ID。 | #### リクエスト本体のパラメータ {#parameters-for-the-request-body} @@ -672,7 +672,7 @@ changefeed 設定を変更するには、 `pause the replication task -> modify ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクの`target_ts` `32`に更新します。 +次のリクエストは、ID `test1`のレプリケーションタスクの`target_ts` `32`に更新します。 ```shell curl -X PUT -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/changefeeds/test1 -d '{"target_ts":32}' @@ -698,11 +698,11 @@ curl -X PUT -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/cha `state`の値のオプションは`all` 、 `normal` 、 `stopped` 、 `error` 、 `failed` 、 `finished`です。 -このパラメータを指定しない場合は、 `normal` 、 `stopped` 、または`failed`状態のレプリケーション タスクの基本情報がデフォルトで返されます。 +このパラメータを指定しない場合は、 `normal` 、 `stopped` 、または`failed`状態のレプリケーションタスクの基本情報がデフォルトで返されます。 ### 例 {#example} -次のリクエストは、状態`normal`にあるすべてのレプリケーション タスクの基本情報を照会します。 +次のリクエストは、状態`normal`にあるすべてのレプリケーションタスクの基本情報を照会します。 ```shell curl -X GET http://127.0.0.1:8300/api/v2/changefeeds?state=normal @@ -732,11 +732,11 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds?state=normal 上記の返された結果のパラメータは次のように説明されます。 -- `id` : レプリケーション タスクの ID。 -- `state` : レプリケーション タスクの現在の[州](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer) 。 -- `checkpoint_tso` : レプリケーション タスクの現在のチェックポイントの TSO。 -- `checkpoint_time` : レプリケーション タスクの現在のチェックポイントのフォーマットされた時刻。 -- `error` : レプリケーション タスクのエラー情報。 +- `id` : レプリケーションタスクの ID。 +- `state` : レプリケーションタスクの現在の[州](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer) 。 +- `checkpoint_tso` : レプリケーションタスクの現在のチェックポイントの TSO。 +- `checkpoint_time` : レプリケーションタスクの現在のチェックポイントのフォーマットされた時刻。 +- `error` : レプリケーションタスクのエラー情報。 ## 特定のレプリケーションタスクをクエリする {#query-a-specific-replication-task} @@ -752,11 +752,11 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds?state=normal | パラメータ名 | 説明 | | :-------------- | :----------------------------------- | -| `changefeed_id` | クエリするレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | クエリするレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクの詳細情報を照会します。 +次のリクエストは、ID `test1`のレプリケーションタスクの詳細情報を照会します。 ```shell curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1 @@ -778,11 +778,11 @@ JSONレスポンスボディの意味は[レプリケーションタスクを作 | パラメータ名 | 説明 | | :-------------- | :----------------------------------- | -| `changefeed_id` | クエリするレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | クエリするレプリケーションタスク (changefeed) の ID。 | ### 例 {#examples} -次のリクエストは、ID `test1`のレプリケーション タスクの同期ステータスを照会します。 +次のリクエストは、ID `test1`のレプリケーションタスクの同期ステータスを照会します。 ```shell curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1/synced @@ -867,11 +867,11 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1/synced | パラメータ名 | 説明 | | :-------------- | :------------------------------------ | -| `changefeed_id` | 一時停止するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 一時停止するレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクを一時停止します。 +次のリクエストは、ID `test1`のレプリケーションタスクを一時停止します。 ```shell curl -X POST http://127.0.0.1:8300/api/v2/changefeeds/test1/pause @@ -893,7 +893,7 @@ curl -X POST http://127.0.0.1:8300/api/v2/changefeeds/test1/pause | パラメータ名 | 説明 | | :-------------- | :---------------------------------- | -| `changefeed_id` | 再開するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 再開するレプリケーションタスク (changefeed) の ID。 | #### リクエスト本体のパラメータ {#parameters-for-the-request-body} @@ -905,11 +905,11 @@ curl -X POST http://127.0.0.1:8300/api/v2/changefeeds/test1/pause | パラメータ名 | 説明 | | :------------------------ | :-------------------------------------------------------------------- | -| `overwrite_checkpoint_ts` | `UINT64`タイプ。レプリケーション タスク (changefeed) を再開するときにチェックポイント TSO を再割り当てします。 | +| `overwrite_checkpoint_ts` | `UINT64`タイプ。レプリケーションタスク (changefeed) を再開するときにチェックポイント TSO を再割り当てします。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクを再開します。 +次のリクエストは、ID `test1`のレプリケーションタスクを再開します。 ```shell curl -X POST http://127.0.0.1:8300/api/v2/changefeeds/test1/resume -d '{}' @@ -970,8 +970,8 @@ curl -X GET http://127.0.0.1:8300/api/v2/processors | パラメータ名 | 説明 | | :-------------- | :----------------------------- | -| `changefeed_id` | クエリするレプリケーション サブタスクの変更フィード ID。 | -| `capture_id` | クエリするレプリケーション サブタスクのキャプチャ ID。 | +| `changefeed_id` | クエリするレプリケーションサブタスクの変更フィード ID。 | +| `capture_id` | クエリするレプリケーションサブタスクのキャプチャ ID。 | ### 例 {#example} @@ -1058,7 +1058,7 @@ curl -X POST http://127.0.0.1:8300/api/v2/owner/resign | パラメータ名 | 説明 | | :---------- | :---------- | -| `log_level` | 設定するログ レベル。 | +| `log_level` | 設定するログレベル。 | `log_level` 、「debug」、「info」、「warn」、「error」、「dpanic」、「panic」、「fatal」の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 diff --git a/ticdc/ticdc-open-api.md b/ticdc/ticdc-open-api.md index 1be51723adf2c..daa5a7c6c8481 100644 --- a/ticdc/ticdc-open-api.md +++ b/ticdc/ticdc-open-api.md @@ -47,7 +47,7 @@ After sending an API request, if an error occurs, the returned error message is } ``` -上記の JSON 出力では、 `error_msg`エラー メッセージを示し、 `error_code`対応するエラー コードを示します。 +上記の JSON 出力では、 `error_msg`エラーメッセージを示し、 `error_code`対応するエラーコードを示します。 ## TiCDCノードのステータス情報を取得する {#get-the-status-information-of-a-ticdc-node} @@ -111,7 +111,7 @@ curl -X GET http://127.0.0.1:8300/api/v1/health #### リクエスト本体のパラメータ {#parameters-for-the-request-body} -| パラメータ名 | 説明 | | :------------------------ | :---------------------- ------------------------------- | | `changefeed_id` | `STRING` type。レプリケーション タスクの ID。(オプション) | | `start_ts` | `UINT64` type。changefeed の開始 TSO を指定します。(オプション) | | `target_ts` | `UINT64` type。changefeed のターゲット TSO を指定します。(オプション) | | **`sink_uri`** | `STRING` type。レプリケーション タスクのダウンストリーム アドレス。(**必須**) | | `force_replicate` | `BOOLEAN` type。一意インデックスのないテーブルを強制的にレプリケートするかどうかを決定します。(オプション) | | `ignore_ineligible_table` | `BOOLEAN` type。レプリケートできないテーブルを無視するかどうかを決定します。(オプション) | | `filter_rules` | `STRING` type 配列。テーブル スキーマのフィルタリングのルール。(オプション) | | `ignore_txn_start_ts` | `UINT64` type 配列。指定された start_ts のトランザクションを無視します。(オプション) | | `mounter_worker_num` | `INT` type。マウンタのスレッド番号。(オプション) | | `sink_config` | シンクの構成パラメータ。(オプション) | +| パラメータ名 | 説明 | | :------------------------ | :---------------------- ------------------------------- | | `changefeed_id` | `STRING` type。レプリケーションタスクの ID。(オプション) | | `start_ts` | `UINT64` type。changefeed の開始 TSO を指定します。(オプション) | | `target_ts` | `UINT64` type。changefeed のターゲット TSO を指定します。(オプション) | | **`sink_uri`** | `STRING` type。レプリケーションタスクのダウンストリーム アドレス。(**必須**) | | `force_replicate` | `BOOLEAN` type。一意インデックスのないテーブルを強制的にレプリケートするかどうかを決定します。(オプション) | | `ignore_ineligible_table` | `BOOLEAN` type。レプリケートできないテーブルを無視するかどうかを決定します。(オプション) | | `filter_rules` | `STRING` type 配列。テーブルスキーマのフィルタリングのルール。(オプション) | | `ignore_txn_start_ts` | `UINT64` type 配列。指定された start_ts のトランザクションを無視します。(オプション) | | `mounter_worker_num` | `INT` type。マウンタのスレッド番号。(オプション) | | `sink_config` | シンクの構成パラメータ。(オプション) | `changefeed_id` `target_ts`意味と形式は、 [`cdc cli`を使用してレプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)ドキュメントに記載されているものと同じです。 `sink_uri` `start_ts`パラメータの詳細については、こちらのドキュメントを参照してください`sink_uri`で証明書パスを指定する際は、対応する証明書が対応する TiCDCサーバーにアップロードされていることを確認してください。 @@ -146,13 +146,13 @@ The configuration parameters of sink are as follows: - `index-value`: uses the name and value of the selected HandleKey column to create the hash value and dispatch events. - `table` : テーブルのスキーマ名とテーブル名を使用してハッシュ値を作成し、イベントをディスパッチします。 -`matcher` : マッチャーの一致構文はフィルター ルール構文と同じです。 +`matcher` : マッチャーの一致構文はフィルタールール構文と同じです。 `protocol` : MQタイプのシンクの場合、メッセージのプロトコル形式を指定できます。現在、 `canal-json` `debezium`プロトコル`open-protocol`サポート`simple`れています`avro` ### 例 {#example} -次のリクエストは、ID が`test5`で`sink_uri`が`blackhole://`のレプリケーション タスクを作成します。 +次のリクエストは、ID が`test5`で`sink_uri`が`blackhole://`のレプリケーションタスクを作成します。 ```shell curl -X POST -H "'Content-type':'application/json'" http://127.0.0.1:8300/api/v1/changefeeds -d '{"changefeed_id":"test5","sink_uri":"blackhole://"}' @@ -174,11 +174,11 @@ curl -X POST -H "'Content-type':'application/json'" http://127.0.0.1:8300/api/v1 | パラメータ名 | 説明 | | :-------------- | :---------------------------------- | -| `changefeed_id` | 削除するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 削除するレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクを削除します。 +次のリクエストは、ID `test1`のレプリケーションタスクを削除します。 ```shell curl -X DELETE http://127.0.0.1:8300/api/v1/changefeeds/test1 @@ -202,19 +202,19 @@ changefeed 設定を変更するには、 `pause the replication task -> modify | パラメータ名 | 説明 | | :-------------- | :---------------------------------- | -| `changefeed_id` | 更新するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 更新するレプリケーションタスク (changefeed) の ID。 | #### リクエスト本体のパラメータ {#parameters-for-the-request-body} 現在、API 経由で変更できるのは次の構成のみです。 -| パラメータ名 | 説明 | | :--------------------- | :-------------------------- --------------------------- | | `target_ts` | `UINT64` type。changefeed のターゲット TSO を指定します。(オプション) | | `sink_uri` | `STRING` type。レプリケーション タスクのダウンストリーム アドレス。(オプション) | | `filter_rules` | `STRING` type 配列。テーブル スキーマ フィルタリングのルール。(オプション) | | `ignore_txn_start_ts` | `UINT64` type 配列。指定された start_ts のトランザクションを無視します。(オプション) | | `mounter_worker_num` | `INT` type。マウント元スレッド番号。(オプション) | | `sink_config` | シンクの構成パラメータ。(オプション) | +| パラメータ名 | 説明 | | :--------------------- | :-------------------------- --------------------------- | | `target_ts` | `UINT64` type。changefeed のターゲット TSO を指定します。(オプション) | | `sink_uri` | `STRING` type。レプリケーションタスクのダウンストリーム アドレス。(オプション) | | `filter_rules` | `STRING` type 配列。テーブルスキーマフィルタリングのルール。(オプション) | | `ignore_txn_start_ts` | `UINT64` type 配列。指定された start_ts のトランザクションを無視します。(オプション) | | `mounter_worker_num` | `INT` type。マウント元スレッド番号。(オプション) | | `sink_config` | シンクの構成パラメータ。(オプション) | 上記のパラメータの意味はセクション[レプリケーションタスクを作成する](#create-a-replication-task)と同じです。詳細については、セクション1を参照してください。 ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクの`mounter_worker_num` `32`に更新します。 +次のリクエストは、ID `test1`のレプリケーションタスクの`mounter_worker_num` `32`に更新します。 ```shell curl -X PUT -H "'Content-type':'application/json'" http://127.0.0.1:8300/api/v1/changefeeds/test1 -d '{"mounter_worker_num":32}' @@ -234,15 +234,15 @@ changefeed 設定を変更するには、 `pause the replication task -> modify #### クエリパラメータ {#query-parameters} -| パラメータ名 | 説明 | | :------ | :----------------------------------------- ----- | | `state` | このパラメータを指定すると、この状態のレプリケーション ステータス情報のみが返されます。(オプション) | +| パラメータ名 | 説明 | | :------ | :----------------------------------------- ----- | | `state` | このパラメータを指定すると、この状態のレプリケーションステータス情報のみが返されます。(オプション) | `state`の値のオプションは`all` 、 `normal` 、 `stopped` 、 `error` 、 `failed` 、 `finished`です。 -このパラメータを指定しない場合は、状態が正常、停止、または失敗であるレプリケーション タスクの基本情報がデフォルトで返されます。 +このパラメータを指定しない場合は、状態が正常、停止、または失敗であるレプリケーションタスクの基本情報がデフォルトで返されます。 ### 例 {#example} -次のリクエストは、状態が`normal`あるすべてのレプリケーション タスクの基本情報を照会します。 +次のリクエストは、状態が`normal`あるすべてのレプリケーションタスクの基本情報を照会します。 ```shell curl -X GET http://127.0.0.1:8300/api/v1/changefeeds?state=normal @@ -269,11 +269,11 @@ curl -X GET http://127.0.0.1:8300/api/v1/changefeeds?state=normal 上記の返された結果のフィールドは次のように説明されます。 -- id: レプリケーション タスクの ID。 -- 状態: レプリケーション タスクの現在の状態[州](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer) 。 -- checkpoint_tso: レプリケーション タスクの現在のチェックポイントの TSO 表現。 -- checkpoint_time: レプリケーション タスクの現在のチェックポイントのフォーマットされた時間表現。 -- error: レプリケーション タスクのエラー情報。 +- id: レプリケーションタスクの ID。 +- 状態: レプリケーションタスクの現在の状態[州](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer) 。 +- checkpoint_tso: レプリケーションタスクの現在のチェックポイントの TSO 表現。 +- checkpoint_time: レプリケーションタスクの現在のチェックポイントのフォーマットされた時間表現。 +- error: レプリケーションタスクのエラー情報。 ## 特定のレプリケーションタスクをクエリする {#query-a-specific-replication-task} @@ -289,11 +289,11 @@ curl -X GET http://127.0.0.1:8300/api/v1/changefeeds?state=normal | パラメータ名 | 説明 | | :-------------- | :----------------------------------- | -| `changefeed_id` | クエリするレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | クエリするレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクの詳細情報を照会します。 +次のリクエストは、ID `test1`のレプリケーションタスクの詳細情報を照会します。 ```shell curl -X GET http://127.0.0.1:8300/api/v1/changefeeds/test1 @@ -340,11 +340,11 @@ curl -X GET http://127.0.0.1:8300/api/v1/changefeeds/test1 | パラメータ名 | 説明 | | :-------------- | :------------------------------------ | -| `changefeed_id` | 一時停止するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 一時停止するレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクを一時停止します。 +次のリクエストは、ID `test1`のレプリケーションタスクを一時停止します。 ```shell curl -X POST http://127.0.0.1:8300/api/v1/changefeeds/test1/pause @@ -366,11 +366,11 @@ curl -X POST http://127.0.0.1:8300/api/v1/changefeeds/test1/pause | パラメータ名 | 説明 | | :-------------- | :---------------------------------- | -| `changefeed_id` | 再開するレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | 再開するレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} -次のリクエストは、ID `test1`のレプリケーション タスクを再開します。 +次のリクエストは、ID `test1`のレプリケーションタスクを再開します。 ```shell curl -X POST http://127.0.0.1:8300/api/v1/changefeeds/test1/resume @@ -415,8 +415,8 @@ curl -X GET http://127.0.0.1:8300/api/v1/processors | パラメータ名 | 説明 | | :-------------- | :----------------------------- | -| `changefeed_id` | クエリするレプリケーション サブタスクの変更フィード ID。 | -| `capture_id` | クエリするレプリケーション サブタスクのキャプチャ ID。 | +| `changefeed_id` | クエリするレプリケーションサブタスクの変更フィード ID。 | +| `capture_id` | クエリするレプリケーションサブタスクのキャプチャ ID。 | ### 例 {#example} @@ -494,7 +494,7 @@ curl -X POST http://127.0.0.1:8300/api/v1/owner/resign | パラメータ名 | 説明 | | :-------------- | :-------------------------------------- | -| `changefeed_id` | スケジュールするレプリケーション タスク (changefeed) の ID。 | +| `changefeed_id` | スケジュールするレプリケーションタスク (changefeed) の ID。 | ### 例 {#example} @@ -554,7 +554,7 @@ curl -X POST -H "'Content-type':'application/json'" http://127.0.0.1:8300/api/v1 | パラメータ名 | 説明 | | :---------- | :---------- | -| `log_level` | 設定するログ レベル。 | +| `log_level` | 設定するログレベル。 | `log_level` 、「debug」、「info」、「warn」、「error」、「dpanic」、「panic」、「fatal」の[zapが提供するログレベル](https://godoc.org/go.uber.org/zap#UnmarshalText)サポートします。 diff --git a/ticdc/ticdc-open-protocol.md b/ticdc/ticdc-open-protocol.md index 0c7f43c7babf8..ccec1b8e6ee5a 100644 --- a/ticdc/ticdc-open-protocol.md +++ b/ticdc/ticdc-open-protocol.md @@ -1,6 +1,6 @@ --- title: TiCDC Open Protocol -summary: TiCDC オープン プロトコルの概念とその使用方法を学びます。 +summary: TiCDC オープンプロトコルの概念とその使用方法を学びます。 --- # TiCDCオープンプロトコル {#ticdc-open-protocol} @@ -15,7 +15,7 @@ TiCDCオープンプロトコルは、データ変更イベントを下流に複 ## 制限 {#restrictions} -- ほとんどの場合、バージョンの行変更イベントは 1 回だけ送信されますが、ノード障害やネットワーク パーティションなどの特別な状況では、同じバージョンの行変更イベントが複数回送信されることがあります。 +- ほとんどの場合、バージョンの行変更イベントは 1 回だけ送信されますが、ノード障害やネットワークパーティションなどの特別な状況では、同じバージョンの行変更イベントが複数回送信されることがあります。 - 同じテーブルで、最初に送信された各バージョンの行変更イベントは、イベント ストリーム内のタイムスタンプ (TS) の順に増加します。 - 解決済みイベントは、各MQパーティションに定期的にブロードキャストされます。解決済みイベントとは、解決済みイベントTSよりも前のTSを持つイベントがダウンストリームに送信されたことを意味します。 - DDL イベントは各 MQ パーティションにブロードキャストされます。 @@ -367,7 +367,7 @@ COMMIT; 85 == 0b_101_0101 == NullableFlag | UniqueKeyFlag | GeneratedColumnFlag | BinaryFlag -列の値が`46`の場合、その列は複合インデックス列、主キー列、生成列、およびハンドル キー列になります。 +列の値が`46`の場合、その列は複合インデックス列、主キー列、生成列、およびハンドルキー列になります。 46 == 0b_010_1110 == MultipleKeyFlag | PrimaryKeyFlag | GeneratedColumnFlag | HandleKeyFlag diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 278f8ee50fec3..0e3c01c26e093 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -5,7 +5,7 @@ summary: TiCDCとは何か、TiCDCが提供する機能、そしてTiCDCのイ # TiCDCの概要 {#ticdc-overview} -[TiCDC](https://github.com/pingcap/tiflow/tree/release-8.5/cdc)は、TiDB から増分データをレプリケートするために使用されるツールです。具体的には、TiCDC は TiKV 変更ログを取得し、キャプチャしたデータを並べ替えて、行ベースの増分データをダウンストリーム データベースにエクスポートします。データ レプリケーション機能の詳細については、 [TiCDCのデータレプリケーション機能](/ticdc/ticdc-data-replication-capabilities.md)を参照してください。 +[TiCDC](https://github.com/pingcap/tiflow/tree/release-8.5/cdc)は、TiDB から増分データをレプリケートするために使用されるツールです。具体的には、TiCDC は TiKV 変更ログを取得し、キャプチャしたデータを並べ替えて、行ベースの増分データをダウンストリームデータベースにエクスポートします。データレプリケーション機能の詳細については、 [TiCDCのデータレプリケーション機能](/ticdc/ticdc-data-replication-capabilities.md)を参照してください。 ## 使用シナリオ {#usage-scenarios} @@ -72,7 +72,7 @@ TiCDCのアーキテクチャを次の図に示す。 - TiCDC: TiCDCプロセスが実行されるTiCDCノード。各ノードではTiCDCプロセスが実行されます。各プロセスは、TiKVノード内の1つ以上のテーブルからデータ変更を取得し、シンクコンポーネントを介して下流システムにその変更を複製します。 - PD：TiDBクラスタのスケジューリングモジュール。このモジュールはクラスタデータのスケジューリングを担当し、通常は3つのPDノードで構成されます。PDはetcdクラスタを介して高可用性を提供します。etcdクラスタでは、TiCDCはノードの状態情報や変更フィードの設定などのメタデータを保存します。 -実装では、TiCDC の[新しいアーキテクチャ](/ticdc/ticdc-architecture.md)と[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)両方が、同じ増分データ レプリケーション モデルに基づいて構築されます。クラシックアーキテクチャと比較して、新しいアーキテクチャはタスク スケジューリングとレプリケーション メカニズムをリファクタリングして最適化し、リソース コストを削減しながら、リアルタイム データ レプリケーションのパフォーマンス、スケーラビリティ、安定性を大幅に向上させます。 +実装では、TiCDC の[新しいアーキテクチャ](/ticdc/ticdc-architecture.md)と[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)両方が、同じ増分データレプリケーション モデルに基づいて構築されます。クラシックアーキテクチャと比較して、新しいアーキテクチャはタスクスケジューリングとレプリケーション メカニズムをリファクタリングして最適化し、リソース コストを削減しながら、リアルタイム データレプリケーションのパフォーマンス、スケーラビリティ、安定性を大幅に向上させます。 アーキテクチャ図に示すように、TiCDCはTiDB、MySQL、Kafka、およびストレージサービスへのデータ複製をサポートしています。 @@ -160,7 +160,7 @@ WHERE `A` = 1 OR `A` = 2; - RawKVのみを使用するTiKVクラスター。 - TiDB の[`CREATE SEQUENCE` DDL操作](/sql-statements/sql-statement-create-sequence.md)と[`SEQUENCE`関数](/sql-statements/sql-statement-create-sequence.md#sequence-function)上流の TiDB が`SEQUENCE`を使用している場合、TiCDC は上流で実行された`SEQUENCE` DDL 操作/関数を無視します。ただし、 `SEQUENCE`関数を使用した DML 操作は正しく複製できます。 - 現在、TiCDC によってレプリケートされているテーブルおよびデータベースへの[TiDB Lightning物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用したデータのインポートはサポートされていません。詳細については、 [TiDB Lightningの物理インポートモードとTiCDCの互換性に関する制限事項は何ですか？](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 -- v8.2.0 より前では、 BR はTiCDC レプリケーション タスクを使用するクラスター[データの復元](/br/backup-and-restore-overview.md)サポートしていません。詳細については、 [BR （バックアップ＆リストア）とTiCDCの互換性に関する制限事項は何ですか？](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-br-and-ticdc)を参照してください。 +- v8.2.0 より前では、 BR はTiCDC レプリケーションタスクを使用するクラスター[データの復元](/br/backup-and-restore-overview.md)サポートしていません。詳細については、 [BR （バックアップ＆リストア）とTiCDCの互換性に関する制限事項は何ですか？](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-br-and-ticdc)を参照してください。 - バージョン8.2.0以降、 BRはTiCDCのデータ復元に関する制限を緩和しました。復元対象データの`BackupTS` （バックアップ時刻）がchangefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) （現在のレプリケーションの進行状況を示すタイムスタンプ）よりも前であれば、 BRは正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオにおいて、 BRはTiCDCレプリケーションタスクを持つクラスタのデータ復元をサポートしていると考えられます。 TiCDCは、アップストリームにおける大規模トランザクションを含むシナリオを部分的にのみサポートしています。詳細については、 [TiCDCに関するFAQ](/ticdc/ticdc-faq.md#does-ticdc-support-replicating-large-transactions-is-there-any-risk)を参照してください。FAQでは、TiCDCが大規模トランザクションのレプリケーションをサポートしているかどうか、および関連するリスクについて詳しく説明されています。 diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index a53eb5cefc2af..fc839efdcb4bf 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -70,7 +70,7 @@ DML: 他の： - `WATERMARK` : 上流 TiDB クラスターの TSO（64 ビットタイムスタンプ）を含み、テーブルレプリケーションの進行状況を示します。ウォーターマークより前のすべてのイベントは下流に送信されています。 -- `BOOTSTRAP` : ダウンストリームのテーブル スキーマを構築するために使用されるテーブルのスキーマ情報が含まれます。 +- `BOOTSTRAP` : ダウンストリームのテーブルスキーマを構築するために使用されるテーブルのスキーマ情報が含まれます。 ## メッセージ形式 {#message-format} @@ -232,7 +232,7 @@ TiCDC は、DDL イベントを次の JSON 形式でエンコードします。 | フィールド名 | 型 | 説明 | | ---------------- | --- | ----------------------------------------------------------------------------------------------------- | | `version` | number | プロトコルのバージョン番号。現在は`1`です。 | -| `type` | string | DDL イベント タイプ ( `CREATE` 、 `RENAME` 、 `CINDEX` 、 `DINDEX` 、 `ERASE` 、 `TRUNCATE` 、 `ALTER` 、 `QUERY` 。 | +| `type` | string | DDL イベントタイプ ( `CREATE` 、 `RENAME` 、 `CINDEX` 、 `DINDEX` 、 `ERASE` 、 `TRUNCATE` 、 `ALTER` 、 `QUERY` 。 | | `sql` | string | DDL ステートメント。 | | `commitTs` | number | DDL ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | @@ -272,10 +272,10 @@ TiCDC は`INSERT`イベントを次の JSON 形式でエンコードします。 | `database` | string | データベースの名前。 | | `table` | string | テーブルの名前。 | | `tableID` | number | テーブルの ID。 | -| `type` | string | DML イベント タイプ`INSERT` 、 `UPDATE` 、 `DELETE`を含む)。 | +| `type` | string | DML イベントタイプ`INSERT` 、 `UPDATE` 、 `DELETE`を含む)。 | | `commitTs` | number | DML ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | -| `schemaVersion` | number | DML メッセージがエンコードされるときのテーブルのスキーマ バージョン番号。 | +| `schemaVersion` | number | DML メッセージがエンコードされるときのテーブルのスキーマバージョン番号。 | | `data` | object | 挿入されたデータ。フィールド名は列名、フィールド値は列値です。 | `INSERT`イベントには`data`フィールドが含まれ、 `old`フィールドは含まれません。 @@ -317,10 +317,10 @@ TiCDC は`UPDATE`イベントを次の JSON 形式でエンコードします。 | `database` | string | データベースの名前。 | | `table` | string | テーブルの名前。 | | `tableID` | number | テーブルの ID。 | -| `type` | string | DML イベント タイプ`INSERT` 、 `UPDATE` 、 `DELETE`を含む)。 | +| `type` | string | DML イベントタイプ`INSERT` 、 `UPDATE` 、 `DELETE`を含む)。 | | `commitTs` | number | DML ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | -| `schemaVersion` | number | DML メッセージがエンコードされるときのテーブルのスキーマ バージョン番号。 | +| `schemaVersion` | number | DML メッセージがエンコードされるときのテーブルのスキーマバージョン番号。 | | `data` | object | 更新後のデータ。フィールド名は列名、フィールド値は列値です。 | | `old` | object | 更新前のデータ。フィールド名は列名、フィールド値は列値です。 | @@ -357,10 +357,10 @@ TiCDC は`DELETE`イベントを次の JSON 形式でエンコードします。 | `database` | string | データベースの名前。 | | `table` | string | テーブルの名前。 | | `tableID` | number | テーブルの ID。 | -| `type` | string | DML イベント タイプ`INSERT` 、 `UPDATE` 、 `DELETE`を含む)。 | +| `type` | string | DML イベントタイプ`INSERT` 、 `UPDATE` 、 `DELETE`を含む)。 | | `commitTs` | number | DML ステートメントの実行がアップストリームで完了したときのコミット タイムスタンプ。 | | `buildTs` | number | TiCDC 内でメッセージが正常にエンコードされたときの UNIX タイムスタンプ。 | -| `schemaVersion` | number | DML メッセージがエンコードされるときのテーブルのスキーマ バージョン番号。 | +| `schemaVersion` | number | DML メッセージがエンコードされるときのテーブルのスキーマバージョン番号。 | | `old` | object | 削除されたデータ。フィールド名は列名、フィールド値は列値です。 | `DELETE`イベントには`old`フィールドが含まれ、 `data`フィールドは含まれません。 @@ -493,7 +493,7 @@ TiCDC は`BOOTSTRAP`イベントを次の JSON 形式でエンコードします ### BOOTSTRAP {#bootstrap} - 生成時間: - - 新しい変更フィードを作成した後、テーブルの最初の DML イベントが送信される前に、TiCDC はテーブル スキーマを構築するために`BOOTSTRAP`イベントをダウンストリームに送信します。 + - 新しい変更フィードを作成した後、テーブルの最初の DML イベントが送信される前に、TiCDC はテーブルスキーマを構築するために`BOOTSTRAP`イベントをダウンストリームに送信します。 - さらに、TiCDCは、新しく参加したコンシューマーがテーブルスキーマを構築できるように、定期的にイベントを`BOOTSTRAP`送信します。デフォルトの送信間隔は120秒または10000メッセージごとです。送信間隔は、 `sink`設定でパラメータ`send-bootstrap-interval-in-sec`と`send-bootstrap-in-msg-count`設定することで調整できます。 - テーブルが30分以内に新しいDMLメッセージを受信しない場合、そのテーブルは非アクティブとみなされます。TiCDCは、新しいDMLイベントを受信するまで、そのテーブルへの`BOOTSTRAP`の送信を停止します。 - 送信先: デフォルトでは、TiCDC は対応するトピックのすべてのパーティションに`BOOTSTRAP`イベントを送信します。シンク設定の`send-bootstrap-to-all-partition`パラメータを設定することで、送信戦略を調整できます。 @@ -504,7 +504,7 @@ TiCDC SimpleプロトコルはDMLメッセージの送信時にテーブルの 以下では、ダウンストリームがDDLまたはBOOTSTRAPメッセージに基づいてDMLメッセージをどのように処理するかについて説明します。これまでの説明から、以下の情報が判明しています。 -- 各 DML メッセージには、DML メッセージに対応するテーブルのスキーマ バージョン番号をマークするための`schemaVersion`フィールドが含まれています。 +- 各 DML メッセージには、DML メッセージに対応するテーブルのスキーマバージョン番号をマークするための`schemaVersion`フィールドが含まれています。 - 各 DDL メッセージには、DDL イベントの前後のテーブルのスキーマ情報をマークするための`tableSchema`フィールドと`preTableSchema`フィールドが含まれています。 - 各 BOOTSTRAP メッセージには、BOOTSTRAP メッセージに対応するテーブルのスキーマ情報をマークするための`tableSchema`フィールドが含まれています。 @@ -601,15 +601,15 @@ TableSchemaは、テーブル名、テーブルID、テーブルバージョン | `schema` | string | データベースの名前。 | | `table` | string | テーブルの名前。 | | `tableID` | number | テーブルの ID。 | -| `version` | number | テーブルのスキーマ バージョン番号。 | +| `version` | number | テーブルのスキーマバージョン番号。 | | `columns` | Array | 列名、データ型、null が可能かどうか、デフォルト値などの列情報。 | | `indexes` | Array | インデックス名、インデックスが一意かどうか、主キーかどうか、インデックス列などのインデックス情報。 | -テーブル名とスキーマ バージョン番号によって、テーブルのスキーマ情報を一意に識別できます。 +テーブル名とスキーマバージョン番号によって、テーブルのスキーマ情報を一意に識別できます。 > **Note:** > -> TiDB の実装上の制限により、 `RENAME TABLE` DDL 操作を実行しても、テーブルのスキーマ バージョン番号は変更されません。 +> TiDB の実装上の制限により、 `RENAME TABLE` DDL 操作を実行しても、テーブルのスキーマバージョン番号は変更されません。 #### カラムの定義 {#column-definition} diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index 2221d5b984ca8..6396391877e31 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -221,16 +221,16 @@ CDC000005.csv ### テーブルレベルのDDLイベント {#ddl-events-at-the-table-level} -アップストリーム テーブルの DDL イベントによってテーブル バージョンが変更されると、TiCDC は自動的に次の処理を実行します。 +アップストリームテーブルの DDL イベントによってテーブル バージョンが変更されると、TiCDC は自動的に次の処理を実行します。 - データ変更レコードを書き込むための新しいパスに切り替えます。例えば、バージョン`test.table1`が`441349361156227074`に変更されると、TiCDCはデータ変更レコードを書き込むためのパスを`s3://bucket/bbb/ccc/test/table1/441349361156227074/2022-01-02/`に変更します。 -- テーブル スキーマ情報を格納するために、次のパスにスキーマ ファイルを生成します。 +- テーブルスキーマ情報を格納するために、次のパスにスキーマファイルを生成します。 ```shell {scheme}://{prefix}/{schema}/{table}/meta/schema_{table-version}_{hash}.json ``` -`schema_441349361156227074_3131721815.json`スキーマ ファイルを例にとると、このファイル内のテーブル スキーマ情報は次のようになります。 +`schema_441349361156227074_3131721815.json`スキーマファイルを例にとると、このファイル内のテーブルスキーマ情報は次のようになります。 ```json { @@ -277,7 +277,7 @@ CDC000005.csv - `TableVersion` : テーブルバージョン。 - `Query` : DDL ステートメント。 - `Type` : DDL タイプ。 -- `TableColumns` : 1 つ以上のマップの配列。各マップはソース テーブル内の列を表します。 +- `TableColumns` : 1 つ以上のマップの配列。各マップはソーステーブル内の列を表します。 - `ColumnName` :カラム名。 - `ColumnType` :カラムの種類。詳細は[データ型](#data-type)を参照してください。 - `ColumnLength` :カラムの長さ。詳細は[データ型](#data-type)参照。 @@ -289,13 +289,13 @@ CDC000005.csv ### データベースレベルのDDLイベント {#ddl-events-at-the-database-level} -アップストリーム データベースでデータベース レベルの DDL イベントが実行されると、TiCDC は次のパスにスキーマ ファイルを自動的に生成し、データベース スキーマ情報を格納します。 +アップストリーム データベースでデータベースレベルの DDL イベントが実行されると、TiCDC は次のパスにスキーマファイルを自動的に生成し、データベーススキーマ情報を格納します。 ```shell {scheme}://{prefix}/{schema}/meta/schema_{table-version}_{hash}.json ``` -`schema_441349361156227000_3131721815.json`スキーマ ファイルを例にとると、このファイル内のデータベース スキーマ情報は次のようになります。 +`schema_441349361156227000_3131721815.json`スキーマファイルを例にとると、このファイル内のデータベーススキーマ情報は次のようになります。 ```json { @@ -321,7 +321,7 @@ TiDBの整数型は`IT[(M)] [UNSIGNED]`と定義され、 - `IT`は整数型で、 `TINYINT` 、 `SMALLINT` 、 `MEDIUMINT` 、 `INT` 、 `BIGINT` 、または`BIT`になります。 - `M`はタイプの表示幅です。 -整数型はスキーマ ファイル内で次のように定義されます。 +整数型はスキーマファイル内で次のように定義されます。 ```json { @@ -339,7 +339,7 @@ TiDBの10進数型は`DT[(M,D)][UNSIGNED]`と定義され、 - `M`はデータ型の精度、つまり合計桁数です。 - `D`は小数点以下の桁数です。 -10 進型はスキーマ ファイルで次のように定義されます。 +10 進型はスキーマファイルで次のように定義されます。 ```json { @@ -356,7 +356,7 @@ TiDBの日付型は`DT`と定義され、 - `DT`は日付型で、 `DATE`または`YEAR`になります。 -日付タイプはスキーマ ファイルで次のように定義されます。 +日付タイプはスキーマファイルで次のように定義されます。 ```json { @@ -370,7 +370,7 @@ TiDBの時間型は`TT[(M)]`と定義され、 - `TT`は時間のタイプで、 `TIME` 、 `DATETIME` 、または`TIMESTAMP`になります。 - `M`は 0 から 6 までの範囲の秒の精度です。 -時間タイプはスキーマ ファイルで次のように定義されます。 +時間タイプはスキーマファイルで次のように定義されます。 ```json { @@ -387,7 +387,7 @@ TiDBの文字列型は`ST[(M)]`として定義され、 - `ST`は文字列型で、 `CHAR` 、 `VARCHAR` 、 `TEXT` 、 `BINARY` 、 `BLOB` 、または`JSON`になります。 - `M`は文字列の最大長です。 -文字列型はスキーマ ファイル内で次のように定義されます。 +文字列型はスキーマファイル内で次のように定義されます。 ```json { @@ -399,7 +399,7 @@ TiDBの文字列型は`ST[(M)]`として定義され、 #### 列挙型と集合型 {#enum-and-set-types} -Enum 型と Set 型は、スキーマ ファイルで次のように定義されます。 +Enum 型と Set 型は、スキーマファイルで次のように定義されます。 ```json { diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index b7228a8ca6ee3..83ed2bda54aa4 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -9,7 +9,7 @@ summary: TiCDC を使用して Apache Kafka にデータを複製する方法を ## レプリケーションタスクを作成する {#create-a-replication-task} -次のコマンドを実行してレプリケーション タスクを作成します。 +次のコマンドを実行してレプリケーションタスクを作成します。 ```shell cdc cli changefeed create \ @@ -75,8 +75,8 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na | `topic-name` | 変数。Kafka トピックの名前。 | | `protocol` | Kafka にメッセージを出力するプロトコル。値のオプションは[`canal-json`](/ticdc/ticdc-canal-json.md) 、 [`open-protocol`](/ticdc/ticdc-open-protocol.md) 、 [`avro`](/ticdc/ticdc-avro-protocol.md) 、 [`debezium`](/ticdc/ticdc-debezium.md) 、 [`simple`](/ticdc/ticdc-simple-protocol.md)です。 | | `kafka-version` | ダウンストリーム Kafka のバージョン。この値は、ダウンストリーム Kafka の実際のバージョンと一致している必要があります。 | -| `kafka-client-id` | レプリケーション タスクの Kafka クライアント ID を指定します (オプション。デフォルトは`TiCDC_sarama_producer_replication ID` )。 | -| `partition-num` | ダウンストリーム Kafka パーティションの数 (オプション。値は実際のパーティション数**以下に**する必要があります。そうでない場合、レプリケーション タスクを正常に作成できません。デフォルトは`3` )。 | +| `kafka-client-id` | レプリケーションタスクの Kafka クライアント ID を指定します (オプション。デフォルトは`TiCDC_sarama_producer_replication ID` )。 | +| `partition-num` | ダウンストリーム Kafka パーティションの数 (オプション。値は実際のパーティション数**以下に**する必要があります。そうでない場合、レプリケーションタスクを正常に作成できません。デフォルトは`3` )。 | | `max-message-bytes` | Kafkaブローカーに毎回送信されるデータの最大サイズ（オプション、デフォルトは`10MB` 、最大値は`100MB` ）。v5.0.6およびv4.0.6以降、デフォルト値は`64MB`および`256MB`から`10MB`に変更されました。 | | `replication-factor` | 保存できるKafkaメッセージレプリカの数（オプション、デフォルトは`1` ）。この値はKafkaの[`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)の値である必要があります。 | | `required-acks` | `Produce`リクエストで使用されるパラメータ。ブローカーが応答するまでに受信する必要があるレプリカ確認応答の数を通知します。値のオプションは`0` ( `NoResponse` : 応答なし、 `TCP ACK`のみ提供)、 `1` ( `WaitForLocal` : ローカルコミットが正常に送信された後にのみ応答)、および`-1` ( `WaitForAll` : すべての複製レプリカが正常にコミットされた後に応答) です。複製レプリカの最小数は、ブローカーの[`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)設定項目を使用して設定できます。(オプション、デフォルト値は`-1` )。 | @@ -111,7 +111,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na - 独自のKafkaトピックを作成することをお勧めします。少なくとも、トピックがKafkaブローカーに送信できる各メッセージの最大データ量と、下流のKafkaパーティションの数を設定する必要があります。チェンジフィードを作成する場合、これらの2つの設定はそれぞれ`max-message-bytes`と`partition-num`に対応します。 - まだ存在しないトピックでチェンジフィードを作成した場合、TiCDCは`partition-num`と`replication-factor`パラメータを使用してトピックを作成しようとします。これらのパラメータは明示的に指定することをお勧めします。 - ほとんどの場合、 `canal-json`プロトコルを使用することをお勧めします。 -- TiCDCにおけるアップストリームデータの変更頻度が低い場合（例えば、10分以上データの変更がないなど）、Kafkaブローカー設定ファイルでKafka接続アイドルタイムアウトを増やすことをお勧めします。詳細については、 [TiCDC の Kafka へのレプリケーション タスクが`broken pipe`エラーで頻繁に失敗する理由](/ticdc/ticdc-faq.md#why-do-ticdc-replication-tasks-to-kafka-often-fail-with-broken-pipe-errors)を参照してください。 +- TiCDCにおけるアップストリームデータの変更頻度が低い場合（例えば、10分以上データの変更がないなど）、Kafkaブローカー設定ファイルでKafka接続アイドルタイムアウトを増やすことをお勧めします。詳細については、 [TiCDC の Kafka へのレプリケーションタスクが`broken pipe`エラーで頻繁に失敗する理由](/ticdc/ticdc-faq.md#why-do-ticdc-replication-tasks-to-kafka-often-fail-with-broken-pipe-errors)を参照してください。 > **Note:** > @@ -173,7 +173,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na ### TiCDC を Kafka Connect (Confluent Platform) と統合する {#integrate-ticdc-with-kafka-connect-confluent-platform} -Confluent が提供する[データコネクタ](https://docs.confluent.io/current/connect/managing/connectors.html)を使用してリレーショナル データベースまたは非リレーショナル データベースにデータをストリーミングするには、 [`avro`プロトコル](/ticdc/ticdc-avro-protocol.md)を使用し、 `schema-registry`で[Confluent スキーマレジストリ](https://www.confluent.io/product/confluent-platform/data-compatibility/)の URL を指定する必要があります。 +Confluent が提供する[データコネクタ](https://docs.confluent.io/current/connect/managing/connectors.html)を使用してリレーショナルデータベースまたは非リレーショナルデータベースにデータをストリーミングするには、 [`avro`プロトコル](/ticdc/ticdc-avro-protocol.md)を使用し、 `schema-registry`で[Confluent スキーマレジストリ](https://www.confluent.io/product/confluent-platform/data-compatibility/)の URL を指定する必要があります。 サンプル構成: @@ -420,8 +420,8 @@ large-message-handle-compression = "none" v7.3.0以降、TiCDC Kafkaシンクは、メッセージサイズが制限を超えた場合にハンドルキーのみを送信することをサポートします。これにより、メッセージサイズが大幅に削減され、Kafkaトピックの制限を超えたメッセージサイズに起因するチェンジフィードエラーやタスクの失敗を回避できます。ハンドルキーとは、以下のものを指します。 -- 複製するテーブルに主キーがある場合、主キーがハンドル キーになります。 -- テーブルに主キーがなく、NOT NULL 一意キーがある場合、NOT NULL 一意キーがハンドル キーになります。 +- 複製するテーブルに主キーがある場合、主キーがハンドルキーになります。 +- テーブルに主キーがなく、NOT NULL 一意キーがある場合、NOT NULL 一意キーがハンドルキーになります。 サンプル構成は次のとおりです。 @@ -435,7 +435,7 @@ large-message-handle-option = "claim-check" ### ハンドルキーのみでメッセージを消費する {#consume-messages-with-handle-keys-only} -ハンドル キーのみを含むメッセージ形式は次のとおりです。 +ハンドルキーのみを含むメッセージ形式は次のとおりです。 ```json { diff --git a/ticdc/ticdc-sink-to-mysql.md b/ticdc/ticdc-sink-to-mysql.md index dce47fbfe61e6..c7686af6e4c27 100644 --- a/ticdc/ticdc-sink-to-mysql.md +++ b/ticdc/ticdc-sink-to-mysql.md @@ -26,7 +26,7 @@ Info: {"sink-uri":"mysql://root:123456@127.0.0.1:3306/","opts":{},"create-time": - `--server` : TiCDCクラスタ内の任意のTiCDCサーバーのアドレス。 - `--changefeed-id` : レプリケーションタスクのID。形式は`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 -- `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。詳細については、[シンクURIを`mysql` / `tidb`で設定します](#configure-sink-uri-for-mysql-or-tidb)を参照してください。 +- `--sink-uri` : レプリケーションタスクのダウンストリーム アドレス。詳細については、[シンクURIを`mysql` / `tidb`で設定します](#configure-sink-uri-for-mysql-or-tidb)を参照してください。 - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 - `--target-ts` : 変更フィードの終了TSOを指定します。このTSOに達すると、TiCDCクラスタはデータのプルを停止します。デフォルト値は空で、これはTiCDCが自動的にデータのプルを停止しないことを意味します。 - `--config` : チェンジフィード構成ファイルを指定します。詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 @@ -58,14 +58,14 @@ MySQLの設定例： | パラメータ/パラメータ値 | 説明 | | :-------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `root` | ダウンストリーム データベースのユーザー名。データを TiDB または他の MySQL 互換データベースにレプリケートするには、ダウンストリーム データベース ユーザーが[特定の権限](#permissions-required-for-the-downstream-database-user)持っていることを確認してください。 | +| `root` | ダウンストリームデータベースのユーザー名。データを TiDB または他の MySQL 互換データベースにレプリケートするには、ダウンストリームデータベースユーザーが[特定の権限](#permissions-required-for-the-downstream-database-user)持っていることを確認してください。 | | `12345678` | 下流データベースのパスワード（Base64でエンコード可能）。 | | `127.0.0.1` | 下流データベースのIPアドレス。 | | `3306` | 下流データベースへのポート番号。 | | `worker-count` | ダウンストリームで同時に実行できる SQL ステートメントの数 (オプション、デフォルト値は`16` 、最大値は`1024`です)。 | -| `cache-prep-stmts` | ダウンストリームで SQL を実行する際にプリペアド ステートメントを使用するかどうか、およびクライアント側でプリペアドステートメントキャッシュを有効にするかどうかを制御します (オプション、デフォルトは`true` )。 | +| `cache-prep-stmts` | ダウンストリームで SQL を実行する際にプリペアドステートメントを使用するかどうか、およびクライアント側でプリペアドステートメントキャッシュを有効にするかどうかを制御します (オプション、デフォルトは`true` )。 | | `multi-stmt-enable` | 下流で実行される SQL ステートメントが、セミコロンで区切られた複数の SQL ステートメントをサポートするかどうかを制御します (オプション、デフォルト値は`true`です)。 `false`に設定されている場合、各 SQL ステートメントは個別のトランザクションとして実行されます。 `true`に設定されている場合、 `cache-prep-stmts`有効になりません。 | -| `max-txn-row` | ダウンストリームに実行される SQL ステートメントのバッチ サイズ (オプション、デフォルト値は`256` 、最大値は`2048`です)。 | +| `max-txn-row` | ダウンストリームに実行される SQL ステートメントのバッチサイズ (オプション、デフォルト値は`256` 、最大値は`2048`です)。 | | `max-multi-update-row` | バッチ書き込み ( `UPDATE ROWS` ) が有効になっている場合にダウンストリームで実行される`batch-dml-enable` SQL ステートメントのバッチサイズは、常に`max-txn-row`より小さくなります (オプション、デフォルト値は`40`で、最大値は`256`です)。 | | `max-multi-update-row-size` | バッチ書き込み ( `batch-dml-enable` ) が有効になっている場合、このパラメーターは、下流で実行される`UPDATE ROWS` SQL ステートメントのバッチ処理サイズ (バイト単位) を制御します。単一行の平均サイズがこのしきい値を超えると、各行は独立した SQL ステートメントとして実行されます (オプション、デフォルト値は`1024` 、最大値は`8192`です)。 | | `ssl-ca` | 下流のMySQLインスタンスに接続するために必要なCA証明書ファイルのパス（オプション）。 | @@ -123,13 +123,13 @@ TiDBまたはその他のMySQL互換データベースにデータを複製す - `Alter` - `Create View` -[`RECOVER TABLE`](/sql-statements/sql-statement-recover-table.md)下流の TiDB に複製するには、下流のデータベース ユーザーは`Super`権限も必要とします。 +[`RECOVER TABLE`](/sql-statements/sql-statement-recover-table.md)下流の TiDB に複製するには、下流のデータベースユーザーは`Super`権限も必要とします。 -ダウンストリーム TiDB クラスターで[読み取り専用モード](/system-variables.md#tidb_restricted_read_only-new-in-v520)が有効になっている場合、ダウンストリーム データベース ユーザーには`RESTRICTED_REPLICA_WRITER_ADMIN`権限も必要です。 +ダウンストリーム TiDB クラスターで[読み取り専用モード](/system-variables.md#tidb_restricted_read_only-new-in-v520)が有効になっている場合、ダウンストリームデータベースユーザーには`RESTRICTED_REPLICA_WRITER_ADMIN`権限も必要です。 ## 災害シナリオにおける結果整合性レプリケーション {#eventually-consistent-replication-in-disaster-scenarios} -TiCDC の最終整合性レプリケーション機能は、リドゥログを使用して、アップストリームで障害が発生した場合でもデータの一貫性を確保します。この機能は、バージョン 6.1.1 から一般提供 (GA) となります。バージョン 5.3.0 から、TiCDC は、アップストリーム TiDB クラスタからダウンストリーム クラスタのオブジェクトストレージまたは NFS への増分データのバックアップをサポートします。アップストリーム クラスタで障害が発生して利用できなくなった場合、TiCDC はダウンストリーム データを最新の最終整合性状態に復元できます。この機能により、アプリケーションをダウンストリーム クラスタに迅速に切り替えることができ、長時間のダウンタイムを回避し、サービスの継続性を向上させることができます。 +TiCDC の最終整合性レプリケーション機能は、リドゥログを使用して、アップストリームで障害が発生した場合でもデータの一貫性を確保します。この機能は、バージョン 6.1.1 から一般提供 (GA) となります。バージョン 5.3.0 から、TiCDC は、アップストリーム TiDB クラスタからダウンストリームクラスタのオブジェクトストレージまたは NFS への増分データのバックアップをサポートします。アップストリームクラスタで障害が発生して利用できなくなった場合、TiCDC はダウンストリームデータを最新の最終整合性状態に復元できます。この機能により、アプリケーションをダウンストリームクラスタに迅速に切り替えることができ、長時間のダウンタイムを回避し、サービスの継続性を向上させることができます。 現在、TiCDCは、TiDBクラスタから別のTiDBクラスタまたはMySQL互換データベースシステム（ Aurora、MySQL、MariaDBを含む）へ増分データを複製できます。上流クラスタがクラッシュした場合、TiCDCがクラッシュ前に正常にデータを複製し、複製遅延が小さいという条件を満たせば、TiCDCは下流クラスタで5分以内にデータを復元できます。データ損失は最大10秒まで許容され、RTOは5分以下、P95 RPOは10秒以下となります。 diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index b44f2b107b5e0..db08d96737ffc 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -9,7 +9,7 @@ summary: TiCDC を使用してデータを Pulsar に複製する方法を学び ## 増分データをPulsarに複製するレプリケーションタスクを作成する {#create-a-replication-task-to-replicate-incremental-data-to-pulsar} -次のコマンドを実行してレプリケーション タスクを作成します。 +次のコマンドを実行してレプリケーションタスクを作成します。 ```shell cdc cli changefeed create \ diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index d675b6191a33d..5e19b005758ae 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -64,7 +64,7 @@ UPDATE t SET a = 3 WHERE a = 2; COMMIT; ``` - ダウンストリームがトランザクションを実行すると、ダウンストリーム データベースのレコードはアップストリーム データベースのレコード ( `(2, 1)`と`(3, 2)`と同じになり、データの一貫性が確保されます。 + ダウンストリームがトランザクションを実行すると、ダウンストリームデータベースのレコードはアップストリーム データベースのレコード ( `(2, 1)`と`(3, 2)`と同じになり、データの一貫性が確保されます。 前の例からわかるように、 `UPDATE`イベントを`DELETE`つと`INSERT`イベントに分割してから Sorter モジュールに書き込むと、分割後の`INSERT`イベントの前に`DELETE`イベントすべてが実行されるようになり、TiCDC が受信した`UPDATE`イベントの順序に関係なく、データの一貫性が維持されます。 diff --git a/ticdc/ticdc-storage-consumer-dev-guide.md b/ticdc/ticdc-storage-consumer-dev-guide.md index f8c3eab191631..8a7b9e856fdea 100644 --- a/ticdc/ticdc-storage-consumer-dev-guide.md +++ b/ticdc/ticdc-storage-consumer-dev-guide.md @@ -108,14 +108,14 @@ func (tc *TableVersionConsumer) ExecuteDML() {} │ └── schema.json ``` -コンシューマーは`schema.json`ファイルのテーブル スキーマを解析し、DDL クエリ ステートメントを取得します。 +コンシューマーは`schema.json`ファイルのテーブルスキーマを解析し、DDL クエリステートメントを取得します。 -- クエリ ステートメントが見つからない場合、または`TableVersion`コンシューマー チェックポイントより小さい場合、コンシューマーはこのステートメントをスキップします。 -- クエリ ステートメントが存在する場合、または`TableVersion`コンシューマー チェックポイント以上の場合、コンシューマーはダウンストリーム MySQL で DDL ステートメントを実行します。 +- クエリステートメントが見つからない場合、または`TableVersion`コンシューマー チェックポイントより小さい場合、コンシューマーはこのステートメントをスキップします。 +- クエリステートメントが存在する場合、または`TableVersion`コンシューマー チェックポイント以上の場合、コンシューマーはダウンストリーム MySQL で DDL ステートメントを実行します。 次に、コンシューマーは`CDC000001.json`ファイルの複製を開始します。 -次の例では、 `test/tbl_1/437752935075545091/schema.json`ファイル内の DDL クエリ ステートメントが空ではありません。 +次の例では、 `test/tbl_1/437752935075545091/schema.json`ファイル内の DDL クエリステートメントが空ではありません。 ```json { diff --git a/ticdc/ticdc-summary-monitor.md b/ticdc/ticdc-summary-monitor.md index cfca9c388c27e..cde9d8f6f2021 100644 --- a/ticdc/ticdc-summary-monitor.md +++ b/ticdc/ticdc-summary-monitor.md @@ -18,7 +18,7 @@ v7.0.0以降、 TiUPを使用してGrafanaをデプロイすると、TiCDCサマ - データフロー: TiCDC 内部モジュールによって処理されるデータ変更の統計。 - トランザクションシンク: ダウンストリーム MySQL または TiDB の書き込みレイテンシー。 - MQ シンク: ダウンストリーム MQ システムの書き込みレイテンシー。 -- クラウド ストレージ シンク: ダウンストリーム クラウドストレージの書き込み速度。 +- クラウドストレージ シンク: ダウンストリーム クラウドストレージの書き込み速度。 - やり直し: やり直し機能が有効な場合の書き込みレイテンシー。 ## サーバーパネル {#server-panel} @@ -51,7 +51,7 @@ v7.0.0以降、 TiUPを使用してGrafanaをデプロイすると、TiCDCサマ - **Sorter出力イベント数/秒**: TiCDCノードのSinkモジュールにSorterモジュールから1秒あたりに出力されるデータ変更の数。Sorterのデータ出力レートはSinkモジュールの影響を受けることに注意してください。したがって、Sorterモジュールの出力レートがPullerモジュールの出力レートよりも低い場合、必ずしもSorterモジュールのソート速度が遅すぎることを意味するわけではありません。まずSinkモジュールに関連するメトリクスを観察し、Sinkモジュールのデータフラッシュに時間がかかり、Sorterモジュールの出力が低下していないかどうかを確認する必要があります。 -- **ソーター出力イベント**: TiCDC ノードのソーター モジュールからシンク モジュールに出力されたデータ変更の合計数。 +- **ソーター出力イベント**: TiCDC ノードのソーターモジュールからシンク モジュールに出力されたデータ変更の合計数。 ![TiCDC Summary Dashboard - Mounter metrics](/media/ticdc/ticdc-summary-monitor-dataflow-mounter.png) diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md index 7a316e64c0736..9a439e74c2536 100644 --- a/ticdc/ticdc-upstream-downstream-check.md +++ b/ticdc/ticdc-upstream-downstream-check.md @@ -1,6 +1,6 @@ --- title: Upstream and Downstream Clusters Data Validation and Snapshot Read -summary: TiDB アップストリーム クラスターとダウンストリーム クラスターのデータを確認する方法を学習します。 +summary: TiDB アップストリームクラスターとダウンストリームクラスターのデータを確認する方法を学習します。 --- # 上流および下流のクラスタのデータ検証とスナップショットの読み取り {#upstream-and-downstream-clusters-data-validation-and-snapshot-read} @@ -18,7 +18,7 @@ Syncpoint機能を有効にするには、レプリケーションタスクの 1. レプリケーション中、TiCDC は定期的に ( `sync-point-interval`で設定) アップストリームとダウンストリームの間でスナップショットを調整し、アップストリームとダウンストリームの TSO 対応をダウンストリーム`tidb_cdc.syncpoint_v1`テーブルに保存します。 2. レプリケーション中、TiCDC は定期的に ( `sync-point-interval`で設定) `SET GLOBAL tidb_external_ts = @@tidb_current_ts`を実行し、バックアップ クラスターにレプリケートされた一貫性のあるスナップショット ポイントを設定します。 -次の TiCDC 構成例では、レプリケーション タスクの作成時に Syncpoint を有効にします。 +次の TiCDC 構成例では、レプリケーションタスクの作成時に Syncpoint を有効にします。 ```toml # Enables SyncPoint. @@ -47,7 +47,7 @@ sync-point-retention = "1h" > > データ一貫性検証を実行する前に、 [同期ポイント機能を有効にしました](#enable-syncpoint)あることを確認してください。 -アップストリーム クラスターとダウンストリーム クラスターのデータを検証するには、sync-diff-inspector で`snapshot`設定するだけです。 +アップストリームクラスターとダウンストリームクラスターのデータを検証するには、sync-diff-inspector で`snapshot`設定するだけです。 ### ステップ1: `ts-map`を取得する {#step-1-obtain-ts-map} @@ -67,7 +67,7 @@ select * from tidb_cdc.syncpoint_v1; - `ticdc_cluster_id` : このレコード内の TiCDC クラスターの ID。 - `changefeed` : このレコード内の変更フィードのID。異なるTiCDCクラスターに同じ名前の変更フィードが存在する可能性があるため、変更フィードによって挿入された`ts-map` IDをTiCDCクラスターIDと変更フィードIDで確認する必要があります。 - `primary_ts` : アップストリーム データベース スナップショットのタイムスタンプ。 -- `secondary_ts` : ダウンストリーム データベース スナップショットのタイムスタンプ。 +- `secondary_ts` : ダウンストリームデータベース スナップショットのタイムスタンプ。 - `created_at` : このレコードが挿入された時刻。 ### ステップ2: スナップショットを構成する {#step-2-configure-snapshot} diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 9f1bf88b81adc..c372bf17282f0 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -13,14 +13,14 @@ summary: TiCDC の使用時に発生する可能性のある問題のトラブ ## TiCDC レプリケーションの中断 {#ticdc-replication-interruptions} -### TiCDC レプリケーション タスクが中断されたかどうかはどうすればわかりますか? {#how-do-i-know-whether-a-ticdc-replication-task-is-interrupted} +### TiCDC レプリケーションタスクが中断されたかどうかはどうすればわかりますか? {#how-do-i-know-whether-a-ticdc-replication-task-is-interrupted} - Grafanaダッシュボードで、レプリケーションタスクの監視メトリック`changefeed checkpoint` （適切な`changefeed id`選択）を確認してください。メトリック値が変化しない場合、またはメトリック`checkpoint lag`が増加し続ける場合、レプリケーションタスクが中断されている可能性があります。 - 監視メトリック`exit error count`を確認してください。メトリック値が`0`より大きい場合、レプリケーションタスクでエラーが発生しました。 - `cdc cli changefeed list`と`cdc cli changefeed query`を実行して、レプリケーションタスクのステータスを確認します。`stopped`はタスクが停止したことを意味し、 `error`は詳細なエラーメッセージを示します。エラー発生後、TiCDCサーバーログで`error on running processor`を検索してエラースタックを確認し、トラブルシューティングを行うことができます。 - 極端なケースでは、TiCDC サービスが再起動されることがあります。トラブルシューティングのために、TiCDCサーバーログの`FATAL`レベル目のログを検索できます。 -### レプリケーション タスクが手動で停止されたかどうかを確認するにはどうすればよいですか? {#how-do-i-know-whether-the-replication-task-is-stopped-manually} +### レプリケーションタスクが手動で停止されたかどうかを確認するにはどうすればよいですか? {#how-do-i-know-whether-the-replication-task-is-stopped-manually} レプリケーションタスクが手動で停止されているかどうかを確認するには、 `cdc cli`を実行します。例: @@ -32,29 +32,29 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc ### レプリケーションの中断をどのように処理しますか? {#how-do-i-handle-replication-interruptions} -次の既知のシナリオでは、レプリケーション タスクが中断される可能性があります。 +次の既知のシナリオでは、レプリケーションタスクが中断される可能性があります。 - ダウンストリームは引き続き異常であり、何度も再試行しても TiCDC は失敗します。 - このシナリオでは、TiCDCはタスク情報を保存します。TiCDCはPDにサービスGCセーフポイントを設定しているため、タスクチェックポイント以降のデータは有効期間`gc-ttl`内にTiKV GCによってクリーンアップされません。 - - 対処方法：ダウンストリームが正常に戻った後、 `cdc cli changefeed resume`を実行することでレプリケーション タスクを再開できます。 + - 対処方法：ダウンストリームが正常に戻った後、 `cdc cli changefeed resume`を実行することでレプリケーションタスクを再開できます。 - ダウンストリームに互換性のない SQL ステートメントがあるため、レプリケーションを続行できません。 - このシナリオでは、TiCDCはタスク情報を保存します。TiCDCはPDにサービスGCセーフポイントを設定しているため、タスクチェックポイント以降のデータは有効期間`gc-ttl`内にTiKV GCによってクリーンアップされません。 - 取り扱い手順: - 1. `cdc cli changefeed query`コマンドを使用してレプリケーション タスクのステータス情報を照会し、 `checkpoint-ts`の値を記録します。 + 1. `cdc cli changefeed query`コマンドを使用してレプリケーションタスクのステータス情報を照会し、 `checkpoint-ts`の値を記録します。 2. 新しいタスク構成ファイルを使用して`ignore-txn-start-ts`パラメータを追加し、指定された`start-ts`に対応するトランザクションをスキップします。 - 3. `cdc cli changefeed pause -c `を実行してレプリケーション タスクを一時停止します。 + 3. `cdc cli changefeed pause -c `を実行してレプリケーションタスクを一時停止します。 4. `cdc cli changefeed update -c --config `を実行して新しいタスク構成ファイルを指定します。 - 5. `cdc cli changefeed resume -c `を実行してレプリケーション タスクを再開します。 + 5. `cdc cli changefeed resume -c `を実行してレプリケーションタスクを再開します。 ### タスク中断後に TiCDC を再起動した後で発生する OOM を処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-oom-that-occurs-after-ticdc-is-restarted-after-a-task-interruption} - TiDBクラスタとTiCDCクラスタを最新バージョンに更新してください。OOM問題は**、v4.0.14以降のv4.0バージョン、v5.0.2以降のv5.0バージョン、および最新バージョン**で既に解決されています。 -## レプリケーション タスクを作成するとき、または MySQL にデータをレプリケートするときに、「 `Error 1298: Unknown or incorrect time zone: 'UTC'`エラーを処理するにはどうすればよいですか? {#how-do-i-handle-the-error-1298-unknown-or-incorrect-time-zone-utc-error-when-creating-the-replication-task-or-replicating-data-to-mysql} +## レプリケーションタスクを作成するとき、または MySQL にデータをレプリケートするときに、「 `Error 1298: Unknown or incorrect time zone: 'UTC'`エラーを処理するにはどうすればよいですか? {#how-do-i-handle-the-error-1298-unknown-or-incorrect-time-zone-utc-error-when-creating-the-replication-task-or-replicating-data-to-mysql} このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)を実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 @@ -82,7 +82,7 @@ Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skippin ## TiCDCタスクの`start-ts`タイムスタンプが現在時刻と大きく異なります。このタスクの実行中にレプリケーションが中断され、エラー`[CDC:ErrBufferReachLimit]`が発生しました。どうすればよいでしょうか？ {#the-start-ts-timestamp-of-the-ticdc-task-is-quite-different-from-the-current-time-during-the-execution-of-this-task-replication-is-interrupted-and-an-error-cdc-errbufferreachlimit-occurs-what-should-i-do} -v4.0.9 以降では、レプリケーション タスクで統合ソーター機能を有効にするか、 BRツールを使用して増分バックアップと復元を実行し、新しい時間から TiCDC レプリケーション タスクを開始することができます。 +v4.0.9 以降では、レプリケーションタスクで統合ソーター機能を有効にするか、 BRツールを使用して増分バックアップと復元を実行し、新しい時間から TiCDC レプリケーションタスクを開始することができます。 ## 変更フィードの下流にMySQLなどのデータベースがあり、TiCDCが時間のかかるDDL文を実行すると、他のすべての変更フィードがブロックされます。どうすればよいでしょうか？ {#when-the-downstream-of-a-changefeed-is-a-database-similar-to-mysql-and-ticdc-executes-a-time-consuming-ddl-statement-all-other-changefeeds-are-blocked-what-should-i-do} diff --git a/tidb-cloud/ai-feature-concepts.md b/tidb-cloud/ai-feature-concepts.md index c01e489d8915a..459c6d855263e 100644 --- a/tidb-cloud/ai-feature-concepts.md +++ b/tidb-cloud/ai-feature-concepts.md @@ -13,7 +13,7 @@ TiDB CloudのAI機能により、データ探索、検索、統合のための Chat2Query は SQL エディターに統合された AI を活用した機能で、ユーザーが自然言語命令を使用して SQL クエリを生成、デバッグ、または書き換えるのを支援します。詳細については、[AI支援型SQLエディタでデータを探索しよう](/tidb-cloud/explore-data-with-chat2query.md)を参照してください。 -さらに、 TiDB Cloud は、 TiDB Cloud Starterインスタンス用の Chat2Query API を提供します。有効にすると、 TiDB Cloud はChat2Query と呼ばれるシステム データ アプリと Data Service に Chat2Data エンドポイントを自動的に作成します。このエンドポイントを呼び出して、AI に指示を提供して SQL ステートメントを生成および実行させることができます。詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)を参照してください。 +さらに、 TiDB Cloud は、 TiDB Cloud Starterインスタンス用の Chat2Query API を提供します。有効にすると、 TiDB Cloud はChat2Query と呼ばれるシステムデータアプリと Data Service に Chat2Data エンドポイントを自動的に作成します。このエンドポイントを呼び出して、AI に指示を提供して SQL ステートメントを生成および実行させることができます。詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)を参照してください。 ## ベクトル検索（プレビュー） {#vector-search-preview} @@ -39,7 +39,7 @@ TiDBは、いくつかの人気のあるAIフレームワークを公式にサ 埋め込みモデルは、データを に変換するアルゴリズムです。適切な埋め込みモデルを選択することは[ベクトル埋め込み](/ai/concepts/vector-search-overview.md#vector-embedding)意味検索結果の正確性と関連性を確保するために非常に重要です。 -TiDB ベクトル検索は、最大 16383 次元のベクトルの保存をサポートしており、ほとんどの埋め込みモデルに対応します。非構造化テキスト データの場合は、 [大規模テキスト埋め込みベンチマーク（MTEB）リーダーボード](https://huggingface.co/spaces/mteb/leaderboard)リーダーボードで最高のパフォーマンスのテキスト埋め込みモデルを見つけることができます。 +TiDB ベクトル検索は、最大 16383 次元のベクトルの保存をサポートしており、ほとんどの埋め込みモデルに対応します。非構造化テキストデータの場合は、 [大規模テキスト埋め込みベンチマーク（MTEB）リーダーボード](https://huggingface.co/spaces/mteb/leaderboard)リーダーボードで最高のパフォーマンスのテキスト埋め込みモデルを見つけることができます。 ### オブジェクトリレーショナルマッピング（ORM）ライブラリ {#object-relational-mapping-orm-libraries} diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 82aec28327de0..014a9eb0fe66d 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -87,7 +87,7 @@ TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2 - **従量課金制**：実際の[リクエストキャパシティユニット（RCU）](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)消費量とストレージ使用量に基づいて課金されます。この柔軟なモデルにより、バックエンドでの手動による過剰プロビジョニングが不要になります。 - **高度なセキュリティ**：大規模企業や規制対象業界が必要とする、より高度なセキュリティ設定とコンプライアンス機能を提供します。 -ミッション クリティカルなワークロードの稼働時間と回復力を最大化するために、 TiDB Cloud Premium は[地域的な高可用性](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture)を提供し、複数のアベイラビリティ ゾーンにノードを分散して、ゾーン展開よりも高い冗長性を実現します。 +ミッション クリティカルなワークロードの稼働時間と回復力を最大化するために、 TiDB Cloud Premium は[地域的な高可用性](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture)を提供し、複数のアベイラビリティゾーンにノードを分散して、ゾーン展開よりも高い冗長性を実現します。 diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md index 9ffd3e49ce4e6..0f4a86cdd5800 100644 --- a/tidb-cloud/backup-and-restore.md +++ b/tidb-cloud/backup-and-restore.md @@ -16,7 +16,7 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] - TiDB Cloud Dedicatedは、v6.2.0以降のバージョンのクラスタでは、デフォルトでバックアップからのユーザーアカウントとSQLバインディングの復元をサポートしています。 - TiDB Cloud Dedicated は、 `mysql`スキーマに保存されているシステム変数の復元をサポートしていません。 -- 最初にデータをインポートし、次に**手動**スナップショット バックアップを実行し、最後にポイントインタイム リストアを有効にすることをお勧めします。 TiDB Cloudコンソールを通じてインポートされたデータは変更ログを生成**しない**ため、自動的に検出してバックアップすることはできません。詳細については、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。 +- 最初にデータをインポートし、次に**手動**スナップショットバックアップを実行し、最後にポイントインタイム リストアを有効にすることをお勧めします。 TiDB Cloudコンソールを通じてインポートされたデータは変更ログを生成**しない**ため、自動的に検出してバックアップすることはできません。詳細については、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。 - ポイントインタイム復元を複数回オン/オフした場合、復元可能な期間内で選択できるのは、直近のポイントインタイム復元が有効になった時点以降の時点のみです。それ以前の復元可能な期間にはアクセスできません。 - **Point-in-time Restore**と**Dual Region Backup**のスイッチを同時に変更しないでください。 @@ -34,7 +34,7 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] ### 自動バックアップを有効にする {#turn-on-auto-backup} -TiDB Cloud Dedicated は、 [スナップショットバックアップ](https://docs.pingcap.com/tidb/stable/br-snapshot-guide)と[ログバックアップ](https://docs.pingcap.com/tidb/stable/br-pitr-guide)両方をサポートしています。スナップショット バックアップを使用すると、データをバックアップ ポイントに復元できます。デフォルトでは、スナップショット バックアップは自動的に作成され、バックアップ保持ポリシーに従って保存されます。自動バックアップはいつでも無効にできます。 +TiDB Cloud Dedicated は、 [スナップショットバックアップ](https://docs.pingcap.com/tidb/stable/br-snapshot-guide)と[ログバックアップ](https://docs.pingcap.com/tidb/stable/br-pitr-guide)両方をサポートしています。スナップショットバックアップを使用すると、データをバックアップ ポイントに復元できます。デフォルトでは、スナップショットバックアップは自動的に作成され、バックアップ保持ポリシーに従って保存されます。自動バックアップはいつでも無効にできます。 #### ポイントインタイム復元を有効にする {#turn-on-point-in-time-restore} @@ -62,7 +62,7 @@ TiDB Cloud Dedicatedクラスターでこの機能を有効にするには、以 > **Warning** > - > ポイントインタイム リストアは、次のバックアップ タスクが完了した後にのみ有効になります。より早く有効にするには、有効にした後に[手動でバックアップを実行する](#perform-a-manual-backup)ことができます。 + > ポイントインタイム リストアは、次のバックアップタスクが完了した後にのみ有効になります。より早く有効にするには、有効にした後に[手動でバックアップを実行する](#perform-a-manual-backup)ことができます。 5. 変更を保存するには、 **保存**をクリックしてください。 @@ -248,7 +248,7 @@ TiDB Cloud Dedicatedクラスターに手動バックアップを適用するに #### バックアップファイルを削除する {#delete-backup-files} -TiDB Cloud Dedicatedクラスターの既存のバックアップ ファイルを削除するには、次の手順を実行します。 +TiDB Cloud Dedicatedクラスターの既存のバックアップファイルを削除するには、次の手順を実行します。 1. TiDB Cloud Dedicatedクラスターの[**バックアップ**](#view-the-backup-page)ページに移動します。 @@ -256,11 +256,11 @@ TiDB Cloud Dedicatedクラスターの既存のバックアップ ファイル #### 実行中のバックアップジョブを削除します {#delete-a-running-backup-job} -TiDB Cloud Dedicatedクラスターの実行中のバックアップ ジョブを削除するには、[**バックアップファイルを削除する**](#delete-backup-files)と同様のプロセスに従います。 +TiDB Cloud Dedicatedクラスターの実行中のバックアップジョブを削除するには、[**バックアップファイルを削除する**](#delete-backup-files)と同様のプロセスに従います。 1. TiDB Cloud Dedicatedクラスターの[**バックアップ**](#view-the-backup-page)ページに移動します。 -2. **保留中**または**実行**中のバックアップ ジョブを見つけて、 **[アクション]**列の**[...]** > **[削除]**をクリックします。 +2. **保留中**または**実行**中のバックアップジョブを見つけて、 **[アクション]**列の**[...]** > **[削除]**をクリックします。 ## 復元する {#restore} diff --git a/tidb-cloud/built-in-monitoring.md b/tidb-cloud/built-in-monitoring.md index 1e02f36216386..3bacb00cc21d6 100644 --- a/tidb-cloud/built-in-monitoring.md +++ b/tidb-cloud/built-in-monitoring.md @@ -38,7 +38,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | クエリ実行時間 | 平均-{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 秒あたりにプラン キャッシュに見つからないクエリの数。 | +| プランキャッシュOPSを使用したクエリ | ヒット、ミス | hit: すべてのTiDBノードにおいて、1秒あたりにプランキャッシュを使用するクエリの数。
    miss: すべての TiDB ノードにおいて、1 秒あたりにプランキャッシュに見つからないクエリの数。 | | トランザクション/秒 | {タイプ}-{トランザクションモデル} | 1秒あたりに実行されるトランザクション数。 | | トランザクション期間 | 平均-{トランザクションモデル}、99-{トランザクションモデル} | トランザクションの平均期間、または99パーセンタイル値。 | | 接続数 | すべて、アクティブな接続 | All: すべてのTiDBノードへの接続数。
    アクティブな接続数：すべてのTiDBノードへのアクティブな接続数。 | diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index ba3bab4f132da..68f15163447e6 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -33,7 +33,7 @@ TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサ > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[変更フィード]**をクリックします。チェンジフィードページが表示されます。 +2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[変更フィード]**をクリックします。チェンジフィードページが表示されます。 **変更フィード**ページでは、変更フィードの作成、既存の変更フィードの一覧表示、および既存の変更フィードの操作（変更フィードの拡大縮小、一時停止、再開、編集、削除など）を行うことができます。 @@ -161,12 +161,12 @@ TiDB Cloudでの変更フィードの請求については、[Changefeedの請 状態は以下のように説明されます。 - `CREATING` : レプリケーションタスクが作成されています。 -- `RUNNING` : レプリケーション タスクは正常に実行され、チェックポイント ts も正常に進行します。 +- `RUNNING` : レプリケーションタスクは正常に実行され、チェックポイント ts も正常に進行します。 - `EDITING` : レプリケーションタスクが編集されています。 -- `PAUSING` : レプリケーション タスクが一時停止されています。 -- `PAUSED` : レプリケーション タスクが一時停止されました。 +- `PAUSING` : レプリケーションタスクが一時停止されています。 +- `PAUSED` : レプリケーションタスクが一時停止されました。 - `RESUMING` : レプリケーションタスクが再開されます。 -- `DELETING` : レプリケーション タスクが削除されています。 -- `DELETED` : レプリケーション タスクが削除されました。 -- `WARNING` : レプリケーション タスクが警告を返します。回復可能なエラーのため、レプリケーションを続行できません。この状態の変更フィードは、状態が`RUNNING`に遷移するまで再開を試み続けます。この状態の変更フィードは[GCオペレーション](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)ブロックします 。 -- `FAILED` : レプリケーション タスクが失敗しました。エラーが発生したため、レプリケーション タスクを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期間 (TTL) は 24 時間です。つまり、変更フィードが中断されてから 24 時間以内に GC メカニズムによってデータが削除されることはありません。 +- `DELETING` : レプリケーションタスクが削除されています。 +- `DELETED` : レプリケーションタスクが削除されました。 +- `WARNING` : レプリケーションタスクが警告を返します。回復可能なエラーのため、レプリケーションを続行できません。この状態の変更フィードは、状態が`RUNNING`に遷移するまで再開を試み続けます。この状態の変更フィードは[GCオペレーション](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)ブロックします 。 +- `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..f57f02e87d269 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -62,9 +62,9 @@ Apache Kafkaにデータをストリーミングするためのチェンジフ TiDB Cloud は現在、セルフホスト型 Kafka のプライベート接続のみをサポートしています。 MSK、Confluent Kafka、またはその他の Kafka SaaS サービスとの直接統合はサポートされていません。 Private Connect 経由でこれらの Kafka SaaS サービスに接続するには、 [kafka-proxy](https://github.com/grepplabs/kafka-proxy)を仲介としてデプロイし、Kafka サービスを自己ホスト型 Kafka として効果的に公開できます。詳細な例については、 [Google Cloud で Kafka-proxy を使用して自己ホスト型 Kafka プライベートサービス接続を設定する](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)を参照してください。この設定は、すべての Kafka SaaS サービスで同様です。 -- Apache Kafka サービスが AWS でホストされている場合は、 [AWSでセルフホスト型のKafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)セットアップする」に従ってネットワーク接続を構成し、**Bootstrap Ports**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)ポイントを設定する」に従ってプライベート エンドポイントを作成します。 -- Apache Kafka サービスが Google Cloud でホストされている場合は、 [Google Cloud でセルフホスト型の Kafka プライベートサービスコネクトを設定する](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md)ネットワーク接続を構成し、**Bootstrap Ports**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)ポイントを設定するに従ってプライベート エンドポイントを作成します。 -- Apache Kafka サービスが Azure でホストされている場合は、 [Azureでセルフホスト型Kafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md)セットアップする」に従ってネットワーク接続を構成し、**Bootstrap Ports**情報を取得してから、[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)エンドプライベートポイントを設定するに従ってプライベート エンドポイントを作成します。 +- Apache Kafka サービスが AWS でホストされている場合は、 [AWSでセルフホスト型のKafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)セットアップする」に従ってネットワーク接続を構成し、**Bootstrap Ports**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)ポイントを設定する」に従ってプライベートエンドポイントを作成します。 +- Apache Kafka サービスが Google Cloud でホストされている場合は、 [Google Cloud でセルフホスト型の Kafka プライベートサービスコネクトを設定する](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md)ネットワーク接続を構成し、**Bootstrap Ports**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)ポイントを設定するに従ってプライベートエンドポイントを作成します。 +- Apache Kafka サービスが Azure でホストされている場合は、 [Azureでセルフホスト型Kafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md)セットアップする」に従ってネットワーク接続を構成し、**Bootstrap Ports**情報を取得してから、[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)エンドプライベートポイントを設定するに従ってプライベートエンドポイントを作成します。
    @@ -87,7 +87,7 @@ Apache Kafka サービスがインターネットにアクセスできない Goo 1. Apache Kafka サービスの VPC とTiDB Cloud Dedicatedクラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 2. Apache Kafkaが配置されているVPCのイングレスファイアウォールルールを変更します。 - TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR を、イングレス ファイアウォール ルールに追加する必要があります。CIDR は**VPC Peering**ページで確認できます。これにより、TiDB Cloud Dedicatedクラスターから Kafka ブローカーへのトラフィックが流れるようになります。 + TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR を、イングレス ファイアウォールルールに追加する必要があります。CIDR は**VPC Peering**ページで確認できます。これにより、TiDB Cloud Dedicatedクラスターから Kafka ブローカーへのトラフィックが流れるようになります。
    @@ -107,11 +107,11 @@ Apache KafkaサービスにパブリックIPアクセスを提供する場合は プライベートコネクトは、クラウドプロバイダーの**Private Link**または**Private Service Connect**技術を活用し、VPC内のリソースがプライベートIPアドレスを使用して他のVPC内のサービスに接続できるようにします。これにより、あたかもそれらのサービスがVPC内で直接ホストされているかのように動作します。 -TiDB Cloud Premium インスタンスでチェンジフィードのプライベート エンドポイントを作成するには、[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)するに従ってください。 +TiDB Cloud Premium インスタンスでチェンジフィードのプライベートエンドポイントを作成するには、[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)するに従ってください。 TiDB Cloudは現在、セルフホスト型KafkaのみPrivate Connectをサポートしています。MSK、Confluent Kafka、その他のKafka SaaSサービスとの直接統合はサポートしていません。これらのKafka SaaSサービスにPrivate Connect経由で接続するには、 [kafka-proxy](https://github.com/grepplabs/kafka-proxy)中間サーバーとしてデプロイし、Kafkaサービスをセルフホスト型Kafkaとして公開する必要があります。 -Apache Kafka サービスが AWS でホストされている場合は、 [AWSでセルフホスト型のKafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)セットアップする」に従ってネットワーク接続を構成し、**Bootstrap Ports**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md)ポイントを設定する」に従ってプライベート エンドポイントを作成します。 +Apache Kafka サービスが AWS でホストされている場合は、 [AWSでセルフホスト型のKafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)セットアップする」に従ってネットワーク接続を構成し、**Bootstrap Ports**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md)ポイントを設定する」に従ってプライベートエンドポイントを作成します。
    @@ -135,14 +135,14 @@ Apache KafkaサービスにパブリックIPアクセスを提供する場合は TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミングし、Kafkaトピックを自動的に作成できるようにするには、Kafkaに以下の権限が追加されていることを確認してください。 - Kafka のトピック リソース タイプに`Create`および`Write`権限が追加されます。 -- Kafka のクラスタ リソース タイプに`DescribeConfigs`権限が追加されます。 +- Kafka のクラスタリソース タイプに`DescribeConfigs`権限が追加されます。 たとえば、Kafka クラスターが Confluent Cloud にある場合、詳細については Confluent ドキュメントの[リソース](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)と[ACLの追加](https://docs.confluent.io/platform/current/kafka/authorization.html#adding-acls)を参照してください。 ## ステップ1. Apache KafkaのChangefeedページを開きます。 {#step-1-open-the-changefeed-page-for-apache-kafka} 1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインします。 -2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスの概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[変更フィード]**をクリックします。 +2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスの概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[変更フィード]**をクリックします。 3. **Create Changefeed**をクリックし、**宛先**として**Kafka**を選択します。 ## ステップ2. changefeedターゲットを設定する {#step-2-configure-the-changefeed-target} @@ -206,7 +206,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン
    1. **Connectivity Method**で**Private Service Connect**を選択します。 -2. **Private Endpoint**で、[ネットワーク](#network)セクションで作成したプライベート エンドポイントを選択します。 +2. **Private Endpoint**で、[ネットワーク](#network)セクションで作成したプライベートエンドポイントを選択します。 3. [ネットワーク](#network)セクションで取得した**Bootstrap Ports**を入力してください。複数のポートを指定することをお勧めします。複数のポートを区切るには、カンマ`,`を使用できます。 4. Kafkaの認証設定に応じて、**認証**オプションを選択してください。 @@ -227,7 +227,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン
    1. **Connectivity Method**で**Private Link**を選択します。 -2. **Private Endpoint**で、[ネットワーク](#network)セクションで作成したプライベート エンドポイントを選択します。 +2. **Private Endpoint**で、[ネットワーク](#network)セクションで作成したプライベートエンドポイントを選択します。 3. [ネットワーク](#network)セクションで取得した**Bootstrap Ports**を入力してください。1つのAZにつき少なくとも1つのポートを設定することをお勧めします。複数のポートを指定する場合は、カンマ`,`で区切ってください。 4. Kafkaの認証設定に応じて、**認証**オプションを選択してください。 @@ -276,7 +276,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - - オープン プロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータ ソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 + - オープンプロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index dd1221b68f823..7b19fccdfd971 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -21,7 +21,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl ## ステップ1. 宛先を設定する {#step-1-configure-destination} -対象のTiDB Cloud Dedicatedクラスターの概要ページに移動します。左側のナビゲーション ペインで**[データ]** > **[変更フィード]**をクリックし、 **Create Changefeed**をクリックして**[宛先]**ページに移動します。次に、 TiDB Cloud Dedicatedクラスターがホストされているクラウド プロバイダーに応じて、宛先として**Amazon S3** 、 **GCS** 、または**Azure Blob Storage**を選択します。構成プロセスは、選択した宛先によって異なります。 +対象のTiDB Cloud Dedicatedクラスターの概要ページに移動します。左側のナビゲーションペインで**[データ]** > **[変更フィード]**をクリックし、 **Create Changefeed**をクリックして**[宛先]**ページに移動します。次に、 TiDB Cloud Dedicatedクラスターがホストされているクラウドプロバイダーに応じて、宛先として**Amazon S3** 、 **GCS** 、または**Azure Blob Storage**を選択します。構成プロセスは、選択した宛先によって異なります。
    diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index b37440c050912..36db22dfc1d16 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -51,13 +51,13 @@ MySQLサービスがパブリックインターネットアクセスを持たな 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns)の手順に従います。 2. **Accepter DNS resolution**オプションを有効にする。 -MySQL サービスがパブリック インターネット アクセスのない Google Cloud VPC 内にある場合は、以下の手順を実行してください。 +MySQL サービスがパブリックインターネット アクセスのない Google Cloud VPC 内にある場合は、以下の手順を実行してください。 1. MySQL サービスが Google Cloud SQL の場合、Google Cloud SQL インスタンスに関連付けられた VPC に MySQL エンドポイントを公開する必要があります。Cloud [**Cloud SQL Auth proxy**](https://cloud.google.com/sql/docs/mysql/sql-proxy)を使用する必要がある場合があります。これは Google によって開発されています。 2. MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 3. MySQLが配置されているVPCの受信ファイアウォールルールを変更します。 - [TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)イングレス ファイアウォール ルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Dedicatedクラスターから MySQL エンドポイントに流れるようになります。 + [TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)イングレス ファイアウォールルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Dedicatedクラスターから MySQL エンドポイントに流れるようになります。
    @@ -65,7 +65,7 @@ MySQL サービスがパブリック インターネット アクセスのない プライベートエンドポイントは、クラウドプロバイダーの**Private Link**または**Private Service Connect**技術を活用し、VPC内のリソースがプライベートIPアドレスを介して他のVPC内のサービスに接続できるようにします。これにより、あたかもそれらのサービスがVPC内で直接ホストされているかのように動作します。 -プライベート エンドポイントを介して、 TiDB Cloud Dedicatedクラスターを MySQL サービスに安全に接続できます。 MySQL サービスでプライベート エンドポイントが利用できない場合は、[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)に従って作成します。 +プライベートエンドポイントを介して、 TiDB Cloud Dedicatedクラスターを MySQL サービスに安全に接続できます。 MySQL サービスでプライベートエンドポイントが利用できない場合は、[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)に従って作成します。
    @@ -79,7 +79,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること プライベートエンドポイントは、クラウドプロバイダーの**Private Link**または**Private Service Connect**技術を活用し、VPC内のリソースがプライベートIPアドレスを介して他のVPC内のサービスに接続できるようにします。これにより、あたかもそれらのサービスがVPC内で直接ホストされているかのように動作します。 -プライベート エンドポイントを通じて、 TiDB Cloud Premium インスタンスを MySQL サービスに安全に接続できます。 MySQL サービスでプライベート エンドポイントが利用できない場合は、 [Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md)に従って作成します。 +プライベートエンドポイントを通じて、 TiDB Cloud Premium インスタンスを MySQL サービスに安全に接続できます。 MySQL サービスでプライベートエンドポイントが利用できない場合は、 [Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/premium/set-up-sink-private-endpoint-premium.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**を作成する時間 @@ -111,7 +111,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること 2. [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)を使用してTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスインスタンスからデータをエクスポートし、 [mydumper/myloader](https://centminmod.com/mydumper.html)などのコミュニティ ツールを使用してデータを MySQL サービスにロードします。 -3. [Dumplingのエクスポートファイル](https://docs.pingcap.com/tidb/stable/dumpling-overview#format-of-exported-files)のメタデータ ファイルから MySQL シンクの開始位置を取得します。 +3. [Dumplingのエクスポートファイル](https://docs.pingcap.com/tidb/stable/dumpling-overview#format-of-exported-files)のメタデータファイルから MySQL シンクの開始位置を取得します。 以下はメタデータファイルの例の一部です。 `Pos`の`SHOW MASTER STATUS`は、既存データの TSO であり、MySQL シンクの開始位置でもあります。 @@ -131,7 +131,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること 前提条件を満たしたら、データをMySQLに取り込むことができます。 -1. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスの概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[変更フィード]**をクリックします。 +1. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Premiumインスタンスの概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[変更フィード]**をクリックします。 2. **Create Changefeed**をクリックし、**宛先**として**MySQL**を選択します。 @@ -167,10 +167,9 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること 8. **Start Replication Position**で、MySQLシンクの開始位置を設定します。 - - Dumplingを使用して[既存のデータをロードした](#load-existing-data-optional)場合は、 **[特定の TSO からレプリケーションを開始する]**を選択し、 Dumpling のエクスポートされたメタデータ ファイルから取得した TSO を入力します。 + - Dumplingを使用して[既存のデータをロードした](#load-existing-data-optional)場合は、 **[特定の TSO からレプリケーションを開始する]**を選択し、 Dumpling のエクスポートされたメタデータファイルから取得した TSO を入力します。 - アップストリームの TiDB にデータがない場合は、 **今すぐレプリケーションを開始する**を選択してください。 - それ以外の場合は、 **特定の時間からレプリケーションを開始する**を選択して、開始時刻をカスタマイズできます。 - 9. **次へ**をクリックして、変更フィードの仕様を設定してください。 - **Changefeed Specification**領域で、チェンジフィードで使用する複製容量単位（RCU）チェンジフィードチェンジフィード容量ユニット（CCU）の数を指定します。 diff --git a/tidb-cloud/changefeed-sink-to-tidb-cloud.md b/tidb-cloud/changefeed-sink-to-tidb-cloud.md index 020d7f709a0c9..8e86764ab25de 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**を作成する時間 @@ -49,7 +49,7 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから 2. [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)を使用してTiDB Cloud Dedicatedクラスターからデータをエクスポートし、 [インポート機能](/tidb-cloud/import-csv-files-serverless.md)を使用して宛先のTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにデータをロードします。 -3. [Dumplingのエクスポートファイル](https://docs.pingcap.com/tidb/stable/dumpling-overview#format-of-exported-files)のメタデータ ファイルからTiDB Cloudシンクの開始位置を取得します。 +3. [Dumplingのエクスポートファイル](https://docs.pingcap.com/tidb/stable/dumpling-overview#format-of-exported-files)のメタデータファイルからTiDB Cloudシンクの開始位置を取得します。 以下はメタデータファイルの例の一部です。 `Pos`の`SHOW MASTER STATUS`は、既存データの TSO であり、 TiDB Cloudシンクの開始位置でもあります。 diff --git a/tidb-cloud/cli-reference.md b/tidb-cloud/cli-reference.md index 7d83dc026d8bf..5d68b067efb80 100644 --- a/tidb-cloud/cli-reference.md +++ b/tidb-cloud/cli-reference.md @@ -13,7 +13,7 @@ TiDB Cloud CLIはコマンドラインインターフェースであり、ター ## 始める前に {#before-you-begin} -必ず最初に[TiDB Cloud CLI環境をセットアップする](/tidb-cloud/get-started-with-cli.md)。 `ticloud` CLI をインストールすると、それを使用してコマンド ラインからTiDB Cloud StarterインスタンスとEssentialインスタンスを管理できるようになります。 +必ず最初に[TiDB Cloud CLI環境をセットアップする](/tidb-cloud/get-started-with-cli.md)。 `ticloud` CLI をインストールすると、それを使用してコマンドラインからTiDB Cloud StarterインスタンスとEssentialインスタンスを管理できるようになります。 ## 使用可能なコマンド {#commands-available} diff --git a/tidb-cloud/configure-external-storage-access.md b/tidb-cloud/configure-external-storage-access.md index a1da71fa2f04d..1421dacb8181b 100644 --- a/tidb-cloud/configure-external-storage-access.md +++ b/tidb-cloud/configure-external-storage-access.md @@ -28,7 +28,7 @@ TiDB Cloud Starter、 Essential、またはPremiumインスタンスがAmazon S3 1. 対象のTiDB Cloud Starter、 Essential、またはPremiumインスタンスの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 - 2. 対象のTiDB Cloud Starter、 Essential、または Premium インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート]**をクリックします。 + 2. 対象のTiDB Cloud Starter、 Essential、または Premium インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート]**をクリックします。 2. **Add New ARN**ダイアログを開きます。 @@ -128,7 +128,7 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 - `"Resource": "//*"` 、ここで``はエクスポートされたデータのターゲットディレクトリ、またはインポートされたデータのソースディレクトリです。例: - - インポートまたはエクスポートするデータが`tidb-cloud-source-data`バケットのルート ディレクトリにある場合は、 `"Resource": "arn:aws:s3:::tidb-cloud-source-data/*"`を使用してください。 + - インポートまたはエクスポートするデータが`tidb-cloud-source-data`バケットのルートディレクトリにある場合は、 `"Resource": "arn:aws:s3:::tidb-cloud-source-data/*"`を使用してください。 - インポートまたはエクスポートするデータがバケットの`mydata`ディレクトリにある場合は、 `"Resource": "arn:aws:s3:::tidb-cloud-source-data/mydata/*"`を使用します。 TiDB Cloud がこのディレクトリ内のすべてのファイルにアクセスできるように、ディレクトリの末尾に`/*`が追加されていることを確認してください。 @@ -156,7 +156,7 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 3. AWS マネジメントコンソールで、 TiDB Cloudのアクセスロールを作成し、ロール ARN を取得します。 - 1. [IAMコンソール](https://console.aws.amazon.com/iam/)で、左側のナビゲーション ペインの**[ロール]**をクリックし、 **Create role**をクリックします。 + 1. [IAMコンソール](https://console.aws.amazon.com/iam/)で、左側のナビゲーションペインの**[ロール]**をクリックし、 **Create role**をクリックします。 ![Create a role](/media/tidb-cloud/aws-create-role.png) @@ -164,8 +164,7 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 - **Trusted entity type**で**AWS account**を選択します。 - **AWSアカウント**で**Another AWS account**を選択し、 TiDB CloudアカウントIDを**Account ID**フィールドに貼り付けます。 - - **[オプション]**で、 **[外部 ID が必要 (サードパーティがこの役割を引き受ける場合のベスト プラクティス)]**をクリックし、 TiDB Cloud外部 ID を**External ID**フィールドに貼り付けます。ロールが外部IDを必須とせずに作成された場合、プロジェクト内のいずれかのTiDB Cloud StarterまたはEssentialインスタンスの設定が完了すると、そのプロジェクト内のすべてのTiDB Cloud StarterおよびEssentialインスタンスは同じロールARNを使用してAmazon S3バケットにアクセスできます。ロールがアカウントIDと外部IDの両方を使用して作成された場合、対応するTiDB Cloud StarterまたはEssentialインスタンスのみがバケットにアクセスできます。 - + - **[オプション]**で、 **[外部 ID が必要 (サードパーティがこの役割を引き受ける場合のベストプラクティス)]**をクリックし、 TiDB Cloud外部 ID を**External ID**フィールドに貼り付けます。ロールが外部IDを必須とせずに作成された場合、プロジェクト内のいずれかのTiDB Cloud StarterまたはEssentialインスタンスの設定が完了すると、そのプロジェクト内のすべてのTiDB Cloud StarterおよびEssentialインスタンスは同じロールARNを使用してAmazon S3バケットにアクセスできます。ロールがアカウントIDと外部IDの両方を使用して作成された場合、対応するTiDB Cloud StarterまたはEssentialインスタンスのみがバケットにアクセスできます。 3. **次へ**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**次へ**をクリックします。 4. **Role details**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 @@ -190,7 +189,7 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 > **Note:** > -> TiDB Cloudはアクセス キーを保存しません。インポートまたはエクスポートが完了したら[アクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)ことをお勧めします。 +> TiDB Cloudはアクセスキーを保存しません。インポートまたはエクスポートが完了したら[アクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)ことをお勧めします。 @@ -200,7 +199,7 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア サービスアカウントキーを設定するには、以下の手順に従ってください。 -1. Google Cloud サービス[サービスアカウントページ](https://console.cloud.google.com/iam-admin/serviceaccounts)ページで、 **CREATE SERVICE ACCOUNT**をクリックしてサービス アカウントを作成します。詳細については、 [サービスアカウントの作成](https://cloud.google.com/iam/docs/creating-managing-service-accounts)を参照してください。 +1. Google Cloud サービス[サービスアカウントページ](https://console.cloud.google.com/iam-admin/serviceaccounts)ページで、 **CREATE SERVICE ACCOUNT**をクリックしてサービスアカウントを作成します。詳細については、 [サービスアカウントの作成](https://cloud.google.com/iam/docs/creating-managing-service-accounts)を参照してください。 1. サービスアカウント名を入力してください。 @@ -225,7 +224,7 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア ![service-account-key](/media/tidb-cloud/serverless-external-storage/gcs-service-account-key.png) -3. デフォルトのキータイプ`JSON`を選択し、 **[作成]**をクリックして Google Cloud 認証情報ファイルをダウンロードします。このファイルには、TiDB Cloud StarterまたはEssentialインスタンスの GCS アクセスを設定する際に使用する必要のあるサービス アカウント キーが含まれています。 +3. デフォルトのキータイプ`JSON`を選択し、 **[作成]**をクリックして Google Cloud 認証情報ファイルをダウンロードします。このファイルには、TiDB Cloud StarterまたはEssentialインスタンスの GCS アクセスを設定する際に使用する必要のあるサービスアカウント キーが含まれています。 diff --git a/tidb-cloud/configure-maintenance-window.md b/tidb-cloud/configure-maintenance-window.md index f67eaa9cdca9f..005ba30b26df8 100644 --- a/tidb-cloud/configure-maintenance-window.md +++ b/tidb-cloud/configure-maintenance-window.md @@ -1,6 +1,6 @@ --- title: Configure Maintenance Window -summary: TiDB Cloud Dedicatedクラスターのメンテナンス ウィンドウを設定する方法を学びましょう。 +summary: TiDB Cloud Dedicatedクラスターのメンテナンスウィンドウを設定する方法を学びましょう。 --- # メンテナンスウィンドウの設定 {#configure-maintenance-window} diff --git a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md index a98e6fdce1f09..5b9a0082eb1b5 100644 --- a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md +++ b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md @@ -13,7 +13,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスへの ## 公開エンドポイント {#public-endpoints} -TiDB Cloud StarterまたはEssentialインスタンスでパブリック アクセスを設定すると、パブリック エンドポイント経由でインスタンスにアクセスできるようになります。つまり、 TiDB Cloud StarterまたはEssentialインスタンスはインターネット経由でアクセス可能になります。パブリック エンドポイントは、公開されている DNS アドレスです。「承認済みネットワーク」とは、TiDB Cloud StarterまたはEssentialインスタンスへのアクセスを許可する IP アドレスの範囲を指します。これらのアクセス許可は、**ファイアウォール ルール**によって適用されます。 +TiDB Cloud StarterまたはEssentialインスタンスでパブリックアクセスを設定すると、パブリックエンドポイント経由でインスタンスにアクセスできるようになります。つまり、 TiDB Cloud StarterまたはEssentialインスタンスはインターネット経由でアクセス可能になります。パブリックエンドポイントは、公開されている DNS アドレスです。「承認済みネットワーク」とは、TiDB Cloud StarterまたはEssentialインスタンスへのアクセスを許可する IP アドレスの範囲を指します。これらのアクセス許可は、**ファイアウォールルール**によって適用されます。 ### 公共アクセスの特徴 {#characteristics-of-public-access} @@ -37,7 +37,7 @@ TiDB Cloud はこのリストを定期的に更新し、予約済みの IP ア ## ファイアウォールルールの作成と管理 {#create-and-manage-a-firewall-rule} -このセクションでは、TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのファイアウォール ルールを管理する方法について説明します。パブリック エンドポイントを使用する場合、インスタンスへの接続はファイアウォール ルールで指定された IP アドレスに制限されます。 +このセクションでは、TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのファイアウォールルールを管理する方法について説明します。パブリックエンドポイントを使用する場合、インスタンスへの接続はファイアウォールルールで指定された IP アドレスに制限されます。 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにファイアウォールルールを追加するには、次の手順を実行します。 diff --git a/tidb-cloud/configure-sql-users.md b/tidb-cloud/configure-sql-users.md index 02338fe8fe4cc..25eaf364aedf2 100644 --- a/tidb-cloud/configure-sql-users.md +++ b/tidb-cloud/configure-sql-users.md @@ -5,14 +5,13 @@ summary: TiDB Cloudコンソールでデータベースユーザーとロール # データベースのユーザーと役割を管理する {#manage-database-users-and-roles} -このドキュメントでは[TiDB Cloudコンソール](https://tidbcloud.com/)の**SQL Users**ページを使用してデータベース ユーザーとロールを管理する方法について説明します。 +このドキュメントでは[TiDB Cloudコンソール](https://tidbcloud.com/)の**SQL Users**ページを使用してデータベースユーザーとロールを管理する方法について説明します。 > **Note:** > > - **SQL Users**ページはパブリックプレビューであり、リクエストがあった場合のみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)**？**をクリックし、**Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、 **Description**フィールドに「SQLユーザーページの申請」と入力して、 **Submit**をクリックします。 -> - データベースのユーザーと役割[組織およびプロジェクトのユーザーと役割](/tidb-cloud/manage-user-access.md)から独立しています。データベース ユーザーは TiDB クラスター内のデータベースにアクセスするために使用され、組織およびプロジェクト ユーザーは[TiDB Cloudコンソール](https://tidbcloud.com/)内の組織およびプロジェクトにアクセスするために使用されます。 -> - **SQL Users**ページに加えて、SQL クライアントを使用してクラスターに接続し、SQL ステートメントを作成することによって、データベース ユーザーとロールを管理することもできます。詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/dev/user-account-management)を参照してください。 - +> - データベースのユーザーと役割[組織およびプロジェクトのユーザーと役割](/tidb-cloud/manage-user-access.md)から独立しています。データベースユーザーは TiDB クラスター内のデータベースにアクセスするために使用され、組織およびプロジェクト ユーザーは[TiDB Cloudコンソール](https://tidbcloud.com/)内の組織およびプロジェクトにアクセスするために使用されます。 +> - **SQL Users**ページに加えて、SQL クライアントを使用してクラスターに接続し、SQL ステートメントを作成することによって、データベースユーザーとロールを管理することもできます。詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/dev/user-account-management)を参照してください。 ## データベースユーザーの役割 {#roles-of-database-users} TiDB Cloudでは、ロールベースのアクセス制御のために、組み込みロールと複数のカスタムロール（利用可能な場合）の両方をSQLユーザーに付与できます。 @@ -33,7 +32,7 @@ SQLユーザーに組み込みロールと複数のカスタムロールの両 ## 前提条件 {#prerequisites} -- **SQL Users**ページを使用してデータベース ユーザーとロールを管理するには、組織の`Organization Owner`ロール、またはプロジェクトの`Project Owner`ロールに属している必要があります。 +- **SQL Users**ページを使用してデータベースユーザーとロールを管理するには、組織の`Organization Owner`ロール、またはプロジェクトの`Project Owner`ロールに属している必要があります。 - プロジェクトの`Project Data Access Read-Write`または`Project Data Access Read-Only`ロールに属している場合、データベースユーザーはそのプロジェクトの**SQL Users**ページでのみ表示できます。 ## SQLユーザーを確認する {#view-sql-users} diff --git a/tidb-cloud/connect-to-tidb-cluster.md b/tidb-cloud/connect-to-tidb-cluster.md index ff43272327254..473351837ca0c 100644 --- a/tidb-cloud/connect-to-tidb-cluster.md +++ b/tidb-cloud/connect-to-tidb-cluster.md @@ -22,19 +22,19 @@ TiDB Cloud Dedicatedクラスタが作成されたら、以下のいずれかの - [パブリック接続](/tidb-cloud/connect-via-standard-connection.md) - パブリック接続はトラフィック フィルターを備えたパブリック エンドポイントを公開するため、ラップトップから SQL クライアント経由で TiDB クラスターに接続できます。 TLS を使用して TiDB クラスターに接続できます。これにより、アプリケーションから TiDB クラスターへのデータ送信のセキュリティが確保されます。詳細については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 + パブリック接続はトラフィックフィルターを備えたパブリックエンドポイントを公開するため、ラップトップから SQL クライアント経由で TiDB クラスターに接続できます。 TLS を使用して TiDB クラスターに接続できます。これにより、アプリケーションから TiDB クラスターへのデータ送信のセキュリティが確保されます。詳細については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 - プライベートエンドポイント（推奨） プライベートエンドポイント接続は、VPC内のSQLクライアントがTiDB Cloud Dedicatedクラスターに安全にアクセスできるようにするためのプライベートエンドポイントを提供します。これは、さまざまなクラウドプロバイダーが提供するプライベートリンクサービスを利用しており、ネットワーク管理を簡素化しながら、データベースサービスへの高度に安全な一方向アクセスを実現します。 - - AWS でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は AWS PrivateLink を使用します。詳細については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 - - Azure 上でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は Azure Private Link を使用します。詳細については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)を参照してください。 - - Google Cloud でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は Google Cloud Private Service Connect を使用します。詳細については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 + - AWS でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベートエンドポイント接続は AWS PrivateLink を使用します。詳細については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 + - Azure 上でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベートエンドポイント接続は Azure Private Link を使用します。詳細については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)を参照してください。 + - Google Cloud でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベートエンドポイント接続は Google Cloud Private Service Connect を使用します。詳細については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 - [VPCピアリング](/tidb-cloud/set-up-vpc-peering-connections.md) - レイテンシーを短縮し、セキュリティを強化したい場合は、VPC ピアリングを設定し、クラウド アカウント内の対応するクラウド プロバイダー上の VM インスタンスを使用してプライベート エンドポイント経由で接続します。詳細については、 [VPCピアリング経由でTiDB Cloud Dedicatedに接続します](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 + レイテンシーを短縮し、セキュリティを強化したい場合は、VPC ピアリングを設定し、クラウドアカウント内の対応するクラウドプロバイダー上の VM インスタンスを使用してプライベートエンドポイント経由で接続します。詳細については、 [VPCピアリング経由でTiDB Cloud Dedicatedに接続します](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 - [組み込みSQLエディタ](/tidb-cloud/explore-data-with-chat2query.md) diff --git a/tidb-cloud/connect-via-standard-connection-serverless.md b/tidb-cloud/connect-via-standard-connection-serverless.md index a983e4e9fc619..8970ecef62537 100644 --- a/tidb-cloud/connect-via-standard-connection-serverless.md +++ b/tidb-cloud/connect-via-standard-connection-serverless.md @@ -18,7 +18,7 @@ TiDB Cloudプランに応じて、適切なエンドポイントモデルを選 > **Tip:** > -> パブリック エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 +> パブリックエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 共有モデルを使用してパブリックエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続するには、以下の手順を実行してください。 @@ -45,11 +45,11 @@ TiDB Cloudプランに応じて、適切なエンドポイントモデルを選 > **Note:** > > - 接続タイプを`Public`のままにすると、接続が標準の TLS 接続を介して行われることを意味します。詳細については、 [TiDB Cloud StarterまたはEssentialへのTLS接続](/tidb-cloud/secure-connections-to-serverless-clusters.md)を参照してください。 - > - **Private Endpoint**ドロップダウン リストで**Connection Type**を選択した場合、接続がプライベート エンドポイント経由であることを意味します。詳細については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 + > - **Private Endpoint**ドロップダウンリストで**Connection Type**を選択した場合、接続がプライベートエンドポイント経由であることを意味します。詳細については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 -4. TiDB Cloudでは、TiDB Cloud Starterインスタンス用に[ブランチ](https://docs.pingcap.com/tidbcloud/branch-overview/?plan=starter)を作成できます。ブランチが作成されると、**ブランチの**ドロップダウン リストからブランチに接続できます。 `main` TiDB Cloud Starterインスタンス自体を表します。 +4. TiDB Cloudでは、TiDB Cloud Starterインスタンス用に[ブランチ](https://docs.pingcap.com/tidbcloud/branch-overview/?plan=starter)を作成できます。ブランチが作成されると、**ブランチの**ドロップダウンリストからブランチに接続できます。 `main` TiDB Cloud Starterインスタンス自体を表します。 5. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。生成されたパスワードは二度と表示されませんので、安全な場所に保存してください。 @@ -57,7 +57,7 @@ TiDB Cloudプランに応じて、適切なエンドポイントモデルを選 > **Note:** > - > TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続するときは、ユーザー名にTiDB Cloud Starterまたは TiDB Cloud Essentialインスタンスのプレフィックスを含め、名前を引用符で囲む必要があります。詳細については、 [ユーザー名の接頭辞](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を参照してください。クライアント IP は、TiDB Cloud StarterまたはEssentialインスタンスのパブリック エンドポイントの許可された IP ルールに含まれている必要があります。詳細については、 [パブリックエンドポイント向けにTiDB Cloud StarterまたはEssential Firewallルールを設定する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)を参照してください。 + > TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続するときは、ユーザー名にTiDB Cloud Starterまたは TiDB Cloud Essentialインスタンスのプレフィックスを含め、名前を引用符で囲む必要があります。詳細については、 [ユーザー名の接頭辞](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を参照してください。クライアント IP は、TiDB Cloud StarterまたはEssentialインスタンスのパブリックエンドポイントの許可された IP ルールに含まれている必要があります。詳細については、 [パブリックエンドポイント向けにTiDB Cloud StarterまたはEssential Firewallルールを設定する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)を参照してください。 ## 公開エンドポイント経由で接続します（エンドポイント占有モデル） {#connect-via-a-public-endpoint-endpoint-exclusive-model} diff --git a/tidb-cloud/connected-care-overview.md b/tidb-cloud/connected-care-overview.md index 6033fa1b1ab5e..5ee56e8d9373f 100644 --- a/tidb-cloud/connected-care-overview.md +++ b/tidb-cloud/connected-care-overview.md @@ -1,6 +1,6 @@ --- title: Connected Care Overview -summary: 新しい世代のTiDB Cloudサポート サービスである Connected Care を紹介します。 +summary: 新しい世代のTiDB Cloudサポートサービスである Connected Care を紹介します。 aliases: ['/ja/tidbcloud/connected-care-announcement'] --- @@ -16,11 +16,11 @@ 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** > -> **Basic** 、 **Enterprise** 、および**Premium の**サポート プランでは、従来のプランと同じプラン名が使用されていますが、サービス コミットメントが異なる異なるプランを指します。 +> **Basic** 、 **Enterprise** 、および**Premium の**サポートプランでは、従来のプランと同じプラン名が使用されていますが、サービス コミットメントが異なる異なるプランを指します。 以下の表は、Connected Careサービスの各サポートプランの概要を示しています。詳細については、 [Connected Careの詳細](/tidb-cloud/connected-care-detail.md)ご覧ください。 @@ -39,11 +39,11 @@ 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} -Connected Care サービスのサポート プランでは、次のようなまったく新しい機能セットが導入されています。 +Connected Care サービスのサポートプランでは、次のようなまったく新しい機能セットが導入されています。 - Connected: Clinic Service @@ -67,15 +67,15 @@ Connected Care サービスのサポート プランでは、次のようなま これらの新機能により、Connected Care サービスは、より優れた接続性、よりパーソナライズされたサポート、さまざまな顧客ニーズに対応するコスト効率の高いソリューションを提供します。 -- 新しい**Enterprise**および**Premium**プラン: Clinic の高度な監視サービス、 TiDB Cloudアラートの IM サブスクリプション、チケット更新の IM サブスクリプション、IM での AI チャット、サポート チケットの IM 対話を通じて、最新のコミュニケーション ツールと高度な AI 機能を提供します。 +- 新しい**Enterprise**および**Premium**プラン: Clinic の高度な監視サービス、 TiDB Cloudアラートの IM サブスクリプション、チケット更新の IM サブスクリプション、IM での AI チャット、サポートチケットの IM 対話を通じて、最新のコミュニケーション ツールと高度な AI 機能を提供します。 -- 新しい**Developer**プラン:**Basic**プランと同じコミュニティ チャネル ( [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap)と[Discord](https://discord.com/invite/KVRZBR2DrG) ) と[TiDB.AI](https://tidb.ai/)サポートへのアクセスに加え、直接接続とテクニカル サポートへの無制限のアクセスが提供されます。 +- 新しい**Developer**プラン:**Basic**プランと同じコミュニティ チャネル ( [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap)と[Discord](https://discord.com/invite/KVRZBR2DrG) ) と[TiDB.AI](https://tidb.ai/)サポートへのアクセスに加え、直接接続とテクニカルサポートへの無制限のアクセスが提供されます。 - 新しい**Basic**プラン: コミュニティ チャネル ( [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap)と[Discord](https://discord.com/invite/KVRZBR2DrG) ) に参加して他のコミュニティ メンバーと交流したり、 [TiDB.AI](https://tidb.ai/)を使用して技術サポートを受けることができます。 ## Connected Careへの移行 {#transition-to-connected-care} -次の表に、従来のサポート プランのシャットダウン スケジュールを示します。 +次の表に、従来のサポートプランのシャットダウン スケジュールを示します。 | サポートプラン | シャットダウン日 | | :----------------------------- | :--------- | @@ -87,7 +87,7 @@ Connected Care サービスのサポート プランでは、次のようなま ## よくある質問 {#faqs} -### 現在のサポート プランを確認または変更するにはどうすればよいですか? {#how-do-i-check-or-make-changes-to-my-current-support-plan} +### 現在のサポートプランを確認または変更するにはどうすればよいですか? {#how-do-i-check-or-make-changes-to-my-current-support-plan} [TiDB Cloudコンソール](https://tidbcloud.com/)で、左下隅の**Support**をクリックします。**Support** ページが表示され、現在のサポートプランが**CURRENT**タグで強調表示されます。 @@ -97,6 +97,6 @@ Connected Care サービスのサポート プランでは、次のようなま 新しいConnected Careサービスは、より包括的で豊富な機能を備えたサポートエクスペリエンスを提供しますが、価格は従来のサービスとほぼ同等です。TiDB Cloudは、お客様のビジネスをより良くサポートするために、付加価値の提供に引き続き尽力してまいります。 -### 従来の**Basic**プランが終了した後、テクニカル サポートを受けるにはどうすればよいですか? {#how-can-i-get-technical-support-after-the-legacy-basic-plan-shuts-down} +### 従来の**Basic**プランが終了した後、テクニカルサポートを受けるにはどうすればよいですか? {#how-can-i-get-technical-support-after-the-legacy-basic-plan-shuts-down} [請求とアカウントサポート](/tidb-cloud/tidb-cloud-support.md#create-an-account-or-billing-support-ticket)には引き続きアクセスできます。テクニカルサポートをご希望の場合は、Connected Care サービスのサポートプランのご購入をご検討ください。1ヶ月の無料トライアルが含まれる**Developer**プランから始めることをお勧めします。 diff --git a/tidb-cloud/connected-lark-ticket-creation.md b/tidb-cloud/connected-lark-ticket-creation.md index 757a1ece09ce2..23dae201a0d0d 100644 --- a/tidb-cloud/connected-lark-ticket-creation.md +++ b/tidb-cloud/connected-lark-ticket-creation.md @@ -41,4 +41,4 @@ TiDB Cloud **Enterprise** [サポートプラン](/tidb-cloud/connected-care-det ## サポートにお問い合わせください {#contact-support} -ヘルプや質問がある場合は、サポート チーム[support@pi​​ngcap.com](mailto:support@pingcap.com)にお問い合わせください。 +ヘルプや質問がある場合は、サポートチーム[support@pi​​ngcap.com](mailto:support@pingcap.com)にお問い合わせください。 diff --git a/tidb-cloud/connected-lark-ticket-interaction.md b/tidb-cloud/connected-lark-ticket-interaction.md index 13ba463ea2cf8..18839be43ccaf 100644 --- a/tidb-cloud/connected-lark-ticket-interaction.md +++ b/tidb-cloud/connected-lark-ticket-interaction.md @@ -5,7 +5,7 @@ summary: サポートチケットのLarkインタラクションに関する詳 # Lark経由でサポートチケットとやり取りする {#interact-with-support-tickets-via-lark} -**Premium** [サポートプラン](/tidb-cloud/connected-care-detail.md)に加入している顧客向けに、 TiDB Cloud は、サポート チケットのより包括的なやり取りと管理をサポートするために、 [Lark](https://www.larksuite.com/)で**PingCAP Support Bot**と呼ばれるチケット ボットを提供します。 +**Premium** [サポートプラン](/tidb-cloud/connected-care-detail.md)に加入している顧客向けに、 TiDB Cloud は、サポートチケットのより包括的なやり取りと管理をサポートするために、 [Lark](https://www.larksuite.com/)で**PingCAP Support Bot**と呼ばれるチケット ボットを提供します。 > **Note:** > @@ -21,7 +21,7 @@ Lark の**PingCAP Support Group**に[サポートチケットを作成する](/t サポートエンジニアがチケットに返信すると、その返信はLarkのメッセージスレッドに同期されます。サポートポータルにアクセスすることなく、スレッド内で直接返信内容を確認したり、返信を送信したりできます。返信はチケットシステムにも同期されます。 -この機能を使用すると、**Premium**サポート プランに加入すると、Lark を離れることなく、チケットをすばやく作成、応答、管理できます。 +この機能を使用すると、**Premium**サポートプランに加入すると、Lark を離れることなく、チケットをすばやく作成、応答、管理できます。 ![lark-ticket-interaction-2](/media/tidb-cloud/connected-lark-ticket-interaction-2.png) @@ -33,4 +33,4 @@ Lark の**PingCAP Support Group**に[サポートチケットを作成する](/t ## サポートにお問い合わせください {#contact-support} -ヘルプや質問がある場合は、サポート チーム[support@pi​​ngcap.com](mailto:support@pingcap.com)にお問い合わせください。 +ヘルプや質問がある場合は、サポートチーム[support@pi​​ngcap.com](mailto:support@pingcap.com)にお問い合わせください。 diff --git a/tidb-cloud/connected-slack-ticket-creation.md b/tidb-cloud/connected-slack-ticket-creation.md index 2093134722406..6d43abeb80b44 100644 --- a/tidb-cloud/connected-slack-ticket-creation.md +++ b/tidb-cloud/connected-slack-ticket-creation.md @@ -41,4 +41,4 @@ Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンショ ## サポートにお問い合わせください {#contact-support} -ヘルプや質問がある場合は、 [support@pingcap.com](mailto:support@pingcap.com)のサポート チームにお問い合わせください。 +ヘルプや質問がある場合は、 [support@pingcap.com](mailto:support@pingcap.com)のサポートチームにお問い合わせください。 diff --git a/tidb-cloud/connected-slack-ticket-interaction.md b/tidb-cloud/connected-slack-ticket-interaction.md index 54ed9de696f01..b90bcc97de13d 100644 --- a/tidb-cloud/connected-slack-ticket-interaction.md +++ b/tidb-cloud/connected-slack-ticket-interaction.md @@ -1,21 +1,21 @@ --- title: Interact with Support Tickets via Slack -summary: サポート チケットの Slack でのやり取りに関する詳細情報を紹介します。 +summary: サポートチケットの Slack でのやり取りに関する詳細情報を紹介します。 --- # Slack経由でサポートチケットとやり取りする {#interact-with-support-tickets-via-slack} -**Premium** [サポートプラン](/tidb-cloud/connected-care-detail.md)に加入している顧客向けに、 TiDB Cloud は、サポート チケットのより包括的なやり取りと管理をサポートするために、 [Slack](https://slack.com/)で**PingCAP Support Bot**と呼ばれるチケット ボットを提供します。 +**Premium** [サポートプラン](/tidb-cloud/connected-care-detail.md)に加入している顧客向けに、 TiDB Cloud は、サポートチケットのより包括的なやり取りと管理をサポートするために、 [Slack](https://slack.com/)で**PingCAP Support Bot**と呼ばれるチケット ボットを提供します。 > **Note:** > > Slackのチケットサポート機能はリクエストに応じてご利用いただけます。この機能をご利用になりたい場合は、 TiDB Cloudサポート[support@pingcap.com](mailto:support@pingcap.com)までご連絡いただくか、担当のテクニカルアカウントマネージャー（TAM）までお問い合わせください。 -**PingCAP Support Bot**を使用して Slack でサポート チケットを作成できます。 +**PingCAP Support Bot**を使用して Slack でサポートチケットを作成できます。 ![Create a support ticket in Slack](/media/tidb-cloud/connected-slack-ticket-interaction-creation.gif) -Slack でサポート チケットに直接返信することもできます。 +Slack でサポートチケットに直接返信することもできます。 ![Reply to a support ticket in Slack](/media/tidb-cloud/connected-slack-ticket-interaction-reply.gif) @@ -37,7 +37,7 @@ Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンショ サポートエンジニアのチケットへのコメントはSlackのメッセージスレッドに同期されるため、ユーザーはサポートポータルに移動してコメントを確認する必要はありません。ユーザーはこのメッセージスレッドに直接返信することができ、返信はチケットシステムに同期されます。 -これにより、**Premium**サポート プランに加入している顧客は、Slack を離れることなく、チケットをすばやく作成、対応、管理できるようになります。 +これにより、**Premium**サポートプランに加入している顧客は、Slack を離れることなく、チケットをすばやく作成、対応、管理できるようになります。 ![slack-ticket-interaction-4](/media/tidb-cloud/connected-slack-ticket-interaction-4.png) @@ -49,4 +49,4 @@ Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンショ ## サポートにお問い合わせください {#contact-support} -ヘルプや質問がある場合は、 [support@pingcap.com](mailto:support@pingcap.com)のサポート チームにお問い合わせください。 +ヘルプや質問がある場合は、 [support@pingcap.com](mailto:support@pingcap.com)のサポートチームにお問い合わせください。 diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 485e8ed07a477..bc35ab7645ce8 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -56,7 +56,7 @@ summary: TiDB Cloudのインポートデータサービスで CSV 構成を使 次のフィールドを例に挙げます。 - - 値が`True`の場合、 `"nick name is \"Mike\""` `nick name is "Mike"`として解析され、ターゲット テーブルに書き込まれます。 + - 値が`True`の場合、 `"nick name is \"Mike\""` `nick name is "Mike"`として解析され、ターゲットテーブルに書き込まれます。 - 値が`False`の場合、 `"nick name is \"` 、 `Mike\` 、 `""`の3つのフィールドとして解析されます。しかし、フィールドが互いに分離されていないため、正しく解析できません。 標準CSVファイルの場合、記録するフィールドに二重引用符で囲まれた文字が含まれている場合は、エスケープ処理のために二重引用符を2つ使用する必要があります。この場合、`Backslash escape = True`を使用すると解析エラーが発生しますが、 `Backslash escape = False`を使用すると正しく解析されます。典型的なシナリオは、インポートされたフィールドにJSONコンテンツが含まれている場合です。標準CSVのJSONフィールドは通常、次のように保存されます。 diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 38d25bd233403..0ec54bf5b0e08 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -26,7 +26,7 @@ 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リクエストは、制限に関する以下のヘッダーを返します。 @@ -89,7 +89,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access > **Tip:** > - > 複数のプロジェクトがある場合は、目的のプロジェクトの**Data Service**ページに移動するには、[**My TiDB**](https://tidbcloud.com/tidbs)ページの**[プロジェクト ビュー]**タブをクリックし、目的のプロジェクトの [ **...** ] をクリックしてから、 **[Data Service]**をクリックします。 + > 複数のプロジェクトがある場合は、目的のプロジェクトの**Data Service**ページに移動するには、[**My TiDB**](https://tidbcloud.com/tidbs)ページの**[プロジェクトビュー]**タブをクリックし、目的のプロジェクトの [ **...** ] をクリックしてから、 **[Data Service]**をクリックします。 2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 @@ -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..ede21a3d59e0a 100644 --- a/tidb-cloud/data-service-app-config-files.md +++ b/tidb-cloud/data-service-app-config-files.md @@ -1,6 +1,6 @@ --- title: Data App Configuration Files -summary: このドキュメントでは、TiDB Cloudのデータ アプリの構成ファイルについて説明します。 +summary: このドキュメントでは、TiDB Cloudのデータアプリの構成ファイルについて説明します。 --- # データアプリコンフィグレーションファイル {#data-app-configuration-files} @@ -169,7 +169,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 | `name` | string | エンドポイント名。 | | `description` | string | （オプション）エンドポイントの説明。 | | `method` | string | エンドポイントの HTTP メソッド。 `GET`を使用してデータを取得し、 `POST`を使用してデータを作成または挿入し、 `PUT`を使用してデータを更新または変更し、 `DELETE`を使用してデータを削除できます。 | -| `endpoint` | string | データ アプリ内のエンドポイントの一意のパス。パスには、文字、数字、アンダースコア ( `_` )、およびスラッシュ ( `/` ) のみを使用できます。パスはスラッシュ ( `/` ) で始まり、文字、数字、またはアンダースコア ( `_` ) で終わる必要があります。例: `/my_endpoint/get_id` 。パスの長さは 64 文字未満である必要があります。 | +| `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.name` | string | パラメータ名。名前には文字、数字、アンダースコアのみを使用できます（ `_` ）。また、文字またはアンダースコアで始まる必要があります（ `_` ）。 `page`および`page_size`はリクエスト結果のページネーション用に**予約されて**いるため、パラメータ名として使用しないでください。 | @@ -192,7 +192,7 @@ summary: このドキュメントでは、TiDB Cloudのデータ アプリの構 ### SQLファイル構成 {#sql-file-configuration} -エンドポイントの SQL ファイルには、エンドポイントを介してデータを照会するための SQL ステートメントが指定されています。データ アプリのエンドポイント SQL ファイルは`http_endpoints/sql/`ディレクトリにあります。各エンドポイントには、対応する SQL ファイルが必要です。 +エンドポイントの SQL ファイルには、エンドポイントを介してデータを照会するための SQL ステートメントが指定されています。データアプリのエンドポイント SQL ファイルは`http_endpoints/sql/`ディレクトリにあります。各エンドポイントには、対応する SQL ファイルが必要です。 SQL ファイルの名前は`-.sql`形式です。ここで、 ``と``は[`http_endpoints/config.json`](#endpoint-configuration)の`method`と`endpoint`の設定と一致する必要があります。 diff --git a/tidb-cloud/data-service-concepts.md b/tidb-cloud/data-service-concepts.md index 6d8005033e230..3cb5817bc0259 100644 --- a/tidb-cloud/data-service-concepts.md +++ b/tidb-cloud/data-service-concepts.md @@ -33,16 +33,16 @@ TiDB Cloudの Chat2Query API は、AI が指示を与えることで SQL 文を サードパーティ製ツールをデータアプリに統合することで、サードパーティ製ツールが提供する高度な自然言語処理機能と人工知能（AI）機能をアプリケーションに導入し、強化することができます。この統合により、アプリケーションはより複雑なタスクを実行し、インテリジェントなソリューションを提供できるようになります。 -現在、GPT や Dify などのサードパーティ ツールをTiDB Cloudコンソールに統合できます。 +現在、GPT や Dify などのサードパーティツールをTiDB Cloudコンソールに統合できます。 詳細については[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)を参照してください。 ## コードとしてのコンフィグレーション {#configuration-as-code} -TiDB Cloud は、 JSON 構文を使用してデータ アプリの構成全体をコードとして表現する、 コンフィグレーション as Code (CaC) アプローチを提供します。 +TiDB Cloud は、 JSON 構文を使用してデータアプリの構成全体をコードとして表現する、 コンフィグレーション as Code (CaC) アプローチを提供します。 -データ アプリを GitHub に接続することで、 TiDB Cloud はCaC アプローチを使用して、データ アプリの構成を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として優先 GitHub リポジトリおよびブランチにプッシュできます。 +データアプリを GitHub に接続することで、 TiDB Cloud はCaC アプローチを使用して、データアプリの構成を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として優先 GitHub リポジトリおよびブランチにプッシュできます。 GitHub接続で自動同期とデプロイが有効になっている場合は、GitHub上の設定ファイルを更新することでデータアプリを変更することもできます。設定ファイルの変更をGitHubにプッシュすると、新しい設定がTiDB Cloudに自動的にデプロイされます。 -詳細については[GitHub でデータ アプリを自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 +詳細については[GitHub でデータアプリを自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 diff --git a/tidb-cloud/data-service-custom-domain.md b/tidb-cloud/data-service-custom-domain.md index 9ba1f4093c1b5..5ec9909f4766e 100644 --- a/tidb-cloud/data-service-custom-domain.md +++ b/tidb-cloud/data-service-custom-domain.md @@ -41,7 +41,7 @@ TiDB Cloud Data Serviceは、各データアプリのエンドポイントにア > > DNSプロバイダーによっては、DNSレコードの検証に最大24時間かかる場合があります。カスタムドメインが24時間以上検証されない場合、 **期限切れ**ステータスになります。この場合、カスタムドメインを削除して再度試すしかありません。 -カスタム ドメインのステータスが**Success**に設定されると、それを使用してエンドポイントにアクセスできるようになります。 TiDB Cloud Data Serviceによって提供されるコード サンプルは、カスタム ドメインとパスに自動的に更新されます。詳細については、 [エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 +カスタムドメインのステータスが**Success**に設定されると、それを使用してエンドポイントにアクセスできるようになります。 TiDB Cloud Data Serviceによって提供されるコード サンプルは、カスタムドメインとパスに自動的に更新されます。詳細については、 [エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 ### カスタムドメインを編集する {#edit-a-custom-domain} diff --git a/tidb-cloud/data-service-get-started.md b/tidb-cloud/data-service-get-started.md index b4c3b65267cad..efcc6494da404 100644 --- a/tidb-cloud/data-service-get-started.md +++ b/tidb-cloud/data-service-get-started.md @@ -17,7 +17,7 @@ Data Service（PREVIEW）を使用すると、カスタムAPIエンドポイン ## 始める前に {#before-you-begin} -データ アプリを作成する前に、AWS でホストされる[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md)インスタンスを作成していることを確認してください。お持ちでない場合は、 [TiDB Cloud StarterまたはEssentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md)の手順に従って作成してください。 +データアプリを作成する前に、AWS でホストされる[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md)インスタンスを作成していることを確認してください。お持ちでない場合は、 [TiDB Cloud StarterまたはEssentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md)の手順に従って作成してください。 > **Note:** > @@ -27,7 +27,7 @@ Data Service（PREVIEW）を使用すると、カスタムAPIエンドポイン Data Serviceを使い始めるには、サンプルデータアプリを作成するのが最適です。プロジェクトにまだデータアプリがない場合は、**Data Service**ページの画面上の指示に従ってサンプルデータアプリを作成し、このアプリを使ってData Serviceの機能を試してみてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページの**[プロジェクト ビュー]**タブをクリックし、プロジェクトの [ **...]**をクリックして、 **[Data Service]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページの**[プロジェクトビュー]**タブをクリックし、プロジェクトの [ **...]**をクリックして、 **[Data Service]**をクリックします。 2. **Data Service**ページで、 **Create Sample Data App**をクリックします。ダイアログが表示されます。 @@ -51,7 +51,7 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 データアプリを作成するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページの**[プロジェクト ビュー]**タブをクリックし、プロジェクトの [ **...]**をクリックして、 **[Data Service]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページの**[プロジェクトビュー]**タブをクリックし、プロジェクトの [ **...]**をクリックして、 **[Data Service]**をクリックします。 2. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左側のペインで **Create DataApp**をクリックします。 @@ -63,7 +63,7 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 > **Note:** > - > デフォルトでは、データ アプリのタイプは**Standard Data App**です。 **Chat2Query Data App**を作成したい場合は、本書の代わりに[Chat2Query API を使い始めよう](/tidb-cloud/use-chat2query-api.md)を参照してください。 + > デフォルトでは、データアプリのタイプは**Standard Data App**です。 **Chat2Query Data App**を作成したい場合は、本書の代わりに[Chat2Query API を使い始めよう](/tidb-cloud/use-chat2query-api.md)を参照してください。 4. （オプション）データアプリのエンドポイントを、お好みのGitHubリポジトリとブランチに自動的にデプロイするには、 **Connect to GitHub**を有効にしてから、以下の手順を実行してください。 @@ -80,9 +80,9 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 5. **Create Data App**をクリックします。 [**Data Service**](https://tidbcloud.com/project/data-service)の詳細ページが表示されます。 -6. データ アプリを GitHub に接続するように構成している場合は、指定した GitHub ディレクトリを確認してください。データ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)`tidb-cloud-data-service`によってディレクトリにコミットされていることがわかります。これは、データアプリが GitHub に正常に接続されていることを意味します。 +6. データアプリを GitHub に接続するように構成している場合は、指定した GitHub ディレクトリを確認してください。データ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)`tidb-cloud-data-service`によってディレクトリにコミットされていることがわかります。これは、データアプリが GitHub に正常に接続されていることを意味します。 - 新しいデータ アプリでは、**Auto Sync & Deployment**および**Review Draft**がデフォルトで有効になっているため、 TiDB Cloudコンソールと GitHub の間でデータ アプリの変更を簡単に同期し、デプロイメント前に変更をレビューできます。 GitHub 統合の詳細については、 [GitHub を使用してデータ アプリの変更を自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 + 新しいデータアプリでは、**Auto Sync & Deployment**および**Review Draft**がデフォルトで有効になっているため、 TiDB Cloudコンソールと GitHub の間でデータアプリの変更を簡単に同期し、デプロイメント前に変更をレビューできます。 GitHub 統合の詳細については、 [GitHub を使用してデータアプリの変更を自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 ### ステップ2. エンドポイントを開発する {#step-2-develop-an-endpoint} @@ -96,7 +96,7 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 - **パス**：ユーザーがエンドポイントにアクセスするために使用するパス。リクエストメソッドとパスの組み合わせは、データアプリ内で一意である必要があります。 -- **Endpoint URL** : (読み取り専用) URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データ アプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`になります。 +- **Endpoint URL** : (読み取り専用) URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データアプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`になります。 - **Request Method**：エンドポイントの HTTP メソッド。 `GET`を使用してデータを取得し、 `POST`を使用してデータを作成または挿入し、 `PUT`を使用してデータを更新または変更し、 `DELETE`を使用してデータを削除できます。 @@ -110,7 +110,7 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 > **Note:** > - > データ アプリにリンクされているTiDB Cloud Starterインスタンスのみがドロップダウン リストに表示されます。リンクされたTiDB Cloud Starterインスタンスを管理するには、 [リンクされたデータソースを管理する](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)を参照してください。 + > データアプリにリンクされているTiDB Cloud Starterインスタンスのみがドロップダウンリストに表示されます。リンクされたTiDB Cloud Starterインスタンスを管理するには、 [リンクされたデータソースを管理する](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)を参照してください。 SQLエディタの上部にあるドロップダウンリストから、SQLステートメントを実行するTiDB Cloud Starterインスタンスを選択します。すると、右側のペインにある**スキーマ**タブで、そのTiDB Cloud Starterインスタンスのすべてのデータベースを表示できます。 @@ -191,7 +191,7 @@ HTTPSリクエストを送信することでエンドポイントを呼び出す #### 1. APIキーを作成する {#1-create-an-api-key} -1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、データ アプリの名前をクリックして詳細を表示します。 +1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、データアプリの名前をクリックして詳細を表示します。 2. **認証**エリアで、 **Create API Key**をクリックします。 diff --git a/tidb-cloud/data-service-integrations.md b/tidb-cloud/data-service-integrations.md index d7d337a2ea117..24e89f6c522be 100644 --- a/tidb-cloud/data-service-integrations.md +++ b/tidb-cloud/data-service-integrations.md @@ -25,9 +25,9 @@ summary: TiDB Cloudコンソールで、 TiDB CloudデータアプリをGPTやDi 4. 表示されたダイアログボックスには、以下の項目が表示されます。 - ａ． **API Specification URL** : データ アプリの OpenAPI 仕様の URL をコピーします。詳細については、 [OpenAPI仕様を使用する](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification)を参照してください。 + ａ． **API Specification URL** : データアプリの OpenAPI 仕様の URL をコピーします。詳細については、 [OpenAPI仕様を使用する](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification)を参照してください。 - b. **API Key**: データ アプリの API キーを入力します。 API キーをまだ持っていない場合は、 **Create API Key**をクリックして作成します。詳細については、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 + b. **API Key**: データアプリの API キーを入力します。 API キーをまだ持っていない場合は、 **Create API Key**をクリックして作成します。詳細については、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 c. **API Key Encoded**：提供したAPIキーに相当するbase64エンコードされた文字列をコピーします。 diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index 404d93fd36b36..b20c65f9585ce 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -1,6 +1,6 @@ --- title: Manage a Data App -summary: TiDB Cloudコンソールでデータ アプリを作成、表示、変更、削除する方法を学習します。 +summary: TiDB Cloudコンソールでデータアプリを作成、表示、変更、削除する方法を学習します。 --- # データアプリを管理する {#manage-a-data-app} @@ -11,31 +11,30 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ ## データアプリを作成する {#create-a-data-app} -プロジェクトのデータ アプリを作成するには、次の手順を実行します。 +プロジェクトのデータアプリを作成するには、次の手順を実行します。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左側のペインで**Create DataApp**。 > **Tip:** > - > これがプロジェクトの最初のデータ アプリである場合は、ページの中央にある**Create Data App**をクリックします。 + > これがプロジェクトの最初のデータアプリである場合は、ページの中央にある**Create Data App**をクリックします。 -2. 名前と説明を入力し、データ アプリがアクセスするクラスターを選択します。 +2. 名前と説明を入力し、データアプリがアクセスするクラスターを選択します。 > **Note:** > > デフォルトでは、データアプリの種類は**Standard Data App**です。**Chat2Query Data App**を作成する場合は、このドキュメントではなく[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)を参照してください。 -3. (オプション) データ アプリのエンドポイントを優先 GitHub リポジトリとブランチに自動的にデプロイするには、 **Connect to GitHub**を有効にして、次の操作を行います。 +3. (オプション) データアプリのエンドポイントを優先 GitHub リポジトリとブランチに自動的にデプロイするには、 **Connect to GitHub**を有効にして、次の操作を行います。 1. **Install on GitHub**をクリックし、画面の指示に従って、 **TiDB Cloud Data Service**をアプリケーションとしてターゲット リポジトリにインストールします。 2. **承認**をクリックして、GitHub 上のアプリケーションへのアクセスを承認します。 - 3. データ アプリの構成ファイルを保存するターゲット リポジトリ、ブランチ、ディレクトリを指定します。 - + 3. データアプリの構成ファイルを保存するターゲット リポジトリ、ブランチ、ディレクトリを指定します。 > **Note:** > > - ディレクトリはスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata` 。指定したディレクトリがターゲットリポジトリとブランチに存在しない場合は、自動的に作成されます。 > - リポジトリ、ブランチ、ディレクトリの組み合わせは、設定ファイルのパスを識別します。このパスはデータアプリ間で一意である必要があります。指定したパスが既に別のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、 TiDB Cloudコンソールで現在のデータアプリ用に設定されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、 [既存のデータアプリの構成をインポートする](/tidb-cloud/data-service-manage-github-connection.md#import-configurations-of-an-existing-data-app)を参照してください。 + > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、 [既存のデータアプリの構成をインポートする](/tidb-cloud/data-service-manage-github-connection.md#import-configurations-of-an-existing-data-app)を参照してください。 4. **Create Data App**をクリックします。 @@ -47,14 +46,14 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ ## データアプリを構成する {#configure-a-data-app} -データ アプリの名前、バージョン、説明を編集したり、GitHub 接続、リンクされたデータ ソース、API キー、エンドポイント、デプロイメントを管理したりできます。 +データアプリの名前、バージョン、説明を編集したり、GitHub 接続、リンクされたデータソース、API キー、エンドポイント、デプロイメントを管理したりできます。 ### データアプリのプロパティを編集する {#edit-data-app-properties} データアプリの名前、バージョン、説明を編集できます。データアプリのプロパティを編集するには、次の手順に従います。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータアプリの名前をクリックして詳細を表示します。 3. **Data App Properties**領域で、 をクリックし、アプリ名、バージョン、または説明を変更して、 **「確認」を**クリックします。 ### GitHub接続を管理する {#manage-github-connection} @@ -63,23 +62,23 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ ### リンクされたデータソースを管理する {#manage-linked-data-sources} -データ アプリのリンクされたクラスターを追加または削除できます。 +データアプリのリンクされたクラスターを追加または削除できます。 -クラスターをデータ アプリにリンクするには、次の手順を実行します。 +クラスターをデータアプリにリンクするには、次の手順を実行します。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックして詳細を表示します。 3. **Linked Data Sources**領域で、 **Add Cluster**をクリックします。 4. 表示されたダイアログボックスで、リストからクラスターを選択し、 **追加**をクリックします。 -データ アプリからリンクされたクラスターを削除するには、次の手順を実行します。 +データアプリからリンクされたクラスターを削除するには、次の手順を実行します。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **Linked Data Sources**領域で、データ アプリから削除する対象のリンク クラスターを見つけて、 **[アクション]**列の**[削除] を**クリックします。 +2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックして詳細を表示します。 +3. **Linked Data Sources**領域で、データアプリから削除する対象のリンク クラスターを見つけて、 **[アクション]**列の**[削除] を**クリックします。 4. 表示されたダイアログボックスで削除を確認します。 - リンクされたクラスターを削除しても、クラスター自体は削除されませんが、データ アプリ内の既存のエンドポイントはクラスターにアクセスできなくなります。 + リンクされたクラスターを削除しても、クラスター自体は削除されませんが、データアプリ内の既存のエンドポイントはクラスターにアクセスできなくなります。 ### APIキーを管理する {#manage-an-api-key} @@ -99,7 +98,7 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックして詳細を表示します。 3. **Deployment Configuration**領域で、 **構成**をクリックします。デプロイメント構成のダイアログが表示されます。 @@ -114,7 +113,7 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ - **Review Draft** - 有効にすると、デプロイ前にTiDB Cloudコンソールでデータアプリに加えた変更を確認できます。確認結果に基づいて、変更をデプロイするか破棄するかを選択できます。 - - 無効にすると、 TiDB Cloudコンソールで行ったデータ アプリの変更が直接デプロイされます。 + - 無効にすると、 TiDB Cloudコンソールで行ったデータアプリの変更が直接デプロイされます。 5. **アクション**列では、必要に応じて変更を編集または再展開できます。 @@ -124,17 +123,17 @@ Data Service（プレビュー版）は、各データアプリ向けのOpenAPI ### OpenAPI仕様をダウンロードする {#download-the-openapi-specification} -データ アプリの OpenAPI 仕様を JSON または YAML 形式でダウンロードするには、次の手順を実行します。 +データアプリの OpenAPI 仕様を JSON または YAML 形式でダウンロードするには、次の手順を実行します。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータアプリの名前をクリックして詳細を表示します。 3. **API Specification**領域で、 **ダウンロード**をクリックし、 **JSON**または**YAML**を選択します。 OpenAPI 仕様を初めてダウンロードする場合は、プロンプトが表示されたらリクエストを承認する必要があります。 -4. 次に、OpenAPI 仕様がローカル マシンにダウンロードされます。 +4. 次に、OpenAPI 仕様がローカルマシンにダウンロードされます。 ### OpenAPIドキュメントを確認する {#view-the-openapi-documentation} @@ -144,7 +143,7 @@ OpenAPI ドキュメントにアクセスするには、次の手順を実行し 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータアプリの名前をクリックして詳細を表示します。 3. ページの右上隅にある**View API Docs**をクリックします。 @@ -152,12 +151,12 @@ OpenAPI ドキュメントにアクセスするには、次の手順を実行し 4. すると、OpenAPIドキュメントが新しいタブで開きます。ドキュメントでは、以下の情報を確認できます。 - - データ アプリの名前、バージョン、説明。 + - データアプリの名前、バージョン、説明。 - タグごとにグループ化されたエンドポイント。 5. (オプション) エンドポイントを試すには、次の手順を実行します。 - 1. **[承認]**をクリックし、表示されたダイアログ ボックスにデータ アプリの公開キーを**ユーザー名**として、秘密キーを**パスワード**として入力します。 + 1. **[承認]**をクリックし、表示されたダイアログボックスにデータアプリの公開キーを**ユーザー名**として、秘密キーを**パスワード**として入力します。 詳細については[APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 @@ -171,10 +170,10 @@ OpenAPI ドキュメントの使用方法の詳細については、 [スワッ > > データアプリを削除する前に、すべてのエンドポイントがオンラインになっていないことを確認してください。オンラインになっていないと、データアプリを削除できません。エンドポイントのデプロイを解除するには、 [エンドポイントのデプロイ解除](/tidb-cloud/data-service-manage-endpoint.md#undeploy-an-endpoint)を参照してください。 -データ アプリを削除するには、次の手順を実行します。 +データアプリを削除するには、次の手順を実行します。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックして詳細を表示します。 3. **Danger Zone**エリアで、 **Delete Data App**をクリックします。確認のダイアログボックスが表示されます。 4. `//`を入力し、 **I understand, delete**をクリックします。 diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index 904ffc36dfa47..606d8f3d50cd3 100644 --- a/tidb-cloud/data-service-manage-endpoint.md +++ b/tidb-cloud/data-service-manage-endpoint.md @@ -13,10 +13,10 @@ Data Service (PREVIEW) のエンドポイントは、SQL ステートメント - エンドポイントを作成する前に、以下の点を確認してください。 - - TiDB Cloud Starterインスタンスとデータ アプリが作成されました。詳細については、 [データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)を参照してください。 + - TiDB Cloud Starterインスタンスとデータアプリが作成されました。詳細については、 [データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)を参照してください。 - エンドポイントが操作するデータベース、テーブル、および列は、既にターゲットのTiDB Cloud Starterインスタンスに存在しています。 -- エンドポイントを呼び出す前に、データ アプリで API キーを作成していることを確認してください。詳細については、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 +- エンドポイントを呼び出す前に、データアプリで API キーを作成していることを確認してください。詳細については、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 ## エンドポイントを作成する {#create-an-endpoint} @@ -67,7 +67,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の - バッチ操作を選択した場合、 TiDB Cloud Data Service は生成されるエンドポイント名に`/bulk`を追加します。たとえば、選択されたテーブル名が`/sample_table`で、選択された操作が`POST (Batch Create)`の場合、生成されるエンドポイントは`POST /sample_table/bulk`と表示されます。 - `POST (Vector Similarity Search)`が選択された場合、 TiDB Cloud Data Service は生成されるエンドポイント名に`/vector_search`を追加します。たとえば、選択されたテーブル名が`/sample_table`で、選択された操作が`POST (Vector Similarity Search)`の場合、生成されたエンドポイントは`POST /sample_table/vector_search`と表示されます。 - - 既に同じリクエスト メソッドとエンドポイント名を持つエンドポイントが存在する場合、 TiDB Cloud Data Service は生成されたエンドポイント名に`_dump_`を追加します。たとえば、 `/sample_table_dump_EUKRfl`となります。 + - 既に同じリクエストメソッドとエンドポイント名を持つエンドポイントが存在する場合、 TiDB Cloud Data Service は生成されたエンドポイント名に`_dump_`を追加します。たとえば、 `/sample_table_dump_EUKRfl`となります。 - SQLステートメント： TiDB Cloud Data Serviceは、テーブルの列仕様と選択されたエンドポイント操作に基づいて、生成されたエンドポイント用のSQLステートメントを自動的に作成します。エンドポイント名をクリックすると、ページの中央部分に表示されるSQLステートメントを確認できます。 @@ -82,7 +82,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の エンドポイントを手動で作成するには、以下の手順を実行してください。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、アプリ名の右側にある**+ を**クリックし、次に**Create Endpoint**をクリックします。 +2. 左側のペインで、対象のデータアプリを見つけ、アプリ名の右側にある**+ を**クリックし、次に**Create Endpoint**をクリックします。 3. 必要に応じてデフォルト名を更新してください。新しく作成されたエンドポイントは、エンドポイントリストの一番上に追加されます。 4. [エンドポイントを開発する](#develop-an-endpoint)」の指示に従って、新しいエンドポイントを構成します。 @@ -94,15 +94,14 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、アプリ名の右側にある**+**をクリックし、次に**Manage Endpoint Library**をクリックします。 - +2. 左側のペインで、対象のデータアプリを見つけ、アプリ名の右側にある**+**をクリックし、次に**Manage Endpoint Library**をクリックします。 エンドポイントライブラリ管理のダイアログが表示されます。現在、このダイアログには**Execute Query** （つまり、 `/system/query`エンドポイント）のみが表示されます。 3. `/system/query`エンドポイントをデータアプリに追加するには、**Execute Query**スイッチを**[追加済み]**に切り替えます。 > **Tip:** > - > データ アプリから追加済みの定義済みエンドポイントを削除するには、 **Execute Query**スイッチを**[削除済み]**に切り替えます。 + > データアプリから追加済みの定義済みエンドポイントを削除するには、 **Execute Query**スイッチを**[削除済み]**に切り替えます。 4. **保存**をクリックしてください。 @@ -174,7 +173,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > > - パス パラメーターは SQL で直接使用できます。詳細については、[パラメータを設定する](#configure-parameters)を参照してください。 -- **Endpoint URL** : (読み取り専用) デフォルト URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データ アプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`です。データ アプリのカスタム ドメインを構成するには、 [Data Serviceのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)を参照してください。 +- **Endpoint URL** : (読み取り専用) デフォルト URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データアプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`です。データアプリのカスタムドメインを構成するには、 [Data Serviceのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)を参照してください。 - **Request Method**：エンドポイントのHTTPメソッド。以下のメソッドがサポートされています。 @@ -193,7 +192,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 - **タグ**：エンドポイントのグループを識別するために使用されるタグ。 -- **ページネーション**：このプロパティは、リクエストメソッドが`GET`で、エンドポイントの最後の SQL ステートメントが`SELECT`操作の場合にのみ使用できます。**ページネーションが**有効になっている場合、エンドポイントを呼び出す際にクエリ パラメータとして`page`と`page_size`を指定することで、結果をページネーションできます（例`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id?page=&page_size=` 。詳細については、[エンドポイントを呼び出す](#call-an-endpoint)を参照してください。 +- **ページネーション**：このプロパティは、リクエストメソッドが`GET`で、エンドポイントの最後の SQL ステートメントが`SELECT`操作の場合にのみ使用できます。**ページネーションが**有効になっている場合、エンドポイントを呼び出す際にクエリパラメータとして`page`と`page_size`を指定することで、結果をページネーションできます（例`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id?page=&page_size=` 。詳細については、[エンドポイントを呼び出す](#call-an-endpoint)を参照してください。 > **Note:** > @@ -204,7 +203,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 - **有効期限（Time-to-live）** ：このプロパティは**Cache Response**が有効になっている場合にのみ使用できます。これを使用して、キャッシュされたレスポンスの有効期限（TTL）を秒単位で指定できます。TTL期間中に同じ`GET`リクエストを再度行うと、Data Serviceはターゲットデータベースからデータを再度取得する代わりに、キャッシュされたレスポンスを直接返します。これにより、クエリのパフォーマンスが向上します。 -- **Batch Operation**: このプロパティは、リクエストメソッドが`POST`または`PUT`の場合にのみ表示されます。**Batch Operation**が有効になっている場合、単一のリクエストで複数の行を操作できます。たとえば、curl コマンドの`POST`オプションのオブジェクトの`items`フィールドにデータ オブジェクトの配列を配置することで、単一`--data-raw`リクエストで複数の行のデータ[エンドポイントを呼び出す](#call-an-endpoint)。. +- **Batch Operation**: このプロパティは、リクエストメソッドが`POST`または`PUT`の場合にのみ表示されます。**Batch Operation**が有効になっている場合、単一のリクエストで複数の行を操作できます。たとえば、curl コマンドの`POST`オプションのオブジェクトの`items`フィールドにデータオブジェクトの配列を配置することで、単一`--data-raw`リクエストで複数の行のデータ[エンドポイントを呼び出す](#call-an-endpoint)。. > **Note:** > @@ -218,7 +217,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > **Note:** > - > データ アプリにリンクされているTiDB Cloud Starterインスタンスのみがドロップダウン リストに表示されます。リンクされたTiDB Cloud Starterインスタンスを管理するには、 [リンクされたデータソースを管理する](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)を参照してください。 + > データアプリにリンクされているTiDB Cloud Starterインスタンスのみがドロップダウンリストに表示されます。リンクされたTiDB Cloud Starterインスタンスを管理するには、 [リンクされたデータソースを管理する](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)を参照してください。 SQLエディタの上部にあるドロップダウンリストから、SQLステートメントを実行するTiDB Cloud Starterインスタンスを選択します。すると、右側のペインにある**スキーマ**タブで、そのTiDB Cloud Starterインスタンスのすべてのデータベースを表示できます。 @@ -305,7 +304,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 - **場所**：パラメータの位置を示します。このプロパティは変更できません。 - パスパラメータの場合、このプロパティは`Path`です。 - - その他のパラメーターの場合、リクエスト メソッドが`GET`または`DELETE`の場合、このプロパティは`Query`です。リクエスト メソッドが`POST`または`PUT`の場合、このプロパティは`Body`です。 + - その他のパラメーターの場合、リクエストメソッドが`GET`または`DELETE`の場合、このプロパティは`Query`です。リクエストメソッドが`POST`または`PUT`の場合、このプロパティは`Body`です。 **Test Values**セクションでは、テストパラメータの表示と設定ができます。これらの値は、エンドポイントをテストする際のパラメータ値として使用されます。値がパラメータの型に変換できることを確認してください。変換できない場合、エンドポイントはエラーを返します。 @@ -327,7 +326,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > **Tip:** > -> データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントをテストすることもできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 +> データアプリを Postman にインポートした場合は、Postman でデータアプリのエンドポイントをテストすることもできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 @@ -354,7 +353,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > **Note:** > -> **Auto Sync & Deployment**を有効にしてデータ アプリを GitHub に接続している場合、GitHub で行ったデータ アプリの変更はすべてTiDB Cloud Data Service に自動的にデプロイされます。詳細については、 [GitHubで自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 +> **Auto Sync & Deployment**を有効にしてデータアプリを GitHub に接続している場合、GitHub で行ったデータアプリの変更はすべてTiDB Cloud Data Service に自動的にデプロイされます。詳細については、 [GitHubで自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 エンドポイントをデプロイするには、以下の手順を実行します。 @@ -372,7 +371,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > **Tip:** > -> データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントを呼び出すこともできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 +> データアプリを Postman にインポートした場合は、Postman でデータアプリのエンドポイントを呼び出すこともできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 ### 前提条件 {#prerequisites} @@ -467,8 +466,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 つのデータオブジェクトのみを受け入れます。 - エンドポイントにパラメータが含まれている場合は、エンドポイントを呼び出す際にパラメータ値を指定してください。 @@ -480,7 +479,7 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ > **Note:** > -> データ アプリ[データアプリをGitHubに接続しました](/tidb-cloud/data-service-manage-github-connection.md)**Auto Sync & Deployment**を有効にしている場合、このデータ アプリのエンドポイントのデプロイを解除すると、GitHub 上のこのエンドポイントの構成も削除されます。 +> データアプリ[データアプリをGitHubに接続しました](/tidb-cloud/data-service-manage-github-connection.md)**Auto Sync & Deployment**を有効にしている場合、このデータアプリのエンドポイントのデプロイを解除すると、GitHub 上のこのエンドポイントの構成も削除されます。 エンドポイントをアンデプロイするには、以下の手順を実行します。 diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index b5fa28ea01130..2d61df997e2f5 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -11,7 +11,7 @@ TiDB Cloudは、 JSON構文を使用してデータアプリの構成全体を GitHub接続で**Auto Sync & Deployment**が有効になっている場合、GitHub上の設定ファイルを更新することでデータアプリを変更することもできます。設定ファイルの変更をGitHubにプッシュすると、新しい設定がTiDB Cloudに自動的にデプロイされます。 -このドキュメントでは、GitHub を使用してデータ アプリを自動的にデプロイする方法と、GitHub 接続を管理する方法について説明します。 +このドキュメントでは、GitHub を使用してデータアプリを自動的にデプロイする方法と、GitHub 接続を管理する方法について説明します。 ## 始める前に {#before-you-begin} @@ -22,11 +22,11 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git > **Note:** > -> GitHub リポジトリは、データ アプリを接続した後、データアプリ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)を保存するために使用されます。構成ファイル内の情報 ( TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの ID、エンドポイント URL など) が機密である場合は、パブリック リポジトリではなくプライベート リポジトリを必ず使用してください。 +> GitHub リポジトリは、データアプリを接続した後、データアプリ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)を保存するために使用されます。構成ファイル内の情報 ( TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの ID、エンドポイント URL など) が機密である場合は、パブリック リポジトリではなくプライベートリポジトリを必ず使用してください。 ## ステップ1：データアプリをGitHubに接続する {#step-1-connect-your-data-app-to-github} -アプリを作成するときに、データ アプリを GitHub に接続できます。詳細については、[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md)を参照してください。 +アプリを作成するときに、データアプリを GitHub に接続できます。詳細については、[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md)を参照してください。 アプリ作成時にGitHub接続を有効にしなかった場合でも、以下の手順で有効にすることができます。 @@ -48,7 +48,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git > > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 + > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 4. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **「自動同期とデプロイの設定」を**有効にします。 @@ -59,7 +59,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git ## ステップ2. データアプリの設定をGitHubと同期する {#step-2-synchronize-data-app-configurations-with-github} -データアプリ[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md)ときに GitHub 接続が有効になっている場合、 TiDB Cloud はアプリの作成直後にこのデータ アプリの構成ファイルを GitHub にプッシュします。 +データアプリ[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md)ときに GitHub 接続が有効になっている場合、 TiDB Cloud はアプリの作成直後にこのデータアプリの構成ファイルを GitHub にプッシュします。 アプリ作成後にGitHub接続が有効になっている場合は、データアプリの設定をGitHubと同期するためにデプロイ操作を実行する必要があります。たとえば、 **[デプロイ]**タブをクリックし、このデータアプリのデプロイを再デプロイすることができます。 @@ -98,7 +98,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git | `data_source/cluster.json` | このファイルを更新する際は、リンクされているTiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターにアクセスできることを確認してください。TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの ID は、その URL から取得できます。たとえば、URL が`https://tidbcloud.com/tidbs/1234567891234567890/overview?orgId=`の場合、ID は`1234567891234567890`です。 | | `http_endpoints/config.json` | エンドポイントを変更する場合は、 [HTTPエンドポイント構成](/tidb-cloud/data-service-app-config-files.md#http-endpoint-configuration)で説明されているルールに従ってください。 | | `http_endpoints/sql/method-.sql` | `http_endpoints/sql`ディレクトリに SQL ファイルを追加または削除するには、対応するエンドポイント構成も更新する必要があります。 | -| `datapp_config.json` | `app_id`ファイルが別のデータ アプリからコピーされたもので、現在のデータ アプリの ID に更新したい場合を除き、このファイルの`dataapp_config.json`フィールドを変更しないでください。そうしないと、この変更によってトリガーされるデプロイが失敗します。 | +| `datapp_config.json` | `app_id`ファイルが別のデータアプリからコピーされたもので、現在のデータアプリの ID に更新したい場合を除き、このファイルの`dataapp_config.json`フィールドを変更しないでください。そうしないと、この変更によってトリガーされるデプロイが失敗します。 | これらのファイルのフィールド構成の詳細については、 [データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)を参照してください。 @@ -125,7 +125,7 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ 2. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、GitHub に接続せずに[新しいデータアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)。 -3. **Auto Sync & Deployment**を有効にして、[新しいデータアプリをGitHubに接続します](#step-1-connect-your-data-app-to-github)。新しいデータ アプリのターゲット リポジトリ、ブランチ、ディレクトリを指定するときは、コピーした構成ファイルを含む新しいパスを使用します。 +3. **Auto Sync & Deployment**を有効にして、[新しいデータアプリをGitHubに接続します](#step-1-connect-your-data-app-to-github)。新しいデータアプリのターゲット リポジトリ、ブランチ、ディレクトリを指定するときは、コピーした構成ファイルを含む新しいパスを使用します。 4. 新しいデータアプリのIDと名前を取得します。左側のペインで新しいデータアプリの名前をクリックすると、右側のペインの**Data App Properties**領域にアプリのIDと名前が表示されます。 @@ -153,7 +153,7 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ > > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 + > - 指定したパスに別のデータアプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータアプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 5. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **「自動同期とデプロイの設定」を**有効にします。 @@ -171,4 +171,4 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ 3. **設定**タブで、 **GitHubに接続**エリアの**Disconnect**をクリックします。 4. 切断を確定するには、 **切断**をクリックしてください。 -接続解除操作後、データ アプリの設定ファイルは GitHub ディレクトリに残りますが、 `tidb-cloud-data-service`によって同期されなくなります。 +接続解除操作後、データアプリの設定ファイルは GitHub ディレクトリに残りますが、 `tidb-cloud-data-service`によって同期されなくなります。 diff --git a/tidb-cloud/data-service-oas-with-nextjs.md b/tidb-cloud/data-service-oas-with-nextjs.md index 3a6c2ce1d4929..9b43196db393f 100644 --- a/tidb-cloud/data-service-oas-with-nextjs.md +++ b/tidb-cloud/data-service-oas-with-nextjs.md @@ -45,7 +45,7 @@ VALUES ('tidb', 'https://github.com/pingcap/tidb'), ## ステップ2. データアプリを作成する {#step-2-create-a-data-app} -データ挿入後、 [TiDB Cloudコンソール](https://tidbcloud.com)の[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターにリンクするデータ アプリを作成し、データ アプリの API キーを作成してから、データ アプリに`GET /repositories`エンドポイントを作成します。このエンドポイントに対応する SQL ステートメントは次のとおりです。これは`test.repository`テーブルからすべての行を取得します。 +データ挿入後、 [TiDB Cloudコンソール](https://tidbcloud.com)の[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターにリンクするデータアプリを作成し、データアプリの API キーを作成してから、データアプリに`GET /repositories`エンドポイントを作成します。このエンドポイントに対応する SQL ステートメントは次のとおりです。これは`test.repository`テーブルからすべての行を取得します。 ```sql SELECT * FROM test.repository; @@ -73,7 +73,7 @@ SELECT * FROM test.repository; 2. 依存関係をインストールします。 - このドキュメントでは[OpenAPIジェネレーター](https://github.com/OpenAPITools/openapi-generator)を使用して、OpenAPI 仕様から API クライアント ライブラリを自動的に生成します。 + このドキュメントでは[OpenAPIジェネレーター](https://github.com/OpenAPITools/openapi-generator)を使用して、OpenAPI 仕様から API クライアントライブラリを自動的に生成します。 OpenAPI Generatorを開発依存関係としてインストールするには、次のコマンドを実行します。 @@ -152,7 +152,7 @@ SELECT * FROM test.repository; TIDBCLOUD_DATA_SERVICE_PRIVATE_KEY=YOUR_PRIVATE_KEY ``` - データ アプリの API キーを作成するには、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 + データアプリの API キーを作成するには、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 2. `hello-repos`プロジェクトディレクトリで、 `app/page.tsx`の内容を、 `GET /repositories`エンドポイントからデータを取得して表示する以下のコードに置き換えてください。 diff --git a/tidb-cloud/data-service-response-and-status-code.md b/tidb-cloud/data-service-response-and-status-code.md index 153dc95de254a..709a674edb9e4 100644 --- a/tidb-cloud/data-service-response-and-status-code.md +++ b/tidb-cloud/data-service-response-and-status-code.md @@ -1,6 +1,6 @@ --- title: Response and HTTP Status Codes of Data Service -summary: このドキュメントでは、TiDB CloudのData Serviceの応答と HTTP ステータス コードについて説明します。 +summary: このドキュメントでは、TiDB CloudのData Serviceの応答と HTTP ステータスコードについて説明します。 --- # Data Serviceの応答とHTTPステータスコード {#response-and-http-status-codes-of-data-service} @@ -250,7 +250,7 @@ HTTPステータスコードが`200`で、 `data.result.code`フィールドに ### 408 {#408} -このステータス コードは、リクエストがエンドポイントのタイムアウト期間を超えたことを示します。エンドポイントのタイムアウトを変更するには、 [プロパティを構成する](/tidb-cloud/data-service-manage-endpoint.md#configure-properties)を参照してください。 +このステータスコードは、リクエストがエンドポイントのタイムアウト期間を超えたことを示します。エンドポイントのタイムアウトを変更するには、 [プロパティを構成する](/tidb-cloud/data-service-manage-endpoint.md#configure-properties)を参照してください。 回答例は以下のとおりです。 @@ -276,7 +276,7 @@ HTTPステータスコードが`200`で、 `data.result.code`フィールドに ### 429 {#429} -このステータス コードは、リクエストが API キーのレート制限を超えていることを示します。さらに多くの割り当てが必要な場合は、サポート チームに[リクエストを送信する](https://tidb.support.pingcap.com/)ください。 +このステータスコードは、リクエストが API キーのレート制限を超えていることを示します。さらに多くの割り当てが必要な場合は、サポートチームに[リクエストを送信する](https://tidb.support.pingcap.com/)ください。 回答例は以下のとおりです。 diff --git a/tidb-cloud/data-streaming-concepts.md b/tidb-cloud/data-streaming-concepts.md index 2f4a14ec92172..d66c3c91a543b 100644 --- a/tidb-cloud/data-streaming-concepts.md +++ b/tidb-cloud/data-streaming-concepts.md @@ -17,6 +17,6 @@ TiDB Cloudコンソールの**Changefeed**ページでは、変更フィード デフォルトでは、レプリケーションには増分データの変更のみが含まれます。既存のデータをレプリケーションする必要がある場合は、変更フィードを開始する前に、手動でエクスポートしてターゲットシステムにロードする必要があります。 -TiDB Cloudでは、テーブル フィルター (レプリケートするテーブルを指定する) とイベント フィルター (INSERT や DELETE などの特定の種類のイベントを含めるか除外するか) を定義することで、レプリケーションをカスタマイズできます。 +TiDB Cloudでは、テーブルフィルター (レプリケートするテーブルを指定する) とイベントフィルター (INSERT や DELETE などの特定の種類のイベントを含めるか除外するか) を定義することで、レプリケーションをカスタマイズできます。 詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md)を参照してください。 diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index e685252c5f9fb..6f241258be210 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -45,7 +45,7 @@ TiDBには`test`という名前のデフォルトデータベースが付属し ### キャッシュされたテーブル {#cached-table} -TiDB は、頻繁にアクセスされるがめったに更新されない小さなホットスポット テーブル用に[キャッシュされたテーブル](/cached-tables.md)機能を導入しました。この機能を使用すると、テーブル全体のデータが TiDBサーバーのメモリにロードされ、TiDB は TiKV にアクセスせずにメモリからテーブル データを直接取得するため、読み取りパフォーマンスが向上します。 +TiDB は、頻繁にアクセスされるがめったに更新されない小さなホットスポット テーブル用に[キャッシュされたテーブル](/cached-tables.md)機能を導入しました。この機能を使用すると、テーブル全体のデータが TiDBサーバーのメモリにロードされ、TiDB は TiKV にアクセスせずにメモリからテーブルデータを直接取得するため、読み取りパフォーマンスが向上します。 ### 一時テーブル {#temporary-table} @@ -125,7 +125,7 @@ TiDB では、 [既存のテーブルにセカンダリインデックスを追 TiDBでは、[ベクトルインデックス](/ai/reference/vector-search-index.md)は、ベクトルデータを含む列に対して効率的な近似最近傍（ANN）検索を行うために設計された特殊なインデックスです。ベクトルインデックス、特にHNSW（階層型ナビゲート可能スモールワールド）アルゴリズムは、K近傍（KNN）検索によってベクトル空間内の最も近いデータポイントを迅速に特定することを可能にします。これによりクエリのパフォーマンスが大幅に向上し、総当たり検索に比べてミリ秒単位で結果が得られます。 -ベクトル インデックスは、データストレージと検索機能をTiFlashレプリカに依存します。 +ベクトルインデックスは、データストレージと検索機能をTiFlashレプリカに依存します。 ## 制約 {#constraints} diff --git a/tidb-cloud/dedicated-external-storage.md b/tidb-cloud/dedicated-external-storage.md index b60640896c8c4..ab4bb77e18874 100644 --- a/tidb-cloud/dedicated-external-storage.md +++ b/tidb-cloud/dedicated-external-storage.md @@ -39,19 +39,19 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA 2. AWS マネジメントコンソールで、Amazon S3 バケット用のマネージドポリシーを作成します。 - 1. AWS マネジメント コンソールにサインインし、 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)で Amazon S3 コンソールを開きます。 + 1. AWS マネジメントコンソールにサインインし、 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)で Amazon S3 コンソールを開きます。 2. **バケット**一覧から、ソースデータが入っているバケットの名前を選択し、 **Copy ARN**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 ![Copy bucket ARN](/media/tidb-cloud/copy-bucket-arn.png) - 3. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)でIAMコンソールを開き、左側のナビゲーション ペインで**[ポリシー]**をクリックし、 **Create Policy**をクリックします。 + 3. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)でIAMコンソールを開き、左側のナビゲーションペインで**[ポリシー]**をクリックし、 **Create Policy**をクリックします。 ![Create a policy](/media/tidb-cloud/aws-create-policy.png) 4. **Create policy**ページで、 **JSON**タブをクリックします。 - 5. 以下のアクセス ポリシー テンプレートをコピーして、ポリシー テキスト フィールドに貼り付けてください。 + 5. 以下のアクセスポリシー テンプレートをコピーして、ポリシー テキスト フィールドに貼り付けてください。 ````json { @@ -111,7 +111,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA 3. AWS マネジメントコンソールで、 TiDB Cloudのアクセスロールを作成し、ロール ARN を取得します。 - 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)のIAMコンソールで、左側のナビゲーション ペインの**[ロール]**をクリックし、 **Create role**をクリックします。 + 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)のIAMコンソールで、左側のナビゲーションペインの**[ロール]**をクリックし、 **Create role**をクリックします。 ![Create a role](/media/tidb-cloud/aws-create-role.png) @@ -152,7 +152,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA > **Note:** > -> TiDB Cloudはアクセス キーを保存しません。インポートが完了したら、 [アクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)ことをお勧めします。 +> TiDB Cloudはアクセスキーを保存しません。インポートが完了したら、 [アクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)ことをお勧めします。 ## GCSへのアクセスを設定する {#configure-gcs-access} @@ -230,7 +230,7 @@ TiDB Cloud DedicatedがAzure Blobコンテナにアクセスできるように 1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するストレージアカウントをクリックします。 -2. ストレージアカウントのナビゲーション ペインで、 **Security + networking** > **Shared access signature**をクリックします。 +2. ストレージアカウントのナビゲーションペインで、 **Security + networking** > **Shared access signature**をクリックします。 ![sas-position](/media/tidb-cloud/dedicated-external-storage/azure-sas-position.png) diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index c336cc8441762..dc757ffe85eeb 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -67,7 +67,7 @@ Apache Kafkaサービスへのパブリックアクセスを提供する場合 TiDB Cloud Essential の変更フィードが Apache Kafka にデータをストリーミングし、Kafka トピックを自動的に作成できるようにするには、Kafka に次の権限が追加されていることを確認してください。 - Kafka のトピック リソース タイプに`Create`および`Write`権限が追加されます。 -- Kafka のクラスタ リソース タイプに`DescribeConfigs`権限が追加されます。 +- Kafka のクラスタリソース タイプに`DescribeConfigs`権限が追加されます。 たとえば、Kafka クラスターが Confluent Cloud にある場合、詳細については、Confluent ドキュメントの[リソース](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)と[ACLの追加](https://docs.confluent.io/platform/current/security/authorization/acls/manage-acls.html#add-acls)を参照してください。 @@ -134,7 +134,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**[適用**] をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタ ルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 + - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 @@ -152,7 +152,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - - オープン プロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータ ソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 + - オープンプロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 diff --git a/tidb-cloud/essential-changefeed-sink-to-mysql.md b/tidb-cloud/essential-changefeed-sink-to-mysql.md index e0f1107e6c2da..bd7d148d265fe 100644 --- a/tidb-cloud/essential-changefeed-sink-to-mysql.md +++ b/tidb-cloud/essential-changefeed-sink-to-mysql.md @@ -42,7 +42,7 @@ TiDB Cloud EssentialインスタンスがMySQLサービスに接続できるこ プライベートリンク接続は、クラウドプロバイダーの**Private Link**技術を活用することで、VPC内のリソースがプライベートIPアドレスを介して他のVPC内のサービスに接続できるようにします。これにより、あたかもそれらのサービスがVPC内で直接ホストされているかのように動作します。 -プライベート リンク接続を通じて、 TiDB Cloud Essentialインスタンスを MySQL サービスに安全に接続できます。 MySQL サービスでプライベート リンク接続が利用できない場合は、プライベートリンク[プライベートリンク接続を介してAmazon RDSに接続する](/tidb-cloud/serverless-private-link-connection-to-aws-rds.md)[プライベートリンク接続を介してAlibaba Cloud ApsaraDB RDS for MySQLに接続する](/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md)。 +プライベートリンク接続を通じて、 TiDB Cloud Essentialインスタンスを MySQL サービスに安全に接続できます。 MySQL サービスでプライベートリンク接続が利用できない場合は、プライベートリンク[プライベートリンク接続を介してAmazon RDSに接続する](/tidb-cloud/serverless-private-link-connection-to-aws-rds.md)[プライベートリンク接続を介してAlibaba Cloud ApsaraDB RDS for MySQLに接続する](/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md)。
    @@ -60,7 +60,7 @@ 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**を作成する時間 @@ -105,7 +105,7 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**[適用**] をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタ ルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 + - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 7. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/essential-database-audit-logging.md b/tidb-cloud/essential-database-audit-logging.md index f0322e9cdbb21..5e8e4c989de5f 100644 --- a/tidb-cloud/essential-database-audit-logging.md +++ b/tidb-cloud/essential-database-audit-logging.md @@ -96,7 +96,7 @@ Alibaba Cloud OSSに監査ログを保存するには、以下の情報を提供 - `filters` : フィルタオブジェクトのリスト。各フィルタオブジェクトには、次のフィールドが含まれます。 - `classes` : 監査イベントをフィルタリングするためのイベントクラスのリスト。例: `["QUERY", "EXECUTE"]` 。 - - `tables` : テーブル フィルターのリスト。詳細については、 [テーブルフィルター](https://docs.pingcap.com/tidb/stable/table-filter/)を参照してください。 + - `tables` : テーブルフィルターのリスト。詳細については、 [テーブルフィルター](https://docs.pingcap.com/tidb/stable/table-filter/)を参照してください。 - `statusCodes` : 監査イベントをフィルタリングするためのステータスコードのリスト。 `1`は成功、 `0`は失敗を意味します。 以下の表は、データベース監査ログにおけるすべてのイベントクラスを示しています。 @@ -124,7 +124,7 @@ Alibaba Cloud OSSに監査ログを保存するには、以下の情報を提供 > **Note:** > -> `AUDIT`イベント クラスとそのサブクラスは常に監査ログに記録され、フィルタリングすることはできません。 +> `AUDIT`イベントクラスとそのサブクラスは常に監査ログに記録され、フィルタリングすることはできません。 ## 監査ログの設定 {#configure-audit-logging} @@ -389,7 +389,7 @@ TiDB Cloudは、監査ログ内の各データベースイベントレコード | `CURRENT_DB` | 現在使用しているデータベースの名前。 | | `SQL_TEXT` | 実行されたSQLステートメント。監査ログの秘匿化が有効になっている場合は、秘匿化されたSQLステートメントが記録されます。 | | `EXECUTE_PARAMS` | `EXECUTE`ステートメントのパラメータ。イベントクラスに`EXECUTE`が含まれ、かつ秘匿化が無効になっている場合にのみ記録されます。 | -| `AFFECTED_ROWS` | SQL ステートメントの影響を受ける行数。イベント クラスに`QUERY_DML`が含まれている場合にのみ記録されます。 | +| `AFFECTED_ROWS` | SQL ステートメントの影響を受ける行数。イベントクラスに`QUERY_DML`が含まれている場合にのみ記録されます。 | ### 接続情報 {#connection-information} diff --git a/tidb-cloud/explore-data-with-chat2query.md b/tidb-cloud/explore-data-with-chat2query.md index 68d659b5139d3..289e7538a308e 100644 --- a/tidb-cloud/explore-data-with-chat2query.md +++ b/tidb-cloud/explore-data-with-chat2query.md @@ -42,7 +42,7 @@ SQLエディタの推奨される使用例は以下のとおりです。 ## AIによるSQLクエリ生成を有効または無効にする {#enable-or-disable-ai-to-generate-sql-queries} -PingCAP は、ユーザーのデータのプライバシーとセキュリティを最優先事項としています。 SQL エディターの Chat2Query の AI 機能は、データ自体ではなく、データベース スキーマにアクセスして SQL クエリを生成することのみが必要です。詳細については、 [Chat2Queryのプライバシーに関するFAQ](https://www.pingcap.com/privacy-policy/privacy-chat2query)を参照してください。 +PingCAP は、ユーザーのデータのプライバシーとセキュリティを最優先事項としています。 SQL エディターの Chat2Query の AI 機能は、データ自体ではなく、データベーススキーマにアクセスして SQL クエリを生成することのみが必要です。詳細については、 [Chat2Queryのプライバシーに関するFAQ](https://www.pingcap.com/privacy-policy/privacy-chat2query)を参照してください。 Chat2Queryに初めてアクセスすると、PingCAPとAmazon Bedrockがお客様のコードスニペットを使用してサービスを調査および改善することを許可するかどうかを尋ねるダイアログが表示されます。 @@ -160,7 +160,7 @@ Chat2Queryでは、以下の手順でChat2Queryデータアプリにアクセス 1. 右上隅の**…**をクリックし、次に**Access Chat2Query via API**をクリックします。 2. 表示されたダイアログで、次のいずれかの操作を行います。 - - 新しい Chat2Query データ アプリを作成するには、 **New Chat2Query Data App**をクリックします。 + - 新しい Chat2Query データアプリを作成するには、 **New Chat2Query Data App**をクリックします。 - 既存のChat2Queryデータアプリにアクセスするには、対象のデータアプリの名前をクリックしてください。 詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)を参照してください。 diff --git a/tidb-cloud/get-started-with-cli.md b/tidb-cloud/get-started-with-cli.md index 109f52f1c40cc..5fc32c6d30d67 100644 --- a/tidb-cloud/get-started-with-cli.md +++ b/tidb-cloud/get-started-with-cli.md @@ -95,7 +95,7 @@ MySQL コマンドライン クライアントがインストールされてい ### TiDB Cloudでユーザープロファイルを作成するか、ログインしてください。 {#create-a-user-profile-or-log-into-tidb-cloud} -TiDB Cloud CLI を使用して TiDB Cloud Starterインスタンスを作成する前に、ユーザー プロファイルを作成するか、 TiDB Cloudにログインする必要があります。 +TiDB Cloud CLI を使用して TiDB Cloud Starterインスタンスを作成する前に、ユーザープロファイルを作成するか、 TiDB Cloudにログインする必要があります。 - [TiDB Cloud APIキー](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)を使用してユーザープロファイルを作成します。 diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index 73ca5dc879434..a9faa05ab3f24 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -80,7 +80,7 @@ TiDB CloudがAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Objec - CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 + バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレットアクセスキーを含む) またはロール ARN の値をメモしておいてください。 - CSV ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 @@ -113,7 +113,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **Source Files URI** ： - 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 ロール ARN または AWS アクセスキーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** ：AWSロールARNの値を入力してください。 - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -127,7 +127,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 @@ -166,7 +166,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **Source Files URI** ： - 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)を参照してください。 + - **認証情報**: GCS IAM役割サービスアカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 4. **次へ**をクリックしてください。 @@ -178,7 +178,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 @@ -229,7 +229,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 @@ -280,7 +280,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 @@ -314,7 +314,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー ### データインポート中の警告を解決する {#resolve-warnings-during-data-import} -**Start Import**をクリックした後、 `can't find the corresponding source files`などの警告メッセージが表示された場合は、正しいソース ファイルを提供するか、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従って既存のファイルの名前を変更するか、**Advanced Settings**を使用して変更することで問題を解決します。 +**Start Import**をクリックした後、 `can't find the corresponding source files`などの警告メッセージが表示された場合は、正しいソースファイルを提供するか、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従って既存のファイルの名前を変更するか、**Advanced Settings**を使用して変更することで問題を解決します。 これらの問題を解決した後、データを再度インポートする必要があります。 diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index a39f0be6b071f..37950ddb4016d 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -37,7 +37,7 @@ aliases: ['/ja/tidbcloud/migrate-from-amazon-s3-or-gcs','/ja/tidbcloud/migrate-f > - データファイルのみを圧縮すればよく、データベースファイルやテーブルスキーマファイルを圧縮する必要はありません。 > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 - > - 圧縮されていないファイルの場合、前述のルールに従って CSV ファイル名を更新できない場合 (たとえば、CSV ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)の**Destination Mapping**手順で**「TiDB ファイル命名規則を使用して自動マッピングを行う」の**選択を解除して、ソース ファイルを単一のターゲット テーブルに手動でマッピングできます。 + > - 圧縮されていないファイルの場合、前述のルールに従って CSV ファイル名を更新できない場合 (たとえば、CSV ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)の**Destination Mapping**手順で**「TiDB ファイル命名規則を使用して自動マッピングを行う」の**選択を解除して、ソースファイルを単一のターゲットテーブルに手動でマッピングできます。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} @@ -84,7 +84,7 @@ TiDB CloudがAmazon S3バケット、GCSバケット、またはAzure Blob Stora - CSV ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 - バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 + バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレットアクセスキーを含む) またはロール ARN の値をメモしておいてください。 - CSV ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 @@ -115,7 +115,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **Source URI** ： - 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 ロール 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ロールを手動で作成します。 - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -170,7 +170,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **Source URI** ： - 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)を参照してください。 + - **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)を参照してください。 4. **次へ**をクリックしてください。 @@ -234,7 +234,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に 2. ストレージアカウントに移動し、 **[概要]** > **JSON View**をクリックします。 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 - - **SAS Token**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 + - **SAS Token**: TiDB Cloud がAzure Blob Storage コンテナー内のソースファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 4. **次へ**をクリックしてください。 diff --git a/tidb-cloud/import-parquet-files-serverless.md b/tidb-cloud/import-parquet-files-serverless.md index a91a0f752a1ab..80f782705143b 100644 --- a/tidb-cloud/import-parquet-files-serverless.md +++ b/tidb-cloud/import-parquet-files-serverless.md @@ -37,7 +37,7 @@ TiDB Cloud StarterまたはTiDB Cloud Essential[Apache Parquet](https://parquet. > **Note:** > - > 場合によっては、前述のルールに従って Parquet ファイル名を更新できないことがあります (たとえば、Parquet ファイル リンクが他のプログラムでも使用されている場合)。その場合は、ファイル名を変更せずに、[ステップ4](#step-4-import-parquet-files)の**Mapping Settings**を使用してソース データを単一のターゲット テーブルにインポートできます。 + > 場合によっては、前述のルールに従って Parquet ファイル名を更新できないことがあります (たとえば、Parquet ファイル リンクが他のプログラムでも使用されている場合)。その場合は、ファイル名を変更せずに、[ステップ4](#step-4-import-parquet-files)の**Mapping Settings**を使用してソースデータを単一のターゲットテーブルにインポートできます。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} @@ -84,7 +84,7 @@ TiDB CloudがAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Objec - Parquet ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-parquet-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 + バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-parquet-files)で必要となるため、アクセスキー (アクセスキー ID とシークレットアクセスキーを含む) またはロール ARN の値をメモしておいてください。 - Parquet ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 @@ -117,7 +117,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **Source Files URI** ： - 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 ロール ARN または AWS アクセスキーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWS Role ARN** ：AWSロールARNの値を入力してください。 - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -131,9 +131,9 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマップできるようにするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマップできるようにするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 @@ -170,7 +170,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **Source Files URI** ： - 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)を参照してください。 + - **認証情報**: GCS IAM役割サービスアカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 4. **次へ**をクリックしてください。 @@ -182,9 +182,9 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 @@ -233,9 +233,9 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 @@ -284,9 +284,9 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 @@ -344,7 +344,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン ### データインポート中の警告を解決する {#resolve-warnings-during-data-import} -**Start Import**をクリックした後、 `can't find the corresponding source files`などの警告メッセージが表示された場合は、正しいソース ファイルを提供するか、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従って既存のファイルの名前を変更するか、**Advanced Settings**を使用して変更することで問題を解決します。 +**Start Import**をクリックした後、 `can't find the corresponding source files`などの警告メッセージが表示された場合は、正しいソースファイルを提供するか、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従って既存のファイルの名前を変更するか、**Advanced Settings**を使用して変更することで問題を解決します。 これらの問題を解決した後、データを再度インポートする必要があります。 diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index 2950564c06c98..5eeec880ae37a 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -41,7 +41,7 @@ summary: Amazon S3、GCS、またはAzure Blob StorageからTiDB Cloud Dedicated > **Note:** > - > - 前述のルールに従って Parquet ファイル名を更新できない場合 (たとえば、Parquet ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)の**Destination Mapping**サブステップで**「TiDB ファイル命名規則を使用して自動マッピングを行う」**の選択を解除して、ソース ファイルを単一のターゲット テーブルに手動でマッピングできます。 + > - 前述のルールに従って Parquet ファイル名を更新できない場合 (たとえば、Parquet ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)の**Destination Mapping**サブステップで**「TiDB ファイル命名規則を使用して自動マッピングを行う」**の選択を解除して、ソースファイルを単一のターゲットテーブルに手動でマッピングできます。 > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} @@ -89,7 +89,7 @@ TiDB CloudがAmazon S3バケット、GCSバケット、またはAzure Blob Stora - Parquet ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 - バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 + バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレットアクセスキーを含む) またはロール ARN の値をメモしておいてください。 - Parquet ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 @@ -120,7 +120,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **Source URI** ： - 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 ロール 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ロールを手動で作成します。 - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -136,7 +136,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 @@ -173,7 +173,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **Source URI** ： - 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)を参照してください。 + - **認証情報**: 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)を参照してください。 4. **次へ**をクリックしてください。 @@ -187,7 +187,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 @@ -235,7 +235,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 2. ストレージアカウントに移動し、 **[概要]** > **JSON View**をクリックします。 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 - - **資格情報**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするためのアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 + - **資格情報**: TiDB Cloud がAzure Blob Storage コンテナー内のソースファイルにアクセスできるようにするためのアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 4. **次へ**をクリックしてください。 @@ -263,7 +263,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet を**選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - **ソース**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 diff --git a/tidb-cloud/import-snapshot-files-serverless.md b/tidb-cloud/import-snapshot-files-serverless.md index 205eb6febea05..7a1f8b1c50a1b 100644 --- a/tidb-cloud/import-snapshot-files-serverless.md +++ b/tidb-cloud/import-snapshot-files-serverless.md @@ -1,6 +1,6 @@ --- title: Import Snapshot Files into TiDB Cloud Starter or Essential -summary: Amazon Auroraまたは RDS for MySQL スナップショット ファイルをTiDB Cloud Starter または Essential にインポートする方法を学びます。 +summary: Amazon Auroraまたは RDS for MySQL スナップショットファイルをTiDB Cloud Starter または Essential にインポートする方法を学びます。 --- # スナップショットファイルをTiDB Cloud StarterまたはEssentialにインポートする {#import-snapshot-files-into-tidb-cloud-starter-or-essential} diff --git a/tidb-cloud/import-snapshot-files.md b/tidb-cloud/import-snapshot-files.md index 519a0a8687675..a846a16005aab 100644 --- a/tidb-cloud/import-snapshot-files.md +++ b/tidb-cloud/import-snapshot-files.md @@ -1,6 +1,6 @@ --- title: Import Snapshot Files into TiDB Cloud Dedicated -summary: Amazon Auroraまたは RDS for MySQL スナップショット ファイルをTiDB Cloud Dedicated にインポートする方法を学びます。 +summary: Amazon Auroraまたは RDS for MySQL スナップショットファイルをTiDB Cloud Dedicated にインポートする方法を学びます。 --- # スナップショットファイルをTiDB Cloud Dedicatedにインポートする {#import-snapshot-files-into-tidb-cloud-dedicated} diff --git a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md index 79a87fd83707e..037becf4bbdf8 100644 --- a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md +++ b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md @@ -44,7 +44,7 @@ AWS CloudFormationは、Secrets Manager、API Gateway、Lambda関数など、プ - [Postman](https://www.postman.com/)や[カール](https://curl.se/)などのAPIテストツール。このドキュメントのほとんどの例では cURL を使用します。 Windows ユーザーには Postman をお勧めします。 -- プロジェクトの[最新リリースのアセット](https://github.com/pingcap/TiDB-Lambda-integration/releases/latest)ローカル マシンにダウンロードします。これには、 `cloudformation_template.yml`および`cloudformation_template.json`ファイルが含まれます。 +- プロジェクトの[最新リリースのアセット](https://github.com/pingcap/TiDB-Lambda-integration/releases/latest)ローカルマシンにダウンロードします。これには、 `cloudformation_template.yml`および`cloudformation_template.json`ファイルが含まれます。 > **Note:** > @@ -158,7 +158,7 @@ AWS CloudFormation を使用して書店プロジェクトを設定するには スタックが作成されたら、プロジェクトは次のように使用できます。 -1. AWS マネジメント コンソールで[APIゲートウェイサービス](https://console.aws.amazon.com/apigateway)サービスにアクセスし、 `TiDBCloudApiGatewayV2` API をクリックし、左側のペインで**API: TiDBCloudApiGatewayV2**をクリックします。 +1. AWS マネジメントコンソールで[APIゲートウェイサービス](https://console.aws.amazon.com/apigateway)サービスにアクセスし、 `TiDBCloudApiGatewayV2` API をクリックし、左側のペインで**API: TiDBCloudApiGatewayV2**をクリックします。 2. **概要**ページから`Invoke URL`をコピーしてください。この URL が API エンドポイントとして機能します。 diff --git a/tidb-cloud/integrate-tidbcloud-with-dbt.md b/tidb-cloud/integrate-tidbcloud-with-dbt.md index a5c55f0738ca0..a8d68a24eb988 100644 --- a/tidb-cloud/integrate-tidbcloud-with-dbt.md +++ b/tidb-cloud/integrate-tidbcloud-with-dbt.md @@ -59,7 +59,7 @@ cd jaffle_shop - `dbt_project.yml`は dbt プロジェクト構成ファイルであり、プロジェクト名とデータベース構成ファイルの情報が含まれています。 -- `models`ディレクトリには、プロジェクトの SQL モデルとテーブル スキーマが含まれています。このセクションはデータ アナリストが作成します。モデルの詳細については、 [SQLモデル](https://docs.getdbt.com/docs/build/sql-models)を参照してください。 +- `models`ディレクトリには、プロジェクトの SQL モデルとテーブルスキーマが含まれています。このセクションはデータ アナリストが作成します。モデルの詳細については、 [SQLモデル](https://docs.getdbt.com/docs/build/sql-models)を参照してください。 - `seeds`ディレクトリには、データベース エクスポート ツールによってダンプされた CSV ファイルが保存されます。たとえば、 Dumplingを通じて[TiDB Cloudデータをエクスポートする](https://docs.pingcap.com/tidbcloud/export-data-from-tidb-cloud)できます。 `jaffle_shop`プロジェクトでは、これらの CSV ファイルが処理される生データとして使用されます。 diff --git a/tidb-cloud/integrate-tidbcloud-with-vercel.md b/tidb-cloud/integrate-tidbcloud-with-vercel.md index c627bbcab2b2e..396f738e56a6e 100644 --- a/tidb-cloud/integrate-tidbcloud-with-vercel.md +++ b/tidb-cloud/integrate-tidbcloud-with-vercel.md @@ -48,7 +48,7 @@ TiDB Cloudにアカウントとクラスターが既に作成されている必 > **Note:** > - > TiDB Cloud Dedicatedクラスターの場合、Vercel デプロイメントは IP アドレスを使用するため、クラスターのトラフィック フィルターがすべての IP アドレス ( `0.0.0.0/0` } に設定) からの接続を許可して[動的IPアドレス](https://vercel.com/guides/how-to-allowlist-deployment-ip-address)ことを確認してください。 + > TiDB Cloud Dedicatedクラスターの場合、Vercel デプロイメントは IP アドレスを使用するため、クラスターのトラフィックフィルターがすべての IP アドレス ( `0.0.0.0/0` } に設定) からの接続を許可して[動的IPアドレス](https://vercel.com/guides/how-to-allowlist-deployment-ip-address)ことを確認してください。 [TiDB Cloud Vercel統合を介してVercelと統合する](#connect-via-the-tidb-cloud-vercel-integration)には、組織の`Organization Owner`ロール、またはTiDB Cloudのターゲット プロジェクトの`Project Owner`ロールに所属することが求められます。詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)を参照してください。 @@ -89,8 +89,7 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ 1. 対象となるVercelプロジェクトを選択し、 **次へ**をクリックしてください。 2. 対象となるTiDB Cloud組織とプロジェクトを選択してください。 3. 接続タイプとして**クラスタ**を選択してください。 - 4. 対象のTiDB Cloudリソースを選択してください。**クラスタ**のドロップダウン リストが空の場合、または新しいTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを選択する場合は、リストの**+ Create Cluster**をクリックして作成してください。 - 5. 接続するデータベースを選択してください。**データベース**のドロップダウンリストが空の場合、または新しいデータベースを選択する場合は、リスト内の**+ Create Database**をクリックして作成してください。 + 4. 対象のTiDB Cloudリソースを選択してください。**クラスタ**のドロップダウンリストが空の場合、または新しいTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを選択する場合は、リストの**+ Create Cluster**をクリックして作成してください。 5. 接続するデータベースを選択してください。**データベース**のドロップダウンリストが空の場合、または新しいデータベースを選択する場合は、リスト内の**+ Create Database**をクリックして作成してください。 6. Vercelプロジェクトで使用しているフレームワークを選択してください。対象のフレームワークが一覧にない場合は、 **一般**を選択してください。フレームワークによって環境変数が異なります。 7. プレビュー環境用に新しいブランチを作成するために、**ブランチ機能**を有効にするかどうかを選択してください。 8. **「統合を追加」をクリックしてVercelに戻ります**。 @@ -247,9 +246,9 @@ TiDB Cloud コンソールでは、 `` 、 `` 、 ``
    -1. データ アプリとそのエンドポイントをまだ作成していない場合は、「データ アプリ[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)と[エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md)の手順に従ってデータ アプリとそのエンドポイントを作成します。 +1. データアプリとそのエンドポイントをまだ作成していない場合は、「データアプリ[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)と[エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md)の手順に従ってデータアプリとそのエンドポイントを作成します。 -2. Vercel ダッシュボード > Vercel プロジェクト >**設定**>**Environment Variables**に移動し、データ アプリの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 +2. Vercel ダッシュボード > Vercel プロジェクト >**設定**>**Environment Variables**に移動し、データアプリの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 ![Vercel Environment Variables](/media/tidb-cloud/vercel/integration-vercel-environment-variables.png) diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index b855ad0ddfbb0..0649371acbea2 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -62,9 +62,8 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 2. アカウントを選択 1. **Sign in**ボタンをクリックすると、新しいログインページにリダイレクトされます。 - 2. ログイン ページで、公開キーと秘密キーを入力します。 TiDB Cloud API キーを取得するには、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)ドキュメントの手順に従ってください。 + 2. ログインページで、公開キーと秘密キーを入力します。 TiDB Cloud API キーを取得するには、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)ドキュメントの手順に従ってください。 3. **続行**をクリックしてください。 - ![Account](/media/tidb-cloud/zapier/zapier-tidbcloud-account.png) 3. アクションを設定する diff --git a/tidb-cloud/key-concepts.md b/tidb-cloud/key-concepts.md index b76d0cf7ea91b..1fb752338034f 100644 --- a/tidb-cloud/key-concepts.md +++ b/tidb-cloud/key-concepts.md @@ -13,7 +13,7 @@ TiDB Cloudは、コンピューティングをストレージから分離する ## データベーススキーマ {#database-schema} -TiDB Cloudを使用すると、データベース、テーブル、列、インデックス、制約などのオブジェクトを使用してデータを整理および構造化できます。また、一時テーブル、ベクトル インデックス、キャッシュされたテーブルなどの高度な機能もサポートしています。[データベーススキーマについて詳しくはこちらをご覧ください](/tidb-cloud/database-schema-concepts.md)。 +TiDB Cloudを使用すると、データベース、テーブル、列、インデックス、制約などのオブジェクトを使用してデータを整理および構造化できます。また、一時テーブル、ベクトルインデックス、キャッシュされたテーブルなどの高度な機能もサポートしています。[データベーススキーマについて詳しくはこちらをご覧ください](/tidb-cloud/database-schema-concepts.md)。 ## トランザクション {#transactions} @@ -33,7 +33,7 @@ Data Serviceを使用すると、カスタム API エンドポイントを使用 ## 拡張性 {#scalability} -TiDB Cloud Dedicated を使用すると、データ量やワークロードの変化に合わせてコンピューティング リソースとストレージリソースを個別に調整できます。[拡張性について詳しくはこちらをご覧ください](/tidb-cloud/scalability-concepts.md)。 +TiDB Cloud Dedicated を使用すると、データ量やワークロードの変化に合わせてコンピューティングリソースとストレージリソースを個別に調整できます。[拡張性について詳しくはこちらをご覧ください](/tidb-cloud/scalability-concepts.md)。 ## 高可用性 {#high-availability} diff --git a/tidb-cloud/manage-user-access.md b/tidb-cloud/manage-user-access.md index 82b5c1f495840..a4a00bd85779b 100644 --- a/tidb-cloud/manage-user-access.md +++ b/tidb-cloud/manage-user-access.md @@ -105,7 +105,7 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル | ------------------------------------------------------------------------------------------------ | -------------------- | ------------------------------ | ----------------------------- | ------------------------------------ | --------------------- | | プロジェクト、APIキー、タイムゾーンなどの組織設定を管理します。 | ✅ | ❌ | ❌ | ❌ | ❌ | | 組織へのユーザーの招待や削除、およびユーザーの組織内役割の編集を行います。 | ✅ | ❌ | ❌ | ❌ | ❌ | -| 組織内のすべてのプロジェクトに対する`Project Owner`のすべての権限、および組織内のすべての TiDB X インスタンスに対する TiDB X インスタンス ロールのすべての権限。 | ✅ | ❌ | ❌ | ❌ | ❌ | +| 組織内のすべてのプロジェクトに対する`Project Owner`のすべての権限、および組織内のすべての TiDB X インスタンスに対する TiDB X インスタンスロールのすべての権限。 | ✅ | ❌ | ❌ | ❌ | ❌ | | 顧客管理暗号化キー（CMEK）を有効にしたプロジェクトを作成します。 | ✅ | ❌ | ❌ | ❌ | ❌ | | 組織の支払い情報を編集します。 | ✅ | ✅ | ❌ | ❌ | ❌ | | 請求書を確認し、 [コストエクスプローラー](/tidb-cloud/tidb-cloud-billing.md#cost-explorer)を使用します。 | ✅ | ✅ | ✅ | ❌ | ❌ | @@ -141,8 +141,8 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル | バックアップからインスタンスまたはクラスターを新しいリソースとして復元します。 | ✅ | ❌ | ❌ | ❌ | | データを読み取るためのエンドポイントの使用または作成など、データ読み取り専用操作の[Data Service](/tidb-cloud/data-service-overview.md)を管理します。 | ✅ | ✅ | ✅ | ❌ | | データの読み取りおよび書き込み操作のための[Data Service](/tidb-cloud/data-service-overview.md)を管理します。 | ✅ | ✅ | ❌ | ❌ | -| リソース タイプでサポートされている場合は、[SQLエディタ](/tidb-cloud/explore-data-with-chat2query.md)を使用してリソース データを確認する。 | ✅ | ✅ | ✅ | ❌ | -| リソースの種類でサポートされている場合は、[SQLエディタ](/tidb-cloud/explore-data-with-chat2query.md)を使用してリソース データを変更および削除します。 | ✅ | ✅ | ❌ | ❌ | +| リソース タイプでサポートされている場合は、[SQLエディタ](/tidb-cloud/explore-data-with-chat2query.md)を使用してリソースデータを確認する。 | ✅ | ✅ | ✅ | ❌ | +| リソースの種類でサポートされている場合は、[SQLエディタ](/tidb-cloud/explore-data-with-chat2query.md)を使用してリソースデータを変更および削除します。 | ✅ | ✅ | ❌ | ❌ | | [変更フィード](/tidb-cloud/changefeed-overview.md)を管理します。 | ✅ | ✅ | ✅ | ❌ | | リソースの種類が対応している場合は、リソースのパスワードを確認し、リセットしてください。 | ✅ | ❌ | ❌ | ❌ | | プロジェクト内のリソースの概要、バックアップ レコード、メトリック、イベント、および[変更フィード](/tidb-cloud/changefeed-overview.md)を確認する。 | ✅ | ✅ | ✅ | ✅ | @@ -333,7 +333,7 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー ### TiDB Xインスタンスへのアクセス権を付与する {#grant-access-to-a-tidb-x-instance} {#grant-access-to-a-tidb-x-instance} -`Organization Owner`または`Project Owner`ロールに属している場合は、特定の TiDB X インスタンスのインスタンス ロールをユーザーに付与できます。 +`Organization Owner`または`Project Owner`ロールに属している場合は、特定の TiDB X インスタンスのインスタンスロールをユーザーに付与できます。 > **Note:** > @@ -349,7 +349,7 @@ TiDB Xインスタンスへのアクセス権を付与するには、以下の > **Tip:** > - > ユーザーがまだ組織に属していない場合は、右上隅にある**Invite User**をクリックし、[ユーザーを組織に招待する](#invite-a-user-to-your-organization)の手順に従って、ユーザーにインスタンス ロールを付与します。 + > ユーザーがまだ組織に属していない場合は、右上隅にある**Invite User**をクリックし、[ユーザーを組織に招待する](#invite-a-user-to-your-organization)の手順に従って、ユーザーにインスタンスロールを付与します。 4. **Edit Role**ページで、 **インスタンスアクセス**セクションの**Instance access**をクリックし、ユーザーにロールを付与して、対象のTiDB Xインスタンスを選択します。 diff --git a/tidb-cloud/managed-service-provider-customer.md b/tidb-cloud/managed-service-provider-customer.md index 8852ded751e65..ca4a166b6bf71 100644 --- a/tidb-cloud/managed-service-provider-customer.md +++ b/tidb-cloud/managed-service-provider-customer.md @@ -1,11 +1,11 @@ --- title: Managed Service Provider Customer -summary: マネージド サービス プロバイダー (MSP) の顧客になる方法を学びます。 +summary: マネージドサービス プロバイダー (MSP) の顧客になる方法を学びます。 --- # マネージドサービスプロバイダーの顧客 {#managed-service-provider-customer} -マネージド サービス プロバイダー (MSP) 顧客とは、マネージド サービス プロバイダーが提供するTiDB Cloudサービスを使用する顧客です。 +マネージドサービス プロバイダー (MSP) 顧客とは、マネージドサービス プロバイダーが提供するTiDB Cloudサービスを使用する顧客です。 TiDB Cloud の直接顧客と比較すると、サインアップと請求書の支払いに関していくつかの違いがあります。 diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index 7c6b1d1fd0efe..8bd7a52e56a5c 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -18,13 +18,13 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 移行を開始する前に、以下の内容を必ずお読みください。 - ソースデータベースが Amazon RDS または Amazon Auroraの場合、 `binlog_format`パラメータを`ROW`に設定する必要があります。データベースがデフォルトのパラメータ グループを使用する場合、 `binlog_format`パラメータはデフォルトで`MIXED`となり、変更できません。この場合、 [新しいパラメータグループを作成する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.Prerequisites.html#CHAP_GettingStarted.Prerequisites.params)必要があります (例: `newset` 。その`binlog_format`を`ROW`に設定します。次に、 [デフォルトパラメータグループを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithDBInstanceParamGroups.html#USER_WorkingWithParamGroups.Modifying)`newset`に変更します。パラメータ グループを変更するとデータベースが再起動されることに注意してください。 -- ソース データベースが TiDB と互換性のある照合順序を使用していることを確認してください。TiDB の utf8mb4 文字セットのデフォルトの照合照合順序は`utf8mb4_bin`です。しかし、MySQL 8.0 では、デフォルトの照合照合順序は`utf8mb4_0900_ai_ci`です。アップストリームの MySQL がデフォルトの照合順序を使用している場合、TiDB は`utf8mb4_0900_ai_ci`と互換性がないため、AWS DMS は TiDB にターゲット テーブルを作成できず、データを移行できません。この問題を解決するには、移行前にソース データベースの照合順序`utf8mb4_bin`に変更する必要があります。TiDB でサポートされている文字セットと照合順序の完全なリストについては、 [文字セットと照合](https://docs.pingcap.com/tidb/stable/character-set-and-collation)を参照してください。 -- TiDB には、デフォルトで`INFORMATION_SCHEMA` 、 `PERFORMANCE_SCHEMA` 、 `mysql` 、 `sys` } 、および`test`システム データベースが含まれています。AWS DMS 移行タスクを作成する際は、デフォルトの`%`を使用して移行オブジェクトを選択するのではなく、これらのシステム データベースを除外する必要があります。そうしないと、AWS DMS はこれらのシステム データベースをソース データベースからターゲット TiDB に移行しようとし、タスクが失敗します。この問題を回避するには、特定のデータベース名とテーブル名を入力することをお勧めします。 +- ソースデータベースが TiDB と互換性のある照合順序を使用していることを確認してください。TiDB の utf8mb4 文字セットのデフォルトの照合照合順序は`utf8mb4_bin`です。しかし、MySQL 8.0 では、デフォルトの照合照合順序は`utf8mb4_0900_ai_ci`です。アップストリームの MySQL がデフォルトの照合順序を使用している場合、TiDB は`utf8mb4_0900_ai_ci`と互換性がないため、AWS DMS は TiDB にターゲットテーブルを作成できず、データを移行できません。この問題を解決するには、移行前にソースデータベースの照合順序`utf8mb4_bin`に変更する必要があります。TiDB でサポートされている文字セットと照合順序の完全なリストについては、 [文字セットと照合](https://docs.pingcap.com/tidb/stable/character-set-and-collation)を参照してください。 +- TiDB には、デフォルトで`INFORMATION_SCHEMA` 、 `PERFORMANCE_SCHEMA` 、 `mysql` 、 `sys` } 、および`test`システムデータベースが含まれています。AWS DMS 移行タスクを作成する際は、デフォルトの`%`を使用して移行オブジェクトを選択するのではなく、これらのシステムデータベースを除外する必要があります。そうしないと、AWS DMS はこれらのシステムデータベースをソースデータベースからターゲット TiDB に移行しようとし、タスクが失敗します。この問題を回避するには、特定のデータベース名とテーブル名を入力することをお勧めします。 - AWS DMSのパブリックネットワークIPアドレスとプライベートネットワークIPアドレスを、ソースデータベースとターゲットデータベースの両方のIPアクセスリストに追加してください。そうしないと、状況によってはネットワーク接続が失敗する可能性があります。 - [VPCピアリング](/tidb-cloud/set-up-vpc-peering-connections.md#set-up-vpc-peering-on-aws)または[プライベートエンドポイント接続](/tidb-cloud/set-up-private-endpoint-connections.md)を使用して、AWS DMS と TiDB クラスターを接続します。 - データ書き込みパフォーマンスを向上させるため、AWS DMSとTiDBクラスターには同じリージョンを使用することをお勧めします。 - AWS DMS `dms.t3.large` （2 vCPU、8 GiBメモリ）以上のインスタンスクラスを使用することをお勧めします。インスタンスクラスが小さい場合、メモリ不足（OOM）エラーが発生する可能性があります。 -- AWS DMS は、ターゲット データベースに`awsdms_control`データベースを自動的に作成します。 +- AWS DMS は、ターゲットデータベースに`awsdms_control`データベースを自動的に作成します。 ## 制限 {#limitation} @@ -100,8 +100,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のリソース名をクリックしてから、右上隅の**[接続]**をクリックすると、 TiDB Cloudデータベースの接続情報が表示されます。 -3. ダイアログの**ステップ 1: トラフィック フィルタの作成**で、 **編集**をクリックし、AWS DMS コンソールからコピーしたパブリック IP アドレスとプライベート IP アドレスを入力して、 **Update Filter**をクリックします。AWS DMS レプリケーション インスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスタのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスタに接続できない場合があります。 - +3. ダイアログの**ステップ 1: トラフィック フィルタの作成**で、 **編集**をクリックし、AWS DMS コンソールからコピーしたパブリック IP アドレスとプライベート IP アドレスを入力して、 **Update Filter**をクリックします。AWS DMS レプリケーションインスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスタのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスタに接続できない場合があります。 4. **Download CA cert**をクリックします。ダイアログの**[ステップ3：SQLクライアントで接続する**]で、接続文字列内の`-u` 、 `-h` 、および`-P`情報を後で使用するためにメモしておきます。 5. ダイアログの**VPC Peering**タブをクリックし、 **Step 1: Set up VPC**の下にある**Add**をクリックして、TiDBクラスターとAWS DMSのVPCピアリング接続を作成します。 @@ -170,7 +169,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 4. **Table mappings**のセクションで、移行するデータベースを指定します。 - スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**Source name**のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステム データベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステム データベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 + スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**Source name**のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステムデータベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステムデータベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 ![Table mappings](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-table-mappings.png) diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 4a2d410deb0c3..6735fdc4c8255 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -105,7 +105,7 @@ Alibaba Cloud RDSをデータソースとして使用する場合、すべての -- TiDB Cloud Premium では、論理モード (デフォルト) と物理モードの両方がサポートされています。論理モードでは、MySQL ソース データベースから SQL ステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premium インスタンスで実行します。このとき、ロード中にリクエストキャパシティユニット (RCU) が消費されます。物理モードでは、ターゲットのTiDB Cloud Premium インスタンスで`IMPORT INTO`を使用し、ロードのスループットとコスト効率を優先する場合の大規模データセットに推奨されます。 +- TiDB Cloud Premium では、論理モード (デフォルト) と物理モードの両方がサポートされています。論理モードでは、MySQL ソースデータベースから SQL ステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premium インスタンスで実行します。このとき、ロード中にリクエストキャパシティユニット (RCU) が消費されます。物理モードでは、ターゲットのTiDB Cloud Premium インスタンスで`IMPORT INTO`を使用し、ロードのスループットとコスト効率を優先する場合の大規模データセットに推奨されます。 - 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 @@ -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,13 +136,13 @@ 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 インスタンスで重複した行が発生する可能性があります。 ## 前提条件 {#prerequisites} -移行する前に、データ ソースがサポートされているかどうかを確認し、MySQL 互換データベースでバイナリ ロギングを有効にし、ネットワーク接続を確認して、ソース データベースとターゲットTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスインスタンス データベースの両方に必要な権限を付与します。 +移行する前に、データソースがサポートされているかどうかを確認し、MySQL 互換データベースでバイナリ ロギングを有効にし、ネットワーク接続を確認して、ソースデータベースとターゲットTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスインスタンス データベースの両方に必要な権限を付与します。 ### データソースとバージョンがサポートされていることを確認してください。 {#make-sure-your-data-source-and-version-are-supported} @@ -178,7 +177,7 @@ TiDB Cloud Essentialのデータ移行機能は、以下のデータソースと -TiDB Cloud Premium の場合、データ移行機能は次の MySQL 互換ソース データベースをサポートしており、 **MySQL は**移行ジョブ ウィザードで使用できる唯一のデータ ソース タイプです。サポートされている接続方法については、[ネットワーク接続を確保する](#ensure-network-connectivity)を参照してください。 +TiDB Cloud Premium の場合、データ移行機能は次の MySQL 互換ソースデータベースをサポートしており、 **MySQL は**移行ジョブ ウィザードで使用できる唯一のデータソース タイプです。サポートされている接続方法については、[ネットワーク接続を確保する](#ensure-network-connectivity)を参照してください。 | データソース | サポートされているバージョン | | :--------------------------------- | :------------- | @@ -193,7 +192,7 @@ TiDB Cloud Premium の場合、データ移行機能は次の MySQL 互換ソー ### レプリケーションのために、ソースのMySQL互換データベースでバイナリログを有効にする {#enable-binary-logs-in-the-source-mysql-compatible-database-for-replication} -DM を使用して、ソースの MySQL 互換データベースからターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスに増分変更を継続的にレプリケートするには、ソース データベースでバイナリ ログを有効にするために次の構成が必要です。 +DM を使用して、ソースの MySQL 互換データベースからターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスに増分変更を継続的にレプリケートするには、ソースデータベースでバイナリ ログを有効にするために次の構成が必要です。 | コンフィグレーション | 必要値 | なぜ | | :------------------------------- | :------------------------------- | :---------------------------------------- | @@ -242,7 +241,7 @@ SHOW VARIABLES WHERE Variable_name IN
    AWS RDSまたはAurora MySQLの設定 -1. AWS マネジメント コンソールで、 [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、左側のナビゲーション ペインで**Parameter groups**をクリックし、カスタム パラメータ グループを作成または編集します。 +1. AWS マネジメントコンソールで、 [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、左側のナビゲーションペインで**Parameter groups**をクリックし、カスタム パラメータ グループを作成または編集します。 2. 上記の4つのパラメータを必要な値に設定してください。 3. パラメータグループをインスタンスまたはクラスターにアタッチし、再起動して変更を適用してください。 4. 再起動後、インスタンスに接続し、 `SHOW VARIABLES`ステートメントを実行して構成を確認します。 @@ -253,7 +252,7 @@ SHOW VARIABLES WHERE Variable_name IN
    Azure Database for MySQL の構成 - Flexible Server -1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL サーバー**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**[設定]** > **Server parameters**をクリックします。 +1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL サーバー**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーションペインで**[設定]** > **Server parameters**をクリックします。 2. 各パラメータを検索し、その値を更新します。 @@ -284,7 +283,7 @@ SHOW VARIABLES WHERE Variable_name IN - `binlog_row_image` : `FULL` -3. 左側のナビゲーション ペインで、 **Backup and Restoration**をクリックし、 **Backup Strategy**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。 +3. 左側のナビゲーションペインで、 **Backup and Restoration**をクリックし、 **Backup Strategy**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。 - 保存期間：最低3日間（推奨7日間）に設定してください。 @@ -391,7 +390,7 @@ TiDB Cloud Premiumで利用可能な接続方法は以下のとおりです。 AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサポートしていません。そのため、ネットワークロードバランサー (NLB) を作成し、それをソース MySQL インスタンスに関連付けられたエンドポイントサービスとして公開し、TiDB Cloud の AWS プリンシパルがそのサービスを利用できるように承認する必要があります。 -1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲット グループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 +1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲットグループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 @@ -399,8 +398,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 - [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**Network Interfaces**をクリックし、 **Description** = `RDSNetworkInterface`と**VPC** = ご使用の VPC でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 - + [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーションペインで**Network Interfaces**をクリックし、 **Description** = `RDSNetworkInterface`と**VPC** = ご使用の VPC でフィルタリングします。一致するネットワークインターフェイスに表示されている**Primary private IPv4 address**を使用します。 > **Note:** > > RDS プライベート IP は、フェールオーバー、メンテナンス、またはストレージの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーション パターンについて、AWS データベース ブログの[AWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/)を参照してください。 @@ -437,17 +435,16 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ
    -
    Azure PrivateLink と MySQL ソース データベース用のプライベート エンドポイントを設定します。 +
    Azure PrivateLink と MySQL ソースデータベース用のプライベートエンドポイントを設定します。 Azure Database for MySQL - Flexible Server は、ネイティブのプライベートエンドポイントをサポートしています。MySQL インスタンスの作成時にプライベートアクセス (VNet 統合) を有効にするか、後からプライベートエンドポイントを追加することができます。 新しいプライベートエンドポイントを追加するには、以下の手順を実行してください。 -1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL サーバー**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**設定** > **ネットワーク**をクリックします。 - +1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL サーバー**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーションペインで**設定** > **ネットワーク**をクリックします。 2. **ネットワーク設定**ページで、**Private endpoints**セクションまでスクロールダウンし、 **+ Create private endpoint**をクリックして、画面の指示に従ってプライベートエンドポイントを設定します。 - セットアップ中に、**Virtual Network**タブでTiDB Cloud がアクセスできる仮想ネットワークとサブネットを選択し、 **DNS**タブで**Private DNS integration**を有効にします。プライベートエンドポイントが作成されてデプロイされたら、 **Go to resource**をクリックし、左側のナビゲーション ペインで**[設定]** > **DNS configuration**をクリックして、**Customer Visible FQDNs**セクションでインスタンスへの接続に使用するホスト名を見つけます。通常、ホスト名は`.mysql.database.azure.com`形式です。 + セットアップ中に、**Virtual Network**タブでTiDB Cloud がアクセスできる仮想ネットワークとサブネットを選択し、 **DNS**タブで**Private DNS integration**を有効にします。プライベートエンドポイントが作成されてデプロイされたら、 **Go to resource**をクリックし、左側のナビゲーションペインで**[設定]** > **DNS configuration**をクリックして、**Customer Visible FQDNs**セクションでインスタンスへの接続に使用するホスト名を見つけます。通常、ホスト名は`.mysql.database.azure.com`形式です。 詳細な手順については、Azure ドキュメントの[プライベートリンクセンターを使用してプライベートエンドポイントを作成します](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-networking-private-link-portal#create-a-private-endpoint-via-private-link-center)を参照してください。 @@ -457,7 +454,7 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -4. [Azureポータル](https://portal.azure.com/)の で、MySQL Flexible Server インスタンスの概要ページ (プライベート エンドポイント オブジェクトではありません) に戻り、 **[Essentials]**セクションで**[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/`形式です。このリソース ID (プライベート エンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。 +4. [Azureポータル](https://portal.azure.com/)の で、MySQL Flexible Server インスタンスの概要ページ (プライベートエンドポイント オブジェクトではありません) に戻り、 **[Essentials]**セクションで**[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/`形式です。このリソース ID (プライベートエンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。 5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 @@ -466,7 +463,7 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ -プロバイダーネイティブのプライベート リンクまたはプライベート エンドポイントを使用する場合は、ソース MySQL インスタンスに対して[プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)を作成します。 +プロバイダーネイティブのプライベートリンクまたはプライベートエンドポイントを使用する場合は、ソース MySQL インスタンスに対して[プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)を作成します。 @@ -477,7 +474,7 @@ AWS 上でホストされているTiDB Cloud Premium インスタンスの場合 AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサポートしていません。そのため、ネットワークロードバランサー (NLB) を作成し、それをソース MySQL インスタンスに関連付けられたエンドポイントサービスとして公開し、TiDB Cloud の AWS プリンシパルがそのサービスを利用できるように承認する必要があります。 -1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲット グループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 +1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲットグループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 @@ -485,8 +482,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 - [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**Network Interfaces**をクリックし、 **Description** = `RDSNetworkInterface`と**VPC** = ご使用の VPC でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 - + [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーションペインで**Network Interfaces**をクリックし、 **Description** = `RDSNetworkInterface`と**VPC** = ご使用の VPC でフィルタリングします。一致するネットワークインターフェイスに表示されている**Primary private IPv4 address**を使用します。 > **Note:** > > RDS プライベート IP は、フェールオーバー、メンテナンス、またはストレージの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーション パターンについて、AWS データベース ブログの[AWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/)を参照してください。 @@ -590,13 +586,13 @@ MySQLサービスがGoogle Cloud VPC内にある場合は、以下の手順を - [TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)イングレス ファイアウォール ルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Dedicatedクラスターから MySQL エンドポイントに流れることが可能になります。 + [TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)イングレス ファイアウォールルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Dedicatedクラスターから MySQL エンドポイントに流れることが可能になります。 - [TiDB Cloud Essentialインスタンスが配置されているリージョンのCIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)イングレス ファイアウォール ルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Essentialインスタンスから MySQL エンドポイントに流れることが可能になります。 + [TiDB Cloud Essentialインスタンスが配置されているリージョンのCIDR](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)イングレス ファイアウォールルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Essentialインスタンスから MySQL エンドポイントに流れることが可能になります。 @@ -660,7 +656,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **Data Migration**をクリックします。 +2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **Data Migration**をクリックします。 3. **Data Migration**ページで、右上隅にある**Create Migration Job**をクリックします。**Create Migration Job**ページが表示されます。 @@ -715,16 +711,14 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 - **公開**を選択した場合は、 **Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 - - **Private Link**が選択されている場合は、[プライベートリンク[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)セクションで作成したプライベート リンク接続を選択します。 - + - **Private Link**が選択されている場合は、[プライベートリンク[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)セクションで作成したプライベートリンク接続を選択します。 - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 - **公開**を選択した場合は、 **Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 - - **Private Link**が選択されている場合は、 **Private Endpoint**フィールドで既存のプライベート エンドポイントを選択するか、 **[ここでプライベート エンドポイントを作成] をクリックしてプライベート エンドポイント**を作成します。プライベート エンドポイントは、 TiDB Cloud Premium インスタンスの**[ネットワーキング]** > **[AWS 外部サービス用プライベートエンドポイント]**で管理されます。プライベート エンドポイントは、複数のデータ移行ジョブおよび変更フィード間で再利用できます。設定の詳細については、[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)をご覧ください。 - + - **Private Link**が選択されている場合は、 **Private Endpoint**フィールドで既存のプライベートエンドポイントを選択するか、 **[ここでプライベートエンドポイントを作成] をクリックしてプライベートエンドポイント**を作成します。プライベートエンドポイントは、 TiDB Cloud Premium インスタンスの**[ネットワーキング]** > **[AWS 外部サービス用プライベートエンドポイント]**で管理されます。プライベートエンドポイントは、複数のデータ移行ジョブおよび変更フィード間で再利用できます。設定の詳細については、[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)をご覧ください。 - **ポート**：データソースのポート番号。 @@ -754,7 +748,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - このオプションは、MySQLサーバーで移行ユーザーに対して`REQUIRE X509`または`REQUIRE SSL`が設定されている場合に必要です。 - このオプションは、MySQLサーバーが認証のためにクライアント証明書を必要とする場合に使用されます。 - 証明書は以下の情報源から入手できます。 - - クラウド プロバイダーからダウンロードします ( [TLS証明書リンク](#end-to-end-encryption-over-tlsssl)を参照)。 + - クラウドプロバイダーからダウンロードします ( [TLS証明書リンク](#end-to-end-encryption-over-tlsssl)を参照)。 - 組織の内部認証局証明書を使用してください。 - 自己署名証明書（開発／テスト専用）。 @@ -772,7 +766,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 接続方法として**Public IP**または**VPC Peering**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - 接続方法として**Private Link**を使用する場合、エンドポイント要求を承認するよう求められます。 - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 - - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 + - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 98f41ce394fff..ac71bd80748fc 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -143,8 +143,7 @@ AWS コンソールでアクセスキーを作成します。詳細について 2. 右上にあるナビゲーションバーでユーザー名を選択し、 **My Security Credentials**をクリックします。 -3. アクセスキーを作成するには、 **Create access key**をクリックします。次に、 **Download .csv file**を選択して、アクセスキー ID とシークレット アクセスキーをコンピュータの CSV ファイルに保存します。このファイルは安全な場所に保存してください。このダイアログボックスを閉じると、シークレット アクセスキーには再度アクセスできなくなります。CSV ファイルをダウンロードしたら、 **閉じる**を選択します。アクセスキーを作成すると、キー ペアはデフォルトで有効になり、すぐに使用できます。 - +3. アクセスキーを作成するには、 **Create access key**をクリックします。次に、 **Download .csv file**を選択して、アクセスキー ID とシークレットアクセスキーをコンピュータの CSV ファイルに保存します。このファイルは安全な場所に保存してください。このダイアログボックスを閉じると、シークレットアクセスキーには再度アクセスできなくなります。CSV ファイルをダウンロードしたら、 **閉じる**を選択します。アクセスキーを作成すると、キーペアはデフォルトで有効になり、すぐに使用できます。 ![Create access key](/media/tidb-cloud/op-to-cloud-create-access-key01.png) ![Download CSV file](/media/tidb-cloud/op-to-cloud-create-access-key02.png) @@ -217,7 +216,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート - kms:復号化 -3. アクセスポリシーを設定します。 [AWSコンソール > IAM > アクセス管理 > ポリシー](https://console.aws.amazon.com/iamv2/home#/policies)してリージョンに切り替えて、 TiDB Cloudのアクセス ポリシーが既に存在するかどうかを確認します。存在しない場合は、このドキュメントに従ってポリシーを作成します。 [JSONタブでポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 +3. アクセスポリシーを設定します。 [AWSコンソール > IAM > アクセス管理 > ポリシー](https://console.aws.amazon.com/iamv2/home#/policies)してリージョンに切り替えて、 TiDB Cloudのアクセスポリシーが既に存在するかどうかを確認します。存在しない場合は、このドキュメントに従ってポリシーを作成します。 [JSONタブでポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 以下は、JSONポリシーのテンプレート例です。 @@ -287,7 +286,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 3. TiDB Cloudのプランに応じて、TiCDCがTiDB Cloudに接続できるようにするために、以下のいずれかの操作を行ってください。 - - TiDB Cloud StarterまたはEssentialの場合は、 **Authorized Networks**セクションで**Add rule**をクリックします。表示されたダイアログで、TiCDCコンポーネントのパブリック IP アドレスを使用するファイアウォール ルールを追加し、 **[保存]**をクリックします。詳細については、 [パブリックエンドポイント向けにTiDB Cloud StarterまたはEssential Firewallルールを設定する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md#create-and-manage-a-firewall-rule)を参照してください。 + - TiDB Cloud StarterまたはEssentialの場合は、 **Authorized Networks**セクションで**Add rule**をクリックします。表示されたダイアログで、TiCDCコンポーネントのパブリック IP アドレスを使用するファイアウォールルールを追加し、 **[保存]**をクリックします。詳細については、 [パブリックエンドポイント向けにTiDB Cloud StarterまたはEssential Firewallルールを設定する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md#create-and-manage-a-firewall-rule)を参照してください。 - TiDB Cloud Dedicatedの場合は、 **Add IP Address**をクリックします。表示されたダイアログで、 **[IP アドレスを使用する]**を選択し、 [ **+]**をクリックし、TiCDCコンポーネントのパブリック IP アドレスを**IP Address**フィールドに入力して、 **[確認]**をクリックします。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 3. 下流のTiDB Cloudリソースの接続情報を取得します。 @@ -309,7 +308,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート - `--pd` : アップストリームクラスタのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 - - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 + - `--sink-uri` : レプリケーションタスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 ```shell [scheme]://[userinfo@][host]:[port][/path]?[query_parameters] diff --git a/tidb-cloud/migrate-from-oracle-using-aws-dms.md b/tidb-cloud/migrate-from-oracle-using-aws-dms.md index a36b7c7384320..7fa7c247b8e1a 100644 --- a/tidb-cloud/migrate-from-oracle-using-aws-dms.md +++ b/tidb-cloud/migrate-from-oracle-using-aws-dms.md @@ -89,13 +89,13 @@ SQLスクリプトの実行が完了したら、Oracleのデータを確認し 1. AWS DMS コンソールの[レプリケーションインスタンス](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。 -2. VPC 内に`dms.t3.large`を使用して AWS DMS レプリケーション インスタンスを作成します。 +2. VPC 内に`dms.t3.large`を使用して AWS DMS レプリケーションインスタンスを作成します。 ![Create AWS DMS Instance](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-8.png) > **Note:** > -> TiDB Cloud Starterで動作する AWS DMS レプリケーション インスタンスを作成する詳細な手順については、 [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md)を参照してください。 +> TiDB Cloud Starterで動作する AWS DMS レプリケーションインスタンスを作成する詳細な手順については、 [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md)を参照してください。 ## ステップ6．DMSエンドポイントを作成する {#step-6-create-dms-endpoints} 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..c97cc75891611 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 @@ -5,7 +5,7 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa # データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データのみを移行する {#migrate-only-incremental-data-from-mysql-compatible-databases-to-tidb-cloud-using-data-migration} -このドキュメントでは、TiDB Cloud コンソールのデータ移行機能を使用して、クラウド プロバイダー (Amazon Aurora MySQL、Amazon Relational Database Service (RDS)、Google Cloud SQL for MySQL、Azure Database for MySQL、または Alibaba Cloud RDS) 上の MySQL 互換データベース、または自己ホスト型のソース データベースから、 TiDB Cloudコンソールのデータ移行機能を使用して、増分データをTiDB Cloud Dedicated TiDB Cloud Essential TiDB Cloud Premiumに移行する方法について説明します。 +このドキュメントでは、TiDB Cloud コンソールのデータ移行機能を使用して、クラウドプロバイダー (Amazon Aurora MySQL、Amazon Relational Database Service (RDS)、Google Cloud SQL for MySQL、Azure Database for MySQL、または Alibaba Cloud RDS) 上の MySQL 互換データベース、または自己ホスト型のソースデータベースから、 TiDB Cloudコンソールのデータ移行機能を使用して、増分データをTiDB Cloud Dedicated TiDB Cloud Essential TiDB Cloud Premiumに移行する方法について説明します。 @@ -156,7 +156,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **Data Migration**をクリックします。 +2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **Data Migration**をクリックします。 3. **Data Migration**ページで、右上隅にある**Create Migration Job**をクリックします。**Create Migration Job**ページが表示されます。 @@ -170,7 +170,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - **Data source**：データソースの種類。 - **リージョン**：データソースのリージョン。クラウドデータベースの場合のみ必要です。 - - **Connectivity method**: データ ソースの接続方法。現在、接続方法に応じて、パブリックIP、VPCピアリング、またはプライベートリンクを選択できます。接続方法に応じて、パブリックIPまたはプライベートリンクを選択できます。接続方法に応じて、パブリックリンクまたはプライベートリンク（AWSのみ）を選択できます。 + - **Connectivity method**: データソースの接続方法。現在、接続方法に応じて、パブリックIP、VPCピアリング、またはプライベートリンクを選択できます。接続方法に応じて、パブリックIPまたはプライベートリンクを選択できます。接続方法に応じて、パブリックリンクまたはプライベートリンク（AWSのみ）を選択できます。 @@ -181,13 +181,13 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - **Hostname or IP address**（パブリックIPの場合）：データソースのホスト名またはIPアドレス。 - - **Private Link Connection**(プライベート リンク用): [プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)セクションで作成したプライベート リンク接続。 + - **Private Link Connection**(プライベートリンク用): [プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)セクションで作成したプライベートリンク接続。 - **Hostname or IP address**（公開の場合）：データソースのホスト名またはIPアドレス。 - - **Private Endpoint**(プライベート リンク用): TiDB Cloud Premium インスタンスの**[ネットワーキング]** > **[外部サービス向け AWS プライベート エンドポイント]**で作成したプライベート エンドポイント。または、**ここで [プライベート エンドポイントの作成] をクリックしてプライベート エンドポイント**を作成します。セットアップの詳細については、データ移行ガイドの[プライベートリンクまたはプライベートエンドポイント](/tidb-cloud/migrate-from-mysql-using-data-migration.md#private-link-or-private-endpoint)セクションを参照してください。 + - **Private Endpoint**(プライベートリンク用): TiDB Cloud Premium インスタンスの**[ネットワーキング]** > **[外部サービス向け AWS プライベートエンドポイント]**で作成したプライベートエンドポイント。または、**ここで [プライベートエンドポイントの作成] をクリックしてプライベートエンドポイント**を作成します。セットアップの詳細については、データ移行ガイドの[プライベートリンクまたはプライベートエンドポイント](/tidb-cloud/migrate-from-mysql-using-data-migration.md#private-link-or-private-endpoint)セクションを参照してください。 diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md index da1f8272073c3..d32f057acb4a9 100644 --- a/tidb-cloud/migrate-sql-shards.md +++ b/tidb-cloud/migrate-sql-shards.md @@ -74,7 +74,7 @@ Dumplingを使用してデータをAmazon S3にエクスポートする場合、 - アップストリームクラスターのbinlogを有効にします。 - 適切なAmazon S3ディレクトリとリージョンを選択してください。 -- 上流クラスタへの影響を最小限に抑えるには、 `-t`オプションを設定して適切な同時実行数を選択するか、バックアップ データベースから直接エクスポートしてください。このパラメータの使用方法の詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)を参照してください。 +- 上流クラスタへの影響を最小限に抑えるには、 `-t`オプションを設定して適切な同時実行数を選択するか、バックアップデータベースから直接エクスポートしてください。このパラメータの使用方法の詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)を参照してください。 - `--filetype csv`と`--no-schemas`に適切な値を設定します。これらのパラメーターの使用方法の詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)を参照してください。 CSVファイルの名前は以下のようにしてください。 @@ -183,7 +183,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 + 2. ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 2. **クラウドストレージからデータをインポート**を選択し、次に**Amazon S3**をクリックします。 @@ -192,12 +192,12 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 - **Import File Count**： TiDB Cloud StarterまたはTiDB Cloud Essentialの場合は、 **Multiple files**を選択してください。このフィールドはTiDB Cloud Dedicatedでは利用できません。 - **Included Schema Files**:**いいえ**を選択します。 - **Data Format**： **CSV**を選択してください。 - - **Folder URI** : ソース データのバケット URI を入力してください。この例では、テーブルに対応する第 2 階層のディレクトリ`s3://dumpling-s3/store/sales/`を使用することで、 TiDB Cloud はすべての MySQL インスタンスのデータを`store.sales`に一度にインポートしてマージできます。 + - **Folder URI** : ソースデータのバケット URI を入力してください。この例では、テーブルに対応する第 2 階層のディレクトリ`s3://dumpling-s3/store/sales/`を使用することで、 TiDB Cloud はすべての MySQL インスタンスのデータを`store.sales`に一度にインポートしてマージできます。 - **Bucket Access**> **AWS Role ARN** ：取得したロールARNを入力してください。 バケットの場所がTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターと異なる場合は、クロスリージョンのコンプライアンスを確認してください。 - TiDB Cloudは、指定されたバケット URI 内のデータにアクセスできるかどうかの検証を開始します。検証後、 TiDB Cloudはデフォルトのファイル命名パターンを使用してデータ ソース内のすべてのファイルのスキャンを試行し、次のページの左側にスキャンの概要結果を返します。 `AccessDenied`エラーが発生した場合は、 [S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)を参照してください。 + TiDB Cloudは、指定されたバケット URI 内のデータにアクセスできるかどうかの検証を開始します。検証後、 TiDB Cloudはデフォルトのファイル命名パターンを使用してデータソース内のすべてのファイルのスキャンを試行し、次のページの左側にスキャンの概要結果を返します。 `AccessDenied`エラーが発生した場合は、 [S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)を参照してください。 4. **接続**をクリックしてください。 @@ -209,9 +209,9 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ワイルドカードを使用してソースファイルを照合することもできます。例： - - `s3://[bucket_name]/[data_source_folder]/my-data?.csv` : そのフォルダ内の`my-data`で始まり、その後に 1 文字が続くすべての CSV ファイル (例えば`my-data1.csv`や`my-data2.csv` ) は、同じターゲット テーブルにインポートされます。 + - `s3://[bucket_name]/[data_source_folder]/my-data?.csv` : そのフォルダ内の`my-data`で始まり、その後に 1 文字が続くすべての CSV ファイル (例えば`my-data1.csv`や`my-data2.csv` ) は、同じターゲットテーブルにインポートされます。 - - `s3://[bucket_name]/[data_source_folder]/my-data*.csv` : `my-data`で始まるフォルダ内のすべての CSV ファイルは、同じターゲット テーブルにインポートされます。 + - `s3://[bucket_name]/[data_source_folder]/my-data*.csv` : `my-data`で始まるフォルダ内のすべての CSV ファイルは、同じターゲットテーブルにインポートされます。 `?`と`*`のみがサポートされていることに注意してください。 @@ -508,7 +508,7 @@ Starting component `dmctl`: /root/.tiup/components/dmctl/${tidb_version}/dmctl/d ### ステップ4．レプリケーションタスクのステータスを確認する {#step-4-check-the-replication-task-status} -DM クラスターでレプリケーション タスクが進行中かどうかを確認し、タスクの状態を表示するには、 `query-status`を使用して`tiup dmctl`コマンドを実行します。 +DM クラスターでレプリケーションタスクが進行中かどうかを確認し、タスクの状態を表示するには、 `query-status`を使用して`tiup dmctl`コマンドを実行します。 ```shell [root@localhost ~]# tiup dmctl --master-addr 192.168.11.110:9261 query-status test-task1 diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index cefd2de530ca6..d11f169c3452c 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -65,7 +65,7 @@ TiDB Cloudでは、アラートを無効化または有効化したり、アラ > **Tip:** > - > 現在、 TiDB Cloudでは、アラート ルール編集の機能が限定的に提供されています。一部のアラート ルールは編集をサポートしていません。異なるトリガー条件や頻度を構成したい場合、または[PagerDuty](https://www.pagerduty.com/docs/guides/datadog-integration-guide/)などのダウンストリーム サービスでアラートが自動的にアクションをトリガーする[サードパーティの監視およびアラートとの統合](/tidb-cloud/third-party-monitoring-integrations.md)使用を検討してください。 + > 現在、 TiDB Cloudでは、アラートルール編集の機能が限定的に提供されています。一部のアラートルールは編集をサポートしていません。異なるトリガー条件や頻度を構成したい場合、または[PagerDuty](https://www.pagerduty.com/docs/guides/datadog-integration-guide/)などのダウンストリーム サービスでアラートが自動的にアクションをトリガーする[サードパーティの監視およびアラートとの統合](/tidb-cloud/third-party-monitoring-integrations.md)使用を検討してください。 ## アラート通知を購読する {#subscribe-to-alert-notifications} @@ -89,7 +89,7 @@ TiDB Cloudでは、以下のいずれかの方法でアラート通知を購読 > - TiDB Cloudコンソールでアラートのしきい値を編集できます。 > - 一部のアラートルールはデフォルトで無効になっています。必要に応じて有効にすることができます。 -TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md)に基づいて、 [TiDB Cloudプラン](/tidb-cloud/select-cluster-tier.md)ごとに異なるアラート ルールを提供します。 +TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md)に基づいて、 [TiDB Cloudプラン](/tidb-cloud/select-cluster-tier.md)ごとに異なるアラートルールを提供します。 diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index 5111edbce98d2..972fcc5e3d813 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -96,7 +96,7 @@ TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合 3. **コンフィグレーション**タブで、 **Install Integration**をクリックします。 - クラスターレベルの Datadog 統合の場合、 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 - - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 + - 従来のプロジェクトレベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 ## 事前に構築されたダッシュボードを確認する {#view-the-pre-built-dashboard} @@ -122,7 +122,7 @@ Datadogは、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_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_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ノードのディスク容量（バイト単位）。 | | tidb_cloud.node_cpu_seconds_total | カウント | クラスター名: ``
    インスタンス: tidb-0|tidb-1…|tikv-0…|tiflash-0…
    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPU使用率。 | | tidb_cloud.node_cpu_capacity_cores | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…|tikv-0…|tiflash-0…
    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPUコア数の制限。 | diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index a66aaec3b8283..a66eda60651f1 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -156,7 +156,7 @@ New Relicは、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_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_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ノードのディスク容量（バイト単位）。 | | tidb_cloud.node_cpu_seconds_total (ベータ版のみ) | カウント | クラスター名: ``

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

    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPU使用率。 | | tidb_cloud.node_cpu_capacity_cores | ゲージ | クラスター名: ``

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

    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPUコア数の制限。 | diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index 6c22411486d0f..905781e687364 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -117,7 +117,7 @@ Prometheusは、TiDBクラスタに関して以下のメトリックデータを | tidbcloud_changefeed_latency | ゲージ | changefeed_id | 変更フィードの上流と下流間のデータ複製レイテンシー | | tidbcloud_changefeed_checkpoint_ts | ゲージ | changefeed_id | 変更フィードのチェックポイントタイムスタンプ。ダウンストリームに正常に書き込まれた最大のTSO（タイムスタンプオラクル）を表す。 | | tidbcloud_changefeed_replica_rows | ゲージ | changefeed_id | 変更フィードがダウンストリームに1秒あたりに書き込む複製行数 | -| tidbcloud_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 ステートメントは無期限にハングします。 | +| tidbcloud_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 ステートメントは無期限にハングします。 | | tidbcloud_node_storage_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
    コンポーネント: `tikv\|tiflash` | TiKV/ TiFlashノードのディスク容量（バイト） | | tidbcloud_node_cpu_seconds_total | カウント | クラスター名: ``
    インスタンス: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
    コンポーネント: `tidb\|tikv\|tiflash` | TiDB/TiKV/ TiFlashノードのCPU使用率 | | tidbcloud_node_cpu_capacity_cores | ゲージ | クラスター名: ``
    インスタンス: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
    コンポーネント: `tidb\|tikv\|tiflash` | TiDB/TiKV/ TiFlashノードのCPU制限コア数 | diff --git a/tidb-cloud/oauth2.md b/tidb-cloud/oauth2.md index 72fb41eb10dce..1a71450b45c82 100644 --- a/tidb-cloud/oauth2.md +++ b/tidb-cloud/oauth2.md @@ -21,11 +21,11 @@ OAuthフレームワークは、さまざまなユースケースに合わせて ### デバイスコード付与タイプ {#device-code-grant-type} -これは通常、デバイス フロー内のブラウザーレス デバイスまたは入力が制限されたデバイスによって、以前に取得したデバイス コードをアクセス トークンと交換するために使用されます。 +これは通常、デバイス フロー内のブラウザーレス デバイスまたは入力が制限されたデバイスによって、以前に取得したデバイス コードをアクセストークンと交換するために使用されます。 ### 認可コード付与タイプ {#authorization-code-grant-type} -これは最も一般的な OAuth 2.0 付与タイプであり、ユーザーがアプリを承認した後、Web アプリとネイティブ アプリの両方がアクセス トークンを取得できるようになります。 +これは最も一般的な OAuth 2.0 付与タイプであり、ユーザーがアプリを承認した後、Web アプリとネイティブ アプリの両方がアクセストークンを取得できるようになります。 ## OAuth を使用してTiDB Cloudにアクセスする {#use-oauth-to-access-tidb-cloud} diff --git a/tidb-cloud/optimize-resource-allocation.md b/tidb-cloud/optimize-resource-allocation.md index 1f9866f22929d..43d2b3366facd 100644 --- a/tidb-cloud/optimize-resource-allocation.md +++ b/tidb-cloud/optimize-resource-allocation.md @@ -13,7 +13,7 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups [リソース管理](/tidb-resource-control-ru-groups.md)を使用すると、 TiDB Cloud Dedicatedクラスタのストレージノード（TiKVまたはTiFlash ）を複数の論理グループに分割できます。混在ワークロードを持つシステムでは、ワークロードを個別のリソースグループに割り当てることで、リソースの分離を確保し、QoS要件を満たすことができます。 -クラスターで予期しない SQL パフォーマンスの問題が発生した場合は、リソース グループと併せて[SQLバインディング](/sql-statements/sql-statement-create-binding.md)または[暴走クエリを管理する](/tidb-resource-control-runaway-queries.md)を使用して、特定の SQL ステートメントのリソース消費を一時的に制限できます。 +クラスターで予期しない SQL パフォーマンスの問題が発生した場合は、リソースグループと併せて[SQLバインディング](/sql-statements/sql-statement-create-binding.md)または[暴走クエリを管理する](/tidb-resource-control-runaway-queries.md)を使用して、特定の SQL ステートメントのリソース消費を一時的に制限できます。 リソース制御を効果的に使用することで、クラスターの数を減らし、運用と保守を簡素化し、管理コストを削減できます。 @@ -25,14 +25,14 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups ## リソース制御とTiDBノードグループのいずれかを選択する {#choose-between-resource-control-and-tidb-node-group} -アプリケーションのニーズと予算に基づいて、リソース制御、TiDB ノード グループ機能、またはその両方の組み合わせを使用して、リソースの分離を実現できます。 +アプリケーションのニーズと予算に基づいて、リソース制御、TiDB ノードグループ機能、またはその両方の組み合わせを使用して、リソースの分離を実現できます。 -次の表は、リソース制御と TiDB ノード グループの機能を比較したものです。 +次の表は、リソース制御と TiDB ノードグループの機能を比較したものです。 | 比較項目 | リソース管理 | TiDBノードグループ | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | 分離レベル | TiKVまたはTiFlash論理レイヤー | TiDBノード物理レイヤー | -| フロー制御 | リソース グループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込み要求のフローを制御します。 | サポートされていません。 | +| フロー制御 | リソースグループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込み要求のフローを制御します。 | サポートされていません。 | | コンフィグレーション方法 | SQL文を使用して構成 | TiDB Cloudコンソールから設定 | -| ワークロードの区別 | 次のレベルでのバインディング リソースをサポートします。
    • ユーザーレベル。
    • セッション レベル (セッションごとにリソース グループを設定します)。
    • ステートメント レベル (ステートメントごとにリソース グループを設定します)。
    | さまざまなワークロードに異なる接続エンドポイントを提供します。 | -| 料金 | 追加料金なし | TiDB ノードの追加に関連するコストは発生しますが、TiDB ノード グループの作成には追加コストは発生しません。 | +| ワークロードの区別 | 次のレベルでのバインディング リソースをサポートします。
    • ユーザーレベル。
    • セッションレベル (セッションごとにリソースグループを設定します)。
    • ステートメントレベル (ステートメントごとにリソースグループを設定します)。
    | さまざまなワークロードに異なる接続エンドポイントを提供します。 | +| 料金 | 追加料金なし | TiDB ノードの追加に関連するコストは発生しますが、TiDB ノードグループの作成には追加コストは発生しません。 | diff --git a/tidb-cloud/pause-or-resume-tidb-cluster.md b/tidb-cloud/pause-or-resume-tidb-cluster.md index 3e90f84a18165..643be71bc1d9d 100644 --- a/tidb-cloud/pause-or-resume-tidb-cluster.md +++ b/tidb-cloud/pause-or-resume-tidb-cluster.md @@ -19,7 +19,7 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ - クラスターを一時停止できるのは、クラスターの状態が**利用可能**の場合のみです。クラスターの状態が**変更中**などの場合、一時停止する前に現在の操作が完了するまで待つ必要があります。 - データインポートタスクの実行中は、クラスターを一時停止することはできません。インポートタスクが完了するまで待つか、インポートタスクをキャンセルするかのいずれかを選択してください。 -- バックアップ ジョブの実行中はクラスターを一時停止できません。現在のバックアップ ジョブが完了するまで待つか、 [実行中のバックアップジョブを削除します](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 +- バックアップジョブの実行中はクラスターを一時停止できません。現在のバックアップジョブが完了するまで待つか、 [実行中のバックアップジョブを削除します](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 - クラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)がある場合、クラスターを一時停止することはできません。クラスターを一時停止する前に[既存の変更フィードを削除する](/tidb-cloud/changefeed-overview.md#delete-a-changefeed)必要があります。 - [Point-in-Time Restore (PITR)](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore) が有効になっている場合、クラスターを一時停止することはできません。クラスターを一時停止する前に、**Backup Setting** の **Point-in-time Restore** スイッチをオフにする必要があります。 - [Data Migration](/tidb-cloud/tidb-cloud-migration-overview.md) ジョブの実行中は、クラスターを一時停止することはできません。クラスターを一時停止する前に、移行ジョブが実行されていないことを確認してください。 diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 5e3b498428e7f..607c685926711 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -431,7 +431,7 @@ TiDB Cloud Dedicatedクラスターによって生成されたバックアップ > **Note:** > -> TiDB Cloudはアクセス キーを保存しません。セキュリティを維持するため、インポートまたはエクスポートのタスクが完了した後[アクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)。 +> TiDB Cloudはアクセスキーを保存しません。セキュリティを維持するため、インポートまたはエクスポートのタスクが完了した後[アクセスキーを削除する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)。 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..f0f265c33a0ec 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 @@ -188,7 +188,7 @@ AWS マネジメントコンソールでプライベート DNS を有効にす > **Tip:** > -> インスタンスに接続できない場合、AWS の VPC エンドポイントのセキュリティ グループが正しく設定されていないことが原因である可能性があります。解決策については、[このFAQ](#troubleshooting)を参照してください。 +> インスタンスに接続できない場合、AWS の VPC エンドポイントのセキュリティグループが正しく設定されていないことが原因である可能性があります。解決策については、[このFAQ](#troubleshooting)を参照してください。 ### プライベートエンドポイントの状態参照 {#private-endpoint-status-reference} @@ -215,6 +215,6 @@ AWS マネジメントコンソールでプライベート DNS を有効にす ### プライベートDNSを有効にした後、プライベートエンドポイント経由でTiDB Cloud Premiumインスタンスに接続できません。なぜでしょうか？ {#i-cannot-connect-to-a-tidb-cloud-premium-instance-via-a-private-endpoint-after-enabling-private-dns-why} -AWS マネジメント コンソールで、VPC エンドポイントのセキュリティ グループを適切に設定する必要がある場合があります。そのためには、 **[VPC]** > **[エンドポイント]**に移動し、VPC エンドポイントを右クリックして、 **Manage security groups**を選択します。選択したセキュリティ グループが、ポート`4000`またはお客様定義のポートで EC2 インスタンスからの受信アクセスを許可していることを確認してください。 +AWS マネジメントコンソールで、VPC エンドポイントのセキュリティグループを適切に設定する必要がある場合があります。そのためには、 **[VPC]** > **[エンドポイント]**に移動し、VPC エンドポイントを右クリックして、 **Manage security groups**を選択します。選択したセキュリティグループが、ポート`4000`またはお客様定義のポートで EC2 インスタンスからの受信アクセスを許可していることを確認してください。 ![Manage security groups](/media/tidb-cloud/private-endpoint/manage-security-groups.png) diff --git a/tidb-cloud/premium/connect-to-premium-via-public-connection.md b/tidb-cloud/premium/connect-to-premium-via-public-connection.md index bf69f1f649a13..fbcdcef3c4a19 100644 --- a/tidb-cloud/premium/connect-to-premium-via-public-connection.md +++ b/tidb-cloud/premium/connect-to-premium-via-public-connection.md @@ -18,7 +18,7 @@ summary: パブリック接続を介してTiDB Cloud Premiumに接続する方 > **Tip:** > > - パブリック接続経由​​でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [パブリックエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/connect-via-standard-connection-serverless.md)を参照してください。 -> - パブリック エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 +> - パブリックエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 ## 前提条件：IPアクセスリストの設定 {#prerequisite-configure-ip-access-list} diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 47f445c4a6190..e3ce72b8a8ef6 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -81,7 +81,7 @@ TiDB Cloud PremiumがAmazon S3またはAlibaba Cloud Object Storage Service（OS - CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud Premium インスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 - バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 + バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレットアクセスキーを含む) またはロール ARN の値をメモしておいてください。 - CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud Premium インスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 @@ -110,7 +110,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **Source Files URI** ： - 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 ロール 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 にコピーしてください。 - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 - **Test Bucket Access**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 @@ -126,7 +126,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloud Premiumは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソース ファイルとターゲット テーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 + - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソースファイルとターゲットテーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 - **Advanced options**：パネルを展開して`Ignore compatibility checks (advanced)`の切り替えボタンを表示します。スキーマ互換性検証を意図的にバイパスしたい場合を除き、無効のままにしておいてください。 @@ -179,7 +179,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloud Premiumは**ソース**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソース ファイルとターゲット テーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 + - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソースファイルとターゲットテーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 - **Advanced options**：パネルを展開して`Ignore compatibility checks (advanced)`の切り替えボタンを表示します。スキーマ互換性検証を意図的にバイパスしたい場合を除き、無効のままにしておいてください。 @@ -213,7 +213,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の ### データインポート中の警告を解決する {#resolve-warnings-during-data-import} -**Start Import**をクリックした後、 `can't find the corresponding source files`などの警告メッセージが表示された場合は、正しいソース ファイルを提供するか、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従って既存のファイルの名前を変更するか、**Advanced Settings**を使用して変更することで問題を解決します。 +**Start Import**をクリックした後、 `can't find the corresponding source files`などの警告メッセージが表示された場合は、正しいソースファイルを提供するか、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従って既存のファイルの名前を変更するか、**Advanced Settings**を使用して変更することで問題を解決します。 これらの問題を解決した後、データを再度インポートする必要があります。 diff --git a/tidb-cloud/premium/import-with-mysql-cli-premium.md b/tidb-cloud/premium/import-with-mysql-cli-premium.md index 92d6daa2e7996..6da2c929a9399 100644 --- a/tidb-cloud/premium/import-with-mysql-cli-premium.md +++ b/tidb-cloud/premium/import-with-mysql-cli-premium.md @@ -5,7 +5,7 @@ summary: MySQLコマンドラインクライアント（mysql`）を使用して # MySQLコマンドラインクライアントを使用してTiDB Cloud Premiumにデータをインポートする {#import-data-into-tidb-cloud-premium-using-the-mysql-command-line-client} -このドキュメントでは[MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)を使用してTiDB Cloud Premium にデータをインポートする方法について説明します。( `mysql` )。以下のセクションでは、SQL ファイルまたは CSV ファイルからデータをインポートするための手順を段階的に説明します。このプロセスでは論理インポートが実行され、MySQL コマンドライン クライアントがローカル マシンからTiDB Cloudに対して SQL ステートメントを再生します。 +このドキュメントでは[MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)を使用してTiDB Cloud Premium にデータをインポートする方法について説明します。( `mysql` )。以下のセクションでは、SQL ファイルまたは CSV ファイルからデータをインポートするための手順を段階的に説明します。このプロセスでは論理インポートが実行され、MySQL コマンドライン クライアントがローカルマシンからTiDB Cloudに対して SQL ステートメントを再生します。 > **Tip:** > @@ -96,7 +96,7 @@ SQLファイルからデータをインポートするには、以下の手順 -認証に使用する SQL ユーザーには、テーブルを定義し、ターゲット データベースにデータをロードするために必要な権限(例えば、 `CREATE`および`INSERT` ) が付与されている必要があります。 +認証に使用する SQL ユーザーには、テーブルを定義し、ターゲットデータベースにデータをロードするために必要な権限(例えば、 `CREATE`および`INSERT` ) が付与されている必要があります。 diff --git a/tidb-cloud/premium/migrate-from-op-tidb-premium.md b/tidb-cloud/premium/migrate-from-op-tidb-premium.md index 15106cb7fc51c..560879373a47f 100644 --- a/tidb-cloud/premium/migrate-from-op-tidb-premium.md +++ b/tidb-cloud/premium/migrate-from-op-tidb-premium.md @@ -143,8 +143,7 @@ AWS コンソールでアクセスキーを作成します。詳細について 2. 右上にあるナビゲーションバーでユーザー名を選択し、 **My Security Credentials**をクリックします。 -3. アクセスキーを作成するには、 **Create access key**をクリックします。次に、 **Download .csv file**を選択して、アクセスキー ID とシークレット アクセスキーをコンピュータの CSV ファイルに保存します。このファイルは安全な場所に保存してください。このダイアログボックスを閉じると、シークレット アクセスキーには再度アクセスできなくなります。CSV ファイルをダウンロードしたら、 **閉じる**を選択します。アクセスキーを作成すると、キー ペアはデフォルトで有効になり、すぐに使用できます。 - +3. アクセスキーを作成するには、 **Create access key**をクリックします。次に、 **Download .csv file**を選択して、アクセスキー ID とシークレットアクセスキーをコンピュータの CSV ファイルに保存します。このファイルは安全な場所に保存してください。このダイアログボックスを閉じると、シークレットアクセスキーには再度アクセスできなくなります。CSV ファイルをダウンロードしたら、 **閉じる**を選択します。アクセスキーを作成すると、キーペアはデフォルトで有効になり、すぐに使用できます。 ![Create access key](/media/tidb-cloud/op-to-cloud-create-access-key01.png) ![Download CSV file](/media/tidb-cloud/op-to-cloud-create-access-key02.png) @@ -220,7 +219,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート #### IAMロールを手動で作成する（オプション） {#manually-create-the-iam-role-optional} -組織がCloudFormationスタックをデプロイできない場合は、アクセス ポリシーとIAMロールを手動で作成してください。 +組織がCloudFormationスタックをデプロイできない場合は、アクセスポリシーとIAMロールを手動で作成してください。 1. AWS IAMで、バケット（および該当する場合はKMSキー）に対して以下の操作を許可するポリシーを作成します。 @@ -303,7 +302,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート - `--pd` : アップストリームクラスタのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 - - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 + - `--sink-uri` : レプリケーションタスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 ```shell [scheme]://[userinfo@][host]:[port][/path]?[query_parameters] diff --git a/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md b/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md index f645516abe379..9091e8e56498a 100644 --- a/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md +++ b/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md @@ -32,7 +32,7 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb- - **AWS Endpoint Service**: ダウンストリームサービスのエンドポイントサービス名と、ダウンストリームサービスがデプロイされている可用性ゾーン（AZ）。 - ダウンストリーム サービスでプライベート エンドポイント サービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスを設定します。 + ダウンストリーム サービスでプライベートエンドポイントサービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスを設定します。 - **Amazon MSK Provisioned**: Amazon MSK ProvisionedクラスターのARN。変更フィード用のAmazon MSK Provisionedクラスターの作成方法については、[AWS PrivateLink 経由で Amazon MSK Provisioned クラスターを設定する](/tidb-cloud/setup-aws-msk-provisioned-private-link-service.md)を参照してください。 @@ -49,7 +49,7 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb- TiDB Cloud VPCへのアクセスを許可するには、エンドポイントサービスの許可リストにTiDB CloudのAlibaba CloudアカウントIDを追加する必要があります。 -ダウンストリーム サービスでプライベート エンドポイント サービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスをセットアップします。 +ダウンストリーム サービスでプライベートエンドポイントサービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスをセットアップします。
    @@ -96,9 +96,8 @@ AWS では、ダウンストリームサービスに応じて接続タイプを 7. **TiDB Managed**ドメインまたは**カスタム**ドメインのいずれかを使用して、Kafka用のアドバタイズドリスナーを設定します。 - - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **[生成]**をクリックします。TiDB Cloud は、各アベイラビリティ ゾーンごとにサブドメインを含むブローカー アドレスを生成します。 + - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **[生成]**をクリックします。TiDB Cloud は、各アベイラビリティゾーンごとにサブドメインを含むブローカーアドレスを生成します。 - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメインタイプを**カスタム**に切り替え、**Custom Domain**フィールドにルートドメインを入力し、 **チェック**をクリックしてから、各アベイラビリティゾーンのブローカーサブドメインを指定します。 - 8. **作成**をクリックして設定を検証し、プライベートエンドポイントを作成します。 **Amazon MSK Provisioned** @@ -121,7 +120,7 @@ AWS では、ダウンストリームサービスに応じて接続タイプを 2. **External Services のプライベートエンドポイントの作成**ダイアログで、プライベートエンドポイントの名前を入力します。 -3. リマインダーに従って、TiDB Cloud の Alibaba Cloud アカウント ID をエンドポイント サービスのホワイトリストに追加して、 TiDB Cloud VPC アクセスを許可します。詳細については、 [エンドポイントサービスの許可リストにおけるアカウントIDの管理](https://www.alibabacloud.com/help/en/privatelink/user-guide/add-and-manage-service-whitelists)を参照してください。 +3. リマインダーに従って、TiDB Cloud の Alibaba Cloud アカウント ID をエンドポイントサービスのホワイトリストに追加して、 TiDB Cloud VPC アクセスを許可します。詳細については、 [エンドポイントサービスの許可リストにおけるアカウントIDの管理](https://www.alibabacloud.com/help/en/privatelink/user-guide/add-and-manage-service-whitelists)を参照してください。 4. [ネットワーク](#network)セクションで収集した**Endpoint Service Name**を入力します。 @@ -131,9 +130,8 @@ AWS では、ダウンストリームサービスに応じて接続タイプを 7. **TiDB Managed**ドメインまたは**カスタム**ドメインのいずれかを使用して、Kafka用のアドバタイズドリスナーを設定します。 - - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **[生成]**をクリックします。TiDB は、各アベイラビリティ ゾーンごとにサブドメインを含むブローカー アドレスを生成します。 + - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **[生成]**をクリックします。TiDB は、各アベイラビリティゾーンごとにサブドメインを含むブローカーアドレスを生成します。 - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメインタイプを**カスタム**に切り替え、**Custom Domain**フィールドにルートドメインを入力し、 **チェック**をクリックしてから、各アベイラビリティゾーンのブローカーサブドメインを指定します。 - 8. **作成**をクリックして設定を検証し、プライベートエンドポイントを作成します。 diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index 333b4535d6c88..fc8c5a535cbe0 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -57,7 +57,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA 4. **データベース監査ログストレージコンフィグレーション**ダイアログで、 **AWS IAM Policy Settings**セクションを探し、後で使用するために**TiDB Cloud Account ID**と**TiDB Cloud External ID**を記録してください。 -2. AWS マネジメント コンソールで、 **IAM** > **Access Management** > **Policies**に移動し、 `s3:PutObject`書き込み専用権限を持つストレージバケット ポリシーが存在するかどうかを確認します。 +2. AWS マネジメントコンソールで、 **IAM** > **Access Management** > **Policies**に移動し、 `s3:PutObject`書き込み専用権限を持つストレージバケット ポリシーが存在するかどうかを確認します。 - はいの場合、後で使用するために、一致したストレージバケットポリシーを記録してください。 - そうでない場合は、 **IAM** > **Access Management** > **Policies** > **Create Policy**に移動し、次のポリシー テンプレートに従ってバケット ポリシーを定義します。 @@ -364,7 +364,7 @@ TiDB Cloudは、監査ログ内の各データベースイベントレコード | `CURRENT_DB` | 現在使用しているデータベースの名前。 | | `SQL_TEXT` | 実行されたSQL文。監査ログのマスキングが有効になっている場合は、マスキングされた文が記録されます。 | | `EXECUTE_PARAMS` | `EXECUTE`ステートメントに渡されるパラメータ。イベントクラスに`EXECUTE`が含まれ、かつ編集が無効になっている場合にのみ記録されます。 | -| `AFFECTED_ROWS` | SQL ステートメントによって影響を受けた行数。イベント クラスに`QUERY_DML`が含まれている場合にのみ記録されます。 | +| `AFFECTED_ROWS` | SQL ステートメントによって影響を受けた行数。イベントクラスに`QUERY_DML`が含まれている場合にのみ記録されます。 | ### 接続情報 {#connection-information} diff --git a/tidb-cloud/premium/tidb-cloud-billing-ticdc-ccu.md b/tidb-cloud/premium/tidb-cloud-billing-ticdc-ccu.md index 632f6c4f058cc..0fb801b29017c 100644 --- a/tidb-cloud/premium/tidb-cloud-billing-ticdc-ccu.md +++ b/tidb-cloud/premium/tidb-cloud-billing-ticdc-ccu.md @@ -38,7 +38,7 @@ summary: {{{ .essential }}} と Premium における変更フィードの課金 ### 価格 {#price} -現在、 {{{ .essential }}} と Premium はパブリック プレビュー段階にあります。価格の詳細については、以下のページを参照してください: +現在、 {{{ .essential }}} と Premium はパブリックプレビュー段階にあります。価格の詳細については、以下のページを参照してください: - [{{{ .essential }}} の料金詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/) - [{{{ .premium }}} の料金詳細](https://www.pingcap.com/tidb-cloud-premium-pricing-details/) diff --git a/tidb-cloud/prometheus-grafana-integration.md b/tidb-cloud/prometheus-grafana-integration.md index abefd1276eb05..9fbd4bdd7ef48 100644 --- a/tidb-cloud/prometheus-grafana-integration.md +++ b/tidb-cloud/prometheus-grafana-integration.md @@ -38,7 +38,7 @@ Prometheus サービスでTiDB Cloudのメトリクスを読み取るように 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **[設定]** > **[統合]** > **Integration to Prometheus(PREVIEW)**をクリックします。 +2. 左側のナビゲーションペインで、 **[設定]** > **[統合]** > **Integration to Prometheus(PREVIEW)**をクリックします。 3. **Add File**をクリックすると、現在のTiDB Cloud Premium インスタンス用の`scrape_config`ファイルが生成されて表示されます。 4. `scrape_config`ファイルの内容のコピーを作成して、後で使用してください。 diff --git a/tidb-cloud/recovery-group-delete.md b/tidb-cloud/recovery-group-delete.md index 36989d567bdcc..cee127ec61970 100644 --- a/tidb-cloud/recovery-group-delete.md +++ b/tidb-cloud/recovery-group-delete.md @@ -11,9 +11,9 @@ summary: リカバリグループが不要になった場合に削除する方 データベース セットのレプリケーションを管理するためにリカバリグループが不要になった場合は、システムから削除できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左上隅のコンボボックスを使用してターゲット プロジェクトに切り替えます。 -2. 左側のナビゲーション ペインで、 **Recovery Group**をクリックします。 +2. 左側のナビゲーションペインで、 **Recovery Group**をクリックします。 3. **Recovery Group**ページで、削除するリカバリグループの名前を見つけます。 @@ -22,6 +22,6 @@ summary: リカバリグループが不要になった場合に削除する方 > **Warning** > > - リカバリグループを削除すると、そのリカバリグループに関連付けられているすべてのレプリケーション関係も削除されます。 - > - リカバリ グループに関連付けられたデータベースは、災害から保護されなくなります。 + > - リカバリグループに関連付けられたデータベースは、災害から保護されなくなります。 5. リカバリグループの名前を入力し、 **I understand, delete it**をクリックして、削除の影響を理解していることを確認します。 diff --git a/tidb-cloud/recovery-group-failover.md b/tidb-cloud/recovery-group-failover.md index 9f437310cb02a..154ea4b953a3c 100644 --- a/tidb-cloud/recovery-group-failover.md +++ b/tidb-cloud/recovery-group-failover.md @@ -13,7 +13,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ ## 前提条件 {#prerequisites} -フェールオーバーを実行する前に、リカバリグループが作成され、セカンダリ クラスターに正常にレプリケートされている必要があります。詳細については、 [回復支援グループに参加してみましょう](/tidb-cloud/recovery-group-get-started.md)を参照してください。 +フェールオーバーを実行する前に、リカバリグループが作成され、セカンダリクラスターに正常にレプリケートされている必要があります。詳細については、 [回復支援グループに参加してみましょう](/tidb-cloud/recovery-group-get-started.md)を参照してください。 ![Protected Recovery Group](/media/tidb-cloud/recovery-group/recovery-group-protected.png) @@ -43,7 +43,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ フェイルオーバーが完了すると、セカンダリクラスタ上のレプリカデータベースがプライマリコピーになります。しかし、フェイルオーバー処理によってレプリケーション関係が停止するため、これらのデータベースは将来の災害に対して保護されません。 -災害の影響を受けた元のプライマリ クラスターを再びオンラインにできる場合は、 **Reprotect**アクションを使用して、リカバリリージョンから元のリージョンへのレプリケーションを再確立できます。 +災害の影響を受けた元のプライマリクラスターを再びオンラインにできる場合は、 **Reprotect**アクションを使用して、リカバリリージョンから元のリージョンへのレプリケーションを再確立できます。 ![Unprotected Recovery Group](/media/tidb-cloud/recovery-group/recovery-group-unprotected.png) @@ -59,7 +59,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ > **Warning** > - > 再保護操作を実行するために必要なデータレプリケーションの一環として、選択されたデータベースの内容は、ターゲットのTiDB Cloud Dedicatedクラスター上で、（新しい）プライマリ クラスターのデータベースの内容に置き換えられます。ターゲットのTiDB Cloud Dedicatedクラスター上の固有のコンテンツを保持したい場合は、再保護操作を実行する前にバックアップを完了してください。 + > 再保護操作を実行するために必要なデータレプリケーションの一環として、選択されたデータベースの内容は、ターゲットのTiDB Cloud Dedicatedクラスター上で、（新しい）プライマリクラスターのデータベースの内容に置き換えられます。ターゲットのTiDB Cloud Dedicatedクラスター上の固有のコンテンツを保持したい場合は、再保護操作を実行する前にバックアップを完了してください。 4. リカバリグループの**アクション**メニューをクリックし、 **再保護**をクリックします。再保護ダイアログが表示されます。 diff --git a/tidb-cloud/recovery-group-get-started.md b/tidb-cloud/recovery-group-get-started.md index 2a926f7ac8a58..331f1c0748a28 100644 --- a/tidb-cloud/recovery-group-get-started.md +++ b/tidb-cloud/recovery-group-get-started.md @@ -1,6 +1,6 @@ --- title: Get Started with Recovery Groups -summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表示する方法を学習します。 +summary: TiDB Cloudでリカバリグループを作成し、その詳細を表示する方法を学習します。 --- # リカバリグループの使用を開始する {#get-started-with-recovery-groups} @@ -14,15 +14,15 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 > **Note** > -> 現在、AWS でホストされているTiDB Cloud Dedicated クラスターのみがリカバリ グループをサポートしています。 +> 現在、AWS でホストされているTiDB Cloud Dedicated クラスターのみがリカバリグループをサポートしています。 ## 新しいリカバリグループを作成する {#create-a-new-recovery-group} リカバリグループを作成するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左上隅のコンボボックスを使用してターゲット プロジェクトに切り替えます。 -2. 左側のナビゲーション ペインで、 **Recovery Group**をクリックします。 +2. 左側のナビゲーションペインで、 **Recovery Group**をクリックします。 3. **Recovery Group**ページで、 **Create Recovery Group**をクリックします。 @@ -32,17 +32,17 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 > > 現在サポートされている回復力レベルは1つだけです。詳細については、 [回復力レベルについて](#about-resiliency-levels)を参照してください。 -5. このグループのプライマリ クラスターとなるTiDB Cloud Dedicated クラスターを選択します。 +5. このグループのプライマリクラスターとなるTiDB Cloud Dedicated クラスターを選択します。 -6. このグループのデータベースが複製されるセカンダリ クラスターとなるTiDB Cloud Dedicated クラスターを選択します。 +6. このグループのデータベースが複製されるセカンダリクラスターとなるTiDB Cloud Dedicated クラスターを選択します。 7. このリカバリグループの一部として複製するデータベースを選択します。 > **Note** > - > データベースをグループに割り当てるときは、特定のデータベースを選択するか、プライマリ クラスター (現在および将来) 上のすべての (システム以外の) データベースを選択できます。 + > データベースをグループに割り当てるときは、特定のデータベースを選択するか、プライマリクラスター (現在および将来) 上のすべての (システム以外の) データベースを選択できます。 > - > - **すべてのデータベース (現在および将来) を割り当てる**と、クラスターに追加される将来のデータベースは自動的にこのリカバリ グループに含まれ、セカンダリ クラスターに複製されます。 + > - **すべてのデータベース (現在および将来) を割り当てる**と、クラスターに追加される将来のデータベースは自動的にこのリカバリグループに含まれ、セカンダリクラスターに複製されます。 > - **Assign specific databases**を選択した場合は、セカンダリクラスタにレプリケートするプライマリクラスタ上の特定のデータベースを選択します。将来、プライマリクラスタにデータベースが追加されても、これらの新しいデータベースはこのリカバリグループの一部として自動的にレプリケートされません。 > > 初期レプリケーション中は、転送されるデータ量が多いため、プライマリクラスタまたはセカンダリクラスタでのオンラインクエリのパフォーマンスに影響が出る可能性があります。データベースの初期保護は、比較的混雑していない時間帯にスケジュールしてください。 @@ -55,15 +55,15 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 ## リカバリグループの詳細を確認する {#view-recovery-group-details} -リカバリ グループを作成した後、**Recovery Group Detail**ページでそのステータス情報を表示できます。 +リカバリグループを作成した後、**Recovery Group Detail**ページでそのステータス情報を表示できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左上隅のコンボボックスを使用してターゲット プロジェクトに切り替えます。 -2. 左側のナビゲーション ペインで、 **Recovery Group**をクリックします。 +2. 左側のナビゲーションペインで、 **Recovery Group**をクリックします。 3. **Recovery Group**ページで、表示するリカバリグループの名前をクリックします。 - **Recovery Group Detail**ページには、リカバリ グループの構成の詳細、ステータス、レプリケーションのスループットとレイテンシーのメトリックなど、リカバリ グループに関する情報が表示されます。 + **Recovery Group Detail**ページには、リカバリグループの構成の詳細、ステータス、レプリケーションのスループットとレイテンシーのメトリックなど、リカバリグループに関する情報が表示されます。 4. レプリケーション関係が完全に確立され、機能している場合、ステータスは**使用可能**と表示されます。 diff --git a/tidb-cloud/recovery-group-overview.md b/tidb-cloud/recovery-group-overview.md index 52cb02fb70ff0..ec4f44d97dacf 100644 --- a/tidb-cloud/recovery-group-overview.md +++ b/tidb-cloud/recovery-group-overview.md @@ -1,6 +1,6 @@ --- title: Recovery Group Overview (Beta) -summary: TiDB Cloudリカバリ グループを使用してデータベースを災害から保護する方法を学びます。 +summary: TiDB Cloudリカバリグループを使用してデータベースを災害から保護する方法を学びます。 --- # リカバリグループの概要（ベータ版） {#recovery-group-overview-beta} @@ -23,9 +23,9 @@ TiDB Cloudリカバリグループを使用すると、 TiDB Cloud Dedicated ク ## 主な機能と制限 {#key-features-and-limitations} -- 現在、AWS でホストされているTiDB Cloud Dedicated クラスターのみがリカバリ グループをサポートしています。 -- リカバリ グループは 2 つのクラスター間に確立されます。 -- リカバリ グループでは、データベースの双方向レプリケーションはサポートされません。 +- 現在、AWS でホストされているTiDB Cloud Dedicated クラスターのみがリカバリグループをサポートしています。 +- リカバリグループは 2 つのクラスター間に確立されます。 +- リカバリグループでは、データベースの双方向レプリケーションはサポートされません。 > **Warning** > @@ -33,5 +33,5 @@ TiDB Cloudリカバリグループを使用すると、 TiDB Cloud Dedicated ク ## 次は何？ {#what-s-next} -- リカバリ グループの使用を開始するには、 [データベース復旧グループの作成](/tidb-cloud/recovery-group-get-started.md)を参照してください。 +- リカバリグループの使用を開始するには、 [データベース復旧グループの作成](/tidb-cloud/recovery-group-get-started.md)を参照してください。 - リカバリグループの使用方法については、 [データベースのフェイルオーバーと再保護](/tidb-cloud/recovery-group-failover.md)を参照してください。 diff --git a/tidb-cloud/releases/_index.md b/tidb-cloud/releases/_index.md index 5fd3b17af06c3..75be83bd1a637 100644 --- a/tidb-cloud/releases/_index.md +++ b/tidb-cloud/releases/_index.md @@ -1,6 +1,6 @@ --- title: TiDB Cloud Releases -summary: TiDB Cloud のリリース ノート、カーネルのバージョン管理、メンテナンス通知について説明します。 +summary: TiDB Cloud のリリースノート、カーネルのバージョン管理、メンテナンス通知について説明します。 --- # TiDB Cloudリリース {#tidb-cloud-releases} @@ -24,7 +24,7 @@ TiDB Cloud には、[クラウドプラットフォーム リリース](#cloud-p | TiDB Cloud **Starter** | クラシック [TiDB v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3/) カーネルをベースにしたカスタマイズ版 [TiDB X](/tidb-cloud/tidb-x-architecture.md) エンジンで実行されます。 | | TiDB Cloud **Essential** | デフォルトでは、クラシック [TiDB v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3/) カーネルをベースにしたカスタマイズ版 [TiDB X](/tidb-cloud/tidb-x-architecture.md) エンジンで実行されます。 | | TiDB Cloud **Premium** | [TiDB X](/tidb-cloud/tidb-x-architecture.md) カーネルの [`TiDB-X-CLOUD.202510.1`](/tidb-cloud/releases/tidb-x-cloud.202510.1.md) バージョンで実行されます。 | -| TiDB Cloud **Dedicated** | クラシック TiDB カーネルで実行され、カーネル バージョンは TiDB Self-Managed のバージョンに直接対応します。現在、新しく作成された TiDB Cloud Dedicated クラスターのデフォルト TiDB バージョンは [v8.5.7](https://docs.pingcap.com/tidb/stable/release-8.5.7/) です。 | +| TiDB Cloud **Dedicated** | クラシック TiDB カーネルで実行され、カーネルバージョンは TiDB Self-Managed のバージョンに直接対応します。現在、新しく作成された TiDB Cloud Dedicated クラスターのデフォルト TiDB バージョンは [v8.5.7](https://docs.pingcap.com/tidb/stable/release-8.5.7/) です。 | > **Note:** > @@ -32,4 +32,4 @@ TiDB Cloud には、[クラウドプラットフォーム リリース](#cloud-p ## メンテナンス通知 {#maintenance-notifications} -TiDB Cloudメンテナンス通知は、 TiDB Cloudサービスに影響を及ぼす可能性のある、スケジュールされたメンテナンス アクティビティに関する情報を提供します。通知の一覧については、左側のナビゲーション ペインを参照してください。 +TiDB Cloudメンテナンス通知は、 TiDB Cloudサービスに影響を及ぼす可能性のある、スケジュールされたメンテナンス アクティビティに関する情報を提供します。通知の一覧については、左側のナビゲーションペインを参照してください。 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..c2ce1b14f3c9a 100644 --- a/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md @@ -1,6 +1,6 @@ --- 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} 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..3f997b5a4f091 100644 --- a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md @@ -1,6 +1,6 @@ --- 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} 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..3a94c3e5adefb 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,6 +1,6 @@ --- 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} @@ -15,7 +15,7 @@ summary: 2023 年 11 月 14 日のTiDB Cloud Dedicated Scale 機能メンテナ > **Note:** > -> 2023-11-16 に更新: メンテナンス ウィンドウの終了時刻が 2023-11-16 から 2023-11-21 に延長されました。 +> 2023-11-16 に更新: メンテナンスウィンドウの終了時刻が 2023-11-16 から 2023-11-21 に延長されました。 ## インパクト {#impact} 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..794481ad39730 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,6 +1,6 @@ --- 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} 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..6a88648140ff1 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,6 +1,6 @@ --- 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} 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..e0c2bcc4bbfc9 100644 --- a/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md +++ b/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md @@ -1,6 +1,6 @@ --- 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} diff --git a/tidb-cloud/releases/release-notes-2020.md b/tidb-cloud/releases/release-notes-2020.md index db854c2dc32b5..9af1147116e95 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} @@ -21,7 +21,7 @@ summary: 2020 年のTiDB Cloudのリリース ノートについて説明しま ## 2020年11月24日 {#november-24-2020} -- TiDB クラスターのパブリック エンドポイントのトラフィック フィルター IP リストを空にして、パブリック アクセスを無効にすることができます。 +- TiDB クラスターのパブリックエンドポイントのトラフィックフィルター IP リストを空にして、パブリックアクセスを無効にすることができます。 - Outlook または Hotmail で顧客に送信される招待メールの配信率を向上します - サインアップ時のエラー通知メッセージを改善する - 新しいクラスターはUbuntuではなくCentOS VM上で実行されます @@ -35,7 +35,7 @@ summary: 2020 年のTiDB Cloudのリリース ノートについて説明しま - フィードバックフォームの入り口ウィジェットを追加する - 設定タブでメンバーがオーナーを削除できないようにする - TiFlashおよび TiKVストレージチャートのメトリックを変更する -- デフォルトの TiDB クラスタ バージョンを 4.0.8 にアップグレードします。 +- デフォルトの TiDB クラスタバージョンを 4.0.8 にアップグレードします。 ## 2020年10月12日 {#october-12-2020} diff --git a/tidb-cloud/releases/release-notes-2021.md b/tidb-cloud/releases/release-notes-2021.md index 2f796b94b36ce..8d4d2ce7e0cf8 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} diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index c5e81a890ee45..61fd97fea9d58 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} @@ -25,7 +25,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま [TiDB Cloudコンソール](https://tidbcloud.com)の**バックアップ設定**で PITR 機能を有効または無効にすることができます。 - 詳細については[TiDB クラスタ データのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 + 詳細については[TiDB クラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 - 複数の変更フィード管理と既存の変更フィード編集をサポートします。 @@ -89,7 +89,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま 新しいレイアウトには次の変更が含まれます。 - - 画面の使用効率を最大化するために、左側のナビゲーション バーを導入します。 + - 画面の使用効率を最大化するために、左側のナビゲーションバーを導入します。 - よりフラットなナビゲーション階層を採用します。 - Serverless Tierユーザーの[**接続する**](/tidb-cloud/connect-to-tidb-cluster-serverless.md)エクスペリエンスを向上します。 @@ -106,7 +106,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- AWS Marketplace と Google Cloud Marketplace のユーザー エクスペリエンスを向上します。 +- AWS Marketplace と Google Cloud Marketplace のユーザーエクスペリエンスを向上します。 TiDB Cloudを初めて使用する場合でも、すでにTiDB Cloudアカウントをお持ちの場合でも、AWS または GCP の請求アカウントにリンクできるようになりました。これにより、AWS または GCP Marketplace のサブスクリプションを簡単に完了できるようになります。 @@ -120,7 +120,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま これまでは、業務を一時停止してオフラインでデータをインポートするか、サードパーティ製のツールを使用してTiDB Cloudにデータを移行する必要があり、これは煩雑でした。しかし、**データ移行**機能を使用すると、 TiDB Cloudコンソールで操作するだけで、最小限のダウンタイムで安全にデータをTiDB Cloudに移行できます。 - さらに、データ移行では、既存のデータと進行中の変更の両方をデータ ソースからTiDB Cloudに移行するための完全および増分データ移行機能が提供されます。 + さらに、データ移行では、既存のデータと進行中の変更の両方をデータソースからTiDB Cloudに移行するための完全および増分データ移行機能が提供されます。 現在、データ移行機能は**ベータ版**です。[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター、AWSオレゴン（us-west-2）およびAWSシンガポール（ap-southeast-1）リージョンでのみご利用いただけます。組織ごとに1つの移行ジョブを無料で作成できます。組織に複数の移行ジョブを作成するには、 [チケットを提出する](/tidb-cloud/tidb-cloud-support.md)が必要です。 @@ -151,7 +151,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - データベース監査ログ機能が GA になりました。 - データベース監査ログを使用すると、ユーザー アクセスの詳細 (実行された SQL ステートメントなど) の履歴をログに記録し、データベース監査ログを定期的に分析して、データベースを安全に保つことができます。 + データベース監査ログを使用すると、ユーザーアクセスの詳細 (実行された SQL ステートメントなど) の履歴をログに記録し、データベース監査ログを定期的に分析して、データベースを安全に保つことができます。 詳細については[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)を参照してください。 @@ -286,7 +286,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - データインポート用の新しいWeb UIを提供します。新しいUIにより、ユーザーエクスペリエンスが向上し、データのインポートがより効率的になります。 - 新しい UI を使用すると、インポートするデータをプレビューしたり、インポート プロセスを表示したり、すべてのインポート タスクを簡単に管理したりできます。 + 新しい UI を使用すると、インポートするデータをプレビューしたり、インポートプロセスを表示したり、すべてのインポートタスクを簡単に管理したりできます。 **APIの変更** @@ -306,9 +306,9 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- ユーザー エクスペリエンスを向上させるために、 [クラスター](https://tidbcloud.com/project/clusters)ページとクラスター概要ページの UI を最適化します。 +- ユーザーエクスペリエンスを向上させるために、 [クラスター](https://tidbcloud.com/project/clusters)ページとクラスター概要ページの UI を最適化します。 - 新しいデザインでは、Dedicated Tierへのアップグレード、クラスター接続、およびデータ インポートの入り口が強調表示されます。 + 新しいデザインでは、Dedicated Tierへのアップグレード、クラスター接続、およびデータインポートの入り口が強調表示されます。 - [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターに Playground を導入します。 @@ -358,7 +358,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[接続する](/tidb-cloud/connect-to-tidb-cluster.md)ダイアログの**VPC ピアリング**タブと**プライベート エンドポイント**タブに、MySQL、MyCLI、JDBC、Python、Go、Node.js のサンプル接続文字列を提供します。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[接続する](/tidb-cloud/connect-to-tidb-cluster.md)ダイアログの**VPC ピアリング**タブと**プライベートエンドポイント**タブに、MySQL、MyCLI、JDBC、Python、Go、Node.js のサンプル接続文字列を提供します。 接続コードをコピーしてアプリに貼り付けるだけで、 Dedicated Tierクラスターに簡単に接続できます。 @@ -389,7 +389,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま ## 2022年8月16日 {#august-16-2022} -- ベータとして TiDB と TiKV の`2 vCPU, 8 GiB (Beta)`ノード サイズを追加します。 +- ベータとして TiDB と TiKV の`2 vCPU, 8 GiB (Beta)`ノードサイズを追加します。 - `2 vCPU, 8 GiB (Beta)` TiKV ノードごとに、ストレージサイズは 200 GiB 〜 500 GiB です。 @@ -409,7 +409,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま ## 2022年8月2日 {#august-2-2022} -- TiDB および TiKV の`4 vCPU, 16 GiB`ノード サイズが一般提供 (GA) になりました。 +- TiDB および TiKV の`4 vCPU, 16 GiB`ノードサイズが一般提供 (GA) になりました。 - `4 vCPU, 16 GiB` TiKV ノードごとに、ストレージサイズは 200 GiB から 2 TiB の間になります。 - 推奨される使用シナリオ: @@ -422,7 +422,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま モニタリングページは、システム全体のパフォーマンス診断のためのシステムレベルのエントリを提供します。トップダウン型パフォーマンス分析手法に基づき、モニタリングページはTiDBのパフォーマンスメトリクスをデータベース時間の内訳に基づいて整理し、異なる色で表示します。これらの色を確認することで、システム全体のパフォーマンスボトルネックを一目で特定できるため、パフォーマンス診断時間を大幅に短縮し、パフォーマンス分析と診断を簡素化できます。 -- CSV および Parquet ソース ファイルの**データ インポート**ページで、**カスタム パターン**を有効または無効にするスイッチを追加します。 +- CSV および Parquet ソースファイルの**データインポート**ページで、**カスタムパターン**を有効または無効にするスイッチを追加します。 **カスタムパターン**機能はデフォルトで無効になっています。特定のパターンに一致するファイル名を持つCSVファイルまたはParquetファイルを単一のターゲットテーブルにインポートする場合は、この機能を有効にできます。 @@ -457,20 +457,20 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - ナビゲーション エクスペリエンスを向上させるために、 TiDB Cloudコンソールにパンくずリストを追加します。 -- TiDB Cloudにデータをインポートするときに複数のフィルター ルールを構成することをサポートします。 +- TiDB Cloudにデータをインポートするときに複数のフィルタールールを構成することをサポートします。 -- **プロジェクト設定**から**トラフィック フィルター**ページを削除し、 **TiDB への接続**ダイアログから**デフォルト セットからルールを追加**ボタンを削除します。 +- **プロジェクト設定**から**トラフィックフィルター**ページを削除し、 **TiDB への接続**ダイアログから**デフォルト セットからルールを追加**ボタンを削除します。 ## 2022年7月19日 {#july-19-2022} - [TiKVノードサイズ](/tidb-cloud/size-your-cluster.md#tikv-vcpu-and-ram) : `8 vCPU, 32 GiB`の新しいオプションを提供します。8 vCPU TiKVノードの場合は、 `8 vCPU, 32 GiB`または`8 vCPU, 64 GiB`選択できます。 - [**TiDBに接続する**](/tidb-cloud/connect-via-standard-connection.md)ダイアログに提供されるサンプルコードで構文のハイライト表示をサポートし、コードの可読性を向上させました。サンプルコード内で置換が必要なパラメータを簡単に特定できます。 -- [**データインポートタスク**](/tidb-cloud/import-sample-data.md)ページでインポート タスクを確認した後、 TiDB Cloud がソース データにアクセスできるかどうかを自動的に検証することをサポートします。 +- [**データインポートタスク**](/tidb-cloud/import-sample-data.md)ページでインポートタスクを確認した後、 TiDB Cloud がソースデータにアクセスできるかどうかを自動的に検証することをサポートします。 - TiDB Cloudコンソールのテーマ カラーを[PingCAPウェブサイト](https://www.pingcap.com/)のテーマ カラーと一致するように変更します。 ## 2022年7月12日 {#july-12-2022} -- Amazon S3 の[**データインポートタスク**](/tidb-cloud/import-sample-data.md)ページに**[検証]**ボタンを追加します。これにより、データのインポートが開始される前にデータ アクセスの問題を検出できるようになります。 +- Amazon S3 の[**データインポートタスク**](/tidb-cloud/import-sample-data.md)ページに**[検証]**ボタンを追加します。これにより、データのインポートが開始される前にデータアクセスの問題を検出できるようになります。 - [**支払方法**](/tidb-cloud/tidb-cloud-billing.md#payment-method)タブで**請求プロファイル**を追加してください。**請求プロファイル**に税務登録番号を入力すると、請求書から特定の税金が免除される場合があります。詳しくは[請求プロファイル情報を編集する](/tidb-cloud/tidb-cloud-billing.md#billing-profile)ご覧ください。 ## 2022年7月5日 {#july-05-2022} @@ -484,7 +484,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - Dedicated Tierクラスターに対して TiKV とTiFlashの[ストレージサイズの増加](/tidb-cloud/scale-tidb-cluster.md#change-storage)をサポートします。 -- ノード サイズ フィールドにメモリ情報を表示する機能をサポートします。 +- ノードサイズ フィールドにメモリ情報を表示する機能をサポートします。 ## 2022年6月28日 {#june-28-2022} @@ -510,8 +510,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - クラスターを作成すると、 TiDB Cloud はデフォルトのクラスター名を提供します。デフォルト名を使用することも、更新することもできます。 - クラスターを作成するときに、 **クラスタの作成**ページでパスワードを設定する必要はありません。 - - クラスターの作成中または作成後に、 **[セキュリティクイックスタート]**ダイアログ ボックスで、クラスターにアクセスするためのルート パスワードと、クラスターに接続するための IP アドレスを設定できます。 - + - クラスターの作成中または作成後に、 **[セキュリティクイックスタート]**ダイアログボックスで、クラスターにアクセスするためのルートパスワードと、クラスターに接続するための IP アドレスを設定できます。 ## 2022年6月14日 {#june-14-2022} - TiDB Cloud をDeveloper Tier[TiDB v6.1.0](https://docs.pingcap.com/tidb/stable/release-6.1.0)にアップグレードします。 @@ -575,7 +574,7 @@ TiDB Cloudが一般提供を開始しました。以下の[サインアップ](h - [新しいクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)の場合、ストレージサイズ（500～2048 GiB）の指定をサポートします。クラスターの作成後はストレージサイズを変更できません。 - 新しいパブリック領域を導入します`eu-central-1` 。 - 8 vCPU TiFlashを廃止し、16 vCPU TiFlashを提供します。 -- CPU とストレージの価格を分離します (どちらも 30% のパブリック プレビュー割引があります)。 +- CPU とストレージの価格を分離します (どちらも 30% のパブリックプレビュー割引があります)。 - [請求情報](/tidb-cloud/tidb-cloud-billing.md)と[価格表](https://www.pingcap.com/pricing/)を更新します。 新機能: diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 279d77d3caf83..9bc7cdbbcae97 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} @@ -55,13 +55,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- TiDB Cloud Dedicated クラスターからデータを復元する場合のデフォルトの動作が、ユーザー アカウントなしでの復元からすべてのユーザー アカウントでの復元に変更されました。 +- TiDB Cloud Dedicated クラスターからデータを復元する場合のデフォルトの動作が、ユーザーアカウントなしでの復元からすべてのユーザーアカウントでの復元に変更されました。 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 -- 変更フィード用のイベント フィルターを導入します。 +- 変更フィード用のイベントフィルターを導入します。 - この機能強化により、 [TiDB Cloudコンソール](https://tidbcloud.com/)を通じて直接変更フィードのイベント フィルターを簡単に管理できるようになり、変更フィードから特定のイベントを除外するプロセスが効率化され、下流のデータ レプリケーションをより適切に制御できるようになります。 + この機能強化により、 [TiDB Cloudコンソール](https://tidbcloud.com/)を通じて直接変更フィードのイベントフィルターを簡単に管理できるようになり、変更フィードから特定のイベントを除外するプロセスが効率化され、下流のデータレプリケーションをより適切に制御できるようになります。 詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)を参照してください。 @@ -82,7 +82,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 営業担当者に連絡せずに、 TiDB CloudコンソールでEnterprise サポート プランに直接アップグレードできます。 +- 営業担当者に連絡せずに、 TiDB CloudコンソールでEnterprise サポートプランに直接アップグレードできます。 詳細については[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)を参照してください。 @@ -178,13 +178,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **APIの変更** -- [AWS プライベートリンク](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc)または[Google Cloud プライベート サービス接続](https://cloud.google.com/vpc/docs/private-service-connect) for [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを管理するためのTiDB Cloud API エンドポイントをいくつかリリースします。 +- [AWS プライベートリンク](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc)または[Google Cloud プライベートサービス接続](https://cloud.google.com/vpc/docs/private-service-connect) for [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを管理するためのTiDB Cloud API エンドポイントをいくつかリリースします。 - - クラスターのプライベート エンドポイント サービスを作成する - - クラスターのプライベート エンドポイント サービス情報を取得する + - クラスターのプライベートエンドポイントサービスを作成する + - クラスターのプライベートエンドポイントサービス情報を取得する - クラスターのプライベートエンドポイントを作成する - クラスターのすべてのプライベートエンドポイントを一覧表示する - - プロジェクト内のすべてのプライベート エンドポイントを一覧表示する + - プロジェクト内のすべてのプライベートエンドポイントを一覧表示する - クラスターのプライベートエンドポイントを削除する 詳細については、 [APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster)を参照してください。 @@ -195,17 +195,17 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに対して Google Cloud [プライベートサービスコネクト](https://cloud.google.com/vpc/docs/private-service-connect)をサポートします。 - プライベート エンドポイントを作成し、Google Cloud でホストされているTiDB Cloud Dedicated クラスタへの安全な接続を確立できるようになりました。 + プライベートエンドポイントを作成し、Google Cloud でホストされているTiDB Cloud Dedicated クラスタへの安全な接続を確立できるようになりました。 主な利点: - - 直感的な操作: わずか数ステップでプライベート エンドポイントを作成できます。 + - 直感的な操作: わずか数ステップでプライベートエンドポイントを作成できます。 - 強化されたセキュリティ: 安全な接続を確立してデータを保護します。 - パフォーマンスの向上: 低遅延かつ高帯域幅の接続を実現します。 詳細については[プライベートエンドポイント経由で Google Cloud に接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから[Google クラウド ストレージ (GCS)](https://cloud.google.com/storage)にデータをストリーミングするための変更フィードの使用をサポートします。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから[Google クラウドストレージ (GCS)](https://cloud.google.com/storage)にデータをストリーミングするための変更フィードの使用をサポートします。 ご自身のアカウントのバケットを使用し、適切にカスタマイズされた権限を付与することで、 TiDB Cloudから GCS にデータをストリーミングできるようになりました。GCS にデータを複製した後、データの変更を自由に分析できます。 @@ -232,7 +232,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この機能により、データベースの負荷が軽減され、エンドポイントのレイテンシーが最適化されます。 - `GET`リクエスト メソッドを使用するエンドポイントの場合、**キャッシュ レスポンス**を有効にし、**詳細プロパティ**でキャッシュの TTL 期間を設定できます。 + `GET`リクエストメソッドを使用するエンドポイントの場合、**キャッシュ レスポンス**を有効にし、**詳細プロパティ**でキャッシュの TTL 期間を設定できます。 詳細については[高度なプロパティ](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)を参照してください。 @@ -257,7 +257,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)でデータ アプリの OpenAPI 仕様をサポートします。 +- TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)でデータアプリの OpenAPI 仕様をサポートします。 TiDB Cloud Data Service は、各データアプリ向けに自動生成された OpenAPI ドキュメントを提供します。ドキュメントでは、エンドポイント、パラメータ、レスポンスを確認し、エンドポイントを試すことができます。 @@ -265,7 +265,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 詳細については、 [OpenAPI仕様を使用する](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification)および[Next.js で OpenAPI 仕様を使用する](/tidb-cloud/data-service-oas-with-nextjs.md)を参照してください。 -- [郵便配達員](https://www.postman.com/)でデータ アプリの実行をサポートします。 +- [郵便配達員](https://www.postman.com/)でデータアプリの実行をサポートします。 Postman統合により、データアプリのエンドポイントをコレクションとして、お好みのワークスペースにインポートできます。PostmanのWebアプリとデスクトップアプリの両方をサポートすることで、強化されたコラボレーションとシームレスなAPIテストのメリットを享受できます。 @@ -289,14 +289,14 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この機能の使用方法の詳細については、 [エンドポイントを自動的に生成する](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically)を参照してください。 -- TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)のエンドポイントの`PUT`および`DELETE`リクエスト メソッドをサポートします。 +- TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)のエンドポイントの`PUT`および`DELETE`リクエストメソッドをサポートします。 - `UPDATE`ステートメントと同様に、 `PUT`メソッドを使用してデータを更新または変更します。 - `DELETE`ステートメントと同様に、 `DELETE`メソッドを使用してデータを削除します。 詳細については[プロパティを構成する](/tidb-cloud/data-service-manage-endpoint.md#configure-properties)を参照してください。 -- TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)で`POST` `PUT`リクエスト メソッドの**バッチ操作を**`DELETE`します。 +- TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)で`POST` `PUT`リクエストメソッドの**バッチ操作を**`DELETE`します。 エンドポイントで**バッチ操作を**有効にすると、単一のリクエストで複数の行に対する操作を実行できるようになります。例えば、単一のリクエスト`POST`で複数行のデータを挿入できます。 @@ -321,7 +321,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 組織レベルとプロジェクト レベルの両方でロールベースのアクセス制御を調整することで、ユーザーに最小限の権限を持つロールを付与し、セキュリティ、コンプライアンス、生産性を向上させることができます。 +- 組織レベルとプロジェクトレベルの両方でロールベースのアクセス制御を調整することで、ユーザーに最小限の権限を持つロールを付与し、セキュリティ、コンプライアンス、生産性を向上させることができます。 - 組織の役割には`Organization Owner` 、 `Organization Billing Admin` 、 `Organization Console Audit Admin` 、 `Organization Member`が含まれます。 - プロジェクト ロールには`Project Owner` 、 `Project Data Access Read-Write` 、 `Project Data Access Read-Only`が含まれます。 @@ -337,7 +337,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloudのインポート機能を最適化し、データのインポートエクスペリエンスを向上させました。以下の改善が行われました。 - - TiDB Cloud Serverless の統合インポート エントリ: データのインポートのエントリを統合し、ローカル ファイルのインポートと Amazon S3 からのファイルのインポートをシームレスに切り替えることができます。 + - TiDB Cloud Serverless の統合インポート エントリ: データのインポートのエントリを統合し、ローカルファイルのインポートと Amazon S3 からのファイルのインポートをシームレスに切り替えることができます。 - 合理化された構成: Amazon S3 からのデータのインポートは 1 つのステップだけで済むため、時間と労力を節約できます。 - 強化された CSV 構成: CSV 構成設定がファイル タイプ オプションの下に配置されるようになり、必要なパラメータを簡単にすばやく構成できるようになりました。 - ターゲットテーブルの選択機能強化：チェックボックスをクリックすることで、データインポートの対象となるターゲットテーブルを選択できるようになりました。この改善により、複雑な式を入力する必要がなくなり、ターゲットテーブルの選択が簡素化されます。 @@ -386,7 +386,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 次の変更を加えることで、全体的なナビゲーション エクスペリエンスが向上します。 - - 統合する**組織**と右上隅の**アカウント**を左のナビゲーション バーに移動します。 + - 統合する**組織**と右上隅の**アカウント**を左のナビゲーションバーに移動します。 - 統合する左のナビゲーションバーの**管理者**に左ナビゲーションバーの**「プロジェクト」を**クリックし、左上隅の☰ホバーメニューを削除します。これで、プロジェクト間を切り替えたり、プロジェクト設定を変更したりします。 - ドキュメント、対話型チュートリアル、自習型トレーニング、サポート エントリなど、 TiDB Cloudのすべてのヘルプとサポート情報を、右下隅の**[?]**アイコンのメニューに統合します。 @@ -396,7 +396,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 新しく作成された[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターの事前構築されたサンプル データセットを削除します。 +- 新しく作成された[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターの事前構築されたサンプルデータセットを削除します。 ## 2023年6月20日 {#june-20-2023} @@ -434,11 +434,11 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに Index Insight (ベータ版) を導入します。これは、スロークエリに対してインデックスの推奨事項を提供することで、クエリ パフォーマンスを最適化します。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに Index Insight (ベータ版) を導入します。これは、スロークエリに対してインデックスの推奨事項を提供することで、クエリパフォーマンスを最適化します。 Index Insight を使用すると、次の方法でアプリケーション全体のパフォーマンスとデータベース操作の効率を向上させることができます。 - - 強化されたクエリ パフォーマンス: Index Insight は、低速なクエリを識別し、適切なインデックスを提案します。これにより、クエリの実行速度が上がり、応答時間が短縮され、ユーザー エクスペリエンスが向上します。 + - 強化されたクエリパフォーマンス: Index Insight は、低速なクエリを識別し、適切なインデックスを提案します。これにより、クエリの実行速度が上がり、応答時間が短縮され、ユーザーエクスペリエンスが向上します。 - コスト効率：Index Insight を使用してクエリパフォーマンスを最適化することで、追加のコンピューティングリソースの必要性が軽減され、既存のインフラストラクチャをより効率的に活用できるようになります。これにより、運用コストの削減につながる可能性があります。 - 簡素化された最適化プロセス：Index Insightは、インデックスの改善点の特定と実装を簡素化し、手作業による分析や推測作業の必要性を排除します。その結果、正確なインデックス推奨によって時間と労力を節約できます。 - アプリケーション効率の向上: Index Insight を使用してデータベース パフォーマンスを最適化することで、 TiDB Cloudで実行されるアプリケーションはより大きなワークロードを処理し、より多くのユーザーに同時にサービスを提供できるようになり、アプリケーションのスケーリング操作がより効率的になります。 @@ -459,18 +459,18 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [データアプリ](/tidb-cloud/tidb-cloud-glossary.md#data-app) GitHub に接続することをサポートします。 - [データアプリをGitHubに接続する](/tidb-cloud/data-service-manage-github-connection.md)により、データ アプリのすべての構成を Github 上の[コードファイル](/tidb-cloud/data-service-app-config-files.md)として管理できるようになり、 TiDB Cloud Data Service がシステムアーキテクチャおよび DevOps プロセスとシームレスに統合されます。 + [データアプリをGitHubに接続する](/tidb-cloud/data-service-manage-github-connection.md)により、データアプリのすべての構成を Github 上の[コードファイル](/tidb-cloud/data-service-app-config-files.md)として管理できるようになり、 TiDB Cloud Data Service がシステムアーキテクチャおよび DevOps プロセスとシームレスに統合されます。 - この機能を使用すると、次のタスクを簡単に実行できるため、データ アプリ開発の CI/CD エクスペリエンスが向上します。 + この機能を使用すると、次のタスクを簡単に実行できるため、データアプリ開発の CI/CD エクスペリエンスが向上します。 - - GitHub を使用してデータ アプリの変更を自動的にデプロイします。 - - バージョン管理を使用して、GitHub でデータ アプリの変更の CI/CD パイプラインを構成します。 + - GitHub を使用してデータアプリの変更を自動的にデプロイします。 + - バージョン管理を使用して、GitHub でデータアプリの変更の CI/CD パイプラインを構成します。 - 接続されている GitHub リポジトリから切断します。 - 展開前にエンドポイントの変更を確認します。 - デプロイメント履歴を確認し、障害が発生した場合に必要なアクションを実行します。 - コミットを再デプロイして、以前のデプロイにロールバックします。 - 詳細については[GitHub でデータ アプリを自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 + 詳細については[GitHub でデータアプリを自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 ## 2023年6月2日 {#june-2-2023} @@ -527,7 +527,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 2023 年 4 月 26 日以降に作成された GCP ホスト クラスタのノード サイズの変更をサポートします。 +- 2023 年 4 月 26 日以降に作成された GCP ホスト クラスタのノードサイズの変更をサポートします。 この機能により、需要の増加に合わせて高パフォーマンスノードにアップグレードしたり、コスト削減のために低パフォーマンスノードにダウングレードしたりできます。この柔軟性の向上により、ワークロードに合わせてクラスターの容量を調整し、コストを最適化できます。 @@ -545,7 +545,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- [**イベント**](/tidb-cloud/tidb-cloud-events.md)ページに新しいイベント タイプを追加して、 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのバックアップ、復元、および changefeed アクションを記録します。 +- [**イベント**](/tidb-cloud/tidb-cloud-events.md)ページに新しいイベントタイプを追加して、 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのバックアップ、復元、および changefeed アクションを記録します。 記録できるイベントの完全なリストについては、 [記録されたイベント](/tidb-cloud/tidb-cloud-events.md#logged-events)を参照してください。 @@ -592,17 +592,16 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 新しい[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデフォルトの TiDB バージョンを[バージョン6.5.1](https://docs.pingcap.com/tidb/stable/release-6.5.1)から[バージョン6.5.2](https://docs.pingcap.com/tidb/stable/release-6.5.2)にアップグレードします。 -- メンテナンス ウィンドウ機能を提供して、 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの計画メンテナンス アクティビティを簡単にスケジュールおよび管理できるようにします。 +- メンテナンスウィンドウ機能を提供して、 [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの計画メンテナンス アクティビティを簡単にスケジュールおよび管理できるようにします。 - メンテナンス ウィンドウとは、 TiDB Cloudサービスの信頼性、セキュリティ、パフォーマンスを確保するために、オペレーティング システムの更新、セキュリティ パッチ、インフラストラクチャのアップグレードなどの計画されたメンテナンス アクティビティが自動的に実行される指定された期間です。 + メンテナンスウィンドウとは、 TiDB Cloudサービスの信頼性、セキュリティ、パフォーマンスを確保するために、オペレーティングシステムの更新、セキュリティパッチ、インフラストラクチャのアップグレードなどの計画されたメンテナンス アクティビティが自動的に実行される指定された期間です。 メンテナンス期間中は、一時的な接続中断やQPSの変動が発生する可能性がありますが、クラスターは引き続き利用可能であり、SQL操作、既存のデータインポート、バックアップ、復元、移行、レプリケーションタスクは通常どおり実行されます。メンテナンス中は[許可された操作と許可されていない操作のリスト](/tidb-cloud/configure-maintenance-window.md#allowed-and-disallowed-operations-during-a-maintenance-window)を参照してください。 メンテナンスの頻度を最小限に抑えるよう努めます。メンテナンス期間が予定されている場合、デフォルトの開始時刻は対象週の水曜日の午前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 の負荷分散を改善し、接続の切断を減らします。 @@ -709,7 +708,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [Data Service（ベータ版）](/tidb-cloud/data-service-overview.md) 、データ アプリに対するよりきめ細かいアクセス制御がサポートされます。 +- [Data Service（ベータ版）](/tidb-cloud/data-service-overview.md) 、データアプリに対するよりきめ細かいアクセス制御がサポートされます。 データアプリの詳細ページで、クラスタをデータアプリにリンクし、各APIキーのロールを指定できるようになりました。ロールは、APIキーがリンクされたクラスタへのデータの読み取りまたは書き込みを許可するかどうかを制御し、 `ReadOnly`または`ReadAndWrite`に設定できます。この機能により、データアプリに対してクラスタレベルおよび権限レベルのアクセス制御が可能になり、ビジネスニーズに応じてアクセス範囲をより柔軟に制御できるようになります。 @@ -755,7 +754,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - モバイル アプリケーションまたは Web アプリケーションから TiDB クラスターのデータベースに直接アクセスします。 - サーバーレス エッジ関数を使用してエンドポイントを呼び出し、データベース接続プールによって発生するスケーラビリティの問題を回避します。 - - Data Serviceをデータ ソースとして使用して、 TiDB Cloud をデータ視覚化プロジェクトと統合します。 + - Data Serviceをデータソースとして使用して、 TiDB Cloud をデータ視覚化プロジェクトと統合します。 - MySQL インターフェースがサポートしていない環境からデータベースに接続します。 さらに、 TiDB Cloud は、AI を使用して SQL ステートメントを生成および実行できる RESTful インターフェースである[チャット2クエリAPI](/tidb-cloud/use-chat2query-api.md)提供します。 @@ -768,7 +767,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 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)減らすことができます。 + ノードサイズを[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)減らすことができます。 - [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能に対して新しい GCP リージョンをサポートします: `Tokyo (asia-northeast1)` 。 @@ -784,7 +783,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[TiDB Cloudクラスター イベント](/tidb-cloud/tidb-cloud-events.md)を参照してください。 -- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターの**[監視]**ページに**[データベース ステータス]**タブを追加します。ここには、次のデータベース レベルのメトリックが表示されます。 +- [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターの**[監視]**ページに**[データベース ステータス]**タブを追加します。ここには、次のデータベースレベルのメトリックが表示されます。 - DBあたりのQPS - DBあたりの平均クエリ実行時間 @@ -800,7 +799,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 新しい[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデフォルトの TiDB バージョンを[バージョン6.5.0](https://docs.pingcap.com/tidb/stable/release-6.5.0)から[バージョン6.5.1](https://docs.pingcap.com/tidb/stable/release-6.5.1)にアップグレードします。 -- ヘッダー行を含むローカル CSV ファイルをアップロードするときに、 TiDB Cloudによって作成されるターゲット テーブルの列名の変更をサポートします。 +- ヘッダー行を含むローカル CSV ファイルをアップロードするときに、 TiDB Cloudによって作成されるターゲットテーブルの列名の変更をサポートします。 ヘッダー行を含むローカルCSVファイルを[Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターにインポートする際、 TiDB Cloudでターゲットテーブルを作成する必要があり、ヘッダー行の列名がTiDB Cloudの列命名規則に従っていない場合、対応する列名の横に警告アイコンが表示されます。この警告を解決するには、アイコンの上にカーソルを移動し、メッセージに従って既存の列名を編集するか、新しい列名を入力してください。 @@ -820,7 +819,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま SQL診断を使用すると、SQL関連の実行時ステータスに関する詳細な分析情報を取得できるため、SQLパフォーマンスチューニングの効率が向上します。現在、Serverless TierのSQL診断機能は、スロークエリデータのみを提供しています。 - SQL 診断を使用するには、 Serverless Tierクラスター ページの左側のナビゲーション バーで**[SQL 診断] を**クリックします。 + SQL 診断を使用するには、 Serverless Tierクラスター ページの左側のナビゲーションバーで**[SQL 診断] を**クリックします。 **コンソールの変更** @@ -938,18 +937,17 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md) - [ChangeFeed を使用してTiDB Cloudから他のデータサービスにデータをストリーミングする](/tidb-cloud/changefeed-overview.md) - - [TiDB クラスタ データのバックアップと復元](/tidb-cloud/backup-and-restore.md) + - [TiDB クラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md) ## 2023年1月10日 {#january-10-2023} **一般的な変更** -- ローカル CSV ファイルから TiDB にデータをインポートする機能を最適化し、 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのユーザー エクスペリエンスを向上させます。 +- ローカル CSV ファイルから TiDB にデータをインポートする機能を最適化し、 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのユーザーエクスペリエンスを向上させます。 - CSV ファイルをアップロードするには、**インポート**ページのアップロード領域にドラッグ アンド ドロップするだけです。 - インポートタスクを作成する際に、対象のデータベースまたはテーブルが存在しない場合は、名前を入力することでTiDB Cloudが自動的に作成します。作成する対象テーブルには、主キーを指定するか、複数のフィールドを選択して複合主キーを形成することができます。 - - インポートが完了したら、 **Chat2Query でデータを探索**をクリックするか、タスク リストでターゲット テーブル名をクリックして、 [AI搭載のChat2Query](/tidb-cloud/explore-data-with-chat2query.md)でデータを探索できます。 - + - インポートが完了したら、 **Chat2Query でデータを探索**をクリックするか、タスクリストでターゲットテーブル名をクリックして、 [AI搭載のChat2Query](/tidb-cloud/explore-data-with-chat2query.md)でデータを探索できます。 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)を参照してください。 **コンソールの変更** @@ -969,15 +967,15 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま Chat2Query では、AI に SQL クエリを自動的に生成させたり、SQL クエリを手動で記述したり、ターミナルなしでデータベースに対して SQL クエリを実行したりできます。 - Chat2Query にアクセスするには、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、クラスター名をクリックして、左側のナビゲーション ペインで**Chat2Query を**クリックします。 + Chat2Query にアクセスするには、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、クラスター名をクリックして、左側のナビゲーションペインで**Chat2Query を**クリックします。 ## 2023年1月4日 {#january-4-2023} **一般的な変更** -- 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コンソールを使用する](/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 日間に延長します。 diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 2e8f4575f0f76..f317ddbac5e31 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -109,9 +109,9 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ TiDB Cloud CLIには、以下の新機能が追加されました。 - [`ticloud serverless sql-user`](/tidb-cloud/ticloud-serverless-sql-user-create.md)を介して、 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターの SQL ユーザー管理をサポートします。 - - [`ticloud serverless create`](/tidb-cloud/ticloud-cluster-create.md)および[`ticloud serverless update`](/tidb-cloud/ticloud-serverless-update.md)で、 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターのパブリック エンドポイントを無効にできるようにします。 + - [`ticloud serverless create`](/tidb-cloud/ticloud-cluster-create.md)および[`ticloud serverless update`](/tidb-cloud/ticloud-serverless-update.md)で、 [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターのパブリックエンドポイントを無効にできるようにします。 - OAuth認証を使用する際に、現在のユーザーに関する情報を取得するには、 [`ticloud auth whoami`](/tidb-cloud/ticloud-auth-whoami.md)コマンドを追加してください。 - - [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md)で`--sql` 、 `--where` 、および`--filter`フラグをサポートし、ソース テーブルを柔軟に選択できるようにします。 + - [`ticloud serverless export create`](/tidb-cloud/ticloud-serverless-export-create.md)で`--sql` 、 `--where` 、および`--filter`フラグをサポートし、ソーステーブルを柔軟に選択できるようにします。 - CSVファイルおよびParquetファイルへのデータエクスポートをサポートします。 - ロールARNを認証情報として使用してAmazon S3にデータをエクスポートする機能をサポートするとともに、Google Cloud StorageおよびAzure Blob Storageへのエクスポートもサポートします。 - Amazon S3、Google Cloud Storage、Azure Blob Storageからのデータインポートをサポートします。 @@ -134,7 +134,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - TiDB Cloudパートナー向けのリソースおよび請求管理を強化するため、 TiDB CloudパートナーWebコンソールとオープンAPIをリリースしました。 - AWS Marketplace Channel Partner Private Offer (CPPO) を通じてマネージド サービス プロバイダー (MSP) と再販業者は[TiDB CloudパートナーWebコンソール](https://partner-console.tidbcloud.com/)とオープン API を活用して日常業務を合理化できるようになりました。 + AWS Marketplace Channel Partner Private Offer (CPPO) を通じてマネージドサービス プロバイダー (MSP) と再販業者は[TiDB CloudパートナーWebコンソール](https://partner-console.tidbcloud.com/)とオープン API を活用して日常業務を合理化できるようになりました。 詳細については、 [TiDB CloudパートナーWebコンソール](/tidb-cloud/tidb-cloud-partners.md)を参照してください。 @@ -188,8 +188,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)のクラスタサイズ構成エクスペリエンスを向上させます。 - TiDB Cloud Dedicatedクラスターの [**クラスタを作成する**](/tidb-cloud/create-tidb-cluster.md)ページと「クラスター [**クラスタの変更**](/tidb-cloud/scale-tidb-cluster.md)ページの**クラスタサイズ**セクションのレイアウトを調整します。さらに、 **クラスタサイズ**セクションには、適切なクラスター サイズの選択に役立つノード サイズの推奨ドキュメントへのリンクが含まれるようになりました。 - + TiDB Cloud Dedicatedクラスターの [**クラスタを作成する**](/tidb-cloud/create-tidb-cluster.md)ページと「クラスター [**クラスタの変更**](/tidb-cloud/scale-tidb-cluster.md)ページの**クラスタサイズ**セクションのレイアウトを調整します。さらに、 **クラスタサイズ**セクションには、適切なクラスターサイズの選択に役立つノードサイズの推奨ドキュメントへのリンクが含まれるようになりました。 ## 2024年7月23日 {#july-23-2024} **全般的な変更** @@ -218,13 +217,13 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **コンソールの変更** -- **VPC ピアリング**ページのレイアウトを調整して、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでの[VPCピアリング接続の作成](/tidb-cloud/set-up-vpc-peering-connections.md)のユーザー エクスペリエンスを向上させます。 +- **VPC ピアリング**ページのレイアウトを調整して、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでの[VPCピアリング接続の作成](/tidb-cloud/set-up-vpc-peering-connections.md)のユーザーエクスペリエンスを向上させます。 ## 2024年7月2日 {#july-2-2024} **全般的な変更** -- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)は、データ アプリに直接追加できる事前定義されたシステム エンドポイントを含むエンドポイント ライブラリを提供し、エンドポイント開発の労力を軽減します。 +- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)は、データアプリに直接追加できる事前定義されたシステムエンドポイントを含むエンドポイントライブラリを提供し、エンドポイント開発の労力を軽減します。 現在、このライブラリには`/system/query`エンドポイントのみが含まれています。このエンドポイントを使用すると、定義済みの`sql`パラメータにSQL文を渡すだけで、任意のSQL文を実行できます。このエンドポイントにより、SQLクエリを即座に実行できるため、柔軟性と効率性が向上します。 @@ -332,11 +331,11 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **全般的な変更** -- さまざまな地域の顧客によりよく対応できるように、タイム[**タイムゾーン**](/tidb-cloud/manage-user-access.md#set-the-time-zone-for-your-organization)セクションのタイム ゾーンの選択を拡大します。 +- さまざまな地域の顧客によりよく対応できるように、タイム[**タイムゾーン**](/tidb-cloud/manage-user-access.md#set-the-time-zone-for-your-organization)セクションのタイムゾーンの選択を拡大します。 - VPC がTiDB Cloudの VPC とは異なるリージョンにある場合、 [VPCピアリングの作成](/tidb-cloud/set-up-vpc-peering-connections.md)サポートします。 -- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)クエリ パラメーターとともにパス パラメーターをサポートしています。 +- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)クエリパラメーターとともにパス パラメーターをサポートしています。 この機能は、構造化URLによるリソース識別を強化し、ユーザーエクスペリエンス、検索エンジン最適化（SEO）、クライアント統合を改善することで、開発者により柔軟性を提供し、業界標準との整合性を高めます。 @@ -441,7 +440,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 詳細については、 [公開エンドポイントを無効にする](/tidb-cloud/connect-via-standard-connection-serverless.md#disable-a-public-endpoint)ご覧ください。 -- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)データ アプリのエンドポイントにアクセスするためのカスタム ドメインの構成をサポートしています。 +- [Data Service（ベータ版）](https://tidbcloud.com/project/data-service)データアプリのエンドポイントにアクセスするためのカスタムドメインの構成をサポートしています。 TiDB Cloud Data Serviceは、デフォルトでは各データアプリのエンドポイントにアクセスするためのドメイン`.data.tidbcloud.com`を提供します。パーソナライズと柔軟性をさらに高めるため、デフォルトドメインの代わりにデータアプリにカスタムドメインを設定できるようになりました。この機能により、データベースサービスにブランドURLを使用でき、セキュリティも強化されます。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 0bb813784066e..942a0429fd313 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} @@ -19,7 +19,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま ハイライト: - - スケーリング操作およびローリング アップグレード中に永続的なクライアント接続を維持します。 + - スケーリング操作およびローリングアップグレード中に永続的なクライアント接続を維持します。 - リソース利用率を向上させるために、TiDB ノード全体にトラフィックを均等に分散します。 詳細については[TiProxyの概要](/tidb-cloud/tiproxy-overview-for-cloud.md)を参照してください。 @@ -30,11 +30,11 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま changefeed 機能は現在、バージョン[TiDB Cloudコンソール](https://tidbcloud.com)と[TiDB Cloud CLI](/tidb-cloud/cli-reference.md) for [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)の両方でベータ版としてご利用いただけます。この機能により、TiDB Cloudから他のデータサービスへのデータストリーミングが可能になり、現在 Apache Kafka と MySQL が送信先としてサポートされています。 - - ダウンストリーム リソースのプライベート リンク接続の構成をサポートします。 + - ダウンストリーム リソースのプライベートリンク接続の構成をサポートします。 プライベートリンク接続は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)の[TiDB Cloudコンソール](https://tidbcloud.com)と[TiDB Cloud CLI](/tidb-cloud/cli-reference.md)両方で利用できるようになりました。この機能により、TiDB Cloudと下流リソース（MySQL、Apache Kafka など）間のプライベートかつ直接的な接続を確立できます。これは、 TiDB Cloudからお客様のインフラストラクチャへの接続を開始する変更フィードやその他のデータフローサービスとの統合向けにカスタマイズされています。 - 詳細については[Dataflow のプライベート リンク接続](/tidb-cloud/serverless-private-link-connection.md)を参照してください。 + 詳細については[Dataflow のプライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)を参照してください。 ## 2025年12月16日 {#december-16-2025} @@ -70,7 +70,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud Starter とTiDB Cloud Essential** - - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)および[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターのクラスター レベルで**統合された統合**ページを追加します。 + - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)および[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターのクラスターレベルで**統合された統合**ページを追加します。 - クラスターの**統合**ページで、すべてのサードパーティ統合を統合します。以下のリストは、ユースケース別にまとめたこれらの統合の概要です。 - **デプロイ**: AWS Lambda、Cloudflare Workers、Gitpod、Netlify、Terraform、WordPress @@ -81,9 +81,8 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **Python** : Django、mysqlclient、MySQL Connector/Python、peewee、PyMySQL、SQLAlchemy - **Node.js** : mysql.js、Next.js、node-mysql2、Prisma、Sequelize、TypeORM - **Ruby** : mysql2、Rails - - 検出可能性を向上させるために、統合エントリ[Vercel](/tidb-cloud/integrate-tidbcloud-with-vercel.md)と[AWS Bedrock](/ai/integrations/vector-search-integrate-with-amazon-bedrock.md)クラスター レベルに移動します。 + - 検出可能性を向上させるために、統合エントリ[Vercel](/tidb-cloud/integrate-tidbcloud-with-vercel.md)と[AWS Bedrock](/ai/integrations/vector-search-integrate-with-amazon-bedrock.md)クラスターレベルに移動します。 - 新しい統合をリクエストするための**統合の提案**を追加します。 - **APIの変更** - TiDB Cloud IAM API (v1beta1) は、コンソール監査ログの一覧表示をサポートしています。 @@ -104,7 +103,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 統合手順については、 [TiDB Cloud をPrometheus および Grafana と統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)を参照してください。 - 既存の Prometheus 統合をクラスター レベルに移行するには、 [Prometheus統合の移行](/tidb-cloud/migrate-prometheus-metrics-integrations.md)を参照してください。 + 既存の Prometheus 統合をクラスターレベルに移行するには、 [Prometheus統合の移行](/tidb-cloud/migrate-prometheus-metrics-integrations.md)を参照してください。 ## 2025年11月18日 {#november-18-2025} @@ -172,13 +171,13 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud Dedicated** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)では、 [チェンジフィード](/tidb-cloud/changefeed-overview.md)プライベート エンドポイント機能が強化され、構成が簡素化され、セキュリティが向上し、データ シンクの柔軟性が向上します。 + - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)では、 [チェンジフィード](/tidb-cloud/changefeed-overview.md)プライベートエンドポイント機能が強化され、構成が簡素化され、セキュリティが向上し、データ シンクの柔軟性が向上します。 - - **簡素化された構成**: プライベート エンドポイントの作成が変更フィードの作成から独立し、同じプロジェクト内の複数の変更フィードが単一のプライベート エンドポイントを共有できるようになり、冗長な構成が削減されます。 - - **MySQL のプライベート リンク シンク**: MySQL にデータをシンクするためのより安全な方法を提供し、プライベート リンク経由で別のTiDB Cloud Dedicated クラスターにデータを直接シンクすることもサポートするようになりました。 - - **カスタム ドメインのサポート**: セルフホスト型 Kafka サービスを使用する場合、データ シンクのカスタム ドメインを構成して、セキュリティを強化し、サーバーの再起動を必要とせずに、アドバタイズされたリスナーの更新をより柔軟に行うことができます。 + - **簡素化された構成**: プライベートエンドポイントの作成が変更フィードの作成から独立し、同じプロジェクト内の複数の変更フィードが単一のプライベートエンドポイントを共有できるようになり、冗長な構成が削減されます。 + - **MySQL のプライベートリンク シンク**: MySQL にデータをシンクするためのより安全な方法を提供し、プライベートリンク経由で別のTiDB Cloud Dedicated クラスターにデータを直接シンクすることもサポートするようになりました。 + - **カスタムドメインのサポート**: セルフホスト型 Kafka サービスを使用する場合、データ シンクのカスタムドメインを構成して、セキュリティを強化し、サーバーの再起動を必要とせずに、アドバタイズされたリスナーの更新をより柔軟に行うことができます。 - 詳細については[Changefeeds のプライベート エンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)を参照してください。 + 詳細については[Changefeeds のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)を参照してください。 - 現在、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して[Prometheus 統合（PREVIEW）](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)が使用可能です。 @@ -251,7 +250,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 統合手順については、 [TiDB CloudとDatadogの統合](/tidb-cloud/monitor-datadog-integration.md)と[TiDB CloudとNew Relicの統合](/tidb-cloud/monitor-new-relic-integration.md)を参照してください。 - 既存の Datadog と New Relic の統合をクラスター レベルに移行するには、 [DatadogとNew Relicの統合の移行](/tidb-cloud/migrate-metrics-integrations.md)を参照してください。 + 既存の Datadog と New Relic の統合をクラスターレベルに移行するには、 [DatadogとNew Relicの統合の移行](/tidb-cloud/migrate-metrics-integrations.md)を参照してください。 ## 2025年9月23日 {#september-23-2025} @@ -267,9 +266,9 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 分割動作の詳細については、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 - - Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 64 GiB`を指定します。 + - Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノードサイズ`32 vCPU, 64 GiB`を指定します。 - この新しいノード サイズは、TiDB ノードで使用できます。 + この新しいノードサイズは、TiDB ノードで使用できます。 ## 2025年9月16日 {#september-16-2025} @@ -390,7 +389,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 試す方法: - - [TiDB Cloudコンソール](https://tidbcloud.com/)から、クラスターを作成するときにクラウド プロバイダーとして Alibaba Cloud を選択して、Essential オプションを表示します。 + - [TiDB Cloudコンソール](https://tidbcloud.com/)から、クラスターを作成するときにクラウドプロバイダーとして Alibaba Cloud を選択して、Essential オプションを表示します。 - [Alibaba Cloud Marketplaceへの掲載](https://www.alibabacloud.com/en/marketplace/tidb?_p_lc=1)経由で Essential にアクセスすることもできます。 今後は、Alibaba Cloud のリージョン カバレッジを拡大し、AWS サポートを追加する予定です。 @@ -443,8 +442,8 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **クラスタ**: TiDB Cloud Dedicated クラスターをより柔軟に管理します。 - **リージョン**: TiDB Cloud Dedicated クラスターをデプロイできるすべてのクラウド リージョンを表示します。 - - **プライベート エンドポイント接続**: クラスターの安全でプライベートな接続を設定します。 - - **インポート**: クラスターのデータ インポート タスクを管理します。 + - **プライベートエンドポイント接続**: クラスターの安全でプライベートな接続を設定します。 + - **インポート**: クラスターのデータインポートタスクを管理します。 詳細については[TiDB Cloud Dedicated API](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated/)を参照してください。 @@ -452,14 +451,14 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **クラスタ**: TiDB Cloud Starter または Essential クラスターをより柔軟に管理します。 - **ブランチ**: クラスターのブランチを管理します。 - - **エクスポート**: クラスターのデータ エクスポート タスクを管理します。 - - **インポート**: クラスターのデータ インポート タスクを管理します。 + - **エクスポート**: クラスターのデータエクスポート タスクを管理します。 + - **インポート**: クラスターのデータインポートタスクを管理します。 詳細については[TiDB Cloud Starterと基本 API](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless/)を参照してください。 - TiDB Cloud IAM API (v1beta1) は、組織レベルとプロジェクトレベルの両方で API キー管理のロールベースのアクセス制御 (RBAC) をサポートします。 - セキュリティとアクセス制御を強化するために、組織レベルまたはプロジェクト レベルで API キーのロールを設定できます。 + セキュリティとアクセス制御を強化するために、組織レベルまたはプロジェクトレベルで API キーのロールを設定できます。 詳細については[TiDB CloudIAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)を参照してください。 @@ -487,7 +486,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 128 GiB`を指定します。 +- Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノードサイズ`32 vCPU, 128 GiB`を指定します。 この新しいサイズは、TiDB、TiKV、およびTiFlashノードで使用できます。 @@ -507,7 +506,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 詳細については、次のドキュメントを参照してください。 - [サンプルデータをTiDB Cloud Serverlessにインポートする](/tidb-cloud/import-sample-data-serverless.md) - - [クラウド ストレージからTiDB Cloud Serverless に CSV ファイルをインポートする](/tidb-cloud/import-csv-files-serverless.md) + - [クラウドストレージからTiDB Cloud Serverless に CSV ファイルをインポートする](/tidb-cloud/import-csv-files-serverless.md) - [Cloud Storage からTiDB Cloud Serverless に Apache Parquet ファイルをインポートする](/tidb-cloud/import-parquet-files-serverless.md) ## 2025年7月15日 {#july-15-2025} @@ -554,25 +553,25 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- 左側のナビゲーション ペインを改良して、全体的なナビゲーション エクスペリエンスを向上させます。 +- 左側のナビゲーションペインを改良して、全体的なナビゲーション エクスペリエンスを向上させます。 - - 新しいアイコンが左上隅に表示されるようになりました。これにより、必要に応じて左側のナビゲーション ペインを簡単に非表示または表示できます。 + - 新しいアイコンが左上隅に表示されるようになりました。これにより、必要に応じて左側のナビゲーションペインを簡単に非表示または表示できます。 - - 左上隅にコンボ ボックスが追加され、組織、プロジェクト、クラスターを 1 つの中央の場所から簡単に切り替えられるようになりました。 + - 左上隅にコンボボックスが追加され、組織、プロジェクト、クラスターを 1 つの中央の場所から簡単に切り替えられるようになりました。 - - 左側のナビゲーション ペインに表示されるエントリは、コンボ ボックスの現在の選択内容に応じて動的に調整されるようになり、最も関連性の高い機能に集中できるようになります。 + - 左側のナビゲーションペインに表示されるエントリは、コンボボックスの現在の選択内容に応じて動的に調整されるようになり、最も関連性の高い機能に集中できるようになります。 - - すぐにアクセスできるように、**サポート**、**通知**、アカウント エントリが、すべてのコンソール ページの左側のナビゲーション ペインの下部に常に表示されるようになりました。 + - すぐにアクセスできるように、**サポート**、**通知**、アカウント エントリが、すべてのコンソール ページの左側のナビゲーションペインの下部に常に表示されるようになりました。 ## 2025年6月4日 {#june-4-2025} **一般的な変更** -- Microsoft Azure の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)がパブリック プレビューで利用できるようになりました。 +- 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 つのリージョンで利用可能であり、近日中にさらに多くのリージョンで利用可能になる予定です。 @@ -581,7 +580,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま Azure でTiDB Cloud Dedicated をすぐに使い始めるには、次のドキュメントを参照してください。 - [Azure 上にTiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) - - [Azure プライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md) + - [Azure プライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md) - [Azure 上のTiDB Cloud Dedicatedクラスターにデータをインポートする](/tidb-cloud/import-csv-files.md) - Prometheus 統合により、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの監視機能を強化するためのメトリックがさらに提供されます。 @@ -634,7 +633,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)を参照してください。 -- メンテナンス タスクを構成および再スケジュールするための直感的なオプションを提供することで、メンテナンス ウィンドウの構成エクスペリエンスを強化します。 +- メンテナンス タスクを構成および再スケジュールするための直感的なオプションを提供することで、メンテナンスウィンドウの構成エクスペリエンスを強化します。 詳細については[メンテナンスウィンドウを構成する](/tidb-cloud/configure-maintenance-window.md)を参照してください。 @@ -677,7 +676,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDBノードグループ](/tidb-cloud/tidb-node-group-overview.md)機能が、AWS と Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して一般提供 (GA) されました。 - この機能により、単一クラスター内で**きめ細かなコンピューティング リソースの分離**が可能になり、マルチテナントまたはマルチワークロードのシナリオでパフォーマンスとリソース割り当てを最適化できます。 + この機能により、単一クラスター内で**きめ細かなコンピューティングリソースの分離**が可能になり、マルチテナントまたはマルチワークロードのシナリオでパフォーマンスとリソース割り当てを最適化できます。 **主な利点:** @@ -688,7 +687,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **簡素化された管理**： - - すべてのノード グループを単一のクラスター内で管理し、運用オーバーヘッドを削減します。 + - すべてのノードグループを単一のクラスター内で管理し、運用オーバーヘッドを削減します。 - 需要に応じてグループを個別にスケールします。 メリットの詳細については[技術ブログ](https://www.pingcap.com/blog/tidb-cloud-node-groups-scaling-workloads-predictable-performance/)ご覧ください。開始するには[TiDBノードグループの管理](/tidb-cloud/tidb-node-group-management.md)ご覧ください。 @@ -713,11 +712,11 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスター内のパブリック エンドポイントのファイアウォール ルールをサポートします。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスター内のパブリックエンドポイントのファイアウォールルールをサポートします。 TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。[TiDB Cloudコンソール](https://tidbcloud.com/)で許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 - 詳細については[パブリックエンドポイント用のTiDB Cloud Serverless ファイアウォール ルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)を参照してください。 + 詳細については[パブリックエンドポイント用のTiDB Cloud Serverless ファイアウォールルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)を参照してください。 ## 2025年3月18日 {#march-18-2025} @@ -727,7 +726,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[TiDBノードグループの概要](/tidb-cloud/tidb-node-group-overview.md)を参照してください。 -- AWS にデプロイされた[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのTiDB Cloudにデータベース監査ログ ファイルを保存することをサポートします。 +- AWS にデプロイされた[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのTiDB Cloudにデータベース監査ログファイルを保存することをサポートします。 これらの監査ログファイルは、 TiDB Cloudから直接ダウンロードできます。この機能はリクエストに応じてのみ利用可能であることにご注意ください。 @@ -741,7 +740,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- TiDB Cloudの新しいサポート サービスである Connected Care を紹介します。 +- TiDB Cloudの新しいサポートサービスである Connected Care を紹介します。 Connected Care サービスは、最新のコミュニケーション ツール、プロアクティブなサポート、高度な AI 機能を通じてTiDB Cloudとの接続を強化し、シームレスで顧客中心のエクスペリエンスを実現するように設計されています。 @@ -750,13 +749,13 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **Clinic Service**: パフォーマンスを最適化するための高度な監視と診断。 - **IM での AI チャット**: インスタント メッセージ (IM) ツールを通じて AI による即時サポートを受けることができます。 - **アラートとチケット更新の IM サブスクリプション**: IM 経由でアラートとチケットの進行状況に関する最新情報を入手します。 - - **サポート チケットの IM 対話**: IM ツールを使用してサポート チケットを作成し、対話します。 + - **サポートチケットの IM 対話**: IM ツールを使用してサポートチケットを作成し、対話します。 詳細については[Connected Careの概要](/tidb-cloud/connected-care-overview.md)を参照してください。 - GCS および Azure Blob Storage から[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターへのデータのインポートをサポートします。 - TiDB Cloud Serverless は、Google Cloud Storage (GCS) および Azure Blob Storage からのデータのインポートをサポートするようになりました。認証には、Google Cloud サービス アカウント キーまたは Azure Shared Access Signature (SAS) トークンを使用できます。この機能により、TiDB Cloud Serverless へのデータ移行が簡素化されます。 + TiDB Cloud Serverless は、Google Cloud Storage (GCS) および Azure Blob Storage からのデータのインポートをサポートするようになりました。認証には、Google Cloud サービスアカウント キーまたは Azure Shared Access Signature (SAS) トークンを使用できます。この機能により、TiDB Cloud Serverless へのデータ移行が簡素化されます。 詳細については、 [Amazon S3、GCS、または Azure Blob Storage からTiDB Cloud Serverless に CSV ファイルをインポートする](/tidb-cloud/import-csv-files-serverless.md)および[Amazon S3、GCS、または Azure Blob Storage から Apache Parquet ファイルをTiDB Cloud Serverless にインポートする](/tidb-cloud/import-parquet-files-serverless.md)を参照してください。 @@ -790,9 +789,9 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま Private Connect は、クラウドプロバイダーの Private Link または Private Service Connect テクノロジーを活用し、 TiDB Cloud VPC 内の変更フィードがプライベート IP アドレスを使用してお客様の VPC 内の Kafka に接続できるようにします。これにより、Kafka がTiDB Cloud VPC 内で直接ホストされているかのように扱われます。この機能は、VPC CIDR の競合を防止し、セキュリティコンプライアンス要件を満たすのに役立ちます。 - - AWS の Apache Kafka の場合は、 [AWS でセルフホスト型 Kafka プライベートリンク サービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)手順に従ってネットワーク接続を構成します。 + - AWS の Apache Kafka の場合は、 [AWS でセルフホスト型 Kafka プライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md)手順に従ってネットワーク接続を構成します。 - - Google Cloud の Apache Kafka の場合は、 [Google Cloud でセルフホスト型 Kafka プライベート サービス接続を設定する](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md)手順に従ってネットワーク接続を構成します。 + - Google Cloud の Apache Kafka の場合は、 [Google Cloud でセルフホスト型 Kafka プライベートサービス接続を設定する](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md)手順に従ってネットワーク接続を構成します。 この機能を使用すると、追加の[プライベートデータリンクのコスト](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md#private-data-link-cost)が発生することに注意してください。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index cdb8be7c689aa..3bf97f3a3152f 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -396,7 +396,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)でごみ箱機能が利用可能になりました。ごみ箱には、有効なバックアップが存在する削除済みTiDB Cloudリソースのデータが保存されます。 - バックアップが存在するTiDB Cloud Essentialインスタンスが削除されると、そのバックアップ ファイルはごみ箱に移動されます。自動バックアップによって作成されたバックアップ ファイルは、指定された期間、ごみ箱に保持されます。データ損失を防ぐため、保持期間が終了する前に、新しいTiDB Cloud Essentialインスタンスにデータを復元してください。なお、 TiDB Cloud Essentialインスタンス**にバックアップがない**場合、削除されたインスタンスはごみ箱に表示されません。 + バックアップが存在するTiDB Cloud Essentialインスタンスが削除されると、そのバックアップファイルはごみ箱に移動されます。自動バックアップによって作成されたバックアップファイルは、指定された期間、ごみ箱に保持されます。データ損失を防ぐため、保持期間が終了する前に、新しいTiDB Cloud Essentialインスタンスにデータを復元してください。なお、 TiDB Cloud Essentialインスタンス**にバックアップがない**場合、削除されたインスタンスはごみ箱に表示されません。 詳細については、 [バックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#restore-from-recycle-bin)を参照してください。 @@ -482,7 +482,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - 新しい[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデフォルトの TiDB バージョンを[v8.5.5](https://docs.pingcap.com/tidb/stable/release-8.5.5/)から[v8.5.6](https://docs.pingcap.com/tidb/stable/release-8.5.6/)にアップグレードします。 - - [TiDB Cloud Clinic](/tidb-cloud/tidb-cloud-clinic.md)のTop SQLページは、AWS 上でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの TiKV ネットワーク トラフィックと論理 I/O メトリックの収集と表示をサポートするようになりました。 + - [TiDB Cloud Clinic](/tidb-cloud/tidb-cloud-clinic.md)のTop SQLページは、AWS 上でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの TiKV ネットワークトラフィックと論理 I/O メトリックの収集と表示をサポートするようになりました。 **コンソールの変更** @@ -558,7 +558,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - **TiDB Cloud Dedicated** - - セキュリティ追跡を改善するために、 TiDB Cloudの [コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md)に**パブリック エンドポイント**ステータスを追加します。 + - セキュリティ追跡を改善するために、 TiDB Cloudの [コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md)に**パブリックエンドポイント**ステータスを追加します。 **コンソールの変更** @@ -572,7 +572,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - データフローシナリオにおけるプライベートリンク接続でのAmazon MSK Provisionedをサポートします。 - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、 [Amazon MSK プロビジョニング済み](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html)クラスターへのプライベート リンク接続の作成をサポートするようになりました。この機能により、トラフィックを公共のインターネットに公開することなく、Amazon MSK プロビジョニングされたクラスターへの変更フィードのプライベート ネットワーク接続が可能になります。 + [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、 [Amazon MSK プロビジョニング済み](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html)クラスターへのプライベートリンク接続の作成をサポートするようになりました。この機能により、トラフィックを公共のインターネットに公開することなく、Amazon MSK プロビジョニングされたクラスターへの変更フィードのプライベートネットワーク接続が可能になります。 詳細については、 [プライベートリンク接続を介してAmazon MSK Provisionedに接続します](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)を参照してください。 @@ -686,8 +686,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', - **プランに応じたサポートのリダイレクト**：クラスタ概要ページで、 **[アクション]**列の**[サポートを受ける]**を選択すると、サブスクリプションプランに基づいて最も適切なリソースにリダイレクトされます。Basicプランのユーザーは**サポートプラン**パネルに、有料プランのユーザーは**サポートポータル**に誘導されます。 - **ヘルプセンターメニューの改善**：ヘルプメニュー項目名を**サポートオプション**と**サポートチケット**に変更し、利用可能なサービスをより適切に反映させます。また、有料プランでのみテクニカルサポートチケットが利用できることを明確にするツールチップを追加します。 - - **明確なコミュニティ サポート アクセス**:**サポート プラン**オプション内では、Slack と Discord がBasic プラン ユーザーの主要なテクニカル サポート チャネルとして明確に識別されます。次のドキュメントは、サポート チャネル ポリシーとコミュニティ アクセスを明確にするために合理化されています: [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)、[Connected Careの概要](/tidb-cloud/connected-care-overview.md)、および[Connected Careの詳細](/tidb-cloud/connected-care-detail.md)。 - - **アクション指向のサポートプランUI** ：**サポートプラン**ウィンドウを再設計し、一般的なプラン比較ではなく、現在ご利用のプランで利用可能なサポートオプションを優先的に表示するようにしました。この変更により、現在ご利用のプランに基づいてサポートを受ける方法をすばやく特定できます。 + - **明確なコミュニティ サポート アクセス**:**サポートプラン**オプション内では、Slack と Discord がBasic プラン ユーザーの主要なテクニカルサポート チャネルとして明確に識別されます。次のドキュメントは、サポート チャネル ポリシーとコミュニティ アクセスを明確にするために合理化されています: [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)、[Connected Careの概要](/tidb-cloud/connected-care-overview.md)、および[Connected Careの詳細](/tidb-cloud/connected-care-detail.md)。 - **アクション指向のサポートプランUI** ：**サポートプラン**ウィンドウを再設計し、一般的なプラン比較ではなく、現在ご利用のプランで利用可能なサポートオプションを優先的に表示するようにしました。この変更により、現在ご利用のプランに基づいてサポートを受ける方法をすばやく特定できます。 詳細については、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)を参照してください。 diff --git a/tidb-cloud/scale-tidb-cluster.md b/tidb-cloud/scale-tidb-cluster.md index b75f48a358264..786906684b6a4 100644 --- a/tidb-cloud/scale-tidb-cluster.md +++ b/tidb-cloud/scale-tidb-cluster.md @@ -48,7 +48,7 @@ TiDB、TiKV、またはTiFlashノードの数を変更するには、次の手 4. **Modify Cluster**ページで、TiDB、TiKV、またはTiFlashノードの数を変更します。 -5. 右側のペインでクラスター サイズを確認し、 **[確認]**をクリックします。 +5. 右側のペインでクラスターサイズを確認し、 **[確認]**をクリックします。 TiDB Cloud APIを使用して、 [TiDB Cloud Dedicated クラスターを変更する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)エンドポイントからTiDB、TiKV、またはTiFlashノードの数を変更することもできます。現在、 TiDB Cloud APIはパブリックプレビューです。詳細については、 [TiDB Cloud API ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)をご覧ください。 @@ -79,7 +79,7 @@ TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更するには、 4. **Modify Cluster**ページで、TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更します。 -5. 右側のペインでクラスター サイズを確認し、 **[確認]**をクリックします。 +5. 右側のペインでクラスターサイズを確認し、 **[確認]**をクリックします。 TiDB Cloud APIを使用して、 [TiDB Cloud Dedicated クラスターを変更する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)エンドポイント経由でTiDB、TiKV、またはTiFlashノードのvCPUとRAMを変更することもできます。現在、 TiDB Cloud APIはパブリックプレビューです。詳細については、 [TiDB Cloud API ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)をご覧ください。 @@ -106,6 +106,6 @@ TiKV またはTiFlashのストレージを変更するには、次の手順を 4. **Modify Cluster**ページで、各 TiKV またはTiFlashノードのストレージを変更します。 -5. 右側のペインでクラスター サイズを確認し、 **[確認]**をクリックします。 +5. 右側のペインでクラスターサイズを確認し、 **[確認]**をクリックします。 TiDB Cloud APIを使用して、 [TiDB Cloud Dedicated クラスターを変更する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)エンドポイント経由でTiKVノードまたはTiFlashノードのストレージを変更することもできます。現在、 TiDB Cloud APIはパブリックプレビューです。詳細については、 [TiDB Cloud API ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)をご覧ください。 diff --git a/tidb-cloud/secure-connections-to-serverless-clusters.md b/tidb-cloud/secure-connections-to-serverless-clusters.md index 991c97bb5c400..35c5f97bc0a6b 100644 --- a/tidb-cloud/secure-connections-to-serverless-clusters.md +++ b/tidb-cloud/secure-connections-to-serverless-clusters.md @@ -25,7 +25,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] 2. 右上隅の**接続**をクリックします。ダイアログが表示されます。 -3. ダイアログでは、接続タイプのデフォルト設定を`Public`のままにして、希望する接続方法とオペレーティング システムを選択します。 +3. ダイアログでは、接続タイプのデフォルト設定を`Public`のままにして、希望する接続方法とオペレーティングシステムを選択します。 4. パスワードをまだ設定していない場合は、 **Generate Password**をクリックして、クラスター用のランダムパスワードを生成します。パスワードはサンプル接続文字列に自動的に埋め込まれ、クラスターへの接続が簡単になります。 @@ -53,7 +53,7 @@ JavaやGoなど、クライアントがシステムのルートCAストアをデ ### ルート証明書のデフォルトパス {#root-certificate-default-path} -異なるオペレーティング システムにおけるルート証明書のデフォルトのストレージパスは次のとおりです。 +異なるオペレーティングシステムにおけるルート証明書のデフォルトのストレージパスは次のとおりです。 **macOS** @@ -80,7 +80,7 @@ JavaやGoなど、クライアントがシステムのルートCAストアをデ WindowsはCAルートへの特定のパスを提供していません。代わりに、 [レジストリ](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/local-machine-and-current-user-certificate-stores)を使用して証明書を保存します。そのため、WindowsでCAルートパスを指定するには、次の手順に従います。 1. [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)をダウンロードし、 ``などの任意のパスに保存します。 -2. TiDB Cloudクラスターに接続するときは、パス ( `` ) を CA ルート パスとして使用します。 +2. TiDB Cloudクラスターに接続するときは、パス ( `` ) を CA ルートパスとして使用します。 ## よくある質問 {#faqs} @@ -98,4 +98,4 @@ TiDB Cloud は一方向の TLS 認証のみをサポートします。つまり 標準接続の場合、 TiDB CloudはTLS接続のみを許可し、SSL/TLS以外の接続は禁止しています。これは、SSL/TLSが、インターネット経由でTiDB Cloudクラスターに接続する際に、インターネットへのデータ漏洩リスクを軽減するための最も基本的なセキュリティ対策の一つであるためです。 -プライベート エンドポイント接続では、 TiDB Cloudサービスへの高度に安全な一方向アクセスがサポートされ、データがパブリック インターネットに公開されないため、TLS の構成はオプションです。 +プライベートエンドポイント接続では、 TiDB Cloudサービスへの高度に安全な一方向アクセスがサポートされ、データがパブリックインターネットに公開されないため、TLS の構成はオプションです。 diff --git a/tidb-cloud/security-concepts.md b/tidb-cloud/security-concepts.md index c2c75149b7f01..d6ddb2176e894 100644 --- a/tidb-cloud/security-concepts.md +++ b/tidb-cloud/security-concepts.md @@ -77,7 +77,7 @@ SQLプロキシアカウントは、 TiDB Cloudによって自動的に生成さ - **TiDB Cloudユーザーアカウントにリンクされています：**各SQLプロキシアカウントは、特定のTiDB Cloudユーザーに対応しています。 -- **役割にマッピングされています:** SQL プロキシ アカウントには`role_admin`役割が付与されます。 +- **役割にマッピングされています:** SQL プロキシアカウントには`role_admin`役割が付与されます。 - **トークンベース：** SQLプロキシアカウントは、パスワードの代わりに安全なJWTトークンを使用するため、 TiDB Cloud Data ServiceまたはSQLエディターを介したシームレスで制限されたアクセスが保証されます。 diff --git a/tidb-cloud/select-cluster-tier.md b/tidb-cloud/select-cluster-tier.md index b8ca7445ec1cd..df42efe4dcc54 100644 --- a/tidb-cloud/select-cluster-tier.md +++ b/tidb-cloud/select-cluster-tier.md @@ -98,7 +98,7 @@ TiDB Cloudは、 TiDB Cloud StarterまたはTiDB Cloud Essentialの各インス > **Note:** > - > TiDB Cloud StarterおよびTiDB Cloud Essential には TLS 接続が必要です。システム上の CA ルート パスを見つけるには、 [ルート証明書のデフォルトパス](/tidb-cloud/secure-connections-to-serverless-clusters.md#root-certificate-default-path)を参照してください。 + > TiDB Cloud StarterおよびTiDB Cloud Essential には TLS 接続が必要です。システム上の CA ルートパスを見つけるには、 [ルート証明書のデフォルトパス](/tidb-cloud/secure-connections-to-serverless-clusters.md#root-certificate-default-path)を参照してください。 - データベースユーザーを作成するには： diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index 21e0b3ddce48a..cb7cba787be18 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -9,9 +9,9 @@ TiDB Cloudを使用すると、 TiDB Cloud StarterまたはEssentialクラスタ [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)や TiDB [Dumpling](https://docs.pingcap.com/tidb/dev/dumpling-overview)などのツールを使用してデータをエクスポートすることもできますが、 TiDB Cloudが提供するエクスポート機能は、クラスターからデータをエクスポートするためのより便利で効率的な方法を提供します。これには、次のような利点があります。 -- 利便性: エクスポート サービスは、クラスターからデータをエクスポートするためのシンプルで使いやすい方法を提供するため、追加のツールやリソースは必要ありません。 -- 分離: エクスポート サービスは個別のコンピューティング リソースを使用するため、オンライン サービスで使用されるリソースからの分離が保証されます。 -- 一貫性: エクスポート サービスは、ロックを発生させることなくエクスポートされたデータの一貫性を確保するため、オンライン サービスには影響しません。 +- 利便性: エクスポートサービスは、クラスターからデータをエクスポートするためのシンプルで使いやすい方法を提供するため、追加のツールやリソースは必要ありません。 +- 分離: エクスポートサービスは個別のコンピューティングリソースを使用するため、オンラインサービスで使用されるリソースからの分離が保証されます。 +- 一貫性: エクスポートサービスは、ロックを発生させることなくエクスポートされたデータの一貫性を確保するため、オンラインサービスには影響しません。 > **Note:** > @@ -41,13 +41,13 @@ TiDB Cloudを使用すると、 TiDB Cloud StarterまたはEssentialクラスタ ### ローカルファイル {#a-local-file} -{{{ .starter }}} インスタンスからローカル ファイルにデータをエクスポートするには、データ[TiDB Cloudコンソールを使用する](#export-data-to-a-local-file)または[TiDB Cloud CLIを使用する](/tidb-cloud/ticloud-serverless-export-create.md)エクスポートし、エクスポートしたデータをTiDB Cloud CLI を使用してダウンロードする必要があります。 +{{{ .starter }}} インスタンスからローカルファイルにデータをエクスポートするには、データ[TiDB Cloudコンソールを使用する](#export-data-to-a-local-file)または[TiDB Cloud CLIを使用する](/tidb-cloud/ticloud-serverless-export-create.md)エクスポートし、エクスポートしたデータをTiDB Cloud CLI を使用してダウンロードする必要があります。 -データをローカル ファイルにエクスポートする場合、次の制限があります。 +データをローカルファイルにエクスポートする場合、次の制限があります。 - TiDB Cloudコンソールを使用してエクスポートされたデータをダウンロードすることはサポートされていません。 - エクスポートされたデータはTiDB Cloudのステージングエリアに保存され、2日後に有効期限が切れます。エクスポートしたデータは期限内にダウンロードする必要があります。 -- ステージング領域のストレージスペースがいっぱいの場合、データをローカル ファイルにエクスポートすることはできません。 +- ステージング領域のストレージスペースがいっぱいの場合、データをローカルファイルにエクスポートすることはできません。 ### Amazon S3 {#amazon-s3} @@ -55,7 +55,7 @@ Amazon S3 にデータをエクスポートするには、次の情報を提供 - URI: `s3:////` - 次のいずれかのアクセス資格情報: - - [アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) : アクセス キーに`s3:PutObject`と`s3:ListBucket`権限があることを確認します。 + - [アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) : アクセスキーに`s3:PutObject`と`s3:ListBucket`権限があることを確認します。 - [ロールARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) : ロールARN（Amazonリソースネーム）に`s3:PutObject`と`s3:ListBucket`権限があることを確認してください。このロールARNはAWSでホストされているクラスターでのみサポートされることに注意してください。 詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 @@ -185,9 +185,9 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット {{{ .starter }}} インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 +2. ターゲット {{{ .starter }}} インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 3. **インポート**ページで、右上隅の**Export Data to**をクリックし、ドロップダウンリストから**Local File**を選択します。以下のパラメータを入力します。 @@ -219,7 +219,7 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 出力からエクスポート ID が取得されます。 -2. エクスポート タスクが成功したら、エクスポートされたデータをローカル ファイルにダウンロードします。 +2. エクスポート タスクが成功したら、エクスポートされたデータをローカルファイルにダウンロードします。 ```shell ticloud serverless export download -c -e @@ -239,9 +239,9 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 3. **インポート**ページで、右上隅の**Export Data to**をクリックし、ドロップダウンリストから**Amazon S3**を選択します。以下のパラメータを入力します。 @@ -267,8 +267,8 @@ ticloud serverless export create -c --target-type S3 --s3.uri ``` - `s3.uri` : `s3:////`形式の Amazon S3 URI。 -- `s3.access-key-id` : バケットにアクセスする権限を持つユーザーのアクセス キー ID。 -- `s3.secret-access-key` : バケットにアクセスする権限を持つユーザーのアクセス キー シークレット。 +- `s3.access-key-id` : バケットにアクセスする権限を持つユーザーのアクセスキー ID。 +- `s3.secret-access-key` : バケットにアクセスする権限を持つユーザーのアクセスキー シークレット。 - `s3.role-arn` : バケットにアクセスする権限を持つロール ARN。 @@ -283,9 +283,9 @@ ticloud serverless export create -c --target-type S3 --s3.uri > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット {{{ .starter }}} インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 +2. ターゲット {{{ .starter }}} インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 3. **インポート**ページで、右上隅の**Export Data to**をクリックし、ドロップダウンリストから**Google Cloud Storage**を選択します。以下のパラメータを入力します。 @@ -307,7 +307,7 @@ ticloud serverless export create -c --target-type GCS --gcs.uri //`形式の Google Cloud Storage バケットの URI。 -- `gcs.service-account-key` : base64 でエンコードされたサービス アカウント キー。 +- `gcs.service-account-key` : base64 でエンコードされたサービスアカウント キー。 @@ -321,9 +321,9 @@ ticloud serverless export create -c --target-type GCS --gcs.uri **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 3. **インポート**ページで、右上隅の**Export Data to**をクリックし、ドロップダウンリストから**Azure Blob Storage**を選択します。以下のパラメータを入力します。 @@ -359,9 +359,9 @@ ticloud serverless export create -c --target-type AZURE_BLOB --azbl > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 3. **インポート**ページで、右上隅の**Export Data to**をクリックし、ドロップダウンリストから**Alibaba Cloud OSS**を選択します。 @@ -402,11 +402,11 @@ ticloud serverless export create -c --target-type OSS --oss.uri **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート] を**クリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート] を**クリックします。 -3. **[インポート]**ページで**[エクスポート]**をクリックして、エクスポート タスク リストを表示します。 +3. **[インポート]**ページで**[エクスポート]**をクリックして、エクスポート タスクリストを表示します。 4. キャンセルするエクスポート タスクを選択し、 **[アクション]**をクリックします。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index c69f949f0f8ab..f1f0c8860eaaa 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -49,13 +49,13 @@ TiDB Cloud StarterをGoogle CloudやAzureを含む他のクラウドプラット ### TiDB Cloud Starterが利用可能になる前にDeveloper Tierクラスターを作成しました。このクラスターは引き続き使用できますか？ {#i-created-a-developer-tier-cluster-before-tidb-cloud-starter-was-available-can-i-still-use-my-cluster} -はい、 Developer TierクラスターはTiDB Cloud Starter クラスターに自動的に移行されており、以前の使用状況に支障をきたすことなく、ユーザー エクスペリエンスが向上します。 +はい、 Developer TierクラスターはTiDB Cloud Starter クラスターに自動的に移行されており、以前の使用状況に支障をきたすことなく、ユーザーエクスペリエンスが向上します。 ### TiDB Cloud Starter の列指向ストレージとは何ですか? {#what-is-columnar-storage-in-tidb-cloud-starter} TiDB Cloud Starterの列指向ストレージは、行ベースストレージの追加レプリカとして機能し、強力な一貫性を確保します。従来の行ベースストレージはデータを行単位で保存しますが、列指向ストレージはデータを列単位で整理し、データ分析タスクに最適化します。 -列指向ストレージは、トランザクション ワークロードと分析ワークロードをシームレスに融合することで、TiDB のハイブリッド トランザクションおよび分析処理 (HTAP) 機能を有効にする重要な機能です。 +列指向ストレージは、トランザクション ワークロードと分析ワークロードをシームレスに融合することで、TiDB のハイブリッドトランザクションおよび分析処理 (HTAP) 機能を有効にする重要な機能です。 列指向ストレージデータを効率的に管理するために、 TiDB Cloud Starterは独立したElastic TiFlashエンジンを使用します。クエリ実行中、オプティマイザーはクラスターに対し、行ベースストレージと列指向ストレージのどちらからデータを取得するかを自動的に決定するよう指示します。 @@ -73,8 +73,8 @@ TiDB Cloud Starterの列指向ストレージは、行ベースストレージ TiDB Cloud Starter での列指向ストレージの使用は、 TiFlashでの使用と同様です。列指向ストレージは、テーブルレベルとデータベースレベルの両方で有効にできます。 -- テーブル レベル: TiFlashレプリカをテーブルに割り当てて、特定のテーブルの列指向ストレージを有効にします。 -- データベース レベル: データベース全体で列型ストレージを使用するように、データベース内のすべてのテーブルに対してTiFlashレプリカを構成します。 +- テーブルレベル: TiFlashレプリカをテーブルに割り当てて、特定のテーブルの列指向ストレージを有効にします。 +- データベースレベル: データベース全体で列型ストレージを使用するように、データベース内のすべてのテーブルに対してTiFlashレプリカを構成します。 テーブルにTiFlashレプリカが設定されると、TiDBは行ベースストレージからそのテーブルの列指向ストレージにデータを自動的に複製します。これにより、データの一貫性が確保され、分析クエリのパフォーマンスが最適化されます。 @@ -142,7 +142,7 @@ TiDB の必須バックグラウンドジョブが原因で、RU 使用量が急 ### データのインポート中に RU 使用量が急増するのはなぜですか? {#why-do-i-observe-spikes-in-ru-usage-while-importing-data} -TiDB Cloud Starter クラスターのデータ インポート プロセス中、データが正常にインポートされた場合にのみ RU 消費が発生するため、RU 使用量が急増します。 +TiDB Cloud Starter クラスターのデータインポートプロセス中、データが正常にインポートされた場合にのみ RU 消費が発生するため、RU 使用量が急増します。 ### TiDB Cloud Starter で列指向ストレージを使用する場合、どのようなコストがかかりますか? {#what-costs-are-involved-when-using-columnar-storage-in-tidb-cloud-starter} @@ -154,7 +154,7 @@ TiDB Cloud Starter の列指向ストレージの料金は、行指向ストレ TiDB Cloud Starterの列指向ストレージは、追加のレプリカが必要となり、データレプリケーションに必要なストレージとリソースが増えるため、追加コストが発生します。ただし、分析クエリを実行する際には、列指向ストレージがコスト効率が高くなります。 -TPC-H ベンチマーク テストによると、列ベースのストレージで分析クエリを実行するコストは、行ベースのストレージを使用する場合のコストの約 3 分の 1 になります。 +TPC-H ベンチマークテストによると、列ベースのストレージで分析クエリを実行するコストは、行ベースのストレージを使用する場合のコストの約 3 分の 1 になります。 したがって、追加のレプリカによる初期コストは発生する可能性がありますが、分析時の計算コストが削減されるため、特定のユースケースではより費用対効果の高いものになる可能性があります。特に分析ニーズが高いユーザーにとって、列指向ストレージはコストを大幅に削減し、大幅なコスト削減の機会を提供します。 @@ -167,7 +167,7 @@ TPC-H ベンチマーク テストによると、列ベースのストレージ ### TiDB Cloud Starter はどのようにしてセキュリティを確保しますか? {#how-does-tidb-cloud-starter-ensure-security} - 接続はTransport Layer Security（TLS）によって暗号化されます。TLSを使用してTiDB Cloud Starterに接続する方法の詳細については、 [TiDB Cloud StarterへのTLS接続](/tidb-cloud/secure-connections-to-serverless-clusters.md)をご覧ください。 -- TiDB Cloud Starter に保存されるすべてのデータは、クラスターが実行されているクラウド プロバイダーのツールを使用して保存時に暗号化されます。 +- TiDB Cloud Starter に保存されるすべてのデータは、クラスターが実行されているクラウドプロバイダーのツールを使用して保存時に暗号化されます。 ## メンテナンスに関するFAQ {#maintenance-faq} diff --git a/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md b/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md index 6bb10688170ee..5cab0f2a878ac 100644 --- a/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md @@ -23,7 +23,7 @@ summary: Alibaba Cloud Endpoint Service プライベートリンク接続を使 Alibaba Cloud アカウント ID とアベイラビリティーゾーンを表示するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 2. **[外部サービス向け Alibaba Cloud プライベートエンドポイント]**領域で、**[外部サービス向けプライベートエンドポイントの作成]**をクリックします。 3. 表示されたダイアログで、Alibaba Cloud アカウント ID とアベイラビリティーゾーンを見つけることができます。 @@ -34,7 +34,7 @@ Alibaba Cloud アカウント ID とアベイラビリティーゾーンを表 ApsaraDB RDS for MySQL インスタンスは次の要件を満たしている必要があります。 - リージョンの一致: インスタンスは、 TiDB Cloud Essential クラスターと同じ Alibaba Cloud リージョンに存在する必要があります。 -- AZ (アベイラビリティ ゾーン) の可用性: アベイラビリティ ゾーンは、 TiDB Cloud Essential クラスターのアベイラビリティ ゾーンと重複する必要があります。 +- AZ (アベイラビリティゾーン) の可用性: アベイラビリティゾーンは、 TiDB Cloud Essential クラスターのアベイラビリティゾーンと重複する必要があります。 - ネットワークのアクセシビリティ: インスタンスは適切な IP 許可リストで構成され、VPC 内でアクセス可能である必要があります。 > **Note** @@ -43,7 +43,7 @@ ApsaraDB RDS for MySQL インスタンスは次の要件を満たしている必 ## ステップ2. ApsaraDB RDS for MySQLインスタンスをエンドポイントサービスとして公開する {#step-2-expose-the-apsaradb-rds-for-mysql-instance-as-an-endpoint-service} -Alibaba Cloud コンソールでロードバランサーとエンドポイント サービスを設定する必要があります。 +Alibaba Cloud コンソールでロードバランサーとエンドポイントサービスを設定する必要があります。 ### ステップ2.1. ロードバランサーを設定する {#step-2-1-set-up-the-load-balancer} @@ -74,7 +74,7 @@ Alibaba Cloud コンソールでロードバランサーとエンドポイント ### ステップ2.2. エンドポイントサービスを設定する {#step-2-2-set-up-an-endpoint-service} -ApsaraDB RDS for MySQL と同じリージョンにエンドポイント サービスを設定するには、次の手順を実行します。 +ApsaraDB RDS for MySQL と同じリージョンにエンドポイントサービスを設定するには、次の手順を実行します。 1. エンドポイントサービスを作成するには、 [エンドポイントサービス](https://vpc.console.alibabacloud.com/endpointservice)に進んでください。以下の情報を入力してください。 @@ -88,6 +88,6 @@ ApsaraDB RDS for MySQL と同じリージョンにエンドポイント サー ## ステップ3. TiDB Cloudでプライベートリンク接続を作成する {#step-3-create-a-private-link-connection-in-tidb-cloud} -TiDB CloudコンソールまたはTiDB Cloud CLI を使用してプライベート リンク接続を作成できます。 +TiDB CloudコンソールまたはTiDB Cloud CLI を使用してプライベートリンク接続を作成できます。 詳細については[Alibaba Cloud Endpoint Service のプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-alibaba-cloud-endpoint-service-private-link-connection)を参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md index c884062364665..c72867d5a0ce0 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -16,7 +16,7 @@ summary: Amazon MSK プロビジョニングされたプライベートリンク AWS アカウント ID とアベイラビリティーゾーンを表示するには: -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 2. **[外部サービス向け AWS プライベートエンドポイント]**領域で、**[外部サービス向けプライベートエンドポイントを作成]**をクリックします。 3. ダイアログで、AWS アカウント ID とアベイラビリティーゾーンをメモします。 @@ -152,6 +152,6 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 ## ステップ 5. TiDB Cloudで Amazon MSK プロビジョニングされたプライベートリンク接続を作成する {#step-5-create-an-amazon-msk-provisioned-private-link-connection-in-tidb-cloud} -MSK クラスターの`ARN`を使用して、 TiDB Cloudにプライベート リンク接続を作成します。 +MSK クラスターの`ARN`を使用して、 TiDB Cloudにプライベートリンク接続を作成します。 詳細については[Amazon MSK プロビジョニングされたプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-amazon-msk-provisioned-private-link-connection)を参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md index 44779e2cc698f..88737483ae3a7 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md @@ -1,6 +1,6 @@ --- title: Connect to Confluent Cloud on AWS via a Private Link Connection -summary: AWS エンドポイント サービス プライベート リンク接続を使用して AWS 上の Confluent Cloud Dedicated クラスターに接続する方法を学習します。 +summary: AWS エンドポイントサービス プライベートリンク接続を使用して AWS 上の Confluent Cloud Dedicated クラスターに接続する方法を学習します。 --- # プライベートリンク接続を介して AWS 上の Confluent Cloud に接続する {#connect-to-confluent-cloud-on-aws-via-a-private-link-connection} @@ -9,7 +9,7 @@ summary: AWS エンドポイント サービス プライベート リンク接 > **Note** > -> AWS 上のすべての Confluent Cloud クラスター タイプのうち、プライベート リンク接続をサポートするのは Confluent Cloud Dedicated クラスターのみです。 +> AWS 上のすべての Confluent Cloud クラスター タイプのうち、プライベートリンク接続をサポートするのは Confluent Cloud Dedicated クラスターのみです。 ## 前提条件 {#prerequisites} @@ -22,7 +22,7 @@ summary: AWS エンドポイント サービス プライベート リンク接 AWS アカウント ID とアベイラビリティーゾーンを表示するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 2. **[外部サービス向け AWS プライベートエンドポイント]**領域で、**[外部サービス向けプライベートエンドポイントの作成]**をクリックします。 3. 表示されたダイアログで、AWS アカウント ID とアベイラビリティーゾーンを見つけることができます。 @@ -34,7 +34,7 @@ Confluent Cloud ネットワークは次の要件を満たしている必要が - タイプ: ネットワークは**PrivateLink**ネットワークである必要があります。 - リージョンの一致: ネットワークは、 TiDB Cloud Essential クラスターと同じ AWS リージョンに存在する必要があります。 -- AZ (アベイラビリティ ゾーン) の可用性: ネットワークのアベイラビリティ ゾーンは、 TiDB Cloud Essential クラスターのアベイラビリティ ゾーンと重複している必要があります。 +- AZ (アベイラビリティゾーン) の可用性: ネットワークのアベイラビリティゾーンは、 TiDB Cloud Essential クラスターのアベイラビリティゾーンと重複している必要があります。 Confluent Cloud ネットワークの一意の名前を取得するには、次の手順を実行します。 @@ -59,9 +59,9 @@ Confluent Cloud ネットワークの一意の名前を取得するには、次 ## ステップ4. TiDB Cloudでプライベートリンク接続を作成する {#step-4-create-a-private-link-connection-in-tidb-cloud} -TiDB Cloudでプライベート リンク接続を作成するには、次の手順を実行します。 +TiDB Cloudでプライベートリンク接続を作成するには、次の手順を実行します。 -1. Confluent Cloud の`VPC Service Endpoint`を使用して、 TiDB Cloudにプライベート リンク接続を作成します。 +1. Confluent Cloud の`VPC Service Endpoint`を使用して、 TiDB Cloudにプライベートリンク接続を作成します。 詳細については[AWS エンドポイントサービスプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)を参照してください。 @@ -69,6 +69,6 @@ TiDB Cloudでプライベート リンク接続を作成するには、次の手 > > AWS 上の Confluent Cloud Dedicated クラスターの場合、 TiDB Cloudからのエンドポイント接続リクエストを手動で承認するために、AWS コンソールのエンドポイントサービスの詳細ページに移動する必要はありません。Confluent Cloud が自動的に処理します。 -2. TiDB Cloudのデータフロー サービスが Confluent クラスターにアクセスできるように、Confluent Cloud サービス ドメインをプライベート リンク接続に接続します。 +2. TiDB Cloudのデータフロー サービスが Confluent クラスターにアクセスできるように、Confluent Cloud サービス ドメインをプライベートリンク接続に接続します。 詳細については[プライベートリンク接続にドメインを添付する](/tidb-cloud/serverless-private-link-connection.md#attach-domains-to-a-private-link-connection)を参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md index 59f27a3fb9952..08d06756a542f 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md @@ -35,7 +35,7 @@ AWSアカウントIDとアベイラビリティゾーンを表示するには、 Amazon RDSインスタンスは、以下の要件を満たす必要があります。 - リージョンの一致：インスタンスは、 TiDB Cloud Essentialインスタンスと同じAWSリージョンに存在する必要があります。 -- Amazon RDS インスタンスの[サブネットグループ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Subnets)には、TiDB Cloud Essentialインスタンスのアベイラビリティ ゾーンと重複するアベイラビリティ ゾーンが必要です。 +- Amazon RDS インスタンスの[サブネットグループ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Subnets)には、TiDB Cloud Essentialインスタンスのアベイラビリティゾーンと重複するアベイラビリティゾーンが必要です。 - Amazon RDSインスタンスに適切なセキュリティグループを設定し、VPC内からアクセス可能であることを確認してください。例えば、以下のルールを持つセキュリティグループを作成できます。 - MySQL/ Auroraを許可する受信ルール： @@ -67,7 +67,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー 詳細については、 [ネットワークロードバランサーのターゲットグループを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html)を参照してください。 -2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers)に移動して、ネットワーク ロード バランサーを作成します。次の情報を入力してください。 +2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers)に移動して、ネットワークロードバランサーを作成します。次の情報を入力してください。 - **スキーマ**: `Internal`を選択 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..f52126702c9ff 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 @@ -1,6 +1,6 @@ --- title: Connect to Alibaba Cloud Self-Hosted Kafka via Private Link Connection -summary: Alibaba Cloud Endpoint Service のプライベート リンク接続を使用して、Alibaba Cloud セルフホスト型 Kafka に接続する方法を学習します。 +summary: Alibaba Cloud Endpoint Service のプライベートリンク接続を使用して、Alibaba Cloud セルフホスト型 Kafka に接続する方法を学習します。 --- # プライベートリンク接続を介して Alibaba Cloud Self-Hosted Kafka に接続する {#connect-to-alibaba-cloud-self-hosted-kafka-via-a-private-link-connection} @@ -9,12 +9,12 @@ summary: Alibaba Cloud Endpoint Service のプライベート リンク接続を このメカニズムは次のように機能します。 -1. プライベート リンク接続は、 `advertised.listeners`で定義されたブローカー外部アドレスを返すブートストラップ ポートを使用して Alibaba Cloud エンドポイント サービスに接続します。 -2. プライベート リンク接続は、ブローカーの外部アドレスを使用してエンドポイント サービスに接続します。 -3. Alibaba Cloud エンドポイント サービスは、リクエストをロード バランサーに転送します。 -4. ロード バランサーは、ポート マッピングに基づいて、対応する Kafka ブローカーにリクエストを転送します。 +1. プライベートリンク接続は、 `advertised.listeners`で定義されたブローカー外部アドレスを返すブートストラップ ポートを使用して Alibaba Cloud エンドポイントサービスに接続します。 +2. プライベートリンク接続は、ブローカーの外部アドレスを使用してエンドポイントサービスに接続します。 +3. Alibaba Cloud エンドポイントサービスは、リクエストをロードバランサーに転送します。 +4. ロードバランサーは、ポートマッピングに基づいて、対応する Kafka ブローカーにリクエストを転送します。 -たとえば、ポート マッピングは次のようになります。 +たとえば、ポートマッピングは次のようになります。 | ブローカー外部アドレスポート | ロードバランサーのリスナーポート | ロードバランサバックエンドサーバー | | -------------- | ---------------- | ----------------- | @@ -30,7 +30,7 @@ summary: Alibaba Cloud Endpoint Service のプライベート リンク接続を - VPCとvSwitchを管理する - ECS ノードに接続して Kafka ノードを構成する -- Alibaba Cloud アカウントでロードバランサーとエンドポイント サービスを設定するには、次の権限があることを確認してください。 +- Alibaba Cloud アカウントでロードバランサーとエンドポイントサービスを設定するには、次の権限があることを確認してください。 - ロードバランサーを管理する - エンドポイントサービスの管理 @@ -42,7 +42,7 @@ summary: Alibaba Cloud Endpoint Service のプライベート リンク接続を Alibaba Cloud アカウント ID とアベイラビリティーゾーンを表示するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 2. **[外部サービス向け Alibaba Cloud プライベートエンドポイント]**領域で、**[外部サービス向けプライベートエンドポイントの作成]**をクリックします。 3. 表示されたダイアログで、Alibaba Cloud アカウント ID とアベイラビリティーゾーンを見つけることができます。 @@ -80,7 +80,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. **名前**を入力します (例: `Kafka VPC` )。 - 2. TiDB Cloudでプライベート リンク接続を設定するリージョンを選択します。 + 2. TiDB Cloudでプライベートリンク接続を設定するリージョンを選択します。 3. **[IPv4 CIDR ブロックを手動で入力]**を選択し、IPv4 CIDR (例: `10.0.0.0/16`を入力します。 @@ -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 @@ -156,7 +156,7 @@ Kafka VPC を作成するには、次の手順を実行します。 tar -zxf openjdk-22.0.2_linux-x64_bin.tar.gz ``` -3. 要塞ノードから各ブローカー ノードにバイナリをコピーします。 +3. 要塞ノードから各ブローカーノードにバイナリをコピーします。 ```shell # Replace {broker-node1-ip} with your broker-node1 IP address @@ -269,7 +269,7 @@ log.dirs=./data **2.4.3 Kafkaブローカーを起動する** -スクリプトを作成し、それを実行して各ブローカー ノードで Kafka ブローカーを起動します。 +スクリプトを作成し、それを実行して各ブローカーノードで Kafka ブローカーを起動します。 ```shell #!/bin/bash @@ -581,7 +581,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - **Backend Server Protocol**: `TCP`を選択 - **Backend servers**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node3:39092`を追加します。 -2. [NLB](https://slb.console.alibabacloud.com/nlb)に進み、ネットワーク ロード バランサーを作成します。 +2. [NLB](https://slb.console.alibabacloud.com/nlb)に進み、ネットワークロードバランサーを作成します。 - **Network Type**: `Internal-facing`を選択 - **VPC** : `Kafka VPC` @@ -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 リスナーを作成します。 - ブートストラップサーバーグループ @@ -634,9 +634,9 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null ### 2. Alibaba Cloudエンドポイントサービスを設定する {#2-set-up-an-alibaba-cloud-endpoint-service} -同じリージョンにエンドポイント サービスを設定します。 +同じリージョンにエンドポイントサービスを設定します。 -1. エンドポイント サービスを作成するには、 [エンドポイントサービス](https://vpc.console.alibabacloud.com/endpointservice)に進みます。 +1. エンドポイントサービスを作成するには、 [エンドポイントサービス](https://vpc.console.alibabacloud.com/endpointservice)に進みます。 - **Service Resource Type**: `NLB`を選択 - **Select Service Resource**: NLB が含まれるすべてのゾーンを選択し、前の手順で作成した NLB を選択します。 @@ -648,19 +648,19 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null ## ステップ3. TiDB Cloudでプライベートリンク接続を作成する {#step-3-create-a-private-link-connection-in-tidb-cloud} -TiDB Cloudでプライベート リンク接続を作成するには、次の手順を実行します。 +TiDB Cloudでプライベートリンク接続を作成するには、次の手順を実行します。 -1. [ステップ2](#2-set-up-an-alibaba-cloud-endpoint-service)で取得した Alibaba Cloud エンドポイント サービス名 (例: `com.aliyuncs.privatelink..xxxxx` ) を使用して、 TiDB Cloudにプライベート リンク接続を作成します。 +1. [ステップ2](#2-set-up-an-alibaba-cloud-endpoint-service)で取得した Alibaba Cloud エンドポイントサービス名 (例: `com.aliyuncs.privatelink..xxxxx` ) を使用して、 TiDB Cloudにプライベートリンク接続を作成します。 詳細については[Alibaba Cloud Endpoint Service のプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-alibaba-cloud-endpoint-service-private-link-connection)を参照してください。 -2. TiDB Cloudのデータフロー サービスが Kafka クラスターにアクセスできるように、プライベート リンク接続にドメインをアタッチします。 +2. TiDB Cloudのデータフロー サービスが Kafka クラスターにアクセスできるように、プライベートリンク接続にドメインをアタッチします。 詳細については、 [プライベートリンク接続にドメインを添付する](/tidb-cloud/serverless-private-link-connection.md#attach-domains-to-a-private-link-connection)を参照してください。 **Attach Domains**ダイアログで、ドメインの種類として**TiDB Cloud Managed**を選択し、生成されたドメインの一意の名前を後で使用するためにコピーする必要があることに注意してください。 ## ステップ4. Kafka設定内の一意の名前プレースホルダーを置き換える {#step-4-replace-the-unique-name-placeholder-in-kafka-configuration} -1. Kafka ブローカー ノードに戻り、各ブローカーの`advertised.listeners`構成内の`unique_name`プレースホルダーを、前の手順で取得した実際の一意の名前に置き換えます。 +1. Kafka ブローカーノードに戻り、各ブローカーの`advertised.listeners`構成内の`unique_name`プレースホルダーを、前の手順で取得した実際の一意の名前に置き換えます。 2. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 -これで、このプライベート リンク接続と 9092 をブートストラップ ポートとして使用し、 TiDB Cloudから Kafka クラスターに接続できるようになります。 +これで、このプライベートリンク接続と 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..1847f8d665c8d 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 @@ -10,9 +10,9 @@ summary: AWS エンドポイントサービスプライベートリンク接続 このメカニズムは次のように機能します。 1. プライベートリンク接続は、すべての Kafka ブローカーのアドレスとポートを返すブートストラップブローカーアドレスを使用して AWS エンドポイントサービスに接続します。 -2. TiDB Cloud は、返されたブローカー アドレスとポートを使用して、プライベート リンク接続を介して接続を確立します。 +2. TiDB Cloud は、返されたブローカーアドレスとポートを使用して、プライベートリンク接続を介して接続を確立します。 3. AWS エンドポイントサービスは、リクエストをロードバランサーに転送します。 -4. ロード バランサーは、ポート マッピングに基づいて、対応する Kafka ブローカーにリクエストをルーティングします。 +4. ロードバランサーは、ポートマッピングに基づいて、対応する Kafka ブローカーにリクエストをルーティングします。 ## 前提条件 {#prerequisites} @@ -25,7 +25,7 @@ summary: AWS エンドポイントサービスプライベートリンク接続 - AWS アカウントでロードバランサーとエンドポイントサービスを設定するには、次の権限があることを確認してください。 - - セキュリティ グループを管理する + - セキュリティグループを管理する - ロードバランサーを管理する - エンドポイントサービスの管理 @@ -36,7 +36,7 @@ summary: AWS エンドポイントサービスプライベートリンク接続 AWS アカウント ID とアベイラビリティーゾーンを表示するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーション ペインで**Settings** > **Networking**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB クラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**Settings** > **Networking**をクリックします。 2. **AWS Private Endpoints for External Services**領域で、 **Create Private Endpoint for External Services**をクリックします。 3. 表示されたダイアログで、AWS アカウント ID とアベイラビリティーゾーンを見つけることができます。 @@ -61,7 +61,7 @@ AWS アカウント ID とアベイラビリティーゾーンを表示するに Kafka VPC には次のものが必要です。 -- ブローカー用のプライベート サブネットが 3 つ (AZ ごとに 1 つ)。 +- ブローカー用のプライベートサブネットが 3 つ (AZ ごとに 1 つ)。 - 任意の AZ に 1 つのパブリックサブネットがあり、インターネットに接続できる要塞ノードと 3 つのプライベートサブネットがあるため、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の要塞ノードが必要になる場合があります。 サブネットを作成する前に、AZ IDとAZ名のマッピングに基づいてAZ内にサブネットを作成します。以下のマッピングを例に挙げます。 @@ -70,7 +70,7 @@ Kafka VPC には次のものが必要です。 - `usw2-az2` => `us-west-2c` - `usw2-az3` => `us-west-2b` -次の AZ にプライベート サブネットを作成します。 +次の AZ にプライベートサブネットを作成します。 - `us-west-2a` - `us-west-2c` @@ -123,12 +123,12 @@ Kafka VPC を作成するには、次の手順を実行します。 2. 前にメモしておいた**VPC ID** (この例では`vpc-01f50b790fa01dffa` ) を選択します。 -3. 次の情報を使用して、任意の AZ にパブリック サブネットを追加します。 +3. 次の情報を使用して、任意の AZ にパブリックサブネットを追加します。 - **Subnet name**: `bastion` - **IPv4 subnet CIDR block**： `10.0.192.0/18` -4. 要塞サブネットをパブリック サブネットに構成します。 +4. 要塞サブネットをパブリックサブネットに構成します。 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。`kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 @@ -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 @@ -233,7 +233,7 @@ Kafka VPC を作成するには、次の手順を実行します。 tar -zxf openjdk-22.0.2_linux-x64_bin.tar.gz ``` -3. バイナリを各ブローカー ノードにコピーします。 +3. バイナリを各ブローカーノードにコピーします。 ```shell # Replace {broker-node1-ip} with your broker-node1 IP address @@ -349,7 +349,7 @@ log.dirs=./data **2.4.3 Kafkaブローカーを起動する** -スクリプトを作成し、それを実行して各ブローカー ノードで Kafka ブローカーを起動します。 +スクリプトを作成し、それを実行して各ブローカーノードで Kafka ブローカーを起動します。 ```shell #!/bin/bash @@ -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 つのターゲットグループを作成します。 - ブートストラップターゲットグループ @@ -674,7 +674,7 @@ b3.usw2-az3.unique_name.aws.plc.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: - **Health check protocol**： `TCP` - **Register targets**: `broker-node3:39092` -2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers:)に進み、ネットワーク ロード バランサーを作成します。 +2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers:)に進み、ネットワークロードバランサーを作成します。 - **Load balancer name**: `kafka-lb` - **Schema**: `Internal` @@ -684,7 +684,7 @@ b3.usw2-az3.unique_name.aws.plc.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: - `usw2-az1`と`broker-usw2-az1 subnet` - `usw2-az2`と`broker-usw2-az2 subnet` - `usw2-az3`と`broker-usw2-az3 subnet` - - **Security groups**: 次のルールで新しいセキュリティ グループを作成します。 + - **Security groups**: 次のルールで新しいセキュリティグループを作成します。 - 受信ルールは、Kafka VPCからのすべてのTCPを許可します：タイプ - `{ports of target groups}` （例： `9092-9095` ）、ソース - `{CIDR of TiDB Cloud}` 。リージョン内のTiDB CloudのCIDRを取得するには、 [TiDB Cloudコンソール](https://tidbcloud.com)で組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、**Project view** タブをクリックして対象のプロジェクトを見つけ、そのプロジェクトの をクリックし、**Project Settings** の下にある **Network Access** をクリックしてから、**Project CIDR** > **AWS** をクリックします。 - アウトバウンドルールは、Kafka VPC へのすべての TCP を許可します: タイプ - `All TCP` 、宛先 - `Anywhere-IPv4` - リスナーとルーティング: @@ -711,7 +711,7 @@ b3.usw2-az3.unique_name.aws.plc.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: ### 2. AWSエンドポイントサービスを設定する {#2-set-up-an-aws-endpoint-service} -1. [エンドポイントサービス](https://console.aws.amazon.com/vpcconsole/home#EndpointServices:)に進みます。 **Create endpoint service**をクリックして、Kafka ロード バランサーのプライベート リンク サービスを作成します。 +1. [エンドポイントサービス](https://console.aws.amazon.com/vpcconsole/home#EndpointServices:)に進みます。 **Create endpoint service**をクリックして、Kafka ロードバランサーのプライベートリンクサービスを作成します。 - **Name**: `kafka-pl-service` - **Load balancer type**: `Network` @@ -726,19 +726,19 @@ b3.usw2-az3.unique_name.aws.plc.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: ## ステップ3. TiDB Cloudでプライベートリンク接続を作成する {#step-3-create-a-private-link-connection-in-tidb-cloud} -TiDB Cloudでプライベート リンク接続を作成するには、次の手順を実行します。 +TiDB Cloudでプライベートリンク接続を作成するには、次の手順を実行します。 1. [ステップ2](#2-set-up-an-aws-endpoint-service)で取得した AWS エンドポイントサービス名 (例: `com.amazonaws.vpce..vpce-svc-xxxx` ) を使用して、 TiDB Cloudにプライベートリンク接続を作成します。 詳細については[AWS エンドポイントサービスプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)を参照してください。 -2. TiDB Cloudのデータフロー サービスが Kafka クラスターにアクセスできるように、プライベート リンク接続にドメインをアタッチします。 +2. TiDB Cloudのデータフロー サービスが Kafka クラスターにアクセスできるように、プライベートリンク接続にドメインをアタッチします。 詳細については、 [プライベートリンク接続にドメインを添付する](/tidb-cloud/serverless-private-link-connection.md#attach-domains-to-a-private-link-connection)を参照してください。 **Attach Domains**ダイアログで、ドメインの種類として**TiDB Cloud Managed**を選択し、生成されたドメインの一意の名前を後で使用するためにコピーする必要があることに注意してください。 ## ステップ4. Kafka設定内の一意の名前プレースホルダーを置き換える {#step-4-replace-the-unique-name-placeholder-in-kafka-configuration} -1. Kafka ブローカー ノードに戻り、各ブローカーの`advertised.listeners`構成内の`unique_name`プレースホルダーを、前の手順で取得した実際の一意の名前に置き換えます。 +1. Kafka ブローカーノードに戻り、各ブローカーの`advertised.listeners`構成内の`unique_name`プレースホルダーを、前の手順で取得した実際の一意の名前に置き換えます。 2. すべてのブローカーを再構成したら、Kafka ブローカーを 1 つずつ再起動します。 -これで、このプライベート リンク接続と 9092 をブートストラップ ポートとして使用し、 TiDB Cloudから Kafka クラスターに接続できるようになります。 +これで、このプライベートリンク接続と 9092 をブートストラップ ポートとして使用し、 TiDB Cloudから Kafka クラスターに接続できるようになります。 diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index 96ce789f0dd37..5f235bdcff0a7 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -1,9 +1,9 @@ --- title: Private Link Connections for Dataflow -summary: Dataflow のプライベート リンク接続を設定する方法を学習します。 +summary: Dataflow のプライベートリンク接続を設定する方法を学習します。 --- -# Dataflow のプライベート リンク接続 {#private-link-connections-for-dataflow} +# Dataflow のプライベートリンク接続 {#private-link-connections-for-dataflow} TiDB Cloudの Dataflow サービス（Changefeed や Data Migration (DM) など）は、RDS インスタンスや Kafka クラスターなどの外部リソースへの信頼性の高い接続を必要とします。パブリックエンドポイントもサポートされていますが、プライベートリンク接続は、より高い効率性、より低いレイテンシー、そして強化されたセキュリティを提供する優れた代替手段となります。 @@ -21,13 +21,13 @@ TiDB Cloudの Dataflow サービス（Changefeed や Data Migration (DM) など ### Amazon MSK プロビジョニング {#amazon-msk-provisioned} -このタイプのプライベート リンク接続により、 **AWS**上のTiDB Cloudクラスターがプライベート リンクを使用して[Amazon MSK プロビジョニング](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html)に接続できるようになります。 +このタイプのプライベートリンク接続により、 **AWS**上のTiDB Cloudクラスターがプライベートリンクを使用して[Amazon MSK プロビジョニング](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provisioned.html)に接続できるようになります。 ### Alibaba Cloud エンドポイントサービス {#alibaba-cloud-endpoint-service} -このタイプのプライベート リンク接続により、 **Alibaba Cloud**上のTiDB Cloudクラスターが Alibaba Cloud PrivateLink を搭載した[Alibaba Cloudエンドポイントサービス](https://www.alibabacloud.com/help/en/privatelink/share-your-service/#51976edba8no7)に接続できるようになります。 +このタイプのプライベートリンク接続により、 **Alibaba Cloud**上のTiDB Cloudクラスターが Alibaba Cloud PrivateLink を搭載した[Alibaba Cloudエンドポイントサービス](https://www.alibabacloud.com/help/en/privatelink/share-your-service/#51976edba8no7)に接続できるようになります。 -プライベートリンク接続は、エンドポイント サービスに関連付けることで、RDS インスタンスや Kafka サービスなどのさまざまな Alibaba Cloud サービスにアクセスできます。 +プライベートリンク接続は、エンドポイントサービスに関連付けることで、RDS インスタンスや Kafka サービスなどのさまざまな Alibaba Cloud サービスにアクセスできます。 ## AWS エンドポイントサービスプライベートリンク接続を作成する {#create-an-aws-endpoint-service-private-link-connection} @@ -52,9 +52,9 @@ ticloud serverless private-link-connection zones --cluster-id > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 3. **[AWS Private Endpoints for External Services]**領域で、**Create Private Endpoint for External Services**をクリックします。 @@ -65,19 +65,19 @@ ticloud serverless private-link-connection zones --cluster-id 4. **[外部サービス用プライベートエンドポイントの作成]**ダイアログで、必要な情報を入力します。 - - **Private Link Connection Name**: プライベート リンク接続の名前を入力します。 + - **Private Link Connection Name**: プライベートリンク接続の名前を入力します。 - **Connection Type**： **AWS Endpoint Service**を選択します。このオプションが表示されない場合は、クラスターがAWS上に作成されていることを確認してください。 - - **Endpoint Service Name**: AWS エンドポイント サービス名を入力します (例: `com.amazonaws.vpce..vpce-svc-xxxxxxxxxxxxxxxxx` )。 + - **Endpoint Service Name**: AWS エンドポイントサービス名を入力します (例: `com.amazonaws.vpce..vpce-svc-xxxxxxxxxxxxxxxxx` )。 5. **[作成]**をクリックします。 -6. [AWSコンソール](https://console.aws.amazon.com)のエンドポイント サービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。 +6. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。
    -TiDB Cloud CLI を使用してプライベート リンク接続を作成するには: +TiDB Cloud CLI を使用してプライベートリンク接続を作成するには: 1. 次のコマンドを実行します。 @@ -85,7 +85,7 @@ TiDB Cloud CLI を使用してプライベート リンク接続を作成する ticloud serverless private-link-connection create -c --display-name --type AWS_ENDPOINT_SERVICE --aws.endpoint-service-name ``` -2. [AWSコンソール](https://console.aws.amazon.com)のエンドポイント サービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。 +2. [AWSコンソール](https://console.aws.amazon.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を承認します。
    @@ -100,9 +100,9 @@ Amazon MSK プロビジョニングプライベートリンク接続を作成す > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 3. **[AWS Private Endpoints for External Services]**領域で、**Create Private Endpoint for External Services**をクリックします。 @@ -113,7 +113,7 @@ Amazon MSK プロビジョニングプライベートリンク接続を作成す 4. **[外部サービス用プライベートエンドポイントの作成]**ダイアログで、必要な情報を入力します。 - - **Private Link Connection Name**: プライベート リンク接続の名前を入力します。 + - **Private Link Connection Name**: プライベートリンク接続の名前を入力します。 - **Connection Type**： **Amazon MSK Provisioned**を選択します。このオプションが表示されない場合は、クラスターがAWS上に作成されていることを確認してください。 - **MSK Cluster ARN** : Amazon MSK プロビジョニングされたクラスターの ARN を入力します (例: `arn:aws:kafka:us-east-1:385595570414:cluster//xxxx` )。 @@ -121,9 +121,9 @@ Amazon MSK プロビジョニングプライベートリンク接続を作成す ## Alibaba Cloud Endpoint Service のプライベートリンク接続を作成する {#create-an-alibaba-cloud-endpoint-service-private-link-connection} -TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、Alibaba Cloud Endpoint Service プライベート リンク接続を作成できます。 +TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、Alibaba Cloud Endpoint Service プライベートリンク接続を作成できます。 -Alibaba Cloud エンドポイント サービスが次の条件を満たしていることを確認します。 +Alibaba Cloud エンドポイントサービスが次の条件を満たしていることを確認します。 - TiDB Cloudクラスターと同じリージョンに存在します。 - TiDB Cloudアカウント ID を**Service Whitelist**に追加します。 @@ -142,9 +142,9 @@ ticloud serverless private-link-connection zones --cluster-id > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 3. **[Alibaba Cloud Private Endpoints for External Services]**領域で、**Create Private Endpoint for External Services**をクリックします。 @@ -155,19 +155,19 @@ ticloud serverless private-link-connection zones --cluster-id 4. **[外部サービス用プライベートエンドポイントの作成]**ダイアログで、必要な情報を入力します。 - - **Private Link Connection Name**: プライベート リンク接続の名前を入力します。 + - **Private Link Connection Name**: プライベートリンク接続の名前を入力します。 - **Connection Type**： **Alibaba Cloud Endpoint Service**を選択します。このオプションが表示されない場合は、クラスターがAlibaba Cloud上に作成されていることを確認してください。 - - **Endpoint Service Name**: Alibaba Cloud エンドポイント サービス名を入力します (例: `com.aliyuncs.privatelink..epsrv-xxxxxxxxxxxxxxxxx` )。 + - **Endpoint Service Name**: Alibaba Cloud エンドポイントサービス名を入力します (例: `com.aliyuncs.privatelink..epsrv-xxxxxxxxxxxxxxxxx` )。 5. **[作成]**をクリックします。 -6. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイント サービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。 +6. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。
    -TiDB Cloud CLI を使用してプライベート リンク接続を作成するには: +TiDB Cloud CLI を使用してプライベートリンク接続を作成するには: 1. 次のコマンドを実行します。 @@ -175,7 +175,7 @@ TiDB Cloud CLI を使用してプライベート リンク接続を作成する ticloud serverless private-link-connection create -c --display-name --type ALICLOUD_ENDPOINT_SERVICE --alicloud.endpoint-service-name ``` -2. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイント サービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。 +2. [Alibaba Cloudコンソール](https://console.alibabacloud.com)のエンドポイントサービスの詳細ページに移動します。**Endpoint Connections**タブで、 TiDB Cloudからのエンドポイント接続要求を許可します。
    @@ -194,22 +194,22 @@ TiDB Cloud CLI を使用してプライベート リンク接続を作成する ドメインがこの表に含まれていない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)に連絡してサポートを依頼してください。 -TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、ドメインをプライベート リンク接続に接続できます。 +TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、ドメインをプライベートリンク接続に接続できます。
    -TiDB Cloudコンソールを使用してドメインをプライベート リンク接続に接続するには、次の手順を実行します。 +TiDB Cloudコンソールを使用してドメインをプライベートリンク接続に接続するには、次の手順を実行します。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 -3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベート リンク接続を選択し、 **[...]**をクリックします。 +3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベートリンク接続を選択し、 **[...]**をクリックします。 4. **Attach Domains**をクリックします。 @@ -247,22 +247,22 @@ ticloud serverless private-link-connection attach-domains -c --priv ## プライベートリンク接続からドメインを切断する {#detach-domains-from-a-private-link-connection} -TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、プライベート リンク接続からドメインをデタッチできます。 +TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、プライベートリンク接続からドメインをデタッチできます。
    -TiDB Cloudコンソールを使用してプライベート リンク接続からドメインをデタッチするには、次の手順を実行します。 +TiDB Cloudコンソールを使用してプライベートリンク接続からドメインをデタッチするには、次の手順を実行します。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 -3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベート リンク接続を選択し、 **[...]**をクリックします。 +3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベートリンク接続を選択し、 **[...]**をクリックします。 4. **Detach Domains**をクリックし、切り離しを確認します。 @@ -270,7 +270,7 @@ TiDB Cloudコンソールを使用してプライベート リンク接続から
    -TiDB Cloud CLI を使用してプライベート リンク接続からドメインをデタッチするには、次の手順を実行します。 +TiDB Cloud CLI を使用してプライベートリンク接続からドメインをデタッチするには、次の手順を実行します。 1. プライベートリンク接続の詳細を取得して`attach-domain-id`を見つけます: @@ -289,22 +289,22 @@ TiDB Cloud CLI を使用してプライベート リンク接続からドメイ ## プライベートリンク接続を削除する {#delete-a-private-link-connection} -TiDB CloudコンソールまたはTiDB Cloud CLI を使用してプライベート リンク接続を削除できます。 +TiDB CloudコンソールまたはTiDB Cloud CLI を使用してプライベートリンク接続を削除できます。
    -TiDB Cloudコンソールを使用してプライベート リンク接続を削除するには、次の手順を実行します。 +TiDB Cloudコンソールを使用してプライベートリンク接続を削除するには、次の手順を実行します。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]**をクリックします。 -3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベート リンク接続を選択し、 **[...]**をクリックします。 +3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベートリンク接続を選択し、 **[...]**をクリックします。 4. **[削除]**をクリックし、削除を確認します。 @@ -312,7 +312,7 @@ TiDB Cloudコンソールを使用してプライベート リンク接続を削
    -プライベート リンク接続を削除するには、次のコマンドを実行します。 +プライベートリンク接続を削除するには、次のコマンドを実行します。 ```shell ticloud serverless private-link-connection delete -c --private-link-connection-id diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-azure.md b/tidb-cloud/set-up-private-endpoint-connections-on-azure.md index 943c8fcacc066..c53e3011c4eb6 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-azure.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-azure.md @@ -11,8 +11,8 @@ summary: Azureプライベートリンクを介してTiDB Cloud Dedicatedクラ > **Tip:** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) +> - AWS のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Google Cloud のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) > - プライベートエンドポイントを介してTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、以下のドキュメントを参照してください。 > - [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md) > - [Alibaba Cloudプライベートエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md) @@ -23,8 +23,8 @@ summary: Azureプライベートリンクを介してTiDB Cloud Dedicatedクラ > **Tip:** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) +> - AWS のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Google Cloud のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) > - プライベートエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 @@ -87,8 +87,7 @@ Azure Private Link のアーキテクチャは次のとおりです: [^1] 3. **Private endpoint**ページで、 **+ Create**をクリックします。 4. **基本**タブで、プロジェクトとインスタンスの情報を入力し、 **Next: Resource**をクリックします。 5. **リソース**タブで、**接続方法**として**リソース ID またはエイリアスを使用して Azure リソースに接続する**を選択し、コピーしたTiDB Cloudリソース ID を**Resource ID or alias**フィールドに貼り付けます。 -6. 引き続き**次へ**をクリックして残りの構成タブに進み、必要な設定を完了します。次に、 **[作成]**をクリックしてプライベート エンドポイントを作成してデプロイします。 Azure のデプロイが完了するまでに数秒かかる場合があります。詳細については、Azure ドキュメントの[プライベートエンドポイントを作成する](https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal?tabs=dynamic-ip#create-a-private-endpoint)を参照してください。 -7. プライベートエンドポイントの作成とデプロイが完了したら、 **Go to resource**をクリックし、以下の手順を実行してください。 +6. 引き続き**次へ**をクリックして残りの構成タブに進み、必要な設定を完了します。次に、 **[作成]**をクリックしてプライベートエンドポイントを作成してデプロイします。 Azure のデプロイが完了するまでに数秒かかる場合があります。詳細については、Azure ドキュメントの[プライベートエンドポイントを作成する](https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal?tabs=dynamic-ip#create-a-private-endpoint)を参照してください。7. プライベートエンドポイントの作成とデプロイが完了したら、 **Go to resource**をクリックし、以下の手順を実行してください。 - 左側のナビゲーションペインで**設定** ＞ **プロパティ**をクリックし、後で使用するために**Resource ID**をコピーしてください。 @@ -179,10 +178,10 @@ Azure Private Link のアーキテクチャは次のとおりです: [^1] ### TiDB Cloudでエンドポイントサービスの作成に失敗しました。どうすればよいですか？ {#tidb-cloud-fails-to-create-an-endpoint-service-what-should-i-do} -**Create Azure Private Endpoint**ページを開き、TiDB クラスターを選択すると、エンドポイント サービスは自動的に作成されます。失敗と表示される場合、または**作成中の**状態が長時間続く場合は、サポートに問い合わせて[サポートチケット](/tidb-cloud/tidb-cloud-support.md)を受けてください。 +**Create Azure Private Endpoint**ページを開き、TiDB クラスターを選択すると、エンドポイントサービスは自動的に作成されます。失敗と表示される場合、または**作成中の**状態が長時間続く場合は、サポートに問い合わせて[サポートチケット](/tidb-cloud/tidb-cloud-support.md)を受けてください。 ### セットアップ中にアクションをキャンセルした場合、プライベートエンドポイントを受け入れる前に何をすべきですか？ {#if-i-cancel-the-action-during-setup-what-should-i-do-before-accepting-the-private-endpoint} -Azure プライベート エンドポイント接続機能は、プライベート エンドポイントを自動的に検出できます。つまり、 [Azureプライベートエンドポイントの作成](#step-2-create-an-azure-private-endpoint)Azure ポータルで、 TiDB Cloudコンソールの [ **Azure プライベート エンドポイント接続の作成**] ダイアログで**[キャンセル] を**クリックしても、作成されたエンドポイントを**[ネットワーク]**ページで表示できます。キャンセルが意図的でない場合は、エンドポイントの設定を続行してセットアップを完了できます。キャンセルが意図的な場合は、TiDB Cloudコンソールでエンドポイントを直接削除できます。 +Azure プライベートエンドポイント接続機能は、プライベートエンドポイントを自動的に検出できます。つまり、 [Azureプライベートエンドポイントの作成](#step-2-create-an-azure-private-endpoint)Azure ポータルで、 TiDB Cloudコンソールの [ **Azure プライベートエンドポイント接続の作成**] ダイアログで**[キャンセル] を**クリックしても、作成されたエンドポイントを**[ネットワーク]**ページで表示できます。キャンセルが意図的でない場合は、エンドポイントの設定を続行してセットアップを完了できます。キャンセルが意図的な場合は、TiDB Cloudコンソールでエンドポイントを直接削除できます。 [^1]: Azure Private Linkアーキテクチャの図は、Creative Commons Attribution 4.0 International に基づいてライセンスされている、Azure ドキュメントの「Azureプライベートリンクサービス[Azureプライベートリンクサービスとは何ですか？](https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview)ドキュメント ( [ソースファイルはGitHubにあります](https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/private-link/private-link-service-overview.md)) からのものです。 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..97e2baed6a450 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 @@ -5,14 +5,14 @@ summary: Google Cloud Private Service Connectを使用してTiDB Cloudクラス # Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。 {#connect-to-a-tidb-cloud-dedicated-cluster-via-google-cloud-private-service-connect} -このドキュメントでは[プライベートサービス接続](https://cloud.google.com/vpc/docs/private-service-connect)を介してTiDB Cloud Dedicatedクラスターに接続する方法について説明します。 Google Cloud Private Service Connect は、Google Cloud が提供するプライベート エンドポイント サービスです。 +このドキュメントでは[プライベートサービス接続](https://cloud.google.com/vpc/docs/private-service-connect)を介してTiDB Cloud Dedicatedクラスターに接続する方法について説明します。 Google Cloud Private Service Connect は、Google Cloud が提供するプライベートエンドポイントサービスです。 > **Tip:** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 +> - AWS のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Azure のプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 > - プライベートエンドポイントを介してTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、以下のドキュメントを参照してください。 > - [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md) > - [Alibaba Cloudプライベートエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md) @@ -23,8 +23,8 @@ summary: Google Cloud Private Service Connectを使用してTiDB Cloudクラス > **Tip:** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 +> - AWS のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Azure のプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 > - プライベートエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 @@ -55,7 +55,7 @@ Google Cloud Private Service Connect のアーキテクチャは以下のとお - `/17` : 地域ごとに最大 119 の PSC 接続 - `/16` : 地域ごとに最大 247 の PSC 接続 - 接続するプライベートエンドポイントとTiDBクラスタは、同じリージョンに配置されている必要があります。 -- 送信ファイアウォール ルールでは、エンドポイントの内部 IP アドレスへのトラフィックを許可する必要があります。 [暗黙の送信許可ファイアウォールルール](https://cloud.google.com/firewall/docs/firewalls#default_firewall_rules)任意の宛先 IP アドレスへの送信を許可します。 +- 送信ファイアウォールルールでは、エンドポイントの内部 IP アドレスへのトラフィックを許可する必要があります。 [暗黙の送信許可ファイアウォールルール](https://cloud.google.com/firewall/docs/firewalls#default_firewall_rules)任意の宛先 IP アドレスへの送信を許可します。 - VPCネットワークで送信拒否ファイアウォールルールを作成している場合、または暗黙的に許可される送信動作を変更する階層型ファイアウォールポリシーを作成している場合、エンドポイントへのアクセスに影響が出る可能性があります。この場合、エンドポイントの内部宛先IPアドレスへのトラフィックを許可する、特定の送信許可ファイアウォールルールまたはポリシーを作成する必要があります。 ほとんどのシナリオでは、VPCピアリングよりもプライベートエンドポイント接続を使用することをお勧めします。ただし、以下のシナリオでは、プライベートエンドポイント接続の代わりにVPCピアリングを使用する必要があります。 @@ -158,7 +158,7 @@ Google Cloudでエンドポイントを正常に作成したら、 TiDB Cloudコ ### プライベートエンドポイントの状態参照 {#private-endpoint-status-reference} -プライベート エンドポイント接続を使用すると、プライベート エンドポイントまたはプライベート エンドポイント サービスのステータスが[**Private Endpoint**ページ](#prerequisites)ページに表示されます。 +プライベートエンドポイント接続を使用すると、プライベートエンドポイントまたはプライベートエンドポイントサービスのステータスが[**Private Endpoint**ページ](#prerequisites)ページに表示されます。 プライベートエンドポイントの可能なステータスは、以下のように説明されます。 @@ -176,7 +176,7 @@ Google Cloudでエンドポイントを正常に作成したら、 TiDB Cloudコ ### TiDB Cloudでエンドポイントサービスの作成に失敗しました。どうすればよいですか？ {#tidb-cloud-fails-to-create-an-endpoint-service-what-should-i-do} -エンドポイント サービスは、 **[Google Cloud Private エンドポイント接続の作成**] ページを開いて TiDB クラスターを選択すると自動的に作成されます。作成が失敗と表示される場合、または[サポートチケット](/tidb-cloud/tidb-cloud-support.md)**作成中] の**状態が長時間続く場合は、サポートに問い合わせてください。 +エンドポイントサービスは、 **[Google Cloud Private エンドポイント接続の作成**] ページを開いて TiDB クラスターを選択すると自動的に作成されます。作成が失敗と表示される場合、または[サポートチケット](/tidb-cloud/tidb-cloud-support.md)**作成中] の**状態が長時間続く場合は、サポートに問い合わせてください。 ### Google Cloudでエンドポイントを作成できませんでした。どうすればよいですか？ {#fail-to-create-an-endpoint-in-google-cloud-what-should-i-do} @@ -186,7 +186,7 @@ Google Cloudでエンドポイントを正常に作成したら、 TiDB Cloudコ キャンセルされたアクションの未保存の下書きは保持も表示もされません。次回TiDB Cloudコンソールで新しいプライベートエンドポイントを作成する際は、各手順を繰り返す必要があります。 -Google Cloud Shell でプライベート エンドポイントを作成するコマンドをすでに実行している場合は、Google Cloud コンソールで手動で[対応するエンドポイントを削除します](https://cloud.google.com/vpc/docs/configure-private-service-connect-services#delete-endpoint)必要があります。 +Google Cloud Shell でプライベートエンドポイントを作成するコマンドをすでに実行している場合は、Google Cloud コンソールで手動で[対応するエンドポイントを削除します](https://cloud.google.com/vpc/docs/configure-private-service-connect-services#delete-endpoint)必要があります。 ### TiDB Cloudコンソールで、サービス添付ファイルを直接コピーして生成されたエンドポイントが表示されないのはなぜですか？ {#why-can-t-i-see-the-endpoints-generated-by-directly-copying-the-service-attachment-in-the-tidb-cloud-console} diff --git a/tidb-cloud/set-up-private-endpoint-connections-serverless.md b/tidb-cloud/set-up-private-endpoint-connections-serverless.md index 791038e155f11..7171664af5526 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-serverless.md +++ b/tidb-cloud/set-up-private-endpoint-connections-serverless.md @@ -9,9 +9,9 @@ summary: プライベートエンドポイントを介してTiDB Cloud Starter > **Tip:** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 +> - AWS のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Azure のプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 +> - Google Cloud のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 TiDB Cloudは、 AWS VPC内でホストされているTiDB Cloudサービスへの[AWSプライベートリンク](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc)を介した高度に安全な一方向アクセスをサポートしています。まるでサービスがお客様自身のVPC内にあるかのように動作します。お客様のVPC内にプライベートエンドポイントが公開され、権限があればそのエンドポイントを介してTiDB Cloudサービスへの接続を作成できます。 @@ -311,6 +311,6 @@ AWS Management Console でプライベートDNSを有効にするには、次の ### プライベートDNSを有効にした後、プライベートエンドポイント経由でTiDB Cloud StarterまたはEssentialインスタンスに接続できません。なぜでしょうか？ {#i-cannot-connect-to-a-tidb-cloud-starter-or-essential-instance-via-a-private-endpoint-after-enabling-private-dns-why} -AWS マネジメント コンソールで**、** VPC エンドポイントのセキュリティ グループを適切に設定する必要がある場合があります。VPC >**エンドポイント**に移動します。VPC エンドポイントを右クリックし、適切な**Manage security groups**を選択します。VPC 内に、EC2 インスタンスからのポート 4000 またはお客様定義のポートへの受信アクセスを許可する適切なセキュリティ グループを設定します。 +AWS マネジメントコンソールで**、** VPC エンドポイントのセキュリティグループを適切に設定する必要がある場合があります。VPC >**エンドポイント**に移動します。VPC エンドポイントを右クリックし、適切な**Manage security groups**を選択します。VPC 内に、EC2 インスタンスからのポート 4000 またはお客様定義のポートへの受信アクセスを許可する適切なセキュリティグループを設定します。 ![Manage security groups](/media/tidb-cloud/private-endpoint/manage-security-groups.png) diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index 2aefba577a072..f5d5a09b507ba 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -10,14 +10,14 @@ summary: AWS を使用してプライベートエンドポイント経由でTiDB > **Tip:** > > - AWS PrivateLink 経由でTiDB Cloud Starter またはTiDB Cloud Essential クラスターに接続する方法については、 [AWS PrivateLink 経由でTiDB Cloud Starter または Essential に接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 -> - Azure のプライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続する方法については、 [Azure Private Link 経由でTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicated クラスタに接続する方法については、 [Google Cloud Private Service Connect 経由でTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)ご覧ください。 +> - Azure のプライベートエンドポイント経由でTiDB Cloud Dedicated クラスターに接続する方法については、 [Azure Private Link 経由でTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)を参照してください。 +> - Google Cloud のプライベートエンドポイント経由でTiDB Cloud Dedicated クラスタに接続する方法については、 [Google Cloud Private Service Connect 経由でTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)ご覧ください。 TiDB Cloudは、 AWS VPCでホストされているTiDB Cloudサービスへの、 [AWS プライベートリンク](https://aws.amazon.com/privatelink)経由の高度に安全な一方向アクセスをサポートします。まるでお客様のVPC内にあるかのように機能します。VPC内にプライベートエンドポイントが公開されており、権限があればエンドポイント経由でTiDB Cloudサービスへの接続を作成できます。 AWS PrivateLink を利用することで、エンドポイント接続は安全かつプライベートであり、データがパブリックインターネットに公開されることはありません。さらに、エンドポイント接続は CIDR オーバーラップをサポートし、ネットワーク管理が容易になります。 -プライベート エンドポイントのアーキテクチャは次のとおりです。 +プライベートエンドポイントのアーキテクチャは次のとおりです。 ![Private endpoint architecture](/media/tidb-cloud/aws-private-endpoint-arch.png) @@ -28,13 +28,13 @@ AWS PrivateLink を利用することで、エンドポイント接続は安全 ## 制限 {#restrictions} -- プライベート エンドポイントを作成できるのは、ロール`Organization Owner`または`Project Owner`持つユーザーのみです。 -- プライベート エンドポイントと接続先の TiDB クラスターは同じリージョンに配置されている必要があります。 +- プライベートエンドポイントを作成できるのは、ロール`Organization Owner`または`Project Owner`持つユーザーのみです。 +- プライベートエンドポイントと接続先の TiDB クラスターは同じリージョンに配置されている必要があります。 ほとんどのシナリオでは、VPC ピアリングではなくプライベートエンドポイント接続を使用することをお勧めします。ただし、以下のシナリオでは、プライベートエンドポイント接続ではなく VPC ピアリングを使用する必要があります。 - 高可用性を実現するために、ソースTiDBクラスターからターゲットTiDBクラスターへリージョンをまたいでデータをレプリケートするために、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)クラスターを使用しています。現在、プライベートエンドポイントはリージョン間接続をサポートしていません。 -- TiCDC クラスターを使用してダウンストリーム クラスター (Amazon Aurora、MySQL、Kafka など) にデータをレプリケートしていますが、エンドポイント サービスを独自に維持することはできません。 +- TiCDC クラスターを使用してダウンストリームクラスター (Amazon Aurora、MySQL、Kafka など) にデータをレプリケートしていますが、エンドポイントサービスを独自に維持することはできません。 - PD または TiKV ノードに直接接続しています。 ## 前提条件 {#prerequisites} @@ -43,7 +43,7 @@ AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっている ## プライベートエンドポイント接続を設定し、クラスターに接続する {#set-up-a-private-endpoint-connection-and-connect-to-your-cluster} -プライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続するには、次の手順を実行します。 +プライベートエンドポイント経由でTiDB Cloud Dedicated クラスターに接続するには、次の手順を実行します。 1. [TiDBクラスタを選択](#step-1-select-a-tidb-cluster) 2. [AWSインターフェースエンドポイントを作成する](#step-2-create-an-aws-interface-endpoint) @@ -57,7 +57,7 @@ AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっている 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、概要ページに移動します。 2. 右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 -3. **Connection Type**ドロップダウン リストで**Private Endpoint**を選択し、 **Create Private Endpoint Connection**をクリックします。 +3. **Connection Type**ドロップダウンリストで**Private Endpoint**を選択し、 **Create Private Endpoint Connection**をクリックします。 > **Note:** > @@ -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`メッセージが表示された場合、対応するエンドポイントサービスは準備完了です。エンドポイントを作成するには、以下の情報を提供してください。 @@ -101,7 +101,7 @@ AWS マネジメントコンソールを使用して VPC インターフェイ 1. [AWS マネジメントコンソール](https://aws.amazon.com/console/)にサインインし、 [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)で Amazon VPC コンソールを開きます。 -2. ナビゲーション ペインで**Endpoints**をクリックし、右上隅の**Create Endpoint**をクリックします。 +2. ナビゲーションペインで**Endpoints**をクリックし、右上隅の**Create Endpoint**をクリックします。 **Create endpoint**ページが表示されます。 @@ -121,11 +121,11 @@ AWS マネジメントコンソールを使用して VPC インターフェイ > > サービスが3つを超えるアベイラビリティゾーン（AZ）にまたがっている場合、 **Subnets**エリアでAZを選択できない場合があります。この問題は、選択したリージョンに、TiDBクラスターが配置されているAZに加えて、追加のAZが存在する場合に発生します。その場合は、 [PingCAP テクニカルサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)お問い合わせください。 -8. **Security groups**領域で、セキュリティ グループを適切に選択します。 +8. **Security groups**領域で、セキュリティグループを適切に選択します。 > **Note:** > - > 選択したセキュリティ グループが、ポート`4000`または顧客定義のポート上の EC2 インスタンスからのインバウンド アクセスを許可していることを確認します。 + > 選択したセキュリティグループが、ポート`4000`または顧客定義のポート上の EC2 インスタンスからのインバウンド アクセスを許可していることを確認します。 9. **Create endpoint**をクリックします。 @@ -140,10 +140,10 @@ 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** をクリックします。 +> - クラスターレベルの**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** をクリックします。 ### ステップ4. プライベートDNSを有効にする {#step-4-enable-private-dns} @@ -177,9 +177,9 @@ AWS マネジメントコンソールでプライベート DNS を有効にす ### ステップ5. TiDBクラスターに接続する {#step-5-connect-to-your-tidb-cluster} -プライベート エンドポイント接続を承認すると、接続ダイアログにリダイレクトされます。 +プライベートエンドポイント接続を承認すると、接続ダイアログにリダイレクトされます。 -1. プライベート エンドポイントの接続ステータスが**System Checking**から**Active**に変わるまで待ちます (約 5 分)。 +1. プライベートエンドポイントの接続ステータスが**System Checking**から**Active**に変わるまで待ちます (約 5 分)。 2. **Connect With**ドロップダウンリストで、希望する接続方法を選択します。対応する接続文字列がダイアログの下部に表示されます。 3. 接続文字列を使用してクラスターに接続します。 @@ -189,24 +189,24 @@ AWS マネジメントコンソールでプライベート DNS を有効にす ### プライベートエンドポイントのステータスリファレンス {#private-endpoint-status-reference} -プライベート エンドポイント接続を使用すると、プライベート エンドポイントとプライベート エンドポイント サービスの状態が次のページに表示されます。 +プライベートエンドポイント接続を使用すると、プライベートエンドポイントとプライベートエンドポイントサービスの状態が次のページに表示されます。 -- クラスター レベルの**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** をクリックします。 +- クラスターレベルの**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** をクリックします。 -プライベート エンドポイントの可能なステータスについては、次のように説明されます。 +プライベートエンドポイントの可能なステータスについては、次のように説明されます。 -- **Not Configured**: エンドポイント サービスは作成されていますが、プライベート エンドポイントはまだ作成されていません。 +- **Not Configured**: エンドポイントサービスは作成されていますが、プライベートエンドポイントはまだ作成されていません。 - **Pending**: 処理を待機中です。 - **Active**：プライベートエンドポイントは使用可能です。このステータスのプライベートエンドポイントは編集できません。 -- **Deleting**: プライベート エンドポイントを削除しています。 +- **Deleting**: プライベートエンドポイントを削除しています。 - **Failed**: プライベートエンドポイントの作成に失敗しました。その行の**Edit**をクリックすると、作成を再試行できます。 -プライベート エンドポイント サービスの可能なステータスについては、次のように説明されます。 +プライベートエンドポイントサービスの可能なステータスについては、次のように説明されます。 -- **Creating**: エンドポイント サービスを作成中です。これには 3 ～ 5 分かかります。 -- **Active**: プライベート エンドポイントが作成されたかどうかに関係なく、エンドポイント サービスが作成されます。 -- **Deleting**: エンドポイント サービスまたはクラスターを削除中です。これには 3 ～ 5 分かかります。 +- **Creating**: エンドポイントサービスを作成中です。これには 3 ～ 5 分かかります。 +- **Active**: プライベートエンドポイントが作成されたかどうかに関係なく、エンドポイントサービスが作成されます。 +- **Deleting**: エンドポイントサービスまたはクラスターを削除中です。これには 3 ～ 5 分かかります。 ## トラブルシューティング {#troubleshooting} diff --git a/tidb-cloud/set-up-sink-private-endpoint.md b/tidb-cloud/set-up-sink-private-endpoint.md index e21b458133aab..64dec0da3b62a 100644 --- a/tidb-cloud/set-up-sink-private-endpoint.md +++ b/tidb-cloud/set-up-sink-private-endpoint.md @@ -1,11 +1,11 @@ --- title: Set Up Private Endpoint for Changefeeds -summary: 変更フィードのプライベート エンドポイントを設定する方法を学習します。 +summary: 変更フィードのプライベートエンドポイントを設定する方法を学習します。 --- -# Changefeeds のプライベート エンドポイントを設定する {#set-up-private-endpoint-for-changefeeds} +# Changefeeds のプライベートエンドポイントを設定する {#set-up-private-endpoint-for-changefeeds} -このドキュメントでは、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで変更フィード用のプライベート エンドポイントを作成し、プライベート接続を介してセルフホスト型 Kafka または MySQL にデータを安全にストリーミングできるようにする方法について説明します。 +このドキュメントでは、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで変更フィード用のプライベートエンドポイントを作成し、プライベート接続を介してセルフホスト型 Kafka または MySQL にデータを安全にストリーミングできるようにする方法について説明します。 ## 制限 {#restrictions} @@ -18,7 +18,7 @@ summary: 変更フィードのプライベート エンドポイントを設定 ### 権限 {#permissions} -組織内で次のいずれかのロールを持つユーザーのみが、変更フィードのプライベート エンドポイントを作成できます。 +組織内で次のいずれかのロールを持つユーザーのみが、変更フィードのプライベートエンドポイントを作成できます。 - `Organization Owner` - `Project Owner` @@ -28,17 +28,17 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb- ### ネットワーク {#network} -プライベート エンドポイントは、クラウド プロバイダーの**Private Link**または**Private Service Connect**テクノロジーを活用し、VPC 内のリソースが、あたかもそれらのサービスが VPC 内で直接ホストされているかのように、プライベート IP アドレスを介して他の VPC 内のサービスに接続できるようにします。 +プライベートエンドポイントは、クラウドプロバイダーの**Private Link**または**Private Service Connect**テクノロジーを活用し、VPC 内のリソースが、あたかもそれらのサービスが VPC 内で直接ホストされているかのように、プライベート IP アドレスを介して他の VPC 内のサービスに接続できるようにします。
    changefeed ダウンストリーム サービスが AWS でホストされている場合は、次の情報を収集します。 -- ダウンストリーム サービスのプライベート エンドポイント サービスの名前 -- ダウンストリーム サービスがデプロイされているアベイラビリティ ゾーン (AZ) +- ダウンストリーム サービスのプライベートエンドポイントサービスの名前 +- ダウンストリーム サービスがデプロイされているアベイラビリティゾーン (AZ) -ダウンストリーム サービスでプライベート エンドポイント サービスが利用できない場合は、手順[ステップ 2. Kafka クラスターをプライベート リンク サービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)に従ってロード バランサーとプライベート リンク サービスを設定します。 +ダウンストリーム サービスでプライベートエンドポイントサービスが利用できない場合は、手順[ステップ 2. Kafka クラスターをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)に従ってロードバランサーとプライベートリンクサービスを設定します。
    @@ -52,9 +52,9 @@ changefeed ダウンストリーム サービスが Google Cloud でホストさ
    -changefeed ダウンストリーム サービスが Azure でホストされている場合は、ダウンストリーム サービスのプライベート リンク サービスのエイリアスを収集します。 +changefeed ダウンストリーム サービスが Azure でホストされている場合は、ダウンストリーム サービスのプライベートリンクサービスのエイリアスを収集します。 -ダウンストリーム サービスでプライベート エンドポイント サービスが利用できない場合は、手順[ステップ 2. Kafka クラスターをプライベート リンク サービスとして公開する](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)に従ってロード バランサーとプライベート リンク サービスを設定します。 +ダウンストリーム サービスでプライベートエンドポイントサービスが利用できない場合は、手順[ステップ 2. Kafka クラスターをプライベートリンクサービスとして公開する](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)に従ってロードバランサーとプライベートリンクサービスを設定します。
    @@ -63,39 +63,37 @@ changefeed ダウンストリーム サービスが Azure でホストされて 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインします。 -2. [**クラスター**](https://tidbcloud.com/project/clusters)ページで、ターゲット クラスターの名前をクリックして、概要ページに移動します。 +2. [**クラスター**](https://tidbcloud.com/project/clusters)ページで、ターゲットクラスターの名前をクリックして、概要ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -3. 左側のナビゲーション ペインで、 **[設定]** > **[ネットワーク] を**クリックします。 +3. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク] を**クリックします。 ## ステップ2. 変更フィードのプライベートエンドポイントを構成する {#step-2-configure-the-private-endpoint-for-changefeeds} -構成手順は、クラスターがデプロイされているクラウド プロバイダーによって異なります。 +構成手順は、クラスターがデプロイされているクラウドプロバイダーによって異なります。
    1. **[ネットワーキング]**ページで、 **[外部サービス用 AWS プライベートエンドポイント]**セクションの**[外部サービス用プライベートエンドポイントの作成]**をクリックします。 -2. **外部サービス用プライベート エンドポイントの作成**ダイアログで、プライベート エンドポイントの名前を入力します。 - +2. **外部サービス用プライベートエンドポイントの作成**ダイアログで、プライベートエンドポイントの名前を入力します。 3. リマインダーに従って、 TiDB Cloudの[AWS プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-accounts)にエンドポイントの作成を承認します。 4. セクション[ネットワーク](#network)で収集した**Endpoint Service Name**を入力します。 5. **Number of AZs**を選択します。AZ の数と AZ ID が Kafka のデプロイメントと一致していることを確認してください。 -6. このプライベート エンドポイントが Apache Kafka 用に作成される場合は、 **Kafka 用のアドバタイズドリスナーを構成する**チェックボックスを選択します。 +6. このプライベートエンドポイントが Apache Kafka 用に作成される場合は、 **Kafka 用のアドバタイズドリスナーを構成する**チェックボックスを選択します。 7. **TiDB Managed**ドメインまたは**カスタム**ドメインのいずれかを使用して、Kafka のアドバタイズされたリスナーを構成します。 - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **生成**をクリックします。TiDB は、各アベイラビリティゾーンのサブドメインを持つブローカーアドレスを生成します。 - - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメイン タイプを**[カスタム]**に切り替え、 **Custom Domain**フィールドにルート ドメインを入力し、[**チェック]**をクリックして、各アベイラビリティー ゾーンのブローカー サブドメインを指定します。 - -8. **[作成]**をクリックして構成を検証し、プライベート エンドポイントを作成します。 + - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメイン タイプを**[カスタム]**に切り替え、 **Custom Domain**フィールドにルート ドメインを入力し、[**チェック]**をクリックして、各アベイラビリティーゾーンのブローカー サブドメインを指定します。 +8. **[作成]**をクリックして構成を検証し、プライベートエンドポイントを作成します。
    @@ -103,20 +101,18 @@ changefeed ダウンストリーム サービスが Azure でホストされて 1. **[ネットワーキング]**ページで、 **[外部サービス用 Google Cloud プライベートエンドポイント]**セクションの**[外部サービス用プライベートエンドポイントの作成]**をクリックします。 -2. **外部サービス用プライベート エンドポイントの作成**ダイアログで、プライベート エンドポイントの名前を入力します。 - +2. **外部サービス用プライベートエンドポイントの作成**ダイアログで、プライベートエンドポイントの名前を入力します。 3. リマインダーに従って、 TiDB Cloudの[Google Cloud プロジェクト](https://cloud.google.com/resource-manager/docs/creating-managing-projects)にエンドポイントの作成を事前承認するよう許可するか、エンドポイント接続要求を受け取ったら手動で承認します。 4. セクション[ネットワーク](#network)で収集した**Service Attachment**を入力します。 -5. このプライベート エンドポイントが Apache Kafka 用に作成される場合は、 **Kafka 用のアドバタイズドリスナーを構成する**チェックボックスを選択します。 +5. このプライベートエンドポイントが Apache Kafka 用に作成される場合は、 **Kafka 用のアドバタイズドリスナーを構成する**チェックボックスを選択します。 6. **TiDB Managed**ドメインまたは**カスタム**ドメインのいずれかを使用して、Kafka のアドバタイズされたリスナーを構成します。 - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **生成**をクリックします。TiDB は、各アベイラビリティゾーンのサブドメインを持つブローカーアドレスを生成します。 - - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメイン タイプを**[カスタム]**に切り替え、 **Custom Domain**フィールドにルート ドメインを入力し、[**チェック]**をクリックして、各アベイラビリティー ゾーンのブローカー サブドメインを指定します。 - -7. **[作成]**をクリックして構成を検証し、プライベート エンドポイントを作成します。 + - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメイン タイプを**[カスタム]**に切り替え、 **Custom Domain**フィールドにルート ドメインを入力し、[**チェック]**をクリックして、各アベイラビリティーゾーンのブローカー サブドメインを指定します。 +7. **[作成]**をクリックして構成を検証し、プライベートエンドポイントを作成します。
    @@ -124,20 +120,18 @@ changefeed ダウンストリーム サービスが Azure でホストされて 1. **[ネットワーク]**ページで、 **[外部サービス用 Azure プライベートエンドポイント]**セクションの**[外部サービス用プライベートエンドポイントの作成]**をクリックします。 -2. **外部サービス用プライベート エンドポイントの作成**ダイアログで、プライベート エンドポイントの名前を入力します。 - +2. **外部サービス用プライベートエンドポイントの作成**ダイアログで、プライベートエンドポイントの名前を入力します。 3. 変更フィードを作成する前に、リマインダーに従って、 TiDB Cloudの Azure サブスクリプションを承認するか、エイリアスを持つすべてのユーザーが Private Link サービスにアクセスできるようにしてください。Private Link サービスの可視性に関する詳細については、Azure ドキュメントの[制御サービスの公開](https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview#control-service-exposure)を参照してください。 -4. セクション[ネットワーク](#network)で収集した**プライベート リンク サービスのエイリアス**を入力します。 +4. セクション[ネットワーク](#network)で収集した**プライベートリンクサービスのエイリアス**を入力します。 -5. このプライベート エンドポイントが Apache Kafka 用に作成される場合は、 **Kafka 用のアドバタイズドリスナーを構成する**チェックボックスを選択します。 +5. このプライベートエンドポイントが Apache Kafka 用に作成される場合は、 **Kafka 用のアドバタイズドリスナーを構成する**チェックボックスを選択します。 6. **TiDB Managed**ドメインまたは**カスタム**ドメインのいずれかを使用して、Kafka のアドバタイズされたリスナーを構成します。 - アドバタイズされたリスナーに**TiDB Managed**ドメインを使用するには、 **Domain Pattern**フィールドに一意の文字列を入力し、 **生成**をクリックします。TiDB は、各アベイラビリティゾーンのサブドメインを持つブローカーアドレスを生成します。 - - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメイン タイプを**[カスタム]**に切り替え、 **Custom Domain**フィールドにルート ドメインを入力し、[**チェック]**をクリックして、各アベイラビリティー ゾーンのブローカー サブドメインを指定します。 - -7. **[作成]**をクリックして構成を検証し、プライベート エンドポイントを作成します。 + - アドバタイズされたリスナーに独自の**カスタム**ドメインを使用するには、ドメイン タイプを**[カスタム]**に切り替え、 **Custom Domain**フィールドにルート ドメインを入力し、[**チェック]**をクリックして、各アベイラビリティーゾーンのブローカー サブドメインを指定します。 +7. **[作成]**をクリックして構成を検証し、プライベートエンドポイントを作成します。
    diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index f1ef56d0c832a..517c94dfabffb 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -27,11 +27,11 @@ VPCピアリングリクエストをリージョンに追加するには、そ 最初のTiDB Cloud Dedicatedクラスタを作成する際にCIDRを設定できます。クラスタ作成前にCIDRを設定する場合は、以下の操作を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用してターゲット プロジェクトに切り替えます。 -2. 左側のナビゲーション ペインで、 **Project Settings** > **Network Access**をクリックします。 +2. 左側のナビゲーションペインで、 **Project Settings** > **Network Access**をクリックします。 -3. **Network Access**ページで、 **Project CIDR**タブをクリックし、クラウド プロバイダーに応じて**AWS**または**Google Cloud**を選択します。 +3. **Network Access**ページで、 **Project CIDR**タブをクリックし、クラウドプロバイダーに応じて**AWS**または**Google Cloud**を選択します。 4. 右上隅の**Create CIDR**をクリックします。 **Create AWS CIDR**または**Create Google Cloud CIDR**ダイアログでリージョンと CIDR 値を指定し、 **Confirm**をクリックします。 @@ -44,13 +44,13 @@ VPCピアリングリクエストをリージョンに追加するには、そ > - 10.250.0.0 - 10.251.255.255 > - 172.16.0.0 - 172.31.255.255 > - 192.168.0.0 - 192.168.255.255 - > - Google Cloudリージョンでは、IP 範囲のサイズを`/19`から`/20`の間で設定することをお勧めします。サポートされているネットワーク アドレスは次のとおりです。 + > - Google Cloudリージョンでは、IP 範囲のサイズを`/19`から`/20`の間で設定することをお勧めします。サポートされているネットワークアドレスは次のとおりです。 > - 10.250.0.0 - 10.251.255.255 > - 172.16.0.0 - 172.17.255.255 > - 172.30.0.0 - 172.31.255.255 > - TiDB Cloud は、リージョンの CIDR ブロック サイズに基づいて、プロジェクトのリージョン内のTiDB Cloudノードの数を制限します。 -5. クラウド プロバイダーと特定のリージョンの CIDR を確認する。 +5. クラウドプロバイダーと特定のリージョンの CIDR を確認する。 CIDRはデフォルトで無効になっています。CIDRを有効にするには、対象リージョンにクラスターを作成する必要があります。リージョンのCIDRが有効な場合は、そのリージョンにVPCピアリングを作成できます。 @@ -62,14 +62,14 @@ VPCピアリングリクエストをリージョンに追加するには、そ ### ステップ1. VPCピアリングリクエストを追加する {#step-1-add-vpc-peering-requests} -VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクト レベルの **Network Access**ページまたはクラスタ レベルの**Networking**ページのいずれかで追加できます。 +VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクトレベルの **Network Access**ページまたはクラスタ レベルの**Networking**ページのいずれかで追加できます。
    -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用してターゲット プロジェクトに切り替えます。 -2. 左側のナビゲーション ペインで、 **Project Settings** > **Network Access**をクリックします。 +2. 左側のナビゲーションペインで、 **Project Settings** > **Network Access**をクリックします。 3. **Network Access**ページで、 **VPC Peering**タブをクリックし、 **AWS**サブタブをクリックします。 @@ -93,17 +93,17 @@ VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジ
    -1. ターゲット クラスターの概要ページを開きます。 +1. ターゲットクラスターの概要ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 - 2. ターゲット クラスターの名前をクリックすると、概要ページに移動します。 + 2. ターゲットクラスターの名前をクリックすると、概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 3. **Networking**ページで**Create VPC Peering**をクリックし、既存の AWS VPC の必要な情報を入力します。 @@ -211,7 +211,7 @@ AWS ダッシュボードを使用して VPC ピアリング接続を構成す 2. 各 VPC サブネット ルート テーブルに対して、 TiDB Cloud VPC へのルートを追加します。 - 1. 左側のナビゲーション バーから、**Route Tables**ページを開きます。 + 1. 左側のナビゲーションバーから、**Route Tables**ページを開きます。 2. アプリケーション VPC に属するすべてのルートテーブルを検索します。 @@ -223,7 +223,7 @@ AWS ダッシュボードを使用して VPC ピアリング接続を構成す 3. VPC でプライベート DNS ホストゾーンのサポートが有効になっていることを確認してください。 - 1. 左側のナビゲーション バーから、 **Your VPCs**ページを開きます。 + 1. 左側のナビゲーションバーから、 **Your VPCs**ページを開きます。 2. アプリケーション VPC を選択します。 @@ -242,14 +242,14 @@ AWS ダッシュボードを使用して VPC ピアリング接続を構成す ### ステップ1. VPCピアリングリクエストを追加する {#step-1-add-vpc-peering-requests} -VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクト レベルの **Network Access**ページまたはクラスタ レベルの**Networking**ページのいずれかで追加できます。 +VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクトレベルの **Network Access**ページまたはクラスタ レベルの**Networking**ページのいずれかで追加できます。
    -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用してターゲット プロジェクトに切り替えます。 -2. 左側のナビゲーション ペインで、 **Project Settings** > **Network Access**をクリックします。 +2. 左側のナビゲーションペインで、 **Project Settings** > **Network Access**をクリックします。 3. **Network Access**ページで、 **VPC Peering**タブをクリックし、 **Google Cloud**サブタブをクリックします。 @@ -272,17 +272,17 @@ VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジ
    -1. ターゲット クラスターの概要ページを開きます。 +1. ターゲットクラスターの概要ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 - 2. ターゲット クラスターの名前をクリックすると、概要ページに移動します。 + 2. ターゲットクラスターの名前をクリックすると、概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 3. **Networking**ページで**Create VPC Peering**をクリックし、既存の Google Cloud VPC の必要な情報を入力します。 @@ -317,9 +317,9 @@ gcloud beta compute networks peerings create --project @@ -58,7 +57,7 @@ aliases: ['/ja/tidbcloud/setup-self-hosted-kafka-private-link-service'] - EC2ノードを管理する - VPCを管理する - サブネットを管理する - - セキュリティ グループを管理する + - セキュリティグループを管理する - ロードバランサーの管理 - エンドポイントサービスの管理 - EC2 ノードに接続して Kafka ノードを構成する @@ -67,7 +66,7 @@ aliases: ['/ja/tidbcloud/setup-self-hosted-kafka-private-link-service'] 3. TiDB Cloud Premium インスタンスから Kafka デプロイメント情報を取得します。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB インスタンスのインスタンス概要ページに移動し、左側のナビゲーション ペインで**Data** > **Changefeed**をクリックします。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、TiDB インスタンスのインスタンス概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。 2. 概要ページで、TiDBインスタンスのリージョンを確認します。Kafkaクラスターが同じリージョンにデプロイされることを確認してください。 3. チェンジフィードを作成するには、チュートリアルを参照してください。 @@ -98,7 +97,7 @@ aliases: ['/ja/tidbcloud/setup-self-hosted-kafka-private-link-service'] Kafka VPC には次のものが必要です。 -- ブローカー用のプライベート サブネットが 3 つ (AZ ごとに 1 つ)。 +- ブローカー用のプライベートサブネットが 3 つ (AZ ごとに 1 つ)。 - 任意の AZ に 1 つのパブリックサブネットがあり、インターネットに接続できる要塞ノードと 3 つのプライベートサブネットがあるため、Kafka クラスターを簡単にセットアップできます。本番環境では、Kafka VPC に接続できる独自の要塞ノードが必要になる場合があります。 サブネットを作成する前に、AZ IDとAZ名のマッピングに基づいてAZ内にサブネットを作成します。以下のマッピングを例に挙げます。 @@ -107,7 +106,7 @@ Kafka VPC には次のものが必要です。 - `usw2-az2` => `us-west-2c` - `usw2-az3` => `us-west-2b` -次の AZ にプライベート サブネットを作成します。 +次の AZ にプライベートサブネットを作成します。 - `us-west-2a` - `us-west-2c` @@ -160,12 +159,12 @@ Kafka VPC を作成するには、次の手順を実行します。 2. 前にメモしておいた**VPC ID** (この例では`vpc-01f50b790fa01dffa` ) を選択します。 -3. 次の情報を使用して、任意の AZ にパブリック サブネットを追加します。 +3. 次の情報を使用して、任意の AZ にパブリックサブネットを追加します。 - **Subnet name**: `bastion` - **IPv4 subnet CIDR block**： `10.0.192.0/18` -4. 要塞サブネットをパブリック サブネットに構成します。 +4. 要塞サブネットをパブリックサブネットに構成します。 1. [VPCダッシュボード > インターネットゲートウェイ](https://console.aws.amazon.com/vpcconsole/home#igws:)に進みます。`kafka-vpc-igw`名前のインターネットゲートウェイを作成します。 @@ -200,7 +199,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 @@ -270,7 +269,7 @@ Kafka VPC を作成するには、次の手順を実行します。 tar -zxf openjdk-22.0.2_linux-x64_bin.tar.gz ``` -3. バイナリを各ブローカー ノードにコピーします。 +3. バイナリを各ブローカーノードにコピーします。 ```shell # Replace {broker-node1-ip} with your broker-node1 IP address @@ -386,7 +385,7 @@ log.dirs=./data **2.4.3 Kafkaブローカーを起動する** -スクリプトを作成し、それを実行して各ブローカー ノードで Kafka ブローカーを起動します。 +スクリプトを作成し、それを実行して各ブローカーノードで Kafka ブローカーを起動します。 ```shell #!/bin/bash @@ -659,7 +658,7 @@ b2.usw2-az2.abc.us-west-2.aws.3199015.tidbcloud.com:9094 (id: 2 rack: null) -> E b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org.apache.kafka.common.errors.DisconnectException ``` -## ステップ 2. Kafka クラスターをプライベート リンク サービスとして公開する {#step-2-expose-the-kafka-cluster-as-private-link-service} +## ステップ 2. Kafka クラスターをプライベートリンクサービスとして公開する {#step-2-expose-the-kafka-cluster-as-private-link-service} ### 1. ロードバランサーを設定する {#1-set-up-the-load-balancer} @@ -674,7 +673,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 つのターゲットグループを作成します。 - ブートストラップターゲットグループ @@ -720,7 +719,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E - **Health check protocol**： `TCP` - **Register targets**: `broker-node3:39092` -2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers:)に進み、ネットワーク ロード バランサーを作成します。 +2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers:)に進み、ネットワークロードバランサーを作成します。 - **Load balancer name**: `kafka-lb` - **Schema**: `Internal` @@ -730,7 +729,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E - `usw2-az1`と`broker-usw2-az1 subnet` - `usw2-az2`と`broker-usw2-az2 subnet` - `usw2-az3`と`broker-usw2-az3 subnet` - - **Security groups**: 次のルールで新しいセキュリティ グループを作成します。 + - **Security groups**: 次のルールで新しいセキュリティグループを作成します。 - 受信ルールは、Kafka VPCからのすべてのTCPを許可します：タイプ - `{ports of target groups}` （例： `9092-9095` ）、ソース - `{CIDR of TiDB Cloud}` 。リージョン内のTiDB CloudのCIDRを取得するには、 [TiDB Cloudコンソール](https://tidbcloud.com)の左上隅にあるコンボボックスを使用してターゲットプロジェクトに切り替え、左側のナビゲーションペインで**Project Settings** > **Network Access**をクリックし、 **Project CIDR** > **AWS**をクリックします。 - アウトバウンドルールは、Kafka VPC へのすべての TCP を許可します: タイプ - `All TCP` 、宛先 - `Anywhere-IPv4` - リスナーとルーティング: @@ -757,7 +756,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E ### 2. プライベートリンクサービスを設定する {#2-set-up-private-link-service} -1. [エンドポイントサービス](https://console.aws.amazon.com/vpcconsole/home#EndpointServices:)に進みます。 **Create endpoint service**をクリックして、Kafka ロード バランサーのプライベート リンク サービスを作成します。 +1. [エンドポイントサービス](https://console.aws.amazon.com/vpcconsole/home#EndpointServices:)に進みます。 **Create endpoint service**をクリックして、Kafka ロードバランサーのプライベートリンクサービスを作成します。 - **Name**: `kafka-pl-service` - **Load balancer type**: `Network` @@ -779,7 +778,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E - **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)の手順に進みます。 @@ -795,7 +794,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E 2. [ステップ1. Kafkaクラスターをセットアップする](#step-1-set-up-a-kafka-cluster)に進んだら、 [実行中の Kafka クラスターを再構成する](#reconfigure-a-running-kafka-cluster)に従って、EXTERNAL リスナーとアドバタイズリスナーの別のグループを作成します。このグループの名前は**EXTERNAL2**とします。EXTERNAL2 のポート範囲は**EXTERNAL**と重複できないことに注意してください。 -3. ブローカーを再構成した後、ブートストラップおよびブローカー ターゲット グループを含む別のターゲット グループをロード バランサーに追加します。 +3. ブローカーを再構成した後、ブートストラップおよびブローカー ターゲットグループを含む別のターゲットグループをロードバランサーに追加します。 4. 次の情報を使用してTiDB Cloud接続を構成します。 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..4f34d5e0167bb 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 @@ -3,13 +3,13 @@ title: Set Up Self-Hosted Kafka Private Link Service in Azure summary: このドキュメントでは、Azure でセルフホスト型 Kafka 用の Private Link サービスを設定し、それをTiDB Cloudで動作させる方法について説明します。 --- -# Azure でセルフホスト型 Kafka プライベートリンク サービスをセットアップする {#set-up-self-hosted-kafka-private-link-service-in-azure} +# Azure でセルフホスト型 Kafka プライベートリンクサービスをセットアップする {#set-up-self-hosted-kafka-private-link-service-in-azure} このドキュメントでは、Azure でセルフホスト型 Kafka 用の Private Link サービスを設定し、それをTiDB Cloudで動作させる方法について説明します。 このメカニズムは次のように機能します。 -1. TiDB Cloud仮想ネットワークは、プライベート エンドポイントを介して Kafka 仮想ネットワークに接続します。 +1. TiDB Cloud仮想ネットワークは、プライベートエンドポイントを介して Kafka 仮想ネットワークに接続します。 2. Kafka クライアントはすべての Kafka ブローカーと直接通信する必要があります。 3. 各 Kafka ブローカーは、 TiDB Cloud仮想ネットワーク内のエンドポイントの一意のポートにマップされます。 4. マッピングを実現するには、Kafka ブートストラップ メカニズムと Azure リソースを活用します。 @@ -34,15 +34,15 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 3. [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから Kafka デプロイメント情報を取得します。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com)で[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 - 2. 左側のナビゲーション ペインで、 **[データ]** > **[Changefeed] を**クリックします。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com)で[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 + 2. 左側のナビゲーションペインで、 **[データ]** > **[Changefeed] を**クリックします。 3. **Changefeed**ページで、右上隅の**Create Changefeed**をクリックし、次の情報を入力します。 1. **宛先**で、 **Kafka**を選択します。 2. **Connectivity Method**で**Private Link**を選択します。 4. 続行する前に、 TiDB Cloud Azureアカウントのリージョン情報とサブスクリプションを**リマインダー**に書き留めておいてください。この情報は、TiDB CloudがKafka Private Linkサービスにアクセスできるように承認する際に使用します。 - 5. 一意のランダム文字列を指定して、Kafka プライベート リンク サービス用の**Kafka Advertised Listener Pattern**を生成します。 + 5. 一意のランダム文字列を指定して、Kafka プライベートリンクサービス用の**Kafka Advertised Listener Pattern**を生成します。 1. 一意のランダム文字列を入力してください。数字または小文字のみ使用できます。この文字列は、後ほど**Kafka Advertised Listener Pattern**を生成する際に使用します。 - 2. **「使用状況を確認して生成」をクリックすると、**ランダム文字列が一意であるかどうかが確認され、Kafka ブローカーの外部アドバタイズ リスナーを組み立てるために使用される**Kafka Advertised Listener Pattern**が生成されます。 + 2. **「使用状況を確認して生成」をクリックすると、**ランダム文字列が一意であるかどうかが確認され、Kafka ブローカーの外部アドバタイズリスナーを組み立てるために使用される**Kafka Advertised Listener Pattern**が生成されます。 すべてのデプロイメント情報をメモしてください。後でKafka Private Linkサービスを設定する際に必要になります。 @@ -120,9 +120,9 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 仮想マシンの展開が完了したら、次の手順を実行します。 -1. [Azureポータル](https://portal.azure.com/)で[**Resource groups**](https://portal.azure.com/#view/HubsExtension/BrowseResourceGroups.ReactView)ページに移動し、リソース グループ名をクリックして、各ブローカー ノード ( `broker-node-1` 、 `broker-node-2` 、および`broker-node-3` ) のページに移動します。 +1. [Azureポータル](https://portal.azure.com/)で[**Resource groups**](https://portal.azure.com/#view/HubsExtension/BrowseResourceGroups.ReactView)ページに移動し、リソースグループ名をクリックして、各ブローカーノード ( `broker-node-1` 、 `broker-node-2` 、および`broker-node-3` ) のページに移動します。 -2. ブローカー ノードの各ページで、左側のナビゲーション ペインの**Connect > Bastion**をクリックし、次の情報を入力します。 +2. ブローカーノードの各ページで、左側のナビゲーションペインの**Connect > Bastion**をクリックし、次の情報を入力します。 - **Authentication Type**: `SSH Private Key from Local File` - **ユーザー名**: `azureuser` @@ -131,7 +131,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 3. ブローカーノードの各ページで**接続**をクリックすると、Linuxターミナルで新しいブラウザタブが開きます。3つのブローカーノードごとに、Linuxターミナルで3つのブラウザタブを開く必要があります。 -4. 各 Linux ターミナルで次のコマンドを実行して、各ブローカー ノードにバイナリをダウンロードします。 +4. 各 Linux ターミナルで次のコマンドを実行して、各ブローカーノードにバイナリをダウンロードします。 ```shell # Download Kafka and OpenJDK, and then extract the files. You can choose the binary version based on your preference. @@ -150,7 +150,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 2. 2 つのブローカー リスナーを構成します。内部 Kafka クライアント アクセス用の**INTERNAL**と、 TiDB Cloudからのアクセス用の**EXTERNAL です**。 2. `advertised.listeners`については、次の操作を行います。 - 1. ブローカー ノードの内部 IP アドレスを使用して、各ブローカーの内部アドバタイズ リスナーを構成します。これにより、内部 Kafka クライアントはアドバタイズ アドレスを介してブローカーに接続できるようになります。 + 1. ブローカーノードの内部 IP アドレスを使用して、各ブローカーの内部アドバタイズリスナーを構成します。これにより、内部 Kafka クライアントはアドバタイズ アドレスを介してブローカーに接続できるようになります。 2. TiDB Cloudから取得した**Kafka Advertised Listener Pattern**に基づいて、各ブローカーノードにEXTERNALアドバタイズリスナーを設定することで、TiDB Cloudが異なるブローカーを区別できるようになります。異なるEXTERNALアドバタイズリスナーを設定することで、 TiDB Cloud側のKafkaクライアントはリクエストを適切なブローカーにルーティングできるようになります。 - Kafka Private Link サービスへのアクセスにおいて、ブローカーを区別するために異なる``値を使用してください。すべてのブローカーの EXTERNAL アドバタイズリスナーのポート範囲を計画してください。これらのポートは、ブローカーが実際にリッスンするポートである必要はありません。これらのポートは、Private Link サービス内のロードバランサーがリッスンするポートであり、ロードバランサーはリクエストを異なるブローカーに転送します。 - トラブルシューティングを容易にするために、ブローカーごとに異なるブローカー ID を構成することをお勧めします。 @@ -214,7 +214,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka log.dirs=./data ``` -3. スクリプトを作成し、それを実行して各ブローカー ノードで Kafka ブローカーを起動します。 +3. スクリプトを作成し、それを実行して各ブローカーノードで Kafka ブローカーを起動します。 ```shell SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" @@ -500,7 +500,7 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. ### 2. プライベートリンクサービスを設定する {#2-set-up-private-link-service} -1. [Azureポータル](https://portal.azure.com/)にログインし、 [プライベートリンクサービス](https://portal.azure.com/#view/Microsoft_Azure_Network/PrivateLinkCenterBlade/~/privatelinkservices)ページに移動して、 **+ Create**をクリックし、Kafka ロードバランサーのプライベートリンク サービスを作成します。 +1. [Azureポータル](https://portal.azure.com/)にログインし、 [プライベートリンクサービス](https://portal.azure.com/#view/Microsoft_Azure_Network/PrivateLinkCenterBlade/~/privatelinkservices)ページに移動して、 **+ Create**をクリックし、Kafka ロードバランサーのプライベートリンクサービスを作成します。 2. **[基本]**タブで、 **[サブスクリプ**ション]、 **Resource group** 、 **[リージョン]**を選択し、[**名前]**フィールドに`kafka-pls`入力して、 **[次へ: 送信設定 >]**をクリックします。 @@ -523,10 +523,10 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**Private Link**経由で Kafka クラスターに接続するための変更フィードを作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 -2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベート リンク」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 +2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベートリンク」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 - **Kafka Advertised Listener Pattern**: [前提条件](#prerequisites)で**Kafka Advertised Listener Pattern**を生成するために使用する一意のランダム文字列。 - - **プライベート リンク サービスのエイリアス**: [2. プライベートリンクサービスを設定する](#2-set-up-private-link-service)で取得したプライベート リンク サービスのエイリアス。 + - **プライベートリンクサービスのエイリアス**: [2. プライベートリンクサービスを設定する](#2-set-up-private-link-service)で取得したプライベートリンクサービスのエイリアス。 - **Bootstrap Ports**: `9093,9094,9095` 。 3. [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)の手順に進みます。 @@ -543,7 +543,7 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 2. [ステップ1. Kafkaクラスターをセットアップする](#step-1-set-up-a-kafka-cluster)に進んだら、 [実行中の Kafka クラスターを再構成する](#reconfigure-a-running-kafka-cluster)に進み、EXTERNAL リスナーとアドバタイズリスナーの別のグループを作成します。このグループの名前は**EXTERNAL2**とします。EXTERNAL2**の**ポート範囲は**EXTERNAL**と重複する可能性があることに注意してください。 -3. ブローカーを再構成した後、新しいロード バランサーと新しいプライベート リンク サービスを作成します。 +3. ブローカーを再構成した後、新しいロードバランサーと新しいプライベートリンクサービスを作成します。 4. 次の情報を使用してTiDB Cloud接続を構成します。 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..fdff889e1bc8c 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -3,22 +3,22 @@ title: Set Up Self-Hosted Kafka Private Service Connect in Google Cloud summary: このドキュメントでは、Google Cloud でセルフホスト型 Kafka 用に Private Service Connect を設定し、それをTiDB Cloudで動作させる方法について説明します。 --- -# Google Cloud でセルフホスト型 Kafka プライベート サービス接続を設定する {#set-up-self-hosted-kafka-private-service-connect-in-google-cloud} +# Google Cloud でセルフホスト型 Kafka プライベートサービス接続を設定する {#set-up-self-hosted-kafka-private-service-connect-in-google-cloud} このドキュメントでは、Google Cloud でセルフホスト型 Kafka 用に Private Service Connect を設定する方法と、それをTiDB Cloudで動作させる方法について説明します。 このメカニズムは次のように機能します。 -1. TiDB Cloud VPC は、プライベート エンドポイントを介して Kafka VPC に接続します。 +1. TiDB Cloud VPC は、プライベートエンドポイントを介して Kafka VPC に接続します。 2. Kafka クライアントはすべての Kafka ブローカーと直接通信する必要があります。 3. 各 Kafka ブローカーは、 TiDB Cloud VPC 内の一意のポートにマッピングされます。 4. マッピングを実現するには、Kafka ブートストラップ メカニズムと Google Cloud リソースを活用します。 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)を参照してください。 +- 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)を参照してください。 +- [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 サービスの使用を推奨します。 @@ -37,16 +37,16 @@ Google Cloud でセルフホスト型 Kafka に Private Service Connect を設 3. TiDB Cloud Dedicated クラスターから Kafka デプロイメント情報を取得します。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com)で[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com)で[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 2. 概要ページで、TiDB クラスターのリージョンを確認します。Kafka クラスターが同じリージョンにデプロイされることを確認してください。 - 3. 左側のナビゲーション ペインで**[データ]** > **[Changefeed] を**クリックし、右上隅の**Create Changefeed**をクリックして、次の情報を入力します。 + 3. 左側のナビゲーションペインで**[データ]** > **[Changefeed] を**クリックし、右上隅の**Create Changefeed**をクリックして、次の情報を入力します。 1. **宛先**で、 **Kafka**を選択します。 2. **Connectivity Method**で、 **Private Service Connect**を選択します。 4. **先に進む前に、Google Cloud プロジェクトをリマインダー**に書き留めておいてください。このプロジェクトは、 TiDB Cloudからのエンドポイント作成リクエストの自動承認を承認するために使用します。 5. **Zones of TiDB Cluster**をメモしておいてください。これらのゾーンに TiDB クラスターをデプロイします。ゾーン間のトラフィックを削減するため、これらのゾーンに Kafka をデプロイすることをお勧めします。 - 6. Kafka プライベート サービス接続サービスに固有の**Kafka Advertised Listener Pattern**を選択します。 + 6. Kafka プライベートサービス接続サービスに固有の**Kafka Advertised Listener Pattern**を選択します。 1. 一意のランダム文字列を入力してください。数字または小文字のみ使用できます。この文字列は、後ほど**Kafka Advertised Listener Pattern**を生成する際に使用します。 - 2. **「使用状況を確認して生成」を**クリックすると、ランダム文字列が一意であるかどうかが確認され、Kafka ブローカーの外部アドバタイズ リスナーを組み立てるために使用される**Kafka Advertised Listener Pattern**が生成されるか、Kafka プロキシが構成されます。 + 2. **「使用状況を確認して生成」を**クリックすると、ランダム文字列が一意であるかどうかが確認され、Kafka ブローカーの外部アドバタイズリスナーを組み立てるために使用される**Kafka Advertised Listener Pattern**が生成されるか、Kafka プロキシが構成されます。 すべてのデプロイメント情報をメモしてください。後でKafka Private Service Connectサービスを設定する際に必要になります。 @@ -59,7 +59,7 @@ Google Cloud でセルフホスト型 Kafka に Private Service Connect を設 | ゾーン |
  • `us-west1-a`
  • `us-west1-b`
  • `us-west1-c`
    • | | Kafka アドバタイズド リスナー パターン | 一意のランダム文字列: `abc`
    生成されたパターン: <broker_id>.abc.us-west1.gcp.3199745.tidbcloud.com:<port> | -## PSC ポート マッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定 {#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping} +## PSC ポートマッピングによるセルフホスト型 Kafka Private Service Connect サービスの設定 {#set-up-self-hosted-kafka-private-service-connect-service-by-psc-port-mapping} PSCポートマッピングメカニズムを使用して、各KafkaブローカーをTiDB Cloud VPCに固有のポートで公開します。次の図は、その仕組みを示しています。 @@ -147,7 +147,7 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con tar -zxf openjdk-22.0.2_linux-x64_bin.tar.gz ``` -2. バイナリを各ブローカー ノードにコピーします。 +2. バイナリを各ブローカーノードにコピーします。 ```shell # Run this command to authorize gcloud to access the Cloud Platform with Google user credentials @@ -171,7 +171,7 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con 1. すべての**コントローラー**ロールノードに同じ CONTROLLER リスナーを設定します。**ブローカー**ロールノードのみを追加する場合は、 `server.properties`の CONTROLLER リスナーは必要ありません。 2. 2 つの**ブローカー**リスナーを構成します。内部アクセスの場合は INTERNAL、 TiDB Cloudからの外部アクセスの場合は EXTERNAL です。 2. `advertised.listeners`については、次の操作を行います。 - 1. ブローカー ノードの内部 IP アドレスを使用して、各ブローカーの内部アドバタイズ リスナーを構成します。これにより、内部 Kafka クライアントはアドバタイズ アドレスを介してブローカーに接続できるようになります。 + 1. ブローカーノードの内部 IP アドレスを使用して、各ブローカーの内部アドバタイズリスナーを構成します。これにより、内部 Kafka クライアントはアドバタイズ アドレスを介してブローカーに接続できるようになります。 2. TiDB Cloudから取得した**Kafka Advertised Listener Pattern**に基づいて、各ブローカーノードにEXTERNALアドバタイズリスナーを設定することで、TiDB Cloudが複数のブローカーを区別できるようになります。異なるEXTERNALアドバタイズリスナーを設定することで、 TiDB Cloud側のKafkaクライアントはリクエストを適切なブローカーにルーティングできるようになります。 - ``ブローカーと Kafka Private Service Connect アクセスポイントを区別します。すべてのブローカーの EXTERNAL アドバタイズリスナーのポート範囲を計画してください。これらのポートは、ブローカーが実際にリッスンするポートである必要はありません。これらは、リクエストを別のブローカーに転送する Private Service Connect のロードバランサーがリッスンするポートです。 - トラブルシューティングを容易にするために、ブローカーごとに異なるブローカー ID を構成することをお勧めします。 @@ -234,7 +234,7 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con log.dirs=./data ``` -3. スクリプトを作成し、それを実行して各ブローカー ノードで Kafka ブローカーを起動します。 +3. スクリプトを作成し、それを実行して各ブローカーノードで Kafka ブローカーを起動します。 ```shell #!/bin/bash @@ -474,7 +474,7 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. - **ネットワーク**: `kafka-vpc` - **サブネット**: `brokers-subnet` -2. ネットワーク エンドポイント グループの詳細ページに移動し、ネットワーク エンドポイントを追加して、ブローカー ノードへのポート マッピングを構成します。 +2. ネットワークエンドポイント グループの詳細ページに移動し、ネットワークエンドポイントを追加して、ブローカーノードへのポートマッピングを構成します。 1. ネットワークエンドポイント1 - **インスタンス**: `broker-node1` @@ -519,7 +519,7 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 5. `kafka-psc`の詳細ページに移動します。**Service attachment**（例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-psc` ）を書き留めます。TiDB Cloudでこの PSC に接続する際に使用します。 -6. VPC ネットワーク`kafka-vpc`の詳細ページに移動し、すべてのブローカーへの PSC トラフィックを許可するファイアウォール ルールを追加します。 +6. VPC ネットワーク`kafka-vpc`の詳細ページに移動し、すべてのブローカーへの PSC トラフィックを許可するファイアウォールルールを追加します。 - **名前**: `allow-psc-traffic` - **Direction of traffic**： `Ingress` @@ -533,7 +533,7 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**Private Service Connect**経由で Kafka クラスターに接続するための changefeed を作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 -2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベート サービス接続」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 +2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベートサービス接続」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 - **Kafka Advertised Listener Pattern**: `abc` 。これは、 [前提条件](#prerequisites)で**Kafka Advertised Listener Pattern**を生成するために使用する一意のランダム文字列と同じです。 - **Service Attachment**: PSC の Kafka サービス アタッチメント (例: `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-psc` )。 @@ -541,7 +541,7 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 3. [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)の手順に進みます。 -## Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ {#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy} +## Kafka-proxy によるセルフホスト型 Kafka プライベートサービス接続のセットアップ {#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy} Kafkaプロキシの動的ポートマッピングメカニズムを使用して、各KafkaブローカーをTiDB Cloud VPCに固有のポートで公開します。次の図は、その仕組みを示しています。 @@ -659,7 +659,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが 3. **kafka-proxy-psc**の詳細ページに移動します。 `Service attachment` （例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-proxy-psc` ）をメモします。これは、 TiDB Cloudがこの PSC に接続する際に使用されます。 -4. VPC ネットワークの詳細ページに移動し、すべてのブローカーの PSC トラフィックを許可するファイアウォール ルールを追加します。 +4. VPC ネットワークの詳細ページに移動し、すべてのブローカーの PSC トラフィックを許可するファイアウォールルールを追加します。 - **名前**: `allow-proxy-psc-traffic` - **Direction of traffic**： `Ingress` @@ -687,16 +687,16 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが すでにこのドキュメントの手順に従って最初のプロジェクトからの接続を正常に設定していて、2 番目のプロジェクトから 2 番目の接続を設定する場合は、次のようにして 2 つの異なるTiDB Cloudプロジェクトから同じ Kafka Private Service Connect サービスに接続できます。 -- PSC ポート マッピングによって Kafka PSC を設定する場合は、次の手順を実行します。 +- PSC ポートマッピングによって Kafka PSC を設定する場合は、次の手順を実行します。 1. このドキュメントの冒頭の指示に従ってください[ステップ1. Kafkaクラスタのセットアップ](#step-1-set-up-the-kafka-cluster)に進んだら、 [実行中の Kafka クラスターを再構成する](#reconfigure-a-running-kafka-cluster)セクションに従って、EXTERNAL リスナーとアドバタイズリスナーの別のグループを作成してください。このグループの名前は`EXTERNAL2`とします。ポート範囲`EXTERNAL2`は EXTERNAL と重複できないことに注意してください。 - 2. ブローカーを再構成した後、ネットワーク エンドポイントの別のグループをネットワーク エンドポイント グループに追加し、ポート範囲を`EXTERNAL2`リスナーにマップします。 + 2. ブローカーを再構成した後、ネットワークエンドポイントの別のグループをネットワークエンドポイント グループに追加し、ポート範囲を`EXTERNAL2`リスナーにマップします。 3. 新しい変更フィードを作成するには、次の入力でTiDB Cloud接続を構成します。 - 新しいブートストラップポート - - 新しい Kafka アドバタイズ リスナー パターン + - 新しい Kafka アドバタイズリスナー パターン - 同じサービスアタッチメント -- [Kafka-proxy によるセルフホスト型 Kafka プライベート サービス コネクトのセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)の場合は、新しい Kafka アドバタイズ リスナー パターンを使用して、最初から新しい Kafka プロキシ PSC を作成します。 +- [Kafka-proxy によるセルフホスト型 Kafka プライベートサービス コネクトのセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)の場合は、新しい Kafka アドバタイズリスナー パターンを使用して、最初から新しい Kafka プロキシ PSC を作成します。 diff --git a/tidb-cloud/sql-concepts.md b/tidb-cloud/sql-concepts.md index d3f3894172f7d..4de60b5eb8c11 100644 --- a/tidb-cloud/sql-concepts.md +++ b/tidb-cloud/sql-concepts.md @@ -17,7 +17,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 SQLは、その関数に応じて以下の4種類に分類されます。 -- DDL (データ定義言語): データベース、テーブル、ビュー、インデックスなどのデータベース オブジェクトを定義するために使用されます。 TiDB の DDL ステートメントについては、 [スキーマ管理／データ定義文（DDL）](/sql-statements/sql-statement-overview.md#schema-management--data-definition-statements-ddl)を参照してください。 +- DDL (データ定義言語): データベース、テーブル、ビュー、インデックスなどのデータベースオブジェクトを定義するために使用されます。 TiDB の DDL ステートメントについては、 [スキーマ管理／データ定義文（DDL）](/sql-statements/sql-statement-overview.md#schema-management--data-definition-statements-ddl)を参照してください。 - DML（データ操作言語）：アプリケーション関連のレコードを操作するために使用されます。TiDB の DML ステートメントについては、 [データ操作文（DML）](/sql-statements/sql-statement-overview.md#data-manipulation-statements-dml)を参照してください。 diff --git a/tidb-cloud/sql-proxy-account.md b/tidb-cloud/sql-proxy-account.md index 545cd490cde84..002465ceedf97 100644 --- a/tidb-cloud/sql-proxy-account.md +++ b/tidb-cloud/sql-proxy-account.md @@ -1,6 +1,6 @@ --- title: SQL Proxy Account -summary: TiDB Cloudの SQL プロキシ アカウントについて説明します。 +summary: TiDB Cloudの SQL プロキシアカウントについて説明します。 --- # SQL プロキシアカウント {#sql-proxy-account} @@ -9,7 +9,7 @@ SQLプロキシアカウントは、 TiDB Cloudによって自動的に作成さ SQLプロキシアカウントは、 TiDB Cloud内のデータベースにアクセスするための安全なトークンベースの認証メカニズムを提供します。従来のユーザー名とパスワードによる認証が不要になるため、SQLプロキシアカウントはセキュリティを強化し、アクセス管理を簡素化します。 -SQL プロキシ アカウントの主な利点は次のとおりです。 +SQL プロキシアカウントの主な利点は次のとおりです。 - 強化されたセキュリティ: JWT トークンを使用することで、静的資格情報に関連するリスクを軽減します。 - 合理化されたアクセス: SQL エディターとData Serviceへのアクセスを具体的に制限し、正確な制御を保証します。 @@ -17,7 +17,7 @@ SQL プロキシ アカウントの主な利点は次のとおりです。 ## SQLプロキシアカウントを特定する {#identify-the-sql-proxy-account} -特定の SQL アカウントが SQL プロキシ アカウントであるかどうかを識別する場合は、次の手順を実行します。 +特定の SQL アカウントが SQL プロキシアカウントであるかどうかを識別する場合は、次の手順を実行します。 1. `mysql.user`テーブルを調べます。 @@ -34,13 +34,13 @@ SQL プロキシ アカウントの主な利点は次のとおりです。 ## SQLプロキシアカウントの作成方法 {#how-the-sql-proxy-account-is-created} -SQL プロキシ アカウントは、クラスター内で権限を持つロールが付与されたTiDB Cloud クラスターの初期化中に自動的に作成されます。 +SQL プロキシアカウントは、クラスター内で権限を持つロールが付与されたTiDB Cloud クラスターの初期化中に自動的に作成されます。 ## SQLプロキシアカウントを削除する方法 {#how-the-sql-proxy-account-is-deleted} -ユーザーが[組織](/tidb-cloud/manage-user-access.md#remove-an-organization-member)または[プロジェクト](/tidb-cloud/manage-user-access.md#remove-a-project-member)から削除されるか、そのロールがクラスターにアクセスできないロールに変更されると、SQL プロキシ アカウントは自動的に削除されます。 +ユーザーが[組織](/tidb-cloud/manage-user-access.md#remove-an-organization-member)または[プロジェクト](/tidb-cloud/manage-user-access.md#remove-a-project-member)から削除されるか、そのロールがクラスターにアクセスできないロールに変更されると、SQL プロキシアカウントは自動的に削除されます。 -SQL プロキシ アカウントを手動で削除した場合、ユーザーが次回TiDB Cloudコンソールにログインしたときに自動的に再作成されることに注意してください。 +SQL プロキシアカウントを手動で削除した場合、ユーザーが次回TiDB Cloudコンソールにログインしたときに自動的に再作成されることに注意してください。 ## SQLプロキシアカウントのユーザー名 {#sql-proxy-account-username} @@ -70,9 +70,9 @@ SQLプロキシアカウントのユーザー名は、 TiDB Cloudのユーザー SQL プロキシアカウントは JWT トークンベースであるため、これらのアカウントのパスワードを管理する必要はありません。セキュリティトークンはシステムによって自動的に管理されます。 -## SQL プロキシ アカウント ロール {#sql-proxy-account-roles} +## SQL プロキシアカウント ロール {#sql-proxy-account-roles} -SQL プロキシ アカウントのロールは、 TiDB CloudユーザーのIAMロールによって異なります。 +SQL プロキシアカウントのロールは、 TiDB CloudユーザーのIAMロールによって異なります。 - 組織レベル: - 組織の所有者: role_admin @@ -85,6 +85,6 @@ SQL プロキシ アカウントのロールは、 TiDB CloudユーザーのIAM - プロジェクトデータアクセスの読み取り/書き込み: role_readwrite - プロジェクトデータアクセス読み取り専用: role_readonly -## SQL プロキシ アカウント アクセス制御 {#sql-proxy-account-access-control} +## SQL プロキシアカウント アクセス制御 {#sql-proxy-account-access-control} SQLプロキシアカウントはJWTトークンベースであり、Data ServiceとSQLエディタからのみアクセスできます。ユーザー名とパスワードを使用してSQLプロキシアカウントを使用してTiDB Cloudクラスターにアクセスすることはできません。 diff --git a/tidb-cloud/terraform-get-tidbcloud-provider.md b/tidb-cloud/terraform-get-tidbcloud-provider.md index 2f3234e813c1a..ecf90c5086dbe 100644 --- a/tidb-cloud/terraform-get-tidbcloud-provider.md +++ b/tidb-cloud/terraform-get-tidbcloud-provider.md @@ -29,7 +29,7 @@ macOS の場合、次の手順に従ってHomebrewを使用して Terraform を brew install hashicorp/tap/terraform ``` -その他のオペレーティング システムの手順については、[Terraform ドキュメント](https://learn.hashicorp.com/tutorials/terraform/install-cli)を参照してください。 +その他のオペレーティングシステムの手順については、[Terraform ドキュメント](https://learn.hashicorp.com/tutorials/terraform/install-cli)を参照してください。 ## ステップ2. APIキーを作成する {#step-2-create-an-api-key} diff --git a/tidb-cloud/terraform-migrate-cluster-resource.md b/tidb-cloud/terraform-migrate-cluster-resource.md index 563a234b3a4a5..eef753c36eae0 100644 --- a/tidb-cloud/terraform-migrate-cluster-resource.md +++ b/tidb-cloud/terraform-migrate-cluster-resource.md @@ -23,7 +23,7 @@ TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソ terraform state list | grep "tidbcloud_cluster" ``` -2. 移行するターゲット クラスター リソースを選択し、後で使用するためにクラスター`id`を取得します。 +2. 移行するターゲットクラスター リソースを選択し、後で使用するためにクラスター`id`を取得します。 ```shell terraform state show ${your_target_cluster_resource} | grep ' id ' @@ -31,7 +31,7 @@ TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソ ## ステップ2. Terraform状態から既存のリソースを削除する {#step-2-remove-the-existing-resource-from-the-terraform-state} -ターゲット クラスター リソースを Terraform 状態から削除します。 +ターゲットクラスター リソースを Terraform 状態から削除します。 ```shell terraform state rm ${your_target_cluster_resource} @@ -39,11 +39,11 @@ terraform state rm ${your_target_cluster_resource} ## ステップ3. ターゲットクラスタリソースの構成を削除する {#step-3-delete-the-configuration-of-your-target-cluster-resource} -`.tf`ファイルで、ターゲット クラスター リソースの構成を見つけて、対応するコードを削除します。 +`.tf`ファイルで、ターゲットクラスター リソースの構成を見つけて、対応するコードを削除します。 ## ステップ4. 新しいクラスターリソースのインポートブロックを追加する {#step-4-add-an-import-block-for-the-new-cluster-resource} -- ターゲット クラスターがTiDB Cloud Starter の場合は、次のインポート ブロックを`.tf`ファイルに追加し、 `example`目的のリソース名に置き換え、 `${id}` [ステップ1](#step-1-identify-the-tidbcloud_cluster-resource-to-migrate)から取得したクラスター ID に置き換えます。 +- ターゲットクラスターがTiDB Cloud Starter の場合は、次のインポート ブロックを`.tf`ファイルに追加し、 `example`目的のリソース名に置き換え、 `${id}` [ステップ1](#step-1-identify-the-tidbcloud_cluster-resource-to-migrate)から取得したクラスター ID に置き換えます。 ``` # TiDB Cloud Starter @@ -53,7 +53,7 @@ terraform state rm ${your_target_cluster_resource} } ``` -- ターゲット クラスターがTiDB Cloud Dedicated の場合は、次のインポート ブロックを`.tf`ファイルに追加し、 `example`目的のリソース名に置き換え、 `${id}` [ステップ1](#step-1-identify-the-tidbcloud_cluster-resource-to-migrate)から取得したクラスター ID に置き換えます。 +- ターゲットクラスターがTiDB Cloud Dedicated の場合は、次のインポート ブロックを`.tf`ファイルに追加し、 `example`目的のリソース名に置き換え、 `${id}` [ステップ1](#step-1-identify-the-tidbcloud_cluster-resource-to-migrate)から取得したクラスター ID に置き換えます。 ``` # TiDB Cloud Dedicated diff --git a/tidb-cloud/terraform-tidbcloud-provider-overview.md b/tidb-cloud/terraform-tidbcloud-provider-overview.md index 0c2655c06ad8f..c8de85a381c30 100644 --- a/tidb-cloud/terraform-tidbcloud-provider-overview.md +++ b/tidb-cloud/terraform-tidbcloud-provider-overview.md @@ -12,7 +12,7 @@ summary: Terraform を使用してTiDB Cloudリソースを作成、管理、更 リソースのプロビジョニングとインフラストラクチャ ワークフローを自動化する簡単な方法を探している場合は、次の機能を提供するTiDB Cloud Terraform Provider を試してみてください。 - プロジェクト情報を取得します。 -- サポートされているクラウド プロバイダー、リージョン、ノード サイズなどのクラスター仕様情報を取得します。 +- サポートされているクラウドプロバイダー、リージョン、ノードサイズなどのクラスター仕様情報を取得します。 - クラスターの作成、スケーリング、一時停止、再開など、TiDB クラスターを管理します。 - クラスターのバックアップを作成および削除します。 - クラスターの復元タスクを作成します。 @@ -27,7 +27,7 @@ summary: Terraform を使用してTiDB Cloudリソースを作成、管理、更 [リソース](https://www.terraform.io/language/resources)と[データソース](https://www.terraform.io/language/data-sources) 、Terraform 言語で最も重要な 2 つの要素です。 -TiDB Cloud は次のリソースとデータ ソースをサポートしています。 +TiDB Cloud は次のリソースとデータソースをサポートしています。 - リソース @@ -44,7 +44,7 @@ TiDB Cloud は次のリソースとデータ ソースをサポートしてい - `tidbcloud_restores` - `tidbcloud_backups` -リソースとデータ ソースの使用可能なすべての構成を取得するには、[構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 +リソースとデータソースの使用可能なすべての構成を取得するには、[構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 ## 次のステップ {#next-step} diff --git a/tidb-cloud/terraform-use-backup-resource.md b/tidb-cloud/terraform-use-backup-resource.md index 4fdb231fa5c9b..e2a047850aefd 100644 --- a/tidb-cloud/terraform-use-backup-resource.md +++ b/tidb-cloud/terraform-use-backup-resource.md @@ -145,7 +145,7 @@ summary: tidbcloud_backup` リソースを使用してTiDB Cloudクラスター ## バックアップを削除する {#delete-a-backup} -バックアップを削除するには、対応する`backup.tf`ファイルが配置されているバックアップ ディレクトリに移動し、 `terraform destroy`コマンドを実行して`tidbcloud_backup`リソースを破棄します。 +バックアップを削除するには、対応する`backup.tf`ファイルが配置されているバックアップディレクトリに移動し、 `terraform destroy`コマンドを実行して`tidbcloud_backup`リソースを破棄します。 $ terraform destroy diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 9e8e0f15e4c3f..600933c6a25c9 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -11,7 +11,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを このドキュメントでは、 `tidbcloud_cluster`リソースを使用してTiDB Cloudクラスターを管理する方法を学習できます。 -さらに、データ ソース`tidbcloud_projects`と`tidbcloud_cluster_specs`を使用して必要な情報を取得する方法も学習します。 +さらに、データソース`tidbcloud_projects`と`tidbcloud_cluster_specs`を使用して必要な情報を取得する方法も学習します。 `tidbcloud_cluster`リソースの機能は次のとおりです。 @@ -27,7 +27,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを 各 TiDB クラスターはプロジェクトに属します。TiDB クラスターを作成する前に、クラスターを作成するプロジェクトの ID を取得する必要があります。 -利用可能なすべてのプロジェクトの情報を表示するには、次のように`tidbcloud_projects`データ ソースを使用します。 +利用可能なすべてのプロジェクトの情報を表示するには、次のように`tidbcloud_projects`データソースを使用します。 1. [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md)を実行すると作成される`main.tf`ファイルに、次のように`data`と`output`ブロックを追加します。 @@ -54,17 +54,17 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを value = data.tidbcloud_projects.example_project.items } - - `data`ブロックを使用して、データ ソース タイプやデータ ソース名など、 TiDB Cloudのデータ ソースを定義します。 + - `data`ブロックを使用して、データソース タイプやデータソース名など、 TiDB Cloudのデータソースを定義します。 - - プロジェクト データ ソースを使用するには、データ ソース タイプを`tidbcloud_projects`に設定します。 + - プロジェクト データソースを使用するには、データソース タイプを`tidbcloud_projects`に設定します。 - データソース名は、必要に応じて定義できます。例："example_project"。 - - `tidbcloud_projects`データ ソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 + - `tidbcloud_projects`データソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 - - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 + - `output`ブロックを使用して、出力に表示されるデータソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 `output`ブロックはプログラミング言語の戻り値と同様に機能します。詳細は[Terraform ドキュメント](https://www.terraform.io/language/values/outputs)を参照してください。 - リソースとデータ ソースの使用可能なすべての構成を取得するには、[構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 + リソースとデータソースの使用可能なすべての構成を取得するには、[構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 @@ -121,9 +121,9 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを ## `tidbcloud_cluster_specs`データソースを使用してクラスター仕様情報を取得する {#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source} -クラスターを作成する前に、使用可能なすべての構成値 (サポートされているクラウド プロバイダー、リージョン、ノード サイズなど) が含まれるクラスター仕様情報を取得する必要があります。 +クラスターを作成する前に、使用可能なすべての構成値 (サポートされているクラウドプロバイダー、リージョン、ノードサイズなど) が含まれるクラスター仕様情報を取得する必要があります。 -クラスター仕様情報を取得するには、次のように`tidbcloud_cluster_specs`データ ソースを使用できます。 +クラスター仕様情報を取得するには、次のように`tidbcloud_cluster_specs`データソースを使用できます。 1. `main.tf`ファイルを次のように編集します。 @@ -254,7 +254,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを 結果は次のとおりです。 -- `cloud_provider`は、TiDB クラスターをホストできるクラウド プロバイダーです。 +- `cloud_provider`は、TiDB クラスターをホストできるクラウドプロバイダーです。 - `region`は`cloud_provider`の領域です。 - `node_quantity_range`最小ノード数とノードをスケーリングするステップを示します。 - `node_size`はノードのサイズです。 diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index cbb2a3ccba070..aabefa6d5ca83 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -7,7 +7,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi このドキュメントでは、 `tidbcloud_dedicated_cluster`リソースを使用して[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを管理する方法について説明します。 -また、 `tidbcloud_projects`データ ソースで必要な情報を取得し、 `tidbcloud_dedicated_node_group`リソースを使用してTiDB Cloud Dedicated クラスターの TiDB ノード グループを管理する方法も学習します。 +また、 `tidbcloud_projects`データソースで必要な情報を取得し、 `tidbcloud_dedicated_node_group`リソースを使用してTiDB Cloud Dedicated クラスターの TiDB ノードグループを管理する方法も学習します。 `tidbcloud_dedicated_cluster`リソースの機能は次のとおりです。 @@ -24,7 +24,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi 各TiDB Cloud Dedicatedクラスタはプロジェクトに属します。TiDB Cloud Dedicatedクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`が指定されていない場合は、デフォルトのプロジェクトが使用されます。 -利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 +利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データソースを使用します。 1. [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md)で作成した`main.tf`ファイルに、次のように`data`と`output`ブロックを追加します。 @@ -50,17 +50,17 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi value = data.tidbcloud_projects.example_project.items } - - `data`ブロックを使用して、データ ソース タイプやデータ ソース名など、 TiDB Cloudのデータ ソースを定義します。 + - `data`ブロックを使用して、データソース タイプやデータソース名など、 TiDB Cloudのデータソースを定義します。 - - プロジェクト データ ソースを使用するには、データ ソース タイプを`tidbcloud_projects`に設定します。 + - プロジェクト データソースを使用するには、データソース タイプを`tidbcloud_projects`に設定します。 - データソース名は必要に応じて定義できます。例： `"example_project"` 。 - - `tidbcloud_projects`データ ソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 + - `tidbcloud_projects`データソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 - - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 + - `output`ブロックを使用して、出力に表示されるデータソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 `output`ブロックは、プログラミング言語の戻り値と同様に機能します。詳細については、 [Terraformドキュメント](https://www.terraform.io/language/values/outputs)を参照してください。 - リソースとデータ ソースに使用可能なすべての構成を取得するには、 [Terraform プロバイダーの構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 + リソースとデータソースに使用可能なすべての構成を取得するには、 [Terraform プロバイダーの構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 @@ -386,8 +386,8 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 - クラスターをスケーリングします。 - クラスターを一時停止または再開します。 - クラスターに[TiDBノードグループ](/tidb-cloud/tidb-node-group-overview.md)追加します。 -- クラスターの TiDB ノード グループを更新します。 -- クラスターの TiDB ノード グループを削除します。 +- クラスターの TiDB ノードグループを更新します。 +- クラスターの TiDB ノードグループを削除します。 ### TiFlashコンポーネントを追加する {#add-a-tiflash-component} @@ -809,13 +809,13 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 5. `terraform apply`コマンドを実行し、確認のために`yes`入力します。しばらく待つと、状態が最終的に`ACTIVE`に変更されます。 -### クラスターに TiDB ノード グループを追加する {#add-a-tidb-node-group-to-the-cluster} +### クラスターに TiDB ノードグループを追加する {#add-a-tidb-node-group-to-the-cluster} -状態が`ACTIVE`の場合、 TiDB ノード グループをクラスターに追加できます。 +状態が`ACTIVE`の場合、 TiDB ノードグループをクラスターに追加できます。 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 @@ -896,7 +896,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 ### クラスターのTiDBノードグループを更新する {#update-a-tidb-node-group-of-the-cluster} -クラスターの TiDB ノード グループの状態が`ACTIVE`の場合、そのグループを更新できます。 +クラスターの TiDB ノードグループの状態が`ACTIVE`の場合、そのグループを更新できます。 1. [クラスターを作成する](#create-a-tidb-cloud-dedicated-cluster)際に使用する`cluster.tf`ファイルで、 `tidbcloud_dedicated_node_group`の設定を編集します。 @@ -960,9 +960,9 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 Apply complete! Resources: 0 added, 1 changed, 0 destroyed. ``` -### クラスターの TiDB ノード グループを削除します {#delete-a-tidb-node-group-of-the-cluster} +### クラスターの TiDB ノードグループを削除します {#delete-a-tidb-node-group-of-the-cluster} -クラスターの TiDB ノード グループを削除するには、 `dedicated_node_group`リソースの構成を削除し、 `terraform apply`コマンドを使用してリソースを破棄します。 +クラスターの TiDB ノードグループを削除するには、 `dedicated_node_group`リソースの構成を削除し、 `terraform apply`コマンドを使用してリソースを破棄します。 ```shell $ terraform apply diff --git a/tidb-cloud/terraform-use-dedicated-network-container-resource.md b/tidb-cloud/terraform-use-dedicated-network-container-resource.md index 944409bc513c0..ef6e2ae66650f 100644 --- a/tidb-cloud/terraform-use-dedicated-network-container-resource.md +++ b/tidb-cloud/terraform-use-dedicated-network-container-resource.md @@ -1,11 +1,11 @@ --- title: Use the `tidbcloud_dedicated_network_container` Resource -summary: tidbcloud_dedicated_network_container` リソースを使用して、 TiDB Cloud Dedicated ネットワーク コンテナを作成および変更する方法を学習します。 +summary: tidbcloud_dedicated_network_container` リソースを使用して、 TiDB Cloud Dedicated ネットワークコンテナを作成および変更する方法を学習します。 --- # `tidbcloud_dedicated_network_container`リソースを使用する {#use-the-tidbcloud-dedicated-network-container-resource} -このドキュメントでは、 `tidbcloud_dedicated_network_container`リソースを使用して[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)ネットワーク コンテナーを管理する方法について説明します。 +このドキュメントでは、 `tidbcloud_dedicated_network_container`リソースを使用して[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)ネットワークコンテナーを管理する方法について説明します。 ネットワークコンテナは、特定のプロジェクトとリージョンのCIDRブロック（IPアドレス範囲）を定義および管理できる論理ネットワークリソースです。このCIDRブロックは、 TiDB Cloud Dedicatedクラスター用のVPCを作成するために使用され、そのリージョンでVPCピアリングを設定する前に必要です。 @@ -13,9 +13,9 @@ summary: tidbcloud_dedicated_network_container` リソースを使用して、 T `tidbcloud_dedicated_network_container`リソースの機能は次のとおりです。 -- TiDB Cloud Dedicatedネットワーク コンテナーを作成します。 -- TiDB Cloud Dedicated ネットワーク コンテナーをインポートします。 -- TiDB Cloud Dedicated ネットワーク コンテナーを削除します。 +- TiDB Cloud Dedicatedネットワークコンテナーを作成します。 +- TiDB Cloud Dedicated ネットワークコンテナーをインポートします。 +- TiDB Cloud Dedicated ネットワークコンテナーを削除します。 > **Note:** > @@ -27,11 +27,11 @@ summary: tidbcloud_dedicated_network_container` リソースを使用して、 T ## TiDB Cloud Dedicatedネットワークコンテナを作成する {#create-a-tidb-cloud-dedicated-network-container} -`tidbcloud_dedicated_network_container`リソースを使用して、 TiDB Cloud Dedicatedネットワーク コンテナーを作成できます。 +`tidbcloud_dedicated_network_container`リソースを使用して、 TiDB Cloud Dedicatedネットワークコンテナーを作成できます。 -次の例は、TiDB Cloud Dedicated ネットワーク コンテナを作成する方法を示しています。 +次の例は、TiDB Cloud Dedicated ネットワークコンテナを作成する方法を示しています。 -1. TiDB Cloud Dedicated ネットワーク コンテナのディレクトリを作成してそこに入ります。 +1. TiDB Cloud Dedicated ネットワークコンテナのディレクトリを作成してそこに入ります。 2. `network_container.tf`ファイルを作成します。 @@ -61,7 +61,7 @@ summary: tidbcloud_dedicated_network_container` リソースを使用して、 T - `tidbcloud_dedicated_network_container`リソースを使用するには、リソース タイプを`tidbcloud_dedicated_network_container`に設定します。 - リソース名は、必要に応じて定義できます（例： `example` ）。 - 必要な引数の値を取得する方法がわからない場合は、 [リージョンの CIDR を設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)を参照してください。 - - TiDB Cloud Dedicated ネットワーク コンテナ仕様の詳細については、 [tidbcloud_dedicated_network_container (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_network_container)を参照してください。 + - TiDB Cloud Dedicated ネットワークコンテナ仕様の詳細については、 [tidbcloud_dedicated_network_container (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_network_container)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 @@ -138,9 +138,9 @@ summary: tidbcloud_dedicated_network_container` リソースを使用して、 T ## TiDB Cloud Dedicatedネットワークコンテナをインポートする {#import-a-tidb-cloud-dedicated-network-container} -Terraform によって管理されていないTiDB Cloud Dedicated ネットワーク コンテナの場合は、インポートすることで Terraform の管理下に置くことができます。 +Terraform によって管理されていないTiDB Cloud Dedicated ネットワークコンテナの場合は、インポートすることで Terraform の管理下に置くことができます。 -たとえば、Terraform によって作成されていないネットワーク コンテナーをインポートできます。 +たとえば、Terraform によって作成されていないネットワークコンテナーをインポートできます。 1. 新しい`tidbcloud_dedicated_network_container`リソースのインポート ブロックを追加します。 @@ -178,7 +178,7 @@ Terraform によって管理されていないTiDB Cloud Dedicated ネットワ Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed. ``` -これで、インポートしたTiDB Cloud Dedicated ネットワーク コンテナを Terraform で管理できるようになりました。 +これで、インポートしたTiDB Cloud Dedicated ネットワークコンテナを Terraform で管理できるようになりました。 ## TiDB Cloud Dedicatedネットワークコンテナを削除する {#delete-a-tidb-cloud-dedicated-network-container} diff --git a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md index b10806a672ba1..38dc6c589c8a7 100644 --- a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md +++ b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md @@ -1,17 +1,17 @@ --- title: Use `tidbcloud_dedicated_private_endpoint_connection` Resource -summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用して、 TiDB Cloud Dedicated プライベート エンドポイント接続を作成および変更する方法を学習します。 +summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用して、 TiDB Cloud Dedicated プライベートエンドポイント接続を作成および変更する方法を学習します。 --- # `tidbcloud_dedicated_private_endpoint_connection`リソースを使用する {#use-the-tidbcloud-dedicated-private-endpoint-connection-resource} -このドキュメントでは、 `tidbcloud_dedicated_private_endpoint_connection`リソースを使用して[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)プライベート エンドポイント接続を管理する方法について説明します。 +このドキュメントでは、 `tidbcloud_dedicated_private_endpoint_connection`リソースを使用して[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)プライベートエンドポイント接続を管理する方法について説明します。 `tidbcloud_dedicated_private_endpoint_connection`リソースの機能は次のとおりです。 -- TiDB Cloud Dedicated プライベート エンドポイント接続を作成します。 -- TiDB Cloud Dedicated プライベート エンドポイント接続をインポートします。 -- TiDB Cloud Dedicated プライベート エンドポイント接続を削除します。 +- TiDB Cloud Dedicated プライベートエンドポイント接続を作成します。 +- TiDB Cloud Dedicated プライベートエンドポイント接続をインポートします。 +- TiDB Cloud Dedicated プライベートエンドポイント接続を削除します。 > **Note:** > @@ -24,11 +24,11 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 ## TiDB Cloud Dedicatedプライベートエンドポイント接続を作成する {#create-a-tidb-cloud-dedicated-private-endpoint-connection} -`tidbcloud_dedicated_private_endpoint_connection`リソースを使用して、 TiDB Cloud Dedicated プライベート エンドポイント接続を作成できます。 +`tidbcloud_dedicated_private_endpoint_connection`リソースを使用して、 TiDB Cloud Dedicated プライベートエンドポイント接続を作成できます。 -次の例は、 TiDB Cloud Dedicated プライベート エンドポイント接続を作成する方法を示しています。 +次の例は、 TiDB Cloud Dedicated プライベートエンドポイント接続を作成する方法を示しています。 -1. TiDB Cloud Dedicated プライベート エンドポイント接続用のディレクトリを作成し、そこに入ります。 +1. TiDB Cloud Dedicated プライベートエンドポイント接続用のディレクトリを作成し、そこに入ります。 2. `private_endpoint_connection.tf`ファイルを作成します。 @@ -58,7 +58,7 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 - `tidbcloud_dedicated_private_endpoint_connection`リソースを使用するには、リソース タイプを`tidbcloud_dedicated_private_endpoint_connection`に設定します。 - リソース名は必要に応じて定義できます。例： `example` 。 - 必要な引数の値を取得する方法がわからない場合は、 [AWS のプライベートエンドポイント経由でTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 - - TiDB Cloud Dedicated プライベート エンドポイント接続仕様情報を取得するには、 [tidbcloud_private_endpoint_connection (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_private_endpoint_connection)を参照してください。 + - TiDB Cloud Dedicated プライベートエンドポイント接続仕様情報を取得するには、 [tidbcloud_private_endpoint_connection (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_private_endpoint_connection)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 @@ -146,7 +146,7 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 ## TiDB Cloud Dedicatedプライベートエンドポイント接続をインポートする {#import-a-tidb-cloud-dedicated-private-endpoint-connection} -Terraform によって管理されていないTiDB Cloud Dedicated プライベート エンドポイント接続の場合は、インポートすることで Terraform による管理を開始できます。 +Terraform によって管理されていないTiDB Cloud Dedicated プライベートエンドポイント接続の場合は、インポートすることで Terraform による管理を開始できます。 1. 新しい`tidbcloud_dedicated_private_endpoint_connection`リソースのインポート ブロックを追加します。 @@ -184,11 +184,11 @@ Terraform によって管理されていないTiDB Cloud Dedicated プライベ Apply complete! Resources: 1 imported, 0 added, 0 changed, 0 destroyed. ``` - これで、インポートしたTiDB Cloud Dedicated プライベート エンドポイント接続を Terraform を使用して管理できるようになりました。 + これで、インポートしたTiDB Cloud Dedicated プライベートエンドポイント接続を Terraform を使用して管理できるようになりました。 ## TiDB Cloud Dedicated プライベートエンドポイント接続を削除する {#delete-a-tidb-cloud-dedicated-private-endpoint-connection} -TiDB Cloud Dedicated プライベート エンドポイント接続を削除するには、 `tidbcloud_dedicated_private_endpoint_connection`リソースの構成を削除してから、 `terraform apply`コマンドを使用してリソースを破棄します。 +TiDB Cloud Dedicated プライベートエンドポイント接続を削除するには、 `tidbcloud_dedicated_private_endpoint_connection`リソースの構成を削除してから、 `terraform apply`コマンドを使用してリソースを破棄します。 ```shell $ terraform apply diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index 1a0f8b37fc6d0..8a84058c25002 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -1,6 +1,6 @@ --- title: Use the `tidbcloud_import` Resource -summary: tidbcloud_import` リソースを使用してインポート タスクを管理する方法を学習します。 +summary: tidbcloud_import` リソースを使用してインポートタスクを管理する方法を学習します。 --- # `tidbcloud_import`リソースを使用する {#use-the-tidbcloud-import-resource} @@ -9,9 +9,9 @@ summary: tidbcloud_import` リソースを使用してインポート タスク `tidbcloud_import`リソースの機能は次のとおりです。 -- TiDB Cloudクラスターのインポート タスクを作成します。 +- TiDB Cloudクラスターのインポートタスクを作成します。 - ローカルディスクまたは Amazon S3 バケットからデータをインポートします。 -- 進行中のインポート タスクをキャンセルします。 +- 進行中のインポートタスクをキャンセルします。 ## 前提条件 {#prerequisites} @@ -22,13 +22,13 @@ summary: tidbcloud_import` リソースを使用してインポート タスク ## インポートタスクを作成して実行する {#create-and-run-an-import-task} -`tidbcloud_import`リソースを使用して、ローカル インポート タスクまたは Amazon S3 インポート タスクのいずれかを管理できます。 +`tidbcloud_import`リソースを使用して、ローカルインポートタスクまたは Amazon S3 インポートタスクのいずれかを管理できます。 ### ローカルインポートタスクを作成して実行する {#create-and-run-a-local-import-task} > **Note:** > -> ローカル ファイルのインポートは、 TiDB Cloud Starter またはTiDB Cloud Essential クラスターでのみサポートされ、 TiDB Cloud Dedicated クラスターではサポートされません。 +> ローカルファイルのインポートは、 TiDB Cloud Starter またはTiDB Cloud Essential クラスターでのみサポートされ、 TiDB Cloud Dedicated クラスターではサポートされません。 1. インポート用のCSVファイルを作成します。例: @@ -68,7 +68,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。 `csv_format`の詳細は [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)に記載されています。 -3. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 +3. `terraform apply`コマンドを実行してインポートタスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 $ terraform apply ... @@ -83,7 +83,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク tidbcloud_import.example_local: Creating... tidbcloud_import.example_local: Creation complete after 6s [id=781074] -4. `terraform state show tidbcloud_import.${resource-name}`を使用してインポート タスクのステータスを確認します。 +4. `terraform state show tidbcloud_import.${resource-name}`を使用してインポートタスクのステータスを確認します。 $ terraform state show tidbcloud_import.example_local # tidbcloud_import.example_local: @@ -162,7 +162,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク type = "LOCAL" } - ステータスが`COMPLETED`に変わると、インポート タスクが完了したことを示します。 + ステータスが`COMPLETED`に変わると、インポートタスクが完了したことを示します。 6. MySQL CLI でインポートされたデータを確認します。 @@ -214,7 +214,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク source_url = "your_url" } -2. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 +2. `terraform apply`コマンドを実行してインポートタスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 $ terraform apply ... @@ -231,15 +231,15 @@ summary: tidbcloud_import` リソースを使用してインポート タスク tidbcloud_import.example_s3_parquet: Creating... tidbcloud_import.example_s3_parquet: Creation complete after 4s [id=781076] -3. `terraform refresh`と`terraform state show tidbcloud_import.${resource-name}`を使用して、インポート タスクのステータスを更新および確認します。 +3. `terraform refresh`と`terraform state show tidbcloud_import.${resource-name}`を使用して、インポートタスクのステータスを更新および確認します。 ## インポートタスクを更新する {#update-an-import-task} -インポート タスクを更新できません。 +インポートタスクを更新できません。 ## インポートタスクを削除する {#delete-an-import-task} -Terraform の場合、インポート タスクを削除すると、対応する`tidbcloud_import`リソースがキャンセルされます。 +Terraform の場合、インポートタスクを削除すると、対応する`tidbcloud_import`リソースがキャンセルされます。 `COMPLETED`インポートタスクをキャンセルすることはできません。キャンセルした場合は、次の例のように`Delete Error`が返されます。 diff --git a/tidb-cloud/terraform-use-restore-resource.md b/tidb-cloud/terraform-use-restore-resource.md index 70e7289a76efb..804729b3b6a05 100644 --- a/tidb-cloud/terraform-use-restore-resource.md +++ b/tidb-cloud/terraform-use-restore-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_restore` リソースを使用して復元タスクを作成 > **Note:** > -> 小さいノード サイズから同じまたは大きいノード サイズにのみデータを復元できます。 +> 小さいノードサイズから同じまたは大きいノードサイズにのみデータを復元できます。 1. 復元用のディレクトリを作成してそこに入ります。 diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md index 918879cc2d5aa..38f6a8031e966 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -7,7 +7,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess このドキュメントでは、 `tidbcloud_serverless_cluster`リソースを使用して[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターを管理する方法について説明します。 -また、 `tidbcloud_projects`データ ソースを使用して必要な情報を取得する方法も学習します。 +また、 `tidbcloud_projects`データソースを使用して必要な情報を取得する方法も学習します。 `tidbcloud_serverless_cluster`リソースの機能は次のとおりです。 @@ -24,7 +24,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess 各TiDBクラスタはプロジェクトに属します。TiDB Cloud Essentialクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`が指定されていない場合は、デフォルトのプロジェクトが使用されます。 -利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 +利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データソースを使用します。 1. [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md)で作成した`main.tf`ファイルに、次のように`data`と`output`ブロックを追加します。 @@ -50,17 +50,17 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess value = data.tidbcloud_projects.example_project.items } - - `data`ブロックを使用して、データ ソース タイプやデータ ソース名など、 TiDB Cloudのデータ ソースを定義します。 + - `data`ブロックを使用して、データソース タイプやデータソース名など、 TiDB Cloudのデータソースを定義します。 - - プロジェクト データ ソースを使用するには、データ ソース タイプを`tidbcloud_projects`に設定します。 + - プロジェクト データソースを使用するには、データソース タイプを`tidbcloud_projects`に設定します。 - データソース名は必要に応じて定義できます。例： `"example_project"` 。 - - `tidbcloud_projects`データ ソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 + - `tidbcloud_projects`データソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 - - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 + - `output`ブロックを使用して、出力に表示されるデータソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 `output`ブロックはプログラミング言語の戻り値と同様の動作をします。詳細は[Terraformドキュメント](https://www.terraform.io/language/values/outputs)を参照してください。 - リソースとデータ ソースに使用可能なすべての構成を取得するには、 [Terraform プロバイダーの構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 + リソースとデータソースに使用可能なすべての構成を取得するには、 [Terraform プロバイダーの構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index b4c4f893c2d4f..5f534606bb1b8 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -7,7 +7,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta このドキュメントでは、 `tidbcloud_serverless_cluster`リソースを使用して[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)クラスターを管理する方法について説明します。 -また、 `tidbcloud_projects`データ ソースを使用して必要な情報を取得する方法も学習します。 +また、 `tidbcloud_projects`データソースを使用して必要な情報を取得する方法も学習します。 `tidbcloud_serverless_cluster`リソースの機能は次のとおりです。 @@ -24,7 +24,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta 各TiDBクラスタはプロジェクトに属します。TiDB Cloud Starterクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。`project_id`が指定されていない場合は、デフォルトのプロジェクトが使用されます。 -利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 +利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データソースを使用します。 1. [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md)で作成した`main.tf`ファイルに、次のように`data`と`output`ブロックを追加します。 @@ -50,17 +50,17 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta value = data.tidbcloud_projects.example_project.items } - - `data`ブロックを使用して、データ ソース タイプやデータ ソース名など、 TiDB Cloudのデータ ソースを定義します。 + - `data`ブロックを使用して、データソース タイプやデータソース名など、 TiDB Cloudのデータソースを定義します。 - - プロジェクト データ ソースを使用するには、データ ソース タイプを`tidbcloud_projects`に設定します。 + - プロジェクト データソースを使用するには、データソース タイプを`tidbcloud_projects`に設定します。 - データソース名は必要に応じて定義できます。例： `"example_project"` 。 - - `tidbcloud_projects`データ ソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 + - `tidbcloud_projects`データソースの場合、 `page`および`page_size`属性を使用して、チェックするプロジェクトの最大数を制限できます。 - - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 + - `output`ブロックを使用して、出力に表示されるデータソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 `output`ブロックはプログラミング言語の戻り値と同様の動作をします。詳細は[Terraformドキュメント](https://www.terraform.io/language/values/outputs)を参照してください。 - リソースとデータ ソースに使用可能なすべての構成を取得するには、 [Terraform プロバイダー構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 + リソースとデータソースに使用可能なすべての構成を取得するには、 [Terraform プロバイダー構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs)を参照してください。 2. 設定を適用するには、コマンド`terraform apply`を実行してください。続行するには、確認プロンプトで`yes`と入力してください。 diff --git a/tidb-cloud/terraform-use-serverless-export-resource.md b/tidb-cloud/terraform-use-serverless-export-resource.md index 9824cc9d4bf7f..dc916d777296a 100644 --- a/tidb-cloud/terraform-use-serverless-export-resource.md +++ b/tidb-cloud/terraform-use-serverless-export-resource.md @@ -1,17 +1,17 @@ --- title: Use `tidbcloud_serverless_export` Resource -summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを作成および変更する方法を学習します。 +summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを作成および変更する方法を学習します。 --- # `tidbcloud_serverless_export`リソースを使用する {#use-tidbcloud-serverless-export-resource} -このドキュメントでは、 `tidbcloud_serverless_export`リソースを使用して、TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを管理する方法について説明します。 +このドキュメントでは、 `tidbcloud_serverless_export`リソースを使用して、TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを管理する方法について説明します。 `tidbcloud_serverless_export`リソースの機能は次のとおりです。 -- TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを作成します。 -- TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクをインポートします。 -- TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを削除します。 +- TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを作成します。 +- TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクをインポートします。 +- TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを削除します。 > **Note:** > @@ -22,13 +22,13 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud - [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md) v0.4.0以降。 - [TiDB Cloud Starter またはTiDB Cloud Essential クラスターを作成する](/tidb-cloud/create-tidb-cluster-serverless.md) 。 -## TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを作成する {#create-a-data-export-task-for-a-tidb-cloud-starter-or-tidb-cloud-essential-cluster} +## TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを作成する {#create-a-data-export-task-for-a-tidb-cloud-starter-or-tidb-cloud-essential-cluster} -`tidbcloud_serverless_export`リソースを使用して、 TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを作成できます。 +`tidbcloud_serverless_export`リソースを使用して、 TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを作成できます。 1. エクスポート用のディレクトリを作成してそこに入ります。 -2. データ エクスポート タスク用に`export.tf`ファイルを作成します。 +2. データエクスポート タスク用に`export.tf`ファイルを作成します。 以下は`export.tf`ファイルの例です。 @@ -142,9 +142,9 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud } ``` -## TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクをインポートします {#import-a-data-export-task-for-a-tidb-cloud-starter-or-tidb-cloud-essential-cluster} +## TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクをインポートします {#import-a-data-export-task-for-a-tidb-cloud-starter-or-tidb-cloud-essential-cluster} -TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクが Terraform によって管理されていない場合は、インポートすることで Terraform 管理下に置くことができます。 +TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクが Terraform によって管理されていない場合は、インポートすることで Terraform 管理下に置くことができます。 1. 新しい`tidbcloud_serverless_export`リソースのインポート ブロックを追加します。 @@ -182,9 +182,9 @@ TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エ これで、インポートしたエクスポートを Terraform で管理できるようになりました。 -## TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを削除します {#delete-a-data-export-task-for-a-tidb-cloud-starter-or-tidb-cloud-essential-cluster} +## TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを削除します {#delete-a-data-export-task-for-a-tidb-cloud-starter-or-tidb-cloud-essential-cluster} -TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータ エクスポート タスクを削除するには、 `tidbcloud_serverless_export`リソースの構成を削除してから、 `terraform apply`コマンドを使用してリソースを破棄します。 +TiDB Cloud Starter またはTiDB Cloud Essential クラスターのデータエクスポート タスクを削除するには、 `tidbcloud_serverless_export`リソースの構成を削除してから、 `terraform apply`コマンドを使用してリソースを破棄します。 ```shell $ terraform apply diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index 1d8115b97af7a..fadb564bf1a40 100644 --- a/tidb-cloud/terraform-use-sql-user-resource.md +++ b/tidb-cloud/terraform-use-sql-user-resource.md @@ -55,7 +55,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ - `tidbcloud_sql_user`リソースを使用するには、リソース タイプを`tidbcloud_sql_user`に設定します。 - リソース名は必要に応じて定義できます。例： `example` 。 - - TiDB Cloud Starter またはTiDB Cloud Essential クラスターの SQL ユーザーの場合、 `user_name`と組み込みロール`role_readonly`および`role_readwrite`ユーザー プレフィックスで始まる必要があり、 `tidbcloud_serverless_cluster`データ ソースを実行することでユーザー プレフィックスを取得できます。 + - TiDB Cloud Starter またはTiDB Cloud Essential クラスターの SQL ユーザーの場合、 `user_name`と組み込みロール`role_readonly`および`role_readwrite`ユーザー プレフィックスで始まる必要があり、 `tidbcloud_serverless_cluster`データソースを実行することでユーザー プレフィックスを取得できます。 - SQL ユーザー指定情報を取得するには、 [`tidbcloud_sql_user` (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/sql_user)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 diff --git a/tidb-cloud/third-party-monitoring-integrations.md b/tidb-cloud/third-party-monitoring-integrations.md index 34173e2631939..7bb33dee7e276 100644 --- a/tidb-cloud/third-party-monitoring-integrations.md +++ b/tidb-cloud/third-party-monitoring-integrations.md @@ -5,7 +5,7 @@ summary: サードパーティのメトリクス統合の使用方法を学習 # サードパーティのメトリクス統合 {#third-party-metrics-integrations} -TiDB Cloud を次のサードパーティ メトリック サービスと統合して、 TiDB Cloudアラートを受信し、これらのサービスで TiDB クラスターのパフォーマンス メトリックを表示できます。 +TiDB Cloud を次のサードパーティ メトリック サービスと統合して、 TiDB Cloudアラートを受信し、これらのサービスで TiDB クラスターのパフォーマンスメトリックを表示できます。 - [Datadog統合](#datadog-integration) - [PrometheusとGrafanaの統合](#prometheus-and-grafana-integration) diff --git a/tidb-cloud/ticloud-config-create.md b/tidb-cloud/ticloud-config-create.md index 8e43d7fa5cd77..c86cfa6118061 100644 --- a/tidb-cloud/ticloud-config-create.md +++ b/tidb-cloud/ticloud-config-create.md @@ -5,7 +5,7 @@ summary: ticloud config create` のリファレンス。 # ticloud config create {#ticloud-config-create} -ユーザー プロファイル設定を保存する[ユーザープロフィール](/tidb-cloud/cli-reference.md#user-profile)を作成します。 +ユーザープロファイル設定を保存する[ユーザープロフィール](/tidb-cloud/cli-reference.md#user-profile)を作成します。 ```shell ticloud config create [flags] @@ -13,17 +13,17 @@ ticloud config create [flags] > **Note:** > -> ユーザー プロファイルを作成する前に、 [TiDB Cloud APIキーを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)必要があります。 +> ユーザープロファイルを作成する前に、 [TiDB Cloud APIキーを作成する](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)必要があります。 ## 例 {#examples} -対話型モードでユーザー プロファイルを作成します。 +対話型モードでユーザープロファイルを作成します。 ```shell ticloud config create ``` -非対話型モードでユーザー プロファイルを作成します。 +非対話型モードでユーザープロファイルを作成します。 ```shell ticloud config create --profile-name --public-key --private-key diff --git a/tidb-cloud/ticloud-config-delete.md b/tidb-cloud/ticloud-config-delete.md index a111d3229dace..82fe9bc07817b 100644 --- a/tidb-cloud/ticloud-config-delete.md +++ b/tidb-cloud/ticloud-config-delete.md @@ -19,7 +19,7 @@ ticloud config rm [flags] ## 例 {#examples} -ユーザー プロファイルを削除します。 +ユーザープロファイルを削除します。 ```shell ticloud config delete diff --git a/tidb-cloud/ticloud-config-list.md b/tidb-cloud/ticloud-config-list.md index e102054643257..55c1c7f03f5ae 100644 --- a/tidb-cloud/ticloud-config-list.md +++ b/tidb-cloud/ticloud-config-list.md @@ -19,7 +19,7 @@ ticloud config ls [flags] ## 例 {#examples} -利用可能なすべてのユーザー プロファイルを一覧表示します。 +利用可能なすべてのユーザープロファイルを一覧表示します。 ```shell ticloud config list diff --git a/tidb-cloud/ticloud-config-set.md b/tidb-cloud/ticloud-config-set.md index f7d52a14b2481..1beb32cf46ae4 100644 --- a/tidb-cloud/ticloud-config-set.md +++ b/tidb-cloud/ticloud-config-set.md @@ -21,7 +21,7 @@ ticloud config set [flags] > **Note:** > -> 特定のユーザー プロファイルのプロパティを構成する場合は、 `-P`フラグを追加し、コマンドで対象のユーザー プロファイル名を指定できます。 +> 特定のユーザープロファイルのプロパティを構成する場合は、 `-P`フラグを追加し、コマンドで対象のユーザープロファイル名を指定できます。 ## 例 {#examples} diff --git a/tidb-cloud/ticloud-config-use.md b/tidb-cloud/ticloud-config-use.md index 1643e6938ec0d..dae4c77302931 100644 --- a/tidb-cloud/ticloud-config-use.md +++ b/tidb-cloud/ticloud-config-use.md @@ -13,7 +13,7 @@ ticloud config use [flags] ## 例 {#examples} -`test`プロファイルをアクティブ ユーザー プロファイルとして設定します。 +`test`プロファイルをアクティブ ユーザープロファイルとして設定します。 ```shell ticloud config use test diff --git a/tidb-cloud/ticloud-import-cancel.md b/tidb-cloud/ticloud-import-cancel.md index 832cee92604a9..a769ef5978f20 100644 --- a/tidb-cloud/ticloud-import-cancel.md +++ b/tidb-cloud/ticloud-import-cancel.md @@ -13,13 +13,13 @@ ticloud serverless import cancel [flags] ## 例 {#examples} -対話モードでインポート タスクをキャンセルします。 +対話モードでインポートタスクをキャンセルします。 ```shell ticloud serverless import cancel ``` -非対話型モードでインポート タスクをキャンセルします。 +非対話型モードでインポートタスクをキャンセルします。 ```shell ticloud serverless import cancel --cluster-id --import-id @@ -32,9 +32,9 @@ ticloud serverless import cancel --cluster-id --import-id --import-id @@ -39,7 +39,7 @@ ticloud serverless import describe --cluster-id --import-id ``` -指定されたクラスターのインポート タスクを JSON 形式で一覧表示します。 +指定されたクラスターのインポートタスクを JSON 形式で一覧表示します。 ```shell ticloud serverless import list --cluster-id --output json diff --git a/tidb-cloud/ticloud-import-start.md b/tidb-cloud/ticloud-import-start.md index 1df77d79e0e2f..67a19b905982e 100644 --- a/tidb-cloud/ticloud-import-start.md +++ b/tidb-cloud/ticloud-import-start.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/ticloud-import-start-local','/ja/tidbcloud/ticloud-impo # ticloud serverless import start {#ticloud-serverless-import-start} -データ インポート タスクを開始します。 +データインポートタスクを開始します。 ```shell ticloud serverless import start [flags] @@ -20,17 +20,17 @@ ticloud serverless import create [flags] > **Note:** > -> 現在、1 つのローカル インポート タスクにつき 1 つの CSV ファイルのみをインポートできます。 +> 現在、1 つのローカルインポートタスクにつき 1 つの CSV ファイルのみをインポートできます。 ## 例 {#examples} -対話型モードでインポート タスクを開始します。 +対話型モードでインポートタスクを開始します。 ```shell ticloud serverless import start ``` -非対話型モードでローカル インポート タスクを開始します。 +非対話型モードでローカルインポートタスクを開始します。 ```shell ticloud serverless import start --local.file-path --cluster-id --file-type --local.target-database --local.target-table @@ -42,25 +42,25 @@ ticloud serverless import start --local.file-path --cluster-id --cluster-id --file-type --local.target-database --local.target-table --local.concurrency 10 ``` -カスタム CSV 形式でローカル インポート タスクを開始します。 +カスタム CSV 形式でローカルインポートタスクを開始します。 ```shell ticloud serverless import start --local.file-path --cluster-id --file-type CSV --local.target-database --local.target-table --csv.separator \" --csv.delimiter \' --csv.backslash-escape=false --csv.trim-last-separator=true ``` -非対話型モードで S3 インポート タスクを開始します。 +非対話型モードで S3 インポートタスクを開始します。 ```shell ticloud serverless import start --source-type S3 --s3.uri --cluster-id --file-type --s3.role-arn ``` -非対話型モードで GCS インポート タスクを開始します。 +非対話型モードで GCS インポートタスクを開始します。 ```shell ticloud serverless import start --source-type GCS --gcs.uri --cluster-id --file-type --gcs.service-account-key ``` -非対話型モードで Azure BLOB インポート タスクを開始します。 +非対話型モードで Azure BLOB インポートタスクを開始します。 ```shell ticloud serverless import start --source-type AZURE_BLOB --azblob.uri --cluster-id --file-type --azblob.sas-token @@ -74,7 +74,7 @@ ticloud serverless import start --source-type AZURE_BLOB --azblob.uri .blob.core.windows.net//`形式で指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | -| --gcs.service-account-key string | GCS の base64 でエンコードされたサービス アカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | +| --gcs.service-account-key string | GCS の base64 でエンコードされたサービスアカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --gcs.uri string | GCS URIを`gcs:///`形式で指定します。ソースタイプがGCSの場合は必須です。 | はい | 非対話型モードでのみ動作します。 | | | | | --s3.access-key-id string | Amazon S3のアクセスキーIDを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | | --s3.role-arn string | Amazon S3のロールARNを指定します。`s3.role-arn`と[ `s3.access-key-id` , `s3.secret-access-key` ]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | | | @@ -83,9 +83,9 @@ ticloud serverless import start --source-type AZURE_BLOB --azblob.uri | フラグ | 説明 | 必須 | 注記 | | -------------------- | ------------------- | --- | ------------------------------------ | | -c, --cluster-id 文字列 | クラスター ID。 | はい | 非対話型モードでのみ動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md index 2c2fdb3d5f5ca..91afd14fde202 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md @@ -52,9 +52,9 @@ ticloud serverless audit-log config update -c --enabled=false | --cloud-storage string | クラウドストレージ`"GCS"` 。 `"AZURE_BLOB"` `"OSS"`オプション: `"TIDB_CLOUD"` `"S3"` | いいえ | 非対話型モードでのみ動作します。 | | -c, --cluster-id string | 更新するクラスターの ID。 | はい | 非対話型モードでのみ動作します。 | | --enabled | データベース監査ログを有効または無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| --gcs.service-account-key string | Google Cloud Storage の Base64 でエンコードされたサービス アカウント キー。 | いいえ | 非対話型モードでのみ動作します。 | +| --gcs.service-account-key string | Google Cloud Storage の Base64 でエンコードされたサービスアカウント キー。 | いいえ | 非対話型モードでのみ動作します。 | | --gcs.uri string | `gs:///`形式の Google Cloud Storage URI。 | いいえ | 非対話型モードでのみ動作します。 | -| --oss.access-key-id string | Alibaba Cloud Object Storage Service (OSS) のアクセス キー ID。 | いいえ | 非対話型モードでのみ動作します。 | +| --oss.access-key-id string | Alibaba Cloud Object Storage Service (OSS) のアクセスキー ID。 | いいえ | 非対話型モードでのみ動作します。 | | --oss.access-key-secret string | Alibaba Cloud OSS のアクセスキーシークレット。 | いいえ | 非対話型モードでのみ動作します。 | | --oss.uri string | `oss:///`形式の Alibaba Cloud OSS URI。 | いいえ | 非対話型モードでのみ動作します。 | | --rotation-interval-minutes int32 | ローテーション間隔（分）。有効な範囲： `[10, 1440]` 。 | いいえ | 非対話型モードでのみ動作します。 | @@ -64,15 +64,15 @@ ticloud serverless audit-log config update -c --enabled=false | --s3.secret-access-key string | Amazon S3のシークレットアクセスキー。`--s3.role-arn`のいずれか、または`--s3.access-key-id`と`--s3.secret-access-key`の両方を設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.uri string | `s3:///`形式の Amazon S3 URI。 | いいえ | 非対話型モードでのみ動作します。 | | --unredacted | データベース監査ログを秘匿化解除または秘匿化します。 | いいえ | 非対話型モードでのみ動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-download.md b/tidb-cloud/ticloud-serverless-audit-log-download.md index bd61ed3495be8..f9745fba64ff8 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-download.md +++ b/tidb-cloud/ticloud-serverless-audit-log-download.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log download` のリファレンス。 # ticloud serverless audit-log download {#ticloud-serverless-audit-log-download} -TiDB Cloud Essential クラスターからデータベース監査ログ ファイルをダウンロードします。 +TiDB Cloud Essential クラスターからデータベース監査ログファイルをダウンロードします。 ```shell ticloud serverless audit-log download [flags] @@ -33,17 +33,17 @@ ticloud serverless audit-log download -c --start-date | --start-date | ダウンロードする監査ログの開始日（ `YYYY-MM-DD`の形式、例： `2025-01-01` ）。 | はい | 非対話型モードでのみ動作します。 | | --end-date | ダウンロードする監査ログの終了日（ `YYYY-MM-DD`の形式、例： `2025-01-01` ）。 | はい | 非対話型モードでのみ動作します。 | | --output-path | 監査ログをダウンロードするパス。指定しない場合は、ログは現在のディレクトリにダウンロードされます。 | いいえ | 非対話型モードでのみ動作します。 | -| --concurrency int | 同時ダウンロード数。デフォルト値は`3`です。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | -| --force | 確認なしで監査ログをダウンロードします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| --concurrency int | 同時ダウンロード数。デフォルト値は`3`です。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | +| --force | 確認なしで監査ログをダウンロードします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md index 7e04165531201..a5c8aaa978c1d 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log filter-rule create` のリファレンス # ticloud serverless audit-log filter-rule create {#ticloud-serverless-audit-log-filter-rule-create} -TiDB Cloud Essential クラスターの監査ログ フィルター ルールを作成します。 +TiDB Cloud Essential クラスターの監査ログフィルタールールを作成します。 ```shell ticloud serverless audit-log filter-rule create [flags] @@ -13,19 +13,19 @@ ticloud serverless audit-log filter-rule create [flags] ## 例 {#examples} -対話モードでフィルタ ルールを作成します。 +対話モードでフィルタルールを作成します。 ```shell ticloud serverless audit-log filter-rule create ``` -非対話型モードですべての監査ログをキャプチャするためのフィルター ルールを作成します。 +非対話型モードですべての監査ログをキャプチャするためのフィルタールールを作成します。 ```shell ticloud serverless audit-log filter-rule create --cluster-id --display-name --rule '{"users":["%@%"],"filters":[{}]}' ``` -非対話型モードで、テーブル`test.t` `QUERY`および`EXECUTE`イベントと、すべてのテーブルの`QUERY`イベントをキャプチャするフィルター ルールを作成します。 +非対話型モードで、テーブル`test.t` `QUERY`および`EXECUTE`イベントと、すべてのテーブルの`QUERY`イベントをキャプチャするフィルタールールを作成します。 ```shell ticloud serverless audit-log filter-rule create --cluster-id --display-name --rule '{"users":["%@%"],"filters":[{"classes":["QUERY","EXECUTE"],"tables":["test.t"]},{"classes":["QUERY"]}]}' @@ -36,17 +36,17 @@ ticloud serverless audit-log filter-rule create --cluster-id --disp | フラグ | 説明 | 必須 | 注記 | | -------------------- | ------------------------------------------------------------------------------------- | --- | ------------------------------------ | | -c, --cluster-id string | クラスターの ID。 | はい | 非対話型モードでのみ動作します。 | -| --display-name string | フィルター ルールの表示名。 | はい | 非対話型モードでのみ動作します。 | +| --display-name string | フィルタールールの表示名。 | はい | 非対話型モードでのみ動作します。 | | --rule string | フィルタールール式。フィルターテンプレートを表示するには`ticloud serverless audit-log filter-rule template`を使用します。 | はい | 非対話型モードでのみ動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md index a1221f5f30fbb..8c9ae3a21ba50 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log filter-rule delete` のリファレンス # ticloud serverless audit-log filter-rule delete {#ticloud-serverless-audit-log-filter-rule-delete} -TiDB Cloud Essential クラスターの監査ログ フィルター ルールを削除します。 +TiDB Cloud Essential クラスターの監査ログフィルタールールを削除します。 ```shell ticloud serverless audit-log filter-rule delete [flags] @@ -13,13 +13,13 @@ ticloud serverless audit-log filter-rule delete [flags] ## 例 {#examples} -対話モードで監査ログ フィルタ ルールを削除します。 +対話モードで監査ログフィルタルールを削除します。 ```shell ticloud serverless audit-log filter-rule delete ``` -非対話型モードで監査ログ フィルタ ルールを削除します。 +非対話型モードで監査ログフィルタルールを削除します。 ```shell ticloud serverless audit-log filter-rule delete --cluster-id --filter-rule-id @@ -30,17 +30,17 @@ ticloud serverless audit-log filter-rule delete --cluster-id --filt | フラグ | 説明 | 必須 | 注記 | | -------------------- | ------------------- | --- | ------------------------------------ | | -c, --cluster-id string | クラスターの ID。 | はい | 非対話型モードでのみ動作します。 | -| --filter-rule-id string | フィルター ルールの ID。 | はい | 非対話型モードでのみ動作します。 | -| --force | 確認なしで削除します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| --filter-rule-id string | フィルタールールの ID。 | はい | 非対話型モードでのみ動作します。 | +| --force | 確認なしで削除します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md index a8d2f81f6618d..650b26cb87d9b 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log filter-rule describe` のリファレン # ticloud serverless audit-log filter-rule describe {#ticloud-serverless-audit-log-filter-rule-describe} -TiDB Cloud Essential クラスターの監査ログ フィルター ルールについて説明します。 +TiDB Cloud Essential クラスターの監査ログフィルタールールについて説明します。 ```shell ticloud serverless audit-log filter-rule describe [flags] @@ -13,13 +13,13 @@ ticloud serverless audit-log filter-rule describe [flags] ## 例 {#examples} -インタラクティブ モードで監査ログ フィルタ ルールを記述します。 +インタラクティブモードで監査ログフィルタルールを記述します。 ```shell ticloud serverless audit-log filter-rule describe ``` -非対話型モードで監査ログ フィルタ ルールを記述します。 +非対話型モードで監査ログフィルタルールを記述します。 ```shell ticloud serverless audit-log filter-rule describe --cluster-id --filter-rule-id @@ -30,16 +30,16 @@ ticloud serverless audit-log filter-rule describe --cluster-id --fi | フラグ | 説明 | 必須 | 注記 | | -------------------- | ------------------- | --- | ------------------------------------ | | -c, --cluster-id string | クラスターの ID。 | はい | 非対話型モードでのみ動作します。 | -| --filter-rule-id string | フィルター ルールの ID。 | はい | 非対話型モードでのみ動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| --filter-rule-id string | フィルタールールの ID。 | はい | 非対話型モードでのみ動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md index 71ac2ec93915c..22e7a0cb6cc08 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log filter-rule list` のリファレンス。 # ticloud serverless audit-log filter-rule list {#ticloud-serverless-audit-log-filter-rule-list} -TiDB Cloud Essential クラスターの監査ログ フィルター ルールを一覧表示します。 +TiDB Cloud Essential クラスターの監査ログフィルタールールを一覧表示します。 ```shell ticloud serverless audit-log filter-rule list [flags] @@ -13,19 +13,19 @@ ticloud serverless audit-log filter-rule list [flags] ## 例 {#examples} -対話モードですべての監査ログ フィルタ ルールを一覧表示します。 +対話モードですべての監査ログフィルタルールを一覧表示します。 ```shell ticloud serverless audit-log filter-rule list ``` -非対話型モードですべての監査ログ フィルタ ルールを一覧表示します。 +非対話型モードですべての監査ログフィルタルールを一覧表示します。 ```shell ticloud serverless audit-log filter-rule list -c ``` -非対話型モードで JSON 形式のすべての監査ログ フィルター ルールを一覧表示します。 +非対話型モードで JSON 形式のすべての監査ログフィルタールールを一覧表示します。 ```shell ticloud serverless audit-log filter-rule list -c -o json @@ -36,16 +36,16 @@ ticloud serverless audit-log filter-rule list -c -o json | フラグ | 説明 | 必須 | 注記 | | -------------------- | ------------------------------------------------------------------------- | --- | ------------------------------------ | | -c, --cluster-id 文字列 | クラスターの ID。 | いいえ | 非対話型モードでのみ動作します。 | -| -o, --output | 出力形式を指定します。有効な値は`human` （デフォルト）または`json`です。完全な結果を得るには、 `json`形式を使用してください。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -o, --output | 出力形式を指定します。有効な値は`human` （デフォルト）または`json`です。完全な結果を得るには、 `json`形式を使用してください。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md index 8317cdc708034..962017dbee3f1 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log filter-rule template` のリファレン # ticloud serverless audit-log filter-rule template {#ticloud-serverless-audit-log-filter-rule-template} -TiDB Cloud Essential クラスターの監査ログ フィルター ルール テンプレートを表示します。 +TiDB Cloud Essential クラスターの監査ログフィルタールール テンプレートを表示します。 ```shell ticloud serverless audit-log filter-rule template [flags] @@ -30,15 +30,15 @@ ticloud serverless audit-log filter-rule template --cluster-id | フラグ | 説明 | 必須 | 注記 | | -------------------- | ------------------- | --- | ------------------------------------ | | -c, --cluster-id 文字列 | クラスターの ID。 | いいえ | 非対話型モードでのみ動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile 文字列 | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md index dd36ade197d1c..374c7a5561e46 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md @@ -5,7 +5,7 @@ summary: ticloud serverless audit-log filter-rule update` のリファレンス # ticloud serverless audit-log filter-rule update {#ticloud-serverless-audit-log-filter-rule-update} -TiDB Cloud Essential クラスターの監査ログ フィルター ルールを更新します。 +TiDB Cloud Essential クラスターの監査ログフィルタールールを更新します。 ```shell ticloud serverless audit-log filter-rule update [flags] @@ -13,7 +13,7 @@ ticloud serverless audit-log filter-rule update [flags] ## 例 {#examples} -対話モードで監査ログ フィルタ ルールを更新します。 +対話モードで監査ログフィルタルールを更新します。 ```shell ticloud serverless audit-log filter-rule update @@ -25,13 +25,13 @@ ticloud serverless audit-log filter-rule update ticloud serverless audit-log filter-rule update --cluster-id --filter-rule-id --enabled ``` -非対話型モードで監査ログ フィルタ ルールを無効にする: +非対話型モードで監査ログフィルタルールを無効にする: ```shell ticloud serverless audit-log filter-rule update --cluster-id --filter-rule-id --enabled=false ``` -非対話型モードで監査ログ フィルタ ルールのフィルタを更新します。 +非対話型モードで監査ログフィルタルールのフィルタを更新します。 ```shell ticloud serverless audit-log filter-rule update --cluster-id --filter-rule-id --rule '{"users":["%@%"],"filters":[{"classes":["QUERY"],"tables":["test.t"]}]}' @@ -42,19 +42,19 @@ ticloud serverless audit-log filter-rule update --cluster-id --filt | フラグ | 説明 | 必須 | 注記 | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | ------------------------------------ | | -c, --cluster-id string | クラスターの ID。 | はい | 非対話型モードでのみ動作します。 | -| --display-name string | フィルター ルールの表示名。 | いいえ | 非対話型モードでのみ動作します。 | -| --enabled | フィルター ルールを有効または無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| --filter-rule-id string | フィルター ルールの ID。 | はい | 非対話型モードでのみ動作します。 | +| --display-name string | フィルタールールの表示名。 | いいえ | 非対話型モードでのみ動作します。 | +| --enabled | フィルタールールを有効または無効にします。 | いいえ | 非対話型モードでのみ動作します。 | +| --filter-rule-id string | フィルタールールの ID。 | はい | 非対話型モードでのみ動作します。 | | --rule string | フィルタルール式を完了します。フィルタテンプレートを表示するには[`ticloud serverless audit-log filter template`](/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md)を使用します。 | いいえ | 非対話型モードでのみ動作します。 | -| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} | フラグ | 説明 | 必須 | 注記 | | ----------------- | ------------------------- | --- | ------------------------------------ | -| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -D, --debug | デバッグ モードを有効にします。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | | --no-color | カラー出力を無効にします。 | いいえ | 非対話型モードでのみ動作します。 | -| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | +| -P, --profile string | 構成ファイルから使用するプロファイルを指定します。 | いいえ | インタラクティブモードと非インタラクティブモードの両方で動作します。 | ## フィードバック {#feedback} diff --git a/tidb-cloud/ticloud-serverless-export-cancel.md b/tidb-cloud/ticloud-serverless-export-cancel.md index de3efbb348194..6bb7300323f89 100644 --- a/tidb-cloud/ticloud-serverless-export-cancel.md +++ b/tidb-cloud/ticloud-serverless-export-cancel.md @@ -5,7 +5,7 @@ summary: ticloud serverless export cancel` の参照。 # ticloud serverless export cancel {#ticloud-serverless-export-cancel} -データ エクスポート タスクをキャンセルします。 +データエクスポート タスクをキャンセルします。 ```shell ticloud serverless export cancel [flags] diff --git a/tidb-cloud/ticloud-serverless-export-create.md b/tidb-cloud/ticloud-serverless-export-create.md index 5226e0544bfa7..7cdc97b226d48 100644 --- a/tidb-cloud/ticloud-serverless-export-create.md +++ b/tidb-cloud/ticloud-serverless-export-create.md @@ -19,7 +19,7 @@ ticloud serverless export create [flags] ticloud serverless export create ``` -非対話型モードでTiDB Cloud Starter またはTiDB Cloud Essential クラスターからローカル ファイルにデータをエクスポートします。 +非対話型モードでTiDB Cloud Starter またはTiDB Cloud Essential クラスターからローカルファイルにデータをエクスポートします。 ```shell ticloud serverless export create -c --filter @@ -75,7 +75,7 @@ ticloud serverless export create -c --sql 'select * from database.t | --s3.secret-access-key string | Amazon S3のシークレットアクセスキーを指定します。s3.role-arnと[s3.access-key-id, s3.secret-access-key]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --s3.role-arn string | Amazon S3のロールARNを指定します。s3.role-arnと[s3.access-key-id、s3.secret-access-key]のいずれか1つだけを設定する必要があります。 | いいえ | 非対話型モードでのみ動作します。 | | --gcs.uri string | GCS URIを`gcs:///`形式で指定します。ターゲットタイプがGCSの場合は必須です。 | いいえ | 非対話型モードでのみ動作します。 | -| --gcs.service-account-key string | GCS の base64 でエンコードされたサービス アカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | +| --gcs.service-account-key string | GCS の base64 でエンコードされたサービスアカウント キーを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | --azblob.uri string | Azure BLOB URI を`azure://.blob.core.windows.net//`形式で指定します。ターゲット タイプが AZURE_BLOB の場合に必須です。 | いいえ | 非対話型モードでのみ動作します。 | | --azblob.sas-token string | Azure Blob の SAS トークンを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | --oss.uri string | Alibaba Cloud OSS URIを`oss:///`形式で指定します。エクスポート`target-type`が`"OSS"`の場合に必須です。 | いいえ | 非対話型モードでのみ動作します。 | diff --git a/tidb-cloud/ticloud-serverless-export-download.md b/tidb-cloud/ticloud-serverless-export-download.md index 137232dad7022..3a9368e39a043 100644 --- a/tidb-cloud/ticloud-serverless-export-download.md +++ b/tidb-cloud/ticloud-serverless-export-download.md @@ -13,7 +13,7 @@ ticloud serverless export download [flags] ## 例 {#examples} -エクスポートされたデータをインタラクティブ モードでダウンロードします。 +エクスポートされたデータをインタラクティブモードでダウンロードします。 ```shell ticloud serverless export download diff --git a/tidb-cloud/ticloud-serverless-export-list.md b/tidb-cloud/ticloud-serverless-export-list.md index ba190ee60e726..166beca664aa3 100644 --- a/tidb-cloud/ticloud-serverless-export-list.md +++ b/tidb-cloud/ticloud-serverless-export-list.md @@ -5,7 +5,7 @@ summary: ticloud serverless export list` のリファレンス。 # ticloud serverless export list {#ticloud-serverless-export-list} -TiDB Cloud Starter およびTiDB Cloud Essential クラスターのデータ エクスポート タスクを一覧表示します。 +TiDB Cloud Starter およびTiDB Cloud Essential クラスターのデータエクスポート タスクを一覧表示します。 ```shell ticloud serverless export list [flags] diff --git a/tidb-cloud/ticloud-serverless-update.md b/tidb-cloud/ticloud-serverless-update.md index 5a12d5223772f..5c9cf030d91e0 100644 --- a/tidb-cloud/ticloud-serverless-update.md +++ b/tidb-cloud/ticloud-serverless-update.md @@ -40,7 +40,7 @@ ticloud serverless update -c --labels "{\"label1\":\"value1\"}" | -c, --cluster-id string | クラスターの ID を指定します。 | はい | 非対話型モードでのみ動作します。 | | | -n, --display-name string | クラスターの新しい名前を指定します。 | いいえ | 非対話型モードでのみ動作します。 | 。 | | --labels string | クラスターの新しいラベルを指定します。 | いいえ | 非対話型モードでのみ動作します。 | | -| --disable-public-endpoint | クラスターのパブリック エンドポイントを無効にします。 | いいえ | 非対話型モードでのみ動作します。 | | +| --disable-public-endpoint | クラスターのパブリックエンドポイントを無効にします。 | いいえ | 非対話型モードでのみ動作します。 | | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | 非対話型モードと対話型モードの両方で動作します。 | | ## 継承されたフラグ {#inherited-flags} diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index e752ef1fb3a5f..05a587655e0e1 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -5,7 +5,7 @@ summary: TiDB Cloudでクラスターを監査する方法について説明し # TiDB Cloud Dedicatedデータベース監査ログ (Preview) {#tidb-cloud-dedicated-database-audit-logging} -TiDB Cloud は、実行された SQL ステートメントなど、データベースへのユーザー アクセス アクティビティを記録する監査ログ機能を提供します。 +TiDB Cloud は、実行された SQL ステートメントなど、データベースへのユーザーアクセス アクティビティを記録する監査ログ機能を提供します。 > **Note:** > @@ -18,7 +18,7 @@ TiDB Cloud は、実行された SQL ステートメントなど、データベ > > このドキュメントは、監査ログ機能のパブリックプレビュー版にのみ適用されます。以前のバージョンのデータベース監査ログを使用している場合は、 [TiDB Cloud Database Audit Logging (Legacy)](/tidb-cloud/tidb-cloud-auditing-legacy.md)を参照してください。 -組織のユーザー アクセス ポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログを定期的に分析することがセキュリティのベスト プラクティスです。 +組織のユーザーアクセスポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログを定期的に分析することがセキュリティのベストプラクティスです。 監査ログ機能は**デフォルトで無効に**なっています。クラスターを監査するには、まず監査ログを有効にし、次に監査フィルタルールを指定する必要があります。 @@ -67,9 +67,9 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の AWS > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 - 2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **DB Audit Logging**をクリックします。 + 2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **DB Audit Logging**をクリックします。 3. **DB Audit Logging**ページで、右上隅の**[有効化]**をクリックします。 @@ -107,7 +107,7 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の AWS #### ステップ3. 監査ログを有効にする {#step-3-enable-audit-logging} -TiDB Cloudコンソールで、 TiDB Cloudアカウント ID と外部 ID 値を取得した**[データベース監査ログストレージ設定]**ダイアログ ボックスに戻り、次の手順を実行します。 +TiDB Cloudコンソールで、 TiDB Cloudアカウント ID と外部 ID 値を取得した**[データベース監査ログストレージ設定]**ダイアログボックスに戻り、次の手順を実行します。 1. **Bucket URI**フィールドに、監査ログファイルが書き込まれる S3 バケットの URI を入力します。 @@ -134,15 +134,15 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の Googl #### ステップ2. GCSアクセスを構成する {#step-2-configure-gcs-access} -1. 監査ログを有効にする TiDB クラスタの Google Cloud サービス アカウント ID を取得します。 +1. 監査ログを有効にする TiDB クラスタの Google Cloud サービスアカウント ID を取得します。 1. TiDB Cloudコンソールで、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 - 2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **DB Audit Logging**をクリックします。 + 2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **DB Audit Logging**をクリックします。 3. **DB Audit Logging**ページで、右上隅の**[有効化]**をクリックします。 @@ -161,17 +161,17 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の Googl 4. パネルで、 **ADD PRINCIPAL**をクリックします。 - プリンシパルを追加するためのダイアログ ボックスが表示されます。 + プリンシパルを追加するためのダイアログボックスが表示されます。 -5. ダイアログ ボックスで、次の手順を実行します。 +5. ダイアログボックスで、次の手順を実行します。 - 1. **New Principals**フィールドに、TiDB クラスタの Google Cloud サービス アカウント ID を貼り付けます。 - 2. **[ロール]**ドロップダウン リストで、ターゲット TiDB クラスターのロールを選択します。 + 1. **New Principals**フィールドに、TiDB クラスタの Google Cloud サービスアカウント ID を貼り付けます。 + 2. **[ロール]**ドロップダウンリストで、ターゲット TiDB クラスターのロールを選択します。 3. **[保存]**をクリックします。 #### ステップ3. 監査ログを有効にする {#step-3-enable-audit-logging} -TiDB Cloudコンソールで、 Google Cloud サービス アカウント ID を取得した**[データベース監査ログストレージ設定]**ダイアログ ボックスに戻り、次の手順を実行します。 +TiDB Cloudコンソールで、 Google Cloud サービスアカウント ID を取得した**[データベース監査ログストレージ設定]**ダイアログボックスに戻り、次の手順を実行します。 1. **Bucket URI**フィールドに、完全な GCS バケット名を入力します。 @@ -202,7 +202,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 > **Tip:** > - > 左側のナビゲーション ペインが非表示になっている場合は、左上隅のメニュー ボタンをクリックして表示を切り替えます。 + > 左側のナビゲーションペインが非表示になっている場合は、左上隅のメニュー ボタンをクリックして表示を切り替えます。 2. 選択したストレージアカウントのナビゲーション ウィンドウで、 **Data storage > Containers**をクリックし、 **+ Container**をクリックして**New container**ウィンドウを開きます。 @@ -219,7 +219,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 2. 表示された**Generate SAS**ペインで、**Signing method**として**Account key**を選択します。 - 3. **[権限]**ドロップダウン リストで、 **[読み取り]** 、 **[書き込み]** 、 **[作成]**を選択して、監査ログ ファイルの書き込みを許可します。 + 3. **[権限]**ドロップダウンリストで、 **[読み取り]** 、 **[書き込み]** 、 **[作成]**を選択して、監査ログファイルの書き込みを許可します。 4. **[開始] フィールド**と**[有効期限]**フィールドで、SAS トークンの有効期間を指定します。 @@ -239,9 +239,9 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 -2. ターゲット クラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[設定]** > **DB Audit Logging**をクリックします。 +2. ターゲットクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[設定]** > **DB Audit Logging**をクリックします。 3. **DB Audit Logging**ページで、右上隅の**[有効化]**をクリックします。 @@ -282,9 +282,9 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 監査ログを有効にした後、監査フィルタルールを指定して、どのユーザーアクセスイベントをキャプチャし、監査ログに書き込むかを制御する必要があります。フィルタルールが指定されていない場合、 TiDB Cloudは何もログに記録しません。 -クラスターの監査フィルター ルールを指定するには、次の手順を実行します。 +クラスターの監査フィルタールールを指定するには、次の手順を実行します。 -1. **DB Audit Logging**ページで、 **Audit Filters**セクションの**Add Filter Rule**をクリックして、監査フィルタ ルールを追加します。 +1. **DB Audit Logging**ページで、 **Audit Filters**セクションの**Add Filter Rule**をクリックして、監査フィルタルールを追加します。 2. **Add Filter Rule**ダイアログで、次の項目を設定します。 @@ -300,13 +300,13 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 ## 監査ログを確認する {#view-audit-logs} -デフォルトでは、 TiDB Cloud はデータベース監査ログ ファイルをストレージサービスに保存するため、ストレージサービスから監査ログにアクセスする必要があります。 +デフォルトでは、 TiDB Cloud はデータベース監査ログファイルをストレージサービスに保存するため、ストレージサービスから監査ログにアクセスする必要があります。 > **Note:** > -> 監査ログ ファイルをTiDB Cloudに保存することを要求して選択した場合は、**Database Audit Logging**ページの**Audit Log Access**セクションからダウンロードできます。 +> 監査ログファイルをTiDB Cloudに保存することを要求して選択した場合は、**Database Audit Logging**ページの**Audit Log Access**セクションからダウンロードできます。 -TiDB Cloud監査ログは、クラスター ID、ノード ID、およびログ作成日が完全修飾ファイルパスに組み込まれた読み取り可能なテキスト ファイルです。 +TiDB Cloud監査ログは、クラスター ID、ノード ID、およびログ作成日が完全修飾ファイルパスに組み込まれた読み取り可能なテキストファイルです。 たとえば、 `13796619446086334065/tidb-0/tidb-audit-2022-04-21T18-16-29.529.log` 。この例では、 `13796619446086334065`クラスター ID を示し、 `tidb-0`ノード ID を示します。 @@ -315,7 +315,7 @@ TiDB Cloud監査ログは、クラスター ID、ノード ID、およびログ クラスターの監査が不要になった場合は、次の手順を実行します。 1. TiDB Cloudコンソールで [**My TiDB**](https://tidbcloud.com/tidbs) ページに移動し、ターゲットの TiDB Cloud Dedicated クラスターの名前をクリックします。 -2. 左側のナビゲーション ペインで、**Settings** > **DB Audit Logging** をクリックします。 +2. 左側のナビゲーションペインで、**Settings** > **DB Audit Logging** をクリックします。 3. **Database Audit Logging** セクションで、**Settings** の横にある **...** をクリックし、**Disable** をクリックします。 > **Note:** diff --git a/tidb-cloud/tidb-cloud-billing-dm.md b/tidb-cloud/tidb-cloud-billing-dm.md index 0b74452a20eae..3e35d7e59ae8d 100644 --- a/tidb-cloud/tidb-cloud-billing-dm.md +++ b/tidb-cloud/tidb-cloud-billing-dm.md @@ -39,11 +39,11 @@ TiDB Cloudは、データ移行のキャパシティをレプリケーション AWS PrivateLink または VPC ピアリング接続を使用しており、ソースデータベースと TiDB ノードが同じリージョンまたは同じアベイラビリティーゾーン (AZ) にない場合は、クロスリージョントラフィック料金とクロス AZ トラフィック料金の 2 つの追加トラフィック料金が発生することに注意してください。 -- ソース データベースと TiDB ノードが同じリージョンにない場合、データ移行ジョブがソース データベースからデータを収集するときに、リージョン間のトラフィック料金が発生します。 +- ソースデータベースと TiDB ノードが同じリージョンにない場合、データ移行ジョブがソースデータベースからデータを収集するときに、リージョン間のトラフィック料金が発生します。 ![Cross-region traffic charges](/media/tidb-cloud/dm-billing-cross-region-fees.png) -- ソース データベースと TiDB ノードが同じリージョン内であっても異なる AZ にある場合、データ移行ジョブがソース データベースからデータを収集するときに、AZ 間のトラフィック料金が発生します。 +- ソースデータベースと TiDB ノードが同じリージョン内であっても異なる AZ にある場合、データ移行ジョブがソースデータベースからデータを収集するときに、AZ 間のトラフィック料金が発生します。 ![Cross-AZ traffic charges](/media/tidb-cloud/dm-billing-cross-az-fees.png) diff --git a/tidb-cloud/tidb-cloud-billing-recovery-group.md b/tidb-cloud/tidb-cloud-billing-recovery-group.md index 924c0d8297965..bf003037df52c 100644 --- a/tidb-cloud/tidb-cloud-billing-recovery-group.md +++ b/tidb-cloud/tidb-cloud-billing-recovery-group.md @@ -1,6 +1,6 @@ --- title: Recovery Group Billing -summary: TiDB Cloudのリカバリ グループの課金について説明します。 +summary: TiDB Cloudのリカバリグループの課金について説明します。 --- # リカバリグループ請求 {#recovery-group-billing} @@ -11,4 +11,4 @@ TiDB Cloudは、データ処理もGiB単位で課金されます。データ処 ## 価格 {#pricing} -TiDB Cloudリカバリ グループがサポートされているリージョンと価格については、 [リカバリグループコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#recovery-group-cost)を参照してください。 +TiDB Cloudリカバリグループがサポートされているリージョンと価格については、 [リカバリグループコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#recovery-group-cost)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md b/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md index aacee5b3219a1..15ed6ec2a26c6 100644 --- a/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md +++ b/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md @@ -45,4 +45,4 @@ TiDB Cloud Dedicatedは、[チェンジフィード](/tidb-cloud/changefeed-over **Private Link**または**Private Service Connect**のネットワーク接続方法を選択した場合、追加の**Private Data Link**料金が発生します。これらの料金は[データ転送コスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#data-transfer-cost)カテゴリに該当します。 -**Private Data Link**の料金は**$0.01/GiB**で、**データ処理量**[AWS インターフェースエンドポイントの料金](https://aws.amazon.com/privatelink/pricing/#Interface_Endpoint_pricing) 、**Consumer data processing**量[Google Cloud プライベート サービス コネクトの料金](https://cloud.google.com/vpc/pricing#psc-forwarding-rules) 、**Inbound/Outbound Data Processed**量[Azure Private Link の料金](https://azure.microsoft.com/en-us/pricing/details/private-link/)と同じです。 +**Private Data Link**の料金は**$0.01/GiB**で、**データ処理量**[AWS インターフェースエンドポイントの料金](https://aws.amazon.com/privatelink/pricing/#Interface_Endpoint_pricing) 、**Consumer data processing**量[Google Cloud プライベートサービス コネクトの料金](https://cloud.google.com/vpc/pricing#psc-forwarding-rules) 、**Inbound/Outbound Data Processed**量[Azure Private Link の料金](https://azure.microsoft.com/en-us/pricing/details/private-link/)と同じです。 diff --git a/tidb-cloud/tidb-cloud-billing.md b/tidb-cloud/tidb-cloud-billing.md index 323d4f098587e..5bc828c10a0cb 100644 --- a/tidb-cloud/tidb-cloud-billing.md +++ b/tidb-cloud/tidb-cloud-billing.md @@ -276,13 +276,13 @@ TiDB Cloudは、概念実証（PoC）ユーザー向けに一定数のクレジ -組織内で`Organization Owner`または`Organization Billing Manager`の役割を担っている場合は、 TiDB Cloudアカウントをクラウド プロバイダー (AWS、Azure、Google Cloud、または Alibaba Cloud) の請求アカウントにリンクできます。それ以外の場合は、このセクションをスキップしてください。 +組織内で`Organization Owner`または`Organization Billing Manager`の役割を担っている場合は、 TiDB Cloudアカウントをクラウドプロバイダー (AWS、Azure、Google Cloud、または Alibaba Cloud) の請求アカウントにリンクできます。それ以外の場合は、このセクションをスキップしてください。 -組織内で`Organization Owner`または`Organization Billing Manager`の役割を担っている場合は、 TiDB Cloudアカウントをクラウド プロバイダー (AWS、Azure、または Google Cloud) の請求アカウントにリンクできます。それ以外の場合は、このセクションをスキップしてください。 +組織内で`Organization Owner`または`Organization Billing Manager`の役割を担っている場合は、 TiDB Cloudアカウントをクラウドプロバイダー (AWS、Azure、または Google Cloud) の請求アカウントにリンクできます。それ以外の場合は、このセクションをスキップしてください。 diff --git a/tidb-cloud/tidb-cloud-budget.md b/tidb-cloud/tidb-cloud-budget.md index c9a873dbc609c..bf56c89a7735b 100644 --- a/tidb-cloud/tidb-cloud-budget.md +++ b/tidb-cloud/tidb-cloud-budget.md @@ -23,19 +23,18 @@ TiDB Cloud、支出を追跡するのに役立つ 2 種類の予算を提供し 組織の予算ページを表示するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[請求]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 +2. 左側のナビゲーションペインで、 **[請求]**をクリックします。 3. **請求**ページで、 **予算**タブをクリックします。 - 各予算について、名前、タイプ、ステータス、使用金額、予算額、期間、範囲を表示できます。 ## カスタム予算を作成する {#create-a-custom-budget} 組織または特定のプロジェクトの支出を監視するためのカスタム予算を作成するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[請求]**をクリックします。 +2. 左側のナビゲーションペインで、 **[請求]**をクリックします。 3. **請求**ページで**予算**タブをクリックし、 **Create Custom Budget**をクリックします。カスタム予算は最大5つまで作成できます。 @@ -67,9 +66,9 @@ TiDB Cloud、支出を追跡するのに役立つ 2 種類の予算を提供し カスタム予算を編集するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[請求]**をクリックします。 +2. 左側のナビゲーションペインで、 **[請求]**をクリックします。 3. **請求**ページで、 **予算**タブをクリックします。 @@ -92,8 +91,7 @@ TiDB Cloud、支出を追跡するのに役立つ 2 種類の予算を提供し カスタム予算を削除するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[請求]**をクリックします。 -3. **請求**ページで、 **予算**タブをクリックします。 -4. 目標予算の行を見つけて、その行の**[...]**をクリックし、 **[削除] を**クリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 +2. 左側のナビゲーションペインで、 **[請求]**をクリックします。 +3. **請求**ページで、 **予算**タブをクリックします。4. 目標予算の行を見つけて、その行の**[...]**をクリックし、 **[削除] を**クリックします。 5. 削除を確認します。 diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index 6d2a6242dd242..25afc2884a5a4 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -15,13 +15,13 @@ TiDB Cloud Clinic は、 TiDB Cloud上で高度な監視および診断機能を ## 前提条件 {#prerequisites} -TiDB Cloud Clinic は、**Enterprise**または**Premium**サポート プランに加入している組織のみが利用できます。 +TiDB Cloud Clinic は、**Enterprise**または**Premium**サポートプランに加入している組織のみが利用できます。 ## クラスタページを確認する {#view-the-cluster-page} **クラスタ**ページを表示するには、次の手順を実行します。 -1. [TiDB Cloud Clinic コンソール](https://clinic.pingcap.com/)にログインし、 **Continue with TiDB Account**を選択して、 TiDB Cloudログイン ページに入ります。 +1. [TiDB Cloud Clinic コンソール](https://clinic.pingcap.com/)にログインし、 **Continue with TiDB Account**を選択して、 TiDB Cloudログインページに入ります。 2. 組織リストから対象の組織を選択します。選択したプロジェクト内のクラスターが表示されます。 @@ -111,14 +111,14 @@ TopSQL を表示するには、次の手順を実行します。 **Benchmark Report**機能は、パフォーマンステスト中にTiDBクラスタのパフォーマンス問題を特定するのに役立ちます。ストレステストを完了すると、ベンチマークレポートを生成してクラスタのパフォーマンスを分析できます。レポートでは、特定されたボトルネックが強調表示され、最適化の提案が提供されます。これらの提案を適用した後、もう一度ストレステストを実行し、新しいベンチマークレポートを生成してパフォーマンスの改善を比較できます。 -ベンチマーク レポートを生成するには、次の手順を実行します。 +ベンチマークレポートを生成するには、次の手順を実行します。 1. [TiDB Cloud Clinic コンソール](https://clinic.pingcap.com/)で、クラスターの**クラスタ**ページに移動します。 2. **Benchmark Report**をクリックします。 -3. ベンチマーク レポートで分析する時間範囲を選択します。 +3. ベンチマークレポートで分析する時間範囲を選択します。 -4. ベンチマーク レポートを生成するには、**Create Report**をクリックします。 +4. ベンチマークレポートを生成するには、**Create Report**をクリックします。 5. レポートの生成が完了するまでお待ちください。レポートが完成したら、 **ビュー**をクリックして開きます。 diff --git a/tidb-cloud/tidb-cloud-connect-aws-dms.md b/tidb-cloud/tidb-cloud-connect-aws-dms.md index e1bd3feb57fc5..82d99a85cc132 100644 --- a/tidb-cloud/tidb-cloud-connect-aws-dms.md +++ b/tidb-cloud/tidb-cloud-connect-aws-dms.md @@ -31,17 +31,17 @@ DMSリソースを作成する前に、DMSがTiDB Cloudクラスターと通信
    -TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアントはパブリック エンドポイントまたはプライベート エンドポイントを介してクラスターに接続できます。 +TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアントはパブリックエンドポイントまたはプライベートエンドポイントを介してクラスターに接続できます。 -- [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーション インスタンスがインターネットにアクセスできることを確認します。 +- [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認します。 - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。 - レプリケーションインスタンスをプライベートサブネットにデプロイし、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)を参照してください。 -- プライベート エンドポイント経由でTiDB Cloud Starter またはTiDB Cloud Essential クラスターに接続するには、次のドキュメントを参照して、まずプライベート エンドポイントを設定し、プライベート サブネットにレプリケーション インスタンスをデプロイします。 +- プライベートエンドポイント経由でTiDB Cloud Starter またはTiDB Cloud Essential クラスターに接続するには、次のドキュメントを参照して、まずプライベートエンドポイントを設定し、プライベートサブネットにレプリケーションインスタンスをデプロイします。 - [AWS PrivateLink 経由でTiDB Cloud Starter または Essential に接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md) - [Alibaba Cloud プライベートエンドポイント経由でTiDB Cloud Starter または Essential に接続します](/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md) @@ -50,13 +50,13 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント -- [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーション インスタンスがインターネットにアクセスできることを確認します。 +- [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認します。 - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)を参照してください。 - レプリケーションインスタンスをプライベートサブネットにデプロイし、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)を参照してください。 -- プライベート エンドポイント経由でTiDB Cloud Starter またはTiDB Cloud Essential クラスターに接続するには、まず[AWS PrivateLink 経由でTiDB Cloud Starter または Essential に接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してプライベート エンドポイントを設定し、レプリケーション インスタンスをプライベート サブネットにデプロイします。 +- プライベートエンドポイント経由でTiDB Cloud Starter またはTiDB Cloud Essential クラスターに接続するには、まず[AWS PrivateLink 経由でTiDB Cloud Starter または Essential に接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してプライベートエンドポイントを設定し、レプリケーションインスタンスをプライベートサブネットにデプロイします。 @@ -64,7 +64,7 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント
    -TiDB Cloud Dedicated の場合、クライアントはパブリック エンドポイント、プライベート エンドポイント、または VPC ピアリングを介してクラスターに接続できます。 +TiDB Cloud Dedicated の場合、クライアントはパブリックエンドポイント、プライベートエンドポイント、または VPC ピアリングを介してクラスターに接続できます。 - [パブリックエンドポイント経由でTiDB Cloud Dedicated クラスターに接続する](/tidb-cloud/connect-via-standard-connection.md)については、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認するために、次のいずれかを実行します。さらに、レプリケーションインスタンスまたは NAT ゲートウェイのパブリック IP アドレスをクラスターの[IPアクセスリスト](/tidb-cloud/configure-ip-access-list.md)に追加する必要があります。 @@ -72,9 +72,9 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - レプリケーションインスタンスをプライベートサブネットにデプロイし、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)を参照してください。 -- プライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続するには、 [プライベートエンドポイントを設定する](/tidb-cloud/set-up-private-endpoint-connections.md) 、プライベート サブネットにレプリケーション インスタンスをデプロイします。 +- プライベートエンドポイント経由でTiDB Cloud Dedicated クラスターに接続するには、 [プライベートエンドポイントを設定する](/tidb-cloud/set-up-private-endpoint-connections.md) 、プライベートサブネットにレプリケーションインスタンスをデプロイします。 -- VPC ピアリング経由でTiDB Cloud Dedicated クラスターに接続するには、 [VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md) 、プライベート サブネットにレプリケーション インスタンスをデプロイします。 +- VPC ピアリング経由でTiDB Cloud Dedicated クラスターに接続するには、 [VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md) 、プライベートサブネットにレプリケーションインスタンスをデプロイします。
    @@ -100,7 +100,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - **Network type - new**: **IPv4**を選択します。 - **IPv4 用の仮想プライベート クラウド (VPC)** : 必要な VPC を選択します。 - - **Replication subnet group**: レプリケーション インスタンスのサブネット グループを選択します。 + - **Replication subnet group**: レプリケーションインスタンスのサブネット グループを選択します。 - **Public accessible**: ネットワーク構成に基づいて設定します。 ![Connectivity and security](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-connect-connectivity-security.png) @@ -119,7 +119,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド ![Create endpoint](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-connect-create-endpoint.png) -2. **Create endpoint**をクリックして、ターゲット データベース エンドポイントを作成します。 +2. **Create endpoint**をクリックして、ターゲットデータベース エンドポイントを作成します。 3. **Endpoint type**セクションで、 **Source endpoint**または**Target endpoint**を選択します。 diff --git a/tidb-cloud/tidb-cloud-console-auditing.md b/tidb-cloud/tidb-cloud-console-auditing.md index cf046ceb0f139..08e26ddfe63d1 100644 --- a/tidb-cloud/tidb-cloud-console-auditing.md +++ b/tidb-cloud/tidb-cloud-console-auditing.md @@ -15,16 +15,16 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー コンソール監査ログ機能はデフォルトで無効になっています。有効にすると、TiDB Cloudコンソールでサポートされているすべてのイベントタイプが監査され、特定のイベントタイプのみを監査するように設定することはできません。有効にするには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[Console Audit Logging]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 +2. 左側のナビゲーションペインで、 **[Console Audit Logging]**をクリックします。 3. 右上隅の**[設定]**をクリックし、コンソール監査ログを有効にして、 **[更新]**をクリックします。 ## コンソール監査ログを無効にする {#disable-console-audit-logging} コンソール監査ログを無効にするには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[Console Audit Logging]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 +2. 左側のナビゲーションペインで、 **[Console Audit Logging]**をクリックします。 3. 右上隅の**[設定]**をクリックし、コンソール監査ログを無効にして、 **[更新]**をクリックします。 ## コンソール監査ログを確認する {#view-console-audit-logs} @@ -36,8 +36,8 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー > - 組織でコンソール監査ログを初めて有効にする場合、コンソール監査ログは空です。監査対象イベントが実行されると、対応するログが表示されます。 > - コンソール監査ログが無効になってから 90 日以上経過した場合、ログは表示されません。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[Console Audit Logging]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 +2. 左側のナビゲーションペインで、 **[Console Audit Logging]**をクリックします。 3. 監査ログの特定の部分を取得するには、イベントの種類、操作ステータス、および時間範囲をフィルタリングできます。 4. (オプション) さらにフィールドをフィルターするには、 **Advanced filter**をクリックし、さらにフィルターを追加して、 **[適用]**をクリックします。 5. ログの行をクリックすると、右側のペインに詳細情報が表示されます。 @@ -46,8 +46,8 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー 組織のコンソール監査ログをエクスポートするには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **[Console Audit Logging]**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 +2. 左側のナビゲーションペインで、 **[Console Audit Logging]**をクリックします。 3. （オプション）コンソール監査ログの特定の部分をエクスポートする必要がある場合は、さまざまな条件でフィルタリングできます。それ以外の場合は、この手順をスキップしてください。 4. **Download logs**をクリックし、JSON または CSV で希望のエクスポート形式を選択します。 @@ -74,7 +74,7 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー ## コンソール監査イベントの種類 {#console-audit-event-types} -コンソール監査ログには、イベント タイプを通じてTiDB Cloudコンソール上のさまざまなユーザー アクティビティが記録されます。 +コンソール監査ログには、イベントタイプを通じてTiDB Cloudコンソール上のさまざまなユーザー アクティビティが記録されます。 > **Note:** > @@ -167,7 +167,7 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー | メンテナンスタスクの延期 | メンテナンスタスクを延期する | | ブランチの作成 | TiDB Cloud Starter またはTiDB Cloud Essential クラスターのブランチを作成する | | ブランチの削除 | TiDB Cloud Starter またはTiDB Cloud Essential クラスターのブランチを削除します | -| ブランチルートパスワードの設定 | TiDB Cloud Starter またはTiDB Cloud Essential クラスターのブランチのルート パスワードを設定する | +| ブランチルートパスワードの設定 | TiDB Cloud Starter またはTiDB Cloud Essential クラスターのブランチのルートパスワードを設定する | | 接続ブランチGitHub | クラスターをGitHubリポジトリに接続してブランチ統合を有効にする | | ブランチを切断GitHub | ブランチ統合を無効にするには、クラスターを GitHub リポジトリから切断します。 | | 認証方法の更新 | Cloud Organization SSO の認証方法を更新する | diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md index 26f0a30d22a6b..ba0ab7a2f475f 100644 --- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md +++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md @@ -96,7 +96,7 @@ TiDB クラスターのストレージが不足しています。 [TiKVノード ### エラーメッセージ：「LOCK TABLES ... アクセスが拒否されました」 {#error-message-lock-tables-access-denied} -ソース データベース ユーザーに`LOCK TABLES`権限がないため、データの完全なエクスポートが失敗します。このエラーは通常、マネージド MySQL サービス (Amazon RDS、 Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL、Google Cloud SQL など) から移行する場合に発生します。これらのサービスでは、クラウド プロバイダーによって`FLUSH TABLES WITH READ LOCK` (FTWRL) が許可されていません。このシナリオでは、DM はデフォルトの`consistency=auto`モードを使用し、完全なエクスポート中にデータの一貫性を確保するために`LOCK TABLES`にフォールバックします。この操作には`LOCK TABLES`権限が必要です。 +ソースデータベースユーザーに`LOCK TABLES`権限がないため、データの完全なエクスポートが失敗します。このエラーは通常、マネージド MySQL サービス (Amazon RDS、 Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL、Google Cloud SQL など) から移行する場合に発生します。これらのサービスでは、クラウドプロバイダーによって`FLUSH TABLES WITH READ LOCK` (FTWRL) が許可されていません。このシナリオでは、DM はデフォルトの`consistency=auto`モードを使用し、完全なエクスポート中にデータの一貫性を確保するために`LOCK TABLES`にフォールバックします。この操作には`LOCK TABLES`権限が必要です。 > **Note:** > @@ -118,15 +118,15 @@ TiDB Cloudのアラートメールを購読すると、アラートが発生し - データ移行ジョブで、データエクスポート中にエラーが発生しました。 - 推奨されるアクション: データ移行ページでエラー メッセージを確認し、[移行エラーとその解決策](#migration-errors-and-solutions)でヘルプを参照してください。 + 推奨されるアクション: データ移行ページでエラーメッセージを確認し、[移行エラーとその解決策](#migration-errors-and-solutions)でヘルプを参照してください。 - データ移行ジョブのデータインポート中にエラーが発生しました - 推奨されるアクション: データ移行ページでエラー メッセージを確認し、[移行エラーとその解決策](#migration-errors-and-solutions)でヘルプを参照してください。 + 推奨されるアクション: データ移行ページでエラーメッセージを確認し、[移行エラーとその解決策](#migration-errors-and-solutions)でヘルプを参照してください。 - 「増分データ移行中にデータ移行ジョブでエラーが発生しました」 - 推奨されるアクション: データ移行ページでエラー メッセージを確認し、[移行エラーとその解決策](#migration-errors-and-solutions)でヘルプを参照してください。 + 推奨されるアクション: データ移行ページでエラーメッセージを確認し、[移行エラーとその解決策](#migration-errors-and-solutions)でヘルプを参照してください。 - 「増分移行中にデータ移行ジョブが6時間以上一時停止されました」 diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index 5687935d7fceb..eb6720b336fe6 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -66,7 +66,7 @@ TiDB Cloudコンソールまたは API を使用して、プロジェクトの C 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、**Project view** タブをクリックします。 2. プロジェクトビューで対象のプロジェクトを見つけ、そのプロジェクトの をクリックします。 -3. 左側のナビゲーション ペインで、**Project Settings** の下にある **Encryption Access** をクリックします。 +3. 左側のナビゲーションペインで、**Project Settings** の下にある **Encryption Access** をクリックします。 4. **Encryption Access**ページで、**Create Encryption Key**をクリックして、キー作成ページに入ります。 5. キープロバイダーはAWS KMSのみをサポートしています。暗号化キーを使用できるリージョンを選択できます。 6. JSONファイルをコピーして`ROLE-TRUST-POLICY.JSON`として保存します。このファイルは信頼関係を記述します。 diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md index 33c64298d42b1..726c096e4bd1e 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md @@ -49,7 +49,7 @@ TiDB Cloudコンソールと Azure ポータルを使用して CMEK を構成す 2. プロジェクトビューで対象のプロジェクトを見つけ、そのプロジェクトの をクリックします。 -3. 左側のナビゲーション ペインで、**Project Settings** の下にある **Encryption Access** をクリックします。 +3. 左側のナビゲーションペインで、**Project Settings** の下にある **Encryption Access** をクリックします。 4. **Encryption Access**ページで、**Create Encryption Key**をクリックします。 @@ -99,11 +99,11 @@ TiDB Cloudコンソールと Azure Resource Manager を使用して CMEK を構 > **Tip:** > - > 複数の組織に所属している場合は、まず左上隅のコンボ ボックスを使用して対象の組織に切り替えてください。 + > 複数の組織に所属している場合は、まず左上隅のコンボボックスを使用して対象の組織に切り替えてください。 2. プロジェクトビューで対象のプロジェクトを見つけ、そのプロジェクトの をクリックします。 -3. 左側のナビゲーション ペインで、**Project Settings** の下にある **Encryption Access** に移動します。 +3. 左側のナビゲーションペインで、**Project Settings** の下にある **Encryption Access** に移動します。 4. **Encryption Access**ページで、**Create Encryption Key**をクリックします。 diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index 75d789f941b15..39513170e211d 100644 --- a/tidb-cloud/tidb-cloud-faq.md +++ b/tidb-cloud/tidb-cloud-faq.md @@ -105,7 +105,7 @@ Software as a Service (SaaS) プロバイダーとして、当社はデータの ### 他のRDBMSからTiDB Cloudへの簡単な移行方法はありますか？ {#is-there-an-easy-migration-path-from-another-rdbms-to-tidb-cloud} -TiDB は MySQL と高い互換性があります。データがセルフホスト型 MySQL インスタンスからのものであっても、パブリック クラウドによって提供される RDS サービスからのものであっても、MySQL 互換データベースから TiDB にスムーズにデータを移行できます。詳細については、 [データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を参照してください。 +TiDB は MySQL と高い互換性があります。データがセルフホスト型 MySQL インスタンスからのものであっても、パブリッククラウドによって提供される RDS サービスからのものであっても、MySQL 互換データベースから TiDB にスムーズにデータを移行できます。詳細については、 [データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を参照してください。 ## バックアップと復元に関するFAQ {#backup-and-restore-faq} diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 699873defe89b..cd9397fe1aeab 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,10 +176,9 @@ 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 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)を参照してください。 +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..7f7b35b958e5c 100644 --- a/tidb-cloud/tidb-cloud-import-local-files.md +++ b/tidb-cloud/tidb-cloud-import-local-files.md @@ -1,6 +1,6 @@ --- title: Import Local Files to TiDB Cloud Starter -summary: ローカル ファイルをTiDB Cloud Starter にインポートする方法を学びます。 +summary: ローカルファイルをTiDB Cloud Starter にインポートする方法を学びます。 --- # ローカルファイルをTiDB Cloud Starterにインポートする {#import-local-files-to-tidb-cloud-starter} @@ -11,9 +11,9 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする ## 制限事項 {#limitations} -- 現在、 TiDB Cloud は、1 つのタスクにつき 250 MiB 以内の CSV 形式のローカル ファイルのインポートのみをサポートしています。 -- ローカル ファイルのインポートは、 TiDB Cloud Starter クラスターでのみサポートされ、 TiDB Cloud Essential クラスターおよび TiDB Cloud Dedicated クラスターではサポートされません。 -- 複数のインポート タスクを同時に実行することはできません。 +- 現在、 TiDB Cloud は、1 つのタスクにつき 250 MiB 以内の CSV 形式のローカルファイルのインポートのみをサポートしています。 +- ローカルファイルのインポートは、 TiDB Cloud Starter クラスターでのみサポートされ、 TiDB Cloud Essential クラスターおよび TiDB Cloud Dedicated クラスターではサポートされません。 +- 複数のインポートタスクを同時に実行することはできません。 ## ローカルファイルをインポートする {#import-local-files} @@ -23,11 +23,11 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする > **Tip:** > - > 左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 + > 左上隅のコンボボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。 - 2. ターゲット TiDB Cloud Starter インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**[データ]** > **[インポート]**をクリックします。 + 2. ターゲット TiDB Cloud Starter インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[インポート]**をクリックします。 -2. **インポート**ページでは、ローカルファイルをアップロードエリアに直接ドラッグ＆ドロップするか、 **Upload a local file**をクリックして対象のローカルファイルを選択してアップロードできます。1つのタスクにつき、250MiB未満のCSVファイルを1つだけアップロードできます。ローカルファイルが250MiBを超える場合は、 [250 MiB を超えるローカル ファイルをインポートするにはどうすればよいでしょうか?](#how-to-import-a-local-file-larger-than-250-mib)を参照してください。 +2. **インポート**ページでは、ローカルファイルをアップロードエリアに直接ドラッグ＆ドロップするか、 **Upload a local file**をクリックして対象のローカルファイルを選択してアップロードできます。1つのタスクにつき、250MiB未満のCSVファイルを1つだけアップロードできます。ローカルファイルが250MiBを超える場合は、 [250 MiB を超えるローカルファイルをインポートするにはどうすればよいでしょうか?](#how-to-import-a-local-file-larger-than-250-mib)を参照してください。 3. **宛先**セクションで、ターゲットデータベースとターゲットテーブルを選択するか、名前を直接入力して新しいデータベースまたはテーブルを作成します。名前には、Unicode BMP（Basic Multilingual Plane）の文字のみを使用し、ヌル文字`\u0000`と空白文字は含めず、最大64文字まで使用できます。 **Define Table**をクリックすると、 **Table Definition**セクションが表示されます。 @@ -56,12 +56,12 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする > **Note:** > - > TiDB Cloudの既存のテーブルに CSV ファイルをインポートし、ターゲット テーブルにソース ファイルよりも多くの列がある場合、状況に応じて余分な列が異なって処理されます。 + > TiDB Cloudの既存のテーブルに CSV ファイルをインポートし、ターゲットテーブルにソースファイルよりも多くの列がある場合、状況に応じて余分な列が異なって処理されます。 > > - 追加列が主キーまたは一意キーでない場合、エラーは報告されません。代わりに、これらの追加列には[デフォルト値](/data-type-default-values.md)が設定されます。 > - 追加列が主キーまたは一意キーであり、属性`auto_increment`または`auto_random`を持たない場合、エラーが報告されます。その場合は、以下のいずれかの戦略を選択することをお勧めします。 - > - これらの主キーまたは一意キーの列を含むソース ファイルを提供します。 - > - ターゲット テーブルの主キーと一意キーの列を、ソース ファイル内の既存の列と一致するように変更します。 + > - これらの主キーまたは一意キーの列を含むソースファイルを提供します。 + > - ターゲットテーブルの主キーと一意キーの列を、ソースファイル内の既存の列と一致するように変更します。 > - 主キーまたは一意キー列の属性を`auto_increment`または`auto_random`に設定します。 6. 新しいターゲットテーブルでは、主キーを設定できます。主キーとして列を選択するか、複数の列を選択して複合主キーを作成できます。複合主キーは、列名を選択した順序で作成されます。 @@ -80,7 +80,7 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする 9. インポートタスクが完了したら、 **SQLエディタでデータを探索**をクリックして、インポートしたデータに対してクエリを実行できます。SQLエディタの使用方法の詳細については、 [AI支援SQLエディターでデータを探索](/tidb-cloud/explore-data-with-chat2query.md)をご覧ください。 -10. **[インポート]**ページで、 **[アクション**] 列の**[...** ] > **[ビュー]**をクリックして、インポート タスクの詳細を確認できます。 +10. **[インポート]**ページで、 **[アクション**] 列の**[...** ] > **[ビュー]**をクリックして、インポートタスクの詳細を確認できます。 ## FAQ {#faq} @@ -106,7 +106,7 @@ LOAD DATA LOCAL INFILE 'load.txt' INTO TABLE import_test FIELDS TERMINATED BY ', 列名がTiDBで予約済みの[キーワード](/keywords.md)である場合、その列をクエリする際には、列名を囲むバッククォート`` ` ``を追加する必要があります。例えば、列名が`order`の場合、 `` `order` ``で列をクエリする必要があります。 -### 250 MiB を超えるローカル ファイルをインポートするにはどうすればよいでしょうか? {#how-to-import-a-local-file-larger-than-250-mib} +### 250 MiB を超えるローカルファイルをインポートするにはどうすればよいでしょうか? {#how-to-import-a-local-file-larger-than-250-mib} ファイルが250MiBより大きい場合は、 [TiDB Cloud CLI](/tidb-cloud/get-started-with-cli.md)を使用してファイルをインポートできます。詳細については、 [`ticloud serverless import start`](/tidb-cloud/ticloud-import-start.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-intro.md b/tidb-cloud/tidb-cloud-intro.md index e42f0cba1e1e7..d2b66db789818 100644 --- a/tidb-cloud/tidb-cloud-intro.md +++ b/tidb-cloud/tidb-cloud-intro.md @@ -6,7 +6,7 @@ category: intro # TiDB Cloudとは何ですか？ {#what-is-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は、データベースの導入と管理を簡単に行う方法を提供し、データベースの複雑さではなく、アプリケーションに集中できるようにします。 TiDB Cloudのリソース（ TiDB Cloud Starterインスタンス、 TiDB Cloud Essentialインスタンス、 TiDB Cloud Dedicatedクラスターなど）を作成することで、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloud上にミッションクリティカルなアプリケーションを迅速に構築できます。 TiDB Cloudのリソース（ TiDB Cloud Starterインスタンス、 TiDB Cloud Essentialインスタンス、 TiDB Cloud Dedicatedクラスターなど）を作成することで、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure上にミッションクリティカルなアプリケーションを迅速に構築できます。 +[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)は、オープンソースのハイブリッドトランザクションおよび分析処理 (HTAP) データベースである[TiDB](https://docs.pingcap.com/tidb/stable/overview)をベースにした、フルマネージドのクラウドネイティブの Database-as-a-Service (DBaaS) です。 TiDB Cloudは、データベースの導入と管理を簡単に行う方法を提供し、データベースの複雑さではなく、アプリケーションに集中できるようにします。 TiDB Cloudのリソース（ TiDB Cloud Starterインスタンス、 TiDB Cloud Essentialインスタンス、 TiDB Cloud Dedicatedクラスターなど）を作成することで、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure、およびAlibaba Cloud上にミッションクリティカルなアプリケーションを迅速に構築できます。 TiDB Cloudのリソース（ TiDB Cloud Starterインスタンス、 TiDB Cloud Essentialインスタンス、 TiDB Cloud Dedicatedクラスターなど）を作成することで、Amazon Web Services（AWS）、Google Cloud、Microsoft Azure上にミッションクリティカルなアプリケーションを迅速に構築できます。 ![TiDB Cloud Overview](/media/tidb-cloud/tidb-cloud-overview.png) @@ -152,7 +152,7 @@ TiDB Cloudは、以下の導入オプションを提供します。 - あなたのVPC - プライベート エンドポイント接続または VPC ピアリング接続を介してTiDB Cloudリソースに接続できます。詳細については[プライベートエンドポイント接続を設定する](/tidb-cloud/set-up-private-endpoint-connections.md)または[VPCピアリング接続の設定](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 + プライベートエンドポイント接続または VPC ピアリング接続を介してTiDB Cloudリソースに接続できます。詳細については[プライベートエンドポイント接続を設定する](/tidb-cloud/set-up-private-endpoint-connections.md)または[VPCピアリング接続の設定](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-org-sso-authentication.md b/tidb-cloud/tidb-cloud-org-sso-authentication.md index 645cf81f6f681..64532dff484a2 100644 --- a/tidb-cloud/tidb-cloud-org-sso-authentication.md +++ b/tidb-cloud/tidb-cloud-org-sso-authentication.md @@ -51,7 +51,7 @@ TiDB Cloud は、Cloud Organization SSO に次の認証方法を提供します Cloud Organization SSO を有効にすると、最初の 4 つの認証方法がデフォルトで有効になります。組織で SSO の使用を強制したい場合は、ユーザー名とパスワードによる認証方法を無効にすることができます。 -有効になっているすべての認証方法はカスタムTiDB Cloudログイン ページに表示されるため、事前に有効または無効にする認証方法を決定する必要があります。 +有効になっているすべての認証方法はカスタムTiDB Cloudログインページに表示されるため、事前に有効または無効にする認証方法を決定する必要があります。 ### 自動プロビジョニングを有効にするかどうかを決定する {#decide-whether-to-enable-auto-provision} @@ -62,7 +62,7 @@ Cloud Organization SSO を有効にすると、最初の 4 つの認証方法が OIDC および SAML 認証方式では、 [認証方法の詳細を設定する](#step-2-configure-authentication-methods)ときに **Auto-provision Accounts** を有効にする場合、 **Allowed Email Domains** を設定する必要があります。SAML では、 **SCIM Provisioning Accounts** を有効にする場合にもこの要件が適用されます。 **Allowed Email Domains** でドメインを使用する前に、 **Domains** でそのドメインを追加して検証してください。 -その他の認証方法では、自動プロビジョニングを有効にする場合は、認証に許可される電子メール ドメインを制限することをお勧めします。 +その他の認証方法では、自動プロビジョニングを有効にする場合は、認証に許可される電子メールドメインを制限することをお勧めします。 ### Cloud Organization SSO 移行計画についてメンバーに通知します {#notify-your-members-about-the-cloud-organization-sso-migration-plan} @@ -77,9 +77,9 @@ Cloud Organization SSO を有効にする前に、次の点についてメンバ Cloud Organization SSO を有効にするには、次の手順を実行します。 -1. `Organization Owner`ロールを持つユーザーとして[TiDB Cloudコンソール](https://tidbcloud.com)にログインし、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 +1. `Organization Owner`ロールを持つユーザーとして[TiDB Cloudコンソール](https://tidbcloud.com)にログインし、左上隅のコンボボックスを使用して対象の組織に切り替えます。 -2. 左側のナビゲーション ペインで、 **Organization Settings** > **[認証]**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **[認証]**をクリックします。 3. **[認証]**ページで、 **[有効にする]**をクリックします。 @@ -119,7 +119,7 @@ Cloud Organization SSO を有効にした後、次のようにユーザー名と > **Note:** > - > 電子メール ドメインを構成している場合は、設定を保存する前に、 TiDB Cloudによってロックアウトされないように、現在ログインに使用している電子メール ドメインを必ず追加してください。 + > 電子メールドメインを構成している場合は、設定を保存する前に、 TiDB Cloudによってロックアウトされないように、現在ログインに使用している電子メールドメインを必ず追加してください。 4. **［保存］**をクリックします。 @@ -160,7 +160,7 @@ TiDB Cloudでは、OIDC認証方式はデフォルトで無効になっていま - **名前** - カスタム ログイン ページに表示される OIDC 認証方法の名前を指定します。 + カスタム ログインページに表示される OIDC 認証方法の名前を指定します。 - **Issuer URL** 、**Client ID** 、**Client Secret** @@ -203,7 +203,7 @@ TiDB Cloudでは、SAML認証方式はデフォルトで無効になっていま - **名前** - カスタム ログイン ページに表示される SAML 認証方法の名前を指定します。 + カスタム ログインページに表示される SAML 認証方法の名前を指定します。 - **Sign on URL** @@ -265,10 +265,9 @@ TiDB Cloudでは、SAML認証方式はデフォルトで無効になっていま 3. TiDB Cloudで、アイデンティティ プロバイダーからプッシュされたグループを表示します。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 - 2. 左側のナビゲーション ペインで、 **Organization Settings** > **[認証]**をクリックします。 - 3. **グループ**タブをクリックします。IDプロバイダーから同期されたグループが表示されます。 - 4. グループ内のユーザーを表示するには、 **[ビュー]**をクリックします。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスを使用して対象の組織に切り替えます。 + 2. 左側のナビゲーションペインで、 **Organization Settings** > **[認証]**をクリックします。 + 3. **グループ**タブをクリックします。IDプロバイダーから同期されたグループが表示されます。 4. グループ内のユーザーを表示するには、 **[ビュー]**をクリックします。 4. TiDB Cloudで、アイデンティティ プロバイダーからプッシュされたグループにロールを付与します。 diff --git a/tidb-cloud/tidb-cloud-partners.md b/tidb-cloud/tidb-cloud-partners.md index 610a3330333ef..ccb4c019115df 100644 --- a/tidb-cloud/tidb-cloud-partners.md +++ b/tidb-cloud/tidb-cloud-partners.md @@ -1,6 +1,6 @@ --- title: TiDB Cloud Partner Web Console -summary: 再販業者およびマネージド サービス プロバイダー (MSP) としてTiDB Cloud Partner Web コンソールを使用する方法を学習します。 +summary: 再販業者およびマネージドサービス プロバイダー (MSP) としてTiDB Cloud Partner Web コンソールを使用する方法を学習します。 aliases: ['/ja/tidbcloud/managed-service-provider'] --- @@ -11,7 +11,7 @@ TiDB Cloudパートナー Web コンソールは、SaaS ソリューションに TiDB Cloudパートナーには 2 つの種類があります。 - 再販業者: AWS Marketplace チャネルパートナープライベートオファー (CPPO) を通じてTiDB Cloud を再販します -- マネージド サービス プロバイダー (MSP): TiDB Cloudを再販し、付加価値サービスを提供します +- マネージドサービス プロバイダー (MSP): TiDB Cloudを再販し、付加価値サービスを提供します ## AWS チャネルパートナープライベートオファー (CPPO) を通じた再販業者 {#reseller-through-aws-channel-partner-private-offer-cppo} @@ -32,7 +32,7 @@ TiDB Cloudパートナーには 2 つの種類があります。 MSP は、 TiDB Cloudを再販し、 TiDB Cloud組織管理、課金サービス、技術サポートなどを含む付加価値サービスを提供するパートナーです。 -マネージド サービス プロバイダーになるメリットは次のとおりです。 +マネージドサービス プロバイダーになるメリットは次のとおりです。 - 割引とインセンティブプログラム - エンパワーメントトレーニング diff --git a/tidb-cloud/tidb-cloud-performance-reference.md b/tidb-cloud/tidb-cloud-performance-reference.md index 3185b19b8673a..fd79590109ae5 100644 --- a/tidb-cloud/tidb-cloud-performance-reference.md +++ b/tidb-cloud/tidb-cloud-performance-reference.md @@ -27,7 +27,7 @@ mysql-ignore-errors=1062,2013,8028,9002,9007 auto-inc=false ``` -このドキュメントでは、トランザクション モデル`Read Only`、`Read Write`、および`Write Only`は、それぞれ読み取りワークロード、混合ワークロード、および書き込みワークロードを表します。 +このドキュメントでは、トランザクションモデル`Read Only`、`Read Write`、および`Write Only`は、それぞれ読み取りワークロード、混合ワークロード、および書き込みワークロードを表します。 ## 4 vCPU パフォーマンス {#4-vcpu-performance} diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index 01ed358eb5400..1089b77f710b4 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -73,15 +73,15 @@ PoC 用の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-d > TiDB Cloud Dedicated クラスターを作成する前に、次のいずれかの支払い方法を追加する必要があります。 > > - クラスター作成ページの画面上の指示に従って、クレジットカードを追加します。 - > - 電信送金で支払う場合は、 TiDB Cloudサポート チームにお問い合わせください。 - > - クラウド マーケットプレイス (AWS、Azure、または Google Cloud) を通じてTiDB Cloudにサインアップし、クラウド プロバイダー アカウントを使用して支払います。 + > - 電信送金で支払う場合は、 TiDB Cloudサポートチームにお問い合わせください。 + > - クラウド マーケットプレイス (AWS、Azure、または Google Cloud) を通じてTiDB Cloudにサインアップし、クラウドプロバイダー アカウントを使用して支払います。 > > PoC クレジットは、PoC 期間中に発生した対象費用を相殺するために自動的に使用されます。 クラスターを作成する前に、キャパシティプランニングを実施してクラスターのサイズを決定することをお勧めします。TiDB、TiKV、またはTiFlashノードの概算数から開始し、パフォーマンス要件に合わせて後からクラスターをスケールアウトすることも可能です。詳細については、以下のドキュメントをご覧いただくか、サポートチームにお問い合わせください。 - サイズ見積もりの実践の詳細については、 [TiDBのサイズ](/tidb-cloud/size-your-cluster.md)を参照してください。 -- TiDB Cloud Dedicated クラスターの構成については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。TiDB、TiKV、 TiFlash (オプション) のクラスター サイズをそれぞれ構成します。 +- TiDB Cloud Dedicated クラスターの構成については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。TiDB、TiKV、 TiFlash (オプション) のクラスターサイズをそれぞれ構成します。 - PoC クレジットの消費を効果的に計画し、最適化する方法については、このドキュメントの[FAQ](#faq)を参照してください。 - スケーリングの詳細については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)を参照してください。 @@ -94,7 +94,7 @@ PoC 用の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-d ## ステップ4. スキーマとSQLを適応させる {#step-4-adapt-your-schemas-and-sql} -次に、テーブルやインデックスを含むデータベース スキーマを TiDB クラスターにロードできます。 +次に、テーブルやインデックスを含むデータベーススキーマを TiDB クラスターにロードできます。 PoC クレジットの数量には限りがあるため、クレジットの価値を最大化するために、 TiDB Cloudで互換性テストや予備分析用の[TiDB Cloud Starter クラスター](/tidb-cloud/select-cluster-tier.md#starter)を作成することをお勧めします。 @@ -115,7 +115,7 @@ TiDB CloudはMySQL 8.0との互換性が非常に高くなっています。MySQ - タイムスタンプ上のインデックスなど、右側のインデックスの増加によって発生する[ホットスポットの問題](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)を回避します。 - [SHARD_ROW_ID_BITS](https://docs.pingcap.com/tidb/stable/shard-row-id-bits)と[AUTO_RANDOM](https://docs.pingcap.com/tidb/stable/auto-random)を使って[ホットスポットの問題](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#identify-hotspot-issues)を回避します。 -SQL ステートメントの場合、データ ソースと TiDB の互換性のレベルに応じて調整する必要がある場合があります。 +SQL ステートメントの場合、データソースと TiDB の互換性のレベルに応じて調整する必要がある場合があります。 ご不明な点がございましたら[PingCAP](/tidb-cloud/tidb-cloud-support.md)までご相談ください。 @@ -160,7 +160,7 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます - ストレージサイズとCPU使用率を評価し、それに応じてTiDBクラスターのスケールアウトまたはスケールインを実施してください。スケーリングの詳細については、セクション[FAQ](#faq)を参照してください。 -パフォーマンス チューニングのヒントを次に示します。 +パフォーマンスチューニングのヒントを次に示します。 - 書き込みパフォーマンスの向上 @@ -219,7 +219,7 @@ TiDB Cloud は、自動バックアップと手動バックアップの 2 種類 PoCの申請が承認されると、アカウントにクレジットが付与されます。通常、このクレジットは14日間のPoCに十分な量です。クレジットは、ノードの種類と数に応じて、時間単位で課金されます。詳細については、 [TiDB Cloud課金](/tidb-cloud/tidb-cloud-billing.md#credits)をご覧ください。 -PoC の合計クレジット数、利用可能なクレジット数、現在のクレジット使用量を確認するには、 TiDB Cloudコンソールの左上隅にあるコンボ ボックスを使用して対象組織に切り替え、左側のナビゲーション ペインで**[請求] を**クリックして、 **[クレジット]**タブをクリックします。 +PoC の合計クレジット数、利用可能なクレジット数、現在のクレジット使用量を確認するには、 TiDB Cloudコンソールの左上隅にあるコンボボックスを使用して対象組織に切り替え、左側のナビゲーションペインで**[請求] を**クリックして、 **[クレジット]**タブをクリックします。 クレジットを節約するには、使用していないクラスターを削除してください。現在、クラスターを停止することはできません。クラスターを削除する前に、バックアップが最新であることを確認してください。そうすれば、後でPoCを再開する際にクラスターを復元できます。 diff --git a/tidb-cloud/tidb-cloud-quickstart.md b/tidb-cloud/tidb-cloud-quickstart.md index d2cfce837a1cc..43f5c60ee9a2e 100644 --- a/tidb-cloud/tidb-cloud-quickstart.md +++ b/tidb-cloud/tidb-cloud-quickstart.md @@ -54,7 +54,7 @@ category: quick start AWS でホストされているTiDB Cloud Starter クラスターでは、 TiDB Cloudコンソールに組み込まれた AI 支援型 SQL エディタを使用して、データの価値を最大限に高めることができます。これにより、ローカル SQL クライアントを使用せずに、データベースに対して SQL クエリを実行できます。クエリ結果は表やグラフで直感的に表示され、クエリログも簡単に確認できます。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページで、クラスター名をクリックして概要ページに移動し、左側のナビゲーション ペインで**SQL Editor**をクリックします。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページで、クラスター名をクリックして概要ページに移動し、左側のナビゲーションペインで**SQL Editor**をクリックします。 2. TiDB Cloudの AI 機能を試すには、画面上の指示に従って、PingCAP と AWS Bedrock が研究とサービスの改善のためにコードスニペットを使用することを許可し、 **[Save and Get Started]** をクリックします。 @@ -129,7 +129,7 @@ TiDB Cloud は、 TiDB Cloudをすぐに使い始めるのに役立つ、丁寧 1. コンソールの右下隅にある**[?]**アイコンをクリックし、 **[SQL エディターのガイド ツアー]**を選択します。 2. ツアーで使用するTiDB Cloud Starterクラスターを選択し、 **Import Dataset**をクリックします。インポート処理には約1分かかる場合があります。 -3. サンプル データをインポートしたら、画面の指示に従ってツアーを完了します。 +3. サンプルデータをインポートしたら、画面の指示に従ってツアーを完了します。 ## ステップ4: {{{ .starter }}} インスタンスに接続する {#step-4-connect-to-your-starter-instance} diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index c2e9176ece55f..12c7bb860ee78 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -25,7 +25,7 @@ TiDB Cloudには、スロークエリを分析するのに役立つツールが TiDB Cloudコンソールには、 [**SQL Statement**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)上に[**SQLステートメント**](/tidb-cloud/tune-performance.md#statement-analysis)タブが用意されています。このタブでは、TiDB Cloudリソース上のすべてのデータベースの SQL ステートメントの実行統計情報を収集します。これを使用して、合計または単一の実行に長い時間を要する SQL ステートメントを特定し、分析することができます。 -このページでは、構造が同じ SQL クエリ (クエリ パラメータが一致しない場合でも) は、同じ SQL ステートメントにグループ化されることに注意してください。たとえば、 `SELECT * FROM employee WHERE id IN (1, 2, 3)`と`select * from EMPLOYEE where ID in (4, 5)`は、どちらも同じ SQL ステートメント`select * from employee where id in (...)`の一部です。 +このページでは、構造が同じ SQL クエリ (クエリパラメータが一致しない場合でも) は、同じ SQL ステートメントにグループ化されることに注意してください。たとえば、 `SELECT * FROM employee WHERE id IN (1, 2, 3)`と`select * from EMPLOYEE where ID in (4, 5)`は、どちらも同じ SQL ステートメント`select * from employee where id in (...)`の一部です。 **SQL Statement**でいくつかの重要な情報を確認できます。 @@ -55,7 +55,7 @@ TiDBによって選択された実行計画が最適でない場合は、 EXPLAI `parser`による元のクエリテキストの解析と基本的な妥当性検証の後、TiDB はまずクエリに対して論理的に同等の変更を行います。詳細については、 [SQL論理最適化](/sql-logical-optimization.md)を参照してください。 -これらの等価性の変更により、クエリは論理実行計画で扱いやすくなります。等価性の変更後、TiDB は元のクエリと等価なクエリ プラン構造を取得し、データ分布と演算子の特定の実行オーバーヘッドに基づいて最終的な実行計画を取得します。詳細については、 [SQLの物理的最適化](/sql-physical-optimization.md)を参照してください。 +これらの等価性の変更により、クエリは論理実行計画で扱いやすくなります。等価性の変更後、TiDB は元のクエリと等価なクエリプラン構造を取得し、データ分布と演算子の特定の実行オーバーヘッドに基づいて最終的な実行計画を取得します。詳細については、 [SQLの物理的最適化](/sql-physical-optimization.md)を参照してください。 また、プリペアドプランキャッシュで紹介したように、TiDB は、 `PREPARE`ステートメントの実行時に実行計画の作成オーバーヘッドを削減するために、[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を提供しています。 @@ -77,7 +77,7 @@ SQLクエリが遅くなる最も一般的な原因は、 `SELECT`ステート ### インデックスのベストプラクティス {#index-best-practices} -[インデックス作成のベストプラクティス](/develop/dev-guide-index-best-practice.md)には、インデックスの作成とインデックスの使用に関するベスト プラクティスが含まれています。 +[インデックス作成のベストプラクティス](/develop/dev-guide-index-best-practice.md)には、インデックスの作成とインデックスの使用に関するベストプラクティスが含まれています。 インデックスの作成速度はデフォルトでは控えめですが、シナリオによっては[変数の変更](/develop/dev-guide-optimize-sql-best-practices.md#add-index-best-practices)によってインデックス作成プロセスを高速化できます。 diff --git a/tidb-cloud/tidb-cloud-support.md b/tidb-cloud/tidb-cloud-support.md index aa2ece1420aba..f92ec7c435b32 100644 --- a/tidb-cloud/tidb-cloud-support.md +++ b/tidb-cloud/tidb-cloud-support.md @@ -1,6 +1,6 @@ --- title: TiDB Cloud Support -summary: TiDB Cloudのサポート チームに連絡する方法について説明します。 +summary: TiDB Cloudのサポートチームに連絡する方法について説明します。 --- # TiDB Cloudサポート {#tidb-cloud-support} @@ -13,7 +13,7 @@ TiDB Cloudは複数のサポートチャネルを提供しています。利用 - サポートチケット ( [ヘルプセンター](#access-pingcap-help-center) ) - TiDB Cloudサポート チームからの直接支援が必要な問題については、このチケット ベースのチャネルを使用してください。 + TiDB Cloudサポートチームからの直接支援が必要な問題については、このチケット ベースのチャネルを使用してください。 - [請求とアカウントチケット](/tidb-cloud/tidb-cloud-support.md#create-an-account-or-billing-support-ticket)はすべてのTiDB Cloudユーザーが利用できます。 - 有料サポートプランでは、応答時間保証付きの[テクニカルサポートチケット](/tidb-cloud/tidb-cloud-support.md#create-a-technical-support-ticket)をご利用いただけます。有料サポートプランにご加入されていない場合は、技術的なご質問についてはコミュニティチャンネルをご利用ください。 @@ -35,12 +35,12 @@ TiDB Cloudは複数のサポートチャネルを提供しています。利用 ## PingCAPヘルプセンターにアクセスする {#access-pingcap-help-center} -[PingCAP ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)は、 TiDB Cloudユーザーがサポート サービスにアクセスし、サポート チケットを管理するための中心的なハブです。 +[PingCAP ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)は、 TiDB Cloudユーザーがサポートサービスにアクセスし、サポートチケットを管理するための中心的なハブです。 PingCAP ヘルプ センターには、 [https://tidb.support.pingcap.com/servicedesk/customer/portals](https://tidb.support.pingcap.com/servicedesk/customer/portals)から直接アクセスすることも、次の[TiDB Cloudコンソール](https://tidbcloud.com/)の方法でアクセスすることもできます。 - [TiDB Cloudコンソール](https://tidbcloud.com/)の右下隅にある**[?]**をクリックし、 **Support Tickets**をクリックします。 -- [TiDB Cloudコンソール](https://tidbcloud.com/)の左下隅にある**[サポート] を**クリックし、サポート プランに応じて次のいずれかを実行します。 +- [TiDB Cloudコンソール](https://tidbcloud.com/)の左下隅にある**[サポート] を**クリックし、サポートプランに応じて次のいずれかを実行します。 - **基本**: **[Account & Billing]**領域で、 **Account/Billing issues**をクリックします。 - **Developer** 、 **Enterprise** 、または**Premium** : **Talk to an expert**エリアで、 **PingCAP Help Center**をクリックします。 - プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページで、クラスターの行にある**[...]**をクリックし、 **Get Support**を選択します。 @@ -66,7 +66,7 @@ TiDB Cloudのすべてのユーザーは、請求およびアカウント関連 ## テクニカルサポートチケットを作成する {#create-a-technical-support-ticket} -技術的な問題に関するサポート チケットを作成するには、次の手順を実行します。 +技術的な問題に関するサポートチケットを作成するには、次の手順を実行します。 1. [PingCAP ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)にログインし、 [TiDB Cloudテクニカルサポート](https://tidb.support.pingcap.com/servicedesk/customer/portal/6)をクリックします。 @@ -105,7 +105,7 @@ TiDB Cloudのすべてのユーザーは、請求およびアカウント関連 ## サポートチケットを確認する {#view-support-tickets} -過去のサポート チケットをすべて表示するには、 [PingCAP ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)にログインし、右上隅のアバターをクリックして、 **[リクエスト]**をクリックします。 +過去のサポートチケットをすべて表示するには、 [PingCAP ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)にログインし、右上隅のアバターをクリックして、 **[リクエスト]**をクリックします。 ## サポートプランを確認またはアップグレードする {#check-or-upgrade-your-support-plan} @@ -153,10 +153,10 @@ TiDB Cloudは、デフォルトで無料の基本サポートプランを提供 ## サポートプランをダウングレードする {#downgrade-your-support-plan} -サポート プランをダウングレードするには、次の手順を実行します。 +サポートプランをダウングレードするには、次の手順を実行します。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左下隅にある**[サポート]**をクリックします。 -2. 切り替えるサポート プランを選択し、 **[ダウングレード]**をクリックします。 +2. 切り替えるサポートプランを選択し、 **[ダウングレード]**をクリックします。 diff --git a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md index 79720246ba5f5..dfe02e43f6ccd 100644 --- a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md +++ b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md @@ -26,7 +26,7 @@ TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスタへの 2. 右上隅の**接続**をクリックします。ダイアログが表示されます。 -3. 接続ダイアログで、 **[接続タイプ]**ドロップダウン リストから**Connection Type**を選択します。 +3. 接続ダイアログで、 **[接続タイプ]**ドロップダウンリストから**Connection Type**を選択します。 IPアクセスリストを設定していない場合は、初回接続前に**Configure IP Access List**をクリックして設定してください。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 @@ -37,7 +37,7 @@ TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスタへの > - ダウンロードしたCA証明書は、オペレーティングシステムのデフォルトのストレージパスに保存することも、別のストレージパスを指定することもできます。以降の手順では、コード例のCA証明書パスをご自身のCA証明書パスに置き換える必要があります。 > - TiDB Cloud Dedicated では、クライアントに TLS 接続の使用を強制しません。また、 [`require_secure_transport`](/system-variables.md#require_secure_transport-new-in-v610)変数のユーザー定義構成は現在TiDB Cloud Dedicated ではサポートされていません。 -5. 希望する接続方法を選択し、タブ上の接続文字列とサンプル コードを参照してクラスターに接続します。 +5. 希望する接続方法を選択し、タブ上の接続文字列とサンプルコードを参照してクラスターに接続します。 次の例は、MySQL、MyCLI、JDBC、Python、Go、Node.js の接続文字列を示しています。 @@ -53,7 +53,7 @@ mysql --connect-timeout 15 --ssl-mode=VERIFY_IDENTITY --ssl-ca=ca.pem --tls-vers パラメータの説明： - `--ssl-mode=VERIFY_IDENTITY`では、MySQL CLI クライアントは TLS を有効にし、 TiDB Cloud Dedicated クラスターを検証することを強制します。 -- `--ssl-ca=`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 +- `--ssl-ca=`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカルパスを指定します。 - TLSプロトコルのバージョンを制限するには、 `--tls-version=TLSv1.2`を使用します。TLS 1.3を使用する場合は、バージョンを`TLSv1.3`に設定できます。
    @@ -68,7 +68,7 @@ mycli --ssl-ca=ca.pem --ssl-verify-server-cert -u root -h tidb.eqlfbdgthh8.clust パラメータの説明： -- `--ssl-ca=`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 +- `--ssl-ca=`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカルパスを指定します。 - `--ssl-verify-server-cert`でTiDB Cloud Dedicated クラスターを検証します。
    @@ -77,7 +77,7 @@ mycli --ssl-ca=ca.pem --ssl-verify-server-cert -u root -h tidb.eqlfbdgthh8.clust ここでは、 [MySQL Connector/J](https://dev.mysql.com/doc/connector-j/en/)の TLS 接続構成が例として使用されています。 -TiDB クラスター CA をダウンロードした後、それをオペレーティング システムにインポートする場合は、 `keytool -importcert -alias TiDBCACert -file ca.pem -keystore -storepass `コマンドを使用できます。 +TiDB クラスター CA をダウンロードした後、それをオペレーティングシステムにインポートする場合は、 `keytool -importcert -alias TiDBCACert -file ca.pem -keystore -storepass `コマンドを使用できます。 ```shell /* Be sure to replace the parameters in the following connection string. */ @@ -140,7 +140,7 @@ jdbc:mysql://tidb.srgnqxji5bc.clusters.staging.tidb-cloud.com:4000/test?user=roo パラメータの説明： - TLS を有効にしてTiDB Cloud Dedicated クラスターを検証するには、 `ssl_mode="VERIFY_IDENTITY"`を設定します。 -- `ssl={"ca": ""}`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカル パスを指定します。 +- `ssl={"ca": ""}`を使用して、ダウンロードした TiDB クラスター`ca.pem`のローカルパスを指定します。
    diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index db4dfeba70b2c..ea0b539bb4aeb 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -47,7 +47,7 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ - [**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) : - **SQL Statement**を使用すると、ページ上のSQL実行を直接観察し、システムテーブルをクエリすることなくパフォーマンスの問題を簡単に特定できます。SQL文をクリックすると、クエリの実行計画をさらに詳しく表示して、トラブルシューティングや分析を行うことができます。SQLパフォーマンスチューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)を参照してください。 - - **Key Visualizer**を使用すると、TiDB のデータ アクセス パターンとデータ ホットスポットを観察できます。 + - **Key Visualizer**を使用すると、TiDB のデータアクセス パターンとデータ ホットスポットを観察できます。 - [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) : このページでは、リクエスト単位、使用済みストレージサイズ、1 秒あたりのクエリ数、平均クエリ実行時間などのメトリックを表示できます。 @@ -79,7 +79,7 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ #### 遅いSQLクエリを最適化する {#optimize-slow-sql-queries} -SQL パフォーマンス チューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)を参照してください。 +SQL パフォーマンスチューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)を参照してください。 #### ホットスポットの問題を解決する {#resolve-hotstpot-issues} diff --git a/tidb-cloud/tidb-node-group-management.md b/tidb-cloud/tidb-node-group-management.md index 0a1c38b4134c0..3a86730c20c8b 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -1,22 +1,22 @@ --- title: Manage TiDB Node Groups -summary: ビジネス ワークロードを分離するために TiDB ノード グループとそのエンドポイントを管理する方法について説明します。 +summary: ビジネスワークロードを分離するために TiDB ノードグループとそのエンドポイントを管理する方法について説明します。 --- # TiDBノードグループの管理 {#manage-tidb-node-groups} -このドキュメントでは、 [TiDB Cloudコンソール](https://tidbcloud.com/)を使用してビジネス ワークロードを分離するために、TiDB ノード グループとそのエンドポイントを管理する方法について説明します。 +このドキュメントでは、 [TiDB Cloudコンソール](https://tidbcloud.com/)を使用してビジネスワークロードを分離するために、TiDB ノードグループとそのエンドポイントを管理する方法について説明します。 > **Note:** > -> TiDB ノード グループ機能は、TiDB Cloud Starter またはTiDB Cloud Essential クラスターでは使用でき**ません**。 +> TiDB ノードグループ機能は、TiDB Cloud Starter またはTiDB Cloud Essential クラスターでは使用でき**ません**。 ## 用語 {#terms} -- TiDB ノード グループ: TiDB ノード グループは、TiDB ノードのグループ化を管理し、エンドポイントと TiDB ノード間のマッピングを維持します。 +- TiDB ノードグループ: TiDB ノードグループは、TiDB ノードのグループ化を管理し、エンドポイントと TiDB ノード間のマッピングを維持します。 - - 各 TiDB ノード グループには一意のエンドポイントがあります。 - - TiDB ノード グループを削除すると、関連するネットワーク設定 (プライベート リンクや IP アクセス リストなど) も削除されます。 + - 各 TiDB ノードグループには一意のエンドポイントがあります。 + - TiDB ノードグループを削除すると、関連するネットワーク設定 (プライベートリンクや IP アクセス リストなど) も削除されます。 - デフォルトグループ: クラスタを作成すると、デフォルトのTiDBノードグループが作成されます。そのため、各クラスタにはデフォルトグループが存在します。デフォルトグループは削除できません。 @@ -31,11 +31,11 @@ summary: ビジネス ワークロードを分離するために TiDB ノード ## TiDBノードグループを作成する {#create-a-tidb-node-group} -TiDB ノード グループを作成するには、次の手順を実行します。 +TiDB ノードグループを作成するには、次の手順を実行します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 +2. 左側のナビゲーションペインで、 **[ノード]**をクリックします。 3. 右上隅の**変更**をクリックします。**Modify Cluster**ページが表示されます。 @@ -67,17 +67,17 @@ TiDBノードグループを作成しても、デフォルトグループのエ パブリック接続を有効にするには、次の手順を実行します。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**接続**をクリックします。接続ダイアログが表示されます。 -3. **TiDB Node Group**リストから TiDB ノード グループを選択し、 **Connection Type**リストから**Public**を選択します。 +3. **TiDB Node Group**リストから TiDB ノードグループを選択し、 **Connection Type**リストから**Public**を選択します。 IP アクセス リストをまだ設定していない場合は、 **Configure IP Access List**をクリックするか、手順[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)に従って、最初の接続の前に設定してください。 -4. 左側のナビゲーション ペインで、 **[設定]** > **[ネットワーク]**をクリックします。 +4. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 -5. **[ネットワーク]**ページで、右上隅の**[TiDB Node Group]**リストから TiDB ノード グループを選択します。 +5. **[ネットワーク]**ページで、右上隅の**[TiDB Node Group]**リストから TiDB ノードグループを選択します。 6. **Public Endpoint**セクションで**Enable**をクリックし、 **IP Access List**セクションで**Add IP Address**をクリックします。 @@ -89,17 +89,17 @@ TiDBノードグループを作成しても、デフォルトグループのエ ### プライベートエンドポイント経由で接続 {#connect-via-private-endpoint} -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**接続**をクリックします。接続ダイアログが表示されます。 -3. **TiDB Node Group**リストから TiDB ノード グループを選択し、**Connection Type**リストから**Private Endpoint**を選択します。 +3. **TiDB Node Group**リストから TiDB ノードグループを選択し、**Connection Type**リストから**Private Endpoint**を選択します。 -4. 左側のナビゲーション ペインで、 **[設定]** > **[ネットワーク]**をクリックします。 +4. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 -5. **[ネットワーク]**ページで、右上隅の**[TiDB Node Group]**リストから TiDB ノード グループを選択します。 +5. **[ネットワーク]**ページで、右上隅の**[TiDB Node Group]**リストから TiDB ノードグループを選択します。 -6. このノード グループの新しい接続を作成するには、 **[Create Private Endpoint Connection]**をクリックします。 +6. このノードグループの新しい接続を作成するには、 **[Create Private Endpoint Connection]**をクリックします。 - AWS にデプロイされたクラスターについては、 [AWS PrivateLink 経由でTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 @@ -107,25 +107,25 @@ TiDBノードグループを作成しても、デフォルトグループのエ > **Note:** > - > Private Link を使用して異なるノード グループを接続する場合は、ノード グループごとに個別のプライベート エンドポイント接続を作成する必要があります。 + > Private Link を使用して異なるノードグループを接続する場合は、ノードグループごとに個別のプライベートエンドポイント接続を作成する必要があります。 -7. プライベート エンドポイント接続を作成したら、ページの右上隅にある**[接続]**をクリックして接続文字列を取得します。 +7. プライベートエンドポイント接続を作成したら、ページの右上隅にある**[接続]**をクリックして接続文字列を取得します。 ### 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)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 -3. 左側のナビゲーション ペインで、 **[設定]** > **[ネットワーク]**をクリックします。 +2. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 +3. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 4. **[ネットワーク]**ページの右上隅にある**[接続]**をクリックして、接続文字列を取得します。 ## TiDBノードグループを確認する {#view-tidb-node-groups} -TiDB ノード グループの詳細を表示するには、次の手順を実行します。 +TiDB ノードグループの詳細を表示するには、次の手順を実行します。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーション ペインで**[ノード]**をクリックして、TiDB ノード グループのリストを表示します。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 +2. 左側のナビゲーションペインで**[ノード]**をクリックして、TiDB ノードグループのリストを表示します。 テーブルビューに切り替えるには、 。 @@ -137,21 +137,20 @@ TiDB ノード グループの詳細を表示するには、次の手順を実 グループ名を変更するには、次の手順を実行します。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 -3. クリック TiDB ノード グループの新しい名前を入力します。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 +2. 左側のナビゲーションペインで、 **[ノード]**をクリックします。 +3. クリック TiDB ノードグループの新しい名前を入力します。 ### ノード構成を更新する {#update-the-node-configuration} グループ内の TiDB、TiKV、またはTiFlashノード構成を更新するには、次の手順を実行します。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 -3. **Node Map**ページで、右上隅の**変更**をクリックします。**Modify Cluster**ページが表示されます。 -4. **Modify Cluster**ページでは、次の操作を実行できます。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 +2. 左側のナビゲーションペインで、 **[ノード]**をクリックします。 +3. **Node Map**ページで、右上隅の**変更**をクリックします。**Modify Cluster**ページが表示されます。4. **Modify Cluster**ページでは、次の操作を実行できます。 - TiDB ノードの数を変更します。 - - 新しいノード グループを追加します。 + - 新しいノードグループを追加します。 - TiKV ノードとTiFlashノードのサイズと**Storage x Nodes**構成を更新します。 ![Change TiDB node group node count](/media/tidb-cloud/tidb-node-group-change-node-count.png) @@ -160,13 +159,12 @@ TiDB ノード グループの詳細を表示するには、次の手順を実 > **Note:** > -> TiDB ノード グループを削除すると、プライベート エンドポイント接続やパブリック アクセス用の IP リストなど、そのノードとネットワーク構成も削除されます。 +> TiDB ノードグループを削除すると、プライベートエンドポイント接続やパブリックアクセス用の IP リストなど、そのノードとネットワーク構成も削除されます。 -TiDB ノード グループを削除するには、次の手順を実行します。 +TiDB ノードグループを削除するには、次の手順を実行します。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲットクラスターの名前をクリックして概要ページに移動します。 +2. 左側のナビゲーションペインで、 **[ノード]**をクリックします。 3. **Node Map**ページで、右上隅の**変更**をクリックします。**Modify Cluster**ページが表示されます。 -4. **Modify Cluster**ページで、 TiDB ノード グループを削除します。 - +4. **Modify Cluster**ページで、 TiDB ノードグループを削除します。 ![Delete the TiDB node group](/media/tidb-cloud/tidb-node-group-delete.png) diff --git a/tidb-cloud/tidb-node-group-overview.md b/tidb-cloud/tidb-node-group-overview.md index 3c55a466f03e3..fb3b329960529 100644 --- a/tidb-cloud/tidb-node-group-overview.md +++ b/tidb-cloud/tidb-node-group-overview.md @@ -1,6 +1,6 @@ --- title: Overview of TiDB Node Group -summary: TiDB ノード グループ機能の実装と使用シナリオについて説明します。 +summary: TiDB ノードグループ機能の実装と使用シナリオについて説明します。 --- # TiDBノードグループの概要 {#overview-of-tidb-node-group} @@ -11,21 +11,21 @@ TiDBノードグループを使用すると、ビジネス要件に基づいて > **Note:** > -> TiDB ノード グループ機能は、TiDB Cloud Starter およびTiDB Cloud Essential クラスターでは使用でき**ません**。 +> TiDB ノードグループ機能は、TiDB Cloud Starter およびTiDB Cloud Essential クラスターでは使用でき**ません**。 ## 実装 {#implementation} -TiDB ノード グループは、TiDB ノードのグループ化を管理し、エンドポイントと対応する TiDB ノード間のマッピングを維持します。 +TiDB ノードグループは、TiDB ノードのグループ化を管理し、エンドポイントと対応する TiDB ノード間のマッピングを維持します。 各TiDBノードグループは専用のロードバランサに関連付けられています。ユーザーがTiDBノードグループのエンドポイントにSQLリクエストを送信すると、リクエストはまずそのグループのロードバランサを通過し、その後、グループ内のTiDBノードにのみルーティングされます。 -次の図は、TiDB ノード グループ機能の実装を示しています。 +次の図は、TiDB ノードグループ機能の実装を示しています。 ![The implementation of the TiDB Node Group feature](/media/tidb-cloud/implementation-of-tidb-node-group.png) TiDBノードグループ内のすべてのノードは、対応するエンドポイントからのリクエストに応答します。以下のタスクを実行できます。 -- TiDB ノード グループを作成し、それに TiDB ノードを割り当てます。 +- TiDB ノードグループを作成し、それに TiDB ノードを割り当てます。 - 各グループの接続エンドポイントを設定します。サポートされている接続タイプは[パブリック接続](/tidb-cloud/tidb-node-group-management.md#connect-via-public-connection) 、 [プライベートエンドポイント](/tidb-cloud/tidb-node-group-management.md#connect-via-private-endpoint) 、 [VPCピアリング](/tidb-cloud/tidb-node-group-management.md#connect-via-vpc-peering)です。 - 個別のエンドポイントを使用してアプリケーションを特定のグループにルーティングし、リソースの分離を実現します。 @@ -48,14 +48,14 @@ TiDBノードグループ機能は、TiDB Cloud Dedicatedクラスタのリソ 現在、TiDBノードグループ機能は無料です。制限事項とクォータは次のとおりです。 - TiDB ノードグループは、AWS または Google Cloud 上のTiDB Cloud Dedicated クラスターでのみ作成できます。他のクラウドプロバイダーへのサポートは、近い将来に予定されています。 -- 4 つの vCPU と 16 GiB のメモリを備えた TiDB クラスターは、TiDB ノード グループ機能をサポートしません。 +- 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 ノード グループ内で分離することはできません。 +- v8.1.2 より前のバージョンの TiDB クラスターの場合、 `ADD INDEX`タスクを個々の TiDB ノードグループ内で分離することはできません。 ## SLAの影響 {#sla-impact} 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..457303620ec76 100644 --- a/tidb-cloud/tidb-x-architecture.md +++ b/tidb-cloud/tidb-x-architecture.md @@ -39,7 +39,7 @@ TiDB X は[クラシックTiDB](/tidb-architecture.md)の共有なしアーキ - **安定性とパフォーマンスの干渉** - - リソース競合：書き込みトラフィックが増加すると、SST ファイルをマージするための大規模なローカル圧縮ジョブが実行されます。従来の TiDB では、これらの圧縮ジョブはオンライン トラフィックを処理する同じ TiKV ノードで実行されるため、同じ CPU および I/O リソースを競合し、オンライン アプリケーションに影響を与える可能性があります。 + - リソース競合：書き込みトラフィックが増加すると、SST ファイルをマージするための大規模なローカル圧縮ジョブが実行されます。従来の TiDB では、これらの圧縮ジョブはオンライン トラフィックを処理する同じ TiKV ノードで実行されるため、同じ CPU および I/O リソースを競合し、オンラインアプリケーションに影響を与える可能性があります。 - 物理的な分離の欠如：論理リージョンと物理的なSSTファイルの間には物理的な分離がありません。リージョンの移動（バランス調整）などの操作は、圧縮オーバーヘッドを発生させ、それがユーザーのクエリと直接競合するため、パフォーマンスの不安定性につながる可能性があります。 @@ -129,11 +129,10 @@ TiDB Xは、従来の**共有なし**アーキテクチャ（TiKVノード間で 従来のTiDBでは、ピーク時のトラフィックとバックグラウンドタスクを同時に処理するために、クラスタが過剰にプロビジョニングされることがよくありました。TiDB Xは**オートスケーリング**に対応しており、ユーザーは消費したリソースに対してのみ料金を支払うことができます（従量課金制）。負荷の高いタスク用のバックグラウンドリソースは必要に応じてプロビジョニングされ、不要になった時点で解放されるため、無駄なコストを削減できます。 -TiDB X は、 [リクエストキャパシティユニット](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)(RCU) を使用してプロビジョニングされたコンピューティング容量を測定します。1 RCU は、一定数の SQL リクエストを処理できる固定量のコンピューティング リソースを提供します。プロビジョニングする RCU の数によって、TiDB X インスタンスのベースラインのパフォーマンスとスループット容量が決まります。上限を設定することで、弾力的なスケーリングのメリットを享受しながらコストを管理できます。 - +TiDB X は、 [リクエストキャパシティユニット](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)(RCU) を使用してプロビジョニングされたコンピューティング容量を測定します。1 RCU は、一定数の SQL リクエストを処理できる固定量のコンピューティングリソースを提供します。プロビジョニングする RCU の数によって、TiDB X インスタンスのベースラインのパフォーマンスとスループット容量が決まります。上限を設定することで、弾力的なスケーリングのメリットを享受しながらコストを管理できます。 ### 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 つのリージョンに対する操作は、そのリージョンのツリー内に限定され、グローバルなミューテックスの競合は発生しません。 diff --git a/tidb-cloud/tidbx-instance-move-faq.md b/tidb-cloud/tidbx-instance-move-faq.md index 378f81d801095..18258a3f9833c 100644 --- a/tidb-cloud/tidbx-instance-move-faq.md +++ b/tidb-cloud/tidbx-instance-move-faq.md @@ -124,7 +124,7 @@ TiDB Cloudのリソースごとに異なるプロジェクトタイプが導入 ## 移行後にはどのような対応が必要ですか？ {#what-actions-are-required-after-migration} -TiDB Cloud StarterまたはEssentialインスタンスを新しい TiDB X プロジェクトに移行した場合は、以下の項目など、元のプロジェクト ID または元のプロジェクト レベルの設定に依存するものを確認してください。 +TiDB Cloud StarterまたはEssentialインスタンスを新しい TiDB X プロジェクトに移行した場合は、以下の項目など、元のプロジェクト ID または元のプロジェクトレベルの設定に依存するものを確認してください。 - 自動化またはスクリプト - 統合 diff --git a/tidb-cloud/tiproxy-management.md b/tidb-cloud/tiproxy-management.md index 8e2cf3fe60039..d625c0f5cfbf6 100644 --- a/tidb-cloud/tiproxy-management.md +++ b/tidb-cloud/tiproxy-management.md @@ -125,4 +125,4 @@ TiProxyをスケールインまたはスケールアウトするには、以下 ## 複数のTiDBノードグループでTiProxyを管理する {#manage-tiproxy-in-multiple-tidb-node-groups} -複数の TiDB ノード グループがある場合、各 TiDB ノード グループには専用の TiProxy グループが割り当てられます。TiProxy は、同じ TiDB ノード グループ内の TiDB ノードにトラフィックをルーティングし、コンピューティング リソースを分離します。各 TiDB ノード グループで TiProxy を有効化、無効化、または変更できます。ただし、すべての TiDB ノード グループで TiProxy のサイズは同じである必要があります。 +複数の TiDB ノードグループがある場合、各 TiDB ノードグループには専用の TiProxy グループが割り当てられます。TiProxy は、同じ TiDB ノードグループ内の TiDB ノードにトラフィックをルーティングし、コンピューティングリソースを分離します。各 TiDB ノードグループで TiProxy を有効化、無効化、または変更できます。ただし、すべての TiDB ノードグループで TiProxy のサイズは同じである必要があります。 diff --git a/tidb-cloud/top-ru.md b/tidb-cloud/top-ru.md index ff539232f6dbb..952854f4dbeb2 100644 --- a/tidb-cloud/top-ru.md +++ b/tidb-cloud/top-ru.md @@ -27,7 +27,7 @@ TiDB Cloudプランによって、RUの主要機能は異なります。 ## オープントップRU {#open-top-ru} 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、 TiDB Cloud EssentialまたはTiDB Cloud Premiumインスタンスに移動してください。 -2. 左側のナビゲーション ペインで、 **[監視]** > **Top RU**をクリックします。 +2. 左側のナビゲーションペインで、 **[監視]** > **Top RU**をクリックします。 ## SQLによるRU消費量の分析 {#analyze-ru-consumption-by-sql} diff --git a/tidb-cloud/transaction-concepts.md b/tidb-cloud/transaction-concepts.md index c75ef69231803..2483ea196ab78 100644 --- a/tidb-cloud/transaction-concepts.md +++ b/tidb-cloud/transaction-concepts.md @@ -19,7 +19,7 @@ TiDBの楽観的トランザクションモデルは、コミットフェーズ TiDBでは、悲観的トランザクションモードはMySQLとほぼ同じ動作をします。トランザクションは実行フェーズでロックを適用し、競合状況での再試行を回避し、高い成功率を保証します。悲観的ロックを適用することで、 `SELECT FOR UPDATE`を使用して事前にデータをロックすることもできます。 -ただし、アプリケーション シナリオの競合が少ない場合は、楽観的トランザクション モデルの方がパフォーマンスが向上します。 +ただし、アプリケーションシナリオの競合が少ない場合は、楽観的トランザクションモデルの方がパフォーマンスが向上します。 詳細については[TiDB 悲観的トランザクションモード](/pessimistic-transaction.md)を参照してください。 diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index c6d2c553032c2..6d3bd73e56110 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -15,17 +15,17 @@ Chat2Query API には HTTPS 経由でのみアクセスできるため、ネッ ## 始める前に {#before-you-begin} -Chat2Query エンドポイントを呼び出す前に、Chat2Query データ アプリを作成し、データ アプリの API キーを作成する必要があります。 +Chat2Query エンドポイントを呼び出す前に、Chat2Query データアプリを作成し、データアプリの API キーを作成する必要があります。 ### Chat2Queryデータアプリを作成する {#create-a-chat2query-data-app} -プロジェクトのデータ アプリを作成するには、次の手順を実行します。 +プロジェクトのデータアプリを作成するには、次の手順を実行します。 1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左ペインで**Create DataApp**をクリックします。データアプリ作成ダイアログが表示されます。 > **Tip:** > - > クラスターの**SQL Editor**ページが表示されている場合は、右上隅の**...**をクリックし、 **Access Chat2Query via API**を選択して、**New Chat2Query Data App**をクリックすることで、データ アプリ作成ダイアログを開くこともできます。 + > クラスターの**SQL Editor**ページが表示されている場合は、右上隅の**...**をクリックし、 **Access Chat2Query via API**を選択して、**New Chat2Query Data App**をクリックすることで、データアプリ作成ダイアログを開くこともできます。 2. ダイアログで、データアプリの名前を定義し、データソースとして必要なクラスターを選択し、**Data App**の種類として**Chat2Query Data App**を選択します。必要に応じて、アプリの説明を記入することもできます。 @@ -35,11 +35,11 @@ Chat2Query エンドポイントを呼び出す前に、Chat2Query データ ア ### APIキーを作成する {#create-an-api-key} -エンドポイントを呼び出す前に、エンドポイントがTiDB Cloudクラスターのデータにアクセスするために使用する Chat2Query データ アプリの API キーを作成する必要があります。 +エンドポイントを呼び出す前に、エンドポイントがTiDB Cloudクラスターのデータにアクセスするために使用する Chat2Query データアプリの API キーを作成する必要があります。 API キーを作成するには、次の手順を実行します。 -1. [**Data Service**](https://tidbcloud.com/project/data-service)の左側のペインで、Chat2Query データ アプリをクリックすると、右側にその詳細が表示されます。 +1. [**Data Service**](https://tidbcloud.com/project/data-service)の左側のペインで、Chat2Query データアプリをクリックすると、右側にその詳細が表示されます。 2. **認証**領域で、 **Create API Key**をクリックします。 @@ -71,7 +71,7 @@ API キーを作成するには、次の手順を実行します。 > > Chat2Queryデータアプリには、1日あたり100リクエストのレート制限があります。レート制限を超えた場合、APIは`429`エラーを返します。クォータを増やすには、サポートチームまで[リクエストを送信する](https://tidb.support.pingcap.com/)ことができます。 -各 Chat2Query データ アプリには、次のエンドポイントがあります。 +各 Chat2Query データアプリには、次のエンドポイントがあります。 - Chat2Query v3エンドポイント: `/v3/dataSummaries`や`/v3/chat2data`など、名前が`/v3`で始まるエンドポイント(推奨) - Chat2Query v2エンドポイント: `/v2/dataSummaries`や`/v2/chat2data`など、名前が`/v2`で始まるエンドポイント @@ -87,11 +87,11 @@ TiDB Cloudは、Chat2Queryエンドポイントを素早く呼び出すための 1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、Chat2Query エンドポイントの名前をクリックします。 - エンドポイント URL、コード例、リクエスト メソッドなど、このエンドポイントを呼び出すための情報が右側に表示されます。 + エンドポイント URL、コード例、リクエストメソッドなど、このエンドポイントを呼び出すための情報が右側に表示されます。 2. **[Show Code Example]**をクリックします。 -3. 表示されたダイアログ ボックスで、エンドポイントの呼び出しに使用するクラスター、データベース、および認証方法を選択し、コード例をコピーします。 +3. 表示されたダイアログボックスで、エンドポイントの呼び出しに使用するクラスター、データベース、および認証方法を選択し、コード例をコピーします。 > **Note:** > @@ -105,20 +105,20 @@ TiDB Cloud Data Serviceは、次の Chat2Query v3 エンドポイントと v2 | メソッド | エンドポイント | 説明 | | -- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -| POST | `/v3/dataSummaries` | このエンドポイントは、分析に人工知能を使用して、データベース スキーマ、テーブル スキーマ、および列スキーマのデータ サマリーを生成します。 | +| POST | `/v3/dataSummaries` | このエンドポイントは、分析に人工知能を使用して、データベーススキーマ、テーブルスキーマ、および列スキーマのデータ サマリーを生成します。 | | GET | `/v3/dataSummaries` | このエンドポイントは、データベースのすべてのデータ概要を取得します。 | | GET | `/v3/dataSummaries/{data_summary_id}` | このエンドポイントは、特定のデータの概要を取得します。 | | PUT | `/v3/dataSummaries/{data_summary_id}` | このエンドポイントは、特定のデータ サマリーを更新します。 | | PUT | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}` | このエンドポイントは、特定のデータ サマリー内の特定のテーブルの説明を更新します。 | | PUT | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}/columns` | このエンドポイントは、特定のデータ サマリー内の特定のテーブルの列の説明を更新します。 | | POST | `/v3/knowledgeBases` | このエンドポイントは新しいナレッジベースを作成します。ナレッジベース関連のエンドポイントの使用方法の詳細については、 [ナレッジベースを活用する](/tidb-cloud/use-chat2query-knowledge.md)を参照してください。 | -| GET | `/v3/knowledgeBases` | このエンドポイントはすべてのナレッジ ベースを取得します。 | -| GET | `/v3/knowledgeBases/{knowledge_base_id}` | このエンドポイントは、特定のナレッジ ベースを取得します。 | -| PUT | `/v3/knowledgeBases/{knowledge_base_id}` | このエンドポイントは、特定のナレッジ ベースを更新します。 | -| POST | `/v3/knowledgeBases/{knowledge_base_id}/data` | このエンドポイントは、特定のナレッジ ベースにデータを追加します。 | -| GET | `/v3/knowledgeBases/{knowledge_base_id}/data` | このエンドポイントは、特定のナレッジ ベースからデータを取得します。 | -| PUT | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | このエンドポイントは、ナレッジ ベース内の特定のデータを更新します。 | -| DELETE | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | このエンドポイントは、ナレッジ ベースから特定のデータを削除します。 | +| GET | `/v3/knowledgeBases` | このエンドポイントはすべてのナレッジベースを取得します。 | +| GET | `/v3/knowledgeBases/{knowledge_base_id}` | このエンドポイントは、特定のナレッジベースを取得します。 | +| PUT | `/v3/knowledgeBases/{knowledge_base_id}` | このエンドポイントは、特定のナレッジベースを更新します。 | +| POST | `/v3/knowledgeBases/{knowledge_base_id}/data` | このエンドポイントは、特定のナレッジベースにデータを追加します。 | +| GET | `/v3/knowledgeBases/{knowledge_base_id}/data` | このエンドポイントは、特定のナレッジベースからデータを取得します。 | +| PUT | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | このエンドポイントは、ナレッジベース内の特定のデータを更新します。 | +| DELETE | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | このエンドポイントは、ナレッジベースから特定のデータを削除します。 | | POST | `/v3/sessions` | このエンドポイントは新しいセッションを作成します。セッション関連のエンドポイントの使用方法の詳細については、 [マルチラウンドChat2Queryを開始する](/tidb-cloud/use-chat2query-sessions.md)を参照してください。 | | GET | `/v3/sessions` | このエンドポイントは、すべてのセッションのリストを取得します。 | | GET | `/v3/sessions/{session_id}` | このエンドポイントは、特定のセッションの詳細を取得します。 | @@ -128,7 +128,7 @@ TiDB Cloud Data Serviceは、次の Chat2Query v3 エンドポイントと v2 | POST | `/v3/chat2data` | このエンドポイントを使用すると、データ サマリー ID と指示を提供することで、人工知能を使用して SQL ステートメントを生成および実行できます。 | | POST | `/v3/refineSql` | このエンドポイントは、人工知能を使用して既存の SQL クエリを改良します。 | | POST | `/v3/suggestQuestions` | このエンドポイントは、提供されたデータの概要に基づいて質問を提案します。 | -| POST | `/v2/dataSummaries` | このエンドポイントは、人工知能を使用して、データベース スキーマ、テーブル スキーマ、および列スキーマのデータ サマリーを生成します。 | +| POST | `/v2/dataSummaries` | このエンドポイントは、人工知能を使用して、データベーススキーマ、テーブルスキーマ、および列スキーマのデータ サマリーを生成します。 | | GET | `/v2/dataSummaries` | このエンドポイントはすべてのデータ概要を取得します。 | | POST | `/v2/chat2data` | このエンドポイントを使用すると、データ サマリー ID と指示を提供することで、人工知能を使用して SQL ステートメントを生成および実行できます。 | | GET | `/v2/jobs/{job_id}` | このエンドポイントを使用すると、特定のデータ サマリー生成ジョブのステータスを照会できます。 | @@ -278,7 +278,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https:// **Note:** > @@ -15,7 +15,7 @@ v3 以降、Chat2Query API を使用すると、Chat2Query データ アプリ ## 始める前に {#before-you-begin} -データベースのナレッジ ベースを作成する前に、次のものを用意してください。 +データベースのナレッジベースを作成する前に、次のものを用意してください。 - A [Chat2Queryデータアプリ](/tidb-cloud/use-chat2query-api.md#create-a-chat2query-data-app) - [Chat2QueryデータアプリのAPIキー](/tidb-cloud/use-chat2query-api.md#create-an-api-key) diff --git a/tidb-cloud/use-chat2query-sessions.md b/tidb-cloud/use-chat2query-sessions.md index b17ecf5e35dd1..d8fb6197321eb 100644 --- a/tidb-cloud/use-chat2query-sessions.md +++ b/tidb-cloud/use-chat2query-sessions.md @@ -17,7 +17,7 @@ Chat2Query API v3以降では、セッション関連のエンドポイントを ## ステップ1. セッションを開始する {#step-1-start-a-session} -セッションを開始するには、Chat2Query データ アプリの`/v3/sessions`エンドポイントを呼び出します。 +セッションを開始するには、Chat2Query データアプリの`/v3/sessions`エンドポイントを呼び出します。 以下は、このエンドポイントを呼び出すための一般的なコード例です。 diff --git a/tidb-cloud/use-tidb-cloud-with-ai-tools.md b/tidb-cloud/use-tidb-cloud-with-ai-tools.md index 83c5c693dc9b5..8e6ca4740deb2 100644 --- a/tidb-cloud/use-tidb-cloud-with-ai-tools.md +++ b/tidb-cloud/use-tidb-cloud-with-ai-tools.md @@ -7,7 +7,7 @@ summary: TiDB Cloud Starter クラスターを、Cursor、Claude Code、VS Code このドキュメントでは、Cursor、Claude Code、Visual Studio Code (VS Code)、Windsurf などのモデル コンテキスト プロトコル (MCP) をサポートする AI 搭載開発ツールにTiDB Cloud Starter クラスターを接続する方法について説明します。 -TiDB Cloud Starter クラスターを MCPサーバーとして構成すると、開発ツールの AI アシスタントを有効にして、データベース スキーマを照会し、データ モデルを理解し、コンテキストに応じたコード提案を生成できるようになります。 +TiDB Cloud Starter クラスターを MCPサーバーとして構成すると、開発ツールの AI アシスタントを有効にして、データベーススキーマを照会し、データモデルを理解し、コンテキストに応じたコード提案を生成できるようになります。 ## 始める前に {#before-you-begin} @@ -43,7 +43,7 @@ TiDB CloudでTiDB Cloud Starter クラスターを作成したら、次の手順 - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして、新しいパスワードを生成します。 - パスワードをリセットすると、既存のすべての root ユーザー セッションが切断されることに注意してください。 + パスワードをリセットすると、既存のすべての root ユーザーセッションが切断されることに注意してください。 5. AI ツールのタブを選択します: **Cursor** 、 **Claude Code** 、 **VS Code** 、または**Windsurf** 。 diff --git a/tidb-cloud/v8.5-performance-highlights.md b/tidb-cloud/v8.5-performance-highlights.md index 82b1ced64a49e..546bff071f3c4 100644 --- a/tidb-cloud/v8.5-performance-highlights.md +++ b/tidb-cloud/v8.5-performance-highlights.md @@ -26,7 +26,7 @@ summary: TiDB バージョン v8.5.0 では、 TiDB Cloud Dedicated クラスタ ### チャレンジ {#challenge} -一部のユーザー シナリオでは、次のような課題が発生する可能性があります。 +一部のユーザーシナリオでは、次のような課題が発生する可能性があります。 - 頻繁なバージョン更新: 一部のワークロードでは、データが非常に頻繁に更新され、読み取られます。 - 履歴バージョンの長期保存：特定の時点へのフラッシュバックのサポートといったビジネス要件を満たすために、ユーザーはGC（ガベージコレクション）時間を過度に長く（例えば24時間など）設定することがあります。その結果、多版型同時実行制御（MVCC）バージョンが過剰に蓄積され、クエリの効率が大幅に低下します。 @@ -70,7 +70,7 @@ MVCC バージョンが蓄積されると、要求されたデータと処理さ ### 解決 {#solution} -TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォーマンスへの影響を軽減するための複数の機能強化が導入されています。 +TiDB v8.5.0 では、クラウドディスク IO ジッターによるパフォーマンスへの影響を軽減するための複数の機能強化が導入されています。 - **Leader書き込み最適化**: リーダーがコミットされたがまだ永続化されていないRaftログを早期に適用できるようにし、リーダー ピアの書き込みレイテンシーに対する IO ジッターの影響を軽減します。 @@ -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} @@ -99,7 +99,7 @@ TiDB v8.5.0 では、クラウド ディスク IO ジッターによるパフォ ディスクジッターの重大度は、ユーザーのワークロードプロファイルにも大きく関係する可能性があります。レイテンシの影響を受けやすいシナリオでは、TiDBの機能と組み合わせてアプリケーションを設計することで、アプリケーションへのIOジッターの影響をさらに最小限に抑えることができます。例えば、読み取り負荷が高くレイテンシの影響を受けやすい環境では、レイテンシー要件に応じて[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)システム変数を調整し、ステイルリードまたはフォロワーリードを使用することで、TiDBから送信されたKVリクエストに対する他のレプリカピアへのフェイルオーバー再試行を高速化できます。これにより、単一のTiKVノードへのIOジッターの影響が軽減され、クエリレイテンシーの改善に役立ちます。この機能の有効性はワークロードプロファイルに依存するため、実装前に評価する必要があります。 -さらに、ユーザー[パブリッククラウドへのTiDBの導入](https://docs.pingcap.com/tidb/dev/best-practices-on-public-cloud)は、より高性能なクラウド ディスクを選択することで、ジッターの可能性を減らすことができます。 +さらに、ユーザー[パブリッククラウドへのTiDBの導入](https://docs.pingcap.com/tidb/dev/best-practices-on-public-cloud)は、より高性能なクラウドディスクを選択することで、ジッターの可能性を減らすことができます。 ## バッチ処理 {#batch-processing} @@ -183,7 +183,7 @@ TiKV スケーリング パフォーマンスは 40% 以上向上し、TiKV ノ ## ベンチマーク {#benchmark} -前述のテスト データに加えて、v8.5.0 のパフォーマンスに関する次のベンチマーク結果を参照できます。 +前述のテストデータに加えて、v8.5.0 のパフォーマンスに関する次のベンチマーク結果を参照できます。 - [TPC-Cパフォーマンステストレポート](/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md) - [Sysbenchパフォーマンステストレポート](/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md) diff --git a/tidb-computing.md b/tidb-computing.md index 67f48402c2850..8202d4890b82a 100644 --- a/tidb-computing.md +++ b/tidb-computing.md @@ -14,13 +14,13 @@ TiKVが提供する分散ストレージをベースに、TiDBは優れたトラ このセクションでは、TiDBにおけるキーと値のペア（キー、値）へのデータのマッピング方法について説明します。ここでマッピングされるデータには、以下の2つの種類が含まれます。 - テーブル内の各行のデータ（以下、テーブルデータと呼びます）。 -- テーブル内のすべてのインデックスのデータ（以下、インデックス データと呼びます）。 +- テーブル内のすべてのインデックスのデータ（以下、インデックスデータと呼びます）。 ### テーブルデータからキー値へのマッピング {#mapping-of-table-data-to-key-value} リレーショナルデータベースでは、テーブルに多数の列が含まれる場合があります。行内の各列のデータを（キー、値）キーと値のペアにマッピングするには、キーの構築方法を検討する必要があります。まず、OLTPシナリオでは、単一行または複数行のデータの追加、削除、変更、検索などの操作が多数発生するため、データベースはデータ行を迅速に読み取る必要があります。そのため、各キーには、キーを迅速に特定できるように、明示的または暗黙的な一意のIDが必要です。また、多くのOLAPクエリでは、テーブル全体のスキャンが必要です。テーブル内のすべての行のキーを範囲にエンコードできれば、範囲クエリによってテーブル全体を効率的にスキャンできます。 -上記の考慮事項に基づいて、TiDB のテーブル データと Key-Value のマッピングは次のように設計されます。 +上記の考慮事項に基づいて、TiDB のテーブルデータと Key-Value のマッピングは次のように設計されます。 - 同じテーブルのデータがまとめて保存され、簡単に検索できるように、TiDB は各テーブルにテーブル ID を割り当てます。テーブル ID は`TableID`で表されます。テーブル ID はクラスター全体で一意の整数です。 - TiDBは、テーブル内の各データ行に行ID（ `RowID`で表されます）を割り当てます。行IDも整数で、テーブル内で一意です。行IDに関しては、TiDBは小さな最適化を行っています。テーブルに整数型の主キーがある場合、TiDBはこの主キーの値を行IDとして使用します。 @@ -89,7 +89,7 @@ CREATE TABLE User ( t10_i1_20_2 --> null t10_i1_30_3 --> null -上記の例は、TiDB におけるリレーショナル モデルからキー値モデルへのマッピング ルールと、このマッピング スキームの背後にある考慮事項を示しています。 +上記の例は、TiDB におけるリレーショナル モデルからキー値モデルへのマッピングルールと、このマッピング スキームの背後にある考慮事項を示しています。 ## メタデータ管理 {#metadata-management} @@ -97,7 +97,7 @@ TiDBの各データベースとテーブルには、その定義と様々な属 各データベースまたはテーブルには、一意のIDが割り当てられます。テーブルデータがKey-Valueにエンコードされる際、このIDは一意の識別子として、Keyに`m_`プレフィックスを付けてエンコードされます。これにより、シリアル化されたメタデータが格納されたKey-Valueペアが構築されます。 -さらに、TiDB は専用の (Key, Value) キーと値のペアを使用して、すべてのテーブルの構造情報の最新のバージョン番号を保存します。このキーと値のペアはグローバルであり、DDL 操作の状態が変化するたびにバージョン番号が`1`ずつ増加します。TiDB は、このキーと値のペアをキー`/tidb/ddl/global_schema_version` 、値が`int64`型のバージョン番号の値として PDサーバーに永続的に保存します。一方、TiDB はスキーマ変更をオンラインで適用するため、PDサーバーに保存されているテーブル構造情報のバージョン番号が変更されていないかどうかを常にチェックするバックグラウンド スレッドを維持します。このスレッドにより、バージョンの変更が一定期間内に取得されることも保証されます。 +さらに、TiDB は専用の (Key, Value) キーと値のペアを使用して、すべてのテーブルの構造情報の最新のバージョン番号を保存します。このキーと値のペアはグローバルであり、DDL 操作の状態が変化するたびにバージョン番号が`1`ずつ増加します。TiDB は、このキーと値のペアをキー`/tidb/ddl/global_schema_version` 、値が`int64`型のバージョン番号の値として PDサーバーに永続的に保存します。一方、TiDB はスキーマ変更をオンラインで適用するため、PDサーバーに保存されているテーブル構造情報のバージョン番号が変更されていないかどうかを常にチェックするバックグラウンドスレッドを維持します。このスレッドにより、バージョンの変更が一定期間内に取得されることも保証されます。 ## SQLレイヤーの概要 {#sql-layer-overview} diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index b116efc9b85a5..0690f371e9d03 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -9,7 +9,7 @@ summary: コマンドラインオプションに関係しない、TiDB設定フ # TiDBコンフィグレーションファイル {#tidb-configuration-file} -TiDB 構成ファイルは、コマンドライン パラメーターよりも多くのオプションをサポートしています。デフォルトの構成ファイル[`config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example)をダウンロードし、その名前を`config.toml`に変更できます。本書では[コマンドラインオプション](/command-line-flags-for-tidb-configuration.md)に関係のないオプションのみを説明します。 +TiDB 構成ファイルは、コマンドラインパラメーターよりも多くのオプションをサポートしています。デフォルトの構成ファイル[`config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example)をダウンロードし、その名前を`config.toml`に変更できます。本書では[コマンドラインオプション](/command-line-flags-for-tidb-configuration.md)に関係のないオプションのみを説明します。 > **Tip:** > @@ -197,7 +197,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - TCP4のみでのリスニングを有効または無効にします。 - デフォルト値: `false` -- [TCPヘッダーからの実際のクライアントIP](https://github.com/alibaba/LVS/tree/master/kernel/net/toa)が「tcp4」プロトコルで正しく解析できるため、ロード バランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。 +- [TCPヘッダーからの実際のクライアントIP](https://github.com/alibaba/LVS/tree/master/kernel/net/toa)が「tcp4」プロトコルで正しく解析できるため、ロードバランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。 ### `enable-enum-length-limit` v5.0で追加 {#enable-enum-length-limit-new-in-v50} @@ -320,13 +320,13 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - デフォルト値: `300` - 単位：ミリ秒 - クエリの実行時間がこの値よりも長い場合、そのクエリはスロークエリとみなされ、そのログがスロークエリログに出力されます。なお、 [`log.level`](#level)の出力レベルが`"debug"`の場合、このパラメータの設定に関わらず、すべてのクエリがスロークエリログに記録されます。 -- バージョン 6.1.0 以降、スロー ログの消費時間のしきい値は、TiDB 設定項目の[`instance.tidb_slow_log_threshold`](/tidb-configuration-file.md#tidb_slow_log_threshold)またはシステム変数[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)で指定されます。 `slow-threshold`は引き続き有効です。ただし、 `slow-threshold`と`instance.tidb_slow_log_threshold`が同時に設定されている場合、後者が有効になります。 +- バージョン 6.1.0 以降、スローログの消費時間のしきい値は、TiDB 設定項目の[`instance.tidb_slow_log_threshold`](/tidb-configuration-file.md#tidb_slow_log_threshold)またはシステム変数[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)で指定されます。 `slow-threshold`は引き続き有効です。ただし、 `slow-threshold`と`instance.tidb_slow_log_threshold`が同時に設定されている場合、後者が有効になります。 ### `record-plan-in-slow-log` {#record-plan-in-slow-log} - 実行計画をスローログに記録するかどうかを決定します。 - デフォルト値: `1` -- バージョン 6.1.0 以降、実行計画をスロー ログに記録するかどうかは、TiDB 設定項目の[`instance.tidb_record_plan_in_slow_log`](/tidb-configuration-file.md#tidb_record_plan_in_slow_log)またはシステム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)によって決定されます。 `record-plan-in-slow-log`は引き続き有効です。ただし、 `record-plan-in-slow-log`と`instance.tidb_record_plan_in_slow_log`が同時に設定されている場合は、後者が有効になります。 +- バージョン 6.1.0 以降、実行計画をスローログに記録するかどうかは、TiDB 設定項目の[`instance.tidb_record_plan_in_slow_log`](/tidb-configuration-file.md#tidb_record_plan_in_slow_log)またはシステム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)によって決定されます。 `record-plan-in-slow-log`は引き続き有効です。ただし、 `record-plan-in-slow-log`と`instance.tidb_record_plan_in_slow_log`が同時に設定されている場合は、後者が有効になります。 ### `expensive-threshold` {#expensive-threshold} @@ -564,13 +564,13 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - 統計情報の再読み込み、テーブル行数の更新、自動分析の実行が必要かどうかの確認、フィードバックを使用した統計情報の更新、および列の統計情報の読み込みを行う時間間隔。 - デフォルト値: `3s` - `stats-lease`間隔で、TiDB は統計情報の更新をチェックし、更新が存在する場合はそれをメモリに更新します。 - - `20 * stats-lease`間隔で、TiDB は DML によって生成された行の総数と変更された行の数をシステム テーブルに更新します。 + - `20 * stats-lease`間隔で、TiDB は DML によって生成された行の総数と変更された行の数をシステムテーブルに更新します。 - `stats-lease`の間隔で、TiDB は自動分析が必要なテーブルとインデックスをチェックします。 - `stats-lease`の間隔で、TiDB はメモリにロードする必要のある列統計をチェックします。 - - `200 * stats-lease`の間隔で、TiDB はメモリにキャッシュされたフィードバックをシステム テーブルに書き込みます。 - - `5 * stats-lease`の間隔で、TiDB はシステム テーブル内のフィードバックを読み取り、メモリにキャッシュされた統計情報を更新します。 -- `stats-lease`を 0s に設定すると、TiDB はシステム テーブル内のフィードバックを定期的に読み取り、メモリにキャッシュされた統計情報を 3 秒ごとに更新します。ただし、TiDB は、以下の統計情報関連のシステム テーブルを自動的に変更しなくなります。 - - `mysql.stats_meta` : TiDB は、トランザクションによって変更されたテーブル行の数を自動的に記録し、このシステム テーブルに更新しなくなりました。 + - `200 * stats-lease`の間隔で、TiDB はメモリにキャッシュされたフィードバックをシステムテーブルに書き込みます。 + - `5 * stats-lease`の間隔で、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 は、クエリされたデータによって返される統計情報の一部に基づいて、テーブルとインデックスの統計情報を更新しなくなりました。 @@ -868,19 +868,19 @@ TiDBサービスの状態に関するコンフィグレーション。 ### deadlock-history-capacity {#deadlock-history-capacity} -- 単一の TiDBサーバーの[`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルに記録できるデッドロック イベントの最大数。このテーブルが満杯の状態でさらにデッドロック イベントが発生した場合、最新のエラーを記録するために、テーブル内の最も古いレコードが削除されます。 +- 単一の TiDBサーバーの[`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルに記録できるデッドロックイベントの最大数。このテーブルが満杯の状態でさらにデッドロックイベントが発生した場合、最新のエラーを記録するために、テーブル内の最も古いレコードが削除されます。 - デフォルト値: `10` - 最小値: `0` - 最大値: `10000` ### deadlock-history-collect-retryable {#deadlock-history-collect-retryable} -- [`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルが再試行可能なデッドロック エラーの情報を収集するかどうかを制御します。再試行可能なデッドロック エラーの説明については、 [再試行可能なデッドロックエラー](/information-schema/information-schema-deadlocks.md#retryable-deadlock-errors)を参照してください。 +- [`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルが再試行可能なデッドロックエラーの情報を収集するかどうかを制御します。再試行可能なデッドロックエラーの説明については、 [再試行可能なデッドロックエラー](/information-schema/information-schema-deadlocks.md#retryable-deadlock-errors)を参照してください。 - デフォルト値: `false` ### pessimistic-auto-commit v6.0.0で追加 {#pessimistic-auto-commit-new-in-v600} -- 悲観的トランザクション モードがグローバルに有効になっている場合 ( `tidb_txn_mode='pessimistic'` ) に、自動コミット トランザクションが使用するトランザクション モードを決定します。デフォルトでは、悲観的トランザクション モードがグローバルに有効になっていても、自動コミット トランザクションは楽観的トランザクション モードを使用します。 `pessimistic-auto-commit`を有効にすると ( `true` に設定)、自動コミット トランザクションも悲観的モードを使用するようになり、明示的にコミットされた他の悲観的トランザクションと一貫性が保たれます。 +- 悲観的トランザクションモードがグローバルに有効になっている場合 ( `tidb_txn_mode='pessimistic'` ) に、自動コミット トランザクションが使用するトランザクションモードを決定します。デフォルトでは、悲観的トランザクションモードがグローバルに有効になっていても、自動コミット トランザクションは楽観的トランザクションモードを使用します。 `pessimistic-auto-commit`を有効にすると ( `true` に設定)、自動コミット トランザクションも悲観的モードを使用するようになり、明示的にコミットされた他の悲観的トランザクションと一貫性が保たれます。 - 競合が発生するシナリオでは、この設定を有効にすると、TiDB は自動コミットトランザクションをグローバルロック待機管理に組み込み、デッドロックを回避し、デッドロックを引き起こす競合によって発生するレイテンシーの急増を軽減します。 - 競合のないシナリオで、自動コミット トランザクションが多数ある場合 (具体的な数は実際のシナリオによって決まります。たとえば、自動コミット トランザクションの数がアプリケーションの総数の半分以上を占める場合)、単一のトランザクションが大量のデータを操作すると、この構成を有効にするとパフォーマンスが低下します。たとえば、自動コミット`INSERT INTO SELECT`ステートメントです。 - セッションレベルのシステム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)が`"bulk"`に設定されている場合、セッションにおけるこの設定の効果は、それを`false`に設定することと同じです。 diff --git a/tidb-control.md b/tidb-control.md index ad217e1add317..89f6aff1ea5b6 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -3,7 +3,7 @@ title: TiDB Control User Guide summary: デバッグ用の TiDB ステータス情報を取得するには、TiDB コントロールを使用します。 --- -# TiDB コントロール ユーザー ガイド {#tidb-control-user-guide} +# TiDB コントロール ユーザーガイド {#tidb-control-user-guide} TiDB ControlはTiDBのコマンドラインツールであり、通常はデバッグのためにTiDBのステータス情報を取得するために使用されます。このドキュメントでは、TiDB Controlの機能とその使用方法について説明します。 @@ -13,7 +13,7 @@ TiDB ControlはTiDBのコマンドラインツールであり、通常はデバ ## TiDBコントロールを入手 {#get-tidb-control} -TiDB Control は、 TiUPを使用してインストールするか、ソース コードからコンパイルすることで入手できます。 +TiDB Control は、 TiUPを使用してインストールするか、ソースコードからコンパイルすることで入手できます。 > **Note:** > @@ -26,7 +26,7 @@ TiUPをインストールした後、 `tiup ctl:v tidb`コマ ### ソースコードからコンパイルする {#compile-from-source-code} - コンパイル環境要件: [Go](https://golang.org/) 1.25以降 -- コンパイル手順: [TiDB制御プロジェクト](https://github.com/pingcap/tidb-ctl)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tidb-ctl`を生成します。 +- コンパイル手順: [TiDB制御プロジェクト](https://github.com/pingcap/tidb-ctl)のルートディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tidb-ctl`を生成します。 - コンパイル ドキュメント: ヘルプ ファイルは`doc`ディレクトリにあります。ヘルプ ファイルが失われた場合、または更新する場合は、 `make doc`コマンドを使用してヘルプ ファイルを生成します。 ## 使い方の紹介 {#usage-introduction} @@ -67,8 +67,8 @@ TiDBコントロールは複数のコマンド層で構成されています。 使用方法の詳細を取得するには、 `tidb-ctl schema -h`を使用します。 `schema`コマンド自体には、 `in`と`tid` 2つのサブコマンドがあります。 -- `in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブル スキーマを取得するために使用されます。 -- `tid` 、データベース全体で一意の`table_id`を使用してテーブル スキーマを取得するために使用されます。 +- `in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブルスキーマを取得するために使用されます。 +- `tid` 、データベース全体で一意の`table_id`を使用してテーブルスキーマを取得するために使用されます。 ### グローバルオプション {#global-options} @@ -92,7 +92,7 @@ TiDBコントロールは複数のコマンド層で構成されています。 #### `in`サブコマンド {#the-in-subcommand} -`in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブル スキーマを取得するために使用されます。 +`in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブルスキーマを取得するために使用されます。 ```bash tidb-ctl schema in @@ -120,7 +120,7 @@ tidb-ctl schema in - テーブル名を指定する場合は、 `tidb-ctl schema in -n
    `を使用してフィルタリングします。 - たとえば、 `tidb-ctl schema in mysql -n db` `mysql`データベース内の`db`テーブルのテーブル スキーマを返します。 + たとえば、 `tidb-ctl schema in mysql -n db` `mysql`データベース内の`db`テーブルのテーブルスキーマを返します。 ```json { @@ -157,7 +157,7 @@ tidb-ctl schema in } ``` -`in`サブコマンドと同様に、デフォルトの TiDB サービス アドレスとステータス ポートを使用しない場合は、 `--host`および`--port`オプションを使用してホストとポートを指定します。 +`in`サブコマンドと同様に、デフォルトの TiDB サービス アドレスとステータスポートを使用しない場合は、 `--host`および`--port`オプションを使用してホストとポートを指定します。 #### `base64decode`コマンド {#the-base64decode-command} @@ -237,7 +237,7 @@ tidb-ctl base64decode [table_id] [base64_data] ### `decoder`コマンド {#the-decoder-command} -- 次の例は、インデックス キーのデコードと同様に、行キーをデコードする方法を示しています。 +- 次の例は、インデックスキーのデコードと同様に、行キーをデコードする方法を示しています。 ```shell $ ./tidb-ctl decoder "t\x00\x00\x00\x00\x00\x00\x00\x1c_r\x00\x00\x00\x00\x00\x00\x00\xfa" diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index e48fcaf8e7d31..87c42a7a3827f 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -17,14 +17,14 @@ TiDBは、優れたスケーラビリティと弾力性を備えたコンピュ データベース管理システムでは、コアとなるトランザクション処理（TP）と分析処理（AP）のワークロードに加えて、DDL操作、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)バックアップ/リストアといった重要なタスクが存在します。これらのタスクは、データベースオブジェクト（テーブル）内の大量のデータを処理する必要があるため、通常[TTL](/time-to-live.md)次のような特性を持ちます。 -- スキーマまたはデータベース オブジェクト (テーブル) 内のすべてのデータを処理する必要があります。 +- スキーマまたはデータベースオブジェクト (テーブル) 内のすべてのデータを処理する必要があります。 - 定期的に実行する必要があるかもしれませんが、頻度は低くなります。 - リソースが適切に制御されていない場合、TP および AP タスクに影響を与え、データベース サービスの品質が低下する可能性があります。 DXF を有効にすると上記の問題が解決され、次の 3 つの利点があります。 - このフレームワークは、高いスケーラビリティ、高い可用性、および高いパフォーマンスを実現する統合された機能を提供します。 -- DXF はタスクの分散実行をサポートしており、TiDB クラスター全体の利用可能なコンピューティング リソースを柔軟にスケジュールできるため、TiDB クラスター内のコンピューティング リソースをより有効に活用できます。 +- DXF はタスクの分散実行をサポートしており、TiDB クラスター全体の利用可能なコンピューティングリソースを柔軟にスケジュールできるため、TiDB クラスター内のコンピューティングリソースをより有効に活用できます。 - DXF は、全体的タスクと個々のタスクの両方に対して、統合されたリソースの使用および管理機能を提供します。 現在、DXF は[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)と[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)ステートメントの分散実行をサポートしています。 @@ -51,11 +51,11 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ 1. 高速オンライン DDL に関連する次のシステム変数を調整します。 - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) : 高速オンラインDDLモードを有効にするために使用されます。TiDB v6.5.0以降ではデフォルトで有効になっています。 - - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスクの最大クォータを制御するために使用されます。 + - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカルディスクの最大クォータを制御するために使用されます。 2. 高速オンライン DDL に関連する次の構成項目を調整します。 - - [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスク パスを指定します。 + - [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) : 高速オンライン DDL モードで使用できるローカルディスク パスを指定します。 > **Note:** > @@ -68,7 +68,7 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ 高速オンライン DDL に関連する次のシステム変数を調整します。 - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) : 高速オンラインDDLモードを有効にするために使用されます。TiDB v6.5.0以降ではデフォルトで有効になっています。 -- [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスクの最大クォータを制御するために使用されます。 +- [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカルディスクの最大クォータを制御するために使用されます。 @@ -115,7 +115,7 @@ DXF のアーキテクチャは次のとおりです。 - ディスパッチャ: 各タスクの分散実行計画を生成し、実行プロセスを管理し、タスクの状態を変換し、実行時のタスク情報を収集してフィードバックします。 - スケジューラ: TiDB ノード間で分散タスクの実行を複製し、タスク実行の効率を向上させます。 - サブタスクエグゼキュータ：分散サブタスクの実際の実行者。また、サブタスクエグゼキュータはサブタスクの実行状況をスケジューラに返し、スケジューラはサブタスクの実行状況を一元的に更新します。 -- リソース プール: 上記のモジュールのコンピューティング リソースをプールすることにより、リソースの使用状況と管理を定量化する基礎を提供します。 +- リソース プール: 上記のモジュールのコンピューティングリソースをプールすることにより、リソースの使用状況と管理を定量化する基礎を提供します。 ## 参照 {#see-also} diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 46d89be61ae3b..40669bd8b9cf3 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -1,6 +1,6 @@ --- title: TiDB Global Sort -summary: TiDB グローバル ソートの使用例、制限、使用方法、実装の原則について学習します。 +summary: TiDB グローバルソートの使用例、制限、使用方法、実装の原則について学習します。 --- @@ -12,7 +12,7 @@ summary: TiDB グローバル ソートの使用例、制限、使用方法、 > **Note:** > > - 現在、グローバルソート処理はTiDBノードの計算リソースとメモリリソースを大量に消費しています。ユーザーの業務アプリケーションの実行中にオンラインでインデックスを追加するようなシナリオでは、クラスターに新しいTiDBノードを追加し、これらのノードに[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を設定し、これらのノードに接続してタスクを作成することをお勧めします。これにより、分散フレームワークはこれらのノードにタスクをスケジュールし、他のTiDBノードからのワークロードを分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンドタスクの実行がユーザーの業務アプリケーションに与える影響を軽減します。 -> - グローバル ソート機能を使用する場合は、OOM を回避するために、少なくとも 16 コアの CPU と 32 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 +> - グローバルソート機能を使用する場合は、OOM を回避するために、少なくとも 16 コアの CPU と 32 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 > **Note:** > @@ -28,11 +28,11 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ グローバルソート機能は、 `IMPORT INTO`と`CREATE INDEX`の安定性と効率性を向上させます。タスクによって処理されるデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上します。これにより、データインポートやDDLタスクのユーザーエクスペリエンスが向上し、より高品質なサービスが提供されます。 -グローバル ソート機能は、統合された DXF 内でタスクを実行し、グローバル スケールでのデータの効率的かつ並列的なソートを保証します。 +グローバルソート機能は、統合された DXF 内でタスクを実行し、グローバル スケールでのデータの効率的かつ並列的なソートを保証します。 ## 制限事項 {#limitations} -現在、グローバル ソート機能は、クエリ結果のソートを担当するクエリ実行プロセスのコンポーネントとして使用されていません。 +現在、グローバルソート機能は、クエリ結果のソートを担当するクエリ実行プロセスのコンポーネントとして使用されていません。 ## 使用法 {#usage} @@ -85,7 +85,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ ### ステップ1: データをスキャンして準備する {#step-1-scan-and-prepare-data} -1. TiDB ノードが特定の範囲のデータをスキャンした後 (データ ソースは CSV データまたは TiKV のテーブル データのいずれかになります)。 +1. TiDB ノードが特定の範囲のデータをスキャンした後 (データソースは CSV データまたは TiKV のテーブルデータのいずれかになります)。 1. TiDB ノードはそれらをキーと値のペアにエンコードします。 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1 つのファイルであり、クラウドストレージにアップロードされます。 diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 8d0f422bc0ba4..ab638891d745c 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -1,6 +1,6 @@ --- title: Best Practices for Importing 50 TiB Data -summary: 大量のデータをインポートするためのベスト プラクティスを学びます。 +summary: 大量のデータをインポートするためのベストプラクティスを学びます。 --- # 50 TiB データのインポートに関するベストプラクティス {#best-practices-for-importing-50-tib-data} @@ -9,9 +9,9 @@ summary: 大量のデータをインポートするためのベスト プラク TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) ）は、空のテーブルへのデータのインポートや空のクラスタの初期化に使用される包括的かつ効率的なデータインポートツールであり、ファイルをデータソースとして使用します。TiDB Lightningは、単一インスタンスと[並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)の2つの実行モードを提供します。異なるサイズのソースファイルをインポートできます。 -- ソース ファイルのデータ サイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。 -- ソース ファイルのデータ サイズが 10 TiB を超える場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)にTiDB Lightningの複数のインスタンスを使用することをお勧めします。 -- ソース ファイルのデータ規模が非常に大きい場合 (50 TiB を超える場合)、並列インポートに加えて、ソース データの特性、テーブル定義、およびパラメータ構成に基づいて特定の準備と最適化を行い、大規模データのインポートをよりスムーズかつ高速に実現する必要があります。 +- ソースファイルのデータサイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。 +- ソースファイルのデータサイズが 10 TiB を超える場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)にTiDB Lightningの複数のインスタンスを使用することをお勧めします。 +- ソースファイルのデータ規模が非常に大きい場合 (50 TiB を超える場合)、並列インポートに加えて、ソースデータの特性、テーブル定義、およびパラメータ構成に基づいて特定の準備と最適化を行い、大規模データのインポートをよりスムーズかつ高速に実現する必要があります。 次のセクションは、複数のテーブルのインポートと単一の大きなテーブルのインポートの両方に適用されます。 @@ -23,7 +23,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - [チェックポイントを有効にする](#enable-checkpoint) - [トラブルシューティング](#troubleshooting) -大きな単一テーブルをインポートするためのベスト プラクティスについては、特別な要件があるため、次のセクションで別途説明します。 +大きな単一テーブルをインポートするためのベストプラクティスについては、特別な要件があるため、次のセクションで別途説明します。 - [大きな単一テーブルをインポートするためのベストプラクティス](#best-practices-for-importing-a-large-single-table) @@ -39,18 +39,18 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - 表の定義 - テーブルごとのセカンダリインデックスの数とサイズは、インポート速度に影響を与える可能性があります。インデックスの数が少ないほど、インポートが高速化し、インポート後のスペース消費も少なくなります。 - - インデックス データ サイズ = インデックスの数 * インデックス サイズ * 行数。 + - インデックスデータサイズ = インデックスの数 * インデックス サイズ * 行数。 - 圧縮比 - TiDBクラスタにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスタにインポートされた後にのみ判定できます。 - - ベスト プラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートしてクラスターの対応する圧縮率を取得し、それを使用してデータ インポート全体の圧縮率を推定することができます。 + - ベストプラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートしてクラスターの対応する圧縮率を取得し、それを使用してデータインポート全体の圧縮率を推定することができます。 - コンフィグレーションパラメータ - `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。 - `send-kv-pairs` : 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 - - `disk-quota` : 物理インポート モードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスク クォータ。 + - `disk-quota` : 物理インポートモードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスククォータ。 - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。[`GOMEMLIMIT`を適切に設定します](#change-configuration-parameters) - データ検証 @@ -86,7 +86,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。 - データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。 -なお、圧縮やスナップショットのレプリケーションなどのバックグラウンド タスクもストレージ領域の一部を消費するため、20% のストレージ領域を予約することをお勧めします。 +なお、圧縮やスナップショットのレプリケーションなどのバックグラウンドタスクもストレージ領域の一部を消費するため、20% のストレージ領域を予約することをお勧めします。 ## 設定パラメータを変更する {#change-configuration-parameters} diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 833e570efb3e8..7f5c69a6acee6 100644 --- a/tidb-lightning/deploy-tidb-lightning.md +++ b/tidb-lightning/deploy-tidb-lightning.md @@ -32,7 +32,7 @@ summary: TiDB Lightningをデプロイ、大量の新しいデータを迅速に [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してTiDB Lightning のバイナリをダウンロードしてください。TiDB Lightning はTiDB の以前のバージョンと完全に互換性があります。最新バージョンのTiDB Lightning を使用することをお勧めします。 -TiDB Lightningバイナリ パッケージを解凍して、 `tidb-lightning`実行可能ファイルを取得します。 +TiDB Lightningバイナリパッケージを解凍して、 `tidb-lightning`実行可能ファイルを取得します。 ```bash tar -zxvf tidb-lightning-${version}-linux-amd64.tar.gz diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 781c348d68e0a..f291a2d738b74 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -37,7 +37,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 TiDB Lightning をデプロイして実行するには、別々のサーバーが必要です。インポートタスクが実行されていない場合、これらのリソースはアイドル状態のままになります。インポートタスクが定期的に実行されるシナリオでは、合計アイドル時間はさらに長くなり、リソースの無駄が発生します。 -インポートするデータセットが大きい場合は、インポートするデータをソートするための大容量のローカル ディスクも準備する必要があります。 +インポートするデータセットが大きい場合は、インポートするデータをソートするための大容量のローカルディスクも準備する必要があります。 ### タスクの構成と統合 {#task-configuration-and-integration} @@ -61,7 +61,7 @@ You can directly write SQL statements to submit import tasks, which are easy to 10 個のTiDB Lightningインスタンスを起動してデータを並列インポートする場合、10 個のTiDB Lightning設定ファイルを作成する必要があります。各ファイルでは、対応するTiDB Lightningインスタンスが読み取るソースファイルの範囲を設定する必要があります。例えば、 TiDB Lightningインスタンス 1 は最初の 100 ファイルを読み取り、インスタンス 2 は次の 100 ファイルを読み取り、というように続きます。 -さらに、これら 10 個のTiDB Lightningインスタンスの共有メタデータ テーブルやその他の構成情報を構成する必要があり、これは複雑です。 +さらに、これら 10 個のTiDB Lightningインスタンスの共有メタデータテーブルやその他の構成情報を構成する必要があり、これは複雑です。 ### グローバルソートとローカルソート {#global-sort-vs-local-sort} diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index 2ed494e478c0c..ea5e1f000a840 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -129,7 +129,7 @@ scrape_configs: - **`lightning_importer_engine`** (カウンター) - 開いているエンジン ファイルと閉じているエンジン ファイルの数をカウントします。ラベル: + 開いているエンジンファイルと閉じているエンジンファイルの数をカウントします。ラベル: - **タイプ**： - `open` @@ -164,7 +164,7 @@ scrape_configs: - `pending` : まだ処理されていません - `written` : すべてのデータがエンコードされて送信されました - `closed` : 対応するすべてのエンジンファイルが閉じられています - - `imported` : すべてのエンジン ファイルがターゲット クラスターにインポートされました + - `imported` : すべてのエンジンファイルがターゲットクラスターにインポートされました - `altered_auto_inc` : AUTO_INCREMENT IDが変更されました - `checksum` : チェックサムを実行 - `analyzed` : 統計分析を実行しました @@ -226,7 +226,7 @@ scrape_configs: - **`lightning_chunk_parser_read_block_seconds`** (ヒストグラム) - データ ファイル パーサーがブロックを読み取るために必要な時間のバケット化されたヒストグラム。 + データファイル パーサーがブロックを読み取るために必要な時間のバケット化されたヒストグラム。 - **`lightning_checksum_seconds`** （ヒストグラム） diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 04a587d1eb3ed..1ed9cafcef791 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ディスクなど、書き込み耐久性が非常に高いドライブにチェックポイントファイルを置くことを強くお勧めします。 @@ -69,7 +69,7 @@ tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`' - 以前にテーブル`` `schema`.`table` ``インポートに失敗した場合、このオプションは次の操作を実行します。 - 1. ターゲット データベースからテーブル`` `schema`.`table` ``を削除します。つまり、インポートされたすべてのデータが削除されます。 + 1. ターゲットデータベースからテーブル`` `schema`.`table` ``を削除します。つまり、インポートされたすべてのデータが削除されます。 2. このテーブルのチェックポイント レコードを「まだ開始されていない」状態にリセットします。 - テーブル`` `schema`.`table` ``に関連するエラーがない場合、この操作は何も実行されません。 diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index 1a6c145a8ea07..f8ad307955981 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -17,16 +17,16 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | :---------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------- | | `--config ` | ファイルからグローバル設定を読み取ります。このパラメータが指定されていない場合、 TiDB Lightningはデフォルト設定を使用します。 | | | `-V` | プログラムのバージョンを印刷します。 | | -| `-d ` | ローカル ディレクトリまたはデータ ファイルの[外部ストレージURI](/external-storage-uri.md) 。 | `mydumper.data-source-dir` | +| `-d ` | ローカルディレクトリまたはデータファイルの[外部ストレージURI](/external-storage-uri.md) 。 | `mydumper.data-source-dir` | | `-L ` | ログレベル：`debug` 、 `info` 、 `warn` 、 `error` 、または`fatal` 。デフォルトは`info` 。 | `lightning.level` | | `-f ` | [テーブルフィルタルール](/table-filter.md) 。複数回指定できます。 | `mydumper.filter` | -| `--backend ` | インポート モードを選択します。`local`は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を、 `tidb`は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を指します。 | `tikv-importer.backend` | +| `--backend ` | インポートモードを選択します。`local`は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を、 `tidb`は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を指します。 | `tikv-importer.backend` | | `--log-file ` | ログファイルのパス。デフォルトでは`/tmp/lightning.log.{timestamp}`です。「-」に設定すると、ログファイルは標準出力に出力されます。 | `lightning.log-file` | | `--status-addr ` | TiDB Lightning HTTPサーバーのリスニング アドレス | `lightning.status-addr` | | `--pd-urls ` | PDエンドポイントアドレス。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 | `tidb.pd-addr` | | `--tidb-host ` | TiDBサーバーホスト | `tidb.host` | | `--tidb-port ` | TiDBサーバーポート (デフォルト = 4000) | `tidb.port` | -| `--tidb-status ` | TiDB ステータス ポート (デフォルト = 10080) | `tidb.status-port` | +| `--tidb-status ` | TiDB ステータスポート (デフォルト = 10080) | `tidb.status-port` | | `--tidb-user ` | TiDBに接続するためのユーザー名 | `tidb.user` | | `--tidb-password ` | TiDBに接続するためのパスワード。パスワードはプレーンテキストまたはBase64エンコードのいずれかで指定できます。 | `tidb.password` | | `--enable-checkpoint ` | チェックポイントを有効にするかどうか（デフォルト = true） | `checkpoint.enable` | @@ -49,8 +49,8 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | `--compact` | 完全な圧縮を実行します。 | | `--switch-mode ` | すべての TiKV ストアを指定されたモード (通常またはインポート) に切り替えます。 | | `--fetch-mode` | 各 TiKV ストアの現在のモードを出力します。 | -| `--import-engine ` | 閉じたエンジン ファイルを TiKV インポーターから TiKV クラスターにインポートします。 | -| `--cleanup-engine ` | TiKV インポーターからエンジン ファイルを削除します。 | +| `--import-engine ` | 閉じたエンジンファイルを TiKV インポーターから TiKV クラスターにインポートします。 | +| `--cleanup-engine ` | TiKV インポーターからエンジンファイルを削除します。 | | `--checkpoint-dump ` | 現在のチェックポイントを CSV としてフォルダーにダンプします。 | | `--checkpoint-error-destroy ` | チェックポイントを削除します。エラーが発生した場合は、テーブルを削除します。 | | `--checkpoint-error-ignore ` | 指定されたテーブルに関連するチェックポイントに記録されたエラーを無視します。 | diff --git a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md index 71640d699db55..5c69f1dbc13b3 100644 --- a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md +++ b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md @@ -1,6 +1,6 @@ --- title: Compatibility of TiDB Lightning and IMPORT INTO with TiCDC and Log Backup -summary: IMPORT INTO およびTiDB Lightning とログ バックアップおよび TiCDC との互換性について説明します。 +summary: IMPORT INTO およびTiDB Lightning とログバックアップおよび TiCDC との互換性について説明します。 --- # TiDB Lightningと IMPORT INTO と TiCDC およびログバックアップとの互換性 {#compatibility-of-tidb-lightning-and-import-into-with-ticdc-and-log-backup} @@ -13,7 +13,7 @@ summary: IMPORT INTO およびTiDB Lightning とログ バックアップおよ ## ログバックアップおよびTiCDCとの互換性 {#compatibility-with-log-backup-and-ticdc} -- TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)は、ログ バックアップおよび TiCDC と互換性があります。 +- TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)は、ログバックアップおよび TiCDC と互換性があります。 - TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)は、ログバックアップおよびTiCDCと互換性がありません。これは、物理インポートモードがソースデータのエンコードされたKVペアをTiKVに直接取り込むため、TiKVがこの処理中に該当する変更ログを生成できないためです。変更ログが生成されないと、ログバックアップによる関連データのバックアップやTiCDCによるレプリケーションが実行できません。 @@ -23,13 +23,13 @@ summary: IMPORT INTO およびTiDB Lightning とログ バックアップおよ ## TiDB Lightning論理インポートモードのシナリオ {#scenarios-for-tidb-lightning-logical-import-mode} -TiDB Lightning論理インポート モードがアプリケーションのパフォーマンス要件を満たすことができ、アプリケーションでインポートされたテーブルを TiCDC を使用してダウンストリームにバックアップまたは複製する必要がある場合は、 TiDB Lightning論理インポート モードを使用することをお勧めします。 +TiDB Lightning論理インポートモードがアプリケーションのパフォーマンス要件を満たすことができ、アプリケーションでインポートされたテーブルを TiCDC を使用してダウンストリームにバックアップまたは複製する必要がある場合は、 TiDB Lightning論理インポートモードを使用することをお勧めします。 ## TiDB Lightning物理インポートモードのシナリオ {#scenarios-for-tidb-lightning-physical-import-mode} このセクションでは、TiDB Lightning を[ログバックアップ](/br/br-pitr-guide.md)および[TiCDC](/ticdc/ticdc-overview.md)と一緒に使用する方法について説明します。 -TiDB Lightning論理インポート モードがアプリケーションのパフォーマンス要件を満たしていない場合、 TiDB Lightning物理インポート モードを使用する必要があり、インポートされたテーブルを TiCDC を使用してダウンストリームにバックアップまたは複製する必要がある場合は、次のシナリオが推奨されます。 +TiDB Lightning論理インポートモードがアプリケーションのパフォーマンス要件を満たしていない場合、 TiDB Lightning物理インポートモードを使用する必要があり、インポートされたテーブルを TiCDC を使用してダウンストリームにバックアップまたは複製する必要がある場合は、次のシナリオが推奨されます。 ### ログバックアップで使用される {#used-with-log-backup} @@ -39,7 +39,7 @@ TiDB Lightning物理インポートモードでインポートされたデータ ### TiCDC で使用される {#used-with-ticdc} -TiCDC を物理インポート モードで使用することは、短期的には互換性がありません。これは、TiCDC がTiDB Lightning物理インポート モードの書き込み速度に追いつけず、クラスター レプリケーションのレイテンシーが長くなる可能性があるためです。 +TiCDC を物理インポートモードで使用することは、短期的には互換性がありません。これは、TiCDC がTiDB Lightning物理インポートモードの書き込み速度に追いつけず、クラスター レプリケーションのレイテンシーが長くなる可能性があるためです。 次のようにさまざまなシナリオで実行できます。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 13e10bbd80910..046c66762df64 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -15,7 +15,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `status-addr` {#status-addr} -- Prometheus メトリックを取得し、デバッグ データを公開し、サーバーモードでインポート タスクを送信するための HTTP ポート。 +- Prometheus メトリックを取得し、デバッグデータを公開し、サーバーモードでインポートタスクを送信するための HTTP ポート。 - `0`に設定するとポートが無効になります。 @@ -25,8 +25,8 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - サーバーモードを設定します。 - デフォルト値: `false` - 値のオプション: - - `false` : コマンドを実行するとすぐにインポート タスクが開始されます。 - - `true` : コマンド実行後、TiDB LightningはHTTP APIを介してインポート タスクを送信するまで待機します。 + - `false` : コマンドを実行するとすぐにインポートタスクが開始されます。 + - `true` : コマンド実行後、TiDB LightningはHTTP APIを介してインポートタスクを送信するまで待機します。 #### `level` {#level} @@ -108,7 +108,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - [並列インポートモード](/tidb-lightning/tidb-lightning-distributed-import.md)では、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名です。このパラメータは、並列インポートが有効な場合にのみ設定してください。 - このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性は保証されません。 -- 並列インポート モードが有効になっている場合は、インポートに使用されるユーザー (構成`tidb.user` ) に、この構成に対応するデータベースを作成してアクセスする権限があることを確認します。 +- 並列インポートモードが有効になっている場合は、インポートに使用されるユーザー (構成`tidb.user` ) に、この構成に対応するデータベースを作成してアクセスする権限があることを確認します。 - TiDB Lightningはインポート完了後にこのスキーマを削除します。そのため、このパラメータを設定する際に既存のスキーマ名を使用しないでください。 - デフォルト値: `"lightning_metadata"` @@ -158,7 +158,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `dsn` {#dsn} -- チェックポイントストレージの場所を示すデータ ソース名 (DSN)。 +- チェックポイントストレージの場所を示すデータソース名 (DSN)。 - `file`ドライバの場合、DSNはパスです。パスが指定されていない場合、 TiDB Lightningはデフォルト値の`/tmp/CHECKPOINT_SCHEMA.pb`を使用します。 - `mysql`ドライバーの場合、 DSN は`USER:PASS@tcp(HOST:PORT)/`形式の URL です。 - URL が指定されていない場合は、 `[tidb]`セクションの TiDBサーバーがチェックポイントの保存に使用されます。 @@ -169,7 +169,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `keep-after-success` {#keep-after-success} - すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。`false`の場合、チェックポイントは削除されます。 -- チェックポイントを保持するとデバッグが容易になりますが、データ ソースに関するメタデータが漏洩します。 +- チェックポイントを保持するとデバッグが容易になりますが、データソースに関するメタデータが漏洩します。 @@ -182,10 +182,10 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 値のオプション: - `""` : - 物理インポートモードでは、 TiDB Lightning は競合するデータを検出または処理しません。ソースファイルに競合する主キーまたは一意キーのレコードが含まれている場合、後続のステップでエラーが報告されます。 - - 論理インポート モードでは、 TiDB Lightning は処理のために`""`戦略を`"error"`戦略に変換します。 + - 論理インポートモードでは、 TiDB Lightning は処理のために`""`戦略を`"error"`戦略に変換します。 - `"error"` : インポートされたデータ内で競合する主キー レコードまたは一意のキー レコードが検出されると、 TiDB Lightning はインポートを終了し、エラーを報告します。 - `"replace"` : 競合する主キー レコードまたは一意のキー レコードが発生した場合、 TiDB Lightning は最新のデータを保持し、古いデータを上書きします。 - - 物理インポート モードを使用すると、競合するデータはターゲット TiDB クラスターの`lightning_task_info.conflict_view`ビューに記録されます。 + - 物理インポートモードを使用すると、競合するデータはターゲット TiDB クラスターの`lightning_task_info.conflict_view`ビューに記録されます。 - `lightning_task_info.conflict_view`ビューにおいて、行の`is_precheck_conflict`フィールドが`0`の場合、その行に記録された競合データは後処理の競合検出によって検出されたことを意味します。行の`is_precheck_conflict`フィールドが`1`の場合、その行に記録された競合データはインポート前の競合検出によって検出されたことを意味します。アプリケーション要件に基づいて、適切なレコードをターゲットテーブルに手動で挿入できます。 - ターゲット TiKV は v5.2.0 以降のバージョンである必要があることに注意してください。 - `"ignore"` : 主キーまたは一意キーのレコードの競合が発生した場合、 TiDB Lightning は古いデータを保持し、新しいデータを無視します。このオプションは論理インポートモードでのみ使用できます。 @@ -212,14 +212,14 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - v8.1.0 以降では、ユーザー入力に関係なく、 TiDB Lightning が`max-record-rows`の値に[`threshold`](#threshold)の値を自動的に割り当てるため、 `max-record-rows`手動で構成する必要はありません。 - `max-record-rows`将来のリリースでは非推奨になります。 - 物理インポートモードでは、戦略が`"replace"`の場合、上書きされる競合レコードが記録されます。 -- 論理インポート モードでは、戦略が`"ignore"`の場合、無視される競合レコードが記録され、戦略が`"replace"`の場合、競合レコードは記録されません。 +- 論理インポートモードでは、戦略が`"ignore"`の場合、無視される競合レコードが記録され、戦略が`"replace"`の場合、競合レコードは記録されません。 - デフォルト値: `10000` ### tikvインポーター {#tikv-importer} #### `backend` {#backend} -- TiDB Lightningのインポート モードを指定します。 +- TiDB Lightningのインポートモードを指定します。 - デフォルト値: `"local"` - 値のオプション: - `"local"` : [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) （デフォルト）です。これは、例えば1 TiBを超えるような大規模なデータセットのインポートに適用されます。ただし、インポート中は下流のTiDBはサービスを提供できません。 @@ -230,7 +230,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - 複数のTiDB Lightningインスタンス（物理インポートモード）が1つ以上のターゲットテーブル[並行して](/tidb-lightning/tidb-lightning-distributed-import.md)にデータをインポートできるようにするかどうかを制御します。このパラメータは、ターゲットテーブルが空の場合にのみ使用されることに注意してください。 - デフォルト値: `false` - 値のオプション: `true` 、 `false` -- 並列インポート モードを使用する場合は、パラメータを`true`に設定する必要がありますが、ターゲット テーブルにデータが存在しないことが前提となります。つまり、すべてのデータはTiDB Lightningによってのみインポートできます。 +- 並列インポートモードを使用する場合は、パラメータを`true`に設定する必要がありますが、ターゲットテーブルにデータが存在しないことが前提となります。つまり、すべてのデータはTiDB Lightningによってのみインポートできます。 #### `duplicate-resolution` {#duplicate-resolution} @@ -238,7 +238,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 > > バージョン8.0.0以降、 `duplicate-resolution`パラメータは非推奨となり、将来のリリースで削除される予定です。詳細については、 [競合検出の旧バージョン](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)を参照してください。 -- 物理インポート モードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 +- 物理インポートモードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 - デフォルト値: `'none'` - 値のオプション: - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。`duplicate-resolution = 'none'`を設定し、 `conflict.strategy`を設定していない場合、 TiDB Lightningは自動的に`conflict.strategy`に`""`を割り当てます。 @@ -250,18 +250,18 @@ 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} -- 物理インポート モードで KV ペアを TiKV に送信するときに圧縮を有効にするかどうかを制御します。 +- 物理インポートモードで KV ペアを TiKV に送信するときに圧縮を有効にするかどうかを制御します。 - 現在、Gzip圧縮アルゴリズムのみがサポートされています。このアルゴリズムを使用するには、このパラメータに`"gzip"`または`"gz"`を入力してください。 - デフォルト値: `""` 。圧縮が有効になっていないことを意味します。 - 値のオプション: `""` 、 `"gzip"` 、 `"gz"` @@ -272,29 +272,29 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `range-concurrency` {#range-concurrency} -- TiKV が物理インポート モードで KV データを書き込む同時実行性を指​​定します。 +- TiKV が物理インポートモードで KV データを書き込む同時実行性を指​​定します。 - TiDB Lightningと TiKV 間のネットワーク伝送速度が 10 ギガビットを超える場合は、この値を適宜増やすことができます。 - デフォルト値: `16` #### `store-write-bwlimit` {#store-write-bwlimit} -- 物理インポート モードでTiDB Lightning が各 TiKV ノードにデータを書き込む帯域幅を制限します。 +- 物理インポートモードでTiDB Lightning が各 TiKV ノードにデータを書き込む帯域幅を制限します。 - デフォルト値: `0` 、制限がないことを意味します。 #### `disk-quota` {#disk-quota} -- 物理インポート モードを使用する場合のローカル一時ファイルのディスク クォータを指定します。 +- 物理インポートモードを使用する場合のローカル一時ファイルのディスククォータを指定します。 - ディスククォータが不足している場合、 TiDB Lightningはソースデータの読み取りと一時ファイルの書き込みを停止しますが、ソート済みのキーと値のペアをTiKVに書き込むことを優先します。TiDB Lightningがローカルの一時ファイルを削除した後、インポートプロセスは続行されます。 - このオプションは、 [`backend`](#backend)オプションを`local`に設定した場合にのみ有効になります。 - デフォルト値: `MaxInt64`バイト、つまり 9223372036854775807 バイト。 #### `add-index-by-sql` {#add-index-by-sql} -- 物理インポート モードで SQL 経由でインデックスを追加するかどうかを指定します。 +- 物理インポートモードで SQL 経由でインデックスを追加するかどうかを指定します。 - このメカニズムは、過去のバージョンと一貫性があります。SQLを使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを個別に実行できるため、データのインポートが高速化されることです。データのインポート後、インデックスの追加に失敗しても、インポートされたデータの整合性には影響しません。 - デフォルト値: `false` - 値のオプション: - - `false` : TiDB Lightningデータとインデックス データの両方を KV ペアにエンコードし、一緒に TiKV にインポートします。 + - `false` : TiDB Lightningデータとインデックスデータの両方を KV ペアにエンコードし、一緒に TiKV にインポートします。 - `true` : TiDB Lightning は、行データをインポートした後、 `ADD INDEX` SQL ステートメントを介してインデックスを追加します。 #### `keyspace-name` {#keyspace-name} @@ -305,26 +305,26 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `pause-pd-scheduler-scope`バージョン7.1.0の新機能 {#pause-pd-scheduler-scope-new-in-v710} -- 物理インポート モードでは、このパラメータはTiDB Lightning がPD スケジュールを停止する範囲を制御します。 +- 物理インポートモードでは、このパラメータはTiDB Lightning がPD スケジュールを停止する範囲を制御します。 - デフォルト値: `"table"` - 値のオプション: - - `"table"` : ターゲット テーブル データを格納するリージョンのみのスケジュールを一時停止します。 + - `"table"` : ターゲットテーブルデータを格納するリージョンのみのスケジュールを一時停止します。 - `"global"` : グローバルスケジューリングを一時停止します。ビジネストラフィックのないクラスターにデータをインポートする場合は、他のスケジューリングからの干渉を避けるため、このパラメータを`"global"`に設定することをお勧めします。 #### `region-split-batch-size` v7.1.0 の新機能 {#region-split-batch-size-new-in-v710} -- 物理インポート モードでは、このパラメータはバッチでリージョンを分割するときのリージョンの数を制御します。 +- 物理インポートモードでは、このパラメータはバッチでリージョンを分割するときのリージョンの数を制御します。 - TiDB Lightningインスタンスごとに同時に分割できるリージョンの最大数は次のとおりです: `region-split-batch-size * region-split-concurrency * table-concurrency` - デフォルト値: `4096` #### `region-split-concurrency` v7.1.0 の新機能 {#region-split-concurrency-new-in-v710} -- 物理インポート モードでは、このパラメーターはリージョンを分割する際の同時実行性を制御します。 +- 物理インポートモードでは、このパラメーターはリージョンを分割する際の同時実行性を制御します。 - デフォルト値: CPUコアの数 #### `region-check-backoff-limit`バージョン7.1.0の新機能 {#region-check-backoff-limit-new-in-v710} -- 物理インポート モードでは、このパラメータは、分割および分散操作後にリージョンがオンラインになるまで待機する再試行回数を制御します。 +- 物理インポートモードでは、このパラメータは、分割および分散操作後にリージョンがオンラインになるまで待機する再試行回数を制御します。 - 再試行間隔は最大2秒です。再試行の間にいずれかのリージョンがオンラインになった場合でも、再試行回数は増加しません。 - デフォルト値: `1800` @@ -336,7 +336,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `logical-import-batch-size` v8.0.0 の新機能 {#logical-import-batch-size-new-in-v800} -- 論理インポート モードでは、このパラメータはダウンストリーム TiDBサーバーで実行される各 SQL ステートメントのサイズを制御します。 +- 論理インポートモードでは、このパラメータはダウンストリーム TiDBサーバーで実行される各 SQL ステートメントのサイズを制御します。 - 単一のトランザクション内の`INSERT`または`REPLACE`ステートメントの`VALUES`部分の予想サイズを指定します。 - このパラメータは厳密な制限ではありません。実際に実行されるSQLは、インポートされるコンテンツに応じて、これより長くなったり短くなったりする場合があります。 - デフォルト値: `"96KiB"` 。これは、 TiDB Lightning がクラスターの唯一のクライアントである場合に、インポート速度が最適化されます。 @@ -344,14 +344,14 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `logical-import-batch-rows` v8.0.0 の新機能 {#logical-import-batch-rows-new-in-v800} -- 論理インポート モードでは、このパラメータはトランザクションごとに挿入される行の最大数を制御します。 +- 論理インポートモードでは、このパラメータはトランザクションごとに挿入される行の最大数を制御します。 - [`logical-import-batch-size`](#logical-import-batch-size-new-in-v800)と`logical-import-batch-rows`両方を指定した場合、最初にしきい値に達したパラメータが有効になります。 - この値を減らすと、大規模なトランザクションによるクラスターのストレスを軽減できます。 - デフォルト値: `65536` #### `logical-import-prep-stmt` {#logical-import-prep-stmt} -- 論理インポート モードでは、このパラメータは、パフォーマンスを向上させるために[準備された文](/sql-statements/sql-statement-prepare.md)およびステートメント キャッシュを使用するかどうかを制御します。 +- 論理インポートモードでは、このパラメータは、パフォーマンスを向上させるために[準備された文](/sql-statements/sql-statement-prepare.md)およびステートメントキャッシュを使用するかどうかを制御します。 - デフォルト値: `false` ### mydumper {#mydumper} @@ -365,7 +365,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 - エンジンファイルは順番にインポートする必要があります。並列処理のため、複数のデータエンジンがほぼ同時にインポートされ、キューが生成されてリソースが浪費されます。そのため、 TiDB Lightning、リソースを適切に配分するために、最初の数バッチのサイズをわずかに大きくしています。 - スケールアップ係数はこのパラメータによって制御されます。このパラメータは、完全な同時実行における「インポート」ステップと「書き込み」ステップの所要時間の比率を表します。これは、約1GiBの単一テーブルにおける比率（インポート所要時間/書き込み所要時間）を使用して計算できます。正確な時間はログで確認できます。 -- 「インポート」の方が高速であれば、バッチ サイズの分散は小さくなり、比率が 0 であればバッチ サイズは均一になります。 +- 「インポート」の方が高速であれば、バッチサイズの分散は小さくなり、比率が 0 であればバッチサイズは均一になります。 - 範囲: `[0, 1)` @@ -378,32 +378,32 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `character-set` {#character-set} -- `CREATE TABLE`ステートメントを含むスキーマ ファイルの文字セットを指定します。 +- `CREATE TABLE`ステートメントを含むスキーマファイルの文字セットを指定します。 - デフォルト値: `"auto"` - 値のオプション: - `"auto"` : スキーマがUTF-8かGB-18030かを自動的に検出します。エンコードがどちらでもない場合はエラーが報告されます。 - - `"utf8mb4"` : スキーマ ファイルは UTF-8 としてエンコードする必要があります。それ以外の場合はエラーが報告されます。 + - `"utf8mb4"` : スキーマファイルは UTF-8 としてエンコードする必要があります。それ以外の場合はエラーが報告されます。 - `"gb18030"` : スキーマファイルは GB-18030 としてエンコードされている必要があります。そうでない場合はエラーが報告されます。 - - `"latin1"` : スキーマ ファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 + - `"latin1"` : スキーマファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 - `"binary"` : スキーマファイルのデコードを試みない #### `data-character-set` {#data-character-set} - ソースデータファイルの文字セットを指定します。TiDB Lightning は、インポート時にソースファイルを指定された文字セットから UTF-8 エンコードに変換します。 - 現在、この設定ではCSVファイルの文字セットのみを指定し、以下のオプションがサポートされています。空白のままにすると、デフォルト値の`"binary"`が使用され、Lightningはエンコーディングを変換しません。 -- TiDB Lightning はソース データ ファイルの文字セットを予測せず、この構成に基づいてソース ファイルを変換し、データをインポートするだけです。 -- この構成の値がソース データ ファイルの実際のエンコードと同じでない場合、インポートの失敗、データの損失、またはデータの乱れが発生する可能性があります。 +- TiDB Lightning はソースデータファイルの文字セットを予測せず、この構成に基づいてソースファイルを変換し、データをインポートするだけです。 +- この構成の値がソースデータファイルの実際のエンコードと同じでない場合、インポートの失敗、データの損失、またはデータの乱れが発生する可能性があります。 - デフォルト値: `"binary"` - 値のオプション: - `"binary"` : TiDB Lightning がエンコーディングを変換しないことを示します (デフォルト)。 - - `"utf8mb4"` : ソース データ ファイルが UTF-8 エンコードを使用していることを示します。 - - `"GB18030"` : ソース データ ファイルで GB-18030 エンコードが使用されていることを示します。 - - `"GBK"` : ソース データ ファイルは GBK エンコードを使用します (GBK エンコードは GB-2312 文字セットの拡張であり、コード ページ 936 とも呼ばれます)。 - - `"latin1"` : ソース データ ファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 + - `"utf8mb4"` : ソースデータファイルが UTF-8 エンコードを使用していることを示します。 + - `"GB18030"` : ソースデータファイルで GB-18030 エンコードが使用されていることを示します。 + - `"GBK"` : ソースデータファイルは GBK エンコードを使用します (GBK エンコードは GB-2312 文字セットの拡張であり、コード ページ 936 とも呼ばれます)。 + - `"latin1"` : ソースデータファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 #### `data-invalid-char-replace` {#data-invalid-char-replace} -- ソース データ ファイルの文字セット変換中に互換性のない文字があった場合に置換する文字を指定します。 +- ソースデータファイルの文字セット変換中に互換性のない文字があった場合に置換する文字を指定します。 - この設定は、フィールドセパレーター、引用符定義子、改行と重複してはいけません。デフォルト値を変更すると、ソースデータファイルの解析パフォーマンスが低下する可能性があります。 - デフォルト値: `"\uFFFD"` 。これは、UTF-8 エンコードにおける「エラー」の Rune または Unicode 置換文字です。 @@ -455,8 +455,8 @@ CSV ファイルの解析方法を構成します。 #### `header-schema-match` {#header-schema-match} -- CSV ファイル ヘッダー内の列名が、ターゲット テーブルで定義されている列名と一致するかどうかを制御します。 -- デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲット テーブルの列名と一致していることが確認されたことを意味します。そのため、2 つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 +- CSV ファイル ヘッダー内の列名が、ターゲットテーブルで定義されている列名と一致するかどうかを制御します。 +- デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲットテーブルの列名と一致していることが確認されたことを意味します。そのため、2 つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 - CSVテーブルヘッダーとターゲットテーブルの列名が一致しない（例えば、CSVテーブルヘッダーの一部の列名がターゲットテーブルに見つからない）ものの、列の順序が同じ場合は、この設定を`false`に設定してください。この場合、 TiDB Lightningはエラーを回避するためにCSVヘッダーを無視し、ターゲットテーブルの列の順序でデータを直接インポートします。したがって、列の順序が同じでない場合は、インポート前にCSVファイル内の列の順序をターゲットテーブルの順序と一致するように手動で調整する必要があります。そうしないと、データの不一致が発生する可能性があります。 - デフォルト値: `true` - 値のオプション: `true` 、 `false` @@ -531,7 +531,7 @@ CSV ファイルの解析方法を構成します。 #### `status-port` {#status-port} -- TiDB からテーブル スキーマ情報を取得します。 +- TiDB からテーブルスキーマ情報を取得します。 @@ -629,10 +629,10 @@ CSV ファイルの解析方法を構成します。 ### 復元後 {#post-restore} -- 物理インポート モードでは、データのインポートが完了すると、 TiDB Lightning はチェックサムと`ANALYZE`操作を自動的に実行できます。 +- 物理インポートモードでは、データのインポートが完了すると、 TiDB Lightning はチェックサムと`ANALYZE`操作を自動的に実行できます。 - 実本番環境ではこれらを true のままにしておくことをお勧めします。 - 実行順序: チェックサム -> `ANALYZE` 。 -- 論理インポート モードでは、チェックサムと`ANALYZE`操作は必要なく、実際の操作では常にスキップされることに注意してください。 +- 論理インポートモードでは、チェックサムと`ANALYZE`操作は必要なく、実際の操作では常にスキップされることに注意してください。 #### `checksum` {#checksum} @@ -679,5 +679,5 @@ CSV ファイルの解析方法を構成します。 #### `check-disk-quota` {#check-disk-quota} -- 物理インポート モードを使用するときに、ローカル ディスク クォータをチェックする時間間隔を指定します。 +- 物理インポートモードを使用するときに、ローカルディスククォータをチェックする時間間隔を指定します。 - デフォルト値: `"60s"` 、これは 60 秒を意味します。 diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 522a8cdff024d..aa392c88b196d 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -1,13 +1,13 @@ --- title: TiDB Lightning Data Sources -summary: TiDB Lightningでサポートされているすべてのデータ ソースについて説明します。 +summary: TiDB Lightningでサポートされているすべてのデータソースについて説明します。 --- # TiDB Lightningデータソース {#tidb-lightning-data-sources} -TiDB Lightning は、CSV、SQL、Parquet ファイルなど、複数のデータ ソースから TiDB クラスターへのデータのインポートをサポートしています。 +TiDB Lightning は、CSV、SQL、Parquet ファイルなど、複数のデータソースから TiDB クラスターへのデータのインポートをサポートしています。 -TiDB Lightningのデータ ソースを指定するには、次の構成を使用します。 +TiDB Lightningのデータソースを指定するには、次の構成を使用します。 ```toml [mydumper] @@ -104,7 +104,7 @@ compression = '$4' CSVファイルはスキーマレスです。CSVファイルをTiDBにインポートするには、テーブルスキーマを提供する必要があります。スキーマは、以下のいずれかの方法で提供できます。 - DDL ステートメントを含む`${db_name}.${table_name}-schema.sql`および`${db_name}-schema-create.sql`名前のファイルを作成します。 -- TiDB にテーブル スキーマを手動で作成します。 +- TiDB にテーブルスキーマを手動で作成します。 ### コンフィグレーション {#configuration} @@ -368,7 +368,7 @@ TiDB Lightningは現在、 Dumplingでエクスポートされた圧縮ファイ > **Note:** > > - TiDB Lightningは単一の大きな圧縮ファイルを同時に解凍できないため、圧縮ファイルのサイズはインポート速度に影響します。解凍後のソースファイルは256MiB以下にすることをお勧めします。 -> - TiDB Lightning は個別に圧縮されたデータ ファイルのみをインポートし、複数のデータ ファイルが含まれる単一の圧縮ファイルのインポートはサポートしていません。 +> - TiDB Lightning は個別に圧縮されたデータファイルのみをインポートし、複数のデータファイルが含まれる単一の圧縮ファイルのインポートはサポートしていません。 > - TiDB Lightningは、 `db.table.parquet.snappy`などの他の圧縮ツールで圧縮された`parquet`ファイルをサポートしていません。`parquet`ファイルを圧縮する場合は、`parquet`ライターの圧縮形式を設定できます。 > - TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` 、 `snappy` 、 `zstd` 圧縮データファイルのみがサポートされています。その他の種類のファイルはエラーの原因となります。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクはエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。 > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)である必要があります。その他の Snappy 圧縮形式はサポートされていません。 @@ -377,7 +377,7 @@ TiDB Lightningは現在、 Dumplingでエクスポートされた圧縮ファイ TiDB Lightningは、命名パターンに従ったデータファイルのみを認識します。場合によっては、データファイルが命名パターンに従っていない可能性があり、その場合、ファイルのインポートなしでデータのインポートが短時間で完了します。 -この問題を解決するには、カスタマイズした式でデータ ファイルを一致させるために`[[mydumper.files]]`を使用します。 +この問題を解決するには、カスタマイズした式でデータファイルを一致させるために`[[mydumper.files]]`を使用します。 S3にエクスポートされたAuroraスナップショットを例に挙げます。Parquetファイルの完全パスは`S3://some-bucket/some-subdir/some-database/some-database.some-table/part-00000-c5a881bb-58ff-4ee6-1111-b41ecff340a3-c000.gz.parquet`です。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 8076603abb9e9..37a19f527fda6 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -1,6 +1,6 @@ --- title: Use TiDB Lightning to Import Data in Parallel -summary: TiDB Lightningを使用する際のデータの並列インポートの概念、ユーザー シナリオ、使用法、および制限について学習します。 +summary: TiDB Lightningを使用する際のデータの並列インポートの概念、ユーザーシナリオ、使用法、および制限について学習します。 --- # TiDB Lightningを使用してデータを並列インポートする {#use-tidb-lightning-to-import-data-in-parallel} @@ -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`を指定する必要があります。 @@ -178,7 +178,7 @@ type = "sql" parallel-import = true ``` -他のインスタンスの構成を変更して、 `05001 ~ 10000`データ ファイルのみをインポートすることができます。 +他のインスタンスの構成を変更して、 `05001 ~ 10000`データファイルのみをインポートすることができます。 その他の手順については、例 1 の関連する手順を参照してください。 @@ -188,15 +188,15 @@ parallel-import = true 並列インポート中に 1 つ以上のTiDB Lightningノードが異常終了した場合は、ログに記録されたエラーに基づいて原因を特定し、エラーの種類に応じてエラーを処理します。 -- エラーが通常の終了 (たとえば、kill コマンドに応答して終了) または OOM によるオペレーティング システムによる終了を示している場合は、構成を調整してから、 TiDB Lightningノードを再起動します。 +- エラーが通常の終了 (たとえば、kill コマンドに応答して終了) または OOM によるオペレーティングシステムによる終了を示している場合は、構成を調整してから、 TiDB Lightningノードを再起動します。 - ネットワーク タイムアウトなどのエラーがデータの精度に影響を与えない場合は、次の手順を実行します。 - 1. チェックポイント ソース データのエラーを消去するには、失敗したすべてのノードで設定`--checkpoint-error-ignore=all`で[`checkpoint-error-ignore`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-ignore)コマンドを実行します。 + 1. チェックポイント ソースデータのエラーを消去するには、失敗したすべてのノードで設定`--checkpoint-error-ignore=all`で[`checkpoint-error-ignore`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-ignore)コマンドを実行します。 2. チェックポイントからのデータのインポートを続行するには、これらのノードを再起動します。 -- ソース ファイル内の無効なデータを示すチェックサムの不一致など、データの不正確さにつながるエラーがログに記録されている場合は、次の手順を実行してこの問題を解決できます。 +- ソースファイル内の無効なデータを示すチェックサムの不一致など、データの不正確さにつながるエラーがログに記録されている場合は、次の手順を実行してこの問題を解決できます。 1. 成功したノードを含むすべてのLightningノードで[`checkpoint-error-destroy`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)コマンドを実行します。このコマンドは、失敗したテーブルからインポートされたデータを削除し、これらのテーブルのチェックポイントステータスを「未開始」にリセットします。 diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index 66c9ddbf3e0bd..7730a10f5b5f3 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -11,7 +11,7 @@ v5.4.0以降、 TiDB Lightningを設定して、無効な型変換や一意キ - `lightning.max-error` : 型エラーの許容閾値 - `conflict.strategy` : 競合`conflict.max-record-rows` `conflict.threshold`に関連する構成 -- `tikv-importer.duplicate-resolution` (v8.0.0 で非推奨となり、将来のリリースで削除される予定): 物理インポート モードでのみ使用できる競合処理構成 +- `tikv-importer.duplicate-resolution` (v8.0.0 で非推奨となり、将来のリリースで削除される予定): 物理インポートモードでのみ使用できる競合処理構成 - `lightning.task-info-schema-name` : TiDB Lightningが競合を検出したときに競合するデータが格納されるデータベース 詳細については[TiDB Lightning （タスク）](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を参照してください。 @@ -51,7 +51,7 @@ max-error = 0 ## エラーレポート {#error-report} -TiDB Lightning がインポート中にエラーに遭遇した場合、終了時にターミナルとログ ファイルの両方にこれらのエラーに関する統計の概要が出力されます。 +TiDB Lightning がインポート中にエラーに遭遇した場合、終了時にターミナルとログファイルの両方にこれらのエラーに関する統計の概要が出力されます。 - ターミナルのエラーレポートは次の表のようになります。 @@ -59,7 +59,7 @@ TiDB Lightning がインポート中にエラーに遭遇した場合、終了 | - | ------ | ---- | ------------------------------------- | | 1 | データ型 | 1000 | `lightning_task_info` `type_error_v1` | -- TiDB Lightningログ ファイル内のエラー レポートは次のとおりです。 +- TiDB Lightningログファイル内のエラーレポートは次のとおりです。 ```shell [2022/03/13 05:33:57.736 +08:00] [WARN] [errormanager.go:459] ["Detect 1000 data type errors in total, please refer to table `lightning_task_info`.`type_error_v1` for more details"] @@ -167,9 +167,9 @@ CREATE VIEW conflict_view AS ## 例 {#example} -この例では、いくつかの既知のエラーを含むデータ ソースが準備されます。 +この例では、いくつかの既知のエラーを含むデータソースが準備されます。 -1. データベースとテーブル スキーマを準備します。 +1. データベースとテーブルスキーマを準備します。 ```shell mkdir example && cd example @@ -197,7 +197,7 @@ CREATE VIEW conflict_view AS EOF ``` -3. TiDB Lightningを構成して厳密な SQL モードを有効にし、ローカル バックエンドを使用してデータをインポートし、重複を置き換え、最大 10 個のエラーをスキップします。 +3. TiDB Lightningを構成して厳密な SQL モードを有効にし、ローカルバックエンドを使用してデータをインポートし、重複を置き換え、最大 10 個のエラーをスキップします。 ```shell cat < config.toml diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index 3bff847040fa0..fb6f15c4948ee 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -15,7 +15,7 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ はい。 -## ターゲット データベースの権限要件は何ですか? {#what-are-the-privilege-requirements-for-the-target-database} +## ターゲットデータベースの権限要件は何ですか? {#what-are-the-privilege-requirements-for-the-target-database} 権限の詳細については[TiDB Lightningを使用するための前提条件](/tidb-lightning/tidb-lightning-requirements.md)を参照してください。 @@ -32,7 +32,7 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ TiDB Lightningはデフォルトで、ローカルデータソースとインポートされたテーブルのチェックサムを実行します。チェックサムが一致しない場合、プロセスは中止されます。このチェックサム情報はログから読み取ることができます。 -ターゲット テーブルで[`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) SQL コマンドを実行して、インポートされたデータのチェックサムを再計算することもできます。 +ターゲットテーブルで[`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md) SQL コマンドを実行して、インポートされたデータのチェックサムを再計算することもできます。 ```sql ADMIN CHECKSUM TABLE `schema`.`table`; @@ -47,7 +47,7 @@ ADMIN CHECKSUM TABLE `schema`.`table`; 1 row in set (0.01 sec) ``` -## TiDB Lightningではどのようなデータ ソース形式がサポートされていますか? {#what-kinds-of-data-source-formats-are-supported-by-tidb-lightning} +## TiDB Lightningではどのようなデータソース形式がサポートされていますか? {#what-kinds-of-data-source-formats-are-supported-by-tidb-lightning} TiDB Lightning は以下をサポートします: @@ -79,9 +79,9 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" - 手動デプロイの場合： `tidb-lightning`フォアグラウンドで実行されている場合は、 Ctrl + Cを押して終了します。それ以外の場合は、 `ps aux | grep tidb-lightning`コマンドを使用してプロセス ID を取得し、 `kill -2 ${PID}`コマンドを使用してプロセスを終了します。 -## TiDB Lightning は1 ギガビット ネットワーク カードで使用できますか? {#can-tidb-lightning-be-used-with-1-gigabit-network-card} +## TiDB Lightning は1 ギガビット ネットワークカードで使用できますか? {#can-tidb-lightning-be-used-with-1-gigabit-network-card} -TiDB Lightning は、10 ギガビット ネットワーク カードで使用するのが最適です。 +TiDB Lightning は、10 ギガビット ネットワークカードで使用するのが最適です。 1ギガビットネットワークカードは合計120MB/秒の帯域幅しか提供できず、これをすべてのターゲットTiKVストアで共有する必要があります。TiDB Lightningは、物理インポートモードで1ギガビットネットワークの全帯域幅を簡単に飽和させ、PDに接続できなくなるため、クラスタを停止させる可能性があります。 @@ -165,8 +165,8 @@ TiDB LightningでSQLの配置ルールを使用するには、データをター 1. データ分散トポロジを計画します。 2. TiKV および PD に必要なラベルを構成します。 -3. 配置ルール ポリシーを作成し、作成したポリシーをターゲット テーブルに適用します。 -4. TiDB Lightningを使用して、データをターゲット テーブルにインポートします。 +3. 配置ルール ポリシーを作成し、作成したポリシーをターゲットテーブルに適用します。 +4. TiDB Lightningを使用して、データをターゲットテーブルにインポートします。 ## TiDB LightningとDumplingを使用してスキーマをコピーするにはどうすればよいですか? {#how-can-i-use-tidb-lightning-and-dumpling-to-copy-a-schema} diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 73f3b6603a734..e8c79588ea945 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 はファイルを複数のチャンクに分割することがあります。 @@ -93,7 +93,7 @@ TiKV インポーターでは、エンジンは KV ペアをソートするた TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送します。まずエンジンを開き、KVペアを（順序は問わず）エンジンに送信し、最後にエンジンを閉じます。エンジンは閉じた後、受信したKVペアをソートします。閉じられたエンジンは、TiKVストアにアップロードして取り込みを行うことができます。 -エンジンは TiKV インポーターの`import-dir`を一時ストレージとして使用します。これは「エンジン ファイル」と呼ばれることもあります。 +エンジンは TiKV インポーターの`import-dir`を一時ストレージとして使用します。これは「エンジンファイル」と呼ばれることもあります。 [データエンジン](/tidb-lightning/tidb-lightning-glossary.md#data-engine)と[インデックスエンジン](/tidb-lightning/tidb-lightning-glossary.md#index-engine)も参照してください。 @@ -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..66f65d96f39b2 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -62,9 +62,9 @@ log-level = "error" ## パフォーマンスチューニング {#performance-tuning} -- 論理インポート モードでは、 TiDB Lightningのパフォーマンスはターゲット TiDB クラスターの書き込みパフォーマンスに大きく依存します。クラスターがパフォーマンスのボトルネックに達した場合は、 [高並行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)を参照してください。 +- 論理インポートモードでは、 TiDB Lightningのパフォーマンスはターゲット TiDB クラスターの書き込みパフォーマンスに大きく依存します。クラスターがパフォーマンスのボトルネックに達した場合は、 [高並行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)を参照してください。 -- 対象の TiDB クラスタで書き込みボトルネックが発生しない場合は、 TiDB Lightning構成の`region-concurrency`の値を増やすことを検討してください。 `region-concurrency`のデフォルト値は CPU コア数です。 `region-concurrency`の意味は、物理インポート モードと論理インポート モードで異なります。論理インポート モードでは、 `region-concurrency`は書き込み同時実行数です。 +- 対象の TiDB クラスタで書き込みボトルネックが発生しない場合は、 TiDB Lightning構成の`region-concurrency`の値を増やすことを検討してください。 `region-concurrency`のデフォルト値は CPU コア数です。 `region-concurrency`の意味は、物理インポートモードと論理インポートモードで異なります。論理インポートモードでは、 `region-concurrency`は書き込み同時実行数です。 設定例： diff --git a/tidb-lightning/tidb-lightning-logical-import-mode.md b/tidb-lightning/tidb-lightning-logical-import-mode.md index 4c87b2172bed0..13a1614f542a8 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode.md @@ -1,6 +1,6 @@ --- title: Logical Import Mode Introduction -summary: TiDB Lightningの論理インポート モードについて学習します。 +summary: TiDB Lightningの論理インポートモードについて学習します。 --- # 論理インポートモードの概要 {#logical-import-mode-introduction} @@ -9,7 +9,7 @@ summary: TiDB Lightningの論理インポート モードについて学習し TiDBクラスターに既にデータが含まれており、外部アプリケーションにサービスを提供している場合は、論理インポートモードでデータをインポートすることをお勧めします。論理インポートモードの動作は通常のSQL文の実行と同じであるため、 ACID準拠が保証されます。 -論理インポート モードのバックエンドは`tidb`です。 +論理インポートモードのバックエンドは`tidb`です。 ## 環境要件 {#environment-requirements} diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md index 3207cb81fa6cc..04b5a779a97c3 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`です。 @@ -41,7 +41,7 @@ TiDB Lightning は、 `backend`で設定された 2 つのインポート モー | ネットワーク帯域幅の消費 | 高い | 低い | | インポート時のACID準拠 | いいえ | はい | | ターゲットテーブル | 空でなければなりません | データを含むことができる | -| TiDB クラスタ バージョン | = 4.0.0 | 全て | +| TiDB クラスタバージョン | = 4.0.0 | 全て | | TiDBクラスタがインポート中にサービスを提供できるかどうか | [限定サービス](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations) | はい | diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index 154bbdaee5413..813745143aca2 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -7,7 +7,7 @@ summary: TiDB Lightningの物理インポートモードの使い方を学びま このドキュメントでは、 TiDB Lightningの[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)の使用方法について説明します。具体的には、設定ファイルの作成、パフォーマンスのチューニング、ディスククォータの設定などが含まれます。 -物理インポート モードには制限があります。物理インポートモードを使用する前に、 [制限事項](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations)必ずお読みください。 +物理インポートモードには制限があります。物理インポートモードを使用する前に、 [制限事項](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations)必ずお読みください。 ## 物理インポートモードを設定して使用する {#configure-and-use-the-physical-import-mode} @@ -142,7 +142,7 @@ analyze = "optional" 旧バージョンの競合検出では、 TiDB Lightningは2つの戦略を提供していました。 -- `remove` (推奨): ターゲット TiDB の一貫した状態を確保するために、ターゲット テーブルから競合するすべてのレコードを記録して削除します。 +- `remove` (推奨): ターゲット TiDB の一貫した状態を確保するために、ターゲットテーブルから競合するすべてのレコードを記録して削除します。 - `none` : 重複レコードを検出しません。 `none` 2 つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 バージョン5.3より前のTiDB Lightningは、競合検出をサポートしていません。競合データが存在する場合、インポート処理はチェックサムの段階で失敗します。競合検出が有効になっている場合、競合データが存在すると、 TiDB Lightningはチェックサムの段階をスキップします（常に失敗するため）。 @@ -264,7 +264,7 @@ io-concurrency = 5 インポート処理中、各テーブルはインデックスを格納するための「インデックスエンジン」1つと、行データを格納するための複数の「データエンジン」に分割されます。 -`index-concurrency`インデックス エンジンの最大同時実行数を制御します。 `index-concurrency`を調整する際は、CPU が最大限に活用されるように`index-concurrency * the number of source files of each table > region-concurrency`も必ず調整してください。比率は通常 1.5 ～ 2 です。 `index-concurrency`を高く設定しすぎたり、2 (デフォルト値) より低く設定したりしないでください。 `index-concurrency`高すぎると、パイプラインが多数構築され、インデックス エンジンのインポート ステージが滞留します。 +`index-concurrency`インデックスエンジンの最大同時実行数を制御します。 `index-concurrency`を調整する際は、CPU が最大限に活用されるように`index-concurrency * the number of source files of each table > region-concurrency`も必ず調整してください。比率は通常 1.5 ～ 2 です。 `index-concurrency`を高く設定しすぎたり、2 (デフォルト値) より低く設定したりしないでください。 `index-concurrency`高すぎると、パイプラインが多数構築され、インデックスエンジンのインポート ステージが滞留します。 `table-concurrency`についても同様です。 `table-concurrency * the number of source files of each table > region-concurrency`がCPUをフル活用していることを確認してください。推奨値は`region-concurrency * 4 / the number of source files of each table`前後で、4を下回らないようにしてください。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index d92ac86db023c..1f4f349ce4f06 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -1,13 +1,13 @@ --- title: Physical Import Mode -summary: TiDB Lightningの物理インポート モードについて学習します。 +summary: TiDB Lightningの物理インポートモードについて学習します。 --- # 物理インポートモード {#physical-import-mode} 物理インポートモードは、SQLインターフェースを経由せずに、TiKVノードにキーと値のペアとして直接データを挿入する、効率的で高速なインポートモードです。物理インポートモードを使用する場合、Lightningインスタンス1つで最大10TiBのデータをインポートできます。Lightningインスタンスの数が増えるにつれて、サポートされるインポートデータ量は理論上増加します。ユーザーによる検証では、Lightningインスタンスの[並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)で最大50TiBのデータを効率的に処理できることが示されています。 -物理インポート モードを使用する前に、必ず[要件と制限](#requirements-and-restrictions)をお読みください。 +物理インポートモードを使用する前に、必ず[要件と制限](#requirements-and-restrictions)をお読みください。 物理インポートモードのバックエンドは`local`です。 `tidb-lightning.toml`で変更できます。 @@ -23,9 +23,9 @@ backend = "local" - v7.1.0 以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、一時停止スケジュールの範囲を制御できます。 - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスタのバージョンによって異なります。TiDB クラスタが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 - - TiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。 + - TiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 -2. TiDB Lightning は、ターゲット データベースにテーブル スキーマを作成し、メタデータを取得します。 +2. TiDB Lightning は、ターゲットデータベースにテーブルスキーマを作成し、メタデータを取得します。 `add-index-by-sql`を`true`に設定した場合、 `tidb-lightning`はSQLインターフェース経由でインデックスを追加し、データをインポートする前にターゲットテーブルからすべてのセカンダリインデックスを削除します。デフォルト値は`false`で、以前のバージョンと一致しています。 @@ -33,11 +33,11 @@ backend = "local" 4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 -5. エンジン ファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 +5. エンジンファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 エンジンファイルには、**データエンジン**と**インデックスエンジン**という2種類のエンジンが含まれています。各エンジンは、キーと値のペアの種類（行データとセカンダリインデックス）に対応しています。通常、行データはデータソース内で完全に順序付けされており、セカンダリインデックスは順序付けされていません。そのため、データエンジンファイルは対応するブロックが書き込まれた直後にインポートされ、すべてのインデックスエンジンファイルはテーブル全体がエンコードされた後にのみインポートされます。 - `tidb-lightning` SQL インターフェイス経由でインデックスを追加する場合 (つまり、 `add-index-by-sql`を`true`に設定する場合)、ターゲット テーブルのセカンダリ インデックスは手順 2 で既に削除されているため、インデックス エンジンはデータを書き込まないことに注意してください。 + `tidb-lightning` SQL インターフェイス経由でインデックスを追加する場合 (つまり、 `add-index-by-sql`を`true`に設定する場合)、ターゲットテーブルのセカンダリインデックスは手順 2 で既に削除されているため、インデックスエンジンはデータを書き込まないことに注意してください。 6. すべてのエンジンファイルがインポートされた後、 TiDB Lightningはローカルデータソースと下流クラスターのチェックサムを比較し、インポートされたデータが破損していないことを確認します。その後、 TiDB Lightningはステップ2で削除したセカンダリインデックスを追加するか、TiDBに新しいデータを分析させて（ `ANALYZE` ）、将来の操作を最適化します。一方、 `tidb-lightning`は将来の競合を防ぐために`AUTO_INCREMENT`値を調整します。 @@ -89,10 +89,10 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ - v5.4.0 より前のTiDB Lightningでは、 `charset=GBK`のテーブルをインポートできません。 -- TiDB Lightning をTiCDC と併用する場合の考慮事項については、 [TiDB Lightning物理インポート モードと TiCDC 間の互換性の制限は何ですか?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 +- TiDB Lightning をTiCDC と併用する場合の考慮事項については、 [TiDB Lightning物理インポートモードと TiCDC 間の互換性の制限は何ですか?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 - BRでTiDB Lightning を使用する場合は、次の点に注意してください。 - - BR がTiDB Lightningによってインポートされているテーブルのスナップショットをバックアップすると、それらのテーブルのバックアップ データが不整合になる可能性があります。 + - BR がTiDB Lightningによってインポートされているテーブルのスナップショットをバックアップすると、それらのテーブルのバックアップデータが不整合になる可能性があります。 - BR がAWS EBS ボリュームスナップショットを使用してデータをバックアップすると、 TiDB Lightning はデータのインポートに失敗する可能性があります。 - - TiDB Lightning物理インポート モードでインポートされたデータは[ログバックアップ](/br/br-pitr-guide.md#start-log-backup)をサポートしていないため、Point-in-Time Recovery (PITR) では復元できません。 + - TiDB Lightning物理インポートモードでインポートされたデータは[ログバックアップ](/br/br-pitr-guide.md#start-log-backup)をサポートしていないため、Point-in-Time Recovery (PITR) では復元できません。 diff --git a/tidb-lightning/tidb-lightning-prechecks.md b/tidb-lightning/tidb-lightning-prechecks.md index ea6b30f57eed2..11cd2f42ca261 100644 --- a/tidb-lightning/tidb-lightning-prechecks.md +++ b/tidb-lightning/tidb-lightning-prechecks.md @@ -11,12 +11,12 @@ TiDB 5.3.0以降、 TiDB Lightningは移行タスク実行前に設定をチェ | チェック項目 | サポートされているバージョン | 説明 | | ---------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| クラスタのバージョンとステータス | = 5.3.0 | 構成でクラスターを接続できるかどうか、および TiKV/PD/ TiFlashバージョンが物理インポート モードをサポートしているかどうかを確認します。 | -| 権限 | = 5.3.0 | データ ソースがクラウドストレージ(Amazon S3) の場合、 TiDB Lightning に必要な権限があるかどうかを確認し、権限不足のためにインポートが失敗しないことを確認します。 | +| クラスタのバージョンとステータス | = 5.3.0 | 構成でクラスターを接続できるかどうか、および TiKV/PD/ TiFlashバージョンが物理インポートモードをサポートしているかどうかを確認します。 | +| 権限 | = 5.3.0 | データソースがクラウドストレージ(Amazon S3) の場合、 TiDB Lightning に必要な権限があるかどうかを確認し、権限不足のためにインポートが失敗しないことを確認します。 | | ディスク容量 | = 5.3.0 | ローカルディスクとTiKVクラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、TiDB Lightningはローカルストレージが十分かどうかも確認します。TiKVクラスターの空き容量とローカルストレージのストレージ容量 ( `sort-kv-dir`で制御) の詳細については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。 | | リージョン配信状況 | = 5.3.0 | TiKVクラスタ内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | | データファイル内の非常に大きなCSVファイル | = 5.3.0 | バックアップファイルに10GiBを超えるCSVファイルがあり、自動スライスが有効になっていない場合（StrictFormat=false）、インポートのパフォーマンスに影響します。このチェックは、データが正しい形式であること、および自動スライスが有効になっていることを確認するためのものです。 | -| ブレークポイントからの回復 | = 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソース ファイルまたはスキーマに加えられないことが保証されます。 | +| ブレークポイントからの回復 | = 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソースファイルまたはスキーマに加えられないことが保証されます。 | | 既存のテーブルにインポートする | = 5.3.0 | 既に作成されたテーブルにインポートする場合、ソースファイルが既存のテーブルと可能な限り一致するかどうかを確認します。列数が一致しているかどうかを確認します。ソースファイルに列名がある場合は、列名が一致しているかどうかを確認します。ソースファイルにデフォルトの列がある場合は、その列にデフォルト値が設定されているかどうかを確認し、設定されている場合はチェックに合格します。 | | 対象テーブルが空かどうか | = 5.3.1 | ターゲットテーブルが空でない場合、 TiDB Lightningは自動的にエラーを出力して終了します。並列インポートモードが有効（ `parallel-import = true` ）になっている場合、このチェック項目はスキップされます。 | | PITRが有効になっているか、またはクラスター内で変更フィードタスクが実行されているかどうか | = 6.5.0 | TiDB Lightning の物理インポートモードは、PITR および changefeed と互換性がありません。PITR が有効になっているか、changefeed タスクが実行中の場合、 TiDB Lightning は自動的にエラーを出力して終了します。インポートするテーブルでレプリケーションに PITR または changefeed が不要であることが確実な場合は、このチェックをスキップしてTiDB Lightning の物理インポートモードを続行できます。 | diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 6482c849869c0..819bb2e000812 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -19,7 +19,7 @@ TiDB Lightning が遅くなる理由はいくつかあります。 2. TiDB Lightning が他のサービス (TiKV Importer など) と同じマシンを共有する場合、 `region-concurrency`をCPU コアの合計数の 75% に**手動で**設定する必要があります。 3. CPUクォータ（例えばKubernetesの設定による制限）がある場合、 TiDB Lightningはそれを読み取れない可能性があります。この場合も、 `region-concurrency`を**手動で**減らす必要があります。 -**原因 2** : テーブル スキーマが複雑すぎます。 +**原因 2** : テーブルスキーマが複雑すぎます。 インデックスを追加するたびに、各行に新しいKVペアが作成されます。インデックスがN個ある場合、実際にインポートされるサイズはDumpling出力のサイズの約(N+1)倍になります。インデックスが無視できるほど小さい場合は、まずスキーマからインデックスを削除し、インポート完了後に`CREATE INDEX`を使用して再度追加することができます。 @@ -27,7 +27,7 @@ TiDB Lightning が遅くなる理由はいくつかあります。 TiDB Lightningは、データソースを256MB程度の複数のファイルに分割し、並列処理することで最適に動作します。各ファイルのサイズが大きすぎると、 TiDB Lightningが応答しない場合があります。 -データ ソースが CSV であり、すべての CSV ファイルに改行制御文字 (U+000A および U+000D) を含むフィールドがない場合は、「厳密な形式」をオンにして、 TiDB Lightning が大きなファイルを自動的に分割するようにすることができます。 +データソースが CSV であり、すべての CSV ファイルに改行制御文字 (U+000A および U+000D) を含むフィールドがない場合は、「厳密な形式」をオンにして、 TiDB Lightning が大きなファイルを自動的に分割するようにすることができます。 ```toml [mydumper] @@ -74,11 +74,11 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode **原因**: ローカルデータソースとリモートインポートデータベースのテーブルのチェックサムが異なります。このエラーには、より深刻な理由がいくつか考えられます。`checksum mismatched`を含むログを確認することで、原因をさらに特定できます。 -`checksum mismatched`を含む行は情報`total_kvs: x vs y`を提供します。ここで、 `x`はインポートの完了後にターゲット クラスターによって計算されたキーと値のペア (KV ペア) の数を示し、 `y`はローカル データ ソースによって生成されたキーと値のペアの数を示します。 +`checksum mismatched`を含む行は情報`total_kvs: x vs y`を提供します。ここで、 `x`はインポートの完了後にターゲットクラスターによって計算されたキーと値のペア (KV ペア) の数を示し、 `y`はローカルデータソースによって生成されたキーと値のペアの数を示します。 -- `x`が大きい場合は、ターゲット クラスター内にさらに多くの KV ペアが存在することを意味します。 +- `x`が大きい場合は、ターゲットクラスター内にさらに多くの KV ペアが存在することを意味します。 - インポート前にこのテーブルが空でなかったために、データのチェックサムに影響が出ている可能性があります。また、 TiDB Lightning が以前に障害を起こしてシャットダウンしたものの、正常に再起動しなかった可能性もあります。 -- `y`が大きい場合は、ローカル データ ソースにさらに多くの KV ペアが存在することを意味します。 +- `y`が大きい場合は、ローカルデータソースにさらに多くの KV ペアが存在することを意味します。 - ターゲットデータベースのチェックサムがすべて0の場合、インポートが実行されていないことを意味します。クラスターがビジー状態のため、データを受信できない可能性があります。 - エクスポートされたデータに、重複した値を持つ UNIQUE KEY や PRIMARY KEY などの重複データが含まれている可能性があります。また、下流のテーブル構造では大文字と小文字が区別されないのに対し、データは大文字と小文字が区別される可能性があります。 - その他の考えられる理由 @@ -92,11 +92,11 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all ``` -2. ターゲット データベースの負荷を軽減するために、チェックポイント (変更`[checkpoint] dsn` ) を保存するために外部データベースの使用を検討してください。 +2. ターゲットデータベースの負荷を軽減するために、チェックポイント (変更`[checkpoint] dsn` ) を保存するために外部データベースの使用を検討してください。 3. TiDB Lightningが不適切に再起動された場合は、 FAQの「 [TiDB Lightningを適切に再起動する方法](/tidb-lightning/tidb-lightning-faq.md#how-to-properly-restart-tidb-lightning) 」セクションも参照してください。 -### `Checkpoint for … has invalid status:` (エラー コード) {#checkpoint-for--has-invalid-status-error-code} +### `Checkpoint for … has invalid status:` (エラーコード) {#checkpoint-for--has-invalid-status-error-code} **原因**: [チェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)が有効になっており、 TiDB Lightningまたは TiKV Importer が以前に異常終了しています。偶発的なデータ破損を防ぐため、エラーが解決されるまでTiDB Lightning は起動しません。 @@ -104,7 +104,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode **ソリューション**： -無効なデータ ソースによってエラーが発生した場合は、 `tidb-lightning-ctl`を使用してインポートされたデータを削除し、Lightning を再起動します。 +無効なデータソースによってエラーが発生した場合は、 `tidb-lightning-ctl`を使用してインポートされたデータを削除し、Lightning を再起動します。 ```sh tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all @@ -120,7 +120,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= 1. ファイル全体が UTF-8 または GB-18030 になるようにスキーマを修正します。 -2. ターゲット データベース内の影響を受けるテーブルを手動で`CREATE` 。 +2. ターゲットデータベース内の影響を受けるテーブルを手動で`CREATE` 。 3. `[mydumper] character-set = "binary"`を設定するとチェックをスキップします。ただし、これにより対象データベースに文字化けが発生する可能性があります。 @@ -130,7 +130,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= **ソリューション**： -1. TiDB Lightningとソース データベースが同じタイム ゾーンを使用していることを確認します。 +1. TiDB Lightningとソースデータベースが同じタイムゾーンを使用していることを確認します。 TiDB Lightning を直接実行する場合、 `$TZ`環境変数を使用してタイムゾーンを強制できます。 diff --git a/tidb-limitations.md b/tidb-limitations.md index 97c730c34ae26..0c87a3a6a8f9c 100644 --- a/tidb-limitations.md +++ b/tidb-limitations.md @@ -5,7 +5,7 @@ summary: TiDB の使用制限について学習します。 # TiDB の制限 {#tidb-limitations} -このドキュメントでは、識別子の最大長や、サポートされるデータベース、テーブル、インデックス、パーティション テーブル、シーケンスの最大数など、TiDB の一般的な使用上の制限について説明します。 +このドキュメントでは、識別子の最大長や、サポートされるデータベース、テーブル、インデックス、パーティションテーブル、シーケンスの最大数など、TiDB の一般的な使用上の制限について説明します。 > **Note:** > diff --git a/tidb-monitoring-framework.md b/tidb-monitoring-framework.md index d9c6ce4ced067..941bab6cac540 100644 --- a/tidb-monitoring-framework.md +++ b/tidb-monitoring-framework.md @@ -32,7 +32,7 @@ Grafanaは、メトリクスを分析および視覚化するためのオープ - {TiDB_Cluster_name}-Disk-Performance: ディスク パフォーマンスに関連するメトリックを監視します。 - {TiDB_Cluster_name}-Kafka-Overview: Kafka に関連するメトリックを監視します。 - {TiDB_Cluster_name}-Lightning: TiDB Lightningに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Node_exporter: オペレーティング システムに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Node_exporter: オペレーティングシステムに関連するメトリックを監視します。 - {TiDB_Cluster_name}-概要: 重要なコンポーネントに関連する監視の概要。 - {TiDB_Cluster_name}-PD: PDサーバーに関連するメトリックを監視します。 - {TiDB_Cluster_name}-Performance-Read: 読み取りパフォーマンスに関連するメトリックを監視します。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 7a8e974c3b5eb..5a21850376a74 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -79,7 +79,7 @@ SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855: - [`44823:10000`](/optimizer-fix-controls.md#44823-new-in-v730) ：メモリを節約するため、プランキャッシュは、この変数で指定された数を超えるパラメータを持つクエリをキャッシュしません。長いインリストを持つクエリでもプランキャッシュを使用できるようにするには、プランキャッシュのパラメータ制限を`200`から`10000`に増やしてください。 - [`44830:ON`](/optimizer-fix-controls.md#44830-new-in-v657-and-v730) : プランキャッシュは、物理最適化中に生成された`PointGet`演算子を含む実行計画をキャッシュすることを許可します。 - [`44855:ON`](/optimizer-fix-controls.md#44855-new-in-v654-and-v730) : `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、オプティマイザは`IndexJoin`選択します。 -- [`52869:ON`](/optimizer-fix-controls.md#52869-new-in-v810) : オプティマイザがクエリ プランに対して (フル テーブル スキャン以外の) 単一のインデックス スキャン メソッドを選択できる場合、オプティマイザは自動的にインデックス マージを選択します。 +- [`52869:ON`](/optimizer-fix-controls.md#52869-new-in-v810) : オプティマイザがクエリプランに対して (フルテーブルスキャン以外の) 単一のインデックススキャン メソッドを選択できる場合、オプティマイザは自動的にインデックスマージを選択します。 ### TiKV構成 {#tikv-configurations} @@ -383,7 +383,7 @@ SET GLOBAL tidb_tso_client_rpc_mode=PARALLEL-FAST; ### 読み込み負荷の高いワークロード向けにコプロセッサキャッシュを調整する {#tune-coprocessor-cache-for-read-heavy-workloads} -[コプロセッサキャッシュ](/coprocessor-cache.md)キャッシュを最適化することで、読み取り負荷の高いワークロードのクエリ パフォーマンスを向上させることができます。このキャッシュにはコプロセッサのリクエスト結果が格納され、頻繁にアクセスされるデータの繰り返し計算が削減されます。キャッシュのパフォーマンスを最適化するには、次の手順を実行します。 +[コプロセッサキャッシュ](/coprocessor-cache.md)キャッシュを最適化することで、読み取り負荷の高いワークロードのクエリパフォーマンスを向上させることができます。このキャッシュにはコプロセッサのリクエスト結果が格納され、頻繁にアクセスされるデータの繰り返し計算が削減されます。キャッシュのパフォーマンスを最適化するには、次の手順を実行します。 1. [コプロセッサーキャッシュ](/coprocessor-cache.md#view-the-grafana-monitoring-panel)で説明した指標を使用してキャッシュヒット率を監視します。 2. キャッシュサイズを増やすことで、より大きなワーキングセットにおけるヒット率を向上させることができます。 diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md index b0bde3fd5ddde..2eae5b08cd8b9 100644 --- a/tidb-resource-control-background-tasks.md +++ b/tidb-resource-control-background-tasks.md @@ -1,6 +1,6 @@ --- title: Use Resource Control to Manage Background Tasks -summary: リソース制御を通じてバックグラウンド タスクを制御する方法を紹介します。 +summary: リソース制御を通じてバックグラウンドタスクを制御する方法を紹介します。 --- # リソース制御を使用してバックグラウンドタスクを管理する {#use-resource-control-to-manage-background-tasks} @@ -22,13 +22,13 @@ v7.4.0以降、 [TiDB リソース制御](/tidb-resource-control-ru-groups.md) - `TASK_TYPES` : バックグラウンドタスクとして管理する必要があるタスクの種類を指定します。複数のタスクの種類を指定する場合は、カンマ ( `,` ) で区切ります。 - `UTILIZATION_LIMIT` : 各 TiKV ノード上でバックグラウンドタスクが消費できるリソースの最大割合（0～100）を制限します。デフォルトでは、TiKV はノードの総リソースとフォアグラウンドタスクが現在占有しているリソースに基づいて、バックグラウンドタスクに利用可能なリソースを計算します。`UTILIZATION_LIMIT`を設定すると、バックグラウンドタスクに割り当てられるリソースはこの制限を超えません。 -TiDB は次の種類のバックグラウンド タスクをサポートしています。 +TiDB は次の種類のバックグラウンドタスクをサポートしています。 - `import` : [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してインポートタスクを実行します。TiDB Lightning の物理インポートモードと論理インポートモードの両方がサポートされています。 - `br` : [BR](/br/backup-and-restore-overview.md)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 -- `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 +- `ddl` : Reorg DDL のバッチデータ書き戻しフェーズ中のリソース使用量を制御します。 - `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 - `background` : 予約済みのタスクタイプ。システム変数[`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740)を使用して、現在のセッションのタスクタイプを`background`として指定できます。 @@ -38,7 +38,7 @@ TiDB は次の種類のバックグラウンド タスクをサポートして - `import` : [TiDB Lightning](https://docs.pingcap.com/tidb/stable/tidb-lightning-overview)を使用してインポートタスクを実行します。TiDB Lightningの物理インポートモードと論理インポートモードの両方がサポートされています。 - `br` : [BR](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 -- `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 +- `ddl` : Reorg DDL のバッチデータ書き戻しフェーズ中のリソース使用量を制御します。 - `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 - `background` : 予約済みのタスクタイプ。システム変数[`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740)を使用して、現在のセッションのタスクタイプを`background`として指定できます。 @@ -52,13 +52,13 @@ TiDB は次の種類のバックグラウンド タスクをサポートして ## 例 {#examples} -1. `br`と`ddl`バックグラウンド タスクとしてマークし、バックグラウンド タスクのリソース制限を 30% に設定して、リソース グループ`default`を変更します。 +1. `br`と`ddl`バックグラウンドタスクとしてマークし、バックグラウンドタスクのリソース制限を 30% に設定して、リソースグループ`default`を変更します。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30); ``` -2. `default`リソース グループを変更して、バックグラウンド タスクの種類を既定値に戻します。 +2. `default`リソースグループを変更して、バックグラウンドタスクの種類を既定値に戻します。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=NULL; @@ -70,7 +70,7 @@ TiDB は次の種類のバックグラウンド タスクをサポートして ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES=""); ``` -4. `default`リソース グループのバックグラウンド タスクの種類を表示する。 +4. `default`リソースグループのバックグラウンドタスクの種類を表示する。 ```sql SELECT * FROM information_schema.resource_groups WHERE NAME="default"; diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 7fd625002c05c..58a9908b0b561 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -16,21 +16,21 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と - TiDBフロー制御：TiDBフロー制御は[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します。バケットに十分なトークンがなく、リソースグループが`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 -- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの`RU_PER_SEC`の値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 +- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソースグループの`RU_PER_SEC`の値を使用して、各リソースグループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 バージョン7.4.0以降、リソース制御機能はTiFlashリソースの制御をサポートしています。その原理は、TiDBフロー制御およびTiKVスケジューリングと同様です。 - TiFlashフロー制御: [TiFlashパイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 -- TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 +- TiFlashスケジューリング: システムリソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソースグループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソースグループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 - TiFlashフロー制御: [TiFlashパイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 -- TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 +- TiFlashスケジューリング: システムリソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソースグループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソースグループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 @@ -80,7 +80,7 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と -- TiKV: [`resource-control.enabled`](/tikv-configuration-file.md#resource-control)パラメータを使用すると、リソース グループに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。 +- TiKV: [`resource-control.enabled`](/tikv-configuration-file.md#resource-control)パラメータを使用すると、リソースグループに基づいてリクエストスケジューリングを使用するかどうかを制御できます。 - TiFlash: TiFlashリソース制御を有効にするかどうかは、 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)システム変数と[`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)構成項目（v7.4.0で導入）を使用して制御できます。 @@ -140,9 +140,9 @@ TiDB Cloud Dedicated では、`CALIBRATE RESOURCE` ステートメントはサ ### リソースグループを管理する {#manage-resource-groups} -リソース グループを作成、変更、または削除するには、 `SUPER`または`RESOURCE_GROUP_ADMIN`権限が必要です。 +リソースグループを作成、変更、または削除するには、 `SUPER`または`RESOURCE_GROUP_ADMIN`権限が必要です。 -[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)コマンドを使用して、クラスターのリソース グループを作成できます。 +[`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 バックフィル率) を変更できます。リソースグループへの変更は即座に有効になります。 @@ -180,13 +180,13 @@ TiDBは、以下の3つのレベルのリソースグループ設定をサポー #### ユーザーをリソースグループにバインドする {#bind-users-to-a-resource-group} -次の例では、ユーザー`usr1`を作成し、そのユーザーをリソース グループ`rg1`にバインドします。 `rg1`は[リソースグループを作成する](#create-a-resource-group)の例で作成されたリソース グループです。 +次の例では、ユーザー`usr1`を作成し、そのユーザーをリソースグループ`rg1`にバインドします。 `rg1`は[リソースグループを作成する](#create-a-resource-group)の例で作成されたリソースグループです。 ```sql CREATE USER 'usr1'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg1; ``` -次の例では`ALTER USER`を使用して、ユーザー`usr2`をリソース グループ`rg2`にバインドします。 `rg2`は[リソースグループを作成する](#create-a-resource-group)の例で作成されたリソース グループです。 +次の例では`ALTER USER`を使用して、ユーザー`usr2`をリソースグループ`rg2`にバインドします。 `rg2`は[リソースグループを作成する](#create-a-resource-group)の例で作成されたリソースグループです。 ```sql ALTER USER usr2 RESOURCE GROUP rg2; @@ -198,10 +198,10 @@ ALTER USER usr2 RESOURCE GROUP rg2; > **Note:** > -> - `CREATE USER`または`ALTER USER`を使用してユーザーをリソース グループにバインドすると、その設定はユーザーの既存のセッションには適用されず、ユーザーの新しいセッションにのみ適用されます。 -> - TiDB はクラスタ初期化時に`default`リソース グループを自動的に作成します。このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の設定を変更することはできます。 +> - `CREATE USER`または`ALTER USER`を使用してユーザーをリソースグループにバインドすると、その設定はユーザーの既存のセッションには適用されず、ユーザーの新しいセッションにのみ適用されます。 +> - TiDB はクラスタ初期化時に`default`リソースグループを自動的に作成します。このリソースグループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。リソースグループにバインドされていないステートメントは、自動的にこのリソースグループにバインドされます。このリソースグループは削除をサポートしていませんが、RU の設定を変更することはできます。 -リソース グループからユーザーのバインドを解除するには、次のようにしてユーザーを`default`グループに再度バインドするだけです。 +リソースグループからユーザーのバインドを解除するには、次のようにしてユーザーを`default`グループに再度バインドするだけです。 ```sql ALTER USER 'usr3'@'%' RESOURCE GROUP `default`; @@ -223,11 +223,11 @@ SET RESOURCE GROUP rg1; #### 現在のステートメントをリソースグループにバインドします。 {#bind-the-current-statement-to-a-resource-group} -SQL ステートメントに[`RESOURCE_GROUP(resource_group_name)`](/optimizer-hints.md#resource_groupresource_group_name)ヒントを追加することで、ステートメントがバインドされるリソース グループを指定できます。このヒントは`SELECT` 、 `INSERT` 、 `UPDATE` 、および`DELETE`ステートメントをサポートします。 +SQL ステートメントに[`RESOURCE_GROUP(resource_group_name)`](/optimizer-hints.md#resource_groupresource_group_name)ヒントを追加することで、ステートメントがバインドされるリソースグループを指定できます。このヒントは`SELECT` 、 `INSERT` 、 `UPDATE` 、および`DELETE`ステートメントをサポートします。 システム変数[`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820)が`ON`に設定されている場合、このヒントを使用するには`SUPER`または`RESOURCE_GROUP_ADMIN`または`RESOURCE_GROUP_USER`の権限が必要です。 -次の例では、現在のステートメントをリソース グループ`rg1`にバインドします。 +次の例では、現在のステートメントをリソースグループ`rg1`にバインドします。 ```sql SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; @@ -243,7 +243,7 @@ SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; SET GLOBAL tidb_enable_resource_control = 'OFF'; ``` -2. リソース グループの RU に基づくスケジューリングを無効にするには、TiKV パラメータ[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)を`false`に設定します。 +2. リソースグループの RU に基づくスケジューリングを無効にするには、TiKV パラメータ[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)を`false`に設定します。 3. TiFlashのリソース制御を無効にするには、 TiFlash構成項目[`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) `false`に設定します。 @@ -318,7 +318,7 @@ TiDBはシステム変数[`tidb_last_query_info`](/system-variables.md#tidb_last -リソース制御を有効にすると、TiDB の[スロークエリログ](/identify-slow-queries.md)と対応するシステム テーブル[`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md)には、リソース グループ、対応する SQL の RU 消費量、および利用可能な RU を待機した時間が含まれます。 +リソース制御を有効にすると、TiDB の[スロークエリログ](/identify-slow-queries.md)と対応するシステムテーブル[`INFORMATION_SCHEMA.SLOW_QUERY`](/information-schema/information-schema-slow-query.md)には、リソースグループ、対応する SQL の RU 消費量、および利用可能な RU を待機した時間が含まれます。 @@ -330,7 +330,7 @@ TiDBはシステム変数[`tidb_last_query_info`](/system-variables.md#tidb_last #### RUの統計情報を`statements_summary`別に表示する {#view-ru-statistics-by-statements-summary} -TiDB のシステム テーブル[`INFORMATION_SCHEMA.statements_summary`](/statement-summary-tables.md#statements_summary)には、SQL ステートメントの正規化および集計された統計情報が格納されます。このシステム テーブルを使用すると、SQL ステートメントの実行パフォーマンスを表示および分析できます。また、リソース グループ名、RU 消費量、利用可能な RU の待機時間など、リソース制御に関する統計情報も含まれています。詳細については、 [`statements_summary`フィールドの説明](/statement-summary-tables.md#statements_summary-fields-description)を参照してください。 +TiDB のシステムテーブル[`INFORMATION_SCHEMA.statements_summary`](/statement-summary-tables.md#statements_summary)には、SQL ステートメントの正規化および集計された統計情報が格納されます。このシステムテーブルを使用すると、SQL ステートメントの実行パフォーマンスを表示および分析できます。また、リソースグループ名、RU 消費量、利用可能な RU の待機時間など、リソース制御に関する統計情報も含まれています。詳細については、 [`statements_summary`フィールドの説明](/statement-summary-tables.md#statements_summary-fields-description)を参照してください。 ### リソースグループのRU消費量を表示する {#view-the-ru-consumption-of-resource-groups} @@ -357,7 +357,7 @@ SELECT * FROM request_unit_by_group LIMIT 5; > **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} @@ -365,9 +365,9 @@ SELECT * FROM request_unit_by_group LIMIT 5; TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の**[TiDB]** > **[リソース制御]**ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについては[TiDBの重要な監視指標](/grafana-tidb-dashboard.md)の**リソース制御**セクションで詳しく説明されています。 -TiKV は、さまざまなリソース グループからのリクエスト QPS も記録します。詳細については、 [TiKVモニタリング指標の詳細](/grafana-tikv-dashboard.md#grpc)を参照してください。 +TiKV は、さまざまなリソースグループからのリクエスト QPS も記録します。詳細については、 [TiKVモニタリング指標の詳細](/grafana-tikv-dashboard.md#grpc)を参照してください。 -TiDB Dashboardの現在の[`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)テーブルでリソース グループのデータを表示できます。詳しくは[リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)をご覧ください。 +TiDB Dashboardの現在の[`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)テーブルでリソースグループのデータを表示できます。詳しくは[リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)をご覧ください。 @@ -399,7 +399,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー 3. すべてのリソースグループの合計リソース割り当て（ `RU_PER_SEC` ）がシステム容量を超えた場合、どうなりますか？ - TiDB は、リソース グループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソース グループのリソース要件を満たすことができます。システム リソースが制限を超えると、TiDB は優先度の高いリソース グループからの要求を満たすことを優先します。同じ優先度の要求すべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 + TiDB は、リソースグループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソースグループのリソース要件を満たすことができます。システムリソースが制限を超えると、TiDB は優先度の高いリソースグループからの要求を満たすことを優先します。同じ優先度の要求すべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 ## 参照 {#see-also} diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 85820fb3f22e6..9c647ab634e39 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -1,6 +1,6 @@ --- title: Manage Queries That Consume More Resources Than Expected (Runaway Queries) -summary: リソース管理機能を使用して、リソースを過剰に消費するクエリ (ランナウェイ クエリ) を制御および低下させる方法を紹介します。 +summary: リソース管理機能を使用して、リソースを過剰に消費するクエリ (ランナウェイクエリ) を制御および低下させる方法を紹介します。 --- # 予想以上にリソースを消費するクエリ（ランナウェイクエリ）を管理する {#manage-queries-that-consume-more-resources-than-expected-runaway-queries} @@ -18,7 +18,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ## `QUERY_LIMIT`パラメータ {#query_limit-parameters} -クエリが次のいずれかの制限を超えると、ランナウェイ クエリとして識別されます。 +クエリが次のいずれかの制限を超えると、ランナウェイクエリとして識別されます。 - `EXEC_ELAPSED` : クエリ実行時間が制限を超えていないかどうかを確認します。このルールは、読み取りおよび書き込みDMLステートメントに適用されます。 - `PROCESSED_KEYS` :コプロセッサーによって処理されるキーの数が制限を超えていないかどうかを確認します。このルールは読み取りステートメントにのみ適用されます。 @@ -37,7 +37,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 - `EXACT` 、まったく同じ SQL テキストを持つ SQL ステートメントのみが迅速に識別されることを示します。 - `SIMILAR` 、同じパターンを持つすべての SQL ステートメントが SQL ダイジェストに一致し、リテラル値が無視されることを示します。 -- `PLAN` 、同じパターンを持つすべての SQL ステートメントがプラン ダイジェストに一致することを示します。 +- `PLAN` 、同じパターンを持つすべての SQL ステートメントがプランダイジェストに一致することを示します。 `WATCH`の`DURATION`オプションは識別項目の有効期間を示し、デフォルトでは無期限です。 @@ -47,9 +47,9 @@ summary: リソース管理機能を使用して、リソースを過剰に消 | パラメータ | 説明 | 注記 | | ---------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | -| `EXEC_ELAPSED` | クエリ実行時間がこの値を超えると、暴走クエリとして識別されます。 | EXEC_ELAPSED = `60s` 、クエリの実行に 60 秒以上かかる場合、クエリがランナウェイ クエリとして識別されることを意味します。 | -| `PROCESSED_KEYS` | コプロセッサーによって処理されるキーの数がこの値を超えると、クエリは暴走クエリとして識別されます。 | `PROCESSED_KEYS = 1000` 、コプロセッサーによって処理されるキーの数が 1000 を超えると、クエリがランナウェイ クエリとして識別されることを意味します。 | -| `RU` | クエリによって消費される読み取りおよび書き込みRUの合計数がこの値を超えると、このクエリはランナウェイクエリとして識別されます。 | `RU = 1000` 、クエリによって消費される読み取り RU と書き込み RU の合計数が 1000 を超える場合に、クエリがランナウェイ クエリとして識別されることを意味します。 | +| `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`です。 | | `WATCH` | 特定されたランナウェイクエリを迅速に照合します。一定時間内に同一または類似のクエリが再度検出された場合、対応するアクションが直ちに実行されます。 | オプション。たとえば、 `WATCH=SIMILAR DURATION '60s'` 、 `WATCH=EXACT DURATION '1m'` 、 `WATCH=PLAN`などです。 | @@ -59,19 +59,19 @@ 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'); ``` -3. ランナウェイ クエリ チェックをキャンセルするには、 `rg1`リソース グループを変更します。 +3. ランナウェイクエリ チェックをキャンセルするには、 `rg1`リソースグループを変更します。 ```sql ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL; @@ -92,7 +92,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 - `PLAN DIGEST`は`PLAN`と同じです。次のパラメータはダイジェスト文字列です。 - `SQL TEXT`入力SQLを生の文字列（ `EXACT` ）として一致させるか、次のパラメータに応じて`SQL DIGEST` （ `SIMILAR` ）または`PLAN DIGEST` （ `PLAN` ）に解析してコンパイルします。 -- デフォルトのリソース グループのランナウェイ クエリ監視リストに一致する機能を追加します (事前にデフォルトのリソース グループに`QUERY LIMIT`設定する必要があります)。 +- デフォルトのリソースグループのランナウェイクエリ監視リストに一致する機能を追加します (事前にデフォルトのリソースグループに`QUERY LIMIT`設定する必要があります)。 ```sql QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2'; @@ -104,13 +104,13 @@ summary: リソース管理機能を使用して、リソースを過剰に消 QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- SQL を SQL ダイジェストに解析して、 `rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `SWITCH_GROUP(rg2)`として指定します。 +- SQL を SQL ダイジェストに解析して、 `rg1`リソースグループのランナウェイクエリ監視リストに一致する機能を追加し、 `ACTION` `SWITCH_GROUP(rg2)`として指定します。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION SWITCH_GROUP(rg2) SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- `PLAN DIGEST`を使用して`rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `KILL`として指定します。 +- `PLAN DIGEST`を使用して`rg1`リソースグループのランナウェイクエリ監視リストに一致する機能を追加し、 `ACTION` `KILL`として指定します。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57'; @@ -142,7 +142,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ## 可観測性 {#observability} -ランナウェイ クエリに関する詳細情報は、次のシステム テーブルおよび`INFORMATION_SCHEMA`から取得できます。 +ランナウェイクエリに関する詳細情報は、次のシステムテーブルおよび`INFORMATION_SCHEMA`から取得できます。 - `mysql.tidb_runaway_queries`テーブルには、過去 7 日間に特定されたすべてのランナウェイクエリの履歴レコードが含まれています。例として、1 つの行を見てみましょう。 @@ -162,7 +162,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 フィールドの説明: - - `start_time` 、ランナウェイ クエリが識別された時間を示します。 + - `start_time` 、ランナウェイクエリが識別された時間を示します。 - `repeats` 、 `start_time`以降にランナウェイクエリが識別された回数を示します。 - `match_type` 、ランナウェイクエリの識別方法を示します。値は次のいずれかになります。 - `identify`ランナウェイクエリの条件に一致することを意味します。 diff --git a/tidb-scheduling.md b/tidb-scheduling.md index c028242642856..4fe7a67e8e455 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -25,7 +25,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン - レプリカの数が予想より多い場合 (たとえば、障害が発生したストアがリカバリ後にクラスターに再参加する場合)、PD はそれらを削除する必要があります。 - 読み取り/書き込み操作はリーダー上で実行されますが、少数の個別のストアにのみ分散することはできません。 - すべてのリージョンがホットなわけではないので、すべての TiKV ストアの負荷をバランスさせる必要があります。 -- リージョンのバランスが取れている場合、データ転送に多くのネットワーク/ディスク トラフィックと CPU 時間が必要となり、オンライン サービスに影響する可能性があります。 +- リージョンのバランスが取れている場合、データ転送に多くのネットワーク/ディスク トラフィックと CPU 時間が必要となり、オンラインサービスに影響する可能性があります。 これらの状況は同時に発生する可能性があり、解決が困難になります。また、システム全体が動的に変化するため、クラスタに関するすべての情報を収集し、クラスタを調整するスケジューラが必要です。そこで、TiDBクラスタにPDが導入されました。 @@ -44,7 +44,7 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン - すべてのリージョンリーダーはストアに均等に分散されます。 - すべての TiKV ピアのストレージ容量がバランスされています。 - ホットスポットはバランスが取れています。 - - オンライン サービスの安定性を確保するには、リージョンの負荷分散の速度を制限する必要があります。 + - オンラインサービスの安定性を確保するには、リージョンの負荷分散の速度を制限する必要があります。 - メンテナーはピアを手動でオンライン/オフラインにすることができます。 最初のタイプの要件が満たされると、システムは障害を許容できるようになります。2番目のタイプの要件が満たされると、リソースはより効率的に利用され、システムのスケーラビリティが向上します。 @@ -126,7 +126,7 @@ PDは、リージョンリーダーのハートビートから、リージョン **戦略3: レプリカはストア間でバランスをとる必要がある** -リージョンレプリカのサイズ制限は固定されているため、ストア間でレプリカのバランスを保つことは、データ サイズのバランスを保つのに役立ちます。 +リージョンレプリカのサイズ制限は固定されているため、ストア間でレプリカのバランスを保つことは、データサイズのバランスを保つのに役立ちます。 **戦略4：ストア間でリーダーのバランスをとる必要がある** @@ -134,7 +134,7 @@ PDは、リージョンリーダーのハートビートから、リージョン **戦略5：ストア間でホットスポットのバランスをとる必要がある** -PD は、ストア ハートビートとリージョンハートビートからホット スポットを検出し、ホット スポットを分散することができます。 +PD は、ストア ハートビートとリージョンハートビートからホットスポットを検出し、ホットスポットを分散することができます。 **戦略6: 保管サイズはストア間でバランスをとる必要がある** diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index bb52804fc4e0f..30f65735fa24b 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -199,11 +199,11 @@ CPU ボトルネックとトランザクションの競合によって引き起 ### 3.8 ロックの競合 {#38-lock-conflicts} -TiDB は完全な分散トランザクションをサポートします。 v3.0 以降、TiDB は楽観的トランザクション モードと悲観的トランザクション モードを提供します。ロック関連の問題のトラブルシューティング方法、および楽観的ロックと悲観的ロックの競合の処理方法については、[ロックの競合をトラブルシューティングする](/troubleshoot-lock-conflicts.md)を参照してください。 +TiDB は完全な分散トランザクションをサポートします。 v3.0 以降、TiDB は楽観的トランザクションモードと悲観的トランザクションモードを提供します。ロック関連の問題のトラブルシューティング方法、および楽観的ロックと悲観的ロックの競合の処理方法については、[ロックの競合をトラブルシューティングする](/troubleshoot-lock-conflicts.md)を参照してください。 ### 3.9 データと指標の不整合 {#39-inconsistency-between-data-and-indexes} -TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントの実行時に、データとインデックスの一貫性をチェックします。チェックの結果、レコードのキーと値、および対応するインデックスのキーと値が一致しない、つまり、行データを格納するキーと値のペアと、そのインデックスを格納する対応するキーと値のペアが一致しない（例えば、インデックスが多すぎる、またはインデックスが欠落している）ことが判明した場合、TiDB はデータ不整合エラーを報告し、関連するエラーをエラー ログに出力。 +TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントの実行時に、データとインデックスの一貫性をチェックします。チェックの結果、レコードのキーと値、および対応するインデックスのキーと値が一致しない、つまり、行データを格納するキーと値のペアと、そのインデックスを格納する対応するキーと値のペアが一致しない（例えば、インデックスが多すぎる、またはインデックスが欠落している）ことが判明した場合、TiDB はデータ不整合エラーを報告し、関連するエラーをエラーログに出力。 不整合エラーとチェックを回避する方法の詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)を参照してください。 @@ -401,24 +401,24 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 6.1.2 `Access denied for user 'root'@'172.31.43.27' (using password: YES)` `query status`を実行したとき、またはログを確認したときに表示されます。 - すべてのDM設定ファイル内のデータベース関連のパスワードは`dmctl`で暗号化する必要があります。データベースパスワードが空の場合は、パスワードを暗号化する必要はありません。バージョン1.0.6以降では、平文パスワードを使用できます。 - - DM 操作中、アップストリームおよびダウンストリーム データベースのユーザーは、対応する読み取りおよび書き込み権限を持っている必要があります。データ移行も、データ複製タスクの開始時に自動的に[対応する権限を事前チェックします](/dm/dm-precheck.md)。 + - DM 操作中、アップストリームおよびダウンストリームデータベースのユーザーは、対応する読み取りおよび書き込み権限を持っている必要があります。データ移行も、データ複製タスクの開始時に自動的に[対応する権限を事前チェックします](/dm/dm-precheck.md)。 - DM クラスターに異なるバージョンの DM-worker/DM-master/dmctl をデプロイするには、 [AskTUGに関するケーススタディ](https://pingkai.cn/tidbcommunity/forum/t/topic/1049/5)を参照してください。 -- 6.1.3 レプリケーション タスクが`driver: bad connection`エラーで中断されました。 +- 6.1.3 レプリケーションタスクが`driver: bad connection`エラーで中断されました。 - `driver: bad connection`エラーは、DM と下流の TiDB データベース間の接続で異常が発生したこと (ネットワーク障害や TiDB の再起動など) と、現在のリクエストのデータがまだ TiDB に送信されていないことを示しています。 - DM 1.0.0 GA より前のバージョンでは、 `stop-task`を実行してタスクを停止し、 `start-task`を実行してタスクを再起動します。 - DM 1.0.0 GA以降のバージョンでは、この種のエラーに対する自動再試行メカニズムが追加されています。詳細は[#265](https://github.com/pingcap/dm/pull/265)を参照してください。 -- 6.1.4 レプリケーション タスクが`invalid connection`エラーで中断されました。 +- 6.1.4 レプリケーションタスクが`invalid connection`エラーで中断されました。 - - `invalid connection`エラーは、DM と下流の TiDB データベース間の接続で異常 (ネットワーク障害、TiDB の再起動、TiKV のビジーなど) が発生し、現在のリクエストのデータの一部が TiDB に送信されたことを示しています。DM はレプリケーション タスクで下流にデータを同時にレプリケートする機能があるため、タスクが中断されるといくつかのエラーが発生する可能性があります。これらのエラーは`query-status`または`query-error`を実行して確認できます。 + - `invalid connection`エラーは、DM と下流の TiDB データベース間の接続で異常 (ネットワーク障害、TiDB の再起動、TiKV のビジーなど) が発生し、現在のリクエストのデータの一部が TiDB に送信されたことを示しています。DM はレプリケーションタスクで下流にデータを同時にレプリケートする機能があるため、タスクが中断されるといくつかのエラーが発生する可能性があります。これらのエラーは`query-status`または`query-error`を実行して確認できます。 - 増分レプリケーション処理中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 - DM がリトライしない、またはバージョン問題のために自動的にリトライできない場合 (自動リトライは v1.0.0-rc.1 で導入されました)、 `stop-task`を使用してタスクを停止し、 `start-task`を使用してタスクを再起動します。 -- 6.1.5 リレーユニットがエラー`event from * in * diff from passed-in event *`を報告するか、レプリケーション タスクがbinlogの取得または解析に失敗するエラー（例: `get binlog error ERROR 1236 (HY000) and binlog checksum mismatch, data may be corrupted returned`で中断される。 +- 6.1.5 リレーユニットがエラー`event from * in * diff from passed-in event *`を報告するか、レプリケーションタスクがbinlogの取得または解析に失敗するエラー（例: `get binlog error ERROR 1236 (HY000) and binlog checksum mismatch, data may be corrupted returned`で中断される。 - DMがリレーログを取得するプロセス、または増分レプリケーションのプロセス中に、アップストリームのbinlogファイルのサイズが4GBを超えると、次の2つのエラーが発生する可能性があります。 @@ -438,7 +438,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - `relay.meta`に記録されたbinlogイベントにより、不完全なリカバリプロセスがトリガーされ、誤ったGTID情報が記録されます。この問題はv1.0.2で修正されていますが、それ以前のバージョンでは発生する可能性があります。 -- 6.1.7 DM レプリケーション プロセスでエラー`Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`が返されます。 +- 6.1.7 DM レプリケーションプロセスでエラー`Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`が返されます。 - この値は MySQL 8.0 または TiDB には正常に書き込めませんが、 MySQL 5.7には書き込めます。 `tidb_skip_utf8_check`パラメータを有効にすることで、データ形式のチェックをスキップできます。 @@ -505,7 +505,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND TiKVコプロセッサが長いキューに入っている理由を調査する必要があります。 -- 7.1.3 `region_cache.go`は`switch region peer to next due to send request fail`を多数報告し、エラー メッセージは`context deadline exceeded`です。 +- 7.1.3 `region_cache.go`は`switch region peer to next due to send request fail`を多数報告し、エラーメッセージは`context deadline exceeded`です。 TiKV へのリクエストがタイムアウトし、リージョン キャッシュがリクエストを他のノードに切り替えるようにトリガーされました。ログの`grep " cancelled`フィールドで`addr`コマンドを引き続き実行し、 `grep`の結果に応じて以下の手順を実行してください。 diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md index 67b7174ba1bf3..6ad6732e3239b 100644 --- a/tidb-upgrade-migration-guide.md +++ b/tidb-upgrade-migration-guide.md @@ -16,10 +16,10 @@ summary: 完全バックアップと復元のためのBRと、増分データレ 1. **リスクの事前チェック**: クラスターの状態とソリューションの実現可能性を確認します。 2. **新しいクラスターを準備します**。古いクラスターの完全バックアップから新しいクラスターを作成し、それをターゲット バージョンにアップグレードします。 3. **増分データを複製する**: TiCDC を使用して順方向データ複製チャネルを確立します。 -4. **切り替えと検証**: 多次元検証を実行し、ビジネス トラフィックを新しいクラスターに切り替え、TiCDC リバース レプリケーション チャネルを設定します。 +4. **切り替えと検証**: 多次元検証を実行し、ビジネストラフィックを新しいクラスターに切り替え、TiCDC リバース レプリケーション チャネルを設定します。 5. **ステータスの監視**：リバースレプリケーションチャネルを維持します。監視期間終了後、環境をクリーンアップします。 -**ロールバック プラン**: 移行およびアップグレード プロセス中に新しいクラスターで問題が発生した場合、いつでもビジネス トラフィックを元のクラスターに戻すことができます。 +**ロールバック プラン**: 移行およびアップグレードプロセス中に新しいクラスターで問題が発生した場合、いつでもビジネストラフィックを元のクラスターに戻すことができます。 以下のセクションでは、TiDB クラスターの移行とアップグレードに関する標準化されたプロセスと一般的な手順について説明します。コマンド例は、TiDB Self-Managed環境に基づいています。 @@ -33,7 +33,7 @@ summary: 完全バックアップと復元のためのBRと、増分データレ - **テーブルスキーマの要件**：レプリケートするテーブルに有効なインデックスが含まれていることを確認してください。詳細については、 [TiCDC有効インデックス](/ticdc/ticdc-overview.md#valid-index)を参照してください。 - **機能制限**：TiCDCはシーケンスDDLレプリケーションまたはTiFlash DDLレプリケーションをサポートしていません。詳細については、 [TiCDC がサポートしていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)を参照してください。 - - **ベスト プラクティス**: スイッチオーバー中に TiCDC のアップストリーム クラスターで DDL 操作を実行しないでください。 + - **ベストプラクティス**: スイッチオーバー中に TiCDC のアップストリームクラスターで DDL 操作を実行しないでください。 - BRの互換性を確認します。 @@ -65,7 +65,7 @@ SET GLOBAL tidb_gc_life_time=60h; 完全なデータを新しいクラスターに移行するときは、次の点に注意してください。 -- **バージョンの互換性**: バックアップと復元に使用されるBRバージョンは、古いクラスターのメジャー バージョンと一致する必要があります。 +- **バージョンの互換性**: バックアップと復元に使用されるBRバージョンは、古いクラスターのメジャーバージョンと一致する必要があります。 - **パフォーマンスへの影響**： BRバックアップはシステムリソースを消費します。ビジネスへの影響を最小限に抑えるには、オフピーク時間帯にバックアップを実行してください。 @@ -76,7 +76,7 @@ SET GLOBAL tidb_gc_life_time=60h; - **コンフィグレーションの整合性**：古いクラスタと新しいクラスタの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。 -- **システム テーブルの復元**: BR復元中に`--with-sys-table`オプションを使用して、システム テーブル データを復元します。 +- **システムテーブルの復元**: BR復元中に`--with-sys-table`オプションを使用して、システムテーブルデータを復元します。 完全なデータを新しいクラスターに移行するには、次の手順を実行します。 @@ -125,7 +125,7 @@ tiup cluster start # Start the cluster > **Note:** > -> TiCDCコンポーネントのバージョンは、古いクラスターのメジャー バージョンと一致する必要があります。 +> TiCDCコンポーネントのバージョンは、古いクラスターのメジャーバージョンと一致する必要があります。 - Changefeedタスクを作成し、データ損失を防ぐために、増分レプリケーションの開始点（ `${tso}` ）を[ステップ2](#step-2-prepare-the-new-cluster)で記録したバックアップTSOと正確に設定します。 @@ -133,7 +133,7 @@ tiup cluster start # Start the cluster tiup ctl:${cluster_version} cdc changefeed create --server http://${cdc_host}:${cdc_port} --sink-uri="mysql://${username}:${password}@${tidb_endpoint}:${port}" --config config.toml --start-ts ${tso} ``` -- レプリケーション タスクのステータスを確認し、 `tso`または`checkpoint`継続的に進んでいることを確認します。 +- レプリケーションタスクのステータスを確認し、 `tso`または`checkpoint`継続的に進んでいることを確認します。 ```shell tiup ctl:${cluster_version} cdc changefeed list --server http://${cdc_host}:${cdc_port} @@ -153,12 +153,12 @@ tiup cluster start # Start the cluster }] ``` -増分データ レプリケーション中は、レプリケーション チャネルの状態を継続的に監視し、必要に応じて設定を調整します。 +増分データレプリケーション中は、レプリケーション チャネルの状態を継続的に監視し、必要に応じて設定を調整します。 - レイテンシ メトリック: `Changefeed checkpoint lag`が 5 分以内などの許容範囲内に留まることを確認します。 - スループットの健全性: `Sink flush rows/s`が一貫してビジネス書き込みレートを超えていることを確認します。 - エラーとアラート: TiCDC ログとアラート情報を定期的に確認してください。 -- (オプション) テスト データ レプリケーション: テスト データを更新し、Changefeed がそれを新しいクラスターに正しく複製することを確認します。 +- (オプション) テストデータレプリケーション: テストデータを更新し、Changefeed がそれを新しいクラスターに正しく複製することを確認します。 - (オプション) TiCDC 構成項目[`gc-ttl`](/ticdc/ticdc-server-config.md#gc-ttl)を調整します (デフォルトは 24 時間)。 レプリケーションタスクが利用できない、または中断され、時間内に解決できない場合、 `gc-ttl` TiCDC に必要なデータがガベージコレクション(GC) によって消去されることなく TiKV に保持されることを保証します。この期間を超えると、レプリケーションタスクは`failed`状態になり、回復できなくなります。この場合、PD の GC セーフポイントは引き続き前進し、プロセスを再開するには新しいバックアップが必要になります。 @@ -177,7 +177,7 @@ tiup cluster start # Start the cluster - [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)を参照してください。 -- テーブルの行数の比較など、ビジネス データの手動検証を実行します。 +- テーブルの行数の比較など、ビジネスデータの手動検証を実行します。 ### 3. 環境設定を完了する {#3-finalize-the-environment-setup} @@ -188,7 +188,7 @@ tiup cluster start # Start the cluster - AUTO_INCREMENT列: 新しいクラスター内のAUTO_INCREMENT ID キャッシュをクリアします。 - 統計: 統計を手動で収集するか、新しいクラスターで自動収集を有効にします。 -さらに、新しいクラスターをスケールアウトして、予想されるワークロードを処理し、アラート サブスクリプション、スケジュールされた統計収集スクリプト、データ バックアップ スクリプトなどの運用タスクを移行することもできます。 +さらに、新しいクラスターをスケールアウトして、予想されるワークロードを処理し、アラート サブスクリプション、スケジュールされた統計収集スクリプト、データバックアップ スクリプトなどの運用タスクを移行することもできます。 ## ステップ4: ビジネストラフィックの切り替えとロールバック {#step-4-switch-business-traffic-and-rollback} @@ -208,7 +208,7 @@ tiup cluster start # Start the cluster 1. 古いクラスタがビジネストラフィックを処理できないように、アプリケーションサービスを停止します。アクセスをさらに制限するには、次のいずれかの方法を使用します。 - - 古いクラスター内のユーザー アカウントをロックします。 + - 古いクラスター内のユーザーアカウントをロックします。 ```sql ALTER USER ACCOUNT LOCK; @@ -235,7 +235,7 @@ tiup cluster start # Start the cluster - TiCDC が追いついたら、新しいクラスターから`down-tso`を取得します。 - [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)ツールを使用して、 `up-tso`と`down-tso`の新しいクラスターと古いクラスター間のデータの一貫性を比較します。 -4. フォワード Changefeed レプリケーション タスクを一時停止します。 +4. フォワード Changefeed レプリケーションタスクを一時停止します。 ```shell tiup ctl:${cluster_version} cdc changefeed pause --server http://${cdc_host}:${cdc_port} -c @@ -261,7 +261,7 @@ tiup cluster start # Start the cluster 7. 新しいクラスターから古いクラスターへのリバースレプリケーションを設定します。 - 1. 古いクラスター内のユーザー アカウントのロックを解除し、読み取り/書き込みモードを復元します。 + 1. 古いクラスター内のユーザーアカウントのロックを解除し、読み取り/書き込みモードを復元します。 ```sql ALTER USER ACCOUNT UNLOCK; @@ -285,14 +285,14 @@ tiup cluster start # Start the cluster tiup ctl:${cluster_version} cdc changefeed list --server http://${cdc_host}:${cdc_port} ``` -8. ビジネス トラフィックを新しいクラスターにリダイレクトします。 +8. ビジネストラフィックを新しいクラスターにリダイレクトします。 9. 次の Grafana パネルを使用して、新しいクラスターの負荷と動作ステータスを監視します。 - [**TiDBダッシュボード > クエリサマリー**](/grafana-tidb-dashboard.md#query-summary) : 期間、QPS、失敗したクエリ OPM メトリックを確認します。 - [**TiDBダッシュボード > サーバー**](/grafana-tidb-dashboard.md#server) :**接続数**メトリックを監視して、ノード間で接続が均等に分散されていることを確認します。 -この時点で、ビジネス トラフィックは新しいクラスターに正常に切り替えられ、TiCDC リバース レプリケーション チャネルが確立されます。 +この時点で、ビジネストラフィックは新しいクラスターに正常に切り替えられ、TiCDC リバース レプリケーション チャネルが確立されます。 ### 3. 緊急ロールバックを実行する {#3-execute-emergency-rollback} @@ -310,7 +310,7 @@ tiup cluster start # Start the cluster 1. 新しいクラスターへのビジネス アクセスを停止します。 2. ビジネス アカウントを再認証し、古いクラスターへの読み取り/書き込みアクセスを復元します。 3. リバース レプリケーション リンクをチェックし、TiCDC が追いついていることを確認し、新しいクラスターと古いクラスター間のデータの一貫性を検証します。 - 4. ビジネス トラフィックを古いクラスターにリダイレクトします。 + 4. ビジネストラフィックを古いクラスターにリダイレクトします。 ## ステップ5：クリーンアップ {#step-5-clean-up} diff --git a/tiflash-deployment-topology.md b/tiflash-deployment-topology.md index c0a757b766512..d7e2920daf949 100644 --- a/tiflash-deployment-topology.md +++ b/tiflash-deployment-topology.md @@ -28,15 +28,15 @@ TiFlashは列指向型ストレージエンジンであり、徐々に標準的 - [TiFlashトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml) - [TiFlashトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +上記の TiDB クラスター トポロジファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} - PD の[配置ルール](/configure-placement-rules.md)機能を有効にするには、構成テンプレートの`replication.enable-placement-rules`の値を`true`に設定します。 -- `tiflash_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 +- `tiflash_servers`のインスタンスレベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 - TiFlashパラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)を参照してください。 > **Note:** > > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPクラスタコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 56c2d7c560b15..de9a16b9c6b23 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -34,18 +34,18 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - `cop_execution` : 現在実行中のコプロセッサ要求の数。 - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。`table_scan`はテーブル スキャン演算子、 `selection`は選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`はデータ受信演算子です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。`table_scan`はテーブルスキャン演算子、 `selection`は選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`はデータ受信演算子です。 ### レイテンシメトリクス {#latency-metrics} 次のメトリックを使用して、 TiFlashのレイテンシーを取得できます。 -- リクエスト期間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエスト タイプの 1 秒あたりの合計処理期間の積み上げグラフを提供します。 +- リクエスト期間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエストタイプの 1 秒あたりの合計処理期間の積み上げグラフを提供します。 - リクエストのタイプが`run_mpp_task` 、 `dispatch_mpp_task` 、または`mpp_establish_conn`の場合、SQL文の実行がTiFlashに部分的または完全にプッシュダウンされたことを示します。これには通常、結合操作とデータ分散操作が含まれます。これはTiFlashで最も一般的なリクエストタイプです。 - リクエストのタイプが`cop`の場合、そのリクエストに関連するステートメントがTiFlashに完全にプッシュダウンされていないことを示します。通常、TiDB はデータアクセスとフィルタリングのために、テーブルフルスキャン演算子をTiFlashにプッシュダウンします。積み上げチャートで`cop`が最も多く表示されるリクエストタイプになった場合は、それが妥当かどうかを確認する必要があります。 - - SQL ステートメントによってクエリされるデータの量が大きい場合、オプティマイザーはコスト モデルに従って、 TiFlash のフル テーブル スキャンの方がコスト効率が高いと見積もる場合があります。 + - SQL ステートメントによってクエリされるデータの量が大きい場合、オプティマイザーはコストモデルに従って、 TiFlash のフルテーブルスキャンの方がコスト効率が高いと見積もる場合があります。 - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザーはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 - 要求期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサ要求タイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 @@ -56,7 +56,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次の図のワークロードでは、 `run_mpp_task`と`mpp_establish_conn`要求が合計処理時間の大部分を占めており、要求のほとんどが実行のためにTiFlashに完全にプッシュダウンされる MPP タスクであることがわかります。 -`cop`リクエストの処理時間は比較的短いため、リクエストの一部はデータ アクセスとコプロセッサを介したフィルタリングのためにTiFlashにプッシュダウンされていることがわかります。 +`cop`リクエストの処理時間は比較的短いため、リクエストの一部はデータアクセスとコプロセッサを介したフィルタリングのためにTiFlashにプッシュダウンされていることがわかります。 ![CH-TiFlash-MPP](/media/performance/tiflash/ch-2tiflash-op.png) @@ -68,7 +68,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ ### ラフト関連のメトリクス {#raft-related-metrics} -次のメトリックを使用して、 TiFlashのRaftレプリケーション ステータスを取得できます。 +次のメトリックを使用して、 TiFlashのRaftレプリケーションステータスを取得できます。 - Raft待機インデックス期間: すべてのTiFlashインスタンスのローカルリージョンインデックスが`read_index`になるまでの待機時間。これは、 `wait_index`操作のレイテンシーを表します。この指標が高すぎる場合、TiKV からTiFlashへのデータレプリケーションに大きなレイテンシーがあることを示しています。考えられる原因は次のとおりです。 diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index 9475153bc0de5..a3577bf67954a 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -7,7 +7,7 @@ summary: TiFlash をアップグレードする際の注意事項を説明しま このドキュメントでは、 TiFlash をアップグレードするときに知っておく必要のある機能の変更と推奨されるアクションについて説明します。 -標準的なアップグレード プロセスについては、次のドキュメントを参照してください。 +標準的なアップグレードプロセスについては、次のドキュメントを参照してください。 - [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md) - [Kubernetes 上の TiDB をアップグレードする](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster) diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 139210ae1fb4a..15b0a41247104 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -68,7 +68,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ' 上記のステートメントの結果は次のようになります。 -- `AVAILABLE`は、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`は使用可能、 `0`は使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 +- `AVAILABLE`は、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`は使用可能、 `0`は使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーションステータスは再計算されます。 - `PROGRESS`はレプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`は少なくとも 1 つのレプリカがレプリケートされていることを意味します。 ## データベースのTiFlashレプリカを作成する {#create-tiflash-replicas-for-databases} @@ -106,7 +106,7 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; > > - ステートメントの実行が完了した**後に**このデータベースにテーブルを作成した場合、これらの新しいテーブルに対してTiFlashレプリカは自動的に作成されません。 > -> - このステートメントは、システム テーブル、ビュー、一時テーブル、およびTiFlashでサポートされていない文字セットを持つテーブルをスキップします。 +> - このステートメントは、システムテーブル、ビュー、一時テーブル、およびTiFlashでサポートされていない文字セットを持つテーブルをスキップします。 > - システム変数[`tidb_batch_pending_tiflash_count`](/system-variables.md#tidb_batch_pending_tiflash_count-new-in-v60)を設定することで、実行中に利用不可のままにできるテーブルの数を制御できます。この値を下げると、レプリケーション中のクラスターへの負荷を軽減できます。ただし、この制限はリアルタイムではないため、設定適用後も利用不可のテーブルの数が制限を超える可能性があります。 @@ -134,7 +134,7 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " -TiDB クラスターは、次のいずれかの操作を実行すると、 TiFlashレプリカのレプリケーション プロセスをトリガーします。 +TiDB クラスターは、次のいずれかの操作を実行すると、 TiFlashレプリカのレプリケーションプロセスをトリガーします。 - テーブルにTiFlashレプリカを追加します。 - 新しいTiFlashインスタンスを追加すると、PD は元のインスタンスのTiFlashレプリカを新しいTiFlashインスタンスにスケジュールします。 @@ -173,14 +173,14 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla 数分以内に、 TiFlashノードのCPUとディスクIOリソース使用量が大幅に増加し、 TiFlashによるレプリカ作成速度が速くなります。同時に、TiKVノードのCPUとディスクIOリソース使用量も増加します。 - この時点で TiKV ノードとTiFlashノードにまだ余分なリソースがあり、オンライン サービスのレイテンシーが大幅に増加しない場合は、制限をさらに緩和して、たとえば元の速度を 3 倍にすることができます。 + この時点で TiKV ノードとTiFlashノードにまだ余分なリソースがあり、オンラインサービスのレイテンシーが大幅に増加しない場合は、制限をさらに緩和して、たとえば元の速度を 3 倍にすることができます。 ```shell tiup ctl:v pd -u http://:2379 store limit all engine tiflash 90 add-peer tiup ctl:v pd -u http://:2379 store limit all engine tiflash 90 remove-peer ``` -3. TiFlashレプリケーションが完了したら、オンライン サービスへの影響を軽減するために、デフォルト構成に戻します。 +3. TiFlashレプリケーションが完了したら、オンラインサービスへの影響を軽減するために、デフォルト構成に戻します。 デフォルトのレプリカ スケジューリング速度制限を復元するには、次のPD Controlコマンドを実行します。 @@ -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..397e1a2a9b3e1 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -39,7 +39,7 @@ TiFlash のバージョンを確認するには、次の 2 つの方法があり ## TiFlashシステムテーブル {#tiflash-system-table} -`information_schema.tiflash_replica`システム テーブルの列名とその説明は次のとおりです。 +`information_schema.tiflash_replica`システムテーブルの列名とその説明は次のとおりです。 | カラム名 | 説明 | | -------- | ----------------------------------------- | diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index 814faa99789b3..17b95a4d3cbf0 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -38,7 +38,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} - 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`はバッチ要求の数です。`batch_cop`はバッチ要求内のコプロセッサ要求の数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`はすべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`はスーパー バッチ機能を有効にするための要求の数です。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブル スキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブルスキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 - リクエスト期間: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 - エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 - リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 @@ -61,7 +61,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## DDL {#ddl} -- スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 +- スキーマバージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 - スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 - スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 - スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 @@ -103,4 +103,4 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas - 読み取りインデックス OPS: 各TiFlashインスタンスが`read_index`回のリクエストをトリガーする回数。これはトリガーされたリージョンの数に等しくなります。 - インデックス読み取り時間: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 -- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信した後、ローカル インデックス >= read_index になるまで待機する時間です。 +- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信した後、ローカルインデックス >= read_index になるまで待機する時間です。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index 817c185f1cf7b..832884dcfbffa 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -1,11 +1,11 @@ --- title: TiFlash Alert Rules -summary: TiFlashクラスターのアラート ルールについて学習します。 +summary: TiFlashクラスターのアラートルールについて学習します。 --- # TiFlashアラートルール {#tiflash-alert-rules} -このドキュメントでは、 TiFlashクラスターのアラート ルールについて説明します。 +このドキュメントでは、 TiFlashクラスターのアラートルールについて説明します。 ## `TiFlash_schema_error` {#tiflash-schema-error} diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 2353338e9a656..e61e9d69c7188 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -41,7 +41,7 @@ summary: TiFlash の設定方法を学びます。 #### `delta_index_cache_size` {#delta_index_cache_size} -- DeltaIndex のキャッシュ サイズの制限。 +- DeltaIndex のキャッシュサイズの制限。 - デフォルト値: `0` 、制限がないことを意味します。 #### `path` {#path} @@ -78,10 +78,10 @@ summary: TiFlash の設定方法を学びます。 - `6` `4` `7` `5` `2` `3` - `format_version = 2` : バージョン v6.0.0 未満のデフォルトの形式。 - `format_version = 3` : v6.0.0 および v6.1.x のデフォルト形式。より多くのデータ検証機能が提供されます。 - - `format_version = 4` : バージョン v6.2.0 から v7.3.0 までのデフォルトの形式。書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 + - `format_version = 4` : バージョン v6.2.0 から v7.3.0 までのデフォルトの形式。書き込み増幅とバックグラウンドタスクのリソース消費を削減します。 - `format_version = 5` : v7.3.0 で導入され、v7.4.0 から v8.3.0 までのバージョンのデフォルト形式で、小さなファイルを結合することで物理ファイルの数を削減します。 - - `format_version = 6` : v8.4.0 で導入され、ベクトル インデックスの構築とストレージを部分的にサポートします。 - - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトル インデックスの構築とストレージをサポートします。 + - `format_version = 6` : v8.4.0 で導入され、ベクトルインデックスの構築とストレージを部分的にサポートします。 + - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトルインデックスの構築とストレージをサポートします。 #### storage.main {#storagemain} @@ -201,7 +201,7 @@ I/O トラフィック制限設定を構成します。 ##### `dir` {#dir} -- 分散ストレージおよびコンピューティングアーキテクチャ内のコンピューティング ノードのローカル データ キャッシュ ディレクトリ。 +- 分散ストレージおよびコンピューティングアーキテクチャ内のコンピューティングノードのローカルデータ キャッシュ ディレクトリ。 @@ -219,7 +219,7 @@ I/O トラフィック制限設定を構成します。 ##### `compact_log_min_gap` v7.4.0 の新機能 {#compact_log_min_gap-new-in-v740} -- 現在のRaftステート マシンによって進められた`applied_index`と最後のディスク スピル時の`applied_index`との差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 +- 現在のRaftステートマシンによって進められた`applied_index`と最後のディスクスピル時の`applied_index`との差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 - このギャップを大きくすると、 TiFlashのディスク書き込み頻度が低下し、ランダム書き込みシナリオにおける読み取りレイテンシーが短縮される可能性がありますが、メモリオーバーヘッドも増加する可能性があります。このギャップを小さくすると、 TiFlashのディスク書き込み頻度が増加し、 TiFlashのメモリ負荷が軽減される可能性があります。ただし、現段階では、このギャップを`0`に設定しても、 TiFlashのディスク書き込み頻度は TiKV よりも高くなることはありません。 - デフォルト値を維持することをお勧めします。 - デフォルト値: `200` @@ -284,7 +284,7 @@ I/O トラフィック制限設定を構成します。 ##### `config` {#config} -- プロキシの構成ファイル パス。 +- プロキシの構成ファイルパス。 @@ -300,7 +300,7 @@ I/O トラフィック制限設定を構成します。 ##### `level` {#level} -- ログ レベル。 +- ログレベル。 - デフォルト値: `"info"` - `"info"` `"debug"` `"error"` `"warn"` `"trace"` @@ -318,7 +318,7 @@ I/O トラフィック制限設定を構成します。 ##### `size` {#size} -- 1 つのログ ファイルのサイズ。 +- 1 つのログファイルのサイズ。 - デフォルト値: `"100M"` ##### `count` {#count} @@ -399,7 +399,7 @@ I/O トラフィック制限設定を構成します。 ##### `enable_elastic_threadpool`バージョン5.4.0の新機能 {#enable_elastic_threadpool-new-in-v540} -- エラスティック スレッド プール機能を有効にするかどうかを制御します。この機能により、 TiFlashの同時実行性の高いシナリオで CPU 使用率が大幅に向上します。 +- エラスティックスレッドプール機能を有効にするかどうかを制御します。この機能により、 TiFlashの同時実行性の高いシナリオで CPU 使用率が大幅に向上します。 - デフォルト値: `true` ##### `dt_compression_method` {#dt_compression_method} @@ -467,7 +467,7 @@ I/O トラフィック制限設定を構成します。 - デフォルト値: `false` - 値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.2.0 で導入されました。 - 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 -- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 +- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザーデータは`?`に置き換えられます。 - 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 - [`tiflash-learner.toml`](#configure-the-tiflash-learnertoml-file)での tiflash-learner のログインにも`security.redact-info-log`設定する必要があることに注意してください。 @@ -500,7 +500,7 @@ I/O トラフィック制限設定を構成します。 ##### `level` v5.4.0 の新機能 {#level-new-in-v540} -- TiFlash Proxy のログ レベル。 +- TiFlash Proxy のログレベル。 - デフォルト値: `"info"` - `"info"` `"debug"` `"error"` `"warn"` `"trace"` @@ -508,16 +508,16 @@ I/O トラフィック制限設定を構成します。 ##### `max-backups` 5.4.0の新機能 {#max-backups-new-in-v540} -- 保存するログ ファイルの最大数。 -- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログ ファイルを保存します。 +- 保存するログファイルの最大数。 +- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログファイルを保存します。 - このパラメータを0以外の値に設定すると、 TiFlash Proxyは最大で`max-backups`で指定された数の古いログファイルを保持します。例えば、 `7`に設定すると、 TiFlash Proxyは最大で7つの古いログファイルを保持します。 - デフォルト値: `0` ##### `max-days` v5.4.0 の新機能 {#max-days-new-in-v540} -- ログ ファイルが保持される最大日数。 -- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログ ファイルを保持します。 -- このパラメータがゼロ以外の値に設定されている場合、 TiFlash Proxy は`max-days`で指定された日数後に古いログ ファイルをクリーンアップします。 +- ログファイルが保持される最大日数。 +- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログファイルを保持します。 +- このパラメータがゼロ以外の値に設定されている場合、 TiFlash Proxy は`max-days`で指定された日数後に古いログファイルをクリーンアップします。 - デフォルト値: `0` #### ラフトストア {#raftstore} @@ -530,7 +530,7 @@ I/O トラフィック制限設定を構成します。 ##### `store-pool-size` {#store-pool-size} -- Raft を処理するスレッドの許容数。これはRaftstoreスレッド プールのサイズです。 +- Raft を処理するスレッドの許容数。これはRaftstoreスレッドプールのサイズです。 @@ -547,7 +547,7 @@ I/O トラフィック制限設定を構成します。 - デフォルト値: `false` - 値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.3.0 で導入されました。 - 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 -- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 +- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザーデータは`?`に置き換えられます。 - 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 #### セキュリティ.暗号化 {#securityencryption} diff --git a/tiflash/tiflash-data-validation.md b/tiflash/tiflash-data-validation.md index 96901b5736778..1bac9ceeee895 100644 --- a/tiflash/tiflash-data-validation.md +++ b/tiflash/tiflash-data-validation.md @@ -19,8 +19,8 @@ summary: TiFlashのデータ検証メカニズムとツールについて学習 | バージョン | 状態 | 検証メカニズム | 注記 | | :---- | :------------------------ | :-------------------------------------------------------- | :---------------------------- | -| V1 | 非推奨 | ハッシュはデータ ファイルに埋め込まれます。 | | -| V2 | バージョン6.0.0未満のデフォルト | ハッシュはデータ ファイルに埋め込まれます。 | V1 と比較して、V2 では列データの統計が追加されます。 | +| V1 | 非推奨 | ハッシュはデータファイルに埋め込まれます。 | | +| V2 | バージョン6.0.0未満のデフォルト | ハッシュはデータファイルに埋め込まれます。 | V1 と比較して、V2 では列データの統計が追加されます。 | | V3 | バージョン >= v6.0.0 のデフォルト | V3 にはメタデータとトークン データのチェックサムが含まれており、複数のハッシュ アルゴリズムをサポートします。 | v5.4.0 の新機能。 | DTFileはデータファイルディレクトリの`stable`フォルダに保存されます。現在有効な形式はすべてフォルダ形式です。つまり、データは`dmf_`のような名前のフォルダの下に複数のファイルとして保存されます。 diff --git a/tiflash/tiflash-disaggregated-and-s3.md b/tiflash/tiflash-disaggregated-and-s3.md index 833eda0156cfd..c5ea5347d1b18 100644 --- a/tiflash/tiflash-disaggregated-and-s3.md +++ b/tiflash/tiflash-disaggregated-and-s3.md @@ -17,18 +17,18 @@ summary: TiFlash の分散ストレージとコンピューティングアーキ 書き込みノードは、TiKVからRaftログデータを受け取り、列指向形式に変換し、一定期間内に更新されたすべてのデータを定期的にパッケージ化してS3にアップロードします。さらに、書き込みノードは、クエリパフォーマンスを向上させるための継続的なデータ整理や不要なデータの削除など、S3上のデータを管理します。 - 書き込みノードは、メモリの過剰な使用を避けるために、ローカル ディスク (通常は NVMe SSD) を使用して最新の書き込みデータをキャッシュします。 + 書き込みノードは、メモリの過剰な使用を避けるために、ローカルディスク (通常は NVMe SSD) を使用して最新の書き込みデータをキャッシュします。 - TiFlashコンピューティングノード コンピューティングノードは、TiDBノードから送信されたクエリリクエストを実行します。まず、書き込みノードにアクセスしてデータのスナップショットを取得し、次に書き込みノードから最新のデータ（つまり、まだS3にアップロードされていないデータ）を読み取り、残りのデータの大部分をS3から読み取ります。 - コンピューティング ノードは、ローカル ディスク (通常は NVMe SSD) をデータ ファイルのキャッシュとして使用し、リモートの場所 (書き込みノードまたは S3) から同じデータを繰り返し読み取ることを回避して、クエリ パフォーマンスを向上させます。 + コンピューティングノードは、ローカルディスク (通常は NVMe SSD) をデータファイルのキャッシュとして使用し、リモートの場所 (書き込みノードまたは S3) から同じデータを繰り返し読み取ることを回避して、クエリパフォーマンスを向上させます。 コンピューティングノードはステートレスであり、スケーリング速度は2段階レベルです。この機能を利用することで、以下のようにコストを削減できます。 - クエリのワークロードが低い場合は、コンピューティングノードの数を減らしてコストを削減します。クエリがない場合、すべてのコンピューティングノードを停止することもできます。 - - クエリのワークロードが増加した場合は、コンピューティング ノードの数を迅速に増やして、クエリのパフォーマンスを確保します。 + - クエリのワークロードが増加した場合は、コンピューティングノードの数を迅速に増やして、クエリのパフォーマンスを確保します。 ## シナリオ {#scenarios} diff --git a/tiflash/tiflash-late-materialization.md b/tiflash/tiflash-late-materialization.md index de5a8e816706d..56b3b2f7f08f9 100644 --- a/tiflash/tiflash-late-materialization.md +++ b/tiflash/tiflash-late-materialization.md @@ -62,7 +62,7 @@ SHOW GLOBAL VARIABLES LIKE 'tidb_opt_enable_late_materialization'; +--------------------------------------+-------+ ``` -`tidb_opt_enable_late_materialization`変数は、セッション レベルまたはグローバル レベルで変更できます。 +`tidb_opt_enable_late_materialization`変数は、セッションレベルまたはグローバルレベルで変更できます。 - 現在のセッションでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 @@ -70,13 +70,13 @@ SHOW GLOBAL VARIABLES LIKE 'tidb_opt_enable_late_materialization'; SET SESSION tidb_opt_enable_late_materialization=OFF; ``` -- グローバル レベルでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 +- グローバルレベルでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 ```sql SET GLOBAL tidb_opt_enable_late_materialization=OFF; ``` - この設定後、新しいセッションでは、セッション レベルとグローバル レベルの両方で`tidb_opt_enable_late_materialization`変数がデフォルトで有効になります。 + この設定後、新しいセッションでは、セッションレベルとグローバルレベルの両方で`tidb_opt_enable_late_materialization`変数がデフォルトで有効になります。 TiFlash の遅延マテリアライゼーションを有効にするには、次のステートメントを使用します。 diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index a27e973868f3e..7c9b43a1b024a 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -61,7 +61,7 @@ MinTSO スケジューラのスケジューリング プロセスは次のとお ![TiFlash MinTSO Scheduler v2](/media/tiflash/tiflash_mintso_v2.png) -ソフト制限とハード制限を導入することで、MinTSO スケジューラはシステム スレッドの数を制御しながらシステム デッドロックを効果的に回避します。ただし、同時実行性の高いシナリオでは、ほとんどのクエリで MPP タスクの一部のみがスケジュールされている可能性があります。MPP タスクの一部のみがスケジュールされているクエリは正常に実行できず、システム実行効率が低下します。この状況を回避するために、 TiFlash は、active_set_soft_limit と呼ばれる MinTSO スケジューラのクエリ レベルの制限を導入しています。この制限により、active_set_soft_limit クエリまでの MPP タスクのみがスケジューリングに参加できます。その他のクエリの MPP タスクはスケジューリングに参加せず、現在のクエリが終了した後にのみ新しいクエリがスケジューリングに参加できます。MinTSO クエリの場合、システム スレッドの数がハード制限を超えない限り、すべての MPP タスクを直接スケジュールできるため、この制限は単なるソフト制限です。 +ソフト制限とハード制限を導入することで、MinTSO スケジューラはシステム スレッドの数を制御しながらシステム デッドロックを効果的に回避します。ただし、同時実行性の高いシナリオでは、ほとんどのクエリで MPP タスクの一部のみがスケジュールされている可能性があります。MPP タスクの一部のみがスケジュールされているクエリは正常に実行できず、システム実行効率が低下します。この状況を回避するために、 TiFlash は、active_set_soft_limit と呼ばれる MinTSO スケジューラのクエリレベルの制限を導入しています。この制限により、active_set_soft_limit クエリまでの MPP タスクのみがスケジューリングに参加できます。その他のクエリの MPP タスクはスケジューリングに参加せず、現在のクエリが終了した後にのみ新しいクエリがスケジューリングに参加できます。MinTSO クエリの場合、システム スレッドの数がハード制限を超えない限り、すべての MPP タスクを直接スケジュールできるため、この制限は単なるソフト制限です。 ## 参照 {#see-also} diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index 723dcc420903d..7690b6cb90004 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -12,7 +12,7 @@ summary: TiFlashパイプライン実行モデルについて学びましょう - v7.2.0 および v7.3.0 の場合: パイプライン実行モデルは実験的であり、 [`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables/#tidb_enable_tiflash_pipeline_model-new-in-v720)によって制御されます。 - v7.4.0 以降のバージョンの場合: パイプライン実行モデルが一般提供されます。これはTiFlashの内部機能であり、 TiFlashリソース制御と緊密に統合されています。 TiFlashリソース制御を有効にすると、パイプライン実行モデルが自動的に有効になります。 TiFlashリソース制御の使用方法の詳細については、 [リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md#parameters-for-resource-control)を参照してください。さらに、v7.4.0 以降、システム変数`tidb_enable_tiflash_pipeline_model`は非推奨になりました。 -論文[モルセル駆動型並列処理：マルチコア時代に向けたNUMA対応クエリ評価フレームワーク](https://dl.acm.org/doi/10.1145/2588555.2610507)からインスピレーションを得た、 TiFlashパイプライン実行モデルは、従来のスレッド スケジューリング モデルとは異なる、きめの細かいタスク スケジューリング モデルを提供します。これにより、オペレーティング システムのスレッド アプリケーションとスケジューリングのオーバーヘッドが削減され、きめ細かいスケジューリング メカニズムが提供されます。 +論文[モルセル駆動型並列処理：マルチコア時代に向けたNUMA対応クエリ評価フレームワーク](https://dl.acm.org/doi/10.1145/2588555.2610507)からインスピレーションを得た、 TiFlashパイプライン実行モデルは、従来のスレッドスケジューリング モデルとは異なる、きめの細かいタスクスケジューリング モデルを提供します。これにより、オペレーティングシステムのスレッド アプリケーションとスケジューリングのオーバーヘッドが削減され、きめ細かいスケジューリングメカニズムが提供されます。 ## 設計と実装 {#design-and-implementation} diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 8e5403f239723..fead9c9e45b91 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -45,7 +45,7 @@ SELECT app_name, country FROM t1; 多くの BI アプリケーションでは、分析クエリ要求が非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリ要求を処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 -- TiFlashによるオンライン アプリケーションの提供 +- TiFlashによるオンラインアプリケーションの提供 TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。`INSERT INTO SELECT`を指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 diff --git a/tiflash/tiflash-spill-disk.md b/tiflash/tiflash-spill-disk.md index fdb84c57e470e..81778cc29e81f 100644 --- a/tiflash/tiflash-spill-disk.md +++ b/tiflash/tiflash-spill-disk.md @@ -17,8 +17,8 @@ summary: TiFlash がデータをディスクに書き出す方法と、書き出 TiFlash は、データをディスクに書き出すための 2 つのトリガー メカニズムを提供します。 -- オペレータ レベルのスピル: 各オペレータのデータ スピルしきい値を指定することにより、 TiFlash がそのオペレータのデータをディスクにスピルするタイミングを制御できます。 -- クエリ レベルのスピル: TiFlashノードでのクエリの最大メモリ使用量とスピルのメモリ比率を指定することにより、 TiFlash がクエリでサポートされている演算子のデータを必要に応じてディスクにスピルするタイミングを制御できます。 +- オペレータ レベルのスピル: 各オペレータのデータスピルしきい値を指定することにより、 TiFlash がそのオペレータのデータをディスクにスピルするタイミングを制御できます。 +- クエリレベルのスピル: TiFlashノードでのクエリの最大メモリ使用量とスピルのメモリ比率を指定することにより、 TiFlash がクエリでサポートされている演算子のデータを必要に応じてディスクにスピルするタイミングを制御できます。 ### オペレータレベルのスピル {#operator-level-spilling} @@ -89,7 +89,7 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし #### 例 {#example} -この例では、クエリ レベルのスピルを示すために大量のメモリを消費する SQL ステートメントを構築します。 +この例では、クエリレベルのスピルを示すために大量のメモリを消費する SQL ステートメントを構築します。 1. 環境を準備します。2ノードのTiFlashクラスターを作成し、TPCH-100データをインポートします。 @@ -134,7 +134,7 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし HAVING SUM(l_quantity) > 314; ``` -5. TiFlashのログから、クエリ レベルのスピルを構成すると、 TiFlash中間結果のスピルがトリガーされ、クエリで使用されるメモリが大幅に削減されることがわかります。 +5. TiFlashのログから、クエリレベルのスピルを構成すると、 TiFlash中間結果のスピルがトリガーされ、クエリで使用されるメモリが大幅に削減されることがわかります。 ``` [DEBUG] [MemoryTracker.cpp:101] ["Peak memory usage (for query): 3.94 GiB."] [source=MemoryTracker] [thread_id=1547] @@ -146,9 +146,9 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし - 現在、演算子レベルのスピルのしきい値は各演算子ごとに個別に計算されます。2つのハッシュ集計演算子を含むクエリの場合、クエリレベルのスピルが設定されておらず、集計演算子のしきい値が10 GiBに設定されている場合、2つのハッシュ集計演算子は、それぞれのメモリ使用量が10 GiBを超えた場合にのみデータをスピルします。 - 現在、ハッシュ集計演算子とTopN/Sort演算子は、リストアフェーズでマージ集計アルゴリズムとマージソートアルゴリズムを使用しています。そのため、これら2つの演算子はスピルを1ラウンドのみトリガーします。メモリ需要が非常に高く、リストアフェーズ中のメモリ使用量が依然としてしきい値を超えている場合、スピルは再度トリガーされません。 - 現在、ハッシュ結合演算子はパーティションベースのスピル戦略を使用しています。リストアフェーズ中のメモリ使用量が依然としてしきい値を超える場合、スピルは再度トリガーされます。ただし、スピルの規模を制御するため、スピルの回数は3回に制限されています。3回目のスピル後もリストアフェーズ中のメモリ使用量が依然としてしきい値を超える場合、スピルは再度トリガーされません。 -- クエリ レベルのスピルが設定されている場合 (つまり、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)と[`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740)両方が 0 より大きい場合)、 TiFlash は個々の演算子のスピルしきい値を無視し、クエリ レベルのスピルしきい値に基づいてクエリ内の関連する演算子のスピルを自動的にトリガーします。 +- クエリレベルのスピルが設定されている場合 (つまり、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)と[`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740)両方が 0 より大きい場合)、 TiFlash は個々の演算子のスピルしきい値を無視し、クエリレベルのスピルしきい値に基づいてクエリ内の関連する演算子のスピルを自動的にトリガーします。 - クエリレベルのスピルが設定されている場合でも、クエリで使用される演算子がスピルをサポートしていない場合、そのクエリの中間計算結果はディスクにスピルできません。この場合、そのクエリのメモリ使用量が関連するしきい値を超えると、 TiFlashはエラーを返し、クエリを終了します。 -- クエリ レベルのスピルが構成されていて、クエリにスピルをサポートする演算子が含まれている場合でも、次のいずれかのシナリオでメモリしきい値を超えたためにクエリからエラーが返される可能性があります。 +- クエリレベルのスピルが構成されていて、クエリにスピルをサポートする演算子が含まれている場合でも、次のいずれかのシナリオでメモリしきい値を超えたためにクエリからエラーが返される可能性があります。 - クエリ内のその他の非スピル演算子はメモリを大量に消費します。 - スピル演算子は、タイムリーにディスクにスピルしません。 diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 9e54636e768ad..ea59cc41287f4 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -33,7 +33,7 @@ TiFlash は様々な理由により正常に起動しない場合があります 仮想マシンにデプロイするときにこの問題が発生した場合は、VM の CPUアーキテクチャを Haswell に変更してから、 TiFlash を再デプロイしてみてください。 -上記の方法で問題を解決できない場合は、TiFlashログ ファイルを収集し、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 +上記の方法で問題を解決できない場合は、TiFlashログファイルを収集し、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 ## 一部のクエリでは`Region Unavailable`エラーが返されます。 {#some-queries-return-the-region-unavailable-error} @@ -43,7 +43,7 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー ## データファイルの破損 {#data-file-corruption} -データ ファイルの破損を処理するには、次の手順に従います。 +データファイルの破損を処理するには、次の手順に従います。 1. 対応するTiFlashノードを停止するには、 [TiFlashノードをダウンさせる](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 2. TiFlashノードの関連データを削除します。 @@ -214,7 +214,7 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 pd-ctl operator add remove-peer ``` -上記のすべてのチェックに合格しても問題が解決しない場合は、 [データはTiFlashに複製されません](#data-is-not-replicated-to-tiflash)の手順に従って、どのコンポーネントまたはデータ レプリケーション プロセスで問題が発生しているかを特定します。 +上記のすべてのチェックに合格しても問題が解決しない場合は、 [データはTiFlashに複製されません](#data-is-not-replicated-to-tiflash)の手順に従って、どのコンポーネントまたはデータレプリケーションプロセスで問題が発生しているかを特定します。 ## データはTiFlashに複製されません {#data-is-not-replicated-to-tiflash} diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 10e52f71e2b05..f865e0db8ebd1 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -296,7 +296,7 @@ mysql> explain analyze select max(l_shipdate), max(l_commitdate), max(l_receiptd ### 実行同時実行性を高める {#set-a-greater-execution-concurrency} -実行の同時実行性が高まると、 TiFlash はシステムの CPU リソースをより多く占有できるようになり、クエリ パフォーマンスが向上します。 +実行の同時実行性が高まると、 TiFlash はシステムの CPU リソースをより多く占有できるようになり、クエリパフォーマンスが向上します。 変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)は、 TiFlashがリクエストを実行する際の最大同時実行数を設定するために使用されます。単位はスレッドです。 diff --git a/tiflash/use-fastscan.md b/tiflash/use-fastscan.md index 0b3ca4961e5ef..ca88274ca2fa0 100644 --- a/tiflash/use-fastscan.md +++ b/tiflash/use-fastscan.md @@ -90,6 +90,6 @@ TiFlashのストレージレイヤーのデータは、デルタレイヤーと 1. データの読み取り: Deltaレイヤーと Stableレイヤーに個別のデータ ストリームを作成し、それぞれのデータを読み取ります。 2. ソートマージ: 手順 1 で作成したデータ ストリームをマージします。次に、(主キー列、タイムスタンプ列) の順序でソートしたデータを返します。 3. 範囲フィルター: データ範囲に従って、手順 2 で生成されたデータをフィルターし、データを返します。 -4. MVCC +カラムフィルター: 手順 3 で生成されたデータを MVCC (つまり、主キー列とタイムスタンプ列に従ってデータ バージョンをフィルター処理) および列 (つまり、不要な列をフィルター処理) を通じてフィルター処理し、データを返します。 +4. MVCC +カラムフィルター: 手順 3 で生成されたデータを MVCC (つまり、主キー列とタイムスタンプ列に従ってデータバージョンをフィルター処理) および列 (つまり、不要な列をフィルター処理) を通じてフィルター処理し、データを返します。 FastScanは、データの一貫性をある程度犠牲にすることで、クエリ速度を向上させます。通常のスキャンプロセスにおけるステップ2とステップ4のMVCC部分はFastScanでは省略されるため、クエリパフォーマンスが向上します。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 64899a8b9b3f9..38970e45f0131 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -81,7 +81,7 @@ explain analyze select count(*) from test.t; > **Note:** > -> [TiDB Dashboard](/dashboard/dashboard-intro.md)およびその他のコンポーネントは、TiDBメモリテーブル領域に格納されている一部のシステム テーブルを読み取る必要があるため、インスタンス レベルのエンジン構成に常に「tidb」エンジンを追加することをお勧めします。 +> [TiDB Dashboard](/dashboard/dashboard-intro.md)およびその他のコンポーネントは、TiDBメモリテーブル領域に格納されている一部のシステムテーブルを読み取る必要があるため、インスタンスレベルのエンジン構成に常に「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..1cfb52f11e6ec 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -113,9 +113,9 @@ TiFlash は、ブロードキャスト ハッシュ結合を使用するかど - [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50) : 値の単位は行です。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できないため、結果セットの行数によってサイズが決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 - [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) : ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 -## MPP モードでパーティション テーブルにアクセスする {#access-partitioned-tables-in-the-mpp-mode} +## MPP モードでパーティションテーブルにアクセスする {#access-partitioned-tables-in-the-mpp-mode} -MPP モードでパーティション テーブルにアクセスするには、まず[動的剪定モード](https://docs.pingcap.com/tidb/stable/partitioned-table#dynamic-pruning-mode)有効にする必要があります。 +MPP モードでパーティションテーブルにアクセスするには、まず[動的剪定モード](https://docs.pingcap.com/tidb/stable/partitioned-table#dynamic-pruning-mode)有効にする必要があります。 例： diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 731ff4c2fbcfa..5cf1f360088ed 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -7,9 +7,9 @@ summary: TiKVの設定ファイルについて学びましょう。 -TiKV の設定ファイルは、コマンドライン パラメータよりも多くのオプションをサポートしています。デフォルトの設定ファイルは[etc/config-template.toml](https://github.com/tikv/tikv/blob/release-8.5/etc/config-template.toml)にあり、 `config.toml`に名前を変更できます。 +TiKV の設定ファイルは、コマンドラインパラメータよりも多くのオプションをサポートしています。デフォルトの設定ファイルは[etc/config-template.toml](https://github.com/tikv/tikv/blob/release-8.5/etc/config-template.toml)にあり、 `config.toml`に名前を変更できます。 -このドキュメントでは、コマンドライン パラメーターに含まれないパラメーターのみについて説明します。詳しくは[コマンドラインパラメータ](/command-line-flags-for-tikv-configuration.md)をご覧ください。 +このドキュメントでは、コマンドラインパラメーターに含まれないパラメーターのみについて説明します。詳しくは[コマンドラインパラメータ](/command-line-flags-for-tikv-configuration.md)をご覧ください。 > **Tip:** > @@ -100,7 +100,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `max-backups` v5.4.0の新機能 {#max-backups-new-in-v540} - TiKVが保持するログファイルの最大数。 - - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はすべてのログ ファイルを保持します。 + - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はすべてのログファイルを保持します。 - 設定項目が`0`以外の値に設定されている場合、TiKV は`max-backups`で指定された数までの古いログファイルを保持します。たとえば、値が`7`に設定されている場合、TiKV は最大 7 つの古いログファイルを保持します。 - デフォルト値: `0` @@ -151,7 +151,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `grpc-concurrency` {#grpc-concurrency} -- gRPC ワーカー スレッドの数。 gRPC スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- gRPC ワーカースレッドの数。 gRPC スレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: @@ -320,7 +320,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `max-thread-count` {#max-thread-count} -- 統合読み取りプールまたは UnifyReadPool スレッド プールの最大作業スレッド数。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- 統合読み取りプールまたは UnifyReadPool スレッドプールの最大作業スレッド数。このスレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - 値の範囲: `[min-thread-count, MAX(4, CPU quota * 10)]` 。 `MAX(4, CPU quota * 10)`は`4`と`CPU quota * 10`からより大きな値を取得します。 - デフォルト値: MAX(4, CPU * 0.8) @@ -501,7 +501,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `scheduler-worker-pool-size` {#scheduler-worker-pool-size} -- スケジューラのスレッド プール内のスレッドの数。スケジューラ スレッドは主に、データの書き込み前にトランザクションの整合性をチェックするために使用されます。 CPU コアの数が`16`以上の場合、デフォルト値は`8`です。それ以外の場合、デフォルト値は`4`です。スケジューラ スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- スケジューラのスレッドプール内のスレッドの数。スケジューラ スレッドは主に、データの書き込み前にトランザクションの整合性をチェックするために使用されます。 CPU コアの数が`16`以上の場合、デフォルト値は`8`です。それ以外の場合、デフォルト値は`4`です。スケジューラスレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: `4` - 値の範囲: `[1, MAX(4, CPU)]` 。 `MAX(4, CPU)`では、 `CPU`は CPU コアの数を意味します。 `MAX(4, CPU)`は`4`と`CPU`のうち大きい方の値を取得します。 @@ -983,7 +983,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `snap-generator-pool-size` v5.4.0の新機能 {#snap-generator-pool-size-new-in-v540} - `snap-generator`スレッドプールのサイズを設定します。 -- TiKV のリカバリシナリオでリージョンがスナップショットをより高速に生成できるようにするには、対応するワーカーの`snap-generator`スレッドの数を増やす必要があります。この構成項目を使用して、 `snap-generator`スレッド プールのサイズを増やすことができます。 +- TiKV のリカバリシナリオでリージョンがスナップショットをより高速に生成できるようにするには、対応するワーカーの`snap-generator`スレッドの数を増やす必要があります。この構成項目を使用して、 `snap-generator`スレッドプールのサイズを増やすことができます。 - デフォルト値: `2` - 最小値: `1` @@ -1121,7 +1121,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### `apply-pool-size` {#apply-pool-size} -- データをディスクにフラッシュするプール内のスレッドの許容数。これは、適用スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- データをディスクにフラッシュするプール内のスレッドの許容数。これは、適用スレッドプールのサイズです。このスレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: `2` - 値の範囲: `[1, CPU * 10]` 。 `CPU`はCPU コアの数を表します。 @@ -1134,13 +1134,13 @@ Raftstoreに関連するコンフィグレーション項目。 ### `store-pool-size` {#store-pool-size} -- Raftを処理するプール内のスレッドの許容数。これはRaftstoreスレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- Raftを処理するプール内のスレッドの許容数。これはRaftstoreスレッドプールのサイズです。このスレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: `2` - 値の範囲: `[1, CPU * 10]` 。 `CPU`はCPU コアの数を表します。 ### `store-io-pool-size` v5.3.0で追加 {#store-io-pool-size-new-in-v530} -- Raft I/O タスクを処理するスレッドの許容数。これは StoreWriter スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- Raft I/O タスクを処理するスレッドの許容数。これは StoreWriter スレッドプールのサイズです。このスレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: `1` (v8.0.0 より前のバージョンでは、デフォルト値は`0`でした) - 最小値: `0` @@ -1305,7 +1305,7 @@ RocksDBに関連するコンフィグレーション項目 ### `max-background-jobs` {#max-background-jobs-1} -- RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- RocksDB のバックグラウンドスレッドの数。 RocksDB スレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: - CPUコア数が10の場合、デフォルト値は`9`です。 - CPUコア数が8の場合、デフォルト値は`7`です。 @@ -1950,7 +1950,7 @@ Titanに関連するコンフィグレーション項目。 ### `max-background-jobs` {#max-background-jobs} -- RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- RocksDB のバックグラウンドスレッドの数。 RocksDB スレッドプールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 - デフォルト値: `4` - 最小値: `2` @@ -2194,7 +2194,7 @@ Raft Engineに関連するコンフィグレーション項目。 > 2. `format-version`を`1`に設定します。 > 3. `enable`を`true`に設定してRaft Engineを有効にし、TiKV を再起動して設定を有効にしてください。 -- Raft Engineのログ ファイルのバージョンを指定します。 +- Raft Engineのログファイルのバージョンを指定します。 - 値のオプション： - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 @@ -2287,7 +2287,7 @@ Raft Engineに関連するコンフィグレーション項目。 ### `previous-master-key` {#previous-master-key} -- 新しいマスター キーをローテーションするときに古いマスター キーを指定します。構成形式は`master-key`と同じです。マスターキーの設定方法については、[保存時の暗号化- 暗号化の設定](/encryption-at-rest.md#configure-encryption)を参照してください。 +- 新しいマスターキーをローテーションするときに古いマスターキーを指定します。構成形式は`master-key`と同じです。マスターキーの設定方法については、[保存時の暗号化- 暗号化の設定](/encryption-at-rest.md#configure-encryption)を参照してください。 ## インポート {#import} @@ -2409,7 +2409,7 @@ BRバックアップに関連するコンフィグレーション項目。 ### `num-threads` {#num-threads} -- バックアップを処理するワーカー スレッドの数 +- バックアップを処理するワーカースレッドの数 - デフォルト値: `MIN(CPU * 0.5, 8)` - 値の範囲: `[1, CPU]` - 最小値: `1` @@ -2422,7 +2422,7 @@ BRバックアップに関連するコンフィグレーション項目。 ### `sst-max-size` {#sst-max-size} - バックアップSSTファイルのサイズのしきい値。TiKVリージョン内のバックアップファイルのサイズがこのしきい値を超えると、TiKVリージョンが複数のリージョン範囲に分割され、ファイルは複数のファイルにバックアップされます。分割されたリージョン内の各ファイルは、 `sst-max-size`と同じサイズ（またはわずかに大きいサイズ）です。 -- 例えば、 `[a,e)`リージョンのバックアップ ファイルのサイズが`sst-max-size`より大きい場合、そのファイルは { `[a,b)` 、 `[b,c)`および`[c,d)` `[d,e)` } の領域を持つ複数のファイルにバックアップされ、 `[a,b)` 、 `[b,c)` 、 `[c,d)`のサイズは`sst-max-size`と同じ (またはわずかに大きい) です。 +- 例えば、 `[a,e)`リージョンのバックアップファイルのサイズが`sst-max-size`より大きい場合、そのファイルは { `[a,b)` 、 `[b,c)`および`[c,d)` `[d,e)` } の領域を持つ複数のファイルにバックアップされ、 `[a,b)` 、 `[b,c)` 、 `[c,d)`のサイズは`sst-max-size`と同じ (またはわずかに大きい) です。 - デフォルト値: `"384MiB"` 。v8.4.0 より前のバージョンでは、デフォルト値は`"144MiB"`です。 ### `enable-auto-tune` v5.4.0の新機能 {#enable-auto-tune-new-in-v540} @@ -2437,7 +2437,7 @@ BRバックアップに関連するコンフィグレーション項目。 > この設定項目は、S3 レート制限によって引き起こされるバックアップの失敗に対処するために導入されました。TiDB v6.1.1 以降では、この値の設定には注意してください。大きく設定しすぎると、ネットワークが不安定な場合に大きなアップロードパートが失敗したりタイムアウトしたりする可能性があります。 - バックアップ時にS3へのマルチパートアップロードを実行する際に使用されるパートサイズです。この設定値を調整することで、S3に送信されるリクエスト数を制御できます。 -- データが S3 にバックアップされ、バックアップ ファイルがこの設定項目の値より大きい場合、 [マルチパートアップロード](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html)が自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップ ファイルは約 10 MiB ～ 30 MiB になります。 +- データが S3 にバックアップされ、バックアップファイルがこの設定項目の値より大きい場合、 [マルチパートアップロード](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html)が自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップファイルは約 10 MiB ～ 30 MiB になります。 - デフォルト値: 5MiB ### `gcp-v2-enable` New in v8.5.7 {#gcp-v2-enable-new-in-v857-1} @@ -2708,9 +2708,8 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### `renew-batch-min-size` {#renew-batch-min-size} - タイムスタンプ要求におけるTSOの最小数。 -- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュ サイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 -- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチ サイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカル キャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 -- デフォルト値: `100` +- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュサイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 +- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチサイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカルキャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。- デフォルト値: `100` ### `renew-batch-max-size` v6.4.0で追加 {#renew-batch-max-size-new-in-v640} @@ -2742,8 +2741,8 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ ### `enabled` （v6.6.0で新規追加） {#enabled-new-in-v660} -- 対応するリソース グループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)に従って、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうかを制御します。 TiDB リソース グループとリソース制御の詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 -- この設定項目を有効にするには、TiDB で[`tidb_enable_resource_control](/system-variables.md#tidb_enable_resource_control-new-in-v660)が有効になっている必要があります。この設定項目が有効になっている場合、TiKV は優先度キューを使用して、フォアグラウンド ユーザーからのキューに登録された読み取り/書き込みリクエストをスケジュールします。リクエストのスケジュール優先度は、そのリクエストを受け取るリソース グループが既に消費しているリソースの量に反比例し、対応するリソース グループのクォータに比例します。 +- 対応するリソースグループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)に従って、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうかを制御します。 TiDB リソースグループとリソース制御の詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 +- この設定項目を有効にするには、TiDB で[`tidb_enable_resource_control](/system-variables.md#tidb_enable_resource_control-new-in-v660)が有効になっている必要があります。この設定項目が有効になっている場合、TiKV は優先度キューを使用して、フォアグラウンド ユーザーからのキューに登録された読み取り/書き込みリクエストをスケジュールします。リクエストのスケジュール優先度は、そのリクエストを受け取るリソースグループが既に消費しているリソースの量に反比例し、対応するリソースグループのクォータに比例します。 - デフォルト値: `true` 。これは、リソースグループのRUに基づいたスケジューリングが有効になっていることを意味します。 ### `priority-ctl-strategy` v8.4.0で追加 {#priority-ctl-strategy-new-in-v840} @@ -2753,7 +2752,7 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ - 値のオプション： - `aggressive` : このポリシーは優先度の高いタスクのパフォーマンスを優先し、優先度の高いタスクのスループットとレイテンシーにはほとんど影響を与えないようにしますが、優先度の低いタスクの実行速度は低下します。 - `moderate` : このポリシーは、優先度の低いタスクに対してバランスの取れたフロー制御を課し、優先度の高いタスクへの影響を少なくします。 - - `conservative` : このポリシーは、システム リソースが最大限に活用されることを優先し、優先度の低いタスクが必要に応じてシステムで利用可能なリソースを最大限に活用できるようにするため、優先度の高いタスクのパフォーマンスに大きな影響を与えます。 + - `conservative` : このポリシーは、システムリソースが最大限に活用されることを優先し、優先度の低いタスクが必要に応じてシステムで利用可能なリソースを最大限に活用できるようにするため、優先度の高いタスクのパフォーマンスに大きな影響を与えます。 - デフォルト値: `moderate` 。 ### `bg-cpu-throttle-threshold` New in v8.5.7 {#bg-cpu-throttle-threshold-new-in-v857} @@ -2873,7 +2872,7 @@ TiKV MVCC インメモリエンジン (IME) のストレージレイヤーに関 > > この設定項目は設定ファイルで設定できますが、SQL文で照会することはできません。 -- インメモリ エンジンを有効にしてマルチバージョン クエリを高速化するかどうか。インメモリ エンジンの詳細については、 [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)を参照してください。 +- インメモリエンジンを有効にしてマルチバージョン クエリを高速化するかどうか。インメモリエンジンの詳細については、 [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)を参照してください。 - デフォルト値: `false` (インメモリエンジンは無効になっています) - TiKVノードには最低でも8GiBのメモリを搭載することを推奨します。最適なパフォーマンスを得るには、32GiB以上を搭載することをお勧めします。 - TiKVノードで使用可能なメモリが不足している場合、この設定項目が`true`に設定されていても、インメモリエンジンは有効になりません。このような場合は、TiKVログファイルで`"in-memory engine is disabled because"`を含むメッセージを確認し、インメモリエンジンが有効にならない理由を調べてください。 diff --git a/tikv-control.md b/tikv-control.md index a4d799da6fb61..d45c6ba710466 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -3,7 +3,7 @@ title: TiKV Control User Guide summary: TiKV Controlを使用して TiKV クラスターを管理します。 --- -# TiKV Controlユーザー ガイド {#tikv-control-user-guide} +# TiKV Controlユーザーガイド {#tikv-control-user-guide} TiKV Control ( `tikv-ctl` ) は、クラスターの管理に使用される TiKV のコマンドラインツールです。インストールディレクトリは次のとおりです。 @@ -105,12 +105,12 @@ tiup ctl:v tikv - ローカルモード: - - ローカル TiKV データ ディレクトリ パスを指定するには、 `--data-dir`オプションを使用します。 - - ローカル TiKV 構成ファイル パスを指定するには、 `--config`オプションを使用します。 + - ローカル TiKV データディレクトリ パスを指定するには、 `--data-dir`オプションを使用します。 + - ローカル TiKV 構成ファイルパスを指定するには、 `--config`オプションを使用します。 このモードでは、実行中の TiKV インスタンスを停止する必要があります。 -特に明記されていない限り、すべてのコマンドはリモート モードとローカル モードの両方をサポートします。 +特に明記されていない限り、すべてのコマンドはリモートモードとローカルモードの両方をサポートします。 さらに、 `tikv-ctl`は`--to-hex`と`--to-escaped` 2 つの簡単なコマンドがあり、これらを使用してキーの形式に簡単な変更を加えます。 @@ -294,13 +294,13 @@ tikv-ctl --host localhost:20160 region-properties -r 2 - `skip` 、TiKV が圧縮を実行するときに最下部のファイルが除外されることを意味します。 - `force` 、TiKV が圧縮を実行するときに、最下層のファイルが常に含まれることを意味します。 -- ローカル モードでデータを圧縮するには、次のコマンドを使用します。 +- ローカルモードでデータを圧縮するには、次のコマンドを使用します。 ```shell tikv-ctl --data-dir /path/to/tikv compact -d kv ``` -- リモート モードでデータを圧縮するには、次のコマンドを使用します。 +- リモートモードでデータを圧縮するには、次のコマンドを使用します。 ```shell tikv-ctl --host ip:port compact -d kv @@ -315,7 +315,7 @@ tikv-ctl --host localhost:20160 region-properties -r 2 ### リージョンをtombstoneに設定する {#set-a-region-to-tombstone} -`tombstone`コマンドは通常、 Raftステート マシンに書き込まれたデータの一部が電源オフによって失われた場合に使用されます。 +`tombstone`コマンドは通常、 Raftステートマシンに書き込まれたデータの一部が電源オフによって失われた場合に使用されます。 TiKVインスタンスでは、このコマンドを使用して一部のリージョンのステータスをtombstoneに設定できます。その後、インスタンスを再起動すると、これらのリージョンはスキップされます。これにより、これらのリージョンのRaftステートマシンの破損による再起動の失敗を回避できます。これらのリージョンは、 Raftメカニズムを介して読み取りと書き込みを継続するために、他のTiKVインスタンスに十分な数の正常なレプリカを持っている必要があります。 @@ -343,7 +343,7 @@ tikv-ctl --data-dir /path/to/tikv tombstone -p 127.0.0.1:2379 -r , **Note:** > -> - `tombstone`コマンドはローカル モードのみをサポートします。 +> - `tombstone`コマンドはローカルモードのみをサポートします。 > - `-p`オプションの引数は、 `http`プレフィックスのない PD エンドポイントを指定します。PD エンドポイントを指定するのは、PD が安全に Tombstone に切り替えられるかどうかを照会するためです。 ### TiKVに`consistency-check`リクエストを送信する {#send-a-consistency-check-request-to-tikv} @@ -360,12 +360,12 @@ DebugClient::check_region_consistency: RpcFailure(RpcStatus { status: Unknown, d > **Note:** > > - `consistency-check`コマンドは TiDB のガベージコレクションと互換性がなく、誤ってエラーを報告する可能性があるため、使用はお勧めし**ません**。 -> - このコマンドはリモート モードのみをサポートします。 +> - このコマンドはリモートモードのみをサポートします。 > - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックを要求するプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 ### スナップショットのメタをダンプ {#dump-snapshot-meta} -このサブコマンドは、指定されたパスにあるスナップショット メタ ファイルを解析し、結果を印刷するために使用されます。 +このサブコマンドは、指定されたパスにあるスナップショット メタファイルを解析し、結果を印刷するために使用されます。 ### Raftステートマシンが破損したリージョンを印刷する {#print-the-regions-where-the-raft-state-machine-corrupts} @@ -491,7 +491,7 @@ success! `ldb`コマンドラインツールは、複数のデータアクセスおよびデータベース管理コマンドを提供します。以下にいくつかの例を示します。詳細については、 `tikv-ctl ldb`実行時に表示されるヘルプメッセージを参照するか、RocksDB のドキュメントをご確認ください。 -データ アクセス シーケンスの例: +データアクセス シーケンスの例: 既存の RocksDB を HEX でダンプするには: @@ -598,7 +598,7 @@ tikv-ctl --data-dir bad-ssts --pd 上記の出力から、破損した SST ファイルの情報が最初に印刷され、次にメタ情報が印刷されていることがわかります。 -- `sst meta`部分で、 `14` SST ファイル番号、 `552997`ファイル サイズを意味し、その後に最小および最大のシーケンス番号とその他のメタ情報が続きます。 +- `sst meta`部分で、 `14` SST ファイル番号、 `552997`ファイルサイズを意味し、その後に最小および最大のシーケンス番号とその他のメタ情報が続きます。 - `overlap region`部分は、関係するリージョンの情報を示しています。この情報はPDサーバーから取得されます。 - パート`suggested operations` 、破損したSSTファイルをクリーンアップするための提案が示されています。この提案に従ってファイルをクリーンアップし、TiKVインスタンスを再起動してください。 diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 16bda249b1db5..2006c36863d6f 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -5,7 +5,7 @@ summary: インメモリエンジンの適用シナリオと動作原理、お # TiKV MVCC インメモリエンジン {#tikv-mvcc-in-memory-engine} -TiKV MVCC インメモリ エンジン (IME) は、主に多数の MVCC 履歴バージョンをスキャンする必要があるクエリを高速化するために使用されます。つまり、 [スキャンされたバージョンの総数（ `total_keys` ）は、処理されたバージョン数（ `processed_keys` ）よりもはるかに多い](/analyze-slow-queries.md#obsolete-mvcc-versions-and-excessive-keys) 。 +TiKV MVCC インメモリエンジン (IME) は、主に多数の MVCC 履歴バージョンをスキャンする必要があるクエリを高速化するために使用されます。つまり、 [スキャンされたバージョンの総数（ `total_keys` ）は、処理されたバージョン数（ `processed_keys` ）よりもはるかに多い](/analyze-slow-queries.md#obsolete-mvcc-versions-and-excessive-keys) 。 TiKV MVCCインメモリエンジンは、以下のシナリオに適しています。 diff --git a/tikv-overview.md b/tikv-overview.md index 250261c76ebe7..275009a16b76d 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -23,7 +23,7 @@ TiKV は、Google Spanner の設計に基づいて、マルチ raft グループ TiKVは、クラスター内の各リージョンの適切なサイズを維持しようとします。リージョンのサイズは現在、デフォルトで256MiBです。このメカニズムは、PDコンポーネントがTiKVクラスター内のノード間でリージョンのバランスをとるのに役立ちます。リージョンのサイズがしきい値（デフォルトでは384MiB）を超えると、TiKVはそれを2つ以上のリージョンに分割します。リージョンのサイズがしきい値（デフォルトでは54MiB）より小さい場合、TiKVは隣接する2つの小さなリージョンを1つのリージョンに結合します。 -PD がレプリカをある TiKV ノードから別の TiKV ノードに移動する場合、まずターゲット ノードにLearnerレプリカを追加し、 LearnerレプリカのデータがLeaderレプリカのデータとほぼ同じになったら、PD はそれをFollowerレプリカに変更し、ソース ノードのFollowerレプリカを削除します。 +PD がレプリカをある TiKV ノードから別の TiKV ノードに移動する場合、まずターゲットノードにLearnerレプリカを追加し、 LearnerレプリカのデータがLeaderレプリカのデータとほぼ同じになったら、PD はそれをFollowerレプリカに変更し、ソース ノードのFollowerレプリカを削除します。 Leaderレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、LearnerレプリカがFollowerレプリカになった後、「Leader移行」処理が実行され、Followerレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いLeaderレプリカを削除します。 diff --git a/time-to-live.md b/time-to-live.md index 7f9ff6b4bb72b..1384fe48230eb 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -138,7 +138,7 @@ ALTER TABLE orders TTL_JOB_INTERVAL = '24h'; TTLジョブを実行する際、TiDBはテーブルを最大64個のタスクに分割します。リージョンを最小単位とします。これらのタスクは分散して実行されます。システム変数[`tidb_ttl_running_tasks`](/system-variables.md#tidb_ttl_running_tasks-new-in-v700)を設定することで、クラスター全体で同時実行可能なTTLタスクの数を制限できます。ただし、すべての種類のテーブルのすべてのTTLジョブをタスクに分割できるわけではありません。どの種類のテーブルのTTLジョブをタスクに分割できないかの詳細については、セクション[制限事項](#limitations)を参照してください。 -TTL ジョブの実行を無効にするには、 `TTL_ENABLE='OFF'`テーブル オプションを設定することに加えて、 [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650)グローバル変数を設定してクラスター全体で TTL ジョブの実行を無効にすることもできます。 +TTL ジョブの実行を無効にするには、 `TTL_ENABLE='OFF'`テーブルオプションを設定することに加えて、 [`tidb_ttl_job_enable`](/system-variables.md#tidb_ttl_job_enable-new-in-v650)グローバル変数を設定してクラスター全体で TTL ジョブの実行を無効にすることもできます。 ```sql SET @@global.tidb_ttl_job_enable = OFF; @@ -273,7 +273,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`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: diff --git a/tiproxy/tiproxy-api.md b/tiproxy/tiproxy-api.md index b1ec5de152fef..144af6d163042 100644 --- a/tiproxy/tiproxy-api.md +++ b/tiproxy/tiproxy-api.md @@ -1,11 +1,11 @@ --- title: TiProxy API -summary: TiProxy API を使用して構成、ヘルス ステータス、監視データにアクセスする方法を学習します。 +summary: TiProxy API を使用して構成、ヘルスステータス、監視データにアクセスする方法を学習します。 --- # TiProxy API {#tiproxy-api} -[TiProxy](/tiproxy/tiproxy-overview.md) 、構成、ヘルス ステータス、および監視データにアクセスするための API エンドポイントを提供します。 +[TiProxy](/tiproxy/tiproxy-overview.md) 、構成、ヘルスステータス、および監視データにアクセスするための API エンドポイントを提供します。 > **Note:** > @@ -131,4 +131,4 @@ curl http://127.0.0.1:3080/metrics/ [`server-http-tls`](/tiproxy/tiproxy-configuration.md#server-http-tls)でTLSを有効にし、 [安全](/tiproxy/tiproxy-configuration.md#security)セクションの`server-http-tls`サブセクションにある`cert-allowed-cn`オプションを設定することで、TiProxy APIへのアクセスを制限できます。TiProxyはクライアント証明書の共通名（CN）を[コンポーネント呼び出し元のIDを確認する](/enable-tls-between-components.md#verify-component-callers-identity)に使用します。 -TLS が有効になっていない場合は、代わりにファイアウォール ルールを使用してアクセスを制御できます。 +TLS が有効になっていない場合は、代わりにファイアウォールルールを使用してアクセスを制御できます。 diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index c52f3cfac3f73..5b7ffedbe1b01 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -54,7 +54,7 @@ ls `tiup --binary tiproxy`ctl コンパイル環境要件: [Go](https://golang.org/) 1.21以降 -コンパイル手順: [TiProxyプロジェクト](https://github.com/pingcap/tiproxy)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tiproxyctl`を生成します。 +コンパイル手順: [TiProxyプロジェクト](https://github.com/pingcap/tiproxy)のルートディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tiproxyctl`を生成します。 ```shell git clone https://github.com/pingcap/tiproxy.git @@ -101,7 +101,7 @@ tiproxyctl --host 127.0.0.1 --port 3080 config get #### `--log_level` {#log-level} -- tiproxyctl のログ レベルを指定します。 +- tiproxyctl のログレベルを指定します。 - タイプ: `string` - デフォルト: `"warn"` - `debug` `info` `error`でき`panic` `warn` @@ -163,7 +163,7 @@ level = 'warning' オプション: -- `--output` : (必須) トラフィック ファイルを保存するディレクトリを指定します。 +- `--output` : (必須) トラフィックファイルを保存するディレクトリを指定します。 - `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`を指定すると 1 時間のトラフィックがキャプチャされます。 例： @@ -180,14 +180,14 @@ tiproxyctl traffic capture --host 10.0.1.10 --port 3080 --output="/tmp/traffic" オプション: -- `--username` : (必須) 再生用のデータベース ユーザー名を指定します。 +- `--username` : (必須) 再生用のデータベースユーザー名を指定します。 - `--password` : (オプション) ユーザー名のパスワードを指定します。デフォルト値は空の文字列`""`です。 -- `--input` : (必須) トラフィック ファイルを含むディレクトリを指定します。 +- `--input` : (必須) トラフィックファイルを含むディレクトリを指定します。 - `--speed` : (オプション) 再生速度の乗数を指定します。範囲は`[0.1, 10]`です。デフォルト値は`1`で、元の速度で再生されます。 例： -次のコマンドは、ユーザー名`u1`とパスワード`123456`を使用して`10.0.1.10:3080`の TiProxy インスタンスに接続し、TiProxy インスタンスの`/tmp/traffic`ディレクトリからトラフィック ファイルを読み取り、元の速度の 2 倍でトラフィックを再生します。 +次のコマンドは、ユーザー名`u1`とパスワード`123456`を使用して`10.0.1.10:3080`の TiProxy インスタンスに接続し、TiProxy インスタンスの`/tmp/traffic`ディレクトリからトラフィックファイルを読み取り、元の速度の 2 倍でトラフィックを再生します。 ```shell tiproxyctl traffic replay --host 10.0.1.10 --port 3080 --username="u1" --password="123456" --input="/tmp/traffic" --speed=2 diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index bc2bdad048f40..7143a5249e4b6 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -151,7 +151,7 @@ TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートさ > **Note:** > -> - 仮想 IP は Linux オペレーティング システムでのみサポートされます。 +> - 仮想 IP は Linux オペレーティングシステムでのみサポートされます。 > - TiProxy を実行する Linux ユーザーには、IP アドレスをバインドする権限が必要です。 > - 1 つの TiProxy インスタンスの実際の IP アドレスと仮想 IP アドレスは、同じ CIDR 範囲内にある必要があります。 diff --git a/tiproxy/tiproxy-deployment-topology.md b/tiproxy/tiproxy-deployment-topology.md index d8776f4165f7f..02ad44aa2d121 100644 --- a/tiproxy/tiproxy-deployment-topology.md +++ b/tiproxy/tiproxy-deployment-topology.md @@ -33,14 +33,14 @@ TiProxy は TiDB の L7 プロキシサーバーであり、接続のバラン TiProxy のテンプレートの詳細については、 [TiProxyトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)を参照してください。 -前述の TiDB クラスタ トポロジ ファイル内の構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 +前述の TiDB クラスタトポロジファイル内の構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} -- `tiproxy_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 +- `tiproxy_servers`のインスタンスレベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 - TiProxyパラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)を参照してください。 > **Note:** > > - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - デプロイメントディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 163f57e675598..cc42c9b7e9263 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -21,7 +21,7 @@ TiProxy v1.0.0 は、TiDB サーバーに対してステータスベースおよ ## ステータスベースの負荷分散 {#status-based-load-balancing} -TiProxy は、SQL ポートとステータス ポートを使用して、TiDBサーバーがオフラインになっているか、シャットダウンしているかどうかを定期的に確認します。 +TiProxy は、SQL ポートとステータスポートを使用して、TiDBサーバーがオフラインになっているか、シャットダウンしているかどうかを定期的に確認します。 ## ラベルベースの負荷分散 {#label-based-load-balancing} @@ -127,7 +127,7 @@ TiProxyはTiDBサーバーのCPU使用率を照会し、CPU使用率の高いTiD このポリシーは、次のシナリオに適しています。 -- バックグラウンド タスク ( `ANALYZE`など) が大量の CPU リソースを消費すると、これらのタスクを実行する TiDB サーバーの CPU 使用率が高くなります。 +- バックグラウンドタスク ( `ANALYZE`など) が大量の CPU リソースを消費すると、これらのタスクを実行する TiDB サーバーの CPU 使用率が高くなります。 - 異なる接続でのワークロードが大きく異なる場合、各 TiDBサーバーの接続数が似ていても、CPU 使用率が大幅に異なる可能性があります。 - クラスター内の TiDB サーバーの CPU リソース構成が異なる場合、接続数が均衡していても、実際の CPU 使用率は不均衡になる可能性があります。 @@ -137,8 +137,8 @@ TiProxy は、TiProxy サーバーと TiDB サーバーの場所に基づいて このポリシーは、次のシナリオに適しています。 -- TiDB クラスターがクラウド内のアベイラビリティ ゾーン全体に展開されている場合、TiProxy と TiDB サーバー間のアベイラビリティ ゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティ ゾーン内の TiDB サーバーへのルーティング要求を優先します。 -- TiDB クラスターがデータ センター全体に展開されている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータ センター内の TiDB サーバーへのルーティング要求を優先します。 +- TiDB クラスターがクラウド内のアベイラビリティゾーン全体に展開されている場合、TiProxy と TiDB サーバー間のアベイラビリティゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティゾーン内の TiDB サーバーへのルーティング要求を優先します。 +- TiDB クラスターがデータセンター全体に展開されている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータセンター内の TiDB サーバーへのルーティング要求を優先します。 デフォルトでは、このポリシーの優先度は、ヘルスベース、メモリベース、CPUベースの負荷分散ポリシーよりも低くなっています。優先度を[`policy`](/tiproxy/tiproxy-configuration.md#policy)から`location`に設定することで、優先度を上げることができます。可用性とパフォーマンスを維持するには、少なくとも3台のTiDBサーバーを同じ場所に配置することを推奨します。 diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index 3c6bb1d433549..3b15fb3c95913 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -17,14 +17,14 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア トラフィック リプレイは、次のシナリオに適しています。 -- **TiDB バージョンのアップグレードを確認する**: 新しい TiDB バージョンを使用してテスト クラスターで本番トラフィックを再生し、新しい TiDB バージョンがすべての SQL ステートメントを正常に実行できることを確認します。 +- **TiDB バージョンのアップグレードを確認する**: 新しい TiDB バージョンを使用してテストクラスターで本番トラフィックを再生し、新しい TiDB バージョンがすべての SQL ステートメントを正常に実行できることを確認します。 - **変更の影響を評価する**：テストクラスター上で本番のトラフィックをシミュレートし、クラスターへの変更の影響を検証します。例えば、構成項目やシステム変数の変更、テーブルスキーマの変更、TiDBの新機能の有効化などを行う前に、その影響を検証します。 - **TiDBのスケーリング前にパフォーマンスを検証**：新しいスケールのテストクラスターで対応する速度でトラフィックを再生し、パフォーマンスが要件を満たしているかどうかを検証します。例えば、コスト削減のためにクラスターを50%縮小する計画を立てる場合、トラフィックを半分の速度で再生し、スケーリング後のSQLレイテンシーが要件を満たしているかどうかを検証します。 -- **パフォーマンス制限のテスト**: 同じ規模のテスト クラスターでトラフィックを複数回再生し、再生レートを毎回上げてその規模のスループット制限をテストし、パフォーマンスが将来のビジネス成長のニーズを満たすかどうかを評価します。 +- **パフォーマンス制限のテスト**: 同じ規模のテストクラスターでトラフィックを複数回再生し、再生レートを毎回上げてその規模のスループット制限をテストし、パフォーマンスが将来のビジネス成長のニーズを満たすかどうかを評価します。 トラフィック再生は、次のシナリオには適していません。 -- TiDB と MySQL 間の SQL 互換性を確認します。TiProxy は生成したトラフィック ファイルの読み取りのみをサポートしており、MySQL からのトラフィックをキャプチャして TiDB で再生することはできません。 +- TiDB と MySQL 間の SQL 互換性を確認します。TiProxy は生成したトラフィックファイルの読み取りのみをサポートしており、MySQL からのトラフィックをキャプチャして TiDB で再生することはできません。 - TiDB バージョン間で SQL 実行結果を比較します。TiProxy は、SQL ステートメントが正常に実行されたかどうかのみを確認し、結果を比較しません。 ## 使用法 {#usage} @@ -34,7 +34,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア 1. テストクラスタを作成します。詳細については、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 2. `tiproxyctl`インストールし、 `tiproxyctl`インストールされているホストが本番とテスト環境の両方の TiProxy インスタンスに接続できることを確認します。詳細については、 [TiProxyコントロールをインストールする](/tiproxy/tiproxy-command-line-flags.md#install-tiproxy-control)を参照してください。 3. 本番クラスタからテスト環境クラスタにデータを複製します。詳細については、 [データ移行の概要](/migration-overview.md)を参照してください。 - 4. テスト クラスターで[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)ステートメントを実行して統計を更新します。 + 4. テストクラスターで[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)ステートメントを実行して統計を更新します。 2. [`tiproxyctl traffic capture`](/tiproxy/tiproxy-command-line-flags.md#traffic-capture)コマンドを使用して、本番クラスターの TiProxy インスタンスに接続し、トラフィックのキャプチャを開始します。 @@ -61,13 +61,13 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア 詳細については[`tiproxyctl traffic capture`](/tiproxy/tiproxy-command-line-flags.md#traffic-capture)を参照してください。 -3. トラフィック ファイル ディレクトリをテスト クラスターの TiProxy インスタンスにコピーします。 +3. トラフィックファイル ディレクトリをテストクラスターの TiProxy インスタンスにコピーします。 -4. [`tiproxyctl traffic replay`](/tiproxy/tiproxy-command-line-flags.md#traffic-replay)を使用してテスト クラスターの TiProxy インスタンスに接続し、トラフィックの再生を開始します。 +4. [`tiproxyctl traffic replay`](/tiproxy/tiproxy-command-line-flags.md#traffic-replay)を使用してテストクラスターの TiProxy インスタンスに接続し、トラフィックの再生を開始します。 デフォルトでは、SQL ステートメントは本番クラスターと同じ速度で実行され、各データベース接続は本番クラスター内の接続に対応して、本番負荷をシミュレートし、一貫したトランザクション実行順序を確保します。 - たとえば、次のコマンドは、ユーザー名`u1`とパスワード`123456`を使用して`10.0.1.10:3080`の TiProxy インスタンスに接続し、TiProxy インスタンスの`/tmp/traffic`ディレクトリからトラフィック ファイルを読み取り、トラフィックを再生します。 + たとえば、次のコマンドは、ユーザー名`u1`とパスワード`123456`を使用して`10.0.1.10:3080`の TiProxy インスタンスに接続し、TiProxy インスタンスの`/tmp/traffic`ディレクトリからトラフィックファイルを読み取り、トラフィックを再生します。 ```shell tiproxyctl traffic replay --host 10.0.1.10 --port 3080 --username="u1" --password="123456" --input="/tmp/traffic" @@ -86,7 +86,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア - `cmd_type` : 失敗したコマンドのタイプ。例: `Query` (通常のステートメントを実行)、 `Prepare` (ステートメントを準備)、 `Execute` (プリペアドステートメントを実行)。 - `digest` : 失敗した SQL ステートメントのダイジェスト。 - `sample_stmt` : ステートメントが最初に失敗したときの SQL テキスト。 - - `sample_err_msg` : SQL ステートメントが失敗した場合のエラー メッセージ。 + - `sample_err_msg` : SQL ステートメントが失敗した場合のエラーメッセージ。 - `sample_conn_id` : SQL文のトラフィックファイルに記録された接続ID。これを使用して、トラフィックファイル内の実行コンテキストを表示できます。 - `sample_capture_time` : トラフィックファイルに記録されたSQL文の実行時間。これを使用して、トラフィックファイル内の実行コンテキストを確認できます。 - `sample_replay_time` : 再生中にSQL文が失敗した時刻。これを使用して、TiDBログファイルでエラー情報を確認できます。 @@ -113,7 +113,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア `other_errors`テーブルには、ネットワーク エラーやデータベース接続エラーなどの予期しないエラーが次のフィールドに格納されます。 - `err_type` : エラーの種類。簡潔なエラーメッセージとして表示されます。例: `i/o timeout` 。 - - `sample_err_msg` : エラーが最初に発生したときの完全なエラー メッセージ。 + - `sample_err_msg` : エラーが最初に発生したときの完全なエラーメッセージ。 - `sample_replay_time` : 再生中にエラーが発生した時刻。これを使用して、TiDBログファイルでエラー情報を確認できます。 - `count` : このエラーの発生回数。 diff --git a/tiproxy/troubleshoot-tiproxy.md b/tiproxy/troubleshoot-tiproxy.md index 0495b111799eb..8d03a48496714 100644 --- a/tiproxy/troubleshoot-tiproxy.md +++ b/tiproxy/troubleshoot-tiproxy.md @@ -12,14 +12,14 @@ summary: TiProxy の一般的な問題、原因、および解決策について 次の手順に従って、問題をトラブルシューティングできます。 1. [コネクタバージョン](/tiproxy/tiproxy-overview.md#supported-connectors)がサポートされているかどうかを確認してください。コネクタがリストにない場合は、コネクタが[認証プラグイン](https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html)サポートしているかどうかを確認してください。 -2. クライアントが`No available TiDB instances, please make sure TiDB is available`報告する場合は、TiDBサーバーが存在するかどうか、および TiDBサーバーの SQL ポートと HTTP ステータス ポートに正常に接続できるかどうかを確認します。 +2. クライアントが`No available TiDB instances, please make sure TiDB is available`報告する場合は、TiDBサーバーが存在するかどうか、および TiDBサーバーの SQL ポートと HTTP ステータスポートに正常に接続できるかどうかを確認します。 3. クライアントが`Require TLS enabled on TiProxy when require-backend-tls=true`報告する場合は、TiProxy が TLS 証明書で正しく構成されているかどうかを確認します。 4. クライアントが`Verify TiDB capability failed, please upgrade TiDB`報告する場合は、TiDBサーバーのバージョンが v6.5.0 以降であるかどうかを確認します。 5. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB is available`報告した場合は、 TiProxy ノードが TiDBサーバーに接続できるかどうかを確認します。 6. クライアントが`Require TLS enabled on TiDB when require-backend-tls=true`報告する場合は、TiDB が TLS 証明書で正しく構成されているかどうかを確認します。 7. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB proxy-protocol is set correctly`報告した場合は、 TiProxy で[`proxy.proxy-protocol`](/tiproxy/tiproxy-configuration.md#proxy-protocol)有効になっているかどうか、 TiDBサーバーで[`proxy-protocol`](/tidb-configuration-file.md#proxy-protocol)有効になっていないかどうかを確認します。 8. TiProxy が[`max-connections`](/tiproxy/tiproxy-configuration.md#max-connections)に設定されており、TiProxy 上の接続数が最大接続制限を超えているかどうかを確認します。 -9. TiProxy ログでエラー メッセージを確認してください。 +9. TiProxy ログでエラーメッセージを確認してください。 ## TiProxyは接続を移行しません {#tiproxy-does-not-migrate-connections} diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index b443941baa0b7..2279a85f95cf0 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -15,7 +15,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ このドキュメントでは、 `tidb`ユーザーを例に挙げます。 -1. すべてのターゲット マシンに`root`ユーザーとしてログインし、 `tidb`という名前のユーザーを作成し、このユーザーのシステム リソース制限を次のように構成します。 +1. すべてのターゲットマシンに`root`ユーザーとしてログインし、 `tidb`という名前のユーザーを作成し、このユーザーのシステムリソース制限を次のように構成します。 > **Note:** > @@ -93,13 +93,13 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ 5. SSH 信頼を確立するには、公開キーをクラスター内の他のマシンにコピーします。 - - `tidb`ユーザーにパスワードを設定している場合は、 `ssh-copy-id`コマンドを使用して公開キーをターゲット マシンにコピーできます。 + - `tidb`ユーザーにパスワードを設定している場合は、 `ssh-copy-id`コマンドを使用して公開キーをターゲットマシンにコピーできます。 ```shell ssh-copy-id tidb@host ``` - `host`をターゲット マシンのホスト名に置き換え、クラスター内の他の各マシンでこのコマンドを実行する必要があります。 + `host`をターゲットマシンのホスト名に置き換え、クラスター内の他の各マシンでこのコマンドを実行する必要があります。 - 別の方法で公開鍵をコピーする場合は、コピー後に`/home/tidb/.ssh/authorized_keys`ファイルの権限を必ず確認してください。 @@ -110,13 +110,13 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ ## トポロジファイルを準備する {#prepare-the-topology-file} -1. 次のコマンドを実行してトポロジ ファイルを生成します。 +1. 次のコマンドを実行してトポロジファイルを生成します。 ```shell tiup cluster template > topology.yaml ``` -2. トポロジ ファイルを編集します。 +2. トポロジファイルを編集します。 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`の行を追加する必要があります。`systemd_mode`パラメータは、`systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 4beb3947d82c5..72b33aebdd9af 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -5,7 +5,7 @@ summary: TiUPは、トポロジファイルを使用してTiDBのクラスター # TiUPを使用した TiDB デプロイメントのトポロジコンフィグレーションファイル {#topology-configuration-file-for-tidb-deployment-using-tiup} -TiUPを使用して TiDB をデプロイまたは拡張するには、クラスター トポロジを記述するトポロジ ファイル ( [サンプル](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml) ) を提供する必要があります。 +TiUPを使用して TiDB をデプロイまたは拡張するには、クラスター トポロジを記述するトポロジファイル ( [サンプル](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml) ) を提供する必要があります。 同様に、クラスタートポロジを変更するには、トポロジファイルに変更を加える必要があります。違いは、クラスターのデプロイ後は、トポロジファイル内のフィールドの一部しか変更できないことです。このドキュメントでは、トポロジファイルの各セクションと各セクション内の各フィールドについて説明します。 @@ -50,7 +50,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `deploy_dir` : 各コンポーネントの配置ディレクトリ。デフォルト値は`"deployed"`です。適用ルールは以下のとおりです。 - - インスタンス レベルで絶対パス`deploy_dir`が設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対して`deploy_dir`設定されます。 + - インスタンスレベルで絶対パス`deploy_dir`が設定されている場合、実際のデプロイメントディレクトリはインスタンスに対して`deploy_dir`設定されます。 - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`になります。 @@ -60,7 +60,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `data_dir` : データディレクトリ。デフォルト値: `"data"` 。適用ルールは以下のとおりです。 - - インスタンス レベルで絶対パス`data_dir`が設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対して`data_dir`設定されます。 + - インスタンスレベルで絶対パス`data_dir`が設定されている場合、実際のデプロイメントディレクトリはインスタンスに対して`data_dir`設定されます。 - 各インスタンスに対して`data_dir`設定しない場合、デフォルト値は``になります。 @@ -68,7 +68,7 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `log_dir` : ログディレクトリ。デフォルト値: `"log"` 。適用ルールは以下のとおりです。 - - 絶対パス`log_dir`インスタンス レベルで構成されている場合、実際のログ ディレクトリはインスタンスに構成されている`log_dir`になります。 + - 絶対パス`log_dir`インスタンスレベルで構成されている場合、実際のログディレクトリはインスタンスに構成されている`log_dir`になります。 - 各インスタンスで`log_dir`設定しない場合、デフォルト値は``になります。 @@ -784,7 +784,7 @@ grafana_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_file` : クラスター構成の初期化フェーズ中に、Alertmanager の構成としてターゲット マシンに転送されるローカル ファイルを指定します。 +- `config_file` : クラスター構成の初期化フェーズ中に、Alertmanager の構成としてターゲットマシンに転送されるローカルファイルを指定します。 - `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 4160dc4380a41..902e9d06b4f8d 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -59,13 +59,13 @@ tiup cluster tiup cluster deploy [flags] ``` -このコマンドでは、クラスター名、TiDB クラスター バージョン ( `v8.5.4`など)、およびクラスターのトポロジ ファイルを指定する必要があります。 +このコマンドでは、クラスター名、TiDB クラスター バージョン ( `v8.5.4`など)、およびクラスターのトポロジファイルを指定する必要があります。 トポロジファイルを作成するには、 [例](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)を参照してください。次のファイルは最も単純なトポロジの例です。 > **Note:** > -> TiUPクラスターコンポーネントがデプロイメントとスケーリングに使用するトポロジ ファイルは[YAML](https://yaml.org/spec/1.2/spec.html)構文を使用して記述されるため、インデントが正しいことを確認してください。 +> TiUPクラスターコンポーネントがデプロイメントとスケーリングに使用するトポロジファイルは[YAML](https://yaml.org/spec/1.2/spec.html)構文を使用して記述されるため、インデントが正しいことを確認してください。 ```yaml --- @@ -125,7 +125,7 @@ tidb_servers: tiup cluster deploy -p prod-cluster v8.5.4 /tmp/topology.yaml ``` -実行中に、 TiUP はトポロジーを再度確認するように要求し、ターゲット マシンのルート パスワードを要求します (フラグ`-p`はパスワードの入力を意味します)。 +実行中に、 TiUP はトポロジーを再度確認するように要求し、ターゲットマシンのルートパスワードを要求します (フラグ`-p`はパスワードの入力を意味します)。 ```bash Please confirm your topology: @@ -162,7 +162,7 @@ Deployed cluster `prod-cluster` successfully ## クラスターリストを表示する {#view-the-cluster-list} -クラスターが正常にデプロイされたら、次のコマンドを実行してクラスター リストを表示します。 +クラスターが正常にデプロイされたら、次のコマンドを実行してクラスターリストを表示します。 ```bash tiup cluster list @@ -181,7 +181,7 @@ tiup cluster list tiup cluster start prod-cluster ``` -クラスターの名前を忘れた場合は、 `tiup cluster list`を実行してクラスター リストを表示します。 +クラスターの名前を忘れた場合は、 `tiup cluster list`を実行してクラスターリストを表示します。 TiUPはデーモンプロセスを起動するために`systemd`を使用します。プロセスが予期せず終了した場合、15秒後に再起動されます。 @@ -234,13 +234,13 @@ TiKV およびTiFlashコンポーネントのオフライン プロセスは非 - その後、クラスタ操作に関連するコマンドが実行されると、 TiUPクラスタはオフラインになったTiKVノードまたはTiFlashノードがあるかどうかを確認します。オフラインになったノードがない場合、 TiUPクラスタは指定された操作を続行します。オフラインになったノードがある場合、 TiUPクラスタは以下の手順を実行します。 1. オフラインになったノードのサービスを停止します。 - 2. ノードに関連するデータ ファイルをクリーンアップします。 + 2. ノードに関連するデータファイルをクリーンアップします。 3. クラスター トポロジからノードを削除します。 - その他のコンポーネントの場合: - - PDコンポーネントをダウンさせる場合、 TiUPクラスターは API を介して指定されたノードをクラスターから迅速に削除し、指定された PD ノードのサービスを停止し、関連するデータ ファイルを削除します。 - - 他のコンポーネントを停止する場合、 TiUPクラスターはノード サービスを直接停止し、関連するデータ ファイルを削除します。 + - PDコンポーネントをダウンさせる場合、 TiUPクラスターは API を介して指定されたノードをクラスターから迅速に削除し、指定された PD ノードのサービスを停止し、関連するデータファイルを削除します。 + - 他のコンポーネントを停止する場合、 TiUPクラスターはノード サービスを直接停止し、関連するデータファイルを削除します。 スケールイン コマンドの基本的な使用方法: @@ -291,7 +291,7 @@ PD がノード上のデータを他の TiKV ノードにスケジュールす > > このセクションでは、スケールアウトコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 [TiUPを使用して TiDBクラスタをスケールする](/scale-tidb-using-tiup.md)を参照してください。 -スケールアウト操作にはデプロイメントと同様の内部ロジックがあります。TiUPクラスタコンポーネントは、まずノードの SSH 接続を確認し、ターゲット ノードに必要なディレクトリを作成してから、デプロイメント操作を実行し、ノード サービスを開始します。 +スケールアウト操作にはデプロイメントと同様の内部ロジックがあります。TiUPクラスタコンポーネントは、まずノードの SSH 接続を確認し、ターゲットノードに必要なディレクトリを作成してから、デプロイメント操作を実行し、ノード サービスを開始します。 PDをスケールアウトすると、ノードが`join`によってクラスターに追加され、PDに関連付けられたサービスの設定が更新されます。他のサービスをスケールアウトすると、サービスが直接起動され、クラスターに追加されます。 @@ -303,7 +303,7 @@ PDをスケールアウトすると、ノードが`join`によってクラスタ > **Note:** > - > 既存のノードではなく、新しいノードの説明のみを含むトポロジ ファイルを作成する必要があります。 + > 既存のノードではなく、新しいノードの説明のみを含むトポロジファイルを作成する必要があります。 ```yaml --- @@ -395,7 +395,7 @@ TiUPクラスターは設定ファイルをviエディタで開きます。他 tiup cluster reload prod-cluster ``` -このコマンドは、構成をターゲット マシンに送信し、クラスターを再起動して構成を有効にします。 +このコマンドは、構成をターゲットマシンに送信し、クラスターを再起動して構成を有効にします。 > **Note:** > @@ -644,9 +644,9 @@ CPUスレッド数チェック、メモリサイズチェック、ディスク - 認証にSSHプラグインを使用するには - カスタマイズされたSSHクライアントを使用するには -次に、 `--ssh=system`コマンドライン フラグを使用して、システムネイティブのコマンドライン ツールを有効にできます。 +次に、 `--ssh=system`コマンドラインフラグを使用して、システムネイティブのコマンドラインツールを有効にできます。 -- クラスターをデプロイ: `tiup cluster deploy --ssh=system` . ``にクラスターの名前、 ``にデプロイする TiDB バージョン ( `v8.5.4`など)、 ``にトポロジ ファイルを入力します。 +- クラスターをデプロイ: `tiup cluster deploy --ssh=system` . ``にクラスターの名前、 ``にデプロイする TiDB バージョン ( `v8.5.4`など)、 ``にトポロジファイルを入力します。 - クラスターを開始する: `tiup cluster start --ssh=system` - クラスターのアップグレード: `tiup cluster upgrade ... --ssh=system` @@ -666,14 +666,14 @@ export TIUP_NATIVE_SSH=enable > **Note:** > -> クラスターの展開プロセス中に、接続にパスワードを使用する必要がある場合 ( `-p` ) またはキー ファイルに`passphrase`が設定されている場合は、制御マシンに`sshpass`がインストールされていることを確認する必要があります。そうでない場合、タイムアウト エラーが報告されます。 +> クラスターの展開プロセス中に、接続にパスワードを使用する必要がある場合 ( `-p` ) またはキー ファイルに`passphrase`が設定されている場合は、制御マシンに`sshpass`がインストールされていることを確認する必要があります。そうでない場合、タイムアウトエラーが報告されます。 ## 制御マシンを移行し、 TiUPデータをバックアップする {#migrate-control-machine-and-back-up-tiup-data} TiUPデータは、ユーザーのホームディレクトリ内の`.tiup`ディレクトリに保存されます。コントロールマシンを移行するには、以下の手順に従って`.tiup`ディレクトリを対応するターゲットマシンにコピーします。 1. 元のマシンのホームディレクトリで`tar czvf tiup.tar.gz .tiup`を実行します。 -2. `tiup.tar.gz`をターゲット マシンのホーム ディレクトリにコピーします。 +2. `tiup.tar.gz`をターゲットマシンのホーム ディレクトリにコピーします。 3. 対象マシンのホームディレクトリで`tar xzvf tiup.tar.gz`を実行します。 4. `.tiup`ディレクトリを`PATH`環境変数に追加します。 @@ -691,7 +691,7 @@ TiUPデータは、ユーザーのホームディレクトリ内の`.tiup`ディ tiup cluster meta backup ${cluster_name} ``` -メタ ファイルが失われた場合は、次のコマンドを実行して復元できます。 +メタファイルが失われた場合は、次のコマンドを実行して復元できます。 ```bash tiup cluster meta restore ${cluster_name} ${backup_file} diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index cf3ca92f13f3e..2e05c6644fb7a 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -32,7 +32,7 @@ tiup mirror clone [global version] [flags] ### -o, --os {#o-os} -- 指定されたオペレーティング システムで実行できるコンポーネントのみを複製します。 +- 指定されたオペレーティングシステムで実行できるコンポーネントのみを複製します。 - データ型: `STRING` - デフォルト: "linux,darwin" diff --git a/tiup/tiup-command-mirror-publish.md b/tiup/tiup-command-mirror-publish.md index 06704fbb210b4..1d4fb811221d5 100644 --- a/tiup/tiup-command-mirror-publish.md +++ b/tiup/tiup-command-mirror-publish.md @@ -48,9 +48,9 @@ tiup mirror publish [flags] - ``のバイナリファイルが実行できるオペレーティングシステムを指定します。``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 - - `linux` : ファイルが Linux オペレーティング システムで実行されることを示します。 - - `darwin` : ファイルが Darwin オペレーティング システムで実行されることを示します。 - - `any` : スクリプトなどのファイルが Linux と Darwin の両方のオペレーティング システムで実行されることを示します。 + - `linux` : ファイルが Linux オペレーティングシステムで実行されることを示します。 + - `darwin` : ファイルが Darwin オペレーティングシステムで実行されることを示します。 + - `any` : スクリプトなどのファイルが Linux と Darwin の両方のオペレーティングシステムで実行されることを示します。 - データ型: `STRING` diff --git a/tiup/tiup-command-mirror-set.md b/tiup/tiup-command-mirror-set.md index 3ac4da9e03f33..e1351e27fd10a 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`です。 diff --git a/tiup/tiup-command-mirror-sign.md b/tiup/tiup-command-mirror-sign.md index 5662df4889b30..78a43ceff029a 100644 --- a/tiup/tiup-command-mirror-sign.md +++ b/tiup/tiup-command-mirror-sign.md @@ -18,7 +18,7 @@ tiup mirror sign [flags] - HTTPまたはHTTPSで始まるネットワークアドレス（例： `http://172.16.5.5:8080/rotate/root.json` - ローカルファイルパス（相対パスまたは絶対パス） -ネットワーク アドレスの場合、このアドレスは次の機能を提供する必要があります。 +ネットワークアドレスの場合、このアドレスは次の機能を提供する必要があります。 - 署名されたファイルの完全な内容 ( `signatures`フィールドを含む) を返す`http get`経由のアクセスをサポートします。 - `http post`経由のアクセスをサポートします。クライアントは`http get`から返されたコンテンツの`signatures`フィールドに署名を追加し、このネットワークアドレスに投稿します。 @@ -39,7 +39,7 @@ tiup mirror sign [flags] > **Note:** > -> このオプションは、 ``がネットワーク アドレスの場合にのみ有効です。 +> このオプションは、 ``がネットワークアドレスの場合にのみ有効です。 ## 出力 {#output} diff --git a/tiup/tiup-command-mirror.md b/tiup/tiup-command-mirror.md index e8e72f7cffbaa..05917b1bed276 100644 --- a/tiup/tiup-command-mirror.md +++ b/tiup/tiup-command-mirror.md @@ -7,7 +7,7 @@ summary: TiUPミラーはTiUPの重要な概念であり、ローカルおよび TiUPでは、 [ミラー](/tiup/tiup-mirror-reference.md)は重要な概念です。TiUPは現在、2つの形式のミラーリングをサポートしています。 -- ローカル ミラー: TiUPクライアントとミラーは同じマシン上にあり、クライアントはファイル システムを介してミラーにアクセスします。 +- ローカル ミラー: TiUPクライアントとミラーは同じマシン上にあり、クライアントはファイルシステムを介してミラーにアクセスします。 - リモート ミラー: TiUPクライアントとミラーは同じマシン上に存在せず、クライアントはネットワーク経由でミラーにアクセスします。 `tiup mirror`コマンドはミラーの管理に使用され、ミラーの作成、コンポーネントの配布、キーの管理を行う方法を提供します。 diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index fca6ea3d2b15c..abf1ceec43fdb 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -33,8 +33,8 @@ tiup status [flags] - `PID` : 動作コンポーネントに対応するプロセス ID。 - `Status` : 動作中のコンポーネントのステータス。 - `Created Time` : コンポーネントの開始時刻。 -- `Directory` : コンポーネントのデータ ディレクトリ。 -- `Binary` : コンポーネントのバイナリ ファイル パス。 +- `Directory` : コンポーネントのデータディレクトリ。 +- `Binary` : コンポーネントのバイナリファイルパス。 - `Args` : 操作コンポーネントの開始引数。 ### コンポーネントのステータス {#component-status} diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md index 862e4dc2092e7..539464a724299 100644 --- a/tiup/tiup-command-telemetry.md +++ b/tiup/tiup-command-telemetry.md @@ -11,7 +11,7 @@ TiUPテレメトリが有効になっている場合、 TiUPコマンドの実 - ランダムに生成されたテレメトリ識別子。 - コマンド実行が成功したかどうか、コマンド実行の継続時間などのTiUPコマンドの実行ステータス。 -- ターゲット マシンのハードウェア情報、コンポーネントのバージョン番号、変更された展開構成名など、展開にTiUPを使用する状況。 +- ターゲットマシンのハードウェア情報、コンポーネントのバージョン番号、変更された展開構成名など、展開にTiUPを使用する状況。 以下の情報は共有されません。 diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 344a888aa77cf..f5734d957e62e 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -9,7 +9,7 @@ summary: TiUP クラスタは、ハードウェアとソフトウェア環境が ## チェック項目一覧 {#list-of-check-items} -### オペレーティング システムのバージョン {#operating-system-version} +### オペレーティングシステムのバージョン {#operating-system-version} デプロイされたマシンのオペレーティングシステムのディストリビューションとバージョンを確認してください。サポートされているバージョンのリストについては、 [OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を参照してください。 @@ -39,7 +39,7 @@ summary: TiUP クラスタは、ハードウェアとソフトウェア環境が ### カーネルパラメータ {#kernel-parameters} -次のカーネル パラメータの値を確認します。 +次のカーネルパラメータの値を確認します。 - `net.ipv4.tcp_tw_recycle` : 0 - `net.ipv4.tcp_syncookies` : 0 @@ -96,7 +96,7 @@ ext4パーティションのマウントオプションを確認してくださ ### ポートの使用 {#port-usage} -トポロジで定義されているポート (自動補完のデフォルト ポートを含む) が、ターゲット マシン上のプロセスによってすでに使用されているかどうかを確認します。 +トポロジで定義されているポート (自動補完のデフォルトポートを含む) が、ターゲットマシン上のプロセスによってすでに使用されているかどうかを確認します。 > **Note:** > @@ -236,7 +236,7 @@ tiup cluster check [flags] ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するためのキー ファイルを指定します。 +- ターゲットマシンに接続するためのキー ファイルを指定します。 - データ型: `STRING` - このオプションはデフォルトで有効になっており、 `~/.ssh/id_rsa` (デフォルト値) が渡されます。 @@ -247,7 +247,7 @@ tiup cluster check [flags] ### -p, --password {#p-password} - ターゲットマシンに接続するときにパスワードを使用してログインします。 - - クラスターに`--cluster`オプションが追加された場合、パスワードはクラスターのデプロイ時にトポロジ ファイルに指定されたユーザーのパスワードになります。 + - クラスターに`--cluster`オプションが追加された場合、パスワードはクラスターのデプロイ時にトポロジファイルに指定されたユーザーのパスワードになります。 - クラスターにオプション`--cluster`が追加されていない場合、パスワードはオプション`-u/--user`で指定されたユーザーのパスワードになります。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index e2d62574f54d2..1a34a3e11dd80 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -27,9 +27,9 @@ tiup cluster deploy [flags] ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- ターゲットマシンに接続するために使用するキー ファイルを指定します。 - データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 +- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲットマシンに接続します。 ### -p, --password {#p-password} diff --git a/tiup/tiup-component-cluster-destroy.md b/tiup/tiup-component-cluster-destroy.md index b78895d7689a6..ac4868b328a85 100644 --- a/tiup/tiup-component-cluster-destroy.md +++ b/tiup/tiup-component-cluster-destroy.md @@ -8,7 +8,7 @@ summary: tiup cluster destroyコマンドは、クラスターを停止し、各 アプリケーションがオフラインになった後、クラスターが占有していたマシンを解放して他のアプリケーションで使用できるようにするには、クラスター上のデータとデプロイされたバイナリファイルをクリーンアップする必要があります。クラスターを破棄するには、 `tiup cluster destroy`コマンドで以下の操作を実行します。 - クラスターを停止します。 -- 各サービスについて、ログ ディレクトリ、デプロイメント ディレクトリ、およびデータ ディレクトリを削除します。 +- 各サービスについて、ログディレクトリ、デプロイメントディレクトリ、およびデータディレクトリを削除します。 - tiup-clusterによって各サービスのデータディレクトリまたはデプロイメントディレクトリの親ディレクトリが作成されている場合は、親ディレクトリも削除します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 333f93d7fbe33..9d4a076762cbb 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -82,7 +82,7 @@ tiup cluster display [flags] - ポート: サービスが占有するポート番号 - OS/アーキテクチャ: このノードのオペレーティングシステムとマシンアーキテクチャ - ステータス: ノードサービスの現在のステータス - - データ ディレクトリ: サービスのデータ ディレクトリ。`-`はデータ ディレクトリがないことを意味します。 + - データディレクトリ: サービスのデータディレクトリ。`-`はデータディレクトリがないことを意味します。 - デプロイディレクトリ: サービスのデプロイディレクトリ ### ノードサービスステータス {#node-service-status} diff --git a/tiup/tiup-component-cluster-import.md b/tiup/tiup-component-cluster-import.md index d083882fec6b0..33d7c3862041e 100644 --- a/tiup/tiup-component-cluster-import.md +++ b/tiup/tiup-component-cluster-import.md @@ -66,6 +66,6 @@ tiup cluster import [flags] ## 出力 {#output} -インポート プロセスのログを表示します。 +インポートプロセスのログを表示します。 [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-list.md b/tiup/tiup-component-cluster-list.md index 5bbebab6b149d..a0a42eaf28c0a 100644 --- a/tiup/tiup-component-cluster-list.md +++ b/tiup/tiup-component-cluster-list.md @@ -9,7 +9,7 @@ tiup-cluster は、同じコントロールマシンを使用して複数のク > **Note:** > -> デプロイされたクラスターのデータはデフォルトで`~/.tiup/storage/cluster/clusters/`ディレクトリに保存されるため、同じコントロール マシン上で、現在ログインしているユーザーは他のユーザーがデプロイしたクラスターを表示できません。 +> デプロイされたクラスターのデータはデフォルトで`~/.tiup/storage/cluster/clusters/`ディレクトリに保存されるため、同じコントロールマシン上で、現在ログインしているユーザーは他のユーザーがデプロイしたクラスターを表示できません。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-meta-backup.md b/tiup/tiup-component-cluster-meta-backup.md index c66a476f11fb0..e35cfdbbb482f 100644 --- a/tiup/tiup-component-cluster-meta-backup.md +++ b/tiup/tiup-component-cluster-meta-backup.md @@ -19,7 +19,7 @@ tiup cluster meta backup [flags] ### --file (文字列、デフォルトは現在のディレクトリ) {#file-string-defaults-to-the-current-directory} -TiUPメタ バックアップ ファイルを保存するターゲット ディレクトリを指定します。 +TiUPメタ バックアップファイルを保存するターゲット ディレクトリを指定します。 ### -h, --help {#h-help} diff --git a/tiup/tiup-component-cluster-meta-restore.md b/tiup/tiup-component-cluster-meta-restore.md index fb5c8905fe67d..6b0d6adf6a609 100644 --- a/tiup/tiup-component-cluster-meta-restore.md +++ b/tiup/tiup-component-cluster-meta-restore.md @@ -5,7 +5,7 @@ summary: TiUPメタファイルを復元するには、クラスター名とバ # tiup cluster meta restore {#tiup-cluster-meta-restore} -TiUPメタ ファイルを復元するには、 `tiup cluster meta restore`コマンドを使用してバックアップ ファイルから復元できます。 +TiUPメタファイルを復元するには、 `tiup cluster meta restore`コマンドを使用してバックアップファイルから復元できます。 ## 構文 {#syntax} @@ -14,7 +14,7 @@ tiup cluster meta restore [flags] ``` - ``は操作対象となるクラスターの名前です。 -- ``はTiUPメタ バックアップ ファイルへのパスです。 +- ``はTiUPメタ バックアップファイルへのパスです。 > **Note:** > diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index 3d717230c1391..4428c47f0fb08 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -7,10 +7,10 @@ summary: tiup cluster patch` コマンドを使用すると、実行中のクラ クラスターの実行中にサービスのバイナリを動的に置き換える必要がある場合（つまり、置き換えプロセス中もクラスターを利用可能な状態に保つ必要がある場合）、 `tiup cluster patch`コマンドを使用できます。コマンドの実行後、 TiUP は以下の処理を実行します。 -- 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 +- 置換用のバイナリパッケージをターゲットマシンにアップロードします。 - ターゲット サービスが TiKV やTiFlashなどのストレージサービスの場合、 TiUP はまず API 経由で関連ノードをオフラインにします。 - 対象サービスを停止します。 -- バイナリ パッケージを解凍し、サービスを置き換えます。 +- バイナリパッケージを解凍し、サービスを置き換えます。 - 対象サービスを開始します。 ## 構文 {#syntax} @@ -20,7 +20,7 @@ tiup cluster patch [flags] ``` - `` : 操作対象となるクラスターの名前。 -- `` : 置換に使用されるバイナリ パッケージへのパス。 +- `` : 置換に使用されるバイナリパッケージへのパス。 ### 準備 {#preparation} @@ -45,7 +45,7 @@ tiup cluster patch [flags] mkdir -p /tmp/package && cd /tmp/package ``` -4. 元のバイナリ パッケージを抽出します。 +4. 元のバイナリパッケージを抽出します。 ```shell tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz @@ -57,7 +57,7 @@ tiup cluster patch [flags] find . ``` -6. バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 +6. バイナリファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 7. すべてのファイルを一時ディレクトリにパックします。 diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md index 7205400d67996..56a21e7066c75 100644 --- a/tiup/tiup-component-cluster-scale-in.md +++ b/tiup/tiup-component-cluster-scale-in.md @@ -18,13 +18,13 @@ TiKV およびTiFlashコンポーネントは非同期的にオフラインに 3. ステータス`Tombstone`のノードをクリーンアップするには、コマンド`tiup cluster prune`を実行する必要があります。コマンド`tiup cluster prune`は以下の操作を実行します。 - オフラインになったノードのサービスを停止します。 - - オフラインになったノードのデータ ファイルをクリーンアップします。 + - オフラインになったノードのデータファイルをクリーンアップします。 - クラスター トポロジを更新し、オフラインになったノードを削除します。 その他のコンポーネントの場合: -- PD コンポーネントをオフラインにする場合、 TiUP クラスタ はAPI を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、ノードから関連データ ファイルを削除します。 -- 他のコンポーネントを停止する場合、 TiUP クラスタ はノード サービスを直接停止し、指定されたノードから関連データ ファイルを削除します。 +- PD コンポーネントをオフラインにする場合、 TiUP クラスタ はAPI を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、ノードから関連データファイルを削除します。 +- 他のコンポーネントを停止する場合、 TiUP クラスタ はノード サービスを直接停止し、指定されたノードから関連データファイルを削除します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-cluster-scale-out.md b/tiup/tiup-component-cluster-scale-out.md index 52c088b7ed28a..06b85189c4cf3 100644 --- a/tiup/tiup-component-cluster-scale-out.md +++ b/tiup/tiup-component-cluster-scale-out.md @@ -29,9 +29,9 @@ tiup cluster scale-out [flags] ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- ターゲットマシンに接続するために使用するキー ファイルを指定します。 - データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 +- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲットマシンに接続します。 ### -p, --password {#p-password} diff --git a/tiup/tiup-component-cluster-template.md b/tiup/tiup-component-cluster-template.md index 7b04bd28ef057..051ac8f60a310 100644 --- a/tiup/tiup-component-cluster-template.md +++ b/tiup/tiup-component-cluster-template.md @@ -28,17 +28,17 @@ tiup cluster template [flags] ### --full {#full} - 設定可能なパラメータがコメント化された詳細なトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加します。 -- このオプションを指定しない場合は、デフォルトで単純なトポロジ テンプレートが出力されます。 +- このオプションを指定しない場合は、デフォルトで単純なトポロジテンプレートが出力されます。 ### --local {#local} -- ローカル クラスターの単純なトポロジ テンプレートを出力します。これは直接使用でき、 `global`パラメータは必要に応じて調整できます。 +- ローカル クラスターの単純なトポロジテンプレートを出力します。これは直接使用でき、 `global`パラメータは必要に応じて調整できます。 - このテンプレートは、PD サービス、TiDB サービス、TiKV サービス、Prometheus サービス、および Grafana サービスを作成します。 ### --multi-dc {#multi-dc} - 複数のデータセンターのトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加してください。 -- このオプションを指定しない場合は、デフォルトで単一のデータセンターのトポロジ テンプレートが出力されます。 +- このオプションを指定しない場合は、デフォルトで単一のデータセンターのトポロジテンプレートが出力されます。 ### -h, --help {#h-help} @@ -46,6 +46,6 @@ tiup cluster template [flags] ## 出力 {#output} -指定されたオプションに従ってトポロジ テンプレートを出力します。これは、デプロイメントのためにトポロジ ファイルにリダイレクトできます。 +指定されたオプションに従ってトポロジテンプレートを出力します。これは、デプロイメントのためにトポロジファイルにリダイレクトできます。 [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index a27ed9e342675..1e04fda9a3563 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -118,7 +118,7 @@ tiup cluster upgrade [flags] ### --restart-timeout {#--restart-timeout} -- ローリング アップグレード中にコンポーネントをアップグレードした後の待機時間を指定します。 +- ローリングアップグレード中にコンポーネントをアップグレードした後の待機時間を指定します。 - データ型: `STRINGS` [`golang time.ParseDuration`](https://pkg.go.dev/time#ParseDuration)で解析できるすべての型がサポートされます。 - デフォルト: `0` - このオプションを指定しないと、コンポーネントのアップグレード後に待機時間は発生しません。 diff --git a/tiup/tiup-component-cluster.md b/tiup/tiup-component-cluster.md index 695d4002dfa37..be53f6ed94eed 100644 --- a/tiup/tiup-component-cluster.md +++ b/tiup/tiup-component-cluster.md @@ -26,7 +26,7 @@ tiup cluster [command] [flags] - サポートされる値: - `builtin` : tiup-clusterに組み込まれている easyssh クライアントを SSH クライアントとして使用します。 - - `system` : 現在のオペレーティング システムのデフォルトの SSH クライアントを使用します。 + - `system` : 現在のオペレーティングシステムのデフォルトの SSH クライアントを使用します。 - `none` : SSHクライアントは使用されません。デプロイメントは現在のマシンのみに適用されます。 - コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`が使用されます。 diff --git a/tiup/tiup-component-dm-deploy.md b/tiup/tiup-component-dm-deploy.md index 19d3df77bde75..584c77e4075ca 100644 --- a/tiup/tiup-component-dm-deploy.md +++ b/tiup/tiup-component-dm-deploy.md @@ -27,7 +27,7 @@ tiup dm deploy [flags] ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- ターゲットマシンに接続するために使用するキー ファイルを指定します。 - データ型: `STRING` - デフォルト: `~/.ssh/id_rsa` diff --git a/tiup/tiup-component-dm-destroy.md b/tiup/tiup-component-dm-destroy.md index d51a157f9e3c5..a4c480f5bde17 100644 --- a/tiup/tiup-component-dm-destroy.md +++ b/tiup/tiup-component-dm-destroy.md @@ -8,7 +8,7 @@ summary: tiup dm destroy`コマンドはクラスタを停止し、各サービ アプリケーションがオフラインになった後、クラスターが占有していたマシンを解放して他のアプリケーションで使用できるようにするには、クラスター上のデータとデプロイされたバイナリファイルをクリーンアップする必要があります。クラスターを破棄するには、 `tiup dm destroy`コマンドで以下の操作を実行します。 - クラスターを停止します。 -- 各サービスについて、ログ ディレクトリ、デプロイメント ディレクトリ、およびデータ ディレクトリを削除します。 +- 各サービスについて、ログディレクトリ、デプロイメントディレクトリ、およびデータディレクトリを削除します。 - `tiup-dm`で各サービスのデータディレクトリやデプロイメントディレクトリの親ディレクトリが作成されている場合は、親ディレクトリも削除します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-display.md b/tiup/tiup-component-dm-display.md index c525531de175e..242699be2dbc4 100644 --- a/tiup/tiup-component-dm-display.md +++ b/tiup/tiup-component-dm-display.md @@ -53,9 +53,9 @@ tiup dm display [flags] - `Role` : ノードにデプロイされたサービス ロール (たとえば、TiDB または TiKV)。 - `Host` : ノードに対応するマシンの IP アドレス。 - `Ports` : サービスで使用されるポート番号。 - - `OS/Arch` : ノードのオペレーティング システムとマシンアーキテクチャ。 + - `OS/Arch` : ノードのオペレーティングシステムとマシンアーキテクチャ。 - `Status` : ノード上のサービスの現在のステータス。 - - `Data Dir` : サービスのデータ ディレクトリ。`-`はデータ ディレクトリが存在しないことを意味します。 - - `Deploy Dir` : サービスのデプロイメント ディレクトリ。 + - `Data Dir` : サービスのデータディレクトリ。`-`はデータディレクトリが存在しないことを意味します。 + - `Deploy Dir` : サービスのデプロイメントディレクトリ。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index a4cfcd876679a..e4351b541551a 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -7,10 +7,10 @@ summary: DM クラスターにホットフィックス パッチを適用する クラスターの実行中にサービスのバイナリを動的に置き換える必要がある場合（つまり、置き換え中もクラスターを利用可能な状態に保つ必要がある場合）、 `tiup dm patch`コマンドを使用できます。このコマンドは、以下の処理を実行します。 -- 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 +- 置換用のバイナリパッケージをターゲットマシンにアップロードします。 - API を使用して関連するノードをオフラインにします。 - 対象サービスを停止します。 -- バイナリ パッケージを解凍し、サービスを置き換えます。 +- バイナリパッケージを解凍し、サービスを置き換えます。 - 対象サービスを開始します。 ## 構文 {#syntax} @@ -24,14 +24,14 @@ tiup dm patch [flags] ### 準備 {#preparation} -以下の手順に従って、このコマンドに必要なバイナリ パッケージを事前にパックする必要があります。 +以下の手順に従って、このコマンドに必要なバイナリパッケージを事前にパックする必要があります。 -- 置換するコンポーネントの名前`${component}` (dm-master、dm-worker ...)、コンポーネントの`${version}` (v2.0.0、v2.0.1 ...)、およびコンポーネントが実行されるオペレーティング システム`${os}`とプラットフォーム`${arch}`を決定します。 +- 置換するコンポーネントの名前`${component}` (dm-master、dm-worker ...)、コンポーネントの`${version}` (v2.0.0、v2.0.1 ...)、およびコンポーネントが実行されるオペレーティングシステム`${os}`とプラットフォーム`${arch}`を決定します。 - コマンド`wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz`を使用して現在のコンポーネントパッケージをダウンロードします。 - `mkdir -p /tmp/package && cd /tmp/package`を実行して、ファイルをパックするための一時ディレクトリを作成します。 -- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`を実行して元のバイナリ パッケージを解凍します。 +- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`を実行して元のバイナリパッケージを解凍します。 - `find .`を実行して、一時パッケージ ディレクトリ内のファイル構造を表示します。 -- バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 +- バイナリファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 - `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *`を実行して、一時ディレクトリにファイルをパックします。 - 最後に、 `tiup dm patch`コマンドの``の値として`/tmp/${component}-hotfix-${os}-${arch}.tar.gz`を使用できます。 @@ -108,7 +108,7 @@ tiup dm patch [flags] tar -zxvf /root/.tiup/storage/dm/packages/dm-worker-v5.3.0-linux-amd64.tar.gz -C /tmp/package/ ``` -2. バイナリ ファイルを修正プログラム パッケージに置き換えます。 +2. バイナリファイルを修正プログラム パッケージに置き換えます。 ```shell # Decompress the hotfix package and use it to replace the binary file. diff --git a/tiup/tiup-component-dm-scale-out.md b/tiup/tiup-component-dm-scale-out.md index 8c69f1982d88e..a4a9a9c24ef87 100644 --- a/tiup/tiup-component-dm-scale-out.md +++ b/tiup/tiup-component-dm-scale-out.md @@ -27,9 +27,9 @@ tiup dm scale-out [flags] ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- ターゲットマシンに接続するために使用するキー ファイルを指定します。 - データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 +- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲットマシンに接続します。 ### -p, --password {#p-password} diff --git a/tiup/tiup-component-dm-template.md b/tiup/tiup-component-dm-template.md index 11253332382e8..55e6046c94133 100644 --- a/tiup/tiup-component-dm-template.md +++ b/tiup/tiup-component-dm-template.md @@ -16,7 +16,7 @@ tiup dm template [flags] このオプションを指定しない場合、出力のデフォルト テンプレートには次のインスタンスが含まれます。 - 3 つの DM マスター インスタンス -- 3 つの DM ワーカー インスタンス +- 3 つの DM ワーカーインスタンス - 1つのPrometheusインスタンス - 1 つの Grafana インスタンス - 1 つの Alertmanager インスタンス @@ -26,7 +26,7 @@ tiup dm template [flags] ### --full {#full} - 設定可能なパラメータがコメント化された詳細なトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加します。 -- このオプションを指定しない場合は、デフォルトで単純なトポロジ テンプレートが出力されます。 +- このオプションを指定しない場合は、デフォルトで単純なトポロジテンプレートが出力されます。 ### -h, --help {#h-help} @@ -34,6 +34,6 @@ tiup dm template [flags] ## 出力 {#output} -指定されたオプションに従ってトポロジ テンプレートを出力します。これは、デプロイメントのためにトポロジ ファイルにリダイレクトできます。 +指定されたオプションに従ってトポロジテンプレートを出力します。これは、デプロイメントのためにトポロジファイルにリダイレクトできます。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-upgrade.md b/tiup/tiup-component-dm-upgrade.md index d6a4dcb24ab92..efe8dc5b5cef1 100644 --- a/tiup/tiup-component-dm-upgrade.md +++ b/tiup/tiup-component-dm-upgrade.md @@ -30,6 +30,6 @@ tiup dm upgrade [flags] ## 出力 {#output} -サービスのアップグレード プロセスのログ。 +サービスのアップグレードプロセスのログ。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm.md b/tiup/tiup-component-dm.md index e673c2265995a..9c49f6de4f4d9 100644 --- a/tiup/tiup-component-dm.md +++ b/tiup/tiup-component-dm.md @@ -26,7 +26,7 @@ tiup dm [command] [flags] - サポート値: - `builtin` : tiup-clusterの組み込み easyssh クライアントを SSH クライアントとして使用します。 - - `system` : 現在のオペレーティング システムのデフォルトの SSH クライアントを使用します。 + - `system` : 現在のオペレーティングシステムのデフォルトの SSH クライアントを使用します。 - `none` : SSHクライアントは使用されません。デプロイメントは現在のマシンのみに適用されます。 - コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`が使用されます。 @@ -64,7 +64,7 @@ tiup dm [command] [flags] ## コマンドリスト {#command-list} - [import](/tiup/tiup-component-dm-import.md) : DM-Ansible によってデプロイされた DM v1.0 クラスターをインポートします。 -- [template](/tiup/tiup-component-dm-template.md) : トポロジ テンプレートを出力します。 +- [template](/tiup/tiup-component-dm-template.md) : トポロジテンプレートを出力します。 - [deploy](/tiup/tiup-component-dm-deploy.md) : 指定されたトポロジに基づいてクラスターをデプロイします。 - [list](/tiup/tiup-component-dm-list.md) : デプロイされたクラスターのリストを照会します。 - [display](/tiup/tiup-component-dm-display.md) : 指定されたクラスターのステータスを表示します。 @@ -84,5 +84,4 @@ tiup dm [command] [flags] - [enable](/tiup/tiup-component-dm-enable.md) : マシンの再起動後にクラスター サービスを自動的に有効化します。 - [disable](/tiup/tiup-component-dm-disable.md) : マシンの再起動後にクラスター サービスの自動有効化を無効にします。 - [help](/tiup/tiup-component-dm-help.md) : ヘルプ情報を出力します。 - [<< 前のページに戻る - TiUP参照コンポーネントリスト](/tiup/tiup-reference.md#component-list) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index ca724f176ecdd..a602d69459824 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -29,16 +29,16 @@ TiUPを使用した DM クラスターのデプロイメントのトポロジ構 - `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 - `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 - - 絶対パス`deploy_dir`インスタンス レベルで構成されている場合、実際のデプロイメント ディレクトリはインスタンスに対して構成されている`deploy_dir`なります。 + - 絶対パス`deploy_dir`インスタンスレベルで構成されている場合、実際のデプロイメントディレクトリはインスタンスに対して構成されている`deploy_dir`なります。 - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`なります。 - `global.deploy_dir`絶対パスに設定すると、コンポーネントは`/`ディレクトリにデプロイされます。 - `global.deploy_dir`相対パスに設定すると、コンポーネントは`/home///`ディレクトリにデプロイされます。 - `data_dir` : データディレクトリ。デフォルト値は「data」です。構築ルールは以下のとおりです。 - - 絶対パス`data_dir`インスタンス レベルで構成されている場合、実際のデータ ディレクトリはインスタンスに構成されている`data_dir`なります。 + - 絶対パス`data_dir`インスタンスレベルで構成されている場合、実際のデータディレクトリはインスタンスに構成されている`data_dir`なります。 - 各インスタンスに対して`data_dir`が設定されていない場合、デフォルト値は``なります。 - `data_dir`相対パスに設定されている場合、コンポーネントデータは`/`に保存されます。 ``の構築規則については、 `deploy_dir`フィールドの構築規則を参照してください。 - `log_dir` : データディレクトリ。デフォルト値は「log」です。構築ルールは以下のとおりです。 - - インスタンス レベルで絶対パス`log_dir`が設定されている場合、実際のログ ディレクトリはインスタンスに設定されている`log_dir`なります。 + - インスタンスレベルで絶対パス`log_dir`が設定されている場合、実際のログディレクトリはインスタンスに設定されている`log_dir`なります。 - 各インスタンスについて、ユーザーが`log_dir`設定しない場合、デフォルト値は``なります。 - `log_dir`が相対パスの場合、コンポーネントログは`/`に保存されます。 ``の構築ルールについては、 `deploy_dir`フィールドの構築ルールを参照してください。 - `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 diff --git a/tiup/tiup-faq.md b/tiup/tiup-faq.md index a1b5e5e96f66b..cafb1a21ed54d 100644 --- a/tiup/tiup-faq.md +++ b/tiup/tiup-faq.md @@ -24,7 +24,7 @@ TiUPは現時点ではサードパーティ製コンポーネントをサポー TiUP Playgroundコンポーネントは、主にLinuxまたはmacOSオペレーティングシステム上でスタンドアロン開発環境を構築するために使用されます。これにより、 TiUPクラスタの特定のバージョンを迅速に開始し、簡単に実行できます。TiUPクラスタコンポーネントは、主に本番環境クラスタ（通常は大規模クラスタ）のデプロイと保守に使用されます。TiUP PlaygroundでデプロイされたTiDBクラスタには、一部の機能と運用能力が不足している可能性があるため、完全な機能テストや安定性テストには推奨されません。 -## TiUPクラスターコンポーネントのトポロジ ファイルを作成するにはどうすればよいでしょうか? {#how-do-i-write-the-topology-file-for-the-tiup-cluster-component} +## TiUPクラスターコンポーネントのトポロジファイルを作成するにはどうすればよいでしょうか? {#how-do-i-write-the-topology-file-for-the-tiup-cluster-component} トポロジファイルの作成方法については、 [これらのテンプレート](https://github.com/pingcap/tiup/tree/master/embed/examples/cluster)を参照してください。テンプレートには以下が含まれます。 @@ -32,7 +32,7 @@ TiUP Playgroundコンポーネントは、主にLinuxまたはmacOSオペレー - 最小限の展開トポロジ - 完全なトポロジファイル -テンプレートとニーズに基づいてトポロジ ファイルを編集できます。 +テンプレートとニーズに基づいてトポロジファイルを編集できます。 ## 同じホストに複数のインスタンスを展開できますか? {#can-multiple-instances-be-deployed-on-the-same-host} diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 2139dbd4170bd..6b0e783e3b757 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -7,7 +7,7 @@ summary: TiUPミラーの一般情報を学びます。 TiUPミラーは、コンポーネントとそのメタデータを保存するTiUPのコンポーネントウェアハウスです。TiUPミラーには、次の2つの形式があります。 -- ローカル ディスク上のディレクトリ: このドキュメントではローカル ミラーと呼ばれるローカルTiUPクライアントを提供します。 +- ローカルディスク上のディレクトリ: このドキュメントではローカル ミラーと呼ばれるローカルTiUPクライアントを提供します。 - リモート ディスク ディレクトリに基づいて開始された HTTP ミラー: このドキュメントではリモート ミラーと呼ばれるリモートTiUPクライアントにサービスを提供します。 ## ミラーの作成と更新 {#create-and-update-mirror} @@ -100,9 +100,9 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの ### 索引 {#index} -インデックス ファイルには、ミラー内のすべてのコンポーネントとコンポーネントの所有者情報が記録されます。 +インデックスファイルには、ミラー内のすべてのコンポーネントとコンポーネントの所有者情報が記録されます。 -インデックス ファイルの形式は次のとおりです。 +インデックスファイルの形式は次のとおりです。 { "signatures": [ # The file's signature. @@ -163,9 +163,9 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの ### コンポーネント {#component} -コンポーネントのメタデータ ファイルには、コンポーネント固有のプラットフォームとバージョンの情報が記録されます。 +コンポーネントのメタデータファイルには、コンポーネント固有のプラットフォームとバージョンの情報が記録されます。 -コンポーネントメタデータ ファイルの形式は次のとおりです。 +コンポーネントメタデータファイルの形式は次のとおりです。 { "signatures": [ # The file's signature. @@ -211,9 +211,9 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの ### スナップショット {#snapshot} -スナップショット ファイルには、各メタデータ ファイルのバージョン番号が記録されます。 +スナップショットファイルには、各メタデータファイルのバージョン番号が記録されます。 -スナップショット ファイルの構造は次のとおりです。 +スナップショットファイルの構造は次のとおりです。 { "signatures": [ # The file's signature. diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 9cfcdf1264da1..4e298ce12e8de 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 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index 536be803da635..3eccd7ad8ac27 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -23,7 +23,7 @@ tiup [flags] [args...] # Runs a component ### --binary {#binary} -- このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 +- このオプションを有効にすると、指定されたバイナリファイルのパスが出力されます。 - `tiup --binary `を実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。``がインストールされていない場合はエラーが返されます。 - `tiup --binary :`を実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 diff --git a/tiup/tiup-terminology-and-concepts.md b/tiup/tiup-terminology-and-concepts.md index 9d526e0845366..514b4904a3f08 100644 --- a/tiup/tiup-terminology-and-concepts.md +++ b/tiup/tiup-terminology-and-concepts.md @@ -28,7 +28,7 @@ TiUPプログラムには、コンポーネントのダウンロード、アッ TiUPのすべてのコンポーネントは、 TiUPミラーからダウンロードされます。TiUPTiUPには、各コンポーネントのTARパッケージと対応するメタ情報（バージョン、エントリ起動ファイル、チェックサム）が含まれています。TiUPはデフォルトでPingCAPの公式ミラーを使用します。ミラーソースは、環境変数`TIUP_MIRRORS`を使用してカスタマイズできます。 -TiUPミラーは、ローカル ファイル ディレクトリまたはオンライン HTTPサーバーになります。 +TiUPミラーは、ローカルファイル ディレクトリまたはオンライン HTTPサーバーになります。 - `TIUP_MIRRORS=/path/to/local tiup list` - `TIUP_MIRRORS=https://private-mirrors.example.com tiup list` diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 4243d3b8f61f3..e96223d45cef0 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -35,13 +35,13 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック - `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。`-i`を使用して秘密鍵のパスを明示的に指定することをお勧めします。 - フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。`ssh -i identity_file user@remote`コマンドを手動で実行することで確認できます。 -- リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 +- リモートホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 -### TiUPクラスタコンポーネントを使用したクラスタのアップグレード プロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} +### TiUPクラスタコンポーネントを使用したクラスタのアップグレードプロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} -誤用を避けるため、 TiUPクラスターコンポーネントは指定されたノードのアップグレードをサポートしていません。そのため、アップグレードが失敗した後は、アップグレード プロセス中のべき等操作を含むアップグレード操作を再度実行する必要があります。 +誤用を避けるため、 TiUPクラスターコンポーネントは指定されたノードのアップグレードをサポートしていません。そのため、アップグレードが失敗した後は、アップグレードプロセス中のべき等操作を含むアップグレード操作を再度実行する必要があります。 -アップグレード プロセスは次の手順に分けられます。 +アップグレードプロセスは次の手順に分けられます。 1. すべてのノード上のコンポーネントの古いバージョンをバックアップします 2. 新しいコンポーネントをリモートに配布 diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 04d0083be42bc..c348b66e7e28f 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -84,10 +84,10 @@ v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオ 現在、適用可能なポイント書き込みステートメントの種類は`UPDATE` 、 `DELETE` 、 `SELECT ...... FOR UPDATE`です。ポイント書き込みステートメントとは、主キーまたは一意キーをフィルター条件として使用し、最終実行演算子に`POINT-GET`含まれる書き込みステートメントを指します。現在、3種類のポイント書き込みステートメントに共通するのは、まずキー値に基づいてポイントクエリを実行することです。キーが存在する場合は、キーをロックします。キーが存在しない場合は、空のセットを返します。 -- ポイント書き込みステートメントの読み取りプロセス全体で更新されたデータ バージョンが検出されない場合、TiDB は引き続き現在のトランザクションのタイムスタンプを使用してデータをロックします。 +- ポイント書き込みステートメントの読み取りプロセス全体で更新されたデータバージョンが検出されない場合、TiDB は引き続き現在のトランザクションのタイムスタンプを使用してデータをロックします。 - ロック取得プロセス中に古いタイムスタンプが原因で書き込み競合が発生した場合、TiDB は最新のグローバル タイムスタンプを取得してロック取得プロセスを再試行します。 - ロック取得プロセス中に書き込み競合やその他のエラーが発生しない場合、ロックは正常に取得されます。 -- 読み取りプロセス中に更新されたデータ バージョンが検出されると、TiDB は新しいタイムスタンプを取得してこのステートメントを再試行します。 +- 読み取りプロセス中に更新されたデータバージョンが検出されると、TiDB は新しいタイムスタンプを取得してこのステートメントを再試行します。 ポイント書き込みステートメントは多いが、分離レベル`READ-COMMITTED`でのポイント書き込み競合が少ないトランザクションでは、この変数を有効にすると、グローバル タイムスタンプの取得のレイテンシーとオーバーヘッドを回避できます。 diff --git a/troubleshoot-data-inconsistency-errors.md b/troubleshoot-data-inconsistency-errors.md index ffe911f23cf67..86ce15e2c924d 100644 --- a/troubleshoot-data-inconsistency-errors.md +++ b/troubleshoot-data-inconsistency-errors.md @@ -21,7 +21,7 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st ## エラーの説明 {#error-explanation} -データとインデックスの不整合が発生した場合は、TiDB エラー メッセージをチェックして、行データとインデックス データのどの項目に不整合があるかを確認したり、関連するエラー ログをチェックしてさらに調査したりすることができます。 +データとインデックスの不整合が発生した場合は、TiDB エラーメッセージをチェックして、行データとインデックスデータのどの項目に不整合があるかを確認したり、関連するエラーログをチェックしてさらに調査したりすることができます。 ### トランザクション実行中に報告されたエラー {#errors-reported-during-transaction-execution} @@ -73,7 +73,7 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st このエラーは、表`t`のインデックス`c2`の列`c2`の値に次の不一致があることを示しています。 -- ハンドルが`2`である行のインデックス キーと値のペアでは、列`c2`の値は`13`です。 +- ハンドルが`2`である行のインデックスキーと値のペアでは、列`c2`の値は`13`です。 - 行レコードのキーと値のペアでは、列`c2`の値は`12`です。 #### エラー8223 {#error-8223} diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index d3ac5174da5b9..e0d9651feb255 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -28,14 +28,14 @@ Value: [col1, col2, col3, col4] キーの`tablePrefix`と`recordPrefixSep`は特定の文字列定数であり、KV 空間内の他のデータと区別するために使用されます。 -インデックス データの場合、キーと値のペアは次の規則に従ってエンコードされます。 +インデックスデータの場合、キーと値のペアは次の規則に従ってエンコードされます。 ``` Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue Value: rowID ``` -インデックス データには、一意インデックスと非一意インデックスの 2 種類があります。 +インデックスデータには、一意インデックスと非一意インデックスの 2 種類があります。 - 一意インデックスの場合は、上記のコーディング規則に従うことができます。 - 非一意インデックスの場合、このエンコーディングでは一意キーを構築できません。これは、同じインデックスの`tablePrefix{TableID}_indexPrefixSep{IndexID}`は同じですが、複数の行の`ColumnsValue`は同じになる可能性があるためです。非一意インデックスのエンコーディング規則は次のとおりです。 @@ -188,6 +188,6 @@ v8.5.7 以降、PD は読み取りホットスポット向けの CPU-aware hot R スケジューリング次元を表示または調整するには、[`pd-ctl scheduler config balance-hot-region-scheduler`](/pd-control.md#scheduler-config-balance-hot-region-scheduler) を使用します。 -## TiKV MVCC インメモリ エンジンを使用して、高い MVCC 読み取り増幅によって発生する読み取りホットスポットを軽減します。 {#use-tikv-mvcc-in-memory-engine-to-mitigate-read-hotspots-caused-by-high-mvcc-read-amplification} +## TiKV MVCC インメモリエンジンを使用して、高い MVCC 読み取り増幅によって発生する読み取りホットスポットを軽減します。 {#use-tikv-mvcc-in-memory-engine-to-mitigate-read-hotspots-caused-by-high-mvcc-read-amplification} GCの履歴MVCCデータの保持期間が長すぎる場合、またはレコードが頻繁に更新または削除される場合、多数のMVCCバージョンをスキャンすることで読み取りホットスポットが発生する可能性があります。このようなホットスポットを軽減するには、 [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)機能を有効にします。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index e3802c1722162..c621ff97ebde6 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -19,7 +19,7 @@ TiDBはバージョン5.1以降、ロックビュー機能をサポートして - [`TIDB_TRX`および`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) : 現在の TiDB ノードまたはクラスター全体で実行中のすべてのトランザクションの情報 (トランザクションがロック待機状態にあるかどうか、ロック待機時間、トランザクションで実行されたステートメントのダイジェストなど) を提供します。 - [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) : ブロックしているトランザクションとブロックされたトランザクションの`start_ts` 、ブロックされた SQL ステートメントのダイジェスト、待機が発生したキーなど、悲観的ロック待機情報を TiKV で提供します。 -- [`DEADLOCKS`と`CLUSTER_DEADLOCKS`](/information-schema/information-schema-deadlocks.md) : デッドロック ループ内のトランザクション間の待機関係、トランザクションで現在実行されているステートメントのダイジェスト、待機が発生しているキーなど、現在の TiDB ノードまたはクラスター全体で最近発生したいくつかのデッドロック イベントの情報を提供します。 +- [`DEADLOCKS`と`CLUSTER_DEADLOCKS`](/information-schema/information-schema-deadlocks.md) : デッドロック ループ内のトランザクション間の待機関係、トランザクションで現在実行されているステートメントのダイジェスト、待機が発生しているキーなど、現在の TiDB ノードまたはクラスター全体で最近発生したいくつかのデッドロックイベントの情報を提供します。 > **Note:** > @@ -29,7 +29,7 @@ TiDBはバージョン5.1以降、ロックビュー機能をサポートして ### デッドロックエラー {#deadlock-errors} -最近のデッドロック エラーの情報を取得するには、テーブル`DEADLOCKS`または`CLUSTER_DEADLOCKS`をクエリできます。 +最近のデッドロックエラーの情報を取得するには、テーブル`DEADLOCKS`または`CLUSTER_DEADLOCKS`をクエリできます。 たとえば、テーブル`DEADLOCKS`をクエリするには、次の SQL ステートメントを実行できます。 @@ -153,13 +153,13 @@ CURRENT_SQL_DIGEST_TEXT: update `t` set `v` = `v` + ? where `id` = ? ; ### メタデータロック {#metadata-locks} -セッションがスキーマの変更を待機している場合、メタデータ ロックが原因である可能性があります。 +セッションがスキーマの変更を待機している場合、メタデータロックが原因である可能性があります。 詳細については[メタデータロック](/metadata-lock.md)を参照してください。 ## 楽観的ロックの競合のトラブルシューティング {#troubleshoot-optimistic-lock-conflicts} -このセクションでは、楽観的トランザクション モードでの一般的なロック競合の問題の解決策を示します。 +このセクションでは、楽観的トランザクションモードでの一般的なロック競合の問題の解決策を示します。 ### 読み書き競合 {#read-write-conflicts} @@ -235,7 +235,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ - 監視中にtxnLockが少量発生しても、あまり気にする必要はありません。バックオフとリトライはバックグラウンドで自動的に実行されます。リトライの初回は100ミリ秒、最大1回のリトライ時間は3000ミリ秒です。 - `KV Backoff OPS`に「txnLock」操作が多すぎる場合は、アプリケーション側から書き込み競合の原因を分析することをお勧めします。 -- アプリケーションで書き込み-書き込み競合が発生するシナリオの場合は、悲観的トランザクション モードを使用することを強くお勧めします。 +- アプリケーションで書き込み-書き込み競合が発生するシナリオの場合は、悲観的トランザクションモードを使用することを強くお勧めします。 ### LockNotFoundエラー {#locknotfound-error} @@ -279,7 +279,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ ## 悲観的ロックの競合のトラブルシューティング {#troubleshoot-pessimistic-lock-conflicts} -このセクションでは、悲観的トランザクション モードでの一般的なロック競合の問題の解決策を示します。 +このセクションでは、悲観的トランザクションモードでの一般的なロック競合の問題の解決策を示します。 > **Note:** > @@ -287,7 +287,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ ### 読み書き競合 {#read-write-conflicts} -エラー メッセージと解決策は、楽観的ロックの競合の[読み取り書き込み競合](#read-write-conflicts)と同じです。 +エラーメッセージと解決策は、楽観的ロックの競合の[読み取り書き込み競合](#read-write-conflicts)と同じです。 ### 悲観的ロック再試行制限に達しました {#pessimistic-lock-retry-limit-reached} @@ -295,7 +295,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ TiDBのロック操作は書き込み操作であり、そのプロセスはまず読み取り、次に書き込みであるため、RPCリクエストは2つあります。トランザクションの途中で書き込み競合が発生した場合、TiDBは対象キーのロックを再度試行し、各再試行はTiDBログに出力されます。再試行回数は[pessimistic-txn.max-retry-count](/tidb-configuration-file.md#max-retry-count)です。 -悲観的トランザクション モードでは、書き込み競合が発生し、再試行回数が上限に達すると、次のキーワードを含むエラー メッセージが TiDB ログに表示されます。 +悲観的トランザクションモードでは、書き込み競合が発生し、再試行回数が上限に達すると、次のキーワードを含むエラーメッセージが TiDB ログに表示されます。 ```log err="pessimistic lock retry limit reached" @@ -310,7 +310,7 @@ err="pessimistic lock retry limit reached" 悲観的トランザクションモードでは、トランザクションは互いのロックを待機します。ロック待機のタイムアウトは、TiDBのパラメータ[innodb_lock_wait_timeout](/pessimistic-transaction.md#behaviors)によって定義されます。これは、SQL文レベルでの最大ロック待機時間であり、SQL文がロックを要求したがロックが取得されなかった場合に想定される時間です。この時間が経過すると、TiDBは再びロックを試行せず、対応するエラーメッセージをクライアントに返します。 -待機ロックのタイムアウトが発生すると、次のエラー メッセージがクライアントに返されます。 +待機ロックのタイムアウトが発生すると、次のエラーメッセージがクライアントに返されます。 ```log ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction @@ -324,7 +324,7 @@ ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction トランザクションの実行時間はGCのタイムリミットを超えることはできません。また、悲観的トランザクションのTTL時間には上限があり、デフォルト値は1時間です。そのため、1時間を超えて実行された悲観的トランザクションはコミットに失敗します。このタイムアウトしきい値は、TiDBパラメータ[`performance.max-txn-ttl`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example)によって制御されます。 -悲観的トランザクションの実行時間が TTL 時間を超えると、TiDB ログに次のエラー メッセージが表示されます。 +悲観的トランザクションの実行時間が TTL 時間を超えると、TiDB ログに次のエラーメッセージが表示されます。 ```log TTL manager has timed out, pessimistic locks may expire, please commit or rollback this transaction diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 7657c5b8858e1..1d255f4397dd0 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -144,7 +144,7 @@ TiKV は 10 秒ごとに次のメトリックをチェックします。 - [`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md)を実行すると、同じTiDBサーバーに接続されている現在のセッションと、現在のステートメントに費やされた時間が表示されます。ただし、start_tsは表示されません。 -進行中の大規模トランザクションが原因でロックが存在する場合は、これらのロックによって解決の進行が妨げられる可能性があるため、アプリケーション ロジックの変更を検討してください。 +進行中の大規模トランザクションが原因でロックが存在する場合は、これらのロックによって解決の進行が妨げられる可能性があるため、アプリケーションロジックの変更を検討してください。 ロックが進行中のトランザクションに属していない場合は、コーディネーター（TiDB）がロックを事前書き込みした後にクラッシュしたことが原因の可能性があります。この場合、TiDBは自動的にロックを解決します。問題が解決しない限り、特に対処する必要はありません。 @@ -156,7 +156,7 @@ TiKV は 10 秒ごとに次のメトリックをチェックします。 - トランザクションの特定：まず、ロックに関連するトランザクションを特定します。ロックが存在する理由を理解することが重要です。ログを活用すると特に役立ちます。 -- アプリケーション ロジックを調べる: トランザクションの所要時間が長くなっている原因がアプリケーションのロジックにある場合は、そのような事態が発生しないようにロジックを修正することを検討してください。 +- アプリケーションロジックを調べる: トランザクションの所要時間が長くなっている原因がアプリケーションのロジックにある場合は、そのような事態が発生しないようにロジックを修正することを検討してください。 - スロークエリに対処する: スロークエリが原因でトランザクションの期間が長くなる場合は、これらのクエリの解決を優先して問題を軽減します。 diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index 8924fc884e818..d36de199a16e2 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -99,7 +99,7 @@ panicログをご提供いただければ、 [バグを報告する](/support.md ## 接続が拒否されました {#the-connection-is-rejected} -オペレーティング システムのネットワーク パラメータが正しいことを確認します。これには以下が含まれますが、これらに限定されません。 +オペレーティングシステムのネットワーク パラメータが正しいことを確認します。これには以下が含まれますが、これらに限定されません。 - 接続文字列内のポートは、開始ポート`tidb-server`と一致します。 - ファイアウォールは正しく設定されています。 diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index aff161dc71446..091ce80fd582f 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -71,7 +71,7 @@ OOM の問題は通常、次の原因で発生します。 不適切な展開による OOM の原因は次のとおりです。 -- オペレーティング システムのメモリ容量が小さすぎます。 +- オペレーティングシステムのメモリ容量が小さすぎます。 - TiUP構成[`resource_control`](/tiup/tiup-cluster-topology-reference.md#global)は適切ではありません。 - ハイブリッド デプロイメント (つまり、TiDB と他のアプリケーションが同じサーバーにデプロイされている) の場合、リソース不足により、TiDB が`oom-killer`によって誤って強制終了されることがあります。 @@ -113,7 +113,7 @@ OOM 問題のさまざまな原因に応じて、SQL ステートメントのメ TiDBノードは起動後、統計情報をメモリに読み込む必要があります。TiDBは統計情報を収集する際にメモリを消費します。メモリ使用量は、以下の方法で制御できます。 -- サンプリング レートを指定し、特定の列の統計情報のみを収集し、`ANALYZE`の同時実行性を減らします。 +- サンプリングレートを指定し、特定の列の統計情報のみを収集し、`ANALYZE`の同時実行性を減らします。 - TiDB v6.1.0 以降では、システム変数[`tidb_stats_cache_mem_quota`](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610)を使用して統計情報のメモリ使用量を制御できます。 - TiDB v6.1.0 以降では、システム変数[`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610)を使用して、TiDB が統計を更新するときに最大メモリ使用量を制御できます。 @@ -146,9 +146,9 @@ TiDBノードは起動後、統計情報をメモリに読み込む必要があ OOM 問題の根本原因を特定するには、次の情報を収集する必要があります。 -- オペレーティング システムのメモリ関連の構成を収集します。 +- オペレーティングシステムのメモリ関連の構成を収集します。 - TiUP構成: `resource_control.memory_limit` - - オペレーティング システムの構成: + - オペレーティングシステムの構成: - メモリ情報: `cat /proc/meminfo` - カーネルパラメータ: `vm.overcommit_memory` - NUMA情報: diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 2cafd6d71174c..e1c228f358619 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -28,7 +28,7 @@ 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) diff --git a/tso-configuration-file.md b/tso-configuration-file.md index 621db83da71f4..ad1c752897e9a 100644 --- a/tso-configuration-file.md +++ b/tso-configuration-file.md @@ -78,7 +78,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `redact-info-log` {#redact-info-log} - TSO ノード ログでログの秘匿化を有効にするかどうかを制御します。 -- 構成値を`true`に設定すると、TSO ノード ログでユーザー データが秘匿化されます。 +- 構成値を`true`に設定すると、TSO ノード ログでユーザーデータが秘匿化されます。 - デフォルト値: `false` ## log {#log} @@ -116,13 +116,13 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `max-days` {#max-days} - ログが保持される最大日数。 -- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はログ ファイルをクリーンアップしません。 +- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はログファイルをクリーンアップしません。 - デフォルト値: `0` ### `max-backups` {#max-backups} -- 保持されるログ ファイルの最大数。 -- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はすべてのログ ファイルを保持します。 +- 保持されるログファイルの最大数。 +- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はすべてのログファイルを保持します。 - デフォルト値: `0` ## metric {#metric} diff --git a/tune-operating-system.md b/tune-operating-system.md index 6daf8adeaaab9..6d6d4a6106fe4 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -1,6 +1,6 @@ --- title: Tune Operating System Performance -summary: オペレーティング システムのパラメータを調整する方法を学びます。 +summary: オペレーティングシステムのパラメータを調整する方法を学びます。 --- # オペレーティングシステムのパフォーマンスを調整する {#tune-operating-system-performance} @@ -43,7 +43,7 @@ CentOS 7.6以降、LinuxカーネルはBerkeley Packet Filter（BPF）をサポ ## パフォーマンスチューニング {#performance-tuning} -このセクションでは、分類されたカーネル サブシステムに基づいたパフォーマンス チューニングについて説明します。 +このセクションでは、分類されたカーネル サブシステムに基づいたパフォーマンスチューニングについて説明します。 ### CPU—周波数スケーリング {#cpufrequency-scaling} @@ -79,7 +79,7 @@ grubby --update-kernel="$KERNEL" --args='transparent_hugepage=never' ### ストレージとファイルシステム {#storage-and-file-system} -コア I/O スタック リンクは、ファイル システムレイヤー、ブロック デバイスレイヤー、およびドライバーレイヤーを含めて長くなります。 +コア I/O スタック リンクは、ファイルシステムレイヤー、ブロック デバイスレイヤー、およびドライバーレイヤーを含めて長くなります。 #### I/Oスケジューラ {#io-scheduler} diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index 3de9b35169e20..fd8820948b306 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -1,29 +1,29 @@ --- title: Tune TiKV Thread Pool Performance -summary: 最適なパフォーマンスを得るために TiKV スレッド プールを調整する方法を学習します。 +summary: 最適なパフォーマンスを得るために TiKV スレッドプールを調整する方法を学習します。 --- -# TiKV スレッド プールのパフォーマンスを調整する {#tune-tikv-thread-pool-performance} +# TiKV スレッドプールのパフォーマンスを調整する {#tune-tikv-thread-pool-performance} -このドキュメントでは、TiKV 内部スレッド プールとそのパフォーマンスを調整する方法について説明します。 +このドキュメントでは、TiKV 内部スレッドプールとそのパフォーマンスを調整する方法について説明します。 ## スレッドプールの紹介 {#thread-pool-introduction} TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftstore、StoreWriter、Apply、RocksDB、そしてCPUをあまり消費しないいくつかのスケジュールタスクと検出コンポーネントで構成されています。このドキュメントでは、主に読み取りおよび書き込みリクエストのパフォーマンスに影響を与える、CPUを大量に消費するスレッドプールをいくつか紹介します。 -- gRPC スレッド プール: すべてのネットワーク リクエストを処理し、さまざまなタスク タイプのリクエストをさまざまなスレッド プールに転送します。 +- gRPC スレッドプール: すべてのネットワークリクエストを処理し、さまざまなタスクタイプのリクエストをさまざまなスレッドプールに転送します。 -- スケジューラ スレッド プール: 書き込みトランザクションの競合を検出し、2 フェーズ コミット、悲観的ロック、トランザクション ロールバックなどの要求をキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 +- スケジューラスレッドプール: 書き込みトランザクションの競合を検出し、2 フェーズコミット、悲観的ロック、トランザクション ロールバックなどの要求をキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 -- Raftstoreスレッド プール: +- Raftstoreスレッドプール: - すべてのRaftメッセージと新しいログを追加する提案を処理します。 - Raftログをディスクに書き込みます。[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)の値が`0`の場合、 Raftstoreスレッドはログをディスクに書き込みます。値が`0`でない場合、 RaftstoreスレッドはログをStoreWriterスレッドに送信します。 - 大部分のレプリカのRaftログが整合している場合、 Raftstoreスレッドはログを適用スレッドに送信します。 -- StoreWriter スレッド プール: すべてのRaftログをディスクに書き込み、結果をRaftstoreスレッドに返します。 +- StoreWriter スレッドプール: すべてのRaftログをディスクに書き込み、結果をRaftstoreスレッドに返します。 -- Apply スレッド プール: Raftstoreスレッド プールから送信された送信ログを受信し、それをキー値要求として解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッド プールに書き込み要求が完了したことを通知し、結果をクライアントに返します。 +- Apply スレッドプール: Raftstoreスレッドプールから送信された送信ログを受信し、それをキー値要求として解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッドプールに書き込み要求が完了したことを通知し、結果をクライアントに返します。 - RocksDBスレッドプール：RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。 @@ -40,32 +40,32 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで ## TiKV スレッドプールのパフォーマンスチューニング {#performance-tuning-for-tikv-thread-pools} -- gRPC スレッド プール。 +- gRPC スレッドプール。 v8.5.4以降、gRPCスレッドプールのデフォルトサイズ（ `server.grpc-concurrency`で設定）が固定値の`5`から、CPUコア数に基づいて計算される適応値に変更されました。詳細な計算式については、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)を参照してください。このスレッドプールはコンピューティングオーバーヘッドがほとんどなく、主にネットワークI/Oとデシリアライズリクエストを処理するため、通常はデフォルト設定を調整する必要はありません。 - TiKV で展開されたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`構成項目を`2`に設定することを検討してください。 - - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッド プールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 + - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッドプールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 -- スケジューラ スレッド プール。 +- スケジューラスレッドプール。 - TiKV がマシンの CPU コアの数が 16 以上であることを検出すると、スケジューラ スレッド プールのデフォルト サイズ ( `storage.scheduler-worker-pool-size`に設定) は`8`なります。TiKV がマシンの CPU コアの数が 16 未満であることを検出すると、デフォルト サイズは`4`なります。 + TiKV がマシンの CPU コアの数が 16 以上であることを検出すると、スケジューラスレッドプールのデフォルトサイズ ( `storage.scheduler-worker-pool-size`に設定) は`8`なります。TiKV がマシンの CPU コアの数が 16 未満であることを検出すると、デフォルトサイズは`4`なります。 このスレッドプールは主に、複雑なトランザクションリクエストを単純なキー値の読み取り/書き込みリクエストに変換するために使用されます。ただし、**スケジューラスレッドプール自体は書き込み操作を実行しません**。 - - トランザクションの競合が検出されると、このスレッド プールは競合の結果を事前にクライアントに返します。 - - 競合が検出されない場合、このスレッド プールは書き込み操作を実行するキー値要求をRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 + - トランザクションの競合が検出されると、このスレッドプールは競合の結果を事前にクライアントに返します。 + - 競合が検出されない場合、このスレッドプールは書き込み操作を実行するキー値要求をRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 一般的に、過度のスレッド切り替えを避けるには、スケジューラのスレッドプールの使用率を50%～75%に保つことが最善です。スレッドプールのサイズが`8`の場合、Grafanaでは400%～600%の範囲で`TiKV-Details.Thread CPU.scheduler worker CPU`を維持することをお勧めします。 -- Raftstoreスレッド プール。 +- Raftstoreスレッドプール。 Raftstoreスレッドプールは、TiKV で最も複雑なスレッドプールです。このスレッドプールのデフォルトサイズ（ `raftstore.store-pool-size`で設定）は`2`です。StoreWriter スレッドプールのデフォルトサイズ（ `raftstore.store-io-pool-size`で設定）は`1`です。 - StoreWriterスレッドプールのサイズが0の場合、すべての書き込みリクエストはRaftstoreスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。Raftstoreスレッド数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 - - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッド プールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 + - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッドプールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 - StoreWriterスレッドプールのサイズが0でない場合、すべての書き込みリクエストはStoreWriterスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 @@ -77,7 +77,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - Raftログの増加が他のスレッドプールのCPUオーバーヘッドに与える影響に注意してください。必要に応じて、 Raftstoreスレッド、Applyスレッド、gRPCスレッドの数を増やす必要があります。 -- UnifyReadPool スレッド プール。 +- UnifyReadPool スレッドプール。 UnifyReadPool はすべての読み取りリクエストの処理を担当します。デフォルトのサイズ（ `readpool.unified.max-thread-count`に設定）は、マシンの CPU コア数の 80% です。例えば、マシンの CPU コア数が 16 の場合、デフォルトのスレッドプールサイズは 12 です。アプリケーションのワークロードに応じて CPU 使用率を調整し、スレッドプールサイズの 60% から 90% の範囲に維持することをお勧めします。 @@ -85,7 +85,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで v6.3.0以降、TiKVは現在のCPU使用率に基づいてUnifyReadPoolスレッドプールサイズを自動調整する機能をサポートしています。この機能を有効にするには、 [`readpool.unified.auto-adjust-pool-size = true`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)を設定します。再読み取りが行われ、最大CPU使用率が80%を超えるクラスターについては、スレッドプールサイズを自動調整することをお勧めします。 -- RocksDB スレッド プール。 +- RocksDB スレッドプール。 RocksDBスレッドプールは、RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。通常は設定する必要はありません。 diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index 69932529b1655..0a37dac6dd8df 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -5,7 +5,7 @@ summary: 1 つのリージョンに 2 つの可用性ゾーンを展開するソ # 1つのリージョンに2つのアベイラビリティゾーンを展開 {#two-availability-zones-in-one-region-deployment} -このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1 つのリージョン内の 2 つのアベイラビリティ ゾーン (AZ) のデプロイメント モードについて説明します。 +このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1 つのリージョン内の 2 つのアベイラビリティゾーン (AZ) のデプロイメント モードについて説明します。 このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 @@ -177,7 +177,7 @@ pd-ctl config placement-rules rule-bundle load --out="default.json" pd-ctl config placement-rules rule-bundle save --in="rule.json" ``` -以前の構成にロールバックする必要がある場合は、バックアップ ファイル`default.json`を復元するか、次の JSON ファイルを手動で作成し、この JSON ファイルで現在の構成を上書きします。 +以前の構成にロールバックする必要がある場合は、バックアップファイル`default.json`を復元するか、次の JSON ファイルを手動で作成し、この JSON ファイルで現在の構成を上書きします。 ``` cat default.json @@ -241,7 +241,7 @@ cat default.json - `wait-recover-timeout`は、ネットワークが回復した後に状態`sync-recover`に戻るまでの待機時間です。デフォルト値は0秒です。 - `pause-region-split`は、ステータス`async_wait`および`async`においてリージョン分割操作を一時停止するかどうかを制御します。リージョン分割を一時停止すると、ステータス`sync-recover`でデータを同期する際に DR AZ で一時的な部分的なデータ損失が発生するのを防ぐことができます。デフォルト値は`false`です。 -クラスターの現在のレプリケーション ステータスを確認するには、次の API を使用します。 +クラスターの現在のレプリケーションステータスを確認するには、次の API を使用します。 ```bash curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status @@ -259,10 +259,10 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status #### ステータススイッチ {#status-switch} -クラスターのレプリケーション モードは、次の 3 つのステータス間を自動的かつ適応的に切り替えることができます。 +クラスターのレプリケーションモードは、次の 3 つのステータス間を自動的かつ適応的に切り替えることができます。 -- クラスターが正常な場合、同期レプリケーション モードが有効になり、災害復旧 AZ のデータ整合性が最大限に高まります。 -- 2 つの AZ 間のネットワーク接続に障害が発生した場合、または災害復旧 AZ が故障した場合、事前に設定された保護間隔の後に、クラスターは非同期レプリケーション モードを有効にして、アプリケーションの可用性を確保します。 +- クラスターが正常な場合、同期レプリケーションモードが有効になり、災害復旧 AZ のデータ整合性が最大限に高まります。 +- 2 つの AZ 間のネットワーク接続に障害が発生した場合、または災害復旧 AZ が故障した場合、事前に設定された保護間隔の後に、クラスターは非同期レプリケーションモードを有効にして、アプリケーションの可用性を確保します。 - ネットワークが再接続するか、災害復旧AZが復旧すると、TiKVノードはクラスターに再び参加し、データを段階的にレプリケーションします。最終的に、クラスターは同期レプリケーションモードに切り替わります。 ステータススイッチの詳細は次のとおりです。 @@ -271,7 +271,7 @@ 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} @@ -281,7 +281,7 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status - プライマリ AZ に障害が発生し、Voter レプリカの大部分が失われたものの、災害復旧 AZ に完全なデータが存在する場合、失われたデータは災害復旧 AZ から復旧できます。この場合、専門ツールを用いた手動介入が必要です。復旧ソリューションについては、PingCAP またはコミュニティから[サポートを受ける](/support.md)ことができます。 -- 災害復旧 AZ に障害が発生し、いくつかの Voter レプリカが失われた場合、クラスターは自動的に非同期レプリケーション モードに切り替わります。 +- 災害復旧 AZ に障害が発生し、いくつかの Voter レプリカが失われた場合、クラスターは自動的に非同期レプリケーションモードに切り替わります。 同期レプリケーションモードになっていないクラスタに災害が発生し、 `RPO = 0`でデータリカバリを実行できない場合: diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index 09230da4b4d7e..6e802d07416ab 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -20,11 +20,11 @@ TiDB クラスターをデプロイすると、 TiUP はクラスターの監視 TiDBとの互換性を高めるため、TiDBインストールパッケージに含まれるPrometheusインストールパッケージの使用をお勧めします。TiDBインストールパッケージに含まれるPrometheusのバージョンは固定です。より新しいバージョンのPrometheusをご利用になる場合は、各バージョンの新機能については[Prometheus リリースノート](https://github.com/prometheus/prometheus/releases)を参照し、本番環境に適したバージョンをお選びください。推奨バージョンについては、PingCAPの技術スタッフにご相談ください。 -次のアップグレード手順では、Prometheus Web サイトから必要なバージョンの Prometheus インストール パッケージをダウンロードし、それを使用してTiUPが使用できる Prometheus パッケージを作成する必要があります。 +次のアップグレード手順では、Prometheus Web サイトから必要なバージョンの Prometheus インストールパッケージをダウンロードし、それを使用してTiUPが使用できる Prometheus パッケージを作成する必要があります。 ### ステップ1. Prometheusのウェブサイトから新しいPrometheusインストールパッケージをダウンロードする {#step-1-download-a-new-prometheus-installation-package-from-the-prometheus-website} -[Prometheusのダウンロードページ](https://prometheus.io/download/)から新しいインストール パッケージをダウンロードして解凍します。 +[Prometheusのダウンロードページ](https://prometheus.io/download/)から新しいインストールパッケージをダウンロードして解凍します。 ### ステップ2. TiDBが提供するPrometheusインストールパッケージをダウンロードする {#step-2-download-the-prometheus-installation-package-provided-by-tidb} @@ -68,7 +68,7 @@ tiup cluster patch prometheus-v{new-version}.tar.gz -R prometheus TiDBとの互換性を高めるため、TiDBインストールパッケージに同梱されているGrafanaインストールパッケージのご利用をお勧めします。TiDBインストールパッケージに含まれるGrafanaのバージョンは固定です。より新しいGrafanaバージョンをご利用になる場合は、各バージョンの新機能については[Grafana リリースノート](https://grafana.com/docs/grafana/latest/whatsnew/)を参照し、本番環境に適したバージョンをお選びください。推奨バージョンについては、PingCAPの技術スタッフまでお問い合わせください。 -次のアップグレード手順では、Grafana Web サイトから必要なバージョンの Grafana インストール パッケージをダウンロードし、それを使用してTiUPが使用できる Grafana パッケージを作成する必要があります。 +次のアップグレード手順では、Grafana Web サイトから必要なバージョンの Grafana インストールパッケージをダウンロードし、それを使用してTiUPが使用できる Grafana パッケージを作成する必要があります。 ### ステップ1. Grafanaのウェブサイトから新しいGrafanaインストールパッケージをダウンロードします。 {#step-1-download-a-new-grafana-installation-package-from-the-grafana-website} @@ -120,7 +120,7 @@ TiDBインストールパッケージに含まれるAlertmanagerパッケージ ### ステップ1. PrometheusのWebサイトから新しいAlertmanagerインストールパッケージをダウンロードします。 {#step-1-download-a-new-alertmanager-installation-package-from-the-prometheus-website} -[Prometheusのダウンロードページ](https://prometheus.io/download/#alertmanager)から`alertmanager`インストール パッケージをダウンロードします。 +[Prometheusのダウンロードページ](https://prometheus.io/download/#alertmanager)から`alertmanager`インストールパッケージをダウンロードします。 ### ステップ2. ダウンロードしたインストールパッケージを使用してAlertmanagerをアップグレードする {#step-2-upgrade-alertmanager-using-the-downloaded-installation-package} diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 4bb37a4d1d668..c42a04bb418c0 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -9,7 +9,7 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > **Warning:** > -> 1. TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 CentOS Linux 7 で実行されているクラスターを v8.5 にアップグレードする場合は、クラスターが使用できなくなるリスクを避けるために、必ず TiDB v8.5.1 以降のバージョンを使用してください。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +> 1. TiDB をアップグレードする前に、オペレーティングシステムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 CentOS Linux 7 で実行されているクラスターを v8.5 にアップグレードする場合は、クラスターが使用できなくなるリスクを避けるために、必ず TiDB v8.5.1 以降のバージョンを使用してください。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 > 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスタをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 > 3. アップグレード処理中はDDLステートメントを実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 > 4. TiDB クラスターで DDL ステートメントが実行されている間は、クラスターをアップグレード**しないでください**(通常、 `ADD INDEX`や列型の変更など、時間のかかる DDL ステートメントの場合)。アップグレードの前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスターで DDL ジョブが実行中かどうかを確認することをお勧めします。クラスターで DDL ジョブが実行されている場合は、クラスターをアップグレードする前に、DDL の実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 @@ -45,13 +45,13 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > > 元のクラスターが v7.1.0 以前の場合、v7.2.0 以降にアップグレードすると、 [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)の導入により、統計情報の読み込み時間が大幅に短縮されます。この場合、アップグレード前の`init stats info time`は、アップグレード後の読み込み時間よりも長くなります。 > -> - TiDB のローリング アップグレード期間を短縮したい場合、およびアップグレード中の初期統計情報の欠落による潜在的なパフォーマンスへの影響がクラスターで許容できる場合は、TiUP を使用して対象インスタンスの設定を変更することで、アップグレード前に`performance.force-init-stats` `OFF`に[TiUPを使用して対象インスタンスの設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)。アップグレードの完了後、必要に応じてこの設定を再評価して元に戻すことができます。 +> - TiDB のローリングアップグレード期間を短縮したい場合、およびアップグレード中の初期統計情報の欠落による潜在的なパフォーマンスへの影響がクラスターで許容できる場合は、TiUP を使用して対象インスタンスの設定を変更することで、アップグレード前に`performance.force-init-stats` `OFF`に[TiUPを使用して対象インスタンスの設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)。アップグレードの完了後、必要に応じてこの設定を再評価して元に戻すことができます。 ## アップグレードに関する注意事項 {#upgrade-caveat} - TiDBは現在、アップグレード後にバージョンをダウングレードしたり、以前のバージョンに戻したりすることをサポートしていません。 - TiCDC、 TiFlash、およびその他のコンポーネントのバージョンアップグレードをサポートします。 -- クラスターが TiCDC クラシックアーキテクチャ(v8.1.2 など) を使用している場合は、メジャー バージョン間のアップグレード中に変更フィードを実行し続けないでください。この場合、次の手順を順番に実行します。すべての変更フィードを一時停止し、TiCDC をアップグレードし、TiDB クラスターをアップグレードし、すべての変更フィードを再開します。詳細については、 [以前のバージョンからのアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。 +- クラスターが TiCDC クラシックアーキテクチャ(v8.1.2 など) を使用している場合は、メジャーバージョン間のアップグレード中に変更フィードを実行し続けないでください。この場合、次の手順を順番に実行します。すべての変更フィードを一時停止し、TiCDC をアップグレードし、TiDB クラスターをアップグレードし、すべての変更フィードを再開します。詳細については、 [以前のバージョンからのアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。 - TiFlashをv6.3.0より前のバージョンからv6.3.0以降のバージョンにアップグレードする場合、Linux AMD64アーキテクチャではCPUがAVX2命令セットを、Linux ARM64アーキテクチャではARMv8命令セットアーキテクチャをサポートしている必要があることに注意してください。詳細は[v6.3.0 リリースノート](/releases/release-6.3.0.md#others)の説明を参照してください。 - 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの「互換性の変更点」セクションに従って、クラスタ構成を変更してください。 - クラスターをv5.3より前のバージョンからv5.3以降のバージョンに更新する場合、デフォルトでデプロイされているPrometheusによって生成されるアラートの時刻フォーマットが変更されることに注意してください。このフォーマット変更はPrometheus v2.27.1から導入されています。詳細については、 [Prometheus](https://github.com/prometheus/prometheus/commit/7646cbca328278585be15fa615e22f2a50b47d06)を参照してください。 @@ -156,7 +156,7 @@ tiup update cluster - クラスタDDL: - - [スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレード プロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 + - [スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレードプロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 - な を使用しない場合は、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)[スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して、実行中の DDL ジョブが存在するかどうかを確認することをお勧めします。実行中の DDL ジョブが存在する場合は、アップグレードを実行する前に、ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)ステートメントを使用してキャンセルしてください。 - クラスタのバックアップ：クラスタ内でバックアップまたはリストアタスクが実行中かどうかを確認するには[`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md)コマンドを実行することをお勧めします。実行中の場合は、アップグレードを実行する前にタスクが完了するまでお待ちください。 diff --git a/user-account-management.md b/user-account-management.md index e5fd4c8678483..3783a30b51b5c 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -1,6 +1,6 @@ --- title: TiDB User Account Management -summary: TiDB ユーザー アカウントを管理する方法を学習します。 +summary: TiDB ユーザーアカウントを管理する方法を学習します。 --- # TiDB ユーザーアカウント管理 {#tidb-user-account-management} @@ -131,7 +131,7 @@ SHOW CREATE USER 'admin'@'localhost'; ## ユーザーアカウントを削除する {#remove-user-accounts} -ユーザー アカウントを削除するには、次[`DROP USER`](/sql-statements/sql-statement-drop-user.md)ステートメントを使用します。 +ユーザーアカウントを削除するには、次[`DROP USER`](/sql-statements/sql-statement-drop-user.md)ステートメントを使用します。 ```sql DROP USER 'test'@'localhost'; @@ -174,7 +174,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ 1. 設定ファイルを変更します。 1. tidb-server インスタンスの 1 つが配置されているマシンにログインします。 - 2. TiDB ノードのデプロイメント ディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 + 2. TiDB ノードのデプロイメントディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)を追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 ``` @@ -202,7 +202,7 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ > > TiDBプロセスを開始する前に`skip-grant-table`を設定すると、オペレーティングシステムのユーザーチェックが開始されます。オペレーティングシステムの`root`ユーザーのみがTiDBプロセスを開始できます。 - 1. TiDB ノードのデプロイメント ディレクトリの下の`scripts`ディレクトリを入力します。 + 1. TiDB ノードのデプロイメントディレクトリの下の`scripts`ディレクトリを入力します。 2. Switch to the `root` account of the operating system. 3. ディレクトリ内の`run_tidb.sh`スクリプトをフォアグラウンドで実行します。 4. 新しいターミナル ウィンドウで`root`としてログインし、パスワードを変更します。