diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 67596986cef42..bd242992c5e40 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -25,7 +25,7 @@ - [コードコメントスタイル](https://github.com/pingcap/community/blob/master/contributors/code-comment-style.md) - 図表スタイル: [Figma クイックスタートガイド](https://github.com/pingcap/community/blob/master/contributors/figma-quick-start-guide.md) - 図のスタイルを統一するために、図の描画やデザインには[Figma](https://www.figma.com/)使用することをお勧めします。図を描く必要がある場合は、ガイドを参照し、テンプレートで提供されている図形や色を使用してください。 + 図のスタイルを統一するために、図の描画やデザインには[Figma](https://www.figma.com/)を使用することをお勧めします。図を描く必要がある場合は、ガイドを参照し、テンプレートで提供されている図形や色を使用してください。 ### ドキュメントテンプレートを選択する {#pick-a-doc-template} @@ -59,7 +59,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ ## 貢献方法 {#how-to-contribute} -このリポジトリへのプルリクエストを作成するには、以下の手順を実行してください。コマンドを使いたくない場合は、 [GitHubデスクトップ](https://desktop.github.com/)使用することもできます。こちらの方が簡単です。 +このリポジトリへのプルリクエストを作成するには、以下の手順を実行してください。コマンドを使いたくない場合は、 [GitHubデスクトップ](https://desktop.github.com/)を使用することもできます。こちらの方が簡単です。 > **注記：** > @@ -121,7 +121,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ ### ステップ8: プルリクエストを作成する {#step-8-create-a-pull-request} 1. [https://github.com/$user/docs](https://github.com/$user/docs)でフォークにアクセスします ( `$user` GitHub ID に置き換えます) -2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。5 [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)参照してください。 +2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。5 [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。 これで、PR が正常に送信されました。この PR がマージされると、自動的に TiDB ドキュメントの貢献者になります。 @@ -148,7 +148,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ > **ヒント：** > -> TiDB Cloudによって再利用される TiDB ドキュメントを確認するには、 [TiDB Cloudドキュメントの TOC ファイル](https://github.com/pingcap/docs/blob/release-8.1/TOC-tidb-cloud.md?plain=1)確認してください。 +> TiDB Cloudによって再利用される TiDB ドキュメントを確認するには、 [TiDB Cloudドキュメントの TOC ファイル](https://github.com/pingcap/docs/blob/release-8.1/TOC-tidb-cloud.md?plain=1)を確認してください。 > > - このファイル内のドキュメントのパスが`/tidb-cloud/`で始まる場合、このドキュメントはTiDB Cloud Dedicatedであることを意味します。 > - このファイル内のドキュメントのパスが`/tidb-cloud/`で始まっていない場合は、この TiDB ドキュメントがTiDB Cloudによって再利用されることを意味します。 @@ -193,7 +193,7 @@ TiDB Cloudで再利用される一部の TiDB ドキュメントには、 `Custo [TiDBドキュメント](https://docs.pingcap.com/tidb/stable) 、SQL構文の理解を助けるために、多くのSQL概要図を提供しています。例えば、 `ALTER INDEX`文[ここ](https://docs.pingcap.com/tidb/stable/sql-statement-alter-index#synopsis)の概要図があります。 -これら概要図のソースは[拡張バッカスナウア記法（EBNF）](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form)使用して記述されています。SQL文のEBNFコードを準備する際には、コードを[https://kennytm.github.io/website-docs/dist/](https://kennytm.github.io/website-docs/dist/)にコピーして**「レンダリング」**をクリックすることで、EBNF図を簡単にプレビューできます。 +これら概要図のソースは[拡張バッカスナウア記法（EBNF）](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form)を使用して記述されています。SQL文のEBNFコードを準備する際には、コードを[https://kennytm.github.io/website-docs/dist/](https://kennytm.github.io/website-docs/dist/)にコピーして**「レンダリング」**をクリックすることで、EBNF図を簡単にプレビューできます。 ## 接触 {#contact} diff --git a/ai/guides/auto-embedding.md b/ai/guides/auto-embedding.md index b8ad302fb7dbf..5eb82b7e84799 100644 --- a/ai/guides/auto-embedding.md +++ b/ai/guides/auto-embedding.md @@ -9,11 +9,11 @@ summary: アプリケーションで自動埋め込みを使用する方法を > **注記：** > -> 自動埋め込みの完全な例については、 [自動埋め込みの例](/ai/examples/auto-embedding-with-pytidb.md)参照してください。 +> 自動埋め込みの完全な例については、 [自動埋め込みの例](/ai/examples/auto-embedding-with-pytidb.md)を参照してください。 ## 基本的な使い方 {#basic-usage} -このドキュメントでは、 TiDB Cloudホストの埋め込みモデルをデモに使用しています。サポートされているプロバイダーの全リストについては、 [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md#available-text-embedding-models)参照してください。 +このドキュメントでは、 TiDB Cloudホストの埋め込みモデルをデモに使用しています。サポートされているプロバイダーの全リストについては、 [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md#available-text-embedding-models)を参照してください。 ### ステップ1. 埋め込み関数を定義する {#step-1-define-an-embedding-function} diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md index 63d54b1762e6c..ddab77aaaca1f 100644 --- a/ai/guides/filtering.md +++ b/ai/guides/filtering.md @@ -183,7 +183,7 @@ results = table.query( ).to_list() ``` -`AND` 、 `OR` 、括弧を使用して複数の条件を組み合わせたり、TiDB でサポートされている[SQL演算子](https://docs.pingcap.com/tidbcloud/operators/)使用したりできます。 +`AND` 、 `OR` 、括弧を使用して複数の条件を組み合わせたり、TiDB でサポートされている[SQL演算子](https://docs.pingcap.com/tidbcloud/operators/)を使用したりできます。 > **警告：** > diff --git a/ai/guides/image-search.md b/ai/guides/image-search.md index a9fefceff7299..89e7558c33f1b 100644 --- a/ai/guides/image-search.md +++ b/ai/guides/image-search.md @@ -11,7 +11,7 @@ TiDBは**ベクトル検索**による画像検索を可能にします。自動 > **注記：** > -> 画像検索の完全な例については、 [画像検索の例](/ai/examples/image-search-with-pytidb.md)参照してください。 +> 画像検索の完全な例については、 [画像検索の例](/ai/examples/image-search-with-pytidb.md)を参照してください。 ## 基本的な使い方 {#basic-usage} diff --git a/ai/guides/join-queries.md b/ai/guides/join-queries.md index 484bf97860578..ff9da5a515638 100644 --- a/ai/guides/join-queries.md +++ b/ai/guides/join-queries.md @@ -14,7 +14,7 @@ summary: アプリケーションで複数のテーブル結合を使用する
-すでに[TiDBに接続](/ai/guides/connect.md)使用して`TiDBClient`あると仮定します。 +`TiDBClient`を使用して、すでに[TiDBに接続](/ai/guides/connect.md)していると仮定します。 `documents`テーブルを作成し、いくつかのサンプル データを挿入します。 diff --git a/ai/guides/tables.md b/ai/guides/tables.md index 728d7f58c83c1..ebc341a32035a 100644 --- a/ai/guides/tables.md +++ b/ai/guides/tables.md @@ -15,7 +15,7 @@ TiDBは、関連するデータのコレクションを整理して保存する > **注記：** > -> 完全な動作例については、リポジトリの[基本的な例](https://github.com/pingcap/pytidb/tree/main/examples/basic)参照してください。 +> 完全な動作例については、リポジトリの[基本的な例](https://github.com/pingcap/pytidb/tree/main/examples/basic)を参照してください。 ## テーブルを作成する {#create-a-table} diff --git a/ai/guides/vector-search-full-text-search-python.md b/ai/guides/vector-search-full-text-search-python.md index f4e712afdf70c..86e8482dbed0d 100644 --- a/ai/guides/vector-search-full-text-search-python.md +++ b/ai/guides/vector-search-full-text-search-python.md @@ -20,9 +20,9 @@ TiDBの全文検索機能は、以下の機能を提供します。 > **ヒント：** > -> SQL の使用法については、 [SQLによる全文検索](/ai/guides/vector-search-full-text-search-sql.md)参照してください。 +> SQL の使用法については、 [SQLによる全文検索](/ai/guides/vector-search-full-text-search-sql.md)を参照してください。 > -> AI アプリで全文検索とベクトル検索を併用するには、 [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md)参照してください。 +> AI アプリで全文検索とベクトル検索を併用するには、 [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md)を参照してください。 ## 前提条件 {#prerequisites} @@ -147,7 +147,7 @@ df = ( # 1 2 the quick brown 2 ``` -完全な例については、 [pytidb全文検索デモ](https://github.com/pingcap/pytidb/blob/main/examples/fulltext_search)参照してください。 +完全な例については、 [pytidb全文検索デモ](https://github.com/pingcap/pytidb/blob/main/examples/fulltext_search)を参照してください。 ## 関連項目 {#see-also} diff --git a/ai/guides/vector-search-full-text-search-sql.md b/ai/guides/vector-search-full-text-search-sql.md index 6bd0d4a6a12cd..84ae9a04b64bf 100644 --- a/ai/guides/vector-search-full-text-search-sql.md +++ b/ai/guides/vector-search-full-text-search-sql.md @@ -22,7 +22,7 @@ TiDBの全文検索機能は、以下の機能を提供します。 > > Python の使い方については、 [Pythonによる全文検索](/ai/guides/vector-search-full-text-search-python.md)ご覧ください。 > -> AI アプリで全文検索とベクトル検索を併用するには、 [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md)参照してください。 +> AI アプリで全文検索とベクトル検索を併用するには、 [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md)を参照してください。 ## さあ始めましょう {#get-started} diff --git a/ai/guides/vector-search-hybrid-search.md b/ai/guides/vector-search-hybrid-search.md index 777f3e0a794df..d74d7a29a798e 100644 --- a/ai/guides/vector-search-hybrid-search.md +++ b/ai/guides/vector-search-hybrid-search.md @@ -158,7 +158,7 @@ df = ( 相互ランク融合（RRF）は、複数の検索結果セットにおける文書のランクを活用して検索結果を評価するアルゴリズムです。 -詳細については、 [RRF論文](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)参照してください。 +詳細については、 [RRF論文](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)を参照してください。 `method`メソッドで`"rrf"`パラメーター`.fusion()`有効にします。 diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index ee4a29cad19c7..dab2f82a85b90 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -9,7 +9,7 @@ summary: アプリケーションでベクトル検索を使用する方法を > **注記：** > -> ベクトル検索の完全な例については、 [ベクトル検索の例](/ai/examples/vector-search-with-pytidb.md)参照してください。 +> ベクトル検索の完全な例については、 [ベクトル検索の例](/ai/examples/vector-search-with-pytidb.md)を参照してください。 ## 基本的な使い方 {#basic-usage} @@ -362,7 +362,7 @@ LIMIT 10; > > これを軽減するには、**内部クエリ**の`LIMIT`値 (例: 50) を増やして、より多くの候補を取得し、フィルタリング後に十分な有効な結果が返される可能性を高めることができます。 -サポートされている SQL 演算子については、 TiDB Cloudドキュメントの[オペレーター](https://docs.pingcap.com/tidbcloud/operators/)参照してください。 +サポートされている SQL 演算子については、 TiDB Cloudドキュメントの[オペレーター](https://docs.pingcap.com/tidbcloud/operators/)を参照してください。
@@ -385,7 +385,7 @@ results = ( ) ``` -サポートされているフィルター演算子については、 [フィルタリング](/ai/guides/filtering.md)参照してください。 +サポートされているフィルター演算子については、 [フィルタリング](/ai/guides/filtering.md)を参照してください。
@@ -400,7 +400,7 @@ ORDER BY distance LIMIT 10; ``` -サポートされている SQL 演算子については、 TiDB Cloudドキュメントの[オペレーター](https://docs.pingcap.com/tidbcloud/operators/)参照してください。 +サポートされている SQL 演算子については、 TiDB Cloudドキュメントの[オペレーター](https://docs.pingcap.com/tidbcloud/operators/)を参照してください。
diff --git a/ai/integrations/vector-search-auto-embedding-gemini.md b/ai/integrations/vector-search-auto-embedding-gemini.md index b5e87ef4a1599..edc4cb768c4d3 100644 --- a/ai/integrations/vector-search-auto-embedding-gemini.md +++ b/ai/integrations/vector-search-auto-embedding-gemini.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/vector-search-auto-embedding-gemini/'] # Gemini埋め込み {#gemini-embeddings} -このドキュメントでは、 TiDB Cloudで Gemini 埋め込みモデルを[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)使用する方法、およびテキストクエリによるセマンティック検索を実行する方法について説明します。 +このドキュメントでは、 TiDB Cloudで Gemini 埋め込みモデルを[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)で使用する方法、およびテキストクエリによるセマンティック検索を実行する方法について説明します。 > **注記：** > diff --git a/ai/integrations/vector-search-auto-embedding-huggingface.md b/ai/integrations/vector-search-auto-embedding-huggingface.md index ea9d5caae3f4c..54bc750047a06 100644 --- a/ai/integrations/vector-search-auto-embedding-huggingface.md +++ b/ai/integrations/vector-search-auto-embedding-huggingface.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/vector-search-auto-embedding-huggingface/'] # Hugging Face Embeddings {#hugging-face-embeddings} -このドキュメントでは、 TiDB Cloudで Hugging Face 埋め込みモデルを[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)使用する方法、テキストクエリによる意味検索を実行する方法について説明します。 +このドキュメントでは、 TiDB Cloudで Hugging Face 埋め込みモデルを[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)で使用する方法、テキストクエリによる意味検索を実行する方法について説明します。 > **注記：** > diff --git a/ai/integrations/vector-search-auto-embedding-nvidia-nim.md b/ai/integrations/vector-search-auto-embedding-nvidia-nim.md index 61eebee029325..a95c035954e6c 100644 --- a/ai/integrations/vector-search-auto-embedding-nvidia-nim.md +++ b/ai/integrations/vector-search-auto-embedding-nvidia-nim.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/vector-search-auto-embedding-nvidia-nim/'] # NVIDIA NIM エンベディング {#nvidia-nim-embeddings} -このドキュメントでは、TiDB CloudでNVIDIA NIM埋め込みモデルを[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)使用して、テキストクエリによるセマンティック検索を実行する方法について説明します。 +このドキュメントでは、TiDB CloudでNVIDIA NIM埋め込みモデルを[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)で使用して、テキストクエリによるセマンティック検索を実行する方法について説明します。 > **注記：** > diff --git a/ai/integrations/vector-search-integrate-with-langchain.md b/ai/integrations/vector-search-integrate-with-langchain.md index df874a56e21be..3d9fa3f9f7e6e 100644 --- a/ai/integrations/vector-search-integrate-with-langchain.md +++ b/ai/integrations/vector-search-integrate-with-langchain.md @@ -91,7 +91,7 @@ TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、 5. 環境変数を設定します。 - このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)指定する必要があります。 + このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)を指定する必要があります。 環境変数を設定するには、次のコードを実行してください。接続文字列とOpenAI APIキーの入力を求められます。 @@ -109,7 +109,7 @@ TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、
-このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)指定する必要があります。 +このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)を指定する必要があります。 環境変数を設定するには、次のコードを実行してください。接続文字列とOpenAI APIキーの入力を求められます。 diff --git a/ai/integrations/vector-search-integrate-with-llamaindex.md b/ai/integrations/vector-search-integrate-with-llamaindex.md index 587af827cfe19..380d15ca070f7 100644 --- a/ai/integrations/vector-search-integrate-with-llamaindex.md +++ b/ai/integrations/vector-search-integrate-with-llamaindex.md @@ -90,7 +90,7 @@ TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、 5. 環境変数を設定します。 - このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)指定する必要があります。 + このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)を指定する必要があります。 環境変数を設定するには、次のコードを実行してください。接続文字列とOpenAI APIキーの入力を求められます。 @@ -108,7 +108,7 @@ TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、
-このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、TiDBクラスターの接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)指定する必要があります。 +このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、TiDBクラスターの接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)を指定する必要があります。 環境変数を設定するには、次のコードを実行してください。接続文字列とOpenAI APIキーの入力を求められます。 diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md index 9e3f2fd83ad34..d30ee98fc25df 100644 --- a/ai/quickstart-via-python.md +++ b/ai/quickstart-via-python.md @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de > **注記：** > -> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 > - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)および[{{{ .starter }}}](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -179,7 +179,7 @@ table.bulk_insert([ ## 最近傍を検索 {#search-for-nearest-neighbors} -指定されたクエリの最近傍を検索するには、 `table.search()`メソッドを使用できます。このメソッドは、 デフォルトで[ベクトル検索](/ai/guides/vector-search.md)実行します。 +指定されたクエリの最近傍を検索するには、 `table.search()`メソッドを使用できます。このメソッドは、 デフォルトで[ベクトル検索](/ai/guides/vector-search.md)を実行します。 ```python table.search( diff --git a/ai/quickstart-via-sql.md b/ai/quickstart-via-sql.md index 01cf80778a70e..7af31a82fe3c3 100644 --- a/ai/quickstart-via-sql.md +++ b/ai/quickstart-via-sql.md @@ -17,7 +17,7 @@ TiDB は、MySQL 構文を拡張して[ベクトル検索](/ai/concepts/vector-s > **注記：** > -> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 > - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)および [{{{ .starter }}}](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index 53c41ef9e85de..8bda4500b2d3b 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -59,9 +59,9 @@ 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)参照してください。 +ベクトル検索インデックスの構築と使用の詳細については、 [ベクトル検索インデックス](/ai/reference/vector-search-index.md)を参照してください。 ## 異なる次元のベクトルを保存する {#store-vectors-with-different-dimensions} @@ -81,7 +81,7 @@ INSERT INTO vector_table VALUES (2, '[0.3, 0.5]'); -- 2 dimensions vector, ## 比較 {#comparison} -[比較演算子](/functions-and-operators/operators.md)を使用して、 `=` 、 `!=` 、 `<` 、 `>` 、 `<=` 、 `>=`などのベクトルデータ型を比較できます。ベクトルデータ型の比較演算子と関数の完全なリストについては、 [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md)参照してください。 +[比較演算子](/functions-and-operators/operators.md)を使用して、 `=` 、 `!=` 、 `<` 、 `>` 、 `<=` 、 `>=`などのベクトルデータ型を比較できます。ベクトルデータ型の比較演算子と関数の完全なリストについては、 [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md)を参照してください。 ベクトルデータ型は要素ごとに数値的に比較されます。例: @@ -225,7 +225,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し 1 row in set (0.01 sec) ``` -追加のキャスト関数については、 [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md)参照してください。 +追加のキャスト関数については、 [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md)を参照してください。 ### ベクトルと他のデータ型間のキャスト {#cast-between-vector-other-data-types} @@ -235,7 +235,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し ## 制限 {#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} diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md index d48572e5b3f80..0d5c1e38a64d0 100644 --- a/ai/reference/vector-search-functions-and-operators.md +++ b/ai/reference/vector-search-functions-and-operators.md @@ -46,7 +46,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou | [`+`](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_plus) | ベクトル要素ごとの加算演算子 | | [`-`](https://dev.mysql.com/doc/refman/8.0/en/arithmetic-functions.html#operator_minus) | ベクトル要素ごとの減算演算子 | -ベクトル演算の仕組みの詳細については、 [ベクトルデータ型 | 算術](/ai/reference/vector-search-data-types.md#arithmetic)参照してください。 +ベクトル演算の仕組みの詳細については、 [ベクトルデータ型 | 算術](/ai/reference/vector-search-data-types.md#arithmetic)を参照してください。 **集計（GROUP BY）関数：** @@ -78,7 +78,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou | [`!=` 、 `<>`](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) | 値が値のセット内にないかどうかを確認する | -ベクトルの比較方法の詳細については、 [ベクトルデータ型 | 比較](/ai/reference/vector-search-data-types.md#comparison)参照してください。 +ベクトルの比較方法の詳細については、 [ベクトルデータ型 | 比較](/ai/reference/vector-search-data-types.md#comparison)を参照してください。 **制御フロー関数:** @@ -96,7 +96,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou | [`CAST()`](https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html#function_cast) | 値を文字列またはベクトルとしてキャストする | | [`CONVERT()`](https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html#function_convert) | 値を文字列としてキャストする | -`CAST()`使用方法の詳細については、 [ベクトルデータ型 | キャスト](/ai/reference/vector-search-data-types.md#cast)参照してください。 +`CAST()`使用方法の詳細については、 [ベクトルデータ型 | キャスト](/ai/reference/vector-search-data-types.md#cast)を参照してください。 ## 完全な参考文献 {#full-references} diff --git a/ai/reference/vector-search-improve-performance.md b/ai/reference/vector-search-improve-performance.md index 2354aef96b905..596016b4be10d 100644 --- a/ai/reference/vector-search-improve-performance.md +++ b/ai/reference/vector-search-improve-performance.md @@ -19,7 +19,7 @@ TiDB Vector Searchを使用すると、画像、ドキュメント、その他 ## ベクトルインデックスが完全に構築されていることを確認する {#ensure-vector-indexes-are-fully-built} -大量のベクトルデータを挿入すると、一部のデータがデルタレイヤーに保持され、永続化を待機している場合があります。TiDBは、データが永続化された後、このようなデータに対してベクトルインデックスを構築します。すべてのベクトルデータがインデックス化されるまで、ベクトル検索のパフォーマンスは最適ではありません。インデックス構築の進行状況を確認するには、 [インデックス構築の進行状況を確認する](/ai/reference/vector-search-index.md#view-index-build-progress)参照してください。 +大量のベクトルデータを挿入すると、一部のデータがデルタレイヤーに保持され、永続化を待機している場合があります。TiDBは、データが永続化された後、このようなデータに対してベクトルインデックスを構築します。すべてのベクトルデータがインデックス化されるまで、ベクトル検索のパフォーマンスは最適ではありません。インデックス構築の進行状況を確認するには、 [インデックス構築の進行状況を確認する](/ai/reference/vector-search-index.md#view-index-build-progress)を参照してください。 ## ベクトルの次元を減らすか埋め込みを短くする {#reduce-vector-dimensions-or-shorten-embeddings} diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index e5288a27d59b2..0783a924be323 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -142,7 +142,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; ALTER TABLE COMPACT; ``` - 詳細については[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)参照してください。 + 詳細については[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)を参照してください。 さらに、 `ADMIN SHOW DDL JOBS;`実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全に正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 diff --git a/ai/reference/vector-search-limitations.md b/ai/reference/vector-search-limitations.md index ef62421c2b7bd..84c0f812e6fe9 100644 --- a/ai/reference/vector-search-limitations.md +++ b/ai/reference/vector-search-limitations.md @@ -25,7 +25,7 @@ aliases: ['/ja/tidb/stable/vector-search-limitations/','/ja/tidb/dev/vector-sear ## ベクトルインデックスの制限 {#vector-index-limitations} -[ベクトル検索制限](/ai/reference/vector-search-index.md#restrictions)参照してください。 +[ベクトル検索制限](/ai/reference/vector-search-index.md#restrictions)を参照してください。 ## TiDBツールとの互換性 {#compatibility-with-tidb-tools} diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..d90e6beb205e3 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -406,14 +406,14 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - 低速TiKVノードがあります。1 `raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)参照してください。 + 低速TiKVノードがあります。1 `raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)を参照してください。 - 解決： - [**TiKV詳細**> **PD**ダッシュボード](/grafana-tikv-dashboard.md#pd)監視し、ストア低速スコアのメトリックを確認します。メトリック値が80を超えるノードを特定し、低速ノードとして検出します。 - [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - レイテンシーのタイムアウト制限を増やすには、 [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)構成項目を大きな値に設定します。 - - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)参照してください。 + - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。 ## TiKVアラートルール {#tikv-alert-rules} @@ -449,7 +449,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`実行して、GC リーダーに対応する`tidb-server`を見つけます。 2. `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。 - 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 + 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)を取得してください。 ### 重大レベルのアラート {#critical-level-alerts} @@ -539,7 +539,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. [**TiKV詳細**> **Raft提案**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)監視し、アラート対象の TiKV ノードの**サーバーあたりの 99% Propose 待機期間**メトリックが他の TiKV ノードと比べて大幅に高いかどうかを確認します。高い場合、この TiKV ノードにホットスポットが存在することを示し、ホットスポットのスケジューリングが適切に機能しているかどうかを確認する必要があります。 2. [**TiKV詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - 3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)参照してください。 + 3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。 #### `TiKV_coprocessor_request_wait_seconds` {#tikv-coprocessor-request-wait-seconds} @@ -772,11 +772,11 @@ 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} diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index 2d39a6a325cdf..cfead2b7bafa3 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -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 @@ -236,7 +236,7 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a; 4. `select b from t where c=3` : プレフィックス条件がないと、マルチカラムインデックスは使用できません。そのため、 `IndexFullScan`使用されます。 5. ... -上記の例は、データ読み取りに使用される演算子です。その他の演算子については、 [TiDB実行プランを理解する](/explain-overview.md)参照してください。 +上記の例は、データ読み取りに使用される演算子です。その他の演算子については、 [TiDB実行プランを理解する](/explain-overview.md)を参照してください。 さらに、 [SQLチューニングの概要](/sql-tuning-overview.md)読むことで、TiDB オプティマイザーをより深く理解し、実行プランが妥当かどうかを判断するのに役立ちます。 diff --git a/api/dm-api-overview.md b/api/dm-api-overview.md index 58c77abadd699..6d0fa9b7e0996 100644 --- a/api/dm-api-overview.md +++ b/api/dm-api-overview.md @@ -15,4 +15,4 @@ DM API を使用して、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)参照してください。 +リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [OpenAPI を使用して DM クラスターを管理](/dm/dm-open-api.md)を参照してください。 diff --git a/api/monitoring-api-overview.md b/api/monitoring-api-overview.md index 1c8b5271469e5..7e44d92a4cd14 100644 --- a/api/monitoring-api-overview.md +++ b/api/monitoring-api-overview.md @@ -12,4 +12,4 @@ TiDB モニタリングフレームワークは、 [Prometheus](https://promethe - [ステータスインターフェース](/tidb-monitoring-api.md#use-the-status-interface) : 現在の TiDBサーバーの[実行ステータス](/tidb-monitoring-api.md#running-status)とテーブルの[ストレージ情報](/tidb-monitoring-api.md#storage-information)を監視します。 - [メトリクスインターフェース](/tidb-monitoring-api.md#use-the-metrics-interface) : コンポーネント内のさまざまな操作に関する詳細情報を取得し、Grafana を使用してこれらのメトリックを表示します。 -リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiDB モニタリング API](/tidb-monitoring-api.md)参照してください。 +リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiDB モニタリング API](/tidb-monitoring-api.md)を参照してください。 diff --git a/api/ticdc-api-overview.md b/api/ticdc-api-overview.md index df62e567ec5b3..e169549a0e01e 100644 --- a/api/ticdc-api-overview.md +++ b/api/ticdc-api-overview.md @@ -16,4 +16,4 @@ TiCDC は、TiCDC クラスターのクエリと操作用に次の 2 つのバ > > TiCDC OpenAPI v1は将来削除される予定です。TiCDC OpenAPI v2のご利用をお勧めします。 -リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiCDC オープンAPI v1](/ticdc/ticdc-open-api.md)および[TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)参照してください。 +リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiCDC オープンAPI v1](/ticdc/ticdc-open-api.md)および[TiCDC オープンAPI v2](/ticdc/ticdc-open-api-v2.md)を参照してください。 diff --git a/api/tidb-operator-api-overview.md b/api/tidb-operator-api-overview.md index f10dd8e69b8b7..e0709dcf43a03 100644 --- a/api/tidb-operator-api-overview.md +++ b/api/tidb-operator-api-overview.md @@ -17,4 +17,4 @@ Kubernetes 上で TiDB クラスターを管理するには、次のTiDB Operato - [Tidbイニシャライザー](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbinitializer) - [Tidbモニター](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbmonitor) -詳細については[TiDB OperatorAPI ドキュメント](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md)参照してください。 +詳細については[TiDB OperatorAPI ドキュメント](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md)を参照してください。 diff --git a/api/tiproxy-api-overview.md b/api/tiproxy-api-overview.md index 19bd99092c84b..abf680d85133c 100644 --- a/api/tiproxy-api-overview.md +++ b/api/tiproxy-api-overview.md @@ -16,4 +16,4 @@ TiProxy API を使用して、TiProxy クラスターで次の操作を実行で - [TiProxy のヘルスステータスを取得する](/tiproxy/tiproxy-api.md#get-tiproxy-health-status) - [TiProxy監視データを取得する](/tiproxy/tiproxy-api.md#get-tiproxy-monitoring-data) -リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiProxy API](/tiproxy/tiproxy-api.md)参照してください。 +リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiProxy API](/tiproxy/tiproxy-api.md)を参照してください。 diff --git a/auto-increment.md b/auto-increment.md index 32ddb3b37a250..98f052ac6305f 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -11,7 +11,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。 > **注記：** > -> `AUTO_INCREMENT`属性は本番環境でホットスポットを引き起こす可能性があります。詳細は[ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)使用することをお勧めします。 +> `AUTO_INCREMENT`属性は本番環境でホットスポットを引き起こす可能性があります。詳細は[ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)を参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)を使用することをお勧めします。 @@ -19,7 +19,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。 > **注記：** > -> `AUTO_INCREMENT`属性は本番環境でホットスポットを引き起こす可能性があります。詳細は[ホットスポットの問題のトラブルシューティング](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#handle-auto-increment-primary-key-hotspot-tables-using-auto_random)参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)使用することをお勧めします。 +> `AUTO_INCREMENT`属性は本番環境でホットスポットを引き起こす可能性があります。詳細は[ホットスポットの問題のトラブルシューティング](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#handle-auto-increment-primary-key-hotspot-tables-using-auto_random)を参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)を使用することをお勧めします。 @@ -343,7 +343,7 @@ SELECT * FROM t; -- [データ移行（DM）](/dm/dm-overview.md)使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流の TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、AUTO_INCREMENT列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 +- [データ移行（DM）](/dm/dm-overview.md)を使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流の TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、AUTO_INCREMENT列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 - TiDB Lightningはデータのインポートを完了すると、AUTO_INCREMENT IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタのAUTO_INCREMENT IDキャッシュを手動でクリアする必要があります。 @@ -354,7 +354,7 @@ SELECT * FROM t; -- アプリケーションで明示的なIDの挿入と暗黙的なIDの割り当ての両方を行う場合、将来暗黙的に割り当てられたIDと以前に明示的に挿入されたIDとの競合を回避するために、AUTO_INCREMENT IDキャッシュをクリアする必要があります。競合が発生すると、主キーの競合エラーが発生する可能性があります。詳細については、 [ユニークさ](/auto-increment.md#uniqueness)参照してください。 +- アプリケーションで明示的なIDの挿入と暗黙的なIDの割り当ての両方を行う場合、将来暗黙的に割り当てられたIDと以前に明示的に挿入されたIDとの競合を回避するために、AUTO_INCREMENT IDキャッシュをクリアする必要があります。競合が発生すると、主キーの競合エラーが発生する可能性があります。詳細については、 [ユニークさ](/auto-increment.md#uniqueness)を参照してください。 クラスター内のすべてのTiDBノードのAUTO_INCREMENT IDキャッシュをクリアするには、 `ALTER TABLE`ステートメントを`AUTO_INCREMENT = 0`とともに実行します。例: diff --git a/auto-random.md b/auto-random.md index 61cc19bf30eb4..faf47e55caaaf 100644 --- a/auto-random.md +++ b/auto-random.md @@ -11,7 +11,7 @@ summary: AUTO_RANDOM 属性について学習します。 -TiDB で同時書き込みの多いワークロードを処理する方法の詳細については、 [高同時書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)参照してください。 +TiDB で同時書き込みの多いワークロードを処理する方法の詳細については、 [高同時書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)を参照してください。 @@ -167,7 +167,7 @@ TiDBは、 `AUTO_INCREMENT`列と同様に、 `AUTO_RANDOM`列にも暗黙的に 複数のTiDBサーバーインスタンスが存在する環境で、 `AUTO_RANDOM`列に明示的な値を持つデータを挿入すると、 `AUTO_INCREMENT`列と同様に、IDの衝突が発生する可能性があります。明示的な挿入で使用されたID値が、TiDBが自動生成に使用する内部カウンターと競合すると、エラーが発生する可能性があります。 -衝突が発生する仕組みは以下のとおりです。 `AUTO_RANDOM` IDはランダムビットとAUTO_INCREMENT部分で構成されています。TiDBはこのAUTO_INCREMENT部分に内部カウンタを使用します。AUTO_INCREMENT部分がカウンタの次の値と一致するIDを明示的に挿入すると、TiDBが後で同じIDを自動生成しようとする際に、重複キーエラーが発生する可能性があります。詳細については、 [AUTO_INCREMENT 一意性](/auto-increment.md#uniqueness)参照してください。 +衝突が発生する仕組みは以下のとおりです。 `AUTO_RANDOM` IDはランダムビットとAUTO_INCREMENT部分で構成されています。TiDBはこのAUTO_INCREMENT部分に内部カウンタを使用します。AUTO_INCREMENT部分がカウンタの次の値と一致するIDを明示的に挿入すると、TiDBが後で同じIDを自動生成しようとする際に、重複キーエラーが発生する可能性があります。詳細については、 [AUTO_INCREMENT 一意性](/auto-increment.md#uniqueness)を参照してください。 TiDBインスタンスが1つの場合、ノードは明示的な挿入を処理する際に内部カウンターを自動的に調整し、将来の衝突を防ぐため、この問題は発生しません。一方、複数のTiDBノードがある場合、各ノードは独自のIDキャッシュを保持しており、明示的な挿入後に衝突を防ぐには、このキャッシュをクリアする必要があります。これらの未割り当てのキャッシュIDをクリアして衝突の可能性を回避するには、次の2つの方法があります。 diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index bc1c5bca8d2ce..0a6eacb06d05f 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -92,7 +92,7 @@ LIMIT DumplingはデフォルトでデータをSQLファイルにエクスポートします。 `--filetype`オプションを追加することで、別のファイル形式を指定できます。 - Dumplingのその他の構成については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)参照してください。 + Dumplingのその他の構成については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)を参照してください。 2. エクスポートが完了すると、ディレクトリ`s3://my-bucket/sql-backup`でバックアップファイルを確認できます。 diff --git a/basic-features.md b/basic-features.md index 7c0d4ab781ede..29a08903617b1 100644 --- a/basic-features.md +++ b/basic-features.md @@ -11,7 +11,7 @@ summary: TiDBの機能概要について学びましょう。 > **注記：** > -> PingCAP は、DMR バージョンのパッチ リリースを提供しません。バグは将来のリリースで修正される予定です。一般的な用途には、[最新のLTSバージョン](https://docs.pingcap.com/tidb/stable)使用することをお勧めします。 +> PingCAP は、DMR バージョンのパッチ リリースを提供しません。バグは将来のリリースで修正される予定です。一般的な用途には、[最新のLTSバージョン](https://docs.pingcap.com/tidb/stable)を使用することをお勧めします。 > > 下記の表の略語は、それぞれ以下の意味を持ちます。 > @@ -317,7 +317,7 @@ summary: TiDBの機能概要について学びましょう。 [^1]: TiDBはlatin1をutf8のサブセットとして誤って扱っています。詳細は[TiDB #18955](https://github.com/pingcap/tidb/issues/18955)を参照してください。 -[^2]: バージョン6.5.0以降、 [`tidb_allow_function_for_expression_index`](/system-variables.md#tidb_allow_function_for_expression_index-new-in-v520)システム変数にリストされている関数に対して作成された式インデックスはテスト済みであり、本番環境で使用できます。今後のリリースでは、さらに多くの関数がサポートされる予定です。この変数にリストされていない関数については、対応する式インデックスは本番環境での使用は推奨されません。詳細については、 [発現指数](/sql-statements/sql-statement-create-index.md#expression-index)参照してください。 +[^2]: バージョン6.5.0以降、 [`tidb_allow_function_for_expression_index`](/system-variables.md#tidb_allow_function_for_expression_index-new-in-v520)システム変数にリストされている関数に対して作成された式インデックスはテスト済みであり、本番環境で使用できます。今後のリリースでは、さらに多くの関数がサポートされる予定です。この変数にリストされていない関数については、対応する式インデックスは本番環境での使用は推奨されません。詳細については、 [発現指数](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 [^3]: サポートされている SQL ステートメントの完全なリストについては[ステートメント参照](/sql-statements/sql-statement-select.md)てください。 diff --git a/basic-sql-operations.md b/basic-sql-operations.md index 08e4f82996f71..f46358ec93bfe 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -5,7 +5,7 @@ summary: TiDBデータベースの基本的なSQL文について学びましょ # TiDBでSQLを試す {#explore-sql-with-tidb} -TiDBはMySQLと互換性があり、ほとんどの場合、MySQLのステートメントを直接使用できます。サポートされていない機能については、 [MySQLとの互換性](/mysql-compatibility.md#unsupported-features)参照してください。 +TiDBはMySQLと互換性があり、ほとんどの場合、MySQLのステートメントを直接使用できます。サポートされていない機能については、 [MySQLとの互換性](/mysql-compatibility.md#unsupported-features)を参照してください。 diff --git a/batch-processing.md b/batch-processing.md index 3da81974e746a..3b8c9eae37bca 100644 --- a/batch-processing.md +++ b/batch-processing.md @@ -47,7 +47,7 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` - データの移行や復旧などのデータインポートシナリオに適しています。該当する場合は、 TiDB Lightningではなく`IMPORT INTO`使用することをお勧めします。 -詳細については[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)参照してください。 +詳細については[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を参照してください。 ## データの挿入、更新、削除 {#data-inserts-updates-and-deletions} @@ -69,7 +69,7 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` - 大量のデータの挿入、更新、削除などの一般的なバッチ処理タスクに適しています。 -詳細については[パイプラインDML](/pipelined-dml.md)参照してください。 +詳細については[パイプラインDML](/pipelined-dml.md)を参照してください。 ### 非トランザクションDMLステートメント {#non-transactional-dml-statements} @@ -91,7 +91,7 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` - 大量のデータの挿入、更新、削除を伴うシナリオに適しています。ただし、その制限のため、パイプラインDMLが適用できない場合にのみ、非トランザクションDMLを検討することをお勧めします。 -詳細については[非トランザクションDML](/non-transactional-dml.md)参照してください。 +詳細については[非トランザクションDML](/non-transactional-dml.md)を参照してください。 ### 非推奨のbatch-dml機能 {#deprecated-batch-dml-feature} diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index f1cc155bef27b..7b168e690fe27 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -7,7 +7,7 @@ summary: TiDB で CH-benCHmark テストを実行する方法を学びます。 このドキュメントでは、CH-benCHmark を使用して TiDB をテストする方法について説明します。 -CH-benCHmarkは、テスト[TPC-C](http://www.tpc.org/tpcc/)とテスト[TPC-H](http://www.tpc.org/tpch/)両方を含む混合ワークロードです。HTAPシステムのテストで最も一般的なワークロードです。詳細については、 [混合ワークロードCH-benCHmark](https://dl.acm.org/doi/10.1145/1988842.1988850)参照してください。 +CH-benCHmarkは、テスト[TPC-C](http://www.tpc.org/tpcc/)とテスト[TPC-H](http://www.tpc.org/tpch/)両方を含む混合ワークロードです。HTAPシステムのテストで最も一般的なワークロードです。詳細については、 [混合ワークロードCH-benCHmark](https://dl.acm.org/doi/10.1145/1988842.1988850)を参照してください。 CH-benCHmarkテストを実行する前に、まずTiDBのHTAPコンポーネントである[TiFlash](/tiflash/tiflash-overview.md)導入する必要があります。TiFlashと[TiFlashレプリカを作成する](#create-tiflash-replicas)TiFlashすると、TiKVがTPC-Cオンライントランザクションの最新データをTiFlashにリアルタイムで複製し、TiDBオプティマイザーがTPC-HワークロードからTiFlashのMPPエンジンにOLAPクエリを自動的にプッシュダウンして効率的に実行します。 @@ -17,7 +17,7 @@ CH-benCHmarkテストを実行する前に、まずTiDBのHTAPコンポーネン tiup install bench ``` -TiUP Benchコンポーネントの詳細な使用方法については、 [TiUPベンチ](/tiup/tiup-bench.md)参照してください。 +TiUP Benchコンポーネントの詳細な使用方法については、 [TiUPベンチ](/tiup/tiup-bench.md)を参照してください。 ## データを読み込む {#load-data} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 8ef9aca7cbb11..dee6a651765e1 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -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} @@ -111,7 +111,7 @@ MySQL クライアントを再起動し、次の SQL ステートメントを実 create database sbtest; ``` -Sysbench スクリプトがインデックスを作成する順序を調整します。Sysbench は「テーブルの作成 -> データの挿入 -> インデックスの作成」という順序でデータをインポートするため、TiDB によるデータのインポートに時間がかかります。ユーザーはこの順序を調整することで、データのインポートを高速化できます。Sysbench バージョン[1.0.20](https://github.com/akopytov/sysbench/tree/1.0.20)使用している場合、順序は次の 2 つの方法で調整できます。 +Sysbench スクリプトがインデックスを作成する順序を調整します。Sysbench は「テーブルの作成 -> データの挿入 -> インデックスの作成」という順序でデータをインポートするため、TiDB によるデータのインポートに時間がかかります。ユーザーはこの順序を調整することで、データのインポートを高速化できます。Sysbench バージョン[1.0.20](https://github.com/akopytov/sysbench/tree/1.0.20)を使用している場合、順序は次の 2 つの方法で調整できます。 - TiDB 用に変更された[oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench/sysbench-patch/oltp_common.lua)ファイルをダウンロードし、 `/usr/share/sysbench/oltp_common.lua`ファイルをそれで上書きします。 - `/usr/share/sysbench/oltp_common.lua`で、行[235-240](https://github.com/akopytov/sysbench/blob/1.0.20/src/lua/oltp_common.lua#L235-L240)行 198 のすぐ後ろに移動します。 diff --git a/benchmark/benchmark-tidb-using-tpcc.md b/benchmark/benchmark-tidb-using-tpcc.md index 69eb092120726..c0eaeffa898c5 100644 --- a/benchmark/benchmark-tidb-using-tpcc.md +++ b/benchmark/benchmark-tidb-using-tpcc.md @@ -35,7 +35,7 @@ TPC-Cは、tpmC（1分あたりのトランザクション数）を使用して tiup install bench ``` -TiUP Benchコンポーネントの詳細な使用方法については、 [TiUPベンチ](/tiup/tiup-bench.md)参照してください。 +TiUP Benchコンポーネントの詳細な使用方法については、 [TiUPベンチ](/tiup/tiup-bench.md)を参照してください。 172.16.5.140 と 172.16.5.141 にある 2 つの TiDB サーバーを含む TiDB クラスターを展開し、両方のサーバーがポート 4000 でリッスンしているとします。次の手順で TPC-C テストを実行できます。 diff --git a/benchmark/v4.0-performance-benchmarking-with-tpch.md b/benchmark/v4.0-performance-benchmarking-with-tpch.md index a2a8c0ea35930..b7596f2e695c3 100644 --- a/benchmark/v4.0-performance-benchmarking-with-tpch.md +++ b/benchmark/v4.0-performance-benchmarking-with-tpch.md @@ -104,7 +104,7 @@ set global tidb_index_lookup_join_concurrency = 16; ### テストプロセス {#test-process} -1. [TiUP](/tiup/tiup-overview.md#tiup-overview)使用して TiDB v4.0 および v3.0をデプロイ。 +1. [TiUP](/tiup/tiup-overview.md#tiup-overview)を使用して TiDB v4.0 および v3.0をデプロイ。 2. TiUPのベンチ ツールを使用して、スケール係数 10 で TPC-H データをインポートします。 diff --git a/best-practices-for-security-configuration.md b/best-practices-for-security-configuration.md index 4d327c9211eab..583b74237e0db 100644 --- a/best-practices-for-security-configuration.md +++ b/best-practices-for-security-configuration.md @@ -121,6 +121,6 @@ TiDB Dashboardにアクセスする必要がある場合は、 [リバースプ ## サードパーティのMySQL脆弱性スキャナーからの誤検知を解決する {#resolving-false-positives-from-third-party-mysql-vulnerability-scanners} -ほとんどの脆弱性スキャナーは、MySQLの脆弱性をバージョン情報に基づいて検出します。TiDBはMySQLプロトコルと互換性がありますが、MySQL自体は互換性がないため、バージョンベースの脆弱性スキャンは誤検知につながる可能性があります。脆弱性スキャンは原則に基づく評価に重点を置くことをお勧めします。コンプライアンススキャンツールが特定のMySQLバージョンを要求する場合は、 [サーバーのバージョン番号を変更する](/faq/high-reliability-faq.md#does-tidb-support-modifying-the-mysql-version-string-of-the-server-to-a-specific-one-that-is-required-by-the-security-vulnerability-scanning-tool)使用して要件を満たすことができます。 +ほとんどの脆弱性スキャナーは、MySQLの脆弱性をバージョン情報に基づいて検出します。TiDBはMySQLプロトコルと互換性がありますが、MySQL自体は互換性がないため、バージョンベースの脆弱性スキャンは誤検知につながる可能性があります。脆弱性スキャンは原則に基づく評価に重点を置くことをお勧めします。コンプライアンススキャンツールが特定のMySQLバージョンを要求する場合は、 [サーバーのバージョン番号を変更する](/faq/high-reliability-faq.md#does-tidb-support-modifying-the-mysql-version-string-of-the-server-to-a-specific-one-that-is-required-by-the-security-vulnerability-scanning-tool)を使用して要件を満たすことができます。 サーバーのバージョン番号を変更することで、脆弱性スキャナーによる誤検知を回避できます。[`server-version`](/tidb-configuration-file.md#server-version)値は、TiDB ノードが現在の TiDB バージョンを確認するために使用されます。TiDB クラスターをアップグレードする前に、予期しない動作を回避するために、 `server-version`値が空であるか、実際の TiDB バージョンであることを確認してください。 diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index 0ba7bb0cbab62..ded3745f7c5dd 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -32,7 +32,7 @@ blob-file-compression = "zstd" > **注記：** > -> Titanを有効にすると、主キーの範囲スキャンのパフォーマンスが若干低下する可能性があります。詳細については、 [`min-blob-size`がパフォーマンスに与える影響](/storage-engine/titan-overview.md#impact-of-min-blob-size-on-performance)参照してください。 +> Titanを有効にすると、主キーの範囲スキャンのパフォーマンスが若干低下する可能性があります。詳細については、 [`min-blob-size`がパフォーマンスに与える影響](/storage-engine/titan-overview.md#impact-of-min-blob-size-on-performance)を参照してください。 ### すべての圧縮レベルを上げる {#increase-all-the-compression-levels} @@ -97,7 +97,7 @@ AWS は、20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/)ボリュー ### 例 2: Azure で TPC-C/Sysbench ワークロードを実行する {#example-2-run-tpc-c-sysbench-workload-on-azure} -Azure 上のRaft Engineに専用の 32 GB [Ultra Disk](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disks)使用すると、次の改善が見られます。 +Azure 上のRaft Engineに専用の 32 GB [Ultra Disk](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disks)を使用すると、次の改善が見られます。 - Sysbench `oltp_read_write`ワークロード: QPS が 17.8% 増加し、平均レイテンシーが 15.6% 減少しました。 - TPC-C ワークロード: QPS が 27.6% 増加し、平均レイテンシーが 23.1% 減少しました。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 2cb133a138aa4..4ec45d70f2422 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -123,7 +123,7 @@ TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限 - DDL 所有者は常に先入先出方式で DDL ジョブを処理します。 - DDL 所有者は、一度に同じタイプ (論理または物理) の DDL タスクを 1 つだけ実行できます。これは比較的厳格であり、ユーザー エクスペリエンスに影響します。 -これらの制限により、意図しないDDLブロッキング動作が発生する可能性があります。詳細については、 [SQL FAQ - DDL実行](https://docs.pingcap.com/tidb/stable/sql-faq#ddl-execution)参照してください。 +これらの制限により、意図しないDDLブロッキング動作が発生する可能性があります。詳細については、 [SQL FAQ - DDL実行](https://docs.pingcap.com/tidb/stable/sql-faq#ddl-execution)を参照してください。
@@ -165,11 +165,11 @@ TiDBがインデックスを追加する際、データのバックフィルフ ## DDL関連コマンド {#ddl-related-commands} -- `ADMIN SHOW DDL` : TiDB DDL操作のステータス（現在のスキーマバージョン番号、DDL所有者のDDL IDとアドレス、実行中のDDLタスクとSQL、現在のTiDBインスタンスのDDL IDなど）を表示するために使用されます。詳細については、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl)参照してください。 +- `ADMIN SHOW DDL` : TiDB DDL操作のステータス（現在のスキーマバージョン番号、DDL所有者のDDL IDとアドレス、実行中のDDLタスクとSQL、現在のTiDBインスタンスのDDL IDなど）を表示するために使用されます。詳細については、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl)を参照してください。 -- `ADMIN SHOW DDL JOBS` : クラスター環境で実行されているDDLタスクの詳細なステータスを表示するために使用されます。詳細については、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-jobs)参照してください。 +- `ADMIN SHOW DDL JOBS` : クラスター環境で実行されているDDLタスクの詳細なステータスを表示するために使用されます。詳細については、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-jobs)を参照してください。 -- `ADMIN SHOW DDL JOB QUERIES job_id [, job_id]` : `job_id`に対応するDDLタスクの元のSQL文を表示するために使用されます。詳細については[`ADMIN SHOW DDL JOB QUERIES`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-job-queries)参照してください。 +- `ADMIN SHOW DDL JOB QUERIES job_id [, job_id]` : `job_id`に対応するDDLタスクの元のSQL文を表示するために使用されます。詳細については[`ADMIN SHOW DDL JOB QUERIES`](/sql-statements/sql-statement-admin-show-ddl.md#admin-show-ddl-job-queries)を参照してください。 - `ADMIN CANCEL DDL JOBS job_id, [, job_id]` : 送信されたが完了していないDDLタスクをキャンセルするために使用されます。キャンセルが完了すると、DDLタスクを実行するSQL文は`ERROR 8214 (HY000): Cancelled DDL job`エラーを返します。 @@ -190,4 +190,4 @@ TiDBがインデックスを追加する際、データのバックフィルフ ## よくある質問 {#common-questions} -DDL 実行に関するよくある質問については、 [SQL FAQ - DDL 実行](https://docs.pingcap.com/tidb/stable/sql-faq)参照してください。 +DDL 実行に関するよくある質問については、 [SQL FAQ - DDL 実行](https://docs.pingcap.com/tidb/stable/sql-faq)を参照してください。 diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 3e00a7a3deb1e..4648c01d86bc8 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -18,7 +18,7 @@ aliases: ['/ja/docs/dev/best-practices/haproxy-best-practices/','/ja/docs/dev/re HAProxyは、C言語で書かれた無料のオープンソースソフトウェアで、TCPおよびHTTPベースのアプリケーション向けの高可用性ロードバランサおよびプロキシサーバーを提供します。CPUとメモリを高速かつ効率的に使用できるため、GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter、Tuenti、AWS（Amazon Web Services）など、多くの著名なウェブサイトで広く利用されています。 -HAProxyは、LinuxカーネルのコアコントリビューターであるWilly Tarreauによって2000年に作成されました。彼は現在もプロジェクトのメンテナンスを担当し、オープンソースコミュニティに無料のソフトウェアアップデートを提供しています。このガイドでは、HAProxy [2.6](https://www.haproxy.com/blog/announcing-haproxy-2-6/)使用しています。最新の安定版の使用を推奨します。詳細は[HAProxyのリリースバージョン](http://www.haproxy.org/)ご覧ください。 +HAProxyは、LinuxカーネルのコアコントリビューターであるWilly Tarreauによって2000年に作成されました。彼は現在もプロジェクトのメンテナンスを担当し、オープンソースコミュニティに無料のソフトウェアアップデートを提供しています。このガイドでは、HAProxy [2.6](https://www.haproxy.com/blog/announcing-haproxy-2-6/)を使用しています。最新の安定版の使用を推奨します。詳細は[HAProxyのリリースバージョン](http://www.haproxy.org/)ご覧ください。 ## 基本機能 {#basic-features} @@ -59,7 +59,7 @@ HAProxy をデプロイする前に、ハードウェアとソフトウェアの > **注記：** > -> - サポートされているその他のオペレーティング システムの詳細については、 [HAProxyドキュメント](https://github.com/haproxy/haproxy/blob/master/INSTALL)参照してください。 +> - サポートされているその他のオペレーティング システムの詳細については、 [HAProxyドキュメント](https://github.com/haproxy/haproxy/blob/master/INSTALL)を参照してください。 #### 依存関係 {#dependencies} diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index b52410574ac9d..9a06f7f0929db 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -86,7 +86,7 @@ DESC TIDB_INDEX_USAGE; 14 rows in set (0.00 sec) ``` -これらの列の説明については、 [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)参照してください。 +これらの列の説明については、 [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)を参照してください。 ### TIDB_INDEX_USAGEを使用して未使用および非効率的なインデックスを特定する {#identify-unused-and-inefficient-indexes-using-code-tidb-index-usage-code} @@ -221,7 +221,7 @@ SELECT * FROM sys.schema_unused_indexes; 以前のバージョンから TiDB v8.0.0 以降にアップグレードされたクラスターの場合は、システム スキーマと含まれるビューを手動で作成する必要があります。 -詳細については[`schema_unused_indexes`ビューを手動で作成する](/sys-schema/sys-schema-unused-indexes.md#manually-create-the-schema_unused_indexes-view)参照してください。 +詳細については[`schema_unused_indexes`ビューを手動で作成する](/sys-schema/sys-schema-unused-indexes.md#manually-create-the-schema_unused_indexes-view)を参照してください。 ## 不可視インデックスを使用してインデックスの削除を安全にテストする {#safely-test-index-removal-using-invisible-indexes} @@ -272,13 +272,13 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; 1. **インデックスの使用状況を定期的に監視します。** - - インデックスの使用アクティビティを追跡するには、 [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)と[`CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md#cluster_tidb_index_usage)使用します。 + - インデックスの使用アクティビティを追跡するには、 [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)と[`CLUSTER_TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md#cluster_tidb_index_usage)を使用します。 - [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)を使用して未使用のインデックスを識別し、削除できるかどうかを評価します。 - クエリ実行プランを監視して、過剰な I/O を引き起こす可能性のある非効率的なインデックスを検出します。 2. **インデックスを削除する前に検証します。** - - [`ALTER TABLE ... INVISIBLE`](/sql-statements/sql-statement-alter-table.md)使用してインデックスを不可視にし、一時的にインデックスを無効にして、完全に削除する前にその影響を確認します。 + - [`ALTER TABLE ... INVISIBLE`](/sql-statements/sql-statement-alter-table.md)を使用してインデックスを不可視にし、一時的にインデックスを無効にして、完全に削除する前にその影響を確認します。 - クエリのパフォーマンスが安定している場合は、インデックスの削除に進みます。 - 最終決定を下す前に、すべてのクエリ パターンを考慮するのに十分な観察期間を確保してください。 diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 247e9544b4434..26e3074daf91e 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -255,4 +255,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 4ceb0ff28f373..6d23b3fa75160 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -295,7 +295,7 @@ TiKV ノードに障害が発生した場合、PD はデフォルトで、対応 TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。1 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)加算することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。 -v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)指定します（デフォルトでは無効）。 +v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)を指定します（デフォルトでは無効）。 > **注記：** > diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index 16e2a684bdb43..b05d6b840d3e8 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -37,7 +37,7 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり - TiDB v8.4.0 以降、TiDB は SQL 実行中に、SQL ステートメントに関連するテーブル情報をオンデマンドで Infoschema キャッシュにロードします。 - TiDB ダッシュボードの**「スキーマ ロード」**パネルの下にある**「Infoschema v2 キャッシュ サイズ」**サブパネルと**「Infoschema v2 キャッシュ操作」**サブパネルを観察することで、Infoschema キャッシュのサイズとヒット率を監視できます。 - - システム変数[`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)使用すると、ビジネスニーズに合わせて Infoschema キャッシュのメモリ制限を調整できます。Infoschema キャッシュのサイズは、SQL 実行に関係するテーブルの数に比例します。実際のテストでは、100 万テーブル（各テーブルに 4 つの列、1 つの主キー、1 つのインデックス）のメタデータを完全にキャッシュするには、約 2.4 GiB のメモリが必要です。 + - システム変数[`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)を使用すると、ビジネスニーズに合わせて Infoschema キャッシュのメモリ制限を調整できます。Infoschema キャッシュのサイズは、SQL 実行に関係するテーブルの数に比例します。実際のテストでは、100 万テーブル（各テーブルに 4 つの列、1 つの主キー、1 つのインデックス）のメタデータを完全にキャッシュするには、約 2.4 GiB のメモリが必要です。 - TiDB は、SQL 実行中に、SQL ステートメントに関係するテーブル統計をオンデマンドで統計キャッシュに読み込みます。 @@ -82,7 +82,7 @@ SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに ## 古いものを使用するには、慎重に読んでください {#use-stale-read-carefully} -[ステイル読み取り](/stale-read.md)使用すると、古いスキーマバージョンによって過去のスキーマがフルロードされ、パフォーマンスに重大な影響を与える可能性があります。この問題を軽減するには、 [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740)の値を（例えば`255`に）増やしてください。 +[ステイル読み取り](/stale-read.md)を使用すると、古いスキーマバージョンによって過去のスキーマがフルロードされ、パフォーマンスに重大な影響を与える可能性があります。この問題を軽減するには、 [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740)の値を（例えば`255`に）増やしてください。 ## BRバックアップと復元を最適化 {#optimize-br-backup-and-restore} diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md index 30c75800828d1..75c73023d79aa 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -25,4 +25,4 @@ TiKVノードとTiDBノードの両方に構成項目`labels`設定されてい TiDB がステイル読み取りクエリを受信すると、その TiDB ノードの`zone`ラベルが設定されていて、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-replicas`に設定されている場合、TiDB は対応するデータ レプリカが存在する同じ`zone`ラベルを持つ TiKV ノードに要求を送信します。 -ステイル読み取り の実行方法については、 [`AS OF TIMESTAMP`句を使用してステイル読み取りを実行する](/as-of-timestamp.md)参照してください。 +ステイル読み取り の実行方法については、 [`AS OF TIMESTAMP`句を使用してステイル読み取りを実行する](/as-of-timestamp.md)を参照してください。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 9c17f7cd94c21..7bdbb4adf8b21 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -117,7 +117,7 @@ tiup ctl:v tikv --host=${ip:port} modify-tikv-config -n gc.max_ 通常、 `tidb_hash_join_concurrency`や`tidb_index_lookup_join_concurrency`などのシステム変数を使用して、実行演算子の TiDB パラメータを調整できます。 -このテストでは、これらのパラメータは調整されていません。実際のアプリケーションの負荷テストにおいて、実行オペレータが過剰なCPUリソースを消費する場合は、アプリケーションのシナリオに応じて特定のオペレータのリソース使用量を制限することができます。詳細については、 [TiDB システム変数](/system-variables.md)参照してください。 +このテストでは、これらのパラメータは調整されていません。実際のアプリケーションの負荷テストにおいて、実行オペレータが過剰なCPUリソースを消費する場合は、アプリケーションのシナリオに応じて特定のオペレータのリソース使用量を制限することができます。詳細については、 [TiDB システム変数](/system-variables.md)を参照してください。 #### `performance.max-procs` {#performance-max-procs} diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index d44bb2d93fdf4..cb85a7c4d53d9 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/tidb-partitioned-tables-best-practices/','/ja/tidb/de TiDBのパーティションテーブルは、大規模データセットの管理、クエリ効率の向上、一括データ削除の容易化、書き込みホットスポット問題の緩和など、多用途なアプローチを提供します。データを論理セグメントに分割することで、TiDBはパーティションプルーニングを活用し、クエリ実行時に不要なデータをスキップします。これにより、リソース消費が削減され、特に大規模データセットを扱うオンライン分析処理（OLAP）ワークロードにおいてパフォーマンスが向上します。 -一般的なユースケースとしては、 [範囲分割](/partitioned-table.md#range-partitioning)とローカルインデックスを組み合わせて、 [`ALTER TABLE ... DROP PARTITION`](/sql-statements/sql-statement-alter-table.md)などの操作で履歴データを効率的にクリーンアップすることが挙げられます。この方法では、古いデータがほぼ瞬時に削除され、パーティションキーによるフィルタリング時に高いクエリ効率が維持されます。ただし、パーティション化されていないテーブルからパーティション化されたテーブルに移行した後、パーティションキーフィルターがないクエリなど、パーティションプルーニングのメリットを享受できないクエリでは、パフォーマンスが低下する可能性があります。このような場合、 [グローバルインデックス](/partitioned-table.md#global-indexes)使用してすべてのパーティションに統一されたインデックス構造を提供することで、パフォーマンスへの影響を軽減できます。 +一般的なユースケースとしては、 [範囲分割](/partitioned-table.md#range-partitioning)とローカルインデックスを組み合わせて、 [`ALTER TABLE ... DROP PARTITION`](/sql-statements/sql-statement-alter-table.md)などの操作で履歴データを効率的にクリーンアップすることが挙げられます。この方法では、古いデータがほぼ瞬時に削除され、パーティションキーによるフィルタリング時に高いクエリ効率が維持されます。ただし、パーティション化されていないテーブルからパーティション化されたテーブルに移行した後、パーティションキーフィルターがないクエリなど、パーティションプルーニングのメリットを享受できないクエリでは、パフォーマンスが低下する可能性があります。このような場合、 [グローバルインデックス](/partitioned-table.md#global-indexes)を使用してすべてのパーティションに統一されたインデックス構造を提供することで、パフォーマンスへの影響を軽減できます。 もう1つのシナリオは、ハッシュまたはキーパーティショニングを使用して書き込みホットスポットの問題に対処することです。特に、 [`AUTO_INCREMENT`](/auto-increment.md) IDを使用するワークロードでは、シーケンシャルな挿入によって特定のTiKVリージョンに過負荷がかかる可能性があります。書き込みをパーティションに分散させることでワークロードのバランスを取ることができますが、レンジパーティショニングと同様に、パーティションプルーニング条件のないクエリではパフォーマンスが低下する可能性があります。このような状況では、グローバルインデックスが役立ちます。 @@ -20,7 +20,7 @@ TiDBのパーティションテーブルは、大規模データセットの管 > **注記：** > -> 基礎を学ぶには、パーティション プルーニング、インデックス タイプ、パーティション分割方法などの主要な概念について説明している[パーティショニング](/partitioned-table.md)参照してください。 +> 基礎を学ぶには、パーティション プルーニング、インデックス タイプ、パーティション分割方法などの主要な概念について説明している[パーティショニング](/partitioned-table.md)を参照してください。 ## クエリ効率の向上 {#improve-query-efficiency} @@ -39,7 +39,7 @@ TiDBのパーティションテーブルは、大規模データセットの管 - マルチテナントまたはカテゴリベースのデータセット: テナント ID またはカテゴリ別にパーティション分割することで、クエリをパーティションの小さなサブセットに集中させることができます。 - ハイブリッドトランザクションおよび分析処理（HTAP）：特にレンジパーティショニングにおいて、TiDBはTiFlash上​​の分析ワークロードにパーティションプルーニングを適用できます。この最適化により、無関係なパーティションがスキップされ、大規模なデータセットにおけるテーブル全体のスキャンが回避されます。 -その他の使用例については、 [パーティションプルーニング](/partition-pruning.md)参照してください。 +その他の使用例については、 [パーティションプルーニング](/partition-pruning.md)を参照してください。 ### セカンダリ インデックスのクエリ パフォーマンス: 非パーティション テーブルとローカル インデックスとグローバル インデックスの比較 {#query-performance-on-secondary-indexes-non-partitioned-tables-vs-local-indexes-vs-global-indexes} @@ -220,7 +220,7 @@ TiDB でパーティション テーブルとインデックスを設計する ## 一括データ削除を容易にする {#facilitate-bulk-data-deletion} -TiDBでは、 [TTL (存続時間)](/time-to-live.md)使用するか、パーティションを手動で削除することで履歴データを削除できます。どちらの方法でもデータは削除されますが、パフォーマンス特性は大きく異なります。以下のテスト結果から、パーティションを削除する方が一般的に高速で消費リソースも少なく、大規模なデータセットや頻繁なデータパージにはより適した選択肢であることがわかります。 +TiDBでは、 [TTL (存続時間)](/time-to-live.md)を使用するか、パーティションを手動で削除することで履歴データを削除できます。どちらの方法でもデータは削除されますが、パフォーマンス特性は大きく異なります。以下のテスト結果から、パーティションを削除する方が一般的に高速で消費リソースも少なく、大規模なデータセットや頻繁なデータパージにはより適した選択肢であることがわかります。 ### TTLとDROP PARTITIONの違い {#differences-between-ttl-and-code-drop-partition-code} @@ -257,7 +257,7 @@ TTL パフォーマンスに関する調査結果は次のとおりです。 #### TiDBでTTLとDROP PARTITION使用する {#use-ttl-and-code-drop-partition-code-in-tidb} -以下の例では匿名化されたテーブル構造を使用しています。TTLの詳細については、 [TTL（Time to Live）を使用して定期的にデータを削除する](/time-to-live.md)参照してください。 +以下の例では匿名化されたテーブル構造を使用しています。TTLの詳細については、 [TTL（Time to Live）を使用して定期的にデータを削除する](/time-to-live.md)を参照してください。 次の例は、TTL 対応のテーブル スキーマを示しています。 @@ -365,7 +365,7 @@ TiDBは新しい行とインデックスエントリを「右端」のリージ > > このセクションでは、読み取りおよび書き込みホットスポットを軽減するための例として、パーティションテーブルを使用します。TiDB は、 [`AUTO_INCREMENT`](/auto-increment.md)や[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)などのホットスポット軽減のための追加機能も提供しています。 > -> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)参照してください。 +> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)を参照してください。 ### パーティショニングの仕組み {#how-partitioning-works} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 612711f0681cb..ec5fe8f9165df 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -22,7 +22,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ### バイナリとして保存 {#store-as-binary} -テキスト形式のUUID形式は次のようになります`ab06f63e-8fe7-11ec-a514-5405db7aad56`は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 +テキスト形式のUUID形式は次のようになります`ab06f63e-8fe7-11ec-a514-5405db7aad56`は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)を使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys} diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index 1d50372e08c2d..795c1559b4950 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -70,7 +70,7 @@ summary: 最適化ルールと式プッシュダウンの動作を制御する ### プッシュダウンがサポートされている式 {#expressions-that-are-supported-to-be-pushed-down} -プッシュダウンがサポートされている式の詳細については、 [TiKVへのプッシュダウンでサポートされている式](/functions-and-operators/expressions-pushed-down.md#supported-expressions-for-pushdown-to-tikv)参照してください。 +プッシュダウンがサポートされている式の詳細については、 [TiKVへのプッシュダウンでサポートされている式](/functions-and-operators/expressions-pushed-down.md#supported-expressions-for-pushdown-to-tikv)を参照してください。 ### 特定の式のプッシュダウンを無効にする {#disable-the-pushdown-of-specific-expressions} diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 8b74856c6582f..7c10cccc6dab4 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -75,7 +75,7 @@ TiDB BRは以下の機能を提供します。 #### バックアップのパフォーマンスとTiDBクラスタへの影響 {#backup-performance-and-impact-on-tidb-clusters} -- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV構成項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 と[バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)参照してください。 +- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV構成項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 と[バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)を参照してください。 - ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3～5分ごとに最後の更新後に生成されたすべての変更をバックアップストレージにフラッシュするため、**最短5分のリカバリポイント目標（RPO）を実現できます**。 ### バックアップデータを復元する {#restore-backup-data} @@ -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） @@ -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 クラスタではサポートされていません。 | diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 5b52764d9ae8e..3f0903a6e7d16 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -37,7 +37,7 @@ BACKUP DATABASE * TO 's3://bucket-name/prefix' SEND_CREDENTIALS_TO_TIKV = FALSE; [scheme]://[host]/[path]?[parameters] ``` -URI 形式の詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +URI 形式の詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 ### URIの例 {#uri-examples} @@ -109,7 +109,7 @@ tiup br restore db --db test -u "${PD_IP}:2379" \ - バックアップ中に`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)を参照してバケット内にフォルダを作成することもできます。 +バックアップディレクトリをまだ作成していない場合は、 [バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照して指定のリージョンに S3 バケットを作成してください。必要に応じて、 [フォルダを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)を参照してバケット内にフォルダを作成することもできます。 > **注記：** > @@ -289,7 +289,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト ### Amazon S3 サーバー側暗号化 {#amazon-s3-server-side-encryption} -BR は、Amazon S3 へのデータバックアップ時にサーバー側暗号化をサポートします。また、 BRを使用して S3 のサーバー側暗号化用に作成した AWS KMS キーを使用することもできます。詳細については、 [BR S3 サーバー側暗号化](/encryption-at-rest.md#br-s3-server-side-encryption)参照してください。 +BR は、Amazon S3 へのデータバックアップ時にサーバー側暗号化をサポートします。また、 BRを使用して S3 のサーバー側暗号化用に作成した AWS KMS キーを使用することもできます。詳細については、 [BR S3 サーバー側暗号化](/encryption-at-rest.md#br-s3-server-side-encryption)を参照してください。 ### Azure Blob Storage のサーバー側暗号化 {#azure-blob-storage-server-side-encryption} diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index bdb278c25e7f3..d407e3fc5cd07 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -9,7 +9,7 @@ TiDBクラスターの増分データは、期間の開始スナップショッ > **警告：** > -> この機能の開発は停止しています。代替として[ログバックアップとPITR](/br/br-pitr-guide.md)使用することをお勧めします。 +> この機能の開発は停止しています。代替として[ログバックアップとPITR](/br/br-pitr-guide.md)を使用することをお勧めします。 ## 制限事項 {#limitations} @@ -42,7 +42,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - `--lastbackupts` : 最後のバックアップのタイムスタンプ。 - `--ratelimit` : バックアップ タスクを実行する**TiKV あたりの**最大速度 (MiB/秒)。 -- `storage` : バックアップデータのストレージパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `storage` : バックアップデータのストレージパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 ## 増分データを復元する {#restore-incremental-data} diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index f4f31a53d7978..d79d2bbbef182 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -171,7 +171,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 8a37e941c407b..61c1fbd368a3c 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -77,7 +77,7 @@ Global Flags: - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 -- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -349,7 +349,7 @@ Global Flags: - `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 - `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 -- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -390,7 +390,7 @@ Global Flags: このコマンドはバックアップストレージにのみアクセスし、TiDB クラスターにはアクセスしません。 -`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのstorageとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのstorageとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -441,7 +441,7 @@ Global Flags: 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 - `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 @@ -449,7 +449,7 @@ Global Flags: - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 -- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -591,7 +591,7 @@ v8.5.5 以降では、ログ バックアップ タスクの実行中に、次 - ログバックアップで使用されるターゲット外部ストレージへの書き込みアクセス - ログバックアップの対象となる外部ストレージは、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)参照してください。 +- 復元対象のデータとログバックアップのどちらにもローカル暗号化が有効になっていません。詳細については、 [ログバックアップの暗号化](#encrypt-the-log-backup-data)と[スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)を参照してください。 上記の条件のいずれかが満たされていない場合は、次の手順に従ってデータを復元できます。 diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 441b8309236f4..1f702b91575b1 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -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-manual.md b/br/br-snapshot-manual.md index 581210cb32cd6..46eb627f8ca2d 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -131,7 +131,7 @@ tiup br restore full \ > > v8.5.5以降、パラメータ`--load-stats`を`false`に設定すると、 BRは復元されたテーブルの統計情報をテーブル`mysql.stats_meta`に書き込まなくなります。復元が完了したら、SQL文[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)を手動で実行して関連する統計情報を更新できます。 -バックアップと復元機能は、データをバックアップする際に、統計情報をJSON形式で`backupmeta`ファイルに保存します。データを復元する際には、JSON形式の統計情報をクラスターに読み込みます。詳細については、 [負荷統計](/sql-statements/sql-statement-load-stats.md)参照してください。 +バックアップと復元機能は、データをバックアップする際に、統計情報をJSON形式で`backupmeta`ファイルに保存します。データを復元する際には、JSON形式の統計情報をクラスターに読み込みます。詳細については、 [負荷統計](/sql-statements/sql-statement-load-stats.md)を参照してください。 v8.5.5以降、 BRは`--fast-load-sys-tables`パラメータを導入し、デフォルトで有効になっています。3 `br`ラインツールを使用して新しいクラスターにデータを復元する場合、上流クラスターと下流クラスター間のテーブルとパーティションのIDを再利用できます（そうでない場合、 BRは自動的に統計を論理的にロードします） `--fast-load-sys-tables`有効にすると、 BRはまず統計関連のシステムテーブルを一時システムデータベース`__TiDB_BR_Temporary_mysql`に復元し、次に`RENAME TABLE`ステートメントを使用してこれらのテーブルを`mysql`データベース内の対応するテーブルとアトミックにスワップします。 @@ -182,7 +182,7 @@ tiup br restore full \ 上記のコマンドでは、次のようになります。 -- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。 +- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)を参照してください。 - `--ratelimit` : 復元タスクを実行する**TiKVあたりの**最大速度。単位はMiB/sです。 - `--log-file` : `br`ログが書き込まれる対象ファイル。 diff --git a/cached-tables.md b/cached-tables.md index a90b2d8264389..48eff9b3b5c6b 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -72,7 +72,7 @@ SHOW CREATE TABLE users; 1 row in set (0.00 sec) ``` -キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。1 文[`TRACE`](/sql-statements/sql-statement-trace.md)使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 +キャッシュされたテーブルからデータを読み込んだ後、TiDBはデータをメモリにロードします。1 文[`TRACE`](/sql-statements/sql-statement-trace.md)を使用すると、データがメモリにロードされているかどうかを確認できます。キャッシュにロードされていない場合、返される結果には`regionRequest.SendReqCtx`属性が含まれます。これは、TiDBがTiKVからデータを読み込んでいることを示します。 ```sql TRACE SELECT * FROM users; diff --git a/character-set-and-collation.md b/character-set-and-collation.md index 41d3961c86dc6..5ed263e4431c0 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -168,7 +168,7 @@ SHOW COLLATION WHERE Charset = 'utf8mb4'; 5 rows in set (0.001 sec) ``` -GBK 文字セットの TiDB サポートの詳細については、 [GBK](/character-set-gbk.md)参照してください。 +GBK 文字セットの TiDB サポートの詳細については、 [GBK](/character-set-gbk.md)を参照してください。 ## TiDB のutf8とutf8mb4 {#code-utf8-code-and-code-utf8mb4-code-in-tidb} @@ -491,7 +491,7 @@ TiDB v4.0 以降では、照合のための完全なフレームワークが導 -この新しいフレームワークは、照合順序の意味解析をサポートし、クラスターの初回初期化時に新しいフレームワークを有効にするかどうかを決定するための設定項目`new_collations_enabled_on_first_bootstrap`導入しました。新しいフレームワークを有効にするには、 `new_collations_enabled_on_first_bootstrap`を`true`に設定します。詳細については、 [`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)参照してください。 +この新しいフレームワークは、照合順序の意味解析をサポートし、クラスターの初回初期化時に新しいフレームワークを有効にするかどうかを決定するための設定項目`new_collations_enabled_on_first_bootstrap`導入しました。新しいフレームワークを有効にするには、 `new_collations_enabled_on_first_bootstrap`を`true`に設定します。詳細については、 [`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)を参照してください。 すでに初期化されている TiDB クラスターの場合、 `mysql.tidb`テーブルの`new_collation_enabled`変数を通じて新しい照合順序が有効になっているかどうかを確認できます。 @@ -598,4 +598,4 @@ SELECT 'a' = _utf8mb4 'A' collate utf8mb4_general_ci; 1 row in set (0.00 sec) ``` -詳細については[接続文字セットと照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html)参照してください。 +詳細については[接続文字セットと照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html)を参照してください。 diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index 4e6cc5822953c..ec3c571b2e084 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -62,7 +62,7 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 > **注記：** > > - Clinic Serverは2022年7月15日から2025年4月15日まで無料です。それ以降に有料になる場合は、2025年4月15日までにメールでお知らせいたします。 -> - 使用制限を調整する場合は、PingCAP から[サポートを受ける](/support.md)実行します。 +> - 使用制限を調整する場合は、PingCAP から[サポートを受けてください](/support.md)。 | サービスタイプ | 制限 | | :------------- | :---------- | diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 6d21af324bb2e..3d8f7939861eb 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -9,7 +9,7 @@ TiUPを使用して導入された TiDB クラスターおよび DM クラスタ > **注記：** > -> - このドキュメントは、セルフホスト環境でTiUPを使用してデプロイされたクラスターに**のみ**適用されます。Kubernetes上でTiDB Operatorを使用してデプロイされたクラスターについては、 [TiDB Operator環境向けPingCAP Clinic](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide)参照してください。 +> - このドキュメントは、セルフホスト環境でTiUPを使用してデプロイされたクラスターに**のみ**適用されます。Kubernetes上でTiDB Operatorを使用してデプロイされたクラスターについては、 [TiDB Operator環境向けPingCAP Clinic](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide)を参照してください。 > > - PingCAP Clinic は、 TiDB Ansible を使用してデプロイされたクラスターからのデータ収集を**サポートしていません**。 @@ -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) @@ -126,7 +126,7 @@ Diag を使用すると、監視データや構成情報などの診断データ ### ステップ1. 収集するデータを確認する {#step-1-check-the-data-to-be-collected} -Diag によって収集できるデータの完全なリストについては、 [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md)参照してください。 +Diag によって収集できるデータの完全なリストについては、 [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md)を参照してください。 後続の診断の効率を高めるため、監視データや設定情報を含む完全な診断データを収集することをお勧めします。詳細については、 [クラスターからデータを収集する](#step-2-collect-data)参照してください。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index b96a47bff02c4..c0f1028017743 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -16,7 +16,7 @@ PingCAP Clinicは、 [Diagクライアント](https://github.com/pingcap/diag) > **注記：** > -> - 以下のデータ収集およびアップロード方法は[TiUPを使用して展開されたクラスター](/production-deployment-using-tiup.md)に**のみ**適用されます。Kubernetes 上のTiDB Operatorを使用してデプロイされたクラスターの場合は、 [TiDB Operator環境向けPingCAP Clinic](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide)参照してください。 +> - 以下のデータ収集およびアップロード方法は[TiUPを使用して展開されたクラスター](/production-deployment-using-tiup.md)に**のみ**適用されます。Kubernetes 上のTiDB Operatorを使用してデプロイされたクラスターの場合は、 [TiDB Operator環境向けPingCAP Clinic](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide)を参照してください。 > - PingCAP Clinicによって収集された診断データは、クラスターの問題のトラブルシューティングに**のみ**使用されます。 ## 前提条件 {#prerequisites} diff --git a/clustered-indexes.md b/clustered-indexes.md index fa561a845a2ef..ab9d7ff91f549 100644 --- a/clustered-indexes.md +++ b/clustered-indexes.md @@ -52,7 +52,7 @@ CREATE TABLE t (a BIGINT, b VARCHAR(255), PRIMARY KEY(a, b) NONCLUSTERED); 列定義において、キーワード`KEY`と`PRIMARY KEY`は同じ意味を持つことに注意してください。 -TiDB の[コメント構文](/comment-syntax.md)使用して主キーのタイプを指定することもできます。例えば： +TiDB の[コメント構文](/comment-syntax.md)を使用して主キーのタイプを指定することもできます。例えば： ```sql CREATE TABLE t (a BIGINT PRIMARY KEY /*T![clustered_index] CLUSTERED */, b VARCHAR(255)); diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 280dd40e95dff..a6618a6cc900f 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -17,7 +17,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - 設定ファイル - デフォルト: `""` -- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)参照してください。 +- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)を参照してください。 ## `--config-check` {#config-check} @@ -119,7 +119,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--proxy-protocol-networks` {#proxy-protocol-networks} -- [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト。 +- [PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)を使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト。 - デフォルト: `""` - 通常、リバースプロキシを経由してTiDBにアクセスする場合、TiDBはリバースプロキシサーバーのIPアドレスをクライアントのIPアドレスとして取得します。PROXYプロトコルを有効にすると、HAProxyなどのこのプロトコルをサポートするリバースプロキシは、実際のクライアントIPアドレスをTiDBに渡すことができます。 - このフラグを設定すると、TiDBは設定された送信元IPアドレスがPROXYプロトコルを使用してTiDBに接続することを許可します。PROXY以外のプロトコルが使用されている場合、この接続は拒否されます。その他のアドレスはPROXYプロトコルを使用せずにTiDBに接続できます。このフラグを空のままにすると、どのIPアドレスもPROXYプロトコルを使用してTiDBに接続できなくなります。値は、IPアドレス（192.168.1.50）またはCIDR（192.168.1.0/24）で、区切り文字として`,`使用します。3 `*`任意のIPアドレスを意味します。 @@ -189,7 +189,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--tidb-service-scope` {#tidb-service-scope} -- 現在の TiDB インスタンスの初期値として[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)指定します。 +- 現在の TiDB インスタンスの初期値として[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を指定します。 - デフォルト: `""` ## `--token-limit` {#token-limit} @@ -222,7 +222,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - サブコマンド`collect-log`使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 - デフォルト: false -- 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)参照してください。 +- 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)を参照してください。 ## `--repair-mode` {#repair-mode} diff --git a/comment-syntax.md b/comment-syntax.md index acaf71da718be..ad6ef0f05dd50 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -119,10 +119,10 @@ TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント SELECT /*+ hint */ FROM ...; ``` -TiDB がサポートするオプティマイザヒントの詳細については、 [オプティマイザーヒント](/optimizer-hints.md)参照してください。 +TiDB がサポートするオプティマイザヒントの詳細については、 [オプティマイザーヒント](/optimizer-hints.md)を参照してください。 > **注記：** > > MySQLクライアントでは、TiDB固有のコメント構文はコメントとして扱われ、デフォルトでクリアされます。5.7.7より前のMySQLクライアントでは、ヒントもコメントとして扱われ、デフォルトでクリアされます。クライアント起動時には、 `--comments`オプションを使用することをお勧めします。例えば、 `mysql -h 127.0.0.1 -P 4000 -uroot --comments`指定します。 -詳細については[コメント構文](https://dev.mysql.com/doc/refman/8.0/en/comments.html)参照してください。 +詳細については[コメント構文](https://dev.mysql.com/doc/refman/8.0/en/comments.html)を参照してください。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 03728301f06e5..1c1a701e4ec50 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -31,7 +31,7 @@ SET tidb_mem_quota_query = 8 << 10; ## tidb-server インスタンスのメモリ使用量しきい値を構成する {#configure-the-memory-usage-threshold-of-a-tidb-server-instance} -v6.5.0 以降では、システム変数[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)使用して、tidb-server インスタンスのメモリ使用量のしきい値を設定できます。 +v6.5.0 以降では、システム変数[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)を使用して、tidb-server インスタンスのメモリ使用量のしきい値を設定できます。 たとえば、tidb-server インスタンスの合計メモリ使用量を 32 GB に設定します。 @@ -121,7 +121,7 @@ tidb-server インスタンスのメモリ使用量がメモリしきい値 (デ ## tidb-server の書き込みトランザクションのメモリ使用量を削減します {#reduce-the-memory-usage-for-write-transactions-in-tidb-server} -TiDBが使用するトランザクションモデルでは、トランザクションのすべての書き込み操作はコミットされる前にメモリにキャッシュされる必要があります。TiDBが大規模なトランザクションを書き込む場合、メモリ使用量が増加し、ボトルネックになる可能性があります。様々な制約下で大規模トランザクションによるメモリ使用量の増加を軽減または回避するには、システム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800) `"bulk"`に調整するか、 [非トランザクションDMLステートメント](/non-transactional-dml.md)使用します。 +TiDBが使用するトランザクションモデルでは、トランザクションのすべての書き込み操作はコミットされる前にメモリにキャッシュされる必要があります。TiDBが大規模なトランザクションを書き込む場合、メモリ使用量が増加し、ボトルネックになる可能性があります。様々な制約下で大規模トランザクションによるメモリ使用量の増加を軽減または回避するには、システム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800) `"bulk"`に調整するか、 [非トランザクションDMLステートメント](/non-transactional-dml.md)を使用します。 ## tidb-serverのその他のメモリ制御動作 {#other-memory-control-behaviors-of-tidb-server} diff --git a/configure-store-limit.md b/configure-store-limit.md index 117c443b9c449..247503d132d95 100644 --- a/configure-store-limit.md +++ b/configure-store-limit.md @@ -29,7 +29,7 @@ PDはオペレータ単位でスケジューリングを実行します。オペ ## 使用法 {#usage} -Store Limit のパラメータは[`PD Control`](/pd-control.md)使用して設定できます。 +Store Limit のパラメータは[`PD Control`](/pd-control.md)を使用して設定できます。 ### 現在のストアのビュー設定 {#view-setting-of-the-current-store} diff --git a/configure-time-zone.md b/configure-time-zone.md index 57200e87af981..8828d15015c11 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -102,9 +102,9 @@ select * from t; - `TIMESTAMP`と`DATETIME`値の変換中にはタイムゾーンが関係し、現在のセッションの`time_zone`に基づいて処理されます。 - データ移行では、プライマリ データベースとセカンダリ データベースのタイム ゾーン設定が一致しているかどうかに特に注意する必要があります。 -- 正確なタイムスタンプを取得するには、ネットワークタイムプロトコル（NTP）または高精度時間プロトコル（PTP）サービスを使用して信頼性の高いクロックを設定することを強くお勧めします。NTPサービスの確認方法については、 [NTPサービスを確認してインストールする](/check-before-deployment.md#check-and-install-the-ntp-service)参照してください。 +- 正確なタイムスタンプを取得するには、ネットワークタイムプロトコル（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プログラミング言語に組み込まれたタイムゾーン処理機能を活用します。 +- MySQLは[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.4/en/mysql-tzinfo-to-sql.html)を使用して、オペレーティングシステムのタイムゾーンデータベースを`mysql`データベースのテーブルに変換します。一方、TiDBはオペレーティングシステムのタイムゾーンデータベースからタイムゾーンデータファイルを直接読み取り、Goプログラミング言語に組み込まれたタイムゾーン処理機能を活用します。 ## 参照 {#see-also} diff --git a/coprocessor-cache.md b/coprocessor-cache.md index b2b589441c767..3eab2431467bf 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -11,7 +11,7 @@ v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシ -コプロセッサーキャッシュは、TiDB設定ファイルの`tikv-client.copr-cache`設定項目で設定できます。コプロセッサーキャッシュの有効化と設定方法の詳細については、 [TiDBコンフィグレーションファイル](/tidb-configuration-file.md#tikv-clientcopr-cache-new-in-v400)参照してください。 +コプロセッサーキャッシュは、TiDB設定ファイルの`tikv-client.copr-cache`設定項目で設定できます。コプロセッサーキャッシュの有効化と設定方法の詳細については、 [TiDBコンフィグレーションファイル](/tidb-configuration-file.md#tikv-clientcopr-cache-new-in-v400)を参照してください。 diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index f5d388d49866a..90128f6243354 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -9,7 +9,7 @@ TiDB Dashboardにアクセスするには、ブラウザから[http://127.0.0.1: > **注記：** > -> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイできます。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。詳細は[TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。 +> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイできます。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。詳細は[TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)を参照してください。 ## 複数のPDインスタンスがデプロイされている場合にTiDB Dashboardにアクセスする {#access-tidb-dashboard-when-multiple-pd-instances-are-deployed} diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index fc6774887162d..9c5bfe8a71c36 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -47,7 +47,7 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 > - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`同じステータスを示します。 > - テーブル内の一部の列は、インスタンスが起動している場合にのみ表示できます。 -インスタンスのステータスはPDのスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)参照してください。 +インスタンスのステータスはPDのスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)を参照してください。 ## ホストリスト {#host-list} diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index bffbb0467c20d..182a9dba7912e 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -5,7 +5,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 # TiDB Dashboard診断レポート {#tidb-dashboard-diagnostic-report} -このドキュメントでは、診断レポートの内容と表示に関するヒントを紹介します。クラスター診断ページにアクセスしてレポートを生成するには、 [TiDB Dashboardのクラスタ診断ページ](/dashboard/dashboard-diagnostics-access.md)参照してください。 +このドキュメントでは、診断レポートの内容と表示に関するヒントを紹介します。クラスター診断ページにアクセスしてレポートを生成するには、 [TiDB Dashboardのクラスタ診断ページ](/dashboard/dashboard-diagnostics-access.md)を参照してください。 ## レポートを表示する {#view-report} diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index cff3050e93c2b..52ffee4313829 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -13,15 +13,15 @@ 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)参照してください。 +- 複数の PD インスタンスを使用した TiDB Dashboardの動作原理については、 [TiDB Dashboardのマルチ PD インスタンスの展開](/dashboard/dashboard-ops-deploy.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} セキュリティ上の理由から、PD上のTiDB Dashboardは、デプロイメント時に指定されたIPアドレスのみを監視します（つまり、1つのNICのみを監視します）。`0.0.0.0`ですべてのNICを監視するわけではありません。そのため、ホストに複数のNICがインストールされている場合、別のNICを使用してTiDB Dashboardにアクセスすることはできません。 -`tiup cluster`または`tiup playground`コマンドを使用して TiDB をデプロイした場合、現時点ではこの問題を解決できません。リバースプロキシを使用して、TiDB Dashboardを別の NIC に安全に公開することをお勧めします。詳細は[リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)参照してください。 +`tiup cluster`または`tiup playground`コマンドを使用して TiDB をデプロイした場合、現時点ではこの問題を解決できません。リバースプロキシを使用して、TiDB Dashboardを別の NIC に安全に公開することをお勧めします。詳細は[リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 ## UIに関するよくあるFAQ {#ui-related-faq} diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 9d5e30ac4cc8e..13685c4c4dab5 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -9,7 +9,7 @@ TiDB Dashboardは、TiDBクラスターの監視、診断、管理のためのWe > **注記：** > -> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、TiDB DashboardをKubernetes上の独立したPodとしてデプロイできます。詳細については、 [TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。 +> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、TiDB DashboardをKubernetes上の独立したPodとしてデプロイできます。詳細については、 [TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)を参照してください。 ![TiDB Dashboard interface](/media/dashboard/dashboard-intro.gif) @@ -63,7 +63,7 @@ TiDB Dashboardの [ログの検索] ページでは、クラスター内で実 [リソース管理](/tidb-resource-control-ru-groups.md)機能を使用してリソース分離を実装するには、クラスター管理者がリソース グループを作成し、各グループにクォータを設定できます。 -リソース計画を立てる前に、クラスター全体の容量を把握しておく必要があります。詳細については、 [リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)参照してください。 +リソース計画を立てる前に、クラスター全体の容量を把握しておく必要があります。詳細については、 [リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)を参照してください。 ## 各インスタンスのプロファイリングデータを収集する {#collect-profiling-data-for-each-instance} diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index 1a3590911de80..fdc0dfe1c7c01 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -13,7 +13,7 @@ TiDB Dashboardにログインし、左側のナビゲーションバーから** ![Monitoring page](/media/dashboard/dashboard-monitoring.png) -TiDBクラスターをTiUPを使用してデプロイした場合、Grafanaでパフォーマンス概要ダッシュボードを表示することもできます。このデプロイメントモードでは、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiDBクラスターをTiUPを使用してデプロイした場合、Grafanaでパフォーマンス概要ダッシュボードを表示することもできます。このデプロイメントモードでは、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 ![performance overview](/media/performance/grafana_performance_overview.png) diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 346f2446a3fe0..ee25e33b27312 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -9,7 +9,7 @@ TiDB Dashboard UIは、v4.0以降のバージョンのPDコンポーネントに > **注記：** > -> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、TiDB DashboardをKubernetes上の独立したPodとしてデプロイできます。詳細については、 [TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。 +> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、TiDB DashboardをKubernetes上の独立したPodとしてデプロイできます。詳細については、 [TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)を参照してください。 標準の TiDB クラスターをデプロイする方法については、次のドキュメントを参照してください。 @@ -123,6 +123,6 @@ TiDB Dashboardを提供するPDインスタンスを手動で指定すること ## 次は何か {#what-s-next} -- TiDB Dashboard UI にアクセスしてログインする方法については、 [TiDB Dashboardにアクセスする](/dashboard/dashboard-access.md)参照してください。 +- TiDB Dashboard UI にアクセスしてログインする方法については、 [TiDB Dashboardにアクセスする](/dashboard/dashboard-access.md)を参照してください。 - ファイアウォールの設定など、TiDB Dashboardのセキュリティを強化する方法については、 [TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 9890376254374..20edabcbe73bb 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -11,7 +11,7 @@ summary: TiDB Dashboardは、リバースプロキシを使用して安全に公 ### ステップ1: 実際のTiDB Dashboardのアドレスを取得する {#step-1-get-the-actual-tidb-dashboard-address} -クラスター内に複数のPDインスタンスがデプロイされている場合、TiDB Dashboardを実際に実行するのは1つのPDインスタンスのみです。そのため、リバースプロキシのアップストリームが正しいアドレスを指していることを確認する必要があります。このメカニズムの詳細については、 [複数のPDインスタンスを使用したデプロイメント](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances)参照してください。 +クラスター内に複数のPDインスタンスがデプロイされている場合、TiDB Dashboardを実際に実行するのは1つのPDインスタンスのみです。そのため、リバースプロキシのアップストリームが正しいアドレスを指していることを確認する必要があります。このメカニズムの詳細については、 [複数のPDインスタンスを使用したデプロイメント](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances)を参照してください。 デプロイメントにTiUPツールを使用する場合は、次のコマンドを実行して実際の TiDB Dashboard アドレスを取得します ( `CLUSTER_NAME`をクラスター名に置き換えます)。 @@ -117,7 +117,7 @@ server_configs:
TiUPを使用して新しいクラスターを展開するときに構成を変更する -新しいクラスタをデプロイする場合は、上記の設定を`topology.yaml` TiUPトポロジファイルに追加してクラスタをデプロイできます。具体的な手順については、 [TiUP展開ドキュメント](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)参照してください。 +新しいクラスタをデプロイする場合は、上記の設定を`topology.yaml` TiUPトポロジファイルに追加してクラスタをデプロイできます。具体的な手順については、 [TiUP展開ドキュメント](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)を参照してください。
diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index c6a3ffe5bfdab..272f215734bde 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -25,7 +25,7 @@ TiDB Dashboardにアクセスしてサインインするには、最小限の権 > **注記：** > -> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降は、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイすることをサポートしています。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。このポートはPDの他の特権インターフェースとは通信しないため、外部から提供される場合は追加のファイアウォールは必要ありません。詳細については、 [TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。 +> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降は、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイすることをサポートしています。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。このポートはPDの他の特権インターフェースとは通信しないため、外部から提供される場合は追加のファイアウォールは必要ありません。詳細については、 [TiDB DashboardをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)を参照してください。 TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:2379/dashboard/](http://IP:2379/dashboard/) ）を介してサービスを提供します。TiDB DashboardはID認証を必要としますが、PDクライアントポート上のPD内の他の特権インターフェース（例： [http://IP:2379/pd/api/v1/members](http://IP:2379/pd/api/v1/members) ）はID認証を必要とせず、特権操作を実行できます。したがって、PDクライアントポートを外部ネットワークに直接公開することは非常に危険です。 @@ -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} @@ -47,7 +47,7 @@ TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:23 テスト環境では、外部アクセス用に TiDB Dashboard ポートを開くようにファイアウォールを構成する必要がある場合があります。 -複数のPDインスタンスがデプロイされている場合、TiDB Dashboardは実際に1つのPDインスタンスのみで実行され、他のPDインスタンスにアクセスするとブラウザのリダイレクトが発生します。そのため、ファイアウォールに正しいIPアドレスが設定されていることを確認する必要があります。このメカニズムの詳細については、 [複数のPDインスタンスを使用したデプロイメント](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances)参照してください。 +複数のPDインスタンスがデプロイされている場合、TiDB Dashboardは実際に1つのPDインスタンスのみで実行され、他のPDインスタンスにアクセスするとブラウザのリダイレクトが発生します。そのため、ファイアウォールに正しいIPアドレスが設定されていることを確認する必要があります。このメカニズムの詳細については、 [複数のPDインスタンスを使用したデプロイメント](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances)を参照してください。 TiUPデプロイメント ツールを使用する場合、次のコマンドを実行すると、実際に TiDB Dashboardを実行している PD インスタンスのアドレスを表示できます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 @@ -82,7 +82,7 @@ http://192.168.0.123:2379/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} diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md index 00feecd4bb95e..d0da2e6270068 100644 --- a/dashboard/dashboard-overview.md +++ b/dashboard/dashboard-overview.md @@ -46,7 +46,7 @@ TiDB Dashboardにログインすると、デフォルトで概要ページが表 ![Top SQL](/media/dashboard/dashboard-overview-top-statements.png) -この領域に表示される情報は、より詳細な[SQL文ページ](/dashboard/dashboard-statement-list.md)と一致しています。 **「Top SQL文」**の見出しをクリックすると、完全なリストが表示されます。この表の列の詳細については、 [SQL文ページ](/dashboard/dashboard-statement-list.md)参照してください。 +この領域に表示される情報は、より詳細な[SQL文ページ](/dashboard/dashboard-statement-list.md)と一致しています。 **「Top SQL文」**の見出しをクリックすると、完全なリストが表示されます。この表の列の詳細については、 [SQL文ページ](/dashboard/dashboard-statement-list.md)を参照してください。 > **注記：** > diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index 5845dc1baf950..d0669c9f2ec82 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -13,7 +13,7 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 これらのパフォーマンス データを使用すると、専門家はインスタンスの CPU やメモリなどの現在のリソース消費の詳細を分析し、CPU オーバーヘッドの増加、メモリ使用量の増加、プロセスの停止など、進行中の高度なパフォーマンスの問題を正確に特定できます。 -プロファイリングを開始すると、TiDB Dashboardは一定期間（デフォルトでは30秒）現在のパフォーマンスデータを収集します。そのため、この機能はクラスターが現在直面している進行中の問題の分析にのみ使用でき、過去の問題には大きな影響を与えません。**いつでも**パフォーマンスデータを収集して分析したい場合は、 [継続的なプロファイリング](/dashboard/continuous-profiling.md)参照してください。 +プロファイリングを開始すると、TiDB Dashboardは一定期間（デフォルトでは30秒）現在のパフォーマンスデータを収集します。そのため、この機能はクラスターが現在直面している進行中の問題の分析にのみ使用でき、過去の問題には大きな影響を与えません。**いつでも**パフォーマンスデータを収集して分析したい場合は、 [継続的なプロファイリング](/dashboard/continuous-profiling.md)を参照してください。 ## サポートされているパフォーマンスデータ {#supported-performance-data} diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index f9cc9cb36df40..6291e2535861e 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -23,7 +23,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ リソース マネージャー ページには、次の 3 つのセクションがあります。 -- コンフィグレーション: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)参照してください。 +- コンフィグレーション: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)を参照してください。 - 容量の見積もり：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 @@ -65,7 +65,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ > **注記：** > -> 容量推定機能を使用するには、現在のログインユーザーが権限`SUPER`または`RESOURCE_GROUP_ADMIN` 、および一部のシステムテーブルに対する権限`SELECT`持っている必要があります。この機能を使用する前に、現在のユーザーがこれらの権限を持っていることを確認してください。権限がない場合、一部の機能が正しく動作しない可能性があります。詳細については、 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#privileges)参照してください。 +> 容量推定機能を使用するには、現在のログインユーザーが権限`SUPER`または`RESOURCE_GROUP_ADMIN` 、および一部のシステムテーブルに対する権限`SELECT`持っている必要があります。この機能を使用する前に、現在のユーザーがこれらの権限を持っていることを確認してください。権限がない場合、一部の機能が正しく動作しない可能性があります。詳細については、 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#privileges)を参照してください。 ## メトリクス {#metrics} diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index 1d78585029fb3..7aa5e1a4589b5 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -11,7 +11,7 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす > **注記：** > -> スロークエリログが無効になっている場合、この機能は利用できません。スロークエリログはデフォルトで有効になっており、システム変数[`tidb_enable_slow_log`](/system-variables.md#tidb_enable_slow_log)使用して有効または無効にすることができます。 +> スロークエリログが無効になっている場合、この機能は利用できません。スロークエリログはデフォルトで有効になっており、システム変数[`tidb_enable_slow_log`](/system-variables.md#tidb_enable_slow_log)を使用して有効または無効にすることができます。 ## ページにアクセスしてください {#access-the-page} @@ -68,7 +68,7 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす ### 実行計画 {#execution-plans} -TiDB Dashboardでは、表、テキスト、グラフの 3 つの方法で実行計画を表示できます。実行計画の読み方については、[クエリ実行プランを理解する](/explain-overview.md)参照してください。 +TiDB Dashboardでは、表、テキスト、グラフの 3 つの方法で実行計画を表示できます。実行計画の読み方については、[クエリ実行プランを理解する](/explain-overview.md)を参照してください。 #### 実行計画を表形式で表示 {#execution-plan-in-table-format} diff --git a/dashboard/dashboard-statement-details.md b/dashboard/dashboard-statement-details.md index 60708616c333b..12847108cb852 100644 --- a/dashboard/dashboard-statement-details.md +++ b/dashboard/dashboard-statement-details.md @@ -63,7 +63,7 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま プランの実行詳細には次の情報が含まれます。 - SQLサンプル: プランに従って実際に実行された特定のSQL文のテキスト。時間範囲内で実行されたSQL文であれば、どれでもSQLサンプルとして使用できます。 -- 実行計画: 実行計画に関する完全な情報が、表、グラフ、テキストで表示されます。実行計画の詳細については、 [クエリ実行プランを理解する](/explain-overview.md)参照してください。複数の実行計画を選択した場合は、そのうちの1つだけが表示されます。 +- 実行計画: 実行計画に関する完全な情報が、表、グラフ、テキストで表示されます。実行計画の詳細については、 [クエリ実行プランを理解する](/explain-overview.md)を参照してください。複数の実行計画を選択した場合は、そのうちの1つだけが表示されます。 - SQL ステートメントの基本情報、実行時間、コプロセッサー読み取り、トランザクション、およびスロークエリについては、対応するタブ タイトルをクリックして、さまざまな情報を切り替えることができます。 ![Execution details of plans](/media/dashboard/dashboard-statement-plans-detail.png) diff --git a/dashboard/dashboard-user.md b/dashboard/dashboard-user.md index 59f9d980bfc21..99c5888d4af76 100644 --- a/dashboard/dashboard-user.md +++ b/dashboard/dashboard-user.md @@ -7,7 +7,7 @@ summary: TiDB Dashboardは、TiDBと同じユーザー権限システムを採 TiDB Dashboardは、TiDBと同じユーザー権限システムとサインイン認証を使用します。TiDB SQLユーザーを制御・管理することで、TiDB Dashboardへのアクセスを制限できます。このドキュメントでは、TiDB SQLユーザーがTiDB Dashboardにアクセスするために必要な最小限の権限について説明し、最小限の権限を持つSQLユーザーの作成方法とRBACによる認証方法を例示します。 -TiDB SQLユーザーを制御および管理する方法の詳細については、 [TiDB ユーザーアカウント管理](/user-account-management.md)参照してください。 +TiDB SQLユーザーを制御および管理する方法の詳細については、 [TiDB ユーザーアカウント管理](/user-account-management.md)を参照してください。 ## 必要な権限 {#required-privileges} @@ -39,7 +39,7 @@ TiDB SQLユーザーを制御および管理する方法の詳細については > **注記：** > -> `ALL PRIVILEGES`や`SUPER`といった高い権限を持つユーザーもTiDB Dashboardにサインインできます。したがって、最小権限の原則を遵守するために、意図しない操作を防ぐために、必要な権限のみを持つユーザーを作成することを強くお勧めします。これらの権限の詳細については、 [権限管理](/privilege-management.md)参照してください。 +> `ALL PRIVILEGES`や`SUPER`といった高い権限を持つユーザーもTiDB Dashboardにサインインできます。したがって、最小権限の原則を遵守するために、意図しない操作を防ぐために、必要な権限のみを持つユーザーを作成することを強くお勧めします。これらの権限の詳細については、 [権限管理](/privilege-management.md)を参照してください。 SQL ユーザーが前述の権限要件を満たしていない場合、以下に示すように、ユーザーは TiDB Dashboardへのサインインに失敗します。 diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index 801317cf7d310..d198d07366c6d 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -47,7 +47,7 @@ Top SQLは、パフォーマンスの問題を分析するのに適していま > **注記：** > -> Top SQLを使用するには、クラスターが最新バージョンのTiUP （v1.9.0以降）またはTiDB Operator （v1.3.0以降）を使用してデプロイまたはアップグレードされている必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、 [FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)参照して手順を確認してください。 +> Top SQLを使用するには、クラスターが最新バージョンのTiUP （v1.9.0以降）またはTiDB Operator （v1.3.0以降）を使用してデプロイまたはアップグレードされている必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、 [FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)を参照して手順を確認してください。 Top SQLは、有効にするとクラスタのパフォーマンスにわずかな影響（平均で3%以内）を与えるため、デフォルトでは有効になっていません。Top Top SQLを有効にするには、以下の手順に従ってください。 @@ -180,7 +180,7 @@ Top SQLのCPU次元の分析機能は維持したまま、TiKVの`Network Bytes` **1.Top SQLを有効にできず、UI に「必要なコンポーネントNgMonitoring が開始されていません」と表示されます**。 -[TiDB Dashboardに関するFAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)参照してください。 +[TiDB Dashboardに関するFAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)を参照してください。 **2.Top SQLを有効にすると、パフォーマンスに影響が出ますか？** diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index d208ab115d40a..da7c58017f076 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -5,7 +5,7 @@ summary: サポートされている日付と時刻の種類について説明 # 日付と時刻の型 {#date-and-time-types} -TiDBは、時間値を格納するためにMySQLのすべての日付と時刻データ型（ [`DATE`](#date-type) 、 [`TIME`](#time-type) 、 [`DATETIME`](#datetime-type) 、 [`TIMESTAMP`](#timestamp-type) 、 [`YEAR`](#year-type)をサポートしています。詳細については、 [MySQLの日付と時刻のデータ型](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-types.html)参照してください。 +TiDBは、時間値を格納するためにMySQLのすべての日付と時刻データ型（ [`DATE`](#date-type) 、 [`TIME`](#time-type) 、 [`DATETIME`](#datetime-type) 、 [`TIMESTAMP`](#timestamp-type) 、 [`YEAR`](#year-type)をサポートしています。詳細については、 [MySQLの日付と時刻のデータ型](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-types.html)を参照してください。 これらのタイプにはそれぞれ有効な値の範囲があり、無効な値を示すためにゼロ値が使用されます。さらに、タイプ`TIMESTAMP`とタイプ`DATETIME`では、変更時に新しい時刻値が自動的に生成されます。 diff --git a/data-type-default-values.md b/data-type-default-values.md index cdefc492e06a5..12e9e7c12db56 100644 --- a/data-type-default-values.md +++ b/data-type-default-values.md @@ -33,7 +33,7 @@ summary: TiDB のデータ型のデフォルト値について学習します。 ## 式をデフォルト値として指定する {#specify-expressions-as-default-values} -MySQL 8.0.13以降では、 `DEFAULT`句のデフォルト値として式を指定できるようになりました。詳細については、 [MySQL 8.0.13以降の明示的なデフォルト処理](https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit)参照してください。 +MySQL 8.0.13以降では、 `DEFAULT`句のデフォルト値として式を指定できるようになりました。詳細については、 [MySQL 8.0.13以降の明示的なデフォルト処理](https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit)を参照してください。 TiDB は、 `DEFAULT`句のデフォルト値として次の式を指定することをサポートしています。 @@ -69,7 +69,7 @@ CREATE TABLE t3 ( ); ``` -UUID の使用方法の詳細については、 [UUIDを主キーとして使用するベストプラクティス](/best-practices/uuid.md)参照してください。 +UUID の使用方法の詳細については、 [UUIDを主キーとして使用するベストプラクティス](/best-practices/uuid.md)を参照してください。 `JSON`使用例: diff --git a/data-type-json.md b/data-type-json.md index f52fa47cb2dc4..6e46f8e474a88 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -23,7 +23,7 @@ INSERT INTO city (id,detail) VALUES (1, '{"name": "Beijing", "population": 100}' SELECT id FROM city WHERE population >= 100; ``` -詳細については、 [JSON関数](/functions-and-operators/json-functions.md)および[生成された列](/generated-columns.md)参照してください。 +詳細については、 [JSON関数](/functions-and-operators/json-functions.md)および[生成された列](/generated-columns.md)を参照してください。 ## JSON値の型 {#json-value-types} @@ -122,4 +122,4 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` INSERT INTO t VALUES (3); ``` -`JSON`データ型の詳細については、 [JSON関数](/functions-and-operators/json-functions.md)および[生成された列](/generated-columns.md)参照してください。 +`JSON`データ型の詳細については、 [JSON関数](/functions-and-operators/json-functions.md)および[生成された列](/generated-columns.md)を参照してください。 diff --git a/data-type-numeric.md b/data-type-numeric.md index d0b1367493d8c..d207c01b002e9 100644 --- a/data-type-numeric.md +++ b/data-type-numeric.md @@ -13,7 +13,7 @@ TiDB は、以下を含むすべての MySQL 数値型をサポートしてい ## 整数型 {#integer-types} -TiDBは、 `INTEGER` / `INT` 、 `TINYINT` 、 `SMALLINT` 、 `MEDIUMINT` 、 `BIGINT`を含むすべてのMySQL整数型をサポートしています。詳細については、 [MySQLの整数データ型の構文](https://dev.mysql.com/doc/refman/8.0/en/integer-types.html)参照してください。 +TiDBは、 `INTEGER` / `INT` 、 `TINYINT` 、 `SMALLINT` 、 `MEDIUMINT` 、 `BIGINT`を含むすべてのMySQL整数型をサポートしています。詳細については、 [MySQLの整数データ型の構文](https://dev.mysql.com/doc/refman/8.0/en/integer-types.html)を参照してください。 次の表はフィールドの説明をまとめたものです。 @@ -113,7 +113,7 @@ BIGINT[(M)] [UNSIGNED] [ZEROFILL] ## 浮動小数点型 {#floating-point-types} -TiDBは、 `FLOAT` 、 `DOUBLE`含むすべてのMySQL浮動小数点型をサポートしています。詳細については、 [浮動小数点型（近似値） - MySQL の FLOAT、DOUBLE](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html)参照してください。 +TiDBは、 `FLOAT` 、 `DOUBLE`含むすべてのMySQL浮動小数点型をサポートしています。詳細については、 [浮動小数点型（近似値） - MySQL の FLOAT、DOUBLE](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html)を参照してください。 次の表はフィールドの説明をまとめたものです。 @@ -164,7 +164,7 @@ DOUBLE PRECISION [(M,D)] [UNSIGNED] [ZEROFILL], REAL[(M,D)] [UNSIGNED] [ZEROFILL > **注記：** > -> TiDBが科学表記法で表現された倍精度浮動小数点数を`CHAR`型に変換すると、MySQLでの表示と矛盾する結果が表示されます。詳細は[キャスト関数と演算子](/functions-and-operators/cast-functions-and-operators.md)参照してください。 +> TiDBが科学表記法で表現された倍精度浮動小数点数を`CHAR`型に変換すると、MySQLでの表示と矛盾する結果が表示されます。詳細は[キャスト関数と演算子](/functions-and-operators/cast-functions-and-operators.md)を参照してください。 ## 固定小数点型 {#fixed-point-types} diff --git a/data-type-string.md b/data-type-string.md index 05af978d4623b..c04aa62a96d6f 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -5,7 +5,7 @@ summary: TiDB でサポートされている文字列型について学習しま # 文字列型 {#string-types} -TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEXT` 、 `ENUM` 、 `SET`を含むすべてのMySQL文字列型をサポートしています。詳細については、 [MySQLの文字列型](https://dev.mysql.com/doc/refman/8.0/en/string-types.html)参照してください。 +TiDBは、 `CHAR` 、 `VARCHAR` 、 `BINARY` 、 `VARBINARY` 、 `BLOB` 、 `TEXT` 、 `ENUM` 、 `SET`を含むすべてのMySQL文字列型をサポートしています。詳細については、 [MySQLの文字列型](https://dev.mysql.com/doc/refman/8.0/en/string-types.html)を参照してください。 ## サポートされているタイプ {#supported-types} @@ -172,7 +172,7 @@ ENUM('apple', 'orange', 'pear') | 'オレンジ' | 2 | | '梨' | 3 | -詳細については[MySQLのENUM型](https://dev.mysql.com/doc/refman/8.0/en/enum.html)参照してください。 +詳細については[MySQLのENUM型](https://dev.mysql.com/doc/refman/8.0/en/enum.html)を参照してください。 ### SET型 {#code-set-code-type} @@ -203,4 +203,4 @@ TiDBでは、 `SET`型の値は内部的に`Int64`に変換されます。各要 この場合、 `('a', 'c')`の要素は 2 進数では`0101`になります。 -詳細については[MySQLのSET型](https://dev.mysql.com/doc/refman/8.0/en/set.html)参照してください。 +詳細については[MySQLのSET型](https://dev.mysql.com/doc/refman/8.0/en/set.html)を参照してください。 diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 27fc9f4c6bbc9..1d287abbac93a 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -14,7 +14,7 @@ summary: このドキュメントでは、新しく作成または再編成さ ## 使用シナリオ {#usage-scenarios} -DDL操作によってインデックスが交互に追加または変更されるシナリオでは、新しいインデックスに統計情報がないため、既存の安定したクエリに推定バイアスが生じ、オプティマイザーが最適ではないプランを選択する可能性があります。詳細については、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)参照してください。 +DDL操作によってインデックスが交互に追加または変更されるシナリオでは、新しいインデックスに統計情報がないため、既存の安定したクエリに推定バイアスが生じ、オプティマイザーが最適ではないプランを選択する可能性があります。詳細については、 [問題 #57948](https://github.com/pingcap/tidb/issues/57948)を参照してください。 例えば： @@ -43,7 +43,7 @@ v8.5.0以降、TiDBはインデックス間のヒューリスティック比較 ## `ADD INDEX` DDL {#add-index-ddl} -`tidb_stats_update_during_ddl`が`ON`の場合、 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)実行すると、再編成フェーズの終了後に埋め込まれた`ANALYZE`操作が自動的に実行されます。この`ANALYZE`操作は、新しく作成されたインデックスがユーザーに表示される前に、その統計情報を収集し、その後`ADD INDEX`残りのフェーズに進みます。 +`tidb_stats_update_during_ddl`が`ON`の場合、 [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)を実行すると、再編成フェーズの終了後に埋め込まれた`ANALYZE`操作が自動的に実行されます。この`ANALYZE`操作は、新しく作成されたインデックスがユーザーに表示される前に、その統計情報を収集し、その後`ADD INDEX`残りのフェーズに進みます。 `ANALYZE`時間がかかる可能性があることを考慮して、TiDB は最初の Reorg の実行時間に基づいてタイムアウトしきい値を設定します。3 `ANALYZE`タイムアウトすると、 `ADD INDEX` `ANALYZE`完了を同期的に待つのをやめ、後続のプロセスを続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、インデックス統計は`ANALYZE`非同期的に完了した後に更新されます。 diff --git a/develop/_index.md b/develop/_index.md index adf03f0a347e3..c03b94f5fa595 100644 --- a/develop/_index.md +++ b/develop/_index.md @@ -147,7 +147,7 @@ mysql2 ドライバーを使用して TiDB に接続します。 ## MySQLクライアントソフトウェアを使用する {#use-mysql-client-software} -TiDBはMySQL互換データベースであるため、多くの使い慣れたクライアントソフトウェアツールを使用してTiDBに接続し、データベースを管理できます。TiDB Cloudでは、 [コマンドラインツール](/tidb-cloud/get-started-with-cli.md)使用してデータベースに接続および管理することもできます。 +TiDBはMySQL互換データベースであるため、多くの使い慣れたクライアントソフトウェアツールを使用してTiDBに接続し、データベースを管理できます。TiDB Cloudでは、 [コマンドラインツール](/tidb-cloud/get-started-with-cli.md)を使用してデータベースに接続および管理することもできます。 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index 9e1e3004c6820..5afb463ad20fa 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-aws-appflow-integration/','/ja/tidb/dev/dev # TiDBとAmazon AppFlowを統合する {#integrate-tidb-with-amazon-appflow} -[Amazon AppFlow](https://aws.amazon.com/appflow/) Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。 +[Amazon AppFlow](https://aws.amazon.com/appflow/) Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)を参照してください。 このドキュメントでは、TiDBをAmazon AppFlowと統合する方法について説明し、 TiDB Cloud Starterインスタンスの統合を例として取り上げます。 diff --git a/develop/dev-guide-bookshop-schema-design.md b/develop/dev-guide-bookshop-schema-design.md index 4e670c179c14c..c78d8d39a3d8e 100644 --- a/develop/dev-guide-bookshop-schema-design.md +++ b/develop/dev-guide-bookshop-schema-design.md @@ -104,7 +104,7 @@ tiup demo bookshop prepare --users=200000 --books=500000 --authors=100000 --rati 4. **「接続」** ＞ **「インポート開始」**をクリックしてインポート処理を開始し、 TiDB Cloudインポート完了をお待ちください。 -データをTiDB Cloudにインポートまたは移行する方法の詳細については、 [TiDB Cloud移行の概要](https://docs.pingcap.com/tidbcloud/tidb-cloud-migration-overview)参照してください。 +データをTiDB Cloudにインポートまたは移行する方法の詳細については、 [TiDB Cloud移行の概要](https://docs.pingcap.com/tidbcloud/tidb-cloud-migration-overview)を参照してください。 ### データインポート状況を表示する {#view-data-import-status} diff --git a/develop/dev-guide-build-cluster-in-cloud.md b/develop/dev-guide-build-cluster-in-cloud.md index 6821f5ba2a4b3..2d3bf086601f9 100644 --- a/develop/dev-guide-build-cluster-in-cloud.md +++ b/develop/dev-guide-build-cluster-in-cloud.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/dev-guide-build-cluster-in-cloud/','/ja/tidb/dev/dev- # TiDB Cloud Starterインスタンスを作成する {#create-a-tidb-cloud-starter-instance} -このドキュメントでは、TiDB を使い始めるための最も簡単な方法を説明します。TiDB [TiDB Cloud](https://www.pingcap.com/tidb-cloud)使用してTiDB Cloud Starterインスタンスを作成し、それに接続して、サンプル アプリケーションを実行します。 +このドキュメントでは、TiDB を使い始めるための最も簡単な方法を説明します。TiDB [TiDB Cloud](https://www.pingcap.com/tidb-cloud)を使用してTiDB Cloud Starterインスタンスを作成し、それに接続して、サンプル アプリケーションを実行します。 ローカル マシンで TiDB を実行する必要がある場合は、 [TiDBをローカルで起動する](/quick-start-with-tidb.md)を参照してください。 @@ -34,7 +34,7 @@ aliases: ['/ja/tidb/stable/dev-guide-build-cluster-in-cloud/','/ja/tidb/dev/dev- > **注記：** > -> TiDB Cloud Starterインスタンスに接続するときは、ユーザー名にインスタンスのプレフィックスを含め、名前を引用符で囲む必要があります。詳細については、 [ユーザー名の接頭辞](https://docs.pingcap.com/tidbcloud/select-cluster-tier#user-name-prefix)参照してください。 +> TiDB Cloud Starterインスタンスに接続するときは、ユーザー名にインスタンスのプレフィックスを含め、名前を引用符で囲む必要があります。詳細については、 [ユーザー名の接頭辞](https://docs.pingcap.com/tidbcloud/select-cluster-tier#user-name-prefix)を参照してください。 ## ステップ2. TiDB Cloud Starterインスタンスに接続します {#step-2-connect-to-a-starter-instance} {#step-2-connect-to-a-starter-instance} diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 849f0068982c2..4a4a1f8f89f2f 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -15,7 +15,7 @@ aliases: ['/ja/tidb/stable/dev-guide-choose-driver-or-orm/','/ja/tidbcloud/dev-g > > 詳細については[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)を参照してください。 -TiDBはMySQLプロトコルと高い互換性がありますが、一部の機能はMySQLと互換性がありません。互換性の違いに関する完全なリストについては、 [MySQLの互換性](/mysql-compatibility.md)参照してください。 +TiDBはMySQLプロトコルと高い互換性がありますが、一部の機能はMySQLと互換性がありません。互換性の違いに関する完全なリストについては、 [MySQLの互換性](/mysql-compatibility.md)を参照してください。 ## Java {#java} @@ -34,7 +34,7 @@ TiDBはMySQLプロトコルと高い互換性がありますが、一部の機 > > MySQL Connector/J 8.0 の 8.0.31 より前のバージョンには[バグ](https://bugs.mysql.com/bug.php?id=106252)という問題があり（詳細は[MySQL JDBC のバグ](/develop/dev-guide-third-party-tools-compatibility.md#mysql-jdbc-bugs)参照）、TiDB バージョン 6.3.0 より前のバージョンを使用するとスレッドがハングする可能性があります。この問題を回避するには、MySQL Connector/J 8.0.31 以前のバージョンを使用し**ない**でください。 -完全なアプリケーションを構築する方法の例については、 [TiDBとJDBCを使用してシンプルなCRUDアプリを構築する](/develop/dev-guide-sample-application-java-jdbc.md)参照してください。 +完全なアプリケーションを構築する方法の例については、 [TiDBとJDBCを使用してシンプルなCRUDアプリを構築する](/develop/dev-guide-sample-application-java-jdbc.md)を参照してください。
@@ -93,7 +93,7 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67 > **注記：** > -> - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)実行します。 +> - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)。 > > - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。5 `@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 @@ -124,8 +124,8 @@ implementation 'org.hibernate:hibernate-core:6.2.3.Final' implementation 'mysql:mysql-connector-java:8.0.33' ``` -- Hibernate を使用してネイティブJavaで TiDB アプリケーションを構築する例については、 [TiDBとHibernateを使ったシンプルなCRUDアプリの構築](/develop/dev-guide-sample-application-java-hibernate.md)参照してください。 -- Spring Data JPA または Hibernate を使用して Spring で TiDB アプリケーションを構築する例については、 [Spring Bootを使用してTiDBアプリを構築する](/develop/dev-guide-sample-application-java-spring-boot.md)参照してください。 +- Hibernate を使用してネイティブJavaで TiDB アプリケーションを構築する例については、 [TiDBとHibernateを使ったシンプルなCRUDアプリの構築](/develop/dev-guide-sample-application-java-hibernate.md)を参照してください。 +- Spring Data JPA または Hibernate を使用して Spring で TiDB アプリケーションを構築する例については、 [Spring Bootを使用してTiDBアプリを構築する](/develop/dev-guide-sample-application-java-spring-boot.md)を参照してください。 さらに、 [Hibernate設定ファイル](https://www.tutorialspoint.com/hibernate/hibernate_configuration.htm) : `org.hibernate.dialect.TiDBDialect`で TiDB 方言を指定する必要があります。これは Hibernate `6.0.0.Beta2`以降でのみサポートされます。7 `Hibernate`バージョンが`6.0.0.Beta2`より前の場合は、まずアップグレードしてください。 @@ -139,7 +139,7 @@ implementation 'mysql:mysql-connector-java:8.0.33' サポートレベル:**フル** -アプリケーションのさまざまな依存関係間の複雑な関係を手動で管理することを避けるために、 [Gradle](https://gradle.org/install)または[Maven](https://maven.apache.org/install.html)使用して、間接的な依存関係も含め、アプリケーションのすべての依存関係を取得できます。 +アプリケーションのさまざまな依存関係間の複雑な関係を手動で管理することを避けるために、 [Gradle](https://gradle.org/install)または[Maven](https://maven.apache.org/install.html)を使用して、間接的な依存関係も含め、アプリケーションのすべての依存関係を取得できます。 Maven を使用している場合は、 ``に以下を追加します。 @@ -164,7 +164,7 @@ implementation 'org.mybatis:mybatis:3.5.13' implementation 'mysql:mysql-connector-java:8.0.33' ``` -MyBatis を使用して TiDB アプリケーションを構築する例については、 [TiDBとMyBatisを使ったシンプルなCRUDアプリの構築](/develop/dev-guide-sample-application-java-mybatis.md)参照してください。 +MyBatis を使用して TiDB アプリケーションを構築する例については、 [TiDBとMyBatisを使ったシンプルなCRUDアプリの構築](/develop/dev-guide-sample-application-java-mybatis.md)を参照してください。
@@ -218,7 +218,7 @@ implementation group: 'io.github.lastincisor', name: 'tidb-loadbalance', version Golangドライバーをダウンロードして設定するには、 [go-sql-driver/mysql ドキュメント](https://github.com/go-sql-driver/mysql)を参照してください。 -完全なアプリケーションを構築する方法の例については、 [Go-MySQL-Driver で TiDB に接続する](/develop/dev-guide-sample-application-golang-sql-driver.md)参照してください。 +完全なアプリケーションを構築する方法の例については、 [Go-MySQL-Driver で TiDB に接続する](/develop/dev-guide-sample-application-golang-sql-driver.md)を参照してください。 ### Golang ORMフレームワーク {#golang-orm-frameworks} @@ -233,7 +233,7 @@ go get -u gorm.io/gorm go get -u gorm.io/driver/mysql ``` -GORM を使用して TiDB アプリケーションを構築する例については、 [GORMでTiDBに接続する](/develop/dev-guide-sample-application-golang-gorm.md)参照してください。 +GORM を使用して TiDB アプリケーションを構築する例については、 [GORMでTiDBに接続する](/develop/dev-guide-sample-application-golang-gorm.md)を参照してください。 ## Python {#python} @@ -248,7 +248,7 @@ GORM を使用して TiDB アプリケーションを構築する例について [PyMySQLドキュメント](https://pypi.org/project/PyMySQL/)に従ってドライバをダウンロードし、設定してください。PyMySQL 1.0.2以降のバージョンの使用をお勧めします。 -PyMySQL を使用して TiDB アプリケーションを構築する例については、 [PyMySQLでTiDBに接続する](/develop/dev-guide-sample-application-python-pymysql.md)参照してください。 +PyMySQL を使用して TiDB アプリケーションを構築する例については、 [PyMySQLでTiDBに接続する](/develop/dev-guide-sample-application-python-pymysql.md)を参照してください。
@@ -257,7 +257,7 @@ PyMySQL を使用して TiDB アプリケーションを構築する例につい [mysqlclient ドキュメント](https://pypi.org/project/mysqlclient/)に従ってドライバをダウンロードし、設定してください。mysqlclient 2.1.1以降のバージョンを使用することをお勧めします。 -mysqlclient を使用して TiDB アプリケーションを構築する例については、 [mysqlclientでTiDBに接続する](/develop/dev-guide-sample-application-python-mysqlclient.md)参照してください。 +mysqlclient を使用して TiDB アプリケーションを構築する例については、 [mysqlclientでTiDBに接続する](/develop/dev-guide-sample-application-python-mysqlclient.md)を参照してください。
@@ -266,7 +266,7 @@ mysqlclient を使用して TiDB アプリケーションを構築する例に [MySQL Connector/Pythonドキュメント](https://dev.mysql.com/doc/connector-python/en/connector-python-installation-binary.html)に従ってドライバをダウンロードし、設定してください。Connector/Python 8.0.31以降のバージョンを使用することをお勧めします。 -MySQL Connector/Python を使用して TiDB アプリケーションを構築する例については、 [MySQL Connector/Python で TiDB に接続する](/develop/dev-guide-sample-application-python-mysql-connector.md)参照してください。 +MySQL Connector/Python を使用して TiDB アプリケーションを構築する例については、 [MySQL Connector/Python で TiDB に接続する](/develop/dev-guide-sample-application-python-mysql-connector.md)を参照してください。
@@ -280,7 +280,7 @@ MySQL Connector/Python を使用して TiDB アプリケーションを構築す [Django](https://docs.djangoproject.com/)は人気のPythonウェブフレームワークです。TiDBとDjangoの互換性問題を解決するため、PingCAPはTiDB方言`django-tidb`を提供しています。インストールするには、 [`django-tidb`ドキュメント](https://github.com/pingcap/django-tidb#installation-guide)を参照してください。 -Django を使用して TiDB アプリケーションを構築する例については、 [Django で TiDB に接続する](/develop/dev-guide-sample-application-python-django.md)参照してください。 +Django を使用して TiDB アプリケーションを構築する例については、 [Django で TiDB に接続する](/develop/dev-guide-sample-application-python-django.md)を参照してください。
@@ -289,7 +289,7 @@ Django を使用して TiDB アプリケーションを構築する例につい [SQLAlchemy](https://www.sqlalchemy.org/)はPythonで人気のORMフレームワークです。アプリケーション内のすべての依存関係を取得するには、 `pip install SQLAlchemy==1.4.44`コマンドを使用します。SQLAlchemy 1.4.44以降のバージョンの使用をお勧めします。 -SQLAlchemy を使用して TiDB アプリケーションを構築する例については、 [SQLAlchemy で TiDB に接続する](/develop/dev-guide-sample-application-python-sqlalchemy.md)参照してください。 +SQLAlchemy を使用して TiDB アプリケーションを構築する例については、 [SQLAlchemy で TiDB に接続する](/develop/dev-guide-sample-application-python-sqlalchemy.md)を参照してください。
@@ -298,7 +298,7 @@ SQLAlchemy を使用して TiDB アプリケーションを構築する例につ [Peewee](http://docs.peewee-orm.com/en/latest/)はPythonで人気のORMフレームワークです。アプリケーション内のすべての依存関係を取得するには、 `pip install peewee==3.15.4`コマンドを使用します。peewee 3.15.4以降のバージョンの使用をお勧めします。 -peewee を使用して TiDB アプリケーションを構築する例については、 [peeweeでTiDBに接続する](/develop/dev-guide-sample-application-python-peewee.md)参照してください。 +peewee を使用して TiDB アプリケーションを構築する例については、 [peeweeでTiDBに接続する](/develop/dev-guide-sample-application-python-peewee.md)を参照してください。
diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index 3e4cf68bccf8d..0d936b825c689 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -26,7 +26,7 @@ Javaには[Tomcat JDBC](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool.html 接続プールのサイズは、アプリケーションのニーズに合わせて適切に調整するのが一般的です。HikariCPを例にとってみましょう。 -- **maximumPoolSize** : コネクションプール内の最大接続数。この値が大きすぎると、TiDB は不要な接続を維持するためにリソースを消費します。この値が小さすぎると、アプリケーションの接続が遅くなります。したがって、アプリケーションの特性に応じてこの値を構成する必要があります。詳細については、 [プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)参照してください。 +- **maximumPoolSize** : コネクションプール内の最大接続数。この値が大きすぎると、TiDB は不要な接続を維持するためにリソースを消費します。この値が小さすぎると、アプリケーションの接続が遅くなります。したがって、アプリケーションの特性に応じてこの値を構成する必要があります。詳細については、 [プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してください。 - **minimumIdle** ：接続プール内のアイドル接続の最小数。主に、アプリケーションがアイドル状態のときに突発的なリクエストに対応するために、一部の接続を確保するために使用されます。アプリケーションの特性に合わせて設定する必要があります。 アプリケーションは、接続の使用が終了したら、その接続を返却する必要があります。接続プールの問題を早期に発見するために、アプリケーションは適切な接続プール監視ツール（ **metricRegistry**など）を使用することをお勧めします。 @@ -68,7 +68,7 @@ TiDBサーバーがシャットダウン、メンテナンスのために再起 接続プールは、以下のようにクライアントからTiDBへの永続的な接続を維持します。 - バージョン5.4より前のTiDBでは、デフォルトでは（エラーが報告されない限り）クライアント接続を積極的に閉じることはありません。 -- バージョン5.4以降、TiDBはデフォルトで`28800`秒間（つまり`8`時間）の非アクティブ状態が続くとクライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBとMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)参照してください。 +- バージョン5.4以降、TiDBはデフォルトで`28800`秒間（つまり`8`時間）の非アクティブ状態が続くとクライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBとMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)を参照してください。 さらに、クライアントとTiDBの間には、 [LVS](https://en.wikipedia.org/wiki/Linux_Virtual_Server)や[HAProxy](https://en.wikipedia.org/wiki/HAProxy)ようなネットワークプロキシが存在する場合があります。これらのプロキシは通常、特定のアイドル期間（プロキシのアイドル設定によって決定されます）が経過すると、接続を自動的にクリーンアップします。接続プールは、プロキシのアイドル設定を監視するだけでなく、キープアライブのために接続を維持またはプローブする必要もあります。 @@ -140,7 +140,7 @@ Javaアプリケーションは、さまざまなフレームワークでカプ ### JDBC API {#jdbc-api} -JDBC API の使用方法については、 [JDBC公式チュートリアル](https://docs.oracle.com/javase/tutorial/jdbc/)参照してください。このセクションでは、いくつかの重要な API の使用方法について説明します。 +JDBC API の使用方法については、 [JDBC公式チュートリアル](https://docs.oracle.com/javase/tutorial/jdbc/)を参照してください。このセクションでは、いくつかの重要な API の使用方法について説明します。 #### Prepare APIを使用する {#use-prepare-api} diff --git a/develop/dev-guide-create-database.md b/develop/dev-guide-create-database.md index 000dc0628e1a5..8f3e6fbc2a25f 100644 --- a/develop/dev-guide-create-database.md +++ b/develop/dev-guide-create-database.md @@ -78,7 +78,7 @@ mysql ## 次のステップ {#next-step} -データベースを作成したら、そこに**テーブル**を追加できます。詳細については、[テーブルを作成する](/develop/dev-guide-create-table.md)参照してください。 +データベースを作成したら、そこに**テーブル**を追加できます。詳細については、[テーブルを作成する](/develop/dev-guide-create-table.md)を参照してください。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-create-secondary-indexes.md b/develop/dev-guide-create-secondary-indexes.md index 3634b1a282394..509ead4ee1e62 100644 --- a/develop/dev-guide-create-secondary-indexes.md +++ b/develop/dev-guide-create-secondary-indexes.md @@ -21,7 +21,7 @@ aliases: ['/ja/tidb/stable/dev-guide-create-secondary-indexes/','/ja/tidb/dev/de TiDBにおけるセカンダリインデックスは論理オブジェクトです。簡単に言えば、TiDBがクエリパフォーマンスを向上させるために使用するソートタイプのデータと考えることができます。TiDBでは、セカンダリインデックスの作成はオンライン操作であり、テーブルに対するデータの読み書き操作をブロックしません。TiDBは、各インデックスに対してテーブルの各行への参照を作成し、データ自体ではなく、選択された列に基づいて参照をソートします。 -セカンダリインデックスの詳細については、 [セカンダリインデックス](/best-practices/tidb-best-practices.md#secondary-index)参照してください。 +セカンダリインデックスの詳細については、 [セカンダリインデックス](/best-practices/tidb-best-practices.md#secondary-index)を参照してください。 TiDB では、[既存のテーブルにセカンダリインデックスを追加する](#add-a-secondary-index-to-an-existing-table)か[新しいテーブルを作成する際にセカンダリインデックスを作成する](#create-a-secondary-index-when-creating-a-new-table)ことができます。 @@ -131,7 +131,7 @@ CREATE INDEX `idx_book_published_at` ON `bookshop`.`books` (`bookshop`.`books`.` 出力では、 **TableFullScan**の代わりに**IndexRangeScan**が表示されます。これは、TiDB がインデックスを使用してこのクエリを実行する準備ができていることを意味します。 -実行プラン内の**TableFullScan**や**IndexRangeScan**などの単語は、TiDB では[オペレーター](/explain-overview.md#operator-overview)です。実行プランと演算子の詳細については、 [TiDBクエリ実行プランの概要](/explain-overview.md)参照してください。 +実行プラン内の**TableFullScan**や**IndexRangeScan**などの単語は、TiDB では[オペレーター](/explain-overview.md#operator-overview)です。実行プランと演算子の詳細については、 [TiDBクエリ実行プランの概要](/explain-overview.md)を参照してください。 実行プランは毎回同じ演算子を返すとは限りません。これは、TiDBが**コストベース最適化（CBO）**方式を採用しているためで、実行プランはルールとデータ分布の両方に依存します。 diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 5a9770d08f350..24bbf8f156f30 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -190,7 +190,7 @@ CREATE TABLE `bookshop`.`ratings` ( ); ``` -さまざまなデータ型のデフォルト値の詳細については、[デフォルト値](/data-type-default-values.md)参照してください。 +さまざまなデータ型のデフォルト値の詳細については、[デフォルト値](/data-type-default-values.md)を参照してください。 ### 重複値を防止する {#prevent-duplicate-values} @@ -228,7 +228,7 @@ CREATE TABLE `bookshop`.`users` ( > **注記：** > -> このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)参照してください。 +> このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)を参照してください。 `ratings`アプリケーションを使用して`bookshop`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合`score`フィールドと`rated_at` `ratings` } フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。 @@ -249,7 +249,7 @@ ALTER TABLE {table_name} SET TIFLASH REPLICA {count}; - `{table_name}` : テーブル名。 - `{count}` : 複製されたレプリカの数。0 の場合、複製されたレプリカは削除されます。 -**TiFlash は**テーブルを複製します。クエリが実行されると、TiDB はコストの最適化に基づいてクエリに対して TiKV (行ベース) またはTiFlash (列ベース) を自動的に選択します。あるいは、クエリで**TiFlash**レプリカを使用するかどうかを手動で指定できます。指定方法については、 [TiDBを使用してTiFlashレプリカを読み取ります](/tiflash/use-tidb-to-read-tiflash.md)参照してください。 +**TiFlash は**テーブルを複製します。クエリが実行されると、TiDB はコストの最適化に基づいてクエリに対して TiKV (行ベース) またはTiFlash (列ベース) を自動的に選択します。あるいは、クエリで**TiFlash**レプリカを使用するかどうかを手動で指定できます。指定方法については、 [TiDBを使用してTiFlashレプリカを読み取ります](/tiflash/use-tidb-to-read-tiflash.md)を参照してください。 ### HTAP機能の使用例 {#an-example-of-using-htap-capabilities} diff --git a/develop/dev-guide-delete-data.md b/develop/dev-guide-delete-data.md index 17dfb72fe382a..8d76a3db58ea7 100644 --- a/develop/dev-guide-delete-data.md +++ b/develop/dev-guide-delete-data.md @@ -29,7 +29,7 @@ DELETE FROM {table} WHERE {filter} | `{table}` | テーブル名 | | `{filter}` | フィルターの適合条件 | -この例は`DELETE`の簡単な使用例のみを示しています。詳細については、 [DELETE構文](/sql-statements/sql-statement-delete.md)参照してください。 。 +この例は`DELETE`の簡単な使用例のみを示しています。詳細については、 [DELETE構文](/sql-statements/sql-statement-delete.md)を参照してください。 。 ## ベストプラクティス {#best-practices} diff --git a/develop/dev-guide-get-data-from-single-table.md b/develop/dev-guide-get-data-from-single-table.md index 2599f00e180ac..1d5c4bbce1f13 100644 --- a/develop/dev-guide-get-data-from-single-table.md +++ b/develop/dev-guide-get-data-from-single-table.md @@ -292,7 +292,7 @@ public List getAuthorsWithLimit(Integer limit) throws SQLException { +-----------+------------------------+------------+ 10 rows in set (0.11 sec) -この例では、 `LIMIT`ステートメントを使用すると、クエリ時間が`0.23 sec`から`0.11 sec`に大幅に短縮されます。詳細については、 [TopNとLimit](/topn-limit-push-down.md)参照してください。 +この例では、 `LIMIT`ステートメントを使用すると、クエリ時間が`0.23 sec`から`0.11 sec`に大幅に短縮されます。詳細については、 [TopNとLimit](/topn-limit-push-down.md)を参照してください。 ## 集計クエリ {#aggregate-queries} @@ -368,7 +368,7 @@ public List getAuthorCountsByBirthYear() throws SQLException { +------------+--------------+ 71 rows in set (0.00 sec) -`COUNT`関数に加えて、TiDB は他の集計関数もサポートしています。詳細については、 [集計（GROUP BY）関数](/functions-and-operators/aggregate-group-by-functions.md)参照してください。 +`COUNT`関数に加えて、TiDB は他の集計関数もサポートしています。詳細については、 [集計（GROUP BY）関数](/functions-and-operators/aggregate-group-by-functions.md)を参照してください。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-gui-datagrip.md b/develop/dev-guide-gui-datagrip.md index b750f78793fc7..ddd336a3d32b7 100644 --- a/develop/dev-guide-gui-datagrip.md +++ b/develop/dev-guide-gui-datagrip.md @@ -128,7 +128,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を起動し、接続を管理するためのプロジェクトを作成します。 diff --git a/develop/dev-guide-gui-dbeaver.md b/develop/dev-guide-gui-dbeaver.md index 006dbf29f84b3..47b61aed7d484 100644 --- a/develop/dev-guide-gui-dbeaver.md +++ b/develop/dev-guide-gui-dbeaver.md @@ -136,7 +136,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を**選択し、 **「次へ」**をクリックします。 @@ -202,7 +202,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt ## 次のステップ {#next-steps} -- DBeaver の使用法の詳細については[DBeaverのドキュメント](https://github.com/dbeaver/dbeaver/wiki)参照してください。 +- DBeaver の使用法の詳細については[DBeaverのドキュメント](https://github.com/dbeaver/dbeaver/wiki)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-gui-mysql-workbench.md b/develop/dev-guide-gui-mysql-workbench.md index 08f42857eb2b3..6572740d42f17 100644 --- a/develop/dev-guide-gui-mysql-workbench.md +++ b/develop/dev-guide-gui-mysql-workbench.md @@ -124,7 +124,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」**タイトルの横にある**「+」**をクリックします。 @@ -191,7 +191,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ## 次のステップ {#next-steps} -- MySQL Workbench の使用法の詳細については[MySQL Workbenchのドキュメント](https://dev.mysql.com/doc/workbench/en/)参照してください。 +- MySQL Workbench の使用法の詳細については[MySQL Workbenchのドキュメント](https://dev.mysql.com/doc/workbench/en/)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-gui-navicat.md b/develop/dev-guide-gui-navicat.md index 8fd977200f199..9306ae8021e9c 100644 --- a/develop/dev-guide-gui-navicat.md +++ b/develop/dev-guide-gui-navicat.md @@ -122,7 +122,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 ddbe5e0250abd..d1402c90d4012 100644 --- a/develop/dev-guide-gui-vscode-sqltools.md +++ b/develop/dev-guide-gui-vscode-sqltools.md @@ -83,7 +83,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code > **注記：** > - > Windows または GitHub コードスペースで実行している場合は、 **SSL を**空白のままにすることができます。デフォルトでは、SQLTools は Let's Encrypt によって厳選された有名な CA を信頼します。詳細については、 [TiDB Cloud Starterルート証明書管理](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters#root-certificate-management)参照してください。 + > Windows または GitHub コードスペースで実行している場合は、 **SSL を**空白のままにすることができます。デフォルトでは、SQLTools は Let's Encrypt によって厳選された有名な CA を信頼します。詳細については、 [TiDB Cloud Starterルート証明書管理](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters#root-certificate-management)を参照してください。 ![VS Code SQLTools: configure connection settings for TiDB Cloud Starter](/media/develop/vsc-sqltools-connection-config-serverless.jpg) @@ -150,7 +150,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**を選択します。 @@ -230,7 +230,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code ## 次のステップ {#next-steps} -- Visual Studio Code の使用法の詳細については[Visual Studio Code のドキュメント](https://code.visualstudio.com/docs)参照してください。 +- Visual Studio Code の使用法の詳細については[Visual Studio Code のドキュメント](https://code.visualstudio.com/docs)を参照してください。 - VS Code SQLTools 拡張機能の使用法について詳しくは、SQLTools の[ドキュメント](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools)および[GitHubリポジトリ](https://github.com/mtxr/vscode-sqltools)ご覧ください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 97e82221730e6..16d549c7956db 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} @@ -143,7 +143,7 @@ TiDB は、より多くの分析ステートメントのために、集約され ### TiFlashレプリカを作成する {#create-tiflash-replicas} -TiDB はデフォルトで行ベースのストレージエンジン TiKV を使用します。列指向ストレージエンジンTiFlashを使用するには、 [HTAP機能を有効にする](/develop/dev-guide-create-table.md#use-htap-capabilities)参照してください。TiFlashを介してデータをクエリする前に、次のステートメントを使用して`books`および`orders`テーブルのTiFlashレプリカを作成する必要があります。 +TiDB はデフォルトで行ベースのストレージエンジン TiKV を使用します。列指向ストレージエンジンTiFlashを使用するには、 [HTAP機能を有効にする](/develop/dev-guide-create-table.md#use-htap-capabilities)を参照してください。TiFlashを介してデータをクエリする前に、次のステートメントを使用して`books`および`orders`テーブルのTiFlashレプリカを作成する必要があります。 ```sql ALTER TABLE books SET TIFLASH REPLICA 1; @@ -235,7 +235,7 @@ SELECT * FROM acc; `EXPLAIN`ステートメントを使用して、上記のSQL文の実行プランを確認できます。タスク列に`cop[tiflash]`と`cop[tikv]`同時に表示される場合、 TiFlashと TiKV の両方がこのクエリを完了するようにスケジュールされていることを意味します。TiFlash と TiKV のストレージエンジンは通常、異なる TiDB ノードを使用するため、2 つのクエリタイプは互いに影響を受けません。 -TiDBがTiFlashをどのように使用するかの詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)参照してください。 +TiDBがTiFlashをどのように使用するかの詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)を参照してください。 ## 続きを読む {#read-more} diff --git a/develop/dev-guide-index-best-practice.md b/develop/dev-guide-index-best-practice.md index e0d54bf6a4520..23695877a91eb 100644 --- a/develop/dev-guide-index-best-practice.md +++ b/develop/dev-guide-index-best-practice.md @@ -93,7 +93,7 @@ CREATE TABLE `books` ( > **警告：** > - > 現在、式インデックスは実験的機能であり、TiDB設定ファイルで有効化する必要があります。詳細については[式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)参照してください。 + > 現在、式インデックスは実験的機能であり、TiDB設定ファイルで有効化する必要があります。詳細については[式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 - クエリ対象の列がインデックス内の列に含まれるカバーリング インデックスを使用するようにし、 `SELECT *`ステートメントですべての列をクエリすることは避けてください。 @@ -121,7 +121,7 @@ CREATE TABLE `books` ( SELECT * FROM books WHERE title LIKE '%database'; ``` -- クエリ条件に複数のインデックスがあり、実際にどのインデックスが最適かわかっている場合は、 [オプティマイザーヒント](/optimizer-hints.md)指定してTiDBオプティマイザにそのインデックスを強制的に使用させることをお勧めします。これにより、統計情報の不正確さやその他の問題により、TiDBオプティマイザが誤ったインデックスを選択することを防ぐことができます。 +- クエリ条件に複数のインデックスがあり、実際にどのインデックスが最適かわかっている場合は、 [オプティマイザーヒント](/optimizer-hints.md)を指定してTiDBオプティマイザにそのインデックスを強制的に使用させることをお勧めします。これにより、統計情報の不正確さやその他の問題により、TiDBオプティマイザが誤ったインデックスを選択することを防ぐことができます。 次のクエリでは、インデックス`id_idx`と`title_idx`それぞれ列`id`と`title`で使用可能であると仮定し、 `id_idx`方が適していることが分かっている場合は、SQL で`USE INDEX`ヒントを使用して、TiDB オプティマイザーに`id_idx`インデックスを使用するように強制できます。 diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index 11a2d98884efe..e152bce66fcda 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -210,7 +210,7 @@ TiDB は、次の一般的なテーブル結合アルゴリズムをサポート オプティマイザは、結合対象テーブルのデータ量などの要因に基づいて、適切な結合アルゴリズムを選択します。クエリが結合にどのアルゴリズムを使用しているかは、 `EXPLAIN`ステートメントで確認できます。 -TiDB のオプティマイザーが最適な結合アルゴリズムに従って実行されない場合は、 [オプティマイザヒント](/optimizer-hints.md)使用して、TiDB がより適切な結合アルゴリズムを使用するように強制できます。 +TiDB のオプティマイザーが最適な結合アルゴリズムに従って実行されない場合は、 [オプティマイザヒント](/optimizer-hints.md)を使用して、TiDB がより適切な結合アルゴリズムを使用するように強制できます。 例えば、上記の左結合クエリの例が、オプティマイザによって選択されないハッシュ結合アルゴリズムを使用した方が高速に実行されると仮定すると、キーワード`SELECT`後にヒント`/*+ HASH_JOIN(b, r) */`を追加できます。テーブルに別名がある場合は、ヒントでも別名を使用することに注意してください。 @@ -242,7 +242,7 @@ FROM authors a STRAIGHT_JOIN book_authors ba STRAIGHT_JOIN books b WHERE b.id = ba.book_id AND ba.author_id = a.id; ``` -この結合したテーブルの再配置アルゴリズムの実装の詳細と制限の詳細については、 [結合したテーブルの再配置アルゴリズムの紹介](/join-reorder.md)参照してください。 +この結合したテーブルの再配置アルゴリズムの実装の詳細と制限の詳細については、 [結合したテーブルの再配置アルゴリズムの紹介](/join-reorder.md)を参照してください。 ## 参照 {#see-also} diff --git a/develop/dev-guide-mysql-tools.md b/develop/dev-guide-mysql-tools.md index 2962e9c001d54..32182b751fa31 100644 --- a/develop/dev-guide-mysql-tools.md +++ b/develop/dev-guide-mysql-tools.md @@ -5,7 +5,7 @@ summary: MySQL ツールを使用して TiDB に接続する方法を学習し # MySQLツールでTiDBに接続する {#connect-to-tidb-with-mysql-tools} -TiDBはMySQLプロトコルと高い互換性があります。クライアントリンクパラメータの完全なリストについては、 [MySQLクライアントオプション](https://dev.mysql.com/doc/refman/8.0/en/mysql-command-options.html)参照してください。 +TiDBはMySQLプロトコルと高い互換性があります。クライアントリンクパラメータの完全なリストについては、 [MySQLクライアントオプション](https://dev.mysql.com/doc/refman/8.0/en/mysql-command-options.html)を参照してください。 TiDB は[MySQL クライアント/サーバー プロトコル](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html)をサポートしており、これにより、ほとんどのクライアント ドライバーと ORM フレームワークは、MySQL に接続するのと同じように TiDB に接続できます。 diff --git a/develop/dev-guide-object-naming-guidelines.md b/develop/dev-guide-object-naming-guidelines.md index 5a302885119e7..5d90a7849b6ea 100644 --- a/develop/dev-guide-object-naming-guidelines.md +++ b/develop/dev-guide-object-naming-guidelines.md @@ -37,7 +37,7 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d - 列に注釈を追加し、「0: オフライン、1: オンライン」などの列挙型の名前付きの値を指定することをお勧めします。 - ブール列の名前は`is_{description}`にすることをお勧めします。例えば、 `member`テーブルの、メンバーが有効かどうかを示す列の名前は`is_enabled`にすることができます。 - 列名を 30 文字以上にすることは推奨されません。また、列の数は 60 未満にする必要があります。 -- `order` 、 `from` 、 `desc`などのTiDB予約語を列名として使用しないでください。キーワードが予約されているかどうかを確認するには、 [TiDBキーワード](/keywords.md)参照してください。 +- `order` 、 `from` 、 `desc`などのTiDB予約語を列名として使用しないでください。キーワードが予約されているかどうかを確認するには、 [TiDBキーワード](/keywords.md)を参照してください。 ## インデックスの命名規則 {#index-naming-convention} diff --git a/develop/dev-guide-optimistic-and-pessimistic-transaction.md b/develop/dev-guide-optimistic-and-pessimistic-transaction.md index e8d7cc7f92f14..1efa4cc5aee8f 100644 --- a/develop/dev-guide-optimistic-and-pessimistic-transaction.md +++ b/develop/dev-guide-optimistic-and-pessimistic-transaction.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimistic-and-pessimistic-transaction/','/
-複数のユーザーが同時にデータを挿入する状況をシミュレートするために複数のスレッドを使用するため、安全なスレッドを備えた接続オブジェクトを使用する必要があります。ここでは、デモとしてJavaの一般的な接続プール[HikariCP](https://github.com/brettwooldridge/HikariCP)使用します。 +複数のユーザーが同時にデータを挿入する状況をシミュレートするために複数のスレッドを使用するため、安全なスレッドを備えた接続オブジェクトを使用する必要があります。ここでは、デモとしてJavaの一般的な接続プール[HikariCP](https://github.com/brettwooldridge/HikariCP)を使用します。
diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index dad031a4c803e..37363f5888347 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -97,11 +97,11 @@ SELECT title, price FROM books WHERE title = 'Marian Yost'; ### 一括削除を使用する {#use-bulk-delete} -大量のデータを削除する場合は[一括削除](/develop/dev-guide-delete-data.md#bulk-delete)使用することをお勧めします。 +大量のデータを削除する場合は[一括削除](/develop/dev-guide-delete-data.md#bulk-delete)を使用することをお勧めします。 ### 一括更新を使用する {#use-bulk-update} -大量のデータを更新する場合は[一括更新](/develop/dev-guide-update-data.md#bulk-update)使用することをお勧めします。 +大量のデータを更新する場合は[一括更新](/develop/dev-guide-update-data.md#bulk-update)を使用することをお勧めします。 ### テーブルデータ全体を取得するには、 DELETEではなくTRUNCATE使用します。 {#use-code-truncate-code-instead-of-code-delete-code-for-full-table-data} @@ -152,7 +152,7 @@ SET @@global.tidb_ddl_reorg_batch_size = 128; ## トランザクションの競合 {#transaction-conflicts} -トランザクションの競合を見つけて解決する方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)参照してください。 +トランザクションの競合を見つけて解決する方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)を参照してください。 ## TiDB を使用したJavaアプリケーション開発のベスト プラクティス {#best-practices-for-developing-java-applications-with-tidb} diff --git a/develop/dev-guide-optimize-sql-overview.md b/develop/dev-guide-optimize-sql-overview.md index cb36532f64902..0cd77a5624180 100644 --- a/develop/dev-guide-optimize-sql-overview.md +++ b/develop/dev-guide-optimize-sql-overview.md @@ -18,14 +18,14 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev- - スキャンする行数はできるだけ少なくしてください。必要なデータのみをスキャンし、余分なデータのスキャンは避けることをお勧めします。 - 適切なインデックスを使用してください。SQLの`WHERE`句の列に対応するインデックスがあることを確認してください。インデックスがない場合、文はフルテーブルスキャンを必要とし、パフォーマンスが低下します。 - 適切な結合タイプを使用してください。クエリに含まれるテーブルの相対的なサイズに基づいて、適切な結合タイプを選択することが重要です。通常、TiDBのコストベースオプティマイザは、パフォーマンスが最も高い結合タイプを選択します。ただし、場合によっては、より適切な結合タイプを手動で指定する必要があることもあります。 -- 適切なストレージエンジンを使用してください。OLTPとOLAPのハイブリッドワークロードには、 TiFlashエンジンが推奨されます。詳細については、 [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)参照してください。 +- 適切なストレージエンジンを使用してください。OLTPとOLAPのハイブリッドワークロードには、 TiFlashエンジンが推奨されます。詳細については、 [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)を参照してください。 ## スキーマ設計 {#schema-design} [SQLパフォーマンスのチューニング](#sql-performance-tuning)後もアプリケーションのパフォーマンスがまだ良好でない場合は、次の問題を回避するためにスキーマ設計とデータ アクセス パターンを確認する必要がある可能性があります。 -- トランザクションの競合。トランザクションの競合を診断して解決する方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)参照してください。 -- ホットスポット。ホットスポットの診断と解決方法については、 [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)参照してください。 +- トランザクションの競合。トランザクションの競合を診断して解決する方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)を参照してください。 +- ホットスポット。ホットスポットの診断と解決方法については、 [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)を参照してください。 ### 参照 {#see-also} diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index bb19a3490b725..3b9fdbd42522a 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql/','/ja/tidbcloud/dev-guide-opt ## 始める前に {#before-you-begin} -[`tiup demo`インポート](/develop/dev-guide-bookshop-schema-design.md#tidb-self-managed-via-tiup-demo)使用してデータを準備できます。 +[`tiup demo`インポート](/develop/dev-guide-bookshop-schema-design.md#tidb-self-managed-via-tiup-demo)を使用してデータを準備できます。 ```shell tiup demo bookshop prepare --host 127.0.0.1 --port 4000 --books 1000000 @@ -60,7 +60,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; 実行プランの`TableFullScan_5`からわかるように、TiDBは`books`番目のテーブルに対してフルテーブルスキャンを実行し、各行について`title`条件を満たすかどうかを確認します。9の`estRows` `TableFullScan_5`の値は`1000000.00`です。これは、オプティマイザがこのフルテーブルスキャンで`1000000.00`行のデータが使用されると見積もっていることを意味します。 -`EXPLAIN`の使用方法の詳細については、 [`EXPLAIN`ウォークスルー](/explain-walkthrough.md)参照してください。 +`EXPLAIN`の使用方法の詳細については、 [`EXPLAIN`ウォークスルー](/explain-walkthrough.md)を参照してください。 ### 解決策: セカンダリインデックスを使用する {#solution-use-secondary-index} @@ -110,7 +110,7 @@ EXPLAIN SELECT * FROM books WHERE title = 'Marian Yost'; 実行プラン`IndexLookup_10`では、まず`IndexRangeScan_8`演算子を使用して`title_idx`インデックスを通じて条件を満たすインデックス データを読み取り、次に`TableLookup_9`演算子を使用して、インデックス データに格納されている行 ID に従って対応する行をクエリします。 -TiDB 実行プランの詳細については、 [TiDB クエリ実行プランの概要](/explain-overview.md)参照してください。 +TiDB 実行プランの詳細については、 [TiDB クエリ実行プランの概要](/explain-overview.md)を参照してください。 ### 解決策: カバーインデックスを使用する {#solution-use-covering-index} diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index b6956c2d29059..c7eb60bcfddc1 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -216,7 +216,7 @@ pageMetaList.forEach((pageMeta) -> { > **ヒント：** > -> `SHOW CREATE TABLE users;`ステートメントを使用して、テーブルの主キーが[クラスター化インデックス](/clustered-indexes.md)使用しているかどうかを確認できます。 +> `SHOW CREATE TABLE users;`ステートメントを使用して、テーブルの主キーが[クラスター化インデックス](/clustered-indexes.md)を使用しているかどうかを確認できます。 例えば： diff --git a/develop/dev-guide-playground-gitpod.md b/develop/dev-guide-playground-gitpod.md index ec7757b488077..184248f923ad2 100644 --- a/develop/dev-guide-playground-gitpod.md +++ b/develop/dev-guide-playground-gitpod.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/dev-guide-playground-gitpod/','/ja/tidbcloud/dev-guid # GitPod {#gitpod} -[GitPod](https://www.gitpod.io/)使用すると、ボタンまたはリンクをクリックするだけでブラウザ内で完全な開発環境が得られ、すぐにコードを記述できます。 +[GitPod](https://www.gitpod.io/)を使用すると、ボタンまたはリンクをクリックするだけでブラウザ内で完全な開発環境が得られ、すぐにコードを記述できます。 Gitpodは、コードを直接記述する開発環境向けのオープンソースKubernetesアプリケーション（GitHubリポジトリアドレス： [https://github.com/gitpod-io/gitpod](https://github.com/gitpod-io/gitpod) ）です。クラウド上で、タスクごとに最新の自動化開発環境を数秒で構築します。開発環境をコードとして記述し、ブラウザまたはデスクトップIDEから直接、リモートおよびクラウドベースの開発環境を即座に開始できます。 @@ -34,7 +34,7 @@ Gitpodは、コードを直接記述する開発環境向けのオープンソ ![playground gitpod workspace init](/media/develop/playground-gitpod-workspace-init.png) -このページのシナリオでは、 [TiUP](https://docs.pingcap.com/tidb/stable/tiup-overview)使用してTiDB Playgroundを構築します。ターミナル領域の左側で進行状況を確認できます。 +このページのシナリオでは、 [TiUP](https://docs.pingcap.com/tidb/stable/tiup-overview)を使用してTiDB Playgroundを構築します。ターミナル領域の左側で進行状況を確認できます。 TiDB Playground の準備が完了すると、さらに`Spring JPA Hibernate`タスクが実行されます。進行状況はターミナル領域の右側で確認できます。 diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index 744013ef926e0..fa711f12d49e4 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -28,7 +28,7 @@ PREPARE {prepared_statement_name} FROM '{prepared_statement_sql}'; | `{prepared_statement_name}` | プリペアドステートメントの名前 | | `{prepared_statement_sql}` | プレースホルダとして疑問符が付いプリペアドステートメントSQL | -詳細については[PREPARE文](/sql-statements/sql-statement-prepare.md)参照してください。 +詳細については[PREPARE文](/sql-statements/sql-statement-prepare.md)を参照してください。 ### プリペアドステートメントを使用する {#use-the-prepared-statement} @@ -130,7 +130,7 @@ try (Connection connection = ds.getConnection()) { ### INSERT例 {#code-insert-code-example} -[`books`](/develop/dev-guide-bookshop-schema-design.md#books-table)を例に挙げると、 `title = TiDB Developer Guide` 、 `type = Science & Technology` 、 `stock = 100` 、 `price = 0.0` 、 `published_at = NOW()` （挿入時の現在時刻）の書籍を挿入する必要があります。17 `books`の**主キー**に`AUTO_RANDOM`属性を指定する必要がないことに注意してください。データの挿入に関する詳細は、 [データの挿入](/develop/dev-guide-insert-data.md)参照してください。 +[`books`](/develop/dev-guide-bookshop-schema-design.md#books-table)を例に挙げると、 `title = TiDB Developer Guide` 、 `type = Science & Technology` 、 `stock = 100` 、 `price = 0.0` 、 `published_at = NOW()` （挿入時の現在時刻）の書籍を挿入する必要があります。17 `books`の**主キー**に`AUTO_RANDOM`属性を指定する必要がないことに注意してください。データの挿入に関する詳細は、 [データの挿入](/develop/dev-guide-insert-data.md)を参照してください。 diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index e5babdc51e0ff..d9d2a69b24ad0 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -329,7 +329,7 @@ systemctl start docker > 3. TiDB Cloud Starterインスタンスをホストリストに追加します。 > 4. ProxySQLとTiDB Cloud Starterインスタンス間の安全な接続を有効にします。 > - > より深く理解するには、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。 ProxySQL 構成の詳細については、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)参照してください。 + > より深く理解するには、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。 ProxySQL 構成の詳細については、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)を参照してください。 以下は出力例です。出力にTiDB Cloud Starterインスタンスのホスト名が表示されていることがわかります。これは、ProxySQLとTiDB Cloud Starterインスタンス間の接続が確立されていることを意味します。 @@ -631,11 +631,11 @@ MySQL クライアントをダウンロードしてインストールします ProxySQLは様々なプラットフォームにインストールできます。以下ではCentOSを例として説明します。 -サポートされているプラ​​ットフォームと対応するバージョン要件の完全なリストについては、 [ProxySQLのドキュメント](https://proxysql.com/documentation/installing-proxysql/)参照してください。 +サポートされているプラ​​ットフォームと対応するバージョン要件の完全なリストについては、 [ProxySQLのドキュメント](https://proxysql.com/documentation/installing-proxysql/)を参照してください。 #### ステップ1. TiDB Cloud Dedicatedクラスタを作成する {#step-1-create-a-tidb-cloud-dedicated-cluster} -詳細な手順については、 [TiDB Cloud Dedicatedクラスターを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster)参照してください。 +詳細な手順については、 [TiDB Cloud Dedicatedクラスターを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster)を参照してください。 #### ステップ2. ProxySQLをインストールする {#step-2-install-proxysql} @@ -671,7 +671,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > **注記：** > -> 次のセクションでは、ProxySQL の必要な構成項目のみをリストします。構成の包括的なリストについては、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)参照してください。 +> 次のセクションでは、ProxySQL の必要な構成項目のみをリストします。構成の包括的なリストについては、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)を参照してください。 ##### オプション1：管理インターフェースを使用してProxySQLを設定する {#option-1-configure-proxysql-using-the-admin-interface} @@ -730,7 +730,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 ##### オプション2：設定ファイルを使用してProxySQLを設定する {#option-2-configure-proxysql-using-a-configuration-file} -このオプションは、ProxySQL を構成するための代替方法としてのみ考慮してください。詳細については、 [設定ファイルによるProxySQLの設定](https://github.com/sysown/proxysql#configuring-proxysql-through-the-config-file)参照してください。 +このオプションは、ProxySQL を構成するための代替方法としてのみ考慮してください。詳細については、 [設定ファイルによるProxySQLの設定](https://github.com/sysown/proxysql#configuring-proxysql-through-the-config-file)を参照してください。 1. 既存のSQLiteデータベース（設定が内部的に保存されている場所）をすべて削除します。 @@ -992,16 +992,16 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > - `^SELECT.*FOR UPDATE$`ルールを追加し、 `rule_id`を`1`として、 `destination_hostgroup`を`0`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`0`として TiDB クラスタに転送されます。 > - `^SELECT`ルールを追加し、 `rule_id`を`2`として、 `destination_hostgroup`を`1`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`1`として TiDB クラスタに転送されます。 > - > より深く理解するには、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。 ProxySQL 構成の詳細については、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)参照してください。 + > より深く理解するには、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。 ProxySQL 構成の詳細については、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)を参照してください。 ProxySQLパターンがクエリルールとどのように一致するかについての追加情報は以下のとおりです。 - ProxySQL は`rule_id`の昇順でルールを 1 つずつ照合しようとします。 - `^`記号は SQL ステートメントの開始と一致し、 `$`終了と一致します。 - ProxySQLの正規表現とパターンマッチングの詳細については、ProxySQLドキュメントの[mysql-query_processor_regex](https://proxysql.com/documentation/global-variables/mysql-variables/#mysql-query_processor_regex)参照してください。 + ProxySQLの正規表現とパターンマッチングの詳細については、ProxySQLドキュメントの[mysql-query_processor_regex](https://proxysql.com/documentation/global-variables/mysql-variables/#mysql-query_processor_regex)を参照してください。 - パラメータの完全なリストについては、ProxySQLドキュメントの[mysql_query_rules](https://proxysql.com/documentation/main-runtime/#mysql_query_rules)参照してください。 + パラメータの完全なリストについては、ProxySQLドキュメントの[mysql_query_rules](https://proxysql.com/documentation/main-runtime/#mysql_query_rules)を参照してください。 6. 設定を確認し、クエリルールが正しく機能するかどうかをチェックしてください。 diff --git a/develop/dev-guide-sample-application-golang-gorm.md b/develop/dev-guide-sample-application-golang-gorm.md index da7b5a71bf382..71975117fa2a4 100644 --- a/develop/dev-guide-sample-application-golang-gorm.md +++ b/develop/dev-guide-sample-application-golang-gorm.md @@ -152,7 +152,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 982bc963c911e..bd4cba1b43eff 100644 --- a/develop/dev-guide-sample-application-golang-sql-driver.md +++ b/develop/dev-guide-sample-application-golang-sql-driver.md @@ -152,7 +152,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`に名前を変更するには、次のコマンドを実行します。 @@ -323,7 +323,7 @@ Golangドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} -- Go-MySQL-Driver の使用法の詳細については[Go-MySQL-Driverのドキュメント](https://github.com/go-sql-driver/mysql/blob/master/README.md)参照してください。 +- Go-MySQL-Driver の使用法の詳細については[Go-MySQL-Driverのドキュメント](https://github.com/go-sql-driver/mysql/blob/master/README.md)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 33ab298145d28..7733faf7ef3a8 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-sample-application-java-hibernate/','/ja/ti # Hibernateを使用してTiDBに接続する {#connect-to-tidb-with-hibernate} -TiDBはMySQL互換データベースであり、[Hibernate](https://hibernate.org/orm/)人気のオープンソースJava ORMです。TiDBはMySQLとの互換性が非常に高いため、長期的な互換性を確保するには、Hibernateの方言として`org.hibernate.dialect.MySQLDialect`使用することをお勧めします。あるいは、 [Hibernateコミュニティ方言](https://github.com/hibernate/hibernate-orm/tree/main/hibernate-community-dialects)にはTiDB専用の方言（ `org.hibernate.community.dialect.TiDBDialect` ）も用意されていますが、PingCAPではメンテナンスされていません。 `MySQLDialect`を使用して互換性の問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +TiDBはMySQL互換データベースであり、[Hibernate](https://hibernate.org/orm/)は人気のオープンソースJava ORMです。TiDBはMySQLとの互換性が非常に高いため、長期的な互換性を確保するには、Hibernateの方言として`org.hibernate.dialect.MySQLDialect`使用することをお勧めします。あるいは、 [Hibernateコミュニティ方言](https://github.com/hibernate/hibernate-orm/tree/main/hibernate-community-dialects)にはTiDB専用の方言（ `org.hibernate.community.dialect.TiDBDialect` ）も用意されていますが、PingCAPではメンテナンスされていません。 `MySQLDialect`を使用して互換性の問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 このチュートリアルでは、TiDBとHibernateを使用して以下のタスクを実行する方法を学ぶことができます。 @@ -153,7 +153,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`に名前を変更するには、次のコマンドを実行します。 @@ -309,7 +309,7 @@ TiDB で`SERIALIZABLE`トランザクション分離レベルを設定しよう SET GLOBAL tidb_skip_isolation_level_check=1; ``` -この変数を有効にすると、TiDB は`SERIALIZABLE`を指定したリクエストをエラーを返さずに受け入れます。内部的には、TiDB は引き続き最も強力な分離レベルである`REPEATABLE-READ`を使用します。詳細については、 [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check)参照してください。 +この変数を有効にすると、TiDB は`SERIALIZABLE`を指定したリクエストをエラーを返さずに受け入れます。内部的には、TiDB は引き続き最も強力な分離レベルである`REPEATABLE-READ`を使用します。詳細については、 [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check)を参照してください。 > **注記：** > @@ -325,11 +325,11 @@ TiDBで`CHECK`制約の適用を有効にするには、次のシステム変数 SET GLOBAL tidb_enable_check_constraint=ON; ``` -この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)参照してください。 。 +この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)を参照してください。 。 ## 次のステップ {#next-steps} -- Hibernate の使用法の詳細については[Hibernateのドキュメント](https://hibernate.org/orm/documentation)参照してください。 +- Hibernate の使用法の詳細については[Hibernateのドキュメント](https://hibernate.org/orm/documentation)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 - Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 diff --git a/develop/dev-guide-sample-application-java-jdbc.md b/develop/dev-guide-sample-application-java-jdbc.md index 7595c5782474b..c7f171c545fe0 100644 --- a/develop/dev-guide-sample-application-java-jdbc.md +++ b/develop/dev-guide-sample-application-java-jdbc.md @@ -156,7 +156,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`に名前を変更するには、次のコマンドを実行します。 @@ -343,7 +343,7 @@ TiDB v8.5.4以降、TiDBはMySQLの動作に準拠するようになりました ## 次のステップ {#next-steps} -- MySQL Connector/J の使用法の詳細については[MySQL Connector/J のドキュメント](https://dev.mysql.com/doc/connector-j/en/)参照してください。 +- MySQL Connector/J の使用法の詳細については[MySQL Connector/J のドキュメント](https://dev.mysql.com/doc/connector-j/en/)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 - Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 diff --git a/develop/dev-guide-sample-application-java-mybatis.md b/develop/dev-guide-sample-application-java-mybatis.md index 478f758187f3e..ecd5ed7595560 100644 --- a/develop/dev-guide-sample-application-java-mybatis.md +++ b/develop/dev-guide-sample-application-java-mybatis.md @@ -153,7 +153,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 8766e91425ae0..c551698ad7701 100644 --- a/develop/dev-guide-sample-application-java-spring-boot.md +++ b/develop/dev-guide-sample-application-java-spring-boot.md @@ -153,7 +153,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 6d07f4a6582a0..b6da252346d26 100644 --- a/develop/dev-guide-sample-application-nextjs.md +++ b/develop/dev-guide-sample-application-nextjs.md @@ -321,7 +321,7 @@ console.log(rsh.affectedRows); ## 次のステップ {#next-steps} - ORM と Next.js を使用して複雑なアプリケーションを構築する方法の詳細については、 [書店デモ](https://github.com/pingcap/tidb-prisma-vercel-demo)を参照してください。 -- node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://sidorares.github.io/node-mysql2/docs/documentation)参照してください。 +- node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://sidorares.github.io/node-mysql2/docs/documentation)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-nodejs-mysql2.md b/develop/dev-guide-sample-application-nodejs-mysql2.md index c925ecceb85cc..c40aadc1e295b 100644 --- a/develop/dev-guide-sample-application-nodejs-mysql2.md +++ b/develop/dev-guide-sample-application-nodejs-mysql2.md @@ -157,7 +157,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`に名前を変更するには、次のコマンドを実行します。 @@ -334,7 +334,7 @@ console.log(rsh.affectedRows); ## 次のステップ {#next-steps} -- node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://github.com/sidorares/node-mysql2#readme)参照してください。 +- 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 アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-nodejs-mysqljs.md b/develop/dev-guide-sample-application-nodejs-mysqljs.md index c1e573157d177..110b7f2d89174 100644 --- a/develop/dev-guide-sample-application-nodejs-mysqljs.md +++ b/develop/dev-guide-sample-application-nodejs-mysqljs.md @@ -157,7 +157,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`に名前を変更するには、次のコマンドを実行します。 @@ -359,7 +359,7 @@ conn.query('DELETE FROM players WHERE id = ?;', [1], (err, ok) => { ## 次のステップ {#next-steps} -- mysql.js ドライバーの使用方法の詳細については[mysql.jsのドキュメント](https://github.com/mysqljs/mysql#readme)参照してください。 +- 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 アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-nodejs-prisma.md b/develop/dev-guide-sample-application-nodejs-prisma.md index bdea7cdd3d648..62072d1abab5f 100644 --- a/develop/dev-guide-sample-application-nodejs-prisma.md +++ b/develop/dev-guide-sample-application-nodejs-prisma.md @@ -165,7 +165,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`に名前を変更するには、次のコマンドを実行します。 @@ -399,7 +399,7 @@ await prisma.player.delete({ ## 次のステップ {#next-steps} -- ORM フレームワーク Prisma ドライバーの使用方法の詳細については[Prismaのドキュメント](https://www.prisma.io/docs)参照してください。 +- 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 アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-nodejs-sequelize.md b/develop/dev-guide-sample-application-nodejs-sequelize.md index 4cb9ec2a1a803..fd1956ea4fda4 100644 --- a/develop/dev-guide-sample-application-nodejs-sequelize.md +++ b/develop/dev-guide-sample-application-nodejs-sequelize.md @@ -161,7 +161,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`に名前を変更するには、次のコマンドを実行します。 @@ -352,7 +352,7 @@ logger.info(deletedNewPlayer?.toJSON()); ## 次のステップ {#next-steps} -- ORM フレームワーク Sequelize ドライバーの使用法の詳細については[Sequelizeのドキュメント](https://sequelize.org/)参照してください。 +- ORM フレームワーク Sequelize ドライバーの使用法の詳細については[Sequelizeのドキュメント](https://sequelize.org/)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-nodejs-typeorm.md b/develop/dev-guide-sample-application-nodejs-typeorm.md index a0f6ef84302f2..9bf3e223439ce 100644 --- a/develop/dev-guide-sample-application-nodejs-typeorm.md +++ b/develop/dev-guide-sample-application-nodejs-typeorm.md @@ -165,7 +165,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`に名前を変更するには、次のコマンドを実行します。 @@ -393,7 +393,7 @@ export class ActionLog { ## 次のステップ {#next-steps} -- TypeORM の使用法の詳細については[TypeORMのドキュメント](https://typeorm.io/)参照してください。 +- 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 アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-python-django.md b/develop/dev-guide-sample-application-python-django.md index 3387b3d45b431..067657f2531ba 100644 --- a/develop/dev-guide-sample-application-python-django.md +++ b/develop/dev-guide-sample-application-python-django.md @@ -169,7 +169,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`に名前を変更するには、次のコマンドを実行します。 @@ -359,7 +359,7 @@ Player.objects.filter(coins=100).delete() ## 次のステップ {#next-steps} -- Django の使用法の詳細については[Djangoのドキュメント](https://www.djangoproject.com/)参照してください。 +- Django の使用法の詳細については[Djangoのドキュメント](https://www.djangoproject.com/)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-python-mysql-connector.md b/develop/dev-guide-sample-application-python-mysql-connector.md index efc202e22081f..27214ee8bdaa5 100644 --- a/develop/dev-guide-sample-application-python-mysql-connector.md +++ b/develop/dev-guide-sample-application-python-mysql-connector.md @@ -157,7 +157,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`に名前を変更するには、次のコマンドを実行します。 @@ -310,7 +310,7 @@ Pythonドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} -- mysql-connector-python の使用法の詳細については[MySQL Connector/Python のドキュメント](https://dev.mysql.com/doc/connector-python/en/)参照してください。 +- mysql-connector-python の使用法の詳細については[MySQL Connector/Python のドキュメント](https://dev.mysql.com/doc/connector-python/en/)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-python-mysqlclient.md b/develop/dev-guide-sample-application-python-mysqlclient.md index 6461623e8899b..1e47fe7cbf0d2 100644 --- a/develop/dev-guide-sample-application-python-mysqlclient.md +++ b/develop/dev-guide-sample-application-python-mysqlclient.md @@ -162,7 +162,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 4b8ea8236125c..3e8460a8dbabd 100644 --- a/develop/dev-guide-sample-application-python-peewee.md +++ b/develop/dev-guide-sample-application-python-peewee.md @@ -161,7 +161,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 64eb94952227a..ec2a959114ec1 100644 --- a/develop/dev-guide-sample-application-python-pymysql.md +++ b/develop/dev-guide-sample-application-python-pymysql.md @@ -157,7 +157,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`に名前を変更するには、次のコマンドを実行します。 @@ -315,7 +315,7 @@ Pythonドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} -- PyMySQL の使用法の詳細については[PyMySQLのドキュメント](https://pymysql.readthedocs.io)参照してください。 +- PyMySQL の使用法の詳細については[PyMySQLのドキュメント](https://pymysql.readthedocs.io)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md index 3986f86fe1a03..5611d9a5feaf8 100644 --- a/develop/dev-guide-sample-application-python-sqlalchemy.md +++ b/develop/dev-guide-sample-application-python-sqlalchemy.md @@ -167,7 +167,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`に名前を変更するには、次のコマンドを実行します。 @@ -328,7 +328,7 @@ with Session() as session: ## 次のステップ {#next-steps} -- SQLAlchemy の使用法の詳細については[SQLAlchemyのドキュメント](https://www.sqlalchemy.org/)参照してください。 +- SQLAlchemy の使用法の詳細については[SQLAlchemyのドキュメント](https://www.sqlalchemy.org/)を参照してください。 - [開発者ガイド](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-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index 7742a50437113..82839962a34b9 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -158,7 +158,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`に名前を変更するには、次のコマンドを実行します。 @@ -335,7 +335,7 @@ CA証明書のパスを手動で指定することも可能ですが、異なる ## 次のステップ {#next-steps} -- mysql2 ドライバーの使用方法の詳細については[mysql2のドキュメント](https://github.com/brianmario/mysql2#readme)参照してください。 +- 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 アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index 9790a61fb619b..93fbd33a71700 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -143,7 +143,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`に名前を変更するには、次のコマンドを実行します。 diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index 7f36ee09a4ae4..91ee1927e3f36 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -44,11 +44,11 @@ TiDBには`test`という名前のデフォルトデータベースが付属し > TiDBでは、**主キー**のデフォルト定義は[InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なストレージエンジン）とは異なります。 > > - InnoDBでは、**主キー**の定義は一意であり、nullではなく、**クラスター化されたインデックス**です。 -> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)参照してください。 +> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 #### 専門索引 {#specialized-indexes} -さまざまなユーザー シナリオのクエリ パフォーマンスを向上させるために、TiDB はいくつかの特殊なタイプのインデックスを提供します。各タイプの詳細については、[インデックスと制約](/basic-features.md#indexing-and-constraints)参照してください。 +さまざまなユーザー シナリオのクエリ パフォーマンスを向上させるために、TiDB はいくつかの特殊なタイプのインデックスを提供します。各タイプの詳細については、[インデックスと制約](/basic-features.md#indexing-and-constraints)を参照してください。 ### その他のサポートされている論理オブジェクト {#other-supported-logical-objects} diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index 95fb09db7c451..6de9c41a74334 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -17,7 +17,7 @@ aliases: ['/ja/tidb/stable/dev-guide-third-party-tools-compatibility/','/ja/tidb > - `SPATIAL`関数、データ型、インデックス > - `XA`構文 > -> 上記のサポートされていない機能は想定される動作であり、このドキュメントには記載されていません。詳細については、 [MySQLの互換性](/mysql-compatibility.md)参照してください。 +> 上記の機能がサポートされていないのは想定された動作であり、このドキュメントには記載されていません。詳細については、 [MySQLの互換性](/mysql-compatibility.md)を参照してください。 このドキュメントに記載されている非互換性の問題は、いくつかの[TiDBでサポートされているサードパーティツール](/develop/dev-guide-third-party-tools-compatibility.md)に見られます。 @@ -54,7 +54,7 @@ TiDBのエラーメッセージは`TIMESTAMP`と`DATETIME`を区別しますが **回避方法** -文字列の照合にはエラーメッセージを使用しないでください。代わりに、トラブルシューティングには[エラーコード](/error-codes.md)使用してください。 +文字列の照合にはエラーメッセージを使用しないでください。代わりに、トラブルシューティングには[エラーコード](/error-codes.md)を使用してください。 ### TiDBはCHECK TABLE文をサポートしていません {#tidb-does-not-support-the-code-check-table-code-statement} @@ -143,7 +143,7 @@ MySQL Connector/J 8.0.32 以前のバージョンを使用している場合、 > **注記：** > -> `useConfigs=maxPerformance`は一連の設定が含まれています。MySQL Connector/J 8.0 および MySQL Connector/J 5.1 の詳細な設定については、それぞれ[mysql-コネクタ-j 8.0](https://github.com/mysql/mysql-connector-j/blob/release/8.0/src/main/resources/com/mysql/cj/configurations/maxPerformance.properties)および[mysql-コネクタ-j 5.1](https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/configs/maxPerformance.properties)参照してください。 `maxPerformance`使用する場合は`useLocalTransactionState`無効にする必要があります。つまり、 `useConfigs=maxPerformance&useLocalTransactionState=false`使用してください。 +> `useConfigs=maxPerformance`は一連の設定が含まれています。MySQL Connector/J 8.0 および MySQL Connector/J 5.1 の詳細な設定については、それぞれ[mysql-connector-j 8.0](https://github.com/mysql/mysql-connector-j/blob/release/8.0/src/main/resources/com/mysql/cj/configurations/maxPerformance.properties)および[mysql-connector-j 5.1](https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/configs/maxPerformance.properties)を参照してください。 `maxPerformance`を使用する場合は`useLocalTransactionState`を無効にする必要があります。つまり、 `useConfigs=maxPerformance&useLocalTransactionState=false`を使用してください。 このバグはMySQL Connector/J 8.0.33で修正されました。8.0.xシリーズのアップデートは終了しているため、安定性とパフォーマンスを向上させるためにMySQL Connector/Jを[最新の一般提供（GA）バージョン](https://dev.mysql.com/downloads/connector/j/)にアップグレードすることを強くお勧めします。 diff --git a/develop/dev-guide-tidb-crud-sql.md b/develop/dev-guide-tidb-crud-sql.md index 69fee41123796..51b099a16c2c1 100644 --- a/develop/dev-guide-tidb-crud-sql.md +++ b/develop/dev-guide-tidb-crud-sql.md @@ -16,13 +16,13 @@ TiDB に接続していることを確認してください。そうでない場 > **注記：** > -> このドキュメントは[TiDBでSQLを探求しよう](/basic-sql-operations.md)を参照し、簡略化しています。詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)参照してください。 +> このドキュメントは[TiDBでSQLを探求しよう](/basic-sql-operations.md)を参照し、簡略化しています。詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)を参照してください。 TiDB は MySQL と互換性があり、ほとんどの場合、MySQL ステートメントを直接使用できます。サポートされていない機能については、 [MySQLとの互換性](/mysql-compatibility.md#unsupported-features)を参照してください。 SQL を試して、MySQL クエリと TiDB の互換性をテストするには、 [TiDB Playground](https://play.tidbcloud.com/?utm_source=docs&utm_medium=basic-sql-operations)試すことができます。最初に[TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md#step-1-create-a-starter-instance)、その中で SQL ステートメントを実行することもできます。 -このページでは、DDL、DML、CRUD 操作などの基本的なTiDB SQLステートメントについて説明します。 TiDB ステートメントの完全なリストについては、 [SQLステートメントの概要](/sql-statements/sql-statement-overview.md)参照してください。 +このページでは、DDL、DML、CRUD 操作などの基本的なTiDB SQLステートメントについて説明します。 TiDB ステートメントの完全なリストについては、 [SQLステートメントの概要](/sql-statements/sql-statement-overview.md)を参照してください。 ## カテゴリ {#category} @@ -36,7 +36,7 @@ SQLは、その関数に応じて以下の4種類に分類されます。 - **DCL（データ制御言語）** ：アクセス権限とセキュリティレベルを定義するために使用されます。 -以下では主にDMLとDQLについて紹介します。 DDL と DCL の詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)または[SQLステートメントの概要](/sql-statements/sql-statement-overview.md)参照してください。 +以下では主にDMLとDQLについて紹介します。 DDL と DCL の詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)または[SQLステートメントの概要](/sql-statements/sql-statement-overview.md)を参照してください。 ## データ操作言語 {#data-manipulation-language} diff --git a/develop/dev-guide-time-to-live.md b/develop/dev-guide-time-to-live.md index 1b7da027f2fa5..db416d2c88175 100644 --- a/develop/dev-guide-time-to-live.md +++ b/develop/dev-guide-time-to-live.md @@ -23,7 +23,7 @@ TTLは、一定期間が経過するとデータがビジネス価値を失う ## クイックスタート {#quick-start} -TTL属性は、テーブルの作成時に設定することも、既存のテーブルに追加することもできます。以下のセクションでは、TTLを使用して期限切れのデータを定期的に削除する基本的な例を示します。詳細な例、使用上の制限、および他のツールや機能との互換性の詳細については、 [TTL (存続時間)](/time-to-live.md)参照してください。 +TTL属性は、テーブルの作成時に設定することも、既存のテーブルに追加することもできます。以下のセクションでは、TTLを使用して期限切れのデータを定期的に削除する基本的な例を示します。詳細な例、使用上の制限、および他のツールや機能との互換性の詳細については、 [TTL (存続時間)](/time-to-live.md)を参照してください。 ### TTLでテーブルを作成する {#create-a-table-with-ttl} diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md index 6d4ca43acccd4..888a889851d8d 100644 --- a/develop/dev-guide-timeouts-in-tidb.md +++ b/develop/dev-guide-timeouts-in-tidb.md @@ -38,9 +38,9 @@ TiDBのトランザクション実装では、MVCC（Multiple Version Concurrenc > > このようなシナリオでは、エクスポート プロセス中の GC によるエクスポートの失敗を回避するために、事前に GC 時間を手動で延長する必要があります。 > -> 詳細については[TiDB GC時間を手動で設定する](/dumpling-overview.md#manually-set-the-tidb-gc-time)参照してください。 +> 詳細については[TiDB GC時間を手動で設定する](/dumpling-overview.md#manually-set-the-tidb-gc-time)を参照してください。 -GC の詳細については、 [GCの概要](/garbage-collection-overview.md)参照してください。 +GC の詳細については、 [GCの概要](/garbage-collection-overview.md)を参照してください。 ## トランザクションタイムアウト {#transaction-timeout} diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 2c292c1649b24..36a7e9ba41dc4 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -159,7 +159,7 @@ mysql> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; ERROR 8048 (HY000): The isolation level 'SERIALIZABLE' is not supported. Set tidb_skip_isolation_level_check=1 to skip this error ``` -TiDBは、MySQLとの整合性を確保するために、スナップショット分離（SI）レベルの整合性（「繰り返し読み取り」とも呼ばれます）を実装しています。この分離レベルは[ANSI繰り返し読み取り分離レベル](/transaction-isolation-levels.md#difference-between-tidb-and-ansi-repeatable-read)および[MySQL 繰り返し読み取り分離レベル](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)とは異なります。詳細については、 [TiDBトランザクション分離レベル](/transaction-isolation-levels.md)参照してください。 +TiDBは、MySQLとの整合性を確保するために、スナップショット分離（SI）レベルの整合性（「繰り返し読み取り」とも呼ばれます）を実装しています。この分離レベルは[ANSI繰り返し読み取り分離レベル](/transaction-isolation-levels.md#difference-between-tidb-and-ansi-repeatable-read)および[MySQL 繰り返し読み取り分離レベル](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)とは異なります。詳細については、 [TiDBトランザクション分離レベル](/transaction-isolation-levels.md)を参照してください。 ## ヘルプが必要ですか? {#need-help} diff --git a/develop/dev-guide-transaction-restraints.md b/develop/dev-guide-transaction-restraints.md index 2c98e2705a310..eb6705886f7b8 100644 --- a/develop/dev-guide-transaction-restraints.md +++ b/develop/dev-guide-transaction-restraints.md @@ -718,7 +718,7 @@ mysql> SELECT * FROM T2; - 単一トランザクションでサポートされる最大サイズは1 TiBです。 - TiDB v4.0 以降のバージョンでは、 [`performance.txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)で設定できます。以前のバージョンでは、値は`100 MB`です。 - - TiDB v6.5.0以降のバージョンでは、この設定は推奨されなくなりました。詳細については、 [`performance.txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)参照してください。 + - TiDB v6.5.0以降のバージョンでは、この設定は推奨されなくなりました。詳細については、 [`performance.txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)を参照してください。 サイズ制限と行数制限の両方において、トランザクション実行時のエンコード処理とトランザクション用の追加キーのオーバーヘッドも考慮する必要があることに注意してください。最適なパフォーマンスを実現するには、100～500行ごとに1つのトランザクションを書き込むことをお勧めします。 diff --git a/develop/dev-guide-transaction-troubleshoot.md b/develop/dev-guide-transaction-troubleshoot.md index 5256a346a1481..a0668fc926172 100644 --- a/develop/dev-guide-transaction-troubleshoot.md +++ b/develop/dev-guide-transaction-troubleshoot.md @@ -92,7 +92,7 @@ MySQL などの従来のデータベースとは異なり、TiDB では、楽観 - `Error 9007: Write conflict` : 書き込み競合エラー。通常、楽観的トランザクション モードが使用されているときに、複数のトランザクションが同じデータ行を変更することによって発生します。 - try ブロックの最後にあるトランザクションを`COMMIT` 。 -エラー コードの詳細については、 [エラーコードとトラブルシューティング](/error-codes.md)参照してください。 +エラー コードの詳細については、 [エラーコードとトラブルシューティング](/error-codes.md)を参照してください。 ```python while True: @@ -120,7 +120,7 @@ while True: > > `Error 9007: Write conflict`頻繁に発生する場合は、スキーマ設計とワークロードのデータ アクセス パターンを確認して競合の根本原因を特定し、設計を改善して競合を回避する必要があります。 -トランザクションの競合のトラブルシューティングと解決方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)参照してください。 +トランザクションの競合のトラブルシューティングと解決方法については、 [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md)を参照してください。 ## 参照 {#see-also} diff --git a/develop/dev-guide-troubleshoot-overview.md b/develop/dev-guide-troubleshoot-overview.md index eeebe80089f22..3ffa21271668b 100644 --- a/develop/dev-guide-troubleshoot-overview.md +++ b/develop/dev-guide-troubleshoot-overview.md @@ -32,7 +32,7 @@ SQL クエリのパフォーマンスを向上させる場合は、 [SQL性能 -SQL 操作について質問がある場合は、 [SQLに関するよくある質問](/faq/sql-faq.md)参照してください。 +SQL 操作について質問がある場合は、 [SQLに関するよくある質問](/faq/sql-faq.md)を参照してください。 ## トランザクションに関する問題のトラブルシューティング {#troubleshoot-transaction-issues} diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 2557a8215595a..63d03f3aaaec3 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -21,7 +21,7 @@ aliases: ['/ja/tidb/stable/dev-guide-update-data/','/ja/tidb/dev/dev-guide-updat ## UPDATEを使用する {#use-code-update-code} -テーブル内の既存の行を更新するには、更新対象の列をフィルタリングするために`WHERE`句を含む[`UPDATE`文](/sql-statements/sql-statement-update.md)使用する必要があります。 +テーブル内の既存の行を更新するには、更新対象の列をフィルタリングするために`WHERE`句を含む[`UPDATE`文](/sql-statements/sql-statement-update.md)を使用する必要があります。 > **注記：** > @@ -174,7 +174,7 @@ ALTER TABLE `bookshop`.`ratings` ADD COLUMN `ten_point` BOOL NOT NULL DEFAULT FA > **注記：** > -> この一括更新アプリケーションは、 **DDL**ステートメントを使用してデータテーブルのスキーマを変更します。TiDB のすべての DDL 変更操作はオンラインで実行されます。詳細については、[列を追加](/sql-statements/sql-statement-add-column.md)参照してください。 +> この一括更新アプリケーションは、 **DDL**ステートメントを使用してデータテーブルのスキーマを変更します。TiDB のすべての DDL 変更操作はオンラインで実行されます。詳細については、[列を追加](/sql-statements/sql-statement-add-column.md)を参照してください。
diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index 13c304c2c1861..db5bde5845089 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-common-table-expression/','/ja/tidbclou トランザクションのシナリオによっては、アプリケーションの複雑さにより、最大2,000行にも及ぶ単一のSQL文を記述しなければならない場合があります。この文には、多数の集計や複数レベルのサブクエリのネストが含まれる可能性があります。このような長いSQL文を管理することは、開発者にとって悪夢となる可能性があります。 -このような長い SQL 文を回避するには、 [ビュー](/develop/dev-guide-use-views.md)使用してクエリを簡略化するか、 [一時テーブル](/develop/dev-guide-use-temporary-tables.md)を使用して中間クエリ結果をキャッシュします。 +このような長い SQL 文を回避するには、 [ビュー](/develop/dev-guide-use-views.md)を使用してクエリを簡略化するか、 [一時テーブル](/develop/dev-guide-use-temporary-tables.md)を使用して中間クエリ結果をキャッシュします。 このドキュメントでは、クエリ結果を再利用するためのより便利な方法である、TiDB の共通テーブル式 (CTE) 構文を紹介します。 diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index 557bc3fd4f9bc..6e765678bd214 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -29,7 +29,7 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク ### 地理的に分散した展開のレイテンシーを削減 {#reduce-latency-for-geo-distributed-deployments} -TiDB クラスターが複数の地区またはデータセンターにまたがって展開されている場合、リージョンの異なるレプリカが異なる地区またはデータセンターに分散されます。この場合、 Follower Read を`closest-adaptive`または`closest-replicas`に設定することで、TiDB が現在のデータセンターからの読み取りを優先するように設定できます。これにより、読み取り操作のレイテンシーとトラフィックのオーバーヘッドが大幅に削減されます。実装の詳細については、 [Follower Read](/follower-read.md)参照してください。 +TiDB クラスターが複数の地区またはデータセンターにまたがって展開されている場合、リージョンの異なるレプリカが異なる地区またはデータセンターに分散されます。この場合、 Follower Read を`closest-adaptive`または`closest-replicas`に設定することで、TiDB が現在のデータセンターからの読み取りを優先するように設定できます。これにより、読み取り操作のレイテンシーとトラフィックのオーバーヘッドが大幅に削減されます。実装の詳細については、 [Follower Read](/follower-read.md)を参照してください。 ## Follower Readを有効にする {#enable-follower-read} @@ -42,7 +42,7 @@ Follower Readを有効にするには、変数`tidb_replica_read` (デフォル SET [GLOBAL] tidb_replica_read = 'follower'; ``` -この変数の詳細については、 [Follower Read使用状況](/follower-read.md#usage)参照してください。 +この変数の詳細については、 [Follower Read使用状況](/follower-read.md#usage)を参照してください。
diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index a208d84d49c17..2b73717830b30 100644 --- a/develop/dev-guide-use-stale-read.md +++ b/develop/dev-guide-use-stale-read.md @@ -93,7 +93,7 @@ SELECT id, title, type, price FROM books AS OF TIMESTAMP '2022-04-20 15:20:00' O - `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` `2016-10-08 16:45:26`から`2016-10-08 16:45:29`の間の最新データを照会します。 - `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() -INTERVAL 20 SECOND, NOW())` 20 秒以内に最新のデータを照会します。 -指定するタイムスタンプまたは間隔は、現在の時刻より早すぎたり遅すぎたりしないようにしてください。また、 `NOW()`デフォルトで秒精度となります。より高い精度を実現するには、パラメータを追加することができます。例えば、 `NOW(3)`ミリ秒精度となります。詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_now)参照してください。 +指定するタイムスタンプまたは間隔は、現在の時刻より早すぎたり遅すぎたりしないようにしてください。また、 `NOW()`はデフォルトで秒精度となります。より高い精度を実現するには、パラメータを追加することができます。例えば、 `NOW(3)`ではミリ秒精度となります。詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_now)を参照してください。 期限切れのデータはTiDBで[ガベージコレクション](/garbage-collection-overview.md)リサイクルされ、クリアされるまでの短い期間保持されます。この期間は[GC の有効期間 (デフォルト 10 分)](/system-variables.md#tidb_gc_life_time-new-in-v50)呼ばれます。GCが開始されると、現在の時刻からこの期間を差し引いた値が**GCセーフポイント**として使用されます。GCセーフポイントより前にデータを読み取ろうとすると、TiDBは次のエラーを報告します。 diff --git a/develop/dev-guide-use-subqueries.md b/develop/dev-guide-use-subqueries.md index 595f94629a82f..d9e4a1033f76b 100644 --- a/develop/dev-guide-use-subqueries.md +++ b/develop/dev-guide-use-subqueries.md @@ -78,7 +78,7 @@ WHERE (IFNULL(a1.death_year, YEAR(NOW())) - a1.birth_year) > 34; | 421294 | Karelle VonRueden | 0 | 1977 | NULL | ... -存在テストや定量比較などの自己完結型サブクエリについては、TiDBはパフォーマンス向上のために、それらを同等のクエリに書き換えて置き換えます。詳細については、 [サブクエリ関連の最適化](/subquery-optimization.md)参照してください。 +存在テストや定量比較などの自己完結型サブクエリについては、TiDBはパフォーマンス向上のために、それらを同等のクエリに書き換えて置き換えます。詳細については、 [サブクエリ関連の最適化](/subquery-optimization.md)を参照してください。 ### 相関サブクエリ {#correlated-subquery} diff --git a/develop/dev-guide-use-temporary-tables.md b/develop/dev-guide-use-temporary-tables.md index c4e8da27f0229..06c9188b8d8c7 100644 --- a/develop/dev-guide-use-temporary-tables.md +++ b/develop/dev-guide-use-temporary-tables.md @@ -247,7 +247,7 @@ DROP GLOBAL TEMPORARY TABLE top_50_eldest_authors_global; ## 制限 {#limitation} -TiDB の一時テーブルの制限については、 [他の TiDB 機能との互換性の制限](/temporary-tables.md#compatibility-restrictions-with-other-tidb-features)参照してください。 +TiDB の一時テーブルの制限については、 [他の TiDB 機能との互換性の制限](/temporary-tables.md#compatibility-restrictions-with-other-tidb-features)を参照してください。 ## 続きを読む {#read-more} diff --git a/develop/dev-guide-use-views.md b/develop/dev-guide-use-views.md index 01f0066363c41..f833c6b4d1848 100644 --- a/develop/dev-guide-use-views.md +++ b/develop/dev-guide-use-views.md @@ -110,7 +110,7 @@ DROP VIEW book_with_ratings; ## 制限 {#limitation} -TiDB のビューの制限については、 [ビューの制限](/views.md#limitations)参照してください。 +TiDB のビューの制限については、 [ビューの制限](/views.md#limitations)を参照してください。 ## 続きを読む {#read-more} diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md index 6dd304962e9b9..26bed7deb8a3b 100644 --- a/develop/dev-guide-vector-search.md +++ b/develop/dev-guide-vector-search.md @@ -24,7 +24,7 @@ TiDB ベクトル検索を開始するには、次のチュートリアルを参 開発を加速させるために、TiDBベクトル検索を一般的なAIフレームワーク（LlamaIndexやLangChainなど）、埋め込みサービス（Jina AIなど）、ORMライブラリ（SQLAlchemy、Peewee、Django ORMなど）と統合できます。ニーズに最適なものを選択できます。 -詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)参照してください. +詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)を参照してください. ## テキスト検索 {#text-search} @@ -42,7 +42,7 @@ RAG シナリオでの検索品質を向上させるには、ベクトル検索 ベクトル検索クエリのパフォーマンスを最適化するには、ベクトル インデックスの追加、インデックス構築の進行状況の監視、ディメンションの削減、ベクトル列の除外、インデックスのウォームアップなどの一連のベスト プラクティスに従うことができます。 -これらのベスト プラクティスの詳細については、 [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md)参照してください。 +これらのベスト プラクティスの詳細については、 [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md)を参照してください。 ## 制限事項 {#limitations} @@ -52,7 +52,7 @@ RAG シナリオでの検索品質を向上させるには、ベクトル検索 - ベクトル列は主キー、一意インデックス、パーティション キーとして使用することはできません。 - ベクトルと他のデータ型間の直接キャストは行いません（文字列を中間として使用します） -完全なリストについては、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)参照してください。 +完全なリストについては、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)を参照してください。 ## 参照 {#reference} diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index e29099d16ee54..2ff322345e50f 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -38,7 +38,7 @@ Javaアプリケーションは、さまざまなフレームワークでカプ ### JDBC API {#jdbc-api} -JDBC APIの使用方法については、 [JDBC公式チュートリアル](https://docs.oracle.com/javase/tutorial/jdbc/)参照してください。このセクションでは、いくつかの重要な API の使用法について説明します。 +JDBC APIの使用方法については、 [JDBC公式チュートリアル](https://docs.oracle.com/javase/tutorial/jdbc/)を参照してください。このセクションでは、いくつかの重要な API の使用法について説明します。 #### Prepare APIを使用する {#use-prepare-api} @@ -80,7 +80,7 @@ TiDBは両方の方法をサポートしていますが、実装がよりシン ### MySQL JDBC パラメータ {#mysql-jdbc-parameters} -JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式で提供します。このセクションでは[MySQL Connector/Jのパラメータ設定](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html)を紹介します (MariaDB を使用する場合は、 [MariaDBのパラメータ設定](https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j#optional-url-parameters)参照してください)。このドキュメントではすべての構成項目をカバーすることはできないため、パフォーマンスに影響を与える可能性のあるいくつかのパラメーターに主に焦点を当てています。 +JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式で提供します。このセクションでは[MySQL Connector/Jのパラメータ設定](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html)を紹介します (MariaDB を使用する場合は、 [MariaDBのパラメータ設定](https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j#optional-url-parameters)を参照してください)。このドキュメントではすべての構成項目をカバーすることはできないため、パフォーマンスに影響を与える可能性のあるいくつかのパラメーターに主に焦点を当てています。 #### 準備関連パラメータ {#prepare-related-parameters} @@ -198,7 +198,7 @@ update t set a = 10 where id = 1; update t set a = 11 where id = 2; update t set > **注記：** > -> `useConfigs=maxPerformance`を有効にするには、MySQL Connector/J バージョン 8.0.33 以降が必要です。詳細については、 [MySQL JDBC バグ](/develop/dev-guide-third-party-tools-compatibility.md#mysql-jdbc-bugs)参照してください。 +> `useConfigs=maxPerformance`を有効にするには、MySQL Connector/J バージョン 8.0.33 以降が必要です。詳細については、 [MySQL JDBC バグ](/develop/dev-guide-third-party-tools-compatibility.md#mysql-jdbc-bugs)を参照してください。 #### タイムアウト関連のパラメータ {#timeout-related-parameters} @@ -252,7 +252,7 @@ hikari: - `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、を参照[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)ください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 - `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 -- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。graceful [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)使用している場合は、この値が待機時間よりも小さいことを確認してください。 +- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。graceful [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 - `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2 分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 ### プローブ構成 {#probe-configuration} @@ -260,7 +260,7 @@ hikari: 接続プールは、以下のようにクライアントからTiDBへの永続的な接続を維持します。 - バージョン5.4より前のTiDBでは、デフォルトでは（エラーが報告されない限り）クライアント接続を積極的に閉じることはありません。 -- バージョン5.4以降、TiDBはデフォルトで`28800`秒（つまり`8`時間）の非アクティブ状態が続くと、クライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBおよびMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)参照してください。 . +- バージョン5.4以降、TiDBはデフォルトで`28800`秒（つまり`8`時間）の非アクティブ状態が続くと、クライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBおよびMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)を参照してください。 . さらに、クライアントとTiDBの間には、 [LVS](https://en.wikipedia.org/wiki/Linux_Virtual_Server)や[HAProxy](https://en.wikipedia.org/wiki/HAProxy)などのネットワークプロキシが存在する場合があります。これらのプロキシは通常、特定のアイドル期間（プロキシのアイドル設定によって決定されます）が経過すると、接続を自動的にクリーンアップします。接続プールは、プロキシのアイドル設定を監視するだけでなく、キープアライブのために接続を維持またはプローブする必要もあります。 diff --git a/develop/serverless-driver-drizzle-example.md b/develop/serverless-driver-drizzle-example.md index 110ea16e7b148..04b31c6a1e9a8 100644 --- a/develop/serverless-driver-drizzle-example.md +++ b/develop/serverless-driver-drizzle-example.md @@ -96,7 +96,7 @@ aliases: ['/ja/tidbcloud/serverless-driver-drizzle-example/'] 1. TiDB Cloud Starterインスタンスにテーブルを作成します。 - [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query)使用してSQL文を実行できます。以下に例を示します。 + [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query)を使用してSQL文を実行できます。以下に例を示します。 ```sql CREATE TABLE `test`.`users` ( @@ -204,7 +204,7 @@ aliases: ['/ja/tidbcloud/serverless-driver-drizzle-example/'] 1. TiDB Cloud Starterインスタンスにテーブルを作成します。 - [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query.md)使用してSQL文を実行できます。以下に例を示します。 + [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query.md)を使用してSQL文を実行できます。以下に例を示します。 ```sql CREATE TABLE `test`.`users` ( diff --git a/develop/serverless-driver-kysely-example.md b/develop/serverless-driver-kysely-example.md index dafaf8edfe4cb..84207d4574e10 100644 --- a/develop/serverless-driver-kysely-example.md +++ b/develop/serverless-driver-kysely-example.md @@ -84,7 +84,7 @@ aliases: ['/ja/tidbcloud/serverless-driver-kysely-example/'] 1. TiDB Cloud Starterインスタンスにテーブルを作成し、データを挿入してください。 - [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query)使用してSQLステートメントを実行できます。以下に例を示します。 + [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query)を使用してSQLステートメントを実行できます。以下に例を示します。 ```sql CREATE TABLE `test`.`person` ( @@ -184,7 +184,7 @@ TiDB Cloud Starterインスタンスの概要ページで、右上隅の**「接 1. TiDB Cloud Starterインスタンスにテーブルを作成し、データを挿入してください。 - [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query)使用してSQL文を実行できます。以下に例を示します。 + [TiDB CloudコンソールのSQLエディタ](https://docs.pingcap.com/tidbcloud/explore-data-with-chat2query)を使用してSQL文を実行できます。以下に例を示します。 ```sql CREATE TABLE `test`.`person` ( diff --git a/develop/serverless-driver-prisma-example.md b/develop/serverless-driver-prisma-example.md index 55fe92b0d517d..e1844342819ae 100644 --- a/develop/serverless-driver-prisma-example.md +++ b/develop/serverless-driver-prisma-example.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidbcloud/serverless-driver-prisma-example/'] - サーバーレス環境におけるPrisma Clientのパフォーマンス向上 - エッジ環境でPrisma Clientを使用できる機能 -このチュートリアルでは、サーバーレス環境およびエッジ環境で[@tidbcloud/prisma-adapter](https://github.com/tidbcloud/prisma-adapter)使用する方法について説明します。 +このチュートリアルでは、サーバーレス環境およびエッジ環境で[@tidbcloud/prisma-adapter](https://github.com/tidbcloud/prisma-adapter)を使用する方法について説明します。 > **ヒント：** > @@ -176,7 +176,7 @@ const prisma = new PrismaClient({ adapter }); npx prisma db push - このコマンドは、 `user`を使用した HTTPS 接続ではなく、従来の TCP 接続を通じてTiDB Cloud Starterインスタンスに`@tidbcloud/prisma-adapter`します。これは、Prisma Migrate と同じエンジンを使用しているためです。このコマンドの詳細については、 [スキーマのプロトタイプを作成します](https://www.prisma.io/docs/concepts/components/prisma-migrate/db-push)参照してください。 + このコマンドは、 `user`を使用した HTTPS 接続ではなく、従来の TCP 接続を通じてTiDB Cloud Starterインスタンスに`@tidbcloud/prisma-adapter`します。これは、Prisma Migrate と同じエンジンを使用しているためです。このコマンドの詳細については、 [スキーマのプロトタイプを作成します](https://www.prisma.io/docs/concepts/components/prisma-migrate/db-push)を参照してください。 4. Prisma Clientを生成する： diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index bd64ef9d764a1..fd319ff922ed3 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -13,7 +13,7 @@ summary: DM バイナリを使用してデータ移行クラスターをデプ ## DMバイナリをダウンロード {#download-dm-binary} -DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)参照してください。 +DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 ## サンプルシナリオ {#sample-scenario} diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 333bccef7ece4..a86ce00af5798 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -113,9 +113,9 @@ alertmanager_servers: > > - 特定のノードで有効にするパラメータについては、このノードの`config`でこれらのパラメータを設定します。 > -> - `.`構成のサブカテゴリ（例： `log.slow-threshold`を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)参照してください。 +> - `.`構成のサブカテゴリ（例： `log.slow-threshold`を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)を参照してください。 > -> - 詳細なパラメータの説明については、 [マスター`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)参照してください。 +> - 詳細なパラメータの説明については、 [マスター`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` ) が相互接続されています。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index b49df9298cdec..e9c8665e72761 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -216,8 +216,8 @@ tiup dm display dm-test dmctl は、DM クラスタを制御するためのコマンドラインツールです[TiUP経由でdmctlを使用する](/dm/maintain-dm-using-tiup.md#dmctl)を使用することをお勧めします。 -dmctlはコマンドモードと対話モードの両方をサポートしています。詳細については[dmctl を使用して DM クラスターを管理](/dm/dmctl-introduction.md#maintain-dm-clusters-using-dmctl)参照してください。 +dmctlはコマンドモードと対話モードの両方をサポートしています。詳細については[dmctl を使用して DM クラスターを管理](/dm/dmctl-introduction.md#maintain-dm-clusters-using-dmctl)を参照してください。 ## ステップ9: データベースのパスワードを暗号化する {#step-9-encrypt-the-database-password} -デプロイメント後、データベースパスワードを暗号化するようにDMタスクを設定できます。詳細については、 [データベースのパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)参照してください。 +デプロイメント後、データベースパスワードを暗号化するようにDMタスクを設定できます。詳細については、 [データベースのパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 diff --git a/dm/dm-arch.md b/dm/dm-arch.md index 15e41ce90e78e..da58efd743382 100644 --- a/dm/dm-arch.md +++ b/dm/dm-arch.md @@ -32,7 +32,7 @@ DM-worker は特定のデータ移行タスクを実行します。 - データ移行サブタスクの操作のオーケストレーション - データ移行サブタスクの実行状態の監視 -DM-workerの詳細については[DMワーカー紹介](/dm/dm-worker-intro.md)参照してください。 +DM-workerの詳細については[DMワーカー紹介](/dm/dm-worker-intro.md)を参照してください。 ### dmctl {#dmctl} diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 8f6e7656a50a7..7511b12ddfc18 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -39,7 +39,7 @@ DM は次のシナリオで使用できます。 #### スキーマ設計におけるAUTO_INCREMENTのビジネスへの影響 {#business-impact-of-auto-increment-in-schema-design} -TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。ただし、分散データベースであるTiDBは、通常複数のコンピューティングノード（クライアント側の接続先）を備えています。アプリケーションデータの書き込み時には、ワークロードが均等に分散されます。そのため、テーブルに`AUTO_INCREMENT`列がある場合、その列のAUTO_INCREMENT IDが不連続になる可能性があります。詳細については、 [AUTO_INCREMENT](/auto-increment.md#implementation-principles)参照してください。 +TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。ただし、分散データベースであるTiDBは、通常複数のコンピューティングノード（クライアント側の接続先）を備えています。アプリケーションデータの書き込み時には、ワークロードが均等に分散されます。そのため、テーブルに`AUTO_INCREMENT`列がある場合、その列のAUTO_INCREMENT IDが不連続になる可能性があります。詳細については、 [AUTO_INCREMENT](/auto-increment.md#implementation-principles)を参照してください。 ビジネスでAUTO_INCREMENT ID に大きく依存している場合は、 [MySQL互換の`AUTO_INCREMENT`モード](/auto-increment.md#mysql-compatibility-mode)または[`SEQUENCE`関数](/sql-statements/sql-statement-create-sequence.md#sequence-function)使用を検討してください。 @@ -49,7 +49,7 @@ TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。 - クラスター化インデックス - [クラスター化インデックス](/clustered-indexes.md) 、データストレージのハンドルID（行ID）として主キーを使用します。主キーを使用してクエリを実行すると、テーブル参照を回避できるため、クエリのパフォーマンスが効果的に向上します。ただし、テーブルが書き込み中心で、主キーに[`AUTO_INCREMENT`](/auto-increment.md)使用している場合、 [書き込みホットスポットの問題](/best-practices/high-concurrency-best-practices.md#highly-concurrent-write-intensive-scenario)発生する可能性が高く、クラスターのパフォーマンスが低下し、単一のストレージノードのパフォーマンスボトルネックが発生します。 + [クラスター化インデックス](/clustered-indexes.md) 、データストレージのハンドルID（行ID）として主キーを使用します。主キーを使用してクエリを実行すると、テーブル参照を回避できるため、クエリのパフォーマンスが効果的に向上します。ただし、テーブルが書き込み中心で、主キーに[`AUTO_INCREMENT`](/auto-increment.md)を使用している場合、 [書き込みホットスポットの問題](/best-practices/high-concurrency-best-practices.md#highly-concurrent-write-intensive-scenario)発生する可能性が高く、クラスターのパフォーマンスが低下し、単一のストレージノードのパフォーマンスボトルネックが発生します。 - 非クラスター化インデックス + `shard row id bit` @@ -100,17 +100,17 @@ DMはデフォルトで悲観的モードを使用します。MySQLシャード | シナリオ | 長所 | 短所 | | :----------- | :--------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 悲観モード（デフォルト） | 下流に移行されたデータが間違っていないことを保証できます。 | シャードの数が多い場合、移行タスクは長時間ブロックされるか、アップストリームのバイナリログがクリーンアップされている場合は停止することもあります。この問題を回避するには、リレーログを有効にしてください。詳細については、 [リレーログを使用する](#use-the-relay-log)参照してください。 | -| 楽観モード | アップストリーム スキーマの変更によってデータ移行のレイテンシーが発生することはありません。 | このモードでは、スキーマ変更の互換性（増分列にデフォルト値があるかどうか）を確認します。不整合なデータが無視される可能性があります。詳細については、 [オプティミスティックモードでシャードテーブルからデータをマージおよび移行する](/dm/feature-shard-merge-optimistic.md#restrictions)参照してください。 | +| 楽観モード | アップストリーム スキーマの変更によってデータ移行のレイテンシーが発生することはありません。 | このモードでは、スキーマ変更の互換性（増分列にデフォルト値があるかどうか）を確認します。不整合なデータが無視される可能性があります。詳細については、 [オプティミスティックモードでシャードテーブルからデータをマージおよび移行する](/dm/feature-shard-merge-optimistic.md#restrictions)を参照してください。 | ### その他の制限と影響 {#other-restrictions-and-impact} #### 上流と下流のデータ型 {#data-types-in-upstream-and-downstream} -TiDBはMySQLのほとんどのデータ型をサポートしています。ただし、一部の特殊な型（ `SPATIAL`など）はまだサポートされていません。データ型の互換性については、 [データ型](/data-type-overview.md)参照してください。 +TiDBはMySQLのほとんどのデータ型をサポートしています。ただし、一部の特殊な型（ `SPATIAL`など）はまだサポートされていません。データ型の互換性については、 [データ型](/data-type-overview.md)を参照してください。 #### 文字セットと照合順序 {#character-sets-and-collations} -TiDB v6.0.0以降、新しい照合順序フレームワークがデフォルトで使用されます。以前のバージョンでは、TiDBでutf8_general_ci、utf8mb4_general_ci、utf8_unicode_ci、utf8mb4_unicode_ci、gbk_chinese_ci、gbk_binをサポートするには、クラスター作成時に`new_collations_enabled_on_first_bootstrap`を`true`に設定して明示的に宣言する必要がありました。詳細については、 [照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)参照してください。 +TiDB v6.0.0以降、新しい照合順序フレームワークがデフォルトで使用されます。以前のバージョンでは、TiDBでutf8_general_ci、utf8mb4_general_ci、utf8_unicode_ci、utf8mb4_unicode_ci、gbk_chinese_ci、gbk_binをサポートするには、クラスター作成時に`new_collations_enabled_on_first_bootstrap`を`true`に設定して明示的に宣言する必要がありました。詳細については、 [照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)を参照してください。 TiDBのデフォルトの文字セットはutf8mb4です。上流および下流のデータベースとアプリケーションではutf8mb4を使用することをお勧めします。上流データベースで文字セットまたは照合順序が明示的に指定されている場合は、TiDBがそれをサポートしているかどうかを確認する必要があります。 @@ -151,7 +151,7 @@ MySQLシャードの移行とマージを行う際、上流のシャードの種 #### アップストリームデータソースを選択して構成する {#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)を参照してください。 次の点に注意してください。 @@ -175,7 +175,7 @@ TiDBスキーマ名はデフォルトでは大文字と小文字を区別しま #### フィルタールール {#filter-rules} -データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 [データ移行タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)参照してください。フィルタールールを設定することの利点は次のとおりです。 +データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 [データ移行タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)を参照してください。フィルタールールを設定することの利点は次のとおりです。 - ダウンストリームで処理する必要があるBinlogイベントの数を減らし、移行の効率を向上させます。 - 不要なリレーログのストレージを削減し、ディスク領域を節約します。 @@ -192,13 +192,13 @@ MySQLのマスター/スタンバイメカニズムでは、非同期レプリ - DMを使用して長時間のデータレプリケーションを実行する場合、様々な理由により移行タスクが長時間ブロックされることがあります。リレーログを有効にすると、移行タスクのブロックによって上流のバイナリログが再利用される問題を効果的に解決できます。 -リレーログの使用にはいくつかの制限があります。DMは高可用性をサポートしています。DMワーカーに障害が発生すると、アイドル状態のDMワーカーインスタンスを稼働中のインスタンスに昇格させようとします。アップストリームのバイナリログに必要な移行ログが含まれていない場合、中断が発生する可能性があります。リレーログを新しいDMワーカーノードにできるだけ早く手動でコピーし、対応するリレーメタファイルを変更する必要があります。詳細については、 [トラブルシューティング](/dm/dm-error-handling.md#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-get-binlog-error-error-1236-hy000-and-binlog-checksum-mismatch-data-may-be-corrupted-returned)参照してください。 +リレーログの使用にはいくつかの制限があります。DMは高可用性をサポートしています。DMワーカーに障害が発生すると、アイドル状態のDMワーカーインスタンスを稼働中のインスタンスに昇格させようとします。アップストリームのバイナリログに必要な移行ログが含まれていない場合、中断が発生する可能性があります。リレーログを新しいDMワーカーノードにできるだけ早く手動でコピーし、対応するリレーメタファイルを変更する必要があります。詳細については、 [トラブルシューティング](/dm/dm-error-handling.md#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-migration-task-is-interrupted-with-failing-to-get-or-parse-binlog-errors-like-get-binlog-error-error-1236-hy000-and-binlog-checksum-mismatch-data-may-be-corrupted-returned)を参照してください。 #### アップストリームでPT-osc/GH-ostを使用する {#use-pt-osc-gh-ost-in-upstream} MySQLの日常的な運用・保守では、業務への影響を最小限に抑えるため、通常、PT-osc/GH-ostなどのツールを使用してオンラインでスキーマを変更します。しかし、このプロセス全体はMySQL Binlogに記録されます。このようなデータを下流のTiDBに移行すると、不要な書き込み操作が大量に発生し、効率的でも経済的でもありません。 -この問題を解決するため、DMは移行タスクの設定時にPT-oscやGH-ostなどのサードパーティ製データツールをサポートしています。これらのツールを使用すると、DMは冗長データを移行せず、データの整合性を確保します。詳細については、 [GH-ost/PT-osc を使用するデータベースからの移行](/dm/feature-online-ddl.md)参照してください。 +この問題を解決するため、DMは移行タスクの設定時にPT-oscやGH-ostなどのサードパーティ製データツールをサポートしています。これらのツールを使用すると、DMは冗長データを移行せず、データの整合性を確保します。詳細については、 [GH-ost/PT-osc を使用するデータベースからの移行](/dm/feature-online-ddl.md)を参照してください。 ## 移行中のベストプラクティス {#best-practices-during-migration} @@ -213,13 +213,13 @@ MySQLの日常的な運用・保守では、業務への影響を最小限に抑 このような問題は通常、下流TiDBのインデックスの変更または追加、あるいは下流TiDBの列数の増加によって発生します。このようなエラーが発生した場合は、上流と下流のスキーマに不整合がないか確認してください。 -このような問題を解決するには、DMにキャッシュされたスキーマ情報を下流のTiDBスキーマと一致するように更新します。詳細については、 [移行するテーブルのテーブルスキーマを管理する](/dm/dm-manage-schema.md)参照してください。 +このような問題を解決するには、DMにキャッシュされたスキーマ情報を下流のTiDBスキーマと一致するように更新します。詳細については、 [移行するテーブルのテーブルスキーマを管理する](/dm/dm-manage-schema.md)を参照してください。 -下流にさらに列がある場合は、 [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md)参照してください。 +下流にさらに列がある場合は、 [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md)を参照してください。 ### DDL の失敗により移行タスクが中断されました {#interrupted-migration-task-due-to-failed-ddl} -DMは、移行タスクの中断を引き起こすDDL文のスキップまたは置換をサポートしています。詳細については、 [失敗したDDL文の処理](/dm/handle-failed-ddl-statements.md#usage-examples)参照してください。 +DMは、移行タスクの中断を引き起こすDDL文のスキップまたは置換をサポートしています。詳細については、 [失敗したDDL文の処理](/dm/handle-failed-ddl-statements.md#usage-examples)を参照してください。 ## データ移行後のデータ検証 {#data-validation-after-data-migration} @@ -227,8 +227,8 @@ DMは、移行タスクの中断を引き起こすDDL文のスキップまたは sync-diff-inspector は、DM タスクを通じてデータ整合性チェック対象のテーブルリストを自動管理できるようになりました。以前の手動設定と比較して、より効率的です。詳細は[DM レプリケーション シナリオにおけるデータ チェック](/sync-diff-inspector/dm-diff.md)ご覧ください。 -DM v6.2.0以降、DMは増分レプリケーションにおける継続的なデータ検証をサポートしています。詳細については、 [DMにおける継続的なデータ検証](/dm/dm-continuous-data-validation.md)参照してください。 +DM v6.2.0以降、DMは増分レプリケーションにおける継続的なデータ検証をサポートしています。詳細については、 [DMにおける継続的なデータ検証](/dm/dm-continuous-data-validation.md)を参照してください。 ## 長期データ複製 {#long-term-data-replication} -DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスタの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 [データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)参照してください。 +DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスタの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 [データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)を参照してください。 diff --git a/dm/dm-binlog-event-filter.md b/dm/dm-binlog-event-filter.md index 17ce31f228a57..24052a2b37af5 100644 --- a/dm/dm-binlog-event-filter.md +++ b/dm/dm-binlog-event-filter.md @@ -21,7 +21,7 @@ filters: ​action: Ignore ``` -DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィルターを設定できます。詳細については、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 +DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィルターを設定できます。詳細については、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 一致するスキーマとテーブルにワイルドカードを使用する場合は、次の点に注意してください。 diff --git a/dm/dm-customized-secret-key.md b/dm/dm-customized-secret-key.md index b5a60629565be..23dc1301db9d1 100644 --- a/dm/dm-customized-secret-key.md +++ b/dm/dm-customized-secret-key.md @@ -5,7 +5,7 @@ summary: DM（データ移行）データ ソースおよび移行タスク構 # DM 暗号化と復号化用の秘密鍵をカスタマイズする {#customize-a-secret-key-for-dm-encryption-and-decryption} -バージョン8.0.0より前のバージョンでは、 [DM](/dm/dm-overview.md)データソースおよび移行タスク設定内のパスワードの暗号化と復号に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)使用していました。しかし、固定の秘密鍵を使用すると、特にセキュリティが極めて重要な環境ではセキュリティリスクが生じる可能性があります。セキュリティを強化するため、バージョン8.0.0以降、DMは固定の秘密鍵を削除し、秘密鍵をカスタマイズできるようになりました。 +バージョン8.0.0より前のバージョンでは、 [DM](/dm/dm-overview.md)データソースおよび移行タスク設定内のパスワードの暗号化と復号に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)を使用していました。しかし、固定の秘密鍵を使用すると、特にセキュリティが極めて重要な環境ではセキュリティリスクが生じる可能性があります。セキュリティを強化するため、バージョン8.0.0以降、DMは固定の秘密鍵を削除し、秘密鍵をカスタマイズできるようになりました。 ## 使用法 {#usage} @@ -18,8 +18,8 @@ DM はバージョン 8.0.0 以降では固定秘密キーを使用しなくな - [データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの構成](/dm/task-configuration-file-full.md)両方でプレーンテキスト パスワードが使用されている場合、アップグレードに追加の手順は必要ありません。 - [データソース構成](/dm/dm-source-configuration-file.md)と[移行タスクの構成](/dm/task-configuration-file-full.md)で暗号化されたパスワードが使用されている場合、または将来的に暗号化されたパスワードを使用する場合は、次の手順を実行する必要があります。 - 1. [DMマスター構成ファイル](/dm/dm-master-configuration-file.md)に`secret-key-path`パラメータを追加し、カスタムキーファイルのパスを指定します。ファイルには、64 文字の 16 進数 AES-256 キーが含まれている必要があります。アップグレード前に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)使用して暗号化していた場合は、この秘密鍵をキーファイルにコピーできます。すべての DM マスターノードで同じ秘密鍵設定が使用されていることを確認してください。 - 2. まずDMマスターのローリングアップグレードを実行し、次にDMワーカーのローリングアップグレードを実行します。詳細については、 [ローリングアップグレード](/dm/maintain-dm-using-tiup.md#rolling-upgrade)参照してください。 + 1. [DMマスター構成ファイル](/dm/dm-master-configuration-file.md)に`secret-key-path`パラメータを追加し、カスタムキーファイルのパスを指定します。ファイルには、64 文字の 16 進数 AES-256 キーが含まれている必要があります。アップグレード前に[固定AES-256秘密鍵](https://github.com/pingcap/tiflow/blob/1252979421fc83ffa2a1548d981e505f7fc0b909/dm/pkg/encrypt/encrypt.go#L27)を使用して暗号化していた場合は、この秘密鍵をキーファイルにコピーできます。すべての DM マスターノードで同じ秘密鍵設定が使用されていることを確認してください。 + 2. まずDMマスターのローリングアップグレードを実行し、次にDMワーカーのローリングアップグレードを実行します。詳細については、 [ローリングアップグレード](/dm/maintain-dm-using-tiup.md#rolling-upgrade)を参照してください。 ## 暗号化と復号化の秘密鍵を更新する {#update-the-secret-key-for-encryption-and-decryption} @@ -30,8 +30,8 @@ DM はバージョン 8.0.0 以降では固定秘密キーを使用しなくな > **注記：** > > - すべての DM マスター ノードが同じ秘密キー構成に更新されていることを確認します。 - > - 秘密鍵の更新中は、新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)または[移行タスク構成ファイル](/dm/task-configuration-file-full.md)作成しないでください。 + > - 秘密鍵の更新中は、新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)または[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成しないでください。 2. DM マスターのローリング再起動を実行します。 -3. 新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)と[移行タスク構成ファイル](/dm/task-configuration-file-full.md)作成するときは、 `tiup dmctl encrypt` (dmctl バージョン >= v8.0.0) で暗号化されたパスワードを使用します。 +3. 新しい[データソース構成ファイル](/dm/dm-source-configuration-file.md)と[移行タスク構成ファイル](/dm/task-configuration-file-full.md)を作成するときは、 `tiup dmctl encrypt` (dmctl バージョン >= v8.0.0) で暗号化されたパスワードを使用します。 diff --git a/dm/dm-daily-check.md b/dm/dm-daily-check.md index 4042695b13fac..76ab7cb6ee3c6 100644 --- a/dm/dm-daily-check.md +++ b/dm/dm-daily-check.md @@ -7,9 +7,9 @@ summary: TiDB Data Migration (DM) の毎日のチェックについて説明し このドキュメントでは、TiDB Data Migration (DM) の毎日のチェックを実行する方法をまとめています。 -- 方法1：コマンド`query-status`を実行して、タスクの実行状態とエラー出力（ある場合）を確認します。詳細は[クエリステータス](/dm/dm-query-status.md)参照してください。 +- 方法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 の実行状態とエラー (ある場合) を確認します。 diff --git a/dm/dm-enable-tls.md b/dm/dm-enable-tls.md index 21a130e8624e8..0438a29e9ee10 100644 --- a/dm/dm-enable-tls.md +++ b/dm/dm-enable-tls.md @@ -89,7 +89,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 ### 上流データベースへの暗号化されたデータ転送を有効にする {#enable-encrypted-data-transmission-for-upstream-database} -1. アップストリームデータベースを設定し、暗号化サポートを有効にし、サーバー証明書を設定します。詳細な操作については、 [暗号化された接続の使用](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html)参照してください。 +1. アップストリームデータベースを設定し、暗号化サポートを有効にし、サーバー証明書を設定します。詳細な操作については、 [暗号化された接続の使用](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html)を参照してください。 2. ソース構成ファイルで MySQL クライアント証明書を設定します。 diff --git a/dm/dm-error-handling.md b/dm/dm-error-handling.md index 131fe19e62965..800a248c531a5 100644 --- a/dm/dm-error-handling.md +++ b/dm/dm-error-handling.md @@ -174,7 +174,7 @@ binlogレプリケーション処理ユニットの場合は、次のソリュ ### タスクをクエリするかログを確認すると、 Access denied for user 'root'@'172.31.43.27' (using password: YES)表示されます。 {#code-access-denied-for-user-root-172-31-43-27-using-password-yes-code-shows-when-you-query-the-task-or-check-the-log} -すべてのDM設定ファイルにおけるデータベース関連のパスワードについては、 `dmctl`で暗号化したパスワードを使用することをお勧めします。データベースパスワードが空の場合は、暗号化する必要はありません。プレーンテキストパスワードの暗号化方法については、 [dmctlを使用してデータベースパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)参照してください。 +すべてのDM設定ファイルにおけるデータベース関連のパスワードについては、 `dmctl`で暗号化したパスワードを使用することをお勧めします。データベースパスワードが空の場合は、暗号化する必要はありません。プレーンテキストパスワードの暗号化方法については、 [dmctlを使用してデータベースパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 さらに、上流データベースと下流データベースのユーザーには、対応する読み取り権限と書き込み権限が必要です。データ移行タスクを開始する際には、データ移行も[対応する権限を自動的に事前チェックします](/dm/dm-precheck.md)必要です。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 1129293e864ae..59cfe328bb5eb 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -16,11 +16,11 @@ Alibaba Cloud RDS の主キーのないアップストリーム テーブルの 互換性に関する既知の問題は次のとおりです。 - **Alibaba Cloud RDS**では、主キーのないアップストリーム テーブルの場合、そのbinlog には非表示の主キー列がまだ含まれており、元のテーブル構造と一致していません。 -- **HUAWEI Cloud RDS**では、 binlogファイルの直接読み取りはサポートされていません。詳細については、 [HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?](https://support.huaweicloud.com/en-us/rds_faq/rds_faq_0210.html)参照してください。 +- **HUAWEI Cloud RDS**では、 binlogファイルの直接読み取りはサポートされていません。詳細については、 [HUAWEI Cloud RDS はBinlogバックアップファイルを直接読み取ることができますか?](https://support.huaweicloud.com/en-us/rds_faq/rds_faq_0210.html)を参照してください。 ## タスク構成のブロックおよび許可リストの正規表現は、 non-capturing (?!) ? {#does-the-regular-expression-of-the-block-and-allow-list-in-the-task-configuration-support-code-non-capturing-code} -現在、DMはこれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。Golangでサポートされている正規表現については、 [re2構文](https://github.com/google/re2/wiki/Syntax)参照してください。 +現在、DMはこれをサポートしておらず、 Golang標準ライブラリの正規表現のみをサポートしています。Golangでサポートされている正規表現については、 [re2構文](https://github.com/google/re2/wiki/Syntax)を参照してください。 ## アップストリームで実行されたステートメントに複数の DDL 操作が含まれている場合、DM はそのような移行をサポートしますか? {#if-a-statement-executed-upstream-contains-multiple-ddl-operations-does-dm-support-such-migration} @@ -28,11 +28,11 @@ DMは、複数のDDL変更操作を含む単一のステートメントを、1 ## 互換性のない DDL ステートメントをどのように処理しますか? {#how-to-handle-incompatible-ddl-statements} -TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを使用して手動で処理する必要があります（DDL文をスキップするか、指定されたDDL文に置き換えます）。詳細は[失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md)参照してください。 +TiDBでサポートされていないDDL文に遭遇した場合は、dmctlを使用して手動で処理する必要があります（DDL文をスキップするか、指定されたDDL文に置き換えます）。詳細は[失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md)を参照してください。 > **注記：** > -> 現在、TiDBはMySQLがサポートするすべてのDDL文と互換性がありません[MySQLの互換性](/mysql-compatibility.md#ddl-operations)参照してください。 +> 現在、TiDBはMySQLがサポートするすべてのDDL文と互換性がありません[MySQLの互換性](/mysql-compatibility.md#ddl-operations)を参照してください。 ## DM はビュー関連の DDL ステートメントと DML ステートメントを TiDB に複製しますか? {#does-dm-replicate-view-related-ddl-statements-and-dml-statements-to-tidb} @@ -175,7 +175,7 @@ curl -X POST -d "tidb_general_log=0" http://{TiDBIP}:10080/settings ## 一部の監視パネルにNo data pointと表示されるのはなぜですか? {#why-do-some-monitoring-panels-show-code-no-data-point-code} -一部のパネルにデータが表示されないのは正常です。例えば、エラーが報告されていない場合、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-v1-0-why-does-the-command-code-sql-skip-code-fail-to-skip-some-statements-when-the-task-is-in-error} diff --git a/dm/dm-glossary.md b/dm/dm-glossary.md index 9b35617f3f4a9..4cfdd99dbf4cd 100644 --- a/dm/dm-glossary.md +++ b/dm/dm-glossary.md @@ -7,13 +7,13 @@ summary: TiDB Data Migration で使用される用語を学習します。 このドキュメントでは、TiDB Data Migration (DM) のログ、監視、構成、およびドキュメントで使用される用語を示します。 -TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)参照してください。 +TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)を参照してください。 ## B {#b} ### Binlog {#binlog} -TiDB DMにおけるbinlogは、TiDBデータベース内で生成されるバイナリログファイルを指します。MySQLやMariaDBにおけるbinlogと同様の意味を持ちます。詳細は[MySQL バイナリログ](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_replication.html)と[MariaDB バイナリログ](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log)参照してください。 +TiDB DMにおけるbinlogは、TiDBデータベース内で生成されるバイナリログファイルを指します。MySQLやMariaDBにおけるbinlogと同様の意味を持ちます。詳細は[MySQL バイナリログ](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_replication.html)と[MariaDB バイナリログ](https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log)を参照してください。 ### Binlogイベント {#binlog-event} @@ -25,7 +25,7 @@ Binlogイベントは、MySQLまたはMariaDBサーバーインスタンスに ### Binlogの位置 {#binlog-position} -binlog位置は、 binlogファイル内のbinlogイベントのオフセット情報です。詳細は[MySQL `SHOW BINLOG EVENTS`](https://dev.mysql.com/doc/refman/8.0/en/show-binlog-events.html)と[MariaDB `SHOW BINLOG EVENTS`](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-binlog-events)参照してください。 +binlog位置は、 binlogファイル内のbinlogイベントのオフセット情報です。詳細は[MySQL `SHOW BINLOG EVENTS`](https://dev.mysql.com/doc/refman/8.0/en/show-binlog-events.html)と[MariaDB `SHOW BINLOG EVENTS`](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/show/show-binlog-events)を参照してください。 ### Binlog複製処理ユニット/同期ユニット {#binlog-replication-processing-unit-sync-unit} @@ -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} diff --git a/dm/dm-handle-performance-issues.md b/dm/dm-handle-performance-issues.md index 7c5c39b9f4db1..9377dcbd432de 100644 --- a/dm/dm-handle-performance-issues.md +++ b/dm/dm-handle-performance-issues.md @@ -55,7 +55,7 @@ binlogイベントをリレーログファイルに書き込む場合、関連 ## Binlogレプリケーションユニット {#binlog-replication-unit} -Binlogレプリケーションユニットのパフォーマンス問題を診断するには、 `binlog file gap between master and syncer`監視メトリックを確認できます。このメトリックの詳細については、 [Binlogレプリケーションの監視メトリクス](/dm/monitor-a-dm-cluster.md#binlog-replication)参照してください。 +Binlogレプリケーションユニットのパフォーマンス問題を診断するには、 `binlog file gap between master and syncer`監視メトリックを確認できます。このメトリックの詳細については、 [Binlogレプリケーションの監視メトリクス](/dm/monitor-a-dm-cluster.md#binlog-replication)を参照してください。 - このメトリックが長時間にわたって 1 より大きい場合、通常はパフォーマンスの問題があることを示します。 - このメトリックが 0 の場合、通常はパフォーマンスの問題がないことを示します。 diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md index 648bc3ac07e2e..f57ca8a48d8c4 100644 --- a/dm/dm-manage-schema.md +++ b/dm/dm-manage-schema.md @@ -5,7 +5,7 @@ summary: DM で移行するテーブルのスキーマを管理する方法を # TiDB データ移行を使用して移行するテーブルのテーブルスキーマを管理する {#manage-table-schemas-of-tables-to-be-migrated-using-tidb-data-migration} -このドキュメントでは、 [dmctl](/dm/dmctl-introduction.md)使用して移行中に DM でテーブルのスキーマを管理する方法について説明します。 +このドキュメントでは、 [dmctl](/dm/dmctl-introduction.md)を使用して移行中に DM でテーブルのスキーマを管理する方法について説明します。 DMが増分レプリケーションを実行する際、まず上流のbinlogを読み取り、SQL文を作成して下流で実行します。ただし、上流のbinlogには完全なテーブルスキーマは含まれていません。SQL文を生成するために、DMは移行対象のテーブルのスキーマ情報を内部的に保持します。これを内部テーブルスキーマと呼びます。 diff --git a/dm/dm-manage-source.md b/dm/dm-manage-source.md index dc6525d105058..0da6ff4fdc214 100644 --- a/dm/dm-manage-source.md +++ b/dm/dm-manage-source.md @@ -144,7 +144,7 @@ help transfer-source Global Flags: -s, --source strings MySQL Source ID. -転送前に、DM はバインド解除するワーカーに実行中のタスクがあるかどうかを確認します。ワーカーに実行中のタスクがある場合は、まず[タスクを一時停止する](/dm/dm-pause-task.md)実行し、バインドを変更してから[タスクを再開する](/dm/dm-resume-task.md)実行する必要があります。 +転送前に、DM はバインド解除対象のワーカーに実行中のタスクがあるかどうかを確認します。ワーカーに実行中のタスクがある場合は、まず[タスクを一時停止](/dm/dm-pause-task.md)し、バインドを変更してから[タスクを再開](/dm/dm-resume-task.md)する必要があります。 ### 使用例 {#usage-example} diff --git a/dm/dm-master-configuration-file.md b/dm/dm-master-configuration-file.md index 11cd4718f34da..ae7b055c81709 100644 --- a/dm/dm-master-configuration-file.md +++ b/dm/dm-master-configuration-file.md @@ -100,4 +100,4 @@ secret-key-path = "/path/to/secret/key" #### `secret-key-path` {#secret-key-path} -- アップストリームおよびダウンストリームのパスワードの暗号化と復号化に使用される秘密鍵のファイルパス。ファイルには、64文字の16進数AES-256秘密鍵が含まれている必要があります。この鍵を生成する方法の一つは、ランダムデータ（例： `head -n 256 /dev/urandom | sha256sum` ）のSHA256チェックサムを計算することです。詳細については、 [DMの暗号化と復号化のための秘密鍵をカスタマイズする](/dm/dm-customized-secret-key.md)参照してください。 +- アップストリームおよびダウンストリームのパスワードの暗号化と復号化に使用される秘密鍵のファイルパス。ファイルには、64文字の16進数AES-256秘密鍵が含まれている必要があります。この鍵を生成する方法の一つは、ランダムデータ（例： `head -n 256 /dev/urandom | sha256sum` ）のSHA256チェックサムを計算することです。詳細については、 [DMの暗号化と復号化のための秘密鍵をカスタマイズする](/dm/dm-customized-secret-key.md)を参照してください。 diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index 444faa55fb40d..e8d4fc16a4bde 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -29,7 +29,7 @@ OpenAPI を有効にするには、次のいずれかの操作を実行します > > - DM マスター ノードを展開した後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 > -> - 設定ファイルでサポートされている一部の機能は、OpenAPIではサポートされていません。これらの機能は完全には連携されていません。本番環境では、 [設定ファイル](/dm/dm-config-overview.md)使用することをお勧めします。 +> - 設定ファイルでサポートされている一部の機能は、OpenAPIではサポートされていません。これらの機能は完全には連携されていません。本番環境では、 [設定ファイル](/dm/dm-config-overview.md)を使用することをお勧めします。 API を使用して、DM クラスターで次のメンテナンス操作を実行できます。 diff --git a/dm/dm-overview.md b/dm/dm-overview.md index d43ae715709c7..5bfc0262663f6 100644 --- a/dm/dm-overview.md +++ b/dm/dm-overview.md @@ -20,7 +20,7 @@ summary: データ移行ツール、そのアーキテクチャ、主要コン - **MySQLシャードの移行とマージ。DM**は、複数のMySQLデータベースインスタンスを上流から下流の1つのTiDBデータベースに移行およびマージすることをサポートします。さまざまな移行シナリオに合わせてレプリケーションルールをカスタマイズできます。上流のMySQLシャードのDDL変更を自動的に検出して処理できるため、運用コストを大幅に削減できます。 - **さまざまな種類のフィルタ。**イベントタイプ、正規表現、SQL式を事前に定義することで、データ移行プロセス中にMySQLbinlogイベントをフィルタリングできます。 - **集中管理。DM**はクラスタ内の数千ノードをサポートし、多数のデータ移行タスクを同時に実行および管理できます。 -- **サードパーティのオンラインスキーマ変更プロセスの最適化。MySQL**エコシステムでは、gh-ostやpt-oscなどのツールが広く使用されています。DMは、中間データの不要な移行を回避するために変更プロセスを最適化します。詳細は、[オンラインDDL](/dm/dm-online-ddl-tool-support.md)参照してください。 +- **サードパーティのオンラインスキーマ変更プロセスの最適化。MySQL**エコシステムでは、gh-ostやpt-oscなどのツールが広く使用されています。DMは、中間データの不要な移行を回避するために変更プロセスを最適化します。詳細は、[オンラインDDL](/dm/dm-online-ddl-tool-support.md)を参照してください。 - **高可用性。DM**は、データ移行タスクを異なるノードに自由にスケジュールすることをサポートします。少数のノードがクラッシュしても、実行中のタスクには影響しません。 ## クイックインストール {#quick-installation} @@ -51,9 +51,9 @@ DMツールを使用する前に、以下の制限事項にご注意ください - DDL構文の互換性 - - 現在、TiDBはMySQLがサポートするすべてのDDLステートメントと互換性があるわけではありません。DMはTiDBパーサーを使用してDDLステートメントを処理するため、TiDBパーサーがサポートするDDL構文のみをサポートします。詳細については、 [MySQLとの互換性](/mysql-compatibility.md#ddl-operations)参照してください。 + - 現在、TiDBはMySQLがサポートするすべてのDDLステートメントと互換性があるわけではありません。DMはTiDBパーサーを使用してDDLステートメントを処理するため、TiDBパーサーがサポートするDDL構文のみをサポートします。詳細については、 [MySQLとの互換性](/mysql-compatibility.md#ddl-operations)を参照してください。 - - DM は、互換性のない DDL ステートメントが発生するとエラーを報告します。このエラーを解決するには、dmctl を使用して手動で処理し、この DDL ステートメントをスキップするか、指定された DDL ステートメントに置き換える必要があります。詳細については、 [異常な SQL ステートメントをスキップまたは置換します](/dm/dm-faq.md#how-to-handle-incompatible-ddl-statements)参照してください。 + - DM は、互換性のない DDL ステートメントが発生するとエラーを報告します。このエラーを解決するには、dmctl を使用して手動で処理し、この DDL ステートメントをスキップするか、指定された DDL ステートメントに置き換える必要があります。詳細については、 [異常な SQL ステートメントをスキップまたは置換します](/dm/dm-faq.md#how-to-handle-incompatible-ddl-statements)を参照してください。 - DMは、ビュー関連のDDLステートメントおよびDMLステートメントをダウンストリームのTiDBクラスタに複製しません。ダウンストリームのTiDBクラスタでビューを手動で作成することをお勧めします。 diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md index 2c58d5ee2be09..bce894497e2cc 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -46,7 +46,7 @@ sysbench --test=oltp_insert --tables=4 --mysql-host=172.16.4.40 --mysql-port=330 #### データ移行タスクを作成する {#create-a-data-migration-task} -1. アップストリームMySQLソースを作成し、 `source-id`を`source-1`に設定します。詳細は[データソース構成をロードする](/dm/dm-manage-source.md#operate-data-source)参照してください。 +1. アップストリームMySQLソースを作成し、 `source-id`を`source-1`に設定します。詳細は[データソース構成をロードする](/dm/dm-manage-source.md#operate-data-source)を参照してください。 2. 移行タスクを作成します（モード`full` ）。タスク設定テンプレートは次のとおりです。 @@ -80,7 +80,7 @@ mydumpers: threads: 32 ``` -移行タスクの作成方法の詳細については、 [データ移行タスクを作成する](/dm/dm-create-task.md)参照してください。 +移行タスクの作成方法の詳細については、 [データ移行タスクを作成する](/dm/dm-create-task.md)を参照してください。 > **注記：** > @@ -103,7 +103,7 @@ DM-worker のログを確認してください。1 `all data files have been fin #### データ移行タスクを作成する {#create-a-data-migration-task} -1. アップストリームMySQLのソースを作成します。1を`source-id` `source-1`設定します（ [完全インポートベンチマークケース](#full-import-benchmark-case)でソースを作成済みの場合は、再度作成する必要はありません）。詳細は[データソース構成をロードする](/dm/dm-manage-source.md#operate-data-source)参照してください。 +1. アップストリームMySQLのソースを作成します。1を`source-id` `source-1`設定します（ [完全インポートベンチマークケース](#full-import-benchmark-case)でソースを作成済みの場合は、再度作成する必要はありません）。詳細は[データソース構成をロードする](/dm/dm-manage-source.md#operate-data-source)を参照してください。 2. DM移行タスク（モード`all` ）を作成します。タスク設定ファイルの例を以下に示します。 @@ -136,7 +136,7 @@ syncers: batch: 100 ``` -データ移行タスクの作成方法の詳細については、 [データ移行タスクを作成する](/dm/dm-create-task.md)参照してください。 +データ移行タスクの作成方法の詳細については、 [データ移行タスクを作成する](/dm/dm-create-task.md)を参照してください。 > **注記：** > @@ -156,4 +156,4 @@ sysbench --test=oltp_insert --tables=4 --num-threads=32 --mysql-host=172.17.4.40 #### テスト結果を取得する {#get-test-results} -DMの移行ステータスを確認するには、コマンド`query-status`実行してください。DMの監視メトリクスを確認するには、Grafanaを使用してください。ここでの監視メトリクスとは、 `finished sqls jobs` （単位時間あたりに完了したジョブ数）およびその他の関連メトリクスを指します。詳細については、 [Binlog移行監視メトリクス](/dm/monitor-a-dm-cluster.md#binlog-replication)参照してください。 +DMの移行ステータスを確認するには、コマンド`query-status`実行してください。DMの監視メトリクスを確認するには、Grafanaを使用してください。ここでの監視メトリクスとは、 `finished sqls jobs` （単位時間あたりに完了したジョブ数）およびその他の関連メトリクスを指します。詳細については、 [Binlog移行監視メトリクス](/dm/monitor-a-dm-cluster.md#binlog-replication)を参照してください。 diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index 87702d5be2c2b..9aeb7020dbd03 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -50,9 +50,9 @@ tiup dmctl check-task ./task.yaml - アップストリームのMySQLテーブルスキーマの互換性 - - アップストリームテーブルに外部キーがあるかどうかを確認してください。TiDBは外部キーをサポートしています（v8.5.0以降でGA）。また、DMはv8.5.6以降、外部キー制約を持つテーブルのレプリケーションを実験的にサポートしています。事前チェック中に、外部キーが検出された場合、DMは警告を返します。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)参照してください。 . + - アップストリームテーブルに外部キーがあるかどうかを確認してください。TiDBは外部キーをサポートしています（v8.5.0以降でGA）。また、DMはv8.5.6以降、外部キー制約を持つテーブルのレプリケーションを実験的にサポートしています。事前チェック中に、外部キーが検出された場合、DMは警告を返します。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)を参照してください。 . - - 上流のテーブルで TiDB と互換性のない文字セットが使用されていないか確認してください。詳細については、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)参照してください。 + - 上流のテーブルで TiDB と互換性のない文字セットが使用されていないか確認してください。詳細については、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を参照してください。 - 上流テーブルに主キー制約または一意キー制約（v1.0.7以降で導入）があるかどうかを確認します。 @@ -92,7 +92,7 @@ tiup dmctl check-task ./task.yaml - シャーディングされたテーブルで主キーをAUTO_INCREMENTする - - シャードテーブルにAUTO_INCREMENT主キーがある場合、事前チェックにより警告が返されます。AUTO_INCREMENT主キーに競合がある場合の解決策については、 [AUTO_INCREMENT主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)参照してください。 + - シャードテーブルにAUTO_INCREMENT主キーがある場合、事前チェックにより警告が返されます。AUTO_INCREMENT主キーに競合がある場合の解決策については、 [AUTO_INCREMENT主キーの競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-of-auto-increment-primary-key)を参照してください。 #### 物理インポートの確認項目 {#check-items-for-physical-import} diff --git a/dm/dm-query-status.md b/dm/dm-query-status.md index 2383396674776..d0dbfbb3ef038 100644 --- a/dm/dm-query-status.md +++ b/dm/dm-query-status.md @@ -230,7 +230,7 @@ DM移行タスクのステータスは、DMワーカーに割り当てられた - `stage` : サブタスクのステータス。「sources」の「subTaskStatus」の「stage」のステータスの説明とステータスの切り替え関係については、 [サブタスクのステータス](#subtask-status)参照してください。 - `unit` : 「チェック」、「ダンプ」、「ロード」、「同期」を含む DM の処理単位。 - `result` : サブタスクが失敗した場合にエラー情報を表示します。 - - `unresolvedDDLLockID` : シャーディングDDLロックID。異常状態におけるシャーディングDDLロックを手動で処理するために使用されます。「sources」の「subTaskStatus」の「unresolvedDDLLockID」の動作の詳細については、 [シャーディング DDL ロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)参照してください。 + - `unresolvedDDLLockID` : シャーディングDDLロックID。異常状態におけるシャーディングDDLロックを手動で処理するために使用されます。「sources」の「subTaskStatus」の「unresolvedDDLLockID」の動作の詳細については、 [シャーディング DDL ロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を参照してください。 - `sync` ： `Sync`処理ユニットの複製情報。この情報は、現在の処理ユニットと同じコンポーネントに関するものです。 - `masterBinlog` : アップストリーム データベース内のbinlog の位置。 - `masterBinlogGtid` : アップストリーム データベース内の GTID 情報。 diff --git a/dm/dm-safe-mode.md b/dm/dm-safe-mode.md index a75205d8e459d..446f844563c2f 100644 --- a/dm/dm-safe-mode.md +++ b/dm/dm-safe-mode.md @@ -26,7 +26,7 @@ summary: DMセーフモードについて、その目的、動作原理、およ バージョン8.5.6以降、タスクセッションで`foreign_key_checks=1`を設定すると、DMは主キーまたは一意インデックス値を変更しない`DELETE` `UPDATE`ステップをスキップします。詳細については、[外部キーの処理](#foreign-key-handling-new-in-v856)キー を参照してください。 -`REPLACE`は、MySQL でデータを挿入するための固有の構文です。 `REPLACE`を使用してデータを挿入し、新しいデータと既存のデータに主キーまたは一意制約の競合がある場合、MySQL は競合するすべてのレコードを削除し、挿入操作を実行します。これは「強制挿入」と同等です。詳細については、MySQL ドキュメントの[`REPLACE`文](https://dev.mysql.com/doc/refman/8.0/en/replace.html)参照してください。 +`REPLACE`は、MySQL でデータを挿入するための固有の構文です。 `REPLACE`を使用してデータを挿入し、新しいデータと既存のデータに主キーまたは一意制約の競合がある場合、MySQL は競合するすべてのレコードを削除し、挿入操作を実行します。これは「強制挿入」と同等です。詳細については、MySQL ドキュメントの[`REPLACE`文](https://dev.mysql.com/doc/refman/8.0/en/replace.html)を参照してください。 `dummydb.dummytbl`テーブルに主キー`id`があると仮定します。このテーブルに対して、次の SQL ステートメントを繰り返し実行します。 diff --git a/dm/dm-shard-merge.md b/dm/dm-shard-merge.md index f23c0cb3c088f..46318ae408260 100644 --- a/dm/dm-shard-merge.md +++ b/dm/dm-shard-merge.md @@ -27,4 +27,4 @@ shard-mode: "pessimistic" ## シャーディングDDLロックを手動で処理する {#handle-sharding-ddl-locks-manually} -異常なシナリオでは、 [シャーディングDDLロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)実行する必要があります。 +異常なシナリオでは、 [シャーディングDDLロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を実行する必要があります。 diff --git a/dm/dm-source-configuration-file.md b/dm/dm-source-configuration-file.md index 52808ae9347f3..9c1a0b6421c9c 100644 --- a/dm/dm-source-configuration-file.md +++ b/dm/dm-source-configuration-file.md @@ -77,7 +77,7 @@ from: #### `enable-relay` {#enable-relay} -- リレーログ機能を有効にするかどうかを指定します。このパラメータはバージョン5.4以降で有効になります。また、コマンド`start-relay`を使用して[リレーログを動的に有効にする](/dm/relay-log.md#enable-and-disable-relay-log)実行することもできます。 +- リレーログ機能を有効にするかどうかを指定します。このパラメータはバージョン5.4以降で有効になります。また、コマンド`start-relay`を使用して[リレーログを動的に有効にする](/dm/relay-log.md#enable-and-disable-relay-log)を実行することもできます。 - デフォルト値: `false` #### `relay-binlog-name` {#relay-binlog-name} @@ -169,4 +169,4 @@ DM v2.0.2 以降では、ソース構成ファイルでbinlogイベント フィ #### `filters` {#filters} -- binlogイベントのフィルタリングルールを指定します。詳細については[Binlogイベントフィルターパラメータの説明](/dm/dm-binlog-event-filter.md#parameter-descriptions)参照してください。 +- binlogイベントのフィルタリングルールを指定します。詳細については[Binlogイベントフィルターパラメータの説明](/dm/dm-binlog-event-filter.md#parameter-descriptions)を参照してください。 diff --git a/dm/dm-task-configuration-guide.md b/dm/dm-task-configuration-guide.md index 107acec680a80..92f5f5f557478 100644 --- a/dm/dm-task-configuration-guide.md +++ b/dm/dm-task-configuration-guide.md @@ -78,7 +78,7 @@ target-database: # Configuration of target TiDB database. tbl-name: "log" ``` - 詳細な設定ルールについては[ブロックと許可のテーブルリスト](/dm/dm-block-allow-table-lists.md)参照してください。 + 詳細な設定ルールについては[ブロックと許可のテーブルリスト](/dm/dm-block-allow-table-lists.md)を参照してください。 2. データ ソース構成のブロック リスト ルールと許可リスト ルールを参照して、移行するテーブルをフィルター処理します。 @@ -113,7 +113,7 @@ target-database: # Configuration of target TiDB database. action: Do ``` - 詳細な設定ルールについては[Binlogイベントフィルター](/dm/dm-binlog-event-filter.md)参照してください。 + 詳細な設定ルールについては[Binlogイベントフィルター](/dm/dm-binlog-event-filter.md)を参照してください。 2. データ ソース構成内のbinlogイベント フィルタリング ルールを参照して、データ ソース内の指定されたテーブルまたはスキーマの指定されたbinlogイベントをフィルタリングします。 @@ -151,7 +151,7 @@ target-database: # Configuration of target TiDB database. target-schema: "test" ``` - 詳細な設定ルールについては[テーブルルーティング](/dm/dm-table-routing.md)参照してください。 + 詳細な設定ルールについては[テーブルルーティング](/dm/dm-table-routing.md)を参照してください。 2. データ ソース構成内のルーティング マッピング ルールを参照して、移行するテーブルをフィルター処理します。 diff --git a/dm/dm-worker-intro.md b/dm/dm-worker-intro.md index aa1cd39041a94..78add1e56da23 100644 --- a/dm/dm-worker-intro.md +++ b/dm/dm-worker-intro.md @@ -22,7 +22,7 @@ DM ワーカー タスクには、リレー ログ、ダンプ処理ユニット リレー ログは、アップストリーム MySQL/MariaDB からのbinlogデータを永続的に保存し、binlogレプリケーションのbinlogイベントにアクセスする機能を提供します。 -その原理と機能はMySQLのリレーログに似ています。詳細については[MySQLリレーログ](https://dev.mysql.com/doc/refman/8.0/en/replica-logs-relaylog.html)参照してください。 +その原理と機能はMySQLのリレーログに似ています。詳細については[MySQLリレーログ](https://dev.mysql.com/doc/refman/8.0/en/replica-logs-relaylog.html)を参照してください。 ### ダンプ処理装置 {#dump-processing-unit} diff --git a/dm/feature-expression-filter.md b/dm/feature-expression-filter.md index 81067f7d2c4e0..b5b51d38615b9 100644 --- a/dm/feature-expression-filter.md +++ b/dm/feature-expression-filter.md @@ -11,4 +11,4 @@ summary: 増分データ移行では、SQL式を使用してbinlogイベント 上記の問題を解決するため、DMはv2.0.5以降、増分移行中に`binlog value filter`使用したデータのフィルタリングをサポートしています。DMがサポートする`ROW`形式のbinlogには、binlogイベントのすべての列の値が含まれます。これらの値に基づいてSQL式を設定できます。SQL式が行の変更を`TRUE`と評価した場合、DMは行の変更を下流に移行しません。 -詳しい操作と実装については[SQL 式を使用して DML イベントをフィルタリングする](/filter-dml-event.md)参照してください。 +詳しい操作と実装については[SQL 式を使用して DML イベントをフィルタリングする](/filter-dml-event.md)を参照してください。 diff --git a/dm/feature-online-ddl.md b/dm/feature-online-ddl.md index 72026224f846a..ba8dfc98d55ed 100644 --- a/dm/feature-online-ddl.md +++ b/dm/feature-online-ddl.md @@ -7,7 +7,7 @@ summary: このドキュメントでは、DM の online-ddl/online-ddl-scheme` 本番環境では、DDL実行中のテーブルロックによって、データベースからの読み取りまたは書き込みがある程度ブロックされる可能性があります。そのため、読み取りと書き込みへの影響を最小限に抑えるため、オンラインDDLツールを使用してDDLを実行することがよくあります。一般的な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を使用してMySQLからTiDBにデータを移行する場合、online-ddlを有効にすると、DMとgh-ostまたはpt-oscの連携が可能になります。online-ddlの有効化方法と、このオプション有効化後のワークフローの詳細については、 [gh-ost または pt-osc による継続的なレプリケーション](/migrate-with-pt-ghost.md)参照してください。このドキュメントでは、DMとオンラインDDLツールの連携の詳細に焦点を当てています。 +DMを使用してMySQLからTiDBにデータを移行する場合、online-ddlを有効にすると、DMとgh-ostまたはpt-oscの連携が可能になります。online-ddlの有効化方法と、このオプション有効化後のワークフローの詳細については、 [gh-ost または pt-osc による継続的なレプリケーション](/migrate-with-pt-ghost.md)を参照してください。このドキュメントでは、DMとオンラインDDLツールの連携の詳細に焦点を当てています。 ## オンライン DDL ツールを使用した DM の動作詳細 {#working-details-for-dm-with-online-ddl-tools} diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index cdc1324ab372e..a70f7abb6a706 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -21,7 +21,7 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル ## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} -楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。5 `strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)参照してください。 +楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。5 `strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 ## 制限 {#restrictions} diff --git a/dm/handle-failed-ddl-statements.md b/dm/handle-failed-ddl-statements.md index abafa293ad40f..a72ec5283dd99 100644 --- a/dm/handle-failed-ddl-statements.md +++ b/dm/handle-failed-ddl-statements.md @@ -33,7 +33,7 @@ dmctl を使用して失敗した DDL ステートメントを手動で処理す ### クエリステータス {#query-status} -`query-status`コマンドは、各 MySQL インスタンス内のサブタスクやリレーユニットなどの現在の状態を問い合わせるために使用されます。詳細については、 [クエリステータス](/dm/dm-query-status.md)参照してください。 +`query-status`コマンドは、各 MySQL インスタンス内のサブタスクやリレーユニットなどの現在の状態を問い合わせるために使用されます。詳細については、 [クエリステータス](/dm/dm-query-status.md)を参照してください。 ### binlog {#binlog} diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 5b3fe240d2216..8d0160dcfbf9e 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -245,7 +245,7 @@ tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 > - インポートする前に元のクラスターを停止する必要があります。 > - 2.0 にアップグレードする必要があるタスクでは`stop-task`実行しないでください。 > - TiUP は、v2.0.0-rc.2 以降のバージョンの DM クラスターへのインポートのみをサポートします。 -> - `import`コマンドは、DM 1.0 クラスターから新しい DM 2.0 クラスターにデータをインポートするために使用されます。既存の DM 2.0 クラスターに DM 移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)参照してください。 +> - `import`コマンドは、DM 1.0 クラスターから新しい DM 2.0 クラスターにデータをインポートするために使用されます。既存の DM 2.0 クラスターに DM 移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 > - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なります。詳細を確認するには、 `display`コマンドを実行してください。 > - インポートする前に`tiup update --self && tiup update dm`実行して、 TiUP DMコンポーネントが最新バージョンであることを確認します。 > - インポート後、クラスターにはDMマスターノードが1つだけ存在します。DMマスターをスケールアウトするには、 [クラスターをスケールアウトする](#scale-out-a-cluster)を参照してください。 diff --git a/dm/migrate-data-using-dm.md b/dm/migrate-data-using-dm.md index 29bfabffc7c08..0729fd9fa18b9 100644 --- a/dm/migrate-data-using-dm.md +++ b/dm/migrate-data-using-dm.md @@ -13,7 +13,7 @@ summary: データ移行ツールを使用して、全データと増分デー > **注記：** > -> - すべての DM 構成ファイルのデータベース パスワードには、 `dmctl`で暗号化されたパスワードを使用することをお勧めします。データベースのパスワードが空の場合、暗号化する必要はありません。 [dmctlを使用してデータベースのパスワードを暗号化します](/dm/dm-manage-source.md#encrypt-the-database-password)参照してください。 +> - すべての DM 構成ファイルのデータベース パスワードには、 `dmctl`で暗号化されたパスワードを使用することをお勧めします。データベースのパスワードが空の場合、暗号化する必要はありません。 [dmctlを使用してデータベースのパスワードを暗号化します](/dm/dm-manage-source.md#encrypt-the-database-password)を参照してください。 > - 上流および下流データベースのユーザーは、対応する読み取り権限と書き込み権限を持っている必要があります。 ## ステップ2：クラスタ情報を確認する {#step-2-check-the-cluster-information} @@ -121,7 +121,7 @@ mydumpers: - DMは、データ移行タスクを開始する際に、対応する権限と構成を自動的にチェックします。 - `check-task`コマンドを使用して、アップストリームの MySQL インスタンス構成が DM の要件を満たしているかどうかを手動で事前確認することもできます。 -事前チェック機能の詳細については、[アップストリームのMySQLインスタンス構成を事前に確認する](/dm/dm-precheck.md)参照してください。 +事前チェック機能の詳細については、[アップストリームのMySQLインスタンス構成を事前に確認する](/dm/dm-precheck.md)を参照してください。 > **注記：** > diff --git a/dm/quick-start-create-source.md b/dm/quick-start-create-source.md index b697de7298b97..764e1a4c3b22d 100644 --- a/dm/quick-start-create-source.md +++ b/dm/quick-start-create-source.md @@ -7,7 +7,7 @@ summary: データ移行 (DM) のデータ ソースを作成する方法を学 > **注記：** > -> データ ソースを作成する前に、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)実行する必要があります。 +> データ ソースを作成する前に、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を実行する必要があります。 このドキュメントでは、TiDB Data Migration (DM) のデータ移行タスク用のデータ ソースを作成する方法について説明します。 diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 7512c09d2b78a..bdb8852410a75 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -209,4 +209,4 @@ MySQL2 の場合、上記のコマンドの設定ファイルを MySQL2 の設 ## データを検証する {#verify-data} -アップストリームのMySQLシャードテーブルのデータを変更できます。その後、 [同期差分インスペクター](/sync-diff-inspector/shard-diff.md)使用して、アップストリームとダウンストリームのデータの整合性を確認します。データの整合性は、移行タスクが正常に機能していることを意味し、クラスタが正常に動作していることも示しています。 +アップストリームのMySQLシャードテーブルのデータを変更できます。その後、 [同期差分インスペクター](/sync-diff-inspector/shard-diff.md)を使用して、アップストリームとダウンストリームのデータの整合性を確認します。データの整合性は、移行タスクが正常に機能していることを意味し、クラスタが正常に動作していることも示しています。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 21860767f77ab..a880bd3110265 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -5,11 +5,11 @@ summary: TiUP Playground を使用してデータ移行環境をすばやくセ # TiDB Data Migrationのクイックスタート {#quick-start-with-tidb-data-migration} -[TiDB Data Migration (DM)](/dm/dm-overview.md) 、MySQL互換データベースからTiDBにデータを複製する強力なツールです。このガイドでは、 [TiUP Playground](/tiup/tiup-playground.md)使用して開発またはテスト用のローカルTiDB DM環境を迅速に構築する方法と、ソースMySQLデータベースからターゲットTiDBデータベースへのデータ移行という簡単なタスクを段階的に説明します。 +[TiDB Data Migration (DM)](/dm/dm-overview.md) 、MySQL互換データベースからTiDBにデータを複製する強力なツールです。このガイドでは、 [TiUP Playground](/tiup/tiup-playground.md)を使用して開発またはテスト用のローカルTiDB DM環境を迅速に構築する方法と、ソースMySQLデータベースからターゲットTiDBデータベースへのデータ移行という簡単なタスクを段階的に説明します。 > **注記：** > -> 本番への展開については、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)参照してください。 +> 本番への展開については、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 ## ステップ1: テスト環境をセットアップする {#step-1-set-up-the-test-environment} @@ -114,7 +114,7 @@ Docker を使用すると、テスト用の MySQL 8.0 インスタンスをす
-macOS では、 [Homebrew](https://brew.sh)使用して MySQL 8.0 をローカルにすばやくインストールして起動できます。 +macOS では、 [Homebrew](https://brew.sh)を使用して MySQL 8.0 をローカルにすばやくインストールして起動できます。 1. Homebrewを更新し、MySQL 8.0 をインストールします。 diff --git a/dm/relay-log.md b/dm/relay-log.md index 8046effb439ed..697ea113db9eb 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -37,7 +37,7 @@ MySQLではストレージ容量が限られているため、最大保存期間 v5.4.0以降のバージョンでは、 `enable-relay`を`true`に設定することでリレーログを有効にできます。v5.4.0以降では、上流データソースをバインドする際に、DM-workerはデータソースの設定で`enable-relay`をチェックします。 `enable-relay`が`true`場合、このデータソースに対してリレーログ機能が有効になります。 -詳しい設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 +詳しい設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 さらに、 `start-relay`または`stop-relay`コマンドを使用してデータ ソースの`enable-relay`構成を動的に調整し、リレー ログイン時間を有効または無効にすることもできます。 @@ -90,7 +90,7 @@ stop-relay -s mysql-replica-01 worker1 worker2 DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`チェックされます。3 `enable-relay` `true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 -設定項目`enable-relay`設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 +設定項目`enable-relay`設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。
diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index a880affb0e779..cb60c973b58d7 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -11,7 +11,7 @@ summary: シャードマージのシナリオにおけるデータ移行のベ [シャードテーブルからのデータのマージと移行](/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)実行するか、データ移行タスク全体をやり直す必要があります。 +現在のシャーディングDDLメカニズムには、異なるシャーディングされたテーブルにおけるDDL操作によってもたらされるスキーマ変更を調整するための[使用制限](/dm/feature-shard-merge-pessimistic.md#restrictions)の制約があります。予期しない理由によりこれらの制約に違反した場合は、 [DMでシャーディングDDLロックを手動で処理する](/dm/manually-handling-sharding-ddl-locks.md)を実行するか、データ移行タスク全体をやり直す必要があります。 例外発生時のデータ移行への影響を軽減するため、各シャーディンググループを個別のデータ移行タスクとして統合・移行することをお勧めします。**これにより、少数のデータ移行タスクのみを手動で処理し、他のタスクへの影響を最小限に抑えることができます。** @@ -145,7 +145,7 @@ CREATE TABLE `tbl_multi_pk` ( アップストリームでシャードされたテーブルを削除する必要がある場合は、次の手順を実行します。 -1. シャード化されたテーブルを削除し、 [`SHOW BINLOG EVENTS`](https://dev.mysql.com/doc/refman/8.0/en/show-binlog-events.html)実行して、 binlogイベント内の`DROP TABLE`ステートメントに対応する`End_log_pos`を取得し、それを*Pos-M*としてマークします。 +1. シャード化されたテーブルを削除し、 [`SHOW BINLOG EVENTS`](https://dev.mysql.com/doc/refman/8.0/en/show-binlog-events.html)を実行して、 binlogイベント内の`DROP TABLE`ステートメントに対応する`End_log_pos`を取得し、それを*Pos-M*としてマークします。 2. `query-status`実行して、DMによって処理されたbinlogイベントに対応する位置（ `syncerBinlog` ）を取得し、それを*Pos-S*としてマークします。 diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index 0a57d5af39fa1..198c0f9ba4231 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -9,7 +9,7 @@ summary: このドキュメントでは、データ移行（DM）の高度なタ ## 重要な概念 {#important-concepts} -`source-id`や DM ワーカー ID などの重要な概念の説明については、 [重要な概念](/dm/dm-config-overview.md#important-concepts)参照してください。 +`source-id`や DM ワーカー ID などの重要な概念の説明については、 [重要な概念](/dm/dm-config-overview.md#important-concepts)を参照してください。 ## タスク設定ファイルテンプレート（上級者向け） {#task-configuration-file-template-advanced} @@ -264,11 +264,11 @@ mysql-instances: #### `routes` {#routes} -- アップストリームテーブルとダウンストリームテーブル間のルーティングマッピングルールセット。アップストリームとダウンストリームのスキーマ名およびテーブル名が同じ場合は、この項目を設定する必要はありません。使用シナリオと設定例については[テーブルルーティング](/dm/dm-table-routing.md)参照してください。 +- アップストリームテーブルとダウンストリームテーブル間のルーティングマッピングルールセット。アップストリームとダウンストリームのスキーマ名およびテーブル名が同じ場合は、この項目を設定する必要はありません。使用シナリオと設定例については[テーブルルーティング](/dm/dm-table-routing.md)を参照してください。 #### `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} diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 44d182539271f..e83b00f8d900d 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -61,11 +61,11 @@ summary: TiCDCに基づいたプライマリ・セカンダリディザスタリ - [TiDB向けのソフトウェアおよびハードウェアに関する推奨事項](/hardware-and-software-requirements.md) - [TiCDC向けのソフトウェアおよびハードウェアに関する推奨事項](/ticdc/deploy-ticdc.md#software-and-hardware-recommendations) -TiDBプライマリクラスタとセカンダリクラスタのデプロイ方法の詳細については、 [TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +TiDBプライマリクラスタとセカンダリクラスタのデプロイ方法の詳細については、 [TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 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 @@ -226,7 +226,7 @@ nohup ./minio server ./data --address :6060 & tiup cdc cli changefeed create --server=http://10.1.1.9:8300 --sink-uri="mysql://{username}:{password}@10.1.1.4:4000" --changefeed-id="dr-primary-to-secondary" --start-ts="431434047157698561" --config changefeed.toml ``` - 変更フィードの設定の詳細については、 [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md)参照してください。 + 変更フィードの設定の詳細については、 [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md)を参照してください。 2. 変更フィードタスクが正しく実行されているかどうかを確認するには、コマンド`changefeed query`を実行します。クエリ結果には、タスク情報とタスクの状態が含まれます。引数`--simple`または`-s`を指定すると、基本的なレプリケーション状態とチェックポイント情報のみが表示されます。この引数を指定しない場合、出力には詳細なタスク構成、レプリケーション状態、およびレプリケーションテーブル情報が含まれます。 @@ -408,8 +408,8 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht 双方向レプリケーション機能により、2つのリージョンにあるTiDBクラスタ間でデータのレプリケーションが可能になります。このDRソリューションは、データのセキュリティと信頼性を保証するとともに、データベースの書き込みパフォーマンスも確保します。計画的なDR切り替えでは、新しいチェンジフィードを開始する前に実行中のチェンジフィードを停止する必要がないため、運用とメンテナンスが簡素化されます。 -双方向DRクラスタを構築するには、 [TiCDCの双方向複製](/ticdc/ticdc-bidirectional-replication.md)参照してください。 +双方向DRクラスタを構築するには、 [TiCDCの双方向複製](/ticdc/ticdc-bidirectional-replication.md)を参照してください。 ## トラブルシューティング {#troubleshooting} -前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告する](/support.md)実行してください。 +前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告する](/support.md)を実行してください。 diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index ddf089b95b4f4..d50c5a1795e91 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -65,7 +65,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、「1対1」の災害復旧ソリューションとも呼ばれます。 -このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、第 2 レベルの RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)参照してください。 +このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、第 2 レベルの RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)を参照してください。 ### 単一クラスター内の複数のレプリカに基づく災害復旧ソリューション {#dr-solution-based-on-multiple-replicas-in-a-single-cluster} diff --git a/dumpling-overview.md b/dumpling-overview.md index 153f8d378711e..0a41fd121d8cd 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)を参照してください。 @@ -39,7 +39,7 @@ TiDBは、必要に応じて選択して使用できるその他のツールも - SST ファイル (キーと値のペア) のバックアップ、またはレイテンシーに影響されない増分データのバックアップについては、 [BR](/br/backup-and-restore-overview.md)を参照してください。 - 増分データのリアルタイムバックアップについては、 [TiCDC](/ticdc/ticdc-overview.md)を参照してください。 -- エクスポートされたすべてのデータは[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)使用してTiDBにインポートし直すことができます。 +- エクスポートされたすべてのデータは[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用してTiDBにインポートし直すことができます。 @@ -217,7 +217,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'se バージョン4.0.8以降、 Dumplingはクラウドストレージへのデータエクスポートをサポートしています。Amazon S3にデータをバックアップする必要がある場合は、 `-o`パラメータでAmazon S3ストレージパスを指定する必要があります。 -指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 +指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)を参照してください。 Amazon S3バックエンドストレージへのアクセス権限を持つアカウントの`SecretKey`と`AccessKey`を環境変数としてDumplingノードに渡します。 @@ -246,7 +246,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --where "id < 100" #### --filterオプションを使用してデータをフィルタリングします。 {#use-the-code-filter-code-option-to-filter-data} -Dumpling`--filter`オプションでテーブルフィルタを指定することで、特定のデータベースまたはテーブルをフィルタリングできます。テーブルフィルタの構文は`.gitignore`と同様です。詳細は、[テーブルフィルター](/table-filter.md)参照してください。 +Dumpling`--filter`オプションでテーブルフィルタを指定することで、特定のデータベースまたはテーブルをフィルタリングできます。テーブルフィルタの構文は`.gitignore`と同様です。詳細は、[テーブルフィルター](/table-filter.md)を参照してください。 ```shell tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test -r 200000 --filter "employees.*" --filter "*.WorkOrder" diff --git a/dynamic-config.md b/dynamic-config.md index d0fd7c54a36ee..6ffb91f897c8b 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -333,7 +333,7 @@ Query OK, 0 rows affected (0.01 sec) ### TiDB構成を動的に変更する {#modify-tidb-configuration-dynamically} -現在、TiDB構成の変更方法は、TiKVおよびPD構成の変更方法とは異なります。1 [システム変数](/system-variables.md)使用してTiDB構成を変更できます。 +現在、TiDB構成の変更方法は、TiKVおよびPD構成の変更方法とは異なります。1 [システム変数](/system-variables.md)を使用してTiDB構成を変更できます。 次の例は、 `tidb_slow_log_threshold`変数を使用して`slow-threshold`動的に変更する方法を示しています。 @@ -376,7 +376,7 @@ select @@tidb_slow_log_threshold; ### TiFlash構成を動的に変更する {#modify-tiflash-configuration-dynamically} -現在、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)使用してTiFlash構成`max_threads`を変更できます。この変数は、 TiFlashが要求を実行するための最大同時実行性を指​​定します。 +現在、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610)を使用してTiFlash構成`max_threads`を変更できます。この変数は、 TiFlashが要求を実行するための最大同時実行性を指​​定します。 デフォルト値は`tidb_max_tiflash_threads` `-1` 、このシステム変数は無効であり、 TiFlash設定ファイルの設定に依存することを示します。 `tidb_max_tiflash_threads`使用すると、 `max_threads`から 10 に設定できます。 diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md index 6e6196514b13a..e5d99be846b88 100644 --- a/ecosystem-tool-user-case.md +++ b/ecosystem-tool-user-case.md @@ -17,27 +17,27 @@ Kubernetes上でTiDBをデプロイ・運用する必要がある場合は、Kub ## CSVからTiDBへのデータのインポート {#import-data-from-csv-to-tidb} -他のツールによってエクスポートされた互換性のある CSV ファイルを TiDB にインポートする必要がある場合は、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)使用します。 +他のツールによってエクスポートされた互換性のある CSV ファイルを TiDB にインポートする必要がある場合は、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用します。 ## 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} MySQL/ Auroraから全データと増分データの両方を移行する必要がある場合は、 [TiDB Data Migration](/dm/dm-overview.md) (DM) を使用して[Amazon Auroraから TiDB へのデータ移行](/migrate-aurora-to-tidb.md)を実行します。 -全データ量が大きい場合 (TB レベル)、最初に[Dumpling](/dumpling-overview.md)と[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)使用して全データ移行を実行し、次に DM を使用して増分データ移行を実行できます。 +全データ量が大きい場合 (TB レベル)、最初に[Dumpling](/dumpling-overview.md)と[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用して全データ移行を実行し、次に DM を使用して増分データ移行を実行できます。 ## TiDB クラスタのバックアップと復元 {#back-up-and-restore-tidb-cluster} TiDB クラスターをバックアップする必要がある場合、またはバックアップしたデータをクラスターに復元する必要がある場合は、 [BR](/br/backup-and-restore-overview.md) (バックアップと復元) を使用します。 -また、 BR はTiDB クラスターデータの[増分バックアップ](/br/br-incremental-guide.md#back-up-incremental-data)と[増分復元](/br/br-incremental-guide.md#restore-incremental-data)実行するためにも使用できます。 +また、 BR はTiDB クラスターデータの[増分バックアップ](/br/br-incremental-guide.md#back-up-incremental-data)と[増分復元](/br/br-incremental-guide.md#restore-incremental-data)を実行するためにも使用できます。 ## 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 0f86e8e642c23..61b716db52b0e 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -47,14 +47,14 @@ DM の基本は次のとおりです。 - 出典: MySQL/MariaDB - ターゲット: TiDB クラスター - サポートされている TiDB バージョン: すべてのバージョン -- Kubernetes サポート: Kubernetes に TiDB DM をデプロイするには[TiDB Operator](https://github.com/pingcap/tidb-operator)使用します。 +- Kubernetes サポート: Kubernetes に TiDB DM をデプロイするには[TiDB Operator](https://github.com/pingcap/tidb-operator)を使用します。 データ量が1TB未満の場合は、DMを使用してMySQL/MariaDBからTiDBに直接データを移行することをお勧めします。移行プロセスには、完全なデータ移行と増分データレプリケーションが含まれます。 データ量が 1 TB を超える場合は、次の手順を実行します。 -1. MySQL/MariaDB から完全なデータをエクスポートするには、 [Dumpling](/dumpling-overview.md)使用します。 -2. [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)使用して、手順 1 でエクスポートしたデータを TiDB クラスターにインポートします。 +1. MySQL/MariaDB から完全なデータをエクスポートするには、 [Dumpling](/dumpling-overview.md)を使用します。 +2. [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用して、手順 1 でエクスポートしたデータを TiDB クラスターにインポートします。 3. TiDB DM を使用して、MySQL/MariaDB から TiDB に増分データを複製します。 > **注記：** @@ -92,7 +92,7 @@ TiDB Lightningの基本は次のとおりです。 - その他の互換性のあるCSVファイル - Amazon Aurora、Apache Hive、またはSnowflakeからエクスポートされたParquetファイル - サポートされている TiDB バージョン: v2.1 以降 -- Kubernetes サポート: はい。詳細は[TiDB Lightningを使用して Kubernetes 上の TiDB クラスターにデータを迅速に復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-data-using-tidb-lightning)参照してください。 +- Kubernetes サポート: はい。詳細は[TiDB Lightningを使用して Kubernetes 上の TiDB クラスターにデータを迅速に復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-data-using-tidb-lightning)を参照してください。 > **注記：** > diff --git a/enable-tls-between-clients-and-servers.md b/enable-tls-between-clients-and-servers.md index 080edb18bd4fe..3a3568684cbc0 100644 --- a/enable-tls-between-clients-and-servers.md +++ b/enable-tls-between-clients-and-servers.md @@ -50,7 +50,7 @@ TiDBサーバーで独自の証明書を使用して安全な接続を有効に ## TiProxyがTLS接続を使用するように設定する {#configure-tiproxy-to-use-tls-connections} -[TiProxy](/tiproxy/tiproxy-overview.md)でTLS接続を有効にするには、TiProxy設定ファイルで[`sql-tls`](/tiproxy/tiproxy-configuration.md#sql-tls)設定項目を指定します。この設定の詳細とバックエンド接続でTLSを有効にする方法については、 [TiProxyのセキュリティ](/tiproxy/tiproxy-overview.md#security)参照してください。 +[TiProxy](/tiproxy/tiproxy-overview.md)でTLS接続を有効にするには、TiProxy設定ファイルで[`sql-tls`](/tiproxy/tiproxy-configuration.md#sql-tls)設定項目を指定します。この設定の詳細とバックエンド接続でTLSを有効にする方法については、 [TiProxyのセキュリティ](/tiproxy/tiproxy-overview.md#security)を参照してください。 ## MySQLクライアントをTLS接続を使用するように設定する {#configure-the-mysql-client-to-use-tls-connections} @@ -69,7 +69,7 @@ MySQL 8.xクライアントには、このパラメータに加えて2つのSSL MySQL 5.7および MariaDB クライアント以前のバージョンでは、 `--ssl-verify-server-cert`を使用してサーバー証明書の検証を有効にできます。 -詳細については、「MySQL の[暗号化接続のためのクライアント側コンフィグレーション](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)参照してください。 +詳細については、「MySQL の[暗号化接続のためのクライアント側コンフィグレーション](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)を参照してください。 ## 認証を有効にする {#enable-authentication} @@ -98,7 +98,7 @@ CREATE USER 'u1'@'%' REQUIRE X509; > **注記：** > -> ログイン ユーザーが[TiDBの証明書ベース認証によるログイン](/certificate-authentication.md#configure-the-user-certificate-information-for-login-verification)使用して設定した場合、ユーザーは TiDB への TLS 接続を有効にすることが暗黙的に要求されます。 +> ログイン ユーザーが[TiDBの証明書ベース認証によるログイン](/certificate-authentication.md#configure-the-user-certificate-information-for-login-verification)を使用して設定した場合、ユーザーは TiDB への TLS 接続を有効にすることが暗黙的に要求されます。 ## 現在の接続が暗号化を使用しているかどうかを確認してください。 {#check-whether-the-current-connection-uses-encryption} diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 542c1180e5819..8be1eff68f560 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -152,7 +152,7 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を > **注記：** > > - v8.4.0以降、PD構成項目`cert-allowed-cn`複数の値をサポートします。必要に応じて、TiDB用構成項目`cluster-verify-cn`とその他のコンポーネント用構成項目`cert-allowed-cn`に、複数の`Common Name`設定できます。TiUPはコンポーネントのステータスを照会する際に別の識別子を使用することに注意してください。例えば、クラスター名が`test`の場合、 TiUPは`Common Name`として`test-client`使用します。 -> - v8.3.0以前のバージョンでは、PD設定項目`cert-allowed-cn`には単一の値しか設定できません。そのため、すべての認証オブジェクトの`Common Name`同じ値に設定する必要があります。関連する設定例については、 [v8.3.0 ドキュメント](https://docs-archive.pingcap.com/tidb/v8.3/enable-tls-between-components/)参照してください。 +> - v8.3.0以前のバージョンでは、PD設定項目`cert-allowed-cn`には単一の値しか設定できません。そのため、すべての認証オブジェクトの`Common Name`同じ値に設定する必要があります。関連する設定例については、 [v8.3.0 ドキュメント](https://docs-archive.pingcap.com/tidb/v8.3/enable-tls-between-components/)を参照してください。 - TiDB @@ -241,7 +241,7 @@ TiDBコンポーネント間の通信にTLSを設定したら、以下のコマ ## 証明書の有効期限 {#certificate-validity} -TiDBクラスタ内の各コンポーネントのTLS証明書の有効期間をカスタマイズできます。例えば、OpenSSLを使用してTLS証明書を発行・生成する場合、 **days**パラメータを使用して有効期間を設定できます。詳細については、 [自己署名証明書を生成する](/generate-self-signed-certificates.md)参照してください。 +TiDBクラスタ内の各コンポーネントのTLS証明書の有効期間をカスタマイズできます。例えば、OpenSSLを使用してTLS証明書を発行・生成する場合、 **days**パラメータを使用して有効期間を設定できます。詳細については、 [自己署名証明書を生成する](/generate-self-signed-certificates.md)を参照してください。 ## 参照 {#see-also} diff --git a/encryption-at-rest.md b/encryption-at-rest.md index fd72cf4f465b4..d2a2f8bc35ea8 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -7,7 +7,7 @@ summary: 機密データを保護するために保存時の暗号化を有効 > **注記：** > -> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。1 [AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 +> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。1 [AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)を参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 保存時の暗号化とは、データが保存時に暗号化されることを意味します。データベースの場合、この機能はTDE（透過的データ暗号化）とも呼ばれます。これは、転送中の暗号化（TLS）や使用中の暗号化（ほとんど使用されません）とは対照的です。保存時の暗号化はSSDドライブ、ファイルシステム、クラウドベンダーなど、さまざまな方法で実行できますが、TiKVが保存前に暗号化を行うことで、攻撃者がデータにアクセスするにはデータベースへの認証が必要となることを確実にします。例えば、攻撃者が物理マシンにアクセスできたとしても、ディスク上のファイルをコピーするだけではデータにアクセスできません。 @@ -123,7 +123,7 @@ AWS KMS を使用してマスターキーを指定するには、TiKV 設定フ region = "us-west-2" endpoint = "https://kms.us-west-2.amazonaws.com" -`key-id` KMS CMK のキー ID を指定します。3 `region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)使用する必要がある場合を除き、通常は指定する必要はありません。 +`key-id` KMS CMK のキー ID を指定します。3 `region` KMS CMK の AWS リージョン名です。5 はオプションであり、AWS 以外のベンダーの AWS KMS 互換サービスを使用している場合や、 `endpoint` [KMS の VPC エンドポイント](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html)を使用する必要がある場合を除き、通常は指定する必要はありません。 AWSでも[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)使用できます。この場合、特定のリージョンに主キーを設定し、必要なリージョンにレプリカキーを追加する必要があります。 diff --git a/error-codes.md b/error-codes.md index 0c2a66dcdf2a4..5499d53609bd0 100644 --- a/error-codes.md +++ b/error-codes.md @@ -9,7 +9,7 @@ summary: TiDB のエラー コードと解決策について学習します。 ## エラーコード {#error-codes} -TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合、MySQLと同じエラーコードを返します。MySQLのエラーコードの一覧については、 [MySQL 8.0 エラーメッセージリファレンス](https://dev.mysql.com/doc/mysql-errors/8.0/en/)参照してください。さらに、TiDBには以下の独自のエラーコードがあります。 +TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合、MySQLと同じエラーコードを返します。MySQLのエラーコードの一覧については、 [MySQL 8.0 エラーメッセージリファレンス](https://dev.mysql.com/doc/mysql-errors/8.0/en/)を参照してください。さらに、TiDBには以下の独自のエラーコードがあります。 > **注記：** > @@ -39,7 +39,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 1回のトランザクションが大きすぎます。 - 原因と解決策については[エラーメッセージ`transaction too large`](/faq/migration-tidb-faq.md#the-error-message-transaction-too-large-is-displayed)参照してください。 + 原因と解決策については[エラーメッセージ`transaction too large`](/faq/migration-tidb-faq.md#the-error-message-transaction-too-large-is-displayed)を参照してください。 - エラー番号: 8005 @@ -147,7 +147,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 サポートされていないデータベース分離レベルが設定されています。 - サードパーティのツールまたはフレームワークを使用しているためにコードを変更できない場合は、 [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check)使用してこのチェックをバイパスすることを検討してください。 + サードパーティのツールまたはフレームワークを使用しているためにコードを変更できない場合は、 [`tidb_skip_isolation_level_check`](/system-variables.md#tidb_skip_isolation_level_check)を使用してこのチェックをバイパスすることを検討してください。 ```sql set @@tidb_skip_isolation_level_check = 1; @@ -157,31 +157,31 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 サポートされていない権限タイプが設定されています。 - 解決策については[TiDB操作に必要な権限](/privilege-management.md#privileges-required-for-tidb-operations)参照してください。 + 解決策については[TiDB操作に必要な権限](/privilege-management.md#privileges-required-for-tidb-operations)を参照してください。 - エラー番号: 8051 TiDB がクライアントから送信された Exec 引数リストを解析するときに、不明なデータ型が検出されました。 - このエラーが発生した場合は、クライアントを確認してください。クライアントが正常な場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 + このエラーが発生した場合は、クライアントを確認してください。クライアントが正常な場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)を取得してください。 - エラー番号: 8052 クライアントからのデータ パケットのシリアル番号が正しくありません。 - このエラーが発生した場合は、クライアントを確認してください。クライアントが正常な場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 + このエラーが発生した場合は、クライアントを確認してください。クライアントが正常な場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)を取得してください。 - エラー番号: 8055 現在のスナップショットは古すぎます。データがガベージコレクションされている可能性があります。この問題を回避するには、値を[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)に増やしてください。TiDBは長時間実行されるトランザクションのためにデータを自動的に予約します。通常、このエラーは発生しません。 - [ガベージコレクションの概要](/garbage-collection-overview.md)と[ガベージコレクションの構成](/garbage-collection-configuration.md)参照してください。 + [ガベージコレクションの概要](/garbage-collection-overview.md)と[ガベージコレクションの構成](/garbage-collection-configuration.md)を参照してください。 - エラー番号: 8059 AUTO_RANDOM IDが不足しているため、割り当てることができません。現在、このようなエラーから回復する方法はありません。AUTO_RANDOM機能を使用する場合は、割り当て数を最大限にするためにbigintを使用することをお勧めします。また、AUTO_RANDOM列に手動で値を割り当てることは避けてください。 - 参考として[AUTO_RANDOM](/auto-random.md)参照してください。 + 参考として[AUTO_RANDOM](/auto-random.md)を参照してください。 - エラー番号: 8060 @@ -191,31 +191,31 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 サポートされていない SQL ヒント。 - SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 + SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 - エラー番号: 8062 SQLヒントで無効なトークンが使用されています。SQLヒント内の予約語と競合しています。 - SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 + SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 - エラー番号: 8063 SQLヒントで設定されたメモリ使用量の制限がシステムの上限を超えています。SQLヒントの設定は無視されます。 - SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 + SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 - エラー番号: 8064 SQLヒントの解析に失敗しました。 - SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 + SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 - エラー番号: 8065 SQL ヒントに無効な整数が使用されています。 - SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 + SQL ヒントを確認して変更するには、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 - エラー番号: 8066 @@ -329,27 +329,27 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 このエラーは、TiDB の以前のバージョンからアップグレードした後に発生する可能性があります。SQL インジェクション攻撃の影響を軽減するため、TiDB ではデフォルトで、 `COM_QUERY`の呼び出しで複数のクエリが実行されないようにするようになりました。 - システム変数[`tidb_multi_statement_mode`](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)使用してこの動作を制御できます。 + システム変数[`tidb_multi_statement_mode`](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)を使用してこの動作を制御できます。 - エラー番号: 8138 - トランザクションは不正な行値を書き込もうとしました。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8138)参照してください。 + トランザクションは不正な行値を書き込もうとしました。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8138)を参照してください。 - エラー番号: 8139 - トランザクションは、インデックス内のハンドルと一致しない行の書き込みを試行しました。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8139)参照してください。 + トランザクションは、インデックス内のハンドルと一致しない行の書き込みを試行しました。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8139)を参照してください。 - エラー番号: 8140 - トランザクションは、インデックスデータと矛盾するデータを持つ行を書き込もうとしました。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8140)参照してください。 + トランザクションは、インデックスデータと矛盾するデータを持つ行を書き込もうとしました。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8140)を参照してください。 - エラー番号: 8141 - トランザクションのコミット時に、キーの存在アサーションが失敗します。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8141)参照してください。 + トランザクションのコミット時に、キーの存在アサーションが失敗します。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md#error-8141)を参照してください。 - エラー番号: 8143 - 非トランザクションDML文の実行中にバッチが失敗すると、文は停止されます。詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)参照してください。 + 非トランザクションDML文の実行中にバッチが失敗すると、文は停止されます。詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)を参照してください。 - エラー番号: 8147 @@ -357,7 +357,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8154 - 現在、 `LOAD DATA` TiDBサーバーからのローカルデータのインポートをサポートしていません。3 `LOCAL`指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。5 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 + 現在、 `LOAD DATA` TiDBサーバーからのローカルデータのインポートをサポートしていません。3 `LOCAL`指定してクライアントからインポートするか、S3 または GCS にデータをアップロードしてからインポートすることができます。5 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)を参照してください。 - エラー番号: 8156 @@ -365,11 +365,11 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8157 - 指定されたファイル形式はサポートされていません。サポートされている形式については、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#format)参照してください。 + 指定されたファイル形式はサポートされていません。サポートされている形式については、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#format)を参照してください。 - エラー番号: 8158 - 指定されたパスは無効です。具体的な対処方法については、エラーメッセージを参照してください。Amazon S3 または GCS のパス設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 + 指定されたパスは無効です。具体的な対処方法については、エラーメッセージを参照してください。Amazon S3 または GCS のパス設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 - エラー番号: 8159 @@ -385,11 +385,11 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8163 - 指定されたオプションは不明です。サポートされているオプションについては、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#parameter-description)参照してください。 + 指定されたオプションは不明です。サポートされているオプションについては、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#parameter-description)を参照してください。 - エラー番号: 8164 - 指定されたオプション値が無効です。有効な値については、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#parameter-description)参照してください。 + 指定されたオプション値が無効です。有効な値については、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#parameter-description)を参照してください。 - エラー番号: 8165 @@ -397,7 +397,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8166 - 一部のオプションは特定の状況でのみ使用できます。対処方法については、該当するエラーメッセージを参照してください。サポートされているオプションについては、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#parameter-description)参照してください。 + 一部のオプションは特定の状況でのみ使用できます。対処方法については、該当するエラーメッセージを参照してください。サポートされているオプションについては、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md#parameter-description)を参照してください。 - エラー番号: 8170 @@ -415,7 +415,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 DDL 構文はまだサポートされていません。 - 参考として[MySQL DDLの互換性](/mysql-compatibility.md#ddl-operations)参照してください。 + 参考として[MySQL DDLの互換性](/mysql-compatibility.md#ddl-operations)を参照してください。 - エラー番号: 8214 @@ -431,7 +431,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 `AUTO_RANDOM`列の使い方が間違っています。 - 変更するには[`AUTO_RANDOM`](/auto-random.md)参照してください。 + 変更するには[`AUTO_RANDOM`](/auto-random.md)を参照してください。 - エラー番号: 8223 @@ -457,13 +457,13 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 シーケンスの作成時にサポートされていないオプションが使用されています。 - サポートされているオプションのリストについては、 [シーケンスドキュメント](/sql-statements/sql-statement-create-sequence.md#parameters)参照してください。 + サポートされているオプションのリストについては、 [シーケンスドキュメント](/sql-statements/sql-statement-create-sequence.md#parameters)を参照してください。 - エラー番号: 8228 シーケンスに`SETVAL`使用すると、サポートされていない型が指定されます。 - 関数の例については[シーケンスドキュメント](/sql-statements/sql-statement-create-sequence.md#examples)参照してください。 + 関数の例については[シーケンスドキュメント](/sql-statements/sql-statement-create-sequence.md#examples)を参照してください。 - エラー番号: 8229 @@ -481,7 +481,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8249 - リソースグループが存在しません。このエラーは、存在しないリソースグループを変更またはバインドした場合に返されます。1 [リソースグループを作成する](/tidb-resource-control-ru-groups.md#create-a-resource-group)参照してください。 + リソースグループが存在しません。このエラーは、存在しないリソースグループを変更またはバインドした場合に返されます。1 [リソースグループを作成する](/tidb-resource-control-ru-groups.md#create-a-resource-group)を参照してください。 - エラー番号: 8250 @@ -505,11 +505,11 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8253 - クエリはランナウェイクエリの条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)参照してください。 + クエリはランナウェイクエリの条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 - エラー番号: 8254 - クエリは、ランナウェイクエリの隔離監視条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)参照してください。 + クエリは、ランナウェイクエリの隔離監視条件を満たしているため停止します。1 [ランナウェイクエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 - エラー番号: 8260 @@ -585,7 +585,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 1回のトランザクションが大きすぎます。 - 解決策については[エラーメッセージ`transaction too large`](/faq/migration-tidb-faq.md#the-error-message-transaction-too-large-is-displayed)参照してください。 + 解決策については[エラーメッセージ`transaction too large`](/faq/migration-tidb-faq.md#the-error-message-transaction-too-large-is-displayed)を参照してください。 - エラー番号: 9007 @@ -647,7 +647,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 完全なエラーメッセージ: `ERROR 9001 (HY000): PD server timeout start timestamp may fall behind safe point` - このエラーは、TiDBがPDへのアクセスに失敗した場合に発生します。TiDBのバックグラウンドワーカーはPDに対してセーフポイントへのクエリを継続的に実行し、100秒以内にクエリに失敗するとこのエラーを報告します。通常、PDのディスクが低速でビジー状態であるか、TiDBとPD間のネットワークに障害が発生していることが原因です。一般的なエラーの詳細については、 [エラー番号と障害診断](/error-codes.md)参照してください。 + このエラーは、TiDBがPDへのアクセスに失敗した場合に発生します。TiDBのバックグラウンドワーカーはPDに対してセーフポイントへのクエリを継続的に実行し、100秒以内にクエリに失敗するとこのエラーを報告します。通常、PDのディスクが低速でビジー状態であるか、TiDBとPD間のネットワークに障害が発生していることが原因です。一般的なエラーの詳細については、 [エラー番号と障害診断](/error-codes.md)を参照してください。 - TiDB ログエラーメッセージ: EOF エラー diff --git a/explain-aggregation.md b/explain-aggregation.md index c6898a8f18006..20412e5b50694 100644 --- a/explain-aggregation.md +++ b/explain-aggregation.md @@ -190,4 +190,4 @@ explain SELECT year, month, grouping(year), grouping(month), SUM(profit) AS prof 前のステートメントの`GROUP BY year, month WITH ROLLUP`構文に従って、このステートメントの SQL 集計結果は、それぞれ`{year, month}` 、 `{year}` 、 `{}` 3 つのグループに計算され、連結されます。 -詳細については[GROUP BY修飾子](/functions-and-operators/group-by-modifier.md)参照してください。 +詳細については[GROUP BY修飾子](/functions-and-operators/group-by-modifier.md)を参照してください。 diff --git a/explain-index-merge.md b/explain-index-merge.md index 27ae22d47cb8c..73ac0ad2b3029 100644 --- a/explain-index-merge.md +++ b/explain-index-merge.md @@ -90,7 +90,7 @@ EXPLAIN SELECT /*+ USE_INDEX_MERGE(t, idx_a, idx_b, idx_c) */ * FROM t WHERE a > > > - インデックスマージ機能はv5.4.0からデフォルトで有効になっています。つまり、 [`tidb_enable_index_merge`](/system-variables.md#tidb_enable_index_merge-new-in-v40)は`ON`なります。 > -> - SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)使用すると、 `tidb_enable_index_merge`設定に関係なく、オプティマイザにインデックスマージを強制的に適用させることができます。フィルタリング条件にプッシュダウンできない式が含まれている場合にインデックスマージを有効にするには、SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)使用する必要があります。 +> - SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用すると、 `tidb_enable_index_merge`設定に関係なく、オプティマイザにインデックスマージを強制的に適用させることができます。フィルタリング条件にプッシュダウンできない式が含まれている場合にインデックスマージを有効にするには、SQLヒント[`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)を使用する必要があります。 > > - [オプティマイザー修正制御 52869](/optimizer-fix-controls.md#52869-new-in-v810)が`OFF`に設定されている場合、オプティマイザがクエリプランに対して単一インデックススキャン方式（フルテーブルスキャン以外）を選択できるとき、オプティマイザはインデックスマージを自動的には選択しません。インデックスマージを使用するには、オプティマイザヒントを指定する必要があります。v8.5.7以降、この制御のデフォルト値は`ON`に変更されており、これにより前述の制限がデフォルトで解除され、オプティマイザはより多くのクエリでインデックスマージを自動的に選択できるようになります。 > diff --git a/explain-joins.md b/explain-joins.md index 8dd543f5d9dd8..74703ce8f7686 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -41,7 +41,7 @@ ANALYZE TABLE t1, t2; > **注記：** > -> 返される実行プランにおいて、演算子`IndexJoin`および`Apply`のすべてのプローブ側子ノードについて、v6.4.0以降では`estRows`の意味がv6.4.0以前と異なります。詳細は[TiDB クエリ実行プランの概要](/explain-overview.md#understand-explain-output)参照してください。 +> 返される実行プランにおいて、演算子`IndexJoin`および`Apply`のすべてのプローブ側子ノードについて、v6.4.0以降では`estRows`の意味がv6.4.0以前と異なります。詳細は[TiDB クエリ実行プランの概要](/explain-overview.md#understand-explain-output)を参照してください。 ```sql EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id; @@ -163,11 +163,11 @@ EXPLAIN ANALYZE SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.int_ > **注記：** > -> 上記の例では、SQLオプティマイザはインデックス結合よりもパフォーマンスの低いハッシュ結合プランを選択します。クエリ最適化は[NP完全問題](https://en.wikipedia.org/wiki/NP-completeness)であり、最適ではないプランが選択される場合があります。頻繁に実行されるクエリの場合は、 [SQLプラン管理](/sql-plan-management.md)使用してクエリにヒントをバインドすることをお勧めします。これは、アプリケーションがTiDBに送信するクエリにヒントを挿入するよりも管理が容易です。 +> 上記の例では、SQLオプティマイザはインデックス結合よりもパフォーマンスの低いハッシュ結合プランを選択します。クエリ最適化は[NP完全問題](https://en.wikipedia.org/wiki/NP-completeness)であり、最適ではないプランが選択される場合があります。頻繁に実行されるクエリの場合は、 [SQLプラン管理](/sql-plan-management.md)を使用してクエリにヒントをバインドすることをお勧めします。これは、アプリケーションがTiDBに送信するクエリにヒントを挿入するよりも管理が容易です。 ### インデックス結合のバリエーション {#variations-of-index-join} -ヒント[`INL_JOIN`](/optimizer-hints.md#inl_joint1_name--tl_name-)使用したインデックス結合操作では、外部テーブルに結合する前に中間結果のハッシュテーブルが作成されます。TiDBは、ヒント[`INL_HASH_JOIN`](/optimizer-hints.md#inl_hash_join)を使用した外部テーブルへのハッシュテーブルの作成もサポートしています。これらのインデックス結合の各バリエーションは、SQLオプティマイザによって自動的に選択されます。 +ヒント[`INL_JOIN`](/optimizer-hints.md#inl_joint1_name--tl_name-)を使用したインデックス結合操作では、外部テーブルに結合する前に中間結果のハッシュテーブルが作成されます。TiDBは、ヒント[`INL_HASH_JOIN`](/optimizer-hints.md#inl_hash_join)を使用した外部テーブルへのハッシュテーブルの作成もサポートしています。これらのインデックス結合の各バリエーションは、SQLオプティマイザによって自動的に選択されます。 ### コンフィグレーション {#configuration} @@ -254,7 +254,7 @@ Query OK, 0 rows affected (0.00 sec) ### 関連する最適化 {#related-optimizations} -TiDBは、ハッシュ結合のパフォーマンスを最適化し、実行速度を大幅に向上させるランタイムフィルタ機能を提供します。具体的な最適化の使用方法については、 [ランタイムフィルター](/runtime-filter.md)参照してください。 +TiDBは、ハッシュ結合のパフォーマンスを最適化し、実行速度を大幅に向上させるランタイムフィルタ機能を提供します。具体的な最適化の使用方法については、 [ランタイムフィルター](/runtime-filter.md)を参照してください。 ## マージ結合 {#merge-join} diff --git a/explain-mpp.md b/explain-mpp.md index 644952d30c1a7..0e5a0d9d17e7d 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -5,7 +5,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行プ # MPPモードでステートメントを説明する {#explain-statements-in-the-mpp-mode} -TiDBは、 [MPPモード](/tiflash/use-tiflash-mpp-mode.md)使用したクエリ実行をサポートしています。MPPモードでは、TiDBオプティマイザはMPP用の実行プランを生成します。MPPモードは、 [TiFlash](/tiflash/tiflash-overview.md)にレプリカを持つテーブルでのみ使用できることに注意してください。 +TiDBは、 [MPPモード](/tiflash/use-tiflash-mpp-mode.md)を使用したクエリ実行をサポートしています。MPPモードでは、TiDBオプティマイザはMPP用の実行プランを生成します。MPPモードは、 [TiFlash](/tiflash/tiflash-overview.md)にレプリカを持つテーブルでのみ使用できることに注意してください。 このドキュメントの例は、次のサンプル データに基づいています。 diff --git a/explain-overview.md b/explain-overview.md index 9200644202fb0..7c67e3e907a96 100644 --- a/explain-overview.md +++ b/explain-overview.md @@ -174,4 +174,4 @@ SQL最適化の目標の一つは、計算を可能な限りTiKVに委ねるこ - `keep order:false` 、このクエリのセマンティクスでは TiKV が結果を順番に返す必要がないことを示しています。クエリが順序付けを必要とするように変更された場合（例えば`SELECT * FROM t WHERE a = 1 ORDER BY id` ）、この条件は`keep order:true`になります。 - `stats:pseudo` 、 `estRows`に示されている推定値が正確ではない可能性があることを示しています。TiDB はバックグラウンド処理の一環として定期的に統計を更新します。4 `ANALYZE TABLE t`実行して手動で更新することもできます。 -`EXPLAIN`文の実行後、異なる演算子は異なる情報を出力します。オプティマイザヒントを使用してオプティマイザの動作を制御し、それによって物理演算子の選択を制御できます。例えば、 `/*+ HASH_JOIN(t1, t2) */`オプティマイザが`Hash Join`アルゴリズムを使用することを意味します。詳細については、 [オプティマイザヒント](/optimizer-hints.md)参照してください。 +`EXPLAIN`文の実行後、異なる演算子は異なる情報を出力します。オプティマイザヒントを使用してオプティマイザの動作を制御し、それによって物理演算子の選択を制御できます。例えば、 `/*+ HASH_JOIN(t1, t2) */`オプティマイザが`Hash Join`アルゴリズムを使用することを意味します。詳細については、 [オプティマイザヒント](/optimizer-hints.md)を参照してください。 diff --git a/explain-subqueries.md b/explain-subqueries.md index 6e8e14aadad99..36556c346ac41 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -5,7 +5,7 @@ summary: TiDB のEXPLAINステートメントによって返される実行プ # サブクエリを使用するステートメントの説明 {#explain-statements-that-use-subqueries} -TiDBはサブクエリのパフォーマンスを向上させるために[いくつかの最適化](/subquery-optimization.md)実行します。このドキュメントでは、一般的なサブクエリに対するこれらの最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 +TiDBはサブクエリのパフォーマンスを向上させるために[いくつかの最適化](/subquery-optimization.md)を実行します。このドキュメントでは、一般的なサブクエリに対するこれらの最適化のいくつかと、 `EXPLAIN`の出力の解釈方法について説明します。 このドキュメントの例は、次のサンプル データに基づいています。 diff --git a/explain-views.md b/explain-views.md index 99281cb878f68..7ed610d0fe55c 100644 --- a/explain-views.md +++ b/explain-views.md @@ -5,7 +5,7 @@ summary: TiDB の EXPLAIN` ステートメントによって返される実行 # ビューを使用したEXPLAINステートメント {#explain-statements-using-views} -`EXPLAIN` 、 [ビュー](/views.md)参照するテーブルとインデックスを表示しますが、ビュー自体の名前は表示しません。これは、ビューが仮想テーブルに過ぎず、それ自体にはデータを格納しないためです。ビューの定義と残りの文は、SQL最適化中にマージされます。 +`EXPLAIN` 、 [ビュー](/views.md)を参照するテーブルとインデックスを表示しますが、ビュー自体の名前は表示しません。これは、ビューが仮想テーブルに過ぎず、それ自体にはデータを格納しないためです。ビューの定義と残りの文は、SQL最適化中にマージされます。 diff --git a/explain-walkthrough.md b/explain-walkthrough.md index 5222c35d625e1..1a1a2929d8314 100644 --- a/explain-walkthrough.md +++ b/explain-walkthrough.md @@ -41,12 +41,12 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 1. コプロセッサ（TiKV）は、 `trips`テーブル全体を`TableFullScan`演算として読み取ります。その後、読み取った行をTiKV内の`Selection_19`の演算子に渡します。 2. 述語`WHERE start_date BETWEEN ..`演算子`Selection_19`でフィルタリングされます。この選択に該当する行は約`250`行と推定されます。この数は統計情報と演算子のロジックに基づいて推定されることに注意してください。演算子`└─TableFullScan_18` `stats:pseudo`表示されますが、これはテーブルに実際の統計情報が存在しないことを意味します。11 `ANALYZE TABLE trips`実行して統計情報を収集すると、統計の精度が向上することが期待されます。 3. 選択基準を満たす行には、関数`count`が適用されます。これも演算子`StreamAgg_9`内で完了しますが、演算子 3 も TiKV 内にあります ( `cop[tikv]` )。TiKV コプロセッサは、MySQL の組み込み関数を多数実行できます。そのうちの 1 つが`count`です。 -4. `StreamAgg_9`の結果は、TiDBサーバー内にある`TableReader_21`演算子（ `root`のタスク）に送信されます。この演算子の`estRows`列の値は`1`です。これは、演算子がアクセス対象のTiKVリージョンごとに1行ずつ受け取ることを意味します。これらのリクエストの詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)参照してください。 +4. `StreamAgg_9`の結果は、TiDBサーバー内にある`TableReader_21`演算子（ `root`のタスク）に送信されます。この演算子の`estRows`列の値は`1`です。これは、演算子がアクセス対象のTiKVリージョンごとに1行ずつ受け取ることを意味します。これらのリクエストの詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を参照してください。 5. 次に、演算子`StreamAgg_20`は演算子`└─TableReader_21`の各行に関数`count`適用します。これは演算子[`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)からもわかるように、約 56 行になります。これはルート演算子であるため、結果をクライアントに返します。 > **注記：** > -> テーブルに含まれるリージョンの概要を表示するには、 [`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)実行します。 +> テーブルに含まれるリージョンの概要を表示するには、 [`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md)を実行します。 ## 現在のパフォーマンスを評価する {#assess-the-current-performance} @@ -175,7 +175,7 @@ EXPLAIN SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 4 rows in set (0.00 sec) ``` -実際の実行時間を比較するには、再度[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)使用します。 +実際の実行時間を比較するには、再度[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を使用します。 ```sql EXPLAIN ANALYZE SELECT count(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'; diff --git a/explore-htap.md b/explore-htap.md index bf705bfab3d5b..49e1753228d42 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -29,7 +29,7 @@ HTAPの典型的な使用例は以下のとおりです。 TiDBをデータハブとして使用する場合、TiDBはアプリケーションのデータとデータウェアハウスのデータをシームレスに接続することで、特定のビジネスニーズを満たすことができます。 -TiDB HTAPの使用例の詳細については、 [PingCAPウェブサイト上のHTAPに関するブログ](https://www.pingcap.com/blog/?tag=htap)参照してください。 +TiDB HTAPの使用例の詳細については、 [PingCAPウェブサイト上のHTAPに関するブログ](https://www.pingcap.com/blog/?tag=htap)を参照してください。 TiDBの全体的なパフォーマンスを向上させるため、以下の技術的なシナリオではHTAPを使用することをお勧めします。 @@ -59,8 +59,8 @@ TiDBでは、オンライン・トランザクション処理（OLTP）用の行 TiDB HTAPの機能を検討する前に、TiDBとそのカラム型ストレージエンジンであるTiFlashを導入する必要があります。データ量が大きい場合（例えば100テラバイト）、ソリューションとしてTiFlashの大規模並列処理（MPP）を使用することをお勧めします。 -- TiFlashノードのない TiDB クラスターをデプロイした場合は、現在の TiDB クラスターにTiFlashノードを追加します。詳細については、 [TiFlashクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)参照してください。 -- TiDB クラスターをデプロイしていない場合は、 [TiUPを使用してTiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。最小限の TiDB トポロジーに基づいて、 [TiFlashのトポロジー](/tiflash-deployment-topology.md)もデプロイする必要があります。 +- TiFlashノードのない TiDB クラスターをデプロイした場合は、現在の TiDB クラスターにTiFlashノードを追加します。詳細については、 [TiFlashクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)を参照してください。 +- TiDB クラスターをデプロイしていない場合は、 [TiUPを使用してTiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。最小限の TiDB トポロジーに基づいて、 [TiFlashのトポロジー](/tiflash-deployment-topology.md)もデプロイする必要があります。 - TiFlashノードの数を決定する際には、以下のシナリオを考慮してください。 - 小規模な分析処理とアドホッククエリを伴うOLTPが必要な場合は、1台または複数台のTiFlashノードを導入してください。分析クエリの速度を劇的に向上させることができます。 @@ -74,8 +74,8 @@ TiDB HTAPの機能を検討する前に、TiDBとそのカラム型ストレー TiFlashがデプロイされた後、TiKVは自動的にTiFlashにデータを複製しません。TiFlashにTiFlashする必要のあるテーブルを手動で指定する必要があります。その後、TiDBが対応するTiFlashレプリカを作成します。 -- TiDBクラスタにデータがない場合は、まずデータを TiDB に移行します。詳細については、[データ移行](/migration-overview.md)参照してください。 -- TiDBクラスタに既にアップストリームからレプリケートされたデータが存在する場合、 TiFlashのデプロイ後、データレプリケーションは自動的に開始されません。TiFlashにレプリケートするテーブルを手動で指定する必要があります。詳細については、 TiFlash[TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash)参照してください。 。 +- TiDBクラスタにデータがない場合は、まずデータを TiDB に移行します。詳細については、[データ移行](/migration-overview.md)を参照してください。 +- TiDBクラスタに既にアップストリームからレプリケートされたデータが存在する場合、 TiFlashのデプロイ後、データレプリケーションは自動的に開始されません。TiFlashにレプリケートするテーブルを手動で指定する必要があります。詳細については、 TiFlash[TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash)を参照してください。 。 ## データ処理 {#data-processing} @@ -112,5 +112,5 @@ TiDBの使用中に問題が発生した場合は、以下のドキュメント ## 次は？ {#what-s-next} -- TiFlash のバージョン、重要なログ、システム テーブルを確認するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)参照してください。 -- 特定のTiFlashノードを削除するには、 [TiFlashクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)参照してください。 +- TiFlash のバージョン、重要なログ、システム テーブルを確認するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 +- 特定のTiFlashノードを削除するには、 [TiFlashクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)を参照してください。 diff --git a/expression-syntax.md b/expression-syntax.md index 2a771bbfa09aa..0325d2e19e608 100644 --- a/expression-syntax.md +++ b/expression-syntax.md @@ -9,7 +9,7 @@ summary: TiDB の式構文について学習します。 表現は次の種類に分けられます。 -- 識別子。参考として[スキーマオブジェクト名](/schema-object-names.md)参照してください。 +- 識別子。参考として[スキーマオブジェクト名](/schema-object-names.md)を参照してください。 - 述語、数値、文字列、日付式。これらのうち[リテラル値](/literal-values.md)式です。 diff --git a/external-storage-uri.md b/external-storage-uri.md index 4fc4e4c1be64c..1e83c7ce18d4c 100644 --- a/external-storage-uri.md +++ b/external-storage-uri.md @@ -31,8 +31,8 @@ URI の基本的な形式は次のとおりです。 - `sse` : アップロードされたオブジェクトの暗号化に使用されるサーバー側暗号化アルゴリズムを指定します (値のオプション: 空、 `AES256` 、または`aws:kms` )。 - `sse-kms-key-id` : `sse` `aws:kms`に設定されている場合は KMS ID を指定します。 - `acl` : アップロードされたオブジェクトの既定 ACL を指定します (たとえば、 `private`または`authenticated-read` )。 - - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMIAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 - - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 + - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMIAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)を参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 + - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)を指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 以下は、 TiDB LightningおよびBRの Amazon S3 URI の例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 @@ -78,15 +78,15 @@ tiup cdc:v7.5.0 cli changefeed create \ - `acl` : アップロードされたオブジェクトの既定 ACL を指定します (たとえば、 `private`または`authenticated-read` )。 - - `role-arn` : TiDB Cloud が特定の[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用して Amazon S3 データにアクセスできるようにするには、 `role-arn` URL クエリパラメータにロールの[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)指定します。例: `arn:aws:iam::888888888888:role/my-role` 。 + - `role-arn` : TiDB Cloud が特定の[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を使用して Amazon S3 データにアクセスできるようにするには、 `role-arn` URL クエリパラメータにロールの[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)を指定します。例: `arn:aws:iam::888888888888:role/my-role` 。 > **注記：** > > - IAMロールを自動的に作成するには、 [TiDB Cloudコンソール](https://tidbcloud.com/)でクラスターの**[Amazon S3 からのデータのインポート]**ページに移動し、 **[フォルダー URI]**フィールドに入力し、 **[ロール ARN]**フィールドの [**ここをクリックして AWS CloudFormation で新しく作成] を**クリックして、 **[新しいロール ARN の追加]**ダイアログの画面上の指示に従います。 > - AWS CloudFormation を使用してIAMロールを作成する際に問題が発生した場合は、 **「新しいロール ARN を追加」**ダイアログで**「問題が発生した場合は、ロール ARN を手動で作成する」を**クリックしてTiDB Cloudアカウント ID とTiDB Cloud外部 ID を取得し、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)の手順に従って手動でロールを作成してください。IAMIAMを設定する際は、 **「アカウント ID」**フィールドにTiDB Cloudアカウント ID を入力し、 [混乱した副官の攻撃](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)から保護するために**外部 ID を要求する」**を選択してください。 - > - セキュリティを強化するために、**最大セッション継続時間を**短く設定することで、 IAMロールの有効期間を短縮できます。詳細については、AWSドキュメントの[ロールの最大セッション期間を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html#id_roles_update-session-duration)参照してください。 + > - セキュリティを強化するために、**最大セッション継続時間を**短く設定することで、 IAMロールの有効期間を短縮できます。詳細については、AWSドキュメントの[ロールの最大セッション期間を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html#id_roles_update-session-duration)を参照してください。 - - `external-id` : TiDB Cloud がAmazon S3 データにアクセスするために必要なTiDB Cloud外部 ID を指定します。この ID は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の**「新しいロール ARN を追加」**ダイアログから取得できます。詳細については、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)参照してください。 + - `external-id` : TiDB Cloud がAmazon S3 データにアクセスするために必要なTiDB Cloud外部 ID を指定します。この ID は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の**「新しいロール ARN を追加」**ダイアログから取得できます。詳細については、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)を参照してください。 以下は、 [`BACKUP`](/sql-statements/sql-statement-backup.md)と[`RESTORE`](/sql-statements/sql-statement-restore.md)のAmazon S3 URIの例です。この例では、ファイルパス`testfolder`を使用しています。 @@ -132,8 +132,8 @@ gcs://external/test.csv?credentials-file=${credentials-file-path} - `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)指定します。 - - `encryption-key` : AES256 暗号化アルゴリズムを使用するサーバー側暗号化の場合は[暗号化キー](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys)指定します。 + - `encryption-scope` : サーバー側の暗号化に[暗号化範囲](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-manage?tabs=powershell#upload-a-blob-with-an-encryption-scope)を指定します。 + - `encryption-key` : AES256 暗号化アルゴリズムを使用するサーバー側暗号化の場合は[暗号化キー](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys)を指定します。 以下は、 BRのAzure Blob Storage URIの例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md index 6212b4c493be5..ec91e60e156df 100644 --- a/faq/backup-and-restore-faq.md +++ b/faq/backup-and-restore-faq.md @@ -9,7 +9,7 @@ summary: よくある質問 (FAQ) とバックアップおよび復元のソリ ## 誤ってデータを削除または更新した後、データをすばやく回復するにはどうすればよいですか? {#what-should-i-do-to-quickly-recover-data-after-mistakenly-deleting-or-updating-data} -TiDB v6.4.0では、フラッシュバック機能が導入されました。この機能を使用すると、GC時間内に特定の時点までデータを迅速に復旧できます。そのため、誤操作が発生した場合でも、この機能を使用してデータを復旧できます。詳細は[フラッシュバッククラスタ](/sql-statements/sql-statement-flashback-cluster.md)と[フラッシュバックデータベース](/sql-statements/sql-statement-flashback-database.md)参照してください。 +TiDB v6.4.0では、フラッシュバック機能が導入されました。この機能を使用すると、GC時間内に特定の時点までデータを迅速に復旧できます。そのため、誤操作が発生した場合でも、この機能を使用してデータを復旧できます。詳細は[フラッシュバッククラスタ](/sql-statements/sql-statement-flashback-cluster.md)と[フラッシュバックデータベース](/sql-statements/sql-statement-flashback-database.md)を参照してください。 ## TiDB v5.4.0 以降のバージョンでは、ワークロードが高いクラスターでバックアップ タスクを実行すると、バックアップ タスクの速度が遅くなるのはなぜですか? {#in-tidb-v5-4-0-and-later-versions-when-backup-tasks-are-performed-on-the-cluster-under-a-heavy-workload-why-does-the-speed-of-backup-tasks-become-slow} @@ -123,7 +123,7 @@ failed to refresh meta for database with schemaID=124, dbName=pitr_test: [ddl:82 - 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-code-new-collation-enabled-code-mismatch-reported-during-restore} @@ -269,7 +269,7 @@ br restore full -f 'mysql.usertable' -s $external_storage_url --with-sys-table [テーブルフィルター](/table-filter.md#syntax)設定しても、 **BR は次のシステム テーブルを復元しないこと**に注意してください。 -- 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。3 [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照してください。 +- 統計表（ `mysql.stat_*` ）。ただし、統計は復元可能です。3 [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照してください。 - システム変数テーブル（ `mysql.tidb` `mysql.global_variables` - [その他のシステムテーブル](https://github.com/pingcap/tidb/blob/release-8.5/br/pkg/restore/snap_client/systable_restore.go#L31) diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 63482d8ba1d96..026c6409eb50a 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -11,11 +11,11 @@ summary: TiDB のデプロイメントに関連する FAQ について説明し ### 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)参照してください。 +TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェア・サーバー・プラットフォーム、またはARMアーキテクチャのハードウェア・サーバー・プラットフォームに導入および実行できます。開発環境、テスト環境、および本番環境におけるサーバー・ハードウェア構成の要件と推奨事項については、 [ソフトウェアとハ​​ードウェアの推奨事項 - サーバー要件](/hardware-and-software-requirements.md#server-requirements)を参照してください。 ### 10 ギガビットのネットワーク カード 2 枚の目的は何ですか? {#what-s-the-purposes-of-2-network-cards-of-10-gigabit} @@ -35,11 +35,11 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ ## インストールと展開 {#installation-and-deployment} -本番環境では、 [TiUP](/tiup/tiup-overview.md)使用してTiDBクラスタをデプロイすることをお勧めします。3 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +本番環境では、 [TiUP](/tiup/tiup-overview.md)を使用してTiDBクラスタをデプロイすることをお勧めします。3 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 ### TiKV/PD 用に変更されたtoml構成が有効にならないのはなぜですか? {#why-the-modified-code-toml-code-configuration-for-tikv-pd-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} @@ -55,13 +55,13 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ 2. スロークエリが発生した場合、Grafana を使用してスロークエリが発生している`tidb-server`インスタンスとスロークエリの時刻を特定し、該当ノードのログに記録された SQL 文の情報を見つけることができます。 -3. ログに加えて、 `ADMIN SHOW SLOW`コマンドを使用してスロークエリも表示できます。詳細は[`ADMIN SHOW SLOW`コマンド](/identify-slow-queries.md#admin-show-slow-command)参照してください。 +3. ログに加えて、 `ADMIN SHOW SLOW`コマンドを使用してスロークエリも表示できます。詳細は[`ADMIN SHOW SLOW`コマンド](/identify-slow-queries.md#admin-show-slow-command)を参照してください。 ### TiDB クラスターを初めてデプロイしたときに TiKV のlabelが構成されていなかった場合、 label構成を追加するにはどうすればよいですか? {#how-to-add-the-code-label-code-configuration-if-code-label-code-of-tikv-was-not-configured-when-i-deployed-the-tidb-cluster-for-the-first-time} 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-code-dd-code-command-for-the-disk-test-use-the-code-oflag-direct-code-option} diff --git a/faq/high-availability-faq.md b/faq/high-availability-faq.md index c848ed9ea3e2a..2df637a2cb337 100644 --- a/faq/high-availability-faq.md +++ b/faq/high-availability-faq.md @@ -9,7 +9,7 @@ summary: TiDB の高可用性に関連する FAQ について説明します。 ## TiDB はどのように強力な一貫性を備えていますか? {#how-is-tidb-strongly-consistent} -ノード障害が発生した場合でも回復可能性を確保するために、データは[Raftコンセンサスアルゴリズム](https://raft.github.io/)使用して TiKV ノード間で冗長的に複製されます。 +ノード障害が発生した場合でも回復可能性を確保するために、データは[Raftコンセンサスアルゴリズム](https://raft.github.io/)を使用して TiKV ノード間で冗長的に複製されます。 最下層では、TiKVはレプリケーションログ＋ステートマシンのモデルを用いてデータを複製します。書き込みリクエストの場合、データはLeaderに書き込まれ、Leaderはログの形式でコマンドをフォロワーに複製します。クラスター内の過半数のノードがこのログを受信すると、ログはコミットされ、ステートマシンに適用できるようになります。 diff --git a/faq/high-reliability-faq.md b/faq/high-reliability-faq.md index fb012ee5beb2c..65703a9a1c5ca 100644 --- a/faq/high-reliability-faq.md +++ b/faq/high-reliability-faq.md @@ -38,4 +38,4 @@ MySQL と同様に、TiDB はユーザー ログイン認証とパスワード TiDB でユーザー パスワードを変更する場合は、他のノードのパスワードがタイムリーに更新されない可能性がある`UPDATE mysql.user`ではなく、 `ALTER USER` (たとえば、 `ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';` ) を使用することをお勧めします。 -ユーザーのパスワードと権限を変更する際は、公式の標準ステートメントを使用することをお勧めします。詳細については、 [TiDB ユーザーアカウント管理](/user-account-management.md)参照してください。 +ユーザーのパスワードと権限を変更する際は、公式の標準ステートメントを使用することをお勧めします。詳細については、 [TiDB ユーザーアカウント管理](/user-account-management.md)を参照してください。 diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index c2892048aface..f2ebd7a1c6db5 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -49,9 +49,9 @@ MySQL と同様に、TiDB にはシステム テーブルも含まれており TiDB v6.1.0 では、グローバルキル機能が導入されました (デフォルトで有効になっている`enable-global-kill`設定によって制御されます)。グローバルキルが有効になっている場合は、 `kill session_id`を実行するだけです。 - TiDB のバージョンが v6.1.0 より前、またはグローバル キル機能が有効になっていない場合、 `kill session_id`デフォルトでは有効になりません。DML ステートメントを終了するには、クライアントを DML ステートメントを実行している TiDB インスタンスに直接接続してから、 `kill tidb session_id`ステートメントを実行する必要があります。クライアントが別の TiDB インスタンスに接続している場合、またはクライアントと TiDB クラスタの間にプロキシがある場合、 `kill tidb session_id`ステートメントが別の TiDB インスタンスにルーティングされ、別のセッションが誤って終了する可能性があります。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)参照してください。 + TiDB のバージョンが v6.1.0 より前、またはグローバル キル機能が有効になっていない場合、 `kill session_id`デフォルトでは有効になりません。DML ステートメントを終了するには、クライアントを DML ステートメントを実行している TiDB インスタンスに直接接続してから、 `kill tidb session_id`ステートメントを実行する必要があります。クライアントが別の TiDB インスタンスに接続している場合、またはクライアントと TiDB クラスタの間にプロキシがある場合、 `kill tidb session_id`ステートメントが別の TiDB インスタンスにルーティングされ、別のセッションが誤って終了する可能性があります。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。 -- DDL ステートメントを強制終了するには、まず`admin show ddl jobs`を使用して終了する必要のある DDL ジョブの ID を見つけ、次に`admin cancel ddl jobs 'job_id' [, 'job_id'] ...`を実行します。詳細については、 [`ADMIN`ステートメント](/sql-statements/sql-statement-admin.md)参照してください。 +- DDL ステートメントを強制終了するには、まず`admin show ddl jobs`を使用して終了する必要のある DDL ジョブの ID を見つけ、次に`admin cancel ddl jobs 'job_id' [, 'job_id'] ...`を実行します。詳細については、 [`ADMIN`ステートメント](/sql-statements/sql-statement-admin.md)を参照してください。 ### TiDBはセッションタイムアウトをサポートしていますか？ {#does-tidb-support-session-timeout} @@ -73,7 +73,7 @@ TiDBは、低コストで簡単にクラスタを管理できるいくつかの TiDB コミュニティは非常に活発です。エンジニアは機能の最適化とバグの修正を続けてきました。したがって、TiDB のバージョンは非常に速く更新されます。最新バージョンの情報を入手したい場合は、 [TiDBのリリーススケジュール](/releases/release-timeline.md)をご覧ください。 -TiDB [TiUPを使用する](/production-deployment-using-tiup.md)、または[TiDB Operatorを使用する](https://docs.pingcap.com/tidb-in-kubernetes/stable)使用するを導入することをお勧めします。 TiDBではバージョン番号を一元管理しています。次のいずれかの方法を使用してバージョン番号を表示できます。 +TiDB [TiUPを使用する](/production-deployment-using-tiup.md)、または[TiDB Operatorを使用する](https://docs.pingcap.com/tidb-in-kubernetes/stable)を使用するを導入することをお勧めします。 TiDBではバージョン番号を一元管理しています。次のいずれかの方法を使用してバージョン番号を表示できます。 - `select tidb_version()` - `tidb-server -V` @@ -419,7 +419,7 @@ TiDBのバージョンとTiKV API V2が有効になっているかどうか（ [ ### TiDBのSysbenchベンチマークテストを実施するにはどうすればよいですか？ {#how-to-conduct-a-sysbench-benchmark-test-for-tidb} -[Sysbenchを使用してTiDBをテストする方法](/benchmark/benchmark-tidb-using-sysbench.md)参照してください。 +[Sysbenchを使用してTiDBをテストする方法](/benchmark/benchmark-tidb-using-sysbench.md)を参照してください。 ### Sysbenchを使用したTiDBのパフォーマンステスト結果はどうなっていますか？ {#what-is-the-performance-test-result-for-tidb-using-sysbench} @@ -449,7 +449,7 @@ TiDBは、小規模なテーブル（例えば1,000万件未満）には適し 現在、大容量データ（1 TB 以上）のバックアップには、[Backup & Restore (BR)](/br/backup-and-restore-overview.md)を使用する方法が推奨されています。それ以外の場合は、 [Dumpling](/dumpling-overview.md)が推奨ツールです。公式の MySQL ツール`mysqldump`も TiDB でデータのバックアップと復元がサポートされていますが、そのパフォーマンスはBRより優れているわけではなく、大容量データのバックアップと復元にははるかに時間がかかります。 -BRに関するその他のよくある質問については、 [BRよくある質問](/faq/backup-and-restore-faq.md)参照してください。 +BRに関するその他のよくある質問については、 [BRよくある質問](/faq/backup-and-restore-faq.md)を参照してください。 ### バックアップと復元の速度はどうですか？ {#how-is-the-speed-of-backup-and-restore} diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index 027d18f160ff0..2a68704c3f2f0 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -22,7 +22,7 @@ TiDB はほとんどの MySQL 構文をサポートしているため、ほと ### データのインポートとエクスポートが遅く、他のエラーがないにもかかわらず、各コンポーネントのログに多くの再試行とEOFエラーが表示されます。 {#data-import-and-export-is-slow-and-many-retries-and-eof-errors-appear-in-the-log-of-each-component-without-other-errors} -他の論理エラーが発生していない場合、再試行とEOFエラーはネットワークの問題が原因である可能性があります。まずはツールを使用してネットワーク接続を確認することをお勧めします。次の例では、トラブルシューティングに[iperf](https://iperf.fr/)使用しています。 +他の論理エラーが発生していない場合、再試行とEOFエラーはネットワークの問題が原因である可能性があります。まずはツールを使用してネットワーク接続を確認することをお勧めします。次の例では、トラブルシューティングに[iperf](https://iperf.fr/)を使用しています。 - 再試行と EOF エラーが発生したサーバー側ノードで次のコマンドを実行します。 @@ -73,7 +73,7 @@ TiDBサービスを再起動し、設定ファイルにパラメータ`-skip-gra TiDB のデータをエクスポートするには、次の方法を使用できます。 -- Dumplingを使用してデータをエクスポートします。詳細については、 [Dumplingのドキュメント](/dumpling-overview.md)参照してください。 +- Dumplingを使用してデータをエクスポートします。詳細については、 [Dumplingのドキュメント](/dumpling-overview.md)を参照してください。 - mysqldump と`WHERE`句を使用してデータをエクスポートします。 - MySQL クライアントを使用して、 `select`の結果をファイルにエクスポートします。 @@ -170,7 +170,7 @@ Google Cloud Spanner には[同様の制限](https://cloud.google.com/spanner/do 大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`使用をお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`ループ終了条件として使用することで、トランザクションサイズの制限を超えないようにします。ビジネスフィルタリングロジックを満たすことを前提として、強力なフィルターインデックス列を追加するか、 `id >= 5000*n+m and id < 5000*(n+1)+m`のように主キーを直接使用して範囲を選択することをお勧めします。 -一度に削除する必要があるデータの量が非常に多い場合、このループメソッドは削除処理が後方に移動するにつれて速度が低下します。前のデータを削除した後、多くの削除フラグが短期間残り（その後、すべてガベージコレクションによって処理されます）、後続のDelete文に影響を与えます。可能であれば、Where条件を絞り込むことをお勧めします。1 [詳細はTiDBベストプラクティスをご覧ください](https://www.pingcap.com/blog/tidb-best-practice/#write)参照してください。 +一度に削除する必要があるデータの量が非常に多い場合、このループメソッドは削除処理が後方に移動するにつれて速度が低下します。前のデータを削除した後、多くの削除フラグが短期間残り（その後、すべてガベージコレクションによって処理されます）、後続のDelete文に影響を与えます。可能であれば、Where条件を絞り込むことをお勧めします。1 [詳細はTiDBベストプラクティスをご覧ください](https://www.pingcap.com/blog/tidb-best-practice/#write)を参照してください。 ### TiDB のデータ読み込み速度を向上させるにはどうすればよいでしょうか? {#how-to-improve-the-data-loading-speed-in-tidb} diff --git a/faq/monitor-faq.md b/faq/monitor-faq.md index 676c6b5bc567a..f8d0806ea5f49 100644 --- a/faq/monitor-faq.md +++ b/faq/monitor-faq.md @@ -7,12 +7,12 @@ summary: TiDB モニタリングに関連する FAQ について説明します このドキュメントでは、TiDB 監視に関連する FAQ をまとめています。 -- Prometheus 監視フレームワークの詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 -- 監視の主な指標の詳細については、 [主要な指標](/grafana-overview-dashboard.md)参照してください。 +- Prometheus 監視フレームワークの詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 +- 監視の主な指標の詳細については、 [主要な指標](/grafana-overview-dashboard.md)を参照してください。 ## 主要な指標を監視するより良い方法はありますか? {#is-there-a-better-way-of-monitoring-the-key-metrics} -TiDBの監視システムは、PrometheusとGrafanaで構成されています。Grafanaのダッシュボードから、システムリソース、クライアント接続とSQL操作、内部通信、リージョンスケジューリングなど、TiDBのさまざまな稼働メトリクスを監視できます。これらのメトリクスを活用することで、データベース管理者はシステムの稼働状況やボトルネックなどをより深く理解できます。これらのメトリクスを監視する実践的な方法として、TiDBの各コンポーネントの主要なメトリクスを以下に挙げます。一般的には、これらの共通メトリクスのみに注意を払う必要があります。詳細については、 [公式文書](/grafana-overview-dashboard.md)参照してください。 +TiDBの監視システムは、PrometheusとGrafanaで構成されています。Grafanaのダッシュボードから、システムリソース、クライアント接続とSQL操作、内部通信、リージョンスケジューリングなど、TiDBのさまざまな稼働メトリクスを監視できます。これらのメトリクスを活用することで、データベース管理者はシステムの稼働状況やボトルネックなどをより深く理解できます。これらのメトリクスを監視する実践的な方法として、TiDBの各コンポーネントの主要なメトリクスを以下に挙げます。一般的には、これらの共通メトリクスのみに注意を払う必要があります。詳細については、 [公式文書](/grafana-overview-dashboard.md)を参照してください。 ## Prometheusの監視データはデフォルトで15日ごとに削除されます。これを2か月に設定したり、監視データを手動で削除したりすることはできますか？ {#the-prometheus-monitoring-data-is-deleted-every-15-days-by-default-could-i-set-it-to-two-months-or-delete-the-monitoring-data-manually} diff --git a/faq/sql-faq.md b/faq/sql-faq.md index b9a0bf480b590..266ab0df14b9b 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -26,13 +26,13 @@ summary: TiDB SQLに関連する FAQ について説明します。 ## 適切なクエリプランを選択するにはどうすればよいですか？ヒントを使用する必要がありますか？それとも、ヒントを使用できますか？ {#how-to-choose-the-right-query-plan-do-i-need-to-use-hints-or-can-i-use-hints} -TiDBにはコストベースのオプティマイザが搭載されています。ほとんどの場合、オプティマイザが最適なクエリプランを選択します。オプティマイザがうまく機能しない場合でも、 [オプティマイザヒント](/optimizer-hints.md)使用してオプティマイザに介入することができます。 +TiDBにはコストベースのオプティマイザが搭載されています。ほとんどの場合、オプティマイザが最適なクエリプランを選択します。オプティマイザがうまく機能しない場合でも、 [オプティマイザヒント](/optimizer-hints.md)を使用してオプティマイザに介入することができます。 さらに、 [SQLバインディング](/sql-plan-management.md#sql-binding)を使用して、特定の SQL ステートメントのクエリ プランを修正することもできます。 ## 特定の SQL ステートメントの実行を防ぐにはどうすればよいでしょうか? {#how-to-prevent-the-execution-of-a-particular-sql-statement} -TiDB v7.5.0以降のバージョンでは、 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)ステートメントを使用して特定のSQL文を終了できます。詳細については、 [予想以上にリソースを消費するクエリ（ランナウェイクエリ）を管理する](/tidb-resource-control-runaway-queries.md#query-watch-parameters)参照してください。 +TiDB v7.5.0以降のバージョンでは、 [`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)ステートメントを使用して特定のSQL文を終了できます。詳細については、 [予想以上にリソースを消費するクエリ（ランナウェイクエリ）を管理する](/tidb-resource-control-runaway-queries.md#query-watch-parameters)を参照してください。 TiDB v7.5.0より前のバージョンでは、 [`MAX_EXECUTION_TIME`](/optimizer-hints.md#max_execution_timen)ヒントを使用して[SQLバインディング](/sql-plan-management.md#sql-binding)作成し、特定のステートメントの実行時間を小さな値（例えば1ミリ秒）に制限することができます。これにより、ステートメントはしきい値によって自動的に終了します。 @@ -134,7 +134,7 @@ TiDB では、システム変数[`tidb_enable_ordered_result_mode`](/system-vari ## TiDBのコーデックはUTF-8文字列がmemcomparableであることを保証できますか？キーがUTF-8をサポートする必要がある場合、コーディングに関する提案はありますか？ {#can-the-codec-of-tidb-guarantee-that-the-utf-8-string-is-memcomparable-is-there-any-coding-suggestion-if-our-key-needs-to-support-utf-8} -TiDBのデフォルトの文字セットは`utf8mb4`です。文字列はmemcomparable形式です。TiDBの文字セットの詳細については、 [文字セットと照合順序](/character-set-and-collation.md)参照してください。 +TiDBのデフォルトの文字セットは`utf8mb4`です。文字列はmemcomparable形式です。TiDBの文字セットの詳細については、 [文字セットと照合順序](/character-set-and-collation.md)を参照してください。 ## トランザクション内のステートメントの最大数はいくつですか? {#what-is-the-maximum-number-of-statements-in-a-transaction} @@ -144,7 +144,7 @@ TiDBのデフォルトの文字セットは`utf8mb4`です。文字列はmemcomp ## 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} -TiDBのAUTO_INCREMENT ID機能は、自動的に増分され一意であることが保証されているだけで、連続的に割り当てられることは保証されていません。現在、TiDBはIDをバッチで割り当てています。複数のTiDBサーバーに同時にデータが挿入された場合、割り当てられるIDは連続的ではありません。複数のスレッドが`tidb-server`のインスタンスに同時にデータを挿入した場合、後で挿入されたデータのAUTO_INCREMENT IDは小さくなる可能性があります。TiDBでは整数フィールドに`AUTO_INCREMENT`指定できますが、1つのテーブルに`AUTO_INCREMENT`フィールドは1つしか指定できません。詳細については、 [AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)と[AUTO_INCREMENT属性](/auto-increment.md)参照してください。 +TiDBのAUTO_INCREMENT ID機能は、自動的に増分され一意であることが保証されているだけで、連続的に割り当てられることは保証されていません。現在、TiDBはIDをバッチで割り当てています。複数のTiDBサーバーに同時にデータが挿入された場合、割り当てられるIDは連続的ではありません。複数のスレッドが`tidb-server`のインスタンスに同時にデータを挿入した場合、後で挿入されたデータのAUTO_INCREMENT IDは小さくなる可能性があります。TiDBでは整数フィールドに`AUTO_INCREMENT`指定できますが、1つのテーブルに`AUTO_INCREMENT`フィールドは1つしか指定できません。詳細については、 [AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)と[AUTO_INCREMENT属性](/auto-increment.md)を参照してください。 ## TiDB のsql_mode変更するにはどうすればよいですか? {#how-do-i-modify-the-code-sql-mode-code-in-tidb} @@ -172,7 +172,7 @@ Sqoopでは、 `--batch`各バッチで100文をコミットすることを意 --batch ``` -- 単一のTiDBトランザクション内のステートメント数の制限を増やすこともできますが、これによりメモリ消費量が増加します。詳細については[SQL文の制限](/tidb-limitations.md#limitations-on-sql-statements)参照してください。 +- 単一のTiDBトランザクション内のステートメント数の制限を増やすこともできますが、これによりメモリ消費量が増加します。詳細については[SQL文の制限](/tidb-limitations.md#limitations-on-sql-statements)を参照してください。 ## TiDB には Oracle のフラッシュバッククエリのような機能はありますか? DDL をサポートしていますか? {#does-tidb-have-a-function-like-the-flashback-query-in-oracle-does-it-support-ddl} @@ -243,7 +243,7 @@ SELECT column_name FROM table_name USE INDEX（index_name）WHERE where_conditio ## DDL実行 {#ddl-execution} -このセクションでは、DDL文の実行に関連する問題を列挙します。DDL実行の原則に関する詳細な説明については、 [DDL ステートメントの実行原則とベストプラクティス](/best-practices/ddl-introduction.md)参照してください。 +このセクションでは、DDL文の実行に関連する問題を列挙します。DDL実行の原則に関する詳細な説明については、 [DDL ステートメントの実行原則とベストプラクティス](/best-practices/ddl-introduction.md)を参照してください。 ### さまざまな DDL 操作を実行するにはどのくらいの時間がかかりますか? {#how-long-does-it-take-to-perform-various-ddl-operations} @@ -336,7 +336,7 @@ TiDB v6.2.0以降、TiDB DDLモジュールは並列フレームワークを採 ## JDBC接続で使用される照合順序 {#collation-used-in-jdbc-connections} -このセクションでは、JDBC接続で使用される照合順序に関する質問を示します。TiDBでサポートされている文字セットと照合順序については、 [文字セットと照合順序](/character-set-and-collation.md)参照してください。 +このセクションでは、JDBC接続で使用される照合順序に関する質問を示します。TiDBでサポートされている文字セットと照合順序については、 [文字セットと照合順序](/character-set-and-collation.md)を参照してください。 ### JDBC URL でconnectionCollationが構成されていない場合、JDBC 接続ではどの照合順序が使用されますか? {#what-collation-is-used-in-a-jdbc-connection-when-code-connectioncollation-code-is-not-configured-in-the-jdbc-url} @@ -413,10 +413,10 @@ SELECT 'café' = 'cafe' COLLATE utf8mb4_0900_ai_ci; -- Returns 1 (TRUE) 推奨事項: -- ハードウェア構成を改善してください。1 [TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)参照してください。 +- ハードウェア構成を改善してください。1 [TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)を参照してください。 - 同時実行性を向上させます。デフォルト値は10です。50に上げて試してみることもできますが、通常はデフォルト値の2～4倍の改善が見られます。 - 大量のデータの場合は`count`をテストします。 -- TiKV設定を最適化します。1と[TiKVメモリパフォーマンスの調整](/tune-tikv-memory-performance.md) [TiKVスレッドのパフォーマンスを調整する](/tune-tikv-thread-performance.md)参照してください。 +- TiKV設定を最適化します。1と[TiKVメモリパフォーマンスの調整](/tune-tikv-memory-performance.md) [TiKVスレッドのパフォーマンスを調整する](/tune-tikv-thread-performance.md)を参照してください。 - [コプロセッサーキャッシュ](/coprocessor-cache.md)を有効にします。 ### 現在の DDL ジョブの進行状況を表示するにはどうすればよいでしょうか? {#how-to-view-the-progress-of-the-current-ddl-job} @@ -451,7 +451,7 @@ ADMIN SHOW DDL; ### クエリプランがツリーとして表現される場合のIDルールは何ですか？このツリーの実行順序は何ですか？ {#what-is-the-id-rule-when-a-query-plan-is-presented-as-a-tree-what-is-the-execution-order-for-this-tree} -これらのIDにはルールはありませんが、IDは一意です。IDが生成されるとカウンターが動作し、プランが1つ生成されるごとに1が加算されます。実行順序はIDとは無関係です。クエリプラン全体はツリー構造になっており、実行プロセスはルートノードから開始され、データは上位レベルへと連続的に返されます。クエリプランの詳細については、 [TiDBクエリ実行プランの理解](/explain-overview.md)参照してください。 +これらのIDにはルールはありませんが、IDは一意です。IDが生成されるとカウンターが動作し、プランが1つ生成されるごとに1が加算されます。実行順序はIDとは無関係です。クエリプラン全体はツリー構造になっており、実行プロセスはルートノードから開始され、データは上位レベルへと連続的に返されます。クエリプランの詳細については、 [TiDBクエリ実行プランの理解](/explain-overview.md)を参照してください。 ### TiDBクエリプランでは、 copタスクは同じルートにあります。それらは同時に実行されますか？ {#in-the-tidb-query-plan-code-cop-code-tasks-are-in-the-same-root-are-they-executed-concurrently} @@ -459,7 +459,7 @@ ADMIN SHOW DDL; `cop task`は、分散実行のために KV エンドにプッシュダウンされるコンピューティング タスクです。2 `root task` 、TiDB エンドでの単一ポイント実行のためのコンピューティング タスクです。 -通常、 `root task`の入力データは`cop task`から取得されます。5 `root task`データを処理している間、TiKVの`cop task`同時にデータを処理し、TiDBの`root task`からのプルを待機します。したがって、 `cop`タスクは`root task`と並行して実行されていると見なすことができますが、それらのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間並行して実行されます。たとえば、最初の`cop task`は[100, 200]のデータを処理し、2番目の`cop task`は[1, 100]のデータを処理します。詳細は[TiDBクエリプランの理解](/explain-overview.md)参照してください。 +通常、 `root task`の入力データは`cop task`から取得されます。5 `root task`データを処理している間、TiKVの`cop task`同時にデータを処理し、TiDBの`root task`からのプルを待機します。したがって、 `cop`タスクは`root task`と並行して実行されていると見なすことができますが、それらのデータには上流と下流の関係があります。実行プロセス中、それらはしばらくの間並行して実行されます。たとえば、最初の`cop task`は[100, 200]のデータを処理し、2番目の`cop task`は[1, 100]のデータを処理します。詳細は[TiDBクエリプランの理解](/explain-overview.md)を参照してください。 ## データベースの最適化 {#database-optimization} diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md index 250fafed4f2c1..ce1855e85d4b0 100644 --- a/faq/tidb-faq.md +++ b/faq/tidb-faq.md @@ -43,7 +43,7 @@ TiDBクラスタは、TiDBサーバー、PD（Placement Driver）サーバー、 ### TiDB は MySQL とどのように互換性がありますか? {#how-is-tidb-compatible-with-mysql} -現在、TiDBはMySQL 8.0の構文の大部分をサポートしていますが、トリガー、ストアドプロシージャ、ユーザー定義関数はサポートしていません。詳細については、 [MySQLとの互換性](/mysql-compatibility.md)参照してください。 +現在、TiDBはMySQL 8.0の構文の大部分をサポートしていますが、トリガー、ストアドプロシージャ、ユーザー定義関数はサポートしていません。詳細については、 [MySQLとの互換性](/mysql-compatibility.md)を参照してください。 ### TiDB は分散トランザクションをサポートしていますか? {#does-tidb-support-distributed-transactions} @@ -95,7 +95,7 @@ Usage of ./bin/tidb-server: - TiDB の列の最大数はデフォルトで 1017 に設定されています。この数は最大 4096 まで調整できます。 - 1行あたりの最大サイズはデフォルトで6MBです。最大120MBまで増やすことができます。 -詳細については[TiDB の制限](/tidb-limitations.md)参照してください。 +詳細については[TiDB の制限](/tidb-limitations.md)を参照してください。 ### TiDB は XA をサポートしていますか? {#does-tidb-support-xa} @@ -112,7 +112,7 @@ Atomikosの2つのデータソースを設定したら、JDBCドライブをXA ### TiFlash はどのような一貫性を提供しますか? {#what-kind-of-consistency-does-tiflash-provide} -TiFlashはデフォルトで強力なデータ整合性を維持します。ラフト学習プロセスがデータを更新します。また、クエリ内のデータがトランザクションと完全に整合していることを確認するためのTSOチェックも実行されます。詳細については、 [非同期レプリケーション](/tiflash/tiflash-overview.md#asynchronous-replication)と[一貫性](/tiflash/tiflash-overview.md#consistency)参照してください。 +TiFlashはデフォルトで強力なデータ整合性を維持します。ラフト学習プロセスがデータを更新します。また、クエリ内のデータがトランザクションと完全に整合していることを確認するためのTSOチェックも実行されます。詳細については、 [非同期レプリケーション](/tiflash/tiflash-overview.md#asynchronous-replication)と[一貫性](/tiflash/tiflash-overview.md#consistency)を参照してください。 ## TiDBテクニック {#tidb-techniques} diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md index 80530c56b5155..c7cced502f8a7 100644 --- a/faq/upgrade-faq.md +++ b/faq/upgrade-faq.md @@ -39,7 +39,7 @@ TiDBサービスにローリングアップデートを適用すると、実行 以前のバージョンからv7.4以降にアップグレードする際、JDBC URLで`connectionCollation`が設定されておらず、かつ`characterEncoding`が設定されていないか`UTF-8`に設定されている場合、アップグレード後にJDBC接続のデフォルトの照合順序が`utf8mb4_bin`から`utf8mb4_0900_ai_ci`に変更される可能性があります。照合順序を`utf8mb4_bin`に維持する必要がある場合は、JDBC URLで`connectionCollation=utf8mb4_bin`設定してください。 -詳細については[JDBC接続で使用される照合順序](/faq/sql-faq.md#collation-used-in-jdbc-connections)参照してください。 +詳細については[JDBC接続で使用される照合順序](/faq/sql-faq.md#collation-used-in-jdbc-connections)を参照してください。 ### DDL操作実行時の文字セット（charset）エラー {#the-character-set-charset-errors-when-executing-ddl-operations} diff --git a/filter-dml-event.md b/filter-dml-event.md index 711a51c0ef5ab..966de199b8def 100644 --- a/filter-dml-event.md +++ b/filter-dml-event.md @@ -12,7 +12,7 @@ summary: SQL 式を使用して DML イベントをフィルター処理する - [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) - [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) -増分データレプリケーションを実行する際に、 [Binlogイベントフィルター](/filter-binlog-event.md)使用して特定の種類のbinlogイベントをフィルタリングできます。例えば、アーカイブや監査などの目的で、 `DELETE`イベントを下流に複製しないように選択できます。ただし、 Binlogイベントフィルタは、より細かい粒度が求められる行の`DELETE`のイベントをフィルタリングするかどうかを判断できません。 +増分データレプリケーションを実行する際に、 [Binlogイベントフィルター](/filter-binlog-event.md)を使用して特定の種類のbinlogイベントをフィルタリングできます。例えば、アーカイブや監査などの目的で、 `DELETE`イベントを下流に複製しないように選択できます。ただし、 Binlogイベントフィルタは、より細かい粒度が求められる行の`DELETE`のイベントをフィルタリングするかどうかを判断できません。 この問題に対処するため、DM v2.0.5以降では、増分データレプリケーションにおいて`binlog value filter`使用したデータのフィルタリングをサポートしています。DM対応の`ROW`形式のbinlogでは、binlogイベントはすべての列の値を保持しており、これらの値に基づいてSQL式を設定できます。式で行の変更が`TRUE`と計算された場合、DMはこの行の変更を下流に複製しません。 diff --git a/follower-read.md b/follower-read.md index 905fb9be2238c..2d3a38c4a625a 100644 --- a/follower-read.md +++ b/follower-read.md @@ -9,7 +9,7 @@ TiDBでは、高可用性とデータの安全性を確保するために、TiKV -Follower Read を実行する際、TiDBはトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDBは`zone`ラベルを使用してローカルレプリカを識別します。つまり、TiDBノードの`zone`ラベルがターゲットTiKVノードの3ラベルと同じ場合、TiDBはそのレプリカをローカルレプリカと見なします。詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 +Follower Read を実行する際、TiDBはトポロジ情報に基づいて適切なレプリカを選択します。具体的には、TiDBは`zone`ラベルを使用してローカルレプリカを識別します。つまり、TiDBノードの`zone`ラベルがターゲットTiKVノードの3ラベルと同じ場合、TiDBはそのレプリカをローカルレプリカと見なします。詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 diff --git a/foreign-key.md b/foreign-key.md index d82d965c6e93b..db2667849ff8e 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`権限を付与するか、ダウンストリーム データベースに対象テーブルを事前に手動で作成して、スムーズなデータインポートを確保する必要があります。 diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md index 5336e0f6624bb..96e16c09320f0 100644 --- a/functions-and-operators/aggregate-group-by-functions.md +++ b/functions-and-operators/aggregate-group-by-functions.md @@ -87,7 +87,7 @@ summary: TiDB でサポートされている集計関数について学習しま ## GROUP BY修飾子 {#group-by-modifiers} -TiDB v7.4.0以降、 `GROUP BY`句は`WITH ROLLUP`修飾子をサポートします。詳細については、 [GROUP BY修飾子](/functions-and-operators/group-by-modifier.md)参照してください。 +TiDB v7.4.0以降、 `GROUP BY`句は`WITH ROLLUP`修飾子をサポートします。詳細については、 [GROUP BY修飾子](/functions-and-operators/group-by-modifier.md)を参照してください。 ## SQLモードのサポート {#sql-mode-support} @@ -135,7 +135,7 @@ MySQL では、 `DISTINCT`と`ORDER BY`含むクエリは、 `ORDER BY`式のい - 式は`SELECT`リストの1に等しい - 式によって参照され、クエリの選択されたテーブルに属するすべての列は、 `SELECT`リストの要素です。 -しかし、TiDB では上記のクエリは有効です。詳細については、 [＃4254](https://github.com/pingcap/tidb/issues/4254)参照してください。 +しかし、TiDB では上記のクエリは有効です。詳細については、 [＃4254](https://github.com/pingcap/tidb/issues/4254)を参照してください。 標準SQLに対するTiDBのもう一つの拡張機能は、 `HAVING`句で`SELECT`番目のリスト内のエイリアス式を参照することを許可します。例えば、次のクエリはテーブル「orders」に一度だけ出現する「name」の値を返します。 diff --git a/functions-and-operators/bit-functions-and-operators.md b/functions-and-operators/bit-functions-and-operators.md index c677541170875..4bfa2980a0dcc 100644 --- a/functions-and-operators/bit-functions-and-operators.md +++ b/functions-and-operators/bit-functions-and-operators.md @@ -275,5 +275,5 @@ MySQL 8.0 と以前のバージョンの MySQL では、ビット関数と演算 以下の場合、TiDB のクエリ結果はMySQL 5.7と同じですが、MySQL 8.0 とは異なります。 -- バイナリ引数によるビット演算。詳細については[＃30637](https://github.com/pingcap/tidb/issues/30637)参照してください。 -- `BIT_COUNT()`関数の結果。詳細については[＃44621](https://github.com/pingcap/tidb/issues/44621)参照してください。 +- バイナリ引数によるビット演算。詳細については[＃30637](https://github.com/pingcap/tidb/issues/30637)を参照してください。 +- `BIT_COUNT()`関数の結果。詳細については[＃44621](https://github.com/pingcap/tidb/issues/44621)を参照してください。 diff --git a/functions-and-operators/cast-functions-and-operators.md b/functions-and-operators/cast-functions-and-operators.md index 82d5db3398594..0499eeb01061a 100644 --- a/functions-and-operators/cast-functions-and-operators.md +++ b/functions-and-operators/cast-functions-and-operators.md @@ -25,7 +25,7 @@ MySQL 8.0.27以降、 [`BINARY`](https://dev.mysql.com/doc/refman/8.0/en/cast-fu [`CAST(<expression> AS <type> [ARRAY])`](https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html#function_cast)関数は、式を特定の型にキャストするために使用されます。 -この関数は[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)作成する場合にも使用されます。 +この関数は[多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)を作成する場合にも使用されます。 次のタイプがサポートされています: @@ -121,6 +121,6 @@ SELECT CONVERT(0x616263 USING utf8mb4); ## MySQLの互換性 {#mysql-compatibility} -- TiDBは`SPATIAL`型に対するキャスト演算をサポートしていません。詳細については[＃6347](https://github.com/pingcap/tidb/issues/6347)参照してください。 -- TiDBは`AT TIME ZONE` for `CAST()`をサポートしていません。詳細については[＃51742](https://github.com/pingcap/tidb/issues/51742)参照してください。 -- `CAST(24 AS YEAR)` TiDBでは2桁、MySQLでは4桁を返します。詳細については、 [＃29629](https://github.com/pingcap/tidb/issues/29629)参照してください。 +- TiDBは`SPATIAL`型に対するキャスト演算をサポートしていません。詳細については[＃6347](https://github.com/pingcap/tidb/issues/6347)を参照してください。 +- TiDBは`AT TIME ZONE` for `CAST()`をサポートしていません。詳細については[＃51742](https://github.com/pingcap/tidb/issues/51742)を参照してください。 +- `CAST(24 AS YEAR)` TiDBでは2桁、MySQLでは4桁を返します。詳細については、 [＃29629](https://github.com/pingcap/tidb/issues/29629)を参照してください。 diff --git a/functions-and-operators/functions-and-operators-overview.md b/functions-and-operators/functions-and-operators-overview.md index 1185c94a5eec5..a88d555fd38df 100644 --- a/functions-and-operators/functions-and-operators-overview.md +++ b/functions-and-operators/functions-and-operators-overview.md @@ -5,11 +5,11 @@ summary: 関数と演算子の使い方を学びます。 # 関数と演算子のリファレンス {#function-and-operator-reference} -TiDBの関数と演算子の使い方はMySQLと似ています。1 [MySQLの関数と演算子](https://dev.mysql.com/doc/refman/8.0/en/functions.html)参照してください。 +TiDBの関数と演算子の使い方はMySQLと似ています。1 [MySQLの関数と演算子](https://dev.mysql.com/doc/refman/8.0/en/functions.html)を参照してください。 SQL 文では、 [`SELECT`](/sql-statements/sql-statement-select.md)文の`ORDER BY`と`HAVING`句、 [`SELECT`](/sql-statements/sql-statement-select.md) / [`DELETE`](/sql-statements/sql-statement-delete.md) / [`UPDATE`](/sql-statements/sql-statement-update.md)文の`WHERE`句、 [`SET`](/sql-statements/sql-statement-set-variable.md)文で式を使用できます。 リテラル、列名、 `NULL` 、組み込み関数、演算子などを使用して式を記述できます。 -- TiDB が TiKV へのプッシュダウンをサポートする式については、 [プッシュダウンの式のリスト](/functions-and-operators/expressions-pushed-down.md)参照してください。 -- TiDB が[TiFlash](/tiflash/tiflash-overview.md)へのプッシュダウンをサポートする式については、 [プッシュダウン式](/tiflash/tiflash-supported-pushdown-calculations.md#push-down-expressions)参照してください。 +- TiDB が TiKV へのプッシュダウンをサポートする式については、 [プッシュダウンの式のリスト](/functions-and-operators/expressions-pushed-down.md)を参照してください。 +- TiDB が[TiFlash](/tiflash/tiflash-overview.md)へのプッシュダウンをサポートする式については、 [プッシュダウン式](/tiflash/tiflash-supported-pushdown-calculations.md#push-down-expressions)を参照してください。 diff --git a/functions-and-operators/group-by-modifier.md b/functions-and-operators/group-by-modifier.md index 55665b83855c7..6ae45832a1824 100644 --- a/functions-and-operators/group-by-modifier.md +++ b/functions-and-operators/group-by-modifier.md @@ -38,13 +38,13 @@ SELECT count(1) FROM t GROUP BY a,b,c WITH ROLLUP; -v8.3.0より前のTiDBでは、 [TiFlash MPPモード](/tiflash/use-tiflash-mpp-mode.md)の`WITH ROLLUP`構文に対してのみ有効な実行プランの生成がサポートされています。そのため、TiDBクラスターにはTiFlashノードが含まれており、ターゲットテーブルには正しいTiFlashレプリカが設定されている必要があります。詳細については、 [TiFlashクラスターのスケールアウト](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)参照してください。 +v8.3.0より前のTiDBでは、 [TiFlash MPPモード](/tiflash/use-tiflash-mpp-mode.md)の`WITH ROLLUP`構文に対してのみ有効な実行プランの生成がサポートされています。そのため、TiDBクラスターにはTiFlashノードが含まれており、ターゲットテーブルには正しいTiFlashレプリカが設定されている必要があります。詳細については、 [TiFlashクラスターのスケールアウト](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)を参照してください。 -v8.3.0より前のTiDBでは、 [TiFlash MPPモード](/tiflash/use-tiflash-mpp-mode.md)の`WITH ROLLUP`構文に対してのみ有効な実行プランの生成がサポートされています。そのため、TiDBクラスターにはTiFlashノードが含まれており、ターゲットテーブルには正しいTiFlashレプリカが設定されている必要があります。詳細については、 [ノード番号を変更する](/tidb-cloud/scale-tidb-cluster.md#change-node-number)参照してください。 +v8.3.0より前のTiDBでは、 [TiFlash MPPモード](/tiflash/use-tiflash-mpp-mode.md)の`WITH ROLLUP`構文に対してのみ有効な実行プランの生成がサポートされています。そのため、TiDBクラスターにはTiFlashノードが含まれており、ターゲットテーブルには正しいTiFlashレプリカが設定されている必要があります。詳細については、 [ノード番号を変更する](/tidb-cloud/scale-tidb-cluster.md#change-node-number)を参照してください。 diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index b3af3f6e13cc9..6346755be32ad 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -200,9 +200,9 @@ TABLE t1; > **注記** > -> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)有効にすることができます。 +> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)を指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)有効にすることができます。 > -> - 上の例ではIDが2ずつ増加しますが、MySQLでは同じシナリオでIDが1ずつ増加します。互換性に関する詳細は[AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)参照してください。 +> - 上の例ではIDが2ずつ増加しますが、MySQLでは同じシナリオでIDが1ずつ増加します。互換性に関する詳細は[AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)を参照してください。 `LAST_INSERT_ID(expr)`関数は式を引数として受け取り、その値を`LAST_INSERT_ID()`次回呼び出し時に保存します。MySQL互換のシーケンス生成メソッドとして使用できます。TiDBは[シーケンス関数](/functions-and-operators/sequence-functions.md)もサポートしています。 diff --git a/functions-and-operators/json-functions.md b/functions-and-operators/json-functions.md index cb128a98d9522..3579003e3fc29 100644 --- a/functions-and-operators/json-functions.md +++ b/functions-and-operators/json-functions.md @@ -77,7 +77,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを ## JSONパス {#jsonpath} -多くの JSON関数は、 [JSONパス](https://www.rfc-editor.org/rfc/rfc9535.html)使用して JSON ドキュメントの一部を選択します。 +多くの JSON関数は、 [JSONパス](https://www.rfc-editor.org/rfc/rfc9535.html)を使用して JSON ドキュメントの一部を選択します。 | シンボル | 説明 | | -------------- | --------- | @@ -139,7 +139,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを | `$**.version` | パスワイルドカードを使用したすべてのバージョン | `["v8.1.0","v8.0.0"]` | | `$.database.features[0 to 2]` | 1 番目から 3 番目までのデータベース機能の範囲。 | `["scalable","relational"]` | -詳細については[JSONPathのIETFドラフト](https://www.ietf.org/archive/id/draft-goessner-dispatch-jsonpath-00.html)参照してください。 +詳細については[JSONPathのIETFドラフト](https://www.ietf.org/archive/id/draft-goessner-dispatch-jsonpath-00.html)を参照してください。 ## 参照 {#see-also} @@ -151,7 +151,7 @@ JSON関数を使用して[JSONデータ型](/data-type-json.md)のデータを - `JSON_TABLE()` - `JSON_VALUE()` -詳細については[＃14486](https://github.com/pingcap/tidb/issues/14486)参照してください。 +詳細については[＃14486](https://github.com/pingcap/tidb/issues/14486)を参照してください。 ## MySQLの互換性 {#mysql-compatibility} diff --git a/functions-and-operators/json-functions/json-functions-utility.md b/functions-and-operators/json-functions/json-functions-utility.md index e9965079b991c..4d667981d6888 100644 --- a/functions-and-operators/json-functions/json-functions-utility.md +++ b/functions-and-operators/json-functions/json-functions-utility.md @@ -33,7 +33,7 @@ SELECT JSON_PRETTY('{"person":{"name":{"first":"John","last":"Doe"},"age":23}}') > **注記：** > -> TiDBはMySQLとは異なるstorageアーキテクチャを採用しているため、この関数は有効なJSON値に対して常に`0`返します。これは[MySQL 8.0との互換性](/mysql-compatibility.md)で実装されています。TiDBはインプレース更新を行わないことに注意してください。詳細については[RocksDB のスペース使用量](/storage-engine/rocksdb-overview.md#rocksdb-space-usage)参照してください。 +> TiDBはMySQLとは異なるstorageアーキテクチャを採用しているため、この関数は有効なJSON値に対して常に`0`返します。これは[MySQL 8.0との互換性](/mysql-compatibility.md)で実装されています。TiDBはインプレース更新を行わないことに注意してください。詳細については[RocksDB のスペース使用量](/storage-engine/rocksdb-overview.md#rocksdb-space-usage)を参照してください。 ```sql SELECT JSON_STORAGE_FREE('{}'); diff --git a/functions-and-operators/locking-functions.md b/functions-and-operators/locking-functions.md index ac4970fd8925c..b730bbcbdce69 100644 --- a/functions-and-operators/locking-functions.md +++ b/functions-and-operators/locking-functions.md @@ -20,6 +20,6 @@ TiDB は、MySQL 8.0 で利用可能なユーザー レベル[ロック関数](h ## MySQLの互換性 {#mysql-compatibility} - TiDB で許可される最小タイムアウトは 1 秒、最大タイムアウトは 1 時間 (3600 秒) です。これは、0 秒と無制限 ( `timeout=-1` ) の両方のタイムアウトが許可されている MySQL とは異なります。TiDB は範囲外の値を最も近い許容値に自動的に変換し、 `timeout=-1`は 3600 秒に変換されます。 -- TiDBは、ユーザーレベルロックによるデッドロックを自動的に検出しません。デッドロックが発生したセッションは最大1時間後にタイムアウトしますが、影響を受けたセッションのいずれかで[`KILL`](/sql-statements/sql-statement-kill.md)使用することで手動で解決することもできます。また、ユーザーレベルロックを常に同じ順序で取得することで、デッドロックを防ぐこともできます。 +- TiDBは、ユーザーレベルロックによるデッドロックを自動的に検出しません。デッドロックが発生したセッションは最大1時間後にタイムアウトしますが、影響を受けたセッションのいずれかで[`KILL`](/sql-statements/sql-statement-kill.md)を使用することで手動で解決することもできます。また、ユーザーレベルロックを常に同じ順序で取得することで、デッドロックを防ぐこともできます。 - ロックはクラスタ内のすべてのTiDBサーバーで有効になります。これは、ロックが単一のサーバーにローカルであるMySQL クラスタやグループレプリケーションとは異なります。 - `IS_USED_LOCK()` 、別のセッションから呼び出され、ロックを保持しているプロセスの ID を返すことができない場合は`1`返します。 diff --git a/functions-and-operators/precision-math.md b/functions-and-operators/precision-math.md index 690b9942bcb54..df762cc374bfe 100644 --- a/functions-and-operators/precision-math.md +++ b/functions-and-operators/precision-math.md @@ -5,7 +5,7 @@ summary: TiDB の高精度計算について学びます。 # 精密計算 {#precision-math} -TiDBの高精度演算サポートはMySQLと一致しています。詳細については、 [MySQL における精密計算](https://dev.mysql.com/doc/refman/8.0/en/precision-math.html)参照してください。 +TiDBの高精度演算サポートはMySQLと一致しています。詳細については、 [MySQL における精密計算](https://dev.mysql.com/doc/refman/8.0/en/precision-math.html)を参照してください。 ## 数値型 {#numeric-types} @@ -50,7 +50,7 @@ DECIMAL列には、先頭の`+`文字目、 `-`文字目、または先頭の`0` DECIMAL列では、列定義で指定された範囲を超える値は許可されません。例えば、 `DECIMAL(3,0)`列は`-999`から`999`までの範囲をサポートします。7 `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 19eaecad26813..06ed45c635d61 100644 --- a/functions-and-operators/string-functions.md +++ b/functions-and-operators/string-functions.md @@ -9,7 +9,7 @@ TiDB は、MySQL 8.0 で利用可能な[文字列関数](https://dev.mysql.com/d -Oracle と TiDB の関数と構文の比較については、 [Oracle と TiDB の機能と構文の比較](/oracle-functions-to-tidb.md)参照してください。 +Oracle と TiDB の関数と構文の比較については、 [Oracle と TiDB の機能と構文の比較](/oracle-functions-to-tidb.md)を参照してください。 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index 692ea2683b124..b28cf18dcda54 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -11,8 +11,8 @@ summary: TiDB 固有の関数の使用法について学習します。 | 関数名 | 機能の説明 | | :------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 | -| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)参照してください。 | +| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループの名前を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 | +| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)を参照してください。 | | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 現在の[TiDB のタイムスタンプ Oracle (TSO)](/tso.md)を返します。 | | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | @@ -36,8 +36,8 @@ summary: TiDB 固有の関数の使用法について学習します。 | 関数名 | 機能の説明 | | :------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループ名を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 | -| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)参照してください。 | +| [`CURRENT_RESOURCE_GROUP()`](#current_resource_group) | 現在のセッションがバインドされているリソースグループ名を返します。1 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 | +| [`TIDB_BOUNDED_STALENESS()`](#tidb_bounded_staleness) | 指定された時間範囲内の最新のデータを読み取るようTiDBに指示します。1 [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md)を参照してください。 | | [`TIDB_CURRENT_TSO()`](#tidb_current_tso) | 現在の[TiDB のタイムスタンプ Oracle (TSO)](/tso.md)を返します。 | | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | @@ -61,7 +61,7 @@ summary: TiDB 固有の関数の使用法について学習します。 `CURRENT_RESOURCE_GROUP()`機能は、現在のセッションがバインドされているリソースグループ名を表示するために使用されます。3 [リソース管理](/tidb-resource-control-ru-groups.md)機能を有効にすると、SQL ステートメントで使用できるリソースは、バインドされているリソースグループのリソースクォータによって制限されます。 -セッションが確立されると、TiDB はログインユーザーがデフォルトでバインドされているリソースグループにセッションをバインドします。ユーザーがどのリソースグループにもバインドされていない場合、セッションは`default`リソースグループにバインドされます。セッションが確立されると、ユーザーのバインドされているリソースグループが[ユーザーにバインドされたリソースグループを変更する](/sql-statements/sql-statement-alter-user.md#modify-basic-user-information)で変更されても、バインドされているリソースグループはデフォルトで変更されません。現在のセッションのバインドされているリソースグループを変更するには、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)使用します。 +セッションが確立されると、TiDB はログインユーザーがデフォルトでバインドされているリソースグループにセッションをバインドします。ユーザーがどのリソースグループにもバインドされていない場合、セッションは`default`リソースグループにバインドされます。セッションが確立されると、ユーザーのバインドされているリソースグループが[ユーザーにバインドされたリソースグループを変更する](/sql-statements/sql-statement-alter-user.md#modify-basic-user-information)で変更されても、バインドされているリソースグループはデフォルトで変更されません。現在のセッションのバインドされているリソースグループを変更するには、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)を使用します。 例: @@ -292,7 +292,7 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR > **注記：** > > - この機能を使用できるのは、 [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみです。 -> - `TIDB_DECODE_SQL_DIGESTS`実行すると、TiDB は各 SQL ダイジェストに対応するステートメントをステートメントサマリーテーブルから照会します。そのため、どの SQL ダイジェストに対しても、必ず対応するステートメントが見つかるとは限りません。見つかるのはクラスタ内で実行されたステートメントのみであり、これらの SQL ステートメントを照会できるかどうかは、ステートメントサマリーテーブルの関連設定にも影響されます。ステートメントサマリーテーブルの詳細については、 [明細書要約表](/statement-summary-tables.md)参照してください。 +> - `TIDB_DECODE_SQL_DIGESTS`実行すると、TiDB は各 SQL ダイジェストに対応するステートメントをステートメントサマリーテーブルから照会します。そのため、どの SQL ダイジェストに対しても、必ず対応するステートメントが見つかるとは限りません。見つかるのはクラスタ内で実行されたステートメントのみであり、これらの SQL ステートメントを照会できるかどうかは、ステートメントサマリーテーブルの関連設定にも影響されます。ステートメントサマリーテーブルの詳細については、 [明細書要約表](/statement-summary-tables.md)を参照してください。 > - この関数はオーバーヘッドが大きいため、行数の多いクエリ（例えば、大規模で高負荷なクラスターでテーブル`information_schema.cluster_tidb_trx`全体を検索するなど）では、この関数を使用するとクエリの実行時間が長くなりすぎる可能性があります。注意して使用してください。 > - この関数は、呼び出されるたびに内部的に`STATEMENTS_SUMMARY` 、 `STATEMENTS_SUMMARY_HISTORY` 、 `CLUSTER_STATEMENTS_SUMMARY` 、 `CLUSTER_STATEMENTS_SUMMARY_HISTORY`テーブルを照会し、そのクエリに`UNION`演算が含まれるため、オーバーヘッドが大きくなります。この関数は現在ベクトル化をサポートしていません。つまり、複数行のデータに対してこの関数を呼び出す場合、上記のクエリは各行ごとに個別に実行されます。 diff --git a/functions-and-operators/window-functions.md b/functions-and-operators/window-functions.md index 9e2e1bda5e9b2..bd9f8dd7386fb 100644 --- a/functions-and-operators/window-functions.md +++ b/functions-and-operators/window-functions.md @@ -5,7 +5,7 @@ summary: このドキュメントでは、TiDB でサポートされているウ # ウィンドウ関数 {#window-functions} -TiDBにおけるウィンドウ関数の使用方法は、MySQL 8.0と同様です。詳細については[MySQL ウィンドウ関数](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html)参照してください。 +TiDBにおけるウィンドウ関数の使用方法は、MySQL 8.0と同様です。詳細については[MySQL ウィンドウ関数](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html)を参照してください。 TiDB では、次のシステム変数を使用してウィンドウ関数を制御できます。 diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index c71a9adc4bdd9..15c2ad895868b 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -14,7 +14,7 @@ summary: GC 構成パラメータについて学習します。 - [`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 セーフ ポイントをブロックする最大時間を指定します。 -システム変数の値を変更する方法の詳細については、 [システム変数](/system-variables.md)参照してください。 +システム変数の値を変更する方法の詳細については、 [システム変数](/system-variables.md)を参照してください。 ## GC I/O制限 {#gc-i-o-limit} diff --git a/generated-columns.md b/generated-columns.md index 6d2b53d1cf5b5..c041109b785a3 100644 --- a/generated-columns.md +++ b/generated-columns.md @@ -94,7 +94,7 @@ ERROR 1048 (23000): Column 'city' cannot be null クエリ内の式がインデックス付きの生成列と厳密に同等である場合、TiDB は式を対応する生成列に置き換え、実行プランの構築時にオプティマイザーがそのインデックスを考慮できるようにします。 -次の例では、式`a+1`に対して生成列を作成し、インデックスを追加します。列`a`の型はint、列`a+1`の型はbigintです。生成列の型がintに設定されている場合、置換は行われません。型変換ルールについては、 [式評価の型変換](/functions-and-operators/type-conversion-in-expression-evaluation.md)参照してください。 +次の例では、式`a+1`に対して生成列を作成し、インデックスを追加します。列`a`の型はint、列`a+1`の型はbigintです。生成列の型がintに設定されている場合、置換は行われません。型変換ルールについては、 [式評価の型変換](/functions-and-operators/type-conversion-in-expression-evaluation.md)を参照してください。 ```sql create table t(a int); @@ -131,7 +131,7 @@ desc select a+1 from t where a+1=3; > **注記：** > -> 置換対象の式と生成列の両方が文字列型で長さが異なる場合でも、システム変数[`tidb_enable_unsafe_substitute`](/system-variables.md#tidb_enable_unsafe_substitute-new-in-v630)を`ON`に設定することで式を置換できます。このシステム変数を設定する際は、生成列によって計算される値が生成列の定義を厳密に満たしていることを確認してください。そうでない場合、長さの違いによりデータが切り捨てられ、誤った結果になる可能性があります。GitHub の問題[＃35490](https://github.com/pingcap/tidb/issues/35490#issuecomment-1211658886)参照してください。 +> 置換対象の式と生成列の両方が文字列型で長さが異なる場合でも、システム変数[`tidb_enable_unsafe_substitute`](/system-variables.md#tidb_enable_unsafe_substitute-new-in-v630)を`ON`に設定することで式を置換できます。このシステム変数を設定する際は、生成列によって計算される値が生成列の定義を厳密に満たしていることを確認してください。そうでない場合、長さの違いによりデータが切り捨てられ、誤った結果になる可能性があります。GitHub の問題[＃35490](https://github.com/pingcap/tidb/issues/35490#issuecomment-1211658886)を参照してください。 ## 制限事項 {#limitations} @@ -141,7 +141,7 @@ JSON と生成された列の現在の制限は次のとおりです。 - `ALTER TABLE`文を使用して、保存された生成列を通常の列に変換したり、通常の列を保存された生成列に変換したりすることはできません。 - 保存された生成列の式を`ALTER TABLE`ステートメントを通じて変更することはできません。 - [JSON関数](/functions-and-operators/json-functions.md)すべてがサポートされているわけではありません。 -- [`NULLIF()`関数](/functions-and-operators/control-flow-functions.md#nullif)サポートされていません。代わりに[`CASE`関数](/functions-and-operators/control-flow-functions.md#case)使用してください。 +- [`NULLIF()`関数](/functions-and-operators/control-flow-functions.md#nullif)サポートされていません。代わりに[`CASE`関数](/functions-and-operators/control-flow-functions.md#case)を使用してください。 - 現在、生成列インデックスの置換ルールは、生成列が仮想生成列である場合にのみ有効です。保存された生成列には適用されませんが、生成列自体を直接使用することでインデックスを使用することは可能です。 - 次の関数と式は生成された列の定義では許可されておらず、使用すると TiDB によってエラーが返されます。 diff --git a/geo-distributed-deployment-topology.md b/geo-distributed-deployment-topology.md index 5a3bde9a7ef1a..a982f4ced57f4 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} @@ -93,9 +93,9 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 > **注記：** > - > TiDB 5.2以降、 `label-property`構成はデフォルトではサポートされません。レプリカポリシーを設定するには、 [配置ルール](/configure-placement-rules.md)使用してください。 + > TiDB 5.2以降、 `label-property`構成はデフォルトではサポートされません。レプリカポリシーを設定するには、 [配置ルール](/configure-placement-rules.md)を使用してください。 -ラベルとRaftグループのレプリカの数に関する詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 +ラベルとRaftグループのレプリカの数に関する詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 > **注記：** > diff --git a/glossary.md b/glossary.md index 2bf4423b4f092..4bad41ce7eb9e 100644 --- a/glossary.md +++ b/glossary.md @@ -25,7 +25,7 @@ ACIDとは、トランザクションの4つの主要な特性、すなわち原 - **一貫性と**は、トランザクションによってデータベースが常に一貫性のある状態から別の一貫性のある状態へと移行することを意味します。TiDBでは、メモリにデータを書き込む前にデータの一貫性が確保されます。 -- **分離とは**、処理中のトランザクションが完了するまで他のトランザクションから見えないことを意味します。これにより、同時実行トランザクションは一貫性を損なうことなくデータの読み書きを行うことができます。詳細については、 [TiDBトランザクション分離レベル](/transaction-isolation-levels.md#tidb-transaction-isolation-levels)参照してください。 +- **分離とは**、処理中のトランザクションが完了するまで他のトランザクションから見えないことを意味します。これにより、同時実行トランザクションは一貫性を損なうことなくデータの読み書きを行うことができます。詳細については、 [TiDBトランザクション分離レベル](/transaction-isolation-levels.md#tidb-transaction-isolation-levels)を参照してください。 - **永続性**とは、一度トランザクションがコミットされると、システム障害が発生した場合でもコミットされた状態が維持されることを意味します。TiKVは永続ストレージを使用して永続性を確保しています。 @@ -33,7 +33,7 @@ ACIDとは、トランザクションの4つの主要な特性、すなわち原 ### Backup & Restore (BR) {#backup-x26-restore-br} -BRは TiDB のバックアップおよび復元ツールです。詳細については[BR概要](/br/backup-and-restore-overview.md)参照してください。 +BRは TiDB のバックアップおよび復元ツールです。詳細については[BR概要](/br/backup-and-restore-overview.md)を参照してください。 TiDBでは、 `br`はバックアップまたはリストアに使用される[br コマンドラインツール](/br/use-br-command-line-tool.md)です。 @@ -65,11 +65,11 @@ TiDBデータベースの分散アーキテクチャでは： - PDノードは、TiDBに対して堅牢なメタデータレイヤーを提供する。 - TiKVノードは、 Raftプロトコルを使用することで、TiDB向けに高可用性、拡張性、および耐障害性に優れたストレージを提供します。 -詳細については、 [TiDBアーキテクチャ](/tidb-architecture.md)参照してください。 +詳細については、 [TiDBアーキテクチャ](/tidb-architecture.md)を参照してください。 ### パーティションを合体させる {#coalesce-partition} -パーティションの結合は、ハッシュまたはキーでパーティションテーブルのパーティション数を減らす方法です。詳細については、 [ハッシュとキーのパーティションを管理する](/partitioned-table.md#manage-hash-and-key-partitions)参照してください。 +パーティションの結合は、ハッシュまたはキーでパーティションテーブルのパーティション数を減らす方法です。詳細については、 [ハッシュとキーのパーティションを管理する](/partitioned-table.md#manage-hash-and-key-partitions)を参照してください。 ### カラムファミリー（CF） {#column-family-cf} @@ -77,11 +77,11 @@ RocksDBとTiKVでは、カラムファミリー（CF）は、データベース ### 共通テーブル式（CTE） {#common-table-expression-cte} -共通テーブル式 (CTE) を使用すると、 [`WITH`](/sql-statements/sql-statement-with.md)句を使用して SQL ステートメント内で複数回参照できる一時的な結果セットを定義できます。これにより、ステートメントの可読性と実行効率が向上します。詳細については、 [共通テーブル式](/develop/dev-guide-use-common-table-expression.md)参照してください。 +共通テーブル式 (CTE) を使用すると、 [`WITH`](/sql-statements/sql-statement-with.md)句を使用して SQL ステートメント内で複数回参照できる一時的な結果セットを定義できます。これにより、ステートメントの可読性と実行効率が向上します。詳細については、 [共通テーブル式](/develop/dev-guide-use-common-table-expression.md)を参照してください。 ### 継続的なプロファイリング {#continuous-profiling} -継続的プロファイリングは、システムコールレベルでのリソースオーバーヘッドを監視する方法です。継続的プロファイリングを使用すると、TiDB はパフォーマンスの問題をきめ細かく監視し、フレームグラフを使用して運用チームが根本原因を特定するのに役立ちます。詳細については、 [TiDB Dashboardインスタンスプロファイリング - 継続的プロファイリング](/dashboard/continuous-profiling.md)参照してください。 +継続的プロファイリングは、システムコールレベルでのリソースオーバーヘッドを監視する方法です。継続的プロファイリングを使用すると、TiDB はパフォーマンスの問題をきめ細かく監視し、フレームグラフを使用して運用チームが根本原因を特定するのに役立ちます。詳細については、 [TiDB Dashboardインスタンスプロファイリング - 継続的プロファイリング](/dashboard/continuous-profiling.md)を参照してください。 ### コプロセッサー {#coprocessor} @@ -93,15 +93,15 @@ RocksDBとTiKVでは、カラムファミリー（CF）は、データベース Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータをSQLまたはCSVデータファイルとしてエクスポートするためのデータエクスポートツールです。論理的なフルバックアップやエクスポートにも使用できます。さらに、 DumplingはAmazon S3へのデータエクスポートもサポートしています。 -詳細については、 [Dumplingを使用してデータをエクスポートする](/dumpling-overview.md)参照してください。 +詳細については、 [Dumplingを使用してデータをエクスポートする](/dumpling-overview.md)を参照してください。 ### データ定義言語（DDL） {#data-definition-language-ddl} -データ定義言語（DDL）は、テーブルやその他のオブジェクトの作成、変更、削除を扱うSQL標準の一部です。詳細については、 [DDL入門](/best-practices/ddl-introduction.md)参照してください。 +データ定義言語（DDL）は、テーブルやその他のオブジェクトの作成、変更、削除を扱うSQL標準の一部です。詳細については、 [DDL入門](/best-practices/ddl-introduction.md)を参照してください。 ### データ移行（DM） {#data-migration-dm} -データ移行 (DM) は、MySQL 互換データベースから TiDB へデータを移行するためのツールです。DM は、MySQL 互換データベースインスタンスからデータを読み込み、TiDB ターゲットインスタンスに適用します。詳細については、 [DMの概要](/dm/dm-overview.md)参照してください。 +データ移行 (DM) は、MySQL 互換データベースから TiDB へデータを移行するためのツールです。DM は、MySQL 互換データベースインスタンスからデータを読み込み、TiDB ターゲットインスタンスに適用します。詳細については、 [DMの概要](/dm/dm-overview.md)を参照してください。 ### データ変更言語（DML） {#data-modification-language-dml} @@ -109,15 +109,15 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### 開発マイルストーンリリース（DMR） {#development-milestone-release-dmr} -開発マイルストーンリリース（DMR）は、最新の機能を導入するTiDBリリースですが、長期サポートは提供されません。詳細については、 [TiDB バージョン管理](/releases/versioning.md)参照してください。 +開発マイルストーンリリース（DMR）は、最新の機能を導入するTiDBリリースですが、長期サポートは提供されません。詳細については、 [TiDB バージョン管理](/releases/versioning.md)を参照してください。 ### 災害復旧（DR） {#disaster-recovery-dr} -ディザスターリカバリー（DR）には、将来発生する災害からデータやサービスを復旧するために使用できるソリューションが含まれます。TiDB は、バックアップやスタンバイクラスタへのレプリケーションなど、さまざまなディザスターリカバリーソリューションを提供しています。詳細については、 [TiDB災害復旧ソリューションの概要](/dr-solution-introduction.md)参照してください。 +ディザスターリカバリー（DR）には、将来発生する災害からデータやサービスを復旧するために使用できるソリューションが含まれます。TiDB は、バックアップやスタンバイクラスタへのレプリケーションなど、さまざまなディザスターリカバリーソリューションを提供しています。詳細については、 [TiDB災害復旧ソリューションの概要](/dr-solution-introduction.md)を参照してください。 ### 分散実行フレームワーク（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} @@ -129,13 +129,13 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ 式インデックスは、式に基づいて作成される特殊なタイプのインデックスです。式インデックスが作成されると、TiDBはこのインデックスを式ベースのクエリに使用できるようになり、クエリのパフォーマンスが大幅に向上します。 -詳細については、 [インデックスの作成 -式インデックス or 関数インデックス](/sql-statements/sql-statement-create-index.md#expression-index)参照してください。 +詳細については、 [インデックスの作成 -式インデックス or 関数インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 ## G {#a-id-g-class-letter-href-g-g-a} ### ガベージコレクション（GC） {#garbage-collection-gc} -ガベージコレクション（GC）は、不要になったデータをクリアしてリソースを解放するプロセスです。TiKV GC プロセスについては、 [GCの概要](/garbage-collection-overview.md)参照してください。 +ガベージコレクション（GC）は、不要になったデータをクリアしてリソースを解放するプロセスです。TiKV GC プロセスについては、 [GCの概要](/garbage-collection-overview.md)を参照してください。 ### 一般提供開始（GA） {#general-availability-ga} @@ -149,11 +149,11 @@ Dumplingは、TiDB、MySQL、またはMariaDBに保存されているデータ ### ホットスポット {#hotspot} -ホットスポットとは、TiKV の読み取りおよび書き込みワークロードが 1 つまたは少数のリージョンまたはノードに集中している状況を指します。これによりパフォーマンスのボトルネックが発生し、最適なシステムパフォーマンスが妨げられる可能性があります。ホットスポットの問題を解決するには、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)参照してください。 +ホットスポットとは、TiKV の読み取りおよび書き込みワークロードが 1 つまたは少数のリージョンまたはノードに集中している状況を指します。これによりパフォーマンスのボトルネックが発生し、最適なシステムパフォーマンスが妨げられる可能性があります。ホットスポットの問題を解決するには、 [ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)を参照してください。 ### ハイブリッドトランザクション・分析処理（HTAP） {#hybrid-transactional-and-analytical-processing-htap} -ハイブリッドトランザクションおよび分析処理（HTAP）は、同一データベース内でOLTP（オンライントランザクション処理）とOLAP（オンライン分析処理）の両方のワークロードを可能にするデータベース機能です。TiDBでは、行ストレージにTiKV、列ストレージにTiFlashを使用することでHTAP機能が提供されます。詳細については、 [TiDB HTAPクイックスタート](/quick-start-with-htap.md)および[HTAPを探索する](/explore-htap.md)参照してください。 +ハイブリッドトランザクションおよび分析処理（HTAP）は、同一データベース内でOLTP（オンライントランザクション処理）とOLAP（オンライン分析処理）の両方のワークロードを可能にするデータベース機能です。TiDBでは、行ストレージにTiKV、列ストレージにTiFlashを使用することでHTAP機能が提供されます。詳細については、 [TiDB HTAPクイックスタート](/quick-start-with-htap.md)および[HTAPを探索する](/explore-htap.md)を参照してください。 ## 私 {#a-id-i-class-letter-href-i-i-a} @@ -193,13 +193,13 @@ Raftグループ（ [仲間](#regionpeerraft-group)構成）では、Leader、Fo ### 長期サポート（LTS） {#long-term-support-lts} -長期サポート (LTS) とは、長期間にわたって徹底的にテストおよびメンテナンスされるソフトウェア バージョンを指します。詳細については、 [TiDB バージョン管理](/releases/versioning.md)参照してください。 +長期サポート (LTS) とは、長期間にわたって徹底的にテストおよびメンテナンスされるソフトウェア バージョンを指します。詳細については、 [TiDB バージョン管理](/releases/versioning.md)を参照してください。 ## M {#a-id-m-class-letter-href-m-m-a} ### 超並列処理（MPP） {#massively-parallel-processing-mpp} -TiDBはv5.0以降、 TiFlashノードを介して大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算を実行するためにMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中にExchange操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算が高速化されます。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)参照してください。 +TiDBはv5.0以降、 TiFlashノードを介して大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算を実行するためにMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中にExchange操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算が高速化されます。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 ### マルチバージョン同時実行制御 (MVCC) {#multi-version-concurrency-control-mvcc} @@ -221,7 +221,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 ### メモリ不足 (OOM) {#out-of-memory-oom} -メモリ不足 (OOM) は、メモリ不足によりシステムが故障する状況です。詳細については、 [TiDBのメモリ不足問題​​のトラブルシューティング](/troubleshoot-tidb-oom.md)参照してください。 +メモリ不足 (OOM) は、メモリ不足によりシステムが故障する状況です。詳細については、 [TiDBのメモリ不足問題​​のトラブルシューティング](/troubleshoot-tidb-oom.md)を参照してください。 ### オペレーター {#operator} @@ -246,7 +246,7 @@ TiCDCが出力する増分変更ログにおける「元の値」。TiCDCが出 楽観的トランザクションとは、楽観的並行性制御を使用するトランザクションであり、一般的に並行環境で競合を引き起こしません。楽観的トランザクションを有効にすると、TiDB はトランザクションが最終的にコミットされたときにのみ競合チェックを行います。楽観的トランザクションモードは、読み取りが多く書き込みが少ない並行シナリオに適しており、TiDB のパフォーマンスを向上させることができます。 -詳細については、 [TiDBの楽観的トランザクションモデル](/optimistic-transaction.md)参照してください。 +詳細については、 [TiDBの楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 ## P {#a-id-p-class-letter-href-p-p-a} @@ -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} @@ -264,13 +264,13 @@ PD Control (pd-ctl) は、TiDB クラスタ内の Placement Driver (PD) と対 ### Placement Driver（PD） {#placement-driver-pd} -Placement Driver(PD) は、メタデータの保存、トランザクション タイムスタンプの[タイムスタンプオラクル（TSO）](/tso.md) 、TiKV 上でのデータ配置の調整、および[TiDB Dashboard](/dashboard/dashboard-overview.md)実行を担当する[TiDBアーキテクチャ](/tidb-architecture.md#placement-driver-pd-server)の中核コンポーネントです。詳細については、 [TiDBスケジューリング](/tidb-scheduling.md)参照してください。 +Placement Driver(PD) は、メタデータの保存、トランザクション タイムスタンプの[タイムスタンプオラクル（TSO）](/tso.md) 、TiKV 上でのデータ配置の調整、および[TiDB Dashboard](/dashboard/dashboard-overview.md)実行を担当する[TiDBアーキテクチャ](/tidb-architecture.md#placement-driver-pd-server)の中核コンポーネントです。詳細については、 [TiDBスケジューリング](/tidb-scheduling.md)を参照してください。 ### 配置ルール {#placement-rules} 配置ルールは、TiKVクラスタにおけるデータの配置を設定するために使用されます。この機能を使用すると、テーブルとパーティションを異なるリージョン、データセンター、キャビネット、またはホストに展開するように指定できます。使用例としては、低コストでデータ可用性戦略を最適化すること、ローカルの古いデータの読み取りのためにローカルデータレプリカが利用可能であることを保証すること、およびローカルのデータコンプライアンス要件に準拠することなどが挙げられます。 -詳細については、 [SQLにおける配置ルール](/placement-rules-in-sql.md)参照してください。 +詳細については、 [SQLにおける配置ルール](/placement-rules-in-sql.md)を参照してください。 ### PointGet {#point-get} @@ -278,7 +278,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ ### 特定時点復旧（PITR） {#point-in-time-recovery-pitr} -ポイントインタイムリカバリ（PITR）を使用すると、データを特定の時点（たとえば、意図しない`DELETE`の直前）に復元できます。詳細については、 [TiDBログバックアップとPITRアーキテクチャ](/br/br-log-architecture.md)参照してください。 +ポイントインタイムリカバリ（PITR）を使用すると、データを特定の時点（たとえば、意図しない`DELETE`の直前）に復元できます。詳細については、 [TiDBログバックアップとPITRアーキテクチャ](/br/br-log-architecture.md)を参照してください。 ### 述語列 {#predicate-columns} @@ -298,7 +298,7 @@ PointGetとは、一意インデックスまたは主インデックスによっ ### Raft Engine {#raft-engine} -Raft Engine は、ログ構造設計の組み込み型永続ストレージエンジンです。TiKV 用に構築されており、複数の Raft ログを保存します。v5.4 以降、TiDB はRaft Engine をログストレージエンジンとして使用することをサポートしています。詳細については、 [Raft Engine](/tikv-configuration-file.md#raft-engine)参照してください。 +Raft Engine は、ログ構造設計の組み込み型永続ストレージエンジンです。TiKV 用に構築されており、複数の Raft ログを保存します。v5.4 以降、TiDB はRaft Engine をログストレージエンジンとして使用することをサポートしています。詳細については、 [Raft Engine](/tikv-configuration-file.md#raft-engine)を参照してください。 ### リージョン分割 {#region-split} @@ -341,13 +341,13 @@ TiKV におけるデータストレージの最小単位はリージョンであ セキュリティ強化モード（SEM）は、TiDB管理者の権限をより細かく制御するために使用されます。1 [セキュリティ強化Linux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)のシステムに触発されたSEMは、 `SUPER`権限を持つユーザーの機能を制限し、代わりに`RESTRICTED`つのきめ細かい権限を必要とします。これらの権限は、特定の管理アクションを制御するために明示的に付与される必要があります。 -詳細については、 [システム変数に関するドキュメント - `tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)参照してください。 +詳細については、 [システム変数に関するドキュメント - `tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)を参照してください。 ### ステイル読み取り {#stale-read} ステイル読み取りは、TiDBに保存されているデータの履歴バージョンを読み取るためにTiDBが適用するメカニズムです。このメカニズムを使用すると、特定の時点または指定された期間内の対応する履歴データを読み取ることができ、ストレージノード間のデータ複製によって発生するレイテンシーを削減できます。Stale ステイル読み取りを使用する場合、TiDBはデータ読み取り用にレプリカをランダムに選択するため、すべてのレプリカがデータ読み取りに使用可能になります。 -詳細については、 [ステイル読み取り](/stale-read.md)参照してください。 +詳細については、 [ステイル読み取り](/stale-read.md)を参照してください。 ### 静的ソート済みテーブル／ソート済み文字列テーブル（SST） {#static-sorted-table-sorted-string-table-sst} @@ -363,17 +363,17 @@ TiKV におけるデータストレージの最小単位はリージョンであ 一時テーブルを使用すると、中間計算結果を一時的に保存できるため、テーブルの作成と削除を繰り返す必要がなくなります。データが不要になると、TiDB は一時テーブルを自動的にクリーンアップして再利用します。この機能により、アプリケーションロジックが簡素化され、テーブル管理のオーバーヘッドが削減され、パフォーマンスが向上します。 -詳細については、 [一時テーブル](/temporary-tables.md)参照してください。 +詳細については、 [一時テーブル](/temporary-tables.md)を参照してください。 ### TiCDC {#ticdc} -TiCDC は、TiDB からさまざまなダウンストリーム ターゲットへの増分データ レプリケーションを可能にするツール[TiCDC](/ticdc/ticdc-overview.md) 。これらのダウンストリーム ターゲットには、他の TiDB インスタンス、MySQL 互換データベース、ストレージサービス、ストリーミング プロセッサ (Kafka や Pulsar など) が含まれます。TiCDC は、アップストリーム TiKV からデータ変更ログを取得し、それを順序付き行レベル変更データに解析し、ダウンストリームにデータを出力します。TiCDC の概念と用語の詳細については、 [TiCDC用語集](/ticdc/ticdc-glossary.md)参照してください。 +TiCDC は、TiDB からさまざまなダウンストリーム ターゲットへの増分データ レプリケーションを可能にするツール[TiCDC](/ticdc/ticdc-overview.md) 。これらのダウンストリーム ターゲットには、他の TiDB インスタンス、MySQL 互換データベース、ストレージサービス、ストリーミング プロセッサ (Kafka や Pulsar など) が含まれます。TiCDC は、アップストリーム TiKV からデータ変更ログを取得し、それを順序付き行レベル変更データに解析し、ダウンストリームにデータを出力します。TiCDC の概念と用語の詳細については、 [TiCDC用語集](/ticdc/ticdc-glossary.md)を参照してください。 ### TiDB Lightning {#tidb-lightning} [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)は、テラバイト規模のデータを静的ファイルからTiDBクラスタにインポートするためのツールです。TiDBクラスタへの初期データインポートによく使用されます。 -TiDB Lightningの概念と用語の詳細については、 [TiDB Lightning用語集](/tidb-lightning/tidb-lightning-glossary.md)参照してください。 +TiDB Lightningの概念と用語の詳細については、 [TiDB Lightning用語集](/tidb-lightning/tidb-lightning-glossary.md)を参照してください。 ### TiFlash {#tiflash} @@ -385,7 +385,7 @@ TiDB Lightningの概念と用語の詳細については、 [TiDB Lightning用 ### タイムスタンプオラクル（TSO） {#timestamp-oracle-tso} -TiKVは分散ストレージシステムであるため、単調増加するタイムスタンプを割り当てるためのグローバルタイミングサービスであるタイムスタンプオラクル（TSO）が必要です。TiKVでは、この機能はPDによって提供され、Google [Spanner](http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf)では、この機能は複数のアトミック時計とGPSによって提供されます。詳細については、 [TSO](/tso.md)参照してください。 +TiKVは分散ストレージシステムであるため、単調増加するタイムスタンプを割り当てるためのグローバルタイミングサービスであるタイムスタンプオラクル（TSO）が必要です。TiKVでは、この機能はPDによって提供され、Google [Spanner](http://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf)では、この機能は複数のアトミック時計とGPSによって提供されます。詳細については、 [TSO](/tso.md)を参照してください。 ### TiUP {#tiup} @@ -393,7 +393,7 @@ TiUP[TiUP](/tiup/tiup-overview.md)は、TiDB クラスタのデプロイ、ア ### Top SQL {#top-sql} -Top SQLは、指定された時間範囲内でTiDBまたはTiKVノードの負荷を高める原因となっているSQLクエリを特定するのに役立ちます。詳細については、 [Top SQLドキュメント](/dashboard/top-sql.md)参照してください。 +Top SQLは、指定された時間範囲内でTiDBまたはTiKVノードの負荷を高める原因となっているSQLクエリを特定するのに役立ちます。詳細については、 [Top SQLドキュメント](/dashboard/top-sql.md)を参照してください。 ### 1秒あたりのトランザクション数（TPS） {#transactions-per-second-tps} @@ -403,11 +403,11 @@ Top SQLは、指定された時間範囲内でTiDBまたはTiKVノードの負 ### 統一リソース識別子（URI） {#uniform-resource-identifier-uri} -URI（Uniform Resource Identifier）は、リソースを識別するための標準化された形式です。詳細については、Wikipediaの[統一リソース識別子](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier)参照してください。 +URI（Uniform Resource Identifier）は、リソースを識別するための標準化された形式です。詳細については、Wikipediaの[統一リソース識別子](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier)を参照してください。 ### ユニバーサル一意識別子（UUID） {#universally-unique-identifier-uuid} -UUID（Universally Unique Identifier）は、データベース内のレコードを一意に識別するために使用される128ビット（16バイト）の生成されたIDです。詳細については、 [UUID](/best-practices/uuid.md)参照してください。 +UUID（Universally Unique Identifier）は、データベース内のレコードを一意に識別するために使用される128ビット（16バイト）の生成されたIDです。詳細については、 [UUID](/best-practices/uuid.md)を参照してください。 ## V {#a-id-v-class-letter-href-v-v-a} diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index b2c42ee3a31f6..7e169d1d1633a 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -5,7 +5,7 @@ summary: Grafana の概要ダッシュボードに表示されるいくつかの # 主要な指標 {#key-metrics} -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、Disk Performance、Performance_overviewといった一連のサブダッシュボードに分かれています。診断に役立つ多くの指標が用意されています。 diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 058013252f195..6aa3bd7a5ebac 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -5,7 +5,7 @@ summary: Grafana PD ダッシュボードに表示されるいくつかの主要 # PDの主要なモニタリング指標 {#key-monitoring-metrics-of-pd} -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporter、Disk Performance、Performance_overviewといった一連のサブダッシュボードに分かれています。診断に役立つ多くの指標が用意されています。 diff --git a/grafana-performance-overview-dashboard.md b/grafana-performance-overview-dashboard.md index a669748df2459..e34eb2c1f6609 100644 --- a/grafana-performance-overview-dashboard.md +++ b/grafana-performance-overview-dashboard.md @@ -5,7 +5,7 @@ summary: パフォーマンス概要ダッシュボードに表示される主 # パフォーマンス概要の主要指標 {#key-metrics-on-performance-overview} -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafanaダッシュボードは、PD、TiDB、TiKV、Node_exporter、概要、パフォーマンス概要を含む一連のサブダッシュボードに分かれています。診断に役立つ多くのメトリックが用意されています。 diff --git a/grafana-resource-control-dashboard.md b/grafana-resource-control-dashboard.md index 715650dfe473f..0232dc7653315 100644 --- a/grafana-resource-control-dashboard.md +++ b/grafana-resource-control-dashboard.md @@ -5,13 +5,13 @@ summary: Grafana Resource Control ダッシュボードに表示される主要 # リソース管理の主要な監視指標 {#key-monitoring-metrics-of-resource-control} -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafana ダッシュボードは、概要、PD、TiDB、TiKV、Node_exporter、ディスク パフォーマンス、パフォーマンス概要などの一連のサブ ダッシュボードに分かれています。 クラスターで[リソース管理](/tidb-resource-control-ru-groups.md)機能を使用している場合は、リソース制御ダッシュボードからリソース消費状況の概要を取得できます。 -TiDBはフロー制御に[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)使用します[RFC: TiDB におけるグローバル リソース制御](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md#distributed-token-buckets)で説明したように、TiDBノードは複数のリソースグループを持つことができ、PD側のGAC（Global Admission Control）によってフロー制御されます。各TiDBノードのローカルトークンバケットは、PD側のGACと定期的に（デフォルトでは5秒）通信し、ローカルトークンを再設定します。TiDBでは、ローカルトークンバケットはリソースコントローラークライアントとして実装されています。 +TiDBはフロー制御に[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します[RFC: TiDB におけるグローバル リソース制御](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md#distributed-token-buckets)で説明したように、TiDBノードは複数のリソースグループを持つことができ、PD側のGAC（Global Admission Control）によってフロー制御されます。各TiDBノードのローカルトークンバケットは、PD側のGACと定期的に（デフォルトでは5秒）通信し、ローカルトークンを再設定します。TiDBでは、ローカルトークンバケットはリソースコントローラークライアントとして実装されています。 このドキュメントでは、リソース コントロール ダッシュボードに表示されるいくつかの主要な監視メトリックについて説明します。 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 0400ea802201e..fdbe24ae73f58 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -5,7 +5,7 @@ summary: Grafana TiDB ダッシュボードに表示されるいくつかの主 # TiDB 監視メトリクス {#tidb-monitoring-metrics} -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。監視アーキテクチャについては、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。監視アーキテクチャについては、 [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafanaダッシュボードは、概要、PD、TiDB、TiKV、Node_exporter、ディスクパフォーマンス、パフォーマンス概要を含む一連のサブダッシュボードに分かれています。TiDBダッシュボードは、TiDBパネルとTiDBサマリーパネルで構成されています。2つのパネルの違いは、以下のとおりです。 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index c2b153047620a..80429cee08a84 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -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} diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 267459a01647f..344a4d8429f31 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -205,7 +205,7 @@ TiKVコプロセッサータスクフィールド： ### サポートされているフィールド {#supported-fields} -フィールドの詳細な説明、診断の意味、背景情報については、 [`identify-slow-queries`のフィールド説明](/identify-slow-queries.md#fields-description)参照してください。 +フィールドの詳細な説明、診断の意味、背景情報については、 [`identify-slow-queries`のフィールド説明](/identify-slow-queries.md#fields-description)を参照してください。 特に断りのない限り、次の表のフィールドは [統一されたルール構文と型制約](#unified-rule-syntax-and-type-constraints)型安定」で説明されている一般的な一致および型ルールに従います。この表には、現在サポートされているフィールド名、タイプ、単位、およびルール固有のいくつかの注意事項のみがリストされています。各フィールドの意味論的な意味を繰り返すことはありません。 @@ -335,9 +335,9 @@ TiKVコプロセッサータスクフィールド： set @@tidb_enable_collect_execution_info=0; ``` -`Plan`フィールドの戻り値は、 `EXPLAIN`または`EXPLAIN ANALYZE`とほぼ同じ形式です。実行プランの詳細については、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)参照してください。 +`Plan`フィールドの戻り値は、 `EXPLAIN`または`EXPLAIN ANALYZE`とほぼ同じ形式です。実行プランの詳細については、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を参照してください。 -詳細については、 [TiDB固有の変数と構文](/system-variables.md)参照してください。 +詳細については、 [TiDB固有の変数と構文](/system-variables.md)を参照してください。 ## スローログのメモリマッピング {#memory-mapping-in-slow-log} diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index 25a7ed0647cbf..e5639944a59ad 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -38,7 +38,7 @@ DESC data_lock_waits; > - 現在、楽観的トランザクションの場合、フィールド`SQL_DIGEST`とフィールド`SQL_DIGEST_TEXT`は`null` （使用不可）になっています。回避策として、ブロックの原因となっているSQL文を特定するには、このテーブルを[`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md)と結合して、楽観的トランザクションのすべてのSQL文を取得できます。 > - `DATA_LOCK_WAITS`テーブルの情報は、クエリ実行中にすべての TiKV ノードからリアルタイムで取得されます。現在、クエリに`WHERE`条件が含まれている場合でも、情報収集はすべての TiKV ノードに対して実行されます。クラスターの規模が大きく、負荷が高い場合、このテーブルへのクエリはパフォーマンスジッターのリスクを引き起こす可能性があります。したがって、実際の状況に応じて使用してください。 > - 異なる TiKV ノードからの情報が、同じ時刻のスナップショットであるとは限りません。 -> - `SQL_DIGEST`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`SQL_DIGEST_TEXT`列の情報は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)参照してください。 +> - `SQL_DIGEST`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`SQL_DIGEST_TEXT`列の情報は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)を参照してください。 ## `KEY_INFO` {#key-info} diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index be6d25a5597db..f43f337dd7575 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -59,7 +59,7 @@ DESC deadlocks; > **警告：** > > - [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみがこのテーブルをクエリできます。 -> - `CURRENT_SQL_DIGEST`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`CURRENT_SQL_DIGEST_TEXT`列の情報は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)参照してください。 +> - `CURRENT_SQL_DIGEST`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`CURRENT_SQL_DIGEST_TEXT`列の情報は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)を参照してください。 ## `KEY_INFO` {#key-info} diff --git a/information-schema/information-schema-inspection-rules.md b/information-schema/information-schema-inspection-rules.md index d4336df0ae567..91879e6543aa6 100644 --- a/information-schema/information-schema-inspection-rules.md +++ b/information-schema/information-schema-inspection-rules.md @@ -5,7 +5,7 @@ summary: INSPECTION_RULES` information_schema テーブルについて学習し # 検査ルール {#inspection-rules} -`INSPECTION_RULES`表は、検査結果で実行される診断テストに関する情報を提供します。使用例については[検査結果](/information-schema/information-schema-inspection-result.md)参照してください。 +`INSPECTION_RULES`表は、検査結果で実行される診断テストに関する情報を提供します。使用例については[検査結果](/information-schema/information-schema-inspection-result.md)を参照してください。 > **注記：** > diff --git a/information-schema/information-schema-resource-groups.md b/information-schema/information-schema-resource-groups.md index 6fde77506982a..fd136f0b40d2c 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`テーブルには、すべてのリソース グループに関する情報が表示されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)参照してください。 +`RESOURCE_GROUPS`テーブルには、すべてのリソース グループに関する情報が表示されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 > **注記：** > diff --git a/information-schema/information-schema-runaway-watches.md b/information-schema/information-schema-runaway-watches.md index 49f19079ddee9..ffa425419e78f 100644 --- a/information-schema/information-schema-runaway-watches.md +++ b/information-schema/information-schema-runaway-watches.md @@ -5,7 +5,7 @@ summary: RUNAWAY_WATCHES` INFORMATION_SCHEMA テーブルについて学習し # ランナウェイ・ウォッチズ {#runaway-watches} -`RUNAWAY_WATCHES`表には、想定よりも多くのリソースを消費する暴走クエリの監視リストが表示されます。詳細については、 [暴走クエリ](/tidb-resource-control-runaway-queries.md)参照してください。 +`RUNAWAY_WATCHES`表には、想定よりも多くのリソースを消費する暴走クエリの監視リストが表示されます。詳細については、 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 > **注記：** > diff --git a/information-schema/information-schema-statistics.md b/information-schema/information-schema-statistics.md index d5f6eab171a91..9b182ac53f88b 100644 --- a/information-schema/information-schema-statistics.md +++ b/information-schema/information-schema-statistics.md @@ -56,7 +56,7 @@ DESC statistics; - `INDEX_TYPE` : インデックスのタイプ。 - `COMMENT` : インデックスに関連するその他の情報。 - `INDEX_COMMENT` : インデックスの作成時にインデックスに指定されたコメント属性を持つコメント。 -- `IS_VISIBLE` : このインデックスが可視かどうか。[不可視インデックス](/sql-statements/sql-statement-create-index.md#invisible-index)参照してください。 +- `IS_VISIBLE` : このインデックスが可視かどうか。[不可視インデックス](/sql-statements/sql-statement-create-index.md#invisible-index)を参照してください。 - `Expression`非式部分のインデックスキーの場合、この値は`NULL`です。式部分のインデックスキーの場合、この値は式そのものです[式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 次の文は同等です。 diff --git a/information-schema/information-schema-tidb-hot-regions-history.md b/information-schema/information-schema-tidb-hot-regions-history.md index 3b77465016509..3c9c5f66afb6d 100644 --- a/information-schema/information-schema-tidb-hot-regions-history.md +++ b/information-schema/information-schema-tidb-hot-regions-history.md @@ -13,7 +13,7 @@ summary: TIDB_HOT_REGIONS_HISTORY`情報スキーマテーブルについて学 -記録間隔は[`hot-regions-write-interval`](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を設定することで指定できます。デフォルト値は 10 分です。ホット リージョンの履歴情報を保持する期間は[`hot-regions-reserved-days`](/pd-configuration-file.md#hot-regions-reserved-days-new-in-v540)を設定することで指定できます。デフォルト値は 7 日です。詳細は、 [PD設定ファイルの説明](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)参照してください。 +記録間隔は[`hot-regions-write-interval`](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を設定することで指定できます。デフォルト値は 10 分です。ホット リージョンの履歴情報を保持する期間は[`hot-regions-reserved-days`](/pd-configuration-file.md#hot-regions-reserved-days-new-in-v540)を設定することで指定できます。デフォルト値は 7 日です。詳細は、 [PD設定ファイルの説明](/pd-configuration-file.md#hot-regions-write-interval-new-in-v540)を参照してください。 diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index d3549578f2fa9..d333cd7781cb9 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -58,7 +58,7 @@ DESC TIDB_TRX; > **注記：** > > - [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみがこのテーブルの完全な情報を取得できます。PROCESS権限を持たないユーザーは、現在のユーザーが実行したトランザクションの情報のみを照会できます。 -> - `CURRENT_SQL_DIGEST`列と`ALL_SQL_DIGESTS`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`CURRENT_SQL_DIGEST_TEXT`列の情報と`TIDB_DECODE_SQL_DIGESTS`関数から返される結果は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)参照してください。 +> - `CURRENT_SQL_DIGEST`列と`ALL_SQL_DIGESTS`列の情報（SQLダイジェスト）は、正規化されたSQL文から計算されたハッシュ値です。`CURRENT_SQL_DIGEST_TEXT`列の情報と`TIDB_DECODE_SQL_DIGESTS`関数から返される結果は、内部的にステートメントサマリーテーブルから照会されるため、対応するステートメントが内部的に見つからない可能性があります。SQLダイジェストとステートメントサマリーテーブルの詳細については、 [ステートメントサマリーテーブル](/statement-summary-tables.md)を参照してください。 > - [`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)関数呼び出しは大きなオーバーヘッドを伴います。この関数を多数のトランザクションの履歴SQL文のクエリに使用した場合、クエリに長時間かかる可能性があります。クラスターが大きく、同時トランザクション数が多い場合は、 `TIDB_TRX`のテーブル全体をクエリする際に、 `ALL_SQL_DIGEST`列に対してこの関数を直接使用することは避けてください。つまり、 `SELECT *, tidb_decode_sql_digests(all_sql_digests) FROM TIDB_TRX`ようなSQL文は避けてください。 > - 現在、 `TIDB_TRX`テーブルは TiDB 内部トランザクションの情報の表示をサポートしていません。 diff --git a/information-schema/information-schema-tiflash-indexes.md b/information-schema/information-schema-tiflash-indexes.md index ae1110ce65760..d9fb8cc2f48fb 100644 --- a/information-schema/information-schema-tiflash-indexes.md +++ b/information-schema/information-schema-tiflash-indexes.md @@ -7,7 +7,7 @@ summary: INFORMATION_SCHEMA` の `TIFLASH_INDEXES` テーブルについて学 > **警告：** > -> 現在、このテーブルは実験的です。本番環境での使用は推奨されません。このテーブルのフィールドはまだ安定しておらず、将来のTiDBバージョンで変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> 現在、このテーブルは実験的です。本番環境での使用は推奨されません。このテーブルのフィールドはまだ安定しておらず、将来のTiDBバージョンで変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 `TIFLASH_INDEXES`表は、 TiFlashレプリカ上のインデックス構築に関する統計を提供します。 diff --git a/integration-overview.md b/integration-overview.md index 0ed6a7d0d3ce7..8f72e2571c77d 100644 --- a/integration-overview.md +++ b/integration-overview.md @@ -9,7 +9,7 @@ summary: データ統合シナリオの概要を学びましょう。 ## Confluent Cloud、Snowflake、ksqlDB、SQL Serverとの統合 {#integrate-with-confluent-cloud-snowflake-ksqldb-and-sql-server} -TiCDC を使用して、増分データを TiDB から Confluent Cloud にレプリケートし、そのデータを Confluent Cloud 経由で Snowflake、ksqlDB、SQL Server にレプリケートできます。詳細については、 [Confluent Cloud、Snowflake、ksqlDB、SQL Serverとデータを統合する](/ticdc/integrate-confluent-using-ticdc.md)参照してください。 +TiCDC を使用して、増分データを TiDB から Confluent Cloud にレプリケートし、そのデータを Confluent Cloud 経由で Snowflake、ksqlDB、SQL Server にレプリケートできます。詳細については、 [Confluent Cloud、Snowflake、ksqlDB、SQL Serverとデータを統合する](/ticdc/integrate-confluent-using-ticdc.md)を参照してください。 ## Apache KafkaおよびApache Flinkとの統合 {#integrate-with-apache-kafka-and-apache-flink} diff --git a/latency-breakdown.md b/latency-breakdown.md index ee161256538f2..f8e4bf64ee587 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -102,7 +102,7 @@ tidb_session_execute_duration_seconds{type="general"} = read value duration ``` -`pd_client_cmd_handle_cmds_duration_seconds{type="wait"}` PDから[TSO (タイムスタンプ オラクル)](/tso.md)取得するのに要した時間を記録します。クラスター化プライマリインデックスを使用した自動コミットトランザクションモード、またはスナップショットからの読み取りの場合、値は0になります。 +`pd_client_cmd_handle_cmds_duration_seconds{type="wait"}` PDから[TSO (タイムスタンプ オラクル)](/tso.md)を取得するのに要した時間を記録します。クラスター化プライマリインデックスを使用した自動コミットトランザクションモード、またはスナップショットからの読み取りの場合、値は0になります。 `read handle duration`と`read value duration`次のように計算されます。 @@ -419,7 +419,7 @@ tikv_grpc_msg_duration_seconds{type="kv_pessimistic_lock"} = lock write duration ``` -- TiDB v6.0以降、TiKVはデフォルトで[メモリ内悲観的ロック](/pessimistic-transaction.md#in-memory-pessimistic-lock)使用します。メモリ内悲観的ロックは非同期書き込みプロセスをバイパスします。 +- TiDB v6.0以降、TiKVはデフォルトで[メモリ内悲観的ロック](/pessimistic-transaction.md#in-memory-pessimistic-lock)を使用します。メモリ内悲観的ロックは非同期書き込みプロセスをバイパスします。 - `tikv_storage_engine_async_request_duration_seconds{type="snapshot"}`はスナップショットタイプの期間です。詳細については、 [TiKVスナップショット](#tikv-snapshot)セクションを参照してください。 @@ -825,7 +825,7 @@ raft db write duration(raft engine disabled) = クォーラム ピアの最長期間は`commit log wait duration`であるため、 `raft db write duration`よりも大きくなる可能性があります。 -v6.1.0 以降、TiKV はデフォルトのログストレージエンジンとして[Raft Engine](/glossary.md#raft-engine)使用するようになり、ログの書き込みプロセスが変更されました。 +v6.1.0 以降、TiKV はデフォルトのログストレージエンジンとして[Raft Engine](/glossary.md#raft-engine)を使用するようになり、ログの書き込みプロセスが変更されました。 ### KV DB {#kv-db} diff --git a/literal-values.md b/literal-values.md index 8bbe99a3ccdc8..48acca59941d4 100644 --- a/literal-values.md +++ b/literal-values.md @@ -63,7 +63,7 @@ N'literal'（またはn'literal'）を使用して、各国語 `'`で囲まれた文字列で`"`表したり、 `"`で囲まれた文字列で`'`表したりする場合は、エスケープ文字を使用する必要はありません。 -詳細については[MySQLの文字列リテラル](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html)参照してください。 +詳細については[MySQLの文字列リテラル](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html)を参照してください。 ## 数値リテラル {#numeric-literals} @@ -75,7 +75,7 @@ N'literal'（またはn'literal'）を使用して、各国語 数値リテラルは、 `1.2E3, 1.2E-3, -1.2E3, -1.2E-3`などの科学的記数法で表すこともできます。 -詳細については[MySQLの数値リテラル](https://dev.mysql.com/doc/refman/8.0/en/number-literals.html)参照してください。 +詳細については[MySQLの数値リテラル](https://dev.mysql.com/doc/refman/8.0/en/number-literals.html)を参照してください。 ## 日付と時刻のリテラル {#date-and-time-literals} diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index 4bff3ae375dda..39d8e724b2017 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -85,7 +85,7 @@ tiup cluster display ${cluster-name} config: log.slow-threshold: 300 - パラメータの形式については[TiUPパラメータテンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)参照してください。 + パラメータの形式については[TiUPパラメータテンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)を参照してください。 **構成項目の階層を表すには、 . を使用します`.`** @@ -109,7 +109,7 @@ tidb-server でトランザクション サイズ制限パラメータ ( [パフ ## 修正プログラムパッケージに置き換える {#replace-with-a-hotfix-package} -通常のアップグレードについては、 [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md)参照してください。ただし、デバッグなどの一部のシナリオでは、現在実行中のコンポーネントを一時パッケージに置き換える必要がある場合があります。これを行うには、 `patch`コマンドを使用します。 +通常のアップグレードについては、 [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md)を参照してください。ただし、デバッグなどの一部のシナリオでは、現在実行中のコンポーネントを一時パッケージに置き換える必要がある場合があります。これを行うには、 `patch`コマンドを使用します。 ```bash tiup cluster patch --help diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index 4d3db375ac9d2..3fd7e0f0b018c 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -28,7 +28,7 @@ summary: DBスナップショットを使用して、Amazon AuroraからTiDBへ Amazon Auroraのスナップショット ファイルには DDL ステートメントが含まれていないため、 Dumplingを使用してスキーマをエクスポートし、 TiDB Lightningを使用してターゲット データベースにスキーマを作成する必要があります。 -次のコマンドを実行して、 Dumplingを使用してスキーマをエクスポートします。このコマンドには`--filter`パラメータが含まれており、目的のテーブルスキーマのみをエクスポートできます。パラメータの詳細については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)参照してください。 +次のコマンドを実行して、 Dumplingを使用してスキーマをエクスポートします。このコマンドには`--filter`パラメータが含まれており、目的のテーブルスキーマのみをエクスポートできます。パラメータの詳細については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)を参照してください。 ```shell export AWS_ACCESS_KEY_ID=${access_key} @@ -105,7 +105,7 @@ nohup tiup tidb-lightning -config tidb-lightning-schema.toml > nohup.out 2>&1 & +----------------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.012 sec) -2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)参照してください。binlogの位置を取得したら、5 分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 +2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)を参照してください。binlogの位置を取得したら、5 分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 #### 2.2 データファイル用のTiDB Lightning構成ファイルを作成する {#2-2-create-the-tidb-lightning-configuration-file-for-the-data-file} diff --git a/migrate-from-mariadb.md b/migrate-from-mariadb.md index 5415555dddee1..f5f939f998bf3 100644 --- a/migrate-from-mariadb.md +++ b/migrate-from-mariadb.md @@ -374,7 +374,7 @@ MariaDB でbinlogを有効にし、 `binlog_format=ROW` 、 `binlog_row_image=FU ignore-checking-items: ["replication_privilege"] ``` -DM を使用してアップストリームからダウンストリームにデータを移行する前に、事前チェックによりアップストリームのデータベース構成のエラーを検出し、移行がスムーズに行われるようにします。詳細については、[移行タスクの事前チェック](/dm/dm-precheck.md)参照してください。 +DM を使用してアップストリームからダウンストリームにデータを移行する前に、事前チェックによりアップストリームのデータベース構成のエラーを検出し、移行がスムーズに行われるようにします。詳細については、[移行タスクの事前チェック](/dm/dm-precheck.md)を参照してください。 ### ステップ2．データの複製 {#step-2-replicate-data} diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 30d5582840908..7384f4012834a 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -48,7 +48,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する ## ステップ2. 全データを移行する {#step-2-migrate-full-data} -環境を設定したら、 [Dumpling](/dumpling-overview.md)使用して上流の TiDB クラスターから完全なデータをエクスポートできます。 +環境を設定したら、 [Dumpling](/dumpling-overview.md)を使用して上流の TiDB クラスターから完全なデータをエクスポートできます。 > **注記：** > @@ -102,7 +102,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する 3. データを復元します。 - MyLoader（オープンソースツール）を使用して、下流のMySQLインスタンスにデータをインポートします。MyLoaderのインストールと使用方法の詳細については、 [マイダンプラー/マイローダー](https://github.com/mydumper/mydumper)参照してください。MyLoaderはv0.10以前のバージョンを使用する必要があります。それ以降のバージョンでは、 Dumplingによってエクスポートされたメタデータファイルを処理できません。 + MyLoader（オープンソースツール）を使用して、下流のMySQLインスタンスにデータをインポートします。MyLoaderのインストールと使用方法の詳細については、 [マイダンプラー/マイローダー](https://github.com/mydumper/mydumper)を参照してください。MyLoaderはv0.10以前のバージョンを使用する必要があります。それ以降のバージョンでは、 Dumplingによってエクスポートされたメタデータファイルを処理できません。 Dumplingによってエクスポートされた完全なデータを MySQL にインポートするには、次のコマンドを実行します。 @@ -112,13 +112,13 @@ summary: TiDB から MySQL 互換データベースにデータを移行する 4. (オプション) データを検証します。 - [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)使用すると、特定の時間に上流と下流の間のデータの整合性をチェックできます。 + [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用すると、特定の時間に上流と下流の間のデータの整合性をチェックできます。 ```shell sync_diff_inspector -C ./config.yaml ``` - sync-diff-inspector の設定方法の詳細については[コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)参照してください。このドキュメントでは、設定は以下のとおりです。 + sync-diff-inspector の設定方法の詳細については[コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、設定は以下のとおりです。 ```toml # Diff Configuration. @@ -164,11 +164,11 @@ summary: TiDB から MySQL 互換データベースにデータを移行する - `--changefeed-id` : チェンジフィードID、正規表現の形式でなければなりません、 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$` - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データの移行](#step-2-migrate-full-data)の「データのバックアップ」セクションの BackupTS) - changefeed 構成の詳細については、 [タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)参照してください。 + changefeed 構成の詳細については、 [タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。 3. GC を有効にします。 - TiCDCを用いた増分移行では、GCは複製された履歴データのみを削除します。そのため、変更フィードを作成した後、以下のコマンドを実行してGCを有効にする必要があります。詳細は[TiCDCガベージコレクション（GC）セーフポイントの完全な動作は何ですか？](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)参照してください。 + TiCDCを用いた増分移行では、GCは複製された履歴データのみを削除します。そのため、変更フィードを作成した後、以下のコマンドを実行してGCを有効にする必要があります。詳細は[TiCDCガベージコレクション（GC）セーフポイントの完全な動作は何ですか？](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)を参照してください。 GC を有効にするには、次のコマンドを実行します。 diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 1a7ae01b60495..8a57571682831 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -38,7 +38,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 2. データを初期化します。 - デフォルトでは、新しくデプロイされたクラスターにテストデータベースが作成されます。そのため、 [Sysbench](https://github.com/akopytov/sysbench#linux)使用してテストデータを生成し、実際のシナリオでデータをシミュレートできます。 + デフォルトでは、新しくデプロイされたクラスターにテストデータベースが作成されます。そのため、 [Sysbench](https://github.com/akopytov/sysbench#linux)を使用してテストデータを生成し、実際のシナリオでデータをシミュレートできます。 ```shell sysbench oltp_write_only --config-file=./tidb-config --tables=10 --table-size=10000 prepare @@ -69,7 +69,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 4. 外部ストレージを準備します。 - フルデータバックアップでは、上流クラスターと下流クラスターの両方がバックアップファイルにアクセスする必要があります。バックアップファイルの保存には[外部ストレージ](/br/backup-and-restore-storages.md)使用することをお勧めします。このドキュメントでは、Minioを使用してS3互換ストレージサービスをシミュレートします。 + フルデータバックアップでは、上流クラスターと下流クラスターの両方がバックアップファイルにアクセスする必要があります。バックアップファイルの保存には[外部ストレージ](/br/backup-and-restore-storages.md)を使用することをお勧めします。このドキュメントでは、Minioを使用してS3互換ストレージサービスをシミュレートします。 ```shell wget https://dl.min.io/server/minio/release/linux-amd64/minio @@ -103,9 +103,9 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー > **注記：** > -> - `BACKUP`と`RESTORE` SQL 文は実験的です。本番環境での使用は推奨されません。予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> - `BACKUP`と`RESTORE` SQL 文は実験的です。本番環境での使用は推奨されません。予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 > - 本番のクラスタでは、GCを無効にしてバックアップを実行すると、クラスタのパフォーマンスに影響する可能性があります。パフォーマンスの低下を防ぐため、オフピーク時にデータのバックアップを実行し、 `RATE_LIMIT`適切な値に設定することをお勧めします。 -> - アップストリームクラスタとダウンストリームクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#before-you-use)確認する必要があります。このドキュメントでは、アップストリームクラスタとダウンストリームクラスタは同じバージョンであると想定しています。 +> - アップストリームクラスタとダウンストリームクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#before-you-use)を確認する必要があります。このドキュメントでは、アップストリームクラスタとダウンストリームクラスタは同じバージョンであると想定しています。 1. GC を無効にします。 @@ -134,7 +134,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー > **注記：** > - > TiCDC `gc-ttl`デフォルトで24時間です。バックアップと復元に時間がかかる場合、デフォルトの`gc-ttl`不十分で、その後の[増分レプリケーションタスク](#step-3-migrate-incremental-data)失敗する可能性があります。このような状況を回避するには、TiCDCサーバーを起動する際に、特定のニーズに合わせて`gc-ttl`値を調整してください。詳細については、 [TiCDCにおける`gc-ttl`とは](/ticdc/ticdc-faq.md#what-is-gc-ttl-in-ticdc)参照してください。 + > TiCDC `gc-ttl`デフォルトで24時間です。バックアップと復元に時間がかかる場合、デフォルトの`gc-ttl`不十分で、その後の[増分レプリケーションタスク](#step-3-migrate-incremental-data)失敗する可能性があります。このような状況を回避するには、TiCDCサーバーを起動する際に、特定のニーズに合わせて`gc-ttl`値を調整してください。詳細については、 [TiCDCにおける`gc-ttl`とは](/ticdc/ticdc-faq.md#what-is-gc-ttl-in-ticdc)を参照してください。 2. データをバックアップします。 @@ -170,13 +170,13 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 4. (オプション) データを検証します。 - [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)使用すると、特定の時刻における上流と下流のデータの整合性を確認できます。上記の`BACKUP`出力は、上流クラスターが 431434047157698561 にバックアップを完了したことを示しています。上記の`RESTORE`出力は、下流クラスターが 431434141450371074 に復元を完了したことを示しています。 + [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用すると、特定の時刻における上流と下流のデータの整合性を確認できます。上記の`BACKUP`出力は、上流クラスターが 431434047157698561 にバックアップを完了したことを示しています。上記の`RESTORE`出力は、下流クラスターが 431434141450371074 に復元を完了したことを示しています。 ```shell sync_diff_inspector -C ./config.yaml ``` - sync-diff-inspector の設定方法の詳細については[コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)参照してください。このドキュメントでは、設定は以下のとおりです。 + sync-diff-inspector の設定方法の詳細については[コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、設定は以下のとおりです。 ```shell # Diff Configuration. @@ -223,11 +223,11 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー - `--changefeed-id` : チェンジフィードID。正規表現の形式である必要があります。^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$ - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データを移行する](#step-2-migrate-full-data)の「データのバックアップ」セクションの BackupTS) - changefeed 構成の詳細については、 [タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)参照してください。 + changefeed 構成の詳細については、 [タスク設定ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。 3. GC を有効にします。 - TiCDCを用いた増分移行では、GCは複製された履歴データのみを削除します。そのため、変更フィードを作成した後、以下のコマンドを実行してGCを有効にする必要があります。詳細は[TiCDCガベージコレクション(GC) セーフポイントの完全な動作は何ですか?](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)参照してください。 + TiCDCを用いた増分移行では、GCは複製された履歴データのみを削除します。そのため、変更フィードを作成した後、以下のコマンドを実行してGCを有効にする必要があります。詳細は[TiCDCガベージコレクション(GC) セーフポイントの完全な動作は何ですか?](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)を参照してください。 GC を有効にするには、次のコマンドを実行します。 diff --git a/migrate-from-vitess.md b/migrate-from-vitess.md index 1a3d173ce92b3..0d208f76c9b81 100644 --- a/migrate-from-vitess.md +++ b/migrate-from-vitess.md @@ -26,7 +26,7 @@ VitessとTiDBはどちらもMySQLプロトコルとSQL方言をサポートし 次の 2 つの例は、 DumplingとTiDB Lightningが連携して Vitess から TiDB にデータを移行する方法を示しています。 -- この例では、 TiDB Lightning は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)使用します。これは、最初にデータを SQL ステートメントにエンコードし、次に SQL ステートメントを実行してデータをインポートします。 +- この例では、 TiDB Lightning は[論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を使用します。これは、最初にデータを SQL ステートメントにエンコードし、次に SQL ステートメントを実行してデータをインポートします。 ![Vitess to TiDB Migration with TiDB backend](/media/vitess_to_tidb.png) diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index 275ccd10c49f9..017a4e8ce5ee3 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -37,7 +37,7 @@ MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規 ### シャーディングされたテーブルの競合をチェックする {#check-conflicts-for-sharded-tables} -移行に異なるシャードテーブルのデータのマージが含まれる場合、マージ中に主キーまたは一意インデックスの競合が発生する可能性があります。したがって、移行前に、ビジネスの観点から現在のシャーディング スキームを詳しく調べ、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャーディングされたテーブル間で主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)参照してください。以下に簡単に説明します。 +移行に異なるシャードテーブルのデータのマージが含まれる場合、マージ中に主キーまたは一意インデックスの競合が発生する可能性があります。したがって、移行前に、ビジネスの観点から現在のシャーディング スキームを詳しく調べ、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャーディングされたテーブル間で主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)を参照してください。以下に簡単に説明します。 表1～4は以下の表構造と同じであると仮定します。 @@ -79,7 +79,7 @@ CREATE TABLE `table5` ( tiup dumpling -h ${ip} -P 3306 -u root -t 16 -r 200000 -F 256MB -B my_db1 -f 'my_db1.table[12]' -o ${data-path}/my_db1 ``` -以下の表は、上記のコマンドで使用されるパラメータについて説明しています。Dumplingのパラメータの詳細については、 [Dumplingの概要](/dumpling-overview.md)参照してください。 +以下の表は、上記のコマンドで使用されるパラメータについて説明しています。Dumplingのパラメータの詳細については、 [Dumplingの概要](/dumpling-overview.md)を参照してください。 | パラメータ | 説明 | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index dbc0ff7723a77..e63897d0430ea 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -33,7 +33,7 @@ summary: シャードの小さなデータセットを MySQL から TiDB に移 ### シャードテーブルの競合をチェックする {#check-conflicts-for-the-sharded-tables} -移行に異なるシャーディングされたテーブルからのデータのマージが含まれる場合、マージ中に主キーまたは一意インデックスの競合が発生する可能性があります。そのため、移行前に、現在のシャーディングスキームをビジネスの観点から詳細に検討し、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)参照してください。以下に簡単に説明します。 +移行に異なるシャーディングされたテーブルからのデータのマージが含まれる場合、マージ中に主キーまたは一意インデックスの競合が発生する可能性があります。そのため、移行前に、現在のシャーディングスキームをビジネスの観点から詳細に検討し、競合を回避する方法を見つける必要があります。詳細については、 [複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する](/dm/shard-merge-best-practices.md#handle-conflicts-between-primary-keys-or-unique-indexes-across-multiple-sharded-tables)を参照してください。以下に簡単に説明します。 この例では、 `sale_01`と`sale_02`次の同じテーブル構造を持ちます。 @@ -166,7 +166,7 @@ block-allow-list: # filter or only migrate all operations of some data do-dbs: ["store_*"] # The allow list of the schemas to be migrated, similar to replicate-do-db in MySQL. ``` -上記の例は、移行タスクを実行するための最小限の構成です。詳細については、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)参照してください。 +上記の例は、移行タスクを実行するための最小限の構成です。詳細については、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 タスク ファイル内の`routes` 、およびその他`filters`構成の詳細については、次のドキュメントを参照してください。 @@ -194,7 +194,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml | `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの`{advertise-addr}`例：172.16.10.71:8261 | | `start-task` | データ移行タスクを開始します。 | -移行タスクの開始に失敗した場合は、エラー情報に従って構成情報を変更し、手順`start-task task.yaml`再度実行して移行タスクを開始してください。問題が発生した場合は、 [エラーの処理](/dm/dm-error-handling.md)と[FAQ](/dm/dm-faq.md)参照してください。 +移行タスクの開始に失敗した場合は、エラー情報に従って構成情報を変更し、手順`start-task task.yaml`再度実行して移行タスクを開始してください。問題が発生した場合は、 [エラーの処理](/dm/dm-error-handling.md)と[FAQ](/dm/dm-faq.md)を参照してください。 ## ステップ4. タスクを確認する {#step-4-check-the-task} @@ -204,7 +204,7 @@ tiup dmctl --master-addr ${advertise-addr} start-task task.yaml tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} ``` -エラーが発生した場合は、 `query-status ${task-name}`使用して詳細情報を表示してください。3 `query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)参照してください。 +エラーが発生した場合は、 `query-status ${task-name}`使用して詳細情報を表示してください。3 `query-status`のクエリ結果、タスクステータス、サブタスクステータスの詳細については、 [TiDB データ移行クエリのステータス](/dm/dm-query-status.md)を参照してください。 ## ステップ5. タスクを監視し、ログを確認する（オプション） {#step-5-monitor-tasks-and-check-logs-optional} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 43b32687af0fb..39c92e2eb095a 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -55,7 +55,7 @@ DM がダウンストリーム テーブル スキーマを使用してアップ このような場合、 `binlog-schema`コマンドを使用して、データソースから移行するテーブルのテーブルスキーマを設定できます。指定するテーブルスキーマは、DM によって複製されるbinlogイベントデータに対応している必要があります。シャード化されたテーブルを移行する場合は、シャード化されたテーブルごとに、binlogイベントデータを解析するためのテーブルスキーマを DM で設定する必要があります。手順は以下のとおりです。 -1. DMでSQLファイルを作成し、上流のテーブルスキーマに対応する`CREATE TABLE`ステートメントをファイルに追加します。例えば、次のテーブルスキーマを`log.messages.sql`に保存します。DM v6.0以降のバージョンでは、SQLファイルを作成せずに、 `--from-source`または`--from-target`フラグを追加することでテーブルスキーマを更新できます。詳細は[移行するテーブルのテーブルスキーマを管理する](/dm/dm-manage-schema.md)参照してください。 +1. DMでSQLファイルを作成し、上流のテーブルスキーマに対応する`CREATE TABLE`ステートメントをファイルに追加します。例えば、次のテーブルスキーマを`log.messages.sql`に保存します。DM v6.0以降のバージョンでは、SQLファイルを作成せずに、 `--from-source`または`--from-target`フラグを追加することでテーブルスキーマを更新できます。詳細は[移行するテーブルのテーブルスキーマを管理する](/dm/dm-manage-schema.md)を参照してください。 ```sql # Upstream table schema diff --git a/migration-overview.md b/migration-overview.md index 37033a2d70b75..e3d3108dad49f 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -32,7 +32,7 @@ Auroraから AWS にデプロイされた TiDB クラスターにデータを移 クラウドストレージ(S3) サービスを使用しておらず、ネットワーク接続が良好で、ネットワークレイテンシーが低い場合は、 [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md)の手順に従って、MySQL から TiDB にデータを移行できます。 -移行速度への要求が高い場合、またはデータサイズが大きい場合（例：1TiB以上）、かつ移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してデータを迅速にインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分データ（binlog）を複製できます。1 [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md)参照してください。 +移行速度への要求が高い場合、またはデータサイズが大きい場合（例：1TiB以上）、かつ移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してデータを迅速にインポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分データ（binlog）を複製できます。1 [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md)を参照してください。 ## MySQL シャードを TiDB に移行してマージする {#migrate-and-merge-mysql-shards-into-tidb} diff --git a/migration-tools.md b/migration-tools.md index ad38707283a97..45acffef7a0bd 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 26e020db3143d..79a32b3355a95 100644 --- a/minimal-deployment-topology.md +++ b/minimal-deployment-topology.md @@ -25,7 +25,7 @@ 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)を参照してください。 > **注記：** > diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 4dca5c0871f9e..692186d19ef8b 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -82,7 +82,7 @@ member leader_priority pdName3 3 > **注記：** > -> TiDB v5.2以降、 `label-property`構成はデフォルトではサポートされません。レプリカポリシーを設定するには、 [配置ルール](/configure-placement-rules.md)使用してください。 +> TiDB v5.2以降、 `label-property`構成はデフォルトではサポートされません。レプリカポリシーを設定するには、 [配置ルール](/configure-placement-rules.md)を使用してください。 **デメリット:** diff --git a/mysql-compatibility.md b/mysql-compatibility.md index c6e295ec5b545..64bcc6375e8f4 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -102,7 +102,7 @@ TiDBはMySQLレプリケーションプロトコルをサポートしていな - TiDB v6.6.0以前のバージョンでは、TiDBのAUTO_INCREMENT列はMySQL InnoDBと同様に動作し、主キーまたはインデックスプレフィックスである必要があります。v7.0.0以降、TiDBはこの制限を撤廃し、より柔軟なテーブル主キー定義を可能にしました。 [#40580](https://github.com/pingcap/tidb/issues/40580) -詳細については、 [`AUTO_INCREMENT`](/auto-increment.md)参照してください。 +詳細については、 [`AUTO_INCREMENT`](/auto-increment.md)を参照してください。 > **注記：** > @@ -138,7 +138,7 @@ mysql> SELECT _tidb_rowid, id FROM t; > **注記：** > -> `AUTO_INCREMENT`属性により、本番環境でホットスポットが発生する可能性があります。詳細については[HotSpotの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)を参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)使用することをお勧めします。 +> `AUTO_INCREMENT`属性により、本番環境でホットスポットが発生する可能性があります。詳細については[HotSpotの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md)を参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)を使用することをお勧めします。 @@ -146,7 +146,7 @@ mysql> SELECT _tidb_rowid, id FROM t; > **注記：** > -> `AUTO_INCREMENT`属性により、本番環境でホットスポットが発生する可能性があります。詳細については[HotSpotの問題のトラブルシューティング](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#handle-auto-increment-primary-key-hotspot-tables-using-auto_random)を参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)使用することをお勧めします。 +> `AUTO_INCREMENT`属性により、本番環境でホットスポットが発生する可能性があります。詳細については[HotSpotの問題のトラブルシューティング](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#handle-auto-increment-primary-key-hotspot-tables-using-auto_random)を参照してください。代わりに[`AUTO_RANDOM`](/auto-random.md)を使用することをお勧めします。 @@ -183,7 +183,7 @@ TiDBでは、サポートされているすべてのDDL変更をオンライン - 単一の`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)参照してください。 +- `ALGORITHM={INSTANT,INPLACE,COPY}`構文はTiDBではアサーションとしてのみ機能し、 `ALTER`アルゴリズムを変更しません。詳細については、 [`ALTER TABLE`](/sql-statements/sql-statement-alter-table.md)を参照してください。 - `CLUSTERED`タイプの主キーの追加/削除はサポートされていません。 `CLUSTERED`タイプの主キーの詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 - 異なるタイプのインデックス（ `HASH|BTREE|RTREE|FULLTEXT` ）はサポートされておらず、指定されても解析されて無視されます。 - TiDB は`HASH` 、 `RANGE` 、 `LIST` 、および`KEY`パーティションタイプをサポートしています。サポートされていないパーティションタイプの場合、TiDB は`Warning: Unsupported partition type %s, treat as normal table`を返します。ここで、 `%s`はサポートされていない特定のパーティションタイプです。 @@ -221,11 +221,11 @@ TiDB のビューは更新できず、 `UPDATE` 、 `INSERT` 、 `DELETE`など ### 一時テーブル {#temporary-tables} -詳細については、 [TiDBローカル一時テーブルとMySQL一時テーブルの互換性](/temporary-tables.md#compatibility-with-mysql-temporary-tables)参照してください。 +詳細については、 [TiDBローカル一時テーブルとMySQL一時テーブルの互換性](/temporary-tables.md#compatibility-with-mysql-temporary-tables)を参照してください。 ### 文字セットと照合順序 {#character-sets-and-collations} -- TiDB でサポートされている文字セットと照合順序については、[文字セットと照合の概要](/character-set-and-collation.md)参照してください。 +- TiDB でサポートされている文字セットと照合順序については、[文字セットと照合の概要](/character-set-and-collation.md)を参照してください。 - GBK文字セットのMySQL互換性に関する情報については、 [GBK互換性](/character-set-gbk.md#mysql-compatibility)を参照してください。 @@ -312,4 +312,4 @@ TiDBは、MySQLで非推奨となった特定の機能を実装していませ ## MySQL InnoDBとの悲観的トランザクション（ロック）に関する相違点 {#differences-on-pessimistic-transaction-lock-with-mysql-innodb} -TiDB と MySQL InnoDB の悲観的トランザクション (ロック) の違いについては、 [MySQL InnoDBとの違い](/pessimistic-transaction.md#differences-from-mysql-innodb)参照してください。 +TiDB と MySQL InnoDB の悲観的トランザクション (ロック) の違いについては、 [MySQL InnoDBとの違い](/pessimistic-transaction.md#differences-from-mysql-innodb)を参照してください。 diff --git a/mysql-schema/mysql-schema-user.md b/mysql-schema/mysql-schema-user.md index 3242c663ff41f..6a2cf0c8d1fa5 100644 --- a/mysql-schema/mysql-schema-user.md +++ b/mysql-schema/mysql-schema-user.md @@ -76,7 +76,7 @@ DESC mysql.user; - 特権： - `_priv`または`_Priv`で終わるフィールドは、ユーザーアカウントに付与される権限を定義します。例えば、 `Select_priv`ユーザーがグローバル権限`Select`を持つことを意味します。詳細については、 [TiDB操作に必要な権限](/privilege-management.md#privileges-required-for-tidb-operations)参照してください。 + `_priv`または`_Priv`で終わるフィールドは、ユーザーアカウントに付与される権限を定義します。例えば、 `Select_priv`ユーザーがグローバル権限`Select`を持つことを意味します。詳細については、 [TiDB操作に必要な権限](/privilege-management.md#privileges-required-for-tidb-operations)を参照してください。 - セキュリティ： - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 @@ -96,7 +96,7 @@ DESC mysql.user; - 特権： - `_priv`または`_Priv`で終わるフィールドは、ユーザーアカウントに付与される権限を定義します。例えば、 `Select_priv`ユーザーがグローバル権限`Select`を持つことを意味します。詳細については、 [TiDB操作に必要な権限](https://docs.pingcap.com/tidb/stable/privilege-management#privileges-required-for-tidb-operations)参照してください。 + `_priv`または`_Priv`で終わるフィールドは、ユーザーアカウントに付与される権限を定義します。例えば、 `Select_priv`ユーザーがグローバル権限`Select`を持つことを意味します。詳細については、 [TiDB操作に必要な権限](https://docs.pingcap.com/tidb/stable/privilege-management#privileges-required-for-tidb-operations)を参照してください。 - セキュリティ： - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 diff --git a/non-transactional-dml.md b/non-transactional-dml.md index fb0cd1b30f371..42127f8c0a4b5 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -18,7 +18,7 @@ summary: TiDBの非トランザクションDMLステートメントについて - `UPDATE` - `DELETE` -詳細な構文については[`BATCH`](/sql-statements/sql-statement-batch.md)参照してください。 +詳細な構文については[`BATCH`](/sql-statements/sql-statement-batch.md)を参照してください。 > **注記：** > diff --git a/optimizer-hints.md b/optimizer-hints.md index fa0f49d2d8779..501af81b36f7c 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -520,7 +520,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 ...]) {#use-index-merge-t1-name-idx1-name-idx2-name} -ヒント`USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...])`は、オプティマイザにインデックスマージ方式で特定のテーブルにアクセスするよう指示します。インデックスマージには、交差型と結合型の2種類があります。詳細は[インデックスマージを使用したステートメントの説明](/explain-index-merge.md)参照してください。 +ヒント`USE_INDEX_MERGE(t1_name, idx1_name [, idx2_name ...])`は、オプティマイザにインデックスマージ方式で特定のテーブルにアクセスするよう指示します。インデックスマージには、交差型と結合型の2種類があります。詳細は[インデックスマージを使用したステートメントの説明](/explain-index-merge.md)を参照してください。 インデックスのリストを明示的に指定すると、TiDB はリストからインデックスを選択してインデックス マージを構築します。インデックスのリストを指定しないと、TiDB は利用可能なすべてのインデックスからインデックスを選択してインデックス マージを構築します。 diff --git a/partitioned-raft-kv.md b/partitioned-raft-kv.md index 6fcb57f9ad409..a0e248f062070 100644 --- a/partitioned-raft-kv.md +++ b/partitioned-raft-kv.md @@ -29,7 +29,7 @@ TiKV クラスターに次の特性がある場合、この機能を使用でき ## 使用法 {#usage} -Partitioned Raft KVを有効にするには、クラスター作成時に設定項目[`storage.engine`](/tikv-configuration-file.md#engine-new-in-v660) ～ `"partitioned-raft-kv"`を設定します。同時に、設定項目[`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660)と[`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660)使用して、 Raft KV使用時のRocksDBのメモリ使用量を制御できます。 +Partitioned Raft KVを有効にするには、クラスター作成時に設定項目[`storage.engine`](/tikv-configuration-file.md#engine-new-in-v660) ～ `"partitioned-raft-kv"`を設定します。同時に、設定項目[`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660)と[`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660)を使用して、 Raft KV使用時のRocksDBのメモリ使用量を制御できます。 ## 制限 {#restrictions} diff --git a/password-management.md b/password-management.md index 125e64debd9d0..a4790bfb4e3bb 100644 --- a/password-management.md +++ b/password-management.md @@ -24,7 +24,7 @@ summary: TiDB でのユーザー パスワード管理のメカニズムを学 - `caching_sha2_password` - `tidb_sm3_password` -TiDB 認証プラグインの詳細については、 [認証プラグインのステータス](/security-compatibility-with-mysql.md#authentication-plugin-status)参照してください。 +TiDB 認証プラグインの詳細については、 [認証プラグインのステータス](/security-compatibility-with-mysql.md#authentication-plugin-status)を参照してください。 ## パスワードの複雑さのポリシー {#password-complexity-policy} @@ -60,7 +60,7 @@ mysql> SHOW VARIABLES LIKE 'validate_password.%'; 8 rows in set (0.00 sec) ``` -各システム変数の詳細な説明については、 [システム変数](/system-variables.md#validate_passwordcheck_user_name-new-in-v650)参照してください。 +各システム変数の詳細な説明については、 [システム変数](/system-variables.md#validate_passwordcheck_user_name-new-in-v650)を参照してください。 ### パスワードの複雑さのポリシーを構成する {#configure-password-complexity-policy} @@ -280,7 +280,7 @@ disconnect-on-expired-password = true - 通常のアカウントのパスワードの有効期限が切れた場合、管理者は SQL ステートメントを使用してアカウントのパスワードを変更できます。 - 管理者アカウントのパスワードの有効期限が切れた場合、別の管理者が SQL ステートメントを使用してアカウントのパスワードを変更できます。 -- 管理者アカウントのパスワードが期限切れで、パスワードの変更を手伝ってくれる他の管理者がいない場合は、 `skip-grant-table`メカニズムを使用してアカウントのパスワードを変更できます。詳細については、 [パスワードを忘れた場合の手続き](/user-account-management.md#forget-the-root-password)参照してください。 +- 管理者アカウントのパスワードが期限切れで、パスワードの変更を手伝ってくれる他の管理者がいない場合は、 `skip-grant-table`メカニズムを使用してアカウントのパスワードを変更できます。詳細については、 [パスワードを忘れた場合の手続き](/user-account-management.md#forget-the-root-password)を参照してください。 ## パスワード再利用ポリシー {#password-reuse-policy} @@ -299,7 +299,7 @@ TiDB はアカウントのパスワード履歴を記録し、履歴からの新 ### グローバルレベルのパスワード再利用ポリシー {#global-level-password-reuse-policy} -グローバル パスワード再利用ポリシーを確立するには、システム変数[`password_history`](/system-variables.md#password_history-new-in-v650)と[`password_reuse_interval`](/system-variables.md#password_reuse_interval-new-in-v650)使用します。 +グローバル パスワード再利用ポリシーを確立するには、システム変数[`password_history`](/system-variables.md#password_history-new-in-v650)と[`password_reuse_interval`](/system-variables.md#password_reuse_interval-new-in-v650)を使用します。 たとえば、過去 6 個のパスワードと過去 365 日以内に使用されたパスワードの再利用を禁止するグローバル パスワード再利用ポリシーを確立するには、次のようにします。 diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 1b8c56a1c768e..32ec4a16f3cfb 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -9,7 +9,7 @@ summary: PD 構成ファイルについて学習します。 PD設定ファイルは、コマンドラインパラメータよりも多くのオプションをサポートしています。デフォルトの設定ファイルは[ここ](https://github.com/tikv/pd/blob/release-8.5/conf/config.toml)あります。 -このドキュメントでは、コマンドラインパラメータに含まれないパラメータについてのみ説明します。コマンドラインパラメータについては、 [ここ](/command-line-flags-for-pd-configuration.md)参照してください。 +このドキュメントでは、コマンドラインパラメータに含まれないパラメータについてのみ説明します。コマンドラインパラメータについては、 [ここ](/command-line-flags-for-pd-configuration.md)を参照してください。 > **ヒント：** > @@ -213,7 +213,7 @@ pd-server関連のコンフィグレーション項目 - PDログでログ編集を有効にするかどうかを制御します - オプション`true` `"marker"` `false` - デフォルト値: `false` -- 使用方法の詳細については、 [PD側でのログ編集](/log-redaction.md#log-redaction-in-pd-side)参照してください。 +- 使用方法の詳細については、 [PD側でのログ編集](/log-redaction.md#log-redaction-in-pd-side)を参照してください。 ## `log` {#log} @@ -306,7 +306,7 @@ pd-server関連のコンフィグレーション項目 > **警告：** > -> この設定項目を1より大きい値に設定すると、同時チェックが有効になります。これは実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/tikv/pd/issues)報告してください。 +> この設定項目を1より大きい値に設定すると、同時チェックが有効になります。これは実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/tikv/pd/issues)を報告してください。 - リージョンのヘルス状態を検査する際にチェッカーによって作成される同時実行数[オペレーター](/glossary.md#operator)を制御します。通常、この設定を調整する必要はありません。 - デフォルト値: `1` @@ -492,7 +492,7 @@ pd-server関連のコンフィグレーション項目 > **注記：** > -> バージョン5.2以降、ラベル関連の設定項目は非推奨となりました。レプリカポリシーの設定には[配置ルール](/configure-placement-rules.md#scenario-2-place-five-replicas-in-three-data-centers-in-the-proportion-of-221-and-the-leader-should-not-be-in-the-third-data-center)使用することをお勧めします。 +> バージョン5.2以降、ラベル関連の設定項目は非推奨となりました。レプリカポリシーの設定には[配置ルール](/configure-placement-rules.md#scenario-2-place-five-replicas-in-three-data-centers-in-the-proportion-of-221-and-the-leader-should-not-be-in-the-third-data-center)を使用することをお勧めします。 ### key （非推奨） {#code-key-code-deprecated} @@ -533,7 +533,7 @@ pd-server関連のコンフィグレーション項目 - TiDB Dashboardがリバース プロキシの背後でアクセスされる場合、この項目はすべての Web リソースのパブリック URL パス プレフィックスを設定します。 - デフォルト値: `/dashboard` -- リバースプロキシを経由せずにTiDB Dashboardにアクセスする場合は、この設定項目を変更**しないで**ください。変更すると、アクセスの問題が発生する可能性があります。詳細は[リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)参照してください。 +- リバースプロキシを経由せずにTiDB Dashboardにアクセスする場合は、この設定項目を変更**しないで**ください。変更すると、アクセスの問題が発生する可能性があります。詳細は[リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 ### `enable-telemetry` {#enable-telemetry} diff --git a/pd-control.md b/pd-control.md index 4f8fe35565d57..17bd2bc11be84 100644 --- a/pd-control.md +++ b/pd-control.md @@ -313,7 +313,7 @@ tiup ctl:v pd -u https://127.0.0.1:2379 --cacert="path/to/ca" - config set cluster-version 8.5.5 // Set the version of the cluster to 8.5.5 ``` -- `replication-mode`デュアルデータセンターシナリオにおけるリージョンのレプリケーションモードを制御します。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)参照してください。 +- `replication-mode`デュアルデータセンターシナリオにおけるリージョンのレプリケーションモードを制御します。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)を参照してください。 - `leader-schedule-policy`はリーダーのスケジューリング戦略を選択するために使用されます。2 または`size`に従ってリーダー`count`スケジュールできます。 @@ -468,7 +468,7 @@ config set service-middleware rate-limit GetRegion concurrency 0 ### `config placement-rules [disable | enable | load | save | show | rule-group]` {#config-placement-rules-disable-enable-load-save-show-rule-group} -`config placement-rules [disable | enable | load | save | show | rule-group]`の使い方については[配置ルールを構成する](/configure-placement-rules.md#configure-rules)参照してください。 +`config placement-rules [disable | enable | load | save | show | rule-group]`の使い方については[配置ルールを構成する](/configure-placement-rules.md#configure-rules)を参照してください。 ### `health` {#health} @@ -565,7 +565,7 @@ v8.5.7 以降では、 `hot read`および`hot history`コマンドの出力に` > **注記：** > -> 本番環境では、 `member delete`コマンドを使用して PD ノードを削除**しないでください**。PD ノードを削除するには、 [TiDB/PD/TiKV クラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tidbpdtikv-cluster)と[Kubernetes 上で TiDB を手動でスケールする](https://docs.pingcap.com/tidb-in-kubernetes/stable/scale-a-tidb-cluster/)参照してください。 +> 本番環境では、 `member delete`コマンドを使用して PD ノードを削除**しないでください**。PD ノードを削除するには、 [TiDB/PD/TiKV クラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tidbpdtikv-cluster)と[Kubernetes 上で TiDB を手動でスケールする](https://docs.pingcap.com/tidb-in-kubernetes/stable/scale-a-tidb-cluster/)を参照してください。 このコマンドを使用して、PD メンバーを表示したり、指定されたメンバーを削除したり、リーダーの優先度を設定したりします。 @@ -1281,7 +1281,7 @@ store weight 1 5 10 #### ストアスケジュールの速度を設定する {#configure-store-scheduling-speed} -`store limit`使ってストアのスケジュール速度を設定できます。 `store limit`の原理と使用方法の詳細については、 [`store limit`](/configure-store-limit.md)参照してください。 +`store limit`使ってストアのスケジュール速度を設定できます。 `store limit`の原理と使用方法の詳細については、 [`store limit`](/configure-store-limit.md)を参照してください。 ```bash >> store limit // Show the speed limit of adding-peer operations and the limit of removing-peer operations per minute in all stores @@ -1299,7 +1299,7 @@ store weight 1 5 10 > **注記：** > -> `pd-ctl`使用すると、TiKVストアの状態（ `Up` 、 `Disconnect` 、 `Offline` 、 `Down` 、または`Tombstone` ）を確認できます。各状態の関係については、 [TiKVストアの各状態間の関係](/tidb-scheduling.md#information-collection)参照してください。 +> `pd-ctl`使用すると、TiKVストアの状態（ `Up` 、 `Disconnect` 、 `Offline` 、 `Down` 、または`Tombstone` ）を確認できます。各状態の関係については、 [TiKVストアの各状態間の関係](/tidb-scheduling.md#information-collection)を参照してください。 ### `log [fatal | error | warn | info | debug]` {#log-fatal-error-warn-info-debug} diff --git a/pd-microservices-deployment-topology.md b/pd-microservices-deployment-topology.md index 62c248494579a..b5b2c84280a11 100644 --- a/pd-microservices-deployment-topology.md +++ b/pd-microservices-deployment-topology.md @@ -80,14 +80,14 @@ grafana_servers: -前述の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ構成ファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 +前述の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ構成ファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 ### 主なパラメータ {#key-parameters} - `tso_servers`のインスタンスのレベル`host`構成では、ドメイン名ではなく IP アドレスのみがサポートされます。 -- TSO 構成項目の詳細については、 [TSO 構成ファイル](/tso-configuration-file.md)参照してください。 +- TSO 構成項目の詳細については、 [TSO 構成ファイル](/tso-configuration-file.md)を参照してください。 - `scheduling_servers`のインスタンスのレベル`host`構成では、ドメイン名ではなく IP アドレスのみがサポートされます。 -- スケジュール設定項目の詳細については、 [スケジュール設定ファイル](/scheduling-configuration-file.md)参照してください。 +- スケジュール設定項目の詳細については、 [スケジュール設定ファイル](/scheduling-configuration-file.md)を参照してください。 > **注記：** > diff --git a/pd-microservices.md b/pd-microservices.md index 7d15867516ad5..2919aac4baef4 100644 --- a/pd-microservices.md +++ b/pd-microservices.md @@ -40,7 +40,7 @@ PDマイクロサービスは通常、PDにおけるパフォーマンスのボ ## 使用法 {#usage} -PD マイクロサービスは[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/)または[TiUP](/tiup/tiup-overview.md)使用してデプロイできます。 +PD マイクロサービスは[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/)または[TiUP](/tiup/tiup-overview.md)を使用してデプロイできます。
diff --git a/pd-recover.md b/pd-recover.md index 38275c058e30b..e48967e9c3568 100644 --- a/pd-recover.md +++ b/pd-recover.md @@ -18,7 +18,7 @@ PD RecoverはPDのディザスタリカバリツールであり、正常に起 ## TiDB Toolkitをダウンロード {#download-tidb-toolkit} -PD Recover インストール パッケージは、 TiDB Toolkitに含まれています。 TiDB Toolkitをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)参照してください。 +PD Recover インストール パッケージは、 TiDB Toolkitに含まれています。 TiDB Toolkitをダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)を参照してください。 以下のセクションでは、PDクラスタを復旧するための2つの方法、すなわち、稼働中のPDノードからの復旧と、PDクラスタ全体の再構築について説明します。 diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index 01c62fb912b09..c6ecd53f93361 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -5,7 +5,7 @@ summary: データベース時間に基づいてデータベース システム # パフォーマンス分析とチューニング {#performance-analysis-and-tuning} -このドキュメントでは、データベース時間によるチューニング方法について説明し、パフォーマンス分析とチューニングに TiDB [パフォーマンス概要ダッシュボード](/grafana-performance-overview-dashboard.md)使用する方法を示します。 +このドキュメントでは、データベース時間によるチューニング方法について説明し、パフォーマンス分析とチューニングに TiDB [パフォーマンス概要ダッシュボード](/grafana-performance-overview-dashboard.md)を使用する方法を示します。 このドキュメントで説明する手法を用いることで、ユーザー応答時間とデータベース時間をグローバルかつトップダウンの視点から分析し、ユーザー応答時間のボトルネックがデータベースの問題に起因するかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要とSQLレイテンシーの内訳を使用してボトルネックを特定し、パフォーマンスを調整できます。 diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index 4a38d9b2bb39d..8638142b59c15 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -99,7 +99,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー - ボトルネックがデータベースにない場合は、データベース外で収集されたリソース使用率に頼るか、アプリケーションのプロファイリングを行ってデータベース外のボトルネックを特定する必要があります。一般的なシナリオとしては、アプリケーションまたはプロキシサーバーのリソース不足、アプリケーション内のシリアルポイントに起因するハードウェアリソースの使用不足などが挙げられます。 - ボトルネックがデータベースにある場合は、包括的なチューニングツールを使用してデータベースのパフォーマンスを分析・診断できます。一般的なシナリオとしては、低速なSQL、アプリケーションによるデータベースの不適切な使用、データベースの読み取りおよび書き込みのホットスポットの存在などが挙げられます。 -分析および診断方法とツールの詳細については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md)参照してください。 +分析および診断方法とツールの詳細については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md)を参照してください。 ### ステップ4. チューニングソリューションを提案し、各ソリューションの利点、リスク、コストを評価する {#step-4-propose-tuning-solutions-and-evaluate-the-benefits-risks-and-costs-of-each-solution} diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index a104543980128..9cd6d45b7aa42 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -424,7 +424,7 @@ QPSは34.9kから40.9kに増加し、KVリクエストタイプはフェーズ`e - パフォーマンス分析とチューニングには、TiDB Dashboard (たとえば、 Top SQL機能や継続的なプロファイリング機能) とパフォーマンス概要ダッシュボードを使用することをお勧めします。 - [Top SQL](/dashboard/top-sql.md)機能を使用すると、実行中にデータベース内の各 SQL ステートメントの CPU 消費量を視覚的に監視および調査して、データベースのパフォーマンスの問題をトラブルシューティングできます。 - - [継続的なプロファイリング](/dashboard/continuous-profiling.md)使用すると、TiDB、TiKV、PD の各インスタンスからパフォーマンスデータを継続的に収集できます。アプリケーションが TiDB とやり取りするために異なるインターフェースを使用する場合、TiDB の CPU 消費量に大きな差が生じます。 - - [パフォーマンス概要ダッシュボード](/grafana-performance-overview-dashboard.md)使用すると、データベース時間とSQL実行時間の内訳情報の概要を取得できます。データベース時間に基づいてパフォーマンスを分析・診断することで、システム全体のパフォーマンスボトルネックがTiDBにあるかどうかを判断できます。ボトルネックがTiDBにある場合は、データベース時間とレイテンシーの内訳、負荷プロファイル、リソース使用率を使用して、TiDB内のパフォーマンスボトルネックを特定し、それに応じてパフォーマンスを調整できます。 + - [継続的なプロファイリング](/dashboard/continuous-profiling.md)を使用すると、TiDB、TiKV、PD の各インスタンスからパフォーマンスデータを継続的に収集できます。アプリケーションが TiDB とやり取りするために異なるインターフェースを使用する場合、TiDB の CPU 消費量に大きな差が生じます。 + - [パフォーマンス概要ダッシュボード](/grafana-performance-overview-dashboard.md)を使用すると、データベース時間とSQL実行時間の内訳情報の概要を取得できます。データベース時間に基づいてパフォーマンスを分析・診断することで、システム全体のパフォーマンスボトルネックがTiDBにあるかどうかを判断できます。ボトルネックがTiDBにある場合は、データベース時間とレイテンシーの内訳、負荷プロファイル、リソース使用率を使用して、TiDB内のパフォーマンスボトルネックを特定し、それに応じてパフォーマンスを調整できます。 これらの機能を組み合わせて使用​​することで、実際のアプリケーションのパフォーマンスを効率的に分析および調整できます。 diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index 68a100174b989..e93ea679cb32c 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -136,7 +136,7 @@ TiDBは、悲観的トランザクションモードにおいて、以下の2つ > **注記：** > - > この分離レベルでは、最新のコミットされたデータに基づいて DML 操作が実行されます。動作は MySQL と同じですが、TiDB の楽観的トランザクション モードとは異なります。 [TiDBとMySQLのリピータブルリードの違い](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)参照してください。 + > この分離レベルでは、最新のコミットされたデータに基づいて DML 操作が実行されます。動作は MySQL と同じですが、TiDB の楽観的トランザクション モードとは異なります。 [TiDBとMySQLのリピータブルリードの違い](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)を参照してください。 - [コミット済みを読む](/transaction-isolation-levels.md#read-committed-isolation-level)。この分離レベルは[`SET TRANSACTION`](/sql-statements/sql-statement-set-transaction.md)ステートメントを使用して設定できます。 diff --git a/pipelined-dml.md b/pipelined-dml.md index 51f04639ac86e..be1a3b766911b 100644 --- a/pipelined-dml.md +++ b/pipelined-dml.md @@ -95,7 +95,7 @@ SELECT @@tidb_last_txn_info; ## ベストプラクティス {#best-practices} - Executorなどのコンポーネントのメモリ使用量が制限を超えないように、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)の値を少し増やしてください。少なくとも2GiBの値を推奨します。十分なTiDBメモリがある環境では、この値をさらに増やすことができます。 -- 新しいテーブルにデータを挿入するシナリオでは、パイプラインDMLのパフォーマンスがホットスポットの影響を受ける可能性があります。最適なパフォーマンスを実現するには、事前にホットスポットに対処することをお勧めします。詳細については、 [ホットスポットの問題のトラブルシューティング](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues)参照してください。 +- 新しいテーブルにデータを挿入するシナリオでは、パイプラインDMLのパフォーマンスがホットスポットの影響を受ける可能性があります。最適なパフォーマンスを実現するには、事前にホットスポットに対処することをお勧めします。詳細については、 [ホットスポットの問題のトラブルシューティング](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues)を参照してください。 ## 関連構成 {#related-configurations} diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md index 7bd2c533cefac..d577d52499f8b 100644 --- a/placement-rules-in-sql.md +++ b/placement-rules-in-sql.md @@ -366,7 +366,7 @@ CREATE PLACEMENT POLICY singleaz CONSTRAINTS="[+region=us-east-1]" SURVIVAL_PREF > **注記：** > -> `SURVIVAL_PREFERENCES` PD の`location-labels`と同等です。詳細については、[トポロジーラベルによるレプリカのスケジュール設定](/schedule-replicas-by-topology-labels.md)参照してください。 +> `SURVIVAL_PREFERENCES` PD の`location-labels`と同等です。詳細については、[トポロジーラベルによるレプリカのスケジュール設定](/schedule-replicas-by-topology-labels.md)を参照してください。 @@ -374,7 +374,7 @@ CREATE PLACEMENT POLICY singleaz CONSTRAINTS="[+region=us-east-1]" SURVIVAL_PREF > **注記：** > -> `SURVIVAL_PREFERENCES` PD の`location-labels`と同等です。詳細については、 [トポロジーラベルによるレプリカのスケジュール設定](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)参照してください。 +> `SURVIVAL_PREFERENCES` PD の`location-labels`と同等です。詳細については、 [トポロジーラベルによるレプリカのスケジュール設定](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)を参照してください。 diff --git a/privilege-management.md b/privilege-management.md index 9325d6e9855c5..0587a262269c1 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -244,7 +244,7 @@ SHOW GRANTS FOR `rw_user`@`192.168.%`; - `RESTRICTED_VARIABLES_ADMIN`は、SEM が有効になっている場合に、権限所有者がすべてのシステム変数を表示できるようにします。 - `RESTRICTED_USER_ADMIN` SEM が有効になっている場合、特権所有者が SUPER ユーザーによってアクセス権を取り消されることを禁止します。 - `RESTRICTED_CONNECTION_ADMIN`権限所有者が`RESTRICTED_USER_ADMIN`ユーザーの接続を強制終了することを許可します。この権限は`KILL`および`KILL TIDB`ステートメントに影響します。 -- `RESTRICTED_REPLICA_WRITER_ADMIN`使用すると、TiDB クラスタで読み取り専用モードが有効になっている場合でも、権限所有者は影響を受けることなく書き込みまたは更新操作を実行できます。詳細については、 [`tidb_restricted_read_only`](/system-variables.md#tidb_restricted_read_only-new-in-v520)参照してください。 +- `RESTRICTED_REPLICA_WRITER_ADMIN`使用すると、TiDB クラスタで読み取り専用モードが有効になっている場合でも、権限所有者は影響を受けることなく書き込みまたは更新操作を実行できます。詳細については、 [`tidb_restricted_read_only`](/system-variables.md#tidb_restricted_read_only-new-in-v520)を参照してください。 動的権限の全セットを確認するには、 `SHOW PRIVILEGES`ステートメントを実行してください。プラグインは新しい権限を追加できるため、割り当て可能な権限のリストは、TiDB のインストール環境によって異なる場合があります。 diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index e506b08ed8e96..243164dd3ec62 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -261,8 +261,8 @@ alertmanager_servers: > > - グローバルに適用されるべきパラメータについては、設定ファイルの`server_configs`セクションで、対応するコンポーネントのこれらのパラメータを設定します。 > - 特定のノードで有効にするパラメータについては、このノードの`config`でこれらのパラメータを設定します。 -> - `.`を使用して、構成のサブカテゴリを指定します (例: `log.slow-threshold` 。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)参照してください。 -> - 対象マシン上に作成するユーザーグループ名を指定する必要がある場合は、 [この例](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml#L7)参照してください。 +> - `.`を使用して、構成のサブカテゴリを指定します (例: `log.slow-threshold` 。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)を参照してください。 +> - 対象マシン上に作成するユーザーグループ名を指定する必要がある場合は、 [この例](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml#L7)を参照してください。 設定の詳細については、以下の設定例を参照してください。 @@ -395,7 +395,7 @@ TiDBクラスタとともに[TiCDC](/ticdc/ticdc-overview.md)をデプロイし - [TiCDCのトラブルシューティング](/ticdc/troubleshoot-ticdc.md) - [TiCDCに関するよくある質問](/ticdc/ticdc-faq.md) -オンライン サービスを中断せずに TiDB クラスターをスケールアウトまたはスケールインしたい場合は、 [TiUPを使用してTiDBクラスタをスケーリングする](/scale-tidb-using-tiup.md)参照してください。 +オンライン サービスを中断せずに TiDB クラスターをスケールアウトまたはスケールインしたい場合は、 [TiUPを使用してTiDBクラスタをスケーリングする](/scale-tidb-using-tiup.md)を参照してください。 ## 関連リソース {#related-resources} diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index e382fde3078b8..d637ce9fda7e2 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -188,7 +188,7 @@ limit 10; `EXPLAIN`ステートメントの結果に`ExchangeSender`と`ExchangeReceiver`演算子が表示されている場合は、MPP モードが有効になっていることを示します。 -さらに、クエリ全体の各部分をTiFlashエンジンのみを使用して計算するように指定することもできます。詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)参照してください。 +さらに、クエリ全体の各部分をTiFlashエンジンのみを使用して計算するように指定することもできます。詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)を参照してください。 これら 2 つの方法のクエリ結果とクエリ パフォーマンスを比較できます。 diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 997ca9ebad1cc..8721fff288e6b 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -70,7 +70,7 @@ summary: TiUP Playgroundを使ってTiDB Self-Managedを素早く使い始める > **注記：** > > - 以下の方法で運用されるPlaygroundの場合、デプロイとテストが完了すると、 TiUPは自動的にクラスタデータをクリーンアップします。コマンドを再実行すると、新しいクラスタが作成されます。 - > - データをストレージに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスタの起動時に、データを保存するタグを指定します](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)参照してください。 + > - データをストレージに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスタの起動時に、データを保存するタグを指定します](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)を参照してください。 > > ```shell > tiup playground --tag ${tag_name} @@ -184,7 +184,7 @@ summary: TiUP Playgroundを使ってTiDB Self-Managedを素早く使い始める > **注記：** > > - 以下の方法で運用されるPlaygroundの場合、デプロイとテストが完了すると、 TiUPは自動的にクラスタデータをクリーンアップします。コマンドを再実行すると、新しいクラスタが作成されます。 - > - データをストレージに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスタの起動時に、データを保存するタグを指定します](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)参照してください。 + > - データをストレージに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスタの起動時に、データを保存するタグを指定します](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)を参照してください。 > > ```shell > tiup playground --tag ${tag_name} @@ -465,7 +465,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 tiup cluster display ``` - `tiup cluster`コマンドの詳細については、 [TiUPクラスタコマンド](/tiup/tiup-component-cluster.md)参照してください。 + `tiup cluster`コマンドの詳細については、 [TiUPクラスタコマンド](/tiup/tiup-component-cluster.md)を参照してください。 11. テスト後にクラスターをクリーンアップしてください。 @@ -481,7 +481,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 ローカルテスト環境用にTiDBクラスタをデプロイしたばかりの場合は、次の手順を実行してください。 -- TiDB における基本的な SQL 操作については、 [TiDBにおける基本的なSQL操作](/basic-sql-operations.md)参照してください。 +- TiDB における基本的な SQL 操作については、 [TiDBにおける基本的なSQL操作](/basic-sql-operations.md)を参照してください。 - データをTiDBに移行するを参照して、TiDBにデータを[データをTiDBに移行する](/migration-overview.md)することもできます。 - TiUPを使用して TiDB クラスターを管理する方法について詳しくは、 [TiUPの概要](/tiup/tiup-overview.md)を参照してください。 diff --git a/read-historical-data.md b/read-historical-data.md index a6610a8210ec4..da21b7bc55555 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -40,7 +40,7 @@ TiDB は、特別なクライアントやドライバーを使用せずに、標 TiDBは、データのバージョン管理にマルチバージョン同時実行制御（MVCC）を実装しています。データの履歴バージョンは保持されます。これは、更新/削除のたびにデータオブジェクトの新しいバージョンが作成されるためです。データオブジェクトをその場で更新/削除するのではなく、新しいバージョンが作成されます。ただし、すべてのバージョンが保持されるわけではありません。特定の時間よりも古いバージョンは完全に削除され、履歴バージョンの過剰によって発生するストレージの占有量とパフォーマンスのオーバーヘッドを削減します。 -TiDBでは、ガベージコレクション（GC）が定期的に実行され、古いデータバージョンが削除されます。GCの詳細については、 [TiDB ガベージコレクション (GC)](/garbage-collection-overview.md)参照してください。 +TiDBでは、ガベージコレクション（GC）が定期的に実行され、古いデータバージョンが削除されます。GCの詳細については、 [TiDB ガベージコレクション (GC)](/garbage-collection-overview.md)を参照してください。 以下の点に特に注意してください。 @@ -172,6 +172,6 @@ SET GLOBAL tidb_gc_life_time="60m"; 以前のバージョンからデータを復元するには、次のいずれかの方法を使用できます。 -- 単純なケースでは、変数`tidb_snapshot`設定した後に[`SELECT`](/sql-statements/sql-statement-select.md)使用して出力をコピーして貼り付けるか、 `SELECT ... INTO OUTFILE`使用し、後で[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)使用してデータをインポートします。 +- 単純なケースでは、変数`tidb_snapshot`設定した後に[`SELECT`](/sql-statements/sql-statement-select.md)を使用して出力をコピーして貼り付けるか、 `SELECT ... INTO OUTFILE`使用し、後で[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)を使用してデータをインポートします。 -- 履歴スナップショットをエクスポートするには[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-historical-data-snapshots-of-tidb)使用します。Dumplingは、より大きなデータセットのエクスポートに適しています。 +- 履歴スナップショットをエクスポートするには[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-historical-data-snapshots-of-tidb)を使用します。Dumplingは、より大きなデータセットのエクスポートに適しています。 diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index f5da598351afb..8301d469537e2 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -51,7 +51,7 @@ summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性 - ハッシュ結合の実行を最適化します。結合タイプが内部結合またはセミ結合で、内部テーブルが空の場合、外部テーブルからデータを読み取らずに結果を返します。 - - [`EXPLAIN ANALYZE`ステートメント](/sql-statements/sql-statement-explain-analyze.md)使用して、各演算子の実行時間と返された行数を含む実行時統計をチェックすることをサポートします。 + - [`EXPLAIN ANALYZE`ステートメント](/sql-statements/sql-statement-explain-analyze.md)を使用して、各演算子の実行時間と返された行数を含む実行時統計をチェックすることをサポートします。 - 統計 diff --git a/releases/release-2.1.15.md b/releases/release-2.1.15.md index f27996dc429b7..732250d89cc27 100644 --- a/releases/release-2.1.15.md +++ b/releases/release-2.1.15.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 2.1.15 - 監査プラグインにセッション接続情報を追加する [＃11189](https://github.com/pingcap/tidb/pull/11189) - ポイントクエリで列を複数回クエリし、返された結果が`NULL`ある場合に発生するpanic問題を修正しました。 [＃11227](https://github.com/pingcap/tidb/pull/11227) - テーブルを作成するときに、散布テーブルRegionsに`tidb_scatter_region`構成項目を追加します。 [＃11213](https://github.com/pingcap/tidb/pull/11213) -- `RAND`関数使用する際に非スレッドセーフ`rand.Rand`によって発生するデータ競合問題を修正 [＃11170](https://github.com/pingcap/tidb/pull/11170) +- `RAND`関数を使用する際に非スレッドセーフ`rand.Rand`によって発生するデータ競合問題を修正 [＃11170](https://github.com/pingcap/tidb/pull/11170) - 整数と非整数の比較結果が場合によっては正しくない問題を修正[＃11191](https://github.com/pingcap/tidb/pull/11191) - データベースまたはテーブルの照合順序の変更をサポートしますが、データベース/テーブルの文字セットは UTF-8 または utf8mb4 である必要があります。 [＃11085](https://github.com/pingcap/tidb/pull/11085) - 列のデフォルト値として`CURRENT_TIMESTAMP`使用され、float精度が指定されている場合、 `SHOW CREATE TABLE`ステートメントで表示される精度が不完全になる問題を修正しました。 [＃11087](https://github.com/pingcap/tidb/pull/11087) diff --git a/releases/release-2.1.16.md b/releases/release-2.1.16.md index c5bf93b16facd..cf1afbc3f22d0 100644 --- a/releases/release-2.1.16.md +++ b/releases/release-2.1.16.md @@ -61,6 +61,6 @@ TiDB Ansible バージョン: 2.1.16 - Spark に`log4j`設定ファイルを追加する [＃842](https://github.com/pingcap/tidb-ansible/pull/842) - tispark jarパッケージをv2.1.2 に更新します [＃863](https://github.com/pingcap/tidb-ansible/pull/863) -- TiDB Binlog がKafka または ZooKeeper 使用する場合に Prometheus 構成ファイルが間違った形式で生成される問題を修正しました [＃845](https://github.com/pingcap/tidb-ansible/pull/845) +- TiDB Binlog がKafka または ZooKeeper を使用する場合に Prometheus 構成ファイルが間違った形式で生成される問題を修正しました [＃845](https://github.com/pingcap/tidb-ansible/pull/845) - `rolling_update.yml`オペレーション実行時にPDがLeaderの切り替えに失敗するバグを修正 [＃888](https://github.com/pingcap/tidb-ansible/pull/888) - PDノードのローリング更新ロジックを最適化 - フォロワーを最初にアップグレードし、次にLeaderをアップグレード - 安定性を向上[＃895](https://github.com/pingcap/tidb-ansible/pull/895) diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index b32a468be3cbd..64e17381c86c1 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -48,7 +48,7 @@ TiDB Ansible バージョン: 2.1.18 - スロークエリログの`COM_STMT_FETCH`時間レコードがMySQLのものと矛盾する問題を修正しました。 [＃12953](https://github.com/pingcap/tidb/pull/12953) - 書き込み競合のエラーメッセージにエラーコードを追加して、原因を素早く特定します[＃12878](https://github.com/pingcap/tidb/pull/12878) - DDL - - デフォルトでは、列の`AUTO INCREMENT`の属性の削除は許可されません。この属性を削除する必要がある場合は、 `tidb_allow_remove_auto_inc`の変数の値を変更してください。詳細は[システム変数](/system-variables.md#tidb_allow_remove_auto_inc-new-in-v2118-and-v304)参照してください[＃12146](https://github.com/pingcap/tidb/pull/12146) + - デフォルトでは、列の`AUTO INCREMENT`の属性の削除は許可されません。この属性を削除する必要がある場合は、 `tidb_allow_remove_auto_inc`の変数の値を変更してください。詳細は[システム変数](/system-variables.md#tidb_allow_remove_auto_inc-new-in-v2118-and-v304)を参照してください[＃12146](https://github.com/pingcap/tidb/pull/12146) - `Create Table`文で一意インデックスを作成するときに複数の`unique`をサポートする [＃12469](https://github.com/pingcap/tidb/pull/12469) - `CREATE TABLE`ステートメントの外部キー制約にスキーマがない場合、 `No Database selected`エラーを返す代わりに、作成されたテーブルのスキーマを使用するという互換性の問題を修正しました。 [＃12678](https://github.com/pingcap/tidb/pull/12678) - `ADMIN CANCEL DDL JOBS` 実行時に`invalid list index`エラーが報告される問題を修正 [＃12681](https://github.com/pingcap/tidb/pull/12681) diff --git a/releases/release-2.1.5.md b/releases/release-2.1.5.md index 7e296edf42396..730a6a67707a6 100644 --- a/releases/release-2.1.5.md +++ b/releases/release-2.1.5.md @@ -23,7 +23,7 @@ summary: TiDB 2.1.5とTiDB Ansible 2.1.5は、2019年2月28日にリリースさ - `RAND()`関数の結果がMySQL と互換性がない問題を修正 [＃9446](https://github.com/pingcap/tidb/pull/9446) - `Semi Join`処理`NULL`と空の結果セットのロジックをリファクタリングして正しい結果を取得し、MySQL との互換性を向上させます。 [＃9449](https://github.com/pingcap/tidb/pull/9449) - サーバ - - `INSERT`ステートメント実行するときにデータの一意性制約をチェックするための`tidb_constraint_check_in_place`システム変数を追加します。 [＃9401](https://github.com/pingcap/tidb/pull/9401) + - `INSERT`ステートメントを実行するときにデータの一意性制約をチェックするための`tidb_constraint_check_in_place`システム変数を追加します。 [＃9401](https://github.com/pingcap/tidb/pull/9401) - `tidb_force_priority`システム変数の値が設定ファイルに設定されている値と異なる問題を修正しました [＃9347](https://github.com/pingcap/tidb/pull/9347) - 一般ログに`current_db`フィールドを追加して、現在使用されているデータベースの名前を出力します。 [＃9346](https://github.com/pingcap/tidb/pull/9346) - テーブルID のテーブル情報を取得するHTTP APIを追加します。 [＃9408](https://github.com/pingcap/tidb/pull/9408) diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index e0bf7c0a6c5e2..d959c41075369 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -47,7 +47,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - 異なるユーザー変数が入力されたときにクエリプランが正しいことを保証するために、サブクエリを含む`Prepare`ステートメントをクエリプランキャッシュに追加することを禁止します[＃8064](https://github.com/pingcap/tidb/pull/8064) - クエリプランキャッシュを最適化して、ステートメントに非決定的な関数が含まれている場合にプランがキャッシュされることを保証します[＃8105](https://github.com/pingcap/tidb/pull/8105) - クエリプランキャッシュを最適化して、 `DELETE` / `UPDATE` / `INSERT`のクエリプランがキャッシュされることを保証する[＃8107](https://github.com/pingcap/tidb/pull/8107) - - クエリプランキャッシュを最適化して、 `DEALLOCATE`文実行するときに対応するプランを削除します。 [＃8332](https://github.com/pingcap/tidb/pull/8332) + - クエリプランキャッシュを最適化して、 `DEALLOCATE`文を実行するときに対応するプランを削除します。 [＃8332](https://github.com/pingcap/tidb/pull/8332) - クエリプランキャッシュを最適化し、メモリ使用量を制限することで、過剰なプランをキャッシュすることによって引き起こされる TiDB OOM の問題を回避します[＃8339](https://github.com/pingcap/tidb/pull/8339) - `Prepare`文を最適化して、 `ORDER BY` / `GROUP BY` / `LIMIT`句の`?`プレースホルダの使用をサポートする [＃8206](https://github.com/pingcap/tidb/pull/8206) - 権限管理 diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 5983b6c1735eb..b1e5bd24fb1d6 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -80,7 +80,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - エンジン - 読み取りトラフィックの統計情報が不正確になる可能性がある問題を修正[＃4436](https://github.com/tikv/tikv/pull/4436) - - 範囲削除するときにプレフィックス抽出プログラムがpanicを起こす可能性がある問題を修正しました [＃4503](https://github.com/tikv/tikv/pull/4503) + - 範囲を削除するときにプレフィックス抽出プログラムがpanicを起こす可能性がある問題を修正しました [＃4503](https://github.com/tikv/tikv/pull/4503) - メモリ管理を最適化してメモリ割り当てとコピーを削減`Iterator Key Bound Option` [＃4537](https://github.com/tikv/tikv/pull/4537) - ラーナーのログギャップを考慮しないと、場合によってはpanicが発生する可能性がある問題を修正しました[＃4559](https://github.com/tikv/tikv/pull/4559) - 異なる`column families` 間での`block cache`共有をサポート [＃4612](https://github.com/tikv/tikv/pull/4612) diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md index 570667b193cc1..1abf28554b338 100644 --- a/releases/release-3.0.1.md +++ b/releases/release-3.0.1.md @@ -27,7 +27,7 @@ TiDB Ansible バージョン: 3.0.1 - データベースまたはテーブルの照合順序の変更をサポートしますが、データベース/テーブルの文字セットは UTF-8 または utf8mb4 である必要があります。 [＃11086](https://github.com/pingcap/tidb/pull/11086) - `UPDATE … SELECT`文の`SELECT`サブクエリが`UPDATE`の列の解析に失敗し、列が誤ってプルーニングされたときにエラーが報告される問題を修正しました[＃11252](https://github.com/pingcap/tidb/pull/11252) - ポイントクエリ中に列が複数回クエリされ、返された結果が NULL である場合に発生するpanic問題を修正しました[＃11226](https://github.com/pingcap/tidb/pull/11226) -- `RAND`関数使用する際に非スレッドセーフ`rand.Rand`によって発生するデータ競合問題を修正 [＃11169](https://github.com/pingcap/tidb/pull/11169) +- `RAND`関数を使用する際に非スレッドセーフ`rand.Rand`によって発生するデータ競合問題を修正 [＃11169](https://github.com/pingcap/tidb/pull/11169) - `oom-action="cancel"`が設定されている場合、SQL 文のメモリ使用量がしきい値を超えているにもかかわらず、この文の実行がキャンセルされず、返される結果が正しくないというバグを修正しました[＃11004](https://github.com/pingcap/tidb/pull/11004) - MemTracker `SHOW PROCESSLIST`メモリ使用量が正しく消去されなかったため、メモリ使用量が`0`ではないと表示される問題を修正しました[＃10970](https://github.com/pingcap/tidb/pull/10970) - 整数と非整数の比較結果が場合によっては正しくないというバグを修正[＃11194](https://github.com/pingcap/tidb/pull/11194) diff --git a/releases/release-3.0.17.md b/releases/release-3.0.17.md index 7a77168b4bd66..0c6ce0b35f5ba 100644 --- a/releases/release-3.0.17.md +++ b/releases/release-3.0.17.md @@ -36,7 +36,7 @@ TiDB バージョン: 3.0.17 - `IndexHashJoin`または`IndexMergeJoin`を含むクエリがpanicに遭遇した場合、空のセットではなく実際のエラー メッセージを返します。 [＃18498](https://github.com/pingcap/tidb/pull/18498) - `SELECT a FROM t HAVING t.a` のようなSQL文の不明な列エラーを修正 [＃18432](https://github.com/pingcap/tidb/pull/18432) - テーブルに主キーがない場合、またはテーブルにすでに整数の主キーがある場合は、テーブルに主キーを追加することを禁止します[＃18342](https://github.com/pingcap/tidb/pull/18342) - - `EXPLAIN FORMAT="dot" FOR CONNECTION` 実行すると空のセットを返します [＃17157](https://github.com/pingcap/tidb/pull/17157) + - `EXPLAIN FORMAT="dot" FOR CONNECTION` を実行すると空のセットを返します [＃17157](https://github.com/pingcap/tidb/pull/17157) - フォーマットトークン '%r'、'%h' 処理を修正`STR_TO_DATE` [＃18725](https://github.com/pingcap/tidb/pull/18725) - TiKV diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index d3bb7ea323b64..4fca9e84a2ff9 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -110,7 +110,7 @@ TiDB Ansible バージョン: 3.0.2 - Scatter リージョンスケジューラが動作しないバグを修正[＃1642](https://github.com/pingcap/pd/pull/1642) - pd-ctl でマージリージョン操作が実行できないバグを修正しました [＃1653](https://github.com/pingcap/pd/pull/1653) - pd-ctl でtombstoneの削除操作が実行できないバグを修正しました [＃1651](https://github.com/pingcap/pd/pull/1651) -- スキャンリージョン操作実行するときに、キースコープと重複するリージョンが見つからない問題を修正しました [＃1648](https://github.com/pingcap/pd/pull/1648) +- スキャンリージョン操作を実行するときに、キースコープと重複するリージョンが見つからない問題を修正しました [＃1648](https://github.com/pingcap/pd/pull/1648) - PD にメンバーが正常に追加されたことを確認するための再試行メカニズムを追加します。 [＃1643](https://github.com/pingcap/pd/pull/1643) ## ツール {#tools} diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 596a8e3148de6..85bfbc844434a 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -72,7 +72,7 @@ TiDB Ansible バージョン: 3.0.5 - リージョンが占有するストレージの精度を向上 [＃1782](https://github.com/pingcap/pd/pull/1782) - `--help`コマンドの出力を改善する [＃1763](https://github.com/pingcap/pd/pull/1763) - TLS を有効にした後に HTTP リクエストがリダイレクトに失敗する問題を修正[＃1777](https://github.com/pingcap/pd/pull/1777) -- pd-ctlが`store shows limit`コマンド使用する際に発生するpanic問題を修正 [＃1808](https://github.com/pingcap/pd/pull/1808) +- pd-ctlが`store shows limit`コマンドを使用する際に発生するpanic問題を修正 [＃1808](https://github.com/pingcap/pd/pull/1808) - ラベル監視メトリクスの可読性を向上させ、リーダーが切り替わるときに元のリーダーの監視データをリセットして、誤ったレポートを回避する[＃1815](https://github.com/pingcap/pd/pull/1815) ## ツール {#tools} diff --git a/releases/release-3.1.0-ga.md b/releases/release-3.1.0-ga.md index 11c9ad4f498a7..3eb7c0eb2d045 100644 --- a/releases/release-3.1.0-ga.md +++ b/releases/release-3.1.0-ga.md @@ -28,7 +28,7 @@ TiDB Ansible バージョン: 3.1.0 GA - TiDB - `explain format = "dot"` のコプロセッサータスク情報の表示をサポート [＃16125](https://github.com/pingcap/tidb/pull/16125) - - `disable-error-stack`設定項目使用してログの冗長スタック情報を削減する [＃16182](https://github.com/pingcap/tidb/pull/16182) + - `disable-error-stack`設定項目を使用してログの冗長スタック情報を削減する [＃16182](https://github.com/pingcap/tidb/pull/16182) - Placement Driver（PD） diff --git a/releases/release-3.1.0-rc.md b/releases/release-3.1.0-rc.md index 3818654d11437..2148f4c89537c 100644 --- a/releases/release-3.1.0-rc.md +++ b/releases/release-3.1.0-rc.md @@ -76,7 +76,7 @@ TiDB Ansible バージョン: 3.1.0-rc - プッシュダウンできない述語がある場合、 `Aggregation`プッシュダウンと`TopN`プッシュダウンを禁止する[＃15141](https://github.com/pingcap/tidb/pull/15141) - ネストされた`view`作成を禁止する [＃15440](https://github.com/pingcap/tidb/pull/15440) - `SET ROLE ALL` の後に`SELECT CURRENT_ROLE()`実行したときに発生したエラーを修正 [＃15570](https://github.com/pingcap/tidb/pull/15570) - - `select view_name.col_name from view_name`文実行するときに`view`名前を識別できない問題を修正 [＃15573](https://github.com/pingcap/tidb/pull/15573) + - `select view_name.col_name from view_name`文を実行するときに`view`名前を識別できない問題を修正 [＃15573](https://github.com/pingcap/tidb/pull/15573) - binlog情報書き込み中にDDL文を前処理するとエラーが発生する可能性がある問題を修正 [＃15444](https://github.com/pingcap/tidb/pull/15444) - `view` s とパーティションテーブル両方にアクセスする際に発生するpanicを修正 [＃15560](https://github.com/pingcap/tidb/pull/15560) - `bit(n)`データ型を含む`update duplicate key`ステートメントで`VALUES`関数を実行したときに発生したエラーを修正します [＃15487](https://github.com/pingcap/tidb/pull/15487) diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 2033849fa94e9..b3870c225b47e 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -36,7 +36,7 @@ TiDB バージョン: 4.0.0 - TiDBサーバーが使用する一時ディスク領域を制限するための`tmp-storage-quota`構成項目を追加します [＃15700](https://github.com/pingcap/tidb/pull/15700) - テーブルの作成時および変更時に、パーティションテーブルが一意のプレフィックスインデックスを使用しているかどうかのチェックをサポート[＃17213](https://github.com/pingcap/tidb/pull/17213) - `insert/replace into tbl_name partition` （ `partition_name_list` ）のステートメントサポートする [＃17313](https://github.com/pingcap/tidb/pull/17313) - - `Distinct`関数使用するときに`collations`の値をチェックする機能をサポート [＃17240](https://github.com/pingcap/tidb/pull/17240) + - `Distinct`関数を使用するときに`collations`の値をチェックする機能をサポート [＃17240](https://github.com/pingcap/tidb/pull/17240) - ハッシュパーティションプルーニング中の`is null`フィルタ条件をサポート [＃17310](https://github.com/pingcap/tidb/pull/17310) - パーティションテーブル[＃17392](https://github.com/pingcap/tidb/pull/17392) で`admin check index` 、 `admin cleanup index` 、 `admin recover index`サポート [＃17317](https://github.com/pingcap/tidb/pull/17317) [＃17405](https://github.com/pingcap/tidb/pull/17405) - `in`式範囲パーティションプルーニングをサポート [＃17320](https://github.com/pingcap/tidb/pull/17320) diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 40f315676641c..32773e3eaa572 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -130,7 +130,7 @@ TiDB バージョン: 4.0.0-rc.1 - 楽観的トランザクションで多くの書き込み競合が発生する場合、パフォーマンスを向上させるために`BatchRollback`で書き込まれたロールバックレコードを保護しないようにする [＃7604](https://github.com/tikv/tikv/pull/7604) - ロック競合の負荷が高いワークロードで、トランザクションの不要なウェイクアップによって無駄な再試行が発生し、パフォーマンスが低下する問題を修正しました[＃7551](https://github.com/tikv/tikv/pull/7551) - リージョンが複数回のマージでスタックする可能性がある問題を修正[＃7518](https://github.com/tikv/tikv/pull/7518) - - ラーナー削除してもラーナーが削除されない問題を修正 [＃7518](https://github.com/tikv/tikv/pull/7518) + - ラーナーを削除してもラーナーが削除されない問題を修正 [＃7518](https://github.com/tikv/tikv/pull/7518) - raft-rs でフォロワーの読み取りによってpanicが発生する可能性がある問題を修正しました [＃7408](https://github.com/tikv/tikv/pull/7408) - `group by constant`エラーによりSQL操作が失敗する可能性があるバグを修正しました [＃7383](https://github.com/tikv/tikv/pull/7383) - 対応するプライマリロックが悲観的ロックの場合に楽観的ロックが読み取りをブロックする可能性がある問題を修正[＃7328](https://github.com/tikv/tikv/pull/7328) diff --git a/releases/release-4.0.0-rc.md b/releases/release-4.0.0-rc.md index 2c64a9466923d..0d4a926a3c2ba 100644 --- a/releases/release-4.0.0-rc.md +++ b/releases/release-4.0.0-rc.md @@ -80,7 +80,7 @@ TiUPバージョン: 0.0.3 - 内部レコードのジョブクエリが正しくないため、 `PREPARE`ステートメントを使用して DDL ジョブを実行すると、上流と下流間のレプリケーションが失敗する可能性がある問題を修正しました。 [＃15435](https://github.com/pingcap/tidb/pull/15435) - 分離レベル`Read Committed` 、分離レベルでサブクエリ結果が不正確になる問題を修正 [＃15471](https://github.com/pingcap/tidb/pull/15471) - - `INSERT ... VALUES`使用して`BIT(N)`データ型指定するときに発生する可能性のある誤った動作の問題を修正しました [＃15350](https://github.com/pingcap/tidb/pull/15350) + - `INSERT ... VALUES`使用して`BIT(N)`データ型を指定するときに発生する可能性のある誤った動作の問題を修正しました [＃15350](https://github.com/pingcap/tidb/pull/15350) - `ErrorCount`の値が正しく合計されないため、DDL ジョブの内部再試行で期待どおりの結果が完全に得られない問題を修正しました[＃15373](https://github.com/pingcap/tidb/pull/15373) - TiDBがTiFlash に接続したときにガベージコレクションが異常動作する可能性がある問題を修正しました [＃15505](https://github.com/pingcap/tidb/pull/15505) - インライン投影の最適化によって誤った結果が発生する問題を修正[＃15411](https://github.com/pingcap/tidb/pull/15411) diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index 3084852117fd7..5fb340c417ab7 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -74,7 +74,7 @@ TiDB バージョン: 4.0.11 - 誤った照合順序と強制可能性を引き起こす可能性のある問題を修正[＃22602](https://github.com/pingcap/tidb/pull/22602) - 照合順序結果が誤っている可能性がある問題を修正[＃22599](https://github.com/pingcap/tidb/pull/22599) - 異なる照合順序における定数置換の問題を修正[＃22582](https://github.com/pingcap/tidb/pull/22582) - - 照合順序使用すると関数`like`間違った結果を返す可能性があるバグを修正しました [＃22531](https://github.com/pingcap/tidb/pull/22531) + - 照合順序を使用すると関数`like`間違った結果を返す可能性があるバグを修正しました [＃22531](https://github.com/pingcap/tidb/pull/22531) - `least`と`greatest`関数における誤った`duration`型推論の問題を修正 [＃22580](https://github.com/pingcap/tidb/pull/22580) - `like`関数が単一文字のワイルドカード ( `_` ) に続いて複数文字のワイルドカード ( `%` ) を処理するときに発生するバグを修正しました[＃22575](https://github.com/pingcap/tidb/pull/22575) - TiDBの組み込み関数の型推論エラーを修正（ `least`と`greatest` ） [＃22562](https://github.com/pingcap/tidb/pull/22562) @@ -94,7 +94,7 @@ TiDB バージョン: 4.0.11 - `PREPARE`文が`EXECUTE` 、 `DEALLOCATE` 、または`PREPARE` とネストされている場合はエラーを報告します。 [＃21972](https://github.com/pingcap/tidb/pull/21972) - 存在しないパーティションで`INSERT IGNORE`ステートメントが使用された場合にエラーが報告されない問題を修正しました [＃21971](https://github.com/pingcap/tidb/pull/21971) - `EXPLAIN`結果のエンコードを統一し、 遅いログ [＃21964](https://github.com/pingcap/tidb/pull/21964) - - 集計演算子使用するときに結合で不明な列が発生する問題を修正しました [＃21957](https://github.com/pingcap/tidb/pull/21957) + - 集計演算子を使用するときに結合で不明な列が発生する問題を修正しました [＃21957](https://github.com/pingcap/tidb/pull/21957) - `ceiling`関数の間違った型推論を修正 [＃21936](https://github.com/pingcap/tidb/pull/21936) - `Double`型の列が小数点無視する問題を修正しました [＃21916](https://github.com/pingcap/tidb/pull/21916) - 相関集計がサブクエリで計算される問題を修正 [＃21877](https://github.com/pingcap/tidb/pull/21877) diff --git a/releases/release-4.0.13.md b/releases/release-4.0.13.md index b54c7dfd39b98..89ae88ba08cd8 100644 --- a/releases/release-4.0.13.md +++ b/releases/release-4.0.13.md @@ -90,7 +90,7 @@ TiDB バージョン: 4.0.13 - `TableScan`が降順の場合にオプティマイザによってTiFlashが誤って選択されるバグを修正[＃23974](https://github.com/pingcap/tidb/pull/23974) - `point_get`プランがMySQL と一致しない列名を返すバグを修正しました [＃23970](https://github.com/pingcap/tidb/pull/23970) - 大文字の名前を持つデータベースで`show table status`文を実行すると間違った結果が返される問題を修正しました[＃23958](https://github.com/pingcap/tidb/pull/23958) - - テーブルに対して同時に`INSERT`と`DELETE`権限を持たないユーザーが`REPLACE`操作実行できるバグを修正しました。 [＃23938](https://github.com/pingcap/tidb/pull/23938) + - テーブルに対して同時に`INSERT`と`DELETE`権限を持たないユーザーが`REPLACE`操作を実行できるバグを修正しました。 [＃23938](https://github.com/pingcap/tidb/pull/23938) - 照合順序が正しく処理されていないため、 `concat` / `make_set` / `insert`式の結果が間違っている問題を修正しました[＃23878](https://github.com/pingcap/tidb/pull/23878) - `RANGE`パーティションを持つテーブルでクエリを実行するときに発生するpanicを修正しました [＃23689](https://github.com/pingcap/tidb/pull/23689) - 問題を修正: 以前のバージョンのクラスターで、変数`tidb_enable_table_partition` `false`に設定されている場合、パーティションを含むテーブルは非パーティションテーブルとして扱われます。クラスターを新しいバージョンにアップグレードした後、このテーブルに対して`batch point get`クエリを実行すると、接続panicが発生します[＃23682](https://github.com/pingcap/tidb/pull/23682) diff --git a/releases/release-4.0.14.md b/releases/release-4.0.14.md index d467246005927..5f058af4f1965 100644 --- a/releases/release-4.0.14.md +++ b/releases/release-4.0.14.md @@ -90,7 +90,7 @@ TiDB バージョン: 4.0.14 - キャッシュされた`prepared`プランが`point get` に誤って使用される問題を修正 [＃24741](https://github.com/pingcap/tidb/issues/24741) - `LOAD DATA`文が非 UTF8 データを異常にインポートする可能性がある問題を修正[＃25979](https://github.com/pingcap/tidb/issues/25979) - HTTP API 経由で統計情報にアクセスする際に発生する可能性のあるメモリリークの問題を修正しました [＃24650](https://github.com/pingcap/tidb/pull/24650) - - `ALTER USER`文実行するときに発生するセキュリティ問題を修正しました [＃25225](https://github.com/pingcap/tidb/issues/25225) + - `ALTER USER`文を実行するときに発生するセキュリティ問題を修正しました [＃25225](https://github.com/pingcap/tidb/issues/25225) - `TIKV_REGION_PEERS`テーブルが`DOWN`ステータス正しく処理できないバグを修正 [＃24879](https://github.com/pingcap/tidb/issues/24879) - `DateTime` の解析時に無効な文字列が切り捨てられない問題を修正 [＃22231](https://github.com/pingcap/tidb/issues/22231) - 列タイプが`YEAR` の場合に`select into outfile`文で結果が返されないことがある問題を修正しました [＃22159](https://github.com/pingcap/tidb/issues/22159) diff --git a/releases/release-4.0.2.md b/releases/release-4.0.2.md index 59f514d7152dc..117cb96241b83 100644 --- a/releases/release-4.0.2.md +++ b/releases/release-4.0.2.md @@ -102,7 +102,7 @@ TiDB バージョン: 4.0.2 - TiDB - `tidb_isolation_read_engines`が変更された後にプランキャッシュから取得される実行プランが正しくない問題を修正[＃17570](https://github.com/pingcap/tidb/pull/17570) - - `EXPLAIN FOR CONNECTION`文実行するときに時々発生するランタイムエラーを修正 [＃18124](https://github.com/pingcap/tidb/pull/18124) + - `EXPLAIN FOR CONNECTION`文を実行するときに時々発生するランタイムエラーを修正 [＃18124](https://github.com/pingcap/tidb/pull/18124) - いくつかのケースで`last_plan_from_cache`セッション変数の誤った結果を修正[＃18111](https://github.com/pingcap/tidb/pull/18111) - プランキャッシュ から`UNIX_TIMESTAMP()`関数を実行するときに発生するランタイムエラーを修正しました [＃17673](https://github.com/pingcap/tidb/pull/17673) [＃18002](https://github.com/pingcap/tidb/pull/18002) - `HashJoin` Executor の子が`NULL`列返すときのランタイムエラーを修正しました [＃17937](https://github.com/pingcap/tidb/pull/17937) diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index 6898e2545606c..80c23009ae668 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -43,7 +43,7 @@ TiDB バージョン: 4.0.9 - ユーザー変数の種類を区別する[＃21107](https://github.com/pingcap/tidb/pull/21107) - 設定ファイルの`GOGC`変数の設定をサポート [＃20922](https://github.com/pingcap/tidb/pull/20922) - ダンプされたバイナリタイム（ `Timestamp`と`Datetime` ）をMySQL との互換性を高める [＃21135](https://github.com/pingcap/tidb/pull/21135) - - `LOCK IN SHARE MODE`構文使用する文にエラーメッセージを表示する [＃21005](https://github.com/pingcap/tidb/pull/21005) + - `LOCK IN SHARE MODE`構文を使用する文にエラーメッセージを表示する [＃21005](https://github.com/pingcap/tidb/pull/21005) - ショートカット可能な式で定数を折り畳むときに不要な警告やエラーを出力しないようにする[＃21040](https://github.com/pingcap/tidb/pull/21040) - `LOAD DATA`文を準備するときにエラーが発生する [＃21199](https://github.com/pingcap/tidb/pull/21199) - 整数列の型を変更するときに整数ゼロフィルサイズの属性を無視する[＃20986](https://github.com/pingcap/tidb/pull/20986) @@ -56,7 +56,7 @@ TiDB バージョン: 4.0.9 - `split`コマンドのソースをトレースするためのタグを追加します [＃8936](https://github.com/tikv/tikv/pull/8936) - `pessimistic-txn.pipelined`構成動的な変更をサポート [＃9100](https://github.com/tikv/tikv/pull/9100) - - バックアップと復元およびTiDB Lightning 実行する際のパフォーマンスへの影響を軽減します [＃9098](https://github.com/tikv/tikv/pull/9098) + - バックアップと復元およびTiDB Lightning を実行する際のパフォーマンスへの影響を軽減します [＃9098](https://github.com/tikv/tikv/pull/9098) - SST 取り込みエラー監視メトリックを追加します [＃9096](https://github.com/tikv/tikv/pull/9096) - 一部のピアがログを複製する必要がある場合にリーダーが休止状態にならないようにします[＃9093](https://github.com/tikv/tikv/pull/9093) - パイプライン化された悲観的ロックの成功率を向上させる[＃9086](https://github.com/tikv/tikv/pull/9086) @@ -136,7 +136,7 @@ TiDB バージョン: 4.0.9 - `slow_query`のクエリ結果で一部の行が欠落する可能性がある問題を修正[＃21211](https://github.com/pingcap/tidb/pull/21211) - データベース名が純粋な下位表現でない場合、データが正しく削除れない可能性がある問題を修正しました`DELETE` [＃21206](https://github.com/pingcap/tidb/pull/21206) - DML操作後にスキーマ変更を引き起こすバグを修正[＃21050](https://github.com/pingcap/tidb/pull/21050) - - 結合使用するときに結合された列をクエリできないバグを修正しました [＃21021](https://github.com/pingcap/tidb/pull/21021) + - 結合を使用するときに結合された列をクエリできないバグを修正しました [＃21021](https://github.com/pingcap/tidb/pull/21021) - 一部のセミ結合クエリの誤った結果を修正[＃21019](https://github.com/pingcap/tidb/pull/21019) - テーブルロックが`UPDATE`文で有効にならない問題を修正 [＃21002](https://github.com/pingcap/tidb/pull/21002) - 再帰ビュー構築時に発生するスタックオーバーフローの問題を修正 [＃21001](https://github.com/pingcap/tidb/pull/21001) diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index c5dee168c68b7..64e9b6a166bda 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -13,7 +13,7 @@ TiDB バージョン: 5.1.1 - TiDB - - TiDBクラスタをv4.0からv5.1にアップグレードする場合、デフォルト値は`tidb_multi_statement_mode`ではなく`OFF`です。代わりに、クライアントライブラリのマルチステートメント機能を使用することをお勧めします。詳細は[`tidb_multi_statement_mode`に関するドキュメント](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)参照してください[＃25751](https://github.com/pingcap/tidb/pull/25751) + - TiDBクラスタをv4.0からv5.1にアップグレードする場合、デフォルト値は`tidb_multi_statement_mode`ではなく`OFF`です。代わりに、クライアントライブラリのマルチステートメント機能を使用することをお勧めします。詳細は[`tidb_multi_statement_mode`に関するドキュメント](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)を参照してください[＃25751](https://github.com/pingcap/tidb/pull/25751) - `tidb_stmt_summary_max_stmt_count`変数のデフォルト値を`200`から`3000`に変更します[＃25874](https://github.com/pingcap/tidb/pull/25874) - `table_storage_stats`テーブルアクセスするには`SUPER`権限が必要です [＃26352](https://github.com/pingcap/tidb/pull/26352) - 他のユーザーの権限表示するには、 `information_schema.user_privileges`テーブルにアクセスするために`mysql.user`の`SELECT`権限が必要です。 [＃26311](https://github.com/pingcap/tidb/pull/26311) diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index e6a0a1e98c703..0a17234c83691 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -63,7 +63,7 @@ TiDB バージョン: 5.3.1 - クエリ実行時に MPP タスク リストが空になるエラーを修正 [＃31636](https://github.com/pingcap/tidb/issues/31636) - innerWorker panicによって発生するインデックス結合の誤った結果を修正しました [＃31494](https://github.com/pingcap/tidb/issues/31494) - 列タイプを`FLOAT`から`DOUBLE`に変更した後の間違ったクエリ結果を修正[＃31372](https://github.com/pingcap/tidb/issues/31372) - - インデックスルックアップ結合使用してクエリを実行するときに発生する`invalid transaction`エラーを修正します [＃30468](https://github.com/pingcap/tidb/issues/30468) + - インデックスルックアップ結合を使用してクエリを実行するときに発生する`invalid transaction`エラーを修正します [＃30468](https://github.com/pingcap/tidb/issues/30468) - `Order By` の最適化による誤ったクエリ結果を修正 [＃30271](https://github.com/pingcap/tidb/issues/30271) - `MaxDays`と`MaxBackups`の設定がスローログに反映されない問題を修正 [＃25716](https://github.com/pingcap/tidb/issues/25716) - `INSERT ... SELECT ... ON DUPLICATE KEY UPDATE`文を実行するとpanicが発生する問題を修正しました [＃28078](https://github.com/pingcap/tidb/issues/28078) diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index c306e68c0abbb..8b81c044bbabd 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -97,7 +97,7 @@ TiDB バージョン: 5.3.2 - `commit state jump backward`エラーによる繰り返しのクラッシュを修正 [＃2576](https://github.com/pingcap/tiflash/issues/2576) - 多数のINSERTおよびDELETE操作後に発生する可能性のあるデータの不整合を修正[＃4956](https://github.com/pingcap/tiflash/issues/4956) - ローカルトンネルが有効な場合、キャンセルされた MPP クエリによってタスクが永久にハングする可能性があるバグを修正しました[＃4229](https://github.com/pingcap/tiflash/issues/4229) - - TiFlash がリモート読み取り使用するときに、 TiFlash のバージョンが一致しないという誤ったレポートを修正しました。 [＃3713](https://github.com/pingcap/tiflash/issues/3713) + - TiFlash がリモート読み取りを使用するときに、 TiFlash のバージョンが一致しないという誤ったレポートを修正しました。 [＃3713](https://github.com/pingcap/tiflash/issues/3713) - ランダムな gRPC キープアライブタイムアウトにより MPP クエリが失敗する可能性があるバグを修正[＃4662](https://github.com/pingcap/tiflash/issues/4662) - 交換レシーバーで再試行がある場合にMPPクエリが永久にハングする可能性があるバグを修正しました [＃3444](https://github.com/pingcap/tiflash/issues/3444) - `DATETIME`を`DECIMAL` にキャストするときに発生する誤った結果を修正 [＃4151](https://github.com/pingcap/tiflash/issues/4151) diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 2633d7407ba9b..0899ff1dc454b 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -27,7 +27,7 @@ TiDB バージョン: 5.4.0 > **注記：** > -> 以前の TiDB バージョンから v5.4.0 にアップグレードする場合、中間バージョンの互換性変更点を確認したい場合は、該当バージョンの[リリースノート](/releases/_index.md)参照してください。 +> 以前の TiDB バージョンから v5.4.0 にアップグレードする場合、中間バージョンの互換性変更点を確認したい場合は、該当バージョンの[リリースノート](/releases/_index.md)を参照してください。 ### システム変数 {#system-variables} @@ -85,7 +85,7 @@ TiDB バージョン: 5.4.0 中国語ユーザーをより適切にサポートするため、TiDB はバージョン 5.4.0 以降、GBK 文字セットをサポートしています。TiDB クラスタを初めて初期化する際に、TiDB 設定ファイルで[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)オプションを有効にすると、TiDB GBK 文字セットは`gbk_bin`と`gbk_chinese_ci`の照合順序をサポートします。 - GBK 文字セットを使用する場合は、互換性の制限に注意する必要があります。詳細については、[文字セットと照合 - GBK](/character-set-gbk.md)参照してください。 + GBK 文字セットを使用する場合は、互換性の制限に注意する必要があります。詳細については、[文字セットと照合 - GBK](/character-set-gbk.md)を参照してください。 ### セキュリティ {#security} diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index 03a3e108eba61..3ba4523bf8c70 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -61,7 +61,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - `tidb_restricted_read_only`有効になっているときに`tidb_super_read_only`自動的に有効にならないバグを修正[＃31745](https://github.com/pingcap/tidb/issues/31745) - 照合順序`greatest`または`least`関数が間違った結果を返す問題を修正しました[＃31789](https://github.com/pingcap/tidb/issues/31789) - データがエスケープ文字で壊れている場合のロードデータpanicを修正 [＃31589](https://github.com/pingcap/tidb/issues/31589) - - インデックスルックアップ結合使用してクエリを実行するときに発生する`invalid transaction`エラーを修正します [＃30468](https://github.com/pingcap/tidb/issues/30468) + - インデックスルックアップ結合を使用してクエリを実行するときに発生する`invalid transaction`エラーを修正します [＃30468](https://github.com/pingcap/tidb/issues/30468) - `left join` を使用して複数のテーブルのデータを削除した場合の誤った結果を修正 [＃31321](https://github.com/pingcap/tidb/issues/31321) - TiDBが重複したタスクをTiFlash にディスパッチする可能性があるバグを修正しました [＃32814](https://github.com/pingcap/tidb/issues/32814) - v4.0 からアップグレードされたクラスターで`all`権限の付与が失敗する可能性がある問題を修正しました [＃33588](https://github.com/pingcap/tidb/issues/33588) diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 96fb5d3aecd93..0792f49359080 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -83,7 +83,7 @@ TiDB バージョン: 5.4.3 - TiDB Data Migration (DM) - - DB Conn [＃3733](https://github.com/pingcap/tiflow/issues/3733)取得する際に DM ワーカーがスタックする可能性がある問題を修正しました + - DB Conn [＃3733](https://github.com/pingcap/tiflow/issues/3733)を取得する際に DM ワーカーがスタックする可能性がある問題を修正しました - DMが`Specified key was too long`エラーを報告する問題を修正しました[＃5315](https://github.com/pingcap/tiflow/issues/5315) - レプリケーション[＃7028](https://github.com/pingcap/tiflow/issues/7028)中にlatin1データが破損する可能性がある問題を修正 - TiDBがIPv6ホスト[＃6249](https://github.com/pingcap/tiflow/issues/6249)を使用しているときにDMが起動に失敗する問題を修正 diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 59576437ae7d7..a3a61f857c208 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -11,7 +11,7 @@ TiDB バージョン: 6.0.0-DMR > **注記：** > -> TiDB 6.0.0-DMR のドキュメントは[アーカイブ済み](https://docs-archive.pingcap.com/tidb/v6.0/)です。PingCAP では、TiDB データベースの[最新のLTSバージョン](https://docs.pingcap.com/tidb/stable)使用することを推奨しています。 +> TiDB 6.0.0-DMR のドキュメントは[アーカイブ済み](https://docs-archive.pingcap.com/tidb/v6.0/)です。PingCAP では、TiDB データベースの[最新のLTSバージョン](https://docs.pingcap.com/tidb/stable)を使用することを推奨しています。 6.0.0-DMR の主な新機能または改善点は次のとおりです。 @@ -64,7 +64,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - カーネルレベルでデータインデックスの一貫性チェックを追加する - トランザクション実行時にデータインデックスの整合性チェックを追加します。これにより、リソースオーバーヘッドを非常に低く抑えながら、システムの安定性と堅牢性が向上します。チェックの動作は、変数`tidb_enable_mutation_checker`と`tidb_txn_assertion_level`を使用して制御できます。デフォルト設定では、ほとんどのシナリオでQPSの低下は2%以内に抑えられます。整合性チェックのエラーの説明については、 [ユーザードキュメント](/troubleshoot-data-inconsistency-errors.md)参照してください。 + トランザクション実行時にデータインデックスの整合性チェックを追加します。これにより、リソースオーバーヘッドを非常に低く抑えながら、システムの安定性と堅牢性が向上します。チェックの動作は、変数`tidb_enable_mutation_checker`と`tidb_txn_assertion_level`を使用して制御できます。デフォルト設定では、ほとんどのシナリオでQPSの低下は2%以内に抑えられます。整合性チェックのエラーの説明については、 [ユーザードキュメント](/troubleshoot-data-inconsistency-errors.md)を参照してください。 ### 可観測性 {#observability} diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 6be04e891e954..c553991c43a14 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -111,7 +111,7 @@ TiDB バージョン: 6.1.0 - 非トランザクションDMLステートメントをサポートする - 大規模データ処理のシナリオでは、大規模なトランザクションを伴う単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。TiDB v6.1.0以降、 `DELETE` SQL文を複数のSQL文に分割してバッチ処理する構文がサポートされています。分割文はトランザクションの原子性と独立性を損なう可能性がありますが、クラスタの安定性を大幅に向上させます。詳細な構文については、 [`BATCH`](/sql-statements/sql-statement-batch.md)参照してください。 + 大規模データ処理のシナリオでは、大規模なトランザクションを伴う単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。TiDB v6.1.0以降、 `DELETE` SQL文を複数のSQL文に分割してバッチ処理する構文がサポートされています。分割文はトランザクションの原子性と独立性を損なう可能性がありますが、クラスタの安定性を大幅に向上させます。詳細な構文については、 [`BATCH`](/sql-statements/sql-statement-batch.md)を参照してください。 [User document](/non-transactional-dml.md) @@ -280,7 +280,7 @@ TiDB バージョン: 6.1.0 | TiKV | [`storage.api-version`](/tikv-configuration-file.md#api-version-new-in-v610) | 新しく追加された | TiKV が生のキー値ストアとして機能するときに TiKV によって使用されるストレージ形式とインターフェース バージョン。 | | PD | [`schedule.max-store-preparing-time`](/pd-configuration-file.md#max-store-preparing-time-new-in-v610) | 新しく追加された | ストアがオンラインになるまでの最大待機時間を制御します。 | | TiCDC | [`enable-tls`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka) | 新しく追加された | ダウンストリーム Kafka インスタンスに接続するために TLS を使用するかどうか。 | -| TiCDC | `sasl-gssapi-user`
`sasl-gssapi-password`
`sasl-gssapi-auth-type`
`sasl-gssapi-service-name`
`sasl-gssapi-realm`
`sasl-gssapi-key-tab-path`
`sasl-gssapi-kerberos-config-path` | 新しく追加された | Kafka の SASL/GSSAPI 認証をサポートするために使用されます。詳細については[`kafka`でシンクURIを設定する](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)参照してください。 | +| TiCDC | `sasl-gssapi-user`
`sasl-gssapi-password`
`sasl-gssapi-auth-type`
`sasl-gssapi-service-name`
`sasl-gssapi-realm`
`sasl-gssapi-key-tab-path`
`sasl-gssapi-kerberos-config-path` | 新しく追加された | Kafka の SASL/GSSAPI 認証をサポートするために使用されます。詳細については[`kafka`でシンクURIを設定する](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)を参照してください。 | | 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 パーティションに送信する方法を制御します。 | @@ -295,7 +295,7 @@ TiDB バージョン: 6.1.0 - プリペアドプランキャッシュをデフォルトで有効にする - 新しいクラスターでは、 プリペアドプランキャッシュがデフォルトで有効化され、リクエストの`Prepare` `Execute`実行プランをキャッシュします。以降の実行では、クエリプランの最適化をスキップできるため、パフォーマンスが向上します。アップグレードされたクラスターは、設定ファイルから設定を継承します。新しいクラスターは新しいデフォルト値を使用するため、 プリペアドプランキャッシュ はデフォルトで有効化され、各セッションで最大100プランをキャッシュできます ( `capacity=100` )。この機能のメモリ消費量については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)参照してください。 + 新しいクラスターでは、 プリペアドプランキャッシュがデフォルトで有効化され、リクエストの`Prepare` `Execute`実行プランをキャッシュします。以降の実行では、クエリプランの最適化をスキップできるため、パフォーマンスが向上します。アップグレードされたクラスターは、設定ファイルから設定を継承します。新しいクラスターは新しいデフォルト値を使用するため、 プリペアドプランキャッシュ はデフォルトで有効化され、各セッションで最大100プランをキャッシュできます ( `capacity=100` )。この機能のメモリ消費量については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)を参照してください。 - TiDB v6.1.0より前のバージョンでは、 `SHOW ANALYZE STATUS`インスタンスレベルのタスクを示し、タスクレコードはTiDBの再起動後に消去されます。TiDB v6.1.0以降では、 `SHOW ANALYZE STATUS`クラスタレベルのタスクを示し、タスクレコードは再起動後も保持されます。`tidb_analyze_version = 2`場合、 `Job_info`列に`analyze option`情報が追加されます。 diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index dbbac0b13534e..332d7f56629d1 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -24,7 +24,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v ## Other changes {#other-changes} -- `TiDB-community-toolkit`バイナリパッケージに以下の内容を追加します。詳細は[TiDB Installation Packages](/binary-package.md)参照してください。 +- `TiDB-community-toolkit`バイナリパッケージに以下の内容を追加します。詳細は[TiDB Installation Packages](/binary-package.md)を参照してください。 - `server-{version}-linux-amd64.tar.gz` - `grafana-{version}-linux-amd64.tar.gz` @@ -33,7 +33,7 @@ Quick access: [クイックスタート](https://docs-archive.pingcap.com/tidb/v - `blackbox_exporter-{version}-linux-amd64.tar.gz` - `node_exporter-{version}-linux-amd64.tar.gz` -- オペレーティングシステムとCPUアーキテクチャの組み合わせに応じて、異なる品質基準に対する多層的なサポートを導入します。1 [OSおよびプラットフォームの要件](https://docs-archive.pingcap.com/tidb/v6.1/hardware-and-software-requirements#os-and-platform-requirements)参照してください。 +- オペレーティングシステムとCPUアーキテクチャの組み合わせに応じて、異なる品質基準に対する多層的なサポートを導入します。1 [OSおよびプラットフォームの要件](https://docs-archive.pingcap.com/tidb/v6.1/hardware-and-software-requirements#os-and-platform-requirements)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.1.5.md b/releases/release-6.1.5.md index fa82689201035..de472ca7d2823 100644 --- a/releases/release-6.1.5.md +++ b/releases/release-6.1.5.md @@ -13,7 +13,7 @@ TiDB バージョン: 6.1.5 ## 互換性の変更 {#compatibility-changes} -- 2023年2月20日以降、TiDBおよびTiDB Dashboardの新しいバージョン（v6.1.5を含む）では、 [テレメトリ機能](/telemetry.md)デフォルトで無効化され、使用状況情報は収集されず、PingCAPと共有されません。これらのバージョンにアップグレードする前に、クラスターがデフォルトのテレメトリ設定を使用している場合、アップグレード後にテレメトリ機能が無効化されます。具体的なバージョンについては、 [TiDB リリース タイムライン](/releases/release-timeline.md)参照してください。 +- 2023年2月20日以降、TiDBおよびTiDB Dashboardの新しいバージョン（v6.1.5を含む）では、 [テレメトリ機能](/telemetry.md)デフォルトで無効化され、使用状況情報は収集されず、PingCAPと共有されません。これらのバージョンにアップグレードする前に、クラスターがデフォルトのテレメトリ設定を使用している場合、アップグレード後にテレメトリ機能が無効化されます。具体的なバージョンについては、 [TiDB リリース タイムライン](/releases/release-timeline.md)を参照してください。 - [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-new-in-v402)システム変数のデフォルト値が`ON`から`OFF`に変更されます。 - TiDB [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-new-in-v402)構成項目のデフォルト値が`true`から`false`に変更されます。 diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index d52d9d8844ba0..0aa66172f86cd 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -52,7 +52,7 @@ TiDBバージョン: 6.2.0-DMR - TiDB Dashboardにモニタリングページが追加されました - 新しいモニタリング ページには、パフォーマンス チューニングに必要な主要な指標が表示され、これに基づいて[データベース時間によるパフォーマンスチューニング](/performance-tuning-methods.md)参照してパフォーマンスを分析および調整できます。 + 新しいモニタリング ページには、パフォーマンス チューニングに必要な主要な指標が表示され、これに基づいて[データベース時間によるパフォーマンスチューニング](/performance-tuning-methods.md)を参照してパフォーマンスを分析および調整できます。 具体的には、ユーザー応答時間とデータベース時間を全体的かつトップダウンの視点から分析することで、ユーザー応答時間のボトルネックがデータベースの問題によるものかどうかを確認できます。ボトルネックがデータベースにある場合は、データベース時間の概要とSQLレイテンシーの内訳を使用してボトルネックを特定し、パフォーマンスを調整できます。 @@ -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 が失敗する可能性があります。アップTiFlashデータベースが TiDB Lightning の物理インポート モードを使用してデータをインポートする場合、ログ バックアップでデータをバックアップできません。データ インポート後にフル バックアップを実行することをお勧めします。PITR のその他の互換性の問題については、 [PITRの制限](/br/backup-and-restore-overview.md#before-you-use)参照してください。 +- バックアップ クラスタにTiFlashレプリカがある場合、PITR を実行すると、リストア クラスタにはTiFlashレプリカ内のデータが含まれません。TiFlash レプリカからデータをリストアするには、 TiFlashレプリカを手動で構成する必要があります。 `exchange partition` DDL ステートメントを実行すると、PITR が失敗する可能性があります。アップTiFlashデータベースが 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より前のバージョンであってはなりません。 diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 16b5e1477cc4e..7392b97a39413 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -95,7 +95,7 @@ TiDBバージョン: 6.4.0-DMR - TiDBチャンク再利用メカニズムの強化 [#38606](https://github.com/pingcap/tidb/issues/38606) @[keeplearning20221](https://github.com/keeplearning20221) - 以前のバージョンでは、TiDB は`writechunk`関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁に要求する必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数[`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。 + 以前のバージョンでは、TiDB は`writechunk`関数内でのみチャンクを再利用していました。TiDB v6.4.0 では、チャンク再利用メカニズムが Executor の演算子に拡張されました。チャンクを再利用することで、TiDB はメモリ解放を頻繁に要求する必要がなくなり、一部のシナリオでは SQL クエリの実行効率が向上します。システム変数[`tidb_enable_reuse_chunk`](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を使用して、チャンク オブジェクトを再利用するかどうかを制御できます。この機能はデフォルトで有効になっています。 詳細については、 [ユーザー向けドキュメント](/system-variables.md#tidb_enable_reuse_chunk-new-in-v640)を参照してください。 diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 94f83a2fde705..b2d1515fab34b 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -48,13 +48,13 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では 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`に設定します。 - 詳細については[ドキュメント](/metadata-lock.md)参照してください。 + 詳細については[ドキュメント](/metadata-lock.md)を参照してください。 - `FLASHBACK CLUSTER TO TIMESTAMP` (GA) を使用して、クラスターを特定の時点に復元する機能をサポートします。 [＃37197](https://github.com/pingcap/tidb/issues/37197) [＃13303](https://github.com/tikv/tikv/issues/13303) @ [Defined2014](https://github.com/Defined2014) @ [bb7133](https://github.com/bb7133) @ [JmPotato](https://github.com/JmPotato) @ [Connor1996](https://github.com/Connor1996) @ [HuSharp](https://github.com/HuSharp) @ [CalvinNeo](https://github.com/CalvinNeo) TiDB v6.4.0以降、 [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)ステートメントが実験的機能として導入されました。このステートメントを使用すると、ガベージコレクション（GC）の有効期間内の特定の時点にクラスターを復元できます。v6.5.0では、この機能はTiCDCおよびPITRと互換性があり、GAとなります。この機能により、DMLの誤操作を簡単に元に戻したり、数分で元のクラスターを復元したり、異なる時点のデータをロールバックしてデータが変更された正確な時刻を特定したりすることが可能になります。 - 詳細については[ドキュメント](/sql-statements/sql-statement-flashback-cluster.md)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-flashback-cluster.md)を参照してください。 - `INSERT` `UPDATE`含む非トランザクションDMLステートメント`DELETE` にサポートし@ [ekexium](https://github.com/ekexium) `REPLACE` [＃33485](https://github.com/pingcap/tidb/issues/33485) @@ -66,7 +66,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TTLは行レベルのデータ有効期間管理を提供します。TiDBでは、TTL属性を持つテーブルはデータ有効期間を自動的にチェックし、期限切れのデータを行レベルで削除します。TTLは、オンラインの読み取りおよび書き込みワークロードに影響を与えることなく、不要なデータを定期的かつタイムリーにクリーンアップできるように設計されています。 - 詳細については[ドキュメント](/time-to-live.md)参照してください。 + 詳細については[ドキュメント](/time-to-live.md)を参照してください。 - `INSERT INTO SELECT`ステートメントを使用したTiFlashクエリ結果の保存をサポート (実験的) [＃37515](https://github.com/pingcap/tidb/issues/37515) @ [gengliqi](https://github.com/gengliqi) @@ -82,7 +82,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - TiFlashクエリ結果を再利用するか、同時実行性の高いオンライン リクエストを処理する - 入力データのサイズと比較して比較的小さい結果セットが必要です。100 MiB 未満が望ましいです。 - 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)を参照してください。 - バインディング履歴実行プランのサポート（実験的） [＃39199](https://github.com/pingcap/tidb/issues/39199) @ [fzzf678](https://github.com/fzzf678) @@ -90,7 +90,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDB v6.5.0では、 [`CREATE [GLOBAL | SESSION] BINDING`](/sql-statements/sql-statement-create-binding.md)ステートメントのバインディングオブジェクトを拡張することで、履歴実行プランのバインディングをサポートします。SQLステートメントの実行プランが変更された場合、元の実行プランがSQL実行履歴メモリテーブル（例えば`statements_summary`に残っている限り、 `CREATE [GLOBAL | SESSION] BINDING`ステートメントで`plan_digest`指定することで元の実行プランをバインドし、SQLパフォーマンスを迅速に回復できます。この機能により、実行プラン変更の問題への対応プロセスが簡素化され、メンテナンス効率が向上します。 - 詳細については[ドキュメント](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)参照してください。 + 詳細については[ドキュメント](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan)を参照してください。 ### セキュリティ {#security} @@ -100,25 +100,25 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDB は、パスワードの強度を検証するための SQL 関数[`VALIDATE_PASSWORD_STRENGTH()`](https://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html#function_validate-password-strength)を提供します。 - 詳細については[ドキュメント](/password-management.md#password-complexity-policy)参照してください。 + 詳細については[ドキュメント](/password-management.md#password-complexity-policy)を参照してください。 - パスワード有効期限ポリシーをサポート [＃38936](https://github.com/pingcap/tidb/issues/38936) @ [CbcWestwolf](https://github.com/CbcWestwolf) TiDBは、パスワードの有効期限ポリシー（手動による有効期限、グローバルレベルの自動有効期限、アカウントレベルの自動有効期限など）の設定をサポートしています。このポリシーを有効にすると、パスワードを定期的に変更する必要があります。これにより、長期使用によるパスワード漏洩のリスクが軽減され、パスワードのセキュリティが向上します。 - 詳細については[ドキュメント](/password-management.md#password-expiration-policy)参照してください。 + 詳細については[ドキュメント](/password-management.md#password-expiration-policy)を参照してください。 - パスワード再利用ポリシーをサポートする [＃38937](https://github.com/pingcap/tidb/issues/38937) @ [keeplearning20221](https://github.com/keeplearning20221) TiDBは、グローバルレベルのパスワード再利用ポリシーとアカウントレベルのパスワード再利用ポリシーを含む、パスワード再利用ポリシーの設定をサポートしています。このポリシーを有効にすると、指定期間内に使用したパスワード、または直近の数個のパスワードは使用できなくなります。これにより、パスワードの繰り返し使用によるパスワード漏洩のリスクが軽減され、パスワードのセキュリティが向上します。 - 詳細については[ドキュメント](/password-management.md#password-reuse-policy)参照してください。 + 詳細については[ドキュメント](/password-management.md#password-reuse-policy)を参照してください。 - ログイン失敗の追跡と一時的なアカウントロックポリシーをサポート [＃38938](https://github.com/pingcap/tidb/issues/38938) @ [lastincisor](https://github.com/lastincisor) このポリシーを有効にすると、TiDBに連続して間違ったパスワードでログインした場合、アカウントは一時的にロックされます。ロック時間が終了すると、アカウントは自動的にロック解除されます。 - 詳細については[ドキュメント](/password-management.md#failed-login-tracking-and-temporary-account-locking-policy)参照してください。 + 詳細については[ドキュメント](/password-management.md#failed-login-tracking-and-temporary-account-locking-policy)を参照してください。 ### 可観測性 {#observability} @@ -132,7 +132,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - PD ノードが利用できない場合でも、ユーザーは診断のために TiDB Dashboardにアクセスできます。 - インターネット経由でTiDB Dashboardにアクセスする場合、PDの特権インターフェースは使用されません。そのため、クラスターのセキュリティリスクは軽減されます。 - 詳細については[ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/v1.5/get-started#deploy-tidb-dashboard-independently)参照してください。 + 詳細については[ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/v1.5/get-started#deploy-tidb-dashboard-independently)を参照してください。 - パフォーマンス概要ダッシュボードにTiFlashと CDC (変更データキャプチャ) パネルが追加されました [＃39230](https://github.com/pingcap/tidb/issues/39230) @ [dbsid](https://github.com/dbsid) @@ -143,7 +143,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - [TiFlashパネル](/grafana-performance-overview-dashboard.md#tiflash)では、 TiFlashクラスターのリクエスト タイプ、レイテンシー分析、リソース使用状況の概要を簡単に表示できます。 - [CDCパネル](/grafana-performance-overview-dashboard.md#cdc)では、TiCDC クラスターの健全性、レプリケーションのレイテンシー、データ フロー、ダウンストリームの書き込みレイテンシーを簡単に確認できます。 - 詳細については[ドキュメント](/performance-tuning-methods.md)参照してください。 + 詳細については[ドキュメント](/performance-tuning-methods.md)を参照してください。 ### パフォーマンス {#performance} @@ -151,7 +151,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では v6.5.0より前のTiDBでは、 `OR`で連結されたフィルタ条件に対してのみインデックスマージがサポートされていました。v6.5.0以降、TiDBは`WHERE`句の`AND`で連結されたフィルタ条件に対してもインデックスマージがサポートされるようになりました。これにより、TiDBのインデックスマージは、より一般的なクエリフィルタ条件の組み合わせをカバーできるようになり、union( `OR` )関係に限定されなくなりました。現在のv6.5.0バージョンでは、オプティマイザによって自動的に選択された`OR`の条件でのインデックスマージのみがサポートされています。11 `AND`条件でインデックスマージを有効にするには、 [`USE_INDEX_MERGE`](/optimizer-hints.md#use_index_merget1_name-idx1_name--idx2_name-)ヒントを使用する必要があります。 - インデックスマージの詳細については、 [v5.4.0 リリースノート](/releases/release-5.4.0.md#performance)と[インデックスのマージについて説明する](/explain-index-merge.md)参照してください。 + インデックスマージの詳細については、 [v5.4.0 リリースノート](/releases/release-5.4.0.md#performance)と[インデックスのマージについて説明する](/explain-index-merge.md)を参照してください。 - 以下のJSON関数をTiFlash にプッシュダウンすることをサポートします [＃39458](https://github.com/pingcap/tidb/issues/39458) @ [yibin87](https://github.com/yibin87) @@ -171,7 +171,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では ビューアクセスのシナリオによっては、最適なパフォーマンスを実現するために、ビュー内のクエリの実行プランにオプティマイザヒントを使用して介入する必要があります。TiDB v6.5.0以降、ビュー内のクエリブロックへのグローバルヒントの追加がサポートされ、クエリで定義されたヒントがビュー内で有効になります。この機能により、ネストされたビューを含む複雑なSQL文にヒントを挿入できるようになり、実行プランの制御が強化され、複雑な文のパフォーマンスが安定します。グローバルヒントを使用するには、 [クエリブロックに名前を付ける](/optimizer-hints.md#step-1-define-the-query-block-name-of-the-view-using-the-qb_name-hint)と[ヒント参照を指定する](/optimizer-hints.md#step-2-add-the-target-hints)必要です。 - 詳細については[ドキュメント](/optimizer-hints.md#hints-that-take-effect-globally)参照してください。 + 詳細については[ドキュメント](/optimizer-hints.md#hints-that-take-effect-globally)を参照してください。 - [パーティションテーブル](/partitioned-table.md)から TiKV へのソート操作のプッシュダウンをサポート [＃26166](https://github.com/pingcap/tidb/issues/26166) @ [winoros](https://github.com/winoros) @@ -183,7 +183,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では コスト モデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 - 詳細については[ドキュメント](/cost-model.md#cost-model-version-2)参照してください。 + 詳細については[ドキュメント](/cost-model.md#cost-model-version-2)を参照してください。 - TiFlashはテーブル行数を取得する操作を最適化します [＃37165](https://github.com/pingcap/tidb/issues/37165) @ [elsa0520](https://github.com/elsa0520) @@ -199,7 +199,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDB v6.5.0以降をご利用の場合は、 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)削除し、トランザクションのメモリ使用量に別途制限を設けないことを推奨します。代わりに、システム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)と[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)を使用してグローバルメモリを管理することで、メモリ使用効率を向上させることができます。 - 詳細については[ドキュメント](/configure-memory-usage.md)参照してください。 + 詳細については[ドキュメント](/configure-memory-usage.md)を参照してください。 ### 使いやすさ {#ease-of-use} @@ -207,13 +207,13 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では `EXPLAIN ANALYZE`ステートメントは、実行計画と実行時統計を出力するために使用されます。v6.5.0 では、 TiFlash は`TableFullScan`演算子の実行情報を改良し、DMFile 関連の実行情報を追加しました。これにより、 TiFlash のデータスキャンステータス情報がより直感的に表示されるようになり、 TiFlash のパフォーマンス分析が容易になります。 - 詳細については[ドキュメント](/sql-statements/sql-statement-explain-analyze.md)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-explain-analyze.md)を参照してください。 - JSON形式での実行プランの出力をサポート[＃39261](https://github.com/pingcap/tidb/issues/39261) @ [fzzf678](https://github.com/fzzf678) TiDB v6.5.0では、実行プランの出力形式が拡張されました。3 `EXPLAIN`に`FORMAT = "tidb_json"`指定することで、SQL実行プランをJSON形式で出力できます。この機能により、SQLデバッグツールや診断ツールは実行プランをより便利かつ正確に読み取ることができるため、SQL診断やチューニングの利便性が向上します。 - 詳細については[ドキュメント](/sql-statements/sql-statement-explain.md)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-explain.md)を参照してください。 ### MySQLの互換性 {#mysql-compatibility} @@ -225,7 +225,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1; ``` - 詳細については[ドキュメント](/auto-increment.md#mysql-compatibility-mode)参照してください。 + 詳細については[ドキュメント](/auto-increment.md#mysql-compatibility-mode)を参照してください。 ### データ移行 {#data-migration} @@ -235,7 +235,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では これまで、CSVファイルやSQLファイルの保存には、データのエクスポートやインポートに大量のストレージ容量が必要であり、ストレージコストが高くなっていました。この機能のリリースにより、データファイルを圧縮することで、ストレージコストを大幅に削減できます。 - 詳細については[ドキュメント](/dumpling-overview.md#improve-export-efficiency-through-concurrency)参照してください。 + 詳細については[ドキュメント](/dumpling-overview.md#improve-export-efficiency-through-concurrency)を参照してください。 - binlog解析機能をで最適化 [＃924](https://github.com/pingcap/dm/issues/924) @ [GMHDBJD](https://github.com/GMHDBJD) @@ -249,7 +249,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では 以前は、 TiDB Lightning が物理モードでデータをインポートすると、生データのエンコード、ソート、分割のためにローカルディスク上に多数の一時ファイルが作成されていました。ローカルディスクの空き容量が不足すると、 TiDB Lightning はファイルへの書き込みに失敗したためにエラーで終了していました。この機能により、 TiDB Lightningタスクはローカルディスクの上書きを回避できます。 - 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#configure-disk-quota-new-in-v620)参照してください。 + 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#configure-disk-quota-new-in-v620)を参照してください。 - DMにおける継続的なデータ検証はGA です [＃4426](https://github.com/pingcap/tiflow/issues/4426) @ [D3Hunter](https://github.com/D3Hunter) @@ -257,7 +257,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では 以前は、データ全体を検証するために業務を中断する必要があり、業務に影響が出ていました。この機能により、業務を中断することなく増分データ検証を実行できるようになりました。 - 詳細については[ドキュメント](/dm/dm-continuous-data-validation.md)参照してください。 + 詳細については[ドキュメント](/dm/dm-continuous-data-validation.md)を参照してください。 ### TiDBデータ共有サブスクリプション {#tidb-data-share-subscription} @@ -271,7 +271,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiCDCは、2つのTiDBクラスタ間の双方向レプリケーションをサポートしています。アプリケーションのために地理的に分散された複数のアクティブデータセンターを構築する必要がある場合、この機能をソリューションとして利用できます。TiCDCの変更フィードに`bdr-mode = true`パラメータを設定することで、あるTiDBクラスタから別のTiDBクラスタへのデータレプリケーションを実現できます。 - 詳細については[ドキュメント](/ticdc/ticdc-bidirectional-replication.md)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-bidirectional-replication.md)を参照してください。 - TiCDCはTLSオンラインの更新をサポート [＃7908](https://github.com/pingcap/tiflow/issues/7908) @ [CharlesCheung96](https://github.com/CharlesCheung96) @@ -289,7 +289,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiDBスナップショットバックアップは、チェックポイントからのバックアップ再開をサポートしています。バックアップ＆リストア（BR）は、回復可能なエラーが発生するとバックアップを再試行します。ただし、再試行が複数回失敗するとBRは終了します。チェックポイントバックアップ機能により、数十分のネットワーク障害など、回復可能なより長い障害の再試行が可能になります。 - BR終了後1時間以内にシステムを障害から復旧しない場合、バックアップ対象のスナップショットデータがGCメカニズムによって再利用され、バックアップが失敗する可能性があることに注意してください。詳細については、 [ドキュメント](/br/br-checkpoint-backup.md#backup-retry-must-be-prior-to-gc)参照してください。 + BR終了後1時間以内にシステムを障害から復旧しない場合、バックアップ対象のスナップショットデータがGCメカニズムによって再利用され、バックアップが失敗する可能性があることに注意してください。詳細については、 [ドキュメント](/br/br-checkpoint-backup.md#backup-retry-must-be-prior-to-gc)を参照してください。 - PITRのパフォーマンスは@ [joccau](https://github.com/joccau)で著しく向上しました @@ -299,7 +299,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では TiKV- BRは、TiKVクラスターで使用されるバックアップおよびリストアツールです。TiKVとPDは、TiDBを使用せずにRawKVと呼ばれるKVデータベースを構成できます。TiKV- BRは、RawKVを使用する製品のデータバックアップとリストアをサポートします。また、 TiKVクラスターの[`api-version`](/tikv-configuration-file.md#api-version-new-in-v610) `API V1`から`API V2`にアップグレードすることもできます。 - 詳細については[ドキュメント](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)参照してください。 + 詳細については[ドキュメント](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)を参照してください。 ## 互換性の変更 {#compatibility-changes} @@ -367,7 +367,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では ### その他 {#others} - v6.5.0 以降、 `mysql.user`テーブルに`Password_reuse_history`と`Password_reuse_time` 2 つの新しい列が追加されます。 -- バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全に互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)参照してください。 +- バージョン6.5.0以降、 [インデックス加速](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)機能がデフォルトで有効になっています。この機能は[1つの`ALTER TABLE`文で複数の列またはインデックスを変更する](/sql-statements/sql-statement-alter-table.md)と完全に互換性がありません。インデックスアクセラレーションを使用して一意インデックスを追加する場合、同じステートメント内で他の列やインデックスを変更しないようにする必要があります。この機能は[PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)とも互換性がありません。インデックスアクセラレーション機能を使用する場合は、バックグラウンドでPITRバックアップタスクが実行されていないことを確認する必要があります。そうしないと、予期しない結果が発生する可能性があります。詳細については、 [ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)を参照してください。 ## 非推奨の機能 {#deprecated-feature} diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index 246f8357b2330..6d1707affb1d7 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -13,7 +13,7 @@ TiDB バージョン: 6.5.1 ## 互換性の変更 {#compatibility-changes} -- 2023年2月20日以降、TiDBおよびTiDB Dashboardの新しいバージョン（v6.5.1を含む）では、 [テレメトリ機能](/telemetry.md)デフォルトで無効化され、使用状況情報は収集されず、PingCAPと共有されません。これらのバージョンにアップグレードする前に、クラスターがデフォルトのテレメトリ設定を使用している場合、アップグレード後にテレメトリ機能が無効化されます。具体的なバージョンについては、 [TiDB リリース タイムライン](/releases/release-timeline.md)参照してください。 +- 2023年2月20日以降、TiDBおよびTiDB Dashboardの新しいバージョン（v6.5.1を含む）では、 [テレメトリ機能](/telemetry.md)デフォルトで無効化され、使用状況情報は収集されず、PingCAPと共有されません。これらのバージョンにアップグレードする前に、クラスターがデフォルトのテレメトリ設定を使用している場合、アップグレード後にテレメトリ機能が無効化されます。具体的なバージョンについては、 [TiDB リリース タイムライン](/releases/release-timeline.md)を参照してください。 - [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-new-in-v402)システム変数のデフォルト値が`ON`から`OFF`に変更されます。 - TiDB [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-new-in-v402)構成項目のデフォルト値が`true`から`false`に変更されます。 @@ -36,11 +36,11 @@ TiDB バージョン: 6.5.1 - IPv6 アドレスの完全サポート: TiDB は、クライアント接続、ノード間の内部通信、外部システムとの通信など、すべてのネットワーク接続で IPv6 アドレスの使用をサポートします。 - デュアルスタックのサポート：まだIPv6への完全移行の準備が整っていない場合でも、TiDBはデュアルスタックネットワークをサポートしています。つまり、同じTiDBクラスタ内でIPv4とIPv6の両方のアドレスを使用し、設定によってIPv6を優先するネットワーク展開モードを選択できます。 - IPv6 の導入の詳細については、 [Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#ipv6-support)参照してください。 + IPv6 の導入の詳細については、 [Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#ipv6-support)を参照してください。 - TiDB クラスタの初期化時に実行される SQL スクリプトの指定をサポート[＃35624](https://github.com/pingcap/tidb/issues/35624) @ [morgo](https://github.com/morgo) - TiDB v6.5.1 では、新しい設定項目[`initialize-sql-file`](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)が追加されました。TiDB クラスタを初めて起動する際に、コマンドラインパラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を行う際に使用できます。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)参照してください。 + TiDB v6.5.1 では、新しい設定項目[`initialize-sql-file`](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)が追加されました。TiDB クラスタを初めて起動する際に、コマンドラインパラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を行う際に使用できます。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)を参照してください。 - メモリリークとパフォーマンスの低下を防ぐため、期限切れのリージョンキャッシュを定期的にクリアします[＃40461](https://github.com/pingcap/tidb/issues/40461) @ [sticnarf](https://github.com/sticnarf) diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index 3ac885d8a8d98..43459595e0c5a 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -13,7 +13,7 @@ TiDBバージョン: 6.5.12 ## 互換性の変更 {#compatibility-changes} -- openEuler 22.03 LTS SP3/SP4 オペレーティングシステムをサポートします。詳細については、 [OSおよびプラットフォームの要件](https://docs.pingcap.com/tidb/v6.5/hardware-and-software-requirements#os-and-platform-requirements)参照してください。 +- openEuler 22.03 LTS SP3/SP4 オペレーティングシステムをサポートします。詳細については、 [OSおよびプラットフォームの要件](https://docs.pingcap.com/tidb/v6.5/hardware-and-software-requirements#os-and-platform-requirements)を参照してください。 - [TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-6.5/docs/tidb_http_api.md)から取得される DDL 履歴タスクのデフォルトの制限を 2048 に設定して、過剰な履歴タスクによる OOM の問題を防止します。 [＃55711](https://github.com/pingcap/tidb/issues/55711) @ [joccau](https://github.com/joccau) - インデックスを追加する際の取り込みフェーズの最大速度を制限する新しいシステム変数[`tidb_ddl_reorg_max_write_speed`](https://docs.pingcap.com/tidb/v6.5/system-variables#tidb_ddl_reorg_max_write_speed-new-in-v6512)を追加します。 [＃57156](https://github.com/pingcap/tidb/issues/57156) @ [CbcWestwolf](https://github.com/CbcWestwolf) diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index ab85e9562dd24..fb32a091fd5af 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -15,7 +15,7 @@ TiDB バージョン: 6.5.3 ### 動作の変更 {#behavior-changes} -- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)参照してください。 +- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index 22712c6fa04cc..bac18ba4bd76c 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -18,7 +18,7 @@ TiDB バージョン: 6.5.4 ### 動作の変更 {#behavior-changes} -- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 +- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 1623cc73b807e..47610c511534f 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -58,7 +58,7 @@ TiDB バージョン: 6.5.6 - TiDB - - HashJoin演算子がプローブ実行するときにチャンクを再利用できない問題を修正しました [＃48082](https://github.com/pingcap/tidb/issues/48082) @ [wshwsh12](https://github.com/wshwsh12) + - HashJoin演算子がプローブを実行するときにチャンクを再利用できない問題を修正しました [＃48082](https://github.com/pingcap/tidb/issues/48082) @ [wshwsh12](https://github.com/wshwsh12) - `AUTO_ID_CACHE=1` に設定されている場合に`Duplicate entry`発生する可能性がある問題を修正しました [＃46444](https://github.com/pingcap/tidb/issues/46444) @ [tiancaiamao](https://github.com/tiancaiamao) - 2つのサブクエリを結合するときに`TIDB_INLJ`ヒントが有効にならない問題を修正しました [＃46160](https://github.com/pingcap/tidb/issues/46160) @ [qw4990](https://github.com/qw4990) - TiDB の再起動後に DDL 操作が停止する可能性がある問題を修正[＃46751](https://github.com/pingcap/tidb/issues/46751) @ [wjhuang2016](https://github.com/wjhuang2016) diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index e093a29c23cca..14f7792682c5d 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -63,7 +63,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone 実行プランキャッシュは同時実行 OLTP の処理能力を向上させるために重要であり、TiDB はすでに[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)をサポートしています。 v7.0.0 では、TiDB は非 Prepare ステートメントの実行プランをキャッシュすることもできるため、実行プラン キャッシュの範囲が拡張され、TiDB の同時処理能力が向上します。 - この機能はデフォルトでは無効になっています。システム変数[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) `ON`に設定することで有効にできます。安定性のため、TiDB v7.0.0 では非プリペアド実行プランをキャッシュするための新しい領域が割り当てられ、システム変数[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)を使用してキャッシュサイズを設定できます。さらに、この機能には SQL ステートメントに関する特定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)参照してください。 + この機能はデフォルトでは無効になっています。システム変数[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) `ON`に設定することで有効にできます。安定性のため、TiDB v7.0.0 では非プリペアド実行プランをキャッシュするための新しい領域が割り当てられ、システム変数[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)を使用してキャッシュサイズを設定できます。さらに、この機能には SQL ステートメントに関する特定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)を参照してください。 詳細については、[ドキュメント](/sql-non-prepared-plan-cache.md)を参照してください。 diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 4dad15890f21d..19a370d7012ca 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -29,7 +29,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 現在、この機能は実験的であり、本番環境での使用は推奨されません。このエンジンは新規に作成されたクラスターでのみ使用でき、元のTiKVストレージエンジンから直接アップグレードすることはできません。 - 詳細については[ドキュメント](/partitioned-raft-kv.md)参照してください。 + 詳細については[ドキュメント](/partitioned-raft-kv.md)を参照してください。 - TiFlashは遅延マテリアライゼーション（GA） をサポートします [＃5829](https://github.com/pingcap/tiflash/issues/5829) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) @@ -37,7 +37,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 バージョン7.1.0以降、 TiFlashの遅延マテリアライゼーション機能が一般提供され、デフォルトで有効化されています（システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)はデフォルトで`ON`に設定されています）。TiDBオプティマイザーは、クエリの統計情報とフィルター条件に基づいて、TableScan演算子にプッシュダウンするフィルターを決定します。 - 詳細については[ドキュメント](/tiflash/tiflash-late-materialization.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-late-materialization.md)を参照してください。 - TiFlashは、ネットワーク伝送のオーバーヘッドに応じてMPP Joinアルゴリズムを自動的に選択することをサポートしています[＃7084](https://github.com/pingcap/tiflash/issues/7084) @ [solotzg](https://github.com/solotzg) @@ -45,13 +45,13 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.1.0 では、TiDB に[`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710)変数が導入されました。この変数は、ネットワーク伝送の最小オーバーヘッドに基づいて MPP Join アルゴリズムを選択するかどうかを制御し、この変数はデフォルトで無効になっています。この変数を`ON`に設定すると、デフォルトのアルゴリズム選択方法が v7.1.0 以前と同じままであることを示します。この変数を有効にすると、 [`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 は、異なる Join アルゴリズムによるネットワーク伝送のしきい値を自動的に推定し、全体的なオーバーヘッドが最小のアルゴリズムを選択します。これにより、ネットワークトラフィックが削減され、MPP クエリのパフォーマンスが向上します。 - 詳細については[ドキュメント](/tiflash/use-tiflash-mpp-mode.md#algorithm-support-for-the-mpp-mode)参照してください。 + 詳細については[ドキュメント](/tiflash/use-tiflash-mpp-mode.md#algorithm-support-for-the-mpp-mode)を参照してください。 - 読み取りホットスポットを軽減するために負荷ベースのレプリカ読み取りをサポートする[＃14151](https://github.com/tikv/tikv/issues/14151) @ [sticnarf](https://github.com/sticnarf) @ [you06](https://github.com/you06) 読み取りホットスポットが発生すると、ホットスポット TiKV ノードは読み取り要求を時間内に処理できず、読み取り要求がキューイングされます。ただし、この時点ですべての TiKV リソースが使い果たされるわけではありません。レイテンシーを短縮するために、TiDB v7.1.0 では負荷ベースのレプリカ読み取り機能が導入されました。この機能により、TiDB はホットスポット TiKV ノードでキューイングすることなく、他の TiKV ノードからデータを読み取ることができます。読み取り要求のキューの長さは、 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700)システム変数を使用して制御できます。リーダーノードの推定キュー時間がこのしきい値を超えると、TiDB はフォロワーノードからのデータの読み取りを優先します。この機能により、読み取りホットスポットが発生すると、読み取りホットスポットを分散させない場合と比較して、読み取りスループットが 70% ～ 200% 向上します。 - 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)参照してください。 + 詳細については[ドキュメント](/troubleshoot-hot-spot-issues.md#scatter-read-hotspots)を参照してください。 - 非プリペアドステートメントの実行プランをキャッシュする機能の強化（実験的） [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) @@ -63,7 +63,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 非プリペアドプランキャッシュは、デフォルトではDML文をサポートしません。この制限を解除するには、システム変数[`tidb_enable_non_prepared_plan_cache_for_dml`](/system-variables.md#tidb_enable_non_prepared_plan_cache_for_dml-new-in-v710)を`ON`に設定してください。 - 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)参照してください。 + 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)を参照してください。 - TiDB 分散実行フレームワーク (DXF) のサポート (実験的) [＃41495](https://github.com/pingcap/tidb/issues/41495) @ [benjamin2037](https://github.com/benjamin2037) @@ -75,7 +75,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 SET GLOBAL tidb_enable_dist_task = ON; ``` - 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)参照してください。 + 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)を参照してください。 ### 信頼性 {#reliability} @@ -89,13 +89,13 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 ユーザーエクスペリエンスを向上させるために、TiDB Dashboardは[リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)を提供します。このページでは、リソースグループの構成を表示し、クラスターの容量を視覚的に見積もることができるため、適切なリソース割り当てが容易になります。 - 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)参照してください。 + 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)を参照してください。 - フォールトトレランスと自動リカバリ機能を向上させるために、高速オンラインDDLのチェックポイントメカニズムをサポートします[＃42164](https://github.com/pingcap/tidb/issues/42164) @ [tangenta](https://github.com/tangenta) TiDB v7.1.0では、 [高速オンラインDDL](/best-practices/ddl-introduction.md)のチェックポイント機構が導入され、Fast Online DDLのフォールトトレランスと自動リカバリ機能が大幅に向上しました。障害によりTiDBオーナーノードが再起動または変更された場合でも、TiDBは定期的に自動更新されるチェックポイントから進捗状況をリカバリできるため、DDL実行の安定性と効率性が向上します。 - 詳細については[ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)を参照してください。 - バックアップと復元はチェックポイント復元をサポートします [＃42339](https://github.com/pingcap/tidb/issues/42339) @ [Leavrth](https://github.com/Leavrth) @@ -103,7 +103,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。 - 詳細については[ドキュメント](/br/br-checkpoint-restore.md)参照してください。 + 詳細については[ドキュメント](/br/br-checkpoint-restore.md)を参照してください。 - 統計のロード戦略を最適化する [＃42160](https://github.com/pingcap/tidb/issues/42160) @ [xuyifangreeneyes](https://github.com/xuyifangreeneyes) @@ -111,19 +111,19 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDBの起動時、初期統計情報が完全にロードされる前に実行されるSQL文は、最適ではない実行プランを持つ可能性があり、パフォーマンスの問題を引き起こす可能性があります。このような問題を回避するために、TiDB v7.1.0では設定パラメータ[`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)が導入されました。このオプションを使用すると、起動時に統計情報の初期化が完了した後にのみTiDBがサービスを提供するかどうかを制御できます。このパラメータはデフォルトで無効になっています。 - 詳細については[ドキュメント](/statistics.md#load-statistics)参照してください。 + 詳細については[ドキュメント](/statistics.md#load-statistics)を参照してください。 - TiCDCは、単一行データのデータ整合性検証機能をサポートしています[＃8718](https://github.com/pingcap/tiflow/issues/8718) [＃42747](https://github.com/pingcap/tidb/issues/42747) @ [3AceShowHand](https://github.com/3AceShowHand) @ [zyguan](https://github.com/zyguan) v7.1.0以降、TiCDCはデータ整合性検証機能を導入しました。この機能は、チェックサムアルゴリズムを用いて単一行データの整合性を検証します。この機能は、TiDBからデータを書き込み、TiCDCを介してレプリケーションし、Kafkaクラスターに書き込むプロセスでエラーが発生していないかどうかを検証するのに役立ちます。データ整合性検証機能は、Kafkaをダウンストリームとして使用するチェンジフィードのみをサポートし、現在はAvroプロトコルをサポートしています。 - 詳細については[ドキュメント](/ticdc/ticdc-integrity-check.md)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-integrity-check.md)を参照してください。 - TiCDCはDDLレプリケーション操作[＃8686](https://github.com/pingcap/tiflow/issues/8686) [ハイ・ラスティン](https://github.com/Rustin170506)で最適化します v7.1.0より前のバージョンでは、大規模なテーブルのすべての行に影響を与えるDDL操作（列の追加や削除など）を実行すると、TiCDCのレプリケーションレイテンシーが大幅に増加していました。v7.1.0以降、TiCDCはこのレプリケーション操作を最適化し、DDL操作が下流のレイテンシーに与える影響を軽減します。 - 詳細については[ドキュメント](/ticdc/ticdc-faq.md#does-ticdc-replicate-data-changes-caused-by-lossy-ddl-operations-to-the-downstream)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-faq.md#does-ticdc-replicate-data-changes-caused-by-lossy-ddl-operations-to-the-downstream)を参照してください。 - TiB レベルのデータをインポートする際のTiDB Lightningの安定性を向上[＃43510](https://github.com/pingcap/tidb/issues/43510) [＃43657](https://github.com/pingcap/tidb/issues/43657) @ [D3Hunter](https://github.com/D3Hunter) @ [lance6716](https://github.com/lance6716) @@ -134,7 +134,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `tikv-importer.region-check-backoff-limit` 、分割および分散処理後にリージョンがオンラインになるまでの再試行回数を制御します。デフォルト値は`1800`で、最大再試行間隔は 2 秒です。再試行の間にいずれかのリージョンがオンラインになった場合、再試行回数は増加しません。 - `tikv-importer.pause-pd-scheduler-scope` TiDB Lightning がPD スケジューリングを一時停止する範囲を制御します。値のオプションは`"table"`と`"global"`です。デフォルト値は`"table"`です。v6.1.0 より前のバージョンの TiDB では、データインポート中にグローバルスケジューリングを一時停止する`"global"`オプションのみを設定できます。v6.1.0 以降では、ターゲットテーブルデータが格納されているリージョンのスケジューリングのみを一時停止する`"table"`オプションがサポートされています。データ量が多いシナリオでは、安定性を向上させるために、この設定項目を`"global"`に設定することをお勧めします。 - 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)参照してください。 + 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 ### SQL {#sql} @@ -144,7 +144,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 この機能はバージョン7.1.0で一般公開されています。3 `INSERT INTO SELECT`の`SELECT`句の実行中、オプティマイザーは、 [SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定できます。そのため、実験的段階で導入された`tidb_enable_tiflash_read_for_write_stmt`システム変数は非推奨となりました。TiFlashの`INSERT INTO SELECT`文の計算規則は`STRICT SQL Mode`要件を満たしていないため、TiDBは、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合にのみ、 `INSERT INTO SELECT`文の`SELECT`句をTiFlashにプッシュダウンすることを許可します。つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれません。 - 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-results-materialization.md)を参照してください。 - MySQL互換の多値インデックスが一般提供（GA）される[＃39592](https://github.com/pingcap/tidb/issues/39592) @ [xiongjiwei](https://github.com/xiongjiwei) @ [qw4990](https://github.com/qw4990) @ [YangKeao](https://github.com/YangKeao) @@ -152,19 +152,19 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 バージョン7.1.0では、多値インデックス機能が一般提供（GA）されました。より包括的なデータ型をサポートし、TiDBツールとの互換性も備えています。多値インデックスを使用することで、本番環境におけるJSON配列の検索操作を高速化できます。 - 詳細については[ドキュメント](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-create-index.md#multi-valued-indexes)を参照してください。 - ハッシュおよびキーパーティションテーブルのパーティション管理を改善[＃42728](https://github.com/pingcap/tidb/issues/42728) @ [mjonss](https://github.com/mjonss) v7.1.0より前では、TiDBのハッシュおよびキーパーティションテーブルは、パーティション管理ステートメント`TRUNCATE PARTITION`をサポートしていました。v7.1.0以降では、ハッシュおよびキーパーティションテーブルは、パーティション管理ステートメント`ADD PARTITION`および`COALESCE PARTITION`もサポートするようになりました。そのため、必要に応じてハッシュおよびキーパーティションテーブルのパーティション数を柔軟に調整できます。例えば、パーティション管理ステートメント`ADD PARTITION`でパーティション数を増やしたり、パーティション管理ステートメント`COALESCE PARTITION`でパーティション数を減らしたりすることができます。 - 詳細については[ドキュメント](/partitioned-table.md#manage-hash-and-key-partitions)参照してください。 + 詳細については[ドキュメント](/partitioned-table.md#manage-hash-and-key-partitions)を参照してください。 - 範囲INTERVALパーティションの構文が一般公開（GA） になります [＃35683](https://github.com/pingcap/tidb/issues/35683) @ [mjonss](https://github.com/mjonss) バージョン6.3.0で導入されたRange INTERVALパーティショニングの構文がGAになりました。この構文を使用すると、すべてのパーティションを列挙することなく、任意の間隔でRangeパーティショニングを定義できるため、RangeパーティショニングのDDL文の長さが大幅に短縮されます。この構文は、従来のRangeパーティショニングの構文と同等です。 - 詳細については[ドキュメント](/partitioned-table.md#range-interval-partitioning)参照してください。 + 詳細については[ドキュメント](/partitioned-table.md#range-interval-partitioning)を参照してください。 - 生成された列は一般公開（GA）されます @[bb7133](https://github.com/bb7133) @@ -172,7 +172,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 生成列を使用すると、TiDBのMySQL互換性が向上し、MySQLからの移行プロセスが簡素化されます。また、データメンテナンスの複雑さが軽減され、データの一貫性とクエリ効率が向上します。 - 詳細については[ドキュメント](/generated-columns.md)参照してください。 + 詳細については[ドキュメント](/generated-columns.md)を参照してください。 ### DB操作 {#db-operations} @@ -182,7 +182,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 よりスムーズなアップグレードを実現するために、TiDB v7.1.0 では DDL タスクの自動一時停止と再開をサポートしています。v7.1.0 以降では、事前に DDL タスクを手動でキャンセルすることなく、クラスターをアップグレードできます。TiDB は、アップグレード前に実行中またはキューに登録されているユーザー DDL タスクを自動的に一時停止し、ローリングアップグレード後にこれらのタスクを再開します。これにより、TiDB クラスターのアップグレードが容易になります。 - 詳細については[ドキュメント](/smooth-upgrade-tidb.md)参照してください。 + 詳細については[ドキュメント](/smooth-upgrade-tidb.md)を参照してください。 ### 可観測性 {#observability} @@ -206,7 +206,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 v7.1.0 以降、TiDB は LDAP 認証をサポートし、 `authentication_ldap_sasl`と`authentication_ldap_simple` 2 つの認証プラグインを提供します。 - 詳細については[ドキュメント](/security-compatibility-with-mysql.md)参照してください。 + 詳細については[ドキュメント](/security-compatibility-with-mysql.md)を参照してください。 - データベース監査機能の強化（Enterprise Edition） @@ -236,15 +236,15 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - 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) +- 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) ### システム変数 {#system-variables} | 変数名 | タイプを変更 | 説明 | | --------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630) | 非推奨 | デフォルト値を`OFF`から`ON`に変更します。 [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50)の場合、オプティマイザーは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。 | -| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)指定することで、キャッシュ可能なプランの最大数を制御できます。 | -| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)指定することで、キャッシュ可能なプランの最大数を制御できます。 | +| [`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | +| [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 非推奨 | バージョン7.1.0以降、このシステム変数は非推奨となりました。1 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を指定することで、キャッシュ可能なプランの最大数を制御できます。 | | `tidb_ddl_distribute_reorg` | 削除済み | この変数の名前は[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)に変更されます。 | | [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) | 変更 | 2 つの新しい値オプション`authentication_ldap_sasl`と`authentication_ldap_simple`が導入されました。 | | [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-new-in-v700) | 変更 | バージョン7.1.0以降で有効となり、負荷ベースのレプリカ読み取りをトリガーするためのしきい値を制御します。追加のテストを経て、デフォルト値を`"0s"`から`"1s"`に変更します。 | diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index f37bc4e4bbab8..897f30cb26098 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -17,7 +17,7 @@ TiDB バージョン: 7.1.1 ### 動作の変更 {#behavior-changes} -- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)参照してください。 +- 更新イベントの処理中に、イベント内の主キーまたはnull以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割します。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-a-single-update-change)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index c8f23e491b175..54485e6576b9a 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -22,7 +22,7 @@ TiDB バージョン: 7.1.2 ### 動作の変更 {#behavior-changes} -- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 +- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたはNULL以外の一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 38c6b284e1447..a5438ede15504 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -87,7 +87,7 @@ TiDB バージョン: 7.1.3 - 集計関数またはウィンドウ関数を含む共通テーブル式 (CTE) が他の再帰 CTE によって参照されるときに発生する可能性のある構文エラーの問題を修正しました[＃47603](https://github.com/pingcap/tidb/issues/47603) [＃47711](https://github.com/pingcap/tidb/issues/47711) @ [elsa0520](https://github.com/elsa0520) - 統計 TopN 構造を構築するときに発生する可能性のあるpanic問題を修正しました。 [＃35948](https://github.com/pingcap/tidb/issues/35948) @ [Rustin170506](https://github.com/Rustin170506) - MPPで計算された`COUNT(INT)`の結果が正しくない可能性がある問題を修正[＃48643](https://github.com/pingcap/tidb/issues/48643) @ [AilinKid](https://github.com/AilinKid) - - HashJoin演算子がプローブ実行するときにチャンクを再利用できない問題を修正しました [＃48082](https://github.com/pingcap/tidb/issues/48082) @ [wshwsh12](https://github.com/wshwsh12) + - HashJoin演算子がプローブを実行するときにチャンクを再利用できない問題を修正しました [＃48082](https://github.com/pingcap/tidb/issues/48082) @ [wshwsh12](https://github.com/wshwsh12) - TiKV diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index 9bda24ee9d1cb..25a3c21ede107 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -169,7 +169,7 @@ TiDB バージョン: 7.2.0 | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720) | 新しく追加された | 定期的な圧縮の間隔を制御します。この値よりも古い更新履歴を持つSSTファイルが圧縮対象として選択され、元のSSTファイルと同じ階層に書き換えられます。 | | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].ribbon-filter-above-level`](/tikv-configuration-file.md#ribbon-filter-above-level-new-in-v720) | 新しく追加された | この値以上のレベルではリボンフィルターを使用し、この値未満のレベルではブロックベースではないブルームフィルターを使用するかどうかを制御します。 | | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720) | 新しく追加された | TTLよりも古い更新情報を持つSSTファイルは、自動的に圧縮対象として選択されます。 | -| TiDB Lightning | `send-kv-pairs` | 非推奨 | バージョン7.2.0以降、パラメータ`send-kv-pairs`は非推奨となりました。物理インポートモードでTiKVにデータを送信する際の1リクエストの最大サイズを制御するには、 [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md)使用してください。 | +| 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 ステートメントを手動で処理する必要があります。 | diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 3154eec22c2fc..44e4419e6bf85 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -21,9 +21,9 @@ TiDB バージョン: 7.4.0 - 分散実行フレームワーク (DXF) のバックエンド`ADD INDEX`または`IMPORT INTO`タスクを並列実行するための TiDB ノードの選択をサポート (実験的) [＃46453](https://github.com/pingcap/tidb/pull/46453) @ [ywqzzy](https://github.com/ywqzzy) - リソースを大量に消費するクラスターで`ADD INDEX`または`IMPORT INTO`タスクを並列実行すると、TiDBノードのリソースを大量に消費し、クラスターのパフォーマンス低下につながる可能性があります。v7.4.0以降では、システム変数[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)使用して、 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)以下の各TiDBノードのサービススコープを制御できます。既存のTiDBノードを複数選択するか、新しいTiDBノードにTiDBサービススコープを設定すると、すべての並列タスク`ADD INDEX`と`IMPORT INTO`これらのノードでのみ実行されます。このメカニズムにより、既存のサービスへのパフォーマンスへの影響を回避できます。 + リソースを大量に消費するクラスターで`ADD INDEX`または`IMPORT INTO`タスクを並列実行すると、TiDBノードのリソースを大量に消費し、クラスターのパフォーマンス低下につながる可能性があります。v7.4.0以降では、システム変数[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を使用して、 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)以下の各TiDBノードのサービススコープを制御できます。既存のTiDBノードを複数選択するか、新しいTiDBノードにTiDBサービススコープを設定すると、すべての並列タスク`ADD INDEX`と`IMPORT INTO`これらのノードでのみ実行されます。このメカニズムにより、既存のサービスへのパフォーマンスへの影響を回避できます。 - 詳細については[ドキュメント](/system-variables.md#tidb_service_scope-new-in-v740)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_service_scope-new-in-v740)を参照してください。 - パーティション化されたRaft KVストレージエンジンの強化 (実験的) [＃11515](https://github.com/tikv/tikv/issues/11515) [＃12842](https://github.com/tikv/tikv/issues/12842) @ [busyjay](https://github.com/busyjay) @ [tonyxuqqi](https://github.com/tonyxuqqi) @ [tabokie](https://github.com/tabokie) @ [bufferflies](https://github.com/bufferflies) @ [5kbpers](https://github.com/5kbpers) @ [SpadeA-Tang](https://github.com/SpadeA-Tang) @ [nolouch](https://github.com/nolouch) @@ -31,7 +31,7 @@ TiDB バージョン: 7.4.0 TiDB v7.4.0では、Partitioned Raft KVストレージエンジンの互換性と安定性がさらに向上しました。大規模データテストを通じて、DM、 Dumpling、 TiDB Lightning、TiCDC、 BR、PITRといったTiDBエコシステムツールおよび機能との互換性が確保されています。さらに、Partitioned Raft KVストレージエンジンは、読み取りと書き込みが混在するワークロードにおいてもより安定したパフォーマンスを提供し、特に書き込み負荷の高いシナリオに適しています。さらに、各TiKVノードは8コアCPUをサポートし、8TBのデータストレージと64GBのメモリを搭載できるようになりました。 - 詳細については[ドキュメント](/partitioned-raft-kv.md)参照してください。 + 詳細については[ドキュメント](/partitioned-raft-kv.md)を参照してください。 - TiFlashは、分散ストレージおよびコンピューティングアーキテクチャ（GA）をサポートします[＃6882](https://github.com/pingcap/tiflash/issues/6882) @ [JaySon-Huang](https://github.com/JaySon-Huang) @ [JinheLin](https://github.com/JinheLin) @ [breezewish](https://github.com/breezewish) @ [lidezhu](https://github.com/lidezhu) @ [CalvinNeo](https://github.com/CalvinNeo) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) @@ -41,7 +41,7 @@ TiDB バージョン: 7.4.0 TiFlash**の分散ストレージおよびコンピューティングアーキテクチャ**と**結合ストレージおよびコンピューティングアーキテクチャ**は、同じクラスター内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。 - 詳細については[ドキュメント](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-disaggregated-and-s3.md)を参照してください。 ### パフォーマンス {#performance} @@ -49,7 +49,7 @@ TiDB バージョン: 7.4.0 - `value MEMBER OF(json_array)` - 詳細については[ドキュメント](/functions-and-operators/expressions-pushed-down.md)参照してください。 + 詳細については[ドキュメント](/functions-and-operators/expressions-pushed-down.md)を参照してください。 - 任意のフレーム定義タイプのウィンドウ関数をTiFlash にプッシュダウンする機能をサポート [＃7376](https://github.com/pingcap/tiflash/issues/7376) @ [xzhangxian1008](https://github.com/xzhangxian1008) @@ -61,7 +61,7 @@ TiDB バージョン: 7.4.0 v7.4.0では、TiDBに[グローバルソート](/tidb-global-sort.md)の機能が導入されました。エンコードされたデータをローカルに書き込んでソートする代わりに、クラウドストレージに書き込んでグローバルソートを行うようになりました。ソート後、インデックスデータとテーブルデータの両方がTiKVに並列でインポートされるため、パフォーマンスと安定性が向上します。 - 詳細については[ドキュメント](/tidb-global-sort.md)参照してください。 + 詳細については[ドキュメント](/tidb-global-sort.md)を参照してください。 - 非プリペアドステートメントの実行プランのキャッシュをサポート (GA) [＃36598](https://github.com/pingcap/tidb/issues/36598) @ [qw4990](https://github.com/qw4990) @@ -69,9 +69,9 @@ TiDB バージョン: 7.4.0 非プリペアドプランキャッシュを有効にすると、メモリとCPUのオーバーヘッドが増加する可能性があり、すべての状況に適しているとは限りません。v7.4.0以降、この機能はデフォルトで無効になっています。[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)を有効にし、 [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)でキャッシュサイズを制御できます。 - また、この機能はデフォルトではDML文をサポートしておらず、SQL文には一定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)参照してください。 + また、この機能はデフォルトではDML文をサポートしておらず、SQL文には一定の制限があります。詳細については、 [制限](/sql-non-prepared-plan-cache.md#restrictions)を参照してください。 - 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)参照してください。 + 詳細については[ドキュメント](/sql-non-prepared-plan-cache.md)を参照してください。 ### 信頼性 {#reliability} @@ -81,7 +81,7 @@ TiDB バージョン: 7.4.0 v7.4.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`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740)に設定することで、クエリのメモリ使用量を効率的に管理し、 TiFlashのメモリリソースをより適切に制御できます。 - 詳細については[ドキュメント](/tiflash/tiflash-spill-disk.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-spill-disk.md)を参照してください。 - ユーザー定義の TiKV 読み取りタイムアウトをサポート [＃45380](https://github.com/pingcap/tidb/issues/45380) @ [crazycs520](https://github.com/crazycs520) @@ -89,7 +89,7 @@ TiDB バージョン: 7.4.0 TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやstorage環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 - 詳細については[ドキュメント](/system-variables.md#tikv_client_read_timeout-new-in-v740)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tikv_client_read_timeout-new-in-v740)を参照してください。 - オプティマイザヒントを使用して、一部のシステム変数の値を一時的に変更することをサポートします。 [＃45892](https://github.com/pingcap/tidb/issues/45892) @ [winoros](https://github.com/winoros) @@ -97,7 +97,7 @@ TiDB バージョン: 7.4.0 変更可能なシステム変数は、ヒント`SET_VAR()`の[システム変数](/system-variables.md)で確認できます。明示的にサポートされていない変数を変更すると、予期しない動作が発生する可能性があるため、変更しないことを強くお勧めします。 - 詳細については[ドキュメント](/optimizer-hints.md)参照してください。 + 詳細については[ドキュメント](/optimizer-hints.md)を参照してください。 - TiFlashはリソース制御をサポート [＃7660](https://github.com/pingcap/tiflash/issues/7660) @ [guo-shaoge](https://github.com/guo-shaoge) @@ -105,13 +105,13 @@ TiDB バージョン: 7.4.0 TiFlashリソース制御機能を有効にするかどうかを制御するには、 TiFlashパラメータ`enable_resource_control`設定します。この機能を有効にすると、 TiFlashはTiDBのリソースグループ設定に基づいてリソースのスケジュールと管理を実行し、全体的なリソースの適切な割り当てと使用を保証します。 - 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)参照してください。 + 詳細については[ドキュメント](/tidb-resource-control-ru-groups.md)を参照してください。 - TiFlashはパイプライン実行モデル（GA） をサポートします。 [＃6518](https://github.com/pingcap/tiflash/issues/6518) @ [SeaRise](https://github.com/SeaRise) TiFlash v7.2.0 以降、パイプライン実行モデルが導入されました。このモデルは、すべてのスレッドリソースを一元管理し、タスク実行を均一にスケジュールすることで、スレッドリソースを最大限に活用し、リソースの過剰使用を回避します。v7.4.0 では、 TiFlash はスレッドリソースの使用状況の統計を改善し、パイプライン実行モデルは GA 機能となり、デフォルトで有効化されます。この機能はTiFlashリソース制御機能と相互に依存しているため、TiDB v7.4.0 では、以前のバージョンでパイプライン実行モデルの有効化/無効化に使用されていた変数`tidb_enable_tiflash_pipeline_model`削除されました。代わりに、 TiFlashパラメータ`tidb_enable_resource_control`を設定することで、パイプライン実行モデルとTiFlashリソース制御機能を有効化または無効化できます。 - 詳細については[ドキュメント](/tiflash/tiflash-pipeline-model.md)参照してください。 + 詳細については[ドキュメント](/tiflash/tiflash-pipeline-model.md)を参照してください。 - オプティマイザモードのオプションを追加 [＃46080](https://github.com/pingcap/tidb/issues/46080) @ [time-and-fate](https://github.com/time-and-fate) @@ -119,7 +119,7 @@ TiDB バージョン: 7.4.0 長期にわたって安定したOLTPアプリケーションや、既存の実行プランに自信がある場合は、テスト後にモード`determinate`に切り替えることをお勧めします。これにより、プラン変更の可能性が軽減されます。 - 詳細については[ドキュメント](/system-variables.md#tidb_opt_objective-new-in-v740)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_opt_objective-new-in-v740)を参照してください。 - TiDB リソース制御はバックグラウンドタスクの管理をサポートします (実験的) [＃44517](https://github.com/pingcap/tidb/issues/44517) @ [glorv](https://github.com/glorv) @@ -134,13 +134,13 @@ TiDB バージョン: 7.4.0 デフォルトでは、バックグラウンドタスクとしてマークされたタスクタイプは空で、バックグラウンドタスクの管理は無効になっています。このデフォルトの動作は、TiDB v7.4.0より前のバージョンと同じです。バックグラウンドタスクを管理するには、 `default`リソースグループのバックグラウンドタスクタイプを手動で変更する必要があります。 - 詳細については[ドキュメント](/tidb-resource-control-background-tasks.md)参照してください。 + 詳細については[ドキュメント](/tidb-resource-control-background-tasks.md)を参照してください。 - ロック統計が一般公開（GA）される[＃46351](https://github.com/pingcap/tidb/issues/46351) @ [Rustin170506](https://github.com/Rustin170506) v7.4.0では、 [ロック統計](/statistics.md#lock-statistics)一般提供となります。運用上のセキュリティを確保するため、統計情報のロックとロック解除には、統計情報の収集と同じ権限が必要です。さらに、TiDBは特定のパーティションに対する統計情報のロックとロック解除をサポートし、柔軟性が向上しています。データベース内のクエリや実行プランに自信があり、変更を防止したい場合は、統計情報をロックすることで安定性を高めることができます。 - 詳細については[ドキュメント](/statistics.md#lock-statistics)参照してください。 + 詳細については[ドキュメント](/statistics.md#lock-statistics)を参照してください。 - テーブルにハッシュ結合を選択するかどうかを制御するシステム変数を導入します。 [＃46695](https://github.com/pingcap/tidb/issues/46695) @ [coderplay](https://github.com/coderplay) @@ -148,7 +148,7 @@ TiDB バージョン: 7.4.0 TiDB v7.4.0以降、テーブルのハッシュ結合を制御するためのシステム変数[`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740)導入されました。これはデフォルトで有効になっています（ `ON` ）。実行プランでテーブル間のハッシュ結合を選択する必要がない場合は、この変数を`OFF`に変更することで、実行プランのロールバックの可能性を低減し、システムの安定性を向上させることができます。 - 詳細については[ドキュメント](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740)を参照してください。 - 統計キャッシュのメモリ制御は一般提供（GA） [＃45367](https://github.com/pingcap/tidb/issues/45367) @ [hawkingrei](https://github.com/hawkingrei) @@ -156,7 +156,7 @@ TiDB バージョン: 7.4.0 v7.4.0 以降、この機能は一般提供 (GA) されます。 - 詳細については[ドキュメント](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610)を参照してください。 ### SQL {#sql} @@ -164,13 +164,13 @@ TiDB バージョン: 7.4.0 v7.4.0より前のバージョンでは、TiDBのパーティションテーブルのパーティションタイプは変更できませんでした。v7.4.0以降では、パーティションテーブルを非パーティションテーブルに変更したり、非パーティションテーブルをパーティションテーブルに変更したり、パーティションタイプの変更がサポートされるようになりました。これにより、パーティションテーブルのパーティションタイプと数を柔軟に調整できるようになりました。例えば、 `ALTER TABLE t PARTITION BY ...`ステートメントを使用してパーティションタイプを変更できます。 - 詳細については[ドキュメント](/partitioned-table.md#convert-a-partitioned-table-to-a-non-partitioned-table)参照してください。 + 詳細については[ドキュメント](/partitioned-table.md#convert-a-partitioned-table-to-a-non-partitioned-table)を参照してください。 - TiDBは`ROLLUP`修飾子と`GROUPING`関数の使用をサポートしています [＃44487](https://github.com/pingcap/tidb/issues/44487) @ [AilinKid](https://github.com/AilinKid) `WITH ROLLUP`修飾子と`GROUPING`関数は、多次元データ要約のためのデータ分析でよく使用されます。v7.4.0 以降では、 `GROUP BY`句で`WITH ROLLUP`修飾子と`GROUPING`関数を使用できます。例えば、 `SELECT ... FROM ... GROUP BY ... WITH ROLLUP`構文で`WITH ROLLUP`修飾子を使用できます。 - 詳細については[ドキュメント](/functions-and-operators/group-by-modifier.md)参照してください。 + 詳細については[ドキュメント](/functions-and-operators/group-by-modifier.md)を参照してください。 ### DB操作 {#db-operations} @@ -180,7 +180,7 @@ TiDB バージョン: 7.4.0 TiDB v7.4.0では、MySQL 8.0と互換性のあるシステム変数`default_collation_for_utf8mb4`も導入されました。これにより、utf8mb4文字セットのデフォルトの照合順序を指定できるようになり、 MySQL 5.7以前のバージョンからの移行やデータレプリケーションとの互換性が確保されます。 - 詳細については[ドキュメント](/character-set-and-collation.md#character-sets-and-collations-supported-by-tidb)参照してください。 + 詳細については[ドキュメント](/character-set-and-collation.md#character-sets-and-collations-supported-by-tidb)を参照してください。 ### 可観測性 {#observability} @@ -194,7 +194,7 @@ TiDB バージョン: 7.4.0 v7.4.0 では、TiDB Dashboardは、診断エクスペリエンスを向上させるために、**スロー クエリ ページ**と**SQL ステートメント**ページで実行プランをテーブル ビューで表示することをサポートしています。 - 詳細については[ドキュメント](/dashboard/dashboard-statement-details.md)参照してください。 + 詳細については[ドキュメント](/dashboard/dashboard-statement-details.md)を参照してください。 ### データ移行 {#data-migration} @@ -207,7 +207,7 @@ TiDB バージョン: 7.4.0 - `Split_File`オプションの構成をサポートします。これにより、大きな CSV ファイルを複数の 256 MiB の小さな CSV ファイルに分割して並列処理し、インポート パフォーマンスを向上させることができます。 - 圧縮されたCSVファイルとSQLファイル`.snappy`インポート`.zst`サポートします。サポートされている`.zstd`形式は、 `.gzip` `.gz` 。 - 詳細については[ドキュメント](/sql-statements/sql-statement-import-into.md)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-import-into.md)を参照してください。 - Dumplingは、データをCSVファイルにエクスポートする際に、ユーザー定義のターミネータをサポートします[＃46982](https://github.com/pingcap/tidb/issues/46982) @ [GMHDBJD](https://github.com/GMHDBJD) @@ -215,13 +215,13 @@ TiDB バージョン: 7.4.0 バージョン7.4.0以降、 Dumplingに新しいパラメータ`--csv-line-terminator`が導入されました。このパラメータを使用すると、データをCSVファイルにエクスポートする際に、任意の終端文字を指定できます。このパラメータは`"\r\n"`と`"\n"`サポートしています。以前のバージョンとの一貫性を保つため、デフォルトの終端文字は`"\r\n"`です。 - 詳細については[ドキュメント](/dumpling-overview.md#option-list-of-dumpling)参照してください。 + 詳細については[ドキュメント](/dumpling-overview.md#option-list-of-dumpling)を参照してください。 - TiCDCはPulsarへのデータ複製をサポート [＃9413](https://github.com/pingcap/tiflow/issues/9413) @ [yumchina](https://github.com/yumchina) @ [asddongmen](https://github.com/asddongmen) Pulsarは、クラウドネイティブかつ分散型のメッセージストリーミングプラットフォームであり、リアルタイムデータストリーミングエクスペリエンスを大幅に向上させます。v7.4.0以降、TiCDCは変更データをPulsarに`canal-json`形式で複製し、Pulsarとのシームレスな統合を実現します。この機能により、TiCDCはTiDBの変更を容易にキャプチャしてPulsarに複製できるため、データ処理と分析機能に新たな可能性をもたらします。Pulsarから新たに生成された変更データを読み取り、処理する独自のコンシューマーアプリケーションを開発することで、特定のビジネスニーズに対応できます。 - 詳細については[ドキュメント](/ticdc/ticdc-sink-to-pulsar.md)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-sink-to-pulsar.md)を参照してください。 @@ -229,7 +229,7 @@ TiDB バージョン: 7.4.0 バージョン7.4.0より前のTiCDCでは、Kafkaの最大メッセージサイズ（ `max.message.bytes` ）を超える大きなメッセージを下流に送信できませんでした。バージョン7.4.0以降では、Kafkaを下流として変更フィードを設定する際に、大きなメッセージを保存する外部ストレージの場所を指定し、外部ストレージ内の大きなメッセージのアドレスを含む参照メッセージをKafkaに送信できるようになりました。コンシューマーはこの参照メッセージを受信すると、外部ストレージのアドレスからメッセージの内容を取得できます。 - 詳細については[ドキュメント](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-storage)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-storage)を参照してください。 ## 互換性の変更 {#compatibility-changes} @@ -247,7 +247,7 @@ TiDB バージョン: 7.4.0 - MySQL 8.0 との互換性を向上させるために[`information_schema.CHECK_CONSTRAINTS`](/information-schema/information-schema-check-constraints.md)テーブルが追加されました。 -- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたは非NULLの一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)参照してください。 +- 複数の変更を含むトランザクションにおいて、更新イベントで主キーまたは非NULLの一意インデックス値が変更された場合、TiCDCはイベントを削除イベントと挿入イベントに分割し、すべてのイベントが挿入イベントに先行する削除イベントの順序に従うようにします。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#transactions-containing-multiple-update-changes)を参照してください。 ### システム変数 {#system-variables} @@ -286,7 +286,7 @@ TiDB バージョン: 7.4.0 ## 廃止および削除された機能 {#deprecated-and-removed-features} - [mydumper](https://docs-archive.pingcap.com/tidb/v4.0/mydumper-overview)バージョン7.5.0で廃止され、その機能の大部分は[Dumpling](/dumpling-overview.md)に置き換えられました。mydumperではなくDumplingを使用することを強くお勧めします。 -- TiKVインポーターはバージョン7.5.0で廃止されます。代替として[TiDB Lightningの物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)使用することを強くお勧めします。 +- TiKVインポーターはバージョン7.5.0で廃止されます。代替として[TiDB Lightningの物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用することを強くお勧めします。 - TiCDCの`enable-old-value`のパラメータは削除されます[＃9667](https://github.com/pingcap/tiflow/issues/9667) @ [3AceShowHand](https://github.com/3AceShowHand) ## 改善点 {#improvements} diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index 8f4d3d814d387..9ceef415db7b1 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -153,7 +153,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - TiKV インポーターは v7.5.0 で非推奨になりました。代わりに[TiDB Lightningの物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用することを強くお勧めします。 -- TiDB v7.5.0以降、 [TiDB Binlog](https://docs.pingcap.com/tidb/v7.5/tidb-binlog-overview)のデータレプリケーション機能に関する技術サポートは提供されなくなりました。データレプリケーションの代替ソリューションとして[TiCDC](/ticdc/ticdc-overview.md)を使用することを強くお勧めします。TiDB Binlog v7.5.0は引き続きポイントインタイムリカバリ（PITR）シナリオをサポートしていますが、このコンポーネントは将来のバージョンで完全に非推奨となります。データリカバリの代替ソリューションとして[PITR](/br/br-pitr-guide.md)使用することをお勧めします。 +- TiDB v7.5.0以降、 [TiDB Binlog](https://docs.pingcap.com/tidb/v7.5/tidb-binlog-overview)のデータレプリケーション機能に関する技術サポートは提供されなくなりました。データレプリケーションの代替ソリューションとして[TiCDC](/ticdc/ticdc-overview.md)を使用することを強くお勧めします。TiDB Binlog v7.5.0は引き続きポイントインタイムリカバリ（PITR）シナリオをサポートしていますが、このコンポーネントは将来のバージョンで完全に非推奨となります。データリカバリの代替ソリューションとして[PITR](/br/br-pitr-guide.md)を使用することをお勧めします。 - 統計情報用の[`Fast Analyze`](/system-variables.md#tidb_enable_fast_analyze)機能（実験的）は、バージョン7.5.0で非推奨となりました。 diff --git a/releases/release-7.5.6.md b/releases/release-7.5.6.md index 6a9d51689b6ea..9c76a65006f34 100644 --- a/releases/release-7.5.6.md +++ b/releases/release-7.5.6.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.5.6 ## 互換性の変更 {#compatibility-changes} -- openEuler 22.03 LTS SP3/SP4 オペレーティングシステムをサポートします。詳細については、 [OSおよびプラットフォームの要件](https://docs.pingcap.com/tidb/v7.5/hardware-and-software-requirements#os-and-platform-requirements)参照してください。 +- openEuler 22.03 LTS SP3/SP4 オペレーティングシステムをサポートします。詳細については、 [OSおよびプラットフォームの要件](https://docs.pingcap.com/tidb/v7.5/hardware-and-software-requirements#os-and-platform-requirements)を参照してください。 ## 改善点 {#improvements} diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index b8ae86a5afd9e..db74f930f3209 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -136,7 +136,7 @@ TiDB バージョン: 7.6.0 - `FLASHBACK CLUSTER`は、正確な TSO [#48372](https://github.com/pingcap/tidb/issues/48372) @ [BornChanger](https://github.com/BornChanger)の指定をサポートしています - TiDB v7.6.0 では、フラッシュバック機能がより強力かつ正確になりました。クラスタを指定した履歴タイムスタンプにロールバックできるだけでなく、 `FLASHBACK CLUSTER TO TSO`を使用して正確なリカバリ[TSO](/tso.md)指定できるため、データリカバリの柔軟性が向上します。たとえば、この機能を TiCDC と組み合わせて使用​​できます。ダウンストリームの TiDB クラスタでデータレプリケーションを一時停止し、オンライン前の読み書きテストを実行した後、この機能を使用すると、クラスタは一時停止した TSO にスムーズかつ迅速にロールバックし、TiCDC を使用してデータのレプリケーションを再開できます。これにより、オンライン前の検証プロセスが効率化され、データ管理が簡素化されます。 + TiDB v7.6.0 では、フラッシュバック機能がより強力かつ正確になりました。クラスタを指定した履歴タイムスタンプにロールバックできるだけでなく、 `FLASHBACK CLUSTER TO TSO`を使用して正確なリカバリ[TSO](/tso.md)を指定できるため、データリカバリの柔軟性が向上します。たとえば、この機能を TiCDC と組み合わせて使用​​できます。ダウンストリームの TiDB クラスタでデータレプリケーションを一時停止し、オンライン前の読み書きテストを実行した後、この機能を使用すると、クラスタは一時停止した TSO にスムーズかつ迅速にロールバックし、TiCDC を使用してデータのレプリケーションを再開できます。これにより、オンライン前の検証プロセスが効率化され、データ管理が簡素化されます。 ```sql FLASHBACK CLUSTER TO TSO 445494839813079041; diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index d6fd27fab9ff8..7e903c1a4a75b 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -29,11 +29,11 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 リソースグループ内のクエリの最大実行時間を設定できます。クエリの実行時間が設定値を超えると、クエリの優先度が自動的に下げられるか、クエリがキャンセルされます。また、問題のあるクエリの同時実行数が多すぎる場合、特定フェーズで過剰なリソース消費を回避するために、テキストまたは実行プランを通じて、特定されたクエリに一致するクエリを一定期間内に即時に指定することもできます。 - TiDBはクエリの手動マークもサポートしています。1コマンド[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)使用すると、SQLテキスト、SQLダイジェスト、または実行プランに基づいてクエリをマークできます。マークに一致するクエリはダウングレードまたはキャンセルされ、SQLブロックリストを追加する目的を達成できます。 + TiDBはクエリの手動マークもサポートしています。1コマンド[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を使用すると、SQLテキスト、SQLダイジェスト、または実行プランに基づいてクエリをマークできます。マークに一致するクエリはダウングレードまたはキャンセルされ、SQLブロックリストを追加する目的を達成できます。 予想よりも多くのリソースを消費するクエリの自動管理機能により、根本原因が特定される前にクエリの問題が全体的なパフォーマンスに与える影響を迅速に軽減する効果的な手段がユーザーに提供され、データベースの安定性が向上します。 - 詳細については[ドキュメント](/tidb-resource-control-runaway-queries.md)参照してください。 + 詳細については[ドキュメント](/tidb-resource-control-runaway-queries.md)を参照してください。 ### SQL {#sql} @@ -43,7 +43,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 v8.1.0 以降では、列を`ADD COLUMN`ずつ追加するときに、式をデフォルト値として使用できます。 - 詳細については[ドキュメント](/data-type-default-values.md#specify-expressions-as-default-values)参照してください。 + 詳細については[ドキュメント](/data-type-default-values.md#specify-expressions-as-default-values)を参照してください。 ### DB操作 {#db-operations} @@ -53,7 +53,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 TiDB v8.1.0以降、この機能はデフォルトで有効になっています（ [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)デフォルト`ON`に設定されます）。この機能を有効にすると、DXFは複数のTiDBノードで同じ`ADD INDEX`または`IMPORT INTO`タスクを並列実行するようにスケジュールできます。これにより、TiDBクラスターのリソースを最大限に活用し、これらのタスクのパフォーマンスを大幅に向上させることができます。さらに、TiDBノードを追加し、追加したノードに[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することで、 `ADD INDEX`および`IMPORT INTO`タスクのパフォーマンスを直線的に向上させることができます。 - 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)参照してください。 + 詳細については[ドキュメント](/tidb-distributed-execution-framework.md)を参照してください。 ### セキュリティ {#security} @@ -61,7 +61,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 強化された TiDB ログの非感度化は、ログファイル内の SQL テキスト情報をマークすることで実装され、ユーザーがログを表示するときに機密データを削除することをサポートします。ログ情報をマークするかどうかを制御することで、さまざまなシナリオで TiDB ログを安全に使用でき、ログ非感度化を使用する際のセキュリティと柔軟性が向上します。この機能を使用するには、システム変数`tidb_redact_log`を`MARKER`に設定すると、TiDB のランタイムログ内の SQL テキストがマークされます。さらに、TiDBサーバーで`collect-log`サブコマンドを使用して、マークされた機密データをログから削除し、ログを安全な方法で表示できます。すべてのマーカーを削除して通常のログを取得することもできます。この機能は、v8.1.0 で一般提供されました。 - 詳細については[ドキュメント](/system-variables.md#tidb_redact_log)参照してください。 + 詳細については[ドキュメント](/system-variables.md#tidb_redact_log)を参照してください。 ### データ移行 {#data-migration} @@ -71,7 +71,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 v8.1.0 では、 `IMPORT INTO ... FROM SELECT`構文が一般公開 (GA) され、 `IMPORT INTO`ステートメントの機能シナリオが充実します。 - 詳細については[ドキュメント](/sql-statements/sql-statement-import-into.md)参照してください。 + 詳細については[ドキュメント](/sql-statements/sql-statement-import-into.md)を参照してください。 - TiDB Lightningは競合解決戦略を簡素化し、 `replace`戦略（GA） を使用して競合するデータの処理をサポートします。 [＃51036](https://github.com/pingcap/tidb/issues/51036) @ [lyzx2001](https://github.com/lyzx2001) @@ -79,13 +79,13 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 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）されます。 - 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)参照してください。 + 詳細については[ドキュメント](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 - TiCDCはクライアント認証をサポートします [＃10636](https://github.com/pingcap/tiflow/issues/10636) @ [CharlesCheung96](https://github.com/CharlesCheung96) v8.1.0では、TiCDC CLIまたはOpenAPIを使用する際に、TiCDCはクライアント認証をサポートします。この機能により、クライアント証明書を用いたクライアント認証を要求するようにTiCDCを設定でき、相互トランスポート層Security（mTLS）を確立できます。さらに、TiDBのユーザー名とパスワードに基づく認証も設定できます。 - 詳細については[ドキュメント](/ticdc/ticdc-client-authentication.md)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-client-authentication.md)を参照してください。 ## 互換性の変更 {#compatibility-changes} @@ -95,9 +95,9 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 ### 動作の変更 {#behavior-changes} -- 以前のバージョンでは、 TiDB Lightningの`tidb.tls`設定項目は、値`"false"`と`""` 、および値`"preferred"`と`"skip-verify"`同じものとして扱いました。v8.1.0 以降、 TiDB Lightning は`tidb.tls`に対して`"false"` 、 `""` 、 `"skip-verify"` 、 `"preferred"`の動作を区別します。詳細については、 [TiDB Lightning構成](/tidb-lightning/tidb-lightning-configuration.md)参照してください。 +- 以前のバージョンでは、 TiDB Lightningの`tidb.tls`設定項目は、値`"false"`と`""` 、および値`"preferred"`と`"skip-verify"`同じものとして扱いました。v8.1.0 以降、 TiDB Lightning は`tidb.tls`に対して`"false"` 、 `""` 、 `"skip-verify"` 、 `"preferred"`の動作を区別します。詳細については、 [TiDB Lightning構成](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 - `AUTO_ID_CACHE=1`のテーブルの場合、TiDB は[集中型AUTO_INCREMENT ID割り当てサービス](/auto-increment.md#mysql-compatibility-mode)をサポートします。以前のバージョンでは、このサービスのプライマリ TiDB ノードは、TiDB プロセスが終了すると（たとえば、TiDB ノードの再起動中）、自動割り当て ID を可能な限り連続的に保つために`forceRebase`操作を自動的に実行していました。しかし、 `AUTO_ID_CACHE=1`のテーブルが多すぎると、 `forceRebase`実行に非常に時間がかかり、TiDB がすぐに再起動できなくなり、データの書き込みがブロックされてシステムの可用性に影響を及ぼします。この問題を解決するために、v8.1.0 以降、TiDB は`forceRebase`動作を削除しますが、この変更により、フェイルオーバー中に一部の自動割り当て ID が連続しなくなります。 -- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは null 以外の一意インデックス値が変更されると、TiCDC はこのイベントを`DELETE`と`INSERT`イベントに分割していました。v8.1.0 では、MySQL シンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`が TiCDC `thresholdTS` (TiCDC の起動時に PD から取得する現在のタイムスタンプ) より小さい場合、TiCDC は`UPDATE`のイベントを`DELETE`と`INSERT`イベントに分割します。この動作変更により、TiCDC が受信した`UPDATE`のイベントの順序が正しくない可能性があり、その結果、分割された`DELETE`と`INSERT`件のイベントの順序も正しくなくなる可能性がある、下流データの不整合の問題が解決されます。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)参照してください。 +- 以前のバージョンでは、 `UPDATE`変更を含むトランザクションを処理する際に、 `UPDATE`イベントで主キーまたは null 以外の一意インデックス値が変更されると、TiCDC はこのイベントを`DELETE`と`INSERT`イベントに分割していました。v8.1.0 では、MySQL シンクを使用する場合、 `UPDATE`の変更のトランザクション`commitTS`が TiCDC `thresholdTS` (TiCDC の起動時に PD から取得する現在のタイムスタンプ) より小さい場合、TiCDC は`UPDATE`のイベントを`DELETE`と`INSERT`イベントに分割します。この動作変更により、TiCDC が受信した`UPDATE`のイベントの順序が正しくない可能性があり、その結果、分割された`DELETE`と`INSERT`件のイベントの順序も正しくなくなる可能性がある、下流データの不整合の問題が解決されます。詳細については、 [ドキュメント](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)を参照してください。 ### システム変数 {#system-variables} @@ -106,7 +106,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 | [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-new-in-v402) | 非推奨 | v8.1.0以降、TiDBのテレメトリ機能が削除され、この変数は機能しなくなりました。これは以前のバージョンとの互換性のためだけに保持されています。 | | [`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio) | 変更 | 値の範囲を`[0, 18446744073709551615]`から`(0, 1]`に変更します。 | | [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) | 変更 | デフォルト値を`OFF`から`ON`に変更します。これは、Distributed eXecution Framework（DXF）がデフォルトで有効になることを意味します。これにより、TiDBクラスターのリソースが最大限に活用され、 `ADD INDEX`および`IMPORT INTO`タスクのパフォーマンスが大幅に向上します。DXFが有効になっているクラスターをv8.1.0以降にアップグレードする場合は、アップグレード前にDXFを無効にしてください（ `tidb_enable_dist_task`を`OFF`に設定）。これにより、アップグレード中に`ADD INDEX`操作が発生し、データインデックスの不整合が発生するのを回避できます。アップグレード後、DXFを手動で有効にすることができます。 | -| [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) | 変更 | オプションの値を`""`または`background`から最大 64 文字の文字列に変更します。これにより、各 TiDB ノードのサービス範囲をより柔軟に制御できます。有効な文字は、数字`0-9` 、文字`a-zA-Z` 、アンダースコア`_` 、ハイフン`-`です。Distributed eXecution Framework (DXF) は、この変数の値に基づいて、どの TiDB ノードに分散タスクの実行をスケジュールするかを決定します。具体的なルールについては、 [タスクのスケジュール](/tidb-distributed-execution-framework.md#task-scheduling)参照してください。 | +| [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) | 変更 | オプションの値を`""`または`background`から最大 64 文字の文字列に変更します。これにより、各 TiDB ノードのサービス範囲をより柔軟に制御できます。有効な文字は、数字`0-9` 、文字`a-zA-Z` 、アンダースコア`_` 、ハイフン`-`です。Distributed eXecution Framework (DXF) は、この変数の値に基づいて、どの TiDB ノードに分散タスクの実行をスケジュールするかを決定します。具体的なルールについては、 [タスクのスケジュール](/tidb-distributed-execution-framework.md#task-scheduling)を参照してください。 | ### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} @@ -286,7 +286,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 ## パフォーマンステスト {#performance-test} -TiDB v8.1.0 のパフォーマンスについては、 TiDB Cloud Dedicated クラスターの[TPC-Cパフォーマンステストレポート](https://docs.pingcap.com/tidbcloud/v8.1-performance-benchmarking-with-tpcc)と[Sysbenchパフォーマンステストレポート](https://docs.pingcap.com/tidbcloud/v8.1-performance-benchmarking-with-sysbench)参照してください。 +TiDB v8.1.0 のパフォーマンスについては、 TiDB Cloud Dedicated クラスターの[TPC-Cパフォーマンステストレポート](https://docs.pingcap.com/tidbcloud/v8.1-performance-benchmarking-with-tpcc)と[Sysbenchパフォーマンステストレポート](https://docs.pingcap.com/tidbcloud/v8.1-performance-benchmarking-with-sysbench)を参照してください。 ## 貢献者 {#contributors} diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 9a042064dfe33..68ad2c99e53bb 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -14,7 +14,7 @@ TiDB バージョン: 8.1.1 ## 互換性の変更 {#compatibility-changes} - TiDB Lightningを使用してCSVファイルをインポートする際、並列性とインポートパフォーマンスを向上させるために大きなCSVファイルを複数の小さなCSVファイルに分割するために`strict-format = true`設定する場合は、明示的に`terminator`を指定する必要があります。値は`\r` 、または`\r\n` `\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ファイルをインポートする際、 `SPLIT_FILE`パラメータを指定して大きなCSVファイルを複数の小さなCSVファイルに分割し、同時実行性とインポートパフォーマンスを向上させる場合は、行末文字`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ファイルをインポートする際、 `SPLIT_FILE`パラメータを指定して大きなCSVファイルを複数の小さなCSVファイルに分割し、同時実行性とインポートパフォーマンスを向上させる場合は、行末文字`LINES_TERMINATED_BY`を明示的に指定する必要があります。値は`\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSVファイルデータの解析時に例外が発生する可能性があります[＃37338](https://github.com/pingcap/tidb/issues/37338) @ [lance6716](https://github.com/lance6716) - 並列計算中のディスクオーバーフローによるクエリ結果の誤りを回避するため、変数[`tidb_enable_parallel_hashagg_spill`](https://docs.pingcap.com/tidb/v8.1/system-variables#tidb_enable_parallel_hashagg_spill-new-in-v800)のデフォルト値を`ON`から`OFF`に変更してください。v8.0.0またはv8.1.0からv8.1.1にアップグレードしたクラスターの場合、この変数はアップグレード後もデフォルト値の`ON`のままとなるため、手動で`OFF`に変更することをお勧めします[＃55290](https://github.com/pingcap/tidb/issues/55290) @ [xzhangxian1008](https://github.com/xzhangxian1008) - TiKV構成項目[`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type)のスコープを変更します。 diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index a43a03347c13a..58ae8a906483b 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -137,7 +137,7 @@ TiDB バージョン: 8.2.0 - [`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} diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 5d4481afc1c35..6876912f168f4 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -118,7 +118,7 @@ TiDBバージョン：8.3.0 バージョン8.3.0より前は、高可用性を実現するためにプライマリ/セカンダリモードを使用する場合、TiProxyは仮想IPアドレスを管理するための追加コンポーネントを必要としていました。バージョン8.3.0以降、TiProxyは仮想IPアドレス管理機能を内蔵しています。プライマリ/セカンダリモードでプライマリノードがフェイルオーバーすると、新しいプライマリノードは指定された仮想IPアドレスに自動的にバインドされるため、クライアントは常に仮想IPアドレスを介して利用可能なTiProxyに接続できます。 - 仮想IPアドレス管理を有効にするには、TiProxy設定項目[`ha.virtual-ip`](/tiproxy/tiproxy-configuration.md#virtual-ip)使用して仮想IPアドレスを指定し、[`ha.interface`](/tiproxy/tiproxy-configuration.md#interface)を使用して仮想IPアドレスをバインドするネットワークインターフェイスを指定します。仮想IPアドレスは、これら両方の設定項目が設定されている場合にのみ、TiProxyインスタンスにバインドされます。 + 仮想IPアドレス管理を有効にするには、TiProxy設定項目[`ha.virtual-ip`](/tiproxy/tiproxy-configuration.md#virtual-ip)を使用して仮想IPアドレスを指定し、[`ha.interface`](/tiproxy/tiproxy-configuration.md#interface)を使用して仮想IPアドレスをバインドするネットワークインターフェイスを指定します。仮想IPアドレスは、これら両方の設定項目が設定されている場合にのみ、TiProxyインスタンスにバインドされます。 詳細については、[ドキュメント](/tiproxy/tiproxy-overview.md)を参照してください。 @@ -213,7 +213,7 @@ TiDBバージョン：8.3.0 - バージョン8.3.0以降、以下の機能は非推奨となります。 - バージョン 7.5.0 以降、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)レプリケーションは非推奨となりました。バージョン 8.3.0 以降、TiDB Binlog は完全に非推奨となり、今後のリリースで削除される予定です。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。 - - バージョン8.3.0以降、 [`tidb_enable_column_tracking`](/system-variables.md#tidb_enable_column_tracking-new-in-v540)システム変数は非推奨となりました。TiDBはデフォルトで述語列を追跡します。詳細については、 [`tidb_analyze_column_options`](/system-variables.md#tidb_analyze_column_options-new-in-v830)参照してください。 + - バージョン8.3.0以降、 [`tidb_enable_column_tracking`](/system-variables.md#tidb_enable_column_tracking-new-in-v540)システム変数は非推奨となりました。TiDBはデフォルトで述語列を追跡します。詳細については、 [`tidb_analyze_column_options`](/system-variables.md#tidb_analyze_column_options-new-in-v830)を参照してください。 - 以下の機能は、将来のバージョンで廃止される予定です。 diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 760e4c127d3e7..a0331db412948 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -99,7 +99,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 バージョン8.5.0以降、両方の暗号化機能が一般提供（GA）となり、クライアント側のデータセキュリティが強化されます。 - 詳細については、 [バックアップデータを暗号化する](/br/br-snapshot-manual.md#encrypt-the-backup-data)および[ログバックアップデータを暗号化する](/br/br-pitr-manual.md#encrypt-the-log-backup-data)参照してください。 + 詳細については、 [バックアップデータを暗号化する](/br/br-snapshot-manual.md#encrypt-the-backup-data)および[ログバックアップデータを暗号化する](/br/br-pitr-manual.md#encrypt-the-log-backup-data)を参照してください。 - TiKVの保存時暗号化は[Google Cloud Key Management Service (Google Cloud KMS)](https://cloud.google.com/docs/security/key-management-deep-dive) (GA) をサポートします。 [#8906](https://github.com/tikv/tikv/issues/8906) @[glorv](https://github.com/glorv) diff --git a/releases/release-8.5.6.md b/releases/release-8.5.6.md index 8ce4df6e1a6d6..be1bb4160dd1c 100644 --- a/releases/release-8.5.6.md +++ b/releases/release-8.5.6.md @@ -39,7 +39,7 @@ TiDBバージョン：8.5.6 バージョン 8.5.6 より前では、TiDB でスロークエリを識別する主な方法は、 [`tidb_slow_log_threshold`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_threshold)システム変数を設定することでした。このメカニズムはインスタンスレベルでグローバルに適用されるため、スロークエリログのトリガーを大まかにしか制御できず、セッションレベルや SQL レベルでのきめ細かい制御はサポートされていません。さらに、トリガー条件として実行時間 ( `Query_time` ) しかサポートしていないため、複雑なシナリオでスロークエリログをより正確にキャプチャする必要性を満たすことができません。 - バージョン 8.5.6 以降、TiDB [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856)スロークエリログの制御を強化しました。tidb_slow_log_rules システム変数を使用して、 `Query_time` 、 `Digest`などの条件に基づいて、 `Mem_max` `KV_total`多次元のスロークエリログ出力ルールを定義できます。tidb_slow_log_max_per_sec [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856)使用して、1 秒あたりに書き込まれるログエントリの数を制限したり、 [`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints)ヒントを使用して、特定の SQL ステートメントに対してスロークエリログを強制的に記録したりできます。これにより、スロークエリログをより柔軟かつきめ細かく制御できます。 + バージョン 8.5.6 以降、TiDB [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856)スロークエリログの制御を強化しました。tidb_slow_log_rules システム変数を使用して、 `Query_time` 、 `Digest`などの条件に基づいて、 `Mem_max` `KV_total`多次元のスロークエリログ出力ルールを定義できます。tidb_slow_log_max_per_sec [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856)を使用して、1 秒あたりに書き込まれるログエントリの数を制限したり、 [`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints)ヒントを使用して、特定の SQL ステートメントに対してスロークエリログを強制的に記録したりできます。これにより、スロークエリログをより柔軟かつきめ細かく制御できます。 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/identify-slow-queries)を参照してください。 @@ -81,8 +81,8 @@ 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は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以降、 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/versioning.md b/releases/versioning.md index 63a64f612441b..577f827ac8fd5 100644 --- a/releases/versioning.md +++ b/releases/versioning.md @@ -16,7 +16,7 @@ TiDB には 2 つのリリース シリーズがあります。 - 長期サポートリリース - 開発マイルストーンリリース（TiDB v6.0.0 で導入） -TiDB のメジャー リリースのサポート ポリシーについては、 [TiDB リリース サポート ポリシー](https://www.pingcap.com/tidb-release-support-policy/)参照してください。 +TiDB のメジャー リリースのサポート ポリシーについては、 [TiDB リリース サポート ポリシー](https://www.pingcap.com/tidb-release-support-policy/)を参照してください。 ## リリースバージョン管理 {#release-versioning} diff --git a/replicate-between-primary-and-secondary-clusters.md b/replicate-between-primary-and-secondary-clusters.md index eeca2bb450a61..86b9c80731924 100644 --- a/replicate-between-primary-and-secondary-clusters.md +++ b/replicate-between-primary-and-secondary-clusters.md @@ -104,7 +104,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー > > - `BACKUP`および`RESTORE` SQL ステートメントは実験的です。本番環境での使用は推奨されません。予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 > - 本番のクラスタでは、GCを無効にした状態でバックアップを実行すると、クラスタのパフォーマンスに影響を与える可能性があります。パフォーマンスの低下を避けるため、データのバックアップはピーク時以外の時間帯に行い、RATE_LIMITを適切な値に設定することをお勧めします。 -> - アップストリームとダウンストリームのクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#some-tips)確認してください。このドキュメントでは、アップストリームとダウンストリームのクラスタのバージョンが同じであることを前提としています。 +> - アップストリームとダウンストリームのクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#some-tips)を確認してください。このドキュメントでは、アップストリームとダウンストリームのクラスタのバージョンが同じであることを前提としています。 1. GCを無効にする。 @@ -171,7 +171,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー sync_diff_inspector -C ./config.yaml ``` - sync-diff-inspector の設定方法の詳細については、 [コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)参照してください。このドキュメントでは、構成は次のようになります。 + sync-diff-inspector の設定方法の詳細については、 [コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)を参照してください。このドキュメントでは、構成は次のようになります。 ```shell # Diff Configuration. @@ -233,11 +233,11 @@ summary: プライマリクラスタからセカンダリクラスタへデー - `--sink-uri` : ダウンストリームクラスタのURI - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時間 (または[ステップ2. 全データを移行する](#step-2-migrate-full-data)) - チェンジフィード構成の詳細については、 [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md)参照してください。 + チェンジフィード構成の詳細については、 [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md)を参照してください。 3. GCを有効にする。 - TiCDC を使用した増分移行では、GC はレプリケートされた履歴データのみを削除します。したがって、変更フィードを作成した後、次のコマンドを実行して GC を有効にする必要があります。詳細については、 [TiCDCのガベージコレクション（GC）セーフポイントの完全な動作とはどのようなものですか？](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)参照してください。 + TiCDC を使用した増分移行では、GC はレプリケートされた履歴データのみを削除します。したがって、変更フィードを作成した後、次のコマンドを実行して GC を有効にする必要があります。詳細については、 [TiCDCのガベージコレクション（GC）セーフポイントの完全な動作とはどのようなものですか？](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)を参照してください。 GCを有効にするには、次のコマンドを実行してください。 diff --git a/replicate-data-to-kafka.md b/replicate-data-to-kafka.md index ffae003789413..5d4f66be13133 100644 --- a/replicate-data-to-kafka.md +++ b/replicate-data-to-kafka.md @@ -50,7 +50,7 @@ summary: TiCDC を使用して TiDB データを Apache Kafka および Apache F {matcher = ['*.*'], topic = "tidb_{schema}_{table}", partition="index-value"}, ] - 設定ファイルの`dispatchers`の詳細な説明については[Kafka シンクのトピックおよびパーティションディスパッチャーのルールをカスタマイズする](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink)参照してください。 + 設定ファイルの`dispatchers`の詳細な説明については[Kafka シンクのトピックおよびパーティションディスパッチャーのルールをカスタマイズする](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink)を参照してください。 2. 増分データを Kafka に複製するための変更フィードを作成します。 diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md index 78a197443bbf9..2737974376daf 100644 --- a/resources/doc-templates/template-concept.md +++ b/resources/doc-templates/template-concept.md @@ -62,8 +62,8 @@ xxx このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiCDC を展開および保守する方法については、 [TiCDCのデプロイと管理](/ticdc/deploy-ticdc.md)参照してください。 -- changefeed の詳細については、 [チェンジフィードの概要](/ticdc/ticdc-changefeed-overview.md)参照してください。 +- TiCDC を展開および保守する方法については、 [TiCDCのデプロイと管理](/ticdc/deploy-ticdc.md)を参照してください。 +- changefeed の詳細については、 [チェンジフィードの概要](/ticdc/ticdc-changefeed-overview.md)を参照してください。 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 diff --git a/resources/doc-templates/template-new-feature.md b/resources/doc-templates/template-new-feature.md index bd28ea204da6e..29dbc963580c0 100644 --- a/resources/doc-templates/template-new-feature.md +++ b/resources/doc-templates/template-new-feature.md @@ -13,7 +13,7 @@ summary: このドキュメントを115～145文字で要約してください > **警告**（オプション） > -> この機能は実験的です。本番環境での使用は推奨されません。構文と実装は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> この機能は実験的です。本番環境での使用は推奨されません。構文と実装は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 このドキュメントでは、[機能名] の使用シナリオ、使用方法、制限事項、およびこの機能を使用する際の FAQ について説明します。 @@ -109,8 +109,8 @@ FAQ が多数ある場合は、この機能用に個別のFAQドキュメント このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)参照してください。 -- TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 +- 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 772d731585f26..69603f9c5c017 100644 --- a/resources/doc-templates/template-task.md +++ b/resources/doc-templates/template-task.md @@ -117,8 +117,8 @@ summary: このドキュメントを115～145文字で要約してください このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)参照してください。 -- TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 +- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)を参照してください。 +- TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 diff --git a/role-based-access-control.md b/role-based-access-control.md index cb53e7a386fe9..ae5b7a9fea8a6 100644 --- a/role-based-access-control.md +++ b/role-based-access-control.md @@ -26,7 +26,7 @@ TiDB のロールベースアクセス制御 (RBAC) システムの実装は、M CREATE ROLE 'app_developer', 'app_read', 'app_write'; ``` -ロールの命名形式と規則については、 [TiDB ユーザーアカウント管理](/user-account-management.md)参照してください。 +ロールの命名形式と規則については、 [TiDB ユーザーアカウント管理](/user-account-management.md)を参照してください。 ロールは`mysql.user`テーブルに保存され、ロール名のホスト名部分（省略されている場合）はデフォルトで`'%'`になります。作成しようとしているロール名は一意である必要があります。一意でない場合はエラーが報告されます。 @@ -34,7 +34,7 @@ CREATE ROLE 'app_developer', 'app_read', 'app_write'; ### ロールに権限を付与する {#grant-a-privilege-to-a-role} -ロールに権限を付与する操作は、ユーザーに権限を付与する操作と同じです。詳細は[TiDB権限管理](/privilege-management.md)参照してください。 +ロールに権限を付与する操作は、ユーザーに権限を付与する操作と同じです。詳細は[TiDB権限管理](/privilege-management.md)を参照してください。 たとえば、次のステートメントを使用して、 `app_read`ロールに`app_db`データベースを読み取る権限を付与できます。 diff --git a/runtime-filter.md b/runtime-filter.md index 80480b274e9be..d766b0fe72ef0 100644 --- a/runtime-filter.md +++ b/runtime-filter.md @@ -130,7 +130,7 @@ SHOW VARIABLES LIKE "tidb_runtime_filter_mode"; ### ステップ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 @@ -249,4 +249,4 @@ TPC-DS におけるテーブル`Sales`とテーブル`date_dim`の結合操作 - 結合タイプ：左外部結合、完全外部結合、およびアンチ結合（左テーブルがプローブ側の場合）は、ランタイムフィルターをサポートしていません。ランタイムフィルターは結合に関係するデータを事前にフィルタリングするため、上記の結合タイプでは不一致データが破棄されず、ランタイムフィルターは使用できません。 - 等価結合式：等価結合式内のプローブ列が複雑な式である場合、またはプローブ列の型がJSON、Blob、配列などの複雑なデータ型である場合、ランタイムフィルターは生成されません。主な理由は、これらの型の列が結合列として使用されることはほとんどないためです。フィルターが生成されたとしても、フィルタリング率は通常低くなります。 -上記の制限事項について、ランタイム フィルターが正しく生成されたかどうかを確認する必要がある場合は、 [`EXPLAIN`文](/sql-statements/sql-statement-explain.md)使用して実行プランを検証できます。 +上記の制限事項について、ランタイム フィルターが正しく生成されたかどうかを確認する必要がある場合は、 [`EXPLAIN`文](/sql-statements/sql-statement-explain.md)を使用して実行プランを検証できます。 diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index da495762cb29f..0d8d6b50b5b86 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -252,7 +252,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する > **注記：** > > - 同様の手順で TiDB ノードまたは PD ノードを削除できます。 -> - TiKVおよびTiFlashコンポーネントは非同期的にオフラインになり、停止処理に時間がかかるため、 TiUPはこれらのコンポーネントを別の方法でオフラインにします。詳細については、 [コンポーネントのオフラインプロセスの特別な処理](/tiup/tiup-component-cluster-scale-in.md#particular-handling-of-components-offline-process)参照してください。 +> - TiKVおよびTiFlashコンポーネントは非同期的にオフラインになり、停止処理に時間がかかるため、 TiUPはこれらのコンポーネントを別の方法でオフラインにします。詳細については、 [コンポーネントのオフラインプロセスの特別な処理](/tiup/tiup-component-cluster-scale-in.md#particular-handling-of-components-offline-process)を参照してください。 > - TiKVのPDクライアントは、PDノードのリストをキャッシュします。現在のバージョンのTiKVには、PDノードを自動的かつ定期的に更新するメカニズムが搭載されており、TiKVによってキャッシュされたPDノードのリストが期限切れになる問題を軽減するのに役立ちます。ただし、PDをスケールアウトした後は、スケールアウト前に存在していたすべてのPDノードを一度に削除することは避けてください。必要に応じて、既存のPDノードをすべてオフラインにする前に、PDリーダーを新しく追加されたPDノードに切り替えてください。 1. ノード ID 情報を表示する。 diff --git a/schema-object-names.md b/schema-object-names.md index 57140157fb44b..210fd5fb3a785 100644 --- a/schema-object-names.md +++ b/schema-object-names.md @@ -64,7 +64,7 @@ SELECT 1 AS `identifier`, 2 AS 'string'; 1 row in set (0.00 sec) ``` -詳細については[MySQLスキーマオブジェクト名](https://dev.mysql.com/doc/refman/8.0/en/identifiers.html)参照してください。 +詳細については[MySQLスキーマオブジェクト名](https://dev.mysql.com/doc/refman/8.0/en/identifiers.html)を参照してください。 ## 識別子修飾子 {#identifier-qualifiers} @@ -94,4 +94,4 @@ CREATE TABLE test.t (i int); `table_name.col_name` ``` -詳細については[MySQL 識別子修飾子](https://dev.mysql.com/doc/refman/8.0/en/identifier-qualifiers.html)参照してください。 +詳細については[MySQL 識別子修飾子](https://dev.mysql.com/doc/refman/8.0/en/identifier-qualifiers.html)を参照してください。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 8e9d28dbdab08..b4fc914dab044 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -44,7 +44,7 @@ The password complexity policies of TiDB and MySQL have the following difference - MySQL v5.7では、この機能は`validate_password`プラグインを使用して実装されています。プラグインをインストールすることで、この機能を有効化できます。 - MySQL v8.0では、この機能は`validate_password`コンポーネントを使用して実装されています。この機能を有効にするには、コンポーネントをインストールしてください。 - - TiDBにはこの機能が組み込まれています。システム変数[`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)使用してこの機能を有効にすることができます。 + - TiDBにはこの機能が組み込まれています。システム変数[`validate_password.enable`](/system-variables.md#validate_passwordenable-new-in-v650)を使用してこの機能を有効にすることができます。 - 辞書チェック: @@ -107,7 +107,7 @@ TiDBとMySQLの実装メカニズムは一貫しています。どちらも`mysq ## Authentication plugin status {#authentication-plugin-status} -TiDBは複数の認証方法をサポートしています。これらの方法は、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md)と[`ALTER USER`](/sql-statements/sql-statement-alter-user.md)使用してユーザーごとに指定できます。これらの方法は、MySQLの同名の認証方法と互換性があります。 +TiDBは複数の認証方法をサポートしています。これらの方法は、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md)と[`ALTER USER`](/sql-statements/sql-statement-alter-user.md)を使用してユーザーごとに指定できます。これらの方法は、MySQLの同名の認証方法と互換性があります。 You can use one of the following supported authentication methods in the table. To specify a default method that the server advertises when the client-server connection is being established, set the [`default_authentication_plugin`](/system-variables.md#default_authentication_plugin) variable. `tidb_sm3_password` is the SM3 authentication method only supported in TiDB. Therefore, to authenticate using this method, you must connect to TiDB using [TiDB-JDBC](https://github.com/pingcap/mysql-connector-j/tree/release/8.0-sm3). `tidb_auth_token` is a JSON Web Token (JWT)-based authentication method used in TiDB Cloud, and you can also configure it for use in TiDB Self-Managed. @@ -189,7 +189,7 @@ Here is an example for Header: > **警告：** > > - ヘッダーとペイロードのBase64エンコードは可逆です。機密情報を添付し**ないで**ください。 -> - `tidb_auth_token`認証方法では、クライアントが[`mysql_clear_password`](https://dev.mysql.com/doc/refman/8.0/en/cleartext-pluggable-authentication.html)プラグインをサポートし、トークンをプレーンテキストで TiDB に送信する必要があります。そのため、 `tidb_auth_token`使用する前に[クライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md)実行する必要があります。 +> - `tidb_auth_token`認証方法では、クライアントが[`mysql_clear_password`](https://dev.mysql.com/doc/refman/8.0/en/cleartext-pluggable-authentication.html)プラグインをサポートし、トークンをプレーンテキストで TiDB に送信する必要があります。そのため、 `tidb_auth_token`使用する前に[クライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md)を実行する必要があります。 #### 使用法 {#usage} @@ -249,7 +249,7 @@ TiDB Self-Managed ユーザーの認証方法として`tidb_auth_token`設定し mycli -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p '' ``` - ここで紹介するMySQLクライアントが`mysql_clear_password`プラグインをサポートしていることを確認してください。3 [mycli](https://www.mycli.net/)デフォルトでこのプラグインをサポートし、有効化します。5 [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)使用している場合は、 `--enable-cleartext-plugin`オプションを使用してこのプラグインを有効化する必要があります。 + ここで紹介するMySQLクライアントが`mysql_clear_password`プラグインをサポートしていることを確認してください。3 [mycli](https://www.mycli.net/)デフォルトでこのプラグインをサポートし、有効化します。5 [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)を使用している場合は、 `--enable-cleartext-plugin`オプションを使用してこのプラグインを有効化する必要があります。 ```Shell mysql -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p'' --enable-cleartext-plugin diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index e7fbd8f9c49f5..3a792554ff6a2 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -28,7 +28,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 > **警告：** > -> `_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)を参照してください。 > **注記：** > @@ -39,13 +39,13 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 -使用方法の詳細については、 [ホットスポットの問題のトラブルシューティングガイド](/troubleshoot-hot-spot-issues.md#use-shard_row_id_bits-to-process-hotspots)参照してください。 +使用方法の詳細については、 [ホットスポットの問題のトラブルシューティングガイド](/troubleshoot-hot-spot-issues.md#use-shard_row_id_bits-to-process-hotspots)を参照してください。 -使用方法の詳細については、 [ホットスポットの問題のトラブルシューティングガイド](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#use-shard_row_id_bits-to-process-hotspots)参照してください。 +使用方法の詳細については、 [ホットスポットの問題のトラブルシューティングガイド](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#use-shard_row_id_bits-to-process-hotspots)を参照してください。 diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index 6f135ae66cb90..2bc4199f59833 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -18,7 +18,7 @@ Starting from v7.1.0, when you upgrade TiDB to a later version, TiDB supports sm - Upgrade from v7.1.1 to v7.2.0 or v7.3.0 - Upgrade from v7.2.0 to v7.3.0 -- この機能はデフォルトで無効になっていますが、 `/upgrade/start`リクエストを送信することで有効にできます。詳細は[TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)参照してください。サポートされているバージョンは次のとおりです。 +- この機能はデフォルトで無効になっていますが、 `/upgrade/start`リクエストを送信することで有効にできます。詳細は[TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)を参照してください。サポートされているバージョンは次のとおりです。 - Upgrade from v7.1.2 and later v7.1 versions (that is, v7.1.x, where x >= 2) to v7.4.0 and later versions - Upgrade from v7.4.0 to later versions diff --git a/sql-non-prepared-plan-cache.md b/sql-non-prepared-plan-cache.md index a9f01d20efeef..14885c981bc12 100644 --- a/sql-non-prepared-plan-cache.md +++ b/sql-non-prepared-plan-cache.md @@ -20,7 +20,7 @@ TiDBは、 [ステートメント`Prepare` / `Execute`](/sql-prepared-plan-cache ## 使用法 {#usage} -非プリペアドプランのキャッシュを有効または無効にするには、システム変数[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)を設定します。また、システム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)使用して、非プリペアドプランのキャッシュのサイズを制御することもできます。キャッシュされたプランの数が`tidb_session_plan_cache_size`を超えると、TiDB は LRU (Least Recently Used) 戦略を使用してプランを削除します。 +非プリペアドプランのキャッシュを有効または無効にするには、システム変数[`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache)を設定します。また、システム変数[`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710)を使用して、非プリペアドプランのキャッシュのサイズを制御することもできます。キャッシュされたプランの数が`tidb_session_plan_cache_size`を超えると、TiDB は LRU (Least Recently Used) 戦略を使用してプランを削除します。 バージョン7.1.0以降では、システム変数[`tidb_plan_cache_max_plan_size`](/system-variables.md#tidb_plan_cache_max_plan_size-new-in-v710)を使用して、キャッシュできるプランの最大サイズを制御できます。デフォルト値は2 MBです。プランのサイズがこの値を超える場合、プランはキャッシュされません。 diff --git a/sql-optimization-concepts.md b/sql-optimization-concepts.md index fa0f4ea26eb4b..1a8add0900da7 100644 --- a/sql-optimization-concepts.md +++ b/sql-optimization-concepts.md @@ -9,8 +9,8 @@ TiDB では、クエリを入力してから最終実行プランに従って実 ![SQL Optimization Process](/media/sql-optimization.png) -TiDBは、元のクエリテキストを`parser`で解析し、簡単な妥当性チェックを行った後、まずクエリに論理的に同等の変更を加えます。詳細な変更については、 [SQL論理最適化](/sql-logical-optimization.md)参照してください。 +TiDBは、元のクエリテキストを`parser`で解析し、簡単な妥当性チェックを行った後、まずクエリに論理的に同等の変更を加えます。詳細な変更については、 [SQL論理最適化](/sql-logical-optimization.md)を参照してください。 -これらの等価変更により、このクエリは論理実行プランで処理しやすくなります。等価変更が完了すると、TiDBは元のクエリと等価なクエリプラン構造を取得し、その後、データ分布と演算子の具体的な実行コストに基づいて最終的な実行プランを取得します。詳細については、 [SQL物理最適化](/sql-physical-optimization.md)参照してください。 +これらの等価変更により、このクエリは論理実行プランで処理しやすくなります。等価変更が完了すると、TiDBは元のクエリと等価なクエリプラン構造を取得し、その後、データ分布と演算子の具体的な実行コストに基づいて最終的な実行プランを取得します。詳細については、 [SQL物理最適化](/sql-physical-optimization.md)を参照してください。 -同時に、TiDBが[`PREPARE`](/sql-statements/sql-statement-prepare.md)ステートメントを実行する際に、キャッシュを有効にするかどうかを選択できます。これにより、TiDBでの実行計画生成のコストを削減できます。詳細については、 [実行プランキャッシュ](/sql-prepared-plan-cache.md)参照してください。 +同時に、TiDBが[`PREPARE`](/sql-statements/sql-statement-prepare.md)ステートメントを実行する際に、キャッシュを有効にするかどうかを選択できます。これにより、TiDBでの実行計画生成のコストを削減できます。詳細については、 [実行プランキャッシュ](/sql-prepared-plan-cache.md)を参照してください。 diff --git a/sql-plan-management.md b/sql-plan-management.md index 4cb6bcb00aff4..483b7f860e15a 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -15,7 +15,7 @@ SQLバインディングはSPMの基盤です。1 [オプティマイザヒン > **注記：** > -> SQLバインディングを使用するには、 `SUPER`権限が必要です。TiDB から権限が不足しているというメッセージが表示された場合は、 [権限管理](/privilege-management.md)参照して必要な権限を追加してください。 +> SQLバインディングを使用するには、 `SUPER`権限が必要です。TiDB から権限が不足しているというメッセージが表示された場合は、 [権限管理](/privilege-management.md)を参照して必要な権限を追加してください。 @@ -23,7 +23,7 @@ SQLバインディングはSPMの基盤です。1 [オプティマイザヒン > **注記：** > -> SQLバインディングを使用するには、 `SUPER`権限が必要です。TiDB から権限が不足しているというメッセージが表示された場合は、 [権限管理](https://docs.pingcap.com/tidb/stable/privilege-management)参照して必要な権限を追加してください。 +> SQLバインディングを使用するには、 `SUPER`権限が必要です。TiDB から権限が不足しているというメッセージが表示された場合は、 [権限管理](https://docs.pingcap.com/tidb/stable/privilege-management)を参照して必要な権限を追加してください。 @@ -222,7 +222,7 @@ explain SELECT * FROM t1, t2 WHERE t1.id = t2.id; #### 履歴実行プランに従ってバインディングを作成する {#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)参照してください。 +SQL文の実行計画を過去の実行計画に固定するには、Plan Digestを使用して過去の実行計画をSQL文にバインドします。これは、SQL文ごとにバインドするよりも便利です。さらに、複数のSQL文の実行計画を一度にバインドすることも可能です。詳細と例については、 [`CREATE [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-create-binding.md)を参照してください。 この機能を使用する場合、次の点に注意してください。 @@ -328,7 +328,7 @@ explain SELECT * FROM t1,t2 WHERE t1.id = t2.id; #### SQLダイジェストに従ってバインディングを削除する {#remove-a-binding-according-to-sql-digest} -SQL文に従ってバインドを削除するだけでなく、SQLダイジェストに従ってバインドを削除することもできます。詳細と例については、 [`DROP [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-drop-binding.md)参照してください。 +SQL文に従ってバインドを削除するだけでなく、SQLダイジェストに従ってバインドを削除することもできます。詳細と例については、 [`DROP [GLOBAL|SESSION] BINDING`](/sql-statements/sql-statement-drop-binding.md)を参照してください。 ```sql DROP [GLOBAL | SESSION] BINDING FOR SQL DIGEST StringLiteralOrUserVariableList; @@ -388,7 +388,7 @@ SHOW [GLOBAL | SESSION] BINDINGS [ShowLikeOrWhere] バインディングのトラブルシューティングには、次のいずれかの方法を使用できます。 -- 最後に実行されたステートメントで使用された実行プランがバインディングからのものであるかどうかを表示するには、システム変数[`last_plan_from_binding`](/system-variables.md#last_plan_from_binding-new-in-v40)使用します。 +- 最後に実行されたステートメントで使用された実行プランがバインディングからのものであるかどうかを表示するには、システム変数[`last_plan_from_binding`](/system-variables.md#last_plan_from_binding-new-in-v40)を使用します。 ```sql -- Create a global binding diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index c746c756b5970..f749bdd8bbb7e 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -71,7 +71,7 @@ MySQL [test]> plan replayer dump explain select * from t; 1 row in set (0.015 sec) ``` -あるいは、セッション変数[`tidb_last_plan_replayer_token`](/system-variables.md#tidb_last_plan_replayer_token-new-in-v630)使用して、最後の`PLAN REPLAYER DUMP`実行の結果を取得することもできます。 +あるいは、セッション変数[`tidb_last_plan_replayer_token`](/system-variables.md#tidb_last_plan_replayer_token-new-in-v630)を使用して、最後の`PLAN REPLAYER DUMP`実行の結果を取得することもできます。 ```sql SELECT @@tidb_last_plan_replayer_token; diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index ca01408c77a8b..2e9e2269585c4 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -62,9 +62,9 @@ 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)参照してください。 +> [`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); @@ -189,7 +189,7 @@ LIMIT 10; -プリペアドプランキャッシュを使用すると、メモリオーバーヘッドが発生します。各TiDBインスタンス内の全セッションのキャッシュされた実行プランによるメモリ消費量の合計を表示するには、Grafanaの[**プランキャッシュメモリ使用**量監視パネル](/grafana-tidb-dashboard.md)使用します。 +プリペアドプランキャッシュを使用すると、メモリオーバーヘッドが発生します。各TiDBインスタンス内の全セッションのキャッシュされた実行プランによるメモリ消費量の合計を表示するには、Grafanaの[**プランキャッシュメモリ使用**量監視パネル](/grafana-tidb-dashboard.md)を使用します。 > **注記：** > diff --git a/sql-statements/sql-statement-add-index.md b/sql-statements/sql-statement-add-index.md index f76d367a0fe9e..e1fc9d59b3eb1 100644 --- a/sql-statements/sql-statement-add-index.md +++ b/sql-statements/sql-statement-add-index.md @@ -9,7 +9,7 @@ summary: TiDBデータベースにおけるADD INDEXの使用方法の概要。 > **ヒント：** > -> [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)使用すると、このステートメントの操作を高速化できます。 +> [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を使用すると、このステートメントの操作を高速化できます。 diff --git a/sql-statements/sql-statement-admin-alter-ddl.md b/sql-statements/sql-statement-admin-alter-ddl.md index d5d889192ed4e..81f3f6226682a 100644 --- a/sql-statements/sql-statement-admin-alter-ddl.md +++ b/sql-statements/sql-statement-admin-alter-ddl.md @@ -15,7 +15,7 @@ summary: TiDBデータベースにおけるADMIN ALTER DDL JOBS`の使用方法 ADMIN ALTER DDL JOBS 101 THREAD = 8; ``` -- `101` : DDL ジョブの ID を示します。この ID は、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)実行することで取得できます。 +- `101` : DDL ジョブの ID を示します。この ID は、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)を実行することで取得できます。 - `THREAD` : DDL ジョブの同時実行数を示します。システム変数[`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt)を使用して初期値を構成できます。 `ADMIN ALTER DDL JOBS`ステートメントでサポートされている DDL ジョブ タイプには、 `ADD INDEX` 、 `MODIFY COLUMN` 、および`REORGANIZE PARTITION`が含まれます。その他の DDL ジョブ タイプの場合、 `ADMIN ALTER DDL JOBS`を実行すると`unsupported DDL operation`エラーが返されます。 diff --git a/sql-statements/sql-statement-admin-bdr-role.md b/sql-statements/sql-statement-admin-bdr-role.md index d351c3e6ae370..2becac4e1365e 100644 --- a/sql-statements/sql-statement-admin-bdr-role.md +++ b/sql-statements/sql-statement-admin-bdr-role.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ADMIN [SET|SHOW|UNSET] BDR ROLE の使用法 # ADMIN [SET|SHOW|UNSET] BDR ROLE {#admin-set-show-unset-bdr-role} -- クラスターのBDRロールを設定するには、 `ADMIN SET BDR ROLE`使用します。現在、TiDBクラスターには`PRIMARY`と`SECONDARY` BDRロールを設定できます。BDRロールの詳細については、 [TiCDC 双方向レプリケーションにおける DDL 同期](/ticdc/ticdc-bidirectional-replication.md#ddl-replication)参照してください。 +- クラスターのBDRロールを設定するには、 `ADMIN SET BDR ROLE`使用します。現在、TiDBクラスターには`PRIMARY`と`SECONDARY` BDRロールを設定できます。BDRロールの詳細については、 [TiCDC 双方向レプリケーションにおける DDL 同期](/ticdc/ticdc-bidirectional-replication.md#ddl-replication)を参照してください。 - クラスターの BDR ロールを表示するには、 `ADMIN SHOW BDR ROLE`使用します。 - クラスターの BDR ロールを設定解除するには、 `ADMIN UNSET BDR ROLE`使用します。 diff --git a/sql-statements/sql-statement-admin-cancel-ddl.md b/sql-statements/sql-statement-admin-cancel-ddl.md index 79d4ea26cfd43..2d0827f47efc0 100644 --- a/sql-statements/sql-statement-admin-cancel-ddl.md +++ b/sql-statements/sql-statement-admin-cancel-ddl.md @@ -6,7 +6,7 @@ category: reference # ADMIN CANCEL DDL {#admin-cancel-ddl} -`ADMIN CANCEL DDL`文は実行中のDDLジョブをキャンセルします。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)実行することで確認できます。 +`ADMIN CANCEL DDL`文は実行中のDDLジョブをキャンセルします。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)を実行することで確認できます。 `ADMIN CANCEL DDL`文を使用すると、コミットされているもののまだ実行が完了していないDDLジョブをキャンセルすることもできます。キャンセル後、DDLジョブを実行するSQL文は`ERROR 8214 (HY000): Cancelled DDL job`エラーを返します。すでに完了しているDDLジョブをキャンセルした場合は、 `RESULT`列に`DDL Job:90 not found`エラーが表示されます。これは、ジョブがDDL待機キューから削除されたことを示します。 diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index c4aa08b6ebed1..dfe25c7e19a4e 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -20,7 +20,7 @@ category: reference [チェックサム](https://docs.pingcap.com/tidb/stable/tidb-lightning-glossary#checksum)テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 -[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
`実行されます。 diff --git a/sql-statements/sql-statement-admin-pause-ddl.md b/sql-statements/sql-statement-admin-pause-ddl.md index 95c1f09adead3..4b81ca14eb1f2 100644 --- a/sql-statements/sql-statement-admin-pause-ddl.md +++ b/sql-statements/sql-statement-admin-pause-ddl.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ADMIN PAUSE DDL JOBS の使用法の概要 # ADMIN PAUSE DDL JOBS {#admin-pause-ddl-jobs} -`ADMIN PAUSE DDL`は実行中のDDLジョブを一時停止します。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)実行することで確認できます。 +`ADMIN PAUSE DDL`は実行中のDDLジョブを一時停止します。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)を実行することで確認できます。 この文を使用すると、発行済みだがまだ実行が完了していないDDLジョブを一時停止できます。一時停止後、DDLジョブを実行するSQL文はすぐには戻りませんが、まだ実行中であるように見えます。すでに完了しているDDLジョブを一時停止しようとすると、列`RESULT`にエラー`DDL Job:90 not found`表示されます。これは、ジョブがDDL待機キューから削除されたことを示します。 diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md index 2bf17694b63fe..1d5a6f8613cbf 100644 --- a/sql-statements/sql-statement-admin-resume-ddl.md +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ADMIN RESUME DDL の使用法の概要。 # ADMIN RESUME DDL JOBS {#admin-resume-ddl-jobs} -`ADMIN RESUME DDL`使用すると、一時停止中のDDLジョブを再開できます。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)実行すると確認できます。 +`ADMIN RESUME DDL`使用すると、一時停止中のDDLジョブを再開できます。`job_id` [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)を実行すると確認できます。 このステートメントを使用すると、一時停止中のDDLジョブを再開できます。再開が完了した後も、DDLジョブを実行するSQL文は実行中として表示されます。すでに完了しているDDLジョブを再開しようとすると、列`RESULT`にエラー`DDL Job:90 not found`が表示されます。これは、ジョブがDDL待機キューから削除されたことを示します。 diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 742ed21e6f504..4cd81107c1aa9 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -32,7 +32,7 @@ WhereClauseOptional ::= 現在実行中のDDLジョブのステータスを表示するには、 `ADMIN SHOW DDL`使用します。出力には、現在のスキーマバージョン、DDL IDと所有者のアドレス、実行中のDDLジョブとSQL文、現在のTiDBインスタンスのDDL IDが含まれます。返される結果フィールドは以下のとおりです。 - `SCHEMA_VER` : スキーマのバージョンを示す数値。 -- `OWNER_ID` : DDL所有者のUUID。2 [`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)参照してください。 +- `OWNER_ID` : DDL所有者のUUID。2 [`TIDB_IS_DDL_OWNER()`](/functions-and-operators/tidb-functions.md)を参照してください。 - `OWNER_ADDRESS` : DDL 所有者の IP アドレス。 - `RUNNING_JOBS` : 実行中の DDL ジョブの詳細。 - `SELF_ID` : 現在接続しているTiDBノードのUUID。2 `SELF_ID` `OWNER_ID`と同じ場合は、DDL所有者に接続していることを意味します。 @@ -69,7 +69,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `add index` : [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)操作の場合。 - `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 - `none` : 存在しないことを示します。通常、 `DROP`操作の後、または`CREATE`操作が失敗してロールバックした後、 `none`番目の状態になります。 - - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 + - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 - `SCHEMA_ID` : DDL 操作が実行されるデータベースの ID。 - `TABLE_ID` : DDL 操作が実行されるテーブルの ID。 @@ -95,7 +95,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `txn-merge` : バックフィルが完了すると元のインデックスとマージされる一時インデックスを使用したトランザクション バックフィル。 - `DXF` : [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)で構成された Distributed eXecution Framework (DXF) を使用して実行されるタスク。 - `service_scope` : [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)で設定された TiDB ノードのサービス スコープ。 - - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。4 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)指定することで動的な変更が可能です。 + - `thread` : バックフィルタスクの同時実行数。初期値は`tidb_ddl_reorg_worker_cnt`に設定できます。4 [`ADMIN ALTER DDL JOBS`](/sql-statements/sql-statement-admin-alter-ddl.md)を指定することで動的な変更が可能です。 - `batch_size` : バックフィルタスクのバッチサイズ。初期値は`tidb_ddl_reorg_batch_size`に設定できます。4 `ADMIN ALTER DDL JOBS`指定することで動的な変更が可能です。 - `max_write_speed` : インジェストタスクのインポート時のフロー制御。初期値は`tidb_ddl_reorg_max_write_speed`に設定できます。4 による動的な変更`ADMIN ALTER DDL JOBS`サポートされます。 @@ -109,7 +109,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `JOB_TYPE` : DDL 操作のタイプ。 - `SCHEMA_STATE` : DDLが操作するスキーマオブジェクトの現在の状態。2 が`JOB_TYPE` `ADD INDEX`場合はインデックスの状態、 `JOB_TYPE`が`ADD COLUMN`の場合は列の状態、 `JOB_TYPE`が`CREATE TABLE`の場合はテーブルの状態です。一般的な状態には以下が含まれます。 - `none` : 存在しないことを示します。通常、 `DROP`操作の後、または`CREATE`操作が失敗してロールバックした後、 `none`番目の状態になります。 - - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](https://docs.pingcap.com/tidb/stable/ddl-introduction#how-the-online-ddl-asynchronous-change-works-in-tidb)参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 + - `delete only` `write reorganization`これらの4つの状態は中間状態です。それぞれの具体的な意味については、 [TiDBにおけるオンラインDDL非同期変更の仕組み](https://docs.pingcap.com/tidb/stable/ddl-introduction#how-the-online-ddl-asynchronous-change-works-in-tidb)を参照してください。中間状態の変換`delete reorganization`高速であるため、これらの状態は通常`write only`演算中は表示されません。10 `ADD INDEX`演算を実行する場合にのみ、 `write reorganization`状態が表示され、インデックスデータが追加されていることを示します。 - `public` : 存在し、ユーザーが利用できることを示します。通常、 `CREATE TABLE`と`ADD INDEX` （または`ADD COLUMN` ）の操作が完了すると、状態は`public`になり、新しく作成されたテーブル、列、およびインデックスが正常に読み書きできることを示します。 - `SCHEMA_ID` : DDL 操作が実行されるデータベースの ID。 - `TABLE_ID` : DDL 操作が実行されるテーブルの ID。 diff --git a/sql-statements/sql-statement-alter-database.md b/sql-statements/sql-statement-alter-database.md index cfd919446532d..d4a5084f99699 100644 --- a/sql-statements/sql-statement-alter-database.md +++ b/sql-statements/sql-statement-alter-database.md @@ -33,7 +33,7 @@ Query OK, 0 rows affected (0.00 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`ALTER DATABASE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`ALTER DATABASE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-alter-resource-group.md b/sql-statements/sql-statement-alter-resource-group.md index 32d3ff750e8f8..faf38988cc8a7 100644 --- a/sql-statements/sql-statement-alter-resource-group.md +++ b/sql-statements/sql-statement-alter-resource-group.md @@ -85,8 +85,8 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで | `RU_PER_SEC` | RUのバックフィル速度（1秒あたり） | `RU_PER_SEC = 500`は、このリソースグループが毎秒500 RUでバックフィルされていることを示します。 | | `PRIORITY` | TiKVで処理されるタスクの絶対的な優先順位 | `PRIORITY = HIGH`は優先度が高いことを示します。指定しない場合、デフォルト値は`MEDIUM`です。 | | `BURSTABLE` | `BURSTABLE`属性が設定されている場合、TiDBは、割り当て量を超過したときに、対応するリソースグループが利用可能なシステムリソースを使用することを許可します。 | | -| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60 秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10 分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)参照してください。 | -| `BACKGROUND` | バックグラウンドタスクを設定します。詳細については、 [バックグラウンドタスクの管理](/tidb-resource-control-background-tasks.md)参照してください。 | `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)`は、バックアップと復元、統計情報の収集に関連するタスクがバックグラウンドタスクとしてスケジュールされ、バックグラウンドタスクはTiKVリソースの最大30%を消費できることを示しています。 | +| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60 秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10 分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 | +| `BACKGROUND` | バックグラウンドタスクを設定します。詳細については、 [バックグラウンドタスクの管理](/tidb-resource-control-background-tasks.md)を参照してください。 | `BACKGROUND=(TASK_TYPES="br,stats", UTILIZATION_LIMIT=30)`は、バックアップと復元、統計情報の収集に関連するタスクがバックグラウンドタスクとしてスケジュールされ、バックグラウンドタスクはTiKVリソースの最大30%を消費できることを示しています。 | > **注記：** > diff --git a/sql-statements/sql-statement-alter-table.md b/sql-statements/sql-statement-alter-table.md index a2dea678f684a..a9ca166c2d210 100644 --- a/sql-statements/sql-statement-alter-table.md +++ b/sql-statements/sql-statement-alter-table.md @@ -174,9 +174,9 @@ TiDB の`ALTER TABLE`には次の主な制限が適用されます。 - 空間データ型はサポートされていません。 -- `ALTER TABLE t CACHE | NOCACHE`はMySQL構文に対するTiDB拡張です。詳細については[キャッシュされたテーブル](/cached-tables.md)参照してください。 +- `ALTER TABLE t CACHE | NOCACHE`はMySQL構文に対するTiDB拡張です。詳細については[キャッシュされたテーブル](/cached-tables.md)を参照してください。 -詳細な制限については[MySQLの互換性](/mysql-compatibility.md#ddl-operations)参照してください。 +詳細な制限については[MySQLの互換性](/mysql-compatibility.md#ddl-operations)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-analyze-table.md b/sql-statements/sql-statement-analyze-table.md index 2421bbbc05d64..cbe4c8f3a05ed 100644 --- a/sql-statements/sql-statement-analyze-table.md +++ b/sql-statements/sql-statement-analyze-table.md @@ -9,7 +9,7 @@ summary: TiDB データベースに対する ANALYZE の使用法の概要。 TiDB は、統計が自身の推定値と一致していないことが判明すると、時間の経過とともに統計を自動的に更新します。 -現在、TiDBは`ANALYZE TABLE`文を使用して完全なコレクションとして統計情報を収集します。詳細については、 [統計学入門](/statistics.md)参照してください。 +現在、TiDBは`ANALYZE TABLE`文を使用して完全なコレクションとして統計情報を収集します。詳細については、 [統計学入門](/statistics.md)を参照してください。 ## 概要 {#synopsis} @@ -96,7 +96,7 @@ mysql> EXPLAIN SELECT * FROM t1 WHERE c1 = 3; TiDBは、収集する統計情報と、クエリ実行時に統計情報を利用する方法の**両方**においてMySQLとは異なります。この文は構文的にはMySQLに似ていますが、以下の違いがあります。 -- TiDBは、 `ANALYZE TABLE`実行時に、ごく最近コミットされた変更を反映させない可能性があります。行のバッチ更新後、統計情報の更新にこれらの変更を反映させるには、 `ANALYZE TABLE`実行する前に`sleep(1)`実行する必要がある場合があります[＃16570](https://github.com/pingcap/tidb/issues/16570)参照してください。 +- TiDBは、 `ANALYZE TABLE`実行時に、ごく最近コミットされた変更を反映させない可能性があります。行のバッチ更新後、統計情報の更新にこれらの変更を反映させるには、 `ANALYZE TABLE`実行する前に`sleep(1)`実行する必要がある場合があります[＃16570](https://github.com/pingcap/tidb/issues/16570)を参照してください。 - `ANALYZE TABLE` 、MySQL よりも TiDB で実行するのに大幅に時間がかかります。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-batch.md b/sql-statements/sql-statement-batch.md index 43df6bde9f9a2..e3d23b0b60f5c 100644 --- a/sql-statements/sql-statement-batch.md +++ b/sql-statements/sql-statement-batch.md @@ -11,7 +11,7 @@ summary: TiDB データベースにおける BATCH の使用法の概要。 `BATCH`構文は、列に基づいてDML文を複数の実行範囲に分割します。各範囲では、1つのSQL文が実行されます。 -使用方法および制限事項の詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)参照してください。 +使用方法および制限事項の詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)を参照してください。 `BATCH`ステートメントで複数テーブルの結合を使用する場合は、あいまいさを避けるために列の完全なパスを指定する必要があります。 @@ -29,7 +29,7 @@ Non-transactional DML, shard column must be fully specified > **注記：** > -> `BATCH`文は実行時に内部的に書き換えられ、複数のDML文に分割されます。現在のバージョンでは、テーブルエイリアスが保持されない可能性があり、 `Unknown column '.' in 'where clause'`のようなエラーが発生する可能性があります。この問題を回避するには、テーブルエイリアスを使用しないでください。実行前に、 `DRY RUN QUERY`または`DRY RUN`を使用して分割文をプレビューしてください。詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)参照してください。 +> `BATCH`文は実行時に内部的に書き換えられ、複数のDML文に分割されます。現在のバージョンでは、テーブルエイリアスが保持されない可能性があり、 `Unknown column '.' in 'where clause'`のようなエラーが発生する可能性があります。この問題を回避するには、テーブルエイリアスを使用しないでください。実行前に、 `DRY RUN QUERY`または`DRY RUN`を使用して分割文をプレビューしてください。詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)を参照してください。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index b76b63b843e8e..e11b39eb75cb5 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -38,8 +38,8 @@ Query OK, 0 rows affected (0.01 sec) ## MySQLの互換性 {#mysql-compatibility} -- 現在、TiDBはメタデータロック（MDL）を使用して、DDL文によるトランザクションで使用されるテーブルの変更をデフォルトで防止しています。メタデータロックの動作はTiDBとMySQLで異なります。詳細については、 [メタデータロック](/metadata-lock.md)参照してください。 -- TiDB 3.0.8以降のバージョンでは、デフォルトで[悲観的ロック](/pessimistic-transaction.md)使用されます。 [楽観的ロック](/optimistic-transaction.md)使用する場合は、別のトランザクションによって行が変更されているために`COMMIT`ステートメントが失敗する可能性があることを考慮することが重要です。 +- 現在、TiDBはメタデータロック（MDL）を使用して、DDL文によるトランザクションで使用されるテーブルの変更をデフォルトで防止しています。メタデータロックの動作はTiDBとMySQLで異なります。詳細については、 [メタデータロック](/metadata-lock.md)を参照してください。 +- TiDB 3.0.8以降のバージョンでは、デフォルトで[悲観的ロック](/pessimistic-transaction.md)使用されます。 [楽観的ロック](/optimistic-transaction.md)を使用する場合は、別のトランザクションによって行が変更されているために`COMMIT`ステートメントが失敗する可能性があることを考慮することが重要です。 - 楽観的ロックが有効な場合、制約`UNIQUE`と`PRIMARY KEY`チェックは文のコミットまで延期されます。これにより、制約`COMMIT`文が失敗する状況が増えます。この動作は`tidb_constraint_check_in_place=ON`設定することで変更できます。 - TiDBは構文`ROLLBACK AND [NO] RELEASE`を解析しますが、無視します。この機能はMySQLでトランザクションのコミット直後にクライアントセッションを切断するために使用されます。TiDBでは、代わりにクライアントドライバの`mysql_close()`機能を使用することをお勧めします。 - TiDBは構文`ROLLBACK AND [NO] CHAIN`を解析しますが、無視します。この機能はMySQLで使用され、現在のトランザクションがコミットされている間に、同じ分離レベルで新しいトランザクションを即座に開始します。TiDBでは、代わりに新しいトランザクションを開始することが推奨されます。 diff --git a/sql-statements/sql-statement-create-binding.md b/sql-statements/sql-statement-create-binding.md index ad590f98be976..4feeea2eb25ca 100644 --- a/sql-statements/sql-statement-create-binding.md +++ b/sql-statements/sql-statement-create-binding.md @@ -9,7 +9,7 @@ summary: TiDB データベースでの CREATE BINDING の使用。 `BINDING` `GLOBAL`または`SESSION`基準で表されます。デフォルトは`SESSION`です。 -バインドされたSQL文はパラメータ化され、システムテーブルに格納されます。SQLクエリが処理される際、パラメータ化されたSQL文とシステムテーブル内のバインドされたSQL文が一致し、システム変数`tidb_use_plan_baselines`が`ON` （デフォルト）に設定されている限り、対応するオプティマイザヒントが利用可能です。複数の実行プランが利用可能な場合、オプティマイザは最もコストの低いプランをバインドします。詳細については、 [バインディングを作成する](/sql-plan-management.md#create-a-binding)参照してください。 +バインドされたSQL文はパラメータ化され、システムテーブルに格納されます。SQLクエリが処理される際、パラメータ化されたSQL文とシステムテーブル内のバインドされたSQL文が一致し、システム変数`tidb_use_plan_baselines`が`ON` （デフォルト）に設定されている限り、対応するオプティマイザヒントが利用可能です。複数の実行プランが利用可能な場合、オプティマイザは最もコストの低いプランをバインドします。詳細については、 [バインディングを作成する](/sql-plan-management.md#create-a-binding)を参照してください。 ## 概要 {#synopsis} diff --git a/sql-statements/sql-statement-create-database.md b/sql-statements/sql-statement-create-database.md index 49f131e5c9015..5438b1ed18dd9 100644 --- a/sql-statements/sql-statement-create-database.md +++ b/sql-statements/sql-statement-create-database.md @@ -49,7 +49,7 @@ create_specification: 既存のデータベースを作成し、 `IF NOT EXISTS`指定しないと、エラーが表示されます。 -`create_specification`オプションは、データベース内の特定の`CHARACTER SET`と`COLLATE`指定するために使用されます。現在、TiDB は一部の文字セットと照合順序のみをサポートしています。詳細については、 [文字セットと照合順序のサポート](/character-set-and-collation.md)参照してください。 +`create_specification`オプションは、データベース内の特定の`CHARACTER SET`と`COLLATE`指定するために使用されます。現在、TiDB は一部の文字セットと照合順序のみをサポートしています。詳細については、 [文字セットと照合順序のサポート](/character-set-and-collation.md)を参照してください。 ## 例 {#examples} @@ -73,7 +73,7 @@ mysql> SHOW TABLES; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`CREATE DATABASE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`CREATE DATABASE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index bfefd1c737fb5..9525087a6ac9a 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -507,7 +507,7 @@ CREATE UNIQUE INDEX c1 ON t1 (c1) INVISIBLE; TiDB v8.0.0以降では、システム変数[`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800)変更することで、オプティマイザに不可視インデックスを選択させることができます。 -詳細については、 [`ALTER INDEX`](/sql-statements/sql-statement-alter-index.md)参照してください。 +詳細については、 [`ALTER INDEX`](/sql-statements/sql-statement-alter-index.md)を参照してください。 ## 関連するシステム変数 {#associated-system-variables} @@ -531,7 +531,7 @@ TiDB v8.0.0以降では、システム変数[`tidb_opt_use_invisible_indexes`](/ - 式インデックスはバインディングとの互換性に問題があります。式インデックスの式に定数が含まれている場合、対応するクエリ用に作成されるバインディングのスコープが拡張されます。たとえば、式インデックスの式が`a+1`で、対応するクエリ条件が`a+1 > 2`であるとします。この場合、作成されるバインディングは`a+? > ?`となり、 `a+2 > 2`のような条件を持つクエリも式インデックスの使用を強制され、実行プランが最適化されません。さらに、これは SQL プラン管理 (SPM) におけるベースラインのキャプチャとベースラインの進化にも影響します。 -- 多値インデックスを使用して書き込まれるデータは、定義されたデータ型と正確に一致する必要があります。そうしないと、データの書き込みは失敗します。詳細については、 [多値インデックスを作成する](/sql-statements/sql-statement-create-index.md#create-multi-valued-indexes)参照してください。 +- 多値インデックスを使用して書き込まれるデータは、定義されたデータ型と正確に一致する必要があります。そうしないと、データの書き込みは失敗します。詳細については、 [多値インデックスを作成する](/sql-statements/sql-statement-create-index.md#create-multi-valued-indexes)を参照してください。 - `UNIQUE KEY`インデックス オプションを使用して、 `GLOBAL`を[グローバルインデックス](/global-indexes.md)として設定することは[パーティション化されたテーブル](/partitioned-table.md)の TiDB 拡張機能であり、MySQL とは互換性がありません。 diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md index 53a9a8f556071..7dab60c2ad5dd 100644 --- a/sql-statements/sql-statement-create-resource-group.md +++ b/sql-statements/sql-statement-create-resource-group.md @@ -82,7 +82,7 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで | `RU_PER_SEC` | RUのバックフィル速度（1秒あたり） | `RU_PER_SEC = 500`は、このリソースグループが毎秒500 RUでバックフィルされていることを示します。 | | `PRIORITY` | TiKVで処理されるタスクの絶対的な優先順位 | `PRIORITY = HIGH`は優先度が高いことを示します。指定しない場合、デフォルト値は`MEDIUM`です。 | | `BURSTABLE` | `BURSTABLE`属性が設定されている場合、TiDBは、割り当て量を超過したときに、対応するリソースグループが利用可能なシステムリソースを使用することを許可します。 | | -| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60 秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10 分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)参照してください。 | +| `QUERY_LIMIT` | クエリの実行がこの条件を満たした場合、そのクエリは暴走クエリとして識別され、対応するアクションが実行されます。 | `QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=EXACT DURATION='10m')`は、実行時間が 60 秒を超えた場合にクエリが暴走クエリとして識別されたことを示します。クエリは終了されます。同じ SQL テキストを持つすべての SQL ステートメントは、今後 10 分以内に直ちに終了します。 `QUERY_LIMIT=()`または`QUERY_LIMIT=NULL`は、暴走制御が有効になっていないことを意味します。 [暴走クエリ](/tidb-resource-control-runaway-queries.md)を参照してください。 | > **注記：** > diff --git a/sql-statements/sql-statement-create-role.md b/sql-statements/sql-statement-create-role.md index 8164cff23d05b..c2f06053144db 100644 --- a/sql-statements/sql-statement-create-role.md +++ b/sql-statements/sql-statement-create-role.md @@ -129,7 +129,7 @@ SHOW TABLES IN test; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`CREATE ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`CREATE ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-create-table-like.md b/sql-statements/sql-statement-create-table-like.md index 1041000af1d4f..aa354d8dc9f0a 100644 --- a/sql-statements/sql-statement-create-table-like.md +++ b/sql-statements/sql-statement-create-table-like.md @@ -55,7 +55,7 @@ Empty set (0.00 sec) ## 分割前のリージョン {#pre-split-region} -コピー元のテーブルに`PRE_SPLIT_REGIONS`属性が定義されている場合、 `CREATE TABLE LIKE`文で作成されたテーブルはこの属性を継承し、新しいテーブルのリージョンは分割されます。詳細については、 `PRE_SPLIT_REGIONS` [CREATE TABLE](/sql-statements/sql-statement-create-table.md)参照してください。 +コピー元のテーブルに`PRE_SPLIT_REGIONS`属性が定義されている場合、 `CREATE TABLE LIKE`文で作成されたテーブルはこの属性を継承し、新しいテーブルのリージョンは分割されます。詳細については、 `PRE_SPLIT_REGIONS` [CREATE TABLE](/sql-statements/sql-statement-create-table.md)を参照してください。 ## MySQLの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md index 7171c8e6899cc..891ee7328d76e 100644 --- a/sql-statements/sql-statement-create-table.md +++ b/sql-statements/sql-statement-create-table.md @@ -177,7 +177,7 @@ NextValueForSequence ::= > **注記：** > -> - `split-table`設定オプションはデフォルトで有効になっています。このオプションを有効にすると、新しく作成されるテーブルごとに個別のリージョンが作成されます。詳細は、 [TiDB設定ファイル](/tidb-configuration-file.md)参照してください。 +> - `split-table`設定オプションはデフォルトで有効になっています。このオプションを有効にすると、新しく作成されるテーブルごとに個別のリージョンが作成されます。詳細は、 [TiDB設定ファイル](/tidb-configuration-file.md)を参照してください。 > - `AFFINITY`を使用する前に、アフィニティが有効になっているテーブルのパーティショニング スキームの変更 (パーティションの追加、削除、再編成、または交換など) はサポートされておらず、一時テーブルまたはビューで`AFFINITY`を構成することもサポートされていないことに注意してください。 @@ -283,7 +283,7 @@ mysql> DESC t1; -- 互換性のために、 `index_col_name`属性は、デフォルトで最大長3072バイトの長さオプションをサポートしています。長さの制限は`max-index-length`設定オプションで変更できます。詳細は、 [TiDB設定ファイル](/tidb-configuration-file.md#max-index-length)参照してください。 +- 互換性のために、 `index_col_name`属性は、デフォルトで最大長3072バイトの長さオプションをサポートしています。長さの制限は`max-index-length`設定オプションで変更できます。詳細は、 [TiDB設定ファイル](/tidb-configuration-file.md#max-index-length)を参照してください。 diff --git a/sql-statements/sql-statement-deallocate.md b/sql-statements/sql-statement-deallocate.md index ae0c76fb914f4..8ab3cf40534ac 100644 --- a/sql-statements/sql-statement-deallocate.md +++ b/sql-statements/sql-statement-deallocate.md @@ -47,7 +47,7 @@ Query OK, 0 rows affected (0.00 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DEALLOCATE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DEALLOCATE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-delete.md b/sql-statements/sql-statement-delete.md index 506fa79f8378d..e7ffa8c021db5 100644 --- a/sql-statements/sql-statement-delete.md +++ b/sql-statements/sql-statement-delete.md @@ -53,7 +53,7 @@ mysql> SELECT * FROM t1; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DELETE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DELETE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-do.md b/sql-statements/sql-statement-do.md index 2d468fea05512..48286e91b1c61 100644 --- a/sql-statements/sql-statement-do.md +++ b/sql-statements/sql-statement-do.md @@ -53,7 +53,7 @@ Query OK, 0 rows affected (2.50 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DO`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DO`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-drop-database.md b/sql-statements/sql-statement-drop-database.md index 0e6fefa724f2a..ae13195dbdd13 100644 --- a/sql-statements/sql-statement-drop-database.md +++ b/sql-statements/sql-statement-drop-database.md @@ -46,7 +46,7 @@ mysql> SHOW DATABASES; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DROP DATABASE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DROP DATABASE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-drop-role.md b/sql-statements/sql-statement-drop-role.md index 5639d9e99b2f1..b1aa6deea3fbb 100644 --- a/sql-statements/sql-statement-drop-role.md +++ b/sql-statements/sql-statement-drop-role.md @@ -162,7 +162,7 @@ ERROR 3530 (HY000): `analyticsteam`@`%` is is not granted to jennifer@% ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DROP ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DROP ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-drop-view.md b/sql-statements/sql-statement-drop-view.md index b7c7ee6dc7a7b..4e26f98c06dbf 100644 --- a/sql-statements/sql-statement-drop-view.md +++ b/sql-statements/sql-statement-drop-view.md @@ -73,7 +73,7 @@ mysql> SELECT * FROM t1; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`DROP VIEW`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`DROP VIEW`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-execute.md b/sql-statements/sql-statement-execute.md index 258de5b5133ea..866648a036e0f 100644 --- a/sql-statements/sql-statement-execute.md +++ b/sql-statements/sql-statement-execute.md @@ -37,7 +37,7 @@ Query OK, 0 rows affected (0.00 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`EXECUTE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`EXECUTE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-explain.md b/sql-statements/sql-statement-explain.md index c78d51472761e..458dcf0a47716 100644 --- a/sql-statements/sql-statement-explain.md +++ b/sql-statements/sql-statement-explain.md @@ -9,7 +9,7 @@ summary: TiDB データベースにおけるEXPLAINの使用法の概要。 > **注記：** > -> 最適化フェーズでは、 `EXPLAIN`文であっても、最適な実行プランを生成するために特定のサブクエリが事前実行されます。この動作の詳細と無効化方法については、 [`tidb_opt_enable_non_eval_scalar_subquery`](/system-variables.md#tidb_opt_enable_non_eval_scalar_subquery-new-in-v730)および[サブクエリの早期実行を無効にする](/explain-walkthrough.md#disable-the-early-execution-of-subqueries)参照してください。 +> 最適化フェーズでは、 `EXPLAIN`文であっても、最適な実行プランを生成するために特定のサブクエリが事前実行されます。この動作の詳細と無効化方法については、 [`tidb_opt_enable_non_eval_scalar_subquery`](/system-variables.md#tidb_opt_enable_non_eval_scalar_subquery-new-in-v730)および[サブクエリの早期実行を無効にする](/explain-walkthrough.md#disable-the-early-execution-of-subqueries)を参照してください。 `DESC`文と`DESCRIBE`文は`EXPLAIN`の別名です。文`EXPLAIN `の代替使用法については[`SHOW [FULL] COLUMNS FROM`](/sql-statements/sql-statement-show-columns-from.md)に記載されています。 @@ -179,9 +179,9 @@ EXPLAIN DELETE FROM t1 WHERE c1=3; | 指定されていない | 形式が指定されていない場合は、デフォルトの形式`EXPLAIN` `row`使用されます。 | | `brief` | `EXPLAIN`ステートメントの出力の演算子 ID は、 `FORMAT`指定されていない場合に比べて簡素化されます。 | | `dot` | `EXPLAIN`ステートメントは DOT 実行プランを出力します。これを使用して、 `dot`プログラム ( `graphviz`パッケージ内) を通じて PNG ファイルを生成することができます。 | -| `row` | `EXPLAIN`文は結果を表形式で出力します。詳細については[クエリ実行プランを理解する](/explain-overview.md)参照してください。 | +| `row` | `EXPLAIN`文は結果を表形式で出力します。詳細については[クエリ実行プランを理解する](/explain-overview.md)を参照してください。 | | `tidb_json` | `EXPLAIN`ステートメントは実行プランを JSON 形式で出力し、演算子情報を JSON 配列に格納します。 | -| `verbose` | `EXPLAIN`文は`row`形式で結果を出力し、さらに`estCost`列にクエリの推定コストが表示されます。この形式の使用方法の詳細については、 [SQLプラン管理](/sql-plan-management.md)参照してください。 | +| `verbose` | `EXPLAIN`文は`row`形式で結果を出力し、さらに`estCost`列にクエリの推定コストが表示されます。この形式の使用方法の詳細については、 [SQLプラン管理](/sql-plan-management.md)を参照してください。 | | `plan_cache` | `EXPLAIN`ステートメントは、 [プランキャッシュ](/sql-non-prepared-plan-cache.md#diagnostics)情報を警告として含めて、 `row`形式で結果を出力します。 | | `cost_trace` | `EXPLAIN`ステートメントは、推定コストの`estCost`とコストの計算式の`costFormula`列の 2 つの追加列を含む拡張`row`形式で結果を出力します。 | diff --git a/sql-statements/sql-statement-flashback-cluster.md b/sql-statements/sql-statement-flashback-cluster.md index 98363fa4ec0c1..1cf13ceac9a23 100644 --- a/sql-statements/sql-statement-flashback-cluster.md +++ b/sql-statements/sql-statement-flashback-cluster.md @@ -7,7 +7,7 @@ summary: TiDBデータベースにおけるFLASHBACK CLUSTERの使い方を学 TiDB v6.4.0 では`FLASHBACK CLUSTER TO TIMESTAMP`構文が導入されました。これを使用すると、クラスタを特定の時点に復元できます。タイムスタンプを指定する際には、datetime 値を設定するか、time 関数を使用できます。datetime の形式は、たとえば「2016-10-08 16:45:26.999」のようになります。最小時間単位はミリ秒です。ただし、ほとんどの場合、時間単位を秒としてタイムスタンプを指定するだけで十分です。たとえば、「2016-10-08 16:45:26」のように指定します。 -TiDBは、v6.5.6、v7.1.3、v7.5.1、v7.6.0以降で`FLASHBACK CLUSTER TO TSO`構文を導入しました。この構文を使用すると、 [TSO](/tso.md)使用してより正確なリカバリ時点を指定できるため、データリカバリの柔軟性が向上します。 +TiDBは、v6.5.6、v7.1.3、v7.5.1、v7.6.0以降で`FLASHBACK CLUSTER TO TSO`構文を導入しました。この構文を使用すると、 [TSO](/tso.md)を使用してより正確なリカバリ時点を指定できるため、データリカバリの柔軟性が向上します。 > **警告：** > diff --git a/sql-statements/sql-statement-flush-privileges.md b/sql-statements/sql-statement-flush-privileges.md index ea64f7164c29b..e93bcd9a6d17d 100644 --- a/sql-statements/sql-statement-flush-privileges.md +++ b/sql-statements/sql-statement-flush-privileges.md @@ -34,7 +34,7 @@ Query OK, 0 rows affected (0.01 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`FLUSH PRIVILEGES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`FLUSH PRIVILEGES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-flush-tables.md b/sql-statements/sql-statement-flush-tables.md index 0eb117ba79309..eaa971df2b938 100644 --- a/sql-statements/sql-statement-flush-tables.md +++ b/sql-statements/sql-statement-flush-tables.md @@ -51,7 +51,7 @@ ERROR 1105 (HY000): FLUSH TABLES WITH READ LOCK is not supported. Please use @@ ## MySQLの互換性 {#mysql-compatibility} - TiDBにはMySQLのようなテーブルキャッシュの概念がありません。そのため、 `FLUSH TABLES`解析されますが、互換性のためにTiDBでは無視されます。 -- ステートメント`FLUSH TABLES WITH READ LOCK`エラーを生成します。これは、TiDBが現在テーブルのロックをサポートしていないためです。この目的には、代わりに[歴史的な読み物](/read-historical-data.md)使用することをお勧めします。 +- ステートメント`FLUSH TABLES WITH READ LOCK`エラーを生成します。これは、TiDBが現在テーブルのロックをサポートしていないためです。この目的には、代わりに[歴史的な読み物](/read-historical-data.md)を使用することをお勧めします。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-grant-role.md b/sql-statements/sql-statement-grant-role.md index 22f481fb39109..5f54f8994ee5d 100644 --- a/sql-statements/sql-statement-grant-role.md +++ b/sql-statements/sql-statement-grant-role.md @@ -129,7 +129,7 @@ SHOW TABLES IN test; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`GRANT `文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`GRANT `文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 55a01714138bb..23ce2bc57e903 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の空き容量が必要です。インポートするデータ量と同等以上のストレージ容量を割り当てることをお勧めします。 @@ -156,7 +156,7 @@ OptionItem ::= | `MAX_WRITE_SPEED=''` | すべてのファイル形式 | TiKVノードへの書き込み速度を制御します。デフォルトでは速度制限はありません。たとえば、このオプションを`1MiB`と指定すると、書き込み速度を1 MiB/sに制限できます。 | | `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` 、 {{B- `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` 、 {{B- `s3:DeleteObject` 、 `s3:PutObject` 、 `s3: AbortMultipartUpload` 。 | | `DISABLE_PRECHECK` | `SELECT`のすべてのファイル形式とクエリ結果 | このオプションを設定すると、CDCやPITRタスクの有無など、重要度の低い項目の事前チェックが無効になります。 | diff --git a/sql-statements/sql-statement-insert.md b/sql-statements/sql-statement-insert.md index 4274c58797852..1c07a6b1afeef 100644 --- a/sql-statements/sql-statement-insert.md +++ b/sql-statements/sql-statement-insert.md @@ -43,7 +43,7 @@ OnDuplicateKeyUpdate ::= > **注記：** > -> TiDB v6.6.0以降、 [リソース管理](/tidb-resource-control-ru-groups.md)サポートします。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、優先度の異なるSQL文のスケジュールをより適切に制御できます。リソース制御を有効にすると、文の優先度（ `PriorityOpt` ）は無効になります。異なるSQL文のリソース使用量を管理するには、 [リソース管理](/tidb-resource-control-ru-groups.md)使用することをお勧めします。 +> TiDB v6.6.0以降、 [リソース管理](/tidb-resource-control-ru-groups.md)サポートします。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、優先度の異なるSQL文のスケジュールをより適切に制御できます。リソース制御を有効にすると、文の優先度（ `PriorityOpt` ）は無効になります。異なるSQL文のリソース使用量を管理するには、 [リソース管理](/tidb-resource-control-ru-groups.md)を使用することをお勧めします。 ## 例 {#examples} @@ -101,7 +101,7 @@ mysql> SELECT * FROM t2; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`INSERT`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`INSERT`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index da70369787ac6..4ae11b9797fc2 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -14,7 +14,7 @@ TiDB v7.0.0 以降、 `LOAD DATA` SQL ステートメントは次の機能をサ > **警告：** > -> 新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> 新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 @@ -175,7 +175,7 @@ IGNORE 1 LINES; ## MySQLの互換性 {#mysql-compatibility} -`LOAD DATA`文の構文はMySQLの構文と互換性がありますが、文字セットオプションは解析されますが無視されます。構文の互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +`LOAD DATA`文の構文はMySQLの構文と互換性がありますが、文字セットオプションは解析されますが無視されます。構文の互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 diff --git a/sql-statements/sql-statement-lock-stats.md b/sql-statements/sql-statement-lock-stats.md index 4e63ce9ae9468..7128c7f213024 100644 --- a/sql-statements/sql-statement-lock-stats.md +++ b/sql-statements/sql-statement-lock-stats.md @@ -5,7 +5,7 @@ summary: TiDB データベースの LOCK STATS の使用法の概要。 # LOCK STATS {#lock-stats} -`LOCK STATS` 、テーブルまたはパーティションの統計情報をロックするために使用されます。統計情報がロックされている場合、TiDB はテーブルまたはパーティションの統計情報を自動更新しません。動作の詳細については、 [統計情報のロックの動作](/statistics.md#behaviors-of-locking-statistics)参照してください。 +`LOCK STATS` 、テーブルまたはパーティションの統計情報をロックするために使用されます。統計情報がロックされている場合、TiDB はテーブルまたはパーティションの統計情報を自動更新しません。動作の詳細については、 [統計情報のロックの動作](/statistics.md#behaviors-of-locking-statistics)を参照してください。 ## 概要 {#synopsis} @@ -130,7 +130,7 @@ mysql> SHOW WARNINGS; 2 rows in set (0.00 sec) ``` -ロック解除統計の詳細については、 [UNLOCK STATS](/sql-statements/sql-statement-unlock-stats.md)参照してください。 +ロック解除統計の詳細については、 [UNLOCK STATS](/sql-statements/sql-statement-unlock-stats.md)を参照してください。 ## MySQLの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-prepare.md b/sql-statements/sql-statement-prepare.md index 8e9cb0f7860b7..e12306918f635 100644 --- a/sql-statements/sql-statement-prepare.md +++ b/sql-statements/sql-statement-prepare.md @@ -47,7 +47,7 @@ Query OK, 0 rows affected (0.00 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`PREPARE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`PREPARE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-rename-index.md b/sql-statements/sql-statement-rename-index.md index 8c550ca7ae181..b7efa18f53995 100644 --- a/sql-statements/sql-statement-rename-index.md +++ b/sql-statements/sql-statement-rename-index.md @@ -51,7 +51,7 @@ Create Table: CREATE TABLE `t1` ( ## MySQLの互換性 {#mysql-compatibility} -TiDBの`RENAME INDEX`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`RENAME INDEX`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-rename-table.md b/sql-statements/sql-statement-rename-table.md index ca7ee38933c83..b56637f9feb5b 100644 --- a/sql-statements/sql-statement-rename-table.md +++ b/sql-statements/sql-statement-rename-table.md @@ -134,7 +134,7 @@ SHOW CREATE TABLE t1\G ## MySQLの互換性 {#mysql-compatibility} -TiDBの`RENAME TABLE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`RENAME TABLE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-rename-user.md b/sql-statements/sql-statement-rename-user.md index 07221b3af8192..673d2f05c1dd2 100644 --- a/sql-statements/sql-statement-rename-user.md +++ b/sql-statements/sql-statement-rename-user.md @@ -72,7 +72,7 @@ ERROR 1141 (42000): There is no such grant defined for user 'newuser' on host '% ## MySQLの互換性 {#mysql-compatibility} -`RENAME USER` MySQL と完全に互換性があると予想されます。互換性に違いが見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +`RENAME USER` MySQL と完全に互換性があると予想されます。互換性に違いが見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-replace.md b/sql-statements/sql-statement-replace.md index 2b0bc59641ddb..8dacf853a2d7e 100644 --- a/sql-statements/sql-statement-replace.md +++ b/sql-statements/sql-statement-replace.md @@ -34,7 +34,7 @@ InsertValues ::= > **注記：** > -> TiDB v6.6.0以降、 [リソース管理](/tidb-resource-control-ru-groups.md)サポートします。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、優先度の異なるSQL文のスケジュールをより適切に制御できます。リソース制御を有効にすると、文の優先度（ `PriorityOpt` ）は無効になります。異なるSQL文のリソース使用量を管理するには、 [リソース管理](/tidb-resource-control-ru-groups.md)使用することをお勧めします。 +> TiDB v6.6.0以降、 [リソース管理](/tidb-resource-control-ru-groups.md)サポートします。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、優先度の異なるSQL文のスケジュールをより適切に制御できます。リソース制御を有効にすると、文の優先度（ `PriorityOpt` ）は無効になります。異なるSQL文のリソース使用量を管理するには、 [リソース管理](/tidb-resource-control-ru-groups.md)を使用することをお勧めします。 ## 例 {#examples} @@ -72,7 +72,7 @@ mysql> SELECT * FROM t1; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`REPLACE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`REPLACE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-revoke-role.md b/sql-statements/sql-statement-revoke-role.md index eee429642d2fb..fb24cc890696a 100644 --- a/sql-statements/sql-statement-revoke-role.md +++ b/sql-statements/sql-statement-revoke-role.md @@ -160,7 +160,7 @@ SHOW GRANTS; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`REVOKE `文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`REVOKE `文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-set-default-role.md b/sql-statements/sql-statement-set-default-role.md index d1bdd6c36572c..b3010c4c82cfd 100644 --- a/sql-statements/sql-statement-set-default-role.md +++ b/sql-statements/sql-statement-set-default-role.md @@ -130,7 +130,7 @@ ERROR 3530 (HY000): `analyticsteam`@`%` is is not granted to jennifer@% ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SET DEFAULT ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SET DEFAULT ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-set-names.md b/sql-statements/sql-statement-set-names.md index 2a3da7a633ba9..fd1f9ce1bfe41 100644 --- a/sql-statements/sql-statement-set-names.md +++ b/sql-statements/sql-statement-set-names.md @@ -71,7 +71,7 @@ mysql> SHOW VARIABLES LIKE 'character_set%'; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SET [NAMES|CHARACTER SET]`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SET [NAMES|CHARACTER SET]`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-set-password.md b/sql-statements/sql-statement-set-password.md index 10e032e6efe71..8634fec25d15a 100644 --- a/sql-statements/sql-statement-set-password.md +++ b/sql-statements/sql-statement-set-password.md @@ -56,7 +56,7 @@ mysql> SHOW CREATE USER 'newuser'; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SET PASSWORD`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SET PASSWORD`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-set-role.md b/sql-statements/sql-statement-set-role.md index dce5aaac3918c..7074b18c62ecd 100644 --- a/sql-statements/sql-statement-set-role.md +++ b/sql-statements/sql-statement-set-role.md @@ -83,7 +83,7 @@ SELECT CURRENT_ROLE(); ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SET ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SET ROLE`文はMySQL 8.0のロール機能と完全に互換性があります。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-set-transaction.md b/sql-statements/sql-statement-set-transaction.md index 5e02956d3331a..05d156c691633 100644 --- a/sql-statements/sql-statement-set-transaction.md +++ b/sql-statements/sql-statement-set-transaction.md @@ -65,7 +65,7 @@ mysql> SHOW SESSION VARIABLES LIKE 'transaction_isolation'; - TiDB は、構文でのみトランザクションを読み取り専用として設定する機能をサポートしています。 - 分離レベル`READ-UNCOMMITTED`および`SERIALIZABLE`サポートされていません。 - `REPEATABLE-READ`分離レベルは、MySQL と部分的に互換性のあるスナップショット分離テクノロジを使用することで実現されます。 -- 悲観的トランザクションでは、TiDBはMySQLと互換性のある2つの分離レベル（ `REPEATABLE-READ`と`READ-COMMITTED`をサポートしています。詳細については、 [分離レベル](/transaction-isolation-levels.md)参照してください。 +- 悲観的トランザクションでは、TiDBはMySQLと互換性のある2つの分離レベル（ `REPEATABLE-READ`と`READ-COMMITTED`をサポートしています。詳細については、 [分離レベル](/transaction-isolation-levels.md)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-character-set.md b/sql-statements/sql-statement-show-character-set.md index ecc3993de74ab..eabe2a5d35e28 100644 --- a/sql-statements/sql-statement-show-character-set.md +++ b/sql-statements/sql-statement-show-character-set.md @@ -62,7 +62,7 @@ SHOW CHARACTER SET WHERE Description='UTF-8 Unicode'; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW CHARACTER SET`文の使用方法はMySQLと完全に互換性があります。ただし、TiDBの文字セットはMySQLと比較してデフォルトの照合順序が異なる場合があります。詳細については[MySQLとの互換性](/mysql-compatibility.md)参照してください。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW CHARACTER SET`文の使用方法はMySQLと完全に互換性があります。ただし、TiDBの文字セットはMySQLと比較してデフォルトの照合順序が異なる場合があります。詳細については[MySQLとの互換性](/mysql-compatibility.md)を参照してください。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-collation.md b/sql-statements/sql-statement-show-collation.md index c7344783d752a..c985a8a0d5bff 100644 --- a/sql-statements/sql-statement-show-collation.md +++ b/sql-statements/sql-statement-show-collation.md @@ -96,7 +96,7 @@ SHOW COLLATION WHERE Charset="utf8mb4"; ## MySQLの互換性 {#mysql-compatibility} -TiDBにおける`SHOW COLLATION`文の使用法はMySQLと完全に互換性があります。ただし、TiDBの文字セットはMySQLと比較してデフォルトの照合順序が異なる場合があります。詳細については[MySQLとの互換性](/mysql-compatibility.md)参照してください。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBにおける`SHOW COLLATION`文の使用法はMySQLと完全に互換性があります。ただし、TiDBの文字セットはMySQLと比較してデフォルトの照合順序が異なる場合があります。詳細については[MySQLとの互換性](/mysql-compatibility.md)を参照してください。互換性に関する相違点が見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-columns-from.md b/sql-statements/sql-statement-show-columns-from.md index 2bbe2a15307fb..8911ecf421717 100644 --- a/sql-statements/sql-statement-show-columns-from.md +++ b/sql-statements/sql-statement-show-columns-from.md @@ -129,7 +129,7 @@ mysql> SHOW FULL COLUMNS FROM mysql.user; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW [FULL] COLUMNS FROM`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW [FULL] COLUMNS FROM`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-create-database.md b/sql-statements/sql-statement-show-create-database.md index afd5ffca30599..865a63624522c 100644 --- a/sql-statements/sql-statement-show-create-database.md +++ b/sql-statements/sql-statement-show-create-database.md @@ -54,7 +54,7 @@ SHOW CREATE SCHEMA IF NOT EXISTS test; ## MySQLの互換性 {#mysql-compatibility} -`SHOW CREATE DATABASE` MySQL と完全に互換性があると予想されます。互換性に違いが見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +`SHOW CREATE DATABASE` MySQL と完全に互換性があると予想されます。互換性に違いが見つかった場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-create-table.md b/sql-statements/sql-statement-show-create-table.md index 102681bfc4feb..debd8b04328bb 100644 --- a/sql-statements/sql-statement-show-create-table.md +++ b/sql-statements/sql-statement-show-create-table.md @@ -31,7 +31,7 @@ Create Table: CREATE TABLE `t1` ( ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW CREATE TABLE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW CREATE TABLE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-databases.md b/sql-statements/sql-statement-show-databases.md index 0bb4698022181..1e1cee67819a9 100644 --- a/sql-statements/sql-statement-show-databases.md +++ b/sql-statements/sql-statement-show-databases.md @@ -52,7 +52,7 @@ mysql> SHOW DATABASES; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW DATABASES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW DATABASES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-engines.md b/sql-statements/sql-statement-show-engines.md index d8fc378090f00..7a1b74394a98c 100644 --- a/sql-statements/sql-statement-show-engines.md +++ b/sql-statements/sql-statement-show-engines.md @@ -32,4 +32,4 @@ mysql> SHOW ENGINES; ## MySQLの互換性 {#mysql-compatibility} -- このステートメントは、サポートされているエンジンとして常にInnoDBのみを返します。TiDBは内部的に、ストレージエンジンとして通常[TiKV](/tikv-overview.md)使用します。 +- このステートメントは、サポートされているエンジンとして常にInnoDBのみを返します。TiDBは内部的に、ストレージエンジンとして通常[TiKV](/tikv-overview.md)を使用します。 diff --git a/sql-statements/sql-statement-show-errors.md b/sql-statements/sql-statement-show-errors.md index 77e9ca145437a..f145f7912b63f 100644 --- a/sql-statements/sql-statement-show-errors.md +++ b/sql-statements/sql-statement-show-errors.md @@ -52,7 +52,7 @@ Empty set (0.00 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW ERRORS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW ERRORS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-grants.md b/sql-statements/sql-statement-show-grants.md index 46aabfe1aa69a..56c224bfa7806 100644 --- a/sql-statements/sql-statement-show-grants.md +++ b/sql-statements/sql-statement-show-grants.md @@ -52,7 +52,7 @@ mysql> SHOW GRANTS FOR u1; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW GRANTS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW GRANTS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-indexes.md b/sql-statements/sql-statement-show-indexes.md index 058622779f79a..82a8b71425137 100644 --- a/sql-statements/sql-statement-show-indexes.md +++ b/sql-statements/sql-statement-show-indexes.md @@ -56,7 +56,7 @@ TiDB `BTREE` `HASH`のインデックス タイプを`RTREE`ますが、無視 ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW INDEXES [FROM|IN]`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW INDEXES [FROM|IN]`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-privileges.md b/sql-statements/sql-statement-show-privileges.md index 62a49bc9a6a6d..d501dc9680f28 100644 --- a/sql-statements/sql-statement-show-privileges.md +++ b/sql-statements/sql-statement-show-privileges.md @@ -78,7 +78,7 @@ SHOW PRIVILEGES; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW PRIVILEGES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW PRIVILEGES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-table-status.md b/sql-statements/sql-statement-show-table-status.md index 7dbce7fbc07db..dd33d39ffa815 100644 --- a/sql-statements/sql-statement-show-table-status.md +++ b/sql-statements/sql-statement-show-table-status.md @@ -78,7 +78,7 @@ Max_data_length: 0 ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW TABLE STATUS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW TABLE STATUS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-tables.md b/sql-statements/sql-statement-show-tables.md index ddd6d494e28e0..71ea472872f00 100644 --- a/sql-statements/sql-statement-show-tables.md +++ b/sql-statements/sql-statement-show-tables.md @@ -77,7 +77,7 @@ mysql> SHOW TABLES IN mysql; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW [FULL] TABLES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW [FULL] TABLES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-variables.md b/sql-statements/sql-statement-show-variables.md index 018e3ef88bd95..530f82997dd7b 100644 --- a/sql-statements/sql-statement-show-variables.md +++ b/sql-statements/sql-statement-show-variables.md @@ -73,7 +73,7 @@ mysql> SHOW VARIABLES WHERE Value=300; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW [GLOBAL|SESSION] VARIABLES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW [GLOBAL|SESSION] VARIABLES`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-show-warnings.md b/sql-statements/sql-statement-show-warnings.md index 77493c23010c5..e32dc07de5455 100644 --- a/sql-statements/sql-statement-show-warnings.md +++ b/sql-statements/sql-statement-show-warnings.md @@ -76,7 +76,7 @@ mysql> SELECT * FROM t1; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`SHOW WARNINGS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`SHOW WARNINGS`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-shutdown.md b/sql-statements/sql-statement-shutdown.md index 55201162aaa58..fa6ba9814af47 100644 --- a/sql-statements/sql-statement-shutdown.md +++ b/sql-statements/sql-statement-shutdown.md @@ -32,4 +32,4 @@ SHUTDOWN; > > TiDB は分散データベースであるため、TiDB のシャットダウン操作では、TiDB クラスター全体ではなく、クライアントに接続された TiDB インスタンスが停止されます。 -`SHUTDOWN`文はMySQLと部分的に互換性があります。互換性の問題が発生した場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)実行してください。 +`SHUTDOWN`文はMySQLと部分的に互換性があります。互換性の問題が発生した場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を実行してください。 diff --git a/sql-statements/sql-statement-truncate.md b/sql-statements/sql-statement-truncate.md index 7b94a0e2e3707..b668531722a42 100644 --- a/sql-statements/sql-statement-truncate.md +++ b/sql-statements/sql-statement-truncate.md @@ -57,7 +57,7 @@ Query OK, 0 rows affected (0.11 sec) ## MySQLの互換性 {#mysql-compatibility} -TiDBの`TRUNCATE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`TRUNCATE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-statements/sql-statement-update.md b/sql-statements/sql-statement-update.md index 5b195ff94cb41..1e69ef5644541 100644 --- a/sql-statements/sql-statement-update.md +++ b/sql-statements/sql-statement-update.md @@ -28,7 +28,7 @@ TableRefs ::= > **注記：** > -> TiDB v6.6.0以降、 [リソース管理](/tidb-resource-control-ru-groups.md)サポートします。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、優先度の異なるSQL文のスケジュールをより適切に制御できます。リソース制御を有効にすると、文の優先度（ `LOW_PRIORITY`と`HIGH_PRIORITY` ）は無効になります。異なるSQL文のリソース使用量を管理するには、 [リソース管理](/tidb-resource-control-ru-groups.md)使用することをお勧めします。 +> TiDB v6.6.0以降、 [リソース管理](/tidb-resource-control-ru-groups.md)サポートします。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、優先度の異なるSQL文のスケジュールをより適切に制御できます。リソース制御を有効にすると、文の優先度（ `LOW_PRIORITY`と`HIGH_PRIORITY` ）は無効になります。異なるSQL文のリソース使用量を管理するには、 [リソース管理](/tidb-resource-control-ru-groups.md)を使用することをお勧めします。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-use.md b/sql-statements/sql-statement-use.md index e83b3eb3951d6..3a15b66d4a71f 100644 --- a/sql-statements/sql-statement-use.md +++ b/sql-statements/sql-statement-use.md @@ -74,7 +74,7 @@ mysql> SHOW TABLES; ## MySQLの互換性 {#mysql-compatibility} -TiDBの`USE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)参照してください。 +TiDBの`USE`文はMySQLと完全に互換性があります。互換性に違いがある場合は、 [バグを報告する](https://docs.pingcap.com/tidb/stable/support)を参照してください。 ## 参照 {#see-also} diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..7f333eee85142 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -73,13 +73,13 @@ SQLチューニングは、クエリの機能を変えずに同じワークロ ### 作業負荷の分散をバランスよく行う {#balance-workload-distribution} -TiDBのような分散アーキテクチャでは、TiKVノード間でワークロードを分散させることが最適なパフォーマンスを得るために不可欠です。読み取りと書き込みのホットスポットを特定して解決するには、 [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md#optimization-of-small-table-hotspots)参照してください。 +TiDBのような分散アーキテクチャでは、TiKVノード間でワークロードを分散させることが最適なパフォーマンスを得るために不可欠です。読み取りと書き込みのホットスポットを特定して解決するには、 [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md#optimization-of-small-table-hotspots)を参照してください。 これらの戦略を実装することで、TiDB クラスターが利用可能なすべてのリソースを効率的に利用し、個々の TiKV ノードでのワークロードの不均一な分散やシリアル化によって発生するボトルネックを回避できるようになります。 ## 高負荷SQLを特定する {#identify-high-load-sql} -リソースを大量に消費する SQL 文を特定する最も効率的な方法は、 [TiDB Dashboard](/dashboard/dashboard-overview.md)使用することです。また、ビューやログなどの他のツールを使用して、負荷の高い SQL 文を特定することもできます。 +リソースを大量に消費する SQL 文を特定する最も効率的な方法は、 [TiDB Dashboard](/dashboard/dashboard-overview.md)を使用することです。また、ビューやログなどの他のツールを使用して、負荷の高い SQL 文を特定することもできます。 ### TiDB Dashboardを使用してSQL文を監視する {#monitor-sql-statements-using-tidb-dashboard} @@ -117,7 +117,7 @@ TiDB Dashboardに加えて、他のツールを使用してリソースを大量 ### 識別されたSQL文に関するデータを収集する {#gather-data-on-identified-sql-statements} -特定された上位のSQL文については、 [`PLAN REPLAYER`](/sql-plan-replayer.md)使用してTiDBクラスタからSQL実行情報を取得・保存できます。このツールは、さらなる分析のために実行環境を再現するのに役立ちます。SQL実行情報をエクスポートするには、次の構文を使用します。 +特定された上位のSQL文については、 [`PLAN REPLAYER`](/sql-plan-replayer.md)を使用してTiDBクラスタからSQL実行情報を取得・保存できます。このツールは、さらなる分析のために実行環境を再現するのに役立ちます。SQL実行情報をエクスポートするには、次の構文を使用します。 ```sql PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql-statement; @@ -257,7 +257,7 @@ SHOW VARIABLES LIKE 'tidb\_auto\_analyze%'; テーブルの統計をロックするには、 [`LOCK STATS table_name`](/sql-statements/sql-statement-lock-stats.md)ステートメントを使用できます。 -詳細については[統計](/statistics.md)参照してください。 +詳細については[統計](/statistics.md)を参照してください。 ### 実行計画を理解する {#understand-execution-plans} @@ -291,7 +291,7 @@ EXPLAIN SELECT id, name FROM emp WHERE id = 901; 論理変換では、TiDBは`SELECT`リスト、 `WHERE`述語、およびその他の条件に基づいてSQL文を最適化します。クエリに注釈を付けて書き換えるための論理実行プランを生成します。この論理プランは、次の段階であるコストベースの最適化で使用されます。この変換では、列プルーニング、パーティションプルーニング、結合順序の変更といったルールベースの最適化が適用されます。このプロセスはルールベースで自動的に実行されるため、通常は手動での調整は不要です。 -詳細については[SQL論理最適化](/sql-logical-optimization.md)参照してください。 +詳細については[SQL論理最適化](/sql-logical-optimization.md)を参照してください。 ##### 3. コストベースの最適化 {#3-cost-based-optimization} @@ -311,7 +311,7 @@ TiDBオプティマイザは、統計情報を用いてSQL文の各ステップ ![cost-based-optimization](/media/sql-tuning/cost-based-optimization.png) -詳細については[SQL物理最適化](/sql-physical-optimization.md)参照してください。 +詳細については[SQL物理最適化](/sql-physical-optimization.md)を参照してください。 #### 実行計画を生成して表示する {#generate-and-display-execution-plans} @@ -338,7 +338,7 @@ EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00 +--------------------------+-------------+--------------+-------------------+----------------------------------------------------------------------------------------------------+ 5 rows in set (0.00 sec) -`EXPLAIN`とは異なり、 `EXPLAIN ANALYZE`対応するSQL文を実行し、その実行時情報を記録し、実行計画とともに返します。この実行時情報は、クエリ実行のデバッグに不可欠です。詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)参照してください。 +`EXPLAIN`とは異なり、 `EXPLAIN ANALYZE`対応するSQL文を実行し、その実行時情報を記録し、実行計画とともに返します。この実行時情報は、クエリ実行のデバッグに不可欠です。詳細については、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を参照してください。 `EXPLAIN ANALYZE`出力には以下が含まれます。 @@ -538,7 +538,7 @@ LIMIT 3; | └─TableRangeScan_82 | 1000.00 | 2048 | cop[tikv] | table:orders | tikv_task:{pro...| N/A | N/A | +---------------------------------------+----------+---------+-----------+----------------------------------------------------------------------------------------+---------------...+----------+------+ -詳細については、 [TiDB クエリ実行プランの概要](/explain-overview.md)および[`EXPLAIN`ウォークスルー](/explain-walkthrough.md)参照してください。 +詳細については、 [TiDB クエリ実行プランの概要](/explain-overview.md)および[`EXPLAIN`ウォークスルー](/explain-walkthrough.md)を参照してください。 ### TiDBのインデックス戦略 {#index-strategy-in-tidb} @@ -604,7 +604,7 @@ TiDBのパフォーマンスを最適化するには、インデックスを効 以下にいくつかのベストプラクティスを示します。 - パフォーマンス上の明らかな利点がある場合にのみインデックスを作成します。 -- [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)使用してインデックスの使用状況統計を定期的に確認します。 +- [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md)を使用してインデックスの使用状況統計を定期的に確認します。 - インデックスを設計するときは、ワークロードの書き込み/読み取り比率を考慮してください。 #### カバーインデックスを使用したSQLチューニング {#sql-tuning-with-a-covering-index} diff --git a/stale-read.md b/stale-read.md index 12478e11e00ee..bc0524afb8567 100644 --- a/stale-read.md +++ b/stale-read.md @@ -15,7 +15,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 - シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 -- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。Stale ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンター展開におけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)参照してください。 +- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。Stale ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンター展開におけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 @@ -30,7 +30,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 TiDB は、次のようにステートメント レベル、セッション レベル、およびグローバル レベルでステイル読み取りを実行する方法を提供します。 - ステートメントレベル - - 正確な時点の指定（**推奨**）：TiDB が特定の時点からグローバルに一貫性のあるデータを分離レベルに違反することなく読み取る必要がある場合は、クエリ文でその時点の対応するタイムスタンプを指定できます。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)参照してください。 + - 正確な時点の指定（**推奨**）：TiDB が特定の時点からグローバルに一貫性のあるデータを分離レベルに違反することなく読み取る必要がある場合は、クエリ文でその時点の対応するタイムスタンプを指定できます。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)を参照してください。 - 時間範囲の指定：TiDB が分離レベルに違反することなく、特定の時間範囲内で可能な限り新しいデータを読み取る必要がある場合、クエリ文で時間範囲を指定できます。指定された時間範囲内で、TiDB は適切なタイムスタンプを選択して対応するデータを読み取ります。「適切」とは、このタイムスタンプより前に開始され、アクセスされたレプリカでコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセスされたレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされないことを意味します。詳細な使用方法については、 [`AS OF TIMESTAMP`句](/as-of-timestamp.md#syntax)および[`TIDB_BOUNDED_STALENESS`関数](/as-of-timestamp.md#syntax)の概要を参照してください。 - セッションレベル - 時間範囲の指定：セッションにおいて、後続のクエリでTiDBが分離レベルに違反することなく、指定された時間範囲内で可能な限り新しいデータを読み取る必要がある場合は、システム変数`tidb_read_staleness`設定することで時間範囲を指定できます。詳細な使用方法については、 [`tidb_read_staleness`](/tidb-read-staleness.md)を参照してください。 @@ -54,7 +54,7 @@ advance-ts-interval = "20s" # The default value is "20s". You can set it to a sm -Resolved TS の内部と診断手法の詳細については、 [TiKV におけるステイル読み取りと safe-ts の理解](/troubleshoot-stale-read.md)参照してください。 +Resolved TS の内部と診断手法の詳細については、 [TiKV におけるステイル読み取りと safe-ts の理解](/troubleshoot-stale-read.md)を参照してください。 diff --git a/statistics.md b/statistics.md index abe3c691b5f2c..f1c252e73744e 100644 --- a/statistics.md +++ b/statistics.md @@ -735,7 +735,7 @@ TiDB v6.0以降、TiDBは`KILL`ステートメントを使用して、バック -`KILL`ステートメントの詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)参照してください。 +`KILL`ステートメントの詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。 ### 制御ANALYZE並行性 {#control-code-analyze-code-concurrency} diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index d02d4cac0564b..fc18c73919c0c 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -30,7 +30,7 @@ TitanはRocksDBと互換性があるため、RocksDBを使用する既存のTiKV tiup cluster reload ${cluster-name} -R tikv ``` - 詳細なコマンドについては[TiUPを使用して構成を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)参照してください。 + 詳細なコマンドについては[TiUPを使用して構成を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)を参照してください。 - 方法 2: TiKV 構成ファイルを直接編集して Titan を有効にします (本番環境では推奨さ**れません**)。 @@ -71,7 +71,7 @@ TitanはRocksDBと互換性があるため、RocksDBを使用する既存のTiKV Titan を有効にした後、RocksDB に保存されている既存のデータは、すぐに Titan エンジンに移動されるわけではありません。新しいデータが TiKV に書き込まれ、RocksDB が圧縮を実行すると、**値は徐々にキーから分離され、 Titan に書き込まれます**。同様に、 BRスナップショット/ログを通じて復元されたデータ、スケーリング中に変換されたデータ、またはTiDB Lightning物理インポート モードによってインポートされたデータは、Titan に直接書き込まれません。圧縮が進むにつれて、処理された SST ファイル内のデフォルト値 ( `32KB` ) の[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)を超える大きな値が Titan に分離されます。TiKV**の詳細 > Titan kv > blob ファイル サイズ**パネルを観察してデータ サイズを見積もることで、Titan に保存されているファイルのサイズを監視できます。 -書き込みプロセスを高速化したい場合は、tikv-ctl を使用して TiKV クラスター全体のデータを手動で圧縮できます。詳細は[手作業による圧縮](/tikv-control.md#compact-data-of-the-whole-tikv-cluster-manually)参照してください。RocksDB から Titan への変換中はデータアクセスが継続的に行われるため、RocksDB のブロックキャッシュによってデータ変換プロセスが大幅に高速化されます。テストでは、tikv-ctl を使用することで、670 GiB の TiKV データを 1 時間で Titan に変換できました。 +書き込みプロセスを高速化したい場合は、tikv-ctl を使用して TiKV クラスター全体のデータを手動で圧縮できます。詳細は[手作業による圧縮](/tikv-control.md#compact-data-of-the-whole-tikv-cluster-manually)を参照してください。RocksDB から Titan への変換中はデータアクセスが継続的に行われるため、RocksDB のブロックキャッシュによってデータ変換プロセスが大幅に高速化されます。テストでは、tikv-ctl を使用することで、670 GiB の TiKV データを 1 時間で Titan に変換できました。 Titan BLOBファイル内の値は連続しておらず、Titanのキャッシュは値レベルであるため、圧縮時にはBLOBキャッシュは役に立ちません。TitanからRocksDBへの変換速度は、RocksDBからTitanへの変換速度よりも桁違いに遅くなります。テストでは、TiKVノード上の800GiBのTitanデータをtikv-ctlでRocksDBに完全圧縮変換するのに12時間かかりました。 @@ -81,15 +81,15 @@ Titanパラメータを適切に設定することで、データベースのパ ### `min-blob-size` {#min-blob-size} -[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)使用すると、RocksDB に保存するデータと Titan の BLOB ファイルに保存するデータを決定するための値のサイズのしきい値を設定できます。テストによると、適切なしきい値は`32KB`です。これにより、RocksDB と比較して Titan のパフォーマンスが低下しないことが保証されます。ただし、多くのシナリオでは、この値は最適ではありません。適切な値を選択するには、 [`min-blob-size`がパフォーマンスに与える影響](/storage-engine/titan-overview.md#impact-of-min-blob-size-on-performance)を参照することをお勧めします。書き込みパフォーマンスをさらに向上させ、スキャンパフォーマンスの低下を許容できる場合は、最小値の`1KB`に設定できます。 +[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)を使用すると、RocksDB に保存するデータと Titan の BLOB ファイルに保存するデータを決定するための値のサイズのしきい値を設定できます。テストによると、適切なしきい値は`32KB`です。これにより、RocksDB と比較して Titan のパフォーマンスが低下しないことが保証されます。ただし、多くのシナリオでは、この値は最適ではありません。適切な値を選択するには、 [`min-blob-size`がパフォーマンスに与える影響](/storage-engine/titan-overview.md#impact-of-min-blob-size-on-performance)を参照することをお勧めします。書き込みパフォーマンスをさらに向上させ、スキャンパフォーマンスの低下を許容できる場合は、最小値の`1KB`に設定できます。 ### blob-file-compressionとzstd-dict-size {#code-blob-file-compression-code-and-code-zstd-dict-size-code} -[`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression)使用すると、Titan の値に使用する圧縮アルゴリズムを指定できます。また、 `zstd`から[`zstd-dict-size`](/tikv-configuration-file.md#zstd-dict-size)の辞書圧縮を有効にして圧縮率を向上させることもできます。 +[`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression)を使用すると、Titan の値に使用する圧縮アルゴリズムを指定できます。また、 `zstd`から[`zstd-dict-size`](/tikv-configuration-file.md#zstd-dict-size)の辞書圧縮を有効にして圧縮率を向上させることもできます。 ### `blob-cache-size` {#blob-cache-size} -Titanの値のキャッシュサイズを制御するには、 [`blob-cache-size`](/tikv-configuration-file.md#blob-cache-size)使用します。キャッシュサイズが大きいほど、Titanの読み取りパフォーマンスが向上します。ただし、キャッシュサイズが大きすぎると、メモリ不足（OOM）の問題が発生します。 +Titanの値のキャッシュサイズを制御するには、 [`blob-cache-size`](/tikv-configuration-file.md#blob-cache-size)を使用します。キャッシュサイズが大きいほど、Titanの読み取りパフォーマンスが向上します。ただし、キャッシュサイズが大きすぎると、メモリ不足（OOM）の問題が発生します。 ストアサイズからBLOBファイルサイズを引いた値を`storage.block-cache.capacity`に設定し、データベースが安定して動作している場合は、監視指標に応じて`blob-cache-size` ～ `memory size * 50% - block cache size`設定することをお勧めします。これにより、ブロックキャッシュがRocksDBエンジン全体に十分な大きさである場合に、BLOBキャッシュサイズが最大化されます。 diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 8032de6dd2f93..7ecf549b6edbb 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -33,7 +33,7 @@ Titan を有効にするための前提条件は次のとおりです。 バージョン7.6.0以降、新規作成されたクラスターではTitanがデフォルトで有効になっています。小さなTiKV値はRocksDBに保存されたままなので、このシナリオでもTitanを有効にすることができます。 -Titan のパフォーマンスを向上させたい場合は、ブログ投稿[Titan: 書き込み増幅を減らす RocksDB プラグイン](https://pingcap.com/blog/titan-storage-engine-design-and-implementation/)参照してください。 +Titan のパフォーマンスを向上させたい場合は、ブログ投稿[Titan: 書き込み増幅を減らす RocksDB プラグイン](https://pingcap.com/blog/titan-storage-engine-design-and-implementation/)を参照してください。 ## アーキテクチャと実装 {#architecture-and-implementation} diff --git a/subquery-optimization.md b/subquery-optimization.md index 0a1a256fec76d..15363e7212dae 100644 --- a/subquery-optimization.md +++ b/subquery-optimization.md @@ -16,7 +16,7 @@ summary: サブクエリに関連する最適化を理解します。 - `EXISTS (SELECT ... FROM ...)` - `... >/>=/ SELECT * FROM t1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- 明示的なトランザクションにないときにステートメントを自動的にコミットするかどうかを制御します。詳細については、[トランザクション概要](/transaction-overview.md#autocommit)参照してください。 +- 明示的なトランザクションにないときにステートメントを自動的にコミットするかどうかを制御します。詳細については、[トランザクション概要](/transaction-overview.md#autocommit)を参照してください。 ### ブロック暗号化モード {#block-encryption-mode} @@ -893,7 +893,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; -- この変数により、TiDB へのすべての接続がローカル ソケット上か TLS を使用するようになります。詳細については、 [TiDBクライアントとサーバー間でTLSを有効にする](/enable-tls-between-clients-and-servers.md)参照してください。 +- この変数により、TiDB へのすべての接続がローカル ソケット上か TLS を使用するようになります。詳細については、 [TiDBクライアントとサーバー間でTLSを有効にする](/enable-tls-between-clients-and-servers.md)を参照してください。 @@ -1183,7 +1183,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - TiDB Self-Managedの場合、v5.3.0以降、この変数のデフォルト値が`1`から`2`に変更されます。 - TiDB Cloudの場合、v6.5.0 以降、この変数のデフォルト値が`1`から`2`に変更されます。 - クラスターを以前のバージョンからアップグレードした場合、 `tidb_analyze_version`のデフォルト値はアップグレード後も変更されません。 -- この変数の詳細については、[統計入門](/statistics.md)参照してください。 +- この変数の詳細については、[統計入門](/statistics.md)を参照してください。 ### tidb_analyze_skip_column_types はv7.2.0 で追加されました。 {#tidb-analyze-skip-column-types-span-class-version-mark-new-in-v7-2-0-span} @@ -1577,7 +1577,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - この変数は悲観的トランザクションにのみ適用されます。楽観的トランザクションの場合は、代わりに[`tidb_constraint_check_in_place`](#tidb_constraint_check_in_place)を使用してください。 - この変数が`OFF`に設定されている場合、TiDB は一意インデックスの一意制約チェックを延期します (インデックスへのロックを必要とするステートメントを実行する次回の時点、またはトランザクションをコミットする時点まで)。これによりパフォーマンスが向上しますが、一部のアプリケーションでは予期しない動作となる可能性があります。 詳細はを[制約](/constraints.md#pessimistic-transactions)してください。 - この変数を無効にすると、TiDB が悲観的トランザクションで`LazyUniquenessCheckFailure`エラーを返す可能性があります。このエラーが発生すると、TiDB は現在のトランザクションをロールバックします。 -- この変数が無効になっている場合、悲観的トランザクションで[`SAVEPOINT`](/sql-statements/sql-statement-savepoint.md)使用することはできません。 +- この変数が無効になっている場合、悲観的トランザクションで[`SAVEPOINT`](/sql-statements/sql-statement-savepoint.md)を使用することはできません。 - この変数が無効になっている場合、悲観的トランザクションをコミットすると、 `Write conflict`または`Duplicate entry`エラーが返される可能性があります。このようなエラーが発生した場合、TiDB は現在のトランザクションをロールバックします。 - `tidb_constraint_check_in_place_pessimistic`を`OFF`に設定し、悲観的トランザクションを使用する場合： @@ -1690,7 +1690,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `OFF` -- この変数は、DDL 埋め込み`ANALYZE`を有効にするかどうかを制御します。有効にすると、新しいインデックスの作成 ( [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) ) または既存のインデックスの再編成 ( [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)および[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) ) を行う DDL ステートメントは、インデックスが表示される前に統計を自動的に収集します。詳細については、 [DDLステートメントに埋め込まれた`ANALYZE`](/ddl_embedded_analyze.md)参照してください。 +- この変数は、DDL 埋め込み`ANALYZE`を有効にするかどうかを制御します。有効にすると、新しいインデックスの作成 ( [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) ) または既存のインデックスの再編成 ( [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)および[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) ) を行う DDL ステートメントは、インデックスが表示される前に統計を自動的に収集します。詳細については、 [DDLステートメントに埋め込まれた`ANALYZE`](/ddl_embedded_analyze.md)を参照してください。 ### tidb_enable_dist_task v7.1.0で追加 {#tidb-enable-dist-task-new-in-v710} @@ -1766,7 +1766,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 単位：行 - この変数は、DDL 操作の`re-organize`フェーズ中にバッチ サイズを設定するために使用されます。たとえば、TiDB が`ADD INDEX`操作を実行すると、インデックス データは`tidb_ddl_reorg_worker_cnt` (数) 個の同時実行ワーカーによってバックフィルされる必要があります。各ワーカーは、インデックス データをバッチ単位でバックフィルします。 - `tidb_ddl_enable_fast_reorg`が`OFF`に設定されている場合、 `ADD INDEX`はトランザクションとして実行されます。 `UPDATE`の実行中に、対象列で`REPLACE`や`ADD INDEX` }} などの更新操作が多数発生する場合、バッチサイズが大きいほどトランザクション競合が発生する可能性が高くなります。この場合、バッチサイズを小さい値に設定することをお勧めします。最小値は 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)を参照してください。 @@ -1939,7 +1939,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 値のオプション: `"standard"` 、 `"bulk"` - この変数は、DMLステートメントの実行モードを制御します。 - `"standard"` TiDBトランザクションがコミットされる前にメモリにキャッシュされる標準DML実行モードを示します。このモードは、潜在的な競合が発生する可能性のある高並行トランザクションシナリオに適しており、推奨されるデフォルトの実行モードです。 - - `"bulk"`はパイプライン DML 実行モードを示し、大量のデータが書き込まれ、TiDB で過剰なメモリ使用量が発生するシナリオに適しています。詳細については、[パイプラインDML](/pipelined-dml.md)参照してください。 + - `"bulk"`はパイプライン DML 実行モードを示し、大量のデータが書き込まれ、TiDB で過剰なメモリ使用量が発生するシナリオに適しています。詳細については、[パイプラインDML](/pipelined-dml.md)を参照してください。 ### tidb_enable_1pc v5.0の新機能 {#tidb-enable-1pc-new-in-v50} @@ -2178,7 +2178,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - 型: Boolean - デフォルト値: `OFF` -- この変数は、TiDB がオプティマイザーをガイドする拡張統計を収集できるかどうかを示します。詳細については、[拡張統計入門](/extended-statistics.md)参照してください。 +- この変数は、TiDB がオプティマイザーをガイドする拡張統計を収集できるかどうかを示します。詳細については、[拡張統計入門](/extended-statistics.md)を参照してください。 ### tidb_enable_external_ts_read はv6.4.0 で追加されました。 {#tidb-enable-external-ts-read-span-class-version-mark-new-in-v6-4-0-span} @@ -2266,7 +2266,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **警告：** > -> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 @@ -2320,7 +2320,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **警告：** > -> DML ステートメント用の非プリペアド実行プラン キャッシュは実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> DML ステートメント用の非プリペアド実行プラン キャッシュは実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 - 範囲: セッション | グローバル - クラスターに保持される: はい @@ -2457,7 +2457,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- この変数は、DML ステートメントの実行中にデータとインデックス間の一貫性をチェックするために使用されるツールである TiDB ミューテーション チェッカーを有効にするかどうかを制御するために使用されます。チェッカーがステートメントに対してエラーを返した場合、TiDB はステートメントの実行をロールバックします。この変数を有効にすると、CPU 使用率がわずかに増加します。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)参照してください。 +- この変数は、DML ステートメントの実行中にデータとインデックス間の一貫性をチェックするために使用されるツールである TiDB ミューテーション チェッカーを有効にするかどうかを制御するために使用されます。チェッカーがステートメントに対してエラーを返した場合、TiDB はステートメントの実行をロールバックします。この変数を有効にすると、CPU 使用率がわずかに増加します。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)を参照してください。 - v6.0.0以降のバージョンの新規クラスターの場合、デフォルト値は`ON`です。v6.0.0より前のバージョンからアップグレードする既存のクラスターの場合、デフォルト値は`OFF`です。 ### tidb_enable_new_cost_interface v6.2.0で追加 {#tidb-enable-new-cost-interface-new-in-v620} @@ -2977,7 +2977,7 @@ Query OK, 0 rows affected (0.09 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `OFF` -- この変数は、式を生成された列に安全でない方法で置き換えるかどうかを制御します。デフォルト値は`OFF`で、これはデフォルトで安全でない置換が無効になっていることを意味します。詳細については、[生成された列](/generated-columns.md)参照してください。 +- この変数は、式を生成された列に安全でない方法で置き換えるかどうかを制御します。デフォルト値は`OFF`で、これはデフォルトで安全でない置換が無効になっていることを意味します。詳細については、[生成された列](/generated-columns.md)を参照してください。 ### tidb_enable_vectorized_expression v4.0で追加 {#tidb-enable-vectorized-expression-new-in-v40} @@ -3042,7 +3042,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **警告：** > -> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 - 範囲: セッション | グローバル - クラスターに保持される: はい @@ -3357,7 +3357,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 整数 - デフォルト値: `0` - 範囲: `[0, 15]` -- この変数は、新しく作成されたテーブルのデフォルトの行分割シャード数を設定するために使用されます。この変数がゼロ以外の値に設定されている場合、TiDB は`PRE_SPLIT_REGIONS`の使用を許可するテーブル (たとえば、 `NONCLUSTERED`テーブル) に、 `CREATE TABLE`ステートメントの実行時にこの属性を自動的に適用します。詳細については、 [`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)参照してください。この変数は通常、 [`tidb_shard_row_id_bits`](/system-variables.md#tidb_shard_row_id_bits-new-in-v840)と組み合わせて、新しいテーブルをシャーディングし、新しいテーブルのリージョンを事前に分割するために使用されます。 +- この変数は、新しく作成されたテーブルのデフォルトの行分割シャード数を設定するために使用されます。この変数がゼロ以外の値に設定されている場合、TiDB は`PRE_SPLIT_REGIONS`の使用を許可するテーブル (たとえば、 `NONCLUSTERED`テーブル) に、 `CREATE TABLE`ステートメントの実行時にこの属性を自動的に適用します。詳細については、 [`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)を参照してください。この変数は通常、 [`tidb_shard_row_id_bits`](/system-variables.md#tidb_shard_row_id_bits-new-in-v840)と組み合わせて、新しいテーブルをシャーディングし、新しいテーブルのリージョンを事前に分割するために使用されます。 ### tidb_generate_binary_plan v6.2.0で追加 {#tidb-generate-binary-plan-new-in-v620} @@ -3452,7 +3452,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **警告：** > -> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 - 範囲: セッション | グローバル - クラスターに保持される: はい @@ -3529,7 +3529,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 v7.6.0 の新機能 {#tidb-ignore-inlist-plan-digest-new-in-v760} @@ -3748,7 +3748,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)を参照してください。 @@ -3760,7 +3760,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)を参照してください。 @@ -3853,7 +3853,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 整数 - デフォルト値: `-1` - 範囲: `[-1, 9223372036854775807]` -- この変数は、 TiFlashの`GROUP BY`を使用したハッシュ集計演算子の最大メモリ使用量をバイト単位で指定するために使用されます。メモリ使用量が指定された値を超えると、 TiFlash はハッシュ集計演算子をトリガーしてディスクに書き出します。この変数の値が`-1`の場合、TiDB はこの変数をTiFlashに渡しません。この変数の値が`0`以上の場合のみ、TiDB はこの変数をTiFlashに渡します。この変数の値が`0`の場合、メモリ使用量は無制限、つまりTiFlashハッシュ集計演算子は書き出しをトリガーしないことを意味します。詳細は、 [TiFlashディスクへのスピル](/tiflash/tiflash-spill-disk.md)参照してください。 +- この変数は、 TiFlashの`GROUP BY`を使用したハッシュ集計演算子の最大メモリ使用量をバイト単位で指定するために使用されます。メモリ使用量が指定された値を超えると、 TiFlash はハッシュ集計演算子をトリガーしてディスクに書き出します。この変数の値が`-1`の場合、TiDB はこの変数をTiFlashに渡しません。この変数の値が`0`以上の場合のみ、TiDB はこの変数をTiFlashに渡します。この変数の値が`0`の場合、メモリ使用量は無制限、つまりTiFlashハッシュ集計演算子は書き出しをトリガーしないことを意味します。詳細は、 [TiFlashディスクへのスピル](/tiflash/tiflash-spill-disk.md)を参照してください。 @@ -3881,7 +3881,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 整数 - デフォルト値: `-1` - 範囲: `[-1, 9223372036854775807]` -- この変数は、 TiFlashの`JOIN`を使用した Hash Join 演算子の最大メモリ使用量をバイト単位で指定するために使用されます。メモリ使用量が指定された値を超えると、 TiFlash はHash Join 演算子をトリガーしてディスクに書き出します。この変数の値が`-1`の場合、TiDB はこの変数をTiFlashに渡しません。この変数の値が`0`以上の場合のみ、TiDB はこの変数をTiFlashに渡します。この変数の値が`0`の場合、メモリ使用量は無制限、つまりTiFlash Hash Join 演算子は書き出しをトリガーしません。詳細は、 [TiFlashディスクへのスピル](/tiflash/tiflash-spill-disk.md)参照してください。 +- この変数は、 TiFlashの`JOIN`を使用した Hash Join 演算子の最大メモリ使用量をバイト単位で指定するために使用されます。メモリ使用量が指定された値を超えると、 TiFlash はHash Join 演算子をトリガーしてディスクに書き出します。この変数の値が`-1`の場合、TiDB はこの変数をTiFlashに渡しません。この変数の値が`0`以上の場合のみ、TiDB はこの変数をTiFlashに渡します。この変数の値が`0`の場合、メモリ使用量は無制限、つまりTiFlash Hash Join 演算子は書き出しをトリガーしません。詳細は、 [TiFlashディスクへのスピル](/tiflash/tiflash-spill-disk.md)を参照してください。 @@ -3909,7 +3909,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 整数 - デフォルト値: `-1` - 範囲: `[-1, 9223372036854775807]` -- この変数は、 TiFlashの TopN および Sort 演算子の最大メモリ使用量をバイト単位で指定するために使用されます。メモリ使用量が指定された値を超えると、 TiFlash はTopN および Sort 演算子をトリガーしてディスクに書き出します。この変数の値が`-1`の場合、TiDB はこの変数をTiFlashに渡しません。この変数の値が`0`以上の場合のみ、TiDB はこの変数をTiFlashに渡します。この変数の値が`0`の場合、メモリ使用量は無制限であり、 TiFlash のTopN および Sort 演算子は書き出しをトリガーしません。詳細については、 [TiFlashディスクへのスピル](/tiflash/tiflash-spill-disk.md)参照してください。 +- この変数は、 TiFlashの TopN および Sort 演算子の最大メモリ使用量をバイト単位で指定するために使用されます。メモリ使用量が指定された値を超えると、 TiFlash はTopN および Sort 演算子をトリガーしてディスクに書き出します。この変数の値が`-1`の場合、TiDB はこの変数をTiFlashに渡しません。この変数の値が`0`以上の場合のみ、TiDB はこの変数をTiFlashに渡します。この変数の値が`0`の場合、メモリ使用量は無制限であり、 TiFlash のTopN および Sort 演算子は書き出しをトリガーしません。詳細については、 [TiFlashディスクへのスピル](/tiflash/tiflash-spill-disk.md)を参照してください。 @@ -3999,7 +3999,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー -- 単一の SQL ステートメントが`tidb_mem_quota_query`で指定されたメモリクォータを超え、ディスクに書き出すことができない場合に TiDB が実行する操作を指定します。詳細は[TiDBメモリ制御](/configure-memory-usage.md)参照してください。 +- 単一の SQL ステートメントが`tidb_mem_quota_query`で指定されたメモリクォータを超え、ディスクに書き出すことができない場合に TiDB が実行する操作を指定します。詳細は[TiDBメモリ制御](/configure-memory-usage.md)を参照してください。 @@ -4025,7 +4025,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 は手動および自動更新タスクの両方のメモリ使用量を制限しません。 > **注記：** > @@ -4069,7 +4069,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - TiDB v6.1.0 より前のバージョンでは、これはセッションスコープ変数であり、 `mem-quota-query`の`tidb.toml`の値を初期値として使用します。v6.1.0 以降では、 `tidb_mem_quota_query`は`SESSION | GLOBAL`スコープ変数です。 - TiDB v6.5.0 より前のバージョンでは、この変数は**クエリ**のメモリ割り当てのしきい値を設定するために使用されます。実行中にクエリのメモリ割り当てがしきい値を超えると、TiDB は[`tidb_mem_oom_action`](#tidb_mem_oom_action-new-in-v610)で定義された操作を実行します。 -- TiDB v6.5.0 以降のバージョンでは、この変数は**セッション**のメモリクォータのしきい値を設定するために使用されます。実行中にセッションのメモリクォータがしきい値を超えると、TiDB は[`tidb_mem_oom_action`](#tidb_mem_oom_action-new-in-v610)で定義された操作を実行します。TiDB v6.5.0 以降では、セッションのメモリ使用量には、セッション内のトランザクションによって消費されたメモリが含まれることに注意してください。TiDB v6.5.0 以降のバージョンにおけるトランザクションのメモリ使用量の制御動作については、 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)参照してください。 +- TiDB v6.5.0 以降のバージョンでは、この変数は**セッション**のメモリクォータのしきい値を設定するために使用されます。実行中にセッションのメモリクォータがしきい値を超えると、TiDB は[`tidb_mem_oom_action`](#tidb_mem_oom_action-new-in-v610)で定義された操作を実行します。TiDB v6.5.0 以降では、セッションのメモリ使用量には、セッション内のトランザクションによって消費されたメモリが含まれることに注意してください。TiDB v6.5.0 以降のバージョンにおけるトランザクションのメモリ使用量の制御動作については、 [`txn-total-size-limit`](/tidb-configuration-file.md#txn-total-size-limit)を参照してください。 - 変数の値を`0`または`-1`に設定すると、メモリのしきい値は正の無限大になります。128 より小さい値を設定すると、デフォルト値として`128`が使用されます。 @@ -4453,7 +4453,7 @@ mysql> desc select count(distinct a) from test.t; > **警告：** > -> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 +> この変数で制御される機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 - 範囲: セッション | グローバル - クラスターに保持される: はい @@ -4511,7 +4511,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[オプティマイザー修正コントロール](/optimizer-fix-controls.md)参照してください。 +- より詳細な概要については、[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 @@ -4524,7 +4524,7 @@ mysql> desc select count(distinct a) from test.t; - デフォルト値: `""` - この変数は、オプティマイザの内部動作の一部を制御するために使用されます。 - オプティマイザの動作は、ユーザーシナリオやSQLステートメントによって異なる場合があります。この変数を使用することで、オプティマイザをより細かく制御でき、オプティマイザの動作変更によってアップグレード後に発生するパフォーマンス低下を防ぐことができます。 -- より詳細な概要については、[オプティマイザー修正コントロール](/optimizer-fix-controls.md)参照してください。 +- より詳細な概要については、[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 @@ -5417,7 +5417,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 はv5.4.0 で追加されました。 {#tidb-persist-analyze-options-span-class-version-mark-new-in-v5-4-0-span} @@ -5671,7 +5671,7 @@ SHOW WARNINGS; - デフォルト値: `leader` - 指定可能な値: `leader` 、 `follower` 、 `leader-and-follower` 、 `prefer-leader` 、 `closest-replicas` 、 `closest-adaptive` 、および`learner` 。 `learner`の値は v6.6.0 で導入されました。 - この変数は、TiDBがデータを読み込む場所を制御するために使用されます。バージョン8.5.4以降、この変数は読み取り専用のSQL文にのみ有効です。 -- 使用方法と実装の詳細については、 [Follower Read](/follower-read.md)参照してください。 +- 使用方法と実装の詳細については、 [Follower Read](/follower-read.md)を参照してください。 ### tidb_restricted_read_only v5.2.0で追加 {#tidb-restricted-read-only-new-in-v520} @@ -5753,7 +5753,7 @@ SHOW WARNINGS; - 型: Enumeration - デフォルト値: `OFF` - 指定可能な値: `OFF` 、 `LOCAL` -- ランタイムフィルタのモード、つまり**フィルタ送信演算子**と**フィルタ受信演算子**の関係を制御します。モードは`OFF`と`LOCAL`の 2 つあります。 `OFF`はランタイムフィルタを無効にすることを意味します。 `LOCAL`はローカルモードでランタイムフィルタを有効にすることを意味します。詳細については、[ランタイムフィルタモード](/runtime-filter.md#runtime-filter-mode)参照してください。 +- ランタイムフィルタのモード、つまり**フィルタ送信演算子**と**フィルタ受信演算子**の関係を制御します。モードは`OFF`と`LOCAL`の 2 つあります。 `OFF`はランタイムフィルタを無効にすることを意味します。 `LOCAL`はローカルモードでランタイムフィルタを有効にすることを意味します。詳細については、[ランタイムフィルタモード](/runtime-filter.md#runtime-filter-mode)を参照してください。 ### tidb_runtime_filter_type v7.2.0で追加 {#tidb-runtime-filter-type-new-in-v720} @@ -5901,7 +5901,7 @@ SHOW WARNINGS; - 型: 整数 - デフォルト値: `0` - 範囲: `[0, 15]` -- この変数は、新しく作成されたテーブルのデフォルトの行 ID シャード数を設定するために使用されます。この変数にゼロ以外の値を設定すると、TiDB は`SHARD_ROW_ID_BITS`の使用を許可するテーブル (たとえば、 `NONCLUSTERED`テーブル) に対して、 `CREATE TABLE`ステートメントの実行時にこの属性を自動的に適用します。詳細については、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)参照してください。 +- この変数は、新しく作成されたテーブルのデフォルトの行 ID シャード数を設定するために使用されます。この変数にゼロ以外の値を設定すると、TiDB は`SHARD_ROW_ID_BITS`の使用を許可するテーブル (たとえば、 `NONCLUSTERED`テーブル) に対して、 `CREATE TABLE`ステートメントの実行時にこの属性を自動的に適用します。詳細については、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を参照してください。 ### tidb_simplified_metrics {#tidb-simplified-metrics} @@ -5992,7 +5992,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: "" - 型: String - この変数は、スロークエリログのトリガールールを定義します。多次元メトリクスを組み合わせることで、より柔軟で詳細なログ記録を実現します。 -- このシステム変数の使用方法の詳細については、 [`tidb_slow_log_rules`使用する](/identify-slow-queries.md#use-tidb_slow_log_rules)参照してください。 +- このシステム変数の使用方法の詳細については、 [`tidb_slow_log_rules`使用する](/identify-slow-queries.md#use-tidb_slow_log_rules)を参照してください。 > **ヒント：** > @@ -6027,7 +6027,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) -詳細については、[スロークエリを特定する](/identify-slow-queries.md)参照してください。 +詳細については、[スロークエリを特定する](/identify-slow-queries.md)を参照してください。 @@ -6102,7 +6102,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `100` - 範囲: `[0, 2147483647]` - 単位：ミリ秒 -- この変数は、同期的に統計情報を読み込む機能を有効にするかどうかを制御します。値`0`は、この機能が無効になっていることを意味します。この機能を有効にするには、この変数に、SQL 最適化が列統計情報を完全に同期的に読み込むために待機できる最大時間 (ミリ秒単位) を設定します。詳細については、[負荷統計](/statistics.md#load-statistics)参照してください。 +- この変数は、同期的に統計情報を読み込む機能を有効にするかどうかを制御します。値`0`は、この機能が無効になっていることを意味します。この機能を有効にするには、この変数に、SQL 最適化が列統計情報を完全に同期的に読み込むために待機できる最大時間 (ミリ秒単位) を設定します。詳細については、[負荷統計](/statistics.md#load-statistics)を参照してください。 ### tidb_stmt_summary_enable_persistent v6.6.0で追加 {#tidb-stmt-summary-enable-persistent-new-in-v660} @@ -6690,7 +6690,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 指定可能な値: `OFF` 、 `FAST` 、 `STRICT` -- この変数はアサーション レベルを制御するために使用されます。アサーションは、データとインデックス間の整合性チェックであり、書き込まれるキーがトランザクションのコミット プロセスに存在するかどうかをチェックします。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)参照してください。 +- この変数はアサーション レベルを制御するために使用されます。アサーションは、データとインデックス間の整合性チェックであり、書き込まれるキーがトランザクションのコミット プロセスに存在するかどうかをチェックします。詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)を参照してください。 - `OFF` : このチェックを無効にします。 - `FAST` : パフォーマンスへの影響はほとんどなく、ほとんどのチェック項目を有効にします。 @@ -6957,7 +6957,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - 型: Enumeration - デフォルト値: `REPEATABLE-READ` - 指定可能な値: `READ-UNCOMMITTED` 、 `READ-COMMITTED` 、 `REPEATABLE-READ` 、 `SERIALIZABLE` -- この変数はトランザクションの分離を設定します。 TiDB は MySQL との互換性のために`REPEATABLE-READ`を宣伝していますが、実際の分離レベルはスナップショット分離です。詳細については、[トランザクション分離レベル](/transaction-isolation-levels.md)参照してください。 +- この変数はトランザクションの分離を設定します。 TiDB は MySQL との互換性のために`REPEATABLE-READ`を宣伝していますが、実際の分離レベルはスナップショット分離です。詳細については、[トランザクション分離レベル](/transaction-isolation-levels.md)を参照してください。 ### tx_isolation {#tx-isolation} diff --git a/temporary-tables.md b/temporary-tables.md index f27b9d0951e51..34170fd447797 100644 --- a/temporary-tables.md +++ b/temporary-tables.md @@ -226,7 +226,7 @@ SELECT * FROM users; テーブル定義時にどのストレージエンジンを`ENGINE`として宣言したとしても、ローカル一時テーブルとグローバル一時テーブルのデータはTiDBインスタンスのメモリ内にのみ保存されます。これらのデータは永続化されません。 -メモリオーバーフローを回避するために、システム変数[`tidb_tmp_table_max_size`](/system-variables.md#tidb_tmp_table_max_size-new-in-v530)使用して各一時テーブルのサイズを制限できます。一時テーブルのサイズがしきい値`tidb_tmp_table_max_size`を超えると、TiDB はエラーを報告します。デフォルト値は`tidb_tmp_table_max_size`ですが、現在は`64MB`です。 +メモリオーバーフローを回避するために、システム変数[`tidb_tmp_table_max_size`](/system-variables.md#tidb_tmp_table_max_size-new-in-v530)を使用して各一時テーブルのサイズを制限できます。一時テーブルのサイズがしきい値`tidb_tmp_table_max_size`を超えると、TiDB はエラーを報告します。デフォルト値は`tidb_tmp_table_max_size`ですが、現在は`64MB`です。 たとえば、一時テーブルの最大サイズを`256MB`に設定します。 diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 27163e42dfe89..892a4150fd60d 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -194,7 +194,7 @@ tikv_servers: > **注記：** > - > TiDB v5.2以降、 `label-property`構成はデフォルトではサポートされません。レプリカポリシーを設定するには、 [配置ルール](/configure-placement-rules.md)使用してください。 + > TiDB v5.2以降、 `label-property`構成はデフォルトではサポートされません。レプリカポリシーを設定するには、 [配置ルール](/configure-placement-rules.md)を使用してください。 - PDの優先度を設定します。PDリーダーが別のリージョン（AZ3）にある状況を回避するには、ローカルPD（シアトル）の優先度を上げ、別のリージョン（サンフランシスコ）のPDの優先度を下げることができます。数値が大きいほど優先度が高くなります。利用可能なすべてのPDノードの中で、優先度が最も高いノードがリーダーになります。 diff --git a/ticdc-deployment-topology.md b/ticdc-deployment-topology.md index b6e91d81047c1..4764dd17d5ce2 100644 --- a/ticdc-deployment-topology.md +++ b/ticdc-deployment-topology.md @@ -32,7 +32,7 @@ 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)を参照してください。 > **注記：** > diff --git a/ticdc-performance-tuning-methods.md b/ticdc-performance-tuning-methods.md index dbcaab6959181..2cb5ad928dbde 100644 --- a/ticdc-performance-tuning-methods.md +++ b/ticdc-performance-tuning-methods.md @@ -36,7 +36,7 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ - Changefeed 解決 ts ラグ: TiCDC ノードの内部レプリケーション状態と上流との間の進捗ラグ（秒単位）。このメトリックが高い場合、TiCDC Puller または Sorter モジュールのデータ処理能力が不足しているか、ネットワークレイテンシーやディスクの読み取り/書き込み速度の低下などの問題が発生している可能性があります。このような場合、TiCDC の効率的かつ安定した運用を確保するには、TiCDC ノードの数を増やす、ネットワーク構成を最適化するなどの適切な対策を講じる必要があります。 -- changefeed のステータス: changefeed のステータスの説明については、 [チェンジフィード状態転送](/ticdc/ticdc-changefeed-overview.md)参照してください。 +- changefeed のステータス: changefeed のステータスの説明については、 [チェンジフィード状態転送](/ticdc/ticdc-changefeed-overview.md)を参照してください。 例1: 単一のTiCDCノードの場合、上流QPSが高いためにチェックポイントの遅延が大きくなる diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index bc7e17568fe06..74b8fbbd91b64 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -35,7 +35,7 @@ cdc_servers: - 詳しい操作については、 [初期化設定ファイルを編集します](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)ご覧ください。 - 設定可能なフィールドの詳細については、 [TiUPを使用して`cdc_servers`を設定する](/tiup/tiup-cluster-topology-reference.md#cdc_servers)を参照してください。 -- TiDB クラスターを展開する詳細な手順については、 [TiUPを使用してTiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +- TiDB クラスターを展開する詳細な手順については、 [TiUPを使用してTiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 > **注記：** > @@ -66,7 +66,7 @@ TiCDCクラスタのスケールアウト方法は、新規デプロイ方法と tiup cluster scale-out scale-out.yml ``` -その他の使用例については、 [TiCDCクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-ticdc-cluster)参照してください。 +その他の使用例については、 [TiCDCクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-ticdc-cluster)を参照してください。 ## TiUPを使用して既存のTiDBクラスタからTiCDCを削除またはスケーリングする {#delete-or-scale-in-ticdc-from-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以降です。 @@ -141,7 +141,7 @@ TiUPを使用すると、TiCDCノードを簡単に停止および起動でき ## TiCDCでTLSを有効にする {#enable-tls-for-ticdc} -[TiDBコンポーネント間でTLSを有効にする](/enable-tls-between-components.md)参照してください。 +[TiDBコンポーネント間でTLSを有効にする](/enable-tls-between-components.md)を参照してください。 ## コマンドラインツールを使用してTiCDCのステータスを表示する {#view-ticdc-status-using-the-command-line-tool} diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 606d4f9738ac1..91df3335a161f 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -7,7 +7,7 @@ summary: TiDB データを Confluent Cloud、Snowflake、ksqlDB、SQL Server に Confluentは、Apache Kafka互換のストリーミングデータプラットフォームであり、強力なデータ統合機能を提供します。このプラットフォームでは、ノンストップのリアルタイムストリーミングデータにアクセス、保存、管理できます。 -TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプリケーションをサポートします。本ドキュメントでは、 [TiCDC](/ticdc/ticdc-overview.md)使用してTiDBの増分データをConfluentにレプリケーションし、さらにConfluent Cloud経由でSnowflake、ksqlDB、SQL Serverにデータをレプリケーションする方法を紹介します。本ドキュメントの構成は以下のとおりです。 +TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプリケーションをサポートします。本ドキュメントでは、 [TiCDC](/ticdc/ticdc-overview.md)を使用してTiDBの増分データをConfluentにレプリケーションし、さらにConfluent Cloud経由でSnowflake、ksqlDB、SQL Serverにデータをレプリケーションする方法を紹介します。本ドキュメントの構成は以下のとおりです。 1. TiCDC が組み込まれた TiDB クラスターを迅速に展開します。 2. TiDB から Confluent Cloud にデータを複製する変更フィードを作成します。 @@ -34,7 +34,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ 2. Confluent Cloud を登録し、Confluent クラスターを作成します。 - ベーシッククラスタを作成し、インターネット経由でアクセスできるようにします。詳細は[Confluent Cloud のクイックスタート](https://docs.confluent.io/cloud/current/get-started/index.html)参照してください。 + ベーシッククラスタを作成し、インターネット経由でアクセスできるようにします。詳細は[Confluent Cloud のクイックスタート](https://docs.confluent.io/cloud/current/get-started/index.html)を参照してください。 ### ステップ2. アクセスキーペアを作成する {#step-2-create-an-access-key-pair} @@ -73,7 +73,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ API secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx - この手順はConfluent CLIを使用して実行することもできます。詳細については[Confluent CLI を Confluent Cloudクラスタに接続する](https://docs.confluent.io/confluent-cli/current/connect.html)参照してください。 + この手順はConfluent CLIを使用して実行することもできます。詳細については[Confluent CLI を Confluent Cloudクラスタに接続する](https://docs.confluent.io/confluent-cli/current/connect.html)を参照してください。 ### ステップ3. Kafkaの変更フィードを作成する {#step-3-create-a-kafka-changefeed} @@ -86,7 +86,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ {matcher = ['*.*'], topic = "tidb_{schema}_{table}", partition="index-value"}, ] - 設定ファイルの`dispatchers`の詳細な説明については[Kafka シンクのトピックおよびパーティションディスパッチャーのルールをカスタマイズする](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink)参照してください。 + 設定ファイルの`dispatchers`の詳細な説明については[Kafka シンクのトピックおよびパーティションディスパッチャーのルールをカスタマイズする](/ticdc/ticdc-sink-to-kafka.md#customize-the-rules-for-topic-and-partition-dispatchers-of-kafka-sink)を参照してください。 2. 増分データを Confluent Cloud に複製するための変更フィードを作成します。 @@ -119,7 +119,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ Info: {... changfeed info json struct ...} ``` - - コマンドを実行しても結果が返されない場合は、コマンドを実行したサーバーとConfluent Cloud間のネットワーク接続を確認してください。詳細は[Confluent Cloudへの接続をテストする](https://docs.confluent.io/cloud/current/networking/testing.html)参照してください。 + - コマンドを実行しても結果が返されない場合は、コマンドを実行したサーバーとConfluent Cloud間のネットワーク接続を確認してください。詳細は[Confluent Cloudへの接続をテストする](https://docs.confluent.io/cloud/current/networking/testing.html)を参照してください。 3. changefeed を作成した後、次のコマンドを実行して changefeed のステータスを確認します。 @@ -156,8 +156,8 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co ### 前提条件 {#prerequisites} -- Snowflakeクラスターの登録と作成が完了しました[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)参照してください。 -- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。1 [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)参照してください。 +- Snowflakeクラスターの登録と作成が完了しました[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)を参照してください。 +- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。1 [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)を参照してください。 ### 統合手順 {#integration-procedure} diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index cb07ddd01f2b5..17f8e7da6e6d7 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -53,7 +53,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 解決： - このアラートはレプリケーションの中断に似ています。1 [TiCDC はレプリケーションの中断を処理します](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-replication-interruptions)参照してください。 + このアラートはレプリケーションの中断に似ています。1 [TiCDC はレプリケーションの中断を処理します](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-replication-interruptions)を参照してください。 ## 警告アラート {#warning-alerts} @@ -155,7 +155,7 @@ summary: TiCDC アラート ルールとアラートの処理方法について - 解決： - 考えられる根本原因は多数あります。1 [TiCDC のトラブルシューティング](/ticdc/troubleshoot-ticdc.md)参照してください。 + 考えられる根本原因は多数あります。1 [TiCDC のトラブルシューティング](/ticdc/troubleshoot-ticdc.md)を参照してください。 ### `ticdc_memory_abnormal` {#ticdc-memory-abnormal} diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index 09e8255096214..9fed90d3611d2 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -141,7 +141,7 @@ cdc_servers: newarch: true ``` -TiCDC デプロイメントの詳細については、 [TiUPを使用してTiCDCを含む新しいTiDBクラスタをデプロイ](/ticdc/deploy-ticdc.md#deploy-a-new-tidb-cluster-that-includes-ticdc-using-tiup)参照してください。 +TiCDC デプロイメントの詳細については、 [TiUPを使用してTiCDCを含む新しいTiDBクラスタをデプロイ](/ticdc/deploy-ticdc.md#deploy-a-new-tidb-cluster-that-includes-ticdc-using-tiup)を参照してください。
@@ -158,7 +158,7 @@ spec: newarch = true ``` -TiCDC 導入の詳細については、 [TiCDCの新規導入](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#fresh-ticdc-deployment)参照してください。 +TiCDC 導入の詳細については、 [TiCDCの新規導入](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#fresh-ticdc-deployment)を参照してください。
@@ -219,7 +219,7 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテクチャでTiCDCノードをデプロイするには、次の手順を実行します。 -- TiDB クラスターに TiCDCコンポーネントが含まれていない場合は、 [既存のTiDBクラスタにTiCDCを追加する](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#add-ticdc-to-an-existing-tidb-cluster)を参照して、新しい TiCDC ノードを追加します。その際、クラスター構成ファイルで TiCDC イメージのバージョンを新しいアーキテクチャのバージョンとして指定します。利用可能なバージョンについては、 [TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)参照してください。 +- TiDB クラスターに TiCDCコンポーネントが含まれていない場合は、 [既存のTiDBクラスタにTiCDCを追加する](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#add-ticdc-to-an-existing-tidb-cluster)を参照して、新しい TiCDC ノードを追加します。その際、クラスター構成ファイルで TiCDC イメージのバージョンを新しいアーキテクチャのバージョンとして指定します。利用可能なバージョンについては、 [TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)を参照してください。 例えば： @@ -294,10 +294,10 @@ cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="mysql://roo cdc cli changefeed query -s --server=http://127.0.0.1:8300 --changefeed-id=simple-replication-task ``` -コマンドの使用方法と詳細については、[変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md)参照してください。 +コマンドの使用方法と詳細については、[変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md)を参照してください。 ## 監視 {#monitoring} 新しいアーキテクチャにおける TiCDC の監視ダッシュボードは**、TiCDC-New-Arch**です。TiDB クラスタのバージョンが v8.5.4 以降の場合、この監視ダッシュボードはクラスタのデプロイまたはアップグレード時に Grafana に統合されるため、手動操作は不要です。クラスタのバージョンが v8.5.4 より前の場合は、監視を有効にするために[TiCDC監視メトリクスファイル](https://github.com/pingcap/ticdc/blob/master/metrics/grafana/ticdc_new_arch.json)を手動でインポートする必要があります。 -インポート手順と各監視メトリクスの詳細な説明については、 [新アーキテクチャにおけるTiCDCのメトリクス](/ticdc/monitor-ticdc.md#metrics-for-ticdc-in-the-new-architecture)参照してください。 +インポート手順と各監視メトリクスの詳細な説明については、 [新アーキテクチャにおけるTiCDCのメトリクス](/ticdc/monitor-ticdc.md#metrics-for-ticdc-in-the-new-architecture)を参照してください。 diff --git a/ticdc/ticdc-avro-protocol.md b/ticdc/ticdc-avro-protocol.md index 4d7a7e9fef89e..6b80286c4af2a 100644 --- a/ticdc/ticdc-avro-protocol.md +++ b/ticdc/ticdc-avro-protocol.md @@ -292,4 +292,4 @@ TiCDC Avro プロトコルは[`io.confluent.kafka.serializers.KafkaAvroDeseriali ## 互換性 {#compatibility} -TiCDC クラスターを v7.0.0 にアップグレードする際、Avro を使用してレプリケートされたテーブルに`FLOAT`データ型が含まれている場合は、アップグレード前に Confluent Schema Registry の互換性ポリシーを手動で`None`に調整し、changefeed がスキーマを正常に更新できるようにする必要があります。そうしないと、アップグレード後に changefeed がスキーマを更新できなくなり、エラー状態になります。詳細については、 [＃8490](https://github.com/pingcap/tiflow/issues/8490)参照してください。 +TiCDC クラスターを v7.0.0 にアップグレードする際、Avro を使用してレプリケートされたテーブルに`FLOAT`データ型が含まれている場合は、アップグレード前に Confluent Schema Registry の互換性ポリシーを手動で`None`に調整し、changefeed がスキーマを正常に更新できるようにする必要があります。そうしないと、アップグレード後に changefeed がスキーマを更新できなくなり、エラー状態になります。詳細については、 [＃8490](https://github.com/pingcap/tiflow/issues/8490)を参照してください。 diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index e8239d0e109f0..c45881120ba04 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -159,7 +159,7 @@ BDRロールが設定されていない場合、任意のDDLを実行できま > > 他のシナリオではBDRロールを設定しないでください。例えば、BDRロールを`PRIMARY` 、 `SECONDARY` 、そして0つを同時に設定しないでください。BDRロールを誤って設定すると、TiDBはデータレプリケーション中にデータの正確性と一貫性を保証できません。 -- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 +- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)を使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 - クラスタAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`設定します - クラスタBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`設定します diff --git a/ticdc/ticdc-canal-json.md b/ticdc/ticdc-canal-json.md index 26179c694c7f4..8389a96055508 100644 --- a/ticdc/ticdc-canal-json.md +++ b/ticdc/ticdc-canal-json.md @@ -176,7 +176,7 @@ Canal-JSON 形式では、対応するデータ型が`mysqlType`フィールド ### MySQLタイプフィールド {#mysql-type-field} -Canal-JSON形式は、 `mysqlType`フィールドの各列にMySQL Typeの文字列を記録します。詳細については、 [TiDB データ型](/data-type-overview.md)参照してください。 +Canal-JSON形式は、 `mysqlType`フィールドの各列にMySQL Typeの文字列を記録します。詳細については、 [TiDB データ型](/data-type-overview.md)を参照してください。 ### SQLタイプフィールド {#sql-type-field} @@ -253,7 +253,7 @@ Canal-JSON形式の`sqlType`のフィールドには、各列のJava SQL型が | TINYINT | -6 | | BIT | -7 | -Java SQL 型の詳細については、 [Java SQL クラス型](https://docs.oracle.com/javase/8/docs/api/java/sql/Types.html)参照してください。 +Java SQL 型の詳細については、 [Java SQL クラス型](https://docs.oracle.com/javase/8/docs/api/java/sql/Types.html)を参照してください。 ## バイナリ型とBlob型 {#binary-and-blob-types} diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index 245ee0ed8a73a..0a7ae8baad709 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -82,7 +82,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl ### `bdr-mode` {#bdr-mode} -- TiCDC を使用して BDR (双方向レプリケーション) クラスターをセットアップするには、このパラメーターを`true`に変更し、TiDB クラスターを BDR モードに設定します。詳細については、 [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md#bidirectional-replication)参照してください。 +- TiCDC を使用して BDR (双方向レプリケーション) クラスターをセットアップするには、このパラメーターを`true`に変更し、TiDB クラスターを BDR モードに設定します。詳細については、 [双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md#bidirectional-replication)を参照してください。 - デフォルト値： `false` 。双方向レプリケーション（BDR）モードが有効になっていないことを示します。 ### `changefeed-error-stuck-duration` {#changefeed-error-stuck-duration} @@ -254,7 +254,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl #### `date-separator` {#date-separator} -- ファイル ディレクトリで使用される日付区切り文字のタイプを指定します。詳細については、 [データ変更記録](/ticdc/ticdc-sink-to-cloud-storage.md#data-change-records)参照してください。 +- ファイル ディレクトリで使用される日付区切り文字のタイプを指定します。詳細については、 [データ変更記録](/ticdc/ticdc-sink-to-cloud-storage.md#data-change-records)を参照してください。 - この設定項目は、ダウンストリームがストレージサービスである場合にのみ有効になります。 - デフォルト値: `day` 、ファイルを日付ごとに分割することを意味します。 - 値のオプション: `none` 、 `year` 、 `month` 、 `day` @@ -264,7 +264,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl - パーティションを区切り文字として使用するかどうかを制御します。 - この設定項目は、ダウンストリームがストレージサービスである場合にのみ有効になります。 - デフォルト値： `true` 。これは、テーブル内のパーティションが別々のディレクトリに保存されることを意味します。 -- この設定は将来のバージョンで非推奨となり、 `true`に強制的に設定されますのでご注意ください。下流のパーティションテーブルでのデータ損失を防ぐため、この設定はデフォルト値のままにしておくことをお勧めします。詳細については、 [第11979号](https://github.com/pingcap/tiflow/issues/11979)を参照してください。使用例については、データ[データ変更記録](/ticdc/ticdc-sink-to-cloud-storage.md#data-change-records)参照してください。 +- この設定は将来のバージョンで非推奨となり、 `true`に強制的に設定されますのでご注意ください。下流のパーティションテーブルでのデータ損失を防ぐため、この設定はデフォルト値のままにしておくことをお勧めします。詳細については、 [第11979号](https://github.com/pingcap/tiflow/issues/11979)を参照してください。使用例については、データ[データ変更記録](/ticdc/ticdc-sink-to-cloud-storage.md#data-change-records)を参照してください。 #### `debezium-disable-schema` {#debezium-disable-schema} @@ -472,7 +472,7 @@ REDO ログを使用する場合の変更フィードのレプリケーション #### `output-raw-change-event` {#output-raw-change-event} -- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 +- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)を参照してください。 - デフォルト値: `false` ### sink.kafka-config.glue-schema-registry-config {#sink-kafka-config-glue-schema-registry-config} @@ -487,7 +487,7 @@ secret-access-key="xxxx" token="xxxx" ``` -詳細については、 [TiCDCをAWS Glueスキーマレジストリと統合する](/ticdc/ticdc-sink-to-kafka.md#integrate-ticdc-with-aws-glue-schema-registry)参照してください。 +詳細については、 [TiCDCをAWS Glueスキーマレジストリと統合する](/ticdc/ticdc-sink-to-kafka.md#integrate-ticdc-with-aws-glue-schema-registry)を参照してください。 ### sink.pulsar-config {#sink-pulsar-config} @@ -584,7 +584,7 @@ token="xxxx" #### `output-raw-change-event` {#output-raw-change-event} -- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 +- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)を参照してください。 - デフォルト値: `false` ### sink.cloud-storage-config {#sink-cloud-storage-config} @@ -623,5 +623,5 @@ token="xxxx" #### `output-raw-change-event` {#output-raw-change-event} -- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 +- 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [主キーまたは一意キーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)を参照してください。 - デフォルト値: `false` diff --git a/ticdc/ticdc-changefeed-overview.md b/ticdc/ticdc-changefeed-overview.md index f83a3283cde69..86c0dc7cec449 100644 --- a/ticdc/ticdc-changefeed-overview.md +++ b/ticdc/ticdc-changefeed-overview.md @@ -40,8 +40,8 @@ summary: チェンジフィードの基本的な概念、状態の定義、お ## チェンジフィードを操作する {#operate-changefeeds} -TiCDCクラスターとそのレプリケーションタスクは、コマンドラインツール`cdc cli`使用して管理できます。詳細については、 [TiCDC の変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md)参照してください。 +TiCDCクラスターとそのレプリケーションタスクは、コマンドラインツール`cdc cli`使用して管理できます。詳細については、 [TiCDC の変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md)を参照してください。 -HTTPインターフェース（TiCDC OpenAPI機能）を使用して、TiCDCクラスターとそのレプリケーションタスクを管理することもできます。詳細については、 [TiCDC オープンAPI](/ticdc/ticdc-open-api.md)参照してください。 +HTTPインターフェース（TiCDC OpenAPI機能）を使用して、TiCDCクラスターとそのレプリケーションタスクを管理することもできます。詳細については、 [TiCDC オープンAPI](/ticdc/ticdc-open-api.md)を参照してください。 TiCDC がTiUPを使用してデプロイされている場合は、 `tiup cdc:v cli`コマンドを実行することで`cdc cli`起動できます。 `v` TiCDC クラスターのバージョン（例： `v8.5.3` ）に置き換えてください。 `cdc cli`直接実行することもできます。 diff --git a/ticdc/ticdc-classic-architecture.md b/ticdc/ticdc-classic-architecture.md index 74d66a9917c4e..c3c60f651a6c1 100644 --- a/ticdc/ticdc-classic-architecture.md +++ b/ticdc/ticdc-classic-architecture.md @@ -57,7 +57,7 @@ TiCDCにおけるChangefeedとTaskは、2つの論理的な概念です。具体 {matcher = ['test3.tab3', 'test4.tab4'], topic = "{schema}_{table}"}, ] -前述の`cdc cli changefeed create`コマンドのパラメータの詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 +前述の`cdc cli changefeed create`コマンドのパラメータの詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 上記のコマンド`cdc cli changefeed create`は、 `test1.tab1` 、 `test1.tab2` 、 `test3.tab3` 、 `test4.tab4` Kafkaクラスターに複製する changefeed タスクを作成します。TiCDCがこのコマンドを受信した後の処理フローは以下のとおりです。 diff --git a/ticdc/ticdc-client-authentication.md b/ticdc/ticdc-client-authentication.md index d4def7b98e9e8..3867b8e0918a0 100644 --- a/ticdc/ticdc-client-authentication.md +++ b/ticdc/ticdc-client-authentication.md @@ -31,7 +31,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB
- [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)使用する場合、以下の方法でクライアント証明書を指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 + [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)を使用する場合、以下の方法でクライアント証明書を指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 1. コマンドラインパラメータ`--cert`と`--key`使用して、証明書と秘密鍵を指定します。サーバーが自己署名証明書を使用している場合は、パラメータ`--ca`を使用して信頼できる CA 証明書も指定する必要があります。 @@ -53,7 +53,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB
- [TiCDC オープンAPI](/ticdc/ticdc-open-api-v2.md)使用する場合、 `--cert`と`--key`使用してクライアント証明書と秘密鍵を指定できます。サーバーが自己署名証明書を使用する場合は、 `--cacert`パラメータを使用して信頼されたCA証明書も指定する必要があります。例： + [TiCDC オープンAPI](/ticdc/ticdc-open-api-v2.md)を使用する場合、 `--cert`と`--key`使用してクライアント証明書と秘密鍵を指定できます。サーバーが自己署名証明書を使用する場合は、 `--cacert`パラメータを使用して信頼されたCA証明書も指定する必要があります。例： ```bash curl -X GET http://127.0.0.1:8300/api/v2/status --cert client.crt --key client.key --cacert ca.crt @@ -85,7 +85,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB
- [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)使用する場合、以下の方法でユーザー名とパスワードを指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 + [TiCDC コマンドラインツール](/ticdc/ticdc-manage-changefeed.md)を使用する場合、以下の方法でユーザー名とパスワードを指定できます。TiCDC は以下の順序でクライアント証明書の読み取りを試みます。 1. コマンドラインパラメータ`--user`と`--password`使用してユーザー名とパスワードを指定します。 @@ -112,7 +112,7 @@ v8.1.0 以降、TiCDC は Mutual Transport Layer Security (mTLS) または TiDB
- [TiCDC オープンAPI](/ticdc/ticdc-open-api-v2.md)使用する場合は、 `--user :`を使用してユーザー名とパスワードを指定できます。例: + [TiCDC オープンAPI](/ticdc/ticdc-open-api-v2.md)を使用する場合は、 `--user :`を使用してユーザー名とパスワードを指定できます。例: ```bash curl -X GET http://127.0.0.1:8300/api/v2/status --user test:password diff --git a/ticdc/ticdc-compatibility.md b/ticdc/ticdc-compatibility.md index 9d522157f4b22..4c2df203ff65d 100644 --- a/ticdc/ticdc-compatibility.md +++ b/ticdc/ticdc-compatibility.md @@ -17,20 +17,20 @@ 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)参照してください。 +1. チェンジフィードを作成します。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)を参照してください。 +2. TiDB Lightningを起動し、論理インポート モードを使用してデータをインポートします。詳細については、 [論理インポートモードを使用する](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md)を参照してください。 物理インポートモードでは、 TiDB Lightning はSST ファイルを TiKV に挿入することでデータをインポートします。TiCDC はこのモードと互換性がなく、物理インポートモードでインポートされたデータの複製をサポートしていません。TiDB Lightning の物理インポートモードと TiCDC の両方を使用する必要がある場合は、ダウンストリームシステムに基づいて、以下のいずれかのソリューションを選択してください。 - ダウンストリームがTiDBクラスタである場合は、以下の手順を実行してください。 1. データの一貫性を確保するため、 TiDB Lightningを使用してデータをアップストリームとダウンストリームの両方のTiDBクラスタにインポートしてください。 - 2. 変更フィードを作成して、SQL を通じて書き込まれた後続の増分データをレプリケートします。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)参照してください。 + 2. 変更フィードを作成して、SQL を通じて書き込まれた後続の増分データをレプリケートします。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)を参照してください。 - ダウンストリームがTiDBクラスタでない場合は、以下の手順を実行してください。 1. TiDB Lightningの入力ファイルをインポートするには、ダウンストリームシステムが提供するオフラインインポートツールを使用してください。 - 2. 変更フィードを作成して、SQL を通じて書き込まれた後続の増分データをレプリケートします。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)参照してください。 + 2. 変更フィードを作成して、SQL を通じて書き込まれた後続の増分データをレプリケートします。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)を参照してください。 ## TiFlashとの互換性 {#compatibility-with-tiflash} @@ -75,12 +75,12 @@ tiup cdc:v8.5.5 cli changefeed resume \ TiCDCの新しいアーキテクチャは、 TiDBのローリングアップグレード中に変更フィードの実行を継続できますが、そのためには、アップグレード前にTiCDCが既に新しいアーキテクチャを使用している場合に限ります。 -TiCDC クラシック アーキテクチャと新しいアーキテクチャの間でアップグレードまたは切り替える必要がある場合は、 [アップグレードガイド](/ticdc/ticdc-architecture.md#upgrade-guide)参照してください。 +TiCDC クラシック アーキテクチャと新しいアーキテクチャの間でアップグレードまたは切り替える必要がある場合は、 [アップグレードガイド](/ticdc/ticdc-architecture.md#upgrade-guide)を参照してください。 ## CLIと設定ファイルの互換性 {#cli-and-configuration-file-compatibility} - TiCDC v4.0.0では、 `ignore-txn-commit-ts`が削除され、 `ignore-txn-start-ts`が追加されました。これは`start_ts`を使用してトランザクションをフィルタリングします。 -- TiCDC v4.0.2 では、 `db-dbs` / `db-tables` / `ignore-dbs` / `ignore-tables`が削除され、 `rules`が追加されました。これは、データベースとテーブルに新しいフィルタルールを使用します。フィルタ構文の詳細については、[テーブルフィルター](/table-filter.md)参照してください。 +- TiCDC v4.0.2 では、 `db-dbs` / `db-tables` / `ignore-dbs` / `ignore-tables`が削除され、 `rules`が追加されました。これは、データベースとテーブルに新しいフィルタルールを使用します。フィルタ構文の詳細については、[テーブルフィルター](/table-filter.md)を参照してください。 - TiCDC v6.2.0 以降、 `cdc cli`は TiCDC Open API を介して TiCDCサーバーと直接やり取りし、PD へのアクセスは不要です。 `--pd`サブコマンドの`cdc cli`パラメータは非推奨となり、TiCDCサーバーアドレスを指定するために`--server`パラメータが追加されました。 `--server` `--pd` } を使用してください。 - バージョン6.4.0以降、 `SYSTEM_VARIABLES_ADMIN`または`SUPER`の権限を持つチェンジフィードのみがTiCDC Syncpoint機能を使用できます。 diff --git a/ticdc/ticdc-csv.md b/ticdc/ticdc-csv.md index 017fcbaef3f5a..2f1dc97fcd901 100644 --- a/ticdc/ticdc-csv.md +++ b/ticdc/ticdc-csv.md @@ -39,7 +39,7 @@ output-field-header = false # New in v8.5.6 (only available in the TiCDC new arc ## データストレージパス構造 {#data-storage-path-structure} -データのストレージパス構造の詳細については、 [ストレージパス構造](/ticdc/ticdc-sink-to-cloud-storage.md#storage-path-structure)参照してください。 +データのストレージパス構造の詳細については、 [ストレージパス構造](/ticdc/ticdc-sink-to-cloud-storage.md#storage-path-structure)を参照してください。 ## データ形式の定義 {#definition-of-the-data-format} diff --git a/ticdc/ticdc-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index 468bb086c0484..2bdb9d54c89e8 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -11,7 +11,7 @@ summary: TiCDC のデータ複製機能について学びます。 - TiCDCはTiKV変更ログ（Raftログ）をリッスンし、行レベルのデータ変更（ `INSERT` `DELETE`操作）を下流と互換性のあるSQL文に変換します。TiCDCは上流データベースで実行された元のSQL文に依存しません。詳細については[TiCDCがデータ変更を処理する方法](/ticdc/ticdc-overview.md#implementation-of-processing-data-changes) `UPDATE`してください。 -- TiCDCは`UPDATE` `INSERT` `DELETE`を生成します。詳細については[TiCDCがデータ変更を処理する方法](/ticdc/ticdc-overview.md#implementation-of-processing-data-changes)参照してください。 +- TiCDCは`UPDATE` `INSERT` `DELETE`を生成します。詳細については[TiCDCがデータ変更を処理する方法](/ticdc/ticdc-overview.md#implementation-of-processing-data-changes)を参照してください。 - TiCDCはトランザクションの最終的な一貫性を保証します。1 [再実行ログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)有効にすると、TiCDCは災害復旧シナリオにおいて最終的な一貫性を保証できます。3 [同期ポイント](/ticdc/ticdc-upstream-downstream-check.md#enable-syncpoint)有効にすると、TiCDCは一貫性のあるスナップショット読み取りとデータ整合性の検証をサポートします。 @@ -44,7 +44,7 @@ TiCDC は、次の種類のアップストリーム データの変更をサポ ## 制限事項 {#limitations} -- TiCDCは特定のシナリオをサポートしていません。詳細については[サポートされていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)参照してください。 +- TiCDCは特定のシナリオをサポートしていません。詳細については[サポートされていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)を参照してください。 - TiCDCは上流データの変更の整合性のみを検証します。変更が上流または下流の制約に準拠しているかどうかは検証しません。データが下流の制約に違反している場合、TiCDCは下流への書き込み時にエラーを返します。 diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 8b4d6c129c7bc..6abe612a3d62a 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -47,7 +47,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 ``` - `checkpoint` : TiCDC はこのタイムスタンプより前のすべてのデータをダウンストリームに複製しました。 -- `state` : このレプリケーションタスクの状態。各状態とその意味の詳細については、 [チェンジフィードの状態](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer)参照してください。 +- `state` : このレプリケーションタスクの状態。各状態とその意味の詳細については、 [チェンジフィードの状態](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer)を参照してください。 > **注記：** > @@ -63,7 +63,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 > > 現在の時刻を返す`NOW()`ような関数を使用する代わりに、 [`TIDB_CURRENT_TSO()`](/functions-and-operators/tidb-functions.md#tidb_current_tso)関数を使用して現在の TSO を取得します。 - 次の例では、 [`TIDB_PARSE_TSO()`](/functions-and-operators/tidb-functions.md#tidb_parse_tso)使用して、TSO を読み取り可能な時刻形式に変換し、さらに比較します。 + 次の例では、 [`TIDB_PARSE_TSO()`](/functions-and-operators/tidb-functions.md#tidb_parse_tso)を使用して、TSO を読み取り可能な時刻形式に変換し、さらに比較します。 ```sql BEGIN; @@ -314,7 +314,7 @@ TiCDC v6.2以降、単一テーブルトランザクションを複数のトラ 上記のエラーが引き続き発生する場合は、 BRを使用して大規模トランザクションの増分データを復元することをお勧めします。詳細な手順は次のとおりです。 -1. 大規模トランザクションにより終了した changefeed の`checkpoint-ts`記録し、この TSO をBR増分バックアップの`--lastbackupts`として使用して[増分データバックアップ](/br/br-incremental-guide.md#back-up-incremental-data)実行します。 +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`から開始します。 @@ -389,7 +389,7 @@ TiDB Lightning物理インポート モードによってインポートされ ## 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 はバージョンに応じて互換性を異なる方法で処理します。 @@ -466,7 +466,7 @@ TiDBにはトランザクションタイムアウト機構があります。ト > **注記：** > -> 保存された生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 +> 保存された生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)を使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 ## 頻繁に発生するCDC:ErrMySQLDuplicateEntryCDCエラーを解決するにはどうすればよいですか? {#how-do-i-resolve-frequent-code-cdc-errmysqlduplicateentrycdc-code-errors} diff --git a/ticdc/ticdc-filter.md b/ticdc/ticdc-filter.md index 9c3013cfbaeec..ede390f958cbf 100644 --- a/ticdc/ticdc-filter.md +++ b/ticdc/ticdc-filter.md @@ -30,7 +30,7 @@ rules = ['*.*', '!test.*'] - `rules = ['scm1.tidb_*']` - `scm1`データベース内の、名前が`tidb_`で始まるすべてのテーブルを複製します。 -詳細については[テーブルフィルタ構文](/table-filter.md#syntax)参照してください。 +詳細については[テーブルフィルタ構文](/table-filter.md#syntax)を参照してください。 ## イベントフィルタールール {#event-filter-rules} diff --git a/ticdc/ticdc-glossary.md b/ticdc/ticdc-glossary.md index e3359bfb943e5..4aa189286fe6f 100644 --- a/ticdc/ticdc-glossary.md +++ b/ticdc/ticdc-glossary.md @@ -7,7 +7,7 @@ summary: Learn the terms about TiCDC and their definitions. この用語集では、TiCDC関連の用語と定義について説明します。これらの用語は、TiCDCのログ、監視メトリック、設定、およびドキュメントで使用されます。 -TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)参照してください。 +TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)を参照してください。 ## C {#c} diff --git a/ticdc/ticdc-integrity-check.md b/ticdc/ticdc-integrity-check.md index 9f0cf7feeeea3..68b268d5f6963 100644 --- a/ticdc/ticdc-integrity-check.md +++ b/ticdc/ticdc-integrity-check.md @@ -37,7 +37,7 @@ TiCDCはデフォルトでデータ整合性検証を無効にしています。 > **注記：** > - > 既存の変更フィードにおいて、 `avro-decimal-handling-mode`と`avro-bigint-unsigned-handling-mode`設定されていない場合、チェックサム検証機能を有効にするとスキーマ互換性の問題が発生する可能性があります。この問題を解決するには、スキーマレジストリの互換性タイプを`NONE`に変更してください。詳細については、 [スキーマレジストリ](https://docs.confluent.io/platform/current/schema-registry/fundamentals/avro.html#no-compatibility-checking)参照してください。 + > 既存の変更フィードにおいて、 `avro-decimal-handling-mode`と`avro-bigint-unsigned-handling-mode`設定されていない場合、チェックサム検証機能を有効にするとスキーマ互換性の問題が発生する可能性があります。この問題を解決するには、スキーマレジストリの互換性タイプを`NONE`に変更してください。詳細については、 [スキーマレジストリ](https://docs.confluent.io/platform/current/schema-registry/fundamentals/avro.html#no-compatibility-checking)を参照してください。 ## 機能を無効にする {#disable-the-feature} @@ -106,7 +106,7 @@ For clusters created in v8.4.0 or later, or clusters upgraded to v8.4.0 or later - NULL および GEOMETRY 型はチェックサム計算から除外され、この関数は空のバイトを返します。 -Golangを使用したデータ消費とチェックサム検証の実装の詳細については、 [TiCDC 行データチェックサム検証](/ticdc/ticdc-avro-checksum-verification.md)参照してください。 +Golangを使用したデータ消費とチェックサム検証の実装の詳細については、 [TiCDC 行データチェックサム検証](/ticdc/ticdc-avro-checksum-verification.md)を参照してください。 > **注記：** > diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index 71aad2817d900..78209a44d8c55 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -5,7 +5,7 @@ summary: TiCDC 変更フィードを管理する方法を学びます。 # チェンジフィードを管理する {#manage-changefeeds} -このドキュメントでは、TiCDCコマンドラインツール`cdc cli`を使用してTiCDCの変更フィードを作成および管理する方法について説明します。変更フィードは、TiCDCのHTTPインターフェース経由でも管理できます。詳細については、 [TiCDC オープンAPI](/ticdc/ticdc-open-api.md)参照してください。 +このドキュメントでは、TiCDCコマンドラインツール`cdc cli`を使用してTiCDCの変更フィードを作成および管理する方法について説明します。変更フィードは、TiCDCのHTTPインターフェース経由でも管理できます。詳細については、 [TiCDC オープンAPI](/ticdc/ticdc-open-api.md)を参照してください。 ## レプリケーションタスクを作成する {#create-a-replication-task} diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 658fcb6f45be5..a7f5466d69fce 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -280,9 +280,9 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | :-------------------- | :--------------------------------------------------------------------------------------------------------------------- | | `event_filters` | イベントをフィルタリングするための設定。(オプション) | | `ignore_txn_start_ts` | `UINT64 ARRAY`型。これを指定すると、 `[1, 2]`など`start_ts`指定するトランザクションは無視されます。（オプション） | -| `rules` | `STRING ARRAY`型。テーブルスキーマフィルタリングのルール（例： `['foo*.*', 'bar*.*']` ）。詳細については、 [テーブルフィルター](/table-filter.md)参照してください。（オプション） | +| `rules` | `STRING ARRAY`型。テーブルスキーマフィルタリングのルール（例： `['foo*.*', 'bar*.*']` ）。詳細については、 [テーブルフィルター](/table-filter.md)を参照してください。（オプション） | -`filter.event_filters`パラメータの説明は以下のとおりです。詳細については[変更フィードログフィルター](/ticdc/ticdc-filter.md)参照してください。 +`filter.event_filters`パラメータの説明は以下のとおりです。詳細については[変更フィードログフィルター](/ticdc/ticdc-filter.md)を参照してください。 | パラメータ名 | 説明 | | :----------------------------- | :----------------------------------------------------------------------------------------------------------------- | diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 318bd3e3f844a..df3e148eed84d 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -120,7 +120,7 @@ MySQLのbinlogは、アップストリームで実行されたすべてのDML SQ TiCDCは、データ変更情報に基づいて、さまざまなダウンストリームタイプに適した形式でデータを生成し、ダウンストリームに送信します。例えば、Canal-JSONやAvroなどの形式でデータを生成してKafkaに書き込んだり、データをSQL文に変換してダウンストリームのMySQLやTiDBに送信したりします。 -現在、TiCDC が対応するプロトコルのデータ変更情報を適応させる場合、特定の`UPDATE`イベントについて、それらのイベントを 1 つの`DELETE`イベントと 1 つの`INSERT`イベントに分割する場合があります。詳細については、 [MySQLシンクの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)および[MySQL以外のシンクにおける、主キーまたは一意キーを分割した`UPDATE`イベント](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 +現在、TiCDC が対応するプロトコルのデータ変更情報を適応させる場合、特定の`UPDATE`イベントについて、それらのイベントを 1 つの`DELETE`イベントと 1 つの`INSERT`イベントに分割する場合があります。詳細については、 [MySQLシンクの`UPDATE`イベントを分割する](/ticdc/ticdc-split-update-behavior.md#split-update-events-for-mysql-sinks)および[MySQL以外のシンクにおける、主キーまたは一意キーを分割した`UPDATE`イベント](/ticdc/ticdc-split-update-behavior.md#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 ダウンストリームがMySQLまたはTiDBの場合、TiCDCはダウンストリームに書き込まれるSQL文がアップストリームで実行されるSQL文と完全に一致することを保証できません。これは、TiCDCがアップストリームで実行される元のDML文を直接取得するのではなく、データ変更情報に基づいてSQL文を生成するためです。ただし、TiCDCは最終結果の一貫性を保証します。 @@ -159,8 +159,8 @@ 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)参照してください。 +- 現在、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)を参照してください。 - バージョン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-server-config.md b/ticdc/ticdc-server-config.md index 5164998dd9a4e..ac0ab3a219b5d 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -14,7 +14,7 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 - `addr` : TiCDCのリスニングアドレス、HTTP APIアドレス、およびTiCDCサービスのPrometheusアドレス。デフォルト値は`127.0.0.1:8300`です。 - `advertise-addr` : クライアントがTiCDCにアクセスするために使用するアドバタイズされたアドレス。指定されていない場合、値は`addr`と同じになります。 - `pd` : PD エンドポイントのコンマ区切りリスト。 -- `config` : TiCDCが使用する設定ファイルのアドレス（オプション）。このオプションはTiCDC v5.0.0以降でサポートされています。このオプションはTiUP v1.4.0以降のTiCDCデプロイメントで使用できます。詳細な設定については、 [TiCDC Changefeed構成](/ticdc/ticdc-changefeed-config.md)参照してください。 +- `config` : TiCDCが使用する設定ファイルのアドレス（オプション）。このオプションはTiCDC v5.0.0以降でサポートされています。このオプションはTiUP v1.4.0以降のTiCDCデプロイメントで使用できます。詳細な設定については、 [TiCDC Changefeed構成](/ticdc/ticdc-changefeed-config.md)を参照してください。 - `data-dir` : TiCDC がファイルを保存するためにディスクを使用する必要があるときに使用するディレクトリを指定します。TiCDC が使用するソートエンジンと REDO ログは、このディレクトリに一時ファイルを保存します。このディレクトリの空きディスク容量は 500 GiB 以上確保することをお勧めします。TiUPを使用している場合は、セクション[`cdc_servers`](/tiup/tiup-cluster-topology-reference.md#cdc_servers)で`data_dir`設定するか、 `global`でデフォルトのパス`data_dir`を直接使用できます。 - `gc-ttl` : TiCDC によって設定される PD のサービスレベル`GC safepoint`の TTL (Time To Live) と、レプリケーションタスクが一時停止できる期間（秒単位）。デフォルト値は`86400`で、これは 24 時間を意味します。注: TiCDC レプリケーションタスクの一時停止は、TiCDC GC セーフポイントの進行に影響します。つまり、 [TiCDC GCセーフポイントの完全な動作](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)で詳述されているように、上流の TiDB GC の進行にも影響します。 - `log-file` : TiCDCプロセス実行時にログが出力されるパス。このパラメータが指定されていない場合、ログは標準出力（stdout）に書き込まれます。 diff --git a/ticdc/ticdc-simple-protocol.md b/ticdc/ticdc-simple-protocol.md index 84ef53c77a522..b09ede1d691cc 100644 --- a/ticdc/ticdc-simple-protocol.md +++ b/ticdc/ticdc-simple-protocol.md @@ -74,7 +74,7 @@ DML: ## メッセージ形式 {#message-format} -Simpleプロトコルでは、各メッセージには1つのイベントのみが含まれます。Simpleプロトコルは、JSON形式とAvro形式のメッセージのエンコードをサポートしています。このドキュメントでは、JSON形式を例として使用します。Avro形式のメッセージの場合、フィールドと意味はJSON形式と同じですが、エンコード形式が異なります。Avro形式の詳細については、 [シンプルプロトコルAvroスキーマ](https://github.com/pingcap/tiflow/blob/release-8.5/pkg/sink/codec/simple/message.json)参照してください。 +Simpleプロトコルでは、各メッセージには1つのイベントのみが含まれます。Simpleプロトコルは、JSON形式とAvro形式のメッセージのエンコードをサポートしています。このドキュメントでは、JSON形式を例として使用します。Avro形式のメッセージの場合、フィールドと意味はJSON形式と同じですが、エンコード形式が異なります。Avro形式の詳細については、 [シンプルプロトコルAvroスキーマ](https://github.com/pingcap/tiflow/blob/release-8.5/pkg/sink/codec/simple/message.json)を参照してください。 ### DDL {#ddl} @@ -712,4 +712,4 @@ TableSchemaは、テーブル名、テーブルID、テーブルバージョン ### Avroスキーマ定義 {#avro-schema-definition} -Simpleプロトコルは、Avro形式でのメッセージ出力をサポートしています。Avro形式の詳細については、 [シンプルプロトコルAvroスキーマ](https://github.com/pingcap/tiflow/blob/release-8.5/pkg/sink/codec/simple/message.json)参照してください。 +Simpleプロトコルは、Avro形式でのメッセージ出力をサポートしています。Avro形式の詳細については、 [シンプルプロトコルAvroスキーマ](https://github.com/pingcap/tiflow/blob/release-8.5/pkg/sink/codec/simple/message.json)を参照してください。 diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index b2cdaaee478d6..3c4515316b7e9 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -32,7 +32,7 @@ Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-repl - `--sink-uri` : チェンジフィードのダウンストリームアドレス。詳細は[シンクURIを構成する](#configure-sink-uri)参照。 - `--start-ts` : チェンジフィードの開始TSO。TiCDCはこのTSOからデータのプルを開始します。デフォルト値は現在時刻です。 - `--target-ts` : チェンジフィードの終了TSO。TiCDCはこのTSOまでデータのプルを停止します。デフォルト値は空で、TiCDCはデータのプルを自動的に停止しません。 -- `--config` : チェンジフィードの設定ファイル。詳細は[TiCDC チェンジフィード構成パラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 +- `--config` : チェンジフィードの設定ファイル。詳細は[TiCDC チェンジフィード構成パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 ## シンクURIを構成する {#configure-sink-uri} @@ -137,7 +137,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを > **ヒント：** > -> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 ### NFSのシンクURIを構成する {#configure-sink-uri-for-nfs} @@ -310,7 +310,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを ### データ型 {#data-type} -この節では、 `schema_{table-version}_{hash}.json`ファイル（以下、スキーマファイル）で使用されるデータ型について説明します。データ型は`T(M[, D])`として定義されています。詳細については[データ型](/data-type-overview.md)参照してください。 +この節では、 `schema_{table-version}_{hash}.json`ファイル（以下、スキーマファイル）で使用されるデータ型について説明します。データ型は`T(M[, D])`として定義されています。詳細については[データ型](/data-type-overview.md)を参照してください。 #### 整数型 {#integer-types} diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index c125fbc8ab208..eba1dfb72138c 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -29,7 +29,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na - `--sink-uri` : レプリケーションタスクのダウンストリームアドレス。詳細は[`kafka`でシンクURIを設定する](#configure-sink-uri-for-kafka)参照してください。 - `--start-ts` : チェンジフィードの開始TSOを指定します。このTSOから、TiCDCクラスターはデータのプルを開始します。デフォルト値は現在時刻です。 - `--target-ts` : チェンジフィードの終了TSOを指定します。このTSOまで、TiCDCクラスターはデータのプルを停止します。デフォルト値は空で、TiCDCはデータのプルを自動的に停止しません。 -- `--config` : changefeed設定ファイルを指定します。詳細は[TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 +- `--config` : changefeed設定ファイルを指定します。詳細は[TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 ## サポートされているKafkaのバージョン {#supported-kafka-versions} @@ -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)を参照してください。 > **注記：** > @@ -147,7 +147,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na --sink-uri="kafka://127.0.0.1:9092/topic-name?kafka-version=2.4.0&sasl-mechanism=gssapi&sasl-gssapi-auth-type=keytab&sasl-gssapi-kerberos-config-path=/etc/krb5.conf&sasl-gssapi-service-name=kafka&sasl-gssapi-user=alice/for-kafka&sasl-gssapi-keytab-path=/var/lib/secret/alice.key&sasl-gssapi-realm=example.com" ``` - SASL/GSSAPI 認証方式の詳細については、 [GSSAPIの設定](https://docs.confluent.io/platform/current/kafka/authentication_sasl/authentication_sasl_gssapi.html)参照してください。 + SASL/GSSAPI 認証方式の詳細については、 [GSSAPIの設定](https://docs.confluent.io/platform/current/kafka/authentication_sasl/authentication_sasl_gssapi.html)を参照してください。 - TLS/SSL暗号化 @@ -188,7 +188,7 @@ dispatchers = [ ] ``` -詳細な統合ガイドについては、 [Confluent Cloud、Snowflake、ksqlDB、SQL Server とデータを統合](/ticdc/integrate-confluent-using-ticdc.md)参照してください。 +詳細な統合ガイドについては、 [Confluent Cloud、Snowflake、ksqlDB、SQL Server とデータを統合](/ticdc/integrate-confluent-using-ticdc.md)を参照してください。 ### TiCDC を AWS Glue スキーマレジストリと統合する {#integrate-ticdc-with-aws-glue-schema-registry} @@ -465,7 +465,7 @@ large-message-handle-option = "claim-check" } ``` -Kafkaコンシューマーはメッセージを受信すると、まず`onlyHandleKey`フィールドをチェックします。このフィールドが存在し、値が`true`場合、メッセージには完全なデータのハンドルキーのみが含まれていることを意味します。この場合、完全なデータを取得するには、上流のTiDBにクエリを実行し、 [履歴データを読み取るための`tidb_snapshot`](/read-historical-data.md)使用する必要があります。 +Kafkaコンシューマーはメッセージを受信すると、まず`onlyHandleKey`フィールドをチェックします。このフィールドが存在し、値が`true`場合、メッセージには完全なデータのハンドルキーのみが含まれていることを意味します。この場合、完全なデータを取得するには、上流のTiDBにクエリを実行し、 [履歴データを読み取るための`tidb_snapshot`](/read-historical-data.md)を使用する必要があります。 > **警告：** > @@ -491,7 +491,7 @@ claim-check-storage-uri = "s3://claim-check-bucket" > **ヒント** > -> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 TiCDCは外部ストレージサービス上のメッセージをクリーンアップしません。データ利用者は外部ストレージサービスを独自に管理する必要があります。 diff --git a/ticdc/ticdc-split-update-behavior.md b/ticdc/ticdc-split-update-behavior.md index df2027c5e7b3e..687423deb7719 100644 --- a/ticdc/ticdc-split-update-behavior.md +++ b/ticdc/ticdc-split-update-behavior.md @@ -10,7 +10,7 @@ summary: TiCDC が UPDATE` イベントを分割するかどうかに関する v6.5.10、v7.1.6、v7.5.2、v8.1.1、v8.2.0以降では、MySQLシンクを使用する場合、テーブルのレプリケーション要求を受信したTiCDCノードは、下流へのレプリケーションを開始する前に、PDから現在のタイムスタンプ`thresholdTS`取得します。このタイムスタンプの値に基づいて、TiCDCは`UPDATE`イベントを分割するかどうかを決定します。 - 1 つまたは複数の`UPDATE`変更を含むトランザクションの場合、トランザクション`commitTS` `thresholdTS`未満であれば、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割してから、それらを Sorter モジュールに書き込みます。 -- トランザクション`commitTS`が`thresholdTS`以上であるイベントが`UPDATE`ある場合、TiCDC はそれらを分割しません。詳細については、GitHub の問題[＃10918](https://github.com/pingcap/tiflow/issues/10918)参照してください。 +- トランザクション`commitTS`が`thresholdTS`以上であるイベントが`UPDATE`ある場合、TiCDC はそれらを分割しません。詳細については、GitHub の問題[＃10918](https://github.com/pingcap/tiflow/issues/10918)を参照してください。 > **注記：** > diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md index 66e9f2dccdfe6..262913146efa5 100644 --- a/ticdc/ticdc-upstream-downstream-check.md +++ b/ticdc/ticdc-upstream-downstream-check.md @@ -94,7 +94,7 @@ select * from tidb_cdc.syncpoint_v1; ## 注記 {#notes} -- TiCDCがチェンジフィードを作成する前に、TiCDC構成項目`enable-sync-point`の値が`true`に設定されていることを確認してください。この設定によってのみ、同期ポイントが有効になり、 `ts-map`がダウンストリームに保存されます。構成項目`sync-point-interval`のデフォルト形式は`"h m s"` （例えば`"1h30m30s"`で、最小値は`"30s"`です。完全な構成情報については、 [TiCDC タスク構成ファイル](/ticdc/ticdc-changefeed-config.md)参照してください。 +- TiCDCがチェンジフィードを作成する前に、TiCDC構成項目`enable-sync-point`の値が`true`に設定されていることを確認してください。この設定によってのみ、同期ポイントが有効になり、 `ts-map`がダウンストリームに保存されます。構成項目`sync-point-interval`のデフォルト形式は`"h m s"` （例えば`"1h30m30s"`で、最小値は`"30s"`です。完全な構成情報については、 [TiCDC タスク構成ファイル](/ticdc/ticdc-changefeed-config.md)を参照してください。 - Syncpointを使用してデータ検証を実行する場合、TiKVのガベージコレクション（GC）時間を変更する必要があります。これは、データチェック中にスナップショットに対応する履歴データがGCによって収集されないようにするためです。GC時間を1時間に変更し、チェック後に設定を復元することをお勧めします。 - 上記の例では`Datasource config`の部分のみを示しています。完全な設定については[sync-diff-inspector ユーザーガイド](/sync-diff-inspector/sync-diff-inspector-overview.md)を参照してください。 - v6.4.0 以降では、 `SYSTEM_VARIABLES_ADMIN`または`SUPER`権限を持つ changefeed のみが TiCDC Syncpoint 機能を使用できます。 diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 257c4b553c151..11de48fd9f405 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -28,7 +28,7 @@ summary: TiCDC の使用時に発生する可能性のある問題のトラブ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc-2316-4f4f-a70b-d1a7c59ba79f ``` -上記のコマンドの出力で、 `admin-job-type`このレプリケーションタスクの状態を示しています。各状態とその意味の詳細については、 [チェンジフィードの状態](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer)参照してください。 +上記のコマンドの出力で、 `admin-job-type`このレプリケーションタスクの状態を示しています。各状態とその意味の詳細については、 [チェンジフィードの状態](/ticdc/ticdc-changefeed-overview.md#changefeed-state-transfer)を参照してください。 ### レプリケーションの中断をどのように処理しますか? {#how-do-i-handle-replication-interruptions} @@ -56,7 +56,7 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc ## レプリケーション タスクを作成するとき、または MySQL にデータをレプリケートするときに、「 Error 1298: Unknown or incorrect time zone: 'UTC'エラーを処理するにはどうすればよいですか? {#how-do-i-handle-the-code-error-1298-unknown-or-incorrect-time-zone-utc-code-error-when-creating-the-replication-task-or-replicating-data-to-mysql} -このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。1 [`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 +このエラーは、下流のMySQLがタイムゾーンをロードしていない場合に返されます。1 [`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html)を実行することでタイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成し、通常どおりデータをレプリケートできます。 ```shell mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p diff --git a/tidb-cloud/ai-feature-concepts.md b/tidb-cloud/ai-feature-concepts.md index 1b9f618954301..c01e489d8915a 100644 --- a/tidb-cloud/ai-feature-concepts.md +++ b/tidb-cloud/ai-feature-concepts.md @@ -11,7 +11,7 @@ TiDB CloudのAI機能により、データ探索、検索、統合のための ## Chat2Query（プレビュー） {#chat2query-preview} -Chat2Query は SQL エディターに統合された AI を活用した機能で、ユーザーが自然言語命令を使用して SQL クエリを生成、デバッグ、または書き換えるのを支援します。詳細については、[AI支援型SQLエディタでデータを探索しよう](/tidb-cloud/explore-data-with-chat2query.md)参照してください。 +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)を参照してください。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index c93c9e527b14f..3d8fbfdfe1f66 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -74,7 +74,7 @@ TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2 - ゾーン高可用性：すべてのコンポーネントを同じ可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。 - 地域別高可用性：ノードを複数の可用性ゾーンに分散させることで、インフラストラクチャの最大限の分離性と冗長性を実現します。 -詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)参照してください。 +詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 @@ -115,13 +115,13 @@ TiDB Cloud CLI `ticloud`と、簡単なコマンドでターミナルから直 TiDB Cloud APIは、RESTベースのインターフェースであり、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、およびTiDB Cloud Dedicatedの各プランにわたるリソースをプログラムから管理するためのアクセスを提供します。これにより、 [TiDB Cloudデータサービス](/tidb-cloud/data-service-overview.md)におけるプロジェクト、クラスタ、バックアップ、リストア、データインポート、課金、その他のリソースの管理といったタスクを自動化し、効率的に処理することが可能になります。 -詳細については、 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview)参照してください。 +詳細については、 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview)を参照してください。 ## ノード {#nodes} ノードはTiDBアーキテクチャの中核となるコンポーネントです。TiDBノード、TiKVノード、およびTiFlashノードは連携して、SQLクエリの処理、データの保存、および分析ワークロードの高速化を行います。 -- TiDB Cloud Dedicatedクラスターでは、パフォーマンス要件に応じて、専用の TiDB、TiKV、およびTiFlashノードの数とサイズを完全に管理できます。詳細については、[拡張性](/tidb-cloud/scalability-concepts.md)参照してください。 +- TiDB Cloud Dedicatedクラスターでは、パフォーマンス要件に応じて、専用の TiDB、TiKV、およびTiFlashノードの数とサイズを完全に管理できます。詳細については、[拡張性](/tidb-cloud/scalability-concepts.md)を参照してください。 - TiDB Cloud Starter、 TiDB Cloud Essential、またはTiDB Cloud Premiumインスタンスでは、TiDB、TiKV、およびTiFlashノードの数とサイズは自動的に管理されます。これにより、シームレスなスケーリングが実現され、ユーザーがノードの設定や管理を行う必要がなくなります。 ### TiDBノード {#tidb-node} diff --git a/tidb-cloud/backup-and-restore-concepts.md b/tidb-cloud/backup-and-restore-concepts.md index 1f08297361149..9423063a25298 100644 --- a/tidb-cloud/backup-and-restore-concepts.md +++ b/tidb-cloud/backup-and-restore-concepts.md @@ -21,13 +21,13 @@ TiDB Cloudでは、スナップショットバックアップはデフォルト TiDB Cloud Dedicatedの手動バックアップ機能は、必要に応じてデータを既知の状態にバックアップし、いつでもその状態に復元できる機能です。 -詳細については、 [手動バックアップを実行する](/tidb-cloud/backup-and-restore.md#perform-a-manual-backup)参照してください。 +詳細については、 [手動バックアップを実行する](/tidb-cloud/backup-and-restore.md#perform-a-manual-backup)を参照してください。 ## デュアルリージョンバックアップ {#dual-region-backup} TiDB Cloud Dedicatedのデュアルリージョンバックアップ機能は、クラスタリージョンから別のリージョンへバックアップを複製できる機能です。この機能を有効にすると、すべてのバックアップが指定されたリージョンに自動的に複製されます。これにより、リージョンをまたいだデータ保護とディザスタリカバリ機能が実現します。データの約99%は1時間以内にセカンダリリージョンに複製できると推定されています。 -詳細については、 [デュアルリージョンバックアップを有効にする](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)参照してください。 +詳細については、 [デュアルリージョンバックアップを有効にする](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)を参照してください。 ## 特定時点への復元 {#point-in-time-restore} @@ -40,5 +40,5 @@ TiDB Cloud Dedicatedのデュアルリージョンバックアップ機能は、 ポイントインタイム復元を実行する場合は、以下の点に注意してください。 - TiDB Cloud Starterインスタンスでは、特定時点への復元機能は利用できません。 -- TiDB Cloud Essentialインスタンスの場合、過去30日間の任意の時点に復元できます。詳細については、 [復元モード](/tidb-cloud/backup-and-restore-serverless.md#restore-mode)参照してください。 +- TiDB Cloud Essentialインスタンスの場合、過去30日間の任意の時点に復元できます。詳細については、 [復元モード](/tidb-cloud/backup-and-restore-serverless.md#restore-mode)を参照してください。 - TiDB Cloud Dedicatedクラスターの場合、事前に[PITRを有効にする](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)必要があります。 diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md index ae65e4793702f..f780c8eecc40c 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)を参照してください。 - ポイントインタイム復元を複数回オン/オフした場合、復元可能な期間内で選択できるのは、直近のポイントインタイム復元が有効になった時点以降の時点のみです。それ以前の復元可能な期間にはアクセスできません。 - **ポイントインタイム復元**と**デュアルリージョンバックアップ**のスイッチを同時に変更しないでください。 diff --git a/tidb-cloud/branch-overview.md b/tidb-cloud/branch-overview.md index dd1dc6b2af191..af463e2666b16 100644 --- a/tidb-cloud/branch-overview.md +++ b/tidb-cloud/branch-overview.md @@ -43,7 +43,7 @@ TiDB Cloudは、高速かつシームレスなブランチ作成を実現する > **注記：** > - > エージェント プラットフォームや多数のブランチを必要とするその他のサービスを構築している有料組織向けに、 TiDB Cloud は5 つを超えるブランチを作成できる**インスタンス キャパシティ プラン**を提供します。詳細については、 [インスタンス容量計画](/tidb-cloud/select-cluster-tier.md#instance-capacity-plan)参照してください。 + > エージェント プラットフォームや多数のブランチを必要とするその他のサービスを構築している有料組織向けに、 TiDB Cloud は5 つを超えるブランチを作成できる**インスタンス キャパシティ プラン**を提供します。詳細については、 [インスタンス容量計画](/tidb-cloud/select-cluster-tier.md#instance-capacity-plan)を参照してください。 - 無料のTiDB Cloud Starterインスタンスの各ブランチには、10 GiB のストレージが許可されます。利用制限が 0 より大きいTiDB Cloud Starterインスタンスの各ブランチには、100 GiB のストレージが許可されます。ストレージ容量が上限に達すると、ストレージを減らすまで、このブランチでの読み取りおよび書き込み操作が制限されます。 diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index f6002a9fafdbc..c44a59c8a4e9f 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -152,7 +152,7 @@ TiDB Cloud Premiumでは、チェンジフィードのTiCDC Changefeed容量ユ ## Changefeedの請求 {#changefeed-billing} -TiDB Cloudでの変更フィードの請求については、[Changefeedの請求](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md)参照してください。 +TiDB Cloudでの変更フィードの請求については、[Changefeedの請求](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md)を参照してください。 ## Changefeedの状態 {#changefeed-states} diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index f65677c84b8a8..5082d2c40e855 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -60,7 +60,7 @@ Apache Kafkaにデータをストリーミングするためのチェンジフ プライベートコネクトは、クラウドプロバイダーの**プライベートリンク**または**プライベートサービスコネクト**技術を活用し、VPC内のリソースがプライベートIPアドレスを使用して他のVPC内のサービスに接続できるようにします。これにより、あたかもそれらのサービスがVPC内で直接ホストされているかのように動作します。 -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 サービスで同様です。 +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)セットアップする」に従ってネットワーク接続を構成し、**ブートストラップ ポート**情報を取得します。次に[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)ネットワーク接続を構成し、**ブートストラップ ポート**情報を取得します。次に[Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md)ポイントを設定するに従ってプライベート エンドポイントを作成します。 @@ -137,7 +137,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - Kafka のトピック リソース タイプに`Create`および`Write`権限が追加されます。 - 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)参照してください。 +たとえば、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} @@ -274,14 +274,14 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン 4. **データフォーマット**領域で、希望する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)参照してください。 + - 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)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)参照してください。 + - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB拡張**オプションを有効にしてください。 - TiDB 拡張フィールドの詳細については、 [Avroデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields)フィールド」および[Canal-JSONデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)参照してください。 + TiDB 拡張フィールドの詳細については、 [Avroデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields)フィールド」および[Canal-JSONデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)を参照してください。 6. データ形式として**Avroを**選択すると、ページにAvro固有の設定項目が表示されます。これらの設定項目は、以下のように入力できます。 @@ -333,7 +333,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - **レプリケーション係数**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - **パーティション番号**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 -10. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 +10. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 11. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 0635b65b37e49..b9f52b8654bad 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -139,7 +139,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [TiCDC Canal- JSONプロトコル](https://docs.pingcap.com/tidb/stable/ticdc-canal-json/)を参照してください。 - - TiDB 拡張フィールドを Pulsar メッセージ本文に追加するには、 **TiDB 拡張**オプションを有効にします。詳細については、 [TiCDC Canal- JSONプロトコルのTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-canal-json/#tidb-extension-field)参照してください。 + - TiDB 拡張フィールドを Pulsar メッセージ本文に追加するには、 **TiDB 拡張**オプションを有効にします。詳細については、 [TiCDC Canal- JSONプロトコルのTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-canal-json/#tidb-extension-field)を参照してください。 5. **トピック配信**エリアで配信モードを選択し、選択したモードに応じてトピック名の設定を入力します。 @@ -185,7 +185,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 テーブルのPulsarメッセージを異なるパーティションに送信するように変更フィードを設定する場合は、この配信方法を選択してください。行の変更ログで指定された列の値によって、変更ログの送信先パーティションが決まります。この配信方法により、各パーティション内の順序が確保され、同じ列の値を持つ変更ログが同じパーティションに送信されることが保証されます。 -7. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 +7. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 8. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index 1d7ec1b93f4de..3a230712c43cf 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -238,7 +238,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl > > これら2つのパラメータは、各データベーステーブルごとにクラウドストレージに生成されるオブジェクトの数に影響します。テーブル数が多い場合、同じ設定を使用すると生成されるオブジェクトの数が増加し、結果としてクラウドストレージAPIの呼び出しコストが上昇します。そのため、リカバリポイント目標（RPO）とコスト要件に基づいて、これらのパラメータを適切に設定することをお勧めします。 -6. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 +6. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 ## ステップ3．仕様の設定 {#step-3-configure-specification} diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index 73106a388177c..2de2f2bda20ec 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -53,7 +53,7 @@ MySQLサービスがパブリックインターネットアクセスを持たな MySQL サービスがパブリック インターネット アクセスのない Google Cloud VPC 内にある場合は、以下の手順を実行してください。 -1. MySQL サービスが Google Cloud SQL の場合、Google Cloud SQL インスタンスに関連付けられた VPC に MySQL エンドポイントを公開する必要があります。Cloud [**Cloud SQL認証プロキシ**](https://cloud.google.com/sql/docs/mysql/sql-proxy)使用する必要がある場合があります。これは Google によって開発されています。 +1. MySQL サービスが Google Cloud SQL の場合、Google Cloud SQL インスタンスに関連付けられた VPC に MySQL エンドポイントを公開する必要があります。Cloud [**Cloud SQL認証プロキシ**](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の受信ファイアウォールルールを変更します。 diff --git a/tidb-cloud/cli-reference.md b/tidb-cloud/cli-reference.md index 7e46bfdbf3897..dbfb605abe3f3 100644 --- a/tidb-cloud/cli-reference.md +++ b/tidb-cloud/cli-reference.md @@ -19,7 +19,7 @@ TiDB Cloud CLIはコマンドラインインターフェースであり、ター 以下の表は、TiDB Cloud CLIで使用できるコマンドの一覧です。 -ターミナルで`ticloud` CLIを使用するには、 `ticloud [command] [subcommand]`を実行してください。TiUP [TiUP](https://docs.pingcap.com/tidb/stable/tiup-overview)使用している場合は、代わりに`tiup cloud [command] [subcommand]`を使用してください。 +ターミナルで`ticloud` CLIを使用するには、 `ticloud [command] [subcommand]`を実行してください。TiUP [TiUP](https://docs.pingcap.com/tidb/stable/tiup-overview)を使用している場合は、代わりに`tiup cloud [command] [subcommand]`を使用してください。 | コマンド | サブコマンド | 説明 | | ------------- | ---------------------------------- | ---------------------------------------------------------------- | @@ -58,7 +58,7 @@ TiDB Cloud CLI では、ユーザープロファイルとは、プロファイ ### OAuthトークンを使用してユーザープロファイルを作成します。 {#create-a-user-profile-with-oauth-token} -[`ticloud auth login`](/tidb-cloud/ticloud-auth-login.md)使用して、現在のプロファイルに OAuth トークンを割り当てます。プロファイルが存在しない場合は、 `default`という名前のプロファイルが自動的に作成されます。 +[`ticloud auth login`](/tidb-cloud/ticloud-auth-login.md)を使用して、現在のプロファイルに OAuth トークンを割り当てます。プロファイルが存在しない場合は、 `default`という名前のプロファイルが自動的に作成されます。 > **注記：** > @@ -92,11 +92,11 @@ TiDB Cloud CLI では、ユーザープロファイルとは、プロファイ ### ユーザープロファイルでプロパティを設定する {#set-properties-in-a-user-profile} -[`ticloud config set`](/tidb-cloud/ticloud-config-set.md)使用して、ユーザープロファイルのプロパティを設定します。 +[`ticloud config set`](/tidb-cloud/ticloud-config-set.md)を使用して、ユーザープロファイルのプロパティを設定します。 ### 別のユーザープロファイルに切り替える {#switch-to-another-user-profile} -[`ticloud config use`](/tidb-cloud/ticloud-config-use.md)使用して、別のユーザープロファイルに切り替えます。 +[`ticloud config use`](/tidb-cloud/ticloud-config-use.md)を使用して、別のユーザープロファイルに切り替えます。 出力例は以下のとおりです。 @@ -104,7 +104,7 @@ TiDB Cloud CLI では、ユーザープロファイルとは、プロファイ ### 設定ファイルを編集する {#edit-the-config-file} -[`ticloud config edit`](/tidb-cloud/ticloud-config-edit.md)使用して、設定ファイルを開いて編集します。 +[`ticloud config edit`](/tidb-cloud/ticloud-config-edit.md)を使用して、設定ファイルを開いて編集します。 ### ユーザープロファイルを削除する {#delete-a-user-profile} diff --git a/tidb-cloud/configure-external-storage-access.md b/tidb-cloud/configure-external-storage-access.md index 54f9ccac18b8d..14408e276f355 100644 --- a/tidb-cloud/configure-external-storage-access.md +++ b/tidb-cloud/configure-external-storage-access.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidbcloud/serverless-external-storage'] TiDB Cloud Starter、 Essential 、またはPremiumインスタンスで外部ストレージからデータをインポートしたり、外部ストレージにデータをエクスポートしたりするには、アカウント間アクセスを設定する必要があります。このドキュメントでは、TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premiumインスタンスで外部ストレージへのアクセスを設定する方法について説明します。 -TiDB Cloud Dedicatedクラスター用にこれらの外部ストレージを構成する必要がある場合は、 [TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md)参照してください。 +TiDB Cloud Dedicatedクラスター用にこれらの外部ストレージを構成する必要がある場合は、 [TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md)を参照してください。 ## Amazon S3へのアクセスを設定する {#configure-amazon-s3-access} @@ -19,7 +19,7 @@ TiDB Cloud Starter、 Essential、またはPremiumインスタンスがAmazon S3 ### ロールARNを使用してAmazon S3へのアクセスを設定する {#configure-amazon-s3-access-using-a-role-arn} -ロールARNの作成には[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)使用することをお勧めします。作成するには、以下の手順に従ってください。 +ロールARNの作成には[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)を使用することをお勧めします。作成するには、以下の手順に従ってください。 > **注記：** > @@ -180,11 +180,11 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 アクセスキーを設定するには、以下の手順に従ってください。 -1. IAMユーザーを作成します。詳細については、 [IAMユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)参照してください。 +1. IAMユーザーを作成します。詳細については、 [IAMユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)を参照してください。 2. AWSアカウントIDまたはアカウントエイリアス、およびIAMユーザー名とパスワードを使用して[IAMコンソール](https://console.aws.amazon.com/iam)にサインインしてください。 -3. アクセスキーを作成します。詳細については、 [IAMユーザーのアクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)参照してください。 +3. アクセスキーを作成します。詳細については、 [IAMユーザーのアクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)を参照してください。 > **注記：** > @@ -198,7 +198,7 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア サービスアカウントキーを設定するには、以下の手順に従ってください。 -1. Google Cloud サービス[サービスアカウントページ](https://console.cloud.google.com/iam-admin/serviceaccounts)ページで、 **[サービス アカウントの作成]**をクリックしてサービス アカウントを作成します。詳細については、 [サービスアカウントの作成](https://cloud.google.com/iam/docs/creating-managing-service-accounts)参照してください。 +1. Google Cloud サービス[サービスアカウントページ](https://console.cloud.google.com/iam-admin/serviceaccounts)ページで、 **[サービス アカウントの作成]**をクリックしてサービス アカウントを作成します。詳細については、 [サービスアカウントの作成](https://cloud.google.com/iam/docs/creating-managing-service-accounts)を参照してください。 1. サービスアカウント名を入力してください。 @@ -294,7 +294,7 @@ Azure ARMテンプレートを使用してSASトークンを作成する際に ![sas-position](/media/tidb-cloud/serverless-external-storage/azure-sas-position.png) -3. **[共有アクセス署名]**ページで、次のように必要なアクセス許可を持つサービス SAS トークンを作成します。詳細については、 [サービスSASトークンを作成します](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)参照してください。 +3. **[共有アクセス署名]**ページで、次のように必要なアクセス許可を持つサービス SAS トークンを作成します。詳細については、 [サービスSASトークンを作成します](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)を参照してください。 1. **「許可されたサービス」**セクションで、 **「Blob」**サービスを選択します。 @@ -323,11 +323,11 @@ TiDB CloudがAlibaba Cloud OSSバケットにアクセスできるようにす アクセスキーペアを設定するには、以下の手順に従ってください。 -1. RAM ユーザーを作成し、AccessKey ペアを取得します。詳細については、 [RAMユーザーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user)参照してください。 +1. RAM ユーザーを作成し、AccessKey ペアを取得します。詳細については、 [RAMユーザーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user)を参照してください。 **アクセスモードの**セクションで、 **「永続的なアクセスキーを使用してアクセスする」を**選択します。 -2. 必要な権限を持つカスタム ポリシーを作成します。詳細については、 [カスタムポリシーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy)参照してください。 +2. 必要な権限を持つカスタム ポリシーを作成します。詳細については、 [カスタムポリシーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy)を参照してください。 - **「効果」**セクションで**「許可」**を選択します。 @@ -341,4 +341,4 @@ TiDB CloudがAlibaba Cloud OSSバケットにアクセスできるようにす - **リソース**セクションで、バケットとバケット内のオブジェクトを選択します。 -3. カスタム ポリシーを RAM ユーザーにアタッチします。詳細については、 [RAMユーザーに権限を付与する](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user)参照してください。 +3. カスタム ポリシーを RAM ユーザーにアタッチします。詳細については、 [RAMユーザーに権限を付与する](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user)を参照してください。 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 04e684019ae38..7d6c875c44548 100644 --- a/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md +++ b/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md @@ -9,7 +9,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスへの > **注記：** > -> このドキュメントは**TiDB Cloud Starter**および**TiDB Cloud Essential**に適用されます。 **TiDB Cloud Dedicated**の IP アクセス リストを設定する手順については、 [TiDB Cloud Dedicatedの IP アクセス リストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 +> このドキュメントは**TiDB Cloud Starter**および**TiDB Cloud Essential**に適用されます。 **TiDB Cloud Dedicated**の IP アクセス リストを設定する手順については、 [TiDB Cloud Dedicatedの IP アクセス リストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 ## 公開エンドポイント {#public-endpoints} diff --git a/tidb-cloud/configure-sql-users.md b/tidb-cloud/configure-sql-users.md index bd1fdf62ad2a8..bf2bb5f2f5b38 100644 --- a/tidb-cloud/configure-sql-users.md +++ b/tidb-cloud/configure-sql-users.md @@ -11,7 +11,7 @@ summary: TiDB Cloudコンソールでデータベースユーザーとロール > > - **SQLユーザー**ページはパブリックプレビューであり、リクエストがあった場合のみ利用可能です。この機能をリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)**？」**をクリックし、**サポートチケット**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。チケットを作成し、 **「説明」**フィールドに「SQLユーザーページの申請」と入力して、 **「送信」を**クリックします。 > - データベースのユーザーと役割[組織およびプロジェクトのユーザーと役割](/tidb-cloud/manage-user-access.md)から独立しています。データベース ユーザーは TiDB クラスター内のデータベースにアクセスするために使用され、組織およびプロジェクト ユーザーは[TiDB Cloudコンソール](https://tidbcloud.com/)内の組織およびプロジェクトにアクセスするために使用されます。 -> - **「SQL ユーザー」**ページに加えて、SQL クライアントを使用してクラスターに接続し、SQL ステートメントを作成することによって、データベース ユーザーとロールを管理することもできます。詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/dev/user-account-management)参照してください。 +> - **「SQL ユーザー」**ページに加えて、SQL クライアントを使用してクラスターに接続し、SQL ステートメントを作成することによって、データベース ユーザーとロールを管理することもできます。詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/dev/user-account-management)を参照してください。 ## データベースユーザーの役割 {#roles-of-database-users} diff --git a/tidb-cloud/connect-to-tidb-cluster-serverless.md b/tidb-cloud/connect-to-tidb-cluster-serverless.md index 8a70331b0398b..daa6711249c05 100644 --- a/tidb-cloud/connect-to-tidb-cluster-serverless.md +++ b/tidb-cloud/connect-to-tidb-cluster-serverless.md @@ -10,7 +10,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにさ > **ヒント：** > > - TiDB Cloud Dedicatedクラスターに接続する方法については、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 -> - このドキュメントでは、TiDB Cloud StarterおよびTiDB Cloud Essentialのネットワーク接続方法について説明します。特定のツール、ドライバ、または ORM を介して TiDB に接続する方法については、 [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)参照してください。 +> - このドキュメントでは、TiDB Cloud StarterおよびTiDB Cloud Essentialのネットワーク接続方法について説明します。特定のツール、ドライバ、または ORM を介して TiDB に接続する方法については、 [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)を参照してください。 ## ネットワーク接続方法 {#network-connection-methods} diff --git a/tidb-cloud/connect-to-tidb-cluster.md b/tidb-cloud/connect-to-tidb-cluster.md index 7231a7d688e5a..4a42447a08466 100644 --- a/tidb-cloud/connect-to-tidb-cluster.md +++ b/tidb-cloud/connect-to-tidb-cluster.md @@ -9,8 +9,8 @@ summary: さまざまな方法でTiDB Cloud Dedicatedクラスターに接続す > **ヒント：** > -> - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)参照してください。 -> - このドキュメントでは、 TiDB Cloud Dedicatedのネットワーク接続方法について説明します。特定のツール、ドライバ、または ORM を介して TiDB に接続する方法については、 [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)参照してください。 +> - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)を参照してください。 +> - このドキュメントでは、 TiDB Cloud Dedicatedのネットワーク接続方法について説明します。特定のツール、ドライバ、または ORM を介して TiDB に接続する方法については、 [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)を参照してください。 TiDB Cloud Dedicatedクラスタが作成されたら、以下のいずれかのネットワーク接続方法で接続できます。 @@ -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-sql-shell.md b/tidb-cloud/connect-via-sql-shell.md index cfce8c3a61631..014a66cb2e8c5 100644 --- a/tidb-cloud/connect-via-sql-shell.md +++ b/tidb-cloud/connect-via-sql-shell.md @@ -9,7 +9,7 @@ TiDB Cloud SQL Shell では、 TiDB SQL を試用したり、TiDB と MySQL の > **注記：** > -> SQL Shell を使用して[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 Essentialインスタンスに接続するには、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)参照してください。 +> SQL Shell を使用して[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 Essentialインスタンスに接続するには、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)を参照してください。 SQLシェルを使用してTiDBに接続するには、以下の手順を実行してください。 diff --git a/tidb-cloud/connect-via-standard-connection-serverless.md b/tidb-cloud/connect-via-standard-connection-serverless.md index 225e52697f5ea..c203e8c1dd0a0 100644 --- a/tidb-cloud/connect-via-standard-connection-serverless.md +++ b/tidb-cloud/connect-via-standard-connection-serverless.md @@ -45,7 +45,7 @@ TiDB Cloudプランに応じて、適切なエンドポイントモデルを選 > **注記：** > > - 接続タイプを`Public`のままにすると、接続が標準の TLS 接続を介して行われることを意味します。詳細については、 [TiDB Cloud StarterまたはEssentialへのTLS接続](/tidb-cloud/secure-connections-to-serverless-clusters.md)を参照してください。 - > - **[接続タイプ]**ドロップダウン リストで**[プライベート エンドポイント]**を選択した場合、接続がプライベート エンドポイント経由であることを意味します。詳細については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)参照してください。 + > - **[接続タイプ]**ドロップダウン リストで**[プライベート エンドポイント]**を選択した場合、接続がプライベート エンドポイント経由であることを意味します。詳細については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 @@ -57,7 +57,7 @@ TiDB Cloudプランに応じて、適切なエンドポイントモデルを選 > **注記：** > - > 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/connect-via-standard-connection.md b/tidb-cloud/connect-via-standard-connection.md index f8b32f414bebe..52f72790778be 100644 --- a/tidb-cloud/connect-via-standard-connection.md +++ b/tidb-cloud/connect-via-standard-connection.md @@ -9,7 +9,7 @@ summary: パブリック接続を使用してTiDB Cloudクラスターに接続 > **ヒント：** > -> パブリック接続経由​​でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [パブリックエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/connect-via-standard-connection-serverless.md)参照してください。 +> パブリック接続経由​​でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [パブリックエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/connect-via-standard-connection-serverless.md)を参照してください。 ## 前提条件：IPアクセスリストの設定 {#prerequisite-configure-ip-access-list} diff --git a/tidb-cloud/connected-care-overview.md b/tidb-cloud/connected-care-overview.md index b93c89e60dfb7..d16d4d968f29a 100644 --- a/tidb-cloud/connected-care-overview.md +++ b/tidb-cloud/connected-care-overview.md @@ -71,7 +71,7 @@ Connected Care サービスのサポート プランでは、次のようなま - 新しい**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/)使用して技術サポートを受けることができます。 +- 新しい**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} diff --git a/tidb-cloud/create-tidb-cluster-serverless.md b/tidb-cloud/create-tidb-cluster-serverless.md index 583b7f0b5beff..c27203d8dbf4f 100644 --- a/tidb-cloud/create-tidb-cluster-serverless.md +++ b/tidb-cloud/create-tidb-cluster-serverless.md @@ -9,7 +9,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスの作 > **ヒント：** > -> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 +> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 8e6db7aca8e50..a84a0e565f7aa 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -7,7 +7,7 @@ summary: TiDB Cloudのインポート データ サービスで CSV 構成を使 このドキュメントでは、 TiDB Cloudの Import Data サービスの CSV 構成について説明します。 -以下は、 TiDB Cloudのデータインポートサービスを使用してCSVファイルをインポートする際のCSVコンフィグレーションウィンドウです。詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 +以下は、 TiDB Cloudのデータインポートサービスを使用してCSVファイルをインポートする際のCSVコンフィグレーションウィンドウです。詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。 diff --git a/tidb-cloud/data-service-concepts.md b/tidb-cloud/data-service-concepts.md index 1563ed6c182e6..61719fcb74842 100644 --- a/tidb-cloud/data-service-concepts.md +++ b/tidb-cloud/data-service-concepts.md @@ -9,25 +9,25 @@ TiDB Cloud [データサービス（PREVIEW）](https://tidbcloud.com/project/da Data Service を使用すると、カスタム API エンドポイントを使用して HTTPS リクエスト経由でTiDB Cloudデータにアクセスできます。この機能は、サーバーレスアーキテクチャを使用してコンピューティングリソースと柔軟なスケーリングを処理するため、インフラストラクチャやメンテナンスコストを気にすることなく、エンドポイントのクエリロジックに集中できます。 -詳細については[TiDB Cloudデータ サービス (PREVIEW) の概要](/tidb-cloud/data-service-overview.md)参照してください。 +詳細については[TiDB Cloudデータ サービス (PREVIEW) の概要](/tidb-cloud/data-service-overview.md)を参照してください。 ## データアプリ {#data-app} [データサービス（PREVIEW）](https://tidbcloud.com/project/data-service)のデータアプリは、特定のアプリケーションのデータにアクセスするために使用できるエンドポイントのコレクションです。データアプリを作成することで、エンドポイントをグループ化し、APIキーを使用してエンドポイントへのアクセスを制限する認証設定を構成できます。これにより、承認されたユーザーのみがデータにアクセスして操作できるようにし、アプリケーションのセキュリティを強化できます。 -詳細については[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)参照してください。 +詳細については[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)を参照してください。 ## データアプリのエンドポイント {#data-app-endpoints} [データサービス（PREVIEW）](https://tidbcloud.com/project/data-service)のエンドポイントは、SQL 文を実行するためにカスタマイズできる Web API です。SQL 文には、 `WHERE`句で使用される値などのパラメータを指定できます。クライアントがエンドポイントを呼び出し、リクエスト URL でパラメータの値を指定すると、エンドポイントは指定されたパラメータを使用して対応する SQL 文を実行し、結果を HTTP レスポンスの一部として返します。 -詳細については[エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md)参照してください。 +詳細については[エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md)を参照してください。 ## Chat2Query API {#chat2query-api} TiDB Cloudの Chat2Query API は、AI が指示を与えることで SQL 文を生成・実行できる RESTful インターフェースです。その後、API がクエリ結果を返します。 -詳細については[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)参照してください。 +詳細については[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)を参照してください。 ## AI統合 {#ai-integrations} @@ -35,7 +35,7 @@ TiDB Cloudの Chat2Query API は、AI が指示を与えることで SQL 文を 現在、GPT や Dify などのサードパーティ ツールをTiDB Cloudコンソールに統合できます。 -詳細については[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)参照してください。 +詳細については[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)を参照してください。 ## コードとしてのコンフィグレーション {#configuration-as-code} @@ -45,4 +45,4 @@ TiDB Cloud は、 JSON 構文を使用してデータ アプリの構成全体 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 da7abb53152f6..68b25b7a58677 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データ サービスによって提供されるコード サンプルは、カスタム ドメインとパスに自動的に更新されます。詳細については、 [エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)参照してください。 +カスタム ドメインのステータスが**Success**に設定されると、それを使用してエンドポイントにアクセスできるようになります。 TiDB Cloudデータ サービスによって提供されるコード サンプルは、カスタム ドメインとパスに自動的に更新されます。詳細については、 [エンドポイントを呼び出す](/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 59a39bb7ed8c0..141865f8f5530 100644 --- a/tidb-cloud/data-service-get-started.md +++ b/tidb-cloud/data-service-get-started.md @@ -82,7 +82,7 @@ summary: TiDB Cloudデータサービスを使用してHTTPSリクエストで 6. データ アプリを GitHub に接続するように構成している場合は、指定した GitHub ディレクトリを確認してください。データ[データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)`tidb-cloud-data-service`によってディレクトリにコミットされていることがわかります。これは、データアプリが GitHub に正常に接続されていることを意味します。 - 新しいデータ アプリでは、**自動同期とデプロイメント**および**ドラフトのレビューが**デフォルトで有効になっているため、 TiDB Cloudコンソールと GitHub の間でデータ アプリの変更を簡単に同期し、デプロイメント前に変更をレビューできます。 GitHub 統合の詳細については、 [GitHub を使用してデータ アプリの変更を自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)参照してください。 + 新しいデータ アプリでは、**自動同期とデプロイメント**および**ドラフトのレビューが**デフォルトで有効になっているため、 TiDB Cloudコンソールと GitHub の間でデータ アプリの変更を簡単に同期し、デプロイメント前に変更をレビューできます。 GitHub 統合の詳細については、 [GitHub を使用してデータ アプリの変更を自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 ### ステップ2. エンドポイントを開発する {#step-2-develop-an-endpoint} @@ -100,7 +100,7 @@ summary: TiDB Cloudデータサービスを使用してHTTPSリクエストで - **リクエストメソッド**：エンドポイントの HTTP メソッド。 `GET`を使用してデータを取得し、 `POST`を使用してデータを作成または挿入し、 `PUT`を使用してデータを更新または変更し、 `DELETE`を使用してデータを削除できます。 -エンドポイントのプロパティの詳細については、 [プロパティを構成する](/tidb-cloud/data-service-manage-endpoint.md#configure-properties)参照してください。 +エンドポイントのプロパティの詳細については、 [プロパティを構成する](/tidb-cloud/data-service-manage-endpoint.md#configure-properties)を参照してください。 #### SQL文を書く {#write-sql-statements} @@ -110,7 +110,7 @@ summary: TiDB Cloudデータサービスを使用してHTTPSリクエストで > **注記：** > - > データ アプリにリンクされている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インスタンスのすべてのデータベースを表示できます。 @@ -122,7 +122,7 @@ summary: TiDB Cloudデータサービスを使用してHTTPSリクエストで > **注記：** > - > TiDB Cloudの AI 機能を試すには、PingCAP と Amazon Bedrock が研究とサービス向上のためにコード スニペットを使用できるようにする必要があります。詳細については、 [AIによるSQLクエリ生成を有効または無効にする](/tidb-cloud/explore-data-with-chat2query.md#enable-or-disable-ai-to-generate-sql-queries)参照してください。 + > TiDB Cloudの AI 機能を試すには、PingCAP と Amazon Bedrock が研究とサービス向上のためにコード スニペットを使用できるようにする必要があります。詳細については、 [AIによるSQLクエリ生成を有効または無効にする](/tidb-cloud/explore-data-with-chat2query.md#enable-or-disable-ai-to-generate-sql-queries)を参照してください。 パラメータを定義するには、SQL文に`${ID}`のような変数プレースホルダーとして挿入します。例えば、 `SELECT * FROM table_name WHERE id = ${ID}`のように記述します。その後、右側のペインにある**「パラメータ」**タブをクリックして、パラメータの定義を変更したり、値をテストしたりできます。 @@ -133,7 +133,7 @@ summary: TiDB Cloudデータサービスを使用してHTTPSリクエストで - **定義**セクションでは、クライアントがエンドポイントを呼び出す際にパラメータが必須かどうか、データ型、およびパラメータのデフォルト値を指定できます。 - **「テスト値」**セクションでは、パラメーターのテスト値を設定できます。テスト値は、SQLステートメントの実行時やエンドポイントのテスト時に使用されます。テスト値を設定しない場合は、デフォルト値が使用されます。 - - 詳細については、 [パラメータを設定する](/tidb-cloud/data-service-manage-endpoint.md#configure-parameters)参照してください。 + - 詳細については、 [パラメータを設定する](/tidb-cloud/data-service-manage-endpoint.md#configure-parameters)を参照してください。 3. SQL文を実行します。 @@ -173,7 +173,7 @@ summary: TiDB Cloudデータサービスを使用してHTTPSリクエストで エンドポイントをテストするには、右上隅の**「テスト」**をクリックするか、 **F5**キーを押してください。 -その後、ページの下部にある**[HTTP 応答]**タブで応答を確認できます。応答の詳細については、 [エンドポイントの応答](/tidb-cloud/data-service-manage-endpoint.md#response)参照してください。 +その後、ページの下部にある**[HTTP 応答]**タブで応答を確認できます。応答の詳細については、 [エンドポイントの応答](/tidb-cloud/data-service-manage-endpoint.md#response)を参照してください。 ### ステップ4. エンドポイントをデプロイ {#step-4-deploy-the-endpoint} @@ -303,7 +303,7 @@ TiDB Cloudは、エンドポイントを呼び出すのに役立つコード例 } ``` -応答の詳細については、 [エンドポイントの応答](/tidb-cloud/data-service-manage-endpoint.md#response)参照してください。 +応答の詳細については、 [エンドポイントの応答](/tidb-cloud/data-service-manage-endpoint.md#response)を参照してください。 ## もっと詳しく知る {#learn-more} diff --git a/tidb-cloud/data-service-integrations.md b/tidb-cloud/data-service-integrations.md index 67c09f8c8ad23..b561c2e47c69a 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 仕様 URL** : データ アプリの OpenAPI 仕様の URL をコピーします。詳細については、 [OpenAPI仕様を使用する](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification)参照してください。 + ａ． **API 仕様 URL** : データ アプリの OpenAPI 仕様の URL をコピーします。詳細については、 [OpenAPI仕様を使用する](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification)を参照してください。 - b. **API キー**: データ アプリの API キーを入力します。 API キーをまだ持っていない場合は、 **「API キーの作成**」をクリックして作成します。詳細については、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)参照してください。 + b. **API キー**: データ アプリの API キーを入力します。 API キーをまだ持っていない場合は、 **「API キーの作成**」をクリックして作成します。詳細については、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 c. **APIキーエンコード**：提供したAPIキーに相当するbase64エンコードされた文字列をコピーします。 diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index fdbec0306922c..26c0ae24ed595 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -35,7 +35,7 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ > > - ディレクトリはスラッシュ（ `/` ）で始まる必要があります。例えば、 `/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. **[データ アプリの作成] を**クリックします。 @@ -59,7 +59,7 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ ### GitHub接続を管理する {#manage-github-connection} -詳細については[GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md)参照してください。 +詳細については[GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 ### リンクされたデータソースを管理する {#manage-linked-data-sources} @@ -83,15 +83,15 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ ### APIキーを管理する {#manage-an-api-key} -詳細については[APIキーを管理する](/tidb-cloud/data-service-api-key.md)参照してください。 +詳細については[APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 ### エンドポイントを管理する {#manage-an-endpoint} -詳細については[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)参照してください。 +詳細については[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)を参照してください。 ### カスタムドメインを管理する {#manage-a-custom-domain} -詳細については[カスタムドメインを管理する](/tidb-cloud/data-service-custom-domain.md)参照してください。 +詳細については[カスタムドメインを管理する](/tidb-cloud/data-service-custom-domain.md)を参照してください。 ### 展開を管理する {#manage-deployments} @@ -159,11 +159,11 @@ OpenAPI ドキュメントにアクセスするには、次の手順を実行し 1. **[承認]**をクリックし、表示されたダイアログ ボックスにデータ アプリの公開キーを**ユーザー名**として、秘密キーを**パスワード**として入力します。 - 詳細については[APIキーを管理する](/tidb-cloud/data-service-api-key.md)参照してください。 + 詳細については[APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 2. ターゲットエンドポイントを見つけ、必要なパラメータを入力して**「試してみる」**をクリックします。レスポンスは**「レスポンス本文」**領域に表示されます。 -OpenAPI ドキュメントの使用方法の詳細については、 [スワッガーUI](https://swagger.io/tools/swagger-ui/)参照してください。 +OpenAPI ドキュメントの使用方法の詳細については、 [スワッガーUI](https://swagger.io/tools/swagger-ui/)を参照してください。 ## データアプリを削除する {#delete-a-data-app} diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index 464a34bfc2eff..4c1ae5d1c79c2 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} @@ -24,7 +24,7 @@ Data Service (PREVIEW) のエンドポイントは、SQL ステートメント > **ヒント：** > -> SQL エディターで SQL ファイルからエンドポイントを作成することもできます。詳細については、 [SQLファイルからエンドポイントを生成する](/tidb-cloud/explore-data-with-chat2query.md#generate-an-endpoint-from-a-sql-file)参照してください。 +> SQL エディターで SQL ファイルからエンドポイントを作成することもできます。詳細については、 [SQLファイルからエンドポイントを生成する](/tidb-cloud/explore-data-with-chat2query.md#generate-an-endpoint-from-a-sql-file)を参照してください。 ### エンドポイントを自動的に生成する {#generate-an-endpoint-automatically} @@ -174,7 +174,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の > > - パス パラメーターは SQL で直接使用できます。詳細については、[パラメータを設定する](#configure-parameters)参照してください。 -- **エンドポイント URL** : (読み取り専用) デフォルト URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データ アプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`です。データ アプリのカスタム ドメインを構成するには、 [データサービスのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)参照してください。 +- **エンドポイント URL** : (読み取り専用) デフォルト URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データ アプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`です。データ アプリのカスタム ドメインを構成するには、 [データサービスのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)を参照してください。 - **リクエストメソッド**：エンドポイントのHTTPメソッド。以下のメソッドがサポートされています。 @@ -218,7 +218,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の > **注記：** > - > データ アプリにリンクされている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インスタンスのすべてのデータベースを表示できます。 @@ -327,7 +327,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の > **ヒント：** > -> データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントをテストすることもできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)参照してください。 +> データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントをテストすることもできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 1. プロジェクトの[**データサービス**](https://tidbcloud.com/project/data-service)ページに移動します。 @@ -354,7 +354,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の > **注記：** > -> **自動同期とデプロイメント**を有効にしてデータ アプリを GitHub に接続している場合、GitHub で行ったデータ アプリの変更はすべてTiDB Cloud Data Service に自動的にデプロイされます。詳細については、 [GitHubで自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)参照してください。 +> **自動同期とデプロイメント**を有効にしてデータ アプリを GitHub に接続している場合、GitHub で行ったデータ アプリの変更はすべてTiDB Cloud Data Service に自動的にデプロイされます。詳細については、 [GitHubで自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 エンドポイントをデプロイするには、以下の手順を実行します。 @@ -372,7 +372,7 @@ TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数の > **ヒント：** > -> データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントを呼び出すこともできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)参照してください。 +> データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントを呼び出すこともできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 ### 前提条件 {#prerequisites} @@ -474,7 +474,7 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ ### 応答 {#response} -エンドポイントを呼び出した後、JSON 形式で応答を確認できます。詳細については、 [データサービスの応答コードとステータスコード](/tidb-cloud/data-service-response-and-status-code.md)参照してください。 +エンドポイントを呼び出した後、JSON 形式で応答を確認できます。詳細については、 [データサービスの応答コードとステータスコード](/tidb-cloud/data-service-response-and-status-code.md)を参照してください。 ## エンドポイントをアンデプロイする {#undeploy-an-endpoint} diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index 3a40e63a83d4d..84fb976a9ad61 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -26,7 +26,7 @@ GitHub接続で**自動同期とデプロイが**有効になっている場合 ## ステップ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接続を有効にしなかった場合でも、以下の手順で有効にすることができます。 diff --git a/tidb-cloud/data-service-oas-with-nextjs.md b/tidb-cloud/data-service-oas-with-nextjs.md index 652d2d9afa02e..05ed10fdfd76e 100644 --- a/tidb-cloud/data-service-oas-with-nextjs.md +++ b/tidb-cloud/data-service-oas-with-nextjs.md @@ -87,7 +87,7 @@ SELECT * FROM test.repository; 2. **API仕様**エリアで**「ダウンロード」**をクリックし、JSON形式を選択して、プロンプトが表示されたら**「承認」**をクリックします。 3. ダウンロードしたファイルを`oas/doc.json`プロジェクトディレクトリに`hello-repos` }という名前で保存してください。 - 詳細については、 [OpenAPI仕様書をダウンロードする](/tidb-cloud/data-service-manage-data-app.md#download-the-openapi-specification)参照してください。 + 詳細については、 [OpenAPI仕様書をダウンロードする](/tidb-cloud/data-service-manage-data-app.md#download-the-openapi-specification)を参照してください。 `oas/doc.json`ファイルの構造は以下のとおりです。 @@ -150,7 +150,7 @@ SELECT * FROM test.repository; TIDBCLOUD_DATA_SERVICE_PUBLIC_KEY=YOUR_PUBLIC_KEY 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-overview.md b/tidb-cloud/data-service-overview.md index 25926c55d74bf..d22e10a7ee0cb 100644 --- a/tidb-cloud/data-service-overview.md +++ b/tidb-cloud/data-service-overview.md @@ -21,7 +21,7 @@ Data Service のエンドポイントは、SQL 文を実行するためにカス > > TiDB Cloudは、TiDBクラスタ用のChat2Query APIを提供します。有効にすると、 TiDB Cloudは自動的に**Chat2Query**と呼ばれるシステムデータアプリと、データサービスにChat2Dataエンドポイントを作成します。このエンドポイントを呼び出すことで、AIが指示を与えるだけでSQL文を生成・実行できるようになります。 > -> 詳細については[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)参照してください。 +> 詳細については[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)を参照してください。 ## シナリオ {#scenarios} diff --git a/tidb-cloud/data-streaming-concepts.md b/tidb-cloud/data-streaming-concepts.md index e8ded6b8f0a11..1c25e7f99e99a 100644 --- a/tidb-cloud/data-streaming-concepts.md +++ b/tidb-cloud/data-streaming-concepts.md @@ -19,4 +19,4 @@ TiDB Cloudコンソールの**Changefeed**ページでは、変更フィード TiDB Cloudでは、テーブル フィルター (レプリケートするテーブルを指定する) とイベント フィルター (INSERT や DELETE などの特定の種類のイベントを含めるか除外するか) を定義することで、レプリケーションをカスタマイズできます。 -詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md)参照してください。 +詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md)を参照してください。 diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index 25bdb423eb084..177a59df9f6b8 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -59,7 +59,7 @@ TiDBでは、パーティション[パーティショニング](/partitioned-tab 列はテーブルの下位要素です。各テーブルには少なくとも1つの列があります。列は、各行の値を単一のデータ型の小さなセルに分割することで、テーブルに構造を与えます。 -詳細については、 [列を定義する](/develop/dev-guide-create-table.md#define-columns)参照してください。 +詳細については、 [列を定義する](/develop/dev-guide-create-table.md#define-columns)を参照してください。 ## 生成された列 {#generated-columns} @@ -113,7 +113,7 @@ TiDB v8.0.0以降では、 [`tidb_opt_use_invisible_indexes`](/system-variables. TiDBにおけるセカンダリインデックスは論理オブジェクトです。簡単に言えば、TiDBがクエリパフォーマンスを向上させるために使用するソートタイプのデータと考えることができます。TiDBでは、セカンダリインデックスの作成はオンライン操作であり、テーブルに対するデータの読み書き操作をブロックしません。TiDBは、各インデックスに対してテーブルの各行への参照を作成し、データ自体ではなく、選択された列に基づいて参照をソートします。 -二次インデックスの詳細については、 [セカンダリインデックス](https://docs.pingcap.com/tidb/stable/tidb-best-practices#secondary-index)参照してください。 +二次インデックスの詳細については、 [セカンダリインデックス](https://docs.pingcap.com/tidb/stable/tidb-best-practices#secondary-index)を参照してください。 TiDB では、 [既存のテーブルにセカンダリインデックスを追加する](/develop/dev-guide-create-secondary-indexes.md#add-a-secondary-index-to-an-existing-table)か[新しいテーブルを作成する際にセカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md#create-a-secondary-index-when-creating-a-new-table)ことができます。 diff --git a/tidb-cloud/dedicated-external-storage.md b/tidb-cloud/dedicated-external-storage.md index 8392bad3aa52f..ece052781f1ee 100644 --- a/tidb-cloud/dedicated-external-storage.md +++ b/tidb-cloud/dedicated-external-storage.md @@ -144,11 +144,11 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA これらのポリシーは、ソースデータが保存されているバケットにのみ適用されるようにすることをお勧めします。 - 詳細については、 [IAMユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)参照してください。 + 詳細については、 [IAMユーザーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)を参照してください。 2. AWSアカウントIDまたはアカウントエイリアス、およびIAMユーザー名とパスワードを使用して[IAMコンソール](https://console.aws.amazon.com/iam)にサインインしてください。 -3. アクセスキーを作成します。詳細については、 [IAMユーザーのアクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)参照してください。 +3. アクセスキーを作成します。詳細については、 [IAMユーザーのアクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)を参照してください。 > **注記：** > diff --git a/tidb-cloud/delete-tidb-cluster.md b/tidb-cloud/delete-tidb-cluster.md index c9609fc0aa0ec..344f2a7530bd9 100644 --- a/tidb-cloud/delete-tidb-cluster.md +++ b/tidb-cloud/delete-tidb-cluster.md @@ -30,9 +30,9 @@ summary: TiDB Cloudリソースを削除する方法を学びましょう。 今後、削除したTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスターを復元したい場合は、必ずバックアップを作成してください。バックアップがない場合、復元することはできません。 - - TiDB Cloud Essentialインスタンスをバックアップする方法の詳細については、 [TiDB Cloud Essentialデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 + - TiDB Cloud Essentialインスタンスをバックアップする方法の詳細については、 [TiDB Cloud Essentialデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)を参照してください。 - - TiDB Cloud Dedicatedクラスターをバックアップする方法の詳細については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + - TiDB Cloud Dedicatedクラスターをバックアップする方法の詳細については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 > **注記：** > diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 030de2695773e..1330f77f85b2a 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -150,14 +150,14 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト 4. **データフォーマット**領域で、希望する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)参照してください。 + - 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)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)参照してください。 + - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB拡張**オプションを有効にしてください。 - TiDB 拡張フィールドの詳細については、 [Avroデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields)フィールド」および[Canal-JSONデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)参照してください。 + TiDB 拡張フィールドの詳細については、 [Avroデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol#tidb-extension-fields)フィールド」および[Canal-JSONデータ形式のTiDB拡張フィールド](https://docs.pingcap.com/tidb/stable/ticdc-canal-json#tidb-extension-field)を参照してください。 6. データ形式として**Avroを**選択すると、ページにAvro固有の設定項目が表示されます。これらの設定項目は、以下のように入力できます。 @@ -209,7 +209,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - **レプリケーション係数**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - **パーティション番号**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 -10. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 +10. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 11. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/essential-database-audit-logging.md b/tidb-cloud/essential-database-audit-logging.md index 1071d9ca72638..957845bf69b73 100644 --- a/tidb-cloud/essential-database-audit-logging.md +++ b/tidb-cloud/essential-database-audit-logging.md @@ -57,7 +57,7 @@ TiDB Cloud Essentialは、以下のいずれかの条件が満たされた場合 - `s3:PutObject`権限を持つ[アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)。 - `s3:PutObject`権限を持つ[ロールARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) 。ロールARNの使用は、AWSでホストされているクラスターのみでサポートされています。 -詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 +詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 ### Google Cloud Storage {#google-cloud-storage} @@ -66,7 +66,7 @@ TiDB Cloud Essentialは、以下のいずれかの条件が満たされた場合 - URI: `gs:////` - アクセス資格情報: `storage.objects.create`および`storage.objects.delete`権限を持つサービス[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)。 -詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)参照してください。 +詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 ### Azure Blob Storage {#azure-blob-storage} @@ -75,7 +75,7 @@ Azure Blob Storage に監査ログを保存するには、以下の情報を提 - URI: `azure://.blob.core.windows.net///`または`https://.blob.core.windows.net///` - [共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)資格情報: `Read`および`Write`および { `Container` `Object`権限を持つ共有アクセス宣言（SAS） ブラウザ。 -詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 +詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 ### アリババクラウドOSS {#alibaba-cloud-oss} @@ -84,7 +84,7 @@ Alibaba Cloud OSSに監査ログを保存するには、以下の情報を提供 - URI: `oss:////` - アクセス資格情報: OSS バケットへのデータのエクスポートを許可する`oss:PutObject`および`oss:GetBucketInfo`権限を持つ[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)キーペア。 -詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 +詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 ## 監査ログフィルタルール {#audit-logging-filter-rules} @@ -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`は失敗を意味します。 以下の表は、データベース監査ログにおけるすべてのイベントクラスを示しています。 diff --git a/tidb-cloud/explore-data-with-chat2query.md b/tidb-cloud/explore-data-with-chat2query.md index 6c931dce0f4f3..bd9b51afca918 100644 --- a/tidb-cloud/explore-data-with-chat2query.md +++ b/tidb-cloud/explore-data-with-chat2query.md @@ -173,7 +173,7 @@ TiDB Cloud には、カスタム API エンドポイントを使用して HTTPS 2. **「エンドポイントの生成」**ダイアログボックスで、エンドポイントを生成するデータアプリを選択し、エンドポイント名を入力します。 3. **「生成」**をクリックします。エンドポイントが生成され、その詳細ページが表示されます。 -詳細については、[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)参照してください. +詳細については、[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)を参照してください. ## SQLエディターの設定を管理する {#manage-sql-editor-settings} diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index 3b5b62919f244..5de1cb141bf6f 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -9,7 +9,7 @@ summary: Amazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object St > **注記：** > -> TiDB Cloud Dedicatedについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 +> TiDB Cloud Dedicatedについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。 ## 制限事項 {#limitations} @@ -113,7 +113,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイル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ロールARN** ：AWSロールARNの値を入力してください。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -166,7 +166,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイル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. **「次へ」**をクリックしてください。 @@ -217,7 +217,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[azure|https]://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 + - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 4. **「次へ」**をクリックしてください。 @@ -268,7 +268,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `oss://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 4. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 20dbec18013c9..5357d573c8ae7 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -115,7 +115,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **ソース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 ロール ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する] を**クリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスター**のTiDB Cloudアカウント ID**と**TiDB Cloud外部 ID**を取得し、 IAMロールを手動で作成します。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -170,7 +170,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **ソース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ビュー]**をクリックします。 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 - - **SAS トークン**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)参照してください。 + - **SAS トークン**: 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 eb1e4d1a14d8f..d206e540b555d 100644 --- a/tidb-cloud/import-parquet-files-serverless.md +++ b/tidb-cloud/import-parquet-files-serverless.md @@ -117,7 +117,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイル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ロールARN** ：AWSロールARNの値を入力してください。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -170,7 +170,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイル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. **「次へ」**をクリックしてください。 @@ -221,7 +221,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[azure|https]://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 + - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 4. **「次へ」**をクリックしてください。 @@ -272,7 +272,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 4. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index 3f83bf5c332cd..000ca6434503f 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -9,7 +9,7 @@ summary: Amazon S3、GCS、またはAzure Blob StorageからTiDB Cloud Dedicated > **ヒント：** > -> TiDB Cloud StarterまたはTiDB Cloud Essentialについては、 [クラウドストレージからTiDB Cloud StarterまたはEssentialにApache Parquetファイルをインポートする](/tidb-cloud/import-parquet-files-serverless.md)参照してください。 +> TiDB Cloud StarterまたはTiDB Cloud Essentialについては、 [クラウドストレージからTiDB Cloud StarterまたはEssentialにApache Parquetファイルをインポートする](/tidb-cloud/import-parquet-files-serverless.md)を参照してください。 ## 制限事項 {#limitations} @@ -120,7 +120,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **ソース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 ロール ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する] を**クリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスター**のTiDB Cloudアカウント ID**と**TiDB Cloud外部 ID**を取得し、 IAMロールを手動で作成します。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -173,7 +173,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **ソース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. **「次へ」**をクリックしてください。 @@ -235,7 +235,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 2. ストレージアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 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. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index b6524571ba4ed..7024b72187622 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -104,7 +104,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー - **SASトークン**： - サンプルデータには、次の**SASトークン**を使用してください： `sv=2015-04-05&ss=b&srt=co&sp=rl&se=2099-03-01T00%3A00%3A01.0000000Z&sig=cQHvaofmVsUJEbgyf4JFkAwTJGsFOmbQHx03GvVMrNc%3D` 。 - - 自分のデータについては、SAS トークンを使用して Azure Blob Storage にアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)参照してください。 + - 自分のデータについては、SAS トークンを使用して Azure Blob Storage にアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 4. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/import-snapshot-files-serverless.md b/tidb-cloud/import-snapshot-files-serverless.md index 34392f855e638..205eb6febea05 100644 --- a/tidb-cloud/import-snapshot-files-serverless.md +++ b/tidb-cloud/import-snapshot-files-serverless.md @@ -5,6 +5,6 @@ summary: Amazon Auroraまたは RDS for MySQL スナップショット ファイ # スナップショットファイルをTiDB Cloud StarterまたはEssentialにインポートする {#import-snapshot-files-into-tidb-cloud-starter-or-essential} -Amazon Auroraまたは RDS for MySQL からTiDB Cloud Starter または Essential にスナップショットファイルをインポートできます。まず、これらのスナップショットファイルを Amazon Auroraまたは RDS for MySQL から Parquet ファイルとしてエクスポートする必要があります。インポートを正常に実行するには、データファイルは特定の命名規則に従う必要があります。例えば、各ソースデータファイルは`.parquet`サフィックスを持ち、 `{db_name}.{table_name}/`というフォルダに保存されている必要があります。詳細については、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)参照してください。 +Amazon Auroraまたは RDS for MySQL からTiDB Cloud Starter または Essential にスナップショットファイルをインポートできます。まず、これらのスナップショットファイルを Amazon Auroraまたは RDS for MySQL から Parquet ファイルとしてエクスポートする必要があります。インポートを正常に実行するには、データファイルは特定の命名規則に従う必要があります。例えば、各ソースデータファイルは`.parquet`サフィックスを持ち、 `{db_name}.{table_name}/`というフォルダに保存されている必要があります。詳細については、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)を参照してください。 -スナップショットファイルのインポートプロセスは、他のParquetファイルと同じです。手順については、 [Cloud Storage からTiDB Cloud Starter または Essential に Apache Parquet ファイルをインポートする](/tidb-cloud/import-parquet-files-serverless.md)参照してください。 +スナップショットファイルのインポートプロセスは、他のParquetファイルと同じです。手順については、 [Cloud Storage からTiDB Cloud Starter または Essential に Apache Parquet ファイルをインポートする](/tidb-cloud/import-parquet-files-serverless.md)を参照してください。 diff --git a/tidb-cloud/import-snapshot-files.md b/tidb-cloud/import-snapshot-files.md index 2e859e9ea8be7..519a0a8687675 100644 --- a/tidb-cloud/import-snapshot-files.md +++ b/tidb-cloud/import-snapshot-files.md @@ -7,4 +7,4 @@ summary: Amazon Auroraまたは RDS for MySQL スナップショット ファイ Amazon Auroraまたは RDS for MySQL からTiDB Cloud Dedicated にスナップショットファイルをインポートできます。これらのスナップショットは Parquet ファイルとしてエクスポートされます。インポートを正常に実行するには、データファイルが特定の命名規則に従う必要があります。例えば、各ソースデータファイルは`.parquet`サフィックスを持ち、 `{db_name}.{table_name}/`名前のフォルダに保存されている必要があります。詳細については[データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ご覧ください。 -スナップショットファイルのインポートプロセスは、他のParquetファイルと同じです。手順については、 [Apache Parquet ファイルを Cloud Storage からTiDB Cloud Dedicated にインポートする](/tidb-cloud/import-parquet-files.md)参照してください。 +スナップショットファイルのインポートプロセスは、他のParquetファイルと同じです。手順については、 [Apache Parquet ファイルを Cloud Storage からTiDB Cloud Dedicated にインポートする](/tidb-cloud/import-parquet-files.md)を参照してください。 diff --git a/tidb-cloud/import-with-mysql-cli-serverless.md b/tidb-cloud/import-with-mysql-cli-serverless.md index 1b7ec8358faf7..d2a0486f04af2 100644 --- a/tidb-cloud/import-with-mysql-cli-serverless.md +++ b/tidb-cloud/import-with-mysql-cli-serverless.md @@ -105,7 +105,7 @@ CSVファイルからデータをインポートするには、以下の手順 > **注記：** > -> `LOAD DATA LOCAL INFILE`の構文の詳細については、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 +> `LOAD DATA LOCAL INFILE`の構文の詳細については、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)を参照してください。
diff --git a/tidb-cloud/import-with-mysql-cli.md b/tidb-cloud/import-with-mysql-cli.md index 015431826808e..1841807753116 100644 --- a/tidb-cloud/import-with-mysql-cli.md +++ b/tidb-cloud/import-with-mysql-cli.md @@ -28,7 +28,7 @@ TiDB Cloud Dedicatedクラスターに接続してください。 5. 右上隅にある**「接続」**をクリックすると、接続情報ダイアログが開きます。 - 接続文字列を取得する方法の詳細については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)参照してください。 + 接続文字列を取得する方法の詳細については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 ## ステップ2：テーブルを定義し、サンプルデータを挿入する {#step-2-define-the-table-and-insert-sample-data} @@ -101,7 +101,7 @@ CSVファイルからデータをインポートするには、以下の手順 > **注記：** > -> `LOAD DATA LOCAL INFILE`の構文の詳細については、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 +> `LOAD DATA LOCAL INFILE`の構文の詳細については、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)を参照してください。
diff --git a/tidb-cloud/integrate-tidbcloud-with-airbyte.md b/tidb-cloud/integrate-tidbcloud-with-airbyte.md index a50a2f86548c6..ee2dfd3bf50ff 100644 --- a/tidb-cloud/integrate-tidbcloud-with-airbyte.md +++ b/tidb-cloud/integrate-tidbcloud-with-airbyte.md @@ -68,7 +68,7 @@ Airbyteのバナーが表示されたら、ユーザー名（ `airbyte` ）と TiDBからSnowflakeへの転送や、CSVファイルからTiDBへの転送など、ソースと宛先を自由に組み合わせて使用​​できます。 -TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyte.com/integrations/sources/tidb)と[TiDB宛先](https://docs.airbyte.com/integrations/destinations/tidb)参照してください。 +TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyte.com/integrations/sources/tidb)と[TiDB宛先](https://docs.airbyte.com/integrations/destinations/tidb)を参照してください。 ## 接続を設定する {#set-up-the-connection} diff --git a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md index 4773082a9b5e3..98980f535715e 100644 --- a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md +++ b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md @@ -5,7 +5,7 @@ summary: TiDB Cloud StarterをAmazon LambdaおよびCloudFormationと統合す # AWS CloudFormationを使用してTiDB Cloud StarterをAmazon Lambdaと統合する {#integrate-tidb-cloud-starter-with-amazon-lambda-using-aws-cloudformation} -このドキュメントでは、 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)使用して、クラウドネイティブな分散 SQL データベースである[TiDB Cloud Starter](https://www.pingcap.com/tidb-cloud-starter/)と、サーバーレスでイベント駆動型のコンピューティング サービスである[AWS Lambda](https://aws.amazon.com/lambda/)を統合する手順を段階的に説明します。TiDB Cloud Starter をAmazon Lambda と統合することで、 TiDB Cloud Starterと AWS Lambda を通じてマイクロサービスの拡張性とコスト効率を活用できます。AWS CloudFormation は、Lambda関数、API Gateway、Secrets Manager などの AWS リソースの作成と管理を自動化します。 +このドキュメントでは、 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)を使用して、クラウドネイティブな分散 SQL データベースである[TiDB Cloud Starter](https://www.pingcap.com/tidb-cloud-starter/)と、サーバーレスでイベント駆動型のコンピューティング サービスである[AWS Lambda](https://aws.amazon.com/lambda/)を統合する手順を段階的に説明します。TiDB Cloud Starter をAmazon Lambda と統合することで、 TiDB Cloud Starterと AWS Lambda を通じてマイクロサービスの拡張性とコスト効率を活用できます。AWS CloudFormation は、Lambda関数、API Gateway、Secrets Manager などの AWS リソースの作成と管理を自動化します。 > **注記：** > diff --git a/tidb-cloud/integrate-tidbcloud-with-cloudflare.md b/tidb-cloud/integrate-tidbcloud-with-cloudflare.md index 91f79a224791e..75b272ad5b7a7 100644 --- a/tidb-cloud/integrate-tidbcloud-with-cloudflare.md +++ b/tidb-cloud/integrate-tidbcloud-with-cloudflare.md @@ -20,7 +20,7 @@ Cloudflare WorkersはV8エンジン上で動作するため、直接TCP接続を この記事の手順を試す前に、以下のものを準備する必要があります。 - [TiDB Cloudアカウント](https://tidbcloud.com/signup)。 -- TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス。お持ちでない場合は、 [TiDB Cloud StarterまたはEssentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md)参照してください。 +- TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス。お持ちでない場合は、 [TiDB Cloud StarterまたはEssentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md)を参照してください。 - [Cloudflare Workersアカウント](https://dash.cloudflare.com/login)。 - [npm](https://docs.npmjs.com/about-npm)がインストールされています。 @@ -101,4 +101,4 @@ Cloudflare Workers ダッシュボードから`DATABASE_URL`シークレット ## 例 {#examples} -[Cloudflare Workersの例](https://github.com/tidbcloud/car-sales-insight/tree/main/examples/cloudflare-workers)参照してください。 +[Cloudflare Workersの例](https://github.com/tidbcloud/car-sales-insight/tree/main/examples/cloudflare-workers)を参照してください。 diff --git a/tidb-cloud/integrate-tidbcloud-with-dbt.md b/tidb-cloud/integrate-tidbcloud-with-dbt.md index 74db7e55b57a8..6750abbbd7ae5 100644 --- a/tidb-cloud/integrate-tidbcloud-with-dbt.md +++ b/tidb-cloud/integrate-tidbcloud-with-dbt.md @@ -17,7 +17,7 @@ dbtとdbt-tidbは、たった1つのコマンドでインストールできま pip install dbt-tidb ``` -dbt を個別にインストールすることもできます。 dbt ドキュメントの[dbtのインストール方法](https://docs.getdbt.com/docs/get-started/installation)参照してください。 +dbt を個別にインストールすることもできます。 dbt ドキュメントの[dbtのインストール方法](https://docs.getdbt.com/docs/get-started/installation)を参照してください。 ## ステップ2：デモプロジェクトを作成する {#step-2-create-a-demo-project} @@ -331,7 +331,7 @@ dbtを使用すると、プロジェクト全体の構造を表示し、すべ ## サポートされている関数 {#supported-functions} -dbt-tidb では、以下の関数を直接使用できます。使用方法については、 [dbt-util](https://github.com/dbt-labs/dbt-utils)参照してください。 +dbt-tidb では、以下の関数を直接使用できます。使用方法については、 [dbt-util](https://github.com/dbt-labs/dbt-utils)を参照してください。 以下の関数がサポートされています。 diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index dd909d071e272..5fb4e77fff6e1 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -21,7 +21,7 @@ summary: n8nにおけるTiDB Cloudノードの使い方を学びましょう。 4. APIキーの説明を入力し、 **「次へ」**をクリックしてください。 5. 作成したAPIキーをコピーしてn8nで後で使用するようにし、 **「完了」**をクリックしてください。 -詳細については、 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview)参照してください。 +詳細については、 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview)を参照してください。 ## ステップ1：n8nをインストールする {#step-1-install-n8n} diff --git a/tidb-cloud/integrate-tidbcloud-with-vercel.md b/tidb-cloud/integrate-tidbcloud-with-vercel.md index 4e2ee66d0533b..fa30f5026013d 100644 --- a/tidb-cloud/integrate-tidbcloud-with-vercel.md +++ b/tidb-cloud/integrate-tidbcloud-with-vercel.md @@ -30,7 +30,7 @@ TiDB CloudとVercelを組み合わせることで、MySQL互換のリレーシ Vercelにアカウントとプロジェクトをお持ちであることが前提となります。お持ちでない場合は、以下のVercelドキュメントを参照して作成してください。 - [新しい個人アカウントを作成する](https://vercel.com/docs/teams-and-accounts#creating-a-personal-account)、 [新しいチームを作る](https://vercel.com/docs/teams-and-accounts/create-or-join-a-team#creating-a-team)。 -- Vercel で[プロジェクトの作成](https://vercel.com/docs/concepts/projects/overview#creating-a-project)か、デプロイするアプリケーションがない場合は、 [TiDB Cloud Starterテンプレート](https://vercel.com/templates/next.js/tidb-cloud-starter)使用して試すことができます。 +- Vercel で[プロジェクトの作成](https://vercel.com/docs/concepts/projects/overview#creating-a-project)か、デプロイするアプリケーションがない場合は、 [TiDB Cloud Starterテンプレート](https://vercel.com/templates/next.js/tidb-cloud-starter)を使用して試すことができます。 Vercelプロジェクトは、1つのTiDB Cloudクラスターにしか接続できません。統合を変更するには、まず現在のクラスターとの接続を解除してから、新しいクラスターに接続する必要があります。 @@ -209,7 +209,7 @@ Gitリポジトリに変更をプッシュすると、Vercelがプレビュー > **注記：** > -> TiDB Cloudの各組織では、デフォルトではTiDB Cloud Starterインスタンス用に最大 5 つのブランチを作成できます。制限を超えないようにするには、不要になったTiDB Cloud Starterインスタンスのブランチを削除してください。詳細については、 [TiDB Cloudブランチを管理する](/tidb-cloud/branch-manage.md)参照してください。 . +> TiDB Cloudの各組織では、デフォルトではTiDB Cloud Starterインスタンス用に最大 5 つのブランチを作成できます。制限を超えないようにするには、不要になったTiDB Cloud Starterインスタンスのブランチを削除してください。詳細については、 [TiDB Cloudブランチを管理する](/tidb-cloud/branch-manage.md)を参照してください。 . ## 環境変数を手動で設定して接続します {#connect-via-manually-setting-environment-variables} diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index 6f9d41f85340c..16b8c6c43c940 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -7,7 +7,7 @@ summary: TiDB CloudをZapierを使って5000以上のアプリに接続する方 [Zapier](https://zapier.com)数千ものアプリやサービスを含むワークフローを簡単に作成できる、ノーコードの自動化ツールです。 -Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations)使用すると、次のことが可能になります。 +Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations)を使用すると、次のことが可能になります。 - MySQL互換のHTAPデータベースであるTiDBを使用してください。ローカルでの構築は不要です。 - TiDB Cloudの管理をより簡単にします。 diff --git a/tidb-cloud/manage-projects-and-resources.md b/tidb-cloud/manage-projects-and-resources.md index a5bc81e35abca..7fc5037ee7a95 100644 --- a/tidb-cloud/manage-projects-and-resources.md +++ b/tidb-cloud/manage-projects-and-resources.md @@ -114,7 +114,7 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 2. プロジェクトビューで、対象のプロジェクトを見つけて、次のように管理します。 - - TiDB X プロジェクトとTiDB Dedicatedプロジェクトの両方で、ターゲット プロジェクトの行にある**[...]**をクリックして、プロジェクトの名前変更やプロジェクトへのメンバーの招待など、プロジェクトに対してクイック アクションを実行できます。詳細については、[プロジェクトへのアクセスを管理する](/tidb-cloud/manage-user-access.md)参照してください。 + - TiDB X プロジェクトとTiDB Dedicatedプロジェクトの両方で、ターゲット プロジェクトの行にある**[...]**をクリックして、プロジェクトの名前変更やプロジェクトへのメンバーの招待など、プロジェクトに対してクイック アクションを実行できます。詳細については、[プロジェクトへのアクセスを管理する](/tidb-cloud/manage-user-access.md)を参照してください。 - TiDB Dedicatedプロジェクトの場合、対象プロジェクトの行にあるアイコンをクリックすると、プロジェクトごとにTiDB Cloud Dedicatedクラスターのネットワーク、メンテナンス、アラートの購読、暗号化アクセスなどの設定を管理できます。 ### TiDB Xインスタンスをプロジェクト間で移動する {#move-a-tidb-x-instance-between-projects} diff --git a/tidb-cloud/manage-serverless-spend-limit.md b/tidb-cloud/manage-serverless-spend-limit.md index 95e50ff224645..85e30173c754c 100644 --- a/tidb-cloud/manage-serverless-spend-limit.md +++ b/tidb-cloud/manage-serverless-spend-limit.md @@ -23,9 +23,9 @@ TiDB Cloudの各組織につき、最大 5 つの [無料のTiDB Cloud Starter TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud StarterTiDB Cloud Starterの行ベースのストレージが5 GiB を超えると、 TiDB Cloud Starterインスタンスは自動的に新しい接続試行を制限します。 -さまざまなリソース（読み取り、書き込み、SQL CPU、ネットワーク出力など）のRU消費量、価格の詳細、およびスロットリング情報の詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +さまざまなリソース（読み取り、書き込み、SQL CPU、ネットワーク出力など）のRU消費量、価格の詳細、およびスロットリング情報の詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 -追加のクォータを使用してTiDB Cloud Starterインスタンスを作成する場合は、 TiDB Cloud Starterインスタンスの作成ページで支出制限を編集できます。詳細については、 [TiDB Cloud Starterインスタンスを作成する](/tidb-cloud/create-tidb-cluster-serverless.md)参照してください。 +追加のクォータを使用してTiDB Cloud Starterインスタンスを作成する場合は、 TiDB Cloud Starterインスタンスの作成ページで支出制限を編集できます。詳細については、 [TiDB Cloud Starterインスタンスを作成する](/tidb-cloud/create-tidb-cluster-serverless.md)を参照してください。 ## 支出限度額を更新する {#update-spending-limit} diff --git a/tidb-cloud/manage-user-access.md b/tidb-cloud/manage-user-access.md index 334654baadb5f..ba0f6f0c6c417 100644 --- a/tidb-cloud/manage-user-access.md +++ b/tidb-cloud/manage-user-access.md @@ -256,7 +256,7 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー ## プロジェクトへのアクセスを管理する {#manage-project-access} -このセクションでは、プロジェクトの名前を変更する方法と、プロジェクト メンバーを招待および削除する方法について説明します。プロジェクトを作成または管理する方法については、 [プロジェクトを管理する](/tidb-cloud/manage-projects-and-resources.md#manage-tidb-cloud-projects)参照してください。 +このセクションでは、プロジェクトの名前を変更する方法と、プロジェクト メンバーを招待および削除する方法について説明します。プロジェクトを作成または管理する方法については、 [プロジェクトを管理する](/tidb-cloud/manage-projects-and-resources.md#manage-tidb-cloud-projects)を参照してください。 ### プロジェクト名を変更する {#rename-a-project} diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index 939333bb395d4..6441246a5a97d 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -18,10 +18,10 @@ 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 と互換性のある照合順序を使用していることを確認してください。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 クラスターを接続します。 +- [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`データベースを自動的に作成します。 @@ -29,7 +29,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ## 制限 {#limitation} - AWS DMS は`DROP TABLE`のレプリケーションをサポートしていません。 -- AWS DMS は、テーブルや主キーの作成など、基本的なスキーマ移行をサポートしています。ただし、AWS DMS はTiDB Cloudにセカンダリインデックス、外部キー、ユーザーアカウントを自動的に作成しません。必要に応じて、セカンダリインデックスを持つテーブルを含め、これらのオブジェクトを TiDB に手動で作成する必要があります。詳細については、 [AWS Database Migration Service の移行計画](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html#CHAP_SettingUp.MigrationPlanning)参照してください。 +- AWS DMS は、テーブルや主キーの作成など、基本的なスキーマ移行をサポートしています。ただし、AWS DMS はTiDB Cloudにセカンダリインデックス、外部キー、ユーザーアカウントを自動的に作成しません。必要に応じて、セカンダリインデックスを持つテーブルを含め、これらのオブジェクトを TiDB に手動で作成する必要があります。詳細については、 [AWS Database Migration Service の移行計画](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_BestPractices.html#CHAP_SettingUp.MigrationPlanning)を参照してください。 ## ステップ1. AWS DMSレプリケーションインスタンスを作成する {#step-1-create-an-aws-dms-replication-instance} @@ -106,7 +106,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 5. ダイアログの**「VPCピアリング」**タブをクリックし、 **「ステップ1：VPCの設定**」の下にある**「追加」**をクリックして、TiDBクラスターとAWS DMSのVPCピアリング接続を作成します。 -6. 対応する情報を設定します。 [VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)参照してください。 +6. 対応する情報を設定します。 [VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 7. TiDBクラスタのターゲットエンドポイントを設定します。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 8f846eb5cb02b..00a8709e4b6ae 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -26,7 +26,7 @@ aliases: ['/ja/tidbcloud/migrate-data-into-tidb','/ja/tidbcloud/migrate-incremen この機能により、既存のMySQLデータを移行し、MySQL互換のソースデータベースからTiDB Cloudへ進行中の変更（binlog）を継続的にレプリケートできます。これにより、同一リージョン内または異なるリージョン間でデータの一貫性が維持されます。合理化されたプロセスにより、個別のダンプおよびロード操作が不要になり、ダウンタイムが短縮され、MySQLからよりスケーラブルなプラットフォームへの移行が簡素化されます。 -進行中のbinlogの変更を MySQL 互換データベースからTiDB Cloudにレプリケートするだけの場合は、 [データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データを移行する](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)参照してください。 +進行中のbinlogの変更を MySQL 互換データベースからTiDB Cloudにレプリケートするだけの場合は、 [データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データを移行する](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)を参照してください。 ## 制限事項 {#limitations} @@ -243,7 +243,7 @@ SHOW VARIABLES WHERE Variable_name IN 3. パラメータグループをインスタンスまたはクラスターにアタッチし、再起動して変更を適用してください。 4. 再起動後、インスタンスに接続し、 `SHOW VARIABLES`ステートメントを実行して構成を確認します。 -詳細な手順については、AWS ドキュメントの[DBパラメータグループの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)と[MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)参照してください。 +詳細な手順については、AWS ドキュメントの[DBパラメータグループの操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)と[MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)を参照してください。 @@ -257,7 +257,7 @@ SHOW VARIABLES WHERE Variable_name IN 3. `SHOW VARIABLES`ステートメントを実行して、設定を確認します。 -詳細な手順については、Microsoft Azure ドキュメントの[Azure ポータルを使用して、Azure Database for MySQL - Flexible Server でサーバーパラメーターを構成する](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-configure-server-parameters-portal)参照してください。 +詳細な手順については、Microsoft Azure ドキュメントの[Azure ポータルを使用して、Azure Database for MySQL - Flexible Server でサーバーパラメーターを構成する](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-configure-server-parameters-portal)を参照してください。 @@ -290,7 +290,7 @@ SHOW VARIABLES WHERE Variable_name IN 4. 変更を適用した後（必要に応じて再起動した後）、インスタンスに接続し、このセクションの`SHOW VARIABLES`ステートメントを実行して構成を確認します。 -詳細については、 [インスタンスパラメータを設定します](https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/modify-the-parameters-of-an-apsaradb-rds-for-mysql-instance)参照してください。 +詳細については、 [インスタンスパラメータを設定します](https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/modify-the-parameters-of-an-apsaradb-rds-for-mysql-instance)を参照してください。 @@ -399,9 +399,9 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ > **注記：** > - > 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/)参照してください。 + > 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/)を参照してください。 - 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)参照してください。 + 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**[エンドポイント サービス]**をクリックし、 **[エンドポイント サービスの作成]**をクリックします。次の設定を構成します。 @@ -411,7 +411,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名は`com.amazonaws.vpce..vpce-svc-`の形式です。たとえば、 `com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0`ようになります。 - 詳細な手順については、AWS ドキュメントの[エンドポイントサービスを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)参照してください。 + 詳細な手順については、AWS ドキュメントの[エンドポイントサービスを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)を参照してください。 3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **[プリンシパルの許可]**タブを開き、 **[プリンシパルの許可]**をクリックして、次のARNを追加します。 @@ -421,7 +421,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ この手順を行わないと、 TiDB Cloud はサービスに接続する VPC エンドポイントを作成できず、 TiDB Cloudの**「外部サービス用のプライベートエンドポイントの作成」**ダイアログがエラーメッセージも表示されずに永久に停止してしまいます。 - 詳細な手順については、AWS ドキュメントの[権限を管理する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions)参照してください。 + 詳細な手順については、AWS ドキュメントの[権限を管理する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions)を参照してください。 4. オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。 @@ -445,7 +445,7 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ セットアップ中に、[仮想**ネットワーク]**タブでTiDB Cloud がアクセスできる仮想ネットワークとサブネットを選択し、 **[DNS]**タブで**[プライベート DNS 統合] を**有効にします。プライベートエンドポイントが作成されてデプロイされたら、 **[リソースに移動] を**クリックし、左側のナビゲーション ペインで**[設定]** > **[DNS 構成] を**クリックして、[**顧客可視 FQDN]**セクションでインスタンスへの接続に使用するホスト名を見つけます。通常、ホスト名は`.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)参照してください。 + 詳細な手順については、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)を参照してください。 3. オプション：移行を開始する前に、同じVPCまたはVNet内の踏み台サーバーまたはクライアントから接続テストを実施してください。 @@ -462,7 +462,7 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ -プロバイダーネイティブのプライベート リンクまたはプライベート エンドポイントを使用する場合は、ソース MySQL インスタンスに対して[プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)作成します。 +プロバイダーネイティブのプライベート リンクまたはプライベート エンドポイントを使用する場合は、ソース MySQL インスタンスに対して[プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)を作成します。 @@ -485,9 +485,9 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ > **注記：** > - > 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/)参照してください。 + > 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/)を参照してください。 - 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)参照してください。 + 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**[エンドポイント サービス]**をクリックし、 **[エンドポイント サービスの作成]**をクリックします。次の設定を構成します。 @@ -497,7 +497,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名は`com.amazonaws.vpce..vpce-svc-`の形式です。たとえば、 `com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0`ようになります。 - 詳細な手順については、AWS ドキュメントの[エンドポイントサービスを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)参照してください。 + 詳細な手順については、AWS ドキュメントの[エンドポイントサービスを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)を参照してください。 3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **[プリンシパルの許可]**タブを開き、 **[プリンシパルの許可]**をクリックして、次のARNを追加します。 @@ -507,7 +507,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ この手順を行わないと、 TiDB Cloud はサービスに接続する VPC エンドポイントを作成できず、 TiDB Cloudの**「外部サービス用のプライベートエンドポイントの作成」**ダイアログがエラーメッセージも表示されずに永久に停止してしまいます。 - 詳細な手順については、AWS ドキュメントの[権限を管理する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions)参照してください。 + 詳細な手順については、AWS ドキュメントの[権限を管理する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions)を参照してください。 4. オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。 @@ -578,7 +578,7 @@ MySQLサービスがAWS VPC内にある場合は、以下の手順を実行し MySQLサービスがGoogle Cloud VPC内にある場合は、以下の手順を実行してください。 -1. セルフホスト型のMySQLの場合は、この手順をスキップして次の手順に進んでください。MySQLサービスがGoogle Cloud SQLの場合は、Google Cloud SQLインスタンスに関連付けられたVPCにMySQLエンドポイントを公開する必要があります。Googleが開発した[Cloud SQL認証プロキシ](https://cloud.google.com/sql/docs/mysql/sql-proxy)使用する必要があるかもしれません。 +1. セルフホスト型のMySQLの場合は、この手順をスキップして次の手順に進んでください。MySQLサービスがGoogle Cloud SQLの場合は、Google Cloud SQLインスタンスに関連付けられたVPCにMySQLエンドポイントを公開する必要があります。Googleが開発した[Cloud SQL認証プロキシ](https://cloud.google.com/sql/docs/mysql/sql-proxy)を使用する必要があるかもしれません。 2. MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 @@ -869,7 +869,7 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 ** ソースデータベースの増分データのみをTiDB Cloudに移行するには、 **「増分データ移行」**を選択します。この場合、移行ジョブはソースデータベースの既存データをTiDB Cloudに移行せず、移行ジョブで明示的に指定されたソースデータベースの進行中の変更のみを移行します。 -増分データ移行の詳細な手順については、 [データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データのみを移行する](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)参照してください。 +増分データ移行の詳細な手順については、 [データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データのみを移行する](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)を参照してください。 ## ステップ4：移行するオブジェクトを選択する {#step-4-choose-the-objects-to-be-migrated} @@ -889,7 +889,7 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 ** エラーと解決策の詳細については、 [事前チェックのエラーと解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#precheck-errors-and-solutions)を参照してください。 -事前チェック項目の詳細については、 [移行タスクの事前チェック](https://docs.pingcap.com/tidb/stable/dm-precheck)参照してください。 +事前チェック項目の詳細については、 [移行タスクの事前チェック](https://docs.pingcap.com/tidb/stable/dm-precheck)を参照してください。 すべてのチェック項目が**「合格」**と表示されたら、 **「次へ」**をクリックしてください。 @@ -905,7 +905,7 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 ** 移行ジョブはどのステータスでも削除できます。 -移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 +移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 @@ -917,7 +917,7 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 ** 移行ジョブは、実行中でも一時停止または削除できます。移行ジョブが失敗した場合は、問題を解決した後に再開できます。移行ジョブは、どの状態でも削除できます。 -移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 +移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 > **注記：** > @@ -929,7 +929,7 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 ** ## ステップ6：仕様を選択して移行を開始する {#step-6-choose-a-spec-and-start-migration} -**「仕様を選択して移行を開始」**ページで、パフォーマンス要件に応じて適切な移行仕様を選択します。仕様の詳細については、 [データ移行の仕様](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)参照してください。 +**「仕様を選択して移行を開始」**ページで、パフォーマンス要件に応じて適切な移行仕様を選択します。仕様の詳細については、 [データ移行の仕様](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)を参照してください。 仕様を選択したら、 **「ジョブの作成」をクリックし、「開始」を**クリックして移行を開始します。 @@ -943,7 +943,7 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 ** 移行ジョブはどのステータスでも削除できます。 -移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 +移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 ## 移行ジョブ仕様を拡張する {#scale-a-migration-job-specification} diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 1daaef714e36a..9dc3bd98d1fa6 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -63,7 +63,7 @@ tiup update --self && tiup update dumpling 1. [ツールキットパッケージ](https://docs.pingcap.com/tidb/stable/download-ecosystem-tools)をダウンロードします。 -2. 対象マシンに展開してください。TiUPを使用して`tiup install dumpling`を実行すると、 Dumpling を入手できます。その後、 `tiup dumpling ...`を使用してDumplingを実行できます。詳細については、 [Dumplingの紹介](https://docs.pingcap.com/tidb/stable/dumpling-overview#dumpling-introduction)参照してください。 。 +2. 対象マシンに展開してください。TiUPを使用して`tiup install dumpling`を実行すると、 Dumpling を入手できます。その後、 `tiup dumpling ...`を使用してDumplingを実行できます。詳細については、 [Dumplingの紹介](https://docs.pingcap.com/tidb/stable/dumpling-overview#dumpling-introduction)を参照してください。 。 #### Dumplingの権限を設定する {#configure-privileges-for-dumpling} @@ -79,9 +79,9 @@ tiup update --self && tiup update dumpling アップストリームの TiDB Self-Managed クラスターからダウンストリームのTiDB Cloudリソースに増分データをレプリケートするには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 -1. アップストリーム TiDB Self-Managedクラスターの現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、上流の TiDB Self-Managedクラスターで`select tidb_version();`を実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 +1. アップストリーム TiDB Self-Managedクラスターの現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、上流の TiDB Self-Managedクラスターで`select tidb_version();`を実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)を参照してください。 -2. TiCDCコンポーネントをアップストリームの TiDB Self-Managedクラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 +2. TiCDCコンポーネントをアップストリームの TiDB Self-Managedクラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)を参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 ```yaml cdc_servers: @@ -137,7 +137,7 @@ SELECT @@global.tidb_gc_enable; #### ステップ2. Dumpling用のAmazon S3バケットへのアクセス権限を設定します {#step-2-configure-access-permissions-to-the-amazon-s3-bucket-for-dumpling} -AWS コンソールでアクセスキーを作成します。詳細については[アクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)参照してください。 +AWS コンソールでアクセスキーを作成します。詳細については[アクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)を参照してください。 1. AWSアカウントIDまたはアカウントエイリアス、 IAMユーザー名、およびパスワードを使用して[IAMコンソール](https://console.aws.amazon.com/iam/home#/security_credentials)にサインインしてください。 @@ -160,7 +160,7 @@ Dumplingを使用して、アップストリームのTiDBクラスタからAmazo export AWS_SECRET_ACCESS_KEY=${SecretKey} ``` -2. AWS コンソールから S3 バケット URI とリージョン情報を取得します。詳細については[バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)参照してください。 +2. AWS コンソールから S3 バケット URI とリージョン情報を取得します。詳細については[バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照してください。 以下のスクリーンショットは、S3バケットURI情報を取得する方法を示しています。 @@ -203,8 +203,8 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 1. [TiDB Cloudコンソール](https://tidbcloud.com/)以下のドキュメントに従って、対象のTiDBリソースのアカウントIDと外部IDを取得してください。 - - TiDB Cloud Dedicatedクラスターについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access-using-a-role-arn)参照してください。 - - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access-using-a-role-arn)参照してください。 + - TiDB Cloud Dedicatedクラスターについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access-using-a-role-arn)を参照してください。 + - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access-using-a-role-arn)を参照してください。 2. Amazon S3 のアクセス権限を設定します。通常、以下の読み取り専用権限が必要です。 @@ -264,7 +264,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート } ``` -4. 役割を設定します。 [IAMロールの作成（コンソール）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)参照してください。 「アカウント ID」フィールドに、ステップ 1 で書き留めたTiDB Cloudアカウント ID とTiDB Cloud外部 ID を入力します。 +4. 役割を設定します。 [IAMロールの作成（コンソール）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)を参照してください。 「アカウント ID」フィールドに、ステップ 1 で書き留めたTiDB Cloudアカウント ID とTiDB Cloud外部 ID を入力します。 5. ロール ARN を取得します。 [AWSコンソール > IAM > アクセス管理 > ロール](https://console.aws.amazon.com/iamv2/home#/roles)。お住まいの地域に切り替えてください。作成したロールをクリックし、ARN をメモします。これは、データをTiDB Cloudにインポートするときに使用します。 @@ -287,8 +287,8 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 3. TiDB Cloudのプランに応じて、TiCDCがTiDB Cloudに接続できるようにするために、以下のいずれかの操作を行ってください。 - - TiDB Cloud StarterまたはEssentialの場合は、 **「認可されたネットワーク」**セクションで**「ルールの追加」**をクリックします。表示されたダイアログで、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の場合は、 **「IP アドレスの追加」**をクリックします。表示されたダイアログで、 **[IP アドレスを使用する]**を選択し、 [ **+]**をクリックし、TiCDCコンポーネントのパブリック IP アドレスを**[IP アドレス]**フィールドに入力して、 **[確認]**をクリックします。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 + - TiDB Cloud StarterまたはEssentialの場合は、 **「認可されたネットワーク」**セクションで**「ルールの追加」**をクリックします。表示されたダイアログで、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の場合は、 **「IP アドレスの追加」**をクリックします。表示されたダイアログで、 **[IP アドレスを使用する]**を選択し、 [ **+]**をクリックし、TiCDCコンポーネントのパブリック IP アドレスを**[IP アドレス]**フィールドに入力して、 **[確認]**をクリックします。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 3. 下流のTiDB Cloudリソースの接続情報を取得します。 diff --git a/tidb-cloud/migrate-from-oracle-using-aws-dms.md b/tidb-cloud/migrate-from-oracle-using-aws-dms.md index 9d1d5eef2e447..02bebc35e5154 100644 --- a/tidb-cloud/migrate-from-oracle-using-aws-dms.md +++ b/tidb-cloud/migrate-from-oracle-using-aws-dms.md @@ -50,7 +50,7 @@ PostgreSQL、Oracle、SQL Serverなどの異種データベースからTiDB Clou [AWSコンソール](https://console.aws.amazon.com/vpc/home#vpcs:)にログインし、AWS VPCを作成してください。後でこのVPC内にOracle RDSおよびDMSインスタンスを作成する必要があります。 -VPC の作成方法については、 [VPCの作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)参照してください。 +VPC の作成方法については、 [VPCの作成](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)を参照してください。 ![Create VPC](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-1.png) @@ -113,15 +113,15 @@ SQLスクリプトの実行が完了したら、Oracleのデータを確認し > **注記：** > -> TiDB Cloud Starter DMS エンドポイントを作成する詳細な手順については、 [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md)参照してください。 +> TiDB Cloud Starter DMS エンドポイントを作成する詳細な手順については、 [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md)を参照してください。 ## ステップ7．スキーマを移行する {#step-7-migrate-the-schema} この例では、スキーマ定義が単純なため、AWS DMS がスキーマを自動的に処理します。 -AWS Schema Conversion Tool を使用してスキーマを移行する場合は、 [AWS SCTのインストール](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html#CHAP_Installing.Procedure)参照してください。 +AWS Schema Conversion Tool を使用してスキーマを移行する場合は、 [AWS SCTのインストール](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html#CHAP_Installing.Procedure)を参照してください。 -詳細については、 [AWS SCTを使用してソーススキーマをターゲットデータベースに移行する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.SCT.html)参照してください。 +詳細については、 [AWS SCTを使用してソーススキーマをターゲットデータベースに移行する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.SCT.html)を参照してください。 ## ステップ8. データベース移行タスクを作成する {#step-8-create-a-database-migration-task} 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 4dcb205541f4a..0634afddac4e3 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 @@ -23,7 +23,7 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa -既存のデータ、または既存のデータと増分データの両方を移行する方法については、 [データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 +既存のデータ、または既存のデータと増分データの両方を移行する方法については、 [データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を参照してください。 ## 制限事項 {#limitations} @@ -281,7 +281,7 @@ SHOW MASTER STATUS; エラーと解決策の詳細については、 [事前チェックのエラーと解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#precheck-errors-and-solutions)を参照してください。 -事前チェック項目の詳細については、 [移行タスクの事前チェック](https://docs.pingcap.com/tidb/stable/dm-precheck)参照してください。 +事前チェック項目の詳細については、 [移行タスクの事前チェック](https://docs.pingcap.com/tidb/stable/dm-precheck)を参照してください。 すべてのチェック項目が**「合格」**と表示されたら、 **「次へ」**をクリックしてください。 @@ -297,7 +297,7 @@ SHOW MASTER STATUS; 移行ジョブはどのステータスでも削除できます。 -移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 +移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 @@ -305,7 +305,7 @@ SHOW MASTER STATUS; ## ステップ6：仕様を選択して移行を開始する {#step-6-choose-a-spec-and-start-migration} -**「仕様を選択して移行を開始」**ページで、パフォーマンス要件に応じて適切な移行仕様を選択します。仕様の詳細については、 [データ移行の仕様](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)参照してください。 +**「仕様を選択して移行を開始」**ページで、パフォーマンス要件に応じて適切な移行仕様を選択します。仕様の詳細については、 [データ移行の仕様](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)を参照してください。 仕様を選択したら、 **「ジョブの作成」をクリックし、「開始」を**クリックして移行を開始します。 @@ -319,6 +319,6 @@ SHOW MASTER STATUS; 移行ジョブはどのステータスでも削除できます。 -移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 +移行中に問題が発生した場合は、 [移行エラーとその解決策](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 diff --git a/tidb-cloud/migrate-metrics-integrations.md b/tidb-cloud/migrate-metrics-integrations.md index 2d11ab0228e52..66281cfcff850 100644 --- a/tidb-cloud/migrate-metrics-integrations.md +++ b/tidb-cloud/migrate-metrics-integrations.md @@ -37,7 +37,7 @@ TiDB Cloudは、DatadogおよびNew Relicとの連携をクラスタレベルで 2. 左側のナビゲーションパネルで、 **[設定]** > **[統合]**をクリックします。 -3. **「統合」**ページで、必要に応じて新しい統合を作成します。詳細については、 [TiDB CloudとDatadogを統合する](/tidb-cloud/monitor-datadog-integration.md)および[TiDB CloudとNew Relicを統合する](/tidb-cloud/monitor-new-relic-integration.md)参照してください。 +3. **「統合」**ページで、必要に応じて新しい統合を作成します。詳細については、 [TiDB CloudとDatadogを統合する](/tidb-cloud/monitor-datadog-integration.md)および[TiDB CloudとNew Relicを統合する](/tidb-cloud/monitor-new-relic-integration.md)を参照してください。 ## インパクトステートメント {#impact-statement} diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md index bac03958269a6..dafaf238e263e 100644 --- a/tidb-cloud/migrate-sql-shards.md +++ b/tidb-cloud/migrate-sql-shards.md @@ -68,14 +68,14 @@ Amazon S3 バケット内に、第 1 階層ディレクトリ`store` (データ ### ステップ2. Dumplingを使用してデータをAmazon S3にエクスポートする {#step-2-use-dumpling-to-export-data-to-amazon-s3} -Dumpling のインストール方法については、 [Dumplingの紹介](https://docs.pingcap.com/tidb/stable/dumpling-overview)参照してください。 +Dumpling のインストール方法については、 [Dumplingの紹介](https://docs.pingcap.com/tidb/stable/dumpling-overview)を参照してください。 Dumplingを使用してデータをAmazon S3にエクスポートする場合、以下の点に注意してください。 - アップストリームクラスターのbinlogを有効にします。 - 適切なAmazon S3ディレクトリとリージョンを選択してください。 -- 上流クラスタへの影響を最小限に抑えるには、 `-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)参照してください。 +- 上流クラスタへの影響を最小限に抑えるには、 `-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ファイルの名前は以下のようにしてください。 @@ -100,7 +100,7 @@ CSVファイルの名前は以下のようにしてください。 [root@localhost ~]# tiup dumpling -u {username} -p {password} -P {port} -h {mysql01-ip} -B store_01,store_02 -r 20000 --filetype csv --no-schemas -o "s3://dumpling-s3/store/sales/instance01/" --s3.region "ap-northeast-1" ``` - パラメータの詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)参照してください。 + パラメータの詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)を参照してください。 3. MySQL instance2 から Amazon S3 バケット内の`s3://dumpling-s3/store/sales/instance02/`ディレクトリにデータをエクスポートします。 @@ -108,7 +108,7 @@ CSVファイルの名前は以下のようにしてください。 [root@localhost ~]# tiup dumpling -u {username} -p {password} -P {port} -h {mysql02-ip} -B store_01,store_02 -r 20000 --filetype csv --no-schemas -o "s3://dumpling-s3/store/sales/instance02/" --s3.region "ap-northeast-1" ``` -詳細な手順については、 [データをAmazon S3クラウドストレージにエクスポートする](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-data-to-amazon-s3-cloud-storage)参照してください。 +詳細な手順については、 [データをAmazon S3クラウドストレージにエクスポートする](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-data-to-amazon-s3-cloud-storage)を参照してください。 ### ステップ3. スキーマを作成しますTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスター {#step-3-create-schemas-in-customcontent-plan-starter-tidb-cloud-starter-instance-customcontent-customcontent-plan-essential-tidb-cloud-essential-instance-customcontent-customcontent-plan-premium-tidb-cloud-premium-instance-customcontent-customcontent-plan-dedicated-tidb-cloud-dedicated-cluster-customcontent} @@ -134,7 +134,7 @@ mysql> CREATE TABLE `sales` ( Query OK, 0 rows affected (0.17 sec) ``` -このような競合を解決する解決策の詳細については、 [列からPRIMARY KEY属性を削除します](https://docs.pingcap.com/tidb/stable/shard-merge-best-practices#remove-the-primary-key-attribute-from-the-column)参照してください。 +このような競合を解決する解決策の詳細については、 [列からPRIMARY KEY属性を削除します](https://docs.pingcap.com/tidb/stable/shard-merge-best-practices#remove-the-primary-key-attribute-from-the-column)を参照してください。 ### ステップ4. Amazon S3へのアクセスを設定する {#step-4-configure-amazon-s3-access} @@ -197,7 +197,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 バケットの場所が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. **「接続」**をクリックしてください。 @@ -437,7 +437,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ignore-checking-items: ["table_schema","auto_increment_ID"] ``` -タスク構成の詳細については、 [DMタスク構成](https://docs.pingcap.com/tidb/stable/task-configuration-file-full)参照してください。 +タスク構成の詳細については、 [DMタスク構成](https://docs.pingcap.com/tidb/stable/task-configuration-file-full)を参照してください。 データレプリケーションタスクをスムーズに実行するために、DM はタスクの開始時に自動的に事前チェックをトリガーし、チェック結果を返します。DM は事前チェックに合格した後にのみレプリケーションを開始します。事前チェックを手動でトリガーするには、check-task コマンドを実行します。 @@ -600,4 +600,4 @@ DM クラスターでレプリケーション タスクが進行中かどうか } ``` -結果の詳細な解釈については、 [クエリステータス](https://docs.pingcap.com/tidb/stable/dm-query-status)参照してください。 +結果の詳細な解釈については、 [クエリステータス](https://docs.pingcap.com/tidb/stable/dm-query-status)を参照してください。 diff --git a/tidb-cloud/monitor-alert-zoom.md b/tidb-cloud/monitor-alert-zoom.md index f2089ba3fb2b3..ceb97e04df09c 100644 --- a/tidb-cloud/monitor-alert-zoom.md +++ b/tidb-cloud/monitor-alert-zoom.md @@ -34,7 +34,7 @@ TiDB Cloud は、Zoom、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メール ### ステップ1. Zoom Incoming Webhookアプリを追加する {#step-1-add-the-zoom-incoming-webhook-app} 1. [Zoomアプリマーケットプレイス](https://marketplace.zoom.us/)にアカウント管理者としてサインインします。 -2. Zoom App Marketplaceの[受信Webhookアプリ](https://marketplace.zoom.us/apps/eH_dLuquRd-VYcOsNGy-hQ)ページに移動し、 **「追加」**をクリックしてこのアプリを追加します。アプリが事前承認されていない場合は、Zoom 管理者に連絡して、アカウントに対してこのアプリを承認してもらいます。詳細については、 [アプリの承認とアプリリクエストの管理](https://support.zoom.us/hc/en-us/articles/360027829671)参照してください。 +2. Zoom App Marketplaceの[受信Webhookアプリ](https://marketplace.zoom.us/apps/eH_dLuquRd-VYcOsNGy-hQ)ページに移動し、 **「追加」**をクリックしてこのアプリを追加します。アプリが事前承認されていない場合は、Zoom 管理者に連絡して、アカウントに対してこのアプリを承認してもらいます。詳細については、 [アプリの承認とアプリリクエストの管理](https://support.zoom.us/hc/en-us/articles/360027829671)を参照してください。 3. アプリが必要とする権限を確認し、 **「承認」**をクリックして受信Webhookアプリを追加します。 ### ステップ2. ZoomのWebhook URLを生成する {#step-2-generate-a-zoom-webhook-url} diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index 91383defb18e6..b8c43b9fa1a99 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -112,11 +112,11 @@ TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md) | 状態 | 推奨される行動 | | :------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| データ移行ジョブでデータエクスポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 | -| データ移行ジョブのデータインポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 | -| データ移行ジョブで増分移行中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 | -| データ移行ジョブが増分移行中に6時間以上一時停止しています | データの増分移行中に、データ移行ジョブが 6 時間以上一時停止されました。アップストリーム データベースのbinlogがパージされる可能性があり (データベースのbinlogパージ戦略によって異なります)、増分移行が失敗する可能性があります。ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 | -| レプリケーション遅延は10分を超え、20分以上経過しても増加し続けている。 | ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)参照してください。 | +| データ移行ジョブでデータエクスポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | +| データ移行ジョブのデータインポート中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | +| データ移行ジョブで増分移行中にエラーが発生しました | エラーを確認し、ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | +| データ移行ジョブが増分移行中に6時間以上一時停止しています | データの増分移行中に、データ移行ジョブが 6 時間以上一時停止されました。アップストリーム データベースのbinlogがパージされる可能性があり (データベースのbinlogパージ戦略によって異なります)、増分移行が失敗する可能性があります。ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | +| レプリケーション遅延は10分を超え、20分以上経過しても増加し続けている。 | ヘルプについては[データ移行のトラブルシューティング](/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md#migration-errors-and-solutions)を参照してください。 | ### TiDB Cloud Dedicatedの変更フィードアラート {#changefeed-alerts-for-tidb-cloud-dedicated} diff --git a/tidb-cloud/optimize-resource-allocation.md b/tidb-cloud/optimize-resource-allocation.md index 8bf04d1738e9d..1f9866f22929d 100644 --- a/tidb-cloud/optimize-resource-allocation.md +++ b/tidb-cloud/optimize-resource-allocation.md @@ -11,9 +11,9 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups ## リソース制御を使用する {#use-resource-control} -[リソース管理](/tidb-resource-control-ru-groups.md)使用すると、 TiDB Cloud Dedicatedクラスタのストレージノード（TiKVまたはTiFlash ）を複数の論理グループに分割できます。混在ワークロードを持つシステムでは、ワークロードを個別のリソースグループに割り当てることで、リソースの分離を確保し、QoS要件を満たすことができます。 +[リソース管理](/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 ステートメントのリソース消費を一時的に制限できます。 リソース制御を効果的に使用することで、クラスターの数を減らし、運用と保守を簡素化し、管理コストを削減できます。 diff --git a/tidb-cloud/pause-or-resume-tidb-cluster.md b/tidb-cloud/pause-or-resume-tidb-cluster.md index 4449e655081e8..f30eeac9d7887 100644 --- a/tidb-cloud/pause-or-resume-tidb-cluster.md +++ b/tidb-cloud/pause-or-resume-tidb-cluster.md @@ -120,4 +120,4 @@ TiDB Cloud API を使用してクラスタを一時停止することもでき クラスターのサイズによっては、クラスターの再開に数分かかる場合があります。クラスターが再開されると、クラスターの状態が**「再開中」**から**「利用可能」**に変わります。 -TiDB Cloud API を使用してクラスタを再開することもできます。現在、 TiDB Cloud API はパブリックプレビューです。詳細については、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)参照してください。 +TiDB Cloud API を使用してクラスタを再開することもできます。現在、 TiDB Cloud API はパブリックプレビューです。詳細については、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)を参照してください。 diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 565d7d08933ce..ab49b55c5740f 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -16,7 +16,7 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] > **ヒント：** > > - TiDB Cloud Dedicatedクラスター上のデータをバックアップおよび復元する方法については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)復元」を参照してください。 -> - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのデータをバックアップおよび復元する方法については、 [TiDB Cloud StarterまたはEssentialデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 +> - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのデータをバックアップおよび復元する方法については、 [TiDB Cloud StarterまたはEssentialデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)を参照してください。 ## バックアップページを確認する {#view-the-backup-page} @@ -241,9 +241,9 @@ TiDB Cloud Premiumは、クラウドストレージ（Amazon S3やAlibaba Cloud 1. IAMユーザーとアクセスキーを作成します。 - 1. IAMユーザーを作成します。詳細については、 [AWSアカウントにIAMユーザーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)参照してください。 + 1. IAMユーザーを作成します。詳細については、 [AWSアカウントにIAMユーザーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)を参照してください。 2. AWSアカウントIDまたはアカウントエイリアス、およびIAMユーザー名とパスワードを使用して[IAMコンソール](https://console.aws.amazon.com/iam)にサインインしてください。 - 3. アクセスキーを作成します。詳細については、 [IAMユーザーのアクセスキーを管理する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)参照してください。 + 3. アクセスキーを作成します。詳細については、 [IAMユーザーのアクセスキーを管理する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)を参照してください。 2. IAMユーザーに権限を付与します。 @@ -294,11 +294,11 @@ TiDB CloudにAlibaba Cloud OSSバケットへのアクセス権を付与する アクセスキーペアを設定するには、以下の手順に従ってください。 -1. RAM ユーザーを作成し、AccessKey ペアを取得します。詳細については、 [RAMユーザーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user)参照してください。 +1. RAM ユーザーを作成し、AccessKey ペアを取得します。詳細については、 [RAMユーザーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user)を参照してください。 **アクセスモードの**セクションで、 **「永続的なアクセスキーを使用してアクセスする」を**選択します。 -2. 必要な権限を持つカスタム ポリシーを作成します。詳細については、 [カスタムポリシーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy)参照してください。 +2. 必要な権限を持つカスタム ポリシーを作成します。詳細については、 [カスタムポリシーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy)を参照してください。 - **「効果」**セクションで**「許可」**を選択します。 @@ -339,4 +339,4 @@ TiDB CloudにAlibaba Cloud OSSバケットへのアクセス権を付与する 3. カスタムポリシーをRAMユーザーに割り当てます。 - 詳細については、 [RAMユーザーに権限を付与する](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user)参照してください。 + 詳細については、 [RAMユーザーに権限を付与する](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user)を参照してください。 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 f6cf988ebfc1d..6f0b92858e768 100644 --- a/tidb-cloud/premium/connect-to-premium-via-public-connection.md +++ b/tidb-cloud/premium/connect-to-premium-via-public-connection.md @@ -9,7 +9,7 @@ summary: パブリック接続を介してTiDB Cloud Premiumに接続する方 > **ヒント：** > -> - パブリック接続経由​​でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [パブリックエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/connect-via-standard-connection-serverless.md)参照してください。 +> - パブリック接続経由​​で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)を参照してください。 ## 前提条件：IPアクセスリストの設定 {#prerequisite-configure-ip-access-list} diff --git a/tidb-cloud/premium/create-tidb-instance-premium.md b/tidb-cloud/premium/create-tidb-instance-premium.md index 0dd65a8ec0e95..a1f9398e5d85a 100644 --- a/tidb-cloud/premium/create-tidb-instance-premium.md +++ b/tidb-cloud/premium/create-tidb-instance-premium.md @@ -9,7 +9,7 @@ summary: TiDB Cloud Premiumインスタンスの作成方法を学びましょ > **注記：** > -> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 +> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/premium/delete-tidb-instance.md b/tidb-cloud/premium/delete-tidb-instance.md index fc3a389b27ca6..5ae19efe32320 100644 --- a/tidb-cloud/premium/delete-tidb-instance.md +++ b/tidb-cloud/premium/delete-tidb-instance.md @@ -23,7 +23,7 @@ summary: TiDB Cloud Premiumインスタンスを削除する方法を学びま インスタンスが正しく削除されるように、 `/`を入力してください。 - 将来インスタンスを復元する場合は、インスタンスのバックアップがあることを確認してください。そうしないと復元できません。 TiDB Cloud Premium インスタンスをバックアップする方法の詳細については、 [TiDB Cloud Premium データのバックアップと復元](/tidb-cloud/premium/backup-and-restore-premium.md)参照してください。 + 将来インスタンスを復元する場合は、インスタンスのバックアップがあることを確認してください。そうしないと復元できません。 TiDB Cloud Premium インスタンスをバックアップする方法の詳細については、 [TiDB Cloud Premium データのバックアップと復元](/tidb-cloud/premium/backup-and-restore-premium.md)を参照してください。 5. **「了解しました、削除します」**をクリックしてください。 @@ -35,4 +35,4 @@ summary: TiDB Cloud Premiumインスタンスを削除する方法を学びま > > バックアップは削除されるまで料金が発生し続けることにご注意ください。 - TiDB Cloud Premium インスタンスをごみ箱から復元する場合は、 [ごみ箱から復元](/tidb-cloud/premium/backup-and-restore-premium.md#restore-from-recycle-bin)参照してください。 + TiDB Cloud Premium インスタンスをごみ箱から復元する場合は、 [ごみ箱から復元](/tidb-cloud/premium/backup-and-restore-premium.md#restore-from-recycle-bin)を参照してください。 diff --git a/tidb-cloud/premium/dual-layer-data-encryption-premium.md b/tidb-cloud/premium/dual-layer-data-encryption-premium.md index eef319ed51359..dabe1d324450f 100644 --- a/tidb-cloud/premium/dual-layer-data-encryption-premium.md +++ b/tidb-cloud/premium/dual-layer-data-encryption-premium.md @@ -101,7 +101,7 @@ TiDB Cloud Premiumインスタンスを作成する際に、二重層データ 6. クラウドプロバイダーのKMSコンソールで、このポリシーステートメントをキーポリシーに追加してください。 - - AWS については、 [AWS KMS の主要ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)参照してください。 + - AWS については、 [AWS KMS の主要ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)を参照してください。 - Alibaba Cloud については、 [キーの管理](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/manage-keys-2)を参照してください。 7. TiDB Cloudコンソールに戻り、キー作成ページの一番下までスクロールして、クラウドプロバイダーのKMSから取得した**KMSキーARN**を入力します。 @@ -140,7 +140,7 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 4. クラウドプロバイダーのKMSコンソールで、このポリシーステートメントをキーポリシーに追加してください。 - - AWS については、 [AWS KMS の主要ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)参照してください。 + - AWS については、 [AWS KMS の主要ポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)を参照してください。 - Alibaba Cloud については、 [キーの管理](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/manage-keys-2)を参照してください。 5. TiDB Cloudコンソールに戻り、ページの一番下までスクロールして、クラウドプロバイダーのKMSから取得した**KMSキーARN**を入力します。 diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 5c8e5eb5a81a7..c2a5f4646f510 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -10,7 +10,7 @@ summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCS > **ヒント：** > > - TiDB Cloud StarterまたはEssentialについては、 [TiDB Cloud StarterまたはEssentialにクラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files-serverless.md)。 -> - TiDB Cloud Dedicatedについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 +> - TiDB Cloud Dedicatedについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。 ## 制限事項 {#limitations} @@ -110,7 +110,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **ソースファイル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 ロール ARN** : AWS ロール ARN の値を入力してください。新しいロールを作成する必要がある場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロールを作成] をクリックし**、ガイド付き手順に従って、提供されているテンプレートを起動し、 IAM警告を確認し、スタックを作成し、生成された ARN をTiDB Cloud Premium にコピーしてください。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 - **バケットへのアクセスをテストする**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 @@ -165,7 +165,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 - **バケットへのアクセスをテストする**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 - **ターゲット接続**：インポートを実行するTiDBのユーザー名とパスワードを入力してください。必要に応じて、 **「接続テスト」を**クリックして認証情報を検証してください。 diff --git a/tidb-cloud/premium/import-from-s3-premium.md b/tidb-cloud/premium/import-from-s3-premium.md index d08c50b4f36d8..f3fd0133b7a77 100644 --- a/tidb-cloud/premium/import-from-s3-premium.md +++ b/tidb-cloud/premium/import-from-s3-premium.md @@ -10,7 +10,7 @@ summary: コンソールウィザードを使用して、Amazon S3からTiDB Clo > **ヒント：** > > - TiDB Cloud StarterまたはEssentialについては、 [TiDB Cloud StarterまたはEssentialにクラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files-serverless.md)。 -> - TiDB Cloud Dedicatedについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 +> - TiDB Cloud Dedicatedについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)を参照してください。 ## 制限事項 {#limitations} @@ -74,5 +74,5 @@ TiDB Cloud Premiumがバケットを読み取れるようにするには、以 ## 次のステップ {#next-steps} -- スクリプトによるインポートについては[MySQLコマンドラインクライアントを使用してTiDB Cloud Premiumにデータをインポートする](/tidb-cloud/premium/import-with-mysql-cli-premium.md)参照してください。 -- IAM関連の問題については[Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)参照してください。 +- スクリプトによるインポートについては[MySQLコマンドラインクライアントを使用してTiDB Cloud Premiumにデータをインポートする](/tidb-cloud/premium/import-with-mysql-cli-premium.md)を参照してください。 +- IAM関連の問題については[Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)を参照してください。 diff --git a/tidb-cloud/premium/import-with-mysql-cli-premium.md b/tidb-cloud/premium/import-with-mysql-cli-premium.md index f30693ace3c79..35cf4301bfd27 100644 --- a/tidb-cloud/premium/import-with-mysql-cli-premium.md +++ b/tidb-cloud/premium/import-with-mysql-cli-premium.md @@ -10,8 +10,8 @@ summary: MySQLコマンドラインクライアント（mysql`）を使用して > **ヒント：** > > - 論理インポートは、比較的小さな SQL ファイルまたは CSV ファイルに最適です。クラウドストレージからのより高速な並列インポート、または[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)エクスポートからの複数のファイルの処理については、 [クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする](/tidb-cloud/premium/import-csv-files-premium.md)インポートするを参照してください。 -> - TiDB Cloud StarterまたはEssentialについては、 [MySQL CLI を介してTiDB Cloud StarterまたはEssentialにデータをインポートする](/tidb-cloud/import-with-mysql-cli-serverless.md)参照してください。 -> - TiDB Cloud Dedicatedについては、 [MySQL CLI を介してTiDB Cloud Dedicatedにデータをインポートする](/tidb-cloud/import-with-mysql-cli.md)参照してください。 +> - TiDB Cloud StarterまたはEssentialについては、 [MySQL CLI を介してTiDB Cloud StarterまたはEssentialにデータをインポートする](/tidb-cloud/import-with-mysql-cli-serverless.md)を参照してください。 +> - TiDB Cloud Dedicatedについては、 [MySQL CLI を介してTiDB Cloud Dedicatedにデータをインポートする](/tidb-cloud/import-with-mysql-cli.md)を参照してください。 ## 前提条件 {#prerequisites} @@ -135,7 +135,7 @@ CSVファイルからデータをインポートするには、以下の手順 > **注記：** > -> `LOAD DATA LOCAL INFILE`の構文の詳細については、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)参照してください。 +> `LOAD DATA LOCAL INFILE`の構文の詳細については、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)を参照してください。
diff --git a/tidb-cloud/premium/migrate-from-op-tidb-premium.md b/tidb-cloud/premium/migrate-from-op-tidb-premium.md index 81cabdd611792..9cd972033d0df 100644 --- a/tidb-cloud/premium/migrate-from-op-tidb-premium.md +++ b/tidb-cloud/premium/migrate-from-op-tidb-premium.md @@ -63,7 +63,7 @@ tiup update --self && tiup update dumpling 1. [ツールキットパッケージ](https://docs.pingcap.com/tidb/stable/download-ecosystem-tools)をダウンロードします。 -2. 対象マシンに展開してください。TiUPを使用して`tiup install dumpling`を実行すると、 Dumpling を入手できます。その後、 `tiup dumpling ...`を使用してDumplingを実行できます。詳細については、 [Dumplingの紹介](https://docs.pingcap.com/tidb/stable/dumpling-overview#dumpling-introduction)参照してください。 。 +2. 対象マシンに展開してください。TiUPを使用して`tiup install dumpling`を実行すると、 Dumpling を入手できます。その後、 `tiup dumpling ...`を使用してDumplingを実行できます。詳細については、 [Dumplingの紹介](https://docs.pingcap.com/tidb/stable/dumpling-overview#dumpling-introduction)を参照してください。 。 #### Dumplingの権限を設定する {#configure-privileges-for-dumpling} @@ -79,9 +79,9 @@ tiup update --self && tiup update dumpling 上流の TiDB Self-Managed クラスターからTiDB Cloud Premium に増分データを複製するには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 -1. 現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、TiDB Self-Managed クラスターで`select tidb_version();`実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 +1. 現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、TiDB Self-Managed クラスターで`select tidb_version();`実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)を参照してください。 -2. TiCDCコンポーネントをTiDB Self-Managedクラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 +2. TiCDCコンポーネントをTiDB Self-Managedクラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)を参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 ```yaml cdc_servers: @@ -137,7 +137,7 @@ SELECT @@global.tidb_gc_enable; #### ステップ2. Dumpling用のAmazon S3バケットへのアクセス権限を設定します {#step-2-configure-access-permissions-to-the-amazon-s3-bucket-for-dumpling} -AWS コンソールでアクセスキーを作成します。詳細については[アクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)参照してください。 +AWS コンソールでアクセスキーを作成します。詳細については[アクセスキーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey)を参照してください。 1. AWSアカウントIDまたはアカウントエイリアス、 IAMユーザー名、およびパスワードを使用して[IAMコンソール](https://console.aws.amazon.com/iam/home#/security_credentials)にサインインしてください。 @@ -160,7 +160,7 @@ Dumplingを使用して、アップストリームのTiDB Self-Managedクラス export AWS_SECRET_ACCESS_KEY=${SecretKey} ``` -2. AWS コンソールから S3 バケット URI とリージョン情報を取得します。詳細については[バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)参照してください。 +2. AWS コンソールから S3 バケット URI とリージョン情報を取得します。詳細については[バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照してください。 以下のスクリーンショットは、S3バケットURI情報を取得する方法を示しています。 @@ -282,7 +282,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 1. [TiDB Cloudコンソール](https://tidbcloud.com/tidbs)で、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 3. **ネットワーク設定**ページで、 **「IPアドレスの追加」**をクリックします。 - 4. 表示されたダイアログで、 **[IP アドレスを使用する]**を選択し、 [ **+** ] をクリックし、 **[IP アドレス]**フィールドに TiCDCコンポーネントのパブリック IP アドレスを入力して、 **[確認]**をクリックします。これで、TiCDC はTiDB Cloud Premium にアクセスできるようになりました。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 + 4. 表示されたダイアログで、 **[IP アドレスを使用する]**を選択し、 [ **+** ] をクリックし、 **[IP アドレス]**フィールドに TiCDCコンポーネントのパブリック IP アドレスを入力して、 **[確認]**をクリックします。これで、TiCDC はTiDB Cloud Premium にアクセスできるようになりました。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 3. 下流のTiDB Cloud Premiumインスタンスの接続情報を取得します。 diff --git a/tidb-cloud/premium/premium-export.md b/tidb-cloud/premium/premium-export.md index 802e6d19ceaef..b385a351b54fe 100644 --- a/tidb-cloud/premium/premium-export.md +++ b/tidb-cloud/premium/premium-export.md @@ -35,7 +35,7 @@ TiDB Cloudを使用すると、 TiDB Cloud Premiumインスタンスから外部 - [アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html): アクセス キーに`s3:PutObject`権限があることを確認してください。 - [ロールARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) ：ロールARN（Amazonリソースネーム）に`s3:PutObject`権限が付与されていることを確認してください。なお、ロールARNはAWS上でホストされているTiDB Cloud Premiumインスタンスのみがサポートしています。 -詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 +詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 ### Azure Blob Storage {#azure-blob-storage} @@ -44,7 +44,7 @@ Azure Blob Storage にデータをエクスポートするには、以下の情 - URI: `azure://.blob.core.windows.net///`または`https://.blob.core.windows.net///` - アクセス資格情報: Azure Blob Storage コンテナーの[共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)。 SAS トークンに、 `Read`および`Write`リソースに対する`Container`および`Object`権限があることを確認してください。 -詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 +詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 ### アリババクラウドOSS {#alibaba-cloud-oss} @@ -53,7 +53,7 @@ Alibaba Cloud OSSにデータをエクスポートするには、以下の情報 - URI: `oss:////` - アクセス資格情報: Alibaba Cloud アカウントの[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)。 AccessKey ペアに`oss:PutObject`および`oss:GetBucketInfo`権限があることを確認してください。 -詳細については、 [外部ストレージへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 +詳細については、 [外部ストレージへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 ## エクスポートオプション {#export-options} @@ -110,7 +110,7 @@ TiDB Cloudコンソールは、選択したデータベースとテーブルを - **ストレージプロバイダー**：Amazon S3を選択してください。 - **フォルダURI** ： `s3:////`形式でAmazon S3のURIを入力してください。 - **バケットへのアクセス**：以下のアクセス認証情報から1つを選択し、認証情報を入力してください。 - - **AWS ロール ARN** : バケットにアクセスする権限を持つロール ARN を入力します。 AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **AWS ロール ARN** : バケットにアクセスする権限を持つロール ARN を入力します。 AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWSアクセスキー**：バケットへのアクセス権限を持つアクセスキーIDとアクセスキーシークレットを入力してください。 - **エクスポートするデータ**：エクスポートするデータベースまたはテーブルを選択してください。 - **データ形式**： **SQL**または**CSV**を選択してください。 @@ -135,7 +135,7 @@ TiDB Cloudコンソールは、選択したデータベースとテーブルを - **ターゲット接続**： - **ストレージプロバイダー**：Azure Blob Storageを選択してください。 - **フォルダー URI** : `azure://.blob.core.windows.net///`の形式で Azure Blob Storage の URI を入力してください。 - - **SAS トークン**: コンテナーへのアクセス権限を持つ SAS トークンを入力します。 [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用して SAS トークンを作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 + - **SAS トークン**: コンテナーへのアクセス権限を持つ SAS トークンを入力します。 [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用して SAS トークンを作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 - **エクスポートするデータ**：エクスポートするデータベースまたはテーブルを選択してください。 - **データ形式**： **SQL**または**CSV**を選択してください。 - **圧縮**： **Gzip** 、 **Snappy** 、 **Zstd** 、または**None**を選択してください。 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 0b0ae28ddde0b..fbc8e9b079df0 100644 --- a/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md +++ b/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md @@ -103,7 +103,7 @@ TiDB Cloud VPCへのアクセスを許可するには、エンドポイントサ 2. **「Changefeed のプライベートエンドポイントの作成」**ダイアログで、プライベートエンドポイントの名前を入力します。 -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)セクションで収集した**エンドポイント サービス名**を入力します。 diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index 4d1c736ca2b87..329154cd79dfa 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -23,7 +23,7 @@ TiDB Cloudは、実行されたSQLステートメントなど、データベー > > - TiDB Cloud Starterでは、データベース監査ログは利用できません。 > - TiDB Cloud Essentialについては、 [TiDB Cloud Essentialのデータベース監査ログ機能 (PREVIEW)](/tidb-cloud/essential-database-audit-logging.md)を参照してください。 - > - TiDB Cloud Dedicatedについては、 [TiDB Cloud Dedicatedデータベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)参照してください。 + > - TiDB Cloud Dedicatedについては、 [TiDB Cloud Dedicatedデータベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)を参照してください。 - 組織内で`Organization Owner`ロールが付与されている必要があります。付与されていない場合、 TiDB Cloudコンソールでデータベース監査関連のオプションは表示されません。 @@ -43,7 +43,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA > > AWS S3バケットでオブジェクトロックを有効にしないでください。オブジェクトロックを有効にすると、 TiDB Cloudが監査ログファイルをS3にプッシュできなくなります。 -詳細については、AWS ユーザーガイドの[汎用バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)参照してください。 +詳細については、AWS ユーザーガイドの[汎用バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照してください。 #### ステップ2. Amazon S3へのアクセスを設定する {#step-2-configure-amazon-s3-access} @@ -120,7 +120,7 @@ Alibaba Cloud 上の TiDB クラウドでデータベース監査ログを有効 TiDB Cloudが監査ログを書き込む宛先として、組織が所有するAlibaba Cloudアカウントにオブジェクトストレージサービス（OSS）バケットを作成します。 -詳細については、Alibaba Cloud Storage ドキュメントの[バケットを作成する](https://www.alibabacloud.com/help/en/oss/user-guide/create-a-bucket-4)参照してください。 +詳細については、Alibaba Cloud Storage ドキュメントの[バケットを作成する](https://www.alibabacloud.com/help/en/oss/user-guide/create-a-bucket-4)を参照してください。 #### ステップ2. OSSアクセスを設定する {#step-2-configure-oss-access} diff --git a/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md b/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md index 99a43c96be955..6940791500cd3 100644 --- a/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md +++ b/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md @@ -27,7 +27,7 @@ TiDB Cloudでは、TLS接続の確立は、 TiDB Cloud Premiumインスタンス 3. 接続ダイアログで、 **「接続タイプ」**ドロップダウンリストから**「パブリック」**を選択します。 - IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] を**クリックして設定します。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/premium/configure-ip-access-list-premium.md)参照してください。 + IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] を**クリックして設定します。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/premium/configure-ip-access-list-premium.md)を参照してください。 4. **「CA証明書」**をクリックすると、 TiDB Cloud PremiumインスタンスへのTLS接続に必要なCA証明書をダウンロードできます。このCA証明書はデフォルトでTLS 1.2をサポートしています。 @@ -46,7 +46,7 @@ TiDB Cloud Premium は、クライアントとTiDB Cloud Premium インスタン ### TiDB Cloud Premiumインスタンスへの接続には、どのTLSバージョンがサポートされていますか？ {#which-tls-versions-are-supported-to-connect-to-my-tidb-cloud-premium-instance} -セキュリティ上の理由から、 TiDB Cloud Premium は TLS 1.2 と TLS 1.3 のみをサポートし、TLS 1.0 または TLS 1.1 はサポートしません。詳細については、「IETF [TLS 1.0およびTLS 1.1のサポートを終了します](https://datatracker.ietf.org/doc/rfc8996/)参照してください。 +セキュリティ上の理由から、 TiDB Cloud Premium は TLS 1.2 と TLS 1.3 のみをサポートし、TLS 1.0 または TLS 1.1 はサポートしません。詳細については、「IETF [TLS 1.0およびTLS 1.1のサポートを終了します](https://datatracker.ietf.org/doc/rfc8996/)を参照してください。 ### 私のクライアントとTiDB Cloud Premium間の双方向TLS認証はサポートされていますか？ {#is-two-way-tls-authentication-between-my-client-and-tidb-cloud-premium-supported} diff --git a/tidb-cloud/recovery-group-failover.md b/tidb-cloud/recovery-group-failover.md index 70eef994b5067..a397ce77a5cc5 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) diff --git a/tidb-cloud/recovery-group-get-started.md b/tidb-cloud/recovery-group-get-started.md index e067cc95f0d9b..d40dfb7cefe05 100644 --- a/tidb-cloud/recovery-group-get-started.md +++ b/tidb-cloud/recovery-group-get-started.md @@ -5,7 +5,7 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 # リカバリグループの使用を開始する {#get-started-with-recovery-groups} -このドキュメントでは、 [TiDB Cloudコンソール](https://tidbcloud.com/)使用してTiDB Cloud Dedicated クラスター上で実行されているデータベースを保護するためのリカバリグループを作成する方法について説明します。また、リカバリグループの詳細を表示する方法も示します。 +このドキュメントでは、 [TiDB Cloudコンソール](https://tidbcloud.com/)を使用してTiDB Cloud Dedicated クラスター上で実行されているデータベースを保護するためのリカバリグループを作成する方法について説明します。また、リカバリグループの詳細を表示する方法も示します。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/recovery-group-overview.md b/tidb-cloud/recovery-group-overview.md index 5fadc3f7b211b..2650acad3eeb1 100644 --- a/tidb-cloud/recovery-group-overview.md +++ b/tidb-cloud/recovery-group-overview.md @@ -33,5 +33,5 @@ TiDB Cloudリカバリグループを使用すると、 TiDB Cloud Dedicated ク ## 次は何？ {#what-s-next} -- リカバリ グループの使用を開始するには、 [データベース復旧グループの作成](/tidb-cloud/recovery-group-get-started.md)参照してください。 -- リカバリグループの使用方法については、 [データベースのフェイルオーバーと再保護](/tidb-cloud/recovery-group-failover.md)参照してください。 +- リカバリ グループの使用を開始するには、 [データベース復旧グループの作成](/tidb-cloud/recovery-group-get-started.md)を参照してください。 +- リカバリグループの使用方法については、 [データベースのフェイルオーバーと再保護](/tidb-cloud/recovery-group-failover.md)を参照してください。 diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 2a69506593285..21be7fcb9dddb 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -25,12 +25,12 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま [TiDB Cloudコンソール](https://tidbcloud.com)の**バックアップ設定**で PITR 機能を有効または無効にすることができます。 - 詳細については[TiDB クラスタ データのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDB クラスタ データのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 - 複数の変更フィード管理と既存の変更フィード編集をサポートします。 - 異なるデータレプリケーションタスクを管理するために、必要な数だけ変更フィードを作成できるようになりました。現在、各クラスタには最大10個の変更フィードを設定できます。詳細については、 [チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)を参照してください。 - - 一時停止状態の既存の変更フィードの設定を編集できます。詳細については、 [変更フィードを編集する](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)参照してください。 + - 一時停止状態の既存の変更フィードの設定を編集できます。詳細については、 [変更フィードを編集する](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)を参照してください。 - Amazon Aurora MySQL、Amazon Relational Database Service (RDS) MySQL、またはセルフホスト型MySQL互換データベースからTiDB Cloudオンラインへのデータ直接移行をサポートします。この機能は現在、一般提供中です。 @@ -49,7 +49,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま タスク設定は数回クリックするだけで完了し、ローカルCSVデータをTiDBクラスターに素早くインポートできます。この方法を使用する場合、クラウドストレージバケットのパスとロールARNを指定する必要はありません。インポートプロセス全体が迅速かつスムーズです。 - 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)参照してください。 + 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)を参照してください。 ## 2022年12月20日 {#december-20-2022} @@ -110,7 +110,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloudを初めて使用する場合でも、すでにTiDB Cloudアカウントをお持ちの場合でも、AWS または GCP の請求アカウントにリンクできるようになりました。これにより、AWS または GCP Marketplace のサブスクリプションを簡単に完了できるようになります。 - リンクの作り方については[クラウドプロバイダーマーケットプレイスからの請求](/tidb-cloud/tidb-cloud-billing.md#billing-from-cloud-provider-marketplace)参照してください。 + リンクの作り方については[クラウドプロバイダーマーケットプレイスからの請求](/tidb-cloud/tidb-cloud-billing.md#billing-from-cloud-provider-marketplace)を参照してください。 ## 2022年11月22日 {#november-22-2022} @@ -124,7 +124,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま 現在、データ移行機能は**ベータ版**です。3 [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)が必要です。 - 詳細については[データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 + 詳細については[データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を参照してください。 ## 2022年11月15日 {#november-15-2022} @@ -142,7 +142,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま デフォルトでは、バックアップデータはクラスタが作成されたリージョンに保存されます。日本では、GCP 上でホストされ PITR が有効になっている TiDB クラスタの場合、バックアップデータを 1 つまたは 2 つのリージョン（東京または大阪、あるいはその両方）に保存することを選択できます。別のリージョンからデータを復元することで、より高いレベルのデータ安全性が確保され、リージョン障害にも耐えることができます。 - 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 この機能はまだベータ版であり、リクエストに応じてのみ利用可能です。 @@ -153,7 +153,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま データベース監査ログを使用すると、ユーザー アクセスの詳細 (実行された SQL ステートメントなど) の履歴をログに記録し、データベース監査ログを定期的に分析して、データベースを安全に保つことができます。 - 詳細については[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)参照してください。 + 詳細については[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)を参照してください。 ## 2022年11月8日 {#november-8-2022} @@ -223,7 +223,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - [Vercelテンプレートリスト](https://vercel.com/templates)中[TiDB Cloud Starter テンプレート](https://vercel.com/templates/next.js/tidb-cloud-starter)を公開します。 - このテンプレートは、VercelとTiDB Cloudを試すための出発点として使用できます。このテンプレートを使用する前に、まず[TiDB Cloudクラスターにデータをインポートする](https://github.com/pingcap/tidb-prisma-vercel-demo#2-import-table-structures-and-data)実行する必要があります。 + このテンプレートは、VercelとTiDB Cloudを試すための出発点として使用できます。このテンプレートを使用する前に、まず[TiDB Cloudクラスターにデータをインポートする](https://github.com/pingcap/tidb-prisma-vercel-demo#2-import-table-structures-and-data)を実行する必要があります。 ## 2022年10月18日 {#october-18-2022} @@ -241,7 +241,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud Terraform プロバイダー](https://registry.terraform.io/providers/tidbcloud/tidbcloud)の[ドキュメント](/tidb-cloud/terraform-tidbcloud-provider-overview.md)を追加しました。 - TiDB Cloud Terraform Providerは、 [Terraform](https://www.terraform.io/)使用してクラスタ、バックアップ、リストアなどのTiDB Cloudリソースを管理できるプラグインです。リソースのプロビジョニングとインフラストラクチャワークフローを自動化するシンプルな方法をお探しの場合は、 [ドキュメント](/tidb-cloud/terraform-tidbcloud-provider-overview.md)に従ってTiDB Cloud Terraform Providerをお試しください。 + TiDB Cloud Terraform Providerは、 [Terraform](https://www.terraform.io/)を使用してクラスタ、バックアップ、リストアなどのTiDB Cloudリソースを管理できるプラグインです。リソースのプロビジョニングとインフラストラクチャワークフローを自動化するシンプルな方法をお探しの場合は、 [ドキュメント](/tidb-cloud/terraform-tidbcloud-provider-overview.md)に従ってTiDB Cloud Terraform Providerをお試しください。 ## 2022年10月11日 {#october-11-2022} @@ -336,7 +336,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- これで、 TiDB Cloudコンソールの右上隅のエントリから[PoCを申請する](/tidb-cloud/tidb-cloud-poc.md)実行できるようになりました。 +- これで、 TiDB Cloudコンソールの右上隅のエントリから[PoCを申請する](/tidb-cloud/tidb-cloud-poc.md)を実行できるようになりました。 **APIの変更** @@ -354,7 +354,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま エンドポイント接続は安全かつプライベートであり、データがパブリックインターネットに公開されることはありません。さらに、エンドポイント接続はCIDRオーバーラップをサポートしており、ネットワーク管理が容易です。 - 詳細については[プライベートエンドポイント接続を設定する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + 詳細については[プライベートエンドポイント接続を設定する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 **コンソールの変更** @@ -447,11 +447,11 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - 新しい[Developer Tierクラスター](/tidb-cloud/select-cluster-tier.md#starter)にユーザー名プレフィックスの制限を追加します。 - データベースユーザー名を使用または設定する際は、必ずユーザー名にクラスターのプレフィックスを含める必要があります。詳細については、 [ユーザー名のプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)参照してください。 + データベースユーザー名を使用または設定する際は、必ずユーザー名にクラスターのプレフィックスを含める必要があります。詳細については、 [ユーザー名のプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を参照してください。 - [Developer Tierクラスター](/tidb-cloud/select-cluster-tier.md#starter)のバックアップと復元機能を無効にします。 - Developer Tierクラスターでは、バックアップと復元機能（自動バックアップと手動バックアップの両方を含む）は無効になっています。ただし、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)使用してデータをバックアップとしてエクスポートすることは可能です。 + Developer Tierクラスターでは、バックアップと復元機能（自動バックアップと手動バックアップの両方を含む）は無効になっています。ただし、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)を使用してデータをバックアップとしてエクスポートすることは可能です。 - [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのストレージサイズを 500 MiB から 1 GiB に増やします。 @@ -582,11 +582,11 @@ TiDB Cloudが一般提供を開始しました。以下の[サインアップ](h - サポート[PrometheusとGrafanaの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) 。 - Prometheus と Grafana の統合により、 [Prometheus](https://prometheus.io/)サービスを設定してTiDB Cloudエンドポイントから主要なメトリックを読み取り、 [Grafana](https://grafana.com/)使用してメトリックを表示できます。 + Prometheus と Grafana の統合により、 [Prometheus](https://prometheus.io/)サービスを設定してTiDB Cloudエンドポイントから主要なメトリックを読み取り、 [Grafana](https://grafana.com/)を使用してメトリックを表示できます。 - 新しいクラスターの選択したリージョンに基づいてデフォルトのバックアップ時間を割り当てることをサポートします。 - 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 ## 2022年3月4日 {#march-04-2022} diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index 6e4e63d1faeef..981a1528e144b 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -11,9 +11,9 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)使用すると、失敗した変更フィードを再開できるため、新しい変更フィードを再作成する手間が省けます。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)を使用すると、失敗した変更フィードを再開できるため、新しい変更フィードを再作成する手間が省けます。 - 詳細については[チェンジフィードの状態](/tidb-cloud/changefeed-overview.md#changefeed-states)参照してください。 + 詳細については[チェンジフィードの状態](/tidb-cloud/changefeed-overview.md#changefeed-states)を参照してください。 **コンソールの変更** @@ -21,7 +21,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **接続**ダイアログインターフェースを改良し、 TiDB Cloud Serverless ユーザーにとってよりスムーズで効率的な接続エクスペリエンスを提供します。さらに、 TiDB Cloud Serverless ではより多くのクライアントタイプが導入され、接続するブランチを選択できるようになりました。 - 詳細については[TiDB Cloud Serverless に接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)参照してください。 + 詳細については[TiDB Cloud Serverless に接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)を参照してください。 ## 2023年11月28日 {#november-28-2023} @@ -31,7 +31,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloud Dedicated は、バックアップからの復元時に、ユーザーアカウントと SQL バインディングをデフォルトで復元するようになりました。この機能強化は v6.2.0 以降のバージョンのクラスターで利用可能で、データ復元プロセスを効率化します。SQL バインディングの復元により、クエリ関連の設定と最適化がスムーズに再統合され、より包括的で効率的なリカバリエクスペリエンスが実現します。 - 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 **コンソールの変更** @@ -49,7 +49,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま AWSおよびGoogle CloudにデプロイされたTiDBクラスタで物理モードがご利用いただけるようになりました。物理モードの移行速度は最大110MiB/sに達し、論理モードの2.4倍の速度です。このパフォーマンス向上は、大規模なデータセットをTiDB Cloudに迅速に移行する場合に最適です。 - 詳細については[既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)参照してください。 + 詳細については[既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)を参照してください。 ## 2023年11月14日 {#november-14-2023} @@ -57,13 +57,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloud Dedicated クラスターからデータを復元する場合のデフォルトの動作が、ユーザー アカウントなしでの復元からすべてのユーザー アカウントでの復元に変更されました。 - 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 - 変更フィード用のイベント フィルターを導入します。 この機能強化により、 [TiDB Cloudコンソール](https://tidbcloud.com/)を通じて直接変更フィードのイベント フィルターを簡単に管理できるようになり、変更フィードから特定のイベントを除外するプロセスが効率化され、下流のデータ レプリケーションをより適切に制御できるようになります。 - 詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)参照してください。 + 詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)を参照してください。 ## 2023年11月7日 {#november-7-2023} @@ -76,7 +76,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB ノード全体の最大 CPU 使用率が 10 分間 80% を超えました - TiKVノード全体の最大CPU使用率が10分間80%を超えました - 詳細については[TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md#resource-usage-alerts)参照してください。 + 詳細については[TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md#resource-usage-alerts)を参照してください。 ## 2023年10月31日 {#october-31-2023} @@ -84,7 +84,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 営業担当者に連絡せずに、 TiDB CloudコンソールでEnterprise サポート プランに直接アップグレードできます。 - 詳細については[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)参照してください。 + 詳細については[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)を参照してください。 ## 2023年10月25日 {#october-25-2023} @@ -94,13 +94,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま Google Cloud でホストされるTiDB Cloud Dedicated クラスタは、Google Cloud Storage とシームレスに連携します。Google Cloud Storage の[デュアルリージョン](https://cloud.google.com/storage/docs/locations#location-dr)機能と同様に、 TiDB Cloud Dedicated のデュアルリージョンで使用するリージョンのペアは、同じマルチリージョン内になければなりません。例えば、東京と大阪は同じマルチリージョン`ASIA`内にあるため、デュアルリージョンstorageとして一緒に使用できます。 - 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)参照してください。 + 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)を参照してください。 - [データ変更ログをApache Kafkaにストリーミングする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)の機能は現在、一般提供 (GA) になっています。 10ヶ月間のベータトライアルを経て、 TiDB CloudからApache Kafkaへのデータ変更ログのストリーミング機能が一般提供となりました。TiDBからメッセージキューへのデータストリーミングは、データ統合シナリオにおいて一般的なニーズです。Kafkaシンクを使用することで、他のデータ処理システム（Snowflakeなど）との統合や、ビジネス利用のサポートが可能になります。 - 詳細については[チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)参照してください。 + 詳細については[チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)を参照してください。 ## 2023年10月11日 {#october-11-2023} @@ -110,13 +110,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま クラウドプロバイダー内の地理的リージョン間でバックアップを複製できるようになりました。この機能により、データ保護と災害復旧機能がさらにレイヤーされます。 - 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 - データ移行では、既存のデータの移行に物理モードと論理モードの両方がサポートされるようになりました。 物理モードでは、移行速度は最大110 MiB/sに達します。論理モードの45 MiB/sと比較すると、移行パフォーマンスが大幅に向上しています。 - 詳細については[既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)参照してください。 + 詳細については[既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)を参照してください。 ## 2023年10月10日 {#october-10-2023} @@ -124,7 +124,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloud Vercel 統合により、 [Vercel プレビュー デプロイメント](https://vercel.com/docs/deployments/preview-deployments)でTiDB Cloud Serverless ブランチの使用をサポートします。 - 詳細については[TiDB Cloud Serverless ブランチに接続](/tidb-cloud/integrate-tidbcloud-with-vercel.md#connect-with-branching)参照してください。 + 詳細については[TiDB Cloud Serverless ブランチに接続](/tidb-cloud/integrate-tidbcloud-with-vercel.md#connect-with-branching)を参照してください。 ## 2023年9月28日 {#september-28-2023} @@ -146,7 +146,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま JavaScript用[TiDB Cloud Serverless Driver](/develop/serverless-driver.md)を使用すると、HTTPS経由で[TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターに接続できます。特に、TCP接続数が[Vercelエッジ関数](https://vercel.com/docs/functions/edge-functions)や[Cloudflareワーカー](https://workers.cloudflare.com/)など制限されているエッジ環境で役立ちます。 - 詳細については[TiDB Cloud Serverless Driver (ベータ版)](/develop/serverless-driver.md)参照してください。 + 詳細については[TiDB Cloud Serverless Driver (ベータ版)](/develop/serverless-driver.md)を参照してください。 **コンソールの変更** @@ -160,13 +160,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま キーを[作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)または[編集](/tidb-cloud/data-service-api-key.md#edit-an-api-key)にすると、API キーのレート制限を調整できます。 - 詳細については[レート制限](/tidb-cloud/data-service-api-key.md#rate-limiting)参照してください。 + 詳細については[レート制限](/tidb-cloud/data-service-api-key.md#rate-limiting)を参照してください。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して新しい AWS リージョンをサポートします: サンパウロ (sa-east-1)。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)つのクラスターごとに最大 100 個の IP アドレスを IP アクセス リストに追加することをサポートします。 - 詳細については[IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 + 詳細については[IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 **コンソールの変更** @@ -174,7 +174,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま このページでは、過去 7 日間のイベント履歴を表示し、トリガー時間やアクションを開始したユーザーなどの重要な詳細を追跡できます。 - 詳細については[TiDB Cloudクラスター イベント](/tidb-cloud/tidb-cloud-events.md)参照してください。 + 詳細については[TiDB Cloudクラスター イベント](/tidb-cloud/tidb-cloud-events.md)を参照してください。 **APIの変更** @@ -203,13 +203,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 強化されたセキュリティ: 安全な接続を確立してデータを保護します。 - パフォーマンスの向上: 低遅延かつ高帯域幅の接続を実現します。 - 詳細については[プライベートエンドポイント経由で Google Cloud に接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 + 詳細については[プライベートエンドポイント経由で 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から GCS にデータをストリーミングできるようになりました。GCS にデータを複製した後、データの変更を自由に分析できます。 - 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)を参照してください。 ## 2023年8月15日 {#august-15-2023} @@ -226,7 +226,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この機能は、最後のクエリが`SELECT`ステートメントである`GET`リクエストに対してのみ使用できることに注意してください。 - 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)参照してください。 + 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 - [データサービス（ベータ版）](https://tidbcloud.com/project/data-service)指定された有効期間 (TTL) にわたって`GET`要求のエンドポイント応答のキャッシュをサポートします。 @@ -234,7 +234,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま `GET`リクエスト メソッドを使用するエンドポイントの場合、**キャッシュ レスポンス**を有効にし、**詳細プロパティ**でキャッシュの TTL 期間を設定できます。 - 詳細については[高度なプロパティ](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)参照してください。 + 詳細については[高度なプロパティ](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)を参照してください。 - AWS でホストされ、2023 年 8 月 15 日以降に作成された[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの負荷分散の改善を無効にします。これには以下が含まれます。 @@ -251,7 +251,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま [「基本」HTTP認証](https://datatracker.ietf.org/doc/html/rfc7617)を使用したリクエストでは、公開鍵をユーザー名として、秘密鍵をパスワードとして提供できます。ダイジェスト認証と比較して、基本認証はよりシンプルで、データサービスエンドポイントを呼び出す際に簡単に使用できます。 - 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)参照してください。 + 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 ## 2023年8月1日 {#august-1-2023} @@ -269,7 +269,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま Postman統合により、データアプリのエンドポイントをコレクションとして、お好みのワークスペースにインポートできます。PostmanのWebアプリとデスクトップアプリの両方をサポートすることで、強化されたコラボレーションとシームレスなAPIテストのメリットを享受できます。 - 詳細については[Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)参照してください。 + 詳細については[Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに新しい**一時停止**ステータスを導入し、この期間中は料金なしでコスト効率の高い一時停止を可能にします。 @@ -277,7 +277,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま クラスターは、ステータスが**[一時停止]**に遷移した後にのみ再開できます。これにより、 **[一時停止]**と**[再開] を**素早くクリックすることで発生する異常な再開の問題が解決されます。 - 詳細については[TiDB Cloud Dedicated クラスターを一時停止または再開する](/tidb-cloud/pause-or-resume-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicated クラスターを一時停止または再開する](/tidb-cloud/pause-or-resume-tidb-cluster.md)を参照してください。 ## 2023年7月26日 {#july-26-2023} @@ -287,20 +287,20 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 開発者は、最小限のクリックと設定でHTTPエンドポイントを簡単に作成できるようになりました。繰り返しの定型コードを排除し、エンドポイントの作成を簡素化・高速化し、潜在的なエラーを削減します。 - この機能の使用方法の詳細については、 [エンドポイントを自動的に生成する](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically)参照してください。 + この機能の使用方法の詳細については、 [エンドポイントを自動的に生成する](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically)を参照してください。 - TiDB Cloud [データサービス](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-manage-endpoint.md#configure-properties)を参照してください。 - TiDB Cloud [データサービス](https://tidbcloud.com/project/data-service)で`POST` `PUT`リクエスト メソッドの**バッチ操作を**`DELETE`します。 エンドポイントで**バッチ操作を**有効にすると、単一のリクエストで複数の行に対する操作を実行できるようになります。例えば、単一のリクエスト`POST`で複数行のデータを挿入できます。 - 詳細については[高度なプロパティ](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)参照してください。 + 詳細については[高度なプロパティ](/tidb-cloud/data-service-manage-endpoint.md#advanced-properties)を参照してください。 ## 2023年7月25日 {#july-25-2023} @@ -315,7 +315,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - **サポート**用の入り口を追加左下隅にあります。 - [TiDB Cloudコンソール](https://tidbcloud.com/)の右下隅にある**?**アイコンのメニューを改良して、より直感的に操作できるようにします。 - 詳細については[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)参照してください。 + 詳細については[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)を参照してください。 ## 2023年7月18日 {#july-18-2023} @@ -327,7 +327,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - プロジェクト ロールには`Project Owner` 、 `Project Data Access Read-Write` 、 `Project Data Access Read-Only`が含まれます。 - プロジェクト内のクラスターを管理するには (クラスターの作成、変更、削除など)、ロール`Organization Owner`または`Project Owner`である必要があります。 - さまざまなロールの権限の詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)参照してください。 + さまざまなロールの権限の詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)を参照してください。 - AWS でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して、カスタマー管理暗号化キー (CMEK) 機能 (ベータ版) をサポートします。 @@ -368,7 +368,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま アプリケーション開発にGitHubをご利用の場合、 TiDB Cloud Serverlessブランチ機能をGitHub CI/CDパイプラインに統合することで、本番のデータベースに影響を与えることなく、ブランチを使用してプルリクエストを自動的にテストできます。詳細については、 [TiDB Cloud Serverless Branching（ベータ版）をGitHubと統合する](/tidb-cloud/branch-github-integration.md)ご覧ください。 -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタの週次バックアップをサポートします。詳細については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタの週次バックアップをサポートします。詳細については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を参照してください。 ## 2023年7月4日 {#july-4-2023} @@ -378,7 +378,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloud Serverless クラスターを過去90日間の任意の時点に復元できるようになりました。この機能により、 TiDB Cloud Serverless クラスターのデータ復旧能力が強化されます。例えば、データ書き込みエラーが発生し、データを以前の状態に復元したい場合、PITR を使用できます。 - 詳細については[TiDB Cloud Serverless データのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#restore)参照してください。 + 詳細については[TiDB Cloud Serverless データのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#restore)を参照してください。 **コンソールの変更** @@ -412,13 +412,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま これにより、 TiDB CloudとAmazon S3のシームレスな統合が可能になります。1 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターからAmazon S3へのリアルタイムのデータキャプチャとレプリケーションが可能になり、下流のアプリケーションと分析機能が最新のデータにアクセスできるようになります。 - 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)を参照してください。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの 16 vCPU TiKV の最大ノードストレージを4 TiB から 6 TiB に増加します。 この機能強化により、 TiDB Cloud Dedicated クラスターのデータストレージ容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 - 詳細については[クラスターのサイズ](/tidb-cloud/size-your-cluster.md)参照してください。 + 詳細については[クラスターのサイズ](/tidb-cloud/size-your-cluster.md)を参照してください。 - [監視メトリクスの保持期間](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) for [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)クラスターを 3 日から 7 日に延長します。 @@ -470,7 +470,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - デプロイメント履歴を確認し、障害が発生した場合に必要なアクションを実行します。 - コミットを再デプロイして、以前のデプロイにロールバックします。 - 詳細については[GitHub でデータ アプリを自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)参照してください。 + 詳細については[GitHub でデータ アプリを自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)を参照してください。 ## 2023年6月2日 {#june-2-2023} @@ -531,7 +531,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この機能により、需要の増加に合わせて高パフォーマンスノードにアップグレードしたり、コスト削減のために低パフォーマンスノードにダウングレードしたりできます。この柔軟性の向上により、ワークロードに合わせてクラスターの容量を調整し、コストを最適化できます。 - 詳細な手順については、 [ノードサイズを変更する](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)参照してください。 + 詳細な手順については、 [ノードサイズを変更する](/tidb-cloud/scale-tidb-cluster.md#change-vcpu-and-ram)を参照してください。 - 圧縮ファイルのインポートをサポートします。CSVファイルとSQLファイルの形式は、 `.gzip` `.zst` 。この機能`.gz` `.zstd`より効率的かつコスト効率の高いデータインポートが可能になり、データ転送コスト`.snappy`削減できます。 @@ -541,13 +541,13 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま プライベートエンドポイント接続では、データがパブリックインターネットに公開されることはありません。さらに、エンドポイント接続はCIDR重複をサポートしており、ネットワーク管理が容易になります。 - 詳細については[プライベートエンドポイント接続を設定する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + 詳細については[プライベートエンドポイント接続を設定する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 **コンソールの変更** - [**イベント**](/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)参照してください。 + 記録できるイベントの完全なリストについては、 [記録されたイベント](/tidb-cloud/tidb-cloud-events.md#logged-events)を参照してください。 - [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターの[**SQL診断**](/tidb-cloud/tune-performance.md)ページに**SQL ステートメント**タブを導入します。 @@ -557,7 +557,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - クエリ時間、実行プラン、データベースサーバーの応答など、各 SQL ステートメントの詳細な情報が提供され、データベースのパフォーマンスの最適化に役立ちます。 - 大量のデータを簡単に並べ替え、フィルタリング、検索できるユーザーフレンドリーなインターフェースにより、最も重要なクエリに集中できます。 - 詳細については[ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 + 詳細については[ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)を参照してください。 ## 2023年5月6日 {#may-6-2023} @@ -569,7 +569,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま あるいは、リージョンを指定せずにグローバルドメイン`data.tidbcloud.com`リクエストすることもできます。この場合、 TiDB Cloud は内部的にリクエストをターゲットリージョンにリダイレクトしますが、レイテンシーが発生する可能性があります。この方法を選択する場合は、エンドポイントを呼び出す際に curl コマンドに`--location-trusted`オプションを追加してください。 - 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)参照してください。 + 詳細については[エンドポイントを呼び出す](/tidb-cloud/data-service-manage-endpoint.md#call-an-endpoint)を参照してください。 ## 2023年4月25日 {#april-25-2023} @@ -584,11 +584,11 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま クラスターの**概要**ページの**「今月の使用量」**エリアで簡単に[クラスターの使用状況を監視するか、使用量の割り当てを増やす](/tidb-cloud/manage-serverless-spend-limit.md)確認できます。クラスターの無料クォータに達すると、クォータを増やすか、新しい月の開始時に使用量がリセットされるまで、このクラスターの読み取りおよび書き込み操作は制限されます。 - さまざまなリソース (読み取り、書き込み、SQL CPU、ネットワーク送信など) の RU 消費量、価格の詳細、スロットル情報の詳細については、 [TiDB Cloud Serverless Tier の料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details)参照してください。 + さまざまなリソース (読み取り、書き込み、SQL CPU、ネットワーク送信など) の RU 消費量、価格の詳細、スロットル情報の詳細については、 [TiDB Cloud Serverless Tier の料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details)を参照してください。 - TiDB Cloud [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのバックアップと復元をサポートします。 - 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 + 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)を参照してください。 - 新しい[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)にアップグレードします。 @@ -596,14 +596,14 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま メンテナンス ウィンドウとは、 TiDB Cloudサービスの信頼性、セキュリティ、パフォーマンスを確保するために、オペレーティング システムの更新、セキュリティ パッチ、インフラストラクチャのアップグレードなどの計画されたメンテナンス アクティビティが自動的に実行される指定された期間です。 - メンテナンス期間中は、一時的な接続中断やQPSの変動が発生する可能性がありますが、クラスターは引き続き利用可能であり、SQL操作、既存のデータインポート、バックアップ、復元、移行、レプリケーションタスクは通常どおり実行されます。メンテナンス中は[許可された操作と許可されていない操作のリスト](/tidb-cloud/configure-maintenance-window.md#allowed-and-disallowed-operations-during-a-maintenance-window)参照してください。 + メンテナンス期間中は、一時的な接続中断や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/configure-maintenance-window.md)参照してください。 + 詳細については[メンテナンスウィンドウを構成する](/tidb-cloud/configure-maintenance-window.md)を参照してください。 - 2023 年 4 月 25 日以降に作成され、AWS でホストされている[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの TiDB ノードをスケーリングするときに、TiDB の負荷分散を改善し、接続の切断を減らします。 @@ -626,7 +626,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この機能を使用すると、仕様をスケールアップして移行パフォーマンスを向上させたり、仕様をスケールダウンしてコストを削減したりできます。 - 詳細については[データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#scale-a-migration-job-specification)参照してください。 + 詳細については[データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#scale-a-migration-job-specification)を参照してください。 **コンソールの変更** @@ -634,11 +634,11 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 新しいデザインは、シンプルさを重視し、視覚的な煩雑さを軽減し、明確な指示を提供します。クラスター作成ページで**「作成」を**クリックすると、クラスターの作成が完了するのを待たずに、クラスターの概要ページに移動します。 - 詳細については[クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 - **請求**ページに**割引**タブを導入し、組織の所有者と請求管理者向けの割引情報を表示します。 - 詳細については[割引](/tidb-cloud/tidb-cloud-billing.md#discounts)参照してください。 + 詳細については[割引](/tidb-cloud/tidb-cloud-billing.md#discounts)を参照してください。 ## 2023年4月11日 {#april-11-2023} @@ -655,7 +655,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま New Relicとの連携により、 TiDB Cloudを設定してTiDBクラスターのメトリックデータを[New Relic](https://newrelic.com/)に送信できます。これにより、 [New Relic](https://newrelic.com/)でアプリケーションパフォーマンスとTiDBデータベースパフォーマンスの両方を監視・分析できます。この機能により、潜在的な問題を迅速に特定してトラブルシューティングし、解決時間を短縮できます。 - 統合手順と利用可能なメトリックについては、 [TiDB CloudとNew Relicの統合](/tidb-cloud/monitor-new-relic-integration.md)参照してください。 + 統合手順と利用可能なメトリックについては、 [TiDB CloudとNew Relicの統合](/tidb-cloud/monitor-new-relic-integration.md)を参照してください。 - Dedicated Tierクラスターの Prometheus 統合に次の[チェンジフィード](/tidb-cloud/changefeed-overview.md)メトリックを追加します。 @@ -666,7 +666,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[監視](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page)ページを[ノードレベルのリソースメトリック](/tidb-cloud/built-in-monitoring.md#server)使用するように更新します。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[監視](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page)ページを[ノードレベルのリソースメトリック](/tidb-cloud/built-in-monitoring.md#server)を使用するように更新します。 ノード レベルのリソース メトリックを使用すると、リソース消費量をより正確に表示して、購入したサービスの実際の使用状況をよりよく理解できます。 @@ -693,7 +693,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 高度なフィルタリングオプションにより、アラートの重大度、ステータス、その他の属性に基づいて、アラートを素早く検索・並べ替えることができます。また、過去7日間の履歴データを表示できるため、アラート履歴の追跡が容易になります。 - **ルール編集**機能。クラスターの特定のニーズに合わせてアラートルール設定をカスタマイズできます。 - 詳細については[TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md)参照してください。 + 詳細については[TiDB Cloud組み込みアラート](/tidb-cloud/monitor-built-in-alerting.md)を参照してください。 - TiDB Cloudのヘルプ関連の情報とアクションを 1 か所に統合​​します。 @@ -727,17 +727,17 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま より高い仕様を選択するとレプリケーションのパフォーマンスが向上し、より低い仕様を選択するとレプリケーションのコストが削減されます。 - 詳細については[チェンジフィードをスケールする](/tidb-cloud/changefeed-overview.md#scale-a-changefeed)参照してください。 + 詳細については[チェンジフィードをスケールする](/tidb-cloud/changefeed-overview.md#scale-a-changefeed)を参照してください。 - AWS の[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから同じプロジェクトおよび同じリージョン内の[Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターへの増分データのリアルタイム複製をサポートします。 - 詳細については[TiDB Cloudにシンク](/tidb-cloud/changefeed-sink-to-tidb-cloud.md)参照してください。 + 詳細については[TiDB Cloudにシンク](/tidb-cloud/changefeed-sink-to-tidb-cloud.md)を参照してください。 - [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能に対して 2 つの新しい GCP リージョン ( `Singapore (asia-southeast1)`と`Oregon (us-west1)`をサポートします。 これらの新しいリージョンにより、 TiDB Cloudへのデータ移行の選択肢が広がります。アップストリームデータがこれらのリージョン内またはその付近に保存されている場合、GCP からTiDB Cloudへのより高速で信頼性の高いデータ移行を活用できるようになります。 - 詳細については[Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 + 詳細については[Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を参照してください。 **コンソールの変更** @@ -774,7 +774,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま この機能を使用すると、Google Cloud Platform (GCP) の MySQL 互換データベースから TiDB クラスタにデータを簡単かつ効率的に移行できます。 - 詳細については[Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 + 詳細については[Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を参照してください。 **コンソールの変更** @@ -782,7 +782,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま このページでは、過去7日間のイベント履歴を表示し、トリガー時刻やアクションを開始したユーザーなどの重要な詳細を追跡できます。例えば、クラスターが一時停止された時刻や、クラスターのサイズを変更したユーザーなどのイベントを確認できます。 - 詳細については[TiDB Cloudクラスター イベント](/tidb-cloud/tidb-cloud-events.md)参照してください。 + 詳細については[TiDB Cloudクラスター イベント](/tidb-cloud/tidb-cloud-events.md)を参照してください。 - [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターの**[監視]**ページに**[データベース ステータス]**タブを追加します。ここには、次のデータベース レベルのメトリックが表示されます。 @@ -792,7 +792,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま これらのメトリックを使用すると、個々のデータベースのパフォーマンスを監視し、データに基づいた意思決定を行い、アプリケーションのパフォーマンスを向上させるためのアクションを実行できます。 - 詳細については[Serverless Tierクラスターのモニタリングメトリクス](/tidb-cloud/built-in-monitoring.md)参照してください。 + 詳細については[Serverless Tierクラスターのモニタリングメトリクス](/tidb-cloud/built-in-monitoring.md)を参照してください。 ## 2023年3月14日 {#march-14-2023} @@ -804,7 +804,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま ヘッダー行を含むローカルCSVファイルを[Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターにインポートする際、 TiDB Cloudでターゲットテーブルを作成する必要があり、ヘッダー行の列名がTiDB Cloudの列命名規則に従っていない場合、対応する列名の横に警告アイコンが表示されます。この警告を解決するには、アイコンの上にカーソルを移動し、メッセージに従って既存の列名を編集するか、新しい列名を入力してください。 - 列の命名規則については、 [ローカルファイルをインポートする](/tidb-cloud/tidb-cloud-import-local-files.md#import-local-files)参照してください。 + 列の命名規則については、 [ローカルファイルをインポートする](/tidb-cloud/tidb-cloud-import-local-files.md#import-local-files)を参照してください。 ## 2023年3月7日 {#march-7-2023} @@ -855,7 +855,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま コンソール監査ログを分析することで、組織内で実行された疑わしい操作を特定し、組織のリソースとデータのセキュリティを向上させることができます。 - 詳細については[コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md)参照してください。 + 詳細については[コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md)を参照してください。 **CLIの変更** @@ -906,7 +906,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **モニタリング**ページには、1 秒あたりに実行される SQL ステートメントの数、クエリの平均実行時間、失敗したクエリの数など、さまざまなメトリックとデータが提供され、 Serverless Tierクラスター内の SQL ステートメントの全体的なパフォーマンスをよりよく理解するのに役立ちます。 - 詳細については[TiDB Cloud組み込み監視](/tidb-cloud/built-in-monitoring.md)参照してください。 + 詳細については[TiDB Cloud組み込み監視](/tidb-cloud/built-in-monitoring.md)を参照してください。 ## 2023年2月2日 {#february-2-2023} @@ -950,7 +950,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - インポートタスクを作成する際に、対象のデータベースまたはテーブルが存在しない場合は、名前を入力することでTiDB Cloudが自動的に作成します。作成する対象テーブルには、主キーを指定するか、複数のフィールドを選択して複合主キーを形成することができます。 - インポートが完了したら、 **「Chat2Query でデータを探索」**をクリックするか、タスク リストでターゲット テーブル名をクリックして、 [AI搭載のChat2Query](/tidb-cloud/explore-data-with-chat2query.md)でデータを探索できます。 - 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)参照してください。 + 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)を参照してください。 **コンソールの変更** @@ -989,7 +989,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま [TiDB CloudとPrometheusを統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)お持ちの場合は、事前に構築されたGrafanaダッシュボードをインポートしてTiDB Cloudクラスターを監視し、ニーズに合わせてダッシュボードをカスタマイズできるようになりました。この機能により、 TiDB Cloudクラスターを簡単かつ迅速に監視し、パフォーマンスの問題を迅速に特定できるようになります。 - 詳細については[Grafana GUIダッシュボードを使用してメトリックを視覚化する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#step-3-use-grafana-gui-dashboards-to-visualize-the-metrics)参照してください。 + 詳細については[Grafana GUIダッシュボードを使用してメトリックを視覚化する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#step-3-use-grafana-gui-dashboards-to-visualize-the-metrics)を参照してください。 - すべての[Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのデフォルトの TiDB バージョンを[バージョン6.3.0](https://docs.pingcap.com/tidb/stable/release-6.3.0)から[バージョン6.4.0](https://docs.pingcap.com/tidb/stable/release-6.4.0)にアップグレードします。Serverless Tierクラスターのデフォルトの TiDB バージョンを v6.4.0 にアップグレードした後に発生していたコールドスタートの問題が解決されました。 diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 16fd0dda4cb0f..3355cd01301f5 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -15,7 +15,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - 新しいクラスターへのデータ復元をサポートすることで、柔軟性が向上し、現在のクラスターの運用が中断されないことが保証されます。 - - クラスター計画に合わせてバックアップと復元の戦略を調整します。詳細については、 [TiDB Cloud Serverless データのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#learn-about-the-backup-setting)参照してください。 + - クラスター計画に合わせてバックアップと復元の戦略を調整します。詳細については、 [TiDB Cloud Serverless データのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#learn-about-the-backup-setting)を参照してください。 - スムーズな移行を支援するために、以下の互換性ポリシーを適用してください。 @@ -56,7 +56,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - **GitHubとの連携機能の改善**： [TiDB Cloud Branching](https://github.com/apps/tidb-cloud-branching)GitHubアプリでは`reset`プルリクエストの同期時の動作を制御する[`branch.mode`](/tidb-cloud/branch-github-integration.md#branchmode)パラメータが導入されました。デフォルトモードでは、アプリはプルリクエストの最新の変更に合わせてブランチをリセットします。 - 詳細については、 [TiDB Cloud Serverless Branchs の管理](/tidb-cloud/branch-manage.md)および[TiDB Cloud Serverless Branching (ベータ版) を GitHub と統合する](/tidb-cloud/branch-github-integration.md)参照してください。 + 詳細については、 [TiDB Cloud Serverless Branchs の管理](/tidb-cloud/branch-manage.md)および[TiDB Cloud Serverless Branching (ベータ版) を GitHub と統合する](/tidb-cloud/branch-github-integration.md)を参照してください。 ## 2024年11月12日 {#november-12-2024} @@ -146,7 +146,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 以前は、 TiDB Cloud は[TiDB Cloud CLI](/tidb-cloud/cli-reference.md)を使用したデータエクスポートのみをサポートしていました。今後は、 [TiDB Cloudコンソール](https://tidbcloud.com/)TiDB Cloud Serverless クラスターからローカルファイルや Amazon S3 へ簡単にデータをエクスポートできます。 - 詳細については、 [TiDB Cloud Serverless からデータをエクスポート](/tidb-cloud/serverless-export.md)[TiDB Cloud Serverless の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)参照してください。 + 詳細については、 [TiDB Cloud Serverless からデータをエクスポート](/tidb-cloud/serverless-export.md)[TiDB Cloud Serverless の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)を参照してください。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの接続エクスペリエンスを向上させます。 @@ -154,7 +154,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - クラスターのネットワーク設定を簡素化するために、新しいクラスターレベルの**ネットワーク設定**ページを導入しました。 - **セキュリティ設定**ページを新しい**パスワード設定**ページに置き換え、IPアクセスリストの設定を新しい**ネットワーク**ページに移動します。 - 詳細については、 [TiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。 + 詳細については、 [TiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデータインポートエクスペリエンスを向上させます。 @@ -162,7 +162,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - TiDB Cloud Serverless クラスターとTiDB Cloud Dedicatedクラスターのインポート手順を統一します。 - AWSロールARNの作成プロセスを簡素化し、接続設定を容易にします。 - 詳細については、 [ファイルからデータをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-migration-overview.md#import-data-from-files-to-tidb-cloud)参照してください。 + 詳細については、 [ファイルからデータをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-migration-overview.md#import-data-from-files-to-tidb-cloud)を参照してください。 ## 2024年8月20日 {#august-20-2024} @@ -170,7 +170,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで新しいプライベートエンドポイント接続を作成する際のユーザーエクスペリエンスを向上させるため、 **「プライベートエンドポイント接続の作成」**ページのレイアウトを改良します。 - 詳細については、 [AWSのプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)および[Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 + 詳細については、 [AWSのプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)および[Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 ## 2024年8月6日 {#august-6-2024} @@ -200,13 +200,13 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ この機能により[ダイファイ](https://dify.ai/)や[GPT](https://openai.com/blog/introducing-gpts)などのAIプラットフォームとのシームレスな統合が可能になり、高度な自然言語処理とAI機能を活用して、より複雑なタスクやインテリジェントなソリューションに対応できるアプリケーションを構築できます。 - 詳細については、 [エンドポイントを自動的に生成する](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically)および[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)参照してください。 + 詳細については、 [エンドポイントを自動的に生成する](/tidb-cloud/data-service-manage-endpoint.md#generate-an-endpoint-automatically)および[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)を参照してください。 - TiDB Cloudの実際のコストを計画された支出と比較して追跡し、予期せぬコストの発生を防ぐのに役立つ予算機能を導入します。 この機能にアクセスするには、組織内で`Organization Owner`または`Organization Billing Admin`の役割を担っている必要があります。 - 詳細については、 [TiDB Cloudの予算を管理する](/tidb-cloud/tidb-cloud-budget.md)参照してください。 + 詳細については、 [TiDB Cloudの予算を管理する](/tidb-cloud/tidb-cloud-budget.md)を参照してください。 ## 2024年7月9日 {#july-9-2024} @@ -228,7 +228,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 現在、このライブラリには`/system/query`エンドポイントのみが含まれています。このエンドポイントを使用すると、定義済みの`sql`パラメータにSQL文を渡すだけで、任意のSQL文を実行できます。このエンドポイントにより、SQLクエリを即座に実行できるため、柔軟性と効率性が向上します。 - 詳細については、 [定義済みのシステムエンドポイントを追加します](/tidb-cloud/data-service-manage-endpoint.md#add-a-predefined-system-endpoint)参照してください。 + 詳細については、 [定義済みのシステムエンドポイントを追加します](/tidb-cloud/data-service-manage-endpoint.md#add-a-predefined-system-endpoint)を参照してください。 - スロークエリのデータストレージを強化する。 @@ -268,7 +268,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - **SQLエディタ**： TiDB CloudコンソールでSQLクエリを手動で記述および実行するためのデフォルトインターフェース。 - **Chat2Query** ：AIを活用したテキストクエリ機能で、自然言語を使ってデータベースと対話し、SQLクエリを生成、書き換え、最適化することができます。 - 詳細については、[AI支援型SQLエディタでデータを探索しよう](/tidb-cloud/explore-data-with-chat2query.md)参照してください。 + 詳細については、[AI支援型SQLエディタでデータを探索しよう](/tidb-cloud/explore-data-with-chat2query.md)を参照してください。 ## 2024年6月18日 {#june-18-2024} @@ -352,7 +352,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [ローカルストレージからTiDB Cloud Serverlessクラスターにデータをインポートする](/tidb-cloud/ticloud-import-start.md) - [OAuth経由で認証する](/tidb-cloud/ticloud-auth-login.md) - TiDB Cloud CLI をアップグレードする前に、この新しい CLI は以前のバージョンと互換性がないことに注意してください。たとえば、CLI コマンドの`ticloud cluster`は`ticloud serverless`に更新されます。詳細については、 [TiDB Cloud CLI リファレンス](/tidb-cloud/cli-reference.md)参照してください。 . + TiDB Cloud CLI をアップグレードする前に、この新しい CLI は以前のバージョンと互換性がないことに注意してください。たとえば、CLI コマンドの`ticloud cluster`は`ticloud serverless`に更新されます。詳細については、 [TiDB Cloud CLI リファレンス](/tidb-cloud/cli-reference.md)を参照してください。 . ## 2024年4月9日 {#april-9-2024} @@ -372,7 +372,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - TiDB Cloud Serverless クラスターが使用量クォータに達した際のスロットリング動作を変更します。クラスターが使用量クォータに達すると、新規接続試行を即座に拒否し、既存の操作に対するサービスの中断を防ぎます。 - 詳細については、 [使用クォータ](/tidb-cloud/serverless-limitations.md#usage-quota)参照してください。 + 詳細については、 [使用クォータ](/tidb-cloud/serverless-limitations.md#usage-quota)を参照してください。 ## 2024年3月5日 {#march-5-2024} @@ -435,7 +435,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 注：プロジェクトに対する以前のグローバルレベルのCIDR設定は廃止されますが、アクティブな状態にある既存の地域別CIDRはすべて影響を受けません。既存のクラスターのネットワークにも影響はありません。 - 詳細については、 [地域ごとにCIDRを設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)参照してください。 + 詳細については、 [地域ごとにCIDRを設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)を参照してください。 - TiDB Cloud Serverlessのユーザーは、クラスターのパブリックエンドポイントを無効にすることができるようになりました。 @@ -445,7 +445,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ TiDB Cloud Data Serviceは、デフォルトでは各データアプリのエンドポイントにアクセスするためのドメイン`.data.tidbcloud.com`を提供します。パーソナライズと柔軟性をさらに高めるため、デフォルトドメインの代わりにデータアプリにカスタムドメインを設定できるようになりました。この機能により、データベースサービスにブランドURLを使用でき、セキュリティも強化されます。 - 詳細については、 [データサービスのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)参照してください。 + 詳細については、 [データサービスのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)を参照してください。 ## 2024年1月3日 {#january-3-2024} diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index 728c505030c58..8e6b9e6278bbd 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -22,7 +22,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - スケーリング操作およびローリング アップグレード中に永続的なクライアント接続を維持します。 - リソース利用率を向上させるために、TiDB ノード全体にトラフィックを均等に分散します。 - 詳細については[TiProxyの概要](/tidb-cloud/tiproxy-overview-for-cloud.md)参照してください。 + 詳細については[TiProxyの概要](/tidb-cloud/tiproxy-overview-for-cloud.md)を参照してください。 - **TiDB Cloud Essential** @@ -34,7 +34,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま プライベートリンク接続は、 [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} @@ -46,7 +46,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 既存の変更フィードを複製する際に、主要な設定とルーティング情報を保持できるようになりました。この機能により、失敗した変更フィードを迅速に再作成したり、同様の設定で新しい変更フィードを作成したりできるため、セットアップ時間と運用上の労力を削減できます。 - 詳細については[チェンジフィードを複製する](/tidb-cloud/changefeed-overview.md#duplicate-a-changefeed)参照してください。 + 詳細については[チェンジフィードを複製する](/tidb-cloud/changefeed-overview.md#duplicate-a-changefeed)を参照してください。 **コンソールの変更** @@ -90,7 +90,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま [監査ログの一覧表示](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/#tag/Audit-Log/paths/~1auditLogs/get)エンドポイントは、コンソール監査ログへのプログラムによるアクセスを提供します。このエンドポイントを使用することで、監査ログを自動的に取得し、セキュリティとコンプライアンスの要件を満たすために定期的なバックアップをスケジュールできます。 - 詳細については[TiDB CloudIAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)参照してください。 + 詳細については[TiDB CloudIAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)を参照してください。 ## 2025年12月2日 {#december-2-2025} @@ -102,9 +102,9 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloudは、Prometheusとの連携をクラスターレベルで管理するようになり、よりきめ細かな制御と設定が可能になります。この機能により、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのメトリクスをシームレスにPrometheusに送信できるようになり、統合プラットフォームで高度なアラート機能を実現できます。 - 統合手順については、 [TiDB Cloud をPrometheus および Grafana と統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)参照してください。 + 統合手順については、 [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} @@ -116,7 +116,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 以前は、変更フィードを一時停止して設定を確認し、再開する必要がありました。**変更フィード**ページでは、サマリービューに完全な設定が直接表示されるようになりました。今回のアップデートでは、編集モードと表示モードの一貫性を維持し、レイアウトを再設計して読​​みやすさを向上させました。これにより、現在の設定をより効率的に確認できます。 - 詳細については[チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)参照してください。 + 詳細については[チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)を参照してください。 ## 2025年11月11日 {#november-11-2025} @@ -128,7 +128,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能を使用すると、元の構成を正確に復元するか、ニーズに合った別のストレージタイプを選択できます。 - 詳細については[新しいクラスターにデータを復元する](/tidb-cloud/backup-and-restore.md#restore-data-to-a-new-cluster)参照してください。 + 詳細については[新しいクラスターにデータを復元する](/tidb-cloud/backup-and-restore.md#restore-data-to-a-new-cluster)を参照してください。 ## 2025年11月4日 {#november-4-2025} @@ -138,11 +138,11 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - Google Cloud でホストされている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに VPC ピアリング経由で接続する場合、 [TiDB Cloudコンソール](https://tidbcloud.com/)で`/16` ～ `/18` IP 範囲サイズを直接設定できるようになりました。この設定についてTiDB Cloudサポートに連絡する必要がなくなりました。 - 詳細については[VPC ピアリング経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-vpc-peering-connections.md)参照してください。 + 詳細については[VPC ピアリング経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 - TiDB Cloud Dedicated では、4 vCPU ノードサイズに関するガイダンスとメッセージがより明確になりました。このノードサイズは、非本番環境でのTiDB Cloud機能のテスト、学習、および探索にのみ使用してください。 - 詳細については[TiDBのサイズを決定する](/tidb-cloud/size-your-cluster.md)参照してください。 + 詳細については[TiDBのサイズを決定する](/tidb-cloud/size-your-cluster.md)を参照してください。 ## 2025年10月28日 {#october-28-2025} @@ -152,7 +152,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 接続の安定性を向上させ、TiDBサーバーの再起動またはメンテナンス中に予期しない切断を防ぐには、データベース接続の最大有効期間を 30 分未満に設定することをお勧めします。 - 詳細については[接続の有効期間を設定する](/develop/dev-guide-connection-parameters.md#configure-the-lifetime-of-connections)参照してください。 + 詳細については[接続の有効期間を設定する](/develop/dev-guide-connection-parameters.md#configure-the-lifetime-of-connections)を参照してください。 **APIの変更** @@ -178,13 +178,13 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **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)が使用可能です。 TiDB Cloudは、Prometheusとの連携をクラスターレベルで管理するようになり、よりきめ細かな制御と設定が可能になります。この機能により、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのメトリクスをシームレスにPrometheusに送信できるようになり、統合プラットフォームで高度なアラート機能を実現できます。 - 詳細については[TiDB Cloud をPrometheus および Grafana と統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)参照してください。 + 詳細については[TiDB Cloud をPrometheus および Grafana と統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)を参照してください。 ## 2025年10月14日 {#october-14-2025} @@ -215,7 +215,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - 詳細については[TiDB Cloud Essential が AWS と Alibaba Cloud でパブリックプレビューとして利用可能になりました](https://www.pingcap.com/blog/tidb-cloud-essential-now-available-public-preview-aws-alibaba-cloud/)参照してください。 + 詳細については[TiDB Cloud Essential が AWS と Alibaba Cloud でパブリックプレビューとして利用可能になりました](https://www.pingcap.com/blog/tidb-cloud-essential-now-available-public-preview-aws-alibaba-cloud/)を参照してください。 @@ -229,7 +229,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 使用量の上限を超えると、処理能力が制限される可能性があります。サービスへの影響を避けるため、最大RCUを増やすことをご検討ください。 - イベントの詳細については、 [TiDB Cloudクラスタイベント](/tidb-cloud/tidb-cloud-events.md)参照してください。 + イベントの詳細については、 [TiDB Cloudクラスタイベント](/tidb-cloud/tidb-cloud-events.md)を参照してください。 - [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page)ページ[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)では、より迅速な診断と容量計画のために次のメトリックが追加されます。 @@ -237,7 +237,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - `Lock-wait (P95/P99)` : ロック待機時間のパーセンタイルを監視して競合ホットスポットを表面化させます。 - `Idle Connection Duration (P99 incl. not/in txn)` : プーラーの制限とタイムアウトを調整するために、トランザクション中とトランザクション外での長時間アイドル状態の接続を識別します。 - 詳細については[TiDB Cloud組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)参照してください。 + 詳細については[TiDB Cloud組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)を参照してください。 ## 2025年9月30日 {#september-30-2025} @@ -251,7 +251,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} @@ -265,7 +265,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能は、[クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)、[Apache Kafka へのシンク](/tidb-cloud/changefeed-sink-to-apache-kafka.md)、および[Apache Pulsar へのシンク](/tidb-cloud/changefeed-sink-to-apache-pulsar.md)で利用可能です。 - 分割動作の詳細については、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 + 分割動作の詳細については、 [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`指定します。 @@ -295,7 +295,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 2. プロジェクトの CMEK 構成を完了します。 3. CMEK 構成と同じリージョンの Azure でホストされるTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[Azure での顧客管理の暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)参照してください。 + 詳細については[Azure での顧客管理の暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)を参照してください。 ## 2025年9月9日 {#september-9-2025} @@ -312,7 +312,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - 新しく作成された[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターでは、リージョン高可用性がデフォルトで有効になっており、クラスターの作成時に必要に応じてゾーン高可用性に変更できます。 - 詳細については[TiDB Cloud StarterとEssentialの高可用性](/tidb-cloud/serverless-high-availability.md)参照してください。 + 詳細については[TiDB Cloud StarterとEssentialの高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 @@ -352,19 +352,19 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **AWS Bedrock とのネイティブ統合**: AWS Bedrock の Amazon Titan および Cohere テキスト埋め込みモデルを含む、無料クォータで管理される埋め込みモデル。 - **SQL および Python のサポート**、埋め込みの作成、保存、クエリのコード例。 - 詳細については[自動埋め込み](https://docs.pingcap.com/tidbcloud/vector-search-auto-embedding-overview/?plan=starter)参照してください。 + 詳細については[自動埋め込み](https://docs.pingcap.com/tidbcloud/vector-search-auto-embedding-overview/?plan=starter)を参照してください。 - **TiDB Cloud Dedicated** - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)では Index Insight (ベータ) 機能はサポートされなくなりました。 - 代わりに、TiDB v8.5.0 以降のバージョンで利用可能な[インデックスアドバイザー](/index-advisor.md)使用することをお勧めします。Index Advisor では`RECOMMEND INDEX` SQL ステートメントが導入されており、クエリのパフォーマンスを向上させるインデックスを推奨することで、ワークロードの最適化に役立ちます。 + 代わりに、TiDB v8.5.0 以降のバージョンで利用可能な[インデックスアドバイザー](/index-advisor.md)を使用することをお勧めします。Index Advisor では`RECOMMEND INDEX` SQL ステートメントが導入されており、クエリのパフォーマンスを向上させるインデックスを推奨することで、ワークロードの最適化に役立ちます。 - 週次バックアップが有効になっている[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで、ポイントインタイム リストア機能を手動で無効にできるようになりました。 この機能強化により、高 RPO 保護のためのポイントインタイム リストアを必要としないクラスターのコストが削減されます。 - 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)を参照してください。 ## 2025年8月12日 {#august-12-2025} @@ -408,7 +408,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [**高度な**](/tidb-cloud/built-in-monitoring.md#advanced)カテゴリでは、**影響を受ける行**、**Leader数**、および**リージョン数の**メトリックを追加して診断を改善します。 - [**サーバ**](/tidb-cloud/built-in-monitoring.md#server)カテゴリでは、 **TiKV IO Bps**メトリックを改良して、精度と一貫性を向上させます。 - 詳細については[TiDB Cloud組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)参照してください。 + 詳細については[TiDB Cloud組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)を参照してください。 @@ -433,7 +433,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [**高度な**](/tidb-cloud/built-in-monitoring.md#advanced)カテゴリでは、**影響を受ける行**、**Leader数**、および**リージョン数の**メトリックを追加して診断を改善します。 - [**サーバ**](/tidb-cloud/built-in-monitoring.md#server)カテゴリでは、 **TiKV IO Bps**メトリックを改良して、精度と一貫性を向上させます。 - 詳細については[TiDB Cloud組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)参照してください。 + 詳細については[TiDB Cloud組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)を参照してください。 @@ -455,13 +455,13 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **エクスポート**: クラスターのデータ エクスポート タスクを管理します。 - **インポート**: クラスターのデータ インポート タスクを管理します。 - 詳細については[TiDB Cloud Starterと基本 API](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless/)参照してください。 + 詳細については[TiDB Cloud Starterと基本 API](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless/)を参照してください。 - TiDB Cloud IAM API (v1beta1) は、組織レベルとプロジェクトレベルの両方で API キー管理のロールベースのアクセス制御 (RBAC) をサポートします。 セキュリティとアクセス制御を強化するために、組織レベルまたはプロジェクト レベルで API キーのロールを設定できます。 - 詳細については[TiDB CloudIAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)参照してください。 + 詳細については[TiDB CloudIAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/)を参照してください。 ## 2025年7月31日 {#july-31-2025} @@ -522,13 +522,13 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能強化により、セキュリティとコンプライアンスの要件を満たすためにバックアップ完了アクティビティをログに記録できます。 - 詳細については[コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md)参照してください。 + 詳細については[コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md)を参照してください。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 変更フィード内の列値のフィルタリングをサポートします。 式を使用して変更フィード内の特定の列値をフィルタリングし、ソースで無関係なデータを除外できるようになりました。この機能により、DMLイベントのきめ細かなフィルタリングが可能になり、リソース消費を削減し、パフォーマンスを向上させることができます。 - 詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md)参照してください。 + 詳細については[チェンジフィード](/tidb-cloud/changefeed-overview.md)を参照してください。 ## 2025年6月24日 {#june-24-2025} @@ -542,7 +542,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能を使用すると、キー管理サービス (KMS) を通じて管理する対称暗号化キーを活用して、保存中のデータを保護できます。 - 詳細については[AWS での顧客管理の暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)参照してください。 + 詳細については[AWS での顧客管理の暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)を参照してください。 ## 2025年6月17日 {#june-17-2025} @@ -550,7 +550,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの場合、16 vCPU および 32 vCPU を持つ TiKV ノードの最大ストレージサイズが**6144 GiB**から**4096 GiB**に変更されます。 - 詳細については[TiKVノードのストレージサイズ](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)参照してください。 + 詳細については[TiKVノードのストレージサイズ](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)を参照してください。 **コンソールの変更** @@ -588,7 +588,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま これで、 `tidbcloud_disk_read_latency`や`tidbcloud_kv_request_duration`などの追加のメトリックを Prometheus に統合して、 TiDB Cloud Dedicated のパフォーマンスのより多くの側面を追跡できるようになりました。 - 利用可能なメトリックと、既存ユーザーと新規ユーザーの両方に対してメトリックを有効にする方法の詳細については、 [TiDB Cloud をPrometheus および Grafana と統合する (ベータ版)](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)参照してください。 + 利用可能なメトリックと、既存ユーザーと新規ユーザーの両方に対してメトリックを有効にする方法の詳細については、 [TiDB Cloud をPrometheus および Grafana と統合する (ベータ版)](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)を参照してください。 - TiKV [標準](/tidb-cloud/size-your-cluster.md#standard-storage)および[パフォーマンス](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage)ストレージの価格が正式に発表されました。 @@ -632,11 +632,11 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能強化により、TiDB Cloud Dedicated クラスターの分析データストレージ容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 - 詳細については[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)参照してください。 + 詳細については[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)を参照してください。 - メンテナンス タスクを構成および再スケジュールするための直感的なオプションを提供することで、メンテナンス ウィンドウの構成エクスペリエンスを強化します。 - 詳細については[メンテナンスウィンドウを構成する](/tidb-cloud/configure-maintenance-window.md)参照してください。 + 詳細については[メンテナンスウィンドウを構成する](/tidb-cloud/configure-maintenance-window.md)を参照してください。 - TiKV [標準](/tidb-cloud/size-your-cluster.md#standard-storage)および[パフォーマンス](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage)ストレージタイプの割引期間を延長します。プロモーションは2025年6月5日に終了します。この日以降は、価格が標準料金に戻ります。 @@ -654,7 +654,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターは、 [アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)を使用して[Alibaba Cloud オブジェクト ストレージ サービス (OSS)](https://www.alibabacloud.com/en/product/object-storage-service)にデータをエクスポートできるようになりました。 - 詳細については[TiDB Cloud Serverlessからデータをエクスポート](/tidb-cloud/serverless-export.md#alibaba-cloud-oss)参照してください。 + 詳細については[TiDB Cloud Serverlessからデータをエクスポート](/tidb-cloud/serverless-export.md#alibaba-cloud-oss)を参照してください。 - [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターの TiDB バージョンを[バージョン7.1.3](https://docs.pingcap.com/tidb/stable/release-7.1.3)から[バージョン7.5.2](https://docs.pingcap.com/tidb/stable/release-7.5.2)にアップグレードします。 @@ -717,7 +717,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloud Serverless クラスターのファイアウォールルールを設定して、パブリックエンドポイント経由のアクセスを制御できるようになりました。1 [TiDB Cloudコンソール](https://tidbcloud.com/)許可する IP アドレスまたは範囲を直接指定することで、セキュリティを強化できます。 - 詳細については[パブリックエンドポイント用のTiDB Cloudサーバーレス ファイアウォール ルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)参照してください。 + 詳細については[パブリックエンドポイント用のTiDB Cloudサーバーレス ファイアウォール ルールを構成する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md)を参照してください。 ## 2025年3月18日 {#march-18-2025} @@ -725,17 +725,17 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - リソース管理の柔軟性を高めるために、Google Cloud にデプロイされた[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して TiDB ノードグループの作成をサポートします。 - 詳細については[TiDBノードグループの概要](/tidb-cloud/tidb-node-group-overview.md)参照してください。 + 詳細については[TiDBノードグループの概要](/tidb-cloud/tidb-node-group-overview.md)を参照してください。 - AWS にデプロイされた[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのTiDB Cloudにデータベース監査ログ ファイルを保存することをサポートします。 これらの監査ログファイルは、 TiDB Cloudから直接ダウンロードできます。この機能はリクエストに応じてのみ利用可能であることにご注意ください。 - 詳細については[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)参照してください。 + 詳細については[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)を参照してください。 - 多要素認証（MFA）の管理を改善することで、 TiDB Cloudアカウントのセキュリティを強化します。この機能は、TiDB Cloudのパスワードベースのログインに適用されます。 - 詳細については[パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)参照してください。 + 詳細については[パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)を参照してください。 ## 2025年2月18日 {#february-18-2025} @@ -766,7 +766,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - タスクあたり最大 250 MiB の単一のローカル CSV ファイルを[TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターにインポートできるようになりました。これは、以前の 50 MiB の制限から増加されました。 - 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)参照してください。 + 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)を参照してください。 ## 2025年1月14日 {#january-14-2025} @@ -776,7 +776,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - 通知機能を導入すると、 [TiDB Cloudコンソール](https://tidbcloud.com/)を通じてTiDB Cloud の更新とアラートに関する最新情報を即座に入手できます。 - 詳細については[通知](/tidb-cloud/notifications.md)参照してください。 + 詳細については[通知](/tidb-cloud/notifications.md)を参照してください。 ## 2025年1月2日 {#january-2-2025} @@ -784,7 +784,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - リソース管理の柔軟性を高めるために、 [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでの TiDB ノードグループの作成をサポートします。 - 詳細については[TiDBノードグループの概要](/tidb-cloud/tidb-node-group-overview.md)参照してください。 + 詳細については[TiDBノードグループの概要](/tidb-cloud/tidb-node-group-overview.md)を参照してください。 - Private Connect (ベータ版) を介して[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを AWS および Google Cloud の汎用 Kafka に接続することをサポートします。 @@ -796,17 +796,17 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能を使用すると、追加の[プライベートデータリンクのコスト](/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md#private-data-link-cost)が発生することに注意してください。 - 詳細については[Apache Kafka への Changefeed シンク](/tidb-cloud/changefeed-sink-to-apache-kafka.md#network)参照してください。 + 詳細については[Apache Kafka への Changefeed シンク](/tidb-cloud/changefeed-sink-to-apache-kafka.md#network)を参照してください。 - Kafka の変更フィードに追加の構成可能なオプションを導入します。 - - Debeziumプロトコルのサポート。Debeziumはデータベースの変更をキャプチャするためのツールです。キャプチャされたデータベースの変更はイベントと呼ばれるメッセージに変換され、Kafkaに送信されます。詳細については、 [TiCDC Debeziumプロトコル](https://docs.pingcap.com/tidb/v8.1/ticdc-debezium)参照してください。 + - Debeziumプロトコルのサポート。Debeziumはデータベースの変更をキャプチャするためのツールです。キャプチャされたデータベースの変更はイベントと呼ばれるメッセージに変換され、Kafkaに送信されます。詳細については、 [TiCDC Debeziumプロトコル](https://docs.pingcap.com/tidb/v8.1/ticdc-debezium)を参照してください。 - すべてのテーブルに対して単一のパーティション ディスパッチャーを定義することも、テーブルごとに異なるパーティション ディスパッチャーを定義することもサポートします。 - Kafka メッセージのパーティション分散用に、タイムスタンプと列値という 2 つの新しいディスパッチャ タイプを導入しました。 - 詳細については[Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 + 詳細については[Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 - TiDB Cloudでの役割の強化: @@ -818,7 +818,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - `Organization Billing Admin`から`Organization Billing Manager` - `Organization Console Audit Admin`から`Organization Console Audit Manager` - 詳細については[アイデンティティアクセス管理](/tidb-cloud/manage-user-access.md#organization-roles)参照してください。 + 詳細については[アイデンティティアクセス管理](/tidb-cloud/manage-user-access.md#organization-roles)を参照してください。 - [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターのリージョン高可用性 (ベータ版)。 @@ -830,7 +830,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま この機能は現在、AWS 東京 (ap-northeast-1) リージョンでのみ利用可能で、クラスターの作成時にのみ有効にできます。 - 詳細については[TiDB Cloud Serverless の高可用性](/tidb-cloud/serverless-high-availability.md)参照してください。 + 詳細については[TiDB Cloud Serverless の高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 - 新しい[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデフォルトの TiDB バージョンを[バージョン8.1.1](https://docs.pingcap.com/tidb/stable/release-8.1.1)から[バージョン8.1.2](https://docs.pingcap.com/tidb/stable/release-8.1.2)にアップグレードします。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index 3fbf398dd538a..888c0c08fcd75 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -190,7 +190,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] Alibaba Cloud Key Management Service (KMS) では、独自のキーを使用して保存データを暗号化できるため、データセキュリティとコンプライアンスをより詳細に管理できます。 - この機能はリクエストに応じて利用できるようになりました。詳細については、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)参照してください。 + この機能はリクエストに応じて利用できるようになりました。詳細については、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)を参照してください。 - TiDB Cloud Premiumインスタンス向けに、**メトリクス**ページ（**インスタンス概要**タブ）に2つの新しいTTL監視メトリクスを追加します。 @@ -237,7 +237,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] 新しい`/members`エンドポイントを使用すると、組織のメンバーシップと役割の割り当てを管理できます。これらのエンドポイントを使用して、特定の役割を持つ新規メンバーのオンボーディング、責任の変更に伴う権限の調整、組織を離れるメンバーの削除など、ユーザーライフサイクル管理タスクを自動化できます。 - 詳細については、 [TiDB Cloud IAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/#tag/Member)参照してください。 + 詳細については、 [TiDB Cloud IAM API](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam/#tag/Member)を参照してください。 ## 2026年5月19日 {#may-19-2026} @@ -249,7 +249,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] バックアップが存在するTiDB Cloud Essentialインスタンスが削除されると、そのバックアップ ファイルはごみ箱に移動されます。自動バックアップによって作成されたバックアップ ファイルは、指定された期間、ごみ箱に保持されます。データ損失を防ぐため、保持期間が終了する前に、新しいTiDB Cloud Essentialインスタンスにデータを復元してください。なお、 TiDB Cloud Essentialインスタンス**にバックアップがない**場合、削除されたインスタンスはごみ箱に表示されません。 - 詳細については、 [バックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#restore-from-recycle-bin)参照してください。 + 詳細については、 [バックアップと復元](/tidb-cloud/backup-and-restore-serverless.md#restore-from-recycle-bin)を参照してください。 - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)の Top RU が、以下のリージョンでパブリックプレビューとして利用可能になりました。 @@ -275,7 +275,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] TiDB Cloud Dedicatedは、99.99%の稼働率SLAを備えた3つのAZ構成による高可用性、 TiFlashによる完全なHTAP、独立したコンピューティングとストレージのスケーリング、PingCAP SREによる完全マネージド運用、シームレスなデータインポートと移行、PITRによる継続的なバックアップ、エンタープライズグレードのセキュリティ、および統合された可観測性を提供します。また、一括データインポート、MySQLやその他のソースからの移行、ダウンストリームシステムへのリアルタイムレプリケーションもサポートしています。Azure [Azure Marketplace](https://azuremarketplace.microsoft.com/)ご利用の場合は、Azure MarketplaceからTiDB Cloud Dedicatedをサブスクライブすることもできます。 - 詳細については、 [プレビュー版から本番環境へ：Microsoft Azure 上のTiDB Cloud Dedicatedが一般提供開始](https://www.pingcap.com/blog/tidb-cloud-dedicated-ga-microsoft-azure/)参照してください。 + 詳細については、 [プレビュー版から本番環境へ：Microsoft Azure 上のTiDB Cloud Dedicatedが一般提供開始](https://www.pingcap.com/blog/tidb-cloud-dedicated-ga-microsoft-azure/)を参照してください。 ## 2026年4月28日 {#april-28-2026} @@ -292,9 +292,9 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - TiDB Cloud Essentialと比較して、 TiDB Cloud Premiumはコンピューティング、storage、ネットワークの各レイヤーにおいて大幅に強化された分離性を提供し、重要なワークロードに対して予測可能なパフォーマンスを保証します。同時に、柔軟性の高いオンデマンドのスケーリングモデルを維持しており、運用上のオーバーヘッドなしにコンピューティング能力を個別に拡張できます。 - TiDB Cloud Dedicatedと比較して、 TiDB Cloud Premiumはアイドル状態の余裕を排除することでコスト効率を向上させ、実際に使用したパフォーマンスに対してのみ料金を支払うことができます。 - TiDB Cloud Premium の詳細については、 [TiDB Cloud Premium: ミッションクリティカルなSQLのパブリックプレビュー](https://www.pingcap.com/blog/tidb-cloud-premium-public-preview/)参照してください。 + TiDB Cloud Premium の詳細については、 [TiDB Cloud Premium: ミッションクリティカルなSQLのパブリックプレビュー](https://www.pingcap.com/blog/tidb-cloud-premium-public-preview/)を参照してください。 - TiDB Cloud Premium を試すには、 [TiDB Cloudコンソール](https://tidbcloud.com/)に移動し、 **[Create Resource]**をクリックして、プランとして**[Premium]**を選択します。詳細については、 [TiDB Cloud Premiumインスタンスを作成します](/tidb-cloud/premium/create-tidb-instance-premium.md)参照してください。 + TiDB Cloud Premium を試すには、 [TiDB Cloudコンソール](https://tidbcloud.com/)に移動し、 **[Create Resource]**をクリックして、プランとして**[Premium]**を選択します。詳細については、 [TiDB Cloud Premiumインスタンスを作成します](/tidb-cloud/premium/create-tidb-instance-premium.md)を参照してください。 - **TiDB Cloud Dedicated** @@ -305,7 +305,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - スケーリング操作およびローリングアップグレード中も、クライアントとの永続的な接続を維持します。 - リソース利用効率を向上させるため、TiDBノード全体にトラフィックを均等に分散します。 - 実装の詳細については、 [TiProxyの概要](/tidb-cloud/tiproxy-overview-for-cloud.md)参照してください。 + 実装の詳細については、 [TiProxyの概要](/tidb-cloud/tiproxy-overview-for-cloud.md)を参照してください。 **コンソールの変更** @@ -323,7 +323,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **バックアップ**： TiDB Cloud Premiumインスタンスのバックアップを管理します。バックアップベースのリストア機能も含まれます。 - **リージョン**： TiDB Cloud Premiumインスタンスを作成するために利用可能なリージョンを取得します。 - 詳細については、 [TiDB Cloud Premium API](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium/)参照してください。 + 詳細については、 [TiDB Cloud Premium API](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium/)を参照してください。 ## 2026年4月14日 {#april-14-2026} @@ -354,7 +354,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **変更案内ツアー**：既存ユーザー向けに、構造変更について説明するガイド付きウォークスルーを実施し、移行期間中の混乱を軽減します。 - 詳細については、 [TiDB Cloudのリソースとプロジェクトを管理する](/tidb-cloud/manage-projects-and-resources.md)および[TiDB Xインスタンスのプロジェクト移行に関するFAQ](/tidb-cloud/tidbx-instance-move-faq.md)参照してください。 + 詳細については、 [TiDB Cloudのリソースとプロジェクトを管理する](/tidb-cloud/manage-projects-and-resources.md)および[TiDB Xインスタンスのプロジェクト移行に関するFAQ](/tidb-cloud/tidbx-instance-move-faq.md)を参照してください。 **APIの変更** @@ -365,7 +365,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - アプリケーションがプロジェクト応答から`id`および`name`フィールドのみを読み取る場合は、変更は必要ありません。 - [プロジェクトの種類](/tidb-cloud/tidbx-instance-move-faq.md#what-project-types-are-available-in-tidb-cloud)を区別する必要がある場合 (たとえば、専用プロジェクト、TiDB X プロジェクト、または TiDB X 仮想プロジェクトをフィルターするため)、 `type`フィールドの読み取りを開始します。 -詳細については、 [TiDB Cloud StarterおよびEssential向けプロジェクトAPI移行ガイド](/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md)参照してください。 +詳細については、 [TiDB Cloud StarterおよびEssential向けプロジェクトAPI移行ガイド](/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md)を参照してください。 ## 2026年4月8日 {#april-8-2026} @@ -401,7 +401,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)クラスターレベルでPrometheusとの連携を管理します。この機能により、 TiDB Cloud EssentialクラスターからPrometheusへメトリクスをシームレスに送信でき、統合プラットフォーム上で高度なアラート機能を実現できます。 - 統合手順については、 [TiDB CloudをPrometheusおよびGrafanaと統合する](/tidb-cloud/prometheus-grafana-integration.md)参照してください。 + 統合手順については、 [TiDB CloudをPrometheusおよびGrafanaと統合する](/tidb-cloud/prometheus-grafana-integration.md)を参照してください。 ## 2026年3月24日 {#march-24-2026} @@ -425,7 +425,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [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)参照してください。 + 詳細については、 [プライベートリンク接続を介してAmazon MSK Provisionedに接続します](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)を参照してください。 ## 2026年3月3日 {#march-3-2026} @@ -437,7 +437,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでは、既存の AK/SK 認証方法に加え、 IAMロール ARN を使用して Amazon S3 シンクの変更フィードを設定できるようになりました。この機能により、有効期限の短い認証情報と自動ローテーションが可能になり、セキュリティが強化されるとともに、シークレット管理が簡素化され、最小権限の原則がサポートされます。 - 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)を参照してください。 - TiKVおよびTiFlashのストレージ使用量計算を改善します。 @@ -467,7 +467,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] Azure Blob Storage から[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターにデータをインポートする際、接続方法としてプライベートリンクを選択し、パブリックインターネットではなく Azure プライベートエンドポイント経由で接続できるようになりました。この機能により、パブリックアクセスが制限されているストレージアカウントでも、安全でネットワーク分離されたデータインポートが可能になります。 - 詳細については、[クラウドストレージからサンプルデータ（SQLファイル）をインポートする](/tidb-cloud/import-sample-data.md)[クラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)[クラウドストレージからApache Parquetファイルをインポートする](/tidb-cloud/import-parquet-files.md)参照してください。 + 詳細については、[クラウドストレージからサンプルデータ（SQLファイル）をインポートする](/tidb-cloud/import-sample-data.md)[クラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)[クラウドストレージからApache Parquetファイルをインポートする](/tidb-cloud/import-parquet-files.md)を参照してください。 - セキュリティ追跡を強化するため、 TiDB Cloudのコンソール監査ログに「パブリックエンドポイントの有効化/無効化」イベントを追加します。 @@ -481,7 +481,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 、変更フィードデータをAzure Blob Storageに直接保存する機能をサポートするようになりました。この機能により、Azureベースのユーザーは、変更データを効率的にアーカイブして、下流の分析や長期保存に活用できます。また、中間メッセージキューが不要になるためコスト削減にもつながり、既存のAmazon S3およびGoogle Cloud Storage（GCS）シンクとのフォーマット互換性も維持されます。 - 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)を参照してください。 ## 2026年1月27日 {#january-27-2026} diff --git a/tidb-cloud/scalability-concepts.md b/tidb-cloud/scalability-concepts.md index d3ce9c27bc3a9..d266f903bc7d2 100644 --- a/tidb-cloud/scalability-concepts.md +++ b/tidb-cloud/scalability-concepts.md @@ -14,7 +14,7 @@ TiDB Cloudは、さまざまなワークロードのニーズに対応できる > **ヒント：** > -> TiDB Cloud Dedicatedクラスターのサイズを決定する方法については、 [TiDBサイズを決定する](/tidb-cloud/size-your-cluster.md)参照してください。 +> TiDB Cloud Dedicatedクラスターのサイズを決定する方法については、 [TiDBサイズを決定する](/tidb-cloud/size-your-cluster.md)を参照してください。 ## 垂直方向および水平方向のスケーリング {#vertical-and-horizontal-scaling} diff --git a/tidb-cloud/scale-tidb-cluster.md b/tidb-cloud/scale-tidb-cluster.md index bafc5c0413dd2..dae0060b7999f 100644 --- a/tidb-cloud/scale-tidb-cluster.md +++ b/tidb-cloud/scale-tidb-cluster.md @@ -16,7 +16,7 @@ TiDB クラスターは次の次元で拡張できます。 - TiDB、TiKV、 TiFlashの vCPU と RAM - TiKVとTiFlashの保存 -TiDB クラスターのサイズを決定する方法については、 [TiDBのサイズを決定する](/tidb-cloud/size-your-cluster.md)参照してください。 +TiDB クラスターのサイズを決定する方法については、 [TiDBのサイズを決定する](/tidb-cloud/size-your-cluster.md)を参照してください。 > **注記：** > @@ -63,7 +63,7 @@ TiDB、TiKV、またはTiFlashノードの vCPU と RAM を増減できます。 > - Google Cloud でホストされ、2023/04/26 以降に作成されています。 > - Azure でホストされます。 > - AWS では、vCPU と RAM の変更にクールダウン期間があります。TiDB クラスターが AWS でホストされている場合、TiKV またはTiFlashの vCPU と RAM を変更した後、再度変更するには少なくとも 6 時間待つ必要があります。 -> - vCPUを減らす前に、TiKVまたはTiFlashの現在のノードストレージが、対象のvCPUの最大ノードストレージを超えていないことを確認してください。詳細は[TiKVノードストレージ](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)と[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)参照してください。いずれかのコンポーネントの現在のストレージが上限を超えている場合は、vCPUを減らすことはできません。 +> - vCPUを減らす前に、TiKVまたはTiFlashの現在のノードストレージが、対象のvCPUの最大ノードストレージを超えていないことを確認してください。詳細は[TiKVノードストレージ](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)と[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)を参照してください。いずれかのコンポーネントの現在のストレージが上限を超えている場合は、vCPUを減らすことはできません。 TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更するには、次の手順を実行します。 diff --git a/tidb-cloud/secure-connections-to-serverless-clusters.md b/tidb-cloud/secure-connections-to-serverless-clusters.md index 94c9c10587d78..f374124f53d91 100644 --- a/tidb-cloud/secure-connections-to-serverless-clusters.md +++ b/tidb-cloud/secure-connections-to-serverless-clusters.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] > **注記：** > -> TiDB Cloud Dedicated クラスターへの TLS 接続を確立する方法については、 [TiDB Cloud DedicatedへのTLS接続](/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md)参照してください。 +> TiDB Cloud Dedicated クラスターへの TLS 接続を確立する方法については、 [TiDB Cloud DedicatedへのTLS接続](/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md)を参照してください。 ## 前提条件 {#prerequisites} @@ -39,7 +39,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] > **注記：** > - > TiDB Cloudクラスターに接続する際は、ユーザー名にクラスターのプレフィックスを含め、引用符で囲む必要があります。詳細については、 [ユーザー名のプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)参照してください。 + > TiDB Cloudクラスターに接続する際は、ユーザー名にクラスターのプレフィックスを含め、引用符で囲む必要があります。詳細については、 [ユーザー名のプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を参照してください。 ## ルート証明書の管理 {#root-certificate-management} @@ -47,7 +47,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [レッツ・エンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 -JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスタに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlクライアント](https://github.com/PyMySQL/mysqlclient)使用してTiDB Cloudクラスタに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`設定する必要があります。 +JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスタに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlクライアント](https://github.com/PyMySQL/mysqlclient)を使用してTiDB Cloudクラスタに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`設定する必要があります。 複数の証明書が含まれる証明書ファイルを受け入れない DBeaver などの GUI クライアントを使用している場合は、 [ISRGルートX1](https://letsencrypt.org/certs/isrgrootx1.pem)証明書をダウンロードする必要があります。 @@ -77,7 +77,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ルートパスを指定するには、次の手順に従います。 +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 ルート パスとして使用します。 diff --git a/tidb-cloud/security-concepts.md b/tidb-cloud/security-concepts.md index 014072e81b160..3f5add0a5f93c 100644 --- a/tidb-cloud/security-concepts.md +++ b/tidb-cloud/security-concepts.md @@ -69,7 +69,7 @@ TiDB Cloudは、ユーザーベースおよびロールベースの権限設定 データベースの初期化中に、TiDB は自動的にデフォルト アカウント`'root'@'%'`を作成します。 -詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/stable/user-account-management#user-names-and-passwords)参照してください。 +詳細については、 [TiDBユーザーアカウント管理](https://docs.pingcap.com/tidb/stable/user-account-management#user-names-and-passwords)を参照してください。 ### SQLプロキシアカウント {#sql-proxy-accounts} @@ -207,7 +207,7 @@ TiDB Cloudは、堅牢なネットワークアクセス制御により、安全 - 仮想プライベートクラウド間でプライベート接続を確立し、安全でシームレスな通信を実現します。 -- 詳細については、 [VPCピアリング経由でTiDB Cloud Dedicatedに接続します](/tidb-cloud/set-up-vpc-peering-connections.md)参照してください。 +- 詳細については、 [VPCピアリング経由でTiDB Cloud Dedicatedに接続します](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 **推奨される使用方法：**重要なワークロードには、インターネットへの公開を避け、パフォーマンスを監視するために使用してください。 @@ -215,7 +215,7 @@ TiDB Cloudは、堅牢なネットワークアクセス制御により、安全 - ファイアウォールとして機能し、クラスタへのアクセスを信頼できるIPアドレスに制限します。 -- 詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 +- 詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 **ベストプラクティス：**セキュリティを維持するために、アクセスリストを定期的に監査し、更新してください。 @@ -253,7 +253,7 @@ TiDB Cloudは、高度な暗号化機能で静的データを保護し、セキ - HIPAAやGDPRなど、厳格なコンプライアンスが求められる業界では、CMEKを活用してください。 -詳細については、 [AWS 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)および[Azure 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)参照してください。 +詳細については、 [AWS 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)および[Azure 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)を参照してください。 @@ -267,7 +267,7 @@ TiDB Cloudは、高度な暗号化機能で静的データを保護し、セキ - セキュリティ要件や運用要件に応じて、顧客管理型暗号化キー（CMEK）とサービス管理型暗号化キーのどちらかを選択できます。 -詳細については、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)参照してください。 +詳細については、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)を参照してください。 diff --git a/tidb-cloud/security-overview.md b/tidb-cloud/security-overview.md index 2600e54180e30..973b43b84abaa 100644 --- a/tidb-cloud/security-overview.md +++ b/tidb-cloud/security-overview.md @@ -27,7 +27,7 @@ TLSを使用してすべての通信を暗号化することで、転送中の 堅牢な鍵管理メカニズムと組み合わせることで、暗号化鍵のライフサイクルと使用状況を制御でき、データセキュリティとコンプライアンスをさらに強化できます。 -詳細については、 [AWS 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)および[Azure 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)参照してください。 +詳細については、 [AWS 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)および[Azure 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md)を参照してください。 @@ -35,7 +35,7 @@ TLSを使用してすべての通信を暗号化することで、転送中の AWS 上でホストされているTiDB Cloud Premium インスタンスでは、デュアルレイヤーデータ暗号化を有効にすることで、デフォルトのストレージレイヤー暗号化に加えてデータベースレイヤー暗号化を追加できます。デュアルレイヤーデータ暗号化を有効にすると、 TiDB Cloud はTiKV に保存されたデータ、変更フィードデータ、およびバックアップデータを暗号化し、顧客管理暗号化キー (CMEK) またはサービス管理暗号化キーのいずれかを選択できます。 -詳細については、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)参照してください。 +詳細については、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)を参照してください。 diff --git a/tidb-cloud/select-cluster-tier.md b/tidb-cloud/select-cluster-tier.md index 91c3615c7d6ba..208a1a64a23ac 100644 --- a/tidb-cloud/select-cluster-tier.md +++ b/tidb-cloud/select-cluster-tier.md @@ -45,7 +45,7 @@ TiDB Cloudでは、組織ごとにデフォルトで最大5つのTiDB Cloud Star TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud Starter TiDB Cloud Starterインスタンスの行ベースのストレージが5 GiB を超えると、インスタンスは自動的に新しい接続試行を制限します。 -さまざまなリソース（読み取り、書き込み、SQL CPU、ネットワーク出力など）のRU消費量、価格の詳細、およびスロットリング情報の詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +さまざまなリソース（読み取り、書き込み、SQL CPU、ネットワーク出力など）のRU消費量、価格の詳細、およびスロットリング情報の詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 ### インスタンス容量計画 {#instance-capacity-plan} diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index 653f6d65483a5..a0c9d376824db 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -58,7 +58,7 @@ Amazon S3 にデータをエクスポートするには、次の情報を提供 - [アクセスキー](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)参照してください。 +詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 ### Googleクラウドストレージ {#google-cloud-storage} @@ -67,7 +67,7 @@ Google Cloud Storage にデータをエクスポートするには、次の情 - URI: `gs:////` - アクセス認証情報: バケットの**Base64エンコードされた**[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys) 。サービスアカウントキーに`storage.objects.create`権限があることを確認してください。 -詳細については[GCS アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)参照してください。 +詳細については[GCS アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 ### Azure BLOB ストレージ {#azure-blob-storage} @@ -76,7 +76,7 @@ Azure Blob Storage にデータをエクスポートするには、次の情報 - URI: `azure://.blob.core.windows.net///`または`https://.blob.core.windows.net///` - アクセス資格情報: Azure Blob Storage コンテナーの[共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview) 。SAS トークンに、 `Container`と`Object`リソースに対する`Read`と`Write`権限があることを確認してください。 -詳細については[Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 +詳細については[Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 ### アリババクラウドOSS {#alibaba-cloud-oss} @@ -85,7 +85,7 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 - URI: `oss:////` - アクセス資格情報：Alibaba Cloudアカウントの[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)ペアに`oss:PutObject`と`oss:GetBucketInfo`権限があることを確認してください。 -詳細については[Alibaba Cloud Object Storage Service (OSS) アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 +詳細については[Alibaba Cloud Object Storage Service (OSS) アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 ## エクスポートオプション {#export-options} @@ -225,7 +225,7 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 ticloud serverless export download -c -e ``` - ダウンロード コマンドの詳細については、 [ticloud サーバーレスエクスポートのダウンロード](/tidb-cloud/ticloud-serverless-export-download.md)参照してください。 + ダウンロード コマンドの詳細については、 [ticloud サーバーレスエクスポートのダウンロード](/tidb-cloud/ticloud-serverless-export-download.md)を参照してください。
@@ -251,7 +251,7 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 - **圧縮**: **Gzip** 、 **Snappy** 、 **Zstd** 、または**None**を選択します。 - **フォルダー URI** : `s3:////`形式で Amazon S3 の URI を入力します。 - **バケット アクセス**: 次のアクセス資格情報のいずれかを選択し、資格情報を入力します。 - - **AWS ロール ARN** : バケットへのアクセス権を持つロール ARN を入力します。AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **AWS ロール ARN** : バケットへのアクセス権を持つロール ARN を入力します。AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - **AWS アクセスキー**: バケットにアクセスする権限を持つアクセスキー ID とアクセスキーシークレットを入力します。 4. **［エクスポート］**をクリックします。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index 74ba0a2979414..f711bffbe1c8d 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -78,7 +78,7 @@ TiDB Cloud Starter での列指向ストレージの使用は、 TiFlashでの テーブルにTiFlashレプリカが設定されると、TiDBは行ベースストレージからそのテーブルの列指向ストレージにデータを自動的に複製します。これにより、データの一貫性が確保され、分析クエリのパフォーマンスが最適化されます。 -TiFlashレプリカの設定方法の詳細については、 [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md)参照してください。 +TiFlashレプリカの設定方法の詳細については、 [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md)を参照してください。 ### 数分間アイドル状態が続いた後に接続が切断されるのはなぜですか? {#why-is-my-connection-disconnected-after-being-idle-for-several-minutes} @@ -86,7 +86,7 @@ TiFlashレプリカの設定方法の詳細については、 [TiFlashレプリ ### 「接続制限を超えました」というエラーが表示されるのはなぜですか? {#why-did-i-receive-a-connection-limit-exceeded-error} -このエラーは、クラスターが最大同時接続数を超えた場合に発生します。詳細については、 [接続制限](/tidb-cloud/serverless-limitations.md#connection)参照してください。 +このエラーは、クラスターが最大同時接続数を超えた場合に発生します。詳細については、 [接続制限](/tidb-cloud/serverless-limitations.md#connection)を参照してください。 ## 請求と計測に関するよくある質問 {#billing-and-metering-faqs} @@ -104,7 +104,7 @@ TiDB Cloud Starterは従量課金モデルを採用しており、ストレー TiDB Cloud Starter クラスターに月間使用制限が設定されている場合、無料割り当て量を超えた使用量には課金されます。無料クラスターの場合、無料割り当て量に達すると、月間使用制限を設定するか、新しい月の開始時に使用量がリセットされるまで、このクラスターの読み取りおよび書き込み操作は制限されます。 -詳細については[TiDB Cloud Starter の使用割り当て](/tidb-cloud/select-cluster-tier.md#usage-quota)参照してください。 +詳細については[TiDB Cloud Starter の使用割り当て](/tidb-cloud/select-cluster-tier.md#usage-quota)を参照してください。 ### 無料プランの制限は何ですか? {#what-are-the-limitations-of-the-free-plan} @@ -118,7 +118,7 @@ TiDB Cloud Starter クラスターに月間使用制限が設定されている ### 消費される RU の数を最小限に抑えるためにワークロードを最適化するにはどうすればよいでしょうか? {#how-can-i-optimize-my-workload-to-minimize-the-number-of-rus-consumed} -[SQLパフォーマンスの最適化](/develop/dev-guide-optimize-sql-overview.md)のガイドラインに従って、クエリが最適なパフォーマンスを得るために注意深く最適化されていることを確認してください。 RU を最も多く消費する SQL ステートメントを特定するには、クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **[SQL ステートメント]**タブを確認します。ここで、SQL 実行を観察し、**合計 RU**または**平均 RU**でソートされた上位のステートメントを表示できます。 詳細については、 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 また、出力トラフィックの量を最小限に抑えることも、RU の消費量を削減するために重要です。 これを実現するには、クエリで必要な列と行のみを返すことをお勧めします。これにより、ネットワークの出力トラフィックが削減されます。 これは、返される列と行を慎重に選択してフィルター処理することで実現でき、それによってネットワーク使用率が最適化されます。 +[SQLパフォーマンスの最適化](/develop/dev-guide-optimize-sql-overview.md)のガイドラインに従って、クエリが最適なパフォーマンスを得るために注意深く最適化されていることを確認してください。 RU を最も多く消費する SQL ステートメントを特定するには、クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **[SQL ステートメント]**タブを確認します。ここで、SQL 実行を観察し、**合計 RU**または**平均 RU**でソートされた上位のステートメントを表示できます。 詳細については、 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)を参照してください。 また、出力トラフィックの量を最小限に抑えることも、RU の消費量を削減するために重要です。 これを実現するには、クエリで必要な列と行のみを返すことをお勧めします。これにより、ネットワークの出力トラフィックが削減されます。 これは、返される列と行を慎重に選択してフィルター処理することで実現でき、それによってネットワーク使用率が最適化されます。 ### TiDB Cloud Starter のストレージはどのように計測されますか? {#how-storage-is-metered-for-tidb-cloud-starter} @@ -138,7 +138,7 @@ TiDB の必須バックグラウンドジョブが原因で、RU 使用量が急 ### クラスターの無料割り当てを使い果たしたり、使用制限を超えたりするとどうなりますか? {#what-happens-when-my-cluster-exhausts-its-free-quota-or-exceeds-its-spending-limit} -クラスターが無料割り当てまたは使用制限に達すると、割り当てが増加するか、新しい月の開始時に使用量がリセットされるまで、クラスターは新しい接続試行を直ちに拒否します。割り当てに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。詳細については、 [TiDB Cloud Starter の制限とクォータ](/tidb-cloud/serverless-limitations.md#usage-quota)参照してください。 +クラスターが無料割り当てまたは使用制限に達すると、割り当てが増加するか、新しい月の開始時に使用量がリセットされるまで、クラスターは新しい接続試行を直ちに拒否します。割り当てに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。詳細については、 [TiDB Cloud Starter の制限とクォータ](/tidb-cloud/serverless-limitations.md#usage-quota)を参照してください。 ### データのインポート中に RU 使用量が急増するのはなぜですか? {#why-do-i-observe-spikes-in-ru-usage-while-importing-data} @@ -148,7 +148,7 @@ TiDB Cloud Starter クラスターのデータ インポート プロセス中 TiDB Cloud Starter の列指向ストレージの料金は、行指向ストレージの料金とほぼ同じです。列指向ストレージを使用すると、データ（インデックスなし）を保存するための追加のレプリカが作成されます。行指向ストレージから列指向ストレージへのデータのレプリケーションには追加料金は発生しません。 -詳細な価格情報については、 [TiDB Cloud Starterの価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +詳細な価格情報については、 [TiDB Cloud Starterの価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 ### 列指向ストレージを使用するとコストは高くなりますか? {#is-using-columnar-storage-more-expensive} diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index d05b67a4922aa..6c80b32cad5b8 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -10,7 +10,7 @@ TiDB Cloudは、デフォルトで高い可用性とデータの耐久性を維 > **注記：** > > - このドキュメントは、 TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premiumにのみ適用されます。 -> - TiDB Cloud Dedicatedの高可用性については、 [TiDB Cloud Dedicatedにおける高可用性](/tidb-cloud/high-availability-with-multi-az.md)参照してください。 +> - TiDB Cloud Dedicatedの高可用性については、 [TiDB Cloud Dedicatedにおける高可用性](/tidb-cloud/high-availability-with-multi-az.md)を参照してください。 ## 概要 {#overview} diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index f0b9ca275c6e4..4f0f92288d4ef 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidbcloud/serverless-tier-limitations'] TiDB Cloud StarterおよびEssentialは、TiDBがサポートするほぼすべてのワークロードで動作しますが、TiDB Self-ManagedまたはTiDB Cloud Dedicatedクラスタと比較して機能に若干の違いがあります。このドキュメントでは、TiDB Cloud StarterおよびTiDB Cloud Essentialの制限事項について説明します。 -TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを継続的に埋めています。ギャップを埋める機能や性能が必要な場合は、機能リクエストに[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)または[お問い合わせ](https://www.pingcap.com/contact-us/?from=en)使用してください。 +TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを継続的に埋めています。ギャップを埋める機能や性能が必要な場合は、機能リクエストに[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)または[お問い合わせ](https://www.pingcap.com/contact-us/?from=en)を使用してください。 ## 制限事項 {#limitations} @@ -22,7 +22,7 @@ TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを - [パブリックエンドポイント](/tidb-cloud/connect-via-standard-connection-serverless.md)と[プライベートエンドポイント](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)のみ使用できます。5 [VPC ピアリング](/tidb-cloud/set-up-vpc-peering-connections.md) TiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するためには使用できません。 - プライベートエンドポイントのサポート[ファイアウォールルール](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md) 。 -- データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)参照してください。 +- データベースクライアント接続は、30分以上開いたままになっていると、予期せず終了する可能性があります。これは、TiDBサーバーのシャットダウン、再起動、またはメンテナンス時に発生する可能性があり、アプリケーションの中断につながる可能性があります。この問題を回避するには、最大接続有効期間を設定してください。最初は5分から始め、テールレイテンシーに影響がある場合は徐々に増やすことを推奨します。詳細については、 [接続プールの推奨設定](/develop/dev-guide-connection-parameters.md)を参照してください。 - TiDB Cloud Starterクラスターでは、最大400の同時接続が可能です。1 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)設定すると、この制限は5,000に増加します。 > **注記：** @@ -76,7 +76,7 @@ TiDB Cloudでは、組織ごとに最大5つのクラスター（デフォルト クラスターが使用量のクォータに達すると、新しい接続試行はすべて拒否されます。これは、新しい月の開始時に使用量がリセットされるか、 [割り当てを増やす](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit)なるまで継続されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。 -さまざまなリソース (読み取り、書き込み、SQL CPU、ネットワーク送信など) の RU 消費量、価格の詳細、スロットル情報の詳細については、 [TiDB Cloud Starter の価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +さまざまなリソース (読み取り、書き込み、SQL CPU、ネットワーク送信など) の RU 消費量、価格の詳細、スロットル情報の詳細については、 [TiDB Cloud Starter の価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 追加のクォータを持つTiDB Cloud Starterクラスターを作成する場合は、クラスター作成ページで月間使用制限を設定できます。詳細については、 [TiDB Cloud Starter クラスターを作成する](/tidb-cloud/create-tidb-cluster-serverless.md)ご覧ください。 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 de8b93a5ac36c..795a8f4e84a8c 100644 --- a/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md @@ -90,4 +90,4 @@ ApsaraDB RDS for MySQL と同じリージョンにエンドポイント サー 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)参照してください。 +詳細については[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 6a974fda65a7b..1b87f5ddbef5b 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -28,7 +28,7 @@ AWS アカウント ID とアベイラビリティーゾーンを表示するに - MSK クラスターには**認証**: [SASL/SCRAM認証](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html)が必要です。 - **ブローカータイプ**: ブローカー`t4.small`タイプは使用しないでください。プライベートリンクをサポートしていません。 -詳細な要件については、 [単一リージョンでの Amazon MSK マルチ VPC プライベート接続](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-requirements)参照してください。 +詳細な要件については、 [単一リージョンでの Amazon MSK マルチ VPC プライベート接続](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-requirements)を参照してください。 Amazon MSK プロビジョニングされたクラスターがない場合は、 TiDB Cloud Essentialクラスターと同じリージョンおよび同じアベイラビリティーゾーンに[1つ作成する](https://docs.aws.amazon.com/msk/latest/developerguide/create-cluster.html) 、作成されたクラスターに[SASL/SCRAM認証を設定する](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html) 。 @@ -154,4 +154,4 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 MSK クラスターの`ARN`使用して、 TiDB Cloudにプライベート リンク接続を作成します。 -詳細については[Amazon MSK プロビジョニングされたプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-amazon-msk-provisioned-private-link-connection)参照してください。 +詳細については[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 fa03f03bbb491..6730ffe237384 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md @@ -46,7 +46,7 @@ Confluent Cloud ネットワークの一意の名前を取得するには、次 ## ステップ2. ネットワークにPrivateLinkアクセスを追加する {#step-2-add-a-privatelink-access-to-the-network} -[ステップ1](#step-1-set-up-a-confluent-cloud-network)で特定または設定したネットワークにPrivateLinkアクセスを追加します。詳細については、 [Confluent Cloud に PrivateLink アクセスを追加する](https://docs.confluent.io/cloud/current/networking/private-links/aws-privatelink.html#add-a-privatelink-access-in-ccloud)参照してください。 +[ステップ1](#step-1-set-up-a-confluent-cloud-network)で特定または設定したネットワークにPrivateLinkアクセスを追加します。詳細については、 [Confluent Cloud に PrivateLink アクセスを追加する](https://docs.confluent.io/cloud/current/networking/private-links/aws-privatelink.html#add-a-privatelink-access-in-ccloud)を参照してください。 プロセス中に、次の操作を行う必要があります。 @@ -55,7 +55,7 @@ Confluent Cloud ネットワークの一意の名前を取得するには、次 ## ステップ3. ネットワークの下にConfluent Cloud専用クラスタを作成する {#step-3-create-a-confluent-cloud-dedicated-cluster-under-the-network} -[ステップ1](#step-1-set-up-a-confluent-cloud-network)で設定した既存のネットワーク下に Confluent Cloud Dedicated クラスターを作成します。詳細については、 [Confluent Cloud で専用クラスターを作成する](https://docs.confluent.io/cloud/current/clusters/create-cluster.html#create-ak-clusters)参照してください。 +[ステップ1](#step-1-set-up-a-confluent-cloud-network)で設定した既存のネットワーク下に Confluent Cloud Dedicated クラスターを作成します。詳細については、 [Confluent Cloud で専用クラスターを作成する](https://docs.confluent.io/cloud/current/clusters/create-cluster.html#create-ak-clusters)を参照してください。 ## ステップ4. TiDB Cloudでプライベートリンク接続を作成する {#step-4-create-a-private-link-connection-in-tidb-cloud} @@ -63,7 +63,7 @@ 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)参照してください。 + 詳細については[AWS エンドポイントサービスプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)を参照してください。 > **注記：** > @@ -71,4 +71,4 @@ TiDB Cloudでプライベート リンク接続を作成するには、次の手 2. TiDB Cloudのデータフロー サービスが Confluent クラスターにアクセスできるように、Confluent Cloud サービス ドメインをプライベート リンク接続に接続します。 - 詳細については[プライベートリンク接続にドメインを添付する](/tidb-cloud/serverless-private-link-connection.md#attach-domains-to-a-private-link-connection)参照してください。 + 詳細については[プライベートリンク接続にドメインを添付する](/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 e2d77e37de9d1..780b4f3e2fec2 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md @@ -65,7 +65,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー - **VPC** ：RDSが配置されているVPCを選択してください。 - **ターゲットの登録**：Amazon RDSインスタンスのIPアドレスを登録します。RDSエンドポイントにpingを実行すると、IPアドレスを取得できます。 - 詳細については、 [ネットワークロードバランサーのターゲットグループを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html)参照してください。 + 詳細については、 [ネットワークロードバランサーのターゲットグループを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html)を参照してください。 2. [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers)に移動して、ネットワーク ロード バランサーを作成します。次の情報を入力してください。 @@ -90,7 +90,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー - **プロトコルとポート**：プロトコルを`TCP`に、ポートをデータベースのポート番号に設定します。例えば、MySQLの場合は`3306`です。 - **対象グループ**：前の手順で作成した対象グループを選択してください。 -詳細については、 [ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)参照してください。 +詳細については、 [ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 ### ステップ2.2. AWSエンドポイントサービスの設定 {#step-2-2-set-up-the-aws-endpoint-service} @@ -112,4 +112,4 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー TiDB CloudコンソールまたはTiDB Cloud CLIを使用して、プライベートリンク接続を作成できます。 -詳細については、 [AWS Endpoint Service のプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)参照してください。 +詳細については、 [AWS Endpoint Service のプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)を参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index 179d1bcd755b3..6b2460557fece 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 @@ -652,7 +652,7 @@ 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)参照してください。 + 詳細については[Alibaba Cloud Endpoint Service のプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-alibaba-cloud-endpoint-service-private-link-connection)を参照してください。 2. 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 b0eb764c9d827..75137f290a675 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 @@ -730,7 +730,7 @@ 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)参照してください。 + 詳細については[AWS エンドポイントサービスプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)を参照してください。 2. TiDB Cloudのデータフロー サービスが Kafka クラスターにアクセスできるように、プライベート リンク接続にドメインをアタッチします。 diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index b74a70e824d70..2e0cd417de298 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -93,7 +93,7 @@ TiDB Cloud CLI を使用してプライベート リンク接続を作成する TiDB Cloudコンソールを使用して、Amazon MSK プロビジョニングされたプライベートリンク接続を作成できます。 -Amazon MSK プロビジョニングプライベートリンク接続を作成する前に、Amazon MSK プロビジョニングクラスターでマルチVPC接続が有効になっていることを確認してください。詳細については、 [プライベートリンク接続経由​​でプロビジョニングされた Amazon MSK に接続する](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)参照してください。 +Amazon MSK プロビジョニングプライベートリンク接続を作成する前に、Amazon MSK プロビジョニングクラスターでマルチVPC接続が有効になっていることを確認してください。詳細については、 [プライベートリンク接続経由​​でプロビジョニングされた Amazon MSK に接続する](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)を参照してください。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 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 c69f8d7496eb5..24ae598d4bc29 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-azure.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-azure.md @@ -87,7 +87,7 @@ Azure Private Link のアーキテクチャは次のとおりです: [^1] 3. **プライベートエンドポイントの**ページで、 **[+ 作成]**をクリックします。 4. **「基本」**タブで、プロジェクトとインスタンスの情報を入力し、 **「次へ: リソース」**をクリックします。 5. **「リソース」**タブで、**接続方法**として**「リソース ID またはエイリアスを使用して Azure リソースに接続する」を**選択し、コピーしたTiDB Cloudリソース ID を**「リソース ID またはエイリアス」**フィールドに貼り付けます。 -6. 引き続き**「次へ」**をクリックして残りの構成タブに進み、必要な設定を完了します。次に、 **[作成]**をクリックしてプライベート エンドポイントを作成してデプロイします。 Azure のデプロイが完了するまでに数秒かかる場合があります。詳細については、Azure ドキュメントの[プライベートエンドポイントを作成する](https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal?tabs=dynamic-ip#create-a-private-endpoint)参照してください。 +6. 引き続き**「次へ」**をクリックして残りの構成タブに進み、必要な設定を完了します。次に、 **[作成]**をクリックしてプライベート エンドポイントを作成してデプロイします。 Azure のデプロイが完了するまでに数秒かかる場合があります。詳細については、Azure ドキュメントの[プライベートエンドポイントを作成する](https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal?tabs=dynamic-ip#create-a-private-endpoint)を参照してください。 7. プライベートエンドポイントの作成とデプロイが完了したら、 **「リソースへ移動」**をクリックし、以下の手順を実行してください。 - 左側のナビゲーションペインで**「設定」** ＞ **「プロパティ」**をクリックし、後で使用するために**リソースID**をコピーしてください。 diff --git a/tidb-cloud/set-up-private-endpoint-connections-serverless.md b/tidb-cloud/set-up-private-endpoint-connections-serverless.md index 298e6534eada7..24cc4f6f1f880 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-serverless.md +++ b/tidb-cloud/set-up-private-endpoint-connections-serverless.md @@ -11,7 +11,7 @@ summary: プライベートエンドポイントを介してTiDB Cloud Starter > > - 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)参照してください。 +> - 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サービスへの接続を作成できます。 @@ -109,7 +109,7 @@ aws ec2 create-vpc-endpoint --vpc-id ${your_vpc_id} --region ${region_id} --serv > **ヒント：** > -> コマンドを実行する前に、AWS CLI をインストールして設定する必要があります。詳細については、 [AWS CLI設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)参照してください。 +> コマンドを実行する前に、AWS CLI をインストールして設定する必要があります。詳細については、 [AWS CLI設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)を参照してください。 diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index adf1864fd6757..c755815328012 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -9,8 +9,8 @@ summary: AWS を使用してプライベートエンドポイント経由でTiDB > **ヒント：** > -> - 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)参照してください。 +> - 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)ご覧ください。 TiDB Cloudは、 AWS VPCでホストされているTiDB Cloudサービスへの、 [AWS プライベートリンク](https://aws.amazon.com/privatelink)経由の高度に安全な一方向アクセスをサポートします。まるでお客様のVPC内にあるかのように機能します。VPC内にプライベートエンドポイントが公開されており、権限があればエンドポイント経由でTiDB Cloudサービスへの接続を作成できます。 @@ -90,7 +90,7 @@ AWS CLI を使用して VPC インターフェイスエンドポイントを作 > **ヒント：** > -> - コマンドを実行する前に、AWS CLI をインストールして設定しておく必要があります。詳細は[AWS CLI 設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)参照してください。 +> - コマンドを実行する前に、AWS CLI をインストールして設定しておく必要があります。詳細は[AWS CLI 設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)を参照してください。 > > - サービスが3つを超えるアベイラビリティゾーン（AZ）にまたがっている場合、VPCエンドポイントサービスがサブネットのAZをサポートしていないことを示すエラーメッセージが表示されます。この問題は、選択したリージョンに、TiDBクラスターが配置されているAZに加えて、追加のAZが存在する場合に発生します。この場合、 [PingCAP テクニカルサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)お問い合わせください。 diff --git a/tidb-cloud/set-up-sink-private-endpoint.md b/tidb-cloud/set-up-sink-private-endpoint.md index d3bcff385f4f8..1a5c69c7db824 100644 --- a/tidb-cloud/set-up-sink-private-endpoint.md +++ b/tidb-cloud/set-up-sink-private-endpoint.md @@ -24,7 +24,7 @@ summary: 変更フィードのプライベート エンドポイントを設定 - `Project Owner` - `Project Data Access Read-Write` -TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)参照してください。 +TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)を参照してください。 ### ネットワーク {#network} @@ -126,7 +126,7 @@ changefeed ダウンストリーム サービスが Azure でホストされて 2. **「Changefeed のプライベート エンドポイントの作成」**ダイアログで、プライベート エンドポイントの名前を入力します。 -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)参照してください。 +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)で収集した**プライベート リンク サービスのエイリアス**を入力します。 diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index 89d2db28956e1..37b94152f0394 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -138,7 +138,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング sudo ./aws/install ``` -2. アカウント情報に応じてAWS CLIを設定してください。AWS CLIに必要な情報を取得するには、 [AWS CLI 設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)参照してください。 +2. アカウント情報に応じてAWS CLIを設定してください。AWS CLIに必要な情報を取得するには、 [AWS CLI 設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)を参照してください。 ```bash aws configure diff --git a/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md index 1ee6cbd51e14d..c2fb206b75217 100644 --- a/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md @@ -45,7 +45,7 @@ aliases: ['/ja/tidbcloud/setup-self-hosted-kafka-private-link-service'] 1. **宛先**で、 **Kafka**を選択します。 2. **[接続方法]**で**[プライベート リンク]**を選択します。 4. **続行する前に、** TiDB Cloud AWS アカウントの情報をリマインダーに書き留めておいてください。この情報は、TiDB Cloud がKafka Private Link サービスのエンドポイントを作成することを承認する際に使用されます。 - 5. **「AZの数」**を選択します。この例では、 **「3つのAZ」**を選択します。KafkaクラスターをデプロイするAZのIDをメモしておいてください。AZ名とAZ IDの関係を知りたい場合は、 [AWS リソースのアベイラビリティゾーン ID](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)参照してください。 + 5. **「AZの数」**を選択します。この例では、 **「3つのAZ」**を選択します。KafkaクラスターをデプロイするAZのIDをメモしておいてください。AZ名とAZ IDの関係を知りたい場合は、 [AWS リソースのアベイラビリティゾーン ID](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)を参照してください。 6. Kafka プライベート リンク サービスに固有の**Kafka アドバタイズ リスナー パターン**を入力します。 1. 一意のランダム文字列を入力してください。数字または小文字のみ使用できます。この文字列は、後ほど**Kafkaアドバタイズリスナーパターン**を生成する際に使用します。 2. **「使用状況を確認して生成」をクリックすると、**ランダム文字列が一意であるかどうかが確認され、Kafka ブローカーの外部アドバタイズ リスナーを組み立てるために使用される**Kafka アドバタイズ リスナー パターンが**生成されます。 @@ -772,7 +772,7 @@ b3.usw2-az3.abc.us-west-2.aws.3199015.tidbcloud.com:9095 (id: 3 rack: null) -> E ## ステップ3. TiDB Cloudから接続する {#step-3-connect-from-tidb-cloud} -1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻って、クラスタ実例**プライベートリンク**を使用してKafkaクラスターに接続します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻って、クラスタ実例**プライベートリンク**を使用してKafkaクラスターに接続します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベート リンク」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 diff --git a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md index 6aaad95a01548..74e9d46e8ce29 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 @@ -521,7 +521,7 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. ## ステップ3. TiDB Cloudから接続する {#step-3-connect-from-tidb-cloud} -1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**プライベートリンク**経由で Kafka クラスターに接続するための変更フィードを作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**プライベートリンク**経由で Kafka クラスターに接続するための変更フィードを作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベート リンク」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 diff --git a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md index 34e413c0f2102..0bece7fa2bfe8 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -18,7 +18,7 @@ Google Cloud でセルフホスト型 Kafka に Private Service Connect を設 - Private Service Connect（PSC）ポートマッピングメカニズムを使用します。この方法では、静的なポートブローカーマッピング設定が必要です。EXTERNALリスナーとアドバタイズリスナーのグループを追加するには、既存のKafkaクラスターを再構成する必要があります。1 [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 クラスターを再設定する必要はありません。3 [Kafka-proxy によるセルフホスト型 Kafka プライベート サービス接続のセットアップ](#set-up-self-hosted-kafka-private-service-connect-by-kafka-proxy)参照してください。 +- [Kafkaプロキシ](https://github.com/grepplabs/kafka-proxy)を使用してください。この方法では、Kafka クライアントと Kafka ブローカー間のプロキシとして、追加の実行プロセスが導入されます。プロキシはポートとブローカーのマッピングを動的に設定し、リクエストを転送します。既存の Kafka クラスターを再設定する必要はありません。3 [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 サービスの使用を推奨します。 @@ -531,7 +531,7 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. ### ステップ3. TiDB Cloudから接続する {#step-3-connect-from-tidb-cloud} -1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**Private Service Connect**経由で Kafka クラスターに接続するための changefeed を作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**Private Service Connect**経由で Kafka クラスターに接続するための changefeed を作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベート サービス接続」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 @@ -671,7 +671,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが ### ステップ3. TiDB Cloudから接続する {#step-3-connect-from-tidb-cloud} -1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**Private Service Connect**経由で Kafka クラスターに接続するための changefeed を作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻り、クラスターが**Private Service Connect**経由で Kafka クラスターに接続するための changefeed を作成します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)を参照してください。 2. **「ChangeFeed ターゲットの構成」** > **「接続方法」** > **「プライベート サービス接続」**に進んだ後、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 diff --git a/tidb-cloud/size-your-cluster.md b/tidb-cloud/size-your-cluster.md index 7d085ff3ec2ea..4d07c51625a77 100644 --- a/tidb-cloud/size-your-cluster.md +++ b/tidb-cloud/size-your-cluster.md @@ -17,7 +17,7 @@ TiDBはコンピューティング専用であり、データの保存は行い TiDB のノード数、vCPU、RAM を構成できます。 -さまざまなクラスター規模のパフォーマンス テスト結果については、 [TiDB Cloudパフォーマンス リファレンス](/tidb-cloud/tidb-cloud-performance-reference.md)参照してください。 +さまざまなクラスター規模のパフォーマンス テスト結果については、 [TiDB Cloudパフォーマンス リファレンス](/tidb-cloud/tidb-cloud-performance-reference.md)を参照してください。 ### TiDB vCPU と RAM {#tidb-vcpu-and-ram} @@ -85,7 +85,7 @@ TiKVはデータの保存を担当し、水平方向に拡張可能です。 TiKV のノード数、vCPU と RAM、ストレージを構成できます。 -さまざまなクラスター規模のパフォーマンス テスト結果については、 [TiDB Cloudパフォーマンス リファレンス](/tidb-cloud/tidb-cloud-performance-reference.md)参照してください。 +さまざまなクラスター規模のパフォーマンス テスト結果については、 [TiDB Cloudパフォーマンス リファレンス](/tidb-cloud/tidb-cloud-performance-reference.md)を参照してください。 ### TiKV vCPU と RAM {#tikv-vcpu-and-ram} @@ -116,7 +116,7 @@ TiDB Cloudは、耐久性と高可用性を実現するために、選択した > **注記：** > -> TiDB クラスターをスケールすると、3 つのアベイラビリティゾーンのノードが同時に増減します。ニーズに応じて TiDB クラスターをスケールインまたはスケールアウトする方法については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)参照してください。 +> TiDB クラスターをスケールすると、3 つのアベイラビリティゾーンのノードが同時に増減します。ニーズに応じて TiDB クラスターをスケールインまたはスケールアウトする方法については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)を参照してください。 TiKVは主にデータストレージに使用されますが、TiKVノードのパフォーマンスはワークロードによって異なります。そのため、TiKVノードの数を計画する際には、 [**データ量**](#estimate-tikv-node-count-according-to-data-volume)と[期待されるパフォーマンス](#estimate-tikv-node-count-according-to-expected-performance)両方に基づいて見積もり、そのうち大きい方の見積もりを推奨ノード数とする必要があります。 diff --git a/tidb-cloud/sql-concepts.md b/tidb-cloud/sql-concepts.md index 7a84dbb516022..5560ed5585815 100644 --- a/tidb-cloud/sql-concepts.md +++ b/tidb-cloud/sql-concepts.md @@ -25,7 +25,7 @@ SQLは、その関数に応じて以下の4種類に分類されます。 - DCL（データ制御言語）：アクセス権限とセキュリティレベルを定義するために使用されます。 -TiDB の SQL ステートメントの概要については、 [SQLステートメントの概要](/sql-statements/sql-statement-overview.md)参照してください。 +TiDB の SQL ステートメントの概要については、 [SQLステートメントの概要](/sql-statements/sql-statement-overview.md)を参照してください。 ## SQLモード {#sql-mode} @@ -91,4 +91,4 @@ TiDB では、ユーザー定義変数を設定および読み取ることがで TiDBでは、メタデータロックは、オンラインスキーマ変更中にテーブルメタデータの変更を管理するために導入されたメカニズムです。トランザクションが開始されると、現在のメタデータのスナップショットにロックされます。トランザクション中にメタデータが変更されると、TiDBは「情報スキーマが変更されました」というエラーをスローし、トランザクションのコミットを阻止します。メタデータロックは、データ操作言語（DML）とデータ定義言語（DDL）の操作を調整し、DMLの優先順位付けを行うことで、古いメタデータを持つ進行中のDMLトランザクションが新しいDDL変更を適用する前にコミットされるようにし、エラーを最小限に抑え、データの一貫性を維持します。 -詳細については、[メタデータロック](/metadata-lock.md)参照してください。 +詳細については、[メタデータロック](/metadata-lock.md)を参照してください。 diff --git a/tidb-cloud/sql-proxy-account.md b/tidb-cloud/sql-proxy-account.md index f10c2201b769f..8a5299a11fca3 100644 --- a/tidb-cloud/sql-proxy-account.md +++ b/tidb-cloud/sql-proxy-account.md @@ -64,7 +64,7 @@ SQLプロキシアカウントのユーザー名は、 TiDB Cloudのユーザー > **注記：** > -> 上記の表の`{user_name_prefix}`は、 TiDB Cloud Serverless クラスターを区別するためにTiDB Cloudによって生成される一意のプレフィックスです。詳細については、 TiDB Cloud Serverless クラスターの「 [ユーザー名のプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)参照してください。 +> 上記の表の`{user_name_prefix}`は、 TiDB Cloud Serverless クラスターを区別するためにTiDB Cloudによって生成される一意のプレフィックスです。詳細については、 TiDB Cloud Serverless クラスターの「 [ユーザー名のプレフィックス](/tidb-cloud/select-cluster-tier.md#user-name-prefix)を参照してください。 ## SQLプロキシアカウントのパスワード {#sql-proxy-account-password} diff --git a/tidb-cloud/terraform-get-tidbcloud-provider.md b/tidb-cloud/terraform-get-tidbcloud-provider.md index 368d333330daf..dc5e966ba5341 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} @@ -37,7 +37,7 @@ TiDB Cloud APIはHTTPダイジェスト認証を使用します。これによ 現在、 TiDB Cloud Terraform Provider は API キーの管理をサポートしていません。そのため、 [TiDB Cloudコンソール](https://tidbcloud.com/project/clusters)で API キーを作成する必要があります。 -詳細な手順については、 [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)を参照してください。 ## ステップ3. TiDB Cloud Terraform Providerをダウンロードする {#step-3-download-tidb-cloud-terraform-provider} diff --git a/tidb-cloud/terraform-migrate-cluster-resource.md b/tidb-cloud/terraform-migrate-cluster-resource.md index 8f5f46b70df72..3f02a6f8eb0f1 100644 --- a/tidb-cloud/terraform-migrate-cluster-resource.md +++ b/tidb-cloud/terraform-migrate-cluster-resource.md @@ -9,7 +9,7 @@ TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソ > **ヒント：** > -> このドキュメントの手順では、Terraform の構成生成機能を使用して、クラスターリソースの`.tf`構成を自動的に再作成することで、移行プロセスを簡素化します。詳細については、Terraform ドキュメントの[構成の生成](https://developer.hashicorp.com/terraform/language/import/generating-configuration)参照してください。 +> このドキュメントの手順では、Terraform の構成生成機能を使用して、クラスターリソースの`.tf`構成を自動的に再作成することで、移行プロセスを簡素化します。詳細については、Terraform ドキュメントの[構成の生成](https://developer.hashicorp.com/terraform/language/import/generating-configuration)を参照してください。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/terraform-tidbcloud-provider-overview.md b/tidb-cloud/terraform-tidbcloud-provider-overview.md index 4fdc5390847cc..4ed609ff2b8b6 100644 --- a/tidb-cloud/terraform-tidbcloud-provider-overview.md +++ b/tidb-cloud/terraform-tidbcloud-provider-overview.md @@ -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-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index 3c179c1474030..d79b93472d89a 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -29,7 +29,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを 利用可能なすべてのプロジェクトの情報を表示するには、次のように`tidbcloud_projects`データ ソースを使用します。 -1. [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md)実行すると作成される`main.tf`ファイルに、次のように`data`と`output`ブロックを追加します。 +1. [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md)を実行すると作成される`main.tf`ファイルに、次のように`data`と`output`ブロックを追加します。 terraform { required_providers { @@ -62,9 +62,9 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 - `output`ブロックはプログラミング言語の戻り値と同様に機能します。詳細は[Terraform ドキュメント](https://www.terraform.io/language/values/outputs)参照してください。 + `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`と入力してください。 @@ -264,7 +264,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを > **注記：** > -> 始める前に、 TiDB Cloudコンソールで CIDR が設定されていることを確認してください。詳細については、 [CIDRを設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)参照してください。 +> 始める前に、 TiDB Cloudコンソールで CIDR が設定されていることを確認してください。詳細については、 [CIDRを設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)を参照してください。 `tidbcloud_cluster`リソースを使用してクラスターを作成できます。 diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index 756c02618104e..522bbfff74fbf 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -58,9 +58,9 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 - `output`ブロックは、プログラミング言語の戻り値と同様に機能します。詳細については、 [Terraformドキュメント](https://www.terraform.io/language/values/outputs)参照してください。 + `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`と入力してください。 @@ -121,7 +121,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi > **注記：** > -> - 始める前に、 [TiDB Cloudコンソール](https://tidbcloud.com)で CIDR が設定されていることを確認してください。詳細については、 [CIDRを設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)参照してください。 +> - 始める前に、 [TiDB Cloudコンソール](https://tidbcloud.com)で CIDR が設定されていることを確認してください。詳細については、 [CIDRを設定する](/tidb-cloud/set-up-vpc-peering-connections.md#prerequisite-set-a-cidr-for-a-region)を参照してください。 > - CIDR を管理するには[`dedicated_network_container`リソースを作成する](/tidb-cloud/terraform-use-dedicated-network-container-resource.md)も使用できます。 次のように、 `tidbcloud_dedicated_cluster`リソースを使用してTiDB Cloud Dedicated クラスターを作成できます。 diff --git a/tidb-cloud/terraform-use-dedicated-network-container-resource.md b/tidb-cloud/terraform-use-dedicated-network-container-resource.md index 9168133332c00..07bb8ee4c016e 100644 --- a/tidb-cloud/terraform-use-dedicated-network-container-resource.md +++ b/tidb-cloud/terraform-use-dedicated-network-container-resource.md @@ -58,8 +58,8 @@ 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)参照してください。 + - 必要な引数の値を取得する方法がわからない場合は、 [リージョンの 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)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 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 751d23874e18b..3babc9251d4f6 100644 --- a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md +++ b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md @@ -55,8 +55,8 @@ 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)参照してください。 + - 必要な引数の値を取得する方法がわからない場合は、 [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)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 diff --git a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md index ab553deb6ceae..0574199e551bd 100644 --- a/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md +++ b/tidb-cloud/terraform-use-dedicated-vpc-peering-resource.md @@ -56,8 +56,8 @@ summary: tidbcloud_dedicated_vpc_peering` リソースを使用して、 TiDB Cl - `tidbcloud_dedicated_vpc_peering`リソースを使用するには、リソース タイプを`tidbcloud_dedicated_vpc_peering`に設定します。 - リソース名は必要に応じて定義できます。例： `example` 。 - - 必要な引数の値を取得する方法がわからない場合は、 [VPC ピアリング経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-vpc-peering-connections.md)参照してください。 - - TiDB Cloud Dedicated VPC ピアリング仕様情報を取得するには、 [tidbcloud_dedicated_vpc_peering (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_vpc_peering)参照してください。 + - 必要な引数の値を取得する方法がわからない場合は、 [VPC ピアリング経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-vpc-peering-connections.md)を参照してください。 + - TiDB Cloud Dedicated VPC ピアリング仕様情報を取得するには、 [tidbcloud_dedicated_vpc_peering (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_vpc_peering)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`使用は推奨されません。 diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index 3788b4b59a276..47e11e2509250 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -179,7 +179,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク > **注記：** > -> TiDB Cloud がAmazon S3 バケット内のファイルにアクセスできるようにするには、まず[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)実行する必要があります。 +> TiDB Cloud がAmazon S3 バケット内のファイルにアクセスできるようにするには、まず[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を実行する必要があります。 1. ディレクトリ`import`を作成し、その中にディレクトリ`main.tf`を作成します。例: @@ -280,4 +280,4 @@ Terraform の場合、インポート タスクを削除すると、対応する ## 構成 {#configurations} -`tidbcloud_import`リソースで使用可能なすべての構成を取得するには、 [構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import)参照してください。 +`tidbcloud_import`リソースで使用可能なすべての構成を取得するには、 [構成ドキュメント](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import)を参照してください。 diff --git a/tidb-cloud/terraform-use-serverless-branch-resource.md b/tidb-cloud/terraform-use-serverless-branch-resource.md index 06b4371bc1743..1134d5340a8b0 100644 --- a/tidb-cloud/terraform-use-serverless-branch-resource.md +++ b/tidb-cloud/terraform-use-serverless-branch-resource.md @@ -56,7 +56,7 @@ summary: サーバーレス ブランチ リソースを使用して、 TiDB Clo - サーバーレス ブランチ リソースを使用するには、リソース タイプを`tidbcloud_serverless_branch`に設定します。 - リソース名は必要に応じて定義できます。例： `example` 。 - リソースの詳細については、サーバーレス ブランチの仕様情報に従って設定できます。 - - サーバーレス ブランチの仕様情報を取得するには、 [tidbcloud_serverless_branch (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/serverless_branch)参照してください。 + - サーバーレス ブランチの仕様情報を取得するには、 [tidbcloud_serverless_branch (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/serverless_branch)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md index 6d7a23b15867a..19b830d36b83d 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -58,9 +58,9 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 - `output`ブロックはプログラミング言語の戻り値と同様の動作をします。詳細は[Terraformドキュメント](https://www.terraform.io/language/values/outputs)参照してください。 + `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 dfaffd90e0145..eab91aa6600aa 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -58,9 +58,9 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta - `output`ブロックを使用して、出力に表示されるデータ ソース情報を定義し、他の Terraform 構成が使用できるように情報を公開します。 - `output`ブロックはプログラミング言語の戻り値と同様の動作をします。詳細は[Terraformドキュメント](https://www.terraform.io/language/values/outputs)参照してください。 + `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 b2e626a8751f6..06bb787bdf313 100644 --- a/tidb-cloud/terraform-use-serverless-export-resource.md +++ b/tidb-cloud/terraform-use-serverless-export-resource.md @@ -54,7 +54,7 @@ summary: tidbcloud_serverless_export` リソースを使用して、 TiDB Cloud - サーバーレス エクスポート リソースを使用するには、リソース タイプを`tidbcloud_serverless_export`に設定します。 - リソース名は必要に応じて定義できます。例： `example` 。 - リソースの詳細については、サーバーレス エクスポート仕様情報に従って設定できます。 - - サーバーレス エクスポート仕様情報を取得するには、 [tidbcloud_serverless_export (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/serverless_export)参照してください。 + - サーバーレス エクスポート仕様情報を取得するには、 [tidbcloud_serverless_export (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/serverless_export)を参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index f882364a431f6..71df694ecd2e8 100644 --- a/tidb-cloud/terraform-use-sql-user-resource.md +++ b/tidb-cloud/terraform-use-sql-user-resource.md @@ -56,7 +56,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`データ ソースを実行することでユーザー プレフィックスを取得できます。 - - SQL ユーザー指定情報を取得するには、 [`tidbcloud_sql_user` (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/sql_user)参照してください。 + - 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 8c72c3f1daf9f..34173e2631939 100644 --- a/tidb-cloud/third-party-monitoring-integrations.md +++ b/tidb-cloud/third-party-monitoring-integrations.md @@ -21,10 +21,10 @@ Datadog 統合を使用すると、TiDB クラスターに関するメトリッ PrometheusとGrafanaの統合により、 TiDB CloudからPrometheus用の`scrape_config`ファイルを取得し、そのファイルの内容を使用してPrometheusを設定できます。これらのメトリクスはGrafanaダッシュボードで確認できます。 -詳細な統合手順と Prometheus が追跡するメトリックのリストについては、 [TiDB Cloud をPrometheus および Grafana と統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)参照してください。 +詳細な統合手順と Prometheus が追跡するメトリックのリストについては、 [TiDB Cloud をPrometheus および Grafana と統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)を参照してください。 ## New Relicとの統合 {#new-relic-integration} New Relic 統合を使用すると、 TiDB Cloudを構成して、TiDB クラスターに関するメトリック データを[New Relic](https://newrelic.com/)に送信し、これらのメトリックを New Relic ダッシュボードで表示できます。 -詳細な統合手順と New Relic が追跡するメトリックのリストについては、 [TiDB CloudとNew Relicの統合](/tidb-cloud/monitor-new-relic-integration.md)参照してください。 +詳細な統合手順と New Relic が追跡するメトリックのリストについては、 [TiDB CloudとNew Relicの統合](/tidb-cloud/monitor-new-relic-integration.md)を参照してください。 diff --git a/tidb-cloud/ticloud-auth-login.md b/tidb-cloud/ticloud-auth-login.md index c43a6acfa8be5..8ab4547373108 100644 --- a/tidb-cloud/ticloud-auth-login.md +++ b/tidb-cloud/ticloud-auth-login.md @@ -44,4 +44,4 @@ ticloud auth login --insecure-storage ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-auth-logout.md b/tidb-cloud/ticloud-auth-logout.md index a83252b43b492..d7b0f04f79cab 100644 --- a/tidb-cloud/ticloud-auth-logout.md +++ b/tidb-cloud/ticloud-auth-logout.md @@ -29,4 +29,4 @@ ticloud auth logout ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-auth-whoami.md b/tidb-cloud/ticloud-auth-whoami.md index 398f41110521a..c2889dd61638c 100644 --- a/tidb-cloud/ticloud-auth-whoami.md +++ b/tidb-cloud/ticloud-auth-whoami.md @@ -37,4 +37,4 @@ ticloud auth whoami ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-branch-create.md b/tidb-cloud/ticloud-branch-create.md index 83a02a04af33e..c3f83ceccaec6 100644 --- a/tidb-cloud/ticloud-branch-create.md +++ b/tidb-cloud/ticloud-branch-create.md @@ -5,7 +5,7 @@ summary: ticloud serverless branch create` のリファレンス。 # ticloud serverless branch create {#ticloud-serverless-branch-create} -TiDB Cloud Starter またはTiDB Cloud Essential クラスターの[支店](/tidb-cloud/branch-overview.md)作成します。 +TiDB Cloud Starter またはTiDB Cloud Essential クラスターの[支店](/tidb-cloud/branch-overview.md)を作成します。 ```shell ticloud serverless branch create [flags] @@ -53,4 +53,4 @@ ticloud serverless branch create --cluster-id --display-name --cluster-id ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-branch-describe.md b/tidb-cloud/ticloud-branch-describe.md index f0574a59853a4..1a26a2d15fe46 100644 --- a/tidb-cloud/ticloud-branch-describe.md +++ b/tidb-cloud/ticloud-branch-describe.md @@ -51,4 +51,4 @@ ticloud serverless branch describe --branch-id --cluster-id -o json ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-branch-shell.md b/tidb-cloud/ticloud-branch-shell.md index e681911b54c23..fb1ebc1780cf3 100644 --- a/tidb-cloud/ticloud-branch-shell.md +++ b/tidb-cloud/ticloud-branch-shell.md @@ -60,4 +60,4 @@ ticloud serverless branch shell -c -b -u -- ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-cluster-create.md b/tidb-cloud/ticloud-cluster-create.md index 5fcd0eb1f74d8..8ade915f55b9b 100644 --- a/tidb-cloud/ticloud-cluster-create.md +++ b/tidb-cloud/ticloud-cluster-create.md @@ -63,4 +63,4 @@ ticloud serverless create --display-name --region --max- ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-cluster-delete.md b/tidb-cloud/ticloud-cluster-delete.md index e07bf6b258718..369ebf24906da 100644 --- a/tidb-cloud/ticloud-cluster-delete.md +++ b/tidb-cloud/ticloud-cluster-delete.md @@ -51,4 +51,4 @@ ticloud serverless delete --cluster-id ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-cluster-describe.md b/tidb-cloud/ticloud-cluster-describe.md index 12249251db5d0..2288404415f54 100644 --- a/tidb-cloud/ticloud-cluster-describe.md +++ b/tidb-cloud/ticloud-cluster-describe.md @@ -50,4 +50,4 @@ ticloud serverless describe --cluster-id ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-cluster-list.md b/tidb-cloud/ticloud-cluster-list.md index 824f6724b0ee0..1d0185caba3f6 100644 --- a/tidb-cloud/ticloud-cluster-list.md +++ b/tidb-cloud/ticloud-cluster-list.md @@ -57,4 +57,4 @@ ticloud serverless list -p -o json ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-completion.md b/tidb-cloud/ticloud-completion.md index 620d8c43d9dcc..89cce1d194706 100644 --- a/tidb-cloud/ticloud-completion.md +++ b/tidb-cloud/ticloud-completion.md @@ -43,4 +43,4 @@ ticloud completion zsh ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-create.md b/tidb-cloud/ticloud-config-create.md index 1043d66983381..11cfeecfab412 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] @@ -50,4 +50,4 @@ ticloud config create --profile-name --public-key -- ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-delete.md b/tidb-cloud/ticloud-config-delete.md index 77ed330b51ba0..ef13d9944ea3c 100644 --- a/tidb-cloud/ticloud-config-delete.md +++ b/tidb-cloud/ticloud-config-delete.md @@ -42,4 +42,4 @@ ticloud config delete ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-describe.md b/tidb-cloud/ticloud-config-describe.md index d7701c9e1a7ad..80904861bbe3e 100644 --- a/tidb-cloud/ticloud-config-describe.md +++ b/tidb-cloud/ticloud-config-describe.md @@ -41,4 +41,4 @@ ticloud config describe ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-edit.md b/tidb-cloud/ticloud-config-edit.md index 50da9d895ed7e..3d3036b774601 100644 --- a/tidb-cloud/ticloud-config-edit.md +++ b/tidb-cloud/ticloud-config-edit.md @@ -15,7 +15,7 @@ Windows を使用している場合は、上記のコマンドを実行すると > **注記：** > -> フォーマットエラーや実行エラーを避けるため、設定ファイルを手動で編集することは推奨されません。代わりに、 [`ticloud config create`](/tidb-cloud/ticloud-config-create.md) 、 [`ticloud config delete`](/tidb-cloud/ticloud-config-delete.md) 、または[`ticloud config set`](/tidb-cloud/ticloud-config-set.md)使用して設定を変更できます。 +> フォーマットエラーや実行エラーを避けるため、設定ファイルを手動で編集することは推奨されません。代わりに、 [`ticloud config create`](/tidb-cloud/ticloud-config-create.md) 、 [`ticloud config delete`](/tidb-cloud/ticloud-config-delete.md) 、または[`ticloud config set`](/tidb-cloud/ticloud-config-set.md)を使用して設定を変更できます。 ## 例 {#examples} @@ -41,4 +41,4 @@ ticloud config edit ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-list.md b/tidb-cloud/ticloud-config-list.md index 408e572098902..9887b1db35b0d 100644 --- a/tidb-cloud/ticloud-config-list.md +++ b/tidb-cloud/ticloud-config-list.md @@ -41,4 +41,4 @@ ticloud config list ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-set.md b/tidb-cloud/ticloud-config-set.md index e8f168141e088..5c3332440e849 100644 --- a/tidb-cloud/ticloud-config-set.md +++ b/tidb-cloud/ticloud-config-set.md @@ -63,4 +63,4 @@ ticloud config set api-url https://api.tidbcloud.com ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-config-use.md b/tidb-cloud/ticloud-config-use.md index 16517cd100490..953f75fde8a4a 100644 --- a/tidb-cloud/ticloud-config-use.md +++ b/tidb-cloud/ticloud-config-use.md @@ -35,4 +35,4 @@ ticloud config use test ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-help.md b/tidb-cloud/ticloud-help.md index 5cbc31fdbedee..fcd52cb2bf714 100644 --- a/tidb-cloud/ticloud-help.md +++ b/tidb-cloud/ticloud-help.md @@ -43,4 +43,4 @@ ticloud help serverless create ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-import-cancel.md b/tidb-cloud/ticloud-import-cancel.md index e6bca94faf58b..aede92cfaa489 100644 --- a/tidb-cloud/ticloud-import-cancel.md +++ b/tidb-cloud/ticloud-import-cancel.md @@ -46,4 +46,4 @@ ticloud serverless import cancel --cluster-id --import-id --import-id --output json ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-import-start.md b/tidb-cloud/ticloud-import-start.md index e723fc887abe1..572ea2bdad98f 100644 --- a/tidb-cloud/ticloud-import-start.md +++ b/tidb-cloud/ticloud-import-start.md @@ -106,4 +106,4 @@ ticloud serverless import start --source-type AZURE_BLOB --azblob.uri ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md index 864bfca8692f0..c5c77e9e6e123 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md @@ -76,4 +76,4 @@ ticloud serverless audit-log config update -c --enabled=false ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-audit-log-download.md b/tidb-cloud/ticloud-serverless-audit-log-download.md index a42ed4beee767..a446c9ecc24a0 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-download.md +++ b/tidb-cloud/ticloud-serverless-audit-log-download.md @@ -47,4 +47,4 @@ ticloud serverless audit-log download -c --start-date ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 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 151e4a61b2df1..2936f71fd4307 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-create.md @@ -50,4 +50,4 @@ ticloud serverless audit-log filter-rule create --cluster-id --disp ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 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 c197fa410759e..2ec5e3f0cfd4f 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-delete.md @@ -44,4 +44,4 @@ ticloud serverless audit-log filter-rule delete --cluster-id --filt ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 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 a5755b426623a..b311d7928a79a 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-describe.md @@ -43,4 +43,4 @@ ticloud serverless audit-log filter-rule describe --cluster-id --fi ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 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 5742a24b607f3..a684b674219ae 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-list.md @@ -49,4 +49,4 @@ ticloud serverless audit-log filter-rule list -c -o json ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 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 f63f800df7a38..f04e785cbbca1 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md @@ -42,4 +42,4 @@ ticloud serverless audit-log filter-rule template --cluster-id ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 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 fc8d4003639e2..ff5b1a4482530 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-filter-rule-update.md @@ -45,7 +45,7 @@ ticloud serverless audit-log filter-rule update --cluster-id --filt | --display-name 文字列 | フィルター ルールの表示名。 | いいえ | 非対話型モードでのみ動作します。 | | --enabled | フィルター ルールを有効または無効にします。 | いいえ | 非対話型モードでのみ動作します。 | | --filter-rule-id 文字列 | フィルター ルールの ID。 | はい | 非対話型モードでのみ動作します。 | -| --rule | フィルタルール式を完了します。フィルタテンプレートを表示するには[`ticloud serverless audit-log filter template`](/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md)使用します。 | いいえ | 非対話型モードでのみ動作します。 | +| --rule | フィルタルール式を完了します。フィルタテンプレートを表示するには[`ticloud serverless audit-log filter template`](/tidb-cloud/ticloud-serverless-audit-log-filter-rule-template.md)を使用します。 | いいえ | 非対話型モードでのみ動作します。 | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | インタラクティブ モードと非インタラクティブ モードの両方で動作します。 | ## 継承されたフラグ {#inherited-flags} @@ -58,4 +58,4 @@ ticloud serverless audit-log filter-rule update --cluster-id --filt ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-authorized-network-create.md b/tidb-cloud/ticloud-serverless-authorized-network-create.md index 9f8d4bcda371f..1b9d64b80439f 100644 --- a/tidb-cloud/ticloud-serverless-authorized-network-create.md +++ b/tidb-cloud/ticloud-serverless-authorized-network-create.md @@ -47,4 +47,4 @@ ticloud serverless authorized-network create -c --display-name --start-ip-address ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-authorized-network-list.md b/tidb-cloud/ticloud-serverless-authorized-network-list.md index 8c5476e26e708..ffadf598ab901 100644 --- a/tidb-cloud/ticloud-serverless-authorized-network-list.md +++ b/tidb-cloud/ticloud-serverless-authorized-network-list.md @@ -45,4 +45,4 @@ ticloud serverless authorized-network list -c ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-authorized-network-update.md b/tidb-cloud/ticloud-serverless-authorized-network-update.md index 8814039d31e52..f58e74d221b1a 100644 --- a/tidb-cloud/ticloud-serverless-authorized-network-update.md +++ b/tidb-cloud/ticloud-serverless-authorized-network-update.md @@ -49,4 +49,4 @@ ticloud serverless authorized-network update -c --start-ip-address ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-capacity.md b/tidb-cloud/ticloud-serverless-capacity.md index 53c2e1541834e..2dde6c7ccdf5e 100644 --- a/tidb-cloud/ticloud-serverless-capacity.md +++ b/tidb-cloud/ticloud-serverless-capacity.md @@ -46,4 +46,4 @@ ticloud serverless capacity -c --max-rcu --min-rcu -e ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-export-create.md b/tidb-cloud/ticloud-serverless-export-create.md index e74260047fa1d..f03082c0d8ec8 100644 --- a/tidb-cloud/ticloud-serverless-export-create.md +++ b/tidb-cloud/ticloud-serverless-export-create.md @@ -86,7 +86,7 @@ ticloud serverless export create -c --sql 'select * from database.t | --csv.separator 文字列 | CSV ファイル内の各値の区切り文字を指定します。(デフォルトは ",") | いいえ | 非対話型モードでのみ動作します。 | | --csv.スキップヘッダー | ヘッダーなしでテーブルの CSV ファイルをエクスポートします。 | いいえ | 非対話型モードでのみ動作します。 | | --parquet.compression 文字列 | Parquet圧縮アルゴリズムを指定します。[ `"GZIP"` `"SNAPPY"` `"ZSTD"` `"NONE"` ]のいずれかです。デフォルト値は`"ZSTD"`です。 | いいえ | 非対話型モードでのみ動作します。 | -| --filter文字列 | エクスポートするテーブルをテーブルフィルタパターンで指定します。--sql と同時に使用しないでください。詳細については、 [テーブルフィルター](/table-filter.md)参照してください。 | いいえ | 非対話型モードでのみ動作します。 | +| --filter文字列 | エクスポートするテーブルをテーブルフィルタパターンで指定します。--sql と同時に使用しないでください。詳細については、 [テーブルフィルター](/table-filter.md)を参照してください。 | いいえ | 非対話型モードでのみ動作します。 | | --sql 文字列 | `SQL SELECT`ステートメントを使用してエクスポートされたデータをフィルターします。 | いいえ | 非対話型モードでのみ動作します。 | | --文字列 | エクスポートされたテーブルを`WHERE`条件でフィルタリングします。--sqlと同時に使用しないでください。 | いいえ | 非対話型モードでのみ動作します。 | | --compression | エクスポートファイルの圧縮アルゴリズムを指定します。サポートされているアルゴリズムは`GZIP` 、 `SNAPPY` 、 `ZSTD` 、 `NONE`です。デフォルト値は`GZIP`です。 | いいえ | 非対話型モードでのみ動作します。 | @@ -103,4 +103,4 @@ ticloud serverless export create -c --sql 'select * from database.t ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-export-describe.md b/tidb-cloud/ticloud-serverless-export-describe.md index a01d3c3cbdd60..1a806ba26e189 100644 --- a/tidb-cloud/ticloud-serverless-export-describe.md +++ b/tidb-cloud/ticloud-serverless-export-describe.md @@ -51,4 +51,4 @@ ticloud serverless export describe -c -e ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-export-download.md b/tidb-cloud/ticloud-serverless-export-download.md index b594e31e3bb7e..bc72228507a21 100644 --- a/tidb-cloud/ticloud-serverless-export-download.md +++ b/tidb-cloud/ticloud-serverless-export-download.md @@ -48,4 +48,4 @@ ticloud serverless export download -c -e ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-export-list.md b/tidb-cloud/ticloud-serverless-export-list.md index 77d131f7d370f..507c5ca2e9c9a 100644 --- a/tidb-cloud/ticloud-serverless-export-list.md +++ b/tidb-cloud/ticloud-serverless-export-list.md @@ -57,4 +57,4 @@ ticloud serverless export list -c -o json ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-region.md b/tidb-cloud/ticloud-serverless-region.md index bca71a6bde279..bf66cc06751eb 100644 --- a/tidb-cloud/ticloud-serverless-region.md +++ b/tidb-cloud/ticloud-serverless-region.md @@ -45,4 +45,4 @@ ticloud serverless region -o json ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-shell.md b/tidb-cloud/ticloud-serverless-shell.md index a96444c502e53..a032e55e2ac1d 100644 --- a/tidb-cloud/ticloud-serverless-shell.md +++ b/tidb-cloud/ticloud-serverless-shell.md @@ -59,4 +59,4 @@ ticloud serverless shell -c -u --password ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-spending-limit.md b/tidb-cloud/ticloud-serverless-spending-limit.md index 1495a13cf7542..a7ab6f75de0e4 100644 --- a/tidb-cloud/ticloud-serverless-spending-limit.md +++ b/tidb-cloud/ticloud-serverless-spending-limit.md @@ -45,4 +45,4 @@ ticloud serverless spending-limit -c --monthly --password --ro ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-sql-user-delete.md b/tidb-cloud/ticloud-serverless-sql-user-delete.md index 54780dcd1cc86..209a4563048c2 100644 --- a/tidb-cloud/ticloud-serverless-sql-user-delete.md +++ b/tidb-cloud/ticloud-serverless-sql-user-delete.md @@ -45,4 +45,4 @@ ticloud serverless sql-user delete -c --user ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-sql-user-list.md b/tidb-cloud/ticloud-serverless-sql-user-list.md index 523f047ae82a0..2b1fa181b3964 100644 --- a/tidb-cloud/ticloud-serverless-sql-user-list.md +++ b/tidb-cloud/ticloud-serverless-sql-user-list.md @@ -45,4 +45,4 @@ ticloud serverless sql-user list -c ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-sql-user-update.md b/tidb-cloud/ticloud-serverless-sql-user-update.md index 0922d407ee99a..624f22122f1f7 100644 --- a/tidb-cloud/ticloud-serverless-sql-user-update.md +++ b/tidb-cloud/ticloud-serverless-sql-user-update.md @@ -49,4 +49,4 @@ ticloud serverless sql-user update -c --user --password ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-serverless-update.md b/tidb-cloud/ticloud-serverless-update.md index 91d31e8a91823..a77244c05c5bb 100644 --- a/tidb-cloud/ticloud-serverless-update.md +++ b/tidb-cloud/ticloud-serverless-update.md @@ -53,4 +53,4 @@ ticloud serverless update -c --labels "{\"label1\":\"value1\"}" ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/ticloud-upgrade.md b/tidb-cloud/ticloud-upgrade.md index 6e90684f1904e..29c736007e853 100644 --- a/tidb-cloud/ticloud-upgrade.md +++ b/tidb-cloud/ticloud-upgrade.md @@ -36,4 +36,4 @@ ticloud upgrade ## フィードバック {#feedback} -TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)作成してください。また、皆様からの貢献も歓迎いたします。 +TiDB Cloud CLI についてご質問やご提案がございましたら、お気軽に[問題](https://github.com/tidbcloud/tidbcloud-cli/issues/new/choose)を作成してください。また、皆様からの貢献も歓迎いたします。 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index b06f40229c5ec..f983f4722dd7f 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -26,7 +26,7 @@ TiDB Cloud は、実行された SQL ステートメントなど、データベ > **注記：** > > - データベース監査ログは、 TiDB Cloud Starter では使用できません。 - > - TiDB Cloud Essential については、 [TiDB Cloud Essential のデータベース監査ログ (PREVIEW)](/tidb-cloud/essential-database-audit-logging.md)参照してください。 + > - TiDB Cloud Essential については、 [TiDB Cloud Essential のデータベース監査ログ (PREVIEW)](/tidb-cloud/essential-database-audit-logging.md)を参照してください。 - 組織内で`Organization Owner`または`Project Owner`ロールに所属しています。それ以外の場合、 TiDB Cloudコンソールでデータベース監査関連のオプションは表示されません。詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)ご覧ください。 @@ -50,7 +50,7 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の AWS > > AWS S3バケットでオブジェクトロックを有効にしないでください。オブジェクトロックを有効にすると、 TiDB Cloudが監査ログファイルをS3にプッシュできなくなります。 -詳細については、AWS ユーザーガイドの[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)参照してください。 +詳細については、AWS ユーザーガイドの[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照してください。 #### ステップ2. Amazon S3アクセスを構成する {#step-2-configure-amazon-s3-access} @@ -197,7 +197,7 @@ Azure の監査ログを有効にするには、次の手順を実行します TiDB Cloudがデータベース監査ログを書き込む宛先として、組織の Azure サブスクリプションに Azureストレージアカウントを作成します。 -詳細については、Azure ドキュメントの[Azureストレージアカウントを作成する](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-create?tabs=azure-portal)参照してください。 +詳細については、Azure ドキュメントの[Azureストレージアカウントを作成する](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-create?tabs=azure-portal)を参照してください。 #### ステップ2. Azure Blob Storageアクセスを構成する {#step-2-configure-azure-blob-storage-access} diff --git a/tidb-cloud/tidb-cloud-billing-dm.md b/tidb-cloud/tidb-cloud-billing-dm.md index a45bf4a3c3252..6f6681eb0c37d 100644 --- a/tidb-cloud/tidb-cloud-billing-dm.md +++ b/tidb-cloud/tidb-cloud-billing-dm.md @@ -20,7 +20,7 @@ TiDB Cloudは、データ移行のキャパシティをレプリケーション | 8台のRCU | 40 MiB/秒 | 40,000行/秒 | 30000 | | 16 RCU | 45 MiB/秒 | 80,000行/秒 | 60000 | -データ移行 RCU の価格の詳細については、 [データ移行コスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#dm-cost)参照してください。 +データ移行 RCU の価格の詳細については、 [データ移行コスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#dm-cost)を参照してください。 > **注記：** > @@ -33,7 +33,7 @@ TiDB Cloudは、データ移行のキャパシティをレプリケーション ## 価格 {#price} -各 Data Migration RCU でサポートされているリージョンとTiDB Cloudの価格については、 [データ移行コスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#dm-cost)参照してください。 +各 Data Migration RCU でサポートされているリージョンとTiDB Cloudの価格については、 [データ移行コスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#dm-cost)を参照してください。 データ移行ジョブは、ターゲット TiDB ノードと同じリージョンにあります。 diff --git a/tidb-cloud/tidb-cloud-billing-recovery-group.md b/tidb-cloud/tidb-cloud-billing-recovery-group.md index 8caa4cb5e015c..a40d50a148120 100644 --- a/tidb-cloud/tidb-cloud-billing-recovery-group.md +++ b/tidb-cloud/tidb-cloud-billing-recovery-group.md @@ -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 b4368a7593030..70816527afce0 100644 --- a/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md +++ b/tidb-cloud/tidb-cloud-billing-ticdc-rcu.md @@ -39,7 +39,7 @@ TiDB Cloud Dedicatedは、TiCDCレプリケーション容量ユニット（RCU ### 価格 {#price} -各 TiCDC RCU でサポートされているリージョンとTiDB Cloudの価格については、 [チェンジフィードコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#changefeed-cost)参照してください。 +各 TiCDC RCU でサポートされているリージョンとTiDB Cloudの価格については、 [チェンジフィードコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#changefeed-cost)を参照してください。 ## プライベートデータリンクのコスト {#private-data-link-cost} diff --git a/tidb-cloud/tidb-cloud-billing.md b/tidb-cloud/tidb-cloud-billing.md index 3ffc73d29e3d5..725ea64741e0b 100644 --- a/tidb-cloud/tidb-cloud-billing.md +++ b/tidb-cloud/tidb-cloud-billing.md @@ -11,11 +11,11 @@ TiDB Cloudは、お客様が使用したリソースに応じて課金されま ### TiDB Cloud Dedicatedの料金プラン {#pricing-for-tidb-cloud-dedicated} -[TiDB Cloud Dedicatedの料金詳細](https://www.pingcap.com/tidb-dedicated-pricing-details/)参照してください。 +[TiDB Cloud Dedicatedの料金詳細](https://www.pingcap.com/tidb-dedicated-pricing-details/)を参照してください。 ### TiDB Cloud Starterの料金プラン {#pricing-for-starter} {#pricing-for-starter} -[TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +[TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 ### TiDB Cloud Essentialの価格設定 {#pricing-for-essential} {#pricing-for-essential} @@ -187,7 +187,7 @@ TiDB Cloudは、概念実証（PoC）ユーザー向けに一定数のクレジ > **ヒント：** > -> PoC を申請するには、 [TiDB Cloudを使用して概念実証（PoC）を実施する](/tidb-cloud/tidb-cloud-poc.md)参照してください。 +> PoC を申請するには、 [TiDB Cloudを使用して概念実証（PoC）を実施する](/tidb-cloud/tidb-cloud-poc.md)を参照してください。 クレジットに関する詳細情報は、「**クレジット」**タブで確認できます。そこには、合計クレジット数、利用可能なクレジット数、現在の使用状況、およびステータスが含まれます。 diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index 09e7d4dd68b11..0168f8da7eb1f 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -89,7 +89,7 @@ TiDB Cloudコンソールのデフォルトの[**スロークエリ**](/tidb-clo スロークエリの保持ポリシーは 7 日間です。 -詳細については[TiDB Dashboardのスロークエリ](https://docs.pingcap.com/tidb/stable/dashboard-slow-query)参照してください。 +詳細については[TiDB Dashboardのスロークエリ](https://docs.pingcap.com/tidb/stable/dashboard-slow-query)を参照してください。 ## TopSQLを監視する {#monitor-topsql} @@ -105,7 +105,7 @@ TopSQL を表示するには、次の手順を実行します。 4. TopSQL によって表示されるグラフと表を分析します。 -詳細については[TiDB DashboardのTopSQL](https://docs.pingcap.com/tidb/stable/top-sql)参照してください。 +詳細については[TiDB DashboardのTopSQL](https://docs.pingcap.com/tidb/stable/top-sql)を参照してください。 ## ベンチマークレポートを生成する {#generate-benchmark-reports} diff --git a/tidb-cloud/tidb-cloud-connect-aws-dms.md b/tidb-cloud/tidb-cloud-connect-aws-dms.md index 68d1281305859..43e1b2eaeb600 100644 --- a/tidb-cloud/tidb-cloud-connect-aws-dms.md +++ b/tidb-cloud/tidb-cloud-connect-aws-dms.md @@ -37,9 +37,9 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント - [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーション インスタンスがインターネットにアクセスできることを確認します。 - - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](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)参照してください。 + - レプリケーションインスタンスをプライベートサブネットにデプロイ、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも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 クラスターに接続するには、次のドキュメントを参照して、まずプライベート エンドポイントを設定し、プライベート サブネットにレプリケーション インスタンスをデプロイします。 @@ -52,9 +52,9 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント - [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーション インスタンスがインターネットにアクセスできることを確認します。 - - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](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)参照してください。 + - レプリケーションインスタンスをプライベートサブネットにデプロイ、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも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)を参照してプライベート エンドポイントを設定し、レプリケーション インスタンスをプライベート サブネットにデプロイします。 @@ -68,9 +68,9 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - [パブリックエンドポイント経由でTiDB Cloud Dedicated クラスターに接続する](/tidb-cloud/connect-via-standard-connection.md)については、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認するために、次のいずれかを実行します。さらに、レプリケーションインスタンスまたは NAT ゲートウェイのパブリック IP アドレスをクラスターの[IPアクセスリスト](/tidb-cloud/configure-ip-access-list.md)に追加する必要があります。 - - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](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)参照してください。 + - レプリケーションインスタンスをプライベートサブネットにデプロイ、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも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) 、プライベート サブネットにレプリケーション インスタンスをデプロイします。 @@ -90,7 +90,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド 3. インスタンス名、ARN、説明を入力します。 4. **インスタンス構成**セクションで、インスタンスを構成します。 - - **インスタンスクラス**: 適切なインスタンスクラスを選択します。詳細については、 [レプリケーションインスタンスタイプの選択](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html)参照してください。 + - **インスタンスクラス**: 適切なインスタンスクラスを選択します。詳細については、 [レプリケーションインスタンスタイプの選択](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html)を参照してください。 - **エンジン バージョン**: デフォルト構成を維持します。 - **高可用性**: ビジネス ニーズに応じて、**マルチ AZ**または**シングル AZ**を選択します。 @@ -113,7 +113,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド ## TiDB Cloud DMSエンドポイントを作成する {#create-tidb-cloud-dms-endpoints} -接続に関しては、 TiDB Cloudクラスターをソースとして使用する場合とターゲットとして使用する場合の手順は似ていますが、DMS ではソースとターゲットでデータベース設定要件が異なります。詳細については、 [MySQLをソースとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html)または[MySQLをターゲットとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html)参照してください。TiDB Cloudクラスターをソースとして使用する場合、TiDB は MySQL binlogをサポートしていないため、**既存のデータの移行**のみが可能です。 +接続に関しては、 TiDB Cloudクラスターをソースとして使用する場合とターゲットとして使用する場合の手順は似ていますが、DMS ではソースとターゲットでデータベース設定要件が異なります。詳細については、 [MySQLをソースとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html)または[MySQLをターゲットとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html)を参照してください。TiDB Cloudクラスターをソースとして使用する場合、TiDB は MySQL binlogをサポートしていないため、**既存のデータの移行**のみが可能です。 1. AWS DMS コンソールで、 [**エンドポイント**](https://console.aws.amazon.com/dms/v2/home#endpointList)ページに移動し、対応するリージョンに切り替えます。 @@ -136,7 +136,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - **ユーザー名**: 移行先クラスターのユーザー。DMSの要件を満たしていることを確認してください。 - **パスワード**: クラスター ユーザーのパスワード。 - **セキュリティ Socket Layer (SSL) モード**：パブリックエンドポイント経由で接続する場合は、トランスポートセキュリティを確保するために、モードを**verify-full**に設定することを強くお勧めします。プライベートエンドポイント経由で接続する場合は、モードを**none**に設定できます。 - - （オプション） **CA証明書**： [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)使用します。詳細については、 [TiDB Cloud Starter または Essential への TLS 接続](/tidb-cloud/secure-connections-to-serverless-clusters.md)参照してください。 + - （オプション） **CA証明書**： [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)を使用します。詳細については、 [TiDB Cloud Starter または Essential への TLS 接続](/tidb-cloud/secure-connections-to-serverless-clusters.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md index 34b8db6b8b1f4..5824347bc5157 100644 --- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md +++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md @@ -16,26 +16,26 @@ summary: データ移行時に発生する事前チェックエラー、移行 ### エラーメッセージ: mysql server_id が 0 より大きいかどうかを確認してください {#error-message-check-whether-mysql-server-id-has-been-greater-than-0} - Amazon Aurora MySQL または Amazon RDS: `server_id`はデフォルトで設定されています。設定する必要はありません。フルデータ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。 -- MySQL: MySQL 用に`server_id`を構成するには、 [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)参照してください。 +- MySQL: MySQL 用に`server_id`を構成するには、 [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)を参照してください。 ### エラーメッセージ: mysql binlogが有効になっているか確認してください {#error-message-check-whether-mysql-binlog-is-enabled} - Amazon Aurora MySQL: [Amazon Aurora MySQL互換クラスターでバイナリログを有効にするにはどうすればよいですか？](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/?nc1=h_ls)を参照してください。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。 -- Amazon RDS: [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)参照してください。 -- Google Cloud SQL for MySQL: Google は、MySQL マスター データベースのポイントインタイムリカバリを通じてバイナリ ロギングを可能にします。 [特定時点へのリカバリを有効にする](https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#enablingpitr)参照してください。 -- MySQL: [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)参照してください。 +- Amazon RDS: [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)を参照してください。 +- Google Cloud SQL for MySQL: Google は、MySQL マスター データベースのポイントインタイムリカバリを通じてバイナリ ロギングを可能にします。 [特定時点へのリカバリを有効にする](https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#enablingpitr)を参照してください。 +- MySQL: [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)を参照してください。 ### エラーメッセージ: mysql binlog_format が ROW かどうか確認してください {#error-message-check-whether-mysql-binlog-format-is-row} - Amazon Aurora MySQL: [Amazon Aurora MySQL互換クラスターでバイナリログを有効にするにはどうすればよいですか？](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/?nc1=h_ls)を参照してください。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。 -- Amazon RDS: [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)参照してください。 -- MySQL: `set global binlog_format=ROW;`を実行します。 [バイナリログフォーマットの設定](https://dev.mysql.com/doc/refman/8.0/en/binary-log-setting.html)参照してください。 +- Amazon RDS: [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)を参照してください。 +- MySQL: `set global binlog_format=ROW;`を実行します。 [バイナリログフォーマットの設定](https://dev.mysql.com/doc/refman/8.0/en/binary-log-setting.html)を参照してください。 ### エラーメッセージ: mysql binlog_row_image が満杯かどうか確認してください {#error-message-check-whether-mysql-binlog-row-image-is-full} - Amazon Aurora MySQL: `binlog_row_image`は設定できません。この事前チェック項目は、設定変更の対象外です。完全データ移行と増分データ移行の両方をサポートするために、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。 - Amazon RDS: 手順は`binlog_format`パラメータの設定と似ています。唯一の違いは、変更する必要のあるパラメータが`binlog_row_image`ではなく`binlog_format`であることです。MySQL [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html). -- MySQL: `set global binlog_row_image = FULL;` 。 [バイナリログのオプションと変数](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_image)参照してください。 +- MySQL: `set global binlog_row_image = FULL;` 。 [バイナリログのオプションと変数](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_row_image)を参照してください。 ### エラーメッセージ: 移行されたデータベースが binlog_do_db/binlog_ignore_db に含まれているかどうかを確認してください {#error-message-check-whether-migrated-dbs-are-in-binlog-do-db-binlog-ignore-db} @@ -52,7 +52,7 @@ Amazon RDS の場合、次のパラメータを変更する必要があります 上流のデータベースでエラーが発生した場合は、 `max_connections`を次のように設定してください。 -- Amazon Aurora MySQL: このプロセスは、 `binlog_format`の設定と似ています。唯一の違いは、変更するパラメータが`max_connections`ではなく`binlog_format`であることです。 [Amazon Aurora MySQL互換クラスターでバイナリログを有効にするにはどうすればよいですか？](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/?nc1=h_ls)参照してください。 +- Amazon Aurora MySQL: このプロセスは、 `binlog_format`の設定と似ています。唯一の違いは、変更するパラメータが`max_connections`ではなく`binlog_format`であることです。 [Amazon Aurora MySQL互換クラスターでバイナリログを有効にするにはどうすればよいですか？](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/?nc1=h_ls)を参照してください。 - Amazon RDS: 手順は`binlog_format`の設定と似ています。唯一の違いは、変更するパラメータが`max_connections`ではなく`binlog_format` } であることです。MySQL [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html). - MySQL: ドキュメント[最大接続数](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connections)に従って`max_connections`を設定します。 diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md index e11f9c64411cd..77d9101d9ef82 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md @@ -60,14 +60,14 @@ TiDB Cloudコンソールと Azure ポータルを使用して CMEK を構成す az ad sp create --id {Microsoft_Entra_Application_ID} ``` - 詳細については[Microsoft Entra ID のアプリケーションおよびサービス プリンシパル オブジェクト](https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)参照してください。 + 詳細については[Microsoft Entra ID のアプリケーションおよびサービス プリンシパル オブジェクト](https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)を参照してください。 6. AzureアカウントでKey Vaultを作成するか、既存のKey Vaultを選択します。以下の点を確認してください。 - **パージ保護**が有効になっています。 - **リージョンは**クラスターのリージョンと一致します。 -7. TiDB Cloudコンソールで、Key Vault 名とキー名を入力します。TiDB Cloud は、セキュリティ強化のため、キー名に一意のサフィックスを追加します。キー名全体をコピーし、Azure ポータルで暗号化キーを作成します。詳細については、 [暗号化キーを作成する](https://learn.microsoft.com/en-us/azure/key-vault/keys/quick-create-portal)参照してください。 +7. TiDB Cloudコンソールで、Key Vault 名とキー名を入力します。TiDB Cloud は、セキュリティ強化のため、キー名に一意のサフィックスを追加します。キー名全体をコピーし、Azure ポータルで暗号化キーを作成します。詳細については、 [暗号化キーを作成する](https://learn.microsoft.com/en-us/azure/key-vault/keys/quick-create-portal)を参照してください。 8. 現在のユーザーに**Key Vault Crypto Officer**ロールを割り当てます。 @@ -108,7 +108,7 @@ TiDB Cloudコンソールと Azure Resource Manager を使用して CMEK を構 az ad sp create --id {Microsoft_Entra_Application_ID} ``` - 詳細については[Microsoft Entra ID のアプリケーションおよびサービス プリンシパル オブジェクト](https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)参照してください。 + 詳細については[Microsoft Entra ID のアプリケーションおよびサービス プリンシパル オブジェクト](https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)を参照してください。 6. Azureポータルで[Azure Resource Manager 用の TiDB カスタム デプロイメント テンプレート](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Ftcidm.blob.core.windows.net%2Fcmek%2Fazure_cmek_rmt.json%3Fsv%3D2015-04-05%26ss%3Db%26srt%3Dco%26sp%3Drl%26se%3D2029-03-01T00%3A00%3A01.0000000Z%26sig%3DIA02CymcFpYCwoTsqCSJVD%2F8Khh%2F0UAPrkKDeLMIIFc%3D)開きます。**サブスクリプション**と**リソースグループ**を選択し、 **「インスタンスの詳細」**セクションに次のように入力します。 diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index 18a6d79061c3b..a44785e1318c4 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} @@ -125,7 +125,7 @@ HTAP シナリオの詳細については、 [データプラットフォーム ### TiFlashにデータを直接インポートできますか？ {#can-i-import-my-data-directly-to-tiflash} -いいえ。TiDB Cloudにデータをインポートすると、データはTiKVにインポートされます。インポートが完了したら、SQLステートメントを使用して、 TiFlashにレプリケートするテーブルを指定できます。その後、TiDBは指定されたテーブルのレプリカをTiFlashに作成します。詳細については、 [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md)参照してください。. +いいえ。TiDB Cloudにデータをインポートすると、データはTiKVにインポートされます。インポートが完了したら、SQLステートメントを使用して、 TiFlashにレプリケートするテーブルを指定できます。その後、TiDBは指定されたテーブルのレプリカをTiFlashに作成します。詳細については、 [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md)を参照してください。. ### TiFlashのデータをCSV形式でエクスポートできますか？ {#can-i-export-tiflash-data-in-the-csv-format} @@ -183,7 +183,7 @@ TiDB Cloud Dedicatedクラスターの場合、クラスターへの接続手順 3. クラスタサーバー用にTLSをダウンロードして設定してください。 4. SQLクライアントを選択し、 TiDB Cloud UIに自動生成された接続文字列を表示させた後、その文字列を使用してSQLクライアント経由でクラスターに接続します。 -詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。 +詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 @@ -194,7 +194,7 @@ TiDB Cloud StarterまたはEssentialインスタンスの場合、インスタ 1. データベースユーザーとログイン認証情報を設定します。 2. SQLクライアントを選択し、 TiDB Cloud UIに自動生成された接続文字列を表示させた後、その文字列を使用してSQLクライアント経由でTiDB Cloud StarterまたはEssentialインスタンスに接続します。 -詳細については、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)参照してください。 +詳細については、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index fcc2c9ddb9a0f..a932c8a992c1f 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -25,9 +25,9 @@ ACIDとは、トランザクションの4つの主要な特性、すなわち原 ### Chat2Query {#chat2query} -Chat2Query は、SQL エディターに統合された AI を活用した機能で、ユーザーが自然言語命令を使用して SQL クエリを生成、デバッグ、または書き換えるのを支援します。詳細については、[AI支援型SQLエディタでデータを探索しよう](/tidb-cloud/explore-data-with-chat2query.md)参照してください。 +Chat2Query は、SQL エディターに統合された AI を活用した機能で、ユーザーが自然言語命令を使用して SQL クエリを生成、デバッグ、または書き換えるのを支援します。詳細については、[AI支援型SQLエディタでデータを探索しよう](/tidb-cloud/explore-data-with-chat2query.md)を参照してください。 -さらに、 TiDB Cloud は、AWS でホストされているTiDB Cloud Starterインスタンス向けに Chat2Query API を提供しています。有効化すると、 TiDB Cloud は自動的に**Chat2Query**というシステムデータアプリと、データサービスに Chat2Data エンドポイントを作成します。このエンドポイントを呼び出すことで、指示を与えることにより AI に SQL ステートメントを生成および実行させることができます。詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)参照してください。. +さらに、 TiDB Cloud は、AWS でホストされているTiDB Cloud Starterインスタンス向けに Chat2Query API を提供しています。有効化すると、 TiDB Cloud は自動的に**Chat2Query**というシステムデータアプリと、データサービスに Chat2Data エンドポイントを作成します。このエンドポイントを呼び出すことで、指示を与えることにより AI に SQL ステートメントを生成および実行させることができます。詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)を参照してください。. ### クラスタ {#cluster} @@ -45,7 +45,7 @@ TiDB Cloudは、概念実証（PoC）ユーザー向けに一定数のクレジ データサービス[データサービス（PREVIEW）](#data-service)のデータアプリは、特定のアプリケーションのデータにアクセスするために使用できるエンドポイントの集合です。APIキーを使用して認証設定を構成することで、データアプリ内のエンドポイントへのアクセスを制限できます。 -詳細については、[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)参照してください。 +詳細については、[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)を参照してください。 ### データサービス {#data-service} @@ -63,7 +63,7 @@ TiDB Cloudは、概念実証（PoC）ユーザー向けに一定数のクレジ Data Service のエンドポイントは、SQL ステートメントを実行するようにカスタマイズできる Web API です。SQL ステートメントには、 `WHERE`句で使用される値などのパラメーターを指定できます。クライアントがエンドポイントを呼び出し、リクエスト URL のパラメーターに値を指定すると、エンドポイントは指定されたパラメーターを使用して対応する SQL ステートメントを実行し、結果を HTTP レスポンスの一部として返します。 -詳細については、[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)参照してください。 +詳細については、[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)を参照してください。 ## F {#f} @@ -71,7 +71,7 @@ Data Service のエンドポイントは、SQL ステートメントを実行す 意味的な類似性に焦点を当てる[ベクトル検索](/ai/concepts/vector-search-overview.md)とは異なり、全文検索では正確なキーワードに基づいて文書を取得できます。検索拡張生成（RAG）シナリオでは、全文検索とベクトル検索を組み合わせて使用​​することで、検索品質を向上させることができます。 -詳細については、 [SQLによる全文検索](/ai/guides/vector-search-full-text-search-sql.md)および[Pythonによる全文検索](/ai/guides/vector-search-full-text-search-python.md)参照してください。 +詳細については、 [SQLによる全文検索](/ai/guides/vector-search-full-text-search-sql.md)および[Pythonによる全文検索](/ai/guides/vector-search-full-text-search-python.md)を参照してください。 ## M {#m} @@ -81,7 +81,7 @@ TiDB Cloudの[組織](#organization)に招待されたユーザー。 ### MPP {#mpp} -バージョン5.0以降、TiDBはTiFlashノードを介した大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算にMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中にExchange操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算速度が向上します。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)参照してください。 . +バージョン5.0以降、TiDBはTiFlashノードを介した大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算にMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中にExchange操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算速度が向上します。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 . ### MSP顧客 {#msp-customer} @@ -162,14 +162,14 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー ### レプリケーション容量ユニット（RCU） {#replication-capacity-unit-rcu} -TiDB Cloud は、TiCDC Replication Capacity Unit (RCU) の[変更フィード](/tidb-cloud/changefeed-overview.md)の容量を測定します。変更フィードを作成するときに、適切な仕様を選択できます。 RCU が高いほど、レプリケーションのパフォーマンスが向上します。これらの TiCDC 変更フィード RCU に対して料金が発生します。詳細については、 [変更フィードのコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#changefeed-cost)参照してください。 +TiDB Cloud は、TiCDC Replication Capacity Unit (RCU) の[変更フィード](/tidb-cloud/changefeed-overview.md)の容量を測定します。変更フィードを作成するときに、適切な仕様を選択できます。 RCU が高いほど、レプリケーションのパフォーマンスが向上します。これらの TiCDC 変更フィード RCU に対して料金が発生します。詳細については、 [変更フィードのコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#changefeed-cost)を参照してください。 ### 要求容量単位（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 は、ワークロードに基づいて 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)参照してください。 +- 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)を参照してください。 ### リクエストユニット（RU） {#request-unit-ru} @@ -177,9 +177,9 @@ TiDB Cloud Starter、 Essential、およびPremiumプランでは、リクエス - TiDB Cloud Starter は、消費された RU の合計数に基づいて請求されます。詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 - TiDB Cloud Essentialは、プロビジョニングされた[要求容量単位（RCU）](#request-capacity-unit-rcu)の数に基づいて請求されます。 1 つの RCU は、1 秒あたり特定の数の RU を処理できる固定量のコンピューティング リソースを提供します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 -- TiDB Cloud Premium は、ワークロードによって消費された実際のリクエスト キャパシティー ユニット (RCU) に基づいて請求されます。 TiDB Cloudは1 秒あたりの平均 RU を毎分計算し、その平均値を[要求容量単位（RCU）](#request-capacity-unit-rcu)として請求に使用します。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)参照してください。 +- TiDB Cloud 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} @@ -208,7 +208,7 @@ TiDB Cloudリソースとは、管理可能なTiDB Cloudデプロイメント単 TiDB Xは、クラウドネイティブなオブジェクトストレージをTiDBの基盤とする、新しい分散SQLアーキテクチャです。コンピューティングとストレージを分離することで、TiDBはワークロードパターン、ビジネスサイクル、データ特性にリアルタイムで適応し、インテリジェントなスケーリングを実現します。 -TiDB Xアーキテクチャは、 TiDB Cloud Starter、 Essential、および Premium で利用できるようになりました。詳細については、 [TiDB Xのご紹介：AI時代の分散SQLのための新たな基盤](https://www.pingcap.com/blog/introducing-tidb-x-a-new-foundation-distributed-sql-ai-era/)および[PingCAPがSCaiLEサミット2025でTiDB Xと新たなAI機能を発表](https://www.pingcap.com/press-release/pingcap-launches-tidb-x-new-ai-capabilities/)参照してください。 +TiDB Xアーキテクチャは、 TiDB Cloud Starter、 Essential、および Premium で利用できるようになりました。詳細については、 [TiDB Xのご紹介：AI時代の分散SQLのための新たな基盤](https://www.pingcap.com/blog/introducing-tidb-x-a-new-foundation-distributed-sql-ai-era/)および[PingCAPがSCaiLEサミット2025でTiDB Xと新たなAI機能を発表](https://www.pingcap.com/press-release/pingcap-launches-tidb-x-new-ai-capabilities/)を参照してください。 ### TiDB Xインスタンス {#tidb-x-instance} diff --git a/tidb-cloud/tidb-cloud-import-local-files.md b/tidb-cloud/tidb-cloud-import-local-files.md index 3e5e9de1762df..795bf4ff09998 100644 --- a/tidb-cloud/tidb-cloud-import-local-files.md +++ b/tidb-cloud/tidb-cloud-import-local-files.md @@ -72,7 +72,7 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする 7. 必要に応じて CSV 構成を編集します。 - **「CSV設定の編集」を**クリックすると、バックスラッシュエスケープ、セパレーター、区切り文字を設定して、よりきめ細かな制御を行うことができます。CSV設定の詳細については、 [データのインポートのためのCSV構成](/tidb-cloud/csv-config-for-import-data.md)参照してください。 + **「CSV設定の編集」を**クリックすると、バックスラッシュエスケープ、セパレーター、区切り文字を設定して、よりきめ細かな制御を行うことができます。CSV設定の詳細については、 [データのインポートのためのCSV構成](/tidb-cloud/csv-config-for-import-data.md)を参照してください。 8. **[インポートの開始]を**クリックします。 @@ -88,7 +88,7 @@ summary: ローカル ファイルをTiDB Cloud Starter にインポートする いいえ。現在、インポート機能を使用する場合、CSV ファイルのすべての列を既存のテーブルにインポートすることしかできません。 -指定した列のみをインポートするには、MySQLクライアントを使用してTiDB Cloud Starter インスタンスに接続し、 [`LOAD DATA`](https://docs.pingcap.com/tidb/stable/sql-statement-load-data)使用してインポートする列を指定します。例： +指定した列のみをインポートするには、MySQLクライアントを使用してTiDB Cloud Starter インスタンスに接続し、 [`LOAD DATA`](https://docs.pingcap.com/tidb/stable/sql-statement-load-data)を使用してインポートする列を指定します。例： ```sql CREATE TABLE `import_test` ( @@ -108,7 +108,7 @@ LOAD DATA LOCAL INFILE 'load.txt' INTO TABLE import_test FIELDS TERMINATED BY ', ### 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)を参照してください。 +ファイルが250MiBより大きい場合は、 [TiDB Cloud CLI](/tidb-cloud/get-started-with-cli.md)を使用してファイルをインポートできます。詳細については、 [`ticloud serverless import start`](/tidb-cloud/ticloud-import-start.md)を参照してください。 あるいは、 `split [-l ${line_count}]`ユーティリティを使って複数の小さなファイルに分割することもできます（LinuxまたはmacOSのみ）。例えば、 `split -l 100000 tidb-01.csv small_files`実行すると、 `tidb-01.csv`というファイルが行長`100000`で分割され、分割後のファイルの名前は`small_files${suffix}`なります。その後、これらの小さなファイルをTiDB Cloudに1つずつインポートできます。 diff --git a/tidb-cloud/tidb-cloud-intro.md b/tidb-cloud/tidb-cloud-intro.md index f5a8e586b629b..c0490383b9503 100644 --- a/tidb-cloud/tidb-cloud-intro.md +++ b/tidb-cloud/tidb-cloud-intro.md @@ -92,7 +92,7 @@ TiDB Cloudは、以下の導入オプションを提供します。 現在、 TiDB Cloud EssentialはAWSおよびAlibaba Cloudでパブリックプレビュー版として提供されています。 - Alibaba Cloud 上のTiDB Cloud StarterとTiDB Cloud Essentialの機能比較については、 [Alibaba Cloud 上の TiDB](https://www.pingcap.com/partners/alibaba-cloud/)参照してください。 + Alibaba Cloud 上のTiDB Cloud StarterとTiDB Cloud Essentialの機能比較については、 [Alibaba Cloud 上の TiDB](https://www.pingcap.com/partners/alibaba-cloud/)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-migration-overview.md b/tidb-cloud/tidb-cloud-migration-overview.md index 44537cb403967..e568db3d80c6a 100644 --- a/tidb-cloud/tidb-cloud-migration-overview.md +++ b/tidb-cloud/tidb-cloud-migration-overview.md @@ -37,7 +37,7 @@ SQL、CSV、Parquet、またはAurora Snapshot形式のデータファイルを - ローカルCSVファイルをTiDB Cloudにインポートする - ローカルCSVファイルをTiDB Cloudにインポートできます。詳細については、 [ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)参照してください。 + ローカルCSVファイルをTiDB Cloudにインポートできます。詳細については、 [ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)を参照してください。 - サンプルデータ（SQLファイル）をTiDB Cloudにインポートする @@ -55,12 +55,12 @@ SQL、CSV、Parquet、またはAurora Snapshot形式のデータファイルを ### クラウドストレージアクセスを構成する {#configure-cloud-storage-access} -ソースデータがAmazon S3、Google Cloud Storage（GCS）バケット、Azure Blob Storageコンテナ、またはAlibaba Cloud OSSバケットに保存されている場合、 TiDB Cloudにデータをインポートまたは移行する前に、ストレージへのアクセスを設定する必要があります。詳細については、 [TiDB Cloud Starter または Essential の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)と[TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md)参照してください。 +ソースデータがAmazon S3、Google Cloud Storage（GCS）バケット、Azure Blob Storageコンテナ、またはAlibaba Cloud OSSバケットに保存されている場合、 TiDB Cloudにデータをインポートまたは移行する前に、ストレージへのアクセスを設定する必要があります。詳細については、 [TiDB Cloud Starter または Essential の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)と[TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md)を参照してください。 ### データインポートの命名規則 {#naming-conventions-for-data-import} -データを確実にインポートするには、命名規則に準拠したスキーマファイルとデータファイルを準備する必要があります。詳細については、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)参照してください。 +データを確実にインポートするには、命名規則に準拠したスキーマファイルとデータファイルを準備する必要があります。詳細については、 [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)を参照してください。 ### Amazon S3 からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング {#troubleshoot-access-denied-errors-during-data-import-from-amazon-s3} -Amazon S3からTiDB Cloudにデータをインポートする際に発生する可能性のあるアクセス拒否エラーをトラブルシューティングできます。詳細については、 [Amazon S3 からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)参照してください。 +Amazon S3からTiDB Cloudにデータをインポートする際に発生する可能性のあるアクセス拒否エラーをトラブルシューティングできます。詳細については、 [Amazon S3 からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-org-sso-authentication.md b/tidb-cloud/tidb-cloud-org-sso-authentication.md index f5c7b6906606c..241b5d1b16e00 100644 --- a/tidb-cloud/tidb-cloud-org-sso-authentication.md +++ b/tidb-cloud/tidb-cloud-org-sso-authentication.md @@ -253,15 +253,15 @@ TiDB Cloudでは、SAML認証方式はデフォルトで無効になっていま 1. ID プロバイダーで、 TiDB Cloud組織の SCIM プロビジョニングを SAML アプリ統合に追加します。 - たとえば、ID プロバイダーが Okta の場合は、 [アプリ統合に SCIM プロビジョニングを追加する](https://help.okta.com/en-us/content/topics/apps/apps_app_integration_wizard_scim.htm)参照してください。 + たとえば、ID プロバイダーが Okta の場合は、 [アプリ統合に SCIM プロビジョニングを追加する](https://help.okta.com/en-us/content/topics/apps/apps_app_integration_wizard_scim.htm)を参照してください。 2. SAML アプリ統合を ID プロバイダー内の目的のグループに割り当て、グループのメンバーがアプリ統合にアクセスして使用できるようにします。 - たとえば、ID プロバイダーが Okta の場合は、 [アプリ統合をグループに割り当てる](https://help.okta.com/en-us/content/topics/provisioning/lcm/lcm-assign-app-groups.htm)参照してください。 + たとえば、ID プロバイダーが Okta の場合は、 [アプリ統合をグループに割り当てる](https://help.okta.com/en-us/content/topics/provisioning/lcm/lcm-assign-app-groups.htm)を参照してください。 3. アイデンティティ プロバイダーからTiDB Cloudにユーザー グループをプッシュします。 - たとえば、ID プロバイダーが Okta の場合は、 [グループプッシュを管理する](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-group-push-main.htm)参照してください。 + たとえば、ID プロバイダーが Okta の場合は、 [グループプッシュを管理する](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-group-push-main.htm)を参照してください。 3. TiDB Cloudで、アイデンティティ プロバイダーからプッシュされたグループを表示します。 @@ -276,8 +276,8 @@ TiDB Cloudでは、SAML認証方式はデフォルトで無効になっていま > > グループにロールを付与すると、グループ内のすべてのメンバーにそのロールが付与されます。グループにTiDB Cloud組織に既に所属しているメンバーが含まれている場合、これらのメンバーにもグループの新しいロールが付与されます。 - 1. グループに組織ロールを付与するには、 **「組織別」を**クリックし、 **「組織ロール」**列でロールを設定します。組織ロールの権限については、 [組織の役割](/tidb-cloud/manage-user-access.md#organization-roles)参照してください。 - 2. グループにプロジェクトロールを付与するには、 **「プロジェクト別」を**クリックし、 **「プロジェクトロール」**列でロールを設定します。プロジェクトロールの権限については、 [プロジェクトの役割](/tidb-cloud/manage-user-access.md#project-roles)参照してください。 + 1. グループに組織ロールを付与するには、 **「組織別」を**クリックし、 **「組織ロール」**列でロールを設定します。組織ロールの権限については、 [組織の役割](/tidb-cloud/manage-user-access.md#organization-roles)を参照してください。 + 2. グループにプロジェクトロールを付与するには、 **「プロジェクト別」を**クリックし、 **「プロジェクトロール」**列でロールを設定します。プロジェクトロールの権限については、 [プロジェクトの役割](/tidb-cloud/manage-user-access.md#project-roles)を参照してください。 5. アイデンティティ プロバイダーでプッシュされたグループのメンバーを変更すると、これらの変更はTiDB Cloud内の対応するグループに動的に同期されます。 diff --git a/tidb-cloud/tidb-cloud-performance-reference.md b/tidb-cloud/tidb-cloud-performance-reference.md index 3f895ea131122..296ea1ae4ab38 100644 --- a/tidb-cloud/tidb-cloud-performance-reference.md +++ b/tidb-cloud/tidb-cloud-performance-reference.md @@ -5,7 +5,7 @@ summary: TiDB Cloud のパフォーマンス テスト結果を確認します # TiDB Cloudパフォーマンス リファレンス {#tidb-cloud-performance-reference} -このドキュメントでは、さまざまな TiDB クラスター スケールのパフォーマンス テスト結果を[Sysbench](https://github.com/akopytov/sysbench)提供しており、 [クラスターサイズを決定する](/tidb-cloud/size-your-cluster.md)実行する際の参考として使用できます。 +このドキュメントでは、さまざまな TiDB クラスター スケールのパフォーマンス テスト結果を[Sysbench](https://github.com/akopytov/sysbench)提供しており、 [クラスターサイズを決定する](/tidb-cloud/size-your-cluster.md)を実行する際の参考として使用できます。 > **注記：** > diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index e4e4e7a95c311..254ce7ec5cc50 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -80,23 +80,23 @@ PoC 用の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-d クラスターを作成する前に、キャパシティプランニングを実施してクラスターのサイズを決定することをお勧めします。TiDB、TiKV、またはTiFlashノードの概算数から開始し、パフォーマンス要件に合わせて後からクラスターをスケールアウトすることも可能です。詳細については、以下のドキュメントをご覧いただくか、サポートチームにお問い合わせください。 -- 推定の実践の詳細については、 [TiDBのサイズ](/tidb-cloud/size-your-cluster.md)参照してください。 +- 推定の実践の詳細については、 [TiDBのサイズ](/tidb-cloud/size-your-cluster.md)を参照してください。 - 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)参照してください。 +- スケーリングの詳細については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)を参照してください。 -専用のPoCクラスターを作成したら、データをロードして一連のテストを実行する準備が整います。TiDBクラスターへの接続方法については、 [TiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。 +専用のPoCクラスターを作成したら、データをロードして一連のテストを実行する準備が整います。TiDBクラスターへの接続方法については、 [TiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 新しく作成されたクラスターの場合は、次の構成に注意してください。 - デフォルトのタイムゾーン（ダッシュボードの**「作成時間」**列）はUTCです。以下の手順[ローカルタイムゾーンを設定する](/tidb-cloud/manage-user-access.md#set-the-time-zone-for-your-organization)で、ローカルタイムゾーンに変更できます。 -- 新しいクラスタのデフォルトのバックアップ設定は、毎日データベース全体のバックアップです。希望するバックアップ時間を指定するか、手動でデータをバックアップすることもできます。デフォルトのバックアップ時間および詳細については、 [TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 +- 新しいクラスタのデフォルトのバックアップ設定は、毎日データベース全体のバックアップです。希望するバックアップ時間を指定するか、手動でデータをバックアップすることもできます。デフォルトのバックアップ時間および詳細については、 [TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を参照してください。 ## ステップ4. スキーマとSQLを適応させる {#step-4-adapt-your-schemas-and-sql} 次に、テーブルやインデックスを含むデータベース スキーマを TiDB クラスターにロードできます。 -PoC クレジットの数量には限りがあるため、クレジットの価値を最大化するために、 TiDB Cloudで互換性テストや予備分析用の[TiDB Cloud Starter クラスター](/tidb-cloud/select-cluster-tier.md#starter)作成することをお勧めします。 +PoC クレジットの数量には限りがあるため、クレジットの価値を最大化するために、 TiDB Cloudで互換性テストや予備分析用の[TiDB Cloud Starter クラスター](/tidb-cloud/select-cluster-tier.md#starter)を作成することをお勧めします。 TiDB CloudはMySQL 8.0との互換性が非常に高くなっています。MySQLと互換性がある、またはMySQLと互換性を持たせることができる場合は、データをTiDBに直接インポートできます。 @@ -139,14 +139,14 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます これで環境の作成、スキーマの調整、データのインポートが完了しました。次はワークロードをテストしましょう。 -ワークロードをテストする前に、必要に応じてデータベースを元の状態に復元できるように、手動バックアップを実行することを検討してください。詳細については、 [TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 +ワークロードをテストする前に、必要に応じてデータベースを元の状態に復元できるように、手動バックアップを実行することを検討してください。詳細については、 [TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を参照してください。 ワークロードを開始した後、次の方法を使用してシステムを観察できます。 -- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。1 [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)参照してください。 -- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。5 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 -- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)参照してください。 -- これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。1 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)参照してください。 +- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。1 [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)を参照してください。 +- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。5 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)を参照してください。 +- クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)を参照してください。 +- これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。1 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)を参照してください。 次はテスト結果を評価する時です。 @@ -184,7 +184,7 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます - バックアップ - ベンダーロックインを回避するには、毎日フルバックアップを実行してデータを新しいクラスタに移行し、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)使用してデータをエクスポートします。詳細については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)と[TiDB Cloud StarterまたはEssentialでデータをバックアップおよび復元する](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 + ベンダーロックインを回避するには、毎日フルバックアップを実行してデータを新しいクラスタに移行し、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)を使用してデータをエクスポートします。詳細については、 [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)と[TiDB Cloud StarterまたはEssentialでデータをバックアップおよび復元する](/tidb-cloud/backup-and-restore-serverless.md)を参照してください。 ## ステップ8. 環境をクリーンアップしてPoCを完了する {#step-8-clean-up-the-environment-and-finish-the-poc} diff --git a/tidb-cloud/tidb-cloud-quickstart.md b/tidb-cloud/tidb-cloud-quickstart.md index d7423c64fd61f..2ce6ef5fe61f6 100644 --- a/tidb-cloud/tidb-cloud-quickstart.md +++ b/tidb-cloud/tidb-cloud-quickstart.md @@ -146,8 +146,8 @@ MySQL CLI クライアントが開き、{{{ .starter }}} インスタンスに ## 次は何か {#what-s-next} -- さまざまな方法を使用してクラスターに接続する方法については、 [TiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-to-tidb-cluster-serverless.md)参照してください。 -- SQL エディターと Chat2Query を使用してデータを探索する方法の詳細については、 [AI支援SQLエディターでデータを探索](/tidb-cloud/explore-data-with-chat2query.md)参照してください。 -- TiDB SQL の使用法については、 [TiDB で SQL を探索する](/basic-sql-operations.md)参照してください。 -- ゾーン間の高可用性、水平スケーリング、および[HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing)利点を備えた本番で使用する場合は、 [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 -- TiDB Cloud CLIを使用してインスタンスを管理する方法については、 [TiDB Cloud CLI Reference (PREVIEW)](/tidb-cloud/cli-reference.md)参照してください。 +- さまざまな方法を使用してクラスターに接続する方法については、 [TiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-to-tidb-cluster-serverless.md)を参照してください。 +- SQL エディターと Chat2Query を使用してデータを探索する方法の詳細については、 [AI支援SQLエディターでデータを探索](/tidb-cloud/explore-data-with-chat2query.md)を参照してください。 +- TiDB SQL の使用法については、 [TiDB で SQL を探索する](/basic-sql-operations.md)を参照してください。 +- ゾーン間の高可用性、水平スケーリング、および[HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing)利点を備えた本番で使用する場合は、 [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 +- TiDB Cloud CLIを使用してインスタンスを管理する方法については、 [TiDB Cloud CLI Reference (PREVIEW)](/tidb-cloud/cli-reference.md)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index 18963682c660d..d18371f03825a 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -16,7 +16,7 @@ SQL文のパフォーマンスを向上させるには、以下の原則を考 - スキャン対象データの範囲を最小限に抑えましょう。常に、必要最小限のデータのみをスキャンし、すべてのデータをスキャンすることは避けるのが最善策です。 - 適切なインデックスを使用してください。SQL文の`WHERE`句の各列には、対応するインデックスが存在することを確認してください。そうでない場合、 `WHERE`句はテーブル全体をスキャンするため、パフォーマンスが低下します。 -- 適切な結合タイプを使用してください。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。一般に、TiDB のコストベースのオプティマイザーは、最適な結合タイプを自動的に選択します。ただし、場合によっては、結合タイプを手動で指定する必要がある場合があります。詳細については、[テーブル結合を使用するステートメントについて説明します](/explain-joins.md)参照してください。 +- 適切な結合タイプを使用してください。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。一般に、TiDB のコストベースのオプティマイザーは、最適な結合タイプを自動的に選択します。ただし、場合によっては、結合タイプを手動で指定する必要がある場合があります。詳細については、[テーブル結合を使用するステートメントについて説明します](/explain-joins.md)を参照してください。 - 適切なストレージエンジンを使用してください。ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードには、 TiFlashストレージエンジンを使用することをお勧めします。HTAP [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)を参照してください。 TiDB Cloudには、スロークエリを分析するのに役立つツールがいくつか用意されています。以下のセクションでは、スロークエリを最適化するためのいくつかの方法について説明します。 @@ -37,7 +37,7 @@ TiDB Cloudコンソールには、 [**診断**](/tidb-cloud/tune-performance.md# ![Details1](/media/dashboard/dashboard-statement-detail1.png) -- 実行プランの詳細：選択した実行プランの詳細を表示します。各SQLタイプの実行プランと、複数の視点からの対応する実行時間を収集し、より多くの情報を取得するのに役立ちます。 [実行計画](https://docs.pingcap.com/tidb/stable/dashboard-statement-details#execution-plans)参照してください。 +- 実行プランの詳細：選択した実行プランの詳細を表示します。各SQLタイプの実行プランと、複数の視点からの対応する実行時間を収集し、より多くの情報を取得するのに役立ちます。 [実行計画](https://docs.pingcap.com/tidb/stable/dashboard-statement-details#execution-plans)を参照してください。 ![Details2](/media/dashboard/dashboard-statement-detail2.png) @@ -47,15 +47,15 @@ TiDB Cloudコンソールには、 [**診断**](/tidb-cloud/tune-performance.md# ### 実行計画を確認する {#check-the-execution-plan} -[`EXPLAIN`](/explain-overview.md)使用すると、コンパイル時にTiDBが計算したステートメントの実行プランを確認できます。つまり、TiDBは数百または数千もの実行プランを推定し、リソース消費が最も少なく、実行速度が最も速い最適な実行プランを選択します。 +[`EXPLAIN`](/explain-overview.md)を使用すると、コンパイル時にTiDBが計算したステートメントの実行プランを確認できます。つまり、TiDBは数百または数千もの実行プランを推定し、リソース消費が最も少なく、実行速度が最も速い最適な実行プランを選択します。 -TiDBによって選択された実行プランが最適でない場合は、 EXPLAINまたは[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)使用して診断できます。 +TiDBによって選択された実行プランが最適でない場合は、 EXPLAINまたは[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)を使用して診断できます。 ### 実行計画を最適化する {#optimize-the-execution-plan} -`parser`による元のクエリテキストの解析と基本的な妥当性検証の後、TiDB はまずクエリに対して論理的に同等の変更を行います。詳細については、 [SQL論理最適化](/sql-logical-optimization.md)参照してください。 . +`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)を提供しています。 @@ -73,7 +73,7 @@ SQLクエリが遅くなる最も一般的な原因は、 `SELECT`ステート ### 主キーを選択する際のDDLのベストプラクティス {#ddl-best-practices-when-selecting-primary-keys} -[主キーを選択する際に従うべきガイドライン](/develop/dev-guide-create-table.md#guidelines-to-follow-when-selecting-primary-key)参照してください。 +[主キーを選択する際に従うべきガイドライン](/develop/dev-guide-create-table.md#guidelines-to-follow-when-selecting-primary-key)を参照してください。 ### インデックスのベストプラクティス {#index-best-practices} @@ -99,7 +99,7 @@ SQLパフォーマンスチューニングを行ってもパフォーマンス ### トランザクションの競合 {#transaction-conflicts} -トランザクションの競合を特定して解決する方法の詳細については、 [ロックの競合をトラブルシューティングする](https://docs.pingcap.com/tidb/stable/troubleshoot-lock-conflicts#troubleshoot-lock-conflicts)参照してください。 +トランザクションの競合を特定して解決する方法の詳細については、 [ロックの競合をトラブルシューティングする](https://docs.pingcap.com/tidb/stable/troubleshoot-lock-conflicts#troubleshoot-lock-conflicts)を参照してください。 diff --git a/tidb-cloud/tidb-cloud-sso-authentication.md b/tidb-cloud/tidb-cloud-sso-authentication.md index 20fb4046390e3..f8c2c3ad42b8e 100644 --- a/tidb-cloud/tidb-cloud-sso-authentication.md +++ b/tidb-cloud/tidb-cloud-sso-authentication.md @@ -11,7 +11,7 @@ TiDB Cloudは、Google、GitHub、MicrosoftアカウントのSSO認証をサポ > **注記：** > -> ユーザー名とパスワードを使用してTiDB Cloudにログインする場合は、 [パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)参照してください。 +> ユーザー名とパスワードを使用してTiDB Cloudにログインする場合は、 [パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)を参照してください。 ## Google SSOでログイン {#sign-in-with-google-sso} diff --git a/tidb-cloud/tidb-cloud-support.md b/tidb-cloud/tidb-cloud-support.md index 83b639d3357bb..e6ea0a7e963f4 100644 --- a/tidb-cloud/tidb-cloud-support.md +++ b/tidb-cloud/tidb-cloud-support.md @@ -130,7 +130,7 @@ TiDB Cloudは、デフォルトで無料の基本サポートプランを提供 3. **「クレジットカードを追加してアップグレード」**をクリックし、**クレジットカードの**詳細を入力します。 - 課金の詳細については、 [TiDB Cloud支払い方法](/tidb-cloud/tidb-cloud-billing.md#payment-method)参照してください。 + 課金の詳細については、 [TiDB Cloud支払い方法](/tidb-cloud/tidb-cloud-billing.md#payment-method)を参照してください。 4. ページの右下にある**「カードを保存」**をクリックします。 diff --git a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md index 1db04a06a8f5c..abf39a2f1b4f5 100644 --- a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md +++ b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md @@ -28,7 +28,7 @@ TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスタへの 3. 接続ダイアログで、 **[接続タイプ]**ドロップダウン リストから**[パブリック]**を選択します。 - IPアクセスリストを設定していない場合は、初回接続前に**「IPアクセスリストの設定**」をクリックして設定してください。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 + IPアクセスリストを設定していない場合は、初回接続前に**「IPアクセスリストの設定**」をクリックして設定してください。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 4. **「CA証明書」**をクリックして、TiDBクラスタへのTLS接続用のCA証明書をダウンロードしてください。CA証明書はデフォルトでTLS 1.2バージョンをサポートしています。 @@ -60,7 +60,7 @@ mysql --connect-timeout 15 --ssl-mode=VERIFY_IDENTITY --ssl-ca=ca.pem --tls-vers
-[mycli](https://www.mycli.net/)指定すると、TLS関連のパラメータを使用する際にTLSが自動的に有効になります。TiDB Cloud Dedicatedクラスタに接続する場合は、 `ssl-ca`と`ssl-verify-server-cert`設定する必要があります。 +[mycli](https://www.mycli.net/)を指定すると、TLS関連のパラメータを使用する際にTLSが自動的に有効になります。TiDB Cloud Dedicatedクラスタに接続する場合は、 `ssl-ca`と`ssl-verify-server-cert`設定する必要があります。 ```shell mycli --ssl-ca=ca.pem --ssl-verify-server-cert -u root -h tidb.eqlfbdgthh8.clusters.staging.tidb-cloud.com -P 4000 -D test diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index 951813bbbc778..6963ff99ad50d 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -44,7 +44,7 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ - [**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) : - - **SQL文を**使用すると、ページ上のSQL実行を直接観察し、システムテーブルをクエリすることなくパフォーマンスの問題を簡単に特定できます。SQL文をクリックすると、クエリの実行プランをさらに詳しく表示して、トラブルシューティングや分析を行うことができます。SQLパフォーマンスチューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)参照してください。 + - **SQL文を**使用すると、ページ上のSQL実行を直接観察し、システムテーブルをクエリすることなくパフォーマンスの問題を簡単に特定できます。SQL文をクリックすると、クエリの実行プランをさらに詳しく表示して、トラブルシューティングや分析を行うことができます。SQLパフォーマンスチューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)を参照してください。 - **Key Visualizer を**使用すると、TiDB のデータ アクセス パターンとデータ ホットスポットを観察できます。 - [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) : このページでは、リクエスト単位、使用済みストレージサイズ、1 秒あたりのクエリ数、平均クエリ実行時間などのメトリックを表示できます。 @@ -75,7 +75,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 5525c8afdc04a..2ac24f2beac0e 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -5,7 +5,7 @@ summary: ビジネス ワークロードを分離するために TiDB ノード # TiDBノードグループの管理 {#manage-tidb-node-groups} -このドキュメントでは、 [TiDB Cloudコンソール](https://tidbcloud.com/)使用してビジネス ワークロードを分離するために、TiDB ノード グループとそのエンドポイントを管理する方法について説明します。 +このドキュメントでは、 [TiDB Cloudコンソール](https://tidbcloud.com/)を使用してビジネス ワークロードを分離するために、TiDB ノード グループとそのエンドポイントを管理する方法について説明します。 > **注記**： > @@ -85,7 +85,7 @@ TiDBノードグループを作成しても、デフォルトグループのエ ![Connect to the new TiDB node group via Public Endpoint](/media/tidb-cloud/tidb-node-group-connect-public-endpoint.png) -詳細については[パブリック接続経由でTiDB Cloud Dedicated に接続](/tidb-cloud/connect-via-standard-connection.md)参照してください。 +詳細については[パブリック接続経由でTiDB Cloud Dedicated に接続](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 ### プライベートエンドポイント経由で接続 {#connect-via-private-endpoint} diff --git a/tidb-cloud/tiproxy-management.md b/tidb-cloud/tiproxy-management.md index a0e72dbecef4e..9358f22a1466a 100644 --- a/tidb-cloud/tiproxy-management.md +++ b/tidb-cloud/tiproxy-management.md @@ -54,7 +54,7 @@ TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスタのQPS - TiDBノードグループには、少なくとも2つのTiDBノードが必要です。 - TiDBノードのサイズは、少なくとも4つのvCPUである必要があります。 -- 組織内の TiProxy ノードのデフォルトの最大数は`10`です。詳細については、[制限と割り当て](/tidb-cloud/limitations-and-quotas.md)参照してください。 +- 組織内の TiProxy ノードのデフォルトの最大数は`10`です。詳細については、[制限と割り当て](/tidb-cloud/limitations-and-quotas.md)を参照してください。 - TiDBクラスタのバージョンはv6.5.0以降である必要があります。 ## TiProxyを無効にする {#disable-tiproxy} @@ -96,7 +96,7 @@ TiProxyのメトリクスを表示するには、以下の手順を実行して - **TiProxyのCPU使用率**：各TiProxyノードのCPU使用率統計情報。上限は100%です。CPU使用率が80%を超える場合は、TiProxyのスケールアウトをお勧めします。 - **TiProxy接続数**：各TiProxyノード上の接続数。 - **TiProxy スループット**: 各 TiProxy ノードで 1 秒あたりに転送されるバイト数。最大スループットが最大ネットワーク帯域幅に達した場合は、TiProxy をスケールアウトすることをお勧めします。最大ネットワーク帯域幅の詳細については、 [TiProxyノードのサイズと数を決定する](#decide-the-size-and-number-of-tiproxy-nodes)参照してください。 -- **TiProxyセッション移行の理由**：1分ごとに発生するセッション移行の数とその理由。たとえば、TiDBがスケールインし、TiProxyがセッションを他のTiDBノードに移行する場合、理由は`status`です。その他の移行理由については、 [TiProxyのモニタリング指標](https://docs.pingcap.com/tidb/stable/tiproxy-grafana#balance)参照してください。 +- **TiProxyセッション移行の理由**：1分ごとに発生するセッション移行の数とその理由。たとえば、TiDBがスケールインし、TiProxyがセッションを他のTiDBノードに移行する場合、理由は`status`です。その他の移行理由については、 [TiProxyのモニタリング指標](https://docs.pingcap.com/tidb/stable/tiproxy-grafana#balance)を参照してください。 ### TiProxyの請求書を確認する {#view-tiproxy-bills} diff --git a/tidb-cloud/tiproxy-overview-for-cloud.md b/tidb-cloud/tiproxy-overview-for-cloud.md index 7faa3fdc62aae..bec283301e54a 100644 --- a/tidb-cloud/tiproxy-overview-for-cloud.md +++ b/tidb-cloud/tiproxy-overview-for-cloud.md @@ -19,7 +19,7 @@ TiProxyは、以下のシナリオに適しています。 - 接続の維持：TiDBサーバーがスケールイン、ローリングアップグレード、またはローリング再起動を実行すると、クライアント接続が切断され、エラーが発生します。クライアントに冪等なエラー再試行メカニズムがない場合、エラーを手動で確認して修正する必要があり、運用上のオーバーヘッドが大幅に増加します。TiProxyはクライアント接続を維持できるため、クライアントはエラーを報告しません。 - 頻繁なスケールインとスケールアウト：アプリケーションのワークロードは定期的に変化する可能性があります。コストを削減するために、TiDBをクラウドにデプロイし、ワークロードに応じてTiDBサーバーを自動的にスケールインおよびスケールアウトすることができます。ただし、スケールインによってクライアントが切断される可能性があり、スケールアウトによって負荷が不均衡になる可能性があります。TiProxyはクライアント接続を維持し、負荷分散を実現できます。 -- CPU負荷の不均衡：バックグラウンドタスクが大量のCPUリソースを消費したり、接続間のワークロードが大きく変動してCPU負荷が不均衡になった場合、TiProxyはCPU使用率に基づいて接続を移行して負荷分散を実現できます。詳細については、 [CPUベースの負荷分散](https://docs.pingcap.com/tidb/stable/tiproxy-load-balance#cpu-based-load-balancing)参照してください。 +- CPU負荷の不均衡：バックグラウンドタスクが大量のCPUリソースを消費したり、接続間のワークロードが大きく変動してCPU負荷が不均衡になった場合、TiProxyはCPU使用率に基づいて接続を移行して負荷分散を実現できます。詳細については、 [CPUベースの負荷分散](https://docs.pingcap.com/tidb/stable/tiproxy-load-balance#cpu-based-load-balancing)を参照してください。 その他のシナリオについては、 [TiProxyのユーザーシナリオ](https://docs.pingcap.com/tidb/stable/tiproxy-overview#user-scenarios)を参照してください。 @@ -40,7 +40,7 @@ TiProxyでは、2種類のコストが導入されています。 - ノードのコスト。詳細については、 [ノードコスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#node-cost)を参照してください。 - データ転送コスト。詳細については、 [データ転送コスト](https://www.pingcap.com/tidb-dedicated-pricing-details/#data-transfer-cost)を参照してください。TiProxy は、同じアベイラビリティゾーン (AZ) 内の TiDB ノードへのトラフィックルーティングを優先します。ただし、TiDB のワークロードが不均一な場合は、他の AZ にもトラフィックをルーティングするため、追加のデータ転送コストが発生する可能性があります。 -TiProxy の請求書は、 **[請求]**ページで確認できます。詳細については、 [TiProxyの請求書を確認する](/tidb-cloud/tiproxy-management.md#view-tiproxy-bills)参照してください。 +TiProxy の請求書は、 **[請求]**ページで確認できます。詳細については、 [TiProxyの請求書を確認する](/tidb-cloud/tiproxy-management.md#view-tiproxy-bills)を参照してください。 ## SLAへの影響 {#sla-impact} diff --git a/tidb-cloud/transaction-concepts.md b/tidb-cloud/transaction-concepts.md index 79a62d2934ca8..b6e9d93778989 100644 --- a/tidb-cloud/transaction-concepts.md +++ b/tidb-cloud/transaction-concepts.md @@ -13,7 +13,7 @@ TiDBの楽観的トランザクションモデルは、コミットフェーズ データベースをカウンターとして使用する場合を考えてみましょう。同時アクセス数が多いと深刻な競合が発生し、複数回の再試行やタイムアウトが発生する可能性があります。したがって、深刻な競合が発生するシナリオでは、悲観的トランザクションモードを使用するか、Redisにカウンターを配置するなど、システムアーキテクチャレベルで問題を解決することをお勧めします。ただし、アクセス競合がそれほど深刻でない場合は、楽観的トランザクションモデルが効率的です。 -詳細については[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)参照してください。 +詳細については[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 ## 悲観的なトランザクションモード {#pessimistic-transaction-mode} @@ -21,7 +21,7 @@ TiDBでは、悲観的トランザクションモードはMySQLとほぼ同じ ただし、アプリケーション シナリオの競合が少ない場合は、楽観的トランザクション モデルの方がパフォーマンスが向上します。 -詳細については[TiDB 悲観的トランザクションモード](/pessimistic-transaction.md)参照してください。 +詳細については[TiDB 悲観的トランザクションモード](/pessimistic-transaction.md)を参照してください。 ## トランザクション分離レベル {#transaction-isolation-levels} @@ -29,7 +29,7 @@ TiDBでは、悲観的トランザクションモードはMySQLとほぼ同じ TiDBはスナップショット分離（SI）一貫性を実装しており、MySQLとの互換性のために`REPEATABLE-READ`として宣伝されています。これはSI [ANSI繰り返し読み取り分離レベル](/transaction-isolation-levels.md#difference-between-tidb-and-ansi-repeatable-read)やSI [MySQL 繰り返し読み取りレベル](/transaction-isolation-levels.md#difference-between-tidb-and-mysql-repeatable-read)とは異なります。 -詳細については[TiDBトランザクション分離レベル](/transaction-isolation-levels.md)参照してください。 +詳細については[TiDBトランザクション分離レベル](/transaction-isolation-levels.md)を参照してください。 ## 非トランザクションDMLステートメント {#non-transactional-dml-statements} @@ -37,4 +37,4 @@ TiDBはスナップショット分離（SI）一貫性を実装しており、My 通常、メモリを大量に消費するトランザクションは、トランザクションサイズ制限を回避するために複数のSQL文に分割する必要があります。非トランザクションDML文は、このプロセスをTiDBカーネルに統合することで、同様の効果を実現します。SQL文を分割することで、非トランザクションDML文の効果を理解するのに役立ちます`DRY RUN`構文を使用すると、分割された文をプレビューできます。 -詳細については[非トランザクションDML文](/non-transactional-dml.md)参照してください。 +詳細については[非トランザクションDML文](/non-transactional-dml.md)を参照してください。 diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index 1668cb5c3de3b..a1bf4d769d627 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -102,7 +102,7 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し }, } -ユーザーに権限を付与してテストする方法の詳細については、 [ユーザーポリシーによるバケットへのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html)参照してください。 +ユーザーに権限を付与してテストする方法の詳細については、 [ユーザーポリシーによるバケットへのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html)を参照してください。 ### IAMロールのポリシーを確認する {#check-the-policy-of-the-iam-role} @@ -224,4 +224,4 @@ S3バケットを暗号化する方法は複数あります。バケット内の ### 手順についてはAWSの記事を確認してください {#check-the-aws-article-for-instruction} -上記のすべてのチェックを実行してもエラー`AccessDenied`が発生する場合は、詳細な手順については AWS の記事[Amazon S3 からの 403 アクセス拒否エラーをトラブルシューティングするにはどうすればいいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-403/)確認してください。 +上記のすべてのチェックを実行してもエラー`AccessDenied`が発生する場合は、詳細な手順については AWS の記事[Amazon S3 からの 403 アクセス拒否エラーをトラブルシューティングするにはどうすればいいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-403/)を確認してください。 diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index ebd41f0445ddb..0c1e50e396150 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -111,7 +111,7 @@ TiDB Cloudデータ サービスは、次の Chat2Query v3 エンドポイント | 置く | `/v3/dataSummaries/{data_summary_id}` | このエンドポイントは、特定のデータ サマリーを更新します。 | | 置く | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}` | このエンドポイントは、特定のデータ サマリー内の特定のテーブルの説明を更新します。 | | 置く | `/v3/dataSummaries/{data_summary_id}/tables/{table_name}/columns` | このエンドポイントは、特定のデータ サマリー内の特定のテーブルの列の説明を更新します。 | -| 役職 | `/v3/knowledgeBases` | このエンドポイントは新しいナレッジベースを作成します。ナレッジベース関連のエンドポイントの使用方法の詳細については、 [ナレッジベースを活用する](/tidb-cloud/use-chat2query-knowledge.md)参照してください。 | +| 役職 | `/v3/knowledgeBases` | このエンドポイントは新しいナレッジベースを作成します。ナレッジベース関連のエンドポイントの使用方法の詳細については、 [ナレッジベースを活用する](/tidb-cloud/use-chat2query-knowledge.md)を参照してください。 | | 得る | `/v3/knowledgeBases` | このエンドポイントはすべてのナレッジ ベースを取得します。 | | 得る | `/v3/knowledgeBases/{knowledge_base_id}` | このエンドポイントは、特定のナレッジ ベースを取得します。 | | 置く | `/v3/knowledgeBases/{knowledge_base_id}` | このエンドポイントは、特定のナレッジ ベースを更新します。 | @@ -119,7 +119,7 @@ TiDB Cloudデータ サービスは、次の Chat2Query v3 エンドポイント | 得る | `/v3/knowledgeBases/{knowledge_base_id}/data` | このエンドポイントは、特定のナレッジ ベースからデータを取得します。 | | 置く | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | このエンドポイントは、ナレッジ ベース内の特定のデータを更新します。 | | 削除 | `/v3/knowledgeBases/{knowledge_base_id}/data/{knowledge_data_id}` | このエンドポイントは、ナレッジ ベースから特定のデータを削除します。 | -| 役職 | `/v3/sessions` | このエンドポイントは新しいセッションを作成します。セッション関連のエンドポイントの使用方法の詳細については、 [マルチラウンドChat2Queryを開始する](/tidb-cloud/use-chat2query-sessions.md)参照してください。 | +| 役職 | `/v3/sessions` | このエンドポイントは新しいセッションを作成します。セッション関連のエンドポイントの使用方法の詳細については、 [マルチラウンドChat2Queryを開始する](/tidb-cloud/use-chat2query-sessions.md)を参照してください。 | | 得る | `/v3/sessions` | このエンドポイントは、すべてのセッションのリストを取得します。 | | 得る | `/v3/sessions/{session_id}` | このエンドポイントは、特定のセッションの詳細を取得します。 | | 置く | `/v3/sessions/{session_id}` | このエンドポイントは特定のセッションを更新します。 | diff --git a/tidb-cloud/use-chat2query-knowledge.md b/tidb-cloud/use-chat2query-knowledge.md index 3fb7ddd9c60cf..1495031f45702 100644 --- a/tidb-cloud/use-chat2query-knowledge.md +++ b/tidb-cloud/use-chat2query-knowledge.md @@ -32,7 +32,7 @@ Chat2Queryデータアプリでは、エンドポイント`/v3/knowledgeBases` > **ヒント：** > -> エンドポイントの具体的なコード例を取得するには、データアプリの左側のペインでエンドポイント名をクリックし、 **「コード例を表示」**をクリックします。詳細については、 [エンドポイントのサンプルコードを取得する](/tidb-cloud/use-chat2query-api.md#get-the-code-example-of-an-endpoint)参照してください。 +> エンドポイントの具体的なコード例を取得するには、データアプリの左側のペインでエンドポイント名をクリックし、 **「コード例を表示」**をクリックします。詳細については、 [エンドポイントのサンプルコードを取得する](/tidb-cloud/use-chat2query-api.md#get-the-code-example-of-an-endpoint)を参照してください。 ```bash curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/knowledgeBases'\ diff --git a/tidb-cloud/use-chat2query-sessions.md b/tidb-cloud/use-chat2query-sessions.md index ec44cc74c158f..53b39994a6530 100644 --- a/tidb-cloud/use-chat2query-sessions.md +++ b/tidb-cloud/use-chat2query-sessions.md @@ -23,7 +23,7 @@ Chat2Query API v3以降では、セッション関連のエンドポイントを > **ヒント：** > -> エンドポイントの具体的なコード例を取得するには、データアプリの左側のペインでエンドポイント名をクリックし、 **「コード例を表示」**をクリックします。詳細については、 [エンドポイントのサンプルコードを取得する](/tidb-cloud/use-chat2query-api.md#get-the-code-example-of-an-endpoint)参照してください。 +> エンドポイントの具体的なコード例を取得するには、データアプリの左側のペインでエンドポイント名をクリックし、 **「コード例を表示」**をクリックします。詳細については、 [エンドポイントのサンプルコードを取得する](/tidb-cloud/use-chat2query-api.md#get-the-code-example-of-an-endpoint)を参照してください。 ```bash curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://.data.tidbcloud.com/api/v1beta/app/chat2query-/endpoint/v3/sessions'\ @@ -98,4 +98,4 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https://eu-cen } ``` -レスポンスはエンドポイント`/v3/chat2data`のレスポンスと同様です。エンドポイント`/v2/jobs/{job_id}`呼び出すことでジョブのステータスを確認できます。詳細については、エンド[`/v2/jobs/{job_id}`を呼び出して分析ステータスを確認します](/tidb-cloud/use-chat2query-api.md#2-check-the-analysis-status-by-calling-v2jobsjob_id)参照してください。 +レスポンスはエンドポイント`/v3/chat2data`のレスポンスと同様です。エンドポイント`/v2/jobs/{job_id}`呼び出すことでジョブのステータスを確認できます。詳細については、エンド[`/v2/jobs/{job_id}`を呼び出して分析ステータスを確認します](/tidb-cloud/use-chat2query-api.md#2-check-the-analysis-status-by-calling-v2jobsjob_id)を参照してください。 diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md index 02575a6e778e0..cd306584bc9e8 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-sysbench.md @@ -41,11 +41,11 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `sbtest`データベースを作成するには、次の SQL ステートメントを実行します。 @@ -55,7 +55,7 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 3. Sysbench データを`sbtest`データベースにロードします。 - 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 + 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 diff --git a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md index 5daacd14614b2..32c700c039d7c 100644 --- a/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v6.5-performance-benchmarking-with-tpcc.md @@ -40,11 +40,11 @@ summary: TiDB バージョン v6.5.6 を使用したTiDB Cloud Dedicated クラ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `tpcc`データベースを作成するには、次の SQL ステートメントを実行します。 diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md index a6d311d6c3f5d..bff320b8b3365 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-sysbench.md @@ -34,7 +34,7 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-sysbench'] > > TiDB Cloudの場合、クラスターの TiKV パラメータを変更するには、 [PingCAP サポート](/tidb-cloud/tidb-cloud-support.md)問い合わせてサポートを受けることができます。 -TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 +TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)を指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 - `oltp_point_select`ワークロードの場合、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータのデフォルト値を使用します。 @@ -62,11 +62,11 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `sbtest`データベースを作成するには、次の SQL ステートメントを実行します。 @@ -76,7 +76,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 3. Sysbench データを`sbtest`データベースにロードします。 - 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 + 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 diff --git a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md index e9575f4d31436..b328d33fce6cb 100644 --- a/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.1-performance-benchmarking-with-tpcc.md @@ -41,11 +41,11 @@ aliases: ['/ja/tidbcloud/v7.1.0-performance-benchmarking-with-tpcc'] 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `tpcc`データベースを作成するには、次の SQL ステートメントを実行します。 diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md index 0527cc29ff14c..afb78437c8293 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-sysbench.md @@ -34,7 +34,7 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-sysbench'] > > TiDB Cloudの場合、クラスターの TiKV パラメータを変更するには、 [PingCAP サポート](/tidb-cloud/tidb-cloud-support.md)問い合わせてサポートを受けることができます。 -TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 +TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)を指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 - `oltp_point_select`ワークロードの場合、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータのデフォルト値を使用します。 @@ -62,11 +62,11 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `sbtest`データベースを作成するには、次の SQL ステートメントを実行します。 @@ -76,7 +76,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 3. Sysbench データを`sbtest`データベースにロードします。 - 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 + 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 diff --git a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md index 5421626304f9d..e8086e6723427 100644 --- a/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v7.5-performance-benchmarking-with-tpcc.md @@ -41,11 +41,11 @@ aliases: ['/ja/tidbcloud/v7.5.0-performance-benchmarking-with-tpcc'] 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `tpcc`データベースを作成するには、次の SQL ステートメントを実行します。 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md index 1e6cc6415d174..142698e60dd03 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-sysbench.md @@ -39,7 +39,7 @@ SET GLOBAL tidb_session_plan_cache_size = 1000; > > TiDB Cloudの場合、クラスターの TiKV パラメータを変更するには、 [PingCAP サポート](/tidb-cloud/tidb-cloud-support.md)問い合わせてサポートを受けることができます。 -TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 +TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)を指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 - `oltp_point_select`ワークロードの場合、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータのデフォルト値を使用します。 @@ -67,11 +67,11 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `sbtest`データベースを作成するには、次の SQL ステートメントを実行します。 @@ -81,7 +81,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 3. Sysbench データを`sbtest`データベースにロードします。 - 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 + 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 diff --git a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md index a4b676a81667d..28525bf40ba24 100644 --- a/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.1-performance-benchmarking-with-tpcc.md @@ -52,11 +52,11 @@ raft-engine.prefill-for-recycle = true 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `tpcc`データベースを作成するには、次の SQL ステートメントを実行します。 diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md index 049a5b2354c40..029792662643f 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-sysbench.md @@ -39,7 +39,7 @@ SET GLOBAL tidb_session_plan_cache_size = 1000; > > TiDB Cloudの場合、クラスターの TiKV パラメータを変更するには、 [PingCAP サポート](/tidb-cloud/tidb-cloud-support.md)問い合わせてサポートを受けることができます。 -TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 +TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)を指定すると、初期化直後からログのリサイクルが有効になります。このドキュメントでは、以下の`prefill-for-recycle`設定を用いて、異なるワークロードに基づいたテストを実施しています。 - `oltp_point_select`ワークロードの場合、 [`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/tikv-configuration-file#prefill-for-recycle-new-in-v700)パラメータのデフォルト値を使用します。 @@ -67,11 +67,11 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `sbtest`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `sbtest`データベースを作成するには、次の SQL ステートメントを実行します。 @@ -81,7 +81,7 @@ TiKVパラメータ[`prefill-for-recycle`](https://docs.pingcap.com/tidb/stable/ 3. Sysbench データを`sbtest`データベースにロードします。 - 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)参照してください。 + 1. このドキュメントのテストは[Sysbench](https://github.com/akopytov/sysbench)に基づいて実装されています。sysbench をインストールするには[ソースからのビルドとインストール](https://github.com/akopytov/sysbench#building-and-installing-from-source)を参照してください。 2. 以下のコマンド`sysbench prepare`を実行して、32個のテーブルと10,000,000行を`sbtest` `${PORT}`にインポート`${THREAD}`ます。5、7、9、11 `${HOST}`実際の値に置き換え`${PASSWORD}`ください。 diff --git a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md index 313fad506bf4d..a6a7fc78202cf 100644 --- a/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md +++ b/tidb-cloud/v8.5-performance-benchmarking-with-tpcc.md @@ -52,11 +52,11 @@ raft-engine.prefill-for-recycle = true 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、 [テスト環境](#tidb-cluster)要件を満たすTiDB Cloud Dedicated クラスターを作成します。 - 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 + 詳細については[TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 2. ベンチマーク エグゼキュータで、新しく作成されたクラスターに接続し、 `tpcc`名前のデータベースを作成します。 - クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + クラスターに接続するには、 [プライベートエンドポイント経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 `tpcc`データベースを作成するには、次の SQL ステートメントを実行します。 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 848642be2dbf9..56e431504bfb3 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -47,7 +47,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - TiDBが一時データを保存するために使用されるファイルシステム上の場所。機能がTiDBノード内でローカルストレージを必要とする場合、TiDBはこの場所に対応する一時データを保存します。 - インデックスを作成する際に、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)有効になっている場合、新しく作成されたインデックスのバックフィルが必要なデータは、まず TiDB のローカル一時ディレクトリに保存され、その後バッチ処理で TiKV にインポートされるため、インデックス作成が高速化されます。 -- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)使用してデータをインポートする場合、ソートされたデータはまず TiDB のローカル一時ディレクトリに保存され、その後バッチ処理で TiKV にインポートされます。 +- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してデータをインポートする場合、ソートされたデータはまず TiDB のローカル一時ディレクトリに保存され、その後バッチ処理で TiKV にインポートされます。 - デフォルト値: `"/tmp/tidb"` > **注記：** @@ -92,7 +92,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - `compatible-kill-query`が`false`の場合、TiDB での`KILL xxx`の動作は MySQL とは異なります。TiDB でクエリを強制終了するには、 `TIDB`のように`KILL TIDB xxx`キーワードを追加する必要があります。 - `compatible-kill-query`が`true`の場合、TiDB でクエリを強制終了するには、 `TIDB`キーワードを追加する必要はありません。クライアントが**常に同じ TiDB インスタンスに接続されることが確実でない限り**、構成ファイルで`compatible-kill-query`を`true`に設定することは強くお勧めしません。これは、デフォルトの MySQL クライアントでControl + Cを押すと`KILL`が実行される新しい接続が開かれるためです。クライアントと TiDB クラスタの間にプロキシがある場合、新しい接続は別の TiDB インスタンスにルーティングされる可能性があり、誤って別のセッションが強制終了される可能性があります。 - [`enable-global-kill`](#enable-global-kill-new-in-v610)が`true`の場合、 `KILL xxx`と`KILL TIDB xxx`は同じ効果を持ちます。 -- `KILL`ステートメントの詳細については、[キル [TIDB]](/sql-statements/sql-statement-kill.md)参照してください。 +- `KILL`ステートメントの詳細については、[キル [TIDB]](/sql-statements/sql-statement-kill.md)を参照してください。 ### `check-mb4-value-in-utf8` {#check-mb4-value-in-utf8} @@ -113,7 +113,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > **注記：** > -> この設定項目は非推奨となり、現在では`@tidb_enable_clustered_index`の値が`INT_ONLY`の場合にのみ有効になります。主キーを追加または削除する必要がある場合は、テーブル作成時に代わりに`NONCLUSTERED`キーワードを使用してください。 `CLUSTERED`型の主キーの詳細については、[クラスター化インデックス](/clustered-indexes.md)参照してください。 +> この設定項目は非推奨となり、現在では`@tidb_enable_clustered_index`の値が`INT_ONLY`の場合にのみ有効になります。主キーを追加または削除する必要がある場合は、テーブル作成時に代わりに`NONCLUSTERED`キーワードを使用してください。 `CLUSTERED`型の主キーの詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 ### `server-version` {#server-version} @@ -226,7 +226,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - グローバルキル（インスタンスをまたいでクエリや接続を終了する）機能を有効にするかどうかを制御します。 - デフォルト値: `true` - 値が`true`の場合、 `KILL`および`KILL TIDB`ステートメントはインスタンス間でクエリまたは接続を終了できるため、クエリまたは接続が誤って終了することを心配する必要はありません。クライアントを使用して任意の TiDB インスタンスに接続し、 `KILL`または`KILL TIDB`ステートメントを実行すると、ステートメントは対象の TiDB インスタンスに転送されます。クライアントと TiDB クラスタの間にプロキシがある場合、 `KILL`および`KILL TIDB`ステートメントも実行のために対象の TiDB インスタンスに転送されます。 -- バージョン7.3.0以降では、 `enable-global-kill`に`true`されている場合、MySQLコマンドラインのControl+Cを使用して[`enable-32bits-connection-id`](#enable-32bits-connection-id-new-in-v730)できます。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)参照してください。 +- バージョン7.3.0以降では、 `enable-global-kill`に`true`されている場合、MySQLコマンドラインのControl+Cを使用して[`enable-32bits-connection-id`](#enable-32bits-connection-id-new-in-v730)できます。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)を参照してください。 ### `enable-32bits-connection-id` v7.3.0で追加 {#enable-32bits-connection-id-new-in-v730} @@ -630,7 +630,7 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも - TiDBの起動時に軽量統計初期化を使用するかどうかを制御します。 - デフォルト値: v7.2.0 より前のバージョンでは`false` 、v7.2.0 以降のバージョンでは`true` 。 - `lite-init-stats`の値が`true`の場合、統計情報の初期化では、インデックスと列のヒストグラム、TopN、または Count-Min Sketch はメモリにロードされません。 `lite-init-stats`の値が`false`の場合、統計情報の初期化では、インデックスのヒストグラム、TopN、および Count-Min Sketch はメモリにロードされますが、主キーと列のヒストグラム、TopN、または Count-Min Sketch はメモリにロードされません。オプティマイザが特定の主キーまたは列のヒストグラム、TopN、および Count-Min Sketch を必要とする場合、必要な統計情報は同期または非同期でメモリにロードされます ( [`tidb_stats_load_sync_wait`](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540)で制御)。 -- `lite-init-stats`を`true`に設定すると、統計情報の初期化が高速化され、不要な統計情報の読み込みを回避することで TiDB のメモリ使用量が削減されます。詳細については、[負荷統計](/statistics.md#load-statistics)参照してください。 +- `lite-init-stats`を`true`に設定すると、統計情報の初期化が高速化され、不要な統計情報の読み込みを回避することで TiDB のメモリ使用量が削減されます。詳細については、[負荷統計](/statistics.md#load-statistics)を参照してください。 ### `force-init-stats` v6.5.7 および v7.1.0 で追加されました。 {#force-init-stats-new-in-v657-and-v710} diff --git a/tidb-global-sort.md b/tidb-global-sort.md index f3fbeb8ae8a60..079339fdc5dce 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -46,7 +46,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](/br/backup-and-restore-storages.md)参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](/br/backup-and-restore-storages.md)を参照してください。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' @@ -55,7 +55,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)を参照してください。 ```sql SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' diff --git a/tidb-in-kubernetes.md b/tidb-in-kubernetes.md index d9404a7288078..47e9262a015db 100644 --- a/tidb-in-kubernetes.md +++ b/tidb-in-kubernetes.md @@ -5,6 +5,6 @@ summary: Kubernetes に TiDB クラスターをデプロイする方法を学び # Kubernetes に TiDBクラスタをデプロイ {#deploy-a-tidb-cluster-on-kubernetes} -[TiDB Operator](https://github.com/pingcap/tidb-operator)使用して Kubernetes 上に TiDB クラスタをデプロイできます。TiDB Operator は、Kubernetes 上の TiDB クラスタ用の自動運用システムです。デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDB のライフサイクル全体を管理します。TiDB Operatorを使用すると、パブリッククラウドまたはプライベートクラウドにデプロイされた Kubernetes クラスタで TiDB をシームレスに実行できます。 +[TiDB Operator](https://github.com/pingcap/tidb-operator)を使用して Kubernetes 上に TiDB クラスタをデプロイできます。TiDB Operator は、Kubernetes 上の TiDB クラスタ用の自動運用システムです。デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDB のライフサイクル全体を管理します。TiDB Operatorを使用すると、パブリッククラウドまたはプライベートクラウドにデプロイされた Kubernetes クラスタで TiDB をシームレスに実行できます。 -現在、Kubernetes 上の TiDB に関するドキュメントは、TiDB のドキュメントとは独立しています。TiDB Operatorを使用して Kubernetes 上に TiDB クラスターをデプロイする詳細な手順については、 [TiDB Operatorと TiDB バージョンの関係](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview)を学習し、対応する[Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/)参照してください。 +現在、Kubernetes 上の TiDB に関するドキュメントは、TiDB のドキュメントとは独立しています。TiDB Operatorを使用して Kubernetes 上に TiDB クラスターをデプロイする詳細な手順については、 [TiDB Operatorと TiDB バージョンの関係](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview)を学習し、対応する[Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/)を参照してください。 diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 9cc0fbc460798..87b5c47aeebb9 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -95,7 +95,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - `disk-quota` : TiDB Lightningのソートディレクトリの容量がデータソースのサイズよりも大きいことを確認することをお勧めします。確保できない場合は、 `disk-quota` TiDB Lightningのソートディレクトリの容量の 80% に設定できます。これにより、 TiDB Lightning は指定された`disk-quota`に従ってデータを一括でソートして書き込みますが、この方法では完全なソート処理と比較してインポートパフォーマンスが低下する可能性があることに注意してください。 - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。インスタンスメモリの80%を`GOMEMLIMIT`に設定することで、GoのGCメカニズムによるOOMの発生確率を低減します。 -TiDB Lightningパラメータの詳細については、 [TiDB Lightning構成パラメータ](/tidb-lightning/tidb-lightning-configuration.md)参照してください。 +TiDB Lightningパラメータの詳細については、 [TiDB Lightning構成パラメータ](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 ## 「チェックサム不一致」エラーを解決する {#resolve-the-checksum-mismatch-error} @@ -130,7 +130,7 @@ TiDB Lightningパラメータの詳細については、 [TiDB Lightning構成 ### クラスタトポロジを計画する {#plan-cluster-topology} -TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10TiBのソースデータを処理できるようにします。各ノードに1つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの[環境要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)参照してください。 +TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10TiBのソースデータを処理できるようにします。各ノードに1つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの[環境要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。 ### 設定パラメータを変更する {#change-configuration-parameters} @@ -148,8 +148,8 @@ TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10 大規模な単一テーブル（たとえば、10 億行以上、50 列以上）の場合、インポートプロセス中に`analyze`操作（ `analyze="off"` ）を無効にし、インポートが完了した後に[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)ステートメントを手動で実行することをお勧めします。 -`analyze`の設定の詳細については、 [TiDB Lightningタスク構成](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)参照してください。 +`analyze`の設定の詳細については、 [TiDB Lightningタスク構成](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を参照してください。 ## トラブルシューティング {#troubleshooting} -TiDB Lightning の使用中に問題が発生した場合は、 [TiDB Lightningのトラブルシューティング](/tidb-lightning/troubleshoot-tidb-lightning.md)参照してください。 +TiDB Lightning の使用中に問題が発生した場合は、 [TiDB Lightningのトラブルシューティング](/tidb-lightning/troubleshoot-tidb-lightning.md)を参照してください。 diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 3e339ec584196..0ecf5accc73a2 100644 --- a/tidb-lightning/deploy-tidb-lightning.md +++ b/tidb-lightning/deploy-tidb-lightning.md @@ -41,6 +41,6 @@ chmod +x tidb-lightning ### TiDB Lightning のアップグレード {#upgrade-tidb-lightning} -TiDB Lightning は、追加の設定を必要とせず、バイナリのみを置き換えるだけでアップグレードできます。アップグレード後は、 TiDB Lightningを再起動する必要があります。詳細は[TiDB Lightningを適切に再起動する方法](/tidb-lightning/tidb-lightning-faq.md#how-to-properly-restart-tidb-lightning)参照してください。 +TiDB Lightning は、追加の設定を必要とせず、バイナリのみを置き換えるだけでアップグレードできます。アップグレード後は、 TiDB Lightningを再起動する必要があります。詳細は[TiDB Lightningを適切に再起動する方法](/tidb-lightning/tidb-lightning-faq.md#how-to-properly-restart-tidb-lightning)を参照してください。 インポートタスクが実行中の場合は、 TiDB Lightningをアップグレードする前に、タスクが完了するまで待つことをお勧めします。そうしないと、チェックポイントがバージョン間で機能する保証がないため、最初から再インポートが必要になる可能性があります。 diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 70ceb6cb370d4..93f45734811a2 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -31,7 +31,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 `IMPORT INTO`タスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。3 タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、 `IMPORT INTO`タスクにデータインポート専用の[特定のTiDBノード](/system-variables.md#tidb_service_scope-new-in-v740)を指定することができ`IMPORT INTO` 。 -[TiDB グローバルソート](/tidb-global-sort.md)使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をstorageとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、ストレージコストを節約できます。 +[TiDB グローバルソート](/tidb-global-sort.md)を使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をstorageとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、ストレージコストを節約できます。 #### TiDB Lightning {#tidb-lightning} diff --git a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md index 1255d6eca8b68..2a5231d54b932 100644 --- a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md +++ b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md @@ -17,7 +17,7 @@ summary: IMPORT INTO およびTiDB Lightning とログ バックアップおよ - TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) 、ログバックアップおよびTiCDCと互換性がありません。これは、物理インポートモードがソースデータのエンコードされたKVペアをTiKVに直接取り込むため、TiKVがこの処理中に該当する変更ログを生成できないためです。変更ログが生成されないと、ログバックアップによる関連データのバックアップやTiCDCによるレプリケーションが実行できません。 -- クラスター内でTiDB Lightningと TiCDC を一緒に使用するには、 [TiDB Lightningとの互換性](/ticdc/ticdc-compatibility.md#compatibility-with-tidb-lightning)参照してください。 +- クラスター内でTiDB Lightningと TiCDC を一緒に使用するには、 [TiDB Lightningとの互換性](/ticdc/ticdc-compatibility.md#compatibility-with-tidb-lightning)を参照してください。 - `IMPORT INTO`はログバックアップおよびTiCDCと互換性がありません。これは、 `IMPORT INTO`ではソースデータのエンコードされたKVペアもTiKVに直接取り込まれるためです。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 4c28b337393a4..f0454668e3972 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -236,7 +236,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)参照してください。 +> バージョン8.0.0以降、 `duplicate-resolution`パラメータは非推奨となり、将来のリリースで削除される予定です。詳細については、 [競合検出の旧バージョン](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)を参照してください。 - 物理インポート モードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 - デフォルト値: `'none'` @@ -372,7 +372,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `data-source-dir` {#data-source-dir} -- ローカルソースデータディレクトリまたは外部ストレージのURIを指定します。外部ストレージのURIの詳細については、 [URI形式](/br/backup-and-restore-storages.md#uri-format)参照してください。 +- ローカルソースデータディレクトリまたは外部ストレージのURIを指定します。外部ストレージのURIの詳細については、 [URI形式](/br/backup-and-restore-storages.md#uri-format)を参照してください。 @@ -549,26 +549,26 @@ CSV ファイルの解析方法を構成します。 #### `build-stats-concurrency` {#build-stats-concurrency} -- チェックサムおよび分析処理を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)参照してください。 +- チェックサムおよび分析処理を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)を参照してください。 #### `distsql-scan-concurrency` {#distsql-scan-concurrency} -- チェックサムおよび分析処理を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)参照してください。 +- チェックサムおよび分析処理を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)を参照してください。 - [`checksum-via-sql`](#checksum-via-sql) `"true"`に設定した場合、 TiDB Lightning は`ADMIN CHECKSUM TABLE
` SQL 文を実行して TiDB のチェックサム演算を実行します。この場合、以下のパラメータ`distsql-scan-concurrency`と`checksum-table-concurrency`無効になります。 #### `index-serial-scan-concurrency` {#index-serial-scan-concurrency} -- チェックサムおよび分析処理を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)参照してください。 +- チェックサムおよび分析処理を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)を参照してください。 #### `checksum-table-concurrency` {#checksum-table-concurrency} -- チェックサムと`ANALYZE`操作を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)参照してください。 +- チェックサムと`ANALYZE`操作を高速化するために、TiDBセッション変数を設定します。詳細については、 [`ANALYZE`同時実行を制御する](/statistics.md#control-analyze-concurrency)を参照してください。 - [`checksum-via-sql`](#checksum-via-sql) `"true"`に設定した場合、 TiDB Lightning は`ADMIN CHECKSUM TABLE
` SQL 文を実行して TiDB のチェックサム演算を実行します。この場合、以下のパラメータ`distsql-scan-concurrency`と`checksum-table-concurrency`無効になります。 diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index dd8eee34f1be4..4e9587966fc07 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -141,7 +141,7 @@ trim-last-separator = false *シングルクォーテーションで囲まれた*文字列 ( `'…'` ) を使用すると、バックスラッシュによるエスケープを抑制できます。例えば、 `terminator = '\n'` 、LF `\n`ではなく、バックスラッシュ ( `\` ) と文字`n`の2文字の文字列を終端として使用することを意味します。 -詳細については[TOML v1.0.0仕様](https://toml.io/en/v1.0.0#string)参照してください。 +詳細については[TOML v1.0.0仕様](https://toml.io/en/v1.0.0#string)を参照してください。 #### `separator` {#separator} @@ -401,7 +401,7 @@ type = '$3' ## Amazon S3からデータをインポートする {#import-data-from-amazon-s3} -以下の例は、TiDB Lightningを使用して Amazon S3 からデータをインポートする方法を示しています。詳細なパラメータ設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +以下の例は、TiDB Lightningを使用して Amazon S3 からデータをインポートする方法を示しています。詳細なパラメータ設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 - ローカルに設定された権限を使用して S3 データにアクセスします。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 0f129cf749a7d..a8581a56dbb35 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -33,7 +33,7 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に ### 主キーまたは一意インデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes} -[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)使用してデータを並列インポートする場合は、データソース間およびターゲット TiDB クラスター内のテーブル間で主キーまたは一意インデックスの競合がないこと、またインポート中にターゲットテーブルにデータの書き込みが行われないことを確認してください。そうでない場合、 TiDB Lightning はインポートされたデータの正確性を保証できず、インポート完了後にターゲットテーブルに不整合なインデックスが含まれることになります。 +[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用してデータを並列インポートする場合は、データソース間およびターゲット TiDB クラスター内のテーブル間で主キーまたは一意インデックスの競合がないこと、またインポート中にターゲットテーブルにデータの書き込みが行われないことを確認してください。そうでない場合、 TiDB Lightning はインポートされたデータの正確性を保証できず、インポート完了後にターゲットテーブルに不整合なインデックスが含まれることになります。 ### インポートパフォーマンスの最適化 {#optimize-import-performance} @@ -59,7 +59,7 @@ TiDB Lightningを使用して共有データベースとテーブルを並列に TiDB Lightning は実行時に一部のリソースを排他的に使用します。単一のマシン（本番環境では推奨されません）または複数のマシンで共有されるディスクに複数のTiDB Lightningインスタンスを展開する必要がある場合は、以下の使用制限にご注意ください。 - 各TiDB Lightningインスタンスの一意のパスを`tikv-importer.sorted-kv-dir`に設定してください。複数のインスタンスが同じパスを共有すると、意図しない動作が発生し、インポートの失敗やデータエラーが発生する可能性があります。 -- 各TiDB Lightningチェックポイントは個別に保存してください。チェックポイントの設定の詳細については、 [TiDB Lightningチェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)参照してください。 +- 各TiDB Lightningチェックポイントは個別に保存してください。チェックポイントの設定の詳細については、 [TiDB Lightningチェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)を参照してください。 - checkpoint.driver = "file" (デフォルト) を設定する場合は、チェックポイントへのパスがインスタンスごとに一意であることを確認してください。 - checkpoint.driver = "mysql" を設定する場合は、インスタンスごとに一意のスキーマを設定する必要があります。 - 各TiDB Lightningのログファイルは、それぞれ異なるパスに設定する必要があります。同じログファイルを共有すると、ログのクエリやトラブルシューティングに影響します。 @@ -78,7 +78,7 @@ TiDB Lightningがデプロイされている 5 つのノード上の 2 つのシ - 2つのシャードテーブルが同じMySQLインスタンス内にある場合、 Dumplingのパラメータ`--filter`使用して直接エクスポートできます。TiDB Lightningを使用してインポートする場合は、 Dumplingがデータをエクスポートするディレクトリとして`data-source-dir`指定できます。 - 2つのシャードテーブルのデータが異なるMySQLノードに分散されている場合は、 Dumplingを使用して個別にエクスポートする必要があります。エクスポートしたデータは、同じ親ディレクトリ内、かつ異なるサブディレクトリに配置する必要があります。TiDB Lightningを使用して並列インポートを実行する場合は、親ディレクトリとして`data-source-dir`指定する必要があります。 -Dumpling を使用してデータをエクスポートする方法の詳細については、 [Dumpling](/dumpling-overview.md)参照してください。 +Dumpling を使用してデータをエクスポートする方法の詳細については、 [Dumpling](/dumpling-overview.md)を参照してください。 ### ステップ2: TiDB Lightningデータソースを構成する {#step-2-configure-tidb-lightning-data-sources} @@ -107,11 +107,11 @@ Dumpling を使用してデータをエクスポートする方法の詳細に tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \ -d 's3://my-bucket/sql-backup' -詳細なパラメータの説明については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +詳細なパラメータの説明については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 ### ステップ3: TiDB Lightningを起動してデータをインポートする {#step-3-start-tidb-lightning-to-import-data} -並列インポート中、各TiDB Lightningノードのサーバー構成要件は、非並列インポートモードの場合と同じです。各TiDB Lightningノードは同じリソースを使用する必要があります。各ノードは異なるサーバーにデプロイすることをお勧めします。詳細なデプロイ手順については、 [TiDB Lightningをデプロイ](/tidb-lightning/deploy-tidb-lightning.md)参照してください。 +並列インポート中、各TiDB Lightningノードのサーバー構成要件は、非並列インポートモードの場合と同じです。各TiDB Lightningノードは同じリソースを使用する必要があります。各ノードは異なるサーバーにデプロイすることをお勧めします。詳細なデプロイ手順については、 [TiDB Lightningをデプロイ](/tidb-lightning/deploy-tidb-lightning.md)を参照してください。 各サーバーで順番にTiDB Lightningを起動します。コマンドラインから`nohup`指定して直接起動すると、SIGHUPシグナルによって終了する可能性があります。そのため、スクリプトに`nohup`指定することをお勧めします。例： @@ -126,20 +126,20 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & - TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 - データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 -チェックをオフにして、 `lightning.check-requirements`設定で強制インポートを実行することもできます。詳細なチェックについては、 [TiDB Lightning事前チェック](/tidb-lightning/tidb-lightning-prechecks.md)参照してください。 +チェックをオフにして、 `lightning.check-requirements`設定で強制インポートを実行することもできます。詳細なチェックについては、 [TiDB Lightning事前チェック](/tidb-lightning/tidb-lightning-prechecks.md)を参照してください。 ### ステップ4: インポートの進行状況を確認する {#step-4-check-the-import-progress} インポートを開始した後、次のいずれかの方法で進行状況を確認できます。 - `grep` log キーワード`progress`で進捗状況を確認します。デフォルトでは5分ごとに更新されます。 -- 監視コンソールで進行状況を確認してください。詳細は[TiDB Lightning監視](/tidb-lightning/monitor-tidb-lightning.md)参照してください。 +- 監視コンソールで進行状況を確認してください。詳細は[TiDB Lightning監視](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 すべてのTiDB Lightningインスタンスが終了するまで待機すると、インポート全体が完了します。 ## 例2: 単一のテーブルを並列にインポートする {#example-2-import-single-tables-in-parallel} -TiDB Lightningは、単一テーブルの並列インポートもサポートしています。例えば、Amazon S3に保存されている複数の単一テーブルを、異なるTiDB Lightningインスタンスで下流のTiDBクラスターに並列インポートできます。この方法により、インポート全体の速度が向上します。Amazon S3などのリモートストレージを使用する場合、 TiDB Lightningの設定パラメータはBRと同じです。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +TiDB Lightningは、単一テーブルの並列インポートもサポートしています。例えば、Amazon S3に保存されている複数の単一テーブルを、異なるTiDB Lightningインスタンスで下流のTiDBクラスターに並列インポートできます。この方法により、インポート全体の速度が向上します。Amazon S3などのリモートストレージを使用する場合、 TiDB Lightningの設定パラメータはBRと同じです。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 > **注記：** > diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index 670c98b0b8f9c..fed9352a951c0 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -14,7 +14,7 @@ v5.4.0以降、 TiDB Lightningを設定して、無効な型変換や一意キ - `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)参照してください。 +詳細については[TiDB Lightning （タスク）](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を参照してください。 ## 入力エラー {#type-error} @@ -45,7 +45,7 @@ max-error = 0 ## 競合エラー {#conflict-errors} -設定項目[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)使用すると、データ競合に関連するエラーの許容度を高めることができます。この設定項目を*N*に設定すると、 TiDB Lightning はデータソースから最大*N 個の*競合エラーを許容し、それをスキップしてから終了します。デフォルト値は`10000`で、これは 10000 個のエラーが許容されることを意味します。 +設定項目[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を使用すると、データ競合に関連するエラーの許容度を高めることができます。この設定項目を*N*に設定すると、 TiDB Lightning はデータソースから最大*N 個の*競合エラーを許容し、それをスキップしてから終了します。デフォルト値は`10000`で、これは 10000 個のエラーが許容されることを意味します。 これらのエラーはテーブルに記録されます。インポートが完了したら、データベースでエラーを確認し、手動で処理することができます。詳細については、 [エラーレポート](#error-report)をご覧ください。 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index c60fbc0b02b40..7c5d425e6b3b9 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -17,7 +17,7 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ ## ターゲット データベースの権限要件は何ですか? {#what-are-the-privilege-requirements-for-the-target-database} -権限の詳細については[TiDB Lightningを使用するための前提条件](/tidb-lightning/tidb-lightning-requirements.md)参照してください。 +権限の詳細については[TiDB Lightningを使用するための前提条件](/tidb-lightning/tidb-lightning-requirements.md)を参照してください。 ## TiDB Lightning で1 つのテーブルのインポート中にエラーが発生しました。他のテーブルにも影響しますか？プロセスは終了しますか？ {#tidb-lightning-encountered-an-error-when-importing-one-table-will-it-affect-other-tables-will-the-process-be-terminated} diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index a7925ddf49f09..43dccc5690b7d 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -7,7 +7,7 @@ summary: TiDB Lightningで使用される特殊用語のリスト。 このページでは、TiDB Lightning のログ、監視、構成、ドキュメントで使用される特殊な用語について説明します。 -TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)参照してください。 +TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)を参照してください。 @@ -69,7 +69,7 @@ TiDB Lightning [インポートされたデータを検証する](/tidb-lightnin > > レガシーシステムへの対応のため、 TiDB Lightning、テーブルのインポートごとに明示的にコンパクションを実行するように設定できます。ただし、これは推奨されず、対応する設定はデフォルトで無効になっています。 -技術的な詳細については[RocksDBの圧縮に関するWikiページ](https://github.com/facebook/rocksdb/wiki/Compaction)参照してください。 +技術的な詳細については[RocksDBの圧縮に関するWikiページ](https://github.com/facebook/rocksdb/wiki/Compaction)を参照してください。 @@ -115,7 +115,7 @@ TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送 読み取り速度とスペース使用量を犠牲にして、書き込み用に TiKV を最適化する構成。 -TiDB Lightningは実行中に自動的にインポートモードを切り替えます。ただし、TiKVがインポートモードで停止した場合は、 `tidb-lightning-ctl` ～ [強制的に元に戻す](/tidb-lightning/troubleshoot-tidb-lightning.md#the-tidb-cluster-uses-lots-of-cpu-resources-and-runs-very-slowly-after-using-tidb-lightning) ～ [通常モード](/tidb-lightning/tidb-lightning-glossary.md#normal-mode)使用してください。 +TiDB Lightningは実行中に自動的にインポートモードを切り替えます。ただし、TiKVがインポートモードで停止した場合は、 `tidb-lightning-ctl` ～ [強制的に元に戻す](/tidb-lightning/troubleshoot-tidb-lightning.md#the-tidb-cluster-uses-lots-of-cpu-resources-and-runs-very-slowly-after-using-tidb-lightning) ～ [通常モード](/tidb-lightning/tidb-lightning-glossary.md#normal-mode)を使用してください。 ### インデックスエンジン {#index-engine} @@ -131,7 +131,7 @@ TiDB Lightningは複数のインデックスエンジンを同時に処理しま 取り込みは、KVペアを1つずつ挿入する操作に比べて非常に高速です。この操作がTiDB Lightningのパフォーマンスを決定づける要因です。 -技術的な詳細については[RocksDB の SST ファイルの作成と取り込みに関する wiki ページ](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)参照してください。 +技術的な詳細については[RocksDB の SST ファイルの作成と取り込みに関する wiki ページ](https://github.com/facebook/rocksdb/wiki/Creating-and-Ingesting-SST-files)を参照してください。 diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md index 6232bbf6fce07..09da7492768c9 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -58,7 +58,7 @@ log-level = "error" 戦略が`"error"`の場合、競合するデータによって発生したエラーはインポートタスクを直接終了させます。戦略が`"replace"`または`"ignore"`の場合、 [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することで許容される競合の最大数を制御できます。デフォルト値は`10000`で、これは 10000 件のエラーが許容されることを意味します。 -戦略が`"ignore"`の場合、競合するデータは下流の`conflict_records`テーブルに記録されます。詳細については、 [エラーレポート](/tidb-lightning/tidb-lightning-error-resolution.md#error-report)参照してください。v8.1.0 より前は、 [`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することでレコードを制限でき、制限を超える競合データはスキップされ、記録されません。v8.1.0 以降は、TiDB Lightning が[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)入力に関係なく`max-record-rows`の値に`threshold`の値を自動的に割り当てるため、代わりにTiDB Lightning を設定する必要があります。 +戦略が`"ignore"`の場合、競合するデータは下流の`conflict_records`テーブルに記録されます。詳細については、 [エラーレポート](/tidb-lightning/tidb-lightning-error-resolution.md#error-report)を参照してください。v8.1.0 より前は、 [`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することでレコードを制限でき、制限を超える競合データはスキップされ、記録されません。v8.1.0 以降は、TiDB Lightning が[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)入力に関係なく`max-record-rows`の値に`threshold`の値を自動的に割り当てるため、代わりにTiDB Lightning を設定する必要があります。 ## パフォーマンスチューニング {#performance-tuning} diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index 6e347151d1384..6c60f7bdf5714 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -89,7 +89,7 @@ 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 を使用する場合は、次の点に注意してください。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 5b58043485fc6..4da1d91734a65 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -108,7 +108,7 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all ``` -その他のオプションについては、セクション[チェックポイント制御](/tidb-lightning/tidb-lightning-checkpoints.md#checkpoints-control)参照してください。 +その他のオプションについては、セクション[チェックポイント制御](/tidb-lightning/tidb-lightning-checkpoints.md#checkpoints-control)を参照してください。 ### `cannot guess encoding for input file, please convert to UTF-8 manually` {#cannot-guess-encoding-for-input-file-please-convert-to-utf-8-manually} @@ -174,11 +174,11 @@ TiDB Lightning Local-backend は、v4.0.0 以降のバージョンの TiDB ク ### `Unknown character set` {#unknown-character-set} -TiDBはMySQLのすべての文字セットをサポートしていません。そのため、インポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、 TiDB Lightningはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)使用して下流で事前にテーブルスキーマを作成してください。 +TiDBはMySQLのすべての文字セットをサポートしていません。そのため、インポート中にテーブルスキーマを作成する際にサポートされていない文字セットが使用されると、 TiDB Lightningはこのエラーを報告します。このエラーを回避するには、特定のデータに応じて、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)を使用して下流で事前にテーブルスキーマを作成してください。 ### `invalid compression type ...` {#invalid-compression-type} -- TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスク`zstd`エラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)参照してください。 +- TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスク`zstd`エラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)を参照してください。 > **注記：** > diff --git a/tidb-monitoring-api.md b/tidb-monitoring-api.md index 87081599a9226..e23a37cc657e0 100644 --- a/tidb-monitoring-api.md +++ b/tidb-monitoring-api.md @@ -72,7 +72,7 @@ curl http://127.0.0.1:10080/schema_storage/test - PD APIアドレス: `http://${host}:${port}/pd/api/v1/${api_name}` - デフォルトポート: `2379` -- API名の詳細については、 [PD APIドキュメント](https://docs-download.pingcap.com/api/pd-api/pd-api-v1.html)参照してください。 +- API名の詳細については、 [PD APIドキュメント](https://docs-download.pingcap.com/api/pd-api/pd-api-v1.html)を参照してください。 PDインターフェースは、すべてのTiKVサーバーのステータスと負荷分散に関する情報を提供します。単一ノードのTiKVクラスターに関する情報については、次の例を参照してください。 @@ -112,6 +112,6 @@ curl http://127.0.0.1:2379/pd/api/v1/stores メトリクス インターフェイスは、TiDB クラスター全体のステータスとパフォーマンスを監視します。 -- 他のデプロイメント方法を使用する場合は、このインターフェイスを使用する前に[PrometheusとGrafanaをデプロイする](/deploy-monitoring-services.md)実行します。 +- 他のデプロイメント方法を使用する場合は、このインターフェイスを使用する前に[PrometheusとGrafanaをデプロイしてください](/deploy-monitoring-services.md)。 Prometheus と Grafana が正常にデプロイされたら、 [Grafanaを設定する](/deploy-monitoring-services.md#configure-grafana) 。 diff --git a/tidb-monitoring-framework.md b/tidb-monitoring-framework.md index 8191daa3facab..66fff1d70818b 100644 --- a/tidb-monitoring-framework.md +++ b/tidb-monitoring-framework.md @@ -5,7 +5,7 @@ summary: Prometheus、Grafana、TiDB Dashboardを使用して、TiDB 監視フ # TiDB 監視フレームワークの概要 {#tidb-monitoring-framework-overview} -TiDB監視フレームワークは、PrometheusとGrafanaという2つのオープンソースプロジェクトを採用しています。TiDBは、監視およびパフォーマンスメトリクスの保存に[Prometheus](https://prometheus.io)使用し、これらのメトリクスの可視化に[Grafana](https://grafana.com/grafana)使用します。また、TiDBは、TiDBクラスターの監視と診断のための組み込みの[TiDB Dashboard](/dashboard/dashboard-intro.md)を提供しています。 +TiDB監視フレームワークは、PrometheusとGrafanaという2つのオープンソースプロジェクトを採用しています。TiDBは、監視およびパフォーマンスメトリクスの保存に[Prometheus](https://prometheus.io)使用し、これらのメトリクスの可視化に[Grafana](https://grafana.com/grafana)を使用します。また、TiDBは、TiDBクラスターの監視と診断のための組み込みの[TiDB Dashboard](/dashboard/dashboard-intro.md)を提供しています。 ## TiDBにおけるPrometheusについて {#about-prometheus-in-tidb} diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index d30978f60cdbf..0fa8be5786d08 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -74,7 +74,7 @@ SET GLOBAL tidb_opt_fix_control = '44262:ON,44389:ON,44823:10000,44830:ON,44855: 以下では、追加の最適化を可能にするオプティマイザ制御構成について説明します。 -- [`44262:ON`](/optimizer-fix-controls.md#44262-new-in-v653-and-v720) : [グローバル統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)が欠落している場合は、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)使用してパーティションテーブルにアクセスします。 +- [`44262:ON`](/optimizer-fix-controls.md#44262-new-in-v653-and-v720) : [グローバル統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)が欠落している場合は、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を使用してパーティションテーブルにアクセスします。 - [`44389:ON`](/optimizer-fix-controls.md#44389-new-in-v653-and-v720) : `c = 10 and (a = 'xx' or (a = 'kk' and b = 1))`のようなフィルターの場合、 `IndexRangeScan`のより包括的なスキャン範囲を作成します。 - [`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`演算子を含む実行プランをキャッシュすることを許可します。 @@ -124,7 +124,7 @@ soft-pending-compaction-bytes-limit = "192GiB" | [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込み要求に対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 | | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 | -| [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じ圧縮効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)参照してください。 | +| [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じ圧縮効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)を参照してください。 | 前述の表に示されている圧縮およびフロー制御構成の調整は、以下の仕様を持つインスタンスへの TiKV デプロイメントに合わせて調整されていることに注意してください。 @@ -248,7 +248,7 @@ sysbench oltp_read_only prepare --mysql-host={host} --mysql-port={port} --mysql- sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user=root --db-driver=mysql --mysql-db=test --threads=200 --time=900 --report-interval=10 --tables=1000 --table-size=10000 ``` -詳細については、 [Sysbenchを使用してTiDBをテストする方法](/benchmark/benchmark-tidb-using-sysbench.md)参照してください。 +詳細については、 [Sysbenchを使用してTiDBをテストする方法](/benchmark/benchmark-tidb-using-sysbench.md)を参照してください。 ### YCSBの大規模レコード値に関するワークロード {#ycsb-workloads-on-large-record-value} diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 05462acab91f3..dd66d5fa57be2 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -69,7 +69,7 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と > **注記：** > > - 各書き込み操作は最終的にすべてのレプリカに複製されます（デフォルトでは、TiKVには3つのレプリカがあります）。各複製操作は、それぞれ異なる書き込み操作として扱われます。 -> - 上記の表には、TiDB Self-ManagedクラスタのRU計算に関わるリソースのみが記載されており、ネットワークとストレージの消費量は含まれていません。TiDB Cloud StarterのRUについては、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +> - 上記の表には、TiDB Self-ManagedクラスタのRU計算に関わるリソースのみが記載されており、ネットワークとストレージの消費量は含まれていません。TiDB Cloud StarterのRUについては、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)を参照してください。 > - 現在、 TiFlashのリソース制御では、SQL CPUのみが考慮されます。SQL CPUとは、クエリおよび読み取りリクエストのペイロードに対するパイプラインタスクの実行によって消費されるCPU時間です。 ## リソース制御のためのパラメータ {#parameters-for-resource-control} @@ -111,7 +111,7 @@ TiDB v7.0.0以降、 `tidb_enable_resource_control`と`resource-control.enabled` -リソース制御メカニズムとパラメータの詳細については、 [RFC: TiDBにおけるグローバルリソース制御](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md)および[TiFlashリソース制御](https://github.com/pingcap/tiflash/blob/release-8.5/docs/design/2023-09-21-tiflash-resource-control.md)参照してください。 +リソース制御メカニズムとパラメータの詳細については、 [RFC: TiDBにおけるグローバルリソース制御](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md)および[TiFlashリソース制御](https://github.com/pingcap/tiflash/blob/release-8.5/docs/design/2023-09-21-tiflash-resource-control.md)を参照してください。 ## リソース制御の使い方 {#how-to-use-resource-control} @@ -207,7 +207,7 @@ ALTER USER usr2 RESOURCE GROUP rg2; ALTER USER 'usr3'@'%' RESOURCE GROUP `default`; ``` -詳細については、 [`ALTER USER`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user)参照してください。 +詳細については、 [`ALTER USER`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user)を参照してください。 #### 現在のセッションをリソースグループにバインドする {#bind-the-current-session-to-a-resource-group} @@ -389,7 +389,7 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー 2. データベースユーザーは複数のリソースグループに紐付けられますか？ - いいえ。データベースユーザーは1つのリソースグループにしかバインドできません。ただし、セッション実行時には、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)使用して、現在のセッションで使用するリソースグループを設定できます。また、オプティマイザヒント[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)を使用して、実行中のステートメントのリソースグループを設定することもできます。 + いいえ。データベースユーザーは1つのリソースグループにしかバインドできません。ただし、セッション実行時には、 [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)を使用して、現在のセッションで使用するリソースグループを設定できます。また、オプティマイザヒント[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)を使用して、実行中のステートメントのリソースグループを設定することもできます。 3. すべてのリソースグループの合計リソース割り当て（ `RU_PER_SEC` ）がシステム容量を超えた場合、どうなりますか？ diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 50a3880f94fde..ef3f4db7912ed 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -12,9 +12,9 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 - バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。3 または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) `QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 -- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 +- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 -リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 +リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 ## QUERY_LIMITパラメータ {#code-query-limit-code-parameters} @@ -79,7 +79,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ## QUERY WATCHパラメータ {#code-query-watch-code-parameters} -`QUERY WATCH`のあらすじについては[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)参照してください。 +`QUERY WATCH`のあらすじについては[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を参照してください。 パラメータは次のとおりです。 @@ -168,4 +168,4 @@ summary: リソース管理機能を使用して、リソースを過剰に消 - `identify`ランナウェイクエリの条件に一致することを意味します。 - `watch` 、監視リスト内のクイック識別ルールに一致することを意味します。 -- `information_schema.runaway_watches`表には、ランナウェイクエリのクイック識別ルールの記録が含まれています。詳細については、 [`RUNAWAY_WATCHES`](/information-schema/information-schema-runaway-watches.md)参照してください。 +- `information_schema.runaway_watches`表には、ランナウェイクエリのクイック識別ルールの記録が含まれています。詳細については、 [`RUNAWAY_WATCHES`](/information-schema/information-schema-runaway-watches.md)を参照してください。 diff --git a/tidb-rowid.md b/tidb-rowid.md index cf98b701677a6..f0f6a767fdcd0 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -130,7 +130,7 @@ SELECT _tidb_rowid, a, b FROM t WHERE _tidb_rowid = 100; `_tidb_rowid`使用するテーブルの場合、TiDB はデフォルトで行 ID を昇順で割り当てます。書き込み負荷の高いワークロードでは、これにより書き込みホットスポットが発生する可能性があります。 -この問題を軽減するために（行IDとして`_tidb_rowid`を使用するテーブルの場合）、行IDをより均等に分配するために[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)使用し、必要に応じてリージョンを事前に分割するために[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)使用することを検討してください。 +この問題を軽減するために（行IDとして`_tidb_rowid`を使用するテーブルの場合）、行IDをより均等に分配するために[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)使用し、必要に応じてリージョンを事前に分割するために[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)を使用することを検討してください。 例： diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 6e67a4cb8b6eb..f3300f55d8946 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -13,13 +13,13 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 1.1.1 `Region is Unavailable`エラーは通常、リージョンが一定期間利用できないことが原因です。 `TiKV server is busy`が発生する場合や、 `not leader`または`epoch not match` } が原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする場合があります。このような場合、TiDB は`backoff`再試行メカニズムを実行します。 `backoff`がしきい値 (デフォルトでは 20 秒) を超えると、エラーがクライアントに送信されます。 `backoff`のしきい値内であれば、このエラーはクライアントには表示されません。 -- 1.1.2 複数のTiKVインスタンスが同時にメモリ不足（OOM）になると、OOM期間中にLeaderが存在しない状態になります。中国語版の[ケース991](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case991.md)参照してください。 +- 1.1.2 複数のTiKVインスタンスが同時にメモリ不足（OOM）になると、OOM期間中にLeaderが存在しない状態になります。中国語版の[ケース991](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case991.md)を参照してください。 - 1.1.3 TiKV は`TiKV server is busy`を報告し、 `backoff`時間を超過します。詳細については、 [4.3](#43-the-client-reports-the-server-is-busy-error)を参照してください。 `TiKV server is busy`は内部フロー制御メカニズムの結果であり、 `backoff`時間にカウントされるべきではありません。この問題は修正されます。 -- 1.1.4 複数の TiKV インスタンスの起動に失敗し、リージョンにLeaderが存在しない状態になる。物理マシンに複数の TiKV インスタンスがデプロイされている場合、ラベルが正しく設定されていないと、物理マシンの障害によってリージョンにLeaderが存在しない状態になることがあります。中国語の[ケース228](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case228.md)参照してください。 +- 1.1.4 複数の TiKV インスタンスの起動に失敗し、リージョンにLeaderが存在しない状態になる。物理マシンに複数の TiKV インスタンスがデプロイされている場合、ラベルが正しく設定されていないと、物理マシンの障害によってリージョンにLeaderが存在しない状態になることがあります。中国語の[ケース228](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case228.md)を参照してください。 -- 1.1.5Followerの申請が前のエポックで遅延した場合、FollowerがLeaderになった後、 `epoch not match`を使用してリクエストを拒否します。中国語の[ケース958](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case958.md)参照してください（TiKV はそのメカニズムを最適化する必要があります）。 +- 1.1.5Followerの申請が前のエポックで遅延した場合、FollowerがLeaderになった後、 `epoch not match`を使用してリクエストを拒否します。中国語の[ケース958](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case958.md)を参照してください（TiKV はそのメカニズムを最適化する必要があります）。 ### 1.2 PDエラーによりサービスが利用できなくなる {#1-2-pd-errors-cause-service-unavailable} @@ -32,13 +32,13 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 2.1.1 TiDB の実行プランが間違っているとレイテンシーが増加します[3.3](#33-wrong-execution-plan)を参照してください。 - 2.1.2 PD Leader選挙問題またはOOM。5.2および[5.2](#52-pd-election) [5.3](#53-pd-oom)参照してください。 - 2.1.3 一部のTiKVインスタンスでLeaderが多数ドロップする[4.4](#44-some-tikv-nodes-drop-leader-frequently)を参照。 -- 2.1.4 他の原因については、[読み取り/書き込みレイテンシの増加に関するトラブルシューティング](/troubleshoot-cpu-issues.md)参照してください。 +- 2.1.4 他の原因については、[読み取り/書き込みレイテンシの増加に関するトラブルシューティング](/troubleshoot-cpu-issues.md)を参照してください。 ### 2.2 持続的かつ著しい増加 {#2-2-persistent-and-significant-increase} - 2.2.1 TiKVシングルスレッドのボトルネック - - TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV-details** -> **Thread CPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`を有効にすることでこの問題を解決できます。中国語の[ケース612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)参照してください。 + - TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV-details** -> **Thread CPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`を有効にすることでこの問題を解決できます。中国語の[ケース612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)を参照してください。 - v3.0より前のバージョンでは、raftstoreスレッドまたはapplyスレッドがボトルネックになった場合（ **Grafana** -> **TiKV-details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリクスが`80%`を超える場合）、TiKV（v2.x）インスタンスをスケールアウトするか、マルチスレッド対応のv3.xにアップグレードできます。 @@ -48,7 +48,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - 2.2.4 TiDB の実行プランが間違っています[3.3](#33-wrong-execution-plan)を参照してください。 -- 2.2.5 他の原因については、[読み取り/書き込みレイテンシの増加に関するトラブルシューティング](/troubleshoot-cpu-issues.md)参照してください。 +- 2.2.5 他の原因については、[読み取り/書き込みレイテンシの増加に関するトラブルシューティング](/troubleshoot-cpu-issues.md)を参照してください。 ## 3. TiDBの問題 {#3-tidb-issues} @@ -135,7 +135,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - SQL クエリには`join`が含まれています。 `explain`を使用して SQL ステートメントを表示すると、 `join`操作で`HashJoin`アルゴリズムが選択され、 `inner`テーブルが大きいことがわかります。 - - 単一の`UPDATE/DELETE`クエリのデータ量が大きすぎます。中国語の[ケース882](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case882.md)参照してください。 + - 単一の`UPDATE/DELETE`クエリのデータ量が大きすぎます。中国語の[ケース882](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case882.md)を参照してください。 - SQL文には`Union`で接続された複数のサブクエリが含まれています。中国語版の[ケース1828](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case1828.md)を参照してください。 @@ -185,27 +185,27 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ ### 3.5 クエリの遅延に関する問題 {#3-5-slow-query-issues} -スロークエリを特定するには、[スロークエリを特定する](/identify-slow-queries.md)参照してください。スロークエリを分析して処理するには、[スロークエリを分析する](/analyze-slow-queries.md)参照してください。 +スロークエリを特定するには、[スロークエリを特定する](/identify-slow-queries.md)を参照してください。スロークエリを分析して処理するには、[スロークエリを分析する](/analyze-slow-queries.md)を参照してください。 ### 3.6 ホットスポットの問題 {#3-6-hotspot-issues} 分散データベースであるTiDBは、サーバーリソースをより有効活用するために、アプリケーションの負荷をさまざまなコンピューティングノードやストレージノードに均等に分散させるロードバランシングメカニズムを備えています。しかし、特定のシナリオでは、アプリケーションの負荷が適切に分散されない場合があり、パフォーマンスに影響を与え、ホットスポットと呼ばれる高負荷の一点が発生する可能性があります。 -TiDB は、ホットスポットのトラブルシューティング、解決、回避のための完全なソリューションを提供します。負荷ホットスポットのバランスをとることで、QPS の向上やレイテンシーの削減など、全体的なパフォーマンスを向上させることができます。詳細な解決策については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)参照してください。 +TiDB は、ホットスポットのトラブルシューティング、解決、回避のための完全なソリューションを提供します。負荷ホットスポットのバランスをとることで、QPS の向上やレイテンシーの削減など、全体的なパフォーマンスを向上させることができます。詳細な解決策については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)を参照してください。 ### 3.7 ディスクI/O使用率が高い {#3-7-high-disk-i-o-usage} -CPU ボトルネックとトランザクションの競合によって引き起こされるボトルネックのトラブルシューティングを行った後に TiDB の応答が遅くなった場合は、現在のシステム ボトルネックを特定するために I/O メトリックを確認する必要があります。 TiDB での高い I/O 使用率の問題を特定して処理する方法については、[ディスクI/O使用率が高い場合のトラブルシューティング](/troubleshoot-high-disk-io.md)参照してください。 +CPU ボトルネックとトランザクションの競合によって引き起こされるボトルネックのトラブルシューティングを行った後に TiDB の応答が遅くなった場合は、現在のシステム ボトルネックを特定するために I/O メトリックを確認する必要があります。 TiDB での高い I/O 使用率の問題を特定して処理する方法については、[ディスクI/O使用率が高い場合のトラブルシューティング](/troubleshoot-high-disk-io.md)を参照してください。 ### 3.8 ロックの競合 {#3-8-lock-conflicts} -TiDB は完全な分散トランザクションをサポートします。 v3.0 以降、TiDB は楽観的トランザクション モードと悲観的トランザクション モードを提供します。ロック関連の問題のトラブルシューティング方法、および楽観的ロックと悲観的ロックの競合の処理方法については、[ロックの競合をトラブルシューティングする](/troubleshoot-lock-conflicts.md)参照してください。 +TiDB は完全な分散トランザクションをサポートします。 v3.0 以降、TiDB は楽観的トランザクション モードと悲観的トランザクション モードを提供します。ロック関連の問題のトラブルシューティング方法、および楽観的ロックと悲観的ロックの競合の処理方法については、[ロックの競合をトラブルシューティングする](/troubleshoot-lock-conflicts.md)を参照してください。 ### 3.9 データと指標の不整合 {#3-9-inconsistency-between-data-and-indexes} TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|INDEX]`](/sql-statements/sql-statement-admin-check-table-index.md)ステートメントの実行時に、データとインデックスの一貫性をチェックします。チェックの結果、レコードのキーと値、および対応するインデックスのキーと値が一致しない、つまり、行データを格納するキーと値のペアと、そのインデックスを格納する対応するキーと値のペアが一致しない（例えば、インデックスが多すぎる、またはインデックスが欠落している）ことが判明した場合、TiDB はデータ不整合エラーを報告し、関連するエラーをエラー ログに出力。 -不整合エラーとチェックを回避する方法の詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)参照してください。 +不整合エラーとチェックを回避する方法の詳細については、 [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md)を参照してください。 ## 4. TiKVに関する問題 {#4-tikv-issues} @@ -279,7 +279,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - TiKV がメモリ不足のため再起動します[4.2](#42-tikv-oom)を参照してください。 - - TiKV は、 `THP` (透明巨大ページ) の動的な調整が原因でハングアップしています。中国語の[ケース500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md)参照してください。 + - TiKV は、 `THP` (透明巨大ページ) の動的な調整が原因でハングアップしています。中国語の[ケース500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md)を参照してください。 - 4.4.2 TiKV RocksDB で書き込み停止が発生し、再選出が行われます。モニター**Grafana** -> **TiKV-details** -> **errors**に`server is busy`が表示されているかどうかを確認してください[4.3.1](#43-the-client-reports-the-server-is-busy-error)を参照してください。 @@ -334,7 +334,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 5.1.1 マージ - - テーブルをまたいで空のリージョンはマージできません。TiKV の`[coprocessor] split-region-on-table`パラメータを変更する必要があります。このパラメータは、v4.x ではデフォルトで`false`に設定されています。詳細は中国語の[ケース896](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case896.md)参照してください。 + - テーブルをまたいで空のリージョンはマージできません。TiKV の`[coprocessor] split-region-on-table`パラメータを変更する必要があります。このパラメータは、v4.x ではデフォルトで`false`に設定されています。詳細は中国語の[ケース896](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case896.md)を参照してください。 - リージョンのマージは遅いです。マージされたオペレーターが生成されているかどうかは、 **Grafana** -> **PD** -> **operator**のモニターダッシュボードにアクセスして確認できます。マージを高速化するには、 `merge-schedule-limit`の値を増やしてください。 @@ -342,7 +342,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - TiKVディスクが容量の80%を使用し、PDがレプリカを追加しない場合、ミスピア数が増加するため、TiKVをスケールアウトする必要があります。詳細は中国語版の[ケース801](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case801.md)を参照してください。 - - TiKVノードがオフラインになると、一部のリージョンを他のノードに移行できなくなる問題がありました。この問題はv3.0.4で修正されました（ [#5526](https://github.com/tikv/tikv/pull/5526) ）。中国語版の[ケース870](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case870.md)参照してください。 + - TiKVノードがオフラインになると、一部のリージョンを他のノードに移行できなくなる問題がありました。この問題はv3.0.4で修正されました（ [#5526](https://github.com/tikv/tikv/pull/5526) ）。中国語版の[ケース870](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case870.md)を参照してください。 - 5.1.3 バランス @@ -352,15 +352,15 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 5.2.1 PD スイッチLeader。 - - 原因1：ディスク。PDノードが配置されているディスクのI/O負荷が最大になっています。PDがI/O負荷の高い他のコンポーネントと一緒にデプロイされているかどうか、およびディスクの状態を調査してください。Grafana**の**「**ディスクパフォ​​ーマンス**」→ **「レイテンシー**/**負荷」**でモニターメトリックを確認することで原因を特定できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。中国語の[ケース292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)参照してください。 + - 原因1：ディスク。PDノードが配置されているディスクのI/O負荷が最大になっています。PDがI/O負荷の高い他のコンポーネントと一緒にデプロイされているかどうか、およびディスクの状態を調査してください。Grafana**の**「**ディスクパフォ​​ーマンス**」→ **「レイテンシー**/**負荷」**でモニターメトリックを確認することで原因を特定できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。中国語の[ケース292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)を参照してください。 - - 原因 2: ネットワーク。PD ログに`lost the TCP streaming connection`が表示されます。PD ノード間のネットワークに問題がないか確認し、モニター**Grafana** -> **PD** -> **etcd**で`round trip`を表示して原因を検証する必要があります。中国語の[ケース177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)参照してください。 + - 原因 2: ネットワーク。PD ログに`lost the TCP streaming connection`が表示されます。PD ノード間のネットワークに問題がないか確認し、モニター**Grafana** -> **PD** -> **etcd**で`round trip`を表示して原因を検証する必要があります。中国語の[ケース177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)を参照してください。 - - 原因3：システム負荷が高い。ログには`server is likely overloaded`と表示されます。中国語の[ケース214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)参照してください。 + - 原因3：システム負荷が高い。ログには`server is likely overloaded`と表示されます。中国語の[ケース214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)を参照してください。 - 5.2.2 PDはLeaderを選出できないか、選挙が遅い。 - - PD はLeaderを選出できません: PD ログには`lease is not expired`が表示されます。 [この問題は](https://github.com/etcd-io/etcd/issues/10355)v3.0.x および v2.1.19 で修正されました。中国語の[ケース875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)参照してください。 + - PD はLeaderを選出できません: PD ログには`lease is not expired`が表示されます。 [この問題は](https://github.com/etcd-io/etcd/issues/10355)v3.0.x および v2.1.19 で修正されました。中国語の[ケース875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)を参照してください。 - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `region storage`を`use-region-storage`に設定することで`true`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 @@ -378,7 +378,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 5.2.4 その他の問題 - - PD は`FATAL`エラーを報告し、ログには`range failed to find revision pair`と表示されます。この問題は v3.0.8 ( [#2040](https://github.com/pingcap/pd/pull/2040) ) で修正されました。詳細は、中国語の[ケース947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md)参照してください。 + - PD は`FATAL`エラーを報告し、ログには`range failed to find revision pair`と表示されます。この問題は v3.0.8 ( [#2040](https://github.com/pingcap/pd/pull/2040) ) で修正されました。詳細は、中国語の[ケース947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md)を参照してください。 - その他の状況については、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 @@ -396,13 +396,13 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ### 6.1 データ移行 {#6-1-data-migration} -- 6.1.1 TiDB Data Migration (DM)は、MySQL/MariaDBからTiDBへのデータ移行をサポートする移行ツールです。詳細については、 [DMの概要](/dm/dm-overview.md)参照してください。 +- 6.1.1 TiDB Data Migration (DM)は、MySQL/MariaDBからTiDBへのデータ移行をサポートする移行ツールです。詳細については、 [DMの概要](/dm/dm-overview.md)を参照してください。 - 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-worker/DM-master/dmctl をデプロイするには、 [AskTUGに関するケーススタディ](https://pingkai.cn/tidbcommunity/forum/t/topic/1049/5)参照してください。 + - DM クラスターに異なるバージョンの DM-worker/DM-master/dmctl をデプロイするには、 [AskTUGに関するケーススタディ](https://pingkai.cn/tidbcommunity/forum/t/topic/1049/5)を参照してください。 - 6.1.3 レプリケーション タスクが`driver: bad connection`エラーで中断されました。 @@ -536,7 +536,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND これは、楽観的トランザクションにおける書き込み競合です。複数のトランザクションが同じキーを変更した場合、1つのトランザクションのみが成功し、他のトランザクションは自動的にタイムスタンプを再取得して操作を再試行するため、業務に影響はありません。 - 競合が深刻な場合は、複数回の再試行後にトランザクションが失敗する可能性があります。この場合、悲観的ロックを使用することをお勧めします。エラーと解決策の詳細については、[楽観的トランザクションにおける書き込み競合のトラブルシューティング](/troubleshoot-write-conflicts.md)参照してください。 + 競合が深刻な場合は、複数回の再試行後にトランザクションが失敗する可能性があります。この場合、悲観的ロックを使用することをお勧めします。エラーと解決策の詳細については、[楽観的トランザクションにおける書き込み競合のトラブルシューティング](/troubleshoot-write-conflicts.md)を参照してください。 - 7.2.3 `TxnLockNotFound` 。 diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md index 48a6b7e183856..4c84ea28ce2e7 100644 --- a/tidb-upgrade-migration-guide.md +++ b/tidb-upgrade-migration-guide.md @@ -31,14 +31,14 @@ summary: 完全バックアップと復元のためのBRと、増分データレ - TiCDC の互換性を確認します。 - - **テーブルスキーマの要件**：レプリケートするテーブルに有効なインデックスが含まれていることを確認してください。詳細については、 [TiCDC有効インデックス](/ticdc/ticdc-overview.md#valid-index)参照してください。 - - **機能制限**：TiCDCはシーケンスDDLレプリケーションまたはTiFlash DDLレプリケーションをサポートしていません。詳細については、 [TiCDC がサポートしていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)参照してください。 + - **テーブルスキーマの要件**：レプリケートするテーブルに有効なインデックスが含まれていることを確認してください。詳細については、 [TiCDC有効インデックス](/ticdc/ticdc-overview.md#valid-index)を参照してください。 + - **機能制限**：TiCDCはシーケンスDDLレプリケーションまたはTiFlash DDLレプリケーションをサポートしていません。詳細については、 [TiCDC がサポートしていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)を参照してください。 - **ベスト プラクティス**: スイッチオーバー中に TiCDC のアップストリーム クラスターで DDL 操作を実行しないでください。 - BRの互換性を確認します。 - - BRフルバックアップの互換性マトリックスを確認してください。詳細については、 [BRバージョン互換性マトリックス](/br/backup-and-restore-overview.md#br-version-compatibility-matrix-between-tidb-v650-and-v850)参照してください。 - - BRバックアップと復元の既知の制限事項を確認してください。詳細については、 [BRの使用制限](/br/backup-and-restore-overview.md#restrictions)参照してください。 + - BRフルバックアップの互換性マトリックスを確認してください。詳細については、 [BRバージョン互換性マトリックス](/br/backup-and-restore-overview.md#br-version-compatibility-matrix-between-tidb-v650-and-v850)を参照してください。 + - BRバックアップと復元の既知の制限事項を確認してください。詳細については、 [BRの使用制限](/br/backup-and-restore-overview.md#restrictions)を参照してください。 - [リージョン](/glossary.md#regionpeerraft-group)健全性やノードのリソース使用率など、クラスターの健全性状態を確認します。 @@ -59,7 +59,7 @@ SET GLOBAL tidb_gc_life_time=60h; > **注記：** > -> `tidb_gc_life_time`増やすと、 [MVCC](/glossary.md#multi-version-concurrency-control-mvcc)データのストレージ使用量が増加し、クエリのパフォーマンスに影響する可能性があります。詳細については、 [GCの概要](/garbage-collection-overview.md)参照してください。storageとパフォーマンスへの影響を考慮しながら、推定操作時間に基づいてGC期間を調整してください。 +> `tidb_gc_life_time`増やすと、 [MVCC](/glossary.md#multi-version-concurrency-control-mvcc)データのストレージ使用量が増加し、クエリのパフォーマンスに影響する可能性があります。詳細については、 [GCの概要](/garbage-collection-overview.md)を参照してください。storageとパフォーマンスへの影響を考慮しながら、推定操作時間に基づいてGC期間を調整してください。 ### 2. 新しいクラスターに全データを移行する {#2-migrate-full-data-to-the-new-cluster} @@ -107,7 +107,7 @@ SET GLOBAL tidb_gc_life_time=60h; ### 3. 新しいクラスターをターゲットバージョンにアップグレードする {#3-upgrade-the-new-cluster-to-the-target-version} -時間を節約するために、以下のコマンドを使用してオフラインアップグレードを実行できます。その他のアップグレード方法については、 [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md)参照してください。 +時間を節約するために、以下のコマンドを使用してオフラインアップグレードを実行できます。その他のアップグレード方法については、 [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md)を参照してください。 ```shell tiup cluster stop # Stop the cluster @@ -175,7 +175,7 @@ tiup cluster start # Start the cluster ./sync_diff_inspector --config=./config.toml ``` -- [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)参照してください。 +- [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)を参照してください。 - テーブルの行数の比較など、ビジネス データの手動検証を実行します。 diff --git a/tiflash-deployment-topology.md b/tiflash-deployment-topology.md index 6d827daa4ac8c..0e2ffae5716c6 100644 --- a/tiflash-deployment-topology.md +++ b/tiflash-deployment-topology.md @@ -28,13 +28,13 @@ 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パラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)参照してください。 +- TiFlashパラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)を参照してください。 > **注記：** > diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index 1db6c51f938fc..7c98f96c6d8f8 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -67,7 +67,7 @@ TiFlash Proxyはv6.1.0（TiKV v6.0.0と連動）にアップグレードされ **テストやその他の特別なシナリオでTiFlash をダウングレードするための回避策** -対象のTiFlashノードを強制的にスケールインし、TiKVからデータを再度複製することができます。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 +対象のTiFlashノードを強制的にスケールインし、TiKVからデータを再度複製することができます。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 ### 動的剪定 {#dynamic-pruning} @@ -77,7 +77,7 @@ TiFlash Proxyはv6.1.0（TiKV v6.0.0と連動）にアップグレードされ - TiDB v6.0以前：動的プルーニングはデフォルトで無効になっています。アップグレード後の動的プルーニングの設定は、以前のバージョンの設定を継承します。つまり、アップグレード後も動的プルーニングは自動的に有効化（または無効化）されません。 - アップグレード後、動的プルーニングを有効にするには、 `tidb_partition_prune_mode`を`dynamic`に設定し、パーティションテーブルのグローバル統計を手動で更新してください。詳細については、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)参照してください。 + アップグレード後、動的プルーニングを有効にするには、 `tidb_partition_prune_mode`を`dynamic`に設定し、パーティションテーブルのグローバル統計を手動で更新してください。詳細については、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を参照してください。 ## v5.x または v6.0 から v6.2 へ {#from-v5-x-or-v6-0-to-v6-2} @@ -121,13 +121,13 @@ TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version **テストやその他の特別なシナリオでTiFlash をダウングレードするための回避策** -対象のTiFlashノードを強制的にスケールインし、TiKVからデータを再度複製することができます。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 +対象のTiFlashノードを強制的にスケールインし、TiKVからデータを再度複製することができます。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 ## v6.x または v7.x からstorage.format_version = 5が設定された v7.3 へ {#from-v6-x-or-v7-x-to-v7-3-with-code-storage-format-version-5-code-configured} TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1 つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash構成パラメータ](/tiflash/tiflash-configuration.md) `storage.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータ圧縮時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。 -TiFlashをv7.3にアップグレードし、V3 DTFilesを使用するように設定した後、 TiFlashを以前のバージョンに戻す必要がある場合は、DTToolをオフラインで使用してV3 DTFilesをV2 DTFilesに書き換えることができます。詳細については、 [DTTool 移行ツール](/tiflash/tiflash-command-line-flags.md#dttool-migrate)参照してください。 +TiFlashをv7.3にアップグレードし、V3 DTFilesを使用するように設定した後、 TiFlashを以前のバージョンに戻す必要がある場合は、DTToolをオフラインで使用してV3 DTFilesをV2 DTFilesに書き換えることができます。詳細については、 [DTTool 移行ツール](/tiflash/tiflash-command-line-flags.md#dttool-migrate)を参照してください。 ## v6.x または v7.x から v7.4 以降のバージョンへ {#from-v6-x-or-v7-x-to-v7-4-or-a-later-version} @@ -139,4 +139,4 @@ v7.4以降、データ圧縮中に発生する読み取りおよび書き込み **テストやその他の特別なシナリオでTiFlash をダウングレードするための回避策** -テストやその他の特殊なシナリオでTiFlashをダウングレードするには、対象のTiFlashノードを強制的にスケールインし、その後TiKVからデータを再度複製します。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 +テストやその他の特殊なシナリオでTiFlashをダウングレードするには、対象のTiFlashノードを強制的にスケールインし、その後TiKVからデータを再度複製します。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 8c53f4366a211..f3b400765c97b 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -141,7 +141,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla このプロセス中、各TiKVインスタンスはテーブル全体をスキャンし、スキャンしたデータのスナップショットをTiFlashに送信してレプリカを作成します。デフォルトでは、TiKVおよびTiFlashの本番ワークロードへの影響を最小限に抑えるため、 TiFlashはレプリカの追加速度を遅くし、使用するリソースを少なくしています。TiKVノードとTiFlashノードに十分なCPUとディスクI/Oリソースがある場合は、以下の手順を実行することでTiFlashレプリケーションを高速化できます。 -1. [動的設定SQL文](https://docs.pingcap.com/tidb/stable/dynamic-config)使用して、各 TiKV およびTiFlashインスタンスのスナップショット書き込み速度制限を一時的に上げます。 +1. [動的設定SQL文](https://docs.pingcap.com/tidb/stable/dynamic-config)を使用して、各 TiKV およびTiFlashインスタンスのスナップショット書き込み速度制限を一時的に上げます。 ```sql -- The default value for both configurations are 100MiB, i.e. the maximum disk bandwidth used for writing snapshots is no more than 100MiB/s. @@ -151,7 +151,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla これらのSQL文を実行すると、クラスターを再起動することなく設定変更が即座に有効になります。ただし、レプリケーション速度はPD制限によってグローバルに制限されているため、現時点では高速化の効果を確認することはできません。 -2. レプリカのスケジュール速度制限を段階的に緩和するには、 [PD Control](https://docs.pingcap.com/tidb/stable/pd-control)使用します。 +2. レプリカのスケジュール速度制限を段階的に緩和するには、 [PD Control](https://docs.pingcap.com/tidb/stable/pd-control)を使用します。 デフォルトの新規レプリカ速度制限は30です。これは、1分間に約30のリージョンが1つのTiFlashインスタンス上でTiFlashレプリカを追加または削除することを意味します。以下のコマンドを実行すると、すべてのTiFlashインスタンスの制限が60に調整され、速度は元の2倍になります。 @@ -243,7 +243,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla ALTER TABLE t SET TIFLASH REPLICA 2; ``` -3. PDは、 TiFlashノードの`learner_config` `server.labels`テーブルのレプリカ数（ `count` ）に基づいて、テーブル`t`のレプリカを異なるアベイラビリティゾーンにスケジュールし、可用性を確保します。詳細については、 [トポロジラベルによるレプリカのスケジュール](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels/)参照してください。次のSQL文を使用して、 TiFlashノード間のテーブルのリージョンの分散を確認できます。 +3. PDは、 TiFlashノードの`learner_config` `server.labels`テーブルのレプリカ数（ `count` ）に基づいて、テーブル`t`のレプリカを異なるアベイラビリティゾーンにスケジュールし、可用性を確保します。詳細については、 [トポロジラベルによるレプリカのスケジュール](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels/)を参照してください。次のSQL文を使用して、 TiFlashノード間のテーブルのリージョンの分散を確認できます。 ```sql -- Non-partitioned table @@ -279,9 +279,9 @@ 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)参照してください。 +TiFlashは、異なるゾーンに対するレプリカ選択戦略の設定をサポートしています。詳細については、 [`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)を参照してください。 diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index 027b56a5b8e42..f19fbe2ab81d9 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -7,7 +7,7 @@ summary: TiFlashの監視項目について学びます。 このドキュメントでは、 TiFlashの監視項目について説明します。 -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、Node_exporterを含む一連のサブダッシュボードに分かれています。診断に役立つ多くのメトリクスが用意されています。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 111820eb77beb..74cc5736af9c0 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -175,7 +175,7 @@ I/O トラフィック制限設定を構成します。 #### storage.s3 {#storage-s3} -以下の設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 +以下の設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)を参照してください。 ##### `endpoint` {#endpoint} @@ -238,7 +238,7 @@ I/O トラフィック制限設定を構成します。 ##### `disaggregated_mode` {#disaggregated-mode} -- この設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 +- この設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)を参照してください。 - 値`"tiflash_compute"`オプション: `"tiflash_write"` ##### `graceful_wait_shutdown_timeout` v8.5.4 の新機能 {#graceful-wait-shutdown-timeout-new-in-v854} @@ -444,17 +444,17 @@ I/O トラフィック制限設定を構成します。 ##### `task_scheduler_thread_soft_limit`バージョン6.0.0の新機能 {#task-scheduler-thread-soft-limit-new-in-v600} -- この項目はMinTSOスケジューラで使用されます。1つのリソースグループが使用できるスレッドの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)参照してください。 +- この項目はMinTSOスケジューラで使用されます。1つのリソースグループが使用できるスレッドの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)を参照してください。 - デフォルト値: `5000` ##### `task_scheduler_thread_hard_limit`バージョン6.0.0の新機能 {#task-scheduler-thread-hard-limit-new-in-v600} -- この項目はMinTSOスケジューラで使用されます。グローバルスコープ内のスレッドの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)参照してください。 +- この項目はMinTSOスケジューラで使用されます。グローバルスコープ内のスレッドの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)を参照してください。 - デフォルト値: `10000` ##### `task_scheduler_active_set_soft_limit`バージョン6.4.0の新機能 {#task-scheduler-active-set-soft-limit-new-in-v640} -- この項目はMinTSOスケジューラに使用されます。TiFlashで同時に実行できるクエリの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)参照してください。 +- この項目はMinTSOスケジューラに使用されます。TiFlashで同時に実行できるクエリの最大数を指定します。詳細については、 [TiFlash MinTSO スケジューラ](/tiflash/tiflash-mintso-scheduler.md)を参照してください。 - デフォルト値: バージョン7.4.0より前のバージョンでは、デフォルト値は`vcpu * 0.25`で、これはvCPU数の4分の1を意味します。バージョン7.4.0以降では、デフォルト値は`vcpu * 2`で、これはvCPU数の2倍を意味します。 #### セキュリティv4.0.5 の新機能 {#security-span-class-version-mark-new-in-v4-0-5-span} @@ -491,7 +491,7 @@ I/O トラフィック制限設定を構成します。 ### tiflash-learner.tomlファイルを設定する {#configure-the-code-tiflash-learner-toml-code-file} -`tiflash-learner.toml`のパラメータは基本的にTiKVと同じです。TiFlashの設定については[TiKV構成](/tikv-configuration-file.md)参照してください。以下はよく使用されるパラメータのみを示しています。ご注意ください。 +`tiflash-learner.toml`のパラメータは基本的にTiKVと同じです。TiFlashの設定については[TiKV構成](/tikv-configuration-file.md)を参照してください。以下はよく使用されるパラメータのみを示しています。ご注意ください。 - TiKV と比較して、 TiFlash Proxy には[`raftstore.snap-handle-pool-size`](#snap-handle-pool-size-new-in-v400)追加パラメーターがあります。 - キーが`engine`の`label`は予約されており、手動で設定することはできません。 @@ -565,22 +565,22 @@ I/O トラフィック制限設定を構成します。 #### セキュリティ.暗号化.マスターキー {#security-encryption-master-key} -- 暗号化が有効になっている場合、マスターキーを指定します。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)参照してください。 +- 暗号化が有効になっている場合、マスターキーを指定します。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)を参照してください。 #### セキュリティ.暗号化.以前のマスターキー {#security-encryption-previous-master-key} -- 新しいマスターキーをローテーションする際に使用する古いマスターキーを指定します。設定形式は`master-key`と同じです。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)参照してください。 +- 新しいマスターキーをローテーションする際に使用する古いマスターキーを指定します。設定形式は`master-key`と同じです。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)を参照してください。 #### サーバー {#server} ##### `labels` {#labels} -- `{ zone = "us-west-1", disk = "ssd" }`などのサーバー属性を指定します。ラベルを使用してレプリカをスケジュールする方法の詳細については、 [利用可能なゾーンを設定する](/tiflash/create-tiflash-replicas.md#set-available-zones)参照してください。 +- `{ zone = "us-west-1", disk = "ssd" }`などのサーバー属性を指定します。ラベルを使用してレプリカをスケジュールする方法の詳細については、 [利用可能なゾーンを設定する](/tiflash/create-tiflash-replicas.md#set-available-zones)を参照してください。 - デフォルト値: `{}` ### マルチディスク展開 {#multi-disk-deployment} -TiFlashはマルチディスク構成をサポートしています。TiFlashノードに複数のディスクがある場合、以下のセクションで説明するパラメータを設定することで、それらのディスクを最大限に活用できます。TiUPで使用するTiUPの設定テンプレートについては、 [TiFlashトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml)参照してください。 +TiFlashはマルチディスク構成をサポートしています。TiFlashノードに複数のディスクがある場合、以下のセクションで説明するパラメータを設定することで、それらのディスクを最大限に活用できます。TiUPで使用するTiUPの設定テンプレートについては、 [TiFlashトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml)を参照してください。 v4.0.9以降のバージョンのTiDBクラスターでは、 TiFlashはストレージエンジンのメインデータと最新データを複数のディスクに保存することをサポートしています。TiFlashノードを複数のディスクにデプロイする場合は、ノードのI/Oパフォーマンスを最大限に活用するために、 `[storage]`セクションでストレージディレクトリを指定することをお勧めします。 diff --git a/tiflash/tiflash-data-validation.md b/tiflash/tiflash-data-validation.md index 48a268f8b941f..2cff76c9d7466 100644 --- a/tiflash/tiflash-data-validation.md +++ b/tiflash/tiflash-data-validation.md @@ -37,7 +37,7 @@ TiFlash は自動と手動の両方のデータ検証をサポートしていま > **警告：** > -> V3検証メカニズムを有効にすると、新しく生成されたDTFileはv5.4.0より前のTiFlashでは直接読み取ることができません。v5.4.0以降、 TiFlashはV2とV3の両方をサポートしており、積極的にバージョンのアップグレードやダウングレードを行うことはありません。既存のファイルのバージョンをアップグレードまたはダウングレードする必要がある場合は、手動で[スイッチバージョン](/tiflash/tiflash-command-line-flags.md#dttool-migrate)実行する必要があります。 +> V3検証メカニズムを有効にすると、新しく生成されたDTFileはv5.4.0より前のTiFlashでは直接読み取ることができません。v5.4.0以降、 TiFlashはV2とV3の両方をサポートしており、積極的にバージョンのアップグレードやダウングレードを行うことはありません。既存のファイルのバージョンをアップグレードまたはダウングレードする必要がある場合は、手動で[スイッチバージョン](/tiflash/tiflash-command-line-flags.md#dttool-migrate)を実行する必要があります。 ### 検証ツール {#validation-tool} diff --git a/tiflash/tiflash-late-materialization.md b/tiflash/tiflash-late-materialization.md index 569695206d39a..13ff7e5dc5e23 100644 --- a/tiflash/tiflash-late-materialization.md +++ b/tiflash/tiflash-late-materialization.md @@ -9,12 +9,12 @@ summary: TiFlash の遅延マテリアライゼーション機能を使用して > > TiFlash の遅延マテリアライゼーションは[高速スキャンモード](/tiflash/use-fastscan.md)では有効になりません。 -TiFlash の遅延マテリアライゼーションは、OLAP シナリオにおけるクエリを高速化するための最適化手法です。システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)使用して、 TiFlash の遅延マテリアライゼーションの有効化または無効化を制御できます。 +TiFlash の遅延マテリアライゼーションは、OLAP シナリオにおけるクエリを高速化するための最適化手法です。システム変数[`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700)を使用して、 TiFlash の遅延マテリアライゼーションの有効化または無効化を制御できます。 - 無効にすると、フィルタ条件（ `WHERE`句）を含む`SELECT`ステートメントを処理するために、 TiFlash はクエリに必要な列からすべてのデータを読み取り、クエリ条件に基づいてデータをフィルタリングして集計します。 - 有効にすると、 TiFlash はフィルター条件の一部を TableScan オペレーターにプッシュダウンすることをサポートします。つまり、 TiFlash はまず TableScan オペレーターにプッシュダウンされたフィルター条件に関連する列データをスキャンし、条件を満たす行をフィルタリングした後、それらの行の残りの列データをスキャンしてさらに計算を行います。これにより、データ処理における IO スキャンと計算量が削減されます。 -OLAPシナリオにおける特定のクエリのパフォーマンスを向上させるため、v7.1.0以降ではTiFlashの遅延マテリアライゼーション機能がデフォルトで有効化されています。TiDBオプティマイザーは、統計情報とフィルタ条件に基づいてプッシュダウンするフィルタ条件を決定し、フィルタリング率の高いフィルタ条件を優先的にプッシュダウンします。詳細なアルゴリズムについては、 [RFC文書](https://github.com/pingcap/tidb/tree/release-8.5/docs/design/2022-12-06-support-late-materialization.md)参照してください。 +OLAPシナリオにおける特定のクエリのパフォーマンスを向上させるため、v7.1.0以降ではTiFlashの遅延マテリアライゼーション機能がデフォルトで有効化されています。TiDBオプティマイザーは、統計情報とフィルタ条件に基づいてプッシュダウンするフィルタ条件を決定し、フィルタリング率の高いフィルタ条件を優先的にプッシュダウンします。詳細なアルゴリズムについては、 [RFC文書](https://github.com/pingcap/tidb/tree/release-8.5/docs/design/2022-12-06-support-late-materialization.md)を参照してください。 例えば： diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index e4149b573fd46..5ac02eb8479b8 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -9,7 +9,7 @@ TiFlash MinTSOスケジューラは、 TiFlash内の[MPP](/glossary.md#massively ## 背景 {#background} -MPPクエリを処理する際、TiDBはクエリを1つ以上のMPPタスクに分割し、これらのMPPタスクを対応するTiFlashノードに送信してコンパイルおよび実行します。TiFlashが[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)使用する前に、各MPPタスクを実行するために複数のスレッドを使用する必要があります。具体的なスレッド数は、MPPタスクの複雑さとTiFlashに設定された同時実行パラメータによって異なります。 +MPPクエリを処理する際、TiDBはクエリを1つ以上のMPPタスクに分割し、これらのMPPタスクを対応するTiFlashノードに送信してコンパイルおよび実行します。TiFlashが[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用する前に、各MPPタスクを実行するために複数のスレッドを使用する必要があります。具体的なスレッド数は、MPPタスクの複雑さとTiFlashに設定された同時実行パラメータによって異なります。 同時実行性の高いシナリオでは、 TiFlashノードは複数のMPPタスクを同時に受信します。MPPタスクの実行が制御されていない場合、 TiFlashがシステムに要求する必要があるスレッド数は、MPPタスク数の増加に伴って直線的に増加します。スレッド数が多すぎるとTiFlashの実行効率に影響を与える可能性があります。また、オペレーティングシステム自体がサポートするスレッド数には制限があるため、オペレーティングシステムが提供できる以上のスレッドをTiFlashが要求するとエラーが発生します。 diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index f3cc020a88b23..6649b776af1a9 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -35,7 +35,7 @@ TiFlashはTiDBと互換性があります。TiDBをTiFlashの計算エンジン ワークロードの分離を確保するため、 TiFlash をTiKV とは別のノードにデプロイすることをお勧めします。業務上の分離が不要な場合は、 TiFlashと TiKV を同じノードにデプロイすることも可能です。 -現在、 TiFlashに直接データを書き込むことはできません。TiKV は TiDB クラスターにLearnerロールとして接続するため、 TiFlashにデータを書き込み、それを複製する必要があります。TiFlashはテーブル単位でのデータ複製をサポートしていますが、デプロイ後、デフォルトではデータは複製されません。指定したテーブルのデータを複製するには、 [テーブルのTiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md#create-tiflash-replicas-for-tables)参照してください。 +現在、 TiFlashに直接データを書き込むことはできません。TiKV は TiDB クラスターにLearnerロールとして接続するため、 TiFlashにデータを書き込み、それを複製する必要があります。TiFlashはテーブル単位でのデータ複製をサポートしていますが、デプロイ後、デフォルトではデータは複製されません。指定したテーブルのデータを複製するには、 [テーブルのTiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md#create-tiflash-replicas-for-tables)を参照してください。 TiFlashは、列指向ストレージコンポーネントとTiFlashプロキシコンポーネントという2つの主要コンポーネントで構成されています。TiFlashコンポーネントは、Multi-Raftコンセンサスアルゴリズムを用いた通信を担います。 @@ -78,7 +78,7 @@ TiFlash は、次の 2 つの方法で TiDB のコンピューティングを高 - 列型ストレージエンジンは読み取り操作の実行においてより効率的です。 - TiFlash はTiDB のコンピューティング ワークロードの一部を共有します。 -TiFlashは、TiKVコプロセッサーと同様にコンピューティングワークロードを分散します。TiDBは、ストレージレイヤーで完了可能なコンピューティングをプッシュダウンします。コンピューティングをプッシュダウンできるかどうかは、 TiFlashのサポート状況によって異なります。詳細については、 [サポートされているプッシュダウン計算](/tiflash/tiflash-supported-pushdown-calculations.md)参照してください。 +TiFlashは、TiKVコプロセッサーと同様にコンピューティングワークロードを分散します。TiDBは、ストレージレイヤーで完了可能なコンピューティングをプッシュダウンします。コンピューティングをプッシュダウンできるかどうかは、 TiFlashのサポート状況によって異なります。詳細については、 [サポートされているプッシュダウン計算](/tiflash/tiflash-supported-pushdown-calculations.md)を参照してください。 ## TiFlashを使用する {#use-tiflash} @@ -100,8 +100,8 @@ TPC-H データセットでのデータのインポートからクエリまで -- TiFlashノードを含む新しいクラスターを展開するには、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 -- デプロイされたクラスターにTiFlashノードを追加するには、 [TiFlashクラスターのスケールアウト](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)参照してください。 +- TiFlashノードを含む新しいクラスターを展開するには、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 +- デプロイされたクラスターにTiFlashノードを追加するには、 [TiFlashクラスターのスケールアウト](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)を参照してください。 - [TiFlashクラスターを管理](/tiflash/maintain-tiflash.md) 。 - [TiFlashのパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) 。 - [TiFlashの設定](/tiflash/tiflash-configuration.md) 。 diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index 84165c7a9cd09..d906fad8fd994 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -10,7 +10,7 @@ summary: TiFlashパイプライン実行モデルについて学びましょう バージョン7.2.0以降、 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`は非推奨になりました。 +- 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パイプライン実行モデルは、従来のスレッド スケジューリング モデルとは異なる、きめの細かいタスク スケジューリング モデルを提供します。これにより、オペレーティング システムのスレッド アプリケーションとスケジューリングのオーバーヘッドが削減され、きめ細かいスケジューリング メカニズムが提供されます。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 8d36cc3e87703..ab672630b55e2 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -611,7 +611,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ > **注記：** > - > 特定の条件下では、この構成項目は`rocksdb.(defaultcf|writecf|lockcf|raftcf).level0-slowdown-writes-trigger`の値を上書きできます。詳細については、 [`rocksdb.(defaultcf|writecf|lockcf|raftcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)参照してください。 + > 特定の条件下では、この構成項目は`rocksdb.(defaultcf|writecf|lockcf|raftcf).level0-slowdown-writes-trigger`の値を上書きできます。詳細については、 [`rocksdb.(defaultcf|writecf|lockcf|raftcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)を参照してください。 - デフォルト値: `20` @@ -621,7 +621,7 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ > **注記：** > - > 特定の条件下では、この構成項目は`rocksdb.(defaultcf|writecf|lockcf|raftcf).soft-pending-compaction-bytes-limit`の値を上書きできます。詳細については、 [`rocksdb.(defaultcf|writecf|lockcf|raftcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)参照してください。 + > 特定の条件下では、この構成項目は`rocksdb.(defaultcf|writecf|lockcf|raftcf).soft-pending-compaction-bytes-limit`の値を上書きできます。詳細については、 [`rocksdb.(defaultcf|writecf|lockcf|raftcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)を参照してください。 - デフォルト値: `"192GiB"` @@ -1525,7 +1525,7 @@ RocksDBに関連するコンフィグレーション項目 ### `track-and-verify-wals-in-manifest` 、v6.5.9、v7.1.5、v7.5.2、v8.0.0 で新しく追加されました。 {#track-and-verify-wals-in-manifest-new-in-v659-v715-v752-and-v800} -- RocksDB MANIFEST ファイルに先行書き込みログ (WAL) ファイルに関する情報を記録するかどうか、および起動時に WAL ファイルの整合性を検証するかどうかを制御します。詳細については、「RocksDB [マニフェストでWALを追跡する](https://github.com/facebook/rocksdb/wiki/Track-WAL-in-MANIFEST)参照してください。 +- RocksDB MANIFEST ファイルに先行書き込みログ (WAL) ファイルに関する情報を記録するかどうか、および起動時に WAL ファイルの整合性を検証するかどうかを制御します。詳細については、「RocksDB [マニフェストでWALを追跡する](https://github.com/facebook/rocksdb/wiki/Track-WAL-in-MANIFEST)を参照してください。 - デフォルト値: `true` - お得なオプション： - `true` : WAL ファイルに関する情報を MANIFEST ファイルに記録し、起動時に WAL ファイルの整合性を検証します。 @@ -2283,11 +2283,11 @@ Raft Engineに関連するコンフィグレーション項目。 ### `master-key` {#master-key} -- 暗号化が有効な場合はマスターキーを指定します。マスターキーの設定方法については、[保存時の暗号化- 暗号化の設定](/encryption-at-rest.md#configure-encryption)参照してください。 +- 暗号化が有効な場合はマスターキーを指定します。マスターキーの設定方法については、[保存時の暗号化- 暗号化の設定](/encryption-at-rest.md#configure-encryption)を参照してください。 ### `previous-master-key` {#previous-master-key} -- 新しいマスター キーをローテーションするときに古いマスター キーを指定します。構成形式は`master-key`と同じです。マスターキーの設定方法については、[保存時の暗号化- 暗号化の設定](/encryption-at-rest.md#configure-encryption)参照してください。 +- 新しいマスター キーをローテーションするときに古いマスター キーを指定します。構成形式は`master-key`と同じです。マスターキーの設定方法については、[保存時の暗号化- 暗号化の設定](/encryption-at-rest.md#configure-encryption)を参照してください。 ## インポート {#import} @@ -2742,7 +2742,7 @@ 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)参照してください。 +- 対応するリソース グループの[リクエストユニット（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に基づいたスケジューリングが有効になっていることを意味します。 diff --git a/tikv-control.md b/tikv-control.md index 037dc39b3f8cf..0bb8424e608a6 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -395,9 +395,9 @@ tikv-ctl --data-dir /path/to/tikv bad-regions ### TiKV構成を動的に変更する {#modify-the-tikv-configuration-dynamically} -`modify-tikv-config`コマンドを使用して、設定引数を動的に変更できます。現在、動的に変更可能な TiKV 設定項目と詳細な変更は、SQL 文を使用した設定変更と一貫性があります。詳細については、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)参照してください。 +`modify-tikv-config`コマンドを使用して、設定引数を動的に変更できます。現在、動的に変更可能な TiKV 設定項目と詳細な変更は、SQL 文を使用した設定変更と一貫性があります。詳細については、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)を参照してください。 -- `-n`設定項目の完全な名前を指定するために使用されます。動的に変更可能な設定項目のリストについては、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)参照してください。 +- `-n`設定項目の完全な名前を指定するために使用されます。動的に変更可能な設定項目のリストについては、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)を参照してください。 - `-v`構成値を指定するために使用されます。 `shared block cache`のサイズを設定します: @@ -633,4 +633,4 @@ v6.5.4およびv7.3.0以降、TiKVはリゾルバの最新の詳細情報を取 number of transactions: 0, stopped: false, -このサブコマンドは、 ステイル読み取りおよびsafe-tsに関連する問題の診断に役立ちます。詳細については、 [TiKV におけるステイル読み取りと safe-ts の理解](/troubleshoot-stale-read.md)参照してください。 +このサブコマンドは、 ステイル読み取りおよびsafe-tsに関連する問題の診断に役立ちます。詳細については、 [TiKV におけるステイル読み取りと safe-ts の理解](/troubleshoot-stale-read.md)を参照してください。 diff --git a/tikv-overview.md b/tikv-overview.md index 02c6c4d3a2f4d..4b420c9a314bb 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -29,7 +29,7 @@ Leaderレプリカをあるノードから別のノードに移動させる場 ## 分散トランザクション {#distributed-transaction} -TiKVは分散トランザクションをサポートします。ユーザー（またはTiDB）は、同じリージョンに属しているかどうかを気にすることなく、複数のキーと値のペアを書き込むことができます。TiKVは2フェーズコミットを使用してACID制約を実現します。詳細は[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)参照してください。 +TiKVは分散トランザクションをサポートします。ユーザー（またはTiDB）は、同じリージョンに属しているかどうかを気にすることなく、複数のキーと値のペアを書き込むことができます。TiKVは2フェーズコミットを使用してACID制約を実現します。詳細は[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 ## TiKVコプロセッサー {#tikv-coprocessor} diff --git a/time-to-live.md b/time-to-live.md index 45bb41bede6e2..6c9575c8e9cc0 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -254,7 +254,7 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー - TTL 属性は、ローカル一時テーブルやグローバル一時テーブルなどの一時テーブルには設定できません。 - TTL 属性を持つテーブルは、外部キー制約のプライマリ テーブルとして他のテーブルから参照されることをサポートしていません。 - すべての期限切れデータが直ちに削除されることは保証されません。期限切れデータが削除されるタイミングは、バックグラウンドクリーンアップジョブのスケジュール間隔とスケジュールウィンドウによって異なります。 -- [クラスター化インデックス](/clustered-indexes.md)使用するテーブルの場合、次のシナリオでのみ、TTL ジョブを複数のサブタスクに分割できます。 +- [クラスター化インデックス](/clustered-indexes.md)を使用するテーブルの場合、次のシナリオでのみ、TTL ジョブを複数のサブタスクに分割できます。 - 主キーまたは複合主キーの最初の列は、 `INTEGER`またはバイナリ文字列型です。バイナリ文字列型は主に以下のものを指します。 - `CHAR(N) CHARACTER SET BINARY` - `VARCHAR(N) CHARACTER SET BINARY` diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index 2a129f5911300..f79e09e68144d 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -23,7 +23,7 @@ summary: TiProxy のコマンドライン起動フラグについて学習しま - TiProxy 構成ファイルのパスを指定します。 - タイプ: `string` - デフォルト: `""` -- 設定ファイルを指定する必要があります。詳細な設定項目については、 [TiProxy を設定する](/tiproxy/tiproxy-configuration.md)を参照してください。設定ファイルが変更されると、TiProxyは自動的に設定を再読み込みするため、設定ファイルを直接変更しないでください。3または[`kubectl edit tc`](https://docs.pingcap.com/tidb-in-kubernetes/stable/modify-tidb-configuration) [`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)実行して設定を変更することをお勧めします。 +- 設定ファイルを指定する必要があります。詳細な設定項目については、 [TiProxy を設定する](/tiproxy/tiproxy-configuration.md)を参照してください。設定ファイルが変更されると、TiProxyは自動的に設定を再読み込みするため、設定ファイルを直接変更しないでください。3または[`kubectl edit tc`](https://docs.pingcap.com/tidb-in-kubernetes/stable/modify-tidb-configuration) [`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)を実行して設定を変更することをお勧めします。 ## TiProxy コントロール {#tiproxy-control} diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 5a58dbbc130d8..927d438f4e23b 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -5,7 +5,7 @@ summary: TiProxy を構成する方法を学びます。 # TiProxyコンフィグレーションファイル {#tiproxy-configuration-file} -このドキュメントでは、 TiProxyの導入と使用に関連する設定パラメータについて説明します。TiUP導入トポロジの設定については、 [tiproxy-servers の設定](/tiup/tiup-cluster-topology-reference.md#tiproxy_servers)参照してください。 +このドキュメントでは、 TiProxyの導入と使用に関連する設定パラメータについて説明します。TiUP導入トポロジの設定については、 [tiproxy-servers の設定](/tiup/tiup-cluster-topology-reference.md#tiproxy_servers)を参照してください。 以下に構成例を示します。 @@ -119,14 +119,14 @@ TiProxy の負荷分散ポリシーの構成。 - デフォルト値: `""` - ホットリロードのサポート: はい - [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)に使用するラベル名を指定します。TiProxy は、このラベル名に基づいて TiDB サーバーのラベル値を照合し、自分と同じラベル値を持つ TiDB サーバーへのルーティング要求を優先します。 -- デフォルト値の`label-name`は空文字列で、ラベルベースの負荷分散が使用されないことを示します。この負荷分散ポリシーを有効にするには、この設定項目を空でない文字列に設定し、TiProxy で[`labels`](#labels) 、TiDB で[`labels`](/tidb-configuration-file.md#labels)の両方を設定する必要があります。詳細については、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)参照してください。 +- デフォルト値の`label-name`は空文字列で、ラベルベースの負荷分散が使用されないことを示します。この負荷分散ポリシーを有効にするには、この設定項目を空でない文字列に設定し、TiProxy で[`labels`](#labels) 、TiDB で[`labels`](/tidb-configuration-file.md#labels)の両方を設定する必要があります。詳細については、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を参照してください。 #### `policy` {#policy} - デフォルト値: `resource` - ホットリロードのサポート: はい - `location` `connection`値: `resource` -- 負荷分散ポリシーを指定します。各値の意味については、 [TiProxy 負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md#configure-load-balancing-policies)参照してください。 +- 負荷分散ポリシーを指定します。各値の意味については、 [TiProxy 負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md#configure-load-balancing-policies)を参照してください。 ### ハ {#ha} @@ -147,7 +147,7 @@ server_configs: ha.interface: "eth0" ``` -TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートされます。コンピューティングレイヤーのリソースを分離する必要がある場合は、複数の仮想IPアドレスを設定し、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)組み合わせて使用​​できます。設定例については、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)参照してください。 +TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートされます。コンピューティングレイヤーのリソースを分離する必要がある場合は、複数の仮想IPアドレスを設定し、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)組み合わせて使用​​できます。設定例については、 [ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を参照してください。 > **注記：** > diff --git a/tiproxy/tiproxy-deployment-topology.md b/tiproxy/tiproxy-deployment-topology.md index 6d015c7ba4ef4..e79694405f1fe 100644 --- a/tiproxy/tiproxy-deployment-topology.md +++ b/tiproxy/tiproxy-deployment-topology.md @@ -10,8 +10,8 @@ summary: 最小限の TiDB トポロジに基づく TiProxy の展開トポロ その他の展開方法については、次のドキュメントを参照してください。 - TiDB Operatorを使用して TiProxy をデプロイするには、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tiproxy)ドキュメントを参照してください。 -- TiUPを使用して TiProxy をローカルに素早く展開するには、 [TiProxyをデプロイ](/tiup/tiup-playground.md#deploy-tiproxy)参照してください。 -- TiUPを使用して TiProxy を展開するには、 [インストールと使用方法](/tiproxy/tiproxy-overview.md#installation-and-usage)参照してください。 +- TiUPを使用して TiProxy をローカルに素早く展開するには、 [TiProxyをデプロイ](/tiup/tiup-playground.md#deploy-tiproxy)を参照してください。 +- TiUPを使用して TiProxy を展開するには、 [インストールと使用方法](/tiproxy/tiproxy-overview.md#installation-and-usage)を参照してください。 TiProxy は TiDB の L7 プロキシサーバーであり、接続のバランスを取り、可能な場合はセッションを移行できます。 @@ -31,14 +31,14 @@ TiProxy は TiDB の L7 プロキシサーバーであり、接続のバラン ### トポロジテンプレート {#topology-templates} -TiProxy のテンプレートの詳細については、 [TiProxyトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)参照してください。 +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パラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)参照してください。 +- TiProxyパラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)を参照してください。 > **注記：** > diff --git a/tiproxy/tiproxy-grafana.md b/tiproxy/tiproxy-grafana.md index 51a4276fb2052..efa77b9286886 100644 --- a/tiproxy/tiproxy-grafana.md +++ b/tiproxy/tiproxy-grafana.md @@ -7,7 +7,7 @@ summary: TiProxy の監視項目について学習します。 このドキュメントでは、TiProxy の監視項目について説明します。 -TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)参照してください。 +TiUPを使用してTiDBクラスターをデプロイする場合、監視システム（PrometheusとGrafana）も同時にデプロイされます。詳細については、 [監視フレームワークの概要](/tidb-monitoring-framework.md)を参照してください。 Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、TiProxy、Node_exporterを含む一連のサブダッシュボードに分かれています。診断に役立つ多くのメトリクスが用意されています。各ダッシュボードには、パネルグループとそのパネルが含まれています。 diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index ee17598fb4d0e..4726280433ea7 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -144,10 +144,10 @@ TiProxy は、TiProxy サーバーと TiDB サーバーの場所に基づいて TiProxyは、ラベル`zone`に基づいて自身とTiDBサーバの場所を決定します。以下の設定項目を設定する必要があります。 -- TiDBサーバーの設定項目[`labels`](/tidb-configuration-file.md#labels)で、 `zone`現在のアベイラビリティゾーンに設定します。設定の詳細については、 [TiDBのラベルを構成する](/schedule-replicas-by-topology-labels.md#optional-configure-labels-for-tidb)参照してください。 +- TiDBサーバーの設定項目[`labels`](/tidb-configuration-file.md#labels)で、 `zone`現在のアベイラビリティゾーンに設定します。設定の詳細については、 [TiDBのラベルを構成する](/schedule-replicas-by-topology-labels.md#optional-configure-labels-for-tidb)を参照してください。 - TiProxy の[`labels`](/tiproxy/tiproxy-configuration.md#labels)の構成項目で、 `zone`現在の可用性ゾーンに設定します。 -TiDB Operatorを使用してデプロイされたクラスターについては、 [データの高可用性](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data)参照してください。 +TiDB Operatorを使用してデプロイされたクラスターについては、 [データの高可用性](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data)を参照してください。 以下はクラスタ構成の例です。 @@ -206,4 +206,4 @@ TiProxy では、 [`policy`](/tiproxy/tiproxy-configuration.md#policy)構成項 ## その他のリソース {#more-resources} -TiProxy の負荷分散ポリシーの詳細については、 [設計書](https://github.com/pingcap/tiproxy/blob/main/docs/design/2024-02-01-multi-factor-based-balance.md)参照してください。 +TiProxy の負荷分散ポリシーの詳細については、 [設計書](https://github.com/pingcap/tiproxy/blob/main/docs/design/2024-02-01-multi-factor-based-balance.md)を参照してください。 diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index 19ef8918bded4..8cfebc7db367b 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -83,8 +83,8 @@ TiProxyは、以下のシナリオに適しています。 - 接続の維持：TiDBサーバーがスケールイン、ローリングアップグレード、またはローリング再起動を実行すると、クライアント接続が切断され、エラーが発生します。クライアントに冪等なエラー再試行メカニズムがない場合、エラーを手動で確認して修正する必要があり、作業コストが大幅に増加します。TiProxyはクライアント接続を維持できるため、クライアントはエラーを報告しません。 - 頻繁なスケールインとスケールアウト：アプリケーションのワークロードは定期的に変化する可能性があります。コストを削減するために、TiDBをクラウドにデプロイし、ワークロードに応じてTiDBサーバーを自動的にスケールインおよびスケールアウトすることができます。ただし、スケールインによってクライアントが切断される可能性があり、スケールアウトによって負荷が不均衡になる可能性があります。TiProxyはクライアント接続を維持し、負荷分散を実現できます。 -- CPU負荷の不均衡: バックグラウンドタスクが大量のCPUリソースを消費したり、接続間でワークロードが大きく変動してCPU負荷が不均衡になったりすると、TiProxyはCPU使用率に基づいて接続を移行して負荷分散を実現できます。詳細については、 [CPUベースの負荷分散](/tiproxy/tiproxy-load-balance.md#cpu-based-load-balancing)参照してください。 -- TiDBサーバーのOOM: 暴走クエリによってTiDBサーバーのメモリが不足した場合、TiProxyはOOMリスクを事前に検出し、他の正常な接続を別のTiDBサーバーに移行することで、クライアントの接続を継続的に確保します。詳細については、 [メモリベースの負荷分散](/tiproxy/tiproxy-load-balance.md#memory-based-load-balancing)参照してください。 +- CPU負荷の不均衡: バックグラウンドタスクが大量のCPUリソースを消費したり、接続間でワークロードが大きく変動してCPU負荷が不均衡になったりすると、TiProxyはCPU使用率に基づいて接続を移行して負荷分散を実現できます。詳細については、 [CPUベースの負荷分散](/tiproxy/tiproxy-load-balance.md#cpu-based-load-balancing)を参照してください。 +- TiDBサーバーのOOM: 暴走クエリによってTiDBサーバーのメモリが不足した場合、TiProxyはOOMリスクを事前に検出し、他の正常な接続を別のTiDBサーバーに移行することで、クライアントの接続を継続的に確保します。詳細については、 [メモリベースの負荷分散](/tiproxy/tiproxy-load-balance.md#memory-based-load-balancing)を参照してください。 TiProxyは、以下のシナリオには適していません。 @@ -105,7 +105,7 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー その他の導入方法については、以下のドキュメントを参照してください。 - TiDB Operatorを使用して TiProxy をデプロイするには、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tiproxy)ドキュメントを参照してください。 -- TiUPを使用して TiProxy をローカルにすばやくデプロイするには、 [TiProxyをデプロイ](/tiup/tiup-playground.md#deploy-tiproxy)参照してください。 +- TiUPを使用して TiProxy をローカルにすばやくデプロイするには、 [TiProxyをデプロイ](/tiup/tiup-playground.md#deploy-tiproxy)を参照してください。 ### TiProxyでクラスターを作成する {#create-a-cluster-with-tiproxy} @@ -129,13 +129,13 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー 以下の点にご注意ください。 - - ワークロードの種類と最大 QPS に基づいて、TiProxy インスタンスのモデルと数を選択します。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)参照してください。 - - TiProxyインスタンスは通常TiDBサーバーインスタンスよりも少ないため、TiProxyのネットワーク帯域幅がボトルネックになりやすくなります。たとえば、AWSでは、同じシリーズのEC2インスタンスのベースラインネットワーク帯域幅はCPUコア数に比例しません。ネットワーク帯域幅がボトルネックになった場合は、TiProxyインスタンスをより多くの小さなインスタンスに分割してQPSを向上させることができます。詳細については、 [ネットワーク仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html#co_network)参照してください。 + - ワークロードの種類と最大 QPS に基づいて、TiProxy インスタンスのモデルと数を選択します。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)を参照してください。 + - TiProxyインスタンスは通常TiDBサーバーインスタンスよりも少ないため、TiProxyのネットワーク帯域幅がボトルネックになりやすくなります。たとえば、AWSでは、同じシリーズのEC2インスタンスのベースラインネットワーク帯域幅はCPUコア数に比例しません。ネットワーク帯域幅がボトルネックになった場合は、TiProxyインスタンスをより多くの小さなインスタンスに分割してQPSを向上させることができます。詳細については、 [ネットワーク仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html#co_network)を参照してください。 - トポロジ構成ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスタをアップグレードするためにコマンド[`tiup cluster upgrade`](/tiup/tiup-component-cluster-upgrade.md)を実行した際にTiProxyが自動的にアップグレードされるのを防ぎ、TiProxyのアップグレードによってクライアント接続が切断されるのを防止できます。 - TiProxy のテンプレートの詳細については、 [TiProxyトポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)参照してください。 + 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)を参照してください。 設定例は以下のとおりです。 @@ -157,7 +157,7 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー 3. クラスターを起動します。 - TiUPを使用してクラスターを起動するには、 [TiUPドキュメント](/tiup/tiup-documentation-guide.md)参照してください。 + TiUPを使用してクラスターを起動するには、 [TiUPドキュメント](/tiup/tiup-documentation-guide.md)を参照してください。 4. TiProxyに接続します。 @@ -225,7 +225,7 @@ TiProxyがデプロイされていないクラスターの場合、TiProxyイン ### TiProxyの設定を変更します {#modify-tiproxy-configuration} -TiProxy がクライアント接続を維持するようにするため、必要がない限り TiProxy を再起動しないでください。そのため、TiProxy の設定項目のほとんどはオンラインで変更できます。オンラインでの変更をサポートする設定項目のリストについては、 [TiProxyの設定](/tiproxy/tiproxy-configuration.md)参照してください。 +TiProxy がクライアント接続を維持するようにするため、必要がない限り TiProxy を再起動しないでください。そのため、TiProxy の設定項目のほとんどはオンラインで変更できます。オンラインでの変更をサポートする設定項目のリストについては、 [TiProxyの設定](/tiproxy/tiproxy-configuration.md)を参照してください。 TiUPを使用してTiProxyの設定を変更する場合、変更する設定項目がオンライン変更に対応している場合は、オプション[`--skip-restart`](/tiup/tiup-component-cluster-reload.md#--skip-restart)を使用することでTiProxyの再起動を回避できます。 @@ -247,7 +247,7 @@ tiup cluster upgrade --tiproxy-version --tiproxy-version **注記：** > @@ -777,7 +777,7 @@ grafana_servers: - `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 -- `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"）です。 +- `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 の構成としてターゲット マシンに転送されるローカル ファイルを指定します。 @@ -787,7 +787,7 @@ grafana_servers: - `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 -- `listen_host` : Alertmanager にプロキシ経由でアクセスできるように、リスニングアドレスを指定します。 `0.0.0.0`に設定することをお勧めします。詳細については、 [Alertmanager 設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-alertmanager-configurations)参照してください。 +- `listen_host` : Alertmanager にプロキシ経由でアクセスできるように、リスニングアドレスを指定します。 `0.0.0.0`に設定することをお勧めします。詳細については、 [Alertmanager 設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-alertmanager-configurations)を参照してください。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index 114f18c78a6a5..35be267b8a808 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -44,7 +44,7 @@ tiup mirror clone [global version] [flags] ### - {コンポーネント} {#component} -- クローンするコンポーネントのバージョンリストを指定します`{component}`にコンポーネント名を入力してください。3 [`tiup list --all`](/tiup/tiup-command-list.md)実行すると、使用可能なコンポーネント名が表示されます。 +- クローンするコンポーネントのバージョンリストを指定します`{component}`にコンポーネント名を入力してください。3 [`tiup list --all`](/tiup/tiup-command-list.md)を実行すると、使用可能なコンポーネント名が表示されます。 - データ型: 文字列 - デフォルト: Null diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index dbeff0bef4c7d..455025b64e5b9 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -10,7 +10,7 @@ summary: 「tiup mirror merge」コマンドは、1つまたは複数のミラ このコマンドを実行するには、次の条件を満たしている必要があります。 - ターゲット ミラーのすべてのコンポーネントの所有者 ID が現在のミラーに存在します。 -- このコマンドを実行するユーザーの`${TIUP_HOME}/keys`ディレクトリには、現在のミラー内の上記の所有者 ID に対応するすべての秘密鍵が含まれています (コマンド[`tiup mirror set`](/tiup/tiup-command-mirror-set.md)使用して、現在のミラーを現在変更が許可されているミラーに切り替えることができます)。 +- このコマンドを実行するユーザーの`${TIUP_HOME}/keys`ディレクトリには、現在のミラー内の上記の所有者 ID に対応するすべての秘密鍵が含まれています (コマンド[`tiup mirror set`](/tiup/tiup-command-mirror-set.md)を使用して、現在のミラーを現在変更が許可されているミラーに切り替えることができます)。 ## 構文 {#syntax} diff --git a/tiup/tiup-command-mirror-rotate.md b/tiup/tiup-command-mirror-rotate.md index 63cb56d4bab70..935c71c93a21a 100644 --- a/tiup/tiup-command-mirror-rotate.md +++ b/tiup/tiup-command-mirror-rotate.md @@ -15,7 +15,7 @@ summary: TiUPミラーローテートは、 TiUPミラー内のroot.jsonファ - タイムスタンプ.json - 有効期限は`root.json` 。公式ミラーの場合、有効期限は作成日`root.json`の 1 年後となります。 -TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup/tiup-mirror-reference.md)参照してください。 +TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup/tiup-mirror-reference.md)を参照してください。 以下の場合には`root.json`更新する必要があります。 @@ -35,7 +35,7 @@ TiUP はコマンド`tiup mirror rotate`を使用して上記のプロセスを > **注記：** > -> - TiUPバージョン1.5.0より前のバージョンでは、このコマンドを実行しても正しい新しい`root.json`ファイルが返されません[＃983](https://github.com/pingcap/tiup/issues/983)参照してください。 +> - TiUPバージョン1.5.0より前のバージョンでは、このコマンドを実行しても正しい新しい`root.json`ファイルが返されません[＃983](https://github.com/pingcap/tiup/issues/983)を参照してください。 > - このコマンドを使用する前に、すべてのTiUPクライアントが v1.5.0 以降のバージョンにアップグレードされていることを確認してください。 ## 構文 {#syntax} @@ -52,7 +52,7 @@ tiup mirror rotate [flags] ### --addr {#addr} -- 一時サーバーのリスニングアドレスを指定します。他のミラー管理者が[`sign`コマンド](/tiup/tiup-command-mirror-sign.md)使用してファイルに署名できるように、このアドレスにアクセスできることを確認する必要があります。 +- 一時サーバーのリスニングアドレスを指定します。他のミラー管理者が[`sign`コマンド](/tiup/tiup-command-mirror-sign.md)を使用してファイルに署名できるように、このアドレスにアクセスできることを確認する必要があります。 - データ型: `STRING` - コマンドでこのオプションを指定しない場合、 TiUP はデフォルトで`0.0.0.0:8080`でリッスンします。 diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index fc35eaba85d04..c047a0fe759ac 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -51,6 +51,6 @@ tiup status [flags] > > TiUPの`Pending Offline` 、PD API によって返される`Offline` 、および TiDB Dashboardの`Leaving`同じステータスを示します。 -コンポーネントのステータスはPDスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)参照してください。 +コンポーネントのステータスはPDスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)を参照してください。 [<< 前のページに戻る - TiUPリファレンスコマンドリスト](/tiup/tiup-reference.md#command-list) diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 03b090de6385b..0ca2e5906313d 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -11,7 +11,7 @@ summary: TiUP クラスタは、ハードウェアとソフトウェア環境が ### オペレーティング システムのバージョン {#operating-system-version} -デプロイされたマシンのオペレーティングシステムのディストリビューションとバージョンを確認してください。サポートされているバージョンのリストについては、 [OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)参照してください。 +デプロイされたマシンのオペレーティングシステムのディストリビューションとバージョンを確認してください。サポートされているバージョンのリストについては、 [OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を参照してください。 ### CPU EPOLLEX限定 {#cpu-epollexclusive} diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index 28323d22d9f08..4973741bd5293 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -46,7 +46,7 @@ tiup cluster deploy [flags] ### --no-labels {#no-labels} - このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 - テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`使用してチェックをスキップできます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 34faf9e746b1c..1633b1314f126 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -99,6 +99,6 @@ tiup cluster display [flags] > > TiUPの`Pending Offline` 、PD API によって返される`Offline` 、および TiDB Dashboardの`Leaving`同じステータスを示します。 -ノードのサービスステータスはPDのスケジューリング情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)参照してください。 +ノードのサービスステータスはPDのスケジューリング情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)を参照してください。 [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-edit-config.md b/tiup/tiup-component-cluster-edit-config.md index 7c67418a72e1e..fd164369e8adc 100644 --- a/tiup/tiup-component-cluster-edit-config.md +++ b/tiup/tiup-component-cluster-edit-config.md @@ -9,7 +9,7 @@ summary: tiup cluster edit-config` コマンドを使用すると、デプロイ > **注記：** > -> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-cluster-scale-out.md)参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-cluster-scale-in.md)参照してください。 +> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-cluster-scale-out.md)を参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-cluster-scale-in.md)を参照してください。 > - `tiup cluster edit-config`コマンドを実行すると、コントロールマシン上でのみ設定が変更されます。その後、 `tiup cluster reload`コマンドを実行して設定を再読み込みする必要があります。 ## 構文 {#syntax} @@ -31,6 +31,6 @@ tiup cluster edit-config [flags] ## 出力 {#output} - コマンドが正常に実行された場合、出力はありません。 -- 変更できないフィールドを誤って変更した場合、ファイルを保存するとエラーが表示され、再度編集する必要があることが通知されます。変更できないフィールドについては、 [トポロジファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 +- 変更できないフィールドを誤って変更した場合、ファイルを保存するとエラーが表示され、再度編集する必要があることが通知されます。変更できないフィールドについては、 [トポロジファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-scale-out.md b/tiup/tiup-component-cluster-scale-out.md index 2c50b0e80f702..40d5945b85ce8 100644 --- a/tiup/tiup-component-cluster-scale-out.md +++ b/tiup/tiup-component-cluster-scale-out.md @@ -42,7 +42,7 @@ tiup cluster scale-out [flags] ### --no-labels {#no-labels} - このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタトポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタトポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 - テスト環境では、このリスクは問題にならない可能性があり、 `--no-labels`使用してチェックをスキップできます。 - データ型: `BOOLEAN` - デフォルト: false diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index a3495f2785a01..5098ed528d2a2 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -9,7 +9,7 @@ summary: tiup dm edit-config`コマンドを使用すると、デプロイメン > **注記：** > -> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-dm-scale-out.md)参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-dm-scale-in.md)参照してください。 +> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-dm-scale-out.md)を参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-dm-scale-in.md)を参照してください。 > - `tiup dm edit-config`コマンドを実行すると、コントロールマシン上でのみ設定が変更されます。その後、 `tiup dm reload`コマンドを実行して設定を再読み込みする必要があります。 ## 構文 {#syntax} @@ -31,6 +31,6 @@ tiup dm edit-config [flags] ## 出力 {#output} - 通常は出力されません。 -- 変更できないフィールドを誤って変更した場合、ファイルを保存するとエラーが表示され、ファイルを再度編集するように促されます。変更できないフィールドについては、 [トポロジファイル](/tiup/tiup-dm-topology-reference.md)参照してください。 +- 変更できないフィールドを誤って変更した場合、ファイルを保存するとエラーが表示され、ファイルを再度編集するように促されます。変更できないフィールドについては、 [トポロジファイル](/tiup/tiup-dm-topology-reference.md)を参照してください。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index 3cd207ebedbbd..e22e10f08a78e 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -65,8 +65,8 @@ global: `server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。6 `server_configs`は主に以下のフィールドが含まれます。 -- `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)参照してください。 -- `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)参照してください。 +- `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 +- `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 `server_configs`構成の例は次のとおりです。 @@ -93,7 +93,7 @@ server_configs: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `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"）です。 +- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 - `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。6を指定した場合、セクション`config` `config`設定が`server_configs` `master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 @@ -149,7 +149,7 @@ master_servers: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `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"）です。 +- `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、ターゲットマシンに[numactl](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[numactl](https://linux.die.net/man/8/numactl)を使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 - `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。6を指定した場合、セクション`config` `config`設定が`server_configs` `worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 @@ -192,7 +192,7 @@ worker_servers: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `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"）です。 +- `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"）です。 - `storage_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は「15日」です。 - `rule_dir` : `*.rules.yml`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズでPrometheusルールとしてターゲットマシンに送信されます。 - `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 @@ -285,7 +285,7 @@ grafana_servers: - `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 -- `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"）です。 +- `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 の構成としてターゲットマシンに送信されます。 - `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`os`値です。 - `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`番目のセクションで設定された`arch`値になります。 diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 34c831153bdd5..f5a3f33e5fc32 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -32,7 +32,7 @@ GitHash: c3e9fc518aea0da66a37f82ee5a516171de9c372 > **注記：** > -> TiUPバージョン1.11.3以降では、新規TiUP時にテレメトリがデフォルトで無効化され、使用状況情報は収集されず、PingCAPと共有されません。共有される情報と共有を無効にする方法については、 [テレメトリー](/telemetry.md)参照してください。 +> TiUPバージョン1.11.3以降では、新規TiUP時にテレメトリがデフォルトで無効化され、使用状況情報は収集されず、PingCAPと共有されません。共有される情報と共有を無効にする方法については、 [テレメトリー](/telemetry.md)を参照してください。 ## TiUPエコシステムの紹介 {#tiup-ecosystem-introduction} diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 5c2d08c7f7e55..3324f9075aa0a 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -179,9 +179,9 @@ TiUP v1.15.0以降では、 TiUP Playgroundを使用してクラスターにTiPr --tiproxy.version string The version of TiProxy. If not specified, the latest version of TiProxy is deployed. ``` -TiProxyのデプロイと使用方法の詳細については、 [TiProxyのインストールと使用方法](/tiproxy/tiproxy-overview.md#installation-and-usage)参照してください。 +TiProxyのデプロイと使用方法の詳細については、 [TiProxyのインストールと使用方法](/tiproxy/tiproxy-overview.md#installation-and-usage)を参照してください。 -TiProxyクライアントプログラム`tiproxyctl`を使用するには、 [TiProxy Controlをインストールする](/tiproxy/tiproxy-command-line-flags.md#install-tiproxy-control)参照してください。 +TiProxyクライアントプログラム`tiproxyctl`を使用するには、 [TiProxy Controlをインストールする](/tiproxy/tiproxy-command-line-flags.md#install-tiproxy-control)を参照してください。 ## PDマイクロサービスをデプロイ {#deploy-pd-microservices} diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ba4809fba802..20e1b0745ad7a 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -5,7 +5,7 @@ summary: TiUPの使用中に問題が発生した場合のトラブルシュー # TiUPトラブルシューティングガイド {#tiup-troubleshooting-guide} -このドキュメントでは、 TiUPの使用時によくある問題とそのトラブルシューティング方法について解説します。このドキュメントに記載されていない問題が発生した場合、Github TiUPリポジトリの[新しい問題を提出する](https://github.com/pingcap/tiup/issues)参照してください。 +このドキュメントでは、 TiUPの使用時によくある問題とそのトラブルシューティング方法について解説します。このドキュメントに記載されていない問題が発生した場合、Github TiUPリポジトリの[新しい問題を提出する](https://github.com/pingcap/tiup/issues)を参照してください。 ## TiUPコマンドのトラブルシューティング {#troubleshoot-tiup-commands} @@ -23,7 +23,7 @@ TiUPはミラーサーバーから最新のコンポーネントリストを毎 ### コンポーネントのダウンロードプロセス中にチェックサムエラーが発生しました {#a-checksum-error-occurs-during-component-downloading-process} -CDNサーバーのキャッシュ時間が短いため、新しいチェックサムファイルがコンポーネントパッケージと一致しない可能性があります。5分後に再度ダウンロードをお試しください。それでも新しいチェックサムファイルがコンポーネントパッケージと一致しない場合は、問題[ここ](https://github.com/pingcap/tiup/issues)報告してください。 +CDNサーバーのキャッシュ時間が短いため、新しいチェックサムファイルがコンポーネントパッケージと一致しない可能性があります。5分後に再度ダウンロードをお試しください。それでも新しいチェックサムファイルがコンポーネントパッケージと一致しない場合は、問題[ここ](https://github.com/pingcap/tiup/issues)を報告してください。 ## TiUPクラスタコンポーネントのトラブルシューティング {#troubleshoot-tiup-cluster-component} diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index c12a2b8c1ac44..2c323eb13d0e9 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -32,7 +32,7 @@ TiDBはスナップショット分離（SI）一貫性を実装しており、My > > TiDB v3.0以降、トランザクションの自動再試行はデフォルトで無効になっています。自動再試行を有効にすると**、トランザクション分離レベルが損なわれる**可能性があるため、有効にすることは推奨されません。詳細は[トランザクションの再試行](/optimistic-transaction.md#automatic-retry)を参照してください。 > -> TiDB v3.0.8以降、新規に作成されたTiDBクラスタはデフォルトで[悲観的トランザクションモード](/pessimistic-transaction.md)使用します。現在の読み取り（ `for update`読み取り）**は繰り返し不可能な読み取り**です。詳細は[悲観的トランザクションモード](/pessimistic-transaction.md)を参照してください。 +> TiDB v3.0.8以降、新規に作成されたTiDBクラスタはデフォルトで[悲観的トランザクションモード](/pessimistic-transaction.md)を使用します。現在の読み取り（ `for update`読み取り）**は繰り返し不可能な読み取り**です。詳細は[悲観的トランザクションモード](/pessimistic-transaction.md)を参照してください。 ## 繰り返し読み取り分離レベル {#repeatable-read-isolation-level} diff --git a/transaction-overview.md b/transaction-overview.md index fa5d8c4d8e15a..71d7527f52aab 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -57,7 +57,7 @@ COMMIT; > **ヒント：** > -> [楽観的トランザクション](/optimistic-transaction.md)有効にする前に、アプリケーションが`COMMIT`ステートメントでエラーが返される可能性があることを正しく処理できることを確認してください。アプリケーションがこれをどのように処理するか不明な場合は、代わりにデフォルトの[悲観的トランザクション](/pessimistic-transaction.md)使用することをお勧めします。 +> [楽観的トランザクション](/optimistic-transaction.md)有効にする前に、アプリケーションが`COMMIT`ステートメントでエラーが返される可能性があることを正しく処理できることを確認してください。アプリケーションがこれをどのように処理するか不明な場合は、代わりにデフォルトの[悲観的トランザクション](/pessimistic-transaction.md)を使用することをお勧めします。 ### トランザクションのロールバック {#rolling-back-a-transaction} @@ -280,7 +280,7 @@ TiDBでは以前、1トランザクションあたりのキーと値のペアの > **注記：** > -> 因果一貫性のあるトランザクションは、非同期コミット機能と1相コミット機能が有効な場合にのみ有効になります。これらの2つの機能の詳細については、 [`tidb_enable_async_commit`](/system-variables.md#tidb_enable_async_commit-new-in-v50)と[`tidb_enable_1pc`](/system-variables.md#tidb_enable_1pc-new-in-v50)参照してください。 +> 因果一貫性のあるトランザクションは、非同期コミット機能と1相コミット機能が有効な場合にのみ有効になります。これらの2つの機能の詳細については、 [`tidb_enable_async_commit`](/system-variables.md#tidb_enable_async_commit-new-in-v50)と[`tidb_enable_1pc`](/system-variables.md#tidb_enable_1pc-new-in-v50)を参照してください。 TiDBは、トランザクションの因果一貫性の有効化をサポートしています。因果一貫性のあるトランザクションは、コミット時にPDからタイムスタンプを取得する必要がなく、コミットレイテンシーが低くなります。因果一貫性を有効にする構文は次のとおりです。 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index c28665f9290ce..2d720674a0642 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -64,7 +64,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - PDはパニックになる[バグを報告する](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md) 。 -- その他の原因。1と`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)実行してgoroutineを取得します。 +- その他の原因。1と`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)を実行してgoroutineを取得します。 ### TiKVの異常 {#tikv-anomalies} diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 3affeed9ad8ec..c44e486587a8a 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -47,7 +47,7 @@ TiDBのコーディングルールによれば、同一テーブルのデータ 一方、TiDBのRowIDもデフォルトでAUTO_INCREMENTされます。主キーが整数型でない場合は、書き込みホットスポットの問題が発生する可能性があります。 -さらに、データ書き込み（新規作成されたテーブルまたはパーティション）またはデータ読み取り（読み取り専用シナリオにおける定期的な読み取りホットスポット）のプロセス中にホットスポットが発生した場合、テーブル属性を使用してリージョンのマージ動作を制御できます。詳細については、 [テーブル属性を使用してリージョン結合の動作を制御する](/table-attributes.md#control-the-region-merge-behavior-using-table-attributes)参照してください。 +さらに、データ書き込み（新規作成されたテーブルまたはパーティション）またはデータ読み取り（読み取り専用シナリオにおける定期的な読み取りホットスポット）のプロセス中にホットスポットが発生した場合、テーブル属性を使用してリージョンのマージ動作を制御できます。詳細については、 [テーブル属性を使用してリージョン結合の動作を制御する](/table-attributes.md#control-the-region-merge-behavior-using-table-attributes)を参照してください。 ### インデックスホットスポット {#index-hotspots} @@ -154,13 +154,13 @@ SELECT LAST_INSERT_ID(); 上記の負荷図に示されているように、 `AUTO_INCREMENT`代わりに`AUTO_RANDOM`使用すると、ホットスポットを適切に分散できます。 -詳細については[AUTO_RANDOM](/auto-random.md)参照してください。 +詳細については[AUTO_RANDOM](/auto-random.md)を参照してください。 ## 小さなテーブルホットスポットの最適化 {#optimization-of-small-table-hotspots} TiDBのコプロセッサーキャッシュ機能は、計算結果のキャッシュのプッシュダウンをサポートします。この機能を有効にすると、TiDBはTiKVにプッシュダウンされる計算結果をキャッシュします。この機能は、小さなテーブルの読み取りホットスポットに適しています。 -詳細については[コプロセッサーキャッシュ](/coprocessor-cache.md)参照してください。 +詳細については[コプロセッサーキャッシュ](/coprocessor-cache.md)を参照してください。 **参照:** diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index 9efa64ab38156..660de362b9a67 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -155,7 +155,7 @@ CURRENT_SQL_DIGEST_TEXT: update `t` set `v` = `v` + ? where `id` = ? ; セッションがスキーマの変更を待機している場合、メタデータ ロックが原因である可能性があります。 -詳細については[メタデータロック](/metadata-lock.md)参照してください。 +詳細については[メタデータロック](/metadata-lock.md)を参照してください。 ## 楽観的ロックの競合のトラブルシューティング {#troubleshoot-optimistic-lock-conflicts} diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 94a3ed4496522..fc4c78b99a37b 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -47,7 +47,7 @@ resolved-ts）は、この値より小さいタイムスタンプを持つすべ ![Stale Read Req Traffic](/media/stale-read/traffic.png) -上記のメトリックの詳細については、 [TiDB 監視メトリクス](/grafana-tidb-dashboard.md#kv-request)参照してください。 +上記のメトリックの詳細については、 [TiDB 監視メトリクス](/grafana-tidb-dashboard.md#kv-request)を参照してください。 ステイル読み取り の問題が発生すると、前述の指標に変化が見られる場合があります。最も直接的な指標は、TiDB の WARN ログです。このログには、リージョンID が`DataIsNotReady`で、検出された`safe-ts`報告されます。 @@ -65,7 +65,7 @@ resolved-ts）は、この値より小さいタイムスタンプを持つすべ ### tikv-ctlを使用して診断する {#use-code-tikv-ctl-code-to-diagnose} -`tikv-ctl`リゾルバの最新の詳細情報を提供し、 `RegionReadProgress`リゾルバの最新の詳細情報を提供します。詳細については[リージョンの`RegionReadProgress`の状態を取得する](/tikv-control.md#get-the-state-of-a-regions-regionreadprogress)参照してください。 +`tikv-ctl`リゾルバの最新の詳細情報を提供し、 `RegionReadProgress`リゾルバの最新の詳細情報を提供します。詳細については[リージョンの`RegionReadProgress`の状態を取得する](/tikv-control.md#get-the-state-of-a-regions-regionreadprogress)を参照してください。 次に例を示します。 @@ -142,7 +142,7 @@ TiKV は 10 秒ごとに次のメトリックをチェックします。 - ログからロックに関する十分な情報を取得できない場合は、テーブル[`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md#cluster_tidb_trx)を使用してアクティブなトランザクションを見つけます。 -- [`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md)実行すると、同じTiDBサーバーに接続されている現在のセッションと、現在のステートメントに費やされた時間が表示されます。ただし、start_tsは表示されません。 +- [`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md)を実行すると、同じTiDBサーバーに接続されている現在のセッションと、現在のステートメントに費やされた時間が表示されます。ただし、start_tsは表示されません。 進行中の大規模トランザクションが原因でロックが存在する場合は、これらのロックによって解決の進行が妨げられる可能性があるため、アプリケーション ロジックの変更を検討してください。 diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index f4ebc1de34924..e77ff38768242 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -13,7 +13,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - 構成と展開トポロジ - `dmesg`のTiDBコンポーネント関連の問題 -その他の情報については[よくある質問（FAQ）](/faq/tidb-faq.md)参照してください。 +その他の情報については[よくある質問（FAQ）](/faq/tidb-faq.md)を参照してください。 ## データベースに接続できません {#cannot-connect-to-the-database} @@ -40,7 +40,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - 起動パラメータにエラーがあります。 - [TiDB の構成とオプション](/command-line-flags-for-tidb-configuration.md)参照してください。 + [TiDB の構成とオプション](/command-line-flags-for-tidb-configuration.md)を参照してください。 - 港は占領されています。 @@ -57,7 +57,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 `tikv-server`起動できない場合の状況については以下を参照してください。 -- 起動パラメータのエラー: [TiKVの設定とオプション](/command-line-flags-for-tikv-configuration.md)参照してください。 +- 起動パラメータのエラー: [TiKVの設定とオプション](/command-line-flags-for-tikv-configuration.md)を参照してください。 - ポートが使用中です: `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tikv-server`開始するポートが使用されていないことを確認します。 @@ -81,7 +81,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 - 起動パラメータにエラーがあります。 - [PD構成とオプション](/command-line-flags-for-pd-configuration.md)参照してください。 + [PD構成とオプション](/command-line-flags-for-pd-configuration.md)を参照してください。 - 港は占領されています。 diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 5b2d606d4e1b2..6758c23706c47 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -19,7 +19,7 @@ summary: TiDB OOM (メモリ不足) の問題を診断して解決する方法 - **TiDB-Runtime** >**メモリ使用量で**は、 `estimate-inuse`メトリックが上昇し続けていることがわかります。 - `tidb.log`確認すると、次のログ エントリが見つかります。 - - OOMに関するアラーム: `[WARN] [memory_usage_alarm.go:139] ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"]` 。詳細については、 [`memory-usage-alarm-ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)参照してください。 + - OOMに関するアラーム: `[WARN] [memory_usage_alarm.go:139] ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"]` 。詳細については、 [`memory-usage-alarm-ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)を参照してください。 - 再起動に関するログエントリ: `[INFO] [printer.go:33] ["Welcome to TiDB."]` 。 ## 全体的なトラブルシューティングプロセス {#overall-troubleshooting-process} @@ -115,10 +115,10 @@ OOM 問題のさまざまな原因に応じて、SQL ステートメントのメ TiDBノードは起動後、統計情報をメモリに読み込む必要があります。TiDBは統計情報を収集する際にメモリを消費します。メモリ使用量は、以下の方法で制御できます。 - サンプリング レートを指定し、特定の列の統計情報のみを収集し、同時実行性を`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 が統計を更新するときに最大メモリ使用量を制御できます。 +- 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 が統計を更新するときに最大メモリ使用量を制御できます。 -詳細については[統計入門](/statistics.md)参照してください。 +詳細については[統計入門](/statistics.md)を参照してください。 #### プリペアドステートメントの過剰使用 {#prepared-statements-are-overused} diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 41d0c8121021a..c8519af1ca27a 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -11,7 +11,7 @@ TiDB v3.0.8より前のバージョンでは、TiDBはデフォルトで楽観 ## 書き込み競合の原因 {#the-reason-of-write-conflicts} -TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf)トランザクションモデルを用いてトランザクションを実装します。3 `percolator`一般的に2PCの実装です。2PCの詳細なプロセスについては[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)参照してください。 +TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf)トランザクションモデルを用いてトランザクションを実装します。3 `percolator`一般的に2PCの実装です。2PCの詳細なプロセスについては[TiDB 楽観的トランザクションモデル](/optimistic-transaction.md)を参照してください。 クライアントが TiDB に`COMMIT`リクエストを送信すると、TiDB は 2PC プロセスを開始します。 diff --git a/tune-operating-system.md b/tune-operating-system.md index 51fe9742c944e..ba73a3bdcb1f2 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -35,11 +35,11 @@ summary: オペレーティング システムのパラメータを調整する ### パフォーマンス {#perf} -perf は、Linux カーネルが提供する重要なパフォーマンス解析ツールです。ハードウェアレベル（CPU/PMU、パフォーマンス監視ユニット）の機能とソフトウェアレベル（ソフトウェアカウンタ、トレースポイント）の機能の両方をカバーしています。詳細な使用方法については、 [perf の例](http://www.brendangregg.com/perf.html#Background)参照してください。 +perf は、Linux カーネルが提供する重要なパフォーマンス解析ツールです。ハードウェアレベル（CPU/PMU、パフォーマンス監視ユニット）の機能とソフトウェアレベル（ソフトウェアカウンタ、トレースポイント）の機能の両方をカバーしています。詳細な使用方法については、 [perf の例](http://www.brendangregg.com/perf.html#Background)を参照してください。 ### BCC/bpftrace {#bcc-bpftrace} -CentOS 7.6以降、LinuxカーネルはBerkeley Packet Filter（BPF）をサポートしています。そのため、 [60秒で](#in-60-seconds)の結果に基づいて適切なツールを選択し、詳細な分析を行うことができます。perf/ftraceと比較すると、BPFはプログラマビリティが高く、パフォーマンスオーバーヘッドが少ないという利点があります。kprobeと比較すると、BPFはセキュリティが高く、本番環境に適しています。BCCツールキットの詳細な使用方法については、 [BPF コンパイラ コレクション (BCC)](https://github.com/iovisor/bcc/blob/master/README.md)参照してください。 +CentOS 7.6以降、LinuxカーネルはBerkeley Packet Filter（BPF）をサポートしています。そのため、 [60秒で](#in-60-seconds)の結果に基づいて適切なツールを選択し、詳細な分析を行うことができます。perf/ftraceと比較すると、BPFはプログラマビリティが高く、パフォーマンスオーバーヘッドが少ないという利点があります。kprobeと比較すると、BPFはセキュリティが高く、本番環境に適しています。BCCツールキットの詳細な使用方法については、 [BPF コンパイラ コレクション (BCC)](https://github.com/iovisor/bcc/blob/master/README.md)を参照してください。 ## パフォーマンスチューニング {#performance-tuning} @@ -56,7 +56,7 @@ cpufreq は、CPU周波数を動的に調整するモジュールです。5つ - 割り込みのバランスをとる必要があるデバイスを特定します。CentOS 7.5以降では、 `be2iscsi`ドライバとNVMe設定を使用するデバイスなど、特定のデバイスとそのドライバに対して、システムが最適な割り込みアフィニティを自動的に設定します。これらのデバイスに対しては、手動で割り込みアフィニティを設定することはできなくなりました。 - その他のデバイスについては、チップのマニュアルを参照して、これらのデバイスが割り込み分散をサポートしているかどうかを確認してください。 - そうでない場合、これらのデバイスのすべての割り込みは同じ CPU にルーティングされ、変更できなくなります。 - - 該当する場合は、 `smp_affinity`マスクを計算し、対応する設定ファイルを設定します。詳細については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)参照してください。 + - 該当する場合は、 `smp_affinity`マスクを計算し、対応する設定ファイルを設定します。詳細については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)を参照してください。 ### NUMA CPU バインディング {#numa-cpu-binding} @@ -111,7 +111,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler - NICハードウェアキャッシュ：ハードウェアレベルでパケットロスを正しく監視するには、コマンド`ethtool -S ${NIC_DEV_NAME}`使用してフィールド`drops`監視します。パケットロスが発生した場合、ハード/ソフト割り込みの処理速度がNICの受信速度に追いつかない可能性があります。受信バッファサイズが上限を下回っている場合は、パケットロスを回避するためにRXバッファを増やすことも検討できます。クエリコマンドは`ethtool -g ${NIC_DEV_NAME}` 、変更コマンドは`ethtool -G ${NIC_DEV_NAME}`です。 -- ハードウェア割り込み：NICが受信側スケーリング（RSS、マルチNIC受信とも呼ばれる）機能をサポートしている場合は、 `/proc/interrupts` NIC割り込みを確認してください。割り込みが不均等な場合は、 [CPU—周波数スケーリング](#cpufrequency-scaling) 、 [CPU—割り込み親和性](#cpuinterrupt-affinity) 、および[NUMA CPU バインディング](#numa-cpu-binding)参照してください。NICがRSSをサポートしていない場合、またはRSSの数が物理CPUコア数よりも大幅に少ない場合は、受信パケットステアリング（RPS、RSSのソフトウェア実装とみなすことができます）と、RPSの拡張である受信フローステアリング（RFS）を設定してください。詳細な設定については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/networking/scaling.txt)参照してください。 +- ハードウェア割り込み：NICが受信側スケーリング（RSS、マルチNIC受信とも呼ばれる）機能をサポートしている場合は、 `/proc/interrupts` NIC割り込みを確認してください。割り込みが不均等な場合は、 [CPU—周波数スケーリング](#cpufrequency-scaling) 、 [CPU—割り込み親和性](#cpuinterrupt-affinity) 、および[NUMA CPU バインディング](#numa-cpu-binding)参照してください。NICがRSSをサポートしていない場合、またはRSSの数が物理CPUコア数よりも大幅に少ない場合は、受信パケットステアリング（RPS、RSSのソフトウェア実装とみなすことができます）と、RPSの拡張である受信フローステアリング（RFS）を設定してください。詳細な設定については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/networking/scaling.txt)を参照してください。 - ソフトウェア割り込み： `/proc/net/softnet_stat`の監視を監視します。3列目以外の列の値が増加している場合は、 `softirq`の`net.core.netdev_budget`または`net.core.dev_weight`の値を適切に調整して、CPU 時間を増やします。さらに、CPU 使用率も確認し、どのタスクが頻繁に CPU を使用しているか、そしてそれらを最適化できるかどうかを特定する必要があります。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index d02329a6ae874..6b0ab60c283d6 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -42,7 +42,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - gRPC スレッド プール。 - v8.5.4以降、gRPCスレッドプールのデフォルトサイズ（ `server.grpc-concurrency`で設定）が固定値の`5`から、CPUコア数に基づいて計算される適応値に変更されました。詳細な計算式については、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)参照してください。このスレッドプールはコンピューティングオーバーヘッドがほとんどなく、主にネットワークI/Oとデシリアライズリクエストを処理するため、通常はデフォルト設定を調整する必要はありません。 + 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`を増やすことを検討してください。 diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index 7a5682af1e752..0583b4f33a51f 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -89,7 +89,7 @@ alertmanager_servers: ### 配置ルール {#placement-rules} -計画されたトポロジに基づいてクラスターをデプロイするには、 [配置ルール](/configure-placement-rules.md)使用してクラスターレプリカの配置場所を決定する必要があります。4 つのレプリカ（Voter レプリカ 2 つをプライマリ AZ、Voter レプリカ 1 つをディザスタリカバリ AZ に、 Learnerレプリカ 1 つをディザスタリカバリ AZ に配置）のデプロイを例に挙げると、配置ルールを使用してレプリカを次のように設定できます。 +計画されたトポロジに基づいてクラスターをデプロイするには、 [配置ルール](/configure-placement-rules.md)を使用してクラスターレプリカの配置場所を決定する必要があります。4 つのレプリカ（Voter レプリカ 2 つをプライマリ AZ、Voter レプリカ 1 つをディザスタリカバリ AZ に、 Learnerレプリカ 1 つをディザスタリカバリ AZ に配置）のデプロイを例に挙げると、配置ルールを使用してレプリカを次のように設定できます。 cat rule.json [ @@ -275,7 +275,7 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status 同期レプリケーションモードのクラスタに災害が発生した場合、 `RPO = 0`でデータリカバリを実行できます。 -- プライマリ AZ に障害が発生し、Voter レプリカの大部分が失われたものの、災害復旧 AZ に完全なデータが存在する場合、失われたデータは災害復旧 AZ から復旧できます。この場合、専門ツールを用いた手動介入が必要です。復旧ソリューションについては、PingCAP またはコミュニティから[サポートを受ける](/support.md)参照してください。 +- プライマリ AZ に障害が発生し、Voter レプリカの大部分が失われたものの、災害復旧 AZ に完全なデータが存在する場合、失われたデータは災害復旧 AZ から復旧できます。この場合、専門ツールを用いた手動介入が必要です。復旧ソリューションについては、PingCAP またはコミュニティから[サポートを受ける](/support.md)を参照してください。 - 災害復旧 AZ に障害が発生し、いくつかの Voter レプリカが失われた場合、クラスターは自動的に非同期レプリケーション モードに切り替わります。 diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index 355e6f743f553..d57aece568eb8 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -12,7 +12,7 @@ TiDB クラスターをデプロイすると、 TiUP はクラスターの監視 > **注記：** > > - 監視サービスが[手動で展開](/deploy-monitoring-services.md)場合、 TiUPを使用する代わりに、このドキュメントを参照せずに直接アップグレードできます。 -> - TiDBと新しいバージョンの監視サービスとの互換性はテストされていないため、アップグレード後、一部の機能が期待どおりに動作しない可能性があります。問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)作成してください。 +> - TiDBと新しいバージョンの監視サービスとの互換性はテストされていないため、アップグレード後、一部の機能が期待どおりに動作しない可能性があります。問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を作成してください。 > - このドキュメントのアップグレード手順は、 TiUPバージョン 1.9.0 以降に適用されます。そのため、アップグレード前にTiUP のバージョンをご確認ください。 > - TiUPを使用して TiDB クラスターをアップグレードすると、 TiUP は監視サービスをデフォルトバージョンに再デプロイします。TiDB のアップグレード後、監視サービスのアップグレードを再度実行する必要があります。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index d1b832ba82894..60055e612e244 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -47,7 +47,7 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま - 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)を参照してください。 @@ -205,7 +205,7 @@ tiup cluster upgrade v8.5.4 > > - 安定したパフォーマンスを維持するには、TiKV インスタンスを停止する前に、インスタンス内のすべてのリーダーが強制終了されていることを確認してください。 `--transfer-timeout`を、例えば`--transfer-timeout 3600` (単位: 秒) のように、より大きな値に設定できます。 > -> - TiFlash をv5.3.0 より前のバージョンから v5.3.0 以降にアップグレードするには、 TiFlash を停止してからアップグレードする必要があります。また、 TiUP のバージョンは v1.12.0 より前である必要があります。詳細については、 [TiUPを使用してTiFlashをアップグレードする](/tiflash-upgrade-guide.md#upgrade-tiflash-using-tiup)参照してください。 +> - TiFlash をv5.3.0 より前のバージョンから v5.3.0 以降にアップグレードするには、 TiFlash を停止してからアップグレードする必要があります。また、 TiUP のバージョンは v1.12.0 より前である必要があります。詳細については、 [TiUPを使用してTiFlashをアップグレードする](/tiflash-upgrade-guide.md#upgrade-tiflash-using-tiup)を参照してください。 #### アップグレード時にコンポーネントのバージョンを指定してください。 {#specify-the-component-version-during-upgrade} diff --git a/user-account-management.md b/user-account-management.md index 746ce29ff1e14..76b9c57638897 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -28,9 +28,9 @@ mysql -P 4000 -u xxx -p You can create TiDB accounts in two ways: - アカウントを作成して権限を確立するための標準のアカウント管理 SQL ステートメント ( [`CREATE USER`](/sql-statements/sql-statement-create-user.md)や[`GRANT`](/sql-statements/sql-statement-grant-privileges.md)など) を使用します。 -- [`INSERT`](/sql-statements/sql-statement-insert.md)などのステートメントを使用して権限テーブルを直接操作し、 [`DELETE`](/sql-statements/sql-statement-delete.md) [`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)実行します。この方法で[`UPDATE`](/sql-statements/sql-statement-update.md)更新が不完全になる可能性があるため、アカウントの作成または変更にはこの方法を使用しないことをお勧めします。 +- [`INSERT`](/sql-statements/sql-statement-insert.md)などのステートメントを使用して権限テーブルを直接操作し、 [`DELETE`](/sql-statements/sql-statement-delete.md) [`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)を実行します。この方法で[`UPDATE`](/sql-statements/sql-statement-update.md)更新が不完全になる可能性があるため、アカウントの作成または変更にはこの方法を使用しないことをお勧めします。 -[サードパーティのGUIツール](/develop/dev-guide-third-party-support.md#gui)使用してアカウントを作成することもできます。 +[サードパーティのGUIツール](/develop/dev-guide-third-party-support.md#gui)を使用してアカウントを作成することもできます。 ```sql CREATE USER [IF NOT EXISTS] user [IDENTIFIED BY 'auth_string']; @@ -141,7 +141,7 @@ TiDB は、データベースの初期化中に`'root'@'%'`デフォルト ア ## アカウントのリソース制限を設定する {#set-account-resource-limits} -TiDBは、リソースグループを使用してユーザーが消費するリソースを制限できます。詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)参照してください。 +TiDBは、リソースグループを使用してユーザーが消費するリソースを制限できます。詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 ## アカウントパスワードの割り当て {#assign-account-passwords} @@ -211,6 +211,6 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ ユーザーと権限に関する情報はTiKVサーバーに保存され、TiDBはこれらの情報をプロセス内にキャッシュします。通常、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md) 、その他[`GRANT`](/sql-statements/sql-statement-grant-privileges.md)ステートメントによる関連情報の変更は、クラスター全体に迅速に反映されます。一時的なネットワーク利用不可などの要因によって操作が影響を受ける場合、TiDBは定期的にキャッシュ情報を再読み込みするため、変更は約15分後に反映されます。 -権限テーブルを直接変更した場合は、 [`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)実行して変更をすぐに適用します。 +権限テーブルを直接変更した場合は、 [`FLUSH PRIVILEGES`](/sql-statements/sql-statement-flush-privileges.md)を実行して変更をすぐに適用します。 詳細は[権限管理](/privilege-management.md)参照。 diff --git a/user-defined-variables.md b/user-defined-variables.md index 1490204f624d4..0d28da3fda9e3 100644 --- a/user-defined-variables.md +++ b/user-defined-variables.md @@ -144,4 +144,4 @@ SELECT @col FROM t; `SELECT ... INTO `を除いて、MySQL と TiDB でサポートされる構文は同一です。 -詳細については[MySQLのユーザー定義変数](https://dev.mysql.com/doc/refman/8.0/en/user-variables.html)参照してください。 +詳細については[MySQLのユーザー定義変数](https://dev.mysql.com/doc/refman/8.0/en/user-variables.html)を参照してください。 diff --git a/wrong-index-solution.md b/wrong-index-solution.md index 65381573efae8..cdd7ba287fa53 100644 --- a/wrong-index-solution.md +++ b/wrong-index-solution.md @@ -49,15 +49,15 @@ summary: 間違ったインデックスの問題を解決する方法を学び デフォルトでは、TiDBはコスト見積もりに基づいてテーブルアクセスにTiKVまたはTiFlashを選択します。エンジン分離を適用することで、同じクエリに対して異なるエンジンを試すことができます。 -詳細については[エンジン分離](/tiflash/use-tidb-to-read-tiflash.md#engine-isolation)参照してください。 +詳細については[エンジン分離](/tiflash/use-tidb-to-read-tiflash.md#engine-isolation)を参照してください。 ## 関数プッシュダウン {#function-pushdown} クエリパフォーマンスを向上させるため、TiDB は特定の関数をTiKV またはTiFlashストレージエンジンにプッシュダウンして実行できます。ただし、一部の関数はプッシュダウンをサポートしていないため、利用可能な実行プランが制限され、クエリパフォーマンスに影響を及ぼす可能性があります。 -プッシュダウンをサポートする式については、 [TiKVはプッシュダウン計算をサポート](/functions-and-operators/expressions-pushed-down.md)と[TiFlashはプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md)参照してください。 +プッシュダウンをサポートする式については、 [TiKVはプッシュダウン計算をサポート](/functions-and-operators/expressions-pushed-down.md)と[TiFlashはプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md)を参照してください。 -特定の式のプッシュダウンを無効にすることもできます。詳細については、 [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md)参照してください。 +特定の式のプッシュダウンを無効にすることもできます。詳細については、 [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md)を参照してください。 ## 参照 {#see-also}